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.
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.
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).
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.
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.
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.
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).
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.
