A language-independent example: CD player
Let's start the discussion with a concrete example. Suppose we are to build a CD player running on computer, which has a graphical user interface (GUI).
According to UML, in the analysis phrase (as opposed to design phrase), we should focus on describing the logic of the player, without considering implementation issues such as GUI and hardware interfaces. It is very natural for us to come up with an event-driven model (whether described in a statechart or sequence diagram). We base our logic on event handling, i.e. when the event track_finished is raised, the player continue to play the next track without being instructed by the user; when the eject_pressed event is raised which denotes a graphical button named eject is pressed, the player checks the state of the drawer: if it is closed, it should be immediately opened; otherwise, it should be closed.
When we finish our model and are going to implement it, we find the implementation is impossible without changing the model. Some change is trivial, while the others are a nightmare. In the above example, there're at least two crucial points:
In case we cannot get a hardware interface library which supports events or callback functions, that is, we only have libraries that provide hardware controlling functions but don't know how to
raise hardware events, we have to discard the event-driven model and redo our modeling.
In my experience, one can hardly find a library (and corresponding hardware) which support the function close_drawer. What software can do is merely to open the drawer, while it is the user's
business to close it whether by clicking on a button on the cd-rom (also hardware) or pushing the drawer back.
The second problem is much more trivial than the first one. Both of them reveal some aspects of the drawback of separating analysis and design.
A language-dependent example
Now quickly go through a language-dependent example: guards. Similar examples are presented elsewhere.
In a statechart, guards specify condictions for transitions. They are often given as boolean expressions. To enable the transitions, values of corresponding guards must be true. But how to evaluate their value? Different implementation languages may have different interpretations. What should be highly concerned is that diversed interpretations exist in even a single language. Pascal is such a language which supports both complete boolean evaluation and short-circuit boolean evaluation by simply setting a compiling option. Though the result of the expression is always the same, there maybe different side effects.
Summary
As indicated in Using UML Action Semantics for Executable Modeling and Beyond, UML lacks exact specification of semantics. It also emphasizes the separation between analysis and design, which is sometimes conceptually difficult and practically impossible. Futhermore, without clearly specifying semantics, models cannot be executed or tested in the analysis phrase. Although they can be tested later in the implementation phrase, changes would be hard to make and cost for every modification skyrockets.
Maintained by Thomas Feng, Winter 2002