Skip to main content

辅导案例-INFS2037-Assignment 2

By May 15, 2020留学咨询

INFS2037 Assignment 2 Due date: Sunday, 10 November 2019, 11:55 PM Weighting: 25% of the course total marks. Submission instructions are at the end of this document. Instructions: This assessment item must be conducted in groups. Students must work in the group as published on the course website. If there are any issues with your group, please let the teaching staff know early, as it may be very difficult to resolve problems late in the study period. Your group will be responsible for designing the implementation of selected use cases of the Radiation Oncology Practice system case study. You may refer to the case study document provided in Assignment 1. You will be creating a suitable object-oriented design including the domain- and persistence layer: • This assignment focuses on developing use case realization at the domain layer of a system. The focus of this assignment should not be on designing a sophisticated user interface at the expense of addressing the functional requirements set out in the use cases. • Moreover, you do not need to design a database schema. For purposes of this assignment you can assume that all classes marked with a dedicated stereotype, e.g. “«persisted»”, are automatically persisted in a database using some persistence framework. You do not need to design the persistence mechanism. You do not need to consider user authentication in your design. You must ensure that your design is sufficiently complete and detailed so that it could be directly implemented in code. All submitted materials must be entirely your own work. Penalties apply for academic misconduct. Hand-drawn diagrams using a ruler are acceptable where appropriate provided that they are legible. You will receive marks via learnonline within 3-4 weeks. Answers will be scored based on relevance, completeness, and correctness of your answers. It is your responsibility to use appropriate document management and collaboration tools if required and to maintain adequate backup at all times. Hardware and software failure are not usually acceptable reasons for requesting extensions. Given that the presentations are scheduled in Week 13, it is not possible to ask for extensions for the presentation aspect of this assignment. A word of advice: do not allocate individual tasks to individual group members and design/develop in isolation. This strategy will almost certainly result in outcomes that do not align with each other, resulting in low marks, possibly even a Fail grade. Rather, collaborate closely with each other to address all four tasks. Start this assignment well before the due date. It is unlikely that you will be able to complete the work in one or two days. Assignment tasks This assignment consists of four tasks. Document all assumptions you make and justify the design decisions. 1. Interaction Diagrams Create interaction diagrams showing the use case realization for the main success scenarios of the use cases • UC01 Book Appointment, • UC02 Cancel Appointment, and • UC09 Find Appointment. Use case narratives are given in the Appendix. You may need to extend the use case narratives with more detail form in order to develop the detailed design. For each diagram, you can choose to create either a Communication- or a Sequence Diagram. For consistency it is recommended to use only one of the two diagram styles for this task. Document all assumptions you make and justify the design decisions. 2. Design Class Diagram Create a design class diagram for the system implementation, showing the classes, attributes, and associations. The design shall include all classes comprising the domain layer of the software implementation, including any controller class(es). Decorate classes that are persisted with the «persisted» stereotype. Ensure that the design adheres to the design principles discussed in the course, and that it includes all classes, attributes, operations, and associations necessary to implement the use cases. Document all assumptions you make and justify the design decisions. 3. Presentation in class Prepare a 15 minute Powerpoint presentation describing your design and implementation. Briefly discuss the main design decisions and design outcomes. Allow 2-3 minutes for questions. Treat the presentation as if you were working at a large development firm and were presenting your proposed design to a group of senior software engineers. Internal students: Each group will present their design in the practical class in week 13. One student per group will record the presentation on their phone and upload the presentation video and the Powerpoint presentation file to LearnOnline. Internal students must present in class to receive marks for this task, and it is recommended that all group members participate in the presentation. It is not sufficient to record and upload a video. The presentation schedule will be announced at a later date. External students: Please upload your group’s Powerpoint presentation file in PDF format and recording to learnonline. Continued next page 4. Individual Contributions Include a summary of the contributions each student has made to this assignment in the design document. Write one short paragraph per student. This will be used for adjusting marks of individual group members based on the extent and quality of their contributions to the overall project. Note that this does not imply that your marks will be determined by only the parts you have contributed to. However, particularly poor contributions may receive a grade that is different from the overall grade awarded to the group’s deliverable. Marking Scheme Task Weighting Task 1: Interaction Diagrams • Uses correct UML notation • Sufficiently complete to support implementation of each use case • Matches Design Class Diagram • Assumptions documented 40% Task 2: Design Class Diagram • Uses correct UML notation, appropriate for Design class diagram • Sufficiently complete to support implementation of each use case • Matches Interaction Diagrams • Responsibilities evident and assigned according to principles • Assumptions documented 30% Task 3: Presentation in class • Clear and focused presentation • Well laid out presentation aids • Covers all aspects of design and design decisions • Video recorded and uploaded • Ability to answer questions 15% Quality of Design Document Deliverable • Well laid out design document • Professionally presented • Easily legible when printed on A4 paper 15% Task 4: Individual contributions • All team members have adequately described their contributions. • If absent, all members may receive the same grade. Used to adjust individual marks Submission Instructions A separate submission area will be created for each group on LearnOnline. Please submit only one submission per group. (It is okay to update your submission.) Do not include any of the assignment specification in your submission nor a cover sheet. Submit the following three files and adhere to the file format and naming conventions: 1. Design.pdf A PDF file containing the following 3 sections listed below. Use the following section headings, in order: a) Interaction Diagrams: the interaction diagrams (Task 1) b) Design Class Diagrams: the design class diagram(s) (Task 2) c) Contributions: a summary of the contributions of each group member (Task 4) You should create multiple diagrams under each sub-heading if the design does not present well on a single page. 2. Presentation.pdf A PDF file containing the presentation slides used in Task 3. 3. Video.mov or Video.mp4 A video recording of the presentation in .mov or .mp4 format. The video must include audio and show the speaker (and, if possible, the presentation slides). Appendix A – Use Case Narratives Use Case UC 1: Book Appointment (detailed) Level: User goal Primary Actor: Receptionist (User) Triggering Event: Receptionis
t receives a referral from a GP for the patient by email or fax. Related Use Cases: UC 2: Book Initial Consultation, UC 14: Schedule Treatments Stakeholders and Interests: • Patient – wants to book an appointment with a Radiation Oncologist/Radiation Therapist; wants to receive confirmation of the appointment; wants to avoid waiting for a long time • Receptionist – wants to quickly book an appointment • Radiation Therapist – wants to avoid double-bookings • Practice Manager – wants to assess practice utilisation Preconditions: • Calendar has been populated with TimeSlots available for booking • The receptionist has made contact with the patient Postconditions: • New appointment has been created and associated with Patient, Radiation Oncologist/Radiation Therapist, and TimeSlot. • Appointment confirmation has been issued to Patient. • TimeSlot state has been changed to booked. Flow of activities: 1. Receptionist requests new Appointment. 2. System presents the available TimeSlots and Receptionist selects a TimeSlot. 3. Receptionist enters patient information and System validates information and creates a Patient. 4. System presents appointment summary and Receptionist confirms appointment. 5. System creates an Appointment and associates it with the Patient, the selected TimeSlot, and the Radiation Oncologist. System marks the TimeSlot state as booked. 6. System issues an appointment confirmation to the Patient. Alternative Flows: *a) No user interaction for 300 seconds *a.1) System aborts use case and reverts to home screen 2a) No timeslots available. 2a.1) Use Case terminates unsuccessfully 3a) Patient information incomplete 4a.1) System notifies Receptionist and repeats step 3. 3b) Patient already exists 4b.1) System retrieves Patient details and continues 4a) Receptionist does not confirm within 300 seconds 5a.1) Use case aborts unsuccessfully 5a) Time slot no longer available 6a.1) System informs Receptionist, and use case reverts to step 2. 6a) Issuing of confirmation message fails (email invalid) 7a.1) System logs failure and continues 6b) Issuing of confirmation message fails (messaging system unavailable) 7b.1) System queues confirmation locally and retries at a later time UC 1: Find Appointment Level: User goal Primary Actor: Receptionist (User) / Radiation Oncologist (User) Triggering Event: User searches for appointment Related use cases: • UC 3: Cancel Appointment • UC 8: Record Patient Arrival Stakeholders and Interests: • Receptionist / Radiation Oncologist – wants to find a specific appointment Preconditions: • Calendar has been populated with TimeSlots with associated Appointments Postconditions: • System has returned the appointment, if any Flow of activities: 1. Receptionist/Radiation Oncologist enters (partial) appointment confirmation number 2. system returns the matched appointment booking(s). Alternative flow: 1.a) Receptionist/Radiation Oncologist performs Error! Reference source not found. to requests patient’s appointments, and system returns appointments for the patient in chronological order. 1.a.1) Receptionist/Radiation Oncologist selects an appointment from the list. UC 2: Cancel Appointment Level: User goal Primary Actor: Receptionist (User) Triggering Event: Patient requests cancellation Stakeholders and Interests: • Patient – wants to cancel their appointment • Receptions – wants to ensure the correct appointment is cancelled. Preconditions: • Receptionist has verified the patient’s identity by asking the patient to confirm the patient’s full details prior to requesting cancellation. Postconditions: • The appointment has been marked as cancelled in the system Flow of activities: 1. Receptionist performs UC11 Find Appointment. 2. System verifies that the appointment can be cancelled. 3. Receptionist confirms patient details match in the appointment. 4. System marks the appointment as cancelled. 5. Patient is notified of the cancellation.

admin

Author admin

More posts by admin

Leave a Reply