Table des matières
Sigles et abréviations 4
Table des figures 5
Liste des Tableaux 6
Avant-propos 7
Introduction 8
Chapitre 1 : Présentations
générales 9
I. Présentation de EXTEL : Structure d'accueil 10
1. Société 10
2. Stratégie 10
3. Solutions 11
II. Présentation du sujet 14
1. Problématique du sujet 14
2. Objectifs du sujet 14
Chapitre 2 : Théorie des Workflow et des
SGWF 16
I. Workflow ou Gestion des processus 17
1. Introduction au Workflow 17
2. Origines et motivations 17
3. Domaines d'applications 19
4. Définitions de base du Workflow 20
5. Dimensions 26
II. Les Systèmes de gestion de Workflow 27
1. Description des Systèmes de Gestion de Workflow 27
2. Model de référence des SGWF 28
3. Classification des systèmes Workflow 31
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
1
Chapitre 3 : Les méthodes d'analyse et de
conception 35
I. Les approches de méthodes d'analyse 36
II. Présentation du langage UML 38
III. Le Processus Unifié 42
1. Présentation 42
2. Les activités 43
3. Les phases 44
Chapitre 4 : Etude de l'existant 46
I. Présentation du progiciel Sunshine software 47
1. Architecture de Sunshine 47
2. Modules de Sunshine 50
3. Framework & Paramétrage 52
II. Présentation du système existant 56
1. Concepts 56
2. Description Fonctionnelle 59
3. Paramétrage de Workflow 59
4. Critiques du système existant 60
Chapitre 5 : Analyse et Conception du
système 61
I. Expression des besoins 62
1. Les utilisateurs 62
2. Le Diagramme de cas d'utilisation 63
3. Scenarii d'utilisation : description textuelle 65
II. Analyse et Conception 69
1. Scénarii d'utilisation : modélisation 69
2. Diagramme de classes du système : ébauche 82
3. Vue logique du système 83
4. Formalisme ou model de description de Workflow 88
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
2
Chapitre 6 : Mise en oeuvre 91
I. Choix des technologies 92
1. J2EE : Plate-forme de développement 92
2. Langage de représentation graphique des Workflow 94
3. Présentation de SVG (Graphiques vectoriels adaptables)
: 96
4. DOM pour l'Interactivité dans les documents svg 98
II. Présentation de l'application 100
Conclusion 106
Bibliographie 107
Wébographie 107
Annexes 108
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
3
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page 4
Sigles et abréviations
API Application Programming
Interface
DOM Document Object
Model
EDI Environnement de
Développement Intégré
EJB Enterprise Java
Beans
GED Gestion Electronique de
Document
http HyperText
Transfer Page
HTTPS Hypertext Transfer
Protocol Secured
IDEF Integration DEfinition
for Function Modeling
IHM Interface
Homme-Machine
J2EE Java 2 Enterprise
Edition
J2SE Java 2 Standard
Edition
JAXP Java API for
XML Parsing
JDBC Java
DataBase Connectivity
JFC Java Foundation
Class
JLOW Java Librairy
FOr Workflow
JSP Java Server
Pages
JTA Java Transaction
API
OMG Object Management
Group
OMT Object Modeling
Technique
OOSE Object Oriented
Software Engineering
PU Processus
Unifié
SADT Structured Analysis and
Design Technique
SGBD Système de
Gestion de Bases de
Données
SGBDR Système de
Gestion de Bases de Données
Relationnel
SGWF Système de
Gestion de Workflow
SOA Services Oriented
Architecture
SQL Structured Query
Language
SVG Scalable Vector
Graphics
UML Unified Modeling
Language
WAPI Workflow Application
Programming Interface
WfMC Workflow Management
Coalition
XML eXchange
Markup Language
XPDL XML Process
Definition Language
XSLT eXtensible
Stylesheet Language
Transformations
WAPI Workflow Application
Programming Interface
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page 5
Table des figures
Nous présentons ici la description des figures
présentes dans le document.
Référence Description
Figure 2.1 Historique des systèmes de gestion de
Workflow
Figure 2.2 Environnement du système Workflow
Figure 2.3 Méta modèle Workflow pour la
définition de Processus
Figure 2.4 Réseau de Processus
Figure 2.5 Dimensions des systèmes Workflow
Figure 2.6 Caractéristiques du système Workflow
Figure 2.7 Model de référence Workflow
Figure 2.8 Différentes classes des systèmes
Workflow
Figure 3.1 Vue 4+1 définie par Kruchten
Figure 3.2 Cycle de vie du Processus Unifié
Figure 4.1 Contexte d'exécution de Sunshine
Figure 5.1 Diagramme de cas d'utilisation du système
Figure 5.2 Diagramme de classes « Gérer les
états »
Figure 5.3 Diagramme de classes « Gérer les
traitements »
Figure 5.4 Diagramme de classes «Gérer les Workflow
»
Figure 5.5 Diagramme de classes «Paramétrer Workflow
»
Figure 5.6 Diagramme de séquences « Paramétrer
Workflow »
Figure 5.7 Diagramme de séquences « Visualiser
Workflow »
Figure 5.8 Diagramme de séquences « Faire le suivi
Workflow »
Figure 5.9 Diagramme de classes « Gérer les
règles d'acceptation »
Figure 5.10 Diagramme de classes « Gérer les attentes
»
Figure 5.11 Diagramme de classes du système
(ébauche)
Figure 5.12 Diagramme de classes « Gestion des états
»
Figure 5.13 Diagramme de classes « Gestion des traitements
»
Figure 5.14 Diagramme de classes « Gestion des Workflow
»
Figure 5.15 Diagramme de classes « Gestion des règles
d'acceptation »
Figure 5.16 Diagramme de classes « Gestion des attentes
»
Figure 5.17 Model IDEF0 de description des processus Workflow
Figure 5.18 Formalisme général de description d'une
transition Workflow
Figure 5.19 Formalisme transition automatique
dans Sunshie
Figure 5.20 Formalisme transition manuelle
Figure 5.21 Formalisme transition sous condition
Figure 6.1 Architecture du système de gestion de
Workflow
Liste des Tableaux
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page 6
Référence Description
Tableau 5.1 Détails de la classe « JATYPET
»
Tableau 5.2 Détails de la classe « JAETAT
»
Tableau 5.3 Détails de la classe « JARESFT
»
Tableau 5.4 Détails de la classe «
JATRAIT»
Tableau 5.5 Détails de la classe « JAFONCT
»
Tableau 5.6 » Détails de la classe « JAWRKPR
»
Tableau 5.7 Détails de la classe « JAWRKFT
»
Tableau 5.8 Détails de la classe « JAWRKFL
»
Tableau 5.9 Détails de la classe « JAWRKCD
»
Tableau 5.10 Détails de la classe «
JACRTRN»
Tableau 5.11 Détails de la classe « JAINFET
»
Tableau 5.12 Détails de la classe « JACTLSP
»
Tableau 5.13 Détails de la classe « JAACPFP
»
Tableau 5.14 Détails de la classe « JACLCTL
»
Tableau 5.15 Détails de la classe « JACRCTL
»
Tableau 5.16 Détails de la classe « JAACPTP
»
Tableau 5.17 Détails de la classe « JAACCRP
»
Tableau 5.18 Détails de la classe « JAFTREP
»
Tableau 5.19 Détails de la classe « JACTREP
»
Avant-propos
L'école supérieure polytechnique est un
établissement public d'enseignement supérieur rattaché
à l'université Cheikh Anta Diop de Dakar. Elle est
composée des départements suivants : génie informatique,
génie civil, génie électrique, génie
mécanique, génie chimique et gestion. Sa vocation est de former
des ingénieurs et des techniciens supérieurs dans ces
différentes filières.
La formation d'ingénieur de conception s'étale
sur trois ans et comporte un stage obligatoire de fin de cycle durant la
troisième année. C'est dans ce cadre que nous avons
effectué un stage pour une durée de quatre mois au sein de la
société EXTEL sur le thème : « Mise en place
d'un système de gestion de Workflow : Paramétrage, suivi et
représentation graphique »
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
7
Introduction
L'environnement des entreprises et des organisations est de
plus en plus complexe, pour rester compétitives, les entreprises doivent
adapter leurs structures et leurs stratégies aux contraintes du
marché qui devient de plus en plus flexible et dynamique. Face à
ces pressions, elles doivent trouver des moyens pour améliorer leur
efficience et, selon leur positionnement sur le marché, faire face
à différents enjeux, tels que : optimiser leur fonctionnement,
améliorer la rentabilité, renforcer un positionnement
compétitif, faciliter l'application d'une réglementation.
La gestion des processus métiers ou Workflow permet
d'adresser ces enjeux par la formalisation et l'optimisation des processus de
l'entreprise et par leur pilotage afin d'en améliorer
l'efficacité.
Le Workflow est une spécification des opérations
de réalisation qui existent dans une organisation. Cette
spécification doit tenir en compte plusieurs aspects, tels que la
chronologie des opérations, la complexité et la nature de ces
opérations, la disponibilité et la localisation des ressources
nécessaires à ces opérations, la nature des participants
à ces opérations, etc.
L'utilisation croissante des systèmes de gestion de
Workflow dans ces entreprises exprime leur importance indéniable comme
outil d'automatisation des procédés de production. Ils
permettent, en particulier, de décrire explicitement les méthodes
de travail réalisant un procédé, de les
expérimenter, de mesurer leur qualité et de les optimiser afin de
pouvoir assurer l'amélioration et la réutilisation des
procédés. Cependant un système de gestion de Workflow doit
être facile d'emploi, et permettre, par un environnement de
modélisation graphique de créer, de déployer et
d'optimiser rapidement des processus métiers nouveaux ou existants en
réponse à l'évolution des contraintes et des
activités de l'entreprise.
C'est face à ces soucis liés à la
performance et aux limites que présente le système de gestion de
Workflow existant dans son progiciel « Sunshine software », que la
société EXTEL a décidé de mettre en place un
système de gestion de Workflow graphique.
Après une présentation de la structure d'accueil
et du sujet, nous donnerons un aperçu sur le Workflow et les
systèmes de gestion de Workflow puis nous procéderons au choix
d'une méthode d'analyse et de conception avant de présenter le
système existant. Nous terminerons par l'analyse proprement dite et la
présentation de la solution mise en oeuvre.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
8
Chapitre 1
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page 9
Présentations générales
I. Présentation de EXTEL : Structure
d'accueil
1. Société
Fort de 20 ans d'expérience, le Groupe EXTEL est bien
ancré dans son rôle d'éditeur de progiciels d'assurance sur
le marché européen et reconnu en tant que tel. D'envergure
internationale, le Groupe EXTEL regroupe dans son portefeuille clients des
grands comptes de l'assurance européenne et mondiale. Sa gamme de
produits et ses services répondent parfaitement aux enjeux du secteur de
l'assurance vie et de la finance. EXTEL est aujourd'hui le spécialiste
européen de l'édition de progiciels d'assurance.
EXTEL est Fondée en 1986 par Monsieur.
Louis-Gérard Brosse, le Groupe EXTEL est composé de 3
sociétés :
? EXTEL sise à Paris
? EXTEL International sise au Luxembourg ? IRCI-LOG sise
à Paris
Au travers de leurs différentes activités
d'édition de progiciel, de consulting, de prestations de services et de
formation, ces 3 entités rassemblent une large gamme de
compétences au service du secteur assurantiel. EXTEL a toujours fait le
choix d'investir régulièrement pour offrir à ses clients
et à ses prospects des solutions nouvelles, toujours avec une approche
prudentielle.
2. Stratégie
Depuis 20 ans, EXTEL a évité les impasses
technologiques. Son choix en 1999 de la technologie XML pour son premier module
FrontOffice montre sa capacité à discerner les technologies
porteuses. Trois points sont primordiaux et dictent la ligne de conduite en
matière de Recherche et Développement :
? La pérennité
? La fiabilité et l'évolution avec
les nouvelles technologies
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
10
? La couverture fonctionnelle
La stratégie d'EXTEL a été depuis
l'origine l'innovation et la sécurité dans les logiciels. C'est
sa manière de participer à l'amélioration de la
profitabilité de ses clients. Ses techniques de développement
assisté par ordinateur et son organisation ont permis une
efficacité et une qualité accrues. Grâce à une
philosophie basée sur le respect et la satisfaction du client, EXTEL a
toujours élaboré des solutions évolutives. En
préservant les investissements de ses clients, EXTEL pérennise sa
relation avec eux sur le long terme. Ses solutions s'appuient sur les
technologies innovantes et reconnues du marché comme Java et XML.
Afin de toujours mieux suivre son positionnement par rapport
à son domaine d'activité et ses confrères, le Groupe EXTEL
a fait le choix d'être audité régulièrement par la
Banque de France. Il en ressort des ratios dans la moyenne du secteur. Le ratio
d'investissement est quant à lui très nettement au-dessus. Cela
montre l'implication du Groupe EXTEL dans la recherche constante
d'amélioration et d'anticipation de ses produits.
EXTEL est un éditeur spécialisé dans
l'assurance de personnes, ce qui lui permet d'offrir toutes les
compétences métiers associées à cette discipline.
Disposant d'une équipe dédiée, les intervenants d'EXTEL
vous proposent aussi d'assister dans les domaines suivants : ? Conseil
? Création et hébergement de site web
? Création de PDF dynamiques
? Formation
Depuis 20 ans, EXTEL déploie tout son talent dans la
conception et le développement de solutions innovantes pour l'assurance
et la finance.
3. Solutions
Editeur européen majeur de solutions progiciel, EXTEL
dispose d'un large panel de solutions métiers afin de toujours mieux
répondre aux attentes des acteurs du marché. Quel que soit le
domaine métier concerné et les préférences
technologiques, EXTEL saura orienter ses clients et ses prospects vers la
solution la plus adéquate, avec toujours en arrière fond, une
parfaite connaissance de leur métier. Les solutions proposées
sont :
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
11
a. Sunshine Software
Première suite Progiciel intégralement natif
Internet, Sunshine Software est la troisième gamme progiciel du Groupe
EXTEL. Sunshine est opérationnel dans les domaines de gestion en
Individuel et Groupe : Epargne, Rentes, Retraite, Fonds de Pension
Internationaux, Prévoyance, Santé
b. Sunshine Life
Le progiciel Sunshine Life rassemble
l'intégralité des rouages métiers hérités
des progiciels OPUS 2000 Life et EXTEL Vie, garantissant une couverture
fonctionnelle et une maturité acquises depuis 20 ans. La
véritable force du progiciel Sunshine Life, c'est avant tout sa nouvelle
approche de l'ergonomie et de l'organisation du travail avec une
simplicité inégalée.
c. Sunshine Framework
Conçu au départ pour permettre au Groupe EXTEL
de développer sa nouvelle suite progiciel Sunshine Software, il a
été décidé de commercialiser Sunshine Framework
pour proposer aux sociétés qui souhaitent progresser dans la voie
de la modernisation et personnalisation de leurs applicatifs, de trouver un
outil éprouvé dans leur domaine.
d. Sunshine LIA
EXTEL s'est associé à MaplesoftTM, leader dans
l'édition de logiciels mathématiques, pour proposer Sunshine LIA,
le Laboratoire d'Ingénierie Actuarielle. Grâce à une
infrastructure mathématique complète pour le Web compatible
SOA1, EXTEL et MaplesoftTM mettent à disposition des services
actuariels et techniques les outils et les technologies les plus avancés
pour les simulations et la tarification de produits.
e. Opus 2000 Life
Orienté Assurance de Personnes, le progiciel OPUS 2000
Life est une solution robuste et éprouvée opérant sur un
system i5 d'IBM. OPUS 2000 Life apporte à ses acquéreurs une
extrême souplesse de paramétrage. Ses rouages englobent
l'intégralité des fonctionnalités nécessaires
à une compagnie d'assurance (ou à une mutuelle) qu'il s'agisse de
paramétrage produit, production de contrats, gestion des sinistres, des
réseaux d'intermédiaires, de la comptabilité
auxiliaire...
1 SOA : Architecture Orientée Services
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
12
f. IRS
Outil de reporting et statistiques spécialement
conçu pour les managers et les décisionnaires, IRS (Integrated
Reporting System) fournit immédiatement toutes les informations
indispensables à la prise de décision, en fonction de 3 axes :
Production, Prestations et Technique
g. Mutualix
Mutualix® est une solution informatique conçue en
collaboration avec des professionnels de l'assurance maladie. Lancé sur
le marché de la santé en 1985, le progiciel Mutualix®
propose aujourd'hui un périmètre fonctionnel des plus aboutis
dans les domaines liés à l'activité des mutuelles et
organismes gérant la couverture complémentaire santé,
quelle que soit leur taille.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
13
II. Présentation du sujet
Intitulé du sujet : «
Mise en place d'un système de Gestion de Workflow :
Paramétrage, suivi et représentation
graphique : Définition et représentation des états, des
traitements, des transitions et des enchaînements »
1. Problématique du sujet
Les entreprises perçoivent de plus en plus les
avantages qu'elles peuvent tirer de la maîtrise et de l'optimisation de
leur processus métier. Le Workflow est un outil qui apporte dans cette
optique une véritable aide à l'organisation, l'exécution
et l'optimisation d'un processus de travail. Les systèmes de gestion de
Workflow couvrent la modélisation des processus, leur implantation et le
contrôle de l'exécution de ces processus. La modélisation
est la phase la plus importante et doit aider à formuler d'une
manière structurée, efficace et conviviale une réponse
complète aux questions essentielles de l'organisation des processus de
l'entreprise. Pour cela l'utilisation d'un outil de modélisation
graphique facile d'emploi s'avère nécessaire voir même
indispensable car il permet d'avoir une compréhension visuel et un
apprentissage quasi-immédiat de l'organisation des processus.
Consciente des limites du système existant dans son
progiciel, la société EXTEL a opté pour la mise en place
d'un système de gestion de Workflow graphique.
2. Objectifs du sujet
Le système de gestion de Workflow qu'on doit
réaliser, devra permettre entre autres:
- Le paramétrage de Workflow d'une
fonctionnalité : Cette étape désigne la
modélisation de Workflow et doit se faire par une interface graphique.
L'utilisateur aura à sa disposition la liste des états et des
traitements qu'il doit ordonner et spécifier suivant les issus des
traitements et leurs transitions, les états vers lesquels le
système doit évoluer
- La représentation graphique d'un Workflow :
Cette tache permet la consultation
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
14
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
15
des Workflow modélisés avec l'outil. En
première vue nous devons avoir la représentation du Workflow
choisi avec des liens sur le graphe permettant de visualiser certains
détails de la modélisation.
- Le suivi d'un Workflow : L'interface de
suivi doit permettre la visualisation de l'avancement des dossiers de la
fonctionnalité. En bref Elle doit permettre de savoir l'état
d'exécution d'un dossier ou le nombre de dossiers d'un état.
« Mise en place d'un système de gestion
de workflow : Paramétrage, suivi et représentation
graphique » | Page 16
Chapitre 2
Théorie des Workflow et
des Systèmes de Gestion
de Workflow
I. Workflow ou Gestion des processus
1. Introduction au Workflow
Un Workflow est la modélisation et la gestion
assistée par ordinateur de l'accomplissement des taches composant un
processus administratif ou industriel, en interaction avec divers acteurs
(humains, logiciels, ou matériels) invoqués. Outil informatique
d'origine industrielle, le Workflow est l'adaptation de la Gestion
électronique de Document adjoint de la faculté à
gérer l'échange de messages. Le Workflow propose des solutions
d'optimisation et de rationalisation des flux d'informations ; que ces
informations soient associées à des documents, des
procédures ou des messages complémentant le système de
gestion électronique de documents et d'informations
A l'heure actuelle beaucoup de système de gestion de
Workflow (SGWF) sont utilisés ou en développement. Cela signifie
que le terme gestion de Workflow n'est pas simplement une nouvelle expression
à la mode. Ce phénomène de gestion de processus aura
certainement un fort impact sur la génération suivante de
systèmes informatiques.
2. Origines et motivations
- Origines :
Il est intéressant de considérer
l'évolution des systèmes informatiques au cours des quatre
dernières décennies pour prendre conscience de la pertinence
d'une gestion électronique de processus (Workflow) et apprécier
l'impact de la gestion de Workflow dans un avenir proche.
La Figure 2.1 ci-dessous présente le
phénomène de gestion de Workflow dans une perspective historique.
Cette figure décrit l'architecture d'un système informatique
classique en termes de composants. Dans les années
soixante, un système informatique était composé
d'un certain nombre d'applications autonomes. Pour chacune de ces applications,
une interface utilisateur et un système de base de données
spécifique étaient développés, chaque application
possédait donc ses propres routines pour interagir avec l'utilisateur,
stocker et récupérer les données. Dans les
années soixante-dix, le développement des SGBD a permis
d'extraire les données des applications. En utilisant les SGBD, les
applications ont ainsi été
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
17
libérées du fardeau de la gestion de
données. Dans les années quatre-vingts,
l'apparition de systèmes de gestion d'interface utilisateur
« User Interface Management Systems » (UIMS) a permis aux
développeurs d'application d'extraire l'interaction avec les
utilisateurs des applications. Enfin, les années
quatre-vingt-dix sont marquées par l'apparition de logiciels de
Workflow, permettant aux développeurs d'application d'extraire les
procédures de travail des applications. La Figure 2.1 fait
apparaître le système de gestion de Workflow comme une composante
générique pour représenter et manipuler les processus
d'entreprise.
Ainsi, à l'heure actuelle, beaucoup d'organisations
commencent à considérer l'utilité d'outils avancés
pour soutenir la conception et l'exécution de leurs processus
d'entreprise.
Figure 2.1 - Les systèmes de gestion de Workflow
dans une perspective historique - Motivations
L'intérêt accru pour la gestion des processus
d'entreprise s'explique par plusieurs faits. Tout d'abord, l'apparition de
philosophies de gestion comme la reconstruction de processus d'entreprise et
l'amélioration continue des processus a stimulé les organisations
à prendre conscience des processus d'entreprise. Le deuxième
élément motivant l'intérêt pour la gestion des
processus provient du nouveau postulat : les organisations actuelles doivent
être en mesure de proposer une large gamme de produits et de services
indexées sur l'actualité des demandes. Ceci induit une
augmentation du nombre de processus, de produits et de services à
l'intérieur des organisations, et en contrepartie une diminution de la
durée de vie des produits et des services. Tout cela entraîne en
conséquence une demande de flexibilité et de
réactivité accrue à l'entreprise qui ne peut être
prise en compte qu'au travers d'une gestion rigoureuse des processus.
En conséquence, les processus d'entreprise actuels sont
soumis à des changements fréquents. De plus, la complexité
de ces processus a considérablement augmenté.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
18
Tous ces changements de l'environnement des organisations, ont
fait des processus d'entreprise une préoccupation importante dans le
développement de systèmes informatiques. Des solutions de gestion
de processus existent dans ce domaine mais sont souvent ad hoc1. Il
est donc important de définir un modèle conceptuel et d'unifier
les techniques de modélisation actuelles. En conclusion il existe
aujourd'hui un réel besoin pour une nouvelle composante dans les
entreprises ; cette composante se nomme « Système de
gestion de Workflow ».
3. Domaines d'applications
Les Workflow ont de multiples applications dans le monde
d'aujourd'hui. L'évolution des processus organisationnels de
l'entreprise conduisent à utiliser cet outil. Il répond à
un besoin d'optimisation des processus de travail en termes d'utilisation des
ressources et de temps effectif.
Le Workflow est amené à jouer un rôle
important dans les entreprises du monde financier comme les systèmes
bancaires, les assurances (délivrer un prêt, opérer un
remboursement...). On peut l'étendre à tout processus de travail
cyclique dans le monde de l'entreprise.
On s'intéresse aussi à ses applications dans le
monde informatique, comme le processus de développement d'un logiciel ;
En intégrant l'aspect travail coopératif au sein du Workflow, on
peut lier l'intégration progressive des éléments d'un
logiciel avec l'organisation prévue. Le chef de projet dispose ainsi
d'un outil de contrôle sur l'avancement du projet et la cohérence
du système en termes de délais.
Les Workflow peuvent également être
utilisés dans des organisations autres que l'entreprise, comme dans le
monde médical : suivi du dossier médical d'un patient (on peut le
mettre à jour automatiquement selon les traitements médicaux
effectués), planification des opérations chirurgicales (salles
d'opérations, chirurgiens)...
On peut imaginer des applications des Workflow dans
l'éducation par exemple la mise en place de processus de contrôle
continu de l'apprentissage via le web.
1 Ad hoc : acte spécialement fait pour un objet
déterminé
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
19
4. Définitions de base du Workflow
Le sens du mot Workflow peut varier en fonction du contexte.
Pour plus de clarté, les définitions les plus communément
admises sur les concepts et les termes du Workflow sont rappelées ci
dessous.
L'idée première du Workflow est donc de
séparer les processus, les ressources et les applications, afin de se
recentrer sur la logistique des processus travail et non pas sur le contenu des
tâches individuelles. Un Workflow est donc le lien entre ces trois
domaines comme le précise la Figure 2.2.
Processus
SGWF
Ressources
Applications
Figure 2.2 - Environnement du système
Workflow
a. Définition d'un Workflow
Le Workflow est une technologie informatique ayant pour
objectif la gestion des processus d'organisations ou d'entreprises : les termes
suivants sont également employés pour qualifier cette technologie
« Système de Gestion Electronique de Processus », «
Gestion de Workflow » ou « Gestion de processus ».
Le Workflow est l'ensemble des moyens mis en oeuvre pour
automatiser et gérer les processus d'une organisation. Cette gestion est
rendue possible par la représentation sous forme d'un modèle, de
tout ou partie des processus considérés. Le Workflow doit ensuite
transcrire les modèles obtenus en une forme exécutable. Enfin,
ces modèles sont exécutés et gérés. Il est
ainsi possible de suivre l'évolution de leur état au fil du
temps. La gestion de processus inclut également, au cours de
l'exécution, la coordination et la synchronisation des différents
acteurs des processus en fonction de l'état actuel des
modèles.
Pour résumer, la gestion de processus permet donc
d'attribuer à chacun et au bon moment, les tâches dont il a la
responsabilité et de mettre à disposition les applications, les
outils et les informations nécessaires pour leurs réalisations.
Dans un contexte d'acteurs
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
20
humains, le Workflow permet de décharger les acteurs de
certaines tâches de gestion administrative, en leur laissant la
possibilité de se concentrer sur les contenus des tâches
techniques en rapport avec leurs compétences. De plus, le Workflow donne
la possibilité d'effectuer une activité de monitoring sur le
déroulement des Workflow de l'entreprise, permettant en particulier de
connaître, en fonction de la date, l'état des activités,
des acteurs, des applications et quelles sont les prochaines activités
planifiées.
En synthèse, La WfMC1 présente le
Workflow comme l'automatisation d'un processus d'entreprise, en
intégralité ou en partie, pendant laquelle on définit les
transmissions des documents, de l'information ou des tâches d'un
participant à un autre pour agir, selon un jeu de règles
procédurales. 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
Workflow.
b. Meta model
Le Workflow est basé sur un ensemble de concepts. La
WfMC a proposé un méta modèle de définition de
procédures, qui identifie les concepts de haut niveau dans la
définition de processus. Ce modèle permet de mieux
appréhender les concepts et leurs interrelations.
Figure 2.3- Méta modèle Workflow pour la
définition de Processus
1 WfMC : Coalition de Gestion de Workflow «
Workflow Management Coalition » fondée en 1993 par un regroupement
d'industriels de l'informatique, de chercheurs et d'utilisateurs,
associée à l'essor du développement des workflows
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
21
Le méta modèle, présenté ci
dessus, identifie un ensemble 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éta modèle peut être enrichi
par les développeurs de systèmes, il peut également
être utilisé à des fins d'échanges entre
différents systèmes Workflow.
c. Concepts et Terminologies Workflow
Les principaux termes associés aux Workflow
proposés par la WfMC sont présentés dans le diagramme du
méta modèle Workflow ci-dessus, ce diagramme permet
également de mettre en évidence leurs interrelations. Les termes
présentés ci-dessous couvrent les notions plus importantes
appartenant au Workflow et à son lexique.
Procédure Workflow (Workflow Process)
Une procédure Workflow est une procédure
contrôlée par un Workflow. Une procédure est
composée de plusieurs activités enchaînées pour
représenter un flux de travail. Une procédure possède une
structure hiérarchique et modulaire, en l'occurrence une
procédure peut donc être composée de sous procédures
et d'activités. Les sous-procédures peuvent être
composée elles mêmes de procédures manuelles ou de
procédures Workflow.
Activité (Process Activity)
Une activité est une étape d'un processus au
cours de laquelle une action élémentaire est
exécutée. On désigne par « action
élémentaire » (ou tâche) une activité qui n'est
plus décomposable en sous-procédures. La WfMC distingue une
« activité manuelle », qui n'est pas contrôlée
par le système Workflow, et une « activité Workflow »
qui est sous le contrôle du Workflow. Un exemple d'une activité
manuelle est l'ouverture d'un courrier. Une activité Workflow peut
être le remplissage d'un formulaire électronique. Il existe donc
des exemples d'activités manuelles intégrables dans un
Workflow.
L'activité Workflow peut être
présentée comme l'intersection entre une ressource humaine ou
matérielle et un bon de travail dans le cadre de l'exécution
d'une tâche. Dans cette représentation, une ressource du
modèle organisationnel est donc exigée pour qu'une tâche
puisse être instanciée en activité et allouée
à un participant de Workflow.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
22
Acteur, Ressource (Workflow Participant)
Un acteur est une entité du modèle
organisationnel participant à l'accomplissement d'une procédure.
L'acteur est chargé de réaliser les activités qui lui sont
attribuées via le ou les rôles qui lui sont définis dans le
modèle organisationnel. Les autres dénominations courantes dans
la littérature de cette entité sont « ressource »,
« agent », « participant » ou « utilisateur ».
L'acteur peut être une ressource humaine ou matérielle (machine,
périphérique informatique...).
Les ressources sont organisées en classes dans le
modèle organisationnel. Ces classes sont des groupes de ressources
possédant des propriétés communes. Une classe est
basée sur : - Rôle : défini ci dans le
point suivant.
- Groupe : cette classification est
basée sur l'organisation (département, équipe,
unité).
Rôle (Role)
Un rôle décrit en général les
compétences d'un acteur dans le processus ou sa position dans
l'organisation. Un rôle est associé à la réalisation
d'une ou de plusieurs activités. Plusieurs acteurs peuvent tenir un
même rôle.
La WfMC distingue deux types de rôles :
- Les rôles organisationnels
définissent un ensemble de compétences qu'un acteur
possède. Ce rôle définit la position de l'acteur dans une
organisation.
- Les rôles procéduraux
définissent une liste d'activités qu'un acteur est en
capacité d'exécuter.
Il est à noter que certains travaux ne
différencient pas les notions d'acteur et de rôle et ne parlent
que d'acteur. Cette opinion semble restreindre la clarté et la
flexibilité des modèles Workflow.
Données (Workflow Relevant Data)
Une donnée pertinente pour les procédures est
une information en rapport avec la réalisation des activités (en
définition de la tâche, en entrée ou en sortie). Elle peut
constituer l'objectif d'une tâche (manipulation de la donnée et
définition de l'état de la procédure), être un
élément essentiel pour activer les transitions d'état
d'une instance Workflow ou être
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
23
générée par la tâche et ainsi
intervenir dans la détermination de la prochaine activité
à déclencher. Ces données sont en général
des objets au sens purement informatique mais peuvent également
être une représentation d'objets physiques.
Notons qu'il existe deux autres types de données
utilisées hors de la gestion de procédures :
- Données de contrôle (Control Data) :
données gérées et utilisées par le système
Workflow et les moteurs Workflow.
- Données applicatives (Applicative Data) : données
propres aux applications, le système de gestion de Workflow n'y a pas
accès.
Application externe (Invoked Application)
Une application externe est une application informatique dont
l'invocation est nécessaire à la réalisation de la
tâche ou à l'exploitation des résultats
générés avant de déclencher la tâche suivante
ou de recommencer cette première. On tiendra compte de l'allocation de
ressources, si l'application n'est pas uniquement informatique. Il faut
différencier les outils, qui sont eux directement interfacés par
le système Workflow, sans l'intervention d'une ressource du
système Workflow.
d. Concepts secondaires
Le paragraphe précèdent a introduit les concepts
Workflow fondamentaux. Afin de présenter plus en détails le
management de systèmes par Workflow, nous rappelons ici quelques
définitions complémentaires.
Cas de procédure (Process instance,
Workflow Definition Instance)
Un cas est une instanciation d'un modèle de
procédure Workflow. Un cas est à la mise en oeuvre d'un Workflow
dans une situation spécifique, donc avec des paramètres
particuliers. Par exemple, considérons un Workflow de remboursement des
déplacements d'un représentant. Un cas de ce Workflow est le
remboursement des frais de voyage de M. Kane, du 12 au 18 Avril 2006.
L'instanciation d'un Workflow donne également lieu à
l'instanciation des activités du Workflow, il s'agit alors d'instances
d'activités, on parle également de tâche et
d'activité (pour l'instance associée).
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
24
Condition de transition (Transition Condition)
Une condition de transition est le critère de
progression régissant 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. Une condition
peut s'exprimer sous la forme d'une expression logique ou sous la forme d'un
événement. Ces conditions sont soit intégrer dans les
modèles de procédure, soit calculées par le moteur de
Workflow au cours de l'exécution pour déclencher le modèle
de procédure suivant adéquat.
Itinéraire, Transition, Enchaînement
(Route, Transition)
Les itinéraires correspondent au contrôle de
l'enchaînement des activités : il peut être choisi des
routes séquentielles, parallèles, en disjonction ou en
synchronisation entre les activités. Le contrôle est en
général représenté sur un modèle Workflow
à l'aide de contrôleurs de flux inspirés des
opérateurs logiques associés à des contraintes de
synchronisation portant sur les données pertinentes. La WfMC identifie 4
types basiques répertoriés Figure 2.4.
Figure 2.4 - Réseau de Processus
Bon de travail (Work item)
Un bon de travail est la représentation informatique du
travail à effectuer par un acteur du Workflow dans le cadre d'une
instance d'activité. Ce bon de travail peut également être
l'interprétation d'un objet physique ou informatique se
déplaçant dans la procédure Workflow dont les
activités qu'il traverse le transforment successivement. Ce
procédé peut
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
25
être illustré par la transformation de
matière première en produit fini.
Corbeille, Liste des bons de travail ou des
tâches (Worklist) La liste des bons de travail,
contient la liste des bons de travail à exécuter par un acteur du
Workflow sur une activité dans le cadre de son rôle, cette liste
correspond a un échéancier d'événements à
traiter pour la ressource en terme de modélisation & simulation.
5. Dimensions
Associé aux définitions
précédentes, il a été défini une
représentation tridimensionnelle des systèmes Workflow (Figure
2.5).
Figure 2.5 - Dimensions des systèmes
Workflow
La Figure 2.5 donne une représentation
tridimensionnelle d'un Workflow : avec une dimension de cas,
une dimension de processus et une dimension de
ressource. La dimension de cas représente l'instanciation du
Workflow, chaque cas est un modèle à simuler et traiter
individuellement. Les cas ne s'influencent donc pas directement. Ils peuvent
éventuellement s'influencer indirectement via les ressources et les
données. Le processus de Workflow est spécifié dans la
dimension de processus, c'est-à-dire, la définition des
tâches et de leur enchaînement. Enfin, dans la dimension de
ressource, les ressources sont regroupées en rôles et en
unités organisationnelles. En résumé, nous pouvons donc
visualiser un certain nombre de termes Workflow dans la vue tridimensionnelle
de la Figure 2.5. En particulier, une entité de travail est
définie par la coordonnée cas + tâche et une
activité par le cas + la tâche + la ressource. Cette
représentation met en relief la gestion de Workflow comme le lien entre
les cas, les tâches et l'organisation.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
26
II. Les Systèmes de gestion de Workflow
1. Description des Systèmes de Gestion de
Workflow
Après avoir présenté la terminologie
Workflow, il est maintenant possible de présenter le principe de
fonctionnement des systèmes Workflow. A un haut niveau, ce type de
système est composé de trois parties fonctionnelles. La Figure
2.6 illustre un Système de gestion de Workflow et les relations entre
ses différentes fonctions.
Figure 2.6 - Caractéristiques du système
Workflow
a. Build time
Cette première phase permet la définition et la
modélisation des procédures Workflow, elle est nommée
build time. Elle est principalement composée d'un outil permettant la
modélisation des Workflow dans un formalisme existant ou
propriétaire à partir d'une analyse de procédures
d'entreprises, il est à noter que les outils actuels
préfèrent une description graphique. Un deuxième composant
transcrit les modèles obtenus dans une définition des
procédures « exécutables », c'est à dire
compréhensibles par la partie chargée de l'exécution.
Certains systèmes permettent en retour de la partie run time des
modifications dynamiques de la structure de définition de
procédures comme indiqué sur la Figure 2.6.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
27
b. Run time
L'environnement d'exécution (ou run time) a
l'entière gestion des modèles de Workflow établis dans la
première partie. Cette gestion comprend l'exécution des Workflow
avec un simulateur mais aussi la distribution des tâches aux rôles
appropriés en cours d'exécution, la mise à disposition de
l'ensemble des données et outils nécessaires, la supervision et
le contrôle, etc.
Plus en détails, cette partie se décline en sous
composants, introduits ci dessous :
Le Moteur de Workflow qui est chargé de la Gestion des
Procédures à travers la simulation de leurs évolutions.
Le gestionnaire des listes de tâches, chargé de
distribuer les activités dans les listes des acteurs en fonction de
leurs rôles.
Les listes de tâches, qui sont les listes
associées à chaque rôle dans lesquelles le moteur place les
tâches à réaliser. Les tâches sont classées
par priorité ou par date avec les données et les outils à
utiliser de façon appropriée.
Les outils d'administration et de contrôle suivent le
déroulement des procédures Workflow, elles peuvent fournir
l'état actuel des composantes du Workflow et donner l'ordre de modifier
le modèle de procédures.
c. Utilisateurs, outils et applications
La troisième phase concerne l'ensemble des outils et
des fonctions d'API qui permettent au système Workflow de s'interfacer
avec des ressources humaines, des applications informatiques extérieures
et d'autres systèmes Workflow.
2. Model de référence des SGWF
Le modèle de référence, Figure 2.7,
présente l'architecture générale de l'environnement
proposée par la WfMC, il identifie les interfaces couvrant cinq domaines
de fonctionnalités entre le système Workflow et son
environnement.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
28
Figure 2.7 - Model de référence
Workflow
a. Interface avec les Outils de définition de
procédures
Cette interface, située entre les outils de
modélisation/définition et le logiciel de gestion du Workflow
pendant l'exécution, est nommée interface d'import/export de
définition de processus. Cette interface définit le format
d'échange et d'appels des APIs, qui permettent l'échange
d'informations de définition de procédures sur une
variété de médias d'échange : physiques ou
électroniques. Cette interface permet l'échange d'une
définition de processus complète ou d'un sous-ensemble. Par
exemple le changement de définition d'un ensemble de procédures
ou plus simplement la modification des attributs d'une activité
particulière dans une définition de procédures.
b. Interface avec les applications clientes Workflow
La liste des tâches (Worklist) à exécuter
par une ressource est généralement définie et
gérée par le service d'exécution du Workflow. Cette liste
doit pouvoir déclencher des appels à des applications clientes
diverses et des ressources. La solution retenue pour respecter cette exigence,
consiste à encapsuler la variété d'application qui peut
être utilisée derrière un jeu standard d'API (le WAPI
Workflow Application Programming Interface). Ce jeu permet ainsi d'utiliser une
communication standardisée entre les applications clientes, le moteur de
Workflow et les Worklist, indifféremment de la nature de
l'implémentation réelle des produits clients.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
29
c. Interface avec les applications invoquées
Il est évident que le système Workflow ne peut
pas intégrer l'invocation automatique de toutes les applications qu'il
peut être amené à utiliser pendant l'exécution d'un
Workflow. Par exemple les applications dont les données sont fortement
typées. Dans ce cas un composant externe supplémentaire,
nommé agent d'application, est ajouté, il est chargé de la
traduction des informations dans un format compréhensible par le
standard WAPI.
Dans le cas le plus simple, l'invocation d'application est
traitée localement par un moteur de Workflow, mais les applications
invoquées peuvent être utilisées par plusieurs moteurs de
Workflow et peuvent se situer sur des machines distantes, il convient donc de
définir un format commun d'utilisation des ces applications entre les
Workflow dans le but de communiquer correctement et de synchroniser l'appel
à ces applications.
d. Interface avec les autres Workflow
Un des objectifs de la normalisation dans la définition
de Workflow est de pouvoir transmettre des bons de travail entre deux
systèmes Workflow conçus par des concepteurs de systèmes
Workflow différents. Trois principaux types
d'interopérabilité ont étés identifiés :
- Workflow chaînés : La dernière
activité d'un Workflow A doit pouvoir fournir un item à la
première activité d'un Workflow B.
- Workflow hiérarchiques : une activité d'un
Workflow A doit pouvoir être vu comme un Workflow B.
- Workflow Peer to Peer : Une procédure globale est
composée d'activités gérées en partie par un
Workflow et en partie par un autre Workflow, sans système de supervision
de la procédure complète.
- Workflow Synchronisés : Deux Workflow
s'exécutent en parallèle et doivent pouvoir se synchroniser sur
certaines activités.
Pour résumer, il est possible d'identifier deux aspects
principaux nécessaires à l'inter fonctionnement de Workflow :
· L'interprétation commune de la définition
de procédures (ou d'un sous-ensemble).
· L'appui pendant l'exécution de l'échange
des divers types d'information de contrôle et le transfert des
données appropriées et/ou d'applications entre les services
d'exécution Workflow différents.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 30
e. Interface avec les outils de contrôle et
d'administration
L'objectif de cette interface est de permettre à un
logiciel de Monitoring de Workflow de s'interfacer avec plusieurs Workflow
différents et ainsi regrouper la supervision d'un ensemble de
systèmes Workflow dans un logiciel.
L'interface 5 permet à une application de gestion
indépendante d'interagir avec des Workflow de différents
domaines. L'application de gestion peut aussi se charger d'autres fonctions de
gestion, au-delà de celles-ci. Par exemple, elle peut aussi gérer
des définitions de procédures de Workflow, agissant comme un
dépôt d'information commun à plusieurs systèmes et
distribuant des définitions de processus aux divers Workflow via des
opérations au travers de leurs interfaces 1.
Malgré cela, des scénarii
d'implémentations moins modulaires sont aussi envisageables; par exemple
l'application de gestion peut être une partie intégrante du
service d'exécution.
3. Classification des systèmes Workflow
Il n'existe pas de classification commune des systèmes
Workflow dans la littérature, reconnue par l'ensemble de la
communauté Workflow. Ceci étant essentiellement dû au
nombre important de critères de classification qu'il est possible de
retenir. En effet, les spécialistes adoptent différents points de
vue par rapport à la notion de Workflow, les critères qui en
découlent varient donc en fonction de leurs perceptions des
caractéristiques présentées par ces systèmes
Workflow. Ainsi, il existe plusieurs classifications, permettant de
sélectionner un outil de gestion de Workflow avec différents
« éclairages » sur le sujet.
Malgré ce manque d'unité, la classification
proposée par McReady S1, distingue quatre catégories
de Systèmes Workflow. La figure 2.8 présente ces
différentes classes selon deux axes : Approche et Structure.
1 McReady S. « Workflow Software »,
Computer World 1992
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 31
Figure 2.8 - Différentes classes des
systèmes Workflow
a. Processus collaboratifs
Cette première classe est axée sur la
communication et sur le partage d'information. Les systèmes
collaboratifs sont définis pour supporter le travail en groupe, dans le
cadre de la conception, de la gestion de projet ou de la résolution de
problèmes faisant appel à plusieurs niveaux d'expertise. Ces
systèmes permettent de réunir les intervenants d'un projet autour
d'un objectif commun, les clients de la procédure y étant souvent
eux-mêmes directement associés, les logiciels employés sont
le plus souvent des groupwares. Les tâches des procédures
gérées sont le plus souvent complexes et leur réalisation
implique l'intervention de ressources aux compétences très
spécifiques pour une forte valeur ajoutée. D'un autre
coté, l'enchaînement des activités des procédures
à traiter est faiblement structuré et peu
répétitif. De part la faible structure de ces processus, ils ne
font pas partie ou se situe à la frontière de ce que l'on
considère comme la « sphère » Workflow comme le
précise la figure 2.8.
b. Workflow administratif
Les systèmes Workflow administratifs (General Purpose
Workflow Management Systems) ont pour objectif de décharger les
ressources d'une entreprise des tâches administratives. En effet ces
procédures sont répétitives, fortement prédictibles
et les règles d'enchaînement des tâches sont très
simples et clairement définis ; ces procédures sont donc
aisément automatisables, évitant ainsi un travail fastidieux
où peuvent naître des erreurs souvent humaines. Les
systèmes Workflow administratifs permettent de lier à une
tâche
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 32
administrative, les documents et les informations
nécessaires à la réalisation de cette tâche par un
acteur humain. Ces systèmes gèrent également le routage
des documents et le remplissage de formulaires. La gestion par Workflow de
procédures administratives permet un gain de l'ordre de 5% à 10%
en termes de productivité et de 30 à 90% en termes de
délais. Enfin une dernière raison de l'automatisation de ce type
de procédures en Workflow provient du fait que ces procédures
possèdent une structure statique et ne sont donc pas souvent assujetties
à modifications car elles possèdent une longue durée
d'utilisation.
c. Workflow de production
Les systèmes Workflow de production impliquent des
procédures prévisibles et assez répétitives. Leurs
principales différences avec les Workflow administratifs résident
dans la complexité des tâches et de la structure des
procédures, dans leur capacité à faire appel à des
informations provenant de systèmes d'information variés et dans
l'enjeu que représente leur réussite. En effet, la
procédure Workflow correspond directement au travail effectué par
l'entreprise. En d'autres termes, la performance de l'entreprise est
directement liée à l'exécution de la procédure
managée par le Workflow. C'est par exemple le cas des organismes
financiers, des compagnies d'assurances, des usines de production
manufacturières. La réalisation des procédures est donc
associée à une forte valeur ajoutée et un volume
d'informations traitées important.
La complexité des procédures traitées
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 informatiques, 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 procédures traitées sont assez
répétitives, elles sont susceptibles d'être
modifiées plus souvent que les procédures administratives, car
associées à la modification des objectifs du métier. Les
systèmes Workflow de production doivent donc pouvoir évoluer. Par
ailleurs, l'exécution de certaines procédures ne peut pas
toujours se poursuivre de manière automatisée, suite à
l'occurrence d'un ou de plusieurs événements qui font aboutir le
système dans un état particulier. Dans ce cas, il est
nécessaire de faire intervenir des acteurs humains pour la prise de
décision. Pour ce faire, le système Workflow de production peut
faire appel à un autre système, de type collecticiel ou un autre
système Workflow ad hoc, qui servira d'interface pour l'exécution
dirigée par un acteur humain de la suite de la procédure. Ce type
de
Workflow est dit « composite »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 33
d. Workflow adaptable ou Workflow ad hoc
L'impossibilité pour les systèmes de gestion de
Workflow traditionnels de traiter les différents changements dynamiques
dans les flux de travail est une limite à dépasser. A ce titre,
il a été introduit les concepts de Workflow adaptable et de
Workflow ad hoc. La nuance entre ces deux nouveaux termes provient du fait
qu'ad hoc désigne un acte spécialement fait pour un objet
déterminé alors qu'adaptable prévoit un changement
définitif de la procédure.
Les Workflow ad hoc se situent à la frontière
gauche de la représentation figure 2.8 dans la « sphère
» Workflow adaptable. Ils régissent des procédures dont la
structure est déterminée pendant l'exécution en fonction
des décisions humaines prises suite à la réalisation d'une
tâche, plus concrètement, la structure se construit par pas en
suivant le rythme de l'exécution. En effet, la réalisation d'une
procédure non structurée peut impliquer à chaque fois
l'exécution d'un nouvel enchaînement des tâches, voire la
création de nouvelles tâches. Il n'y a pas a priori de persistance
de l'enchaînement de ces tâches.
Les Workflow adaptables sont, quant à eux, des
supports comparables aux Workflow de production classiques possédant une
structure préétablie, mais pouvant traiter certains changements
de structure « en ligne ». Ces changements peuvent aller des
changements individuels/ad hoc (gestion d'exception), c'est à dire d'un
aiguillage pour déterminer l'activité suivante, jusqu'à
une nouvelle conception par BPR1 de processus. En conclusion, ils
ont une action globale pouvant inclure la définition du Workflow ad
hoc.
1 BPR : Business Process Reengineering : approche
visant à repenser les processus d'affaires de l'entreprise et à
les rendre plus efficaces.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
34
« Mise en place d'un système de gestion
de workflow : Paramétrage, suivi et représentation
graphique » | Page 35
Chapitre 3
Les méthodes d'analyse
et de conception
L'analyse permet d'avoir une vision claire et rigoureuse du
problème posé et du système à réaliser en
déterminant ses éléments et leurs interactions. A ce
niveau l'accent est mis sur une investigation du problème et des
exigences, plutôt que sur une solution. L'analyse permet de voir les
résultats attendus en termes de fonctionnalités, de performance,
de robustesse, de maintenance, de sécurité,
d'extensibilité, etc.
Quant à la conception, elle permet de décrire
de manière claire le fonctionnement du système le plus souvent
à l'aide d'un langage de modélisation pour faciliter la
réalisation.
A ce niveau l'accent est mis sur une solution conceptuelle
qui satisfait aux exigences plutôt que sur une implémentation qui
consiste à la réalisation du programme conformément aux
critères définis dans les phases d'analyse et de conception.
I. Les approches de méthodes d'analyse
Les méthodes d'analyse peuvent être classées
en trois grandes familles :
? Les méthodes cartésiennes ;
? Les méthodes systémiques ;
? Les méthodes orientées objet.
a. Les méthodes cartésiennes ou
fonctionnelles
Le processus de modélisation débute par
l'identification d'une fonction globale. Au vu de la règle de division,
on procède ensuite à une découpe cartésienne
(fonctionnelle et hiérarchique) des processus et des flux
d'informations. On part du général pour aboutir au plus
particulier. Les difficultés sont alors graduées : du plus simple
au plus complexe (fonction globale du système).
Quelques règles méthodologiques doivent
également être observées : le principe du doute (se
défaire des opinions toutes faites, ne rien croire sans preuve
dûment perçue par soi-même) d'où la tentation de
précipitation à éviter ainsi que l'exhaustivité
pour bien connaître le sujet. Les avantages de cette approche sont sa
simplicité et son appel au bon sens. Elle est en adéquation avec
la capture des besoins. Cependant, les efforts sont concentrés sur les
fonctions au détriment des données et les règles de
décomposition ne sont pas explicites.
b. Les méthodes systémiques
L'approche est inspirée d'une vision systémique.
Le système est vu comme une
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 36
structure avec un comportement. Cela nous conduit à
deux modélisations : celle des données et celle des traitements.
En effet, d'une part les données suivent des modélisations
conceptuelle et logique et, d'autre part, les traitements sont soumis aux
modélisations conceptuelle et organisationnelle. Les méthodes
systémiques font preuve d'une bonne prise en charge des données.
Les niveaux d'abstraction y sont bien définis : niveau externe, niveau
conceptuel, niveau interne. A chaque niveau, le système comporte tous
les caractères du niveau inférieur. Le principal souci demeure le
manque de cohérence entre données et traitements, leur
étude séparée conduisant à un certain
décalage lors de la mise en place du modèle physique.
c. Les méthodes objets
Elle est née de la prise de conscience de l'importance
d'une méthode spécifiquement objet : il était
impératif de faire évoluer l'approche systémique vers une
plus grande cohérence entre les objets et leurs comportements en
structurant un système sans pour autant centrer l'analyse sur les
données ou les traitements mais sur les deux. Le système est
alors considéré comme un ensemble d'objets en interaction et
ayant chacun des caractéristiques comportementales et un but.
Ainsi, une méthode objet permet de définir le
problème à haut niveau, d'identifier et d'organiser les concepts
du domaine d'application sans se préoccuper de l'implémentation
(indépendance totale par rapport aux langages de programmation). Ce
processus est une manière de penser (et non une technique de
programmation). Il représente ainsi un outil permettant de
définir un problème de façon graphique, afin par exemple
de le présenter à tous les acteurs d'un projet (dont les clients
qui ne sont pas forcément des experts en un langage). Une méthode
objet est donc une méthode d'analyse permettant une
représentation standard stricte des concepts abstraits (la
modélisation) afin de constituer un langage commun aisément
compréhensible. Une autre propriété essentielle de
l'approche orientée objet est sa capacité à réduire
les distorsions entre système informatique et monde réel.
Au vu des caractéristiques des trois familles de
méthodes, nous avons opté pour l'approche orientée objet
compte tenu de certains avantages essentiels qu'elle présente :
? sa maturité : étant la dernière
née, elle connaît les atouts et limites des autres approches et
s'en sert pour se bonifier ;
? la combinaison (prise en charge commune) des données
et des traitements qui constituait la limite majeure des méthodes
systémiques ;
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 37
· l'abstraction par rapport aux outils
d'implémentation ;
· la représentation du monde réel dans
tous ses aspects (statiques, dynamiques et fonctionnels) ;
· les possibilités de réutilisation (on ne
s'attarde pas sur un problème déjà efficacement
résolu) et d'évolutivité (paramètre primordial
à prendre en compte).
Les trois méthodes objets prédominantes OMT
(Object Modeling Technique) de James Rumbaugh, Booch de Grady Booch et OOSE
(Object Oriented Software Engineering) d'Ivar Jacobson ont été
à la base de l'unification des démarches de cette approche en
donnant naissance à un formalisme unique : UML. Ce dernier va fortement
influencer le choix de notre méthode.
II. Présentation du langage UML
UML (Unified Modeling Language, « langage de
modélisation objet unifié » en français) est un
langage de description standard intégrant les avantages des
différentes méthodes composantes (ainsi que celles d'autres
analystes). Il a été normalisé par l'OMG en 1997.
Rapidement devenu un standard incontournable, il donne une définition
plus formelle à l'approche objet et lui apporte la dimension
méthodologique qui lui faisait défaut.
Les créateurs d'UML ont tenu à ce qu'il tire le
meilleur profit de ses principales méthodes composantes dont les
caractéristiques suivantes sont confirmées :
· OOSE : expressive pour l'analyse des besoins grâce
aux « cas d'utilisation » ;
· OMT : expressive pour l'analyse et la conception de
systèmes à base de données ;
· Booch : expressive durant les phases de design et
d'implantation des projets.
UML opte pour l'élaboration des modèles
plutôt que pour une approche qui impose une barrière stricte entre
analyse et conception : les modèles des deux activités ne
diffèrent que par leur niveau de détail, il n'y a pas de
différence dans les concepts utilisés.
Il n'introduit pas d'éléments de
modélisation propres à une activité : le langage reste le
même à tous les niveaux d'abstraction. L'élaboration
encourage une approche non linéaire facilitant les retours en
arrière entre niveaux d'abstraction différents.
Cependant, notons que UML a été construite afin
de standardiser les artéfacts de développement (modèles,
notation, diagrammes) sans pour autant standardiser la démarche, le
processus de développement. De ce fait, UML est une notation, un langage
qui permet de
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 38
représenter des modèles mais il ne définit
pas leur processus d'élaboration. En résumé, c'est
un formalisme et pas une méthode.
? Démarche préconisée
Les concepteurs d'UML préconisent l'utilisation d'une
démarche qui soit :
- itérative et incrémentale,
- guidée par les besoins des utilisateurs du
système,
- centrée sur l'architecture logicielle.
* Itérative et incrémentale
Il est évident que, pour modéliser (comprendre et
représenter) un système
complexe, il vaut mieux procéder à une
étude par étapes. Cette démarche devrait aussi
s'appliquer au cycle de développement dans son ensemble,
en favorisant le prototypage.
Le but est de mieux maîtriser la part d'inconnu et
d'incertitudes des systèmes. Si
l'itératif s'est imposé, c'est parce qu'il
réduit la complexité de réalisation des phases, en
travaillant par approches successives et incrémentales. Il
est alors possible de présenter
rapidement aux utilisateurs des éléments de
validation. Chaque incrément ajoute de nouvelles
fonctionnalités. La difficulté réside dans
le fait de combiner au final les sous projets ou
incréments et de respecter leurs interdépendances
et la cohérence générale du produit
envisagé.
* Guidée par les besoins des utilisateurs
L'utilisateur est l'acteur principal lors de la
définition des modèles. L'objectif étant de
répondre aux besoins des utilisateurs du système
à concevoir, leurs besoins tracent les limites
et contours du futur système. Somme toute, ils
déterminent sa nature.
Lors du cycle de développement, tout reste basé
sur les exigences des utilisateurs :
- à la phase d'analyse, les besoins sont
clarifiés, affinés et validés ;
- lors de conception et de réalisation, on veille
à la prise en compte des besoins ;
- à la phase de test, on vérifie que les besoins
sont satisfaits.
* Centrée sur l'architecture logicielle
Une architecture adaptée garantit le succès d'un
développement. Elle décrit des choix
stratégiques qui déterminent en grande partie la
qualité du logiciel (adaptabilité,
performances, fiabilité, etc.). Kruchten1
propose différentes perspectives indépendantes et
1 Model de Kruchten d'après Philippe Kruchten
: model adopté dans le processus unifié
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 39
complémentaires qui définissent un
modèle d'architecture. Cette vue (« 4+1 ») a fortement
inspiré UML :
Vue comportement Vue déploiement
Vue logique
Vue utilisateur
Vue implémentation
Figure 3.1 : Vue 4+1 définie par
Kruchten
La vue logique se concentre sur
l'abstraction et l'encapsulation. Elle modélise les mécanismes
principaux du système, identifie les éléments du domaine
et les liens qui les unissent. C'est la définition du système vue
de l'intérieur. Elle explique comment peuvent être satisfait les
besoins des acteurs. Il s'agit du « comment ».
La vue des composants montre l'allocation
des éléments de modélisation dans des modules (fichiers
sources, bibliothèques dynamiques, bases de données,
exécutables, etc.). Elle identifie les modules qui réalisent
physiquement les classes de la vue logique. Elle renseigne sur l'organisation
des composants et leurs dépendances. Elle montre aussi l'organisation
des modules en sous systèmes.
La vue des processus est la vue temporelle
et technique. Elle montre la décomposition du système en termes
de processus, les interactions entre les processus (communication), la
synchronisation des activités parallèles.
La vue de déploiement décrit
les ressources matérielles et la répartition du logiciel dans ces
ressources. Elle précise la disposition, la nature physique et les
performances des ressources ainsi que l'implantation des modules principaux sur
les noeuds du réseau et les exigences en termes de performance.
La vue des besoins des utilisateurs guide
toutes les autres vues et les unifient. Elle définit les besoins des
clients et centre la définition de l'architecture du système sur
la satisfaction de ces besoins. A l'aide de scénarios et de cas
d'utilisation, cette vue conduit à la définition d'un
modèle d'architecture pertinent. Elle motive les choix et force à
se concentrer sur les problèmes importants. Il s'agit du « qui
» et du « quoi ».
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 40
? Les diagrammes UML
UML 2.0 comporte ainsi treize types de diagrammes
représentant autant de vues distinctes pour représenter des
concepts particuliers du système d'information. Ils se
répartissent en deux grands groupes :
- Diagrammes structurels ou diagrammes statiques
(diagramme de classes, d'objets, de composants, de déploiement,
de paquetages, de structures composites)
- Diagrammes comportementaux ou diagrammes dynamiques
(diagramme de cas d'utilisation, d'activités,
d'états-transitions, d'interaction, de séquence,
de communication, global d'interaction et de temps)
Ces diagrammes, d'une utilité variable selon les cas,
ne sont pas nécessairement tous produits à l'occasion d'une
modélisation.
? Diagramme de cas d'utilisation
Le diagramme de cas d'utilisation représente la
structure des grandes fonctionnalités nécessaires aux
utilisateurs du système. C'est le premier diagramme du modèle
UML, celui où s'assure la relation entre l'utilisateur et les objets que
le système met en oeuvre.
? Diagramme de classes
Le diagramme de classes est généralement
considéré comme le plus important dans un développement
orienté objet. Il représente l'architecture conceptuelle du
système : il décrit les classes que le système utilise,
ainsi que leurs liens, que ceux-ci représentent un emboîtage
conceptuel (héritage) ou une relation organique (agrégation).
? Diagramme de séquences
Les diagrammes de séquences permettent de
représenter des collaborations entre objets selon un point de vue
temporel, on y met l'accent sur la chronologie des envois de messages. Les
diagrammes de séquences peuvent servir à illustrer un cas
d'utilisation.
? Diagrammes d'activités
UML permet de représenter graphiquement le
comportement d'une méthode ou le déroulement d'un cas
d'utilisation, à l'aide de diagrammes d'activités (une variante
des diagrammes d'états transitions). Une activité
représente une exécution d'un mécanisme, un
déroulement d'étapes séquentielles. Le passage d'une
activité vers une autre est matérialisé par une
transition.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 41
Nous allons, dans le chapitre analyse et conception du
système, utiliser certains de ces diagrammes pour analyser puis
concevoir une solution qui réponde effectivement aux exigences de notre
système.
UML n'étant pas une méthode, sa norme a
été décrite en même temps qu'une méthode
générique d'analyse et de conception des systèmes
logiciels : le Processus Unifié. Synthèse de nombreuses
méthodes et notations, le couple UML et Processus Unifié propose
une approche pour conduire la réalisation de systèmes
orientés objet depuis les spécifications jusqu'au
déploiement. Aujourd'hui, il est à la base de nombreuses
méthodes de travail utilisées dans les entreprises
réalisant des logiciels. Nous allons nous appesantir sur cette
méthode dite générique qui sera la nôtre.
III. Le Processus Unifié
1. Présentation
Le Processus Unifié (PU ou UP en anglais pour Unified
Process) est un processus de développement défini pour prendre en
compte les meilleures pratiques. Il prend en charge le cycle de vie du
logiciel. C'est une méthode générique qui respecte les
spécifications d'UML (itérative et incrémentale,
guidée par les besoins des utilisateurs et centrée sur
l'architecture logicielle) et vient compléter la systémique de
ses modèles. Son caractère « générique »
constitue un de ses atouts essentiels car il donne la possibilité au
concepteur d'adapter la méthode à son domaine, son cas, ses
réalités, possibilité que nous ne manquerons pas
d'exploiter.
Les utilisateurs peuvent corriger, grâce aux
prototypes, la tournure du développement. Dès le début,
des résultats tangibles sont obtenus. Si les besoins des utilisateurs
changent en cours de développement, cette évolution peut
être, dans une certaine mesure, intégrée.
Le PU distingue cinq (5) activités que sont : les
spécifications, l'analyse, la conception, l'implémentation et les
tests. Il prévoit un cycle de vie où les itérations sont
regroupées en catégories d'activités. Ces
catégories sont soit initiales (création), soit
intermédiaires (élaboration, construction) soit finales
(transition vers l'utilisateur ou mise en production). Il est évident
qu'en phase de création, une plus grande partie du temps sera
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 42
consacrée à l'analyse des besoins qu'aux tests
; inversement, en phase de transition, les tests sont encore en cours alors que
l'analyse des besoins et son raffinage sont théoriquement bouclés
depuis la phase de construction.
Figure 3.2 : Cycle de vie du Processus
Unifié
Faisons une description des activités et phases (axes
vertical et horizontal) du PU.
2. Les activités
? L'expression des besoins
Il s'agit d'identifier les acteurs, de recenser les besoins
fonctionnels qui conduisent à l'élaboration des modèles de
cas d'utilisation et affiner ces modèles, de définir les besoins
non fonctionnels et livrer une liste des exigences. Le modèle de cette
activité présente le système du point de vue de
l'utilisateur et représente, sous forme de cas d'utilisation et
d'acteurs, les besoins exprimés. PU étant très axé
sur ces besoins, cette activité est essentielle pour la réussite
des autres.
? L'analyse
Elle permet d'identifier les classes et les attributs, de
réaliser les cas d'utilisation, de structurer le modèle par la
spécification d'interfaces. Son objectif est d'accéder à
une compréhension des besoins et des exigences. Son modèle livre
une spécification complète des besoins afin de les structurer
sous une forme qui facilite la compréhension, la préparation
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 43
(architecture), la modification et la maintenance du futur
système. Il s'écrit dans le langage des développeurs et
peut être considéré comme une ébauche du
modèle de conception.
? La conception
Il s'agit d'identifier les classes manquantes, de choisir les
algorithmes en cas de besoin, de décomposer les éléments
en vue du déploiement. Elle permet d'acquérir une
compréhension des contraintes liées au langage de programmation,
à l'utilisation des composants et au système d'exploitation. Elle
définit la structure statique du système sous forme de sous
systèmes et constitue un point de départ à l'implantation
en créant une abstraction transparente de celle-ci.
? L'implémentation
C'est le résultat de la conception pour
réaliser le système sous forme de composants : codes sources,
scripts, exécutables et d'autres éléments du même
type. On y choisit le langage. Ses objectifs principaux sont la planification
de l'intégration des composants pour chaque itération, la
production des classes sous forme de codes sources.
? Les tests
Ils permettent de vérifier des résultats de
l'implémentation en testant la construction. Pour mener à bien
ces tests, il faut les planifier pour chaque itération (les
hiérarchiser), les implémenter en créant des cas de tests,
les effectuer et prendre en compte le résultat de chacun d'eux. Des
règles de validation doivent être définies.
3. Les phases
? L'analyse des besoins
Aussi appelée phase de création, elle porte
essentiellement sur les besoins principaux
(selon les utilisateurs), l'architecture générale
du système, les risques majeurs, les délais et les
coûts. On met en place le projet.
Elle répond aux questions suivantes : que va faire le
système ? Quels services va t'il
rendre aux utilisateurs ? Quels vont être les
délais, les coûts, les ressources ? Etc.
? L'élaboration
L'élaboration reprend les éléments de la
phase d'analyse des besoins et les précise pour
arriver à une spécification
détaillée de la solution à mettre en oeuvre.
Les tâches à effectuer dans cette phase sont les
suivantes :
- créer une architecture de référence ;
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 44
- formuler les cas d'utilisation pour couvrir les besoins
fonctionnels ;
- élaborer une offre abordant les questions de
calendrier, de budget, etc.
? La construction
L'architecture de référence se
métamorphose en produit complet. Le produit contient tous les cas
d'utilisation que les chefs de projet, en accord avec les utilisateurs ont
décidé de mettre au point pour cette version.
? La transition
Un groupe d'utilisateurs essaye le produit et détecte
les anomalies et défauts. Cette phase suppose des activités comme
la formation des utilisateurs clients, la mise en oeuvre d'un service
d'assistance et la correction des anomalies constatées.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 45
Chapitre 4
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
46
Etude de l'existant
I. Présentation du progiciel Sunshine
software
Le terme progiciel résulte de la
contraction des mots produit et logiciel. C'est un logiciel commercial
vendu par un éditeur sous forme d'un produit complet, plus ou moins
clés en main. Le progiciel complet comprend :
· Les composants logiciels
· Une documentation
· Des stages de formation
· Eventuellement une assistance à l'installation, au
paramétrage et à la mise en oeuvre ;
· Eventuellement une assistance
téléphonique
Première suite progiciel intégralement natif
Internet, Sunshine Software est la troisième gamme progiciel du Groupe
EXTEL et est opérationnel dans les domaines de gestion en Individuel et
Groupe : Epargne, Rentes, Retraite, Fonds de Pension Internationaux,
Prévoyance, Santé. Sunshine s'appuie sur les technologies
innovantes et reconnues du marché comme Java et XML1
1. Architecture de Sunshine
C'est une application web de type 3 tiers. :
L'architecture 3-tiers est un modèle logique
d'architecture applicative qui vise à séparer très
nettement trois couches logicielles au sein d'une même application ou
système, à modéliser et présenter cette application
comme un empilement de trois couches dont le rôle est clairement
défini :
· La présentation des
données : correspond à l'affichage, la restitution sur le poste
de travail, le dialogue avec l'utilisateur ;
· Le traitement métier des
données : correspond à la mise en oeuvre de l'ensemble des
règles de gestion et de la logique applicative ;
· Et enfin l'accès aux données
persistantes : correspond aux données qui sont destinées
à être conservées sur la durée, voire de
manière définitive.
1 XML : eXchange
Markup Language
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
47
Dans cette approche, les couches communiquent entre elles au
travers d'un « modèle d'échange », et chacun d'entre
elles propose un ensemble de services rendus. Les services d'une couche sont
mis à disposition de la couche supérieure. On s'interdit par
conséquent qu'une couche invoque les services d'une couche plus basse
que la couche immédiatement inférieure ou plus haute que la
couche immédiatement supérieure (chaque niveau ne communique
qu'avec ses voisins immédiats )
a. Les Composants de Sunshine
? Le « Controller » géré par un
serveur d'application J2EE1 basé sur les technologies des
servlets et JSP : TOMCAT, WEBLOGIC, WEBSPHERE ;
? Le client « léger » : navigateur web Internet
Explorer Version 5.5 minimum ;
? La base de données hébergée par un SGBD
relationnel qui permet de stocker des données de type Long
Binary2: DB23, SQL Server, ORACLE.
? Le « Controller »
L'application comprend :
o des classes java spécifiques - Servlets - capables
de recevoir et d'envoyer des informations à travers le protocole
http.
o des classes java simples
o des APIs java sur lesquelles s'appuient les programmes
Sunshine
o des fichiers JSP pour envoyer des infos construites
dynamiquement au client
o des fichiers JavaScript contenant des fonctions devant
s'exécuter au niveau du client : contrôles de format de
données, gestion des évènements sur les formulaires
clients (déclenchement de pop-up, initialisation de zones à
partir d'autres)
o des fichiers css pour le formatage du codage HTML.
Le serveur d'application permet l'exécution des
programmes d'une application mais également de maintenir le contexte
d'exécution pour chaque utilisateur : sa session.
Dans l'environnement d'exécution de Sunshine, on
retrouvera :
- trois objets statiques partagés par tous les
utilisateurs et qui sont initialisés par
le premier utilisateur qui
aura besoin de les utiliser :
1 J2EE : Java2 Entreprise Edition
2 Long Binary : Type de donnée binaire qui permet de
stocker des données de longueur arbitraire
3 DB2 : est un système de gestion de base de
données propriétaire à IBM
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 48
o le gestionnaire de pools de connexions à la base de
données
o le gestionnaire de batch
o l'objet contenant les paramètres de l'application
pré-chargés.
- les sessions utilisateurs : Le numéro de session
généré par le serveur
d'application est
encapsulé dans les requêtes et réponses du client et permet
à chaque fois de retrouver les objets propres à l'utilisateur. La
session contient entre autres:
o Le code de l'utilisateur
o Son niveau d'autorisation
o Eventuellement un objet Connexion en mode Commit
différé dans le cas d'un enchaînement de transactions
élémentaires.
o un objet « work » spécifique à une
transaction donnée et donc réinitialisé au début de
chacune d'elle. Il contient les éléments nécessaires
à l'exécution de la transaction : informations sur le dossier
traité, document XML courant, les noms des écrans qui seront
utilisés...).
Le contexte d'exécution en mémoire est le suivant
:
JVM
TOMCAT
Sunshine
Gest. Pool Connexions
Donn. Framework
Gest. Batchs
Contexte 1
Servlets Chargées
Contexte 2
Exécution des Programmes
Figure 4.1 : Contexte d'exécution de Sunshine
? La base de données
Dans la base de données sont stockées :
- des données de type scalaire,
- des fichiers XML
- des fichiers images (documents GED),
- des fichiers HTML (documents générés),
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
49
- des documents PDF (documents générés).
D'un point de vue fonctionnel, on distingue trois
catégories d'informations :
- les données de paramétrage Framework:
- les données de paramétrage métier
(produits d'assurances...),
- les données de production.
b. Communication entre les différents composants
- Client ? ? Controller
Le Controller envoie au client via HTTP, essentiellement du
code HTML. Ce dernier peut inclure l'appel à des fonctions JavaScript
pour le formatage des données et les contrôles
élémentaires sur les infos saisies. Des fichiers .doc, .tif,
.pdf, xml sont également transmis au navigateur.
Le client transmet au serveur d'application à la
soumission des formulaires, les informations saisies qui sont alors
encapsulées dans un objet Request1 toujours grâce au
même protocole.
Grâce à l'API MultiPartRequest, le chargement de
fichiers à partir du client est également possible : fichiers
HTML pour les modèles de courriers, fichiers JSP pour les écrans,
fichiers XML pour le paramétrage des structures de stockages.
- Controller ? ? Base de Données
La communication entre ces deux éléments se fait
via un driver JDBC2 : envoi de requêtes SQL et réponses
sous forme de ResultSet3 pour les demandes d'extraction de
données.
2. Modules de Sunshine
L'urbanisation du progiciel s'articule selon 4 domaines :
- Gestion Administrative
- Gestion des Réseaux de commercialisation
- Gestion Technique
- Gestion Comptable
Modulaire fonctionnellement, à l'exception de la gestion
comptable qui est commune
à l'ensemble des domaines, chaque domaine se
décline en fonction de ses spécificités.
1 Objet Request : permet la
récupération d'informations en provenance d'une station
cliente
2 JDBC : API fournie avec Java
permettant de se connecter à des bases de données
3 ResultSet : objet envoyé
comme résultat après l'exécution d'une requête SQL
par JDBC
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
50
a. Gestion Administrative
Ce module est composé des parties
suivantes :
- Vie individuelle : Assurance vie, décès et
prévoyance, Epargne financière,
Assurance mixte, Assurance complémentaire
- Vie groupe : Prévoyance Collective, Retraite Collective,
Fonds de pensions
- Rentes : Rente de survie, Rente viagère, Rente en cas de
décès, d'incapacité de
travail, d'invalidité permanente
- Gestion des prêts bancaires : Couverture de prêts
bancaires, Contrats
emprunteurs
- Fonds de pensions internationaux
- Santé : Complémentaire, Premier Euro
b. Gestion des réseaux de commercialisation
L'objectif de ce module est de décrire le réseau
commercial, les types de commissions et les règles de calcul des
commissions en vue de calculer, régler et éventuellement
reprendre les commissions. L'alimentation en information est
générée par un flux de données en provenance des
modules de gestion administrative. Le module gestion des réseaux
calculera alors les commissions à verser. Deux modes de gestion existent
: le commissionnement au fil de l'eau ou le commissionnement escompté.
D'autres formes de commissionnement existent. Le commissionnement qui ne
provient pas de la gestion, comme par exemple des rétrocessions de la
part des gestionnaires d'actif, doivent faire l'objet d'une intégration
spécifique. Un commissionnement manuel est possible. Un flux
d'alimentation de commission existe également.
La mise en règlement des commissions peut-être
synchronisée avec l'affectation. Le règlement s'effectue
périodiquement auprès des agents et courtiers non salariés
et est transmis mensuellement au service administratif. Dans le cas où
l'encaissement se fait commission déduite, l'écart affectation /
encaissement est transféré au compte commission.
Bien que pouvant être unique, ce module peut être
dupliqué pour satisfaire une organisation particulière de la
gestion des réseaux. Un travail d'intégration est alors
nécessaire.
c. Gestion Technique
Ce module extrait les informations nécessaires aux
calculs de provisions. La nature des provisions dépend du module de
gestion administrative :
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
51
· Provisions mathématiques d'assurances
· Provisions mathématiques d'épargne
· Provisions mathématiques de rentes
· Provisions pour incapacité et invalidité
· Provisions pour primes acquises non émises
· Provisions pour primes émises non acquises
· Provisions pour risques en cours
· Provisions pour sinistres à payer
Par ailleurs, un ensemble d'extractions fournit des bases
statistiques sur lesquelles s'appuient les visualisations des analyses et les
états réglementaires. Ces extractions peuvent servir
d'alimentation à des systèmes préexistants.
Plus particulièrement sur la santé, des
fonctions d'analyse de la consommation médicale sont fournies.
d. Gestion Comptable
Elle comprend le paramétrage des schémas
comptables, des journaux et des états comptables.
Un flux entrant, en provenance des modules de gestion, des
modules gestion des réseaux de commercialisation et des modules de
gestion technique, alimente un générateur de mouvements
comptables. Ceux-ci sont centralisés.
Un flux sortant à destination de la
comptabilité générale est généré. Le
lien entre comptabilité auxiliaire et comptabilité
générale nécessite un travail d'intégration.
Des transactions permettent de visualiser les comptes et les
états.
3. Framework & Paramétrage
Le paramétrage de Sunshine se fait par l'aide du
Framework. Ce dernier fournit un
ensemble de fonctions facilitant la création de tout ou
d'une partie d'un système logiciel, ainsi
qu'un guide architectural en partitionnant le domaine
visé en modules.
Le framework de Sunshine offre plusieurs possibilités
:
- paramétrage et création de tables de stockage
- paramétrage de Windows de sélection
- intégration d'écrans JSP
- intégration de modèles de courriers
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 52
- paramétrage de règles d'acceptation
- paramétrage d'attentes de pièces,
d'informations
- paramétrage de traitements
- paramétrage de Workflow de dossiers
- paramétrage des menus utilisateurs
- paramétrage de fonctionnalités de gestion de
dossiers qui s'appuie sur les
éléments précédents
a. Paramétrage de tables de stockage
Une structure de stockage peut être créée
à partir d'un fichier XML décrivant les
caractéristiques des données. On peut avoir deux
formes de stockage de ces données :
1er cas : chaque donnée correspond à un
champ de la table ;
2ème cas : seules les informations clés
vont correspondre à des champs de la table ;
un champ supplémentaire FICXML, de type
long binary, est rajouté et contient
l'ensemble des informations stockées sous forme d'un
document XML.
Remarque :
- les fichiers XML ayant une structure arborescente avec plus
d'un niveau de
profondeur ne peuvent être représentés que
sous le 2ième format.
- Pour le 2ième format, les données
clés sont présentes sous forme de champs mais
également dans le document XML global. Mettre à
jour ces champs
indépendamment du document XML entraînerait une
inconsistance des données.
Génération d'une table de stockage
: Les informations suivantes sont demandées à la
création d'une table :
- le nom de la table
- sa description
- son domaine fonctionnel de rattachement
I - Individuel
D - Reprise
R - Rentes
B - Exploitation
P - Paramétrage
G - Fonctions Administratives
A - Assurance de Groupe
M - Gestion Commerciale
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 53
- son type : Production ou Paramétrage
- le fichier XML qui peut être pris de la table JAGSXML ou
du système de fichiers
de l'utilisateur connecté
A la création d'une table Sunshine, outre la table qui
va être créée, un certain nombre
de tables vont être alimentées :
- JATABST : Index des tables Sunshine ;
- JAEXTAF : contient pour chaque table Sunshine, ses
données d'affichage
stockées sous forme d'arbre XML;
- JADOCVID : contient le modèle de document vierge pour
chaque table ;
- JACLETB : contient les données clés de chaque
table ;
- JAPRINI : contient les règles d'initialisation des
zones des tables ;
- JAPRCTL : contient les règles de contrôles des
zones des tables ;
- JANUMCP : contient les définitions de compteurs ;
- J[code du domaine fonctionnel]VARCR : Table des variables
d'édition ; une
table par domaine fonctionnel
b. Paramétrage de Fonctionnalités
Une fonctionnalité est un ensemble de traitements
applicables à des dossiers de même nature. L'application de ces
traitements peut les faire évoluer (changement d'état) en
obéissant à des règles de transitions qui constituent
alors le paramétrage du Workflow des dossiers.
Caractéristiques générales d'une
fonctionnalité : A la création d'une
fonctionnalité on indiquera :
- son code, unique dans tout Sunshine;
- son libellé ;
- le type de fonctionnalité : Batch1 ou
Interactif
- le type de Workflow que l'on aura : Cyclique ou Non
Cyclique : Un Workflow est dit cyclique si on définit un certain nombre
d'états et que de manière cyclique (la périodicité
rencontrée actuellement est celle annuelle), un dossier se retrouve au
même état. Exemple : Dans le Workflow de la
fonctionnalité d'émission de primes, les états
définis correspondent aux mois de l'année. Un contrat dont les
primes sont émises trimestriellement, se retrouvera chaque année
dans les états
1 Batch : Traitement par lot ; utilisé pour
les taches automatisées
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 54
janvier, avril, juillet, septembre. Pour le cas cyclique,
à l'état du dossier, sera associé la donnée
année pour définir de manière unique, la position d'un
dossier dans le Workflow ;
- les domaines et sous-domaines de rattachement;
- les structures de stockage des dossiers de la
fonctionnalité : le dossier d'une fonctionnalité peut être
stocké dans une ou plusieurs tables Sunshine. On aura toujours une table
principale et d'éventuelles tables secondaires. Pour chacune de ces
dernières, on précisera son lien avec la table principale;
- les formulaires par défaut, d'accès aux
informations. Il faudra définir au moins
un écran en mode liste et un ou plusieurs formulaires en
mode détail.
c. Les données clés de
paramétrage
Il s'agit des données dont la valeur peut influer sur
le déroulement des traitements, le choix du Workflow, des formulaires et
des règles de validation
Ces données sont bien sûr choisies parmi celles
des tables de stockage des dossiers de la fonctionnalité.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 55
II. Présentation du système existant
Le système de gestion Workflow existant dan Sunshine
permet de définir un ou plusieurs Workflow cycliques ou non pour une
fonctionnalité par l'aide de formulaires.
Après sa création le Workflow est
paramétré au niveau du framework pour être utilisé
au niveau du domaine de la fonctionnalité.
1. Concepts
Les concepts principaux sont : ? Etat
Un état est une étape d'un
Workflow lors de laquelle un ou plusieurs traitements autorisés sont
exécutés. Dans toute fonctionnalité où on veut
suivre l'évolution des dossiers, on définira la liste des
états que les dossiers peuvent prendre. Ces états peuvent
être regroupés en catégories.
Les catégories vont intervenir à la
définition des règles de contrôle sur les zones, des
règles d'acceptation, des attentes d'informations. En effet pour ces
trois types de règles, on doit indiquer le moment où elles
deviennent bloquantes empêchant le dossier d'évoluer dans le
Workflow.
? Traitement
Un traitement consiste à l'action
élémentaire exécutée à une étape
donnée du Workflow si elle est autorisée pour cet état.
Tout traitement d'une fonctionnalité correspond
à une fonction prédéfinie de Sunshine. Un traitement peut
être de type manuel ou automatique. Lors de la définition du
traitement l'option visible peut être configurée pour l'avoir au
niveau du menu de la fonctionnalité.
? Code retour
Le code retour comme son nom l'indique désigne le
résultat obtenu après l'exécution d'un traitement. On peut
avoir plusieurs codes retours dans l'exécution d'un traitement.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 56
? Transition
Une transition est la manière de progression d'un
traitement vers un autre traitement, ou de changement d'état d'un
traitement à l'état suivant, lors d'un cas d'exécution
donné, qu'il s'agisse d'une procédure manuelle ou
automatisée. Dans ce système nous avons trois cas de transition
:
Automatique : le passage d'un traitement vers
un état final ou un autre traitement indiqué se fait
automatiquement
Manuelle : Le passage d'un traitement vers
un autre état se fait manuellement. Dans ce cas de figure l'utilisateur
aura à choisir à partir d'une liste d'états finaux
définie lors du paramétrage du Workflow, l'état vers
lequel devra évoluer le dossier
Sous condition : l'état final est
déterminé suivant la vérification de l'une des conditions
définies et qui sont exclusives entre elles.
? Enchaînement
On parle d'enchaînement lorsqu'au cours d'une
procédure, les traitements sont exécutées les unes
à la suite des autres, et que c'est le seul itinéraire
possible.
? Règles d'acceptation
Elles interviennent dans le processus de validation
fonctionnelle d'un dossier. Elles doivent être vérifiées
pour que les dossiers puissent évoluer. Le non respect de ces
règles peut empêcher un dossier d'atteindre un état du
Workflow même si une règle de transition l'y autorise.
Une règle d'acceptation peut porter sur une seule zone
d'un dossier ou sur plusieurs ou encore sur les liens du dossier avec d'autres
entités de l'application.
Pour une fonctionnalité, on peut définir les
règles qui devront être vérifiées en
précisant le niveau (catégorie d'état) où ces
règles bloquent l'évolution des dossiers.
Le catalogue des règles d'acceptation : Le catalogue
permet d'uniformiser la codification des règles d'acceptation et des
messages d'erreurs qu'elles renvoient et de réutiliser des programmes de
vérification pour des dossiers de nature différente.
Les règles d'acceptation des fonctionnalités :
Si les règles d'une fonctionnalité ne sont valables que pour une
catégorie de dossiers, on peut :
- soit ne limiter la définition des règles qu'aux
dossiers répondant aux critères indiqués ;
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 57
- soit définir les règles pour tous les
dossiers sauf pour ceux répondant à ces critères.
Une règle d'acceptation peut être définie
comme entraînant la création d'attentes sur le dossier. On peut
préciser les cas de validité des règles d'acceptation. Les
critères de sélection définies correspondent alors :
- soit aux règles d'acceptation
- soit aux attentes d'information
? Attentes
Une information manquante, une demande d'accord marquent une
attente sur un
dossier. Les motifs d'attentes peuvent influer sur
l'évolution du dossier dans le Workflow.
Les attentes dépendent des fonctionnalités et sont
paramétrées comme :
- dépendant de règles d'acceptation du dossier,
- ou correspondant à une demande de pièce.
Dans un souci d'uniformisation de la codification, il existe
dans Sunshine :
- Un catalogue des motifs d'attentes.
- Un catalogue de levée d'attentes
- Un catalogue de réponses de levée d'attente
- Un catalogue de relances d'attentes
? Courriers
Après chaque transition dans un Workflow il est
possible que des courriers soient générés : Ceux-ci sont
souvent des documents destinés aux clients pour leur faire part d'une
situation de leurs dossiers.
? Liens
Le changement d'état d'un dossier peut avoir un impact
sur un dossier ou plusieurs dossiers qui lui sont liés. Exemple :
la validation d'un dossier Sinistre va entraîner la mise à
l'état arrêt du contrat qui lui est rattaché. Ce
paramétrage est stocké est indiqué à la fin des
transitions.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 58
2. Description Fonctionnelle
Le système actuel gère les fonctionnalités
suivantes :
? La Gestion des états et types états:
Cette partie permet de définir les états que peuvent
prendre les dossiers dans une fonctionnalité.
? La Gestion des traitements : Toute
fonctionnalité dispose d'un nombre d'actions élémentaires
applicables à ses dossiers. On y gère les niveaux d'autorisation
pour chaque traitement et le type du traitement
? La Gestion des attentes et regles d'acceptation :
Cette partie gère les différents catalogues des
règles d'acceptation et des attentes pour une fonctionnalité
donnée
? La Gestion de Workflow : Dans cette partie
nous avons la définition, le paramétrage et le suivi de Workflow
d'une fonctionnalité
3. Paramétrage de Workflow
On peut définir plusieurs Workflow pour une
fonctionnalité, chacun à utiliser pour un
type de dossiers donné (en se basant sur les
critères de paramétrage de la fonctionnalité : les
données clés de paramétrage). Dans tous les
cas, l'un deux sera défini comme étant celui par
défaut :
Définir le processus Workflow d'une
fonctionnalité, revient à définir les liens qui
existent entre les états et les traitements :
- définir les traitements autorisés pour chaque
état
- définir ce qu'il y a lieu de faire suivant le code
retour du traitement. Pour
chaque code retour, on indiquera le type de transition :
Chaque paramétrage de règle de transition incluera
:
- l'état de départ ;
- le traitement appliqué ;
- le code issue du traitement ;
- le type de transition choisi ;
- l'état final du dossier (transition automatique) ou la
liste des états à proposer
(transition manuelle) ou les conditions à vérifier
et l'état qui en résultera (transition sous
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 59
conditions) ;
- Eventuellement le traitement sur lequel on enchaînera
à la fin ;
Remarques :
Remarque 1 : le traitement que l'on indique à
ce niveau, doit être défini comme étant autorisé
pour l'état qu'aura le dossier à l'issue de la transition
courante ;
Remarque 2 : dans le système actuel,
l'enchaînement sur un autre traitement n'est possible que pour une
transitjon automatique.
- Eventuellement les documents qui devront être
générés à la fin : Pour cela, on précise le
code script de génération du courrier à appeler. On peut
définir plusieurs codes scripts et également restreindre la
génération de documents à certains dossiers. Il faut alors
préciser une valeur pour les critères de paramétrage de la
fonctionnalité.
- Eventuellment l'impact qu'aura ce changement d'état
sur l'état d'autres
dossiers liés à la fonctionnalité
courante.
4. Critiques du système existant
Sunshine dispose d'un système de gestion de Workflow
permettant de définir un ou plusieurs Workflow pour une
fonctionnalité. Cependant le paramétrage d'un Workflow par un
formulaire peu s'avérer difficile voire même ennuyant si le nombre
d'état ou de traitement devient important.
Le système ne dispose pas d'interface graphique de
modélisation de processus métier et ce dernier pourrait permettre
d'ajuster leurs processus opérationnels en un clin d'oeil, ce qui est un
avantage concurrentiel considérable.
Un des problèmes majeurs de ce système est la
façon donc les données d'un Workflow sont enregistrées au
niveau de la base de données.
? difficultés d'interpréter ou de sortir certains
évènements spécifiques dans un Workflow comme le cas d'un
enchaînement
? enregistrement non optimale : c'est à dire que des
données non importantes d'un Workflow sont enregistrées. Exemple
: Lors de la définition d'un Workflow les traitements non
autorisés n'ont pas besoin d'être enregistrés.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 60
« Mise en place d'un système de gestion
de workflow : Paramétrage, suivi et représentation
graphique » | Page 61
Chapitre 5
Analyse et Conception
du système
I. Expression des besoins
La démarche du Processus Unifié étant
basée sur les besoins des utilisateurs de notre système, nous
présenterons ces utilisateurs (dits acteurs) et ce qu'ils attendent de
leurs interactions avec le système. Cela nous donnera les informations
nécessaires à l'élaboration du diagramme de cas
d'utilisation, reflet des différentes fonctionnalités du
système et, par ailleurs, modèle de l'activité
d'expression des besoins. Les divers cas d'utilisation notés seront
ensuite détaillés textuellement (de sorte qu'ils soient
très compréhensibles) dans le cadre de leur validation par les
utilisateurs par rapport à leurs besoins.
1. Les utilisateurs
Les utilisateurs entrant en communication avec le
système pour un objectif précis sont classés par profil et
chaque profil a un niveau d'autorisation dépendant du domaine.
N'empêche que nous pouvons classés les acteurs du système
en 2 catégories :
Les administrateurs : Ces utilisateurs ont
des privilèges non limités dans le système. Ils sont les
principaux acteurs du système et peuvent réaliser les
opérations suivantes :
· gestion les états (ajouter, modifier, consulter ou
supprimer les états et types d'états)
· gestion les traitements (ajouter, modifier, consulter
ou supprimer les traitements), assigner aux traitements des fonctions
prédéfinis
· Gestion des Workflow : création, modification,
paramétrage, consultation, suivi
· Gestion des règles et attentes : définir
les différents catalogues de règles et d'attentes applicables aux
Workflow
Les visiteurs : ce sont des utilisateurs aux
privilèges limités. Ils n'ont pas accès au framework pour
effectuer des taches d'administrateur mais une fois connecté à un
domaine ils peuvent :
· Faire le suivi des dossiers
· Consulter le paramétrage de Workflow
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 62
2. Le Diagramme de cas d'utilisation
Avant de définir le diagramme de cas d'utilisation
à l'aide des acteurs (utilisateurs du système) et des cas
d'utilisation (leurs utilisations du système), revenons sur les types de
relations pouvant exister entre cas d'utilisation et entre acteurs, ces
relations étant essentielles dans la structuration et la
compréhension du dit diagramme. UML définit trois types de
relations standardisées entre cas d'utilisation :
? une relation d'inclusion : formalisée par la
dépendance « include » ;
? une relation d'extension : formalisée par la
dépendance « extend » ;
? une relation de généralisation /
spécialisation.
Voyons la sémantique de ces trois relations en UML
version 2.0 (« extend » n'ayant pas toujours eu le même sens
pour toutes les versions d'UML). Sachant que la dernière
(généralisation / spécialisation) est aussi valable entre
deux acteurs, sa terminologie ne change pas selon qu'elle soit définie
pour deux cas d'utilisation ou deux acteurs.
- Inclusion : La relation "Include" est une
relation entre 2 instances de cas d'utilisation telle que la réalisation
de l'un nécessite la réalisation de l'autre. Dans une relation
« include », le cas d'utilisation de base utilise
systématiquement les enchaînements provenant du cas inclus.
- Extension : La relation extend est une
relation entre 2 instances de cas d'utilisation telle que A extend B signifie
que le comportement de B peut être complété par le
comportement de A. La relation « extend » montre une
possibilité d'exécution d'interactions qui augmenteront les
fonctionnalités du cas étendu, et ce de façon optionnelle
(alors que la relation « include » suppose une obligation
d'exécution des interactions).
- Généralisation / spécialisation :
La version 1.1 de UML ne distinguait d'ailleurs pas l'extension et la
généralisation. Cette relation est à prendre au sens
classique de spécialisation, inhérent à l'héritage.
Ici, la généralisation peut être vue aussi comme un
"polymorphisme".
Après définition des types de liens pouvant
exister entre cas d'utilisation et entre acteurs, les attentes définies
plus haut des utilisateurs par rapport au système nous ont conduits
à l'élaboration du diagramme de cas d'utilisation suivant :
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 63
Administrateur
Gérer les Workflows
Creer Etat Mettre à jour
Etat
Définir les types
d'états
<<include>> <<include>>
<<include>>
Gérer les Etats
<<include>>
Mettre à jour type Etat
Créer Traitement
Mettre à jour Traitement
<<include>>
<<include>>
Gérer les Traitements
Créer Workflow Mettre à jour
Workflow
Visualiser Workflow
<<include>>
<<extend>>
<<include>>
<<extend>>
<<include>>
Paramétrer Workflow
Faire le suivi de workflow
<<include>>
<<include>>
Visiteur
<<include>>
<<include>>
Définir les attentes
Définir les courriers
Définir les règles
Définir les liens
Gérer les règles
<<include>>
<<include>>
Mettre à jour règle
Créer règle
Créer attente
<<include>>
Gérer les attentes
<<include>>
Mettre à jour attente
Figure 5.1 : Diagramme de cas d'utilisation du
système
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 64
3. Scenarii d'utilisation : description textuelle
Le diagramme de cas d'utilisation décrit les grandes
fonctions d'un système du point de vue des acteurs, mais n'expose pas de
façon détaillée le dialogue entre les acteurs et les cas
d'utilisation. Bien que de nombreux diagrammes d'UML permettent de
décrire un cas, il est recommandé de rédiger une
description textuelle car c'est une forme souple qui convient dans bien des
situations.
La description textuelle d'un cas d'utilisation permet de
communiquer facilement et précisément avec les utilisateurs. Elle
est également l'occasion de s'entendre sur la terminologie
employée, ainsi que d'identifier le contexte d'exécution de l'un
ou de l'autre des enchaînements.
Ainsi, dans les lignes suivantes, nous allons définir
textuellement les différents cas d'utilisation obtenus.
Cas d'utilisation 1 : « Gérer les
états »
Cette partie est gérée par les profils
administrateurs. Lors d'un accès, une liste des états
crées est présentée avec des liens d'ajout et de
suppression d'états. Chaque état doit appartenir à un type
d'état qu'on définira au niveau du cas inclus «
définir les types d'états ». Les autres cas inclus sont
« créer état», « Mise à jour
état», « créer type état» et « Mise
à jour type état»
Cas d'utilisation 2 : « Créer
état »
Ce cas est inclus dans le cas « gérer les
états ». Pour créer un état l'utilisateur clique sur
un lien « ajouter » de la page de consultation des états pour
ensuite donner les informations concernant l'état.
Cas d'utilisation 3 : « Mettre à
jour état »
Ce cas est inclus dans « gérer les états
»; si l'utilisateur veut supprimer un état il choisit l'état
à supprimer sur une liste et valider la suppression. Si son choix est
validé l'état est supprimé définitivement. Pour la
modification, il suffit juste de remplacer les champs de l'état
concerné par les nouvelles valeurs et de valider.
Cas d'utilisation 4 : « Définir les
types d'états »
Comme le cas précédent, ce cas aussi est
à la charge des administrateurs. A chaque type d'état est
attribué lors de sa création un niveau qui déterminera le
niveau bloquant des règles et attentes associées. Les autres
informations à donner sont le libellé et le code du type.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 65
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 66
Cas d'utilisation 5 : « Mettre à jour
type état »
La modification comme la suppression se fait directement sur
la page de consultation des types d'états. Pour modifier, on doit
changer les valeurs correspondant au type et valider. Quant à la
suppression on choisit le type à supprimer ensuite on valide la
suppression.
Cas d'utilisation 6 : « Gérer les
traitements »
La gestion des traitements va de la définition par
l'administrateur à la suppression en passant par la modification et la
consultation. Lors de la définition du traitement une fonction
prédéfinie lui est associée avec un niveau d'autorisation
et un type de traitement. Il comporte les sous cas « créer
traitement » et « mise à jour traitement»
Cas d'utilisation 7 : « Créer
traitement »
Ce cas est inclus dans « gérer les traitements
»; Pour créer un traitement l'utilisateur renseigne les
informations comme la fonction Sunshine associée qui est un programme
défini auparavant dans JAPROG1, son libellé, son type,
le niveau d'autorisation.
Cas d'utilisation 8 : « Mettre à
jour traitement »
Comme le cas précédent, il est inclus dans le
cas « Gérer les traitements ». La suppression d'un traitement
se fait directement au niveau de la page de consultation. Il choisit
l'état à supprimer sur une liste et valide pour la suppression.
La modification suffit juste de remplacer les champs du traitement
concerné par les nouvelles valeurs et de valider.
Cas d'utilisation 9 : « Gérer les
Workflow »
La gestion des Workflow se fait à l'aide du framework
de Sunshine dont seuls les profils administrateurs y ont accès. Ce cas
contient les sous cas d'utilisation suivants : «Créer un
Workflow», «Mettre à jour Workflow»,
«Paramétrer Workflow» et «Visualiser Workflow»
Cas d'utilisation 10 : «
Créer Workflow »
Ce cas est inclus dans « Gérer les Workflow
»; Lors de la création d'un Workflow on définit son code,
son libelle, le critère spécifique de paramétrage et on
indique si on part d'un paramétrage nouveau ou existant.
Cas d'utilisation 11 : « Mettre à
jour Workflow »
Ce cas est inclus dans « Gérer les Workflow
». Pour modification on choisit le Workflow à modifier et on
renseigne les mêmes informations puis on valide. La suppression
1 JAPROG : Table où sont stockés les
noms des programmes et leur servlet associée
d'un Workflow se fait directement au niveau de la page de
consultation en choisissant l'état à supprimer sur une liste et
valider la suppression.
Cas d'utilisation 12 . « Paramétrer
Workflow »
Après la définition du Workflow, les
administrateurs doivent maintenant le paramétrer et ceci à l'aide
de l'outil de modélisation graphique. Pour paramétrer un Workflow
on définit la liste des états puis pour chaque état on
autorise des traitements et à chaque traitement autorisé on
associe une transition et un code issu. Pour chaque combinaison état,
traitement, transition, se définira si besoin est : des courriers,
attentes, règles de vérification ou liens vers d'autres dossiers.
Ce cas est inclus dans le cas d'utilisation « Gérer les
Workflow»
Cas d'utilisation 13 : « Définir
les courriers»
Ce cas est inclus dans le cas « Paramétrer
Workflow » donc il est à la charge des administrateurs. Pour
définir un courrier à générer il faut choisir sur
une liste proposée un critère de paramétrage, donner sa
valeur et son script de génération.
Cas d'utilisation 14 : « Définir
des attentes »
Comme le cas précédent, c'est un cas inclus dans
le cas « Paramétrer Workflow ». En effet lors du
paramétrage on peut spécifier après une transition les
éventuelles attentes des dossiers au niveau de cet état. Pour
définir une attente, il s'agit de donner le code du motif. Cas
d'utilisation 15 . « Définir des règles
d'acceptation »
Comme les attentes, les règles d'acceptation sont
définies pour le Workflow lors du paramétrage. Il s'agit de
donner les programmes à vérifier par les dossiers une fois
à cet état pour pouvoir évoluer. Les informations
demandées sont le code de la règle, la liste des valeurs des
paramètres.
Cas d'utilisation 16 . « Définir
des liens entre dossiers »
C'est un cas inclus dans le cas « Paramétrer
Workflow ». Il s'agit de définir les fonctionnalités dont
l'état des dossiers sera modifié et l'état final où
les dossiers vont être dirigés. Une restriction peut être
faite sur les dossiers à l'aide d'une requête de sélection
au niveau d'une zone.
Cas d'utilisation 17 . « Visualiser
Workflow »
Ce cas est une extension du cas « Gérer les
Workflow». Il s'agit de la représentation du graphe du Workflow
modélisé. Au début l'utilisateur (administrateur ou
visiteur) aura à choisir sur une liste le Workflow à
représenter. Après validation une représentation du
Workflow choisi lui sera présentée avec des liens permettant
d'accéder à des détails du
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 67
Workflow comme les scripts des courriers, la liste des
utilisateurs pour un traitement, la liste des attentes, règles et
liens.
Cas d'utilisation 18 . « Faire le suivi du
Workflow »
Ce cas est une extension du cas « Gérer les
Workflow ». Les administrateurs comme les visiteurs ont les droits requis
pour le suivi de Workflow. Il se fait à l'aide d'un graphe de Workflow
donnant pour chaque état le pourcentage de dossier présent. En
cliquant sur la zone de l'état on accède à la liste des
dossiers.
Cas d'utilisation 19 . « Gérer les
attentes »
Il s'agit de la définition et la mise à jour des
catalogues d'attentes. Ce cas comprend les cas « Créer
attente» et « Mise à jour attente» et est sous la charge
de l'administrateur. Cas d'utilisation 20 . « Créer
attente »
L'administrateur pour définir une attente dans le
catalogue doit spécifier le motif, son type de motif, le niveau de
l'état bloquant, le programme de vérification, les relances et le
paramétrage de la levée de l'attente.
Cas d'utilisation 21 . « Mettre à
jour attente »
Comme le cas précédent, c'est un cas inclus
dans « Gérer les attentes ». Avant de mettre à jour une
attente le système vérifie si son type permet cette action de
mise à jour. Si ce n'est pas le cas l'action est refusée par le
système.
Cas d'utilisation 22 . « Gérer les
règles d'acceptation »
Ce cas permet de définir et de mettre à jour
des catalogues de règles. IL comprend les cas « Créer
règle» et « Mise à jour règle» et est comme
les attentes sous la charge de l'administrateur.
Cas d'utilisation 23 . « Créer
règle »
Lors de la création de la règle
l'administrateur spécifie son nom, le libellé, le programme de
vérification, le type de règle, et le niveau de l'état
bloquant. Il peut ajouter en même temps pour la règle des
critères de validité du motif et des liens avec des motifs
d'attentes. Ce cas est inclus dans le cas « Gérer les règles
»
Cas d'utilisation 24. « Mettre à
jour règle »
C'est un cas inclus dans « Gérer les
règles». Il s'agit de la modification ou la suppression d'une
règle d'acceptation. Pour modifier une règle, on la choisit dans
une liste et on modifie les informations de la règle puis on valide. La
suppression se fait après le choix et la validation de la règle
à supprimer.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 68
II. Analyse et Conception
L'analyse du système se fera en deux étapes :
La première étape est la modélisation de certains
scénarii d'utilisation décrits textuellement dans le dernier
paragraphe de l'expression des besoins (Scénarii d'utilisation : forme
textuelle) ; puis nous passerons à la mise en oeuvre d'une
ébauche du diagramme de classes du système à partir des
différents objets relevés, diagramme que l'on affinera lors de
l'activité de conception notamment en y intégrant les attributs
et les opérations des classes.
1. Scénarii d'utilisation : modélisation
La description textuelle des diverses utilisations du
système servant de domaine de consensus pour la compréhension des
besoins des clients, il est nécessaire de passer à un langage
« plus soutenu » qu'est celui des concepteurs. La modélisation
des scénarii d'utilisation nous permet de franchir ce cap. Elle montre
le comportement des uns et des autres dans le cadre de la réalisation
d'objectifs précis. Elle présente également les
éléments du système en classes décrivant les objets
manipulés.
Précisons que la nature du diagramme à utiliser
pour la modélisation d'un cas d'utilisation donné dépend
de l'aspect que l'on désire mettre en exergue : c'est ce qui explique
que, pour certains cas d'utilisation, seule une vue statique sera
présentée alors que, pour d'autres, nous avons cru
nécessaire d'insister sur les interactions ayant lieu en faisant appel
à un diagramme dynamique.
Cas d'utilisation 1 : « Gérer les
états »
JATYPET
JAETAT
1--1
0--*
Figure 5.2 : Diagramme de classes « Gérer
les états »
JATYPET
Champ
|
Type
|
Description
|
CDTYPET
|
CHAR(3)
|
Code de la catégorie
|
CODEFONCT
|
CHAR(20)
|
Code fonctionnalité
|
LIBTYPET
|
CHAR(25)
|
Libellé de la catégorie d'états
|
NIVET
|
INTEGER
|
A la présentation, n° d'ordre du type
d'état.
|
|
Tableau 5 .1 : Détails de la classe «
JATYPET »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 69
JAETAT
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement
|
NUMORD
|
INTEGER
|
Rang de l'état
|
NUMETAT
|
INTEGER
|
N° d'état, identifiant de l'état
|
CODETAT
|
CHAR(9)
|
Identifiant de l'état, utile pour codifier les
états suivant leur fonction
|
LIBETAT
|
CHAR(50)
|
Libellé de l'état
|
CODEFONCT
|
CHAR(20)
|
Code fonctionnalité
|
CDTYPET
|
CHAR(3)
|
Code de la catégorie d'état (table JATYPET)
|
UNIQAUTO
|
CHAR(1)
|
{`O', `N'} : la valeur `O' indique que l'état ne
pourra être choisi que dans les transitions automatiques.
|
RESTRIC
|
CHAR(1)
|
Paramètre de présentation intervenant dans le
traitement de visualisation du graphe du Workflow de la
fonctionnalité.
|
|
Tableau 5.2 : Détails de la classe «
JAETAT »
Cas d'utilisation 6 : « Gérer les traitements
»
JARESFT
1--1
1--*
JATRAIT
Figure 5.3 : Diagramme de classes « Gérer
les traitements »
JARESFT
Champ
|
Type
|
Description
|
FONCTION
|
CHAR(20)
|
Code de la fonction prédéfinie
|
CODEISSUE
|
CHAR(20)
|
Code d'identification de l'issue du traitement
|
DESCISSUE
|
CHAR(100)
|
Descriptif de la fonction
|
|
Tableau 5.3 : Détails de la classe «
JARESFT »
JATRAIT
Champ
|
Type
|
Description
|
NUMORDRE
|
INTEGER
|
N° d'ordre du traitement (ordre d'affichage)
|
IDENT
|
INTEGER
|
Compteur d'enregistrement
|
NOMTABLE
|
CHAR(20)
|
Code fonctionnalité de rattachement
|
CODETRAIT
|
CHAR(20)
|
Code traitement (unique par fonctionnalité)
|
LIBTRAIT
|
CHAR(50)
|
Libellé du traitement
|
FONCTION
|
CHAR(20)
|
Code fonction Sunshine
|
|
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 70
TYPETRAIT
|
CHAR(3)
|
Type traitement : {`M','A'} Interactif ou Batch
|
DESCTRAIT
|
CHAR(100)
|
Description du traitement
|
PARAMS
|
CHAR(500)
|
liste des valeurs des paramètres de la fonction.
|
PROG
|
CHAR(30)
|
nom du programme de la fonction prédéfinie
|
MODEAPP
|
CHAR(1)
|
valeur du paramètre de même nom de JAPROG
|
OPTMENU
|
CHAR(1)
|
{O','N'}: Accessibilité à partir du menu
|
NIVAUT
|
INTEGER
|
Niveau d'autorisation du traitement. Le traitement est
accessible à tous les utilisateurs dont le niveau d'autorisation pour le
sous-domaine fonctionnel est >= à la valeur de ce champ.
|
|
Tableau 5.4 : Détails de la classe « JATRAIT
» Cas d'utilisation 6 : « Gérer les Workflow
»
JAWRKFT
1--1
1--1
1--*
1--1
JAFONCT
JAWRKPR
Figure 5.4 : Diagramme de classes « Gérer
les Workflow »
JAFONCT
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
CODEFONCT
|
CHAR(20)
|
Code de la fonctionnalité
|
NOMTABPRIN
|
CHAR(20)
|
Nom de la table principale
|
DATCRT
|
INTEGER
|
Date de création
|
DATMOD
|
INTEGER
|
Date de dernière modification
|
LIBFONC
|
CHAR(50)
|
Libellé de la fonctionnalité
|
DESCFONC
|
CHAR(200)
|
Description de la fonctionnalité
|
REDAC
|
CHAR(10)
|
Code rédacteur
|
CODEDOM
|
CHAR(2)
|
Domaine fonctionnel
|
SOUSDOM
|
CHAR(2)
|
Sous-domaine fonctionnel
|
CODEWRK
|
CHAR(10)
|
Code Workflow par défaut
|
TYPEFONCT
|
CHAR(1)
|
Interactif ou batch
|
TYPEWRK
|
CHAR(1)
|
Type de Workflow : cyclique ou non cyclique
|
|
Tableau 5.5 : Détails de la classe «
JAFONCT »
JAWRKPR
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
|
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 71
CODEFONCT
|
CHAR(20)
|
Code de la fonctionnalité
|
CODEWRK
|
CHAR(10)
|
Code du Workflow (unicité par
fonctionnalité)
|
LIBWRK
|
CHAR(50)
|
Libellé du Workflow
|
REDAC
|
CHAR(3)
|
Code rédacteur ayant créé le Workflow
|
DCREAT
|
INTEGER
|
Date de creation du Workflow
|
DMODIF
|
INTEGER
|
Date de dernière modification
|
FICPARAM
|
Long Binary
|
Fichier XML de paramétrage
|
|
Tableau 5.6 : Détails de la classe «
JAWRKPR »
JAWRKFT
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
CODEFONCT
|
CHAR(20)
|
Code de la fonctionnalité
|
CODEWRK
|
CHAR(10)
|
Code du Workflow (unicité par
fonctionnalité)
|
CRIT1
|
CHAR(60)
|
1er critère de validité du Workflow
|
VALCRIT1
|
CHAR(20)
|
Valeur du 1er critère
|
CRIT2
|
CHAR(60)
|
2ième critère de validité du Workflow
|
VALCRIT2
|
CHAR(20)
|
Valeur du 2ieme critère
|
CRIT3
|
CHAR(60)
|
3ieme critère de validité du Workflow
|
VALCRIT3
|
CHAR(20)
|
Valeur du 2ième critère
|
|
Tableau 5.7 : Détails de la classe «
JAWRKFT »
Cas d'utilisation 12 : « Paramétrer Workflow
»
0--*
1--1
1--1
0--*
1--1
1--1
0--*
JAWRKFL
1--1
0--*
JAACPFP
JACRTRN
JACTLSP
0--*
JAWRKCD
JAINFET
Figure 5.5 : Diagramme de classes «
Paramétrer Workflow »
JAWRKFL
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur Sunshine d'enregistrement
|
|
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 72
ETATDEP
|
INTEGER
|
N° d'état de départ de la transition
|
TRAITDEP
|
CHAR(20)
|
Code du Traitement appliqué
|
CODEISSUE
|
CHAR(20)
|
Code issue du traitement
|
DESCACT
|
CHAR(100)
|
Description de la transition
|
CHOIXFIN
|
CHAR(1)
|
{`A','M','C'} : type de transition
|
ETATISSUE
|
INTEGER
|
n° d'état final (transition automatique), n°
de l'état par défaut pour les transitions manuelles et
sous-conditions.
|
TRAITISSUE
|
CHAR(20)
|
code du traitement sur lequel on enchaîne
|
CODEFONCT
|
CHAR(20)
|
Code de la fonctionnalité
|
CODEWRK
|
CHAR(10)
|
Code du Workflow
|
ANNEE
|
CHAR(20)
|
formule de calcul de l'année associée à
l'état ANNEE + x : année de l'état de départ + x
|
|
Tableau 5.8 : Détails de la classe «
JAWRKFL »
JAWRKCD
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
IDTRANS
|
INTEGER
|
n° de l'enregistrement JAWRKFL (IDENT).
|
ETATDEP
|
INTEGER
|
Reprennent les champs de JAWRKFL de
même nom pour l'enregistrement dont
l'IDENT vaut
IDTRANS
|
TRAITDEP
|
CHAR(20)
|
|
CHAR(20)
|
|
CHAR(100)
|
Liste des états qui seront proposés à
l'utilisateur
|
LISTANNEE
|
CHAR(200)
|
Liste des formules de calcul
|
CONDT
|
CHAR(200)
|
code du programme à vérifier (transition SC)
|
CODEFONCT
|
CHAR(20)
|
Code de la fonctionnalité
|
CODEWRK
|
CHAR(20)
|
Code du Workflow
|
|
Tableau 5.9 : Détails de la classe «
JAWRKCD »
JACRTRN
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
REDAC
|
CHAR(3)
|
Code rédacteur
|
IDTRANS
|
INTEGER
|
N° de l'enregistrement de JAWRKFL
|
ETATISSUE
|
INTEGER
|
N° état final pour lequel on aura à
générer un document
|
CONDT
|
CHAR(200)
|
Reprend la condition décrite dans JAWRKCD
|
TYPTRANS
|
CHAR(1)
|
Indique le type de transition, {`A','M','C'}
|
CRIT
|
CHAR(60)
|
nom du critère de sélection des dossiers.
|
VALCRIT
|
CHAR(20)
|
Valeur du critère de sélection des dossiers
|
CDGEN
|
CHAR(10)
|
Code script de génération de documents
|
|
Tableau 5.10 : Détails de la classe «
JACRTRN »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 73
JAINFET
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement
|
REDAC
|
CHAR(3
|
Code rédacteur
|
GESAC
|
CHAR(3)
|
Code gestionnaire
|
ETAAC
|
CHAR(2)
|
Flag enregistrement
|
IDTRANS
|
INTEGER
|
N° de l'enregistrement de JAWRKFL
|
ETATISSUE
|
NUMBER
|
L'état final des dossiers
|
CONDT
|
CHAR(200)
|
Restriction des dossiers
|
TYPTRANS
|
CHAR(1)
|
Type de transition
|
CRIT
|
CHAR(60)
|
Critère spécifique
|
VALCRIT
|
CHAR(20)
|
Valeur critère
|
RECUPDOS
|
CHAR(200)
|
Requête de sélection de dossiers
|
PROGRECUP
|
CHAR(20)
|
Programme de récupération
|
PREDRECUP
|
CHAR(200)
|
Prédicat de récupération
|
ETATFONCT
|
CHAR(200)
|
L'état de la fonctionnalité où mettre les
dossiers
|
PROGRECAUT
|
CHAR(20)
|
Programme de récupération avec prédicat
|
PREDRECAUT
|
CHAR(200)
|
Prédicat
|
ANNEE
|
CHAR(20)
|
formule de calcul de l'année de l'état
|
CODEFONCT
|
CHAR(20)
|
Code de la fonctionnalité
|
CODEWRK
|
CHAR(20)
|
Code du Workflow
|
|
Tableau 5.11 : Détails de la classe «
JAINFET »
JACTLSP
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
REDAC
|
CHAR(3)
|
Code Rédacteur
|
CDTYPET
|
CHAR(3)
|
Niveau bloquant de la règle
|
CODAC
|
CHAR(6)
|
Code règle d'acceptation du catalogue
|
CODEFONCT
|
CHAR(20)
|
Code Fonctionnalité
|
LIBAC
|
CHAR(30)
|
Libellé Règle Acceptation
|
DESCAC
|
CHAR(60)
|
Descriptif règle
|
PRGCTL
|
CHAR(10)
|
Nom du programme
|
REGLE
|
CHAR(200)
|
Règle exprimée sous forme de prédicat
|
PARAMS
|
CHAR(200)
|
Liste des paramètres du catalogue auxquels on doit
attribuer une valeur à ce niveau.
|
LIBELS
|
CHAR(500)
|
Liste des libellés des paramètres
|
VALEURS
|
CHAR(300)
|
Liste des valeurs des paramètres
|
MSGACC
|
CHAR(150)
|
Liste des messages d'erreurs
|
CODACCT
|
CHAR(6)
|
Code de la règle dans la fonctionnalité
|
TYPEREGACC
|
CHAR(8)
|
Catégorie de traitements pour lesquels la règle
sera testée.
|
|
Tableau 5.12 : Détails de la classe «
JACTLSP »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 74
JAACPFP
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement
|
REDAC
|
CHAR(3
|
Code rédacteur
|
GESAC
|
CHAR(3)
|
Code gestionnaire
|
ETAAC
|
CHAR(2)
|
Flag enregistrement
|
CDTYPET
|
CHAR(3)
|
Niveau d'état bloquant
|
CODEFONCT
|
CHAR(20)
|
Code fonctionnalité
|
MTFAC
|
CHAR(4)
|
Code motif attente
|
PIECE
|
CHAR(25)
|
Pièce correspondant à l'attente s'il s'agit
d'une attente de pièce
|
CDTAB
|
CHAR(8)
|
Code table des réponses de levée des attentes
|
INDMA
|
CHAR(1)
|
Type motif attente : P- demande de pièces et A :
lié à une règle d'acceptation
|
CODACCT
|
CHAR(6)
|
Code règle d'acceptation si INDMA='A'
|
TYPEATT
|
CHAR(8)
|
Catégorie de traitements pour lesquels
l'attente sera vérifiée.
|
|
Tableau 5.13 : Détails de la classe «
JAACPFP »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 75
Diagramme de Sequence :
Paramétrer Workflow
Repeter
: Administrateur
liste code retour traitement
choix traitement à
enchainer
Appel fonction parametrage
Proposition liste workflow
Interface de paramétrage
Validation paramétrage
autoriser traitements
ajouter transition
choix code retour
choix etat initial
Définir courriers
Choix workflow
choix état final
définir attentes
définir règles
définir liens
:Système
Génération fichier
xml
Sauvegarde paramétrage
Figure 5.6 : Diagramme de séquences «
Paramétrer Workflow »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 76
Cas d'utilisation 17 : « Visualiser un Workflow
»
Diagramme de Sequence :
Visualiser Workflow
: Visiteur
Appel traitement
représentation
Proposition liste workflow
visualisation du workflow
représentation workflow
demander détails
résultat détails
Choix workflow
:Système
Figure 5.7 : Diagramme de séquences «
Visualiser Workflow »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 77
Cas d'utilisation 18 : « Faire le suivi du Workflow
»
Diagramme de Sequence :
Faire le suivi du Workflow
: Visiteur
demander liste dossiers d'un
état
Proposition liste workflow
Appel traitement suivi
liste dossiers de l'état
histogramme de suivi
Choix workflow
:Système
Figure 5.8 : Diagramme de séquences « Faire
le suivi du Workflow » Cas d'utilisation 22 : «
Gérer les règles d'acceptation »
0..*
JACTLSP
1..1
0..1
JACRCTL
0..*
1..1
JACLCTL
0..*
JAFONCT
JAACPFP
Figure 5.9 : Diagramme de classe « Gérer
les règles d'acceptation »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 78
JACLCTL : Catalogue des règles d'acceptation
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement système
|
REDAC
|
CHAR(3)
|
Code rédacteur
|
CODAC
|
CHAR(6)
|
Code d'identification de la règle
|
LIBAC
|
CHAR(30)
|
Libellé de la règle
|
DESCAC
|
CHAR(60)
|
Descriptif de la règle
|
PRGCTL
|
CHAR(10)
|
Nom du programme vérifiant la règle
|
REGLE
|
CHAR(200)
|
Règle exprimée sous forme de prédicat.
|
MSGACC
|
CHAR(150)
|
Liste des codes des messages d'erreurs
|
PARAMS
|
CHAR(200)
|
Liste des paramètres de la fonction
|
LIBPARAMS
|
CHAR(500)
|
Liste des libellés des paramètres de la
fonction
|
|
Tableau 5.14 : Détails de la classe «
JACLCTL »
JACTLSP : Catalogue des règles par
fonctionnalité (conférer tableau 5.12)
JACRCTL
Champ
|
Type
|
Description
|
CODEFONCT
|
CHAR(20)
|
Code Fonctionnalité
|
CODACCT
|
CHAR(6)
|
Code de la règle dans la fonctionnalité
|
TYPECRIT
|
CHAR(3)
|
{`IN','OUT'}. `IN' indique si la règle doit être
testée pour les dossiers répondant aux critères qui
suivent
|
CRIT1
|
CHAR(60)
|
nom du 1er critère de sélection des
dossiers
|
VALCRIT1
|
CHAR(20)
|
Valeur du 1er critère
|
CRIT2
|
CHAR(60)
|
nom du 2ième critère
|
VALCRIT2
|
CHAR(20)
|
Valeur du 2ième critère
|
CRIT3
|
CHAR(60)
|
nom du 3ième critère
|
VALCRIT3
|
CHAR(20)
|
Valeur du 3ième critère
|
IMTFAC
|
INTEGER
|
Utilisé pour le paramétrage des attentes,
critères de sélection des attentes mais cette fois-ci le lien se
fait avec la table JAACPFP.
|
|
Tableau 5.15 : Détails de la classe «
JACRCTL »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 79
Cas d'utilisation 19 : « Gérer les attentes
»
JAFONCT
0..*
0..*
JAACPFP
0..1
JAACPTP
0..1
0..*
JACTREP
JAFTREP
0..*
1..1
0..*
JAACCRP
Figure 5.10 : Diagramme de classes « Gérer
les attentes »
JAACPTP : Catalogue des motifs d'attentes
Champ
|
Type
|
Description
|
REDAC
|
CHAR(3)
|
Code rédacteur
|
MTFAC
|
CHAR(4)
|
Code motif d'attente
|
LM1AC
|
CHAR(60)
|
Libellé motif d'attente
|
LIBEDT
|
CHAR(100)
|
Libellé d'édition de l'attente
|
|
Tableau 5.16 : Détails de la classe «
JAACPTP »
JAACPFP : Motifs d'attentes par fonctionnalité
(conférer tableau 5.13) JAACCRP : Paramétrage des
relances
Champ
|
Type
|
Description
|
IDENT
|
INTEGER
|
Compteur d'enregistrement Système
|
REDAC
|
CHAR(3)
|
Code rédacteur
|
GESAC
|
CHAR(3)
|
Code gestionnaire
|
ETAAC
|
CHAR(2)
|
Flag enrégistrement
|
IMTFAC
|
INTEGER
|
N° enregistrement de JAACPFP
|
NUMREL
|
INTEGER
|
N° de relance paramétré
|
DURAP
|
INTEGER
|
Nombre de « UNRAP » au bout duquel on
considère que l'attente a expiré
|
UNRAP
|
CHAR(1)
|
{`J','M'...}Unité durée attente
|
CDGEN
|
CHAR(10)
|
Code de génération du courrier lié à
l'attente
|
CDMSG
|
CHAR(10)
|
Code de génération des messages à envoyer
aux user
|
|
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 80
ETATWL
INTEGER
N° Etat du Workflow où mettre le dossier
Tableau 5.17 : Détails de la classe «
JAACCRP »
JAFTREP : Paramétrage de la levée des
attentes
Champ
|
Type
|
Description
|
REDAC
|
CHAR(3)
|
Code Rédacteur
|
GESAC
|
CHAR(3)
|
Code Gestionnaire
|
ETAAC
|
CHAR(2)
|
Flag de Position
|
IMTFAC
|
INTEGER
|
Identifiant définition motif attente de rattachement
|
CDTAB
|
CHAR(10)
|
Code Table Réponses
|
CDREP
|
CHAR(10)
|
Code réponse
|
INDSUP
|
CHAR(1)
|
Indicateur motif à supprimer suite à la
réponse
|
INDCL
|
CHAR(1)
|
Indicateur clause à rajouter
|
CHPCL
|
CHAR(35)
|
Nom champ clause si clause à rajouter
|
INMTFAC
|
INTEGER
|
Identifiant nouveau motif si nouveau motif à
générer
|
ETATWL
|
INTEGER
|
N° Etat du Workflow si réponse entraîne
changement
|
TRAIT
|
CHAR(20)
|
Code traitement à lancer si traitement à
exécuter
|
|
Tableau 5.18 : Détails de la classe «
JAFTREP »
JACTREP : Catalogue des réponses de levée
d'attente
Champ
|
Type
|
Description
|
REDAC
|
CHAR(3)
|
Code Rédacteur
|
GESAC
|
CHAR(3)
|
Code Gestionnaire
|
ETAAC
|
CHAR(2)
|
Flag de Position
|
CDTAB
|
CHAR(10)
|
Code Table Réponses
|
LIBTAB
|
CHAR(35)
|
Libellé table
|
CDREP
|
CHAR(10)
|
Code réponse
|
LIBREP
|
CHAR(35)
|
Libelle Réponse
|
|
Tableau 5.19 : Détails de la classe «
JACTREP »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 81
2. Diagramme de classes du système : ébauche
La modélisation des scénarii nous a permis de
passer du langage compris par tous les acteurs (forme textuelle) au langage de
conception. L'identification des classes nées des cas d'utilisation
étant faite, nous allons toutes les regrouper dans un même
diagramme de classes qui nous fournira une idée précise sur la
structure statique de notre système, structure qui sera peaufinée
tout au long de l'activité de conception.
Par souci de clarté, seuls les noms des classes seront
mentionnés. Nous ferons donc volontairement abstraction de leurs
attributs et méthodes.
JARESFT
JATRAIT
1..1
1..*
0..*
JATYPET
JAETAT
1..1
0..*
0..*
JAWRKFT
1..1
1..1
JAWRKCD
JAWRKPR
1..*
1..1 0..*
1..1
1..1
1..1
1..1
0..*
JACLCTL
JAFONCT
JAWRKFL
0..*
0..*
JACTLSP
1..1
0..*
1..1
1..1
1..1
JAACPFP
0..1
0..*
0..*
0..*
JACRCTL
1..1 0..*
JAACCRP
1..1
0..*
1..1
0..*
JAINFET
JACRTRN
0..1
0..*
0..*
JAFTREP
JACTREP
JAACPTP
0..*
0..1
Figure 5.11 : Diagramme de classes du système
(ébauche)
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 82
3. Vue logique du système
L'analyse nous a permis de déterminer les
différents éléments (acteurs, objets, liens, informations,
etc.) qui interviennent dans notre système. Cependant, ces
éléments ne suffisent souvent pas pour répondre aux
différentes attentes des utilisateurs. Interviennent alors les classes
et associations dites « de conception ». Comme leurs noms
l'indiquent, elles voient le jour lors de l'activité de conception et
viennent en complément des éléments issus de
l'activité d'analyse. L'ensemble ainsi formé fournit un
modèle statique du système (à travers le diagramme de
classes) satisfaisant au mieux les besoins des acteurs. La conception sert
aussi à raffiner les liens entre les différents objets avec
notamment les notions d'héritage, d'agrégat, de composition,
etc.
Dans le cadre de sa vue logique, le système sera
subdivisé en sous systèmes dont nous élaborerons les
diagrammes de classes, leur réunion constituera le diagramme de classes
du système.
a. La gestion des états
- CDTYPET - CODEFONT -
LIBTYPET - NIVET
+ définir ()
+ mettre_a_jour ()
JATYPET
: String : String :
String : String
1..1
0..*
- IDENT
- NUMORD
- NUMETAT
- CODETAT
- LIBETAT
- CODEFONCT
- CDTYPET
- UNIQAUTO
- RESTRIC
+ creer ()
+ mise_a_jour_etat ()
JAETAT
: Integer : Integer :
Integer : String : String : String
: String : String : String
Figure 5.12 : Diagramme de classes « Gestion des
états »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 83
b. La gestion des traitements
- fonction
- codeissue
+ creer O+ mettre_a_jour O
JARESFT
: String : String
1..1
1..*
- NUMORDRE - IDENT
- NOMTABLE - CODETRAIT -
LIBTRAIT - FONCTION - TYPETRAIT -
DESCTRAIT - PARAMS - PROG
- MODEAPP - OPTMENU - NIVAUT
+ CREER O+ modifier O+
consulter O+ suprimer O
JATRAIT
: Integer : Integer : String :
String : String : String : String :
String : String : String : String :
String : Integer
Figure 5.13 : Diagramme de classes « Gestion des
traitements »
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 84
c. La gestion des Workflow
1..1
0..*
1..1
1..*
1..1
1..1
- IDENT
- CODEFONCT
- CODEWRK
- CRIT1
- CRIT3
- CRIT2
- VALCRIT2
- VALCRIT3
- VALCRIT1
+ definir_critere ()
JAWRKFT
: Integer : String : String :
String : String : String : String :
String : String
- IDENT
- CODEFONCT
- CODEWRK
- REDAC
- LIBWRK
- DCREAT
- DMODIF
- FICPARAM
+ CREER ()
+ modifier ()
+ visualiser ()
+ suprimer ()
+ Paramétrer ()
+ Faire_le_suivi ()
JAWRKPR
: Integer : String : String :
String : String : Integer : Integer
: Long Bin
- IDENT
- CODEFONCT
- NOMTABPRIN
- DATCRT
- DATMOD
- LIBFONC
- DESCFONC
- REDAC
- CODEDOM
- SOUSDOM
- CODEWRK
- TYPEFONCT
- TYPEWRK
+ creer ()
+ modifier () + consulter () +
suprimer () + parametrer ()
JAFONCT
: Integer : String : String :
Integer : Integer : String : String
: String : String : String : String
: String : String
1..1
- IDENT
- REDAC
- IDTRANS
- ETATISSUE
- CONDT
- TYPTRANS
- CRIT
- VALCRIT
- CDGEN
+ definir ()
JACRTRN
: Integer : String : Integer :
Integer : String : String : String
: String : String
1..1
1..1
0..*
- IDENT
- IDTRANS - ETATDEP - TRAITDEP
- CODEISSUE - LISTEET - LISTANNEE -
CONDT
- CODEFONCT - CODEWRK
+ définir ()
JAWRKCD
: Integer : Integer : Integer :
String : String : String : String :
String : String : String
0..*
1..1
- IDENT
- REDAC
- GESAC
- ETAAC
- IDTRANS
- ETATISSUE
- CONDT
- TYPTRANS
- CRIT
- VALCRIT
- RECUPDOS
- PROGRECUP
- PREDRECUP
- ETATFONCT
- PROGRECAUT
- PREDRECAUT
- ANNEE
- CODEFONCT
- CODEWRK
+ définir ()
JAINFET
: Integer : String : String :
String : Integer : Integer : String
: String : String : String : String
: String : String : String : String
: String : String : String :
String
JAWRKFL
- IDENT
- ETATDEP - TRAITDEP - AUTORISE
- CODEISSUE - DESCACT - CHOIXFIN -
ETATISSUE - TRAITISSUE - CODEFONCT -
CODEWRK - ANNEE
: Integer : Integer : String :
String : String : String : String :
String : String : String : String :
String
+ ajouter_param () + modifier () +
suprimer ()
1..1
0..*
JAACPFP
- IDENT
- REDAC
- GESAC
- ETAAC
- CDTYPET
- CODEFONCT
- MTFAC
- PIECE
- CDTAB
- INDMA
- CODACCT
- TYPEATT
: Integer : String : String :
String : String : String : String :
String : String : String : String :
String
+ definir () + suprimer () +
consulter () + modifier ()
0..*
- IDENT
- REDAC
- CDTYPET
- CODAC
- CODEFONCT
- LIBAC
- DESCAC
- PRGCTL
- MSGACC
- PARAMS
- LIBELS
- VALEURS
- CODACCT
- TYPEREGACC
+ ajouter () + consulter () +
supprimer () + modifier ()
JACTLSP
: Integer : String : String :
String : String : String : String :
String : String : String : String :
String : String : String
0..*
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
85
Figure 5.14 : Diagramme de classes « Gestion des
Workflow »
d. La gestion des règles
d'acceptations
JACLCTL
JAFONCT
- IDENT
- REDAC
- CODAC
- LIBAC
- DESCAC
- PRGCTL
- REGLE
- MSGACC
- PARAMS
- LIBPARAMS
: Intege : String : String :
String : String : String : String :
String : String : String
+ definir_critere () + suprimer () +
modifier ()
- IDENT
- CODEFONCT
- NOMTABPRIN
- DATCRT
- DATMOD
- LIBFONC
- DESCFONC
- REDAC
- CODEDOM
- SOUSDOM
- CODEWRK
- TYPEFONCT
- TYPEWRK
: Integer : String : String :
Integer : Integer : String : String
: String : String : String : String
: String : String
- IDENT
- REDAC
- GESAC
- ETAAC
- CDTYPET
- CODEFONCT
- MTFAC
- PIECE
- CDTAB
- INDMA
- CODACCT
- TYPEATT
+ suprimer () + consulter () +
modifier () + definir ()
: Integer : String : String :
String : String : String : String :
String : String : String : String :
String
0--*
1--1
1--1
- IDENT
- REDAC
- CDTYPET
- CODAC
- CODEFONCT
- LIBAC
- DESCAC
- PRGCTL
- MSGACC
- PARAMS
- LIBELS
- VALEURS
- CODACCT
- TYPEREGACC
+ ajouter () + suprimer () +
consulter () + modifier ()
JACTLSP
: Integer : String : String :
String : String : String : String :
String : String : String : String :
String : String : String
0--*
+ creer ()
+ modifier () + consulter () +
suprimer ()
- CODEFONCT
- CODACCT
- TYPECRIT
- CRIT1
- CRIT3
- CRIT2
- VALCRIT2
- VALCRIT1
- VALCRIT3
JACRCTL
: String : String : String :
String : String : String : String :
String : String
+ creer ()
+ modifier () + consulter () +
suprimer () + parametrer ()
JAACPFP
0--*
0--1
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
86
Figure 5.15 : Diagramme de classes « Gestion des
règles d'acceptation »
e. La gestion des attentes
d'informations
JAFONCT
- IDENT
- CODEFONCT
- NOMTABPRIN
- DATCRT
- DATMOD
- LIBFONC
- DESCFONC
- REDAC
- CODEDOM
- SOUSDOM
- CODEWRK
- TYPEFONCT
- TYPEWRK
+ creer ()
+ modifier ()
+ consulter ()
+ suprimer ()
+ parametrer ()
: Integer : String : String :
Integer : Integer : String : String
: String : String : String : String
: String : String
0..'
- IDENT
- REDAC
- GESAC
- ETAAC
- CDTYPET
- CODEFONCT
- MTFAC
- PIECE
- CDTAB
- INDMA
- CODACCT
- TYPEATT
+ suprimer ()
+ consulter ()
+ modifier ()
+ definir ()
JAACPFP
: Integer : String : String :
String : String : String : String :
String : String : String : String :
String
0..'
- REDAC - MTFAC - LM1AC -
LIBEDT
+ suprimer ()
+ consulter ()
+ modifier ()
+ creer ()
JAACPTP
: String : String : String :
String
0..1
0..'
- REDAC - GESAC - ETAAC -
CDTAB - LIBTAB - CDREP - LIBREP
+ creer ()
+ suprimer () + modifier ()
JACTREP
: String : String : String :
String : String : String :
String
- REDAC - GESAC - ETAAC -
IMTFAC - CDTAB - CDREP - INDSUP -
INDCL - CHPCL - INMTFAC - ETATWL -
TRAIT
+ creer ()
+ suprimer ()
+ modifier ()
JAFTREP
: String : String : String :
Integer : String : String : String
: String : String : Integer :
Integer : String
0..'
0..1
1..1 0..'
- IDENT - REDAC - GESAC -
ETAAC - IMTFAC - NUMREL - DURAP -
UNRAP - CDGEN - CDMSG - ETATWL
+ ajouter ()
+ modifier () + suprimer ()
JAACCRP
: Integer
: String
: String
: int
: int
: int
: int
: int
: int
: int
: int
Figure 5.16 : Diagramme de classes « Gestion des
attentes »
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
87
4. Formalisme ou model de description de Workflow
Un formalisme pour la modélisation de processus est un
langage textuel ou graphique qui permet de décrire des modèles de
processus. Il existe diverses techniques et standards pour décrire la
coordination des processus Workflow.
D'un côté, il existe les approches textuelles
pour lesquelles la description de la gestion de flux est définie par un
langage basé sur un alphabet textuel, D'un autre côté, il
existe les approches graphiques où la gestion du flux fait appel
à un alphabet symbolique.
Parmi les standards orientés texte on distingue
XPDL1, un langage pour la définition de procédures
Workflow, développé par le consortium international de gestion de
Workflow (WfMC) à l'aide du langage XML. XPDL est orienté texte,
il possède des caractéristiques comme l'ouverture, la
liberté et l'évolutivité dans la description des
procédures.
Le point faible des formalismes et standards basés sur
des grammaires textuelles est l'absence de représentation graphique, qui
est primordiale pour la description du flux entre les activités, car les
relations causales et temporelles existant entre les activités peuvent
être naturellement détectées et exprimées par des
outils visuels.
Dans les approches graphiques, on trouve :
- le standard IDEF0 qui appartient à la famille des
méthodologies de définition d'intégration pour la
modélisation de fonctions (Integration Definition for Function Modeling
IDEF). La Méthode de Modélisation de Fonctions (Function
Modeling Method) IDEF0 est une méthode conçue pour
modéliser les décisions, les actions et les activités
d'une organisation ou d'un système. IDEF0 a été
dérivé d'un langage graphique bien établi, de l'analyse
structurée et de la technique de conception SADT. IDEF0 est conçu
pour saisir et organiser les informations sur les fonctions
exécutées par une organisation et leurs corrélations en
termes d'entrées, de sorties, de commandes et de mécanismes.
Figure 5.17 : Model IDEF0 de description des processus
Workflow
1 XPDL : XML Process
Definition Language
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
88
Même si ce formalisme est normalisé, ces
modèles présentent des problèmes d'ambiguïté
qui rend difficile leur interprétation.
- Le diagramme d'activités d'UML :
Un diagramme d'activités représente un ensemble
d'activités liées par une transition séquentielle ou
conditionnelle, une synchronisation ou une itération. Plus
récent, les diagrammes d'activités permettent de mettre l'accent
sur les traitements. Ils sont donc particulièrement adaptés
à la modélisation du cheminement de flots de contrôle et de
flots de données. Ils permettent ainsi de représenter
graphiquement le comportement d'une méthode ou le déroulement
d'un cas d'utilisation.
Nous allons donc nous inspirer de cette forme de
représentation qu'est le diagramme d'activités pour
établir un formalisme beaucoup plus proche des concepts présents
dans notre système. Ainsi le formalisme graphique adopté pour
représenter une combinaison état - traitement - transition
quelconque du Workflow est le suivant :
Traitement T
R
Etat S
Etat I
Documents, Attentes, Règles,
Liens
Figure 5.18 : Formalisme général de
description d'une transition Workflow
Dans ce cas simple nous avons un traitement T autorisé
à l'état I et suivant son code issue et le type de transition R
les dossiers appliqués passent à l'état S.
L'état S peut signifier une liste d'états finaux
dans le cas d'une transition manuelle ou sous-condition. Dans ce cas la liste
sera représentée par un rectangle avec une liste de cercles dans
lesquels sont marqués les numéros des états finaux
Ainsi les formes résultantes pour chaque cas de transition
sont les suivantes :
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
89
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page
90
* Transition automatique
A
Etat S
Etat I
Documents, Attentes, Règles, Liens
Figure 5.19 : Formalisme transition
automatique
Traitement T
* Transition manuelle
Traitement T
M
2 5 4
Etat I
Documents, Attentes, Règles, Liens
Figure 5.20 : Formalisme transition
manuelle
* Transition sous condition
Traitement T
C
2 5 4
Etat I
Documents, Attentes, Règles, Liens
Figure 5.21 : Formalisme transition sous
condition
Chapitre 6
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
91
Mise en oeuvre
I. Choix des technologies
La qualité de l'implémentation est fondamentale
dans le cadre du développement d'une application informatique car c'est
elle qui met en valeur toutes les autres travaux menés durant le cycle
de développement (spécification, analyse, conception, etc.) aux
yeux des futurs utilisateurs.
De ce fait, le choix des outils pour la réalisation de
la solution conçue lors de la modélisation doit faire l'objet
d'une étude minutieuse. Pour la mise en oeuvre de notre application,
nous allons nous intéresser aux différentes technologies
permettant de mettre en oeuvre la solution Puis nous procéderons au
choix de celles qui seront utilisées. Cependant ces choix seront
fortement influencés par l'architecture et les technologies
déjà présentes dans le progiciel.
1. J2EE : Plate-forme de développement
Sunshine est implémenté à partir de la
plate-forme J2EE qui s'appuie sur le langage Java et permet de
développer des applications web composées de servlets, JSP (Java
Server Pages) et d'applications métiers à base données.
Java est complètement orienté objet et Il permet
de développer des applications bien structurées, modulables,
efficaces et beaucoup plus facilement maintenables. Ce qui augmente la
productivité des équipes de développement.
J2EE est l'extension serveur de la plate-forme J2SE (Java 2
Standard Edition) de Sun. Elle apporte une certaine standardisation des
serveurs d'applications et fournit un ensemble de services permettant aux
composants de dialoguer entre eux : HTTP et HTTPS, JTA, JDBC, JNDI, EJB, etc.
J2EE est composée de deux parties :
- un ensemble de spécifications pour une infrastructure
dans laquelle s'exécute les
composants écrits en Java : un tel environnement se
nomme serveur d'application ; - un ensemble d'API (Application Programming
Interface) qui peuvent être obtenues et
utilisées séparément.
Sun propose une implémentation minimale des
spécifications de J2EE : le J2EE SDK. Cette implémentation permet
de développer des applications respectant les spécifications
mais
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
92
n'est pas prévue pour être utilisée dans
un environnement de production. Ces spécifications doivent être
respectées par les outils développés par des
éditeurs tiers.
L'utilisation de J2EE pour construire une application propose
plusieurs avantages :
- une architecture d'application basée sur les
composants qui permet un
découpage de l'application et donc une
séparation des rôles lors du développement ;
- la possibilité de s'interfacer avec le système
d'information existant grâce à de
nombreuses API : JDBC, JNDI,
JMS, JCA, etc.
- la possibilité de choisir les outils de
développement et le ou les serveurs
d'applications utilisés qu'ils soient commerciaux ou
libres.
J2EE permet une grande flexibilité dans le choix de
l'architecture de l'application en
combinant les différents composants. Ce choix
dépend des besoins auxquels doit répondre
l'application.
Les API : J2EE fournit à l'application
un ensemble de services : connexions aux bases
de données, messagerie, transactions... L'architecture
J2EE unifie l'accès à ces services au sein
des API. En voici quelques unes très usitées :
- Entreprise java Bean (EJB) : composants serveurs contenant la
logique métier ;
- Remote Method Invocation (RMI) : permet l'utilisation
d'objets java distribués ;
- Java Naming and Directory Interface (JNDI) : accès aux
services de nommage et aux
annuaires d'entreprises ;
- Java DataBase Connectivity (JDBC) : accès aux bases de
données ;
- Java Transaction API (JTA) : support des transactions ;
- Java API for XML Parsing (JAXP) : analyse et exploitation de
données au format
XML.
L'architecture d'une application J2EE se découpe
généralement en trois tiers : - la partie cliente : c'est la
partie qui permet le dialogue avec l'utilisateur ; - la partie métier :
elle encapsule les traitements ;
- la partie donnée : c'est la partie qui stocke les
données.
Avec cette plate-forme de développement adopté
l'architecture qui en découlera sera la suivante :
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
93
Couche présentation
Couche métier
Servlets
Couche donnée
Oracle
SQL Server
DB2
Figure 6.1 : Architecture du système de gestion de
Workflow 2. Langage de représentation graphique des
Workflow
? JLOW (Java Library fOr Workflow)
basé sur JGraph, qui est un API java qui permet la représentation
de données sous formes de graphes. Il peut représenter des
graphes de Workflow, des courbes d'analyse de données. JGraph est fait
à partir de Swing qui est une bibliothèque graphique de Java,
faisant partie du package Java Foundation Classes (JFC), inclus dans
J2SE (Java 2 Standard Edition). Swing
constitue l'une des principales évolutions apportées par Java 2
par rapport aux versions antérieures. Même si les composants Swing
sont décrits comme légers, il nécessite un environnement
d'exécution java coté client et ne pourront être
visualisé avec un navigateur qu'à partir d'un applet java.
? Flash Player permet la création de graphiques vectoriels
et de bitmaps. Pour
être bref Adobe flash est un logiciel d'environnement de
développement intégré (IDE) avec flash player une machine
virtuelle utilisée pour lire les fichiers flash. Mais le terme flash
peut se référer à un lecteur, un environnement ou à
un fichier
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page
94
d'application. Depuis son lancement en 1996, cette technologie
est devenue une des méthodes les plus populaires pour ajouter des objets
interactifs à une page Internet. Flash est léger, bien
répandu. Elle permet de zoomer, déplacer et afficher des
données graphiques avec beaucoup de fluidité et de
précision (ce sont des vecteurs qui sont affichés et non des
images). Mais demeure une technologie propriétaire et payante.
Nécessite un logiciel spécifique (Macromédia Flash).
? SVG : Le SVG (Scalable Vector Graphics) permet
d'écrire des graphiques vectoriels deux dimensions en XML. Il a
été créé en 1998 pour répondre à un
besoin de graphiques légers, dynamiques et interactifs. C'est un
concurrent direct de Flash.
Les avantages de SVG sont nombreux
- Langage libre de droit ;
- Utilise toutes les potentialités du XML ;
- Langage supporté par les technologies d'Internet les
plus communes :
(HTML, GIF, JPEG, JavaScript, ASP, PHP, JSP) ;
- Compression possible d'un fichier SVG jusqu'à 95%.
- Intégration des 3 types d'objets graphiques (vecteurs,
images et textes)
- Nombreux effets graphiques ;
- Zooms et interactivité du document;
- Possibilité d'effectuer des recherches de vocabulaire
dans le graphique
Inconvénients :
- Le plug-in SVG (viewer) n'est encore pas implanté sur
les navigateurs
comme Internet explorer même si Microsoft promet de le
mettre dans les prochaines versions.
- Concurrence avec Flash qui est devenu un vrai standard.
Certes flash a des avantages bien placés mais son
caractère propriétaire est une vrai limite. Ce qui n'est pas le
cas pour les autres qui sont des technologies libres.
Quant à JLOW, son caractère spécifique
pour la représentation de Workflow est un atout. Avec JLOW le formalisme
de représentation des concepts de Workflow sont déjà
défini mais sa dépendance de JGraph pose un problème non
négligeable.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
95
Ainsi notre choix se porte sur la technologie svg qui a un
atout majeur (C'est un langage dérivé de XML). Même s'il
est nécessaire d'avoir un plugin coté client pour le visualiser,
svg présente des avantages beaucoup plus avancés (graphe
vectoriel, interactivité, technologie libre etc.)
3. Présentation de SVG (Graphiques vectoriels
adaptables) :
a. Aperçu sur le graphisme vectoriel :
Un dessin vectoriel est une représentation
composée d'objets géométriques (lignes, points, polygones,
courbes, ....) ayant des attributs de forme, de position, de couleur, etc..,
permettant de produire des images. Il se différencie de cette
manière des images matricielles (ou « bitmap »), dans
lesquelles on travaille sur des pixels.
Par nature, un dessin vectoriel est dessiné à
nouveau à chaque visualisation et est indépendant de la
résolution de l'écran. Le principe de base du dessin vectoriel
consiste à décrire des formes géométriques simples
(arc de cercle ou d'ellipse, segments de droite, courbes de Béziers,..)
auxquelles on peut appliquer différents transformations : rotations,
écrasement, mise à l'échelle. Les effets spéciaux
permettent une grande souplesse : extrusion, effet miroir,
dégradé de formes, morphage, etc.
Ce langage permet d'écrire des graphiques vectoriels
à deux dimensions en XML. Il a été inventé en 1998
par un groupe de travail (comprenant Microsoft, Autodesk, Adobe, IBM, Sun,
Netscape, Xerox, Apple, Corel, HP, ILOG...) pour répondre à un
besoin de graphiques légers, dynamiques et interactifs. SVG semble plus
adapté aux contextes suivants : visualisation de contenus
(économiques, processus, cartes, etc.) au format XML, associée
à JavaScript plus DOM, ou bien à des transformations XSLT... ;
interface utilisateur pour certains types d'applications Internet ; dessins
statiques, animés ou même interactifs dans le monde de
l'éducation.
b. Pourquoi SVG ?
Les raisons pouvant pousser à l'adoption d'un format comme
SVG sont nombreuses :
? Adaptation de l'affichage à des media variés et
à des tailles différentes ;
? Possibilité d'appliquer des styles ;
? Possibilité d'indexer le texte qui fait partie du
graphisme ;
? Taille de l'image après compression ;
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
96
· Facilités d'édition : les
éléments sont des objets, des hiérarchies, etc.
· Liées aux avantages particuliers du format SVG
:
· Insertion dans le monde XML/XHTML :
· Génération de SVG avec XSLT à partir
de données XML ;
· Future intégration totale dans XHTML, viewers
SMIL, etc.
· Utilisation de CSS ;
· Scriptable avec JavaScript via DOM.
· Possibilité de mélanger des grammaires
XML entre elles : un document HTML peut contenir des graphiques SVG, des
expressions mathématiques en Math ML, des présentations en
SMIL...
· Modèle de couleurs sophistiqué, filtres
graphiques (comme dans Photoshop) ;
· Possibilité de partager du code (format texte
non propriétaire) ;
· Meilleures capacités graphiques dans
l'ensemble
SVG n'est actuellement pas supporté en natif par tous
les navigateurs. Si le navigateur ne le supporte pas en natif. Il est donc
nécessaire d'installer soi-même un plugin. Le plus répandu
d'entre eux est, le plugin SVG Viewer 3.03
c. Structure d'une simple page SVG
Un fichier SVG commence par une déclaration de version
XML standard Exemple : <? xml version="1.0" encoding="ISO-8859-1"
standalone="no"?>
Élément racine : La racine d'un
fichier SVG est un élément <svg>. <svg > (...)
</svg> La taille de la fenêtre SVG est définie par les
attributs width et height de l'élément <svg>
Imbrication d'un fichier SVG dans HTML : La
version canonique demande d'utiliser la balise <embed>, sous la forme
<embed src=" fichier_svg.svg" type="image/svg+xml">, il est aussi
possible d'utiliser un environnement iframe : <iframe src=" fichier_svg.svg
" </iframe>
Éléments graphiques de base :
SVG définit un certain nombre d'éléments
graphiques de base. Voici la liste des éléments les plus
importants :
· Texte avec <text> ;
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 97
? Rectangles <rect> ;
? Le cercle <circle> et l'ellipse <ellipse> ;
? Lignes <line> et poli-lignes <polyline> ;
? Polygones, Formes arbitraires avec <path>.
Chaque élément graphique est
représenté par un élément XML qui est
paramétrable avec des attributs XML et hérite d'attributs de ses
parents.
Comme dans d'autres langages vectoriels, il existe des formes
géométriques de base (rectangle, ellipse, cercle, lignes,
poly-lignes et polygone). Il existe également une méthode
permettant de produire des formes complexes.
- Rectangles : L'élément <rect>
permet de définir des rectangles, y compris avec
des coins arrondis.
Les attributs de base sont : x et y, qui donnent la position du coin
supérieur gauche. Width et height, qui permettent de définir
respectivement largeur et hauteur du rectangle.
- Cercles et ellipses : Un cercle est
créé par l'élément <circle> et une ellipse
par
l'élément <ellipse>. Leurs attributs principaux sont
: cx et cy qui définissent les coordonnées du centre , r qui
définit le rayon du cercle, rx et ry qui définissent les
demi-axes x et y de l'ellipse.
- Lignes et poly-lignes : Une ligne est
définie avec l'élément <line>, une poly-
ligne
par l'élément <polyline>. Les attributs de <line>
sont : x1 et y1, qui définissent les coordonnées du point de
départ. x2 et y2, qui définissent les coordonnées du point
d'arrivée. L'attribut de base de <polyline> est points qui prend
comme valeur une suite de coordonnées.
- Polygones et formes arbitraires : Il est possible
de créer et dessiner facilement
des chemins (path) ainsi que des
formes géométriques comme les polygones. L'attribut principal
pour le tracé de chemin est d
4. DOM pour l'Interactivité dans les documents svg
La représentation du Workflow par le langage svg est
très efficace mais ne suffit pas totalement car lors de la
modélisation de Workflow comme à la représentation,
l'utilisateur aura parfois besoin d'interagir avec les éléments
du Workflow. Cette interaction entre l'utilisateur et le document svg en
question peut être gérée par le DOM.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 98
Le Document Object Model (ou DOM) est une recommandation du
W3C qui décrit une interface indépendante de tout langage de
programmation et de toute plate-forme, permettant à des programmes
informatiques et à des scripts d'accéder ou de mettre à
jour le contenu, la structure ou le style de documents. Le document peut
ensuite être traité et les résultats de ces traitements
peuvent être réincorporés dans le document tel qu'il sera
présenté. DOM est essentiellement utilisé pour pouvoir
modifier facilement des documents de base XML.
En tant que spécification du W3C, un objectif important
du Modèle Objet de Document est de fournir une interface de
programmation standard qui puisse être utilisée dans une grande
variété d'environnements et d'applications. DOM est conçu
pour être utilisé avec n'importe quel langage de programmation.
Niveaux de DOM : Il y a plusieurs niveaux dans la
spécification DOM
· DOM 1 : Il permet d'accéder au contenu d'un
document XML ou HTML.
· DOM 2 : Le niveau 2 ajoute des espaces de nom XML, des
vues filtrées, des intervalles, des évènements, etc.
· DOM 3 : Le niveau 3 est en cours. Une interface de
requêtes est attendue ainsi que le chargement et la sauvegarde.
Eléments d'interactivité : Grâce
au DOM 2 niveau à partir duquel les évènements (on click,
onmouseover, onmousemove, onload etc.) sont intégrés, SVG permet
de réaliser les fonctions suivantes
· répondre aux actions de l'utilisateur, comme
presser un bouton du pointeur peuvent démarrer des animations ou
déclencher l'exécution d'un script.
· L'utilisateur peut suivre des liens vers d'autres
pages Web : l'élément <a> par des actions telles qu'un
click de souris quand le pointeur est sur des éléments graphiques
particuliers.
· dans de nombreux cas, suivant les valeurs de
l'attribut 'zoomAndPan' de l'élément <svg> et les
caractéristiques du rendu, les utilisateurs peuvent zoomer ou faire un
panoramique sur le contenu SVG.
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 99
II. Présentation de l'application
A la connexion, l'utilisateur donne son login, son mot de passe
et choisit l'environnement de connexion
Page de connexion
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
100
Menu général
Sous menu domaine Individuel
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
101
Liste Workflow : Fonctionnalité souscription polices
fonds de pension employés
Représentation Workflow : Bande de virements
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
102
Liste Workflow pour paramétrage: Fonctionnalité
souscription nouvelles polices
Interface de paramétrage : ajout d'un
traitement
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page
103
Interface de paramétrage : ajout d'une transition
automatique
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
104
Interface de paramétrage : ajout d'une transition
manuelle
Interface de paramétrage : ajout d'une transition
sous condition
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 105
Conclusion
Le projet qui nous a été confié à
EXTEL consistait à mettre en place un système de gestion de
Workflow afin de permettre aux acquéreurs du progiciel de disposer
d'outils graphiques de modélisation, de représentation et de
suivi des processus Workflow. Notre travail s'est articulé en trois
parties.
Dans un premier temps nous avons justifié le sujet et
présenté un aperçu sur les Workflow et système de
gestion de Workflow.
La deuxième partie était consacrée, au
choix d'une méthode d'analyse et de conception, qui nous permet de bien
mener l'étude du projet (de l'analyse à l'implémentation)
et une étude du système existant.
Enfin la troisième partie décrit l'analyse
proprement dite et la réalisation de la solution découlant de
l'analyse.
Par ailleurs, des idées essentielles nous ont
accompagnés tout au long de notre étude à
savoir :
- Compléter les interfaces graphiques par celle de
simulation d'une instance de processus : En effet cette interface peut nous
permettre d'avoir une vue sur le cheminement d'un cas de Workflow
- Utiliser un langage de définition de Workflow comme
XPDL pour stocker toutes informations d'un Workflow (informations de base,
paramétrage) pour son utilisation par un autre moteur de Workflow.
- On peut aussi appliquer ces outils de modélisation
au module de gestion des batchs : modélisations, simulations de
l'exécution de batchs
Aujourd'hui, nous ne pouvons prétendre avoir accompli
cette partie du travail sans la moindre difficulté. En effet, on a
dû surmonter des problèmes liés au choix de formalisme, de
méthode d'analyse et de langage de représentation graphique,
chacun d'entre eux devant être motivé et exigeant lors de
l'étude des diverses possibilités.
« Mise en place d'un système de gestion de workflow
: Paramétrage, suivi et représentation graphique » | Page
106
Bibliographie
· Glossaire, WfMC-TC-1011, Hollingsworth E.D, ed.1998.
· Terminology & Glossary, WfMC-TC-1011, Hollingsworth
E.D, ed. 1999.
· Workflow Process Definition Interface -- XML Process
Definition Language (XPDL), WFMC-TC-1025, 2005
· Théorie et Pratique du Workflow.
Schaël T, Springer-Verlag, 1997.
· Un environnement G-DEVS/HLA : Application à la
modélisation et simulation distribuée de Workflow, thèse
de doctorat Grégory Zacharewicz, 2006
· Document Technique Sunshine, Abdoulaye Samba 2007
Wébographie
· http://www.extel.fr/ : Documentation sur la
société Extel
·
http://uml.free.com pour la
modélisation avec UML
·
http://fr.wikipedia.org/wiki/Workflow
: Documentation sur les Workflow
·
http://www.wfmc.org/wfmc_publications.htm:
Documentation sur les Workflow
·
http://java.developpez.com/Cours
: Documentations sur java
·
http://svgfr.org?rub=forum : Forum de
code et débogage svg
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page
107
Annexes
? Annexe 1 : Vue Explorateur de package du projet SunshineDev ?
Annexe 2 : Extrait Fichier web.xml : Package Communes.Communs.GesWrk ? Annexe 3
: Extrait fichier svg de représentation de Workflow ? Annexe 4 : Syntaxe
Fichier XML généré après modélisation
Annexe 1 : Vue de l'explorateur de package du projet
SunshineDev
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page
108
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 109
Annexe 2 : Extrait Fichier web.xml : Package
Communes.Communs.GesWrk
<!-- Servlets Communes.Communs.GesWRK -->
<servlet>
<servlet-name>ServPilot</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServPilot</servlet-class>
</servlet>
<servlet>
<servlet-name>ServAffEnchain</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServAffEnchain</servlet-class>
</servlet>
<servlet>
<servlet-name>ServAffHisto</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServAffHisto</servlet-class>
</servlet>
<servlet><servlet-name>ServSuiviWorkflow</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServSuiviWorkflow</servlet-class>
</servlet>
<servlet><servlet-name>ServDebSuiviWorkflow</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServDebSuiviWorkflow</servlet-class>
</servlet>
<servlet><servlet-name>ServAffHistoGed</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServAffHistoGed</servlet-class>
</servlet>
<servlet>
<servlet-name>ServRepWrk</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServRepWrk</servlet-class>
</servlet>
<servlet>
<servlet-name>ServWrkDom</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServWrkDom</servlet-class>
</servlet>
<servlet>
<servlet-name>ServListeWrk</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServListeWrk</servlet-class>
</servlet>
<servlet>
<servlet-name>ServWrkPopup</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServWrkPopup</servlet-class>
</servlet>
<servlet>
<servlet-name>ServWrkLien</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServWrkLien</servlet-class>
</servlet>
<servlet>
<servlet-name>ServWrkRegle</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServWrkRegle</servlet-class>
</servlet>
<servlet>
<servlet-name>ServWrkDetail</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServWrkDetail</servlet-class>
</servlet>
<servlet>
<servlet-name>ServListeWrkDef</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServListeWrkDef</servlet-class>
</servlet>
<servlet>
<servlet-name>ServDefWrk</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServDefWrk</servlet-class>
</servlet>
<servlet>
<servlet-name>ServDefIssue</servlet-name>
<servlet-class>Communes.Communs.GesWRK.ServDefIssue</servlet-class>
</servlet>
<!-- Fin Servlets Communes.Communs.GesWRK -->
Annexe 3 : Extrait fichier svg de
représentation de Workflow
« Mise en place d'un système de gestion de workflow :
Paramétrage, suivi et représentation graphique » | Page
110
Annexe 4 : Syntaxe fichier XML
généré après modélisation
<Workflow>
<etat codetat="1" numord="1" libetat="Saisie Proposition"
>
<traitement codetrait="MAJPOL" libtrait="Mise à jour
Police" >
<transition type="A" issue="SAIVA" etatfinal="2">
<courrier code="code1" />
<courrier code="code2" />
<attentes motif="motif1" valeur="valmotif"/>
<regle code="regle1" parametre="valeur1|valeur2"/>
<lien codefonct="japolip" etatfinal="3"
restric="WNUPO='87875'" />
</transition>
<transition type="M" issue="SAIAN" listetat="2|5|6">
<courrier code="code1" />
<courrier code="code2" />
<attentes motif="motif1" valeur="valmotif"/>
<regle code="regle1" parametre="valeur1|valeur2"/>
</transition>
<transition type="C" issue="SAIAN" listetat="2|5|6"
condition="pred">
<courrier code="code1" />
<courrier code="code2" />
<attentes motif="motif1" valeur="valmotif"/>
<regle code="regle1" parametre="valeur1|valeur2"/>
</transition>
</traitement>
</etat>
</Workflow>
« Mise en place d'un système de gestion de
workflow : Paramétrage, suivi et représentation graphique »
| Page 111
| 
