CS计算机代考程序代写 case study 300144

Documenting Use Cases(Cont.)
• Basic Course (Main Success Scenario/Basic Flow) – 1
– 2
– 3
–…
• Alternative Courses (Extensions/Alternative Flows)
– – –…
• Exceptions
–
– • Constraints
–
*The use case text may also be written in an Action-Response or Intention-Responsibility format
6

Documenting Use Cases(Cont.)
• User Interface Specifications
–
• Metrics
–
• Priority
–
• Status
–
• Author & History
–
• Reference Material
–
7

Main Topics of Lecture
• UseCaseDiagrams
• Relationships in use case diagram
• Activity Diagrams
• Relating Activity diagram to Use Case Diagrams
• UML’s Extensibility Mechanisms
8

What is a Use Case Diagram?
• A Use Case Diagram is used to illustrate how actors use the system and visualise the relationships between actors and use cases.
Use case diagrams are secondary in use case work. Use cases are text documents. Doing
use case work means to write text.
9

What is a Use Case Diagram? (Cont.)
• Notations: Actor, Use case, Relations • Relations:
– Relations in a use case diagram are powerful mechanism to organise and reuse requirements, contain including, extending, generalising (inheritance).
• Context in a use case diagram indicates the boundary of the system (between the Actor and the System)
10

Notations of a Use case Diagram
Actor
Use case
Actor to Use case Association
<>
<>
Inheritance
Inclusion Of a Use case by Another
Extension of a Use case by Another
Notes
System Boundary
11

UML Notation for Use Case Relationships
:Actor
<>
UsecaseB
UsecaseA
<>
UsecaseD
<>
UsecaseC
Use case A <> Use case B Use case C <> Use case A Use case D <> Use case A
12

Include Relationship
• Whenrequirementstendtoexhibitcommon behaviour, they should be factored out
• These common behaviours form a use case of their own
• They are then “included” in the original use cases, and many other use cases
Tip: Included use case is usually Mandatory; However, an If-Then-Else situation can’t be easily shown (add Notes)
13

Extend Relationship
• Describes extensions to an existing use case
• The extended use case describes one specialised set
of interactions
• Enables extending the use case diagrams for new requirements without disturbing existing diagrams
Tip: Extends implies specialisation; usually is Optional execution of the extended Use Case;
14

Inherit Relationship
• Willmakesensewhenusecasesaredocumentedas ‘essential’ and ‘concrete’ (general or abstract, and concrete)
• (Ref. Constantine and Lockwood)
• Essentialusecasesdescribethe‘intentional’ behaviour – corresponding concrete behaviour can be inherited from it
• Tip: This Inherit relationship has still not fully matured in UML, hence it is best used only when understood within the project
15

Inheritance vs Extend
• Generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used:
void makePayment(const PaymentDetails* pd) {
pd->pay();
}//inheritance
//different concrete version pay() will be called
void makePayment(const PaymentDetails* pd) {
switch(pd->type)
{ case EFT: payViaEFT(pd); break;
case PAYPAL: payViaPayPal(pd);
break;
case CREDITCARD: payViaCreditCard(pd); break;
}
}// above payment methods are extensions to pay()
Object Oriented Analysis – 300144 16

Putting Together a Use Case Diagram
Visual Representation of Requirements through Actors, Use cases and Relationships
17

“Patient Maintenance” Use Case Diagram
‘UC10-RegistersPatient’
:
‘A90-GovernmentHealthRegulatorySystem’
For Verification
of Medicare Details – Applies to all Patients registering first time.
‘A80-Administrator’
The Administrator
helps in creating and
verifying the details.
Once created, maintenance does not require Administrator
‘A10-Patient’
‘UC12-MaintainsPatientDetails’
‘UC14-CreatesPatientsMedicalProfile’
‘A60-Doctor’
‘UC16-UpdatesPatientsMedicalProfile’
18

“Calendar Maintenance” Use Case Diagram
‘UC20-CreatesCalendar’
‘UC22-MaintainsCalendar’
<>
‘UC24-ChecksCalendar’
:
Some maintenance activities (such as booking a Vacation) will require appropriate authorization.
‘A50-Staff’
19

“Consultation Details” Use Case Diagram
:
‘UC30-BooksConsultation’
<> ‘UC24-ChecksCalendar’
‘A10-Patient’
‘A80-Administrator’
Involved in manual bookings of consultations
This calendar is updated
by the Doctors with their availability
‘UC32-ExaminesPatient’
‘A64-Physician’
‘UC34-OrdersTests’ ‘UC35-WritesPrescription’
‘UC36-ManagesConsultationSchedule’
20

