CS8592-OOAD Lecture Notes Unit-3

CS6502
OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT III - DYNAMIC AND IMPLEMENTATION
UML DIAGRAMS
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.

2
Dynamic Diagrams
• UML interaction diagrams
• System sequence diagram
• Collaboration diagram (Communication
Diagrams)
• State machine diagram
• Activity diagram

Interaction Diagrams
 Illustrates how objects interact via messages
 2 diagram types:
 Sequence Diagram
(fence format)
 Collaboration Diagram
(graph or network)
3

 Class diagrams represent static
modeling.
 What about modeling dynamic behavior?
 Interaction diagrams (Sequence and
communication diagrams) model how
groups of object collaborate to perform some
behavior
Typically captures the behavior of a single
use case
System Sequence Diagrams
4

System Sequence Diagram (SSD)
For a use case scenario, an SSD shows:
 The System (as a black box)
 The external actors that interact with System
 The System events that the actors generate ,
their temporal order.
:System
5

Naming System events & operations
System events and associated system operations
should be expressed at the level of intent.
Rather than physical input medium or UI widget
Start operation names with verb (from use case)
6

Common interaction Diagram Notation
 Classes and Instances:
9

Common interaction Diagram Notation
 Basic Message Expression Syntax:
return := message(parameter : parameterType) : returnType
10

Basic Sequence Diagram Notation
 Links:
 Sequence diagrams do not show links (connection
paths between objects)
11

 Messages – illustrating returns:
12

 Messages to ’self’ or ’this’:
13

 Creation of Instances:
14

 Object lifelines and Object Destruction:
15

 Conditional Messages:
16

 Mutually Exclusive Conditional Messages:
17

 Iteration for a single message:
18

 Iteration of a Series of Messages:
19

 Iteration over a Collection:
20

 Messages to Class Objects
21

Basic Collaboration Diagram Notation
 Links:
a connection path between two objects
22

 Messages:
 Messages to ’self’ or ’this’
23

 Creation of Instances:
24

 Message number sequencing:
25

 Complex sequence numbering:
26

 Conditional Messages:
27

 Mutually Exclusive Conditional Paths:
28

 Iteration or Looping:
29

 Iteration over a Collection:
30

 Messages to a Class Object
31

Sequence Diagrams Collaboration Diagrams
It represents the UML, which is used
to visualize the sequence of calls in a
system that is used to perform a
specific functionality.
It also comes under the UML
representation which is used to
visualize the organization of the
objects and their interaction.
It is used to represent the sequence
of messages that are flowing from
one object to another.
It is used to represent the structural
organization of the system and the
messages that are sent and received.
The sequence diagram is used when
time sequence is main focus.
The collaboration dagram is used
when object organization is main
focus.
The sequence diagrams are better
suited of analysis activities.
The collaboration diagrams are better
suited for depicting simpler
interactions of the smaller number of
objects. 32
Sequence Diagrams vs Collaboration Diagrams

Naming System events & operations
enterItem(itemID, quantity)
scan(itemID, quantity)
: Cashier
worse name
better name
:System
Capture the intent of
the operation while
remaining abstract
33

36
When to use Communication Diagrams?
• Communication / Collaboration diagrams should be
used when you want to look at the behavior of several
objects within a single use case.
• They are good at showing the collaborations between
the objects, they are not so good at precise definition of
the behavior.

37
State machine diagram and Modelling
What is State Machine Diagram?
• A state is an abstraction of the attribute values and links of an object. Sets of values are
grouped together into a state according to properties that affect the gross behavior of the
object.
• State machine diagrams are also called as state chart diagrams. State machine diagrams
are used to capture the behavior of a software system.
• UML State machine diagrams can be used to model the behavior of a class, a subsystem,
a package, or even an entire system.
• Statechart diagrams provide us an efficient way to model the interactions or communication
that occur within the external entities and a system.
• These diagrams are used to model the event-based system.
• A state of an object is controlled with the help of an event.

38
Two types of state machine diagrams
1. Behavioral state machine
• It captures the behavior of an entity present in the system.
• It is used to represent the specific implementation of an element.
• The behavior of a system can be modelled using behavioral state
machine diagrams.
2. Protocol state machine
• These diagrams are used to capture the behavior of a protocol.
• It represents how the state of protocol changes concerning the
event. It also represents corresponding changes in the system.
• They do not represent the specific implementation of an element.

39
Characteristics of State
• State represent the conditions of objects at certain points
in time.
• Objects (or Systems) can be viewed as moving from state
to state.
• A point in the lifecycle of a model element that satisfies
some condition, where some particular action is being
performed or where some event is waited.

