Analysis and design models cannot be tested in the conventional sense, because they cannot be executed. However, formal technical reviews ...
Analysis and design models cannot be tested in the conventional sense, because they cannot be executed. However, formal technical reviews can be used to examine the correctness and consistency of both analysis and design models.
Correctness of OOA and OOD Models
The notation and syntax used to represent analysis and design models will be tied to the specific analysis and design method that is chosen for the project. Hence, syntactic correctness is judged on proper use of the symbology; each model is reviewed to ensure that proper modeling conventions have been maintained.
Correctness of OOA and OOD Models
The notation and syntax used to represent analysis and design models will be tied to the specific analysis and design method that is chosen for the project. Hence, syntactic correctness is judged on proper use of the symbology; each model is reviewed to ensure that proper modeling conventions have been maintained.
During analysis and design, semantic correctness must be judged based on the model’s conformance to the real world problem domain. If the model accurately reflects the real world (to a level of detail that is appropriate to the stage of development at which the model is reviewed), then it is semantically correct. To determine whether the model does, in fact, reflect the real world, it should be presented to problem domain experts, who will examine the class definitions and hierarchy for omissions and ambiguity. Class relationships (instance connections) are evaluated to determine whether they accurately reflect real world object connections.
Consistency of OOA and OOD Models
The consistency of OOA and OOD models may be judged by “considering the relationships among entities in the model. An inconsistent model has representations in one part that are not correctly reflected in other portions of the model”.
To assess consistency, each class and its connections to other classes should be examined. The class-responsibility-collaboration model and an object-relationship diagram can be used to facilitate this activity. The CRC model is composed on CRC index cards. Each CRC card lists the class name, its responsibilities (operations), and its collaborators (other classes to which it sends messages and on which it depends for the accomplishment of its responsibilities). The collaborations imply a series of relationships (i.e., connections) between classes of the OO system. The object-relationship model provides a graphic representation of the connections between classes. All of this information can be obtained from the OOA model .
To evaluate the class model the following steps have been recommended :
1. Revisit the CRC model and the object-relationship model. Cross check to ensure that all collaborations implied by the OOA model are properly represented.
2. Inspect the description of each CRC index card to determine if a delegated responsibility is part of the collaborator’s definition. For example, consider a class defined for a point-of-sale checkout system, called credit sale. This class has a CRC index card illustrated in figure For this collection of classes and collaborations, we ask whether a responsibility (e.g., read credit card) is accomplished if delegated to the named collaborator (credit card). That is, does the class credit card have an operation that enables it to be read? In this case the answer is, “Yes.” The object-relationship is traversed to ensure that all such connections are valid.
3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a reasonable source. For example, if the credit card class receives a request for purchase amount from the credit sale class, there would be a problem. Credit card does not know the purchase amount.
4. Using the inverted connections examined in step 3, determine whether other classes might be required and whether responsibilities are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be combined into a single responsibility. For example, read credit card and get authorization occur in every situation. They might be combined into a validate credit request responsibility that incorporates getting the credit card number and gaining authorization.
6. Steps 1 through 5 are applied iteratively to each class and through each evolution of the OOA model.
Once the OOD model is created, reviews of the system design and the object design should also be conducted. The system design depicts the overall product architecture, the subsystems that compose the product, the manner in which subsystems are allocated to processors, the allocation of classes to subsystems, and the design of the user interface. The object model presents the details of each class and the messaging activities that are necessary to implement collaborations between classes.
The system design is reviewed by examining the object-behavior model developed during OOA and mapping required system behavior against the subsystems designed to accomplish this behavior. Concurrency and task allocation are also reviewed within the context of system behavior. The behavioral states of the system are evaluated to determine which exist concurrently. Use-case scenarios are used to exercise the user interface design.
The object model should be tested against the object-relationship network to ensure that all design objects contain the necessary attributes and operations to implement the collaborations defined for each CRC index card. In addition, the detailed specification of operation details (i.e., the algorithms that implement the operations) are reviewed using conventional inspection techniques.
