modeling using um l

7/28/2019 Modeling Using Um l

http://slidepdf.com/reader/full/modeling-using-um-l 1/56

3/27/20

- 1 -

Version 2.0

Unified Modeling Language(UML)

- 2 -

Models have two major aspects: semantic information

(semantics) and visual presentation (notation).

Semantics means meaning or the study of meaning.

Every model expresses a certain meaning (semantics)

represented by the model elements and their interactions.

Semantic model elements carry the meaning of the model.

ModelsWhat Is In a Model?



3/27/20

- 3 -

Modeling is the process of model creation.

In the context of software development, a typical modeling

language provides the (mainly graphical) notation elements

and their semantic to develop models that express the

product of analysis and design of the system.

A modeling language is not a programming language. A

modeling language may be less precise on purpose because

additional detail may be irrelevant.

Modeling Languages

- 4 -

A modeling language should include:

Model elements — fundamental modeling concepts

and semantics

Notation — visual rendering of model elements

Guidelines — idioms of usage

UML is the de-facto modeling language for developingsoftware applications.

Most of the models we cover are UML based

Modeling Languages (cont.)



3/27/20

5

Model Types

Models may also be classified according to many criteriasuch as:

The underlying Technology:

– Structured Analysis Modelling

– Object Oriented Modelling

Notation

– Textual

– Graphical

– Formal

Abstraction – High Level

– Low Level

6

Context Models

Context models are used to illustrate the operational

context of a system - they show what lies outside the

system boundaries.

Architectural models show the system and its relationship

with other systems.

This model as shown on the following slide is not UML.

How to represent it using UML? Answer this questionafter you finish reading this tutorial.



3/27/20

7

The Context of an ATM System

Auto-teller

system

Security

system

Main tenance

system

Account

dat abase

Usage

database

Branch

accounting

system

Branch

counter

system

- 8 -

UML Different ModelsDiagram Types

Diagram

Structure

Diagram

Behavior

Diagram

Class Diagram

Component Diagram

Composite Structure Diagram

Deployment Diagram

Object Diagram

Package Diagram

Activity Diagram

Use Case Diagram

State Machine Diagram

Interaction Diagram

Sequence Diagram

Communication

Diagram

Interaction Overview

Diagram

Timing Diagram



3/27/20

- 9 -

UML Class Diagram

- 10 -

Modeling Elements in Class Diagrams

Modeling elements in class diagrams are:

o Classes and their structure and behavior (i.e., specifications)

o Relationships: Multiplicity, navigation indicators, and role names

Types of relationships Association, aggregation, dependency, andinheritance relationships

In the following, we discuss each of these elements.



3/27/20

- 11 -

Class Diagram

An Example

- 12 -

ClassNotation

Class Name

Attributes

Operations



3/27/20

- 13 -

Class

Notation: An Example

Class Name

Attributes

Operations

- 14 -

ClassNotation: Class Name

Every class must have a name, which is a text containing any number of

letters, numbers, and certain punctuation marks and may continue over

several lines.

Class name is written with capitalized first letter of every word in the name.

Name must be unique (among class names) within its package.

Class name is displayed in the name compartment with other properties

applied to the whole class.



3/27/20

- 15 -

Class

Notation: Attributes

An attribute represents a property of the thing under modeling; that property isshared by all instances (objects) of the class.

An attribute describes a piece of information that an object owns or knows about

itself.

A class may have any number of attributes or no attributes at all.

Every object of a class will have a specific value/values for its class attributes.

Attribute names typically begin with a lowercase letter with capitalized first letter

of every word.

- 16 -

ClassNotation: Attributes (cont.)

Attribute default syntax:

[visibility] name [ multiplicity ] [: type-expression]

[= initial-value] { property-string }

Where:

– Visibility defines how the attribute can be seen and used by other

classes [an attribute may be public (+) or private (-)]. – Name is an identifier string that represents the name of the attribute.

– Multiplicity is a specification of the range of allowable cardinalities that a

set may assume.



3/27/20

- 17 -

