UNIT III

DYNAMIC AND IMPLEMENTATION

UML DIAGRAMS
 SYLLABUS
Dynamic Diagrams – UML interaction diagrams -
System sequence diagram – Collaboration
diagram – When to use Communication Diagrams
- State machine diagram and Modelling –When
to use State Diagrams - Activity diagram – When
to use activity diagrams

Implementation Diagrams - UML package

diagram - When to use package diagrams -
Component and Deployment Diagrams – When to
use Component and Deployment diagrams
 UML interaction diagrams
 The UML includes interaction diagrams to
illustrate how objects interact via messages.
 They are used for dynamic object modeling.
There are two common types:
1. Sequence Diagram
2. Communication Diagrams.
 Sequence diagrams
 Sequence diagrams illustrate interactions in a
kind of fence format, in which each new object
is added to the right
 Sequence diagrams
public class A {
private B myB = new B();
public void doOne() {
[Link]();
[Link](); }
// ...
}
 Communication diagrams
Communication diagrams illustrate object
interactions in a graph or network format, in
which objects can be placed anywhere on the
diagram
 Sequence diagrams Vs
Communication diagrams
Type Strengths Weaknesses
clearly shows forced to extend to the
sequence or time right when adding new
ordering of messages objects; consumes
Sequence large set horizontal space
large set of detailed
notation options
space economical—
flexibility to add new more difficult to see
Communication objects in two sequence of messages
dimensions
fewer notation options
Common UML Interaction Diagram
Notation
Lifeline Boxes
Common UML Interaction Diagram
Notation
Message Expression
 Interaction diagrams show messages between
objects.
 Syntax
return = message(parameter : parameterType) :
returnType
Common UML Interaction Diagram
Notation
Singleton Objects
 One instance of a class instantiated
 Such an object is marked with a '1' in the
upper right corner of the lifeline box.
 What are System Sequence
Diagrams?
 Use cases describe how external actors
interact with the software system we are
interested in creating.
 During this interaction an actor
generates system events to a system, usually
requesting some system operation to handle
the event.
 A system sequence diagram is a picture that
shows, for one particular scenario of a use
case, the events that external actors generate,
their order, and inter-system events.
 Basic Sequence Diagram Notation

Lifeline Boxes and Lifelines

 Sequence diagrams the lifeline boxes include
a vertical line extending below them—these
are the actual lifelines.
 Basic Sequence Diagram Notation

Messages
 Message between objects is represented with a
message expression on a filled-arrowed solid
line between the vertical lifelines.

 Basic Sequence Diagram Notation

Messages to “self” or “this”

 Message being sent from an object to itself by
using a nested activation bar.
 Basic Sequence Diagram Notation
Creation of Instances
 Object creation notation is the UML-
mandated dashed line.
The arrow is filled if it's a regular synchronous
message
 The message name create is not required—
anything is legal
The typical interpretation of a create message
on a dashed line with a filled arrow is “invoke
the new operator and call the constructor”.
 Basic Sequence Diagram Notation
Object Destruction
 It is desirable to show explicit destruction of
an object.
 For example, when using C++ which does not
have automatic garbage collection.
 Diagram Frames in UML Sequence
Diagrams
 To support conditional and looping constructs
the UML uses frames.
 Frames are regions or fragments of the
diagrams
 common frame operators:
Frame Meaning
Operator
Alt Alternative fragment for mutual exclusion
conditional logic expressed in the guards.

Loop Loop fragment while guard is true. Can also

write loop(n) to indicate looping n times. There is
discussion that the specification will be enhanced to
define a FOR loop, such as loop(i, 1, 10)
Opt Optional fragment that executes if guard is true.

Par Parallel fragments that execute in parallel.

Region Critical region within which only one thread can run.
 Looping
 Looping Notation
 Conditional Messages
An OPT frame is placed around one or more
messages.
 Notice that the guard is placed over the related
lifeline.
 Mutually Exclusive Conditional
Messages
An ALT frame is placed around the
mutually exclusive alternatives.
 Iteration Over a Collection
 A common algorithm is to iterate over all
