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 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:
  • receptionist (the staff working in the box-office who will be able to use the BOS subsystem),
  • 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).
  • customer, (i.e., members of the public, who will be able to make on-line bookings and payments. No login is required).
  • 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).

Assignment

You are expected to refine some of the models provided in the Appendix (and made available as a Visual Paradigm project, released via Moodle with this assignment) and develop a set of new models on the SADBOMS by answering the following questions.

Question 1: Design class diagram

Appendix 1 shows one of the analysis packages, the Reservation package. You are expected to refine the Reservation package and add design level details to the classes, the relationships between them and design the access to this subsystem of SADBOMS from the other parts of the system (subsystems). The Reservation package contains the following classes:

• Ticket,
• Seat,
• Performance, and - Reservation.

The following details must be added:

• Each analysis class should be refined, and its attributes and operations (methods) must be fully specified with types, visibility and, if appropriate, cardinality (arrays, vectors, etc.). For each of the methods a return type must be clearly defined, too.
• Constructors (one or more) should be added to each of the design classes, as necessary, with full details parameters and their types.
• The associations between design classes should be refined, too: the simple associations in the analysis class model should become aggregations/compositions and navigability should be added. 1-to-many associations should be refined using collection classes such as arrays, vectors (check the lecture notes and Arlows book if in doubts). o Design should also try to achieve loose coupling between classes included in different packages/subsystems by revising the associations between classes captured in the analysis class diagram. Some of the associations shown in the analysis class diagram may be dropped. You may also discover that some new associations are needed. You may apply CRC cards and refine the responsibilities of the classes or even discover new class responsibilities, which are delegated to other (new helper) classes.
• Finally, in design you must add classes from the solution domain. You are expected to demonstrate your understanding about how in design we mix problem domain classes (which are shown in the analysis model) and classes from the solution domain by addressing the following three aspects:
  • Assume that the SADBOMS software uses a local database (e.g., the popular embedded SQL Lite or a more advanced RDBMS such as PostgrSQL) to store the relevant data. Provide a minimalistic design of database connectivity, which includes:
  • an interface for database access to store/retrieve data from the classes in the Reservation subsystem to a database of choice, and
  • an implementation class which realizes the above interface (you can refer for examples to the lecture notes and to the model answers of the Tutorial on system design);
  • You are also expected to show which problem domain classes will be using/accessing database connectivity (these classes should have dependency relationship with the respective interface). If necessary, you can add helper classes to simplify the database access.
  • Design the communication between the Reservation subsystem and the other subsystems, e.g., with the classes which are outside the Reservation subsystem. You may define an interface, provided by the Reservation subsystem, which the other sub-systems will use to access the functionality of the Reservation subsystem. You may also need to define required interface(s), which the Reservation subsystem will use to access the other subsystems of SADBOMS software, e.g., for payments to be cleared.

Hint: You do not need to provide implementation classes for the required interfaces as these will be provided by the other sub-systems.

• Consider using design patterns, e.g., a Faade or other, suitable for the particular context to reduce the coupling between the subsystems of SADBOMS software.