Software Architecture and Design-Ch-2-v6.pdf

© 2025, UKH, Dr.Ibrahim Ismael Hamarash, ibrahim.hamad@ukh.edu.krd
Software Architecture & Design, Chapter II: Overview: The Unified Modeling Language (UML)
Software Architecture and Design
Chapter II
Overview: The Unified Modeling
Language (UML)
Professor Dr. Ibrahim Ismael Hamarash
ibrahim.hamad@ukh.edu.krd
https://ibrahimhamarash.github.io

Why Modeling Languages?
➢ People in the Software Industry need a
common language to communicate.

Architects do architecture diagrams
The
Model-Code
Gap

The Unified Modeling Language (UML)
➢ A graphical language for visualizing,
specifying, constructing, and documenting
the artifacts of distributed object
systems. www.omg.org
➢ UML enables us to present the widely
varying aspects of a software system (e.g.,
requirements, data structures, data flows,
and information flows) within a single
framework using object-oriented concepts.
The UML originally was developed in middle of
1990s as a combination of previously competing
object-oriented analysis and design
approaches:
• Booch method by Booch
• Object-Modeling Technique (OMT) by
Rumbaugh, Blaha, Premerlani, Eddy, and
Lorensen.
• Object-Oriented Software Engineering (OOSE)
by Jacobson, Christerson, Jonsson, and
Overgaard.
• Other contributions to modeling complex
systems, e.g., statecharts by Harel.

The Unified Modeling Language (UML), cont.
➢ UML is a family of graphical notations, backed by a
single meta-model, that help in describing and designing
software systems.
➢ As a language, UML offers the syntax (the notation of
the language elements), the semantics (the meaning of
the language elements), and the pragmatics (how to use
the language elements) through a set of diagrams.
➢ Some consider UML to be the software equivalent of
the blueprints in other engineering disciplines.
The first version of UML
(version 1.1) was approved by
OMG in year 1997; afterwards
UML has been revised with
several releases (UML 1.3,
1.5, 2.0, 2.1.1, 2.1.2, 2.2, 2.3,
2.4.1, 2.5, and 2.5.1 ).

➢ UML is considered a prescriptive language, but for most people, it has
descriptive rules.
➢ UML is not by any means a complete list of all the useful diagrams that
you might want to use. You should not hesitate to use non-UML diagrams
if no UML diagrams suit your purpose.
➢ How to start, is up to you.
➢ Patterns, use handbooks if available to do common things.
(example: www.hillside.net )

UML 2.5 Diagrams

1. Class Diagram: Definition
A class is a category or group of things that have the same
attributes and the same behaviours.
Example: in an education diagram, you can model that the
classes Course, Student, and Professor occur in a system.
Professors teach courses and students attend courses.
Students and professors have common properties as they are
both members of the class Person. This is expressed by a
generalization relationship.

The Class Diagram
➢ In object-oriented approaches, it is possible to define classes that
describe the attributes and the behaviour of a set of objects (the instances
of a class) abstractly and thus group common features of objects.
➢ We use the class diagram to model the static structure of a system, thus Class diagram
describing the elements of the system and the relationships between them. These
elements and the relationships between them do not change over time.
➢ A class also defines a set of permitted operations that can be applied to the instances of
the class. For example, you can reserve a lecture hall for a certain date, a student
can register for an exam, etc. In this way, classes describe the behaviour of objects.
➢

Class: Example
Students have a name and a
matriculation number and attend various
courses.
This sentence covers a small part of
the university structure and does not
lose any validity even over years. It is
only the specific students and courses
that change

Visualizing a class
➢ A class is represented as a rectangle in
the UML.
➢ By convention, Class name is a word
with an initial uppercase letter. It
appears near the top of the rectangle.
➢ If your class has a two word name,
join the two words together and
capitalize the first letter of the
second word too.
Attributes
Operations
Class name

Visualizing a class
➢ The list of attribute names begins below
a line separating them from the class
name.
➢ By convention, a one word attribute name
is written in lowercase letters. If the
name consists of more than one word, the
words are joined and each word other
than the first word begins with an
uppercase letter.
Attributes
Operations
Class name

Visualizing a class, cont.
➢ An operation is something a class can do, and
hence it is something that you (or another class)
can ask the class to do.
➢ Like an attribute name, an operation's name is all
in lowercase if it's one word. If the name consists
of more than one word, join the words and begin all
words after the first with an uppercase letter.
The operation name is followed by a closed
parenthesis.
➢ The list of operations begins below a line that
separates the operations from the attributes.
Attributes
Operations
Class name

