SYSTEM MODELING

Software Design (UML) © SERG

 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.

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

© SERG
 Existing and planned system models

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

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

© SERG
 Overview of UML Diagrams
Behavioral
Structural : behavioral features of a system / business
process
: element of spec. irrespective of time
• Activity
• State machine
• Class
• Use case
• Component
• Interaction
• Deployment
• Object
• Composite structure Interaction
: emphasize object interaction
• Package
• Communication(collaberati
on)
• Sequence
• Interaction overview
• Timing
© SERG
 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.

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

Context models simply show the other systems in the environment,

not how the system being developed is used in that environment.

© SERG
The Context of the Mentcare System

© SERG
 Classes
A class is a description of a set of
ClassName objects that share the same attributes,
operations, relationships, and semantics.
attributes
Graphically, a class is rendered as a
rectangle, usually including its name,
operations attributes, and operations in separate,
designated compartments.

Software Design (UML) © SERG

 Class Names
The name of the class is the only required
ClassName tag in the graphical representation of a
class. It always appears in the top-most
attributes compartment.

operations

Software Design (UML) © SERG

 Class Attributes

Person

name : String An attribute is a named property of a

address : Address class that describes the object being modeled.
birthdate : Date In the class diagram, attributes appear in
ssn : Id the second compartment just below the
name-compartment.

Software Design (UML) © SERG

 Class Attributes (Cont’d)
Attributes are usually listed in the form:
Person attributeName : Type

name : String
address : Address
birthdate : Date
ssn : Id

Software Design (UML) © SERG

 Class Attributes (Cont’d)

Person

Attributes can be:

+ name : String
+ public
# address : Address
# protected
# birthdate : Date
- private
/ age : Date
/ derived
- ssn : Id

Software Design (UML) © SERG

 Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id
eat Operations describe the class behavior
sleep and appear in the third compartment.
work
play

Software Design (UML) © SERG

 Depicting Classes
When drawing a class, you needn’t show attributes and operation
in every diagram.

Person Person Person

name : String
birthdate : Date
Person ssn : Id
name Person eat()
address sleep()
birthdate eat work()
play play()

Software Design (UML) © SERG

Basic Concepts of Object Orientation

• Object
• Class
• Attribute
• Operation
• Relationships

© SERG
 The Relationship Between Classes and
Objects
A class is an abstract definition of an object
 It defines the structure and behavior of each object in the class
 It serves as a template for creating objects
Objects are grouped into classes
Objects Class

Professor

Professor Smith Professor Mellon

Professor Jones

© SERG
 Relationships
• A relationship is a general term covering the specific types
of logical connections found on class and object diagrams.

© SERG
 Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.

There are three kinds of relationships in UML:

• dependencies

• generalizations

• associations (aggregation & composition)

Software Design (UML) © SERG

Generalization Relationships

Person

• A generalization connects a subclass

to its superclass.
Student • It denotes an inheritance of attributes
and behavior from the superclass to the
subclass and indicates a specialization
in the subclass of the more general
superclass.

Software Design (UML) © SERG

 Association Relationships
If two classes in a model need to communicate with each other,
there must be link between them.

An association denotes that link.

Student Instructor

Software Design (UML) © SERG

 Relationships: Association
• An association represents a family of links.
• Models a semantic connection among classes
Association Name

Professor Works for University

Association Role Names

Class Professor University

Employee Employer

© SERG
Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more

Instructors:

Student Instructor
1..*

Software Design (UML) © SERG

Association Relationships (Cont’d)

The example indicates that every Instructor has one or more

Students:

Student Instructor
1..*

Software Design (UML) © SERG

Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.

teaches learns from

Student Instructor
1..* 1..*

Software Design (UML) © SERG

Association Relationships (Cont’d)
We can also name the association.

membership
Student Team
1..* 1..*

Software Design (UML) © SERG

 Relationships: Aggregation
• A special form of association that models a whole-part
relationship between an aggregate (the whole) and its
parts
Part
Whole

Student Schedule

Aggregation

