Dynamic Object Model and Adaptive Workflow – Computer Science Essay
1 Introduction: Hammer and Champy identify three factors that characterize modern businesses: customers take charge, intense competition, and constant change.Also scientists and engineers require flexible models for process definition and execution. The outcomes of scientific processes evolve as the experiment unfolds. It is difficult to determine in advance the structure
of the entire process. Scientific workflow systems must allow workflows and product data to evolve at runtime.
2 Dynamic Object Models for Changing Environments
Dynamic Object Model (DOM) architecture stores its object model in configuration data and interprets it at runtime. Changing the object model will immediately result in a change in behavior. Since the object model is represented as data, it is usually easy to change.
DOMs strive to represent knowledge about a domain as relationships between the objects that model the domain. They avoid hard-coding this knowledge into the code, since usually code can’t change at runtime.
DOMs usually emerge from mature domain-specific frameworks. As developers evolve a framework from white-box to black-box [RJ97], they gain a better understanding of the domain. This enables them to recognize the “hot spots” of the design—the parts that are likely to change. Next, developers factor out these parts into configuration data. What’s left is a generic system that interprets the configuration data at runtime. Changing the behavior doesn’t require code changes any longer.
This approach yields a dynamically modifiable system, where the data contains the configuration information. Users can modify the system without programming and can defer configuration decisions until runtime. When you let users modify the system, you also have to deal with their mistakes. For this reason, DOM applications require user support tools.
The DOM architectural style has been successful in domains where the business rules change often. For example, automobile makers release new models every year. Manufacturing can benefit from DOM, but the benefit might not be worth the cost.
3 The Structure of the Dynamic Object Model
Design patterns;
Type Object [JW97], most important, which separates an Entity from an EntityType. Entities have Properties and Type Object is used a second time to separate Property from PropertyType. Strategy objects [GHJV95] define the behavior of an EntityType.
Metadata [FY98] supplies the mechanism that allows the architecture to represent the knowledge about the domain as configuration information. Visual Builder [RJ97] provides a means for the now-empowered users to interact with the object model.
3.1 Properties
Objects encapsulate state and behavior. State corresponds to attributes which are usually implemented with instance variables. Changing the instance variables of an object requires changing its code.
Instead of having an instance variable for each attribute, the Property pattern uses an instance variable that holds a collection of attributes. Each attribute is associated with a unique key. Users use these keys to access, alter, modify or remove attributes at runtime.
Users can add the extra attribute at runtime, without stopping the system.
3.2 Strategy
In an object-oriented programming language, methods or virtual functions define the behavior of objects. The most languages do not allow objects to control their own methods.
We want to be able to control an object’s behavior. We need to represent behavior with a user-level mechanism. A Strategy is the reification of behavior into objects. The Strategy pattern defines a standard interface for a family of algorithms. Clients can work with any algorithm of a given family. If an object’s behavior is defined by one or more strategies then that behavior is easy to change.
3.3 Type object
The majority of object-oriented languages structure a program as a set of classes. A class defines the structure and behavior of objects. Most object-oriented systems use a separate class for each kind of object. Introducing a new kind of object requires making a new class, which requires programming.
The Type Object pattern makes the class-instance classification relationship explicit.
Some languages permit the class of an object to change (e.g., Smalltalk), but most do not. With
Type Object, the classification relationship is at the user level and can be dynamically modified. Of course, simply changing the process type is not enough—we also need to convert the attributes. However, now the user controls the state, behavior, and classification relationship.
3.4 Metadata
DOMs represent the reminder of the object model as configuration data, or Metadata. Therefore, modifications of the configuration data change the object model. In turn, changing the object model alters the system behavior.
Two factors contribute to the extended flexibility of DOM architectures.
• the generic part is hardwired; types, entities, attributes and algorithms are universal concepts
• the variable part is pushed into Metadata; users have full control and modify it to adapt the object model to their needs
3.5 Visual builder
One of the main reasons to build a DOM is to extend the system without programming. Users have direct access to the object model. They control the relationships between its core components and the Metadata information.
DOM architectures push complexity into the configuration data and delegate configuration decisions to the users.
4 An Object-OrientedWorkflow Model
The typical workflow system architecture consists of three components [Hol95, AAAM97, Sch96]. Build-time functions provide support for process definition and modeling. Run-time control manage process execution and their associated resources. Finally, run-time interaction functions provide the interfaces to human users and IT application tools. Usually, a workflow engine integrates both run-time control and interaction functions.
The workflow engine handles process enactment. This consists of reading process definitions; creating new process instances; and scheduling the various steps within the process and the appropriate resources. For adaptive workflow, we should be able to change the process definition while the process is running. We should also have a way to change a particular process instance.
We look at workflow through the lens of object-oriented technology. Since we are familiar with
DOMs in the context of flexible object-oriented systems, we’d like to use the same architectural style and techniques for adaptive workflow and modifiable process models.
Creating process instances from a process definition is similar to creating instances of a class.
We usually employ the Composite design pattern to implement tree structures. For adaptive workflow we want to be able to dynamically change the type of a procedure. The catalog form of the Composite pattern [GHJV95] uses separate classes for node and leaf elements. To provide
maximum runtime flexibility, we don’t want to commit a procedure type to a particular class. Therefore, we employ a variant that doesn’t use a classification relationship. Leaves can now change into composites and vice versa.
6 Dynamic Object Model and Workflow Adaptation
First, we need a workflowmodel that supports evolution as well as ad-hoc modifications of process instances. Model evolution is essential for Business Process Reengineering (BPR) and Continuous Process Improvement (CPI). Ad-hoc modifications allow users to adjust a particular process instance to specific circumstances. Second, we need a flexible infrastructure. The underlying software systems must be able to keep up with the process changes.
We proceed from the highest to the lowest level of abstraction. We also look at an additional characteristic supporting adaptive workflow, namely the convergence of build-time and run-time environments.
6.1 Domain level adaptation
Software has two dimensions:
• Application domain and contains domain-specific logic
• Control and data flow (i.e. workflow) and is domain independent
Generally we use the same tool (usually a programming language) in both dimensions. This characteristic encourages beginners to combine the two dimensions. Consequently, domain-specific code and control logic are usually intertwined within applications. Inexperienced programmers see (and think in) a unidimensional problem space.
In contrast, workflow is a tool only for the control and data flow dimension.
We can change on either dimension with minimal consequences for the other.
To facilitate domain level adaptation, application and workflow-specific processing should be loosely coupled. However, only experienced architects achieve a good separation.
The procedure framework tries to maintain a reduced contact area between the application and workflow domains. Control crosses the domain boundary only from the instance side in the workflow domain, at the level of Procedure objects—see Figure 6. The Iterative procedure type helps us to keep the application domain unspoiled from control logic. This reduced coupling means that changing the domain objects has a low impact on procedures, and vice versa.
6.2 Process level adaptation
The workflow framework abstracts control flow in procedures.
Type Object pattern in object-oriented design separates the issues of workflow evolution and those of dynamic ad-hoc changes:
• process owners can modify the ProcedureType, in the knowledge level. This structural change affects all Procedure objects of the corresponding type
• process users can change the Procedure instance, in the operational level. These changes have local scope and don’t affect other users
The flexible composition supports process evolution as well as ad-hoc modifications.
The key observation here is that the ProcedureType instantiates the Procedure at runtime, a dynamic binding between a process and various potential implementations. In other words, we don’t need the complete process specification at build time. A procedure can complete its specification at runtime. Alternatively, the workflow system may ask the
For adaptive workflow we need adaptive exception handlers. At the framework level, we can implement exception handlers as procedure types. Users change the handlers in the same way they change process definitions.
6.3 Resource level adaptation
In an adaptive workflow system resources are dynamic.
6.4 Infrastructure
The hospital may decide to replace the relational database used for persistence with an object-oriented database.
6.5 Build-time and run-time environments
We need an integrated environment for adaptive workflow.
Ouksel and Watson investigate the capabilities needed by workflow systems to accommodate adaptive workflow [OJW98]. They identify the integration of build-time and run-time environments as an important requirement. Chiu and Li [CKL98] also recognize the importance of an integrated environment for workflow evolution.
The build-time environment enables them to create new procedure types, in the knowledge level. For instance, a new treatment for a disease may be discovered. Likewise, the run-time environment handles procedure execution. Physicians customize a particular running process (procedure instance) according to their needs.
Smalltalk, a powerful object-oriented language, has one of the best programming environments. The development environment is fully integrated with the run-time. A user can interrupt a running program, change the code and resume execution.