Goal-driven Modeling

Conrad Bock


Reprinted from
Journal Of Object-Oriented Programming Vol 13, No 5, September 2000
Copyright © 2000 101 Communications, Inc, New York, NY

This is the fourth article in a series on modeling behavior in the context of object orientation. The first three reviewed traditional categories of behavior model, how they can be used in an object-oriented way, addressed their unification, and examined one of those models more closely. This article examines interfaces to behavior, independently of which model is used to define them. The parts of a behavior interface are reviewed, and a goal-based technique for defining them is presented. Focusing on goals coordinates the choices involved in designing behavior interfaces, links them more closely to the object model, and places object-orientation within a spectrum of modeling styles that includes event-driven and rule-based approaches.

Interfaces to Behavior

Regardless of which model is used to define a behavior (control flow, data flow, or state machine [1]), it is always invoked through an interface that does not vary as the underlying behavior is changed. In general, there are at least three parts to such an interface:

  1. What task is to be done.

  2. What the task is to operate on or with.

  3. How the task is to be carried out.

For example, object-orientation defines behavior interfaces like this:
  1. The operation name specifies the task to be done, more colloquially called the message. This might be augmented with preconditions and postconditions to further specify the task.

  2. The parameters of the operation, which include the object hosting the operation, specify what the task will operate on or with.

  3. A method dispatch technique determines how the task will be carried out. This depends only on the type of object hosting the operation.

The above aspects are not coordinated in object-oriented methodologies. For example, the choice of operation name and parameters are completely independent because a name has no structure, and consequently cannot affect the choice of parameters. Likewise, there is only one method dispatch technique, at least for singly-classified objects, and no standard for multiply-classified objects, but in any case the method-dispatch technique is not at all related to the task or what it operates on.

That these three aspects of behavior interfaces are independent in object-orientation makes them harder to use than if they were related under a more comprehensive methodology. The purpose of this article is to describe a spectrum of possibilities in which object-orientation resides. These possibilities add power and provide guidance in using it, thereby simplifying the process of analysis and design.

Goals

All three aspects of a behavior interface can be coordinated by defining the goal of the behavior. Goals describe the state of objects or data that a behavior is intended to achieve. For example, suppose we are defining a business model containing an operation for hiring staff. Its goal is to fill a position in a company. The goal constrains the state of a company after the goal is attained, namely that a position is filled. Figure 1 shows the FILL operation using a combination of UML Activity Diagram and Martin/Odell Event Diagram notation [3].

Figure 1: Operation with Goal

Goals do not restrict how the behavior is carried out. This distinguishes them from postconditions generally. Postconditions may contain any sort of constraint on an operation [4]. For example, the FILL operation may specify that the remaining money in the budget only decrease by a certain amount during the execution of the operation, that is, there is a recruitment cap. This is not a goal of the operation, only a constraint on its execution. Goals are a specific kind of postcondition describing the desired result, not how the result is achieved.

Goals are a formalization of what is usually implicit in the name of an operation. A well-chosen operation name, like FILLPOSITION suggests to the reader the intent of the operation. However, only humans can interpret an operation name, and often only well-trained humans and sometimes only the author, so operation names are not easily integrated into a structured methodology and certainly cannot be support by tools.

Operation Parameters

Goals are able to bridge the gap between operations, their parameters, and their methods, because goals are constraints on behavior that are expressed in a purely object-centric way. Let's return to the example business model that contains an operation for hiring staff. Once we choose a specific goal, let's say to find a staff member for a particular position, the parameters are clear: an in parameter for the position, and out parameter or return value for the person hired. Without a goal, the choice of parameters is much wider and more arbitrary. Should the operation also take as input the hiring manager, a budget, or other related data? Should it take a department rather than a position? Focusing on the goal of the operation reduces this complexity, because the choice of goals is more narrow than parameters.

An important advantage of proper parameter specification is that it requires explicit modeling of associations and attributes in an object model, where they might otherwise be omitted. In the hiring example, if a manager were passed into the operation, the association between a position and its superior would not necessarily be modeled in objects (see left side of Figure 2). But if parameters are chosen in a goal-directed way, the hiring manager needs to be derived from the input position during the execution of the behavior. This derivation is most easily done with an association between each position and its superior, in other words, an organization chart (see right side of Figure 2). This effect would happen with any reduction in the number of parameters, but goal-driven modeling guides the choice of parameters, so the reduction is not arbitrary.

