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 concessionaire 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
2
–
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).
3
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”. In your answer you
should use the use case specification of this use case and of the use cases related to
“Book seats” 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 “Booking” 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 solution domain. You are expected to
demonstrate your understanding of this aspect of design by addressing the following
three aspects:
Assume that the data in SADBOMS will be stored in a database (customers,
reservations, payments, etc.) 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);
Refine the analysis model of 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 defined the Payment processor
API. Integrate IPay and PayClass in your design class diagram (Hint: IPay and
PayClass are likely to replace the boundary class PayGateway).
Provide a minimal design for the communication with the SMTP server, e.g.
refine the boundary class, SMTPGateway, by adding design details. You may
follow the suggestions provided above on how to design the communication
with the payment processor.
(50 marks)
4
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, 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).
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)