Restaurant Booking System

Phase 1: Design Document

1 | Page
 1. Introduction

XYZZY Software is contracted to develop a booking system for a very small and
exclusive restaurant. 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 1 system.

2 | Page
 2. 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 bookings. In

this regard, note that the restaurant is unusual in that its owner believes that
eating should be communal experience. As such, there is only a single large
table with seating for 20. Because of the quality of the food and the uniqueness
of the dining experience, the restaurant has become so popular that bookings
are taken only for the current week. Bookings are currently taken by phone and
written into a booking diary; the booking diary is to be replaced with a database
managed by a Java desktop application through a simple Swing GUI. Interaction
between the database and the application is to be via JDBC. The system is to be
developed using the NetBeans IDE.

The initial functional requirements are:

1. Start the application and connect to the database

2. Close the database connection and stop the application
3. Display all bookings for the current week
4. Display all bookings for a specified day
5. Display the total number of people who have booked for a particular day
6. Add a booking to the database if sufficient seating is available

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 | Page
 3. Architecture

A two-layered architecture will be employed in Phase 1, consisting of a view layer

and a model layer. Given the simplicity of the architecture, an architecture
diagram is not provided.

In Phase 2, the application will be refactored into an MVP conformant three-

layered architecture, with the introduction of a presenter layer. Layers are
modelled as packages the package structure for the application is illustrated in
Figure 1.

Figure 1. Package structure

4 | Page
 4. Database / Data Access Design

Restaurant capacity (20 diners) is to be hardcoded into the BookingQueries class.

The remaining model data is to be stored in a JavaDB database. The SQL script
that is to be used to create the databases BOOKINGS table is given below.

DROP TABLE BOOKINGS;

CREATE TABLE BOOKINGS

(
ID INT NOT NULL GENERATED ALWAYS AS IDENTITY,
LASTNAME VARCHAR (30) NOT NULL,
PHONE VARCHAR (10) NOT NULL,
DINERS INT NOT NULL,
DAYOFWEEK VARCHAR (10) NOT NULL
);
INSERT INTO BOOKINGS (LASTNAME,PHONE,DINERS,DAYOFWEEK)
VALUES ('Turnbull','123456',7,'Monday'),
('Abbott','234567',2,'Monday'),
('Shorten','345678',3,'Wednesday'),
('Rudd','456789',3,'Wednesday');

As there is only one table, an ERD is not provided.

Data access will be via JDBC using prepared statements.

5 | Page
 5. GUI Design

Developers are free to use the GUI Builder or alternatively, they can hand code
the complete GUI. An indicative GUI and its usage is presented in Figure 2 and
Table 1. Developers are free to use this design as is or to do things differently.
Note that because of the simplicity of the GUI in Figure 2, screen shots for the
realisation of each requirement are not shown. Rather, the required actions 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.

6 | Page
Requirement Button Inputs Required
2 Exit None
3 All Bookings None
4 Bookings for Day Day
5 Total Diners for Day Day
6 Book All

Table 2. Mapping of requirements to actions

7 | Page
 6. Class Diagram

The class diagram for the application is illustrated in Figure 3.

Figure 3. Class diagram

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

8 | Page
main class. If you are using the NetBeans GUI builder, all that this means is that
the main() method that the Builder generates is refactored into the Restaurant
class. Also note that interaction between the BookingQueries 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.

9 | Page