Class

Notation: Attributes (cont.)

Attribute default syntax:

[visibility] name [ multiplicity ] [: type-expression]

[= initial-value] { property-string }

Where:

Type is language-dependent representing the allowable type of the attribute.

Initial-value indicates the initial value assumed for the attribute when a new

object is created.

Property-string includes the set of values that apply to the attribute.

- 18 -

ClassNotation: Operations

Operations are the actions that a class knows to carry out.

An operation is a service that an instance of the class may be requested to

perform to affect behavior.

Operation specifies the service that can be requested from an object of the

class, while method is the implementation of the operation.

Often, invoking an operation affects the object’s state.



3/27/20

- 19 -

Class

Notation: Operations (cont.)

Operation default syntax:

[visibility] name [( parameter-list )] [: return-type-expression] [{ property-

string }]

Where:

visibility defines how the attribute can be seen and used by other classes.

name is an identifier string that represents the name of the attribute.

return-type-expression is a language-dependent specification of the

implementation type or types of the value returned by the operation. A list of

expressions may be supplied to indicate multiple return values.

- 20 -

ClassNotation: Operations (cont.)

Operation default syntax:

[visibility] name [( parameter-list )] [: return-type-expression] [{

property-string }]

Where:

parameter-list is a comma-separated list of formal parameters.

– Parameter list may have zero or more parameters.

property-string indicates property values that apply to the operation. – {abstract} class does not implement the operation

– {query} operation has no side effects (does not modify system state).



3/27/20

- 21 -

Relationships

Introduction

Represents the basic relational building blocks of the UML that associate

(connects) things together.

Includes the following main types:

– Association,

– Generalization,

– Inheritance,

– Realization, and

– Interfaces

- 22 -

RelationshipsAssociation

An association describes discrete connections among classes in a system.

An association describes a set of links.

Link: An instance of an association.

link

association name name direction

Student Course

ahmed data structure

association end

Register



3/27/20

- 23 -

Relationships

Association

Navigation Across Association

Bidirectional, unless otherwise specified.

Can be explicitly represented by an arrowhead pointing to the direction of

traversal.

Student Course

association navigation

Register

- 24 -


Role

The named specific behavior of a classifier participating in an association.

Person Departmentemployee employer

Works for

role name



3/27/20

- 25 -

Relationships

AssociationMultiplicity

How many objects may be connected across a link?

Expression that evaluates to a range of values.

Explicit value: one (1)

zero or one (0..1)

many (0..*)

Person Departmentemployee employer

Works for1..* *

multiplicity

one or more (1..*),

exact number (e.g. 4)

- 26 -

RelationshipsAssociationConstraints

Express constraints on the association relationships.

Constraints may appear on both ends, either ends, or neither end of the

association.

Thomas A. Pender. UML Weekend Crash Course™, Wiley Publishing, Inc., 2002



3/27/20

- 27 -

Relationships

AssociationAssociation Class

An association class encapsulates information about an association.

Association classes add attributes, operations, and other features to

associations.


- 28 -

RelationshipsAssociationAggregation

A special form of association.

Specifies a whole-part relationship between the aggregate (whole) and a

component part.

aggregation

Product

Component

1

1..*

whole

part



3/27/20

- 29 -

Relationships

AssociationComposition

A form of aggregation association with strong ownership.

In a composition, an object may be a part of only one composite at a

time.

The composite must manage the creation and destruction of its parts.

Composition is used for aggregations where the life span of the part

depends on the life span of the aggregate.

- 30 -


Composition (cont.)

Car

Tire

1

4

composition



3/27/20

- 31 -

Relationships

Generalization

It is a relationship between a general thing (superclass or parent) and a

more specific kind of that thing (subclass or child).

It “is-a-kind-of ” relationship, one thing is-a-kind-of a more general thing.

A subclass inherits all the properties of its superclass. A subclass may have

its own properties in addition to the ones inherited from its superclass.

- 32 -

RelationshipsGeneralization (cont.)



3/27/20

- 33 -

Relationships

