1. Alloy4SPV Reda Bendraou- LIP6
Part of Yoann Laurent’s Phd Work (a Year and half) - LIP6
Reda Bendraou- LIP6

2. Definitions: Agents, Activities & Artifacts
Software Process
Agent
Artifact
Activity
Modeler
Developer
Tester …
… build ...
Models
Source Code
Tests …
in order to produce…
Software
Problem?
How to make sure that they are always going to work the same way?
There’s a new guy, How to make sure he’ll know how to integrate to the rest of the team?
Pourquoi? Pour présenter le concepts qui seront utilisés pendant toute la présentation
Activity is an elementary task.
Artifact is a product created or modified during a process either as a required result or to facilitate the process.
Agent is a performer of the process. It may be a human or a computerized tool.
Software Process is a set of partially ordered activities realized by agents, which create/maintain sets of related artifacts.
Based on [Lonchamp, ICSP’93]

3. Definitions : Software Process Model
« … is an abstract software process description. It can be more or less formal. A given process model expresses: (i) a certain level of abstraction and (ii) a particular view on the process. »
[Lonchamp, SICSP’93]
Artifact
designModel
sourceCode
design
code
Et ça sert à quoi le modèle de procédé?
ça sert a comprendre comment on travaille, pour analyser notre façon de travailler et aussi pour automatiser ce qui peut être automatisé.
Valeur ajoutée
maintenant on a un modèle de ce que se passe pendant l’exécution, on peut l’analiser, par exemple, découvrir des problèmes…
Problem?
Le modèle est juste un modèle, ce que nos intèresse vraiment c’est son execution, c’est ce que se passe dans la vrai vie
Mais comment s’assurer que ça se passe comme ça pendant l’exécution d’un modèle de procédé? Bon, la réponse c’est ce qu’on appelle PSEE
__________
Le deuxième concept important ici est celui de Process Enactment, c’est à dire d’exécution du modèle de procédé.
Il faut voir que le modèle de procèdé décris un “monde idéal” et que dans la vrai vie il doit être exécuté.
Par exemple, dans ce cas, on doit démarrer l’activité design, pui travailler dans la construction de nôtre modèle de design, puis finir l’activité et démarrer la suivante et continuer jusqu’à la fin du procédé.
Le problème c’est que, comme je vois ai dit avant, cela réprésente un monde idéale aussi, car on suppose que nos agents sont parfaits, que notre modèle est parfait et que son exécution correspondra toujours a ce qu’on attends au moment où on conçoit le modèle de procédé.
Mais en réalité, ça ne se passe pas toujours comme ça, et il faut que d’abbord on puisse s’assurer que nos agents travaillent en cohérence avec le modèle de procedé, et puis il faut pouvoir les aider dans le cas ou ils ne le suivent pas.
Cela peut arriver soit parce que les agents ne sont pas parfaits, donc ils vont forcement dévier, soit parce que notre modèle de procédé n’est pas parfait, donc ils ne sont pas capables de le suivre à la perfection
UML:                          standard / outillé / +utilisé
Activity
Used for learning, vericiation and execution purposes

4. Some constraints are not represented in Software Process Models
Software Process Models never come alone
Organizational Constraints
Timing and resources assignement issues
Business Constraints
Specific and very contextual to the project
And of course, process models should be sound before deployment
Well-Known soundness properties

5. Behavioral Constraints
(1) Soundness A B C D
Control-Flow
{Initial, A, Decision, C, Merge, D, Final}
{Initial, A, Decision, B, Merge}
« CtoD » will not receive an offer
« D » input will never receive an offre C A B D
1..1
Data-Flow
{Initial, A, Decision, B, Merge, D, Final}
{Initial, A, Decision, C, Merge}
« Soundness of Workflow nets » [Aalst’11]
(1) Option to complete (2) Proper completion (3) No dead transition

6. Behavioral Constraints
(2) Organizational A B1 D
(1hour)
(1hour)
(1hour) B2
Execution path
Time
Possible in 3 hours?
{A, B1, D} 3h
yes
{A, B2, D} 4h
Impossible
{A, (B3)*, D}
[2:30 à oo]
yes but only if B executes only once
(2hour) B3
(30min)
[continue]

7. Behavioral Constraints
(3) Business A B
ImportantAction D
ImportantArtifact
Constraints specific to a given project:
ImportantAction should be executed whatever the execution path.
ImportantArtifact should be created whatever the execution path.
{Initial, A, Decision, ImportantAction, Merge,
D, Final}
{Initial, A, Decision, B(ImportantArtifact),
Merge, D, Final}

8. Software Process Constraintes
Logiques temporelles
LTL : Linear Temporal Logic
CTL : Computation Tree Logic

9. PSEE – Process-centered Software Engineering Environment
« … provides some assistance to its users by interpreting software proces models » Based on [Lonchamp, SICSP’93]
designModel
sourceCode
design
code
Process
Modeler
Le probléme c’est que ça ne se passe toujours comme prévu…
Agent
Manager
start
design
create
design
Model
end
design
Are the produced artifacts correct?
Is the agent doing what she/he is supposed to do?
Are the required artifacts present?

