Unit 3

OBJECT ORIENTED
MODELLING AND DESIGN
 Unified Modeling Language
• The main purpose of UML is to
– support communication about the analysis and
design of the system being developed
– support the movement from the problem domain in
the "world" to the solution domain in the machine
• two views of the same system
– one view has diagrams
– source code is another view
• UML
– graphical notation to describe software design
– has rules on how to draw models of
• classes
• associations between classes
• message sends between objects
– has become the de facto industry standard
• Not official, but everyone uses it
– Like a blueprint to show what is going on during
analysis, design and implementation
• Some Projects require UML documentation
The UML is a language for
 visualizing
 specifying
 constructing
 documenting
Models and multiple Views
Behavioral
Structural
behavioral features of a system / business process

element of spec. irrespective of time • Activity

• State machine
• Class • Use case
• Component • Interaction
• Deployment
• Object
Composite structure
•
• Package
Interaction
emphasize object interaction

• Communication
(collaboration)
• Sequence
• Interaction overview
• Timing 5
 Diagram Taxonomy
• Structural Diagrams
 show the static structure of elements in the system.
 depict such things as
• the architectural organization of the system,
• the physical elements of the system,
• its runtime configuration, and
• domain-specific elements of your business,
• structure diagrams include
o Package diagram
o Class diagram
o Component diagram
o Deployment diagram
o Object diagram
o Composite structure diagram
Behavior Diagrams
• we express the dynamic behavioral semantics of a
problem or its implementation
• Behavioral diagrams are-
■ Use case diagram
■ Activity diagram
■ State machine diagram
■ Interaction diagrams
■ Sequence diagram
■ Communication diagram
■ Interaction overview diagram
■ Timing diagram
 Use of diagrams in Practice
• Helps in analysis and design
• Helps in forward and reverse engineering
• Use of CASE tools
• Notations captures architecture and behavior
 Conceptual, Logical and Physical
Models
• Conceptual model captures in terms of domain
and associations
• Logical models determine system architecture
and design
• Physical model describes software and
hardware composition and implementation
 Role of tools
• Larger applications use automated tools
• Tools provide consistency checking, completeness,
constraint checking
• Helps developers to walk through analysis and
design
Outline:
• Introduction.
• Package.
• What is Packageable Element?
• Relationship between Packages.
• Element Import.
• Package Import.
• Package Merge.
• Package Model.
• Use-case package Diagram.
• Class Package Diagram.
• References.
• Question ?????????
Package Diagram:

• A package diagram in the Unified Modeling Language depicts

the dependencies between the packages that make up a
model.
• Package diagram shows the arrangement and organization of
model elements in middle to large scale project.
• Package diagram can also show both structure and
dependencies between sub-systems or modules.
UML Package Symbols:
 UML Package Symbols:
• Access: An element import is defined as a directed
relationship between an importing namespace and a
packageable element.
• Dependency: A dependency is a relationship that signifies that
a single or a set of model elements requires other model
elements for their specification or implementation.
• Import: A package import is defined as a directed relationship
that identifies a package whose members are to be imported
by a namespace.
• Merge: A package merge is a directed relationship between
two packages that indicates that the contents of the two
packages are to be combined.
Package:
• A package is used to group elements, and provides a
namespace for the grouped elements. A package is a
namespace for its members, and may contain other packages.
• Owned members of a package should all be package
elements.
• Package can also be merge with other package, thus provide
the hierarchical organization of the package.
• Different types of elements are allow to have the same name.
• The members of the package may be shown within the
boundaries of the package.
Package:

• The elements that can be referred to within a package using

non-qualified names are: Owned Element, Imported Element,
and elements enclosing namespaces.

• Owned and imported elements may have a visibility that

determines whether they are available outside the package.
Package:

• Package Member are not shown inside the package.

• Package org.hibernate
Package:

• Package org.hibernate contains SessionFactory and Session.

• Package Member are shown inside the package.
Package:

• Members of the package may be shown outside of the

