UML Diagrams

Presented by
Prianka .R.R
 What is UML?
• Standard language for specifying, visualizing,
constructing, and documenting the artifacts of
software systems, business modeling and other non-
software systems.
• The UML is a very important part of developing
object oriented software and the software
development process.
• The UML uses mostly graphical notations to express
the design of software projects.
 As a Sketch
• Most common use of UML
• Used to help communicate some aspect of a system and to better
understand it
• Used for both forward engineering (i.e., build diagrams before coding) and
reverse engineering (i.e., build diagrams from existing code)
• Strives to be informal and dynamic
• Only emphasizes those classes, attributes, operations, and relationships
that are of interest
• More concerned with selective communication than complete
specification

3
 As a Blueprint
• Goal is completeness
• Is more definitive, while the sketch approach is more explorative
• Used to describe a detailed design for a programmer to follow in
writing source code
• Notation should be sufficiently complete so that a programmer can
follow it in a straightforward manner
• Can be used by a designer to develop blueprint-level models that
show interfaces of subsystems or classes
– Developers then work out the implementation details
• As a reversed engineered product, diagrams convey detailed
information about the source code that is easier for developers to
understand

4
 As a Programming Language
• Specifies the complete system in UML so that code can be
automatically generated
• Looks at UML from a software perspective rather than a conceptual
perspective which concentrates on the domain of study
• Diagrams are compiled directly into executable code so that the UML
becomes the source code
• Challenge is making it more productive to use UML rather than some
another programming language
• Another concern is how to model behavioral logic
– Done with interaction diagrams, state diagrams, and activity diagrams

5
 Overview of UML Diagrams
UML 2.0: 12 diagram types

Structural Behavioral
: element of spec. irrespective of time : behavioral features of a system / business
process

• Class ; Object • Activity

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

• Communication(collaberati
on); Sequence
• Interaction overview
• Timing
 3 basic building blocks of UML - Diagrams
Graphical representation of a set of elements.
Represented by a connected graph: Vertices are things; Arcs are relationships/behaviors.
5 most common views built from
UML 1.x: 9 diagram types. Behavioral Diagrams
Represent the dynamic aspects.
– Use case
– Sequence;
Collaboration
Structural Diagrams – Statechart
Represent the static aspects of a system. – Activity
– Class;
Object
Interction Diagrams
– Component
– Deployment

– Sequence;
Communication
– Interaction Overview
– Timing
7
Class Diagrams

Structural Diagrams

– Class;
Object
– Component
– Deployment
– Composite Structure
– Package
8
 Class Diagram
The basis for all object modeling
All things lead to this

• Most common diagram.

• Shows a set of classes, interfaces, and collaborations and their relationships
(dependency, generalization, association and realization); notes too.
• Represents the static view of a system (With active classes, static process view)

Three modeling perspectives for Class Diagram

 Conceptual: the diagram reflects the domain
 Specification: focus on interfaces of the software (Java supports interfaces)
 Implementation: class (logical database schema) definition to be implemented in
code and database.

Most users of OO methods take an implementation perspective, which is a shame because the
other perspectives are often more useful. -- Martin Fowler
9
 Classes
type/class

Names Account simple name - start w. upper cas

balance: Real = 0 default value
Attributes
<<constructor>>
short noun - start w. lower ca
Operations +addAccount()
may cause object to <<process>> signature
change state
+setBalance( a : Account)
+getBalance(a: Account): Amount
… ellipsis for additional
<<query>> attributes or operations
isValid( loginID : String): Boolean stereotypes to categorize

Bank Customer only the name compartment, ok

Java::awt::Polygon path name = package name ::package name::name

10
 Account
Responsibilities
Responsibilities
-- handles deposits
• anything that a class knows or does -- reports fraud to managers
(Contract or obligation)

• An optional 4th item carried out by attributes and operations.

• Free-form text; one phrase per responsibility.
• Technique - CRC cards (Class-Responsibility-Collaborator); Kent Beck and Ward
Cunningham’89

• A collaborator is also a class which the (current) class interacts with to fulfill a responsibility