Figure 2: Parameter/Association Tradeoff

The above tradeoff between parameter choice and object modeling is familiar to anyone who faces the problem of defining operations. It is also common in translating use cases to software models [5][6]. For example, the hiring operation example might have been defined during the formalization of a raw use case, like this one for staffing a film project:

  1. The producer gets funding for the film.
  2. The producer of the film gets a list of directors.
  3. The producer of the film chooses one from this list.
  4. The producer makes an offer.
  5. If the director does not accept, go back to step 3.
  6. The director gets a list of cinematographers.
  7. The director chooses one from this list.
  8. The director makes an offer.
  9. If the cinematographer does not accept, go back to step 7.
  10. and so on.
To begin translating the use case to an object model, the modeler defines the FILLPOSITION operation because of the common pattern of going through a list of possible hires, choosing one, and making an offer. This compacts the top-level use case so we can show more steps:

  1. The producer gets funding.
  2. The producer hires the director.
  3. The director hires the cinematographer.
  4. The cinematographer hires the camera and lighting people.
  5. The director hires actors.
The operation defined this way takes the position and hiring manager as input. Now when we let goals drive the parameter definition, and eliminate the input hiring manager, we can create an organization chart as described before. The entire use case can be translated to an algorithm that recursively descends the organization chart, with each person hiring those below them.

The narrative aspect of use cases reflects the fact that professionals in domains other than computer science tend to explain their knowledge in procedural terms [7]. The task of the modeler, who is called the knowledge engineer in expert system methodology, is to translate procedures like the film staffing example into objects, operations, and methods. Goal-driven operation definition structures this process, in part by resolving the tradeoff between parameters and associations. This is confirmed by the success of using goal-driven techniques in use-case development [8][9][10].

Method Dispatch

The way an operation is carried out in object orientation is determined by the type of the object on which the operation is invoked. The advantage of this over functional programming is that the task to be done can be separated from how it is to be achieved. Functional programming, by contrast, supports only one method for doing each operation. However, the method dispatch available in object-orientation is inadequate when compared to the needs of many applications. For example, suppose we are modeling a business process for ships coming into port for unloading. The particular cranes and techniques used may depend on the kind of ship being unloaded, the kind of cargo, and the kind of dock. This is an example of multi-methods, wherein the method is chosen according to the types of more than one input parameter [11][12]. This is shown in the top part of Figure 3. Method selection may also examine specific features of the objects receiving a message, in addition to their type. In our shipping example, the weight of cargo may determine what kind of crane use, and the dock's country location may determine the paperwork required. This is shown in the lower portion of Figure 3.

Figure 3: Generalized Method Dispatch

It might be objected that multi-methods and other more powerful forms of method dispatch violate encapsulation, but the real purpose of encapsulation is to ensure the integrity of private data, not restrict method dispatch. It also might be objected that multi-methods prevent componentization, because the method is dependent on more than one type. Components, however, are usually a collection of classes, and so a method-dispatch table for an operation on the component can index from any of those classes to a method stored in the component. Finally, regarding notation, the assignment of a method to an operation is already separated from the declaration of the operation in object-oriented languages, so it is just a matter of providing a special syntax for the procedure that chooses the method.

In general, selecting a way to satisfy a request can be a complex activity, usually with a number of alternatives, as well as dependencies on the particular situation. For example, there are many ways to fill a position: hiring, transferring from another part of the company, leasing from a consulting firm, and so on. Putting pre-defined limits on such decision making will inevitably lead to incorrect method selection in some cases. More powerful forms of method dispatch require additional support over what is provided by object-oriented languages. It might be implemented using a message broker or other high-level service. At least one system supports method dispatch by the application of expert system rules to choose a method [13].

Relation to Other Approaches

A promising aspect of goal-driven modeling is that it can bridge imperative programming styles like object-orientation to the so-called declarative styles like event-driven and rule-based systems, thereby creating synergies between them. These styles are becoming more popular with the advent of XML as a lingua franca, because it requires the modeler to relate behavior more closely to objects than simply declaring operations on them with arbitrarily assigned parameters and methods. In addition, XML is manipulated by XSL, a rule-based language that transforms an XML document from one form to another. Let's examine a couple of declarative styles that XML is encouraging.

