Chapitre I : Rôle et évolution de la technologie de l'Information

Chapitre I
Rôle et évolution de la Technologie de l'Information

1. La Technologie de l’Information
L’intégration de la Technologie de l’Information au sein des entreprises dans les années
soixante, a été l’un des facteurs importants impliqués dans l’amélioration de leurs
performances. Les capacités de structurer et mémoriser l’information, la puissance de calcul
et les possibilités d’automatiser et de contrôler les traitements, sont autant d’atouts séduisants
et puissants offerts aux entreprises.

Pour définir la Technologie de l’Information, nous reprendrons une partie de la définition

proposée par [HUBER 90] :

§ Equipement qui transmet, manipule, analyse ou exploite de l’information,

§ Dans lequel un ordinateur traite l’information nécessaire à la réalisation de la tâche de

l’utilisateur, qu’elle soit de communication, de décision, de gestion ou de production.

Sans remonter aux années 30-50, "préhistoire" de l'informatique, nous allons en quelques
lignes retracer l'évolution de la technologie Informatique, depuis les années 60 jusqu'à nos
jours.

Dans les années 60 et début des années 70, l’utilisation première de cette technologie était
plutôt orientée vers la gestion des fiches de paie, la comptabilité et la gestion des commandes
et des factures clients. L'intérêt de l'informatique se limitait à ses capacités à traiter plus ou
moins rapidement de gros volumes de données et les ordinateurs avaient essentiellement le
rôle de super calculateurs. Leur coût était - très - élevé, leur rendement plutôt modeste et leur
manipulation ardue, raisons pour lesquelles ces outils n'avaient pas encore attiré l'attention des
managers des entreprises. Ouvrons ici une petite parenthèse pour signaler que l'expression
"Computer Science" est plutôt mal traduite par le terme "Informatique". En effet, le mot
"computer", dérivé du verbe "compute" exprime un traitement lié à un calcul, alors que le mot
Informatique réunit, comme chacun le sait, les mots "information" et "automatique". Or dans
ces années là, il n'est encore que question de données et pas d'informations.

A partir du milieu des années 70 jusqu'au début des années 80, les progrès réalisés autant dans
le domaine du matériel que des logiciels (ainsi que de la théorie), ont attiré l'attention des
entreprises (et principalement de leur management). Celles-ci se sont vite rendu compte des
innovations et des améliorations qu’il était possible de réaliser à l’appui de cette technologie.
D'outil utilitaire - "brasseur" de données - les systèmes informatiques passent à l'état d'outil
stratégique, pouvant apporter un avantage compétitif décisif aux entreprises qui prennent
l’initiative de les mettre en œuvre. Il ne s'agit plus uniquement de manipuler des données pour
automatiser des traitements, mais également de relier ces données afin de produire de
l'information. Il est alors véritablement possible de parler de Technologie de l'Information.

1
 Chapitre I : Rôle et évolution de la technologie de l'Information

Un bon exemple d'innovation compétitive au cours des années soixante-dix est celui du
système SABRE, développé par la compagnie aérienne « Américan Airlines » [PEAUCELLE
99]. Le but du système était de prendre en charge les demandes de réservation de places
d’avion, et de supporter la mise en œuvre des nouvelles stratégies commerciales de la
compagnie (par l'analyse des comportements et des besoins des clients). Malgré le coût élevé
du projet (environ 250 millions de dollars) l’innovation et les facilités apportées par ce
système ont rapidement séduit les clients et placé la compagnie au premier rang mondial. Plus
encore, les très importants bénéfices engendrés grâce à l’utilisation du système ont vite attiré
les autres compagnies qui ont requis la possibilité d’y être hébergées, augmentant de ce fait
les bénéfices de la compagnie initiatrice du système. Comme exemple beaucoup plus récent,
les entreprises ont vite compris le parti qu’elles pouvaient tirer de l’explosion de l’Internet et
des technologies du Web, ce qui se reflète aujourd’hui par l’omniprésence du concept du
commerce électronique.

L'aspect stratégique de la Technologie de l'Information est important à souligner car il est à

présent l'un des facteurs essentiels de l'évolution de la Technologie de l'Information, qui se
fait sur trois axes :

1. L'évolution du matériel (en terme d'augmentation de volume de stockage, de rapidité, de

fiabilité et réciproquement, de diminution de volume physique et de prix, etc.)
2. L'évolution des logiciels (plus complexes dans leurs fonctionnalités, plus graphiques, plus
orientés vers l'utilisateur, etc.)
3. L'évolution vers une utilisation de l'informatique en tant qu'outil stratégique, qui peut
apporter des "plus" significatifs face à la concurrence. Ces plus s'expriment en termes de
rapidité de réponse aux besoins des clients, maîtrise du contexte informationnel de
l'entreprise, étude des comportements des clients pour un obtenir une "connaissance", etc.
Cette évolution va créer une relation très étroite entre l'évolution des fonctionnalités et des
orientations des systèmes d'Informations, et les besoins managériaux et stratégiques des
entreprises.

A partir des années 80, la Technologie de l’Information s’est rapidement répandue au sein des
entreprises (notamment celles de tailles importantes) qui se sont équipées d’outils (matériel et
logiciel) de plus en plus performants, dédiés à des tâches spécifiques (comptabilité, gestion
des stocks, Conception Assistée par Ordinateur, etc.). Cette expansion s'est vue facilitée par
l'apparition de la "micro-informatique", plus légère, plus accessible et plus "démocratique".
On constate cependant que la structure informatique des entreprises s’est retrouvée composée
de ressources hautement spécialisées, mais dispersées et cloisonnées, avec peu
d’interopérabilité : c’est le phénomène des "îlots d’excellences" ("islands of automation")
[WALDNER 92]. Ce phénomène traduit le fait que la technologique de l’information a
surtout été utilisée de façon "ponctuelle" ou individuelle. Les conséquences ont été certes une
amélioration des performances des individus ou de petits groupes d’individus, mais ont induit
d’autre part de nouveaux problèmes de fragmentation de l’information et par conséquent, de
communication entre systèmes et services.

Le début des années 90 a observé une mouvance vers une mise en valeur de la nécessité de
sortir les compétences individuelles des différents services et départements de l’entreprise,
pour les concentrer dans une même entité "logique" autour d’un objectif commun. En termes
de Technologie de l’Information, cette mouvance s'est justifiée en partie par la constatation
du fait que les gains engendrés par l’usage de la technologie dans un but collectif étaient plus
importants que ceux générés par des technologies performantes, mais appliquées à des

2
 Chapitre I : Rôle et évolution de la technologie de l'Information

niveaux "individuels" [WARBOYS et al. 95]. Au niveau organisationnel, cela consiste à

extraire les activités réalisées par les différents départements (ou services) pour les regrouper
dans une même structure "logique", indépendante des frontières établies par la hiérarchie de
l’entreprise : les "processus métiers" [SHELTON 96]. En d'autres termes, au lieu de décrire
les fonctions des services de l'entreprise en termes d'activités non nécessairement liées
(fig.I.1), on identifie des ensembles d'activités, issues de fonctions diverses, mais réunies
autour de la réalisation d'un objectif commun (fig.I.2). Chaque ensemble correspond alors à
un processus clairement identifié. Le premier intérêt de cette organisation est d'apporter une
plus grande clarté et de faciliter la détection des problèmes éventuels et l'amélioration ciblée
des performances. Autre conséquence, l’activité perd son statut individuel pour s’inscrire dans
un cadre collectif de travail de groupe.

Direction Direction
Processus

Activité 1.1 Activité 1.1

Activité 1.2 Département 1 Département 2 Activité 1.2 Département 1 Département 2
… …

Service 3 Service 4 Service 5 Service 3 Service 4 Service 5

Activité 3.1 Activité 4.1 Activité 5.1 Activité 3.1 Activité 4.1 Activité 5.1
{
Fonction Activité 3.2
…
Activité 4.2
…
Activité 5.2
…
Activité 3.2
…
Activité 4.2
Activité
…
4.2 Activité 5.2
…

Figure I.1 – Organisation hiérarchique Figure I.2 - Organisation par processus

Fonctions par départements (services) Processus composé d’activités

Au niveau managérial, on constate l’émergence du concept de "l’entreprise en réseau"

[PEAUCELLE 99] et de nouvelles techniques d’organisation au sein des entreprises, telles
"l’organisation par projet" ou l’organisation "par processus stratégiques" [ZARIFIAN 97],
encore appelée "Business Process Orientation" (BPO) [McCORMACK 99]. Ce denier décrit
les entreprises mettant en œuvre la BPO comme étant des organisations qui mettent l'accent
sur une réflexion orientée processus, bénéfices et clientèle, à l'opposé des structures
hiérarchiques rigides. Globalement, ces méthodes se caractérisent donc par le passage du
découpage fonctionnel et hiérarchique des entreprises, à une organisation par processus
impliquant un engagement collectif des acteurs et des ressources, ainsi qu’une forte
intégration des données et des informations.

En résumé, l’accent est mis sur trois aspects importants :

1. La gestion des processus de l’entreprise,

2. La communication et la coordination des acteurs impliqués dans les processus,
3. Le partage des informations et des connaissances individuelles pour des informations
et des connaissances "organisationnelles" et collectives [GREENWOOD et al. 95].

Cette importance croissante de la notion de processus et du travail de groupe ainsi que les
changements dans la conception du travail et de son organisation impliquent nécessairement
des évolutions des technologies de l’information. Les prochains paragraphes se concentrent
sur les répercussions de ses évolutions sur celles des systèmes d'informations, en explicitant
quels sont les nouveaux besoins et les nouvelles fonctionnalités qui leur sont réclamées. Nous

3
 Chapitre I : Rôle et évolution de la technologie de l'Information

tentons également de clarifier certaines des notions présentées ci-dessus, notamment celles de
processus et de processus métiers.

2. La gestion des processus

2.1 Définitions
2.1.1 Définition d’un processus

Le dictionnaire en ligne des éditions Hachette [HACHETTE 97] nous renseigne qu'un
processus est "un développement temporel de phénomènes marquant chacun une étape". Plus
précisément, pour Davenport [DAVENPORT 93], un processus se définit comme étant un
ordonnancement d'activités à travers le temps et les lieux, ayant un début et une fin, avec des
entrées et des sorties clairement définies. En d’autres termes, un processus peut se définir
comme étant un ensemble d'étapes identifiées, chronologiquement reliées, consommant des
entrées et/ou produisant des sorties et dont la réalisation permet de satisfaire un objectif global
ou une transaction donnée. En étendant la définition, il est possible d’envisager qu’une étape
composant un processus, est elle-même composée d’autres étapes dont la réalisation complète
correspond globalement à celle de l’étape conteneur. Cette dernière possède donc les
caractéristiques d’un processus. Par conséquent, un processus peut être composé d’autres
processus que l’on pourra appeler "sous processus", afin de marquer leur appartenance à un
processus plus global.

En ce qui nous concerne, nous nous intéressons plus particulièrement aux processus mis en
œuvre au sein des entreprises. Dans ce type de processus, les différentes étapes les composant
correspondent à des activités ou des sous processus réalisés par certains éléments de
l’entreprise, qu’ils soient de type humain, matériel ou logiciel. Etant donné la diversité des
activités d’une entreprise, il est concevable de distinguer différents types de processus, liés à
la nature de leurs activités, à leurs objectifs ou à leur entrées sorties. Le paragraphe suivant
identifie les trois types de processus de base des entreprises et en donne une définition.

2.1.2 Types de processus en entreprise

[MEDINA-MORA et al. 92] distinguent trois types de processus : les processus matériels
("material processes") (également appelés processus physiques par [DENNING et al. 95]), les
processus informationnels ("information processes" ) et les processus métiers ("business
processes") :

1. Les processus matériels : ces processus se caractérisent par la manipulation, l'assemblage,

la livraison, la transformation, la mesure et le stockage d'objets physiques. Les processus
matériels lient entre elles des activités humaines ou automatisées, localisées dans le
monde physique. Il ne s'agit donc pas d'activités administratives, intellectuelles ou
spirituelle (quoique l'on puisse se poser la question de savoir si l'activité de rédaction d'un
livre est plutôt une activité intellectuelle ou une activité matérielle puisqu'elle a pour
conséquence immédiate la production d'un document physique). Pour [DENNING et al.
95], la mise en œuvre d'un processus matériel doit nécessairement aboutir à la production
d'objets physiques.

4
 Chapitre I : Rôle et évolution de la technologie de l'Information

2. Les processus informationnels : les processus informationnels relient entre elles des
activités automatisées (exécutée par des programmes) ou semi-automatisée (accomplies
par des humains en interaction avec des programmes). Ces activités créent, traitent, gèrent
et fournissent de l'information. L'infrastructure de base des processus informationnels est
fournie par les systèmes d'information de l'entreprise, tels les Systèmes de Gestion de
Bases de Données, les systèmes de gestion de transaction, etc.

3. Les processus métiers : Selon [SHELTON 96] et [DAVENPORT et al. 90], un processus
métier est une collection d'activités consommant des entrées (matériels, finances,
données,...) et délivrant un ou plusieurs résultats à orientation économique ("business
result") ou à forte valeur ajoutée pour l'entreprise. Un processus métier représente la façon
dont un travail est réalisé plutôt que l'organisation des personnes et des services, traversant
les barrières hiérarchiques et structurelles de l'entreprise. Pour [GEORGAKOPOULOS et
al. 95], les processus métiers se situent à un niveau conceptuel plus élevé que les deux
types précédents de processus de part leur orientation économique. Par suite, un processus
métier peut mettre en œ uvre d'autres processus, de type informationnel et/ou matériel, si
leur réalisation permet d'atteindre l'objectif qui est associé au processus métier.
L'expression de "processus métier" est l'une des nombreuses traductions de "business
process" que l'on peut rencontrer dans la littérature francophone. D'autres traductions
possibles et intéressantes sont par exemple "processus opérationnel", proposée par
[VERNADAT 99], processus d'entreprise, que l'on retrouve dans le lexique de la
Workflow Management Coalition (WfMC) [WfMC 99] ou encore "processus
stratégique", que l'on retrouve dans [ZARIFIAN 97]. Remarquons que pour F. Vernadat,
la notion de processus opérationnel adopte un sens plus global et concerne tout processus
d'intérêt pour l'entreprise. Néanmoins l'expression "processus métier", employée entre
autres dans la revue "Le Monde Informatique" nous semble convenir le mieux. En effet,
l'expression "processus métier" indique que le processus en question est directement lié au
métier de l'entreprise qui le met en œuvre. Par métier on comprend l'ensemble des
compétences d'une entreprise, son domaine d'activité, qui se traduisent par l'offre d'un
ensemble de services, produits ou artefacts, dont la consommation par des clients lui
permet de se pérenniser et de se développer. L'échec ou le succès des processus métiers
est le principal indicateur de la santé de l'entreprise, donc de la qualité de ses compétences
dans son métier.

Notons enfin que [DENNING et al. 95] proposent un autre type de processus qu'ils
appellent "processus humains" ("human processes"). Ces processus décrivent des accords
passés entre personnes et organisations (sous la forme de contrats de type client -
fournisseur) dans un but de coordination des éléments impliqués dans les contrats. Les
processus humains permettent de gérer les processus matériels et informationnels.

Nous avons souligné ci-dessus l'importance de la réussite des processus métiers dont dépend
la réussite des entreprises qui les mettent en œuvre. Par conséquent, l'une des préoccupations
majeures des entreprises est d'améliorer et d'optimiser l'exécution de ces processus. Pour ce
faire, un certain nombre de méthodes de management ont été développées, que nous
présentons succinctement dans les paragraphes suivants.

2.2 Amélioration et optimisation des processus métiers

Etre compétitif, vendre, augmenter sa part de marché est une préoccupation évidente des
entreprises, quel que soit leur métier. Dans les années 70, l'un des meilleurs atouts de

5
 Chapitre I : Rôle et évolution de la technologie de l'Information

compétitivité était de se positionner sur le marché avec des prix moins élevés que ceux de la
concurrence, grâce à un débit de production important [ZARIFIAN 97]. Depuis le milieu des
années 80, ce principe de production massive et de prix réduit ne suffit plus. En effet, un
grand nombre de facteurs viennent modifier la donne, parmi lesquelles notamment: une
clientèle de plus en plus exigeante au niveau des prix mais surtout de la qualité des produits et
une compétition accrue due à l'ouverture des marchés. Ces facteurs s'associent à d'autres
contraintes, telle l'innovation et la rapidité de mise sur le marché.

L'amélioration des processus métiers est par conséquent, une des préoccupations majeures et
permanente des entreprises qui souhaitent rester compétitives. Pour y parvenir, plusieurs
méthodes de management sont utilisées, dont deux particulièrement connues et intéressantes:
l'amélioration continue (ou progressive) des processus ("Continuous Process Improvement"
ou CPI) et la reconception des processus métiers ("Business Process Reengineering" ou BPR).
Nous les décrivons succinctement dans les paragraphes suivants, en reprenant la terminologie
anglo-saxonne, plus répandue.

2.2.1 Le "Continuous Process Improvement"

Le "Continuous Process Improvement" (également appelé "Total Quality Management" par

certains auteurs alors que pour d’autres le TQM est plus global), correspond à des
programmes et des initiatives qui mettent l'accent sur une amélioration incrémentale des
processus de l'entreprise, étalée sur une période de temps plus ou moins longue
[DAVENPORT 93]. Le CPI est donc une approche progressive, qui consiste à comprendre,
mesurer et évaluer le résultat des processus des entreprises et faire évoluer leurs performances
en conséquence. Le CPI se caractérise également par une approche "botton up", c'est à dire
qui part de la partie exécutive du processus, en aval, vers la partie stratégique et
décisionnelle, en amont. Les principales étapes de la mise en œuvre d'une approche de PCI
peuvent se résumer de la façon suivante (fig. I.3) :

§ Commencer par documenter l'état des processus actuels ("As is"), c'est à dire la façon
dont le travail est réalisé,
§ Définir des critères pour mesurer les performances des processus,
§ Exécuter le processus,
§ Collecter et évaluer les résultats,
§ Identifier les lacunes, cibler les améliorations et les implémenter dans le nouveau
processus,
§ Mesurer le nouveau processus,
§ etc.
1. Documenter
les
7. Executer
Processus 2. Etablir des
les
Processus critères
d ’évaluation
6. Implémenter
les 3. Exécuter
améliorations les
Processus
5. Identifier les
lacunes 4. Mesurer
les
performances

Figure I.3 – Continuous Process Improvement

6
 Chapitre I : Rôle et évolution de la technologie de l'Information

Les intérêts principaux du CPI sont la limitation des risques pris lors de l'apport des
modifications et la tendance à converger effectivement vers de meilleures solutions. A
l'opposé, les principaux inconvénients qui sont reprochés à cette méthode sont, d'une part la
"lenteur" de la méthode, qui n'est pas toujours adaptée aux besoins de réactivité et
d'adaptation de l'entreprise face à des situations nouvelles. La rapidité avec laquelle une
entreprise réagit aux nouvelles donnes du marché étant en effet un facteur crucial de réussite.
D'autre part, l'utilisation du CPI peut s'avérer peu efficace dans le cas où un processus métiers
n'est plus du tout en phase avec le monde réel, donc qu'il n'est plus "récupérable". C'est
justement dans ce contexte de réactivité et de changements cruciaux que s'inscrit la démarche
du BPR, décrite dans le paragraphe suivant.

2.2.2 Business Process Reengineering

A l'opposé du CPI, le BPR opte pour des solutions radicales et une amélioration drastique des
performances. [HAMMER et al. 93] définissent le BPR comme étant une façon de repenser et
de reconcevoir fondamentalement et radicalement les processus métiers, dans le but
d'atteindre des améliorations importantes dans les critères de performances critiques tels le
coût, la qualité, les services et la vitesse. Cette approche se base sur le concept de "l'état net"
("clean state"), c'est à dire la définition de nouveaux processus n'ayant aucun rapport (mise à
part l'objectif de performances) avec les précédents. Le BPR préconise donc des changements
radicaux, que ce soit dans l'organisation et la structure de l'entreprise ou des méthodes de
travail. Enfin, contrairement au CPI, le BPR adopte une approche "top down", de l'amont vers
l'aval. Les principales étapes pour l'application d'un BPR peuvent se résumer tels qu'il suit
(fig.I.4) :

§ Définir les objectifs des nouveaux processus, leur champ d'action et l'état à atteindre
("to be state"),
§ Identifier les processus à reconcevoir. Deux approches sont utilisées [YOGESH 98].
La première se concentre sur les processus les plus importants ou ceux qui sont en
contradiction avec les objectifs définis dans la première étape. La deuxième approche
consiste à identifier tous les processus d'une organisation et de leur affecter un ordre
de priorité en fonction de l'urgence de la reconception.
§ Comprendre et évaluer les processus existants,
§ Etablir un plan de transition, en comparant le "to be" avec le "as is".
§ Implémenter les nouveaux processus.
Prototypage
et évaluation

Définir le champ Identifier les Evaluer Etablir un plan Implémenter les

du processus processus l ’existant de transition processus

Figure I.4 – Business Process Reegineering

Le BPR a provoqué un engouement important au début des années 90. Ce succès s'est
cependant émoussé petit à petit et le nombre des détracteurs de cette approche a
proportionnellement augmenté. Ce revirement de situation est principalement du aux faibles
résultats obtenus par l'application de cette méthode. Ainsi, selon [YOGESH 98], 70% des
projets de BPR ont été un échec, dont les causes principales sont notamment:

§ Le BPR est une méthode trop "cassante" voir "despotique" selon [STRASSMAN 94]
qui compare cyniquement les principes du BPR aux méthodes révolutionnaires. Sans

7
 Chapitre I : Rôle et évolution de la technologie de l'Information

aller jusque là, force est de constater la réticence voir le déboussolement des employés
face aux remises en cause et aux changements radicaux de leurs habitudes, de leur
façon de travailler et de la structure de l'entreprise. Ces modifications trop rapides,
accompagnées de la réticence de certains entraînent souvent un temps d'adaptation
important, une hésitation qui limite l'échange d'idées, bridant l'intérêt du BPR.
Remarquons toutefois que toujours selon [STRASSMAN 94], dans les cas critiques où
la rapidité de réaction est le seul atout disponible, le BPR reste l'une des seules
alternatives avantageuses.

§ Pour [DAVENPORT 94], une conception des processus uniquement selon l'approche
"top down" n'est pas réaliste. La participation de ceux qui réalisent le travail est une
condition essentielle d'acceptation et de réussite des nouveaux processus.

§ Une autre cause de l'échec de projet de BPR est le manque de réalisme des objectifs et
des attentes fixées avant la mise en œuvre du BPR. En effet, il semblerait que certains
managers aient plus tendance à s'intéresser au fait d'appliquer le BPR en tant que
tactique, plutôt que de se concentrer sur la stratégie de mise en œuvre [YOGESH 98].
En conséquence, le BPR est mal préparé et les performances à atteindre sont
surévaluées.

§ Le recours au BPR dans des cas ne justifiant pas une remise en question totale de
l'acquis. On peut donc remarquer que pour les deux derniers points, les causes des
échecs sont essentiellement dues à des erreurs "humaines" d'appréciation et
d'évaluation, et non dues au BPR lui-même.

Enfin et pour clore cette partie, le tableau suivant (extrait de [DAVENPORT 93]) résume les
principales caractéristiques des deux méthodes:

CPI BPR
Niveau de modifications Incrémental Radical
Point de départ Processus existant Etat net
Fréquence des modifications Unique/Continue Unique
Temps requis Court Long
Participation Bottom-up Top-down
Champ d'action Court terme Long terme
Risque Modéré Elevé
Type de modifications Culturelles (discutable1) Culturelles/ Structurelles

Tableau I.1 - Comparatif du CPI et du BPR

2.3 Modélisation des processus

Quelle que soit la méthode de management et quel que soit le processus impliqué, on retrouve
au moins un élément commun, qui est la nécessité de pouvoir évaluer les performances et le
fonctionnement des processus. Il est évident que la meilleure évaluation est obtenue en
situation réelle. Il est tout aussi évident que la situation réelle est la plus risquée, puisque les
erreurs se répercutent réellement sur l'entreprise. Il est donc intéressant de disposer au

1
Remarque personnelle. Les changements peuvent aussi bien être structurels et organisationnels, sans
nécessairement impliquer de profonds bouleversements.

8
 Chapitre I : Rôle et évolution de la technologie de l'Information

préalable de la possibilité de simuler et de tester ces processus sur des représentations fidèles
de ces derniers. Cette possibilité est entre autres offerte par la modélisation préalable des
processus. Qu'est ce qu'un modèle de processus et quels sont les types de modélisations
possibles ? Enfin, quels sont les critères permettant d'évaluer les entreprises et en particulier
leurs processus métiers ? Les deux paragraphes suivants tentent d'y apporter quelques
éléments de réponses.

2.3.1 Modèle de processus

Un modèle est une abstraction d’un certain sujet, matériel (par exemple, une voiture) ou
immatériel (par exemple, un processus) existant ou susceptible d’exister. Par exemple, un
modèle d’un processus métier peut correspondre à un processus existant ("as is") ou à un
processus auquel on veut aboutir ("to be"). Un modèle se concentre en général uniquement sur
certains des aspects du sujet, qui présentent un intérêt pour le concepteur du modèle
[GREENWOORD et al. 95] [MULLER 98].

La modélisation présente plusieurs intérêts : d'une part, elle permet d'obtenir une
représentation observable, manipulable et évaluable d'un sujet, qui permet de le comprendre et
de l'étudier sans avoir à affecter le sujet lui-même. D'autre part, l'abstraction faite lors de la
modélisation permet de simplifier le sujet abordé en ne s'occupant que des aspects qui lui sont
significatifs.

Un modèle de processus est par conséquent une abstraction d'un ensemble d'activités,
représentant leur enchaînement chronologique, leurs entrées et sorties ainsi que les entités
chargées de réaliser les activités. Pour [SNOWDON 95], les modèles de processus permettent
de comprendre et de représenter le comportement de systèmes, tels par exemple une
entreprise. Plus spécifiquement, [KAWALEK et al. 97] et [BERRY 98] identifient cinq
fonctionnalités et intérêts principaux de la modélisation de processus :

§ Faciliter la compréhension du fonctionnement de l'entreprise au travers de ces

processus,
§ Faciliter la communication entre les participants au processus d'une part et les
concepteurs et décideurs d'autre part,
§ Permettre et supporter l'amélioration des processus (CPI) ou leur reconception (BPR),
§ Définir une base pour permettre l'automatisation de l'exécution des processus,
§ Supporter la gestion des processus (grâce à leur automatisation).

Les trois premiers intérêts de la modélisation de processus s'inscrivent dans ce que

[SNOWDON 95] appelle la "modélisation descriptive". Ce type de modélisation a pour but de
décrire les processus dans un but de compréhension et de représentation du comportement des
organisations. Les deux derniers intérêts de la modélisation de processus s'inscrivent quant à
eux, dans ce que le même auteur appelle la "modélisation active". Son but est de construire
des modèles de processus qui serviront de base pour un support informatisé de leur exécution,
l'une des finalités les plus intéressantes.

Cette classification du type de modélisation est complétée par celle, très intéressante,
proposée par [GREENWOOD et al. 96] qui proposent de distinguer trois types de modèles de
processus : les modèles "passifs" les modèles "passifs dynamiques" et les modèles "actifs" :

9
 Chapitre I : Rôle et évolution de la technologie de l'Information

1. Les modèles passifs : selon les auteurs, les modèles sont le plus souvent réalisés à l'aide de
moyens passifs de modélisation. Un modèle passif est un modèle qui capture la structure
ou l'aspect d'un système (dans notre cas, un processus) à un moment donné. Une fois le
modèle créé, il devient indépendant du sujet qu'il représente, c'est à dire qu'il n'est pas
affecté par des évolutions ou des modifications du sujet. Ce type de modèle est celui qui
est le plus communément utilisé dans les systèmes d'informations tels les bases de
données.

2. Les modèles dynamiques passifs : ce sont des modèles passifs qui permettent de
représenter le comportement d'un processus ou d'un système. Ils sont principalement
utilisés à des fins de simulation, pour l'analyse et la validation des systèmes modélisés. Ils
peuvent également servir de support pour une exécution automatisée.

3. Les modèles actifs : les modèles actifs utilisent des techniques de modélisation leur
permettant de rester liés au sujet avec lequel ils deviennent synchronisés. Toute
modification du sujet est donc automatiquement répercutée sur le modèle qui reflète à tout
moment l'état et la structure du sujet. Deux types de liens unissent un modèle actif à son
sujet: les liens "réactifs" et les liens "actifs". Le premier type de lien permet aux modèles
actifs de contrôler le comportement du sujet. Les modèles reçoivent des stimuli (par
exemple un état du sujet) qui une fois évalués induisent un comportement approprié au
sujet. Les liens actifs quant à eux permettent aux modèles actifs d'évoluer en fonction de
l'état du sujet. Malgré le fait que le développement de ce concept par [GREENWOOD et
al. 95] présente certaines lacunes, notamment au niveau de l'implémentation des modèles
actifs, il n'en reste pas moins que ce concept est très intéressant car les modèles actifs
reflètent le fait qu'un processus métier ne peut être figé. En effet, et c'est ce qui justifie le
recours au BPR et au CPI, l'environnement des entreprises est dynamique, et par
conséquent, l'organisation des entreprises et du travail doit être constamment revue pour
correspondre à la réalité. Nous reviendrons d'ailleurs plus longuement sur ces aspects
d'adaptabilité dans la suite de cet ouvrage.

2.3.2 Critères d'évaluation

Si l'un des intérêts de la modélisation des processus réside dans la possibilité de simuler et
d'évaluer les processus mis en œuvre (ou à mettre en œuvre) dans l'entreprise, il est intéressant
de se pencher rapidement sur le choix des critères retenus pour cette évaluation. Globalement,
un critère d'évaluation pourrait se définir comme étant une mesure standard permettant de
mesurer la performance d'une entité (dans notre cas une entreprise) dans un domaine ou à un
niveau donné (par exemple pour un processus métier). Le critère d'évaluation le plus global
pour une entreprise est sans doute sa performance financière. Toutefois, plusieurs aspects
contribuent à différents niveaux à l'état financier d'une entreprise. Il est donc intéressant d'y
associer des critères d'évaluation. [TRIMBLE 98] distingue cinq niveaux auxquels il est
possible d'associer des critères :

1. Les clients : cette catégorie comprend deux critères, la capacité de l'entreprise à satisfaire
les besoins des clients, et la satisfaction du client. Malgré les apparences, il existe une
différence entre ces deux critères. Le premier correspond au fait q'une entreprise est
capable techniquement de satisfaire une demande client (selon par exemple un certain
cahier de charge ou des exigences). Le deuxième critère correspond à l'évaluation du
client par rapport au produit proposé par l'entreprise.

10
 Chapitre I : Rôle et évolution de la technologie de l'Information

2. Les processus métiers : c'est la partie qui nous intéresse le plus. On y distingue trois
critères principaux d'évaluation. La durée des cycles, la qualité des services et des
produits, le coût des activités des processus.

3. Les fournisseurs : évaluer les performances des fournisseurs dans la satisfaction les
besoins de l'entreprise.

4. Les critères financiers : deux en particuliers. La profitabilité et les parts de marché.

5. Les employés : en termes de satisfaction professionnelle.

Ces cinq critères s'inscrivent dans deux catégories principales, les "critères de performances"
et les "critères de diagnostic" :

1. Les critères de performances : ce sont des mesures de haut niveau qui expriment ce qui est
fait, c'est à dire la performance globale des niveaux mesurés. Ces critères sont "externes",
c'est à dire qu'ils reflètent essentiellement le résultat d'une évaluation, par exemple par les
clients.

2. Les critères de diagnostic : ce sont des mesures qui permettent d'évaluer ce qui ne va pas
dans l'entreprise, par exemple pourquoi un processus n'atteint pas les objectifs fixés. Ils
sont donc "internes" par nature.

3. Rôle et évolution de la Technologie de l’Information

Mary Parker Follet écrivait en 1927 [GREENWOOD et al. 95] que les entreprises devaient
faire face à trois problèmes majeurs : premièrement, comment former les membres de
l'organisation afin que chacun puisse donner de son mieux; deuxièmement, comment procurer
à chacun tous les moyens pour mettre en œuvresa contribution; et troisièmement, comment
unifier les différentes contributions : c'est le problème de la coordination, le c œur des
entreprises. Bien évidemment, la technologie de l'information a connu de profonds
bouleversements et de fulgurantes améliorations depuis 1927. Il n'en reste pas moins que cette
définition reste étonnamment moderne puisque effectivement, ces trois problèmes sont
toujours d'actualité.

Comme nous l'avons vu au début de ce chapitre, jusqu'à une époque peu lointaine, la
technologie de l'Information s'était essentiellement préoccupée de fournir des solutions aux
deux premiers problèmes – c'est à dire, fournir de l'information et des outils de travail
performants. Toutefois les concepts de managements dont nous avons parlé dans les
paragraphes précédents, ainsi que la nouvelle perception de l'individu en tant que membre
d'un groupe, ont généré de nouvelles contraintes et de nouveaux besoins. En particulier,
l'accent est mis sur les problèmes de coordination, de travail de groupe et de communication.
C'est donc vers le support des ces trois aspects stratégiques que s'est orientée la Technologie
de l'Information, au début des années 90. Par conséquent, l'importance de cette technologie
s'est accrue, passant de l'état de ressource privilégiée, de super calculateur pour devenir un
partenaire, voir mieux, un environnement de travail ("business environement" [BROWNING
90]).

11
 Chapitre I : Rôle et évolution de la technologie de l'Information

Le premier indice marquant le fort besoin de communication est donné par deux faits
importants et complémentaires. D'une part, on constate depuis au moins une vingtaine
d'années l'augmentation du nombre et de l'importance des réseaux et des technologies de la
télécommunication. L'exemple le plus marquant est celui de l'explosion des technologies de
l'Internet et de ses variantes : Intranet et Extranet pour les entreprises. D'autre part, on
constate, dans la même période de temps, un grand effort placé dans la recherche de
standards de représentation de l'information pour faciliter l'EDI (Echange de Données
Informatisées), dont les deux champions sont le langage STEP et plus récemment XML,
dernier-né de la sphère Internet.

Au niveau du support de travail de groupe, les années 90 ont vu naître une nouvelle discipline
de la Technologie de l'Information, la TCAO ou technologie de "Travail Coopératif Assisté
par Ordinateur" (CSCW en anglais, pour "Computer Supported Cooperative Work") encore
appelée "Collectique". La TCAO se propose de fournir des outils dédiés au support du travail
de groupe. L'AFCET en donne la définition suivante [AFCET 94] : "La Collectique regroupe
l'ensemble des techniques et des méthodes qui contribuent à la réalisation d'un objectif
commun à plusieurs acteurs, séparés ou réunis par le temps et par l'espace, à l'aide de tout
dispositif interactif faisant appel à l'informatique". Quant aux outils permettant de supporter le
travail coopératif, ils sont nommés Groupware ou Collecticiels.

3.1 Classifications des Collecticiels

Pour l'AFCET ainsi que pour certains spécialistes des Collecticiels, toute application
informatique ou outil permettant de mettre en œ uvre la collectique tombe dans la catégorie
des Collecticiels. Cette opinion n'est cependant pas complètement partagée par tous, nous y
reviendrons par la suite.

En se basant sur la première définition des collecticiels, il est possible de les répartir en trois
catégories : les outils de communication, les outils de partage et les outils de coordination.
Chaque catégorie réunit un ensemble d'outils contribuant au support du travail de groupe par
l'intermédiaire de médias spécifiques :

1. Les outils de communication : cette catégorie réunit tous les outils permettant à des acteurs
distants de communiquer. La communication peut être asynchrone ou synchrone. Dans le
premier cas, elle est assurée par des applications informatiques telles que :

§ La messagerie électronique,
§ Les programmes de "tchatche" ("chat" en anglais) où deux ou plusieurs personnes
peuvent discuter par l'échange rapide de messages,
§ Les forums de discussion ("forums" et "newgroups") où une personne peut proposer
un sujet ("topic") et où d'autres personnes peuvent réagir en déposant des messages
auxquels peuvent à leur tour réagir d'autres personnes. Chaque message est
consultable par l'ensemble des individus inscrits au forum.
§ Les tableaux d'affichage ("bulletin boards") où les intervenants peuvent laisser des
notes visibles par d'autres personnes.

La communication synchrone quant à elle est assurée par des outils tels que :

§ La vidéoconférence ou visioconférence, où un intervenant est filmé par une caméra et

est visible par plusieurs personnes. La retransmission peut être hertzienne ou, comme

12
 Chapitre I : Rôle et évolution de la technologie de l'Information

c'est de plus en plus le cas, via un réseau, numérique (tel Numéris de France Telecom)
ou plus communément TCP/IP (Internet). La tendance actuelle est d'avoir plusieurs
utilisateurs filmés par une mini-caméra (une "webcam"), pouvant apercevoir et
dialoguer avec d'autres utilisateurs en s'inscrivant sur le même canal. Un exemple bien
connu est "Net Meeting" de Microsoft.
§ Les outils de tchatche synchrones, dont le plus connu du grand public est ICQ.

2. Les outils de partage : cette catégorie recouvre tous les outils qui permettent à des
utilisateurs de partager un même espace de travail, de partager ou d'échanger des fichiers
ou de partager la même application informatique. Parmi ces applications on retrouve les
applications de type "tableau blanc", où des utilisateurs peuvent écrire ou dessiner
simultanément ou selon un mode de gestion de tour de parole. Parmi ces applications,
notons SharedX et ProShare qui regroupe également des outils de communication tels le
chat et la visioconférence.

3. Les outils de coordination : les outils de coordination permettent de gérer et coordonner

les activités de plusieurs utilisateurs. En général cette coordination s'appuie sur un
ensemble de règles de synchronisation ou une modélisation préalable d'un ou de plusieurs
processus impliquant plusieurs personnes. Le choix du mode de coordination dépend
essentiellement de l'importance du processus, l'usage de règles étant souvent associé à des
collecticiels de partage, dans des buts de régulation de tour de parole. Cette catégorie
correspond à ce que l'on appelle le Workflow. Cette technologie s'est fortement
développée depuis le début des années 90, en parallèle à l'évolution des méthodes de CPI
et de BPR dont elle constitue l'un des outils de référence. Le Workflow est donc la partie
de la Technologie de l'Information qui s'occupe de la coordination des acteurs des
processus des entreprises, processus dont ils assurent également l'exécution et la gestion.
Cette description plus que sommaire est reprise en détail dans le prochain chapitre. Le
Workflow constitue la matière première de la réflexion développée dans cet ouvrage.

Une autre classification des collecticiels propose de les répartire en deux catégories : les
collecticiels synchrones et les collecticiels asynchrones [URNES et al. 94]. La première
comprend tous les outils de communication asynchrone dont nous avons parlé ci-dessus, plus
la catégorie des outils de coordination. La deuxième classe comprend tous les outils de
communication et de partage en temps réel.

3.2 Workflow versus Collecticiel

Pour certains spécialistes, le Workflow ne fait pas partie de la classe des collecticiels mais de
celle plus générale des outils de TCAO [JOOSTEN et al. 95], [GEORGAKOPOULOS et al.
95], [NURCAN 96]. Le Workflow est orienté vers la gestion et l'automatisation des processus
de l'entreprise. A la limite, si l'on souhaite apporter une nuance, on pourrait dire que la plupart
des collecticiels supportent le travail en groupe alors que le Workflow intervient dans un
travail de groupe. La nuance est importante (fig. I.5, fig. I.6). Le travail en groupe implique la
présence d'outils permettant à des personnes géographiquement distantes d'interagir de façon
plus ou moins synchrone, dans un plan commun virtuel de travail, et d'y partager des objets et
des informations de façon plus ou moins synchrone également. Le travail de groupe implique
la présence de personnes interagissant de façon asynchrone, unies autour de la réalisation d'un
objectif commun. La synchronisation et la coordination dans les collecticiels se situent au
niveau de l'activité en cours. Pour le Workflow, elles se situent au niveau du processus. Dans
un collecticiel, l'accent est mis sur le groupe. Dans le Workflow l'accent est mis sur le

13
 Chapitre I : Rôle et évolution de la technologie de l'Information

processus. Ce dernier fédère les acteurs et crée le groupe grâce aux capacités de coordination
fournies. C'est donc le processus qui définit le groupe dont chacun des membres est
responsable d'une ou de plusieurs activités à un moment donné. A l'opposé dans les
collecticiels, se sont les membres du groupe qui définissent l'activité.

Processus
Activité commun
commune
Activité 1
A
Espace partagé

C A
Objets
partagé B
s Activité 2 Activité 3

A
B
Activité 4
C

Figure I.5 – Travail en groupe Collecticiels – Figure I.6 – Travail de groupe

Support de l'activité commune Workflow – Support des processus

On peut être d'accord avec cette opinion, ce qui est notre cas, ou la réfuter. Notre but n'est pas
ici d'établir une classification définitive que d'autres ont essayé de poser sans franc succès,
mais d'afficher les différents points de vue. L'important est surtout de retenir que le Workflow
est la technologie qui propose des outils de coordination des activités, de gestion et
d'automatisation des processus des entreprises. Le chapitre suivant tente d'apporter des
définitions plus amples et plus précises.

Bibliographie

[AFCET 94] AFCET, "Enquête sur la pratique de la collectique (groupware) en France.

Rapport d'étude, septembre 1994.
[BROWNING 90] J. Browning, "Information Technology: The Ubiquitous Machine". The
Economist, 16 Juin 1990, p.5.
[DAVENPORT et al. 90] T.H. Davenport, J. Short. "The new Industrial Engineering : Information
Technology and Business Process redesign". Sloan Management Review,
1990, pp. 11-27.
[DAVENPORT 93] T.H. Davenport, "Process Innovation". Harvard Business School Press,
Boston, MA. 1993.
[DAVENPORT 94] T.H. Davenport, "Reegineering: Business Chnage of Mythic Proprtions?".
MIS Quaterly, 1994, pp.121-127.
[DENNING. Et al. 1995] P. Denning, M. Hieb, D. Menascé, "The workflow Module".
[Link] 1995.
[GREENWOOD et al. 95] R.M. Greenwood, I. Robertson, R.A. Snowdon, B.C. Warboys, "Active
Models in Business". Proceedings of the Business IT Conference,
Manchester, 1995.
[GEORGAKOPOULOS et al. 95] D. Georgakopoulos, M. Hornick, A. Sheth, "An Overview of Workflow
Management : From Process Modeling to Workflow Automation
Infrastructure", Distributed and Parallel Databases, An International Journal,
3, 1995.
[HUBER 90] G. Huber, "A Theory of the Effects of Advanced Information Technologies
on Organizational Design, Intelligence and Decision Making". Academy of
Management Review, issue n°15, 1990; pp. 47-71.

14
 Chapitre I : Rôle et évolution de la technologie de l'Information

[JOOSTEN et al. 95] [Link], S. Brinkkemper : "Funamental Concepts for Workflow

Automation in Practice". Centre for Telematics and Information
Technology, University of Twente, Enschede 1995.
[KALLAK et al. 97] P. Kallak, P. Kueng, "The Usefulness of Process Models : A Lifecycle
Description of how Process Models are used in Modern Organisations".
[Link]
[MULLER 98] P.A. Muller, "Modélisation Object avec UML". Eyrolles. 1998
[NURCAN 96] S. NURCAN, "Analyse et conception de systèmes d'information
coopératifs". Techniques et science informatiques, Vol. 15, n°9, 1996; pp.
1287 – 1315.
[PEAUCELLE 99] J.L. Peaucelle. "Systèmes d'information : le point de vue des gestionnaires".
ECONOMICA. 1999.
[SNOWDON 95] [Link], "Overview Of Process Modelling".
[Link] 1997.
[SHELTON 96] R.E. Shelton, "Business Objects – Workflow". Data Management Review,
Mars 1996.
[STRASSMAN 94] P.A. Strassman, "The Hocus-Pocus of Reengineering".
[Link] 1994.
[URNES et al. 94] T. Urnes, R. Nejabi, "Tools for Implementing Groupware : Survey and
Evaluation". Technical Report N° CS-94-03. Dpt Of Computer Science,
York University, Ontario, Canada. 1994.
[VERNADAT 96] F. Vernadat. Enterprise Modeling and Integration – Principles and
Applications. Chapman & Hall, 1996.
[VERNADAT 99] F. Vernadat. Techniques de Modélisation en Entreprise : Application aux
Processus Opérationnels. Economica. 1999.
[WARBOYS et al. 95] B.C. Warboys, R.A. Snowdon, "An Introduction to Process-Centered
Environments". Software Process Modelling and Technology. A.
Finklestein, J. Kramer, B. Nuseibeh Editors, Advanced Software
Development Series, Research Studies Press. 1995.
[WfMC 99] Workflow Management Coalition. "Terminologie et Glossaire Workflow".
v. 2.0 Fev. 1999. [Link]
[YOGESH 98] M. Yogesh. "Business Process Redesign : An Overview," IEEE Engineering
Management Review, vol. 26, no. 3, Fall 1998.
[ZARIFIAN 98] P. Zarifian, "L'émergence de l'organisation par processus : à la recherche
d'une difficile cohérence" dans "Cohérence, Pertinence et Evaluation",
groupe ECOSIP. ECONOMICA. 1996. Pp. 65 - 86.

15
 Chapitre II : Workflow - Présentation, définitions et Concepts

Chapitre II
Workflow – Présentation, définitions et Concepts

1. Le Workflow – Origines et Définitions

Le marché du Workflow s'est développé au début des années 90 et a connu une forte
croissance au milieu de la décennie. Aujourd'hui ce marché s'est un peu stabilisé et est en train
de se réorienter, comme nous le verrons à la fin de ce chapitre.

Comme c'est souvent le cas en informatique dès qu'une technologie a le vent en poupe,
l'étiquette "Workflow" a été abondamment utilisée pour qualifier divers systèmes et outils
informatiques. De plus, la montée en force du Workflow a coï ncidé avec celle de deux autres
événements : d'une part l'engouement pour de "nouvelles" méthodes de management telles le
Continuous Process Improvement (CPI) et le Business Process Reegineering; d'autre part on
constate l'apparition d'une technologie informatique dédiée au travail de groupe, la TCAO ou
Travail Coopératif Assisté par Ordinateur. Par conséquent, une certaine confusion entoure le
Workflow et certaines questions se posent : en quoi les différentes méthodes citées ci-dessus
sont-elles liés ? A quelle catégorie - Management ou TCAO - le Workflow appartient-il ? Plus
simplement qu'est ce que le Workflow ?

Une partie des réponses aux deux premières questions posées ci-dessus a été fournie dans le
chapitre précédent, notamment en ce qui concerne la place du Workflow ainsi que la
différence entre Workflow et Collecticiels. En effet, le Workflow est une technologie de la
TCAO qui se distingue de celle des Collecticiels. Cette distinction se fait notamment par
rapport aux objectifs fixés par l'utilisation de chaque technologie. En effet, si le travail
coopératif est bien une préoccupation majeure dans les deux cas, les Collecticiels adoptent
une approche basée sur le groupe, alors que le Workflow est essentiellement basé sur les
processus.

En ce qui concerne le rapport entre BPR, CPI et Workflow, on peut dire simplement que le
Workflow propose des outils méthodologiques ou informatiques, qui permettent d'analyser et
d'évaluer les processus métiers et de leur fournir un support d'exécution automatisé. Mettre en
œuvre une solution Workflow ne signifie pas nécessairement qu'elle est précédée d'un CPI ou
d'un BPR. Cependant, pour reprendre S. NURCAN [NURCAN 95], il est évident que "bien
automatiser un mauvais processus ne peut permettre d’atteindre ses objectifs à long terme".
Par conséquent, on ne peut profiter pleinement des avantages apportés par le Workflow en
l'appliquant sur des processus vacillants.

Afin de comprendre quels sont justement les avantages et les capacités offerts par le
Workflow, ce chapitre propose de faire un tour d'horizon de cette technologie, sous ses
différents aspects :
§ L'aspect lexique et définitions,
§ L'aspect système,
§ L'aspect méthodologique.

16
 Chapitre II : Workflow - Présentation, définitions et Concepts

1.1 Origine du Workflow

Dans le premier chapitre, nous avons mis l'accent sur l'importance des processus pour les
entreprises, notamment des processus métiers. Nous avons également parlé de l'orientation du
management vers la prise en compte de l'individu en tant que membre d'un groupe, partageant
un savoir collectif et intervenant activement dans la réalisation d'un objectif commun. Enfin
nous avons souligné que l'une des évolutions majeures de la Technologie de l'Information
était justement de s'orienter vers le support de la communication, de la coordination et du
partage d'informations entre les participants des processus métiers. Nous avons ensuite
présenté le Workflow comme étant une des technologies de référence pour la satisfaction de
ces besoins.

Ainsi selon plusieurs spécialistes, dont [GEORGAKOPOULOS et al.95], [SCHAEL 97],

l'origine du Workflow se situe aux niveaux des recherches sur l'optimisation et de la
rationalisation des processus de l'entreprise, quelque soit leur nature et leur objectifs. Pour
reprendre P. Berry [BERRY 98], le Workflow ne se limite pas à apporter des améliorations à
un seul type de processus mais à l'ensemble des processus d'une entreprise, qu'elle appelle des
"processus de travail" ("work processes"). Ces objectifs d'optimisation peuvent être atteints
par l’association de deux moyens :

1. Par une amélioration ou une reconception des processus, en appliquant une démarche de
CPI ou de BPR. C'est le niveau "managérial".

2. Grâce à l’automatisation de l’exécution et du suivi des processus métiers et plus

globalement de tous les processus des entreprises. C'est le niveau Workflow. Les avantages
recherchés sont les suivants :

§ Fiabilité, transparence et rapidité des accès aux données et documents (le mot
document étant à prendre au sens large, c’est à dire tout ce qui peut servir de
support d’informations),
§ Résolution des problèmes d’organisation et de synchronisation des participants
aux processus,
§ Suivi et traçabilité des travaux effectués.

D'autres spécialistes restreignent l'origine du Workflow à la Gestion Electronique de

Documents (GED), ayant évolué vers des objectifs d’organisation globale des processus de
l’entreprise [DUPOIRIER 94] et [COURTOIS 96]. Brièvement, la GED consiste en un
ensemble de techniques et d'outils informatiques, permettant d'accéder aux informations et
documents gérés par un organisme, ainsi que de les archiver. Toutefois, la satisfaction des
besoins d'accès et d'archivage de données, formulés par les utilisateurs de la GED n'est pas
suffisante. Les utilisateurs ont vite constaté le besoin de faire circuler entre eux l'information
récupérée et de l'associer à des ensembles de tâches qui la consomment. Or qui dit ensemble
de tâches dit processus. Par conséquent, on constate effectivement que des outils issus de la
GED ont rapidement développé des moyens permettant de représenter, d'exécuter et de gérer
les processus associés à la circulation de l'information entre utilisateurs.

Enfin, un point de vue plus global que le précédent est donné par S. Joosten [JOOSTEN 96].
Pour lui, le Workflow est issu des recherches dans le domaine de l’automatisation et
l'optimisation des processus de "bureau" ("office automation"). Cette catégorie est plus

17
 Chapitre II : Workflow - Présentation, définitions et Concepts

générale que le seul domaine de la GED, puisqu'il regroupe tout ce qui est travail
administratif, gestion de transactions et GED.

En fait, nous aurons l'occasion de voir plus loin dans ce chapitre que les différentes origines
attribuées au Workflow correspondent à la recherche de la réalisation d'objectifs quelque peu
différents, qui ont donné lieu à la création de systèmes spécialisés.

1.2 Définitions
Dans la famille Workflow, je voudrais "le Workflow", "un workflow" et un "système
Workflow", pourrai-t-on dire familièrement. Il est vrai que selon ce dont on parle, le sens du
mot workflow varie légèrement. Pour plus de clarté, nous proposons de donner dans ce qui
suit certaines définitions sur les concepts et les termes du Workflow et d'en expliciter le sens.
Nous les utiliserons par la suite selon la définition que nous leur aurons donnée. Avant de
poursuivre plus avant, il est important de mentionner ici l'existence de la "Workflow
Management Coalition" (WfMC) ([Link] regroupement d'industriels de
l'informatique, de chercheurs et d'utilisateurs. Le but de la WfMC est de définir des standards
pour le développement d'applications Workflows. Ces standards servent notamment à
résoudre les problèmes d'interopérabilité entre systèmes Workflows mais également à définir
les caractéristiques fondamentales de ces systèmes. Les documents publiés par la WfMC, qui
couvrent plusieurs aspects, peuvent être considérés comme des références en la matière. Nous
basons d'ailleurs nos définitions sur ces travaux, en complétant toutefois quand cela est
nécessaire, par des opinions complémentaires issues de la recherche.

1.2.1 Vocabulaire de base

Définition 1 - Workflow

Le Workflow est la technologie informatique du TCAO, qui s'occupe de la gestion des

processus des organisations. On parle également de "Gestion de workflows" ou de "Gestion
de processus" [COURTOIS 96] ("Workflow Management").

Plus globalement, nous pouvons dire que le Workflow est l’ensemble des moyens mis en
œuvre pour automatiser et gérer entièrement les processus d’une organisation. Cette gestion
repose sur la possibilité de représenter d'une façon informatisable, tout ou une partie des
processus en question. A partir des représentations ainsi définies, le Workflow a tout d’abord
pour but de transcrire les modèles obtenus en une forme exécutable. Ces modèles sont ensuite
exécutés et gérés. Il doit de plus être possible de suivre leur évolution au fil du temps. La
gestion de processus inclut également la coordination et la synchronisation des différents
acteurs des processus. Par ailleurs, ces derniers doivent avoir à leur disposition l’ensemble du
contexte informationnel dont ils ont besoin pour mener à bien le travail qui leur est affecté.
Dans un contexte d’acteurs exclusivement humains, la solution Workflow permet ainsi de
décharger le personnel de tâches administratives et de gestion lourdes, en leur laissant la
possibilité de se concentrer sur les problèmes humains et techniques en rapport avec leurs
compétences.

La Gestion de Processus permet donc d’attribuer à chacun et au bon moment, les tâches dont
il a la responsabilité avec les outils et les informations nécessaires pour leur réalisation. Le
terme d’outils est, pour le moment du moins, limité à la désignation de l'outil informatique.
D’autre part, la Gestion de Processus donne la possibilité de tracer et de suivre pas à pas

18
 Chapitre II : Workflow - Présentation, définitions et Concepts

("monitoring") le déroulement des workflows de l’entreprise, en particulier de répondre aux

questions suivantes : qui fait quoi, quand, comment, avec quoi et dans quel but ?

Définition 2 - workflow

Un workflow est un processus d’une organisation, gérable par un outil Workflow. Il est établi
dans le but principal d’automatiser l'exécution du processus mais il peut aussi servir à le
simuler et à l'analyser. On parle également de "flux de travaux" ou de "procédure Workflow"
[WfMC 99].

Définition 3 - Système Workflow

Un Système Workflow est comme son nom l'indique, un système informatique dédié à la
gestion des processus. Les services proposés par un système Workflow sont au minimum
l'exécution d'un processus et sa gestion (contrôle et suivi) ainsi que la mise à disposition des
documents et outils nécessaires à la réalisation des étapes du processus. Selon la définition
donnée par la WfMC, un système Workflow définit, gère et exécute des procédures en
exécutant des programmes dont l’ordre d’exécution est prédéfini dans une représentation
informatique de la logique de ces procédures - les workflows. Un système Workflow est
parfois appelé plus simplement Workflow ( donc un risque de confusion avec la technologie),
"logiciel de gestion des procédures" ou "fluxgiciel" [WfMC 99].

1.2.2 Concepts de base rattachés

Le Workflow s'accompagne de concepts fondamentaux qu'il est nécessaire de présenter. Pour

mieux comprendre quels sont ces concepts et comment ils sont reliés, il est intéressant
d'examiner le métamodèle proposé par la WfMC [WfMC 95]. Nous en donnons ci-dessous
une représentation en UML, la notation unifiée objet :
possède workflow

composé de

Données Utilise/produit Activité Réalisé par Rôle

: Classe (entité)
soummise à Tenu
Fait référence à par
: association
Condition Acteur
de Applications : relation d'agrégation
Fait référence à Transition externes

: relation de composition
utilise
Agrégation : L'agrégation est une association non symétrique, qui exprime un couplage fort et une relation de subordination.
Le cycle de vie de l ’agrégat et de ses objets agrégés sont indépendants, ils peuvent donc exister indépendamment les
uns des autres. L’agrégation représente une relation de type "ensemble / élément".
Composition : La composition est une agrégation forte. Les cycles de vies des éléments (les "composants") et de l'agrégat sont
liés : si l'agrégat est détruit (ou déplacé, ou copié), ses composants le sont aussi et l’éléments composé ne peut exister
sans ses composants.

Figure II.1 - Métamodèle Workflow pour la définition de Processus

Ce métamodèle identifie un ensemble élémentaire d'objets fondamentaux qui entrent dans la

définition d'un processus géré par un système Workflow, et que nous allons définir et
commenter dans les paragraphes suivants. Remarquons que le métamodèle peut être enrichi

19
 Chapitre II : Workflow - Présentation, définitions et Concepts

par les développeurs de tels systèmes, comme il peut également être utilisé à des fins
d'échanges entre différents systèmes Workflows.

Définition 4 - Activité

Pour la WfMC [WfMC 99], une activité est une étape d’un processus lors de laquelle une
action élémentaire est exécutée. Par action élémentaire, on signifie que l'activité n'est plus
décomposable en d'autres activités - donc qu'elle n'est pas un sous-processus. La WfMC
introduit une distinction entre "activité manuelle", qui n'est pas contrôlée par le système
Workflow, et "activité Workflow" qui est sous le contrôle du système. Un exemple d'une
activité manuelle est par exemple l'ouverture du courrier. Une activité Workflow serait par
exemple le remplissage d'un formulaire électronique. On pourrait toutefois se poser la
question de savoir si une activité manuelle ne peut quand même pas être contrôlée par un
système Workflow. Par exemple on peut envisager d'utiliser le système pour fournir aux
acteurs "manuels" une interface leur permettant de signaler la fin d'une activité manuelle. On
peut également tirer profit du Workflow pour rappeler à un acteur quelconque qu'il doit
terminer son activité s'il a dépassé les délais. Il existe donc des cas où une activité manuelle
peut être intégrée dans un workflow. Par conséquent, nous ne distinguerons pas les activités
manuelles des activités Workflow, sauf contre indication de notre part.

Enfin et pour en terminer avec le concept d'activité Workflow, il reste à signaler le fait qu'il
arrive souvent dans la littérature Workflow, que les auteurs emploient le terme de "tâche". Le
sens de ce mot est souvent dépendant du contexte où il est employé et de sa compréhension
par l'auteur. Certains spécialistes appellent "tâche" tout élément d'un workflow qui représente
un travail ou un ensemble de travaux. Ainsi, une tâche peut être une activité (telle que nous
l'avons définie) ou un sous processus, un workflow étant alors composé de tâches. D'autres
personnes utilisent indifféremment "tâche" et "activité" pour désigner le même concept. Si
l'on souhaite approfondir le terme, il est possible de définir la tâche comme étant un travail
affecté à un individu, dont la réalisation est en général au moins soumise à une contrainte
temporelle. La réalisation d'une tâche permet d'atteindre un but local donné. Le travail
permettant de réaliser la tâche est alors appelé "activité". En ce qui nous concerne, nous
utiliserons de préférence le terme "activité" mais nous lui attribuons, dans ce travail, le même
sens que le mot "tâche", sauf quand cela est spécifiquement mentionné.

Remarquons que la définition de l'activité que nous adoptons diffère quelque peu de celle
proposée par la théorie de l'activité, dont les principaux fondateurs, Vygotskij, Leontjev et
Lurija sont des psychologues originaires de l'ex union Soviétique. Cette théorie s'intéresse à
l'analyse de l'activité humaine et définit globalement une activité comme un engagement d'un
sujet vers un objet, qui constitue l'objectif - la motivation ou le domaine du problème - de
l'activité, et qui permet de distinguer les activités entre elles [Kutti, cité dans BANNON 90].
La réalisation d'une activité produit un certain résultat, qui peut être différent de celui
originairement prévu.

Une activité possède une structure hiérarchique dont le premier niveau est constitué par les
actions, qui sont les composants moteurs de l'activité. Chaque action est associée à un but
conscient qui doit être réalisé afin d'atteindre l'objectif global représenté par l'objet de
l'activité. Les actions sont elles-mêmes exécutées par des opérations "automatiques" (réflexes,
mécanismes non conscients) sans but associé, mais qui permettent d'effectuer une action en
fonction d'une certaine situation ou de certaines conditions (également appelées "règles").
Ainsi, la réalisation d'une action est fortement dépendante du contexte dans laquelle elle se

20
 Chapitre II : Workflow - Présentation, définitions et Concepts

déroule, ce qui implique qu'une même action, et par conséquent une même activité, peuvent
être réalisées de façons différentes [CHAT 98], [RYDER 98].

Une activité peut être réalisée sans médiateurs (encore appelés "outils", "instruments" ou
"artefacts") ou peut en nécessiter l'utilisation. Il se peut enfin que la personne réalisant
l'activité en soit elle-même le médiateur. C'est par exemple le cas des activités d'une personne
à son travail, puisqu'elle exécute des activités "imposées" par son employeur (ici le sujet),
pour atteindre un objectif que ce dernier lui a fixé.

Par analogie avec nos définitions, nous pourrions dire que l'activité - telle qu'elle est définie
par la théorie de l'activité - correspond plutôt à un processus Workflow, dont le sujet n'est pas
une personne mais le groupe impliqué dans la réalisation du processus, ou l'initiateur de ce
dernier. Les actions correspondent alors aux activités Workflows puisque chacune d'elle est
liée à un but local, la réalisation de l'ensemble des buts permettant d'atteindre l'objectif global
lié au processus. Enfin, comme nous avons pu le constater sur le modèle, un workflow
nécessite la manipulation d'objets (les données) que l'on peut très bien assimiler à une partie
des instruments permettant de réaliser l'activité.

Définition 5 - Acteur

Un acteur ("actor") est une entité (personne ou matériel) faisant partie d’une organisation et
participant à la réalisation d’un processus. L'acteur est chargé de réaliser les activités qui lui
sont attribuées via le ou les rôles qu'il tient. On parle également "d'agent", de "participant" ou
"d'utilisateur".

Définition 6 - Rôle

Le concept de rôle est extrêmement important en Workflow. Un rôle est un qualificatif

attribué à un ou plusieurs acteurs, décrivant en général ses compétences dans le processus ou
l’organisation. Un rôle est associé à la réalisation d’une ou de plusieurs tâches (activités). Un
même rôle peut être tenu par plusieurs acteurs. La WfMC propose de distinguer deux types de
rôles [WfMC 99] :

§ Les rôles organisationnels, qui définissent un ensemble de compétences et de savoir-

faire qu’un acteur possède et met en pratique. Ce rôle définit la position de l’acteur
dans une organisation.
§ Les rôles procéduraux, qui correspondent à la liste des activités qu’un acteur peut
assumer et exécuter.

En ce qui nous concerne, nous ne faisons pas de distinction entre les deux. En effet étant
donné qu'un rôle correspond à un ensemble de compétences, il est donc lié par définition à un
ensemble d'activités qu'il est capable de réaliser, étant donné ses compétences. Remarquons
enfin que certains spécialistes ne font pas de différence entre acteur et rôle et ne parlent que
d’acteur. Nous ne partageons pas cette opinion qui restreint la clarté et la flexibilité des
modèles Worflows, comme nous aurons l'occasion de le voir par la suite.

Définition 7 - Donnée

Une donnée ("relevant data") est un objet en rapport avec la réalisation d’une activité (en
entrée et/ou en sortie). Elle peut constituer l’objectif de la tâche (manipulation de la donnée),

21
 Chapitre II : Workflow - Présentation, définitions et Concepts

être un élément essentiel pour aider à sa réalisation ou être généré par la tâche. Les données
sont en général des objets informatiques mais il peut également s'agir de références à des
objets physiques.

Définition 8 - Condition de transition

Une condition de transition ("transition condition") est le critère régissant la progression ou le

changement d’état d’une activité (étape de travail) ou le passage à l’activité (étape) suivante
lors d’un cas d’exécution donné, qu’il s’agisse d’une procédure manuelle ou informatisée
[WfMC 99]. Une condition peut s'exprimer sous la forme d'une expression logique ou sous la
forme d'un événement (interne ou externe à l'application Workflow).

Définition 9 - Application externe

Une application externe ("invoked application") est une application informatique dont
l'invocation est nécessaire à la réalisation de la tâche. On pourra parfois parler plus
globalement de ressource, si l'application n'est pas uniquement informatique.

1.2.3 Concepts complémentaires

Les précédentes définitions sont une première étape vers la compréhension du Workflow et
des concepts qui y sont rattachés. Afin d'approfondir un peu cette compréhension, il est
intéressant d'apporter encore quelques autres définitions complémentaires, que nous
présentons ci-dessous.

Définition 10 - Cas d'un workflow

Un cas ("workflow case" ou "workflow instance") est une instance d'un modèle de workflow
("workflow model" ou "workflow schema"). On parle également "d'instance de workflow". Un
cas correspond à la mise en œuvre d'un workflow par rapport à une situation spécifique. Par
exemple on peut avoir le workflow de remboursement des frais d'un enseignant. Un cas de ce
workflow est le remboursement des frais de voyage de M. Dupont, pour la période du 1 au 6
août. L'instanciation d'un workflow donne également lieu à l'instanciation des activités du
workflow. On parle alors d'instances d'activités.

Définition 11 - Règle

La notion de règle ("rule") n'est pas présente partout dans la littérature Workflow mais elle est
néanmoins très intéressante. En fait, cette notion est surtout spécifique aux spécialistes du
Workflow, initialement issus des mondes des bases de données et de l'intelligence artificielle.
Le mot règle peut prendre selon le cas, deux sens assez proches :

§ Il peut s'agit d'un principe de comportement à suivre par un acteur (ou un rôle) vis à vis
d’une activité. La règle peut par exemple déterminer la façon dont l'acteur va réaliser
l'activité. Dans certains cas une règle pourra être confondue avec une condition de
transition.

§ Une règle peut correspondre à un principe de comportement à suivre par un acteur ou par
le système, dans la détermination de choix. Le choix peut concerner le routage d'un
processus (quelle activité choisir parmi un ensemble d'activités) ou la prise en compte de

22
 Chapitre II : Workflow - Présentation, définitions et Concepts

situations non prévues. Nous reviendrons d'ailleurs plus longuement sur ce dernier aspect
dans le prochain chapitre.

Définition 12 - Contrôle de flux

Le contrôle de flux ("control flow") correspond au contrôle de l'ordre de réalisation des

activités: séquentiel, parallèle, disjonction, synchronisation, etc.. Le contrôle est en général
représenté sur un modèle de workflow à l'aide de contrôleurs de flux inspirés des opérateurs
logiques (AND, OR, XOR) associés à des contraintes de synchronisation.

Définition 13 - Bon de travail

Un bon de travail ("work item") est la représentation informatique du travail à effectuer par un
acteur du workflow dans le cadre d’une instance d’activité. Dans la plupart des cas cependant,
on parle plus simplement d'activité, sans faire la distinction.

Définition 14 - Liste des tâches

La liste des tâches ("worklist") ou encore "liste des travaux", "corbeille" ou "liste des bons de
travail", contient la liste des bons de travail attribués à un rôle.

Les définitions que nous avons présentées ci-dessus couvrent l'ensemble des notions
importantes appartenant au Workflow et à son lexique. Toutefois, le lecteur souhaitant
approfondir cet aspect du Workflow trouvera un ensemble de documents très intéressants,
dont un glossaire complet en français, sur le site de la WfMC dont nous rappelons l'adresse
URL : [Link]

1.2.4 Description des Systèmes Workflow

La partie concernant la définition du Workflow ne saurait être complète sans un aperçu du

principe de fonctionnement des systèmes Workflows. Globalement, ce type de système est
composé de trois parties aux intérêts complémentaires [WfMC 95] :

1. La première partie concerne la modélisation des workflows, c'est le "build time". Elle est
essentiellement composée d'un outil permettant la modélisation des workflows, sous une
notation existante ou propriétaire, le plus généralement sous forme graphique. Un
deuxième composant est chargé de transcrire les modèles obtenus en entités
compréhensibles par la partie chargée de l'exécution : le "run time". Selon les systèmes, le
build time peut également être composé d'un "traducteur", permettant d'importer des
modèles réalisés sous des applications externes (systèmes de modélisation et d'analyse par
exemple), et de les traduire au format compris par le système.

2. Le "run time" ou "environnement d'exécution", est chargé de la gestion complète des

modèles de workflow établis dans la première partie. Cette gestion comprend l'exécution
des workflows, la distribution des tâches aux rôles appropriés, la mise à disposition de
l’ensemble des données et des outils nécessaires, la supervision et le contrôle de la
cohérence etc..

Cette partie se décompose en fait en plusieurs autres composants, parmi lesquels il

convient de noter :

23
 Chapitre II : Workflow - Présentation, définitions et Concepts

§ Le "moteur" ("Workflow Engine") qui est véritablement chargé de la Gestion de

Processus.

§ Le gestionnaire des listes de tâches, chargé de répartir les activités en fonction de

leur attribution aux rôles.

§ Les listes de tâches ("Worklists") qui sont les récipients attribués à chaque rôle
dans lesquels le moteur place les tâches à réaliser, par ordre de priorité et en leur
associant les données et les outils appropriés.

§ Les outils d'administration et de contrôle.

3. Enfin, la troisième partie concerne l'ensemble des outils et des fonctions d'API qui
permettent au système Workflow de "s'ouvrir" vers des applications extérieures, en
particulier d'autres systèmes Workflows. Les fonctions d'API permettent également aux
utilisateurs de customiser le système et ses services en fonction de leurs besoins
spécifiques.

Cette architecture globale des systèmes Workflows peut se résumer à l'aide des deux figures
suivantes, tirées d'un des documents de référence de la WfMC [WfMC 95] :

Modélisation Analyse des processus

et définition Outils de Modélisation
Outils de définition
des processus

Build time Définition des

Run time processus API Workflow

Service d’exécution
Outils Autres
d'administration Services
Instanciation Services d’exécution du et de contrôle Moteur
et contrôle système Workflow Workflow

Interaction avec
les utilisateurs Applications et Applications Applications
et les applications outils externes clientes utilisées
externes

Figure II.2 - Caractéristiques des Figure II.3 - Modèle de référence des

systèmes Workflows systèmes Workflows

En fait, l'architecture décrite ci-dessus donne une vision très générale des systèmes
Workflows et de leur fonctionnement. Il existe en effet plusieurs types de systèmes, chacun
étant basé sur des concepts spécifiques, en plus des concepts de base le plus souvent
invariants. Le nombre de critères permettant de classer les systèmes Workflows fait qu'il
existe plusieurs classifications importantes et intéressantes. Ceci justifie d'ailleurs le fait que
nous consacrions ci-après un paragraphe complet à cet aspect du Workflow.

24
 Chapitre II : Workflow - Présentation, définitions et Concepts

2. Classification des Systèmes Workflow

Il est difficile de trouver dans la littérature une classification unique des systèmes Workflow,
faisant l’unanimité. Ce fait provient essentiellement du nombre de critères sur lesquelles il est
possible de les classer. Ces critères varient en fonction des différents points de vue
qu’adoptent les spécialistes par rapport au Workflow et de la perception qu’ils ont sur les
services à rendre ou les caractéristiques présentées par ces systèmes. Ainsi, il est plus réaliste
de parler de plusieurs classifications, plutôt que d'une seule. Ceci n'est pas nécessairement un
inconvénient puisque cela permet entre autres aux personnes chargées de sélectionner un tel
outil, de prendre en compte les différents points de vue sur le sujet. Dans les paragraphes
suivants, nous proposons donc un aperçu des classifications les plus courantes.

2.1 Classification par domaines d'application

Une classification très répandue dans la littérature est proposée par [McCREADY 93] et est
reprise par bon nombre d’auteurs. Elle propose de distinguer trois catégories de Systèmes
Workflow : les Systèmes Workflow Administratifs ("Administrative Workflow Management
Systems"), les Systèmes Workflow de Production ("Production Workflow Management
Systems") et les Systèmes Workflow Ad-hoc ("Ad-hoc Workflow Management Systems ").

2.1.1 Les Systèmes Workflow Administratifs

Comme leur nom l'indique, les systèmes workflow administratifs sont orientés vers la gestion
de processus de type administratif. Il s'agit donc essentiellement d'alléger des tâches de
bureau, où les erreurs sont souvent humaines. Les systèmes workflow administratifs
permettent de lier à une tâche administrative les documents et informations nécessaires à la
réalisation de la tâche par un acteur humain. Ces systèmes prennent également en charge le
routage des documents et le remplissage de formulaires. Selon Martin Ader, l’amélioration
des processus administratifs due au Workflow est de l’ordre de 20% à 50% en terme de
productivité et jusqu’à 90% en terme de délais. Ces systèmes, également appelés « General
Purpose Workflow Management Systems » par [SCHEER et al. 97], gèrent des workflows
répétitifs à forte prédictibilité, à structure simple et sans grande complexité. Le processus et
les règles de passage d’une étape à une autre sont clairement définis, donc facilement
automatisables. En général, ce type de workflows ne requière pas l’accès à plusieurs systèmes
d’informations lors de son exécution et possède une longue durée de vie, c’est à dire qu’il
n’est pas souvent, voire rarement, soumis à des modifications [SCHEER et al. 97].

2.1.2 Les Systèmes Workflow de Production

Les systèmes Workflows de production peuvent être considérés comme étant une variante
évoluée des systèmes administratifs. A leur instar, ils impliquent des processus assez
répétitifs. La principale différence réside dans la complexité de la structure des processus et
des tâches, ainsi que dans l’enjeu que représente leur réussite. En effet, la réalisation du
workflow correspond directement aux objectifs et au travail de l’entreprise. En d’autres
termes, le processus correspond aux services assurés par l’entreprise et sa performance
dépend du succès de l’exécution du workflow. On dit dans ce cas qu’ils sont "mission
critical" [SCHEER et al. 97], [INCONCERT 97]. C’est par exemple le cas des organismes
financiers ou des compagnies d’assurances (qui sont les principaux utilisateurs de ce type de
Systèmes). La réalisation des processus est donc à forte valeur ajoutée par rapport à
l’entreprise et le volume de transactions traitées est important.

25
 Chapitre II : Workflow - Présentation, définitions et Concepts

La complexité des processus traités est également due à la répartition de leurs activités sur
plusieurs sites. Dans ce cas, les tâches exécutées nécessitent souvent l’interrogation de
plusieurs systèmes d’information, hétérogènes et distribués. Il est donc nécessaire que les
systèmes workflow de production fournissent un ensemble d’outils ou de fonctions d'API
permettant de se connecter à plusieurs systèmes. Enfin, même si les processus traités sont
assez répétitifs, ils sont susceptibles d’être modifiés plus souvent que les processus de type
administratif, de par leur orientation métier. Les modifications peuvent par exemple avoir lieu
lors d'une démarche de CPI ou d’une restructuration plus globale, de type BPR. Par
conséquent les systèmes workflow de production doivent pouvoir prendre en compte les
évolutions. Par ailleurs, il arrive que l'exécution d'un processus ne puisse plus se poursuivre
de manière automatisée, suite à l'occurrence d'un ou de plusieurs événements qui remettent en
cause le processus. Dans ce cas, il est parfois nécessaire de faire intervenir des acteurs
humains pour la prise de décision. Pour se faire, le système Workflow de production peut
passer la main à un système plus souple, comme un collecticiel (ou un système Workflow ad
hoc), qui servira de support pour l'exécution "manuelle" de la suite du processus. On parle
dans ce cas de "Workflow composite" [EDER et al. 96].

Les systèmes workflow de production sont également appelés "case-based" car ils gèrent des
"cas" [SCHEER et al. 97]. Un cas est l’instanciation d’un workflow. Par exemple dans une
compagnie d’assurance, on peut avoir le workflow "Gestion des sinistres de type dégâts des
eaux". La gestion d’une plainte formulée par un client X dont l’appartement a été inondé
correspond à ce type de sinistre et est un "cas" du workflow précédent.

2.1.3 Les Systèmes Workflow Ad hoc

Les systèmes workflow ad hoc sont utilisés pour l’exécution de processus non structurés ou
très peu structurés. Un processus peu ou non structuré est un processus dont l’ordre et le
temps exact de réalisation des tâches ne sont pas établis au préalable. A la limite, les tâches
elles-mêmes de ce type de processus ne sont pas connues au départ. Les choix de routage des
tâches, et la nature des tâches sont décidés au fur et à mesure de l’exécution, et il est donc très
difficile d’automatiser de tels processus. Par conséquent, un processus non structuré propose
un objectif immuable, mais pouvant être atteint de différentes façons. Cela justifie donc
l'usage de l'expression "ad hoc" qui désigne un acte spécialement fait pour un objet déterminé.
En effet, la réalisation d'un processus non structuré peu impliquer à chaque fois l'exécution
d'un nouvel enchaînement des tâches, voire de nouvelles tâches.

Dans les processus ad hoc, le système intervient essentiellement pour gérer les échanges entre
rôles (qui font en général uniquement référence à des acteurs humains), gérer l’accès aux
sources d’informations et fournir l’historique du workflow. Comme le font remarquer
[GEORGAKOPULOS et al. 95], l'approche de ces systèmes est souvent de type "pull", c'est à
dire que leurs utilisateurs doivent les interroger pour connaître l’état du processus et en
déduire leurs tâches. Dans les autres types de systèmes, l'approche est plutôt de type "push",
c'est à dire que les utilisateurs sont informés par le système des travaux qu’ils ont à traiter.
Techniquement, la métaphore utilisée dans ce type de système est celle du "dossier"
[WAINER et al. 95]. Les utilisateurs font circuler un dossier virtuel dans lequel sont "placés"
des documents et des données électroniques. Chaque utilisateur en possession du dossier
décide du prochain destinataire. Il peut baser son choix sur un schéma directeur général établi
au préalable ou décider seul (s'il en a le privilège), du prochain destinataire. Les Systèmes
Workflow Ad hoc. En effet, le qui sont surtout utilisés pour des besoins de travail collaboratif,
pour la co-décision [INCONCERT 97], [GEORGALOPOULOS et al. 95] ou dans le

26
 Chapitre II : Workflow - Présentation, définitions et Concepts

traitement d’événements imprévus dont on n’a pas une modélisation [MARSHAK 95], par
exemple comme auxiliaires des systèmes workflow de production.

Aux trois classes de systèmes Workflow présentées ci-dessus, certains spécialistes

([INCONCERT 97] et [ALONSO et al. 97b]) proposent d'en ajouter une quatrième, celle des
Systèmes Workflow Collaboratifs ("Collaborative Workflow Management Systems"), dont
nous donnons une description dans ce qui suit.

2.1.4 Les Systèmes Workflow Collaboratifs

Les systèmes Workflow collaboratifs sont dédiés au support de travail de groupe, tels la
conception, la gestion de projet ou la résolution de problèmes faisant appels à différents
niveaux d’expertise. Les Systèmes Workflow Collaboratifs permettent de réunir un certain
nombre d’intervenants dans le but d’atteindre un objectif commun, les clients du processus y
étant souvent eux-mêmes directement associés. Les tâches des processus gérés sont le plus
souvent complexes et leur réalisation implique l’intervention d’acteurs très compétents (dans
la spécialité qui est la leur). Dans ce cas également, les workflows à traiter sont faiblement
structurés et peu répétitifs. Ils sont par contre à forte valeur ajoutée par rapport à l’entreprise
qui les met en place. Certains spécialistes classent les Systèmes de Workflow ad-hoc et
collaboratifs dans la catégorie des Collecticiels asynchrones [GEORGAKOPOULOS et al.
95].

Il est légitime de se demander quelle est vraiment la différence entre systèmes workflow ad
hoc et collaboratifs et si la distinction est justifiée. En effet, ces deux types de systèmes se
basent sensiblement sur les mêmes concepts et proposent à peu près les mêmes services. On
retrouve principalement la possibilité de gérer des workflows non structurés et de partager des
documents et des informations. Pour certains, la distinction réside dans la complexité des
tâches à réaliser et dans leur valeur ajoutée : peu de complexité et faible valeur ajoutée pour
les premiers, grande complexité et forte valeur ajoutée pour les deuxièmes. Toutefois, ces
critères ne sont pas suffisamment représentatifs pour un grand nombre d’experts qui ne font
pas de distinction entre les deux types de systèmes.

L'analyse des types de systèmes Workflows présentés ci-dessus nous permet de distinguer
certains critères permettant de caractériser chacun des types de systèmes. Par exemple nous
pouvons remarquer que les systèmes Workflows ad hoc et collaboratifs apportent plus de
"souplesse" d'utilisation que les systèmes workflows de production et les systèmes
administratifs. En effet, ces derniers se basant sur une modélisation bien précise du processus,
ils sont beaucoup plus rigides sur la façon de réaliser les activités. A l'opposé, ces derniers
permettent entre autres, une gestion plus efficace du processus et un accès facilité à
l'information nécessaire, justement grâce au fait qu'ils se basent sur une modélisation bien
structurée. D'autres critères sont également visibles, tels la capacité à gérer des processus
complexes, à accéder à plusieurs systèmes d'informations, etc. Nous proposons de lister
l'ensemble de ces critères et de les discuter, dans le paragraphe suivant

2.1.5 Critères de répartition

Des descriptions données dans les paragraphes ci-dessus, nous pouvons donc extraire un
certain nombre de critères de classification, que nous nommons critères de répartition. Nous
les avons qualifiés ainsi car ils nous permettent de répartir les systèmes Workflows dans des
espaces à deux dimensions (deux critères) complémentaires, en fonction de leurs spécificités.

27
 Chapitre II : Workflow - Présentation, définitions et Concepts

Les figures suivantes décrivent la répartition des systèmes Workflows en fonction des critères
que nous avons relevés, dont nous donnons ensuite la liste.

Complexité
Valeur Des tâches
ajoutée Production
Production
Collaboratif Collaboratif

Administratif Ad hoc Administratif

Ad hoc
Volume des transactions Structuration

Figure II.4.a - Répartition par valeur Figure II.4.b - Répartition par complexité des
ajoutée et volume des transactions Processus et structure du workflow

Durée Souplesse
de vie Administratif d’utilisation
Collaboratif
Production
Ad hoc
Collaboratif
Production
Ad hoc
Administratif

Automatisation Puissance

Figure II.4.c - Répartition par degré

d’automatisation et durée de vie du Figure II.4.d - Réparation par souplesse
workflow d'utilisation et puissance du système

§ Degré de structuration du workflow. Les processus gérés sont-ils clairement définis,

les tâches sont-elles identifiées et leur ordre d'exécution peut-il être établi ?

§ Degré d’automatisation. C'est une conséquence directe du premier critère. Plus les
processus sont prédictibles, plus ils sont identifiés et plus il est simple d'en donner une
représentation informatique qui servira à l'automatisation de l'exécution. Le degré
d'automatisation correspond au pourcentage de travail qui pourra être géré par le
système Workflow.

§ Durée de vie du workflow (répétitivité des processus). Ce critère indique si un

workflow est soumis à des modifications fréquentes.

§ Complexité du processus. La complexité du processus réunit plusieurs facteurs, telle la

distribution des tâches sur plusieurs sites, la nécessité d'avoir accès à des systèmes
d'information hétérogènes et répartis.

§ Valeur ajoutée du processus. Ce critère définit l'apport du Workflow à l'organisme qui

le met en place en terme de profitabilité par rapport aux services proposés par
l'organisme.

28
 Chapitre II : Workflow - Présentation, définitions et Concepts

§ Volume des transactions effectuées. Ce critère réunit le volume des accès à des
systèmes d'informations pour la récupération de données, le volume des tâches et des
interactions effectuées.

§ Souplesse d'utilisation. La souplesse d'utilisation consiste en la capacité du système à

"enfreindre" l'ordre établi (changement de routages des activités, modifications du
processus, etc.), à absorber les situations imprévues et à proposer (ou permettre) des
alternatives. Il est évident que les systèmes gérants des processus peu structurés offrent
le plus de possibilités à ce niveau, puisqu'il est possible à tout moment, de redéfinir la
façon dont sont réalisées les activités.

§ Puissance. Le critère de puissance de traitement est plutôt flou et assez subjectif.

Qu'entend-on exactement par puissance ? S'agit-il du volume des transactions traitées,
de la vitesse d'accès aux informations, du nombre d'utilisateurs pris en compte ? En
fait, la signification du terme puissance employé ici englobe l'ensemble de ces aspects :
il s'agit des capacités et des fonctionnalités proposées par le système. Il nous semble
intéressant de comparer les aspects souplesse et puissance. En effet, comme nous
pouvons le voir sur la figure II.4.d, les systèmes Workflows de production, qui sont
considérés comme les plus "puissants" ne sont pas nécessairement les plus maniables.
Cela nous permet de nous interroger sur l'intérêt de la maniabilité - de la flexibilité -
d'un système en tant que facteur intervenant dans sa "puissance". En d'autres termes, un
système puissant ne devrait-il pas également être flexible ? Nous reviendrons plus en
détail sur cet aspect dans la suite de cet ouvrage.

2.1.6 Intérêts et inconvénients de la classification par domaines d'application

L'intérêt principal de la classification présentée dans les paragraphes précédents est de

présenter les domaines d'applications dans lesquels peuvent être utilisés les systèmes
Workflows. Un domaine d'application est un contexte métier pour lequel on souhaite utiliser
le système Workflow. Ce dernier doit donc présenter les fonctionnalités nécessaires à la prise
en charge des problèmes issus du contexte du métier. Par exemple, un système Workflow
administratif propose nécessairement des fonctionnalités d'archivage et de routage des
documents, ainsi que de description du processus administratif traité. Le choix d'un type de
système par domaine d'application est donc facilité par l'adéquation des critères présentés
avec les besoins du métier des utilisateurs.

En contrepartie, cette classification est critiquée par plusieurs spécialistes, notamment

[KOULOPOULOS 98]. En effet selon eux, la classification ci-dessus ne se base pas sur des
critères de classifications homogènes. Ainsi, les systèmes dits "administratifs" et "de
production" reflètent la fonctionnalité du système par rapport au contexte métier dans lequel il
intervient. A l'opposé les systèmes "ad hoc" et "collaboratifs" reflètent des choix
d'organisation et de management : une organisation des acteurs en groupe et une mise en
œuvre de processus non structurés, sans laisser transparaître le métier sous-jacent.

A ces remarques, nous pouvons également ajouter la relative fragilité des frontières définies
par les termes servant à classer les systèmes. Cette constatation s'applique notamment sur les
systèmes administratifs et ceux de production. Ainsi, un système workflow administratif ne
peut-il pas être de production si la raison d'être de l'organisme qui le met en œuvre est de
gérer des processus administratifs ? En d'autres termes, si le critère retenu est celui de la
valeur ajoutée, alors un système workflow administratif apporte une forte valeur ajoutée à un

29
 Chapitre II : Workflow - Présentation, définitions et Concepts

organisme administratif, puisqu'il lui permet d'augmenter sa performance globale, donc sa

"production".

2.2 Classification par objectifs

Dans la littérature Workflow on retrouve souvent une deuxième classification qui se base sur
les types de problèmes pour lesquels les systèmes Workflow apportent des solutions et les
objectifs qu'ils permettent d'atteindre [THULLIER et al. 98] [KOULOPOULOS 98]. On peut
se demander qu'elle est la différence entre "classification par types de problèmes à résoudre
(ou objectifs)" et "classification par domaines d'application". En fait, les partisans de la
première distinguent, comme nous allons le voir, trois classes de problèmes typiques
auxquelles correspondent trois classes de systèmes Workflows. Ces classes recouvrent celles
plus spécifiques des domaines d'application. La classification présentée ci-dessous distingue
donc trois catégories de systèmes Workflow : ceux dits "orientés processus" ("Process
Workflows"), les systèmes Workflows "orientés Documents" ("Document Workflows") et les
systèmes Workflows "de Communication" ("Communication Workflows").

2.2.1 Les systèmes Workflow orientés Processus

Pour T. Koulopoulos, les systèmes orientés processus ont été les premiers à être présents sur
le marché (ce qui n'est pas l'avis de tous, nous l'avons vu) et sont les plus répandus
actuellement. Un système Workflow est dit orienté processus s'il utilise sur une modélisation -
précise - des processus qu'il gère et exécute. Les systèmes Workflows orientés processus sont
donc dédiés à l'automatisation de l'exécution et la gestion des processus métiers des
entreprises, ce qui leur vaut le qualificatif de "mission critical". En effet, ces systèmes sont
fondamentalement impliqués dans la réussite de processus critiques des organisations où, pour
reprendre T. Koulopoulos, le processus définit le business ("the business is the process"). La
gestion efficace des processus métiers est donc un élément clé de la réussite de ces
organisations.

Techniquement, les systèmes orientés processus basent l'automatisation des processus métiers
sur une modélisation fine de ceux-ci. Ces modèles sont généralement réalisés grâce à un outil
propre au système et à l'aide de formalismes propriétaires ou plus répandus (Réseaux de Petri,
SADT, etc..). En plus des processus (décrit en termes d'activités interconnectées), les modèles
permettent d'associer les rôles responsables de la réalisation des activités, d'identifier les
acteurs disponibles ainsi que d'attribuer des ressources (documents, formulaires, etc..) aux
activités. Mentionnons enfin que ce type de systèmes fait partie des outils utilisés lors de la
mise en œuvre des méthodes de CPI et de BPR, certains d'entre eux proposant également des
fonctions de simulation et d'analyse des processus modélisés.

2.2.2 Les systèmes Workflow orientés Documents

Les systèmes Workflow orientés Documents sont directement issus de la Gestion

Electronique de Document (GED) dont ils se démarquent par des fonctionnalités
supplémentaires d’assemblage, de création et de routage des documents. Pour reprendre la
définition de [PELLETIER 98] la GED est "l’ensemble de techniques qui permettent
d’accéder rapidement et le plus économiquement possible aux masses d’informations et de
documents générés ou reçus par un organisme…". Du point de vue de certains experts de la
GED tels [DUPOIRIER 94], il n’y a pas de Systèmes Workflow orientés Documents mais des

30
 Chapitre II : Workflow - Présentation, définitions et Concepts

applications de GED intégrant des capacités Workflow, notamment pour la gestion du routage
et de la distribution des documents. Ce fait s'explique par l'évolution des applications de GED
vers l'intégration de fonctionnalités de routage, en réponse aux besoins des clients.
Conséquence logique de cette évolution, on observe aujourd'hui l'intégration de moteurs
Workflow au sein d'applications plus vastes, telles les Systèmes de GED et de Gestion de
Données Techniques (SGDT) [STARK 98] et [KOULOPOULOS 98] ou les outils d'ERP
(Engineering Ressources Planning) [ZUR MULLEN et al. 00]. Nous reviendrons d'ailleurs
plus longuement sur ces aspects d'intégration dans un paragraphe dédié à l'évolution des
systèmes Workflows.

2.2.3 Les systèmes Workflow de Communication

Certains éditeurs de logiciels [INCONCERT 97] et auteurs tels [FRYER 94] et [COURTOIS
96] interprètent le sens du terme "Communication" par la présence d'outils de messagerie
sophistiqués fournit par le système workflow ("mail centric workflow systems"). Cette
interprétation n'est pas la bonne. En fait, les systèmes Workflow de Communication se basent
sur la théorie du "Discours/Action" reprise par Winograd et Flores [WINOGRAD 87] pour
établir une méthodologie de modélisation de workflows. Cette théorie quand elle est
appliquée au domaine du Workflow et sur laquelle nous reviendrons ultérieurement,
représente les étapes d'un processus non pas en termes d'activités mais en termes de
transactions entre un client et un fournisseur, donnant lieu à des interactions dont l'objectif est
le succès de la transaction. A chaque étape du processus on identifie un client et un
fournisseur, qui peut prendre à son tour le rôle de client par rapport à un autre intervenant.
L'objectif principal étant la réussite de la transaction, le système offre les moyens de trouver
le meilleur chemin pour que la transaction ait lieu de manière satisfaisante pour le client. En
1998, [KOULOPOULOS 98] constatait que ce type de système, le plus récent, avait connu
une progression de 40 % pour l'année 1997 et pronostiquait une progression annuelle de
l'ordre de 30 à 50 %, ce qui ne s'est pas tout à fait vérifié.

2.2.4 Critères de classification

La typologie décrite ci-dessus ne présente que trois critères de classification, assez bien
définis puisqu'ils correspondent aux fonctionnalités des systèmes Workflow. Il s'agit
respectivement de :

§ La capacité à modéliser, exécuter et gérer des processus,

§ La capacité à référencer, archiver, manipuler et regrouper de l'information au travers de
différents types de documents,
§ La capacité à prendre en main des transactions client – fournisseur (plus ou moins
structurées).

Orienté
Processus

Orienté Orienté
Documents Communication

Figure II.5– Classification par Objectifs des Systèmes Workflow

31
 Chapitre II : Workflow - Présentation, définitions et Concepts

Bien que ces trois critères soient distincts, il est par contre facile de remarquer qu'ils se
retrouvent souvent ensemble (à des degrés certes différents) dans les trois types de systèmes.
En effet, un système orienté processus aura nécessairement besoin d'accéder aux documents,
de les lier aux activités des processus puis de les gérer. Réciproquement, un système orienté
documents a également besoin d'une modélisation (même grossière) du processus
correspondant au routage des documents. Il en est de même pour les systèmes dits de
coordination. Par conséquent ce7s trois classes de systèmes se recouvrent partiellement,
comme on peut le constater dans la représentation de la figure II.5.

2.2.5 Avantages et inconvénients de la classification par Objectifs

L'avantage de la classification par objectifs est que chaque classe correspond à une
technologie et que chaque technologie est dédiée à un type de problème bien spécifique. La
compréhension en est ainsi facilitée. Grossièrement, on pourrait dire : si l'on a des processus à
gérer, alors on a besoin de systèmes Workflow orientés processus, si l'on est plus intéressé par
la gestion de documents il faut utiliser des systèmes orientés documents, etc.. Les
détracteurs de cette classification quant à eux, lui reprochent justement le fait de ne pas
dissocier le type de Workflow du fonctionnement du système et de la technologie qu'il utilise,
ce qui ne permet pas d'établir un rapprochement avec le métier de l'entreprise. De plus, la
frontière entre les trois classes est mal définie étant donné que les fonctionnalités se
combinent la plupart du temps. Notons enfin que les trois catégories ne tiennent pas
explicitement compte du fait qu'il est possible d'avoir des workflows peu structurés (en fait,
cette possibilité est principalement présente dans les systèmes de communication). Cette
classification reste néanmoins séduisante de par sa clarté.

2.3 Autres classifications

Bien que les deux classifications précédentes soient représentatives de la majorité des avis sur
le sujet, il est toujours possible de classer les systèmes Workflow selon d'autres critères. Nous
donnons ci dessous des descriptions rapides et non exhaustives de classifications proposées
par certains auteurs.

2.3.1 Workflow orienté Activités Humaines versus Workflow orienté Activités

Automatiques

Il est possible de classer les systèmes Workflow uniquement selon le degré d'automatisation
qu'ils proposent : "Human Oriented" versus "System Oriented". Cette classification est
proposée par [GEORGAKOPOULOS et al. 95].

Les systèmes Workflow orientés activités humaines supportent le travail de personnes

impliquées dans un travail coopératif. Les fonctionnalités requises dans ce type de système
sont :

§ Le support et la coordination des activités de groupe,

§ Le support des interactions Homme – Machine,
§ L'adéquation des compétences des personnes aux exigences des tâches (choix des
acteurs).

Toutefois, la responsabilité de la cohérence du processus et des informations est

essentiellement humaine.

32
 Chapitre II : Workflow - Présentation, définitions et Concepts

A l'opposé, les systèmes orientés vers le support des activités automatiques impliquent en
grande majorité des interactions entre machines ou entre applications informatiques, souvent
sur des systèmes d'information hétérogènes ou répartis. Par conséquent, il est nécessaire de
fournir des mécanismes de contrôle puissants (puisque le contrôle et la coordination sont
assurés par le système Workflow), de gestion de la cohérence des données manipulées, ainsi
que des mécanismes de récupération inspirés des systèmes de gestion de bases de données
(propriétés ACID : Atomicité, Cohérence, Intégrité, Durabilité, sur lesquelles nous
reviendrons dans le prochain chapitre). A l'intersection des deux types de systèmes
précédents, [GEORGAKOPOULOS et al. 95] situent les systèmes Workflow transactionnels
qui impliquent des processus mixtes, donc composés de tâches automatiques ou humaines. Ils
combinent par conséquent les fonctionnalités des deux types de systèmes. Par analogie avec
les classes de systèmes définis dans la première classification, on peut placer les systèmes ad
hoc et collaboratifs dans la catégorie des systèmes orientés activités humaines, les systèmes
de production dans la catégorie des workflows transactionnels et les systèmes administratifs et
militaires (dont nous n'avons pas parlé) dans la partie orientée activités automatiques (fig.
II.6).
Collecticiel Workflow Transactionnel

Workflow Workflow Workflow Systèmes

ad hoc de Production administratif militaires

Orienté Humain Orienté système

Figure II.6 – Classification en fonction du degré d'automatisation

2.3.2 Workflows structurés versus Workflows non structurés

Une autre classification possible des systèmes Workflow est réalisée en fonction du degré de
structuration des workflows, c'est à dire de la possibilité de définir au préalable un modèle du
processus [MARSHAK 95]. On parle également de workflows "formels" ou "informels"
[GUIMARAES et al. 95]. En fait, dans ces deux catégories on retrouve respectivement les
systèmes Workflow ad hoc dans la première et dans la deuxième, les systèmes Workflow
administratifs ou de production.

2.3.3 Messagerie et Base de Données

Cette classification qu'on retrouve entre autres dans [EDER et al. 96] et [GUIMARAES et al.
95], se base sur la technologie utilisée par le système pour fonctionner. Les systèmes
workflow basés sur la messagerie utilisent, comme leur nom l'indique, des mécanismes de
messageries électroniques pour faire circuler des documents et la description des activités
entre participants. En fait, beaucoup de systèmes workflows, parmi lesquels les systèmes dits
ad- hoc et une partie de ceux dits orientés processus et orientés documents, utilisent la
messagerie électronique ou des techniques analogues.

Les systèmes workflows basés sur les bases de données quant à eux, utilisent les mécanismes
offerts par les SGBD pour assurer trois fonctionnalités :

1. Gérer le stockage et les accès aux données utiles lors de l'exécution du workflow,
2. Gérer les droits d'accès aux informations du workflow,

33
 Chapitre II : Workflow - Présentation, définitions et Concepts

3. Contrôler le flux des activités à l'aide des déclencheurs ("Triggers") utilisés dans les
SGBD [EDER et al. 96]. Nous reviendrons d'ailleurs plus longuement sur cet aspect dans
la partie consacrée à la modélisation de workflows.

2.3.4 Workflow Statique versus Workflow Dynamique

La dernière classification que nous souhaitons présenter, distingue les workflows statiques des
workflows dynamiques. Par workflow statique on comprend tous les workflows basés sur une
modélisation figée des processus. Cette modélisation, si elle est remise en cause en cours
d'exécution, nécessite l'arrêt du système pour introduire des corrections ou de nouvelles
entités. C'est le cas du plus grand nombre des systèmes orientés processus et orientés
documents. Le workflow dynamique quant à lui, englobe deux situations. La première
concerne tous les systèmes workflows peu structurés, donc qui gèrent des activités de groupes
plutôt que des processus, comme nous l'avons vu précédemment. La deuxième situation
concerne les systèmes workflows et les workflows qui donnent la possibilité de s'adapter et de
faire évoluer les modèles sous jacents en cours d'exécution des processus. C'est un aspect
extrêmement intéressant du workflow, sur lequel nous reviendrons beaucoup plus longuement
dans le chapitre consacré aux workflows "avancés".

3. Modélisation Workflow

La modélisation est un élément de base de la technologie Workflow, en particulier dans le cas

des systèmes basés sur une modélisation des processus ou sur l'enchaînement des activités.
Côté formalismes et méthodes de modélisation, on constate aujourd'hui que la plupart des
systèmes commerciaux proposent leurs propres formalismes et leurs propres méthodes.
Malgré tout on constate également que ces formalismes propriétaires se basent souvent sur
des formalismes et des méthodes connus. Cette constatation provient du fait que la
modélisation de workflows se base sur des concepts théoriques invariants, sur lesquels
peuvent s'appliquer avec plus ou moins de succès des formalismes et des méthodes de
modélisation existants. Le premier de ces invariants correspond à ce qui est à modéliser en
termes de Workflow. Nous discutons ce premier aspect dans le paragraphe suivant. Ensuite,
nous présenterons certaines méthodes et certains formalismes de modélisation utilisés, en
discutant de leurs intérêts et leurs inconvénients

3.1 Fondements de la modélisation Workflow

Dans leur étude sur l'intégration et l'utilisation du Workflow dans les entreprises et les
administrations, [JOOSTEN et al. 96] avaient constaté l'absence de méthodologies spécifiques
à ce domaine. Les entreprises qu'ils avaient étudiées avaient développé leurs propres
méthodes, mettant l'accent sur tel ou tel aspect leur paraissant intéressant. Il a toutefois été
possible d'extraire de cette étude des fondements pour la modélisation de workflows, en se
basant sur les critères retenus par les entreprises et ceux définis par les spécialistes
théoriciens. Ces fondements ou depuis été repris en partie par les développeurs de systèmes
Workflows ou augmentés par d'autres chercheurs. Cette partie de notre travail tente
d'identifier les principales bases de la modélisation Workflow, en synthétisant les différentes
opinions établies à ce sujet. En premier lieu, nous nous intéressons aux différents aspects qui
doivent ou qui peuvent être modélisés lors de la mise en œuvre du Workflow. Ces aspects
sont présentés dans le paragraphe qui suit.

34
 Chapitre II : Workflow - Présentation, définitions et Concepts

3.1.1 Quoi modéliser ?

L'exécution d'un workflow doit permettre, nous l'avons dit, de répondre aux questions
suivantes : quelles sont les activités à réaliser (quoi) ? Quelles sont les compétences
nécessaires (qui) ? Quand faut-il les réaliser (quand) ? Quels sont les outils et les informations
nécessaires (comment)? On peut donc identifier plusieurs aspects différents à prendre en
compte lors de la modélisation de workflows [JOOSTEN et al. 96], [BARTHELMESS et al.
95], [JABLONSKI et al. 93] :

1. L'aspect fonctionnel
2. L'aspect Comportemental
3. L'aspect Informationnel
4. L'aspect Organisationnel

1. L'aspect fonctionnel : L'aspect fonctionnel concerne l'identification des activités des

processus que l'on souhaite modéliser. Il est important de comprendre qu'il ne s'agit pas
uniquement d'identifier les fonctions des différents départements d'une organisation mais
bien de distinguer les activités composant un processus. La modélisation fonctionnelle
doit également permettre d'établir la hiérarchie des activités, c'est à dire d'exprimer de
possibles décompositions en termes de sous-processus. Enfin, le modèle fonctionnel doit
éventuellement représenter le flux de données associées aux activités ("data flow").

2. L'aspect Comportemental : L'aspect comportemental est un aspect primordial du

Workflow puisqu'il correspond à la dynamique du processus. Le comportement s'exprime
par la modélisation d'un contrôle de flux entre les activités. Ce dernier permet d'indiquer
la chronologie de l'exécution des activités, leur flux (séquentiel ou parallèle), les points
de synchronisation entre activités ou au contraire, les points de disjonction. De plus, le
modèle comportemental doit représenter les évènements qui permettent de déclencher les
activités. Notons pour souligner l'importance de ce modèle, qui permettra l'exécution du
workflow que le modèle fonctionnel seul est insuffisant. En fait, on remarque souvent que
les deux modèles sont représentés en un seul. L'aspect comportemental est également
appelé aspect de coordination.

3. L'aspect Informationnel : Cet aspect concerne l'ensemble des informations et des données
qui sont associées aux activités. Le modèle informationnel, souvent négligé lors de
l'implémentation d'un Workflow [JOOSTEN et al. 96], décrit en détail les relations qui
existent entre les données, leur type et leur structure. Ce modèle peut être assimilé par
exemple au Modèle Conceptuel de Données de la méthode MERISE [TARDIEU et al.
85] ou à un modèle de classes d'une méthode Objet. Le modèle informationnel peut
également représenter le flux des informations, c'est à dire leur circulation et les
différents états qu'elles peuvent prendre.

4. L'aspect Organisationnel : Comme son nom l'indique, la partie organisationnelle

concerne la description de l'organisation des acteurs de l'entreprise. Le modèle
organisationnel peut refléter fidèlement l'organigramme de l'entreprise, c'est à dire la
décomposition hiérarchique de celle-ci en départements et services ou bien décrire des
unités organisationnelles dans lesquelles on identifie des acteurs. Selon la méthode
choisie, la description est plus ou moins détaillée et permet d'établir des liens
hiérarchiques entre les acteurs ainsi que des relations entre unités organisationnelles ou
départements. Toutefois, quelle que soit la méthode retenue, un élément reste invariant,

35
 Chapitre II : Workflow - Présentation, définitions et Concepts

c'est la description des rôles associés aux différentes activités. Les rôles créent l'interface
entre le modèle organisationnel et les modèles représentant les activités.

Il est possible de faire deux commentaires sur ces quatre aspects. Tout d'abord, ceux qui
s'intéressent aux Méthodes de Modélisation d'Entreprises (MME), peuvent remarquer la
similitude entre les vues de l'entreprises identifiées par les MME et les quatre aspects cités ci-
dessus. Globalement, une MME a pour but de proposer une méthode pour la modélisation
d'une entreprise. La méthode se base sur des formalismes existants si ceux-ci s'adaptent aux
exigences de la méthode ou en propose d'autres si ce n'est pas le cas. La modélisation se fait
dans plusieurs buts, notamment dans un but d'analyse, de compréhension de simulation et
d'amélioration du fonctionnement de l'entreprise (BPR ou CPI) [SCHEER 98] [VERNADAT
96]. Dans un but d'expressivité, de clarté et de simplification, les MME telles ARIS
[SCHEER 98] et CIMOSA [VERNADAT 96] par exemple, proposent de distinguer plusieurs
vues spécifiques d'une entreprise, très similaires aux quatre aspects de modélisation que nous
venons de citer. Toutefois, et c'est notre deuxième commentaire, le but du Workflow même
étroitement lié à la structure de l'entreprise, n'est pas d'en proposer une modélisation globale.
Par conséquent ces quatre aspects, bien que fondamentaux, ne se retrouvent pas toujours
simultanément dans les modèles Workflows ou s'y retrouvent sous des formes allégées. Tout
dépend de l'importance du Workflow dans l'entreprise qui le met en place, est-il utilisé
uniquement pour la gestion des processus ou également dans des buts de reconfiguration ? En
fait, même si le modèle comportemental et le modèle organisationnel (ou une partie de ce
modèle) sont suffisants, il est intéressant d'avoir une représentation des quatre aspects dans
un but d'intégration du Workflow dans un contexte plus global, qui est celui de l'entreprise et
des ses autres systèmes d'information.

D'autre part, il est important de mentionner le fait que la plupart des MME (telles ARIS et
CIMOSA), distinguent au moins trois niveaux d'élaboration des modèles : la partie analyse et
spécification, la partie conception et la partie implémentation. Or le Workflow, nous l'avons
mentionné, a des objectifs d'implémentation et d'exécution. Par suite, un modèle Workflow
n'est pas un modèle d'analyse car dans cette phase, la granularité de la modélisation n'est pas
suffisamment fine et les modèles ne peuvent être exécutables. En fait, les points de vues
divergent sur ce sujet. En effet, pour [GEORGALOPOULOS et al. 95] par exemple, le
Workflow peut aussi bien être utilisé à des fins d'analyse pour le BPR ou le CPI, que dans un
but d'implémentation pour l'exécution automatique des processus. Par conséquent, tout
modèle permettant de décrire un organisme dans les termes que nous avons cités
précédemment, peut être qualifié de modèle Workflow. Dans le même esprit, [EDER et al.
96] distinguent plusieurs utilisations des modèles Workflows (en plus de l'exécution
automatisée) :

§ Spécification et analyse des modèles de processus,

§ Documentation des processus,
§ Intégration entre données et entre systèmes d'information hétérogènes.

Nous partageons cet avis et pensons ainsi qu'il peut y avoir plusieurs niveaux de modélisation
Workflows, ayant une granularité de détail de plus en plus fines. A l'opposé, [SCHEER et al.
97] estiment que seule une modélisation fine des processus, pouvant donner lieu à une
implémentation et exécution automatique, correspond à un modèle Workflow. Les modèles
servant à l'analyse et la compréhension en restent à l'état de modèles de processus.

36
 Chapitre II : Workflow - Présentation, définitions et Concepts

3.1.2 Types de modélisation

En marge des différents éléments à modéliser dans un workflow, il est possible de distinguer
quatre types de modélisation, basés sur des paradigmes différents :

1. La modélisation à base d'activités ("activity based modeling") [GEORGAKOPOULOS et

al. 95], [BERRY 98],
2. La modélisation basée sur la communication ("communication based modeling")
[GEORGAKOPOULOS et al. 95], [BERRY 98], [NURCAN 96], [SCHAEL 97],
3. La modélisation à base d'artefacts ("artifact based modeling") [BERRY 98],
4. La modélisation à base de règles ("Rule based modeling") [EDER et al. 96], [CASATI 96]

1. La modélisation à base d'activités se concentre sur la modélisation du travail en termes

d'activités. C'est le type de modélisation le plus répandu actuellement et c'est celui qui est
à la base des outils de modélisation des systèmes Workflows orientés processus. La
modélisation à base d'activités consiste principalement à décrire des processus en termes
d'activités et de sous-processus en définissant les conditions d'exécution des activités (les
événements déclencheurs) et le contrôle de flux (opérateurs de synchronisation, de
disjonction) (fig. II.7). Selon la richesse des formalismes utilisés, les modèles à base
d'activités correspondent aux modèles fonctionnels, aux modèles comportementaux ou
aux deux à la fois. Ils peuvent également inclure une partie du modèle organisationnel ou
du moins y faire référence grâce aux rôles associés aux activités. Les modèles obtenus
sont en général enrichis grâce aux outils des systèmes Workflow (principalement le
remplissage de formulaires de propriétés).
Doc.1

Activité 2 [OK]
[OK]
Activité 1 AND
Activité 3
// Activité 3
[OK]
Doc.1
[NOT OK]
Activité 4
Doc.2

Figure II.7 – Modélisation à base d'activités

2. La modélisation basée sur la communication encore appelée modélisation

conversationnelle par [EDER 98], est fondée sur théorie du discours/action dont nous
avons parlé précédemment. Ce type de modélisation est basé sur le paradigme de la
communication entre un client et un fournisseur. Le modèle décrit des transactions entre
ces deux types d'acteurs ([Link].8). Les différentes transactions sont liées entre elles afin
de décrire l'ensemble du processus. Ce type de modélisation est utilisé par les systèmes
orientés communication.

Client But de la transaction Fournisseur

Figure II.8 – Modélisation basée sur la communication

37
 Chapitre II : Workflow - Présentation, définitions et Concepts

3. La modélisation à base d'artefacts se concentre sur les artefacts (documents, formulaires,

tables de base de données ou objets informatiques métiers – tel par exemple une
"facture", une "plainte", un "contrat", etc.. Ce type de modélisation décrit le déroulement
d'un processus en termes d'états atteints par les différents objets manipulés tout au long
du processus. En fait, on pourrait dire qu'il s'agit du dual des modèles à base d'activités.
Comme nous l'avons vu, ces derniers mettent l'accent sur les activités, en leur associant
des artefacts (documents ou autres). Le routage se fait selon l'occurrence d'événements.
Dans la modélisation à base d'artefacts, le routage est tracé en fonction de l'états des
artefacts (fig. II.9). L'état d'un artefact est lié à une activité qui permet de faire passer
l'artefact à un autre état souhaité. Le processus est donc basé sur le résultat des activités
accomplies sur les artefacts.

Doc. 1
Doc. 1 Remplir Archiver
À remplir Doc. 1 - rempli Doc. 1
- A archiver

Fig. II.9 – Modélisation à base d'artefacts

4. La Modélisation à base de règles propose de décrire un processus grâce à des règles.

Chaque règle est composée d'événements de conditions et d'une ou plusieurs actions.
L'occurrence des événements permet d'activer la règle. Les conditions si elles sont
vérifiées, permettent à la règle d'exécuter les actions qui lui sont associées ("Event
Condition Action rules – ECA rules"). Ce type de modélisation est directement issu du
monde des base de données où on les appelle également des déclencheurs ("Triggers").
En général, le formalisme utilisé est principalement textuel, par exemple un langage de
définition de règles (fig. II.10).

WHEN event1 OCCURS

IF condition1 = TRUE AND condition2 = TRUE
ACTION activity1 AND activity2

[Link].10 – Modélisation à base de règles

Si ces types de modélisation sont distincts, on remarque souvent dans la pratique que les
modèles Workflows en combinent deux ou plusieurs, pour plus d'efficacité et de clarté. Cette
combinaison intervient souvent à des niveaux différents. Par exemple certains systèmes (tels
TriGSflow) utilisent des formalismes graphiques à base d'activités pour la spécification des
workflows, complétés ensuite par des ECA lors de l'implémentation. Le choix dépend de
l'expressivité et de la puissance des formalismes retenus mais aussi bien entendu, de leur
adéquation aux besoins des utilisateurs.

3.2 Formalismes et méthodes de modélisation

La modélisation de processus, d'informations ou d'organisations n'est pas une innovation du
Workflow. Plusieurs méthodes ont été développées dans les années 80 et 70 (voir avant) dans
des domaines variés tels la gestion de production, les base de données ou le développement de
logiciels. Certaines de ces méthodes ont été reprises telles quelles ou réadaptées aux besoins

38
 Chapitre II : Workflow - Présentation, définitions et Concepts

du Workflow. D'autres méthodes ont également été créées spécifiquement pour ce domaine,
enfin d'autres encore se sont contentées de "réinventer la roue". Souvent ou retrouvera
plusieurs méthodes combinées, afin de couvrir l'ensemble des aspects qu'il convient de
modéliser : les fonctions, le comportement, les informations et l'organisation. La principale
contrainte à respecter est de conserver la cohérence et l'intégration des modèles entre eux,
dans un soucis d'efficacité. Dans ce qui suit, nous présentons rapidement les principales
méthodes qui ont été reprises ou réadaptées par les développeurs de systèmes Workflow. Plus
de détails pourront être trouvées dans les documents cités en référence dans les différents
paragraphes.

3.2.1 Les réseaux de Petri

Un grand nombre de méthodes de modélisation et systèmes Workflows utilisent des modèlent

inspirés des graphes orientés. En général, les places (ou n œuds) correspondent aux activités
des processus modélisés alors que les arcs sont associés à des conditions de transitions ou des
flux d'informations. Parmi les dérivés des graphes, on retrouve souvent les réseaux de Petri.
Les réseaux de Petri (RdP) sont largement utilisés dans les modèles qui traitent de problèmes
de coordination et de synchronisation et ce dans diverses disciplines comme l'Informatique et
l'Automatique. Leur succès tient à plusieurs facteurs : la simplicité de leurs formalismes, leur
base mathématique, la possibilité de représenter la dynamique d'un système et les contrôle de
flux (parallélismes, boucles, synchronisations) ainsi que la possibilité de faire des simulations,
atout très important dans le domaine de l'ingénierie des systèmes et des processus.

[Link] Description

Les RdP s'expriment sous la forme de graphes orientés, composés de places, d'arcs et de
transitions (fig. II.11) [BRAMS 83]. Un réseau débute par une ou plusieurs places d'entrée et
se termine par une ou plusieurs places de sortie. Entre les places sont positionnées les
transitions. Les arcs relient les places aux transitions en entrée et les transitions aux places en
sortie. Les arcs peuvent être munis de poids. La dynamique du système modélisé est
représentée par la circulation d'un ou de plusieurs jetons entre les places. Le nombre de jetons
étant défini par le poids de l'arc liant la transition à la place en sortie. Le passage de jetons
d'une place à l'autre est soumis à la (aux) condition(s) ou l'événement (aux événements)
représenté(s) par la transition. Dès que la condition est vérifiée, la transition est mise à feu et
les jetons peuvent circuler.

Selon les besoins du modèle et le domaine d'application, une place peut correspondre à une
activité dans un processus, à l'état d'un système ou à un événement, à une file d'attente, etc..
Les transitions quant à elles correspondent le plus souvent à des événements ou des conditions
à vérifier. Elles peuvent cependant représenter des activités, en particulier si les places jouent
le rôle d'événements.

Jeton

Place
Transition

Figure II.11 – Réseaux de Petri

39
 Chapitre II : Workflow - Présentation, définitions et Concepts

[Link] Avantages des Réseaux de Petri

Le formalisme et la méthode des RdP sont très répandus dans les systèmes Workflow orientés
processus, sous leur forme initiale ou sous une forme modifiée. De plus, beaucoup de
méthodes destinées à la modélisation Workflow se basent sur ces formalismes. Ce succès est
du, nous l'avons dit, à la simplicité des formalismes des RdP et à leurs caractéristiques qui les
rendent particulièrement adaptés et puissants pour la représentation de la dynamique d'un
système, en particulier d'un processus. D'autre part, la possibilité d'effectuer des simulations et
de les visualiser (grâce à la circulation des jetons) permet de détecter les causes de
ralentissement et les boucles. Ceci facilite grandement le travail d'amélioration du processus
modélisé et est un avantage indéniable.

[Link] Inconvénients des Réseaux de Petri

Malgré leurs avantages indéniables et l'attachement que leur portent beaucoup de spécialistes,
les RdP n'en demeurent pas moins sans inconvénients pour la modélisation Workflow. Le
premier inconvénient provient de leur simplicité qui ne permet pas de prendre en compte tous
les aspects plus compliqués qui sont utiles, voir nécessaires à la modélisation d'un workflow.
Parmi ces aspects, nous distinguons en particulier :

§ Le temps ou la durée, qui permettent d'évaluer des temps d'exécution ou d'initialiser

des événements à certains moments. Pour ce faire, d'autres versions des RdP sont
nécessaires, telle les RdP "temporisés" qui permettent d'inclure cette notion de temps
au sein des RdP.

§ Les jetons d'un RdP ne correspondent à rien de vraiment précis. Ils peuvent servir à
indiquer où en est l'état du processus. Ils peuvent également correspondre à des objets
véhiculés d'une place à l'autre mais il n'est pas possible de distinguer plusieurs types
d'objets à l'aide d'un seul type de jeton. Une autre évolution des RdP, dite RdP colorés,
permet d'introduire des jetons de couleurs différentes au sein des places, ce qui permet
d'établir des correspondances entre jetons et objets manipulés dans le processus mais
introduit également quelques difficultés au niveau des transitions, notamment pour
fixer le routage des différents jetons. Quoiqu'il en soit, les RdP colorés restent
insuffisants pour représenter l'ensemble des objets requis par les activités d'un
processus ainsi que pour décrire les relations qui existent entre eux.

§ Les rôles responsables de la réalisation des activités ne peuvent être représentés sur un
RdP alors que la notion de rôle est fondamentale pour le Workflow. Bien évidemment,
il est toujours possible grâce à l'éditeur d'un système Workflow d'ajouter les rôles en
tant qu'attributs des places par exemple mais ces attributs ne pourront figurer sur le
modèle. Pour améliorer la clarté du RdP, il est alors nécessaire de créer des modèles de
transition entre le modèle organisationnel et celui du processus.

§ L'intégration du modèle comportemental (défini à l'aide d'un RdP) avec les autres
modèles n'est pas facilitée par l'absence d'entités pouvant jouer le rôle d'interface. Par
exemple, l'intégration avec le modèle organisationnel n'est pas simple puisque les rôles,
entités pouvant servir d'interface, ne figurent pas sur le RdP. Le problème se pose
également entre le modèle informationnel et le modèle comportemental, puisqu'on ne
peut représenter les informations requises au niveau des activités. Ce problème est
partiellement résolu à l'aide des RdP colorés.

40
 Chapitre II : Workflow - Présentation, définitions et Concepts

§ Le dernier aspect concerne le manque de niveaux de décomposition des RdP. Afin de

réduire la complexité de la représentation et d'éviter la surcharge du modèle, il est
intéressant de pouvoir réduire ou augmenter la granularité de la représentation en
fonction du point de vue qu'on souhaite adopter – global ou détaillé. Pour résoudre ce
problème [VAN DER AALST et al. 99] proposent une modélisation basée sur le
principe de la décomposition de réseaux ("nets in nets"). Un RdP peut être contenu
dans une place faisant partie d'un RdP plus général. La modélisation utilise des places
de types différents qui correspondent à des vues globales de RdP spécifiques.

§ Enfin, malgré la dynamique qu'ils expriment, les réseaux de Petri sont impossible à
reconfigurer dynamiquement, par exemple lors d'une modification du processus
correspondant.

[Link] Exemple de modélisation d'un workflow à l'aide de RDP

Dans ce paragraphe, nous considérons un exemple très simple et élémentaire de workflow. Il

s'agit de la commande d'un article passée par un client, à une entreprise donnée. Les workflow
se compose de quatre activités :

§ La vérification de la disponibilité de la commande auprès du stock.

§ Si l'article n'est pas disponible, l'activité suivante consiste uniquement à envoyer une
lettre d'excuse au du client.
§ Si l'article est disponible, il s'agit alors d'envoyer une facture au client et l'ordre de
préparation du colis.
§ Si la facture est payée dans les temps, l'ordre est envoyé aux convoyeurs pour la
livraison du colis.
§ Dans le cas contraire, il faut annuler la commande.
Envoyer lettre
d’excuse

Vérification
de la disponibilité
 OK Fin du workflow
Article non
disponible Commande indisponible
Envoyer colis
Envoyer facture
Arrivée d’une OK facture
commande payée
Article
disponible facture Fin du workflow
Facture payée Commande aboutie
envoyée
Facture
Préparer colis impayée
Article
disponible Annuler la commande

Colis prêt
Facture
impayée Fin du workflow
Commande annulée

Figure II.12 – Modélisation d'un workflow par RdP

Dans la figure II.12, on considère qu'une place représente l'état du workflow à un moment
donné, que les transitions correspondent à des activités et qu'il est possible de leur ajouter des
conditions d'activation. On peut constater sur cette figure que les rôles ne sont effectivement
pas représentés, donc qu'il n'est pas possible de repérer la répartition des activités sur les
différentes responsabilités. De plus, on constate bien qu'on ne sait pas quels sont les objets

41
 Chapitre II : Workflow - Présentation, définitions et Concepts

manipulés par chacune des activités et qu'on ne connaît pas non plus l'évolution de leur état.
Cet exemple très simple et démonstratif sera repris pour chacune des méthodes décrites dans
les pages suivantes.

En conclusion sur l'adéquation des RdP à la modélisation Workflow, il est possible de dire
que ceux-ci restent des formalismes de modélisation de bas niveau, plus adaptés à la
description des mécanismes internes et locaux des entités Workflow qu'à la représentation
claire des workflows des organisations.

3.2.2 La méthode SADT/IDEF0

La méthode SADT ("Structured Analysis and Design Technique") trouve ses racines dans le
début des années 70. Son but est de permettre la modélisation et l'analyse d'activités en les
décomposant hiérarchiquement, à l'aide d'une méthode et de formalismes standards, afin de
faciliter la communication les différentes équipes de l'entreprise [IDEF0 93]. Etant donné que
cette décomposition est possible, alors on peut généraliser en l'appliquant aux processus de
production des entreprises (eux-mêmes décomposables en activités). La méthode IDEF0
quant à elle, est basée sur la plupart des concepts et formalismes de SADT, sauf les
"datagrammes" qu'elle ne reprend pas. Elle introduit en revanche quelques ajouts au niveau
méthodologique. Nous confondons donc la description des formalismes de ces deux
méthodes.

[Link] Description

Côté formalismes, SADT ne présente pas de difficulté particulière. On distingue deux types
de diagrammes duaux : les "actigrammes" et les "datagrammes", utilisant trois formalismes
principaux (accompagnés d'autres formalismes auxiliaires) : les diagrammes parents, les
boîtes et les flèches.
Données de
Globalement, un actigramme est représenté par une Contrôle
boîte, identifiée par un verbe d'action. Il sollicite une *
Activité
entrée (une donnée) qui est transformée, modifiée ou Ou
changée d'état pour générer une ou plusieurs sorties. Entrée Sous-processus Sortie
Ce processus s'effectue suivant certains mécanismes Index
et sous des directives de contrôle. Les données de
Ressource Appel
contrôle ne sont pas modifiées par l'activité, par
opposition aux données d'entrée. Elles peuvent
déclencher, inhiber ou jouer le rôle de paramètre sur Figure II.13 – Actigramme SADT
l'activité. Les mécanismes représentent les moyens
de réaliser l'activité, le comment. Les flèches d'entrée, de sortie et de contrôle sont identifiées
dans les datagrammes par des noms.
Activité de
Contrôle
Similairement, un diagramme de données crée, à
partir d'activités d'entrées (les activités génératrices), Donnée
une donnée utilisée par l'activité de sortie. Le Activité Activité
processus s'effectue sous l'influence d'activités de génératrice Index génératrice
contrôle et en utilisant des mécanismes de support de
la donnée. Les activités génératrices, utilisatrices et Ressource Appel
de contrôle sont identifiées par des verbes et la
donnée par un nom.. Figure II.14 - Datagramme SADT

42
 Chapitre II : Workflow - Présentation, définitions et Concepts

Les mécanismes sont ceux servant à mémoriser la donnée. Les formalismes utilisés pour
décrire les deux types de diagrammes sont les mêmes mais leur contenu est "inversé" - les
données deviennent des activités et vice-versa. Le sens du terme "donnée" est à prendre au
sens large, il peut s'agir de données informatiques, de documents ou d'objets physiques.

Dans le cas des actigrammes, un diagramme parent correspond à un processus ou un sous

processus. Il est constitué de trois zones ([Link].15) : l'une contient un index permettant
d'indiquer le niveau de décomposition du processus au sein d'un autre processus, ainsi que son
ordre chronologique. Une deuxième zone contient le nom du processus lui-même. Enfin, dans
la zone la plus importante, sont représentés les processus et activités qui composent le
processus en question. Ces éléments sont décrits à l'aide d'actigrammes interconnectées par
des flèches. Comme nous l'avons vu, ces derniers sont utilisés pour la représentation de
plusieurs éléments, respectivement ([Link].13) :

§ Les contraintes et conditions imposées sur une boîte. Ces contraintes peuvent prendre
plusieurs formes, de l'expression logique à l'occurrence d'un événement. Par exemple,
un document en sortie d'une activité peut être utilisé en tant que contrainte d'une autre
activité. Elle exprime dans ce cas que l'activité doit atteindre la disponibilité du
document pour pouvoir s'exécuter.
§ Les ressources requises pour l'exécution de la tâche (machines, personnel, objets, …),
§ Les appels émis par la tâche vers d'autres boîtes,
§ Les entrées et sorties – principalement les objets consommés et produits par la boîte.

Les flèches peuvent être annotées pour plus de clarté et leur position par rapport aux boîtes
varie en fonction du type d'élément représenté. Ainsi, les contraintes et conditions sont
représentées par des flèches descendantes, situées au dessus de l'activité. Les ressources sont
représentées par des flèches remontantes situées en dessous de la boîte, tandis que les
entrées/sorties sont exprimées par des flèches horizontales, respectivement placées à l'entrée
et à la sortie d'une boîte. Il est également possible d'exprimer des mises en parallèle ou des
boucles, sans toutefois de formalismes particuliers.

Sous-
Processus 1

2
3

P.1/1 Processus P1
Figure II.15 – Diagramme parent SADT/IDEF0

[Link] Avantages de SADT

SADT présente peu d'avantages pour la modélisation Workflow, bien que ce soit une
modélisation à base d'activités. L'intérêt principal de la méthode est la possibilité de
représenter des activités avec en plus, une approche descendante dans le niveau de granularité
ce qui permet d'obtenir plusieurs vues de la même activité. Plus globalement, les autres

43
 Chapitre II : Workflow - Présentation, définitions et Concepts

intérêts qu'il est possible de citer sont la simplicité de la méthode et la possibilité de

représenter des objets manipulés par les activités, ainsi que les rôles qui leurs sont associées.
De plus, les contrôles permettent de poser des contraintes de plusieurs types sur la réalisation
des activités (temps, expression logique, etc..). Cependant, cette technique de modélisation
commence un peu à dater et elle est supplantée par d'autres méthodes de sa famille, plus
performantes.

[Link] Inconvénients de SADT

Par rapport à la modélisation Workflow, SADT souffre de certaines lacunes qui limitent son
intérêt. Nous en donnons ci dessous la liste des plus importantes :

§ Les formalismes utilisés par SADT sont clairs mais trop pauvres. Si le formalisme qui
permet de représenter les activités (et par extension, des processus) est intéressant (les
diagrammes parents et les boîtes), on constate en contrepartie qu'on utilise les mêmes
formalismes pour les datagrammes et le reste des éléments du modèle (boîte, flèche et
description textuelle). Par conséquent, la clarté du modèle et sa lisibilité s'en ressentent
quand le nombre d'entités augmente. Les lacunes suivantes en sont d'ailleurs toutes des
conséquences.

§ La représentation des ressources et des contraintes est redondante, donc source d'erreurs.
De plus, chaque fois qu'une ressource ou qu'une contrainte est requise par une activité ou
un processus (une boîte), elle est représentée par une flèche annotée qui est un symbole
"anonyme", c'est à dire qu'il se perd parmi les autres flèches.

§ Il n'y a pas dans SADT de formalisme qui permette de représenter clairement les
contrôles de flux. Aussi, malgré la possibilité d'introduire des activités en parallèles ou
des points de rencontre, aucun symbole de SADT ne permet de le faire explicitement.

§ De même que pour les RdP, l'intégration d'un modèle fonctionnel SADT avec les autres
modèles (organisationnels et informationnels) n'est pas simple.

[Link] Exemple de modélisation d'un workflow à l'aide de SADT

Commande Article non Lettre
client disponible d’excuse
Vérification de Envoyer lettre
la disponibilité d’excuse
1 2.1
Agent Facture
Marketing payée
Agent
Facture
Marketing Colis
Article Envoyer facture Livrer colis
Disponible
+ 2.2 24.1
Commande
Agent Magasinier
Comptable
Colis Facture
Préparer colis Non payée
xxx
Annuler la
23
: Objet en entrée Commande
ou en sortie 24.2
Magasinier
Agent Marketing
Agent Comptable

Figure II.16 – Modélisation d'un workflow avec SADT

44
 Chapitre II : Workflow - Présentation, définitions et Concepts

Comme nous pouvons le constater, SADT permet de représenter les rôles impliqués dans la
réalisation des activités, contrairement aux RdP. Il est même possible d'indiquer quels sont les
objets produits ou manipulés à chaque étape (quel que soit leur type – physique ou
informatique) ce qui apporte un "plus" au niveau de la compréhension du processus. Par
contre, ces avantages sont infirmés par le manque de clarté du modèle, dont la cause
principale est due à la pauvreté des formalismes, comme nous l'avons déjà souligné. En effet,
il est par exemple difficile de distinguer les événements enclenchant les activités des objets
qu'elles consomment ou produisent. De même, comme il est possible de représenter un
événement ou un objet en tant qu'entrée d'une activité ou en tant que contrainte, cela introduit
des problèmes de confusion et de redondance de l'information. Tous ces facteurs aboutissent à
des modèles trop chargés à la lisibilité réduite.

En conclusion, on pourra dire que la méthode SADT est trop rigide et qu'elle n'est pas assez
complète pour être appliquée dans le domaine du Workflow, en particulier pour la production
de modèles exécutables. SADT reste néanmoins intéressante pour la modélisation rapide de
processus, destinés à la compréhension et au début d'une phase d'analyse pour la
reconception. Par ailleurs, il est étonnant qu'une méthode aussi structurée et précise au niveau
de la description des processus le soit très peu au niveau de la description des ressources,
informations et contraintes. Enfin, par rapport aux systèmes Workflow du marché, le seul
élément repris à SADT est la représentation des processus à des niveaux de granularité
différents. Toutefois, cette caractéristique n'est pas uniquement spécifique à SADT car elle se
retrouve dans plusieurs autres méthodes.

3.2.3 La méthode IDEF3

IDEF3 est spécifiquement dédiée à la modélisation de processus et de workflows [MAYER et

al. 95]. IDEF3 reprend une grande partie des formalismes d'IDEF0 et propose d'autres
concepts intéressants. Remarquons qu'IDEF3 a été introduite comme méthode
complémentaire à IDEF0 et non en tant que remplaçante, quoique à notre avis, IDEF3 suffise
à englober IDEF0. Les principales nouveautés résident dans l'introduction de formalismes
supplémentaires au modèle fonctionnel, ainsi que l'introduction d'un nouveau modèle, le
modèle des objets.

[Link] Description d'IDEF3

Dans IDEF3, on distingue trois composants essentiels :

1. Les vues sur les processus, dont les modèles sont appelés "schémas de processus"
2. Les vues sur les objets manipulés dans un processus, appelés "schémas des objets".
3. Un langage d'élaboration qui permet de décrire d'une façon logique et textuelle, les
schémas de processus. Nous ne parlerons cependant pas de ce langage dans ce travail.

1. Les schémas de processus : les schémas des processus d'IDEF3 ressemblent beaucoup
aux actigrammes de IDEF0. Ils en reprennent d'ailleurs un des éléments les plus
importants : les boîtes (actigrammes), qui correspondent à des processus ou des activités,
avec la possibilité de décomposition des vues sur les boîtes. Dans IDEF3, une boîte est
appelée "unité de comportement" (UDC) ("unit of behavior" - UOB). Cette dénomination
est intéressante puisqu'elle permet de réunir sous le même qualificatif, une activité ou un
ensemble d'activités. Les UDC sont reliées par des liens, exprimés par des flèches dont la

45
 Chapitre II : Workflow - Présentation, définitions et Concepts

représentation graphique varie en fonction de la contrainte sur le lien. Le lien le plus

simple est représenté par une flèche simple, partant d'une UDC à une autre (fig. II.17.a).
Elle n'exprime aucune contrainte sur ce lien. D'autres types de flèches permettent
d'exprimer des "contraintes de précédence" entre UDC : l'activité A doit être suivie de
l'activité B (fig. II.17.b) ou réciproquement, l'activité B doit être précédée de l'activité A
(fig. II.17.c). La contrainte la plus forte indique que A est nécessairement suivie de B qui
est nécessairement précédée de A (fig. II.17.d).

A B A B

Figure II.17.a – Lien simple Figure II.17.b - Contrainte de précédence

Sans contrainte A suivi de B
A B A B

Figure II.17.c – Contrainte de Figure II.17.d – Contrainte de

précédence B précédé de A précédence A et B toujours ensembles

IDEF3 abandonne par contre tous les autres types de flèches indiquant les contraintes sur
les activités ou les ressources allouées, ce qui a le mérite d'augmenter la lisibilité du
modèle. Par ailleurs, IDEF3 introduit de nouveaux symboles très intéressants de contrôle
de flux, appelés "jonctions" ("junctions"). Il s'agit des opérateurs logiques classiques :
AND noté "&", OR noté "O" et XOR noté "X", auxquels il est possible d'ajouter des
contraintes de synchronisation. Un opérateur de jonction est représenté à l'aide d'une case
dans laquelle figure l'opérateur. Si ce dernier est asynchrone, la case est marquée d'une
barre à gauche. Si elle est synchrone elle est barrée de part et d'autre (fig. II.18). Les
opérateurs de jonction peuvent être utilisés en entrée d'UDC ou en sortie. Ainsi, dans la
figure II.18, la première jonction "&" indique que les activités B et C sont exécutées en
parallèle une fois que l'activité A se termine. Toutefois, le fait que la jonction soit
asynchrone permet à l'une ou l'autre des activités de commencer sans attendre l'activité
parallèle. Le symbole "O" suivant l'activité C est synchrone. Il indique que E ou F est
exécutée après C. Les deux peuvent également s'exécuter simultanément. La contrainte de
synchronisation implique que si plusieurs occurrences de l'une de ces activités sont créées,
alors elles doivent s'exécuter simultanément. Le "O" synchrone en sortie indique que E et
F doivent être terminées avant de lancer l'activité G. L'utilisation d'un "O" non synchrone
aurait assoupli la contrainte et aurait permis à G de s'exécuter après la fin de l'une ou
l'autre des activités. Enfin, la jonction synchrone "&" précédant l'activité F contraint cette
dernière à ne s'exécuter que si D et G sont terminées.

B D

A & & H
E
C O O G
F

Figure II.18 – Exemple de schéma de processus IDEF3

46
 Chapitre II : Workflow - Présentation, définitions et Concepts

2. Les schémas d'objets : ces schémas constituent eux aussi une amélioration intéressante
d'IDEF3 par rapport à IDEF0. Ils appartiennent à la catégorie des modèles basés sur les
artefacts (§ 3.1.2) pour laquelle nous n'avions jusqu'à présent pas donné d'exemple.
Globalement, un schéma d'objet sert à représenter les différents états que peuvent prendre
les objets utilisés par les UDC lors de l'exécution. Par conséquent, les schémas d'objets
reflètent en général des scénarios et non tous les cas possibles. Il peut donc y avoir
plusieurs schémas d'objets pour un même schéma de processus. Cela n'empêche pas, bien
entendu, de pouvoir afficher tous les cas possibles sur le même schéma d'objets. Un état
est représenté par un cercle dans lequel on affiche le nom de l'objet suivi de l'état qu'il
prend. Les schémas d'objets se spécialisent en deux autres types de schémas : les
"schémas de transition" et les "schémas étendus de transitions ". Les schémas de
transitions (fig. II.19.a) permettent d'associer les UDC des schémas de processus aux
états des objets. Comme une UDC intervient dans le passage d'un objet d'un état à un
autre, on l'appelle une "transition". Les transitions utilisent un formalisme légèrement
différent de celui des UDC. Les états sont reliés aux transitions par des liens décrits par
des flèches. Il est de plus possible d'attribuer un poids à un lien de transition. On
distingue donc les liens de transition normale, sans poids, des liens de transition forte,
décrit par une double flèche. Un objet pouvant prendre plusieurs états suite à la
réalisation d'une UDC, les schémas d'objets font également l'usage des opérateurs
logiques, sans toutefois avoir la possibilité de préciser la synchronisation. Enfin, il est
possible d'associer des conditions aux objets, lors de leur entrée ou de leur sortie d'un état
ou lors du passage d'une transition. Ces conditions sont notées sur des formulaires
indépendants du schéma d'objets.

T1 T2
: objet
1 2 O2:
OK x : transition
O1: O2: i
vide plein X
: opérateur
O2:
refus

Figure II.19.a – Exemple de Schéma de Transition IDEF3

Les schémas étendus de transition sont des représentations plus complètes des schémas
de transition (fig. II.19.b). En effet, en plus de l'état des objets et des transitions, ces
schémas représentent les liens qui existent entre les objets concernés par les transitions, et
entre ces objets et ceux du monde extérieur. Il est donc possible de décrire l'ensemble des
relations qui existent entre les objets créés et manipulés par les UDC ou de lier les objets
à ceux qui sont chargés de les manipuler. Il est possible d'exprimer n'importe quel type de
relation à l'aide d'un lien entre des objets, des relations d'utilisation, de composition et
même de spécialisation.
T1 T2
1 2 O2:
OK
O1: O2:
vide plein X
O2:
Traité refus
Doit
O4 composé contenir par
de
R1 : Lien entre
composé O3 les objets
O5 de

Figure II.19.b – Exemple de Schéma étendu de Transition

47
 Chapitre II : Workflow - Présentation, définitions et Concepts

Dans la figure 1.19b, nous avons ajouté des informations supplémentaires sur les objets qui
sont manipulés par les transitions. En premier lieu, nous avons exprimé sous forme de lien, la
contrainte que l'objet O1 devait contenir l'objet O3. Ce dernier est lui-même composé de deux
autres objets O4 et O5. Enfin, la liaison entre O2 et l'objet R1 (ressource) exprime que l'objet
O2 est traité par la ressource R1. Nous avons donc utilisé les liens entre objets pour exprimer
différentes relations (contrainte, composition, utilisation), qui enrichissent le diagramme de
départ (II.19.a).

[Link] Avantages de IDEF3

La méthode IDEF3 présente des caractéristiques qui la rendent très intéressante pour la
modélisation Workflow. Il est important de mentionner que nous n'avons parlé ci-dessus que
des concepts et des formalismes les plus importants d'IDEF3. Il en existe d'autres tout aussi
intéressants que nous ne n'évoquerons pas ici, mais qu'il est possible de découvrir dans
[MAYER et al. 95].

Le premier avantage de la méthode est la disponibilité de deux (trois) modèles

complémentaires et bien intégrés - les schémas de processus et ceux de transition, ce qui
facilite la compréhension du processus et permet d'étendre le nombre d'entités représentées.
D'autre part, les jonctions apportées par les schémas de transition de IDEF3 permettent de
représenter clairement toutes les possibilités de contrôle de flux, sans confusion possible sur
leur signification (comme c'était le cas pour IDEF0). L'intérêt est double : le modèle est plus
lisible mais surtout, aspect très important, le modèle est plus facilement exécutable puisque
les jonctions peuvent être traduites en éléments de programme. D'autres avantages sont
directement hérités de la méthode IDEF0, notamment la possibilité de décomposition des
UDCs. Par ailleurs, les schémas de transition offrent la possibilité très intéressante de
représenter les objets impliqués dans les processus ainsi que l'état qu'ils doivent prendre après
chaque transition. Cette option est particulièrement utile dans le cas du contrôle de
l'exécution, puisqu'il est possible de vérifier l'adéquation de l'état des instances du schéma
avec celui qu'ils doivent théoriquement avoir. Il est même possible, grâce aux schémas de
transition étendus, de représenter les liens qui existent entre les objets des processus, ainsi que
les ressources pouvant les manipuler. On recouvre ainsi une grande partie des aspects à
modéliser dans un workflow. Enfin il reste à mentionner qu'IDEF3 s'intègre dans une famille
de méthodes (notamment IDEF4, qui propose une méthode et des formalismes objets)
permettant de compléter les modèles réalisés à l'aide d'IDEF3.

[Link] Inconvénients de IDEF3

IDEF3 nous l'avons dit, est dans l'ensemble bien adaptée à la modélisation de workflows.
Toutefois, bien qu'elle présente plusieurs aspects très attrayants, elle n'en reste pas moins
exempte de quelques défauts non négligeables. Le premier de ces inconvénients est celui de
l'absence de la notion d'événement dans une représentation IDEF3, que ce soit au niveau d'un
schéma de processus ou d'un schéma d'objet. Les seuls événements qu'il est possible de
prendre en compte sont les "fins d'activités" (qui sont implicites et non représentés) pour les
schémas de processus, ainsi que les états d'objet pour les schémas de transition. La transition
d'un objet d'un état à un autre peut être confondue avec l'occurrence d'un événement qui
permet de décider du routage à suivre dans la suite. Par contre, il ne semble pas possible de
représenter des événements non prévus par la méthode. Par exemple, il n'est pas possible de
représenter explicitement des événements externes ou des événements correspondant à l'état
des activités et non à celui des objets, pourtant essentiels pour la gestion du workflow. Ce

48
 Chapitre II : Workflow - Présentation, définitions et Concepts

manque dans la modélisation IDEF3 est assez handicapant pour la modélisation de workflows
qui est en grande partie, basée sur l'occurrence d'événements.

Un autre inconvénient à nos yeux est l'absence de la notion fondamentale de rôle, qui
n'apparaît pas clairement dans les schémas IDEF3. Bien sûr, il est possible de lier un objet
manipulé par les transitions à un objet "personne" dans les schémas étendus de transition mais
sans que cet objet "personne" ne corresponde nécessairement à un rôle référencé dans un autre
modèle. En fait, la possibilité offerte dans les schémas étendus de transition de lier des objets
à d'autres objets constitue un intérêt certain mais risque d'être en même temps une source de
confusion. En effet nous avons vu qu'IDEF3 représente tous les objets par un seul formalisme,
le cercle. Ces objets peuvent donc être de n'importe quel type et correspondre à "n'importe
quoi : " un objet du processus, une personne, un lieu ou même un concept. Il n'existe pas de
formalismes spécifiques pour différencier les objets entre eux, ni les objets externes au
processus de ceux qui lui sont internes. Il n'existe pas non plus de moyens de classer ces
objets en des types différents. Par conséquent, même si un schéma étendu de transition est
plus riche en information que les schémas de transition "classiques", celle-ci n'est pas
suffisamment typée ni structurée pour pouvoir être exploitée correctement, notamment pour
une exécution automatique. Par exemple, dans la figure I.19b, on indique bien que l'objet O2
est traité par R1 mais nous n'avons aucune information sur ce dernier objet - pas de type (est-
ce une ressource, une personne, etc.) ni d'attributs qui permettent de le caractériser ou de le
repérer.

[Link] Exemple de modélisation d'un workflow avec IDEF3

Envoyer letrre
d’excuse
2
Vérification
de la disponibilité X Envoyer Annuler
Facture la commande
1
3 5
& & X
Préparer Livrer
Colis le colis
4 6

Figure II.20.a – Modélisation d'un workflow avec IDEF3 : schéma de processus

Envoyer
Lettre
d’excuse
2 Magasinier Livreur
Vérification Commande Commande Envoyer
indisponible
avortée Le
de la
commande colis
Livré par
Envoyer Préparé par 6
1
Facture Colis Colis
commande X préparé & livré
3
Commande
validée &
Traitée par Référence
à activité
Préparer externe Facture
Agent colis payée
x
marketing
4 Facture
envoyée X
Facture Annuler
non commande
Agent Envoyée par payée
marketing
5
Commande
& annulée

Figure II.20.b – Modélisation d'un workflow avec IDEF3 : schéma étendu de transition

49
 Chapitre II : Workflow - Présentation, définitions et Concepts

L'exemple ci-dessus nous permet de constater deux faits : premièrement, nous pouvons
observer qu'il est nécessaire d'avoir les deux types de schémas pour obtenir une modélisation
exploitable des processus modélisés. Chacun des schémas pris séparément n'est pas
suffisamment explicite pour bien comprendre le processus et encore moins l'exécuter
automatiquement. Deuxièmement, nous pouvons constater dans le schéma de transition, que
le déroulement du workflow est orchestré par les changements d'états des objets qui y sont
manipulés et non par des événements. Bien sûr, si les événements qui régulent le workflow
sont exprimés par les changements d'états des objets, il n'y a pas de problème. Par contre si ce
n'est pas le cas, alors la notation ne permet pas de l'exprimer.

En conclusion sur IDEF3, nous pouvons dire que c'est une méthode aboutie et réfléchie,
présentant d'indéniables intérêts pour la modélisation de workflows. IDEF3 est certainement
plus performante que les méthodes présentées jusqu'à présent. Les schémas obtenus sont
globalement implémentables, bien que plus dédiés à l'analyse qu'à l'exécution automatique de
workflows. Il existe d'ailleurs des outils commerciaux de modélisation et d'analyse de
processus basés sur IDEF3 (téléchargeables sur le site [Link] mais à notre
connaissance, il n'existe pas de systèmes Workflows commerciaux basés sur cette méthode.

3.2.4 Trigger Modelling for Workflow Analysis

Le "Trigger Modelling for Workflow" (TMW) ou modélisation à base de déclencheurs, se

base comme son nom le laisse comprendre, sur une modélisation événementielle des
workflows. Les concepteurs de la méthode [JOOSTEN 94][ANAXAGORAS 94] proposent
un métamodèle (représenté en UML par la figure II.21) inspiré de celui proposé par la
WfMC1, où toute activité d'un workflow ou tout processus, est enclenché par l'occurrence d'un
ou de plusieurs événements. Le TMW est initialement prévu pour l'analyse du comportement
des workflows dans un but d'amélioration mais est également utilisable à des fins
d'implémentation.

Objet Processus

Lié à < : sens de la relation

Evénement Activité : association

déclenche < est responsable de
: agrégation/ appartenance
Acteur
< réalise
: composition

Figure II.21 – Métamodèle du Trigger Modelling for Workflow Analysis

[Link] Description de la méthode

D'après le métamodèle de la figure II.21, on peut comprendre par l'association entre les entités
"Activité" et "Evénement", que l'occurrence des événements est un élément déclencheur
d'activité. La relation d'agrégation / appartenance est par contre moins claire : comment un
événement peut-il appartenir à une activité ? Le TMW considère en fait qu'une activité est un
ensemble d'événements dont l'occurrence a lieu suite à la réalisation de l'activité. En d'autres
termes, un événement survient toujours suite à la réalisation d'une activité est y est donc
1
Bien que les documents de la WfMC auxquels nous nous référons dans ce chapitre soient de 1995 et au delà,
ces derniers ont pour la plupart, en particulier le modèle de référence, une première version rédigée en 1994.

50
 Chapitre II : Workflow - Présentation, définitions et Concepts

intimement lié. A notre avis, cette conception de la relation entre événements et activité est un
peu limitative. En effet, elle suppose que les seuls événements à représenter dans un workflow
sont ceux qui indiquent la fin des activités. Ce fait est regrettable car le métamodèle, tel qu'il
est défini aurait pu supporter tous les types d'événements et augmenter ainsi l'expressivité des
modèles obtenus.
La méthode distingue également les acteurs responsables d'une activité de ceux qui la
réalisent. Cette distinction sous-entend donc qu'un acteur peut avoir plusieurs rôles dans une
organisation. Toutefois, la notion de rôle n'apparaît pas clairement dans le métamodèle.

Enfin, la méthode du Trigger Modelling propose trois étapes de modélisation que l'on pourrait
comparer aux étapes classiques de l'élaboration des logiciels : l'analyse, la conception et
l'implémentation. A chacune des étapes, le TMW associe respectivement trois types de
modèles. Chaque modèle possède ses propres formalismes et propose, selon l'étape de la
modélisation à laquelle il est lié, une vue plus ou moins détaillée des processus modélisés.

1. Première étape - le Trigger Model "d'analyse" : Le Acteur A Acteur B

Trigger Model d'analyse (fig. II.22) est surtout utilisé
comme moyen d'analyse et de compréhension des Activité 1

besoins. Il sert également à la communication entre

analystes et clients du processus. Ce modèle distingue Activité 2
deux types d'entités : les rôles et les activités. Les rôles
sont représentés par des colonnes intitulées par le nom du
rôle. Chaque colonne contient les activités que le rôle a la Figure II.22 - Trigger
responsabilité de traiter. Les activités quant à elles sont Model d'analyse
représentées par des rectangles contenant le nom de
l'activité. Les activités sont reliées entre elles par des
flèches.

2. Deuxième étape - le Trigger Model "de conception" :

cette deuxième étape a pour but de raffiner le modèle
d'analyse. Le raffinement est itératif, c'est à dire qu'il est
réalisé autant de fois que nécessaire pour arriver à un Acteur A Acteur B Acteur C

résultat satisfaisant. Par conséquent, le modèle obtenu se

doit d'apporter des formalismes permettant de prendre en Activité 1
compte ce niveau de détail. En effet, le modèle de
Activité 2
conception distingue trois éléments de formalismes :
Activité 3
§ Les cercles, qui représentent les activités atomiques – Activité 4
les actions – non décomposables et ne générant qu'un
seul événement. Activité 5

§ Les triangles, qui correspondent aux activités Activité 6

déclenchées par l'occurrence de plusieurs événements
de fin d'activités ou au contraire, génératrice n fois de
l'événement marquant sa réalisation. En d'autres Figure II.23 – Trigger
termes, l'activité peut notifier n activités qu'elle est Model de conception
terminée mais ne peut générer n événements distincts.
Selon le cas, la base du triangle sert de récepteur ou
d'émetteur d'événements.

51
 Chapitre II : Workflow - Présentation, définitions et Concepts

§ Les rectangles enfin, représentent des activités qu'il est possible de décomposer en
d'autres modèles TMW.

3. Troisième étape - Modèle "d'implémentation" : cette dernière étape a pour objectif de

traduire le modèle de conception en un réseau de Petri. La méthode propose certaines
règles de transition permettant de passer d'un formalisme à l'autre. Le modèle
d'implémentation sert à valider les modèles de workflows établis. Il peut également être
utilisé pour l'implémentation des workflows, à l'aide d'un système Workflow utilisant le
formalisme de RdP.

[Link] Avantages de la méthode Trigger Modelling for Workflow Analysis

La méthode TMW présente certains aspects intéressants mais reste globalement assez limitée.
Comme premier intérêt, nous pouvons noter que la méthode propose de décomposer le
processus de modélisation en plusieurs étapes – analyse, conception, implémentation – en
plus des possibilités de décomposition des activités ("rectangles" du modèle de conception).
Deuxièmement, la notion explicite de flux dirigé par les événements est très intéressante et
correspond très bien aux concepts du Workflow. Il est cependant regrettable qu'elle se limite
aux événements marquant la fin des activités. Enfin, le TMW est un moyen d'enrichir le
formalisme des RdP. L'intérêt est double puisque d'une part, la méthode profite des avantages
des RdP et de leur base mathématique, et d'autres part, elle introduit des formalismes
permettant d'augmenter la clarté des modèles obtenus.

[Link] Inconvénients de la méthode TMW

Malgré les concepts intéressants et prometteurs affichés par le métamodèle de la méthode, le

TMW souffre de quelques lacunes importantes. La première de celles-ci tient à l'exploitation
incomplète de la notion d'événement, que nous avons déjà soulignée dans le paragraphe
d'introduction. Deuxième lacune, la méthode ne prend pas en compte dans les différents
modèles, les objets qui sont manipulés à chaque activité, bien que le métamodèle y fasse
référence. On peut toutefois rétorquer à cette constatation que le TMW est essentiellement
utilisé pour l'analyse et la validation des modèles de workflows d'un point de vue dynamique
– détection des boucles, évaluation du temps, etc.. Cela reste cependant regrettable, d'autant
plus que les modèles d'analyse utilisent un formalisme inspiré des "diagrammes d'activités"
utilisés dans la notation objet UML, qui eux représentent le flux des objets entre les activités.
Enfin la méthode souffre globalement des même inconvénients que les RdP, dont elle partage
aussi les avantages, comme nous l'avons déjà indiqué.

[Link] Exemple de modélisation d'un workflow avec le Trigger Modelling for Workflow

Comme cela a été le cas pour les autres méthodes et formalismes, nous proposons une
modélisation à l'aide du TMW, du workflow de prise en charge d'une commande client. Cet
exemple nous permet de vérifier certains des inconvénients présentés par la méthode,
notamment en ce qui concerne les événements. En effet, comme on peut le constater sur les
figures de la page suivante, il n'est pas possible dans certains cas, de définir la cause de la
réalisation d'une activité - donc l'événement déclencheur. Par exemple, il n'est pas possible de
dire dans quel cas une commande sera annulée ou quand le colis sera livré, suite à la décision
du client. Bien évidemment, dans notre exemple, la compréhension est facilitée de par la
simplicité du cas. Par contre dans des exemples plus compliqués, la notation ne suffit plus
pour exprimer correctement l'ensemble des situations.

52
 Chapitre II : Workflow - Présentation, définitions et Concepts

Client Agent Agent Magasinier Client Agent Agent Magasinier

Marketing Comptable Marketing Comptable
Passer
commande Vérifier
disponibilité
Vérifier Passer
disponibilité commande

Facture
r
Annuler Facturer Préparer Annuler
indispo. colis non dispo.
Préparer
Payer. colis
Décision

Ne
Livrer pas
Annuler Annuler
colis payer.
non payé non payé Livrer
colis

Annuler Annuler
Figure II.24.a - Exemple de workflow non Payé non Payé
Modèle d'analyse TMW
Passer
commande
Figure II.24.c – Modélisation d'un
workflow avec TMW. Modèle de
Vérifier
conception
disponibilité Facturer Préparer colis

Payer
Livrer
Ne pas colis
payer

Annuler Annuler
non payé non payé

Figure II.24.b – Modélisation d'un workflow

avec le TMW. Modèle d'implémentation

3.2.5 - La méthode Communication / Action

La méthode Communication/Action ("Speech/Action") a été adaptée au Workflow par T.

Winograd et F. Flores [WINOGRAD 90], [ACTION 99]. Elle se base sur un concept bien
précis : la communication, et vise un objectif bien déterminé : la satisfaction du client. Ainsi,
au lieu de décrire des processus et des objets circulant dans une organisation, cette méthode
décrit plutôt une transaction entre un client et un fournisseur. En effet, pour Winograd et
Flores, le travail dans une organisation est avant tout réalisé par des personnes qui
communiquent et coopèrent entre elles. A chaque étape de la communication, on peut
identifier une personne cliente et une autre qui lui fournit un service. Par conséquent, l'analyse

53
 Chapitre II : Workflow - Présentation, définitions et Concepts

des processus métiers d'une entreprise doit se concentrer en priorité sur la façon d'améliorer la
communication, la collaboration et l'interaction entre les différents membres de l'organisation.

[Link] Description de la méthode

Pour la méthode Communication /Action, un workflow correspond à une transaction entre un

client et un fournisseur. La transaction ne s'arrête que lorsque le client est satisfait du produit
livré par le fournisseur avec lequel il est en relation. Une transaction est décrite par quatre
flèches circulaires entre un client et un fournisseur, comme le montre la figure II.25. Les
flèches représentent les quatre étapes principales composant une transaction :

1. La préparation : cette étape correspond à la formulation d'une requête par un client.

2. La négociation : suite à l'émission d'une requête, le client et le fournisseur se mettent
d'accord sur le cahier des charges à respecter par le fournisseur pour répondre à la requête
du client.
3. La réalisation : cette étape correspond à l'acte commis par le fournisseur pour livrer le
résultat de son travail.
4. L'acceptation : c'est la dernière étape d'un cycle de transaction. Elle correspond à l'acte
commis par le client pour accepter le produit du fournisseur. L'acceptation se base sur
plusieurs critères qui sont définis par le client en collaboration avec l'analyste Workflow,
lors des phases de modélisation. Par exemple la durée d'une transaction peut être un
critère d'acceptation.

Chaque étape donne lieu à des actes biens définis, commis par les rôle associés à l'étape en
question. En effet, Winograd et Flores estiment que quel que soit le type de transaction liant
un client et un fournisseur, elle peut toujours se résumer à des actes biens définis, liés à l'une
des quatre étapes principales. Par exemple, l'étape de négociation donne lieu à un acte de
"proposition de contre offre" de la part du fournisseur. Le client peut refuser commettre les
actes de "refuser l'offre", "d'accepter l'offre" ou de "faire une nouvelle proposition". Les
quatre étapes peuvent de plus se répéter plusieurs fois pour une même transaction, jusqu'à la
satisfaction du client. Signalons par ailleurs que si le client est en général l'initiateur de la
requête, il est également possible qu'il réponde parfois à une offre faite par le fournisseur.
Dans ce cas, c'est ce dernier qui est l'initiateur du workflow.

Bien entendu, la méthode prévoit la possibilité - tout à fait réaliste - qu'une transaction
nécessite la réalisation d'autres transactions en cascade. Par conséquent, on distingue deux
types de workflows : le "workflow primaire" ("primary workflow") et les "workflows
secondaires" ("secondary workflows") qui le composent. Le workflow primaire correspond à
l'objectif global du workflow en question, il distingue le client et le fournisseur principaux du
workflow. Les workflows secondaires sont représentés sur le même modèle ou séparément.
S'ils figurent sur le même modèle, alors ils sont liés au workflow primaire ou entre eux par
liens représentés par des flèches. On distingue deux façons d'établir des liens entre workflows:

§ Les liens orientés par les actes, qui signifient qu'un workflow secondaire est instancié
lorsqu'un des actes d'une étape est en cours de réalisation. Ce lien est représenté par
une flèche partant du début de l'étape en question.

§ Les liens orientés par les états, qui expriment qu'un workflow secondaire est initialisé
lorsque le workflow auquel il est lié entre dans l'une des quatre étapes répertoriées.
Dans ce cas le lien est représenté par une flèche partant de la fin de l'étape en question.

54
 Chapitre II : Workflow - Présentation, définitions et Concepts

La méthode distingue également cinq types de liens :

1. Le lien conditionnel, qui est représenté par un losange. Chaque flèche partant du losange à
destination d'un workflow secondaire, correspond à un choix. Il est utile de décrire
textuellement sur le lien la nature du choix ou la cause le justifiant.

2. Le lien de flux normal, il est représenté par une flèche pleine. Il déclenche un workflow
dont la réalisation permet l'avancée du processus métier vers la réussite.

3. Le lien de flux exceptionnel qui est par contre représenté par une flèche rouge et instancie
un workflow qui permet de prendre en charge des situations exceptionnelles ou des
problèmes.

4. Le lien de parallélisme, il indique que des workflows secondaires sont lancés en parallèle.
Les flèches représentant les liens doivent avoir la même origine sur le modèle.

5. Le lien de séquence, qui signifie que les workflows sont réalisés séquentiellement. Une
séquence est représentée par une flèche partant de la dernière étape d'un workflow et
aboutissant à la première étape du workflow qu'elle relie.

Workflow
Choix 1 a

Workflow
b
séquence Workflow Choix 2
préparation négociation primaire

But de la transaction
Workflow
Workflow c
acceptation réalisation e
workflow
Workflow parallèles
d

Figure II.25 - Transaction workflow

de la méthode Figure II.26 - Exemple de liens entre workflows
Communication/Action primaire et secondaires

Signalons enfin la possibilité de représenter les données associées aux workflows par une
flèche grisée, liée à une symbole représentant un support de stockage (cylindre). Il est de plus
possible de signaler des contraintes de temps sous la forme de petites horloges.

[Link] Avantages de la méthode Communication / Action

La méthode de Winograd et Flores caractérise un troisième type de modélisation Workflow

pour lequelle nous n'avions pas encore donné d'exemple : la modélisation à base de
communication. Comme nous avons pu le constater, cette méthode adopte une approche qui
diffère de ce que nous avons pu voir jusqu'à présent et qui n'est pas sans présenter plusieurs
aspects intéressants. En premier lieu, la méthode semble plus facilement abordable pour les
personnes impliquées dans les workflow et qui ne sont pas spécialistes de ce domaine. En
effet, l'aspect transaction entre un client et un fournisseur à l'avantage d'être simple et clair.

55
 Chapitre II : Workflow - Présentation, définitions et Concepts

Les personnes peuvent plus facilement comprendre leur rôle - client ou fournisseur - et sont
plus impliquées dans leur travail puisqu'elles sont responsables de la qualité du résultat obtenu
dans la transaction. De plus, la possibilité d'itérer les workflows (donc les transactions)
jusqu'à obtention des résultats fixés est un facteur de qualité et d'amélioration des processus,
similaire à l'approche de CPI.

Côté formalisme, nous noterons les possibilités très intéressantes de représenter

spécifiquement des workflows de prise en charge des situations à problèmes, ainsi que le
formalisme de l'horloge qui permet d'introduire sur le modèle même la notion de contrainte de
temps. En ce qui concerne la représentation des flux, la méthode propose, comme nous
l'avons vu, un certain nombre de moyens pour représenter les choix, le parallélisme et les
séquences - le minimum requis.

Enfin, dernier avantage non négligeable, il est important de signaler que la méthode
Communication / Action est utilisée dans un produit assez puissant, commercialisé sous le
nom de "Action Workflow".

[Link] Inconvénients de la méthode Communication / Action

Etant donné que la méthode ne se base pas dans son ensemble sur les mêmes concepts que les
méthodes que nous avons présentées précédemment, il est parfois délicat de la juger sur les
mêmes critères qui n'y sont pas toujours significatifs. Par exemple nous pourrions dire que les
événements ne sont pas pris en compte. Mais les événements sont-ils toujours dans le cas
présent des éléments importants, puisque l'essentiel lors de l'exécution, n'est pas d'enchaîner
sur une autre activité mais de réussir la transaction ? D'autre part la possibilité de représenter
des choix, d'établir des liens en fonction de l'état d'un workflow, et la prise en charge des
situations problématiques recouvre en grande partie cet aspect événementiel.

En fait, le premier inconvénient de la méthode est qu'elle est surtout destinée à des processus
qu'il est possible d'assimiler à des négociations. En effet, dans plusieurs cas les processus ne
sont pas composés d'activités nécessitant une négociation entre plusieurs acteurs mais
uniquement des compétences individuelles. L'aspect collectif du processus est alors donné par
l'assemblage des compétences individuelles et non par la communication entre les entités. Si
l'activité est individuelle, comment y représenter un client et un fournisseur ? Il est bien
entendu hors de question de considérer qu'un système d'information est un client ou un
fournisseur s'il n'a pas de rôle actif dans le processus mais n'est là qu'en tant que ressource.
D'autre part, on peut dire que la méthode est essentiellement dédiée à des utilisateurs humains
puisqu'elle ne descend pas dans le détail des workflows et se limite à des actes prédéfinis -
assez abstrait pour des machines ou des logiciels.

Enfin, nous pouvons signaler un autre inconvénient de la méthode - plutôt mineur - qui est sa
notation graphique. En effet, dès qu'il est nécessaire de représenter plusieurs workflows reliés
entre eux, le modèle (également appelé "carte du workflow" dans la méthode ("workflow
map")), prend vite des aspects tentaculaires, nuisibles à la compréhension du processus.

[Link] Exemple de modélisation d'un workflow avec la méthode Communication / Action

L'exemple que nous avons utilisé jusqu'à présent - celui du traitement de la commande d'un
client - n'est pas très adapté à la méthode de modélisation Communication / Action. En effet,
comme il est possible de le voir sur la figure II.27, plusieurs activités du processus sont des

56
 Chapitre II : Workflow - Présentation, définitions et Concepts

activités individuelles ne nécessitant pas la mise en place d'une négociation entre deux
acteurs. Le modèle de l'exemple met donc plus en avant les inconvénients de la méthode que
ses intérêts, quand elle est appliquée à des cas similaires.

Sur la figure II.27, nous pouvons constater que nous avons représenté un workflow secondaire
pour la recherche de la disponibilité des articles commandés par le client. Ce workflow met en
communication le magasin et le marketing. Il est en fait évident que la recherche de la
disponibilité de la commande ne nécessite que la consultation de la base de donnée du stock
de l'entreprise et non une communication directe. Plus encore, l'activité d'annulation de la
commande est représentée par un workflow secondaire vide car il ne met pas en relation des
acteurs pouvant tenir les rôles de client ou de fournisseur. On s'aperçoit donc bien par cet
exemple que la méthode ne permet pas d'entrer dans le détail des processus. En fait, pour
modéliser le workflow de prise en charge de la commande du client, seul le workflow
primaire aurait pu être suffisant, puisque effectivement les seuls à établir une vraie
négociation sont le client et l'entreprise (via le marketing).
Workflow primaire

Client Commande Entreprise

client

Agent Recherche Magasinier

Marketing disponibilité
Client
Livraison Magasinier

Facturation Agent
Client
Payé Comptable

Annulation Préparation Magasinier

colis
Agent
Marketing

Figure II.27 - Modélisation d'un workflow avec la méthode Communication / Action

Cet exemple ne doit pas pour autant faire oublier l'intérêt de cette méthode, notamment en ce
qui concerne les aspects de communication et de qualité qu'elle suscite chez les utilisateurs.

3.2.6 La méthode ARIS et les Diagrammes d'Enchaînement de Processus

La méthode ARIS [SCHEER 98] est une Méthode de Modélisation d'Entreprises (ou "en
entreprise") qui connaît un fort succès ces dernières années. Les outils informatiques qui ont
été développé autour font les premières ventes du marché et ont été intégré dans plusieurs
logiciels d'ERP ("Enterprise Ressource Planning") dont le plus célèbre est SAP.

Nous avons mentionné au début de ce chapitre que le Workflow n'était qu'un des aspects
couverts par la modélisation d'entreprise, dont le champ d'action est beaucoup plus vaste
puisqu'il ne se limite pas uniquement à la modélisation des processus et de leur flux. Nous
avons également dit qu'il existait une intersection entre les domaines traités par les MME et le
Workflow. Cette intersection concerne les quatre aspects théoriquement nécessaires à la
modélisation Workflow : l'aspect Informationnel, l'aspect Organisationnel, l'aspect

57
 Chapitre II : Workflow - Présentation, définitions et Concepts

Fonctionnel et l'aspect Comportemental. Ces aspects ne sont toutefois pas toujours développés
de façon égale dans la pratique, où l'accent est beaucoup plus mis sur l'aspect comportemental
et fonctionnel. Nous avons pu le constater lors de la description des méthodes et des
formalismes précédents, utilisés pour la modélisation Workflow. Quel est alors l'intérêt d'une
MME telle que ARIS pour la modélisation Workflow ?

En réalité, nous ne nous intéressons pas à l'ensemble de la méthode mais à certains de ses
aspects et de ses formalismes, qui nous semblent particulièrement bien adaptés à la
modélisation Workflow. Nous en donnons une description sommaire dans le paragaraphe
suivant.

[Link] Description de la méthode ARIS

Afin de réduire la complexité des modèles de l'entreprise, la méthode ARIS propose de les
décomposer en quatre modèles complémentaires correspondant aux quatre vues d'une
entreprise, respectivement :

1. La vue des données ("Data view"), qui représente l'ensemble des données utilisées lors de
l'exécution des activités de l'entreprise. Par donnée on comprend toute entité informatique
porteuse d'information, tel un document électronique ou une table de base de données. Un
modèle de donnée établit les liens qui existent entre les données elles-mêmes et entre elles
et des entités extérieures. Les données peuvent également être liées à des contraintes
temporelles ou autres, conditionnant leur état ou à des événements.

2. La vue des fonctions ("Function view"), décrit sous forme d'arbre la décomposition des
fonctions de l'entreprise. Les feuilles de l'arbre correspondent aux activités réalisées par
les employés.

3. La vue de l'organisation ("Organisation view"), représente l'organisation de l'entreprise en

termes d'unités organisationnelles et de personnes appartenant aux unités.

4. La vue des Ressources ("Ressources view"). Cette dernière vue concerne l'ensemble des
ressources de l'entreprise (logicielles et matérielles) qui peuvent être affectées aux
activités, lors de l'exécution.

A l'instar des méthodes de génie logiciel, ARIS propose plusieurs niveaux de modélisation, à
la granularité de détail toujours plus fine :

§ Le premier niveau correspond à la compréhension du problème et la collecte

d'informations.

§ Le deuxième niveau concerne l'expression des besoins et la formulation du problème –

"requirement definition level".

§ Le troisième niveau consiste en la conception du système – le "design specification

level".

§ Enfin le quatrième et dernier niveau est celui de l'implémentation – "implementation

level".

58
 Chapitre II : Workflow - Présentation, définitions et Concepts

Comme nous l'avons dit, la granularité du détail s'affine en fonction du niveau. A chaque
étape les vues : fonctionnelle, organisationnelle et informationnelle sont modélisées, en y
apportant au besoin un complément de précision. La vue ressource quant à elle, n'apparaît qu'à
l'étape de conception car elle concerne un niveau de détail beaucoup trop fin pour les étapes
précédentes.

Les vues de l'entreprise modélisées dans ARIS sont interconnectables deux à deux. Il est donc
facile d'établir des liens entre les vues pour obtenir une vue plus globale et complète de
l'entreprise. Cette vue existe dans ARIS et porte le nom de vue de contrôle ("Control view").
Les quatre vues : organisationnelle, fonctionnelle, informationnelle et de contrôle forment
l'architecture d'ARIS décrite par la figure – emblématique d'ARIS – présentée ci-après.

Par rapport à la modélisation Workflow, nous nous intéressons plus particulièrement à la vue
de contrôle, aux entités qui y sont représentées et à leurs formalismes. La vue de contrôle
étant la vue fédératrice des trois autres vues de l'entreprise, on y retrouve donc l'ensemble des
entités leur appartenant respectivement, ainsi que d'autres éléments supplémentaires. On
distingue ainsi :

§ Les données manipulées par les activités,

§ Les activités des processus,
§ Les acteurs responsables des activités,
§ Les événements déclencheurs d'activités ou émis par ces dernières,
§ Des opérateurs de flux et de synchronisation - XOR, AND, OR, en entrée et en sortie
des activités.

Vue organisationnelle

Définition
des besoins

Conception

implémentation

Définition Définition
Définition
des besoins des besoins
des besoins

Conception Conception Conception

implémentation
implémentation implémentation

Vue données Vue de contrôle Vue Fonctions

Figure II.28 – Architecture d'ARIS

Un workflow est décrit dans la vue de contrôle par des modèles associant ces éléments de
modélisation. Ce type de modèle est appelé "diagramme d'enchaînement de processus" ou
"Process Chain Diagram". Un PCD peut être représenté de deux façons :

§ A l'aide d'un tableau réunissant les entités provenant des différents modèles de vues.
Chaque colonne du tableau correspond à un type d'entité. Trois colonnes spéciales du

59
 Chapitre II : Workflow - Présentation, définitions et Concepts

tableau sont réservées à la description du type de l'activité (batch, interactive,

manuelle).
Événement Fonction Données Interactif Batch Manuel Système applicatif Unité Organisation.

Portail Web Unité A

Activité 1 Donnée 1
Événement entreprise
1
Flux de données
Flux de contrôle

Événement
2
∧

Événement
3 Système Unité B
Activité 2
logistique

SGBD Unité B
Activité 3 ∨

Véhicule Unité C
Activité 4 Donnée 2
de transport

Figure II.29 - Exemple de processus modélisé par Process Chain Diagram

sous forme de tableau

§ A l'aide d'un diagramme en forme de graphe, qui reprend la plupart des formalismes du
PCD tableau :
Unité B

Unité A Activité 3
Événement
3 Activité 2
∧ ∨
Événement Activité 1 Activité 4
Événement
1
2 Donnée 2

Donnée 1 Unité C

: événement : donnée : unité organisationnelle : flux de données

: activité/fonction : opérateur : flux de contrôle

Figure II.30 – Modélisation d'un workflow à l'aide d'un Process Chain Diagram de la
méthode ARIS

[Link] Avantages de la méthode ARIS

La méthode ARIS est une méthode qui connaît un succès assez important dans le milieu de la
modélisation d'entreprise. Certains diront que la méthode n'a rien inventé et qu'elle reprend
des concepts somme toute classiques. Ce fait est possible, d'ailleurs beaucoup des
formalismes utilisés dans les vues d'ARIS sont repris de modèles existants tel par exemple le
modèle entité / association pour la vue des données, ou la méthode CIMOSA pour
l'architecture [VERNADAT 97]. Il n'en reste pas moins que la méthode est claire, bien
structurée et que les différentes vues sont facilement intégrables les unes aux autres. En ce qui
concerne la modélisation Workflow en particulier, deux aspects nous semblent
particulièrement avantageux : d'une part les vues proposées par ARIS peuvent facilement être
"mapées" aux aspects à modéliser dans un workflow, et d'autre part, les PCD proposent des
formalismes qui concentrent toutes les entités nécessaires à la modélisation d'un workflow :

60
 Chapitre II : Workflow - Présentation, définitions et Concepts

données, contrôleurs de flux, événements et rôles. Il est même possible en suivant toutes les
étapes de la méthode d'arriver à un niveau de détail très fin, séparant les rôles des ressources.
En ce qui nous concerne, nous considérons que les PCD et ARIS en général sont très
intéressants pour la modélisation Workflow.

[Link] Inconvénients de la méthode ARIS

A priori, la méthode ARIS et les PCD ne présentent pas d'inconvénients particuliers pour la
modélisation Workflow, notamment pour la modélisation à base d'activités.

[Link] Exemple de modélisation d'un workflow à l'aide des PCD de ARIS

Agent
Marketing

non Envoyer Annuler Fin

Commande disponible
arrivée Excuse
Stock
Excuse Commande
Vérifier XOR
Commande Disponibilité
Agent
Agent Comptable
Marketing Magasinier

Envoyer Facture
Facture envoyée
∧ Livrer
Disponible colis
Facture
∧ Excuse
payée

Préparer Colis
colis prêt ∧ Annuler
commande

Facture
Magasinier
non
payée Agent Agent
Comptable Marketing

: événement : donnée : unité organisationnelle : flux de données

: activité/fonction : opérateur : flux de contrôle

Figure II.31 – Modélisation d'un workflow avec les PCD de la méthode ARIS

L'exemple modélisé ci-dessus montre bien l'adéquation des PCD à la modélisation de

workflow. La plupart des aspects à représenter figure sur le diagramme obtenu, qui gagne en
clarté. De plus, chaque entité figurant dans le PCD appartient à un modèle plus détaillé. Il est
donc possible de récupérer toutes les informations sur les éléments du diagramme. Enfin, les
modèles des vues de l'entreprise pouvant être implémentés dans différents systèmes
d'informations, le système Workflow peut s'intégrer facilement dans l'environnement
informationnel de l'entreprise.

Signalons enfin que nous n'avons rapidement présenté ici que la partie de ARIS présentant le
plus d'intérêts pour le Workflow. Il existe encore beaucoup de formalismes et d'aspects de la
méthode, que nous n'avons pas développé faute de place mais surtout parce qu'ils sont surtout
orientés vers la modélisation d'entreprise.

61
 Chapitre II : Workflow - Présentation, définitions et Concepts

3.2.7 La notation unifiée objet UML

La notation unifiée objet UML [MULLER 98], [RATIONAL 96] est le résultat de
l'unification des principales méthodes d'analyse, de conception et de développement Objet –
ou plutôt de leurs formalismes. Trois remarques sont importantes par rapport à UML :
premièrement, UML n'est pas une méthode mais une notation proposant un large éventail de
diagrammes et d'outils. Deuxièmement, UML n'est pas une notation spécifique au Workflow
mais est une notation générale, plutôt dédiée au développement de systèmes informatiques.
Enfin troisième remarque importante, UML est une notation "ouverte", c'est à dire qu'il est
possible d'augmenter et d'adapter son métamodèle. UML nous paraît intéressante pour
plusieurs aspects que nous aurons l'occasion de détailler par la suite. Notons tous simplement
pour l'instant la richesse de ces formalismes et la flexibilité de son métamodèle.

[Link] Description de la notation UML

UML propose plusieurs types de diagrammes, que l'on peut regrouper grossièrement dans
trois catégories principales :

1. Les diagrammes statiques,

2. Les diagrammes dynamiques,
3. Les diagrammes d'architecture.

1. Les diagrammes statiques : le premier type de diagramme d'UML permet de représenter les
entités du domaine modélisé, leurs propriétés et les relations qui les unissent. Dans cette
catégorie on distingue les diagrammes de classes (fig. II.32.a) et les diagrammes d'objets.
Les diagrammes de classes décrivent les
Classe A Classe C
relations entre classes d'objets. Selon la phase
attributs attributs
méthodes
1..1 *
méthodes
de modélisation (analyse ou conception) il est
possible d'ajouter la liste des attributs et des
fonctions des objets - appelées "méthodes",
Classe B
Classe D Classe E ainsi que d'indiquer leur visibilité par rapport
attributs
méthodes attributs attributs aux autres objets et leur type.
méthodes méthodes
: héritage / spécialisation Les diagrammes d'objets quant à eux sont des
Classe D
: composition diagrammes d'instances, c'est à dire qu'ils
attributs
méthodes : agrégation expriment les relations entre les objets et non
entre les classes des objets.
: association

Figure II.32.a - Diagramme UML de

classes

2. Les diagrammes dynamiques : la dynamique du système est décrite par deux facettes : le
comportement des objets et la collaboration entre objets, que nous décrivons ci-dessous :

a) Le comportement interne des objets : Ce comportement est décrit selon deux points de
vues distincts :

§ Le premier point de vue décrit les états qu'un objet peut prendre en fonction de
l'occurrence de certains d'événements. Les diagrammes utilisés sont appelés
"diagrammes d'états / transitions" (fig. II.32.b), inspirés des "statecharts". Un

62
 Chapitre II : Workflow - Présentation, définitions et Concepts

diagramme d'états / transition décrit les différents états d'un objet, depuis sa création
jusqu'à sa destruction. Chaque case marquant un état peut être détaillé. Il est ainsi
possible d'indiquer la ou les actions déclenchées lors de l'entrée de l'objet dans l'état,
les actions ou activités réalisées par l'objet Création
tant qu'il est dans cet état, ainsi que l'action
réalisée lorsqu'il le quitte.
Etat 1
Enfin, signalons qu'il est possible d'inclure [Événement b]

des diagrammes d'états transitions dans [Événement a] [Événement c]

Etat 2
d'autres diagrammes du même type. Cette
Etat 3
possibilité est utile dans deux cas : celui des : état
[Événement d]
objets imbriqués (objets composés d'autres : transition
[xxx] : événement
objets), cas dans lequel on peut souhaiter : création de l’objet
Destruction
représenter uniquement l'état de l'objet : destruction de l’objet

conteneur. Le deuxième cas où il est

également utile d'imbriquer des diagrammes Figure II.32.b - Diagramme UML
d'états / transition est quand l'objet lui-même d'états / transitions
possède des comportements - par exemple
une méthode - qui nécessitent des
diagrammes qui leurs sont propres.
Activité 1

§ Le second point de vue décrit le [choix 1] [choix 2]

comportement des objets par rapport à leurs Activité 2 Activité 3
actions et est traduit à l'aide de "diagrammes
d'activités" ([Link].32.c) dont ce n'est
Activité
d'ailleurs pas l'unique utilisation. En effet, Activité 4 Activité 5 composée
selon la granularité de modélisation adoptée,
les diagrammes d'activités permettent soit de Activité 6
: activité
décrire le comportement des méthodes des activité composée /
:
objets, soit de décrire l'enchaînement des sous-processus
: opérateur de choix
activités d'un processus. Dans le premier Activité 7
[xxx] : condition /choix /événement
cas, un diagramme d'activité décrit le {xxx}: contrainte
comportement des méthodes en termes : flux
: début du processus / fonction
d'activités qui sont déclenchées par des : fin du processus / fonction

événements. La notation prévoit des : Mise en parallèle du flux

: jonction / synchronisation
symboles de mise en parallèle d'activités,
leur synchronisation et des branchements
conditionnels. Enfin, nous traitons le Figure II.32.c – Diagramme d'activité
deuxième cas (modélisation d'un processus) UML : Modélisation d'une méthode
dans le paragraphe suivant.

b) La coopération des objets entre eux : cette coopération peut être décrite par trois types de
diagrammes différents :

§ Les "diagrammes de collaboration" (fig. II.32.d) décrivent un échange de messages

entre les objets. Selon le niveau de détail souhaité et en fonction de la phase de la
modélisation (analyse ou conception), les messages représentent des comportements
souhaités (phase d'analyse) ou plus précisément des méthodes des objets (phase de
conception).

63
 Chapitre II : Workflow - Présentation, définitions et Concepts

Objet 1 : Classe A 1 : message1( ) nomObjet : nomClasse : Instance d’une classe

message : appel d’une méthode d’un objet

Objet 1 : Classe B par un autre objet
[if condition ] / xxx : message : ordre du message dans les appels
2.a : message2a( ) 2.b : message2b( ) [Link] : message : mise en parallèle à partir de cet ordre.
2.a, 2.b/
.lettre = identifiant du flux parallèle
3 : message3( )
[Link] : message : choix à partir de cet ordre.
.chiffre = sous-ordre dans le choix
Objet 1 : Classe C Objet 1 : Classe D xxx, yyy, .../ zzz : message
: synchronisation de l’envoi du
message d ’ordre zzz après la
réalisation des messages xxx, yyy, ...

Figure II.32.d – Diagramme de collaboration UML

Les messages sont indexés chronologiquement. Il est possible de représenter des mises
en parallèle, des boucles, des comportements conditionnels et des synchronisations de
messages.

§ Les "diagrammes de séquences" (fig. II.32.e) Obj. 1 : Classe A Obj. 2 : Classe B

sont l'équivalent des diagrammes précédents Message 1

mais sont plus orientés sur la visualisation de la
Retour
chronologie de l'envoi des messages. Pour ce
faire, ces diagrammes adoptent une notation en
forme de lignes de flux, chaque ligne étant
Message n
associée à un objet. Les messages sont
Message interne
représentés par des flèches à des niveaux
différents des lignes. A l'instar des diagrammes
de collaboration, les messages correspondent à
des ébauches d'interactions ou à l'appel de
méthodes des objets destinataires, selon la phase t

de modélisation. Dans le cas de la conception par

exemple, il est possible si souhaité, de Figure II.32.e – Diagramme de
représenter la durée d'un message en séquence UML
représentant ce dernier sous la forme d'un Objet A Objet B
rectangle plus ou moins allongé selon la durée.
Activité 1
§ Les "diagrammes d'activités" (fig. II.32.f) sont [Evénement a]
également utilisés pour décrire la collaboration Donnée
entre objets – en plus du comportement des a : état 1

méthodes. Les même formalismes sont utilisés Activité 2

avec quelques variantes. Par exemple les Donnée [ if X]

activités d'un objet sont représentées sur des a : état 2

lignes de flux ou dans des "couloirs" attribués

des objets actifs. Les activités – qui peuvent
Activité 4 Activité 3
correspondre à des sous processus, sont liées
entre elles par des flèches qui correspondent au
"contrôle de flux". Il est en outre possible de
représenter les objets qui sont manipulés par Figure II.32.f - Diagramme
chaque activité en indiquant leur état. Enfin, en d'activité UML : modélisation
liant ces objets entre eux il est possible de d'un processus
représenter le "flux de données" du diagramme.

64
 Chapitre II : Workflow - Présentation, définitions et Concepts

3. Les diagrammes d'architecture : cette dernière catégorie de diagramme permet de décrire

l'architecture du système modélisé. A l'instar des autres catégories, plusieurs diagrammes
sont disponibles, en fonction du détail souhaité. Nous ne décrirons pas ici les différents
formalismes proposés, faute de place et parce qu'ils présentent un intérêt limité pour la
modélisation Workflow.

4. Les diagrammes de "cas d'utilisation" Rôle

Utilisation
(fig. II.32.g) permettent de modéliser les 1 interaction 1
fonctionnalités d'un système, en phase
d'analyse de ce dernier. Les Rôle Utilisation
2 2
fonctionnalités sont représentées en <<extends> Utilisation
fonction des besoins des utilisateurs, et Utilisation > 4
3
plus particulièrement du "profil" de leur
profils. On parle de "rôles" des << uses >>
Utilisation
utilisateurs. Ceux ci y sont représentés 5
: cas d’utilisation /
sous la forme de personnages en fonctionnalité
"bâtonnets". Un personnage représente en : interaction
fait un rôle que peuvent prendre un ou interaction : nom - nature de
plusieurs utilisateurs. Chaque rôle est lié à l’interaction

un ou plusieurs cas d'utilisations qui décrit

d'un mot clé, l'usage que fait le rôle du Figure 32.g - Diagramme de cas
système. Un cas d'utilisation peut faire d'utilisation
appel aux services d'autres cas d'utilisation
(relation d'utilisation) ou les spécialiser (relation d'extension). Notons enfin que les cas
d'utilisation sont souvent complétés par des diagrammes de séquence décrivant à un haut
niveau, les interactions entre les acteurs et le système.

[Link] Avantages de la notation UML

Bien que la notation UML ne soit pas spécifiquement dédiée à la modélisation Workflow, elle
n'en présente pas moins certains avantages – et des avantages certains. D'une façon générale,
nous notons trois intérêts principaux :

§ L'intégration des diagrammes UML entre eux. Cela permet de proposer plusieurs vues
totalement complémentaires d'un système, d'où une modélisation plus puissante.

§ Le nombre important de formalismes disponibles qui permettent de prendre en compte la

plupart des aspects nécessaires à la modélisation d'un système.

§ La possibilité "d'augmenter" la notation grâce au concept puissant de "stéréotype". Un

stéréotype permet de créer de nouveaux types qu'il est possible d'ajouter au métamodèle
d'UML. Par exemple on peut créer le stéréotype "workflow" pour lequel on définit des
propriétés, un formalisme graphique et un métamodèle, au besoin. Ce stéréotype peut
ensuite être utilisé dans la modélisation au même titre que n'importe quel concept d'UML.
Autre aspect intéressant, les stéréotypes peuvent être utilisés pour établir une
correspondance avec les formalismes d'autres méthodes - par exemple ARIS.

Par rapport à la modélisation Workflow, nous nous intéressons plus particulièrement à trois
types de diagrammes : les diagrammes de cas d'utilisation, les diagrammes d'activités et les
diagrammes de classes. Les diagrammes de cas d'utilisation permettent de saisir rapidement

65
 Chapitre II : Workflow - Présentation, définitions et Concepts

les besoins des processus modélisés en phase d'analyse. Cela est par exemple le cas pour la
méthode WIDE de modélisation de workflows [WIDE 97]. Les diagrammes de cas
d'utilisation permettent de distinguer rapidement les principaux sous-processus et rôles du
workflow.

Les diagrammes d'activités sont les diagrammes les plus intéressants et les mieux adaptés à la
modélisation Workflow. En effet, ils se prêtent très facilement à la représentation des
processus et plus particulièrement de l'ensemble des éléments des modèles Workflows à base
d'activités, respectivement : les rôles, les activités, les événements, les contrôle de flux et les
flux de données. De plus, chaque entité d'un diagramme d'activité peut être décrite en détail
par d'autres diagrammes. Par exemple on peut décrire les propriétés et le comportement des
données à l'aide de diagrammes d'états / transitions, et les relations qui existent entre les
données à l'aide de diagrammes de classes. Il en est de même pour les rôles et les acteurs
associés aux activités.

Autre avantage, UML peut être utilisé en tant que moyen de communication entre les
différents acteurs du projet Workflow – par exemple entre les analystes de processus et les
programmeurs. En effet, étant donné que la notation UML est générale et non spécifique à un
domaine particulier, elle peut être utilisée à différents niveaux du projet. Ainsi que le souligne
P. Hruby [HRUBY 98], l'avantage est donc que les différents spécialistes puissent utiliser les
mêmes formalismes ou des formalismes appartenant à la même notation, donc
compréhensibles par tous. Enfin dernier point très important à souligner qui est la base objet
d'UML et tous les avantages qui découlent des caractéristiques intrinsèques des objets, en
particulier les propriétés d'adaptation et de spécialisation. Nous reviendrons d'ailleurs plus
longuement sur la discussion de ce dernier aspect dans les prochains chapitres.

[Link] Inconvénients d'UML

UML nous le rappelons, n'est pas initialement dédiée à la modélisation Workflow mais à la
modélisation objet de systèmes informatiques. Ce que nous proposons donc, c'est une
adaptation des outils proposés par UML à la modélisation Workflow. Il existe en fait dans la
notation UML, une réflexion et certains formalismes dédiés à la modélisation de processus.
C'est la partie intitulée "UML for business Modelling" [RATIONAL 96]. Cette partie
introduit des stéréotypes spécifiques à la modélisation de processus, tels les stéréotypes
d'acteur, d'activité ou de processus métier. Néanmoins, cette percée reste très peu développée
dans la version 1.1 d'UML et peu attirante. Cela ne nuit cependant en rien à l'intérêt des outils
proposés par UML. Il s'agit juste d'organiser une réflexion sur comment les utiliser et les
adapter à la modélisation Workflow, ce qui est le cas actuellement dans la communauté UML.

Etant donné qu'UML n'est pas une notation Workflow, il est probable qu'elle présente
certaines lacunes. Une présentation intéressante a été réalisée à ce sujet par O. Wiegert de
SAP [WIEGERT 98]. Ce dernier distingue principalement six aspects à perfectionner dans
l'application d'UML à la modélisation de processus, respectivement :

§ La séparation du type des diagrammes d'activités de celui des diagrammes d'états. En

effet, selon le document de spécifications, un diagramme d'activité est une spécialisation
des diagrammes d'états. Or certaines restrictions imposées aux diagrammes d'états ne le
sont pas aux diagrammes d'activités. Cette réflexion est plutôt d'ordre "puriste" car elle se
base sur le fait qu'une spécialisation ne peut alléger des contraintes mais en introduire de
nouvelles - ce qui est discutable.

66
 Chapitre II : Workflow - Présentation, définitions et Concepts

§ Permettre la mise en parallèle non contrainte des activités, c'est à dire permettre de décrire
les interactions entre activités parallèles, ce qui n'est pas explicitement mentionné par la
notation.

§ Permettre que le nombre de threads parallèles soit défini en cours d'exécution au lieu
d'être fixé par le modèle.

§ Fournir des formalismes et des opérateurs décrivant des événements, ce qui est important.
On pourrait ajouter à cela la nécessité de fournir des opérateurs de contrôle de flux plus
développés que ceux proposés par UML, tels par exemple des opérateurs logiques.

§ Etendre les capacités de représentation des flux de données dans les diagrammes
d'activités

§ Proposer des solutions organisationnelles, par exemple établir un lien explicite entre rôles
et un modèle organisationnel en UML, introduisant des concepts organisationnels tels
ceux que l'on peut retrouver dans ARIS.

En fait, l'analyse de O. Wiegert s'attaque

Client Agent Agent Magasinier
plus à la façon dont le métamodèle et les Marketing Comptable
spécifications UML prévoient l'utilisation Passer
commande
de la notation, qu'à la façon de faire
Vérifier
l'adaptation au Workflow. En effet, s'il est disponibilité
indéniable que les aspects relevés par [Commande disponible]
Wiegert sont importants et qu'il est Commande
valide
nécessaire d'y remédier, il est quand même
possible d'adapter la notation selon les [Commande
non disponible]
besoins spécifiques de chacun, en Facturer Préparer
colis
n'utilisant de surcroît que des formalismes
UML. Le risque de "défigurer" la notation Lettre Envoyer [Facture [Colis
d’excuse Lettre payée] prêt]
est donc très réduit puisque seules des
règles "mineures" risquent d'être colis
Annuler
outrepassées. Cela est d'autant plus commande
réalisable que le métamodèle UML se veut
être un métamodèle ouvert, donc Commande
annulée Livrer
adaptable. En fait, le problème à notre avis, colis
est que UML est "coincée" entre la volonté [Facture non
d'en faire un standard universel de la payée] colis
modélisation objet et son métamodèle
ouvert, qui pourrait intégrer toutes sortes
d'adaptations en dehors de toute Annuler Annuler
standardisation. Par conséquent, toute Commande Commande
adaptation doit d'abord faire l'objet d'une
proposition (Request For Proposal - RFP) Figure II.33.a - Exemple de modélisation d'un
soumise et validée par l'Object Workflow avec UML
Management Group - OMG - pour l'inclure
ensuite en tant que nouveau standard de la
notation

67
 Chapitre II : Workflow - Présentation, définitions et Concepts

[Link] Exemple de modélisation de workflow avec UML

L'exemple de la figure II.33.a reprend notre problème de prise en charge d'une commande
client. Nous utilisons un diagramme d'activités pour représenter le workflow correspondant.
Comme nous pouvons le constater, le diagramme suffit amplement à représenter tous les
aspects nécessaires à la modélisation d'un workflow. On peut facilement distinguer les
contrôle de flux et de données, qui se confondent lorsque les données sont consommées par
les activités suivant l'activité émettrice. Les événements sont représentés ainsi que les
mécanismes de mise en parallèle et de synchronisation. On peut toutefois regretter l'absence
d'opérateurs logiques dont la présence permettrait parfois d'augmenter la clarté du modèle. Par
ailleurs, la figure ci-dessous montre comment il est ensuite facile de lier les différentes vues
entre elles via leurs modèles, preuve qu'UML est un bon outil d'intégration.
Agent
Client Marketing
Unité
Passer Organisationnelle
commande
*
Commande Vérifier
disponibilité Service
Financier
1..1 Commande
valide
Excuse
Facturer * *
Agent Agent
Marketing Comptable
Agent
*
Comptable
Article Vue
Vue
comportementale Vue
Données
organisationnelle

Figure II.30.b - Intégration des vues et des modèles avec UML

3.2.8 Autres méthodes et formalismes

Les méthodes et formalismes que nous avons présentés précédemment s'intéressent à fournir
en premier lieu, une modélisation graphique des workflows et de leurs entités. Ainsi que nous
l'avons mentionné dans le paragraphe 3.1, il existe différentes approches de la modélisation,
dont l'une consiste en une description textuelle des workflows, à l'aide d'un langage de
description adéquat. Dans beaucoup de cas, le langage de modélisation s'inspire directement
des bases de données actives [EDER et al. 98]. Le langage de modélisation des workflows sert
à définir des déclencheurs (triggers) permettant de décrire le contrôle de flux du Workflow.
Bien qu'une approche graphique de la modélisation soit préconisée pour la représentation des
workflows [BARTHELMESS et al. 95], notamment pour des raisons de simplicité
d'utilisation, les langages de description de processus à l'aide de déclencheurs sont assez
intéressants. En premier lieu, si le langage utilisé est basé sur celui de la base de donnée sous-
jacente, on assure l'intégration du workflow avec ses données d'une part, et d'autre part avec
les autres systèmes informatiques en coopération avec la BD. De plus, le langage peut tirer
profit de toutes les capacités de la BD, notamment en terme de sécurité et de contrôle de
cohérence des données, qui peut être étendu à contrôle des processus. D'autres systèmes
peuvent adoptent également une approche mixte consistant en une modélisation graphique à
haut niveau, puis en une transcription en un langage donné (souvent à base de déclencheurs).
C'est notamment le cas de WIDE [BARESI et al. 99] et du système OPERA [ALONSO et al.
97a].

68
 Chapitre II : Workflow - Présentation, définitions et Concepts

3.3 Conclusion sur les méthodes de modélisation Workflow

La recherche dans le domaine du Workflow est très active et est due à un grand nombre de
laboratoires universitaires. Leurs travaux sont souvent repris en partie dans les systèmes
commerciaux et peuvent également aboutir à la mise sur le marché de systèmes Workflows. Il
va sans dire qu'il existe donc un grand nombre de méthodes et de formalismes, nous l'avions
d'ailleurs déjà mentionné et nous en avons présentés dans ces quelques pages. Il est toutefois
important de mentionner l'existence de nombreuses autres méthodes intéressantes telles
OORAM [REENSKAUG 95] ou OSSAD [NURCAN 96], etc.. Malgré leur intérêt, nous ne
décrirons pas ces méthodes. D'une part parce leur description serait trop volumineuse mais
surtout parceque celles que nous avons déjà présentées sont celles qui sont principalement
utilisées dans ce domaine, dans leur forme d'origine ou comme base pour des versions
améliorées. Remarquons enfin à ce sujet que la profusion de formalismes et de méthodes,
parfois même de concepts, augmente le fossé existant entre les différents systèmes
Workflows. Leur standardisation et l'interconnexion des systèmes Workflows hétérogènes est
d'ailleurs l'un des principaux efforts de la WfMC qui a produit plusieurs documents à ce sujet.
En particulier il est important de citer le langage d'échange de définitions des processus. Ce
langage permet de décrire un workflow selon les concepts définis par la WfMC, à l'aide d'une
syntaxe standardisée. Il devrait permettre à des systèmes Workflows hétérogènes de
s'échanger des modèles de workflows et par suite, répartir l'exécution des workflows sur
différents sites et systèmes. Un autre effort de standardisation est également fourni par
l'Object Management Group (OMG - [Link] - sous la forme d'un framework
objet et de description IDL, le langage de description d'interfaces de CORBA. Nous
reviendrons d'ailleurs plus en détail par la suite sur ce framework.

4. Evolution du Workflow
Ainsi que nous l'avons mentionné au tout début de ce chapitre, le marché du Workflow a
connu une croissance spectaculaire du début jusqu'aux deux tiers des années 90, pour
connaître ensuite une réorientation des stratégies du marché. En effet, le Workflow est apparu
au moments où les besoins de gestion de processus et de travail coopératifs étaient mis en
évidence. Cette apparition a de plus coï ncidé avec les méthodes de management orientées vers
les processus, telle le BPR et la CPI dont nous avons parlé précédemment. Par conséquent le
succès du Workflow, technologie proposant des solutions aux problèmes de l'heure ne s'est
pas fait attendre. Ce succès est également du au phénomène que nous pourrions qualifier de
"mode technologique" et que P. Strassman nomme "the Joneses syndrome" - selon
l'expression anglo-saxonne consacrée [STRASSMAN 97]. Ce phénomène se traduit par le fait
que les entreprises mettent parfois en œuvre une nouvelle technologie parce que ses
concurrents l'ont fait. Cela est souvent le cas en informatique où l'on voit tous les six ou sept
mois une nouvelle technologie se présenter et connaître le plus souvent, un rapide
engouement. Cela ne va toutefois pas jusqu'à dire que le Workflow n'est qu'un phénomène de
mode, bien au contraire. Aujourd'hui, le marché du Workflow continue de croître mais d'une
façon moins exponentielle. Trois tendances sont en concurrence [ZUR MULLEN et al. 00]:
§ Les systèmes Workflows propriétaires, qui sont indépendants des autres systèmes de
l'entreprises avec lesquels ils coopèrent ou qu'ils utilisent en tant que ressources. C'est le
cas aujourd'hui du plus grand nombre des systèmes Workflow.
§ Les systèmes Workflow s'intégrant en tant que module ou moteur de gestion de processus
dans des progiciels, notamment les systèmes d'ERP (Engineering Ressource Planning) tels

69
 Chapitre II : Workflow - Présentation, définitions et Concepts

le célèbre SAP, qui se situent à un niveau plus global - celui de l'entreprise en entier. C'est
la tendance la plus forte actuellement
§ Enfin, on distingue également les systèmes Workflow s'intégrant dans une suite complète
de solutions, dont un exemple est la suite MQSeries de IBM.

Outre la réorientation stratégique des systèmes Workflow au sein des entreprises, la nouvelle
génération de systèmes doit également affronter un problème de taille, celui de la flexibilité.
En effet, les avantages et points forts des systèmes Workflow sont également leurs principales
faiblesses. En effet les systèmes Workflow - notamment les systèmes orientés processus - ont
bien atteint leur objectif principal qui est de permettre de contrôler les flux de tâches et de
données, de gérer au mieux les processus. Mais ils ont également figé les entreprises dans des
cadres et des modèles trop rigides où toute modification est coûteuse en temps et par
conséquent en argent. Par suite, l'une des priorités des nouveaux systèmes Workflow réside
dans la mise en œuvre de solutions flexibles, permettant aux modèles d'absorber les incidents
et d'évoluer plus facilement pour s'adapter aux besoins de changements extérieurs. Ces
aspects de flexibilité et de nouvelle orientation du Workflow sont la base du chapitre suivant,
où ils sont présentés, décrits et commentés.

Bibliographie
[ACTION 99] Action Technologies. "Introducing ActionWorkflow Methodology
overview and Implementation guidelines". 1999. [Link]
[THUILLIER et al. 98] F. Thuillier, G. Saccone, "Workflow SI et Objets métiers". Présentation à la
réunion du groupe de travail sur la Conception Orienté Objet des Systèmes
d'Information. 27 mai 1998.
[ALONSO et al. 97a] G. Alonso, C. Hagen. 'Geo-Opera: Workflow Concepts for Spatial
Processes". Proc. 5th Intl. Symposium on Spatial Databases
(SSD '97), Berlin, Germany. Juin 1997.
[ALONSO et al. 97b] G. Alonso, C. Mohan, "Workflow Management Systems: The Next
Generation Of Distributed Processing Tools". In "Advanced Transaction
Models and Architectures", S. Jajodia and L. Kerschberg (Eds.), Kluwer
Academic Publishers, 1997, pp. 35--62.
[ANAXAGORAS 94] ANAXAGORAS B.P. Innovations. "Trigger Modelling for Workflow
Analysis". [Link] 1994.
[BANNON 90] L.J. Bannon. 'Pilgrim's Progress: From Cognitive Science to Cooperative
Design". AI & Society, 4,4, Fall Issue. 1990. pp. 259-275
[BARESI et al. 99] L. Baresi, F. Casati, S. Castano, S. Ceri, M.G. Fugini, I. Mirbel, B. Pernici.,
G. Pozzi. "WIDE Workflow Development Methodology". Report n°3027-6.
ESPRIT Project 20280. 3 Mars 1999.
[BARTHELMESS et al. 95] P. Barthelmess, J. Wainer, "Workflow Modeling". CYTED-RITOS
International Workshop on Groupware", Lisbon, Portugal, Septembre 1995.
[BERRY 98] P. Berry. "Intelligent Workflow – State of the Art in Workflow".
[Link] 1998.
[BRAMS 83] G.W. Brams. " Réseaux de Petri : Théorie et Pratique". Ed. MASSON.
1983.
[CASATI 96] F. Casati, S. Ceri, B. Pernici, G. Pozzi. 'Deriving Active Rules
for Workflow Enactment". DEXA Database and Expert
Systems Applications. Zurich, Suisse. 9-13 Septembre 1996.
[CHAT 98] CHAT. "CHAT - Theoritical framework – Cultural – Historical Activity
Theory". Center for Activity Theroy and Developmental Work Research.
Univeristy of Helsinki. [Link] 1998.
[COURTOIS 96] [Link], "Logiciels & Systèmes N°11", p. 46. Septembre-Octobre 1996.
[DUPOIRIER 94] G. Dupoirier. "Technologie de la GED : l'édition électronique". Hermes.
1994.

70
 Chapitre II : Workflow - Présentation, définitions et Concepts

[EDER et al. 96] J. Eder, H. Groiss, W. Liebhart. "Workflow Management and Databases".
2eme Forum International d'Informatique Appliquée, Tunis, Mars 1996.
[EDER et al. 98] J. Eder, W. Liebhart. "Contributions to Exception Handling in Workflow
Management". Proc. EDBT Workshop on Workflow Management Systems,
Valencia, 1998, pp 3-10
[FRYER 94] C. Fryer. "Move to workflow Provokes Business Process Scrutiny".
Software Magazine. Avril 1994.
[GEORGAKOPOULOS et al. 95] D. Georgakopoulos, M. Hornick, A. Sheth, "An Overview of Workflow
Management : From Process Modeling to Workflow Automation
Infrastructure", Distributed and Parallel Databases, An International Journal,
3, 1995.
[GUIMARAES et al. 95] N. Guimarães, A.P. Pereira. "Workflow Modeling, Automation,
Augmentation – Enlighting experiences in the ORCHESTRA project". NSF
Workshop on Workflow & Process Automation in Information systems,
State of the Art and Future Directions. Athen
[HRUBY 98] P. HRUBY, Specification of Workflow Management Systems with UML,
OOPSLA 98: Workshop on Object Oriented WMS, 1998.
[INCONCERT 97] InConcert. "InConcert Specifications Document".
[Link] 1997.
[IDEF0 93] IDEF0. "Integration Definition For Process Modeling". Draft federal
Information Processing Standard Publications I83. 23 Décembre 1993.
([Link]
[JABLONSKI et al. 94] S. Jablonski, C. Bussler, "Process Modeling and Execution in Workflow
Management Systems". Proc. of the 3rd International Workshop on
Information Technologies and Systems, Orlando, FL, Décembre 1993.
[JOOSTEN 94] S. Joosten, "Trigger modelling for workflow analysis ". CON’94 : Workflow
Management, pp. 236-247,publ : R. Oldenbourg, Vienna, München, 1994.
[JOOSTEN et al. 95] [Link], S. Brinkkemper, "Fundamental Concepts for Workflow
Automation in Practice", ICIS’95 conference, Amsterdam, Décembre 1995.
[KOULOPOULOS 98] T. Koulopoulos. "Workflow Reference Market Point 97".
[Link] 1998.
[MARSHAK 95] R. Marshak, "Rethinking workflow part I & II". [Link]
[Link]/alunos/dti/wdl/workflow/[Link]. 1995.
[MAYER et al. 95] J. Mayer, [Link], [Link], [Link]. "A Framework and a
Suite of Methods for Business Process Reengineering", Part one.
[Link] 1995.
[McCREADY 93] S. McReady. "There is more than one kind of workflow software".
Computerworld. 2 Novembre 1992.
[MULLER 98] P.A. Muller, "Modélisation Object avec UML". Eyrolles. 1998
[NURCAN 96] S. Nurcan, "Analyse et conception de systèmes d'information coopératifs".
Techniques et science informatiques, Vol. 15, n°9, pp. 1287 – 1315. 1996.
[REENSKAUG 95] T. Reenskaug. "Working With Objects. The OORAM Software Engineering
Method" . Manning/Prentice Hall. 1995.
[PELLETIER 98] F. Pelletier. Introduction à la GEIDE. MOS Magazine. ARCA Editions.
1998.
[RATIONAL 96] Rational Software Corporation. "UML Resource Center, Unified Modeling
Language, Standard Software Notation V. 1.3". 1996.
[RATIONAL 97b] Rational Software Corporation. "UML Extension for Business Modeling
version 1.1". 1997.
[RYDER 98] M. Ryder. "Spinning Web of Significance, Considering Anonymous
Communities". 4th Congress of the International Society for Cultural
Research And Activity Therory. Aarhus University, Aarhus, Denmark. 7-11
Juin 1998.
[SCHAEL 97] Thomas Schaël. Théorie et Pratique du Workflow. Springer-Verlag. 1997.
[SCHEER et al. 97] A.W SCHEER, R. ROBOWSKY, S. KALBUNDE, A. TAUT, Flexible
industrial applications through model based workflows, Proc. Of the
International conference on Enterprise Integration and Modeling
Technology. Torino, Italy. 1997.
[SCHEER 98] A.W. SCHEER, Business Process Engineering, Springer 1998
[STARK 98] [Link], "Introduction to Engineering Workflow ".

71
 Chapitre II : Workflow - Présentation, définitions et Concepts

[Link] 1998
[STRASSMAN 97] P. STRASSMAN, "Has Business Squandered The IT Payoff ? ", Computer
Finance, Issue Number :8.01, Janvier 1997.
[TARDIEU et al. 85] Tardieu, Rochfeld. "Méthode MERISE, démarche et pratique". Tome 2.
Editions D'Organisation. 1985.
[VAN DER AALST et al. 99] W. Van der Aalst, D. Moldt, R. Valk, [Link]. "Enacting
Interorganizational Workflow Using Nets in Nets". Workflow Management
'99, Conference on Workflow Based Applications. University of Muenster,
Germany. 9 Novembre 1999.
[VERNADAT 96] F. Vernadat. "Enterprise Modeling and Integration – Principles and
Applications". Chapman & Hall, 1996.
[VERNADAT 98] F. Vernadat. "Enterprise Integration Issues--An application viewpoint";
ICEIMT'97 International Conference on Enterprise Integration Modeling
Technology. 1997 28/30 Octore, Torino, Italy. 1997.
[WAINER et al. 95] J. Wainer, M. Weske, G. Vossen, C. Medeiros. "Scientific workflow
systems". NSF Workshop on Workflow and Process Automation, USA.
1996
[WfMC 95] WfMC. "The Workflow Management Coalition specifications".
[Link] 1994.
[WfMC 99] Workflow Management Coalition. "Terminologie et Glossaire Workflow".
v. 2.0 Fev. 1999. ([Link]
[WIEGERT 98] O. WIEGERT. "Business Process Modeling & Workflow Definition with
UML". [Link]
[WIDE 97] WIDE. "The WIDE Workflow model and Language". Report n°4080-2.
ESPRIT Project 20280. 31 Octobre 1997.
[WINOGRAD 87] T. Winograd. "A language/action perspective on the design of cooperative
work," Human-Computer Interaction 3:1. 19987. pp. 3-30.
[WINOGRAD 90] T. Winograd. "What can we teach about Human-computer interaction?"
Proc. of the CHI90 Conference on Human Factors in Computing, Seattle,
Avril 1990. pp. 443- 449.
[ZUR MULLEN et al. 00] M. zur Mühlen, R. Allen, "Autonomous and Embedded Workflow. A
Workflow Management Coalition Classification". Workflow Management
Coalition White Paper, Lighthouse Point (FL), USA. 2000.

72
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Chapitre III
Workflow et Systèmes Workflows avancés

1. Limites des Systèmes Workflows

Après avoir connu une période de forte expansion dans la première moitié des années 90, le
marché du Workflow s'est stabilisé voire même tassé. A la fin du chapitre précédent, nous
avons mentionné la façon dont ce marché se réorientait vers trois approche distincts : les
systèmes Workflow propriétaires et autonomes, les systèmes intégrés dans les progiciels et
enfin les systèmes intégrés dans une suite de solutions logicielles. En fait, l'essoufflement du
marché peut s'expliquer par la combinaison de plusieurs raisons que nous classons par ordre
croissant d'importance :

§ La fin d'un "phénomène de mode" qui incitait certaines entreprises à "faire du

Workflow" sans vraiment avoir cerné son adéquation à leurs besoins. Ce phénomène
est bien présent en informatique, à chaque fois qu'une nouvelle technologie apparaît.

§ La volonté qu'ont certaines entreprises de gérer plus que les processus métiers. Ce
besoin fait que les systèmes Workflows "de la première génération", notamment les
systèmes propriétaires - majoritaires sur le marché - ne sont pas vraiment en
adéquation avec les attentes de ces entreprises. Ce fait s'exprime clairement par les
nouvelles orientations du marché dont nous avons parlé précédemment.

§ La cause la plus importante expliquant le tassement du marché du Workflow et "la

désillusion" des utilisateurs, pour reprendre les termes de R. SIEBERT [SIEBERT 98],
provient des systèmes Workflows eux-mêmes. Si ceux-ci proposent des solutions
efficaces pour la gestion rigoureuse des processus et ont en cela atteint la majorité des
objectifs qui leur étaient initialement fixés, ils sont victimes de leurs propres
fonctionnalités. En effet, la gestion des workflows, telle que nous l'avons décrite dans
les chapitres précédents, nécessite dans un grand nombre de cas, une modélisation
précise et bien structurée des processus à gérer. Une fois le modèle établi, il est "figé"
et par conséquent ne peut être aisément modifié en cours d'exécution, transformant les
entreprises en structures peu flexibles. Dans le paragraphe suivant, nous développons
plus avant ce problème de non-flexibilité pour lequel nous décrivons au préalables, les
causes principales.

1.1 Causes des limites des systèmes Workflows

Les entreprises sont sans cesse soumises à de nouvelles contraintes issues du marché et à de
nouveaux défis. Les entreprises les plus performantes sont donc celles qui s'adaptent le plus
rapidement, en améliorant la qualité et la rapidité de leurs services ainsi que l'adéquation de
leurs produits aux besoins des clients. Par conséquent, l'environnement des entreprises ainsi
que les processus métiers qui décrivent leur comportement sont dynamiques par nature. Par
dynamique, on signifie ici qu'un processus est perpétuellement sujet à des modifications car

73
 Chapitre 3 : Workflow et Systèmes Workflows avancés

soumis à l'influence de facteurs externes ou internes, remettant en cause sa structure et sa

validité. Un processus est donc une entité qui évolue, se modifie et s'adapte. C'est d'ailleurs
l'essence même de l'existence des méthodes telles que le BPR et le CPI, basées sur le fait
qu'un processus est constamment à améliorer. Il est donc intéressant de se pencher sur
l'ensemble des facteurs qui poussent à la modification et l'adaptation des processus. [SHETH
97] et [HAN et al. 98] en distinguent cinq sources principales, que nous classons selon une
granularité croissante du niveau d'adaptation :

1. Les évolutions technologiques : ces évolutions, tant au niveau matériel que logiciel,
apportent des améliorations significatives et des solutions nouvelles, dont doivent tirer
profit les entreprises, ou rendent obsolètes leurs équipements, qui doivent être mis à jour.
Cette opération nécessite d'adapter les processus existants et de construire de nouvelles
interfaces, utilisateurs et matériels.

2. Les événements externes et internes : certains événements dont l'occurrence perturbe le

bon fonctionnement des processus, nécessitent une réaction et une prise en charge
efficace. Leurs origines sont diverses - interne ou externe à l'entreprise - et ils nécessitent
des adaptations plus ou moins profondes et durables des processus. Les événements
internes sont principalement dus à des problèmes techniques : pannes, incidents,
traitements erronés, etc. Les événements externes quant à eux, peuvent par exemple
correspondre à des problèmes de livraison de la part de fournisseurs ou à des
changements de législations etc. Dans le premier cas, le processus doit être adapté pour
faire face à la situation (trouver un autre fournisseur), mais l'adaptation du processus n'est
que temporaire, c'est à dire qu'elle ne remet pas en cause la structure du processus pour
les autres situations où l'événement n'a pas eu lieu. Par contre, dans le cas d'un
changement de législation, c'est l'adéquation du processus avec le monde extérieur qui est
remise en cause et les adaptations apportées servent à définir une nouvelle version
corrigée du processus.

3. Les besoins des clients : les entreprises veillent constamment à satisfaire aux attentes du
marché, aux exigences des clients en termes de qualité, de prix et de fonctionnalités. Par
conséquent, l'évolution de ces contraintes a une incidence directe sur les processus
métiers des entreprises, qui doivent sans cesse être améliorés.

4. Les changements d'organisation et de mode du travail, qui s'expriment par l'application

de nouveaux modes de management et la restructuration des entreprises et des
organisations. C'est notamment une conséquence directe de la satisfaction des contraintes
de performance et de satisfaction des exigences du marché.

5. Les changements stratégiques des organisations, en termes d'orientations stratégiques, de

clientèle visée, de partenariats etc.. qui sont également une conséquence de l'optimisation
des processus et de la reconfiguration de l'organisation des entreprises.

A ces cinq principales sources de modifications des processus, il est possible d'en rajouter
d'autres, relevées par [OUKSEL et al. 98] :

6. L'incertitude de l'information : étant donnée la nature fluctuante et évolutive de

l'environnement des entreprises, les informations recueillies par les spécialistes lors de la
modélisation des processus sont souvent incertaines, contradictoires ou issues de sources

74
 Chapitre 3 : Workflow et Systèmes Workflows avancés

diverses. Ces spécialistes sont donc parfois obligés de synthétiser l'information ou de

faire des choix tactiques et des spéculations sur la qualité de l'information obtenue.

7. L'incomplétude de l'information : ce fait est complémentaire au précédent. En effet, il

arrive que l'information sur les exigences du marché soit non seulement incertaine mais
parfois incomplète. Par conséquent, il incombe aux concepteurs des processus de
compléter l'information en se basant sur des estimations et/ou leur expérience. Ces
estimations et les choix effectués peuvent souvent être la cause de modélisations
partiellement erronées nécessitant une correction des processus concernés.

8. Les conflits : les systèmes Workflows sont le plus souvent conçus sur l'idée qu'il existe un
certain consensus entre les utilisateurs des systèmes, régissant leur comportement et
éliminant les conflits qui pourraient se créer entre eux. Cela est cependant loin d'être le
cas et il arrive bien sûr que des conflits d'origines diverses (sociales, techniques ou
personnelles) freinent le bon déroulement des workflows. Il est par conséquent nécessaire
de pouvoir prendre en compte et traiter ces conflits lorsqu'ils surviennent.

Comme nous l'avons dit précédemment, les systèmes Workflow sont théoriquement les outils
de référence de la mise en œuvre de l'amélioration des processus, du support de leur
automatisation et plus globalement, de la flexibilité des entreprises. Or en examinant les
systèmes Workflow positionnés sur le marché avant la fin des années 90 – ceux que l'on
pourrait qualifier de "première génération" - on constate qu'ils ne supportent en réalité qu'une
partie des exigences : celle qui concerne la gestion et l'exécution des processus modélisés.

Côté adaptabilité, flexibilité et support des modifications, les mécanismes sont assez
rudimentaires [EDMOND et al. 98]. La raison de cette carence est autant due aux bases
technologiques que méthodologiques du Workflow. En effet, les systèmes Workflows sont
construits sur des bases technologiques qui en font des produits finis, orientés vers la prise en
charge de scénarios prédéfinis ne leur permettant pas de prendre en compte les changements
[OUKSEL et al. 98]. De plus, les systèmes Workflows et plus particulièrement ceux dits
orientés processus et documents, utilisent une modélisation précise et bien structurée des
processus à exécuter. Or ce type de modélisation est justement une arme à double tranchant.
En effet, la modélisation bien structurée permet de déterminer, de définir et décrire l'ensemble
des éléments intervenants dans un workflow. L'avantage est donc bien évidemment de
pouvoir assurer un environnement d'exécution théoriquement stable et fiable, un suivi
rigoureux ainsi qu'une bonne coordination des acteurs, grâce à la modélisation précise du flux
des activités. C'est d'ailleurs sur ces aspects là que les systèmes Workflows ont démontré leurs
capacités et leur intérêt. D'un autre côté cependant, la situation est moins optimiste. En effet,
il est évident qu'il n'est pas possible de prendre en compte dans un modèle Workflow,
l'ensemble des éventualités pouvant se présenter. Cela n'est d'ailleurs pas souhaitable à la
limite, pour des raisons de clarté et de lisibilité du modèle [HORN et al. 98], [REICHERT et
al. 98] ainsi que de temps du déploiement de l'application Workflow [DEITERS et al. 98].

Un modèle workflow ne représente donc en général que les situations les plus plausibles et ne
peut prendre en compte toutes les alternatives ou les situations exceptionnelles. Par ailleurs,
certaines parties du modèle ne peuvent être connues en détail que lors de l'exécution – pour
des raisons déjà citées d'incertitude et d'incomplétude de l'information. Par conséquent, les
modèles workflows risquent parfois de ne plus correspondre à la réalité ou de ne pas pouvoir
absorber les événements imprévus qui ont lieu.

75
 Chapitre 3 : Workflow et Systèmes Workflows avancés

L'un des principaux problèmes des systèmes Workflow est donc, comme nous allons le voir
plus en détail, celui de la flexibilité : les modèles, aussi bien que les systèmes, ne sont pas
suffisamment flexibles, ni pour permettre de réagir aux perturbations, ni pour permettre aux
modèles d'évoluer. Il s'agit toutefois de rester objectif. En effet, selon [SHETH 97], les
systèmes Workflows actuels permettent de prendre en charge 70 à 80% des processus pour
lesquels ils sont utilisés – chiffre qu'il faut malgré tout prendre avec précaution. Néanmoins, il
est vrai que pour des entreprises dont l'environnement est plus ou moins stable,
l'automatisation des processus reste la priorité alors que la flexibilité est secondaire. C'est
notamment le cas des organisations qui utilisent des systèmes Workflows dits administratifs.
De plus, dans un bon nombre de cas, une modélisation bien étudiée, basée sur des
formalismes puissants, permet souvent d'éviter les modifications fréquentes ou trop
importantes.

La flexibilité n'en reste pas moins une caractéristique essentielle à retrouver dans les systèmes
Workflow de la "nouvelle génération" ou des systèmes Workflows "avancés" [HORN et al.
98], [BOLCER et al. 96]. Les paragraphes suivants s'attachent à mieux définir ce qu'est la
flexibilité par rapport au Workflow, quels sont les besoins à satisfaire par ces systèmes et que
sont les systèmes Workflows avancés.

1.2 Workflow et flexibilité

Physiquement parlant, la flexibilité est une propriété permettant à l'entité qui la présente de
résister à des forces et des contraintes sans se briser, se rompre ou se déformer définitivement.
Au sens figuré, le dictionnaire francophone en ligne [HACHETTE 99] nous apprend que la
flexibilité est une caractéristique qui permet à son détenteur "de s'adapter aisément aux
circonstances". En productique, un système flexible (d'usinage) possède la capacité de traiter
différents types de produits, de s'adapter à des changements de la production et fait preuve
d'une certaine tolérance aux fautes [FROMENT et al. 89]. Globalement, la flexibilité d'un
système peut être définie par deux propriétés : celle de s'adapter à des situations ou des
configurations nouvelles, et la capacité d'absorber les fautes ou les problèmes. Les domaines
des bases de données et de la gestion de production sont de ceux ou la recherche de la
flexibilité est très développée.

Comme nous l'avons vu, le Workflow ne recouvre pas un mais plusieurs domaines et aspects,
qui sont les processus, les données et l'organisation. Par conséquent, les contraintes de
flexibilité du Workflow ne s'appliquent pas à un seul domaine mais à la combinaison des
trois. Il s'agit donc d'une part d'absorber tous les événements pouvant inquiéter la cohérence et
l'intégrité des données mais également de conserver la cohérence du déroulement du
processus en toute circonstance, ainsi que d'intégrer les modifications qui peuvent avoir lieu
dans l'organisation de l'entreprise. Dans la pratique, on constate cependant que la flexibilité du
Workflow se reflète principalement au niveau des processus, bien qu'elle implique et s'appuie
également sur les deux autres niveaux – données et organisation.

[WESKE et al. 96] définissent la flexibilité du Workflow comme étant la capacité de pouvoir
changer la définition d'un workflow en cours d'exécution ainsi que celle de réutiliser les
modèles pour la conception d'autres workflows. Plus globalement, nous pouvons dire que la
flexibilité du Workflow se définit par, et s'applique à deux niveaux complémentaires :

1. La flexibilité du modèle Workflow,

2. La flexibilité du système Workflow.

76
 Chapitre 3 : Workflow et Systèmes Workflows avancés

1. La flexibilité du modèle Workflow est une condition nécessaire de réalisation de la

flexibilité. Un modèle Workflow flexible est basé sur une méthode dont les concepts et
les formalismes intègrent des notions de flexibilité, proposent des mécanismes flexibles
ou permettent de construire de tels mécanismes. Si la méthode sur laquelle est basé le
modèle ne présente pas ces propriétés mais que le modèle le fait, alors le modèle peut être
flexible. Globalement, un modèle Workflow est dit flexible s'il présente les propriétés
principales suivantes :

§ Il est évolutif, c'est à dire que lui ou les entités qui le composent peuvent être modifiés,
sans remettre en cause l'intégralité et la cohérence globale du modèle. En particulier
nous nous intéressons à une faculté primordiale : l'adaptabilité des modèles. Bien que
nous revenions plus longuement sur l'adaptabilité dans la suite de ce chapitre, il est
intéressant de donner ici quelques définitions. L'adaptabilité d'un modèle est sa
capacité à intégrer des situations nouvelles. Cette intégration (qui peut aboutir à une
restructuration du modèle) peut être faite par le modèle lui-même, qui est qualifié dans
ce cas "d'auto-adaptable" ou "d'adaptatif". Si l'adaptation est possible mais qu'elle est
réalisée par l'intermédiaire d'une intervention extérieure, on dit que le modèle est
"adaptable".

§ Il permet de représenter ou de prendre en compte les exceptions. Globalement, une

exception traduit l'occurrence d'un événement qui ne correspond pas au déroulement
normal d'un processus. Tout comme l'adaptabilité, la notion d'exception est très
importante en Workflow, nous lui consacrons donc également une partie de ce
chapitre.

§ Il est réutilisable, c'est à dire que l'on peut s'en servir comme base pour la construction
d'autres modèles ou que l'on peut réutiliser certains de ses composants.

§ Le modèle propose des entités de haut niveau d'abstraction ou des entités

suffisamment génériques pour pouvoir être adaptées en fonction des besoins.

§ Le modèle doit éventuellement pouvoir s'intégrer avec d'autres modèles.

2. La flexibilité du système Workflow est le second aspect du concept de flexibilité du

Workflow. Globalement, un système Workflow flexible propose des mécanismes
permettant de détecter des situations erronées et d'y faire face – par exemple détecter et
gérer des exceptions – et donne les moyens logiciels de modifier le modèle sous jacent.
Pour être vraiment flexible, un système Workflow doit fournir des mécanismes pouvant
être mis en œuvre en cours d'exécution des workflows, c'est à dire sans avoir à
interrompre ceux qui sont en train de s'exécuter. Enfin un système Workflow flexible doit
pouvoir éventuellement collaborer avec d'autres systèmes Workflows, c'est à dire
partager des définitions de modèles et absorber les erreurs des systèmes avec lesquels il
collabore.

La flexibilité est donc l'une des principales caractéristiques de la "nouvelle génération" de

systèmes Workflow. Si ceux-ci doivent réunir l'ensemble des propriétés que nous avons
énoncées ci-dessus (mise en œuvre de la flexibilité), ils doivent également satisfaire un
ensemble de besoins importants qui se traduisent par de nouvelles fonctionnalités dont nous
dressons une liste dans le paragraphe suivant.

77
 Chapitre 3 : Workflow et Systèmes Workflows avancés

1.3 Fonctionnalités des nouveaux systèmes Workflows – Workflows avancés

Comme nous l'avons vu dans précédemment, l'un des principaux défauts des systèmes
Workflows est leur manque de flexibilité. Par conséquent, une grande partie des efforts de la
recherche dans le domaine du Workflow se concentre sur cet aspect. D'autres thèmes
essentiels font également l'objet de recherches importantes. Nous citerons notamment le
problème de l'interopérabilité des systèmes Workflows hétérogènes et distants, ainsi que le
problème de la modélisation de l'organisation de l'entreprise. La réunion de ces trois grandes
catégories de problèmes définit les besoins à satisfaire par la nouvelle génération de système
Workflow et les fonctionnalités qu'ils doivent présenter. Pour qualifier ces systèmes, on
retrouve souvent le terme de "Technologies de gestion de Workflow avancé" ("Advanced
Workflow Management Technologies") ou plus simplement "Workflow avancé" ("Advanced
Workflow").

Pour [BOLCER et al. 96], le Workflow avancé est un amalgame regroupant les connaissances
et le savoir-faire de plusieurs disciplines, telles le groupware, les systèmes de gestion de
l'information, la gestion de processus, la gestion de projet et bien entendu, le Workflow
"traditionnel". Plus exactement, le Workflow avancé propose d'apporter des solutions et des
améliorations aux principales faiblesses des systèmes Workflow traditionnels. Remarquons
que le concept de Workflow avancé n'est pas une remise en question des acquis – une sorte de
BPR du Workflow – mais naît de la conclusion que le Workflow n'a pas atteint tous les
objectifs fixés au départ et qu'il est possible pour y arriver, de tirer profit des technologies et
disciplines connexes. Ce fait est également souligné par d'autres chercheurs dont A. Shet
[SHETH 97] qui déplore que toutes les avancées technologiques dans les diverses disciplines
de l'informatique (gestion de l'information, gestion des transactions, gestion de la coopération,
applications d'intégration des systèmes hétérogènes et distants, etc..) n'aient pas été réunies et
exploitées autour d'un même objectif - l'amélioration des performances des systèmes
Workflows. Pour A. Sheth, ceux-ci devraient évoluer vers un nouveau type qu'il nomme
"systèmes de collaboration et coordination du travail" ("Work coordination and collaboration
systems – WCCSs"). Plusieurs travaux ont défini les principales fonctionnalités et
caractéristiques que devraient présenter ces systèmes – dont celles des systèmes Workflows
avancés. Nous en proposons une synthèse dans ce qui suit, en ne retenant que les
fonctionnalités les plus importantes :

1. Support des processus dynamiques, c'est à dire permettre de gérer et d'exécuter deux
types de processus : ceux qui sont peu structurés et ceux à la structure instable, donc
pouvant changer sous l'influence d'événements remettant en cause leur adéquation. Le
support des processus dynamiques recouvre plusieurs aspects :

§ La modélisation "ad hoc" des processus, c'est à dire la modélisation en cours

d'exécution des activités et des ressources du processus. On distingue deux cas de
modélisation ad hoc [WAINER et al. 95]. Dans le premier cas, il s'agit surtout de
déterminer le routage des activités en cours d'exécution, ainsi que la définition des
activités elles-mêmes. Cette fonctionnalité se retrouve déjà dans les systèmes
Workflows dits ad hoc. Ce routage en "temps réel" peut être utilisée de deux façons
Soit en tirant profit des capacités de systèmes ad hoc, donc en les intégrants à des
systèmes Workflows plus conventionnels où ils peuvent être utilisés en tant
qu'auxiliaires lors de la prise en charge d'événements imprévus. On parle alors de
systèmes Workflows composites dont un exemple d'application peut être la gestion des
exceptions. La deuxième façon de permettre le routage en temps réel est d'intégrer

78
 Chapitre 3 : Workflow et Systèmes Workflows avancés

directement cette possibilité au sein des systèmes Workflows, donc sans avoir recours
à des systèmes auxiliaires. Le deuxième cas de modélisation ad-hoc concerne la
"modélisation tardive" ("late modelling"), encore appelée "dynamic refinement". En
effet, il arrive qu'en phase de modélisation il ne soit pas possible de déterminer
explicitement une partie d'un processus. La partie manquante pourrait alors être
remplacée par une ou plusieurs entités génériques qui seront détaillées lors de
l'exécution.

§ L'autre aspect recouvert par le support des processus dynamique consiste en la

possibilité de modifier une partie d'un processus en cours d'exécution. Cette
modification se fait par exemple par le réordonnancement des activités d'un workflow
ou la suppression ou l'ajout d'une ou plusieurs de ses entités. La modification peut
également concerner la définition d'une des entités du workflow, comme la
modification de ses attributs ou de son comportement. La modification des processus
intervient généralement pour deux raisons : soit pour adapter le workflow aux
changements (qu'ils soient de l'environnement de l'entreprise ou issus de l'entreprise
elle-même); Soit pour corriger le processus dont l'exécution n'atteint pas les objectifs
et les performances fixées au préalable. Dans ce cas, la correction sert à mettre en
oeuvre une amélioration continue des processus. L'adaptation et la correction des
processus en cours d'exécution mettent en œuvre des mécanismes sophistiqués de
modélisation ad hoc.

2. Fournir un support robuste des transactions, en d'autres termes, assurer que les
transactions sont réalisées en intégralité ou être capable de faire face à tout problème
pouvant remettre en cause leur intégrité. C'est principalement le problème soulevé par la
gestion des exceptions sur lequel nous reviendrons plus en détail dans la suite de ce
chapitre.

3. Réutilisation des processus existants, c'est à dire la possibilité de reprendre une ou

plusieurs parties d'un modèle de processus ou de workflow et de la (les) réutiliser pour la
conception d'un autre modèle. La réutilisation des processus implique également de
pouvoir modifier – hors exécution – la définition des processus

4. Mise en œuvre de la collaboration. Il s'agit de fournir des moyens de coopération ayant

un niveau de synchronisation plus important que ceux proposés par les systèmes
Workflows orientés processus. La mise en œuvre de la collaboration Homme – Homme
est envisagée dans plusieurs situations, notamment dans les cas de processus incomplets
ou lorsque la décision ne peut être prise que par un acteur humain. Ici encore il est
possible d'intégrer les fonctionnalités des systèmes Workflow ad-hoc, voir des
collecticiels.

5. Support des utilisateurs déconnectés. Avec l'explosion des techniques du Web et de

l'Internet, les entreprises ouvrent de plus en plus leurs systèmes d'informations vers un
accès externe sécurisé (extranet, intranet). Le premier intérêt de cette ouverture est de
permettre une meilleure coopération entre l'entreprise et ses partenaires, et de faciliter
l'échange des informations entre eux. Les systèmes Workflows ne supportent en général
que les utilisateurs connectés grâce à une application cliente fournie avec le système.
L'utilisation de client Web permet dès aujourd'hui à des utilisateurs d'accéder aux
workflows dans lesquels ils sont impliqués, sans être connectés au réseau de l'entreprise
via un client Workflow. Un client Web est en général une page Web sécurisée, accessible

79
 Chapitre 3 : Workflow et Systèmes Workflows avancés

depuis n'importe quel navigateur Web. Cette page sert d'intermédiaire entre le système
Workflow et l'utilisateur. Elle présente en général les mêmes fonctionnalités que
l'application utilisateur cliente du système. L'accès aux systèmes informatiques via le
Web est un des facteurs principaux de la flexibilité du Workflow puisqu'elle permet aux
utilisateurs – Humains – de s'impliquer dans un workflow sans contraintes
technologiques dues au système sous-jacent. Cette fonctionnalité est d'ailleurs une des
premières à avoir été mise en œuvre par les vendeurs de systèmes Workflow.

6. Intégration des environnements de conception et d'exécution, principalement pour

permettre l'amélioration des modèles workflows grâce à un feed-back issu de la phase
d'exécution. Il s'agit d'intégrer des outils d'analyse des performances des processus
modélisés permettant de faire remonter le résultat de l'évaluation des processus vers la
phase de conception. Ce feed-back permet d'apporter des améliorations progressives mais
celles-ci devraient à terme se faire en cours d'exécution suite à des évaluations "locales"
signalant des réductions de performances ou des situations à problème. Cette situation
nécessite alors de rendre moins nette la frontière entre les phases de conception et
d'exécution, puisqu'elle nécessite en fait une reconception progressive et continue de
parties de processus. On constate également que cette fonctionnalité requiert également
celle permettant le support des processus dynamiques.

7. Interopérabilité des systèmes Workflows : L'interopérabilité des systèmes Workflows

hétérogènes et/ou distants est, nous l'avons dit, un des principaux axes de la recherche
dans ce domaine. En effet, certaines entreprises mettent en œuvre des processus à grande
échelle, dont l'exécution se répartit sur un large domaine géographique ("large scale
processes)" [GEORGAKOPOULOS et al. 95]. D'autre part, certaines entreprises
impliquent aussi la participation de partenaires ou de sous-traitants dans la réalisation de
certaines phases de leurs processus. Dans ce cas, le système Workflow doit être en
mesure de communiquer et de coopérer avec les systèmes d'information des autres
entreprises et notamment leur(s) système(s) Workflow(s), si elles en sont équipées. Cette
communication permet de répartir l'exécution des processus sur plusieurs systèmes sans
problèmes d'incompatibilité et de translation, en tirant au mieux profit des capacités de
chacun des systèmes.

Les fonctionnalités présentées ci-dessus donnent une vue globale de ce que devraient être les
systèmes Workflow avancés, en fait ceux d'aujourd'hui. Dans les parties suivantes, nous
allons plus particulièrement nous concentrer sur les deux caractéristiques primordiales de la
flexibilité du Workflow : la gestion des exceptions (support robuste des transactions) et
l'adaptabilité (support des processus dynamiques).

80
 Chapitre 3 : Workflow et Systèmes Workflows avancés

2. Flexibilité du Workflow – Gestion des exceptions et adaptabilité

Les deux caractéristiques principales de la flexibilité du Workflow, tant au niveau modèle
qu'au niveau système sont définies par la gestion des exceptions et l'adaptabilité. Nous nous
attachons dans cette partie du chapitre à définir plus en détail ces deux concepts et à montrer
quelles sont les méthodes existantes pour leur mise en œuvre, dans le domaine de la recherche
et dans les systèmes du marché.

2.1 La gestion des exceptions

2.1.1 Définition d'une exception

Le terme d’exception est largement utilisé en informatique – en programmation notamment -

pour désigner un événement problématique dont l’occurrence empêche un programme ou une
fonction de continuer normalement [ECKEL 97]. Selon B. Meyer, une exception est un
événement anormal dont l'occurrence empêche une "routine" (un service, une fonction ou une
procédure) d'accomplir sa tâche telle qu'elle était initialement prévue [MEYER 92]. B. Meyer
introduit la notion de "contrat" - l'un des piliers du langage Eiffel - entre un client (l'appelant
d'une routine) et un fournisseur (la routine) [MEYER 92], [MEYER 95]. Globalement, un
contrat est défini par un ensemble de pré-conditions et de post-conditions (résultat prévu) qui
doivent être satisfaites respectivement lors de l'appel de la routine et en sortie de cette
dernière. La "rupture" du contrat, c'est à dire la non satisfaction des conditions, ou
l'occurrence d'un événement empêchant la réalisation de la routine entraînent la levée d'une
exception.

Ces définitions sont adaptées et généralisées dans le domaine du Workflow où une exception
peut être définie comme étant une déviation du comportement du système par rapport à son
comportement normal [CASATI 98] ou encore, comme un besoin apparu dans un cas
Workflow (l’instance d’un workflow) et qui ne peut être satisfait à partir du modèle initial
duquel le cas est instancié [DEITERS et al. 98]. Plusieurs définitions complémentaires d’une
exception coexistent dans la littérature Workflow mais on considère globalement qu’une
exception est un événement à faible probabilité d’occurrence, ayant un effet perturbateur
empêchant le déroulement d’un processus tel qu’il a été défini au préalable.

La gestion des exceptions Workflows correspond globalement à un ensemble de mécanismes

réactifs et proactifs, permettant de répondre de façon appropriée aux exceptions et offrant
plusieurs fonctionnalités. Dans le cas réactif, le plus répandu, la gestion d'exception consiste
d'abord en la détection d'une exception par le système Workflow puis par sa prise en charge
selon un ensemble de règles et/ou de mécanismes prédéfinis au préalable (dans le modèle). La
réaction et la réactivité du système face aux exceptions, dépendent d'une part du modèle
Workflow sous-jacent et d'autre part du système lui-même (niveaux modèle et système de la
flexibilité). La réaction est définie par le comportement adopté - la procédure déclenchée - en
réponse à une perturbation - une exception. La réactivité quant à elle se définit par l'aptitude à
détecter et à réagir à une perturbation. Notons enfin que la détection d'une exception peut être
faite par un utilisateur et non par le système. Dans ce cas, plusieurs possibilités de réaction,
sur lesquelles nous reviendrons, sont envisageables.

Dans le cas proactif, deux comportements sont possibles. Dans le premier, le système évalue
le déroulement du processus et lance une procédure de gestion d'exception s'il prévoit un
comportement anormal. En fait, il n'est pas tout à fait exact de parler de proactivité dans ce

81
 Chapitre 3 : Workflow et Systèmes Workflows avancés

cas, puisque par définition, un système proactif anticipe les problèmes et permet de redéfinir
le processus "normal" en fonction. Dans le cas d'une exception, le processus résultant n'est pas
un processus normal mais un processus de prise en charge d'exception. Le deuxième
comportement proactif possible consiste à détecter la possibilité d'un dysfonctionnement, puis
à redéfinir la suite du processus en fonction de cet événement. Cela nécessite cependant le
support des processus dynamiques et reste assez coûteux en temps. Cette méthode est donc
très rare dans les systèmes Workflows existants.

2.1.2 Classification des exceptions

Afin de faciliter la prise en charge des exceptions, il est intéressant d'en établir une
classification. Une des premières contributions sur la classification des exceptions en
Workflow a été proposée par [EDER et al. 95]. Elle répartit les exceptions en quatre
catégories se recouvrant partiellement. La raison de ce recouvrement provient du fait que les
classes se basent sur des critères différents : l'origine de l'exception pour les deux premières
classes, alors que les deux dernières se fondent sur sa prédictibilité. Nous proposons donc de
les décrire en premier lieu, puis de proposer ensuite une autre classification plus cohérente.

[Link] Une première classification

La classification proposée par Eder et Liebhart distingue les quatre niveaux suivants :

1. les échecs de base ("basic failures")

2. les échecs d'applications ("applications failures")
3. les exceptions prévues ("expected exceptions")
4. les exceptions imprévues ("unexpected exceptions")

1. Les échecs de base correspondent à des pannes, des erreurs ou des dysfonctionnements du
matériel ou des systèmes informatiques sous-jacents au Système Workflow. La catégorie
des systèmes informatiques englobe en particulier le système d'exploitation ou le SGBD
qui gère les instances des workflows. Dans la catégorie du matériel informatique, on
retrouve principalement les réseaux et tout le matériel utilisé par les machines sur
lesquelles tourne le système Workflow. Par conséquent, il est possible de répartir les
exceptions de base en deux sous-catégories, les exceptions systèmes et les exceptions
matérielles. Un échec de base doit en principe être pris en charge par le système ou le
matériel sous-jacent. Par exemple les SGBD fournissent plusieurs fonctionnalités leur
permettant de faire face à des problèmes de sécurité ou d'interruption des transactions. En
général, un échec de base n'est donc pas explicitement pris en compte dans le workflow,
sauf dans le cas où il pourrait empêcher la réalisation d'une de ses activités.

2. Les échecs d’applications correspondent aux exceptions provenant des applications

interrogées par le Système Workflow, utilisées par les activités du workflow ou participant
à leur réalisation. Ces exceptions sont directement liées au workflow en cours, par suite
leur occurrence implique la non réalisation de l’activité utilisant l’application et représente
alors un risque d'échec du workflow. Il est donc nécessaire de prévoir et de pouvoir
détecter ce type de problèmes au niveau du workflow. Notons bien qu'il ne s'agit pas
d'applications utilisant le workflow (comme dans le cas d'un moteur Workflow intégré
dans une suite logicielle) mais d'applications utilisées par le système Workflow en tant que
ressources. Par exemple, si une activité nécessite la rédaction d'un document, alors le
logiciel de traitement de texte invoqué par le système appartient à la catégorie

82
 Chapitre 3 : Workflow et Systèmes Workflows avancés

d'applications dont nous parlons. Un échec d'application correspond donc à un

dysfonctionnement ou à une panne de l'application interrogée, ce qui peut remettre en
cause le bon déroulement du workflow. Cela comprend donc tout comportement non
conforme aux prévisions du modèle du processus sous-jacent. Par exemple, si une
application renvoie un résultat qui ne correspond pas à l'attente du workflow alors il est
possible de "lever" une exception.

3. Les exceptions prévues définissent l'ensemble de toutes les exceptions qu’il est possible de
prévoir ou qui sont identifiées pendant la phase de modélisation. Il est alors éventuellement
possible de leur associer un traitement approprié et d’éviter une interruption de la
réalisation du processus en cours. Les avis sont partagés quant à la représentation des
exceptions prévues et de leur traitement. Pour certains, les exceptions prévues et la
description de leur traitement, sont intégrés au modèle du processus. En d'autres termes, le
modèle doit représenter l'ensemble des exceptions prévues ainsi que les sous-processus de
prise en charge. Ceux-ci font donc partie intégrante de la description du flux des activités
dans le workflow. Pour d’autres spécialistes tel [PURDON et al. 95], la modélisation des
exceptions d’un processus fait l’objet d’une modélisation et d’une prise en charge à part,
quoique directement référencée par le modèle du processus.

Nous illustrons ces deux points de vue respectifs dans les figures III.1.a et III.1.b. Les
tâches qui y sont représentées font partie d'un processus de recyclage automatique de
composants de produits usagés. Un composant donné doit être extrait de chaque produit
soumis à l'automate chargé du démontage. Ce dernier est normalement équipé d'une
gamme d'outils lui permettant de traiter sans problème ce type de produit. Or il se peut que
sur l'un des appareils démontés, un changement de pièce - effectué par exemple lors d'une
réparation - fait que l'outillage de l'automate n'est plus adapté et l'extraction impossible : il
s'agit donc d'une exception. La figure III.1 représente la modélisation du processus de
gestion de l'exception à l'intérieur du processus initial, alors que dans la figure III.2, ce
processus n'est que référencé.
Composant Arrivée d’un produit
Arrivée d’un extrait Stocker
produit Extraire
composant exception : outils
non adaptés
Extraire Exception :
composant outils non adaptés
Composant
extrait Composant extrait
Extraction Annuler
manuelle Récupération
stocker
impossible
sans destruction

Figure III.1.a – Modélisation explicite Figure III.1.b – Modélisation implicite

d'exceptions d'exceptions

Pour F. CASATI [CASATI 98], les exceptions prévues sont des événements qui font
dévier la réalisation du processus vers des alternatives établies lors de la modélisation mais
qui ne correspondent pas aux chemins pris lors du déroulement "normal" du processus. Il
donne l'exemple d'un processus de réservation dans une agence de voyage, où l'annulation
de la réservation entraînant la fin du processus correspondrait pour lui à une exception
prévue. En effet, dans le déroulement normal, le processus doit se terminer par la livraison
des réservations, billets, etc.

On peut cependant se demander si un événement tel "réservation annulée" correspond

vraiment à une exception ou si ce n’est finalement pas un des événements qui créent la

83
 Chapitre 3 : Workflow et Systèmes Workflows avancés

dynamique du workflow. En effet, il n'y a rien d'exceptionnel au fait d'annuler une

réservation. En fait, on s'aperçoit en général qu'il n’y a pas vraiment de règles ni de critères
qui indiquent si un fait est plutôt un événement ou une exception. Pour [DEITERS et al.
98] la distinction se fait surtout par rapport à la perception de l’utilisateur et/ou du
concepteur. Nous estimons pour notre part, contrairement à F. Casati, que les exceptions
doivent rester à l'état d'événements "non conventionnels" de faible occurrence.

Il est toutefois possible de répartir les exceptions prévues en deux sous-catégories

§ Les exceptions qui correspondent à des événements parfaitement connus et

indexés pendant la modélisation.

§ Les exceptions qu’on ne peut associer qu’à un type générique d’événements car
elles ne peuvent être complètement définies avant d’avoir eu lieu. Par exemple le
type d’événements "erreur système" est générique, tandis que l’événement
"programme ne répond pas" en est une instance spécifique.

4. Les exceptions imprévues sont des événements qui ne font pas partie ou ne sont pas
initialement associés au modèle d’un processus car ils n'apparaissent qu’en cours
d’exécution. Selon F. Casati, ils correspondent à des inconsistances entre le processus
opérationnel et le monde réel. Dans un modèle de workflow, une exception peut être
imprévue pour plusieurs raisons :

§ La cause la plus probable reste la grande difficulté de pouvoir prendre en compte et

surtout de représenter dès le départ toutes les situations possibles.

§ La deuxième raison principale entraînant l'occurrence des exceptions imprévues est

également due au fait que leur existence n'était pas connue avant qu’elles n'aient lieu.
On dit dans ce cas qu'elles sont "inconnues" ou "non identifiées". Leur origine provient
en général de changements issus de l’environnement de l’entreprise (et non de
l’entreprise elle-même). Par exemple, un changement de législation imprévu ou une
nouvelle taxe peuvent provoquer certaines perturbations dans le déroulement d'un
processus.

§ Une très faible probabilité d’apparition.

§ Une négligence ou une mauvaise analyse du processus.

Il est intéressant d'apporter ici une nuance entre une exception imprévue et une exception
non identifiée au préalable (ou inconnue). Une exception est imprévue par rapport au
modèle du workflow dans lequel elle n'est pas prise en compte. Cela ne l'empêche pas
d'être éventuellement connue des concepteurs du workflows qui auraient jugé non
nécessaire de la reporter sur le modèle. A l'opposé, une exception non identifiée au
préalable est un fait dont l'existence était inconnue des concepteurs avant son occurrence.
Par exemple, lors du processus de fabrication d'un médicament, ce dernier peut avoir un
effet secondaire insoupçonné avant sa déclaration sur un "cobaye", ce qui peut remettre en
cause l'avancée du processus. La nuance entre exception inconnue et exception imprévue
entre en compte dans le déclenchement des procédures de prise en charge "manuelle",
comme nous aurons l'occasion de le voir plus tard.

84
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Les problèmes posés par les exceptions imprévues sont bien évidemment plus délicats à traiter
que dans le cas où elles sont prévues. En effet, il n'est pas possible d'en connaître le moment
ni la localisation d'occurrence. Nous verrons dans la suite de ce chapitre quelles sont les
méthodes les plus courantes pour prendre en charge ce type d'exceptions. Enfin, notons que la
classification proposée ci-dessus est acceptée et reconnue par une grande partie des
spécialistes du Workflow. Bien sûr, elle reste à un niveau assez général et il est toujours
possible et même souhaitable, d'établir de nouvelles classifications, de les diversifier ou plus
simplement, de spécialiser les quatre classes d'exceptions précédentes.

[Link] Autre classification des exceptions

La classification proposée dans le paragraphe précédent est intéressante mais ne nous satisfait
pas pleinement, pour deux raisons principales :

§ La première, comme nous l'avons mentionné, est due au fait que les classes décrites se
recouvrent partiellement. Au lieu de distinguer quatre classes, il nous semble qu'il aurait
mieux valu avoir deux classifications différentes : l'une contenant les échecs de base et
d'applications, l'autre plus englobante, composée des exceptions prévues et imprévues.

§ La deuxième raison est que cette classification ne permet pas de créer des types (des
catégories) des gestionnaires suffisamment adaptés, car les classes ne sont pas assez
spécifiques.

Nous proposons donc une autre classification, basée sur une re-formulation de la classification
précédente, et dans laquelle nous distinguons quatre classes au niveau d'abstraction croissant :

1. Le niveau matériel : c'est le premier niveau d'abstraction, que nous avions déjà distingué
dans la classe des "échecs de bases". Il concerne les pannes dues au matériel utilisé par le
système Workflow ou par les systèmes avec lesquels il collabore ou encore ceux qu'il
utilise. Les types d'exceptions concernés par ce niveau vont du dysfonctionnement
physique d'un matériel (disque crashé, composant électronique grillé, etc.), au blocage
d'un réseau ou d'une ressource.

2. Le niveau système : les exceptions systèmes sont des exceptions logicielles, générées soit
par des exceptions du niveau matériel, soit par un dysfonctionnement interne des modules
du système en question. On distingue respectivement deux sous niveaux d'exceptions
systèmes : le "bas niveau", qui concerne essentiellement le système d'exploitation des
machines sur lequel tournent le système Workflow et les applications connexes. Le "haut
niveau" concerne les exceptions définies au niveau du fonctionnement du système
Workflow et des applications. Les exceptions systèmes sont normalement prises en charge
par les systèmes concernés.

3. Le niveau application correspond à la classe des échecs d'applications, définie dans la

classification précédente. Il concerne les exceptions systèmes qui ont une incidence
directe sur l'exécution du workflow. Par exemple, supposons qu'une activité du workflow
requiert l'accès à une base de données pour y lire des données nécessaires à sa réalisation.
Si l'opération de lecture ne peut se faire alors l'activité ne peut s'exécuter. Dans ce cas,
l'exception, qui est située au niveau de la base, affecte directement l'exécution du
workflow qui doit pouvoir la prendre en charge. Les exceptions du niveau application sont
donc gérées par le workflow.

85
 Chapitre 3 : Workflow et Systèmes Workflows avancés

4. Le niveau Workflow. Jusqu'à présent, les trois niveaux précédents correspondent à une re-
formulation de la classification proposée par Eder et Liebhart. Il est cependant possible de
leur ajouter un quatrième niveau, qui concerne les "exceptions Workflows" [CASATI 96],
encore appelées "exceptions sémantiques" [HAGEN et al. 98], car elles sont
sémantiquement liées à la définition du processus, c'est à dire qu'elles font partie du
contexte de l'affaire traitée et peuvent aboutir à l'échec du processus et/ou remettre en
cause le modèle établi. Nous distinguons deux sous-niveaux d'exceptions Workflow :

§ Le premier correspond aux "anomalies" : elles sont essentiellement dues à des

résultats incohérents, renvoyés par les applications utilisées par le système Workflow
ou renvoyés par les activités du processus. Par exemple, considérons un workflow de
commande par téléphone. Supposons qu'au début du processus, l'opérateur chargé de
saisir des informations sur le client ce soit trompé lors de la saisie de son adresse.
L'activité d'enregistrement de la commande, bien que correcte, ne permet pas la
réussite de l'activité de livraison en aval du processus. Cette dernière renverra
vraisemblablement l'exception "adresse erronée".

§ Le deuxième sous-niveau correspond au problème plus grave des "incohérences".

Dans ce cas, les exceptions Workflows ont pour cause l'inadéquation du modèle
processus à la réalité du problème qu'il traite, ou aux contraintes du monde réel.

Après ce tour d'horizon des classifications possibles des exceptions, nous allons à présent
nous intéresser aux moyens qui sont proposés et mis en œuvre dans le domaine Workflow
pour détecter et réagir aux exceptions.

2.1.3 Gestion et Traitement des exceptions

Le traitement des exceptions ou plus globalement des problèmes rencontrés en cours

d'exécution, n'est pas spécifique au Workflow. Beaucoup d'autres domaines de l'informatique
- et même d'autres disciplines - sont confrontés à la prise en charge des défaillances,
anomalies et autres problèmes. En particulier - pour ce qui se rapporte à l'informatique - le
Workflow s'inspire principalement des techniques issues des Bases de Données et de la
gestion des transactions, ainsi que de la programmation classique [GEORGAKOPOULOS et
al. 95].

La gestion des exceptions est en fait un terme générique regroupant deux phases principales
(en plus de la phase de déclaration de l'exception). La première phase consiste en la détection
des exceptions (le signalement) et le routage du processus vers des mécanismes de prise en
charge ou de traitement qui forment la deuxième phase. Celle-ci concerne le traitement des
exceptions proprement dit, c'est à dire l'application de méthodes permettant de résoudre le
problème lié à l'exception.

Nous apportons ici une distinction entre les mécanismes mis en œuvre lors de l'occurrence
d'une exception, et les méthodes de gestion d'exception. Globalement, on pourrait définir les
mécanismes comme étant des techniques permettant de traiter tout ou une partie des
problèmes engendrés par une exception. Les méthodes quant à elles définissent une approche
plus ou moins originale, composée de règles structurant l'utilisation d'un ensemble de
mécanismes (fig. III.2). Ces règles peuvent être exprimées de diverses façons, en particulier
sous la forme d'algorithmes.

86
 Chapitre 3 : Workflow et Systèmes Workflows avancés

En plus des mécanismes, les méthodes de gestion d'exception prennent en compte un

ensemble de contraintes, telles par exemple l'état des processus ou des activités, leur
importance, etc. Les prochains paragraphes définissent plus amplement ce que sont les
mécanismes et les méthodes de traitement des exceptions Workflows.
Rollback 1

2 Méthode 1
Compensation

Contingence 3

Forward recovery

Annulation 2
Méthode 2

Nouvel Essai 1

...
Mécanismes Méthodes

Figure III.2 - Méthodes et mécanismes de traitement d'exceptions

[Link]. Détection et prise en charge des exceptions

S’il est primordial de traiter les exceptions, il n’en est pas moins important de pouvoir d'abord
les détecter. L’habileté du système à détecter une exception et/ou les moyens qu’il offre pour
les signaler reste une garantie du bon déroulement du processus. Dans le domaine du
Workflow, on distingue principalement deux modes et trois approches principales de
détection.

Modes de détection

§ La détection synchrone se fait en fonction d’un ou de plusieurs événements dont

l’occurrence a lieu en cours de réalisation d’une tâche. C'est une détection en temps
réel, qui donne lieu à une réaction, donc une prise en charge a l'effet "réparateur".

§ La détection asynchrone est réalisée grâce à l’évaluation des résultats des tâches et
l’application de prédicats sur les données internes du workflow : elle n'est donc pas
faite en temps réel. La détection synchrone est en général réactive mais il est
envisageable de l'utiliser d'une façon proactive, pour prévoir l'occurrence d'exceptions
et les éviter. Par exemple, supposons qu'on utilise un système Workflow pour gérer un
atelier de désassemblage. Chaque cellule de l'atelier est assignée à des tâches par le
workflow et doit rendre compte de son état d'avancement. Si grâce à ce retour
d'information le système détecte un ralentissement au niveau de certaines cellules, il
peut "prévoir" un problème dans l'atelier et décider a priori d'une modification des
paramètres du processus - par exemple augmenter la capacité des files d'attentes - et
éviter le problème. Dans la réalité, il est plus vraisemblable que la tâche d'analyse et de
prévision soit affectée à un module d'ordonnancement ou un système de gestion de
production auquel serait couplé le système Workflow. Ce dernier joue alors le rôle
d'interface entre le système d'analyse auquel il fait remonter un ensemble
d'informations issues de l'atelier.

87
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Méthodes de détection

1. La détection "manuelle"
2. Les gestionnaires d'exceptions
3. Les déclencheurs ou règles

1. La détection avec la prise en charge manuelle est la méthode de détection et de prise en

charge la plus "simple", puisqu'elle se base sur la faculté de l'utilisateur à détecter et
signaler l'occurrence d'une exception. Cette approche nécessite cependant la satisfaction
de plusieurs conditions. La première et la plus importante est que l'utilisateur doit avoir un
certain niveau de compétence lui permettant de détecter des anomalies, donc les
exceptions non prévues. Le problème étant en effet moins ardu pour les exceptions
prévues. Ces dernières correspondent toujours, nous l'avons vu, à des événements connus
par les participants au processus. Ces événements font partie de la sémantique du
workflow, bien que ne résultant pas de faits "normaux". De plus, nous avons dit que des
tâches alternatives sont en général associées à une exception prévue. Par conséquent dans
le cas manuel, pour détecter et traiter une exception prévue, il "suffit" que l'utilisateur soit
bien au courant de la procédure à suivre. Le problème est plus délicat pour les exceptions
non prévues puisqu'elles nécessitent des capacités d'analyse et de décision de la part des
utilisateurs, en plus de leurs connaissances de base des tâches qu'elles traitent. Enfin, une
autre condition à satisfaire est de fournir aux utilisateurs des moyens leur permettant de
signaler une exception et ce, quelque soit son type (prévue ou imprévue). En général cela
est rendu possible grâce à l'interface graphique qui lie l'utilisateur au système, à partir de
laquelle l'utilisateur peut propager un signal.

2. Le gestionnaire d'exceptions est une approche très intéressante et assez répandue, inspirée
des langages de programmation. Le principe de base est le même que pour les langages
traitants les exceptions, tels Eiffel, C++, Java, Smalltalk, Ada, etc. Chaque tâche d'un
workflow peut être associée à des exceptions prises en charge par un gestionnaire. Chaque
exception correspond en fait à un signal émis par la tâche - ou par son réalisateur - vers le
ou les gestionnaires appropriés (fig. III.3).

Plusieurs façons de mettre en œuvre l'approche de

Exception
gestionnaire d'exceptions sont possibles. Une première
approche est proposée par [PURDON et al. 95]. Elle
consiste à établir une arborescence des signaux - donc
des exceptions - en les classant par catégories. La racine Tâche Signal Gestionnaire
du sous-arbre représenté par une catégorie correspond au d’exception

signal le plus générique de cette dernière. Par exemple si

l'on crée une catégorie "exception système", alors on Figure III.3 - Gestionnaire
peut y placer les exceptions "mémoire insuffisante", d'exceptions
"lecture impossible sur le lecteur X", etc. Dans ce
cas, le signal le plus générique pourrait correspondre à
"exception système". Cette structuration se répète jusqu'à la racine de l'arbre, qui
correspond au signal de plus haut niveau de généricité. Afin de déterminer avec exactitude
quelle exception a été levée, on associe au signal un "contexte". Ce denier est un ensemble
d'informations comprenant l'état du processus et/ou de l'activité en cours, l'émetteur du
signal, etc. Pour éviter de surcharger le modèle sous-jacent, [PURDON et al. 95]
préconisent de ne pas représenter "explicitement" les branchements alternatifs de prise en
charge de l'exception. Pour ce faire, chaque signal ou ensemble de signaux est associé à un

88
 Chapitre 3 : Workflow et Systèmes Workflows avancés

gestionnaire, concrétisé par un workflow spécifique, stocké dans la base de données du

système Workflow (fig. III.4), ou par un workflow ad hoc. Dans ce dernier cas, la main est
passée à un système Workflow ad hoc et les utilisateurs poursuivent le processus d'une
façon non structurée - c'est à dire sans se baser sur un modèle de processus, jusqu'au
rétablissement de la situation. L'émetteur du signal est la personne affectée à la tâche
levant l'exception. La détection est donc "manuelle" mais la prise en charge automatique.
Workflow « normal »
Pointeur vers
worklow
Tâche gestionnaire
d ’exception

Branchement
non
exceptionnel
( contrôleur
de flux )

BD Workflow

Figure III.4 – Mise en œuvre de gestionnaire d'exceptions

L'approche proposée par [PURDON et al. 95] est très intéressante et constitue la base d'autres
méthodes fondées sur le même principe. Elle souffre toutefois de deux inconvénients :
§ En premier lieu, nous y avions fait illusion auparavant, le fait de passer la main d'un
workflow à un autre nécessite de bons mécanismes de synchronisation et de
communication entre les deux. Le problème est accentué si le workflow "exceptionnel" est
exécuté sur un autre système que celui où le workflow initial a lieu, en particulier si cet
autre système est ad hoc, donc non structuré. Il convient alors de définir des points de
rencontre entre les différents workflows.

§ Le deuxième problème qui est soulevé par les auteurs eux-mêmes est celui de l'aspect
statique de l'arborescence des signaux. En effet, tout changement dans la stratégie de
détection ou de prise en charge se répercute au niveau de la hiérarchie des signaux, de la
définition du processus et même parfois des applications clientes. De plus, la détection et
l'identification de nouvelles exceptions requiert l'insertion de nouvelles catégories ou de
nouveaux nœuds dans l'arbre. Il est par la suite nécessaire d'établir une mise à jour
continue de l'arborescence et des applications clientes qui y font référence. Ce problème
d'importance a suscité la recherche et la conception de différentes solutions. Nous y
revenons à la fin de ce paragraphe consacré aux méthodes de détection des exceptions.

D'autres approches fondées sur les gestionnaires d'exceptions existent. Nous nous intéressons
notamment à celle proposée dans le système OPERA [ALONSO et al. 97],[HAGEN et al. 98].
Le principe de base y est le même que dans le cas précédent : les exceptions sont levées par la
combinaison d'un signal et d'un contexte - celui de la tâche en cours. Néanmoins, plusieurs
améliorations sont apportées, d'une part dans le cadre de la détection des exceptions et d'autre
part dans celui de leur prise en charge.

OPERA fait une distinction entre les deux types de détection : synchrone et asynchrone. Dans
le cas de la détection synchrone, on associe à chaque tâche du workflow un "signal proxy" ou
"mandataire de signal", qui fait explicitement partie du contrôle de flux de workflow (fig.
II.4). Chaque mandataire est associé à un nom, une catégorie et à un gestionnaire d'exception,

89
 Chapitre 3 : Workflow et Systèmes Workflows avancés

fixé par le concepteur du workflow. Si aucun gestionnaire n'a été défini, un gestionnaire par
défaut est automatiquement associé à la tâche. La catégorie de l'exception quant à elle, permet
de restreindre le comportement du gestionnaire. Par exemple la catégorie "escape" signifie
que le gestionnaire doit arrêter l'exécution du processus en cours après le traitement de
l'exception. Le gestionnaire d'exceptions est activé par le mandataire si ce dernier est atteint
par le contrôle de flux. Dans la figure III.5 par exemple, le signal proxy "E_excep1" est atteint
si la condition X n'est pas vérifiée.
Activités
La prise en charge des exceptions dans le
système OPERA est récursive : si un If (X)
Act. 1 Act. 2
gestionnaire n'a pas été capable de traiter
l'exception qui lui est passée, il la fait If (!X)

"remonter" vers le gestionnaire du niveau Signal

E_excep1
proxy tâche normale
supérieur, (groupe d'activités, sous-processus, Escape

etc.), jusqu'à atteindre éventuellement le

Gestionnaire
gestionnaire le plus générique qui est associé Act. n Act. n+1 - sous processus -
au workflow dans sa globalité. En général, ce
gestionnaire est associé aux événements
"succès du workflow en cours" ou "échec du Figure III.5 - Gestion d'exception
workflow en cours". synchrone dans le système OPERA

OPERA traite également, nous l'avons dit, les exceptions asynchrones, c'est à dire celles qui
ne sont pas détectées en temps réel mais par application de règles et de prédicats sur les
données du workflow. Dans ce cas, OPERA propose une base de "déclencheurs" ("triggers"),
écrit sous la forme de règles Evènement(s) - Condition -Action (ECA). Une règle ECA permet
de déclencher une action en réaction à un ou plusieurs évènements, si la condition liée à
l'action est vérifiée. Les déclencheurs restent actifs pendant toute la durée du processus, c'est à
dire qu'ils sont constamment "informés" de l'évolution des données du workflow. Ainsi, il
n'est pas besoin d'associer de règle ECA à une tâche car toutes les tâches du workflow sont
automatiquement liées à l'ensemble de règles.

Enfin pour terminer la section concernant les gestionnaires d'exception, il convient de

mentionner l'approche originale du système OPERA qui propose un langage nommé OCR
(Opera Canonical Representation) qui permet de décrire le flux des tâches mais surtout qui
intègre la notion d'exception dans sa syntaxe et sa sémantique, à la façon des langages de
programmation.

3. L'approche par déclencheur ou règle constitue la troisième méthode de détection et de

prise en charge des exceptions, directement issue du monde des bases de données et plus
particulièrement des bases de données dites "actives". Un déclencheur est un mécanisme
qui réagit à l'occurrence d'un (ou de plusieurs) événement par l'exécution d'une fonction
(dans le sens de la programmation) ou d'un processus. Les déclencheurs sont en général
formalisés à l'aide de règles ECA et sont souvent appelés règles ou prédicats.

Les règles ECA sont très utilisées dans le domaine du Workflow, que ce soit pour le
contrôle de flux (description de la dynamique du processus) ou plus particulièrement pour
la gestion des exceptions. Dans ce dernier cas, trois possibilités se présentent.

§ La première consiste à associer directement une ou plusieurs règles à une activité

Workflow (fig. III.6). Lorsque l'activité (ou l'entité responsable de sa réalisation) émet

90
 Chapitre 3 : Workflow et Systèmes Workflows avancés

un événement, ce dernier est testé par les règles. S'il correspond à l'entrée de l'une
d'entre elles, la procédure de prise en charge de l'exception est activée.

§ La deuxième possibilité consiste a mettre un ensemble (ou paquet) de règles à la

disposition de l'ensemble des activités (fig. III.7), ainsi que nous l'avons décrit pour le
système OPERA. Chaque activité du workflow émet vers le pool des événements qui
sont absorbés ou ignorés par les règles.

§ Enfin la troisième méthode est mixte et consiste à mélanger des règles spécifiques
pour les exceptions prévues et l'ensemble de règles pour les exceptions imprévues.

Activité i Activité i+1

Activité i Activité i+1

événements événements

Déclencheur Déclencheur Ensemble de déclencheurs

Figure III.6 - Gestion d'exception à l'aide Figure III.7 - Gestion d'exceptions à l'aide
de déclencheurs associés aux activités de déclencheurs en pool

La gestion d'exception à base de déclencheurs se retrouve dans un nombre important de

systèmes et d'architectures Workflows, tels par exemple le système WIDE [BARESI et al.
97], [BARESI et al. 99], et l'architecture WAMO [EDER et al. 98]. La raison de cet
engouement s'explique par le fait que beaucoup de spécialistes Workflows sont issus du
monde des bases de données. Ils ont donc fait migrer leurs outils et leurs méthodes vers ce
nouveau type de systèmes qui sont parfois perçus comme une mutation des SGBD.
Certains spécialistes tels [EDER et al. 96] estiment même qu'ils est possible de construire
des workflows à l'aide de base de données actives.

Avant de s'occuper de la description des mécanismes de traitement des exceptions, il est

intéressant de revenir un instant sur le problème de l'évolution de l'arborescence des classes
d'exceptions, soulevé plus haut. Parmi les solutions existantes, nous en retenons plus
particulièrement trois, sur lesquelles il est intéressant de se pencher car elles sont typiques des
solutions à ce problème, que l'on peut retrouver dans la littérature.

La première solution, qui est aussi la plus intéressante, est proposée par le système WERDE et
se base sur le concept de "patterns" [CASATI et al. 98]. Un pattern se définit comme étant
une façon éprouvée, performante et générale de résoudre une catégorie particulière de
problèmes [ECKEL 99], une solution type à un problème récurrent [RIEHLE et al. 96]. Le
système WERDE est un éditeur de patterns de gestion d'exceptions Workflows. WERDE
permet de conserver dans une base, un catalogue (semblable à l'arbre des signaux cité plus
haut) de patterns d'exceptions classés en catégories. Ceux-ci peuvent ensuite être directement
réutilisés par les concepteurs de workflows auxquels WERDE offre également la possibilité
très intéressante de créer de nouvelles catégories ou de nouveaux patterns, grâce à la
réutilisation et la spécialisation des patterns existants. Cette approche permet d'enrichir le
catalogue des gestionnaires d'exceptions au fur et à mesure des besoins, en se préservant d'une
redondance inutile grâce à la classification.

91
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Une seconde solution, cousine éloignée de la précédente, est mise en œuvre dans le système
ADOME [CHIU et al. 98]. Elle est particulièrement adaptée aux exceptions imprévues qu'il
est difficile de classer ou pour lesquelles il n'existe pas de traitement spécifique. Dans le
système ADOME, toute exception imprévue ainsi que la description de la procédure ayant
permis de la traiter, sont enregistrées dans une base de données. Celle-ci peut être consultée
ultérieurement par tout utilisateur faisant face à un problème imprévu.

Enfin la troisième solution, mise en œuvre dans certains systèmes et architectures comme
ADOME et WAMO [EDER et al. 98] se caractérise par la possibilité d'introduire de
nouveaux gestionnaires en cours d'exécution, donc de façon ad hoc.

[Link] Mécanismes de traitement d'exceptions

Dans leur grande majorité, les mécanismes de traitement des exceptions dans le Workflow
sont directement calqués sur ceux utilisés en gestion de transactions et dans les Bases de
Données. Les paragraphes qui suivent donnent une vision globale des mécanismes les plus
couramment utilisés dans les systèmes Workflows. Avant de poursuivre, signalons que dans
cette partie, nous utilisons le mot tâche au sens large - c'est à dire activité ou sous-processus.

§ L'essai répétitif ou "retry" [EDER et al. 98] ou re-exécution [HAGEN et al. 98] : le
système tente d'exécuter la tâche jusqu'à ce qu'elle réussisse ou qu'un nombre critique
d'essais soit atteint. Cette approche est assez coûteuse en temps et n'est valable que dans
certains cas. Par exemple un appareil tentera d'envoyer un fax jusqu'à ce que le numéro du
correspondant soit disponible. L'essai répétitif peut également être utilisé après un autre
mécanisme, afin de relancer le processus.

§ Le retour arrière ("défaire") ou "roll back", consiste à annuler l'effet de l'activité ou

des activités précédentes jusqu'à atteindre un certain point de cohérence et de stabilité du
workflow. Cela nécessite donc d'une part de pouvoir annuler l'effet d'une activité et d'autre
part, de spécifier certains points de cohérence ou de garder un historique de l'exécution - à
l'image d'un journal d'un SGBD. Selon les méthodes, l'un ou l'autre des choix sera préféré.
Pour faciliter le choix du point de retour, le système OPERA [ALONSO et al. 97],
[HAGEN et al. 98] propose de se baser sur la propriété d'atomicité - du tout ou rien. Ainsi
dans le système OPERA, il est possible de définir des blocs logiques, auxquels on confère
la propriété d'atomicité. Un bloc peut contenir une ou plusieurs activités, voir des sous-
processus. Il n'est donc envisageable d'effectuer un roll back que sur un block
complètement atomique. [HAGEN et al. 98] définissent néanmoins plusieurs niveaux
d'atomicité, selon lesquels le roll back pourra être automatique ou semi-automatique.
Remarquons pour finir que le roll back ne peut être appliqué dans tous les cas. Par
exemple si un fax a été envoyé par erreur, on ne peut annuler son effet.

§ La compensation : dans les cas où le roll back seul est difficilement applicable, il est
possible d'envisager l'utilisation de tâches ou de processus de "compensation". La
compensation consiste à associer à une activité - ou à un processus selon la granularité -
une autre tâche ou un sous-processus qui permet de corriger l'effet occasionné par
l'exécution de la tâche en question. Dans l'architecture Workflow WAMO [EDER et al.
98], il est possible de définir des tâches de compensation en fonction de l'activité qui a
généré l'exception. Les concepteurs du modèle introduisent un certain nombre de
concepts, dont celui de "vitalité" et de "complexité". La vitalité d'une tâche (au sens large
du terme) correspond à son importance vis à vis du processus. Une tâche non vitale pourra

92
 Chapitre 3 : Workflow et Systèmes Workflows avancés

être annulée ou abandonnée en cas de problème ou d'exception, ce qui n'est pas le cas
d'une tâche vitale. Les tâches vitales sont associées à des mécanismes de gestion
d'exceptions, notamment le roll back, la compensation et la contingence. La notion de
complexité d'une tâche équivaut au fait qu'une tâche peut être composée de sous-tâche (il
s'agit donc d'un sous-processus). Dans ce cas, il est peut être nécessaire de propager les
mécanismes de traitement des exceptions vers les tâches composantes, selon la vitalité de
la tâche à traiter. Par exemple une tâche vitale sur laquelle on souhaite appliquer un roll
back devra annuler l'effet de toutes ses sous-tâches.

§ La contingence : elle consiste à proposer une ou plusieurs alternatives à une tâche vouée
à l'échec après avoir levé une exception. L'exécution du processus est redirigée vers une
ou plusieurs autres tâches de secours, dites de contingence. La contingence s'utilise en
général en association avec d'autres mécanismes tels que le roll back et la compensation.
Il est curieux de constater l'existence dans le Workflow, d'un mécanisme de contingence
proposant des choix alternatifs à une tâche, alors que la modélisation de chemins possibles
est critiquée comme étant source de confusion et de surcharge du modèle. En fait, la
distinction entre contingence et choix multiples réside surtout dans la mise en forme du
mécanisme au sein du modèle. En effet, s'il est évident que les tâches de contingence
peuvent être représentées sous la forme de routes alternatives - ce qui est d'ailleurs le cas
dans la plupart des systèmes Workflows - la bonne solution consiste à éviter une "sur-
modélisation", en créant des artifacts de modélisation, graphiques ou syntaxiques. C'est
notamment le cas du système OPERA précédemment cité, qui propose un langage de
modélisation - OCR - intégrant la notion d'exception.

§ La délégation : le mécanisme de délégation est mis en œuvre quand l'entité responsable

du traitement d'une tâche ayant levé une exception ne sait pas appliquer de décision quant
à la suite des événements. Elle délègue alors la responsabilité de la décision à une instance
plus compétente ou hiérarchiquement supérieure. La délégation est un mécanisme qui peut
être automatisé mais qui intervient souvent pour des tâches humaines. Il peut bien
évidemment être utilisé en combinaison avec d'autres techniques et être une alternative à
la contingence. Il est intéressant de remarquer que le fait de déléguer une tâche à une autre
entité fait "sortir" la tâche du processus auquel elle appartient et par suite, de la
responsabilité du système Workflow qui la traite. En effet, la prise en charge d'une tâche
déléguée peut se faire de façon "manuelle" ou à l'aide d'un autre système Workflow, par
exemple un système ad hoc. Le problème qui se pose ici est de pouvoir récupérer
l'ensemble du contexte de l'activité et des informations, créés à l'extérieur du système
initial. Cela pose d'une part des problèmes d'interfaçage entre les systèmes Workflows
utilisés et d'autre part, des problèmes de synchronisation. Ces problèmes peuvent en
partie être résolus dans le cas manuel, en intégrant des modules au système Workflow qui
sont appelées lors d'une délégation. Ces modules sont constamment en relation avec le
système et permettent à un utilisateur humain de traiter l'exception. Cette solution se
retrouve notamment dans le système ADOME cité précédemment, qui propose un
"gestionnaire d'intervention humaine" ("human intervantion handler").

§ L'annulation : l'annulation est un traitement "primaire" d'une exception qui consiste

simplement à annuler la tâche qui a levé l'exception. Cela nécessite bien entendu d'être
certain que la tâche en question n'est pas essentielle pour le processus. On peut le vérifier
par exemple grâce à un attribut de vitalité, tel qu'il est proposé dans l'architecture WAMO.
La vitalité d'une tâche indique au système que cette dernière est essentielle au bon

93
 Chapitre 3 : Workflow et Systèmes Workflows avancés

déroulement du processus. Par conséquent une tâche vitale ne peut être annulée, à moins
d'annuler l'ensemble du processus.

Remarquons que dans certains cas on apporte une distinction entre annulation et
abandon (abort) de la tâche. Quant cette distinction est proposée, on définit l'abandon
comme le fait de stopper une tâche au cours de son exécution, suite à une exception et
après avoir essayé d'autres mécanismes de traitement ou de récupération. L'abandon d'une
tâche implique la notion de vitalité et nécessite souvent de mettre en œuvre par la suite,
des mécanismes de compensation et/ou de contingence. La distinction entre annulation et
abandon peut également être importante lors de l'analyse de l'état des activités.

§ La relaxation : ce mécanisme s'inspire des problèmes de résolutions de contraintes en

intelligence artificielle. La relaxation équivaut à alléger les contraintes qui existent sur une
tâche donnée afin de permettre sa réalisation [CHIU et al. 98]. Par exemple considérons
une tâche de réservation d'une place dans un train. Une contrainte à respecter pourrait être
que la réservation doit se faire en deuxième classe. Si aucune place n'y est disponible,
alors on peut admettre une réservation en première classe. On relaxe donc la première
contrainte. La relaxation peut se faire de manière automatique ou manuelle
(éventuellement par délégation) lors de la réalisation d'une tâche, à l'aide par exemple
d'une liste de contraintes, classées dans un ordre d'importance, qu'il est possible de
relaxer.

§ "Berner" le système : c'est une solution parfois valable, souvent utilisée dans la réalité,
qui correspond au fait de faire "comme si" l'exception n'avait pas eu lieu. Par exemple,
considérons le processus de gestion de commandes clients. La livraison ne peut se faire
qu'à la condition explicite que le paiement soit bien arrivé. Or, il se peut
qu'exceptionnellement, pour des raisons diverses, on admette de livrer le colis sans
règlement préalable. Dans ce cas on peut envisager d'inventer un règlement fictif qui sera
utilisé pour permettre au système de poursuivre le processus. Bien entendu, cette solution
ne peut être mise en œuvre que pour certaines exceptions "sémantiques" (donc hors
pannes, erreurs, échecs systèmes et autres) et sous certaines conditions, par exemple que
la tâche soit traitée par une personne, qu'on ait la possibilité de corriger les données
fictives ultérieurement etc.

§ Adapter le workflow en cours d'exécution : malgré son importance, nous avons

volontairement gardé ce mécanisme pour la fin, pour la simple raison qu'il constitue une
transition entre la gestion d'exception et la partie de ce chapitre consacrée à l'adaptabilité.
Adapter le workflow en cours d'exécution signifie que l'on y apporte certaines
modifications ou quelques ajouts, sans stopper le système et les processus en cours. Selon
l'importance de l'exception, la localisation des modifications se fera à différents niveaux
du workflow. Dans certains cas - par exemple pour une gestion d'exceptions à base de
règles, il suffira d'introduire de nouvelles règles à l'ensemble de règles du workflow pour
résoudre le problème. C'est notamment le cas du système ADOME et de l'architecture
WAMO. Dans d'autres cas plus "graves", il est nécessaire de revoir le modèle de
processus sous-jacent. D'autres mécanismes plus complexes sont alors à mettre en œuvre.
Leur description détaillée et l'importance de cet aspect de la flexibilité Workflow justifient
que nous leur consacrions une partie de ce chapitre. Il est cependant d'ores et déjà possible
de remarquer que l'adaptation nécessite une grande "malléabilité" du système et du
modèle de processus sous-jacent.

94
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Pour en terminer avec la gestion d'exceptions, il reste à rappeler que les mécanismes décrits
ci-dessus sont ceux qui sont principalement utilisés dans les méthodes de traitement des
exceptions. Toutefois, bien qu'ils aient pour la plupart été éprouvés dans d'autres systèmes
d'informations, leur utilisation au sein de systèmes Workflow nécessite certaines évolutions.
En effet dans un workflow, les transactions ne peuvent pas toujours vérifier certaines
propriétés, comme par exemple l'atomicité ou l'isolation [GEORGAKOPOULOS et al. 95].
Un sous-processus Workflow nécessite la réalisation d'un ensemble d'activités et de sous-
processus, eux-mêmes liés à la réalisation d'un sous-ensemble de tâches etc.. La complexité
est encore augmentée par le fait que l'exécution peut avoir lieu en parallèle et sur des systèmes
différents ou géographiquement distants. Il y a donc un risque "d'effet de bord" qu'il faut
prendre en compte lors de l'exécution des activités des workflows. Par conséquent, il est
difficile d'isoler et de définir des transactions uniques et de leur associer des mécanismes de
récupération, en particulier quand il s'agit d'échecs d'applications. Pour ce faire, les
mécanismes de traitements des exceptions classiques s'accompagnent souvent d'autres
mécanismes, ainsi que d'algorithmes de propagation des exceptions. Cette propagation se fait
selon le cas vers l'amont ou vers l'aval, répercutant d'une façon récursive l'effet d'une
exception et le résultat local du mécanisme de traitement correspondant. C'est le cas pour un
grand nombre de méthodes ou de systèmes Workflows expérimentaux ou industriels, tels
OPERA, WAMO ou ADOME précédemment cités.

2.2 Adaptabilité des Workflows

L'adaptabilité est le deuxième aspect fondamental de la flexibilité dans le Workflow. Le terme
d'adaptabilité est souvent flou et peut donner lieu à plusieurs interrogations : que veut-on dire
par adaptabilité ? Qu'est ce qui est adapté ? Quand doit-on adapter ?

2.2.1 Définition de l'adaptabilité

L'adaptabilité d'un workflow est définie par sa capacité à modifier la définition du modèle de
processus sur lequel il est basé [KAMMER et al. 98]. Les causes qui font qu'il est nécessaire
d'adapter un modèle workflow sont diverses mais peuvent toutefois être réparties en deux
catégories principales :

1. La réutilisation du modèle ou d'une partie du modèle [BUSSLER 97]. En effet, il est

souvent utile de réutiliser le schéma d'un workflow pour deux raisons majeures :

§ Pour économiser un effort de conception et de développement lors de la définition de

nouveaux workflows, partageant des points communs avec des workflows existants.
Dans ce cas des parties de modèles sont réutilisées telles qu'elles lors de la conception
de nouveaux modèles.

§ Pour particulariser un schéma général à des cas plus spécifiques. L'exemple le plus
commun est celui d'une entreprise ayant des implantations dans différentes régions ou
différents pays. Ces ramifications fonctionnent toutes sur le même modèle (qui
caractérise l'entreprise), elles se basent donc toutes sur les mêmes processus métiers.
Néanmoins, étant donné leurs disparités géographiques, il se peut que ces processus
différent légèrement sur quelques aspects propres à chaque site. Ces différences
peuvent être dues à certaines contraintes locales, d'ordre législatif, culturel ou autres.
Par exemple on peut imaginer que dans un pays, une loi particulière nécessite l'ajout

95
 Chapitre 3 : Workflow et Systèmes Workflows avancés

d'étapes supplémentaires à un processus. Si l'entreprise fait appel à la technologie du

Workflow pour gérer ses processus métier, elle ne souhaite certainement pas concevoir
différents workflows pour chacune de ses branches. La solution la plus intéressante est
de définir un workflow "générique", factorisant les comportements communs et qui
sera adapté localement sous la forme d'un workflow spécifique.

2. Le besoin d'apporter des modifications au modèle des processus, pour deux raisons
principales :

§ Pour des motifs de correction du modèle des processus. Il est en effet possible qu'à un
certain moment, le processus en cours d'exécution dévie des objectifs qui lui sont
associés. Il est alors nécessaire d'intervenir sur le modèle des processus pour en
corriger la "trajectoire". Une autre source de correction peut être la réponse à une
exception. Il arrive en effet parfois, que la définition préétablie du processus soit à
l'origine d'une exception. Même si l'exception est traitée sur le moment, le fait qu'elle
ait pour origine la définition même du processus implique que son occurrence sera
récurrente. Par suite il est nécessaire d'intervenir sur le modèle workflow pour y
apporter des corrections. Pour illustrer cela, considérons le processus d'admissions de
patients dans un hôpital, pour une opération. La première activité du processus
consiste en la création impérative du dossier administratif du patient (numéro de
sécurité sociale, mutuelle, assurance, etc.). Or l'on constate que dans les cas
d'urgences, la première activité ne peut être réalisée qu'à posteriori (une fois le patient
soigné). On peut en déduire que le modèle du départ n'exprime pas entièrement la
vraie situation. Ceci a donc pour effet de générer des exceptions au niveau du
workflow et oblige les utilisateurs à utiliser des processus de gestion d'exceptions.
Afin d'éviter d'avoir à traiter de façon exceptionnelle des cas finalement "normaux", il
convient donc de revoir la définition du modèle workflow. Dans le cas de notre
exemple, il s'agira par exemple d'intégrer la possibilité de paiement différé.

§ Il est également nécessaire d'apporter des modifications pour des motifs

d'actualisation du modèle des processus. En effet, étant donné que l'environnement
des entreprises est en perpétuelle évolution, il est très probable que ces dernières aient
à revoir et à améliorer leur processus, pour rester en adéquation avec les contraintes du
marché. C'est le principe des méthodes telles le Continuous Process Improvement,
dont nous avons précédemment parlé. Le CPI n'étant pas une méthode radicale mais
progressive, elle se base donc sur un acquis. En transposant ce principe au Workflow,
actualiser les modèles workflows nécessite donc de les faire évoluer et de les adapter
aux nouvelles exigences, en conservant une part de l'acquis.

Que ce soit pour des motifs de correction ou d'actualisation, nous pouvons constater qu'il
est souvent impératif d'apporter des modifications aux modèles des processus, voir au
système lui-même. Ces modifications peuvent revêtir plusieurs formes. Il peut s'agir d'une
modification du flux des activités, de l'ajout de nouvelles entités (activités, rôles, acteurs,
etc.), de la suppression d'entités existantes ou de leur redéfinition en termes de
comportements.

S'il est clair que l'adaptabilité des workflows est nécessaire dans les deux cas - réutilisation et
modification - il est important d'indiquer qu'elle ne s'y applique pas de la même façon. En
effet, la réutilisation des workflows n'est pas contraignante au niveau du temps, c'est à dire
qu'elle peut se faire hors exécution des processus. Il s'agit surtout d'un moyen rapide et

96
 Chapitre 3 : Workflow et Systèmes Workflows avancés

efficace de récupérer l'existant pour l'adapter. La modification des processus quant à elle doit
se faire en cours d'exécution, sans arrêt du système Workflow ni du processus en cours de
réalisation. Si les mécanismes de base pour l'adaptation sont les mêmes dans les deux cas,
l'adaptation en cours d'exécution introduit des contraintes supplémentaires importantes, qu'il
convient de traiter. Nous reviendrons plus en détails sur ce point là dans la suite de ce
chapitre. Enfin, pour terminer la partie des définitions, il convient de distinguer deux
déclinaisons de l'adaptabilité. Quant le besoin d'adaptation du workflow en cours d'exécution
est détectée par le système et que l'adaptation est réalisée par le système ou par un de ses
agents, on dit que le système et que le modèle sont adaptatifs, c'est à dire qu'ils sont capables
de s'auto-adapter. Quand les modifications et les adaptations sont réalisées par une personne
(via les moyens fournis par le système et le modèle), on dit que le Workflow est adaptable.

2.2.2 Niveaux d'adaptabilité

[HAN et al. 98] estiment qu'il existe quatre niveaux d'adaptabilité dans le domaine du
Workflow. Ces niveaux sont classés par ordre décroissant d'abstraction :

1. L'adaptation au niveau du contexte. Les systèmes Workflows sont dans la plupart des cas
intégrés à un environnement informatique et informationnel, dans lequel ils jouent un rôle
particulier. Ces systèmes sont donc en collaboration avec d'autres systèmes d'information
et d'autres applications informatiques. Le rôle joué par le système Workflow est défini par
un certain contexte organisationnel et métier, qui définissent la configuration des systèmes
d'information de l'entreprise. Les contextes étant changeants (pour des raisons stratégiques
ou/et technologiques) leur modification peuvent avoir un impact sur la façon dont le
système Workflow s'intègre dans son environnement. Cet impact se répercute en fait sur
l'un des niveaux inférieurs de la classification, lequel devra mettre en œuvre des
mécanismes d'adaptation.

2. L'adaptation au niveau des processus. Elle concerne principalement les modèles

workflows et leurs composants. Le niveau processus est en général le plus concerné par
les besoins d'adaptation, notamment pour les causes que nous avons détaillées dans le
paragraphe de définitions.

3. L'adaptation au niveau des ressources. Pour [HAN et al. 98], ce niveau d'adaptation se
subdivise en deux sous niveaux :

§ L'adaptation de l'organisation, par exemple les changements de personnel ou les

restructurations, qui peuvent avoir un impact direct sur la cohérence du workflow.
Sont également concernées les ressources matérielles et logicielles impliquées dans la
réalisation des activités des processus. Tout changement organisationnel, au niveau
humain ou matériel doit être réfléchi sur les modèles workflow pour en préserver la
cohérence.

§ L'adaptation liée au données. Si les données dont dépendent les processus sont
modifiées ou si leur structure est modifiée, il convient alors de répliquer les
modifications sur les modèles qui leurs sont associés.

4. L'adaptation au niveau de l'infrastructure. C'est le niveau le plus bas de la classification.

Il concerne tous les changements dus aux avancées techniques et technologiques qui font

97
 Chapitre 3 : Workflow et Systèmes Workflows avancés

qu'il est nécessaire d'adapter les configurations des systèmes d'informations et des
applications sous-jacentes.

Cette classification est intéressante mais à notre sens, il aurait été plus exact de distinguer
uniquement deux niveaux principaux : celui du processus et celui du système. Le niveau
processus (ou plutôt niveau Workflow) englobe tout ce qui a trait avec la cohérence et
l'exactitude du modèle workflow. En effet, par définition (voir chapitre 1), un modèle
workflow traite différents aspects : l'aspect comportemental et fonctionnel, l'aspect
organisationnel (qui englobe l'aspect ressources) et l'aspect informationnel. Par conséquent le
niveau "processus" est concerné par toute modification ou changement sur l'un de ces aspects
et non uniquement par l'aspect comportemental comme semblent l'indiquer [HAN et al. 98].
Le niveau système quant à lui correspond au niveau infrastructure mentionné ci-dessus et
englobe tous les problèmes de mise à jour de matériel, de logiciel ou d'intégration avec
d'autres systèmes composant l'environnement du système Workflow.

2.2.3 Impact (profondeur) de l'adaptation

En plus des niveaux sur lesquels il est possible d'agir en terme d'adaptation, il est également
intéressant de se pencher sur l'impact des modifications sur le modèle workflow initial,
autrement dit sur la "profondeur" des modifications. Nous distinguons en effet trois niveaux
de profondeur, qui dépendent de l'importance des modifications par rapport au modèle initial :
le niveau "local", le niveau "local généralisé" et le niveau "global". Avant d'entrer dans le
détail de ces niveaux, il convient de décrire rapidement le fonctionnement global d'un système
Workflow lors de l'instanciation de "cas". Un cas, nous le rappelons, est une réalisation
pratique d'un workflow, c'est à dire une situation réelle d'un processus modélisé (voir chapitre
2). Chaque cas est instancié à partir du modèle workflow de référence que nous qualifions
"d'initial" et qui est stocké dans la base de données du système Workflow (fig. III.8). Il existe
plusieurs instanciation possible d'un workflow, donc plusieurs cas. Ces instances fonctionnent
toutes selon le schéma définit par le modèle initial.
Base de données
du système Workflow

Système Workflow

instanciation
Modèle du
processus de traitement
d ’un dossier
médical

Cas de monsieur Cas de madame

X Y

Figure III.8 - Instanciation de modèles de processus : "cas" Workflows

Nous distinguons donc trois niveaux de profondeur où il est possible d'adapter un workflow :

1. Le niveau local est le plus superficiel. Il correspond à une adaptation appliquée au niveau
d'une instance. Adapter un workflow au niveau local signifie qu'un besoin d'adaptation a

98
 Chapitre 3 : Workflow et Systèmes Workflows avancés

été constaté lors de l'exécution d'un cas du workflow mais que ce besoin se limite à ce cas.
Il s'agit donc d'adaptations spécifiques, sans récurrence ou à très faible fréquence
d'apparition. Par conséquent il n'est besoin d'adapter le workflow que pour ce cas, donc
"localement".

2. Le niveau local généralisé est plus profond que le niveau local et correspond
proportionnellement à un besoin d'adaptation plus sérieux. Ce niveau englobe toutes les
instances d'un workflow en cours de réalisation. En d'autres termes, si la nécessité d'une
adaptation est constatée sur l'une des instances, alors elle doit être répercutée sur toutes les
instances en cours d'exécution. L'adaptation au niveau local généralisé ne remet en cause
que la validité des instances en cours d'exécution. Par suite, elle ne s'applique pas aux
nouvelles instances du processus.

Ce type d'adaptation est réalisé dans le but d'actualiser les instances en cours d'exécution
ou pour corriger le processus. Un problème se pose quant à la stratégie d'application des
modifications : soit celles-ci ne concernent que les instances qui en sont au même degré de
réalisation, soit elles recouvrent l'ensemble des instances, y compris celles étant à un stade
plus avancé. Ce dernier cas est assez difficile à mettre en œuvre dans la réalité pour
plusieurs raisons. En particulier, cela nécessite de stopper l'activité en cours, d'appliquer
des mécanismes de roll back et de compensation performants, ce qui n'est pas toujours
possible, puis de reprendre l'exécution au point le plus éloigné dans le processus ayant
nécessité une adaptation (au cas où plusieurs points aient requis des modifications)
[HORN et al. 98]. En général par soucis de simplicité, seules les instances pouvant
intégrer l'ensemble des modifications sans nécessité de retour arrière sont concernées par
les adaptations ("tout ou rien"). Dans ce cas, le workflow ayant en premier lieu émit le
besoin d'adaptation sert de référentiel. Une autre solution consiste à poser une borne
"virtuelle". Dans ce cas, toutes les instances dont l'exécution n'a pas atteint la borne sont
concernées par les modifications. Les figure III.9 et III.10 montrent respectivement un
exemple d'adaptation locale généralisée avec un workflow référentiel et un exemple
d'adaptation avec une borne.

workflow du cas
m

workflow du cas n

workflow du cas p

workflow du cas q

: activité : activité en cours : activité à

terminée d’exécution exécuter
: insertion d’une : point d’exécution du
modification/adaptation workflow

Figure III.9 - Adaptation locale généralisée avec un workflow référentiel

99
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Dans la figure III.9, le workflow m sert de référentiel, par conséquent, seul le workflow n
est capable d'intégrer l'ensemble des modifications, puisqu'il n'a pas atteint le même stage
d'avancée que le workflow m. Par contre, bien qu'il soit encore possible de modifier une
partie du workflow q (la dernière activité), l'adaptation n'est pas réalisée pour satisfaire la
contrainte du "tout ou rien". Enfin, il est évident que le workflow p ne peut en aucun cas
absorber l'une ou l'autre des modifications.

L'exemple de la figure III.10 montre une adaptation avec une borne virtuelle servant de
référentiel. La borne, définie par un utilisateur compétent, indique un point de réalisation
processus avant lequel toute modification est possible. Toutes les instances du workflow
n'ayant pas atteint ce point peuvent donc intégrer les adaptations. Dans ce cas, il est
possible au workflow q de prendre en compte les modifications initialisées par le
workflow m. Toutefois, le workflow q doit mettre en œuvre des mécanismes de roll
back et de compensation.

workflow du cas
m

workflow du cas n

workflow du cas p

workflow du cas q

: activité : activité en cours : activité à

terminée d’exécution exécuter
: insertion d’une : point d’exécution du
modification/adaptation workflow

Figure III.10 - Adaptation locale généralisée

avec une borne "virtuelle" servant de référentiel

Avant de passer au niveau suivant, il est ici possible d'introduire une variante de
l'adaptation locale généralisée que nous nommons "adaptation locale contrainte". Cette
stratégie d'adaptation concerne toutes les instances en cours d'exécution répondant à
certains critères spécifiques. Par exemple, imaginons un processus de production et de
distribution de matériel technologique pointu. On peut imaginer qu'une imperfection a été
détectée sur un élément faisant partie d'un lot ou de plusieurs lots ayant été produits
pendant une période déterminée. Alors on peut souhaiter modifier uniquement le
workflow de production et de distribution de ces éléments pour les diriger vers un
processus de recyclage ou de réhabilitation.

3. Le niveau global. C'est le niveau le plus profond de l'adaptabilité car les adaptations sont
directement répercutées sur toutes les instances en cours d'exécution mais aussi et surtout
sur le modèle initial. Réaliser une adaptation au niveau global signifie que le modèle de
référence est remis en cause et qu'il ne correspond plus à la réalité. Par conséquent, les
nouvelles instances sont elles aussi concernées par les modifications. Notons que le niveau

100
 Chapitre 3 : Workflow et Systèmes Workflows avancés

global rencontre les mêmes problèmes que le niveau précédent, quant à la stratégie
d'applications des modifications. Les solutions y sont donc similaires.

Enfin, et pour terminer ce paragraphe, la figure III.11 se propose de résumer et d'illustrer les
trois niveaux de profondeur de l'adaptabilité.

Base de données Base de données Base de données

du système Workflow 1 du système Workflow 2 du système Workflow 3

Modèle Système Modèle Système Modèle Système

initial Workflow initial Workflow initial Workflow

Instances en
cours
modifications d ’exécution modifications
modifications

Adaptation locale Adaptation locale généralisée Adaptation globale

Figure III.11 - Niveaux de profondeur de l'adaptation des workflows

2.2.4 Adaptabilité et permissions

Mettre en œuvre l'adaptabilité des workflows est certes un aspect impératif des nouveaux
systèmes Workflows, encore faut-il savoir qui en est responsable, notamment dans le cas du
Workflow "adaptable". En effet, dans le cas "adaptatif", nous avons précédemment dit que le
système ou l'un de ses agents est chargé d'introduire les modifications. Sans rentrer dans les
détails - chose que nous ferons par la suite - il est clair que le cas adaptatif est plus
contraignant puisqu'il suppose la présence d'une certaine forme "d'intelligence" au sein du
système. Dans la majeure partie des cas, les modifications sont en fait réalisées par des acteurs
humains. Cela n'est toutefois pas non plus sans poser quelques problèmes. En effet, lorsque la
nécessité de modifier un processus se présente, trois questions fondamentales se posent :

1. Qui possède les qualifications nécessaires pour apporter les adaptations ?

2. Comment assurer la cohérence des modifications ?
3. Quels sont les moyens mis à la disposition des utilisateurs non-spécialistes (notamment en
programmation ou en Workflow) ?

Dans ce paragraphe, nous nous intéressons plus particulièrement à répondre à la première

question, bien que nous abordions les deux autres qui y sont logiquement reliées.

La conception d'un modèle de processus n'est en général pas triviale mais est le résultat de
réflexions importantes. C'est l'œuvre de spécialistes, analystes, managers, concepteurs, etc.
Par conséquent, modifier un modèle pour y apporter des adaptations n'est pas à la portée de
tout utilisateur mais nécessite certaines compétences. D'une part, il faut être certain que les
modifications sont nécessaires et d'autre part, il faut s'assurer que l'intervention de l'utilisateur
n'apporte pas plus de problèmes qu'elle n'en résout [DEITERS et al. 98]. En particulier, un
contrôle de la cohérence du nouveau modèle doit être assuré, soit par le système Workflow
lui-même, soit par un système d'analyse de processus, qui s'y interface [REICHERT et al. 98].
Pour éviter des interventions non désirables, la méthode la plus couramment utilisée est celle

101
 Chapitre 3 : Workflow et Systèmes Workflows avancés

des droits d'accès (permissions) associées aux workflows et à leurs données. Dans certains
systèmes Workflows, ces droits correspondent à ceux attribués aux utilisateurs par
l'administrateur du système d'exploitation. Les personnes pouvant modifier les workflows
sont donc des utilisateurs spéciaux ou appartenant à des groupes spéciaux. Toutefois dans la
majorité des systèmes Workflows, il est possible d'établir une hiérarchie de permissions et de
privilèges, via le module de modélisation de l'organisation de l'entreprise. En général, les
permissions sont des caractéristiques intrinsèques aux rôles que peuvent prendre les
utilisateurs inscrits dans la base du système. Il est de plus souvent possible d'avoir des rôles
prédéfinis, tels "administrateur", "créateur" (d'un processus) ou "ayant droit".

Enfin, l'autre problème qui se pose est de savoir comment faire en sorte que des utilisateurs
non-spécialistes de la programmation, puissent adapter un workflow. L'adaptation n'étant pas
uniquement rappelons-le, un problème de réordonnancement mais elle concerne souvent la
définition même des entités impliquées dans le processus. Nous discuterons plus en détail ce
problème dans la suite de ce chapitre et dans le chapitre suivant.

Jusqu'à présent, il a été question des niveaux d'applicabilité des adaptations, de leur impact sur
les modèles de processus, ainsi que de leurs conséquences sur les questions de sécurité et de
cohérence des modèles. Toutefois, un aspect de l'adaptabilité n'a pas encore été abordé : celui
de la mise en œuvre de l'adaptabilité Workflow. Quelles sont les approches existantes et quels
sont leurs intérêts et leurs défauts ? Cet aspect étant l'un des plus importants de l'adaptabilité,
nous proposons de lui consacrer un paragraphe complet dans ce chapitre.

3. Mise en œuvre de l'adaptabilité - approches et méthodes

Ainsi que le mentionnent [HAN et al. 98], il existe deux catégories principales d'approches
pour la mise en œuvre de l'adaptabilité Workflow : les approches ponctuelles et les approches
par métamodèles. Ces approches diffèrent dans les techniques qui y sont développées et
adoptées mais également en efficacité en terme d'adaptabilité. Dans les paragraphes suivants,
nous détaillons et discutons chacune de ces approches séparément.

3.1 Approches ponctuelles

Les approches ponctuelles ("open point approaches") consistent à définir certains points dans
un modèle Workflow à partir desquels des adaptations peuvent être apportées : on les appelle
également points "d'entrée". Le terme de point d'entrée est en fait assez générique car cette
approche englobe en fait différentes formes de réalisation qui peuvent être classées en trois
techniques :

1. Les choix multiples,

2. L'allocation dynamique de ressources,
3. La modélisation tardive et la modélisation ad hoc.

1. La technique des choix multiples est l'expression la plus simple de l'approche ponctuelle.
Elle consiste comme son nom l'indique, à placer des "bornes" au sein du modèle du
processus. Chaque borne, quand elle est atteinte, permet de stopper l'exécution du
processus pour offrir à l'utilisateur plusieurs alternatives pour la poursuite de l'exécution.
Une borne est en général associée à une activité ou à un événement ayant lieu dans le

102
 Chapitre 3 : Workflow et Systèmes Workflows avancés

processus. La technique des choix multiples est utilisée lorsque l'on ne peut pas fixer des
choix lors de la conception du workflow mais qu'on a une évaluation globale de la
situation, qui permet de concevoir différentes alternatives. Une évolution hybride de cette
technique permet à l'utilisateur d'introduire des "morceaux" de processus ou des sous-
processus, stockés dans une librairie. Cette dernière technique est en fait à l'intersection
entre celle des choix multiples et la modélisation tardive. Elle est notamment proposée
par le système pour "workflows Scientifiques" WASA [WESKE 96]. Ce dernier donne
aux utilisateurs, le moyen de choisir un sous-processus dans une librairie, afin de
compléter le workflow en cours. Deux modes sont possibles : le premier mode est de type
"actif", ce sont les utilisateurs qui interviennent sur l'exécution du processus et indiquent
leur choix au serveur Workflow (à l'aide d'instructions SQL). Le deuxième mode est de
type "passif" : c'est le serveur qui relance les utilisateurs afin de connaître l'évolution du
processus, en leur proposant éventuellement des sous-processus possibles.

2. L'allocation dynamique de ressources est une autre technique assez répandue de

l'approche ponctuelle. Elle permet essentiellement de résoudre les problèmes dus à des
conflits d'attribution de ressources (qu'elles soient matérielles ou humaines) lors de
l'exécution du workflow. En effet, la plupart des langages de modélisation Workflows
nécessitent de fixer l'application des ressources aux tâches lors de la phase de
modélisation. Il peut en découler des conflits lors de l'exécution, si des ressources ne sont
pas disponibles ou si leur utilisation est requise simultanément par plusieurs activités.
Une première approche est de confier la résolution du problème, lorsqu'il se présente, à
des applications d'ordonnancement, qui se chargeront de trouver la meilleure solution.
Une autre solution plus intéressante est proposée par l'allocation dynamique de ressource,
qui s'intéresse à éviter le problème plutôt qu'à le résoudre. Cette approche consiste à
associer aux tâches des types de ressources, plutôt que les ressources elles-mêmes.
Plusieurs ressources physiques peuvent donc appartenir à un même type. Ainsi, lors de
l'exécution, un algorithme d'allocation des ressources (plus ou moins sophistiqué) affecte
dynamiquement les ressources physiques aux tâches, en recherchant celles qui sont
disponibles pour le type de ressource requis par la tâche. Cette approche est très
semblable à la liaison dynamique (dynamic binding) des langages de programmation
objets, lors de l'appel de méthodes de classes polymorphes.

L'allocation dynamique de ressource est en autre mise en œuvre dans le système

Workflow "Endeavor" [BOLCER et al. 96], [KAMMER et al. 98], [HITOMI et al. 98],
sous une forme assez évoluée. En effet, l'allocation dynamique y est utilisée pour
l'attribution des ressources aux tâches mais également, pour choisir dynamiquement le
comportement adéquat d'un objet du système, parmi l'ensemble de ses comportements. La
possibilité d'allouer dynamiquement un comportement est une évolution de l'allocation
dynamique de ressources, appelée "late binding" [JOERIS 00] ou "liaison tardive de
comportement". Elle se situe à mi-chemin entre l'allocation dynamique et la modélisation
tardive. Cette approche ne concerne pas les ressources mais la façon de réaliser le
processus. Nous y reviendrons plus longuement par la suite. Remarquons enfin que dans
les langages de programmation par objets, il n'y a pas de différence entre les expressions
"allocation dynamique" et "allocation tardive" [ECKEL 00].

3. La modélisation tardive et la modélisation ad hoc, représentent deux dernières techniques

des approches ponctuelles. L'expression "modélisation tardive" regroupe en fait deux
déclinaisons sous une même appellation : la "modélisation tardive" proprement dite ("late
modelling") et "l'affinage dynamique" des modèles ("dynamic refinement"), bien que

103
 Chapitre 3 : Workflow et Systèmes Workflows avancés

souvent aucune distinction ne soit faite dans la littérature. Dans les deux cas, il s'agit
d'ajouter des éléments au modèle du processus, qui n'avaient pas pu être représentés pour
des raisons diverses - dont nous avons discuté au début de ce chapitre.

L'affinage dynamique des modèles représente en quelque sorte, une entrée en la matière
de la modélisation tardive. En général, l'affinage dynamique s'exprime surtout par
l'instanciation ou la particularisation de valeurs génériques appartenant au modèle avant
exécution. Il s'agit donc de définir au niveau du modèle initial, des "templates" (modèles)
dans lesquels certaines entités sont exprimées sous forme générique, que l'on instancie en
cours d'exécution. La figure III.12 donne un exemple d'un modèle de processus (construit
à l'aide d'un pseudo langage Workflow).

Process makeReservation
Le processus "makeReservation" est utilisé
Activity check_train (<journey>) pour organiser les voyages des membres d'une
if not (free_places)
Process <exception_Process>
entreprise. Dans le modèle de ce processus, on
else Activity check_hotel( hotel du nord) a deux éléments génériques : <journey> qui
if not (free_rooms)
Activity try_Hotel2
correspond à un type global de voyage et
<exception_Process>, un processus générique
traitant les exceptions mais n'ayant pas été
Process makeReservation identifié au préalable. Lors de l'exécution, il est
Activity check_train (businessTravel(paris))
if not (free_places) possible de remplacer les entrées génériques
Process check_plane par des instances particulières. Par exemple ici,
else Activity check_hotel( hotel du nord)
if not (free_rooms) le terme <journey> est remplacé par un type
Activity try_Hotel2 spécifique nommé "businessTravel(paris)",
qu'on suppose être défini dans la base du
< xxx > : terme générique
xxx : mot clé - xxx : instance système Workflow. Le processus générique de
xxx : valeur gestion d'exceptions est quant à lui, remplacé
par un vrai processus "check_plane".
Figure III.12 - Instanciation de parties
génériques d'un modèle de processus

Le système Workflow "MQseries Workflow" (ex "FlowMark") [MQseries 99],

[VOSSEN et al. 96] de IBM propose un exemple d'affinage dynamique. Il y est en effet
possible de créer des sous-processus génériques, appelées "bundles". Un bundle est un
sous-processus dont on ne connaît pas au préalable le nombre d'instances. Ce dernier n'est
connu qu'en cours d'exécution, soit par déduction du résultat d'une activité précédente,
soit grâce à l'intervention d'un utilisateur.
A1 A2 SP-x A4
La modélisation tardive quant à elle, est
une étape plus évoluée qui consiste à Modélisation
modéliser en cours d'exécution (donc en cours d ’exécution

d'une façon ad hoc), certaines parties

manquantes du processus. Celles-ci sont x/A1 x/A3
A1 A2 A4
représentées au préalable par des &
x/A2
éléments génériques (des "boîtes noires")
qui sont remplacés par la suite par une
: activité SP : sous-processus
modélisation "on line", adéquate et
: Et -jointure : boîte-noire / zone générique
détaillée. A première vue, cela ressemble &

à l'affinage dynamique. La différence qui

existe entre les deux est en fait que Figure III.13 - Modélisation tardive

104
 Chapitre 3 : Workflow et Systèmes Workflows avancés

la modélisation tardive consiste à introduire de nouveaux éléments au modèle (figure

III.13), alors que l'affinage dynamique se limite à en instancier des parties génériques

Avant de donner un exemple de modélisation tardive, remarquons qu'on retrouve parfois

dans la littérature - à juste titre - une différence entre "modélisation tardive" et
"modélisation ad hoc", bien que souvent - comme pour l'affinage dynamique - la
distinction ne soit pas toujours faite. La modélisation tardive consiste, nous l'avons vu, à
remplacer une partie générique du modèle - un "outil à tout faire" - par une modélisation
"on line" de cette partie. Il faut donc que l'emplacement de cette partie ait été réservé au
préalable. La modélisation ad hoc par contre, n'intervient pas en remplacement d'une
partie générique mais directement sur la construction du modèle, lors de l'exécution.
Comme nous l'avons vu dans la "classification par catégories des systèmes Workflows"
du chapitre 1, un système Workflow ad hoc gère des processus très peu répétitifs, non
structurés et non définis au préalable. Ces systèmes proposent donc en général de créer
les activités workflow au fur et à mesure de l'avancée du processus. Ainsi contrairement à
la modélisation tardive où seuls quelques éléments restent à définir en cours d'exécution,
la modélisation ad hoc propose de définir les composants du workflow, au fur et à mesure
de l'avancée du processus. Cependant, on constate souvent que des systèmes ad hoc sont
utilisés pour définir les zones génériques en cours d'exécution.

En définitive, quand la distinction entre modélisation ad hoc et modélisation tardive est

faite, si la modélisation ad hoc n'est possible qu'en certains points du modèle, alors elle
reste dans la catégorie des approches ponctuelles. Par contre, si la modélisation ad hoc est
permise à tout endroit du processus et qu'elle peut remettre en cause la définition du
modèle et de ses composants, alors elle passe dans la catégorie des approches par
métamodèles, que nous développons plus loin.

Un exemple de modélisation tardive est donné par le moteur Workflow du système

"Baan" [MEIJLER et al. 98]. Le système prévoit le cas où les concepteurs d'un modèle
workflow ne peuvent connaître par avance l'ensemble des activités d'un processus, mais
qu'ils sont capables d'en définir une importante partie. Afin de permettre l'exécution du
workflow incomplet d'une part, et l'ajout des activités manquantes d'autre part, le système
Baan propose le concept "d'activité d'extension" ("shoot tip activity") (fig. III.14). Une
activité d'extension est une activité neutre - donc sans effet dans le processus - qui a deux
fonctions. La première est de permettre l'exécution d'un workflow incomplet, grâce à des
éléments syntaxiquement corrects qui servent à "combler les vides". La deuxième
fonction est de servir de point d'entrée dans le modèle, pour l'insertion de nouvelles
activités. Ainsi, quand l'activité d'extension est exécutée, elle appelle automatiquement
une méta activité en lui passant l'état du processus. Cette dernière invoque ensuite
l'éditeur de modèles du moteur Workflow. Les insertions sont d'abord validées par la
méta activité puis répercutées sur l'instance du modèle en cours d'exécution. Remarquons
qu'une autre activité d'insertion est ajoutée à la fin du nouveau modèle, et ce pour
préserver la possibilité de faire d'autres insertions.

Cette technique fait en fait appel à des mécanismes réflexifs, dont nous reparlerons dans
la partie concernant les approches par métamodèles. Toutefois, la technique développée
par Baan présente un inconvénient majeur malgré son intérêt. En effet, les activités
d'extension ne servent que pour l'insertion de nouvelles activités. Elles sont donc toujours
positionnées à la fin d'une partie d'un processus, susceptible d'être augmentée. Si le
processus est composé de plusieurs parties en parallèle, alors le modèle fini vite par être

105
 Chapitre 3 : Workflow et Systèmes Workflows avancés

surchargé d'un nombre important d'entités sémantiquement et conceptuellement inutiles

(les activités d'insertion) (figure III.14)

Démonter activité
lave-linge à insérer

Extraire le
mélangeur

Extraire le Extraire le
moteur tambour

Ôter le
couvercle Récupérer
le tableau

: Activité ou sous-processus : Décomposition

: Activité "d’insertion" : Flux

ou "d'extension"

Figure III.14 - Modélisation tardive dans le système Baan

3.2 Approches par métamodèles

La deuxième catégorie d'approches visant à mettre en œuvre l'adaptabilité Workflow est
caractérisée par les approches dites "par métamodèles". Celles-ci utilisent des métamodèles
ou des méta composants Workflows pour définir - et redéfinir - la structure, le type et les
comportements des éléments constituant un modèle Workflow. Avant de rentrer dans le détail
de ces approches, il convient de définir ce qu'est un métamodèle.

3.2.1 Métamodèle : définition

Un modèle est, nous l'avons dit, une abstraction d'une partie du monde réel (ou d'un
problème). Il est composé d'un ensemble d'éléments en relation, traduisant des entités réelles
en relation, qu'elles soient physiques ou conceptuelles. Un modèle sert généralement à décrire
le comportement de ces entités lorsqu'elles sont placées dans une situation particulière, dans
un but de compréhension et/ou de simulation. Un modèle se situe donc au premier niveau
d'abstraction "au-dessus" des objets du monde réel. Les objets traduits par un modèle et les
relations qui existent entre eux, sont représentés au travers de formalismes et des vues
spécifiques. A un deuxième niveau d'abstraction, plus élevé, se pose alors le problème de la
structuration et de la réglementation des comportements des formalismes et des relations,
utilisés pour la création des modèles. C'est le niveau des "métamodèles". Un métamodèle est
un modèle permettant de décrire les comportements et les relations existants entre des
formalismes d'un même domaine, afin de permettre, grâce à leur utilisation, la conception
correcte de modèles d'objets du monde réel. Par exemple, la notation unifiée objet UML
propose un métamodèle qui décrit la façon d'utiliser l'ensemble des formalismes de la
notation, dans les différents types de diagrammes qu'elle propose.

Au niveau du Workflow, l'approche par métamodèle a donc pour but de permettre d'apporter
des modifications sur les modèles workflow, via leurs métamodèles. Plus généralement, une
approche par métamodèles s'étend au recouvrement de deux objectifs principaux :

106
 Chapitre 3 : Workflow et Systèmes Workflows avancés

§ Définir un métamodèle Workflow qui sert de fondement à la construction et à la

réutilisation de modèles Workflows. Ceux-ci sont donc construits à partir des composants
du métamodèle (ou de leur spécialisation si la réutilisation est possible) et en appliquant
les règles de conception et de modélisation qui y sont définies.

§ Proposer un ensemble de primitives associées aux composantes du métamodèle,

définissant des règles et des opérations et permettant de manipuler les workflows issus du
métamodèle. Ce deuxième aspect est, pour la plupart des approches par métamodèles,
basé sur un même principe, celui de la réflexivité.

3.2.2 La réflexivité

Selon le dictionnaire en ligne des éditions Hachette [HACHETTE 99], un acte est réflexif s'il
est fondé sur une réflexion. La réflexion est définie comme étant un "retour opéré par la
pensée sur elle-même en vue d'une conscience plus nette et d'une maîtrise plus grande de ses
processus". Plus simplement, la réflexion d'un objet (par exemple dans un miroir) est l'image
qu'un objet a de lui-même. Ces définitions sont intéressantes car elles s'appliquent bien à
l'utilisation du terme de réflexivité en informatique.

Un système informatique est dit réflexif s'il intègre une représentation (un modèle) de sa
structure et de son comportement [FOOTE 90], [DOURISH 95], [DOURISH 96], [SOBEL et
al. 96]. Ce modèle est directement lié à l'état et au comportement du système par une relation
"causale", qui établit une connexion à deux sens entre le modèle et le comportement que le
modèle décrit. Cette relation permet ainsi au système d'obtenir une représentation de son
comportement et de son état, mais lui permet également de les contrôler et de les modifier. En
d'autres termes, la relation causale implique que toute modification fait sur la représentation
du système se "réfléchit" immédiatement sur son état et son comportement [FOOTE 90]. Un
système réflexif est donc un système capable d'observer et de modifier son propre
comportement en cours d'exécution. Par conséquent, un modèle réflexif est un modèle "actif",
tel que nous l'avons défini dans le premier chapitre de ce mémoire.

La faculté d'un système à examiner son état et SYSTEME

son comportement est appelée Méta niveau

"introspection". La faculté d'un système à Méta entité Méta entité ... Méta entité ...
modifier son état et son comportement est
introspection
appelée "intercession". La réflexivité est mise intercession relation causale
réification
en œuvre dans un système par une conception Niveau de base
de ce dernier en deux niveaux d'abstraction :
le niveau d'abstraction inférieure est le niveau
Entité du
domaine
d’application
Entité du
domaine
d’application
...
"de base". Les entités qu'il contient
appartiennent au domaine d'application du
système. Le niveau d'abstraction supérieure
est le niveau "méta", où le domaine de Entité du Entité du Entité du
définition des entités est le système lui-même. monde réel monde réel monde réel
La relation causale s'applique donc entre les
Domaine d’application - monde réel
entités des deux niveaux. On parle de
"réification" lorsqu'une entité du niveau de
base renvoie son état et sa structure (attributs Figure III.15 - Système réflexif
plus comportements) sous la forme d'une

107
 Chapitre 3 : Workflow et Systèmes Workflows avancés

structure de données, vers une méta entité. Cette dernière peut alors agir sur cette structure de
données et réfléchir les modification vers l'entité du niveau inférieur qui reprend alors son
exécution sur de nouvelles bases. On parle dans ce cas de "méta traitement".

Si la réflexivité est l'un des principes de base suivis par les approches par métamodèles,
l'application de ce principe - la façon dont il est mis en œuvre - diffère d'un système
Workflow à un autre ou d'une architecture à une autre. Ainsi, nous avons vu précédemment
que beaucoup de systèmes Workflows s'inspirent des théories des SGBD avancés, dont ils
emploient et enrichissent les outils; cela est notamment vrai dans le cas de la gestion
d'exceptions. Les systèmes WASA et WISE précédemment cités en sont de bons spécimens.

Dans le système WASA par exemple, outre les choix multiples qui sont proposés en cours
d'exécution (approche ponctuelle), il est possible de modifier un modèle Workflow en y
accédant directement. Cet accès est réalisé par l'intermédiaire Interface
d'instructions SQL - définies en tant que primitives - de contrôle Base des spécifications
intervenant sur la définition des composants de la "base de tâche_1
spécifications". Ces composants correspondent aux entités
des workflows ou aux règles ECA qui définissent le flux
de contrôle. Remarquons que les concepteurs ou les SQL Modèle
tâche_2

utilisateurs privilégiés ont également la possibilité Workflow

d'introduire des instructions SQL autres que les primitives,

via un interpréteur de commandes. En fait dans le cas de Figure III.16 – Adaptabilité
WASA, l'adaptabilité est mise en œuvre, non pas à l'aide dans le système WASA
d'un métamodèle ou d'un méta objet, mais via une
interface utilisateur de contrôle, permettant de visualiser la définition d'un processus (le
niveau méta) et son exécution. Dans cas, il s'agit plus de "méta traitement", tel que nous
l'avons défini dans le paragraphe précédent, que de réflexivité proprement dite. Cela est
d'ailleurs le cas d'un grand nombre de systèmes Workflows qui proposent des mécanismes
d'adaptabilité.

Un exemple plus intéressant est proposé par le modèle ROK ("Reflexive Object Model")
[EDMOND 98], [EDMOND 00]. Ce modèle a initialement été conçu pour introduire de la
flexibilité dans les SGBD et les systèmes coopératifs répartis et a évolué vers les systèmes
Workflows. ROK propose d'associer à tout objet d'une application informatique – en
particulier d'un workflow – cinq méta objets qui correspondent chacun à une facette de l'objet.

1. Le premier de ces méta objets est celui "d'état" ("State"). Un objet d'état définit l'ensemble
des attributs d'un objet, son contexte (en fait le nom de la classe de l'objet), un ensemble
de prédicats sur les valeurs que les attributs peuvent prendre, ainsi que des conditions et
des valeurs d'initialisation. Plusieurs objets peuvent appartenir au même contexte, et sont
de fait, lié au même objet d'état.

2. Le deuxième méta objet est l'objet de "comportement" ("Can"). Il décrit l'ensemble des
comportements – ou activités - que peut réaliser un objet. Chaque comportement est
associé à un ensemble de pré et de post conditions qui définissent, à la manière des règles
ECA, les conditions d'activation d'une activité. Enfin, chaque activité est décrite par une
spécification générique, traçant dans sa globalité la façon dont elle est réalisée. Cette
spécification générique se rapproche des "templates" de l'affinage dynamique. A l'instar
de l'objet d'état, plusieurs objets appartenant au même contexte peuvent être liés au même
objet de comportement. Remarquons qu'un objet comportement décrit uniquement les

108
 Chapitre 3 : Workflow et Systèmes Workflows avancés

compétences d'un objet mais non la façon dont il les réalise. Par conséquent, des objets
partageant les mêmes comportements peuvent les réaliser de façons différentes. A la
limité, un même objet pourra avoir différentes réalisations pour un comportement.

3. Le troisième méta objet est l'objet "tâche" Comportement

("Task"). Il décrit les relations chronologiques Etat

qui existent entre les activités d'un objet et Application

celles des objets d'un même groupe. Un
groupe correspond tout simplement à un Objet
Tâche Acte
intérêt commun réunissant des objets. En
d'autres termes, un méta objet "tâche" décrit un
ensemble d'interactions qui existent entre les groupe Objet Objet
objets d'un même groupe. Par conséquent, une
même "tâche" est associée à plusieurs objets.
: Invocation d’une primitive d’un méta objet
Parmi les composants principaux d'une tâche,
on retrouve un ensemble d'activités des objets : Réflexion de l’effet vers un ou + objets

d'un groupe, les événements qui les

Figure III.17 – Réflexivité dans le
enclenchent - en fait des couples d'activités,
modèle ROK
l'une enclenchant l'autre – des sous tâches, etc.

4. Le quatrième méta objet, l'objet "acte" ("Act"), est directement lié au méta objet "Tâche",
pour lequel il définit un ensemble d'attributs fondamentaux décrivant l'état de la tâche :
"programmée", "terminée", "en cours", etc..

5. Enfin le dernier méta objet est l'objet "d'application" ou de "correspondance" ("Map").

Comme sa dénomination anglaise l'indique, ce méta objet fait un mappage entre les
activités d'un objet (celle définie dans le méta objet de comportement) et le code (ou la
procédure) qui permet de les réaliser. L'un des attributs essentiels de ce méta objet est
l'attribut de localisation, qui détermine l'endroit (répertoire, URL, etc.) où la réalisation de
l'activité est accessible.

Toute modification faite sur un objet, par exemple sur un composant d'un processus, est
réalisée via l'un des méta objets. Ces derniers sont munis de primitives qui leur permettent de
modifier le contenu de leurs attributs et de réfléchir ces modifications vers les objets auxquels
ils sont associés. La méthode ROK propose donc un vrai exemple de réflexivité. Elle utilise
en plus d'autres concepts importants, notamment la séparation entre "interface" et
"réalisation". En effet, le méta objet de comportement définit clairement l'interface d'un objet.
En d'autres termes, il donne des indications sur la façon dont l'objet peut être utilisé, sans
dévoiler le comment de la réalisation (ce qui est fait par le méta objet acte). Cette séparation
permet à l'objet de changer la façon dont il réalise une activité (donc le contenu de "acte"),
sans perturber ses relations avec les autres objets, puisque celles-ci se basent sur le contenu de
l'interface. Ceci est bien évidemment d'un grand intérêt pour les besoins d'adaptation des
workflows. Nous développerons cet aspect beaucoup plus en détail dans un prochain
paragraphe.

Les deux exemples précédents – WASA et ROK - nous ont permis de présenter deux cas
typiques d'approches par métamodèle, avec des niveaux de complexité différents dans leur
mise en œuvre. D'autres méthodes et d'autres façons d'appliquer la réflexivité sont également
proposées par d'autres systèmes et d'autres modèles. Ces méthodes partagent des points de

109
 Chapitre 3 : Workflow et Systèmes Workflows avancés

vues communs, et se distinguent sur d'autres. Nous aurons l'occasion d'y revenir dans le
prochain chapitre de ce travail.

Dans les paragraphes 3.1 et 3.2, nous avons décrit les deux principales catégories d'approches
mettant en œuvre l'adaptabilité des Workflows. Comme nous avons pu le constater, la
complexité de cette mis en œuvre, mais aussi son efficacité, diffèrent selon les approches.
Globalement, nous pouvons dire que les approches ponctuelles sont plus "facile" à réaliser
mais que leur efficacité se limite aux points d'entrée prévus sur les modèles. A l'opposé, les
approches par métamodèles sont plus efficaces puisqu'elles permettent d'adapter l'ensemble
des parties d'un workflow, que ce soit en termes de flux ou en termes de définitions des
composants des modèles. Par contre, leur réalisation est plus complexe, pour les concepteurs-
développeurs Workflows, ainsi que pour les utilisateurs, qui ne sont pas nécessairement
spécialistes des concepts utilisés. Afin de tirer profits des avantages de chacune des deux
approches, [HAN et al. 98] proposent d'adopter des approches mixtes. Celles-ci combinent les
techniques de la première catégorie pour les besoins d'adaptation localisés et pour les
problèmes de gestion de ressources, alors que les techniques de la deuxième catégorie sont
utilisées pour les besoins plus importants d'adaptation en cours d'exécution, ou en vue d'une
réutilisation.

Jusqu'à présent, nous avons vu quelles sont les approches possibles pour réaliser l'adaptabilité
Workflow. Toutefois, nous n'avons pas vu quels sont les concepts et les outils sur lesquels se
basent et sont élaborées ces approches. En d'autres termes, comment les différentes approches
sont-elles réalisées ? Parmi ces concepts, nous nous intéressons plus particulièrement à celui
des objets informatiques et encore plus spécifiquement au concept de Workflow Orienté
Objet.

110
 Chapitre 3 : Workflow et Systèmes Workflows avancés

4. Workflow Orienté Objet

4.1 Concepts des Objets

La programmation par objets est née de deux besoins fondamentaux qu'ont les développeurs
et les concepteurs d'applications informatiques : maîtriser la complexité des grands projets et
maintenir et faire évoluer leurs logiciels, de la façon la moins coûteuse possible [BOOCH 92],
[MULLER 98]. Ce coût est évalué en fonction de trois facteurs indissociables : le temps
consacré à la réalisation de l'évolution, (ou de mise à jour), ainsi que l'effort et les ressources
nécessaires à lui attribuer.

Afin d'amoindrir le coût de l'évolution, l'une des solutions est de réutiliser des parties des
applications existantes, en les adaptant aux nouveaux besoins des utilisateurs. Pouvoir
réutiliser et adapter des parties de logicielles à faible coût nécessite de satisfaire deux
conditions :

§ Avoir un cloisonnement entre les différents composants d'une application, une certaine
"indépendance du code" qui fait qu'il est possible de modifier une partie d'un logiciel
sans avoir à répercuter la modification sur les autres parties avec lesquelles le
composant modifié interagit.

§ Avoir des mécanismes permettant de réutiliser des parties de logiciels sans avoir à
connaître leur code source ou à le réécrire. Cet aspect est entre autres particulièrement
intéressant quand on souhaite adapter et spécialiser les éléments d'une librairie.

Le concept des objets informatiques apporte une réponse très satisfaisante à ces deux
conditions. Un objet informatique - nous dirons simplement un objet - est une abstraction
d'une entité du monde réel, physique ou conceptuelle. Un objet est en général définit en
fonction du point de vue que porte une personne sur l'objet réel, placé dans un contexte
particulier. La définition de l'objet est réalisée à l'aide de deux ensembles d'éléments :

1. L'ensemble des "attributs". Un attribut est un descripteur, un conteneur de qualificatif qui

sert à décrire un aspect de l'objet. Ce qualificatif peut prendre une ou plusieurs valeurs
durant la vie de l'objet et l'ensemble des valeurs des attributs à un certain moment,
renseigne sur l'état de l'objet au même moment. L'un des attributs de l'objet, son
identifiant, joue un rôle particulier qui permet de le distinguer des autres objets. Un objet
est donc une entité unique.

2. L'ensemble des "comportements" de l'objet. Un comportement correspond à une activité

ou à une fonction que peut remplir un objet. En général, les comportements de l'objet
(appelés "méthodes" dans les langages de programmation objets) sont divisés en trois
catégories :

§ La première catégorie comporte des fonctions qui permettent de manipuler les attributs
de l'objet ou d'en connaître la valeur.

§ La deuxième catégorie des comportements est composée de services que peut rendre
l'objet, on parle également de compétence. Les compétences d'un objet ne sont pas
toutes nécessairement directement accessibles.

111
 Chapitre 3 : Workflow et Systèmes Workflows avancés

§ Enfin la dernière catégorie correspond à l'ensemble des fonctions qui permettent à

l'objet de dialoguer avec d'autres objets - on dit que les objets communiquent par
l'envoi de messages. Cette catégorie englobe en fait la première, puisque les méthodes
de manipulation des attributs sont en partie des moyens permettant de communiquer
avec l'objet en question.

Les objets qui peuvent être décrits par les mêmes attributs et présentant les mêmes
comportements sont réunis dans un ensemble appelé "classe". Une classe définit un type
d'objets, donc une conceptualisation de l'abstraction introduite par l'objet. La création d'un
objet d'une classe donnée s'appelle instanciation de la classe. Tout objet est donc l'instance
d'une classe. Il existe toutefois des classes, dites abstraites, qui ne peuvent être instanciées car
elles représentent des concepts trop génériques. Une classe n'est abstraite que par rapport au
point de vue adopté dans le problème où elle s'insère. Par exemple la classe "Véhicule" peut
être une classe abstraite pour une application de gestion de parc automobile car elle représente
une notion trop générique pour être instanciée.

Un langage de programmation est dit "orienté objet" s'il permet d'appliquer "naturellement"
les propriétés des objets, en particulier l'encapsulation, l'héritage et le polymorphisme, que
nous décrivons plus avant. Un langage orienté objet est un langage dont le vocabulaire, la
syntaxe et la sémantique intègrent les notions des objets. A l'opposé, un langage est dit "basé"
objet s'il ne met pas en œuvre l'ensemble des concepts des objets (en particulier l'héritage et le
polymorphisme) [BOOCH 92], ou s'il ne peut le faire que par des artifices de programmation.
Un langage orienté objet peut être entièrement basé sur les concepts des objets, c'est à dire
qu'il ne permet que de créer des objets. C'est le cas des langages Java, Eiffel, Smalltalk, etc.
Enfin, un langage peut être étendu aux objets, s'il ajoute des mécanismes de programmation
objets à des mécanismes de programmation procédurale classique. C'est le cas des langages
C++, ADA, Pascal Objet, etc.

Les objets possèdent également plusieurs propriétés intrinsèques, parmi lesquelles trois sont
fondamentales et sont des conditions nécessaires pour qu'un langage de programmation
puissent prétendre à l'appellation de "langage objet" ou "orienté objet" [BOOCH 92],
[MULLER 98] :

1. L'encapsulation. Cette propriété correspond à la capacité que possèdent les objets à

protéger l'accès à leurs données internes. L'encapsulation introduit une séparation entre le
monde extérieur et l'objet, qui n'est accessible que par l'intermédiaire d'une "interface".
L'interface est composée d'une liste de comportements de l'objet qui peuvent être invoqués
par des objets externes. Cette liste ne contient que la description de la façon d'invoquer les
comportements - "ce que l'objet peut faire" - mais non la description de la réalisation des
comportements, par l'objet - "comment l'objet fait ce qu'il doit faire". En termes de
programmation, une interface permet donc d'occulter le code des méthodes de l'objet en ne
laissant apparaître que sa signature. Il y a donc deux intérêts évidents de l'encapsulation, le
premier est la sécurité, grâce à l'accès restreint aux données via l'interface. Le deuxième
intérêt est de donner aux objets la possibilité de modifier la façon dont ils réalisent leurs
comportements (changer les algorithmes) sans avoir à notifier, ni modifier les objets avec
lesquels ils interagissent.

2. L'héritage - la spécialisation et la généralisation. L'héritage est une propriété très

importante des objets, pour ne pas dire la propriété la plus importante. Comme son nom

112
 Chapitre 3 : Workflow et Systèmes Workflows avancés

l'indique, l'héritage permet de transmettre des caractéristiques - comportements et attributs

- d'une classe, dite "mère" à une autre classe, dite "fille". En terme de programmation, la
spécialisation s'effectue sans recopier le code correspondant. L'héritage implique une
relation de type entre la classe mère et ses classes héritière. En d'autres termes, si une
classe introduit un type "X" (le nom de la classe) alors toute classe héritière est également
un X. L'intérêt de la relation d'héritage est de permettre de réutiliser les propriétés d'une
classe au sein d'une autre classe en y ajoutant d'autres propriétés pour créer un nouveau
type dérivé. A l'opposé, si plusieurs classes présentent des attributs et des comportements
communs, alors il est possible de les factoriser au sein d'une classe plus générale, on parle
alors de généralisation. Enfin, notons que la correspondance de type fait qu'il est possible
de remplacer une instance d'une classe mère par celle d'une classe fille - c'est le principe
de substitution. Par contre, la réciproque n'est pas vraie.

3. Le polymorphisme. Le polymorphisme est une propriété en relation directe avec les deux
précédentes. En effet, si une classe fille introduit de nouvelles propriétés (attributs et
comportement) à la définition de la classe mère, elle peut également modifier la façon
dont elle réalise un comportement dont elle a hérité. Le polymorphisme est donc la
possibilité de définir au niveau de classes héritières, différentes réalisations d'un (ou de
plusieurs) comportement(s) hérité(s) d'une classe mère. Par exemple considérons la classe
d'une forme géométrique d'une application graphique, munie d'une méthode "dessiner()"
lui permettant de s'afficher à l'écran. Cette classe peut être dérivée en plusieurs sous-
classes, par exemple la classe des carrés et la classe des cercles. Etant donné que la forme
d'un cercle diffère de celle d'un carré alors il est légitime que la méthode dessiner() soit
redéfinie par chaque classe fille, pour afficher la forme adéquate à l'écran.

D'autres concepts sont également liés aux objets, que nous ne présentons pas ici, exceptions
faites pour les notions de "métaclasse" et de "réflexivité" dont nous avons précédemment
parlé :

4. Une métaclasse est une classe dont les instances sont également des classes. Les
métaclasses se situent à un niveau d'abstraction supérieur à celui des classes. Leur intérêt
est principalement de permettre de manipuler des classes - les instances des métaclasses -
en tant qu'objets. Si une classe est en même temps une instance, alors il est possible d'agir
sur ses propriétés lors de l'exécution. Le concept de métaclasse est supporté par peu de
langages objets (dont CLOS, Smalltalk et dans une moindre mesure, Java). Le concept de
métaclasse est particulièrement utile dans la mise en œuvre de la réflexivité.

5. La réflexivité. Dans le paragraphe 3.2.2, nous avons définit la réflexivité des systèmes
comme étant leur capacité à générer une représentation de leur état et de leur
comportement, et de les modifier dynamiquement. Nous apportons ici quelques notions
supplémentaires concernant les langages objets réflexifs. Un langage orienté objet réflexif
est un langage qui supporte la redéfinition dynamique de parties d'un programme en cours
d'exécution (écrit dans ce langage). On dit de ce langage qu'il est mutable [FOOTE 92],
par opposition aux langages orientés objets dit "extensible" [STROUSTRUP 1991], qui
supportent uniquement l'ajout de nouvelles propriétés au programme.

La programmation, l'analyse et la conception objets ont fait leurs preuves dans le domaine de
la production de logiciels flexibles et réutilisables. Les propriétés des objets - parmi lesquelles
celles que nous avons décrites, constituent la raison principale de ce succès. En effet,
l'encapsulation, l'héritage et le polymorphisme et la réflexivité sont les mécanismes

113
 Chapitre 3 : Workflow et Systèmes Workflows avancés

fondamentaux pour la mise en œuvre de la réutilisation et l'adaptation. Il est alors naturel de

penser transposer ces propriétés vers des domaines plus spécifiques, notamment le Workflow
et la gestion de processus. La façon dont ces concepts sont transposés et utilisés constitue la
réflexion développée dans le paragraphe suivant.

4.2 Workflow et Objets

Les objets sont utilisés pour développer des systèmes informatiques plus flexibles,
réutilisables et adaptables. Les systèmes Workflows étant eux-mêmes des systèmes
informatiques, alors il paraît évident qu'ils peuvent également bénéficier des avantages d'un
développement objet. Si à première vue le problème de transposition des concepts des objets
au Workflow ne semble pas se poser, il est important d'apporter une nuance. L'objectif à
atteindre par la transposition des propriétés des objets au Workflow, va plus loin que
l'implémentation des systèmes Workflow à l'aide de langages de programmation objets ou
orientés objet. Le problème qui se pose donc est de déterminer à quel niveau conceptuel la
notion d'objet va-t-elle être utilisée et intégrée ?

4.2.1 Intégration des objets au Workflow

Dans un article consacré à la spécialisation des workflows, C. Bussler [BUSSLER 97] apporte
une réponse à cette question, en définissant trois niveaux pour l'application des concepts des
objets dans le Workflow.

1. Le premier niveau est celui où le système Workflow est implémenté à l'aide d'un langage
objet ou orienté objet. Dans ce cas, le système est évolutif, c'est à dire que les objets
composant le système peuvent évoluer ou être réutilisés, notamment pour la production de
code plus performant. Cependant, les workflows, leur modèles et les processus ne sont pas
eux évolutifs et ne bénéficient donc en rien de l'apport des objets. La transposition Objet –
Workflow se fait donc uniquement au niveau du logiciel. Il est important de noter que le
fait que le système est évolutif n'entraîne pas qu'il est flexible au sens du Workflow, donc
par exemple qu'il fournit des moyens pour prendre en charge les exceptions.

2. Le deuxième niveau est déjà plus intéressant. Il consiste à utiliser les langages objets pour
l'implémentation du système Workflow mais également pour la définition des entités
Workflows. Celles-ci ont donc accès à toutes ou une partie des caractéristiques des objets,
fournis par le langage de programmation sous-jacent. La transposition Objet – Workflow
se fait donc à deux niveaux : le niveau logiciel et une partie du niveau conceptuel (le
niveau Workflow), puisqu'il est toujours nécessaire de passer par le langage de
programmation pour accéder aux mécanismes des objets. Par analogie avec les langages
de programmation, nous proposons de qualifier de "basé objet" les systèmes Workflows
de ce niveau.

3. Enfin, le troisième et dernier niveau consiste à intégrer véritablement les concepts des
objets au niveau Workflow proprement dit et non uniquement au niveau logiciel. Il s'agit
donc de doter les entités Workflows de mécanismes objets à la façon des langages de
programmation. En d’autres termes, l’idée est d’élaborer un langage Workflow objet ou
l’équivalent, on parle dans ce cas de "Workflow objet" ou "Workflow orienté objet". Un
workflow objet et les entités qui le composent, présentent donc les propriétés
d'encapsulation, d'héritage et de polymorphisme. Par conséquent, il doit être possible de
spécialiser des entités Workflows, de spécialiser des modèles Workflows ou d'obtenir des

114
 Chapitre 3 : Workflow et Systèmes Workflows avancés

comportements polymorphes selon la nécessité des cas. Quant au système Workflow, il

pourra être implémenté à l'aide d'un langage objet ou non.

Il existe donc une nuance importante entre orientation objet au niveau des langages
d'implémentation des systèmes Workflows, et orientation objet au niveau des langages de
modélisation Workflow. Dans ce dernier cas, les concepts des objets sont directement intégrés
au niveau du métamodèle Workflow. Parmi les trois niveaux présentés ci-dessus, seul le
dernier répond véritablement à cette contrainte, le deuxième niveau adoptant une approche
hybride.

4.2.2 Apports des objets au Workflow

Les paragraphes précédents nous ont appris qu'il est intéressant d'intégrer les propriétés des
objets dans le Workflow, afin de bénéficier de leurs propriétés d'adaptation, en créant des
Workflows objets et orientés objet. Cette notion en reste toutefois à un niveau conceptuel
assez général puisque nous n'avons pas encore décrit comment exploiter ces propriétés au
niveau de la modélisation de processus et de la gestion de workflow. Ce paragraphe propose
donc de descendre à un niveau plus concret, en indiquant la correspondance entre propriété
objet et bénéfice sur le Workflow.

[Link] L'encapsulation

Nous commençons part la première propriété des objets, l'encapsulation. Ainsi que nous
l'avons vu précédemment, l'encapsulation permet de séparer un objet, dans notre cas un objet
Workflow, en deux facettes : l'interface et la réalisation. Pouvoir réaliser cette séparation est
l'une des premières étapes de la flexibilité [HAN et al. 98] puisqu'elle permet au concepteur
d'un modèle Workflow d'isoler la description d'une tâche ("what to do") de la façon de la
réaliser ("how to do it") [JOERIS 00]. A l'instar de la programmation objet, il est donc
possible au concepteur d'un workflow de modifier la façon de réaliser une tâche sans
perturber le modèle du processus qui lui reste valide. Par exemple, il est possible lors de
l'exécution, de choisir la réalisation la plus valable pour une tâche en fonction du cas qui se
présente. Un exemple de mise en œuvre de l'encapsulation est donné dans [JOERIS 00] et
[JOERIS et al. 98]. Une tâche est définie à l'aide de deux parties complémentaires :
définition « context-
La partie indépendante du contexte (context définition « context-free » dependent »
d’une tâche d’une tâche
free) dans lequel la tâche va être réalisée (le
cas Workflow), et la partie réalisation, qui peut ECA
varier en fonction du contexte (context ECA Contextuel
par
dependent). Dans la première partie, une tâche défaut Remplace
est décrite par un diagramme d'états / Le ECA
Par défaut
transitions, sur lequel sont reportés tous les
Attributs de la tâche
états que peut prendre la tâche et les transitions
(activités ou événements) qui la font passer
dans ces états. Un ensemble de règles ECA
décrivant le comportement générique de la Figure III.18 - Exemple d"encapsulation :
tâche est également associé. Il peut être utilisé comportement "context free" et "context
par défaut. dependent".

La deuxième partie de la tâche correspond à la réalisation proprement dite. Elle consiste en

plusieurs ensembles de règles ECA, qui seront associé à la tâche selon le cas présent. Il est

115
 Chapitre 3 : Workflow et Systèmes Workflows avancés

possible de modifier chaque ensemble de règles ou de choisir celui qui correspond le mieux
au cas traité. Remarquons qu'il ne s'agit pas ici de choix multiples mais bien d'encapsulation.
En effet, dans le cas de choix multiples, plusieurs tâches différentes sont candidates pour
succéder à une tâche lors de l'exécution du processus. A l'opposé, dans notre exemple
précédent, nous n'avons qu'une seule tâche candidate mais plusieurs façons possibles de la
réaliser.

[Link] L'héritage

Il est évident que l'intérêt principal de l'héritage est de permettre la réutilisation de modèles
Workflows et d'entités Workflows. Cette possibilité est très intéressante puisqu'elle donnerait
aux concepteurs de workflows, la possibilité de récupérer la définition d'un workflow existant,
pour en créer de nouveaux. Spécialiser des workflows peut se faire de deux façons, qui
dépendent du niveau d'intégration des propriétés objets. Si le Workflow est basé objet, alors
l'héritage se fait par l'intermédiaire des mécanismes du langage de programmation servant à
implémenter le système. Il s'agit donc de l'héritage de classes composant un workflow. Dans
le cas du workflow objet, un mécanisme d'héritage est intégré dans toute entité Workflow,
modèle compris. L'héritage se fait donc directement au niveau du Workflow, sans passer
explicitement par le langage de programmation sous-jacent. A titre d'illustration, nous
reprenons une partie d'un exemple tiré de [BUSSLER 97]. L'article présente un langage de
script, permettant de modéliser des workflows mais surtout, proposant des mécanismes
d'héritage de types de workflows (workflow type inheritence).

Dans l'exemple ci-contre, un workflow A est WORKFLOW_TYPE A ( )

créé à l'aide de la syntaxe adéquate. Ce SUBWORKFLOWS
a : step_a;
workflow est composé de sous-processus : a, b : step_b;
b, c, d dont le flux d'exécution est donné par c : step_c;
la section "CONTROL FLOW". Celle-ci nous d : step_d
END_SUBWORKFLOWS
renseigne que b et c sont exécutés en parallèle CONTROL FLOW
une fois que a est réalisé et enfin, d est sequence (step_a,
exécuté quand b et c terminent (et non b ou c). sequence (parallel (step_b, step_c), step_d)
END_CONTROLFLOW
END_WORKFLOW_TYPE
Le workflow B est défini comme étant un
sous-type de A, donc B hérite du workflow A. WORKFLOW_TYPE B ( ) SUBTYPE_OF A()
CONTROL FLOW
Le langage utilisé dans l'exemple permet - cf_1 : sequence (step_a, step_b);
grâce au mot clé "SUBTYPE_OF" - de créer cf_2 : sequence (step_b, step_c);
le workflow B à partir de A, sans avoir à cf_3 : sequence (step_c, step_d);
END_CONTROLFLOW
recopier la partie qu'ils ont en commun. On END_WORKFLOW_TYPE
peut constater que l'héritage est directement
réalisé grâce au langage de modélisation et WORKFLOW_TYPE : déclaration d’un nouveau type
non par l'intermédiaire du langage SUBTYPE_OF : opérateur d ’héritage
SUBWORKFLOWS : workflows composants (sous processus)
d'implémentation du système. Par ailleurs, B CONTROL FLOW : flux de contrôle des sous processus - chronologie
d ’exécution
redéfinit à son niveau la section de contrôle de cf_i : identifiant du flux
flux, en modifiant l'ordre dans lequel les sous- sequence : exécution d ’un flux sequentiel
parallel : exécution d ’un flux parallèle
processus composants vont s'exécuter. On a END_mot_clé : Fin de la section concernée
( ) : liste d'arguments éventuels du workflow
donc en même temps un exemple de
polymorphisme Workflow.
Figure III.19 - Exemple d'héritage de
workflows

116
 Chapitre 3 : Workflow et Systèmes Workflows avancés

La spécialisation des workflow - et donc des processus - pose un problème intéressant,

soulevé par [WYNER et al. 95]. En conception objet "traditionnelle", quand une classe
spécialise une autre classe, elle en récupère les attributs et les comportements, qu'elle peut
modifier ("surcharger") à son niveau. En général, la classe fille ajoute de nouveaux attributs et
de nouveaux comportements à ceux dont elle a hérité et il est très rare (voir impossible)
d'utiliser l'héritage pour réduire le nombre de propriétés d'une classe. Il est important de faire
ici la distinction entre réduire le nombre de propriétés et restreindre (ou contraindre) les
comportements de la classe héritière. En effet dans ce dernier cas, il s'agit d'ajouter des
contraintes qui limitent les possibilités de la classe fille. Par exemple, considérons la classe
"Carte_Visa_Premier" et imaginons sa classe fille "Carte_Visa_Premier_Join_the_Club". On
suppose que l'introduction de cette carte est une opération commerciale visant à attirer une
partie des détenteurs d'une carte visa simple vers le club des "privilégiés". La nouvelle carte
offre les mêmes fonctionnalités et avantages que la carte "Visa_Premier" mais y apporte
toutefois quelques contraintes. Ainsi, les propriétaires des instances de la première classe ont
la possibilité de retirer 2000 Euros par semaine et sont autorisés à avoir un découvert de 1500
Euros sur leur compte courant. Les possesseurs de la carte "Visa_Premier_Join_The_Club"
quant à eux, sont limités à 1800 Euros par semaine et ne peuvent avoir un découvert excédant
1300 Euros. On voit bien que dans ce cas, les comportements des instances des deux cartes
sont similaires, sauf qu'ils ont été contraints dans le cas de la carte visa simple.

Dans un article consacré à la spécialisation des modèles de processus [WYNER et al. 95],
[Link] et J. Lee posent la question suivante : la spécialisation d'un processus est-elle un
mécanisme qui permet d'augmenter la classe fille par rapport à la classe mère ou est-il plutôt
un moyen de la limiter ? Selon ces spécialistes, la bonne réponse est la deuxième : la
spécialisation d'un processus résulte en un nouveau processus dont les composants sont un
sous-ensemble des composants du processus père. Pour G. Wyner et J. Lee, la spécialisation
de processus est une opération qui crée un processus à partir d'un cas général pour l'appliquer
à un cas particulier. Cette définition est discutable. En effet, ces auteurs considèrent qu'un cas
général couvre plus d'aspects qu'un cas particulier. En d'autres termes, un processus père peut
traiter l'ensemble des applications possibles justifiant le processus. A l'opposé, un processus
fils ne peut traiter qu'une seule application. Par exemple, considérons le processus de gestion
des repas dans un restaurant. Ce processus peut prendre des formes différentes en fonction du
type de restaurant, trois dans le cas de notre exemple :

On voit bien dans la figure Restaurant Prendre Préparer Servir Encaisser

Commande
III.20 que les activités
composant les processus
Fast food Préparer Prendre Servir Encaisser
sont les mêmes, mais que commande
leur ordonnancement diffère
selon le cas. Pour construire Cantine Encaisser Prendre Préparer Servir
un restaurant flexible, on commande
peut généraliser les trois Restaurant Encaisser
processus spécifiques pour flexible –
généralisation
élaborer un modèle de
processus plus général, qui Servir Prendre
commande
peut prendre en compte
l'ensemble des cas possibles, Préparer
comme le montre la figure
ci-contre.
Figure III.20 – Généralisation / spécialisation de processus

117
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Nous estimons de notre part que la spécialisation de processus n'est pas un mécanisme de
limitation. Au contraire, l'héritage et la spécialisation sont des moyens d'enrichir un modèle
initial par de nouvelles propriétés, de modifier ou de particulariser son comportement.

[Link] Le polymorphisme

Le polymorphisme est une propriété très intéressante pour le Workflow. En effet, comme
nous avons pu le voir dans l'exemple de la figure III.19, le polymorphisme permet à des
workflows héritiers de modifier une partie des propriétés qu'ils ont récupérées de leur
workflow père. Donc, outre la possibilité de réutiliser des modèles, offerte par l'héritage, le
polymorphisme introduit un "plus" de flexibilité en rendant possible la personnalisation des
comportements hérités. Au niveau d'un workflow, cela peut par exemple se traduire par une
modification du flux de contrôle des tâches, comme nous l'avons vu précédemment. Une autre
application très importante du polymorphisme, se traduit pat la possibilité de réaliser une
activité d'un workflow de différentes façons, selon le contexte d'exécution ou l'acteur qui en
est responsable. C'est en partie le cas de l'exemple de la figure III.18. La possibilité d'adopter
un comportement selon le contexte peut se généraliser à l'ensemble des composants d'un
workflow. Dans le chapitre suivant, nous reviendrons plus longuement sur les possibilités
offertes par le polymorphisme (ainsi que les deux autres propriétés) appliqué au Workflow.
Nous étudierons également la façon dont la réflexivité peut être utilisée pour concevoir des
systèmes Workflow adaptables.

Conclusion
La recherche dans le domaine de la flexibilité du Workflow est un domaine en forte
expansion. Les besoins en systèmes adaptables et flexibles sont très présents dans les
entreprises, étant donné le contexte de remise en cause perpétuel de leurs processus métiers,
du au besoin de compétitivité et aux contraintes auxquelles elles sont soumises. Plusieurs
systèmes commerciaux et expérimentaux ont apporté des solutions plus ou moins
convaincantes à ce besoin de flexibilité. Le problème de la gestion des exceptions a en
particulier été traité dans un grand nombre de systèmes expérimentaux dont nous avons
précédemment parlé, tels WIDE, OPERA ou WAMO. D'autres systèmes, également issus des
deux milieux (recherche et industrie), ont approfondi le problème de l'adaptabilité.
Néanmoins dans la plupart des cas, des lacunes dans les approches limitent l'intérêt des
solutions apportées. Nous nous sommes intéressés plus particulièrement à la mise en œuvre de
l'adaptabilité dans les modèles et les systèmes Workflow, en privilégiant l'approche par
métamodèle, basée sur le concept des Workflows objets.

Dans le chapitre suivant, nous présentons un framework objet pour Workflows adaptables. Le
framework propose une approche originale pour la conception de modèles et de systèmes
Workflows flexibles et adaptables.

118
 Chapitre 3 : Workflow et Systèmes Workflows avancés

Bibliographie
[ALONSO et al. 97] G. Alonso, D. Agrawal, A. El Abbadi, C. Mohan. "Functionality and
Limitations of Current Workflow Management Systems". IEEE Expert,
Vol.2, n°5. Septembre-Octobre 1997.
[BARESI et al. 99] L. Baresi, F. Casati, S. Castano, S. Ceri, M.G. Fugini, I. Mirbel, B. Pernici.,
G. Pozzi. "WIDE Workflow Development Methodology". Report n°3027-6.
ESPRIT Project 20280. 3 Mars 1999.
[BUSSLER 97] C. Bussler. "Towards Workflow Type Inheritance". Proc. of the OOPSLA
'98 Workshop on Implementation and Application of Object Oriented
Workflow Systems. Vancouver, BC, Canada. Octobre 1998
[BOLCER et al. 96] G.A. Bolcer, R.N. Taylor. "Endeavors : A Process System Integration
Infrastructure". International Conference on Software Process (ICSP4).
Brighton, U.K.2-6 Décembre 1996.
[BOOCH 92] G. Booch. "Conception Orientée Objet et applications. Addison-Wesley.
1992.
[CASATI 96] F. Casati, S. Ceri, B. Pernici, G. Pozzi. 'Deriving Active Rules for Workflow
Enactment". DEXA Database and Expert Systems Applications. Zurich,
Suisse. 9-13 Septembre 1996.
[CASATI 98] F. Casati. "Approaches to Handling Exceptions in Workflow". CSCW-
98,Workshop Towards Adaptive Workflow Systems Seattle, WA. 14
novembre 1998.
[CASATI et al. 98] F. Casati, S. Castano, M. G. Fugini, I. Mirbel, B. Pernici. "WERDE: A
Pattern-Based Tool for Exception Design in Workflows". SEBD, Sesto
Convegno Nazionale su "Sistemi Evoluti Per Basi di Dati".
Ancona, Italie. 23-25 juin 1998.
[CHIU et al. 98] D.K.W. Chiu
, K. Karlapalem, Q. Li. "Exception Handling with Workflow Evolution in
ADOME-WFMS : a Taxonomy and Resolution Techniques". CSCW-
98,Workshop Towards Adaptive Workflow Systems Seattle, WA. 14
novembre 1998.
[DEITERS et al. 98] W. Deiters, T. Goesmann, K. Just-Haln, T. Löffeler, R. Rolles. "Support for
exceptions handling through workflow management systems". CSCW-
98,Workshop Towards Adaptive Workflow Systems Seattle, WA. 14
novembre 1998.
[DOURISH 95] P. Dourish. "Developing A Reflective Model of Collaborative Systems".
ACM Transactions on Computer-Human Interactions". Mars 1995. pp.40-
63.
[DOURISH 96] P. Dourish. "Open Implementation and Flexibility in CSCW Toolkits".
Mémoire de Thèse pour l'obtention du titre de "Doctor of Philisophy of the
University of London". Department of Computer Science. University
College London. Juin 1996.
[ECKEL 97] B. Eckel. "Thinking in Java". 1st Edition. Prentice-Hall. 1997.
[ECKEL 99] B. Eckel. "Thinking in Patterns with Java". [Link]
1999.
[ECKEL 00] B. Eckel. "Thinking in C++". Vol.1. 2nd Edition. Prentice-Hall. 2000.
[EDER et al. 95] J. Eder, W. Liebhart. "The Workflow Activity Model WAMO". Proc. of the
3rd Int. Conf. on Cooperative Information Systems (CoopIS), Vienna,
Austria, Mai 1995.
[EDER et al. 98] J. Eder, W. Liebhart. "Contributions to Exception Handling in Workflow
Management". Proc. EDBT Workshop on Workflow Management Systems,
Valencia, 1998. pp 3-10.
[EDMOND et al. 98] D. Edmond, A.H.M Hofstede. "Achieving Workflow Adaptability by means
of Reflection". CSCW-98,Workshop Towards Adaptive Workflow Systems
Seattle, WA. 14 novembre 1998.
[EDMOND 00] D. Edmond. "Applications of Reflection for Cooperative Information
Systems". Mémoire de Thèse pour l'obtention du titre de "Doctor of
Philisophy". Faculty of Information Technology, Queensland University of
Technoloy, Australia. Juillet 2000.

119
 Chapitre 3 : Workflow et Systèmes Workflows avancés

[FOOTE 90] B. Foote. "Object-Oriented Reflective Metalevel Architectures:Pyrite or

Panacea?". Position Paper for the ECOOP/OOPSLA '90 Workshop
on Reflection and Metalevel Architectures. Ottawa, Canada 21-25 Octobre.
1990.
[FOOTE 92] B. Foote. "Objects, Reflection, and Open Languages". Workshop on Object-
Oriented Reflection and Metalevel Architectures ECOOP '92. Utrecht, The
Netherlands. 29 juin - 3 juillet 1992.
[FROMENT et al. 89] B. FROMENT, J.J. LESAGE. "Productique : les techniques de l'usinage
flexible". 2ème édition. Editions Dunod. 1989
[GEORGAKOPOULOS et al. 95] D. Georgakopoulos, M. Hornick, A. Sheth, "An Overview of Workflow
Management : From Process Modeling to Workflow Automation
Infrastructure", Distributed and Parallel Databases, An International Journal,
3, 1995.
[HAGEN et al. 98] C. Hagen, G. Alonso. "Exception Hnadling in Process Support Systems".
Technical Report n° 29. ETH Zürich, Dpartement of Computer Science.
[HAN et al. 98] Y. Han, A. Sheth, C. Bussler. "A Taxonomy of Adaptive Workflow
Management". CSCW-98,Workshop Towards Adaptive Workflow Systems
Seattle, WA. 14 novembre 1998.
[HACHETTE 99] Hachette -AUPELF-UREF. Dictionnaire francophone en ligne.
[Link]
[HORN et al. 98] S. Horn, S. Jablonski. "An Approach to Dynamic Instance Adaption in
Workflow Management Application". CSCW-98,Workshop Towards
Adaptive Workflow Systems Seattle, WA. 14 novembre 1998.
[HITOMI et al. 98] A. S. Hitomi, D. Le. "Endeavors and Component Reuse in Web-Driven
Process Workflow". Proc. of the California Software Symposium.. Octobre
1998.
[JOERIS 00] G. Joeris. "Decentralized and Flexible Workflow Enactment Based on Task
Coordination Agents". CAISE'OO, Workshop on Agent Oriented
Information Systems. Stockhlom, Sweeden. 5-6 juin 2000.
[JOERIS et al. 98] G. Joeris, O. Herzog. "Towards Object-Oriented Modeling and Enacting of
Processes". TZI Technical Report 7/98, Center for Computing Technologies,
University of Bremen. 1998.
[KAMMER et al. 98] P.J. Kammer, G.A. Bolcer, "Techniques for Supporting Dynamic and
Adaptive Workflow". Technical Report UCI-ICS-99-03. University Of
California Irvine. Janvier 1999.
[MEIJLER et al. 98] T.D. Meijler, H. Kessels, C. Vujist, R. le Comte. "Realising Run-time
Adaptable Wokflow by means of Reflectionin the Baan Workflow Engine".
CSCW-98,Workshop Towards Adaptive Workflow Systems Seattle, WA. 14
novembre 1998.
[MEYER 88] B. Meyer. "Applying "Design by Contract". IEEE Computer 25(10): 40-51.
1992.
[MEYER 95] B. Meyer. "Eiffel: An Overview of the Language and Method". Appendix D
of ISE Eiffel: The Environment. 1995.
[MQSeries 99] MQSeries. "MQSeries product Family". [Link] 1999.
[MULLER 98] P.A. Muller. "Modélisation Objet avec UML". Eyrolles 98.
[OUKSEL et al. 98] A. Ouksel, J. Watson. "The Need for Adaptive Workflow and What is
Currently available on the Market". CSCW-98,Workshop Towards Adaptive
Workflow Systems Seattle, WA. 14 novembre 1998.
[PURDON et al. 95] D. Muller, K. Sharma. "Workflow Exception Handling".
[Link]
[REICHERT et al. 98] M. Reichert, C. Hensinger, P. Dadam. "Supporting Adaptive Workflows in
Advanced Application Environments". Proc. of the EDBT Workshop on
Workflow Management Systems. Valencia. Italie. Mars 1998. pp. 100-109.
[RIEHLE et al. 96] D. Riehle, H. Züllighoven. "Understanding and Using Patterns in Software
Development". Theory And Practice of Object Systems (TAPOS). Vol. 2,
n°1. Novembre 1996. pp. 3-13.
[SIEBERT 97] R. Siebert. "An Open Architecture For Adaptive Workflow Management
Systems". Third Biennial World Conference on Integrated Design and
Process Technology, Vol.2 - Issues and Applications of Database
Technology. Berlin, Juillet 1998. pp 79-85.

120
 Chapitre 3 : Workflow et Systèmes Workflows avancés

[SHETH 97] A. Sheth. "From Contemporary Workflow Process Automation to Adaptive

and Dynamic Work Activity Coordination and Collaboration". Workshop on
workflows in Scientific and Engineering Applications, Toulouse,
France.1997.
[SOBEL et al. 96] J.M. Sobel, D.P. Friedman. "An Intorduction to Reflection Oriented
Programming". Reflection'96. San Fransisco, USA. 22 avril 1996.
[STROUSTRUP 91] B. Stroustrup. "The C++ Programming Language". Second Edition.
Addison-Wesley. 1991.
[WAINER et al. 95] J. Wainer, M. Weske, G. Vossen, C. Medeiros. "Scientific workflow
systems". NSF Workshop on Workflow and Process Automation, USA.
1996.
[WESKE et al. 96] M. Weske, G. Vossen, C. Medeiros. "Scientific Workflow Management :
Architecture and Applications". Fachbericht Angewandte Mathematik und
[Link]ät Münster. Mars 1996.
[WIDE 97] WIDE. "The WIDE Workflow model and Language". Report n°4080-2.
ESPRIT Project 20280. 31 Octobre 1997.
[WYNER et al. 95] G. Wyner, J. Lee. "Applying Specialization to Process Models". Proc. of the
Conference on Organizational Computing Systems. Milpitas, California:
Association for Computing Machinery. 1995.

121
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Chapitre IV
2FLOW - Framework pour Workflows Objets Flexibles

1. Objectifs du Framework
La flexibilité des systèmes Workflows est un des objectifs prioritaires de la nouvelle
génération de systèmes. Si elle se décline sous deux aspects principaux : la gestion des
exceptions et l'adaptabilité, ce dernier aspect reste encore à approfondir. En effet, le problème
de la gestion des exceptions a largement été traité dans la recherche, notamment parce qu'il
peut se baser sur les fondements posés par la Gestion des Transactions, les Bases de Données
et le Génie Logiciel. Côté adaptabilité, bien que plusieurs recherches aient été initialisées et
soient toujours en cours, le champ "d'investigation" reste encore ouvert. Plusieurs solutions et
approches ont été proposées, nous en avons décrit les principales dans le chapitre précédent.
L'une de celles-ci, dite du Workflow Objet ou Workflow Orienté Objet, est néanmoins plus
prometteuse. Cette approche, qui prend ses racines dans le Génie Logiciel, a globalement pour
but d'intégrer les concepts des objets informatiques au sein du domaine du Workflow, en
particulier au niveau des modèles et des métamodèles Workflows.

Nous avons choisi d'approfondir l'approche Workflow Objet basée sur les métamodèles, pour
ses capacités de contribuer à l'adaptabilité des Workflows. Le choix de l'approche objet s'est
imposé de lui-même. En effet, l'intérêt de l'utilisation des objets dans la conception et
l'implémentation d'applications informatiques évolutives n'est plus à démontrer. La
transposition des propriétés de l'approche objet aux concepts du Workflow nous semblait
donc une approche "naturelle" pour la résolution d'un ensemble de problèmes de la même
catégorie : évolutivité - flexibilité - adaptabilité. Notre travail de thèse s'est donc orienté vers
la conception et l'élaboration d'un framework pour Workflows objets adaptables, appelé
2FLOW (Flexible Framework for Object Workflows).

Un framework, encore appelé en français "charpente", "cadre" ou "architecture", est un

ensemble de classes extensibles d'objets en collaboration, qui définit une architecture
logicielle réutilisable et extensible [DEMEYER 97]. Dans un très bon livre sur la conception
et l'utilisation de patterns, B. Eckel [ECKEL 99] définit un framework comme étant un
ensemble de classes que l'on peut spécialiser et dont on réutilise le plus gros du code, en
redéfinissant quelques méthodes afin de les adapter aux besoins d'une application spécifique.
Ces deux définitions sont complémentaires car elles expriment deux aspects fondamentaux
d'un framework :

§ Le fait qu'un framework fournit des objets de base, aux propriétés et aux
comportements bien définis qu'il est possible de réutiliser tels quels ou d'adapter,
toujours dans le cadre de l'architecture globale.

§ Le fait qu'il existe des relations structurelles et comportementales entres les classes
d'un framework, donc une architecture de base qui définit un cadre d'action. Par
conséquent, un framework n'est pas une bibliothèque d'objets car il définit à l'opposé

121
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

des bibliothèques de classes, des relations, des interactions entre des instances de
classes [MANHES 98].

Enfin, un troisième aspect fondamental des frameworks est le fait d'être dédié à un type
d'application donné. Ainsi, il existe des frameworks pour le développement d'applications
multimédia, pour des applications de gestion, etc. Pourquoi ne pas concevoir alors de
framework pour la construction de systèmes et de modèles Workflows ?

La conception de notre framework vise trois objectifs principaux que nous classons par
ordre croissant d'importance :

1. Fournir un cadre de modélisation Workflow, en proposant un métamodèle – définit par

les classes composant le framework et les relations existantes entre elles ainsi que par
une méthode de modélisation de Workflows. Nous avons choisi UML pour la
modélisation du framework et pour la modélisation des workflows issus du
framework. Le choix d'UML se justifie pour deux raisons :

§ En premier lieu, UML est la notation standardisée de modélisation Objet, ce qui

justifie l'intérêt du choix d'une notation largement répandue.

§ La deuxième raison est basée sur la première mais est la plus importante. En effet,
UML est adoptée par un grand nombre de spécialistes du monde Objet mais
également par des spécialistes d'autres disciplines. Par conséquent, UML peut
jouer un rôle d'intégration important entre les équipes des différents services d'une
entreprise, en fournissant un langage commun. En particulier, nous voyons
l'utilisation d'UML comme un bon moyen de réunir les vues des spécialistes des
processus et celles des développeurs Workflows.

Nous reviendrons plus en détail sur l'utilisation d'UML dans un paragraphe de ce

chapitre dédié à la méthode de modélisation proposée. Signalons toutefois que notre
but n'est pas de proposer une autre méthode de modélisation Workflow. En effet, de
par sa nature de framework, 2FLOW s'inscrit plus dans un niveau intermédiaire entre
la modélisation et l'implémentation de workflows. La méthode que nous proposons
nous sert en tant qu'outil dans le cade de l'utilisation du framework mais non en tant
que nouvelle théorie de la modélisation.

2. Le deuxième objectif du framework est de fournir un ensemble de composants (les

classes du framework), munis des comportements de base nécessaires pour permettre
la construction de workflows par "assemblage" de composants.

3. Enfin et surtout, le framework doit mettre en œuvre l'adaptabilité et la réutilisation,

grâce à la spécialisation des classes du framework, hors exécution et en cours
d'exécution des workflows.

2FLOW étant implémenté en Java, nous verrons que nous utilisons ce même langage
pour les besoins de customisation (pour reprendre l'expression anglo-saxonne), de
réutilisation et d'adaptation des workflows construits à partir du framework. Le choix
de Java se justifie non pas par un phénomène de mode mais pour deux raisons
majeures :

122
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ Les propriétés très intéressantes du langage et la richesse de ses outils.

§ Permettre aux concepteurs Workflows d'utiliser un langage bien maîtrisé au lieu
d'avoir à réapprendre un autre langage propriétaire - celui du système Workflow,
comme c'est le cas des systèmes commerciaux ou issus de la recherche.

Nous développerons bien entendu plus en détail ces choix et leur intérêt dans les paragraphes
suivants, notamment dans celui consacrés à la mise en œuvre de la flexibilité.

2. Description du framework
Le framework (fig. IV.1) propose un ensemble de classes en relation, correspondant toutes à
des entités constitutives de Workflow. Nous nous sommes initialement basés sur le
métamodèle de la "Wokflow Management Coalition" (WfMC), présenté dans le chapitre 2.
Ce métamodèle a été enrichi par la suite par des éléments qui nous semblent fondamentaux
pour la modélisation Workflow, ainsi que par d'autres éléments plus spécifiques à notre
framework. La figure ci-dessous donne une vue globale du framework et de ses composants,
qui seront décrits, avec leurs relations, dans les paragraphes suivants.

Dans ce chapitre, nous adoptons une approche progressive dans nos explications sur le
framework. Nous donnons d'abord une description de sa structure suivie d'explications
techniques et détaillées sur son fonctionnement. Par la suite, nous présentons la mise en
œuvre de la flexibilité dans 2FLOW, puis nous décrivons la méthode de modélisation que
nous proposons. Enfin nous terminons ce chapitre par la comparaison de 2FLOW avec
d'autres solutions workflows flexibles.

Externe

Figure IV.1 - Vue Globale du Framework - 2FLOW

123
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

2.1 Vue fonctionnelle

La vue fonctionnelle d'un workflow, nous le
*
rappelons, donne la description de la Processus
structure d'un workflow, c'est à dire sa *
décomposition en fonctions (sous-
workflows - ou sous-processus, et activités).
Processus_Générique Processus_Externe
Dans 2FLOW, un processus est représenté
par la classe "Processus" et peut être lui-
même composé d'autres processus (des sous-
*
processus) et/ou d'activités (fig. IV.2). Activité
Celles-ci sont des unités de travail
atomiques, donc non décomposables, ainsi
que nous l'avons défini au chapitre 2. Figure IV.2 - Vue fonctionnelle de 2FLOW

La classe "Processus" se spécialise en deux sous-classes, respectivement "Processus_Externe"

et "Processus_Générique".

1. La classe "Processus_Externe" indique une séparation entre deux processus. Cette

séparation peut être géographique ou technologique. Dans le premier cas, la séparation
signifie que le processus externe n'est pas géré sur le même site que le workflow en cours.
Dans le deuxième cas, cela indique que le processus n'est pas géré par un système
Workflow du même type que celui du workflow en cours. L'intérêt d'une telle classe se
situe à deux niveaux :

§ Au niveau de la modélisation, cette classe permet de représenter le workflow externe à

l'aide d'un seul élément générique, en faisant abstraction de sa structure interne.

§ Le framework rappelons-le, propose de fournir à des concepteurs de workflows, des

composants munis de comportements de base. Le deuxième intérêt est donc de mettre
à la disposition de ces concepteurs, une classe qui peut servir d'interface entre le
processus 2FLOW et un processus quelconque externe. La classe Processus_Externe
encapsule les protocoles de communications entre processus et se charge donc de
définir quels sont les objets à transmettre au processus qu'elle représente, et quels sont
les objets que l'on doit en récupérer. De plus, la classe Processus_Externe contient un
attribut permettant de décrire l'emplacement (sous forme d'URL) du processus distant,
ainsi que la commande qui permet, au besoin, de lancer son exécution. Le
référencement d'un processus externe (géographiquement distant) s'inspire d'une
technique mise en œuvre dans le système Workflow Endeavor [BOLCER 98],
[HITOMI et al. 98], et sur laquelle nous reviendrons par la suite. Globalement cette
technique consiste à référencer dans une classe (au moyen d'une URL), un fichier
décrivant le comportement de la classe.

2. La classe "Processus_Générique" permet de mettre en œuvre le principe de modélisation

tardive dont nous avons parlé dans le chapitre précédent. Cette classe peut se substituer à
tout processus incomplet, afin de valider le modèle Workflow. En d'autres termes, il est
possible de construire un modèle Workflow exécutable, même si toutes ses composantes
ne sont pas connues dès le départ. Il s'agit dans un premier temps de remplacer la partie
manquante par la classe Processus_Générique, qui devra ensuite être associée à un vrai
processus au moment de l'exécution.

124
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Enfin, la classe "Activité" correspond à une activité du processus modélisé. Dans 2FLOW,
nous adoptons une approche du concept d'activité légèrement différente de celle des autres
systèmes Workflow. Nous la décrivons en détail dans la partie consacrée à la vue
organisationnelle.

2.2 Vue comportementale

La vue comportementale d'un workflow correspond à la modélisation de la dynamique du
processus, c'est à dire la façon dont les activités sont chronologiquement exécutées. Cette vue
s'intéresse en particulier à définir le contrôle de flux du processus, qui s'exprime globalement
sous forme de séquences, de mises en parallèle, de boucles et de branchements.

Activité BCF
*
*
émet

* notifie
Événement
S_BCF B_BCF P_BCF

notifie

Expression_Logique

For_BCF While_BCF

Fin_Activite Exception

Figure IV.3 - Vue comportementale de 2FLOW

Dans 2FLOW, nous représentons la dynamique du processus à l'aide de deux moyens

complémentaires : les événements et les "expressions logiques" d'une part, et les "blocs de
contrôle de flux" d'autre part.

2.2.1 Evénements et expressions logiques

1. Les événements : la notion d'événement est fondamentale en Workflow, bien que certains
systèmes et métamodèles Workflows ne lui accordent pas toute sa dimension. Ainsi par
exemple, plusieurs systèmes et métamodèles ne permettent pas de créer des types
d'événements autres que ceux signalant la fin d'une activité. Nous rappelons qu'un
événement est un fait ayant lieu lors de l'exécution du processus et dont l'occurrence
(seule ou conjointement avec d'autres événements) permet de déclencher une activité.
Remarquons de plus qu'un événement ou un groupe d'événements sert de déclencheurs,
donc qu'il signifie à l'activité qu'elle doit s'exécuter. Toutefois, l'événement ne s'occupe
pas de déterminer l'ordre dans lequel les activités s'exécutent, c'est à dire le contrôle de
flux.

2FLOW introduit une classe "Evénement" de base, qui correspond à tout événement
pouvant avoir lieu au cours d'un processus. Un objet de la classe Evénement est généré par
une activité du workflow ou peut être associé à un fait externe, pour lequel on souhaite
réagir de façon appropriée.

125
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

La classe Evénement est également spécialisée en une classe "Exception", qui sert à
représenter les exceptions pouvant avoir lieu au cours de l'exécution d'un workflow. La
gestion des exceptions est développée dans le paragraphe dédié à la mise en œuvre de la
flexibilité dans 2FLOW.

En général, la dynamique d'un workflow est générée par la production et la consommation

d'événements. Toutefois, les activités sont souvent uniquement déclenchées après la fin
d'une ou de plusieurs activités précédentes. Aussi, les événements marquant la fin des
activités sont suffisants pour générer le flux d'un processus. Ils sont toutefois plus
implicites qu'explicites, c'est à dire qu'il n'est pas nécessaire de les représenter dans un
modèle de workflow pour en permettre la compréhension. En général, il suffit de lier les
activités entre elles sur le modèle pour exprimer que chaque activité est déclenchée par la
fin de celle ou celles qui la précèdent. Nous avons introduit dans 2FLOW, une classe
"Fin_Activite" (plus véritablement "EndOfActivity"), afin de permettre aux activités de
signaler à celles qui les suivent qu'elles sont achevées. Cette classe n'est pas à la charge
des concepteurs lors de la modélisation car elle est automatiquement instanciée par toute
activité qui prend fin.

2. Les expressions logiques : nous avons dit dans le paragraphe précédent qu'il était possible
que plusieurs événements soient à l'origine du début d'une activité. Dans les systèmes et
les modèles Workflows se basant sur des formalismes ou dans certaines des méthodes
décrites au chapitre 2 (telle ARIS), le contrôle de flux est en général exprimé à l'aide
d'opérateurs de contrôle permettant d'exprimer certains choix sur l'association des
événements et des activités.

La modélisation Workflow distingue en général six type d'opérateurs : la jonction en

entrée d'activités (AND Join), des opérateurs de jonction en sortie d'activités (AND split),
des disjonctions non exclusives ou exclusives, en entrée et en sortie (respectivement OR
Join, OR Split, XOR Join, XOR Split). La figure IV.4 en résume le fonctionnement :

A1 AND Join AND Split A2

A3 A1

A2 A3

A3 ne peut se réaliser que si A1 et A2 ont terminé La réalisation de A1 entraîne la réalisation de A2 et A3

A1 OR Join OR Split A2
A3 A1

A2 A3

A3 peut se réaliser si A1 et A2 ou si l ’un des deux est terminé La réalisation de A1 entraîne la réalisation de A2 ou de A3
ou des deux simultanément

A1 XOR Join XOR Split A2

A3 A1

A2 A3

A3 peut se réaliser si A1 ou A2 est terminé La réalisation de A1 entraîne la réalisation de A2 ou de A3

Ax Activité / Remarque: En entrée, les activités peuvent être remplacées par des événements

Opérateur de type “ SPLIT ”

Opérateur de type “ JOIN ”

Figure IV.4 - Opérateurs usuels de contrôle de flux

126
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Un inconvénient de ces opérateurs est qu'ils combinent deux aspects : l'aspect

événementiel - les événements qui déclenchent les activités - et l'aspect contrôle de flux
proprement dit - séquence, parallélisme, boucles, etc. L'aspect événementiel est explicite
puisqu'il est formalisé par les activités et les événements reportés sur le modèle. A
l'opposé, l'aspect contrôle de flux est implicite puisqu'il se déduit du modèle. Par exemple
un "AND Split" indique implicitement que les activités qui y sont reliées en sortie sont
exécutées en parallèle.

Les opérateurs de contrôle de flux présentent également l'inconvénient de ne pouvoir

traiter que des cas relativement simples. En effet, si le concepteur du workflow souhaite
faire une gestion complexe d'événements qui combine l'effet de l'application de plusieurs
opérateurs, la modélisation devient vite surchargée et ardue. Pour illustrer cela, nous
proposons les deux exemples suivants :

§ Exemple 1 : Supposons que le concepteur du E1

AND
workflow souhaite exprimer le fait qu'une
activité A n'est exécutée que dans deux cas E2
bien précis : si deux événements E1 et E2 ont XOR
A
lieu simultanément ou (exclusif) si l'un ou les
E3
deux autres événements E3 et E4 ont lieu.
Cela pourrait se traduire par une expression OR

de la forme : E4

(E1 AND E2) XOR (E3 OR E4) à A (1)

Le modèle correspondant à cette expression E1

pourrait ressembler au schéma de la figure ci- AND
A1
contre. Ce modèle, bien que compréhensible,
E2
est relativement chargé.
XOR

§ Exemple 2 : Considérons à présent un cas E1

légèrement plus compliqué. Nous disposons
AND A2
de deux activités, A1 et A2 ne pouvant E3

s'exécuter que de façon exclusive. La

réalisation de A1 est liée à l'occurrence E4

simultanée de deux événements E1 et E2,

tandis que celle de A2 est liée à l'occurrence
conjointe de trois événements, E1, E3 et E4. Opérateur de type “ JOIN ”

Cette situation peut se résumer par

Opérateur de type “ SPLIT ”
l'expression suivante :

( (E1 AND E2) à A1 ) XOR (2)

( (E1 AND E3 AND E4) à A2)
Figure IV.5 - exemples d'utilisation
des opérateurs de contrôle de flux

Comme nous pouvons le constater dans la figure IV.5 (2), la modélisation de cette expression
donne lieu à une représentation chargée, qui n'est pas nécessairement claire mais surtout, qui
n'exprime pas correctement la situation. En effet, dans la figure on comprend bien que
l'occurrence des deux événements E1 et E2 est nécessaire. Cela est également visible pour les
événements E1, E3 et E4. La disposition des opérateurs nous permet de plus de comprendre

127
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

que A1 et A2 s'exécutent de façon exclusive. Par contre, le modèle ne permet pas de savoir
que A1 est liée à E1 et E2, alors que A2 est liée à l'autre ensemble d'événements.

Une solution peut consister en l'utilisation des E2

opérateurs de branchement conditionnels. Le
modèle correspondant à l'exemple 2 aurait alors
A (E1 AND E2)
la forme de la figure ci-contre. Dans ce cas, on a A1
bien exprimé quelles sont les conditions qui
E1
permettent à A1 et A2 de s'exécuter, par contre
nous avons perdu l'information qui indiquait que
leur exécution est exclusive. En fait, pour bien B A2
exprimer la situation, il aurait fallu que
l'opérateur de branchement serve également (E1 AND E3 AND E4)
E3 E4
d'opérateur de contrôle de flux - en l'occurrence
de XOR.

Les opérateurs classiques souffrent donc d'un Figure IV.6 - Opérateur de

certain manque d'expressivité dans les situations branchement
complexes.

Afin de résoudre les problèmes liés à la modélisation du contrôle de flux (séparation des
aspects événementiels et chronologiques, combinaison complexe d'opérateurs de contrôle de
flux), nous avons introduit dans le framework deux classes spéciales : la classe
"Expression_Logique" dédiée à la gestion des événements et la classe "BCF" (ou Bloc de
Contrôle de Flux) pour le contrôle de flux.

La classe Expression_Logique est associée en entrée à des événements, et en sortie à des

activités dont l'exécution dépend de l'occurrence des événements. Elle permet d'introduire des
expressions complexes et puissantes dans le modèle Workflow. Leur écriture se fait à l'aide
d'une notation symbolique, que nous appelons "2FLEx", associant les opérateurs booléens
XOR, OR et AND à des événements et à des activités, ce qui permet de prendre en compte
l'ensemble des cas de figure possibles. Les formes de base d'une expression logique sont les
suivantes :

[ … [ Evénement ( activité i, activité k, … ) Opérateur ( activité j, activité l, … ) Evénement (

activité m, activité n, …) ] … ]

[… [Expression logique] Opérateur (activités) [Expression logique] ...]

Le terme "Evénement" fait référence à un événements émis en cours d'exécution du processus

(il peut s'agir d'une exception). Le terme "Opérateur" correspond à l'un des opérateurs
logiques XOR, OR et AND. Enfin le terme "activité" concerne une activité associée à un
événement ou à un opérateur. La présence d'activités dans chacun des événements et de
l'opérateur est optionnelle et il suffit que l'un d'eux soit associé à au moins une activité. Cette
notation permet de gérer les événements de façon puissante et efficace, à l'aide d'un
formalisme simple, ce qui est difficile à réaliser par les d'opérateurs de contrôle de flux
classiques.

Chaque événement d'une expression logique peut déclencher l'exécution des activités
auxquelles il est directement associé, et sa combinaison avec d'autres événements, via
l'opérateur logique, permet de lancer un autre ensemble d'activités. Ainsi :

128
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ : indique que l'événement Evénement X déclenche

Evénement X ( Activité 1, …, Activité i)
l'ensemble des activités mentionnées entre les parenthèses, de Activite1 jusqu'à Activité
i. Remarquons que l'indice des activités dans l'exemple n'indique pas leur ordre
d'exécution chronologiquee.

§ Evénement X ( ) Opérateur ( Activité n, … Activité t ) Evénement Y ( ) : cette notation

exprime que c'est l'association des deux événements Evénement X et Evénement Y via
l'opérateur Opérateur qui déclenche l'ensemble des activités de Activité n à Activité t.

Nous illustrons les possibilités de la classe Expression_Logique par les exemples suivants, le
tableau IV.1 donne la correspondance des opérateurs logiques dans la notation 2FLEx :

Opérateur logique Opérateur 2FLEx

OR |
AND &
XOR ^

Tableau IV.1 - Equivalence entre opérateurs logiques et la notation 2FLEx

§ Exemple 1 bis : l'exemple 1 de la figure IV.5.1 s'écrit, à l'aide de notre notation, de la

façon suivante :

[E1( ) &( ) E2( ) ] ^(A) [ E3( ) | ( ) E4 ( ) ].

Nous voyons dans cet exemple que les événements E1, E2, E3 et E4 ne sont associés
individuellement à aucune activité. Il en est de même pour les deux opérateurs "&" et
"|". En fait, l'activité A est lancée suite à l'occurrence exclusive de ces deux ensemble
d'événements, par conséquent l'activité dépend de l'opérateur exclusif "^" avec lequel
on l'associe.

§ Exemple 2 bis : l'équivalent de l'exemple 2 de la figure IV.5 transcrit dans la notation

2FLEx correspond indifféremment à l'une des expressions ci-dessous :

[ E1( ) & (A1) E2( ) ] ^( ) [ [ E1( ) & (A2) [ E3 ( ) &( ) E4( )] ]

ou encore
[ E1( ) & (A1) E2( ) ] ^( ) [ [ E1( ) & ( ) E3 ( ) ] &(A2) E4( )].

Chacune de ces expressions logiques permet d'indiquer que le déclenchement de

l'activité A1 dépend de l'occurrence conjointe des événements E1 et E2, par
conséquent l'activité est associée à l'opérateur "&". L'activité A2 quant à elle dépend
de l'occurrence simultanée des événements E1, E3 et E4, ce qui est indiqué par
l'association de l'activité au deuxième opérateur "&". Enfin, les activités ne peuvent
s'exécuter que de manière exclusive, ce que nous exprimons grâce à l'opérateur ^.

C'est l'instance de la classe Expression_Logique qui se charge de gérer correctement le

déclenchement des activités. Par exemple dans le cas présent, si le premier ensemble
d'événements a lieu en premier (E1 et E2) alors l'instance Expression_Logique invalide
la réception des autres événements. Il n'est alors plus possible de déclencher A2.

129
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ Exemple 3 : nous traitons dans cet exemple un cas plus compliqué que les deux
précédents. Supposons que nous ayons quatre activités, A1, A2, A3 et A4. A1 est
déclenchée par un événement E1, tandis que E2 déclenche les activités A2 et A3. E1 et
E2 sont issus de la même activité A mais ils sont disjoints (OR), c'est à dire qu'ils
peuvent être générés séparément ou pas. L'activité A4 quant à elle, est mise à feu par
l'occurrence simultanée de deux autres événements, E3 et E4, générés par une activité
B. Toutefois, l'occurrence des événements (E1, E2) et (E3, E4) est exclusive, il n'est
donc pas possible de réaliser (A1, A2, A3) et A4. L'expression 2FLEx correspondant à
cette situation est la suivante :

[ E1(A1) | ( ) E2(A2, A3) ] ^( ) [ E3( ) &(A4) E4( ) ]

Cette expression est relativement simple à écrire et permet de traiter efficacement le

problème posé. Chacun de ses membres permettant d'exprimer clairement une
situation donnée. Par comparaison, la même expression à l'aide d'opérateurs classiques
de contrôle de flux aurait donné le résultat de la figure IV.7 :

E1 A1

A2
OR

A E2 XOR

A3

XOR

B
E3

XOR
A4
AND

E4

Figure IV.7 - Exemple 3

Les expressions logiques de 2FLEx permettent de décrire tous les cas de figure, même
complexes, sans avoir de plus à surcharger le modèle puisqu'un seul élément -
l'expression logique - remplace l'ensemble des opérateurs de contrôle de flux
normalement nécessaires, sans faire perdre au modèle Workflow son expressivité.
Nous rappelons de plus que les expressions logiques servent uniquement à gérer les
événements et non à contrôler le flux. Cette information n'est donc pas perdue mais
exprimée dans 2FLOW à l'aide d'opérateurs spécifiques, comme nous allons le voir.

Dans 2FLOW, la gestion des événements est donc prise en charge à l'aide des instances de
la classe "Expression_Logique". La gestion de l'ordre d'exécution des activités est quant à
elle prise en charge par un autre type de contrôleurs, que nous appelons "BCF" ("Bloc de
Contrôle de Flux").

2.2.2 Blocs de contrôle de flux

Les événements générés en parallèle indiquent implicitement que les activités auxquelles ils
sont reliés en entrée doivent également être exécutées en parallèle. Cependant, étant donné
que nous avons souhaité séparer la gestion d'événements de la gestion de l'ordre d'exécution -

130
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

pour des raisons de clarté - nous avons introduit au sein du framework un ensemble de classes
spécialisées dans le contrôle de flux, dont la classe mère abstraite, est appelée "BCF". Un BCF
se spécialise en fait en trois autres classes, dédiée chacune au traitement d'un type de flux
spécifique. Nous distinguons ainsi :

§ La classe BCF_S (ou BCF de séquence), qui est dédiée au contrôle de l'exécution
séquentielle des activités et des BCF qui y sont contenus.

§ La classe BCF_B (ou BCF boucle), dédiée à l'instauration d'une exécution en

boucle. Elle se spécialise elle-même en deux autres classes :

a) La classe BCF_For, qui exécute les activités et les BCF contenus dans le bloc
un nombre fixé n de fois.

b) La classe BCF_While, qui exécute les activités et les BCF contenus dans le bloc
tant qu'une condition de fin de boucle n'est pas atteinte. Il peut s'agit de
l'occurrence d'un ou de plusieurs événements ou d'une expression testant le
contenu de variables du workflow.

§ Enfin, la classe BCF_P (ou BCF parallèle) qui permet d'exécuter simultanément
plusieurs activités et/ou BCF.

L'exécution d'un processus est toujours associée à un BCF_S, le flux pouvant varier par la
suite en fonction des souhaits des concepteurs, qui décomposent alors l'exécution du
processus en celle de plusieurs BCF. Ce découpage, qui est surtout utile pour l'exécution,
n'entre pas à notre sens dans la perception "naturelle" d'un processus, qui est plutôt
événementielle. Par conséquent, nous séparons notre framework en deux points de vues
complémentaires : le point de vue "processus métier", qui permet de décrire et de comprendre
complètement un processus grâce à une approche événementielle, et le point de vue "logique"
qui inclue l'aspect contrôle de flux.

2.3 Vue Organisationnelle

La vue organisationnelle d'un workflow permet de représenter deux aspects importants : d'une
part, elle décrit la structure de l'entreprise en termes de services, de départements,
d'employés, etc. et d'autre part, elle permet de spécifier les rôles chargés de réaliser les
activités du workflow et de les lier aux ressources (personnes et matériels) de l'entreprise.
Nous distinguons donc ces deux aspects dans notre framework, à l'aide de classes spécifiques.
Nous proposons notamment une approche originale des notions de rôle et d'acteur.

2.3.1 Les rôles, les acteurs et les activités

Dans le chapitre 2, nous avons défini un rôle comme étant un qualificatif permettant de
décrire les compétences d'un acteur d'un processus donné. Dans la grande majorité des
modélisations et des systèmes Workflows, un rôle n'est utilisé que pour donner une
description de ce que son titulaire fait et éventuellement, lui associer des droits d'accès aux
données du workflow. Par exemple on pourrait imaginer que le formulaire de saisie de la
définition d'un rôle a la forme suivante :

131
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Nom du Rôle : Chef d'atelier

Description :

Un chef d'atelier supervise le bon déroulement du travail dans un atelier. Il intervient

ponctuellement sur des postes en cas de problème.
Permissions :
Ecriture x Lecture x Exécution Choix d'une donnée gamme d'assemblage

Figure IV.8 - Exemple de définition d'un rôle dans un système Workflow quelconque

Lors de la modélisation, les activités du workflow sont liées aux différents rôles qui ont été
identifiés. Dans la plupart des cas, elles sont attribuées aux acteurs en cours d'exécution, soit
"manuellement" soit à l'aide d'algorithmes de sélection ("approche push"). Dans certains cas
cependant (par exemple dans le système Teamware Dolphin [YOUNG 94], l'activité est
envoyée à tous les acteurs tenant le même rôle ("approche pull"). C'est ensuite à l'un d'entre
eux de s'approprier l'activité qui est immédiatement retirée des worklists des autres acteurs.

Dans le framework 2FLOW, nous proposons une approche différente des relations entre rôles
- acteurs et activités. Nous nous basons sur le fait bien admis qu'un rôle définit un ensemble
de compétences. Or dans un processus, un ensemble de compétences correspond
nécessairement à la possibilité de réaliser certaines activités. Par extrapolation, on peut donc
dire qu'un rôle correspond à un ensemble d'activités qui sont réalisables par un acteur tenant le
rôle en question. Quel que soit le processus concerné, ces activités sont invariantes, c'est à
dire qu'elles correspondent toujours à la réalisation du même objectif - ce qui ne veut pas dire
qu'elles sont réalisées de la même façon.

Nous proposons donc de concevoir la notion

<< interface >>
de rôle comme une interface, au sens
Nom_Interface Activité
Objet du terme - à ne pas confondre avec les
interfaces graphiques, matérielles ou + méthode_1 (…) implémente
+ méthode_2 (…) + méthode_1 (…)
logicielles. + méthode_3 (…) + méthode_2 (…)
+ méthode_3 (…)
+ autre_méthode_1 ( ...)
Dans le monde Objet, une interface + autre_méthode_2 (…)

détermine un ensemble de comportements

(des méthodes), pour lesquelles elle ne Figure IV.9 - Notion d'interface en
donne pas d'implémentation. Celle-ci est conception Objet
réalisée par les classes d'objets qui
implémentent l'interface.

On dit qu'une classe implémente une interface si elle en implémente toutes les méthodes - ce
qui ne l'empêche pas de définir des méthodes qui lui sont propres. L'intérêt d'une interface est
de regrouper un ensemble de services sous une même dénomination. Ainsi, chaque classe qui
implémente les services de l'interface pourra être qualifiée par son nom, c'est à dire perçue en
tant que fournisseur des services de l'interface. Il est alors possible d'utiliser indifféremment
les instances des classes qui implémentent l'interface, à tout endroit où celle-ci est sollicitée.

132
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles
<< interface >>
Par exemple, considérons la métaphore d'une Décapsuleur
interface "Décapsuleur" qui définit le service
rendu par un décapsuleur via une méthode + décapsuler (…)
"décapsuler(...)" (fig. IV.10). Considérons à
présent deux autres classes - "Couteau_Suisse" et
"Tire_Bouchon". Celles-ci, bien que n'étant pas Couteau_Suisse Tire_Bouchon
du même type (donc non issues d'une même
classe de base), implémentent à leur façon la + couper (…) + déboucher (…)
+ scier (…) + décapsuler (…)
méthode décapsuler(...), parmi d'autres méthodes + ouvrir (…) + pulvériser_bouchon(...)
qui leur sont propres. Etant donné que ces deux + décapsuler ( ...)
+ dévisser (…)
classes fournissent le service "décapsuler(...)", il + couper_les_doigts (...)
est donc possible d'y avoir recours
indifféremment, s'il est besoin d'un décapsuleur. Figure IV.10 – Exemple d'interface

Dans 2FLOW, un "Rôle" est une interface qui regroupe un ensemble de services
correspondant à certaines activités d'un processus. Un rôle étant tenu par un ou plusieurs
acteurs, les services d'un rôle sont donc implémentés par des sous-classes de la classe
"Acteur", chacune d'entre elles correspondant à un type d'acteur particulier. En réalité, les
"vrais" acteurs sont des sous-classes des classes "Acteur_Humain" ou "Acteur_Automatique" qui
spécialisent à leur tour la classe de base Acteur. Enfin, les activités (représentées par la classe
du même nom) sont associées aux rôles qui sont chargés de les réaliser.

La possibilité de définir un ensemble de services réalisés de façons différentes selon les

entités qui les proposent, ouvre des perspectives très intéressantes pour le Workflow. En effet,
cette façon de procéder crée une indépendance entre "ce qu'il y a à faire" et "comment le
faire" [JOERIS et al. 98]. En d'autres termes, cette séparation permet de construire un
processus en associant les activités aux rôles sans se préoccuper des entités qui vont
réellement traiter les activités lors de l'exécution. Il est ainsi possible de remplacer un acteur
par un autre sans que cela ne perturbe le bon déroulement du processus. La capacité de choisir
un acteur ou de le remplacer par un autre en cours d'exécution est déjà fournie par bon
nombre de systèmes Workflows. C'est d'ailleurs bien là le but de la notion de rôle. Toutefois
dans ces systèmes, il n'y a pas de relations directes entre un rôle et les activités qui lui sont
attribuées, autres que celles que les concepteurs établissent lors de la modélisation. En
d'autres termes, rien n'empêche théoriquement d'attribuer un rôle à un acteur même s'il ne
possède pas les compétences nécessaires pour réaliser les activités qui lui sont confiées.

En effet, considérons par exemple le processus simplifié d'admission d'un patient pour une
opération, dans un hôpital. La première étape du processus consiste à établir un dossier
administratif au patient (numéro de sécurité sociale, type de couverture assurance maladie ou
mutuelle, etc.). Cette tâche est attribuée à un agent administratif du personnel de l'hôpital.
L'étape suivante consiste à établir le dossier médical du patient : connaître ses antécédents
médicaux, faire des examens, établir un diagnostic, etc. La responsabilité de cette tâche est
attribuée au médecin chef du service où le patient est admis. Une fois le dossier médical établi
et la date de l'opération arrivée, le patient est opéré par un chirurgien qui aura pris
connaissance au préalable du dossier médical du patient. Enfin, la dernière activité du
processus consiste en la facturation du patient. Elle est attribuée à un des agents comptables
de l'hôpital.

133
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Dossier Dossier
administratif médical

Etablir dossier Etablir dossier Opérer Facturer

administratif médical
Arrivée d’un
patient

€
Agent
€
Médecin chef
Date opération
€
Chirurgien
€Agent
administratif du service Comptable

Evénement € Rôle Données

Activité Flux des tâches Flux d’informations

Figure IV.11 – Processus simplifié de la prise en charge d'un patient dans un hôpital

Dans la grande majorité des systèmes Workflows actuels, nous avons dit qu'un rôle n'est qu'un
ensemble d'informations descriptif. D'autre part, un acteur est le plus souvent décrit à l'aide
d'une entité contenant des informations générales (nom, prénom, position, etc.) qui ont surtout
un intérêt administratif. De plus, la possibilité d'avoir des acteurs humains et automatiques se
fait dans très peu de cas – sur lesquels nous reviendrons, car en effet, les systèmes Workflows
sont le plus souvent principalement dédiés à des utilisateurs humains. Dans les autres cas, les
acteurs automatiques sont au mieux, assimilés à des "ressources".

Attribuer un rôle à un acteur consiste en fait à lui attribuer une "casquette", sans
nécessairement s'assurer qu'il est capable de la porter. Ainsi, l'adéquation entre les activités
d'un processus attribuées à un rôle et les compétences des acteurs tenant le rôle reste à la
charge des concepteurs du workflow. Dans l'exemple précédent, rien n'empêche d'attribuer la
tâche d'établir un dossier médical à l'agent administratif, sinon le bon sens du concepteur. Au
mieux, cela voudrait dire que l'acteur tenant le rôle d'agent administratif tient également celui
de médecin chef, donc qu'il possède une double compétence. Nous en revenons donc aux
compétences – ou aux services que doit fournir le tenant d'un rôle.

L'intérêt de l'utilisation d'une interface en tant que rôle, "force" les acteurs à fournir les
services proposés par le rôle. Un acteur ne réalisant pas les services de l'interface ne
l'implémente pas, donc ne peut pas prétendre tenir le rôle correspondant. Par conséquent la
classe Acteur implémentée dans 2FLOW n'est pas un simple ensemble d'informations sur un
acteur mais définit tous les comportements qui lui sont associés – c'est à dire l'ensemble des
activités qu'il peut réaliser. La classe Acteur est donc, pour reprendre la terminologie anglo-
saxonne, un "wrapper" de l'acteur réel, son équivalent informatique dans le système
Workflow, en quelque sorte. Les mécanismes du langage objet sous-jacent nous permettent de
valider l'adéquation des compétences d'un acteur avec celles des rôles qu'il tient, puisqu'il
s'agit pour le compilateur de ce langage, de vérifier qu'une classe donnée (un acteur)
implémente bien une ou plusieurs interfaces (les rôles). Nous aurons l'occasion de revenir sur
ces mécanismes dans le paragraphe consacré au fonctionnement du framework.

L'approche activité – rôle – acteur proposée par 2FLOW apporte un autre intérêt très
important, celui de la possibilité d'utiliser indifféremment des acteurs humains ou
automatiques. En effet, nous avons dit que dans la plupart des systèmes Workflows, les
acteurs concernés par le processus sont le plus souvent humains. Par conséquent, les activités

134
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

se résument à la notification de l'acteur d'un travail qu'il a à faire, via sa worklist. Peu de
systèmes prennent réellement en compte les acteurs automatiques. Dans certains cas, ceux-ci
sont assimilés à des ressources. Dans d'autres cas plus performants, il existe une spécialisation
des acteurs en deux types : acteurs humains et acteurs automatiques. C'est notamment le cas
du système TriGSflow [KAPPEL et al. 95] [KAPPEL et al. 98] (aujourd'hui commercialisé
sous le nom de Verve1) qui permet de créer des "Agents" humains ou automatiques. Une autre
approche est adoptée par le système commercial Ultimus [ULTIMUS 99] qui dispose d'une
technologie originale offrant la possibilité de créer des "flobots" (pour workflow robots). Ces
derniers sont des agents informatiques prédéfinis qui sont associés à des applications
informatiques (Word, Excel, Access, etc.) auxquelles ils peuvent passer des données, et
desquelles ils peuvent en récupérer. Nous décrirons plus en détail ces différentes technologies
dans un futur paragraphe comparatif.

Nous pensons, pour des raisons évidentes de flexibilité, qu'il est très important que les
systèmes Workflows prennent autant en compte les acteurs automatiques que les acteurs
humains. Toutefois, il ne faut pas que cela oblige les concepteurs du modèle du workflow à
effectuer des tâches de conception différentes selon le cas. En d'autres termes, la modélisation
et la conception d'un workflow doit nécessiter les mêmes opérations, que ce soit avec des
acteurs automatiques ou humains. Il ne faut pas non plus que le système Workflow ait à se
"soucier" de faire cette distinction qui doit rester transparente, c'est à dire que pour lui, "un
acteur est un acteur".

L'approche élaborée dans 2FLOW nous permet de satisfaire ces deux contraintes. En effet,
nous avons dit qu'un acteur est un "wrapper" de l'acteur réel. C'est une classe qui dispose d'un
certain nombre de méthodes, correspondant toutes à des activités de processus et
implémentées de façon spécifique. Ainsi, la connaissance de comment réaliser une activité est
encapsulée au sein de l'objet acteur. Lors de l'exécution, l'instance de la classe Activité notifie
l'acteur chargé de la réaliser (nous verrons plus loin le mécanisme exact) et celui-ci active sa
méthode qui porte le même nom que l'activité. L'intérêt de notre approche est donc de créer
une indépendance qui existe entre la définition du processus et sa réalisation, ce qui nous
permet d'utiliser indifféremment un acteur humain ou un acteur automatique lors de
l'exécution d'une activité. Il est également possible de remplacer un acteur par un autre sans
perturber le bon déroulement du processus.

En résumé, la notion activité – rôle – acteur développée dans 2FLOW apporte trois avantages

§ L'indépendance entre définition et réalisation d'un processus.

§ La vérification assurée de l'adéquation d'un acteur au rôle qui lui est attribué.
§ La possibilité d'utiliser des acteurs humains et automatiques.

Pour résumer ces trois avantages, examinons l'exemple suivant, représenté par la figure IV.13.
Considérons un processus de désassemblage d'appareils électroménagers. On y distingue,
entre autres, deux rôles : un rôle "Opérateur de désassemblage" et un autre rôle "Chef
d'atelier". Deux acteurs, l'un humain, nommé "Alain", l'autre automatique, nommé
"Robot_007" sont disponibles. Alain tient les deux rôles, il implémente donc chacun des
services des deux interfaces. Robot_007 quant à lui n'implémente que l'interface "Opérateur
de désassemblage". Dans le processus, nous distinguons trois activités : "Dévisser", "Séparer"
et "Superviser". Elles correspondent aux services respectifs des deux rôles, auxquels elles sont
associées. La réalisation de "Dévisser" et "Séparer" peut être achevée indifféremment par
1
[Link]

135
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

"Alain" ou "Robot_007" puisque tous deux implémentent l'interface "Opérateur de

désassemblage". Par contre, l'activité "Superviser" ne peut être réalisée que par "Alain",
puisqu'il est le seul à l'implémenter. Remarquons que "Alain", "Robot_007" et les activités
sont des classes et non des instances de classes. Cette stratégie spécifique à 2FLOW permet
une modélisation et une exécution très flexibles.
<< interface >>
Acteur_Humain
Rôle

Acteur_Humain Acteur_Automatique
Opérateur Chef d’atelier
désassemblage

+ dévisser ( ) + superviser ( )
+ déclipser ( ) + notifier_opérateur ( )
+ séparer ( )
+ ranger ( )
Alain Robot_007

+ dévisser ( ) + dévisser ( )
+ déclipser ( ) + déclipser ( )
+ séparer ( ) + séparer ( )
+ ranger ( ) + ranger ( )
+ superviser ( )
+ notifier_opérateur ( )
Activité

Dévisser Séparer Superviser

Figure IV.13 – Exemple de modélisation d'un processus

en termes d'activités – rôles – acteurs

2.3.2 Les unités organisationnelles

Le second aspect de la vue organisationnelle concerne la modélisation de la structure de

l'entreprise. Il n'est pas très développé dans notre framework et se limite à une seule classe de
base : " l'Unité_Organisationnelle". Ainsi dans 2FLOW, un acteur appartient à une unité
organisationnelle, qui peut correspondre à n'importe quelle entité structurelle d'une entreprise,
que ce soit un département, un service, une équipe, etc. Il existe une association réflexive sur
une unité organisationnelle, parcourue dans les deux sens : une unité appartient à une autre
unité – une unité est composée d'une ou de plusieurs unités. Cette relation permet par exemple
de dire qu'un département est composé de services qui sont eux-mêmes divisés en équipes.
Les différences qui existent dans le découpage organisationnel
Acteur
des entreprises fait qu'il nous a paru plus raisonnable de *

rester à un niveau générique, qu'il est possible de

spécialiser en des sous-classes plus spécifiques. Unité
Remarquons enfin que certains systèmes Workflows du Organisationnelle
*
marché proposent des modèles organisationnels assez
complets des entreprises. Des travaux de standardisation
pour un framework organisationnel commun sont en cours
au sein de la WfMC, décrits en partie dans [ZUR Figure IV.14 – Vue
MULLEN 99]. organisationnelle de 2FLOW

136
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

2.4 Vue Informationnelle

La vue informationnelle concerne en général l'ensemble des informations qui sont échangées,
consommées et produites par les activités du workflow. La plus grande majorité des systèmes
Workflows ne considèrent dans cette catégorie, que les données issues de documents
électroniques, de formulaires ou de requêtes sur des bases de données. En général, ces objets
sont appelés "données" mais nous lui préférons le terme beaucoup plus générique
"d'artefacts". Ce terme est utilisé par des spécialistes de différentes disciplines dont [BOLCER
et al. 96], [KRUCHTEN 99] pour désigner les objets manipulés par des activités. Ainsi par
exemple dans le système Workflow Endeavor, un artefact désigne tout document électronique
ou morceau de code utilisé par une activité.

Dans le framework 2FLOW, nous avons créé une classe Artefact pour représenter les artefacts
manipulés par les activités. Nous la spécialisons en trois sous-classes de base :

§ La classe Document_Electronique, qui peut se spécialiser en tout type de document

électronique (requête, formulaire, feuille de calcul, etc.)

§ La classe Variable_Workflow permet de créer des variables qui pourront être utilisées
lors de l'évaluation d'événements, pour faire des calculs, etc.

§ La classe Objet_Technique correspond à des objets physiques utilisés par les

activités du workflow.

L'un des objectifs de ce framework, nous le rappelons, est de faciliter la construction de

workflows. En particulier, nous souhaitons permettre de produire des workflows par simple
assemblage de composants. Par conséquent, toute classe du framework doit être munie d'un
ensemble minimal de comportements les habilitant à se comporter d'une façon plus ou moins
"autonome". Plus précisément, chaque artefact doit décharger le concepteur du workflow d'un
certain ensemble de tâches dont il ne devrait pas se préoccuper. Par exemple, on peut
imaginer qu'une activité Workflow nécessite de connaître le résultat d'une requête sur une
base de données. Le concepteur du workflow ne devrait pas se préoccuper de la façon dont la
requête est exécutée et comment doit se faire la connexion à la base. Au contraire, cette tâche
devrait être réalisée par l'objet correspondant à l'artefact. Par conséquent, un artefact est
également un "wrapper", muni de son propre comportement, qui est l'équivalent de l'objet
réel.

L'utilité de concevoir l'artefact comme étant l'équivalent informatique d'un objet nous semble
particulièrement intéressante dans le cas où le workflow doit traiter des objets physiques. Il
peut en effet paraître étrange d'avoir inclu une classe Objet_Technique dans un système
Workflow. En fait, cette classe sert à représenter l'objet physique réel, ce qui permet en
particulier de connaître son état et de le manipuler lors du processus.

Par exemple, reprenons le cas d'un appareil traité par un processus de désassemblage. Le but
de ce dernier est de démonter un lave-linge en y extrayant trois composants. On voit bien dans
ce cas que les activités ont besoin d'avoir accès au lave-linge qui est donc un artefact physique
du processus, tout comme les composants extraits par les activités. En plus des objets réels,
les opérateurs du démontage (qu'ils soient humains ou automatiques) nécessitent d'obtenir des
informations sur l'appareil qu'ils ont à traiter, telles par exemple la localisation des pièces, les
outils à utiliser, etc.

137
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Lave-linge Moteur Tambour

Par ailleurs, lors de la modélisation du
workflow du désassemblage, les activités
permettant de faire circuler l'appareil à
démonter d'un acteur à un autre, ne sont pas
Système et processus de transport des pièces
directement en relation avec le processus. En
effet, ce qui importe au workflow, c'est le
résultat, donc que les appareils soient transmis Artefact Artefact Artefact
Lave_Linge Moteur Tambour
aux acteurs. Le comment, c'est à dire la façon
dont les appareils sont acheminés, n'est pas
Extraire Extraire Extraire
intéressant. Par conséquent, la représentation couvercle moteur tambour
des activités de transport au sein du workflow
workflow
de désassemblage constitue une surcharge
inutile car ces activités appartiennent en fait à
un autre processus – par exemple un Figure IV.15 – Processus de désassemblage
processus de logistique. d'appareils. Utilisation d'artefacts 2FLOW

Nous avons donc à résoudre un double problème :

§ Faire circuler des informations techniques entre les activités du processus. C'est un
service rendu par la plupart des systèmes Workflow.

§ Faire circuler les objets physiques entre les activités auxquelles on a passé les
informations techniques. Par contre, les activités permettant cette circulation, bien
que nécessaires, ne doivent pas être représentées dans le workflow puisqu'elles
n'en font pas directement partie.

La solution que nous proposons à ce problème est concrétisée sous la forme de la classe
Objet_Technique, l'équivalent informatique de l'objet physique manipulé par les activités. Un
Objet_Technique contient des informations sur l'état de son objet physique mais surtout, sert
d'interface entre le workflow et les processus extérieurs manipulant cet objet. Nous déléguons
ainsi la responsabilité de la manipulation des objets réels à leurs "représentants" au sein du
système Workflow. Cette approche nous permet donc d'une part de libérer le concepteur du
workflow d'une modélisation inutile, et d'autre part de créer une indépendance entre le
workflow et la façon dont les objets physiques sont "envoyés" aux acteurs. Il est ainsi possible
de modifier les processus extérieurs sans perturber le workflow en cours, puisque tout se fait à
travers les artefacts Objet_Technique.

Dans l'illustration de l'exemple du processus de désassemblage donnée par la figure 4.15, trois
sous-classes d'Objet_Technique sont créées. Elles correspondent respectivement aux trois
objets physiques consommés et créés par les activités du processus : "Lave_Linge", "Moteur"
et "Tambour". Les instances de ces classes sont associées explicitement aux activités du
workflows lors de la modélisation, et implicitement à un système extérieur gérant le transport
d'objets au sein de l'atelier. Les sous-classes de Objet_Technique encapsulent les appels au
système extérieur ou à l'un des processus gérés par ce système. Lorsque ces classes sont
transmises aux activités, elles invoquent automatiquement les processus extérieurs qui se
chargeront d'envoyer l'appareil ou le composant concerné à l'activité.

Remarquons que dans notre framework, nous nous sommes limités à définir des attributs et
des comportements de base aux artefacts. La spécialisation de ces classes en d'autres entités
reste à la charge des programmeurs.

138
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

3. Fonctionnement de 2FLOW
Dans cette partie du chapitre, nous allons approfondir la description de 2FLOW en nous
intéressant à la description de son fonctionnement. Cette description englobe en fait une
première partie décrivant succinctement la façon d'utiliser le framework et une deuxième
partie décrivant le fonctionnement interne de ses classes.

3.1 Utilisation du framework

Avant de commencer à détailler le fonctionnement interne des classes de 2FLOW, il est
intéressant de comprendre le principe de leur utilisation.

2FLOW étant un framework, il propose Acteur_Humain

comme nous avons pu le voir lors des - nom : Chaîne
- id : entier
paragraphes précédents, un ensemble de - unité_org : Unité_Org
- rôle : Rôle
classes aux comportements prédéfinis. A ... Classe de
l’opposé de la plupart des systèmes base
Comportement prédéfini
Workflows, ces classes ne sont pas adaptable et extensible
directement instanciables. Elles servent en
fait de classes de base pour la définition
des classes propres aux utilisateurs, qui Classe Workflow
Alain_Tairieur
elles, sont instanciées lors de l’exécution.
En général, une classe utilisateur est + démonter ( )
instanciée pour chaque "cas" du workflow. + extraire ( )
+ séparer ( )
Afin de faciliter la modélisation et la
création de workflows par assemblage de
composants, les comportements définis au << instance >> << instance >>

niveau des classes de base permettent instance # 2 : instance # 1 :

d’assurer un "service minimum". En Alain_Tairieur Alain_Tairieur
- Alain Tairieur - Alain Tairieur
d'autres termes, il n'est pas nécessaire de - AT2000 - AT2000
redéfinir ces comportements dans les - atelier - atelier
- opérateur - opérateur
classes des utilisateurs pour construire des
workflows qui fonctionnent, sauf en cas de
besoin de spécialisation, de réutilisation ou
d'adaptation.
Figure IV.16 – Utilisation de 2FLOW

Dans l'exemple de la figure ci-contre, nous créons une classe "Alain_Tairieur" qui hérite de
la classe "Acteur_Humain". Cette classe est l'équivalent dans le workflow du vrai acteur du
même nom, dans une entreprise donnée. La classe Alain_Tairieur hérite de tous les attributs et
les comportements de la classe Acteur_Humain, plus les comportements du rôle qu'elle doit
implémenter. Nous verrons dans la suite de cette partie du chapitre quels sont les
comportements de base d'un objet de type Acteur_Humain dans le framework. Sans rentrer
dans le détail, il suffit pour le moment de savoir que si des traitements particuliers ne sont pas
associés aux méthodes d'un acteur, donc si elles ne sont pas redéfinies au niveau de la
modélisation, alors celles-ci invoquent par défaut une méthode héritée qui envoie une
notification à la worklist du vrai acteur.

Le principe d'utilisation du framework consiste donc à en spécialiser les classes composantes

en des classes spécifiques au workflow à construire. Si aucun nouveau comportement n'est à

139
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

redéfinir à ce niveau, alors les nouvelles classes sont parfaitement fonctionnelles, grâce aux
méthodes et attributs dont elles ont hérités. Il est néanmoins nécessaire d'attribuer des valeurs
initiales à certains des attributs pour que le workflow puisse s'exécuter. Nous illustrons cela
par un premier exemple concret sur la création de classes basées sur le framework. Dans la
figure ci-dessous nous décrivons, à l'aide d'un diagramme de classes UML, l'exemple du
processus de désassemblage d'un lave-linge, précédemment illustré par la figure IV.15.

Processus BCF

Acteur Rôle Activité BCF_S

Acteur_Humain Acteur_Auto

Superviseur Opérateur Désassemblage Sequence_p

Lave_Linge
+ superviser ( ) + extraire_ carte ( )
+ notifier ( ) + extraire_couvercle ( )
+ extraire_tambour ( )
+ extraire_moteur ( )
+ séparer ( )

Alain

+ superviser ( ) Robot_007
+ notifier ( )
+ extraire_tambour ( ) + extraire_tambour ( )
+ extraire_moteur ( ) + extraire_moteur ( ) Extraire_couvercle Extraire_tambour Extraire_moteur
+ extraire_couvercle ( ) + extraire_couvercle ( )
+ extraire_ carte ( ) + extraire_ carte ( )
+ séparer ( ) + séparer ( )

Réalisée par

Figure IV.17 - Construction d'un workflow à l'aide de 2FLOW

Dans cet exemple, le workflow du processus de démontage est obtenu par l'assemblage de
classes dérivées des classes de base. Chacune de celles-ci correspond à un élément du
workflow. Ainsi, les trois activités du processus sont représentées à l'aide de trois classes du
même nom, dérivées de la classe Activité du framework. De la même façon nous avons créé
deux acteurs, deux rôles et un bloc de contrôle de flux en les faisant hériter de leurs classes
mères respectives. Nous pouvons remarquer que les activités du processus correspondent aux
méthodes des rôles Superviseur et Opérateur, et qu'elles sont redéfinies au niveau des acteurs
qui tiennent les rôles.

Bien que les comportements hérités par les classes du workflow soient suffisants pour
permettre son exécution, il est toutefois nécessaire de spécifier les valeurs de certains attributs
au moment de la construction du workflow. Pour ce faire, chaque classe du framework
dispose nécessairement de deux catégories d'attributs :

§ La première sert à stocker les noms des classes associées à la classe en question. Selon la
cardinalité, les attributs de cette catégorie sont soit de type vecteur de chaînes de
caractères (StringVector, que nous présentons dans un prochain paragraphe) pour les
cardinalités multiples, soit de type chaîne de caractère (String) pour une cardinalité simple.
La classe dispose d'autant d'attributs de type String ou StringVector qu'elle est associée à des

140
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

classes différentes. En règle générale, le nom de l'attribut est composé du nom de la classe
associée suivi de "Name" (ou "Names" pour les cardinalité multiples). Par exemple, la
classe Activité est liée à des événements, des expressions logiques, des artefacts et à un
rôle. Une partie de son interface est alors de la forme suivante :

class Activité {

...
protected StringVector eventsNames;
protected StringVector logicalExpressionsNames;
protected StringVector artefactsNames;
protected String roleName;
...
}

Ce sont donc les attributs de cette catégorie qui doivent tous être initialisés lors de la
modélisation car ce sont eux qui permettront, lors de l'exécution, l'instanciation des classes
dont ils contiennent les noms.

§ La deuxième catégorie d'attribut est complémentaire à la première, elle sert à référencer

les instances des classes dont les noms sont contenus dans les attributs du type précédent.
Nous n'entrons pas ici dans le détail car les explications nécessaires sont du domaine du
fonctionnement interne du framework, que nous décrivons en détail dans ce qui suit.

A l'instar des concepteurs du système Workflow Endeavor précédemment cité, nous

distinguons trois niveaux d'utilisateurs de 2FLOW :

1. Le premier niveau concerne l'ensemble des utilisateurs "cibles" des workflows, c'est à
dire les participants aux processus, ceux qui vont réaliser les activités. Les membres de
cet ensemble n'interviennent sur le modèle du workflow que pour y apporter des
corrections et des modifications, à condition d'en avoir le privilège.

2. Le deuxième niveau englobe l'ensemble des personnes chargées de concevoir les

workflows. Ils utilisent les classes du framework (en les spécialisant comme nous l'avons
montré dans l'exemple précédent), pour les assembler et construire des workflows
fonctionnels, qui répondent aux besoins de l'entreprise. Ces utilisateurs ont
nécessairement des compétences en analyse et modélisation de processus, et
éventuellement en informatique. Les concepteurs des workflows peuvent également en
être des utilisateurs, ils ont par défaut les prérogatives nécessaires pour y apporter des
modifications.

3. Enfin, le troisième niveau implique des utilisateurs particuliers, que nous qualifions de
développeurs Workflows. Ceux-ci sont chargés d'enrichir le framework, de construire de
nouvelles classes en fonction des besoins des concepteurs ou de redéfinir les
comportements des classes existantes. Les développeurs Workflow doivent posséder un
minimum fonctionnel de connaissances informatiques.

141
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

3.2. Fonctionnement interne de 2FLOW

Les paragraphes précédents nous ont permis de donner un aperçu étendu du framework : sa
structure (les vues et leur composition), son utilisation et son mode général de
fonctionnement. Cette description englobante mais peu détaillée nous permet d'appréhender à
présent une vision plus approfondie du fonctionnement interne de 2FLOW.

3.2.1 Les classes auxiliaires

La première étape à aborder dans le fonctionnement du framework consiste en la description

des classes que nous appelons "auxiliaires". Celles-ci ne font pas partie du métamodèle
Workflow que nous avons présenté au début de ce chapitre et qui forment l'architecture de
base de 2FLOW. La raison de cette absence est que les classes auxiliaires ne sont pas des
"objets Workflow", c'est à dire qu'elles ne correspondent pas à des concepts fondamentaux du
Workflow comme le sont les activités, les acteurs, etc. Nous distinguons donc deux types
d'objets au sein de 2FLOW :

1. Les objets Workflows

2. Les objets Auxiliaires

1. Les classes d'objets Workflows correspondent comme nous l'avons dit, à des objets
fondamentaux du Workflow dont ils formalisent les concepts et en implémentent les
comportements. Un objet Workflow est un objet métier, spécifique au Workflow.

2. Les classes d'objets auxiliaires ne sont pas directement en relation avec le Workflow car
elles n'en formalisent aucun concept : ce ne sont pas des objets métiers. Elles ont pour
vocation de fournir des services aux objets Workflows. Leur utilisation se situe à deux
niveaux : le premier correspond au "niveau Workflow" où les services rendus par les
utilitaires qui s'y trouvent, assurent le bon fonctionnement des workflows construits à
l'aide des classes de base de 2FLOW. Le deuxième niveau est appelé "niveau Utilitaire".
Ses classes rendent des services semblables aux librairies des langages de
programmation. Leur effet se limite donc à fournir des utilitaires de programmation.

[Link] La classe InstanciatedClasses

La classe InstanciatedClasses est l'une des classes auxiliaires de niveau Workflow les plus
importantes de 2FLOW. Elle sert à référencer l'ensemble des objets issus de l'instanciation des
classes d'un modèle workflow. Celles-ci s'y inscrivent automatiquement lors de leur création
(lors de l'appel du constructeur de la classe) en invoquant l'une des méthodes de la classe
utilitaire : "addObjetct( )". La classe InstanciatedClasses propose plusieurs services. Nous en
présenterons certains en fonction des besoins des explications mais nous en décrivons une
partie importante dans ce qui suit :

§ Vérification de l'instanciation d'une classe. Nous avons signalé que pour propager
l'exécution du workflow, certaines classes ont la possibilité d'en instancier d'autres. Il se
peut toutefois que deux classes (ou plus) puissent en instancier une même troisième. C'est
par exemple le cas des événements et des activités qui, comme nous le verrons plus loin,
peuvent respectivement instancier une ou plusieurs activités et être déclenchées par un ou
plusieurs événement. Dans le cas où le déclenchement d'une même activité est lié à

142
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

l'occurrence de plusieurs événements, alors seul l'un d'entre eux – le premier à avoir lieu –
doit instancier l'activité en question. Il n'est en effet pas envisageable de créer pour le
même processus, plusieurs instances de la même activité. Par conséquent, tout événement
doit vérifier au préalable que la classe d'activité à laquelle il est lié n'a pas été instanciée
au préalable. Pour ce faire, toute classe de base peut faire appel à la méthode
checkClassExistance (nom de la classe) de l'utilitaire InstanciatedClasses.

§ Ajout d'un objet au référentiel, grâce à la méthode addObject (instance d'une classe), qui est
automatiquement invoquée par les instances des classes, lors de leur création.

§ Récupération de la référence sur un objet. Ce service est réalisé par la méthode

retrieveObject (nom de la classe). Remarquons que pour chaque cas Workflow, une et une
seule instance est créée pour chacune des classes composant le processus. Par conséquent
le passage du nom de la classe comme argument de la méthode retrieveObject est suffisant
pour récupérer l'objet.

§ Suppression de la référence à un objet dans le référentiel, en appelant la méthode

surchargée removeObject(entier) ou removeObject(nom de la classe). Dans le premier cas, on
suppose que l'objet qui invoque la méthode connaît la position de la référence de l'objet à
retirer dans le référentiel. Dans la deuxième version de la méthode, il faut de donner le
nom de la classe de l'objet dont on souhaite supprimer la référence.

[Link] Les classes ensemble

Certaines classes de 2FLOW sont liées les unes aux autres par des relations aux cardinalités
multiples. C'est le cas des activités, des événements, des expressions logiques et des artefacts.
En effet, comme l'indique le métamodèle de 2FLOW, une activité peut être liée à plusieurs
événements ou plusieurs expressions logiques. Réciproquement, un événement peut
déclencher plusieurs activités ou concerner différentes expressions logiques qui à leur tour
peuvent déclencher plus d'une activité. Enfin, une activité peut utiliser plusieurs artefacts. Il
est donc nécessaire dans ces cas de gérer des ensembles d'objets, ce que nous réalisons à l'aide
de classes spécifiques que nous qualifions de "classes ensemble", qui appartiennent au niveau
Workflow. Par rapport aux classes que nous avons citées précédemment, cela revient à créer
les quatre classes suivantes : le vecteur d'activités (ActivityVector), le vecteur d'événements
(EventVector), les vecteurs d'expressions logiques (LogicalExpressionVector) et enfin le vecteur
d'artefacts (ArtefactVector).

En Java, un vecteur ("Vector") est une collection dynamique d'éléments de type quelconque.
Par dynamique on signifie que la dimension de la collection n'est pas fixée lors du
développement mais qu'elle évolue (en diminuant ou en augmentant) selon les retraits et les
ajouts d'éléments [CAMPIONE 97], [ECKEL 97]. Un vecteur se différencie donc d'un tableau
par le fait qu'il n'a pas de dimension fixe et par la possibilité d'y placer des objets de type
différent. Cette dernière propriété est à double tranchant : en effet, s'il est parfois pratique de
pouvoir placer toutes sortes d'objets dans un même ensemble, cela implique aussi qu'il n'y a
pas de vérification du type de ces objets. En d'autres termes, il est possible de mettre "tout et
n'importe quoi" dans un vecteur, ce qui n'est pas toujours l'objectif. En particulier dans notre
cas, nous nous intéressons plus aux propriétés dynamiques d'un vecteur qu'à son statut de
collection générique.

143
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Afin de tirer profit des caractéristiques des vecteurs en apportant toutefois un contrôle sur leur
contenu, nous avons conçu les six classes ActivityVector, EventVector, LogicalExpressionVector,
ArtefactVector, ProcessVector et RunnableComponentVector. Ces classes fonctionnent toutes sur
le même principe, ce sont des collections dynamiques d'objets du même type proposant des
méthodes de manipulation des objets qu'elles contiennent (en fait, il est plus exact en Java de
parler de références vers des objets). Ceux-ci correspondent respectivement dans 2FLOW à
des activités, des événements, des expressions logiques, des artefacts et des composants
exécutables. Ces types ont tous été présentés, mis à part le dernier que nous évoquerons dans
un prochain paragraphe. La modélisation UML d'une classe ensemble est proposée par la
figure 4.18. Le symbole générique XXX sert à remplacer le nom d'une classe Workflow.
XXXVector
# referential : InstanciatedClasses
XXX
+ XXXVector( )
+ addXXX (objetXXX : XXX ) *
+ getXXXAt ( i : entier ) : XXX
+ getXXX ( XXXname : chaîne) : XXX
+ setXXXAt (i : entier)
+ removeXXXAt ( i : entier )
+ removeXXX ( XXXname : chaîne)
+ checkXXXExistence ( XXXname : chaîne ) : booléen
+ size ( )

Figure IV.18 – Modèle UML d'une classe ensemble de 2FLOW

Plus concrètement, l'interface d'une classe ensemble écrite en Java ressemble à ce qui suit :

class XXXVector {

private InstanciatedClasses referential;

private XXX xxx; // si XXX = Activite alors xxx = activites, etc.

public XXXVector( );
public void addXXX (XXX);
public XXX getXXXAt (int);
public XXX getXXX (String);
public void setXXXAt (int);
public void removeXXXAt (int);
public removeXXX (String);
public checkXXXExistence boolean (String);
public int public size ( );
}

Remarquons que l'interface rajoute un attribut de type Vector, au diagramme UML. Il sert de
conteneur pour les objets de la classe XXX. La vérification du type est assurée par les
méthodes de la classe ensemble dont les arguments sont du même type que celui pour lequel
XXXVector est prévu. Par exemple pour la classe ActivityVector la méthode addActivity(Activity a)
permet de s'assurer que l'on ajoute bien une activité au vecteur.

Les noms des méthodes membres des classes d'ensemble et leur utilisation sont inspirés en
partie de celles de la classe Vector de Java. L'intérêt de procéder de cette façon est de rendre
plus familière l'utilisation des classes d'ensemble aux développeurs souhaitant en ajouter de
nouvelles au framework.

144
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

[Link] La classe WorkflowObject

Les classes du métamodèle de 2FLOW sont toutes héritières d'une classe abstraite de base
appelée WorkflowObject. Nous rappelons qu'une classe abstraite n'a pas d'implémentation et
que son rôle est en général de proposer un type de base muni d'un ensemble de propriétés et
de comportements bien définis. Nous avons volontairement choisi de ne pas la représenter sur
le métamodèle de 2FLOW car elle ne correspond pas en réalité à une entité Workflow. Le but
de cette classe est de factoriser un ensemble de propriétés et de mécanismes communs aux
classes Workflows de base, dans un objectif d'optimisation du code : c'est donc une classe
auxiliaire. Il est cependant intéressant de se pencher quelque peu sur son interface et d'en
décrire rapidement le rôle et l'intérêt des attributs et des méthodes.

abstract class WorkflowObject {

protected String packageName;

protected String runningPackageName;
protected InstantiatedClasses referential;

public WorkflowObject( );
public String getPackageName( );
public String getRunningPackageName( );
public void setRunningPackageName(String);
abstract public initialize( );
public void setReferential(InstanciatedClasses);
synchronized public void wakeUp( );

L'attribut runningPackageName sert à identifier le package d'exécution de l'instance de la

classe, plus véritablement des instances des classes filles puisque WorkflowObject est
abstraite. Quant à l'attribut packageName, il correspond au nom du package où la classe a été
définie.

Dans la notation UML, un package est un ensemble de classes logiquement reliées, à forte
cohérence interne et faiblement couplée avec l'extérieur [MULLER 98], [ROQUES et al. 98].
L'intérêt des packages est de fournir un moyen de structuration dès lors que le nombre de
classes d'une application augmente.

Les liens existant entre des packages sont << auxiliaires >> << métamodèle >>
des liens d'utilisation - ou liens d'importation
- qui sont concrétisés par les relations créées ActivityVector
Activité
*
entre les classes des packages (fig. IV.19).
Un lien d'importation signifie que certaines << import >>
EventVector
classes du package importateur nécessitent * Événement

l'accès à des classes de l'autre package. Dans

le framework 2FLOW, nous distinguons
différents packages, parmi lesquels "le
package d'exécution" d'une classe, celui où
elle s'exécute, et son "package de : classe : package
définition", celui où elle est définie. Les
noms de ces deux packages sont : importation

respectivement consignés dans les attributs

packageName et runningPackageName. Figure IV.19 - Packages UML

145
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Dans 2FLOW, chaque workflow correspond à un package spécifique, appelé "package de

définition", dans lequel sont définies les classes de ses composants. Le package "d'exécution"
est celui où une classe est instanciée lors de la réalisation du workflow. En général, ces deux
packages sont identiques pour un composant 2FLOW, sauf dans le cas de l'héritage des
workflows. Il est donc important de différencier ces deux éléments car ils interviennent, dans
le mécanisme de mise en œuvre de la flexibilité - notamment de l'héritage - implémenté dans
2FLOW. Comme nous le verrons dans la suite de ce chapitre, la spécialisation des workflows
se base sur le mécanisme de spécialisation des classes d'objets, auquel nous en avons ajouté
d'autres spécifiques au Workflow.

Les méthodes getRunningPackageName( ) et getPackageName( ) de la classe WorkflowObject

permettent respectivement de récupérer la valeur des attributs runningPackageName et
packageName. La méthode setRunningPackageName(String) permet de spécifier à l'instance
d'une classe le package où elle doit s'exécuter, ce qui est pratique dans plusieurs cas,
notamment dans celui d'une exécution répartie du workflow sur des sites différents. Cet
ensemble de méthodes portant sur les packages est très important car il est à la base des
mécanismes d'exécution flexible de 2FLOW.

La méthode abstraite initalize ( ) donc sans implémentation, sert à initialiser l'instance d'une
classe d'objet Workflow. En effet, les instances sont le plus souvent créés à partir de
constructeurs sans arguments. Cette façon de procéder permet en effet à la classe
"instanciatrice" de ne pas avoir à faire de supposition sur le contenu de la classe qu'elle
instancie, mais uniquement à en connaître le nom. Le contenu de la méthode initialize( ) est
construit par le concepteur du workflow à l'aide d'un formulaire spécifique qui le décharge du
codage de la méthode. Ce formulaire fait partie d'un éditeur que nous avons développé pour la
création rapide de workflows basés sur 2FLOW.

La méthode setReferential(InstanciatedClasses) permet de fixer le référentiel auprès duquel les

instances de la classe devront s'inscrire. Cette méthode est très utile, en particulier quand
l'exécution du workflow est distribuée sur plusieurs sites ou pour la collaboration entre deux
processus. Il est en effet intéressant dans ce cas de pouvoir préciser à une classe à quel
référentiel elle appartient – donc auprès duquel elle doit s'inscrire - ce qui permet aux autres
classes du workflow de la retrouver et de s'en servir.

Nous ne détaillerons pas ici l'effet de la méthode wakeUp( ), que nous reverrons dans la partie
du chapitre concernant l'affichage des workflows.

[Link] L'interface RunnableComponent

L'interface RunnableComponent caractérise les objets concernés par la dynamique des

processus. Elle est donc implémentée par les classes de composants de 2FLOW qui sont
directement impliquées dans le flux d'exécution des workfows. Il s'agit des activités, des blocs
de contrôle de flux et des processus. RunnableComponent dérive d'une interface du langage
Java, nommée "Runnable", que doivent implémenter les classes que l'on souhaite associer à
des processus indépendants appelés "threads". La notion de threads est développée plus avant
dans le paragraphe [Link] car elle concerne la mise en œuvre de l'exécution des workflows.
Interface RunnableComponent extends Runnable {

int getState( );
void setState (int);

146
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

void start ( );
void run ( );
void resume ( );
void suspend( );
}

[Link] L'interface RunnableComponentStates

L'interface RunnableComponentStates permet de fixer sous une forme symbolique les états que
peuvent prendre les composants exécutables de 2FLOW (ceux qui implémentent l'interface
RunnableComponant) :

interface RunnableComponentStates {
int ACTIVATED = 0, WAITING = 1, APPOINTED = 2, RUNNING = 3, FINISHED
= 3, CANCELED = 4, STALLED = 5;
}

Il aurait été possible de représenter ces états sous une autre forme, par exemple à l'aide d'un
tableau de chaînes de caractères, correspondant chacune à un état donné. Le recours à une
interface permet cependant de créer un type de base régissant les états d'un composant
exécutable, ce qui lui permet d'être modifié, amélioré ou adapté aux besoins de d'éventuels
développeurs Workflows utilisant 2FLOW.

[Link] La classe StringVector

La classe StringVector est une classe auxiliaire du niveau utilitaire, c'est à dire qu'elle sert
uniquement comme outils de programmation. Comme son nom l'indique, cette classe est un
vecteur de chaînes de caractères, utilisé comme type pour certains attributs des classes de base
de 2FLOW.

class StringVector implements Serializable {

private Vector strings;

public StringVector( );
public StringVector(StringVector other);
public void addString(String s);
public void empty( );
public String getStringAt(int i);
public boolean isString(String string);
public void removeAllStrings( );
public void removeString(String string);
public void removeStringAt(int i);
public void replaceStringAt(String string, int index);
public int size( );
public String toString( );

Il existe encore quelques classes auxiliaires que nous n'avons pas encore évoquées, qui sont
les classes des exceptions internes aux classes du framework. Ces classes dérivent de la classe
"Exception" de Java et non de la classe Exception de 2FLOW car ce ne sont pas des exceptions
Workflows telles que nous les avons définies au chapitre 3. Nous ne détaillerons pas ici ces
classes car elles concernent des mécanismes de bas niveau du framework. Nous y ferons
néanmoins référence lorsque cela sera nécessaire au cours des explications qui vont suivre.

147
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

3.2.2 Exécution des workflows

[Link] Principe d'exécution propagée (ou distribuée)

Dans la majorité des cas, l'architecture des systèmes Workflow est centralisée, c'est à dire
qu'elle est composée de plusieurs éléments dont l'un est le c œur du système. Dans le chapitre I
nous avions donné une vision globale de l'architecture d'un système Workflow, en reprenant
le schéma de référence proposé par la Workflow Management Coalition. Ce schéma montre
que le composant principal de ces systèmes est représenté par le "moteur Workflow", encore
parfois appelé par abus de langage "serveur Workflow". Ce dernier est en fait la composante
chargée de l'échange des messages entre le système et les utilisateurs, ainsi que de
l'interconnexion des workflows en cours avec des ressources et/ou des processus distants. En
quelque sorte, on peut dire que le serveur "encapsule" le moteur Workflow. Globalement, le
rôle du moteur est d'exécuter les modèles de processus qui ont été établis au préalable dans la
phase de construction (build time). C'est lui qui instancie les éléments du modèle, qui les
exécute et qui se charge de leur élimination lorsqu'ils ne sont plus utiles. Le moteur transmet
également les messages aux listes de tâches (worklists) des acteurs des processus, via les
services du serveur.

L'approche adoptée dans 2FLOW est différente, principalement parce qu'il n'y a pas de
moteur Workflow. Nous avons en effet opté pour une exécution répartie des composants d'un
Workflow. Par répartie nous ne signifions pas (pour le moment) que l'exécution est distribuée
sur des sites géographiquement distants mais qu'elle est distribuée sur l'ensemble des éléments
du Workflow, qui peuvent à la limite être répartis sur différents sites. En d'autres termes,
chaque composant participe à l'exécution de l'ensemble du processus par l'intermédiaire des
comportements qui sont définis au niveau des classes de base du framework.
Instance y : classe Y 2.a.n+m : Création
Instance t : classe T
2.a.n : Création

1 : Création Instance initiatrice : classe X

Coopération des objets pour
la réalisation du processus
Classe U
2.b.n : Création
Instance z : classe Z

Classes non
instanciées
Classe W

Message entre objets [Link] : mise en parallèle nom : Classe : Instance d'une classe

nombre : Ordre chronologique

Figure IV.20 – Exécution et instanciation répartie des workflows sous 2FLOW

Réaliser les processus de façon collaborative apporte plus de flexibilité à l'exécution. En effet,
le principe de fonctionnement global du framework, que nous allons détailler sous peu,
consiste à n'instancier que les classes dont on a besoin à un instant t de l'exécution. Cela évite
d'une part de surcharger le système sous-jacent, et d'autre part, cela permet de modifier, en
cours d'exécution, les classes qui n'ont pas encore été instanciées. L'instanciation des classes
se fait par propagation, c'est à dire que chaque instance qui en a les compétences, instancie la
ou les classes avec lesquelles elle communique. Ainsi, toute classe du framework joue un rôle
déterminé qui lui permet d'apporter sa contribution à la réalisation de l'ensemble du processus.

148
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

On pourrait comparer l'exécution d'un workflow à une "vague de dominos", chaque pièce
propageant l'impulsion à une ou plusieurs autres, pour enfin réaliser l'ensemble d'une figure
(fig. IV.20).

Bien entendu, le rôle des classes ne se borne pas à en instancier d'autres. La réalisation du
workflow se fait donc en combinant les deux aspects : d'une part grâce au comportement
spécifique des classes qui leur permet de collaborer et de remplir leur "part du contrat", et
d'autre part, par l'instanciation d'autres classes – donc la propagation de l'exécution.

Jusqu'à présent, l'approche de l'exécution répartie (au sens où nous l'avons définie) est adoptée
par très peu de systèmes Workflows. Dans le paragraphe consacré à la comparaison de
2FLOW avec d'autres systèmes et d'autres architectures, nous nous intéresserons à la façon
dont deux systèmes Workflows (dont celui de Baan) la mettent en œuvre.

[Link] Notion de "thread"

Lors de l’exécution d’un programme, il est parfois intéressant de découper le flux d’exécution
principal en plusieurs autres flux - ou sous-processus - s’exécutant indépendamment. L’intérêt
de la création de sous-processus est de permettre la réalisation parallèle de différentes parties
d’un programme et/ou de répartir des tâches spécifiques sur des unités spécialisées. Par
exemple, supposons que l’exécution de certains composants d’une application est rattachée à
l’occurrence d’un événement ou à la libération d’une ressource. Il est alors préférable de les
dissocier du reste des composants de l’application afin de ne pas en suspendre inutilement
l'exécution. C’est, par exemple, le cas des interfaces graphiques ou l’on dissocie l’exécution
des composants qui réagissent à des événements (comme les boutons) du reste de
l’application. Un
thread

En Java, un thread est un processus "léger" ("light

weight process") [CAMPIONE et al. 97], un flux
séquentiel de contrôle indépendant, au sein d'un
programme. Un thread sert à isoler des tâches - au
sens large du terme - et permet leur exécution en
parallèle avec d'autres threads ( parmi lesquels celui
du programme principal). Un programme composé
de plusieurs threads est dit "multi-threadé". Pour
créer et manipuler des threads, Java fournit une Un programme Programme
classe appelée "Thread", ainsi qu'une interface à un seul thread multi-threadé
"Runnable" que toute classe "threadée" ne dérivant
pas de la classe Thread, doit implémenter. Figure IV.21 – Threads et Multi-
threadings

Nous nous intéressons particulièrement à deux méthodes des threads : "start( )" et "run ( )".
Start( ) signale au thread qu'il peut commencer et effectue certaines initialisations préalables
(qui sont à la charge du programmeur) avant d'appeler la méthode run( ) laquelle contient le
code à exécuter par le thread, tant qu'il n'est pas arrêté ou suspendu.

Si la possibilité d'isoler des tâches et de les exécuter en parallèle est un avantage indéniable
des threads, leur utilisation présente certains risques, en particulier lors de l'accès aux
ressources ou de l'appel de procédures. En effet, chaque thread étant une entité indépendante,
alors plusieurs threads d'un même programme peuvent tenter d'accéder simultanément à une
même ressource ou faire appel à une même fonction. Cela peut bien évidemment s'avérer

149
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

dangereux, par exemple lors de l'accès aux informations d'une base de données. Pour
empêcher l'accès simultané aux méthodes des autres objets par différents threads, Java
propose de synchroniser l'appel des méthodes, par le mot clé "synchronized". Une méthode ou
un attribut synchronisé ne peut être utilisé que par un seul thread à la fois.

La notion de thread est très importante pour le Workflow et en particulier pour 2FLOW, étant
donné que l'exécution des processus ou des sous-processus est souvent réalisée en parallèle et
qu'il y a des accès concourants aux ressources.

[Link] Initialisation des Workflows

L'exécution des workflows est principalement régie par deux composants fondamentaux que
nous avons traités dans le paragraphe consacré à la vue comportementale de 2FLOW. Il s'agit
des événements et des blocs de contrôle de flux. Dans les paragraphes qui vont suivre, nous
décrivons en détail les mécanismes qui sont mis en œuvre par ces deux composants dans la
réalisation des workflows, et par tous les autres composants concernés. Mais auparavant, il
convient d'apporter une nuance sur l'utilisation du terme "exécution". L'exécution d'un
workflow correspond à l'appel d'un programme exécutable (par exemple à partir de la ligne de
commande d'un système d'exploitation) et à la réalisation de l'ensemble de ses activités et
sous processus. Par ailleurs, nous employons souvent le terme "exécution" pour exprimer la
réalisation d'une activité au sein d'un workflow. Ainsi, sauf contre indication, lorsque les
termes "exécution" et "exécutable" sont associés à des composants de 2FLOW, ils concernent
respectivement la réalisation d'un composant, et sa capacités à générer son propre flux de
contrôle (thread).

Dans le framework 2FLOW, un workflow est représenté par la classe Processus, qui est la
première a être instanciée lors de l'initialisation du workflow. Indiquons ici que la classe
processus est exécutable - au sens Java - c'est à dire qu'elle contient une méthode main ( ), lui
permettant d'être exécutée en tant que programme. L'exécution d'un workflow construit à
l'aide de 2FLOW étant distribuée, nous avons dit dans le paragraphe [Link], que toutes ses
classes n'étaient pas immédiatement instanciées lors de son initialisation. En réalité,
l'initialisation d'un processus entraîne la création simultanée d'un nombre minimum d'objets
qui vont permettre au workflow de "démarrer".

En tout premier lieu, le processus crée le référentiel du workflow auprès duquel toutes les
instances des classes participant au processus devront s'inscrire lors de leur création,
processus inclus. Chaque processus crée son propre référentiel lorsqu'il est instancié. Si un
sous-processus est créé au sein d'un autre processus, il s'enregistre d'abord dans le référentiel
de ce dernier avant de créer son propre référentiel et de s'y inscrire.

La deuxième étape consiste à instancier les classes des acteurs susceptibles de participer au
processus. Rappelons que l'affectation d'acteurs au processus se fait pendant la phase de
modélisation - lors de la création de la classe processus - en indiquant leur nom, qui
correspond à celui de leur classe. Le nombre d'acteur n'est toutefois pas figé lors de la
modélisation. En effet, le nom des acteurs impliqués dans le processus est stocké dans un
attribut de la classe Processus appelé "actorsNames", de type StringVector, qui n'est pas de
dimension fixe. La classe Processus dispose également d'une méthode particulière appelée
"addActor (Actor)", permettant d'ajouter un acteur au processus au cours de son exécution.
Nous reviendrons plus en détail sur l'ajout d'éléments à un workflow en cours d'exécution
dans la partie du chapitre dédiée à la flexibilité.

150
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Enfin la dernière étape consiste en l'émission d'un événement générique Start qui va instancier
les premières activités du processus – celles auxquelles il est relié. Le mécanisme utilisé par
Start est identique à celui de la classe Evénement de 2FLOW.

Les paragraphes qui vont suivre affinent encore un peu plus la granularité et la technicité de la
description du fonctionnement des composants de 2FLOW. Le lecteur ne souhaitant pas
rentrer dans ces détails peut contourner ces paragraphes, quitte à y revenir par la suite, pour
une meilleure compréhension du framework.

3.2.3 Comportement et collaboration des composants de 2FLOW

[Link] Evénements

Dans 2FLOW, un événement est émis par une activité ou est créé en conséquence d'un fait
externe au workflow. Dans le premier cas, l'activité concernée instancie la classe
correspondant à l'événement. Dans l'autre cas, les événements sont "injectés" dans le
workflow par les utilisateurs du système via leur interface ou par des applications externes via
des points d'entrée du système.

Une fois l'événement créé, trois possibilités – non-exclusives – se présentent :

§ L'événement peut être relié à une ou plusieurs activités en sortie, dont les noms sont
contenus dans un attribut activitiesNames de type StringVector. Afin de propager
l'exécution, l'événement doit notifier au moment de son émission les activités
auxquelles il est relié. Pour ce faire, il doit au préalable vérifier que ces activités ont
été instanciées, ce qu'il fait en invoquant la méthode checkClassExistence(nom de
l'activité) du référentiel. Chaque classe n'étant pas encore référencée – donc non
instanciée – l'est alors par l'événement. L'ensemble des activités est par la suite notifié
de l'occurrence de l'événement via l'invocation de la méthode getActivated( ) de la
classe activité, qui la fait passer à un état d'attente identifié par WAITING.

§ L'événement est relié en sortie à une ou plusieurs expressions logiques. Un autre

attribut de type StringVector, nommé logicalExpressionsNames contient les noms des
expressions logiques à notifier. La procédure de notification est similaire au cas
précédent, c'est à dire que l'objet événement doit au préalable vérifier l'existence des
instances des expressions logiques auprès desquelles il doit s'inscrire. Les expressions
n'ayant pas encore été instanciée sont créées par l'objet événement qui s'inscrit par la
suite auprès de l'ensemble des expressions logiques, via l'invocation de leur méthode
registerEvent(l'événement).

§ Enfin, l'événement peut déclencher un ou plusieurs processus lors de son occurrence.

Par conséquent, la classe Evénement dispose d'un autre attribut, processesNames de
type StringVector, dans lequel sont stockés les noms des processus déclenchés par
l'événement en question. Ici aussi, la notification des processus se fait de manière
similaire aux deux situations précédentes.

Remarquons que l'événement peut être à la fois lié à des activités, à des expressions logiques
et à des processus. L'ensemble des possibilités est testé lors de l'instanciation d'un événement,
par l'appel de la méthode notifyNext( ) de la classe. Enfin, les références des activités et des

151
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

expressions logiques instanciées sont respectivement stockées dans les attributs activities de
type ActivityVector et expressions de type LogicalExpressionVector.

:InstanciatedClasses
* [ := 1.. nbr élements]
3 : checkClassExistence(nom classe
)
1 : créer
:Evénement * [ 1.. nbr éléments ] : 5 : activation
:Elément à notifier

2 : notifyNext( )

* [:= 1.. nbr éléments non Éléments à notifier : terme générique pour désigner les activités,
instanciés ] : 4.a : créer les expressions logiques et les processus
activation : terme générique pour désigner la méthode
:Elément à notifier permettant d’activer l’instance de la classe =
• getActivated( ) pour les activités et les processus
• registerEvent pour les expressions logiques
créer : terme générique pour désigner le constructeur de
la classe

Figure IV.22 –Diagramme de collaboration décrivant les tâches d'un événement

[Link] Exceptions

Dans 2FLOW, nous distinguons deux niveaux d'abstraction pour représenter les exceptions,
que nous qualifions pour le premier de "niveau Workflow" et le second de "niveau interne".
Les exceptions Workflows correspondent à la définition que nous avons donnée au chapitre
III : elles concernent directement la logique d'exécution du processus, au niveau duquel elles
sont situées. Les exceptions internes quant à elles, sont localisées au niveau des mécanismes
des classes de 2FLOW, c'est à dire qu'elles traitent des problèmes liés à l'implémentation et à
l'utilisation des classes du framework en tant qu'objets informatiques et non en tant qu'entités
Workflows.

Une exception Workflow est donc un événement Workflow - certes particulier - dont elle
récupère l'ensemble des propriétés. Le fait d'assimiler une exception à un type d'événement
particulier présente un intérêt majeur. En effet, nous avons vu que tout événement disposait
d'un ensemble d'activités et d'expressions logiques à notifier. Elles correspondent, dans le cas
des événements, aux activités du flux normal du workflow. Nous avons vu dans le chapitre III
que le traitement d'une exception est le plus souvent réalisé à l'aide d'un gestionnaire dont le
travail est de déclencher une procédure spécifique. Il s'agit en général d'une activité ou d'un
processus particuliers. Par conséquent, l'émission d'une exception résulte en l'exécution d'une
certaine tâche (au sens large). Or c'est justement ce que font les événements de 2FLOW, il est
donc logique qu'une exception puisse tirer profit de ce comportement.

La classe ExceptionWorkflow représente le niveau le plus générique des exceptions d'un

processus. A l'instar des autres classes de 2FLOW, elle doit être spécialisée lors de
l'élaboration de workflows mais peut également être directement utilisée. Dans ce cas, elle
peut être associée par défaut à toutes les activités d'un processus, pour absorber par exemple
les situations imprévues.

152
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

[Link] Blocs de Contrôle de Flux

Si la dynamique des workflows est engendrées par les événements, son contrôle est du ressort
des blocs de contrôle de flux (BCF). Les BCF sont des classes de 2FLOW dédiées au contrôle
du flux des activités, c'est à dire de l'ordre dans lequel elles vont s'exécuter. Nous distinguons
trois sortes de BCF correspondant aux trois types de flux : séquentiel, parallèle et bouclé,
dérivant tous de la même classe abstraite de base BCF.

Globalement, le fonctionnement générique d'un BCF est le suivant : tout composant

exécutable (RunnableComponent) qui est placé sous le contrôle d'un BCF doit s'inscrire auprès
de ce dernier lors de son instanciation. La référence à cet élément est ajoutée à un vecteur de
composants, représenté par l'attribut components du BCF. Les composants concernés sont les
activités, les processus et les BCF. Ceux-ci possèdent tous deux attributs respectivement
nommés containerCFBname et containerCFB. Le premier contient le nom du BCF auquel
appartient le composant exécutable, il est défini lors de la modélisation. Le second attribut
contient la référence du BCF conteneur, qui est impérativement obtenue au moment de
l'instanciation du composant par l'invocation automatique de sa méthode setContainerCFB( ).
L'inscription auprès du BCF conteneur se fait ensuite par l'appel de la méthode
registerComponent(RunnableComponent) de ce dernier, en lui passant le composant exécutable
comme argument.

Une fois le composant inscrit chez le BCF, il doit attendre la satisfaction d'une certaine
condition dépendant du type du BCF, avant de pouvoir s'exécuter. Une fois la condition
satisfaite, le BCF invoque la méthode start( ) du composant exécutable.

Enfin, tout composant ayant achevé son exécution doit en rendre compte au BCF qui le
référence, en appelant la méthode notifyFinished(RunnableComponent) de ce dernier, et en se
passant lui-même en argument (pointeur "this"). Quand tous ses composants ont terminé, le
BCF passe à l'état FINISHED et notifie à son tour son BCF conteneur. Remarquons que si le
BCF est le premier de la hiérarchie – ce qui est indiqué lors de la modélisation à l'aide d'un
attribut booléen isMaster initialisé à "vrai" - alors il n'a évidemment pas à s'envoyer de
notification.

Le fonctionnement générique d'un BCF et ses échanges avec son environnement sont
représentés par le diagramme de séquence de la figure IV.23 :

:RunnableComponent :BCF components containerCFB

:ComponentVector :BCF

RegisterComponent(this)

addComponent(component)
[ si condition satisfaite ] :
start ()

[ if finished ] :
notifyFinished(this)
Si tous les composants
ont terminé :
notifyFinished(this)

Figure IV.23 - Echanges génériques d'un BCF dans son environnement

153
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

BCF Séquentiels

Les BCF séquentiels permettent d'assurer que les éléments qui les composent sont exécutés de
façon séquentielle. Au premier abord, il peut paraître étrange d'avoir à introduire un
contrôleur de flux séquentiel, puisqu'il semble logique que les activités soient réalisées "par
défaut" de façon séquentielle, notamment grâce aux événements de fin d'activité. Toutefois,
laisser l'exécution à la seule responsabilité des événements peut parfois poser des problèmes
et il est nécessaire d'y apporter un contrôle. Pour le démontrer, considérons l'exemple suivant,
illustré par la figure IV.24 :

Comme on peut le constater sur la figure, A 4.1 A 4.1.1

chacune des trois premières activités est A1 A2 A3
initialisée par la fin de l'activité précédente. XOR A 4.2
Quant aux deux activités 4.1 et 4.2, elles A 4..2.1

sont réalisées de façon exclusive à la fin de E1 OR

la troisième. La présence de l'exclusivité

assure que le flux reste séquentiel, puisqu'il Figure IV.24 – Exemple de l'intérêt d'un bloc
n'y a qu'un chemin choisi malgré la de contrôle de flux séquentiel
présence des deux cas possibles.
Dans le premier, l'activité 4.1.1 est exécutée après l'achèvement de l'activité 4.1, tandis que
dans le second cas, l'activité 4.2.1 est initialisée soit par l'occurrence de l'événement E1, soit
suite à la fin de l'activité précédente, ce qui est exprimé par le OR. Puisque l'exécution de
l'activité 4.2.1 dépend indifféremment de deux événements, alors si E1 a lieu avant la fin de
l'activité 4.2, rien n'empêche l'activité 4.2.1 de démarrer. Le problème se pose si l'événement a
lieu avant l'achèvement de A 3, par exemple en cours d'exécution de A 2. En effet, dans ce cas
il n'est pas possible de savoir quel chemin a été choisi – A 4.1 ou A 4.2 - puisque le choix ne
se fait qu'à la fin de A 3. Par conséquent réaliser l'activité A 4.2.1 risque de poser un problème
si ce n'est pas le chemin qui aurait du être pris.

Le bloc de contrôle de flux séquentiel (BCF_S) apporte un contrôle au niveau de la réalisation

des activités qu'il contient. Pour ce faire, le BCF_S dispose de l'attribut awaitingComponents de
type RunnableComponentVector. Cet attribut sert de file d'attente dans laquelle sont placés les
composants, dans l'ordre où ils doivent s'exécuter. Cet ordre est déduit de l'attribut
componentsNames dans lequel les noms des composants ont été stockés lors de la
modélisation, dans leur ordre chronologique d'exécution. Notons à propos que cet attribut sert
également à valider l'inscription de tous les objets venant s'enregistrer dans le BCF. Un objet
référencé par la file d'attente ne peut s'exécuter tant que son tour n'est pas arrivé. Pour
effectuer cette régulation, le BCF séquentiel est muni d'un attribut particulier nommé
nextToRun et de deux méthodes : addToAwaitingComponents(RunnableComponent) et
startNextComponent( ). La première méthode est appelée lors de l'inscription d'un nouveau
composant dans le BCF. Son rôle est de comparer la position du composant qu'on lui passe en
argument avec celle des composants en attente, en prenant le vecteur componentsNames pour
référence. Si le composant vient après ceux qui sont déjà en attente, il est ajouté à la fin de la
file. Sinon, le composant y est inséré à la place qui lui revient ou au début de la file, si les
composants qui devraient le précéder n'ont pas encore été instanciés.

Pour exécuter les composants en attente, la méthode addToAwaitingComponents fait appel aux
services de startNextComponent( ). Cette dernière compare le nom de la classe de l'instance se
trouvant au début de la file avec le nom de celle qui se trouve à la position nextToRun dans le
vecteur de noms. Cet attribut est un indice servant à repérer la prochaine activité à exécuter.

154
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Lors de l'instanciation du BCF, nextToRun contient la valeur de l'indice du premier élément du

vecteur de noms, soit 0. Au fur et à mesure que les activités sont exécutées, l'indice est
incrémenté de 1. Ainsi à chaque nouvel ajout d'un élément dans la file d'attente, la méthode
startNextComponent vérifie si le nom de la classe du premier élément correspond bien à celui
du composant qu'il faut exécuter. Si c'est le cas, le BCF_S invoque la méthode start( ) du
composant en question et incrémente nextToRun de 1. Une fois que le composant s'achève, il
en informe le BCF via la méthode notifyFinished(RunnableComponent) de ce dernier, qui le
retire aussitôt de la file d'attente et appelle à nouveau la méthode startNextComponent. Nous
résumons ce mécanisme dans la figure IV.25 :
nextToRun nextToRun

Vecteur de noms
A1 A2 A3 A4 A1 A2 A3 A4

Comparaison des noms des Comparaison des noms des

Insertion de A2 classes classes
dans la file ?
?
OK suppression de OK
start( ) A2 de la file
A2 A3 A2 A2 start( )
A4 A3 A3
A3 A2 A3
A4 A4
Composants en A4 A4
attente
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5

Figure IV.25 - Fonctionnement d'un BCF séquentiel

En réalité, si les mécanismes de contrôle des BCF_S résolvent le problème de l'exécution

"anarchique" des composants, leur rigidité apporte d'autres problèmes dans certains cas. En
effet, reprenons l'exemple du processus d'admission d'un patient dans un hôpital, pour une
opération. Nous avions dit que l'activité "opérer" était enclenchée à un jour J, à la condition
que le dossier médical du patient soit prêt (ce dernier étant préparé après acceptation de son
dossier administratif). Or il semblerait plus pertinent de prendre en compte le fait où le cas du
patient étant tellement urgent, il faut opérer immédiatement, sans préparation préalable de
dossier. Le processus pourrait alors ressembler à ce qui suit :

Dossier Dossier
administratif médical

ET OU
Etablir dossier Etablir dossier Opérer Facturer
administratif médical
Arrivée d’un
patient
Date

€ € € €
Urgence
opération

Agent Médecin chef Chirurgien Agent

administratif du service Comptable

Evénement
€ Rôle Données opérateur

Activité Flux des tâches Flux d’informations

Figure IV.26 - Exemple revisité du processus d'acceptation d'un patient

155
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Dans ce processus, les activités sont bien exécutées séquentiellement - surtout dans le cas
"normal" - le cas "anormal" étant représenté par la nécessiter d'opérer le patient d'urgence.
Dans cette situation, il est nécessaire de "brûler" les deux premières étapes pour commencer
directement par l'activité "opérer". Or si ces activités sont gérées par un même BCF_S, les
mécanismes de contrôle de ce dernier font qu' "opérer" ne pourra s'exécuter avant la fin des
activités précédentes, même si l'événement "urgence" a lieu.

Pour résoudre ce problème, nous proposons deux solutions : la première consiste à munir les
classes Activité et Processus d'un opérateur booléen que nous nommons isFree. Ce dernier, s'il
est mis à "vrai" lors de la modélisation, indique que l'activité en question a le droit de
s'exécuter, même si elle n'est pas candidate dans la file d'attente.

La deuxième solution est similaire et consiste à introduire dans ces mêmes classes, un
opérateur booléen nommé isExceptional, dont la mise à "vrai" rendrait possible l'exécution
anticipée d'un composant. En effet, nous avons dit que le besoin d'opérer d'urgence un patient
correspondait à un cas "anormal", donc exceptionnel. Par conséquent, l'événement urgence
pourrait correspondre à une exception, dont la prise en charge est assurée par l'activité
"opérer". En effet, rien n'empêche d'utiliser les mêmes activités d'un processus pour traiter les
exceptions. Nous avons donc décidé de munir les classes Activité et Processus d'une méthode
appelée setExceptional( ) pouvant être invoquée par des exceptions auxquelles ces classes
seraient reliées. L'appel de cette méthode affecterait la valeur "vrai" à l'attribut isExceptionnal,
rendant alors possible l'exécution de l'activité ou du processus en question.

Techniquement, ces deux solutions répondent efficacement au problème posé. Toutefois, il est
important de se poser la question de savoir comment est réalisé la suite du processus, après la
réalisation d'un composant "libre" ou "exceptionnel". En effet, dans le cas de notre exemple,
même si l'opération a lieu, il est impératif de dresser les dossiers administratifs et médicaux
du patient. Par conséquent, une fois l'activité "opérer" terminée, il est nécessaire de reboucler
vers les étapes précédentes et non de continuer vers la facturation. Le problème ne se situe
alors plus au niveau du framework, mais à celui de la phase de conception qui doit aboutir à
une modélisation juste et efficace de la situation. Dans le cadre de l'exemple, le modèle
proposé est incomplet et il est nécessaire d'y introduire des boucles et des conditions qui
permettent de reprendre l'ordre normal - établir les dossiers – sans bien sûr repasser par
l'activité "opéreré".

Pour clore le paragraphe sur les BCF_S, nous allons reprendre l'exemple de la figure 4.23 que
nous avions utilisé pour expliciter l'intérêt des BCF_S. La représentation interne de ce cas
dans un BCF_S de 2FLOW est la suivante :

L'ensemble des activités est contenu dans un BCF_S1

A1 A2 A3 BCF_S2 BCF_S3
BCF_S principal appelé BCF_S1. Etant
donné que l'activité A3 donne lieu à un choix
exclusif, les activités suivantes sont placées BCF_S2 A 4.1 A 4.1.1
dans des BCF_S distincts (BCF_S2,
BCF_S3), puisque chaque choix correspond à BCF_S3 A 4.2 A 4.2.1
un flux spécifique. Ces deux blocs sont
cependant positionnés séquentiellement dans
le bloc principal. Figure IV.27 - Composition d'un BCF_S

156
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Si l'on applique les mécanismes de 2FLOW que nous avons déjà présentés, alors BCF_S3 ne
peut être réalisé avant BCF_S2, puisqu'ils sont disposés dans cet ordre. De plus, si c'est la
première activité de BCF_S3 qui est instancié par le choix exclusif, elle ne pourra jamais
s'exécuter étant donné que BCF_S2 n'a pas encore été réalisé. Il y a donc un blocage et pour le
résoudre, nous avons ajouté une règle à la méthode startNextComponent. Cette règle dit que si
plusieurs BCF_S sont consécutifs dans un autre BCF_S, alors c'est le premier à s'exécuter qui
est pris en compte. Le pointeur nextToRun est ensuite déplacé jusqu'à l'élément suivant le
dernier BCF_S. En effet, on ne peut avoir de BCF_S consécutifs que dans le cas où leur
première activité dépend d'un choix exclusif, ce qui est notre cas dans l'exemple. Remarquons
que si le choix est multiple (un OU), alors certains BCF risquent de s'exécuter en parallèle et
il est donc nécessaire de les inclure au préalable dans un bloc de ce type.

BCF parallèles

Un BCF parallèle (BCF_P) permet d'exécuter ses composants en parallèle. Le type bloc
parallèle est le moins contraignant au niveau de l'exécution. En effet, nous avons vu que
chaque composant exécutable est muni de deux méthodes start et run, qui permettent de
l'exécuter en tant que thread indépendant. Le travail d'un BCF_P se limite donc à enregistrer
les références des instances de ses composants et d'en invoquer la méthode start pour lancer
leur exécution. A l'instar des autres BCF, le BCF_P est notifié de la fin de chaque composant
ce qui lui permet à son tour de signaler qu'il a terminé à son BCF conteneur.

BCF Boucles

Bien que 2FLOW prévoie deux types de BCF boucles (BCF_B), nous n'en avons implémenté
qu'un au niveau du framework, qui est le BCF_For. Ce bloc permet d'exécuter un nombre n
fixé de fois l'ensemble des composants qu'il contient. Notons bien que c'est l'ensemble qui est
exécuté n fois et non chaque composant individuellement. Pour ce faire, le BCF_For dispose
d'un attribut appelé internalCounter qui est incrémenté à chaque fois que les composants du
BCF sont tous terminés. La boucle se poursuit tant que le compteur n'atteint pas la valeur
fixée dans l'attribut numberOfLoops fixé lors de la modélisation.

[Link] Activités

Nous avons vu que dans 2FLOW, il n'y a pas de distinction entre activités "humaines" et
activités "automatiques". La distinction est transparente au niveau du système ainsi qu'au
niveau du concepteur du workflow qui n'a qu'à se préoccuper d'identifier le ou les rôle(s)
nécessaire(s) à la réalisation d'une activité. Par conséquent, le travail de la clase Activité dans
le framework se limite à deux choses :

1. Signaler à un acteur qu'il a été sélectionné pour la réaliser.

2. Emettre, au besoin, des événements dont un par défaut, celui marquant la réalisation de
l'activité. Ces événements sont destinés à d'autres activités ou à des expressions logiques.

Nous allons donc examiner la façon dont les activités de 2FLOW prennent en charge ces deux
tâches :

1. La notification d'un acteur de la présence d'une activité à exécuter est réalisée par
l'invocation de la méthode notifyActor( ) de la classe Activité. Cette méthode, dont nous

157
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

décrivons le fonctionnement dans les paragraphes suivants, se décompose en deux parties:

la première se charge de sélectionner un acteur, et la deuxième lui signifie qu'il doit
exécuter l'activité en question.

Nous avons dit que lors de la modélisation d'un workflow, il suffit au concepteur
d'associer le nom des rôles pouvant réaliser les activités à ces dernières. On peut imaginer
toutefois que ce concepteur émette une certaine préférence pour l'un ou l'autre des acteurs
lors de l'attribution effective de l'activité à l'un d'entre eux. Nous avons donc prévu dans le
framework de permettre aux concepteurs de spécifier un niveau de préférence pour le
choix d'un acteur dans le traitement d'une activité. Pour ce faire, nous avons, entre autres,
doté la classe Activité de quatre attributs spécifiques : "roleName", "actorName", "actor" et
"demandLevel".

class Activity extends WorkflowObject implements RunnableComponent{

...
protected String roleName;
protected Actor actor;
protected int demandLevel;
protected String actorName;

...

L'attribut roleName correspond au nom du rôle pouvant réaliser l'activité. Il est

impérativement défini lors de la modélisation. La valeur de cet attribut est nécessaire et
suffisante pour permettre à l'activité de s'exécuter.

Préférence pour un acteur

L'attribut actorName correspond au nom de l'acteur qui devrait être choisi de préférence.
Cet attribut peut ne contenir aucune valeur mais s'il en a, il s'agit de définir à quel point il
est important que ce soit cet acteur qui traite l'activité. Cela est réalisé à l'aide de l'attribut
demandLevel, qui peut prendre les valeurs 0, 1 et 2, 1 étant la valeur par défaut. Le 0
indique que n'importe quel acteur tenant le rôle indiqué par roleName est susceptible d'être
sélectionné. La valeur 1 indique que si le nom d'un acteur a été fourni, alors celui-ci devra
être choisi en priorité, en fonction de ses disponibilités. En d'autres termes, si l'acteur en
question n'est pas disponible, alors n'importe quel autre tenant le même rôle pourra
convenir. Enfin, la valeur 2 est la plus contraignante puisqu'elle indique que seul l'acteur
dont le nom a été mentionné doit exécuter l'activité.

Situations bloquantes

Choisir une préférence (demandLevel) de niveau 2 pour le choix de l'acteur peut amener à
des situations bloquantes où l'acteur n'étant pas disponible (par exemple, s'il est en
vacance), l'activité n'est jamais réalisée. Pour éviter ce blocage et le résoudre s'il a lieu,
nous avons prévu dans 2FLOW des algorithmes de détection et de résolutions de
situations bloquantes. En effet, lors de l'affectation d'un acteur à la réalisation d'une
activité, cette dernière passe à l'état d'APPOINTED - donc affectée. Lorsque l'acteur
commence à exécuter l'activité, celle-ci passe - nous verrons comment - à l'état de
RUNNING, donc en cours d'exécution. L'algorithme de détection de blocage que nous

158
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

avons implémenté a comme principe de vérifier que l'activité passe suffisamment vite de
l'état d'affectation à celui d'exécution. Dans le cas contraire, un blocage est détecté et
l'activité passe à l'état STALLED. La solution consiste ensuite à "casser" la contrainte et
rechercher un autre acteur disponible. Dans 2FLOW, la détection du blocage se fait au
niveau de l'activité. Si l'acteur n'est pas trouvé, une exception NoActorFoundException est
émise par l'activité, puis prise en charge par un gestionnaire approprié qui met en œuvre la
solution de relaxation de la contrainte.

Deux questions se posent quant au traitement de cette exception :

§ La détection des blocages et leur résolution doit-elle se faire au niveau de l'activité ou

au niveau d'un gestionnaire d'événements ? Vaut-il mieux encore, ainsi que nous
l'avons choisi, répartir la tâche entre les deux : détection et émission d'une exception
par l'activité, puis résolution par un gestionnaire approprié ?

§ La contrainte sur le choix d'un acteur peut-elle être allégée par l'activité elle-même ou
faut-il faire remonter le problème à un autre niveau, par exemple vers le concepteur du
workflow ? Tout en étant conscient du fait que cette procédure peut être coûteuse en
temps.

Au niveau de la version actuelle de 2FLOW, nous en restons à la méthode que nous avons
choisie, c'est à dire laisser à l'activité le soin de détecter un blocage et d'émettre une
exception en direction du gestionnaire approprié. Nous rediscuterons néanmoins de cette
question dans le paragraphe sur la flexibilité dans 2FLOW.

Sélection d'un acteur

Dans les cas où le niveau de préférence sur l'acteur est de 0, la recherche de l'acteur
approprié s'effectue par l'activité via les services du référentiel, où est répertorié
l'ensemble des objets créés dans le workflow. Pour ce faire, le référentiel fournit une
méthode appelée retrieveInterfaceImplementor(String). Cette dernière effectue une recherche
sur les classes du référentiel en comparant le nom des interfaces implémentées par les
objets testés. Dans sa tâche, cette méthode en fait appel à une deuxième nommée
"getInterfaces( )" implémentée par la classe "Class" définie par le langage Java. Les
instances de cette classe sont en fait les autres classes écrites en Java, pour lesquelles elle
est donc une sorte de métaclasse commune. Son grand intérêt est de proposer des
mécanismes réflexifs sur les classes, permettant à tout objet Java de connaître la
généalogie de ses ancêtres (classes mères, grands-mères, etc.), l'ensemble de ses attributs
et de ses méthodes (hérités ou propres) ainsi que les interfaces qu'il implémente, grâce à la
méthode "getInterfaces( )".

La méthode retrieveInterfaceImplementor(String) du référentiel 2FLOW renvoie la référence

de l'instance du premier acteur implémentant le rôle dont le nom est passé en argument à
la méthode. Cette référence est stockée au niveau de l'activité dans l'attribut actor.

Dans le cas où la préférence sur le choix de l'acteur est de niveau 2, alors l'activité invoque
la méthode retrieveObject(String) du référentiel, en lui passant le nom de l'acteur comme
argument. Cette méthode renvoie elle aussi une référence vers l'objet acteur, stockée dans
l'attribut actor.

159
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Enfin si la préférence est de niveau 1, alors l'activité tente d'abord de récupérer l'acteur
grâce à retrieveObject( ) ou fait appel à la méthode retrieveInterfaceImplementor(String) en cas
d'échec.

Notification d'un acteur

Une fois la référence de l'acteur connue, il s'agit de lui "demander" de réaliser l'activité en
question. En effet, nous avons dit que chaque activité associée à un rôle correspond à une
méthode des acteurs implémentant le rôle. Par conséquent pour réaliser une activité, il
convient d'invoquer la méthode correspondante chez l'acteur sélectionné. C'est le travail
de la deuxième partie de la méthode notifyActor( ). Il consiste à récupérer la signature de
l'ensemble des méthodes de l'acteur, à l'aide de la méthode "getMethods( )" de la classe
"Class". Celle-ci renvoie un tableau d'objets de la classe "Method" de Java duquel on
extrait la méthode ayant le même nom que l'activité. Cette classe dispose d'une méthode
appelée "invoke( )", permettant d'invoquer indirectement la méthode d'un objet en lui
passant la référence de celui-ci et un tableau d'arguments. Ceux-ci consistent en général en
un vecteur de références sur les artefacts nécessaires à la réalisation de l'activité, ainsi que
la priorité de l'activité. Ces notions seront approfondies par la suite. Le code ci-dessous est
extrait de notifyActor( ) et permet d'illustrer cette procédure :

actorMethods = ([Link]()).getMethods();
className = [Link]([Link]('.') + 1,
[Link]()); // permet de récupérer le nom de la classe sans
ses packages
for (int i = 0;((i < [Link]) && (!found)); i++) {
String methodName = actorMethods[i].getName();
methodName = [Link]([Link]('.') + 1,
[Link]());
if (([Link]()).indexOf([Link]()) > -1)
{
found = true; // transforme le nom de la classe en minuscule
toInvoke = actorMethods[i];
}
}
...
[Link](actor, new Object[0]);// invocation de la méthode

2. Outre la notification des acteurs, l'autre "tâche" des activités consiste à émettre des
événements. En fait, mis à part les événements de fin et de blocage, une activité ne sait
pas d'elle-même quel événement il faut envoyer. C'est donc soit par l'intervention des
méthodes des acteurs, soit par des objets extérieurs que les événements sont émis. Pour ce
faire, la classe Activité dispose de la méthode sendEvent(String) qui indique à l'activité
qu'elle doit émettre l'événement dont le nom est passé en argument. Par ailleurs, la classe
Activité dispose de deux attributs, eventClasses, de type StringVector, qui contient les noms
des événements qu'elle peut émettre et events, de type EventVector, qui contient la
référence des instances d'événements créés par l'activité. Les noms des événements émis
par l'activité sont à ajouter à l'attribut eventClasses lors de la modélisation. Il convient bien
entendu que les classes de ces événements soient définies au préalables ou au même
moment. A l'opposé, le vecteur d'événements n'est rempli qu'au fur et à mesure de leur
émission.

160
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Priorité d'une activité

Un acteur pouvant tenir plusieurs rôles, il est possible qu'il se voie affecté de plusieurs
tâches à réaliser. Certaines tâches pouvant être plus importantes que d'autres, nous avons
introduit un attribut nommé priority, dont la valeur, comprise entre 1 et 10, permet
d'indiquer la priorité d'une activité sur les autres. Nous avons choisi cet intervalle car il
correspond aux priorités des threads de Java. La priorité d'un thread fait qu'il sera choisi
par l'ordonnanceur ("scheduler") de Java avec plus ou moins d'avantage, pour être
exécuté. La priorité d'une activité s'applique à deux niveaux : au niveau de l'exécution des
méthodes run dans un BCF, et au niveau des acteurs qui classeront les appels de méthodes
par ordre de priorité. Remarquons que la priorité d'une activité au premier niveau ne
s'applique que dans les BCF parallèles où l'ordre d'exécution est libre. Dans les autres cas,
seule la priorité au niveau de l'acteur est appliquée.

8 10 2 8 10 2
BCF_S BCF_P
A1 A2 A3 A1 A2 A3

A1 A1
A2 A2
A3
A3
A2
A2
A1
A3

activité flux
Temps imparti à priorité
l'exécution

Figure IV.27 - Priorité des threads d'activité dans les BCF

Evénements génériques

La classe Activité émet deux événements génériques, l'un est l'instance de la classe
EndOfActivity qui sert à signaler la fin de l'activité et l'autre, issu de la classe ActivityStalled
sert à signaler une situation de blocage. L'événement EndOfActivity est émis
automatiquement par une activité lorsqu'elle prend fin. Elle en invoque les méthodes
setActivites(StringVector) et setExpressions(StringVector), en leur passant respectivement les
noms des activités suivantes et des expressions logiques à notifier de la fin de l'activité.
: Activité : InstanciatedClasses : BCF : Acteur : EndOfActivity

getActivated( )
addObject(this)

registerComponent(this)

[Acteur trouvé ] : exécute activité

[ si pas de problème ] : finish( )

notifyFinished(this)

créer

Figure IV.28 –Collaboration de la classe Activité avec son

environnement

161
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

[Link] Acteurs

Les classes d'acteurs sont, nous l'avons dit, les représentantes informatiques des vrais acteurs
du workflow. Au niveau de la classe abstraite de base, seuls sont définis les comportements et
les propriétés fondamentales d'un acteur. Parmi ceux-ci, nous nous intéressons
particulièrement à la façon dont un acteur gère l'invocation de ses méthodes, et aux
différences qui existent entre acteurs humains et acteurs automatiques.

Gestion des tâches

Dans le paragraphe concernant les activités, nous avons introduit la notion de priorité en
mentionnant les niveaux où elle s'applique, notamment celui de l'acteur. Nous n'avons
toutefois pas précisé la façon dont ces priorités étaient prises en compte lors de l'appel des
méthodes des acteurs. Par ailleurs, la partie de code que nous avons montrée, ne correspond
en fait qu'à l'un des deux cas de figures qui se sont présentés lors de la conception du
framework, et qui sont :

1. La délégation de la gestion des tâches à l'acteur réel.

2. La gestion localisée des tâches au niveau de l'acteur 2FLOW.

1. Dans le premier cas, on décide de laisser le vrai acteur gérer lui-même la façon de traiter
les activités qui lui sont affectées, et par conséquent leurs priorités. L'approche consiste
uniquement à invoquer les méthodes des acteurs sans se préoccuper de leur gestion -
comme c'est le cas dans le code que nous avons montré. Les références des activités qui
invoquent les méthodes des acteurs sont stockées dans un vecteur nommé activities. Ce
dernier est utilisé par chaque méthode d'un acteur pour signaler à l'activité en question
qu'elle a terminé - ou qu'elle est bloquée.

Le choix de laisser le vrai acteur gérer lui-même ses activités n'est pas une façon de
contourner le problème. En effet, nous le verrons par la suite, les méthodes d'un acteur
2FLOW effectuent un traitement spécifique en direction de l'acteur réel. Ce traitement est
défini au préalable par les concepteurs de la classe en question. Dans le cas d'un acteur
automatique de type robot par exemple, il peut s'agir de l'invocation d'une des commandes
du robot, pour laquelle l'appel n'entraîne pas une exécution immédiate mais une mise en
mémoire tampon. En effet, on peut supposer que le robot est programmé pour "décider"
lui-même de la façon dont il va réaliser l'appel de ses commandes. Par conséquent, la
méthode de l'acteur 2FLOW "Robot" n'aura pour rôle que d'invoquer la commande avec
les paramètres qu'elle nécessite, parmi lesquelles éventuellement l'ordre de priorité. Il n'est
pas nécessaire dans ce cas, de gérer les priorités au niveau de l'acteur 2FLOW.

2. Le deuxième cas de figure consiste à dire à l'opposé, que la gestion des activités doit être
réalisée au départ par l'acteur informatique. Nous avons étudié cet aspect et développé une
implémentation adéquate, que nous n'utilisons pas pour le moment. Cette approche
consiste à munir la classe Acteur de base, d'un attribut et d'une méthode particuliers.
L'attribut, nommé activities comme dans le cas précédent, est un vecteur à deux
dimensions. La première sert à stocker le nom d'une méthode de l'acteur et la deuxième, à
stocker ses arguments sous la forme d'un tableau d'objets. L'indice de la ligne du vecteur
correspond à l'importance de la tâche à réaliser. Plus celle-ci est importante et plus elle se
rapproche du début du vecteur.

162
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Au lieu d'invoquer directement les méthodes qui les concernent, les activités vont faire
appel à la nouvelle méthode execute(String, Object[ ], int) de la classe acteur, en lui passant
comme arguments : le nom de la méthode à invoquer (qui est le nom de la classe activité),
la liste de ses arguments sous la forme d'un tableau d'objets, et la priorité de l'activité (qui
correspond à la valeur de l'attribut priority). A l'instar des BCF_S, la méthode execute se
charge ensuite d'insérer les valeurs de ses arguments au sein du vecteur activities, à la
position correspondant à la priorité. La dernière étape pour la fonction consiste à invoquer
la méthode référencée par le premier élément du vecteur activities, élément qu'elle retire
par la suite. L'invocation de la méthode se fait de la même façon que dans le cas n°1, c'est
à dire en créant un objet Java "Method" pour la méthode en question, dont on appelle la
fonction "invoke" en lui passant la référence de l'acteur courant et les arguments de la
méthode, récupérés du vecteur activities. De même, chacune des méthodes qui prend fin
notifie l'activité correspondante.

Il est important de remarquer que quelle que soit la stratégie de gestion adoptée, il convient
qu'elle le soit pour tous les acteurs, afin de préserver l'indépendance entre processus et
réalisation. Le cas contraire forcerait, en effet, les concepteurs des workflows à connaître des
informations spécifiques sur les acteurs (afin de savoir comment invoquer les méthodes), ce
qui n'est pas le but recherché.

Acteurs humains

La plupart des systèmes Workflows sont, nous l'avons mentionné, plutôt dédiés à des
utilisateurs humains. En général, les activités de ce type d'acteur sont représentées sous la
forme de messages, de notes ou de documents électroniques (formulaires) déposés dans une
liste de tâches (worklist) attribuée à l'acteur en question. C'est elle qui, le plus souvent, est
chargée de trier les tâches en fonction de leur importance. Au besoin, des documents
électroniques sont attachés à l'activité.

Ce mécanisme de base est suffisant pour les acteurs humains qui savent comment traiter les
activités qui leur sont affectées, et il suffit donc d'associer une liste de tâches à ces acteurs.
2FLOW étant un framework et non un système Workflow à part entière, il ne propose que
des composants fondamentaux, aux interactions prédéfinies leur permettant de collaborer et
de s'exécuter de façon autonome. Un certain nombre d'outils de base qui accompagnent en
général les systèmes Workflows, n'ont pas été développés, c'est notamment le cas des
applications clientes telles les listes de tâches.

Toutefois, quelle que soit la méthode invoquée chez un acteur humain, celle-ci fait toujours
appel par défaut à une méthode de base appelée sendActivity( ). Celle-ci a pour effet d'envoyer
un message électronique à l'acteur, contenant des informations sur l'activité (issue de son
attribut description) et éventuellement des artefacts attachés, si ceux-ci sont de type fichier
(code, documents électroniques, formulaire, etc.). Les adresses électroniques d'un acteur
humain, ainsi que les informations le concernant sont des attributs de base de la classe
ActeurHumain :

class HumanActor extends Acteur {

...
protected StringVector eMailAdresses;
protected StringVector phoneNumbers;
protected String firstName, lastName;

163
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

protected Date dateOfBirth;

...

public boolean sendActivity();

}

Les concepteurs souhaitant créer des acteurs humains n'ont donc qu'à faire dériver cette classe
en d'autres, plus spécifiques. Ces dernières peuvent redéfinir la méthode sendActivity et ont à
définir les méthodes correspondant aux services des rôles que l'acteur implémente. Par
exemple dans un atelier, Mr "Alain Tairieur" tient le rôle de superviseur dont les tâches
consistent à vérifier le fonctionnement des machines et à corriger les dysfonctionnements.
Alors il s'agit de créer la classe AlainTairieur qui peut avoir l'allure suivante :

class AlainTairieur extends HumanActor implements Superviseur {

…
public void corriger ( ) {…};
public void superviser ( ) {…};

L'acteur AlainTairieur peut réaliser ces deux activités de la façon dont il le souhaite. De plus, la
classe peut redéfinir la méthode sendActivity (ou les deux autres méthodes), pour envoyer la
tâche non pas par courrier électronique, mais par exemple sur un terminal WAP.

Acteurs automatiques

L'approche que nous avons adoptée dans 2FLOW nous permet d'introduire les acteurs
automatiques avec une certaine facilité dans les workflows. A l'instar des acteurs humains,
toute classe d'acteur automatique doit définir les méthodes correspondant aux rôles qu'elle
implémente. Dans ce cas toutefois, les méthodes implémentées ne font appel à aucune
méthode par défaut. Au contraire, leur intérêt est de donner le code nécessaire pour
déclencher les opérations adéquates au niveau de l'acteur réel.

Par ailleurs, la classe ActeurAutomatique propose un ensemble de propriétés de base permettant

de décrire l'acteur réel, notamment son emplacement représenté par l'attribut location de type
String, qui permet de le repérer physiquement. Selon le cas, il pourra s'agir d'un URL – s'il
s'agit d'une application informatique – ou d'une adresse réseau s'il s'agit d'une machine, etc.

Pour reprendre l'exemple du robot, supposons que ce dernier soit associé au rôle de
"Démonteur". Les services à rendre par celui-ci sont le dévissage, l'extraction, le déclipsage et
la séparation. Pour chacun de ces services, il est possible d'écrire une méthode dont le rôle est
d'invoquer l'opération correspondante chez le robot. A titre d'exemple, la classe Robot
pourrait ressembler à ce qui suit :

class Robot extends AutomatedActor implements Demonteur {

...
protected String location;

public void declipser ( );

public void devisser ( );
public void extraire ( );
public void separer ( );
...
}

164
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Correspondance activités – méthodes

Nous avons dit jusqu'à présent que chaque service d'un rôle correspond à une compétence
donnée, qui est associée à une activité d'un processus. Les services étant implémentés par la
suite sous la forme de méthodes. Il arrive cependant que certaines activités soient tellement
spécifiques qu'il n'est pas utile de les transcrire directement en tant que méthodes, dans des
classes d'acteurs. Par exemple, reprenons le processus de désassemblage d'un lave-linge, qui
est composé des activités suivantes : "démonter le couvercle", "extraire le moteur", "extraire
le tambour". La question qui se pose est de savoir s'il est intéressant d'associer ces activités à
des méthodes distinctes. En effet, s'il faut définir une méthode pour chacune d’elles, alors on
risque d'obtenir des classes d'acteurs contenant plusieurs dizaines de méthodes réalisant
pratiquement la même chose. Par exemple, si l'extraction se répète pour différentes pièces, de
plusieurs appareils, il faudrait créer autant de méthodes spécifiques. Or en fait, on peut dire
que le démontage ou l'extraction correspondent à des types génériques d'activités, qui sont
paramétrés en fonction de l'appareil ou de la pièce sur laquelle on agit. Par conséquent dans
certains cas, il est plus intéressant de s'arrêter à un niveau suffisamment générique. En
d’autres termes, il suffit de définir une seule méthode "extraire( )" au lieu de
"extraireMoteur()" et "extraireTambour( )". D’un autre côté cependant, puisqu’un rôle
représente un ensemble de compétences, alors en restant dans le cadre du même exemple, on
pourrait imaginer qu’un opérateur sachant désassembler un lave-linge ne sait pas
désassembler un réfrigérateur. On a donc besoin de distinguer deux rôles, tels
"OpérateurLaveLinge" et "OpérateurRéfrigérateur", dans lesquels chacun pourrait proposer sa
propre version de l'activité "extraire". Mais quand un même acteur présente les deux
compétences, comment faire pour implémenter les méthodes de même nom ?

La correspondance entre les noms des activités et ceux des méthodes pose donc trois
questions :

§ Faut-il définir une méthode pour chaque activité d'un processus ou peut-on avoir des
méthodes "globales" (génériques) ?
§ Si c'est le cas, comment faire pour que des activités n'ayant pas le même nom mais
faisant référence à la même méthode, puissent invoquer cette dernière ?
§ Comment faire la distinction entre les méthodes globales de même nom, comme nous
l'avons vu dans l'exemple précédent ?

En réalité, le problème soulevé par la première question – et transitivement par les autres -
se pose plus au niveau de la perception du concepteur qu'au niveau du framework. En effet, si
le fait d'extraire un tambour ou d'extraire un moteur sont deux activités totalement différentes
sur le fond, alors il est sans doute nécessaire de les distinguer en termes de compétences. Dans
ce cas, celle-ci se situe au niveau de l'extraction d'une pièce donnée : "extraire moteur",
"extraire tambour". Par contre, s'il suffit à un opérateur de savoir extraire une pièce pour
réaliser cette activité, la compétence se situe alors globalement au niveau de l'extraction
générique et non plus à celui de l'extraction d'une pièce spécifique. Il s'agit en fait plutôt d'un
problème de connaissances. En effet, une compétence est accompagnée d'un ensemble de
connaissances, de savoir-faire ou plus simplement d'informations, qui sont possédées par
l'acteur. Dans les deux cas précédents, la connaissance peut être localisée à deux niveaux chez
un acteur. Soit à celui de la méthode – dont le code décrirait alors l'ensemble des opérations
nécessaires à la réalisation de l'activité - soit au niveau des artefacts qui sont passés comme
arguments à la méthode – la méthode se contentant alors d'interpeller l'acteur réel en lui
passant les informations nécessaires pour réaliser l'activité.

165
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Nous pensons donc effectivement, que le choix doit se faire au niveau de la conception. Pour
reprendre l'exemple des rôles, est-il véritablement judicieux de distinguer un rôle d'opérateur
pour le démontage de chaque type d'appareil ? Ne serait-il pas plus pertinent d'avoir un seul
rôle, tel "Opérateur de Désassemblage", qui couvrirait l'ensemble des compétences
nécessaires pour réaliser un désassemblage ? La réponse à cette question semble plutôt du
ressort du concepteur du workflow.

Quoiqu'il en soit, il est très probable que les concepteurs aient recours, à un moment ou à un
autre, à des méthodes génériques. Se pose alors le problème technique soulevé par la
deuxième question : si une activité invoque chez un acteur la méthode qui porte son nom,
comment faire lorsqu'on a plusieurs activités différentes qui sont réalisées par la même
méthode ? Nous apportons une réponse à ce problème en introduisant un attribut spécifique
dans la classe Activité, nommé invokedService. Cet attribut est initialisé au moment de la
modélisation, avec le nom du service du rôle que l'activité est censée invoquer lors de
l'exécution. Par exemple pour les activités ExtraireMoteur et ExtraireTambour, la valeur
"extraire" est attribuée à cet attribut. Lors de l'invocation de la méthode notifyActor( ) d'une
activité, il suffit d'utiliser la valeur de invokedService s'il n'est pas nul, au lieu du nom de
l'activité, avant d'exécuter le reste du mécanisme qui ne change pas.

Quant au problème soulevé par la troisième question, nous ne lui apportons pas pour l'instant
de solution technique. Notre proposition est d'éviter d'utiliser des noms de services similaires
lors de la modélisation, en particulier si leur principe est le même. Dans ce dernier cas en
effet, la modélisation du workflow est peut-être à revoir.

[Link] Expressions Logiques

Les expressions logiques sont, comme nous l'avons vu, les opérateurs de 2FLOW dédiés au
contrôle du flux des événements. Leur fonctionnement est simple (fig. IV.28) :

Une expression logique est avant tout instanciée par l'un des événements qui la composent,
lequel s'y inscrit par la même occasion, en invoquant la méthode registerEvent (WorkflowEvent).
Pour stocker les références des événements qui viennent s'y enregistrer, la classe
ExpressionLogique est munie d'un attribut events de type EventVector. Chaque demande
d'inscription donne lieu au préalable à une vérification, afin de savoir si l'événement candidat
fait bien partie de l'expression. Celle-ci est fixée par les concepteurs lors de la modélisation, et
est stockée dans l'attribut expression, de type String. A la fin de chaque enregistrement, un
appel de la méthode interne evaluateExpression( ) est généré, dont le rôle est d'évaluer
l'expression logique. Si l'expression est vérifiée (renvoie la valeur "vrai"), la méthode va
notifier les instances des activités concernées (en les créant éventuellement). La méthode
d'évaluation de l'expression fait appel à d'autres fonctions internes de la classe. Sans rentrer
dans leur détail, il suffit de savoir que l'évaluation consiste à construire un arbre, dont les
n œuds non terminaux sont des opérateurs logiques, et les feuilles des événements. Chaque
n œud de l'arbre pointe sur une structure de type StringVector, contenant les noms des activités
qui doivent être notifiée par les n œuds, via leur méthode getActivated( ). Les événements
n'ayant pas eu lieu sont remplacés dans l'arbre par des n œuds génériques qui sont évalués à
"faux" par la fonction d'évaluation. A l'opposé chaque événement s'étant inscrit renvoie une
valeur "vrai" dans le n œud correspondant.

166
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

[ E1( ) &(A1) E2( ) ] | ( ) [ E3(A2, A3) ]

Ajout
Attente |
do : vérifier
do : [nom ok ] : ajouter
A1 & E3 A2 A3
Evaluation

do : evaluateExpression ( )
E1 E2
do : notifications

Figure IV.29 – Fonctionnement des Figure IV.30 – Arbre d'une expression

expressions logiques logique

Par exemple, l'expression [ E1( ) &(A1 ) E2( ) ] | ( ) [ E3 (A2, A3) ] se traduit par l'arbre de la
figure IV.30. Si au cours de l'exécution du workflow l'événement E3 s'inscrit auprès de
l'expression, alors celle-ci est évaluée à "vrai", étant donné que l'arbre correspondant équivaut
à ( (faux AND faux) OR vrai) qui donne vrai. Ce sont dans ce cas les activités A2 et A3 qui
sont activées.

[Link] Artefacts

La classe Artefact de base est abstraite et ne contient qu'un ensemble minimum de propriétés,
telles le nom de l'artefact et son identifiant. Elle sert surtout comme type de base aux classes
qui en dérivent, DocumentElectronique, ObjetTechnique et VariableWorkflow.

DocumentElectronique

La classe DocumentElectronique englobe l'ensemble des objets de ce type. Elle peut donc
concerner les fichiers textes, les documents de tableurs, les résultats de requêtes sur des bases
de données, etc. A l'instar de la plupart des composants de 2FLOW, cette classe peut être
spécialisée pour chacun des types de documents, selon les besoins des concepteurs des
workflows. Elle est néanmoins munie de propriétés et de comportements, que nous présentons
ci-dessous, qui font qu'elle peut être utilisée directement.

class ElectronicDocument extends Artefact {

protected String name;

protected String URL;
protected String openCommand;
protected String defaultOpenCommand;
protected boolean mustBeCreated;
protected StringVector createStatement;
protected String receiver;
...

public ElectronicDocument get ( );

public boolean open ( );
public boolean useDefaultViewer ( );
public void send ( );
public void create ( );
public void setReceiver( );
...
}

167
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

L'attribut name contient le nom du document électronique, qui est repéré grâce à la valeur de
l'attribut URL, de type String également. L'URL d'un document correspond à la localisation
du document et non nécessairement à une adresse web. Elle peut donc revêtir plusieurs
formes, telles : "[Link] "LecteurRéseau//Dossier/…", etc.

L'attribut openCommand contient la syntaxe de la commande permettant d'afficher le

document chez le destinataire en question - repéré grâce à l'attribut receiver. Lorsqu'un acteur
souhaite visualiser le document, un appel de la méthode openDocument( ) est généré. Celle-ci
utilise par défaut la concaténation des trois attributs précédents afin d'ouvrir le document en
question. Elle peut, bien sûr, être redéfinie au niveau des classes utilisateurs. OpenDocument
renvoie un booléen mis à "vrai" en cas de succès en "faux" si le viewer du document n'a pu
être lancé chez le destinataire. Dans ce cas, une autre tentative est effectuée par la méthode
useDefaultViewer( ) qui fait appel à un viewer par défaut, dont le nom et la localisation sont
stockés dans l'attribut defaultOpenCommand.

Enfin, il se peut que le document réel doive être créé physiquement lors de l'instanciation de
la classe DocumentElectronique, ou avant l'appel des méthodes open( ), get( ) ou send( ). Ces
deux dernières méthodes permettent respectivement de télécharger le document à partir de son
URL et d'envoyer le document au destinataire. Pour créer le document, la classe dispose de la
méthode create ( ) qui utilise le contenu de l'attribut createStatement, de type StringVector. Ce
dernier est un ensemble de chaînes de caractères (un script), décrivant la procédure de
création du document ou le nom d'un script qui permet de le faire. Cette méthode est
particulièrement utile pour la création de fichiers issus de requêtes sur des bases de données.

Variable Workflow

Les variables Workflows servent à stocker des objets de n'importe quel type, qu'il est possible
d'utiliser par la suite dans les autres classes des workflows. La classe VariableWorkflow est
générique et fournit des mécanismes de base pour la manipulation de l'objet qu'elle contient.
En l'état actuel de sa définition dans 2FLOW, l'emploi de cette classe nécessite certains
artifices de programmation que ne peuvent par nécessairement mettre en œuvre des
concepteurs de workflows sans connaissances minimales en Java. Cela semble rentrer quelque
peu en contradiction avec les principes fondamentaux de 2FLOW. Néanmoins, il n'était pas
possible de rester en même temps à un niveau générique - qui permet de stocker toutes sortes
d'objets - et fournir des mécanismes de manipulation de types précis. A fortiori quand le type
de l'objet à contenir n'est pas connu au départ.

L'interface de la classe VariableWorkflow est la suivante :

class WorkflowVariable extends Artefact {

...
private String name;
private String type;
private Object value;

public Object getValue ( );

public String getType ( );
public String getName ( );
public void setValue (Object);
public void setType ( ); // pas nécessaire
public void setName ( );
...
}

168
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Le rôle de chacun des trois attributs de la classe est suffisamment explicite pour que nous ne y
attardions pas. Il convient de commenter toutefois l'attribut value - qui stocke la valeur de la
variable - et qui est de type "Object". En Java, la classe Object est la classe de base de toutes
les classes Java, y compris celles des utilisateurs du langage. C'est donc un type générique qui
peut être utilisé en remplacement de n'importe quel autre type de Java (mis à part les types de
base "int", "float", "char" etc.). Il est alors logique de déclarer comme "Object" l'attribut
servant à stocker la valeur de la variable, ce qui permet de récupérer tout type d'objet.

Afin de récupérer la valeur d'une variable Workflow 2FLOW, les utilisateurs disposent de
deux méthodes, getValue ( ) qui renvoie un Object, et getType ( ) qui renvoie le type de l'objet
mémorisé dans la variable, dont les rôles respectifs sont de renvoyer la valeur de la variable et
son type. Afin d'utiliser correctement cette valeur, la seule manipulation à réaliser par les
concepteurs est de faire une conversion explicite de type (un "cast"), du type générique
"Object" au type de l'objet stocké dans la variable. Par exemple si l'on a une variable
workflow stockant un entier, il suffit pour récupérer cette valeur d'écrire le code suivant :

WorkflowVariable maVariable = …;
Integer uneVariable = (Integer) [Link]( ); // cast en "entier"

De la même façon si l'on veut créer un objet de type Acteur (2FLOW) et le stocker dans une
variable, il suffit d'écrire le code suivant :

Actor monActeur = new Actor (…); // constructeur de la classe Acteur

WorkflowVariable maVariableActeur = new WorkflowVariable ("maVariable",
"Acteur", maVariableActeur); // création de la variable workflow
...
Acteur autreActeur = (Acteur) [Link] ( );

Remarquons que la méthode getValue renvoie une copie de l'objet et non l'objet lui-même.
Enfin nous avons indiqué que la méthode setType n'était pas nécessaire car il est en effet
directement possible, grâce à la méthode "getClass( )" des objets de Java de connaître le type
d'un objet.

Objets Techniques

Les objets techniques sont la dernière classe de base issue de la classe Artefact. Ainsi que nous
l'avons mentionné, ce sont les équivalents des objets techniques (OT) réels dans le
framework. Le rôle de la classe ObjetTechnique est principalement de gérer la circulation et
l'évolution des objets réels entre les acteurs du workflow, ce qui n'est pas réalisable avec les
systèmes Workflows usuels. Pour ce faire, la classe possède un ensemble d'attributs et de
méthodes spécifiques, implémentés au sein de 2FLOW, ce qui permet d'utiliser aussi les
instances de cette classe sans avoir à les spécialiser nécessairement.

Afin de gérer l'évolution des états d'un OT, nous utilisons un attribut nommé objectStates de
type Vector. Il sert à stocker des objets de type TechnicalObjectState qui est défini en tant que
classe interne de la classe ObjetTechnique. L'interface de cette classe est la suivante :

private class TechnicalObjectState {

private String stateName;

private String stateValue;

public String getStateName ( );

169
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

public String getStateValue ( );

public void setStateName (String);
public void setStateValue (String);
...

Les deux attributs stateName et stateValue servent respectivement à définir le nom d'un état de
l'OT et sa valeur. Les méthodes fournies par la classe permettent de manipuler les valeurs de
ces deux attributs.

Un autre attribut de type ArtefactVector, nommé components, sert à représenter les liens de
composition ou de nomenclature pouvant exister entre un OT et d'autres OT. Les méthodes
addArtefact (Artefact) et removeArtefact( String nomArtefact) appliquées à cet attribut, permettent
de simuler l'évolution d'un objet en lui ajoutant ou ôtant des composants. Cela peut
notamment s'avérer très utile dans les processus d'assemblage ou de désassemblage de
produits manufacturés.
Enfin, pour gérer la circulation des OT, la classe ObjetTechnique dispose de deux attributs
nommés getObjectProcess de type String et processArguments de type StringVector, ainsi que
d'une méthode getObject( ). Cet attribut contient la référence du processus logistique qui
permet de déplacer l'objet réel d'un endroit à l'autre. Ce dernier peut être un processus
2FLOW ou un processus externe et l'ensemble des arguments nécessaire à son exécution son
introduits par l'attribut processArguments. Enfin, le processus logistique est invoqué par la
méthode getObject( ), qui peut être redéfinie au niveau des classes des utilisateurs. Cette
méthode doit contenir le code nécessaire à l'appel du processus, en lui passant au besoin les
arguments nécessaires.

3.3 Architecture de 2FLOW

L'architecture de 2FLOW est formée de trois niveaux : le niveau fondamental (core level),
constitué de quatre packages principaux, le niveau des définitions de base utilisateur (user
base definitions level) et enfin le niveau des workflows. Le package le plus important contient
les classes de base de 2FLOW, celles du métamodèle que nous avons présenté. Vient ensuite
le package des classes auxiliaires qui se décompose lui-même en trois sous-packages (non
représentés dans la figure) : le package des exceptions 2FLOW, le package des classes
auxiliaires de niveau Workflow et enfin celui des classes utilitaires. Le niveau fondamental
contient également un package que nous n'avons pas encore mentionné, celui des vues. Nous
avons en effet doté chaque classe de base du framework d'un équivalent graphique qui permet
de visualiser l'évolution de la classe en cours d'exécution. C'est le référentiel du workflow qui
est chargé de créer un équivalent graphique pour chacune des classes qui s'y enregistre. Par la
suite, chaque objet qui change d'état à un certain instant invoque la méthode
update(WorkflowObject) du référentiel en se passant en argument. Cette méthode se charge de
retrouver l'équivalent graphique de l'objet auquel elle demande de se dessiner en tenant
compte du nouvel état de l'objet 2FLOW. Nous rappelons que WorkflowObject est la classe
mère de toutes les classes de base 2FLOW.

170
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Niveau fondamental
Classes workflows utilisateurs

Niveau classes de bases

utilisateurs
Workflow 1 Workflow 2
...
Niveau modèles Workflows

Classes de base Fichiers de

utilisateurs définitions
Contôleur
générique
2FLOW

Vues Classes de base Classes Auxiliaires Modeleur

fondamentales générique
2FLOW

Figure IV.31 – Architecture globale de 2FLOW

Chacune des classes du package - les composants Workflows graphiques - dérive d'une classe
de base appelée WorkflowGraphicComponent qui définit un ensemble d'attributs et de
comportements communs à tous les composants. Ces propriétés sont redéfinies au besoin au
niveau des composants spécifiques, notamment les méthodes drawSelf( ) et paint( ) qui
permettent au composant de se dessiner sur la surface appropriée. Nous n'allons toutefois pas
nous attarder sur le package des vues dont les classes ne proposent pour l'instant que de
représentations assez élémentaires.

Un autre package du niveau fondamental qui n'a pas encore été évoqué dans ce chapitre est
celui des fichiers de définitions. Lors de la modélisation – via l'éditeur que nous décrirons
sous peu – des fichiers de définitions sont créés pour chaque classe. Ces fichiers contiennent
sous une forme quasi textuelle, l'ensemble des informations sur la structure d'une classe
2FLOW. Ils sont utilisés ensuite pour la génération de classes sources Java et leur
compilation. Les fichiers de définitions sont l'un des moyens que nous utilisons pour mettre
en œuvre la flexibilité dans le framework.

Le deuxième niveau de l'architecture est défini par un package dédié aux classes de base
définies par les développeurs utilisant 2FLOW. Il sert à ajouter des extensions au métamodèle
qui seront utilisées par l'ensemble des concepteurs workflows et non uniquement pour des cas
spécifiques.

Enfin, le dernier niveau concerne les packages des workflows des utilisateurs. Chaque modèle
de workflow est représenté par un package du même nom, dans lequel sont placées les classes
nécessaires à son fonctionnement. Celles-ci peuvent dériver des classes du package des
classes fondamentales de 2FLOW, des classes de base définies par les développeurs ainsi que
des classes des autres workflows. L'exécution des workflows donne lieu à la création d'un
nouveau package par cas d'exécution, dans lequel sont recopiées puis instanciées les classes
(fig. IV.32).

171
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Workflow désassemblage

MrX
Modèle workflow
produit

Robot_Z
extraire

recopie recopie

Workflow désassemblage Workflow désassemblage

produit MrX extraire Robot_Z produit MrX extraire Robot_Z

définitions définitions
instances instances
: Robot_Z
: produit : MrX : extraire : produit : extraire

Cas 1 Cas 2

Figure IV.32 - Exécution des workflows : un cas - un package d'exécution

Les paragraphes précédents nous ont permis de présenter d'une façon détaillée l'ensemble des
concepts de 2FLOW, sa structure, son utilisation, son fonctionnement et son architecture.
Nous espérons que cela aura, entre autres, permis de montrer l'utilité de 2FLOW pour la
construction de workflows par assemblage de composants. Ces paragraphes auront peut être
également permis d'entrevoir la façon dont le framework est utile pour les problèmes de
réutilisation, d'adaptation et plus globalement de flexibilité. Ceci notamment grâce à sa nature
orientée objet et son approche par métamodèle.

Nous donc consacrons le prochain paragraphe à la description de la façon dont 2FLOW

intègre et met en œuvre la flexibilité des workflows. Nous décrivons les mécanismes
disponibles, et leur adéquation aux différents besoins relatifs à la flexibilité, notamment la
réutilisation des workflow, leur adaptation hors et en cours d'exécution, ainsi que la gestion
des exceptions.

172
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

4. La flexibilité dans 2FLOW

La flexibilité dans le framework 2FLOW s'applique à trois niveaux distincts, que nous avons
présentés et commentés dans le chapitre III (au paragraphe 4.2.1, concernant l'application des
concepts objets au Workflow):

§ La réutilisation des workflows, des composants existants et l'adaptation hors

exécution.
§ L'adaptation en cours d'exécution des workflows.
§ La gestion des exceptions.

Ainsi que nous l'avons mentionné au début de ce chapitre, nous nous intéressons
particulièrement aux deux premiers niveaux, bien que nous traitions également la gestion des
exceptions. Nous les abordons dans l'ordre dans les paragraphes qui vont suivre.

4.1 Réutilisation des workflows et des composants existants

De par leur conception Objet, les composants de 2FLOW bénéficient naturellement des
capacités des objets à évoluer, à se spécialiser et à s'adapter. L'exploitation de ces propriétés
est d'ailleurs l'un des principes fondamentaux de l'utilisation du framework puisque, nous
l'avons vu, les concepteurs doivent spécialiser les classes de base (avec ou sans redéfinitions)
afin de construire leurs workflows. L'approche utilisée dans 2FLOW se situe entre le
deuxième et le troisième niveau d'application des concepts des objets au Workflow, tels qu'ils
ont été définis par C. Bussler (chap. III). Nous utilisons en effet les mécanismes offerts par le
langage objet sous-jacent – en l'occurrence Java – et nous proposons un mécanisme spécifique
aux classes du framework, qui permet de spécialiser les workflows.

Nous distinguons trois paliers de mise en œuvre de la réutilisation et de l'adaptation hors

exécution dans le framework :

1. La réutilisation et l'adaptation des composants.

2. La réutilisation et l'adaptation des workflows sans modification du flux.
3. La réutilisation et l'adaptation des workflows avec modification du flux.

1. La réutilisation et l'adaptation des composants est le premier pallier de la réutilisation

dans 2FLOW. Il concerne la réutilisation des composants Workflows, ceux des classes
définies par les utilisateurs. L'objectif est de récupérer des composants de workflows
existants pour la construction de nouveaux workflows. Ces composants son réutilisés tels
quels ou spécialisés en de nouvelles classes, comme nous l'illustrons dans la figure ci-
dessous.

Workflow 1 Workflow 2
Process1 Process2

A1 B1 C1 D1 A1 F G
D2

Figure IV.33 – Réutilisation de composants hors exécution

173
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Dans notre exemple, nous avons un premier package nommé "Workflow 1" correspondant
à un processus "Processus1", lié à un ensemble de classes composantes A1, B1, C1 et D1.
Un deuxième package est créé – "Workflow B" – correspondant à un autre processus,
nommé "Processus2". Ce dernier fait appel à de nouvelles classes, F et G, mais également
à la classe même A1 définie dans le workflow précédent, ainsi qu'à une spécialisation D2
de la classe D1 définie précédemment. Nous avons donc ici deux cas de figures de la
réutilisation de composants : une réutilisation directe, avec la classe A1 et une adaptation
(ou une modification), avec D2. Le premier cas de figure ne nécessite qu'une simple
recopie de la classe depuis le premier package jusqu'au deuxième ou plus simplement,
d'une "importation" de cette classe dans le deuxième paquetage. L'importation consiste
lors de l'exécution, en une recopie du code objet d'une classe située dans un package
donné dans un autre package. Elle est mise en œuvre dans Java par le mot clé "import". Le
deuxième cas de figure consiste en une spécialisation de la classe D1 en une nouvelle
classe D2, qui y apporte et/ou qui en redéfinit des propriétés.

Remarquons que les workflows 1 et 2 ne sont pas "apparentés", c'est à dire que le
workflow 2 traite un processus différent du premier. La réutilisation et la spécialisation ne
se font donc pas au niveau des workflows eux-mêmes mais à celui des composants. Les
mécanismes mis en œuvre dans ce cas sont ceux du langage Java – et des langages objets
en général – notamment la spécialisation et l'importation.

2. La réutilisation et l'adaptation des workflows sans modification du flux est le deuxième

palier de mise en œuvre de la réutilisation et de l'adaptation - hors exécution - dans
2FLOW. Contrairement au premier palier qui adressait uniquement les classes de
composants, ce niveau concerne la spécialisation des workflows. Comme nous l'avons vu
dans le chapitre 3 avec les définitions de C. Bussler, spécialiser des workflows consiste à
pouvoir en créer à partir de la définition d'autres workflows. Pour y arriver, nous
combinons dans notre framework l'effet de deux mécanismes : celui de l'héritage des
classes Java et un mécanisme spécifique à 2FLOW. Nous nous situons donc à
l'intersection entre le deuxième et le troisième niveau des workflows Objets. Nous
rappelons que ce dernier consiste à intégrer les mécanismes des Objets au sein d'un
langage de définition de workflows

La spécialisation des workflows est rendue possible dans 2FLOW par une procédure en
deux étapes, dont la première consiste en la spécialisation de la classe du processus en
une nouvelle classe du même type. Nous rappelons que cette classe contient
essentiellement deux vecteurs, le premier stockant le nom des BCF gérant les flux du
processus, et le deuxième le nom des acteurs qui y sont impliqués.

La deuxième étape consiste à définir les classes qui doivent éventuellement être ajoutées
(si le nouveau workflow nécessite de le faire) ou de redéfinir les classes qui doivent être
modifiées. Il est important de noter que les modifications doivent se propager à l'ensemble
des classes concernées. Remarquons que grâce au mécanisme que nous adoptons – et que
nous allons décrire dans ce qui suit – il est possible de spécialiser un composant d'un
workflow en un composant du même nom dans un autre workflow.

Lors de la définition de la classe WorkflowObject du framework dans le paragraphe [Link],

nous avons dit que toute classe 2FLOW dispose des noms de deux packages distincts :
celui dit de définition, et celui de l'exécution. En effet, toute classe est définie à l'intérieur
d'un paquetage donné, qui correspond au workflow qui l'utilise : c'est son package de

174
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

définition. Quant au package d'exécution d'une classe, il correspond toujours à celui de

définition de la classe processus qui est exécutée. Par défaut et en général, les deux
paquetages sont identiques, sauf dans le cas de la réutilisation.

Dans un langage de programmation objet, lorsqu'une classe est dérivée, ces filles héritent
de toutes ses propriétés, en particulier des liens qui la lient avec d'autres classes. Il n'est
donc pas nécessaire de les redéfinir au niveau des classes héritières. Nous appliquons ce
même principe à la spécialisation de workflows. Celle-ci donne bien lieu à la création de
nouveaux workflows et par conséquent de nouveaux packages, mais ceux-ci ne doivent
contenir que les nouvelles classes ou celles qui sont redéfinies. Le package père et son
contenu son simplement référencés dans le nouveau processus et les nouvelles classes, à
l'aide du mot clé "import nom du package". Si le nouveau processus est exécuté, il a alors
accès aux classes de son paquetage ainsi qu'à celle de son paquetage père, mais dans ce
cas, les classes de ce dernier possèdent des packages de définition et d'exécution distincts.

L'intérêt de la distinction réside dans le mécanisme d'instanciation des classes du

framework. En effet, lorsqu'une classe 2FLOW souhaite en instanicer une autre, elle la
recherche d'abord dans le package d'exécution – pour en obtenir une version
éventuellement plus récente - et si elle ne la pas trouvée, dans son propre package de
définition. Ce mécanisme assure que quel que soit le niveau d'héritage, une classe est
toujours capable de retrouver celles avec lesquelles elle collabore.

Pour expliciter ces mécanismes à l'aide d'un exemple, reprenons le processus de base
d'hospitalisation d'un patient. Nous avons dit qu'il est composé de quatre activités :
"préparation du dossier administratif" attribuée à un "agent administratif", "préparation du
dossier médical", réalisée par un "chef de service", "opération", traitée par un "chirurgien"
et enfin la "facturation", exécutée par un "agent comptable".

Nous illustrons ce workflow par la figure IV.34-a

<< Processus>> << BCF>> Hospitalisation_1
ci-contre, en n'y représentant qu'un nombre réduit Hospitalisation1 Sequ1

des classes intéressées, notamment le processus,

le BCF principal, les activités et les rôles chargés
de les réaliser. << Activités>>
EtablirDA EtablirDM Opérer Facturer

Supposons que nous souhaitions modifier ce << Rôles>>

processus – hors exécution – pour y ajouter une AgentAdm ChefServ Chirurgien AgentCtble

activité : "rééduquer", réalisée par un

"kinésithérapeute". Cette activité s'insérant entre -a-
"opérer" et "facturer". Pour ce faire, il suffit de
créer un nouveau processus, sous la forme de la << Processus>>
Hospitalisation2
<< BCF>>
Sequ1 Hospitalisation_2
classe "Hospitalisation2", héritant du premier.
Dans le nouveau package du même nom, il s'agit Rééduquer
également d'ajouter les classes correspondant Opérer
respectivement à la nouvelle activité et au
nouveau rôle. Il faut également y redéfinir le BCF Kinésithérapeute

"Sequ1" étant donné qu'il contient à présent une

nouvelle activité, ainsi que l'activité "Operer" qui -b-
change d'activité suivante.
Figure IV.34 – Exemple de
Au niveau du code correspondant, cela revient en spécialisation de workflow

175
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

fait à réaliser très peu de travail. En effet, il suffit d'écrire le code suivant pour la
redéfinition et la spécialisation des classes (bien sûr, il faut également définir les nouvelles
classes) :

import Hospitalisation_1.*;

class Hospitalisation2 extends Hospitalisation1 {

/* il n'y a rien à ajouter. Seule la méthode main( ) qui permet

d'exécuter le programme doit changer pour créer une instance du nouveau
processus */

Public void main ( ) { ... };

import Hospitalisation_1.*;

class Sequ1 extends Hospitalisation_1.Sequ1 {

/* il faut préciser le nom du package si on garde le même nom pour la

classe */

public void Sequ1() {

super( );
// appel du constructeur de la classe mère. Initialisation commune
activities = {"EtablirDA", "EtablirDM, "Operer", "Reeduquer",
"Facturer"};

// il faut uniquement redéfinir une partie du constructeur

...
}

import Hospitalisation_1.*;

class Operer extends Hospitalisation_1.Operer {

public void EtablirDM ( ) {

nextActivities = { "Reeduquer"};
...
}

Remarquons que pour le moment, la réutilisation et la spécialisation ne remettent pas en

cause le flux des activités, c'est à dire que les composants qui sont modifiés ne sont pas
des BCF. Ceux-ci sont concernés par le troisième palier de réutilisation, que nous
décrivons dans ce qui suit.

3. La réutilisation et l'adaptation des workflows avec modification du flux consiste à dériver

des workflows existants en de nouveaux workflows, en modifiant le flux des activités. La
modification du flux se traduit par la redéfinition des BCF existants dans les classes mères
ou par la création de nouveaux BCF. Les mécanismes mis en œuvre sont les mêmes que
dans le niveau précédent mais les modifications y ont plus de répercussions.

176
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Reprenons l'exemple du processus d'hospitalisation précédemment décrit. Nous supposons

à présent que suite à une reconception du travail dans l'hôpital, le processus commence par
une mise en parallèle des deux premières activités consistant à établir les deux dossiers,
administratif et médical (fig. IV.35).
Médecin chef
du service
€ Dossier
médical

Etablir dossier ET
médical Opérer Rééduquer Facturer

Arrivée d’un
patient Etablir dossier
administratif
Jour opération
€ € €
€
Chirurgien Kinésithérapeute Agent
Comptable

Agent Dossier
administratif administratif

Evénement
€ Rôle Données Opérateur

Activité Flux des tâches Flux d’informations

Figure IV.35 – Modification du flux d'un workflow

Le nouveau processus, que nous nommons

<< Processus>> << BCF>> Hospitalisation2
"Hospitalisation3" hérite du processus précédent Hospitalisation2 Sequ1

dont il modifie le flux. Pour ce faire, un nouveau

BCF est à insérer, afin de permettre la mise en Rééduquer

parallèle des deux premières activités. Nous

introduisons donc la classe "Parallel1", qui est un Kinésithérapeute
BCF parallèle contenant les deux activités
"EtablirDA" et "EtablirDM". Celles-ci doivent
être légèrement modifiées dans le nouveau
processus, puisqu'elles pointent à présent sur une << Processus>> << BCF>> << BCF_P >>
Hospitalisation3 Sequ1 Parallel1
expression logique que nous nommons "ET". Son
rôle est de joindre les événements marquant la fin
des deux premières activités, et celui qui signale ET << Expression Logique>>

l'arrivée du jour de l'opération. Nous la << Activités >>

formalisons à l'aide d'une nouvelle classe à ajouter EtablirDA EtablirDM
Hospitalisation3
au package du nouveau workflow.

A l'instar du deuxième processus, le code à ajouter Figure IV.36 – Héritage avec

est très simple. Il faut néanmoins remarquer qu'il modification du flux
est nécessaire d'importer les classes des deux
packages précédents, et non seulement du package "Hospitalisation_2", étant donné qu'il
est nécessaire de redéfinir les classes des deux premières activités, qui n'y sont pas
présentes.

Il peut paraître quelque peu contraignant d'avoir à connaître les noms des packages
desquels il faut importer des classes, étant donné que l'on peut avoir plusieurs niveaux de

177
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

spécialisation de workflows. De plus, même si dans le cas de la réutilisation telle que nous
l'avons présentée dans nos exemples, le code à ajouter est très simple, le codage reste plus
du ressort des développeurs que des analystes de processus. Par conséquent, pour éviter
aux concepteurs d'avoir à écrire du code et de se soucier de l'arborescence des packages,
nous avons développé un éditeur générique de classes 2FLOW, que nous présentons plus
en détail dans une autre partie de ce chapitre.

4.2 Adaptation et spécialisation des workflows en cours d'exécution

L'adaptation en cours d'exécution est un problème techniquement plus difficile à résoudre que
celui de l'adaptation hors ligne. Plusieurs contraintes sont à prendre en compte afin d'assurer
la cohérence des workflows résultants. Globalement, adapter les workflows en cours
d'exécution pose deux types de problèmes : il s'agit d'une part de proposer des mécanismes
qui permettent de faire évoluer les workflows en cours d'exécution, et d'autre part, il faut
poser des règles de cohérence et de validation des adaptations. Nous allons dans ce
paragraphe voir quelles sont les solutions apportées par 2FLOW à ces problèmes.

Dans le framework, l'adaptation des workflows en cours d'exécution recouvre deux catégories
de modifications et d'adaptations :

§ La première catégorie concerne les adaptations et les corrections qui ne nécessitent pas
de modifier la structure des classes et des workflows existants. En d'autres termes, il
s'agit essentiellement de modifier les valeurs de leurs attributs, ce qui peut néanmoins
nécessiter l'ajout ou la suppression de composants au package, sans que cela n'ait
d'influence sur la structure du workflow. Par exemple, supposons que nous ayons une
activité dans laquelle le nom d'un acteur a été fixé et que nous souhaitions changer
d'acteur en cours d'exécution. Dans ce cas, il faut intervenir directement sur l'attribut
actorName de la classe activité et s'assurer de la présence dans le package, de la classe de
l'acteur correspondant. Quoiqu'il en soit, les adaptations n'affectent pas la structure du
workflow.

En plus des attributs, il est également possible dans ce niveau de modifier les
comportements des composants Workflows. Il s'agit essentiellement de redéfinir
certaines de leurs méthodes, donc de modifier leur implémentation. On peut en effet
supposer qu'un acteur modifie la façon dont il traite une activité. Par exemple,
l'apparition d'une nouvelle contrainte technique fait qu'un robot qui traitait une activité
par l'appel d'une commande donnée, doive la traiter par la combinaison d'autres
commandes. Afin d'adapter le workflow à ces nouvelles exigences, il convient alors de
revoir l'implémentation de la méthode correspondant à l'activité en question.

§ La deuxième catégorie concerne les adaptations et les corrections des workflows qui
remettent en cause leur structure. Il peut s'agir de l'ajout ou du retrait de composants, ce
qui nécessite simultanément les modifications des valeurs de plusieurs attributs, ainsi
que la mise à jour du contenu du package du workflow. Par exemple l'ajout ou le retrait
d'activités, d'événements ou de blocs de contrôle de flux sont des causes de modification
de la structure des workflows. En règle générale, tout ajout ou retrait de composants
intervenant dans le flux des workflows en nécessitent une restructuration.

En tenant compte de ces différentes contraintes, nous proposons dans 2FLOW deux approches
complémentaires pour la mise en œuvre de l'adaptation en cours d'exécution.

178
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

4.2.1 Approche par métaclasse générique et réflexivité : contrôleur générique

La première approche consiste à fournir des moyens pour manipuler "à distance" les attributs
des instances des composants Workflows. Pour ce faire, 2FLOW propose un outil sous la
forme d'un contrôleur générique – défini par un ensemble de classes contenues dans le
package "Contrôleur Workflow Générique". La classe principale de ce package, appelée
"ControlerEngine", est instanciée lors de l'initialisation d'un workflow et à accès à son
référentiel. Le moteur du contrôleur dispose d'une copie des objets contenus dans le
référentiel du workflow, que ce dernier met régulièrement à jour lors de l'ajout de nouvelles
instances. L'outil propose une interface sous la forme d'une première fenêtre - le panneau de
contrôle - dans laquelle s'affiche au fur et à mesure la liste de tous les objets Workflows qui
sont créés lors de l'exécution. Il est possible aux utilisateurs de les sélectionner et d'en afficher
les attributs (avec leurs valeurs) dans une nouvelle fenêtre. De la même façon, chaque attribut
peut être sélectionné séparément et une nouvelle valeur peut lui être directement attribuée. Par
exemple dans la figure IV.37, nous avons lancé le contrôleur pour un processus de rédaction
collaborative d'un document. Ce dernier est composé d'un ensemble d'activités et de CFB.
Dans notre exemple, nous avons sélectionné le CFB séquentiel principal du processus (1ere
fenêtre) pour lequel nous avons demandé l'affichage de tous les attributs (2ème fenêtre). Nous
avons ensuite sélectionné l'attribut contenant le nom des composants du CFB, dont nous
affichons le contenu à l'aide de la troisième fenêtre. Celle-ci nous permet d'agir directement
sur le contenu de l'attribut en lui attribuant une nouvelle valeur.

Figure IV.37 - Contrôleur Générique de 2FLOW : sélection d'un objet du référentiel -

Affichage des attributs de l'objet - Sélection et modification d'un attribut

[Link] Mise en œuvre

La technique qui a été adoptée met en œuvre les mécanismes de la réflexivité dont nous avons
parlé au chapitre précédent. Dans notre cas, nous faisons appel aux mécanismes proposés par
le langage Java, ainsi qu'à des mécanismes que nous avons directement intégrés aux classes
de 2FLOW et que nous avons volontairement occultés jusqu'à présent.

Lors de la sélection d'un objet du référentiel via l'interface du contrôleur, la classe

"SelectedObject" du paquetage du contrôleur est instanciée. Elle agit en tant que métaclasse

179
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

générique de tous les objets 2FLOW, dont elle peut récupérer l'ensemble des attributs grâce à
sa méthode getObjectFields( ). Cette dernière utilise les services de la méthode
"getDeclaredFields( )" de la classe "Class" de Java dont nous avons précédemment parlé.
Cette méthode permet d'obtenir sous la forme d'un tableau de champs (objets de la classe
"Field" de Java, définie dans le package "reflect" - reflexivité - du langage), l'ensemble des
attributs d'une classe, quelle que soit leur visibilité. L'effet de la méthode se limite toutefois
aux champs définis dans la classe même, sans remonter vers les classes ancêtres. Ce problème
est résolu par la méthode getObjectFields( ) dont le rôle est de construire un tableau de champs
en remontant l'ensemble de l'arborescence des générations.

En fait, la solution n'est pas encore entière car il reste encore à récupérer les valeurs des
attributs. Pour ce faire, la classe "Field" de Java dispose d'une méthode particulière appelée
"get(Object )" qui reçoit en argument l'objet dont on veut connaître la valeur du champ en
question. Le problème est que cette méthode ne peut - heureusement - pas avoir accès aux
valeurs des attributs privés et protégés d'une classe, elle ne peut donc être directement utilisée
dans la classe SelectedObject, même si c'est le champ concerné qui y fait appel. Pour
contourner le problème, nous avons donc muni la classe WorkflowObject (mère de toutes les
classes 2FLOW) de la méthode "getFieldValue(Field)" à laquelle on passe en argument un des
propres attributs de la classe - le champ dont on veut connaître la valeur. Cette méthode
invoque à son tour la méthode "[Link]( )" ce qui résout le problème car la localisation de
l'appel a ainsi été déplacée vers la classe concernée, qui a accès à l'ensemble de ses attributs.

1: select( )
:ControlerPanel
2 : select(indexSelection)

:ControlerEngine 4 : getObjectFields( )

3 : créer(objet) :Field
:SelectedObject

8 : créer(this)
5 : créer(nom des champs) 9 : getFieldValue(field)
value
:WorkflowObject
6 : select( ) 7 : getField
:ObjectPanel (indexSelection)
10 : créer(fieldName, fieldType, fieldValue)

:AttributePanel

Figure IV.38 - Diagramme de collaboration des objets du contrôleur générique pour

l'affichage des objets Workflows et de leurs attributs

Le même problème se pose, en sens inverse, pour l'affectation de nouvelles valeurs aux
attributs sélectionnés. La classe SelectedObject propose pour ce faire une méthode,
setFieldValue(Object), à laquelle on passe la nouvelle valeur "castée" vers le type générique
"Object". Celle-ci invoque à son tour la méthode setFieldValue(Field, Object) de la classe
WorkflowObject qui a le choix entre deux solutions possibles.

La solution la plus simple consiste à utiliser la méthode "[Link]( Object, Object)" de Java.
Celle-ci affecte à l'attribut d'un objet la valeur d'un autre objet, en essayant de forcer une
conversion de type (du type Object vers le type de l'attribut). Le problème est que cette
opération n'est pas toujours couronnée de succès quand le type en question ne propose pas de
constructeur adéquat ou quand la classe est trop complexe. Le moyen que nous avons adopté

180
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

consiste à définir au niveau de chaque classe de base de 2FLOW, une méthode setXXX(Object)
associée à un attribut de nom XXX susceptible d'être modifié en cours d'exécution. Par
exemple la classe CFB possède l'attribut componentsNames de type StringVector. Nous lui
associons donc la méthode setComponentsNames(Object) permettant de lui affecter une valeur.

Ainsi lorsqu'elle est appelée, [Link]( ) commence d'abord par

rechercher une méthode setXXX( ) qu'elle invoque si elle existe. Dans le cas contraire, elle
appelle "[Link]( )". L'intérêt est de laisser chaque classe proposer sa solution pour attribuer
correctement des valeurs à ses attributs.
1 : setValue(valeur )
:AttributePanel 2 : setFieldValue(valeur)

3 : setFieldValue(field, valeur)

:SelectedObject :WorkflowObject

4 : choix du mécanisme adéquat

Figure IV.39 - Diagramme de collaboration des objets du contrôleur pour l'attribution

de valeurs aux attributs des objets Workflows

[Link] Limites

L'approche du contrôleur générique est intéressante mais limitée. En effet, elle ne s'applique
que sur les classes déjà instanciées des workflows. Or nous avons vu que l'exécution des
processus 2FLOW est répartie et que l'instanciation des classes est progressive. Par
conséquent, le contrôleur ne peut agir que sur les objets existants qui de plus n'ont pas encore
terminé leur tâche dans le workflow. Par exemple si une activité a été instanciée, il est inutile
d'essayer de modifier le nom du rôle (ou de l'acteur) qui la réalise, étant donné qu'un acteur
aura déjà été notifié dès la création de l'objet activité, sauf si l'activité en question est dans un
BCF bouclé. Dans ce cas la modification est prise en compte lors des autres "passages".

Nous avons volontairement choisi de ne pas permettre la manipulation des comportements des
objets 2FLOW via le contrôleur, les attributs seuls pouvant être affectés. Néanmoins,
plusieurs opérations intéressantes peuvent être réalisées à l'aide du contrôleur, telles modifier
les noms des événements générés par l'activité, les noms des activités ou des expressions
logiques suivantes, etc. Il est également possible de remanier la structure d'un workflow en
changeant le contenu des BCF, via leur attribut componentsNames. Bien entendu, ces
modifications doivent se faire en respectant la cohérence du workflow sous-jacent, ce qui peut
nécessiter l'ajout de classes ou la modification d'autres composants.

Des fonctions de vérification de la cohérence des workflows suite aux modifications sont en
cours d'études. Etant donné l'importance et la complexité de la tâche - réalisation d'un
analyseur de modèles workflow - ces fonctions n'ont pas encore été implémentées dans
2FLOW. Notons enfin qu'étant donné l'impact du contrôleur sur l'ensemble des classes du
workflow, il n'est évidemment pas accessible à tous les utilisateurs. Il convient donc à ceux-ci
de définir les rôles ayant le privilège de l'accès à cet outil, afin de préserver le bon
fonctionnement des processus.

181
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

4.2.2 Approche par modélisation dynamique

Nous avons vu que l'usage du contrôleur générique des objets 2FLOW connaissait certaines
limites, notamment au niveau des comportements et des classes non instanciées. Afin
d'englober l'ensemble des besoins de l'adaptation dynamique, nous proposons un autre outil,
complémentaire du premier, qui n'est autre que l'éditeur générique de 2FLOW, que nous
n'avons fait que mentionner jusqu'à présent.

[Link] Description de l'éditeur

Afin de faciliter la tâche des

concepteurs et des développeurs de
workflows basés sur les composants
de notre framework, nous avons conçu
un prototype d'éditeur générique (aux
fonctionnalités assez restreintes pour
le moment).

Les classes composant l'éditeur sont

contenues dans le package
"WorkflowModeller" de l'architecture
2FLOW. Son principe de
fonctionnement est le suivant : il
propose d'un plan de travail dans
lequel les utilisateurs vont dessiner les
différents composants du workflow, Figure IV.40 - Plan de travail de l'éditeur
sous la forme de classes UML ( fig. générique 2FLOW
IV.40) .

Le fait de double-cliquer sur le dessin d'une classe déclenche l'ouverture de la fenêtre de ses
propriétés, c'est à dire l'ensemble de ses attributs et ses méthodes (fig. IV.41). Cette fenêtre est
l'outil principal de construction des
composants Workflow. En premier lieu,
l'utilisateur y est invité à saisir le nom de la
classe ("NewWorkflowClass" par défaut).
Les deux champs suivants sont très
intéressants. Le premier est intitulé
"stéréotype".

Dans la notation UML, un stéréotype est un

type de composant du langage, qu'il est
possible d'utiliser pour qualifier des classes
ou des éléments de modélisation. La plupart
des composants du métamodèle UML sont
des stéréotypes ("classe", "relation", etc.).
Les stéréotypes permettent d'étendre la Figure IV.41 - Fenêtre des propriétés d'un
sémantique des éléments de modélisation : composant 2FLOW
il s'agit d'un mécanisme d'extensibilité du
métamodèle d'UML, qui permet de définir de nouvelles classes d'éléments de modélisation,
en plus du noyau prédéfini par UML. D'autres stéréotypes plus spécifiques ont été créés, tels

182
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

par exemple les stéréotypes servant à la modélisation de processus ("Acteur", "Rôle",

"Processus", etc.). Au niveau de la modélisation, le fait de rapporter les classes des
diagrammes à un stéréotype permet de mieux comprendre leur utilisation. Par exemple la
création d'un stéréotype <<utilitaire>> associé à certaines classes d'un diagramme éclaircit le
rôle joué par celles-ci dans l'application. L'un des intérêts d'UML est donc de permettre aux
utilisateurs de la notation d'introduire leurs propres stéréotypes. C'est ce que nous avons fait
dans 2FLOW où chaque classe de base du framework correspond à un stéréotype. Ainsi lors
de la modélisation, toute nouvelle classe créée par un utilisateur est associée à un stéréotype
qu'il choisit dans la liste qui lui est proposée. Dans l'exemple de la figure précédente, nous
avons créé une nouvelle activité, en choisissant le stéréotype "Activity".

Le deuxième champ auquel nous nous intéressons dans la fenêtre des propriétés est le champ
intitulé "Extends Workflow Class". Il permet de choisir une classe non pas parmi les
stéréotypes mais parmi les classes déjà créées par les utilisateurs. Pour ce faire, une recherche
descendante est effectuée depuis les packages "Classes de base des utilisateurs" et celui des
"Workflows utilisateurs" qui contient les classes de tous les workflows déjà construits.
Lorsqu'un stéréotype et/ou une classe mère sont
sélectionnées, leurs attributs sont automatiquement
chargés dans la liste correspondante, intitulée
"Attributes". Il est possible d'en sélectionner les
éléments pour modification, grâce au bouton "/"
(éditer), ce qui a pour effet d'afficher la fenêtre des
propriétés des attributs. Celles-ci concernent le nom
de l'attribut, sa visibilité (privé, protégé, public),
son type, qu'il est possible de choisir parmi les types
élémentaires (entier, réel, chaîne, etc.) ou parmi
toutes les classes Workflows (stéréotypes et classes
utilisateurs confondues). La propriété "Value" sert à
indiquer la valeur initiale de l'attribut (affectée lors Figure IV.42 - Fenêtre des propriétés
de l'appel du constructeur de la classe). Cette d'un attribut d'un composant
initialisation a lieu si le champ "Must initialize" est
mis à "true". Si un attribut a été sélectionné au préalable, alors ses propriétés sont affichées
dans la fenêtre, sinon les champs sont vides ou munis de valeurs par défaut. La figure 4.38
correspond à l'attribut "roleName" d'une activité. Il est initialisé avec la valeur "Operateur",
c'est donc ce rôle qui sera chargé de réaliser l'activité en question lors de l'exécution.

Enfin le dernier champ correspond à la liste des

comportements de la classe, c'est à dire ses
méthodes. Contrairement à la liste des attributs,
celle-ci n'est automatiquement "remplie" que par les
méthodes de la classe mère (et celles des autres
classes ancêtres). Les méthodes des stéréotypes -
qui ne sont pas toutes connues des utilisateurs car
participant au fonctionnement interne du
framework- ne peuvent être directement redéfinies
ou surchargées. Les concepteurs peuvent toutefois
créer des méthodes de même nom (en s'aidant d'une
documentation sur le framework) et les modifier via Figure IV.43 - Fenêtre des propriétés
l'éditeur, afin de les redéfinir ou de les surcharger. d'une méthode d'un composant

183
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

Les propriétés d'une méthode sont son nom, sa visibilité, sont type de retour (qui peut être
choisi parmi tous les types de base et les types Workflows, ainsi que la liste de ses arguments,
référencée par le champ "parameters". Ce dernier peut également être remanié via une fenêtre
spécifique affichant les propriétés de chaque argument sélectionné ou permettant d'en ajouter
de nouveaux ou d'en supprimer.

Enfin, la fenêtre des propriétés donne

également accès à un petit éditeur de
texte intégré, qui permet de saisir
directement le code de la méthode en
question. Ainsi dans notre exemple (fig.
IV.44), nous avons ajouté une nouvelle
méthode nommée "getActor", à notre
classe de stéréotype "Activity". Son rôle
est de renvoyer la référence de l'acteur
associé à l'activité. Le code de cette
méthode est directement saisi dans
l'éditeur de texte, qui n'est pour le
moment pas muni de fonctionnalités
avancées mais sert uniquement dans un
but utilitaire. Figure IV.44 - Editeur de code pour les méthodes
des composants Workflows.

Notons que l'utilisateur a la possibilité de naviguer entre

les classes qu'il a créées grâce à une fenêtre décrivant une
arborescence. Chaque nœud de l'arbre correspond à une
classe, les feuilles correspondant quant à elles à leurs
attributs et à leurs méthodes respectifs. Enfin, cliquer sur
un n œud de l'arbre permet de le repérer immédiatement
sur le plan de travail, ce qui est utile lorsque le modèle
devient conséquent.

Une fois les propriétés de la classe saisies ou modifiées,

elles peuvent être validées en cliquant sur le bouton
"Validate". Le bouton "Generate" de la fenêtre des Figure IV.45 - Arbre des classes
propriétés permet quant à lui, de générer un fichier de
définition ("Workflow Definition File") dans un package spécifique nommé
"XXX_Definitions" où XXX correspond au nom du workflow, placé à l'intérieur du package
du workflow (nommé "XXX"). Ce fichier est modifié pour chaque validation du contenu de la
classe.

Enfin, lorsqu'il l'estime utile, l'utilisateur de l'éditeur peut choisir de générer le code Java des
composants qu'il a créés, et de le compiler en cliquant sur le bouton "Generate" de l'éditeur.
Ceci cause l'appel de la classe "CodeGenerator" qui se base sur les fichiers de définition pour
produire deux séries de fichiers, l'une contenant le code source Java des classes, et l'autre leur
code objet. Le compilateur utilisé est celui du JDK de Sun et il n'est pas possible pour le
moment de laisser à l'utilisateur le choix d'un compilateur spécifique.

En réalité, la construction du code Java de chaque composant dépend de son stéréotype,

notamment dans la définition du constructeur. En effet, en règle générale, l'initialisation des

184
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

attributs objets est toujours réalisée lors de l'appel du constructeur de leur classe. Dans le cas
de 2FLOW, les valeurs initiales sont introduites, comme nous venons de le voir, lors de la
modélisation dans l'éditeur. Or chaque stéréotype étant muni d'attributs spécifiques, il est
nécessaire d'en réaliser une initialisation spécifique également. Pour ce faire, nous avons
défini un générateur de code par stéréotype, formalisé par des classes dont les noms sont
composés du nom du stéréotype suivi de "Generator". Par exemple, le générateur d'une
activité s'appelle "ActivityGenerator".

Le click du bouton "Generate" déclenche un processus que nous allons décrire ci-après, dont
l'effet est entre autres d'invoquer la méthode "generate(String, String)" de la classe
CodeGenerator, en lui passant pour chaque composant, le nom du stéréotype concerné et le
nom du fichier de définition. Cette méthode crée ensuite une instance du générateur du
stéréotype, dont il appelle la méthode "generate(String)" avec comme argument le nom du
fichier de définition. Remarquons que l'instanciation se fait de façon générique uniquement
via le nom du stéréotype, ce qui permet d'ajouter autant de générateurs (et de stéréotypes) que
souhaité, sans modification de la classe CodeGenerator.

[Link] Modélisation dynamique

Comme nous l'avons vu, les fichiers de définitions contiennent la description de l'ensemble de
la structure d'une classe Workflow. Cela permet d'une part de générer les classes Java
correspondantes et d'autre part, de récupérer la définition des classes déjà existantes. Lors de
la création d'un composant à l'aide de notre éditeur, cette fonctionnalité est utilisée pour
l'importation des attributs et méthodes des classes mères et des stéréotypes. Nous l'utilisons
également lors de l'exécution, afin de connaître la structure des composants du workflow en
cours de réalisation. Dans l'éditeur, la classe contenant l'ensemble des propriétés (attributs +
méthodes) d'un composant est appelée "ClassProperties". A l'instar du contrôleur présenté dans
un précédent paragraphe, elle joue également le rôle de métaclasse générique, puisqu'elle
permet de connaître et de manipuler l'ensemble des propriétés d'un composant, non pas en se
basant sur son code Java, mais sur son fichier de définition. A l'opposé du contrôleur, cette
classe ne met pas en œuvre de mécanismes d'introspection et de réification, puisqu'elle ne
permet pas de connaître l'état d'un objet. Grâce à la classe ClassProperties, il est donc possible
de modifier les caractéristiques d'un composant, que ce soit hors ou en cours d'exécution,
puisqu'on manipule principalement les fichiers de définition Workflows.

Si les modifications sont dynamiques, il est nécessaire de les répercuter directement sur le
workflow en cours, en tenant compte des différents niveaux d'adaptation dont nous avons
précédemment discuté : le niveau local, le niveau local généralisé et le niveau global.

En premier lieu, il est nécessaire de générer le code

source des classes adaptées et de le compiler. Cela est
fait, comme nous l'avons vu, grâce au bouton
"Generate". Nous avons toutefois volontairement omis
d'indiquer qu'un click sur ce bouton provoquait au
préalable l'apparition de l'interface graphique de la
classe CodeGenerator, dans laquelle l'utilisateur doit
fournir deux informations primordiales :

§ L'adaptation concerne-t-elle un workflow "passif" Figure IV.46 – Choix du mode

d'adaptation des workflows

185
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

(qui n'est pas en train de s'exécuter) ou un workflow en cours d'exécution ?

§ Quel est le niveau de l'adaptation ? Ce renseignement n'est nécessaire que s'il s'agit
d'un workflow en cours d'exécution.

Nous avons indiqué que lors de l'exécution d'un workflow (lors de l'occurrence d'un "cas"), un
package spécifique au cas est créé, dans lequel sont recopiés puis instanciés les composants
du workflow. Le nom du package "d'instance" est composé du nom du package initial plus un
numéro attribué par un compteur. Par exemple, une première instanciation du workflow
d'hospitalisation que nous avons vu précédemment génère un package nommé
"Hospitalisation_001".

Afin d'éviter le maximum d'incohérences, la stratégie d'adaptation que nous proposons pour
l'instant consiste à ne modifier que les classes qui n'ont pas encore été instanciées, donc dont
les modifications peuvent être prises en compte à coup sûr, sans remettre en cause la stabilité
du processus. Les noms des classes ayant déjà été instanciées peuvent facilement être obtenus
grâce au contrôleur générique que nous avons décrit précédemment.

Le principe d'adaptation en cours d'exécution dans 2FLOW est le suivant : Lorsque l'ordre de
modifier un workflow est émis, le générateur de code appelle les services d'une classe appelée
WorkflowTranslator. Son rôle est de créer un nouveau package dans lequel elle va générer les
fichiers source et objet des classes modifiées, puis y copier ceux des classes non modifiées.

Si le package duquel sont copiées les classes est un package d'instance, alors le
WorkflowTranslator invoque la méthode translate( ) du référentiel du workflow en cours - que
nous n'avons pas encore décrite. L'appel de cette méthode enclenche un processus composé de
trois étapes principales :

§ En premier lieu, le référentiel va créer un nouveau référentiel, dans le nouveau

package d'instance.

§ En deuxième étape, le référentiel parcours l'ensemble de ses éléments, en testant s'il

s'agit d'un composant exécutable (RunnableComponent) - donc possédant son propre
thread d'exécution. Si c'est le cas, le référentiel suspend l'exécution de l'objet, puis en
crée un clone qu'il ajoute au nouveau référentiel. Dans le cas contraire, l'objet est
uniquement cloné. Remarquons que la suspension de l'exécution d'un composant
exécutable correspond à l'invocation de sa méthode suspend( ) qui a deux fonctions
essentielles : la sauvegarde de l'état de l'objet à ce moment et la suspension de son
thread d'exécution.

§ En troisième étape, les objets exécutables de "l'ancien" référentiel courant sont stoppés
puis l'ensemble des objets est supprimé du référentiel. les objets exécutables sont
relancés dans le nouveau référentiel.

Enfin, le WorkflowTranslator passe le contrôle au nouveau référentiel en invoquant sa méthode

resume( ), qui a pour effet de relancer l'exécution de tous les objets exécutables qui y ont été
clonés. Chaque composant exécutable de 2FLOW est en effet muni d'une méthode (également
nommée "resume( )" ) qui lui permet de reprendre son exécution à partir de son dernier état.
L'ancien package d'instance est par la suite éliminé et le nouveau package prend son nom.

186
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

En fonction du niveau d'adaptation choisi, cette manipulation est réalisée pour un seul
package (niveau local), pour tous les packages dont le workflow - du même processus - est en
cours d'exécution (niveau local généralisé). Enfin au niveau global, les modifications sont
également répercutées sur le package initial.

Workflow X
Classe2
Classe1

Classe4
Classe3

Workflow X_00n - instance Workflow X_00n - instance Workflow X_00n - instance

Classe2 Classe2 Classe2
Classe1 Classe1 Classe1

Classe4 Classe4 Classe4

Classe3 Classe3 Classe3

Classe1
Workflow X - instance bis Workflow X_00n - instance

Définitions Classe2 (copie) Classe2

Classe4
Classe1 Classe1
des composants
Classe4 Classe4
Classe3 Classe3
(copie)

Etape 1 Etape 2 Etape 3

modifications Création Renommer
EDITEUR GENERATEUR GENERATEUR
Générer de de
CODE supprimer CODE

Figure IV.47 - Mécanisme d'adaptation en cours d'exécution

4.3 Gestion des exceptions

Comme nous l'avons vu dans la partie de ce chapitre consacrée au fonctionnement de
2FLOW, une exception est un type particulier d'événement, dont elle reprend le
comportement. Chaque exception est concrétisée par une classe dérivant de la classe mère
ExceptionWorkflow, et est associée en entrée à une ou plusieurs activités - voir à des
expressions logiques. Les exceptions peuvent également être produites par les activités d'un
processus - elles y sont dans ce cas liées en sortie.

4.3.1 Représentation et prise en charge des exceptions

Les activités ou les processus consommant des exceptions en entrée, jouent le rôle de
gestionnaires d'exceptions, puisqu'elles détectent leur occurrence et effectuent en conséquence
une tâche déterminée - plus réellement, elles notifient le rôle concerné d'exécuter le travail
correspondant. Il est donc assez aisé de créer des gestionnaires d'exception à l'aide des
composants de 2FLOW, puisqu'il s'agit de créer des classes d'exceptions et de les lier à des
classes d'activités ou à des processus.

187
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

AgentAdministratif ChefDeService Chirurgien ChefDeService

Reprenons encore une fois le processus de
base de l'hospitalisation d'un malade. Nous
le représentons cette fois à l'aide d'un
EtablirDA
diagramme d'activités UML. Dans ce
processus, nous avons considéré la EtablirDM

possibilité que le chirurgien désigné pour DossierA DossierM

[complet] [complet]
l'opération ne pouvait être disponible au
jour prévu pour diverses raisons (accident, [JourFixé]
{Chirurgien = X}
empêchement, etc.). Il s'agit donc d'une
[TrouvéRemplaçant]
exception que nous représentons par {Chirurgien = Y} Operer
l'événement "[ChirurgienIndisponible]". [JourSortie] Facturer

Cette exception est associée à l'activité [ChirurgientIndisponible]

"Remplacer" du processus, réalisée par le Remplacer
DossierA
[complet]
chef de service. En cas de succès, cette
activité génère un nouvel événement,
"[TrouvéRemplaçant]" qui relance : artefact : flux des tâches [ XXX ] : événement
l'activité opérer - ce qui se traduit dans le
: Activité : flux des artefact { XXX } : contrainte
composant 2FLOW par un nouvel appel à
: Synchronisation : branchement conditionnel
la méthode notifyActor( ). Remarquons que
dans ce cas, un acteur est fixé pour
l'activité, non pas lors de l'initialisation, Figure IV.48 - Processus d'hospitalisation
mais lors de la résolution du problème d'un malade avec gestion d'une exception
soulevé par l'exception.

Afin de permettre l'affectation d'un acteur en cours d'exécution, nous proposons donc une
surcharge de la méthode notifyActor( ) de la classe Activité, prenant en argument le nom de la
classe de l'acteur concerné. Cela implique toutefois que ce dernier doit exister en tant que
composant du workflow (il a donc été identifié au préalable comme acteur potentiel, lors de la
modélisation). Supposons que ce ne soit pas le cas, c'est à dire que dans notre processus, le
chef de service fasse appel à un chirurgien exerçant dans un autre hôpital. Il est alors
nécessaire d'utiliser les mécanismes de modélisation en cours d'exécution de 2FLOW, en plus
de la gestion de l'exception, afin de créer une nouvelle classe d'acteur. Au niveau du processus
d'hospitalisation, le choix du remplaçant étant fixé par le chef de service, cela implique que
c'est également à lui d'introduire le nouveau composant dans le workflow en cours. Pour ce
faire, il doit avoir accès à l'éditeur et doit donc tenir un autre rôle lui accordant ce privilège.

4.3.2 Les exceptions imprévues

Dans l'exemple précédent, nous avons vu que l'exception avait clairement été identifiée au
moment de la modélisation, il s'agit donc d'une exception "prévue" : c'est un événement
exceptionnel mais connu. Pour traiter le cas des exceptions imprévues (ou plutôt inconnues),
nous avons créé la classe "ExceptionWorkflowGenerique" qui est automatiquement associée à
chaque activité d'un processus. Lorsqu'elle est instanciée, cette classe instancie à son tour un
processus, générique lui aussi, qui est chargé de traiter les exceptions inconnues, et dont la
classe doit être redéfinie au niveau des workflows utilisateurs.

Ces deux classes permettent de traiter n'importe quel type d'exception mais restent à un niveau
très global qui ne permet pas toujours de répondre de façon appropriée à la situation, bien
qu'ils permettent d'éviter la "panne". Il est donc conseillé de les spécialiser afin de créer des

188
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

catégories d'exceptions, dont les processus de prise en charge seront plus spécifiques - tout en
restant dans une granularité de traitement assez grossière.

4.3.3 Conclusion sur la gestion des exceptions dans 2FLOW

La génération d'exception - et plus globalement d'événements - est encore en cours d'étude

dans le framework, notamment parce que nous avons concentré nos efforts sur la mise en
œuvre de l'adaptabilité. Pour le moment, les seuls types d'événements qu'une activité "sait"
automatiquement générer sont ceux de fin d'activité ou ceux qui correspondent à son échec ou
encore à son blocage. Bien sûr, il est possible aux utilisateurs du framework de créer des
classes d'événements à volonté et leur traitement sera réalisé correctement, à condition que
leurs classes soient instanciées lors de l'exécution. Le problème qui se pose est donc de créer
des mécanismes permettant aux utilisateurs ou aux applications externes "d'injecter" des
événements dans les workflows, donc d'en instancier les classes. Ces mécanismes sont en
cours de réalisation. Ils devraient déboucher sur la définition de nouvelles méthodes au sein
des activités ainsi que la création de "clients 2FLOW" attribués aux acteurs des processus, en
particulier les acteurs humains. Jusqu'à présent, les événements et les exceptions "externes"
sont injectés "manuellement" dans les processus, à des fins de tests - qui sont du reste réussis.
Cet "inconvénient" devrait donc être réglé au fur et à mesure de la maturation de 2FLOW et
de la création d'outils exploitant les mécanismes qu'il propose.

189
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

5. Méthode et formalismes de modélisation

Jusqu'à présent - mis à part lorsqu'il s'agissait d'une modélisation de classes 2FLOW - nous
avons représenté les processus à l'aide de formalismes quelconques, le plus souvent basés sur
des formalismes existants. Pour la construction de Workflows à l'aide des composants de
notre framework, nous proposons néanmoins une méthode de modélisation inspirée des
méthodes d'analyse et de conception Objet du Génie logiciel. Nous y utilisons certains des
formalismes et les diagrammes disponibles dans le langage UML. Notre objectif n'est
toutefois pas d'apporter une nouvelle contribution au domaine déjà riche de la modélisation
Workflow. Notre but est essentiellement utilitaire, visant à faciliter la construction de
workflows par composition des classes du framework.

Dans les paragraphes précédents, nous avons souvent utilisé les diagrammes de classes et les
paquetages pour la représentation des workflows et de leurs constituants. Les diagrammes de
classes et de composants (paquetages) ne représentent que la finalité de l'usage de la méthode,
le résultat à obtenir. Comme nous allons le voir, nous faisons appel à d'autres diagrammes qui
nous permettent d'élaborer peu à peu les modèles finals.

5.1 Pourquoi UML ?

Deux raisons ont essentiellement motivé et justifié l'utilisation d'UML comme langage de
modélisation :

1. L'intégration et la cohérence des modèles et des points de vue.

2. La mise à disposition d'un moyen facilitant la communication entre les différents acteurs
de la conception des workflows et de leurs systèmes.

1. La première de ces raisons est due à la nature Objet des composants du framework. En
effet, étant donné que celui-ci est composé de classes, et que nous utilisons les propriétés
des Objets pour la mise en œuvre des mécanismes d'adaptation, il est nécessaire d'utiliser
des formalismes propres à ces concepts. C'est ce qui est fait au niveau de la représentation
de la structure des workflows, à l'aide des diagrammes de classes. Cependant, en plus de
la modélisation de leur structure, il est nécessaire de représenter la dynamique des
workflows : le flux des tâches et des artefacts, les attributions de rôle, etc. Or un autre
intérêt d'UML est le grand nombre de types de diagrammes qu'il propose, et notamment
des diagrammes permettant de représenter la dynamique des systèmes : les diagrammes
d'activités, les diagrammes de collaboration et les diagrammes de séquence. Cet intérêt est
mis en relief par la forte cohérence qui existe entre les différents types de diagrammes. En
effet, les diagrammes de collaboration et d'activités permettent de représenter le
déroulement d'un processus en y représentant les objets qui participent à sa réalisation. Il
est par conséquent facilement possible de les utiliser pour l'élaboration d'autres
diagrammes, en particulier les diagrammes de classes. Du moins, il est aisé d'établir la
correspondance entre les éléments d'un diagramme d'activités et ceux d'un diagramme de
classes, puisqu'il s'agit pour la plupart des mêmes éléments présentés sous des aspects
différents. Nous percevons donc l'usage d'UML comme un moyen d'assurer la cohérence
entre les différents points de vue, grâce à leur capacité d'intégration commune. Cette
propriété n'est pas proposée par toutes les méthodes de modélisation où il est parfois
difficile de trouver les liens qui existent entre un point de vue et un autre.

190
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

2. Au début de ce chapitre, nous avons constaté qu'UML est largement répandu au sein de la
communauté des spécialistes des Objets, mais également dans d'autres domaines - non
informatiques - dont les membres utilisent déjà certains types des diagrammes du langage.
Beaucoup d'entre eux possèdent également une culture UML générale. Par conséquent,
UML peut être perçu non seulement comme un moyen d'intégration et de cohésion entre
les modèles, mais également en tant que langage commun et outil de cohésion des
différentes équipes attachées à la réalisation d'un projet. Cette possibilité nous semble
particulièrement intéressante pour la modélisation et la conception de workflows, qui
rassemble les acteurs et les concepteurs des processus, ainsi que les éventuels
développeurs Workflows. Cet aspect d'intégration pluri-culturelle et pluridisciplinaire est
relevé par d'autres personnes, notamment [Link] [FOWLER et al. 97] et [Link]
[HRUBY 98]. Ces deux spécialistes, le premier dans le domaine des Objets, l'autre du
Workflow, estiment qu'UML est un outil facilitant la communication entre les différents
partenaires d'un projet. En particulier, les diagrammes de cas d'utilisation et les
diagrammes d'activités (ou de séquence) proposent des formalismes simples et clairs, qui
permettent de bien appréhender les premières approches du problème. P. Hruby préconise
d'ailleurs l'utilisation de ces deux types de diagrammes en tant qu'outil commun pour la
définition des besoins et des fonctionnalités des systèmes Workflows, par les utilisateurs
et les concepteurs de ces systèmes.

5.2 Description de la méthode

5.2.1 Les cas d'utilisation
Administrateur
Les cas d'utilisation ("use case") servent à système
Administrer
déterminer les principales fonctionnalités d'un
système, qu'il soit informatique ou non. Ils se Client

focalisent principalement sur l'expression des Conseiller

Gérer les Suivre
exigences du système par rapport à ses dossiers dossier

utilisateurs ou plutôt aux types d'utilisateurs. Ces

Communiquer Communiquer
types sont exprimés à l'aide de "rôles", tels par avec le client avec le conseiller

exemple "administrateur", "employé", "chef de

<< utilise>> << utilise>>
service", etc. La figure ci-contre donne un communiquer

exemple de cas d'utilisation d'un système Système

informatique d'une compagnie d'assurance,

permettant de gérer des plaintes de clients via le Figure IV.49 – cas d'utilisation
Web. Chaque plainte de la part d'un client
donne lieu à l'ouverture d'un dossier assigné à un conseiller. Le système propose quatre
fonctions principales : la gestion des dossiers, réalisée par les conseillers, le suivi - et le dépôt
- du dossier via le Web de la part du client, la communication entre client et conseiller (qui
sont deux fonctionnalités qui en utilisent une même troisième, et enfin, la dernière fonction
étant l'administration du système, à la charge d'un administrateur. Un cas d'utilisation peut
être raffiné en plusieurs autres cas. Ainsi dans notre exemple, il est possible de créer un cas
d'utilisation décrivant plus en détail la fonctionnalité d'administration du système.
Remarquons enfin qu'un cas d'utilisation peut être accompagné d'une description textuelle de
plusieurs pages.

Le formalisme des cas d'utilisation est simple à comprendre et à repérer car il s'appuie sur
deux notions, ce qui facilite la création des diagrammes ou du moins, leur compréhension. En
ce qui nous concerne, il nous semble intéressant de faire un rapprochement entre les cas

191
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

d'utilisation et les besoins de la modélisation Workflow. En effet, la notion de rôle y est

naturellement présente et s'apparente très bien avec celle du Workflow où elle décrit en plus
d'un type d'utilisateurs, un ensemble de compétences. Par ailleurs, les formalismes
représentant les fonctionnalités d'un système dans un cas d'utilisation peuvent facilement être
utilisées pour représenter les principales activités ou les principaux sous-processus d'un
workflow. D'autant plus qu'elles sont directement reliées aux rôles et qu'il est possible de les
raffiner – à l'instar des processus – en d'autres cas d'utilisation plus détaillés.

La simplicité des cas d'utilisation, nous l'avons constaté, fait de ce type de diagramme un
vecteur de communication de choix. En effet, lors de la conception des modèles de processus,
les personnes qui en sont chargées travaillent en étroite collaboration avec les futurs acteurs
ou utilisateurs du processus. Leur but étant de comprendre, d'analyser et d'exprimer au mieux
leurs besoins et la situation. Il est donc très intéressant de disposer d'un média commun de
dialogue, qui de plus est spécifiquement dédié à l'analyse des besoins. Cet avantage combiné
au rapprochement des concepts des cas d'utilisation avec ceux du workflow, font des cas
d'utilisation un moyen très intéressant pour une première analyse et conception des modèles
Workflows. C'est donc à cette fin que nous les utilisons dans notre méthode. Ce choix a
également été retenu par d'autres méthodes pour les mêmes raisons, notamment celle
développée par le système WIDE [WIDE 97], [BARESI et al. 99], ainsi que par la méthode de
spécification des systèmes Workflows, développée par P. Hruby [HRUBY 98].
Spécialiste
médical
Dans l'exemple suivant, nous illustrons la façon Expert
dont il est possible d'utiliser les cas d'utilisation Valider
assurance
le dossier
des workflows. Considérons le processus de médical
Validation
traitement des remboursements des frais administrative
du dossier
médicaux d'une assurance. Après une première Spécialiste Agent
médical
analyse, on peut globalement le décomposer en comptable
Rembourser
trois tâches (au sens large) principales : la
validation du dossier par deux médecins Workflow
rattachés à la compagnie, la validation
administrative du dossier par un expert et enfin Figure IV.50 – Première analyse
le remboursement des frais au client. d'un workflow à l'aide de cas
d'utilisation
Spécialiste
Après une première analyse aboutissant au médical Validation
diagramme de la figure IV.50, il est possible de médicale 1

raffiner le modèle en s'intéressant à chacune Concertation

des tâches qui y sont définies. Ainsi, la Spécialiste
médical Validation
validation du dossier médical se décompose en médicale 2
fait en trois activités : la validation médicale
Sous-cas : validation dossier médical
(adéquation des soins prodigués avec le mal du
patient, etc.), réalisée deux fois mais Expert Vérification
du dossier client
assurance
séparément par deux spécialistes médicaux
Contact de
distincts, et une concertation réalisée l’hôpital

conjointement par ces deux acteurs. Quant à la Mise à jour

tâche de validation administrative, elle se Agent du dossier
comptable Sous-cas: validation administrative
décompose en une séquence de trois activités :
Rembourser
la vérification du dossier du client (vérification Workflow
si les cotisations sont à jour, vérification des
antécédents de remboursement, droits offerts Figure IV.51 – Affinage des cas
par le type de contrat souscrit etc.), la d'utilisation

192
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

vérification auprès de l'hôpital concerné de la véracité des documents produits par le client, et
enfin, une mise à jour de son dossier. Nous pouvons donc raffiner le cas d'utilisation
précédent en trois nouveaux cas, tels que nous le montrons dans la figure IV.51.

Nous proposons de continuer l'analyse et la décomposition progressive des cas d'utilisation -

en détaillant les tâches trop globales – jusqu'à l'obtention d'une représentation très proche de
la réalité du processus. Cette décomposition doit permettre d'aboutir à la représentation de la
structure du processus (sa vue fonctionnelle), c'est à dire sa décomposition en termes
d'activités et de sous-processus (les sous-cas).

5.2.2 Diagrammes d'activités

La première étape de la méthode a conduit, après une analyse plus ou moins approfondie, à
une première modélisation de la structure du processus. La deuxième étape consiste
maintenant à approfondir ce modèle, à lui "donner vie", c'est à dire à y représenter les flux des
tâches, les événements déclencheurs et ceux qui sont générés, les choix qui peuvent être
réalisée, ainsi que les objets qui y sont manipulés.

Cette étape est concrétisée à l'aide des diagrammes d'activités d'UML. Ceux-ci sont utilisés à
différents niveaux de granularité, depuis la représentation du fonctionnement d'une méthode
d'un objet, l'échange des messages entre objets ou plus globalement, le déroulement d'un
processus. Ainsi que nous l'avons dit dans le deuxième chapitre de ce mémoire, les
diagrammes d'activités proposent un ensemble de notions très intéressantes au niveau du
Workflow. En effet, il est possible d'y représenter les activités et leur flux, ainsi que celui des
objets manipulés qui sont également représentés, les événements et/ou les contraintes en
entrée des activités, ainsi que les rôles
Medecin Medecin Expert Assurance Comptable
chargés de les réaliser. De plus, les
diagrammes d'activités proposent des
opérateurs de choix (branchements Validation
Validation
conditionnels) ainsi que des opérateurs Médicale 1 Médicale 2
de synchronisation ou de mise en
parallèle des flux. Nous utilisons les
Concertation
diagrammes d'activités afin d'affiner les
[conforme]
détails des modèles obtenus par les cas [anomalie]
d'utilisation. Cet affinage peut par ailleurs Dossier

servir à mettre en évidence des lacunes de Vérification

dossier
Lettre refus
l'analyse ou des incohérences dans le [non conformité]
[ok]
processus - puisqu'on descend dans le
niveau de détails. Il est alors nécessaire Lettre de mise Contact
en règle Hôpital
de boucler vers la première étape, jusqu'à
[incohérence]
l'obtention d'un modèle cohérent. D'autre [ok]

part, les diagrammes d'activités peuvent Avertissement

Mise à jour
servir à valider et à enrichir un premier dossier
niveau – non détaillé – des modèles des Rembourser
cas d'utilisation. La démarche à suivre
Chèque
consiste ensuite à affiner progressivement
les cas d'utilisation en s'aidant des
diagrammes d'activités, et ainsi de suite
jusqu'à l'obtention d'un diagramme Figure IV.52 - Diagramme d'activités -
d'activité suffisamment détaillé pour dynamique des workflows

193
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

passer à la troisième étape. Dans la figure ci-contre, nous représentons le diagramme

d'activités de l'exemple que nous avons initialisé dans le paragraphe 5.2.

Remarquons que dans un diagramme d'activités, la notation UML ne prévoit pas de

formalisme particulier pour une activité réalisée conjointement par plusieurs acteurs, comme
c'est le cas pour l'activité "Concertation". Nous l'avons donc placée "à cheval" entre les deux
lignes d'activités de chacun des deux acteurs, pour marquer sa réalisation collaborative.
Notons également que dans les diagrammes d'utilisation de la figure IV.52, nous avons mis en
évidence la présence de deux sous-processus, qui ne sont pas présents dans le diagramme de
la figure IV.52. En fait, nous avons souhaité y donner
Medecin 1/2 Expert Assurance Comptable
un premier aperçu des possibilités des diagrammes
d'activités. La meilleure approche consiste à établir
une modélisation progressive, depuis le diagramme Valider
le dossier
d'activité le plus général, jusqu'aux diagrammes médical

détaillant les sous-processus, ce qui permet de gérer [conforme]

la complexité de la modélisation. Par exemple, la [anomalie] Dossier

figure IV.53 représente la vue globale du processus,
inspirée du premier cas d'utilisation. Elle permet de Lettre refus Validation
administrative
plus de mettre en évidence les principaux événements du dossier

qui créent la dynamique du processus, ainsi que les [problème]

principaux objets qui y sont créés ou échangés. Documents
[ok] Rembourser
de refus

Nous proposons deux approches dans notre méthode

Chèque
de modélisation. La première consiste à affiner
successivement l'ensemble des cas d'utilisation, puis
de passer aux diagrammes d'activités. La deuxième
: sous-processus
approche, que nous préférons, consiste ainsi que nous
l'avons dit dans la page précédente, à mettre en œuvre
un processus itératif de modélisation, qui débute par Figure IV.53 - Vue globale d'un
un cas d'utilisation global détaillé par un diagramme processus / composition en sous-
d'activités, puis à nouveau la description des cas processus
d'utilisation de chaque sous-processus identifié, pour
Affinage itératif
lesquels il faut créer d'autres diagrammes d'activités, 1

etc. (fig. IV.54). Ainsi pour reprendre notre exemple,

Use case
le premier diagramme de cas d'utilisation (fig. IV.50) 1.1 1.2 1.3 ...
est détaillé en un diagramme d'activités
correspondant à celui de la figure ci-dessus. Chacun Diagrammes
1.1.1 1.1.2 ...
d’activités
des sous-processus qui y sont repérés est ensuite
analysé par un cas d'utilisation qui à son tour (fig.
IV.51), est affiné par un diagramme d'activité. Figure IV.54 - Démarche de
modélisation

Les diagrammes d'activités représentent la phase de transition vers le modèle définitif du

workflow, celui qui est donné par son diagramme de classes. Il peut paraître étrange de
modéliser un workflow à l'aide d'un diagramme statique. En fait, la dynamique du workflow
est représentée comme nous l'avons vu, par les diagrammes d'activités. Ces derniers sont
suffisants pour représenter l'ensemble des éléments qui entrent en jeu lors de la réalisation du
processus - ceux qui en composent les différentes vues. N'oublions pas toutefois que le but de
l'utilisation du framework est d'aboutir à un assemblage de composants qui doit produire des
workflows exécutables. Notre méthode doit donc fournir une démarche pour la modélisation

194
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

et la conception de workflows à l'aide des classes du framework, par conséquent, le résultat

final doit s'exprimer en termes de classes de composants et de relations entre ces classes.

5.2.3 Diagramme de classes

L'obtention d'un diagramme de classes en tant que finalité de la modélisation constitue la

troisième et dernière étape de notre méthode de modélisation. Les diagrammes de classes sont
obtenus par application des stéréotypes du framework. La transposition des concepts des
diagrammes d'activités en classes 2FLOW est donnée par le tableau suivant :

Formalismes des Classe ou fonction

diagrammes d'activités 2FLOW équivalente
Processus

Activité

[condition / événement] EvenementWorkflow

Objet Artefact

… ExpressionLogique

… BCF_P

BCF_Seq

BCF_Boucle

XXX Role

{ xxx } Initialisation ou affectation

Start

EndWorkflow

Tableau IV.1 - Correspondance entre formalismes des diagrammes d'activités

et composants 2FLOW

Jusqu'à présent, la conversion est à la charge des concepteurs. Nous espérons toutefois
pouvoir ajouter cette fonctionnalité à l'éditeur que nous avons développé, qui ne permet pour
le moment, que de créer des diagrammes de composants. L'utilisation de l'éditeur devrait
permettre de créer les trois types de diagrammes, en proposant des fonctions de translation de
l'un à l'autre, notamment entre les diagrammes d'activités et les diagrammes de composants
(classes 2FLOW) correspondants.

Avant de passer au diagramme de classe du processus d'hospitalisation que nous avons pris
pour exemple, il est intéressant de remarquer que les composants 2FLOW peuvent en fait
s'adapter à tous types de concepts, pour peu que des fonctions de transition soient définies. En
effet, les classes de base du framework correspondent dans leur ensemble à des concepts

195
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

classiques du Workflow. Par exemple, les concepts de la méthode ARIS pourraient être
utilisés pour la plupart pour construire un workflow à l'aide des composants de notre
framework. Une perspective intéressante de notre travail, sur laquelle nous reviendrons,
pourrait donc consister à enrichir l'éditeur de certains modules de "mapping", entre des
formalismes spécifiques à tel ou tel type de notation ou de méthode Workflow, et les
composants de 2FLOW. Les classes étant générées par la suite sur la base des fonctions de
transitions et d'un moteur commun de génération, celui qui est actuellement utilisé.

Les diagrammes ci-dessous correspondent aux diagrammes de classes du processus

d'hospitalisation que nous avons traité jusqu'à présent. Afin d'éviter la surcharge du modèle,
nous l'avons décomposé en plusieurs vues (les vues Workflows), ce qui explique la
redondance des classes.
Vue comportementale / Événements
<<Evénement>>
<<Activité>> NonConformite
ExamenDM <<Processus>> <<Evénement>>
<<Evénement>> <<Activité>> Remboursement FinDuWorkflow
NouveauDossier ExamenDossier

<<Activité>> <<Evénement>>
ExamenDM DossierAConforme

<<Evénement>> <<Evénement>>
Anomalie Incoherence
<<Activité>>
Concertation
<<Activité>>
ContacterHopital
<<Evénement>> <<Evénement>> <<Activité>>
DossierMConforme DeclarationOK MiseAjourDossier

Vue fonctionnelle <<Processus>>

RemboursementFrais

<<Processus>> <<Processus>> <<Processus>>

ValidationDM ValidationAdministrative Remboursement

<<Activité>> <<Activité>> <<Activité>> <<Activité>> <<Activité>>

ExamenDM Concertation ExamenDossier ContacterHopital MiseAjourDossier

Vue comportementale / Flux <<BCF_S>>

MainSeq

<<BCF_P>> <<BCF_S>> <<Processus>>

BCFP1 BCFS1 Remboursement

<<Activité>> <<Activité>> <<Activité>> <<Activité>> <<Activité>>

ExamenDM Concertation ExamenDossier ContacterHopital MiseAjourDossier

Vue Organisationnelle <<Activité>>

MiseAjourDossier
<<Activité>>
ExamenDM
<<Role>> <<Role>> <<Activité>>
SpecialisteMedical ExpertAssurances ContacterHopital
<<Activité>>
Concertation
<<Activité>>
<<Role>> ExamenDossier
AgentComptable

Figure IV.55 - Diagramme de classes du "processus d'hospitalisation"

196
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

6. D'autres architectures et systèmes Workflows adaptables -

comparaison avec 2FLOW.

Dans ce paragraphe, nous allons nous intéresser aux solutions d'adaptabilité (et plus
globalement de flexibilité) apportées par d'autres frameworks et d'autres systèmes Workflows,
et les comparer avec celles de 2FLOW. Etant donné le nombre important de systèmes et
d'architectures existants, nous ne décrivons ici qu'un nombre réduit de ceux qui, à notre avis,
traitent le mieux la question de la flexibilité des Workflows.

La description et la comparaison portent essentiellement sur les six principales

caractéristiques de 2FLOW, à savoir :

1. La réutilisation et l'adaptation de composants Workflows, hors exécution.

2. La réutilisation et l'adaptation des processus, hors exécution.
3. L'adaptation des composants en cours d'exécution.
4. L'adaptation des workflows en cours d'exécution.
5. La gestion des exceptions.
6. La prise en charge des acteurs humains et automatiques.
7. La prise en charge des artefacts.

6.1 Micro Workflow

Micro Workflow est un framework Workflow développé par D.A. Manolescu au cours de son
travail de thèse [MANOLESCU 00]. Ce framework est essentiellement adressé à des
informaticiens ayant de bonnes connaissances en programmation, souhaitant intégrer des
fonctionnalités Workflows au sein d'applications informatiques d'un autre type. Pour
l'anecdote, l'appellation "Micro" provient du fait que son concepteur dédie le framework à la
construction de workflows de petite envergure, utilisés en tant qu'utilitaires de gestion de
processus dans des systèmes plus importants.

Micro Workflow permet de construire des workflows objets du deuxième niveau - ou

workflows basés objets - (Voir la définition de C. Bussler dans le chapitre III). Cela signifie
que ses composants sont des classes d'objets qui utilisent les mécanismes des objets du
langage sous-jacent, sans les redéfinir au niveau du Workflow.

Micro Workflow adopte une approche par métamodèle, dans laquelle sont définis trois types
d'objets (métaclasses) situés à un niveau d'abstraction élevé - que Manolescu appelle
"knowledge level" :

1. Le premier de ces types est la classe "ProcedureType" - métaclasse d'une procédure. Elle
se décline en plusieurs sous types, respectivement :

§ "Sequence procedure", qui est une procédure dont le rôle est d'assurer la séquentialité
de l'exécution des procédures qui la composent.
§ "ConditionProcedure", qui sert à définir une condition dont la satisfaction permet de
poursuivre l'exécution vers l'une des procédures qui la composent.
§ "ItérativeProcedure", dont le rôle est d'exécuter itérativement ses procédures
composantes.

197
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ "ForkProcedure", qui permet de mettre en parallèle le flux d'exécution de ses

procédures composantes.
§ "JoinProcedure", qui sert à la synchronisation des procédures qui la composent
§ "PrimitiveProcedure", qui correspond à une "vraie" activité, contrairement aux
précédentes qui servent uniquement au contrôle de flux. Une procédure primitive n'est
exécutée qu'à condition de satisfaire la pré-condition qui lui est associée.

Micro Workflow conçoit la structure d'un processus comme un arbre de procédures, dont
la racine et les n œuds sont des procédures de contrôle de flux, et les feuilles des
procédures "primitives". Cette structuration ressemble à celle des Blocs de Contrôle de
Flux de 2FLOW. Nous pouvons toutefois reprocher à Micro Workflow de ne pas faire de
distinction entre activités et contrôle de flux en les réunissant sous un même type de base.
Or la sémantique des deux entités est différente, et celles-ci correspondent à deux points
de vue distincts que nous séparons dans 2FLOW : le point de vue "processus métier",
exprimé par la composition des processus en activités et sous processus, et le point de
vue "logique" qui exprime le contrôle de flux des activités. De plus, il nous semble erroné
de considérer qu'une activité est "un type" de contrôle de flux - comme le suppose la
relation d'héritage entre la classe procédure primitive et la classe procédure de Micro
Workflow. La non distinction de ces deux notions risque donc, à notre avis, d'être source
de confusion chez les concepteurs et les développeurs.

2. La deuxième métaclasse est nommée "ContextObject". Elle sert à référencer l'information

dont a besoin une procédure. Cette dernière en extrait des données (uniquement celles qui
y sont référencées) et peut les mettre à jour. Cela suppose donc que l'activité connaît une
partie de la structure et des services d'un ContextObject.

3. Enfin la troisième métaclasse est appelée "RessourceType", et correspond à un acteur

chargé de réaliser une procédure primitive. Les procédures primitives sont directement
liées à des ressources qui les réalisent, sans passer par l'intermédiaire d'un rôle. Cela
implique que les classes de procédures primitives doivent connaître les noms des
fonctions qu'elles peuvent invoquer chez la ressource. Il n'y a donc pas d'indépendance
entre les acteurs et les activités, ce qui limite la flexibilité des workflows. En effet, si lors
de l'exécution, il est nécessaire de remplacer une ressource par une nouvelle, il faut que
cette dernière propose exactement les mêmes noms de fonctions. Dans le cas contraire, il
faut modifier la définition de l'activité.

Lors de l'exécution, les métaclasses de Micro Workflow instancient des classes de niveau
inférieur (appelé "operational level") qui leur sont associées (respectivement "Procedure",
"Context" et "Ressource").

Après ce tour d'horizon de Micro Workflow, nous allons à présent nous intéresser aux six
points de comparaison que nous avons définis.

6.1.1 Réutilisation et adaptation des composants hors exécution

Bien que Micro Workflow ne propose pas de mécanismes objets Workflows, il est
parfaitement possible de réutiliser les composants qu'il définit, c'est d'ailleurs son principal
objectif en tant que framework. Manolescu prévoit deux modes de réutilisation et d'adaptation
hors exécution :

198
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ La réutilisation et l'adaptation par spécialisation des classes du framework, en utilisant

les mécanismes d'héritage du langage objet sous-jacent.

§ La réutilisation par composition des classes de Micro Workflow, pour la création de

nouveaux composants.

A ce niveau, ce framework est donc similaire à 2FLOW.

6.1.2 Réutilisation et adaptation des processus hors exécution

Contrairement à 2FLOW, Micro Workflow ne propose par de spécialisation Workflow des

processus (procédures). La spécialisation des processus est donc entièrement à la charge des
développeurs - ils doivent spécialiser et recopier l'ensemble des classes concernées - et fait
appel aux mécanismes de spécialisation du langage objet sous-jacent.

6.1.3 Adaptation des composants en cours d'exécution

Initialement, Micro Workflow ne proposait pas de moyens d'adapter les composants d'un
workflow en cours d'exécution [MANOLESCU 00]. Il semble cependant qu'une mise à jour
récente du framework prenne en compte cet aspect [MANOLESCU et al. 00]. Pour ce faire,
les concepteurs du framework ont implémenté un éditeur visuel (un "Visual Builder"), qui
permet à l'utilisateur du framework de visualiser les propriétés d'une classe (uniquement les
attributs), de lui en ajouter de nouvelles ou d'en retirer. Chaque propriété peut correspondre à
une classe du framework, ou être définie par l'utilisateur.

L'éditeur visuel de Micro Workflow est similaire au contrôleur générique de 2FLOW (décrit
au paragraphe 4.2.1). Il permet d'observer les attributs des classes et de les modifier grâce à
des mécanismes d'introspection. A l'instar du contrôleur de 2FLOW (§4.2.1), les
modifications sont possibles sans nécessiter des connaissances en programmation. Toutefois,
l'éditeur visuel est limité à la modification des attributs d'une classe et ne peut pas en modifier
le comportement (ajouter, modifier ou supprimer des méthodes), ce qui est possible avec
l'éditeur de composants de 2FLOW.

6.1.4 Adaptation des processus en cours d'exécution

Micro Workflow propose des solutions intéressantes au problème de l'adaptation des

processus en cours d'exécution. En effet, nous avons mentionné que ce framework adoptait
une vue arborescente d'un processus. Celle-ci peut être visualisée à l'aide d'un outil
implémenté par les concepteurs du framework, qui propose deux fonctionnalités principales :

§ Revenir sur une procédure ayant déjà été exécutée. Cette fonctionnalité est très utile
lors de l'échec d'une procédure. En effet, en revenant sur une procédure, il est possible
de l'exécuter une seconde fois, ou de la remplacer par un nouveau sous-arbre.

§ La deuxième fonctionnalité est la possibilité d'annuler l'exécution du processus.

Dans la nouvelle version, les concepteurs affirment qu'il est également possible d'ajouter ou
de supprimer des procédures au sein d'un processus à l'aide de l'éditeur visuel, puisque ce
dernier permet de manipuler les attributs d'une classe, en particulier ceux d'une procédure. La

199
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

nouvelle version permettrait également de propager les adaptations sur deux niveaux (local et
global).

6.1.5 Prise en charge des acteurs automatiques et humains

Micro Workflow peut prendre en charge les acteurs automatiques – à l'aide de la classe
Ressource – et les acteurs humains, par l'intermédiaire d'une liste de tâche qui leur est
associée. Toutefois, étant donné que ce framework n'utilise pas la notion de rôle, il n'y a pas
d'indépendance entre une procédure et la ressource qui la réalise, comme nous l'avons
mentionné au début du paragraphe 6.1.

6.1.6 Gestion des exceptions

Le framework Micro Workflow ne prend pas en compte les exceptions et ne propose pas de
moyens pour les représenter ou les traiter explicitement. Il incombe aux utilisateurs d'ajouter
au framework une nouvelle classe de ce type, ou de détourner l'usage des pré-conditions
utilisées pour l'exécution des activités, pour gérer des exceptions.

6.1.7 Prise en charge des Artefacts

Micro Workflow représente les artefacts manipulés par les procédures sous la forme de
"Context Object". Chaque objet de ce type est en fait un agrégat de données, qu'une procédure
peut manipuler au travers de l'interface de l'objet contextuel. Les artefacts restent sous la
forme de données informatiques, comme c'est le cas pour les autres systèmes et architectures
Workflows.

6.1.8 Conclusion sur Micro Workflow

Micro Workflow est un framework qui présente des concepts et des fonctionnalités
intéressantes. Il est essentiellement destiné à un usage au niveau middleware, par des
informaticiens. Bien qu'il propose des moyens d'adapter et de réutiliser les composants des
workflows, ceux-ci restent quelque peu limités dans la version actuelle du framework,
notamment pour les adaptations dynamiques. Il semblerait toutefois que des améliorations
soient en cours de réalisation dans la nouvelle version, particulièrement dans la mise en œuvre
de mécanismes réflexifs pour l'adaptation des workflows. Micro Workflow souffre de plus de
certains défauts que nous avons soulignés, comme le fait de ne pas établir de distinction entre
contrôle de flux et activité, ou de ne pas introduire d'indépendance entre acteurs et activité.
Enfin, ce framework ne prend en charge que les types d'artefacts électroniques.

Micro Workflow présente toutefois une approche très efficace de la gestion des processus que
nous qualifions "d'externes" (appelé "federated procedures" dans Micro Workflow),
notamment grâce à l'utilisation de CORBA. Nous n'avons pas discuté de cet aspect du
framework mais plus de détails à ce sujet peuvent être trouvés dans [MANOLESCU 00].

200
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

6.2 Endeavors
Endeavors [BOLCER 98], [HITOMI et al. 99], [JOHNSON 99] est un système Workflow
orienté objet issu de la recherche, récemment commercialisé (hhtp://[Link],
[Link] Il est défini par ces concepteurs comme étant un système de
gestion de processus ouvert et extensible. Endeavors est construit sur la base d'un autre
système Workflow nommé Teamware [YOUNG 94], [TEAMWARE 99], développé au sein
du même laboratoire et également commercialisé, dans une filiale du groupe Fujitsu
([Link]

Endeavors se base sur l'architecture objet de son prédécesseur dont il hérite de l'ensemble des
fonctionnalités classiques des systèmes Workflow. Endeavors en propose également de
nouvelles, permettant l'adaptation des processus ainsi que l'adaptation et la réutilisation de
leurs composants, hors et en cours d'exécution,. En particulier, il met en œuvre des
mécanismes de réflexivité dont certains sont proches de ceux proposés par 2FLOW.

Endeavors distingue cinq classes fondamentales, appelées "categories", elles-mêmes issues

d'une classe unique nommée "MetaClass". Nous les décrivons succinctement ci-dessous :

§ La classe "Activity" : elle sert à définir les activités d'un processus. Une activité est
réalisée par des agents automatiques ou des utilisateurs humains. Elle utilise des
"ressources" et consomme et produit des "artefacts". A l'instar de Micro Workflow,
certaines activités servent à définir le flux de contrôle du processus (début, fin,
branchement, mise en parallèle, synchronisation).

§ La classe "Artefact" concerne l'ensemble des objets - documents électroniques ou

programmes - pouvant être consommés ou produits par des activités.

§ La classe "Ressource" représente, selon les concepteurs du système, un type de

ressource parmi celles utilisées en gestion de projet, telles le personnel, les salles de
réunions, les budgets, etc. Une ressource est similaire à un artefact, sauf que son
existence n'est pas liée à celle du processus. Remarquons ici que les ressources et les
artefacts d'Endeavors ne font pas référence à des processus permettant de manipuler les
objets réels, comme c'est la cas avec 2FLOW.

§ La classe "Networks" permet de regrouper logiquement un ensemble d'activités. Plus

précisément, quand un réseau est associé à une activité, elle devient un sous-processus
car sa réalisation est liée à celle du groupe d'activités du réseau.

§ La classe "Arc" permet de définir des dépendances entre catégories. En d'autres termes,
il décrit les flux de contrôle, de données et de ressources, existants entre deux
catégories.

§ Enfin la classe "MetaClasse" est comme nous l'avons mentionné, la classe mère de
toutes les classes d'Endeavors. Elle sert d'interface pour la manipulation des classes
catégories, grâce à des mécanismes réflexifs.

201
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

6.2.1 Réutilisation et adaptation des composants hors exécution

De par leur nature objet, les composants d'Endeavors sont réutilisables. La réutilisation se fait
en créant de nouvelles classes à partir des catégories existantes. Les classes obtenues sont soit
de nouvelles catégories, soit des "spécifications" qui servent à construire les workflows des
utilisateurs. L'exécution des workflows aboutit à la création "d'instances" des spécifications.
La réutilisation et l'adaptation se font via l'outil principal d'Endeavors, qui est son panneau de
contrôle. Ce dernier permet d'accéder de façon réflexive à l'ensemble des workflows (appelés
projets) et aux instances de leurs classes, s'ils sont en cours d'exécution. Les accès se font via
un ensemble de fenêtres ("artists") permettant respectivement de décrire les catégories, les
spécifications, les attributs et les instances. Par comparaison avec 2FLOW, le panneau de
contrôle d'Endeavors correspond simultanément à une partie de l'éditeur et au contrôleur
générique de notre framework.

6.2.2 Réutilisation et adaptation des processus hors exécution

La version d'Endeavors que nous avons testée, ainsi que les documents que nous avons lus sur
ce système ne mentionnent pas la présence de mécanismes objets Workflows pour la
spécialisation de processus. Le seul moyen de spécialiser un processus est d'en faire une
copie, puis d'en modifier son contenu à l'aide du panneau de contrôle.

6.2.3 Adaptation des composants en cours d'exécution

Le panneau de contrôle d'Endeavors permet, via la fenêtre d'instance, d'accéder en cours

d'exécution aux instances des classes du workflow et d'y apporter des modifications. Par
ailleurs, Endeavors rend possible l'attribution et la modification dynamique de comportements
("messages") aux objets des workflows. L'approche adoptée est simple mais intéressante.
Chaque message est l'équivalent d'un fichier de code (en Java, ADA, Tcl ou Python), dont on
indique l'URL. Les fichiers sont chargés dans le système puis compilés lors de l'exécution. Ce
mécanisme est appelé "liaison dynamique" par les concepteurs d'Endeavors. Il permet de
modifier dynamiquement le comportement d'un objet (appartenant à une catégorie) grâce à la
modification de la référence du fichier contenant son code.

Afin d'invoquer un comportement - y compris ceux qui permettent au workflow de s'exécuter,

il est nécessaire de construire un gestionnaire ("handler") approprié. Celui-ci doit être associé
à toutes les classes ayant recours au comportement. Sa conception est à la charge des
développeurs Workflows, qui peuvent se baser sur le modèle de gestionnaire définit par le
système. Remarquons qu'à l'opposé, dans 2FLOW, l'exécution des processus est un
mécanisme interne des composants dont n'ont pas à se soucier les développeurs. De plus,
chaque gestionnaire d'Endeavors doit avoir le même nom que le comportement qu'il invoque,
ce qui entraîne une dépendance entre l'appelant et la classe produisant le comportement.
Enfin, il n'est pas possible d'ajouter des gestionnaires en cours d'exécution.

6.2.4 Adaptation des processus en cours d'exécution

Dans Endeavors, il est possible de supprimer et d'ajouter de nouveaux éléments au modèle

d'un workflow en cours d'exécution. La cohérence du modèle n'est pas validée après
modification et seule les classes n'ayant pas encore été exécutées sont concernées par les
changements. Par ailleurs, Endeavors ne distingue pas de niveaux d'adaptations (local, global,
etc.), celles-ci ne concernant que le workflow concerné, au niveau de son instance et de sa

202
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

définition. Ceci est un défaut important du système car une modification sur la définition
implique que toutes les futures instances seront créées à partir de la nouvelle définition, ce qui
n'est pas nécessairement le résultat souhaité. Dans 2FLOW, la distinction entre plusieurs
niveaux d'adaptation permet une gestion plus pointue des adaptations.

6.2.5 Gestion des exceptions

Les spécifications d'Endeavors ne mentionnent pas explicitement les exceptions. Néanmoins,

toute classe a la possibilité d'émettre un signal, qui est associé à un message. Par conséquent,
il est quand même possible de construire des gestionnaires d'exceptions.

6.2.6 Gestion des acteurs humains et automatiques

La classe activité contient deux attributs, l'un nommé "assignedTo" qui permet d'affecter
l'activité à une personne, et l'autre "automate", qui la transmet à un acteur automatique. Cette
approche demande donc au concepteur du workflow de savoir à l'avance quel acteur est
chargé de réaliser l'activité, ce qui réduit son intérêt. En effet, s'il est nécessaire de faire la
distinction entre activités "humaines" et activités automatiques, il n'est plus possible de
remplacer un acteur humain pas un acteur automatique lors de l'exécution, et réciproquement.

6.2.7 Prise en charge des artefacts

Comme nous l'avons indiqué précédemment, les artefacts manipulés par les activités
d'Endeavors sont des documents électroniques. Il n'est donc pas possible, comme le propose
2FLOW, de gérer des objets physiques. Néanmoins, Endeavors propose un ensemble
intéressant de méthodes pour la catégorie "artefact", allant de la commande d'ouverture du
fichier à l'invocation des outils permettant sa visualisation. Endeavors permet également -
atout très intéressant - de gérer le versionnage des documents et de les partager entre plusieurs
activités.

6.2.8 Conclusion sur Endeavors

Endeavors est un système intéressant, certainement l'un de ceux qui prennent le mieux en
compte la question d'adaptabilité des workflows. Parmi ses principaux intérêts, nous citerons
la réflexivité du modèle sous-jacent, et la liaison dynamique des comportements dont nous
nous sommes inspirés pour l'invocation des services des acteurs automatiques 2FLOW. Notre
framework propose toutefois des solutions mieux adaptées à certains problèmes que rencontre
Endeavors, tels la gestion des exceptions, l'indépendance entre activités et acteurs, la gestion
des artefacts généralisée à tous types d'objets et la spécialisation Workflow des processus, qui
n'est pas possible avec Endeavors.

Enfin, il est important de signaler qu'Endeavors s'est orienté vers la gestion de workflows via
le Web afin de supporter les utilisateurs déconnectés, l'un des autres axes importants de la
recherche Workflow.

203
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

6.3 TriGSflow
TriGSflow est un système Workflow hybride, dont le métamodèle est composé de classes
d'objets, mais dont une partie importante des mécanismes est directement basée sur ceux des
bases de données [KAPPEL et al. 95], [KAPPEL et al. 98]. TriGSflow est issu de la recherche
et est aujourd'hui commercialisé sous le nom de "Verve" ([Link] en tant que
moteur Workflow intégrable à d'autres applications, notamment de e-commerce.

Le métamodèle objet de TriGSflow définit des classes de bases ("BusinessProcess",

"Activity", "Agent", "Folder") que les utilisateurs peuvent spécialiser pour créer leurs propres
classes. Le métamodèle définit aussi des classes d'arrière plan, qui gèrent le comportement du
système et qui ne sont pas spécialisables. Nous décrivons brièvement les quatre classes de
base dans ce qui suit.

§ La classe "BusinessProcess" représente le processus à exécuter. Elle est composée

d'une activité de départ, une activité de fin, un agent chargé de l'initialisation et des
dossiers (folders).

§ La classe "Activity" correspond à une activité d'un workflow. Lors de la modélisation,

elle est associée à un ensemble d'agents (appelé "relevant agents"), dont le nombre
peut être réduit lors de l'exécution, aux agents effectivement disponibles pour réaliser
l'activité ("actuals agents").

§ Un "Agent" est un acteur qui exécute les activités du Workflow. TriGSflow en

distingue deux types : les agents humains ("HumanAgent") et les agents automatiques
("Auto agents"). Cette dernière classe se divise en deux sous-types : les applications
internes au Workflow ("InternalAppObject") et les applications qui lui sont externes
("ExternalApp").

Dans le cas des agents humains, une activité est concrétisée par l'envoi d'un message
vers la worklist de la personne sélectionnée. Ce message peut être associé à un
ensemble de données (ou de documents électroniques), référencés dans l'activité en
question. Les valeurs de ces références sont stockées dans la base de données sur
laquelle est implémenté le système TriGSflow.

Dans le cas des agents automatiques, un objet de la classe "InternalAppObject"

correspond à l'un des objets d'une application utilitaire du système Workflow
(messagerie, éditeur, gestionnaire de l'historique, etc.). En général, un objet d'une
d'application interne propose un ensemble de méthodes associées à des activités du
processus dont elle porte le nom. Ce sont ces dernières qui se chargent d'invoquer les
méthodes lors de l'exécution des workflows.

Les objets de la classe "ExternalApp" correspondent à des applications externes que le

système Workflow peut solliciter. Pour ce faire, la classe "ExternalApp" dispose d'un
attribut spécifique, qui contient la commande permettant de lancer l'application.

Remarquons que les agents automatiques disposent également d'une worklist dont le
rôle est de gèrer la file d'attente des messages envoyés aux applications.

204
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ Enfin, une classe "Folder" est associée à une activité en cours. Elle fait référence à la
worklist de l'acteur et aux données de l'activité.

Contrairement aux deux architectures que nous avons présentées auparavant, le système
TriGSflow n'est pas entièrement orienté objet, mais, nous l'avons dit, adopte une approche
hybride. En effet, la modélisation de workflows dans TriGSflow se fait à l'aide d'éléments se
rapportant aux composants du métamodèle (processus métier, activités, agents, dossier) ainsi
qu'avec des éléments de l'ensemble des classes d'arrière plan (contrôleurs de flux
essentiellement). Les modèles sont ensuite traduits sous la forme de règles ECA qui décrivent
entièrement le workflow.

Trois types de règles sont disponibles : les règles contrôlant le flux des activités (générés à
partir des contrôleurs de flux), les règles gérant la sélection des agents et leur affectation aux
activités et enfin, les règles gérant les files d'attentes des worklists. Les règles sont associées
aux activités du workflows. Elles sont générées par le Système de Gestion de Base de
Données (SGDB) utilisé par TriGSflow, qui, de plus, est chargé de gérer leur exécution.
TriGSflow présente donc une architecture monolithique car il n'est pas possible de le dissocier
du SGBD sous-jacent.

6.3.1 Réutilisation et adaptation des composants hors exécution

TriGSflow permet la réutilisation des classes définies par les utilisateurs. Dans le cas
particulier des classes d'activités, les règles ECA sont héritées telles quelles car il n'est pas
possible de les spécialiser. Par contre, les utilisateurs peuvent surcharger les règles d'une
activité, c'est à dire les remplacer par d'autres règles.

La réutilisation des règles - en particulier celles de contrôle de flux - nous semble toutefois
dangereuse car celles-ci sont normalement générées d'après le modèle workflow. Il risque
donc d'y avoir des problèmes d'incohérence dans les nouveaux workflows, entre les règles
héritées et celles générées pour les autres classes.

6.3.2 Réutilisation et adaptation des processus hors exécution

Il n'est pas possible de spécialiser des processus directement dans TriGSflow (donc de
spécialiser la classe "BusinessProcess"). A l'instar des deux autres architectures que nous
avons présentées, TriGSflow ne met pas en œuvre de mécanismes objets Workflows. Par
ailleurs, comme nous l'avons mentionné ci-dessus, il ne nous semble pas recommandé de
réutiliser les règles ECA décrivant la dynamique d'un processus.

6.3.3 Adaptation des composants en cours d'exécution

Il n'est pas possible d'adapter les instances des classes de TriGSflow en cours d'exécution. En
particulier, on ne peut pas modifier les comportements des acteurs lors de la réalisation du
processus, ce qui est regrettable. Par contre, il est tout à fait possible de remplacer les règles
ECA associées aux activités par d'autres règles, ou de modifier les données utilisées par les
activités (puisqu'elles n'utilisent que leur référence, qui est gérée par le SGBD sous-jacent).

205
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

6.3.4 Adaptation des processus en cours d'exécution

L'adaptation du flux des processus en cours d'exécution est réalisable grâce à la possibilité de
remplacer les règles ECA par d'autres règles. La suppression et l'insertion d'activités est
également possible, mais uniquement par des artifices de programmation par lesquels le flux
des activités est dévié pour prendre en compte les nouvelles activités, ou au contraire, pour les
ignorer.

6.3.5 Prise en charge des exceptions

Etant donné que la notion de règle ECA est omniprésente dans TriGSflow et que celles-ci sont
l'un des mécanismes de référence de la gestion des exceptions (voir chapitre III), TriGSflow
peut gérer efficacement le problème des exceptions.

6.3.6 Prise en charge des acteurs automatiques

Comme nous l'avons vu au début du paragraphe 6.3, le métamodèle de TriGSflow intègre la

notion d'acteur automatique. Par ailleurs, contrairement aux architectures précédentes et à
l'instar de 2FLOW, TriGSflow sépare la définition des activités de leur réalisation (qui est
encapsulée dans la classe Agent). Il y a donc une indépendance entre ce qui doit être fait par
une activité et par quelle entité l'activité est réalisée.

6.3.7 Prise en charge des artefacts

Les seuls artefacts gérés par TriGSflow sont les types assimilables par le SGBD sous-jacent
(donc essentiellement des données, des "tables" et des documents électroniques).

6.3.8 Conclusion sur TriGSflow

TriGSflow se démarque des autres systèmes et architectures par son approche orientée objet -
base de données. Ses concepteurs parlent d'ailleurs parfois de système de base de données
objet actif [KAPPEL et al. 98] pour la gestion de Workflow. TriGSflow tire profit avec succès
des fonctionnalités apportées par les SGBD actifs, et fait incontestablement partie du clan des
systèmes Workflow issus des bases de données. Bien que la réutilisation des composants soit
partiellement possible, et bien que la gestion et l'adaptation des flux et des données ne soit pas
un problème pour ce système, il n'en est pas de même pour les propriétés des composants et
leur comportement, en cours d'exécution.s. Ces carences font que TriGSflow ne permet pas
vraiment une adaptation complète des processus.

6.4 Autres systèmes Workflows

D'autres systèmes Workflows, commercialisés pour la plupart, affirment permettre de créer
des workflows adaptables et flexibles. Il est très difficile de se faire une idée précise de la
réalité de ces affirmations et des techniques utilisées par ces systèmes, et ce pour deux
raisons:

§ Le manque de documentation technique détaillée sur ces systèmes, qui se limite le plus
souvent à un texte superficiel de quelques pages, mettant surtout en avant la présence
dans le produit de technologies "à la mode" (Java, XML, CORBA, EJB, etc.)

206
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ L'impossibilité matérielle de tester l'ensemble des produits, pour des raisons évidentes
de coût et de temps

Nous avons néanmoins pu nous pencher sur certains de ces produits, parmi lesquels nous en
citons deux qui proposent des solutions intéressantes :

1. "InConcert", de la société du même nom, anciennement filiale du groupe Xerox,

aujourd'hui rachetée par TIBCO softwares. InConcert [INCONCERT 97] est un système
Workflow orienté processus, basé sur une architecture objet - client/serveur. Il permet
d'adapter dynamiquement le flux des processus (ajouter/supprimer des activités, rediriger
un flux) et permet aux utilisateurs de définir de nouvelles classes en spécialisant les
classes de base du système, ou leurs propres classes. Il s'agit toutefois de "pseudo
création" de classes, puisque les utilisateurs ne peuvent pas y définir de nouveaux
comportements, ni même surcharger les comportements dont leurs classes héritent. Par
ailleurs, les acteurs d'InConcert sont essentiellement humains, les acteurs automatiques
étant limités à un petit nombre d'applications informatiques (traitement de texte, tableur,
SGBD, messagerie électronique), invoquées par des activités spécifiques. L'intégration
d'acteurs automatiques peut toutefois être améliorée grâce à l'utilisation de l'API du
système qui permet de développer de petites applications clientes en C, C++ ou Java. Ces
fonctions sont cependant essentiellement orientées vers l'intégration de InConcert dans
une suite logicielle plus globale.

2. Ultimus, de la société du même nom également ([Link] est un système

Workflow orienté processus, basé lui aussi sur une architecture objet/client-serveur.
Ultimus [ULTIMUS 99] ne permet toutefois pas d'adaptation dynamique des Workflows,
ni de création ou de spécialisation de classes. L'intérêt de ce système provient de sa
technologie de "Flobots", qui permet aux utilisateurs de créer facilement des acteurs
automatiques, grâce à un éditeur spécifique qui lie les activités du workflow à de vrai
acteurs automatiques (applications informatiques ou machines - ce qui dans ce cas,
nécessite un peu de programmation à l'aide des fonctions de l'API). Malheureusement,
Ultimus requiert de faire une distinction au niveau du processus, entre les activités
"humaines" et celles qui sont confiées à des flobots.

7. Conclusion
Dans ce chapitre, nous avons présenté le framework 2FLOW, qui propose des solutions pour
la construction de workflows flexibles, ainsi qu'une méthode pour la conception de workflow
à l'aide des composants du framework. 2FLOW est basé sur un métamodèle objet et met en
œuvre des mécanismes objets Workflows qui, combinés avec des mécanismes réflexifs,
permettent d'adapter les workflows hors et en cours d'exécution.

Par rapport aux autres systèmes et architectures Workflows proposant également la mise en
œuvre de la flexibilité, 2FLOW se distingue par les caractéristiques suivantes :

§ La mise en œuvre des mécanismes Workflows Objets (spécialisation)

§ L'introduction d'une indépendance entre les acteurs et les activités grâce à une
approche innovante du concept de rôle.
§ La gestion de tous types d'artefacts dans les workflows.

207
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

§ Les adaptations hors et en cours d'exécution des processus et des composants

§ La possibilité de distinguer entre trois niveaux d'adaptations : local à l'instance en
cours, local généralisé, qui affecte l'ensemble des instances, et global qui se répercute
en plus sur la définition du workflow.

En contrepartie, 2FLOW souffre d'un manque de maturité par rapport aux systèmes existants,
notamment en ce qui concerne les aspects de gestion de processus "externes", de sécurité et de
fiabilité des transactions. Ces aspects ouvrent plusieurs perspectives de recherche, sur
lesquelles nous reviendrons dans la conclusion de ce mémoire.

Bibliographie
[BARESI et al. 99] L. Baresi, F. Casati, S. Castano, S. Ceri, M.G. Fugini, I. Mirbel, B. Pernici.,
G. Pozzi. "WIDE Workflow Development Methodology". Report n°3027-6.
ESPRIT Project 20280. 3 Mars 1999.
[BOLCER et al. 96] G.A. Bolcer, R.N. Taylor. "Endeavors : A Process System Integration
Infrastructure". International Conference on Software Process (ICSP4).
Brighton, U.K.2-6 Décembre 1996.
[BOLCER 98] G. A. Bolcer. " Flexible and Customizable Workflow Execution on the
WWW". Mémoire de Thèse pour l'obtention du titre de "Doctor of
Philosophy in Information and Computer Science". University of California,
Irvine, USA. 1998.
[CAMPIONE et al. 97] M. Campione, K. Walrath. "The Java Tutorial". 1st Edition. Addison-
Wesley. 1997.
[DEMEYER 97] S. Demeyer. "Design Guidelines for 'Tailorable frameworks' ".
Communication of the ACM, Vol. 40, n°10. Octobre 1997.
[ECKEL 97] B. Eckel. "Thinking in Java". 1st Edition. Prentice-Hall. 1997.
[FOWLER et al. 97] M. Fowler, K. Scott. "UML Distilled. Applying the Standard Object
Modeling Language". Addison-Wesley. 1997.
[HITOMI 98] A. S. Hitomi, D. Le. "Endeavors and Component Reuse in Web-Driven
Process Workflow". Proc. of the California Software Symposium.. Octobre
1998.
[HRUBY 98] P. HRUBY. "Specification of Workflow Management Systems with UML".
OOPSLA 98, Workshop on Object Oriented WMS. 1998.
[INCONCERT 97] InConcert. "InConcert Specifications Document".
[Link] 1997.
[JOERIS et al. 98] G. Joeris, O. Herzog. "Towards Object-Oriented Modeling and Enacting of
Processes". TZI Technical Report 7/98, Center for Computing Technologies,
University of Bremen. 1998.
[JOHNSON 99] K. Johnson. "Endeavors".
[Link]
[KAPPEL et al. 95] G. Kappel, B. Pröll, S. Rausch-Schott, W. Retschitzegger. "TriGSflow,
Active Object-Oriented Workflow Management". Proc. of the 28th Hawaii
International Conference on System Sciences (HICSS'98). Janvier 1995. pp.
727-736.
[KAPPEL et al. 98] G. Kappel, S. Rauscht-Schott, W. Retschitzegger. "A Tour on the TriGS
Active Databse System - Architecture and Implementation". Proc. of the
ACM Symposium on Applied Computing (SAC'98). 27 Février - 1 Mars,
1998. pp. 211-219.
[KRUCHTEN 99] P. Kruchten. "The Rational Unified Process". Addison-Wesley. 1998.
[MANHES 98] S. Manhes. "Les patterns métier : extraction dans l'existant logiciel".
Rapport de DEA, Institut de Recherche en Informatique de Nantes.
Septembre 1998.

208
 Chapitre IV : 2FLOW - Framework pour Workflows Objets Flexibles

[MANOLESCU 00] D. Manolescu. "Micro Workflow. A Workflow Architecture Supporting

Compositional Object-Oriented Software Development". Mémoire de Thèse
pour l'obtention du diplôme de " Doctor of Philosophy in Computer
Science", Graduate College of the University of Illinois at Urbana-
Champaign, USA. Octobre 2000.
[MANOLESCU et al. 00] D. Manolescu, R. Johnson. "A Micro-Workflow Component for Federated
Workflow". OOPSLA2000, Workshop on Implementation and Application
of Object-Oriented Workflow Management Systems III,. Minneapolis,
Minnesota, USA. Octobre 2000.
[MULLER 98] P.A. Muller. "Modélisation Objet avec UML". Eyrolles 98.
[ROQUES et al. 98] P. Roques, F. Vallée. "UML en action, de l’analyse des besoins à la
conception en Java". Eyrolles. 2000.
[TEAMWARE 99] Teamware. "Application Developer's Guide". Fujitsu Corp. 1999.
[ULTIMUS 99] ULTIMUS. 3Utlimus Workflow product guide". [Link]
1999.
[WIDE 97] WIDE. "The WIDE Workflow model and Language". Report n°4080-2.
ESPRIT Project 20280. 31 Octobre 1997.
[YOUNG 94] P.S.C. Young. "Customizable Process Specification and Enactment
for Technical and Non-Technical Users" Mémoire de Thèse pour l'obtention
du diplôme de "Doctor Of Philosophy in Information and Computer
Science", University of California, Irvine, USA. 1994.
[ZUR MULLEN 99] M. zur Mühlen. "Evaluation of Workflow Management Systems Using
Meta Models". Proceedings of the 32nd Hawaii International Conference on
System Sciences (HICSS 1999), Wailea Los Alamitos (HI), 5-8 Janvier,
1999.

209
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Chapitre V
Application de 2FLOW – Le projet RESTER PROPRE

1. Application de 2FLOW
Nous allons dans ce chapitre décrire un exemple d'application du framework 2FLOW et de
ses propriétés, par la construction de workflows par assemblage de composants et la mise en
œuvre de leurs mécanismes d'adaptabilité. Nous nous intéressons à la gestion d'un processus
de recyclage "noble", réalisé sur une plate-forme générique de revalorisation de produits
manufacturés usagés, que nous décrivons dans les paragraphes suivants.

1.1 Le projet RESTER PROPRE

Le recyclage des produits manufacturés en fin de vie est une préoccupation écologique et
économique majeure dans la plupart des pays industrialisés. Pour parer à ce problème et
réduire la consommation de ressources naturelles et le volume des déchets, il est nécessaire de
mettre en œuvre des méthodes efficaces de recyclage des produits en fin de vie. Ces méthodes
passent par la récupération classique de matières premières (le recyclage "brut"), mais
également par la récupération et la réutilisation de composants des produits usagés : le
recyclage "noble".

L’approche de récupération "classique" de

recyclage des produits en fin de vie consiste
à en récupérer des matières premières dont
une partie est revalorisée en énergie. Bien
qu’étant largement répandue et utilisée, cette
méthode reste souvent limitée en efficacité.
Pour optimiser la récupération, une solution
plus "intelligente" est d'intégrer un nouveau
circuit dans le cycle de vie des produits. En
d'autres termes, il s'agit de faire précéder le
recyclage brut par une autre étape, qu’on
appelle le recyclage "noble". Cette approche
consiste à récupérer les composants et les
pièces valides d'un produit en fin de vie et Figure V.1 – Introduire un nouveau circuit
constitue la première étape vers un recyclage dans le cycle de vide des produits usagés
efficace et intelligent. Le but du recyclage grâce au recyclage "noble"
noble est donc de réinjecter les produits
usagés dans un nouveau cycle de vie, après un reconditionnement qui propose de réutiliser
les pièces extraites pour la réparation, voire la fabrication, d'autres appareils [DAVID et al.
99a].

210
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Le projet "RESTER PROPRE" (REcherches Socio-TEchniques pour le Recyclage de

PROduits manufactures Par Revalorisation) s'est attaché à la recherche de solutions, autant
méthodologiques que systémiques, au problème du recyclage noble. Ce projet, financé par la
région Rhône-Alpes a impliqué trois laboratoires aux compétences complémentaires
(informatique - ICTT, automatique - LAG/INPG et ergonomie du travail - ERIHST/UPMF).
Globalement, les objectifs principaux du projet ont été dirigés suivants plusieurs axes :

§ L'étude du contexte informationnel du système de désassemblage en identifiant les

informations nécessaires pour le démontage, telles que la modélisation et la mise en place
d'un Système de Gestion de Données Techniques.
§ La conception, l'organisation, la gestion et la conduite de ce système de recyclage face à la
variété des objets et des ressources humaines.
§ L'étude des méthodes de production de séquences de démontage optimisées pour les
différents types de produits, l'optimisation se faisant en fonction des contraintes
économiques et écologiques.
§ L'étude, la conception et la mise en œuvre d'un système coopératif Hommes - machines,
prenant en considération les compétences des individus lors de l’exploitation et la
supervision d'une cellule et d'un atelier de démontage.
§ L’analyse et l’étude de l’aménagement des postes de travail et l’organisation d'un atelier
de démontage en tenant compte de critères ergonomiques, économiques et techniques.

La concrétisation des travaux effectués dans le Matières Pièces Matières

brutes détachées brutes
cadre du projet "RESTER PROPRE" a secondaires secondaires secondaires
convergé vers la conception d’une plate-forme
semi automatique de référence, appelée REX
Désassemblage Stock Réparation
(récupération – réparation - recyclage)
(fig.V.2). En effet, pour pouvoir faire face aux info info

contraintes de recyclage de plus en plus

pièce pièce
importantes, il faut étudier la manière de passer s s
à un mode du recyclage efficace de plus grande
envergure, avec notamment un certain niveau
Diagnostic
d'automatisation. Afin de permettre cette
non réparable réparable
évolution, nous avons étudié la solution de la
plate-forme REX, qui a pour but de traiter des
appareils électroménagers en fin de vie selon Collecte Collecte Collecte
un processus bien déterminé, que nous
décrivons ci-après. Figure V.2 – La plate-forme REX

1.1.1 La plate-forme REX et le processus de recyclage noble

La plate-forme REX est globalement composée de cinq principaux "modules" : le module

responsable de la collecte des produits usagés, le module qui établit le diagnostic sur les
produits récoltés, les ateliers : l'un pour le désassemblage, l'autre pour la réparation et enfin un
module de stockage des éléments récupérés ou des appareils réparés. La structure de cette
plate-forme peut être "virtuelle", c'est à dire que les modules peuvent ne pas tous être
rassemblés dans un même lieu physique. Chaque passage des produits par l'un de ces modules
constitue une étape principale du processus de recyclage, dont nous décrivons les grandes
lignes dans ce qui suit.

211
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Le processus commence par la collecte des appareils en fin de vie. Les appareils sont
récupérés à la demande (de particuliers, de collectivités ou d’entreprises) et la collecte est
exécutée en fonction d'un plan établi par une unité logistique. Les appareils récupérés sont
ensuite soumis à une phase de diagnostic chargée d'évaluer leur état (pièces et composants).
Si l'appareil est jugé réparable il est acheminé vers l'atelier de réparation. Dans le cas
contraire, s’il est possible d’en récupérer des composants, une liste des éléments récupérables
est dressée et l'appareil est dirigé vers le démontage. Enfin, si l'appareil est jugé irrécupérable
ou si trop peu de pièces sont en état de marche, il est envoyé vers le recyclage "brut" (pour
l’extraction de matières).

La phase de diagnostic fait activement usage du système d'information de la plate-forme : un

Système de Gestion de Données Techniques (SGDT). D'une part elle en récupère les
descriptions des appareils à évaluer ainsi que les fonctionnalités à tester (modèles structurel
et fonctionnel), d'autre part elle enrichit le modèle du produit en renvoyant un ensemble
d'informations telles que les types de pannes rencontrées, leur fréquence, etc.. Le diagnostic
permet également d’établir des listes standards de pièces à récupérer et/ou à réparer, qui sont
utilisées pour établir des patterns spécifiques de démontage et de réparation. Ces patterns sont
eux aussi associés aux produits référencés par le SGDT de la plate-forme.

Une fois le diagnostic établi et les séquences de réparation ou de démontage connues, les
appareils sont envoyés vers les ateliers (démontage ou réparation) en fonction des opérations
qu’ils auront à subir. Notons que les deux ateliers peuvent interférer puisque certaines
opérations de réparation peuvent en nécessiter d’autres de démontage. Dans les ateliers, le
démontage peut être réalisé selon trois modes : entièrement automatique, semi-automatique
ou entièrement manuel. Le choix de l’un de ces modes dépend de la complexité des
opérations à réaliser, de leur standardisation (si elles correspondent à un pattern référencé)
ainsi que du danger qu’elles peuvent faire courir à un opérateur humain. Par conséquent, les
ateliers sont composés de cellules semi-automatiques décrites dans [CHEVRON 99], pouvant
fonctionner selon l’un des trois modes précédents. Les patterns de désassemblage (référencés
dans le SGDT) sont fournis aux cellules ainsi que les données techniques sur les produits à
traiter, selon le niveau de granularité de détail souhaité (qui varie en fonction du type de
démontage : manuel ou automatique). Les cellules enrichissent à leur tour les informations sur
le produit en rapportant leurs différentes observations et évaluations. Enfin, les éléments
récupérés ou/et réparés sont placés dans des stocks, pour être réutilisés.

1.1.2 Réseau de plates-formes

A un niveau plus élevé, nous envisageons la conception d’un réseau de plates-formes du type
de REX. En effet, avec la généralisation de l'intérêt du démontage, il est possible d'envisager
la distribution du processus de recyclage sur plusieurs plates-formes. Plusieurs scénarios sont
envisageables : les plates-formes peuvent être génériques (aptes à tous types de démontage)
ou spécialisées (dédiées à certains types d’appareils). Il est nécessaire dans ces deux cas
d'établir une coopération entre plates-formes et une distribution du processus de recyclage sur
le réseau. La répartition des activités pourrait se faire en fonction des disponibilités des plates-
formes ou par rapport à leur spécialisation, elles sont dans ce cas groupées en fonction des
compétences des plates-formes.

Dispatcher le processus de recyclage sur un réseau accentue la complexité de sa gestion

puisqu'il augmente le nombre de contraintes techniques à résoudre. En effet, il est nécessaire
de mettre en œuvre des mécanismes de communication et de coopération non seulement entre

212
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

les acteurs d'une même plate-forme, mais également entre les plates-formes concernées par un
même processus. Par ailleurs, plusieurs problèmes d'ordre logistique sont à considérer, tels les
échanges de produits ou de composants entre les différents sites, etc.

1.2 Apport du Workflow au processus de recyclage

La technologie du workflow propose des solutions avantageuses aux besoins d’organisation,
de gestion des processus et de mise à disposition de l’information. La plate-forme REX et à
plus grande échelle, le réseau de plates-formes, présentent de tels besoins. En effet, REX
réunit au sein d’une même structure - qui peut être virtuelle, c'est à dire dont les composants
sont répartis géographiquement - différentes compétences : ateliers de démontage et
réparation, stocks de produits, centre de logistique, etc.. qui interviennent à des niveaux
distincts du processus de recyclage et de revalorisation des produits électroménagers en fin de
vie. De plus, à chaque étape du processus, plusieurs informations, documents et objets (les
appareils ou leurs composants) sont manipulés, échangés et modifiés.

1.2.1 Besoins et contraintes de la plate-forme

Après concertation des différents membres du projet et compréhension de leur point de vue et
de leur conception du fonctionnement de la plate-forme, nous avons défini un ensemble de
contraintes et de besoins principaux qui devraient être satisfaits par l'usage de la technologie
Workflow [SAIKALI et al. 00], [SAIKALI et al. 99] :

§ Un besoin de gestion et de suivi rigoureux du processus, qui est d'autant plus

important que les étapes principales du processus peuvent ne pas se dérouler
nécessairement sur la même plate-forme.

§ Des besoins d'organisation et de communication entre les différents acteurs du

recyclage.

§ Des besoins d'accessibilité et de mise à disposition de l'information. Celle-ci concerne

les données techniques sur les produits à associer aux tâches, les informations sur les
appareils à récupérer, les plans de route des centres de collectes, etc.

Ces besoins peuvent être satisfaits grâce aux fonctionnalités des systèmes et de la technologie
"classique" du Workflow. Cependant, en plus des besoins d'ordre général dont nous venons de
parler, la plate-forme introduit un certain nombre de contraintes qui devront nécessairement
être prises en compte par la solution Workflow adoptée :

§ Contrairement aux processus qui sont traditionnellement gérés par les systèmes
Workflow, le processus de recyclage implique de façon importante des acteurs
automatiques dans la réalisation de ses activités. Cela est notamment vrai au niveau
des ateliers où, selon la configuration adoptée, les acteurs chargés du démontage
peuvent être de type humain ou automatique. Dans ce dernier cas, les appareils utilisés
(robots, automates, etc.) sont des acteurs à part entière, traitant des activités clés de la
chaîne des activités du processus.

Une autre contrainte directement liée à cet aspect est qu'il ne doit y avoir qu'une seule
configuration Workflow, quel que soit le type d'acteurs retenus. Il n'est en effet pas
envisageable, pour des raisons d'efficacité et de faisabilité, de construire plusieurs

213
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

configurations Workflows possibles (activités "humaines" ou automatiques). Cela est

d'autant plus difficile qu'on ne sait pas toujours quand une activité nécessitera d'être
réalisée par un acteur humain ou non. Par exemple, supposons que les activités
d'extraction des pièces volumineuses de certains appareils soient confiées à des robots.
Si l'un d'entre eux tombe en panne et qu'il n'est pas possible de rediriger les appareils
vers un autre robot, une solution peut être de remplacer le robot défectueux par un
opérateur humain. Réciproquement, certaines activités normalement traitées par des
personnes peuvent être réalisées par des robots pour plusieurs raisons, parmi lesquelles
par exemple, des raisons de sécurité (manipulation de composants dangereux).

§ La deuxième contrainte, qui découle en partie de ce que nous venons dire, est celle de
l'adaptabilité du processus. En effet, plusieurs facteurs peuvent nécessiter d'adapter le
processus de recyclage. Au niveau de la plate-forme, et en particulier à celui des
ateliers, les pannes des cellules de démontage et de réparation - qu'il est aussi
nécessaire de détecter - peuvent amener à une reconfiguration de l'atelier. Celle-ci peut
également être due à des évolutions technologiques qui exigent de remplacer le
matériel existant par un autre ou les méthodes utilisées par des méthodes plus récentes.
Par ailleurs, la plate-forme est soumise à des contraintes issues de l'activité même du
recyclage dont la législation peut changer (devenir plus stricte sur le pourcentage à
recycler, sur les méthodes à utiliser, etc.), ce qui amène à introduire des modifications
dans la façon de réaliser le recyclage et la revalorisation des appareils usagés. Ces
modifications peuvent concerner toutes les étapes du processus, depuis la collecte
jusqu'à la mise en stock des composants extraits ou des produits réparés. Par
conséquent, le système Workflow utilisé doit, lui aussi, pouvoir intégrer les
modifications, de la façon la plus transparente possible.

§ Enfin, la modélisation Workflow établie doit être compréhensible par l'ensemble des
acteurs - décideurs - du processus, aux spécialités diverses. En particulier, l'outil de
modélisation Workflow doit être partagé par tous les membres du projet "RESTER
PROPRE". En effet, la conception de REX est un travail coopératif mettant en jeu des
compétences différentes, aboutissant à la création de plusieurs modèles spécifiques.
Dans le souci de la mise en place d'un système intégré, il est primordial que ces
modèles soient cohérents entre eux et qu'il soit possible de trouver les relations
permettant de passer de l'un à l'autre. D'autre part, les membres du projet sont
représentatifs des domaines techniques et scientifiques nécessaires au bon
fonctionnement de la plate-forme, ils peuvent par conséquent servir "d'échantillon
expérimental" pour valider la modélisation Workflow du processus de recyclage.

1.2.2 Solution 2FLOW

Les composants de 2FLOW permettent de répondre aux besoins définis par la plate-forme, en
satisfaisant les contraintes qui y sont fixées. En effet, en plus de la plupart des fonctionnalités
"classiques" proposées par les systèmes Workflows, notre framework présente un ensemble
de propriétés qui sont directement concernées par les contraintes posées par la plate-forme
REX. En particulier, l'approche adoptée par le framework pour l'attribution des activités aux
acteurs nous paraît bien convenir à la prise en charge des acteurs humains et automatiques.

Par ailleurs, les capacités d'adaptabilité développées dans 2FLOW doivent nous permettre
d'appréhender les besoins d'adaptation à deux niveaux

214
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

1. Au niveau de la reconfiguration de la plate-forme.

2. Au niveau du processus de recyclage.

1. L'adaptation au niveau de la reconfiguration de la plate-forme et en particulier celle des

ateliers, ne concerne que les adaptations sur les composants ne remettant pas en cause le
flux des activités du processus. Cette adaptation peut concerner différents niveaux. Il peut
s'agir de la modification du comportement de certains acteurs - due par exemple à
l'évolution des technologies utilisées – ou de l'introduction de nouveaux composants à la
structure du workflow en cours, en réponse à l'introduction réelle de nouveaux acteurs
dans la plate-forme.

2. L'adaptation au niveau du processus de recyclage remet en cause le déroulement des

activités du processus. Elle peut nécessiter leur réordonnancement et/ou l'ajout et/ou la
suppression de certaines classes d'activités ou de sous-processus.

Quel que soit le niveau d'adaptation, nous pensons pouvoir les traiter grâce aux mécanismes
d'adaptation et de modélisation dynamique, fournis par le framework.

Enfin, côté modélisation, les formalismes UML retenus pour le développement des workflows
à l'aide des composants 2FLOW représentent un atout supplémentaire étant donné la culture
générale UML acquise par l'ensemble des membres du projet. L'usage d'UML a donc été un
atout de communication et un outil de travail qui a permis de partager et d'intégrer les
différents points de vues sur le projet.

2. Conception du Workflow de la plate-forme REX

Dans les prochains paragraphes, nous allons développer la solution 2FLOW pour le
processus de recyclage traité par la plate-forme REX. La recherche de cette solution s'effectue
de façon progressive, en appliquant la méthode de conception que nous avons proposée dans
le chapitre précédent. Nous allons donc partir de l'identification des principales tâches à
réaliser dans le processus, sous la forme de cas d'utilisation, pour terminer avec la création de
l'ensemble des classes 2FLOW nécessaires à la construction et l'exécution du workflow de la
plate-forme.

2.1 Analyse du processus de recyclage

En général, l'instanciation d'un cas Workflow commence par l'identification d'un événement
lié à la présence d'un objet autour duquel le workflow va se concrétiser. L'objectif du
workflow étant la résolution du cas posé par cet objet. Par exemple, reprenons le processus de
remboursement des frais d'hospitalisation par une assurance, que nous avons précédemment
décrit. Un cas du workflow correspondant est instancié par une nouvelle demande de
remboursement, qui correspond à l'objet du cas. Reprenons également l'exemple du processus
d'hospitalisation d'un patient : le workflow est déclenché par le patient qui constitue lui-même
le "cas" à traiter.

L'exécution de chaque workflow se justifie donc par l'objet d'un cas, qui est traité dans son
intégralité en tant qu'entité indépendante. En d'autres termes, les activités exécutées lors d'un
cas workflow ne traitent en général que l'objet de ce cas, ce qui n'empêche pas, bien entendu,

215
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

qu'un même acteur participe au traitement de plusieurs cas, donc réalise plusieurs instances de
la même activité, mais sur des objets différents.

Dans le cas de la plate-forme cependant, cette logique ne peut pas toujours s'appliquer de la
même façon. En effet, en appliquant ce même raisonnement, alors tout appareil introduit dans
la plate-forme REX devrait donner lieu à l'instanciation d'un cas d'un workflow que l'on
pourrait intituler "démontage d'un appareil". L'exécution de ce workflow aurait pour effet de
suivre l'évolution de l'appareil en question, depuis sa récupération, en passant par son
diagnostic, l'élaboration de ses séquences de désassemblage ou de réparation, jusqu'à son
passage en atelier. Or en fait, après concertation des membres du projet impliqués dans les
problèmes de logistique, d'ordonnancement des ateliers et de conception des cellules, nous
avons constaté qu'il n'était pas toujours possible de considérer que nous avons un processus de
recyclage en un seul "bloc", partant de la collecte d'un appareil jusqu'à sa mise en stock. En
effet, des problèmes de gestion de file d'attentes, de stocks et de lots font qu'il y a une
discontinuité entre les étapes principales du processus de recyclage. Cette discontinuité
implique que l'objet d'un workflow - en l'occurrence un appareil usagé – perd son statut
d'unicité lorsqu'il est associé à un lot. Considérons l'exemple d'un appel vers le centre de
collecte faisant état d'un appareil usagé disponible. Les contraintes logistiques d'optimisation
des déplacements font qu'il n'est pas possible de récupérer chaque appareil séparément. Ainsi,
lorsqu'un appareil est récupéré lors d'une collecte, l'objet du workflow dans ce cas n'est pas
l'appareil lui-même, mais le lot dont il fait partie. Cet exemple se répète pour d'autres étapes
du processus de recyclage, que nous aurons l'occasion de décrire dans la suite de ce chapitre.

Par conséquent, bien qu'on parle de processus de recyclage de façon globale, ce dernier n'est
en fait pas réalisé par un seul workflow global. Il est plus juste de parler de plusieurs
workflows, gérant des processus collaboratifs entre différents acteurs de la plate-forme,
associés à des objectifs spécifiques. Les effets cumulés de l'exécution des activités de ces
workflows décrit le fonctionnement de la plate-forme et réalise le processus de recyclage.

Monde Monde
extérieur extérieur

Workflow 2

Workflow 1

Workflow n

Plate-forme REX

: acteur : échanges entre workflows

: participation : Appareil usagé/réparé Pièces détachées

Figure V.3 – Coopération de workflows pour gérer le fonctionnement de REX

L'analyse du fonctionnement de la plate-forme en fonction des travaux des membres du projet

RESTER PROPRE nous amène à décrire le fonctionnement de REX en termes de quatre
processus principaux : la collecte des appareils usagés, le diagnostic, le traitement des

216
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

appareils (désassemblage/réparation) et la gestion des échanges entre plates-formes. Ces

processus, bien qu'indépendants dans leur déroulement, expriment une collaboration entre les
acteurs qui les réalisent.

Nous allons à présent étudier les workflows qui décrivent le fonctionnement de la plate-
forme. Pour chacun d'entre eux, nous appliquons pour l'instant les deux premières étapes de
notre méthode, c'est à dire de la détermination des processus et sous processus à l'aide des cas
d'utilisation et leur description en termes de diagrammes d'activités.

2.1.1 Collecte des produits usagés et processus de transport de produits

La collecte des appareils des produits usagés peut se faire selon deux modes [LANDRIEU
99]:

1. Un mode "passif", dont le principe est d'attendre que les appareils soient déposés dans la
plate-forme ou dans sa composante chargée de la collecte. Celle-ci peut correspondre à
des centres de récupération ou des centres d'achats, dans lesquels les produits sont achetés
aux personnes qui les y apportent.

2. Un mode "actif", qui consiste à aller chercher les produits usagés, ce qui nécessite
l'intervention de véhicules pour ramener les produits vers la plate-forme. Le mode actif
peut être réalisé de trois façons différentes :

§ La collecte depuis des centres de déchetteries.

§ La collecte de "trottoir".
§ La collecte "à la carte", qui consiste à enregistrer des demandes ponctuelles de la part
de particuliers ou d'organismes. C'est ce dernier mode qui est mis en œuvre sur REX,
car il permet une dynamisation de la récupération des produits usagés en impliquant
les utilisateurs dans la problématique du recyclage et de la revalorisation.
Réceptionniste
La collecte des appareils usagés est le premier
processus mis en œuvre sur la plate-forme. Ce
processus implique la participation des tenants de Chef logistique Chef magasinier

quatre rôles : le "réceptionniste", le "gestionnaire des Collecte des

appareils
transports", le "responsable logistique" et le chef
magasinier (fig. V.4). Gestionnaire transport

Ce processus est affiné en deux sous-processus

distincts (fig. V.5) : le premier, que l'on nomme
Figure V.4 – Processus de collecte
"traitement des appels" implique un réceptionniste et le
chef logistique. Il consiste en la réception des Réceptionniste Chef logistique
Traitement
demandes concernant la récupération des appareils des appels
usagés. Chaque appareil requiert la création d'un
dossier qui est transmit à la composante logistique de Gestionnaire
transport
la plate-forme. Celle-ci a pour mission de valider les Récupérer
produits
dossiers et de les associer à des prévisions de collectes. Chef magasiner
Le deuxième processus concerne "la récupération des
Collecte
appareils". Lorsque la logistique dispose d'un nombre des appareils
suffisant d'appareils pour justifier un déplacement, elle
Figure V.5 – Affinage du "use
génère un plan de route qui est transmis au gestionnaire
case" Processus de collecte

217
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Réceptionniste Chef Logistique

des transports, lequel va initialiser le processus
de récupération physique des produits. Une fois
[demande de
ceux-ci récupérés, ils sont pris en charge par le récupération]

stock, géré par le chef magasiner. Etablir

dossier

Dossier
Nous allons à présent détailler chacun de ces
deux processus à l'aide du diagramme Evaluer Dossier:
d'activités appropriés. L'analyse affinée du dossier(s) archivé

processus de traitement des dossiers concernant [nombre

suffisant]

les appareils nous apprend que ce dernier est Dossier: Dossier:

Dossier
refusé archivé
initialisé par la réception d'une demande (appel
téléphonique, message électronique, etc.) - qui Établir
plan de route
est donc un événement - pour la récupération
d'un appareil donné. Le réceptionniste recevant Plan de
route
l'appel doit établir un dossier pour chaque
produit concerné, contenant un ensemble Récupérer
d'informations telles le type de l'appareil, son produits

état, sa localisation, etc. Une fois le dossier

établi, il est envoyé au chef logistique pour
évaluation. Chaque dossier accepté est archivé Figure V.6 - Diagramme d'activités du
tant que le nombre de dossiers ne justifie pas la processus "Traitement des appels"
mise en œuvre du processus de récupération des appareils, qui doit être optimisé. Quand cela
est le cas, un événement "nombre appareils suffisant" déclenche la création d'un plan de
route qui est transmis au processus de récupération.
Chef logistique

Le processus de récupération implique essentiellement

deux rôles, le "chef magasinier" et le "gestionnaire de Gestionnaire
transport
transport", et dans une moindre mesure, le chef Récupérer Chef magasinier
produits
logistique. Il est intéressant de nous pencher quelque
peu sur le diagramme de cas d'utilisation de ce « étend »
processus. Il est en effet lié à un autre cas d'utilisation
Transport
appelé "Transport de produits", par une relation de produits
nommée "étend". La relation d'extension est l'équivalent
d'une spécialisation de classes, appliquée aux cas
d'utilisations. En d'autres termes, si un cas d'utilisation Figure V.7 - Processus de
en étend un autre, il en est donc une spécialisation. récupération des produits usagés
Dans notre cas particulier, le processus de récupération
des produits usagés est une spécialisation d'un processus plus générique, qui est le transport
de produits. La présence d'une relation d'extension entre les cas d'utilisation nous conforte
dans le choix d'UML comme langage de modélisation puisqu'il est "naturellement" possible
de représenter la spécialisation de processus, aspect qui nous intéresse fortement en termes
d'adaptabilité et de réutilisation.

Le processus générique de transport est initialisé par la soumission d'un plan de routage au
gestionnaire de transport. Ce dernier doit alors s'acquitter de sa mission, c'est à dire organiser
le déplacement des véhicules chargés de transporter des produits, en fonction du plan de route
fixé. L'activité de transport peut avoir plusieurs finalités : la collecte d'appareils, la circulation
de produits entre plates-formes, etc. mais elle est toujours réalisée de la même façon, à
quelques variantes près. Elle produit également deux événements exclusifs : la réussite, qui
exprime que le véhicule a mené à bien le transport dont il avait la charge ou l'échec dans le

218
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

cas contraire. En cas de réussite, le plan de route est validé. De plus si l'objectif du transport
était la récupération de produits, ceux-ci sont envoyés au stock où ils sont réceptionnés par le
chef magasinier qui doit organiser leur stockage.
Gestionnaire transport Chef Magasinier

L'échec du transport donne lieu à la production

Plan de
d'un rapport, envoyé à la logistique. Ce rapport route
explicite les causes de l'échec, ce qui permet la
prise de décision quant à la suite des Réaliser
Mission
événements, exprimée dans la figure sous la [échec
]
forme d'un processus générique. Par exemple si [succès] Plan de
route:
le transport n'a pu se faire suite à une panne de Rapport validé
véhicule, la logistique peut envoyer un nouveau
plan de route qui sera exécuté une prochaine
Processus Produit Stocker
fois. Par contre si le transport consistait en la Décision
collecte d'appareils mais que les adresses étaient
incorrectes, il convient alors de supprimer les
dossiers correspondants et d'abandonner
l'objectif de récupération pour ces objets. Figure V.8 - Processus générique de
transport
Le processus générique de transport peut être
utilisé tel quel ou spécialisé, au moins pour lui Chef logistique Gestionnaire
attribuer un nom plus spécifique, comme c'est le transport
Requête de
cas du processus de récupération des produits. Produits

Magasinier « utilise » Envoi

Un autre exemple de l'utilisation du processus de produits
générique de transport est donné par le processus
"requête de produits" entre plates-formes. Il se « étend »

peut que les plates-formes aient à s'envoyer Processus

de transport
réciproquement des produits (appareils,
composants ou pièces, etc.) pour des raisons
diverses (distribution du processus de recyclage, Figure V.9 - Processus de déplacement
surplus de stock ou au contraire, besoins sur tels de produits
type de pièces, etc.) Il convient alors de mettre
en œuvre un processus qui permet de prendre en compte les requêtes des plates-formes et le
transport des produits de l'une à l'autre. C'est l'objectif du processus "requête de produits".

Dans la figure V.9, nous avons introduit la relation UML "d'utilisation" (ou "d'inclusion")
entre use cases. Cette relation exprime le fait qu'un cas d'utilisation utilise les services d'un
autre cas d'utilisation. Plus précisément, elle indique que le use case "utilisateur" comprend
(inclue) les services proposés par l'autre use case. Cette relation est très intéressante à notre
niveau car en la "détournant" pour l'appliquer au Workflow, elle nous permet d'exprimer une
composition entre processus, sans avoir à affiner la vue du processus conteneur. L'intérêt est
donc d'exprimer les caractéristiques principales d'un processus dès les premiers diagrammes.

Par exemple dans le processus "requête de produits" (fig. V.9), la relation d'utilisation nous
permet de percevoir immédiatement qu'un processus de transport de produit est nécessaire
- "envoi de produits"- et que ce dernier est une spécialisation du processus générique de
transport. Etant donné que la relation d'utilisation exprime une inclusion, alors on en déduit
que le processus "envoi de produits" est un composant du processus "requête de produits".

219
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Chef Magasinier Chef Logistique

Le processus "requête de produits" est initialisé par
l'occurrence d'une requête provenant d'une autre plate- [requête produits]

forme (appel téléphonique, courrier électronique, etc.),

Vérifier
adressée à un Magasinier. Celui-ci est alors chargé de disponibilité
vérifier les disponibilités du stock pour la satisfaction [produits non
disponibles]
[produits
disponibles]
de la requête. Si la vérification est infructueuse, alors
Envoyer Émettre
un message est envoyé à l'émetteur de la requête. Message requête
Remarquons que cette activité n'est effectuée que si la
Message Requête Etablir
vérification ne se fait pas en temps réel. En effet, si la Transport plan
requête est faite par téléphone et que la vérification se
fait immédiatement, il n'est pas nécessaire d'envoyer Plan de
route
un message.
Envoi des
Si les produits demandés sont disponibles, le produits
magasinier émet une requête vers le chef logistique –
en lui passant les types des objets à transporter et leur
destination – afin d'établir un plan de route dont la Figure V.10 – Diagramme
production va servir à initialiser le processus d'envoi d'activités du processus de requête
des produits. de produits.

2.1.2 Processus de diagnostic et de planification Evaluation

Préparation
Agent de
Chaque appareil récolté et stocké dans la planification
plate-forme est soumis à un diagnostic Evaluation
Préparation
qui sert à évaluer son état et à décider s'il
est réparable ou si l'on peut en extraire Diagnostic
Planification
des composants en état de marche. Afin
de prendre cette décision, les acteurs Agent diagnostic Agent de planification
chargés du diagnostic ont besoin des
Modèle
informations détaillées sur l'appareil en fonctionnel
question, principalement [KOBEISSI 00]: Modèle [arrivage
structurel d’un appareil]

Etablir
§ Son "modèle fonctionnel", qui décrit Etat du
diagnostic
Stock [Démontable
l'appareil en termes de fonctions et de ]

fonctionnalités. Celles-ci sont testées [irrécupérable] [Réparable]

Etablir
afin de localiser les pannes dans ListePièces
[si liste non référencée]
l'appareil. Etablir
ListePannes [liste référencée]

§ Une fois la panne localisée, le Pièces à extraire

diagnostic se base sur le "modèle Liste des

Pannes
structurel" du composant - sa Appareil Générer
Séquences
nomenclature - afin de déterminer
quels sont les composants et les Séquences de
démontage
pièces à l'origine de la panne.
Séquences de
§ Enfin, le diagnostic requiert de Recyclage
brut
Réparation
démontage
Démontage
connaître l'état du stock en terme de
besoins éventuels sur des types de
pièces. Figure V.11 - Diagnostic et Planification

220
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

L'ensemble des informations techniques sur les appareils à évaluer est extrait du système
d'information de la plate-forme, le SGDT. Ce dernier contient un modèle global de chaque
appareil pouvant être traité par la plate-forme, diversifié en fonction des vues spécifiques sur
le produit (vues diagnostic, vue planification, modèles structurel, fonctionnel, séquences de
désassemblage, etc..) [BOUTROS et al. 00a], [BOUTROS et al. 00b]. Ce modèle peut être
enrichi par les observations réalisées en cours du processus de recyclage. Par exemple, les
constatations faites par le diagnostic sur les défaillances concernant un modèle de produit,
peuvent être ajoutées aux informations de la vue diagnostic sur le produit. Ainsi, les pièces
concernées par ces défaillances récurrentes pourront être testées en priorité et l'origine de leur
panne connue.

Trois résultats peuvent découler du diagnostic :

1. Le produit est réparable et dans ce cas il est envoyé au processus de réparation. Les
artefacts qui lui sont passés sont respectivement l'appareil lui-même, ainsi que la "liste
des pannes", générée par l'activité "établir liste de panne", qui contient la description des
dysfonctionnements constatés sur l'appareil et leur localisation (en terme de pièces).

2. Le produit n'est pas réparable mais il est possible d'en extraire certaines pièces en état de
marche. Dans ce cas, la liste des pièces à démonter est générée par l'activité "établir liste
des pièces". Si la liste des pièces était déjà existante, alors l'appareil et directement
envoyé à l'atelier de démontage, sans passer par la tâche de planification. En effet, les
travaux menés par les membres du projet chargés de l'étude du diagnostique [KOBEISSI
et al. 00] et de la planification [GERNER et al. 99], [GERNER et al. 00] estiment que
dans la majorité des cas, il s'agit toujours d'extraire les mêmes listes de pièces des
appareils. Par conséquent, il est possible d'établir des séquences de désassemblage
optimisées une fois pour toutes, puis de les lier au modèle du produit, ce qui permet
d'accélérer le processus de recyclage. Si toutefois la liste des pièces n'est pas déjà
référencée dans le modèle du produit, alors elle est envoyée à un agent de planification,
qui est chargé d'établir la meilleure séquence de désassemblage. Celle-ci est par la suite
envoyée avec l'appareil à l'atelier de désassemblage. Notons qu'elle est également
automatiquement liée au modèle du produit concerné, et associée à la liste de pièces
correspondantes.

3. Le produit n'est ni réparable, ni récupérable. Dans ce cas, il est directement envoyé vers
un processus de recyclage brut, qui n'a pas lieu sur la plate-forme (il peut avoir besoin de
la mise en œuvre d'un processus de transport que nous ne représentons pas ici).

2.1.3 Processus de désassemblage

Il n'est pas possible de donner une modélisation précise du processus de désassemblage,

puisqu'il dépend de plusieurs facteurs non prévisibles. En effet, les ateliers peuvent traiter
différents types d'appareils, sans nécessairement connaître les pièces qui en seront extraites.
De plus, un ordonnancement des ateliers est à prévoir avant d'affecter les appareils et les
séquences de désassemblage aux cellules de l'atelier. Par conséquent, les tâches ne sont pas
fixées à l'avance, ni les artefacts qui y seront échangés. En fait, il nous semble que c'est aux
acteurs chargés de l'ordonnancement de produire un modèle Workflow décrivant la répartition
des tâches au sein de l'atelier. La production de ce modèle pourrait être faite manuellement,
via l'éditeur de Workflows que nous proposons, soit automatiquement, via un module de
transcription des modèles d'ordonnancement à ceux du Workflow. Ce module n'existe pas

221
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

pour l'instant et il est donc plus vraisemblable que la modélisation se fera "à la main". Nous
pouvons néanmoins nous intéresser aux apports de 2FLOW à la modélisation des processus
de désassemblage.

[Link] Modélisation des acteurs automatiques et humains

Nous l'avons dit, le framework nous permet de gérer des acteurs automatiques aussi bien que
des acteurs humains. Ceci est un atout important au niveau des ateliers, puisqu'il est possible
d'y avoir plusieurs configurations (automatique, semi-automatique ou manuelle à des niveaux
de supervision ou d'action [DAVID et al. 99b]). Il faut cependant remarquer que selon qu'un
acteur est humain ou automatique, les artefacts et les activités qui lui sont attribuées ne
possèdent pas le même contenu.

Considérons par exemple une activité d'extraction d'une pièce Px d'un appareil A. Si cette
activité, attribuée à un "opérateur de désassemblage", est prise en charge par un opérateur
humain, alors ce dernier doit obtenir la description du produit et celle de la pièce Px. Il peut
éventuellement avoir besoin - en fonction de son niveau - des types d'outils à utiliser. Par
contre, dans le cas d'un acteur automatique, le niveau de détail des informations à passer est
beaucoup plus profond. Un robot nécessite doit avec précision la géométrie et la topologie de
l'appareil afin qu'il puisse atteindre la pièce désirée. Bien que 2FLOW permette sans problème
la réalisation d'une activité par un acteur humain ou automatique, le problème qui se pose est
au niveau des artefacts : comment faire la distinction entre les artefacts dédiés aux acteurs
humains et ceux des acteurs automatiques ? En effet, il n'est pas souhaitable de prévoir deux
types d'activités (l'une pour les acteurs humains, l'autre pour les automatiques). Il est de même
exclu de laisser à l'activité le soin de déterminer le type de l'acteur qui prend l'activité. Nous
proposons donc deux solutions à ce problème :

1. La solution la plus simple consiste à prévoir les deux types d'artefacts, et de les lier tous
les deux aux activités du modèle. Cette solution ne pose pas de problème particulier au
niveau de la conception - il faut bien sûr prévoir deux classes d'artefacts. Les deux
artefacts sont par la suite envoyés à l'acteur concerné, qui se chargera à son niveau de faire
le tri. Celui-ci peut être fait au niveau de la méthode correspondant à l'activité dans la
classe de l'acteur, soit au niveau de l'acteur lui-même.
faireX : Activite :DocumentElectronique :Acteur
2. La deuxième solution est un peu plus
compliquée. Elle consiste à déplacer le
problème de l'activité à l'artefact. Nous faireX(objet:DocumentElectronique)
avons dit que lors de l'invocation de la sendArtefact(type de l’acteur)
méthode d'un acteur correspondant à
une activité, les références des artefacts évaluation

qui y sont liés sont passées dans un

setArtefact(artefact adéquat)
tableau d'objets, en tant qu'arguments
de la méthode. Il suffit alors d'ajouter à
la classe de l'artefact, une méthode
Figure V.12 - Récupération d'un artefact
pouvant être invoquée par l'acteur.
en fonction du type de l'acteur
Cette méthode pourrait recevoir en
argument
le type de l'acteur appelant (humain ou automatique) ce qui permettrait à l'artefact de lui
envoyer l'objet adéquat (fig.V.12).

222
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Nous n'avons pas encore implémenté cette solution au sein du workflow car elle ne nous
semble pas nécessaire pour l'instant, la première solution étant très acceptable. Elle peut
néanmoins être mise en œuvre par les développeurs workflows eux-mêmes, sans grand effort
de programmation.

Au niveau de la plate-forme REX, les artefacts qui sont associés aux activités dépendent
fortement de la stratégie de démontage adoptée dans l'atelier. En effet, on peut choisir d'avoir
un désassemblage complet par cellule ou bien d'attribuer à chaque cellule un sous-ensemble
des tâches du désassemblage - à la limite, une pièce par cellule. Selon le cas, le sens d'une
activité diffère. N'y a t'il qu'une seule activité (désassembler appareil A) ou une activité par
pièce (extraire pièce) ? Tout dépend du point de vue des organisateurs de l'atelier.

Si l'on considère que le désassemblage complet d'un appareil est une seule activité, alors les
artefacts à passer à l'acteur concerné sont :

§ Dans le cas automatique, la séquence de désassemblage complète (récupérée du SGDT ou

directement obtenue de l'étape de planification) est associée à l'activité. Elle comprend
l'ensemble des opérations nécessaire au désassemblage des pièces référencées dans la liste
produite par le diagnostic ainsi que l'appareil lui-même. Dans le cadre du projet RESTER
PROPRE, les séquences de démontage sont générées à l'aide de l'outil "Tecnomatix", sous
la forme de fichiers texte. Ceux-ci comprennent l'ensemble des opérations et des
déplacements à réaliser, ainsi qu'une indication sur le type d'outil à utiliser. Enfin,
l'appareil est envoyé à l'acteur - grâce au processus d'envoi lié à son artefact correspondant
dans le workflow.

§ Dans le cas manuel, il n'est théoriquement nécessaire d'envoyer à l'opérateur que la liste
des pièces à extraire. En fait, il est plus vraisemblable de tenir compte du niveau de
l'opérateur en question. En effet, nous avons prévu la possibilité de la présence dans les
ateliers d'opérateurs novices aussi bien que d'experts. Afin de fournir un support
informationnel adéquat à ces opérateurs, un des objectifs du projet a été la conception d'un
didacticiel multimédia pour apprendre le désassemblage [BOUTROS et al. 00c]. Un
générateur de didacticiels a également été conçu, afin de générer automatiquement des
didacticiels spécialisés à chaque appareils pouvant être traité par la plate-forme. Afin de
produire des didacticiels adaptés au niveau de l'utilisateur (novice ou expert pour
l'instant), le générateur fait appel à un éditeur de patterns de présentation, actuellement en
cours de développement dans le projet. Par conséquent, un autre artefact à être envoyé à
l'utilisateur est le didacticiel lui-même (ou plus exactement son URL). Bien entendu,
l'appareil à démonter est également envoyé en tant qu'artefact.

Si nous considérons que nous avons une activité par pièce à extraite :

§ Dans le cas automatique, il convient alors de fractionner les séquences de démontages afin
de les particulariser pour chaque pièce. Dans ce cas, on obtient une séquence de
démontage global pour l'ensemble de l'appareil, composée de sous-séquences spécifiques
à chacune des pièces. Ce sont ces sous-séquences qui sont envoyées sous forme
d'artefacts, accompagnées bien entendu de l'appareil lui-même.

223
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

§ Dans le cas humain, les artefacts à envoyer sont les mêmes que dans le cas précédent, sauf
qu'il ne faut plus envoyer la liste des pièces à extraire, mais uniquement le nom de la pièce
concernée.
Remarquons enfin que si les activités sont définies en fonction des pièces à traiter, se pose
alors la question de leur correspondance avec les méthodes des acteurs. Nous avions déjà
soulevé ce problème dans le chapitre IV, et nous y avions évoqués la solution de méthodes
génériques. Nous pensons que cette solution est la mieux adaptée aux cellules et aux
opérateurs de la plate-forme. En effet, il n'est pas concevable de créer pour chacun d'entre
eux, une méthode spécifique à chaque pièce pouvant être traitée, ce qui aboutirait à une
"explosion" du nombre de méthodes en fonction du nombre d'appareils pris en charge par la
plate-forme.

L'approche la mieux adaptée est celle que nous avons proposée dans le chapitre 4. Elle
consiste à créer des classes d'activités pour chacune des pièces, mais que ces classes fassent
référence à des méthodes génériques dans la classe de l'acteur associé. Nous utilisons pour ce
faire l'attribut "invokedService" de la classe "Activité", en lui affectant le nom du service
générique à invoquer chez l'acteur – au lieu d'invoquer la méthode ayant le même nom que
l'activité. Nous avons ainsi déterminé un ensemble de services que devait fournir un opérateur
de désassemblage, nous les décrivons dans la figure ci-dessous.
<<Activité>> <<Rôle>>
DecouperCouvercle OperateurDesassemblage
invokedService =couper
...
+ extraire ( ... ) <<Acteur>>
+ separer ( ... ) Robot_ZX
+ devisser ( ... )
<<Activité>> + couper ( ... ) ...
ExtraireCouvercle + declipser ( ... ) + extraire ( ... )
+ saisir ( ... ) + separer ( ... )
invokedService =extraire + ecarter ( ... ) + devisser ( ... )
... + deposer ( ... ) + couper ( ... )
+ declipser ( ... )
+ saisir ( ... )
+ ecarter ( ... )
<<Activité>> + deposer ( ... )
ExtraireMoteur
invokedService =extraire
...

Figure V.13 – Correspondance entre activités du désassemblage et services des acteurs

[Link] Modélisation des objets techniques

A chaque étape du processus de l'atelier, il est intéressant d'ajouter des informations sur l'état
d'avancement du désassemblage d'un produit. Ces informations peuvent être utilisées par des
modules de contrôle de l'atelier, afin d'évaluer son fonctionnement. Dans le workflow du
désassemblage, les pièces et les appareils traités sont associés à des artefacts de type
"ObjetTechnique", classe dérivée de la classe 2FLOW "Artefact". Dans le chapitre précédent,
nous avons dit qu'un ObjetTechnique pouvait être composé d'autres artefacts, ce qui est
notamment le cas des appareils traités par la plate-forme.

Lors de la création d'un objet technique correspondant à l'appareil, il est possible de lui faire
correspondre automatiquement les références aux autres objets qui le composent, sous la
forme d'artefacts. Cela est réalisé grâce à la méthode addArtefact( ) de la classe ObjetTechnique
de 2FLOW. A l'opposé lors du désassemblage, chaque méthode correspondant à une activité
attribuée à un acteur peut inclure un appel à la méthode removeArtefact( ) de la classe
correspondant à l'appareil en question. L'appel de la méthode se fait en lui passant comme
argument le nom de la pièce extraite de l'appareil, ce qui permet de retirer sa référence de

224
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

l'ObjetTechnique correspondant. Par ailleurs, il est également possible d'inclure une invocation
de la méthode [Link]( ), en lui communiquant le nouvel état de l'appareil (par
exemple 90 qui correspond à au pourcentage d'avancement du démontage).

Ces différentes méthodes sont des moyens intéressants d'obtenir des comptes-rendus sur l'état
d'avancement du désassemblage d'un produit. Ces informations peuvent en particulier être
utilisées lors de l'occurrence d'aléas dans l'atelier (des exceptions) qui en nécessitent une
reconfiguration rapide. Il s'agit alors de recommencer le processus là où il s'était arrêté, ce qui
est possible grâce à la récupération de l'état des appareils démontés. Nous rappelons que ces
valeurs peuvent être connues grâce aux méthodes [Link]( ) et
[Link]( ) mais également, grâce au contrôleur générique fourni par
2FLOW.

[Link] Exceptions et modifications des workflows

Les ateliers sont - malheureusement - nécessairement soumis à un moment ou à un autre, à

l'occurrence d'aléas divers (pannes de machines, cassure d'outil, etc.) Lorsque ces aléas ont
lieu, il est très important de pouvoir y réagir rapidement, afin de conserver la productivité de
l'atelier. Nous proposons donc de modéliser ces aléas sous la forme d'exceptions 2FLOW, qui
sont liées aux activités du workflow de désassemblage. Chaque classe exception est à son tour
associée à un processus ou une activité de gestion de l'exception.

Dans le cas de REX, les travaux sur les cellules de désassemblage [CHEVRON 99] prévoient
de munir cette dernière d'un dispositif de contrôle, soit entièrement automatique, soit sous la
forme d'une interface Homme-Machine qui communique l'état de la cellule à un superviseur
humain. Dans ces deux cas, les activités de gestion des exceptions peuvent consister en
l'invocation d'une procédure du système de contrôle de la cellule. Il s'agit alors de modéliser
le système de contrôle en tant qu'acteur responsable de l'activité (ou du processus) de
traitement en question. Les méthodes de l'acteur correspondant aux activités doivent donc
contenir le code nécessaire pour invoquer les procédures du système de contrôle.

<<Exception>>
cassureOutil:CassureOutil

1 : créer

<<Activite>>

:
signaleCassureOutil:SignaleCassureOutil Interface de contrôle

cassure outil

€
2 : signaleCassureOutil(... )

<<Rôle>>
Contrôleur
<<Acteur>>
interfaceControle:InterfaceControle
signal
8
Contrôleur

Workflow de désassemblage

Figure V.14 - Prise en charge d'une exception - redirection vers un système de contrôle
Homme-Machine (contrôleur humain, interface informatique)

L'occurrence des aléas peut également conduire à une reconfiguration de l'atelier :

remplacement de machine ou plus globalement remplacement d'acteurs, suppression de
tâches, etc. Il est alors nécessaire de modifier le workflow en cours d'exécution, ce qui est
rendu possible grâce aux mécanismes d'adaptation proposés par 2FLOW.

225
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

La stratégie de modification dépend de la "gravité" de la situation. S'il s'agit d'une panne

d'outil ou d'une panne de cellule, il faut remplacer l'acteur concerné par l'activité par un
nouvel acteur, en utilisant le contrôleur générique de 2FLOW. Si le problème nécessite de
réordonnancer les activités du processus ou de les modifier, il est alors nécessaire de
passer par une re-modélisation du workflow de désassemblage en utilisant l'éditeur
générique de 2FLOW. La manipulation de ce dernier pourrait être accordée aux personnes
chargée de l'ordonnancement du désassemblage ou aux entités de contrôle et de
commande de l'atelier. Il serait par ailleurs intéressant de tendre vers la possibilité d'une
génération automatisée des workflows, sujet sur lequel nous reviendrons dans les
perspectives de ce travail.

2.2 Conception du workflow de la plate-forme

La conception du workflow de la plate-forme consiste à passer à la troisième étape de la
méthode de conception que nous proposons, c'est à dire, à la conception des classes de
composants. Ces classes, nous l'avons dit, sont obtenues à partir des éléments des diagrammes
d'activités obtenus, en appliquant les règles de translation définies dans le chapitre précédent.

Etant donné que les classes déduites des diagrammes d'activités représentant les workflows de
la plate-forme sont plutôt nombreuses, nous les avons ajoutées en annexe de cet ouvrage.
Remarquons que les différentes vues sont établies pour chacun des workflows, ce qui aboutit
à une redondance de la représentation des classes. Cette redondance est bénéfique pour deux
raisons :

§ Elle permet d'éviter de surcharger le modèle global du workflow en le morcelant en

parties plus accessibles.
§ La redondance de représentation permet de lier les différentes vues entre elles, grâce aux
éléments qu'elles ont en commun - et qui sont bien sûr les éléments redondants.

Cette approche est d'ailleurs suivie par plusieurs méthodes de modélisation (telles ARIS ou
CIMOSA [VERNADAT 96]), qui préconisent de concevoir séparément les différentes vues
puis de les lier par la suite grâce à leurs éléments communs.

3. Conclusion
Au niveau de la plate-forme, nous attendons l'évolution des travaux des autres membres du
projet afin de mieux cerner les comportements des classes que nous avons définies. En
particulier, le format des documents à échanger entre les différents acteurs doivent être
définis, ainsi que les comportements des acteurs automatiques. Pour ces derniers, nous
comptons pour l'instant essentiellement sur une simulation, éventuellement avec l'outil
Tecnomatix ([Link] utilisé par certains membres du projet. Il reste
cependant à étudier les protocoles de communication avec cet outil et la façon dont nous
allons y créer des agents automatiques.

226
 Chapitre V : Application de 2FLOW – le projet RESTER PROPRE

Bibliographie

[BOUTROS et al. 00a] N. Boutros, K. Saï kali, B.T. David. "Intégration du Recyclage en
Conception: Application au recyclage de produits manufacturiers". IDMME
2000. Montréal, Canada. Mai 2000.
[BOUTROS et al. 00b] N. Boutros, K. Saï kali, B.T. David. "Recycling and Sustainable Design,
Role of Information Technology". MCPL 2000. Grenoble, France. 5-8
Juillet 2000.
[BOUTROS et al. 00c] N. Boutros, I. Vial, B. David, M. Dubois, D.R. Kouabenan. "Conception et
mise en œuvre d’un didacticiel professionnel". RJC-IHM 2000, 1ères
Rencontres Jeunes Chercheurs en IHM. 3-5 Mai 2000, Ile de Berder (Golfe
du Morbihan) France. Mai 2000.
[CHEVRON 99] D. Chevron. "Contribution à l'étude de la supervision d'une cellule de
démontage de produits techniques en fin de vie". Mémoire de Thèse pour
l'obtention du grade de "Docteur de L'institut Polytechnique de Grenoble en
Automatique et Productique". Grenoble. Novembre 1999.
[DAVID et al. 99a] B.T. David, [Link], [Link]ï kali, [Link], [Link], [Link], [Link],
[Link] . "Automation of Disassembly Processes and its Information
Systems". EcoDesign’99, First International Conference on EcoDesign.
Tokyo, Japan. Février 1999.
[DAVID et al. 99b] B. T. David, K. Saï kali, N. Boutros. "Conception orientée recyclage des
produits manufacturiers". 3° Congrès International de Génie Industriel.
Montréal, Canada. 26-28 Mai 1999.
[GERNER et al. 99] S. Gerner, A. Landrieu, Z. Binder, B. Descotes-Genon. "Recycling system:
distributed disassembly networks and disassembly workshop modelling".
3eme Congrès international de Génie Industriel, Montréal, Canada. 26-28
mai1999.
[GERNER et al. 00] S. Gerner, A. Kobeissi. "Economic and Ecological Product Evaluation in
Disassembly". MCPL'[Link], France. 5-8 Juillet 2000.
[KOBEISSI et al. 00] A. Kobeissi, Z. Simeu-Abazi. "Evaluation Methods and test product for
recycling". MCPL' 2000. Grenoble, France.. 5-8 Juillet 2000.
[LANDRIEU 99] A. Landrieu. "Une heuristique du problème de chargement et déchargement
appliquée au recyclage des produits manufacturés". ROADEF'99, 2è Congrès
de la Société Française de Recherche Opérationnelle et d'Aide à la Décision,
Autrans (Vercors), France. 13-15 Janvier 1999.
[SAIKALI et al. 99] K. Saï kali, N. Boutros, B.T. David. "An Adaptive Workflow Management
System for a Semi Automated Disassembly Platform". Workflow
Management’99, Conference on Workflow Based Applications. University
of Muenster, Germany. Novembre 1999.
[SAIKALI et al. 00] K. Saï kali, N. Boutros, B.T. David, J. Poquet. "Information Technology
support for the Recycling Problematic". CE2000, Conference on concurrent
engineering. Juillet 2000.
[VERNADAT 96] F. Vernadat. "Enterprise Modeling and Integration – Principles and
Applications". Chapman & Hall, 1996.

227