40
Three types of states
• Simple state
• They do not have any substrate.
• Composite state
• These types of states can have one or more than one
substrate.
• A composite state with two or more substates is called an
orthogonal state.
• Submachine state
• These states are semantically equal to the composite
states.
• Unlike the composite state, we can reuse the submachine
states.

43
Example - Entry / Exit Action
illustrates a state machine diagram derived from a Class - "BookCopy"

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:
initial State
state
transition
event

State charts in UML:
• Transitions labels have three optional parts:
Event [Guard] / Action
• Find one of each
• Item Received is an event, /get first item is
an action, [Not all items checked] is a guard
• State may also label activities, e.g.,
do/check item
• Actions, associated with transitions, occur
quickly
and aren’t interruptible
• Activities, associated with states, can take
longer and
are interruptible
• Definition of “quickly” depends on the kind of
system,
e.g., real-time vs. info system States in ovals, Transitions as arrows

46
Substates
• A simple state is one which has no substructure. A state
which has substates (nested states) is called a composite
state.
• Substates may be nested to any level.
• A nested state machine may have at most one initial state
and one final state.
• Substates are used to simplify complex flat state machines by
showing that some states are only possible within a particular
context (the enclosing state).

Superstates (nested states)
• Shows a super-state of
three states
• Can draw a single
transition to and from a
super-state

When to develop a state chart?
Model objects that have change state in interesting ways:
• Devices (microwave oven, Ipod)
• Complex user interfaces (e.g., menus)
• Transactions (databases, banks, etc.)
• Stateful sessions (server-side objects)
• Controllers for other objects
• Role mutators

Concurrency in state diagrams
• Dashed line indicates
that an order is in two
different states, e.g.
Checking &
Authorizing
• When order leaves
concurrent states, it’s
in a single state:
Canceled, Delivered
or Rejected

51
Example 1: ATM software states at a bank

52
Example 2: Java thread states

Classes as active state machines
• Consider whether a class should keep track of its own internal state
• Example from Bertrand Meyer: first cut design of LINKED_LIST class
class LINKABLE[T] --linkable cells
feature
value:T;
right: LINKABLE[T]; --next cell
--routines to change_value, change_right
end;
class LINKEDLIST[T]
feature
nb_elements: INTEGER;
first_element: LINKABLE[T];
value(i:INTEGER):T is --value of i-th element; loop until it reaches the ith element
insert(i:INTEGER; val:T); --loop until it reaches ith element, then insert val
delete(i:INTEGER); --loop until it reaches ith element, then delete it
• Problems with first-cut?
• Getting the loops right is tricky (loops are error-prone)
• Redundancy: the same loop logic recurs in all these routines
• Reuse leads to inefficiency: suppose I want a routine search
• Find an element then replace it: I'll do the loop twice!
• Need some way to keep track of the position I found!
• Could return the LINKABLE cell found, but this would ruin encapsulation

Classes as active state machines (cont.)
• Instead, view LINKED_LIST as a machine with an internal state
• Internal state is information stored as attributes of an object
• To represent internal state
• Cursor: current position in the list
• search(item) routine moves the cursor until it finds item
• insert and delete operate on the element pointed at by cursor
• How does this simplify the code of insert, delete, etc.?
• Client has a new view of LINKED_LIST objects:
• l.search(item); --find item in l
• if not offright then delete end; --delete LINKABLE at cursor
• Other routines move cursor: l.back; l.forth

55
State machine vs Flowchart
Statemachine FlowChart
• It represents various states of a
system.
• The Flowchart illustrates the
program execution flow.
• The state machine has a WAIT
concept, i.e., wait for an action or
an event.
• The Flowchart does not deal with
waiting for a concept.
• State machines are used for a
live running system.
• Flowchart visualizes branching
sequences of a system.
• The state machine is a modeling
diagram.
• A flowchart is a sequence flow or
a DFD diagram.
• The state machine can explore
various states of a system.
• Flowchart deal with paths and
control flow.

56
When to use State Diagrams?
• State diagrams are used to implement real-life working
models and object-oriented systems in depth.
• These diagrams are used to compare the dynamic and static
nature of a system by capturing the dynamic behavior of a
system.
• Statechart diagrams are used to capture the changes in
various entities of the system from start to end.
• They are used to analyze how an event can trigger change
within multiple states of a system.

57
Activity diagram
What is an Activity Diagram?
• Activity diagram is defined as a UML diagram that focuses
on the execution and flow of the behavior of a system
instead of implementation.
• It is also called object-oriented flowchart.
• Activity diagrams consist of activities that are made up of
actions which apply to behavioral modeling technology.

