SYSTEM MODELING

1
Systems, Models and System
Modeling

2
 System

• A system is an organized set of communicating

parts
– A car, composed of four wheels, a chassis, a body,
and an engine, is designed to transport people
– A payroll system, composed of a computer,
printers, software, and the payroll staff, is
designed to issue salary checks for employees of a
company
• Parts of a system can in turn be considered as
simpler systems called subsystems
 Model

• A model is a simplification of reality

• Modeling means constructing an abstraction of a
system that focuses on interesting aspects and
ignores irrelevant details
• We build models so that we can better
understand the system we are developing.
• We build models of complex system because we
cannot comprehend such a system in its entirety.
 System Modeling
• System Modelling is the process of developing
abstract models of a system each representing
a different view or perspective of that system
• You may develop models of both the existing
system and the system to be developed
– Models of the existing system are used during requirements
engineering
• Help clarify what the existing system does and can be used as a basis
for discussing its strengths and weaknesses
– Models of the new system are used during requirements
engineering to help explain the proposed requirements to
other system stakeholders
 System Perspective
• You may develop different models to represent the
system from different 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
 Unified Modeling Language

• UML is a standard language for modeling

software systems
– Serves as a bridge between the requirements
specification and the implementation.
– Provides a means to specify and document the
design of a software system.
– UML is process and programming language
independent.
– UML is particularly suited to object-oriented
program development.
 Types of UML Diagrams
• 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 .
• 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
Context Models

10
 Context Models

• Context models are used to illustrate the

operational context of a system - they show
what lies outside the system boundaries.
– Context models normally show that the
environment includes several other automated
systems
The Context of University Admission System
The context of the MHC-PMS
Context diagram of Online System
Interaction & Process Models

Business Process & Functional Modeling

Atique Zafar

16
Overview

17
18
 Bridging with Requirements
Engineering Process
• As a first step, the project team gathers
requirements from the users.
• The project team then identifies the business
processes and their environment using use
cases and use-case diagrams.
• Next, users work closely with the team to
model the business processes in the form of
activity diagrams, and the team documents
• the business processes by creating a use-case
description for each use case.
19
• Finally, the team verifies and validates the
business processes by ensuring that all three
models (use-case diagram, activity diagram(s),
and use case descriptions) agree with one
another.
• Once the current understanding of the
business processes is documented in the
functional models, the team is ready to move
on to structural modeling
20
 The Scenario View
• The scenario view describes the functionality of the system,
i.e., how the user employs the system and how the system
provides services to the users.

• This view provides a foundation for the other four views

• It helps designers to discover architecture elements and to

validate the architecture design afterward.

• So, the scenario view helps to make the software architecture

consistent with functional and nonfunctional requirements.

21
 USE-CASE DIAGRAMS/ Interaction Models

• use-case diagram provides a simple,

straightforward way of communicating to the
users exactly what the system will do.
• A use-case diagram illustrates in a very simple
way the main functions of the system and the
different kinds of users that will interact with
it.

22
 Elements of Use-Case Diagrams

• The elements of a use-case diagram include

– actors, use cases, subject boundaries, and a set of
relationships among actors, actors and use cases,
and use cases.
• These relationships consist of
– association, include, extend, and generalization
relationships.

23
 Actors

• An actor: Is a person or system that derives benefit from and

is external to the subject.
• Is depicted as either a stick figure (default) or, if a nonhuman
actor is involved, a rectangle with <<actor>> in it (alternative).
• Is labeled with its role.
• Can be associated with other actors using a
specialization/superclass association, denoted by an arrow
with a hollow arrowhead.
• Is placed outside the subject boundary.
24
 Use Case

• Represents a major piece of system

functionality.
• Can extend another use case.
• Can include another use case.
• Is placed inside the system boundary.
• Is labeled with a descriptive verb–noun phrase.

25
 A Subject Boundary
• Includes the name of the
subject inside or on top.
• Represents the scope of
the subject, e.g., a
System or an individual
business process.

26
 Use case Diagram Relationships

• An association relationship:
– Links an actor with the use case(s) with which it
interacts.
• An include relationship:
– Represents the inclusion of the functionality of
one use case within another.
– Has an arrow drawn from the base use case to the
used use case.

27
 Use case Diagram Relationships

• An extend relationship:
– Represents the extension of the use case to
include optional behavior.
– Has an arrow drawn from the extension use case
to the base use case.
• A generalization relationship:
– Represents a specialized use case to a more
generalized one.
– Has an arrow drawn from the specialized use case
to the base use case.
28
Example

