In-Depth

An Object-Oriented Analysis Technique Based on the Unified Modeling Language

• By Shih-Chien Chou, Jen-Yen Jason Chen
• June 1, 2001

This article proposes an object-oriented analysis (OOA) technique based on the unified modeling language (UML). The technique emphasizes its OOA process, that is composed of the following activities: requirement capturing, specification component identification, and specification representation. During requirement capturing, several function-viewed notations are used, including context diagram of the structured analysis (SA) technique, and use case diagrams and activity diagrams of the UML. During specification component identification, a systematic procedure is provided to identify class and their attributes from data, and to identify class operations from CRC (class, responsibility, collaborator) cards. And, during specification representation, most notations used are from UML.

An OOA technique is generally composed of an OOA process to analyze requirements and identify specification components (e.g., classes and class relationships), and an OOA model to represent specifications. Most early OOA researchers focused on an OOA model.^1–21 They identified new components that should be included in an OO specification. They designed new notations to improve understandability. Additionally, they argued whether functions should be included in an OO specification. As for the OOA process, it seems that most early researchers focused on class identification and argued whether an OOA process should be purely OO or if it can be based on functional decomposition. They, however, generally neglected many important activities in an OOA process, such as requirement capturing and attribute identification.

Recently, OOA researchers have been substantially affected by UML.²² UML can be used for OO models in all phases of software development, including OOA. It provides rich notations for representing OO components, such as classes, objects, object behaviors of classes, object interactions, and even functions (use cases and activity diagrams). It seems that UML integrated most OO models. Therefore, the search for new OOA models has been dramatically reduced, if not totally terminated.

UML does contribute much in OOA research. However, UML does not provide a process. Therefore, different analysts may follow different processes in using UML. This may result in large performance differences between experienced analysts and inexperienced ones. Our experience in the research of software process shows that the OOA process tremendously affects OOA performance.^{23, 24} Generally, an OOA process consists of requirement capturing, specification component identification, and specification representation.

Nevertheless, what are the essential elements in an OOA process? We have the following observations:

1. Customers normally provide requirements from the functional aspect. For example, a customer may require that a supermarket system to manage the status of goods, employees, and so on. Also, customer requirements may be incomplete, incorrect, ambiguous, or even inconsistent.
2. Specification components, especially classes and their attributes and operations, are usually difficult to identify.
3. Since both classes and attributes can be identified from data, it may be difficult to decide which data should be transformed into classes and which should be regarded as attributes.^15,21

According to the observations above, we propose that an OOA process should:

1. Facilitate capturing real requirements from the functional aspect,
2. Facilitate identifying specification components, especially classes and their attributes and operations, and
3. Facilitate differentiating data that should be transformed into classes from those that should be regarded as attributes.

As stated before, most OOA researchers focused on the OOA model.^1–21 As for the OOA process, quite a few techniques neglect the need for requirement capturing.^{1, 2, 4–19, 21, 25–26} They generally assume that the required documents are available and correct. Only a few techniques such as OOSE and OBA regard requirement capturing as important.^{3, 20} In identifying classes, most OOA techniques provide guidelines. For example, classes are suggested to be identified from problem domains,¹ real world,⁹ nouns in requirements¹¹ or informal strategy,¹⁶ event descriptions,^12,13 requirement documents,¹⁷ or functional decomposition results.^4,18 Some techniques even suggest applying any existing techniques to identify classes.^{19, 25–26} However, our experiences show that most guidelines suggested by the techniques mentioned above are heuristic and thus, may be difficult for novice analysts to follow. As for identifying class attributes and operations, many OOA techniques pay it little attention.^2,5 For example, Bailin's technique does not specify attributes at all.⁴ Therefore, our survey shows that the processes of the existing OOA techniques seem rather weak in capturing the requirements, and identifying classes and their attributes and operations.

