Smalltalk and Object Orientation: an Introduction - Free

devolved amongst the objects). This is another non -trivial step and may result in modifications
to the classes and objects identified in the last step.
Identification of the relationships between classes and objects . This step involves identifying
links between objects as well as inheritance between classes. As this step may ident ify new
services required of objects, there is usually an iteration between this step and the last step.
Implementation of classes and objects. This step attempts to consider how the classes and objects
will be implemented, how attributes will be defined and services provided. This will involve
consideration of algorithms etc. This process may lead to modifications in the deliverables of all
of the above steps and may force the designer to return to some or all of the above steps.
During these steps cla ss diagrams, object diagrams, module diagrams, process diagrams, state
transition diagrams and timing diagrams are produced. The class diagrams illustrate the classes in the
system and their relationships. The object diagrams illustrate the actual object s in the system and their
relationships. Module diagrams, in turn, package the classes and objects into modules (these modules
illustrate the influence Ada had on the development of the Booch method [Booch 1987].) Process
diagrams perform a similar funct ion for processes and processors. The state transition diagrams,
together with the timing diagrams, describe the dynamic behavior of the system (while the class, object
and other diagrams describe the static structure of the system).
It is notable that Bo och recommends an incremental and iterative development of a system through
the refinement of different yet consistent logical and physical views of that system.
16.5.2 Strengths and weaknesses
The biggest problem for a designer approaching the Booch method for t he first time is that the plethora
of different notations are supported by a very poorly defined and loose process (although the revision to
the method described in [Booch 1994] addresses this to some extent). It lacks the step by step guidance
required. In particular it possesses very few mechanisms for determining the system’s requirements.
Thus its main strengths are its (mainly graphical) notations which cover most aspects of the design of an
object oriented system, whilst its greatest weakness is th e lack of sufficient guidance in the generation
of these diagrams.
16.6 The Object Modeling Technique
The Object Modeling Technique [Rumbaugh et al 1991] is an OOD method which aims to construct a
series of models which refine the system design, such that the final model is suitable for
implementation. The actual design process is divided into 3 phases:
• the Analysis Phase which attempts to model the problem domain;
• the Design Phase which structures the results of the analysis phase in an appropriate manner;
• the Implementation Phase which takes into account target language constructs.
Each of these will be briefly described below.
16.6.1 The Analysis phase
Three types of model are produced by the Analysis p hase; these are the object model, the dynamic
model and the functional model.
The Object Model describes the objects in the domain, their class and the relationships between the
objects. For example, the obj ect model might represent the fact that a department object possesses a
single manager (object) but many employees (objects). The object model therefore represents the static
structure of the domain. The actual notation used is based on an extension of t he basic Entity -
Relationship (E-R) notation.
The Dynamic Model expresses what happens in the domain, when it occurs and what the effect is.
That is, the dynamic model expresses the behavior of the system (although it does not represent how the
behavior is achieved). The formalism used to express the dynamic model is based on a variation of
finite state machines called statecharts . These were developed by Harel [Harel et al 1987, Harel 1988]
133