Journal Of Object-Oriented Programming Vol 13, No 5, September 2000
Copyright © 2000 101 Communications, Inc, New York, NY
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 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.
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.
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 . 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:
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 . 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 .
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 .
Event-driven programming in theory focuses on the changes in objects that trigger the invocation of behaviors . 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 .
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 . 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.
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 . 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.
 Object Management Group, OMG Unified Modeling Language, version 1.3, available at http://www.omg.org.
 Martin, James, and James J. Odell, Object-Oriented Methods: A Foundation (UML edition), Prentice Hall, Englewood Cliffs, NJ, 1998.
 Meyer, Bertrand, Object-Oriented Software Construction, Prentice Hall, Englewood Cliffs, NJ, 1997.
 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.
 Jacobson, Ivar, and M. Christerson, P. Jonsson, G. Overgaard, Object-Oriented Software Engineering, Addison-Wesley, Reading MA, 1993.
 Walters, J.R. and N.R. Neilson, Crafting Knowledge-based Systems, Wiley, New York, 1988
 Cockburn, A., "Goals and Use Cases", Journal of Object-Oriented Programming, 10:5, September/October 1997
 Cockburn, A., "Using Goal-Based Use Cases", Journal of Object-Oriented Programming, 10:7, November/December 1997.
 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.
 Kiczales, Gregor, J. des Rivieres, D.G. Bobrow, The Art of the Metaobject Protocol, MIT Press, Cambridge, MA, 1991.
 Saar, Ruben, "Extension of Software Components Using Multimethods", Journal of Object-Oriented Programming, 13:1, March/April 2000.
 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.
 S. Cook and J. Daniels, "Object Communication", Journal of Object-Oriented Programming, 8:5, September 1994.
 Rumbaugh, James, Ivar Jacobson, and Grady Booch, Unified Modeling Language Reference Manual, Addison-Wesley, Reading, MA, 1999.