Reda Bendraou Reda.Bendraou@inria.fr

1. A Model-Driven Approach For Software Process Modeling and Execution Reda Bendraou Reda.Bendraou@inria.fr

2. Software Development Processes • Challenge =>crafting quality software in a repeatable and sustainable manner and at lower costs • A pivotal ingredient to achieve this Challenge =>a good coordination of development teams over the software development phases A constant need =>the appropriate language for representing software development processes

3. "Software Processes are Software Too" • "Software Processes are Software Too" [L. J. Osterweil 87] • Design Software Processes as you design Software • Executability as principal requirement • Used only for executing processes • E.g. of Software Process Programming Languages: APPL/A (Ada), AP5 (Lisp), MERLIN (Prolog), etc • We assist to a shift from Programming Languages to Modeling Languages "Attempts in building complex systems highlighted inadequacies of the abstraction provided by current high-level programming languages" [R. France 06] • Model-Driven Engineering (MDE) • UML succeeded to become the de facto standard for modeling OO applications • Understandability, Expressiveness, Reusability as primary requirements • Used only for documenting processes • E.g. OMG's SPEM, Promenade, etc • Next Objective in the agenda: Executability of Models • Automation of no human-oriented and iterative tasks

4. Basic SPML Requirements From [Riddle 89] [Kellner 89] [Curtis 92] and [Jaccheri 99] • Expressiveness (Semantic Richness) • Description of basic process elements • Activity, Artifact, Role, Human and Tool[Humphrey 91] [Dowson_91] [Conradi 95] • Activities and steps sequencing • Proactive controlVs. Reactive control • Understandability • Code like descriptions Vs graphical representations • Multiple perspectives • Modularization • The ability to combine different chunks of processes

5. Basic SPML Requirements • Executability • Constructs with operational semantics • Support of process execution and simulation • Flexibility • To be able to adapt and customize your Software Process to specific projects • Extending the SPML at lower costs • No need to build a new interpreter/compiler for the SPML • Humans as deciders for the process workflow • Modification of the process model at runtime

6. Outline • State of the Art: Current SPMLs • The UML4SPM Language • Execution of UML4SPM Software Process Models • The UML4SPM–2–WS–BPEL Approach • The UML4SPM Execution Model Approach • Conclusions & Perspectives

7. Current SPMLs • SPEM1.1 [OMG 2005] • SPEM2.0 [OMG 2007] • Di Nitto's et al. Approach [ICSE 2002] • Promenade [UPGRADE 2004] • Chou's Approach [JOT 2002]

8. Current SPMLs (1) • Expressiveness (Semantic Richness) • Process Elements • Lacks: Agent and Tool in SPEM1.1 (Agent in SPEM2.0), Role in DiNitto • Activity Activation / Sequencing • Proactive Control:Only SPEM2.0 represents all precedence relationships • Reactive Control: is not taken into account by SPEM1 &2, and Chou's approach • Exception Handling • Is not addressed by all approaches • Understandability • SPEM1.1 good, SPEM2.0 very complex • Other approaches: the language comes in form of a UML Class diagram

9. Current SPMLs (2) • Modularization • All approaches, except SPEM2.0, require a unification procedure • i.e., renaming process elements in the different process models • Executability • Not addressed in all studied approaches • Di Nitto's and Chou's approaches, code written manually (proprietary formalism in Chou) • Flexibility • Customize your Software Process to specific projects • Only SPEM2.0 addresses this aspect • Modification of the process model at runtime • Not addressed by all the approaches

10. Outline • State of the Art: Current SPMLs • The UML4SPM Language • Execution of UML4SPM Software Process Models • The UML4SPM–2–WS–BPEL Approach • The UML4SPM Execution Model Approach • Conclusions & Perspectives