We designed an OOA technique based on parallel decomposition of function and data.²¹ It provides a systematic process for separating classes and attributes from data, and class operations from functions. It also facilitates differentiating the data that should be transformed into classes from those that should be regarded as attributes. However, the requirement capturing ability of that technique is weak. After years of using the technique, its process has been improved by integrating several requirement analysis processes such as structured analysis (SA)²⁷ and CRC card techniques.²⁷ Also, the requirement capturing ability has been enhanced. Moreover, the model of the technique has been revised, in which most notations are from UML. Features of the new technique are described next.

1. It uses function-viewed notations to facilitate requirement capturing, including context diagram of the SA technique,²⁷ and use case diagrams and activity diagrams of the UML.²²
2. It uses data hierarchies (as discussed in our previous OOA technique) to identify classes and their attributes.²¹
3. It uses CRC cards to identify class operations.²⁸
4. It uses UML notations to represent specifications.

REQUIREMENT CAPTURING
Requirements, as stated before, are usually incomplete, incorrect, ambiguous, or even inconsistent. To capture real requirements, analysts should keep close contact with customers through interviews or meetings, such as the FAST (facilitated application specification techniques) procedure.²⁹ To facilitate that communication, a model should be used.

Since customers generally provide requirements from the functional aspect, the communication model should take a functional view. We found the use case diagram of UML beneficial because use cases take a functional view, and use cases roughly correspond to requirement information.³ However, utilizing use case diagrams for communication is insufficient, because the diagrams do not show the activities of the use cases. Since use case activities facilitate understanding use cases, those activities are essential in validating the requirements. Therefore, use case activities should also be specified for communication. It seems that the activity diagram of UML is good for describing use case activities, because: 1) it takes a functional view, 2) it is powerful in describing activities, activity sequence, synchronization, and concurrency, and 3) it is graphic and hence easy to understand. See Figure 1(a) for a use case diagram and Figure 1(b) for its corresponding activity diagram. Note that Figure 1(b) puts the name of the use case in the starting circle. This relates a use case to its corresponding activity diagram.

Figure 1. Use case and its corresponding diagram.

Before drawing use case diagrams and activity diagrams, use cases should be identified first. It is known that a use case consists of a sequence of interactions between actors and a system in which an actor may be a user or another system.³ Use cases can thus be identified from the perspectives of actors. Therefore, our technique first identifies actors, from whose perspectives use cases are then identified.

In identifying actors and use cases, the context diagram of the SA technique is used.27 The rationales are:

1. The diagram describes system boundary, which prevents analysts from wasting time analyzing parts outside a system.
2. The diagram shows the system's actors (here an actor corresponds to an external entity of that diagram) whose perspectives can be taken to identify use cases.

Sometimes, use cases identified from actor perspectives do not cover all of the system's functions. For example, in a supermarket management system that should periodically check stock levels, no actor will initiate the checking function. Actually, the function is automatically initiated inside the system, which is called an internal use case. Generally, internal use cases can be identified by checking the functions that must be periodically performed.

According to the above description, the requirement capturing process in our technique contains the following steps, which may be iterated.

1. Identify actors (external entities).
2. Draw a context diagram.
3. Identify use cases from actor perspectives.
4. Identify internal use cases by checking functions that must be periodically performed.
5. Draw use case diagrams and activity diagrams for use cases.
6. Take the context diagram, use case diagrams, and activity diagrams as communication model to validate requirements with customers.

SPECIFICATION COMPONENT IDENTIFICATION
Primary specification components in our technique include:

1. Classes, including their attributes and operations,
2. Class relationships, including inheritance, composition, utilization, and association relationships,
3. Object behaviors of classes,
4. Object interactions,
5. Use cases (functions) and their detailed operations, and
6. Grouping of classes and use cases.

From past experience we found that: 1) classes and their attributes and operations are generally not easy to identify, and 2) classes may be difficult to differentiate from attributes, because both are separated from data. The problems are solved by our technique as described below.

Identify and differentiate classes and attributes using data hierarchies²¹: Generally, classes and attributes can be distinguished from data.^{15, 21} However, before determining whether data can be transformed into classes or regarded as attributes, we must first discuss data decomposition. The rationale is that our technique distinguishes classes and attributes from data decomposition results.