Note:
➢ The UML gives you the option of indicating
additional information for attributes. In the
icon for the class, you can specify a type for
each attribute's value.
➢ Possible types include string, floating point
number, integer, and Boolean (and other
enumerated types).
➢ To indicate a type, use a colon to separate
the attribute name from the type. You can
also indicate a default value for an attribute.
Attributes
Operations
Class name

➢ Note
You can specify additional properties of
the attribute within curly brackets { }.
For example, the property {readOnly}
means that the attribute value cannot
be changed once it has been initialized.
The specification of a forward slash
before an attribute name indicates that
the value of this attribute is derived
from other attributes.
Ex.
Default value pw123
Read Only ssNo
15

Note: Attribute visibility, who is permitted to access the attribute
Tip: Expose only as much as needed and hide everything else.
16

Specification of Classes: Different Levels of Detail
coarse-grained fine-grained
17

Example: Class Auction
18

2. Object Diagram
An object is an instance of a specific thing (Class). It
is a snapshot of the objects in a system at a point in
time. It is useful to show examples of objects
connected together.
Example: an object diagram could show that a
professor Henry Foster (henryFoster) teaches the
courses Object-Oriented Modeling (oom) and Object-
Oriented Programming (oop).

Note: From Object to Class
➢Individuals of a system often have identical
characteristics and behavior.
➢A class is a construction plan for a set of similar
objects of a system.
➢Objects are instances of classes.
➢Attributes: structural characteristics of a class
➢Different value for each instance (= object)
➢Operations: behavior of a class
➢Identical for all objects of a class
→ not depicted in object diagram
Class
Object of that class
20

Object Diagram: Visualization
Object name Class
Attribute Current value
Anonymous objects
= no object name
In the object diagram, an
object is shown as a rectangle
which can be subdivided into
multiple compartments. The
first compartment always
contains information in the form
objectName:Class. This
information is centered and
underlined.
21

Example: Object Diagram
➢ An Object Diagram contains three student objects: helenLewis, mikeFox, and
paulSchubert. The first name and the last name of the object helenLewis
are Helen and Lewis respectively.
➢ We also know the date of birth and matriculation number for each of these objects.
➢ The system contains the three courses oom (Object-Oriented Modeling), iprog
(Introduction to Programming), and db (Databases).
➢ The course iprog takes place in lecture hall lh1 and the course db takes place in lecture hall
lh2. There is no corresponding information for oom.
➢ Student helenLewis attends the two courses oom and iprog.
➢ Student mikeFox also attends iprog; course db is attended only by student paulSchubert
(at least, among these three students).

Object Diagram: Example, cont.
Link
23

Association
➢ Relationships between classes model
possible relationships, known as
Association, between instances of the
classes. They describe which classes are
potential communication partners.
➢ If their attributes and operations have
the corresponding visibilities, the
communication partners can access each
other’s attributes and operations.
➢ A class diagram can be viewed as a
graph in which the classes represent the
nodes and the associations represent
the edges.

Association visualization
Connects instances of two classes with one another
Association name Reading direction
Non-navigability
Multiplicity
Role
Visibility
Navigability
25

Example: Generalization
(Inheritance)
➢ Generalization refers to a type of
relationship wherein one
associated class is a child of
another by virtue of assuming the
same functionalities of the parent
class.
➢ In other words, the child class is a
specific type of the parent class.
To show inheritance in a UML
diagram, a solid line from the child
class to the parent class is drawn
using an unfilled arrowhead.
26

Example: Aggregation
➢ Aggregation refers to the formation
of a particular class as a result of
one class being aggregated or built
as a collection. For example, the
class “library” is made up of one or
more books, among other materials.
➢ In aggregation, the contained
classes are not strongly dependent
on the lifecycle of the container. In
the same example, books will remain
so even when the library is
dissolved.
➢ To show aggregation in a diagram,
draw a line from the parent class to
the child class with a diamond shape
near the parent class.
27

Multiplicity
28

Link
A line connects two objects, the name of the link is underlined.
29

Example: Associations (Auction class)
30

Example: University Information
System (UIS)
31

Example: University Information System (UIS)
➢A university consists of multiple faculties which are composed of various
institutes. Each faculty and each institute has a name. An address is known
for each institute.
➢Each faculty is led by a dean, who is an employee of the university.
➢The total number of employees is known. Employees have a social security
number, a name, and an email address. There is a distinction between
research and administrative personnel.
➢Research associates are assigned to at least one institute. The field of study
of each research associate is known. Furthermore, research associates can
be involved in projects for a certain number of hours, and the name, starting
date, and end date of the projects are known. Some research associates hold
courses. Then they are called lecturers.
➢Courses have a unique number (ID), a name, and a weekly duration in hours.
32

