Software

Engineering
SPRING 2024-2025
CHAPTER 5 – DESIGN MODELS
Week 10: Lecture 9 & 10

• Lecture Textbook Reference

Chapter 05: System Modeling
Ian Sommerville,
Software Engineering, 9th Edition
Objectives
Contents
THE SOFTWARE PROCESS

• A structured set of activities required to develop a software system.

• Many different software processes but all involve:
• Specification – defining what the system should do;
• Design and implementation (Development) – defining the organization
of the system and implementing the system;
• Validation (Testing) – checking that it does what the customer wants;
• Maintenance & Evolution – changing the system in response to
changing customer needs.
• A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.
Modeling

• A model is an abstraction of a system.

• Abstraction allows us to ignore unessential details
• Why building models?
• To reduce complexity
• To test the system before building it
• To communicate with the customer
• To document and visualize your ideas

 For instance, architectural models can highlight potential bottlenecks in scalability or

performance, allowing developers to address them at the design stage itself.
 System perspectives
SDD  Viewpoints as called on IEEE standards

• An external perspective, where you model the context or environment of the system.
• An interaction perspective, where you model the interactions between a system and
its environment, or between the components of a system.
• A structural perspective, where you model the organization of a system or the
structure of the data that is processed by the system.
• A behavioral perspective, where you model the dynamic behavior of the system and
how it responds to events.

Chapter 5 System Modeling 8

UML diagram types

• Context diagrams, provides an overview of a system by showing its boundaries, the entities
that interact with it, and the interactions between the system and its external entities.
• Activity diagrams, which show the activities involved in a process or in data processing.
• Use case diagrams, which show the interactions between a system and its environment.
• Sequence diagrams, which show interactions between actors and the system and between
system components.
• Class diagrams, which show the object classes in the system and the associations between
these classes.
• State diagrams, which show how the system reacts to internal and external events

Chapter 5 System Modeling 9

UML TOOLS
• Some UML tools can generate code once UML diagram is
completed.
• Some UML tools are sketching tools.
• Rational Rose is one of the most popular software for UML creation
(IBM).
• Bouml is an open source software. It supports python, C++, java.
• Visio is a sketching tool.
Context models

Chapter 5 System Modeling 12

Context models
• Context models are used to illustrate the operational context of a system -
they show what lies outside the system boundaries.
• Social and organisational concerns may affect the decision on where to
position system boundaries.
• Architectural models show the system and its relationship with other
systems.
• A system context diagram (SCD) also called A level 0 data flow
diagram(DFD)is a diagram that defines the boundary between the system,
or part of a system, and its environment, showing the entities that interact
with it.
• This diagram is high-level abstract view of the system.

Chapter 5 System Modeling 13

System boundaries

• System boundaries are established to define what is inside

and what is outside the system.
• They show other systems that are used or depend on the system
being developed.
• The position of the system boundary has a profound effect
on the system requirements.

Chapter 5 System Modeling 14

The context of the Mentcare system

Context Model 1
Chapter 5 System Modeling 15
ATM System Context Diagram

Context Model 2
Chapter 5 System Modeling 16
 Test Your Self
• The JazzN!ghts festival in Zurich, an annual jazz event since 1986, is revolutionizing its ticket-selling
approach. Previously exclusive to two events agencies, the festival is embracing a modernized
system. Tickets will now be available through three distinct channels: the traditional agencies, the
festival's website in electronic format, and via collaboration with Swiss railway company SBB. All
channels will share a unified ticket database to prevent duplication in sales. Additionally, the festival
aims to establish a partnership with SBB to offer combined tickets covering festival entry and train
travel at reduced rates across Switzerland. The system will undergo expansion to support multiple
languages—German, English, French, and Italian— catering to a diverse audience. To ensure secure
online transactions, SecurePayment Inc. will manage the online payment service. On-site, attendees
will utilize touch screen terminals for self-check-ins, receiving electronic-chipped bracelets facilitating
cashless purchases of snacks and beverages, an initiative by WristSolutions Inc.
Test Your Self
Process Perspective

Chapter 5 System Modeling 19

Process perspective

• Context models simply show the other systems in the

environment, not how the system being developed is used
in that environment.
• Process models reveal how the system being developed is
used in broader business processes.
• UML activity diagrams may be used to define business
process models.

Chapter 5 System Modeling 20

Activity Diagram Symbols
Activity Diagram Symbols (cont.)
Activity Diagram Symbols (cont.)
Activity Diagram Symbols (cont.)
 Login

Activity Model 1
Document Management System

Activity Model 2
Activity Model 3
 Process model of involuntary detention