Figure 2. Data relationships.

Data in a system should be decomposed if their components are operated on by some operation. For example, the datum "Car" in a car repairing system should be decomposed, because its components such as "Engine" and "Wheel" will be operated on (i.e., repaired). Components of data may be further decomposed if necessary. For example,"Engine" in a car repairing system should be further decomposed, because its components such as"Fuel injector" and "Piston" will also be repaired. As depicted in Figure 2, after decomposition certain data relationships including sequence, iteration, and selection may exist between a datum and its components, as described next³⁰:

1. Sequence relationships indicate that a datum contains one copy of its components. For example, Figure 2(a) indicates that "Paper" contains one copy of "Abstract," one copy of "Main text," and one copy of "References."
2. Iteration relationships indicate that a datum contains multiple copies of its components. For example, Figure 2(b) indicates that"Main text" contains multiple copies of "Section."
3. Selection relationships indicate that a datum is a generalization of its components. For example, Figure 2(c) indicates that "Paper" is a generalization of "Conference_paper" and "Journal_Paper."

The data relationships just mentioned can be used to structure data and their components. Since data components can be further decomposed, a datum may be decomposed into a hierarchy called data hierarchy. Figure 3 shows the data hierarchy of the datum "Car" in a car repairing system.

Figure 3. Data hierarchy for 'Car' in car repairing system.

Having discussed data decomposition, let us check which data can be transformed into classes and which into attributes. Generally, a datum can be transformed into a class if its attributes are operated on by some operation, because classes encapsulate attributes and the operations operating on those attributes.²¹ That is, data that have been decomposed can be transformed into classes, while those that have not should be regarded as attributes of a class. For example, the datum "Engine" in Figure 3 can be transformed into a class by encapsulating its components (which are regarded as attributes) and the operations operating on the components. On the other hand, the datum "Engine" in Figure 4 cannot be transformed into a class. Instead, it should be regarded as an attribute of "Car."

Figure 4. Data hierarchy for 'Car' in a car selling system.

According to the previous description, our technique regards the datum in a leaf node of a data hierarchy as an attribute of its parent, and transforms a non-leaf node into a class by encapsulating its attributes and the operations operating on the attributes. For example, "Engine," "Model," and so on, in Figure 4 are regarded as attributes of "Car." On the other hand, "Car" in Figure 4 is transformed into a class by encapsulating the following attributes and the operations operating on them: "Producer," "Model," "Price," "Engine," and "Horsepower." Note that the datum in a non-leaf node cannot be regarded as an attribute of its parent because the datum itself can be transformed into a class. In this case, the class transformed from a non-leaf node should be regarded as a part class of the class transformed from its parent. For example, the class "Engine" transformed from the datum "Engine" in Figure 3 is a part class of the class "Car" transformed from the datum "Car" in the same figure. In this regard, data hierarchies can be used to identify class composition relationships (this will be described later).

Identify class operations from CRC cards: Class operations correspond to class responsibilities in a software system. Since CRC cards facilitate identifying responsibilities, those cards can be used to identify class operations. According to this consideration, our technique constructs a CRC card for each class and identifies class operations from class responsibilities. CRC cards also facilitate identifying using and association relationships among classes (discussed later).

According to the previous description, our technique identifies most specification components from data hierarchies and CRC cards. The specification component identification process in our technique contains the following steps: 1) construct data hierarchies, 2) identify classes, attributes, and class relationships from data hierarchies, 3) construct CRC cards, 4) identify class operations and class relationships from CRC cards, and 5) describe object behaviors of classes. In the following subsections, the steps mentioned above are respectively described.

Figure 5. Activity diagram showing data used by activities.

Construct data hierarchy
To construct data hierarchy, data should first be identified. Data can be distinguished from customer requirements, whose detailed operations are represented in activity diagrams, after requirement capturing. Therefore, in constructing data hierarchies, data used by activities of activity diagrams are first identified. Then, related data are structured using these relationships: sequence, iteration, and selection. For example, the activity diagram in Figure 1(b) is redrawn in Figure 5, in which data used by an activity are listed besides the activity (in italic). From the data listed in Figure 5, the data hierarchies shown in Figure 6 can be constructed.

