SE101 : Introduction to SE

BSSE/BSAI-II-B : Spring 2025

Topic: System Modeling

Uswah Ahmad Khan

Lecturer

Slides Credit: Dr. Qurat-ul-Ain

Recap
User Requirements
System Requirements

Functional Requirements

Non Functional Requirements

Requirement Engineering Process
❖ Establishing what services are required

3
 System Models

Abstract descriptions of systems whose

requirements are being analyzed

VS

Existing System New System

4
 System Models

VS

Existing System New System

• Models of the new system - used to
• Clarify what the existing system does
• Explain the proposed requirements to other system
• Basis for discussing its strengths and weaknesses
stakeholders
• Lead to requirements for the new system
• Discuss design proposals
5 • Document the system for implementation.
System Perspectives
External
Perspective

Interaction
System Perspective
Perspectives Structural
Perspective

Behavioral
Perspective
6
Unified Modeling Language (UML)
❖ A standardized, graphical “modeling language” for
communicating software design.
❖ Allows implementation-independent specification of:
○ user/system interactions (required behaviors)
○ partitioning of responsibility (OO)
○ integration with larger or existing systems
○ data flow and dependency
○ operation orderings (algorithms)
○ concurrent operations

https://software-engineering-book.com/web/uml/ 7
Motivation for UML
❖ UML is a fusion of ideas from several precursor modeling
languages.

❖ We need a modeling language to:

○ help develop efficient, effective and correct designs,
particularly Object Oriented designs.
○ communicate clearly with project stakeholders (concerned
parties: developers, customer, etc).
○ give us the “big picture” view of the project.

8
UML Pitfalls
1. rigorous syntax
2. semantics of UML

3. Arrow happiness
4. Diagram fever
5. General loopiness

9
UML Diagram Types 10
Typical uses of UML

❖ conceptual component diagrams in the concept

document.

❖ use cases and class diagrams in the requirements

document.

❖ class, sequence, state, package and deployment

diagrams in the architecture document.

11
Context Models
❖ Context models are used to illustrate the
operational context of a system - they show
what lies outside the system boundaries.
❖ Social and organizational concerns may
affect the decision on where to position
system boundaries.
❖ Architectural models show the system and
its relationship with other systems.

12
Context of MentCare system
Shared Data

Used for research 13

Problem with Context Models
❖ show that the environment includes several other
automated systems
❖ type of relationship not specified
▪ Data flow
▪ Connectivity
▪ Location

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

15
Activity Diagrams

Model business Identify candidate use Identify pre- and Model workflows Model complex
workflows cases, through the post-conditions for use between/within use workflows in operations
examination of business cases cases on objects
workflows

Model in detail complex

activities in a high level
activity diagram
Activity Diagrams - Vocabulary
❖ Activities and Actions
❖ Transitions and Activity Edges
❖ Tokens and Activity Nodes
❖ Control Nodes
○ Initial and Final Nodes
○ Forks and Joins
○ Decision and Merge Points
❖ States
❖ Swimlanes

18
Action
❖ An Action is a step in the overall activity
❖ There are four ways in which an action can be triggered
1. On Entry – as soon as the activity starts
2. Do – during lifetime of the activity
3. On Event – in response to an event
4. On Exit – just before the activity completes

20
Transitions
❖ A Transition is the movement from one activity to
another, the change from one state to another, or the
movement between a state and an activity in either
direction

❖ Transitions: unlabeled arrows from one activity to the

next
❖ Transitions take place when one activity is complete and
the next can commence

21
Forks
❖ A transition can be split into multiple paths and multiple
paths combined into a single transitions by using a
synchronization bar

❖ A fork is where the paths split

❖ A fork node splits the current flow through an activity

into multiple concurrent flows

22
Joins
❖ A join is where the paths meet

❖ The bar represents synchronisation of the completion of

those activities with arcs into the transition

❖ A join synchronises multiple flows of an activity back to a

single flow of execution

23
 Fork & Join
Node

Process model of involuntary detention 24