package by branching lines.
• Package org.hibernate contains interfaces Session and
SessionFactory.
Package:

• Packages are useful for simplify this kind of diagrams

• Nested packages.
• Qualifier for Graphics class is Java::Utilities::Graphics
Package:

• Visibility of Owned and Import element.

• "+" for public and "-" for private or helper class.
• All elements of Library Domain package are public except for
Account.
Packageable Element:

• Packageable element is a named element that may be owned

directly by a package.
• Owned member of the package should all be packageable
elements.
• If a package is removed from the model, so are all the
elements owned by the package. Package by itself is
packageable element, so any package could be also a
member of the other packages.
Relationships:
• Dependency
• Generalization
• Refinement
Dependency:
• One Package depends on another package.

Fish depends on water.

Generalizations:

Fish is a kind of Animal.

Refinement:
• Refinement shows different kind of relationship between
packages.
• One Package refines another package, if it contains same
elements but offers more details about those elements.

Performance refines rehearsals.

Element Import:
• The keyword «import» is shown near the dashed arrow if the
visibility is public
• The keyword «access» is shown to indicate private visibility
• Public import of PageInfo element and private import of
SortInfo element from Domain package.
Package Import:

• Package Import (PackageImport) is a directed relationship

between an importing namespace and imported package
• A package import is shown using a dashed arrow with an open
arrowhead from the importing namespace to the imported
package.
• It looks exactly like dependency and usage relationships.
• The visibility of a PackageImport could be either public or
private.
Package Access:

• The keyword «access» is shown to indicate private visibility.

• Public import of PageInfo element and private import of
SortInfo element from Domain package.
• Web Application access Presentation package.
Package Import :

• Private import of Presentation package and public import of

Domain package.
Package Merge:

• A package merge is a directed relationship between two

packages.
• It indicates that content of one package is extended by the
contents of another package.
• Package merge used when elements defined in different
packages have the same name and are intended to represent
the same concept.
• Package merge is shown using a dashed line with an open
arrowhead pointing from the receiving package to the merged
package.
Package Merge :

Rules for Merging Packages:

• Private elements within the package do not merge with the
receiving package.
• UML allows multiple inheritance in package merge.
• Any sub packages within the package are added to the
receiving package.
• If both packages have different packages of the same name, a
merge takes place between those packages.
Package Merge :

• UML packages Constructs and Primitive Types are merged by

UML Kernel package.
Model:

• Model is a package which captures a view of a system.

• View of the system defined by its purpose and abstraction
level.
• Model is notated using the ordinary package symbol (a folder
icon) with a small triangle in the upper right corner of the
large rectangle.
• Business layer model :
Model :

• If contents of the model are shown within the large rectangle,

the triangle may be drawn to the right of the model name in
the tab.
• Service Layer model contains service interfaces and message
types.
Model:

• Model could be notated as a package with the keyword

«model» placed above the name of the model.
• Stereotyped model Layered Service :
Package Relationship:

• A relationship between two packages is called a package

dependency.
• Dependencies are not transitive.
• The dependency relationship between packages is consistent
with the associative relationship between classes.
• Ex. If changing the contents of a package, P2, affects the
contents of another package, P1, we can say that P1 has a
Package Dependency on P2.
Package Relationship:
• Package dependency diagram :
Package Relationship:
• Two types of relationship: Unidirectional and Bidirectional
• Unidirectional Diagram :
Package Relationship:
• Bidirectional Diagram :
Package Relationship:
• Package Coupling—Unidirectional relationships between
packages emphasize lower coupling. While some coupling
must exist, those packages most loosely coupled are more
easily maintained.
• Reuse Impact—Packages with bidirectional dependencies
limit reusability. Those packages exhibiting lower degrees of
coupling on other packages promote reuse.
• Layering—Defining unidirectional dependencies is consistent
with how we would layer a system. Typically, upper-level
layers are dependent on lower-level layers. A package should
reside in, not span across, a layer. As such, packages in lower-
level layers should be less dependent on other packages,
increasing the reusability of those packages.
Examples:
Use Case Package Diagram:

