3/27/2013

Unified Modeling Language (UML) Version 2.0

-1-

Models What Is In a Model?

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.

-2-

3/27/2013

Modeling Languages
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.

-3-

Modeling Languages (cont.)

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 developing software applications. Most of the models we cover are UML based

-4-

3/27/2013

Model Types
Models may also be classified according to many criteria such as: The underlying Technology:
Structured Analysis Modelling Object Oriented Modelling

Notation
Textual Graphical Formal

Abstraction
High Level Low Level
5

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 question after you finish reading this tutorial.

3/27/2013

The Context of an ATM System

Securit y s ys tem Branch accoun t in g s ys tem Aut o -t el l er s ys tem Branch coun ter s ys tem Main tenance s ys tem Us age dat ab as e Acco un t da t abas e

UML Different Models Diagram Types

Class Diagram Component Diagram Composite Structure Diagram Deployment Diagram

Structure Diagram
Diagram Behavior Diagram

Object Diagram Package Diagram Activity Diagram Use Case Diagram State Machine Diagram Interaction Diagram
-8-

Sequence Diagram Communication Diagram Interaction Overview Diagram Timing Diagram

3/27/2013

UML Class Diagram

-9-

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, and inheritance relationships

In the following, we discuss each of these elements.

- 10 -

3/27/2013

Class Diagram An Example

- 11 -

Class Notation

Class Name Attributes

Operations

- 12 -

3/27/2013

Class Notation: An Example

Class Name Attributes

Operations

- 13 -

Class Notation: 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.

- 14 -

3/27/2013

Class Notation: Attributes

An attribute represents a property of the thing under modeling; that property is shared 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.

- 15 -

Class Notation: 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.

- 16 -

3/27/2013

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.

- 17 -

Class Notation: 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 objects state.

- 18 -

3/27/2013

Class Notation: Operations (cont.)

Operation default syntax: [visibility] name [( parameter-list )] [: return-type-expression] [{ propertystring }]
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.

- 19 -

Class Notation: 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).

- 20 -

10

3/27/2013

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

- 21 -

Relationships Association
An association describes discrete connections among classes in a system. An association describes a set of links. Link: An instance of an association.
association name Student name direction

Register

Course

association end link

ahmed
- 22 -

data structure

11

3/27/2013

Relationships Association
Navigation Across Association
Bidirectional, unless otherwise specified. Can be explicitly represented by an arrowhead pointing to the direction of traversal.

Student

Register

Course

association navigation

- 23 -

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

Person
employee

Works for
employer

Department

role name

- 24 -

12

3/27/2013

Relationships Association
Multiplicity
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..*)

one or more (1..*), exact number (e.g. 4)

multiplicity

1..*

Works for

Person
employee
- 25 -

* employer

Department

Relationships Association
Constraints
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

- 26 -

13

3/27/2013

Relationships Association
Association Class
An association class encapsulates information about an association. Association classes add attributes, operations, and other features to associations.

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

- 27 -

Relationships Association
Aggregation
A special form of association. Specifies a whole-part relationship between the aggregate (whole) and a component part.

Product
whole 1 aggregation

part

1..*

Component
- 28 -

14

3/27/2013

Relationships Association
Composition

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.

- 29 -

Relationships Association
Composition (cont.)
Car
1 composition

Tire

- 30 -

15

3/27/2013

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.

- 31 -

Relationships Generalization (cont.)

- 32 -

16

3/27/2013

Relationships Generalization (cont.)

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

- 33 -

Relationships Inheritance
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.

- 34 -

17

3/27/2013

Relationships Inheritance (cont.)

- 35 -

Relationships Inheritance (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).

- 36 -

18

3/27/2013

Relationships Inheritance (cont.)

Single inheritance

Single inheritance
- 37 -

Relationships Inheritance (cont.)

Multiple inheritance

- 38 -

19

3/27/2013

Package Diagram

- 39 -

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 a system. Package name may be a simple name or a path name.

- 40 -

20

3/27/2013

Packages
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
simple name

package name path name

- 41 -

Packages (cont.)

- 42 -

21

3/27/2013

Packages (cont.)

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

- 43 -

Functional View
Use Case Diagram Activity Diagram

- 44 -

22

3/27/2013

Use Case Diagram

- 45 -

The Use Case Model Overview

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 users 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.

- 46 -

23

3/27/2013

The Use Case Model Resources

The Use Case Model makes use of three different resources to fully describe each requirement: 1. The Use Case Diagram, 2. The Use Case Narrative, and 3. Use Case Scenarios

Use Case Model

Use Case Diagram Use Case Scenarios
- 47 -