Decision & Merge Points
❖ A decision point shows where the exit transition from a
state or activity may branch in alternative directions
depending on a condition
❖ Each branched edge contains a guard condition (inside
[])
❖ A merge point brings together alternate flows into a
single output flow

25
States
❖ A state in an activity diagram is a point where some
event needs to take place before activity can continue
❖ Activities and States are similar
○ States carry out actions as activities do
○ Activities need to complete their actions before exiting
○ States are used to imply waiting, not doing
❖ It is possible to show an object changing states as it flows
through an activity

26
Start & End States
❖ The Start state is the entry point to a flow

❖ There can be several End states – multiple End states

can be used to indicated different follow-on processes
from a particular process

❖ Start and End states can have actions too

❖ Malformed diagrams – it is possible to form ill-formed

diagrams that require multiple activations of activities
or can allow deadlock 27
Problem Description : Process Order
❖ Once the order is received, the activities split into two
parallel sets of activities. One side fills and sends the
order while the other handles the billing.
❖ On the Fill Order side, the method of delivery is decided
conditionally. Depending on the condition either the
Overnight Delivery activity or the Regular Delivery
activity is performed.
❖ Finally the parallel activities combine to close the order.

29
Swimlanes
❖ Swimlanes (or activity partitions) indicate where
activities take place.
❖ Swimlanes can also be used to identify areas at the
technology level where activities are carried out

❖ Swimlanes allow the partition an activity diagram

so that parts of it appear in the swimlane relevant
to that element in the partition

31
Swimlanes
❖ Partitions may be constructed on the basis of:
1. the class and actor doing the activity
○ Partitioning by class and actor can help to identify new
associations that have not been documented in the class
model
2. the use case the activity belongs to
○ Partitioning by use cases can help document how use cases
interact

32
Class Activity: Student Enrollment in University
❖ The applicant hands a filled out copy of Enrollment Form.
❖ The registrar inspects the forms.
❖ The registrar determines that the forms have been filled
out properly.
❖ The registrar informs student to attend in university
overview presentation.
❖ The registrar helps the student to enroll in seminars
❖ The registrar asks the student to pay for the initial
tuition.

34
How to construct Activity Diagram
1. Finding system Actors, Classes and use cases
2. Identifying key scenarios of system use cases
3. Combining the scenarios to produce comprehensive workflows
described using activity diagrams
4. Where significant object behaviour is triggered by a workflow,
adding object flows to the diagrams
5. Where workflows cross technology boundaries, using swimlanes to
map the activities
6. Refining complicated high level activities similarly, nested activity
diagrams

35
Class Activity - Solution

36
Interaction Models
❖ Modeling user interaction is important as it helps to
identify user requirements.
○ interaction between user input, output
○ interaction between software developed and other system

❖ Use case diagrams and sequence diagrams may be

used for interaction modeling.

37
Use Case Diagram
❖ A case of a use of the system/product
❖ Mainly cares for the system’s expected behavior (what)
rather that how it is done!

❖ Tells a story
○ A sequence of events involving
○ Interactions of a user with the system
❖ Specifies one aspect of the behavior of a system, without
specifying the structure of the system

38
Use Case Descriptions
❖ actors - something with a behavior or role, e.g., a
person, another system, organization.

❖ scenario - a specific sequence of actions and interactions

between actors and the system, a.k.a. a use case instance

❖ use case - a collection of related success and

failure/alternate scenarios, describing actors using the
system to support a goal.

39
Use Case Descriptions - Actors
❖ Include all user roles that interact with the system
❖ Include system components only if they are responsible
for initiating/triggering a use case.

40
Use Case Descriptions – User Story
❖ An abbreviated description of a use case
❖ Used in agile development

Answers 3 questions:
1. Who? As a <type of user>,
2. Does What? I want <some behavior from the system>
so that <some value is achieved>
3. And Why?

41
Transfer-data use case in the MentCare system

42
Tabular description of the ‘Transfer
data’ use-case

43
Use Case Diagram: Actor
❖ Name
Actor is someone interacting with use case (system
function). Named by noun.
❖ can play different roles;

