1. Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 3
4/1/2017
CPSC , CPSC , Lecture 3

2. Overview of the Last Lecture
Software Development Models
Waterfall Model
Evolutionary Models
Incremental Model
Spiral Model
Unified Process
Overview of UML
History
4 + 1 View models
Using UML in UP
4/1/2017
CPSC , CPSC , Lecture 3

3. Overview of This Lecture
Introduction to Case Studies
Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
Activity Diagram
4/1/2017
CPSC , CPSC , Lecture 3

4. Case Study 1: The Restaurant
Example developed in the Practical Object-Oriented 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:
Hand-written forms in large folder.
4/1/2017
CPSC , CPSC , Lecture 3

5. Case Study 1: The Restaurant
Current system uses manual booking sheets.
4/1/2017
CPSC , CPSC , Lecture 3

6. Case Study 1: The Restaurant
Three sittings (slots) in an evening
Booking can span more than one slot
Each Booking records:
Contact Name and Phone Number
Annotation made for various events:
Arrival of customer (Cross out record)
Table switch (Arrow to new table)
Cancellation
Time to vacate
“Walk-In” Customer
4/1/2017
CPSC , CPSC , Lecture 3

7. 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/1/2017
CPSC , CPSC , Lecture 3

8. 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:
User starts the simulation by indicating the number of simulated players.
All turns are simulated with result (trace) printed.
4/1/2017
CPSC , CPSC , Lecture 3

9. 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 object-oriented approach by Bimlesh Wadhwa, Stefan Andrei, Soo Yuen Jien, 2007, McGraw Hill.
4/1/2017
CPSC , CPSC , Lecture 3

10. Where are we now? Requirement Gathering Business Modeling
Understanding the requirements.
Business Modeling
Understanding the problem domain.
Requirement
Analysis
Design
Implement
Test
4/1/2017
CPSC , CPSC , Lecture 3

11. Requirement: Overview
Early phase of the development.
Inputs:
informal specification.
Activities:
create use case model.
define use cases.
create domain model.
create glossary.
create activity diagram.
4/1/2017
CPSC , CPSC , Lecture 3

12. 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/1/2017
CPSC , CPSC , Lecture 3

13. Use Case and Scenarios Use Case: Scenarios:
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/1/2017
CPSC , CPSC , Lecture 3

14. 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/1/2017
CPSC , CPSC , Lecture 3

15. Use Case Diagram
UML diagram to summarize the relationship between actors and use cases.
Diagram Element:
Actor
Use Case
Communication
<<Include>>
<<Extend>>
Use Case Dependency
Constraints
Inherit
(Actor Relationship)
4/1/2017
CPSC , CPSC , Lecture 3

16. Case Study 1: Use Cases A preliminary list of use cases:
Record new booking.
Cancel a booking.
Record customer arrival.
Transfer a customer from one table to another.
4/1/2017
CPSC , CPSC , Lecture 3

17. Case Study 1: Use Case Diagram
Show use cases, actors and who does what.
System
4/1/2017
CPSC , CPSC , Lecture 3

18. 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/1/2017
CPSC , CPSC , Lecture 3

19. 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/1/2017
CPSC , CPSC , Lecture 3

20. 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/1/2017
CPSC , CPSC , Lecture 3

21. Other Use Case Description Template
This version emphasizes the exchange between user and system, e.g.:
Actor
System
Receptionist enters date of requested reservation;
there is a suitable table available: Receptionist enters details (customer’s name, phone number, time of booking, number of covers, table number);
System displays bookings for that date.
System records and displays new booking.
4/1/2017
CPSC , CPSC , Lecture 3

22. 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/1/2017
CPSC , CPSC , Lecture 3

23. Alternative Courses of Events
Describe predicted alternative flows.
For example, if no table is available:
Record Booking – No Table Available: Alternative Course of Event
Receptionist enters date;
System displays bookings;
no table available: end of use case.
4/1/2017
CPSC , CPSC , Lecture 3

24. 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
receptionist enters date;
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.
4/1/2017
CPSC , CPSC , Lecture 3

25. Shared Functionality Different use cases can overlap.
E.g., ‘Record Arrival’:
Record Arrival: Basic Course of Events
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).
4/1/2017
CPSC , CPSC , Lecture 3

26. 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/1/2017
CPSC , CPSC , Lecture 3

27. The <<include>> Dependency
UML shows inclusion as a dependency between use cases, labelled with the stereotype <<include>> on the dashed arrow:
System
4/1/2017
CPSC , CPSC , Lecture 3

28. Case Study 1: Use Case Diagram (Revised)
Display booking
Note: Intentionally left Incomplete
System
4/1/2017
CPSC , CPSC , Lecture 3

29. 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/1/2017
CPSC , CPSC , Lecture 3

30. Actor Generalization Notation
System
4/1/2017
CPSC , CPSC , Lecture 3

31. 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/1/2017
CPSC , CPSC , Lecture 3

32. Use Case Extension
Record Walk-in: Basic Course of Events:
Head waiter performs Display Bookings use case;
Head waiter enters details (time, number of covers and the table allocated to the customer);
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.
The ‘include’ dependency is inappropriate, because the interactions specified in ‘Record walk-in’ are not performed every time ‘Record arrival’ is performed.
Rather, ‘Record walk-in’ is performed in some cases of ‘Record Arrival’, when there is no booking for the customer, there is a suitable table free, and the customer still wants to eat there.
4/1/2017
CPSC , CPSC , Lecture 3

