Software Engineering &

Project Management
Introduction to Software Engineering
and UML (part 2)
Hong Kong Metropolitan University

Autumn 2024/25
Presentation
1
Tutorial Group 2
Unit 1
Introduction to Software
Engineering and UML
(Part #2)

2
U
Unit 1
COMPS356

Introduction to Software
Engineering and UML

1.6 Use Case Diagrams 1.1 Introduction to Software

Engineering
1.7 Class Diagrams 1.2 Software Engineering
From Development Activities
Tutorial #1 1.12 Software Engineering
1.8 Interaction Diagrams …..
Concepts
1.9 Statechart Diagrams 1.3 An Overview of UML
1.4 Modeling Concepts
1.10 Activity Diagrams 1.5 UML tools

1.11 Diagram organization and extensions

3
1.6 Use Case
Diagram

4
 Unit: 1.6

I UML Use Case

Diagram

What is Use  Represent a function of the system

Case  Show who is the actor (user) of the function

Diagram?  It is used in the requirement elicitation activity

5
 Unit: 1.6

I UML Use Case

Diagram: Actor
 Actors are external entities interact with the
system
o Users: System administrators, a bank customer,
etc.
o Another system: database system, connected
What is Use systems, etc.

Case  Use case describes the system from the actor’s

Diagram? point of view, also known as external behavior

6
 Unit: 1.6

 FieldOfficer

I UML Use Case

Diagram: Actor
o ReportEmergency

 Dispatcher
o ReportEmergency
o OpenIncident
o AllocateResource

What is Use
Case Actor communicates
with use case

Diagram? Boundary of the

system
7
 Unit: 1.6

I UML Use Case Diagram:

Use Case Template
Use Case
Description
#1

Use Case
Description
#2

Use Case
Description
#3
Use Case Template

8
 Unit: 1.6

I UML Use Case Diagram:

Use Case Template
Name
The name of the use case
Entry Condition (precondition)
Describes the conditions that
uniquely identify a use case need to be satisfied before the
with no ambiguity use case is initiated

Emphasize
the use of Participating Actors Flow of Events
Actors that are interacting with Describes the sequences of
natural the use case interactions of the use case
which are to be numbered for
language reference

Exit Condition (postcondition) Quality Requirements

Use Case Template Describes the conditions that Requirements that are not
are satisfied after the related to the functionality of
completion of the use case the system
9
I
Unit: 1.6
Use Case Name: Purchase Book
UML Use Case Diagram: Initiating Actor: Registered User
Stakeholders and Interests:
Use Case Template  Registered User: Wants to purchase a book and
receive confirmation.
Scenario Question:  System Administrator: Wants to ensure successful Extensions (Alternative Flows):
You are the lead system analyst for a startup sales and maintain a record of all transactions. 5a. Payment Gateway declines the
developing an online bookstore platform.  Payment Gateway: Interested in processing
payment.
One of the key features that your payments and notifying the system of success or
failure. 1.System displays an error message
stakeholders want is the ability for users to
Preconditions: to the user indicating payment
purchase books online. They are concerned
 User is logged in. failure.
about ensuring a seamless and secure
 User has selected at least one book to purchase.
experience for users, from selecting a book 2.User is prompted to provide an
 User has a valid payment method saved or available.
to receiving confirmation of their purchase. alternate payment method or
Postconditions:
 The book is marked as "purchased" in the user's check the validity of the current
Given this scenario: account. payment details.
1. How would you describe the process of a  The book stock count is decreased by one. 7a. Book stock count is zero (sold out).
user purchasing a book on this platform?  User receives a confirmation email with purchase 3.System displays a message
2. What are the prerequisites that need to details. indicating the book is sold out.
be in place before a user can initiate a Main Success Scenario (Basic Flow):
4.Transaction is cancelled, and user is
purchase? 1. User navigates to the shopping cart.
2. User reviews selected books and chooses "Proceed to not charged.
3. How should the system respond if there's
Checkout." Special Requirements:
an issue with the payment or if the book
3. System prompts user to select a payment method or  System should process payments
is out of stock?
enter new payment details. within 60 seconds to ensure a smooth
4. Are there any additional requirements
4. User provides or selects payment details and chooses
or considerations the system should take user experience.
"Purchase."
into account during this process? 5. System communicates with the Payment Gateway to Frequency of Occurrence:
10
process payment.  Hundreds of times a day.
6. Payment Gateway confirms successful payment. Miscellaneous:
 Unit: 1.6

I UML Use Case

Diagram: Scenarios
Scenario
is an instance of use case
describing a concrete set of
actions

Use case Scenario is used as example for

What is Use illustrating common cases, focus
on understandability
is an abstraction describing
Case all possible scenarios Scenarios are assumed to have
involving the described same set of entry and exit
Diagram? functionalities conditions as in the use case
11
 Unit: 1.6

I
UML Use Case Diagram:
Scenario Template

Simple Scenario: Online Bookstore Imagine an

online bookstore where customers can browse
books, add them to their cart, and make a purchase.
The bookstore also has an admin who can add or
remove books from the inventory.
Use Cases
Actors Relationships
• Browse Books
User
• User can "Browse
• Add to Cart
Admin
Books", "Add to
• Purchase Books
Cart", and
• Add Book to Inventory (for Admin)
"Purchase Books".
• Remove Book from Inventory (for
Admin)
• Admin can "Add
Book to Inventory"
and "Remove Book 12
from Inventory".
 Unit: 1.6

I
UML Use Case Diagram:
Scenario Template

Simple Scenario: Online Bookstore Imagine an

online bookstore where customers can browse
books, add them to their cart, and make a purchase.
The bookstore also has an admin who can add or
remove books from the inventory.
Use Cases
Actors Relationships
• Browse Books
User
• User can "Browse
• Add to Cart
Admin
Books", "Add to
• Purchase Books
Cart", and
• Add Book to Inventory (for Admin)
"Purchase Books".
• Remove Book from Inventory (for
Admin)
• Admin can "Add
Book to Inventory"
and "Remove Book 13
from Inventory".
 Unit: 1.6

I
UML Use Case
Diagram: Scenario
Template
Discussion :
Bank ATM

What is Use
Case
Diagram?
14
Unit: 1.6

15
 Unit: 1.6 include
Used for reducing the

I
Communication complexity by identifying
UML Use Case commonalities in different use
cases (repeated functions)
Diagram: Actor and use case communicates
when information is exchanged The ViewMap use case is used

Relationships between them in both OpenIncident and

AllocateResources use cases
The line between the actor and use
case denoted an access to
functionality

In use case diagrams,

relationships define how actors inheritance
and use cases interact, allowing extend One use case can specialize a
Used for reducing the complexity general one by adding more detail
for clear representation of
by extending a use case by adding
The AuthenticateWithPassword and
system functionality and user events, normally exceptions AuthenticateWithCard use cases are specialization
of the general use case Authenticate
interactions. Properly using The ConnectionDown use case
extends the OpenIncident and
these relationships ensures AllocateResources use cases

clarity and accuracy in

depicting system behavior. 16
 Unit: 1.6

I UML Use Case Diagram:

Relationships

1. Solid Line: Represents a direct association between an actor and a use case. In the diagram, the "Actor" has a
direct association with "Use Case A" using a solid line.
2. Dotted Line: Represents relationships like "include" or "extend" between use cases. In the diagram, "Use Case
A" includes or extends "Use Case B" using a dotted line.
3. Generalization (Solid Line with Hollow Triangle Arrowhead): Represents a generalization or inheritance
relationship between use cases. In the diagram, "Use Case C" is a specialized form of "Use Case A" using a
generalization arrow.
17
 Unit: 1.6

I UML Use Case Diagram:

Relationships

Relationships
Include
The "Login" use case is included in the
"Browse Products" use case. This
means that every time a customer
browses products, they must first log
in.
Extend
The "Apply Discount" use case extends
the "Purchase Product" use case. This
means that under certain conditions, a
discount can be applied during the
purchase process.
Use Cases
Inheritance (Generalization) Actors
• Browse Products
The "Manage Electronics" use case is a Customer
specialized form of the "Manage • Purchase Product
Admin
Inventory" use case. This relationship
• Apply Discount
is represented by a solid line with a
hollow triangle arrowhead pointing to • Login
the more general use case.
• Manage Inventory
18
• Manage Electronics
 Unit: 1.6

I
UML Use Case
Diagram: Summary
 Function Models: Utilized in the template form for use case diagrams
and their accompanying descriptions.

 User's Perspective: These models effectively capture the system's

functionality from the viewpoint of the user.

 Requirement Elicitation: They play a pivotal role during this process,

ensuring that user needs and system functionalities align.

 Foundation for Development: Setting the foundation and direction

for the subsequent stages of software development.
19
1.7 Class
Diagrams

20
 Unit: 1.7

I Class Diagrams
 Show the structure of a system

 Show the associations between classes

 It is used in the analysis activity and detailed

in the system and object design activities

21
 Unit: 1.7

I Class Diagrams:
3 Compartments
FieldOfficer Class Name
 Class name
name : string
Attributes
 Attributes with data type badgeNumber : integer

 Operations with submitReport() Operations

parameters (if any)

22
 Unit: 1.7

I Class Diagrams:
3 Compartments All of them are valid

FieldOfficer
Attributes and Operations name : string FieldOfficer
badgeNumber : integer
can be omitted for name : string
submitReport() badgeNumber : integer
simplicity

FieldOfficer
FieldOfficer
submitReport()

23
Unit: 1.7

Class diagrams Object diagrams

Class Diagrams:
Class vs Object I
bob:FieldOfficer  Object Diagram shows the instance of
FieldOfficer

name : string name = “Bob D.” a class

badgeNumber : integer badgeNumber =132
 Names are underlined and followed
by class name with a colon as

alice:FieldOfficer separator

name = “Alice W.”  Actual values of attributes are shown

badgeNumber = 23

24
 Unit: 1.7

I Class Diagrams: 1
EmergencyReport Incident
Association - Example reportsGenerated
*
1..*
reports
incidentsGenerated
*

 Association represents the

FieldOfficer Dispatcher
relationship between classes 1
name : string name : string 1
 At the ends of association are badgeNumber : integer author badgeNumber : integer initiator

Multiplicity and Role

 Multiplicity is the set of integer values indicating the  Role is the meaning of the association between the
number of links that can legitimately originated connecting classes
 The set of integer values can be of any kind (e.g. prime  It is optional
numbers) but normally fell into 3 categories  Example
o One-to-one: 1 at both ends o FieldOfficer is the author of EmergencyReport
o One-to-many: 1 at one end while 0..n, 1..n or * at the other o EmergencyReport are reportsGenerated of FieldOfficer
o Many-to-many: 0..n, 1..n or * at both ends
25
 Unit: 1.7

I Class Diagrams: Unary

Association - Example
ClassA

+doSomething()
- myB
ClassB

+actionB()

Person has-a
Address ClassA ClassB
(ClassA) (ClassB)
- myB : ClassB

 Person know its address +doSomething() +actionB()

ClassA knows about ClassB

 Address doesn’t know who is living ClassA ClassB

there - myB : ClassB

- myB

ClassB knows nothing about ClassA

+doSomething() +actionB()
26
 Unit: 1.7

I Class Diagrams: Unary

Association - Example

Person Address

- address - street : String

- name : string - city : String
- zip : String

+doSomething() + toString() : String

27
Unit: 1.7

I
Class Diagrams
(Association): Unary
Association: Aggregation
i.e. whole-part relationship

Pool Slide
(ClassA) (ClassB)

The slide is part of the lake

ClassB is part of ClassA

28
Unit: 1.7

I
Class Diagrams
(Association): Unary
Association: Composition
i.e. whole-part relationship

Company Department
Composition where the
lifecycle of the part class
depends on that of the whole A department is part of a company. The
class construction and destruction of a
department depends on the company
29
Unit: 1.7

I
Class Diagrams
(Associations):
Binary Association

ClassC ClassD

 ClassC knows about ClassD and

 ClassD knows about ClassC

30
Unit: 1.7

I Class Diagrams:
Inheritance

 Inheritance is the relationship

between generalized class
and specialized class
 We use italic format on
abstract class name

31
Unit: 1.7

M
Class Diagrams
(Associations):
Multiplicity
0 .. 1 an optional instance (zero or one)

n exactly n instances

* zero or more instances

1 .. * one or more instances

n .. m n to m instances

32
Unit: 1.7

M
Class Diagrams
(Associations):
Multiplicity –
composition

1
Kitchen
inheritance

Example – when
1
designing a house
House Bath Room
1 .. *
aggregation
independent
Bedroom
0 .. 1

Mortgage one or more

instance
1

Mailbox
associated
but not part of the house
33
Unit: 1.7

I Class Diagrams:
More OO terms

 Abstract class is a class without actual instantiation, i.e. no objects

 Class with actual instantiation is called concrete class
 Operations are the behavior of the class of objects can perform
 An object request another object to perform certain operation
through sending message
 Method is the implementation of operation

34
 Unit: 1.7

I Class Diagrams:
Summary  Class Diagrams is used for describing the structure of
the system
 During analysis, Class Diagrams is used for formalizing
the application domain, i.e. the scope and boundary
of the system
 The result of analysis is the analysis model
Summary  Detail implementation is not the focus in analysis and
Class Diagrams will be used in later stages again
35
1.8 Interaction
Diagrams

36
 Unit: 1.8

IInteraction
Diagrams



Show the interaction between the objects,
mostly for a particular use case

Interaction is done by sending message with

arguments (if any)
 The object received the message will execute a
corresponding method
What is
 Two kinds of interaction diagrams: Sequence
Interaction
Diagram and Communication Diagram
Diagram?
37
 Unit: 1.8

I
Interaction
Diagrams:
 Interaction between objects are arranged
Sequence Diagram
horizontally and time vertically
 Messages represented by horizontal headed
arrows
 Actor may appear on the sequence diagram
What is  Lifeline is the dotted line showing the life time of
Sequence an object
Diagram?  Activations are represented by tall thin rectangles
38
 Unit: 1.8

I
Interaction
Diagrams:
Sequence Diagram

What is
Sequence
Diagram?
39
 Unit: 1.7

I Interaction Diagrams:
Sequence Diagram
conditional notations

 Condition is presented
by square brackets, for
example, [i>0], [i<=1],
etc.

 Repetition is presented
by an asterisk: * 40
 Unit: 1.7

I Interaction Diagrams:
Object creation and
destruction

 Object creation by sending

create message

 Object destruction
represented by a cross

41
 Unit: 1.7

I Interaction Diagrams:
Time Constraint

Specify time
constraint
between the
message sent by
a notes

42
 Unit: 1.7

I Interaction Diagrams: Message sequence:

1: pressButton1And2()
Communication Diagram 1.1: blinkHours()
2: pressButton1()
2.1: blinkMinutes()
3: pressButton2()
3.1: incrementMinutes()
 Represent same 3.1.1: refresh()
4: pressButton1And2()
information as 4.1: commitNewTime()
4.2: stopBlinking()
sequence diagram

 No constraint on
arranging the message
sent horizontally and
time sequence
vertically 43
 Unit: 1.8

I UML: Interaction Diagrams - Show the interaction between objects

Communication diagram emphasize the

organization of objects rather than the time
Sequence diagram emphasize the time ordering ordering.
of messages
44
Source: https://www.w3computing.com/systemsanalysis/sequence-communication-diagrams/
 Unit: 1.7

I Interaction Diagrams: Sequence

diagram vs Communication diagram

Discussion :
What are the pros and cons
between sequence diagram and
communication diagram?

45
 Unit: 1.7

I Interaction Diagrams: Sequence

diagram vs Communication diagram

Strengths Strengths
clearly shows Space economical—
sequence or time flexibility to add
ordering of messages new objects in two
Sequence with large set of dimensions Communic
detailed notation
Diagram ation
options
Weakness Weakness Diagram
forced to extend to more difficult to see
the right when sequence of
adding new objects; messages with
consumes horizontal fewer notation
space options

46
1.9 State Machine
Diagrams

47
Unit: 1.9

 Show the behavior of a single object throughout the

whole system
 Round rectangle represents a state

I
 A transition represented by an arrow
UML: State
 Solid dark circle represents initial state
Machine
Diagrams  Circle surrounds a dark circle represents final state

48
 Unit: 1.9

I State Machine Diagrams:

event/ action
 A transition can be
o Event
o Time
o Condition

 Possibly no final state

 Event and action are
separated by a slash
49
 Unit: 1.9

I State Machine
Diagrams: actions
 Actions are small atomic behaviors executed in a short period of time
 There are actions within a state
 Action occurs in the following situations:
o Transition (including internal transition)
o A state is entered
o A state is exited
 A ‘do’ event is within a state which causes the corresponding action
to perform repeatedly
50
 Unit: 1.9

I
Refi n e d S tate M a c h in e D ia g ra m s wit h
State Machine Diagrams: a c ti o n s w it h in a state
internal transition vs self
transition
 pressButton1/blink next
number is an internal
transition, the event
pressButton1 caused the
action blink next number but
does not change the state of
the object
 self transition will not change
the state of the object as well
but the exit and enter events
will be triggered as well
51
 Unit: 1.9

I State Machine Diagrams:

internal transition vs self
transition
Refi n e d S tate M a c h in e D ia g ra m s wit h
n e ste d state s

 Nested states are states within a

state, used for sub-dividing a
state into serveral internal states
 It is used for reducing the
complexity of internal transition
(it really depends)
 Use double colon to fully qualify
a nested state, e.g.
SetTime::BlinkHours

52
 Unit: 1.9

I State Machine
Diagrams

 Represent the non-trival behavior of a

subsystem or an object
 Identify object attributes and refine the
object behavior description of an object
 State Machine Diagrams will be used in
Summary analysis and system design
53
1.10 Activity
Diagrams

54
Unit: 1.10

I UML: Activity
Diagrams

 Activity represents the execution of a set

of operations

 Activity Diagrams shows the control flow

between activities

 A synchronization bar can be used for

activities having temporal dependency

55
Unit: 1.10

I Activity Diagrams:
action state

 Action state: An associated action of a state

 Name of a state denotes a condition
 Name of an action state denotes an action
 Activity Diagrams can be considered as statechart diagram where states
are action state
 Initial state and final state are optional 56
Unit: 1.10

I Activity Diagrams:
decision

 Decision are branches in control flow

 A diamond represents a decision with one or more incoming flow and two or
more outgoing flow
 A condition is labelled on outgoing flow with square bracket
57
Unit: 1.10

I Activity Diagrams: complex

transitions & swimlane
 Complex transitions are transitions
having multiple sources and
multiple destination action states
 Synchronization of concurrent
multiple activties
 Split of control flow to multiple
threads

 Swimlanes
 Actions maybe grouped into swimlanes to denote the object or
subsystem implementing the actions
 Represented by rectangles
 Transition may across swimlanes 58
Unit: 1.10

I Activity Diagrams

 Describe task-centric view of the behavior of a set

of objects
o Sequencing constraints in use case

o Sequential activities among a group of objects or task of a

project

Summary  Can be applied in software engineering managing

activities: project management and software life
cycle
59
Unit: 1.10

State Machine Diagram vs Activity Diagram

State Machine Diagram Factor Activity Diagram

Conditional State State
State Action State

Event flow Flow type

Flow Type Control flow

One to one only Flow Constraint

Flow constraint Many to many: Joint and Fork

Time event Temporal

Temporal Constraint
constraint Synchornization bar

One object only Object

Objects Group of objects

Object detail design Usage

Usage Task centric activities
60
1.11 Diagram
Organization
and Extension

61
Unit: 1.10

I Diagram Organization:
Package

 When there are more modeling elements are constructed,

the diagrams are becoming more complex and complicated
 Package is used for grouping related modelling elements
together for reducing complexity
 Package is represented by a rectangle with a tab on the top
left corner having a name on it
 Package can be presented at different level of complexity
subject to the usage
62
Unit: 1.10

Package grouping related use cases together

Diagram Organization:
Package I
Package grouping related classes together

63
Unit: 1.10

I Diagram Organization:
Package

 A class may appear in more than

one package but only one is the
owner while other are referrer
only
 A note can be attached in
package diagram to provide
description in natural language

64
Unit: 1.10

I Diagram
Extensions  Stereotype is used for extending the meaning of
a modeling element as a classifier
o <<include>> in use case diagram

 Constraint is a rule applied to modeling elements

to restrict is meaning
o Informally as natural language stated in {}
o Formally stated by Object Constraint
Language (OCL)

65
66