Software Engineering,
CPSC-4360-01, CPSC-5360-01,
Lecture 3
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
1
Overview of the Last Lecture

Software Development Models






Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model
Unified Process
Overview of UML



4/9/2015
History
4 + 1 View models
Using UML in UP
CPSC-4360-01, CPSC-5360-01, Lecture 3
2
Overview of This Lecture





Introduction to Case Studies
Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
Activity Diagram
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
3
Case Study 1: The Restaurant


Example developed in the Practical ObjectOriented Design With UML by Mark Priestley,
chapter 4.
Support the day-to-day operations of
restaurant by improving the processes of:



Making Reservations
Allocating Tables
Current System is based on manual booking
system:

4/9/2015
Hand-written forms in large folder.
CPSC-4360-01, CPSC-5360-01, Lecture 3
4
Case Study 1: The Restaurant
 Current system uses manual booking sheets.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
5
Case Study 1: The Restaurant

Three sittings (slots) in an evening


Each Booking records:


Booking can span more than one slot
Contact Name and Phone Number
Annotation made for various events:





4/9/2015
Arrival of customer (Cross out record)
Table switch (Arrow to new table)
Cancellation
Time to vacate
“Walk-In” Customer
CPSC-4360-01, CPSC-5360-01, Lecture 3
6
Case Study 1: Restaurant

Problems with the manual systems:





Slow
Confusing and difficult to read
No backup copies
Hard to get useful management data
Develop an automated computerized version.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
7
Case Study 2: The Monopoly Game




Chosen because of its familiarity.
A game played almost in every country.
Developed in the Applying UML and Patterns by
Craig Larman, Chapter 3.
The software version will run as simulation:


4/9/2015
User starts the simulation by indicating the number of
simulated players.
All turns are simulated with result (trace) printed.
CPSC-4360-01, CPSC-5360-01, Lecture 3
8
Case Study 3: The Bicycle Renting


Adopts a use-case driven object-oriented approach to
develop a system to support the process of bicycle
renting in a kiosk at East Coast Park, Singapore.
Developed in the Software Engineering: An objectoriented approach by Bimlesh Wadhwa, Stefan
Andrei, Soo Yuen Jien, 2007, McGraw Hill.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
9
Where are we now?

Requirement
Requirement Gathering

Analysis

Design
Implement
Understanding the
requirements.
Business Modeling

Understanding the
problem domain.
Test
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
10
Requirement: Overview


Early phase of the development.
Inputs:


informal specification.
Activities:





4/9/2015
create use case model.
define use cases.
create domain model.
create glossary.
create activity diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 3
11
Use Case View
 Intended to provide a structured view of the system's
functionality.
 Description of how users interact with the system.
 Supported by UML use case diagrams.
 Serves as the starting point for all subsequent
development.
 Three important definitions:
 Use Case
 Scenario
 Actor
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
12
Use Case and Scenarios
 Use Case:
 The different tasks that users can perform while
interacting with the system.
 Scenarios:
 Are particular instances of the use case:
 Basic Course of Events: normal flow.
 Alternative Course of Events: optional flow.
 Exceptional Course of Events: erroneous flow.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
13
Actor
 Roles played by users when interacting with
a system, e.g.:
 Receptionist (makes bookings);
 Head waiter (assigns tables etc).
 Individual user may play one or more roles at
different times.
 Often corresponds to certain level of access,
e.g., logging into Lamar website as Staff or
Student.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
14
Use Case Diagram


UML diagram to summarize the relationship
between actors and use cases.
Diagram Element:
Actor
Communication
Use Case
<<Include>>
Inherit
(Actor Relationship)
4/9/2015
Constraints
CPSC-4360-01, CPSC-5360-01, Lecture 3
<<Extend>>
Use Case
Dependency
15
Case Study 1: Use Cases

A preliminary list of use cases:
1 Record new booking.
2 Cancel a booking.
3 Record customer arrival.
4 Transfer a customer from one table to another.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
16
Case Study 1: Use Case Diagram
 Show use cases, actors and who does what.
