Object oriented analysis and design

\seindex{analysis} \seindex{software life-cycle} In the previous section we have given an inventory of the mechanisms provided by object oriented programming languages and we have indicated the possible use of these mechanisms in the enterprise of object oriented modeling. The question we wish to raise now is what influence object oriented technology may exert on the software life cycle and what issues play a role in object oriented analysis and design. \nop{ Traditionally, the software life cycle is subdivided in an analysis phase in which the requirements for a system are laid down, a design phase in which a conceptual architecture for a system meeting the requirements put forward in the analysis phase is proposed, an implementation phase in which the conceptual structure resulting from the design phase is embodied in actual software and an operational phase that includes installing and maintenance of the system. The transition from one phase to the next usually involves a significant effort of translating the results into the formalism appropriate to that phase. The use of object oriented techniques in the design and implementation phase has resulted in a shift of emphasis in favor of the design phase since the effort of implementing a system in an object oriented programming language on the basis of an object oriented design may be regarded as a process of refining the decisions laid down in the design. The use of object oriented techniques has thus effectively reduced the gap between the concept-oriented world of design and the technology-oriented world of implementation. C.f.  [WWW90] and  [Meyer88]. } \nop{ The central guideline in developing an object oriented program comes down to the advice to construct an (object oriented) model of the problem domain. Object oriented modeling is also the main activity in (an object oriented approach to) the rquirement analysis and the design of a system. }

Object oriented analysis

The main issue in the analysis phase is to extract the needs of the person or organization for which the software will be developed. Analysis is not so much concerned with the development of the system as with an adequate description of the problem domain, to enable the problem to be solved. A basic requirement to any analysis method is that it provides the means to handle the complexity of the underlying problem domain. In  [CY90] some currently used analysis methods, such as functional decomposition, the data flow approach and semantic modeling are discussed and compared with object oriented analysis. Functional decomposition amounts to breaking up the problem into functional steps that have to be carried out to complete the task. The data flow approach primarily models the flow of information and the events that are of influence on this flow. Information (or semantic) modeling comes closest to an object oriented approach, since it models the objects occurring in the domain, their attributes and their relationships. \seindex{information modeling} Object oriented analysis may be regarded as extending the information modeling approach by providing the means to model not only the attributes but also the behavior of the entities occurring in the domain and by the use of inheritance to elucidate the conceptual relationships between these entities. Both the information modeling approach and the object oriented approach aim at modeling the problem domain, by identifying the objects that exist in that reality. \oopindex{object identification} \seindex{linguistic analysis} \seindex{requirements} As a possible method to identify the proper objects,  [Booch86] and  [WWW90] suggest a linguistic analysis of a (written down) natural language account of the requirements. As a first attempt, objects are suggested by thinking of objects that correspond to the nouns occurring in the document and of operations or methods to correspond with the verbs used. Clearly, such a method provides only a first step towards a model or a design. \oopindex{modeling} \seindex{modeling} \seindex{rapid prototyping} A major advantage of a modeling approach to analysis is that it facilitates the communication with domain experts, since these may be supposed to be well-acquainted with the objects that constitute the problem domain.\ftn{ In contrast, domain experts are usually not well-acquainted with the methods used in functional decomposition or the data flow approach, nor are they generally willing to acquire that expertise. } Another advantage of the modeling approach is that it allows for rapid prototyping. In particular in cases where there is a continual change of user requirements, prototyping may be helpful in establishing these requirements. \nop{ Evidently, communication with domain experts plays a crucial role in successfully completing the analysis phase. }

Object oriented design

