زیرساخت های انعکاسی برای انطباق پذیری جریان کار
|کد مقاله||سال انتشار||مقاله انگلیسی||ترجمه فارسی||تعداد کلمات|
|21679||2000||34 صفحه PDF||سفارش دهید||12025 کلمه|
Publisher : Elsevier - Science Direct (الزویر - ساینس دایرکت)
Journal : Data & Knowledge Engineering, Volume 34, Issue 3, September 2000, Pages 271–304
We present a flexible framework that enables workflow systems to adapt to changing conditions. The model is designed to reveal key aspects of the tasks involved in representing and enacting business processes. These fundamental characteristics are identified as state, behaviour, distribution, coordination and enactment. By isolating such core concepts in a way that allows them to be varied, we open up the general process of task coordination and execution, allowing for extensions in a planned way. By suitable manipulation of each of these aspects, at the appropriate level, a workflow system may be extensively modified in a way that minimises the effect of such change upon other aspects of the system.
Remaining competitive is almost a raison d'être for most organisations. They are involved in a restless and unceasing struggle to attain and retain competitiveness. In the case of a manufacturing company, for example, this may be carried out in a number of ways : • Production techniques can be restructured, leading to an increase in output or in capacity. • Product characteristics – such as quality, design, delivery time and outlet distribution – may be adjusted. • Product demand may be stimulated through advertising campaigns. • Innovation in both the production and the design processes may arise from research carried out by the company. All of these may be instrumental in enabling a firm to compete in a market: whatever the particular nature of an organisation, it will have, at its disposal, a variety of tools and techniques to be used in whatever tactics are employed to maintain market share and relevance. A particular set of tactics may be realised in the form of a business process (BP), which is defined as a group of tasks, the performance of which results in something of value to a customer . Belief in the importance of business processes has resulted in a great deal of attention being paid to the workflow systems that automate them. Business Process Reengineering (BPR), in particular, advocates the use of information technology as the means of driving the process, and thus achieving goals more quickly. This promotion of IT has led to a great deal of research into the concepts of workflows and workflow management. A workflow is the automation of a business process, with documents, information or tasks being passed from one participant to another for action, according to a set of procedural rules. Workflow (WF) technology is designed for building process-centred application systems. A workflow management system (WFMS) is a system that defines, creates and manages the execution of workflows by means of software which interprets the process definition, interacts with workflow participants, and invokes IT tools and applications . Yet, as previously discussed, in many application domains, business processes are highly volatile. To meet the constraints and opportunities posed by new technology, new markets, and new laws, businesses must constantly refine their processes: unplanned deviations are the norm  and . Organisations need to be able to adjust their business processes, and quickly adapt their software systems to match. Rigid process models do not allow for creativity because they curb flexibility . The consistent and effective evolution of workflows is a basic step towards the adaptability that will be demanded of future workflow management systems . Evolution in workflows gives rise to two related problems: sometimes, because of organisational and functional adaptations of the BP model itself, the corresponding workflow schema requires amending; but sometimes also, because of unplanned events or exceptional circumstances, individual BPs may require changes and dynamic extensions . The next generation of workflow systems must provide primitives that allow the incremental modification of a workflow, without requiring that it be entirely rewritten; and they must provide mechanisms to handle running instances of a workflow schema that is undergoing modification . However, changes must be controlled, and restrictions placed on change operators. Such restrictions must be based on a WF model that has a proper theoretical basis. Generally, it must be possible to add new tasks to a WF at any point of time during its execution, to work on an inserted task concurrently to other tasks, to synchronise the execution of an inserted task with those of other tasks, to insert tasks into WF regions that have not yet been entered, to dynamically map the parameters of the inserted task to existing or to newly generated data elements, and so on . Ideally, process-centred applications should reflect changes of the BPs they support without delay. Presently, however, only if the BP to be supported is well-structured, may WFMSs be used reliably. Current WF technology handles well-defined sets of tasks, ones with fairly fixed execution sequences. It only provides rudimentary support for dynamic structural changes and dynamic extensions of WFs. This significantly limits its applicability . Existing workflow systems have made various attempts to provide adaptability: • Fujitsu's TeamWARE Dolphin and TeamWARE Flow both allow processes to be changed, even while they are in progress, allowing business processes to undergo continuous improvement. • InConcert's InConcert 2000 allows changes to an active process. • Verve Workflow supports schema modification. The product distinguishes between the process plan, which is the model, and the actual process, which is an enactment of that plan. The plan can be re-fashioned without limit, thus modification of each individual instance is possible. • Forte Conductor offers extensive work tracking and process management capabilities, but does not allow process evolution. • FileNet's Visual Workflo provides an Active Work Performer which provides control over what work gets processed. • IBM's MQSeries Workflow (the successor to FlowMark) limits workflow intervention to the transfer of an activity from one person's worklist to another's. From a research perspective, a conceptual and operational framework that supports ad hoc changes and extensions to individual workflows, rather than the evolution of a workflow schema, is presented in . From this model, a complete and minimal set of consistent and correct change operations has been developed. These operations support users in modifying the structure of WFs at runtime, while preserving their correctness and consistency. The model is a compromise: the expressive power of its WF model has been sacrificed to cope with the complexity of the algorithms required for model checking. The problems of both static and dynamic workflow evolution are addressed in . They define a complete, minimal and consistent set of modification primitives that allow alterations to the flow of a process. Policies for managing evolution are also presented. They deal with workflow instances that are running when the corresponding schema is modified, defining in particular the constraints that these instances have to meet in order to continue their execution according to the modified model. An approach to the handling of both ad hoc and evolutionary changes is discussed in . The approach, which is based on the use of Petri nets, does not provide any protocol for the management of change. This article, in contrast, offers a guided approach. Changes may only be applied under strict guidelines. However, we pay less attention to instance evolution. In addressing the general issue of software adaptability, reflection has been employed as a means of constructing flexible and extensible computer systems – ones that can evolve and adapt to changing circumstances and expectations . Applications include knowledge-based systems that can successfully answer self-imposed questions relating to their performance. Reflection has been particularly successful in object-oriented settings, where it has been employed as a novel methodology for constructing complex yet flexible systems. An initial step has been taken towards the use of reflective agents for the consistent adaptation of workflows . These agents have a representation of their own capabilities and plans. By altering these, the execution of a workflow may be altered. Another reflective approach  is concerned with ad hoc adaptations, whereby a domain-oriented base-level process model may be presented to a meta-level process model for inspection and alteration. In this article, we aim to demonstrate how reflective techniques may be applied to workflow systems, and how they may be made more adaptable as a result. We begin by presenting some basic workflow concepts, and their expression in a particular workflow notation called Task Structures. Then we present a reflective framework known as View the MathML source (for reflective object knowledge), an early version of which was presented in ; we show how that model may be used to enable modifications to a task structure; after that, we discuss the process of evolution, and how that meta-level process may also be modified. Next, we demonstrate how, within the same framework, workflow instance enactment may be specified and controlled. Finally, by merging the control structures for schema evolution and instance enactment, we derive a control structure for instance evolution. The advantages that we perceive in our approach are that: • The View the MathML source model is built upon concepts that are both recognisable and well-accepted. • Only five concepts are involved. • Merely by repeated application of these few ideas, key aspects of a workflow system may be addressed. • By enabling the modification of these key areas, extensive workflow adaptability is achieved. Moreover, because the model is based on established formalisms, and these formalisms may be applied at many different levels, a deeper understanding of workflow systems can be achieved.
نتیجه گیری انگلیسی
In this article, we have discussed the View the MathML source model and how, through its reflective capabilities, a flexible infrastructure for workflow systems may be achieved. The philosophy of the model follows the observation that, essentially, there are two applications of reflection: representing the functionality of a system, and representing its implementation. Hence we might expect two basic categories of metaobject . • There will be ones that contribute towards the specification of an object and which provide a declarative description of an object and its behaviour. • There will be ones that describe aspects of the implementation of an object. Using this prescription, the five metaobjects that form the heart of the model – state, behaviour, location, coordination and enactment – capture domain and operational knowledge, as well as allowing task-oriented activities to be monitored. Isolating key facets, in such a way that they may be inspected and adjusted, opens up the process of task coordination and specification, and enables extensions in an open and clearly-specified way. Metaobject protocols provide a means of expressing the execution semantics of objects: a reflective object protocol for workflow systems offers a flexible framework for providing structured descriptions and coordinated execution of the tasks involved. Through such protocols, the View the MathML source model provides: • A metalevel architecture for workflow systems that allows an appropriate abstraction of evolution in workflow systems. • A set of possible rules for governing the evolution of a workflow specification. • An approach to the control of the process of evolution itself. • A set of rules governing the enactment of a workflow instance. • A set of rules governing the evolution of an instance, in the light of changes to its schema. Together, these features allow the rigorous evolution of accurate and reliable workflow systems, and hence, of the corresponding business processes. The advantages that we perceive in our approach are: that the model is built upon a small number of well-established concepts; that merely by repeated application of these few ideas, key aspects of a workflow system may be addressed; and that by enabling the modification of these key areas, extensive workflow adaptability is achieved. Furthermore, because the model is founded upon familiar formalisms, and these formalisms may be applied at many different levels, a deeper understanding of workflow systems can be achieved.