لطفا منتظر باشید ...
5.7 Related Work
The notion that processes can be specialized is not new. An informal notion of process specialization can be found in a number of organizational design approaches. Checkland (1981) builds the design process on an idealized abstract model (referred to as a ''root definition'') that is then adapted and interpreted to the situation at hand. Senge (1990) introduces the notion of systems archetypes, which provide a generalized vocabulary that can be adapted to particular organizational situations. The practice of benchmarking can also be viewed as constructing idealized models of best practice, which are to be adapted to specific organizations. Our approach can be viewed as formalizing the intuitions behind these studies.More formal notions of process specialization can be found in the studies of AI planning (Friedland and Iwasaki 1985; Stefik 1981), conceptual modeling (Borgida et al. 1993), object-oriented design (Nierstraz 1993)[14], and work flow (van der Aalst and Basten 1999). In all of these studies, however, process specialization is defined for the specific representation being proposed and none of these studies are concerned with process design.Keller and Teufel (1998), in their approach to SAP customization, propose a series of transformations (e.g., selection of relevant modules, deletion of extraneous functionality, and setting of parameters) to be applied to the SAP code base. These transformations, when formalized, can be viewed as a precursor to our notion of specializing transformation. However, this work makes no attempt to extend the notion of process specialization beyond the SAP context.There are other studies of process representation that take approaches similar to the one we propose. For example, the process formalism in this chapter and the definition of refinement, in particular, are somewhat similar to the approach taken by Horning and Randell (1973). Horning and Randell also develop a notion of one process containing another, which is equivalent to our definition of process specialization. This concept, however, plays a secondary role in their analysis. The F-ORM method, a method for specifying applications, discusses ''transformation operations''among process representations (De Antonellis et al. 1991). In this method, however, these transformations pertain to the decomposition relation, and not specialization.What is unique in our approach, then, is the notion that process specialization can be defined in a way that permits it to be incorporated into existing process representations by means of a set of specializing transformations. These transformations, when applied to a process in a given representation, result in a specialization of the original process. It is this transformational aspect of our approach that we claim provides a kind of generativity, and this will prove invaluable to process redesign. By supporting specialization for existing process representations, we hope to make this approach available as an extension to existing systems analysis and design methods.As mentioned at the outset, the suggestion by Malone et al. (1999) that specialization can be applied to processes has been the foundation for this research effort. In their Process Handbook, Malone et al. arrange business processes in a specialization hierarchy. Entries in this Handbook can be viewed at various levels of decomposition. One can also traverse the specialization hierarchy to identify interesting variants of a given process, including specializations, generalizations, and ''siblings''(alternative specializations of the process's parent in the hierarchy).
Some modeling languages such as TAXIS (Borgida et al. 1993) define a kind of specialization specific to their process representation. Our goal, on the other hand, is to define a general method for specializing processes under any process representation (even one that does not build the notion of specialization into its semantics, e.g., the state diagram or dataflow diagram).As we have emphasized throughout this chapter, the most obvious point of comparison for our work is the specialization of objects. Indeed, the research most closely related to our own would appear to be Nierstrasz's work on defining a sub-typing relationship for active objects (Nierstrasz 1993). Nierstrasz treats an object as a finite state machine that defines the communications protocol supported by that object: the messages it accepts and the services it provides. He then defines a sub-typing relationship on these state machines. This would appear to be quite similar to our own efforts to define a specialization relationship for state machines. In comparing our work with Nierstrasz, four differences are evident:
Nierstrasz is concerned with state machines as defining the interactions between individual objects, whereas we are concerned with state machines as describing the internal behavior of entire systems.
Nierstrasz provides an algorithm for determining whether the subtype relationship holds between any two state machines. We provide a set of transformations for generating specializations and generalizations from a state machine. These two operationalizations would appear to be complementary; one could imagine situations in which it would be desirable to have the capability both to analyze and generate specializations.
Nierstrasz is concerned exclusively with state machines, whereas we are interested in applying our approach to a number of process representations.
Probably most intriguing is that our definition of specialization is almost exactly the opposite of Nierstrasz's definition of subtyping. For Nierstrasz, a state machine that is a subtype must accept a superset of the sequences accepted by the supertype; otherwise, it cannot be substituted safely for that supertype (Nierstrasz 1993). For us, a state machine that is a specialization must accept a subset of the sequences accepted by its generalization; otherwise, it will not represent a restriction in extension.
This apparent contradiction is easily resolved by observing that Nierstrasz implicitly employs a minimal execution set semantics instead of the maximal execution set approach taken here. Given the minimal execution set semantics, clearly a specialization must support a superset of the original minimal execution set, and thus a state diagram is specialized by adding states and events. As shown above, our choice of semantics leads to exactly the opposite result.While this dramatic divergence can thus be explained by a difference in semantics, the question remains whether an approach that involves specialization by deletion can be reconciled with the standard object-oriented framework. In section 5.8 we argue that despite surface differences our approach is entirely consistent with the object-oriented approach to specialization: what appear to be significant inconsistencies between the two types of specialization disappear when one looks more fully into the matter.[14]Interestingly Nierstrasz operationalizes specialization for state machines in a manner almost diametrically opposed to our own. As we discuss in section 5.8, however, this apparent inconsistency can be resolved as a difference in how the state machines are interpreted as objects-what we refer to in section 5.2.1 as the distinction between maximal and minimal execution semantics.