Customer Account
Opens account Knows interest rate Manager
Account
Knows name Knows balance
Knows address Handles deposits
Reports fraud to
manager

11
 Scope & Visibility
• Instance Scope — each instance of the classifier holds its own value.
• Class Scope — one value is held for all instances of the classifier (underlined).

Instance scope Frame

class scope header : FrameHeader
uniqueID : Long

+ addMessage( m : Message ) : Status

public # setCheckSum() Public Public Public
- encrypt() class method attribute
protected - getClassName()
Private
private class

Protected
class

• Public - access allowed for any outside classifier (+).

• Protected - access allowed for any descendant of the classifier (#).
• Private - access restricted to the classifier itself (-).
• (using adornments in JBuilder)
12
 Multiplicity

singleton
multiplicity
1
NetworkController
3
consolePort [ 2..* ] : Port ControlRod

Using Design Pattern

public class Singleton {
Singleton private static Singleton instance = null;
- instance private Singleton() {}
public static Singleton getInstance() {
+ getInstance():Singleton if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
NetworkController
consolePort [ 2..* ] : Port
13
 Relationships
Window Event

open()
close() dependency
generalization
association
ConsoleWindow DialogBox Control

generalization
Controller EmbeddedAgent
(multiple inheritance)

<<interface>> association navigation

URLStreamHandler SetTopController
authorizationLevel PowerManager
openConnection()
parseURL() startUp()
shutDown() <<friend>> ChannelIterator
setURL()
toExternalForm() Connect() 14
stereotyped dependency
realization
 Dependency
• A change in one thing may affect another.
• The most common dependency between two classes is one where one class
<<use>>s another as a parameter to an operation.

AudioClip
name
Microphone
record(m:Microphone)
start()
stop()
dependency Using relationship

CourseSchedule

addCourse(c : Course) Course

removeCourse(c : Course

Usually initial class diagrams will not have any significant number of dependencies in the
15
beginning of analysis but will as more details are identified.
 Dependency – Among Classes
AbstractClass {abstract} <<metaclass>> <<interface>>
attribut MetaClassName InterfaceName
e
concreteOperation() operation()
abstractOperation()
<<instanceOf>>
generalization realization
ClassName
-simpleAttribute: Type = Default <<use>>
#classAttribute: Type
+/derivedAttribute: Type
+operation(in arg: Type = Default): ReturnType

<<instanceOf>>

objectName: ClassName ClientClass

Attribute = value
simpleAttribute: Type = Default
classAttribute: Type
/derivedAttribute: Type

16
 Dependency –Among Classes

• Eight Stereotypes of Dependency Among Classes

– bind: the source instantiates the target template using the given actual
parameters
– derive: the source may be computed from the target
– friend: the source is given special visibility into the target
– instanceOf : the source object is an instance of the target classifier
– instantiate: the source creates instances of the target
– powertype: the target is a powertype of the source; a powertype is a
classifier whose objects are all the children of a given parent
– refine: the source is at a finer degree of abstraction than the target
– use: the semantics of the source element depends on the semantics of the
public part of the target

17
 Dependency –Among Use Cases
• Two Stereotypes of Dependency Among Use Cases:
– extend: the target use case extends the behavior of the source
– include: the source use case explicitly incorporates the behavior of another use case
at a location specified by the source
System

Use Case A

Actor
<<include>> <<extend>> Order Processing System
<<actor>>
Place Order
Use Case B Use Case C
Actor <<extend>>
Extension points Request Catalog
Additional requests:
1 * after creation of The sales person
the order asks for the catalog

SalesPerson <<include>> <<include>> <<include>>

Supply Customer Info. Order Item Make Payment

18
Object Diagrams

Structural Diagrams

– Class;

Object
– Component
– Deployment
– Composite Structure
– Package
19
 Instances & Object Diagrams
 “instance” and “object” are largely synonymous; used interchangeably.

 difference:
 instances of a class are called objects or instances; but
 instances of other abstractions (components, nodes, use cases, and associations)
are not called objects but only instances.

What is an instance of an association called?

Object Diagrams
 very useful in debugging process.
– walk through a scenario (e.g., according to use case flows).
– Identify the set of objects that collaborate in that scenario (e.g., from use case
flows).
– Expose these object’s states, attribute values and links among these objects. 20
 Instances & Objects - Visual Representation
anonymous instance
named instance
myCustomer
: Multimedia :: AudioStream
t : Transaction

: keyCode c : Phone
agent :
[WaitingForAnswer]
multiobject orphan instance
(type unknown) instance with current state

r : FrameRenderThread myCustomer
active object
(with a thicker border; owns a id : SSN = “432-89-1738”
thread or process and can initiate
control activity) active = True
instance with attribute values
21
Instances & Objects - Modeling Concrete Instances
• Expose the stereotypes, tagged values, and attributes.
• Show these instances and their relationships in an object diagram.

current: Transaction

primaryAgent <<instanceOf>>
[searching] LoanOfficer

current := retrieve()
: Transaction

Instances & Objects - Modeling Prototypical Instances

• Show these instances and their relationships in an interaction diagram or an activity

diagram. 2.1 : startBilling

1 : create
a: CallingAgent c: Connection
2: enableConnection 22
 Instances & Objects – More Examples

1: sort() c : Company
list()
d: Directory contents: File

s : Department rd : Department
addFile(f:File) 1: addElement(f)
name = “Sales” name = “R&D”
d: Directory contents: File

secureAll() 1*: changeMode(readOnly) uss : Department

d: Directory f: File *
name = “US Sales”

client servers :Server manager

1: aServer := find(criteria) erin : Person
aServer:Server : ContactInfomation
name = “Erin”
2: process(request)
employeeID = 4362 address = “1472 Miller St.”
title = “VP of Sales”
call ::= label [guard] [“*”] [return-val-list “:=“] msg-name “(“ arg-list “)”
23
Component Diagrams

Structural Diagrams

– Class;
Object

– Component
– Deployment
– Composite Structure
– Package
24
Component Diagram UML1.x – implementation view

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

Mapping of Components into Classes Components and their Relationships

loanOfficer.dll component
Registrar.exe

LoanOfficer CreditSearch
Course.dll
Student.dll
LoanPolicy
classes

25
Component Diagram UML2.0 – architectural view

• Short history behind architecture

• Architecture still an emerging discipline
• Challenges, a bumpy road ahead

• UML and architecture evolving in parallel

• Component diagram in need of better
formalization and experimentation

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

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

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

29
 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 30
StudentSchedule DataAccess
Data[1..*]
Component Diagram: UML 1.x and UML 2.0
(http://www.agilemodeling.com/artifacts/componentDiagram.htm)

31
 Component Diagram: UML 1.x and UML 2.0
(http://www.agilemodeling.com/artifacts/componentDiagram.htm)

So, how many different conventions for components in UML2.0? 32

 Building a Component

 simplified the ports to either provide or require a single interface

 relationships between ports and internal classes in three different ways:
i) as stereotyped delegates (flow), as delegates, and as realizes (logical->physical) relationships
33
Cohesive reuse and change of classes; acyclic component dependency ???
 Component Diagram – Connector & Another Example

 a connector: just a link between two or more connectable elements (e.g., ports or
interfaces)
 2 kinds of connectors: assembly and delegation. For “wiring”
 An assembly connector: a binding between a provided interface and a required
interface (or ports) that indicates that one component provides the services required by
another; simple line/ball-and-socket/lollipop-socket notation
 A delegation connector binds a component’s external behavior (as specified at a port)
to an internal realization of that behavior by one of its parts (provide-provide, request-request).

delegation
delegation

assembly store
connector

Left delegation: direction of arrowhead indicates

“provides”
Right delegation: direction of arrowhead indicates
So, what levels of abstractions for connections? 34
“requests”
 Structured Class
 A structured class(ifier) is defined, in whole or in part, in terms of a number of parts -
contained instances owned or referenced by the structured class(ifier).
 With a similar meaning to a composition relation
Any difference?
 A structured classifier’s parts are created within the containing classifier (either when the
structured classifier is created or later) and are destroyed when the containing classifier is
destroyed.
 Like classes and components, combine the descriptive capabilities of structured classifiers
with ports and interfaces

component or
class?

connector

label /roleName : type

Components extend classes with additional features such as

 the ability to own more types of elements than classes can; e.g., packages, constraints,

use cases, and artifacts

 deployment specifications that define the execution parameters of a component
35
deployed to a node
 Classifiers
• Classifier—mechanism that describes structural (e.g. class attributes) and behavioral
(e.g. class operations) features. In general, those modeling elements that can have
instances are called classifiers.
• cf. Packages and generalization relationships do not have instances.
an asynchronous stimulus
communicated between instances
class interface signal
Shape data type <<signal>>
IUnknown OffHook
origin
<<type>>
move() Int
resize() { values range from
display() -2**31 to +2**31 - 1 }
use case

Process loan
egb_server
membership_server
kernel32.dll
<<subsystem>>
Customer Service

component node
subsystem
Generalizable Element, Classifier, Class, Component? 36
Structured Class – Another Example

what kind?

37
Deployment Diagrams

Structural Diagrams

– Class;
Object
– Component

– Deployment
– Composite Structure
– Package

38
 Deployment Diagram

• Shows a set of processing nodes and their relationships.

• Represents the static deployment view of an architecture.
• Nodes typically enclose one or more components.

TCP/IP IIS + PhP Server

TCP/IP

J2EE Membership
Server Server
DecNet

Tomcat
Server

39
 Structural Diagrams - Deployment Diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm)

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

40
 Structural Diagrams - Deployment Diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm)

Is this better?
More concrete
Implementation-oriented

41
 Types of nodes in deployment
• Device Node • Execution Environment
Node(EEN)
- It represent the physical - This is the software
computing device having computing resource
processor and memory. which typically executes
- It is responsible for on device node.
executing software - Following are choices of
system. EEN-
Eg: Bank Server, Computer, Database Engine, Web
mobile phone etc. Browser,WorkFlow
engine, Servlet container,
OS Software
Package Diagrams

Structural Diagrams

– Class;
Object
– Component
– Deployment
– Composite Structure

–Package
43
 Packages
• Package — general-purpose mechanism for organizing elements into groups.
• Nested Elements: Composite relationship (When the whole dies, its parts
die as well, but not necessarily vice versa)
• (C++ namespace; specialization means “derived”)

simple names path names

Client Client
visibility
+ OrderForm +OrderForm -Order enclosing package name
Business rules + TrackingForm package name
- Order Client
+TrackingForm
Sensors::Vision
textual nesting graphical nesting { version = 2.24 }

• Packages that are friends to another may see all the elements of that package,
Visibility no matter what their visibility.
• If an element is visible within a package, it is visible within all packages nested
inside the package. 44
 Dependency –Among Packages
• Two Stereotypes of Dependency Among Packages:
– access: the source package is granted the right to reference the elements of the
target package (:: convention)
– import: a kind of access; the public contents of the target package enter the flat
namespace of the source as if they had been declared in the source

Client
packageName + OrderForm
+ TrackingForm
- Order
<<import>> <<access>>
exports Policies <<import>>

packageName packageName
+OrderRules
-GUI:Window imports
subPackageName PackageClass GUI
<<import>>
+Window
+Form
#EventHandler

45
 Modeling Groups of Elements
• Look for “clumps” of elements that are semantically close to one another.
• Surround “clumps” with a package.
• Identify public elements of each package.
• Identify import dependencies.

Use Case package Diagram

• Included and extending use cases belong in the same
package as the parent/base use case
Java.awt • Cohesive, and goal-oriented packaging
• Actors could be inside or outside each package
utd.administration

registration

Tools.db

db interfaces

Cloudscape Oracle

46
 Class Package Diagrams
(http://www.agilemodeling.com/artifacts/packageDiagram.htm)

• Classes related through inheritance, composition or communication often

belong in the same package
Schedule
<<import>>

Seminar
Registration <<import>> Java
<<application>> Student Contact Infrastructure
Point <<technical>>
<<import>>
<<import>>
Professor <<import>>

• A frame depicts the contents of a package (or components, classes, operations, etc.)
• Heading: rectangle with a cut-off bottom-right corner, [kind] name [parameter]
Package Schedule
1..* 1 A frame encapsulates
Seminar Course a collection of collaborating instances or
refers to another representation of such
1 1..* held at
0..* 1
Location
Enrollment Time 47
 Common Mechanisms

•Adornments
Notes & Compartments
•Extensibility Mechanisms
–Stereotypes - Extension of the UML metaclasses.
–Tagged Values - Extension of the properties of a UML element.
–Constraints - Extension of the semantics of a UML element.

48
 Adornments
• Textual or graphical items added to an element’s basic notation.

• Notes - Graphical symbol for rendering constraints or comments attached to an element

or collection of elements; No Semantic Impact
Rendered as a
rectangle with a dog- See smartCard.doc for See http://www.rational.com
details about this for related info.
eared corner.
May contain combination of
routine. May contain URLs linking to
text and graphics. external documents.

Additional Adornments Transaction

• Placed near the element as named addAction()
– Text compartment
Exceptions
– Graphic Resource Locked
• Special compartments for adornments in
– Classes Client
– Components anonymous bill.exe
– Nodes compartment report.exe
contacts.exe 49
 Stereotypes
• Mechanisms for extending the UML vocabulary.
• Allows for new modeling building blocks or parts.

• Allow controlled extension of metamodel classes.

[UML11_Metamodel_Diagrams.pdf]

• Graphically rendered as «metaclass»

– Name enclosed in guillemets (<< >> ) ModelElement
• <<stereotype>>
– New icon
Internet

• The new building block can have

• its own special properties through a set of tagged values
• its own semantics through constraints
50
 Tagged Values
• a (name, value) pair describes a property of a model element.
• Properties allow the extension of “metamodel” element
attributes.
• modifies the semantics of the element to which it relates.
• Rendered as a text string enclosed in braces { }
• Placed below the name of another element.

<<library>> «subsystem»
Server accounts.dll AccountsPayable
{ dueDate = 12/30/2002
{channels = 3} {customerOnly} status = unpaid }

tagged values 51
 Constraints
• Extension of the semantics of a UML element.
• Allows new or modified rules
• Rendered in braces {}.
– Informally as free-form text, or
– Formally in UML’s Object Constraint Language (OCL):
E.g., {self.wife.gender = female and self.husband.gender = male}

Corporation
Portfolio Department
BankAccount
{or} * *
{secure} {subset}
Person
BankAccount id : {SSN, passport} member 1..* 1 manager
A simple constraint Constraint across multiple elements Person

Person employees employers Compan

0..* 0..* y
age: Integer
Company
self.employees.forAll(Person p | 52
p.age >= 18 and p.age <= 65)
 Appendix
Some Additional Material

53
 Classes: Notation and Semantics

Class - Name

attribute-name-1 : data-type-1 = default-value-1

attribute-name-2 : data-type-2 = default-value-2

operation-name-1 ( argument-list-1) : result-type-1

operation-name-2 ( argument-list-2) : result-type-2

responsibilities

To model the <<semantics>> (meaning) of a class:

 Specify the body of each method (pre-/post-conditions and invariants)
 Specify the state machine for the class
 Specify the collaboration for the class
 Specify the responsibilities (contract) 54
 Attributes
• Syntax
[ visibility ] name [ multiplicity ] [ : type ] [ = initial-value ] [ {property-string } ]
• Visibility
+ public; - private; # protected; {default = +}
• type
– There are several defined in Rational Rose.
– You can define your own. Or you can define your own: e.g. {leaf}
• property-string
Built-in property-strings:
– changeable—no restrictions (default)
– addOnly—values may not be removed or altered, but may be added
– frozen—may not be changed after initialization

origin Name only

+ origin Visibility and name
origin : Point Name and type
head : *Item Name and complex type
name [ 0..1 ] : String Name, multiplicity, and type
origin : Point = { 0, 0 } Name, type, and initial value

id : Integer { frozen } Name and property 55

 Operations
• Syntax
[ visibility ] name [ (parameter-list ) ] [ : return-type ] [ (property-string) ]
• Visibility
+ public; - private; # protected; {default = +}
• parameter-list syntax
[ direction ] name : type [ = default-value ]
• direction
– in—input parameter; may not be modified
– out—output parameter; may be modified
– inout—input parameter; may be modified

• property-string
– leaf
– isQuery—state is not affected
– sequential—not thread safe
– guarded—thread safe (Java synchronized)
– concurrent—typically atomic; safe for multiple flows of control 56
 Template Classes; Primitive Types
• A template class is a parameterized element and defines a family of classes
• In order to use a template class, it has to be instantiated
• Instantiation involves binding formal template parameters to actual ones, resulting in a concrete
class

template parameters
template class
Item
Value
Map Buckets : int

+ bind( in i : Item; in v : Value ) : Boolean

+ isBound( in i : Item ) : Boolean {isQuery}
explicit binding
Uses <<bind>>

Map< Customer, Order, 3 >

<<bind>> ( Customer, Order, 3 )

OrderMap
implicit binding Item Value Buckets

Primitive Types <<enumeration

using a class notation stereotype <<dataType>>
>> Int
false
Boolean
{ value range
true constraint
–2**31 to +2**31-
57
1
 Package Diagrams: Standard Elements

• Façade — only a view on some other package.

• Framework — package consisting mainly of patterns.
• Stub — a package that serves as a proxy for the public
contents of another package.
• Subsystem — a package representing an independent part of
the system being modeled.
• System — a package representing the entire system being
modeled.

Is <<import>> transitive?
Is visibility transitive?
Does <<friend>> apply to all types of visibility: +, -, #?

58
 Dependency –Among Objects

• 3 Stereotypes of Dependency in Interactions among Objects:

– become: the target is the same object as the source but at a later point in
time and with possibly different values, state, or roles
– call: the source operation invokes the target operation
– copy: the target object is an exact, but independent, copy of the source

59
7. UML in the Software Process
 Fitting UML into
Software Requirements Analysis
• A use case diagram helps describe how people interact with the system
• An activity diagram shows the context for use cases and also the details of
how a complicated use case works
• A class diagram drawn from the conceptual perspective is a good way of
building up a rigorous vocabulary of the domain
– It also shows the attributes and operations of interest in domain classes and
the relationships among the classes
• A state diagram shows the various states of a domain class and events that
change that state

61
 Fitting UML into
Software Design

• A class diagram drawn from the software perspective can show design
classes, their attributes and operations, and their relationships with
the domain classes
• A sequence diagram helps to combine use cases in order to see what
happens in the software
• A package diagram shows the large-scale organization of the software
• A state diagram shows the various states of a design object and
events that change that state
• A deployment diagram shows the physical layout of the software

62
 Fitting UML into
Software Documentation

• Complements the written documentation and in some instances can

replace it
• Captures the outcome of the requirements analysis and design
activities in a graphical format
• Supplies a software maintainer with an overall understanding of a
system
• Provides a good logical roadmap of the system layout
• Describes the various states in which a system may exist
• Details complex algorithms in a more understandable form
• Shows how multiple objects collaborate in the system

63
 Activity Diagram

Behavioral Diagrams
Represent the dynamic aspects.
– Use case
– Sequence;
Collaboration
– Statechart

–Activity
 Activity Diagrams
• Model business workflows
• Identify candidate use cases, through the
examination of business workflows
• Identify pre- and post-conditions for use cases
• Model workflows between/within use cases
• Model complex workflows in operations on
objects
• Model in detail complex activities in a high
level activity diagram
 Activity Diagrams
• Activities and Actions
• Transitions and Activity Edges
• Tokens and Activity Nodes
• Control Nodes
– Initial and Final Nodes
– Forks and Joins
– Decision and Merge Points
• States
• Swimlanes
 Activity diagrams
• Useful to specify software or hardware system behaviour
• Based on data flow models – a graphical representation (with
a Directed Graph) of how data move around an information
system

[order reject]

Receive Fill Ship Close

Order Order Order Order
[order
accepted]

Send Accept
Invoice Make Payment
Invoice Payment
67
 Activities
• An activity is the specification of parameterized behaviour as the
coordinated sequencing of subordinate units whose individual
elements are actions
• Uses parameters to receive and provide data to the invoker
Activity
nodes
Parameter Activity Parameter Output
Input name
edges name
parameter Parameter parameter
name

 An action can invoke an activity to describe its action more finely

This action invokes the
activity Fill Order 68
 Activity nodes
• Three type of activity nodes:
– Action nodes: executable activity nodes; the execution of an
action represents some transformations or processes in the
modeled system (already seen)

– Control nodes: coordinate flows in an activity diagram

between other nodes

– Object nodes: indicate an instance of a particular object, may

be available at a particular point in the activity (i.e Pins are
object nodes)

69
 Activity edges (1)
• Are directed connections
• They have a source and a target, along which tokens may flow

• Any number of tokens can pass along the edge, in groups at

one time, or individually at different times
• Weight: determines the minimum number of tokens that
must traverse the edge at the same time

In this example we use a non-constant weight: an invoice for a particular job can
70
only be sent when all of its tasks have been completed
 Control nodes – initial nodes
• In an activity the flow starts in initial nodes, that return the
control immediately along their outgoing edges

• If there are more than one initial node, a control token is

placed in each initial node when the activity is started,
initiating multiple flows
• If an initial node has more than one outgoing edge, only
one of these edges will receive control, because initial
nodes cannot duplicate tokens
A or B ?

71
 Control nodes – decision nodes

• Route the flow to one of the outgoing edges (tokens are

not duplicated)
• Guards are specified on the outgoing edges or with the
stereotype «decisionInput»
• There is also the predefined guard [else], chosen only if
the token is not accepted by all the other edges
• If all the guards fail, the token remains at the source
object node until one of the guards accept it

72
 Control nodes – merge nodes

• Bring together multiple alternate flows

• All controls and data arriving at a merge node
are immediately passed to the outgoing edge
• There is no synchronization of flows or joining
of tokens

73
 Control nodes – fork nodes

• Fork nodes split flows into multiple concurrent flows

(tokens are duplicated)

• State machine forks in UML 1.5 required synchronization

between parallel flows through the state machine RTC step
(it means that the first state in each branch is executed,
then the second one, etc.)
• UML 2.0 activity forks model unrestricted parallelism

74
 Control nodes – join nodes

• Join nodes synchronize multiple flows

• Generally, controls or data must be available on every incoming

edge in order to be passed to the outgoing edge, but user can
specify different conditions under which a join accepts incoming
controls and data using a join specification

75
 Control nodes – final nodes
• Flow final:
– destroys the tokens that arrive into it
– the activity is terminated when all tokens in the graph are
destroyed

• Final node:
– the activity is terminated when the first token arrives

intentional race
between flows

76
 Object nodes
• Hold data temporarily while they wait to move through the graph
• Specify the type of values they can hold (if no type is specified, they
can hold values of any type)
• Can also specify the state of the held objects

• There are four kinds of object nodes:

Central Buffer Data Store

Activity Parameter Nodes Nodes
Nodes Pins
77
(three differents notations)
 Sequence Diagram

Behavioral Diagrams
Represent the dynamic aspects.
– Use case

–Sequence;
Collaboration
– Statechart
– Activity
 Building a Sequence Diagrams
Sequence diagrams capture the use-case
behavior using the foundation of the classes.
Use Case 1
Class C
Class A
Use Case 3
Use Case 2
Class D
Class B

Sequence = Objects + messages

Introduction | Basics | Alternations | Modularity

 Sequence Diagrams
• A simple sequence diagram:
objects
sd Product Buying

Diagram
Name p : Product : ShooppingCart
customer
display()
message
getPrice()

activation addProduct (p)

(focus of
control) checkout ()

Lifeline

Introduction | Basics | Alternations | Modularity

 Object Control
obj1 : Class1 obj2 : Class2
user
operate()
Object Creation

do (…)

create (…)
: Class3
Return Message

foo()
Messages to self
Object
Destruction
Illustration

Introduction | Basics | Alternations | Modularity

 Corresponding Class Diagram

Notice that a dependency

exists whenever messages Dependencies can
are passed between be overridden by
instances of the class associations,
aggregations etc.

Illustration

Introduction | Basics | Alternations | Modularity

 Sequences and Use-Cases
p : Product : ShooppingCart
customer
display()

getPrice()

addProduct (p)

checkout ()
create (…)
: Order

Visible part Hidden part

Introduction | Basics | Alternations | Modularity

 Full Message Attributes
[sequence-expression]
[return-value :=] [message-name] [(argument-list)]

C3.1: res := getLocation (fig)

sequence number
message name argument list
return value

Introduction | Basics | Alternations | Modularity

 Different Kinds of Messages
Synchronous Message

asynchronousMessage

Return Message

Introduction | Basics | Alternations | Modularity

 Synchronous & Asynchronous
Messages
Nested Flow Asynchronous Flow
manager sensor eye sensor manager alarm

check unknown

check ring

operate log

Example Example

Price need to be finished,

before teller can do Ring is executed, while the
another operation control flow is returned to
(getName) err handle and appl

Introduction | Basics | Alternations | Modularity

 Synchronous & Asynchronous
Messages
Nested Flow Asynchronous Flow
manager sensor eye sensor manager alarm

check unknown

check ring

operate log

Example Example

Price need to be finished,

before teller can do Ring is executed, while the
another operation control flow is returned to
(getName) err handle and appl

Introduction | Basics | Alternations | Modularity

 Options
msg : Message : Database Fragment

opt

[msg.status=confirmed]
Condition
archive(msg)

Do something... Used for modeling simple

optional blocks.
Has one operand; no "else"
guard.

Example

Introduction | Basics | Alternations | Modularity

 Alternatives
msg : Message : Database : Admin

alt

[msg.status=confirmed] Alternative Fragment

archive(msg) group
Condition
[msg.status=error]
notify(msg.getID())

[else]
wait()
Execution regions. At most
Else one will execute.
condition
(optional)

Introduction | Basics | Alternations | Modularity

 Loops
: OS : Folder : File

loop

[for each Folder]

Loop Display()
Fragment
loop
[for each File]
Display()
Condition

Nested Loop
Fragment

Introduction | Basics | Alternations | Modularity

 Breaks
: User : User Manager : Policy

isLooged = login(name,pass)

break If the condition is met,

the break fragment is
[¬isLooged]
addBadLogin(name) executed, and the
reminder of the
sequence is ignored
Do something…

Do something …
Handy in model
exception
handling

Introduction | Basics | Alternations | Modularity

MODULARITY

We need ways to create modular scenarios

Introduction | Basics | Alternations | Modularity

 Referencing a diagram
: User : User Manager : Policy

login(name,pass) ref
Login Handling(user,pass) :
bool

Do something… Reference Gate

Do something …

Introduction | Basics | Alternations | Modularity

 BOOK BANK
MODULE: Registering

PRE-FUNCTION:

• Login to the website.

• Collection the required documents to be submitted for registration.

POST-FUNCTION:

• Verification of documents submitted.

• Conformation email sent accessing that authentication can be prevailed for the individual.

MODULE: Display book details

PRE-FUNCTION:
• Analyze the course of semester of logger.

POST-FUNCTION:

• Display the required book details

 BOOK BANK
UML USECASE DIAGRAM
UML CLASS DIAGRAM:
UML SEQUENCE DIAGRAM:
UML COLLABRATION DIAGRAM:
UML STATE CHART DIAGRAM:
UML ACTIVITY DIAGRAM:
UML COMPONENT DIAGRAM:
UML DEPLOYEMENT DIAGRAM:
UML PACKAGE DIAGRAM:
Thank You
