Chapter 5 – System Modeling

CHAPTER 5 SYSTEM MODELING 1

Topics covered
Context models
Interaction models
Structural models
Behavioral models

CHAPTER 5 SYSTEM MODELING 2

System modeling
oSystem modeling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system.

oSystem modeling has now come to mean representing a system using some kind of graphical
notation, which is now almost always based on notations in the Unified Modeling Language
(UML).

oSystem modelling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.

CHAPTER 5 SYSTEM MODELING 3

Existing and planned system models
o Models of the existing system are used during requirements engineering. They help
clarify what the existing system does and can be used as a basis for discussing its
strengths and weaknesses. These then lead to requirements for the new system.

o Models of the new system are used during requirements engineering to help explain
the proposed requirements to other system stakeholders. Engineers use these models
to discuss design proposals and to document the system for implementation.

o In a model-driven engineering process, it is possible to generate a complete or

partial system implementation from the system model.

CHAPTER 5 SYSTEM MODELING 4

System perspectives
oAn external perspective, where you model the context or environment of the system.

oAn interaction perspective, where you model the interactions between a system and its
environment, or between the components of a system.

oA structural perspective, where you model the organization of a system or the structure of the
data that is processed by the system.

oA behavioral perspective, where you model the dynamic behavior of the system and how it
responds to events.

CHAPTER 5 SYSTEM MODELING 5

UML diagram types
1. Activity diagrams, which show the activities involved in a process or in data processing .
2. Use case diagrams, which show the interactions between a system and its environment.
3. Sequence diagrams, which show interactions between actors and the system and between
system components.
4. Class diagrams, which show the object classes in the system and the associations between
these classes.
5. State diagrams, which show how the system reacts to internal and external events.

CHAPTER 5 SYSTEM MODELING 6

Use of graphical models
As a means of facilitating discussion about an existing or proposed system
◦ Incomplete and incorrect models are OK as their role is to support discussion.

As a way of documenting an existing system

◦ Models should be an accurate representation of the system but need not be complete.

As a detailed system description that can be used to generate a system implementation

◦ Models have to be both correct and complete.

CHAPTER 5 SYSTEM MODELING 7

1- Context models
o Context models are used to illustrate the operational context of a system - they show what
lies outside the system boundaries.

o Social and organisational concerns may affect the decision on where to position system
boundaries.

o Architectural models show the system and its relationship with other systems.

CHAPTER 5 SYSTEM MODELING 8

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.

Defining a system boundary is a political judgment

◦ There may be pressures to develop system boundaries that increase / decrease the influence or
workload of different parts of an organization.

CHAPTER 5 SYSTEM MODELING 9

The context of the MHC-PMS

CHAPTER 5 SYSTEM MODELING 10

2- Interaction models
o Modeling user interaction is important as it helps to identify user requirements.

o Modeling system-to-system interaction highlights the communication problems that may

arise.

o Modeling component interaction helps us understand if a proposed system structure is likely

to deliver the required system performance and dependability.

o Use case diagrams and sequence diagrams may be used for interaction modelling.

CHAPTER 5 SYSTEM MODELING 11

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

CHAPTER 5 SYSTEM MODELING 12

Example: Student Administration System
▪System
(what is being described?)
▪ Student administration system

▪Actors
(who interacts with the system?)
▪ Professor

▪Use cases
(what can the actors do?)
▪ Query student data
▪ Issue certificate
▪ Announce exam

4
 Actor
▪Actors interact with the system …
▪ by using use cases,
i.e., the actors initiate the execution of use cases.
▪ by being used by use cases,
i.e., the actors provide functionality for the execution of use cases.
▪Actors represent roles that users adopt.
▪ Specific users can adopt and set aside multiple roles simultaneously.
▪Actors are not part of the system, i.e., they are outside of the system boundaries.
▪Alternative notations:

6
 Actor
▪Human Human
▪ E.g., Student, Professor Primary
Active
▪Non-human
▪ E.g., E-Mail Server Human
Secondary
▪Primary: has the main benefit of the execution of the use case Active
▪Secondary: receives no direct benefit
▪Active: initiates the execution of the use case
Human
▪Passive: provides functionality for the execution of the use case Primary
Active

▪Example: Non-human
Secondary
Passive
8
Relationships between Use Cases and Actors
▪Actors are connected with use cases via solid lines (associations).
▪Every actor must communicate with at least one use case.
▪An association is always binary.
▪Multiplicities may be specified.

9
8
Relationships between Use Cases
«inlcude» - Relationship

▪The behavior of one use case (included use case) is integrated in the behavior of another use
case (base use case)

Base use case

requires the behavior of the included use
case to be able to offer its functionality

Included use case

