Software Design and Architecture

(SDA)

Lecture # 5 & 6

Software Planning Software Design

Software
and Requirement (Architectural &
Development
analysis Detailed)
1
 Outline

Unified Modeling Language diagrams

Structural diagrams
 Object diagram
 Package diagram
Behavioral diagrams
 Activity
 State machine
 Sequence

Object-Oriented Paradigm: OO development process:

OO analysis  Requirements and Domain Classes : covered
OO design  detailed design: this lecture
OO implementation (in java course)
‘4+1’ view model
2
UML diagrams

3
UML diagrams

4
 Dependency Relationships

We use a dependency relationship to show when one element depends

on another element.

Class diagrams, component diagrams, deployment and object diagrams

use dependency relationships.

5
 Structural diagram: object diagram 1/2
Derived from class diagrams
Similar to a class diagram except it shows the instances of the classes
in the system and the relationship that exists between them
Represent the static view of a system but this static view is a
snapshot of the system at a particular moment
Help to understand functional requirements of a system
 Example: snapshot of moving train

6
Structural diagram: object diagram 2/2

7
 Structural diagram: package diagram
A package is represented by a tabbed folder that indicates where all included
classes and subpackages reside.
Packages play a similar role as a directory for grouping files in a file system;
they allow the organization of all closely related classes in one “container.”
Example: java packages as java, lang, awt, javax, swing, etc.
This diagram shows the dependency relationship between packages in which
a change of one package may result in changes in other packages.

8
 Behavioral Diagrams Activity Diagram
Workflow-oriented diagram describing the steps in a single process.
Can be used :
To model a human task (a business process, for instance).
To describe a system function that is represented by a use case.
In operation specifications, to describe the logic of an operation.
Involves complex workflow, decision making, concurrent executions,
exception handling, process termination, etc.
One starting point and one or more finishing points.
Identify the following elements before drawing an activity diagram:
 Activities
 Association
 Conditions

9
10
 Behavioral Diagrams Activity Diagram in UML

 Fork notation
 Join Notation

11
 Behavioral Diagrams  State Machine Diagram
Also called state chart and state transition diagram
Mostly drawn for a single class to show the lifetime behavior
(different states ) of a single object or entire system
event-oriented diagram  objects change their states in response to
external or internal events
a state is a rounded rectangle with three subdivisions: state name,
state variables, and state activities.
A complex composite state may have a subordinate state diagram.
One starting point in a solid black circle and has one or more
endpoints

12


13
 Behavioral Diagrams State Machine Diagram
State machine diagram of ‘Order Processing System’ login use case ??

14
 Activity diagram vs state machine diagram 1/2

Activity diagram State machine diagram

Is flow of functions without trigger (event) Consist of triggered states
mechanism
Does not need explicit events but rather Performs actions in response to explicit
transitions from node to node in its graph events
automatically upon completion of activities.

Capture high level aspects of the whole Mostly drawn for a single class to show the
system activities. lifetime behavior (different states ) of a single
object or entire system

15
 Activity diagram vs state machine diagram 2/2

State machine diagram Activity diagram

16
 Behavioral Diagrams  Interaction Diagrams

Interaction Diagrams used to describe some type of

interactions among the different elements in the model.

The purpose of interaction diagram is to: −

capture the dynamic behavior of a system.
describe the message flow in the system.
describe the structural organization of the objects.
describe the interaction among objects
UML provides two popular forms of interaction diagrams:
i. Sequence diagrams
ii. Communication or collaboration diagrams.

17
 Behavioral Diagrams  Sequence Diagram
One of the most important and widely used UML diagram
Is a time oriented interaction diagram
Usually, one sequence diagram corresponds to one use case.
Activations represent the object-activated state in which it receives
or sends out messages.
Synchronous message represented by a line with full arrow head
Asynchronous message represented by a line with half arrowhead
Can branch or fork many separate lifelines for the if-selection
scenario conditions; eventually all forked lines will join together.

18
19
Behavioral Diagrams Sequence Diagram

20
 Communication or collaboration diagrams
Here method call sequence is indicated by some numbering technique.
The number indicates how the methods are called one after another.
shows the object organization.

21
 Sequence diagram vs collaboration diagrams
To choose between these two diagrams, emphasis is placed on the type
of requirement. If the time sequence is important, then the sequence
diagram is used. If organization is required, then collaboration diagram is
used.

22
 Case Study
