The objective of object-oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer-d...
The objective of object-oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer-defined requirements. OOA, like the conventional analysis methods , builds a multipart analysis model to satisfy this objective. The analysis model depicts information, function, and behavior within the context of the elements of the object model .
Conventional vs. OO Approaches
Is object-oriented analysis really different from the structured analysis approach ? Fichman and Kemerer address the question head-on:
We conclude that the object-oriented analysis approach . . . represents a radical change over process oriented methodologies such as structured analysis, but only an incremental change over data oriented methodologies such as information engineering. Process-oriented methodologies focus attention away from the inherent properties of objects during the modeling process and lead to a model of the problem domain that is orthogonal to the three essential principles of object-orientation: encapsulation, classification of objects, and inheritance.
Stated simply, structured analysis (SA) takes a distinct input-process-output view of requirements. Data are considered separately from the processes that transform the data. System behavior, although important, tends to play a secondary role in structured analysis. The structured analysis approach makes heavy use of functional decomposition.
Fichman and Kemerer suggest 11 “modeling dimensions” that may be used to compare various conventional and object-oriented analysis methods:
1. Identification/classification of entities
2. General-to-specific and whole-to-part entity relationships
3. Other entity relationships
4. Description of attributes of entities
5. Large-scale model partitioning
6. States and transitions between states
7. Detailed specification for functions
8. Top-down decomposition
9. End-to-end processing sequences
10. Identification of exclusive services
11. Entity communication (via messages or events)
Because many variations exist for structured analysis and dozens of OOA methods have been proposed over the years, it is difficult to develop a generalized comparison between the two methods. It can be stated, however, that modeling dimensions 8 and 9 are always present with SA and never present when OOA is used.
The OOA Landscape
The popularity of object technologies spawned dozens of OOA methods during the late 1980s and into the 1990s. Each of these introduced a process for the analysis of a product or system, a set of diagrams that evolved out of the process, and a notation that enabled the software engineer to create the analysis model in a consistent manner. Among the most widely used were
The Booch method. The Booch method [BOO94] encompasses both a “micro development process” and a “macro development process.” The micro level defines a set of analysis tasks that are reapplied for each step in the macro process. Hence, an evolutionary approach is maintained. Booch’s OOA micro development process identifies classes and objects and the semantics of classes and objects and defines relationships among classes and objects and conducts a series of refinements to elaborate the analysis model.
The Rumbaugh method. Rumbaugh and his colleagues developed the object modeling technique (OMT) for analysis, system design, and object-level design. The analysis activity creates three models: the object model (a representation of objects, classes, hierarchies, and relationships), the dynamic model (a representation of object and system behavior), and the functional model (a high-level DFD-like representation of information flow through the system).
The Jacobson method. Also called OOSE (object-oriented software engineering), the Jacobson method is a simplified version of the proprietary objectory method, also developed by Jacobson. This method is differentiated from others by heavy emphasis on the use-case—a description or scenario that depicts how the user interacts with the product or system.
The Coad and Yourdon method. The Coad and Yourdon method is often viewed as one of the easiest OOA methods to learn. Modeling notation is relatively simple and guidelines for developing the analysis model are straightforward. A brief outline of Coad and Yourdon’s OOA process follows:
• Identify objects using “what to look for” criteria.
• Define a generalization/specification structure.
• Define a whole/part structure.
• Identify subjects (representations of subsystem components).
• Define attributes.
• Define services.
The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner do not make a clear distinction between analysis and design tasks. Rather a continuous process that begins with the assessment of a customer specification and ends with design is proposed. A brief outline of Wirfs-Brock et al.'s analysis-related tasks follows:
• Evaluate the customer specification.
• Extract candidate classes from the specification via grammatical parsing.
• Group classes in an attempt to identify superclasses.
• Define responsibilities for each class.
• Assign responsibilities to each class.
• Identify relationships between classes.
• Define collaboration between classes based on responsibilities.
• Build hierarchical representations of classes.
• Construct a collaboration graph for the system.
• Extract candidate classes from the specification via grammatical parsing.
• Group classes in an attempt to identify superclasses.
• Define responsibilities for each class.
• Assign responsibilities to each class.
• Identify relationships between classes.
• Define collaboration between classes based on responsibilities.
• Build hierarchical representations of classes.
• Construct a collaboration graph for the system.
Although the terminology and process steps for each of these OOA methods differ, the overall OOA processes are really quite similar. To perform object-oriented analysis, a software engineer should perform the following generic steps:
1. Elicit customer requirements for the system.
2. Identify scenarios or use-cases.
3. Select classes and objects using basic requirements as a guide.
4. Identify attributes and operations for each system object.
5. Define structures and hierarchies that organize classes.
6. Build an object-relationship model.
7. Build an object-behavior model.
8. Review the OO analysis model against use-cases or scenarios.
A Unified Approach to OOA
Over the past decade, Grady Booch, James Rumbaugh, and Ivar Jacobson have collaborated to combine the best features of their individual object-oriented analysis and design methods into a unified method. The result, called the Unified Modeling Language (UML), has become widely used throughout the industry.
UML allows a software engineer to express an analysis model using a modeling notation that is governed by a set of syntactic, semantic, and pragmatic rules. Eriksson and Penker explain these rules in the following way:
The syntax tells us how the symbols should look and how the symbols are combined. The syntax is compared to words in natural language; it is important to know how to spell them correctly and how to put different words together to form a sentence. The semantic rules tell us what each symbol means and how it should be interpreted by itself and in the context of other symbols; they are compared to the meanings of words in a natural language.
The pragmatic rules define the intentions of the symbols through which the purpose of the model is achieved and becomes understandable for others. This corresponds in natural language to the rules for constructing sentences that are clear and understandable.
In UML, a system is represented using five different “views” that describe the system from distinctly different perspectives. Each view is defined by a set of diagrams. The following views are present in UML:
User model view. This view represents the system (product) from the user’s (called actors in UML) perspective. The use-case is the modeling approach of choice for the user model view. This important analysis representation describes a usage scenario from the end-user's perspective.
Structural model view. Data and functionality are viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled.
Behavioral model view. This part of the analysis model represents the dynamic or behavioral aspects of the system. It also depicts the interactions or collaborations between various structural elements described in the user model and structural model views.
Implementation model view. The structural and behavioral aspects of the system are represented as they are to be built.
Environment model view. The structural and behavioral aspects of the environment in which the system is to be implemented are represented.
In general, UML analysis modeling focuses on the user model and structural model views of the system. UML design modeling addresses the behavioral model, implementation model, and environmental model views.
