In-Depth

An Approach to Assessing and Comparing Object-Oriented Analysis Methods

• By Ying Liang
• July 13, 2001

Many object-oriented analysis (OOA) methods are now available for use in system analysis. The methods have many common essential features. For example, they build analysis models for systems and provide an analysis process for building those models. However, the details of the features can be defined differently because of the different goals of analyzing systems with object orientation. The details have to be assessed in order to understand the features correctly within the method, or the features have to be compared precisely in different methods. This article presents a framework as a tool for assessing the details of the common essential features in individual OOA methods, and explores the dependency of the features.

Many object-oriented analysis (OOA) methods are now available for analyzing and modeling a system with objects. My colleagues and I have used some of them in case studies^{1, 2} and also analyzed a number of OOA methods in detail to find how they support OOA. Our research found that all of these OOA methods have seven similar essential features: analysis models, modeling concepts, fundamental principles, analysis tactics, analysis processes, requirement sources, and analysis deliverables. These features exist with dependent relationships; that is, a feature may depend on other features (see Fig. 1). All of these essential features support the common goal of OOA methods: to build the object analysis model for a system through an analysis process.

However, the methods may define these essential features with different details, as they want to build their own analysis models for a system. For example, the Object Modeling Technique (OMT)³ defines the analysis for a system model with three small models (object, dynamic, and functional models). The Coad/Yourdon method⁴ and the Wirfs-Brock method⁵ define only one model for a system. Another example is that OMT³ defines a class with attributes while the Wirfs-Brock method⁴ defines a class without attributes. Therefore, to understand the uniqueness of an OOA method and its real differences from other OOA methods, we must find out how the method defines details of the features and also how the features depend on each other. In addition, we should find out to what extent the similarities and differences between OOA methods are real, rather than merely apparent, when we compare the methods based on their features.

Some comparative studies of OO methods were done (e.g., Arnold et al.,⁶ de Champeaux and Faure,⁷ Fowler,⁸ and Monarchi and Puhr⁹) in the past based upon features similar to those mentioned. However, the studios or researchers put little emphasis on examining the details of the features and the relationships between the features in individual OOA methods. We have created a framework that consists of a collection of common essential features of OOA methods and assesses the features with a dependent structure, so that an OOA method can be learned, analyzed, and assessed through the details of its features.

THE FRAMEWORK
The framework used for assessing the common essential features and their dependencies in individual OOA methods is shown in Figure 2. In the diagram, each rectangular box represents a feature; each solid line represents a dependent relationship between two features; and each arrow represents a possible requirement resource of analysis.

The common essential features covered by the framework are specified as follows:

• The Fundamental Principle: basic laws of analysis.
• The Analysis Model: a view and representation of a system. Different types of models may be built by a method to represent different views and aspects of the system separately. A model is defined together with a set of modeling concepts. Each modeling concept is an abstract idea behind the business of analysis; that is, it abstracts and specifies a specific piece of the system.
• The Notation: a set of diagrammatic or textual symbols used to represent a model.
• The Tactic of OOA: a strategy for driving the process of analysis.
• The Source of Requirement: the details of an analyzed system.
• The Process of OOA: a way of building the model step by step. Each step should provide guidelines and criteria for building the right model correctly.
• The Deliverable of Analysis: the product generated through analysis.

As an example, Table 1 shows the essential features of OMT³ identified using the framework.

The framework also links the features by their dependent relationships (represented by solid lines). For example, the notation depends on the modeling concepts in order to represent them. The process of OOA depends on the model, as the process has to build the model and the deliverable includes the model. The process of OOA depends on the tactic of OOA because it is driven by a tactic of OOA , for instance, a data-driven tactic creates the process to model objects and their attributes first, and a process-driven tactic drives the process to model objects and their operations first. Such dependent relationships between the features can show how the details of a feature may affect the details of another feature.

THE PROCESS OF ASSESSING OOA METHODS USING THE FRAMEWORK
We illustrate a process of using the framework to assess an OOA method in Figure 3. Each box in the diagram shows a step of the process. The solid arrows represent the order of the steps. The dashed arrows represent the feature flows between the steps and the framework. In each step, a set of instructions is provided based on the framework, which explores and assesses the details—such as definitions—of the essential features of the OOA method. The answers are found according to the tasks during the assessment.

In the following section, we explain details of each step in the process. OOA methods numbered from 1–10 (see Table 2) are assessed as examples of using the framework through the process.

Identify fundamental principles.

1. Which fundamental principles does the OOA method use for OOA? How are they defined?

   Many OOA methods books introduce and explain the fundamental principles employed by the methods. You must be aware of the definition or meaning of each principle in each OOA method, as a principle may be termed differently or a term may name a few principles with different meanings in different OOA methods. For example, Table 3 lists the fundamental principles employed by the 10 OOA methods.

   The terms show that some principles such as abstraction are employed by more than one method and others such as domain are only employed by one. However, the meanings of the principles tell which term represents the same thing and which does not. For example:

   • The abstraction principle refers to different types of abstraction in the methods (see Step 2).
   • The encapsulation principle also means information hiding in the methods except with the Wirfs-Brock method and HOOD: Encapsulation means the separation of external aspects of an object from its internal ones, and only external aspects can be seen by other objects. The two methods define "encapsulation" and "information hiding" differently: Encapsulation means the combination of the data and the operations that affect data in objects, and information hiding means to hide the internal details of an object from other objects.
   • The inheritance principle has the same meaning in the nine methods that use it. (HOOD does not use this principle.)
   • The scale principle in the Coad/Yourdon method is similar to the domain principle in Syntropy: Scale is a principle that guides a reader through a large model by partitioning it into smaller parts. Domain is a way of dividing a system description, though not of system execution, into smaller parts, i.e., subsystem descriptions.