11. UML4SPM Design Goals • To respect basic SPML requirements • Executability and Flexibility as principal ones • Use of a Standard and a Well-Known formalism • Easier adoption • Leveraging existing tools and training supports  UML2.0 as a privileged candidate • Understandability • High-Level Constructs and Graphical Representations • Expressiveness • Concepts and mechanisms to ensure Proactive & Reactive Control - Executability • Concepts with execution semantics (Activity & Action packages) • No virtual machine, interpreter, nor compiler provided!!!

12. UML4SPM: Metamodel

13. UML4SPM:Actions &Activityelements • Identification of a subset of UML2.0 Action and Activity elements suitable for process modeling

14. 1 1 Classifier (from Kernel) +type {subsets namespace, subsets context} +postcondition {subsets ownedRule} Constraint Behavior * * (from Kernel) +precondition 0..1 0..1 {subsets namespace, subsets context} * * {subsets ownedRule} {subsets ownedElement} Activity +specification (from IntermediateActivities) 1 1 0..1 0..1 ValueSpecification {ordered filters node} (from Kernel) 0..* 0..* +/action Action 1 1 effect : String SoftwareActivity +action {filters owner} 1 1 isInitial : Boolean = false {filters owner} executionKind : ActivityExecutionKind +action {ordered, union {filters input} priority : priorityKind subsets ownedElement} +inputPin * * complexity : complexityKind +output * * duration : String InputPin OutputPin (from BasicActions) ... ) (from BasicActions) TypedElement Pin (from Kernel) (from BasicActions) Connecting UML4SPMwith UML2.0 Metamodel

15. Evaluating UML4SPM with the ISPW-6 benchmark [Kellner 91] • Designed to incorporate important process aspects and issues • Benchmark process problem comes in form of a "Core" problem and "Optional Extensions" • Core Problem • Modeling of designing, coding, unit testing, and monitoring of a software system modification • Relates to Expressivenessand Understandability aspects • Optional Extensions • WorkProduct versioning and management features, Tool invocations, communication between teams, etc.

16. Evaluating UML4SPM with the ISPW-6 benchmark • Expressiveness • Basic process elements • Software Activity / Action, WorkProduct, Responsible Role, Role Performer (Agent, Team and Tool), Time Limit, Guidance, etc. • Two kinds of sequencing/activation mechanisms • Proactive Control (explicit order of Activities/Actions) • Control Flows & Object Flows combined with Control Nodes (Fork, decision, etc) • Invocation Actions: CallBehaviorAction (calling other activities) • Reactive Control (in reaction to an event or a condition) • Use of Events (Time Event, Change Event and Message Event) • Use of UML2.0 Exception Handling concepts

17. A a {Accepted Events} UML4SPM Software Activity Notation {Triggered Events} IsInitial=true << Software Activity Kind>> -M/H- Software Activity Name {Optional:Priority, Complexity, Duration} Exception Parameter Pre-Condition: * [State] Outputs Post-Condition: Inputs Role Performer (s): x Tool (s): xx Exception Type Exception Handler Evaluating UML4SPM with the ISPW-6 benchmark • Understandability • Use of UML2.0 graphical notation • Minor customization to incorporate software process specific features • Multiple views/perspectives • Activity Diagram a workflow like description of the process • State Machines Diagram define allowable states for Software Activities, WorkProducts and Agents • Class Diagram relationships between different process model elements (inheritance, dependencies, etc.)

18. Evaluating UML4SPM with the ISPW-6 benchmark: Results • All issues of the Core problem were satisfied[EDOC 06] • Modeling of all process's activities with all their aspects • Issues related to Optional Extensions were satisfied • Except process improvement & measurement options are not yet addressed by UML4SPM • The benchmark helped in improving our language in terms of Expressiveness and Understandability

19. UML4SPM: Flexibility • Possibility to define method-specific and user-defined kinds of process elements Example • Rup Activities • Phase • Discipline • Iteration, etc. • Scrum WorkProducts • Story • Burn Down Chart • Backlog • etc.

20. Outline • State of the Art: Current SPMLs • The UML4SPM Language • Execution of UML4SPM Software Process Models • The UML4SPM–2–WS–BPEL Approach • The UML4SPM Execution Model Approach • Conclusions & Perspectives

