OOA/OOD

Mark J. Klocke

A structured engineering approach (methodology) is required to support the development of complex software systems. A methodology consists of a required set of development deliverables and formal guidelines for producing the deliverables. This article will present object-oriented analysis and design deliverables with examples from a Time Reporting System application. An automated and integrated tool set is a crucial component of a successful software project. Examples in this article were created with MacA&D, a commercial Computer Aided Software Engineering (CASE) tool from Excel Software.

Object-oriented methods offer improvements in quality, managing complexity, and ultimately reducing the development and maintenance cost of software projects. The project challenges to overcome are to flatten the object-oriented learning curve, apply objects to your domain, and achieve re-use of your domain objects. Several object-oriented analysis and design (OOA & OOD) methods, such as the Coad/Yourdon, Rumbaugh, Shlaer/Mellor, and Booch, are currently being used to address these challenges and improve the development of applications. Coupled with CASE tools these methods can provide an integrated, streamlined approach to software development (see Figure 1: Object-oriented Analysis and Design Deliverables).

In the Time Reporting System example, we boil down the myriad of OOA and OOD techniques to their essential elements; these elements are class diagrams, object (instance and communication) diagrams, and their supporting state and flow diagrams. In addition, we will use screen prototyping to express the sample application's user interface. Diagrams are integrated with a global data dictionary and requirement database to simplify model associations for development and maintenance. Other text deliverables such as the project specification, test information, and code will not be reviewed at this time. Chronologically, the deliverables in Figure 1 are produced top down, and left to right, with information in the data dictionary being supplied from the other documents.

Development Deliverables Overview

The Requirements Database integrates models by common requirements, providing traceability throughout the development and maintenance of the application. Requirements may be collected portions of a text document, or entered according to a user defined template.

Screen prototyping can be used to analyze the essential elements of the user interface prior to the formal design process. Menus, buttons, data fields, and other interface items may be used to quickly generate a sample interface and interactively browse through connected screens and dialogs.

A class diagram illustrates object classes and structures using a variety of symbols, line styles and line terminations. For each object class, attributes (data) and operations (algorithms) are identified and defined.

Some objects have an associated life cycle represented by specific states or modes in which the object can exist. A transition from one state to another will occur when a specific event takes place. Object life cycles can be represented by state transition diagrams or tables.

Data Flow Diagrams are used within some methodologies to model application context and object interfaces (data and control). Data Flow Diagrams are used more extensively for functional decomposition in Structured Analysis, and will only be touched upon briefly for this example.

While a class diagram is great for illustrating the static structure of classes from which objects are instantiated, it reveals little about how objects interact with each other. An object diagram is used to show how each mechanism in the design works by passing messages between object operations.

To ensure consistency and completeness, the various views of a software design must be integrated. A data dictionary integrates all the diagramming views into a common repository of information and provides detailed definitions for items used on diagrams.

Requirement Database

Historical data shows that defects which occur during the requirement definition phase are much more costly to correct than those introduced during the later design or implementation phases of development. This effect is compounded as the size of the project and development team grows. Requirement defects include missing, incomplete, ambiguous, or non-implemented requirements. Using a requirement database can reduce the risk and cost of requirement defects.

A requirement database is simply a list of requirement statements each uniquely identified by a name or number. Parent and child references are associated with each requirement statement to provide traceability. A parent reference identifies the source of a requirement, while a child reference targets a deliverable such as a design diagram or test procedure which satisfies the requirement. Transforming user requirements, concepts, and ideas into a detailed design ready for implementation is an iterative modeling process.

Each requirement statement is an unambiguous, testable fact (typically by multiple test cases) about a condition or capability needed by a user to solve a problem or achieve an objective. Requirements are processing, information, performance, or capacity statements about the system under design. System and product requirements are typically derived from market demands, quality, reliability, performance, and safety considerations.

The requirement database provides concrete links between requirement statements and other deliverables of the development process. Traceability provides a clear picture of how each requirement is satisfied and quick assessment of the impact of requirement changes.

To illustrate requirement statements and the other forms of modeling to follow, consider the analysis and design of a Time Reporting System. Here is a requirement used to specify this project:

NAME: Report$Employee$Sort
PARENT: FOREIGN TimeReports.Spec
DEFINITION: Employee reports shall be sorted by job title or
            alphabetically by last name.
CHILD: FORM TimeReports.Form Main Screen 
ERD TimeReports.ERD TRS 
OBJECT TimeReports.OBJ Generate Employee Reports 
FOREIGN Reports.TDS EmployeeSortTest 

Requirement statements can be written using a formal structure or as simple sentences as we have used here. References provide traceability to origin (parent) and development deliverables (children).

Screen Prototype

Screen prototyping can be an effective means of exposing requirements and achieving consensus on user interface early in a project. A screen prototype is simply a set of interconnected user screens containing interface elements such as data entry fields, buttons, menus, text and graphics. MacAnalyst supports dynamic interactive screen prototypes which allow users to provide constructive feedback on the user interface before starting the software design process.