58
What is an Activity?
• Activity Diagrams are used to describe activities
• Activity Diagrams are useful for describing complicated methods
• Activity Diagrams are useful for describing use cases, since, after all, a use
case is an interaction, which is a form of activity
• Using Activity Diagrams with Use Cases
• Start with a coarse-grained use case, which is composed of subordinate use
cases
• For the complicated subordinate use cases, use Activity Diagrams rather
than Use Case Diagrams
• Activity Diagrams are like Flow Charts, but Flow Charts are usually limited to
sequential activities while Activity Diagrams can show parallel activities as well

59
Notation Description UML Notation
Activity
Is used to represent a set of actions
Action
A task to be performed
Control Flow
Shows the sequence of execution
Object Flow
Show the flow of an object from one activity (or action) to another activity (or
action).
Initial Node
Portrays the beginning of a set of actions or activities
Activity Final Node
Stop all control flows and object flows in an activity (or action)
Object Node
Represent an object that is connected to a set of Object Flows
Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it.
Activity Diagram Notation

60
Activity Diagram Notation
Notation Description UML Notation
Decision Node (Guards)
Represent a test condition to ensure that the control flow or object flow only
goes down one path
Merge Node
Bring back together different decision paths that were created using a
decision-node.
Fork Node (Synchronization)
Split behavior into a set of parallel or concurrent flows of activities (or
actions)
Join Node (Synchronization)
Bring back together a set of parallel or concurrent flows of activities (or
actions).
Swimlane and Partition
A way to group activities performed by the same actor on an activity diagram
or to group activities in a single thread

61
Activity Diagrams Notation
Start at the top black circle
If condition 1 is TRUE, go right;
if condition 2 is TRUE, go down
At first bar (a synchronization
bar), break apart to follow 2
parallel paths
At second bar, come together to
proceed only when both parallel
activities are done

62
Activity Diagrams – Notation (concluded)
Activity – an oval
Trigger – path exiting an activity
Guard – each trigger has a guard, a
logical expression that evaluates to “true”
or “false”
Synchronization Bar – can break a
trigger into multiple triggers operating in
parallel or can join multiple triggers into
one when all are complete
Decision Diamond – used to describe
nested decisions (the first decision is
indicated by an activity with multiple
triggers coming out of it)

63
Activity Diagrams – Example 1
Business process for
meeting a new client
Non-Swinlane
Activity Diagram

64
Activity Diagrams – Example 2
Business process for
meeting a new client
Swinlane Activity
Diagram

65
Activity Diagram – Example 3
Use Case: Receiving a Supply

66
Use Case: Receiving an Order
and Receiving a Supply

67
Swimlanes - Activity Diagrams that show
activities by class
Arrange activity diagrams into vertical
zones separated by lines
Each zone represents the responsibilities of
a particular class (in this example, a
particular department)

68
Decomposing an Activity
An activity can be decomposed
into a further Activity Diagram
When an Activity Diagram
represents a decomposition of a
higher-level activity, there can be
only one start point

69
When to use activity diagrams?
Activity diagram is used to model business processes and workflows. These
diagrams are used in software modeling as well as business modeling.
Most commonly activity diagrams are used to,
• Model the workflow in a graphical way, which is easily understandable.
• Model the execution flow between various entities of a system.
• Model the detailed information about any function or an algorithm which is used inside the system.
• Model business processes and their workflows.
• Capture the dynamic behavior of a system.
• Generate high-level flowcharts to represent the workflow of any application.
• Model high-level view of an object-oriented or a distributed system.

Implementation Diagrams
• UML package diagram
• When to use package diagrams
• Component and Deployment Diagrams
• When to use Component and Deployment diagrams
70

UML Package Diagrams
What is 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, for example, as multi-
layered (aka multi-tiered) application - multi-layered
application model.
• Package diagram is used to simplify complex class
diagrams, you can group classes into packages. A package
is a collection of logically related UML elements.
71

 UML Package Diagrams:
 Used to illustrate the logical architecture of a
system
 Layers, subsystems, Java packages
 Provides a way to group elements
 Different from (more general than) a Java package
 Can group anything
 Classes, other packages, diagrams, use cases, …
 Nesting packages is very common
UML Package Diagrams
72

Package Diagram
73
Business model in
which the classes are
grouped into packages

Basic Concepts of Package Diagram
• Package diagram follows hierarchal structure of nested
packages.
• Atomic module for nested package are usually class diagrams.
Few constraints while using package diagrams, they are as follows,
• Package name should not be the same for a system, however classes
inside different packages could have the same name.
• Packages can include whole diagrams, name of components alone or no
components at all.
74

