PROCESS AND THREADS
Common Modeling Techniques
To model multiple flows of control
▪ Identify the opportunities for concurrent action and reify each
flow as an active class. Generalize common sets of active objects
into an active class ▪ Consider how each group of classes collaborates with one another
dynamically.Capture those decisions in interaction diagrams ▪ Pay close attention to communication
among active objects.
Apply synchronous and asynchronous messaging, as appropriate.
To model interprocess communication
• Model the multiple flows of control.
• Consider which of these active objects represent processes and which represent threads.
Distinguish them using the appropriate stereotype.
• Model messaging using asynchronous communication; model remote procedure calls using
synchronous communication.
• Informally specify the underlying mechanism for communication by using notes, or more formally
by using collaborations
EVENTS AND SIGNALS
Modeling family of signals
• To model a family of signals,
• 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.
• 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.
Modeling Exceptions
• To model exceptions,
• For each class and interface, and for each operation of such elements, consider the exceptional
conditions that may be raised.
• Arrange these exceptions in a hierarchy. Elevate general ones, lower specialized ones, and
introduce intermediate exceptions, as necessary.
• For each operation, specify the exceptions that it may raise. You can do so explicitly (by showing
send dependencies from an operation to its exceptions) or you can put this in the operation’s
specification.
STATE MACHINES
History States
• A state machine describes the dynamic aspects of an object whose current behavior depends on its
past.
• A state machine in effect specifies the legal ordering of states an object may go through during its
lifetime.
• In the UML, a simpler way to model this idiom is by using history states.
• A history state allows a composite state that contains sequential substates to remember the last
substate that was active in it prior to the transition from the composite state.
• As below Figure shows, you represent a shallow history state as a small circle containing the symbol
H
Concurrent Substates
• Sequential substates are the most common kind of nested state machine you'll encounter. In
certain modeling situations, however, you'll want to specify concurrent substates.
• For example, below fig. shows an expansion of the Maintenance state Maintenance is decomposed
into two concurrent substates,
• Testing and Commanding, shown by nesting them in the Maintenance state but separating them
from one another with a dashed line.
• Each of these concurrent substates is further decomposed into sequential substates.
• When control passes from the Idle to the Maintenance state, control then forks to two concurrent
flows• the enclosing object will be in the Testing state and the Commanding state.
Common Modeling Techniques
• Modeling the Lifetime of an Object
• The most common purpose for which you'll use state machines is to model the lifetime of an
object.
• state machine models the behavior of a single object over its lifetime, such as you'll find with user
interfaces, controllers, and devices.
• Starting from the initial state to the final state, lay out the top-level states the object may be in.
• Connect these states with transitions triggered by the appropriate events. Continue by adding
actions to these transitions
• Identify any entry or exit.
• Expand these states as necessary by using substates
