WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Génération dynamique d'interfaces spécifiques dans l'exploitation des processus d'ingénierie logicielle en apprentissage

( Télécharger le fichier original )
par Claude Albert MOGHOMAYE
Ecole Polytechnique Yaoundé CAMEROUN - DEA en Sciences de l'Ingénieur option Génie Logiciel 2004
  

précédent sommaire suivant

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.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy