Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition)

In the previous chapter we discussed the definition of structural elements of the system classes and objects (in the small), and systems, subsystems, and components (in the large). As developers, we are usually even more concerned about how these structural elements behave dynamically as the system runs. Behavior can be divided up into two distinct perspectives how structural elements act in isolation and how they act in collaboration.

In the UML metamodel, Elements are the primary structural elements that have behavior. Classifiers (which are types of Elements) also have BehavioralFeatures, such as Operations, and their realization, Methods. In practice, we are primarily concerned with the specification of the reactive behavior of only certain Classifiers (classes, objects, systems, subsystems, components, and use cases) and certain other Elements (Actions, Operations, Methods, States, Events, Signals, and Transitions).

Logically, behavior of single elements or groups of elements can be modeled as one of three distinct types: simple, stateful, and continuous. All three are important, although the second has a particular importance in real-time systems.

3.2.1 Simple Behavior

The most common kind of behavior is called simple. The object performs services on request and keeps no memory of previous services. Each action is atomic and complete, at least from an external perspective. A simple object may maintain a collection of primitive data types and operations defined to act on them. A binary tree object, for instance, shows simple behavior. Another example is a cos(x) function. cos(p/2) always returns the same value, regardless of what value it was invoked with before. It retains no memory of previous invocations. This kind of object is also called primitive because it adds no additional constraints on the use of its operations.

An object exhibiting simple behavior always responds to a given input in exactly the same way, regardless of its history. Some examples of simple behaviors are

• Simple mathematical functions, such as cosine or square root

• A search operation of a static data structure that always starts from the same point, such as the search of a static binary tree

• Sort operations

• A knob that returns the number of clicks for a given user action

Note that simple behavior is also known as functional behavior, meaning that it defines simple behavior to be a mathematical function. Simple behavior is often modeled using activity diagrams, a topic covered in Section 3.4.8. Simple behavior is composable in the sense that if g(c) = a and f(a) = b, then f(g(c)) = b.

3.2.2 State Behavior

The second type of object behavior treats the object as a particular type of machine, called a finite state automaton or finite state machine (FSM). This kind of object possesses a bounded (finite) set of conditions of existence (state). It must be in one and only one state at a time. An automaton exhibits modal behavior, each mode constituting a state. A state is defined to be a mutually exclusive condition of existence defined by the set of events it processes and the actions it performs. Because objects with state machines react to events in well-defined ways, they are also called reactive objects.

Incoming events can induce transitions between object states in some predefined manner.

A sample-and-hold A/D converter is such an object (see Figure 3-1). It shows the states of

• Disabled: In this state, the object is not acquiring data and the hardware inverters are turned off.

• Enabled: In this state, the hardware inverters are turned on and the object may be in one of the following states: ready to acquire data, actively acquiring data, or holding data that has been acquired.

• Ready: The object is enabled but has not yet begun to capture data.

• Sampling: The object is actively acquiring data.

• Holding: The object is holding data that it previously acquired.

The statechart semantics and notation are discussed in more detail later in this chapter. Nevertheless, we can see that the state machine controls the sequence of the execution of the actions defined within the statechart. For example, when the object is in the state of Ready and it receives a GetSample event, it initializes a counter attribute to zero and begins the sampling process. When in the Holding state, the object responds to the receipt of a GetValue request event by returning the value held in the object's attribute "value."

3.2.3 Continuous Behavior

The third kind of object behavior is called continuous. An object with continuous behavior is one with an infinite, or at least unbounded, set of existence conditions. One example is the so-called algorithmic object. This is an object that executes some algorithm on a possibly infinite data stream. A moving average filter performs a smoothing function over an incoming data stream. Objects with continuous behavior are objects whose current behavior is dependent on past behavior and inputs, but the dependency is of a continuous, rather than discrete nature. Fuzzy systems, PID^[1] control loops, and digital filters are examples of objects exhibiting continuous behavior. Their current behavior depends on past history but in a quantitative not qualitative way.

^[1] PID, proportional integral-differential, is a common type of control theoretic system that uses feedback, integration, and differentiation to smoothly control continuous systems.

All that is required for continuous behavior is that the current output depends on the previous history in a mathematically smooth way.

Although the UML is very expressly a discrete modeling language, it is possible to model continuous behavior by specifying actions on activity diagrams or statecharts. Since the UML doesn't define an action language (although it does define the things that an action language must be able to do), the continuous aspects are, strictly speaking, outside of the auspices of the UML.^[2] Nevertheless, people can and do build systems that perform continuous behavior with differential and partial differential equations. This process is discussed in Chapter 10, which covers detailed design.

^[2] As of this writing, work is under way on the "UML for Systems Engineering" specification. This work defines a means for modeling truly continuous behavior via extensions to activity diagrams. This UML extension is expected to be adopted by the OMG as a separate specification in late 2004 or 2005.

It is even sometimes appropriate to mix state and continuous behavior. For example, different sets of trajectory differential equations may be used, depending on whether a spacecraft is undergoing launch, achieving orbit, in orbit, or in cruise. Such systems are called piece-wise continuous. The way in which this is normally done is to define a different set of equations (or activity diagram) for each state of the object.