Design Choices Document

You must also provide a file documenting your major design choices and the reasons for those choices. Most candidates write this file in ASCII format. However, you can submit a Microsoft Word file with UML diagrams, which the evaluator will appreciate. The two most important topics you must include are whether you chose Remote Method Invocation (RMI) versus serialized objects over TCP socket connections and whether you modified or subclassed the supplied Data class. Chapter 1, "Certification Steps and Submission Grading," discussed additional topics you could include, although none of them are required. I recommend carefully reading the section of your instructions that explains how the assignment is graded. The point items listed in that section are the key factors evaluators will be looking for. Why not make it easy for them to give you full credit by explaining what you did?

The following example of a design choices document gives you a good idea of what to write in yours and what style to use as you explain your thinking. To maintain Sun's confidentiality requirement, you need to adapt the DESIGN_DECISIONS.TXT file shown here, as you will have to do with all examples in this book. I follow this philosophy throughout the book, but it gets tricky when I show you code in later chapters. We should be able to share a lot of information as we help each other. Isn't that what Sun and third-party SCJP mock exams dogive away details about the exams? It is a horse race. If Sun doesn't keep changing the exams, the mock exam folks get so close to the real exam that the certification's value diminishes. Conversely, if we aren't told what is on the exam, too few developers take and pass the exam, and the certification's value never increases .

Most of the items discussed in your design decisions document apply to a variety of applications. The evaluator wants to know whether you understand why you designed your solution the way you did.

Super Bowl Reservation System Table of Contents

1. Design Decisions

   1.1 Design Decisions Summary

   1.2 Modifying Versus Extending the Supplied Classes

   1.3 Separate LockManager Class

   1.4 RMI Versus Sockets Communication

   1.5 Implements All Public Methods of the Database Class

   1.6 Search Function

   1.7 Single Interface for Both Remote and Local Network Modes

   1.8 User Interface Designed for Ease of Use

   1.9 Coding Standards and Readability

   1.10 Clarity and Maintainability

   1.11 Documentation

   1.12 Exception Handling and Error Testing

2. Design Patterns Used

   2.1 Client Tier

   2.1.1 Model-View-Controller Pattern

   2.1.2 Business Delegate Pattern

   2.1.3 Value Objects Pattern

   2.1.4 Connection Factory Pattern

   2.2 Server Tier

   2.2.1 Data Access Objects Pattern

   2.2.2 Decorator Pattern

1 Design Decisions

1.1 Design Decisions Summary

• Chose RMI over serialized objects instead of sockets.

• Extended the supplied class instead of modifying it.

• Didn't modify method signatures in supplied classes; rather, I overrode them in a subclass.

• Subclassed the supplied class to Database, whose name is better for its responsibilities.

• Implemented on-the-fly local database switching.

• Relied on RMI distributed garbage collection for releasing stale locks.

• Used Factory, MVC, and Adapter patterns.

• Implemented single DatabaseInterface for both local and remote database operations.

• Implemented separate LockManager class.

• Provided online help.

The following is an architecture snapshot of the Super Bowl Reservation system:

• Supplied classes Unchanged from the original download.

• DatabaseInterface Defines all public methods used in the Database class.

• DatabaseRemote This is the same as Database, except it uses a LockManager for multiuser operation.

1.2 Modifying Versus Extending the Data Class

I created a new subclass of Data called Database. I extended the Data class to maintain legacy compatibility with the Data class, to cleanly separate the new functionality and the changes from the original Data class, and to use a new name that seems more descriptive of the class responsibilities. The Database class, which is a subclass of Data, is responsible for being a more complete database, providing access to a single local database file, and comprising reading, writing, and searching facilities. Two methods in Data use deprecated code, which might be required for legacy applications, but are overridden in the Database subclass.

1.3 Separate LockManager Class

I implemented a separate LockManager class that allows Insert Row Locking (IRL) so that if two clients attempt to perform the sequence lock-read/modify/write-unlock concurrently, both modification attempts will be handled correctly. The LockManager class provides consistent and concurrent access to data in a multiuser environment (RMI). Because IRL is necessary only in remote mode, not in local mode, it makes better sense to implement it as a separate LockManager class. Locks prevent simultaneous updates of the same row of data. With a separate lock manager, only one user at a time can update a row of data. So while one user is reserving a seat for a given game, another user can't do the same thing. Without a good lock manager, users could overwrite each other's seat reservations , giving the impression that someone can sell the same seat to more than one person.