“Accounting” Use Case Diagram
Pre-condition is that
the Bill has been Issued
‘UC50-PaysBill’
‘UC55-PaysBillByCard’
‘A10-Patient’
<> <>
‘A00-CardReader’
‘UC56-PaysBillOnInternet’
<>
‘UC57-CashChequePayment’
‘UC58-PlacesInsuranceClaim’
‘A00-Printer’
‘A20-PrivatePatient’
Note: In this use case diagram, the system boundary has not been drawn. However, observe how the use cases are all grouped together in the centre of the diagram and the actors are on the outside. This improves the aesthetics of the use case diagram.
21

“Business Customer’s Activities” Use Case Diagram
22

“Human Resource’s Activities” Use Case Diagram
• Human Resource (HR) Management: adding / maintaining employee’s personal records (e.g. information, salary, degree, skills, etc), work schedule of employees, leave and leave balances.
23

“Human Resource’s Activities” Use Case Diagram
24

Use Case Diagrams: Common Pitfalls!
• Treated as Data Flow Diagrams
– Use Activity Diagrams to Show the Flow
• Looks like a Spider’s web
– Abstract both Actors and Use cases and draw separate
‘abstract’ use case diagrams
• Too Coarse or Too Fine Granularity
– Experience needed to Get it Right
– Perhaps Use Case Diagram Patterns can Help?
• UseCaseDiagramstreatedasDeliverables – More than 50% work is Documenting Use Cases
• Force fitting Actors that Don’t Exist
25

What happen within a use case or the system?
Activity Diagrams
26

Major Ingredients of an Activity Diagram
Start Activity
Stop Activity
Flow of Activities
Activity
Fork / Join
Decision Point
Partition
Notes
27

What is an Activity Diagram?
• Essentially a Flow Chart
• Able to visually show Sequentially Dependent Business
Objects
• However, in addition to a Flowchart, they also show:
– Multiple Threads
– Partitions (swimlanes) resulting in their use in Workflow modelling
• They do not have separate Documentation within UML
28

Purpose of Activity Diagrams
• Primary purpose is to show the flow of Activities – Within the requirements (use cases)
– In the System
– For the Overall Business
• A highest level Activity Diagram can be used as a Context-diagram
– showing how various business processes are related
29

“Registers Patient” Activity Diagram
‘A10-Patient’
‘A80-Administrator’
S ys te m
‘A90-GovtHRS’
AnnounceArrival
YES
‘Provide Details’
If Patient is already Registered, then they need not be Registered again here.
FirstTime? NO
‘Enter Details’
Additiona / Mandatory Details have to be provided by the First time Patient
NO
‘Verify Details’
DetailsCorrect?
CreatePatientRecord
Verify Medical Insurance Details
Private Patient
details will be
similarly forwarded to their Insurance company
RegistrationConfi
rm ed
30

Staff is seeking their own personal calendar (Roster)
Staff update the Calendar with their availability
Roster duties are also updated
System Validates the data entered by Staff against existing Calendar, and against other Staff’s Calendar.
31
‘A50-Staff’
System
Request Personal Calendar
EnterPreferred RosterDetails
Provide Calendar Options to Staff
AcceptDetails
Provides Personal Calendar
ValidatePreferred RosterDetails
YES
NO
ConflictingRosters ?
UpdateCalendar
“Maintains Calendar” Activity diagram

Specifies Initial Details for Consultation
SelectsPhysician
SelectsDay&Time
ViewsConfirmation
UpdatesCalendar
‘A10-Patient’
System
These details include selecting first from a
list of services (diseases)
ProvidesLIstof Physicians
ProvidesAvailable ConsultationDays&Times
Patient may indicate type of consultation (Brief, Detailed)
32
“Books Consultation“ Activity Diagram

“PaysBill“ Activity Diagram
This is a generic PaysBill Activity Diagram. It is extended to specific types of Payments
See extended
use cases and their activity diagram s for
paym ent by C ard, Internet and Cash/Cheque
33
‘A 1 0 -P a tie n t’
S y s t e m
R eceivesBill
V a lid ? YES
PaysBill
VerifiesBill against
C o n s u ta tio n s
N O
ReportError

Make New Booking Activity Diagram
++ NOTE: This Activity Diagram follows the NewBooking Use Case
Use Case Thumbnail: UC10-NewBooking
Actors: A20-OnlineCustomer, A130-OnlineCustOperator, A00-
Printer
Use Case Description: this use case deals with booking a new travel online. A20-OnlineCustomer selects destinations, date and time and any associated activities, such as car rental, hotel, etc. A20-OnlineCustomer also need to log onto the system in order to confirm the booking and pay the fee. The customer operator must double check the booking and contacting the customer if required. A receipt will be given to the customer.
Pre-Conditions: N/A.
Post-Conditions: Booking is issued with the receipt.
34