Use case Diagram  Use case Package Diagram

Use Case Package Diagram:
Use Case Package Diagram:
 Class Package Diagram

class Diagram  class Package Diagram

When to use Package Diagram ???
• A large complex project can hundred of classes. Without
some way to organization those classes. It becomes
impossible to make sense of them all.
• Packages create a structure for your classes or other Uml
element by grouping related elements.
Use of Package Diagram:
• When you want to show high level view of the system.
• To keep track of dependencies.
• With the large system to show its major element and how
they relate to one another.
• To divide a complex system into module
• Package diagrams can use packages that represent the
different layers of a software system to illustrate the layered
architecture of a software system.
 Component Diagrams
• Introduction.
• What is component Diagram?
• Relationships Component Diagram
• Example
 The Component Notation
 Shows a set of components and their relationships.
 Represents the static implementation view of a system.
 Components map to one or more classes, interfaces, or collaborations.

Component diagram name

Component Diagram – another example
(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)

54
Component Diagram – another example

55
Component Diagram – another example
(www.cs.tut.fi/tapahtumat/olio2004/richardson.pdf)

56
 Component Diagram UML2.0 – architectural view
Explicit description of interfaces: lollipop
 provided services to other components Component
 requested services from other components
socket
 An interface is a collection of 1..* methods, and 0..* attributes
 Interfaces can consist of synchronous and / or asynchronous operations
 A port (square) is an interaction point between the component and its environment.
 Can be named; Can support uni-directional (either provide or require) or bi-directional (both provide and require)
communication; Can support multiple interfaces.
 possibly concurrent interactions
 fully isolate an object’s internals from its environment

caller or callee?

security AccessControl

StudentAdministration
Student Encription
Incoming
Persistence
signals/calls Outgoing
signals/calls 57
StudentSchedule DataAccess
Data[1..*]
Component Diagram: UML 1.x and UML 2.0

58
The Component Notation
The Component Diagram
Component Interfaces
Component Realization
A Component’s Internal Structure
Component diagram of ATM system
 Deployment Diagram
• Introduction.
• What is Deployment Diagram?
• Relationships Deployment Diagram
• Example
 Deployment Diagram
• show the structure of the run-time system
• capture the hardware that will be used to
implement the system and the links between
different items of hardware.
• Model physical hardware elements and the
communication paths between them
• Plan the architecture of a system
• Document the deployment of software
components or nodes
The Notation
 Structural Diagrams - Deployment Diagram
()

Student administration application

Physical nodes - stereotype device
WebServer - physical device or
software artifact
RMI/message bus: connection type
Nodes can contain other nodes
or software artifacts recursively
 Deployment specs: configuration files:
name and properties

71
Is this better?
More concrete
Implementation-oriented

72
Deployment Diagram of ATM system
 Class Diagrams
• Introduction
• What are classes
• Notation of Classes
• Object Diagram
• Relationships of classes
• Constraints
 A class describes a group of objects with
 similar properties (attributes),
 common behaviour (operations),
 common relationships to other objects,
 and common meaning (“semantics”).
 Examples
 Employee: has a name, employee# and department; an employee is hired, and fired; an
employee works in one or more projects

Employee
name Name (mandatory)
Attributes
(optional) employee#
department
hire()
fire() Operations
assignproject() (optional)
75
 Classes
A class is a description of a set of
objects that share the same attributes,
ClassName operations, relationships, and semantics.

Graphically, a class is rendered as a

attributes rectangle, usually including its name,
attributes, and operations in separate,
designated compartments.
operations

Software Design (UML)

 Class Names

The name of the class is the only required tag in the

ClassName graphical representation of a class. It always appears in
the top-most compartment.

attributes

operations

Software Design (UML)

 Class Attributes

Person

An attribute is a named property of a

name : String class that describes the object being modeled.
address : Address In the class diagram, attributes appear in
birthdate : Date the second compartment just below the
ssn : Id name-compartment.

