Reda Bendraou [email protected] A Model-Driven Approach For Software Process Modeling and...

Reda Bendraou

[email protected]

A A Model-DrivenModel-Driven Approach For Approach For Software Process Modeling and ExecutionSoftware Process Modeling and Execution

A A Model-DrivenModel-Driven Approach For Approach For Software Process Modeling and ExecutionSoftware Process Modeling and Execution

2

Software Development ProcessesSoftware 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 =>A constant need => the appropriate language for representing software development processes

3

• "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 SSoftware PProcess PProgramming LLanguages: 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 ModelsExecutability of Models– Automation of no human-oriented and iterative tasksAutomation of no human-oriented and iterative tasks

"Software Processes are Software Too""Software Processes are Software Too"

4

Basic Basic SPMLSPML Requirements Requirements

• 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 control VsVs. Reactive control

• Understandability– Code like descriptions Vs graphical representations– Multiple perspectives

• Modularization– The ability to combine different chunks of processes

From [Riddle 89] [Kellner 89]From [Riddle 89] [Kellner 89] [Curtis 92] [Curtis 92] and [Jaccheri 99] and [Jaccheri 99]

5

Basic Basic SPMLSPML Requirements 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

• State of the Art: Current SPMLsState 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

OutlineOutline

7

Current SPMLsCurrent 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

• 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

Current SPMLs (1)Current SPMLs (1)

9

• 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

Current SPMLs (2)Current SPMLs (2)

10

• State of the Art: Current SPMLs

• The The UMLUML44SPMSPM Language Language





OutlineOutline

11

UMLUML44SPMSPM Design Goals 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 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

UMLUML44SPM: SPM: MetamodelMetamodel

ActivityExecutionKind

machineExecutionhumanExecution

<<enumeration>>

complexityKind

easyMediumDifficult

<<enumeration>>

priorityKind

LowMediumHigh

<<enumeration>>

Agent

skills : StringisAvailable : Boolean

ProcessElementKind

name : String

ProcessElement

description : String 0..11

+kind

0..1

+processElement

1

Tool

description : StringisBatch : Booleanversion : String

TeamTimeLimit

milestone : StringGuidance

RolePerformer

name : String1..n

+performers

1..n

SoftwareActivity

isInial : Boolean = falseexecutionKind : ActivityExecutionKindpriority : priorityKindcomplexity : complexityKindduration : String

0..1

+endsAt

0..10..1

+startsAt

0..10..n

+guidance

0..n

WorkProduct

idWorkProduct : StringisDeliverable : Booleancreated : StringlastTimeModified : StringuriLocalization : Stringversion : String

0..n

+impacts

0..n

ResponsibleRole

responsability : Stringqualifications : Stringrights : String

1..n

0..n

+rolePerformer 1..n

+Role 0..n

1..n

0..n

+responsibleRoles

1..n

+activities

0..n

0..n

0..n

+workProducts

0..n

+performer

0..nSoftwareActivityKind

WorkProductKind

ResponsibleRoleKind

13

Actions Activity Elements

• AcceptEventAction

• CallBehaviorAction

• CallOperationAction

• RaiseExceptionAction

• SendSignalAction

• OpaqueAction

• Activity

• Activity Edge (ControlFlow, ObjectFlow)

• ControleNode (DecisionNode FinalNode, ForkNode, InitialNode, JoinNode, MergeNode)

• ObjectNode (ActivityParameterNode, Inputpin & Outputpin, DataStoreNode)

• ConditionalNode & LoopNode

• ExceptionHandler

• Identification of a subset of UML2.0 Action and Activity elements suitable for process modeling

UMLUML44SPMSPM:: ActionsActions & & ActivityActivity elementselements

14

SoftwareActivity

executionKind : ActivityExecutionKindpriority : priorityKindcomplexity : complexityKind

isInitial : Boolean = false

BehaviorConstraint(from Kernel)

*

+precondition

*{subsets ownedRule}{subsets namespace, subsets context}

*

+postcondition

*{subsets ownedRule}

{subsets namespace, subsets context}

ValueSpecification(from Kernel)

0..1

1

0..1

+specification1

