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