Using the Time Reporting System example, two screens and a menu representing its user interface are shown below. Upon access (login) to the Time Reporting System, the main menu is displayed (see Figure 2-Time System Startup Screen).

The screen was created by defining the pull-down menus and menu commands. The following screens which use the same menu commands 'clone' the definition from the startup screen. In the Time Reporting System, the user selects commands from the File, Edit, and Report pull-down menus (see Figure 3-Interactively Browsing Screens). In Browse mode (interactive), selecting the New Time Sheet command from the File menu brings up the New Time Sheet window (see Figure 4-New Time Sheet Screen).

Like other views in the modeling process, interface items on the screens of a prototype are integrated with other CASE models via the data dictionary and requirement database.

Class Diagram

The class diagram shows each object class and its associated attributes and operations. Structures between classes such as inheritance are represented on the class diagram. In our Time Reporting System example, a fictitious third party class library (called SimpleApp) is used for the user interface and file manipulation. A new Coad/Yourdon style class library (TimeReports) was created for our time reports application.

The SimpleApp class named "Object" is at the root of the inheritance tree. The class "Application" is a subclass of "Event Handler." Subclasses, or the general/specific relationship, is shown by the rounded triangle. Aggregation, or whole/part relationships, are shown by a triangle such as "ListOfItems" being part of a "Document." The "Application" class will have attributes "TimeSheetsList," "ProjectList," and "EmployeeList" (which are references to instances of the "ListOfItems" container class), and operations "MainEventLoop," "DoMenu-Command," and "VerifyLogin," plus attributes and operations inherited from its parent classes (see Figure 5-Coad/Yourdon Style Class Diagram Portion of SimpleApp, and Figure 6-Coad/Yourdon Style Class Diagram - Time Reporting System).

Organizing data and algorithms into classes is an important part of analysis and design. Good candidate classes can often be chosen from a general description of the problem domain as in our example of Employee, Manager, Project, and TimeSheet. Design is an iterative process requiring many refinements as more is understood about the system under study. Object communication diagrams described below are an excellent way of revealing the inadequacies of a first draft class diagram by exposing missing or inconsistent attributes and operations.

Like other views of the system, the class diagram is an integrated part of the CASE repository. For example, within MacA&D, double-clicking on a Class object brings forward the Data Dictionary window and displays detailed information about that class including its attributes, operations and inherited classes. Detailed descriptions of each attribute and operation can be included in the dictionary.

State Transition Diagrams

Since objects may be dynamically allocated, real-time modeling techniques for state transitions and data/event flow can be used to detail each object. Data flow diagrams are used to provide a frame of reference, or context, for the system, and to provide another view of the objects abstract control and data interface.

Dynamically allocated objects have various states of operation, such as "Initialized," "Active," and "Failure Mode." The states of dynamic objects, often referred to as an object life-cycle, are modeled with a state transition diagram (STD).

State transition diagrams (STDs) and tables are a common modeling technique for expressing the finite states within a system or object, and events which can occur to cause a transition from one state to another. A state model can also express a list of actions which take place upon transition from one state to another.

In the Time Reporting System example, two states ("Active User" and "Active Admin") are detailed in subdiagrams. Upon initialization, a login dialog is presented. A correct login transitions service to one of two "Active" states and enables the menu commands. This is illustrated in Figure 7.

Object Communication Diagram

Object communication diagrams are used to show how mechanisms in the design work by passing messages between instantiated object classes. In our Time Reporting System example, five diagrams are sufficient to represent the new mechanisms of the Time System domain. Two of the seven original (SimpleApp) mechanisms for event handling were modified for our application. The Login and Project Reports mechanisms are shown.

After application initialization, the "VerifyLogin" operation of the Application invokes the iterate operation "EachItemDo" to verify the login EmployeeID with the Employee list IDs (see Figure 8-Object Communication Diagram - Login).

Now let's consider the mechanism of Generate Project Reports. In this mechanism, a menu Project Report command event is processed by the "Main Event Loop" which invokes the "ListInfoReport" operation with the requested project number. "ListInfoReport" iterates through the "TimeSheets" ListOfItems and if the project number matches the requested project number, the "TimeSheet" instances "Print" operation generates its portion of the report. When the search is complete Project notifies the Application instance (see Figure 9-Object Communication Diagram - Generate Project Reports).

Summary

This article presented an overview of object-oriented analysis and design techniques for software applications. A Requirements Database, Screen Prototypes, Class Diagrams, and Object Diagrams deliverables were presented. The diagrams were created using a CASE tool, MacA&D. In addition to easy creation and editing of diagrams, MacA&D allows designers to integrate the different modeling views of their project and provide easy navigation between these models.

Producing these deliverables within a CASE tool automates steps of the development process, such as error checking and producing reports. For example, when you have completed the class diagrams of a design, use the Relation Specifications report to automatically produce a complete text narrative of your design directly from the diagrams. Verification and balancing reports can check for literally hundreds of inconsistencies or omissions between diagrams and dictionary information within seconds. Together OOA and OOD techniques coupled with CASE technology can provide a powerful method for software development.