UIS Modeling: Step 1: Identifying Classes
▪ A university consists of multiple faculties which are composed of
various institutes. Each faculty and each institute has a name. An
address is known for each institute.
▪ Each faculty is led by a dean, who is an employee of the university.
▪ The total number of employees is known. Employees have a social
security number, a name, and an email address. There is a
distinction between research and administrative personnel.
▪ Research associates are assigned to at least one institute. The
field of study of each research associate is known. Furthermore,
research associates can be involved in projects for a certain
number of hours, and the name, starting date, and end date of the
projects are known. Some research associates hold courses. Then
they are called lecturers.
▪ Courses have a unique number (ID), a name, and a weekly duration
in hours.
33

UIS Modeling: Step 2: Identifying Attributes
▪ A university consists of multiple faculties which are composed of
various institutes. Each faculty and each institute has a name. An
address is known for each institute.
▪ Each faculty is led by a dean, who is an employee of the university.
▪ The total number of employees is known. Employees have a social
security number, a name, and an email address. There is a distinction
between research and administrative personnel.
▪ Research associates are assigned to at least one institute. The field
of study of each research associate is known. Furthermore,
research associates can be involved in projects for a certain number
of hours, and the name, starting date, and end date of the projects
are known. Some research associates hold courses. Then they are
called lecturers.
▪ Courses have a unique number (ID), a name, and a weekly duration in
hours.
34

UIS Modeling: Step 3: Identifying Relationships
▪ Three kinds of relationships:
▪ Association
▪ Generalization
▪ Aggregation
▪ Indication of a generalization
▪ “There is a distinction between research
and administrative personnel.”
▪ “Some research associates hold courses. Then they
are called lecturers.”
35

UIS Modeling: Step 3: Identifying Relationships, cont.
“A university consists of multiple faculties which are composed of various
institutes.”
Composition to show existence
dependency
36

“Each faculty is led by a dean, who is an employee of the university”
In the leads-relationship, the
Employee takes the role of a dean.
37

“Research associates are assigned to at least one institute.”
Shared aggregation to show that ResearchAssociates
are part of an Institute,
but there is no existence dependency
38

“Furthermore, research associates can be involved in projects for a certain
number of hours.”
Association class enables to store
the number of hours for every
single Project of every single
ResearchAssociate
39

“Some research associates hold courses. Then they are called lecturers.”
Lecturer inherits all characteristics,
associations, and aggregations from
ResearchAssociate.
In addtion, a Lecturer has an association
teaches to Course.
40

UIS Example–Complete Class Diagram
41

Assignment
Case Study: Basketball game
Suppose you're an analyst building a model of the game of basketball, and you're interviewing a
coach in order to understand the game. The conversation might go something like this:
Analyst: "Coach, what's basketball all about?"
Coach: "The goal of the game is to shoot the ball through the basket and score more points than
your opponent. Each team consists of five players: two guards, two forwards, and a centre. Each
team advances the ball toward the basket with the objective of ultimately shooting the ball
through the basket."
Analyst: "How does it advance the ball?"
Coach: "By dribbling and passing. But the team has to take a shot at the basket before the shot
clock expires."
Analyst: "Shot clock?"
Coach: "Yes. That's 24 seconds in the pros, 30 seconds in international play, and 35 seconds in
college to take a shot after a team gets possession of the ball."
42

Case Study, Basketball game, cont.
Analyst: "How does the scoring work?"
Coach: "Each basket counts two points, unless the shot is from behind the three point line. In that
case, it's three points. A free throw counts one point. A free throw, by the way, is the penalty a
team pays for committing a foul. If a player fouls an opponent, play stops and the opponent gets to
shoot at the basket from the free throw line."
Analyst: "Tell me a little more about what each player does."
Coach: "The guards generally do most of the dribbling and passing. They're typically shorter than
the forwards, and the forwards are usually shorter than the centre. All the players are supposed
to be able to dribble, pass, shoot, and rebound. The forwards do most of the rebounding and
intermediate range shooting, while the centre stays near the basket and shoots from close range."
Analyst: "How about the dimensions of the court? And by the way, how long does a game last?"
Coach: "In international play, the court is 28 meters long by 15 meters wide. The basket is 10 feet
off the ground. In the pros, a game lasts 48 minutes, divided into four 12 minute quarters. In
college and international play, it's 40 minutes divided into two 20 minute halves. A game clock
keeps track of the time remaining."
43

Case Study, Basketball game , cont.
Notes:
➢ This could go on and on, but let's stop and take stock of where we are.
➢ Here are the nouns you've uncovered: ball, basket, team, players, guards, forwards, center,
shot, shot clock, three point line, free throw, foul, free throw line, court, and game clock.
➢ Here are the verbs: shoot, advance, dribble, pass, foul, and rebound.
➢ You also have some additional information about some of the nouns—like the relative heights of
the players at each position, the dimensions of the court, the total amount of time on a shot
clock, and the duration of a game.
➢ Your own common sense knowledge could come into play as you generate a few attributes on your
own. For example, that the ball has attributes like volume and diameter.
➢ Using this information, you can create a diagram. It has to show the classes, and provides some
attributes, operations, and constraints. The diagram also shows responsibilities. You could use
this diagram as a foundation for further conversations with the coach, to uncover more
information.
44