Event-driven programming in theory focuses on the changes in objects that trigger the invocation of behaviors [14]. For example, when an employee fills a position, the IS department sets up a new computer account. However, events are commonly modeled as "sending" events to objects, with the same sort of behavior interface as an operation invocation, but without a return (asynchronous), and usually with the intent of making a transition in the state machine of the receiver [2].

This view of events has most of the difficulties identified earlier for object-oriented operations, namely the intent of the operation is not explicitly modeled, and the resolution of the parameters/association tradeoff is arbitrary. Event specification as defined in UML and most methodologies is not guided by the object model, the way goal-driven techniques are. The example given for signals in the UML Reference Manual shown in Figure 4 is redundant with a properly constructed object model [15]. Presumably the model should contain objects for the various input devices, including the mouse buttons, keyboard keys and so on. These objects have attributes or states for whether they are up or down. It is terrible programming practice to model these redundantly in signals. It might be argued that these objects lie outside the software being constructed, but that is a matter for design, not analysis. In general, models should cover the entities outside the software system as well as inside, so that use case models and their relation to the software are more explicit.

Figure 4: UML Signals

In a behavior methodology that is more integrated with object modeling, the input devices would be modeled explicitly as objects, and events as changes to those objects [3]. Then receiving a signal in the UML sense is mediated through an object-level publish/subscribe layer that detects changes in objects and reacts appropriately. The UML weakly supports this through change events, but these again are not explicitly modeled as changes to objects.

Rule-based programming takes event-driven modeling even further by invoking behaviors completely through queries and modifications on objects. For example, to invoke a rule-based version of the FILL operation described earlier, one simply asks the systems to achieve the goal: that a person fill the position. Rules that have such a goal as a consequence (the then part) are triggered to try to achieve the goal. These rules spawn subgoals from their precedents (the if part) and the process recurs until subgoals are reached which are already achieved (backward chaining). Rule-based systems are very flexible in the way they achieve goals, and consequently are sometimes hard to control directly, as we do in object-oriented systems. This issue will be addressed in a later article.

Conclusion

This article examines the various parts of a behavior interface, independently of the type of model used to define the behavior. A goal-based approach is presented for choosing parameters that ties behavior interfaces more closely to the object model. Goal-based parameters and the more powerful method dispatching techniques described here place object-orientation on a spectrum of modeling styles that includes rule-based systems.

References

[1] Bock, Conrad, "Three Kinds of Behavior Model," Journal of Object-Oriented Programming, 12:4, July/August 1999.

[2] Object Management Group, OMG Unified Modeling Language, version 1.3, available at http://www.omg.org.

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

[4] Meyer, Bertrand, Object-Oriented Software Construction, Prentice Hall, Englewood Cliffs, NJ, 1997.

[5] Filman, Robert, et al, "Eliciting Rules from Procedures" in New Generation Knowledge System Tools, Final Report, Strategic Computing Program, Defense Advanced Research Project Agency, Contract F30602-85-C-0065, September 1989.

[6] Jacobson, Ivar, and M. Christerson, P. Jonsson, G. Overgaard, Object-Oriented Software Engineering, Addison-Wesley, Reading MA, 1993.

[7] Walters, J.R. and N.R. Neilson, Crafting Knowledge-based Systems, Wiley, New York, 1988

[8] Cockburn, A., "Goals and Use Cases", Journal of Object-Oriented Programming, 10:5, September/October 1997

[9] Cockburn, A., "Using Goal-Based Use Cases", Journal of Object-Oriented Programming, 10:7, November/December 1997.

[10] Constantine, L.L. , and L. Lockwood, Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design, Addison-Wesley, Reading, MA, 1999.

[11] Kiczales, Gregor, J. des Rivieres, D.G. Bobrow, The Art of the Metaobject Protocol, MIT Press, Cambridge, MA, 1991.

[12] Saar, Ruben, "Extension of Software Components Using Multimethods", Journal of Object-Oriented Programming, 13:1, March/April 2000.

[13] Genesereth, Michael. R, "An overview of meta-level architecture" Proceedings of the Eighth AAAI Conference, American Association of Artificial Intelligence, Menlo Park, CA, 1990, pp. 119-124.

[14] S. Cook and J. Daniels, "Object Communication", Journal of Object-Oriented Programming, 8:5, September 1994.

[15] Rumbaugh, James, Ivar Jacobson, and Grady Booch, Unified Modeling Language Reference Manual, Addison-Wesley, Reading, MA, 1999.


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