❖ Actor triggers use case.

❖ Actor has responsibility toward the system (inputs), and
Actor have expectations from the system (outputs).

44
Use Case Diagram: Use Case
❖ System function (process – automated or manual).
❖ Named by verb.
Do Something

Use Case Diagram: Communication Link

❖ The participation of an actor in a use case is shown
by connecting an actor to a use case by a solid link.

45
Linking Use Cases
1. Association relationships
○ an association is a relationship between two classifiers,
such as classes or use cases
2. Generalization relationships
○ One element (child) "is based on" another element
(parent)
3. Include relationships
○ One use case (standard) includes the functionality of
another (inclusion case)
4. Extend relationships
○ One use case (extension) extends the behavior of another 46
(standard)
Association between Use Cases and Actors
❖ Actors may be connected to use cases by associations,
indicating that the actor and the use case communicate
with one another using messages.

updating
grades

faculty

47
Generalization
❖ The child use case inherits the behavior and meaning of
the parent use case.
❖ The child may add to or override the behavior of its
parent.

parent

child
48
Include Relationship
❖ The standard use case explicitly incorporates the
behavior of another use case at a location specified.
❖ Supports re-use of functionality

standard <<include>>
included

49
Include Relationship
❖ Include relationship – a standard case linked to
a mandatory use case.
❖ The standard use case includes the mandatory
use case (use the verb to figure direction
arrow).
Example: to Authorize Car Loan (standard use
case), a clerk must run Check Client’s Credit
History (include use case).

❖ Standard use case can NOT execute without the

include case 🡪 tight coupling 50
Include Relationship

❖Enables us to avoid describing the same flow of

events several times by putting the common behavior
in a use case of its own.

51
Extend Relationship
❖ The standard use case implicitly incorporates the
behavior of another use case at certain points called
extension points.
❖ The standard use case may stand alone, but under
certain conditions its behavior may be extended by the
behavior of another use case.

<<extend>>
standard extending
52
Extend Relationship
❖ Enables to model optional behavior or branching under
conditions.

53
Extend Relationship
❖ Extend relationship – linking an optional use
case to a standard use case.
❖ The optional use case extends the standard
use case
Example: Register Course (standard use
case) may have Register for Special Class
(extend use case) – class for non-standard
students, in unusual time, with special topics,
requiring extra fees…).
❖ Standard use case can execute without the
extend case 🡪 loose coupling
54
55
Class Activity: Library Management System
❖ Construct a use case diagram for a library management
system. The system is used by the librarian, the assistant
librarian and the clients.
❖ The librarian, can add books, delete books, add clients,
delete clients, list books, list clients, check in/out books
❖ The assistant librarian has all the functionality of the
librarian except for add/delete for books and clients
❖ Clients may only check in/out books

56
 Class Activity: Library Management
System - Solved
❖ Construct a use case diagram for a library management
system. The system is used by the librarian, the
assistant librarian and the clients.
❖ The librarian, can add books, delete books, add
clients, delete clients, list books, list clients, check
in/out books
❖ The assistant librarian has all the functionality of the
librarian except for add/delete for books and clients
❖ Clients may only check in/out books

57
Class Activity: Library Management
System - Solved

58
 How to create use case diagram (1/2)

1. List main system functions (use cases) in a column:

– think of business events demanding system’s response
– users’ goals/needs to be accomplished via the system
– Create, Read, Update, Delete (CRUD) data tasks
– Naming use cases – user’s needs usually can be translated in
data tasks
2. Draw ovals around the function labels-> function name convention
to be follow

3. Draw system boundary

59
 How to create use case diagram (2/2)

4. Draw actors and connect them with use cases (if more intuitive, this
can be done as step 2)
5. Specify include and extend relationships between use cases (yes, at
the end - not before, as this may pull you into process thinking,
which does not apply in Use Case diagramming).

60
Reading
❖ Sommerville Chapter#5
❖ Pressman Chapter#7

61
Thanks!
Any comment/questions?

62