COMP S356

Software
Engineering
and Project
Management
Tutorial Group 1
 Download Presentation
Slides
 Web:
http://learn.hkmu.edu.hk/~t4412
84
 Presentation Outlines
 Review of last tutorial
 Unit 1
 Introduction to Software Engineering and
UML (Part 2)
 Q&A
 Outline for next tutorial
 Review of Last Tutorial
 Four aspects of SE
 Development and management activities
of SE
 Introduction to UML
 Use case diagram
 Class diagram
 Interaction diagram
 Statechart diagram
 Activity diagram
 Side notes on Visual
Paradigm
 The quality for exporting diagram to
GIF/JPEG is acceptable
 File  Export  Active Diagram as
Image
UML diagrams
UML diagrams
Deeper View – Use Case
Diagram
Use Case Diagrams
 The diagram:
 Represents functionality of the system from user’s point of view. It also called a
functional model
 Defines boundaries of the system
 Used during requirements elicitation to represent external behavior
 Additional description can be added as a “note symbol”

OLE Forum
Write message Special privileges is
required
Delete message
User
Read message
Use Case Diagrams
 Actors:
 Represent roles (i.e. a type of user of the system)
 Use cases:
 Represent a sequence of interaction for a type of functionality
 Use case model:
 The set of all use cases. It is a complete description of the functionality of the
system and its environment

Ticket System
PurchaseTicket
CheckTrain
Schedule
Passenger
ValidateTicket
Use Case Diagrams
 Each actor models an external entity which communicates with the system. e.g.:
 General users
 External systems
 Each actor has a unique name and an optional description. e.g.:
 Passenger: A person in the train
 Student: Course participants
 Librarian: Staff in the library

Library System
Student ReserveBooks

Librarian
CheckBook
Information UpdateBook
Other Lib. Information
System
 Use Case
understand the difference between use case diagram and us

A use case represents class of

functionality provided by the system as
PurchaseTicket an event flow.

A use case consists of:

 Unique name
 Participating actors
 Flow of events
 Entry conditions
 Exit conditions
 Special / quality requirements

Ref: (page 79, figure 2-14) 

Use Case: Example
Name: PurchaseTicket

Participating actor: Passenger

Entry condition: Event flow:

 Passenger standing in front of
1. Passenger selects the station to be
ticket distributor. traveled.
 Passenger has sufficient money to
2. Distributor displays the amount
purchase ticket. due.
3. Passenger inserts money, of at
Exit condition: least the amount due.
 Passenger has ticket. 4. Distributor returns change.
5. Distributor issues ticket.
Scenario: Example
Scenario – instance of use case (page 85, figure 2-21) 
Three fields: Name, participating actor instances, flow
of events
Name: PurchaseTicketToMongkok

Participating actor: peter: Passenger

Event flow:
1. Peter selects Mongkok station as the destination.
2. Distributor displays the amount due.
3. Peter inserts money.
4. Distributor returns change.
5. Distributor issues ticket.

Anything missing? Exceptional cases!

The <<extend>> Relationship
 <<extend>> relationships represent
exceptional or seldom invoked cases.
 The exceptional event flows are
factored out of the main event flow for
clarity.
Passenger
 Use cases representing exceptional
flows can extend more than one use
case.
Purchase  The direction of a <<extend>>
Ticket relationship is to the extended use case
d>> <<
ex
e n te
<<extend>>

xt n d>
<<

e >
<<
ex
te
nd

OutOfOrder TimeOut
>>

Cancel NoChange
The <<extend>> Relationship

Purchase <<e
Ticket xte
nd>
>
TimeOut

Use case TimeOut

name
Participating Communicates with Passenger.
actor
Flow of …
events
Entry This use case extends the PurchaseTicket use
condition cases. It is initiated by the system whenever the
interaction between the Passenger and system is
paused for a certain amount of time.
Exit condition …
The <<include>> Relationship
 <<include>> relationship
represents behavior that is
factored out of the use case.
Passenger  <<include>> behavior is
Purchase factored out for reuse, not
MultiTicket because it is an exception.
Purchase
SingleTicket
 The direction of a <<include>>
relationship is to the using
e> >
clud use case (unlike <<extend>>
<<

relationships).
in

<< in
cl

 Stereotypes (<< >>) can be

ud
e>

added to a model to provide

>

<<extend>>
more detailed meaning to the
Cancel Collect diagram. <<include>> and
d>> Money
t en <<extend>> are 2 examples
< <ex
used in Use Case diagram
NoChange
The <<include>> Relationship
Purchase <<include>> <<include>> Purchase
Collect
SingleTicket Money MultiTicket

Use case PurchaseSingleTicket

name
Participating Initiated by Passenger
actor
Flow of 1. Passenger selects the station to be traveled
events 2. Distributor collects the money required
(CollectMoney)
3. Distributor issues ticket
Entry - Passenger standing in front of ticket distributor
condition - Passenger has sufficient money to purchase
ticket
Exit condition - Passenger has ticket
The inheritance relationships

 Inheritance relationships (page 83) 

 Specialize another more general use case by adding more detail
 Different from extend relationships, which have different flow
of events

Purchase
Ticket

