September 93 - OOA/OOD
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.