Hi there,
I can't say for sure why I lost marks on design considerations, though I have some suspicions. I'll mention them below but, first, the package descriptions:
Package: com.flybynight.applications.flightres
Description: The root package of the FBN application.
Package: com.flybynight.applications.flightres.application
Description: Contains classes used to model application state.
Package: com.flybynight.applications.flightres.domain
Description: Contains classes used to model the FBN reservation environment.
Package: com.flybynight.applications.flightres.domain.catalog
Description: Contains classes used to model the flight catalog.
Package: com.flybynight.applications.flightres.domain.reservation
Description: Contains classes used to model a flight reservation.
Package: com.flybynight.applications.flightres.presentation.swing
Description: Contains main JFrame and associated classes.
Package: com.flybynight.applications.flightres.presentation.swing.connection
Description: Contains JOptionPane and associated classes for gathering connection information from the travel agent.
Package: com.flybynight.applications.flightres.presentation.swing.reservation
Description: Contains JOptionPane and associated classes for verifying and reserving seats on a selected flight.
Package: com.flybynight.applications.flightres.presentation.swing.route
Description: Contains JTable and associated classes for rendering the flight reservation table.
Package: suncertify.db
Description: Core flight database classes.
Package: suncertify.db.connection
Description: Contains classes used to establish local and remote connections to the database. Also contains server classes.
Package: suncertify.db.lock
Description: Contains classes used in implementing the Lock Manager.
Package: suncertify.db.search
Description: Contains classes used to implement the search functionality.
Package: suncertify.db.search.strategy
Description: Contains the various search strategy classes.
Here's the writeup I provided in the README.txt document about the package layout:
Application Design:Layered Package Architecture
In this application I chose to architect my code after the
Layers design pattern discussed in Craig Larman's book, 'Applying
UML and Patterns (Second Edition.)' According to this pattern,
the components of a given software application are arranged into
a number of layers, each of which establish a behavioural
boundary of a system by implementing a functionally-related set of
system operations.
This design pattern offers many advantages to the application
developer:
1. Code is highly localized and encapsulated. This allows for easy
testing, transaction control, and modification of the codebase.
2. Code is highly reusable since the presentation layer is
decoupled from the application layer, the application layer is
decoupled from the domain layer, etc.
3. Code is highly extensible and pluggable. Since layers establish
the behavioural boundaries of an application, entire layers (or
the components therein) can be swapped, extended, modified, and
replaced with only a minimal number of changes being entailed in
the adjacent layers.
Following Larman, I chose to incoroporate the following layers in
my application:
1. Presentation Layer. This layer contains code needed to
render an application's graphical user interface of the
client application. In this instance, the presentation layer
contains the Java classes needed to render the Swing-based
GUI that travel agents use to search the flight catalog and make
seat reservations. It interacts with the controller class of the
application layer in order to send and retrieve information
information and various command requests too and from the
domain and service layers.
2. Application Layer. This layer contains code needed to manage
the use case scenarios of an application. In this application,
the application layer consists of a single class that acts as
a gateway of sorts between the presentation and domain layers.
Information and business requests are sent on behalf of the
presentation layer to the domain layer, and data is returned
back. The controller class of this application is simple enough
that it does not maintain use case state. As the application
grows and the interface becomes more complex, however, use-case
based behavioural logic can be decoupled from the presentation
layer and moved into the application layer.
3. Domain/Business Layer. This layer contains code needed to
represent the domain model of an application. In this
application, the domain layer is not distinguished from the
business layer because not enough information is known about
Fly-By-Night to accurately distinguish between classes that
model entities specific to this application, and classes that
model entities common to the business. As such, the classes of
this layer model domain and business entities using information
pulled from the connection classes of the services layer.
4. Services Layer. This layer contains code needed to access
the various services used by an application. In this application,
the services layer contains classes needed to connect to local
and remote datasources as well as manage concurrent access to
records in the datasources. The services layer also contains
classes responsible for the persistence of information.
By choosing to incorporate a layered architecture in this application,
I was able to design a robust and maintainable application. I did
incur the following overhead, however:
1. In order to decouple access between adjacent layers, I had to
program a number of Controller classes (i.e. ApplicationController,
DomainController, and ConnectionController) to mediate communication
between the layers.
2. More generally, in order to manage the indirect interaction
between classes in the presentation layer and classes in the
services layer, I had to design a pipline architecture in which
requests initiatiated in the presentation layer, are pipelined
to classes in the services layer via classes in the application
and domain layers. This introduced a lot of overhead in the
development of this application and required data to be tranformed
in a step-wise fashion throughout the pipeline.
3. Since various responsibilities are distributed to various classes
throughout the pipeline, I had to sit down and plan how transactions
were going to be managed, state was going to be maintained, and
objects were going to be distributed.
As for the difference between "domain/reservation" and "swing/reservation", the former contains classes that model the Flight Reservation business concept, whereas the latter contains classes that render a JOptionPane used to book a flight reservation.
I think there are 3 or 4 places where I might have lost points:
1. I didn't like my exception handling strategy. As mentioned in a previous post, I am new to Java and object-oriented programming in general, so I wasn't sure how to implement an effective exception handling strategy. I had decided early on to throw fine-grained exception classes at the lower levels and then wrap them in more general exception classes as it traversed its way up the stack. Because I have a large number of classes in my application, however, this really became tedious so I only half-heartedly followed through with my strategy.
2. I think I could have done without the application package. In bigger projects it would contain a number of controllers to manage the state of the application through time. But in this application, I only had one controller class which did nothing more than pipeline information too and from the presentation and domain layers.
3. It's possible that regex/hashmap based search strategies weren't appreciated :-) I thought my search strategy was pretty kewl but I felt myself in implementing it that regular expressions didn't form a comfortable fit with Java. But then again, I think it's just becuse I haven't worked with object-oriented regular expressions long enough to feel comfortable with them. In any event, perhaps my search strategy lost me some points.
4. I kept track of user preferences with the 'java.util.prefs' package. I don't know if it was a good or bad choice but I haven't read a lot of discussion about this package on SCJD so perhaps it was inappropriate to use it in this assignment.
And as for marks lost on documentation, I think I would have salvaged a few of them if I had submitted UML diagrams. I had a lot of classes and they would have helped. I was so tired at the end, though, I just decided to take the loss.
Thats about it for me.
Cheers,
Darryl
