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].
Methods
- OOA/D -- incremental \zline{ [CY91b]}
- Objectory -- use-case analysis \zline{ [Jacobs92]}
- OOSA -- model-driven \zline{ [Kurtz90]}
- OOSD -- structured \zline{ [Wasserman89]}
- CRC -- cards \zline{ [BC89]}
- RDD -- responsibility-driven \zline{ [Wirfs89]}
- OMT -- object modeling \zline{ [Rum91]}
- OOD -- development \zline{ [Booch91]}
- Fusion -- lifecycle \zline{ [Fusion]}
slide: Software development methods
In the list above, we have collected
a number of development methods.
With the exception of OOSA
(which proposes a model-driven approach to analysis), OOSD (which introduces
a structured design representation method)
and Fusion
(which presents a promising synthesis of ideas
found in a number of other methods, such
as CRC, RDD and OMT)
we have encountered these methods previously
in chapters 1 and 3.
We have based our discussion of the
object-oriented lifecycle in section
[life] on the OOA/D method
proposed in [CY90] and [CY91b],
which stresses the gradual transition from
the analysis to the design and implementation phase.
In section [process] we have briefly discussed
the Objectory method, which proposes
employing a use case analysis
to arrive at a model specifying
system requirements.
In section [process] and [contracts],
we have discussed the responsibility-driven approach proposed in
[Wirfs89], and
the various modeling perspectives suggested by [Rum91].
Our discussion of object-oriented development in section [identifying]
has been based on Booch (1986, 1991, 1994).
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.
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 some 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 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.
Structured methods
Initially, structured methods (which were developed
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], {\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 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.
Requirements engineering {\em -- Fusion}
The Fusion method is presented in [Fusion]
as a second generation object-oriented method.
The phrase second generation is meant
to indicate the method transcends and incorporates
the ideas and techniques that were 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 lifecycle 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
\zline{\fbox{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,
as in the JSD method.
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.
Tools for analysis and design {\em -- 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, in particular the method proposed
in [Shlaer88] 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
for 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].
Comparison - as a systematic approach
|
Objectory |
OMT |
Booch |
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 the 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 diagraming techniques are also supported,
for example by Paradigm Plus, which also
supports the diagraming techniques of OMT. See section [pde].
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 its authors.
An important question, when considering methods
for software development,
is what means we wish to have to
represent the decisions taken during design.
Design representation
As phrased in [Fichman],
{\em 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.
Many of the diagram techniques employed, however, have no clear
semantics, and rely on an informal description
of common cases only.
In slide [11-diagrams]
a number of the diagram types proposed in [Booch91] are listed.
Diagrams
Booch
- class diagram/template
- object diagram/template -- dynamics
- module diagram/template
- process diagram/template -- physical design
- state transition diagram
- timing diagram
slide: Diagrams for design
Apart from class diagrams and templates
to describe the functionality
of classes and their (static) relations to other classes,
the methods also uses object diagrams (and templates) to
characterize the dynamic behavior of (collections of) objects.
Moreover, the method provides for
module diagrams
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 (Wirfs-Brock {\it et al.}, 1990) and contracts
( [Meyer88]) 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.
See [CY91b], [Bigelow88] and [Webster].
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 reuse potential 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.
Program development environments -- OODBMS
A method provides guidelines with respect
to the development of a system,
possibly including maintenance and project management.
We speak of a CASE (Computer Aided Software Engineering)
tool, when the tool supports a method in its various aspects.
Support may even include the generation of code.
Usually, a distinction is made between Upper CASE tools,
supporting the first phases of software development,
and Lower CASE tools, providing support primarily for
the later phases, include code generation.
At the lower end of the spectrum of tools we have
program development environments.
A program development environment is a collection of more
or less well-integrated software tools that
support the various activities that arise
in the course of realizing the project aims in actual software.
Program development environments may include
configuration management facilities,
a graphical interface builder, various browsers
(for example for the class inheritance structure, cross referencing
and source code module dependencies), and
facilities for interactive debugging.
An example of a CASE tool is the tool accompanying
the Objectory method.
Paradigm Plus may be characterized as a meta CASE tool,
in that it supports multiple diagraming techniques,
including those of OMT and Fusion.
See slide [11-pde].
CASE tools
\zline{\fbox{C++}}
- Rational Rose -- www.rational.com
- Paradigm Plus -- OMT, Fusion
- HP/Softbench -- Fusion
Program development environments
- ObjectCenter -- SaberC++ \zline{CenterLine}
- Objectworks/C++
- Microsoft Visual C++ -- Foundation Classes
- Sniff \zline{info@takefive.co.at}
Public domain
- ET++PE \zline{iamsun.unibe.ch:/C++}
- Cweb \zline{labrea.stanford.edu:/pub/cweb}
slide: Program development environments
HP/Softbench may be characterized as a broad spectrum tool.
It supports a variety of diagram techniques
(via third party Softbench-compatible tools,
such as Protosoft's Paradigm Plus),
among which are the techniques employed
in the HP Fusion method.
Moreover, it provides a C++ workbench,
including editors, browsers, profilers
as well as additional libraries with utilities.
A veritable programming environment is CenterLine's ObjectCenter.
ObjectCenter is a descendant of SaberC++.
It includes a variety of browsers, a configuration
management facility and quite impressive interactive
debugging facilities.
An interesting feature of ObjectCenter
is that it supports both interpreted
and compiled code, thus facilitating
rapid incremental development.
Apart from the latter facility, which is quite a unique feature,
ObjectCenter provides a rather shallow interface to standard
Unix facilities.
Beware, using ObjectCenter requires a powerful
workstation with lots of memory.
For an evaluation of ObjectCenter, consult [ObjectCenter].
Another example of a program development
environment is
Objectworks/C++, which provides a functionality
similar to Objectworks/Smalltalk,
including class hierarchy browsers, editors
and debugging facilities.
Not really a program development,
but rather a graphical user interface
development tool, is provided
by Microsoft Visual C++.
Visual C++, together with the Microsoft
Foundation Classes, allows one to develop an
application, including the
graphical user interface interactively.
The advantage of such an approach is
that it relieves the programmer of coding
the graphical layout and organizing the
code related to the window-based events.
Sniff is another interactive program development environment
with a visual flavor.
It supports a repository-based approach and allows for browsing and editing
in a unified fashion.
Information may be obtained by email from {\tt info@takefive.co.at}.
In the public domain, we have, for example,
ET++PE,
which is closely coupled with a C++ library for the development of
graphical interfaces. See section [libraries].
An essential ingredient of any
CASE tool is documentation support.
Some even go so far as to denounce
CASE tools altogether by stating that
these tools do {\em produce nothing but
PostScript (documentation)}.
As a package that in principle may valuably be incorporated
in a program development tool,
the Cweb package may be mentioned which
may be used
for producing literate C++ code.
See section [static].
Documentation tools are also part of the OSE library
that is mentioned in section [libraries].
OODBMS
Many applications require data storage facilities as offered by (object)
data base systems.
The list of systems in slide [11-oodbms] is taken from
[Harmon93].
Object database systems
\zline{\fbox{C++}}
- ObjectDesign \zline{ObjectStore}
- Ontos \zline{Ontos Inc.}
- Objectivity \zline{Objectivity Inc.}
- O2 \zline{O2 Technology}
- GemStone \zline{Servio Corp.}
- Versant ODBS \zline{Versant \c{Object Technology}}
Research
- OBST -- Stone \zline{ftp.fzi.de}
- ODE/O++ -- AT&T \zline{netlib.att.com}
slide: Object database systems
Above, we have listed some of the
popular object database systems with
an interface to C++.
These include ObjectDesign,
Ontos, Objectivity,
O2,
GemStone
and
Versant ODBS.
As packages available for research we may mention
OBST (which is the result of an ESPRIT
research project)
and ODE/O++ which provides an extension of
C++ with persistent objects and transactions.