52.234 Systems Analysis and Design

Class Project

 

Third Stage

 

Deadline: Friday, April 1

 

Weight: 50 out of 200

 

Deliverables:

User Interface Design

 

In order to make the development of the overall train ticket reservation system easier and faster, it was decided to break it down into a number of components that could be developed in parallel. Moreover, the decision was taken to have two separate components for the system one to support the customer interaction and one to support the functionality required by the Stinking Trains employees. In this stage we only focus on the former of the two components.

 

The support provided to the customers has two aspects: (a) support for purchasing tickets and (b) support for changing tickets. Regarding the user interface it was decided that each aspect would be supported by a separate user interface, namely purchase ticket and change ticket respectively.

 

1.      Purchase Ticket Interface design.

a.       Use Case Description. Provide an extended real use description of the Purchase Ticket use case. The use case starts with the customer specifying his/her trip details and preferences, which is followed by the system presenting a number of alternatives for the customer to choose from. After a particular trip has been specified, the customer can continue to select ticket and payment options.

b.      Purchase Ticket Interface Screen Layout. Design the layout of the main screen and any secondary screens that support the Purchase Ticket use case, according to the description you provided above.

c.       Sequence Diagram. Provide a sequence diagram for the Purchase Ticket use case. Your diagram should include both boundary (user interface) and entity classes and should describe the interaction between them during the execution of the use case (see also the class diagram provided below).

d.      Statechart. Provide a statechart describing the dynamic behaviour of each element of the user interface for the Purchase Ticket use case as designed above.

 

2.      Change Ticket Interface design.

a.       Use Case Description. Provide an extended real use description of the Change Ticket use case. The use case starts with the customer providing the code of its purchased ticket to the system. In response to this the system retrieves the associated ticket information and checks whether changes are allowed before proceeding to provide options for changing the data and/or time of the ticket. Remember that ticket changes may require additional payment.

b.      Change Ticket Interface Screen Layout. Design the layout of the main screen and any secondary screens that support the Change Ticket use case, according to the description you provided above.

c.       Sequence Diagram. Provide a sequence diagram for the Change Ticket use case. Your diagram should include both boundary (user interface) and entity classes and should describe the interaction between them during the execution of the use case (see also the class diagram provided below).

d.      Statechart. Provide a statechart describing the dynamic behaviour of each element of the user interface for the Change Ticket use case as designed above.

 

3.      Evaluation of User Interface Dialogue Design. Provide a short evaluation (no longer that one page) of the dialogue for the interfaces designed above.

 

4.      Peer and Self-evaluation on Group Functions. Each group member needs to fill in and email individually his or her peer and self evaluation form to Neil Walkinshaw. Note that you evaluate the performance both of yourselves and of all the group members that have participated to at least one stage of the project (i.e. you should not provide an evaluation for those that have not taken part in any stage of the project). There are four criteria on which you evaluate group members including yourself. These criteria are:

a.       Level of enthusiasm/participation

b.      Suggesting ideas

c.       Understanding what was required

d.      Organising the group and ensuring things got done

For each criterion, award each group member, including you, marks as follows:

            3          for ‘better than most of the group in this respect’

            2          for ‘about average for this group in this respect’

            1          for ‘not as good as most of the group in this respect’

            0          for ‘no help at all in this respect’

If necessary, you can award:

            -1         for ‘a hindrance to the group in this respect’

 

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.

 

·        Assume that it was decided to follow a three-tier architecture for the system. Different groups will carry out the development of each tier. Your team is responsible for the presentation tier.

·        Your screen layout design descriptions should consist of two parts: (a) a picture depicting the various user interface elements that make up the screen, (b) some text explaining the role of each user interface element. Note that the text should not be excessive (no more than a page).

·        You can use the documentation of the java.awt package as your source of reference for available user interface elements. Note that if you use element appearing in the java.awt package, then you don’t have to explain how they work. 

·        For all the above deliverables assume the following class diagram. Note that you are allowed to make additions to the diagram below, but any addition should be justified.

 

 

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.