The row is locked by a given client ID. The adapter for Database (DatabaseRemote) has a one-to-one relationship with a single client, so the client ID is the reference to DatabaseRemote. In the LockManager class, the client ID is referred to with a WeakReference. That way, should another client try to lock a record previously locked by a client who has died, the LockManager removes the lock because the garbage collector will have nullified that reference. The responsibility for record locking is kept in the LockManager, and the responsibility for references to dead objects stays with the JVM, a clean separation of responsibilities.

DatabaseRemote is a wrapper around Database that implements the same interface (DatabaseInterface), but changes Database's local, single-user semantics into networked, multiuser semantics by implementing locking with the help of a LockManager class.

1.4 RMI Versus Sockets Communication

In the remote connection mode, I use a proxy pattern to design the socket connection. The DatabaseRemote_Stub class is the proxy for the client side. I chose RMI over sockets communication for the following reasons:

• Thread safety is built into RMI, whereas in sockets, multithreading issues need to be addressed.

• Sockets need a communication protocol that has to be custom defined, but RMI has RMP built in.

• RMI presents a simpler programming model over sockets.

• RMI supports dynamic class loading.

• RMI gives more scope for scalability. New objects can easily be introduced without requiring changes to the communication protocol.

• The socket technology is the foundation on which RMI is built, but RMI is more mature and using it is much simpler.

• RMI is a better standard, so it would be easy for other developers to understand the design for future development.

• Because remote objects appear local, method calls are completely type-safe.

• The Registry acts as a central lookup for finding various remote objects.

1.5 DatabaseRemote Implements All Public Methods of the Data Class

I chose to use one interface, DatabaseInterface, for both the local Database class and the remote DatabaseRemote class. This design is cleaner and reduces the chance of errors.

1.6 Search Function

The search method is abstracted so that it can return a DataInfo object containing all rows that have at least one value matching one criteria value. The column names and values are dynamic, so this method processes any number of criteria for any table, not just the one that came in the download. This is the algorithm used:

1. Parse the criteria string with StringTokenizer.

2. Get a new row of data from database.

3. Find the column that matches the criteria field name.

4. Test for a match between row value and search value.

5. If the values match, save the row of data and start at step 2 again for the next row.

6. If there's no match for the current criteria, go to the next criteria and start at step 3.

7. When the criteria are exhausted, start at step 2 again for the next row.

The search method uses java.util.StringTokenizer to parse the search criteria. This class breaks Strings into chunks at the delimiters. The requirements made the search criteria String simple, so I stayed with the StringTokenizer. I would have chosen the regular expression route if the input search String had been more complicated.

1.7 Single Interface for Both Remote and Local Network Modes

Because both Database and the DatabaseRemote adapter implement the same interface, DatabaseInterface, the client doesn't know whether the database is local or remote. The client has no local or remote specific code; it is all coded to the DatabaseInterface type, which defines one set of public methods for Database, the base class.

1.8 User Interface Designed for Ease of Use

The user interface is designed for ease of use following good Human/Computer Interaction (HCI) principles. For example, the user simply clicks on Games to select one for reservation. Also, the search feature is easy, with drop-down combo boxes to select stadium seats to search. It accomplishes this with Swing components , especially the JTable. It also uses menu bars, buttons , and tool tips set in a JSplitPane for a user-friendly window look and feel. There are other helpful features, such as table sorting. The user can sort the entire table by clicking on any column heading. The main interface uses the BorderLayout, with the status bar and connection bar in the south part. The left side of the main JSplitPane is another JSplitPane, which includes a reservation area in the upper part and a search panel in the lower part. The right side of the main JSplitPane is the main data output section of the user interface, which is the JTable. The BorderLayout is the main layout manager because it makes it easy to position components proportionately and it handles window resizes.

1.9 Coding Standards and Readability