Activity Model 4 Chapter 5 System Modeling 28

An activity model of the insulin pump’s operation

Chapter 5 System Modeling 29

Interaction models

Chapter 5 System Modeling 30

Interaction models

• Modeling user interaction is important as it helps to identify user

requirements.
• Modeling system-to-system interaction highlights the
communication problems that may arise.
• Modeling component interaction helps us understand if a proposed
system structure is likely to deliver the required system performance
and dependability.
• Use case diagrams and sequence diagrams may be used for
interaction modelling.

Chapter 5 System Modeling 31

Use case modeling

• Use cases were developed originally to support

requirements elicitation and now incorporated into the
UML.
• Each use case represents a discrete task that involves
external interaction with a system.
• Actors in a use case may be people or other systems.
• Represented diagrammatically to provide an overview of
the use case and in a more detailed textual form.

Chapter 5 System Modeling 32

Use Case Diagram
Objects
Relationships in Use Case Diagrams

1. Association between an actor and a use case

2. Generalization of an actor
3. Extend relationship between two use cases
4. Include relationship between two use cases
5. Generalization of a use case
Relationships in Use Case Diagrams
(cont.)
Association Between Actor and Use Case
An actor must be associated with at least one usecase.
An actor can be associated with multiple use cases.
Multiple actors can be associated with a single use case.
Relationships in Use Case Diagrams
(cont.)
Generalization of an Actor:
Generalization of an actor
means that one actor can
inherit the role of the other
actor.
 Relationships in Use Case Diagrams
(cont.)
• Extend Relationship Between Two
Use Cases
• The extending use case is dependent on the extended
(base) use case. In the below diagram the “Calculate
Bonus” use case doesn’t make much sense without the
“Deposit Funds” use case.
• The extending use case is usually optional and can be
triggered conditionally. In the diagram, you can see that
the extending use case is triggered only for deposits
over 10,000 or when the age is over 55.
• The extended (base) use case must be meaningful on
its own. This means it should be independent and must
not rely on the behavior of the extending use case.
Relationships in Use Case Diagrams
(cont.)
• Include Relationship
Between Two Use Cases
• Include relationship show that the
behavior of the included use case
is part of the including (base) use
case.
• The base use case is incomplete
without the included use case.
• The included use case is
mandatory and not optional.
Relationships in Use Case Diagrams
(cont.)
• Generalization of a Use Case
• This is similar to the generalization of an actor. The behavior of the ancestor is inherited
by the descendant. This is used when there is common behavior between two use cases
and also specialized behavior specific to each use case.
• For example, in the previous banking example, there might be a use case called “Pay
Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.
Transfer-data use case

• A use case in the Mentcare system

Chapter 5 System Modeling 40

 Tabular description of
the ‘Transfer data’ use-case
MHC-PMS: Transfer data
Actors Medical receptionist, patient records system (PRS)
Description A receptionist may transfer data from the Mentcase system to a
general patient record database that is maintained by a health
authority. The information transferred may either be updated personal
information (address, phone number, etc.) or a summary of the
patient’s diagnosis and treatment.

Data Patient’s personal information, treatment summary

Stimulus User command issued by medical receptionist
Response Confirmation that PRS has been updated
Comments The receptionist must have appropriate security permissions to
access the patient information and the PRS.

Chapter 5 System Modeling 41

 Use cases in the Mentcare system
involving the role ‘Medical Receptionist’

Chapter 5 System Modeling 42

Sequence diagrams

• Sequence diagrams are part of the UML and are used to model the interactions
between the actors and the objects within a system.
• A sequence diagram shows the sequence of interactions that take place during a
particular use case or use case instance.
• The objects and actors involved are listed along the top of the diagram, with a
dotted line drawn vertically from these.
• Interactions between objects are indicated by annotated arrows.

Chapter 5 System Modeling 43

Symbols of Sequence Diagram

• Lifeline Notation

• A lifeline notation with an actor element symbol is

used when the particular sequence diagram is owned
by a use case.
Symbols of Sequence Diagram (cont.)

• Lifeline Notation
• A lifeline with an entity element represents system data. For
example, in a customer service application, the Customer entity
would manage all data related to a customer.
Symbols of Sequence Diagram (cont.)

• Activation Bars
• The activation bar is the box placed on the lifeline. It is used to
indicate that an object is active (or instantiated) during an
interaction between two objects. The length of the rectangle
indicates the duration of the objects staying active.
Symbols of Sequence Diagram (cont.)

• Synchronous message
• a synchronous message is used when the sender waits for the
receiver to process the message and return before carrying on with
another message.

• Asynchronous message
 Symbols of Sequence Diagram (cont.)

• Asynchronous message
• An asynchronous message is used
when the message caller does not
wait for the receiver to process the
message and return before sending
other messages to other objects
within the system. The arrowhead
used to show this type of message
is a line arrow as shown in the
example below.
Symbols of Sequence Diagram (cont.)

• Return message
• A return message is used to
indicate that the message
receiver is done processing the
message and is returning
control over to the message
caller.
Symbols of Sequence Diagram (cont.)

• Participant Create message

Symbols of Sequence Diagram (cont.)

• Participant destruction
message
Symbols of Sequence Diagram (cont.)

• Reflexive message
• When an object sends a
message to itself, it is called
a reflexive message. It is
indicated with a message
arrow that starts and ends at
the same lifeline as shown in
the example below.
Symbols of Sequence Diagram (cont.)

• Alternatives
• The alternative combination
fragment is used when a
choice needs to be made
between two or more
message sequences. It
models the “if then else”
logic.
Symbols of Sequence Diagram

• Alternatives
• The alternative combination
fragment is used when a
choice needs to be made
between two or more
message sequences. It
models the “if then else”
logic.
How to Draw a Sequence Diagram

• A sequence diagram represents the scenario or flow of events

in one single use case.
• Then, before you start drawing the sequence diagram or decide
what interactions should be included in it, you need to draw
the use case diagram and ready a comprehensive description
of what the particular use case does.
How to Draw a Sequence Diagram (cont.)

• Before drawing the

sequence diagram, it’s
necessary to identify the
objects or actors that would
be involved in creating a new
user account. These would
be;
• Librarian
• Online Library Management
system
• User credentials database
• Email system
How to Draw a Sequence Diagram (cont.)

• Once you identify the objects, it is then important to write a

detailed description of what the use case does.
• Here are the steps that occur in the use case named ‘Create
New Library User Account’.
1. The librarian request the system to create a new online library
account
2. The librarian then selects the library user account type
3. The librarian enters the user’s details
4. The user’s details are checked using the user Credentials Database
5. The new library user account is created
6. A summary of the new account’s details is then emailed to the user
How to Draw a Sequence Diagram (cont.)
 Sequence
diagram for
Transfer Data

Chapter 5 System Modeling 61

Structural models

Chapter 5 System Modeling 62

Structural models

• Structural models of software display the organization of a system in

terms of the components that make up that system and their
relationships.
• Structural models may be static models, which show the structure of
the system design, or dynamic models, which show the organization
of the system when it is executing.
• You create structural models of a system when you are discussing
and designing the system architecture.

Chapter 5 System Modeling 63

 UML Class Diagram Examples of Common Scenarios | EdrawMax (edrawsoft.com)

Class diagrams

• Class diagrams are used when developing an object-oriented system model to

show the classes in a system and the associations between these classes.
• An object class can be thought of as a general definition of one kind of system
object.
• An association is a link between classes that indicates that there is some
relationship between these classes.
• When you are developing models during the early stages of the software
engineering process, objects represent something in the real world, such as a
patient, a prescription, doctor, etc.

Chapter 5 System Modeling 64

UML classes and association

Chapter 5 System Modeling 65

Classes and associations in the MHC-PMS

Chapter 5 System Modeling 66

The Consultation class

Chapter 5 System Modeling 67

Generalization

• Generalization is an everyday technique that we use to manage

complexity.
• Rather than learn the detailed characteristics of every entity that we
experience, we place these entities in more general classes
(animals, cars, houses, etc.) and learn the characteristics of these
classes.
• This allows us to infer that different members of these classes have
some common characteristics e.g. squirrels and rats are rodents.

Chapter 5 System Modeling 68

Generalization (cont.)

• In modeling systems, it is often useful to examine the classes in a system to

see if there is scope for generalization. If changes are proposed, then you do
not have to look at all classes in the system to see if they are affected by the
change.
• In object-oriented languages, such as Java, generalization is implemented
using the class inheritance mechanisms built into the language.
• In a generalization, the attributes and operations associated with higher-level
classes are also associated with the lower-level classes.
• The lower-level classes are subclasses inherit the attributes and operations
from their superclasses. These lower-level classes then add more specific
attributes and operations.

Chapter 5 System Modeling 69

A generalization hierarchy

Chapter 5 System Modeling 70

A generalization hierarchy with added detail

Chapter 5 System Modeling 71

Object class aggregation models

• An aggregation model shows how classes that are

collections are composed of other classes.
• Aggregation models are similar to the part-of relationship
in semantic data models.

Chapter 5 System Modeling 72

The aggregation association

Chapter 5 System Modeling 73

Behavioral models

