Software is contracted to develop a

Airline Booking System Phase 2: Design Document

Version 1.0
XYZZY Software
March, 2018
Version
Date
Author
Comments
1.0
03/03/18
D. Jarvis
Initial draft
Revision History 2
1. Introduction 4
2. Requirements 5
3. Architecture 6
4. Database / Data Access Design 7
5. GUI Design 8
6. Class Diagram 12
7. Sequence Diagrams 14
8. Test Plan 15
Acknowledgements 16
Introduction
XYZZY Software is contracted to develop a reservation system for a very small and exclusive airline. The system is to be developed using Java Technologies (NetBeans, Java DB) and a phased implementation strategy will be adopted. This document represents the current state of the design for the Phase 2 system.
Requirements
Because of the simplicity of the functional requirements, the corresponding use cases are not duplicated here.
The purpose of the system is to assist staff in the management of reservations. In this regard, note that the airline is unusual in that it only operates two flights per day – one from Canberra to Melbourne and the other from Melbourne to Canberra. Because of the quality of the in-flight dining, business is thriving and in order to retain its exclusivity, the owners have no immediate intention of adding more flights or destinations. The reservation system is to be implemented as a Java desktop application that employs a simple Swing GUI and Java DB database. Interaction between the database and the application is to be via JDBC. The NetBeans IDE is to be used for development.
The functional requirements for the Phase 1 system were as follows:
Start the application and connect to the database
Close the database connection and stop the application
Display all reservations
Display all reservations for which the number of passengers is within a specified range
Display the total number of passengers who have booked for a particular flight
Add a reservation to the database if sufficient seating is available
and the application was to conform to the MVP (Model View Presenter).
In Phase 2, the following additional functional requirements are added:
Clear all fields in the GUI
For commands that return reservation records (ie requirements 3 and 4) the records are to be browsable via previous and next buttons, as detailed in Section 5.
Furthermore, the display of browsable records is to be realised using the MVC (Model View Controller) pattern. Any output associated with requirements 5 and 6 will be initiated by the controller (using the MVP pattern) and not by the model. Refer to the class diagram of Figure 6 for clarification. Note that “presenter” functionality is provided by the ReservationsController class. Your application must conform to Figure 6, although you are free to add additional private members and methods.
The database design and sample data are provided in Section 4. Note that dates are represented (both in the database and in the application) as text strings. Data validation is not required at this stage. However, basic preconditions must be satisfied for each requirement and if these are not satisfied, an appropriate message is to be displayed. These preconditions are specified in Section 8.
Architecture
A three-layered architecture will be employed in Phase 2, consisting of view, controller and model layers. Given the simplicity of the architecture, an architecture diagram is not provided.
Layers are to be modelled as packages – the package structure for the application is illustrated in Figure 1.
Figure 1. Package structure
Database / Data Access Design
Flight capacity (20 passengers) is to be hardcoded into the ReservationQueries class. The remaining model data is to be stored in a JavaDB database. The SQL script that is to be used to create the database’s RESERVATIONS table is given below.
DROP TABLE RESERVATIONS;
CREATE TABLE RESERVATIONS
(
ID INT NOT NULL GENERATED ALWAYS AS IDENTITY,
LASTNAME VARCHAR (30) NOT NULL,
PHONE VARCHAR (10) NOT NULL,
PASSENGERS INT NOT NULL,
DESTINATION VARCHAR(20) NOT NULL,
DATEOFFLIGHT VARCHAR (10) NOT NULL
);
INSERT INTO RESERVATIONS (LASTNAME,PHONE,PASSENGERS,DESTINATION, DATEOFFLIGHT)
VALUES (‘Turnbull’,’123456′,7,’Melbourne’,’01-03-18′),
(‘Abbott’,’234567′,2,’Melbourne’,’01-03-18′),
(‘Gillard’,’345678′,3,’Canberra’,’01-03-18′),
(‘Rudd’,’456789′,3,’Canberra’,’01-03-18′);
As there is only one table, an ERD is not provided.
Data access will be via JDBC using prepared statements. Normally, in an XYZZY design document, we would specify the queries in this section and relate them to the methods exposed by the ReservationsQueries class. However, for this project, we have decided to leave query formulation to the implementers.
GUI Design
Developers are free to use the GUI Builder or alternatively, they can hand code the complete GUI. The GUI design and its usage is presented in Figures 2-5 and Table 1. Note that because of the simplicity of the GUI in Figure 2, screen shots for the realisation of every requirement are not shown. However, the required inputs are summarised in Table 2.
Figure 2. Indicative GUI
Functionality
Swing Components
Output
JTextArea
Input
JLabel, JTextField
Operations
JButton
Table 1. Mapping of GUI functionality to Swing component types.
Requirement
Button
Inputs Required
2
Exit
None
3
All Reservations
None
4
Total Passengers on Flight
Destination and Date
5
Reservations by Size
Number of passengers – see below
6
Book
All, except for second Passenger s input
7
Clear
None
8
Previous, Next
Buttons are to be enabled only when one or more records have been generated for browsing.
Table 2. Mapping of requirements to actions
All output (except for reservation records, which are displayed in the input fields and stack traces, which are displayed on System.err) is to be displayed in the messages area, as shown in Figures 3 and 4:
Figure 3. Screen after All Reservations is clicked.
Figure 4. GUI after Reservations By Size is clicked, but no data entered.
Figure 5. GUI after Reservations By Size is clicked, but with a size range that generates no records.
Note that in Figures 4 and 5, the Previous and Next buttons are disabled.
For Requirement 4, note that clicking of the button will result in the invocation of a single method (ReservationsQueries.getReservationsBySize()), that takes two parameters. If two numbers are specified as input, then they are to be treated as the lower bound (left) and upper bound (right) of an inclusive range. Having the upper bound less than the lower bound is to be treated as an error. Having both numbers the same is not an error – they are the endpoints of a range of length zero. If one number is specified, then if it is the right input, then the left input is set to 0. If the left input is specified, then the right input is set to the value of the left input.
For Requirement 8, browsing is to be cyclical – clicking Next on the last record will display the first record and clicking previous on the first record will display the last record.
Class Diagram
The class diagram for the application is illustrated in Figure 6.
Figure 6. Class diagram
Note the following:
Data validation and any associated type conversion is to be performed in ReservationsView
GUI startup (setVisible() invocation) is to be performed in Reservations.main().
ReservationsBrowsingModel will need to catch exceptions thrown by the IQueries methods. However, in the catch blocks, just print a stack trace (to System.err) and exit the application. Note that the ReservationsQueries constructor also throws an exception that will need to be caught and handled in similar way, but this time in Reservations.main().
There is only one main() method – in Reservations.
Both ReservationsController and ReservationsBrowsingModel have an attribute called queries of type IQueries. This is a reference to the same object, which will be created in Reservations.main()
The mapping to packages/layers is provided in Section 3. Note that Figure 6 represents a refactoring of the class structure favoured by the NetBeans GUI Builder. Rather than having GUI creation in the GUI class definition (through the provision of a main() method, we have chosen to place GUI creation in a separate main class. If you are using the NetBeans GUI builder, all that this means is that the main() method that the Builder generates is moved into the Reservations class. Also note that interaction between the ReservationsQueries class and the JBC library classes is not shown. This is normal for class diagrams. Finally, formal UML syntax is not strictly followed. In particular, we feel that method signatures as employed in NetBeans are clearer than their UML counterparts. In this regard, note that if no return type for a method is specified, void is assumed.
Sequence Diagrams
Omitted.
Test Plan
The following tests will be performed prior to acceptance:
Requirement
Test
Comment
1
Operation performs correctly given correct preconditions
1
Handles no database/incorrect database
Application is to exit
2
Operation performs correctly
3
Operation performs correctly
4
Operation performs correctly given correct preconditions
No data validation checks required.
4
Input variants as specified in Section 5 are handled correctly
5
Operation performs correctly given correct preconditions
No data validation checks required.
5
Handles incomplete field entry
6
Operation performs correctly given correct preconditions
No data validation checks required.
6
Handles flight overbooked
6
Handles incomplete field entry
7
Operation performs correctly
8
Browsing operates cyclically
8
Records are displayed correctly in the input/output text fields. Appropriate messages are displayed in the messages text area
8
Edge cases (eg no records generated) are handled correctly.
Table 3. Acceptance tests
Note:
By preconditions, we mean that the required values are available.
Acceptance tests coincide with class unit test, so no separate unit testing is required.
Testing will be conducted with the database specified in Section 4.
The UML diagrams were created using Violet ( http://horstmann.com/violet/ )