Methods and tools

Object oriented software development is a relatively new technology. Consequently, ideas with respect to methodologies supporting an object oriented approach are still in flux. Nevertheless, a plethora of methods and tools does exist supporting object oriented analysis and design. Some of these methods (and corresponding tools) directly stem from a more conventional approach to software development. Others are more radical and propose new tools to support the decomposition principles underlying object oriented technology. Naturally, those who wish to make a gradual shift from conventional technology to adopting an object oriented approach may benefit from methods that adapt familiar techniques to the new concepts. Having studied the principles underlying object-based architectures and object oriented design, we may now well look at a variety of existing methods and the tools they offer. We will not discuss the tools and diagram techniques used in any detail. For the reader this section may, however, supply an overview and the references needed for a more detailed study of a particular method or tool. First we will look at the techniques offered by structured methodologies, next we will discuss how a transition towards an object oriented approach is reflected in methods for requirements engineering. Lastly, we will look at methods and tools proposed for object oriented design. Our treatment is to a large extent based on  [Fichman].

Structured methods

Initially, structured methods (which were develeped the beginning of the 1970s) were primarily concerned with modeling processes in a modular way. Based on software engineering principles such as module coupling and chohesion, tools were developed to represent the structure of a design (within what we have previously called the procedural or modular paradigm).  [Yourdon79]. Apart from diagrams to describe the modular architecture of a system, the method proposed also to use data flow diagrams to depict processes and the flow of data between them, and hierarchy diagrams to model the structure of the data involved.

Tools for structured methodologies

Later, structured methods were extended to encompass analysis, and the focus shifted to modeling the data by means of entity-relationship diagrams and data dictionaries. Also state transition diagrams were employed to represent the behavioral aspects of a system. As observed in  [Fichman], {\em in the late 1970s and early 1980s, planning and modeling of data began to take on a more central role in system development, culminating in data oriented methodologies, such as information engineering} (which may be regarded as precursors to object oriented methods). Information engineering, however, is primarily concerned with analysis and strategic planning. In addition to the modeling techniques mentioned, tools were developed to model the information need of an enterprise and to perform risk analysis. Also, extensions to the data dictionary were proposed in order to have an integrated repository, serving all phases of the development. Currently, repository based techniques are again of interest since, in combination with modern hypermedia technology, they may serve as the organizational basis for reuse.

Requirements engineering

In  [Fichman] a comparative review of a selected number of object oriented analysis methods is given. Criteria for selection were the availability of documentation and acceptance in the object oriented community, measured in terms of refereed articles.  [Yourdon89],  [Shlaer88],  [Shlaer92]. Paraphrasing  [Fichman] again: As with traditional analyis, the primary goal of object oriented analysis is the development of an accurate and complete description of the problem domain. The three analysis models described in  [Fichman] share a number of diagram techniques with both structured methods and methods for object oriented design. However, in particular the method proposed in  [Shlaer88] reflects the domain oriented focus of analysis.

Tools for object oriented analysis

Among the diagram techniques offered by the {\sl Shlaer and Mellor} method we find for instance a domain chart to depict the various domains constituting the model. These domains include the application, the services offered, architectural issues and the implementation constraints. To depict the relation between the various submodels (corresponding to the subsystems of the application) a subsystem relationship model may be used. Action-dataflow diagrams are used to model the events that may occur. In contrast to traditional dataflow and process-structure diagrams, these diagrams do not intent to provide a hierarchical model or functional decomposition, but instead are employed to model elementary processes. To model the objects in the domain and their relations information structure diagrams, a variant of entity-relationship diagrams, may be used. In addition explicit object attribute descriptions may be used as well as diagrams modeling synchronous access and asynchronous communication between objects. To model the dynamic characteristics of the domain, state models (resembling state-transition diagrams) may be used. However, in contrast to state transition diagrams as used in structured methods, state models are intended to characterize the behavioral changes of domain entities. }

Tools for design

As phrased in  [Fichman], design is the process of mapping system requirements defined during analysis to an abstract representation of a specific system-based implementation meeting cost and performance constraints. In other words, design is concerned with architectural issues whereas analysis is concerned with requirements and constraints. Although different in objective, in an object oriented approach analysis and design may share a common object model. Both in the method proposed by  [CY91b] and the method proposed in  [Booch91], the difference between analysis and design lies primarily in the level of detail in which the respective components of the system are specified. Below a number of the diagram types proposed in  [Booch91] are listed.

Tools for object oriented design

Apart from class diagrams and templates to describe the functionality of classes and their (static) relations to other classes, the methods uses also uses object diagrams (and templates) to characterize the dynamic behavior of (collections of) objects. Moreover, the method provides for techniques to depict the relations between modules and to describe the physical architecture of distributed systems. As additional techniques to describe the behavioral characteristics of object,  [Booch91] employs state-transition diagrams and timing diagrams (expressing constraints on the order in which methods may be invoked). These diagram techniques have as a common objective to represent the important properties and aspects of a design. Along the dimensions by which we may classify design representation technologies, expressiveness and formality, object oriented technology may be ranked as being midway between non-formal, highly expressive techniques such as hypertext and highly formal (logic-based) techniques which require a lot of expertise to express relationships and properties. However, object oriented techniques cover a broad range. For example, collaboration graphs and contracts offer (in principle) a high degree of formality, whereas many of the diagram techniques seem to be amenable to an extension with hypertext features to support browsing and the retrieval of information. A major problem that is still not satisfactorily solved by any of the existing methods, is to support what may be called the harvesting of reuse, that is the actual exploitation of the potentiality of reuse that is intrinsic to object oriented technology. Both at the level of analysis and design, a repository-based approach to managing reuse (in combination with appropriate retrieval techniques) seems to be the most promising. Another issue about which opinions diverge is by what principles objects should be clustered, and what techniques must be provided to support system partitioning. Perhaps the solution to these problems is not strictly a matter of technology but instead requires us to wait for appropriate conventions and styles to emerge within each particular application domain.