2. Why does the method choose to use such principles?

   Different OOA methods may choose to employ different fundamental principles for different reasons. For example, the Wirfs-Brock method analyzes the functional connections rather than the data relationships between objects. OMT focuses on the object structure but not on the messages flowing between objects. Therefore, the principle "emphasis on object structure" is used by OMT and the principle "communication with messages" is used by the Wirfs-Brock method. Answering this question helps understand the aims of the method more precisely and deeply.

1. How many different types of models are built?

   Some OOA methods build one model only and other methods build two or more models for a system. For example, the Wirfs-Brock method, the Coad/Yourdon method, HOOD, and Syntropy build one model only. OMT, the Booch method, OOSE, the Shlaer/Mellor method, OSA, and Ptech build two or more models (see Table 4). It is necessary to assess each model separately if the method builds more than one model, so that details of each model can be found and assessed precisely.

2. Which perspective of a system is emphasized and specified by each model?

   Booch points out that it is impossible to capture all of the subtle details of a complex software system in just one view.¹⁰ That means that it is better to use different views to capture different aspects of a system. Some OOA methods may prefer to build one model for one view. Other methods may choose to use different views to build different parts of a model. For example, OMT employs three views to capture the data, event, and process details of a system respectively and builds three separate models corresponding to each of the views. The Coad/Yourdon method employs two views to capture the data and event details of a system and builds one model through the two views. Table 4 summarizes the views and perspectives supported by the 10 methods.

3. What modeling concepts are defined within the models? A model includes a set of modeling concepts, each of which usually abstracts the details of a system. An OOA method defines models with modeling concepts and also explains the meanings of the concepts clearly and precisely. For example, Table 5^* lists the modeling concepts included in the models within the 10 OOA methods.
4. How is each modeling concept defined by the method?

   Due to a lack of standardized terminology in OOA methods, the definitions of terms naming the modeling concepts must be examined carefully to avoid confusion of their meanings. For example, the term "object" may mean different things in different OOA methods, as follows:

   • An object has a state, attributes, and operations (in OMT).
   • An object is an encapsulation of attribute values and their exclusive services (in the Coad/Yourdon method).
   • An object has state, behavior, and identity (in the Booch method).
   • An object is the encapsulation of functions and data, and it has a public interface and a private representation to make the internal details invisible to other objects (in the Wirfs-Brock method).
   • An object consists of property values and responsibilities (in Syntropy).

   From these object definitions, you can see that the Booch method and the Wirfs-Brock method do not define attributes with objects—but other methods do. In addition, "object class" in OMT, "object type" in Syntropy, "class-&-object" in the Coad/Yourdon method, and "class" in other methods shown in Table 4 are defined as the same thing, i.e., a collection of objects. Additional modeling concepts represented by the same or different terms are shown in Table 6, according to their definitions. Therefore, the appreciation of the meaning of elements is important for us to understand the modeling concepts precisely.
5. Is any modeling concept defined under a condition?

   OOA methods may define a modeling concept under a condition. For example, "attribute" cannot be an object, and "aggregation" should not be used unless necessary in OMT. The finding of such conditions helps to use modeling concepts correctly.

1. Which notation(s) is provided by the method?

   An OOA method provides at least a notation for representing analysis models. A notation often consists of a set of textual or graphical symbols, each of which represents a piece of information in a system abstracted using modeling concepts. For example, the 10 OOA methods provide various notations for the models, as shown in Table 7. In many cases, a symbol corresponds to a modeling concept. However, different symbols may correspond to the same modeling concept in different OOA methods, if different notations are used.

2. Why does the method prefer such notations?

   Many OOA methods suggest that notations with diagrams seem more intuitive, readable, and understandable than texts. Therefore, they use diagrams to represent models. A model can be represented by one diagram, or two or more diagrams. In addition, some methods use one diagram to focus on one aspect of a system, making the diagram simple and small. The name of each diagram indicates the focus or intent of the diagram.¹⁰

1. Which tactic of analysis is employed by the method?

   Some OOA methods books show the tactics of analysis to let the analyst know which perspective of a system is the most basic and focused by the methods. For example, Table 8 shows the tactic of analysis of five OOA methods. However, some methods books, such as the other five methods in our example may not show their tactics explicitly. In this case the tactic employed has to be found by assessing the relationship between the tactic and the process (see second subsection of Step 2).

2. How does the tactic work?

   The tactic of analysis impacts the order of viewing and modeling different parts of a system. For example, a data-driven tactic of analysis takes the object structure in system objects, their attributes, and their inherent relationships prior to the object behavior, while a process-driven tactic of analysis is vice versa (starting wtih object behavior).