Introduction

What you will Find Here

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. Since then, I have developed a similar-style solution to an even simpler problem: maintaining a very simple address book.

Beginning with a statement of requirements, the process proceeds through analysis, overall design, and detailed design and implementation, culminating with some suggestions for maintenance. (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. Also, an initial set of functional test cases is specified, to serve as a vehicle for checking that the implementation is complete and basically correct. Analysis culminates in identifying classes implied by the use cases, and documenting them using an Analysis Class Diagram. (The Statechart diagrams done under design are also, in part, analysis tasks. In OO, the line between analysis and design is not always a sharp one.)

Overall design begins by using CRC cards to assign responsibilities to the various classes. The static structure of the design is summarized by means of an overall Class Diagram. Then the dynamic aspects of the design are developed, using State Charts for the major controller classes, plus an Interaction Diagram for each of the main use cases.

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. A package diagram is used to show how the various classes are groupled into packages. Each class is 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, but the Applet is accessible to anyone over the web).

The Executable Applet version can be loaded and executed from within any web browser that supports at least JDK 1.1.x.

The Maintenance page discusses ideas for possible changes to the system, each of which would require changes to multiple documents, not just the code.

Background

This is the second significant revision of this series of pages.

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++. (That version is available here - from which you can follow a link to an even older version if you wish.)
The second version represents 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 the second and subsequent versions is the use of UML notation throughout, together with a reorganization of the process to more closely follow the UML approach. Moreover, the original version was implemented in both C++ and Java; but subsequent versions 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. That version is available here.
I more recently (in 2002) revised the sequencing of the pages to reflect a slightly different ordering of the steps in the software development process as I am now teaching it in 2002. (The content of the current set of pages is almost exactly the same as the 2000-2001 version, but the order is different.)

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. For second and subsequent versions, 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.

Using these Pages

Probably the best way to start using these pages is to first read the requirements, and then 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.
- Before studying the flows of events in detail, it might be helpful to look at the diagram showing the Analysis classes to get an overall view of the system implicit in the use cases. The Analysis Class Diagram captures the basic class structure implied by the use case flows of events.
- Then it is time to study the flows of events in detail.
Having looked at the requirements/analysis documents, you can then study the design phase by viewing the CRC cards, the overall Class Diagram, and the Statechart and Interaction Diagrams.
- There is one CRC card for each class, incorporating all responsibilities of the class arising from all of the use cases, linked to from the icon for the class in either Class Diagram. The CRC cards were created by "walking through" each use case, assigning the responsibility for each task to some class. Note that there are CRC cards for classes that do not appear in the Analysis Class Diagram; the need for these classes became apparent as the other cards were being created. (This is typical; Booch suggests that the ratio of classes in a complete application to analysis classes may be as much as 5:1; in this particular case, it is about 2:1.)
- The Class Diagram pulls together all of the structural information from the CRC Cards and shows the needed links between classes. Each class icon is linked to other relevant design documents, including a detailed design for that class.
- For the major controller classes, there is also a Statechart diagram depicting the various states the corresponding object can be in. This, too, is accessible from the class's icon in either Class Diagram.
- Finally, there is one Interaction diagram for each use case, linked to from the use case flow of events. This shows the objects that work together to realize the use case, and the flow of messages between them. This records the same assignment of responsibilities as in the CRC cards, but in a different way (organized by use case, rather than by class), with additional detail. (These, rather than the CRC cards, were actually used when creating the detailed design. CRC cards are not actually a UML diagram, but are a useful tool to help in discovering the design that does get recorded in UML Interaction diagrams.)
In terms of the order in which these would be created, the Analysis Class Diagram and the CRC cards would be done first, then the overall Class Diagram, and finally the Statechart and Interaction Diagrams. Thus, to understand the design process, these could be read in the order they were created. However, in terms of understanding the design itself, it may be desirable to read the Class Diagram first.
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.

In terms of actually writing the code, the skeletons for the various classes were created directly from the detailed design. The individual method bodies were fleshed out by using the Statechart and Interaction diagrams. Each message on the Interaction diagram becomes a line or so of code in the implementation. The controller classes for which a statechart was done have a method that is structured as a finite state machine based on the statechart (run() in ATM; performSession() in Session; performTransaction() in Transaction.)

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 Quality Assurance heading, 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.

Downloadable Version

A downloadable version of the complete set of pages - including the Java source code in a folder called "source" is available here. Please note the copyright information below before downloading.

Author and Copyright Information

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