Assume that you are going to construct an Order Processing System (OPS) that is
an important part of an online store.
 The online store has the following subsystems:
 An online product catalog
 Order processing system for user orders
 Financial department
 Shipping department,
 OPS must interact with other components and provide the following services to
customers:
 Each customer has an online shopping cart to add and remove items
 A customer is able to check out using a credit card.
 Before the transaction is completed, a customer should be able to learn
about his order's estimated arrival date
 A customer can choose to cancel the transaction by clearing all items in the
shopping cart.
 OPS must be available as a web accessible system.
23
 OO Development process

• Results in requirements and domain classes

OO Analysis • Requirement Specification with the help Of:
(Domain & requirement 1. UML use case diagram
analyses) 2. Analysis-class diagram.

Responsibilities are assigned to each class:

OO Design Step 1: Identify Classes—CRC Card High-
Step 2: Construct an Interaction Diagram level
Step 3: Build a State Machine Diagram Low-
Step 4: Class Specification level

OO
OO program
Development

24
OO Analysis  Analysis class diagram of OPS

26
 OO development process  OO Design
OO Analysis use-case diagram and analysis class diagrams are
very useful in the OO design process

Goal is to develop the structural architecture of a system

System is decomposed into logical components called classes

with detail description including attributes, operations etc.

27
 OO Design

High-level (conceptual) design: all classes needed for building

the system are identified and each class is assigned a certain
responsibility.
class diagram (CRC card) is constructed in order to clarify
the relations among the classes
Interaction diagrams constructed on the basis of use cases
diagram

Low-level (detailed) design: attributes and operations are

assigned to each class based on the interaction diagrams.
State machine diagrams constructed for complex classes

28
 OO Design:
1) Identify Classes: Class-Responsibility-Collaborator (CRC) Card
CRC card modeling is a team-based approach  consists of three
sections: class name, responsibility, and collaborator.

Responsibility of a class is a task that must be performed by the

class or the knowledge that is known by the class.

A collaborator is a class that is involved in accomplishing the

responsibility of a class.

Three types of participants are:

i. Domain users
ii. OO design analysts
iii. Facilitators
29
 OO Design : CRC card for Register Use case
Register: A customer visits the registration page and specifies
the desired user name and password. If there is already such a
username/password pair, the system reports error; otherwise, it
reports success. When the registration is completed, the user
name, password, full name, and the billing address are stored in a
database system.

30
CRC card for Register Use case registrationController

31
CRC card for Register Use case  CustomerInfoDB

32
CRC card for SessionController class

33
 OO Design:  2. Construct an Interaction Diagram
UML provides two popular forms of interaction diagrams:
i. Sequence diagrams
ii. Communication or collaboration diagrams.

They are semantically equivalent. Here sequence diagram will be

used to model OPS.

34
Sequence Diagram of registration use case

35
 OO Design  3) Build a State Machine Diagram
Detailed level design begins after completion of analysis class
diagram, CRC card designs and interaction diagrams for each use
case

Main objective is to specify the interface of each class and make

decision about implementation

Final Outcome: detailed class diagram having attributes and

operations defined for each class

State machine diagrams used to clarify the classes having

complex behaviors

36
 State Machine Diagram
A state machine diagram consists of two types of basic elements:
(1) state
(2) Transition

Two cases of building a state machine diagram are When a class is :

1. Responsible for a single complex use case
2. Involved in multiple use cases
 Complex state machine diagram can be divided into the
substate utility included in UML 2.

37
Composite sate

Low-level state diagram

38
 OO Design  4) Class Specification

1. Identify public interface of classes that should be complete and

stable. Four kinds of operations in public interface are:
i. Constructor operations,
ii. Destructor operations,
iii. Accessor operations, and
iv. Mutator operations.
2. Define implementation details of the class i.e the private attributes
and additional operations. must consider the following for
identifying private attributes.
i. According to the CRC cards, what must be known by the class?
ii. Based on the state machine diagram, what states does the
object go through?  constant attributes.
iii. What association factors should be modeled?
iv. What other data members might be needed for the
implementation of operations? 39
 Class Specification of SessionController class
Examine the:
 CRC card
Analysis class diagram
State machine diagram
Interaction diagram

3. Refine the design of operations:

i. What parameters are needed to invoke the operation?
ii. What should be the return value?

Final outcome: detailed design class diagram containing

documentation of each class in the system

40
Class Specification of SessionController class

41
 Intent of 4+1 view model

 a mechanism to separate the different aspects of a software