33. 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
‘Record walk-in’ contains more details than ‘Record arrival’.
Rather, ‘Record walk-in’ is performed in some cases of ‘Record Arrival’, when there is no booking for the customer, there is a suitable table free, and the customer still wants to eat there.
System
4/1/2017
CPSC , CPSC , Lecture 3

34. Case Study 1: Complete Use Case Diagram
System
4/1/2017
CPSC , CPSC , Lecture 3

35. 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/1/2017
CPSC , CPSC , Lecture 3

36. 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/1/2017
CPSC , CPSC , Lecture 3

37. 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/1/2017
CPSC , CPSC , Lecture 3

38. 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/1/2017
CPSC , CPSC , Lecture 3

39. Domain Model Notation
A subset of class diagram model elements are used.
Class Name
Attributes
Name
Multiplicity
Multiplicity
Association
Class
Constraints
Class
Generalization
4/1/2017
CPSC , CPSC , Lecture 3

40. 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/1/2017
CPSC , CPSC , Lecture 3

41. Case Study 1: Customers and Reservations
Basic business fact: customers make reservations.
4/1/2017
CPSC , CPSC , Lecture 3

42. 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/1/2017
CPSC , CPSC , Lecture 3

43. 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/1/2017
CPSC , CPSC , Lecture 3

44. 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/1/2017
CPSC , CPSC , Lecture 3

45. Use of Generalization
A superclass can be used to show the properties shared by different types of booking.
4/1/2017
CPSC , CPSC , Lecture 3

46. 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/1/2017
CPSC , CPSC , Lecture 3

47. Supplementary Documents
Common Supplementary Documentation:
Glossary.
Activity Diagram.
Glossary:
A mini dictionary that captures concepts and vocabulary relevant in the problem domain.
Avoids misunderstanding and facilitate communication.
Activity Diagram
UML diagram that describes activities.
4/1/2017
CPSC , CPSC , Lecture 3

48. 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/1/2017
CPSC , CPSC , Lecture 3

49. 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/1/2017
CPSC , CPSC , Lecture 3

50. Activity Diagram Diagram Elements: Action Transition
Activity Initial Node
Activity End Node
Fork
Join
Rendezvous
Decision
4/1/2017
CPSC , CPSC , Lecture 3

51. Activity Diagram Action: Transition: Initial and End Node:
Fundamental block in an activity diagram.
Represents a unit of work (something is done).
Automatic transition upon completion.
Transition:
Represents the control flow: it is simply a movement between actions.
Initial and End Node:
Show the beginning and ending points in an activity diagram.
4/1/2017
CPSC , CPSC , Lecture 3

52. Case Study 1: Activity Diagram
Documenting the sequence when customer arrives.
Note the interrelation of Record Arrival and Record Walk-In.
Display Booking
Enter Information
[Booking Exist]
[No Booking]
Confirm Arrival
Record Walk-In
4/1/2017
CPSC , CPSC , Lecture 3

53. Concurrent Actions
Independent actions which can be carried out at the same time (in parallel).
Shown using forks, joins and rendezvous:
Fork:
One incoming transition and multiple outgoing transitions.
Execution splits into multiple concurrent threads.
Rendezvous:
Multiple incoming and multiple outgoing transitions.
All incoming transitions must occur before the outgoing transitions.
4/1/2017
CPSC , CPSC , Lecture 3

54. Representing Concurrency
Join:
Multiple incoming transitions and one outgoing transition.
The outgoing transition will be taken when all incoming transitions have occurred.
4/1/2017
CPSC , CPSC , Lecture 3

55. Activity Diagram: Another Example
Verify
course not
full
Receive course
registration request
Check
prerequisites
special
permission
Complete
registration
[ok]
[not ok]
Use Cases:
Submit registration request.
Register student:
Verify prerequisites.
Verify course enrolment.
Verify special cases.
4/1/2017
CPSC , CPSC , Lecture 3

56. Swimlanes
Activity diagrams are most often associated with several classes.
The partition of activities among the existing classes can be explicitly shown using swimlanes.
Further clarify where an action takes place.
4/1/2017
CPSC , CPSC , Lecture 3

57. Action taken by Student
Swimlanes: Example
Student
Course
Receive course
registration request
Check
Verify
prerequisites
course not
Action taken by Student
full
[not ok]
[ok]
Action taken by Course
[ok]
[not ok]
Check
special
[ok]
permission
[not ok]
Complete
registration
4/1/2017
CPSC , CPSC , Lecture 3

58. Where are we now? Typical Artifacts: Requirement Specification.
Use Cases:
Use Case Description.
Use Case Diagrams.
Activity Diagrams.
Glossary.
Domain Model.
Requirement
Analysis
Design
Implement
Test
4/1/2017
CPSC , CPSC , Lecture 3

59. Summary Introduction to Case Studies Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
Activity Diagram
4/1/2017
CPSC , CPSC , Lecture 3

60. Reading suggestions From [Wadhwa, Andrei, Soo; 2007]
Chapter 3
From [Priestley; 2004]
Chapter 4, sections 4.2 to 4.5
Exercises
From [Larman; 2005]
Chapters 1, 6
From [Stevens, Pooley; 1999]
Chapter 11
4/1/2017
CPSC , CPSC , Lecture 3

61. Coming up next Analysis: UML Class and Object Diagrams:
[Priestley; 2004], Chapter 5
[Wadhwa, Andrei, Soo; 2007], Chapter 3
UML Class and Object Diagrams:
[Priestley; 2004], Chapter 8
[Wadhwa, Andrei, Soo; 2007], Chapter 4
4/1/2017
CPSC , CPSC , Lecture 3

62. Thank you for your attention! Questions?
4/1/2017
CPSC , CPSC , Lecture 3