Use Case Narrative

The Use Case Model Resources: 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.

- 48 -

24

3/27/2013

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.

- 49 -

The Use Case Model Resources: 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.

- 50 -

25

3/27/2013

The Use Case Model Resources: Use Case Scenarios (cont.)

Consider the following Buy a Product scenario in a typical Web-based online 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

- 51 -

How to Describe a Use Case

1. 2. 3. 4. 5. 6. 7. 8. Name: Give a short, descriptive name to the use case. Actors: List the actors who can perform this use case. Goals: Explain what the actor or actors are trying to achieve. Preconditions: State of the system before the use case. Description: Give a short informal description. Related use cases. Steps: Describe each step using a 2-column format. Post-conditions: State of the system in following completion.

52

26

3/27/2013

Use Case Scenario Example

Buy Items Use Case
Actor Action
1. A customer arrives at the POST with items 2. Cashier records the identifier of each item, and its quantity. 4. On completion, Cashier indicates the end of items to the POST 6. Cashier tells Customer the total 7. Customer gives cash payment 8. Cashier records the sale 10. Cashier deposits the cash , returns balance and gives printed receipt 12. Customer leaves
53

System Response

3. Determine item price, adds item information to running sales transaction 5. Calculates the total

9. Shows balance due 11. Logs completed sale

Alternative Course of Events of Buy Items Use Case

Actor Action
1. A customer arrives at the POST with items 2. Invalid identifier error indicator shows 4. On completion, Cashier indicates the end of items to the POST 6. Cashier tells Customer the total 7. Customer gives cash payment 8. Cashier records the sale 10. Cashier deposits the cash , returns balance and gives printed receipt 12. Customer leaves
54

System Response

3. Determine item price, adds item information to running sales transaction 5. Calculates the total

9. Shows balance due 11. Logs completed sale

27

3/27/2013

Alternative Course of Events of Buy Items Use Case (cont.)

Actor Action
1. A customer arrives at the POST with items 2. Invalid identifier error indicator shows 4. On completion, Cashier indicates the end of items to the POST 6. Cashier tells Customer the total 7. Not have enough cash. Cancel sale. 8. Cashier records the sale 10. Cashier deposits the cash , returns balance and gives printed receipt 12. Customer leaves
55

System Response

3. Determine item price, adds item information to running sales transaction 5. Calculates the total

7a. Resets 9. Shows balance due 11. Logs completed sale

Use Case Diagram Basic Elements

The Use Case diagram consists of six graphic symbols that represent the system: actors, system, Use Cases, associations, dependencies, and generalizations.

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

- 56 -

28

3/27/2013

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

- 57 -

Use Case Diagram Basic 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.

- 58 -

29

3/27/2013

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.

- 59 -

Use Case Diagram Use 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 processes until describing all the internal workings of the system).

- 60 -

30

3/27/2013

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.

- 61 -

Use Case Diagram Relationships: 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.

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

- 62 -

31

3/27/2013

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.

- 63 -

Use Case Diagram Relationships: 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.

- 64 -

32

3/27/2013

Use Case Diagram Relationships: Include (cont.)

- 65 -

Use Case Diagram Relationships: 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.

- 66 -

33

3/27/2013

Use Case Diagram Relationships: Extend (cont.)

- 67 -

Activity Diagram

- 68 -

34

3/27/2013

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
69

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
70

35

3/27/2013

The Activity Diagram (cont.)

An activity diagram shows flow control within a system and models Decisions
Handle Incident Document Incident Archive Incident

[lowPriority] Open Incident [fire & highPriority] [not fire & highPriority] Notify Fire Chief Notify Police Chief Allocate Resources

71

Activity Diagrams: Modeling Concurrency

Synchronization of multiple activities Splitting the flow of control into multiple threads

Splitting
Allocate Resources Open Incident Coordinate Resources Document Incident

Synchronization

Archive Incident

72

36

3/27/2013

Activity Diagrams: Swimlanes

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

Allocate Resources Open Incident Coordinate Resources Document Incident

Dispatcher

Archive Incident FieldOfficer

73

Elements of an Activity Diagram

Course Registration example

Start
Browse Course Catalog Select Course Info

Activity
Enter Personal Data

Guard
Confirm Registration

Branch
[data correct]

End
[else] Send Email Print Bill

Update Course

74

37

3/27/2013

Elements of an Activity Diagram

Course Registration example
Customer Registration System Select Course Info Database System

(cont.)

Billing System

Browse Course Catalog [else]

Swimlane

Enter Personal Data [data correct] Confirm Registration

Fork
Send Email Update Course Print Bill