Chapter 5 System Modeling 74

Behavioral models

• Behavioral models are models of the dynamic behavior of a system

as it is executing. They show what happens or what is supposed to
happen when a system responds to a stimulus from its environment.
• You can think of these stimuli as being of two types:
• Data Some data arrives that has to be processed by the system.
• Events Some event happens that triggers system processing.
Events may have associated data, although this is not always the
case.

Chapter 5 System Modeling 75

Data-driven modeling

• Many business systems are data-processing systems that are

primarily driven by data. They are controlled by the data input to the
system, with relatively little external event processing.
• Data-driven models show the sequence of actions involved in
processing input data and generating an associated output.
• They are particularly useful during the analysis of requirements as
they can be used to show end-to-end processing in a system.

Chapter 5 System Modeling 76

Order processing

Chapter 5 System Modeling 77

Event-driven modeling

• Real-time systems are often event-driven, with minimal data

processing. For example, a landline phone switching system
responds to events such as ‘receiver off hook’ by generating a dial
tone.
• Event-driven modeling shows how a system responds to external
and internal events.
• It is based on the assumption that a system has a finite number of
states and that events (stimuli) may cause a transition from one
state to another.

Chapter 5 System Modeling 78

State machine models

• These model the behaviour of the system in response to external

and internal events.
• They show the system’s responses to stimuli so are often used for
modelling real-time systems.
• State machine models show system states as nodes and events as
arcs between these nodes. When an event occurs, the system
moves from one state to another.
• Statecharts are an integral part of the UML and are used to represent
state machine models.

Chapter 5 System Modeling 79

State diagram of a microwave oven

Chapter 5 System Modeling 80

Microwave oven operation

Chapter 5 System Modeling 81

State Diagram of OS processes
States and stimuli for the microwave oven (a)
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows
the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
Display shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for five
seconds. Oven light is on. Display shows ‘Cooking complete’ while
buzzer is sounding.

Chapter 5 System Modeling 83

States and stimuli for the microwave oven (b)
Stimulus Description
Half power The user has pressed the half-power button.

Full power The user has pressed the full-power button.

Timer The user has pressed one of the timer buttons.

Number The user has pressed a numeric key.

Door open The oven door switch is not closed.
Door closed The oven door switch is closed.
Start The user has pressed the Start button.
Cancel The user has pressed the Cancel button.

Chapter 5 System Modeling 84

STATIC DIAGRAMS

• Class diagrams: show the classes and their relations.

• Object diagrams: show objects and their relations.
• Package diagrams: show how the various classes are
grouped into packages to simplify complex class
diagrams.
CLASS MODEL

• A class model captures the static structure of the system by

characterizing
• the classes and objects in the system,
• the relationships among the objects and
• the attributes and operations for each class of objects
• Class models are the most important OO models.
• In OO systems we build the system around objects not
functionality.
WHAT IS OO SOFTWARE?

• Object-oriented software means that we organize software as a

collection of discrete objects that incorporate both data structure
and behavior.
• The fundamental unit is the Object.
• An object has state (data) and behavior (operations).
• In Structured programming, data and operations on the data were
separated or loosely related.
OBJECT ORIENTED “OO”
CHARACTERISTICS
• Identity
• Classification
• Encapsulation
• Abstraction
• Inheritance
• Polymorphism
• Generics
• Cohesion
• Coupling
Identity

• An object can be concrete like a car, a file, …

• An object can be conceptual like a feeling, a plan,…
• Each object has its own identity even if two objects have exactly
the same state.

Omar’s car Rana’s car

Identity

• Object identity is the property by which each object can be identified

and treated as a distinct software entity.
• Each object has unique identity which distinguishes it from all its fellow
objects. It is its memory address (or handle) that is referred to by one
or more object identifiers (variables).
Identity

• car my_car = new car(“Opel”, 2005);

• The object handle is 0x00FDA610 is referenced by an object identifier
(object variable) my_car

0x00FDA610
my_car

0x00FDA610
CLASSES AND OBJECTS
• Each object is an instance of a class
• Each object has a reference to its
class (knows which class it belongs to)
Identity
CLASSIFICATION

• Classification means that objects with the same data structure

(attributes) and behavior (operations) belong to the same class.
• A class is an abstraction that describes the properties important for
an application
• The choice of classes is arbitrary and application-dependent.

Mohamed’s car Ahmed’s car Samar’s car A Car

CLASSIFICATION

• Objects in a class share a common semantic purpose in the system model.

• Both car and cow have price and age.
• If both were modeled as pure financial assets, they both can belong to the same
class.
• If the application needs to consider that:
• Cow eats and produces milk
• Car has speed, make, manufacturer, etc. then model them using separate classes.
• So the semantics depends on the application
ABSTRACTION