Fully qualified Package Diagram
75
Fully qualified name of a package has the following syntax.

UML Package Diagrams Notation
• Package - Package is a namespace used to group together
elements that are semantically related and might change
together.
• Package Template - Package can be used as a template
for other packages.
• Packageable Element - Packageable element is a named
element that may be owned directly by a package.
76

Domain::Sales
UI::Web
UI::Swing
Sales
Web
Swing
UI
Domain
Domain
UI
Swing Sales
Web
UML Package Diagram Notations
77

Package Diagram
78
UI Domain
Swing Web Sales

Package Diagram - Dependency Notation
79

Structure of Import and Access Relationship
80

Example: Package Diagram for Order Processing subsystem
81

Inheritance
• A package with a generalization to another package inherits
public and protected elements that are owned or imported by
the inherited package.
82

Subsystems
• Subsystems are used for system decomposition that can be
represented by the parts of a system.
• Specification / Realization
83

Modeling Complex Grouping
• A package diagram is
often used to describe
the hierarchical
relationships (groupings)
between packages and
other packages or
objects. A package
represents a
namespace.
84

Visibility of Packages
• A public element is visible to elements outside the
package, denoted by ‘+’
• A protected element is visible only to elements within
inheriting packages, denoted by ‘#’
• A private element is not visible at all to elements outside
the package, denoted by ‘-’
85

Domain
UI
Swing
not the Java
Swing libraries, but
our GUI classes
based on Swing
Web
Sales Payments Taxes
Technical Services
Persistence Logging RulesEngine
Higher Layer
Lower Layer
Example
86

 Two key architectural principles
 Separation of concerns
 Maintaining high cohesion
 Separation of concerns:
 Discrete layers of distinct, related responsibilities
 Clean cohesive separation of duties:
 Lower layers: Low-level, general services
 Higher layers: More application-specific services
 Easier to define boundaries for different developers
 Collaboration and coupling from higher to lower layers
Layers: Why?
87

 Limiting dependencies between subsystems:
 Source code changes ripple throughout the
system if many parts are tightly coupled
 Example: If application logic is intertwined with
UI,
 it cannot be distributed to another physical
node
 It cannot be used with a different UI
 General technical services and business logic can
be re-used, replaced or moved to another physical
node
Layers: Why? (continued)
88

UI
(AKA Presentation, View)
Application
(AKA Workflow, Process,
Mediation, App Controller)
Domain
(AKA Business,
Application Logic, Model)
Technical Services
(AKA Technical Infrastructure,
High-level Technical Services)
Foundation
(AKA Core Services, Base Services,
Low-level Technical Services/Infrastructure)
width implies range of applicability
GUI windows
reports
speech interface
HTML, XML, XSLT, JSP, Javascript, ...
handles presentation layer requests
workflow
session state
window/page transitions
consolidation/transformation of disparate
data for presentation
handles application layer requests
implementation of domain rules
domain services (POS, Inventory)
- services may be used by just one
application, but there is also the possibility
of multi-application services
(relatively) high-level technical services
and frameworks
Persistence, Security
low-level technical services, utilities,
and frameworks
data structures, threads, math,
file, DB, and network I/O
more
app
specific
dependency
Business Infrastructure
(AKA Low-level Business Services)
very general low-level business services
used in many business domains
CurrencyConverter
Typical set of layers for information systems
89

 What if the organization of code into packages changes
later on?
 Follow a good package naming convention
 Use CASE tools to reverse-engineer code into UML packages
 What is a tier?
 Originally, it meant a logical layer
 Common usage today: Physical processing node (or cluster of
nodes)
 What is a partition?
 Division into relatively parallel subsystems for a layer.
Some more issues, terms
90

Persistence Security Logging
Technical Services
POS Inventory Tax
Domain
Vertical Layers
Horizontal Partitions
Layers vs. Partitions
91

Domain(s)
Technical
Services
Foundation
MySQL
Inventory
Persistence
Namingand
Directory Services
Web
AppFramework
Technical Services
POS Inventory
Domain(s)
Foundation
Worse
mixes logical anddeployment views
Better
alogical view
alogical representation
of the needfor dataor
services relatedtothese
subdomains, abstracting
implementation
decisionssuch asa
database.
«component»
Novell
LDAP
UMLnotation: AUMLcomponent, or replaceable, modular part of the physical system
UMLnotation: Aphysical databaseintheUML.
Don’t mix physical implementation components
and logical architecture components
92

 Old terminology
 Model: Domain layer (application logic)
 View: UI objects (windows, web pages, reports, …)
 Model-view separation:
 Do not put application logic (such as tax calculation code) in the UI objects
 UI objects should only
 initialize UI elements,
 receive UI events (mouse click, etc.)
 delegate requests for application logic on to non-UI objects
 Do not connect non-UI objects to UI objects
 Example: a Sale object should not have a reference to a JFrame window
object
 Why not?
 What if we want to use the application logic with different windows or
multiple views?
The Model-View Separation Principle
93

 A relaxation of the model-view principle: the
Observer pattern
 Domain objects send messages to UI objects
viewed only in terms of an interface
 Example: PropertyListener interface
 Domain object is aware of existence of object
implementing PropertyListener
 But not of particular object
 Notification happens using interface methods
What if domain objects need to notify the UI?
94

 Domain objects focus on domain processes
 Not on user interfaces
 Domain objects and UI can be developed separately
 Effect of requirements changes in one component to
the other one minimized
 New views (UIs) connected to existing domain layer
 Multiple simultaneous views (e.g. a GUI and a text-
based interface) on the same model object
 Domain layer operable without needing UI layer to be
on
 Basically, modularity.
Motivation for the model-view principle
95

When to use package diagrams?
Package diagram used to create an overview of a large set of
model elements.
• To organize a large model
• To group related elements
• To separate namespaces
96

UML Component and Deployment Diagrams
What is Component diagram?
• UML Component diagrams are used in modeling the physical
aspects of object-oriented systems that are used for
visualizing, specifying, and documenting component-based
systems and also for constructing executable systems through
forward and reverse engineering.
• Component diagrams are essentially class diagrams that focus
on a system's components that often used to model the
static implementation view of a system.
97

Interface
Two type of component interfaces
• Provided interface symbols with a complete circle at their end
represent an interface that the component provides "lollipop" symbol is
shorthand for a realization relationship of an interface classifier.
• Required Interface symbols with only a half circle at their end
represent an interface that the component requires.
Example
99

Subsystems
• The subsystem classifier is a specialized version of a component
classifier. Because of this, the subsystem notation element inherits all
the same rules as the component notation element.
• The only difference is that a subsystem notation element has the
keyword of subsystem instead of component.
100

Port
• Ports are represented using a square along the edge of the system or a
component.
• A port is often used to help expose required and provided interfaces of a
component.
101

Relationships
• A component diagram is a collection of vertices and arcs and commonly
contain components, interfaces and dependency, aggregation,
constraint, generalization, association, and realization relationships.
102
Relationships Notation
Association
Composition
Aggregation
Constraint
Dependency
Links

Component Example - Java Source Code
103

Component Diagram Example - C++ Code with versioning
104

Component Diagram Example - Modeling an Executable Release
105

Component Diagram Example - Modeling a Physical Database
106

UML Component and Deployment Diagrams
What is Deployment diagram?
• A UML deployment diagram is a diagram that shows the
configuration of run time processing nodes and the
components that live on them.
• Deployment diagrams is a kind of structure diagram used in
modeling the physical aspects of an object-oriented system.
• They are often be used to model the static deployment view of a
system (topology of the hardware).
107

Deployment Diagram Notations
• Node
• 3-D box represents a node, either software or hardware
• HW node can be signified with <<stereotype>>
• Connections between nodes are represented with a line, with optional
<<stereotype>>
• Nodes can reside within a node
• Dependency
• Association relationships.
• Notes and constraints.
108

Deployment Diagram Notations
109

Deployment Example - Modeling an Embedded System
110

Deployment Example - Modeling a Client/Server System
111

Deployment Example - TCP/IP Client / Server
112

Deployment Example - Modeling a Distributed System
113

When to use Component and Deployment diagrams?
• 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 middleware, including the operating system and communications approaches
and protocols, will system use?
• What hardware and software will users directly interact with (PCs, network computers,
browsers, etc.)?
• How will you monitor the system once deployed?
• How secure does the system needs to be (needs a firewall, physically secure
hardware, etc.)?
114

References
• Text Book 1 : Craig Larman, Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design
and Iterative Development, Third Edition, Pearson Education, 2005.
• Text Book2 : Ali Bahrami, Object Oriented Systems Development, McGraw Hill International Edition, 1999
• https://www.visual-paradigm.com
• https://www.tutorialspoint.com
• https://medium.com
115

CS8592-OOAD Lecture Notes Unit-3

More Related Content

What's hot (20)

Similar to CS8592-OOAD Lecture Notes Unit-3 (20)

More from Gobinath Subramaniam (20)

Recently uploaded (20)

CS8592-OOAD Lecture Notes Unit-3