1

>

Modeling

Dr. Anıl Koyuncu

> System modeling
➢Process of developing abstract models of a system, with each
model presenting a different view or perspective of that system.

2
> System modeling
➢Using some kind of graphical notation, which is now almost
always based on notations in the Unified Modeling Language
(UML).

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

4
> Types of UML Diagrams

-5 -
> UML diagram types
➢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.
➢Activity diagrams, which show the activities involved in a process
or in data processing .
➢State diagrams, which show how the system reacts to internal and
external events.
➢Class diagrams, which show the object classes in the system and
the associations between these classes.

6
> Diagrams of UML
➢Modeling along 4 main viewpoints:
• User view (Who?)
• Use cases
• Static Aspect (What?)
• Describes objects and their relationships:
• Structuring with packages: Package diagrams
• Class diagrams
• Dynamic Aspects (When? How?)
• Sequence Diagram
• Collaboration Diagram
• State Diagram
• Activity Diagram
• Implementation Aspects (Where?)
• Component Diagram & deployment diagram

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

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

9
>

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

11
> Use Case vs Sequence Diagrams

Aspect Use Case Diagram Sequence Diagram

Represents functional requirements

Purpose Represents how objects interact in a scenario
and user interactions

Components
Actors, use cases, relationships Objects, lifelines, messages

Focus
High-level overview of functionalities Detailed view of interactions over time

12
 Use cases in the MHC-PMS involving the role
> ‘Medical Receptionist’
MHC-PMS

13
> Use case description
Use Case View Patient Info
Use Case ID UC-001
Actor Medical Receptionist
Use Case Description The Medical Receptionist retrieves patient information from the system and verifies the
patient's authorization status. This process includes requesting patient details, checking
authorization, and handling the response from the database.
Preconditions • The Medical Receptionist must be logged into the MHC-PMS.
• The patient must have an existing record in the PatientInfo database.

Postconditions • The patient information is retrieved and displayed if authorized.

• An error message is displayed if authorization fails.

14
> Use case description
Use Case View Patient Info
Basic Flow 1. The Medical Receptionist initiates a request for patient information.
2. The system sends the request to the MHC-PMS database.
3. The system retrieves the patient information and sends it back to the Medical
Receptionist.
4. The system checks if the retrieved patient information requires authorization:
1. If authorization is OK: The system provides the necessary patient details.
2. If authorization fails: The system returns an error message indicating that the
patient cannot be accessed without proper authorization.
Alternative Flows Alternative Flow 1: If the Medical Receptionist does not have the required access rights:
The system displays a message stating that the user does not have permission to
access the requested patient information.
Exceptions • The patient record is not found in the database.
• There is a system error that prevents retrieval of patient information.

Assumptions • The Medical Receptionist is trained to use the MHC-PMS effectively.

• The system is reliable and has proper database connectivity.
15
> Sequence diagram for View patient information

16
> Actor
➢a type of role played by an entity that interacts
with the subject (e.g., by exchanging signals and
data)
➢external to the subject (i.e., in the sense that an
instance of an actor is not a part of the instance
of its corresponding subject).
➢represent roles played by human users, external
hardware, or other subjects.

17
> Lifeline
➢A lifeline represents an individual participant in
the Interaction.
➢the dashed vertical lines extending downward
from the actor and system symbols, which
indicate the life of the sequence

18
> Activations
➢A thin rectangle on a lifeline) represents
the period during which an element is
performing an operation.
➢The top and the bottom of the of the
rectangle are aligned with the initiation
and the completion time respectively

19
> Call (Input) Message
➢A message defines a particular
communication between Lifelines of
an Interaction.
➢Call message is a kind of message
that represents an invocation of
operation of target lifeline.

20
 Return (Output) Message
>
➢A message defines a particular
communication between Lifelines of an
Interaction.
➢Return message is a kind of message
that represents the pass of information
back to the caller of a corresponded
former message.

21
> Self Message
➢Self message is a kind of message that
represents the invocation of message of
the same lifeline.

22
> Create Message
➢Create message is a kind of
message that represents the
instantiation of (target) lifeline.

23
 Destroy Message
>
➢Destroy message is a kind of
message that represents the request
of destroying the lifecycle of target
lifeline.

24
> Note
➢A note (comment) gives the
ability to attach various
remarks to elements. A
comment carries no semantic
force, but may contain
information that is useful to a
modeler.

25
> Message and Focus of Control

26
> Sequence Fragments
➢A sequence fragment is represented as a box, called a combined
fragment, which encloses a portion of the interactions within a
sequence diagram

27
> Sequence Fragments Types
Operator Fragment Type
Alternative multiple fragments: only the one whose condition is true
alt
will execute.
Optional: the fragment executes only if the supplied condition is true.
opt
Equivalent to an alt only with one trace.
par Parallel: each fragment is run in parallel.
Loop: the fragment may execute multiple times, and the guard
loop
indicates the basis of iteration.
Critical region: the fragment can have only one thread executing it at
region
once.
neg Negative: the fragment shows an invalid interaction.
Reference: refers to an interaction defined on another diagram. The
ref frame is drawn to cover the lifelines involved in the interaction. You can
define parameters and a return value.
sd Sequence diagram: used to surround an entire sequence diagram. 28
> Combined Fragment Example

29
 Guidelines for Constructing System Sequence
> Diagrams
➢Identify which scenario of use case you will depict. Purpose is to
discover messages, not to model logic. So more important to
clearly communicate a single scenario.
➢Draw a rectangle representing the system as a whole and extend
a lifeline under it.
➢Identify each actor who directly provides an input to the system or
directly receives an output from the system. Extend lifelines under
the actor(s).
➢Examine use case narrative to identify system inputs and outputs.
Ignore messages inside system.
➢Draw each external message as a horizontal arrow from the
actor's lifeline to the system or from the system to the actor.

30
 Guidelines for Constructing System Sequence
> Diagrams
➢Label inputs according to UML convention.
➢Add frames to indicate optional messages with conditions. Frames
can also indicate loops and alternate fragments.
➢Confirm that the messages are shown in the proper sequence
from top to bottom.

31
 Sequence Diagram for Modeling Use Case Scenarios
>

32
 Sequence Diagram for Modeling Use Case Scenarios
>

33
 Use cases in the MHC-PMS involving the role
> ‘Medical Receptionist’
MHC-PMS

34
> Sequence diagram for Transfer Data

35
> Additional Reading
➢https://developer.ibm.com/articles/the-sequence-diagram/

➢https://www.uml-diagrams.org/sequence-diagrams.html

➢https://guides.visual-paradigm.com/creating-sequence-diagrams-
in-uml-a-comprehensive-tutorial/

36
>

37