IV.1.1.5. Relations entre les cas d'utilisation
métier
Nous allons dans la figure 4-4 suivante montrer les relations
entre les cas d'utilisation et les acteurs.
Figure 4-4 : Diagramme des relations entre
les cas d'utilisation métier.
31
32
Figure 4-5 : Suite du diagramme des cas
d'utilisation.
IV.1.1.6. Classement des cas d'utilisation
métier
Après tout ce travail d'identification des cas
d'utilisation, nous pouvons maintenant les classifier en tenant compte des deux
facteurs suivants (ROQUES, 2002) :
· la priorité fonctionnelle,
déterminée par la Sous-direction des équivalences ;
· le risque technique, estimé par le chef de projet.
Le tableau suivant illustre cette démarche sur notre étude de
cas.
Tableau 4-1 : Classement des cas
d'utilisation
Cas d'utilisation
|
Priorités
|
Risques
|
Gérer dossier
|
Haute
|
Haut
|
Gérer lettre
|
Haute
|
Haut
|
Evaluer dossier
|
Haute
|
Haut
|
Envoyer dossier
|
Haute
|
bas
|
Gérer établissement
|
Moyenne
|
bas
|
|
33
Imprimer
Moyenne
|
bas
|
Paramétrages
|
Basse
|
bas
|
|
Dans ce classement des cas d'utilisation nous avons
distingués trois niveaux d'importance (Haute, Moyenne,
Basse). Les quatre priorités hautes des cas d'utilisation
Gérer dossier, Gérer lettre, Evaluer dossier, Envoyer dossier
sont celles sur lesquelles un accent sera mis tout au long du projet. Au
niveau technique les cas d'utilisation Gérer dossier, Gérer
lettre et évaluer dossier ont été classer avec le
risque le plus haut à cause de leurs complexités de mise en
oeuvre.
IV.1.1.7. Planification du projet en
itérations
À partir du classement précédent, nous
avons effectué le découpage en itérations suivant : Un des
bons principes du Processus Unifié consiste à identifier et lever
les risques majeurs au plus tôt. Nous devons donc prendre en compte de
façon combinée la priorité fonctionnelle et
l'estimation du risque (ROQUES, 2002):
· Si la priorité est haute et le risque
également, il faut planifier le cas d'utilisation dans une des toutes
premières itérations ;
· Si la priorité est basse et le risque
également, on peut reporter le cas d'utilisation à une des toutes
dernières itérations ;
· Lorsque les deux critères sont antagonistes, soit
on essaye de décider en pesant le pour et le contre, soit on
négocier avec les cadres de la SDE pour les convaincre qu'il vaut mieux
pour le projet traiter en premier un cas d'utilisation risqué mais peu
prioritaire, au lieu d'un cas d'utilisation plus prioritaire mais ne comportant
pas de risque (ROQUES, 2002).
Tableau 4-2 : Planifications des
itérations obtenu grâce aux cas d'utilisation.
Cas d'utilisation
|
Priorités
|
Risques
|
Itération#
|
Gérer dossier
|
Haute
|
Haut
|
1
|
Gérer lettre
|
Haute
|
haut
|
2
|
Evaluer dossier
|
Haute
|
Haut
|
4
|
Envoyer dossier
|
Haute
|
bas
|
3
|
Gérer établissement
|
Moyenne
|
bas
|
5
|
Consultation
|
Moyenne
|
bas
|
6
|
Paramétrages
|
Basse
|
bas
|
7
|
|
IV.1.1.8. Traçabilité des cas
d'utilisation avec les besoins textuelles
Nous avons établir dans cette figure des liens de
traçabilité entre besoins textuelles et les cas d'utilisations du
système (voir figure 4-6).
Figure 4-6 : Matrice de relations entre cas
d'utilisation et besoins sous EA.
34
35
Nous déduisons de cette matrice que toutes les besoins
textuelles ont bien été tracés par rapport à au
moins un cas d'utilisation. Par contre, les cas d'utilisation
paramétrages, s'authentifier doivent induire des
nouveaux besoins, puisqu'ils n'ont pas été reliés du tout.
Il est tout à fait courant que l'identification des cas d'utilisation
amène ainsi à une révision des besoins textuels.
IV.1.1.9. Maquette du système
De ces cas d'utilisation nous pouvons déjà
déduire nous marquette du logiciel du suivi des dossiers
d'équivalence suivante (voir figure 4-7).
Figure 4-7 : Maquette système.
IV.1.2. Modèles d'analyse
Les modèles d'analyse vont nous permettre de faire une
description détaillée du système. Nous débuterons
cette description par une présentation de la démarche, ensuite
l'analyse des cas d'utilisations et enfin la réalisation des cas
d'utilisation d'analyse.
IV.1.2.1. Démarche des modèles
d'analyse
Nous rappelons que l'expression préliminaire des
besoins nous a donné lieu à une modélisation par les cas
d'utilisation métier et à une maquette d'interface homme-machine.
Nous allons maintenant apprendre à les décrire de façon
détaillée afin
36
d'obtenir une expression précise des besoins (ROQUES,
2002). La figure 4-8 ci-dessous illustre cette démarche :
Figure 4-8 : Démarche des cas
d'utilisation qui conduisent au diagramme de séquence
et de classes
participantes.
IV.1.2.2. Analyse des cas d'utilisations
L'analyse des cas d'utilisation consiste à
élaborer des diagrammes de cas d'utilisation et faire une description de
ces cas d'utilisation. Ensuite élaborer la matrice de validation,
décrire les opérations système, structurer ces
opérations systèmes en interface et enfin les reliées au
cas d'utilisation.
a) Élaboration du diagramme des cas d'utilisation
d'analyse
Ce diagramme de cas d'utilisation d'analyse est plus
détaillé que celui présenté au paragraphe
précédent. En effet, nous sommes passés dans une phase
d'analyse qui correspond à une vue informatique du système.
~ Diagramme des cas d'utilisation d'analyse du chef de
la Sous-direction
Le diagramme de la figure 4-9 présente les cas
d'utilisation du chef de la sous-direction.
Figure 4-9 : Diagramme des cas d'utilisation
d'analyse du chef de la sous direction.
~ Diagramme des cas d'utilisation d'analyse des cadres
de la Sous-direction Le diagramme de la figure 4-10 présente
les cas d'utilisation des cadres
Figure 4-10 : Diagramme des cas d'utilisation
des cadres.
37
38
Figure 4-11 : Suite du diagramme des cas
d'utilisation des cadres. b) Description des cas d'utilisation
d'analyse
Nous allons décrire chaque cas d'utilisation d'analyse
dans l'ordre des itérations du tableau des planifications. Le tableau
suivant résume l'ordre d'analyse des cas d'utilisation
présenté dans la partie du modèle des cas d'utilisation
précédente.
Tableau 4-3 : Description des cas d'utilisation
d'analyse.
Itération
|
Cas d'utilisation métier
|
Cas d'utilisation d'analyse
|
1
|
Gérer dossier
|
Créer dossier Modifier dossier Supprimer dossier
Rechercher dossier
|
2
|
Gérer lettre
|
créer lettre
|
3
|
Evaluer dossier
|
Evaluer dossier
|
5
|
Envoyer dossier
|
Envoyer dossier
|
6
|
Gérer établissement
|
Créer établissement
|
7
|
Imprimer
|
Lettres
Faux-diplômes Arrêtés
|
|
|
|
Equivalences
|
8
|
Paramétrages
|
Gérer comptes Gérer modèle
|
|
Pour chaque cas d'utilisation, les sous-activités
suivantes de l'activité « Analyse des cas d'utilisation » sont
réalisées :
- Description textuelle du cas d'utilisation ; -
Elaboration du diagramme de séquence ; - Elaboration de l'interface
utilisateur.
Nous allons décrire les sous-activités des cas
d'utilisation suivant : créer dossier, envoyer dossier, créer
établissement, créer compte.
> Use case 1 : Créer
dossier
|
|
|
Figure 4-12 : Use case 1- créer
dossier.
|
|
|
|
|
|
39
1' Acteur principal : Cadres
1' Priorité : 1
1' Objectifs : sauvegarder les informations sur
le dossier des candidats
1' Pré-conditions :
· L'application est lancée,
· Le cadre s'authentifier,
· Le cadre se situé dans la page Gérer
dossier.
40
1' Post-conditions :
· Le dossier a été créé
· La page Gérer dossier est affichée 1'
Scénario nominal :
Tableau 4-4: Scenario nominal use case 1.
|
Action menée par le cadre
|
Action réalisée par le
système
|
|
1- Demande de création du dossier
|
|
|
2- Affiche le formulaire de saisi
|
3- Saisi les données relatives aux dossiers
|
|
4- Valide la saisie
|
|
|
5- Accède à la base de données et y ajoute
les données relatives au dossier
|
|
6- Informe le cadre que le dossier a été
créé
7- Affiche la page Gérer dossier
|
|
1' Alternatives :
· Le système signale le dysfonctionnement au
cadre
· Le système détecte des erreurs ou des
incohérences parmi les nouvelles informations
· Le cadre modifié toutes les informations
erronées et valide de nouveaux 1' Besoin IHM
· Un élément pour demander la création
d'un dossier,
· Un formulaire composé de composants de saisie
(champs de texte, listes de choix, etc.) pour saisir les informations
liées au dossier,
· Une zone de confirmation contenant un
élément de validation et un élément
d'annulation,
· Une barre des tâches pour informer de la
création du dossier ;
41
V' Fonction Qualité Mesure :
Tableau 4-5: Fonction qualité mesure use
case 1.
Fonction
|
Fréquence
|
Qualité
|
Mesure
|
Créer dossier
|
Régulière
|
Rapidité
|
Instantanée
|
|
Gère les accès concurrents aux
données de la base
|
|
V' Diagramme de séquence créer
dossier
Ce diagramme (voir figure 4-13) montre les interactions entre
les cadres et le système.
Figure 4-13 : Diagramme de séquence
créer dossier.
L'interface Homme Machine de la création des dossiers
pourra ressembler au dessin suivant (voir figure 4-10), réalisé
avec l'outil EA, permettant ainsi de relier les dessins de la maquette aux cas
d'utilisation.
|
Figure 4-10 : IHM créer dossier.
|
|
> Use case 2 : Envoyer dossier
|
|
|
Figure 4-14 : Use case 2 envoyer dossier.
|
|
|
42
" Acteur principal : Cadres
" Priorité : 2
" Objectifs : envoyer les dossiers dans un
service
" Pré-conditions :
· L'application est lancée,
· Le cadre s'authentifier,
· Le cadre se situé dans la page Envoyer dossier.
" Post-conditions :
· Le dossier a été envoyé
· La page Envoyer dossier est affichée
43
V' Scénario nominal :
Tableau 4-4: Scenario nominal use case 2.
|
Action menée par le cadre
|
Action réalisée par le
système
|
|
1- Demande d'envoi du dossier
|
|
|
2- Affiche le formulaire d'envoi
|
3- sélectionne le(s) dossier(s) de(s) candidat(s) et le
service
|
|
4- Valide l'envoi
|
|
|
5- Accède à la base de données et y ajoute
les données relatives a l'envoi
|
|
6- Informe le cadre que l'envoi s'est effectué
7- Affiche la page Envoyer dossier
|
|
V' Alternatives :
· Le système signale le dysfonctionnement au
cadre
· Le cadre modifié toutes les informations
erronées et valide de nouveaux V' Besoin IHM
· Un élément pour demander l'envoi des
dossiers,
· Un formulaire composé de composants de
sélection (listes de choix, checkbox, etc.) pour sélectionner les
informations liées a l'envoi du
dossier,
· Une zone de confirmation contenant un
élément de validation et un élément
d'annulation,
· Une barre des tâches pour informer de l'envoi du
dossier. V' Fonction Qualité Mesure :
Tableau 4-5: Fonction qualité mesure use
case 2.
Fonction
|
Fréquence
|
Qualité
|
Mesure
|
Créer dossier
|
Régulière
|
Rapidité
|
Instantanée
|
|
Gère les accès concurrents aux
données de la base
|
|
|
Figure 4-16 : IHM envoyer dossier.
|
|
44
i' Diagramme de séquence envoyer
dossier
Le diagramme de la figure 4-15 suivante montre l'interaction
de l'envoie d'un dossier entre le cadre et le système.
Figure 4-15: Diagramme de séquence
envoyer dossier.
L'interface Homme Machine (IHM) de l'envoi des dossiers pourra
ressembler au dessin suivant (voir figure 4-16).
> Use case 3 : Créer
comptes
|
Figure 4-17 : Use case 3
créer
comptes.
|
|
45
1' Acteur principal : Cadres
1' Priorité : 7
1' Objectifs : Enregistrer les comptes des
cadres
1' Pré-conditions :
· L'application est lancée,
· Le cadre s'authentifier,
· Le cadre se situé dans la page
Paramétrages. 1' Post-conditions :
· les comptes ont été crées
· La page Paramétrage est affichée 1'
Scénario nominal :
Tableau 4-6: Scenario nominal use case
3.
|
Action menée par le cadre
|
Action réalisée par le
système
|
|
1- Demande de création du compte
|
|
|
2- Affiche le formulaire de saisi
|
3- Saisi les données relatives aux compte
|
|
4- Valide la saisie
|
|
|
5- Accède à la base de données et y ajoute
les données relatives au compte
|
|
6- Informe le chef de la sous direction que le compte a
été créé
7- Affiche la page de Paramétrage
|
|
46
i' Alternatives :
· Le système signale le dysfonctionnement au
cadre
· Le système détecte des erreurs ou des
incohérences parmi les nouvelles
informations
· Le chef de la sous direction modifié toutes les
informations erronées et valide
de nouveaux i' Besoin IHM
· Un élément pour demander la création
d'un dossier,
· Un formulaire composé de composants de saisie
(champs de texte, listes de choix, etc.) pour saisir les informations
liées au dossier,
· Une zone de confirmation contenant un
élément de validation et un élément
d'annulation,
· Une barre des tâches pour informer de la
création du compte i' Fonction Qualité Mesure
:
Tableau 4-7: Fonction qualité mesure use
case 3.
Fonction
|
Fréquence
|
Qualité
|
Mesure
|
Créer compte
|
Occasionnelle
|
Rapidité
|
Instantanée
|
|
Gère les accès concurrents aux
données de la base
|
|
i' Diagramme de séquence créer
comptes
Le chef de la sous-direction devra définir au
préalable définir les comptes de tous les cadres qui devront
interagir avec le système. Pour création de chaque compte, il
clique sur le menu administration et choisi le menu nouveau utilisateur. La
figure suivante illustre la suite des opérations.
|
Figure 4-19 : IHM créer comptes.
|
|
47
i' Diagramme de séquence créer
comptes
Ce diagramme montre l'interaction entre le chef et le
système dans la création d'un comptes.
Figure 4-18 : Diagramme de séquence
créer comptes.
L'interface Homme Machine (IHM) de la création de compte
pourra ressembler au dessin suivant.
> Use case 4 : Créer
établissement
|
Figure 4-20 : Use case 4 créer
établissement.
|
|
48
" Acteur principal : cadres
" Priorité : 5
" Objectifs : Créer les
établissements
" Pré-conditions :
· L'application est lancée,
· Le cadre s'est authentifié. "
Post-conditions :
· les établissements ont été
crées " Scénario nominal :
Tableau 4-8: Scenario nominal use case
4.
|
Action menée par le cadre
|
Action réalisée par le
système
|
|
1- Demande de création de l'établissement
|
|
|
2- Affiche le formulaire de saisi
|
3- Saisi les données relatives à
l'établissement
|
|
4- Valide la saisie
|
|
|
5- Accède à la base de données et y ajoute
les données relatives a l'établissement
|
|
6- Informe le chef de la sous direction que
l'établissement a été créé
7- Affiche la page de Pa métrage
|
|
49
V' Alternatives :
· Le système signale le dysfonctionnement au
cadre
· Le système détecte des erreurs ou des
incohérences parmi les nouvelles
informations
· Le chef de la sous direction modifié toutes les
informations erronées et valide
de nouveaux V' Besoin IHM
· Un élément pour demander la création
d'un dossier,
· Un formulaire composé de composants de saisie
(champs de texte, listes de choix, etc.) pour saisir les informations
liées au dossier,
· Une zone de confirmation contenant un
élément de validation et un élément
d'annulation,
· Une barre des tâches pour informer de la
création de l'établissement V' Fonction Qualité
Mesure :
Tableau 4-9: Fonction qualité mesure use
case 4.
|
Fonction
|
Fréquence
|
Qualité
|
Mesure
|
|
Créer compte
|
Occasionnelle
|
Rapidité
|
Instantanée
|
|
Sécurité
|
Gère les accès concurrents aux
données de la base
|
V' Diagramme de séquence créer
établissement
Seul le chef de la sous-direction peut créer un
établissement, car nous avons spécifiés dans les besoins
que le chef approuve les établissements dont le statut est
authentifié au pas (voir figure 4-21).
Figure 4-21 : Diagramme de séquence
créer établissement.
|
Figure 4-22 : IHM créer
établissement.
|
50
L'interface homme machine de création des
établissements pourra ressembler à ceci (voir figure 4-22).
c) 51
Élaboration de la matrice de
validation
La matrice de validation permet de vérifier que l'analyse
du cas est complète, c'est-à-dire que tous les cas d'utilisation
métier ont été intégrés. Elle permet aussi
d'établir une correspondance entre les cas d'utilisation métier
et les cas d'utilisation d'analyse (voir figure 4-23).
Figure 4-23 : Élaboration de la matrice
de validation.
d) Opérations système
Les événements système envoyés par
les acteurs au système LOSEQUIV déclenchent des traitements
internes que nous appellerons opérations système.
L'ensemble des opérations système de tous les
cas d'utilisation définit l'interface publique du système, qui
visualise le système comme une entité unique, boîte noire
offrant des services. En UML, le système pris dans son ensemble peut
être représenté par une classe, avec le mot-clé
«system», comme nous l'avons déjà fait dans les
diagrammes de séquence précédents (ROQUES, 2002). À
la suite de la création des différents DSS et en enrichissant
cette description préliminaire avec les
extensions des cas d'utilisation, nous obtenons la liste
d'opérations système suivante (voir figure 4-24).
|
Figure 4-24 : Opérations
système.
|
Cette liste n'est bien sûr pas exhaustive, car nous n'avons
pas encore décrit dans les détails tous les cas d'utilisation.
Elle sera donc progressivement complétée au fur et à
mesure des itérations successives. On commence cependant à voir
apparaître les fonctionnalités majeures du système,
à un niveau de détail proche de ce qui sera disponible dans
l'IHM.
e) Structuration des opérations systèmes en
interface
Il serait également possible de commencer à
définir des interfaces, pour découper l'ensemble des
opérations en groupes cohérents (voir figure 4-25).
Figure 4-25 : Opérations système
structurés en interfaces.
52
f) Opérations système structurés en
interfaces et reliées aux cas d'utilisation
Nous avons reliées chaque opération
système aux cas d'utilisation dans la figure 4-26 suivante.
53
Figure 4-26 : Opérations système
structurés en interfaces et reliées aux cas d'utilisation.
54
IV.1.2.3. Réalisation des cas
d'utilisation
Après avoir effectué l'analyse des cas
d'utilisation à la section précédente, nous allons donc
passer à la réalisation de ces derniers. Le procédé
de cette réalisation débutera par une identification des concepts
du domaine qui permettra de faire ressortir des entités et attributs.
Par la suite, ces entités et attributs seront mis en associations entre
eux. Enfin une description d'une typologie des classes d'analyse permettra la
réalisation des diagrammes de classes d'analyse participantes du
système. a) Identification des concepts du domaine
L'étape typiquement orientée objet de l'analyse
est la décomposition d'un domaine d'intérêt en classes
conceptuelles représentant les entités significatives de ce
domaine. Il s'agit simplement de créer une représentation
visuelle des objets du monde réel dans un domaine donné (ROQUES,
2002).
Comment identifier les concepts du domaine ? Plutôt que
de partir à l'aveugle et nous heurter à la taille du
problème à résoudre, nous allons prendre les cas
d'utilisation un par un et nous poser pour chacun la question suivante : quels
sont les concepts métier qui participent à ce cas d'utilisation
?
> Pour le cas d'utilisation Gérer dossiers,
nous identifions les concepts
fondamentaux suivants :
· Candidat ;
· Pièces ;
· Dossiers ;
· Etablissement ;
· Session ;
· Diplômes.
> Pour le cas d'utilisation Evaluer dossier, nous
identifions :
· Dossiers ;
· Types ;
· Statut.
55
> Pour le cas d'utilisation Envoyer dossiers, nous
identifions :
· Services ;
· Envoyer ;
· Alertes ;
· Dossiers.
> Pour le cas d'utilisation initier lettre, nous
identifions :
· Lettre ;
· Modèle ;
· Dossier.
> Enfin, pour le cas d'utilisation
Paramétrages, nous identifions :
· Comptes ;
· Modèle.
c) Ajout des associations et des attributs
Une fois que l'on a identifié les concepts fondamentaux,
il est utile d'ajouter :
· les associations nécessaires pour prendre en
compte les relations qu'il est fondamental de mémoriser ;
· les attributs nécessaires pour répondre aux
besoins d'information. Reprenons donc les cas d'utilisation majeurs un par
un.
" Gérer dossiers
Un candidat dépose un dossier pour une session qui est
composé de plusieurs pièces, ce candidat possède un
diplôme qui est obtenu dans un établissement (voir figure 427).
Figure 4-27 : Concepts liés à la
gestion des dossiers.
" Traiter lettre
56
Figure 4-28 : Concepts liés à
l'initiation de la lettre.
Le traitement d'une lettre concerne un dossier appartement
à un modele (voir figure 4-28)
57
1' Evaluer dossiers
Les dossiers font l'objet d'une évaluation (voir figure
4-29).
Figure 4-29 : Concepts liés à
l'évaluation des dossiers.
1' Envoyer dossiers
Les dossiers sont envoyés dans les services et un envoie
possède plusieurs alertes (voir figure 4-30)
Figure 4-30 : Concepts liés à
l'envoie des dossiers.
58
d) Typologie des classes d'analyse
Pour élargir cette première identification des
concepts du domaine, nous allons utiliser une catégorisation des classes
d'analyse qui a été proposée par I. Jacobson et
popularisée ensuite par le RUP. Les classes d'analyse qu'ils
préconisent se répartissent en trois catégories (ROQUES,
2002):
· Celles qui permettent les interactions entre le
système et ses utilisateurs sont qualifiées de
dialogues. Il s'agit typiquement des écrans
proposés à l'utilisateur : les formulaires de saisie, les
résultats de recherche, etc. Ces classes proviennent directement de
l'analyse de la maquette. Il y a au moins un dialogue pour chaque paire
acteur-cas d'utilisation. Ce dialogue peut avoir des objets subalternes
auxquels il délègue une partie de ses responsabilités. En
général, les dialogues vivent seulement le temps durant lequel le
cas d'utilisation est concerné.
· Les classes qui contiennent la cinématique de
l'application sont appelées contrôles. Elles font
la transition entre les dialogues et les concepts du domaine, en permettant aux
écrans de manipuler des informations détenues par des objets
métier. Elles contiennent les règles applicatives et les isolent
à la fois des objets d'interface et des données persistantes. Les
contrôles ne donnent pas forcément lieu à de vrais objets
de conception, mais assurent que nous n'oublions pas de fonctionnalités
ou de comportements requis par les cas d'utilisation.
· Celles qui représentent les concepts métier
sont qualifiées d'entités. C'est elles que nous
avons appris à identifier au début de ce chapitre, cas
d'utilisation par cas d'utilisation. Elles sont très souvent
persistantes, c'est-à-dire qu'elles vont survivre à
l'exécution d'un cas d'utilisation particulier et qu'elles permettront
à des données et des relations d'être stockées dans
des fichiers ou des bases de données.
59
e) Classes d'analyse participantes des cas d'utilisation
du système
Il s'agit de diagrammes de classes participantes (DCP) UML qui
décrivent, cas d'utilisation par cas d'utilisation, les trois
principales classes d'analyse et leurs relations.
Règles
Pour compléter ce travail d'identification, nous allons
ajouter des attributs et des opérations dans les classes d'analyse,
ainsi que des associations entre elles (ROQUES, 2002).
· Les entités vont seulement
posséder des attributs. Ces attributs représentent en
général des informations persistantes de l'application.
· Les contrôles vont seulement
posséder des opérations. Ces opérations montrent
la logique de l'application, les règles transverses
à plusieurs entités, bref les comportements du système
informatique.
· Les dialogues vont posséder des
attributs et des opérations. Les attributs représenteront des
champs de saisie ou des résultats. Les résultats seront
distingués en utilisant la notation de l'attribut dérivé.
Les opérations représenteront des actions de l'utilisateur sur
l'IHM.
Nous allons également ajouter des associations entre les
classes d'analyse, mais en respectant des règles assez strictes :
· Les dialogues ne peuvent être reliés qu'aux
contrôles ou à d'autres dialogues, mais pas directement aux
entités.
· Les entités ne peuvent être reliées
qu'aux contrôles ou à d'autres entités.
· Les contrôles ont accès à tous les
types de classes, y compris d'autres contrôles.
Enfin, nous ajouterons les acteurs sur les diagrammes en
respectant la règle suivante : un acteur ne peut être lié
qu'à un dialogue (voir figure 4-31).
« Entité »
E
« Contrôle »
C
Opération1 () Opération2 () ...
« Dialogue»
D
|
Champ1 Champ2
|
|
Action IHM1 () Action IHM2 () ...
Figure 4-31 : Exemple d'entité, de
contrôle et dialogue.
60
« Contrôle»
Figure 4-32 : Exemple de diagramme de classe
participante.
" Gérer dossier
Le cadre à besoin de créer le dossier du
candidat qui a déposé la demande d'équivalence. Lorsque le
dossier du candidat a été créé, il doit être
en mesure de le modifier lorsque le candidat lui communique d'autres
informations supplémentaires ou de supprimer complètement le
dossier de l'application.
Nous supposerons que nous avons un seul écran, avec un
seul contrôle et un dialogue (voir figure 4-33).
61
Figure 4-33 :DCP gérer dossiers.
62
1' Initier dossier
Une fois que le dossier à été créer,
le candidat initier la lettre du candidat.
Figure 4-34 : DCP Initier lettre.
1' Evaluer dossier
Le cadre veut connaitre le statut du dossier du candidat. Il
s'agit notamment de vérifier si l'établissement qui a
délivré le diplôme a été reconnu, si le
diplôme a été également reconnu par cet
établissement. Il entre les informations du candidat et l'application
lui donne le statut du dossier.
Nous supposerons que la marquette va nous montrer deux
écrans :
· Un écran ou il entre les informations du candidat
;
· Un deuxième qui nous donne les résultats de
l'évaluation. La figure 4-36 suivante illustre ces l'évaluation
des dossiers.
Figure 4-35 : DCP évaluer dossier.
1' Envoyer dossier
63
Figure 4-36 : DCP envoyer dossier.
Le cadre veut envoyer les dossiers des candidats à un
service. Sélectionne les dossiers des candidats et le service, puis
envoi. Nous supposerons que nous avons un seul écran, avec un seul
contrôle et un dialogue (voir figure 4-36).
IV.1.3. Modèles navigationel
Nous allons commencer par présenter la
démarche, ensuite définir quelques conventions
spécifiques, procéder à une structuration de la navigation
et terminer par une représentation des diagrammes de navigation.
IV.1.3.1. Démarche des modèles
navigationnel
Nous avons identifié à la section
précédente les principales classes d'IHM (dialogues) ainsi que
celles qui décrivent la cinématique de l'application
(contrôles). Pour que le tableau soit complet, il nous reste à
détailler une exploitation supplémentaire de la maquette ou une
extension éventuelle de celle-ci. Il s'agit de réaliser des
diagrammes dynamiques représentant de manière formelle l'ensemble
des chemins possibles entre les principaux écrans proposés
à l'utilisateur (ROQUES, 2002). Ces diagrammes s'appellent des
diagrammes de navigation (voir figure 4-37).
64
Figure 4-37 : Démarche de la maquette
et DCP qui conduisent à un diagramme
de navigation.
IV.1.3.2. Conventions spécifiques
Nous allons pousser un peu plus loin et nous servir du concept
d'état pour modéliser plusieurs concepts différents,
grâce aux conventions graphiques suivantes (ROQUES, 2002):
· une page complète de l'application
(«page»),
· un frame particulier à l'intérieur d'une
page («frame»),
· une erreur ou un comportement inattendu du système
(«exception »,
· une liaison vers un autre diagramme d'activité,
pour des raisons de structuration et de lisibilité
(«connector»).
Les concepts de page et de frame sont directement en rapport
avec les classes dialogues du chapitre précédent (voir figure
4-38).
65
Figure 4-38 : Conventions graphiques
spécifiques.
66
IV.1.3.3. Structuration de la navigation
Pour commencer le travail de modélisation, nous devons
d'abord le séparer en ensembles maîtrisables et les plus
indépendants possibles.
Début du diagramme de navigation des acteurs
(voir figure 4-39)
Figure 4-39 : Début des diagrammes de
navigation.
Le cadre se connecte au système à partir de
l'intranet. Il doit saisir son identifiant et son mot de passe dans un frame
particulier. Suivant le résultat du contrôle effectué par
le système, il se retrouve soit sur la page d'accueil propre à
son profil, soit de nouveau sur le frame d'identification avec un message
d'erreur. Nous n'avons pas modélisé la limite de trois erreurs
consécutives pour ne pas compliquer le diagramme, mais il faudrait bien
sûr le faire dans la réalité.
IV.1.3.4. Diagramme de navigation des cas
d'utilisation
Nous pouvons maintenant réaliser un diagramme global de
navigation du système. Il va comprendre l'ensemble des pages, frames et
actions principales des cas d'utilisation. Pour simplifier, nous n'avons pas
repris les exceptions.
Le schéma ainsi obtenu (figure 4-40) est très
intéressant, car il fournit sur une seule page les règles
fondamentales de déplacement dans l'application.
67
Figure 4-40 : Diagramme global simplifié
de la navigation.
IV.2. CONCEPTION
« L'attribution des bonnes responsabilités aux
bonnes classes est l'un des problèmes les plus délicats de la
conception orientée objet. Pour chaque service ou fonction, il faut
décider quelle est la classe qui va la contenir. Les diagrammes
d'interactions (séquence ou communication) sont particulièrement
utiles au concepteur pour représenter graphiquement ses décisions
d'allocation de responsabilités. Chaque diagramme va ainsi
représenter un ensemble d'objets de classes différentes
collaborant dans le cadre d'un scénario d'exécution du
système. Dans ce genre de diagramme, les objets communiquent en
s'envoyant des messages qui invoquent des opérations (ou
méthodes) sur les objets récepteurs. Il est ainsi possible de
suivre visuellement les interactions dynamiques entre objets, et les
traitements réalisés par chacun » (ROQUES, 2002).
Nous débuterons cette conception objet par une
description de la démarche de mise en place, ensuite la
réalisation d'un digramme d'interaction et enfin un diagramme de classes
de conception.
IV.2.1. Démarche de conception objet
Par rapport aux diagrammes de séquence système
du chapitre 4, nous allons remplacer le système vu comme une boîte
noire par un ensemble d'objets en interaction. Pour cela, nous utiliserons
encore dans ce chapitre les trois types de classes d'analyse, à savoir
les dialogues, les contrôles et les entités.
La figure 4-41 ci-dessous illustre la démarche
adoptée :
68
Figure 4-41 : Démarche de
réalisation de diagrammes d'interaction et de classes de
conception
69
Suite de la démarche de réalisation des digrammes
d'interaction et de classes (voir figure 4-42)
Figure 4-42 : Suite démarche de
réalisation de diagrammes d'interaction et de
classes de
conception.
IV.2.2. Digramme d'interaction
L'expression diagramme d'interactions englobe principalement
deux types de diagrammes UML spécialisés, qui peuvent servir tous
les deux à exprimer des interactions de messages similaires :
les diagrammes de communication et les diagrammes de
séquence. Les diagrammes de communication ne feront pas
l'objet de cette étude. Les diagrammes d'interactions font participer
des objets et non pas des classes. Il ne s'agit d'ailleurs pas forcément
d'occurrences spécifiques, mais plus généralement de
rôles possédant un type. Du coup, UML n'utilise pas directement la
notation des instances dans les diagrammes d'objets (nomObjet:NomClasse), mais
une notation légèrement différente, sans soulignement
(nomRÙle:NomType) (ROQUES, 2002).
Pour la représentation des diagrammes d'interaction
nous commencerons par définir quelques règles, ensuite nous
donnerons une notation détaillée. Nous avons choisit de
représenter les diagrammes de séquence qui avaient la
priorité fonctionnelle haute : créer et supprimer dossier,
évaluer et envoyer.
70
IV.2.2.1. Règles de conception des diagrammes de
séquence objet
Nous respecterons également les règles que nous
avions fixées sur les relations entre classes d'analyse, mais en nous
intéressant cette fois-ci aux interactions dynamiques entre objets
(ROQUES, 2002):
· Les acteurs ne peuvent interagir (envoyer des messages)
qu'avec les dialogues.
· Les dialogues peuvent interagir avec les
contrôles.
· Les contrôles peuvent interagir avec les dialogues,
les entités, ou d'autres contrôles.
· Les entités ne peuvent interagir qu'entre
elles.
Le changement de niveau d'abstraction par rapport au diagramme
de séquence système peut ainsi se représenter comme sur la
figure 4-43 ci-dessous.
Figure 4-43 : Passage de l'analyse à la
conception préliminaire Source : (ROQUES, 2002)
IV.4.2.2. Notation détaillée des
diagrammes de séquence
Les diagrammes de séquence représentent les
interactions dans un format où chaque nouvel objet est ajouté en
haut à droite. On représente la ligne de vie de chaque objet par
un trait pointillé vertical. Cette ligne de vie sert de point de
départ ou d'arrivée à des messages
représentés eux-mêmes par des flèches horizontales
(voir figure 4-44). Par convention, le temps coule de haut en bas. Il indique
ainsi visuellement la séquence relative des envois et réceptions
de messages, d'où la dénomination : diagramme de
séquence.
71
Figure 4-44 : Notation détaillé de
diagramme de séquence Source : (ROQUES, 2002)
Tout message est bon pour créer une instance, mais la
convention UML que nous appliquerons ici veut que l'on utilise à cet
effet un message standardisé appelé create. Le message create
peut comprendre des paramètres d'initialisation. Il peut s'agir, par
exemple, d'un appel de constructeur avec paramètres en Java ou en C#
(ROQUES, 2002).
De même, lorsque nous souhaiterons montrer explicitement
la destruction des objets, nous utiliserons le message standardisé
destroy.
> Diagramme de séquence créer dossier
(voir figure 4-45)
Figure 4-45 : Diagramme de séquence
détaillée créer dossier.
Le cadre entre les paramètres de création du
dossier, le dialogue passe la main à un contrôleur qui va
créer l'objet. Il peut aussitôt optionnellement évaluer le
dossier créé.
Nous n'avons représenté que le scénario
nominal sur ce diagramme ci-dessus, Cela signifie que tout « se passe bien
», le cadre abouti à la création du dossier.
Les cas d'erreur sont abordés avec le diagramme suivant
(voir figure 4-46).
Figure 4-46 : Diagramme de séquence
détaillée créer dossier avec erreur. >
Diagramme de séquence suppression d'un dossier
La suppression ne peut être possible que si on a
supprimé au préalable le candidat, diplôme et pièces
correspondant au dossier (voir figure 4-47).
72
Figure 4-47 : Diagramme de séquence
détaillée suppression dossier.
73
> Diagramme de séquence d'évaluation
d'un dossier (voir figure 4-48)
Figure 4-48 : Diagramme de séquence
détaillée évaluer dossier.
Le cadre entre le nom du dossier avant évaluation, si
ce dossier existe, il sera évalué. La fin de l'évaluation
nous indique si le dossier doit être approuvé ou rejeté. Le
diagramme suivant permet aux cadres de valider le statut du dossier (voir
figure 4-49).
Figure 4-49 : Diagramme de séquence
détaillée valider statut dossier.
74
> Diagramme de séquence envoyer dossier (voir
figure 4-50)
Figure 4-50 : Diagramme de séquence
détaillée envoyer dossier.
IV.2.3. Classes de conception
En partant du modèle d'analyse (voir section IV.2),
nous allons affiner et compléter les diagrammes de classes participantes
obtenus précédemment. Nous allons utiliser les diagrammes de
séquence que nous venons de réaliser pour (ROQUES, 2002):
· Ajouter ou préciser les opérations dans
les classes (un message ne peut être reçu par un objet que si sa
classe a déclaré l'opération publique correspondante).
· Ajouter des types aux attributs et aux
paramètres et retours des opérations.
· Affiner les relations entre classes : associations
(avec indication de navigabilité), généralisations ou
dépendances.
Nous utiliserons également le travail
réalisé à la section (IV.3) sur la navigation pour ajouter
les éventuels dialogues qui manquaient.
Nous débuterons cette conception par la
présentation de la méthode des liens durable ou temporaires qui
donnera lieu à une association navigable entre les classes
correspondantes ou une relation de dépendance. Ensuite une structuration
en package de classes en trois couches : couche présentation, couche
logique Applicative et la couche logique métier.
IV.2.3.1. Méthode des liens durable ou
temporaires
Un lien durable entre éléments va donner lieu
à une association navigable entre les classes correspondantes ; un lien
temporaire va donner lieu à une relation de dépendance.
« Sur l'exemple du schéma ci-dessous, le lien
entre les éléments: A et :B devient une association navigable
entre les classes correspondantes. Le fait que l'élément :A
reçoive en paramètre un message d'une référence sur
un objet de la classe C induit une dépendance entre les classes
concernées » (ROQUES, 2002).
Figure 4-51 : Exemple liens temporaires et
dépendances.
Figure 4-53 : DCP détaillé
évaluer dossier
75
> Diagramme de classe participante évaluer
dossier (voir figure 4-53)
> Diagramme de classe participante gérer
dossier (voir figure 4-52)
Figure 4-52 : DCP détaillé
gérer dossier.
76
Figure 4-54 : DCP détaillé
envoyer dossier.
> Diagramme de classe participante envoyer dossier
(voir figure 4-54)
77
IV.2.3.2. Structuration en packages de
classes
« Pour structurer notre modèle, nous allons
organiser les classes et les regrouper en ensembles cohérents. Pour ce
faire, nous utilisons une fois de plus le concept général d'UML,
le package » (ROQUES, 2002).
Les systèmes informatiques modernes sont organisés
en couches horizontales, elles-mêmes découpées en
partitions verticales. Cette découpe est d'abord logique, puis
éventuellement physique en termes de machines.
Nous allons donc structurer les classes identifiées
jusqu'à présent en trois couches principales :
· une couche Présentation, rassemblant toutes les
classes dialogues ;
· une couche Logique Applicative, rassemblant toutes les
classes contrôles ;
· une couche Logique Métier, rassemblant toutes les
classes entités ;
L'architecture logique de notre étude de cas est ainsi
représentée par un premier diagramme de packages, comme
illustré par la figure 4-55 ci-dessous.
|
Figure 4-55 : Diagramme de packages
de
l'architecture logique.
|
|
V' Architecture en couches
« Le principal objectif de la séparation en
couches est d'isoler la logique métier des classes de
présentation (IHM), ainsi que d'interdire un accès direct aux
données stockées par ces classes de présentation. Le souci
premier est de répondre au critère d'évolutivité :
pouvoir modifier l'interface de l'application sans devoir modifier les
règles métier, et pouvoir changer de mécanisme de stockage
sans avoir à retoucher l'interface, ni les règles métier
»2.
Si nous répartissons maintenant les classes
identifiées précédemment, nous obtenons une structuration
comme celle illustrée sur la copie d'écran 4-52, issue de l'outil
Enterprise Architect.
Figure 4-57 : Détail de l'architecture
logique
2 ROQUES Pascal (2002), p.140
78
« La structuration des couches Présentation et
Logique Applicative peut s'effectuer en tenant compte des cas d'utilisation. La
structuration de la couche Logique Métier est à la fois plus
délicate et plus intéressante, car elle fait appel à deux
principes fondamentaux : cohérence et indépendance »
(ROQUES, 2002).
V' Le premier principe consiste
à regrouper les classes qui sont proches d'un point de vue
sémantique. Un critère intéressant consiste à
évaluer les durées de vie des instances et à rechercher
l'homogénéité. Par exemple, les entités
Modèles, Services et Etablissement ont une durée de vie de
plusieurs mois, voire de plusieurs années. En contrepartie, les concepts
de Envoyer et Evaluer sont beaucoup plus volatiles. Il est donc naturel de les
séparer dans des packages différents.
V' Le deuxième principe
s'efforce de minimiser les relations entre packages, c'est à-dire plus
concrètement les relations entre classes de packages différents.
Les considérations précédentes amènent à une
solution naturelle consistant à découper le modèle en
trois packages comme indiqué sur la figure 4-58. Les packages ainsi
constitués vérifient bien les principes de forte cohérence
interne et de faible couplage externe.
79
Figure 4-58 : Découpage en packages
montrant leur indépendance.
Figure 4-59 : Suite découpage en packages
montrant leur indépendance.
IV.2.3.3. Diagrammes de classes des packages de la couche
métier Terminons ce chapitre en peaufinant les diagrammes de
classes de chacun des packages.
Figure 4-60: Diagramme de classe du package
dossier.
80
i' Diagramme de classe du package dossier (voir 4-60)
i' Diagramme de classe du package traitement
Figure 4-61 : Diagramme de classe du package
traitement. i' Diagramme de classe du package suivi (voir figure 4-62)
81
Figure 4-62 : Diagramme de classe du package
suivi.
Figure 4-63 : Diagramme synthétique.
82
Les dépendances entre packages de la couche
métier sont représentées sur le diagramme
synthétique de la figure 4-63.
83
| 