may be executed on its own

10
Relationships between Use Cases
«extend» - Relationship
▪The behavior of one use case (extending use case) may be integrated in the behavior of another use
case (base use case) but does not have to.
▪Both use cases may also be executed independently of each other.

Base use case

Extending use case

▪A decides if B is executed.
▪Extension points define at which point the behavior is integrated.
▪Conditions define under which circumstances the behavior is integrated.

11
 Relationships between Use Cases
«extend» - Relationship: Extension Points

▪Extension points are written directly within the use case.

▪Specification of multiple extension points is possible.

▪Example:

12
Relationships between Use Cases
Generalization of Use Cases

▪Use case A generalizes use case B.

▪B inherits the behavior of A and may Base use case
either extend or overwrite it.
Sub use case
▪B also inherits all relationships from A.
▪B adopts the basic functionality of A but
decides itself what part of A is executed or changed.
▪A may be labeled {abstract}
▪ Cannot be executed directly
▪ Only B is executable

▪Example:

13
Description of Use Cases - Example
▪ Name: Reserve lecture hall

▪ Short description: An employee reserves a lecture hall at the university for an event.

▪ Precondition: The employee is authorized to reserve lecture halls.

▪ Postcondition: A lecture hall is reserved.

▪ Error situations: There is no free lecture hall.

▪ System state in the event of an error: The employee has not reserved a lecture hall.

▪ Actors: Employee

▪ Trigger: Employee requires a lecture hall.

▪ Standard process: (1) Employee logs in to the system.

(2) Employee selects the lecture hall.

(3) Employee selects the date.

(4) System confirms that the lecture hall is free.

(5) Employee confirms the reservation.

▪ Alternative processes: (4’) Lecture hall is not free.

(5’) System proposes an alternative lecture hall.

(6’) Employee selects alternative lecture hall and confirms the reservation.

16
Best Practices
«include»

UML standard Best practice

17
Best Practices
▪Use case diagrams do not model processes/workflows!

21
Best Practices
▪Actors are not part of the system, hence, they are positioned outside the system boundaries!

22
Best Practices
▪Many small use cases that have the same objective may be grouped to form one use case

✓
24
2.2 Sequence diagrams
oSequence diagrams are part of the UML and are used to model the interactions between the
actors and the objects within a system.

oA sequence diagram shows the sequence of interactions that take place during a particular use
case or use case instance.

oThe objects and actors involved are listed along the top of the diagram, with a dotted line
drawn vertically from these.

oInteractions between objects are indicated by annotated arrows.

CHAPTER 5 SYSTEM MODELING 26

Sequence Diagram
▪Two-dimensional diagram
▪ Horizontal axis: involved interaction partners
▪ Vertical axis: chronological order of the interaction

▪Interaction = sequence of event specifications

27
Interaction Partners
▪Interaction partners are depicted as lifelines
▪Head of the lifeline
▪ Rectangle that contains the expression roleName:Class
▪ Roles are a more general concept than objects
▪ Object can take on different roles over its lifetime

▪Body of the lifeline

▪ Vertical, usually dashed line
▪ Represents the lifetime of the object associated with it
Head of the lifeline

Body of the Lifeline

28
Exchanging Messages
▪Interaction: sequence of events
▪Message is defined via send event and receive event
▪Execution specification
▪ Continuous bar
▪ Used to visualize when an interaction partner executes some behavior

Send event Receive event

Execution specification

29
 Messages
▪Synchronous message
▪ Sender waits until it has received a response message
before continuing
▪ Syntax of message name: msg(par1,par2)
▪ msg: the name of the message
▪ par: parameters separated by commas

▪Asynchronous message
▪ Sender continues without waiting for a response
message
▪ Syntax of message name: msg(par1,par2)
▪Response message
▪ May be omitted if content and location are obvious
▪ Syntax: att=msg(par1,par2):val
▪ att: the return value can optionally be assigned to a variable
▪ msg: the name of the message
▪ par: parameters separated by commas
▪ val: return value

30
Combined Fragments
▪Model various control structures
▪12 predefined types of operators Combined Fragment

Operator
Operand

Operand
Operand

31
alt Fragment
▪To model alternative sequences
▪Similar to switch statement in Java
▪Guards are used to select the one path to be executed
▪Guards
▪ Modeled in square brackets
▪ default: true
▪ predefined: [else]

▪Multiple operands
▪Guards have to be disjoint to avoid indeterministic
behavior

32
opt Fragment
▪To model an optional sequence
▪Actual execution at runtime is dependent on the guard
▪Exactly one operand
▪Similar to if statement without else branch
▪equivalent to alt fragment with two operands, one of
which is empty