Generalization (cont.)


- 34 -

RelationshipsInheritance

Inheritance is the mechanism by which more specific elements incorporate

structure and behavior of more general elements related by behavior.

A class may have one or more superclasses.

A class that has no superclass and one or more subclasses is called a root

class.

A class that has no sublasses is called a leaf class.



3/27/20

- 35 -

Relationships

Inheritance (cont.)

- 36 -

RelationshipsInheritance (cont.)

There are two types of inheritance:

– Single inheritance: A type (class) may have only one supertype

(superclass).

– Multiple inheritance: A type (class) may have more than one supertype

(superclass).



3/27/20

- 37 -

Relationships

Inheritance (cont.)

Single inheritance

Single inheritance

- 38 -

RelationshipsInheritance (cont.)

Multiple inheritance



3/27/20

- 39 -

Package Diagram

- 40 -

Packages

A package is a grouping of model elements.

It is a general purpose mechanism for organizing modeling elements into

groups.

Packages are extremely useful on larger-scale systems. They help in

getting a picture of the dependencies between major elements of asystem.

Package name may be a simple name or a path name.



3/27/20

- 41 -

Packages

simple name

path name

package name

Simple name is the name alone

without any path information.

A path name is the package name

prefixed by the name of the

package in which that package

lives, if any.

Packages themselves may be

nested within other packages

A package may contain

subordinate packages as well as

other kinds of model elements

All kinds of UML model elements

can be organized into packages

- 42 -

Packages (cont.)



3/27/20

- 43 -

Packages (cont.)

• A package and its contents can be shown in the form of

tree.

- 44 -

Functional View

– Use Case Diagram

– Activity Diagram



3/27/20

- 45 -

Use Case Diagram

- 46 -

The Use Case ModelOverview

• The Use Case model is a collection of diagrams and text that together

document how users expect to interact with the system (i.e., the behavior of

the system from the user’s point of view).

• A “user” is anything external to the system being developed which interacts

with the system.

• Thus, a user might be a person, an information system, a hardware device,etc.



3/27/20

- 47 -

The Use Case Model

Resources

The Use Case Model makes use of three different resources to fullydescribe each requirement:

1. The Use Case Diagram,

2. The Use Case Narrative, and

3. Use Case Scenarios

Use Case

Diagram Use Case

NarrativeUse Case

Scenarios

Use Case Model

- 48 -

The Use Case ModelResources: The Use Case Diagrams

The Use Case Diagram:

– A Use Case diagram provides a high-level explanation of the

relationship between the system and the outside world.

– A Use Case diagram provides only a surface level, or black-box, view

of the system.

– Use Case diagrams use a set of Use Case to describe the system.

– a Use Case represents a discrete unit of interaction between a user

(human or machine) and the system.



3/27/20

- 49 -

The Use Case Model

Resources: The Use Case Narrative

The Use Case Narrative:

– Each Use Case presents a functionality that will be built in the

proposed system.

– A Use Case as presented in a use case diagram does not explain

what can be expected from this system feature.

– The Use Case narrative provides a fairly standard (yet user-defined)

set of information that is required to guide the analysis, design, and

coding of the corresponding feature.

- 50 -

The Use Case ModelResources: Use Case Scenarios

Use Case Scenarios:

– A Use Case is a set of scenarios tied together by a common user

goal.

– A Use Case scenario is one possible sequence of steps in the

execution of the Use Case.

– A Use Case may include any number of scenarios.

– The set of scenarios for one Use Case identifies everything that

can happen when that Use Case is used.



3/27/20

- 51 -

The Use Case Model

Resources: Use Case Scenarios (cont.)

Consider the following Buy a Product scenario in a typical Web-based on-line store:

The customer browses the catalog and adds desired items to the shopping basket.

When the customer wishes to pay, the customer describes the shipping and credit

card information and confirms the sale. The system checks the authorization on the

credit card and confirms the sale both immediately and with a follow-up e-mail.

Other possible scenarios:

– Credit card authorization fails