Software Design (UML)

 Class Attributes (Cont’d)
Attributes are usually listed in the form:

Person attributeName : Type

A derived attribute is one that can be

computed from other attributes, but
name : String doesn’t actually exist. For example,
address : Address a Person’s age can be computed from
birthdate : Date his birth date. A derived attribute is
/ age : Date designated by a preceding ‘/’ as in:
ssn : Id
/ age : Date

Software Design (UML)

 Class Attributes (Cont’d)

Person

Attributes can be:

+ public
+ name : String
# protected
# address : Address
- private
# birthdate : Date
/ derived
/ age : Date
- ssn : Id

Software Design (UML)

 Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id

Operations describe the class behavior

eat and appear in the third compartment.
sleep
work
play

Software Design (UML)

 Attribute
type Name of the class
Attribute
name Student
Other Properties

+ name: string [1] = “Anon” {readOnly}

+ registeredIn: Course [*]
Visibility: Default value
+, -, #
+ register (c: Course) Multiplicity
+ isRegistered (c: Course) : Boolean

Operation
name Return value
Parameters
82
 Object Diagram
 The instances of a class are called objects.
 The relation between an Object and its Class is called “Instantiation”
 Two different objects may have identical attribute values (like two people with
identical name and address)
c:Company

d1:Department d2:Department

name:"Sales" name:"R&D"
link

d3:Department
object
name:"US Sales" attribute value

anonymous object

p:Person :ContactInformation
name:"Erin" address="1472 Miller St."
employeeID=4362
title="VP of Sales"
The name of an object may be written in any of the three following
forms:
■ objectName Object name only
■ :ClassName Object class only
■ objectName :ClassName Object name and class
Object Relationship
 Class diagrams show classes and their relationships
 In UML, there are different types of relationships:
 Association
 Aggregation and Composition
 Generalization
 Dependency

87
 Associations are semantic connections between
classes.
 Ifthere is a link between two objects, there must be an
association between the classes of those objects.
 Links are instances of associations just as objects are
instances of classes.
Association

Link
88
  Associations may optionally have the following properties:
 Association name
 may be prefixed or post fixed with a small black arrowhead to indicate the direction in which the
name should be read;
 should be a verb or verb phrase;
 Role names
 on one or both association ends;
 should be a noun or noun phrase describing the semantics of the role;
 Multiplicity
 The number of objects that can participate in an instantiated relation
 Navigability

Association name navigability role name navigability

* *
multiplicity multiplicity
89
 Ask questions about the associations:
 Can a company exist without any employee?
 If yes, then the association is optional at the Employee end - zero or more (0..*)
 If no, then it is not optional - one or more (1..*)
 If it must have only one employee - exactly one (1)
 What about the other end of the association?
 Can an employee work for more than one company?
 No. So the correct multiplicity is one.

1 0 .. *
Company Employee

 Some examples of specifying multiplicity:

 Optional (0 or 1) 0..1
 Exactly one 1 = 1..1
 Zero or more 0..* =*
 One or more 1..*
 A range of values 2..6

90
91
 Association Relationships (Cont’d)
Associations can also be objects themselves, called link classes or an
association classes.

Registration

modelNumber
serialNumber
warrentyCode

Product Warranty

Software Design (UML)

 Association Relationships (Cont’d)
A class can have a self association.
Company

0..* employer
Job
next
description : string
employee 1..* dateHired : Date
LinkedListNode
salary : Money previous

Person

Software Design (UML)

 Qualified Association Examples:
0..1
Show Ticket
sales
1

perf: Date, 0..1

Show Ticket
seat: Number sales
1

1 1
Bank Account number Person
has

2/14/05 G-94
 Generalization
• Generalization is a relationship between a
more general thing and a more specific thing:

– the more specific thing is consistent in every way

with the more general thing.

– the substitutability principle states that you can

substitute the more specific thing anywhere the
more general thing is expected.
 Generalization/Specialization
• Generalization hierarchies may be created by generalizing from
specific things or by specializing from general things.

