APersonal Bus Timetable System: Design Document Version 2.0 XYZZY Software April 2016   Revision History Version Date Author Comments 1.0 12/03/16 D. Jarvis Initial draft: Phase 1 2.0 01/04/16 D. Jarvis Initial draft: Phase 2 If any corrections / clarifications are required to this document, please email [email protected]   Table of Contents Revision History 2 1. Introduction 4 2. Requirements 5 3. Architecture 7 4. Database / Data Access Design 8 5. GUI Design 10 6. Class Diagram 13 7. Sequence Diagrams 15 8. Test Plan 16 Acknowledgements 17   1. Introduction XYZZY Software has been approached to develop a personal bus timetable system. The Phase 1 system has been developed and stakeholder feedback has been solicited. This document reflects the current state of the design for the Phase 2 system.   2. Requirements Because of the simplicity of the functional requirements, the corresponding use cases are not duplicated here, as would be the case in a normal XYZZY design document. The purpose of the system is to assist the customer in bus travel to and from work by providing him with information about scheduled services. In this regard note that for the Phase 1 system • Only a single route (411) is modelled • Destinations are designated as "city" and "home" • Only the Monday to Friday schedule is of interest • Within the database, times are stored as minutes from midnight. However, the user specifies times in terms of hours and minutes A Java desktop application is to be developed, driven by a simple Swing GUI. Interaction between the database and the application is to be via JDBC. The NetBeans IDE is to be used for development. Java DB must be used as the database. The Phase 1 user requirements were: 1. Start the application and connect to the database. If a connection cannot be established, the application is to exit. 2. Close the database connection and stop the application. 3. Display all services 4. Display all services for a particular route and destination that are within a specified range. 5. Display the number of express services operating daily for a particular route and destination. 6. Add a new service 7. Remove an existing service For Phase 2, the customer has requested that 1. A second route (66) is to be modelled, as he is now working 2 days per week at a site serviced by this route. This will necessitate the renaming of destinations to "inbound" and outbound". 2. Records returned from all queries be browsable through the use of previous and next buttons 3. Requirement 5 be modified to return all records for express services operating daily for a particular route and destination 4. The system provides a connection capability – if a route, destination and time are specified, the application will find the first service after the designated time and all connecting services with a pickup time of later than the pickup time of the first service. In addition, it has been decided that the architecture of the application is to be revised to conform to the MVP (Model View Presenter) pattern. The revised requirements are as follows: 1. Start the application and connect to the database. If a connection cannot be established, the application is to exit. 2. Close the database connection and stop the application. 3. Browse all services 4. Browse all services for a particular route and destination that are within a specified range. 5. Browse all express services operating daily for a particular route and destination. 6. Find the first service for a designated route and destination that has a pickup later than a specified time and browse it and its connecting services. 7. Add a new service 8. Remove an existing service 9. Refactor the application to conform to MVP. The database design and sample data are provided in Section 4. 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.   3. Architecture A three-layered architecture is to be employed, consisting of view, presenter 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  4. Database / Data Access Design The SQL script that is to be used to create the database's TIMETABLE table is given below. DROP TABLE TIMETABLE; CREATE TABLE TIMETABLE ( ID INT NOT NULL GENERATED ALWAYS AS IDENTITY, ROUTE VARCHAR (8) NOT NULL, DESTINATION VARCHAR (16) NOT NULL, PICKUP INT NOT NULL, EXPRESS BOOLEAN NOT NULL ); INSERT INTO TIMETABLE (ROUTE,DESTINATION,PICKUP,EXPRESS) VALUES ('411','inbound',8*60,TRUE), ('411','inbound',8*60+20,FALSE), ('411','inbound',8*60+40,FALSE), ('411','inbound',9*60,TRUE), ('411','outbound',17*60,TRUE), ('411','outbound',17*60+20,FALSE), ('411','outbound',17*60+40,FALSE), ('411','outbound',18*60,TRUE); ('66','inbound',8*60+10,TRUE), ('66','inbound',8*60+30,FALSE), ('66','inbound',8*60+50,FALSE), ('66','inbound',9*60+10,TRUE), ('66','outbound',17*60+10,TRUE), ('66','outbound',17*60+30,FALSE), ('66','outbound',17*60+50,FALSE), ('66','outbound',18*60+10,TRUE); As there is only one table, an ERD is not provided. Data access will be via JDBC using prepared statements. Java DB must be used as the database. Normally, in an XYZZY design document, we would specify the queries in this section and relate them to the methods exposed by the TimetableQueries class described in Section 6. However, for this project, we have decided to leave query formulation to the implementers.   5. GUI Design Developers are free to use the NetBeans GUI Builder or alternatively, they can hand code the complete GUI. An indicative GUI is presented in Figure 2 and Table 1. Developers are free to use this design as is or to do things differently, for example using menus for data entry. Note that because of the simplicity of the GUI in Figure 2, screen shots for the realisation of each requirement are not shown as would normally occur in an XYZZY design document. Rather, the required actions are summarised in Table 2. Figure 2. Indicative GUI   Functionality Swing Components Output JTextArea Input JLabel, JTextField, jCheckBox Operations JButton Table 1. Mapping of GUI functionality to Swing component types. Requirement Button Inputs Required 1 n/a n/a 2 Exit None 3 All Services None 4 All Services for Destination within Time Range Route, Destination, Time Range. See below for further details re time range specification. 5 Express Services for Destination Route, Destination 6 Connecting Services Route, Destination, Time Range (lower value only) 7 Insert Service Route, Destination, Pick Up (both fields), Express 8 Delete Service Route, Destination, Pick Up 9 n/a n/a Table 2. Mapping of requirements to actions Note that in Figure 2, input fields double up as output fields when browsing, as in the AddressBook case study. The TextArea is used for the display of messages. For Requirement 4, note that clicking of the corresponding button will result in the invocation of a single method, as in Phase 1. For Requirement 5, only the lower value needs to be provided - the upper value can be set to 24:0 and the first record from the query result used to find connecting services. The rules for time range specification are as follows: 1. All fields empty is an error 2. Both fields empty for time 1 is an error 3. If 1 and 2 do not apply, then a. Any empty field is treated as 0 b. If time 2 is 0:0, it treated as 24:0 c. time 2 < time 1 is an error When browsing, • when the end of the list is reached, next is to display the first record • when the start of the list is reached, previous is to display the final record   6. Class Diagram The class diagram for the application is illustrated in Figure 3. Figure 3. Class diagram IModel is defined as follows: public interface IModel { public void getServices(); public void getServices( String r, String d ); public void getServices( String r, String d, int t1, int t2 ); public void getConnectingServices( String r, String d, int t ); public void close(); public void next(); public void previous(); public Result current(); // did the last query succeed? public boolean queryStatus(); } A definition of IView is not provided – use AddressBookMVP as a guide. The mapping to packages/layers is provided in Section 3. Note that Figure 3 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 Timetable class. Also note that interaction between the TimetableQueries 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 felt that method signatures as employed in NetBeans are clearer than their UML counterparts. In this regard, note that if a return type for a method is not specified, void is assumed.  7. Sequence Diagrams Omitted   8. 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 Handles incomplete field entry 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 A destination of outbound is flagged as having no connecting services 6 Handles incomplete field entry 7 Operation performs correctly given correct preconditions No data validation checks required. 7 Handles incomplete field entry 8 Operation performs correctly given correct preconditions No data validation checks required. 8 Handles incomplete field entry Browsing Previous and next buttons cycle Table 3. Acceptance tests Note: 1. By preconditions, we mean that the required values are available. 2. Acceptance tests coincide with class unit tests, so no separate unit testing is required. 3. Testing will be conducted with the database specified in Section 4. Acknowledgements The UML diagrams were created using Violet ( http://horstmann.com/violet/ )