– Regular customer with stored shipping and credit card information, etc.

The user in the three scenarios share the same goal: to buy a product.

Martin Fowler. UML Distilled. Addison Wesley Third Edition, 2003

52

How to Describe a Use Case

1. Name: Give a short, descriptive name to the use case.

2. Actors: List the actors who can perform this use case.

3. Goals: Explain what the actor or actors are trying to achieve.

4. Preconditions: State of the system before the use case.

5. Description: Give a short informal description.

6. Related use cases.7. Steps: Describe each step using a 2-column format.

8. Post-conditions: State of the system in following completion.



3/27/20

53

Use Case Scenario ExampleBuy Items Use Case

System ResponseActor Action

1. A customer arrives at the POST with items

3. Determine item price, adds item information to

running sales transaction

2. Cashier records the identifier of each item, and its

quantity.

5. Calculates the total4. On completion, Cashier indicates the end of items

to the POST

6. Cashier tells Customer the total

7. Customer gives cash payment

9. Shows balance due8. Cashier records the sale

11. Logs completed sale10. Cashier deposits the cash , returns balance and

gives printed receipt

12. Customer leaves

54

Alternative Course of Events of Buy Items Use Case





2. Invalid identifier – error indicator shows


to the POST


7. Customer gives cash payment




12. Customer leaves



3/27/20

55





2. Invalid identifier – error indicator shows


to the POST


7a. Resets7. Not have enough cash. Cancel sale.




12. Customer leaves

Alternative Course of Events of Buy

Items Use Case (cont.)

- 56 -

Use Case DiagramBasic Elements

• The Use Case diagram consists of six graphic symbols that represent

the system: actors, system, Use Cases, associations, dependencies,

and generalizations.




3/27/20

- 57 -

Use Case Diagram

Basic Elements (cont.)

• Actor: A role played by a person, system, or device that has a stake in

the successful operation of the system.

• System: Sets the boundary of the system in relation to the actors who

uses it (outside the system) and the features it must provide (inside the

system).

• Use Case: A Use Case represents a discrete unit of interaction between

a user (human or machine) and the system. Each Use Case:

• Identifies a key feature of the system needed to fulfill the user/actor requirements

• Expresses a goal that the system must achieve

- 58 -

Use Case DiagramBasic Elements (cont.)

• Association: Identifies an interaction between actors and Use Cases.

Each association becomes a dialog that must be explained in a Use Case

narrative. Each narrative in turn provides a set of scenarios that function

as test cases for the implementation of the Use Case.

• Generalization: Defines a relationship between two actors or two Use

Cases where one Use Case inherits and adds to or overrides the

properties of the other.

• Dependency: Identifies a communication relationship between two Use

Cases.



3/27/20

- 59 -

Use Case Diagram

Use Case Notation

• Each Use Case is named using a textual string (verb phrase) that

expresses a goal the system must accomplish.

• For example, deposit money, withdraw cash, and update account.

- 60 -

Use Case DiagramUse Case: Rule of Thumb

• Problem: Developers tend to complicate use case diagrams and spend too

much time in it.

• Solution: Identify the set of Use Case that describes only those features

visible and meaningful to the actors who use the system.

• Keeping this in mind will help avoiding functional decomposition (the

breaking down of procedures and tasks into smaller and smaller processesuntil describing all the internal workings of the system).



3/27/20

- 61 -

Use Case Diagram

Relationships: Association

• An association is simply a line connecting an actor to a Use Case. This is

the only relationship between actors and use cases.

• Association is represented by a line connecting an actor to a Use Case.

• The association represents the fact that the actor communicates with the

Use Case.

• A directionality arrow on either end of the association line denotes the

direction of the communication.

- 62 -

Use Case DiagramRelationships: Association (cont.)

• For bidirectional associations, either an arrowhead is placed on both ends

of the association line, or simply no arrowheads are shown at all.




3/27/20

- 63 -

Use Case Diagram

Relationships: Include

• An include relationship from use case E (base use case) to use case F

indicates that an instance of the use case E will also contain the behavior

