Software architecture, definition

• The architecture of a software system defines the system in

terms of computational components and interactions among
those components.
(from Shaw and Garlan, Software Architecture, Perspectives
on an Emerging Discipline, Prentice-Hall, 1996.)

1 1
 Architecture vs. Design
Architecture: where non-functional decisions are cast, and functional requirements are
partitioned
Design: where functional requirements are accomplished

non-functional architecture
requirements
(“ilities”)

functional
requirements design
(domains)

2
 Goals of Software Architecture
Stakeholder Concerns
• Customer Schedule and budget estimation
feasibility and risk assessment
Requirements traceability
Progress tracking
• User Consistency with requirements and usage
scenarios
Performance, security etc.
• Architect/System Eng. Requirements traceability
Completeness of architecture

3 3
 Software Architecture & Quality
• The notion of quality is central in software architecting: software
architecture is devised to gain insight in the qualities of a system at the
earliest possible stage.

• Some qualities are observable via execution: performance, security,

functionality etc.

• And some are not observable via execution: portability, reusability,

integrability, testability

4 4
 Role of Software Architect
• Excellent software engineering skills
• Lead technical development team by example
• Solve the hard problems
• Understand impact of decisions
• Defend architectural design decisions
• Know and understand relevant technology
• Track technology development

5 5
 Design
• Definition:
– Design is a problem-solving process whose objective is to find
and describe a way:
• To implement the system’s functional requirements while
respecting the constraints imposed by the quality and
budget.”

6
 Design as a series of decisions
• A designer is faced with a series of design issues
– Each issue normally has several alternative solutions:
• design options.
– The designer makes a design decision to resolve each issue.
• This process involves choosing the best option from among the
alternatives.
• Making decisions-To make each design decision, the software
engineer uses:
– Knowledge of
• the requirements
• the design as created so far
• the technology available
• software design principles

7
 Design space
• The space of possible designs that could be achieved by choosing different
sets of alternatives is often called the design space
– For example:

Programmed in
Client/Server Fat Client Java

Programmed in
Visual Basic

Monolithic
Programmed in
Thin Client
C++

8
Layered/Tiered Architecture

9
 Principles Leading to Good Design
• Overall goals of good design:
– Increasing profit by reducing cost and increasing revenue
– Ensuring that we actually conform with the requirements
– Accelerating development
– Increasing qualities such as
• Changeability
• Extensibility
• Reusability

10
 Changeability
• Existing requirements change and new ones are added.
• To reduce maintenance costs and the workload involved in
changing an application, it is important to prepare its
architecture for modification and evolution.
• Two reasons why software ages:
• Lack of movement-software ages if it is not frequently updated.
• Ignorant surgery-changes made by people who do not understand
the original design, gradually destroy the architecture.

11
 Extensibility
• This focuses on the extension of a software system with new features, as
well as the replacement of components with improved versions and the
removal of unwanted or unnecessary features and components.
• To achieve extensibility a software system requires loosely-coupled
components.

12
 Reusability
• It promises a reduction of both cost and development time for
software systems, as well as better software quality.
• Reusability has two major aspects-software development with reuse
and software development for reuse:
• Software development with reuse means reusing existing components
and results from previous projects or commercial libraries or code
components.
• Software development for reuse focuses on producing components that
are potentially reusable in future projects as part of the current
software development.

13
 Design Principle 1: Divide and conquer
• Trying to deal with something big all at once is normally much
harder than dealing with a series of smaller things
– Separate people can work on each part.
– An individual software engineer can specialize.
– Each individual component is smaller, and therefore easier to understand.
– Parts can be replaced or changed without having to replace or extensively
change other parts.

14
 Ways of dividing a software system
– A distributed system is divided up into clients and servers

– A system is divided up into subsystems

– A subsystem can be divided up into one or more packages

– A package is divided up into classes

– A class is divided up into methods

15
 Design Principle 2: Increase cohesion
where possible
• A subsystem or module has high cohesion if it keeps together
things that are related to each other, and keeps out other things
– This makes the system as a whole easier to understand and change
– Type of cohesion:
• Functional, Layer, Communicational, Utility

16
 Functional cohesion
• This is achieved when all the code that computes a particular
result is kept together - and everything else is kept out
– i.e. when a module only performs a single computation, and returns a
result, without having side-effects.
– Benefits to the system:
• Easier to understand
• More reusable
• Easier to replace
– Modules that update a database, create a new file or interact with the
user are not functionally cohesive

17
 Layer cohesion
• All the facilities for providing or accessing a set of related services
are kept together, and everything else is kept out
– The layers should form a hierarchy
• Higher layers can access services of lower layers,
• Lower layers do not access higher layers
– The set of procedures through which a layer provides its services is the
application programming interface (API)
– You can replace a layer without having any impact on the other layers
• You just replicate the API

18
Example of the use of layers

19
 Communicational cohesion
• All the methods that access or manipulate certain data are kept
together (e.g. in the same class) - and everything else is kept out
– A class would have good communicational cohesion
• if all the system’s facilities for storing and manipulating its data are
contained in this class.
– Main advantage: When you need to make changes to the
data, you find all the code in one place
– Example- StudentManager class (insert, update, delete,
search etc.)

20
 Utility cohesion
• When related utilities which cannot be logically placed in other
cohesive units are kept together
– A utility is a procedure or class that has wide applicability to
many different subsystems and is designed to be reusable.
– For example, the java.lang.Math class.

21
 Design Principle 3: Reduce coupling where
possible
• Coupling occurs when there are interdependencies between one
module and another
– When interdependencies exist, changes in one place will
require changes somewhere else.
– A network of interdependencies makes it hard to see at a
glance how some component works.
– Type of coupling:
• Common, Control, Routine Call,

22
 Common coupling
• Occurs whenever you use a global variable
– All the components using the global variable become coupled
to each other
– can be acceptable for creating global variables that represent
system-wide default values
– The best way is declare all the global variables in an interface
and use them through interface
– The Singleton pattern provides encapsulated global access to
an object

23
 Control coupling
• Occurs when one procedure calls another using a ‘flag’ or
‘command’ that explicitly controls what the second procedure
does
– To make a change you have to change both the calling and
called method
– The use of polymorphic operations is normally the best way
to avoid control coupling
– One way to reduce the control coupling could be to have a
look-up table
• commands are then mapped to a method that should be called when
that command is issued

24
 Example of control coupling
public routineX(String command)
{
if (command.equals("drawCircle")
{
drawCircle();
}
else
{
drawRectangle();
}
}

25
 Routine call coupling
• Occurs when one routine (or method in an object
oriented system) calls another
– The routines are coupled because they depend on each
other’s behaviour
– Routine call coupling is always present in any system.
– If you repetitively use a sequence of two or more methods to
compute something
• then you can reduce routine call coupling by writing a single routine
that encapsulates the sequence.
Method foo{
B();
C(); Method foo(){ Method
D(); Bcd(); bcd(){
.. .. B();
B(); Bcd(); C();
C(); D();
D(); } }

}
26
 Design Principle 4: Keep the level of abstraction as
high as possible
• Ensure that your designs allow you to hide or defer consideration
of details, thus reducing complexity
– A good abstraction is said to provide information hiding
– Abstractions allow you to understand the essence of a
subsystem without having to know unnecessary details

27
 Abstraction and classes
• Classes are data abstractions that contain procedural
abstractions
– Abstraction is increased by defining all variables as private.
– The fewer public methods in a class, the better the
abstraction
– abstract classes and interfaces increase the level of
abstraction

28
 Design Principle 5: Increase reusability where
possible
• Design the various aspects of your system so that they can be
used again in other contexts
– Generalize your design as much as possible

29
 Design Principle 6: Reuse existing designs and code
where possible
• Design with reuse is complementary to design for reusability
– Actively reusing designs or code allows you to take advantage
of the investment you or others have made in reusable
components.

30
 Design Principle 7: Design for flexibility
• Actively anticipate changes that a design may have to undergo in
the future, and prepare for them
– Reduce coupling and increase cohesion
– Create abstractions
– Do not hard-code anything
– Use reusable code and make code reusable

31
 Design Principle 8: Anticipate obsolescence
• Plan for changes in the technology or environment so the
software will continue to run or can be easily changed
– Avoid using early releases of technology
– Avoid using software libraries that are specific to particular
environments
– Use standard languages and technologies that are supported
by multiple vendors

32
 Design Principle 9: Design for Portability
• Have the software run on as many platforms as possible
– Avoid the use of facilities that are specific to one particular
environment
– E.g. a library only available in Microsoft Windows

33
 Design Principle 10: Design for Testability
• Take steps to make testing easier
– Design a program to automatically test the software
• Ensure that all the functionality of the code can be driven by an
external program, bypassing a graphical user interface
– In Java, you can create a main() method in each class in order
to exercise the other methods

34
 Design Principle 11: Design defensively
• Never trust how others will try to use a component you are
designing
– Handle all cases where other code might attempt to use your
component inappropriately means check that all of the inputs
to your component are valid: the preconditions
– Validate the user input before using in your program

35
Thank You
 Unified Modeling Language
(UML)

Lecture-2

Lecture By:
Alemayehu Shemebo (M.Sc.in CSE)
Department of Software Engineering
College of Engineering and Technology
Wachemo University
1
 Engineering and Blueprints
• Standard Notation: Symbol for
representation
• Communication tool: aim is to enhance
communication among stakeholders

2
Important Terminologies for Software
Engineers
Me

G
ui
tho

de
Ph do

l
in
ilo lo

es
so gy
Mo ph
del y
s
Too
l Su Nota
ppo tion
rt s
Proce
ss

3
 History
• CASE Tools: Automation of Software Development
• People-to-People communication (very important for
requirements gathering/elicitation)
• People-to-Computer: Engineers use CASE tools
• Rational Software (An IBM Company)
• Rational Rose / MS Visio:
Embedding UML-Diagrams-to-Programs

• OMG: Object Management Group (early effort to

4
standardization)
 History

• Booch: Booch Method

• Rumbaugh: OMT (Object Modeling
Tech.)
• Jacobson: OOSE (OO Software Eng.)
• Three Amigos: UML

5
 History

• UML: An Open Standard controlled by OMG

• UML 1.0 (1997)
• UML 2.0 (2004)

6
 Unified Modeling Language
§ The Unified Modeling Language(UML) unifies the
notations of Booch, Rumbaugh (OMT) and
Jacobson (OOSE)
§ Notation is the graphical stuff in the different
types of models, it is the syntax of the modeling
language
§ The UML is approved as a standard by the
OMG and has become widely accepted in the
IT industry
§ The UML is a modeling language, not a
software development process; it intends to 7
 Meta-Model

• A diagram that defines the notation to

be used in the modeling language

8
 UML Supported Diagrams
• Class • Use Case
• Object • Interaction
» component – Communication
• Package – Sequence
• Deployment – Collaboration
– Timing
• Activity
• State/State chart

9
 Brief Overview
• Class - set of classes, interfaces,
collaboration, relationships
• Object - set of objects and their
relationships
• Use case - description of functionality
provided by system along with actors
and their connection to the use case

10
 Overview (cont.)
• Interaction - set of objects and their
relationships including messages
• State/state chart - a state machine
showing states, transitions, events, and
activities
• Activity - state chart sequential flow of
activities
• Component - physical structure of code in
terms of code components
11
 Overview (cont.)
• Deployment - physical architecture of
hardware and software in the system
• Package - shows packages of classes
and dependencies among them
– grouping mechanism
– form of class diagram
– also called subsystem

12
Organization of Diagrams
Domain Expert System Designer
• Use Case • Class
• Activity • Component
• Interaction • Deployment
• State
• Package

13
 Another Organization
Static Dynamic
• Class • Use Case
• Component • Interaction
• Package • State
• Deployment • Sequence
• Activity

14
Another Organization

15
Another Broad Organization

16
 Structural UML Diagrams
• Structural UML diagrams represent the static aspects of a system.
• These static aspects represent those parts of a diagram which
forms the main structure and is therefore stable.
• These static parts are represented by classes, interfaces, objects,
components and nodes.
• UML has the following Structural Diagrams

17
 Behavioral UML Diagrams
• Behavioral diagrams basically capture the dynamic aspect of a
system.
• Dynamic aspects are basically the changing/moving parts of a system.
• UML has the following types of behavioral diagrams

18
Mapping UML Diagrams to Architectural 4+1
Views

19
 Model Terminology
• User Model View - Problem and
solution from the perspective of the
users
• Structural Model View - static or
structural aspects of a problem and
solution
• Behavioral Model View - dynamic or
behavioral aspects; interactions or
collaborations among problem and 20
 Model Terminology
• Implementation Model View -
structural and behavioral aspects of the
solution’s realization
• Environment Model View - structural
and behavioral aspects of the domain in
which a solution must be realized

21
 Language Versus Method

• A (software engineering) method is composed of a

language and a process.

• UML is a language, not a method, since it has no

notion of process

• Process can have a model and it is called Process

Models

22
 Software Development Process Models :
Overview

• Waterfall
• Iterative Across Life Cycle Phases
• Spiral
• RUP

23
Examples of Process Model: Waterfall Model

24
Iteration Across Life Cycle Phases

25
Spiral Model of Software Development

26
The Unified Process Life Cycle Model (Object Oriented)

27
 Terminology
• Inception - a few days’ work to decide if a
few months of elaboration is worth it
• Elaboration - risk assessment, about 1/5
of project time; includes planning based
on use cases; generates a commitment
schedule
• Construction - composed of iterations that
include refactoring, frameworks &
patterns
• Transition - testing, Make to Work 28
 Refactoring
The process of changing the internal
structure of a program or system to
make it easier to understand or change
while maintaining its functionality.

29
 Frameworks & Patterns
• Frameworks are reusable designs of all
or part of a software system described
by a set of abstract classes and the way
instances of those classes collaborate
• Patterns are common designs that
have repeating themes
• Design Patterns
• Architectural Patterns
30
 Class Diagram
• Static View of a system in terms of
classes and relationships among the
classes
– associations
– subtypes
• Typically done in parallel with interaction
diagrams
• a more graphical alternative to CRC
cards 31
 Common Uses
• Objective: provide a view of services
the system should provide to its end
user
• Model the vocabulary of a system
• Model simple collaborations
• Model a logical database schema

32
 Terminology
• Association: a description of a related
set of links between objects of two
classes
• Subtype: “is a” or “is a kind of”
• Generalization: relationship between a
more general and a more specific
element - see subtype

33
 Terminology (cont.)

• Dependency: relationship where a

change in the independent element
affects the dependent element
• Refinement: relationship between two
descriptions of the same thing, but at
different levels of abstraction

34
 Terminology (cont.)
• Aggregation: association specifying a whole-
part relationship between the aggregate
(whole) and a component (part).
• An aggregation may not have any
components and a component may not
belong to any aggregation.
• Composition: special form of aggregation (a
component must belong to a composition and
only to one composition)
– strong ownership
– coincident lifetime of parts and whole

35
Notation

36
More Notation

37
Aggregation/Composition

38
Example

39
 Levels of Abstraction
• Conceptual Model: class name
– associations are conceptual relationships

• Specification model: above + behavior

– associations and responsibilities

• Implementation model: above + state

– probably too low-level for design stage

40
 Conceptual: Aggregation, Generalization

Project

*
Activity

is produced by * consumes

WorkProduct * Task * Resources

System Participant

Model Time

Document Equipment

41
 Associations
• Describe relations between classes
• Associations have roles (given at the
end of the association) which have
multiplicities
• Associations have navigability
– A sends a message to B
– A creates an instance of B
– A needs to maintain a connection with B
• Navigability is identified from
collaboration diagrams 42
 Associations (cont.)

• Navigability in one direction is termed

uni-directional association and has an
arrow
• Two-way navigability is bi-directional
association and has no arrow
• An association with no arrow could also
mean that the direction is unknown
• bidirectional requires inverse
relationship 43
 Operation Signatures
+ public
# protected
- private

44
 Operations & Methods
• Operation
– something invoked on an object which in
turn is implemented by a method
• Method (in coding not design method)
– body of the procedure
• Polymorphism forces a distinction
between the two (all siblings have the
same operation but different methods)

45
 Steps to create a Class
Diagram
• Identify classes using the interaction
diagram and place them in the class
diagram
• get attributes from the conceptual
model and the method names from the
interaction diagram
• add type information and associations
based on attribute visibility
• add navigability arrows and
dependencies 46
Another Example

47
 Cautions
• Start small
• Perspective should match activity
– analysis: conceptual model
– software: specification model
• don’t go to details too early

48
 Dependency Relationship
• One element (of any kind, including
classes, use cases, etc.) has knowledge
of another element
• if one element changes, the other might
have to change as well
• differs from plain attribute visibility
which uses regular association line
and a navigability arrow
49
 Interface
• Interface is a class of abstract/pure
virtual functions.
• All functions in the interface are public.
• Interface cannot be used to
instantiate objects.
• There is no data members in an
interface class.
• UML: use <<interface>> to prefix the
class name.
50
 Abstract Class
• An abstract class has one or more
abstract/pure virtual functions.
• An abstract class cannot be used to
instantiate objects.
• An abstract class can contain data
members.
• UML: use abstract to prefix the class
name.

51
 Use Case Diagram
• For capturing the functional requirements of a
system.
• Typical interaction between user and system
– captures some user-visible function
– achieves a discrete goal for the user
note the distinction between the user goal and
system interaction in which system interaction
is the low-level work that ultimately achieves
the user goal
52
Notation

53
An Example (Use Case)

54
Another Example (UML 1.1)

55
 Common Uses
• To model the context of a system
– system, actors, and their interactions with it

• To model the requirements of a system

– what system should do
– independent of how it is done
– point of view outside of system

56
 Caution
• It is easy to get too low-level

A use case is a relatively large end-to-

end process description that typically
includes many steps or transactions; it
is not normally an individual step or
activity in a process.

57
 Steps
• Capture normal case first
• For every step, ask:
“What can go wrong”
“How might this work differently”
• Each variation is plotted as an
extension
• Common behavior can be encapsulated
in another use case to be used by other
cases 58
 Steps (cont.)
• After creating the diagram, write a
generic scenario (called a use case
description) which is a series of
sentences describing each step in the
interaction
• Each step in a use case is an element
of the interaction between an actor and
the system.
• Use case description can be used to
generate specific scenarios and 59
 Scenario

• A thread through a use case

• A sequence of steps describing an
interaction between a user and a
system.
• A use case is a set of scenarios tied
together by a common user goal.

60
 Assignment 2: To be
submitted
Attempt the following Questions for an ATM System:
The hypothetical ATM System description is given in
the next slide

Q#1. Identify potential Actors from the system description

Q#2 Identify potential Use Cases from the ATM system’s
description
Q#3. Draw a Use Case for the ATM system
Q#4. Identify Boundary objects Show
Q#5. the use case sequences of ATM system using Activity
Diagram
Q#6 Draw a sequence diagram to show the time based
collaboration among objects
Q#7 Think of any exceptional behavior handling mechanisms,
which were not included in the ATM system description
61
 Hypothetical ATM System Description
• In the Automatic Teller Machine (ATM) System, the ATM operator starts up the ATM
machine using the operator panel. Then the ATM becomes idle in its state until the
customer arrives for service. Each customer of the ATM has their own ATM card. The
ATM machine asks the users on the information screen to insert his/her ATM card. The
user inserts ATM card into the ATM machine through the card slot.
• Once the ATM system recognizes the ATM card, validating with the customer detail in
the account database; it asks the user to insert their Personal Identification Number
(PIN), otherwise the system displays the message invalid user. But if the customer
enters wrong PIN, the system requests the customer to reenter his/her PIN again for at
most three times after which it retain/confiscate the ATM card of particular customer. For
releasing the retained ATM card, customers should report to the systems Administrator
to fix the problem.
• If the PIN is accepted the system creates a session for the customer. During the active
session, the customer can make transaction type through menu like withdraw, deposit,
transfer and make balance inquiry. For every type of transaction, the system checks the
bank’s account and make necessary update for the transaction that individual
customers performs.
• The operator shutdown the ATM system when it is needed using the operator panel.
ATM has interfaces like receipt printer for printing the receipt for transaction, card slot to
allow user to enter ATM card, money dispenser to withdraw money, number pad to enter
amount of transaction and PIN, user screen to display messages from the ATM. 62
 Assignment 3: For
Presentation
• Client/Server Software Architecture (G-
1)
• Service-Oriented Architecture (G-2)
• Component-Based Software
Architecture (G-3)
• Real-Time Architecture (G-4)

63
 Overview of Software Modeling and Design
Method

Lecture Three

5/29/2025 1
Lecture Outline
vKey SW design concepts for designing Software
Architecture
vObject Oriented Concepts: Objects and Classes
vRole of Information Hiding and Inheritance
vThe Concurrent Processing Concept
vSW Design Patterns, Architecture and Component based
system
vThe concept of Software quality attributes
vCOMET life cycle with other SW development process

5/29/2025 2
Software Design and Architecture
Concepts
vThe term object-oriented was first introduced in
connection to OO programming

v Information hiding as a way to design modules.

v Then Classes and inheritance were introduced to ensure
reusability.

v But they start gaining widespread acceptance with the

introduction of Smalltalk.

vSince then, OO concepts are considered

important in software development b/c they
address fundamental issues of adaptation and
evolution.
5/29/2025 3
 Software Design and Architecture
Concepts
vObject-oriented applications consist of objects.

v Object can be physical or conceptual

v Object groups both data and procedures
v The procedures are usually called operations or
methods.
v Some approaches, refer to the operation as the
specification of a function performed by an object and
the method as the implementation of the function.

vIn this class, the term operation refers to both the

specification and the implementation.

5/29/2025 4
Software Design and Architecture
Concepts
vThe signature of an operation specifies the
operation’s name, parameters, and return value.

vAn object’s interface is the set of operations it

provides, as defined by the signatures of the
operations.

v An object’s type is defined by its interface.

v An object’s implementation is defined by its class.
v An object is an instance of a class.

5/29/2025 5
Software Design and Architecture
Concepts
vInformation hiding is a fundamental software
design concept relevant to the design of all
software.

v Early systems were error-prone and difficult to modify

because of the widespread of global data.

v Parnas advocated information hiding as a criterion for

decomposing a software system into modules.

v Each information hiding module should hide a design

decision that is considered likely to change.

v Each changeable decision is called the secret of the

module.
5/29/2025 6
Software Design and Architecture
Concepts
vWith information hiding, the information that could
potentially change is encapsulated (i.e., hidden)
inside an object.

vThe information can be externally accessed only

indirectly by the invocation of operations.

vThus, the hidden information and the operations

that access it are bound together to form an
information hiding object.

5/29/2025 7
Software Design and Architecture
Concepts
vImportant data structures can be accessed by
several objects.
vWithout information hiding, any change to the
data structure is likely to require changes to all the
objects (lack of resilience).

vInformation hiding can be used to hide the design

decision concerning the data structure, its internal
linkage, and the details of the operations.

vThe information hiding solution is to encapsulate

the data structure in an object.

5/29/2025 8
Software Design and Architecture
Concepts
vOther objects may only indirectly access the
encapsulated data structure by calling the
operations of the object.

v If the data structure changes, the only object affected

is the one containing the data structure

v The external interface supported by the object does

not change; hence, the objects that indirectly access
the data structure are not affected by the change.

v This form of information hiding is called data

abstraction.
5/29/2025 9
Software Design and Architecture
Concepts
vThe design of an object (or class) is two-step
process:

v First to design the interface, which is external view

v Then design the internals

v The first is part of high-level design

v The second step is part of the detailed design

v This is an iterative process to decide what should be externally visible and

what should not.

5/29/2025 10
Software Design and Architecture
Concepts
vInheritance is a mechanism for sharing and
reusing code between classes.

v A child class inherits the properties of a parent class

v The parent class is referred to as a super class(parent)
or base class(child).
v The child class is referred to as a subclass or derived
class
v The child adapts the operations by adding new
operations or by redefining existing operations.
v It is also possible for a child class to suppress an operation
of the parent; though, such suppression is not
recommended.
5/29/2025 11
 Software Design and Architecture
Concepts
vA sequential application is a sequential program that
consists of passive objects and has only one thread
of control.

v Only synchronous message communication (procedure call

or method invocation) is supported.

vIn a concurrent application, there are typically

several concurrent objects, each with its own thread
of control.

v Asynchronous message communication is supported

5/29/2025 12
Software Design and Architecture
Concepts
vConcurrent objects are also referred to as active
objects, concurrent processes, concurrent tasks,
or threads.
vThe following three problems commonly arise
when concurrent objects cooperate with each
other:

v Mutual exclusion problem (exclusive access to

resourses)
v Synchronization problem (operation synchronization)
v Producer/consumer problem (to pass data)
vCommunication between concurrent objects is
often referred to as inter-process communication
(IPC).
5/29/2025 13
Software Design and Architecture
Concepts
vEvent synchronization is used when two tasks
need to synchronize their operations without
communicating data between the tasks.

v The source task executes a signal (event) operation,

which signals that an event has taken place.
v Event synchronization is asynchronous

v The destination task executes a wait (event) operation,

which suspends the task until the source task has
signaled the event.

v If the event has already been signaled, the destination

task is not suspended.

5/29/2025 14
Software Design and Architecture Concepts

Example of synchronization between concurrent objects

5/29/2025 15
Software Design and Architecture
Concepts

5/29/2025 16
Software Design and Architecture
Concepts

5/29/2025 17
Software Design and Architecture
Concepts
vA common problem in concurrent systems is that of
producer and consumer concurrent objects.

v The producer concurrent object produces information, which

is then consumed by the consumer concurrent object.

v Necessary for the concurrent objects to synchronize their

operations when they wish to exchange data

v The producer must produce the data before the consumer

can consume it.
v The consumer must wait for the producer

v Producer has to be held up or the data needs to be buffered for

the consumer

5/29/2025 18
Software Design and Architecture
Concepts
vA common solution to this problem is to use
message communication between the producer
and consumer concurrent objects.

vMessage communication between concurrent

objects serves two purposes:

v Transfer of data from a producer concurrent object to a

consumer concurrent object.
v Synchronization between producer and consumer

vMessage communication between concurrent

objects may be asynchronous or synchronous

5/29/2025 19
Software Design and Architecture
Concepts
vIn asynchronous message communication the
producer sends a message to the consumer and
either does not need a response or has other
functions to perform before receiving a response.

v Thus, the producer sends a message and continues

without waiting for a response.

v The consumer receives the message.

v A first-in-first-out (FIFO) message queue can build up

between producer and consumer.

v If there is no message available when the consumer

requests one, the consumer is suspended.
5/29/2025 20
Software Design and Architecture
Concepts

Asynchronous message communication

5/29/2025 21
Software Design and Architecture
Concepts
vIn the case of synchronous message
communication with reply, the producer sends a
message to the consumer and then waits for a
reply.
v The producer and consumer then both continue.
v No message queue develops between the producer and
the consumer.

5/29/2025 22
 Software Design and Architecture
Concepts
vSoftware patterns, including architectural and
design patterns, is helping developers avoid
unnecessary redesign and reimplementation.

v A design pattern describes a recurring design problem

to be solved, a solution to the problem, and the context
in which that solution works

v A design pattern (microarchitecture) is a larger-grained

form of reuse than a class

v Design pattern the “gang of four” book (reference)

5/29/2025 23
 Software Design and Architecture
Concepts
vThe main kinds of reusable patterns are:

v Design patterns: small group of collaborating objects

v Architectural patterns: larger-grained than design
patterns
v Analysis patterns: patterns found in object-oriented
analysis
v Product line-specific pattern: patterns used in specific
application areas, such as factory automation
v Idioms: low-level patterns that are specific to a given
programming language and describe implementation
solutions
5/29/2025 24
Software Design and Architecture
Concepts
vA component is a self-contained, usually
concurrent, object with a well-defined interface
that is capable of being used in applications
different from that for which it was originally
designed.

v It is necessary to define component in terms of the

operations it provides and the operations it requires
v Communication between components include
asynchronous (loosely coupled) and synchronous
(tightly coupled).

5/29/2025 25
 Software Design and Architecture
Concepts
vEach of the nonfunctional requirements (SW
quality attributes) needs to be explicitly considered
in the design of the software architecture.
v Maintainability;
v Modifiability;
v Testability;
v Traceability;
v Scalability;
v Reusability,
v Performance,
v Security,
v Availability

5/29/2025 26
Overview of SW Modeling and Design Method
vThe COMET use case–based Software life cycle
model is a highly iterative Software development
process:

v The method addresses three phases of requirements,

analysis, and design modeling

v In the requirements model, the functional requirements

of the system are described in terms of actors and use
cases.
v In the analysis model, the use case is realized to
describe the objects that participate in the use case and
their interactions.
v In the design model, the software architecture is
developed, describing components and their interfaces.
5/29/2025 27
 SW Modelling and Design
Method

COMET use case-based software life cycle model

5/29/2025 28
 Overview of SW Modeling and Design
Method

vRequirement modeling:

v Functional requirements are defined

v A narrative description of each use case is developed.
v In the requirements model, the functional requirements
of the system are described in terms of actors and use
cases.

v User inputs and active participation are essential

v If the requirements are not well understood, a
throwaway prototype can be developed
5/29/2025 29
Overview of SW Modeling and Design Method

vAnalysis modeling:

v Static and dynamic models of the system are developed.

v The classes and their relationships are depicted on
class diagrams.
v Object structuring criteria are used to determine the
objects
v Dynamic model to show the objects that participate in
each use case and how they interact with each other

v Either communication diagrams or sequence diagrams

and also statechart diagrams
5/29/2025 30
Overview of SW Modeling and Design Method

vDesign modeling:
v The analysis model is mapped to the design model to
emphasized on the solution domain.
v Subsystem structuring criteria are provided to structure
the system into subsystems
v For sequential systems, the emphasis is on the object-
oriented concepts of information hiding, classes, and
inheritance.
v For the design of concurrent systems, such as real-time,
client/server, and distributed applications, it is necessary
to consider concurrent tasking concepts.

5/29/2025 31
Overview of SW Modeling and Design Method
vCOMET Vs Unified SE Development Process:
v The COMET method is compatible with USDP
v The workflows of the USDP are the requirements,
analysis, design, implementation, and test workflows.
v USDP emphasizes process and – to a lesser extent –
method

v COMET method can also be used with the spiral model

v Requirements modeling, analysis modeling, or design
modeling, is then performed in the third quadrant
v The fourth quadrant, determine the numbers of iterations

5/29/2025 32
Overview of SW Modeling and Design Method

vActivities in Requirement Modeling :

v Define actors and use cases (use case model)

v The functional requirements described in terms of use
cases and actors.
v The use case modeling approach can be supplemented
to address nonfunctional requirements

5/29/2025 33
Overview of SW Modeling and Design Method
vActivities in Analysis Modeling (COMET) :
v The emphasis is on understanding the problem

v Classes are defined in terms of their attributes, as well as

their relationship with other classes

v Operations are defined in the design model.

v Determine the objects that participate in each use case

(entity, boundary, control and application logic)

v Communication or sequence diagrams are developed to

show how objects communicate with each other to execute
the use case.

v Describes state-dependent dynamic interaction modeling

5/29/2025 34
 Overview of SW Modeling and Design
Method
vActivities in Design Modeling (COMET) :
v Develop integrated object communication diagram(s)
v Make decisions about subsystem structure and
interfaces
v Make decisions about what software architectural and
design patterns to use
v Make decisions about class interfaces, in particular for
sequential software architectures.
v Design the operations of each class and the parameters
of each operation.
v Make decisions about how to structure the distributed
application into distributed subsystems
5/29/2025 35
Overview of SW Modeling and Design
Method
vActivities in Design Modeling (COMET) :
v Define the message communication interfaces between
the components
v Make decisions about the characteristics of objects,
particularly whether they are active or passive.
v Make decisions about the characteristics of messages,
particularly whether they are asynchronous or
synchronous

5/29/2025 36
Overview of SW Modeling and Design Method
vCOMET emphasized the use of structuring criteria
:
v Object structuring criteria are used to help determine the
objects in the system
v Subsystem structuring criteria are used to help
determine the subsystems
v Concurrent object structuring criteria are used to help
determine the concurrent (active) objects in the system.
v UML stereotypes are used throughout to clearly show
the use of the structuring criteria.

5/29/2025 37
Overview of SW Modeling and Design Method

vDuring SW design model the characteristics of the

SW architecture has to be decided:

v OO software architecture
v Client/Server software architecture
v Service-Oriented Architectures
v Distributed Component-Based Software Architectures
v Real-Time Software Architectures
v Software Product Line Architectures

5/29/2025 38
Assignment Five: Reading Assignment

v What is Design pattern?

v What is Architectural pattern?
v Write the different types of design patterns.
v Write the different types of architectural patterns.

5/29/2025 39
 Chapter -4
Requirement Modeling

5/29/2025 1
 Outline
Ø Software requirements analysis and specification
Ø Use case approach to define functional requirements
Ø How to extend use case to describe non-functional
requirements
Ø Use case modeling
Ø Actors and their role in the use case
Ø How to document use cases
Ø Use case guidelines
Ø How to describe use case using activity diagram

5/29/2025 2
 Use Case Modeling
vThe Software requirements describe the functionality that
the system must provide for the users.
vRequirement Analysis:
v What is your role in the current system?
v How do you use the current system?
v What are the advantage and limitation of the current
system?
v What features the new should provide for you?
v After the analysis the requirements has to be
specified.
v Requirement specification document need to be agreed by
both the analysts and users. (functional and nonfunctional)

5/29/2025 3
 Use Case Modeling
v In defining the functional requirement, it is necessary
to describe:
v What functionality the system needs to provide
v What information needs to be input from external
v What the system needs to output to the external
v What stored information the system reads or update
v Consider the following for a well written SRS:
v Correct, Complete, Unambiguous, Consistent, Verifiable,
Understandable by non-technical, Modifiable, Traceable.
v Several reviews need to be held with users.

5/29/2025 4
 Use Cases
v Use case model describes the functional
requirements of the system interims of actors and
use cases:
v What the system do, not the internals of how it does it
v A use case always starts with input from an actor
v The actor provides input to the system and the system
response to the actor
v Use case might involves several interactions b/n the actor
and the system
v More complex use cases might involves more than one
actors.
5/29/2025 5
 A Simple Use Case
ü The essentials of the use case description consist of
the following:
ü The name of the use case, View Alarms.
ü The name of the actor, Monitoring Operator.
ü A one-sentence use case summary
ü The description of the main sequence of events.
ü The description of any alternative to the main sequence

5/29/2025 6
 A Simple Use Case

5/29/2025 7
 Actors
v Actor can be human or external system
v Actor can be:
v Primary actor: initiates a use case
v Secondary actor: can participate in the use case

Input device actors

External system actors

5/29/2025 8
 Primary and Secondary Actors
v In some case, an actor can be an input device actor
or an input/output device actor.
v This can happen when there is no human
involvement with the use case.
v An actor can also be a timer actor that periodically
sends timer events to the system.

Example of timer actor

5/29/2025 9
 Identifying Use cases

v To determine the use cases, it is useful to start by

considering the actors and the interactions they
have with the system.
v Each use case describe interactions b/n the actor and the
system
v In this way, the functional requirements of the system
are described in terms of the use cases
v To avoid functional decomposition, focuses on a
sequence of events that provides a useful result to the
actor.

5/29/2025 10
 Identifying Use cases
v Each sequence through the use case is called a
scenario.
v A use case usually describes several scenarios,
one main sequence and a number of alternative
sequences.

v Note that a scenario is a complete sequence

through the use case:
v So a scenario could start out executing the main
sequence and then follow an alternative branch at the
decision point.
5/29/2025 11
 Documenting Use Cases in Use case
Model
v Each use cases in the use case model is
documented in the use case description:
v Use case:
v Summary: brief description (1 or 2 sentences)
v Dependency: optional (includes / extends)
v Actors: primary and secondary
v Precondition: one or more conditions
v Description of main sequence: the most usual sequence
v Description of alternative sequences: alternative branches off the
main
v Nonfunctional requirements: description of nonfictional requirements
v Postcondition: condition that must be true at the end of the use case
v Outstanding questions: question to be discussed with the user
5/29/2025 12
 Use case Descriptions

v An example of a use case for Make Order Request,

which is one of the use cases from the Online
Shopping System.
5/29/2025 13
 Use case Descriptions
(Scenario)

5/29/2025 14
 Use case Descriptions (cont.)

5/29/2025 15
 Use Cases Relationships
v When use cases get too complex, dependencies
between use cases can be defined by using the
include and extend.

v The objective is to maximize extensibility and

reuse of use cases.
v Include use case: common to more than one use case.
v An inclusion use case is executed in conjunction with a
base use case.

5/29/2025 16
 Use Cases Relationships

Example of an include use case and include

relationships
5/29/2025 17
 Use Cases Relationships

5/29/2025 18
 Use Cases Relationships

5/29/2025 19
 Use Cases Relationships
v The include relationship can also be used to structure a
lengthy use case.
v The base - high level sequence,
v The inclusion low-level sequence

Example of multiple include use case and include

5/29/2025 20
relationships
 Use Cases Relationships
v The extend relationship is used to model
alternative paths that a use case might take.
v The extend relationship can be used as follows:
v To show a conditional part of the base use case
that is executed only under certain circumstances.
v To model complex or alternative paths.

v The extension use case, depends on the base

use case and executes only if the condition in the
base use case is true.

5/29/2025 21
 Use Cases Relationships

Example of an extend relationship and extension use

case
5/29/2025 22
 Use Cases Relationships

5/29/2025 23
 Use Cases Relationships

5/29/2025 24
 Specifying Nonfunctional
Requirements
v The nonfunctional requirements can be specified
in a separate section of the use case.
v For the Validate PIN use case, they would be
described as follows:

5/29/2025 25
 Use Case Packages
v A use case package groups together related use
cases to manage the large number of use cases in a
large system.

5/29/2025 26
 Activity Diagram

v An activity diagram can be used to represent the

sequential steps of a use case, including the main
sequence and all the alternative sequences.

5/29/2025 27
 Activity Diagram for ATM Use
Cases

5/29/2025 28
 Static Modeling

5/29/2025 29
 Static Modeling

v A static model describes the static structure of the

system.
v The classes in the system
v The attributes of the class
v The relationship b/n the class
v The operations of each class

v The multiplicity of an association:

v One-to-one, One-to-many, Numerically specified,
Optional, Many-to-many association.
5/29/2025 30
 Static Modeling

Example of association on class diagram (bank

application)

5/29/2025 31
 Static Modeling

Example of class attributes

5/29/2025 32
 Association Class

v A class that models an association between two or

more classes.
v The attributes of the association class are the
attributes of the association

Example of association class

5/29/2025 33
 Composition and Aggregation
v Identify a class that is made up of other class
(whole/part).
v A composition is a stronger relationship than an
aggregation
v An aggregation is a stronger relationship than an
association

Example of composition hierarchy (physical class)

5/29/2025 34
 Composition and Aggregation
v In aggregation parts can be added and removed
from the aggregate whole. (conceptual classes)

Example of aggregation hierarchy

5/29/2025 35
 Generalization and
Specialization
v A discriminator is an attribute that indicates which
property of the object is being abstracted by the
generalization relationship.

Generalization / Specialization hierarchy

5/29/2025 36
 Static Modeling and the UML
v The approach used in COMET is to have a
conceptual static model early in the analysis phase
that is used to model and help understand the
problem domain.
v Physical class and the data-intensive classes (entity
classes)
v Physical: physical devices, sensors, external systems,
and timers. (embedded system)
v Entity: in information systems (banking application)

5/29/2025 37
 Static Modeling and the UML

Conceptual static model for Banking System

5/29/2025 38
 Static Modeling of the System
Context
v To understand the scope of the system.
v Context modeling explicitly identifies what is inside
the system and what is outside. It can be done at:
v The total system (HW and SW) level
v The software system (software only) level

v System context diagram: shows the border b/n the

system and the external environment.
v Software system context diagram: shows the
border b/n the SW system and the external
environment.

5/29/2025 39
 Static Modeling of the System
Context

Banking HW/SW system context class diagram

5/29/2025 40
 Static Modeling of the System
Context

Banking software system context class diagram

5/29/2025 41
 Categorization of classes using UML
Stereotypes
v In class structuring, the COMET method advocates
categorizing classes in order to group together
classes with similar characteristics.
v Stereotypes are used to distinguish among the various
kinds of classes.
v A class is categorized by the role it plays in the
application.
v Such as:
v <<entity>> class or <<boundary>> class
v External class can categorized: <<external system>>
<<external user>>

5/29/2025 42
 Categorization of classes using UML
Stereotypes

Example of UML classes and their stereotypes

5/29/2025 43
 Modeling External Classes
v Classification of external classes from the
perspective of the software system.

Classification of external classes by stereotype

5/29/2025 44
 Modeling External Classes
v The standard association names on software
system context class diagrams are Inputs to,
Outputs to, Communicates with, Interacts with,
and Signals.

5/29/2025 45
 Modeling External Classes
ü To develop a SW system context class diagram:
ü Determine the external classes from the static model
ü Categorized the external classes using stereotype
ü An I/O device actor is equivalent to an external
I/O device class.
ü An external system actor is equivalent to an
external system class.
ü A timer actor interfaces to the system via an
external timer class.

5/29/2025 46
Static Modeling of Entity Classes

v The COMET approach emphasizes static modeling

of entity classes, in order to take advantage of the
strengths of the static modeling.
v Entity classes are often mapped to a database in
the design phase.
v The COMET emphasis is on determining the entity
classes that are defined in the problem, their attributes,
and their relationships.

5/29/2025 47
Static Modeling of Entity Classes

Entity class model for online shopping application

5/29/2025 48
 Modeling Class Attributes

v An entity class is data-intensive, meaning that it

has several attributes.
v Entity classes having only one attribute is
questionable.
v Most probably it can be an attribute of another class

5/29/2025 49
 Modeling Class Attributes

Entity class attributes for online shopping application

5/29/2025 50
 Lecture five

Object and Class Structuring, and

Dynamic Interaction

5/29/2025 1
 I. Object and Class Structuring

5/29/2025 2
 Lecture Outline

ü Overview of object and class structuring

ü Describes modeling application classes and objects
ü Overview of object and class structuring categories
ü Describes external classes and boundary classes
ü Describe the different types of boundary classes and
objects
ü Describe entity classes and objects
ü Describe the different types of control classes and
objects
ü Describe application logic classes and objects
5/29/2025 3
Object and class Structuring Criteria
§ Determining the software objects is the next
step after defining the use cases and developing
the static model.
§ But there is no one unique way to decompose a
system into objects
§ Because the decision is based on the analyst
judgment
§ Whether objects are in the same class or in a
different class depends on the nature of the
problem. Example: cars, vans and trucks
§ In automobile catalog – (object in the same class)
§ For vehicle manufacturer – (object of different class)
5/29/2025 4
 Object and class Structuring Criteria
ü Object and class structuring criteria are provided to
assist the designer in structuring a system into objects.
ü Look for real-world objects in the problem domain and
then design corresponding software objects.

ü It is necessary to determine what software classes

and objects are needed to realize each use case.
ü Before starting dynamic modeling
ü The structuring criteria categorize software classes and
objects by the roles they play

5/29/2025 5
 Modeling Application Classes and
Objects

5/29/2025 Classification of Application classes by 6

 Object and Class Structuring
Criteria
ü In this step, classes should be categorized in order
to group together, based on their similar
characteristics.
ü The categorization in previous slide applies equally
to classes and objects.
ü B/c an object is an instance of a class.
ü Object has the same stereotype as the classes

5/29/2025 7
 Object and class Structuring
Categories
ü Most applications will have objects from each of
the four categories.
ü However, different types of applications will have a
greater number of classes in one or other category.

ü Information-intensive systems will have several entity

classes (Static model is so important).
ü Real-time systems are likely to have several device I/O
boundary classes. (state-dependent control classes)

5/29/2025 8
 Object and class Structuring
Categories
Ø The four main objects and classes categories:
1. Entity Objects: encapsulates information and provides
access to the information it stores
2. Boundary Objects: interfaces to and communicates
with the external environment
ü User interaction objects: object that interacts with and
interfaces to a human user
ü Proxy objects: object that interfaces to and communicates
with an external system or subsystem
ü Device I/O objects: object that receives input from and/or
outputs to a hardware I/O device

5/29/2025 9
 Object and class Structuring
Categories
v The four main objects and classes categories (Cont..)
3. Control Objects: object that provides the overall
coordination for a collection of objects (reading assignment:
read the following types of control objects)
ü Coordinator objects: overall decision maker of all related
objects
ü State-dependent objects: object whose behaviour varies in
each of its states.
ü Timer objects:
4. Application logic Objects: object that contains the details
of the application logic.
v To hide the application logic separately from the data
v It can be business logic, algorithm and service.

5/29/2025 10
 Object and class Structuring
Categories
Ø In most cases, what category an object fits into
is usually obvious.
Ø However, in some cases, it is possible for an object
to satisfy more than one of the aforementioned
criteria.

Ø Example: an object can have entity object and algorithm

object characteristics.
Ø In such cases, allocate the object to the category it
seems to fit best.

5/29/2025 11
 External Class and Software Boundary
Classes
ü External classes are classes that are outside the
software system and that interface to the
system.
ü Boundary classes are classes inside the system
that interface to and communicate with the
external classes.
ü Consider the external classes to determine the
boundary classes.
ü Each of the external classes communicates with a
boundary class.
ü There is usually a one-to-one association between
the external class and the internal boundary class.

5/29/2025 12
 External Class and Software Boundary
Classes
ü External classes interface to software boundary
classes as follows:

ü An external user class interfaces to and interacts with

a user interaction class.
ü An external system class interfaces to and
communicates with a proxy class.

ü An external device class provides input to and/or

receives output from a device I/O boundary class.

ü An external timer class signals to a software timer

class.
5/29/2025 13
 Boundary Classes and Objects

v The three different types of boundary classes:

v User interaction object.

v Proxy objects
v Device I/O objects

5/29/2025 14
 User Interaction Objects
§ Communicates directly with the human user.
§ Receiving input from the user and providing output
to the user via standard I/O devices.

Example of user interaction class and object

5/29/2025 15
 Proxy Objects
v Interfaces to and communicates with an external
system.
v Local representative of the external system and
hides the details of “how” to communicate with the
external system.

5/29/2025 Example of proxy class and object 16

 Device I/O Objects
§ Provides the software interface to a hardware I/O device.
§ Device I/O boundary objects are needed for
nonstandard application specific I/O devices.

5/29/2025 Example of input class and object 17

 Device I/O Objects

Example of output class and object

5/29/2025 18
 Device I/O Objects

5/29/2025 Example of I/O class and object 19

 Depicting External Classes and Boundary
Classes

5/29/2025 Banking System External classes and Boundary classes 20

 Entity Classes and Objects
ü It is a software object that stores information.
ü Entity objects store data and provide limited access
to that data via the operations they provide.

5/29/2025 Example of entity class and object 21

 Control Classes and Objects
ü Provides the overall coordination of the objects that
realize a use case.

ü Simple use cases do not need control objects.

ü Depending on the characteristics of the use

case, the control object may be state-dependent.
ü A coordinator object is an overall decision-making
object that determines the overall sequencing for a
collection of related objects.
ü The decision is based on the input it receives

5/29/2025 22
 Control Classes and Objects

5/29/2025 Example of coordinator class and object 23

 Control Classes and Objects
v A state-dependent control object is a control object
whose behavior varies in each of its states.
v A finite state machine is used to define a state-
dependent control object.

5/29/2025 Example of state-dependent control class and object 24

 Control Classes and Objects
v A timer object is a control object that is activated by
an external timer. (real-time clock, OS clock)
v It either performs some action itself or activates
another object to perform the desired action.

5/29/2025 Example of a timer class and object 25

 Application Logic Classes and
Objects
ü A business logic object define the business-specific
application logic for processing a client request.
ü Usually a business logic object accesses various
entity objects during its execution.
ü If the business rule can be executed by accessing two or
more entity objects, there should be a separate
business logic object.
ü See next slide… where withdrawal transaction manager
business logic accesses three entity objects to serve its
purpose.
ü If accessing one entity object is sufficient to execute
the business rule, it could be provided by an
operation of that object.
5/29/2025 26
 Application Logic Classes and
Objects

Example of business logic class and object

5/29/2025 27
 Application Logic Classes and
Objects
ü An algorithm object encapsulates an algorithm
used in the problem domain.
ü More prevalent in real-time, scientific, and
engineering domains.
ü Simple algorithms are usually operations of an entity
object that operate on the data.
ü An algorithm object frequently has to interact with
other objects in order to execute its algorithm.

ü Encapsulate and excite the algorithm

ü Coordinator object (supervise other objects)

5/29/2025 28
 Application Logic Classes and
Objects

5/29/2025 Example of algorithm class and object 29

 Application Logic Classes and
Objects
v A service object is an object that provides a service
for other objects.
v A service object never initiates a request; however, in
response to a service request it might seek the
assistance of other service objects.

v Service objects play an important role in service-

oriented architectures.

v Also client/server, component-based Software

architecture

5/29/2025 30
 Application Logic Classes and
Objects

5/29/2025 Example of service class and object 31

 II. Dynamic Interaction Modeling

5/29/2025 32
 Lecture Outline
v Overview of object interaction modeling
ü Communication diagrams
ü Sequence diagrams
v Describes message sequence numbering on
interaction diagrams
v Introduces dynamic interaction modeling
v Describe stateless dynamic interaction modeling
v Examples of dynamic interaction modeling

5/29/2025 33
 Object Interaction Modeling
ü A communication diagram is an interaction diagram
that depicts a dynamic view of a group of objects
interacting with each other by showing the sequence
of messages passed among them.
ü A communication diagram is developed for each use
case
ü Only objects that participate in the use case are
depicted

ü The sequence in which the objects participate in

each use case is depicted by means of message
sequence numbers.
5/29/2025 34
 Object Interaction Modeling

5/29/2025 Use case diagram for the View Alarms use case 35
 Object Interaction Modeling

5/29/2025 Communication diagram for the View Alarms use case 36

 Object Interaction Modeling
– Sequence diagram: shows object interactions
arranged in time sequence.
• Can also depict loops and iterations

– Sequence diagrams and communication diagrams

depict similar information, but in different ways.

– Usually either communication or sequence diagrams

are used to describe a dynamic view of a
system.
– Numbering the messages on sequence diagram
is not essential, it can be shown from the top to
the bottom.
5/29/2025 37
 Object Interaction Modeling

5/29/2025 Sequence diagram for the View Alarms use case 38

 Analysis and Design Decision in Object Interaction
Modeling
q In the analysis model, messages represent the
information passed between objects.
q Interaction diagrams (communication or sequence )
help in determining the operations of the objects.
q But, the information is more important at this stage

q During design:
q The type operations
q Kind of message passed between objects
q Object type

5/29/2025 39
 Sequence Diagram Vs Communication
Diagram
ü Sequence diagrams:
ü Clearly shows the order of the messages
ü Indicating the objects connection is more difficult
ü Iterations and decision statements can obscure
ü Communication diagrams :
ü Shows the layout of the objects (connection)
ü Message sequence is less readily visible

ü The communication diagrams are the COMET

preference
ü Important step in the transition to design (To create
the initial software architecture)
5/29/2025 40
 Massage Label on Interaction
Diagram
v A message label has the following syntax:
v [sequence expression]: Message Name (argument
list)
v Dynamic interaction modeling is carried out for each
use case.
v Dynamic interaction modeling can be either state-
dependent or stateless.

5/29/2025 41
 Stateless Dynamic Interaction
Modeling
ü The main steps in the stateless dynamic interaction
modeling approach are:
ü Start with the use case
ü Consider the objects needed to realize the use case
ü Determine the sequence of message communication
among the objects
ü Two dynamic interaction modeling examples:
ü Use case for View Alarms
ü Use case for Process Delivery Order

5/29/2025 42
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Use case description 43

 Example of Stateless Dynamic Interaction
Modeling
v Determine objects needed to realize use case:
v Two objects participate
v User interaction object (Operator Interaction)
v Service object (Alarm Service)

v Determine message communication sequence:

v Operator Interaction object make a request
v Alarm Service responds with the desired information

5/29/2025 44
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Message sequence 45

 Object Interaction Modeling

5/29/2025 Communication diagram for the View Alarms use case 46

 Example of Stateless Dynamic Interaction
Modeling
v Example 2: Stateless dynamic interaction modeling
of an online shopping service-oriented system.

5/29/2025 Use case diagram for the Make Order Request use case 47
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 48
Use case description
 Example of Stateless Dynamic Interaction
Modeling
v Determine objects needed to realize use case:

v User interaction object (Customer Interaction)

v Service one (Customer Account Service)
v Service two (Credit Card Service)
v Service three (Delivery Order Service)
v Service four (Email Service)
v Coordinator object (Customer Coordinator)

5/29/2025 49
 Example of Stateless Dynamic Interaction
Modeling
v Determine message communication sequence:
v Customer Interaction makes an order request to
Customer Coordinator (M1 and M2)
v Customer Coordinator needs to request account
information from Customer Account Service (M3 and
M4)

v Customer Coordinator needs to request credit card

authorization from Credit Card Service (M5)
v The credit card authorization request is approved (M6)

5/29/2025 50
 Example of Stateless Dynamic Interaction
Modeling
v Determine message communication sequence:

v Customer Coordinator needs to store the order at

Delivery Order Service (M7 and M8)

v The system confirms the order to the user (M9 and

M10)

v Sends a confirmation email via the email service (M9a)

5/29/2025 51
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Message description 52

 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Communication Diagram : Main Sequence 53

 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Sequence diagram : main sequence 54

 Example of Stateless Dynamic Interaction
Modeling
v Determine alternative sequence:

v The scenario diverges from the main scenario at step

M4A.
v The alternative response to the account request of
step M3 is M4A [no account]:
v Account does not exist

v The message sequence for this alternative scenario is

M4A through M4A.8

5/29/2025 55
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025
Alternative message description 56
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Sequence diagram : alternative sequence for Create New Account 57

 Example of Stateless Dynamic Interaction
Modeling
ü Determine alternative sequence:
ü The scenario also diverges from the main scenario at
step M6A.
ü The alternative response to the authorized credit card
request of step M5 is M6A [denied]:
ü Credit card denied

ü The message sequence for this alternative scenario is

M6A through M6A.2.

5/29/2025 58
 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Alternative sequence description 59

 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Communication diagram : alternative sequence for Credit Card denied 60

 Example of Stateless Dynamic Interaction
Modeling

5/29/2025 Generic communication diagram (main + alternative sequences) 61

 Example of Stateless Dynamic Interaction
Modeling

Generic sequence diagram (main + alternative sequences)

5/29/2025 62
 Thank You !!!

?
5/29/2025 63
 Finite State Machine and State-
Dependent Dynamic Interaction
Modeling
Lecture - 6

5/29/2025 1
 I. Finite State Machines

5/29/2025 2
 Lecture Outline
v Describes events and states in finite state
machines
v Introduces the statechart by examples
v Describes events and guard conditions
v Describe statechart actions
v Describe hierarchical statecharts
v Provides guidelines for developing statecharts
v The process of developing statecharts from
use case
5/29/2025 3
 Finite State Machines and State
Transitions
vA finite state machine is a conceptual machine with a
finite number of states.
v It can be in only one state at any one time.
v A state transition is a change in state that is caused by
an input event.
v The event might have no effect, in this case the finite state
machine remains in the same state.
v The next state depends on the current state, as
well as on the input event.
v An output action might result from the state transition.

5/29/2025 4
 Events
ü An event is an occurrence at a point in time; it is also
known as a discrete event, discrete signal, or
stimulus.
ü An event is an atomic occurrence and
conceptually has zero duration.
ü Example: Card Inserted, Pin Entered, and Door Opened.

ü Events can depend on each other.

ü An event can originate from an external source, Card
Inserted, or
ü Can be internally generated by the system, Valid PIN.

5/29/2025 5
 Events

5/29/2025 Figure 1: Example of main sequence of statechart 6

 States
ü A State represents a recognizable situation that
exists over an interval of time.
ü Whereas an event occurs at a point in time.

ü In theory, a state transition is meant to take zero

time to occur.
ü In practice, the time for a state transition to occur is
negligible compared to the time spent in the state.

5/29/2025 7
 Example of ATM Statechart
ü The initial state of the ATM statechart is Idle.

ü Consider the scenario consisting of the customer

inserting the card into the ATM, entering the PIN, and
then selecting cash withdrawal.

ü When the Card Inserted event arrives, the ATM

statechart transitions from the Idle state to the Waiting
for PIN state, during which time the ATM is waiting for
the customer to input the PIN.

5/29/2025 8
 Example of ATM Statechart

5/29/2025 Example of alternative events on statechart 9

 Example of ATM Statechart
vIn some cases, it is also possible for the same event to
occur in different states and have the same effect.

vThe customer may decide to enter Cancel in any of the

three states:
v Waiting for PIN,
v Validating PIN, or
v Waiting for Customer Choice.
v The statechart entering the Ejecting state, the ATM
card being ejected, and the transaction terminated.

5/29/2025 10
 Example of ATM Statechart

Figure 3: Example of same event occurring in different

5/29/2025 states 11
 Example of ATM Statechart

Figure 4: Example of complete ATM scenario: cash withdrawal

scenario
v It is also possible for the same event to occur in a
different state and have a different effect.
5/29/2025 12
 Example of Microwave Oven
Statechart

Figure 5: Simplified statechart for Microwave Oven Control

5/29/2025 13
 Events and Guard Conditions

v It is possible to make a state transition conditional

through the use of a guard condition.
v This can be achieved by combining events and guard
conditions in defining a state transition.

v The notation used is Event [Condition]. Conditions are

optional.

5/29/2025 14
 Events and Guard Conditions

Figure 6: Example of events and conditions

5/29/2025 15
 Actions

v An action is a computation that executes as a result of

a state transition.
v An event is the cause of a state transition, an
action is the effect of the transition.

v These are entry and exit actions.

v Entry actions are triggered when the state is entered.
v Exit actions are triggered on leaving the state.

5/29/2025 16
 Actions on State Transitions

v To depict a transition action on a statechart, the state

transition is labeled Event/Action or Event [Condition]/
Action.

Figure 7: Example of actions in main sequence

5/29/2025 17
 Actions on State Transitions

Figure 8: Example of alternative state transitions and actions

5/29/2025 18
 Actions on State Transitions

Figure 9: Example of same event and action on different state

5/29/2025 transitions 19
 Entry Actions
v An entry action is an instantaneous action that is
performed on transition into the state.
v An entry action is represented by the reserved word
entry and is depicted as entry/Action inside the state
box.
v The best time to use an entry action is when the
following occur:
v More than one transition into a state
v The same action needs to be performed on every
transition
v The action is performed on entry into this state and not
on exit from the previous state.
5/29/2025 20
 Entry Actions

Figure 10: Example of entry action: (a) Actions on state transitions (b) Entry
5/29/2025 21
actions
 Exit Actions
v An exit action is an instantaneous action that is
performed on transition out of the state.
v An exit action is represented by the reserved word exit
and is depicted as exit/Action inside the state box.
v The best time to use an exit action is when the
following occur:
v More than one transition out of a state
v The same action needs to be performed on every
transition
v The action is performed on exit into this state and not
on entry into the next state.

5/29/2025 22
 Exit Actions

Figure 11: Example of exit action: (a) Actions on state transitions (b) Exit
5/29/2025 23
actions
 Composite States
v Composite states can be depicted in two ways on
statecharts
v As a black box without revealing its internal substates
v With its internal substates

Figure 12: Example of hierarchical statechart

5/29/2025 24
 Composite States

Figure 12: Example of hierarchical statechart (Aggregate)

5/29/2025 25
 Orthogonal Statecharts
v Another kind of hierarchical state decomposition
is orthogonal state decomposition.
v A high-level state on one statechart is decomposed into
two (or more) orthogonal statecharts.
v The two orthogonal statecharts are shown separated by a
dashed line.

v It is better to use this kind of decomposition to

show different parts of the same object that are
not concurrent.

5/29/2025 26
 Orthogonal Statecharts

Figure 13: Example of orthogonal statecharts in the ATM

5/29/2025 27
 Guidelines for Developing
Statecharts
v To develop flat/hierarchical statecharts:
v State name should reflect situation.
v Each state must have a unique name.
v It is not necessary for a statechart to have a terminating
state.
v Two states cannot be active simultaneously (sequential)
v Do not confuse events and actions.
v An action is a command.
v An action executes instantaneously.
v A condition is a Boolean value.
v Actions and conditions are optional.

5/29/2025 28
 Developing Statecharts from Use
Cases

v Develop Statechart for Each Use Case

Figure 14: Statechart for ATM Control: Validate PIN use case
5/29/2025 29
 Developing Statecharts from Use
Cases

Figure 15: Statechart for ATM Control: Withdraw Funds use

5/29/2025 case 30
Consider Alternative Sequences

Figure 16: Statechart for ATM Control: Withdraw Funds use case with
5/29/2025 alternatives 31
Developing Integrated Statechart

Figure 17: Statechart for ATM Control: integrated statechart for Validate PIN
5/29/2025
and Withdraw Funds use case with alternatives 32
 Developing Hierarchical
Statechart

Figure 18: Top-level statechart ATM Control

5/29/2025 33
 Developing Hierarchical
Statechart

Figure 19: Statechart for ATM Control: Processing Customer Input

5/29/2025 composite state 34
 Developing Hierarchical
Statechart

Figure 20: Statechart for ATM Control: Processing Transaction composite

state

5/29/2025 35
 Developing Hierarchical
Statechart

5/29/2025 Statechart for ATM Control: Terminating Transaction composite state 36

 II. State-Dependent Dynamic
Interaction Modeling

5/29/2025 37
 Outline

v Describes the steps in state-dependent dynamic

interaction modeling
v Describe how to model interaction scenario on
interaction modeling and statecharts
v Give examples of state-dependent dynamic
interaction modeling

5/29/2025 38
Steps in State-Dependent Dynamic Interaction Modeling

v Objective is to determine the interactions among the

following objects.
v The state-dependent control object
v The objects, usually software boundary objects, which
send events to the control object.
v The objects that provide the actions and activities,
which are triggered by the control object.
v Any other objects that participate in realizing the use
case.

5/29/2025 39
Steps in State-Dependent Dynamic Interaction Modeling

v The main steps in the state-dependent dynamic

interaction modeling:
v Determine the boundary object(s).
v Determine the state-dependent control object.
v Determine the other software objects.
v Determine object interactions in the main sequence scenario.
v Determine the execution of the statechart.
v Consider alternative sequence scenarios.

5/29/2025 40
Example of State-Dependent Dynamic Interaction Modeling:
Banking System
vDetermine main sequence:
v Consider the main sequence of the Validate PIN use
case.

5/29/2025 Figure 1: Communication diagram for Validate PIN use case: Valid PIN 41
scenario
Example of State-Dependent Dynamic Interaction Modeling: Banking
System

5/29/2025 Sequence diagram for Validate PIN use case: Valid PIN scenario 42
 Example of State-Dependent Dynamic Interaction
Modeling: Banking System

5/29/2025 43
Validate PIN statechart: Valid PIN scenario
 Example of State-Dependent Dynamic Interaction
Modeling: Banking System

5/29/2025 Sequence diagram for Validate PIN use case: Invalid PIN scenario 44
Example of State-Dependent Dynamic Interaction
Modeling: Banking System

Sequence diagram for Validate PIN use case: Third Invalid PIN scenario
5/29/2025 45
 Example of State-Dependent Dynamic Interaction
Modeling: Banking System

Figure 6: Sequence diagram for Validate PIN use case: Stolen or expired card
scenario

5/29/2025 46
Generic Interaction Diagram with all Scenarios

5/29/2025 Communication diagram for Validate PIN use case: generic 47

 Sequencing on Control Object and
Statechart
v In general, a message on an interaction diagram
(communication or sequence diagram) is referred to
as an event on a statechart.

v To ensure that the communication diagram and

statechart are consistent with each other, the
equivalent communication diagram message and
statechart event must be given the same name.

5/29/2025 48
 Sequencing on Control Object and State
chart

5/29/2025Statechart for ATM control for validate PIN use case, showing alternatives 49
 Read, Read.. and Read..

5/29/2025 50