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

Template: Documenting Use Cases…
• 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
28

Template: Documenting Use Cases…
• User Interface Specifications
–
• Metrics
–
• Priority
–
• Status
–
• Author & History
–
• Reference Material
–
29

Brief Use Cases in the HMS
Use Case Thumbnail: UC10-RegistersPatient Actors: A10-Patient, A80-Administrator, A90-
GovernmentHealthRegulatorySystem, A95-PrivateInsuranceProvider
Use Case Description: this use case deals with registration of new patients in the hospital management system. These registration details include name, address, date of birth and related details of the patient, including Medicare card and status (private or public patient). A10-Patient provides all the details and A80-Administrator enters them into the system. A90-GovermentHealthRegulatorySystem is an interface to an external system, which is provided by the State department of health, to verify the Medicare card details of public patients. A95-PrivateInsuranceProvider is an interface to an external system for individual private health insurance companies, to verify the insurance details of private patients.
30

Brief Use Cases in the HMS
Use Case Thumbnail: UC30-BooksConsultation
Actors: A10-Patient
Use Case Description: this use case describes the process by which A10-Patient is able to book a consultation with a Doctor. This process would require the A10-Patient to search for information on availabilities of doctors, relevant for particular ailments, on a particular day and time. The system would help provide alternative and patient will select from those alternatives.
31

Detailed Use Cases Documentation
Use Case Thumbnail: UC10-RegistersPatient
Use Case Description: this use case deals with registration of new patients in the hospital management system. These registration details include name, address, date of birth and related details of the patient, including Medicare card and status (private or public patient). A10-Patient provides all the details and A80-Administrator enters them into the system. A90-GovermentHealthRegulatorySystem is an interface to an external system, which is provided by the State department of health, to verify the Medicare card details of public patients. A95-PrivateInsuranceProvider is an interface to an external system for individual private health insurance companies, to verify the insurance details of private patients.
Stereotype and Package: <>
Pre-Conditions: Patient must have not been already registered with the
hospital
Post-Conditions: Patient is registered in the hospital system
Actors: A10-Patient, A80-Administrator, A90- GovernmentHealthRegulatorySystem, A95-PrivateInsuranceProvider
Use Case Relationships: ?
32

Detailed Use Cases Documentation
Basic Flow:
1. A patient arrives at the hospital for some medical treatment
2. The administrator asks the patient if they have been previously treated at this hospital
3. Patient provides the answer (A1)
4. Administrator asks patient for his/her personal details such as Name, Address, Telephone, DOB, Emergency Contact
5. Patient Provides details as requested
6. Administrator enters details into system
7. System verifies details (A2)
8. Administrator asks patient whether he is a public or private patient
9. Patient provides the answer
[Public]
a. Administrator asks public patient for Medicare number
b. Patient provides Medicare number
c. Administrator enters Medicare number into system
d. System verifies patient identity with Government Health Regulatory System (A3)
33

Detailed Use Cases Documentation
[Private]
a. Administrator ask private patient for insurance details
b. Patient provides insurance details
c. Administrator enters insurance details (e.g. company & policy number) into system
d. System verifies patient identity with Private Health Insurance Company System (A4)
10.
11.
System saves patient details
System confirms patient registration
Alternative Flow:
A1 – if the patient has visited the hospital previously, he/she will have been registered in the hospital’s system. The administrator informs the patient of existing registration.
A2 – If insufficient or incorrect details have been provided, the patient is requested to provide the details again
A3- The patient cannot be verified with the government health regulatory system, so the administrator asks the patient for the Medicare card detail again. If no verification is possible, the patient is conditionally registered as either a full fee paying patient, or one who will provide Medicare details later
A4- The Patient cannot be verified with the private health insurance company’s system, so the administrator asks the patient for the private health insurance details again. If no verification is possible, the patient is conditionally registered as either a full fee paying patient and his details with the health insurance company are to be verified later
34

