Smalltalk and Object Orientation: an Introduction - Free

20.2.1.3 Prepare sequence and collaboration diagrams
Once you have identified events within the system document them first as sequence diagrams and then
as collaboration diagrams. This approach is easier, as sequence diagrams tend to deal with the
sequential ordering of the events from one object to another whereas a collaboration diagram may
involve a number of objects.
20.2.1.4 Build a state diagram
A state diagra m should be constructed for each object class with nontrivial dynamic behavior. Every
sequence diagram (and thus collaboration diagram) corresponds to a path through a state diagram. Each
branch in control flow is represented by a state with more than one exit transition. The procedure for
producing state diagrams as described by the OMT method, is summarized below by the following
algorithm:
1. Pick a class.
2. Pick one sequence diagram involving that class.
3. Follow the events for the class, the gaps in between the events are states. Give each state a name
(if it is meaningful to do so).
4. Draw out a set of states and events linking states based on the sequence diagrams.
5. Now find loops within the diagram. That is, repeated sequences of states.
6. Chose another sequence diagram for the class and produce the states and events for that diagram.
Next merge these states and events into the first diagram. That is, find the states and events
which are the same and find where they diverge. Now add the new events and states.
7. Repeat step 6 for all sequence diagrams involving this class.
8. Repeat from step 1 for all classes.
After considering all normal events, add boundary cases and special cases. Also consider events which
occur at awkward times including error events.
You should now consider any conditions on the transitions between states and any events which are
triggered off by these transitions. Note that we still have not really considered the operations which the
system will perform.
20.2.1.5 Match events between objects
Having produced the state diagrams you should now check for completeness and consistency across the
whole system. Every event should have a sender and a receiver, all states should have a predecessor and
a successor (even if they are start points or exit points) and every use case should have at least one state
diagram which explains its effect on the system’s behavior. You should also make sure that events
which are the same but on different state charts have the same name.
20.2.2 Functional modeling
The functional model in OMT describes how values are computed. UML does not possess any notation
for representing functional models and this reflects the lack of emphasis placed on functional model
style analysis by object oriented design methods. OMT uses Data Flow Diagrams (or DFD’s) to
represent functional models. In essence the functional model explains how the operations (yet to be
added) in the object model and the actions / activities of the dynamic model are achieved. It can also be
used to represent constraints amongst the values of the model.
A DFD possesses inputs and outputs, data stores, processes and data flows (arrows). Figure 20.1
illustrates an example DFD diagram.
Data stores are passive objects which store data for later use. That is they merely respond to
requests to store and access data. The Icon Definitions label between two parallel bars indicates a data
store.
Processes are drawn as an ellipse. They possess a fixed number of inputs and outputs which are
labeled with their type or name. Processes may be nested and of arbitrary complexity and eventually
reference atomic operations.
163