Figure 6. Partial data hierarchies identified from Figure 5.

In identifying data from activity diagrams, complicated activities can be decomposed (refined) if necessary. For example, the activity "Check item list" in Figure 5 can be decomposed into the activity diagram shown in Figure 7. With the decomposition, new data may be identified (see Figure 7), which should be added to the data hierarchies (see Figure 8). Note that in Figure 7, the starting circle is labeled with "Check item list," which is the name of the activity being decomposed. Therefore, starting circles of activity diagrams show the decomposition relationships among activity diagrams.

Figure 7. Decomposing the activity "Check item list."

Figure 8. Refined data hierarchies.

Identify classes, attributes, and class relationships from data hierarchies: Leaf nodes in data hierarchies are regarded as attributes of their parents, and non-leaf nodes are transformed into classes. Data relationships affect attribute characteristics, as described below.

1. Sequence relationships define single-valued attributes. For example, "Item_ID" in Figure 8 is a single-valued attribute of "In_delivery_item."
2. Iteration relationships define multiple-valued attributes. For example, "Spark plug" in Figure 3 is a multiple-valued attribute of "Engine."
3. Selection relationships could not exist between a class and its attributes, because the relationships depict that a parent is a generalization of its sons. The sons should thus possess different attributes. Accordingly, the sons should be further decomposed. For example, in Figure 2(c), the nodes "Conference_paper" and "Journal_paper" are different. The difference is reflected in their components after decomposition.

Data hierarchies can also be used to identify composition and inheritance relationships, which exist between a non-leaf node and its no-leaf sons, as described next.

1. If a non-leaf node has other non-leaf nodes as sons and sequence relationships exist among the sons, then one-to-one composition relationships exist between the class transformed from the parent and the classes transformed from the sons. For example, in Figure 8, a one-to-one composition relationship exists between the classes "In_delivery" and "In_item_list."
2. If a non-leaf node has another non-leaf node as a son and an iteration relationship exists between them, then a one-to-many composition relationship between the class transformed from the parent and that transformed from the son. For example, in Figure 8, a one-to-many composition relationship can be identified between the classes "In_item_list" and "In_delivery_item."
3. If a non-leaf node has other non-leaf nodes as sons and selection relationships exist among the sons, then inheritance relationships exist between the class transformed from the parent and the classes transformed from the sons. For example, in Figure 2(c), inheritance relationships can be identified between the class "Paper" and the classes "Conference_paper" and "Journal_paper."

Construct CRC cards: In this step, a CRC card is constructed for each class. The responsibilities and collaborators of a class can be identified from customer requirements represented in activity diagrams. For example, from the activity diagram shown in Figure 7, the CRC card of the class "In_delivery_item" can be constructed as Figure 9.

Figure 9. CRC card for the class "In_delivery_item."

Identify class operations and class relationships from CRC cards: Guidelines for identifying class operations from responsibilities of CRC cards are listed next.

1. If a responsibility only uses attributes of one class, the responsibility can be transformed into an operation of that class. For example, suppose that the responsibility "Get delivery quantity" in Figure 9 uses the attribute "Delivery_quantity" of the class "In_delivery_item." Then, that responsibility can be transformed into the operation "Get_delivery_quantity" of that class.
2. If a responsibility uses attributes of multiple classes, the responsibility can be transformed into multiple operations, each belongs to a class. For example, suppose that the responsibility "Check quantity" in Figure 9 checks whether the attributes "Delivery_quantity" and "Order_quantity" are equal, in which those attributes belong to the classes "In_delivery_item" and "Out_order_item," respectively. Then, the responsibility can be transformed into the operations "Get_delivery_quantity" and "Check_delivery_quantity" for the class "In_delivery_item," and the operation "Get_order_quantity" for the class "Out_order_item."
3. If a responsibility is complicated, it should be decomposed. For example, the responsibility of an analyst is to analyze requirements. That complicated responsibility can be decomposed into simpler responsibilities such as "Requirement capturing," "Specification component identification," and so on.