Industry coding standards were followed to enhance code readability and reuse. I used conventional coding style, except that opening braces fall under the first letter of the declaration (also known as "West Coast style"). I packaged classes so that similar classes went into the same package. I used three packages: myPackage.database, myPackage.client, and myPackage.server.

1.10 Clarity and Maintainability

The application was designed for clarity and maintainability. For example, comments are thorough, but obvious code is not commented. Another example is the search method, designed so that it can be used on any table without code modification. Last, the command-line parser makes it very clear what the parameters are, so the user is less likely to get confused or make a mistake.

1.11 Documentation

The application is submitted with full documentation. The user can access a helpful Web page via the GUI. Because standard formatting conventions are used, the user can learn how to best use the application to reserve Super Bowl seats. For the evaluator, all source code has been documented thoroughly, and javadoc was used to generate a complete set of source documentation.

1.12 Exception Handling and Error Testing

The application has strong exception handling. For example, if a client locks a record in remote mode and then crashes, the application accurately releases the lock when the next lock is attempted on the same record. Also, the client is designed to reduce the possibility of user errors. For example, the user cannot type the Super Bowl number; he just clicks the Super Bowl row in the table instead. The user clicks the Super Bowl origin or destination to search for Super Bowls, so he cannot mistype it. Last, the user can type only the number of seats he wants. If the number is higher than the number of seats available, or the seats available equals zero, or the user doesn't type a number ( accidentally types a letter, for example), the application kindly displays a message to the user describing the error, but no harm is done.

For most exceptions, the application cascades them up into a user-friendly message. In the remote connection mode, all exceptions happen in the server-side cascade, all the way to the ClientWindow object, so that the end user is shown the correct response or error message about the operation.

2 Design Patterns Used

The following are the design patterns used in the solution along with a specific explanation of how they were implemented.

2.1 Client Tier

2.1.1 Model-View-Controller Pattern

The following describes how the MVC pattern was used in this application:

• Model SuperBowlTableModel, which extends AbstractTableModel.

• View Swing GUI, including menus , buttons, combo boxes, and a JTable.

• Controller Event methods and JTable-triggered code.

The JTable is set up to allow only row selection. Cell editing is forbidden to avoid confusion. Tool tips and a status bar keep the user informed.

2.1.2 Business Delegate Pattern

I used a Business Delegate pattern to reduce coupling between the presentation-tier client and the business service (remote database). This pattern hides the underlying implementation details of the business service, such as lookups, reads, and writes of data to the database. The Business Delegate acts as a client-side business abstraction; it provides an abstraction for, and therefore hides, the implementation of the business services.

2.1.3 Value Objects Pattern

The Value Objects pattern is used in this application to transfer data between business objects and clients across tiers. The actual value object is an object representing a row, or rows, of data from the database.

2.1.4 Connection Factory Pattern

The Factory pattern uses one class object (the factory) that returns references to objects of another class. This way, the factory class encapsulates management of the resource connection objects, allowing caching, object recycling, and other types of optimizations. Additionally, the Factory pattern separates the container's implementation from the Enterprise JavaBean (EJB) code, allowing the maximum degree of extensibility and scalability. These are the two parts of a factory pattern:

• Factory DatabaseFactory

• Object Database

2.2 Server Tier

2.2.1 Data Access Objects Pattern

I used a Data Access Object (DAO) pattern to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. The DAO (Database) implements the access mechanism required to work with the data source. The data source is a persistent store (database.bin). The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source. When using the DAO, keep in mind the following patterns and which objects they represent:

• Business Object GUI

• Data Access Object Database

• Value Object The classes representing database data

• Data Source database.bin

2.2.2 Decorator Pattern

The Decorator pattern was used for the DatabaseRemote class, which decorates Database. The intent is to attach a responsibility to an object at runtime. Decorator is a flexible alternative to extending a class. Sometimes you want to add a responsibility to an object A, not its whole class. In this project, DatabaseRemote wraps Database and adds the responsibility of Insert Row Locking via a LockManager. The decorator (DatabaseRemote) implements Database's interface (DatabaseInterface). Database's clients can then interact with DatabaseRemote instead of Database.