topical media & game development
object-oriented programming
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
- class diagrams, object interaction, packages, state and activity
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].
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.
(C) Æliens
04/09/2009
You may not copy or print any of this material without explicit permission of the author or the publisher.
In case of other copyright issues, contact the author.
