Au Seigneur Dieu Tout Puissant
L éternel mon
berger
A la mémoire de ma mère feu Rebecca
DJUIKOM
Qui n a pas vécu assez longtemps
Pour encadrer ses
enfants
A mon père Charles MOGHOMAYE
Qui n a jamais
ménagé d efforts
Pour l éducation de ses enfants
A la mémoire de mon oncle feu Albert
FOTSO
Je dédie ce mémoire
lailfflefflge
Ce mémoire a été réalisé au
sein du Laboratoire d Informatique du Multimédia et Applications de l
Ecole Polytechnique du Cameroun pendant le premier semestre de dans le cadre du
mémoire d ingénieur de conception en informatique Les bases de ce
travail proviennent de l Université du Québec A Montréal
depuis l année
J aimerai ici rendre gloire au Seigneur Dieu Tout
Puissant pour la grâce qu il m a accordée tout au long de mes
études ainsi que pour celle à venir
Je remercie particulièrement le P Janine
MAGNIER pour avoir accepté d apporter sa caution scientifique
à ce travail en tant que Présidente du jury
Qu il me soit ici permis d exprimer ma gratitude aux
enseignants D Eric BADOUEL D Guillaume KOUM qui ont bien voulu
apporter leur caution scientifique à ce travail en acceptant d
être membres du jury
Je souhaite à tous les étudiants de disposer d
encadreurs comme D Claude TANGHA et D Roland YATCHOU Leurs
disponibilités leurs promptitudes leurs critiques et leurs conseils ont
beaucoup guidé la réalisation de ce travail qui est beaucoup plus
le reflet du leur
Je n oublierai pas d adresser un merci tout aussi particulier
au P Roger NKAMBOU et à M Raphaël NBOGNI pour
avoir initié le projet et pour le suivi de celui ci
Je tiens à témoigner toute ma reconnaissance a
ceux qui depuis toujours ont oeuvré pour mon épanouissement
intellectuel la famille MOGHOMAYE Charles Chantal Julienne Alexis Mary et
Joël
A tous mes camarades de la promotion GI compagnons de
bataille durant les cinq
dernières années je souhaite à tous de
réussir dans leurs carrières professionnelles
A tous les membres du LABORIMA à qui je
souhaite de savoir tirer le meilleur de ce laboratoire et d oeuvrer pour son
rayonnement
A tous ceux Michel YOUMBI Solange MAGNE La famille KENGNE
Herve DONFACK Ghislain NGANTCHAHA Pierre Marie OUM SACK Yves WANKO Hervé
FONDJA Achille TCHAPI Gérard KOM qui se reconnaîtront dans ce
travail et dont l apport a été considérable pour sa
réalisation
MM
La complexité sans cesse croissante des applications
logicielles amène le génie logiciel à rechercher
constamment de nouvelles méthodologies pour construire des logiciels
faciles d utilisation et supportant l évolutivité Ces
méthodologies à l instar du processus générique
Rational Unified Process RUP de Rational Software elles mêmes
très complexes définissent très souvent des approches de
modélisation et des manières de travailler Les outils CASE
proposent une assistance à la façon de modéliser mais peu
d outils s intéressent au déroulement des activités du
processus Ce déroulement est essentiellement guidée par une
kyrielle de documents fournis par les auteurs de la méthodologie
Une approche basée sur l utilisation d un
Système Multi Agents SMA d agents intelligents pour assister le
développeur dans la réalisation de ses logiciels en lui
fournissant le How To Do Knowledge la connaissance sur le comment
faire est une solution idoine Nous proposons ici la réalisation d un
Système Multi Agents d Assistance à la Modélisation SM
AM Notre système s intéresse essentiellement à l
assistance au développeur pendant les disciplines d Expression des
Besoins et d Analyse Conception du processus générique de
développement RUP
L aperception de ce système a nécessité d
identifier dans le processus générique RUP les
éléments pouvant permettre d assister le développeur dans
l utilisation du processus Ensuite il a fallu formaliser ces
connaissances et les implémenter dans une Base de Connaissances du
Processus de Développement BCPD générique RUP Cette
formalisation a suivi la spécification SPEM Software Process
Engineering Metamodel de l Object Management Group OMG un méta
modèle pour la représentation des processus d ingénierie
logicielle
Cette BCPD est ensuite exploitée avec efficience par le
SMA qui dispose des éléments d assistance pour assister
effectivement le développeur dans son travail en utilisant aussi la
connaissance sur le profil du développeur profiling Elle
constitue le blackboard de nos agents
Mots Clés Assistance Génie Logiciel SMA RUP Base de
Connaissances
&MW
The increasing complexity of software applications has caused
the software industry to constantly seek new methodologies in order to build up
easily usable software which supports evolutivity These methodologies which
include the generic process Rational Unified Process RUP of Rational
Software are themselves very complex and very often define a way of modelling
and a way of working Whereas the CASE tools propose an assistance to the way of
modelling little tools give a regard to the way of working throughout the RUP
This way of working is primarily given by a great number of documents provided
by authors of methodology
An approach is using a Multi Agents System MAS where
intelligent agents assist the developer in the realization of his software by
providing him the How To Do Knowledge the how to do knowledge We
propose here a Multi Agents System for Modeling Assistance MASMA Our system
primarily assists the developer during the RUP s disciplines of Requirements
and Analysis Design
The construction of this system has required the
identification of elements which can allow assistance to developer throughout
the process Then it was necessary to formalize these knowledges and to
implement them in a Knowledge Base of Development Process KBDP RUP This
formalization follows SPEM Software Process Metamodel Engineering
specification of the Object Management Group OMG a meta model for the
representation of the software process engineering
This KBDP is exploited by the MAS which has knowledge in
assistance to assist indeed the developer in his work by also using knowledge
on his profile profiling It represents the blackboard of our agents
Keywords Assistance Software Engineering MAS RUP Knowledge
Base
»WI§
DEDICACES i
REMERCIEMENTS i
RESUME ii
ABSTRACT iii
Sommaire iv
Table des Illustrations vi
TABLEAUX vii
Sigles et Abreviations vii
CaA??e« 1 Introduction
I Contexte
II Description du projet CIAO
III Notre apport dans le projet CIAO
IV Plan du mémoire
CaA??eEE 11 Problématique
I Un processus d ingénierie logicielle une introduction
I Définition
I Avantages d un processus
I Le cycle de développement
I UML dans le processus de développement
II Expression des besoins
II Problème
II Position du produit
II Spécification supplémentaires
III Approches existantes
III NATURE
III CPCE
III Argo Project
III ALF Project
III ArgoUML
III WayPointer
IV Analyse
V Conclusion
CaA??e« 111 Méthode et concepts
I Concevoir un SM AM La méthode
II Présentation des concepts
II RUP Un processus générique
II L assistance
II Un Système Multi Agents
II Une Base de Connaissance du Processus de
Développement
III Conclusion
CEApnna lV Modélisation
I Outils de Modélisation
II Les ontologies de domaine et de tâches du RUP
II RUP Ontologies de domaine
II RUP Ontologies des tâches
III Le Système Multi Agents d Assistance à la
Modélisation
III Vision du système
III Expression des Besoins
III Acteurs et Rôles
III Modèle générique
III Scénario
III Cas d Utilisation
III Architecture du système
III Réalisation des Cas d Utilisation
III Diagrammes de Classes
III Prototype de l interface utilisateur
III Conclusion
CRapnea V Réalisation
I Outils de réalisation
II Une Base de Connaissances du Processus de
Développement RUP
III Un SMA pour l exploitation de la BCPD
IV Une Assistance au développeur avec le SM AM
IV Présentation de l interface
IV Déroulement du scénario
V Conclusion
Canp?e« Vl Conclusion
I Synthèse
II Critiques propres
III Perspectives BIBLIOGRAPHIE WEBOGRAPHIE GLOSSAIRE ANNEXE A
Le Meta Modele SPEM ANNEXE B Acceder au site RUP ANNEXE C La BCPD RUP
vaum le ima??a?»
Figure Architecture de CIAO SI
Figure Le processus d ingénierie logicielle
Figure La Boite Noire du RUP
Figure Présentation schématique de RUP selon
axes RUP
Figure Classification de Nwana HSN
Figure Architecture BDI
Figure Formats d échange et formalismes
Figure La pyramide des niveaux de modélisation
Figure Modèle conceptuel de SPEM SPEM
Figure RUP Concepts et liens entre les concepts
Figure La structure du processus RUP Rôles
Activités et Artefacts Figure Analyse Conception RUP
Figure Expression des exigences RUP
Figure Schéma de fonctionnement
Figure Acteurs du système
Figure Activité de l Agent Activité
Figure BCPD Modèle des Cas d Utilisation
Figure Processus Modèle des Cas d Utilisation
Figure SMA Modèle des Cas d Utilisation
Figure Composants du système
Figure SMA Structure
Figure Classes persistantes du SM AM
Figure Déroulement de l interface del
application
Figure SM AM Interface
Figure Créer le projet sous Rational
Figure Exporter le projet sous Rational
Figure Importer Figure Nouveau Figure
Nouveau Figure Nouveau Figure Adopter un rôle
Figure Sélectionner une itération
Figure Sélectionner un groupe d
activité
Figure Créer un acteur
Figure Vue du projet
Figure Explications
Figure Rapport
Figure Contrôles Figure Process Structure
de SPEM Figure Dependancies de SPEM Figure Exemple RUP
site
ia1311a??
Tableau Comparaison des différentes approches
Tableau Rôles Artefacts Activités du RUP Tableau Les
agents formalisme BDI
81??Bt BU alliBe?Uhit
Agent Working Group
Base de Connaissances du Processus de Développement
Computer Assist Software Engineering
Conception Intelligemment Assistée par Ordinateur des
Systèmes d Information
Foundation of Intelligent Physical Agents
Laboratoire d Informatique du Multimédia et
Applications
Object Constraint Language Object Management Group Rational
Unified Process Système Multi Agents
SMA d Assistance a la Modélisation
Software Process Engineering Metamodel
Unified Modelling Language
chapitre 1
I Contexte
Ce projet s inscrit dans le cadre d un projet global
dénommé CIAO SI Conception Intelligemment Assistée par
Ordinateur des Systèmes d Information Ce projet a été
initié par le Groupe Infotel et le laboratoire GDAC Gestion
Diffusion et Acquisition des Connaissances de l Université du
Québec A Montréal UQAM Il est réalisé en
partenariat avec le Laboratoire d Informatique du Multimédia et
Applications LABORIMA de l Ecole Nationale Supérieure
Polytechnique de Yaoundé depuis deux ans
II Description du projet CIAO
Les projets de génie logiciel sont confrontés
très souvent à un problème récurrent celui de
produire et maintenir des logiciels de complexité élevée L
application des méthodologies de développement de logiciels
paraît nécessaire pour garantir un minimum de qualité des
logiciels produits C est ainsi que de nombreuses méthodologies ont
été développées durant les trois dernières
décennies Seulement les méthodologies les plus complètes
présentent elles mêmes une complexité certaine due au
nombre élevé d artefacts exigés aux règles de la
méthodologie et à leurs processus plutôt compliqués
à mettre en oeuvre Il ne fait plus de doute que le développeur a
aujourd hui besoin de plus d assistance qu avant que ce soit face à la
complexité grandissante des problèmes à résoudre ou
à celle des méthodologies de développement
utilisées dans les différents projets
CIAO SI vise l étude de faisabilité la
conception et la mise en oeuvre d un système permettant d offrir une
assistance au concepteur pendant le processus de développement de
logiciels et de capitaliser l expérience acquise avec le
développement d applications en constituant une mémoire de
modèles de conception réutilisables
CIAO SI NGA utilise une approche Case Based Reasonning
CBR raisonnement à base
de cas qui préconise la résolution de nouveaux
problèmes par adaptation des solutions viables aux problèmes
similaires déjà résolus
CIAO SI comporte sept modules
La gestion des ontologies Ce module consiste à
spécifier les ontologies du domaine d application et ceux du processus
de développement puis construire les bases de connaissances
associées au domaine d application ainsi qu aux deux processus de
développement MERISE et RUP
La gestion des cas Il s agit de définir la
structure d un cas en prenant en compte toutes les étapes d un processus
de développement et permettre la création et la mise à
jour des cas
L exploitation des cas Permet de mettre en oeuvre des
techniques d indexation et de recherche des cas
L adaptation des cas On spécifie et on
construit un système pour l adaptation des cas Le système
pourrait être constitué d un agent spécialisé dans l
adaptation des cas et d un agent interface
L intégration Il s agit d intégrer les
sous systèmes déjà construits gestion des cas recherche
des cas adaptation des cas en vue de produire la première version
utilisable prototype du système CIAO SI
La gestion de l assistance A pour but de
spécifier concevoir et construire un système pour l assistance du
concepteur pendant le processus de développement
La réutilisation du code La finalité est d
étendre le système CIAO SI à la réutilisation au
niveau du code source
Figure 1 Architecture de CIAO-SI
Deux étudiants ont déjà eu à
travailler respectivement dans la gestion et l exploitation des
cas la mise en oeuvre des ontologies du domaine d application
III Notre apport dans le projet CIAO
Nous intervenons primordialement dans la gestion des ontologies
du processus de
développement générique RUP par
La réalisation d une ontologie des tâches
spécifiant les tâches et liens entre tâches pour les
différentes disciplines du cycle de développement
associées au RUP
La réalisation d une ontologie de domaine
spécifiant les concepts et liens entre concepts manipulés dans
les différentes disciplines du cycle de développement
associées au RUP
La construction de la Base de Connaissances du Processus de
Développement BCPD générique RUP
Une simulation de l exploitation de la BCPD avec un SMA Ceci
passe par la mise en oeuvre d un Système Multi Agents d Assistance
à la Modélisation SM AM
Notre approche consiste à fournir une assistance au
déroulement du processus de
développement spécialement pour les disciplines d
Expression des Besoins d Analyse Conception du RUP Il s agit de suivre et
assister le développeur pendant la modélisation en s assurant qu
il suit un processus donné
C est ainsi que nous proposons de construire un Système
Multi Agents d Assistance a la Modélisation SM AM lire SM two
AM Nous partons du fait que la connaissance utile au développeur
peut être représentée sous forme de best practices de
guides de méthodologies et autres SM AM doit fournit cette connaissance
SM AM vient combler l isthme entre la pléiade de documents et les outils
CASE UML La suite de ce rapport spécifiera plus en détail le SM
AM
IV Plan du mémoire
Notre travail se subdivise en six chapitres Un aperçu
global de notre travail peut être
obtenu en ajoutant à la lecture de l introduction et de la
conclusion celle des résumes fournis au début de chaque
chapitre
Dans le second chapitre nous introduisons les notions
fondamentales sur des processus
d ingénierie logicielle afin de mieux
appréhender la problématique Cette dernière nous
amène à présenter des projets et solutions existantes ou
envisagées Nous terminons par une analyse de ces différentes
solutions afin de mieux élaborer la nôtre
Le troisième chapitre présente la
méthodologie adoptée Après avoir introduit le
processus générique RUP il spécifie les
méthodes d assistance à utiliser Puis fournit des notions
générales sur les SMA et leur application à notre contexte
Enfin l ingénierie des connaissances incluant des éléments
d ontologie et le méta modèle SPEM Software Process
Engineering Metamodel standard de l OMG Object Management Group
pour la spécification des processus d ingénierie logicielle sont
présentés succinctement
Des modèles de notre système sont
présentés au chapitre quatre Nous commençons
par
la modélisation du métier du processus d
ingénierie logicielle RUP qui aboutit à la BCPD Puis la
modélisation expression des exigences analyse conception du SM AM qui
utilise la BCPD pour assister le développeur
Le chapitre cinq s intéresse davantage à l
implémentation de la BCPD et du SM AM
Une conclusion des discussions et des perspectives au
chapitre six viennent clôturer
le travail réalisé
Le lecteur trouvera dans les annexes une présentation
beaucoup plus détaillée du méta modèle SPEM Il y
trouvera également un moyen d accéder au site du processus
générique RUP pour une représentation des ontologies et
enfin l implémentation de notre base de connaissances
came« ii la013161??ille%
|
Il faut que l imagination prenne trop pour que la
pensée ait assez
Gaston Bachelard
|
|
La problématique ne saurait être bien
assimilée sans des notions sur les processus d ingénierie
logicielle ce chapitre commence par présenter les concepts clés d
un processus d ingénierie logicielle Puis le problème posé
à savoir l assistance au développeur avec un Système Multi
Agents est étayé avec quelques exigences logicielles liées
à l application elle même et au projet CIAO
Un état de l art des initiatives et des solutions
existantes se rapportant à la problématique est ensuite
réalisé Nous y présentons notamment les projets NATURE
CPCE Argo ArgoUML ALF et WayPointer
Nous fournissons enfin une analyse des solutions existantes
par rapport au travail que nous allons à réaliser Une conjecture
nous permet de repréciser le contexte de l analyse
I Un processus d'ingénierie logicielle -- une
introduction
1.1 Définition
Un processus est un ensemble d étapes partiellement
ordonnées destinées à réaliser des objectifs dans
le génie logiciel le but est de construire un produit logiciel ou mettre
en valeur ceux qui existent déjà Un processus définit
qui rôles fait quoi artefacts quand workflow le
faire et comment activités réaliser certains
objectifs
Un processus d ingénierie logicielle fournit une
description de l ensemble des activités à réaliser pour
transformer les besoins de l utilisateur nouveaux ou changeants en
système logiciel
Figure 2 Le processus d'ingénierie
logicielle
1.2 Avantages d'un processus
Un processus d ingénierie logicielle est
intéressant dans le développement d un système
informatique à plus d un titre à savoir
· Chaque membre de l équipe de développement
comprend quel est son rôle dans le développement du produit
· Les développeurs comprennent mieux leur
participation dans le développement et leur contribution par rapport aux
autres développeurs
· Les dirigeants et responsables comprennent mieux l
avancement du travail de chacun grâce aux différents
modèles produits
· Le processus permet de mesurer lors de la phase de
lancement les risques liés au projet et de mesurer à chaque
itération les écarts entre ce qui est prévu et la
réalité
1.3 Le cycle de développement
L enchaînement des activités et des phases qui
mènent à la réalisation d une version du logiciel s
appelle cycle de développement Le cycle de vie est un enchaînement
de plusieurs cycles de développement Le cycle de développement
comprend généralement quatre phases d un point de vue de pilotage
du projet KMP
·
La phase d Etude d opportunité qui prend acte
de la naissance du projet et définit sa portée L objectif
réel étant de prendre la décision de réaliser ou de
ne pas réaliser le projet sur la base d orientations
générales claires
· La phase d Elaboration est comparable
à une activité de recherche et de développement dans le
monde industriel Elle permet de finaliser l analyse du problème de
construire l architecture du système de traiter les risques majeurs du
projet et de finaliser le plan de développement
· La phase de Construction permet de
compléter le développement logiciel et de fournir une version
opérationnelle pour la phase de transition
· La phase de Transition concerne la mise en
oeuvre chez les utilisateurs d une version opérationnelle non
finalisée du logiciel
D un point de vue des activités le cycle de
développement représente l enchaînement des
activités élémentaires qui se
déroulent dans le cadre d une itération Ces activités sont
le planning de l itération l analyse la conception le code et le test l
évaluation et la préparation de version
1.4 UML dans le processus de développement
UML OMG est un langage de modélisation unifié qui
tient une place importante dans la
communication au sein des équipes de
développement I Jacobson définit un processus d ingénierie
logicielle comme un processus de construction de plusieurs modèles
allant du modèle des besoins au modèle du code et du test Les
modèles UML ont été largement adoptés dans l
industrie du génie logiciel pour la communication et la production des
résultats
La vue générale des processus d ingénierie
logicielle définie ci dessous nous permettra de mieux assimiler la
problématique qui suit
Il Expression des besoins
11.1 Problème
Le développement de logiciels de complexité
croissante s avère de plus en plus difficile aujourd hui Les
développeurs apprennent continuellement les pratiques des nouvelles
méthodologies de développement en les appliquant à leurs
projets Ces méthodologies elles même d une complexité sans
cesse croissante ne fournissent des résultats qu après plusieurs
années d expérience dans divers autres projets et une adaptation
conséquente au type de projet Les développeurs doivent donc
apprendre en parcourant la kyrielle de documents qui accompagnent ces
méthodologies ce qui entraîne souvent des retards dans les projets
ou de mauvaises interprétations des concepts de la méthodologie
utilisée Les équipes de développeurs sont également
confrontées au récurrent problème de savoir qui fait
quoi et comment dans l équipe
Eu égard à ceci il se pose le problème
de savoir comment assister les équipes de développement en
définissant les rôles qui les activités
quoi et le workflow comment et en leur permettant d adapter la
méthodologie choisie à leurs projets Et surtout en les dispensant
d un énorme background dans le développement pour produire des
logiciels de qualité En conséquence un certain nombre de
problèmes prévalent à savoir
Comment assister et guider activement le
développeur pendant la modélisation avec le RUP méthodes d
assistance
Quelles connaissances nécessaires peuvent
être manipulées par un système d assistance à la
modélisation Comment peuvent elles être représentes
conceptualisation et formalisation des connaissances
Comment permettre au développeur d adapter RUP
à son projet adaptation du processus
Comment gérer et réutiliser la connaissance du
processus RUP BCPD et SMA
Comment aider le développeur à suivre le
workflow en exploitant les best practices du RUP
Au vu de la problématique ci dessus
spécifiée nous proposons donc de construire un Système
Multi Agents d Assistance à la Modélisation dans
le cas du processus générique RUP
SM AM
11.2 Position du produit
SM AM est destiné aux développeurs et aux
équipes de développement Ceux ci ont très souvent besoin d
être guidés activement autant que possible dans leur travail
quotidien c est à dire assistés et conseillés
guidés et contrôlés activement SM AM est une application
basée sur un Système Multi Agents qui assiste et guide les
équipes de développeurs dans la capacité à
appliquer le processus d ingénierie logicielle générique
RUP pour les disciplines d Expression des Besoins d Analyse Conception des
Systèmes d Information SI SM AM exploite la
généricité du processus de développement RUP pour
permettre au développeur de configurer le processus et l appliquer
à son type de projet Notre produit fournit une assistance
stratégique et un guidage globaux au niveau du flot d activités
il fournit également une assistance et un guidage locaux pendant le
déroulement de chaque activité Cette assistance est
essentiellement proactive
SM AM fournira la connaissance nécessaire à l
équipe de développement pour l adoption des rôles et la
réalisation des activités Il permettra le suivi du workflow et
des best practices Il s agit donc de concevoir un système qui sera
perçu comme un collaborateur un véritable partenaire par les
développeurs Cela revient à mettre à la disposition du
développeur un système qui contribue à l efficacité
et à l approfondissement de sa réflexion avec également
une possibilité de délégation pour certaines tâches
Notre assistance portera essentiellement sur la manière de
travailler A way of working
11.3 Spécification supplémentaires
SM AM est un assistant au développement logiciel Il
fournit la connaissance nécessaire au développeur en termes de
best practices de guides de méthodologie et autres Il est capable de
raisonner sur les connaissances du Processus de Développement pour aider
le développeur à réaliser ses objectifs SM AM devrait donc
assister le développeur en capturant les éléments d une
base de connaissances en basant son raisonnement sur ces connaissances et en
appliquant les éléments de ces connaissances à la
construction du système en cours de développement
SM AM est un outil d aide pour le développeur Pour
remplir cette fonction de façon efficiente et substantielle il est
nécessaire pour lui de
· Comprendre la méthodologie il s agit de savoir
quels sont les artefacts à produire les règles de la
méthodologie le processus de développement de la
méthodologie les tâches les activités
·
Comprendre les objectifs du développeur Un projet a
généralement des objectifs globaux Cependant chaque
développeur participant au projet aura des objectifs propres
basés sur les objectifs globaux du projet Le développeur adopte
un Rôle pour réaliser une Activité qui produira un Artefact
R A A ces notions de rôle d activité et d artefact doivent
être comprises par l assistant qui assiste le développeur
· Il doit savoir comment produire des artefacts pour le
système savoir quand appliquer ses connaissances spontanément
fournir au développeur des informations spécifiques Ceci peut se
faire sur la base des activités l assistant sachant quand le
développeur doit procéder à une activité
donnée peut anticiper sur un besoin d aide Les connaissances sont
appliquées aux artefacts pour les affiner selon les règles de la
méthode
En outre SM AM devra pouvoir
· Etre intégrée à l environnement CIAO
global
· Permettre les échanges avec les outils CASE UML en
permettant l importation et l exportation au format standard XMI
· Interagir avec les outils de support de tâches de
modélisation et d implémentation outils CASE EDI
·
Raisonner dans un contexte particulier directement ou en
dialoguant avec le développeur
·
Etre personnalisable pour prendre en compte le type de projet ou
encore le domaine de l application
· Permettre de mettre à jour la base de
connaissances
Le problème étant clairement
défini il s agit dans le paragraphe suivant de recenser les
différentes approches de solutions existantes
III Approches existantes
Plusieurs travaux ont été réalisés
en vue de l assistance à la production de logiciels Nous
présentons ici les plus importants
111.1 NATURE
Les premiers travaux sur l assistance aux méthodes de
modélisation ont débuté avec le projet NATURE PR
et son environnement MENTOR SRG qui démontre la
faisabilité de la modélisation orientée décision
pour le support aux méthodes NATURE utilise une approche d utilisateur
unique en faisant abstraction de l espace de travail des rôles et de tous
les aspects organisationnels liées au développement
111.2 CPCE
L approche CPCE du laboratoire LORIA de l
Université Nancy avec Jacques Lonchamp LON a vise à
construire un noyau d environnement paramétré par des
modèles de procédés qui fournit assistance et guidage
actif à ses utilisateurs
Grâce à une approche hybride orientée
tâche au niveau global et orientée décision au niveau local
le système peut s adapter à une large gamme d applications de
conception collective Le premier prototype de CPCE permet de piloter
essentiellement des inspections collectives de code
Le projet CPCE propose une assistance et guidage
stratégique au niveau du flot d activités et une assistance et un
guidage tactique concernant les décisions à prendre pendant une
activité spécifique Il propose également un approche
intégrant quatre vues la vue orientée tâche workflow
view la vue orientée décision problem solving view
la vue oriente produit artifact view et la vue organisationnelle
Ce premier prototype va faire évoluer le projet vers un
nouvel autre qui le fait passer sous le giron du CNRS Centre National de
Recherches Scientifique français le projet Argo qui
généralise CPCE pour l assistance à la méthode et
à la coopération
111.3 Argo Project
L objectif général du projet Argo est de
construire un noyau d environnement LON b centré processus fournissant
une assistance et une guidance active a ses utilisateurs
Il utilise une approche hybride de modélisation
orientée tâche et orientée décision cette approche
peut être paramétrée pour supporter une plus large gamme d
activités de conception Il préconise comme son
prédécesseur quatre vues la vue tâche la
vue
organisation la vue produit et la vue processus
111.4 ALF Project (1987 - 1992)
Nacer Boudjlida et al de l Université de Loria
présentent dans ALF ALF un framework
pour construire des environnements de génie logiciel
centrés processus Ce projet avait pour objectif de fournir des
facilités pour supporter les activités de développement de
logiciels
Il se propose de rompre avec la mécanique des
environnements de génie logiciel en proposant des éléments
pour des environnements beaucoup plus orientés activités et
objectifs de l utilisateur Il fournit deux fonctionnalités remarquables
à savoir une assistance intelligente à l utilisateur et la
possibilité pour l utilisateur de paramétrer son environnement
111.5 ArgoUML
ArgoUML est un projet Open Source fondé par Jason
Robbins à l Université de Californie en Irvinie ArgoUML guide
dans le workflow d un processus qui n a pas encore été
défini ou plutôt qui manque de standard
Il s apparente également à un outil CASE UML
avec une surcouche assistance essentiellement axée sur les critiques
dans la manière de modéliser Il vise à long terme une
assistance complète au développeur pendant le processus de
développement
Poiseidon for UML reprend et étend les concepts
de ArgoUML c est la version commerciale d ArgoUML
Néanmoins ils n utilisent pas un Système Multi
Agents à l instar de la dernière initiative dans le domaine
WayPointer de Jaczone
11 1.6 WayPointer
WayPointer est défini par JAB comme une
application personnelle de productivité basée
sur les agents intelligents qui supportent un
développeur individuel dans la modélisation avec le langage UML
WayPointer permet de définir les objectifs en termes d artefacts qui
peuvent être spécifiés ou affinés à la
demande et il fournit un support proactif et des conseils sur la
réalisation des objectifs définis WayPointer assiste le
développeur dans la modélisation des cas d utilisation l analyse
et la conception
1V Analyse
Les projets CPCE et Argo se sont particulièrement
intéressés à la collaboration Ils définissent des
méthodes d assistance et de guidage stratégiques et tactiques
assez intéressantes Néanmoins les prototypes fournis encore
incomplets ne sont pas à la hauteur de la modélisation ou
plutôt des objectif à atteindre De plus ils utilisent des
méthodologies propres pas encore assez répandues dans le
génie logiciel
Le projet ALF resté au niveau de la
spécification des méthodes d assistance et de paramétrage
n est pas appliqué à un processus particulier Il demeure un
framework qui peut s adapter à toutes les méthodologies
ArgoUML et Poseidon for UML s apparentent à des outils
CASE UML avec une assistance consistant à critiquer le travail du
développeur Ils disposent également de vues destinées
à répartir le travail du développeur Ces projets n en sont
pas encore à leur phase terminale qui consistera à pousser un peu
plus loin pour assister le développeur dans la réalisation d un
logiciel avec un processus clairement défini
http argouml tigris org http www gentleware com http www
jaczone com
WayPointer est beaucoup plus intéressant du fait qu il
utilise un SMA pour assister le développeur pendant les phases d
expression des exigences et d analyse conception Il pêche au niveau du
fait que son processus qui est une adaptation du processus
générique RUP n est pas assez représentatif il dispose de
sept activités sur la trentaine des disciplines concernées De
plus la version disponible ne gère pas les rôles du processus Elle
est payante et surtout ne fournit pas de format d échange standard si ce
n est avec les outils de Rational Software
Bien que ne satisfaisant pas complètement à nos
besoins des concepts disparates de ces projets seront utilisés pour
notre application notamment l assistance stratégique et active l
orientation tâches et décision des deux premiers Les
éléments d assistance du projet ALF seront également
utilisés Puis les concepts de WayPointer nous seront d une grande
utilité quant à la construction de nos agents Nous mettrons l
accent sur la réutilisabilité en tenant compte du contexte qui
est le projet CIAO
|
Application
|
Processus de
modélisation
|
Assistance
|
Configuration
du processus
|
Réutilisation
Imp Exp Format
|
SMA
|
|
Oui
|
Inconnu
|
Contrôle
|
Non
|
Non Non
|
Non
|
|
Oui
|
Inconnu
|
Contrôle
|
Non
|
Non Non
|
Non
|
|
Non
|
Non
|
Guidage Explication Contrôle
|
Non
|
Non Non
|
Non
|
|
Oui
|
Inconnu
|
Critiques
|
Non
|
Oui Oui XMI
|
Non
|
|
Oui
|
Dérivation
du RUP
|
Explication Contrôle
|
Non
|
Non Oui XMI
|
Oui
|
|
Oui
|
RUP
|
Guidage Explication Contrôle
|
Oui
|
Oui Oui XMI
|
Oui
|
|
Tableau 1 Comparaison des différentes
approches
V Conclusion
Ce chapitre a présenté tour à tour des
notions fondamentales sur un processus d ingénierie logicielle la
problématique posée l existant dans le domaine puis une critique
de cet existant Nous allons maintenant poser les bases de notre approche pour
la résolution du problème
cmarnifts ooo eiIf001I If UMM
Pour faire de grandes choses il ne faut pas être un si
grand génie il ne faut pas être au dessus des hommes il faut
être avec eux Montesquieu Sur l homme
La problématique définie au chapitre
précédent impose notre approche méthodologique Assister et
guider activement le développeur pendant le processus nécessite
de passer en revue les différentes méthodes d assistance à
utiliser par notre SMA Identifier les éléments du processus
générique RUP et les formaliser fait appel aux ontologies pour la
construction de la BCPD Gérer et réutiliser la connaissance
nécessite de construire la BCPD et le SMA qui l exploitera
Une présentation succincte du processus
générique RUP permet une plus grande clairvoyance dans la suite
du travail La définition des éléments d assistance vient
guider celle du SMA Nous concluons avec un distinguo des différents
formalismes de représentation et une présentation de la
spécification SPEM conforme au formalisme retenu UML OCL
I Concevoir un SM2AM : La méthode
Nous nous proposons en premier lieu d identifier et de
formaliser les éléments du RUP pouvant permettre d assister un
développeur Ceci sera suivi par la représentation cette base en
utilisant une spécification donnée en l occurrence la
spécification SPEM qui intègre le formalisme UML OCL
Ensuite nous entrevoyons utiliser un agent interface pour
gérer les interactions avec le développeur et des agents
intelligents pour assister dans le déroulement du processus RUP sur un
projet particulier Nous disposerons d agents spécialisés dans le
déroulement du workflow l adoption des rôles et la
réalisation des activités avec des connaissances
particulières sur le processus fournies par la base de connaissances du
RUP que nous aurons préalablement construite Les agents intelligents
seront munis de croyances sur un projet faits représentant l état
courant Ils consommeront ces faits pour atteindre leurs objectifs suivre un
projet suivre un workflow suivre un rôle suivre une activité en
réalisant les plans Guider Expliquer et Contrôler Les plans sont
réalisés par l évaluation des règles sur le
processus disponibles dans la BCPD en tenant compte des faits Ces plans
modifient le tableau noir représenté par le projet en cours Les
agents communiquent par l envoi de messages et collaborent afin d atteindre l
objectif commun qui est l assistance Au niveau de celle ci l application devra
fournir guidage actif en guidant en fournissant des explications et en
contrôlant le travail Le développeur pourra également
prendre des notes La BCPD RUP devra contenir les ontologies de tâches et
de domaine
La suite de ce travail va présenter le processus d
ingénierie logicielle RUP les éléments d assistance des
notions sur les SMA des notions d ontologie et une description de la
spécification SPEM
Il Présentation des concepts
11.1 RUP : Un processus générique
Le Rational Unified Process est une
méthodologie de développement de logiciels qui a
été mise en oeuvre par les auteurs d UML C est le dernier
paradigme de la longue lignée de méthodologies de
développement communément adoptées dans le génie
logiciel C est également un produit RUP de Rational Software qui
accompagne le processus RUP
Deux facteurs principaux ont contribué au
développement de cette méthodologie la complexité
croissante des produits logiciels et le temps de livraison des produits sur le
marché devenu un facteur critique dans le succès de ceux ci
JBR
RUP préconise l adoption d un certain nombre de
meilleures pratiques pour un développement logiciel moderne GAP
permettant de réduire les risques inhérents au
développement de nouveaux logiciels Ces bonnes pratiques sont
Développer itérativement
Gérer les exigences
Développer à base d architecture de
composants
Modéliser visuellement UML
Evaluer continuellement la qualité
Gérer les changements
Ces bonnes pratiques sont mises en oeuvre par la
définition des rôles des disciplines des
activités et des artefacts tels que
présentés sur la boîte noire du RUP Figure
Figure La Boite Noire du RUP
Le RUP est un processus itératif qui définit
quatre phases pour les projets de
développement logiciels A travers le temps le projet
comprend les phases de Lancement d Elaboration de Construction et de Transition
Chaque phase contient une ou plusieurs itérations où des
exécutables peuvent être produits Durant chaque itération l
effort est orienté vers des activités de disciplines
différentes à des niveaux de détail divers La Figure
présente une vue générale du RUP
Figure 4 Présentation schématique de RUP
selon 2 axes IRUP03 02]
Les phases d expressions des besoins et d analyse et
conception sont celles qui nous intéressent car elles constituent les
disciplines principales pour la modélisation Nous les détaillons
ci dessous
Expression des Besoins
L objectif principal de l expression des besoins est de
décrire ce que le système est censé faire et permettre au
développeur et au client de trouver un terrain d entente le premier sur
ce qu il doit réaliser le second sur ce qu il doit recevoir Pour arriver
à cela il est nécessaire d organiser et de documenter les
fonctionnalités requises ainsi que les contraintes Tout ceci est
réalisé en utilisant les cas d utilisation
Analyse Conception
L analyse la conception doivent pouvoir montrer comment le
système sera réalisé à la phase d
implémentation Elles produisent un modèle de conception et
optionnellement un modèle d analyse Le modèle de conception
consiste en un ensemble de classes de conception structurées en packages
de conception et sous systèmes avec des interfaces bien définies
représentant ce qui deviendra des composants pendant l
implémentation
Le RUP est un exemple de framework de processus TP qui a
bénéficié d une longue
expérience dans les différents projets L
identification des concepts clés du RUP nous permet
|
Microarchitecture qu on peut étendre ou
réutiliser
|
|
de ressortir un bon nombre de caractéristiques
inhérentes à ce processus dont la disponibilité des outils
guides fait de lui aujourd hui un processus en pleine croissance Notamment RUP
gère très tôt les risques en développant rapidement
une première version du système qui permet de définir l
architecture du système Il ne gère pas un ensemble fixe de
spécifications à la phase de lancement mais permet de les affiner
et les compléter au cours du projet Le processus ne met pas un accent
particulier sur la production de documents mais se prête à une
automatisation des différentes tâches associées La
qualité du logiciel produit par RUP se mesure au degré de
satisfaction du client RUP est assez générique pour être
appliqué à une large gamme de développement de logiciels
et de projets
11.2 L'assistance
Un méta modèle pour la modélisation des
processus d ingénierie logicielle est proposé par N
BOU puis amélioré par celui ci dans ALF Ce
méta modèle est orienté déroulement du processus
pour l assistance au développeur Il propose des fonctionnalités
de travail du système réaliser une tâche observer et
contrôler monitoring et des fonctionnalités d assistance au
développeur guider coaching prendre une initiative expliquer et
apprendre
Une dimension de l assistance est l initiative d après NIT
une assistance peut
être active ou passive Une autre dimension concerne le
degré d automatisation un système d assistance peut agir
automatiquement et exécuter des tâches pour l utilisateur proposer
les prochaines actions possibles et fournir des informations Une autre
dimension est le fait que le système d assistance doit être
adaptatif ou adaptable il doit pouvoir s adapter lui même aux besoins de
l utilisateur et l utilisateur doit pouvoir l adapter
L assistance au développeur peut être
catégorisée comme le suggère LON a en
Une façon de modéliser A way of modeling
où on dispose d un ensemble de
concepts de modélisation fondamentaux pour capturer la
connaissance sémantique sur un problème et sa solution avec un
ensemble de vues et de notations pour présenter cette information
Une façon de travailler à travers le processus
A way of working le processus décrit
le modèle a construire quand et comment le construire
avec un ensemble de règles pour prendre des décisions de
modélisation
Le premier type d assistance est assez répandu avec les
outils case UML le second beaucoup
moins répandu fera l objet de l assistance que nous
proposons dans la suite Nous proposons une assistance qui consiste à
Contrôler les initiatives du développeur et le
guider lorsqu il ne se conforme pas au processus
Faire jouer au système un rôle actif c est
à dire lui permettre de prendre des initiatives constructives pour
réaliser les activités au gré du développeur
prendre des initiatives de correction pour vérifier la consistance
lorsque des prescriptions sont violées
Guider les développeurs en leur fournissant les
facilités suivantes
Quoi faire après pour informer l utilisateur sur
les activités à réaliser en considérant l
état courant du processus
Comment faire quelque chose qui fournit un type de
chemin pour réaliser un
objectif comme produire des artefacts
Comment est ce que quelque chose marche pour aider dans
la réalisation des activités
Analyser l impact d une action donc évaluer ses
conséquences spécialement pour les actions qui peuvent modifier
des éléments de modèle
Résumer ce qui a été fait et
comment l état courant du système a été atteint
Expliquer une initiative du système à l utilisateur
Apprendre en observant le développeur et ses
actions
Ces éléments d assistance seront pris en compte
par notre SMA pour assister le développeur
Nous décrivons ci dessous un SMA
11.3 Un Système MuIti-Agents
La venue des SMA a été bénéfique
à beaucoup de disciplines en leur permettant de construire des
applications distribuées intelligentes et robustes Un SMA peut
être défini comme un ensemble d agents qui collaborent et
coopèrent afin d atteindre leurs buts respectifs ou communs Nous n irons
pas ici donner une définition d un agent il existe une kyrielle de
documents dans la littérature à ce sujet et il est très
difficile de donner une définition complète Retenons juste qu un
agent assiste et supplée un humain dans sa tâche et que tout le
monde s accorde beaucoup plus sur les caractéristiques
intrinsèques d un agent que sur leur définition
Les agents se distinguent généralement des
autres systèmes logiciels par leur habileté à interagir
intelligemment dans un sens constructif avec les autres agents ou les hommes De
plus leurs ressources et services ne sont pas directement accessibles mais
invoquées par des requêtes
11.3.1 Un agent : caractéristiques de I'AWG
L AWG caractérise un agent par ses
propriétés en l occurrence être capable d agir sans une
intervention extérieure directe autonomie communiquer avec son
environnement et les autres agents interactivité pouvoir
modifier son comportement par l expérience adaptabilité
ne pas réagir uniquement à son environnement mais être
orienté objectifs proactivité avoir un état
formalisé par une connaissance et communiquer avec les autres agents en
utilisant un langage symbolique intelligence être capable de
choisir une action suivant ses objectifs et sa connaissance
rationalité être capable de réaliser une
activité dans un environnement partagé avec d autres agents
coordination et enfin être apte à collaborer avec les autres
agents pour réaliser un but commun collaboration
L AWG AWG propose également des éléments de
caractérisation d un agent
intelligent Son état doit être formalisé
par une connaissance les croyances les buts les désirs les intentions
les plans les hypothèses et il doit être capable d agir sur cette
connaissance Il doit pouvoir examiner ses croyances et ses désirs former
ses intentions planifier les actions qu il réalisera sous certaines
hypothèses et éventuellement agir sur ses plans Il doit enfin
pouvoir communiquer avec d autres agents en utilisant un langage symbolique L
AWG AWG propose aussi des éléments de caractérisation d un
agent interactif Un agent interactif peut communiquer avec son environnement et
d autres entités Il réagit en observant les
événements de son environnement Il coordonne ses actions avec
celles des autres agents du système en coopérant avec ceux ci
11.3.2 Les agents : classification de Nwana
propose dans HSN une
classification des agents tels que présentés
à la Figure Il définit trois attributs des agents à savoir
la coopération l autonomie et l adaptation Il combine la
coopération et l adaptation ainsi que la coopération et l
autonomie pour avoir une
autre caractéristique des agents la
collaboration Les agents interfaces
Figure 5 Classification de Nwana (HSN 96]
résultent de l autonomie et de l adaptabilité
Enfin les agents intelligents viennent fédérer tous ces
attributs
11.3.3 Architecture du SMA : Le formalisme BD1 (Croyances --
Désirs - 1ntentions)
L architecture BDI Beliefs Desires Intentions associe
aux agents des croyances sur l environnement et les autres agents les
désirs ou les objectifs à réaliser ainsi que les
intentions ou plans à exécuter pour réaliser les
désirs L environnement influe sur les croyances de l agent ces croyances
permettent de réaliser des objectifs en utilisant les plans
préalablement définis Ces plans modifient l environnement et le
tableau noir qu ils utilisent également
Figure 6 Architecture BD!
Nos agents doivent disposer de connaissances sur le processus
générique de développement RUP Ceci justifie le fait que
nous donnions des notions relatives aux ontologies afin d implémenter
une BCPD RUP
11.4 Une Base de Connaissance du Processus de
Développement
La construction d une BCPD RUP passe par la conceptualisation et
la formalisation des ontologies de domaine et des tâches du processus
11.4.1 Ontologies
11.4.1.1 Définition
Nées du besoin de représenter les connaissances
dans les systèmes informatiques les ontologies informatiques n ont
été de ce fait précisément définies que par
rapport au processus général de représentation des
connaissances A l heure actuelle un certain consensus s est établi sur
le rôle des ontologies dans ce processus consensus bâti autour de
la
formule de T G une ontologie est une spécification
explicite et formelle d une
conceptualisation commune GRU La construction d une
ontologie n intervient donc
qu après que le travail de conceptualisation ait
été mené à bien Ce travail consiste à
identifier au sein d un corpus les connaissances spécifiques au domaine
de connaissances à représenter Dans le cadre de cette
définition le terme conceptualisation renvoie à un modèle
abstrait d un
phénomène fondé sur l identification de
concepts significatifs le terme explicite signifie que les concepts
utilisés et leurs contraintes d utilisation sont définis de
façon explicite l adjectif formelle précise que l ontologie doit
être lisible par un ordinateur et enfin le terme commune renvoie à
l idée qu une ontologie rend compte d un savoir consensuel elle n est
pas liée à un individu mais elle est reconnue par un groupe
N G affine la définition de T G en considérant les
ontologies comme des
spécifications partielles et formelles d une
conceptualisation GUA Les ontologies sont formelles car exprimées sous
forme logique et partielles car une conceptualisation ne peut pas toujours
être entièrement formalisée dans un cadre logique du fait d
ambiguïtés ou du fait qu aucune représentation de leur
sémantique n existe dans le langage de représentation d
ontologies choisi J N montre dans NOB que les formalismes opérationnels
présentent une faible tolérance d interprétation
ce qui oblige à passer directement d une ontologie informelle à
une ontologie totalement formelle et non ambiguë De plus on doit souvent
modifier la BCPD au cours de son élaboration ce qui entraîne des
incohérences et des modifications plus larges
11.4.1.2 Utilité
Une ontologie est utile pour
Capturer modéliser transformer et intégrer une
connaissance dans un contexte particulier
Traiter et automatiser les raisonnements de sur cette
connaissance
Partager en collaboration une compréhension commune d une
structure d informations parmi les agents humains et ou parmi les agents
logiciels
Etre capable de réutiliser le domaine d
intérêt par des connaissances opérationnelles ad hoc ou
autre des standards qui unifient les mécanismes de modélisation
des catégories ontologiques de connaissances sur l existence
11.4.1.3 La nécessité d'un formalisme de
représentation
Le but de la représentation des connaissances est de
modéliser un domaine particulier d application de sorte que la
représentation ou le modèle obtenu soit manipulable par une
machine La représentation des connaissances doit remplir les conditions
suivantes
L énoncé des connaissances doit être
indépendant de tout mode d exploitation exploitation par un
système à base de connaissances ou un SMA par exemple
La facilité de compréhension et de modification des
connaissances
Le contrôle des mécanismes
Les connaissances une fois modélisées
débouchent sur une ontologie du domaine Le terme
ontologie issu du domaine de la philosophie où il
signifie explication systématique de l existence revêt de
multiples acceptions suivant la discipline dans laquelle il est
considéré Il existe plusieurs formalismes de
représentation d ontologies qui se confondent très souvent avec
ceux de représentation des connaissances
11.4.1.4 Quelques formalismes de représentation des
ontologies
On classe généralement les formes de
représentation des connaissances en deux groupes principaux DLI celui
des représentations basées sur la logique et celui des
représentation non basées sur la logique Parmi les
représentations non basées sur la logique on distingue les
représentations dites graphiques à cause de l utilisation dans
celles ci de la notion des graphes des représentations proches de la
terminologie des frames Les formats d échange des ontologies sont
très souvent liés aux formalismes de représentation comme
le montre la Figure
Figure 7 Formats d'échange et formalismes
Un graphe conceptuel représente une formule
logique les noms et arguments sont représentés par des noeuds Les
arcs du graphe relient les noms des prédicats à leurs
arguments
Les réseaux sémantiques
représentent des structures plus complexes Un réseau
sémantique est formé d un ensemble de graphes conceptuels Le
réseau permet de visualiser l ensemble des relations existant entre les
graphes conceptuels
Les Frames sont des descriptions d entités
conceptuelles ces entités pouvant être des objets réels
comme une voiture ou un article ou des objets abstraits comme une facturation
ou un achat ou encore un ensemble d objets Les frames sont essentiellement
définis par leurs relations avec d autres frames Les relations entre les
frames sont représentées par l utilisation des facettes
La représentation logique est basée sur
la logique du premier ordre qui propose des règles de dérivation
utilisées dans les démonstrations On distingue le modus
ponens le modus tollens et le principe de résolution
La logique de description est une approche de
représentation des connaissances plus flexible que les frames mais qui
fournit une syntaxe et une sémantique assez rigoureuse
La logique de description structure la connaissance en deux
niveaux le niveau terminologique T Box qui contient les classes des
objets du domaine concepts avec leurs propriétés rôles et
un niveau assertionnel A Box qui comporte les objets abstraits
individuels instances
La représentation basée sur les frames a
évolué en donnant naissance aux types abstraits de données
et aux objets La représentation par objets se présente
comme étant le mode de représentation le plus communément
admis en raison de l existence d une large gamme d outils la supportant partant
de langages de représentation aussi bien textuels que visuels aux
environnements de modélisation de la grande structuration des
connaissances Des langages de contraintes ont été définis
pour combler le vide relevé quant à l expression des
règles régissant le domaine du discours On peut cependant
reprocher à cette forme de représentation l inexistence d un
mécanisme formel de raisonnement
La quasi totalité des langages utilisés aujourd
hui pour représenter les connaissances sont
basés sur le formalisme des frames voir Figure Le
langage UML associé à OCL est de plus en plus utilisé pour
représenter des ontologies des profils UML et des méta
modèles exprimés en UML sont définis pour étendre
le langage en l enrichissant de stéréotypes afin qu il se
prête aisément à la représentation des concepts d un
domaine donné
Les choix du formalisme de représentation des
connaissances et des modes de raisonnement vont nécessiter l aperception
du mode d utilisation de ces connaissances En effet lorsqu on manipule des
connaissances une bonne partie de nos réflexions sont implicites L un
des objectifs à atteindre dans le projet est l exploitation des
connaissances par un SMA Ceux ci devrait constituer le moteur d
inférence de la base de connaissances construite Cette base de
connaissances devra contenir les ontologies des tâches et de domaine du
processus de développement RUP La mise à jour de ces ontologies
se fera avec l évolution de RUP
11.4.2 Le formalisme UML/OCL
Les ontologies incluent les hiérarchies de classe sous
classe les relations entre ces classes la définition des attributs et
des axiomes qui spécifient les contraintes En UML cette information
ontologique est généralement modélisée dans des
diagrammes de classe et des contraintes OCL Object Constrainst
Language De plus la représentation des connaissances dépend
du type de connaissances TAN UML un langage graphique de modélisation
des systèmes discrets est utilisé par le produit RUP c est aussi
un standard de l OMG dont une spécification complète est
disponible dans UML d où son adoption pour la représentation des
ontologies de RUP Plus d une raison nous ont guidé dans le choix
préconisé par
dans l article SSM
UML est un standard maintenu par l OMG et dispose d un
mécanisme de définition des extensions dans le contexte d
applications spécifiques à l instar de la modélisation des
ontologies
UML est largement adopté dans l industrie et dans
plusieurs universités
UML est supporté par une large gamme d outils CASE
notamment par le produit RUP
UML a été utilisé avec brio pour la
représentation de plusieurs d ontologies CRA
Un diagramme UML à l instar d un diagramme de classe n
est typiquement pas assez affiné
pour fournir tous les aspects liés à une
spécification Plusieurs autres éléments nécessitent
des contraintes supplémentaires souvent décrites dans le langage
naturel Les langages formels existants nécessitent un background
mathématique et ne sont de ce fait pas adaptés à la
modélisation des logiciels
OCL Object Constraint Language est
un langage formel d expression des contraintes facile à lire et à
écrire né pour pallier à ce manque C est un standard de l
OMG OCL est purement un langage d expression qui est utilisé pour
spécifier les invariants sur les classes et types dans le modèle
de classe pour spécifier les invariants de types pour les
stéréotypes pour décrire les pré et post conditions
sur les opérations et les méthodes pour décrire les gardes
OMG
pour spécifier les contraintes sur les opérations
Une spécification complète peut être trouvée au
chapitre six de UML
Le formalisme UML OCL étant choisi l OMG propose un
méta modèle pour la description des processus d ingénierie
logicielle SPEM Ce méta modèle est un stéréotype d
UML qui utilise le formalisme UML OCL d où son adoption pour la
représentation des ontologies Nous présentons SPEM dans la
suite
11.4.3 SPEM
11.4.3.1 Approche de modélisation
L OMG a adopté une approche orientée objet pour
modéliser une famille de processus et utilise pour cela le langage UML
La Figure présente les quatre couches de l architecture de
modélisation telle que définie par l OMG Un processus qui est
utilisé dans le déroulement d un projet réel se trouve au
niveau M Le niveau M comprend les différents modèles des
processus correspondants qui sont applicables dans des projets à l
instar de RUP et ses différentes adaptations Les modèles de
modèle de processus communément dénommés les
méta modèles de processus se trouvent au niveau M Enfin le niveau
M MOF Meta Object Facility est au sommet pour la représentation
des méta méta modèles
Figure 8 La pyramide des niveaux de
modélisation
La spécification SPEM est structurée comme un
UML profile voir ci dessous et fournit aussi un méta modèle
complet basé sur MOF Nous commençons par définir SPEM puis
nous le décrivons comme un méta modèle et ensuite comme un
UML profile
11.4.3.2 SPEM, un standard
Le méta modèle SPEM Software Process
Engineering Metamodel SPEM est utilisé pour
décrire un processus de développement logiciel ou
une famille de processus Il permet de décrire le processus et ses
composants SPEM est né d une RFP Request For Proposai de l OMG
sur le Software Process Engineering Management en Novembre Nous
faisons ici
référence à la version de Novembre
L objectif de SPEM est de définir un langage commun
pour décrire des processus mais aussi de faciliter la communication
entre les différents outils de fabrication des processus Le SPEM permet
d unifier les vocabulaires utilisé pour décrire les processus Il
définit un ensemble d éléments de modèle
nécessaires pour décrire un processus quelconque de
développement logiciel sans les contraintes et modèles
spécifiques à une quelconque discipline telle la gestion des
projets ou l analyse
11.4.3.3 Le méta-modèle SPEM
SPEM a pour idée sous jacente qu un processus de
développement logiciel est une collaboration entre des entités
abstraites les rôles qui réalisent des opérations
appelées activités sur des entités tangibles
appelées artefacts La Figure présente les liens entre ces trois
concepts Plusieurs rôles peuvent collaborer par l échange de
produits et le déclenchement de l exécution de certaines
activités Le but global d un processus est de fournir un ensemble d
artefacts dans un état bien défini
Figure 9 Modèle conceptuel de SPEM (SPEM 02]
SPEM est construit sur le SPEM Foundation package
qui est un sous ensemble du modèle physique de UML et qui
présente les types de données les éléments
fondamentaux les actions les machines à état les graphes d
activité et la gestion de modèles Il comporte également
les six sous packages du SPEM Extension qui sont
Basic Elements qui contient les éléments
de base pour la description d un processus Dependancies montre les
dépendances définies dans SPEM
Process Structure définit les
éléments structuraux majeurs qui permettent de construire la
description du processus
Process Components détaille le package des
composants d un processus
Process Lifecycle introduit les éléments
de définition d un processus qui aident à sa mise en oeuvre
Management of Process Assets en cours de
définition
Nous présentons en Annexe A le package Process
Structure qui nous intéressera beaucoup
pour l ontologie des tâches de RUP et le package
Dependancies qui fournira les règles sur les composants de notre
processus Les autres packages nous seront tout aussi utiles notamment dans la
construction de la base de connaissances et interviennent dans l ontologie de
domaine du RUP
SPEM a été décrit ici directement comme un
méta modèle Il peut être utilisé directement par
instanciation de ce méta modèle Mais SPEM est aussi défini
comme un UML profile
11.4.3.4 SPEM comme un UML profile
Un UML profile est une variante de UML qui utilise les
mécanismes d extension de UML pour la standardisation dans un but
particulier La définition de SPEM comme UML profile a été
guidée par la popularité de UML auprès d une large
communauté de développeurs qui utilisent des outils de
modélisation UML Ceci permettra notamment la réutilisation de
leurs
connaissances de modélisation et des outils L OMG a ainsi
procédé à un mapping des classes du méta
modèle SPEM vers des classes de UML
SPEM est supporté par l outil Rational Process
Workbench RPW de Rational Software qui est un outil de construction de
processus basé sur UML Et aussi XMI eXtensible Metamodel
Interchange XMI un autre standard de l OMG qui définit le format d
échange des méta données en terme de Meta Object Facility
MOF standard définit une DTD Document Definition Type pour UML
Tous ces éléments ainsi que la grande adoption de UML ont
guidé l utilisation de SPEM comme un UML profile pour la suite de notre
travail
III Conclusion
Ce chapitre a présenté la méthode
adoptée pour résoudre le problème posé Ensuite les
concepts fondamentaux relatifs aux différentes terminologies ont
été passés en revue Notamment la présentation du
processus générique RUP ainsi que les meilleures pratiques
associées ensuite une formalisation de l assistance Puis une
architecture d agent a été définie après les
caractéristiques essentielles des agents selon l Agent Working Group et
Nwana Le formalisme BDI a également été
présenté Des notions d ontologie ont été
abordées avec une description du formalisme UML OCL pour la
représentation des ontologies Nous avons terminé par une
brève description du méta modèle SPEM La suite de notre
travail consistera à utiliser cette approche méthodologique pour
modéliser notre système
CRAMEZ liy eac???eece
|
Le monde de la réalité a ses limites le
monde de l imagination est sans frontières
Jean Jacques
Rousseau
|
|
|
Nous présentons ici notre aperception du SM AM qui va
aider le développeur à suivre un workflow en exploitant les best
practices et les connaissances du processus générique RUP
Les outils de modélisation de notre système
UML RUP et Rational XDE liées à la méthodologie
utilisée RUP for Small Project sont brièvement
décrits
Le mapping de SPEM au processus générique RUP
pour la représentation des ontologies du RUP est ensuite décrit
puis la conceptualisation et la formalisation de ces ontologies sont fournies
comme modèle de notre BCPD générique RUP
La modélisation du SM AM clos ce chapitre avec l
expression des besoins qui contient la vision du système une
présentation des acteurs et des rôles un modèle
générique détaillant les fonctionnalités et les
interactions entre les agents un scénario de fonctionnement du
système et des modèles de cas d utilisation Une architecture du
système est fournie Puis le passage de l expression des besoins à
la conception est effectué par le biais des réalisations de cas d
utilisation qui présentent les interactions Enfin les diagrammes de
classes viennent compléter la conception avec une architecture
détaillée du système
I Outils de Modélisation
Nous avons utilisé un certain nombre d outils et de
concepts pour la modélisation de notre système Notamment UML pour
le langage de modélisation RUP pour la méthodologie et Rational
XDE comme outil de conception des modèles Nous décrivons
brièvement ces outils ci dessous
UML C est le langage de modélisation
unifiée Il permet de décrire la structure et le comportement des
systèmes et logiciels C est le standard pour décrire des
modèles Il possède un ensemble de notations graphiques
RUP le processus et le produit Voir la description de
RUP au Chapitre II
Rational XDE Rational XDE Professional for Java est
une plate forme d édition Java un environnement de conception visuelle
et de développement Il allie modélisation et
implémentation orientée Java C est un outil
particulièrement intéressant dans la gestion des
différentes phases du processus générique RUP
Il Les ontologies de domaine et de tâches du RUP
L approche de modélisation de la base de connaissances
tel que suggérée par le prosélyte
d UML Philippe
Kruchten le père des vues de UML et responsable du produit RUP
à
Rational Software par email a été le méta
modèle SPEM
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
I Outils de réalisation
Les outils suivant ont aidé à la réalisation
de ce travail
JDOM API java qui permet de gérer les fichiers
XML Il définit une interface de consultation et de mise à jour
des fichiers XML
NetBeans Véritable environnement de
développement visuel IDE Java NetBeans est une plate forme de
réalisation d application web et Java Elle est disponible gratuitement
sur le site de SUN
Protégé Nous avons utilisé
Protégé pour la construction de la base de
connaissances du processus de développement
générique RUP Protégé est le
dernier outil d une
suite d outils développés par l Université de Standford
depuis pour l acquisition des connaissances Il est utilisé par un
millier d utilisateurs à travers
le monde qui développent des projets divers et
variés Protégé est gratuitement
disponible en téléchargement sous la licence open
source Mozilla Protégé fournit
un environnement graphique et interactif de conception d
ontologie de développement de base de connaissances
Rational XDE Présenté comme outil de
modélisation au premier paragraphe du Chapitre IV
II Une Base de Connaissances du Processus de Développement
RUP
Nous présentons en Annexe B la DTD du fichier XML
représentant notre base de
connaissances Elle est conforme à
la DTD de SPEM présentée en Annexe A Les règles sur
ces
connaissances seront aussi fournies Elles sont
représentées par les dépendances Elle a
été
générée avec l outil Protégé
La mise à jour de la base de connaissance par l expert se fera
sous Protégé qui génèrera le fichier
XML Concevoir des interfaces de mise à jour aurait
été développer un Protégé
III Un SMA pour l'exploitation de la BCPD
Nos agents utilisent trois concepts action conclusion
recommandation pour assister le
développeur Une recommandation est
une tâche atomique que le développeur peut réaliser
comme décrire un cas d utilisation ou nommer un acteur
Une action est une proposition au développeur par le SMA d un ensemble
de recommandations Une conclusion est également une action à la
différence qu elle survient après l évaluation d une ou de
plusieurs règles
Le formalisme BDI est implémenté en munissant
nos agents d un ensemble de faits Ces faits sont essentiellement les objets sur
lesquels ils raisonnent et leur état courant Lorsque les agents Workflow
Activité et Rôle sont informés de la modification d un fait
ils cherchent un objectif qui peut consommer le fait l objectif trouvé
ils appliquent le plan qui sied le mieux au fait
IV Une Assistance au développeur avec le SM2AM
IV.1 Présentation de l'interface
Notre interface se décompose en un quinté d
éléments tels que présentés à Figure
Menu comporte les différentes
fonctionnalités proposées au développeur Il s agit
notamment pour fichier de lui permettre de créer ouvrir enregistrer
importer et exporter un projet d imprimer un rapport de son activité
Affichage lui permet de choisir parmi les actions les conclusions et les
recommandations celles à afficher Rôle est utilisé par le
développeur pour adopter un ou plusieurs rôle s Activité
contient les groupes d activités que le développeur peut
décider de réaliser Modélisation contient les
éléments de modèles UML que l utilisateur peut
décider de créer à un moment donné Enfin Outil
permet au développeur de configurer son environnement et le processus
Visualisation comporte trois vues qui permettent au
développeur d avoir un récapitulatif de son projet à tout
moment La vue cas d utilisation UseCaseView inclut le modèle des cas d
utilisation qui représente les fonctionnalités attendues du
système et l environnement tel qu il est perçu par les
utilisateurs finaux Elle sert de contrat entre l utilisateur final et le
développeur et est essentielle pour les activités d analyse et
conception et de test Elle inclut également les diagrammes des cas d
utilisation le flot d évènements des cas d utilisation et une
documentation supplémentaire Il peut également inclure des
diagrammes d activité C est le coeur des autres vues parcequ elle
modèle l architecture du système La vue logique LogicalView
supporte les besoins fonctionnels du système les services que le
système final doit fournir à ses utilisateurs Elle inclut les
réalisations des cas d utilisation les classes et les diagrammes d
interaction et peut également inclure les diagrammes d état et
les diagrammes d activité La vue développement EnactmentView
permet d avoir un aperçu sur le déroulement du processus les
activités déjà réalisées l activité
en cours les activités à réaliser les différents
artefacts avec leur état respectifs La documentation des
activités y est incluse
Activité vient guider le développeur dans
la réalisation d une activité en lui fournissant des actions des
conclusions ainsi que des recommandations Elle permet au développeur de
modifier l état des artefacts en paramètres de l activité
en cours Recommandation présente les éléments
à modifier suivant les propositions de Activité Documentation
et Assistance permet au SMA de guider le workflow du développeur de
le contrôler et de lui fournir des explications Le développeur
peut prendre des notes qui lui permettront de se remémorer le
workflow
Figure 24 SM2AM : Interface
Un déroulement de scénario est fourni ici
IV.2 Déroulement du scénario
Pour le déroulement du scénario nous allons
commencer par créer un projet sous Rational Rose puis l exporter au
format XMI et l importer dans SM AM SM AM fera le contrôle et enfin le
réexportera au format XMI et le développeur pourra continuer son
développement en dessinant les diagrammes
D Etape création et exportation du projet sous
Rational Rose
Le développeur crée un nouveau projet
dénommé sm am Dans la Use Case View il crée
quatre acteurs le développeur l agent GUI l agent Workflow
l agent Activité et l agent Rôle
Il crée également les cas d utilisation suivre
un projet suivre une itération suivre une activité suivre un
rôle et réaliser un projet Figure Le développeur exporte
ensuite le projet au format standard XMI dans le menu Tools Export to UML
Figure
Ø
Etape importation sous SM AM et création du projet
Dans le menu Projet Importer le développeur entre le chemin du
fichier et valide
l importation La boîte de dialogue de création de
nouveau projet apparaît également
accessible à partir de Projet Nouveau Figure à
Figure
L Agent Workflow naît le premier bouton s allume et se met
en attente
Ø Etape adoption d un rôle Le
développeur adopte un rôle celui d Analyste Système L Agent
Rôle Analyste Système naît
le deuxième bouton s allume et se met en attente Figure
Ø Etape Réalisation d une activité dans
un groupe d activités Il sélectionne Figure le groupe d
activités à réaliser Définir le
système
Une description du groupe d activité est
affichée et le développeur sélectionne l itération
concernée Figure L Agent Workflow est aussitôt informé de l
itération en cours Il modifie aussitôt la vue
La liste des activités composant le groupe
Définir le système s affiche Les Agents Capturer le
vocabulaire courant Développer la vision Rechercher les acteurs et les
cas d utilisation et Gérer les besoins naissent et se
mettent en attente
Il décide de réaliser l activité
Rechercher les acteurs et les cas d utilisation en la
sélectionnant
Figure Le développeur crée un nouvel acteur l
acteur Expert L agent Rechercher les acteurs et les cas d utilisation
crée l acteur et met à jour le tableau noir L agent Workflow est
informé de la modification et met à jour la vue Figure
L assistance fournie permet au développeur de prendre
des notes qui seront contenues dans le rapport du projet Des explications des
éléments de guidage et de contrôle sont fournis Figure et
Figure
Ø
Etape Génération du rapport Le
développeur génère le rapport Figure du projet en
précisant le niveau de détail Le
rapport contient les éléments de la vue
déroulement EnactmentView Des descriptions sont
associées aux différents éléments
Ø Etape Exportation du projet Le projet est
ensuite exporté au format XMI et réutilisable sous Rational Rose
pour ajouter des
diagrammes
|
|
|
Figure 25 Créer le projet sous Rational
|
Figure 26 Exporter le projet sous Rational
|
|
|
|
Figure 27 Importer
|
Figure 28 Nouveau I
|
Figure 29 Nouveau 2 Figure 30 Nouveau 3
|
|
|
Figure 31 Adopter un rôle
|
|
Figure 32 Sélectionner une itération
Figure 33 Sélectionner un groupe
d'activité
|
|
|
Figure 35 Vue du projet
|
|
Figure 34 Créer un acteur
|
|
Figure 37 Rapport
Figure 38 Contrôles
V Conclusion
Nous avons présenté ici un résultat
palpable de notre travail à savoir la base de connaissances de RUP qui
est représenté sous le format d échange XML avec
Protégé Ensuite la réalisation de notre SMA et l
intégration à SM AM SM AM a également été
présenté comme résultat de notre travail
cmaruen s? Milan«
Si tout ici bas était excellent il n y aurait rien d
excellent Denis Diderot Le Neveu de Rameau
I Synthèse
Ce travail a présenté un prototype du SM AM avec
le RUP Un SMA qui devait permettre d assister le développeur dans la
conception d application Ce prototype a nécessite un certain nombre d
étapes La première phase de notre travail a essentiellement
consisté à l élaboration des données que notre
système allait utiliser Nous avons suivi une démarche pour le
moins méticuleuse et inductive en
Identifiant les ontologies du processus de développement
RUP
Identifiant les formalismes de représentation des
ontologies étape au cours de laquelle nous avons retenu le formalisme
SPEM sous ensemble UML OCL
Représentant ces ontologies avec le formalisme SPEM
Cette phase d élaboration des données a
conséquemment abouti à la construction de la BCPD
conforme SPEM que le SMA devait exploiter Une autre
étape menée en parallèle a été la
modélisation du SM AM à concevoir avec une consécution d
éléments nouveaux Cette modélisation a consistée
à
Modéliser la société d agents en utilisant
les standards en l occurrence celui de la FIPA Foundation of Intelligent
Physical Agents
Modéliser le SM AM
Bref nous avons identifiés dans le RUP les connaissances
nécessaires pour guider un
développeur dans la modélisation avec le RUP
Puis nous les avons représentées Nous avons également mis
en oeuvre une SMA pour gérer et utiliser ces connaissances Enfin le
prototype fourni permet au développeur de suivre un workflow tout en
étant assisté par le SMA Ce prototype a été
réalisé en implémentant la société d agents
et l application elle même puis en effectuant une intégration des
deux sous systèmes
II Critiques propres
Vu le temps a nous imparti et aussi la documentation non
disponible la réalisation n a pris en compte qu un RUP simplifié
le RUP for Small Project De plus la configuration du processus par l
utilisateur n a pas été réalisée Les plates formes
de réalisation de SMA Zeus JACK FIPA OS n étaient pas assez
documentées pour permettre un développement rapide de plus les
forums sur ces différentes plates formes n étaient pas suivis Une
étude comparative des
http www fipa org
différentes plates formes devrait être
réalisée afin de choisir celle qui sied le mieux à notre
système
Il est certes des éléments qui auraient pu
être faits autrement et beaucoup de choses à corriger du fait de
notre manque d expérience item pour la technologie des agents elle
même Les trois mois de travail en cours devraient nous permettre de
prendre en compte tout le processus et d affiner la BCPD Toute oeuvre humaine n
étant jamais parfaite nous restons ouverts à toutes critiques
constructives
III Perspectives
Dans le cadre du projet CIAO nous devrons dans la suite
intégrer le SMA d assistance à la production d artefacts valides
de notre camarade Francis Michel KONHAWA Nous devrons également
prendre en compte la méthodologie de développement MERISE L
intégration dans CIAO devrait également mettre l accent sur la
réutilisabilité par l exploitation des cas et de la base de
connaissances du domaine d application
Nous ne pouvons qu ici conjecturer en disant que ce prototype
du SM AM vient à point nommé pour guider tous les protagonistes
de la modélisation dans le génie logiciel avec le RUP Loin de la
forte propension des prosélytes du way of modeling avec UML il
est grand temps que les éditeurs se tournent vers le way of
working en utilisant le Processus Unifié qui tend à la
standardisation Cette initiative devrait aller plus loin pour couvrir toutes
les neuf disciplines du RUP
Bibliographie
?????????????
Webographie
???????????
http://www.aifb.uni-
karlsruhe.de
bject anagement roup,
Glossaire
?????????
(M??G/G (M : /1§ iti1§M Qa itiO?1§?1§
8?Giti
Figure 39 Process Structure de SPEM
Un WorkProduct ou Artefact est un élément
produit consommé ou modifié par le processus Un
WorkProduct décrit une classe de produits de travail
résultant d un processus
Un WorkProductKind décrit une catégorie de
produits de travail tels les documents textes les modèles UML les
exécutables le code
WorkDefinition est une Operation qui
décrit le travail réalisé dans le processus Ses sous
classes sont Activity Phase Iteration et Lifecycle dans le
package Process Lifecycle Il dispose d entrées et de sorties
explicites référencées par ActivityParameter
Activity est la sous classe principale de
WorkDefinition Elle décrit un travail réalisé par un
unique ProcessRole les tâches les opérations et les actions qui
sont réalisées ou assistées par un rôle Un
Activity peut être décomposé en éléments
atomiques appelés Step
Un ProcessPerformer définit un rôle pour
un ensemble de WorkDefinitions dans le processus
ProcessPerformer dispose d une sous classe ProcessRole qui
définit les responsabilités pour des WorkProduct
spécifiques et définit les rôles qui réalisent et
assistent des activités spécifiques
Figure 40 Dependancies de SPEM
Une dépendance Categorizes agit d un package
à un élément individuel du processus dans un autre package
Il permet d associer les éléments du processus à plusieurs
catégories
Une dépendance Impacts concerne les
WorkProduct elle indique que la modification d un WorkProduct
peut en invalider un autre
Une dépendance Import indique que le contenu du
package cible est ajouté à la visibilité du package
source
Une dépendance Precedes concerne des
Activity ou des WorkDefinition pour indiquer le type de
précédence Start start synchronisation au début finish
start séquencement strict finish finish synchronisation à la
fin
Une dépendance RefersTo indique qu un
élément du processus réfère à un autre
Une dépendance Trace agit sur les
WorkDefinition pour montrer pour tracer les besoins et les changements
à travers les modèles
Ce tableau présente une correspondance entre des
éléments de SPEM et ceux du RUP Le reste n est pas
modifié
|
SPEM
|
ProcessRole
|
Activity Step
|
WorkProduct
|
Lifecycl e
|
Guidance
|
|
RUP eng
|
Role
|
Activity Step
|
Artifact
|
Process
|
Guidelines
|
|
RUP fr
|
Rôle
|
Activité Etape
|
Artefact
|
Cycle de Vie
|
Guide
|
Eillffl E31 Eil??111112 êl tit?11 laes
Allez à l URL http www rational com
Cliquez sur product dans le menu de gauche
Cliquez sur le produit IBM Rational Unified Process au bas de la
page
Cliquez sur Free Eval à gauche
Cliquez sur Try It pour évaluer le produit ou sur Online
Demo pour une démonstration en ligne du produit RUP
Accepter les termes de la licence
Inscrivez vous pour évaluer le produit en remplissant le
formulaire
Répondez au mail d inscription et vous pouvez consulter
RUP en ligne
Lorsque vous accéder au site vous pouvez cliquez sur
une discipline puis sur un groupe d activités pour avoir une
représentation visuelle sommaire des ontologies à l exemple de la
Figure
Figure 41 Exemple RUP site
_??___ ? ? Iii UY??I 1J1P
>
< Activity (assistant?, discipline, english_name?,
french_name,
numero?, step?)>
< Activity
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< ActivityParameter (english_name?, french_name,
hasWorkPerArtifact)>
< ActivityParameter
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
< WorkDefinition (activity?, discipline, english_name?,
french_name, numero?, parentWork?, performer?)>
< WorkDefinition
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< WorkProduct (english_name?, french_name, isDeliverable,
numero?,
responsibleRole, workProductKind?)>
< WorkProduct
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< WorkProductKind (english_name?, french_name)>
< WorkProductKind
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< Step (english_name?, french_name)>
< Step
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< ProcessPerformer (english_name?, french_name, work?)>
< ProcessPerformer
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< ProcessRole (discipline, english_name?, french_name,
numero?)>
< ProcessRole
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< ProcessStructure (english_name?, french_name)>
< ProcessStructure
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
>
< PrecedenceKind (client, english_name?, french_name,
pk_finish_finish, pk_finish_start, pk_start_start, supplier)>
< PrecedenceKind
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
, french_name)>
< ProcessComponent
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< ProcessLifecycle (english_name?, french_name)>
< ProcessLifecycle
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< Dependancies (client, english_name?, french_name,
supplier)>
< Dependancies
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< Categorizes (client, english_name?, french_name,
supplier)>
< Categorizes
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< Impacts (client, english_name?, french_name,
supplier)>
< Impacts
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< Import (client, english_name?, french_name, supplier)>
< Import
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< Precedes (client, english_name?, french_name,
precedenceKind,
supplier)>
< Precedes
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
< RefersTo (client, english_name?, french_name,
supplier)>
< RefersTo
id ID #IMPLIED
superclass_id IDREFS #IMPLIED
>
s