33
loop Fragment
▪To express that a sequence is to be executed repeatedly
▪Exactly one operand
▪Keyword loop followed by the minimal/maximal number of iterations (min..max) or (min,max)
▪ default: (*) .. no upper limit
▪Guard
▪ Evaluated as soon as the minimum number of iterations has taken place
▪ Checked for each iteration within the (min,max) limits
▪ If the guard evaluates to false, the execution of the loop is terminated
Max
Min
Guard Notation alternatives:
loop is executed
at least once, loop(3,8) = loop(3..8)
then as long as loop(8,8) = loop (8)
a<1 is true loop = loop (*) = loop(0,*)

34
break Fragment
▪Simple form of exception handling
▪Exactly one operand with a guard
▪If the guard is true:
▪ Interactions within this operand are executed
▪ Remaining operations of the surrounding
fragment are omitted
▪ Interaction continues in the next higher
level fragment
▪ Different behavior than opt fragment

Not executed if break is executed

35
loop and break Fragment - Example

36
3- Structural models
o Structural models of software display the organization of a system in terms of the
components that make up that system and their relationships.

o 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.

o You create structural models of a system when you are discussing and designing the system
architecture.

CHAPTER 5 SYSTEM MODELING 37

3.1 Class diagrams
o Class diagrams are used when developing an object-oriented system model to show the
classes in a system and the associations between these classes.

o An object class can be thought of as a general definition of one kind of system object.

o An association is a link between classes that indicates that there is some relationship between
these classes.

o 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 38

Class

Class name

Attributes

Operations

39
 From Object to Class
▪Individuals of a system often have identical characteristics and behavior
Class
▪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 Object of that class

▪ Different value for each instance (= object)

▪Operations: behavior of a class

▪ Identical for all objects of a class
→ not depicted in object diagram

40
3.2 Aggregation
▪Aggregation means that one object (the whole) is composed of other objects (the parts).

▪To define aggregation, a diamond shape is added to the link next to the class that represents
the whole

41
3.3 Generalization
▪Characteristics (attributes and operations), associations, and
aggregations that are specified for a general class
(superclass) are passed on to its subclasses. Superclass

▪Every instance of a subclass is simultaneously an indirect

instance of the superclass.
▪Subclass inherits all characteristics, associations, and
aggregations of the superclass except private ones. Subclasses
…inherit characteristics,
▪Subclass may have further characteristics, associations, and associations, and
aggregations. aggregations
▪Generalizations are transitive. A Secretary is
an Employee and
a Person

42
Generalization – Abstract Class
▪Used to highlight common characteristics of their subclasses.
▪Used to ensure that there are no direct instances of the superclass.
▪Only its non-abstract subclasses can be instantiated.
▪Useful in the context of generalization relationships.
▪Notation: keyword {abstract} or class name in italic font.

No Person-object possible

Two types of Person: Man and Woman

43
Generalization – Multiple Inheritance
▪UML allows multiple inheritance.
▪A class may have multiple superclasses.

▪Example:

A Tutor is both an Employee and a Student

44
With and Without Generalization

45
Creating a Class Diagram
▪Not possible to completely extract classes, attributes and associations from a natural
language text automatically.
▪Guidelines
▪ Nouns often indicate classes
▪ Adjectives indicate attribute values
▪ Verbs indicate operations

▪Example: The library management system stores users with their unique ID, name and
address as well as books with their title, author and ISBN number. Ann Foster wants to use
the library.

46
Example – University Information System
▪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.

47
Example – Step 1: Identifying Classes
We model the system „University“

▪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.

Dean has no further attributes than

any other employee

48
Example – Step 2: Identifying the 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.

49
Example – Step 3: Identifying Relationships
▪Three kinds of relationships:
▪ Association Abstract, i.e., no other types
of employees
▪ 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.”

50
 Example – Step 3: Identifying Relationships
▪“A university consists of multiple faculties which are composed of various institutes.”

Composition to show existence

dependency

51
 Example – Step 3: Identifying Relationships
▪“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.

52
Example – Step 3: Identifying Relationships
▪“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

53
Example – Step 3: Identifying Relationships
▪“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

54
Example – Step 3: Identifying Relationships
▪“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.

55
Example – Complete Class Diagram

56
4- 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 57

4.1- Data-driven modeling
o 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.

o Data-driven models show the sequence of actions involved in processing input data and
generating an associated output.

o 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 58

An activity model of the insulin pump’s
operation

CHAPTER 5 SYSTEM MODELING 59

Activity
▪Specification of user-defined behavior at different levels of granularity
▪Examples:
▪ Definition of the behavior of an operation in the form of individual instructions
▪ Modeling the course of actions of a use case Output
▪ Modeling the functions of a business process parameter