as specified by F..

• When one Use Case delegates to another, the dependency is drawn as a

dashed arrow from the “using” Use Case to the “used” Use Case and

labeled with the <<include>> stereotype notation.

• This conveys that executing the “using” (dependent/source) Use Case will

include or incorporate the functionality of the “used” (independent/target)

Use Case.

- 64 -

Use Case DiagramRelationships: Include (cont.)

• Delegation may occur for one of two reasons:

• Another Use Case may already exist to perform the task that is

needed.

• A number of Use Cases may need to perform the same task. Rather

than write the same logic multiple times, the common task is isolated

into its own Use Case and reused by, or included into, each Use

Case that needs it.



3/27/20

- 65 -

Use Case Diagram

Relationships: Include (cont.)

- 66 -

Use Case DiagramRelationships: Extend

• An extend relationship from use case A to use case B indicates that an

instance of use case B may be augmented (subject to specific conditions

specified in the extension) by the behavior specified by A.

• The <<extend>> dependency stereotype says that one Use Case might

need help from another Use Case.

• The <<extend>> dependency arrow points from the extension Use Case(the one providing the extra help) to the main Use Case that it is helping.



3/27/20

- 67 -

Use Case Diagram

Relationships: Extend (cont.)

- 68 -

Activity Diagram



3/27/20

69

From Use Case to Activity Diagram

Now that we have gathered the most important use cases, it is

important to get a good understanding of the relevant business

processes, especially in large projects.

So it is a good idea to model the important business processes

to give the developer a better understanding of the stakeholder

requirements and to visualize the control flow of an individual

scenario in an overview diagram.

Here UML offers the activity diagram, as a very helpful tool

to: – Visualize workflows

– Visualize use case sequences

70

The Activity Diagram

A graphical representation of process and control flow -

Similar to flow charts

Purpose – Describe business processes and individual use case scenarios

– Model concurrent behavior

It shows.

– The flow of control from activity to activity in the process,

– What activities can be done in parallel.

– Alternate paths through the flow.

They are very well understood without any computer

knowledge, so are an excellent means for user

communication



3/27/20

71

An activity diagram shows flow control within a system and models

Decisions

HandleIncident

DocumentIncident

ArchiveIncident

The Activity Diagram (cont.)

Open

Incident

Notify

Police Chief

Notify

Fire Chief

Allocate

Resources

[fire & highPriority]

[not fire & highPriority]

[lowPriority]

72

Activity Diagrams: Modeling Concurrency

Synchronization of multiple activities

Splitting the flow of control into multiple threads

SynchronizationSplitting

ArchiveIncident

OpenIncident

DocumentIncident

Allocate

Resources

CoordinateResources



3/27/20

73

Activity Diagrams: Swimlanes

Actions may be grouped into “swimlanes” to denote the object or subsystem that implements the actions.

ArchiveIncident

Dispatcher

FieldOfficer

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources

74

Elements of an Activity Diagram

Course Registration example

Browse Course

Catalog

Select Course

Info

Enter Personal

Data

Confirm

Registration

Send Email Print Bill

[else]

[data correct]

Update Course

Start Activity

Guard Branch

End



3/27/20

75

Elements of an Activity Diagram (cont.)

Browse Course

Catalog

Select Course

Info

Enter Personal

Data

Confirm

Registration

Send Email Print Bill

[else]

[data correct]

Update Course

Customer Registration

System

BillingSystem

Database

System

Swimlane

Fork

Join

Course Registration example

76

When to Use an Activity Diagram

Two main strengths to activity diagrams:

1. Can be used very well for visualizing business and workflow processes. They are not yet SW related and can be easilyunderstood by users and customers.

2. They support modeling parallel behavior. This again makesthem a very good tool for workflow modeling.

Hence, they can be used for :

Analyzing Use Cases

Understanding Workflows

Describing complicated sequential algorithms

Modeling parallel behavior



3/27/20

- 77 -

Dynamic View – Sequence Diagram

– State Machine Diagram

- 78 -

