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 small size problem: a simple address book. These pages are similar in style to another, more complicated set of pages I developed earlier: A Simulation of an Automated Teller Machine (ATM). I developed both that set of pages and this in the belief that students would benefit from seeing a complete example of OO methodology applied to a single problem. The problem documented by this set of pages is much simpler than the ATM Example, and so is more accessible to undergraduate students seeing OO methodology and UML for the first time.

Beginning with a statement of requirements, the process proceeds through analysis, overall design, detailed design, and implementation in code.

Background

The original idea for this example came from a textbook example in the book I used for my Introduction to Programming course - An Introduction to Object-Oriented Programming with Java by C. Thomas Wu. (This particular course was replaced by a different course in a recent revision of our curriculum.) The first time I taught that course (in the spring of 2000), I turned this example into a set of labs and a project which culminated in having students develop a fairly complete GUI for the address book (which went far beyond the example in Wu's book). In subsequent years, I have improved the labs and the project, giving my students some design information in the form of various UML diagrams. More recently, I decided that working this up into a complete example of the design process, using UML, could be a valuable teaching tool in my Object-Oriented Software Development course, which many of the students who take the new version of our Introduction to Programming course take the following semester. This example also illustrates the Model-View-Controller and Observer design patterns.

In the past I used a vastly-simplified version of these pages for a project in the old Introduction to Programming course. I currently use an intentionally "broken" version of this program in a lab on Testing in the Object-Oriented Software Development course. This version of these pages is a revision that incorporates some ideas from both the project and the lab. (The previous version is available at a site for a course from our previous curriculum.)

It may be argued that more diagrams have been used than are really necessary for a project of this size. I wanted to give an example of using a variety of different UML diagrams. Even so, this example does not include any statechart, collaboration, package, activity, component, or deployment diagrams.

Note: Some of the diagrams have been deliberately omitted from the various pages. Students taking my course will no doubt come to understand the phrase "... has been left as an exercise for the reader"!

Using these Pages

Probably the best way to start using these pages is to begin with the requirements and work through the entire analysis, high-level design, and detailed design process.

1. Begin with the Requirements and User Interface document.
    
   The first task that must be performed in any project is clearly understanding the requirements. This series of pages starts with a statement of the overall requirements for the software, without attempting to discuss the process of actually arriving at them. For a problem of this size, identifying the requirements is fairly straightforward. In a real system, however, identifying the requirements will generally be a non-trivial task. That, however, is not the focus of this set of pages.
    
2. Then view the Use Cases and Further Analysis.
    
   Analysis is begun by identifying the use cases that follow from the requirements, and detailing a flow of events for each. Further analysis identifies the key classes that are suggested by the use cases, and considers how each use case can be carried out by an interaction between objects belonging to these classes.
    
   • The Use Case document has a Use Case Diagram and a series of flows of events, one for each use case. Each use case also has a link to a Sequence Diagram (part of the Design phase) which shows how it is realized; these links can be followed while studying the design phase to see how the analysis phase flows into the design phase.
   • The Further Analysis document deals with both the "big picture" and the details of the various use cases. The former is provided by an Analysis Class Diagram, with each class having a link to its CRC card; the latter by a discussion of how the key objects objects would need to interact in order to implement the use case.
      
   These two documents represent two different ways of viewing the overall system, which continue into the next phase. The Use Case document presents a use-case centric view of the system, focussing on the specific functions it provides. The Further Analysis document presents a class centric view of the system, focussing on how will be built.
    
3. This example uses CRC Cards and Sequence Diagrams for high level Design. There are certainly other tools that might be used - e.g. the ATM Example referred to above makes use of Collaboration Diagrams and State Charts as well.
    
   • The responsibilities of each class that arise from the use cases are recorded on a CRC card for each class. The CRC cards could be created by "walking through" each use case, assigning the responsibility for each task to some class.
   • There is a Sequence Diagram for each use case, showing how the use case is realized by interaction of the major objects.
   • A Class Diagram shows how the various classes are related to one another. It also shows several additional classes that were "discovered" during the process of creating the Sequence Diagrams - i.e. classes needed to actually build the system, though not evident in the original analysis. On this diagram, the class icon is linked to a detailed design for that class.
   
    
4. Detailed design is done by using a detailed UML diagram for each class, showing its attributes and operations.
    
5. Both source code and "Javadoc" documentation is available for all classes.
    
6. A demonstration executable version of the the system is available, in the form of a Java Applet. This version is limited, because the Java mechanisms to protect against malicious code limit access to the file system on the host computer. For this reason, it is not possible to use the "Open", "Save", or "Save As" features of the demonstration - attempting to do so will result in an error dialog.
    
7. A page of maintenance ideas suggests changes that might be made to improve the system. These changes would necessarily involve modifying many of the sample documents, not just modifying code.

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 teaching 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
russell.bjork at gordon dot edu

Page of links for non frames-enabled browsers.

Copyright © 2005, 2008, 2011 - Russell C. Bjork. Permission for non-commercial reproduction for educational use is hereby granted; all other rights are reserved.