A fundamental unit of behavior specification that represents some transformation or processing in the modeled system, be it a computer system or a real-world system. Actions are contained in activities, which provide their context. See: activity.
An object that may execute its own behavior without requiring method invocation. This is sometimes referred to as “the object having its own thread of control.” The points at which an active object responds to communications from other objects are determined solely by the behavior of the active object and not by the invoking object. This implies that an active object is both autonomous and interactive to some degree [OMG 03].
Explanation:
In the context of the Quantum Framework (QF), an active object is a state machine object endowed with its own thread of execution and communicating with other active objects by exchanging event instances.
The most important characteristic of an active object is its opaque encapsulation shell, which strictly separates the internal structure of an active object from the external environment. The only objects capable of penetrating this shell, both from the outside and from the inside, are event instances.
The concept of autonomous software objects (actors) communicating by event passing dates back to the late 1970s, when Carl Hewitt and colleagues [Hewitt+ 71] developed the notion of an actor. In the 1980s, actors were all the rage within the distributed artificial intelligence community, much as agents are today. In the 1990s, methodologies like ROOM [Selic+ 94], adapted actors for real-time computing. More recently, the UML specification has introduced the concept of active object that is essentially synonymous with the notion of an actor [OMG 01]. Active objects in the UML specification are the roots of threads of control in multitasking systems and engage one another asynchronously via events. The UML specification further proposes the UML variant of statecharts, with which to model the behavior of event-driven active objects.
A method of implementation in which concurrent applications are organized as cooperative collections of active objects, each endowed with a thread of execution. In such applications, active objects don’t share memory or any other resources, communicate only by sending and receiving events, and process each event in a run-to-completion (RTC) fashion.
Explanation:
Perhaps the most important characteristics of active object-based computing model is that individual active objects can be programmed internally with purely sequential techniques thus avoiding most of the hazards of traditional multithreading (such as race conditions, deadlock, starvation, or priority inversion). Yet, an active object application (as a whole) can reap all the benefits of concurrent programming, such as fast task-level response, good CPU utilization, and scalability.
Active object applications are typically instantiated from an active object-based application framework, which provides base classes for derivation of active objects and events as well as mechanisms for thread-safe event exchange. In contrast to applications, an active object framework must explicitly deal with the concurrency issues.
A specification of parameterized behavior that is expressed as a flow of execution via a sequencing of subordinate units (whose primitive elements are individual actions). See: action.
An application framework is a partially completed application, pieces of which are customized by the user to complete the application [Rogers 97].
Explanation:
Much of the infrastructure among event-driven applications is the same: The mechanisms of event queueing, event passing, time management, executing state machines, are all not very application-specific. A real-time, event-driven framework, such as QF, captures all these common elements so that they need not be re-invented and re-implemented from scratch for each application. Usually, anywhere from 60 to 90 percent of an application is common "housekeeping" code that can be reused [Douglass 99]
Reuse on the framework level leads to inversion of control between your application and the infrastructure on which it is based (the framework). When you use a class library you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls [Gamma+ 95].
You can view a framework as an application skeleton that you need to flesh out to create a complete application. You achieve this by attaching your code to the framework’s specifically designed “extension points.” You typically customize the framework’s behavior by extending classes (data types) defined inside the framework. In addition, virtually every framework also incorporates a compatible class library that you can use as a toolkit of components.
A relationship between a substate and its (direct or transitive) superstate in a hierarchical state machine [Samek+ 00].
Explanation:
A substate (nested state) in a hierarchical state machine needs only define the differences from the superstates (surrounding states). A substate can easily share (reuse) the behavior from its superstate(s) by simply ignoring commonly handled events, which are then automatically handled by higher level states. This semantics of state nesting allows a substate to inherit all aspects of behavior from its ancestors (superstates); therefore, it’s called behavioral inheritance.
Behavioral inheritance in QP, just as class inheritance in OOP, combines abstraction and hierarchy and allows building whole taxonomies of states. Just as class inheritance, behavioral inheritance is subject to the same fundamental law of generalization (the Liskov Substitution Principle extended to nested states). Also, as any other kind of inheritance, behavioral inheritance supports reuse through programming-by-difference.
A class defines an object’s interface and implementation. It specifies the object’s internal representation and defines the operations that the object can perform [Gamma+ 95].
The open source term created originally by the authors of the GNU General Public License. Essentially copyleft is equivalent to reciprocity.
Explanation:
The term copyleft is both play on the word copyright and an acknowledgment that it promoted the radical (i.e., left-wing, perhaps) departure from traditional software licensing models. The role of copyleft software license is to grow the public commons of software rather than allow each owner's copyright to pull from that common
[Rosen 04].
A software tool that can automate certain aspects of software design, documentation,
implementation and testing. The most powerful of such tools are based on UML statecharts
and support "automatic code synthesis" from state diagrams.
Explanation:
Many people understand automatic code synthesis as the generation of a program
to solve a problem from a statement of the problem specification. Statechart-based
tools cannot provide this because a statechart is just a higher level (mostly visual)
solution rather than the statement of the problem.
As far as the automatically generated code is concerned, the statechart-based tools
can autonomously generate only so-called housekeeping code [Douglass 99]. The
modeler explicitly must provide all the application-specific code, such as action and
guard expressions, to the tool. The role of housekeeping code is to “glue” the vari-ous
action and guard expressions together to ensure proper state machine execution
in accordance with the statechart semantics. For example, synthesized code typically
handles event queuing, event dispatching, guard evaluation, or transition chain exe-cution
(including exit and entry of appropriate states). Almost universally, the tools
also encompass some kind of a real-time framework
Some of the design automation tools with support for statecharts currently available on the market
include:
A template collaboration that describes the structure of a design pattern. UML patterns are more limited than those used by the design pattern community. In general, design patterns involve many non-structural aspects, such as heuristics for their use and usage trade-offs.
The result of hiding a representation and implementation in an object. The representation is not visible and cannot be accessed directly from outside the object. Operations are the only way to access and modify an object’s representation [Gamma+ 95].
An action that a method executes when an object enters a state in a state machine regardless of the transition taken to reach that state. See exit action.
An occurrence in time and space that has significance to the system. Strictly speaking, in the UML specification, the term “event” refers to the type of occurrence rather than to any concrete instance of that occurrence [OMG 01].
Explanation:
UML clearly distinguishes between “event” (type of occurrence) and event instance (concrete instance of that occurrence). For example, “Keystroke” is an event for the keyboard, but each press of a key is not an event but a concrete instance of the “Keystroke” event. Another event of interest for the keyboard might be “Power-on”, but turning the power on tomorrow at 10:05:36 will be just an instance of the “Power-on” event.
An event can have associated parameters, allowing the event instance to convey not only the occurrence of some interesting incident but also quantitative information regarding that occurrence. For example, the “Keystroke” event generated by pressing a key on a computer keyboard has associated parameters that convey the character scan code, as well as the status of the Shift, Ctrl, and Alt keys.
An event instance outlives the instantaneous occurrence that generated it and might convey this occurrence to one or more state machines. Once generated, the event instance goes through a processing life cycle that can consist of up to three stages. First, the event instance is received when it is accepted and awaiting processing (e.g., it is placed on the event queue). Later, the event instance is dispatched to the state machine, at which point it becomes the current event. Finally, it is consumed when the state machine finishes processing the event instance. A consumed event instance is no longer available for processing.
An action that a method executes when an object exits a state in a state machine regardless of the transition taken to exit that state. See entry action.
Explanation:
One possible interpretation of state for software systems is that each state represents one distinct set of valid values of the whole program memory. Even for simple programs with only a few elementary variables, this interpretation leads to an astronomical number of states. For example, a single 32-bit integer could contribute to 2 32 (4,294,967,296) different states. Clearly, this interpretation is not practical, so program variables are commonly dissociated from states. Rather, the complete condition of the system (called the extended state) is the combination of a qualitative aspect — the state — and the quantitative aspects — the extended state variables. In this interpretation, a change of variable does not always imply a change of the qualitative aspects of the system behavior and therefore does not lead to a change of state [Selic+ 94].
State machine with memory (extended state variables). (See also extended state)
Explanation:
Extended state machines can apply the underlying formalism to much more complex problems than is practical with the basic (memory-less) state machines. For instance, suppose the behavior of a computer keyboard depends on the number of characters typed on it so far and that after, say, 100,000 keystrokes, the keyboard breaks down and enters a broken state. To model this behavior in a state machine without memory, you would need to introduce 100,000 states (e.g., pressing a key in state “stroke54312” would lead to state “stroke54313”, and so on), which is clearly an impractical proposition. Alternatively, you could construct an extended state machine with a 32-bit counter. The counter would be incremented by every keystroke without changing state. When the counter reached the critical value of 100,000 keystrokes, the state machine would enter the “broken” state.
An abstract machine that defines a finite set of conditions of existence (called “states”), a set of behaviors or actions performed in each of those states, and a set of events that cause changes in states according to a finite and well-defined rule set [Douglass 99a].
Explanation:
FSMs are an efficient way to specify constraints of the overall behavior of a system. Being in a state means that the system responds only to a subset of all allowed inputs, produces only a subset of possible responses, and changes state directly to only a subset of all possible states.
A stereotyped package that contains model elements which specify a reusable architecture for all or part of a system. Frameworks typically include classes, patterns or templates. When frameworks are specialized for an application domain, they are sometimes referred to as application frameworks. See design pattern.
Boolean condition of extended state variables (and perhaps event parameters) that affect the behavior of a state machine by enabling or disabling certain operations (e.g., change of state).
Explanation:
Extended state machines often react to stimuli based not only on the qualitative state (extended state) but also on the value of the extended state variables associated with that state. For instance in the keyboard example (see explanation to extended state machine), when the keystroke counter exceeds a certain value, the state machine alters its behavior by changing state. In fact, the logical condition (comparing the keystroke counter with the threshold) is tested by every keystroke, but the change of state occurs only when the condition evaluates to TRUE. This example illustrates the general mechanism by which extended state variables influence behavior. Guard conditions (or simply guards), are evaluated dynamically based on the value of extended state variables, affect the behavior of a state machine by enabling or disabling certain operations (e.g., change of state).
The need for guards is the immediate consequence of adding memory (extended state variables) to the state machine formalism. Used sparingly, guards and extended state variables form an incredibly powerful mechanism that can immensely simplify designs. Used too liberally, however, guards can easily defeat the purpose of using state machines in the first place.
A visual formalism invented by David Harel in the early 1980’s for describing states and transitions in a modular fashion, enabling clustering (state nesting), orthogonality (concurrency) and refinement. Harel statecharts extend the conventional state transition diagrams by AND/OR decomposition of states together with inter-level transitions, and broadcast mechanisms for communication between concurrent components. The two essential ideas enabling this extension are the provision of hierarchical states (see hierarchical state machine) and the notion of orthogonality. In a nutshell, one can say: statecharts = state-diagrams + state-hierarchy + orthogonality + broadcast-communication [Harel 87]. (See also UML statecharts.)
Explanation:
The major difference between Harel statecharts and UML statecharts results from the external context of the state machine. Object state machines, such as UML statecharts, primarily come to represent behavior of a class. Classical (Harel) statechart specify behaviors of processes. The following list of differences result from the above rationale [OMG 01]:
In UML events may carry parameters. Harel statecharts support only primitive signals.
UML statecharts support call events (operation triggers) to model behaviors of types.
UML statecharts don’t support event conjunction, and the semantics is given in respect to a single event dispatch, to better match the type context as opposed to a general system context.
Classical (Harel) statecharts have an elaborated set of predefined actions, conditions and events that are not mandated by object state machines, such as entered(s), exited(s), true(condition), tr!(c) (make true), fs!(c).
In UML statecharts operations are not broadcast but can be directed to an object-set.
The notion of activities (processes) does not exist in object state machines (UML statecharts). Therefore all predefined actions and events that deal with activities are not supported, as well as the relationships between states and activities.
In UML statecharts transition compositions are constrained for practical reasons. In Harel statecharts any composition of pseudostates, simple transitions, guards, and labels is allowed.
Object state machine supports the notion of synchronous communication between state machines.
UML statecharts execute actions on transitions in their given order.
Harel statecharts do not support dynamic choice points.
Harel statecharts are based on the zero-time assumption, meaning transitions take zero time to execute. The whole system execution is based on synchronous steps where each step produces new events that will be processed at the next step. In object-oriented state machines, these assumptions are relaxed and replaced with these of software execution model, based on threads of execution and that execution of actions may take time.
Is an extended state machine that supports hierarchical decomposition of states by allowing nesting states within states. A HSM has characteristics of both a Mealy automaton and a Moore automaton in that actions generally depend on both the state of the system and the triggering event, as in a Mealy automaton. Additionally, an HSM provides optional entry and exit actions, which are associated with states rather than transitions, as in a Moore automaton.
The concept of HSM is essentially identical to ROOMchart as defined in [Selic+ 94]. (See also UML statecharts).
Explanation:
HSMs allow nesting states within states with the following semantics (see Figure HSM.1a). If a system is in the nested state “s11” (called substate), it also (implicitly) is in the surrounding state “s1” (the superstate). This HSM will attempt to handle any event in the context of state “s11” (which is in the lower level of the hierarchy). However, if state “s11” does not prescribe how to handle the event, the event is not quietly discarded (as in a classical finite state machine); rather, it is automatically handled in the higher level context of state “s1”. This is what is meant by the system being in state “s1” as well as “s11”. Of course, state nesting is not limited to one level only, and the simple rule of event processing applies recursively to any level of nesting.
Figure HSM.1 Simple HSM with state “s11” nested inside state “s1”; (b) state model of a simple toaster-oven in which states “toasting” and “baking” share the common transition from state “heating” to “doorOpen”.
States that contain other states are called composite states; conversely, states without internal structure are called simple states. A nested state is called a direct substate when it is not contained by any other state; otherwise, it is referred to as a transitively nested substate.
The semantics of hierarchical state decomposition are designed to allow sharing (reuse) of behavior. The substates (nested states) need only define the differences from the superstates (surrounding states). A substate can easily reuse the common behavior from its superstate(s) by simply ignoring commonly handled events, which are then automatically handled by higher level states. In this manner, the substates can share all aspects of behavior with their superstates. For example, in a state model of a simple toaster oven (Figure HSM.1b), states “toasting” and “baking” share a common transition to state “doorOpen”, defined in their common superstate “heating”.
Hierarchical state decomposition can be viewed as the classical exclusive-OR applied to states. For example, if a system is in state “heating” (Figure HSM.1b), it means that it’s either in state “toasting” OR “baking”. That is why state hierarchy is alternatively called OR-decomposition and the nested states are called OR-states.
A relationship that defines one entity in terms of another. Class inheritance defines a new class in terms of one or more parent classes. The new class inherits its interface and implementation from its parents. The new class is called a subclass or (in C++) a derived class. Class inheritance combines interface inheritance and implementation inheritance. Interface inheritance defines a new interface in terms of one or more existing interfaces. Implementation inheritance defines a new implementation in terms of one or more existing implementations [Gamma+ 95].
One of the most general laws of generalization. In its traditional formulation for classes, LSP requires that a subclass can be freely substituted for its superclass. This means that every instance of the subclass should be compatible with the instance of the superclass and that any code designed to work with the instance of the superclass should continue to work correctly if an instance of the subclass is used instead. LSP can be naturally extended to apply to hierarchical states in hierarchical state machines.
Explanation:
LSP is a general law applicable to any specialization/generalization hierarchy, including the hierarchy of states in hierarchical state machines (HSMs). LSP generalized for hierarchical states means that the behavior of a substate should be consistent with the superstate. For example, all states nested inside the “heating” state of the toaster oven, (e.g., “toasting” or “baking”, see Figure HSM.1b) should share the same basic characteristics of the heating state. In particular, if being in the “heating” state means that the heater is turned on, then none of the substates should turn the heater off (without transitioning out of the “heating” state). Turning the heater off and staying in the “toasting” or “baking” states would be inconsistent with being in the “heating” state and would indicate poor design (violation of the LSP).
Compliance with the LSP allows you to build better (more correct) state hierarchies and make efficient use of abstraction. For example, in an LSP-compliant state hierarchy, you can safely zoom out and work at the higher level of the “heating” state (thus abstracting away the specifics of “toasting” and “baking”). As long as all the substates are consistent with their superstate, such abstraction is meaningful. On the other hand, if the substates violate basic assumptions of being in the superstate, zooming out and ignoring specifics of the substates will be incorrect.
One of the classical interpretations of finite state automaton, which associates actions with state transitions. In a Mealy automaton actions are assumed to take no time to execute (zero-time assumption) to avoid the conceptual difficulty of ill-defined state during a state transition. Since actions necessarily take a finite amount of time, a Mealy automaton causes conceptual difficulty, because while a system is executing actions, it is not in any state (it is “between” two states). In other words, the state of a Mealy automaton is not well defined at all times. (See also Moore automaton.)
One of the classical interpretations of finite state automaton, which associates actions with states rather than transitions (as the Mealy automaton). The output of a Moore automaton depends only on the current state, whereas the output of a Mealy automaton depends on both the current state and the current input. The state of a system is always well defined in a Moore automaton (even without the zero-time assumption) because action-less transitions can be considered instantaneous (actions may take time but are executed in a well-defined state context). Mealy and Moore automata are mathematically equivalent (i.e., one always can be transformed into the other). In general, however, a Moore automaton requires more states to model the same system because a Mealy automaton can use different transitions (transitions with different triggers) to the same state and can execute different actions. A Moore automaton must use different states to represent conditions in which different actions are performed.
A method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. In such programs, classes are generally viewed as static, whereas objects typically have a much more dynamic nature, which is encouraged by the existence of polymorphism.
The word provenance (from French provenir, "to originate") is used in the art and antiques world to refer to an object's history and ownership. Knowing the provenance of an art object is equivalent to knowing the chain of title to a piece of land. When used in the context of open source software, it indicates that the chain of title to the intellectual property in the software is known [Rosen 04].
A programming paradigm that extends traditional object-oriented programming (OOP) with two additional fundamental concepts: hierarchical state machines and active object-based computing. These two concepts beautifully complement encapsulation, inheritance, and polymorphism—the famous tripartite mantra of OOP—and are just as fundamental.
Explanation:
The term Quantum Programming has been first coined in the book [Samek 02]. QP owes its name to a striking and fundamental analogy between reactive software systems and microscopic objects (such as elementary particles, nuclei, atoms, and molecules), governed by the laws of quantum physics. The quantum analogy consists of the following two elements:
Reactive software systems are analogous to quantum systems in that they are always found in strictly defined discrete states (quantum states) and can change their state only by means of uninterruptible run-to-completion (RTC) steps (quantum leaps). The states are naturally hierarchical and must comply with the Liskov Substitution Principle (LSP) for states. State nesting is fundamental and it expresses various symmetries within the system.
The hierarchical state machines interact with one another according to the active object–based computing model, which is analogous to the way particles interact in the quantum field theory. The only interaction allowed among reactive objects (hierarchical state machines) is the explicit exchange of event instances (intermediate virtual particles). The quantum model of interaction corresponds to the publish–subscribe model in software.
A metaphor, such as the quantum analogy is one of the most powerful ways to foster conceptual integrity of the software design. Only recently has the software community started to appreciate the role of analogies and metaphors in programming. For example, inventing a good metaphor is one of the key practices of eXtreme Programming.
You can view QP as a set of straightforward design patterns, idioms, concrete implementations and common-sense techniques that enable using statecharts and active object computing model without the assistance of sophisticated and high-ceremony design-automation tools. QP treats statecharts and active object-based computing model as ways of design rather than the use of a particular tool.
QP can be described as a minimalist, code-centric, and a relatively low-level approach. This characterization is not pejorative; it simply means that QP maps the fundamental concepts of hierarchical state machines and active objects directly to the source code, without intermediate layers of graphical representations. QP clearly separates essentials from niceties by implementing the former directly and supporting the latter only as design patterns. Keeping the implementation small and simple has real benefits. Programmers can learn and deploy QP quickly without large investments in tools and training. They also can adapt and customize the statechart-based application framework (Quantum Framework) easily to their particular situation, including to severely resource-constrained embedded real-time systems. They can understand, and indeed regularly use, all the features.
A minimal realization of an active object-based application framework specialized for embedded real-time systems. QF is a publish-subscribe architecture based on the quantum analogy (see Quantum Programming).
Explanation:
The term Quantum Framework has been first coined in the book [Samek 02]. The book provides concrete implementations of QF in C and C++.
QF represents a minimal and efficient realization of the active object–based computing model tailored specifically for embedded real-time systems. The design avoids all potentially risky programming techniques internally but does not limit the application designer to only these techniques. The framework has a small memory footprint (typically around 5KB) and executes the applications deterministically. It is royalty-free and can be embedded in commercial products.
A system, whose primary function is constant interaction with its environment by sending and receiving events. The main difficulty in building reactive systems is the unpredictable order, type, and timing of events that the system must handle. A graphical user interface (GUI) is an example of a reactive system.
In the run-to-completion (RTC) execution model, the system processes events in discrete, indivisible RTC steps. Higher-priority events cannot interrupt the handling of other events thereby completely avoiding the internal concurrency issue. State machine formalisms, including UML statecharts, universally assume the RTC execution semantics. The key advantage of the RTC processing is simplicity. Its biggest disadvantage is that within the scope of a single state machine event handling can-not take too long to ensure a timely response to higher-priority events. In order to achieve high responsiveness, timely low-latency and high-priority processing cannot be mixed in the same state machine with high-latency low-priority processing. This can sometimes significantly complicate designs.
Run-to-completion does not mean that a state machine has to monopolize the processor until the RTC step is complete. The preemption restriction only applies to the task context of the state machine that is already busy processing events. In a multitasking environment, other tasks (not related to the task context of the busy state machine) may be running — possibly preempting the currently executing state machine. As long as other state machines do not share resources with each other, there are no concurrency hazards.
The open source concept that can be paraphrased as follows: You may have this free software on condition that any derivative works that you create from it and distribute must be licensed to all under the same license [Rosen 04]. See also copyleft.
A diagram that depicts an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding event occurrences on the lifelines. A sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario).
The specification of an asynchronous stimulus that triggers a reaction in the receiver in an asynchronous way and without a reply. The receiving object handles the signal as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal [OMG 03].
A situation or condition in the life of a system during which some (usually implicit) invariant holds, the system performs some activity, or the system waits for some external event [OMG 03].
Explanation:
A state captures the relevant aspects of the system’s history very efficiently. For example, when you strike a key on a keyboard, the character code generated will be either an uppercase or a lowercase character, depending on whether the Caps Lock is active. Therefore, the keyboard is in the “capsLocked” state, or the default state (most keyboards have an LED that indicates when the keyboard is in the “capsLocked” state). The behavior of a keyboard depends only on certain aspects of its history, namely whether Caps Lock has been activated, but not, for example, on how many and which specific characters have been typed previously. A state can abstract away all possible (but irrelevant) event sequences and capture only the relevant ones.
A single path of execution through a program, a dynamic model, or some other representation of control flow. Also, a stereotype for the implementation of an active object as lightweight process. [OMG 03]
An interaction diagram that shows the change in state or condition of a lifeline (representing a Classifier Instance or Classifier Role) over linear time. The most common usage is to show the change in state of an object over time in response to accepted events or stimuli. [OMG 03]
An event that denotes the time elapsed since the event was armed. Typically, time events are armed upon entry to a state, so they denote time since the current state was entered.
A relationship between two states indicating that an object in the first state will perform certain specified actions and enter the second state when a specified event occurs and specified conditions are satisfied. On such a change of state, the transition is said to fire.
Object-based variants of Harel statecharts that incorporate several concepts defined in ROOMcharts, a variant of the statechart defined in the real-time object-oriented modeling (ROOM) language [Selic+ 94]. UML statecharts are hierarchical state machines (HSMs) that additionally support orthogonal regions. They represent current state of the art in state machine theory and notation.
Explanation:
As hierarchical state machines, UML statecharts support state nesting and behavioral inheritance. In addition, in a UML statechart a composite state can be decomposed into two or more orthogonal regions (orthogonal means independent in this context) and that being in such a composite state entails being in all of its orthogonal regions simultaneously.
For example, a computer keyboard has two independent parts: the main keypad and a smaller numeric keypad (see Figure HSM.2). The main keypad can be in two states: “default” and “capsLocked”, depending on the state of the Caps Lock key. The numeric keypad also can be in two states: “numbers” and “arrows”, depending on whether the Num Lock is active. The complete state space of the keyboard in the standard decomposition is the cross product of the two components (main keypad and numeric keypad) and consists of four states: “default-numbers”, “default-arrows”, “capsLocked-numbers”, and “capsLocked-arrows”. However, this is unnatural, since behavior of the numeric keypad does not depend on the state of the main keypad and vice versa. Orthogonal regions allow not to mix the independent behaviors as a cross product, but rather to keep them separate, as shown in Figure HSM.2.
In most real-life situations, orthogonal regions are only approximately orthogonal (i.e., they are not quite independent). Therefore, UML statecharts provide a number of ways for orthogonal regions to communicate and synchronize their behaviors. From this rich set of (sometimes complex) mechanisms, perhaps the most important is that orthogonal regions can coordinate their behaviors by sending event instances to each other.
Figure HSM.2 UML statechart describing a computer keyboard with two orthogonal regions (“main-keypad” and “numeric-keypad”).
Even though orthogonal regions imply independence of execution (i.e., some kind of concurrency), the UML specification does not require that a separate thread of execution be assigned to each orthogonal region (although it can be implemented that way). In fact most commonly, orthogonal regions execute within the same thread. The UML specification only requires that the designer not rely on any particular order in which an event instance will be dispatched to the involved orthogonal regions.
