System Modeling

1
Topics covered
 Context models
 Interaction models
 Structural models
 Behavioral models
 Model-driven engineering

2
System modeling
 System modeling is the process of
developing abstract models of a system, with
each model presenting a different view or
perspective of that system.
 System 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).
 System modelling helps the analyst to
understand the functionality of the system
and models are used to communicate with
customers.
3
Existing and planned
system models
 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.
 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.
 In a model-driven engineering process, it is
possible to generate a complete or partial system
implementation from the system model.
4
System perspectives
 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.

5
Context models

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

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

8
Interaction models
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
modeling.
Chapter 5 System
10
Modeling
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.
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.

12
What is UML and Why we
use UML?
 UML → “Unified Modeling Language”
 Language: express idea, not a methodology

 Modeling: Describing a software system at a

high level of abstraction

 Unified: UML has become a world standard

Object Management Group (OMG): www.omg.org
What is UML and Why we
use UML?
 More description about UML:
 It is a industry-standard graphical language for
specifying, visualizing, constructing, and
documenting the artifacts of software systems

 The UML uses mostly graphical notations to

express the OO analysis and design of
software projects.

 Simplifies the complex process of software

design
What is UML and Why we
use UML?
 Why we use UML?
 Use graphical notation: more clearly than natural
language (imprecise) and code (too detailed).

 Help acquire an overall view of a system.

 UML is not dependent on any one language or

technology.

 UML moves us from fragmentation to standardization.

How to use UML
diagrams to design
software system?
 Types of UML Diagrams:
 Use Case Diagram
 Class Diagram
 Sequence Diagram
 Collaboration Diagram
 State Diagram

This is only a subset of diagrams … but are most widely

used
Use-Case Diagrams
 A use-case diagram is a set of use cases
 A use case is a model of the interaction
between
 External users of a software product (actors) and
 The software product itself
 More precisely, an actor is a user playing a specific role

 describing a set of user scenarios

 capturing user requirements
 contract between end user and software
developers
 Use-Case Diagrams
Boundary Use Case
Actor Library System

Borrow Employee
Client

Order Title

Fine Remittance

Supervisor
 Use-Case Diagrams
 Actors: A role that a user plays with respect to the system, including human
users and other systems. e.g., inanimate physical objects (e.g. robot); an
external system that needs some information from the current system.

 Use case: A set of scenarios that describing an interaction between a user

and a system, including alternatives.

 System boundary: rectangle diagram representing the boundary between

the actors and the system.
Use-Case Diagrams
 Association:
communication between an actor and a use case; Represented by a solid
line.

 Generalization: relationship between one general use case and a

special use case (used for defining special alternatives) Represented
by a line with a triangular arrow head toward the parent use case.
Use-Case Diagrams
Include: a dotted line labeled <<include>>
beginning at base use case and ending with an
arrows pointing to the include use case. The
include relationship occurs when a chunk of
behavior is similar across more than one use
case. Use “include” in stead of copying the
description of that behavior.
Extend: a dotted line labeled <<extend>> with
<<include>>
an arrow toward the base case. The extending
use case may add behavior to the base use
case. The base class declares “extension
points”.
Use-Case Diagrams

Figure 16.12
Use-Case Diagrams
Use-Case Diagrams
 Both Make Appointment
and Request Medication
include Check Patient
Record as a subtask
(include)

 The extension point is

written inside the base
case Pay bill; the
extending class Defer
payment adds the
behavior of this extension
point. (extend)

 Pay Bill is a parent use

case and Bill Insurance
is the child use case.
(generalization)

(TogetherSoft, Inc)
 Data Flow Diagrams
WHAT ARE DATA FLOW DIAGRAMS?
DFDs models the system by depicting

 External entities from which the data flows and

where results terminate
 Processes which transform data flows
 Data stores from which the data are read or into
which data are written by the processes.
Flow Modeling
Notation
External Entity

Process

Data flow

Data store

26
External Entity
A producer or consumer of data

Examples: a person, a device, a sensor

Another example: computer-based system

Data must always originate somewhere

and must always be sent to something

27
 Process
A data transformer (changes input
to output)

Examples: compute taxes, determine

area, format report, display graph

Data must always be processed in some

way to achieve system function

28
Data Flow
Data flows through a system, beginning
as input and transformed into output.
base
compute
triangle area
area
height

29
 Data Stores
Data is often stored for later use.

sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number

sensor data

30
 DFD Rules and Tips
 Each process should have at least one input
and an output.
 Each data store should have at least one data
flow in and one data flow out.
 Data stored in a system must go through a