{subsets ownedElement}

InputPin(from BasicActions)...)

OutputPin(from BasicActions)

TypedElement(from Kernel)

Pin(from BasicActions)

Classifier(from Kernel) +type

11

Activity(from IntermediateActivities)

Action

effect : String

*

1

+inputPin*

{filters input} +action

1{filters owner}

*

1

+output*

{ordered, unionsubsets ownedElement}

+action

1

{filters owner}

+/action

{ordered filters node}0..*

0..1

0..*

0..1

duration : String

Connecting UMLConnecting UML44SPMSPM withwith UML2.0 UML2.0 MetamodelMetamodel

15

Evaluating Evaluating UMLUML44SPMSPM with the with the ISPW-6ISPW-6 benchmark benchmark

• 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 Expressiveness and Understandability aspects

– Optional Extensions • WorkProduct versioning and management features, Tool invocations,

communication between teams, etc.

[Kellner 91]

16

• 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


Expressiveness

17


• 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.)

Exception Parameter

Aa

InputsOutputs

Exception Handler

Exception Type

<< Software Activity Kind>> -M/H-Software Activity Name

{Optional: Priority, Complexity, Duration}

Role Performer (s): x Tool (s): xx

{Accepted Events} {Triggered Events}

Pre-Condition:

Post-Condition:

*[State]

*[State]

IsInitial=true

UML4SPM Software Activity Notation

Understandability

18

Evaluating Evaluating UMLUML44SPMSPM with the with the ISPW-6ISPW-6 benchmark: Results 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

SoftwareActivityKind WorkProductKind

SoftwareActivity

isInial : Boolean = falseexecutionKind : ActivityExecutionKindpriority : priorityKindcomplexity : complexityKindduration : String

0..1

*

+softwareActivityKind0..1 {redefines kind}

*

WorkProduct

idWorkProduct : StringisDeliverable : Booleancreated : StringlastTimeModified : StringuriLocalization : Stringversion : String

0..1

*

+workProductKind

0..1 {redefines kind}

*

ResponsibleRoleKind ResponsibleRole

responsability : Stringqualifications : Stringrights : String

1..n

0..n

+responsibleRoles 1..n

+activities0..n0..n

0..n

+workProducts0..n

+performer

0..n

0..1

*

+responsibleRoleKind

0..1

{redefines kind} *

• Possibility to define method-specific and user-defined kinds of process elements

UMLUML44SPMSPM: Flexibility : Flexibility

Example

• Rup Activities– Phase

– Discipline

– Iteration, etc.

• Scrum WorkProducts– Story

– Burn Down Chart

– Backlog

– etc.

20



• Execution of Execution of UMLUML44SPMSPM Software Process Models Software Process Models




OutlineOutline

21

UMLUML44SPMSPM: Executability: 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 The UMLUML44SPMSPM-2-WS-BPEL Approach-2-WS-BPEL Approach

• Mapping of UML4SPM models toward WS-BPEL

– BPEL (Business Process Execution Language)

– A well established standard with a tooling support

UML4SPM WS-BPEL

Software Activity BPEL Process

SoftwareActivityKind BPEL Variable

Software Activity's attributes and associations

BPEL Variable with name = "attributeName" (respectively "associationEndName") and type = "XSD_Type". The type may be simple or complex and defined in a xsd file

Software Activity hierarchy and enclosing elements (actions, inputpins and ouputpin, control nodes, etc)

BPEL Sequence or Flow elements

Pre and Post Conditions of a SA BPEL Transition Condition element

Value of the Pre/Post Condition The text element of the BPEL Transition Condition

WorkProduct input or output of Actions BPEL Variable

Responsible Role BPEL Variable

TimeLimit of a SA BPEL Variable

Guidance BPEL Variable

Team BPEL Variable

Agent BPEL Variable

Tool BPEL Variable

Variable (in the context of a StructuredActivity)

BPEL Variable with name and type

ReadVariableAction followed by a WriteVariableAction

BPEL Assign with From (for reading) and To (for writing) within the Copy element

CallBehaviorAction (Sync / Async)BPEL Invoke activity (with input and output specification / Only input specification)

