Object-Oriented Analysis

Object-oriented analysis (OOA) is concerned with developing software engineering requirements and specifications that expressed as a system's object model (which is composed of a population of interacting objects), as opposed to the traditional data or functional views of systems. OOA can yield the following benefits: maintainability through simplified mapping to the real world, which provides for less analysis effort, less complexity in system design, and easier verification by the user; reusabilityof the analysis artifacts which saves time and costs; and depending on the analysis method and programming language, productivity gains through direct mapping to features of Object-Oriented Programming Languages

Technical Detail

An object is a representation of a real-life entity or abstraction. For example, objects in a flight reservation system might include: an airplane, an airline flight, an icon on a screen, or even a full screen with which a travel agent interacts. OOA specifies the structure and the behavior of the object- these comprise the requirements of that object. Different types of models are required to specify the requirements of the objects. The information or object model contains the definition of objects in the system, which includes: the object name, the object attributes, and object relationships to other objects. The behavior or state model describes the behavior of the objects in terms of the states the object exists in, the transitions allowed between objects, and the events that cause objects to change states. These models can be created and maintained using CASE tools that support representation of objects and object behavior.

OOA views the world as objects with data structures and behaviors and events that trigger operations, or object behavior changes, that change the state of objects. The idea that a system can be viewed as a population of interacting objects, each of which is an atomic bundle of data and functionality, is the foundation of object technology and provides an attractive alternative for the development of complex systems. This is a radical departure from prior methods of requirements specification, such as functional decomposition and structured analysis and design.

Usage Considerations

This technology works best when used in new development. The experiences of Hewlett-Packard in trying to recapture the requirements of legacy systems using OOA suggests that the process can be accomplished only when legacy systems are projected to be long-lived and frequently updated.

Maturity

Numerous OOA methods have been described since 1988. These OOA methods include: Shlaer-Mellor, Jacobson, Coad-Yourdon, and Rumbaugh.. The results of implementing these methods range from tremendous successes at AT&T Bell Labs to a mixture of successes and partial failures on other projects. AT&T Bell Labs realized benefits from OOA on a large project called the Call Attempt Data Collection System (CADCS). Additionally, they found during the development of two releases of the CADCS that use of the OOA techniques resulted in an 8% reduction in requirements specification time and a 30% reduction in requirements staff effort. Other OOA efforts have not been able to reproduce these successes for reasons such as the lack of completed pilot projects, and the lack of formal OOA training.

Costs and Limitations

The use of this technology requires a commitment to formal training in OOA methods. A method of training that has produced desired results is to initiate pilot projects, conduct formal classes, employ OOA mentors, and conduct team reviews to train properly both the analysis and development staff as well as the program management team. There are almost no reported successes using OOA methods on the first application without this type of training program. Projects with initial and continuing OOA training programs realize that the benefits of this technology depend upon the training and experience levels of their staffs. Purchase of CASE tools that support object-oriented methods may significantly enhance OOA- this is another cost to consider.

Alternatives

Alternative technologies that are used for developing software engineering requirements and specifications include functional decomposition, essential systems analysis, and structured analysis.

Complementary Technologies

There is a strong relationship between OOA and other object-oriented technologies (see Object-Oriented Database, Object-Oriented Design, and Object-Oriented Programming Languages). This is especially true of object-oriented design- certain object-oriented methods combine particular analysis and design methods that work well together. In fact, the seamless use of objects throughout the analysis, design, and programming phases provides the greatest benefit. Use of OOA alone, without transition into OOD, would be a severely limited approach.

Combining object-oriented methods with Cleanroom (with its emphasis on rigor, formalisms, and reliability) can define a process capable of producing results that are reusable, predictable, and high-quality. Thus, object-oriented methods can be used for front-end domain analysis and design, and Cleanroom can be used for life-cycle application engineering.