Detailed Use Cases Documentation
Exceptions: None
Constraints: None
User Interface Specifications: UI10-Patient Registration Form Metrics: Complex,
Priority: High
Status: Major
Author & History: John Mathew
Reference Material: Details of patient that are required by law are specified in the hospital’s patient policy. Document is available from the administration department
35

Sources of Use Cases
• User Workshops
– Following the Joint Application Design style
– Playing various Scenarios with Users – Critical Requirements Analysis
• Formal and Informal Problem Statements
• Knowledge of Domain Experts
• InterviewsandDiscussions
• ExistingSystems(esp.Legacy)
• UseCasePatterns/PublishedLiterature/URLs
36

Detailed Use Cases Documentation– Another Example
Use Case Thumbnail: UC30-BooksConsultation
Use Case Description: this use case describes the process by which A10-Patient is able to book a consultation with a Doctor. This process would require the A10-Patient to search for information on availabilities of doctors, relevant for particular ailments, on a particular day and time. The system would help provide alternative and patient will select from those alternatives.
Stereotype and Package: <> Pre-Conditions:
Patient is already registered in the system and has identified himself to the administrator.
Post-Conditions:
Patient is given a date and time of his consultation. Actors: A10-Patient, A80-Administrator
Use Case Relationships:
<> UC24-ChecksCalender
37

Detailed Use Cases Documentation– Another Example (Cont.)
Basic Flow:
1. Patient requests a consultation with a doctor to the administrator.
2. Administrator request details of the patient’s condition.
3. Patient describes his/her condition to the administrator.
4. Administrator enters condition into system.
5. System provides a list of doctors and their available consultation times for the specified condition.
5.1 <> UC24-ChecksCalender
6. Patient selects a doctor and their preferred time (A1).
7. Administrator enters selected doctor and time into the system.
8. System schedules the consultation and updates doctor’s personal calendar.
9. System confirms consultation time, room and doctor.
Alternative Flow:
A1 – None of the offered times and doctors are acceptable to the patient, so the patient cancels his/her request
38

Detailed Use Cases Documentation– Another Example (Cont.)
Exceptions: None.
Constraints: None.
User Interface Specifications: UI30-ConsultationMaintenanceForm Metrics: Simple
Priority: Low
Status: Major
Author & History: John Citizen
Reference Material: None
39

Strengths
1. Models the Important user as Actor 2. Organises Requirements
3. Facilitates communication
4. Documents all Functionality
5. Reuses and extends requirements 6. Facilitates Traceability of Reqs.
7. Provides System context/Boundary
Weaknesses
1. Not object-oriented
2. Have no documentation standards 3. Imprecise Relationships
4. Granularity is subjective
5. Has no Flow of use cases
Objectives
1.Visualise how system is used 2.Scope and Prioritise requirements 3.Facilitate project estimation
4. Facilitate contract management 5. Starting point for other diagrams
Traps
1. Can’t express Non-functional req.
2. Ignoring internal use case doc.
3. Coding directly from use cases
4. Pedantic usage, in other modeling spaces
5. Use case driven project plans
SWOT of Use Case
40

Common mistakes
• Toobrief
1. Patient expresses his/her interest in booking a consultation with
the doctor.
2. Administrator books a doctor appointment for the patient.
Use cases should tell the complete story of users using the software to do something
41

Common mistakes (Cont.)
• One-personshow
1. Patient comes in.
2. Patient wants to book a doctor appointment. 3. Patient provides his personal details.
4. Patient picks a doctor and a time.
• Unclearsubjects/actors
1. An Express of interest is made for booking a consultation. 2. Details provided.
3. Details confirmed.
Use cases should show interactions between actors and the system; “who did what” should be clear from use case documents
42

