5.4 Architecture Logicielle
Le développement a été fait sous forme de
composants et indépendemment de l'interface. On pourra donc
accéder au système d'assistance et l'utiliser. Nous ne
présentons ici que la distribution pour l'exploitation qui a
été prise en compte au cours du développement. Ces
composants sont :
- processstate contient les classes permettant de gérer
les éléments du processus.
- processengine contient les classes permettant de gérer
la validation des artefacts. - processgui contient les classes de manipulation
des interfaces dynamiques. - bind contient les classes de liaison avec les
fichiers XML.
FIG. 5.1 - Créer un nouveau projet : choisir le
processus
FIG. 5.2 Créer un nouveau projet : spécifier
l'emplacement
FIG. 5.3 Création d'une entité dans
l'activité Elaboration de la solution
FIG. 5.4 - Création d'un acteur dans l'activité
Rechercher les acteurs et les cu
projet contient les classes de gestion de projet.
- sma contient tous les agents qui s'occupent de l'assistance.
- gui contient les classes pour l'interface utilisateur.
- none contient tous les autres éléments.
Le package projet utilise sma pour l'assistance pendant le
déroulement du processus, il utilise également processgui pour
les interfaces spécifiques, ainsi que none. sma utilise gui pour fournir
ses résultats à l'utilisateur, processstate et processengine pour
les éléments d'assistance, ainsi que none.
FIG. 5.5 Architecture logicielle de PERSEE
5.5 Le déploiement des ROSE
Nous avons prévu pour le stockage physique une
arborescence (voir figure 5.6) avec les répertoires correspondants
respectivement aux dimensions Fait, Regle et GUI, ceci afin de nous conformer
à la representation de SPEM. La codification qui y est
présentée est détaillée à la figure 5.7.
Cette codification comporte trois (03) champ : le premier représente le
numéro de la discipline, le second peut prendre les valeurs 0,1,2 ou 3
suivant que l'on ait respectivement des WorkDefinition, des Activity, des
WorkProduct ou des ProcessRole, le dernier numéro indique la position de
l'élément du processus correspondant dans sa classe.
5.6 Elaboration de la BC de MERISE
Pour élaborer la base de connaissances de MERISE, nous
avons été guidé par les méthodologies
définies par Joseph Gabay [Gabay 2001] et Jean-Patrick Matheron
[Matheron 2000]. En effet, il est assez difficile de trouver une
démarche standard de MERISE à l'instar de RUP.
FIG. 5.6 - La répartition physique des ROSE
FIG. 5.7 - La codification des ROSE
Nous présentons ici une énumération
sommaire, accompagnée de codifications, des éléments
constituant la BC de MERISE : les artefacts, les activités et les roles.
Les relations entre les éléments du processus ne sont pas
présentés. Nous présenterons également des
règles sur les artefacts de MERISE. Tout ceci concerne les disciplines
d'étude préalable, de conception générale et de
conception détaillée de MERISE.
5.6.1 Artefacts de MERISE
Nous présentons donc les artefacts de MERISE ainsi que
leur codification :
121 Entité
122 Relation
123 Propriété
124 Processus
125 Opération
126 Evènement-Résulat
127 Syncronisation
221 Entité
222 Relation
223 Propriété
224 Procédure
225 Phase
226 Tâche
321 Table
322 Attribut
323 Procédure
324 Phase
325 Tâche
326 Fonction-Module-DLT
Le lecteur attentionné et connaissant un peu MERISE se
demandera où sont le MCD (Modèle Conceptuel de Données),
le MLD (Modèle Logique de Données), ..., en effet, nous ne les
avons pas rescensés comme des artefacts. Nous nous intéressons
essentiellement aux éléments de modèle et un MCD peut
être vue comme un regroupement d'éléments de
modèles, donc beaucoup plus comme un artefact de type rapport. De plus,
les diagrammes qui sont des regroupements de modèles ne sont pas pris en
compte dans notre démarche, autrement, on aurait déporté
l'attention vers la mise en oeuvre d'un AGL à l'instar de IBM Rational
Rose. Nous préférons rester un frontal avec les AGL. Certains
artefacts (WorkProduct) ont été repétés, c'est
intentionnel et nécessaire d'un point de vue structurel, en effet, un
élément du
processus doit toujours appartenir à une discipline.
Nous utilisons l'artifice de duplication pour gérer les
éléments qui se retrouvent dans plusieurs disciplines, ceci
n'empêche pas que ceci soit géré comme un unique artefact,
ce que nous avons fait.
| 