\seindex{design} After completing the analysis phase, the next step is to design the system. Applying an object oriented approach, the transition between the analysis phase and the design phase may be rather smooth. The objects comprising the design may (to a certain extent) be thought of as refining the object identified during analysis. Similarly, when using an object oriented language, the objects actually implemented may be considered as a further refinement specifying the implementation details. In addition, however, to the object identified in the analysis phase, objects will play a role in the design for which no clearly identifiable counterpart exists in reality. As an example of such objects, think of the objects that are needed to develop a (graphical) user interface. Also, objects may be present that embody hypothetical entities of the domain. For instance, in a medical expert system objects may be used to define the reasoning capabilities of the experts in a domain-independent manner. These objects do not exist in reality, but are artefacts needed to explain the functional behavior of the entities involved. An example of a very elementary design method is the method introduced in  [BC89]. \oopindex{CRC cards} \seindex{CRC cards} The authors propose the use of so-called CRC-cards. An example of such a card (approximately the size of a small postcard) is pictured below. \fboxClassname & Collaborators \\ Responsibilities & \vspace{3cm} \\ \hline \end{tabular} The abbreviation CRC stands for Class, Responsibility and Collaborators. One such card may be used to describe the responsibilities of a particular class (of objects) and to indicate what kind of object classes are needed to provide the services listed under the responsibilities of the (object) class. The design of a system consists of a collection of such cards, one for each class. The authors report that the use of these cards facilitates the design, in particular when working in groups; and, perhaps more importantly, that such a card design may be conveniently used to explain the design of a system to others. Using these cards, the dynamic operation of a system may be mimicked by selecting the appropriate card whenever a particular service is needed. Surprisingly simple, yet apparently quite effective. A similar method is proposed in  [CY90]. As an example of the use of CRC-cards we will discuss the design of the classes underlying the user interface of Smalltalk programs. The approach taken by the designers of the Smalltalk system has become known as the MVC-paradigm. The basic postulate in this approach is that the classes describing the functionality that is needed to solve a problem must be separated from the classes that implement the interaction with the user. The class describing the problem related functionality is known as the model. Smalltalk provides a class Model that incorporates the methods needed to specify the other classes in an independent way. A CRC-card describing the class Model is pictured below. {\mbox{}\hspace{1cm}\begin{tabular}{|p{5cm}|p{4cm}|} \hline \fboxModel & \\ Maintain problem-related info.\nl Broadcast change information. & ... \\ \hline \end{tabular}} A model class is defined as a subclass of Model. To enable the (graphic) display of a model, a view class must be associated with the model. To factor out the display, the model maintains a list of dependents of which the view object is a member. When the state of the model is changed, then the model notifies the objects in its list of dependents to allow these objects to update the information they have of the model. The functionality of a view class is rendered by the CRC-card depicted below. {\mbox{}\hspace{1cm}\begin{tabular}{|p{5cm}|p{4cm}|} \hline \fboxView & \\ Render the model.\nl Transform coordinates. & Controller \n Model \\ \hline \end{tabular}} Apart from the possibility of displaying its state, a model may need input from the user. In the MVC-paradigm, obtaining user input is delegated to a so-called controller object. A controller object in its turn cooperates with both the model and the view. An additional function of a controller object is to distribute the control in response to the input from the user. The functionality of a controller is summarized in the CRC-card depicted below. {\mbox{}\hspace{1cm}\begin{tabular}{|p{5cm}|p{4cm}|} \hline \fboxController & \\ Interpret user input.\nl Distribute control. & View \n Model \\ \hline \end{tabular}} A model may allow for a variety of views and a variety of ways to obtain user input. Hence, to each model may correspond a multiple of view--controller pairs. A design by CRC-cards may be regarded as a first attempt at modeling a real system. It presents, when properly documented, an overview of the design of the system that may be used to explain the decisions taken. However, it lacks the details needed to provide an adequate model that gives insight in the behavioral aspects of the system. \nop{ The example above shows that CRC-cards may be helpful in giving an outline of the design. However, as observed by the authors, an explanation needs to accompany such a design to make it understandable. }

Object oriented modeling

In an object oriented system, computation amounts to sending messages among objects.  [Booch86] identifies the roles that objects may play in such a system. An object may be an actor that operates by sending requests to other objects but provides no services. An object may be a server that may be requested to perform some task. The most usual case, however, is that an object both suffers and requires actions. These objects, called agents in  [Booch86], need as well as provide services. \id{ With regard to the distinctions made, we may want to phrase the design guideline {\it `minimize and localize dependencies among objects'} as a recommendation to maximize the number of actors and servers in a system, under the proviso that no more objects are introduced than necessary. } \oopindex{concurrency} An important advantage of an object oriented approach is that objects allow for a natural introduction of concurrency. A client of an object does not have to be aware of whether the object has activity of its own or is passive and only activated to respond to a message. In contrast, when applying a functional decomposition method to design a system the introduction of concurrency requires to reorganize the modular structure of the program, since modules there represent the major computation steps. The central guideline in developing an object oriented program comes down to the advice to construct an (object oriented) model of the problem domain. Object oriented modeling is hence the main activity in (an object oriented approach to) the requirement analysis and the design of a system.