CRC cards also facilitate identifying association and using relationships among classes. Those relationships can be identified from the "Collaborator" field of the cards. Generally, there are association relationships between a class and its collaborators. For example, an association relationship between the classes "In_delivery_item" and "Out_order_item" can be identified from Figure 9. Moreover, if a class invokes a collaborator's operations, a using relationship exists between them. For example, in Figure 9, if an operation of the class "In_delivery_item" invokes an operation of the class "Out_order_item," then a using relationship can be identified between those classes.

Describe object behaviors of classes: The object behaviors of a class facilitate understanding that class. It seems unnecessary to describe object behaviors for all classes.¹⁹ Our technique suggests describing object behaviors of complicated classes only.

Object behaviors are normally represented by state transition diagrams.^1,11 To construct a state transition diagram, object states and state transitions should be identified. Generally, object states consist of object attribute values and state transitions are caused by executing class operations. Therefore, object states and state transitions can be distinguished from attribute values and class operations, respectively.

It is possible that a class contains an infinite number of attributes. For example, the stock level of a sell item may be zero, one, two, and so on. This will result in an infinite number of states, which causes difficulty in drawing a state transition diagram. To solve this problem, the concept of a macro state can be used. That is, multiple states can be grouped into a macro state. This simplifies the state transition diagrams. For example, the states of a sell item can be grouped into the macro states "safe" and "unsafe," where the former means that its stock level is not less than its re-order level and the latter means otherwise. Figure 10 is a state transition diagram for the class "Item," where the macro states "safe" and "unsafe" are used.

Figure 10. State transition diagram for the class "Item."

SPECIFICATION REPRESENTATION
Most notations used in our technique are from UML. Specification components represented in our technique are described next.

Figure 11. Class diagram.

Figure 12. Sequence diagram.

1. A class diagram is used to represent classes and their relationships. Figure 11 shows a class diagram, where an arrow-headed line represents a using relationship between two classes. If necessary, class attributes and operations can also be shown in the diagram.²²
2. State transition diagrams are used to describe object behaviors of classes. Figure 10 shows the state transition diagram for the class "Item."
3. Interaction diagrams (i.e., sequence diagrams or collaboration diagrams) are used to represent object interactions.²² Figure 12 is a sequence diagram showing the interactions between objects to accomplish the use case "Deliver items." The diagram shows that when ordered items are delivered, the following should be checked against the original order: a) the total price listed in the receipt and b) the delivery quantity listed in the delivery item list.
4. Use case diagrams are used to show use cases (functions). Figure 13 shows use case diagrams, in which three use cases are initiated by actors and the other one is an internal use case.
5. Activity diagrams are used to represent detailed operations of use cases. See Figure 1 for a use case and its corresponding activity diagram. In an activity diagram, complicated activities can be decomposed into more detailed activity diagrams. For example, the activity "Check item list" in Figure 5 can be decomposed into the diagram in Figure 7. Decomposing complicated activities results in hierarchies of activity diagrams, which facilitate understanding use cases. That is, to understand a use case, the top activity diagram is first examined. The more detailed activities can then be understood by following the activity diagrams after decomposition.
6. Package diagrams are used to group classes when many classes exist in a specification. In addition, subsystem diagram is provided for grouping use cases into subsystems. Figure 14(a) shows the notation for a subsystem diagram, in which use cases of the subsystem are listed. Figure 14(b) shows the subsystem "Supermarket management system" that contains the following use cases: "Check stock levels," "Buy items," "Deliver items," and "Order items." Note that subsystem diagram is not included in the UML.

Figure 13. Use case diagram.

Figure 14. Subsystem diagram and system-subsystem hierarchy.

Having grouped use cases, if there are many subsystems obtained, they can be further grouped. The grouping ended when all subsystems (or use cases) are finally grouped into a system. The grouping thus results in a system-subsystem hierarchy (see Figure 14[c]).