members of a collection, sending the same
message to each.
 Two alternatives are shown—reviewed
1. Iteration over a collection using relatively
explicit notation.
2. Iteration over a collection leaving things more
implicit.
 Iteration Over a Collection
1. Iteration over a collection using relatively
explicit notation.
 Iteration Over a Collection
2. Iteration over a collection leaving things more
implicit.
 Nesting of Frames
 Frames can be nested.
Example: NextGen SSD
 What is the Relationship Between
SSDs and Use Cases?
 An SSD shows system events for one
scenario of a use case, therefore it is
generated from inspection of a use case
 Basic Communication Diagram
Notation
Links
 A link is a connection path between two
objects;
 For example, there is a link—or path of
navigation—from a Register to a Sale, along
which messages may flow, such as
the makePayment message.
 Messages
 Each message between objects is represented
with a message expression and small arrow
indicating the direction of the message.
 A sequence number is added to show the
sequential order of messages in the current
thread of control.
 Messages to “self” or “this”
 A message can be sent from an object to
itself
 Creation of Instances
 Any message can be used to create an
instance,
 Three Ways
1. Message named create for this purpose
2. message may be annotated with
a UML stereotype, like so: «create».
3. UML tagged value {new} may optionally be
added to the lifeline box to highlight the
creation.
 Message Number Sequencing
 The numbering scheme is:
1. The first message is not numbered.
Thus, msg1 is unnumbered.
2. The order and nesting of subsequent
messages is shown with a legal numbering
scheme
Sequence numbering.
Complex sequence numbering.
 Conditional Messages
 You show a conditional message by following
a sequence number with a conditional clause
in square brackets
 Iteration or Looping
 If the details of the iteration clause are not
important to the modeler, a simple * can be
used.
UML Activity Diagrams and Modeling

 A UML activity diagram shows sequential

and parallel activities in a process.
 They are useful for modeling business
processes, workflows, data flows, and
complex algorithms.
 Notation
Notation Symbol

Start

Stop

Action

Transition
 Notation
Notation Symbol

Object

Join

Fork

Partition
 Notation
Notation Symbol

Condition

Rake
How to Apply Activity Diagrams?
 A UML activity diagram offers rich notation
to show a sequence of activities, including
parallel activities.
 It may be applied to any perspective or
purpose, but is popular for visualizing
business workflows and processes, and use
cases.
 Business Process Modeling
 Now we take the express parcel shipping
business.
 There are many parties involved (customer,
driver, ...) and many steps.
 This process can be captured in text (in use case
text).
 Activity diagrams are a great example of
pictures being worth a thousand words.
 The partitions are useful to see the multiple
parties and parallel actions involved in the
shipping process, and the object nodes illustrate
what's moving around.
 Data Flow Modeling
 Starting in the 1970s, data flow
diagrams (DFD) became a popular way to
visualize the major steps and data involved in
software system processes.
 DFDs were usually used to show data flows
in a computer system
State Machine Diagrams and Modeling
 UML state diagrams show a dynamic view.
 The UML includes notation to illustrate the
events and states of things—transactions, use
cases, people, and so forth.
 A UML state machine diagram, illustrates the
interesting events and states of an object, and the
behavior of an object in reaction to an event.
 A state machine diagram shows the lifecycle of
an object: what events it experiences, its
transitions, and the states it is in between these
events.
 Notations
 Transitions are shown as arrows, labeled with
their event.
 States are shown in rounded rectangles.
 It is common to include an initial pseudo-
state, which automatically transitions to
another state when the instance is created.
 Definitions: Events, States, and
Transitions
Events
 An event is a significant or noteworthy
occurrence
 For example: A telephone receiver is taken off
the hook.
States
 A state is the condition of an object at a
moment in time—the time between events.
 For example: A telephone is in the state of
being “idle” after the receiver is placed on the
hook and until it is taken off the hook.
 Definitions: Events, States, and
Transitions
transition
 A transition is a relationship between two
states that indicates that when an event
occurs, the object moves from the prior state
to the subsequent state.
 For example: When the event “off hook”
occurs, transition the telephone from the
“idle” to “active” state.
 How to Apply State Machine