3. Scenario and Use Case Diagram
45
Consider a Web based online Store, we might
have a Buy a Product scenario that would
say this :
➢ The customer browses the catalogue and
adds desired items to the Shopping
basket.
➢ When the customer wishes to pay, the
customer describes the shipping and
credit card information and confirms the
sale .
➢ The System Checks the authorization on
the credit card and confirms the sale
both immediately and with a follow up e-
mail.

The scenario, cont.
➢ This scenario is one thing that can
happen.
For example:
➢ The credit card authorization might fail,
and this would be a separate scenario .
➢ In another case, you may have a regular
customer for whom you don't need to
capture the shipping and credit card
information, and this is a third scenario .
46

The scenario
.
All these scenarios are different yet similar.
The essence of their similarity is that in all
these three scenarios, the user has the same
goal : to buy a product .
The user doesn't always succeed, but the
goal remains. This user goal is the key to use
cases :
A use case is a set of scenarios tied
together by a common user goal.
47

The Use Case Diagram
The idea is to get system users and scenarios involved in the early
stages of system analysis and design
Use cases represent what the customer wants the system to do, that
is, the customer’s requirements of the system.
At a very high abstraction level, the use cases show what the future
system is for.
Technically
It expresses what a system should do but does not address any
realization details such as data structures, algorithms, etc.
48

Use Case Analysis (How to identifying actors and use cases?)
1. Client interviews: lead to the initial class diagram, gives some idea of
the area we are working in and a familiarity with the terms we will
using.
2. Interview (Preferably in group): ask them to tell you everything they
would do with the system you are getting ready to design.
Here their answers form a set of candidates use cases.
3. Derive a list of all the actors who will initiate and benefit from
the use cases.
49

50
Exercise: Questions for identifying
Actors
➢ Who uses the main use cases?
➢ Who needs support for their daily work?
➢ Who is responsible for system
administration?
➢ What are the external devices/
(software) systems with which the
system must communicate?
➢ Who has an interest in the results of
the system?

51
Questions for identifying use cases,
cont.
➢ What are the main tasks that an actor
must perform?
➢ Does an actor want to query or even
modify information contained
in the system?
➢ Does an actor want to inform the system
about changes in other systems?
➢ Should an actor be informed about
unexpected events within the system?

Notes
The use case is applied during the entire analysis and design
process,
1st: They help with the design of a system’s user interface.
2nd : They help developers make programming choices.
3rd : They provide the basis for testing the newly constructed
system.
4th : They can be used to document the functionality of an
existing system.
52

Representing a Use Case Diagram
➢ The system is depicted as a box .
➢ A use case is depicted as an ellipse, its
name appears inside the ellipse or just below
it.
➢ An actor is depicted as a stick figure or by
a freely definable symbol The actors name
appears just below the actor
➢ The initiating actor (the primary) is on the
left of the use case and the receiving actor
(the secondary) is on the right.
➢ An association line (a solid line) connects an
actor to the use case.
53

54
Describing Use Cases
➢ To ensure that even large use case diagrams
remain clear, it is extremely important to select
short, concise names for the use cases.
➢ When situations arise in which the intention
behind the use case and its interpretation are
not clear, you must also describe the use cases.
➢
It is important to ensure that you describe the
use cases clearly and concisely, as otherwise
there is a risk that readers will only skim over
the document.

55
Describing Use Case, Template *
✓ Name
✓ Short description
✓ Precondition: prerequisite for successful execution
✓ Postcondition: system state after successful execution
✓ Error situations: errors relevant to the problem domain
✓ System state on the occurrence of an error
✓ Actors that communicate with the use case
✓ Trigger: events which initiate/start the use case
✓ Standard process: individual steps to be taken
✓ Alternative processes: deviations from the standard process
* A. Cockburn. Goals and Use Cases. Journal of Object-Oriented Programming, 10(5):35–40, 1997.

Describing Use Case:
Example: Reserve Lecture Hall
56

Relationships in Use Case
57

Relationships: Include
If a use case A includes a use case B, represented
as a dashed arrow from A to B labelled with the
keyword «include», the behaviour of B is integrated
into the behaviour of A. Here, A is referred to as
the base use case and B as the included use case.
The base use case always requires the behaviour of
the included use case to be able to offer its
functionality. In contrast, the included use case can
be executed on its own. The use of «include» is
analogous to calling a subroutine in a procedural
programming language.
58

