Principles of Object-Oriented Software Development
[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

talk show tell print

Development methods

subsections:
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. See slide 11-methods.

Unified Modeling Language -- standard notation

UML


slide: Software development methods
 Some of these methods (and corresponding tools) directly stem from a more conventional (read structured) 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.

In this section we will look at a variety of existing methods and the tools they offer. We do not discuss the tools and diagram techniques used in any detail. However, we will discuss the Fusion method in somewhat more detail. Fusion is a strongly systematic approach to object-oriented software development that integrates various concepts and modeling techniques from the other methods, notably OMT, Booch OOD, Objectory and CRC. We will discuss the process view underlying Fusion and sketch the models it supports in relation to the other methods. For the reader this section may supply an overview and references needed for a more detailed study of a particular method or tool.

A recent development is the Unified Modeling Language (UML), which has been approved as a standard in 1998. UML brings together the models and notations featured by the various methods. Jim Rumbaugh, Grady Booch and Ivar Jacobson, all leading experts in object-oriented development, joined forces to achieve this.

The importance of such a standardization can hardly be overemphasized. However, it must be noted that UML does not provide a method, in the sense of delineating the steps that must be taken in the development of a system. UML itself may be regarded as a toolbox, providing notations and modeling techniques that may be deployed when needed. A brief overview of UML is given in UML. An excellent introduction to UML, including advice how to apply it in actual projects may be found in  [Fowler97].

Structured methods

Initially, structured methods (which were developed at 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 cohesion, tools were developed to represent the structure of a design (within what we have previously called the procedural or modular paradigm); see, for example,  [Yourdon79]. Apart from diagrams to describe the modular architecture of a system (such as structure charts and process specifications), structured methods also employ data flow diagrams to depict processes and the flow of data between them, and hierarchy diagrams to model the structure of the data involved. See slide 11-structured.

Structured methods

tools


  • structure chart
  • process specification
  • dataflow diagrams
  • hierarchy diagram
  • entity-relationship diagrams
  • data dictionary
  • state transition diagram
slide: Tools for a structured approach
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], 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 needs 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.

Perspectives of modeling

 Understanding a problem domain may be quite demanding. Understanding is even more difficult when the description of the domain is cast in some representation pertaining to the solution domain. An object-oriented approach is said to require less translation from the problem domain to the (software) solution domain, thus making understanding easier. Many proponents of an object-oriented approach, however, seem to be overly optimistic in their conception of the modeling task. From an epistemological point of view, modeling may be regarded as being essentially colored by the mechanisms that are available to express the model. Hence, rather than opposing the functional and object-oriented approach by claiming that an object-oriented approach aims at modeling reality, I would prefer to characterize the distinction in terms of (modeling from) a different vernacular, a different perspective due to different modeling mechanisms. In other words, a model is meant to capture some salient aspects of a system or problem domain. Dependent on what features are considered as most important, different means will be chosen to construct a model. Even within the confines of an object-oriented approach, there appear to be radically different perspectives of the modeling required in the various phases of the software life-cycle.

Modeling reality -- vernacular
  • requirements -- use cases
  • analysis -- domain concepts
  • design -- system architecture
  • implementation -- language support

Design model -- system oriented
  • provides a justification of the architecture
slide: Perspectives of modeling
An important contribution of  [Jacobs92] is the notion of use cases that describe the situations in which a user actually interacts with the system. Such a (use case) model is an important constituent of the requirements document, since it precisely describes what the system is intended for. For the purpose of analysis, it may be helpful to develop a more encompassing (conceptual) model of the problem domain. The advantage of such an approach is that the actual system may later easily be extended due to the generality of the underlying analysis model.

In contrast to the model used in analysis, both the design model and the implementation model are more solution oriented than domain oriented. The implementation model is clearly dependent on the available language support. Within a traditional life-cycle, the design model may be seen as a transition from analysis to implementation. The notion of objects may act as a unifying factor, relating the concepts described in the analysis document to the components around which the design model is built. However, as we have noted, object-oriented development does not necessarily follow the course of a traditional software life-cycle. Alternatively, we may characterize the function of the design document as a justification of the choices made in deciding on the final architecture of the system. This remark holds insofar as an object-oriented approach is adopted for both design and implementation. However, see  [Hend90] for a variety of combinations of structured, functional and object-oriented techniques.

Dimensions of modeling

When restricting ourselves to design models, we may again distinguish between different modeling perspectives or, which is perhaps more adequate in this context, dimensions of modeling.

In  [Rum91], it is proposed to use three complementary models for describing the architecture and functionality of a system. See slide 3-dimensions.

Dimensions of modeling -- OMT
  • object model -- decomposition into objects
  • dynamic model -- intra-object state changes
  • functional model -- object interaction (data-flow)

Model of control

  • procedure-driven, event-driven, concurrent
slide: The OMT method
The OMT method distinguishes between an object model, for describing the (static) structure of object classes and their relations, a dynamic model, that describes for each object class the state changes resulting from performing operations, and a functional model, that describes the interaction between objects in terms of a data-flow graph. An important contribution of  [Rum91] is that it identifies a number of commonly used control models, including procedure-driven control, event-driven control and concurrent control. The choice for a particular control model may deeply affect the design of the system. The OMT approach may be called a hybrid method since it employs non object-oriented techniques for describing intra-object dynamics, namely state-charts, and a functional approach involving data-flow diagrams, for describing inter-object communication.

Coherent models

The OMT object model, however, only captures the static structure of the system. To model the dynamic and functional aspects, the object model is augmented with a dynamic model, which is given by state diagrams, and a functional model, which is handled by data flow diagrams. From a formal point of view this solution is rather unsatisfactory since, as argued in  [Hayes91], it is hard to establish the consistency of the combined model, consisting of an object, dynamic and functional model.

Model criteria -- formal approach

  • unambiguous -- single meaning
  • abstract -- no unnecessary detail
  • consistent -- absence of conflict
slide: Coherent models -- criteria
Consistency checking, or at least the possibility to do so, is important to increase our belief in the reliability (and reusability) of a model. To be able to determine whether a model is consistent, the model should be phrased in an unambiguous way, that is, in a notation with a clear and precise meaning. See slide 3-coherent. Also, to make the task of consistency checking manageable, a model should be as abstract as possible, by leaving out all irrelevant details. To establish the consistency of the combined model, covering structural, functional and dynamic aspects, the interaction between the various models must be clearly defined.

Requirements engineering -- Fusion

 The Fusion method is presented in  [Fusion] as a second generation object-oriented method. The phrase second generation is meant to indicate that the method transcends and incorporates the ideas and techniques employed in the early object-oriented methods. Above all, the Fusion method focuses on a strongly systematic approach to object-oriented software development, with an emphasis on the process of development and the validation of the consistency between the models delivered in the various phases of a project. The software life-cycle model underlying Fusion is the traditional waterfall model, consisting of the subsequent phases of analysis, design and implementation. Each phase results in a number of models describing particular aspects of the system. See slide 11-fusion. A data dictionary is to be kept as a means to unify the terminology employed in the various phases.

Analysis -- Fusion

Fusion


  • Object Model -- concepts and relations
  • LifeCycle Model -- sequences of operations
  • Operation Model -- semantics of system operations

Design -- data dictionary

data dictionary


  • Object Interaction Graph -- functional dependencies
  • Visibility Graphs -- communication structure
  • Class Descriptions -- attributes and methods
  • Inheritance Graphs -- subtype refinement

Implementation -- validation

validation


  • System Lifecycle -- state machines
  • Class Descriptions -- coding, performance
slide: The Fusion method
The models produced as the result of analysis, design and implementation serve to document the decisions made during the development. Each of the phases covers different aspects of the system. Analysis serves to document the system requirements from a user perspective. The Fusion method describes how to construct an Object Model that captures the basic concepts of the application domain. These concepts are represented as entities or objects and are connected by relations, similar to entity-relationship diagrams employed in semantic modeling. Analysis also results in an Operation Model, describing the semantics of the operations that may be performed by a user by means of pre- and post-conditions, in a formal manner. In addition, Fusion defines a Lifecycle Model that describes, by means of regular expressions, which sequences of operations are allowed. Design may be considered as the transition between analysis and implementation. During design, decisions are made with respect to the realization of the system operations identified during analysis. Design according to the Fusion method results in an Object Interaction Graph, that for each system operation describes which objects are involved and which methods are invoked. Fusion also allows one to label the arrows representing method calls in the interaction diagram with sequencing information. In addition, design involves the construction of Visibility Graphs, indicating the attribute and method interface for each object, Class Descriptions, defining the attributes and methods of objects, and Inheritance Graphs, specifying the subtype refinement relation between classes. Implementation is considered in the Fusion method as a phase in which to work out the details of the decisions taken during analysis and design. It results in a System Lifecycle description for each object identified in the Object Model, in the form of a finite state machine, and precise Class Descriptions, in the form of (preferably) efficient code.

Validation

An important aspect of the Fusion method is the validation of the completeness and consistency of the collection of models. Completeness, obviously, is a relative matter and can only be established with respect to explicitly stated user requirements. However, the models developed in a particular phase impose additional requirements upon the efforts engaged in the later phases and in the end maintenance. Consistency involves verifying whether the various models are not contradictory. For both development and validation, the data dictionary plays an important role, as a common point of reference.

Methods for analysis and design -- a comparative study

 In  [Fichman] a comparative review of a selected number of object-oriented analysis and design methods is given. Criteria for selection were the availability of documentation and acceptance in the object-oriented community, measured in terms of refereed articles. Paraphrasing  [Fichman] again: As with traditional analysis, 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, the method proposed in  [Shlaer88] in particular reflects the domain-oriented focus of analysis. A similar focus on domain requirements and analysis may be found in the Objectory method. See slide 11-compar-1. Objectory is one of the methods that has inspired Fusion, in particular because it presents a systematic approach to the process of software development. The Objectory method centers around use case analysis. Use case analysis involves a precise description of the interaction between the user of a system and the components representing domain-specific functionality. The Objectory method gives precise guidelines on how to proceed from the identification of use cases, which include user interface aspects, to their realization in the subsequent phases of design and implementation. Objects are called blocks in Objectory. Use case analysis corresponds in a loose way with the identification of system operations in Fusion.

Objectory -- systematic process

  • requirements -- use cases, domain object model, user interface
  • analysis -- subsystems
  • design, implementation -- block model, interaction diagrams

OMT -- few rules for discovering inconsistencies
  • analysis -- object model, dynamic model, functional model
  • design, implementation -- heuristics to implement analysis models

Booch -- descriptive
  • diagrams -- class, object, timing, state, module, process

CRC -- exploratory
  • analysis, design -- class, responsibilities, collaborators

Formal methods
  • operations -- pre- and post-conditions
slide: Comparison of methods (1)
There is a close correspondence between the OMT object model and the analysis object model of Fusion. Both OMT and Fusion employ extended entity-relationship diagrams. Also, the dynamic model of OMT reoccurs in the Fusion method, albeit in a later phase. The functional model of OMT, which has the form of a dataflow diagram, is generally considered to be inappropriate for object-oriented analysis. Instead, Fusion employs a model in which the semantics of system operations are captured by means of formal pre- and post-conditions. In  [Fusion], OMT is characterized as a very loose method, giving few rules for discovering inconsistencies between the various models and lacking a clear view with respect to the process of development. OMT is strongly focused on analysis, giving nothing but heuristics to implement the models that result from analysis. However, what is called the light-weight Fusion method almost coincides with OMT. A lack of detailed guidelines for the process of software development is also characteristic of the Booch OOD method. Booch offers a wealth of descriptive diagrams, giving detailed information on the various aspects of a system, but offers merely heuristics for the actual process of development. The CRC method must be regarded primarily as a means to explore the interaction between the various objects of a domain. It is powerful in generating ideas, but offers poor support for documenting the decisions with respect to the objects and how they interact. Formal methods have been another important source of inspiration for the Fusion method. The description of system operations during analysis employs a characterization of the functionality of operations that is directly related to the specification of operations in model-based specification methods such as VDM and Z. See section formal-coop. The Fusion method may be regarded as being composed of elements of the methods mentioned above. It shares its object model with OMT, its approach to the characterization of system operations with formal methods, its focus on object interaction with CRC and its explicit description of classes and their relations with Booch. See slide 11-compar-2.

systematic comparison


ObjectoryOMTBooch CRC Fusion
development++--x+
maintenance++-+-+
structure+-+-+++
management++-+--+
tool support+-+-+--+
slide: Comparison of methods (2)
In comparison with these methods, however, it provides a much more systematic approach to the process of development and, moreover, is explicitly concerned with issues of validation and consistency between models. In addition,  [Fusion] claim to provide explicit semantics for their various models, whereas the other methods fail to do so. However, it must be remarked that the Fusion method remains somewhat obscure about the nature of system operations. System operations are characterized as asynchronous. Yet, if they are to be taken as methods, such operations may return a result, which is quite hard to reconcile with their asynchronous nature. The claim that the models have a precise semantics, which is essential for tool support, must be substantiated by providing an explicit semantics in a formal manner! With regard to the process of development, both Objectory and Fusion provide precise guidelines. The CRC method may be valuable as an additional exploratory device. For maintenance, the extent to which a method enforces the documentation of design decisions is of utmost importance. Both the Objectory and Booch method satisfys this criterion, as does the Fusion method. OMT is lacking in this respect, and CRC is clearly inadequate. Whether a method leads to a good object-oriented design of the system architecture, depends to a large extent upon the ability and experience of the development team. Apart from Fusion, both the Booch method and CRC may be characterized as purely object-oriented, whereas Objectory and OMT are considered to be impure. A strongly systematic approach to the process of development is important in particular from the point of view of project management. Project management support entails a precise definition of the deliverables associated with each phase, as well as an indication of the timing of their deliverance and validation. Both the OMT method and Booch are lacking in this respect, since they primarily provide techniques to develop descriptive models. Clearly, CRC lacks any support for project management. Tool support is dependent on the existence of a well-defined semantics for the models employed. For both Objectory and OMT commercial tools are available, despite their loosely specified semantics. The Fusion diagramming techniques are also supported. For CRC, tool support is considered to be useless. The success of the method depends upon flexibility, the ease with which new ideas can be tried, a flexibility which even hypertext cannot offer, according to its authors.
[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources
eliens@cs.vu.nl

draft version 0.1 (15/7/2001)