Smalltalk and Object Orientation: an Introduction - Free

for representing dynamic behavior in real-time avionic control systems. Essentially statecharts indicate
the states of the system, the transitions between states, their sequence and the events which cause the
state change.
The Functional Model describes how system functions are performed. To do this it uses data flow
diagrams (DFD). These illustrate the sources and sinks of data as well as the data being exchanged.
They contain no sequencing information or control structures.
The relationshi p between these three models is important as each model adds to the designer's
understanding of the domain. Essentially the relationships are:
• The object model defines the objects which hold the state variables referenced in the dynamic
model and are the sources and sinks referenced in the functional model.
• The dynamic model indicates when the behavior in the functional model occurs and what
triggered it.
• The functional model explains why an event transition leads from one state to another in the
dynamic model.
The construction of these models is not sequential, with changes to any one of the models having a
knock on effect in the other models. Typically, the designer will start with the object model, then
consider the dynamic and finally the functional, but the process is iterative.
The actual analysis process is described in considerable detail and is supported by step by step
guidance. This ensures that the developer knows what to do at any time to advance the three models.
16.6.2 The Design phase
The Design phase of OMT builds upon the models produced during the analysis phase by breaking them
down into subsystems and by identifying appropriate algorithms for methods. These two steps are
performed during the system design and object design steps.
• The syste m design breaks the system down into subsystems and determines the overall
architecture to be used.
• The object design decides on the algorithms to be used for the methods. The methods
themselves are identified by analyzing the three analysis models for each class etc.
Each of these steps possess some guidelines for their respective tasks, however, far less support is
provided for the designer than in the analysis phase. For example, systematic guidance for the
identification of subsystems is missing. In stead the issues involved are discussed such as resource
management, batch versus interactive modes etc. This means that identifying where to start, how to
proceed and what to do next can be difficult.
16.6.3 The Implementation phase
The implementation phase rep resents the process of codifying the system and object designs into the
target language. This phase does provide some very useful guidance on how to implement features used
in the model-based design process used, but is again lacking in the step by step g uidance which would
be so useful for those new to object orientation.
16.6.4 Strengths and weaknesses
OMTs’ greatest strength is the level of step by step support which it provides during the analysis phase.
However it is much weaker in its guidance during the de sign and implementation phases providing
general guidance (and some heuristics).
16.7 The Objectory method
The Objectory method [Jacobson 1991] possesses three phases each of which produce a set of models.
The three phas es are: the Requirements phase, the Analysis phase and the Construction phase. The
134