Use Case for NewBooking (cont)
Basic Flow:
1. A20-OnlineCustomer requests a travel booking with the system.
2. The system provides the travel booking page with destinations, date/time and preferable carrier(s).
3. The customer selects the destinations, date/time, and carrier preference.
4. The system displays the matching information (A1).
5. The customer selects a trip (A2).
6. The system confirms the travel detail and offer suggestion for associated activities including car rental, hotel and tour.
7. The customer selects an associated activities (A3). 7.1 <> Book a car/hotel/tour use case
8. The system updates the booking record
9. The customer logs onto the system to confirm the booking and pay the fee (A4)
10. Thesystemacknowledgesthebookingwithareceipttothecustomer.
11. A130-OnlineCustOperatorchecksthebookingonsite(A5) 11.1 <> Operator checking use case
35

Use Case for NewBooking (cont)
Alternative Flow:
A1 – There is no matching travel. The customer is asked to change the information, such as date/time and preferable carriers
A2 – The customer does not like the recommendation. The system provides new travel information according to the new preference.
A3 – No other activity is selected. The system moves to the next step.
A4 – Invalid login detail. The system asks the customer to enter the login information again or register detail if he/she is a new customer.
A5 – If further information is required from the booking, the OnlineCustOperator contacts the customer directly.
36

37
Make New Booking Activity Diagram

UML’s Extensibility Mechanism
Stereotypes and Notes
38

Extending UML
• UML provides three mechanisms to extend itself further
– Stereotypes – Mechanism to classify anything and everything in UML, by far the most popular
– Tagged Values and Constraints • MaynotbeusedduringAnalysis
– Notes: Can be used to Extend diagrams and add further value or explanation to all UML diagrams
39

Stereotypes
<< >>
guillemet
<> Doctor
Doctor
<>
<> RegistersPatientDetails
<>
40

Stereotypes (Cont.)
• Stereotypes are ‘types’ of types
– For Example: Some Use Cases deal with
Interactions, Others with Business Logic
– Use Cases dealing with Business Logic may be categorized as <> types of use cases or <> Stereotypes
– Class < as against <> and <>
• << >> is the notation for stereotypes
• Each UML artifact Has only one Stereotype
41

Some Stereo typed Classes
<> Patient
<> PatientForm
<> PatientManager
<

Notes
(A)
<>
Notes provide further explanation
(B)
A10-Patient
This actor will have specialised behavior when its an Internet Patient
(C)
BooksConsultation
A21-InternetPatient
Precondition to Booking a Consultation is that the Patient is Registered for Internet access.
43

NOTES: Invaluable in Enhancing Quality of UML diagrams
Notes can be drawn on ALL diagrams;
Notes help provide additional explanations on diagrams to
to enhance readability;
Notes are represented by a “Dog eared Rectangle” which is then linked to any other “‘things” to be annotated on the diagram. Notes may also be stereotyped, if required.
SampleClass1
SampleNote
name : char ID : int
44

Workbook
Exercises
For The Class Room!
45

Workbook Exercises
1. Name and draw two additional use case diagrams from the Hospital domain. Include at least two and three use cases spread over the two diagrams.
2. In the first use case diagram, show the include relationship between two use cases clearly. In addition, show an actor-to- actor inheritance relationship. Stereotype the actors use cases where relevant.
3. Ensure you have at least one non-human actor in this first diagram.
4. In the second use case diagram, show the extend relationship clearly. Again stereotype the actors and use cases.
5. Add notes on both diagrams to provide further explanations.
46

Workbook Exercises (Cont.)
6. Draw a detailed activity diagram that shows partitions, multithreads and decision points based on a use case in your project.
47

Project Work :
(During Practical in the Lab);
Carry Out the Project Work
Discuss Project Work with Team Members and Tutor
48

Conclusions
• UseCaseDiagramsaredrawnduringanalysisto Visualize
✓Users and their Interaction with the system.
✓Relationship between various Use Cases are discussed (Include, the most relevant relationship; Others are Extend and Inherit)
• Activity Diagrams show data flow ✓Within the requirements (use cases)
✓In the System
✓For the Overall Business
Object Oriented Analysis – 300144 49

RUPRUP Case Study – Train Traffic Management System (TTMS)
Inception-2
Object Oriented Analysis – 300144 50

Actors
• Users of TTMS
– Dispatcher: establishes train routes and tracks the
progress of individual trains.
– TrainEngineer: monitors the condition of and operates the train.
– Maintainer: monitors the condition of and maintains train systems.
• External system
– Navstar GPS: provides geolocation services used to track trains
Object Oriented Analysis – 300144 51

