This page is the starting point into a series of pages that attempt to give a complete example of object-oriented analysis, design, and programming applied to a moderate size problem: the simulation of an Automated Teller Machine. I developed these pages in the belief that students would benefit from seeing a complete example of OO methodology applied to a single problem.
Beginning with a statement of requirements, the process proceeds through analysis, overall design, and detailed design and implementation. (Testing is left as an exercise to the reader :-) .)
Analysis is done by identifying the use cases and detailing a flow of events for each. The next step is identifying the analysis classes (representing boundary, controller, and entity objects) that are suggested by the use cases. Finally, Statechart Diagrams are created for the major controller classes.
Overall design is done by using CRC cards to assign responsibilities to the various objects, leading to the development of an Interaction Diagram for the main use cases. The design is summarized by means of an overall Class Diagram.
The detailed design is developed by spelling out the attributes and methods for each class, using a class diagram for each class with all three "compartments" fully filled in. These are then implemented in Java. The code page contains links both to Javadoc documentation for each class, and to the complete source code. Also included are a main class, which allows the simulation to run as an application, and an Applet class, which allows it to be run as an Applet. (This illustrates how the same basic code can be designed to be used either way.) The application was used for most of the initial development work. The Applet version can be loaded and executed from within any web browser that supports at least JDK 1.1.x.
I originally developed this series of pages for use in a course which was taught to junior CS majors at Gordon College from 1996 to 1999, using C++. The present version is a major revision (done during 2000 and 2001) for use in "Object-Oriented Software Development") which is taught to sophmore CS majors and uses Java. The most signficant change in this version is the use of UML notation throughout, together with a reorganization of the process to more closely follow the UML approach. The original version was implemented in both C++ and Java; this version uses only Java, so as to be able to utilize some features of that language (e.g. threads) which have no direct analog in the C++ language per se.
The original version followed the design methodology taught in the textbook I used in the earlier course - [Horstmann, 1997], and some aspects of that approach remain. (That version is available here - from which you can follow a link to an even older version if you wish.) For this version, I have used a simplified version of the process outlined in [Jacobson, Booch, and Rumbaugh, 1999].
It may be argued that more diagrams have been used than are really necessary for a project of this size. I wanted to give as complete an example of using the various UML diagrams as possible. Even so, this example does not include any activity, component, or deployment diagrams.
Probably the best way to start using these pages is to begin with the analysis phase and work through the entire analysis, design, and implementation process. Begin with the Statement of Requirements and then view the Use Cases. The Use Case document has a Use Case Diagram and a series of flows of events, one for each use case. The analysis phase can be studied both in terms of the "big picture" and in terms of the details of the use cases.
Having looked at these requirements/analysis documents, you can then move to the design phase by viewing the CRC cards, the Interaction Diagrams, and the overall Class Diagram.
In terms of the order in which these would be created, the CRC cards would be done first, then the Interaction Diagrams, and then the Class Diagram. Thus, to understand the design process, these should be read in the order they were created. However, in terms of understanding the design itself, it may be desirable to read them in the exact reverse order.
The detailed design and implementation were developed from the CRC cards, Interaction Diagrams, and Class Diagram. The detailed design document was developed directly from the Interaction diagrams and Class Diagram. The former determined what methods the class would need, and both the former and the latter determined what attributes were needed. The skeletons for the various classes were created directly from the detailed design, and the the individual method bodies were fleshed out by using the Interaction diagrams. Each message on the Interaction diagram becomes a line or so of code in the implementation.
Although this web site shows a finished product in which the various design documents and the code are in agreement, the reality is that the coding process demonstrated the need for slight changes to the various design documents, so in some cases the design documents were modified to conform to the code, rather than vice versa. (However, the bulk of the design did exist before the code was written! The idea is to use the design documents to guide coding, not to produce design documents after the fact!)
Under the Testing heading, the there is a link to an executable (applet) form of the Java implementation, which you can run if you have a JDK 1.1.x (or later) compliant browser. Enjoy!
Finally, under the Maintenance heading, there is a link to a page of suggested changes. One such change deals with implementing a stated requirement that is missing from the design and implementation presented here. (This would never happen in real life, of course :-) ) Can you find the missed requirement? Other changes have to do with adding additional features to the system. These make interesting exercises for the reader.
Though the pages are copyrighted, I hereby freely give permission for their reproduction for non commercial educational purposes. I hope they will prove useful to other faculty who are starting - as I am - to teach OO methods. I would also really welcome suggestions and feedback - either about the design itself or the way it is presented. Input from UML guru's would especially be appreciated, as I am revising these pages in part as a way to learn UML myself!
Russell C. Bjork
Professor of Computer Science
Gordon College
255 Grapevine Road
Wenham, MA 01984
(978) 927-2300 x 4377
bjork@gordon.edu
Page of links for non frames-enabled browsers.
