11.1 RUP : Ontologies de domaine
Nous présentons dans l ontologie de domaine les
concepts du processus générique RUP et les liens entre ces
différents concepts Nous commençons par identifier et
définir les concepts clés de RUP ensuite nous proposons un
modèle et les contraintes associées et enfin nous indiquons
comment accéder a des illustrations de la représentation de ces
concepts en Annexe B
11.1.1 Conceptualisation
· Activité Les rôles possèdent
des activités qui définissent le travail qu ils réalisent
Une activité est un
élément qu un rôle réalise et qui
fournit un résultat dans le contexte d un projet Chaque activité
est composée d étapes et comporte un guide de travail
associé
· Artefact Les activités ont en
entrée et en sortie des artefacts Un artefact est un produit de travail
du
processus les rôles utilisent les artefacts pour
réaliser les activités et produisent des artefacts dans la
réalisation de ces activités Les artefacts sont la
responsabilité d un rôle unique On distingue cinq
catégories d artefacts
Un modèle comme le Modèle des Cas d
Utilisation
Un élément de modèle comme une
Classe de Conception
Un document comme le Document d Architecture
Logicielle
Le code source et les exécutables sorte de composants Les
exécutables en tant que produit logiciel
Dans la catégorie document on distingue trois
éléments
Guide d artefact et Point de contrôle
Les artefacts ont des guides et des points de
vérification associés qui présentent les informations sur
leur développement leur évaluation et leur utilisation Les guides
d artefacts capturent l essence même du travail réalisé
tandis que la description des activités capture l essence de ce qui doit
être fait Les points de vérification fournissent une
référence rapide qui aide à estimer la qualité de l
artefact
Plan type
Les plans types sont des modèles ou prototypes d
artefacts Plusieurs plans types sont associés à la description d
un artefact et peuvent être utilisés pour créer les
artefacts correspondants Les plans types sont liés aux outils à
utiliser
Rapport
Les modèles et éléments de modèle
peuvent avoir des rapports associés Ces rapports extraient les
informations sur le modèle et les éléments de
modèle d un outil
· Discipline Une discipline est une collection d
activités liées par un intérêt majeur pendant tout
le projet Le
regroupement des activités dans une discipline permet de
mieux appréhender le projet du point de vue de l approche
linéaire
· Etape Les activités sont composées
d étapes On distingue trois catégories d étapes
Les étapes de réflexion où l
individu réalisant le rôle comprend la nature de la tâche
rassemble et examine les artefacts en entrée et formule les sorties
Les étapes de réalisation où l
individu réalisant le rôle crée ou met à jour
plusieurs artefacts
Les étapes de revue où l individu
réalisant le rôle inspecte les résultats au moyen d un
certain nombre de critères
· Guide de travail
Les activités peuvent être associées
à des guides de travail Ceux ci présentent des techniques et
des conseils pratiques qui aident le rôle réalisant
l activité
· Guide outil Les activités les
étapes ainsi que les guides associés fournissent un guidage
général Pour aller
un peu plus loin dans les étapes les Guides d outils
sont des éléments additionnels qui fournissent le guidage en
montrant comment réaliser les étapes en utilisant des outils
spécifiques
· Itération
C est une séquence d activités distinctes
accompagnées d un plan type et de critères
d évaluation Elle produit une version interne ou
externe
· Jalon Point d arrêt formel d une phase il
correspond à un point de version
· Jalon Mineur Point d arrêt formel d une
itération il correspond à un point de version
· Phase C est le temps qui sépare deux
jalons du projet pendant lequel un groupe d objectifs bien définis
sont réalisés les artefacts
complétés et les décisions d aller ou non à la
prochaine phase sont prises
· Rôle Le concept central du processus RUP
est le rôle Un rôle définit le comportement et les
responsabilités d un individu ou d un groupe d individus
travaillant ensemble en équipe
· Workflow Un workflow est une
séquence d activités qui produisent en résultat une valeur
observable Un
workflow est généralement associé
à une discipline on parle alors de workflow de discipline qui est
représenté généralement sous forme de diagramme d
activités Ce diagramme d activité comporte les détails de
workflow comme les groupes d activités et les liens entre ceux ci
11.1.2 Formalisation
Modèle
|
|
|
|
Discipline
|
|
|
|
|
|
|
|
nom
|
|
0..* 1
|
description
|
|
|
|
|
|
1
1
1
1..*
0..*
5
Equipe
Workflow
0..*
1
1
0..*
0..*
Itération
JalonMineur
Personne
0..*
0..*
Phase
Jalon
type (maj ou min)
description sujet
0..*
0..*
GuideDeTravail
description sujet
GuideOutil
0..*
Etape
0..*
Guide
type discipline
Artefact
0..*
0..*
1
1
Rôle
1
0..*
0..*
0..*
1
0..*
0..*
discipline
Activité
discipline
Modèle
Document
rôle
planType
activitésEntrée activitésSortie
informations
|
représentationUML rôleResponsable rapports
informations activitésEntrée
activitésSortie
|
|
ElémentDeModèle
Figure 10 RUP: Concepts et liens entre les
concepts
Le modèle de la Figure présente les
différents concepts du processus générique RUP Un projet
utilise une équipe qui est constituée de personnes et celles ci
adoptent un ou plusieurs rôles pour la réalisation des objectifs
du projet Parallèlement un projet utilise aussi le processus
générique RUP Ce processus est découpé en phases
qui représentent sa structure statique et qui se terminent chacune par
un jalon Chaque phase comporte une ou plusieurs itérations qui sont
conclues chacune par un jalon mineur Chaque itération met en oeuvre un
workflow pour son achèvement Ces workflows parties intégrantes de
la dynamique du processus sont constituées de plusieurs activités
appartenant à l une des neuf disciplines du processus Et chaque
activité est réalisée par un rôle prend en
entrée des artefacts et en produit en sortie Chaque rôle qu un
développeur adopte est responsable d un ou de plusieurs artefacts Chaque
activité se décompose atomiquement en étapes et dispose d
un guide de réalisation Les artefacts peuvent être des guides des
modèles des éléments de modèle ou encore des
documents
Contraintes sur le modèle
Les contraintes sur le modèle sont fournies dans SPEM ce
sont notamment les règles C
C C C C etC
11.1.3 Représentation
La représentation des ontologies de domaine consiste
à instancier les éléments du modèle de la Figure
Nous ne présentons pas cela ici Une manière d accéder
à des illustrations est fournie en Annexe B
11.2 RUP : Ontologies des tâches
Nous présentons dans l ontologie des tâches celles
du processus générique RUP et les liens entre ces
différentes tâches Une tâche pour nous sera le trio
Rôle Activité Artefact car une activité est
liée au rôle qui la réalise et aux artefacts produits ou
modifiés Nous commençons par identifier et définir les
groupes d activités puis les activités en les regroupant par
discipline Ensuite nous proposons un modèle et les contraintes
associées et enfin nous fournirons une manière d accéder
à des illustrations Annexe B Les relations entre les groupes d
activités présentées ci dessous se trouvent sur les
différentes Figure et Figure
Nous utiliserons la numérotation suivante afin d y
référer le moment venu xy z x représentera la discipline
pour expression des besoins et pour analyse conception y prendra la valeur pour
un groupe d activités pour une activité pour un artefact pour un
rôle z sera le numéro del élément
concerné
11.2.1 Conceptualisation
11.2.1.1 Expression des Besoins : Groupes d'activités
Analyser le problème Ce groupe d activités
consiste à capturer le
vocabulaire courant développer la vision rechercher les
acteurs et les cas d utilisation et développer un plan de gestion des
besoins
Comprendre les besoins du partenaire Ce groupe d
activités consiste à capturer
le vocabulaire courant développer la vision expliciter
les requêtes du partenaire rechercher les acteurs et les cas d
utilisation gérer les dépendances et réexaminer les
changements de besoins
Gérer les changements de besoins Ce groupe d
activités consiste à gérer les
dépendances réexaminer les changements de besoins
réexaminer les besoins structurer le modèle des cas d utilisation
et réexaminer le rapport
Définir le système Ce groupe d
activités consiste à développer la vision
capturer le vocabulaire courant rechercher les acteurs et les
cas d utilisation et gérer les dépendances
Gérer la portée du système Ce
groupe d activités consiste à développer la
vision gérer les dépendances prioriser les cas d
utilisation et réexaminer les changements de besoins
Affiner la définition du système Ce groupe
d activités consiste à détailler les
cas d utilisation détailler les exigences du logiciel
modéliser et prototyper l interface utilisateur
11.2.1.2 Analyse & Conception : Groupes
d'activités
Définir une architecture candidate Ce groupe d
activités consiste à analyser
l architecture et les cas d utilisation
Réaliser la synthèse architecturale Ce
groupe d activités consiste à analyser
l architecture construire l architecture preuve de concept et
estimer sa viabilité
Analyser le comportement Ce groupe d activités
consiste à analyser les cas
d utilisation identifier les
éléments de conception et réexaminer la conception
Affiner l architecture Ce groupe d activités
consiste à prioriser les cas
d utilisation décrire l
architecture d exécution décrire la distribution identifier les
mécanismes de conception réexaminer l architecture et structurer
le modèle d implémentation
Concevoir les composants Ce groupe d activités
consiste à concevoir les cas
d utilisation les classes de test et les packages les sous
systèmes les capsules réexaminer la conception et
implémenter les composants
Concevoir la base de données Ce groupe d
activités consiste à concevoir les
classes la base de données réexaminer la
conception et implémenter les composants
11.2.1.3 Expression des Besoins : Activités
Développer le plan de gestion des exigences
Pour développer un plan de documentation des exigences
leurs attributs et les guides pour la
traçabilité et la gestion des exigences du
produit
Développer la vision
S entendre sur les problèmes à résoudre
Identifier les partenaires du système
Définir les limites du système
Décrire les premières caractéristiques du
système
Expliciter les requêtes avec le partenaire Pour
savoir qui sont les partenaires du projet
Pour collecter les requêtes sur les exigences à
remplir par le système Pour accorder des priorités aux
requêtes des partenaires
Capturer le vocabulaire courant
Pour définir le vocabulaire commun qui peut être
utilisé dans toutes les descriptions textuelles
du système spécialement dans la description des
cas d utilisation
Rechercher les acteurs et les cas d utilisation Pour
mettre en relief les fonctionnalités du système
Pour définir ce qui sera traité par le
système et ce qui sera traité à l extérieur du
système Pour définir qui et quoi pourra interagir avec le
système
Diviser le modèle en packages avec les acteurs et les cas
d utilisation
Créer les diagrammes du modèle de cas d
utilisation
Développer un aperçu du modèle de cas d
utilisation
Gérer les dépendances
Pour utiliser les attributs et la traçabilité des
exigences du projet pour assister dans la gestion
des limites du projet et la gestion des changements d
exigences
Structurer le modèle de cas d utilisation
Pour extraire le comportement dans le cas d utilisation qui
nécessite d être considéré comme
un cas d utilisation abstrait Comme exemple de ce
comportement on a le comportement courant le comportement optionnel et le
comportement qui sera développé dans les dernières
itérations
Pour rechercher de nouveaux acteurs abstraits qui
définissent les rôles à partager par plusieurs acteurs
Accorder des priorités aux cas d utilisation
Pour définir les entrées à la
sélection constituée de l ensemble des scénarii et cas d
utilisation
qui sont à analyser dans l itération courante
Pour définir l ensemble des scénarios et cas d
utilisation qui représentent des fonctionnalités significatives
et centrales
Pour définir l ensemble des scénarii et cas d
utilisation qui couvrent substantiellement l architecture qui mettent en jeu
plusieurs éléments architecturaux ou qui illustrent un point
délicat et spécifique de l architecture
Détailler un cas d utilisation
Pour décrire le flot d évènements des cas d
utilisation en détail
Pour décrire le flot d évènements des cas d
utilisation de manière à faciliter la compréhension par
les clients et les utilisateurs
Détailler les exigences logicielles
Pour collecter détailler et organiser l ensemble package d
artefacts qui décrivent
complètement les exigences logicielles du système
ou du sous système
Modéliser l interface utilisateur
Pour construire un modèle de l interface utilisateur sur
lequel on peut discuter qu on peut
améliorer et qui est aisé d utilisation
Prototyper l interface utilisateur Pour créer un
prototype d interface utilisateur
Réexaminer les exigences
Pour vérifier formellement que les résultats des
exigences satisfont la vue du client du
système
11.2.1.4 Analyse & Conception : Activités
Estimer la viabilité de l architecture
candidate
Pour évaluer l architecture candidate
synthétisée et déterminer si les exigences critiques de
l architecture sont réalisables et peuvent être
utilisées par ce système ou une autre solution
Analyse architecturale
Pour définir une architecture candidate du système
basée sur l expérience des problèmes de
systèmes ou domaines similaires
Pour définir les modèles d architecture les
mécanismes clés et le conventions de modélisation pour le
système
Pour définir la stratégie de
réutilisabilité
Pour fournir une entrée au planning du processus
Identifier les mécanismes de conception
Pour transformer les mécanismes d analyse en
mécanismes de conception basés sur les
contraintes imposées par l environnement d
implémentation
Identifier les éléments de conception
Pour analyser les interactions des classes d analyse et
identifier les éléments du modèle de
conception
Construire l architecture candidate
Pour synthétiser au moins une solution qui devra
être tout simplement conceptuelle qui
répond aux exigences architecturales critiques
Incorporer les éléments de conception
existants
Pour analyser les interactions des classes d analyse et
rechercher les interfaces des classes de
conception et des sous systèmes de conception
Pour affiner l architecture en incorporant la
réutilisabilité où cela est possible
Pour identifier les solutions courantes aux problèmes de
conception couramment rencontrés Pour inclure des éléments
du modèle de conception significatifs de l architecture dans la section
de la vue logique du document d architecture logicielle
Décrire l architecture d exécution
Pour analyser les exigences concurrentes pour identifier le
processus identifier les
mécanismes de communication interprocessus allouer les
ressources de coordination interprocessus identifier les cycles de vie du
processus et distribuer les éléments du modèle à
travers le processus
Décrire la distribution
Pour décrire comment la fonctionnalité du
système est distribuée le long des noeuds
physiques Ceci est fait juste pour les systèmes
distribués
Concevoir la capsule
Pour élaborer et affiner la description d une capsule
Analyser le cas d utilisation
Pour identifier les classes qui réalisent un flot d
événement de cas d utilisation
Pour distribuer le comportement du cas d utilisation à
ces classes en utilisant les réalisations du cas d utilisation
Pour identifier les responsabilités les attributs et les
associations des classes
Pour noter l usage des mécanismes architecturaux
Concevoir le cas d utilisation
Pour affiner les réalisations du cas d utilisation en
termes d interactions
Pour affiner les exigences sur les opérations des classes
de conception
Pour affiner les exigences sur les opérations des sous
systèmes et ou leurs interfaces Pour affiner les exigences sur les
opérations des capsules
Concevoir le sous système
Pour définir les comportements spécifiés
dans les interfaces du sous système en termes de
collaborations des classes contenues dans le sous
système
Pour documenter la structure interne du sous système
Pour affiner les réalisations entre les interfaces du
sous système et les classes contenues dans le sous système
Pour déterminer les dépendances avec les autres
sous systèmes
Concevoir la classe
Pour s assurer que la classe fournit le comportement des
réalisations du cas d utilisation
requis
Pour s assurer qu il y a assez d informations pour
implémenter la classe sans ambiguïté Pour manipuler les
exigences non fonctionnelles reliées à la classe
Pour incorporer les mécanismes de conception
utilisés par la classe
Concevoir les classes de test et les packages Pour
concevoir les fonctionnalités spécifiques de test
Concevoir la base de données
Pour s assurer que la persistance des données est
efficacement stockée et est consistant
Pour définir le comportement qui doit être
implémenté dans la base de données Réexaminer l
architecture
Pour découvrir un quelconque risque ou des risques
perçus dans l agenda ou le budget
Pour détecter un défaut de conception
quelconque dans l architecture Les défauts d architecture sont reconnus
pour être difficiles à arranger les plus dommageables dans le
processus
Pour détecter des incohérences potentielles
entre les exigences et l architecture conception élevée exigences
non réalistes ou exigences perdues En particulier l évaluation
pourrait examiner plusieurs aspects très souvent négligés
dans les opérations l administration et la maintenance Comment le
système est installé Mis à jour Comment migrer la base de
données courante Pour évaluer une ou plusieurs qualités
architecturales spécifiques la performance la sûreté l
évolutivité la sécurité
Pour identifier les opportunités de
réutilisation
Réexaminer la conception
Pour vérifier que le modèle de conception est
conforme aux exigences du système et qu il sert de bonne base pour son
implémentation
Pour s assurer que le modèle de conception est conforme
au guide général de conception Pour s assurer que le
modèle de conception remplit ses objectifs
11.2.2 Formalisation
Modèle
Le modèle que nous présentons ci dessous
résulte de l adaptation de la structure du processus de SPEM sur la
Figure au processus générique RUP mapping L adaptation a
consisté à affiner la structure d un processus fournie par SPEM
au processus générique RUP
Figure 11 La structure du processus RUP: Rôles,
Activités et Artefacts
Contraintes sur le modèle
Les contraintes que nous utilisons sont celles
présentées dans la structure du processus de SPEM SPEM au
paragraphe de la page
11.2.3 Représentation des concepts
Les diagrammes basiques d UML seront utilisés pour
présenter les différents aspects de RUP en respectant la
standardisation SPEM En particulier nous utiliserons les diagrammes de classe
de package et d activité
Les diagrammes de classe permettent la
représentation des aspects tels l héritage la dépendance
les associations simples les points de commentaires pour les guides par exemple
lien URL les relations Rôle Artefact la structure la décomposition
et les dépendances des artefacts
Les diagrammes de package permettent la
représentation du processus des composants du processus des packages du
processus et des disciplines
Les diagrammes d activité permettent de
présenter la séquence d activité avec leurs entrées
sorties comme des états de flot d objet
11.2.3.1 Les groupes d'activités
Ces deux diagrammes d activités présentent les
groupes d activités constituant les disciplines d expression des
exigences et d analyse conception et leur enchaînement dans un ordre
logique Dans la suite nous nous attarderons sur ces groupes d
activités
Figure 12 Analyse & Conception IRUP03
Figure 13 Expression des exigences IRUP03 02] 02]
Le tableau ci dessous présente les artefacts et les
activités de chaque rôle pour les disciplines d Expression des
Besoins et d Analyse Conception Des illustrations seront
présentées en Annexe B
Expression des Besoins
|
Rôle
|
Artefacts
|
Activités
|
Analyste Système
|
Plan de Gestion des Besoins Requêtes du Partenaire
Glossaire
Vision
Modèle des Cas d Utilisation Spécifications
Supplémentaires Attributs des Besoins
|
Développer le Plan de Gestion des Besoins
Etablir les Requêtes du Partenaire Capturer le Vocabulaire
Courant Développer la Vision
Structurer le Modèle des Cas d Utilisation
Gérer les Dépendances
|
|
Spécificateur des Besoins
|
Cas d Utilisation
Package des Cas d Utilisation Spécification des Besoins
Logiciels
|
Détailler un Cas d Utilisation
Détailler les
Besoins Logiciels
|
|
|
Acteur
Classe Frontière
Historique des Cas d Utilisation Prototype de l Interface
Utilisateur
|
Modéliser l Interface Utilisateur Prototyper l Interface
Utilisateur
|
Architecte Logiciel
|
|
Prioriser les Cas d Utilisation
|
Réexaminateur des Besoins
|
|
Réexaminer les Besoins
|
|
Analyse Conception
Rôle
Artefacts
Activités
Architecte Logiciel
|
Concepteur
|
|
Modèle de Déploiement Document d Architecture
Logicielle
Réalisation du Cas d Utilisation Sous système de
Conception Package de Conception
Classe d Analyse
Classe de Conception
Modèle d Analyse
Modèle de Conception
Preuve du Concept Architectural Architecture de
Référence Interface
Signal
Evènement
Protocole
Estimer la viabilité de
l Architecture Preuve du Concept Analyse Architecturale
Identifier les mécanismes de conception
Identifier les éléments de conception
Construire l Architecture Preuve
du Concept
Incorporer les éléments de conception existants
Décrire l Architecture d Exécution Décrire
la Distribution
|
|
Analyse des Cas d Utilisation Conception des Cas d Utilisation
Conception des Sous systèmes Conception des Classes Conceptions des
Classes de Test et des Packages
Concepteur de BD
|
Modèle de Données
|
Conception de BD
|
|
Concepteur de Capsule
|
Capsule
|
Conception de la Capsule
|
Réexaminateur de l Architecture
|
Pas d artefacts
|
Réexamen de l Architecture
|
Réexaminateur de la Conception
|
Pas d artefacts
|
|
|
|
Tableau 2 Rôles/Artefacts/Activités du RUP
111 Le Système Multi-Agents d'Assistance à la
Modélisation
111.1 Vision du système
Le SM AM dans le cas du processus générique RUP
fournit la connaissance nécessaire à l équipe de
développement pour l adoption des rôles et la réalisation
des activités Il permet le suivi du workflow et des best practices du
processus générique RUP Il permet également l adaptation
du processus générique RUP à un projet et concerne
essentiellement les phases d Expression des Besoins et d Analyse Conception
Le système est un collaborateur un véritable
partenaire du fait qu il assiste le développeur en le guidant en lui
fournissant des explications en contrôlant son travail et en prenant des
initiatives visant a anticiper sur les tâches du développeur C est
un système qui contribue à l efficacité et à l
approfondissement de la réflexion du développeur sur un projet en
cours avec également une possibilité de délégation
pour certaines tâches et d assistance du SMA sur le projet en cours
Ce SMA tire sa connaissance de la base de connaissances du
processus de développement Une connaissance désigne un
élément du processus avec les règles qui l accompagnent La
figure ci dessous présente ces différents
éléments
Interface d'assistance
communique
est assisté
utilise
Developpeur
SMA
accède
BCPD
Systeme Logiciel en cours
Figure Schéma de fonctionnement
met à jour
111.2 Expression des Besoins
Le système devra permettre au développeur de
· Réaliser un projet
· Réaliser les différentes itérations
d un projet
· Réaliser les différentes activités d
une itération
· Réaliser les différentes étapes d
une activité
Il devra également assister le développeur dans
ces différentes tâches et prendre
éventuellement des décisions de
modélisation Assister consiste essentiellement à
· Guider
· Expliquer
· Contrôler
111.3 Acteurs et Rôles
SM AM utilise essentiellement les cinq acteurs du
développement présenté à la Figure
Ce sont essentiellement deux acteurs primaires
Le développeur qui est l utilisateur principal de
notre système c est à lui qu est destiné le système
Il doit disposer de connaissances sur le langage de modélisation
unifié UML
L expert s occupe essentiellement de la mise à
jour de la base de connaissances du processus de développement RUP
à chaque mise à jour par Rational Software ou lorsqu il veut
modifier des connaissances
Et quatre acteurs secondaires
L Agent GUI est un agent interactif qui capture
toutes les actions de l utilisateur et utilise le profil de l utilisateur et
les connaissances des autres agents pour assister le développeur Il s
adapte à l utilisateur L Agent GUI est un agent interface intelligent
qui assiste le développeur dans l interaction et la réalisation
des tâches liées au SM AM dans un environnement intuitif et
agréable Il aide le développeur en l assistant dans son travail
Il peut apprendre par l exemple et accumuler les expériences en
observant et en interagissant avec le développeur ou en s informant chez
ses pairs
L Agent Activité est un agent intelligent qui
dispose des connaissances relatives aux différentes activités du
processus Une activité est définie comme une unité de
travail qu un développeur réalise Le but d une activité
est typiquement de créer ou de développer les artefacts Les
activités sont subdivisées en étapes et chaque
étape est associée à un certain nombre de règles
qui supportent la réalisation de l étape
L Agent Rôle est un agent intelligent qui
dispose des connaissances relatives aux différents rôles du
processus Il connaît également les différentes
activités qu un rôle réalise et les artefacts dont il est
responsable Il suit un développeur dans l adoption d un rôle
particulier Il sera d un apport immense lors de la gestion des équipes
de développement qui sort du cadre actuel de ce travail
L Agent Workflow est aussi un agent intelligent qui
intègre tous les éléments de déroulement du
processus au vu des best practices de celui ci Il utilise également les
éléments de la base de connaissances et la connaissance des
Agents Activité et Rôle pour fournir des éléments d
assistance à l agent GUI Il garde toutes les informations sur le projet
en cours de réalisation
interagit
communique
assiste
Figure Acteurs du système
Les agents réagissent aux événements qui
affectent leurs rôles Une activité est réalisée par
un rôle adopté par le développeur dans l environnement SM
AM Cette activité fait partie intégrante d un workflow du
processus générique RUP qui permet d assister le
développeur dans sa tâche
111.3.1 Les règles
Les règles capturent la connaissance dans SM AM et
servent les agents dans leur raisonnement Une règle est
constituée d une partie condition et d une partie action à l
instar d une clause if then dans les langages de programmation
conventionnels
111.4 Modèle générique
Le Tableau présente les croyances les objectifs et les
plans de nos agents intelligents selon le formalisme BDI Les agents ont
exactement les même plans mais ils les appliquent différemment Les
croyances sont les faits sur les éléments en cours de
réalisation Dépendances concerne les dépendances entre les
différentes activités les différents artefacts tels que
définis par le package Dependencies de SPEM
|
Croyances
|
Objectif
|
Plans
|
Agent Workflow
|
Itération Phase
Discipline
Groupe d activités Activités
Dépendances
|
Suivre et assister une itération
|
Guider Expliquer Contrôler
|
Agent Activité
|
Activité Etapes
Artefacts
|
Suivre et assister une activité
|
Guider Expliquer Contrôler
|
|
|
Dépendances
|
|
|
Agent Rôle
|
Rôle
Activités
Artefacts
|
Suivre et assister un rôle
|
Guider Expliquer Contrôler
|
|
Tableau 3 Les agents : formalisme BDI
Beaucoup plus formellement les agents ont les rôles
suivants
Agent GUI Interface Gérer l interface Agent Workflow
Assistant Guider Expliquer Contrôler Agent Role Assistant Guider
Expliquer Contrôler Agent Activite Assistant Guider Expliquer
Contrôler
Ces différents rôles sont utilisé dans la
réalisation des objectifs du développeur suivant la
description des fonctionnalités détaillées
des agents dans l environnement 111.4.1 Fonctionnalités
détaillées des agents
111.4.1.1 Agent GU1
· Reçois la requête du développeur
· Accède au profil du développeur
· Décide du mode d assistance
· Transmet la requête du développeur à
l agent concerné et reçoit la réponse de celui ci
· Transmet la réponse au développeur
· Affiche les messages d assistance des différents
agents au développeur de manière conviviale
· Reçoit les modalités d interaction du
développeur et s adapte à celui ci en mettant le profil à
jour profiling
· 
Sent la présence du développeur clic par exemple
111.4.1.2 Agent Workflow
· Reçoit la requête de l Agent GUI
· Accède à sa connaissance Base de
Connaissances Connaissances Internes
· Demande des informations appropriées aux autres
agents
· Reçoit les informations des autres agents
· Suit une itération
· Guide le workflow du projet en cours
· Explicite le workflow du projet en cours
· Contrôle le workflow du projet en cours
· Envoie une réponse à l Agent GUI
· Met à jour sa connaissance
111.4.1.3 Agent Activité
· Reçoit la requête de l Agent GUI
·
Accède à sa connaissance Base de Connaissances
Connaissances Internes
· Demande des informations appropriées aux
autres agents
· Reçoit les informations des autres agents
· Suit une activité
· Suit une étape
· Guide l activité en cours de réalisation
par le développeur
· Explicite l activité en cours de
réalisation par le développeur
· Contrôle l activité en cours de
réalisation par le développeur
· Envoie une réponse a l Agent GUI
· Met à jour sa connaissance
Le diagramme suivant présente l activité de l
Agent Activité dans l environnement
L'Agent Activité est toujours en attente des
interactions du développeur. Une recommandation est proposition de
l'agent au développeur tandis qu'une conclusion est le résultat
d'une évaluation.
Fournir la liste des
artefacts et des étapes
[Arrêt]
Capturer les interactions
Fournir des
conclusions ou des
recommandations
Modifier l'état
[Validation]
Contrôler et enregistrer
[Artefact]
[Recommandation]
[Conclusion]
[Etape]
Décrire et fournir les
éléments
à modifier
Décrire et fournir les
éléments
à créer
Contrôler l'étape
Figure 16 Activité de l'Agent Activité
111.4.1.4 Agent Rôle
· Reçois la requête de l Agent GUI
· Accède a sa connaissance Base de Connaissances
Connaissances Internes
· Demande des informations appropriées aux autres
agents
· Reçois les informations des autres agents
· Suit un rôle
· Guide le rôle courant adopté par le
développeur
· Explicite le rôle courant adopté par le
développeur
|
|
|
· Contrôle le rôle courant adopté par le
développeur
· Envois une réponse a l Agent GUI
· Met à jour sa connaissance
111.4.2 1nteractions des agents 111.4.2.1 Agent GU1 -- Agent
Workflow
· L Agent GUI informe l Agent Workflow du début d un
projet
· L Agent Workflow requiert les informations sur le
projet
· L Agent GUI informe l Agent Workflow du début d
une phase
· L Agent Workflow requiert les informations sur la
phase
· L Agent GUI informe l Agent Workflow du début d
une itération
· L Agent Workflow requiert les informations sur l
itération
· L Agent GUI demande de l assistance sur le workflow
· L Agent Workflow fournit l assistance au workflow
· L Agent GUI informe l Agent Workflow de la fin d une
itération
· L Agent GUI informe l Agent Workflow de la fin de la
phase
· L Agent GUI informe l Agent Workflow de la fin du
projet
111.4.2.2 Agent GU1 -- Agent Activité
· L Agent GUI informe l Agent Activité du
début d une nouvelle activité
· L Agent Activité demande les informations sur l
activité
· L Agent GUI informe l Agent Activité du
début d une nouvelle étape
· L Agent Activité demande les informations sur la
nouvelle étape
· L Agent GUI demande de l assistance sur l activité
ou un étape particulière
· L Agent Activité fournit l assistance à l
activité
· L Agent GUI informe l Agent Activité de la fin d
une activité
111.4.2.3 Agent GU1 -- Agent Role
· L Agent GUI informe l Agent Rôle de l adoption d un
rôle par le développeur
· L Agent GUI demande de l assistance sur le rôle
· L Agent Rôle fournit l assistance au rôle
111.4.2.4 Agent Workflow -- Agent Activité
· L Agent Workflow demande des informations sur l
activité en cours de réalisation
· L Agent Activité informe l Agent Workflow sur l
activité en cours de réalisation
111.4.2.5 Agent Workflow -- Agent Role
· L Agent Workflow demande des informations sur le
rôle adopté par le développeur
· L Agent Rôle informe l Agent Workflow sur le
rôle adopté
111.4.2.6 Agent Activité -- Agent Role
· L Agent Activité demande des informations sur le
rôle adopté par le développeur
· L Agent Rôle informe l Agent Activité sur le
rôle adopté
· L Agent Rôle demande des informations sur l
Activité en cours de réalisation
· L Agent Activité informe l Agent Rôle
sur l activité en cours de réalisation
111.5 Scénario
SM AM offre une assistance au développeur Cette
assistance consiste essentiellement à le guider lui fournir des
explications et contrôler son travail Ce scénario décrit la
réalisation d un projet avec SM AM
Le développeur crée un projet en
précisant les informations relatives au projet nom nombre d
itérations L Agent GUI informe l Agent Workflow du début d un
projet Le développeur spécifie une itération L Agent GUI
informe l Agent Workflow qui maintient un ensemble d activités
disponibles pendant cette itération
Le développeur adopte un rôle L Agent GUI informe
l Agent Rôle qui crée une instance pour gérer le rôle
Cette instance maintient un ensemble d activités réalisables par
le rôle concerné et d artefacts dont le rôle est responsable
L Agent Rôle informe l Agent Workflow des activités
réalisables par le rôle
Le développeur décide de réaliser une
activité qu il sélectionne dans la liste des activités en
respectant les précédences fournies par l Agent Workflow L Agent
GUI informe l Agent Activité qui crée une instance pour
gérer l activité Cette instance maintient un ensemble d artefacts
utilisables et produits par l activité
Le développeur réalise une activité en
utilisant les éléments d assistance fournis par l Agent GUI pour
documenter son activité Le développeur crée
également les différents artefacts et peut consulter l
état des artefacts existants fournit par l Agent Workflow
Le développeur réalise également une
activité avec l aide de l Agent Activité qui le guide pas
à pas dans la réalisation des différentes étapes
constitutives de l activité en cours
Le développeur passe ensuite à l activité
suivante fournie par l Agent Workflow
Les Agents Workflow et Rôle interviennent dans la
réalisation d une activité essentiellement au niveau de l
assistance en particulier du contrôle
Le développeur peut enregistrer son projet l importer
au format standard d échange des fichiers de modélisation pour
compléter son travail avec un outil case UML Il peut également
obtenir le rapport de modélisation de SM AM avec des indications qui le
guideront dans ces outils CASE
111.6 Cas d'Utilisation
Nous présentons ici les modèles de cas d
utilisation des trois packages que nous avons
défini plus haut Les noms des cas d utilisation ont
été choisis de manière à lever toute
ambiguïté tout en permettant d avoir une idée en se
référant aux Chapitres II pour le package processus et III pour
les éléments d assistance On peut également se
référer à la description des fonctionnalités des
agents Un modèle détaillé complet est momentanément
disponible sur le site http sm am
«extend»
Agent peut-etre
l'Agent Role, l'Agent Activite, l'Agent GUI ou l'Agent
Processus
«extend»
Figure 17 BCPD : Modèle des Cas
d'Utilisation
«include»
«include»
«include»
Figure 18 Processus : Modèle des Cas
d'Utilisation
«include»
«include»
«include»
«include»
«include»
«include»
Agent peut-etre l'Agent Role,
l'Agent Activite, l'Agent GUI ou
l'Agent Processus
Figure SMA Modèle des Cas d Utilisation
111.7 Architecture du système
Notre système se compose essentiellement de cinq
composants et de trois sous
composants
BCPD Base de connaissances du Processus de Développement
elle contient les ontologies de tâches tâches et liens entre les
tâches et de domaine concepts et liens entre les concepts du processus de
développement Elle constitue la connaissance de certains agents Workflow
Activité Rôle
Interface d assistance Le développeur sera
assisté par les agents au travers d une interface d assistance Toutes
les entrées et les sorties des agents seront capturées à
travers cette interface Cette interface unifie tous les éléments
du système Cette interface intègre également un
gestionnaire de projet qui se charge des tâches liées au projet
à l instar de l importation l exportation la sauvegarde et l ouverture
des projets
Processus Très souvent les organisations et à
moindre échelle les développeurs ont besoin de configurer un
processus générique pour l adapter à leurs projets Le
degré d adaptation ou de personnalisation dépend des objectifs
à atteindre du temps des équipes Ce composant contient les
éléments de configuration du processus ainsi que les
éléments liés aux rôles aux activités et aux
artefacts dans notre système
Profil Utilisateur Ce package contient tous les
éléments de gestion du profil d utilisateur Il constitue la
connaissance de l Agent GUI
SMA C est le noeud du système il contient un ensemble de
règles sur le processus de
développement Il utilise la base de
connaissances du processus pour évaluer ces règles et
les
appliquer au projet en cours On distingue quatre types d agents dans le
SMA l agent
GUI les agents de rôle les agents d activités et l
agent Workflow le détail a été donné
plus haut
Les dépendances entre ces composants sont
représentées sur la Figure
SMA
BCPD
Interface d'assistance
Processus
Activite
Artefact
Role
Figure Composants du système
Profil Utilisateur
111.8 Réalisation des Cas d'Utilisation
Le pont entre l Expression des Besoins et la Conception est la
réalisation des cas d utilisation présenté dans REJ Elle
consiste essentiellement à faire ressortir les interactions avec des
diagrammes de séquence des diagrammes de collaboration ou des diagrammes
d activités Une description complète est fournie sur le site http
sm am
111.9 Diagrammes de Classes
Figure 21 SMA : Structure
Les quatre agents dérivent de la superclasse Agent Les
agents
Workflow Activité et Rôle appliquent leurs plans
guider contrôler et expliquer lorsque des faits peuvent être
consommés L Agent GUI gère le projet en cours
Figure 22 Classes persistantes du SM2AM
Un Projet suit généralement un Processus Le
processus est composé des activités et des rôles
réalisant ces activités Les rôles et les activités
peuvent appartenir à plusieurs processus à la fois Les valeurs de
certain éléments d interface sont gardés au cours de leur
dernier accès dans le Profiling et restitués lorsque le
développeur y accède par la suite
111.1 0 Prototype de l'interface utilisateur
Plusieurs logiciels modernes sont conçus pour interagir
avec des utilisateurs Pour faciliter la communication entre le système
logiciel et les utilisateurs les développeurs ont inventé les
interfaces graphiques utilisateurs Graphical User Interfaces RUP
prône l intégration de l utilisateur final tout au long du
processus afin de minimiser les risques Il est donc nécessaire de
prototyper l interface utilisateur pour lui donner un aperçu du produit
final Nous fournissons ici une description brève suivi d une
illustration à la Figure
L interface comporte un menu principal qui est toujours
affiché Dans ce menu l utilisateur dispose des options comme nouveau
projet ouvrir un projet enregistrer un projet importer un projet exporter un
projet générer le rapport Pour un nouveau projet l ouverture d
un
projet et l importation le développeur précise les
propriétés du projet Il peut également modifier son profil
pour l ouverture d un projet
Senior Architect à Rational Software présente dans
REO une manière
.,
d utiliser les diagrammes d activités de UML pour
détailler la navigation de l utilisateur a travers l interface Il
définit pour cela des stéréotypes comme
presentation pour indiquer une conversation entre l acteur et le
système connector représente la connexion a un autre
diagramme et frame décrit l affichage
111.11 Conclusion
Ce chapitre a présenté le modèle de notre
système L identification des concepts et liens entre concepts et l
identification des tâches et liens entre tâches proviennent
essentiellement d une étude du produit RUP disponible sur le site de
Rational Software Nous avons suivi la méthodologie de
modélisation simplifiée de RUP RUP for Small Project
pour la modélisation de SM AM Cette modélisation telle que
décrite dans le cours en ligne de Rational Software consiste à
identifier les cas d utilisation puis réaliser ces cas d utilisation en
utilisant les diagrammes d interaction puis ressortir les classes Ceci a
été complété par les éléments du RUP
for Small Project
[Quitter]
[Projet]
«presentation»
Main Dialog(minimum)
Affichage, Role, Activite, Modelisation,
Outils et Aide
n'ont pas ete presentes
[nouveau]
[importer]
[exporter]
[enregistrer]
[ouvrir]
[generer]
«presentation»
Nouveau
«presentation»
Importer
«presentation»
Ouvrir
«presentation»
Exporter
«presentation»
Enregistrer
«f r am e»
Ouvrir un document
«presentation»
Rapport
«frame»
Enregistrer un projet
[Proprietes]
«frame»
Ouvrir un projet
[OK]
[conf igurer]
«presentation» Proprietes du nouveau projet
[O [OK]
«presentation»
Proprietes du projet
[valider]
[profil]
[close]
Valider
«connector»
Configuration du
processus
[OK,Annuler]
[OK,Annuler]
Projet complet
avec toutes les
fonctionnalites
«presentation»
Profil
[OK,Annuler]
«presentation»
Main Dialog(GUI)
Figure 23 Déroulement de l'interface de
l'application
cammu Y la?leltin«
Vingt fois sur le métier remettez votre ouvrage
Polissez le sans cesse et repolissez le
Boileau
Nous présentons ici les outils qui nous ont permis de
construire la BCPD Protégé et d implémenter notre
application NetBeans JDOM
La BCPD contenant l implémentation des ontologies de
domaine description du domaine et de tâches quoi
réaliser et comment le réaliser du processus
générique RUP est ensuite présentée
Le SMA suit
Nous terminons par la présentation de l application SM
AM
| 