Relationships: extend
If a use case B is in an «extend» relationship
with a use case A, then A can use the
behaviour of B but does not have to.
Use case B can therefore be activated by A in
order to insert the behaviour of B in A. Here
A is again referred to as the base use case
and B as the extending use case. An «extend»
relationship is shown with a dashed arrow
from the «extend» extending use case B to
the base use case A. Both use cases can also
be executed independently of one another
59

Case Study, A Banking App
➢ The system
➢ The Actors
➢ Use Cases
➢ The Relationships
60

Banking App., cont.
Login Check Balance Transfer Fund Make Payment
61

Mobile App., cont.
62

More use cases
Verify the password Error message for
incorrect password
Verify sufficient
fund
Pay from saving
or by check
63

Banking App., Cont.
Include and extend relationships
64

Banking App., Cont.
Generalization relationship
65

Banking App., Extension point
66

Banking App., Use Case Diagram
67

68
Remarks
➢ The use case diagram provides only a few language elements. At first glance,
this diagram seems to be extremely simple to learn and use. In practice,
however, the use case diagram is an extremely underestimated diagram. The
content of a use case diagram express the expectations that the customer
has of the system to be developed. The diagram documents the
requirements the system should fulfil. This is essential for a detailed
technical design.
➢ If use cases are forgotten or specified imprecisely or incorrectly, in some
circumstances the consequences can be extremely serious: the development
and maintenance costs increase, the users are dissatisfied, etc.

69
4. Activity Diagram
➢ Activity diagrams: shows the steps in an
operation or process.
➢ It is an integral part of system analysis
➢ An activity diagram can be used to represent
the sequential steps of a use case or an
activity itself can describe the
implementation of a use case including the
main sequence and all the alternative
sequences.

70
Visualizing Activity Diagram
➢ Action: A step in the activity wherein the users
or software perform a given task. Actions are
symbolized with round-edged rectangles.
➢ Decision node: A conditional branch in the flow
that is represented by a diamond. It includes a
single input and two or more outputs.
➢ Control flows: Another name for the connectors
that show the flow between steps in the diagram.
➢ Start node: Symbolizes the beginning of the
activity. The start node is represented by a black
circle.
➢ End node: Represents the final step in the
activity. The end node is represented by an
outlined black circle.

71
Example: Ticket Vending Machine
Activity Diagram describing behaviour of the Purchase Ticket use case.
➢ Activity is started by Commuter actor who needs to buy a ticket.
➢ Ticket vending machine will request trip information from Commuter. This
information will include number and type of tickets, e.g. whether it is a monthly
pass, one way or round ticket, route number, destination or zone number, etc.
➢ Based on the provided trip info ticket vending machine will calculate payment
due and request payment options. Those options include payment by cash, or by
credit or debit card.
➢ If payment by card was selected by Commuter, another actor, Bank will
participate in the activity by authorizing the payment.

72
Example: Ticket Vending Machine, cont.
➢ After payment is complete, ticket is dispensed to the
Commuter. Cash payment might result in some change
due, so the change is dispensed to the Commuter in this
case.
➢ Ticket vending machine will show some "Thank You"
screen at the end of the activity.

73
Example:
Ticket
Vending
Machine,
cont.
swimlane

74
Activity Diagram
Use cases show what your system should
do. Activity diagrams allow you to specify
how your system will accomplish its goals.

75
Example: Create a new blog account
Elaborating the use case ( what ) by an activity diagram (How).

76
Use case
description
Use case name Create a new blog account
Goal in context A new or existing author requests a new blog account
Preconditions The system is limited to recognizing authors, and so the author needs to have
appropriate proof of identity
Successful end
condition
A new blog account is created for the author
Failed end condition The application for the new account is rejected
Primary actor Blog administrator
Secondary actor Author credential database
Trigger The blog admin asks the CMS to create new blog account
Main flow step Action
1
2
3
4
5
6
The blog admin asks the system to create a new blog
The blog admin select an account type
The blog admin enters the author's detail
The author detail is verified using the author credential database
The new blog account is created
A summery of the new account details are emailed to the author

77
Use case vs
Activity
diagrams

78
Example: Activity diagram
This activity diagram shows
the process of logging into a
website, from entering a
username and password to
successfully logging in to the
system.

79
Concurrent paths
Signals
Activity diagrams:
More symbols

80
Example,Check-In in Airport Activity diagrams:
Concurrent paths

81
Example:
Business
process of
meeting a new
client
swimlane

82
Note:
➢ A business process is a set of coordinated tasks that
achieve a business goal, such as shipping customers’
orders.
➢ Some business process management (BPM) tools allow
you to define business processes using activity
diagrams and then execute them.
➢ This allows you to define and execute, for example, a
payment approval process where one of the steps
invokes a credit card approval web service using an
easy graphical notation such as activity diagrams.