Sequence Diagram



3/27/20

- 79 -

Sequence Diagrams

Introduction

The Sequence diagram provides a path from the textual descriptions of

behaviors in the scenarios to operations/interfaces in the Class diagram.

Typically, a sequence diagram captures the behavior of a single scenario.

A sequence diagram shows the objects participating in the interaction and

the sequence of messages exchanged.

It emphasizes the time-ordering of messages.

All Sequence diagrams are modeled at the object level rather than the class

level.

- 80 -

Sequence DiagramsNotations

The Sequence diagram uses three fundamental notation elements: objects,

messages/stimuli, and object lifeline.

The object lifeline is a vertical dashed line below each object. A lifeline always

runs from the beginning at the top to the end at the bottom.

A message (stimulus), represented by an arrow, is usually a call.

The type of arrow indicates the type of message:

– A solid line and a arrowhead: a message that requires a response.

– A dashed arrow: a response.



3/27/20

- 81 -

Sequence Diagrams

Notations (cont.)

The Sequence diagram uses three fundamental notation elements: objects,messages/stimuli, and object lifeline.

The object lifeline is a vertical dashed line below each object. A lifeline always

runs from the beginning at the top to the end at the bottom.

A message (stimulus), represented by an arrow, is usually a call,

The type of arrow indicates the type of message:

– A solid line and a arrowhead: a message that requires a response.

– A dashed arrow: a response.

- 82 -


1. Object lifeline

2. Message/Stimulus

3. Iteration

4. Self-reference

5. Return

6. Anonymous object

7. Object name

8. Sequence number

9. Condition

10. Basic comment



3/27/20

- 83 -

Action Meaning

Call Invokes an operation on an object; an object may send a

message to itself, resulting in the local invocation of an

operation

Return Returns a value to the caller

Send Sends a signal to an object

Create Creates an object

Destroy Destroys an object; an object may commit suicide bydestroying itself

Sequence Diagrams

Basic Types of Actions

- 84 -

Sequence DiagramsWhen to Use Sequence Diagrams

In his book entitled UML Distilled, Martin Fowler suggests that it is better to use:

– Sequence diagrams: To look at the behavior of several objects within a

single use case.

– State diagrams: To look at the behavior of a single object across many

use cases (to be discussed shortly).

– Activity diagrams: to look at behavior across many use cases or many

threads.



3/27/20

- 85 -


86

State Machine Models

A State Machine models the behaviour of the system in

response to external and internal events.

Shows the system’s responses to stimuli (events) so are

often used for modelling real-time systems.

Shows system states as nodes and events as arcs between

these nodes.

When an event occurs, the system moves from one state

to another.

Statecharts are an integral part of the UML and are used

to represent state machine models.



3/27/20

87

off

on


Graphical Representation of object states

Lamp On

Lamp Off

off

on

88

Outputs and Actions

As the state changes, output may be generated :

on

off

Lamp On

Lamp

Off

off

on/print(”on”)



3/27/20

89

top

Basic UML Statechart Diagram

Ready

stop

/ctr := 0 stop

State

Trigger

Action

Initial pseudostate

Transition

Final

state

Done

“top” state

90

What Kind of Behavior?

In general, state machines are suitable for describing event-

driven, discrete behavior

– inappropriate for modeling continuous behavior

time

threshold



3/27/20

91

Object Behavior - General Model

Simple server model:

Handle

Request

Initialize

Object

Terminate

Object

Wait for

Request

void:offHook ();

{busy = true;

obj.reqDialtone();

…

};

Handling depends on

specific request type

92

Object Behavior and State Machines

Direct mapping:

Handle

Event

Initialize

Object

Terminate

Object

Wait for

Event

on

off

Lamp On

Lamp

Off

off

on/print(”on”)

stop



3/27/20

93

State Entry and Exit Actions

LampOn

entry/lamp.on();

exit/lamp.off();

e1

e2

94

Resulting action sequence: printf(“exiting”);

printf(“to off”);

lamp.off();

Order of Actions: Simple Case