LoopNode with Test expressed via the association test:ExecutableNode

While activity with element Condition

RepeatUnitl activity

ForEach activityA Sample of mapping rules

23

The The UMLUML44SPMSPM-2-WS-BPEL Approach: Example-2-WS-BPEL Approach: Example

<?xml version="1.0" encoding="UTF-8"?><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>

Generated BPEL CodeUML4SPM Process model

24

The The UMLUML44SPMSPM-2--2-WS-BPELWS-BPEL Approach: Results 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

UMLUML44SPMSPM: Executability: 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 The UMLUML44SPMSPM Execution ModelExecution Model Approach Approach

• Definition of an Execution Model for UML4SPM– Specifies the precise execution behavior of UML4SPM elements

– Goal: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 UML4SPM Process Engine

27

The The UMLUML44SPMSPM Execution ModelExecution Model Approach: Approach: RationalRational

• 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 UML4SPM Metaclass

28

The The UMLUML44SPMSPM Execution ModelExecution Model: Rational: Rational

UML4SPM UML4SPM Executable Model

29

The The UMLUML44SPMSPM Execution ModelExecution Model: Rational: Rational

sourceActNode: ActivityNodesourceActNode: ActivityNode targetActNode: ActivityNodetargetActNode: ActivityNodeactEdgeInstance: ActivityEdgeactEdgeInstance: ActivityEdge

Validate Analysis Model (in: UML Analysis Model)

UML Analysis Model [Created]

Elaborate Analysis Model (in: Requirement Document)

UML Analysis Model [Created]

:Action :OutputPin :ActivityEdge

:InputPin

:Action

Un bout d’exemple de procédé

Comportement Opérationnel

30

The The UMLUML44SPMSPM Execution ModelExecution Model : Flexibility : Flexibility

• UML4SPM Language and its Execution Model are easily extensible

UML4SPM UML4SPM Execution Model

implementation

31

The The UMLUML44SPMSPM Execution ModelExecution Model : Results : 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

UML4SPM Execution Model used as a Process 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 of UML4SPM Process 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 The UMLUML44SPMSPM Execution ModelExecution Model : : TheThe Kermeta Kermeta approachapproach

• 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 The UMLUML44SPMSPM Execution ModelExecution Model : : TheThe Kermeta Kermeta approachapproach

UML.ecore

uml4spm.ecore

Constraints.ocl Semantics.kmt

UML.kmt

SPMSimulator.kmt

requires

package uml4spm;

require kermetarequire "uml4spm.ecore"require "UML.kmt"

aspect class SoftwareActivity{ operation execute(): Void is do

// Initialize actions having InputPins without incomming edges self.node.select{e|e.isInstanceOf(Action)}.each{ action | action.asType(Action).getInputPins().select{ pin | pin.incoming.empty }.each { pin | loadWorkProductToInputPins(pin) } }

//Intialize Activity's Intial Nodes self.node.select{e|e.isInstanceOf(InitialNode)}.each { inode | inode.asType(InitialNode).fire() } end

[...]

}

Context Team inv:

self.performers->forAll ( roleperformer |

not roleperformer.isKindOf (Tool)

)

Standard UML 2 metamodel provided by the Eclipse / UML project.

Implemenation of UML 2 semantics in Kermeta. This is provided by the UML Model Development Kits which is part of the Kermeta project.

Main of the simulator

34






• Conclusions & PerspectivesConclusions & Perspectives

OutlineOutline

35

Learned LessonsLearned 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 LessonsLearned 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 & ExecutionIssues in Software Process Modeling & Execution

• Dynamic evolution of process models– Identification of actions & conditions under which process models can be modified at runtime

….

Time

Process Model

Process Engine / Execution

Evolutions / Changes

Launching a new execution of the process

Stop execution !!

….

Process Model

Process Description

Process realization

Coherence

Coher

ence

Loss of Process’s

state

Coherence

38

Issues in Software Process Modeling & ExecutionIssues 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

Reda Bendraou [email protected] A Model-Driven Approach For Software Process Modeling and...

Documents

Transcript of Reda Bendraou [email protected] A Model-Driven Approach For Software Process Modeling and...