According to the previous description, a specification represented in our technique is composed of: 1) a system-subsystem hierarchy, 2) subsystem diagrams, 3) use case diagrams, 4) activity diagrams in which activities may be decomposed into more detailed activity diagrams, 5) a class diagram, 6) state transition diagrams, 7) interaction diagrams, and 8) package diagrams.

To trace a specification represented in our technique, the system-subsystem hierarchy is first examined to get an overview of the specification. Next, the individual subsystem diagrams are traced to identify use cases in a subsystem. Then, use case diagrams and their corresponding activity diagrams are examined. With the above trace, the functions of the specification can be understood. To understand how the functions are implemented by classes, the class diagram, package diagrams, interaction diagrams, and state transition diagrams are then traced.

PROCESS OF THE TECHNIQUE
According to the description in sections 2 through 4, process for our OOA technique is composed of the following steps. Note that the steps do not follow a waterfall sequence. They can be iterated if necessary.

Step 1: Capture requirements with the following process:

1. Identify actors.
2. Draw a context diagram, where an actor corresponds to an external entity.
3. Identify use cases from actor perspectives.
4. Identify internal use cases by checking functions that must be periodically performed.
5. Draw use case diagrams and activity diagrams for use cases.
6. Take the context diagram, use case diagrams, and activity diagrams as communication model to validate requirements with customers.

Step 2: Identify specification components with the following process:

1. Identify data used in activity diagrams, refine activity diagrams if necessary, and draw data hierarchies.
2. Identify classes, attributes, and inheritance and composition relationships from data hierarchies.
3. Construct a CRC card for each class.
4. Identify class operations, and association and using relationships from the CRC cards.
5. Identify object states and state transitions for describing object behaviors of classes.

Step 3: Represent specification components as follows:

1. Represent use cases and their detailed operations in use case diagrams and activity diagrams, respectively.
2. Represent subsystems in subsystem diagrams.
3. Represent system-subsystem relationships with a system-subsystem hierarchy.
4. Represent classes and their relationships in a class diagram.
5. Represent object behaviors of classes in state transition diagrams.
6. Represent object interactions in interaction diagrams.

AN EXAMPLE
A simplified supermarket system is used here as an example. Its requirements are described next.

The system manages stock levels and re-order levels of sell items. It periodically checks stock levels. If the stock level of an item is under its re-order level, the manager orders the item from a supplier. Having issued an order to the supplier, the supermarket expects to receive a delivery package containing the ordered items, a receipt, and an item list. The system checks the receipt and item list against the original order. It then increases stock levels by the received quantities.

When a customer buys items (i.e., the customer issues an order to the supermarket), the system creates a receipt and an item list. The receipt and the list together with the ordered items constitute a delivery package for the customer. The system then decreases the stock levels by the sold quantities.

The OOA process for the simplified supermarket system is described in the following subsections.

Requirement capturing
This step begins with identifying actors (external entities) and drawing a context diagram. The following three actors are identified: "Customer," "Supplier," and "Manager." The context diagram is drawn in Figure 15.

Figure 15. Context diagram for the supermarket management system.

The actor perspectives are then taken to identify use cases. Moreover, internal use cases are also identified. Table 1 and Figure 13 show the use cases identified and their corresponding use case diagrams.

Table 1. Use cases of the supermarket management system.

The use cases are then described using activity diagrams. To simplify this example, only the activity diagrams for the use cases "Deliver items" and "Check stock levels" are shown (see Figures 1(b) and 16).

Figure 16. Activity diagram for the use case "Check stock levels."

Figure 17. Data used in the use case "Check stock levels."

Specification component identification: The following steps are used to identify specification components.

1. Construct data hierarchies.
   Data used by activities are first identified. Figures 5 and 17 respectively show the data used by the activities in the use cases "Deliver items" and "Check stock levels" (data are shown in italic). If necessary, complicated activities can be decomposed and more data can be identified. Figure 7 is obtained by decomposing the activity "Check item list" in Figure 5. The identified data are then structured into data hierarchies. Figure 18 shows the data hierarchies obtained.