83
5. Sequence diagrams
➢ Model the interactions between objects in a single
use case. They illustrate how the different parts
of a system interact with each other to carry out a
function, and the order in which the interactions
occur when a particular use case is executed.
➢ Sequence diagrams show the behaviour of objects
and actors. As a result, the concept of time, as well
as dependencies between objects, appears in
sequence diagrams. This, in turn, enables sequence
diagrams to show “what happens” in the system.

84
Visualizing the sequence diagram
In a sequence diagram, the interaction
partners are depicted as lifelines.
A lifeline is shown as a vertical, usually
dashed line that represents the lifetime
of the object associated with it.
At the top end of the line is the head of
the lifeline, a rectangle which contains an
expression in the form roleName:Class
Synchronous message
Return message
Asynchronous message

85
Remark
Sequence, use case and activity diagrams
The entire dynamic modelling with sequence
diagrams is, however, within a given time frame.
Thus, sequence diagrams show a “snapshot” of
events. They are not to be used to model end-to-
end messaging (which is the purview of use case and
activity diagrams)

86
Remarks
An interaction specifies how messages and data are
exchanged between interaction partners. The interaction
partners are either human, interaction partner such as
lecturers or students, or non-human, such as a server, a
printer, or executable software.

87
Example: AT machine

88
Example: The Soda machine
Assume that The class contains three components—a front, a
register, and a dispenser.
In your model of the soda machine,
the front
➢ Accepts selections and cash
➢ Displays prompts like "Out of selection" and "Use correct change“
➢ Receives change from the register and makes it available to the
customer
➢ Returns cash
➢ Receives a can of soda from the dispenser and makes it available
to the customer

89
Example, cont.
The register
➢ Gets the customer's input (that is, the
selection and the cash) from the front
➢ Updates its cash reserve
➢ Checks for change
The dispenser
➢ Checks the availability of a selection
➢ Releases a can of soda

90
Example, cont.
The class diagram
(aggregation relationship)

91
Example, cont.
The Use Case diagram

92
Example, cont. The sequence diagram for the use case “Buy
soda”
Scenario for "Buy soda" use case:
The customer inserts the correct change, and the customer's
selection is available. The sequence goes like this:
1. The customer inserts the money into the money slot in the front
of the machine and makes a selection.
2. The money travels to the register, which updates itself.
3. Because this is the best case scenario, an availability check
reveals the soda is in stock, and the register has the dispenser
release the soda to the front of the machine.

93
Example, cont.
Scenario 1,
correct change

94
Example, cont.
scenario 2: (sold out
scenario)

95
Example, cont.
Scenario 3
(Correct change)

96
Example, cont.
scenario 4:
(Incorrect Change
scenario)

97
Example, cont.
A generic scenario
(put all together)

98
Example,cont. Modified scenarios
Consider a telecommunications technology enables customers to use their cell phones
to buy from soda machines.
How would you model this interaction in a sequence diagram? What would you have to add?
Through a wireless connection, the CellPhone interfaces to the Front.
The Front is smarter than before and now has the ability to process information from the
Customer.
In this version it acquires an additional capability—the real focus here:
It creates a transaction record of the interaction between the customer and the soda
machine. The machine uses this record to charge the customer's credit card for the soda.
The sequence diagram has to visualize the creation of the transaction record.

99
The modified class diagram

100
Modified scenario 1

101
Modified scenarios, cont.
Object destruction
To show an object being
destroyed, place a large, bold
X at the bottom of its
lifeline.
An object destroying itself
(may be because a certain
amount of time has passed).
An object can instruct another
object to destroy itself. It
does this by sending a message
whose label is a «destroy»
keyword.

102
The sequence
diagram Framing

103
The sequence
diagram Using
Framing technique,
cont.
(ref -reference- type
framing)

104
The sequence
diagram Using
Framing technique,
cont.
Note:
The interaction occurrence is a
special case of an interaction
fragment. There are different
interaction fragments (ex. Alt-
alternative- (conditional), par
(parallel)) with different
applications.

105
Interaction Overview
Diagram
The interaction
overview diagram is an
activity diagram in
which each activity is a
separate sequence
diagram.

Case Study:
Software
Architecture and
Design: Note Taking
App

Note taking Application

Functional Requirements
➢ We need to build a note-taking app.
➢ Users can create and edit text-based
notes. A note may also include images or
hand-drawn sketches.
➢ Sensitive notes should be protected
from prying eyes using a password.
➢ The app automatically uploads changes to
pre-configured servers. We should
support all major platforms: Dropbox,
iCloud and Google Drive.

