A Proposal for a Common Infrastructure for Process and Product Models Dragos¸-Anton Manolescu and Ralph E. Johnson fmanolesc,
[email protected] July 6, 1999
More than a decade ago, Terry Winograd and Fernando Flores suggested a different way to look at computers and the way they are being used. Their vision had its roots in philosophy, biology and architecture. Extrapolating from cognition as a biological phenomenon, they conclude [WF86]: The most successful designs are not those that try to fully model the domain in which they operate, but those that are ‘in alignment’ with the fundamental structure of that domain, and that allow for modification and evolution to generate new structural coupling. This paper presents an infrastructure for process and product models where structural coupling plays a central role. It begins with two sections that introduce process and product models. Then the third section describes the components of a common infrastructure. This is a domain model engine that relies on some powerful metaphors. We describe these metaphors with a few software patterns. The ideas contained here stem from two existing frameworks, one for telecommunications billing [JA] and the other for insurance systems [JO].
1 Process Models A process describes how an actor can use the services of an enterprise. It encompasses the complete flow of events that characterize how the actor starts, performs and completes the process [JEJ94]. A process model includes a set of concepts that are useful to describe processes, their activities, the coordination of activities (control and data flow) and the actors (or roles) that can perform the specified activities [GT]. The model also provides metrics about process evolution. These are essential to keep the overall system at peak efficiency and effectiveness. Therefore, process models include functionality as well as system requirements. They are the result of a significant amount of business analysis—e.g., use case modeling. Consider order processing, a typical process for an on-line ordering system. The process model defines the actors that trigger and execute each action (customer, sales department and shipping department) and what are the conditions of completion for each action. For instance, an order is closed only when the payment is received and the ordered items are shipped to the customer. The model also provides alternatives for actions that cannot be executed or fail. Assume that the shipping department is not able to find one of the ordered items. In this case, the sales department contacts the customer and eventually suggests alternatives. 1
Business systems are dynamic. During the system’s lifetime, new processes are added and existing processes are changed or discarded. The forces behind these changes are either external (e.g., introduction of new services to remain competitive on the market) or internal (e.g., changes in the supporting information system). It is not feasible to redeploy the entire business system for each change. However, only a few of these changes can be anticipated from the beginning. Moreover, sometimes users employ the system in ways that were not even imagined by the original developers. Therefore, the process model has to be very flexible. Successful process models accommodate changes in a transparent way.
2 Product Models Products are the features of processes. Sometimes the products are physical objects. For example, a bicycle manufacturer produces bikes and spare parts for them. In other cases, products are abstract. An insurance policy is such a product. The printed document only proves the existence of the policy. Regardless of their nature, products are represented as domain objects within information systems. A product model encompasses the output of all processes of an enterprise and the interdependencies between them. It includes rules that determine different product combinations. For example, a life insurance does not allow its beneficiary to be the same as the policy holder. Another important characteristic is the possibility to track how products evolve in time. Flexible product models also provide a standard GUI editor and a uniform database interface. Users modify existing products or create new ones with the editor. The database interface allows products to change without requiring changes in the persistence mechanism. Since the editor and the database interface are provided by the product model, they are compatible with all products derived from the same model. Product models are domain specific. They require a good understanding of the domain and thorough domain analysis. As pointed out in the previous section, business environments are constantly spawning new process lifecycles. Does this have any impact on the product model? The answer depends on how the process model changes. External changes affect the product model. After all, this is their objective. For example, an insurance company can introduce a new policy, or changes in the legislation may affect existing policies. In contrast, the product model is likely to be independent from internal changes. When an enterprise replaces its relational database with an object-oriented database, this should not modify the products. Of course, the new system may enable product enhancements that can change the products as well. However, process lifecycle is faster than the deployment of new technology. Therefore, the majority of changes are external. Good product models let their users construct new products without programming. Just like process models, flexibility is very important. For example, the User-Defined Product framework (UDP) [JO] was developed at the Hartford to represent insurance policies. The framework facilitates the specification, representation and manipulation of objects with attributes that are a function of their components. Details about an insurance policy are accessible from a GUI editor. The editor presents the attributes whose values must be specified and provides a list of components that can be added. Users create new policies by combining these components in various ways. This process does not require any programming. The relationship between the product model and the products is similar to the one between a class and its instances. A product model contains general characteristics and business rules. Each product has a particular configuration of these characteristics and rules. This is key to product diversity. For instance, the product model of an insurance company is an “insurance.” The various policies that the company offers to its customers (e.g., life, home owner, automobile, etc.) are the products. Although they have different properties and business rules, they are derived from the same model. The tools provided by the product model are compatible with each particular product. 2
3 Common infrastructure for Process and Product Models The previous sections identify the process model (the “how”) and the product model (the “what”) as two important dimensions of the enterprise information system. However, the business is continuously changing. The challenge then is to reflect these changes in the information system without its redeployment. Processes and products should be able to change without programmer intervention. This section suggests a common infrastructure called the Domain Modeling Engine (DME). The DME addresses the flexible maintenance of business rules and objects within the enterprise.
Domain modeling engine The DME resides above the hardware and the system software. It is a specialized object-oriented language for process and product models. System architects build models on top of the DME using the concepts and metaphors it provides, as well as some generic external services. Figure 1 illustrates this layering. Therefore, the DME is mainly concerned with providing the foundation for the models. Process Model
Product Model
Domain Modeling Engine
Common Services
System Software
Hardware
Figure 1: The Domain Modeling Engine. The DME is a specialized object-oriented language. Unlike a universal object-oriented programming language, it does not have much support for operations. Instead, it lets system architects specify constraints and keeps track of history. 3
On the one hand, the domain engine is simpler than an universal object-oriented language, since it tries to eliminate code changes. Several features characteristic to a full-blown programming language do not have a direct correspondent within the DME. On the other hand, it supports some mechanisms that are not directly available in object-oriented languages. These include versioning and database integration.
Types and entities Two universal concepts that are in alignment with the fundamental structure of most domains are types and entities (instances). They enable system architects to define objects within the DME—Figure 2. A powerful metaphor that relates types and entities is the type object pattern [JW97] . The pattern enables explicit control of the relationship between a type and its instances. Consequently, the DME can control the knowledge level and the operational level independently. This is essential for generating new structural coupling at runtime that was not envisioned during design. Children Product model 0..1 Entity
1 0..*
Type
*
0..1
0..1 0..* Attribute
0..* 1 Attribute Type
0..*
Knowledge level
Operational level
Figure 2: DME components.
Attributes Once objects are available, it is essential to be able to associate with them different properties. In objectoriented languages, properties usually correspond to instance variables. Programmers modify the source code each time the number of instance variables of a class changes. However, representing attributes as instance variables is not viable for the DME. The domain model metaphor for object properties is the variable state [Bec96] pattern. This pattern represents the attributes of an object as a collection rather than instance variables. Users can therefore add or remove attributes without having to modify the code. This is key to maximize the reuse capabilities and flexibility of the domain engine. (This idea is along the same lines as the CORBA object property service [OHE97].)
Composable system Business objects are complex. In an object-oriented language, a typical way to manage complexity is to specialize some more general classes. However, this technique requires writing code. The DME manages 4
complexity in a different way. A set of simple components combined together yields a more powerful component. This approach corresponds to the divide and conquer principle. There are several metaphors for making new, more powerful components by composing existing ones. The composite [GHJV95] pattern combines the features of several objects. Decorator [GHJV95] dynamically attaches additional functionality to an existing object. These patterns enable users to extend functionality by adding new instances of objects and generating new structural coupling between them.
Model evolution Process and product models are dynamic. Attribute and component definitions, as well as attribute values change in time. These changes may affect the system built on top of the domain engine. In such circumstances, it is important to know what has changed and when. The history pattern [JO] keeps track of changes in definitions and values. Applications can restore component definitions and values at particular points in time. Transactions [JO] extend the history pattern to maintain the temporal information about when a change becomes effective into the computer system (see also “Two-Dimensional History” in [Fow97, page 305]). This is important since most systems do not receive knowledge of changes in a timely manner. History and transactions also enable auditing.
Integrating process with product models Figure 2 illustrates the building blocks of the product model. The model is based on a set of universal concepts and metaphors that are reusable in many different domains. The modeling engine reuses these components for the process model as well. Through structural coupling between its components, the process model is able to support a large number of rapidly changing business rules. The process model metaphor within the DME is a procedure. Procedures are also entities (objects). Figure 3 illustrates the components of the knowledge and operational levels for procedures. Operational level Procedure Context 0..* 1 Procedure
Primitive
Parallel
* * * *
Sequence
Alternation
(Domain dependent)
Repetition Knowledge level
Figure 3: Process model.
5
Each type maintains a collection of procedures. They are passed to their corresponding entities whenever these are instantiated. Afterwards, an entity can dynamically change its procedures. This is a flexible and reusable solution, since objects are easier to reuse than individual methods [RJ97]. Similar to the other DME metaphors, it does not require programmer intervention. Behavioral patterns [GHJV95] make procedures a powerful concept—e.g., interpreter, state, strategy. Executing a procedure is a two step process. First the entity sets up a procedure context. This contains all the information needed to execute the procedure. Next the entity executes the procedure and updates the context. If for some reason the procedure cannot execute, the entity aborts it entirely. The universal concepts that form the foundation of the process model are the parallel, sequence, alternation and repetition types from Figure 3. These are in alignment with the fundamental behavior of most domains. Only the primitive type (shown as a shaded box) is domain dependent. Users build processes by combining instances of these five procedure types. The following example illustrates how this works. Consider an insurance system. Life insurances for less than $1,000,000 are processed automatically. For policies over this amount, a human evaluates the policy. In the DME, this business rule can be represented by a procedure “evaluate” that is attached to a life policy entity. In a Pascal-like language, this procedure looks as follows (Compare is a procedure specific to the types that are being compared): Alternation: Sequence: Compare: value < 1000000; Primitive: automatic evaluate Sequence: Compare: value > 1000000; Primitive: find supervisor; Primitive: manual evaluate If the first Compare fails, its corresponding Sequence fails as well. When this happens, the Alternation procedure starts the second Sequence with a fresh procedure context. Figure 4 shows the corresponding procedure tree. The DME records the contexts as procedures execute. This way, the evolution of the entire process is recorded. Contexts Alternation
Sequence
Compare
Sequence
Primitive
Compare
Primitive
Primitive
Figure 4: Procedure tree.
Procedures are an important concept within the DME. All process models are expressed only in terms of procedures. There is no need for other constructs.
6
User tools All the metaphors described so far eliminate programmer intervention. However, the DME is supposed to allow users to build process and product models. What is then the DME equivalent for a programming environment? The concepts and metaphors at the core of the domain engine enable users to implement lifecycle process and product models. These models are determined entirely by how their corresponding building blocks within the DME are interconnected—structural coupling. The metaphor for a programming environment is a visual builder [RJ97]. Users orchestrate the structural coupling by simply manipulating graphic widgets on the screen. This approach widens the audience of the DME, since domain experts are rarely programmers.
Conclusion The essence of the DME lies in the structural coupling between some universal concepts. Adding instances of objects generates new structural coupling and extends functionality. The process and product models are based on a common set of universal concepts and metaphors. The domain engine allows them to maintain the same high-level object structure and change only the details. Additionally, since both models rely on the same foundation, there is no impedance mismatch between them. Ideally, the DME should enable system architects to implement lifecycle process and product models without adding any new lines of code. In practice, programmer intervention cannot be completely eliminated. New lines of code are needed to customize the engine for a particular domain. Based on domain analysis, programmers provide the set of primitive procedures—Figure 3. Other components that are likely to be domain dependent are the GUIs for model configuration.
4 Summary This paper proposed a common infrastructure for process and product models. The infrastructure is based on a domain modeling engine. The DME is a specialized object-oriented language for these models. As such, it has its own set of metaphors which emphasize flexibility and reuse. These metaphors can be expressed in the form of software patterns. They enable the change and evolution of process and product models. One hard part about the DME is finding a set of universal concepts that is in alignment with the fundamental structure of the domain. The other is identifying the set metaphors that are suitable to implement lifecycle process and product models. As with object-oriented frameworks, building a DME is an iterative process [JF88]. Developers need a few concrete examples to factor out the abstractions and metaphors that are suitable for a particular domain. Based on the ideas presented in this paper, we are planning to build product and process models for workflow applications. This exercise should help us to refine the model and identify the parts that are likely to change across domains.
References [Bec96]
Kent Beck. Smalltalk Best Practice Patterns. Prentice Hall, October 1996.
[Fow97]
Martin Fowler. Analysis Patterns—Reusable Object Models. Addison-Wesley Object-Oriented Software Engineering Series. Addison-Wesley, 1997.
7
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns—Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [GT]
Dimitrios Georgakopoulos and Aphrodite Tsalgatidou. Technology and Tools for Comprehensive Business Process Lifecycle Management, pages 356–395.
[JA]
Ralph E. Johnson and Francis Anderson. Objectiva. Work in progress.
[JEJ94]
Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object Advantage–Business Process Reengineering with Object Technology. Addison-Wesley, 1994.
[JF88]
Ralph E. Johnson and Brian Foote. Designing reusable classes. Journal of Object-Oriented Programming, 1(2), June/July 1988.
[JO]
Ralph E. Johnson and Jeff Oakes. The user-defined product framework. Work in progress.
[JW97]
Ralph E. Johnson and Bobby Woolf. The Type Object Pattern, chapter 4. In Martin et al. [MRB97], October 1997.
[MRB97] Robert C. Martin, Dirk Riehle, and Frank Buschmann, editors. Pattern Languages of Program Design 3. Software Patterns Series. Addison-Wesley, October 1997. [OHE97]
Robert Orfali, Dan Harkey, and Jeri Edwards. Instant CORBA. John Wiley & Sons, 1997.
[RJ97]
Don Roberts and Ralph Johnson. Evolving Frameworks—A Pattern Language for Developing ObjectOriented Frameworks, chapter 26. In Martin et al. [MRB97], October 1997.
[WF86]
Terry Winograd and Fernando Flores. Understanding Computers and Cognition. Addison-Wesley, 1986.
8