System
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
17
Use Cases Description
 A use case comprises all the possible
interactions that a user can have when
performing a given task.
 Often a dialogue between system and user.
 These are described as courses of events, or
scenarios.
 A full description of a use case includes:
 a basic course of events;
 a number of alternative and exceptional courses.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
18
Basic Course of Events
 Describes what happens in the ‘normal’ case.
 For example, for ‘Record Booking’:
Record Booking: Basic Course of Events
 Receptionist enters date of requested reservation;
 System displays bookings for that date;
 There is a suitable table available: Receptionist
enters details (customer’s name, phone number,
time of booking, number of covers, table number);
 System records and displays new booking.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
19
Use Case Templates
 UML does not define a standard format for
use case descriptions.
 Various templates have been defined to
structure descriptions.
 Essentially a list of subheadings such as:
 Name
 Actors
 Courses of events
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
20
Other Use Case Description Template

This version emphasizes the exchange between
user and system, e.g.:
Actor
System
1. Receptionist enters date
of requested reservation;
2. System displays bookings
for that date.
3. there is a suitable table
4. System records and
available: Receptionist
displays new booking.
enters details (customer’s
name, phone number,
time of booking, number
of covers, table number);
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
21
User Interface Prototype

During the use case modeling activity, it is usually
useful to have a rough idea of the user interface, e.g.:
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
22
Alternative Courses of Events


Describe predicted alternative flows.
For example, if no table is available:
Record Booking – No Table Available: Alternative Course of Event
1
2
3
4/9/2015
Receptionist enters date;
System displays bookings;
no table available: end of use case.
CPSC-4360-01, CPSC-5360-01, Lecture 3
23
Exceptional Courses of Events


Situations where a mistake has been made.
E.g., allocate a booking to a small table:
Record Booking – table too small: Exceptional course of events
1 receptionist enters date;
2
3
4
5
6
4/9/2015
system displays bookings;
receptionist enters details;
system asks for confirmation of oversize booking;
if “no”, use case terminates with no booking made;
if “yes”, booking recorded with warning flag.
CPSC-4360-01, CPSC-5360-01, Lecture 3
24
Shared Functionality


Different use cases can overlap.
E.g., ‘Record Arrival’:
Record Arrival: Basic Course of Events





4/9/2015
head waiter enters date;
system displays bookings;
head waiter confirms arrival for booking;
system records this and updates display.
First two steps shared with ‘Record Booking’
(even though different actor).
CPSC-4360-01, CPSC-5360-01, Lecture 3
25
Use Case Inclusion

Move shared functionality to a separate use case:
Display Bookings: Basic Course of Events

user enters a date;

system displays bookings for that date.

Include this in other use cases, e.g.:
Record Booking: Basic Course of Events (revised)

receptionist performs Display Bookings;

receptionist enters details;

system records and displays new booking.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
26
The <<include>> Dependency
 UML shows inclusion as a dependency
between use cases, labelled with the
stereotype <<include>> on the dashed arrow:
System
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
27
Case Study 1: Use Case Diagram (Revised)
Display
booking
System
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
28
Actor Generalization
 The last diagram shows that the Receptionist
can performs the Display bookings use case
independently from the Record Booking use
case.
 Head Waiters can also performs Display
bookings use case.
 Introduce a more general actor Staff to show
what the other two actors have in common.
 The initial actors are specializations of the
general actor.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
29
Actor Generalization Notation
System
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
30
Use Case Extension
 Recording a walk-in can be described as an
exceptional course of events:
 someone arrives but there’s no booking recorded.
 It could also be a separate use case:
 a customer arrives and asks if there's a free table.
 Then, it can extend ‘Record Arrival’:
 even without a booking, the customer stays to eat.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
31
Use Case Extension
Record Walk-in: Basic Course of Events:
1 Head waiter performs Display Bookings use case;
2 Head waiter enters details (time, number of covers
and the table allocated to the customer);
3 System records and displays new booking.