• Abstraction is the selective examination of certain aspects

of a problem.
• Abstraction aims to isolate the aspects that are important
for some purpose and suppress the unimportant aspects.
• The purpose of abstraction determines what is important
and what is not.
Abstraction
Encapsulation

• Encapsulation separates the external aspects of an object, that are

accessible to other objects, from the internal implementation details that are
hidden from other objects.
• Encapsulation reduces interdependency between different parts of the
program.
• You can change the implementation of a class (to enhance performance, fix
bugs, etc) without affecting the applications that use objects of this class.
• Data hiding. information from within the object cannot be seen outside the
object.
• Implementation hiding. implementation details within the object cannot be
seen from the outside.
Encapsulation
Inheritance

• Inheritance is the sharing of features (attributes and operations)

among classes based on a hierarchical relationship.
• A superclass (also parent or base ) has general features that
sublcasses (child or derived ) inherit. and may refine some of them.
• Inheritance is one of the strongest features of OO technology.
Inheritance

• Inheritance is the facility by which objects of a class (say B) may

use the methods and variables that are defined only to objects of
another (say A), as if these methods and variables have been
defined in class B
• Inheritance is represented as shown in UML notation.
A

B
HOW TO USE INHERITANCE?

• Inheritance helps building software

incrementally:
• First; build classes to cope with the
most straightforward (or general) case,
• Second; build the special cases that inherit from
the general base class. These new classes will
have the same features of the base class plus
their own.
Polymorphism

• Polymorphism means that the same operation may behave

differently for different classes.
• An operation is a procedure or a transformation that the object
performs or is subject to.
• An implementation of an operation by a specific class is called a
method.
• Because an OO operation is polymorphic, it may have more than
one method for implementing it, each for a different class.
Polymorphism
GENERICS

• Generic Class ; the data types of one or more of its attributes are
supplied at run-time (at the time that an object of the class is
instantiated).
• This means that the class is parameterized, i.e., the class gets a
parameter which is the name of another type.
CLASS MODEL

• A class model captures the static structure of the system by

characterizing
• the classes and objects in the system,
• the relationships among the objects and
• the attributes and operations for each class of objects
• Class models are the most important OO models
• In OO systems we build the system around objects not
functionality
Objects

• Objects often appear as proper nouns in the problem description or

discussion with the customer.
• Some object correspond to real world entities (BUE, MIT, Omar’s car)
• Some objects correspond to conceptual entities (the formula for solving an
equation, binary tree, etc.)
• The choice of objects depends on the analyst’s judgment and the problem in
hand. There can be more than one correct representation.
Class

• An object is an instance of a class

• A class describes a group of objects with the same
• Properties (attributes)
• Behavior (operations)
• Kinds of relationships
• Person, Company and Window are all classes
• Classes often appear as common nouns and noun phrases in
problem description and discussion with customers or users
Class Model

• Provides a graphical notation for modeling classes and their

relationships, thereby describing possible objects.
• Class diagram is useful for:
• Designing and Implementing the programs.
VALUES AND ATTRIBUTES

• An attribute is a named property of class that describes a value held by each object of that class.
• Attribute name is unique per class.
• Several classes may have the same attribute name.
• A value is a piece of data assigned to an attribute.
MORE ON ATTRIBUTES
OPERATIONS AND METHODS

• An operation is a function or procedure that may be

applied to or by objects of a class.
• A method is the implementation of an operation for
a class.
• An operation is polymorphic if it takes different
forms in different classes.
• All objects of the same class have the same
operations.
SUMMARY OF CLASS NOTATION

• The attribute and operation compartments are optional.

• You may show them or not depending on the level of abstraction
you want.
• A missing attribute compartments means that the attributes are not
specified yet.
• But empty compartment means that the attributes are specified but
there are none.
SUMMARY OF BASIC CLASS NOTATION
A SAMPLE CLASS MODEL

• Model the classes in a system that represents flights. Each city

has at least an airport. Airlines operate flights from and to
various airports. A flight has a list of passengers, each with a
designated seat. Also a flight uses one of the planes owned
by the operating airline. Finally a flight is run by a pilot and a
co-pilot.
A SAMPLE CLASS MODEL

• Model the classes in a system that represents flights. Each city

has at least an airport. Airlines operate flights from and to
various airports. A flight has a list of passengers, each with a
designated seat. Also a flight uses one of the planes owned
by the operating airline. Finally a flight is run by a pilot and a
co-pilot.
A SAMPLE CLASS MODEL