21. UML4SPM: Executability Two Approaches were explored • Mapping of UML4SPM process models toward a Process Execution Language • Implementation of an Interpreter for UML4SPM models : The UML4SPM Execution Model

22. The UML4SPM-2-WS-BPEL Approach • Mapping of UML4SPM models toward WS-BPEL • BPEL (Business Process Execution Language) • A well established standard with a tooling support A Sample of mapping rules 

23. The UML4SPM-2-WS-BPEL Approach: Example UML4SPM Process model Generated BPEL Code <?xml version="1.0" encoding="UTF-8"?> <!--BPEL Process DefinitionEdited using ActiveBPEL(tm) Designer Version 3.0.0 (http://www.active-endpoints.com)--> <bpel:process xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:ns1="http://www.softeam.fr/WorkflowAdministration/" xmlns:ns2="http://www.example.org/orchestration/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Inception" suppressJoinFailure="yes" targetNamespace="http://Inception"> <bpel:import importType="http://schemas.xmlsoap.org/wsdl/" location="WorkflowAdministration.wsdl" namespace="http://www.softeam.fr/WorkflowAdministration/"/> <bpel:import importType="http://schemas.xmlsoap.org/wsdl/" location="../orchestration/orchestration.wsdl" namespace="http://www.example.org/orchestration/"/> <bpel:partnerLinks> <bpel:partnerLink myRole="HumanActivityFacade" name="HumanActivity" partnerLinkType="ns1:HumanActivity" partnerRole="HumanActivityFacade"/> <bpel:partnerLink name="OrchTool" partnerLinkType="ns2:OrchTool" partnerRole="OrchastrationProvider"/> </bpel:partnerLinks> <bpel:variables> <bpel:variable messageType="ns1:HumanActivityRequest" name="InceptionRequest"/> <bpel:variable messageType="ns1:HumanActivityRequest" name="ElaborateAnalysisModelRequest"/> <bpel:variable messageType="ns1:HumanActivityResponse" name="ElaborateAnalysisModelResponse"/> <bpel:variable messageType="ns1:HumanActivityRequest" name="ValidateAnalysisModelRequest"/> <bpel:variable messageType="ns1:HumanActivityResponse" name="ValidateAnalysisModelResponse"/> <bpel:variable messageType="ns2:sendMailRequest" name="sendMailRequest"/> </bpel:variables> <bpel:flow> <bpel:links> <bpel:link name="L1"/> <bpel:link name="L2"/> <bpel:link name="L3"/> <bpel:link name="L4"/> <bpel:link name="L5"/> </bpel:links> <bpel:receive createInstance="yes" name="StartInception" operation="HumanActivityRequest" partnerLink="HumanActivity" portType="ns1:WorkflowAdministrationPT" variable="InceptionRequest"> <bpel:sources> <bpel:source linkName="L1"/> </bpel:sources> </bpel:receive> <bpel:invoke inputVariable="ElaborateAnalysisModelRequest" name="ElaborateAnalysisModelRequest" operation="HumanActivityRequest" partnerLink="HumanActivity" portType="ns1:WorkflowAdministrationPT"> …………… </bpel:flow> </bpel:process>

24. The UML4SPM-2-WS-BPEL Approach: Results • Executability +Leveraging the existing tools and technologies in the Business Process domains +A clear separation between process description (high-level) and its execution (low-level) • Hide the complexity of the BPEL code through the transformation • Need for a configuration phase before execution ▼ Flexibility • Human interaction aspects are not taken into account by BPEL • Need to regenerate the BPEL code if the UML4SPM process models are modified • Modifications in the BPEL code are not traced-up in UML4SPM process models • If a concept is added in the UML4SPM language, you need to extend the BPEL engine • Makes it a non standard BPEL

25. UML4SPM: Executability Two Approaches were explored • Mapping of UML4SPM process models toward a Process Execution Language • Implementation of an Interpreter for UML4SPM models : The UML4SPM Execution Model

26. The UML4SPMExecution Model Approach • Definition of an Execution Model for UML4SPM • Specifies the precise execution behavior of UML4SPM elements • Goal: UML4SPM Process models executed straightforwardly • Inspired from OMG's RFP: "Executable UML Foundation" • Defines a full specification of the runtime behavior of compact subset of UML 2.0 metamodel • There is no implementation proposed • Used as a Basis of UML4SPMProcess Engine

27. The UML4SPMExecution Model Approach: Rational • Comes in form of classes and operations • Operations aim to reproduce the execution behavior of UML4SPM elements • Inspired from the GOF visitor pattern • For each UML4SPM element  a run time "Execution" visitor class is defined in the execution model • Eg. ActivityExecution, ActionExecution, ActivityNodeExecution, etc. • An Association links the Execution Class with the UML4SPMMetaclass

28. UML4SPM Executable Model UML4SPM The UML4SPMExecution Model: Rational

29. sourceActNode: ActivityNode actEdgeInstance: ActivityEdge targetActNode: ActivityNode The UML4SPMExecution Model: Rational Un bout d’exemple de procédé Comportement Opérationnel

30. The UML4SPMExecution Model : Flexibility • UML4SPM Language and its Execution Model are easily extensible UML4SPM Execution Model UML4SPM implementation

31. The UML4SPMExecution Model : Results • Executability • Respects the Execution Semantics defined by the UML2.0 standard + Reusable for UML2.0 Activity Diagram executions - Semantics variation points are not taken into account • UML4SPMExecution Model used as aProcess Engine • UML4SPM Process Models executed through interpretation • No additional steps or configuration are needed • Early feedback through simulation and testing • Automation of many iterative and no-interacting process's activities • Flexibility • Connection of the process execution with external applications • Strong Coupling ofUML4SPMProcess Models and their Executions • Possibility to modify the process definition at runtime without restarting the process execution • Conditions still need to be identified • UML4SPM Language and its Execution Model easily extensible

32. The UML4SPMExecution Model : The Kermeta approach • UML4SPM operational semantics using Kermeta • Extension to MOF • Imperative OO Language • Support for OCL • A Framework to support aspect modeling • Possibility to compose different aspects on the same Metamodel • An «Interpretation » aspect is woven to UML4SPM • UML4SPM not affected • Weaving at runtime • UML4SPM model instances straightforwardly runable and testable

33. The UML4SPMExecution Model : The Kermeta approach

34. Outline • State of the Art: Current SPMLs • The UML4SPM Language • Execution of UML4SPM Software Process Models • The UML4SPM–2–WS–BPEL Approach • The UML4SPM Execution Model Approach • Conclusions & Perspectives

35. Learned Lessons • Expressiveness (Semantic Richness) • Determines the power of the language • Take into account workflow patterns • Expressiveness vs. Complexity • Understandability • Value of graphical representations • Use of widely used standard? • Modularization • A strong issue regarding the emergence of new ways of working!! • Still neglected • And Reuse?

36. Learned Lessons • Executability • Constructs with operational semantics? • Ease process automation but not that necessary • Simulation & Testing: an important value to improve the process • Flexibility • This what penalized this discipline and still do!! • A key issue: Adaptability at lower costs • Human interactions, Human interactions & Human interactions!!!

37. …. …. Issues in Software Process Modeling & Execution Process Model Process Model • Dynamic evolution of process models • Identification of actions & conditions under which process models can be modified at runtime Process Description Evolutions / Changes C o h e r e n c e C o h e r e n c e Time Coherence Loss of Process’s state Process realization Stop execution !! Process Engine / Execution Launching a new execution of the process

38. Issues in Software Process Modeling & Execution • Reusability of software process models • Process models composition, extension, process patterns, etc. • Variability!!! • Distributed process models • Communication and coordination between distributed executions of process models • Resource management, distribution units (Activity, Action, etc.), process’s global state