modeling using um l
TRANSCRIPT
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?
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 2/56
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.)
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 3/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 4/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 5/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 6/56
3/27/20
- 11 -
Class Diagram
An Example
- 12 -
ClassNotation
Class Name
Attributes
Operations
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 7/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 8/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 9/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 10/56
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).
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 11/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 12/56
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 -
RelationshipsAssociation
Role
The named specific behavior of a classifier participating in an association.
Person Departmentemployee employer
Works for
role name
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 13/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 14/56
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.
Thomas A. Pender. UML Weekend Crash Course™, Wiley Publishing, Inc., 2002
- 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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 15/56
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 -
RelationshipsAssociation
Composition (cont.)
Car
Tire
1
4
composition
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 16/56
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.)
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 17/56
3/27/20
- 33 -
Relationships
Generalization (cont.)
Thomas A. Pender. UML Weekend Crash Course™, Wiley Publishing, Inc., 2002
- 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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 18/56
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).
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 19/56
3/27/20
- 37 -
Relationships
Inheritance (cont.)
Single inheritance
Single inheritance
- 38 -
RelationshipsInheritance (cont.)
Multiple inheritance
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 20/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 21/56
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.)
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 22/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 23/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 24/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 25/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 26/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 27/56
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
System ResponseActor Action
1. A customer arrives at the POST with items
3. Determine item price, adds item information to
running sales transaction
2. Invalid identifier – error indicator shows
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 28/56
3/27/20
55
System ResponseActor Action
1. A customer arrives at the POST with items
3. Determine item price, adds item information to
running sales transaction
2. Invalid identifier – error indicator shows
5. Calculates the total4. On completion, Cashier indicates the end of items
to the POST
6. Cashier tells Customer the total
7a. Resets7. Not have enough cash. Cancel sale.
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
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.
Thomas A. Pender. UML Weekend Crash Course™, Wiley Publishing, Inc., 2002
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 29/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 30/56
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).
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 31/56
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.
Thomas A. Pender. UML Weekend Crash Course™, Wiley Publishing, Inc., 2002
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 32/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 33/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 34/56
3/27/20
- 67 -
Use Case Diagram
Relationships: Extend (cont.)
- 68 -
Activity Diagram
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 35/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 36/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 37/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 38/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 39/56
3/27/20
- 77 -
Dynamic View – Sequence Diagram
– State Machine Diagram
- 78 -
Sequence Diagram
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 40/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 41/56
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 -
Thomas A. Pender. UML Weekend Crash Course™, Wiley Publishing, Inc., 2002
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 42/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 43/56
3/27/20
- 85 -
State Machine Diagram
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 44/56
3/27/20
87
off
on
State Machine Diagram
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”)
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 45/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 46/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 47/56
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”);
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 48/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 49/56
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/
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 50/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 51/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 52/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 53/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 54/56
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
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 55/56
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.
7/28/2019 Modeling Using Um l
http://slidepdf.com/reader/full/modeling-using-um-l 56/56
3/27/20
- 111 -
Deployment Diagram
An Example