• is a variant of the "has a" association relationship;

aggregation is more specific than association. © SERG
Association Relationships (Cont’d)

Software Design (UML) © SERG

Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *

Software Design (UML) © SERG

 EXAMPLE # 1
• In a university, there are different classrooms, offices and
departments.
• A department has a name and it contains many offices.
• A person working at the university has a unique ID and can
be a professor or an employee.
• A professor can be a full, associate or assistant professor
and he/she is enrolled in one department.
• Offices and classrooms have a number ID, and a classroom
has several seats.
• Every employee works in an office.

Software Design (UML) © SERG

 Solution

Software Design (UML) © SERG

ATM Example

Software Design (UML) © SERG

Software Design (UML) © SERG
 Process Perspective

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

© SERG
 Activity Diagrams

• It is essentially a flowchart
– Showing flow of control from activity to activity
• Purpose
– Model business workflows
– Model operations

© SERG
 Activity Diagrams

• Activity diagrams commonly contain

– Activity states
– Transitions
– Objects

© SERG
ACTIVITY DIAGRAM

© SERG
DECISIONS

© SERG
 SYNCHRONIZATION
• A fork node is used to split a single incoming flow into multiple
concurrent flows. It is represented as a straight, slightly thicker line in
an activity diagram.
• A join node joins multiple concurrent flows back into a single outgoing
flow.
• A fork and join mode used together are often referred to as
synchronization.

© SERG
CONCURRENT PATHS

© SERG
 SWIM LANES
• Swim lanes group related activities into one column.
• The activity diagram adds the dimension of visualizing
roles.
• To do that, you separate the diagram into parallel segments
called swimlanes.
• Each swimlane shows the name of a role at the top and
presents the activities of each role.
• Transitions can take place from one swimlane to another.

© SERG
© SERG
Activity Diagram Example 1

© SERG
© SERG
 SEQUENCE DIAGRAM
• The UML sequence diagram adds the
dimension of time to object interaction.

• The sequence diagram depicts that interaction

among the objects take place in a specified
sequence, and the sequence takes time to go from
beginning to end.

© SERG
 OBJECTS

•The objects are laid out near the top of the

diagram from left to right.
•Extending downward from each object is a
dashed line called the object's lifeline.
•Along the lifeline is a narrow rectangle
called an activation (represents an execution
of an operation the object carries out).

© SERG
 Representing Objects

• squares with object type, optionally preceded by object name and

colon
– write object's name if it clarifies the diagram
– object's "life line" represented by dashed vertical line

© SERG
 MESSAGES
• A message that goes from one object to another
goes from one object's lifeline to the other object's
lifeline.

• An object can also send a message to itself that is,

from its lifeline back to its own lifeline.

• The message is of two types:

1. Synchronous
2. A Synchronous
© SERG
 SYNCHRONOUS MESSAGE
• One type of message is a call. This is a request from the object
sending the message to the object receiving the message.

• The request is for the receiver to carry out one of its (the
receiver's) operations.

• Usually, this entails the sender waiting for the receiver to carry
out that operation. Because the sender waits for the receiver
(that is, "synchs up" with the receiver), this message is also
referred to as synchronous.

• UML signifies this message type with a filled arrowhead at the

end of a solid line.

© SERG
 A SYNCHRONOUS MESSAGE
• With this one, the sender transfers control to the
receiver and doesn't wait for the operation to
complete.

• The symbol for this message is an open-stick

arrow head as shown in figure below:

© SERG
 TIME
• The diagram represents time in the vertical direction.

• Time starts at the top and progresses toward the bottom.

• A message that's closer to the top occurs earlier in time

than a message that's closer to the bottom.

• Thus, the sequence diagram is two-dimensional.

• The left-to-right dimension is the layout of the objects,

and the top-to-bottom dimension shows the passage of
time.
© SERG
OBJECT DESTRUCTION

© SERG
Sequence diagram for View Patient
Information

© SERG
ATM Example

Software Design (UML) © SERG

Software Design (UML) © SERG