process.
 All processes in a DFD go to another process
or a data store.
 Rules for Data Flow
 E-P  E-E
 P-P  E-S
 P-S  S-S
 P-E
 S-E
 DFD levels and layers:
From context diagrams to pseudocode

 A data flow diagram can dive into

progressively more detail by using levels and
layers, zeroing in on a particular piece.
 DFD levels are numbered 0, 1 or 2, and
occasionally go to even Level 3 or beyond.
 DFD 0
 DFD Level 0 is also called a Context Diagram. It’s
a basic overview of the whole system or process
being analyzed or modeled.
 It’s designed to be an at-a-glance view, showing the
system as a single high-level process, with its
relationship to external entities.
 It should be easily understood by a wide audience,
including stakeholders, business analysts, data
analysts and developers.
 DFD 0
 DFD Level 0 is also called a Context Diagram. It’s a
basic overview of the whole system or process being
analyzed or modeled.
 It’s designed to be an at-a-glance view, showing the
system as a single high-level process, with its
relationship to external entities.
 It should be easily understood by a wide audience,
including stakeholders, business analysts, data
analysts and developers.
DFD 0
 DFD-1

 DFD Level 1 provides a more detailed

breakout of pieces of the Context Level
Diagram.
 You will highlight the main functions carried
out by the system, as you break down the
high-level process of the Context Diagram
into its sub-processes.
DFD-1
 DFD-2

DFD Level 2 then goes one step

deeper into parts of Level 1.
It may require more text to reach the
necessary level of detail about the
system’s functioning.
DFD-2
Class diagram
 A class diagram depicts classes and their interrelationships

 Used for describing structure and behavior in the use cases

 Provide a conceptual model of the system in terms of

entities and their relationships

 Used for requirement capture, end-user interaction

 Detailed class diagrams are used for developers

Class diagram
 Each class is represented by a rectangle
subdivided into three compartments
 Name
 Attributes
 Operations

 Modifiers are used to indicate visibility of

attributes and operations.
 ‘+’ is used to denote Public visibility
(everyone)
 ‘#’ is used to denote Protected visibility
(friends and derived)
 ‘-’ is used to denote Private visibility (no one)

 By default, attributes are hidden and

operations are visible.
Class diagram

Name
Account_Name
- Customer_Name
Attributes
- Balance
+addFunds( ) Operations
+withDraw( )
+transfer( )
OO Relationships
 There are two kinds of Relationships
 Generalization (parent-child relationship)
 Association (student enrolls in course)

 Associations can be further classified

as
 Aggregation
 Composition
 OO Relationships: Generalization

Example:
Supertype Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2

-Inheritance is a required feature of object orientation

-Generalization expresses a parent/child relationship
among related classes.
-Used for abstracting details in several layers
 OO Relationships: Association

 Represent relationship between instances of classes

 Student enrolls in a course
 Courses have students
 Courses have exams
 Etc.

 Association has two ends

 Role names (e.g. enrolls)
 Multiplicity (e.g. One course can have many students)
 Navigability (unidirectional, bidirectional)
 Association: Multiplicity and
Roles
student
1 *
University Person

0..1 *
employer teacher

Multiplicity Role
Symbol Meaning
1 One and only one
Role
0..1 Zero or one “A given university groups many people;
some act as students, others as teachers.
M..N From M to N (natural
language) A given student belongs to a single
university; a given teacher may or may not
* From zero to any positive
be working for the university at a particular
integer
time.”
0..* From zero to any positive
integer
1..* From one to any positive
Class diagram

[from UML Distilled Third Edition]

Association: Model to
Implementation

* 4
Student Course
has enrolls
Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
 OO Relationships: Composition

Whole Class
Class W Association
Models the part–whole relationship

Composition
Class P1 Class P2 Also models the part–whole relationship but, in
addition, Every part may belong to only one
whole, and If the whole is deleted, so are the
Part Classes parts
[From Dr.David A. Workman]
Example Example:
A number of different chess boards: Each square
belongs to only one board. If a chess board is
thrown away, all 64 squares on that board go as
well.

Figure 16.7
 OO Relationships: Aggregation

Container Class
Aggregation:
Class C expresses a relationship among instances of related
classes. It is a specific kind of Container-Containee
AGGREGATION
relationship.

Class E1 Class E2
express a more informal relationship than
composition expresses.
Containee Classes
Aggregation is appropriate when Container and
Example Containees have no special access privileges to
Bag each other.

Apples Milk

[From Dr.David A. Workman]

