Three Kinds of Behavior Model

Conrad Bock


Reprinted from
Journal Of Object-Oriented Programming Vol 12, No 4, July/August 1999
Copyright © 1999 SIG Publications, Inc, New York, NY



Object orientation focuses on how data and behavior relate under a single class. Emphasis on the object naturally obscured how objects are associated and how their behavior is defined in detail. A previous series of articles addressed a more complete model of associations [1]. This article is the first in a series on modeling behavior in the context of object orientation. Behavior modeling was developed, for the most part, independently of object orientation. Consequently it is beneficial to review the three traditional categories of behavior model, examine how they differ, and explore how they can be used in an object-oriented way. These categories will be employed in later articles to evaluate unified behavior models, such as UML, and as a basis for modeling more specific aspects of behavior.


Categorizing Behavior Models

Behavior models coordinate a set of what we will call steps. These are called states, actions, or subactivities in UML [2]. Such a specification requires that at least two questions be answered for each step:
Three traditional categories of behavior model provide the following answers:

  1. Control flow takes each step when another step (or steps) is complete, perhaps taking into account other conditions, but without regard to the availability of inputs. Inputs are determined during the transitions between steps, but are not required to start a step. No restrictions are placed on how inputs are determined.

  2. Data flow takes each step when other steps provide its inputs. Inputs are determined by being passed directly from outputs of other steps.

  3. State machines take each step based on when events occur in the environment of the behavior being performed. The inputs to each step are calculated as part of the step itself.

The above models answer the original two questions along these dimensions:

  1. Each step starts based on conditions that are either internal or external to the behavior being defined.

  2. Input values to each step are all determined just before the step is taken, or each input is determined separately at its own time before the step starts.

We can characterize the three models along these two dimensions as shown in Table 1. For example, the inputs to data-flow steps are determined at various times before the step is started; state machine steps are initiated by conditions external to the state machine, and so on. The table reveals a fourth model, one in which input values are determined before a step starts and the steps are initiated by conditions outside the model. This has not arisen as a traditional behavior model for some reason. In the interest of brevity it is not considered further here, but might be an interesting area for future research.

Control Flow

Data Flow

State Machine

?

Inputs determined

At Start

Before Start

At Start

Before Start

Start conditions

Internal

Internal

External

External

Table 1: Dimensions of Behavior Modeling

The behavior models above can be unified into one, but at the expense of making them more cumbersome to use. The next article addresses this topic.


When to Use Each Model

The reader who has used a variety of programming languages knows that they equally expressive for the most part, but that some are more suited to certain applications than others. For example, APL is the most concise for array-based applications, even though one could use C, Fortran, or other languages for the same tasks. The differences between languages lie in how easy it is to write certain kinds of applications, and how easy it is to compile efficient code from them.

The same observation applies the three types of behavior model. Each model could be used for all programming tasks. For example, control flow could be used in embedded system applications by defining special steps that wait for external events. However, each model emphasizes certain aspects of behavior and de-emphasizes others, making each more suitable for particular applications. For example, control flow emphasizes the sequencing of steps by requiring one step to finish before another starts. It de-emphasizes the calculation of inputs by using whatever information happens to be available when a step starts, according to some unrestricted algorithm. This makes control flow more suitable for applications in which the exact sequence of steps is most important, as in business applications.

Data flow emphasizes the calculation of inputs by requiring the outputs of one step to be explicitly linked to inputs of another step or steps. It de-emphasizes the sequencing of steps, because the time at which all the inputs to a step arrive is determined by however long the various input steps take to complete. This means some steps may get all their inputs earlier than others in a less restrictive order than control flow. These characteristics make data flow more suitable for applications in which the proper determination of inputs is most important, as in manufacturing applications.

State machines emphasize response to external stimuli by requiring that each step start only when certain events happen in the environment of the system. It de-emphasizes the sequencing of steps by allowing this to be controlled by external events. It also de-emphasizes the calculation of inputs to each step by doing it as part of the steps themselves. This makes state machines more suitable for applications that operate in response to their environment, as in real-time or embedded applications.


Object-oriented Behavior Modeling

Object orientation distinguishes between an operation and the specific behavior that carries out the operation, which is called the method in UML terminology [9]. The simplest way to make the various behavior models object-oriented is to use them as methods. For example, a control-flow language like C is not object-oriented, but it is suitable for defining a method as long as it is not necessary to send a message from inside the method. The same applies to data flow, for example, when LISP is used in a functional style to write a method. State machines are perhaps the least suitable for method definition, because they can wait indefinitely for external events before finishing, but even these may be appropriate in some applications.

Another way to make a behavior model object-oriented is to invoke operations instead of functions in each of its steps. For example, a method written in C can be translated to C++ in part by substituting message-passing for function calls. Likewise, the steps in data flow or state machines can send a message rather than perform a more complicated or non-object-oriented computation. Languages like CLOS and modeling techniques like OOIE make this translation very easy by using the same syntax for function calls and message-passing. In these languages, polymorphism is introduced by statements that are separate from function or operation invocation. None of the code calling a function needs to change when the function is made object-oriented. This facilitates the transition from behavior specifications written by non-computer professionals, like business behavior modelers, to object-oriented implementations [10, 11].

The two simple techniques above can transform a seemingly old-fashioned behavior model into an object-oriented one. For example, the control-flow model in Figure 1 would not be acceptable to an OO practitioner, because it does not relate the steps or the entire behavior to objects responsible for them. This is an incomplete use of the UML activity notation [2].