Parent
More general element
Superclass
Ancestor
Base Class
{ kind of}

Child
Subclass
Descendant
More specific element
Leaf
 Inheritance
 Class inheritance is implicit in a generalization relationship between
classes.
 Subclasses inherit attributes, associations, & operations from the
superclass

What is the inheritance

mechanism in Java?
 Inheritance

Notes:
 A subclass may override an inherited aspect
 e.g. AdminStaff & CreativeStaff have different methods for calculating bonuses
 A Subclass may add new features
 qualification is a new attribute in CreativeStaff
 Superclasses may be declared {abstract}, meaning they have no instances
 Implies that the subclasses cover all possibilities
 e.g. there are no other staff than AdminStaff and CreativeStaff
Aggregation
 This is the “Has-a” or “Whole/part” relationship

aggregation

Club Member
* *

1 Has 1 Engine
Car Makes
Transmission
1 1

99
 Aggregation
 This is the “Has-a” or “Whole/part” relationship

 Composition
 Strong form of aggregation that implies ownership:
 if the whole is removed from the model, so is the part.
 the whole is responsible for the disposition of its parts
 Note: Parts can be removed from the composite (where allowed) before the composite is
deleted

{ordered} Point centre Circle

Polygon
3..* 1

Note: No sharing - any instance of point can be

part of a polygon or a circle, but not both (Why?)
100
 Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident lifetime of parts by the
whole (i.e., they live and die as a whole). Compositions are denoted by a filled-
diamond adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *

Software Design (UML)

 1 :Engine

composition
:Locomotive 1..*
1 0..1
:Car :Train
0..1 0..1
:Person 0..*
driver 1 passengers
aggregation

102
 Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to Course exists because
Course is used in both the add and remove operations of CourseSchedule.

CourseSchedule

Course

add(c : Course)
remove(c : Course)

Software Design (UML)

 Constraints on attributes
• Conditions that restrict Portfolio Corporation
values, relationships,…
• Can be free text or Object
{secure}
Constraint Langauge (OCL) {or}
(see textbook) BankAccount

• Recommendation: Use
sparingly!
Person
• This example: from UML
gender : {female, male}
User Guide, p. 82
husband 0..1 0..1 wife

{self.wife.gender = female and

self.husband.gender = male}

2/14/05 G-104
 Constraints on links
• Example from UML User
Guide, p. 88 Department
• A dependency and a
constraint used * *
• Shows Manager must be one
of Members of a {subset}
Department
• One link (say, Jane-to-DeptA) member 1..* manager 1
is a subset of all links
between Persons and DeptA Person

2/14/05 G-105
 Class Activity
• Draw the UML class diagram which represents
a ATM system and Ticket Sales
 Example: Ticket Sales

2/14/05 G-108
 Composite structure diagrams
• Introduction
• Syntax
• Example
 Introduction
• UML Composite structure diagrams are used
to explore run-time instances of
interconnected instances collaborating over
communications links.
• Show the internal structure (including parts
and connectors) of a structured classifier or
collaboration.

110
 Syntax of a composite structure
Diagram
• Composite Structure Diagrams show the internal parts of a class.
Parts are named:
partName:partType[multiplicity]
Composite structure Diagram of ATM system
 Interaction Diagrams
• Use case Diagrams
• Sequence Diagrams
• Activity Diagrams
 Interaction Diagrams
• Interaction diagrams model the behavior of use cases by
describing the way groups of objects interact to complete the
task.
When to Use: Interaction Diagrams
• Interaction diagrams are used when you want to model the
behavior of several objects in a use case. They demonstrate
how the objects collaborate for the behavior. Interaction
diagrams do not give a in depth representation of the
behavior.
 Use Case Diagram
• What is a Use Case
• Use Cases Diagram
• Use Case - Relationships
– Generalization
– Association
– Include
– Extends

• Example of Use case

• Benefits of Use Cases
• What is a Use Case
A formal way of representing how a business
system interacts with its environment.
 Illustrates the activities that are performed by
