Object Oriented Analysis & Design

By Ujjwal

I have a deadline this saturday.

This coursework, has 3 questions.

Use the scenario and answer them 3 questions.

1st Question is, Sequence Diagram

2nd Question is, Class Diagram

3rd Question is, State machine

Use the file below, as it has all the questions and scenario.

I need 1st class standard.

1 IN2013 Object-Oriented Analysis and Design Stevenage Amateur Dramatic Box Office and Membership System (SADBOMS) Dr Peter T. Popov Version 3.0 October 13th, 2015 Document History The changes introduced in this version of the document are summarized below: 1. Question 1 has been modified. A sequence diagram of the use case “MakeOnlineReservation” is now required. The references to the non-existing use case “Book Seats” have been removed from the question. 2. The use case “SearchSeats” in the diagram has now been renamed to “ViewAvailability”, thus making the diagram and the specifications consistent. 3. Question 2 has now been extended with further details about how to design the boundary classes and DB connectivity. 4. Various typos have been fixed. Introduction There is one piece of coursework for IN2013 worth 30% of the total mark for the module. You are asked to refine a set of models by extending the analysis and then to develop a detailed design of a part of the modelled system. Please note that although this coursework has been released at the beginning of Week 3, the coursework tests your knowledge of topics that will be taught in subsequent weeks, and you will not be able to answer all the questions until Week 4, unless you read ahead in the text book on system design and state machines. The coursework is not due in until the end of Week 7, but you should be able to answer the first two questions already. Hence, you are advised to start working on the coursework as soon as possible, and not delay starting until Week 7. The deadline for this coursework is 23:55 on 15th of November 2015, and all work must be submitted electronically in accordance with the guidelines below. 2 Scenario In the Stevenage Amateur Dramatic Society (SADS) theatre after the show one night, you are talking to the secretary of the society and discover that SADS have bought two second – hand personal computers (each with a fairly large hard disk and a DVD player), two broadband modems, and two printers. The membership secretary will have one computer, printer and modem at home. The other computer, printer and modem will be located in the theatre box office. Having bought this equipment, SADS do not have enough funds left in this financial year to buy any standard software packages, but can afford two broadband subscriptions. The CEO of one of the local Internet Service Providers (ISP), also a long term SADS supporter, has offered a minimal hosting package free of charge for a year that includes a web-server, large disk space, a single database, email server with up to 20 separate email accounts, and many software packages necessary for creating a minimalistic website. SADS urgently require a software solution to help them to manage box-office reservations and membership subscriptions. Being a graduate software engineer and a freelancer, and being also a life-long member of SADS, you offer to produce software for them free of charge. By talking to the secretary, you discover that the following seem to be the main requirements for the software that SADS wish to acquire: – The box-office subsystem (BOS) will allow theatre seats to be reserved by telephone. It will maintain a database of the seats available for each night, and display these on a seating plan on screen to the box-office staff who will enter the reservations in response to reservation requests made by telephone, but they will only be available to do this during box office opening hours. The customer making a phone reservation will be given a unique reservation number once the reservation has been successfully made. The system must also record payment for tickets as and when these are collected. The system must also allow the box office staff to handle returned tickets and cancelled bookings (e.g. all refunds are made in cash and the relevant reservations are cancelled). The payments will be collected by staff either in cash or with credit/debit card when tickets are collected: the customer collecting the ticket(s) is expected to show the reservation number to the box-office staff so that staff can retrieve from the system the amount due. Once a payment is collected, the respective reservation is recorded in the system as confirmed. The phone bookings are expected to be paid for in full at least 2 days before the particular performance. In case this does not happen SADS would like the system to cancel those (non-confirmed) bookings automatically so that other customers can book the released seats. – The membership subsystem (MEMS) will maintain a database of members’ names and addresses, record the payment of annual subscriptions, print the labels for posting of subscription reminders, newsletters and programmes of events or email them to members who have an e-mail address,. Handling subscriptions will be made more complicated by the fact that there are several types of membership: junior, senior citizen, non acting patron, etc., each with its own subscription rate. In addition, patrons pay a Concessionary price for tickets, so BOS must communicate with MEMS to check the type of membership. Members who provide an email address will be offered an online access to the system and will be able to pay their membership fee or purchase tickets on-line (see PAY subsystem below). The members, however, will not be able to alter any of their details. Should they require changes of their details they should contact the membership manager (e.g. by email) to request the change which only the membership manager can apply. – On-line payment subsystem (PAY). This subsystem will allow on-line bookings and payments to be made by customers/members. The customers will be able to view on their screen and choose from the seats available for a particular performance. Bookings will be confirmed by email only if a payment in full is made successfully (PAY will interact with an external Payment Processor such as PayPal to clear the payment 3 transactions). If the on-line payment is cancelled, the on-line payment transaction fails or no on-line payment is received within 30 min of the respective on-line booking, the system will cancel the on-line booking. – Assess subsystem (ACC). This subsystem will offer a basic authentication procedure for the users of the system: o receptionist (the staff working in the box-office who will be able to use the BOS subsystem), o membership manager (who will be able to work with the MEM subsystem), o system administrator (who will be responsible for creating new user accounts and deleting obsolete ones. The SADS are keen to delegate this responsibility to you). o customer, (i.e. members of the public, who will be able to make on-line bookings and payments. No login is required). o Members of the SADS, who will be able to pay their membership fee (login required), and make on-line bookings and payments (login required in case the members wish to use the concessionary prices they are entitled to). 4 Assignment You are expected to refine some of the models provided in the Appendix and develop a set of new models on SADBOMS and answer the following questions. Question 1: Use case realization (sequence diagram) a) Draw a sequence diagram that realizes the use case “Book seats” “MakeOnlineReservation”. In your answer you should use the use case specification of this use case and of the use cases related to “Book seats” “MakeOnlineReservation” and the analysis class diagram, both provided in the Appendix. The diagram should cover all possible branches, loops and alternative flows that are documented in the provided use case specifications. Make sure that your sequence diagram is consistent with the provided class diagram and the use case specifications. (25 marks) Question 2: Design class diagram Appendix 1 shows one of the analysis packages, the “Bookings” package, which includes the following classes: Ticket, Payment, (the sub-class CardPayment), Seat, Performance, Controller, Reservation, PayGateway (a boundary class, which models the interaction of SADBOMS with the external PaymentProcessor) and SMTPGateway (a boundary class, which models the interaction of SADBOMS with the external SMTP server). Design the “Bookings” subsystem of SADBOMS by adding design details to the “Bookings” package as follows: o Each of the analysis classes should be refined and its attributes and operations (methods) must be fully specified. o Add constructors (one or more) to each of the design classes, as necessary. o Refine the associations between the design classes and resolve them into aggregations/compositions and adding navigability as needed. o Design should achieve loose coupling between the classes. As a result of this effort in your design some of the associations shown in the analysis class diagram can be dropped. Also, as a result of detailed design you may discover that some new associations may be needed. You may need to use CRC cards and refine the responsibilities of the classes and more specifically, whether some of the responsibilities of classes are delegated to other classes. o Finally, in design you must add classes from the solution domain. You are expected to demonstrate your understanding by addressing the following three aspects: § Assume that the data in SADBOMS (customers, reservations, payments, etc.) will be stored in a database and provide a minimalistic design of database connectivity, e.g. define: · an interface for database access that can be used to store/retrieve data from SADBOMS to a database (e.g. MySQL database server), and · an implementation class that realizes the above interface; You will also need to design in detail how the data will move between entity classes and database connectivity. This will require you to introduce associations of the interface with the classes that can use the DB connectivity. § Design the SADBOMS interaction with the external Payment processor. Assume that a 3rd party class, PayClass, is available which implements an interface, IPay, which in turns defines the Payment processor’s API. Integrate IPay and PayClass in your design class diagram. (Hint: IPay and PayClass are likely to replace the boundary class PayGateway). 5 § Provide a minimal design for the communication of SADBOMS with an SMTP server, i.e. refine the boundary class SMTPGateway, by adding design details. One way to do that would be to follow the suggestions above on how to design the communication with the payment processor using an interface and an implementation class. (50 marks) Up to 5 extra marks will be awarded for using design patterns, e.g. Façade or other, suitable for the particular context. Question 3: State machine Develop a behavioural state machine diagram, which models the work of an instance of the class Reservation. The diagram should show the states of the instance, the transitions between the states with their events, guards and actions, the actions (entry/exit) and activities (do) associated with the states. The diagram must be consistent with the definition of the Reservation class (shown in the design class diagram that you develop answering Q2). Hint: Remember that the state of an instance is represented by the values of its attributes and the links that the instance may have with instances of the classes that the Reservation class has associations with. (25 marks) 6 Appendix Use case model Diagram Use case Diagram Specifications (of selected use cases) Use case ID: 22 Use case: MakePhoneReservation Brief Description: Receptionist books a seat taking details over the phone from a customer (member of the public) or a SADS member. Primary actors: Receptionist Secondary actors: None. 7 Preconditions: 1) System is operational. 2) The Receptionist has logged in to SADBOMS URL and chosen to make a phone reservation. Main flow: 1) The use case starts when the Receptionist selects “MakePhoneReservation” functionality. 2) The system sets the variable session.patron = false 3) if a member is making a phone reservation 3.1. The Receptionist activates the dialog “Member validation” extension point : ApplyConcessionaryPrice 4) include(ViewAvailability) 5) While (further reservations needed). 5.1. The Receptionist selects one of the available seats. 5.2. if(session.patron = true) Set Price = concessionaire price 5.2. else Set Price = normal price 5.3. The system books the seat, updates the seating view 5.4. The system returns a unique reservation number 6) The system saves all bookings. Postconditions: 1) All new bookings saved. Alternative flows: Cancel Use case ID: 22 Use case: MakePhoneReservation : Cancel Brief Description: Receptionist aborts making a phone reservation. Preconditions: System is operational. The Receptionist has logged in to SADBOMS URL and chosen to make a phone reservation. Alternative flow: 1) The flow may start at any step of the main flow. 2) The system aborts the bookings made in the main flow (if any) and restores the seating plan to what it was prior to the beginning of the main flow. Postconditions: None. Use case ID: 23 Use case: ApplyConcessionaryPrice Segment 1 brief description: The receptionist checks if a member is a patron and is entitled to paying a Concessionary price for tickets. Primary actors: Receptionist Secondary actors: None. Segment 1 Preconditions: System is operational. The user has activated the dialog “Member Validation”. 8 Segment 1 flow: 1) SADBOMS asks the user to specify the membership ID and provide validation details (e.g. their name). 2) The user specifies the membership ID and validation details. 3) The system validates the member. 4) If (a valid member and they are a patron) 4.1. The system sets the variable session.patron = true 5) Else 5.1. The system sets the variable session.patron = false Segment 1 postcondition: 1) The variable session.patron is set. Use case ID: 23 Use case: ViewAvailability Brief Description: User specifies the date of performance and obtains on screen the seating plan with the seats available. Primary actors: Receptionist, Online user Secondary actors: None. Preconditions: System is operational. The user has accessed the SADBOMS URL and has chosen to retrieve the seating plan. Main flow: 1) The system asks the user to specify the date of the performance they would like to view. 2) The user specifies the required date. 3) The system retrieves the seating plan for the chosen performance and displays it on the screen. 4) The system set the session variable session.noPerformance = false. Postconditions: 2) The seating plan is displayed on the screen. 3) Sets the session variable session,noPerformance = false. Alternative flows: NoScheduledPerformance Use case ID: 23 Use case: ViewAvailability : NoScheduledPerformance Brief Description: An exceptional situation is handled of the user specifying a date when no performance is scheduled. Primary actors: Receptionist, Online user Secondary actors: None. Preconditions: System operational, user has specified a performance date to view the seating plan. Alternative flow: 1) The flow starts after step 2 of the main flow. 9 2) The system shows on screen an error message ‘No performance scheduled for the day’. 3) The system set the session variable session. noPerformance = true. Postconditions: Sets the session variable session. noPerformance = true. Use case ID: 24 Use case: MakeOnlineReservation Brief Description: A user makes an on-line booking. Primary actors: Customer, SADS Member Secondary actors: None. Preconditions: System is operational. The user has accessed the SADBOMS URL and has chosen to make an online reservation. Main flow: 1) The use case starts when the user activates the functionality “MakeOnlineReservation”. 2) include(ViewAvailability) 3) The user selects one of the available seats. 4) if(session.patron = true) // session.patron is set in Login. Set Price = Concessionary price else Set Price = normal price 5) The system books the seat and updates the seating view 6) The system returns a unique reservation number 7) include(MakeOnlinePayment) 8) The system emails the reservation details/tickets to the user1. 9) The system saves all bookings. Postconditions: The new booking saved. Reservation details/tickets emailed to the customer. Alternative flows: Cancel Timeout NoPerformance PaymentIncomplete Use case ID: 24 Use case: MakeOnlineReservation : Cancel Brief Description: A user aborts an on-line booking. Primary actors: Receptionist, Online user Secondary actors: 1 Here two assumptions are made (these are consistent with the actual payment processors, e.g. PayPal): 1) the payment processor will return to SADBOMS a confirmation for the payment which includes the payment status (success or declined/cancelled) and ii) the payee email address. The payee email address is used by SADBOMS to email the customer the reservation details/tickets. 10 None. Preconditions: The system is operational. The user has accessed the SADBOMS URL and chosen to make online reservation. Alternative flow: 1) The flow may start at any step of the main flow. 2) The user aborts the reservation. 3) The system cancels the bookings made in the main flow (if any) and restores the seating plan to what it was prior to the beginning of the main flow. Postconditions: None. Use case ID: 24 Use case: MakeOnlineReservation : Timeout Brief Description: Online payment has timed out (the on-line payment has taken longer than 30 min). Primary actors: Receptionist, Online user. Secondary actors: None. Preconditions: 1) System is operational. 2) The user has started an online payment after an online booking of a seat. 3) 30 min have passed since the beginning of the online payment. Alternative flow: 1) The alternative flow starts when 30 min have passed since the start of step 6 of the main flow and the step 6 has not been completed. 2) The system aborts the bookings made in the main flow (if any) and restores the seating plan to what it was prior to the beginning of the main flow. Postconditions: The booking made in the same session is removed. Use case ID: 24 Use case: MakeOnlineReservation : NoPerformance Brief Description: The online user has chosen a day without scheduled performances. Primary actors: Receptionist, Online user. Secondary actors: None. Preconditions: 1) System is operational. 2) The user has completed. viewAvailability 3) The variable session. noPerformance = true. Alternative flow: 1) The alternative flow starts after step 2 of the main flow. 2) The system aborts the online booking. Postconditions: None. Use case ID: 24 Use case: MakeOnlineReservation : PaymentIncomplete 11 Brief Description: Online payment did not complete successfully (either the user cancelled it or the payment transaction was rejected by the payment processor). Primary actors: Receptionist, Online user. Secondary actors: None. Preconditions: 1) System is operational. 2) The user has started an online payment after an online booking of a seat. 3) The variable session.payment_complete = false. Alternative flow: 1) The alternative flow starts after step 6 of the main flow. 2) The system aborts the booking made in the main flow and restores the seating plan to what it was prior to the beginning of the main flow. Postconditions: None. Use case ID: 25 Use case: MakeOnlinePayment Brief Description: An online payment transaction using a 3rd party Payment Processor. Primary actors: Receptionist, Online user. Secondary actors: Payment Processor. Preconditions: 1) System is operational. 2) A user has made an online reservation and the cost of the booking has been retrieved. 3) The user has been taken to the page of an online processor to make an online payment. 4) The transaction details (amount due and reservation reference) have been passed to the payment processor. Main flow: 1) The flow starts when the user is taken to the Payment Processor site to make a payment. 2) The user interacts with the payment processor as necessary and completes the payment. 3) The payment processor notifies the system of a successful payment. 4) The system saves the payment details returned by the payment processor. 5) The system sets the variable session.payment_complete = true Postconditions: 1) On-line payment recorded, 2) The variable session.payment_complete = true. Alternative flows: Cancel Failed Use case ID: 25 Use case: MakeOnlinePayment : Cancel Brief Description: An online user cancels the online payment. 12 Primary actors: Receptionist, Online user. Secondary actors: Payment Processor. Preconditions: 1) System is operational. 2) The user has started an online payment after an online booking of a seat. Alternative flow: 1) The alternative flow starts when the user chooses not to proceed with the online payment (instead of providing the payment details such as credit card details the user aborts the payment using the facilities offered by the Payment Processor). 2) The Payment Processor notifies the system of the payment cancellation. 3) The system records the cancellation (recording will be specific to the chosen Payment Processor). 4) The system sets the variable session.payment_complete = false. Postconditions: 1) A payment cancellation record is created 2) The variable session.payment_complete = false. Use case ID: 25 Use case: MakeOnlinePayment : Failed Brief Description: An online payment transaction fails (e.g. due to insufficient funds on card or some other reason). Primary actors: Receptionist, Online user. Secondary actors: Payment Processor. Preconditions: 1) The system is operational. 2) The online payment transaction started by a user has failed. Alternative flow: 1) The alternative flow starts when the user completes the online payment interaction with the Payment Processor (step 2 of the main flow). 2) The Payment Processor notifies the system that the transaction has failed. 3) The system records the cancellation (details recorded will depend on the chosen Payment Processor). 4) The system sets the variable session.payment_complete = false. 5) The system notifies the user of the failure. Postconditions: 1) A payment cancellation record created. 2) session.payment_complete = false. 13 Analysis class diagram 14 Submission guidelines 1) Submissions can only be made electronically via Moodle, using the coursework submission area for the IN2013 module. 2) The deadline for submission is 23.55 on Sunday, the 15th of November 2015. 3) Moodle will adhere to the cut-off date/time and automatically prevent you from attempting to submit your work after the deadline. 4) I suggest that you do not even attempt to work right up to the deadline and instead recommend that you get your submission in well before the cut-off time. The last thing you need is the stress and worry of watching the clock tick and then encountering a problem that delays you. It can and does happen! Late submission policy In accordance with the usual policy on coursework submission, late submission will receive 0% unless there are extenuating circumstances with supporting evidence, which must be notified to Nicola Daniel in advance of the deadline. Feedback We will aim to get coursework marked and returned to you by the end of Week 10. General feedback will be provided during the revision lecture in Week 10, and you will also receive individual feedback and a provisional mark via the grade book in Moodle. Format All UML diagrams must be created using a UML tool and exported as images for subsequent inclusion in the submission document. Diagrams drawn without a tool will be penalized by deducting 20% from the awarded mark. Your coursework must be submitted as a single PDF file. Export your diagrams from the UML tool you have used as images, and then assemble all your answers, text and diagrams, in a single word processor file and convert to PDF. Make sure you diagrams are eligible. UML Diagrams UML tools are available on PCs in the laboratories, and you can also download a copy for your personal machine (Windows, Mac, or Linux) by following the instructions on Moodle. Note that you may come across variations in UML syntax on websites and within certain textbooks. This is of no consequence for the purposes of this coursework.

Sequence diagram

Class diagram

State machine diagram

References

Dennis, A., Wixom, B. and Tegarden, D. (2002). Systems analysis and design, an object-oriented approach with UML. New York, NY: Wiley.