|
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
| 