2. Identify classes, attributes, and class relationships from data hierarchies. Classes and attributes identified are listed in Table 2. Since some classes are quite similar, classes are thus combined. Table 3 shows the classes after combination. Note that to clarify Table 3, class operations, which will be identified latter, are also shown. In addition to classes and attributes, the following composition relationships are also identified from the data hierarchies: a) that between "Delivery" and "Item_list," b) that between "Delivery" and "Receipt,t" c) that between "Item_list" and "Delivery_item," and d) that between "Order" and "Order_item."
3. Construct CRC cards.
   A CRC card is constructed for each class, where class responsibilities are identified from activity diagrams. To simplify this example, only the CRC cards for "Delivery" and "Delivery_item" are shown (Figure 19).

Figure 18. Data hierarchies for the supermarket management system.

Table 2. Classes and attributes identified.

Table 3. Classes after grouping.

Figure 19. CRC cards.

Identify class operations and class relationships from the CRC cards: CRC cards are used to identify class operations. See Table 3 for the class operations identified. Moreover, the following using relationships are also identified from the CRC cards: a) that between "Delivery" and "Failure_report," b) that between "Delivery" and "Checking_report," c) that between "Receipt" and "Order," d) that between "Delivery_item" and "Order_item," and e) that between "Order" and "Item."

Describe object behaviors of classes: A class can be associated with a state transition diagram to show its object behavior. For example, Figure 10 shows the object behavior of the class "Item."

CONCLUSION
This article proposes a new OOA technique. It enhances our previous technique, which is based on parallel decomposition of function and data. The process of the proposed technique integrates several requirement analysis processes. Therefore, our technique is expected to possess the strengths of multiple requirement analysis processes. Primary features of our technique are described next.

1. It facilitates capturing real requirements.

   The technique uses function-viewed notations to facilitate requirement capturing, including context diagram, use case diagrams, and activity diagrams. A context diagram defines the boundary of the system being analyzed, and shows the system's actors from whose perspectives use cases can be identified. Use case diagrams show functions of the system. And, activity diagrams show detailed operations of use cases.

   During requirement capturing, the diagrams just mentioned are used as communication model between analysts and customers. Since customers normally provide requirements from the functional aspect, using those function-viewed diagrams as communication model seems to facilitate capturing real requirements.

2. It facilitates identifying specification components, especially classes and their attributes and operations.

   To identify classes and attributes, our technique first identifies data and structures them into data hierarchies using the following relationships: sequence, iteration, and selection. It then regards leaves of data hierarchies as attributes of their parents, and transforms each non-leaf into a class by encapsulating its attributes and the operations operating on the attributes. To identify class operations, the technique first constructs CRC cards for classes, and then transforms class responsibilities recorded in the cards into class operations.

3. Most notations used in the proposed technique are from the well known and widely used UML. Therefore, the technique is expected to be easy to use.

Acknowledgments
This research is sponsored by the National Science Council in Taiwan under grant number NSC88-2213-E-009-012.

REFERENCES

