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
