intro,
methods,
objects,
contracts,
formal,
summary,
Q/A,
literature
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.
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.
[3]
-
[up]
[top] -
[I]
[II]
[III]
[IV] -
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12] -
[A]
[R]