Diagrams?
State-Independent and State-Dependent
Objects
State-Independent Objects:
 If an object always responds the same way to
an event, then it is considered state-
independent (or modeless) with respect to that
event.
State-Dependent Objects
 State-dependent objects react differently to
events depending on their state or mode.
 How to Apply State Machine
Diagrams?
Modeling State-dependent Objects
 State machines are applied in two ways:
1. To model the behavior of a complex reactive
object in response to events.
2. To model legal sequences of operations—
protocol or language
 How to Apply State Machine
Diagrams?
COMPLEX REACTIVE OBJECTS
 Physical Devices controlled by software
 Transactions and related Business Objects
 Role Mutators
PROTOCOLS AND LEGAL SEQUENCES
 Communication Protocols
 UI Page/Window Flow or Navigation
 UI Flow Controllers or Sessions
 Use Case System Operations
More UML State Machine Diagram
Notation
Transition Actions and Guards
 A transition can cause an action to fire.
 A transition may also have a conditional
guard—or boolean test.
More UML State Machine Diagram
Notation
Nested States
 A state allows nesting to contain substates; a
substate inherits the transitions of its
superstate (the enclosing state).
Example
Example
 Package Diagram
Introduction
 If some package X is widely depended upon
by the development team, it is undesirable for
X to be very unstable, since it increases the
impact on the team regarding constant version
re-synchronization .
 But sometimes a team does not pay attention
to identifying and stabilizing the most
depended-upon packages and ends up
experiencing more version thrashing
 Package Diagram
 Package diagram, a kind of structural
diagram, shows the arrangement and
organization of model elements in middle to
large scale project.
 Package diagram can show both structure and
dependencies between sub-systems or
modules, showing different views of a
system.
 Package Diagram
Notation
 Package

Package name

 Dependency
Package Organization Guidelines
Package Functionally Cohesive Vertical and
Horizontal Slices
 The basic principle is modularization based
on cohesion functional types.
 Classes and interfaces are grouped together
that are strongly related in terms of their
participation in a common purpose, service,
collaborations, policy, and function.
 For example, all the types in the
NextGen Pricing package are related to
product pricing.
Package Organization Guidelines
Package Functionally Cohesive Vertical and
Horizontal Slices
 In addition to the usually sufficient informal
guesswork on grouping by function (“I think
class SalesLineItem belongs in Sales”).
 Functional grouping is a cluster of types with
strong internal coupling and weaker extra-
cluster coupling.
 For example, Register has a strong coupling
to Sale, which has a strong coupling
to SalesLineItem.
Package Organization Guidelines
Package Functionally Cohesive Vertical and
Horizontal Slices
 Internal package coupling, or relational
cohesion, can be quantified

 NumberOfInternalRelations includes attribute

and parameter relations, inheritance
 Interface implementations between types in
the package.
Package Organization Guidelines
Example
 A package of 6 types with 12 internal
relations has RC=2.
 A package of 6 types with 3 intra-type
relations has RC=0.5.
A very low RC value suggests either:
 The package contains unrelated things and is
not factored well.
 The package contains unrelated things and the
designer deliberately does not care.
Package Organization Guidelines
Guideline: Package a Family of Interfaces
 Place a family of functionally
related interfaces in a separate package—
separate from implementation classes.
 The Java technologies EJB package [Link]
is an example: It is a package of at least
twelve interfaces.
Package Organization Guidelines
Guideline: Package by Work and by Clusters
of Unstable Classes
 Packages are usually the basic unit of
development work and of release.
 It is less common to work on and release just
one class.
 Unless a package is massive or very complex,
a developer is often responsible for all the
types within it.
Package Organization Guidelines
Guideline: Package by Work and by Clusters of
Unstable Classes
 Suppose
1) there is an existing large package P1 with thirty
classes,
2) there is a work trend that a particular subset of ten
classes (C1 through C10) is regularly modified and re-
released.
 In this case, refactor P1 into P1-a and P1-b, where P1-
b contains the ten frequently worked on classes.
 Thus, the package has been refactored into more