29
 Format and guideline to write use case(s)

Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1.2.1
Use Case Name: Enter a short name for the Use Case using an active verb phrase. e.g.
Withdraw Cash
Actors: [An actor is a person or other entity external to the software system
being specified who interacts with the system and performs use
cases to accomplish tasks. Different actors often correspond to
different user classes, or roles, identified from the customer
community that will use the product. Name the actor that will be
initiating this use case (primary) and any other actors who will
participate in completing the use case (secondary).]
Description: [Provide a brief description of the reason for and outcome of this use
case.]
Trigger: [Identify the event that initiates the use case. This could be an
external business event or system event that causes the use case to
begin, or it could be the first step in the normal flow.]

30
 Preconditions: [List any activities that must take place, or any conditions that must
be true, before the use case can be started. Number each pre-
condition. e.g.
1. Customer has active deposit account with ATM privileges
2. Customer has an activated ATM card.]
Postconditions: [Describe the state of the system at the conclusion of the use case
execution. Should include both minimal guarantees (what must
happen even if the actor’s goal is not achieved) and the success
guarantees (what happens when the actor’s goal is achieved. Number
each post-condition. e.g.
1. Customer receives cash
2. Customer account balance is reduced by the amount of the
withdrawal and transaction fees]

31
Normal Flow: [Provide a detailed description of the user actions and system
responses that will take place during execution of the use case under
normal, expected conditions. This dialog sequence will ultimately lead
to accomplishing the goal stated in the use case name and description.
1. Customer inserts ATM card
2. Customer enters PIN
3. System prompts customer to enter language performance English
or Spanish
4. System validates if customer is in the bank network
5. System prompts user to select transaction type
6. Customer selects Withdrawal From Checking
7. System prompts user to enter withdrawal amount
8. …
9. System ejects ATM card]

32
 Alternative [Document legitimate branches from the main flow to handle special
Flows: conditions (also known as extensions). For each alternative flow
[Alternative Flow 1 –
Not in Network] reference the branching step number of the normal flow and the
condition which must be true in order for this extension to be executed.
e.g. Alternative flows in the Withdraw Cash transaction:
4a. In step 4 of the normal flow, if the customer is not in the bank
network
1. System will prompt customer to accept network fee
2. Customer accepts
3. Use Case resumes on step 5
4b. In step 4 of the normal flow, if the customer is not in the bank
network
4. System will prompt customer to accept network fee
5. Customer declines
6. Transaction is terminated
7. Use Case resumes on step 9 of normal flow
Note: Insert a new row for each distinctive alternative flow. ]

33
Exceptions: [Describe any anticipated error conditions that could occur during
execution of the use case, and define how the system is to respond to
those conditions.
e.g. Exceptions to the Withdraw Case transaction

2a. In step 2 of the normal flow, if the customer enters and invalid PIN
1. Transaction is disapproved
2. Message to customer to re-enter PIN
3. Customer enters correct PIN
4. Use Case resumes on step 3 of normal flow]
Includes: [List any other use cases that are included (“called”) by this use case.
Common functionality that appears in multiple use cases can be split out
into a separate use case that is included by the ones that need that
common functionality. e.g. steps 1-4 in the normal flow would be
required for all types of ATM transactions- a Use Case could be written
for these steps and “included” in all ATM Use Cases.]

34
 [Identify any additional requirements, such as nonfunctional
Special/Quality requirements, for the use case that may need to be addressed during
Requirements design or implementation. These may include performance
(other requirements or other quality attributes.]
information):
Assumptions: [List any assumptions that were made in the analysis that led to
accepting this use case into the product description and writing the
use case description.
e.g. For the Withdraw Cash Use Case, an assumption could be:
The Bank Customer understands either English or Spanish
language.]
Business Rule: Some business rules constrain which roles can perform all or parts
of a use case. Perhaps only users who have certain privilege levels
can perform specific alternative flows. That is, the rule might
impose preconditions that the system must test before letting the
user proceed. Business rules can influence specific steps in the
normal flow by defining valid input values or dictating how
computations are to be performed.

35
 Activity Diagram/ Process Models
• Activity diagrams are used to model the
behavior in a business process independent of
objects.
• Activity diagrams can be used to
– model everything from a high-level business
workflow that involves many different use cases,
• to the details of an individual use case,
– all the way down to the specific details of an individual
method.

• In a nutshell, Activity diagrams can be used to

model any type of process.
36
Syntax of Activity Diagram

37
Syntax of Activity Diagram

38
 Elements of an Activity Diagram
• Activity diagrams portray the primary
activities and the relationships among the
activities in a process

39
 Actions and Activities
• Actions and activities are performed for some
specific business reason.
• Actions and activities can represent manual or
computerized behavior.
• They should have a name that begins with a
verb and ends with a noun
– (e.g., Get Patient Information or Make Payment
Arrangements).
• Names should be short, yet contain enough
information so that the reader can easily
understand exactly what they do. 40
 Actions and Activities
• The only difference between an action and an
activity is that an activity can be decomposed
further into a set of activities and/or actions,
– whereas an action represents a simple non
decomposable piece of the overall behavior being
modeled.
• Typically, only activities are used for business
process or workflow modeling.
• In most cases, each activity is associated with
a use case
41
 Object Nodes
• Activities and actions typically modify or transform
objects.
– Object nodes model these objects in an activity
diagram.
• The name of the class of the object is written inside
the rectangle.
• Essentially, object nodes represent the flow of
information from one activity to another activity.
– The simple appointment system portrayed in
Figure 4-8 shows object nodes flowing from Get
Patient Information activity.
42
 Control Flows and Object Flows
• Th ere are two different types of flows in
activity diagrams:
– Control flows model the paths of execution
through a business process.
– A control flow is portrayed as a solid line with an
arrowhead on it showing the direction of flow.
Control flows can be attached only to actions or
activities.
– Figure 4-8 portrays a set of control flows through
the doctor’s office’s appointment system.

43
 Control Flows and Object Flows
• Object flows model the flow of objects
through a business process.
– Because activities and actions modify or transform
objects,
– object flows are necessary to show the actual
objects that flow into and out of the actions or
activities.
– An object flow is depicted as a dashed line with
an arrowhead on it showing the direction of flow.
– An individual object flow must be attached to an
action or activity on one end and an object node
on the other end. Figure 4-8
44
 Control Nodes
• There are seven different types of control nodes in an activity
diagram:
– Initial, final-activity, final-flow, decision, merge, fork, and
join.
• An initial node portrays the beginning of a set of actions or
activities.
– An initial node is shown as a small filled-in circle.
• A final-activity node is used to stop the process being
modeled.
– Any time a final-activity node is reached, all actions and
activities are ended immediately, regardless of whether
they are completed.
– A final-activity node is represented as a circle surrounding
a small, filled-in circle, making it resemble a bull’s-eye.
45
 Control Nodes
• A final-flow node is similar to a final-activity
node, except that
– it stops a specific path of execution through the
business process but allows the other concurrent
or parallel paths to continue.
– A final-flow node is shown as a small circle with an
X in it.

46
 Decision and Merge nodes
• The decision and merge nodes support
modeling the decision structure of a business
process.
– The decision node is used to represent the actual
test condition that determines which of the paths
exiting the decision node is to be traversed.
– In this case, each exiting path must be labeled
with a guard condition.
– A guard condition represents the value of the test
for that particular path to be executed.
– In Figure 4-8
47
 Decision and Merge nodes
• The merge node is used to bring back
together multiple mutually exclusive paths
that have been split based on an earlier
decision
– (e.g., the old- and new-patient paths in Figure 4-8
are brought back together near the bottom of the
diagram).

48
 Fork and Join nodes
• The fork and join nodes allow parallel and concurrent
processes to be modeled.
• The fork node is used to split the behavior of the
business process into multiple parallel or concurrent
flows.
• Unlike the decision node, the paths are not mutually
exclusive
– (i.e., both paths are executed concurrently).
• For example, in Figure 4-10
• The join node simply brings back together the
separate parallel or concurrent flows in the business
process into a single flow.
49
 Swimlanes
• Activity diagrams can model a business
process independent of any object
implementation.
– However, there are times when it helps to break
up an activity diagram in such a way that it can be
used to assign responsibility to objects or
– individuals who would actually perform the
activity.
– This is especially useful when modeling a business
workflow and is accomplished through the use of
swimlanes. In Figure 4-10,
50
51
52
Example of Swimlanes
This is an example of UML activity diagram describing
behavior of the Purchase Ticket use case.
• Activity is started by Commuter actor who needs
to buy a ticket.
• Ticket vending machine will request trip
information from Commuter. This information will
include number and type of tickets, e.g. whether it
is a monthly pass, one way or round ticket, route
number, destination or zone number, etc.
• Based on the provided trip info ticket vending
machine will calculate payment due and request
payment options. Those options include payment
by cash, or by credit or debit card.
• If payment by card was selected by Commuter,
another actor, Bank will participate in the activity
by authorizing the payment.
• After payment is complete, ticket is dispensed to
the Commuter. Cash payment might result in
some change due, so the change is dispensed to
the Commuter in this case.
• Ticket vending machine will show some "Thank
You" screen at the end of the activity.
53