Figure 1: Non-object-oriented Control Flow

Applying the two techniques produces the model in Figure 2, which is object-oriented. It uses the OOIE convention that the type of object receiving a message is specified in parentheses below the name of the operation that it supports. For example, the operation FIX ORDER is available on the object type CUSTOMER SUPPORT, because supporters are responsible for contacting the customer and helping them correct the order. UML unfortunately does not have a concise notation for this yet. It provides swimlanes, wherein each step is assigned to a column on the diagram corresponding to the type of object responsible for that step. Figure 2 also makes the entire control-flow model into a method by connecting it to the operation it implements, namely the operation PROCESS ORDER on the object SALES DEPARTMENT. UML uses the «realize» dependency to model this, notated by a dashed arrow. These two additions make the model object-oriented by relating the steps and entire behavior to objects that handle them.

Figure 2: Object-oriented Control Flow

In passing it should be mentioned that it is a common mistake to assume messages are passed between steps. For example, in Figure 2 it might be mistakenly taken that when step RECEIVE ORDER is done, it sends a message for REVIEW ORDER to begin. Such an interpretation would impair the reusability of the steps, because a step would imply what others must be executed after it, rather than allowing the sequence of steps to be determined by control-flow links in each diagram where the step is used. A better interpretation is that messages are passed from the method containing the steps to the operation in each step. For example in Figure 2, the method for the PROCESS ORDER operation on the SALES DEPARTMENT object invokes the SHIP ORDER operation on the SHIPPING object. This way the operations invoked by the steps have no dependence on each other. The method containing the steps coordinates the steps by defining their order and the conditions under which they are invoked, without making the operations in them dependent on each other.

An advanced technique to make a behavior model object-oriented is to associate each step with the changes to objects that the step is intended to cause, and associate those changes with the steps that they initiate [12, 13]. For example, Figure 3 shows the effects of fixing a roof, namely, a fixed roof and workers available for another job. Each has their own effect, billing the customer and assigning workers, respectively. The figure uses the UML signal flow notation in activity diagrams to notate the effect of each step. This is unfortunate because it forces the user to employ object flow to model cause and effect. For example, a fixed roof would not necessarily be an input to billing a customer, only the reason for doing so. The UML will be discussed in more detail in the next article on unified behavior models. This technique is not normally applied to data flow, because effects of a step are implicitly modeled in the structure of objects returned for consumption by later steps. When applied to state machines, this technique should not be confused with the events that trigger the beginning of steps in a state machine. State machine events model object changes, but they are caused by external factors, not by a step in the state machine.

Figure 3: Modeling the effects and causes of a step

In addition to the general techniques described so far, there are a couple techniques that apply to particular kinds of models. Fully object-oriented data flow requires that the data passed between steps are objects of certain types, perhaps also in certain states, rather than unstructured or non-object-oriented data. One of the objects passed to a step is usually used as the target of the step's operation. With these restrictions it becomes object flow.

A fully object-oriented state machine requires that it be associated with a single type of object, and that each step in the machine correspond to a particular configuration of the data in the object. These configurations are called states. For example, a state machine for soda dispenser might have steps for the state of the dispenser being ready to take an order, of having taken in money, of having dispensed soda, and of having given change. A more complete model of states and state machines will be presented in a later article.

Conclusion

This article begins a series on behavior modeling by reviewing three traditional kinds of behavior model and how they can be used in an object-oriented way. It is especially important for practitioners of object orientation to note that control- and data-flow models can be updated to object-oriented form, not just state machines, and used to significant benefit in modern applications. The various kinds of behavioral model are analyzed along two dimensions, which yields a new kind of model for future consideration. The characteristics of each model are described, along with the applications to which they are most suited. The next article in the series will address attempts to create unified behavior models that incorporate features of all three models.

References

[1]Bock, Conrad, and James Odell, "A More Complete Model of Relations and Their Implementation, Part IV: Aggregation," Journal of Object-Oriented Programming, 11(5):68-70, Sept. 1998.

[2] Rational Software, et al, UML Semantics, version 1.1, Rational Software Corporation, Santa Clara, CA, September 1997, chapter 11.

[3] Kernighan, B. W. and D. M. Ritchie, The C Programming Language, Prentice Hall, Englewood Cliffs, NJ, 1988.

[4] Martin, J., and J. J. Odell, Object-Oriented Methods: A Foundation (UML edition), Prentice Hall, Englewood Cliffs, NJ, 1998.

[5] Keller, G. and T. Teufel, SAP R/3 Process Oriented Implementation: Iterative Process Prototyping, Addison-Wesley, MA, 1998.

[6] Graham, P., ANSI Common Lisp, Prentice Hall, Englewood Cliffs, NJ, 1996.

[7] Filman, R. E. and D. P. Friedman, Coordinated Computing: Tools and Techniques for Distributed Software, McGraw Hill, New York, NY, 1984, chapter 9.

[8] Harel, D., and M. Politi, Modeling Reactive Systems With Statecharts: The Statemate Approach, McGraw Hill, 1998.

[9] Rational Software, op cit, chapter 4.

[10] Kiczales, G., J. Des Rivieres, and D. Bobrow, The Art of the Metaobject Protocol , MIT Press, 1991.

[11] Martin, op cit, p 144.

[12] Martin, op cit, pp 145-148.

[13] Keller, op cit, chapter 4.



Return to Bock Online
If you have any comments on this page or problems, contact Conrad Bock (conrad dot bock at nist dot gov)