In most event-driven systems, signal events are hierarchical. For example, an autonomous robot might distinguish between external signals, such as a Collision, and internal ones, such as a HardwareFault. External and internal signals need not be disjoint, however. Even within these two broad classifications, you might find specializations. For example, HardwareFault signals might be further specialized as BatteryFault and MovementFault. Even these might be further specialized, such as MotorStall, a kind of MovementFault.
|
Generalization is discussed in Chapters 5 and 10 . |
By modeling hierarchies of signals in this manner, you can specify polymorphic events. For example, consider a state machine with a transition triggered only by the receipt of a MotorStall. As a leaf signal in this hierarchy, the transition can be triggered only by that signal, so it is not polymorphic. In contrast, suppose you modeled the state machine with a transition triggered by the receipt of a HardwareFault. In this case, the transition is polymorphic and can be triggered by a HardwareFault or any of its specializations, including BatteryFault, MovementFault, and MotorStall.
|
State machines are discussed in Chapter 22 . |
Consider all the different kinds of signals to which a given set of active objects may respond.
Look for the common kinds of signals and place them in a generalization/specialization hierarchy using inheritance. Elevate more general ones and lower more specialized ones.
Look for the opportunity for polymorphism in the state machines of these active objects. Where you find polymorphism, adjust the hierarchy as necessary by introducing intermediate abstract signals.
|
Abstract classes are discussed in Chapters 5 and 9 . |
Figure 21-6 models a family of signals that may be handled by an autonomous robot. Note that the root signal (RobotSignal) is abstract, which means that there may be no direct instances. This signal has two immediate concrete specializations (Collision and HardwareFault), one of which (HardwareFault) is further specialized. Note that the Collision signal has one parameter.
An important part of visualizing, specifying, and documenting the behavior of a class or an interface is specifying the abnormal occurrences that its operations can produce. If you are handed a class or an interface, the operations you can invoke will be clear, but the abnormal occurrences that each operation may raise will not be clear unless you model them explicitly.
|
Classes are discussed in Chapters 4 and 9; interfaces are discussed in Chapter 11; stereotypes are discussed in Chapter 6 . |
In the UML, abnormal occurrences are just additional kinds of events that can be modeled as signals. Error events may be attached to specification operations. Modeling exceptions is somewhat the inverse of modeling a general family of signals. You model a family of signals primarily to specify the kinds of signals an active object may receive; you model abnormal occurrences primarily to specify the kinds of abnormal occurrences that an object may produce.
To model abnormal occurrences
For each class and interface, and for each operation of such elements, consider the normal things that happen. Then think of things that can go wrong and model them as signals among objects.
Arrange the signals in a hierarchy. Elevate general ones, lower specialized ones, and introduce intermediate exceptions as necessary.
For each operation, specify the abnormal occurrence signals that it may raise. You can do so explicitly (by showing send dependencies from an operation to its signals) or you can use sequence diagrams illustrating various scenarios.
Figure 21-7 models a hierarchy of abnormal occurrences that may be produced by a standard library of container classes, such as the template class Set. This hierarchy is headed by the abstract signal Error and includes three specialized kinds of errors: Duplicate, Overflow, and Underflow. As shown, the add operation may produce Duplicate and Overflow signals, and the remove operation produces only the Underflow signal. Alternatively, you could have put these dependencies in the background by naming them in each operation's specification. Either way, by knowing which signals each operation may send, you can create clients that use the Set class correctly.
|
Template classes are discussed in Chapter 9 . |
Note
Signals, including abnormal occurrence signals, are asynchronous events between objects. UML also includes exceptions such as those found in Ada or C++. Exceptions are conditions that cause the mainline execution path to be abandoned and a secondary execution path executed instead. Exceptions are not signals; instead, they are a convenient mechanism for specifying an alternate flow of control within a single synchronous thread of execution.