Join
75

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 easily understood by users and customers. 2. They support modeling parallel behavior. This again makes them 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
76

38

3/27/2013

Dynamic View
Sequence Diagram

State Machine Diagram

- 77 -

Sequence Diagram

- 78 -

39

3/27/2013

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.

- 79 -

Sequence Diagrams Notations

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.

- 80 -

40

3/27/2013

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.

- 81 -

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

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

- 82 -

41

3/27/2013

Sequence Diagrams Basic Types of Actions

Action
Call

Meaning
Invokes an operation on an object; an object may send a message to itself, resulting in the local invocation of an operation Returns a value to the caller Sends a signal to an object Creates an object Destroys an object; an object may commit suicide by destroying itself

Return Send Create Destroy

- 83 -

Sequence Diagrams When 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.

- 84 -

42

3/27/2013

State Machine Diagram

- 85 -

State Machine Models

A State Machine models the behaviour of the system in response to external and internal events. Shows the systems 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.
86

43

3/27/2013

State Machine Diagram

Graphical Representation of object states
on Lamp On on off off Lamp Off
87

Outputs and Actions

As the state changes, output may be generated :
on
Lamp On on/print(on) off Lamp Off off

88

44

3/27/2013

Basic UML Statechart Diagram

top state Initial pseudostate
top

State Trigger

Ready
Transition

stop /ctr := 0
Final state

Done
Action

stop

89

What Kind of Behavior?

In general, state machines are suitable for describing eventdriven, discrete behavior
inappropriate for modeling continuous behavior

threshold

time
90

45

3/27/2013

Object Behavior - General Model

Simple server model:
Initialize Object Wait for Request
void:offHook (); {busy = true; obj.reqDialtone(); };

Handling depends on specific request type

Handle Request

Terminate Object
91

Object Behavior and State Machines

Direct mapping:
on
Initialize Object Wait for Event Handle Event

Lamp On on/print(on) off Lamp Off off

Terminate Object

stop
92

46

3/27/2013

State Entry and Exit Actions

LampOn
entry/lamp.on(); exit/lamp.off();

e2

e1

93

Order of Actions: Simple Case

Exit actions prefix transition actions Entry action postfix transition actions LampOn
entry/lamp.on(); exit/printf(exiting);

off/printf(to off);

LampOff
entry/lamp.off(); exit/printf(exiting);

Resulting action sequence: printf(exiting); printf(to off); lamp.off();

off/printf(needless); printf(exiting); printf(needless); lamp.off();

94

47

3/27/2013

State (Do) Activities

Forks a concurrent thread that executes until:
the action completes or the state is exited through an outgoing transition

do activity Error
entry/printf(error!) do/while (true) alarm.ring();

95

Guards
Conditional execution of transitions

bid [value < 100] /reject Selling

bid [value >= 200] /sell

Happy

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

Unhappy
96

48

3/27/2013

Conditional Branching
Choice pseudostate: guards are evaluated at the instant when the decision point is reached Selling Happy

bid /gain := calculatePotentialGain(value)

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

Unhappy
97

Hierarchical State Machines

States decomposed into state machines
LampOff entry/lamp.off()
off/

flash/

LampFlashing FlashOn entry/lamp.on() 1sec/

on/ LampOn entry/lamp.on()

on/ on/

1sec/ FlashOff entry/lamp.off()

98

49

3/27/2013

Statechart Example
Course Offering The CourseOffering object can be in one of the following states: Initialization (prior to registration, no students added) Open (able to accept students) Closed (max number of students registered for it) Cancelled (no longer offered)

99

Statechart Example
Course Offering

100

50

3/27/2013

Other UML Diagrams

- 101 -

Other UML Diagrams

This module provides a brief overview for the following UML diagrams: Implementation Diagrams o Component Diagram o Deployment Diagram

- 102 -

51

3/27/2013

Implementation Diagrams

- 103 -

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.

- 104 -

52

3/27/2013

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.

- 105 -

Component Diagram Component 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:

ComponentName

UML 2 removed that icon but allows the annotation of a class box with a similar-looking icon. Alternatively, the component keyword can be used in a class box.
<<component>>
ComponentName ComponentName

- 106 -

53

3/27/2013

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.

- 107 -

Component Diagram An Example

- 108 -

54

3/27/2013

Deployment Diagram Definition

Deployment diagrams show a system's physical layout, revealing which pieces 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.

- 109 -

Deployment Diagram Some 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 represented as a line from one node to another. Associations between nodes represent communication paths.

- 110 -

55

3/27/2013

Deployment Diagram An Example

- 111 -

56