system into different views of the system.  Different
stakeholders always have different interest in a software
system.

DEVELOPERS – Aspects of Systems like classes

SYSTEM ADMINISTRATOR – Deployment, hardware and

network
configuration.

 Similar points can be made for Testers, Project Managers and

Customers.
 Solution came from 4+1 View Model
 “4+1” view model used to address the large and challenging
architectures

 The views are used to describe the system from the viewpoint of
different stakeholders, such as end-users, developers and project
managers.

 In addition selected use cases or scenarios are utilized to illustrate

the architecture serving as the 'plus one' view.
 The 4+1 View model

End user Development Programmers

Logical view & software
view
managers

Scenarios

Process View Physical View

Integrator System Engineer

 Describes software architecture using five concurrent

views.
 Scenario / Use case View

(Putting it all together)

Viewer
: All users of other views and Evaluators.
Considers : System consistency, validity

 Capture the most important aspects of the functional requirements

 used to drive architecture design in the earlier phases of software
development and is also used for software validation at later phases
of the development cycle
 It is redundant with other views.
 UML diagram – Use case diagrams.
 Logical View

(Object-oriented Decomposition)

Viewer : End-users, analysts, designers

Considers : Functional requirements- What the system should
provide in terms of services to its users.

 This view shows the components (objects) of the system as well as their
interactions / relationships.

 UML diagrams – Class, State, Object, Sequence,

Communication diagrams.
 Process View

(The process decomposition)

Viewer : developers and Integrators

Considers : Non - functional requirements (concurrency, performance, scalability,
synchronization, distribution, system throughput) as well as
functional requirements
 Focuses on the dynamic aspects of the system, i.e., its execution
time behaviour
 shows the processes / workflow rules of a system and how those
processes communicate with each other concurrency and
synchronization issues
 UML diagrams – Activity diagram
48
 Development View
(Subsystem decomposition)

Viewer : Programmers and Software project Managers

Considers : organization of software module created by many teams
of developers  (Hierarchy of layers, software
management, reuse, constraints of tools)

 Describes the static organization of the system modules.  Eg:

Packages Used, Execution Environments, Class Libraries and Sub
systems utilized.
 Maps software component elements to actual physical directories
and files.
 UML diagrams – Component, Package diagrams.
 Physical Views

(Mapping the software to the Hardware)

Viewer : System Engineers, system installers, system administrators

Considers : Non-functional req. regarding to underlying hardware
(Topology e.g. star topology, bus topology, Communication),
system availability, reliability (fault-tolerance) etc.

 describes installation, configuration, and deployment of the

software application.  systems execution environment
 shows the mapping of software onto hardware

 UML diagram – Deployment diagram.

 Relationship among the views

 Concurrency is not addressed in the logical view, to achieve the

process view, we need to map classes and their objects onto tasks and
processes addressing concurrency and synchronization.
 The processes and process groups are mapped onto the processing
nodes of a physical computer network to obtain the physical view.
For each dependency between components, there must be a
corresponding link between nodes.
 The logical view is also the basis for the development view.
Normally each class corresponds to a module.
 Modeling a system

 Decide which views are needed to best express the architecture of

the system and to expose the technical risks to the project.
 For each of these views, decide the artifacts(eg. UML Diagrams)
needed to be created to capture the essential details of that view.
 As part of process planning, decide which of the UML diagrams
require frequent reviews and which have to be documented.
 Why is it called the 4 + 1 instead of just 5?

 The use case view has a special significance. When all other views are
finished, it's effectively redundant.
 all other views would not be possible without use case view .
 It details the high levels requirements of the system.
 The other views detail how those requirements are realized.
 Is it important?
 It makes modeling easier.

 Better organization with better separation of concern.

 The 4 + 1 approach provides a way for architects to be able to

prioritize modeling concerns.
 The 4 + 1 approach makes it possible for stakeholders to get

the parts of the model that are relevant to them.

 References
Chapter 3-4 (selective topics) of book 3: “Software Architecture Design -
Illuminated”

https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-i
s-sequence-diagram/
https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
https://www.geeksforgeeks.org/association-composition-aggregation-java/
https://www.c-sharpcorner.com/UploadFile/3614a6/accessors-and-mutators-i
n-java/#:~:text=A%20Mutator%20method%20is%20commonly,in%20other%2
0words%20change%20things.&text=Mutator%20methods%20do%20not%20
have,depending%20on%20their%20private%20field
.

55
56