Hi all, I haven't posted much to the SCJD groups but I wanted to thank everyone for their postings to the site. The SCJD forum was my main resource for the project (apart from O'Reilly!) and I thank you greatly :-) Here's my breakdown: General Considerations (maximum = 58): 42 Documentation (maximum = 20): 17 GUI (maximum = 24): 24 Server (maximum = 53): 53 Here are some of my design choices: 1. Used a layered architecture ala Craig Larman. 2. Both extended and modified the Data class. Most of my code was placed in the extension class, but I did modify permissions and address the deprecated code in the original Data class. 3. Used hashmaps, regular expressions and the strategy design pattern to implement the search code. 4. Used resource bundles. 5. Implemented the search GUI as drop-down menus. 6. Chose RMI over sockets. 7. Server was console-based, not GUI. 8. Did not implement dynamic classloading or policy files. 9. Used 'java.rmi.dgc.VMID' to identify clients. 10. Implemented 'java.rmi.server.Unreferenced' to clean up dead client locks. 11. Implemented 'java.lang.Runtime.addShutdownHook (Thread)' in order to lock the database while shutting down. Cheers, Darryl
Hi, Congratulations. Please let us know what you did for the following points (and why). 1. Used a layered architecture ala Craig Larman. 3. Used hashmaps, regular expressions and the strategy design pattern to implement the search code. 4. Used resource bundles. 9. Used 'java.rmi.dgc.VMID' to identify clients.
regards
Darryl A. J. Staflund
Ranch Hand
Joined: Oct 06, 2002
Posts: 303
posted
0
> 1. Used a layered architecture ala Craig Larman. I had originally planned to follow the JCert certification track and had just passed the IBM UML course before starting the SCJD. Craig Larman's book, "Applying UML and Patterns (2nd ed.)", is a recommended read for the IBm course so I decided to apply some of its ideas in the FBN project. At the end of development, I had the following package structure: com.flybynight.applications.flightres com.flybynight.applications.flightres.application com.flybynight.applications.flightres.domain com.flybynight.applications.flightres.domain.catalog com.flybynight.applications.flightres.domain.reservation com.flybynight.applications.flightres.presentation.swing com.flybynight.applications.flightres.presentation.swing.connection com.flybynight.applications.flightres.presentation.swing.reservation com.flybynight.applications.flightres.presentation.swing.route suncertify.db suncertify.db.connection suncertify.db.lock suncertify.db.search suncertify.db.search.strategy There are a lot of packages so I won't discuss each of them in particular. If you want me to expand on them, just give me a shout and I will do so.
> 3. Used hashmaps, regular expressions and the strategy design pattern to implement the search code. I've worked with three main languages over the course of my career. In the eighties my language of course was Pascal. In the nineties it was Perl. And it seems as though in the --- ummm, zeroes (?) --- it might be Java though .NET is really very nice (please no spam -- it's just a personal opinion.) Since I am coming to Java from Perl, I wanted to see how Perl parsing and search strategies could be applied in Java -- especially given that Java 1.4 (with its regex capabilities) had just been released. So, the parsing of the search criteria string was done using regular expressions, searching the database for matching records was done by iterating over various hash collections (a common strategy in Perl), and the strategy design pattern -- well, that was another Larman influence still working its way through my system :-) 4. Used resource bundles. I found that in order to perform searches and seat reservations, I had to hard-code either the column title or the column number of the database into my code. Without this information I had no way of determining which columns to search on or modify. In order to make my code as flexible as possible, I placed this information in a resource file rather than hard-coding them as constants in my application.
9. Used 'java.rmi.dgc.VMID' to identify clients. The VMID class generates a unique ID for a given VM in a distributed environment. Given this and the fact that the Lock Manager needed to identify clients in a distributed environment, I use it to generate the identifier of these clients. Cheers, Darryl
HS Thomas
Ranch Hand
Joined: May 15, 2002
Posts: 3404
posted
0
Thanks, Darryl, that was very useful. It's nice to know what could be some alternatives. Do you know why you lost all those marks in General Considerations ? Scoring max in GUI and Server, you could have had a perfect or near-perfect score. BTW, the max in GUI and Server is almost just as good. regards
HS Thomas
Ranch Hand
Joined: May 15, 2002
Posts: 3404
posted
0
Actually, a one-line description of these would help. Also why the two reservation classes i.e. com.flybynight.applications.flightres.domain.reservation com.flybynight.applications.flightres.presentation.swing.reservation
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
Darryl A. J. Staflund
Ranch Hand
Joined: Oct 06, 2002
Posts: 303
posted
0
Oh, I forgot to answer your last question. Yes, I created both a client.jar and server.jar.
HS Thomas
Ranch Hand
Joined: May 15, 2002
Posts: 3404
posted
0
Hi Daryl, You seem to have taken a very methodical and thorough approach. Perhaps this is to do with your background with the IBM OOAD Exam. I think it'll stand you in good stead over time, with a large project. Perhaps , simplicity is a key criterion for this assignment. Sorry you lost those marks in that case. regards
P.S I am keeping a copy of this just in case I find I'd like to tackle IBM OOAD & Craig Larman. What other resources did you need to read ?
Darryl A. J. Staflund
Ranch Hand
Joined: Oct 06, 2002
Posts: 303
posted
0
Hi there, My reading list for the IBM OOAD course? Larman's book, primarily. They recommend Martin Fowler's "UML Distilled" and it did cover some test questions that Larman's book didn't, but I didn't focus too much on it. Good luck. I can't help but recommend Larman's book wholeheartedly. It was a watershed for me because it helped me make sense of how UML, OOAD, and design patterns all fit together. Cheers, Darryl
HS Thomas
Ranch Hand
Joined: May 15, 2002
Posts: 3404
posted
0
it helped me make sense of how UML, OOAD, and design patterns all fit together.
Thanks Darryl, This comment may well be the turning point for me. regards
0