Very similar to Record Arrival use case. Can we
simplify?
<<Include>> dependency is inappropriate. (why?)
Record Walk-in is performed in some cases of
Record Arrival, when there is no booking for the
customer.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
32
The <<extend>> Dependency
 Use case extension is shown with a <<extend>> dependency.
 Record walk-in optionally extends the functionality of Record
arrival.
 States the constraint (condition) which causes the branch off.
No Prior
Booking
System
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
33
Case Study 1: Complete Use Case Diagram
System
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
34
Guidelines
 Use case:
 Should cover full sequence of steps from the beginning
of a task until the end.
 Should describe user’s interaction with the system.
 Should not describe actual computations.
 Should be as independent as possible from any
particular user interface design.
 Should only include actions in which the actor interacts
with the computer.
 Use case diagram should be used to supplement
the use case description, not as the main artifact.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
35
Use Cases: Strengths

Simple and Familiar




Can be understood easily by untrained personnel,
e.g., the customer.
Involve the customer early in the development.
Emphasize the user goals and perspective.
Scale in term of sophistication and formality.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
36
Use Cases: Problems




Care must be taken to ensure the use cases
are complete and unambiguous.
Only actor initiated activities are recorded.
Software requirement derived from use cases
often mimics the manual system too closely.
Preventing any innovative or more efficient
way to be developed.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
37
Domain Modelling
 Using UML diagram to construct a model of the
real-world system:
 Understand the problem domain.
 Model recorded as a simplified class diagram.
 Seamless development:
 The same notation is used for analysis and design.
 The design can evolve from the initial domain model.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
38
Domain Model Notation

A subset of class diagram model elements
are used.
Class Name
Attributes
Name
Multiplicity
Multiplicity
Association
Class
Class
Generalization
4/9/2015
Constraints
CPSC-4360-01, CPSC-5360-01, Lecture 3
39
Domain Model Notation
 Classes represent real-world entities.
 Attributes represent the data held about
entities.
 Associations represent relationships
between the entities.
 Generalization can be used to simplify the
structure of the model.
 Constraints can be used to indicate
conditions.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
40
Case Study 1: Customers and Reservations
 Basic business fact: customers make reservations.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
41
Defining a Relationship
 Give a name to the relationship:
 use a verb so that the relationship can be read as a
sentence:
 A customer can make many reservations.
 How many people make a reservation?
 one principal contact whose details are held;
 that principal contact can make more than one
reservation (e.g., by postponing the time);
 the expected number of diners can be modelled as
an attribute of the reservation.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
42
Case Study 1: Tables and Reservation
 Is table number an attribute of ‘Reservation’?
 Better modelled as a separate class:
 tables exist even if there are no reservations;
 other attributes of tables, e.g., size, can be stored.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
43
Use of Constraints
 Not all domain properties can be shown
graphically:
 e.g., it should be impossible to double-book a
table.
 Constraints add information to models:
 written in a note connected to the model element
being constrained.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
44
Use of Generalization
 A superclass can be used to show the properties
shared by different types of booking.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
45
Correctness
 How do we know when a domain model is
complete?
 we don't: there are lots of plausible models in
most cases.
 Domain modelling is not an end in itself, but a
guide to further development.
 Realizing use cases tests the domain model,
and will usually lead to refinements.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
46
Supplementary Documents

Common Supplementary Documentation:



Glossary:



Glossary.
Activity Diagram.
A mini dictionary that captures concepts and
vocabulary relevant in the problem domain.
Avoids misunderstanding and facilitate
communication.
Activity Diagram

4/9/2015
UML diagram that describes activities.
CPSC-4360-01, CPSC-5360-01, Lecture 3
47
Case Study 1: Partial Glossary





Booking: an assignment of diners to a table.
Covers: the number of diners for a booking.
Customer: a person who makes a reservation.
Reservation: a booking made in advance.
Walk-in: a booking that is not made in
advance.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
48
Activity Diagram

Similar to flow chart that describes sequence of
activities.

Useful in:

Business Modelling (business workflow).