▪An activity is a directed graph

▪ Nodes: actions and activities
▪ Edges: for control and object flow
Input
▪Control flow and object flow define parameter
the execution
▪Optional:
▪ Parameter Node Edge
▪ Pre- and postconditions
60
Action
▪Basic element to specify user-defined behavior
▪Atomic but can be aborted
▪No specific rules for the description of an action
→Definition in natural language or in any programming language
▪Process input values to produce output values
▪Special notation for predefined types of actions, most importantly
▪ Event-based actions
▪ Call behavior actions

61
Edges
▪Connect activities and actions to one another
▪Express the execution order Control flow
▪Types
▪ Control flow edges
▪ Define the order between nodes
▪ Object flow edges
▪ Used to exchange data or objects
▪ Express a data/causal dependency between nodes
Object flow
▪Guard (condition)
▪ Control and object flow only continue if
guards in square brackets
evaluate to true

62
Beginning and Termination of Activities
▪Initial node
▪ Starts the execution of an activity
▪ Provides tokens at all outgoing edges
▪ Keeps tokens until the successive nodes accept them
▪ Multiple initial nodes to model concurrency

▪Activity final node

▪ Ends all flows of an activity
▪ First token that reaches the activity final node terminates the entire activity
▪ Concurrent subpaths included
▪ Other control and object tokens are deleted
▪ Exception: object tokens that are already present at the output parameters of the activity

▪Flow final node

▪ Ends one execution path of an activity
▪ All other tokens of the activity remain unaffected
63
Alternative Paths – Decision Node
▪To define alternative branches
▪„Switch point“ for tokens
▪Outgoing edges have guards
▪ Syntax: [Boolean expression]
▪ Token takes one branch
▪ Guards must be mutually exclusive
▪ Predefined: [else]

▪Decision behavior
▪ Specify behavior that is necessary for the evaluation of the guards
▪ Execution must not have side effects

64
Alternative Paths – Merge Node
▪To bring alternative sub-paths together
▪Passes token to the next node

▪Combined decision and merge node

▪Decision and merge nodes can also be used to model loops:

65
Example: Alternative Paths

66
4.2 Event-driven modeling
o 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.

o Event-driven modeling shows how a system responds to external and internal events.

o 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 67

State machine models
o These model the behaviour of the system in response to external and internal
events.
o They show the system’s responses to stimuli so are often used for modelling
real-time systems.
o 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.
o State charts are an integral part of the UML and are used to represent state
machine models.

CHAPTER 5 SYSTEM MODELING 68

State machine models
▪Every object takes a finite number of different states during its life
▪State machine diagram is used as follows:
▪ To model the possible states of a system or object
▪ To show how state transitions occur as a consequence of events
▪ To show what behavior the system or object exhibits in each state

▪Example: high-level description of the behavior of a lecture hall

Transition State

69
 State
▪States = nodes of the state machine

▪When a state is active

▪ The object is in that state
▪ All internal activities specified in this state can be executed
▪ An activity can consist of multiple actions

▪entry / Activity(...)
▪ Executed when the object enters the state
▪exit / Activity(...)
▪ Executed when the object exits the state
▪do / Activity(...)
▪ Executed while the object remains in this state

70
Transition
▪Change from one state to another

Event Guard Sequence of actions (effect)

Source state Transition Target state

71
Example: Lecture Hall with Details
class LectureHall {
private boolean free;

public void occupy() {

free=false;
}
public void release() {
free=true;
}
}

72
4.3- Model-driven engineering
o Model-driven engineering (MDE) is an approach to software development where models
rather than programs are the principal outputs of the development process.

o The programs that execute on a hardware/software platform are then generated automatically
from the models.

o Proponents of MDE argue that this raises the level of abstraction in software engineering so
that engineers no longer have to be concerned with programming language details or the
specifics of execution platforms.

CHAPTER 5 SYSTEM MODELING 73

Usage of model-driven engineering
Model-driven engineering is still at an early stage of development, and it is unclear whether or
not it will have a significant effect on software engineering practice.

Pros
◦ Allows systems to be considered at higher levels of abstraction
◦ Generating code automatically means that it is cheaper to adapt systems to new platforms.

Cons
◦ Models for abstraction and not necessarily right for implementation.
◦ Savings from generating code may be outweighed by the costs of developing translators for new
platforms.

CHAPTER 5 SYSTEM MODELING 74

References
Seidl, M., Huemer, M. S. C., & Kappel, G. (2012). UML@ Classroom An Introduction to
Object-Oriented Modeling.
Seidl, M., Huemer, M. S. C., & Kappel, G. (2012). UML@ Classroom An Introduction to
Object-Oriented Modeling.