Use Case Route Train
• Use case name: UC 10 Route Train
• Use case purpose: The purpose of this use case is to establish a train plan that acts as a repository for all the pertinent information associated with the route of one particular train and the actions that take place along the way.
• Point of contact: Katarina Bach
• Date modified: 9/5/06
• Preconditions: A traffic plan exists for the time frame and geographic region (territory) relevant to the train plan being developed.
• Postconditions: A train plan has been developed for a particular train to detail its travel route.
• Limitations:
– Each train plan will have a unique ID within the system. Resources
Object Oriented Analysis – 300144 52

Use Case Route Train (Cont.)
– may not be committed for utilization by more than one train plan for a particular time frame.
• Assumptions: A train plan is accessible by dispatchers for inquiry and modification and accessible by train engineers for inquiry.
• Basic Flow:
1. The Train Traffic Management System (TTMS) presents the
dispatcher with a list of options.
2. The dispatcher chooses to develop a new train plan. (A1) (A2)
3. The TTMS presents the template for a train plan to the dispatcher.
4. The dispatcher completes the train plan template, providing information about locomotive ID(s), train engineer(s), and waypoints with times.
5. The dispatcher submits the completed train plan to the TTMS.
6. The TTMS assigns a unique ID to the train plan and stores it. The TTMS makes the train plan accessible for inquiry and modification.
Object Oriented Analysis – 300144 53

Use Case Route Train (Cont.)
• Alternate Flow A1:
1. Dispatch chooses to develop a new train plan,
based on an existing one.
2. The dispatcher provides search criteria for existing train plans.
3. The TTMS provides the search results to the dispatcher.
4. The dispatcher chooses an existing train plan.
5. The dispatcher completes the train plan.
6. The basic flow is resumed at step 5.
Object Oriented Analysis – 300144 54

Use Case Route Train (Cont.)
• Alternate Flow A2:
1. The dispatcher chooses to modify an existing train plan.
2. The dispatcher provides search criteria for existing train plans.
3. The TTMS provides the search results to the dispatcher.
4. The dispatcher chooses an existing train plan.
5. The dispatcher modifies the train plan.
6. The dispatcher submits the modified train plan to the TTMS.
7. The TTMS stores the modified train plan and makes it accessible for inquiry and modification.
8. This use case ends.
Object Oriented Analysis – 300144 55

Use Case Monitor Train System
• Use case name: Monitor Train Systems
• Use case purpose: The purpose of this use case is to monitor the onboard train systems for proper functioning.
• Point of contact: Katarina Bach
• Date modified: 9/5/06
• Preconditions: The locomotive is operating.
• Postconditions: Information concerning the functioning of onboard train systems has been provided.
• Limitations: None identified.
Object Oriented Analysis – 300144 56

Use Case Monitor Train System (Cont.)
• Assumptions: Monitoring of onboard train systems is provided when the locomotive is operating. Audible and visible indications of system problems, in addition to those via video display, are provided.
• Basic Flow:
1. The Train Traffic Management System (TTMS) presents
the train engineer with a list of options.
2. The train engineer chooses to monitor the onboard train systems. (A1) (A2)
3. The TTMS presents the train engineer with the overview status information for the train systems.
4. The train engineer reviews the overview system status information.
Object Oriented Analysis – 300144 57

Use Case Monitor Train System (Cont.)
• Alternate Flow A1:
1. The train engineer chooses to perform detailed monitoring of a system that has a yellow condition.
2. The TTMS presents the train engineer with the detailed system status information for the selected system.
3. The train engineer reviews the detailed system status information.
4. The basic flow is resumed at Step 2.
Object Oriented Analysis – 300144 58

Use Case Monitor Train System (Cont.)
• Alternate Flow A2:
1. The train engineer requests a failure prediction analysis
for a system.
2. The TTMS performs a failure prediction analysis for the selected system.
3. The TTMS presents the train engineer with the failure prediction analysis for the system.
4. The train engineer reviews the failure prediction analysis.
5. The train engineer requests that the TTMS alert the maintainer of the system that might fail.
6. The TTMS alerts the maintainer of that system.
7. The maintainer requests the failure prediction analysis for review
Object Oriented Analysis – 300144 59

Use Case Monitor Train System (Cont.)
8. The TTMS presents the maintainer with the failure prediction analysis.
9. The maintainer reviews the analysis and determines that the yellow condition is not severe enough to warrant immediate action.
10. The maintainer requests that the TTMS inform the train engineer of this determination.
11. The TTMS provides the train engineer with the determination of the maintainer.
12. The train engineer chooses to perform detailed monitoring of the selected system.
13. The alternate scenario is resumed at Step A1-3.
Object Oriented Analysis – 300144 60

Object Oriented Analysis – 300144 61
Use Case Diagram for TTMS