1. Coad, P. and E. Yourdon. Object-Oriented Analysis, 2nd ed., Prentice Hall, Upper Saddle River, New Jersey, 1991.
2. Chen, J.Y. and Y.T. T. Chen. "A New Object-Oriented Method Integrating Jackson Structured Programming Method," Journal of Systems and Software, 24( 2):125–137, 1994.
3. Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach, Addison–Wesley, Reading, MA, 1992.
4. Bailin, S. C. "An Object-Oriented Requirements Specification Method," Communication of the ACM, 32(5):608–623, 1989.
5. Chen, J.Y. and Y.S. Hung. "An Integrated Object-Oriented Analysis and Design Method Emphasizing Entity/Class Relationship and Operation Finding." Journal of Systems and Software, 24(1):31–47, 1994.
6. Embley, D.W., B. D. Kurtz, and S. N. Woodfield. Object-Oriented Systems Analysis, A Model-Driven Approach, Yourdon Press, New Jersey, 1992.
7. Graham, I. "Migration Using SOMA: a Semantically Rich Method of Object-Oriented Analysis," Journal of Object Oriented Programming, 5(9):31–42, Feb. 1993.
8. Lee, S. and D. L. Carver. "Object-Oriented Analysis and Specification: A Knowledge Base Approach," Journal of Object-Oriented Programming, 3(5):35–43, Jan. 1991.
9. Martin, J. and J. Odell. Object-Oriented Analysis and Design, Prentice Hall, Upper Saddle River, New Jersey, 1992.
10. Shlaer, S. and S. J. Mellor. Object Lifecycles, Modeling the World in States, Yourdon Press, New Jersey, 1992.
11. Rumbaugh, J., et. al. Object-Oriented Modeling and Design, Prentice Hall, Upper Saddle River, New Jersey, 1991.
12. Poo, D. C. C. "Adapting and Using JSD Modeling Technique as Front-End to Object-Oriented Systems Development," Information and Software Technology, 33:466–476, 1991.
13. Poo, D. C. C. "An Object-Oriented Software Requirements Analysis Method," International Journal of Software Engineering and Knowledge Engineering, 2(1):145–168, 1992.
14. Hayes, F. and D. Coleman. "Coherent Models for Object-Oriented Analysis," Proceedings of the Conference of Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'91), 171–183, 1991.
15. Meyer, B. Object-Oriented Software Construction, Prentice Hall, Upper Saddle River, New Jersey, 1988.
16. Booch, G. "Object-Oriented Development," IEEE Transactions on Software Engineering, 12(2):211–221, 1986.
17. Drake, J. M., W. Xie, and W. T. Tsai. "Document-Driven Analysis: Description and Formalization," Journal of Object-Oriented Programming, 5(7):33–50, Nov./Dec. 1992.
18. Jalote, P. "Functional Refinement and Nested Objects for Object-Oriented Design," IEEE Transactions on Software Engineering, 15(3):264–270, 1989.
19. Booch, G. Object-Oriented Analysis and Design with Applications, 2nd ed., The Benjamin/Cummings Publishing Company, Inc., 1994.
20. Robin K. S. and A. Goldberg, "Object Behavior Analysis," Communications of the ACM, 35(9):48–62, 1992.
21. Chou, Shih-Chien and Jen-Yen Chen. "An Object-Oriented Analysis Method Based on Parallel Decomposition of Function and Data," Report on Object Analysis and Design (ROAD), 2(6):22–35, Mar./Apr. 1996.
22. Fowler, Martin and Kendall Scott. UML Distilled, Applying the Standard Object Modeling Language, Addison–Wesley, Reading, MA, 1997.
23. Chen, Jen-Yen Jason. "CSPL: An Ada95-Like, Unix-Based Process Environment," IEEE Transactions on Software Engineering, 23(3):171–184, Mar. 1997.
24. Jen-Yen Jason Chen and Shih-Chien Chou. "Enacting Object-Oriented Methods by a Process Environment," Information and Software Technology, 40(5-6):311–325, 1998.
25. Ana, M., D. Moreira and Robert G. Clark. "Adding Rigour to Object-Oriented An-alysis," Software Engineering Journal, 11(5):270–280, Sept. 1996.
26. Belkhouche, B. and A. M. Gamino. "Object-Oriented Analysis Through a Knowledge-Based System," Journal of Object-Oriented Programming, 11(7):52–59, Nov./Dec. 1998.
27. Yourdon, E. Modern Structured Analysis, Prentice Hall, Upper Saddle River, New Jersey, 1989.
28. Wilkinson, Nancy M. Using CRC Cards, An Informal Approach to Object-Oriented Development, SIGS Books, New York, 1995.
29. Pressman, R. S. Software Engineering: A Practitioner's Approach, 3rd ed., McGraw Hill, 1992.
30. Cameron, J. R. Tutorial JSP & JSD: The Jackson Approach to Software Development, IEEE Computer Society Press, 1983.