stable and less stable subsets, or more generally, into
groups related to work.
Package Organization Guidelines
Guideline: Most Responsible Are Most Stable
 If the most responsible packages are
unstable, there is a greater chance of
widespread change dependency impact.
 As an extreme case, if a widely used utility
package such as [Link] changed
frequently, many things could break.
Package Organization Guidelines
Guideline: Factor out Independent Types
 Organize types that can be used
independently or in different contexts into
separate packages.
Package Organization Guidelines
Guideline: Factor out Independent Types
 Organize types that can be used
independently or in different contexts into
separate packages.
Package Organization Guidelines
Guideline: Use Factories to Reduce
Dependency on Concrete Packages
 One way to increase package stability is to
reduce its dependency on concrete classes in
other packages.
 We can reduce the coupling to this concrete
package by using a factory object that creates
the instances, but whose create methods
return objects declared in terms of interfaces
rather than classes.
 It illustrates the diagram “before” situation.
After factories
Package Organization Guidelines
Guideline: No Cycles in Packages
 If a group of packages have cyclic
dependency, then they may need to be treated
as one larger package in terms of a release
unit.
 This is undesirable because releasing larger
packages increases the likelihood of affecting
something.
Package Organization Guidelines
Guideline: No Cycles in Packages
There are two solutions:
1. Factor out the types participating in the cycle
into a new smaller package.
2. Break the cycle with an interface
Example order system
 When to use package diagram
 Package Diagram can be used to simplify
complex class diagrams, it can group classes
into packages.
 A package is a collection of logically related
UML elements.
 Packages are depicted as file folders and can
be used on any of the UML diagrams.
UML Deployment and Component
Diagrams
 UML Deployment Diagrams
 A deployment diagram shows the assignment
of concrete software artifacts (such as
executable files) to computational nodes
(something with processing services).
 It shows the deployment of software elements
to the physical architecture and the
communication (usually on a network)
between physical elements.
 Deployment diagrams are useful to
communicate the physical or deployment
architecture.
 UML Deployment Diagrams
 The basic element of a deployment diagram is
a node, of two types:
1. device node (or device)—. A physical (e.g.,
digital electronic) computing resource with
processing and memory services to execute
software
 Example
 typical computer
 mobile phone.
 UML Deployment Diagrams
2. execution environment node (EEN)—. This
is a software computing resource that runs
within an outer node (such as a computer) and
which itself provides a service to host and
execute other executable software elements.
Example
 operating system (OS)
 virtual machine
 database engine
 Web browser
 UML Deployment Diagrams
 Important Points
 As the UML specification suggests, many node
types may show stereotypes, such as «server»,
«OS», «database», or «browser», but these are not
official predefined UML stereotypes.
 Device node or EEN may contain another EEN.
 The normal connection between nodes is
a communication path, which may be labeled with
the protocol.
 UML Component Diagrams
 A component represents a modular part of a system
that encapsulates its contents and whose
manifestation is replaceable within its environment.
 A component defines its behavior in terms of
provided and required interfaces.
 As such, a component serves as a type, whose
conformance is defined by these provided and
required interfaces
 UML Component Diagrams
 UML component, the modeling and design intent is
to emphasize
1) that the interfaces are important,
2) it is modular, self-contained and replaceable.
 UML components are a design-level perspective;
they don't exist in the concrete software perspective
 Software component modeling is a home
entertainment system; we expect to be able to easily
replace the DVD player or speakers. They are
modular, self-contained, replaceable, and work via
standard interfaces.
 UML Component Diagrams
 For example, at a large-grained level, a SQL
database engine can be modeled as a component;
When to use Deployment diagram
 What existing systems will the newly added system
need to interact or integrate with?
 How robust does system need to be (e.g., redundant
hardware in case of a system failure)?
 What and who will connect to or interact with
system, and how will they do it
 What hardware and software will users directly
interact with (PCs, network computers, browsers,
etc.)?
 How will you monitor the system once deployed?
When to use Component diagram
 To model the hardware topology of a system.
 To model the embedded system.
 To model the hardware details for a client/server
system.
 To model the hardware details of a distributed
application.
 For Forward and Reverse engineering.