Exit actions prefix transition actions

Entry action postfix transition actions

printf(“exiting”);

printf(“needless”);

lamp.off();

off/printf(“needless”);

off/printf(“to off”); LampOff

entry/lamp.off();

exit/printf(“exiting”);

LampOn

entry/lamp.on();

exit/printf(“exiting”);



3/27/20

95

Error

entry/printf(“error!”)

State (“Do”) Activities

Forks a concurrent thread that executes until: – the action completes or

– the state is exited through an outgoing transition

do/while (true) alarm.ring();

“do” activity

96

Guards

Conditional execution of transitions

Selling

Unhappy

Happy

bid [(value >= 100) & (value < 200)] /sell

bid [value >= 200] /sell

bid [value < 100] /reject



3/27/20

97

bid /gain := calculatePotentialGain(value)

Selling

Unhappy

Happy

Conditional Branching

Choice pseudostate: guards are evaluated at the instant when the

decision point is reached

[(gain >= 100) & (gain < 200)] /sell

[gain >= 200] /sell

[gain < 100] /reject

98

Hierarchical State Machines

States decomposed into state machines

LampFlashingflash/

1sec/

1sec/

FlashOff

entry/lamp.off()

FlashOn

entry/lamp.on()off/

LampOff

entry/lamp.off()

LampOn

entry/lamp.on()

on/

on/

on/



3/27/20

99

Statechart ExampleCourse Offering

The CourseOffering object can be in one of the followingstates:

– Initialization (prior to registration, no students added)

– Open (able to accept students)

– Closed (max number of students registered for it)

– Cancelled (no longer offered)

100

Statechart Example

Course Offering



3/27/20

- 101 -

Other UML Diagrams

- 102 -

Other UML Diagrams

This module provides a brief overview for the following UML diagrams:

– Implementation Diagrams

o Component Diagram

o Deployment Diagram



3/27/20

- 103 -

Implementation Diagrams

- 104 -

Implementation Diagrams

After completing the logical design of the system, the next step is to define

the physical implementation of the design.

The physical implementation addresses three problems: the software, the

hardware, and the integration of the two.

UML defines two types of diagrams for describing the implementation of the

system: – Component diagram: models the physical implementation of the software.

– Deployment diagram: models the physical architecture of the hardware.

Combined, they model the distribution of the application software across the

hardware implementation.



3/27/20

- 105 -

Component Diagram

Component Definition

A component is a physical unit of implementation, including software code

(source, binary or executable), with well-defined interfaces that is intended to

be used as replaceable part of a system.

Components represent pieces that are independently purchasable and

upgradeable.

Components have interfaces they support and interfaces they require from

other components.

- 106 -

Component DiagramComponent Notation

UML 1 had a distinctive symbol for a component. A component icon is

modeled as a rectangle with two small rectangles centered on the left edge.

The name is placed inside the icon:

UML 2 removed that icon but allows the annotation of a class box with asimilar-looking icon. Alternatively, the «component» keyword can be used in a

class box.

ComponentName

ComponentName

<<component>>

ComponentName



3/27/20

- 107 -

Component Diagram

Definition

A component diagram is a diagram that shows the organizations and

dependencies among components.

It addresses the static implementation view of a system.

Dependencies between components are drawn with the dashed arrow from

the dependent component to the component it needs help from.

- 108 -

Component DiagramAn Example



3/27/20

- 109 -

Deployment Diagram

Definition

Deployment diagrams show a system's physical layout, revealing whichpieces of software run on what pieces of hardware.

The focus of the Deployment diagram is the nodes on which the developed

software will run.

Each node is a physical object that represents a processing resource.

- 110 -

Deployment DiagramSome Notations

Deployment diagrams has two types of elements:

– nodes (resources) and

– associations (connections)

The node icon is drawn as a 3D box.

The lines between the nodes are physical associations that are representedas a line from one node to another.

Associations between nodes represent communication paths.



3/27/20

- 111 -

Deployment Diagram

An Example

modeling using um l

Documents