Purchase Purchase
SingleTicket MultiTicket
The inheritance relationships
Use case name PurchaseTicket
Participating Initiated by Passenger
actor
Flow of events
Entry condition Passenger standing in front of ticket distributor.
Passenger has sufficient money to purchase ticket.
Exit condition Passenger has ticket.

Use case name PurchaseSingleTicket

Participating Inherited from PurchaseTicket use case
actor
Flow of events 1. Passenger selects the station to be traveled
2. Distributor collects the money required
(CollectMoney)
3. Distributor issues ticket
Entry condition Inherited from PurchaseTicket use case
Exit condition Inherited from PurchaseTicket use case
Use Case Diagrams: Summary

 Use case diagrams

 Represent external behavior of the system
 Useful as an index into the use cases
 Use case descriptions provide meat of model, not the use
case diagrams.
 All use cases need to be described for the model to be
useful.
Deeper View – Class
Diagram
Class Diagram
 Class diagram
 Represent structure of a
system
 Three compartment
 Class name
 Attributes
 Operations
 Undefined element
 Blank
 Marked undefined
Class Diagram

 Association
 Relationship between classes
 Role
 Give meaning to an association

Officer Report
author reportsGenerated

Association name
Class Diagram
 Multiplicity
 Indicates how many objects participate in a given
relationship
 One-to-one, one-to-many, many-to-many
 0 1 0..n 1..n n 0..* 1..* * etc.

1 0..n
Officer Report
author reportsGenerated

Customer Account
1 1..4
Class Diagram
 Aggregation and Composition
 Captures “Whole/part” relationship

Car Wheel
1 4

Car Wheel
1 4

 Plain association is acceptable, but not a complete

description then
Car Wheel
1 4
Class Diagram
 Generalization
 Captures “General/specific” relationship

Vehicle

Car Ship

 Any other examples you can think of?

Class Diagram

 Navigation arrow
 Associations can be bi-directional or uni-directional
 Navigation arrow indicates the direction of associations

* *
Polygon Point

* *
Course Student

* *
Course Student
Deeper View – Object
Diagram
Object Diagram
 Modified form a class diagram
FieldOfficer
 Class becomes Object (instance of class)
 Underline the object name to represent object
name
 Example badgeNumber
 john
 john : FieldOfficer Class
 thomasPC : Computer
 Attribute value for an object
 Also an object
john:FieldOfficer
 Underline it as well
John Wong : name
1357 : badgeNumber

Object
Object Diagram
 Associations (in class diagram) becomes actual links (in object
diagram)
 Multiplicity does not apply in object diagram

Student Course
1 1..4

john: Student c356 : Course

m212 : Course

t361 : Course
More on classes and objects

 Abstract class
 Class which cannot be instantiate
 Cannot create object using abstract class Vehicle
 Consider the Vehicle class in the diagram

 Concrete class Car Ship

 Class which can be instantiate

 Notes
Staff
 Sometimes both class defined in a hierarchy
can be concrete class
 For example
Manager
 Staff and Manager
More on classes and objects

Method of a class
 Also known as operation Car
 Call a method of an object
 Means sends a message to an object moveForward( )
moveBackward( )

:CarContr :Car
ol

moveForward( )
Deeper View – Interaction
Diagram
Interaction Diagram
 Represent system’s behavior in terms of interactions
among a set of objects.
 Two types of diagrams
1) Sequence diagram 2) Collaboration diagram

:UserInterface :TimeControl

:User
Lifeline
Check current time getTime( )

time
Current time

Activatio
n of
object
Interaction Diagram
 Sequence Diagram
 Object creation and destruction
Interaction Diagram
 Sequence Diagram
 Condition and iteration
Interaction Diagram
 Sequence Diagram
 Timing constraint
 Sending time, receive time, elapsed time, queue
time, etc.

Constraints are denoted by { }. They can be attached to UML

models elements for
restricting its semantics
Interaction Diagram
 Another example of Sequence diagram, we will remap it to Collaboration
diagram
Interaction Diagram
 Communication Diagram
 Numbering the message
Interaction Diagram
 Sequence diagram (mapped from communication
diagram)

1 1.1

2
2.1
3
3.1 3.2
4 4.1

4.2
Interaction Diagram
 What are the pros and cons between sequence
diagram and communication diagram?

 Try to compare them on:

 Resemblance to an object diagram

 Sending messages

 Message ordering

 How do we decide when to use sequence or

communication diagram?
Deeper View – Statechart
Diagram
Statechart Diagram
 Represent the behavior of nontrivial objects
 State
 Transition
 Internal transition
State A
Entry/action 1
Exit/action 2

 Self-transition

State B
Statechart Diagram

Button1

Button2
Statechart Diagram

Nested State
Deeper View – Activity
Diagram
Activity Diagram
 Represent data flow or control flow through a system
 Initial and stop states
 Not mandatory but increase readability
 Decision

Download [Can complete the work on time]Work on the

the TMA TMA

[Need much more

Time to complete]
[Need more time
to complete]
Apply 14-day
extension

Apply 7-day
extension
Activity Diagram
 Synchronization bar
 Fork, Join, Swimline

Prepare
Developer
Software Tools

Prepare Develop
Create Project Hardware Application

Create
Database Admin
Database
End