Non-functional Requirements
➢ Release our app for iOS first. We'll support
iOS 14 and iOS 15 versions.
➢ The app needs to run on the iPhone and the
iPad and Apple Mac computers well.
➢ We will create a dedicated support web site
and we'll also include the link in the app's
description and it’s "About" page.

Epics or multiple user stories that describe
common functionality.
Epic number one: "Note creation and
editing".
1. As a user, I want to create and edit notes
so that I can quickly jot down my
thoughts.
2. As a user, I want to attach photos to a
note so that I can keep my memories in
one place.
3. As a user, I want to add handwritten
sketches so that I can insert funny toons
into my notes.

Epic number two: "Privacy".
As a user, I want to create private notes so
that only I can access them.
As a user, I want to protect my sensitive notes
with a password.

Epic number three: "Sync'ing to Cloud
Server".
1. As a user, I want to sync my notes across
my iOS devices, so that my data is up-to-
date on all of them.
2. As a user. I want my notes automatically
uploaded to cloud servers (Dropbox, Google
Drive or iCloud), so that I have a backup of
all my data.

Let’s go ahead and map these user
stories to actual use case, class and
sequence diagrams

Use Case Diagram
The actor is the user of this app.
Next, I add the use-cases: “Create
Note” and “Edit Note”.
Epic #1: Note creation and
editing
-As a user, I want to create
and edit notes so that I can
quickly jot down my
thoughts.
(next slide)
- As a user, I want to attach
photos to a note so that I
can keep my memories in one
place.
- As a user, I want to add
handwritten sketches so
that I can insert funny
drawings into my notes.

We also need an “Attach Photo” and
“Add Handwritten Sketch” use case.
Now, these are not standalone use-
cases. We can’t attach a photo or add a
handwritten sketch without creating or
editing a note. Thus, I represent them
as included in the “Create Note” and
“Edit Note” use-cases.

We need an actor; it’s the user as usual. The creation of
private notes is a special case of note creation. We can
represent the “Create Private Note” as an extension of
the regular “Create Note” use-case.
Epic #2: Privacy -
Protecting User Data -
As a user, I want to
create private notes so
that only I can access
them.
- As a user, I want to
protect my sensitive
notes with a password.

The third epic is about synchronizing data with a server.
This server is another actor, a non-human one. W’ll
represent it on the right side of the diagram using this
special format.
Epic #3: Syncing to cloud
servers - As a user, I want to
sync my notes across my iOS
devices so that my data is up-
to-date on all of them. - As a
user, I want my notes
automatically uploaded to
cloud servers (Dropbox,
Google Drive or iCloud) so that
I have a backup of all my data.

Use-
Case
Diagram

Class Diagram
Let’s create the static structure of our system. We’ll
identify the main classes and the relationships between
them. Our app is about taking notes. So, we’ll need a class
that represents a Note.
A Note has a text. So, I add a private attribute called
“text” of type String. As you may recall, we should not
expose class properties. Hence “text” is private.
We also need an “Attach Photo” and “Add Handwritten
Sketch” use case. A Note needs to have an attribute for the
photos and one for the handwritten sketches. I’m using the
plural form: photos and sketches. That is, a Note may have
many photos and hand-drawn sketches attached to it. So, I’ll
make these attributes of List type.

Class Diagram, cont.
The photos attribute is a List of Image type. I
introduce an Image class, which can later be
changed to an existing type. The point is to
identify the potential classes that play a role in our
system. Similarly, we need a list of sketches. The
Sketch class represents our handdrawn sketches.
The Note class needs some methods:
- addImage(image: Image) to attach a new image
- getImages(): List to retrieve all images of a
Note.
- addSketch(sketch: Sketch)
- getSketches(): List to get the hand-draw
sketches of a Note

Remarks
➢ We don’t know anything yet about the underlying format for the
Image and the Sketch class. And that’s fine. We need to
abstract things first and iteratively refine it.
➢ At the end, we may store our hand-drawn sketches either as a
JPEG image. But requirements may change and we’ll need a vector
format, so we’ll use PDF. Again, we should not go into such details
at this stage or we may easily get stuck. This phenomenon is well-
know and it even has a name: analysisparalysis.
➢ Start with a few broad strokes instead of overthinking and
spending too much time on figuring out the details right away.
Then try to get more specific as you understand more.

Now, let’s think about the relationships between these classes? Is there
an association between the Note and the Image class? Or rather a
dependency?
The Note class has an attribute that refers to the Image and the
Sketch class. It did not receive instances of these classes as parameters
to a method, so it’s not a dependency relationship.
So, is it an association? Yes, it is.
But let’s dig a bit deeper. What happens when we delete a Note object
with its images and sketches? They will be destroyed, too. It doesn’t
make sense to keep them if the user decides to remove the Note. That
means that the images and the sketches live and die with the Note
object. As you may recall, this is the “part-of ” relationship called
composition.
Now, an Image doesn’t need to know about the Note. Nor does the
Sketch. So, these are directed relationships.