10. Process Models: Strong assumptions
1) The process model is perfect
captures the right steps, milestones, artifacts, roles & workflow
2) Process’s agents are strictly following the process model
They don’t take any personal initiative to perform the process differently
Process Models and PSEE, the means for companies
to ensure repeatability of the processes,
to gain in maturity
This based on two assumptions:
Ces assumptions sont peut être vraies dans certains domaine ou le process model est rigoureusement analysé, testé, etc. ou l’intervention humaine est minimisée, ou le contexte du projet ne contient pas beaucoup de paramètres/variantes qui peuvent influencé le déroulement du process
Ce n’est pas le cas dans le monde du soft. Process. Voici donc ce qui se passent dans la réalité

11. What the PSEE/Project Manager should do?
Process Deviations
Business Constraints
Process Model
Organizational Constraints ….
Process Description C o n s i t e c y C o n s i t e c y
Time
Process realization
Agent deviation
from the process model
Process Model and PSEE are the means to enforce the agent to follow the process
Deviation reasons: unforseen/unexpected situation
Misinterpretation/ambiguity of the process model (souvent les novices)
performing creative task folling its intuition /experience (les experts)
schedule constraints/orde from the project manager (les managers)
PSEE / Execution
What the PSEE/Project Manager should do?
Deviation: any action performed by an agent during the process execution which is not defined in the process model (In almost 98% of the time [Vissagio])
Deviation Vs Exception [Lerner et al.]

12. What are the impacts of these deviations?G H I J
Soundness ?
Organizational Constraints ?
Skip an Activity A E F G H I J
Business Constraints ? A E F G I J X
Add a new Activity

13. Consequences of agent’s deviations
Do they represent a threat to the process’s continuity & project management ?
Do we still have a chance to respect project deadlines?
What are the impacts of these deviations?
How can we make sure to preserve these constraints along the process execution if deviations or modifications have to occur?
At enact time : No means to prevent the process from a blocking state
The deviation level
Post enact: How can we improve the process model if we have the wrong data (or don’t have it at all)?

14. Our previous work on process deviations
Early detection of deviations [MoDELS 10a, b][TSI 13][Caise-F 12]
Handling of deviations [Caise 10, EDOCW11]
Living with Deviations [ASE 11]
But we never explored the idea of on the fly process model modification to handel deviations => need to calculate the impact of a modification/deviation

15. Requirements for more flexibiliy in handling process deviations
Ability to decorate the process model with various constraints
More reusability of process models
Ability to verify process models before execution
Ability to preserve process constraints at runtime even if deviations occur
Planning possible solutions

16. Our Proposition: Alloy4SPV
Alloy for Software Process Verification
UML2.0 Activities
fUML
Process Model
AlloyToProcess
PSEE
Alloy4SPV
Process View
Alloy Modules
is Enacted
Semantic.als
Alloy Analyzer
Process Engine
Syntax.als
ProcessToAlloy
ProcessModel.als
Satysfying Solution
Counter-example
interact
PropertiesToAlloy
Properties.als
Properties View

17. Our Proposition: Alloy4SPV
Constraints specification through a GUI
Automatic translation to Alloy

18. Why Alloy?
You define your own semantics, you don’t need to rely on any other formalims such as Petri Nets.
It supports a wide variety of properties such as invariants, user-defined assertions, LTL and CTL formulas with fairness constraints
It is expressive enough to represent a UML-based model associated with OCL constraints
A model-finder (and not a model-checker)
Simulation (run) : finds an instance that satisfies a set of constraintes
Checking (check) : finds a counter-example that violates a constraint
On-the-shelf SAT-solvers (MiniSat, ZChaff,...).

19. Contributions so far
Formalization of the fUML in first order logic [1]
Implementation of the fUML semantics using Alloy
Process execution engine and debugger based on fUML
A library of ready to use and customizable constraints expressed through a graphical interface
Graphical Alloy-based Verification tool
[1]

20. Results
Time to analyze the « OptionToComplete » property with Alloy4SPV
We had « good » results (18 bilion clauses . 7 Bilion vars.) in less than 1 minute
This proofs the effectiveness of the approach…

21. Still to achieve: Performance issues
Some Intuitions !

22. Abstracting the process
Sequence Reduction H A
BCD E FG H IJ
6 Actions I J A B C D E F G
10 Actions
Reduction -> abstraction du procece
Reduction Rules for Petri-Net [Murata’89,Desel’95]

23. Decomposition Program slicing methods
Single Entry Single Exit (SESE) [Johnson’94] A 2 H I J 1 A B C D E 3 F G

24. Scope and Constraints reductions
Impact Reduction H I J A E F G X F G X
Currently executing
New activity
Difficle de trouver le sous ensemble impacté
Scope and constraints reductions [SPE Journal 13]

25. Conclusion Some promising results so far
Two perspectives on the agenda
To increase performance at runtime
To use the “Synthesis” facility of Alloy to compute solutions and repair plans
Generateur de procédé / Debugger UML

26. Questions Paper accepted this year around this work Submitted
Executing and Debugging UML Models: an fUML extension, SAC’2013
Generation of Process using Multi-objective Genetic Algorithm, ICSSP’2013 (ICSE co-located event)
Submitted
Alloy4SPV: a Formal Framework for Software Process Verification, SLE’2013