52.234 Systems Analysis and Design

Class Project

 

Second Stage

 

Deadline: Friday, March 11

 

 

Weight: 100 out of 200

 

 

Deliverables:

 

  1. A Use Case Diagram. Your diagram should include all the use cases for all the actors of the system. It should also show relationships both between use cases and between actors. You should always keep in mind that too much detail in a use case diagram rather obscures than clarifies matters.
  2. Use Case Descriptions. You should provide short description (not more than 4 lines) for all the use cases of the system. You should also provide extended use case descriptions for the 3 most interesting use cases of the system. In addition to that you should provide a small paragraph (not more than 5 lines) that justifies your choice of use cases.
  3. Class Diagram. Provide a class diagram for the system. The class diagram should show all the classes of the system, their corresponding attributes and associations, and indicative operations. Any assumption made during the construction of the class diagram should be documented.
  4. Activity Diagrams. Select two of the most interesting use cases and provide an activity diagram for them.
  5. Interaction Diagrams. For the use cases you selected in 4, draw sequence diagrams. Make sure that the operations in the sequence diagrams are consistent with the operations of the class diagram for the corresponding classes.
  6. Statechart. Select the most interesting class and determine its different states, the events that cause changes in its state. In addition to that, provide a statechart for the selected class.

 

Supporting Material, Assumptions and Advice:

 

·        The consistency between the various deliverables is of paramount importance.

 

·        The information below is by no way complete. For any additional information or any clarifications regarding the provided information, you should use the class newsgroup.

 

After the initial requirements elicitation phase was carried out it became clear that the train ticket reservation system should support three particular aspects of functionality: (a) the purchasing of ticket for trips by customers, (b) the checking of passenger ticket validity, and (c) the monitoring of ticket sales.

 

More specifically, customers can purchase tickets for particular trips. Each trip has a start and a destination, which are either rail stations serviced by Stinking Trains S.A., or bus stations that are part of the collaborating bus routes. Trips are either single or return with each leg of a trip taking place on a particular date. A trip may be direct from the start to the destination, or may include a number of changes. Changes take place at particular rail or bus stations and link different services, either rail or bus ones. As a result, a trip contains one or more services. Each ticket is for one trip, but may be for any number of passengers. There are three types of tickets: (i) fixed ones, which are for a particular date and particular services that cannot be changed, (ii) flexible ones, which are also for a particular date and particular services that may subsequently be changed, and (iii) open ones, which are for a particular date but for any services of that day. Fixed and flexible tickets guarantee passengers a seat, while open ones do not. In general, customers should not be allowed to buy tickets for services that have no available seats. The price of the ticket depends on the number of passengers, the services comprising its trip and its type. Tickets can either be paper or electronic ones depending on the way in which the purchase was carried out (e.g. online or phone purchases issue electronic tickets, while machine or desk purchases issue paper tickets). In both cases a ticket code is produced that can be subsequently used to check ticket validity. Payment for tickets can be either in cash, using a debit or credit card, or by mobile phone charge. In the case of card payment customers needs to provide their card details and address, while in the case of mobile phone payments they need to provide their mobile phone number and a special code provided by their service provider. Furthermore, when customers purchase tickets, besides their trip details, they can specify their preferences with respect to the number of changes they want and the system should list all available services satisfying the customers’ requirements.

 

In the case of flexible tickets customers may later change the date and/or time of their ticket. For this purpose, they either need to use the paper ticket itself or the code of the electronic ticket. In all cases when a change is carried out a new ticket is issued. Whether the new ticket is paper or electronic depends on how the change was carried out (i.e. online, on the phone, etc.). Note that a change of ticket may require additional payment from the customer in the case that the new trip is more expensive than the original one.

 

In order to support the purchasing of tickets the system needs to maintain information about the various services. Both rail and bus services start from a particular station and finish on another, and they take place on particular date and time. Note that on the same date there may be a number of services from the same start to the same finish at different times. A service includes a number of intermediate stations, which are either all rail stations in the case of rail services or bus stations in the case of bus services. Most stations are either a rail or a bus ones, but some are both. Trips can use only part of a particular service, i.e. they do not have to go from the start to the finish but may instead only go through a number of the intermediate stations. Moreover each service is carried out by either a train or a bus that has a limited capacity of seats. As trips may only use part of a particular service their corresponding seat is only taken during that part.

 

The checking of passenger ticket validity is carried out either by ticket controllers of Stinking Trains S.A. or of the bus companies that offer collaborating routes, or by automatic machines (e.g. electronic gates). In all cases this process involves using the ticket code to retrieve the trip details and to check whether use of the particular service on which the check is carried out is covered or not. Moreover, the checking of paper tickets involves a ticket reader that reads the code of the ticket, while the checking of electronic tickets involves keying in the ticket code. Note that for tickets that do not guarantee a seat use of a particular service may be refused in order to avoid overcrowding.

 

The monitoring of ticket sales is only available to Stinking Trains managers and finance and service-planning staff. Managers can view summarised information regarding the overall tickets sales and the utilisation of particular services, the overall ticket sales of the company, the money collected and the real revenue (i.e. the part of the collected money that remains after service charges and payments to collaborating bus companies have been made). Service planning staff can only view overall ticket sale and utilisation of particular routes in order to decided whether changes in capacity are necessary. Finance staff can view all the information available to managers and also summaries of the amount to be paid in the various collaborating companies as either service charges or bus ticket sales.

 

Staff members of Stinking Trains S.A. are responsible for the maintenance of the information in the system. In particular, finance staff is responsible for updating the pricing information for the different services and ticket types, service-planning staff is responsible for entering and removing rail routes and of changing the capacity of services (i.e. adding or removing carriages from the trains), and the director of commercial relations is responsible for entering and removing new bus routes and changing the commercial terms of the collaboration with other companies (e.g. the service charge that mobile phone operators or card companies are paid for ticket purchases).

 

Submission Guidelines:

 

  1. Your submission should include a cover page and all the required deliverables clearly marked with the appropriate title.
  2. The cover page should include the project group number, and names, registration numbers and signatures of all the group members. If a group member did not participate at all to the submission, he or she should not be allowed to sign it.
  3. All submissions should be given to the departmental secretaries’ office L11.06 no later than 16:00 on the submission deadline date.
  4. All submission material should be typed. All UML diagrams should be created using Together Control Center. All other diagrams should be created using an appropriate software package. Any handwritten material will not be marked.

 

Note: Failure to comply with the submission guidelines will lead to a reduction of marks from your submission.