Lecture 04 DomainModelling 2spp
-
Upload
jaimin-i-shah -
Category
Documents
-
view
217 -
download
0
Transcript of Lecture 04 DomainModelling 2spp
-
7/25/2019 Lecture 04 DomainModelling 2spp
1/25
Requirements analysis and
modelling the domain
Software Development Practices
Lecture 4
Where are you at?Assignment #1
Due next week, Wednesday 3rd September at 12:30 pm
Submission via Blackboard Turnitin
Assignment #2
To be released next week, Wednesday afternoon
Group assignment (Group of 3-4 students, from the same
tutorial session)
Form your group early start NOW
Progress will be monitored by your tutor on a weekly basis
2
-
7/25/2019 Lecture 04 DomainModelling 2spp
2/25
SDP Roadmap
Problem analysis Domain modelling domain diagrams
Modelling behaviour use cases, use case diagrams
Adding detail to domain model class diagrams
Dynamic behaviour sequence, collaboration diagrams
etc
Defining Architecture deployment diagrams
Detailed design wireframes
Testing3
Overview of This Lecture Introduction to Case Studies
Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
4
-
7/25/2019 Lecture 04 DomainModelling 2spp
3/25
Case Study 1: The Restaurant
Example developed in the Practical Object-Oriented DesignWith UML by Mark Priestley, chapter 4.
Support the day-to-day operations of restaurant by improvingthe processes of:
Making Reservations
Allocating Tables
Current System is based on manual booking system:
Hand-written forms in large folder.
5
Case Study 1: The Restaurant Current system uses manual booking sheets.
6
-
7/25/2019 Lecture 04 DomainModelling 2spp
4/25
Case Study 1: The Restaurant
Three sittings (slots) in an eveningBooking 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 Customer7
Case Study 1: Restaurant Problems with the manual systems/Pain points:
Slow
Confusing and difficult to read/modifiy
No backup copies
Hard to get useful management data
Goal: Develop an automated computerized version.
8
-
7/25/2019 Lecture 04 DomainModelling 2spp
5/25
Case Study 2: The Monopoly Game
Chosen because of its familiarity.
A game played almost in every country.
Developed in theApplying UML and Patterns by Craig Larman,
Chapter 3.
The software version will run assimulation:
User starts the simulation by indicating the number of simulated players.
All turns are simulated with result (trace) printed.
9
Where are we now?
Requirement
Analysi s &
Design
Implementation
Deployment
Business
Modeling Business Modeling
Understanding the problem domain.
Requirement Gathering
Understanding the requirements.
10
Testing
-
7/25/2019 Lecture 04 DomainModelling 2spp
6/25
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.
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 UMLuse case diagrams.
Serves as the starting point for all subsequent development.
Three important definitions:
Use Case
Scenario
Actor
12
-
7/25/2019 Lecture 04 DomainModelling 2spp
7/25
Use Case and Scenarios
Use Case: The different tasks that users can perform while interacting
with the system.
Scenarios aka. Courses of events:
Are particular instances of the use case:
Basic Scenario: normal flow.
Alternative Scenario: optional flow.
Exceptional Scenario: erroneous flow.
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 Swinburne website as Staff or Student.
14
-
7/25/2019 Lecture 04 DomainModelling 2spp
8/25
Use Case Diagram
UML diagram to summarize the relationship between actors
and use cases.
Diagram Element:
Actor Communication Use Case
Use Case
Dependency
Inherit(Actor Relationship) Constraints
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.
16
-
7/25/2019 Lecture 04 DomainModelling 2spp
9/25
Case Study 1: Use Case Diagram
Show use cases, actors and who does what.
System
17
Use Cases DescriptionA 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 scenarios, or courses of events.
A full description of a use case includes:
an actor;
preconditions; success guarantees;
abasic scenario;
a number ofalternative and exceptional scenarios, also calledextensions. 18
-
7/25/2019 Lecture 04 DomainModelling 2spp
10/25
Basic Scenario
Describes what happens in the normal case. For example, for Record Booking:
Record Booking: Basic Scenario
Receptionist enters date of requested reservation;
System displays bookings for that date;
There is a suitable table available: Receptionist enters details
(customers name, phone number, time of booking, number of
covers, table number);
System records and displays new booking.
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 (of the use case)
Actors/goal
Preconditions:
Success guarantees/ postconditions:
Scenarios (basic + extensions)20
-
7/25/2019 Lecture 04 DomainModelling 2spp
11/25
Other Use Case Description Template
1. Receptionist enters date of
requested reservation;
3. there is a suitable table available:
Receptionist enters details
(customers name, phone
number, time of booking, numberof covers, table number);
2. System displays bookings for that
date.
4. System records and displays new
booking.
This version emphasizes the exchange between user andsystem, e.g.:
Actor System
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.:
22
-
7/25/2019 Lecture 04 DomainModelling 2spp
12/25
Al ternat ive Scenarios
Describe predicted alternative flows.
For example, if no table is available:
Record Booking No Table Available: Alternative Scenario
1 Receptionist enters date;
2 System displays bookings;
3 no table available: end of use case.
23
Exceptional Scenarios Situations where a mistake has been made.
E.g., allocate a booking to a small table:
Record Booking table too small: Exceptional Scenario
1 receptionist enters date;
2 system displays bookings;
3 receptionist enters details;
4 system asks for confirmation of oversize booking;
5 if no, use case terminates with no booking made;
6 if yes, booking recorded with warning flag.
24
-
7/25/2019 Lecture 04 DomainModelling 2spp
13/25
Shared Functionality
Different use cases can overlap.
E.g., Record Arrival:
Record Arrival: Basic Scenario
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 (eventhough different actor).
25
Use Case Inclusion Move shared functionality to a separate use case:
Record Booking: Basic Scenario (revised)
receptionist performs Display Bookings;
receptionist enters details;
system records and displays new booking.
Include this in other use cases, e.g.:
Display Bookings: Basic Scenario
user enters a date;
system displays bookings for that date.
26
-
7/25/2019 Lecture 04 DomainModelling 2spp
14/25
The Dependency
UML shows inclusion as a dependency between use cases,labelled with the stereotype on the dashed
arrow:
System
27
Case Study 1: Use Case Diagram (Revised)
System
Display
booking
28
-
7/25/2019 Lecture 04 DomainModelling 2spp
15/25
Actor Generalization
The last diagram shows that the Receptionist can performsthe Display bookings use case independently from the RecordBooking use case.
Head Waiters can also performs Display bookings use case.
Introduce a more general actor Staffto show what the othertwo actors have in common.
The initial actors are specializations of the general actor.
29
Actor Generalization Notation
System
30
-
7/25/2019 Lecture 04 DomainModelling 2spp
16/25
Use Case Extension
Recording a walk-in can be described as an exceptionalcourse of events:
someone arrives but theres 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.
31
Use Case ExtensionRecord Walk-in: Basic Scenario:
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?
dependency is inappropriate. (why?) Record Walk-in is performed in some cases of Record Arrival,
when there is no booking for the customer.
32
-
7/25/2019 Lecture 04 DomainModelling 2spp
17/25
The Dependency
Use case extension is shown with a dependency. Record walk-in optionally extends the functionality of Record arrival.
States the constraint (condition) which causes the branch off.
System
No Prior
Booking
33
Case Study 1: Complete Use Case Diagram
System
34
-
7/25/2019 Lecture 04 DomainModelling 2spp
18/25
Guidelines
Use case: Should cover full sequence of steps from the beginning of a task until
the end.
Should describe users interaction with the system.
Should not describeactual computations.
Should be as independent as possible from any particular userinterface design.
Should only include actions in which the actor interacts with thecomputer.
Use case diagram should be used to supplement the use casedescription, not as the main artifact.
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.
36
-
7/25/2019 Lecture 04 DomainModelling 2spp
19/25
Use Cases: Problems
Care must be taken to ensure the use cases arecomplete 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.
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.
38
-
7/25/2019 Lecture 04 DomainModelling 2spp
20/25
Domain Model Notation
A subset of class diagram model elements are used.
Class Name
Attr ibutes
Class
Association
Name
MultiplicityMultiplicity
ClassGeneralization Constraints
39
Domain Model Notation Classes represent real-world entities.
At tr ibutes 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.
40
-
7/25/2019 Lecture 04 DomainModelling 2spp
21/25
Case Study 1: Customers and Reservations
Basic business fact: customers make reservations.
41
Defining a Relationship Give a name to the relationship:
use a verb so that the relationship can be read as a sentence:
Acustomercanmake 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.
42
-
7/25/2019 Lecture 04 DomainModelling 2spp
22/25
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.Thisimagecannotcurrently bedisplayed.
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.
44
-
7/25/2019 Lecture 04 DomainModelling 2spp
23/25
Use of Generalization
A superclass can be used to show the properties shared bydifferent types of booking.
Thisimagecannotcurrently bedisplayed.
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.
46
-
7/25/2019 Lecture 04 DomainModelling 2spp
24/25
Supplementary Documents
Common Supplementary Documentation:Glossary.
Activity Diagram.
Glossary:
Amini dictionary that captures concepts and vocabulary relevant in
the problem domain.
Avoids misunderstanding and facilitate communication.
Activity Diagram
UML diagram that describes activities.
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.
48
-
7/25/2019 Lecture 04 DomainModelling 2spp
25/25
Summary
Introduction to Case Studies
Requirement Gathering
Use Case Modeling
Domain Modeling / Business Modeling
49
References Evans, E. (2004), Domain-driven design : tackling complexity in
the heart of software, Boston, Mass.: Addison-Wesley (LibraryCall Number: 005.1 EVA-D)
Booch et. al. (1998)The unified modelling language user guide,Amazon.com, 2nd edition. (Swinburne library electronic resource)
Larman, C (2006)Applying UML and Patterns, 3rd Ed PrenticeHall
Fowler, M. (2004), UML Distilled: a brief guide to the standardobject modeling language, Addison-Wesley
Simon, B., McRobb, S. & Farmer, R. (2006), Object-orientedsystems analysis and design using UML, London : McGraw-HillEducation, 3rd Edition (Library Call Number: 005.117 BEN-O3)
Bruegge, B & Dutoit, A (2010), OO Software Engineering usingUML, Patterns and Java, 3rdEdition, Prentice Hall
50