Aggregation vs. Composition
Composition is really a strong form of association
components have only one owner
components cannot exist independent of their owner
components live or die with their owner
e.g. Each car has an engine that can not be shared with other cars.

Aggregations
may form "part of" the association, but may not be essential to it. They
may also exist independent of the aggregate. e.g. Apples may exist
independent of the bag.
 Activity Diagram
 Activity diagrams describe the workflow behavior of a system.

 Activity diagrams are used in process modeling and analysis of during

requirements engineering.

 A typical business process which synchronizes several external incoming events

can be represented by activity diagrams.

 They are most useful for understanding work flow analysis of synchronous
behaviors across a process.
 Activity Diagram

 Activity diagrams are used for

 documenting existing process
 analyzing new Process Concepts
 finding reengineering opportunities.

 The diagrams describe the state of activities by showing the sequence of

activities performed.
 they can show activities that are conditional or parallel.
 Activity Diagram
Concepts

 An activity is trigged by one or more events and activity may result in one or
more events that may trigger other activity or processes.

 Events start from start symbol and end with finish marker having activities in
between connected by events.

 The activity diagram represents the decisions, iterations and parallel/random

behavior of the processing.
 They capture actions performed.
 They stress on work performed in operations (methods).

55
 When to Use Activity Diagrams

 The main reason to use activity diagrams is to model the workflow behind
the system being designed.

 Activity Diagrams are also useful for:

 analyzing a use case by describing what actions need to take place and when they
should occur
 describing a complicated sequential algorithm
 modeling applications with parallel processes

 Activity Diagrams should not take the place of interaction diagrams and
state diagrams.

 Activity diagrams do not give detail about how objects behave or how
objects collaborate.
56
 Components
 An activity is an ongoing, though interruptible, execution of a
step in a workflow (such as an operation or transaction)
 Represented with a rounded rectangle.
 Text in the activity box should represent an activity (verb phrase in
present tense).

57
 Components
 An event is triggered by an activity. It specifies a significant occurrence that has a
location in time and space.
 An instance of an event (trigger) results in the flow from one activity to another.
 These are represented by directed straight lines emerging from triggering activity and ending
at activity to be triggered. Label text for events should represent event but not the data
involved.

 A decision may be shown by labeling multiple output transitions of an activity with

different guard conditions.
 For convenience a stereotype is provided for a decision: the traditional diamond shape, with
one or more incoming arrows and with two or more outgoing arrows, each labeled by a
distinct guard condition with no event trigger.

58
 How to Draw an Activity Diagram
 Diagrams are read from top to bottom and have branches and forks to describe
conditions and parallel activities.
 A fork is used when multiple activities are occurring at the same time.

 A branch describes what activities will take place based on a set of conditions.

 All branches at some point are followed by a merge to indicate the end of the
conditional behavior started by that branch.

 After the merge all of the parallel activities must be combined by a join before
transitioning into the final activity state.

59
Activity Diagram Example Start State

Activity
Fork

Branch

Merge Join

End
State
60
Interaction Diagrams
 show how objects interact with one
another

 UML supports two types of interaction

diagrams
 Sequence diagrams
 Collaboration diagrams
Sequence Diagram(make a
phone call)
Caller Phone Recipient

Picks up

Dial tone

Dial

Ring notification Ring

Picks up

Hello
Sequence Diagram:Object
interaction

A B
Self-Call:
Self-Call A message that an
Synchronous
Object sends to itself.

Condition: indicates when a Asynchronous

message is sent. The message is
Transmission
sent only if the condition is true. delayed

[condition] remove()
Condition
*[for each] remove()
Iteration

Self-Call
 Sequence Diagram
Us er
Message Catalog Res ervations

•Sequence diagrams demonstrate the

behavior of objects in a use case by 1: look up ()

describing the objects and the 2: title data ()

messages they pass.
3: [not available] res erve title ()

4 : title returned ()
•The horizontal dimension shows the
objects participating in the interaction. 5: hold title ()

5 : title available ()

•Thevertical arrangement of 6 : borrow title ()

messages indicates their order.

6 : rem ove res ervation ()

•The labels may contain the seq. # to

indicate concurrency.
Conclusion
 UML is a standardized specification
language for object modeling
 Several UML diagrams:
 use-case diagram: a number of use cases (use case models the
interaction between actors and software)
 Class diagram: a model of classes showing the static relationships
among them including association and generalization.
 Sequence diagram: shows the way objects interact with one another as
messages are passed between them. Dynamic model
 State diagram: shows states, events that cause transitions between
states. Another dynamic model reflecting the behavior of objects and
how they react to specific event
 There are several UML tools available
 Thank you
Questions?