the users of the system.
 A scenario-based technique in the UML
 A sequence of actions a system performs that yields
a valuable result for a particular actor.
 Use Cases Diagram
• Use Case – Actor
• Use Case
Actors
 Actors
• What is an Actor?
– A user or outside system that interacts with the
system being designed in order to obtain some
value from that interaction
• Use Cases describe scenarios that describe the
interaction between users of the system (the actor)
and the system itself.
 Use Case - Actor
• Labelled using a descriptive noun or phrase
• Represented by a stick character.
 Use Case
• Labelled using a descriptive verb-noun phrase
• Represented by an oval

Make
Appointment
 Use Cases Diagram
• Use case diagrams describe what a system
does from the standpoint of an external
observer. The emphasis is on what a system
does rather than how.

• Use case diagrams are closely connected to

scenarios. A scenario is an example of what
happens when someone interacts with the
system.
 Use Case - Relationships

• Relationships
– Represent communication between actor and use
case
– Depicted by line or double-headed arrow line
– Also called association relationship

Make
Appointment
 Use Case - Relationships

• Boundary
– A boundary rectangle is placed around the perimeter
of the system to show how the actors communicate
with the system.

Make
Appointment
The picture below is a Make Appointment use case for the
medical clinic.
The actor is a Patient. The connection between actor and use
case is a communication association (or communication for
short).
 Use-Case Diagram

Use case Example of Appointment system of a hospital

Other Types of Relationships for Use Cases

Generalization
Include
Extend
 Components of Use Case Diagram

• Generalization Relationship
– Represented by a line and a hollow arrow
• From child to parent

Child use case Parent use case

Child use case Parent use case

 Example of Relationships

Use case Example with relationships of Appointment system of a hospital

 Use Case Diagram

• Include Relationship
– Represents the inclusion of the functionality of one
use case within another
– Arrow is drawn from the base use case to the used
use case
– Write << include >> above arrowhead line
 Use Case Diagram

• Extend relationship
– Represents the extension of the use case to
include optional functionality
– Arrow is drawn from the extension use case to the
base use case
– Write << extend >> above arrowhead line
Example of Relationships
Use Case Specification
Use case name: Maintain Storage Tanks
Use case purpose: This use case provides the ability to maintain the fill
levels of the contents of the storage tanks. This use case allows the actor to
maintain specific sets of water and nutrient tanks.
Optimistic flow:
A. Actor examines the levels of the storage tanks’ contents.
B. Actor determines that tanks need to be refilled.
C. Normal hydroponics system operation of storage tanks is suspended by
the actor.
D. Actor selects tanks and sets fill levels.
For each selected tank, steps E through G are performed.
E. If tank is heated, the system disables heaters.
1. Heaters reach safe temperature.
F. The system fills tank.
G. When tank is filled, if tank is heated, the system enables heaters.
1. Tank contents reach operating temperature.
H. Actor resumes normal hydroponics system operation.
Pragmatic flows:
Conditions triggering alternate flow:
Condition 1: There is insufficient material to fill tanks to the levels
specified by the actor.
D1. Alert actor regarding insufficient material available to meet tank
setting. Show amount of material available.
D2. Prompt actor to choose to end maintenance or reset fill levels.
D3. If reset chosen, perform step D.
D4. If end maintenance chosen, perform step H.
D5. Else, perform step D2.
Condition 2: . . .
 Benefits of Use Cases
• Use cases are the primary vehicle for requirements capture.
• Use cases are described using the language of the customer
(language of the domain which is defined in the glossary)
• Use cases provide a contractual delivery process (RUP is Use
Case Driven)
• Use cases provide an easily-understood communication
mechanism
• When requirements are traced, they make it difficult for
requirements to fall through the cracks
• Use cases provide a concise summary of what the system
should do at an abstract (low modification cost) level.
 Sequence Diagram
• Communication Diagram
• Scenarios
• Benefits of scenarios
• Sequence Diagram
• Types of Messages
• Procedural Sequence Models
• Sequence Diagrams with Transient Objects
 Communication diagram