Use Cases (interrelation and interaction).

Design (algorithm, complex sequence etc).

Often associated with several classes.

One of the strengths of activity diagrams is the
representation of concurrent activities.
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
49
Activity Diagram

Diagram Elements:
4/9/2015
Activity
Initial Node
Activity
End Node
Transition
Decision
Fork
Join
CPSC-4360-01, CPSC-5360-01, Lecture 3
Action
Rendezvous
50
Activity Diagram

Action:




Transition:


Fundamental block in an activity diagram.
Represents a unit of work (something is done).
Automatic transition upon completion.
Represents the control flow: it is simply a
movement between actions.
Initial and End Node:

4/9/2015
Show the beginning and ending points in an activity
diagram.
CPSC-4360-01, CPSC-5360-01, Lecture 3
51
Case Study 1: Activity Diagram

Documenting the
sequence when
customer arrives.

Note the interrelation
of Record Arrival and
Record Walk-In.
CPSC-4360-01, CPSC-5360-01, Lecture 3
52
Display Booking
Enter Information
Record
Walk-In
4/9/2015
[No
Booking]
[Booking
Exist]
Confirm
Arrival
Concurrent Actions


Independent actions which can be carried out at the
same time (in parallel).
Shown using forks, joins and rendezvous:

Fork:



Rendezvous:


4/9/2015
One incoming transition and multiple outgoing transitions.
Execution splits into multiple concurrent threads.
Multiple incoming and multiple outgoing transitions.
All incoming transitions must occur before the outgoing
transitions.
CPSC-4360-01, CPSC-5360-01, Lecture 3
53
Representing Concurrency

Join:


4/9/2015
Multiple incoming transitions and one
outgoing transition.
The outgoing transition will be taken when all
incoming transitions have occurred.
CPSC-4360-01, CPSC-5360-01, Lecture 3
54
Activity Diagram: Another Example
Receive course
registration request

Use Cases:

Check
prerequisites
[not ok]
[ok]
Verify
course not
full
[ok]
Check
special
permission

Submit registration
request.
Register student:
[not ok]

[ok]

[not ok]

Verify prerequisites.
Verify course
enrolment.
Verify special cases.
Complete
registration
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
55
Swimlanes

Activity diagrams are most often associated
with several classes.


4/9/2015
The partition of activities among the existing
classes can be explicitly shown using swimlanes.
Further clarify where an action takes place.
CPSC-4360-01, CPSC-5360-01, Lecture 3
56
Swimlanes: Example
Course
Student
Receive course
registration request
Check
prerequisites
Action taken
by Student
[not ok]
[ok]
Verify
course not
full
[ok]
Check
special
permission
[not ok]
Action taken
by Course
[ok]
[not ok]
Complete
registration
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
57
Where are we now?

Requirement
Typical Artifacts:


Analysis
Requirement Specification.
Use Cases:


Design


Implement

Use Case Description.
Use Case Diagrams.
Activity Diagrams.
Glossary.
Domain Model.
Test
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
58
Summary





Introduction to Case Studies
Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
Activity Diagram
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
59
Reading suggestions

From [Wadhwa, Andrei, Soo; 2007]


From [Priestley; 2004]



Chapter 4, sections 4.2 to 4.5
Exercises 4.1-4.7
From [Larman; 2005]


Chapter 3
Chapters 1, 6
From [Stevens, Pooley; 1999]

4/9/2015
Chapter 11
CPSC-4360-01, CPSC-5360-01, Lecture 3
60
Coming up next

Analysis:



[Priestley; 2004], Chapter 5
[Wadhwa, Andrei, Soo; 2007], Chapter 3
UML Class and Object Diagrams:


4/9/2015
[Priestley; 2004], Chapter 8
[Wadhwa, Andrei, Soo; 2007], Chapter 4
CPSC-4360-01, CPSC-5360-01, Lecture 3
61
Thank you for your attention!
Questions?
4/9/2015
CPSC-4360-01, CPSC-5360-01, Lecture 3
62