280 likes | 296 Views
Explore the use of UML and model transformations for defining workflow processes, incorporating elements such as UML Activity Diagrams, BPMN diagrams, and more. Learn about current workflow modeling topics, MDD approach, AD and BPMN subsets, workflow system requirements, and resource management. This study delves into adjusting UML Activity Diagrams for workflow definitions, demonstrating AD to BPMN transformation, and discussing the convergence of workflow systems with ERP and EAI systems.
E N D
Use of UML and Model Transformations for Workflow Process Definitions Audris Kalnins, Valdis Vitolins University of Latvia, IMCS Baltic DB&IS '2006, July 3-6, Vilnius, Lithuania
Agenda • Current workflow modeling topics • Required aspects of workflow definition • Workflow definition languages • MDD approach with model transformations as a novel solution in business modeling area • Adjusting UML Activity Diagram for workflow definition • AD subset for workflow definitions, Workflow Profile for AD • BPMN diagrams as another notation for workflows • BPMN subset, adjustments and additions • Demo • AD to BPMN transformation • Conclusion
Current workflow modeling topics • Workflow systems: • have become completely distributed and global, • rely on web services as an implementation platform, • converge with ERP and EAI systems, • but till have to support humans in their business activities. • Many different authorities: • bunch of organizations (W3C, WfMC, OMG, OASIS, AIM, ...), • heap of standards (UML, BPMN, BPEL, WSCL, WSCI, ebXML, ...). • Only two of these standards provide an easy readable graphical notation for workflow processes: • UML Activity Diagrams (AD) and • Business Process Modeling Notation (BPMN), therefore as a proof of technique AD and BPMN have been chosen.
“Workflow complete" workflow system requirements • Adequate description of the control structure of the process – support for branching, decisions, parallelization, synchronization and loops. • Possibility to model data flows and to base decisions, looping and branching on process data. Process data should support rich data structures. • Possibility to define different types of tasks: • for invocation of a workflow subprocesses, • automated tasks, which are either executed by workflow engine directly (Script Task), or by some sort of automated software service (Service Task, e.g. for Web services), • tasks where a human performer performs the task with the assistance of a software application (User Task), • taskswhich are expected to be performed without aid of the workflow system (Manual Task). • Resource management – mainly, the definition and management of human task performers.
AD subset for workflow definition AD notation has a vast majority of features, most of which make no sense for workflow definition. As a suitable subset for workflow modeling the following elements are chosen : • Activities and OpaqueBehaviors • CallActions: • CallBehavior, CallOperation actions • SendSignal, AcceptEvent actions • ObjectNodes: • ActivityParameter nodes • Input and Output pins • Variables with Read and WriteVariable actions • Control nodes (Initial, ActivityFinal, FlowFinal, Fork, Join, Decision, Merge) • Control and Object Flows • ActivityPartitions, Interruptible Regions, Loop Nodes Classes which have Workflow Profile (AD stereotypes) applied, are described in the format Class – Stereotype.
AD subset for workflow definition Activities and Opaque behaviors Manual actions User actions Script actions Service actions (external automated tasks – web service operations ir our case) Activity - MainProcessrepresents an activity which is a separate workflow process Behavior - ManualAction, UserAction, ScriptAction -stereotypes for definitions of manual, software-supported manual and automated tasks Operation - ServiceOperation stereotype for web service operation
AD subset for workflow definition CallActions: CallBehavior, CallManual, CallSript, CallUser, CallOperation Actions CallBehaviorAction – CallManualAction, CallScriptAction, CallUserAction – calls to stereotyped actions CallOperationAction - CallServiceAction is an automated task, which means invoking an interface of an external software component
AD subset for workflow definition SendSignal, AcceptEvent Actions AcceptEventAction- StartAcceptEventAction- a new activity instance is started (createInstance="yes" in BPEL). IntermAacceptEventAction only activates the suspended activity
AD subset for workflow definition ObjectNodes: ActivityParameter nodes InputPins and OutputPins
AD subset for workflow definition Variables, ReadVariable- and WriteVariableActions
AD subset for workflow definition Control nodes: Initial, ActivityFinal, FlowFinal, Fork, Join, Decision, Merge
AD subset for workflow definition Control and Object Flows
AD subset for workflow definition ActivityPartitions, Interruptible Regions, Loop Nodes Partition - Performer represents a performer of a manual or user action LoopeNode -ForEachwith heavyweight extension – new ForEach.collection association for loop iterator.
Fragment of the AD metamodel source of model transformation yellow – original classes orange - stereotypes
BPMN subset for workflow definition Similarly to the AD, BPMN also has unnecessary redundancy. Therefore as a suitable subset the following elements (which have natural semantics and mapping to BPEL) were chosen: • All types of Activities User, Service, Manual, Script Tasks, Embedded and Independent Subrpocesses, LoopActivity • Receive and Send Tasks for for receiving and sending messages in non-interrupt situations • Start and EndEvents, TimerIntermediate and IntermediateEvents, attached to the boundary of an Activity ("interrupt construct") • All kinds of Gateways • Properties and property Assignments While the implicit BPMN metamodel is quite acceptable, the BPMN graphical notation lacks some important elements. Therefore for some elements new graphical notation is introduced.
BPMN subset for workflow definition Following the BPMN style the following elements are used in model, but are not shown graphically: • Input/output Messages for tasks (analogs to AD pins), • Implementation related aspects (e.g., service operation, URI). Dropped elements: • Intermediate events other than timer and "interrupt construct", • Data Objects, • MessageFlows BPMN Property it is not sufficient for modeling rich data structures, therefore BPMN is supplemented with UML Class diagram similarly to AD.
BPMN subset for workflow definition All types of Activities: User, Service, Manual, Script, Send, Receive Tasks Independent Subprocess, LoopActivity Task type is shown as task icon: Hand – manual,”S” – script, arrows – service, hand+arrows – user task, loop – loop activity Task performers are shown in another compartment
BPMN subset for workflow definition All types of Activities: Receive and Send Tasks for receiving and sending messages in non-interrupt situations Convex flag – Send task, concave flag – Receivetask Similarly to AD, data join criteria are shown as Annotations (an analog to Notes in AD)
BPMN subset for workflow definition All types of Activities: Embedded subproces for interrupt construction
BPMN subset for workflow definition Start, End Events, TimerIntermediate Event, and IntermediateEvents, attached to the boundary of an Activity ("interrupt construct")
BPMN subset for workflow definition Properties and Assignments Property is shown as a rectangle containing name:type Assignment is shown as a thick arrow
BPMN subset for workflow definition All kinds of Gateways
BPMN subset for workflow definition Sequence Flows
BPMN Metamodel Target for model transformation (subtypes for events are not shown)
Transformation as effective solution for AD to BPMN mapping Pattern part Though graphical presentation looks similar, transformation is not trivial due to conceptual differences between AD and BPMN: ForEach loop . . . Loop variable Loop body . . . Action (create) part Rule with Pattern . . . . . . More about MOLA: Tomorrow (July 5) 13.00, Session 4 A (Research Track, Room 1: Auditorium 03), Simple and Efficient Implementation of Pattern Matching in MOLA Tool
Conclusion • When there is no single standards (for languages, techiques and platforms),only model driven development (MDD) approach with model transformations permits to use all the notations (the most appropriate one for each case). • For model transformations precise modeling language semantics is necessary.As it was shown with UML AD and BPMN, standards should be adjusted and profiled. • Metamodel-based generic modeling tools for MDD approach is of high demand, however there is no adequate industry support for that.Therefore development of new generation of metamodel-based and model transformation-ready tool is started at UL IMCS.