RECENT ASSIGNMENT

Assignment1
Task Details
In this assignment, you are to apply Robustness Analysis in the initial design of a Swing-based booking system for a small restaurant. The restaurant only offers a degustation menu and there is one sitting per day. Bookings are made by telephone. Because of the popularity of the restaurant, bookings are only taken for the current week. The restaurant has 20 tables that can each seat a maximum of 4 people. If a booking is for more than 4 people, up to 4 tables can be combined, proving seating for 10 people. If the restaurant is fully booked, customers can choose to go on a waiting list. If a cancellation occurs, then the waiting list is processed as a queue.
The following 3 use cases will form the basis for the initial design:
1. Customer requests a booking
2. Customer makes a cancellation
3. Manager checks tables in use for a day / week
You are to provide the details for each of these use cases. In this regard, for use cases 1 and 2, the actor is the person answering the telephone, as he/she will be interacting with the booking system. Also, offering of cancellations to customers on the waiting list is not part of use case 2. It is a separate use case which is not in scope for this exercise. Finally, browsing of records/results (as in AddressBook) is not required. For your GUI design, I suggest that you use a design similar to the sample design document in Week 5, where query output is displayed in the Output text area.
The level of detail expected in the use case descriptions will be similar to that provided in the Robustness Analysis example discussed in Week 4. However, note that use case 1 will have alternate pathways. One way to capture alternate pathways in a use case description is outlined in
http://pmblog.accompa.com/2009/10/08/use-case-template-example-requirements-management-basics/
Once the use cases have been specified, you are to then apply robustness analysis in the manner described in Week 4 to create an analysis class diagram. The intermediate artefacts (communication diagrams and use case class diagrams) are to be provided in a Word document, together with the use cases and the analysis class diagram.
In a separate document, you are to provide an initial design document for the booking system. Your design document is to follow the format and content described in Week 5. An example design document is provided in the Week 5 Resources section – use this document as a guide. Note that a design document contains supporting text and not just diagrams. Furthermore, in the example document, some sections/content have been omitted (e.g. use cases and sequence diagrams). These must be provided in your document. However, the test plan section can be omitted.
In terms of the level of detail required, interfaces are not considered in robustness analysis. Consequently, they should not appear in your analysis class diagram. Also query methods in your design will be database specific, as in the original version of AddressBook and its first refactoring. Generalisation of data access, as in the Week 6 refactoring of AddressBook, is a detailed design concern. However, do note that robustness analysis will generate an architecture that is similar to MVP. In this regard, I would expect all control classes in the use case class diagrams to be consolidated into a single (presenter) class in the analysis class diagram.
Submission
You are to submit two Word documents – one containing the use cases and diagrams generated in the Robustness Analysis and the other a design document for the booking system that is based on the analysis class diagram that was generated from your robustness analysis.
Marking Criteria
Criteria Marks Available
Use case specifications 1.5
Robustness Analysis 8
Screens (one per use case) 3
Data access (tables, queries) 1.5
Sequence Diagrams (one per use case) 3
Report (supporting text for diagrams/tables; introduction for design document) 3
Total 20