Based on the second epic, we need a specialized
Note that holds sensitive data
This note shares most of the attributes and
behavior associated with the Note class. This
looks like a perfect candidate for inheritance.
In addition to the inherited attributes, it has a
property called passwordHash. Storing the
password is insecure. Instead, we store the
password’s hash value. The hash is generated
using a one-way hashing algorithm from the
password. The password can’t be reconstructed
from its hash value.

For the hashing algorithm, I’m
going to define a Crypto class.
It provides the public hash()
method that takes a String as
input and returns its hash
value.
The SecureNote is going to
rely on the Crypto utility class
to create the password hash. I
indicate this as a dependency
between the SecureNote and
the Crypto class.

Next, we need a class that’s responsible for storing the notes and their
associated data in the local persistence. We don’t want to be too specific at
this point as we haven’t defined yet what local persistence means. It could be
the filesystem or an SQLite database. We could also choose CoreData. That’s
not important at this point, so we’ll use abstraction.
Instead of specifying a concrete file or database manager, We are going to
create an interface that defines a couple of methods. Let’s call it
LocalPersistence. It’s an interface: it declares the method signatures that
need to be implemented, but it provides no functionality. The implementation
classes will be responsible for implementing these methods.

The LocalPersistence declares the following interface:
- getNotes(): List
retrieves all notes from the local persistence
- save(note: Note)
stores a note locally
- update(note: Note)
updates a note that has been persisted
- delete(note: Note)
removes a note from the local persistence
All these methods have parameters or return values of type Note. Thus, we can draw a
dependency relationship between the LocalPersistence interface and the Note class.
Let’s say that we decide to store our notes in the file system. The FileManager implements the
methods declared in LocalPersistence. We use the realization relationship to show that.

Similarly, w’ll create an interface for the cloud syncing
feature.
The NetworkController interface declares the methods
that take care of the networking-related operations:
- fetchNotes(): List<node>: fetches all notes from the
server
- upload(note: Note) : uploads a new note to the server
- refresh(note: Note) : updates the note that has been
uploaded
- remove(note: Note) : deletes a note from the server
Networking is slow, so these should be implemented as
asynchronous operations.

Class
Diagram

Analyzing the behavior
Sequence Diagram
We are going to walk through the creation of the
sequence diagram for one specific scenario: adding
a new note. We’ll be focusing on the flow of note
creation.
We try to answer the following question:
Which objects are involved and what messages are
sent between them?

Sequence Diagram, cont.
The user can initiate the note creation by pressing a
button on the application’s user interface. So, we need a
view instance first that represents the button.
The button receives the user input and triggers and event
that’s intercepted by a controller object.
Note:
Having separate view and controller objects stands at the core
of a well known architectural design pattern called Model-View-
Controller. The view displays data and receives user input. The
controller triggers actions based on events received from its
view and processes the data to be displayed.

In our scenario, the controller
triggers the creation of a newNote
instance. We’ll use a create message
rather than a regular one. A Note
object gets created.

Next, the user fills the note’s
details and presses the save
button. This will trigger two
actions: saving to the local
persistence and uploading the
new note to the cloud.
Local persistence is managed by
the FileManager object. We
invoke the save(note: Note)
method. File operations are
slow, thus We call the save
method asynchronously. To
avoid misunderstanding, We
mark the message explicitly as
async.

Sequence Diagram,
cont.
For the upload part, we
need an OnlineManager
instance. The
upload(note: Note)
method gets executed in
the background, too.

The saving to local
persistence and uploading
the new Note to the cloud
are asynchronous, so they
return instantly, without
blocking the caller.
Eventually, they return to
signal either success or
failure.

Sequence
Diagram

Assignment
Add State Diagram to the design of the
note taking application.

Reading list
Suriya Sundaramurthy, UML Diagramming, A Case Study Approach, Tylor and
Francies, 2022.
Ajit, S., and Anamika, 2022. Object Oriented Modeling And Design Using UML, Self
Published.
Joseph Ingeno, Software Architecture’s Handbook, Packt Publishing Ltd., 2018
Website resource:
https://www.omg.org
www.hillside.net

Questions?

Software Architecture and Design-Ch-2-v6.pdf

More Related Content

Similar to Software Architecture and Design-Ch-2-v6.pdf (20)

More from Salahaddin University-Erbil, University of Kurdistan Hewler (9)

Recently uploaded (20)

Software Architecture and Design-Ch-2-v6.pdf