• Communication diagrams used to model the
dynamic behavior of the use case. When
compare to Sequence Diagram, the
Communication Diagram is more focused on
showing the collaboration of objects rather
than the time sequence.
Communication diagram
 Scenarios
• A scenario is a sequence of events that occurs during one
particular execution of a system.
• For example:
John Doe logs in transmits a message from John Doe to the
broker system.
 Benefits of scenarios

• Enable dialogue with non-technical users

• Initial exploration of the domain
 Sequence diagram
• A sequence diagram shows the participants in
an interaction and the sequence of messages
among them.
• A sequence diagram shows the interaction of
a system with its actors to perform all or part
of a use case.
• Each use case requires one or more sequence
diagrams to describe its behavior
 Sequence Diagram - Objects
• A life line illustrates what is happening to an
object in a chronological fashion.

:Name Object

Life line

Activation

146
Sequence Diagram – Time & Messages
• Messages are used to illustrate communication between
different active objects of a sequence diagram.

:Name1 :Name2
Actor
Message One

Message Two

147
 Types of Messages
• Synchronous (flow interrupt until the message has
completed.

• Asynchronous (don’t wait for response)

• Flat – no distinction between sysn/async

• Return – control flow has returned to the caller.

148
Sequence diagram
Procedural Sequence Models
• Sequence Diagrams with Passive Objects
• A passive object is not activated until it has been called.
Sequence Diagrams with Transient Objects
 Timing diagram
• Timing diagram shows the behavior of the
objects in a given period of time.
• Timing diagram is a special form of a sequence
diagram. The differences between timing
diagram and sequence diagram are the axes
are reversed so that the time are increase
from left to right and the lifelines are shown in
separate compartments arranged vertically.
 Timing constraints
 Useful in real-time applications
 useful to specify race condition behaviour
 Two ways to specify (in 1.x)

156
 Activity Diagrams
• Introduction
• Special constructs for activity diagrams
 Introduction
•An activity diagram shows the
sequence of steps that make up a
complex process, such as an
algorithm or workflow.
•Activity diagrams are most useful
during the early stages of designing
algorithms and workflows.
•Activity diagram is like a traditional
flowchart in that it shows the flow of
control from step to step.
Activity Diagram for ATM
card transaction
 Special constructs for activity
diagrams
• Sending and receiving signals
• Swim lanes
• Object flows
 Activity Diagram Basics
• Activity Diagram – a special kind of Statechart diagram, but showing the flow from activity to activity (not
from state to state).
• Activity state –non-atomic execution, ultimately result in some action; a composite made up of other
activity/action states; can be represented by other activity diagrams
• Action state –atomic execution, results in a change in state of the system or the return of a value (i.e.,
calling another operation, sending a signal, creating or destroying an object, or some computation); non-
decomposable
No notational distinction between
initial state action and activity states!
optional
Select site But, activity states can have certain
triggerless transition types of parts
action state do construct()
Commission
architect Entry/ setLock()

Develop plan sequential branch/decision merge (unbranch)

one incoming, several outgoing multiple incoming, one outgoing
Bid plan guard expression (for alternative threads) OR

[not accepted] concurrent fork

[else]
activity state with submachine

Do trade concurrent join AND

Do site work work()
object flow

Finish : CertificateOfOccupancy
final state construction [completed]
0..* 162
 Swimlanes & Object Flow
• A swimlane is a kind of package.
• Every activity belongs to exactly one swimlane, but transitions may cross lanes.
• Object flow – objects connected using a dependency to the activity or transition that
creates, destroys, or modifies them

Customer Sales Stockroom

object flow
swimlane
Request service
Order
[placed] Take order Order
[entered]

Order Fill order

Pay
? [filled]
sub-activity indicator
Deliver order
Order
[delivered]

Collect order
flow final
the process stops at this point for this
part of the activity diagram

What if using pins? 163

 State Diagrams
• Introduction to State Diagrams
• Elements of State Diagrams
• Types of Events
• States and Transitions
• Nested State Diagrams
• Concurrency in state diagrams
 Introduction to State Diagrams
• Interaction diagrams are very good for communication
– between clients and designers
– between designers and other designers
– between designers and implementors
• But they are not part of the constructive core
– Constructive core means that part from which an actual implementation could
be generated
• The constructive core of the UML is
– class diagrams (for the static part)
– state diagrams (for the dynamic part)
• State diagrams can describe very complex dynamic behavior
 Elements of State Diagrams
• The basic elements of state diagrams are
– states – the state in which the object finds itself at any moment
– transitions – take the object from one state to another
– events – cause the transition from one state to another
– actions – take place as a result of a transition
• In the UML, many other extensions have been added,
such as:
– generalization/Inheritance among events (i.e. a mouse click and keyboard
input as subclasses of user interface events)
– hierarchical diagrams for managing complexity (from StateCharts)
– guards – conditions on transitions
• State Diagrams should only be used for objects with significant
dynamic behavior
 Types of Events
• ChangeEvent (i.e.: when(x>y))
– A change event models an event that occurs when an explicit boolean
expression becomes true as a result of a change in value of one or more
attributes or associations.
– A change event is raised implicitly and is not the result of some explicit
change event action.
Eg:

• SignalEvent (i.e.: leftButtonDown)

– A signal event represents the reception of a particular (asynchronous)
signal.
– Eg:
• TimeEvent (i.e.: after(1 second))
– A TimeEvent models the expiration of a specific deadline. Note that the time
of occurrence of a time event instance (i.e., the expiration of the deadline) is
the same as the time of its reception.
– Time event is an event caused by the occurrence of an absolute time or the
elapse of a time interval.
– Eg: when (date = jan 1, 2000 )
after (10 seconds )
 Events accepted in the state:

event action next state

current time = target time + 20s reset alarm normal
button pushed (any button) reset alarm normal
Basic UML State Diagram Syntax
– A state is drawn with a round
box, with three compartments
for Name sometimes
– name left out when
state variables
empty
– state variables (if any)
actions
– actions to be performed
– A transition is drawn with an
arrow, possibly labeled with
– event causing the transaction
– guard condition
– Action to perform AnEvent [guard] / SomeAction
 States and Transitions
transition state

On First up floor
Moving
arrive at Floor Up
first floor

Moving to
An Elevator up floor
First Floor arrive at
floor

arrive at floor
Idle
Moving
Down down floor

time-out
 State chart Diagrams
A State chart diagram shows the lifecycle of an object
• A state is a condition of an object for a particular time
• An event causes a transition from one state to another state
• Here is a State chart for a Phone Line object:
state
initial State

event

transition
 Conditions
• Used as guards on transitions.
– A guarded transition only fires when the condition
is true e.g.
• When you go out in the morning (event),
• If the temperature is below freezing (condition).
• Put on your gloves (next state).
 State Transition Diagram With
Conditions

Traffic light

time-out[cars in N/S right lanes]

North/south may go straight North/south may turn right

time-out time-out[no cars Time-out

in N/S right lanes]
time-out[no cars
in E/W right lanes]

East/west may turn right East/west may go straight

Time out[cars in E/W
right lanes]
 Initial/final States

• The previous example is a continuous loop

• Most situations will have an initial and final state
• Chess game
Concurrency in state diagrams

White's turn checkmate

Start stalemate white wins

White Black
moves moves
stalemate Draw
Black's turn
Checkmate
Black wins
ATM software states at a bank
State diagram example
Nested States
 Concurrency in state diagrams
Concurrency :
•The state model implicitly supports concurrency among objects.
•In general, objects are autonomous entities that can act and state independent of
one another. However objects need not be completely independent and may be
subject to shared constraints that cause some correspondence among their state
changes.
1. Aggregation concurrency
2. concurrency within an object
3. synchronization of concurrent activities
concurrency within an object
synchronization of concurrent activities
UML diagram hierarchy