Common mistakes (Cont.)
• Missingsystembehaviour
1. Patient requests a consultation with a doctor to the administrator.
2. Administrator request details of the patient’s condition.
3. Patient describes his/her condition to the administrator.
4. Administrator enters condition into system.
5. Patient chooses a doctor and their preferred time.
6. Administrator enters selected doctor and time into the system.
7. Patient has made an appointment with the selected doctor at the given time.
Use cases should describe what the users want the system to do for them
43

Common mistakes (Cont.)
• Fixing the “missing system behaviour” problem
1. Patient requests a consultation with a doctor to the administrator.
2. Administrator request details of the patient’s condition.
3. Patient describes his/her condition to the administrator.
4. Administrator enters condition into system.
5. System provides a list of candidate doctors and their available times.
6. Patient chooses a doctor and their preferred time.
7. Administrator enters selected doctor and time into the system.
8. Patient has made an appointment with the selected doctor at the given time.
9. System confirms the appointment time and updates the doctor’s calendar.
44

Workbook Exercises
For The Class Room!
45

Workbook Exercises
1. Identify and List 5 additional Actors from the hospital domain. Ensure at least one Actor is a non-human or a device. Stereotype them appropriately.
2. Place the Actors you identified above in an Actor diagram with appropriate Actor hierarchy. Add notes for clarification.
3. Document any one of the actors you have identified above. Use the template provided in the appendix.
4. Identify and document TWO use cases: one in the shorter version and another in greater detail using the longer and more formal version of use case documentation. Use the template provided in the appendix.
46

Great Western Real Estate Management System
Actors and Use Cases
47

Conclusions
• Use Case Modeling Includes:
✓Identification of Actors (primarily Users, but also other
external interfaces)
✓Documentation of Actors
✓Creation of Actor Hierarchy for Simplification
✓Identification of Use Cases based on the Actors Identified
✓Documentation of the Use Cases in sufficient details (to be able to identify Classes)
• Pre-prepared Template for Actor and Use case documentation is helpful
48

Project Work : (During Practical in the Lab)
Follow the Project Work Requirements described in Tutorial 3;
Discuss Project Work with Team Members and Tutor;
Carry Out the Project Work
49

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

Project Background
Trains provide an important and economical means of transporting passengers/goods in many countries. Additionally, as major metropolitan centres grow more crowded, light rail transport is increasingly providing an attractive option for easing congestion and addressing the problems of pollution caused by cars.
Railroad companies must delicately balance the demands of frugality and safety and the pressures to increase traffic against efficient and predictable train scheduling. These conflicting needs suggest an automated solution to train traffic management, including computerised train routing and monitoring of all elements of the train system.
The motivation for such a system is largely economic and social: lower operating costs and more efficient use of resources are the goals, with improved safety as an integral by-product.
Object Oriented Analysis – 300144 51

Critical Requirement Analysis
• The Train Traffic Management System has two primary functions:
– train routing
– train systems monitoring
• Functional requirements include – traffic planning,
– Failure prediction,
– train location tracking,
– traffic monitoring,
– collision avoidance
– maintenance logging
Object Oriented Analysis – 300144 52

Critical Requirement Analysis (Cont.)
• Non-functional requirements
– Safely transport passengers and cargo
– Support train speeds up to 250 miles per hour
– Interoperate with the traffic management systems of operators at the TTMS boundary
– Ensure maximum reuse of and compatibility with existing equipment
– Provide a system availability level of 99.99%
– Provide complete functional redundancy of TTMS capabilities
Object Oriented Analysis – 300144 53

Critical Requirement Analysis (Cont.)
– Provide accuracy of train position within 10.0 yards
– Provide accuracy of train speed within 1.5 miles per hour
– Respond to operator inputs within 1.0 seconds
– Have a designed-in capability to maintain and evolve the TTMS
• Constraints
– Meet national standards, both government and industry
– Maximise use of commercial-off-the-shelf (COTS) hardware and software
Object Oriented Analysis – 300144 54

Object Oriented Analysis – 300144 55
Top Level Subsystems (Packages)