Génération automatique de règles métier par enrichissement sémantique de modèles

Transcription

1 Génération automatique de règles métier par enrichissement sémantique de modèles Diouf Mouhamed, Sofian Maabout, Kaninda Musumbu LaBRI, Domaine Universitaire 351, cours de la Libération Talence Cedex, France {diouf, maabout, RÉSUMÉ. Les systèmes d information (SI) deviennent de plus en plus complexes. La réalisation de tels systèmes fait intervenir de plus en plus d individus avec des expertises variées. Le métier, exprimé au départ de la conception, évoluent et ceci peut devenir assez fréquent. Alors, plus le système est flexible, plus les mises à jour sont faciles. Une manière de mettre sur place un SI flexible est d utiliser l approche par règles métier, dont l objectif est de séparer la logique métier et la logique système. Dans une approche traditionnelle, la logique métier est codée en dure dans l application rendant ainsi la maintenance. L un des principes basiques de l ingénierie du logiciel est l abstraction, qui se fait à travers des modèles. Modélisation et transformation de modèles constituent le cœur du Model Driven Architecture (MDA). Le but de ce papier est de présenter une approche permettant de générer automatiquement une partie des règles métier en combinant les deux domaines que sont le MDA et le Web Sémantique. ABSTRACT. Information systems (IS) are getting more and more complex. The design of such systems requires various individuals with varied expertises. The requirements expressed, when the design of such a system is decided, may change. These changes may even occur very often. Thus, the more the system is flexible, the easier the upgrades will be. One of the standard ways to design flexible systems is the use of the so called business rules s approach whose aim is the separation of business from application. Business rules define and constrain business processes in enterprizes. Software engineers have been doing that into Information Systems, which become difficult to maintain when business changes. The elicitation step of such business rules is heavy. The aim of this paper is to give the way to automatically generate a part of the business rules by combining Model Driven Architecture and the Semantic Web. The semantic web aims to add semantics to the web content in order to use automatic reasoning. MOTS-CLÉS : Intelligence Artificielle, règles métier, ingénierie dirigée par les modèles, représentation de connaissance, Web Sémantique, raisonnement. KEYWORDS: Artificial Intelligence, knowledge based systems, model driven architecture, knowledge representation, reasoning.

2 1. Introduction Le principe de l approche par règles métier est la séparation de la logique métier et de la logique système dans une application. Dans un système à base de règles, une des phases les plus importantes est la phase d élicitation ou d extraction de ces règles d où l intérêt de générer automatiquement une partie. Les règles métier opèrent sur des modèles. Si nous arrivons à bien formaliser les contraintes sur ces modèles en y injectant de la sémantique, alors une génération automatique devient possible. Model Driven Architecture (MDA) [OMG 03b] préconise l utilisation massive de modèles et de transformations de modèles à tous les niveaux du développement de logiciels. D un autre côté le Web Sémantique a pour but de rendre le contenu du web aussi bien exploitable par l homme que par la machine en utilisant des méta-données sur toutes les ressources. Dès lors il parait intéressant de lier les deux domaines que sont le MDA et le Web Sémantique. Des travaux permettant une telle liaison sont en cours de standardisation. Nous allons voir comment les utiliser pour faire de la génération automatique de règles métier. Dans la suite nous allons d abord rappeler sommairement le principe de l approche par règles métier, les principes du MDA et du Web Sémantique. Puis nous présentons notre approche en exposant d abord quelques solutions potentielles que nous n avons pas retenues. Nous présentons également comment nous avons procédé pour atteindre notre objectif qui est l enrichissement sémantique des modèles afin de générer automatiquement des règles métier. 2. L approche par règles métier 2.1. Définition d une règle métier Les règles métier permettent une encapsulation des besoins d un utilisateur [ROS 97]. Le terme règle métier a un sens différent selon un point de vue métier ou professionnel des systèmes d information : D un point de vue système d information : les règles métier sont des formulations qui définissent ou contraignent certains aspects d un métier. Elles permettent de structurer un métier (politique, savoir-faire), de le contrôler ou d en influencer le comportement [ROS 03, BRG ], D un point de vue métier : une règle métier est une directive qui est censée influencer ou guider le comportement d un métier dans le but de mettre en œuvre une politique métier qui est formulée en vue d une réponse à une opportunité ou un risque [HAY 97] Le principe de l approche par règles métier Dans toute application, nous ne nous posons plus la question de savoir est-ce que le métier changera? mais plutôt quand ces changements vont-ils intervenir?. Ainsi, 2

3 il serait plus judicieux de prévoir ces futurs changements dès la phase de conception. L approche par règle métier permet de remédier à l héritage d application dont le code devient à travers le temps très difficile et lourd à maintenir et aussi à faire évoluer. Un système doit être capable de s adapter, en temps réel, aux changements de l environnement. Plus loin encore, il faudrait que le comportement d un système d information puisse être modifié par l expert métier, sans avoir à attendre que le service informatique soit disponible. C est ce qui fait que l approche par règles métier permette la réalisation de systèmes d information guidés par le métier, pour le métier et en vue du métier [ROS 03]. L approche par règles métier permet de fournir un lieu de collaboration entre les acteurs métier et les acteurs système contrairement aux approches classiques. Les règles métier répondent à ces exigences en permettant de séparer (voir la figure 2.2) la logique métier (le comportement) et la logique système d une application (le comment). Ainsi, les experts techniques (développeurs) ne s occupent que de la logique Figure 1. Séparation du métier et du système système applicative tandis que les experts métiers se chargent de la maintenance métier (qui change le plus souvent) dans un environnement zéro-développement. Le cycle de développement devient plus court car de la conception aux scénarios de tests en passant par le codage, les experts métiers travaillent en étroite collaboration avec l équipe technique. Avec l approche par règles métier, dans chaque domaine les applications sont dirigées et gérées par les experts métier du domaine : pour une application financière c est l expert financier, pour une application bancaire c est le banquier, etc. et pour une application de validation ergonomique, c est l expert ergonome qui modifie les règles ergonomiques [DIO 06]. Les règles sont au cœur de toute application, cependant le plus dur est de les recenser et de les structurer en une approche de management plus effective [HAL 02]. L utilisation d un Business Rules Management System (BRMS) facilite le recensement et la mise en œuvre des règles métier. Le principe des règles métier n a rien de nouveau, c est une application directe de théories du domaine de l intelligence artificielle des années 70 [FRI 03] qui, à cette époque, face à un problème de puissance de calcul, passait pour être utopique. Le plus difficile lors de la conception d un système à base de règles métier est l extraction de ces règles. On gagnerait beaucoup à en automatiser une partie. En général la connaissance est représentée sous forme de modèles. Dans les sections suivantes, 3

4 nous allons parler de MDA, de Web Sémantique et comment utiliser ces deux domaines pour automatiser une partie de l extraction des règles métier. 3. MDA et sémantique MDA (Model Driven Architecture) se base sur une idée bien connue : la séparation de la spécification du système, des détails sur la manière dont ce système utilise les capacités de sa plateforme. MDA fournit une approche et des outils permettant : de spécifier un système indépendamment de la plateforme qui le supporte, de spécifier des plateformes, de choisir une plateforme particulière pour le système, de passer d une plateforme particulière à une autre. Les 3 principaux objectifs du MDA sont la portabilité, l interopérabilité et la réutilisabilité. MDA est orienté modèle parce qu il fournit un moyen d utiliser les modèles afin de diriger le cours de la compréhension, de la construction, du déploiement, des opérations, de la maintenance et de la modification. Le principe clé de MDA est l utilisation de modèles aux différentes phases du cycle de développement d une application. Plus précisément, MDA préconise l élaboration de modèles d exigences (Computation Independent Model - CIM), d analyse et de conception (Platform Independent Model - PIM) et de code (Platform Specific Model - PSM) [BLA 05]. Pour le mettre en œuvre, il faut concevoir un CIM puis un PIM. Ensuite, pour produire un PSM, il pourrait être nécessaire de procéder à un marquage du modèle PIM. A partir du PSM on peut produire un modèle de code et enfin du code. Comme le montre la figure 2, la transformation dans le sens inverse, appelée reverse engineering, est aussi envisageable. L idéal serait que toutes ces transformations soient automatisées. Bien qu in- Figure 2. Les étapes du Model Driven Architecture 4

5 téressante, la spécification du MDA ne dit rien sur la sémantique dans les modèles manipulés, ceci est dû à son origine plutôt génie logiciel qui est orienté contenu et non contexte. L utilisation d une sémantique formellement définie dans des modèles MDA offre d intéressantes options pour la génération automatique. Les transformations entre CIM et PIM, inter PIM, entre PIM et PSM, inter PSM et enfin entre PSM et code se font par des règles de transformation. Actuellement ces règles de transformations sont manuelles et il n y a pas de génération automatique car il n y a aucune notion de sémantique entre les concepts qui interviennent dans ces transformations. Malgré l existence d outils tels que Kermeta ou ATL [TRI, JOU 06] qui facilitent la manipulation de modèles, beaucoup de mécanismes pourraient y être automatisés ou semi-automatisés. Pour atteindre un haut degré d automatisation, une définition formelle de la sémantique des concepts et relations utilisées est nécessaire. 4. Notre approche : génération automatique de règles métier par enrichissement sémantique de modèles Les règles métier portent sur la connaissance et travaillent sur des modèles. Il est clair que générer toutes les règles métier n est pas possible. Par exemple depuis le modèle de la figure 3, nous sommes capables de générer les règles suivantes : Tout Humain doit avoir une mère et un père. Si Humain1 est la mère de Humain2 Alors Humain1 est une Femme. Si Humain1 est le père de Humain2 Alors Humain1 est un Homme. Figure 3. Un petit exemple de modèle En enrichissant sémantiquement les modèles, une telle génération est possible. Dans les prochaines sections nous allons voir quels sont les mécanismes possibles pour rajouter de la sémantique dans les modèles. Dans un premier temps nous allons recenser ces mécanismes puis en faire un comparatif pour justifier notre choix Techniques d enrichissement sémantique dans les modèles MDA préconise l utilisation de UML pour ses modèles [BLA 05]. Ce dernier offre des éléments qui pourraient nous permettre d arriver à nos fins, à savoir l ajout de sémantique dans des modèles. Nous allons rappeler les principes de profils UML, du langage de contrainte OCL et Action Semantics. Nous allons voir aussi une nouvelle 5

6 norme en cours de finalisation à l Object Management Group (OMG) ayant pour nom Ontology Definition Metamodel (ODM) Les possibilités avec UML Les profils UML UML peut être utilisé pour modéliser une multitude de domaines, dès lors il devient difficile de savoir si un modèle correspond à une application objet, un métamodèle, une base de données ou autre chose [BLA 05]. Afin de spécialiser un modèle UML à un domaine d application, l OMG a standardisé le concept de profil UML. Cette spécialisation est dynamique donc ne modifie en rien la structure du métamodèle UML et peut se faire sur n importe quel modèle UML. Un profil UML se définit aux travers de concepts de stéréotype. Un stéréotype est une sorte d étiquette nommée que l on peut coller sur n importe quel élément d un modèle UML. Lorsqu un stéréotype est collé sur un élément, le nom du stéréotype définit la nouvelle signification de l élément. Par exemple, coller un stéréotype nommé Sécurisé sur une classe UML signifie que la classe en question n est plus une simple classe mais que c est une classe sécurisée. Utiliser un profil consiste donc à coller sur un modèle UML un ensemble de stéréotypes. L intérêt principal des profils est qu il est possible de leur associer des traitements spécifiques du domaine couvert par le profil. Ces traitements permettent de rendre les modèles UML profilés plus productifs, car disposant d informations supplémentaires grâce aux stéréotypes. Pour traiter la sémantique dans des modèles on peut faire un raisonnement sur ces étiquettes. Par exemple on peut mettre en œuvre le raisonnement suivant : Si l étiquette est Sécurisée alors seules les classes ayant pour étiquette Directeur peuvent l utiliser. Un tel raisonnement est tout à fait possible, mais ce n est pas un raisonnement automatique. Un raisonnement automatique n est possible que si la sémantique est formellement définie, ce qui n est pas le cas pour les profils UML et donc pas exploitable par une machine Le standard OCL Dans UML il n est pas possible d exprimer précisément ce que fait une opération, c est-à-dire son corps. En effet dans le métamodèle UML, une opération est définie uniquement par son nom, ses paramètres et les exceptions qu elle émet. Le langage OCL [OMG 03d], Object Constraint Language, a été défini par l OMG pour combler cette lacune. OCL peut exprimer des contraintes sur tous les éléments d un modèle UML. Il est utilisé pour exprimer des pré et post-conditions sur les opérations. Par exemple, il est possible de dire que l opération accepterunelocationdevoiture a comme pré-condition verifierclientmajeur. Les expressions OCL ne génèrent aucun effet de bord. L évaluation d une expression OCL n entraîne aucun changement d état dans le modèle auquel elle est rattachée. Cependant la version OCL2.0 permet de faire référence à des opérations avec effet de bord dans les post-coditions. OCL dispose d un formalisme textuel. Une expression OCL porte sur un élément du 6

7 modèle UML. Pour être évaluée, elle doit être rattachée à un contexte, qui doit être directement relié à un modèle UML. Pour des raisons évidentes de simplicité d utilisation, OCL reste avant tout un langage textuel. Cependant, un effort important a été fourni pour définir la façon de passer automatiquement de la forme textuelle à la forme modèle bien qu elle ne soit pas triviale. OCL semble donc être une bonne solution pour notre problématique qui est d ajouter de la sémantique dans les modèles MDA, cependant ce n est pas le cas. Le premier souci avec OCL c est qu il ne permet pas d exprimer des opérations d effets de bord. Aussi, comme les profils UML, la sémantique n est pas formellement définie en OCL et donc n offre pas de possibilité de traitement automatique Action Semantics Jusqu à sa version 1.4, UML était très critiqué parce qu il ne permettait pas de spécifier des créations, des suppressions ou des modifications d éléments de modèles. Ces actions ne pouvant pas non plus être spécifiées à l aide du langage OCL, puisque celui-ci est sans effet de bord, il était nécessaire de standardiser un nouveau langage. C est ce qui a donné naissance au langage AS (Action Semantics) [BLA 05]. L objectif de Action Semantics [CON 01] est de permettre de définir des actions. Une action au sens AS est une opération sur un modèle qui fait changer l état du modèle. Grâce à ces actions, il est possible de modifier les valeurs des attributs, de créer ou de supprimer des objets, de créer de nouveaux liens entre les objets, etc. Ainsi le concept d Action Semantics permet de spécifier pleinement le corps des opérations UML. Au départ AS était un langage développé à part entière hors de UML puis inclus dans la version 1.5. Dans UML 2.0, il est enfin totalement intégré au métamodèle. AS n est standardisé que sous forme de métamodèle, et aucune syntaxe concrète (textuelle) n est définie, contrairement à OCL. Ceci offre l avantage d utiliser la syntaxe que l on veut. Ce manque de format concret, rend l utilisation de AS complexe. Outre cette complexite d AS, nous avons toujours le même souci que les profils UML et OCL, c est-à-dire la sémantique n est pas formalisée et donc n offre aucune forme d inférence automatique Synthèse Les mécanismes de UML ne sont pas des solutions adaptées pour faire de l enrichissement sémantique, d ailleurs ceci n est pas une surprise car le métamétamodèle (Meta Object Facilities MOF) qui les définit ne s intéresse pas à la définition d une sémantique formelle. D un autre côté nous avons le domaine du Web Sémantique qui ne s intéresse qu au traitement automatique de la sémantique [PAS 04]. Alors quoi de plus naturel que d opter pour l utilisation des techniques du Web Sémantique pour rajouter de la sémantique aux modèles conceptuels. En 2004, le W3C avait fini de mettre sur place OWL qui est une recommandation pour la définition d ontologies [SMI 04]. Après l étude de OWL nous nous sommes rendus compte qu il était parfait pour nos besoins à savoir définir une sémantique et en faire un traitement automatique. Cependant nous étions confrontés à un problème, qui était, comment concilier Web Sémantique et modèles MDA? C est là qu inter- 7

8 vient l Ontologie Definition Metamodel qui est en cours de standardisation par l OMG [OMG 06b] et qui a pour objectif de permettre la modélisation d une ontologie en utilisant une instance du métamétamodèle MOF Ontology Definition Metamodel (ODM) ODM [OMG 06b] a pour objectif de permettre la modélisation d ontologies en utilisant une instance de MOF. ODM est une spécification de l OMG qui, à l heure actuelle (Avril 2007) est encore en phase de finalisation. ODM est le fruit de recherches dans le domaine du MDA et de l ontologie [BAC 01, BAC 02, BRO 04, CRA 01, DJU 05, FAL 03, KEN 02]. L ingénierie d ontologies a atteint un certain degré de maturité et un franc succès dans certains domaines. Cependant, il y a toujours un écart entre l ingénierie d ontologies (basée sur l intelligence artificielle) et l ingénierie traditionnelle de logiciels. Depuis quelques décennies, l ingénierie de logiciels s est définie sur différents langages de modélisation tel que UML. L objectif premier des travaux sur ODM est de réduire l écart entre deux différents, mais complémentaires, domaines d ingénierie [PAN 05]. Une ontologie définit les termes et concepts (sens) utilisés pour décrire et représenter une connaissance. Une ontologie peut aller de la taxonomie (connaissance avec un minimum d hiérarchie ou structure Parent/Enfant) au thésaurus ou lexique (mots et synonymes) ou modèles conceptuel (avec une connaissance plus complexe), à la théorie de logique (avec une connaissance très riche, complexe, consistante et sensée) [CRA 04]. Une ontologie doit être exprimée dans une syntaxe bien définie permettant une automatisation du traitement par les machines. Les ontologies sont souvent décrites dans des langages de représentation de la connaissance (KR : Knowledge Representation). Ces langages sont pour la plupart structurés suivant des formalismes de logique (premier ordre, logique de description,...). Cette structure a rendu la syntaxe de ces langages inhabituelle et peu commode à ceux qui ont l habitude d utiliser d autres langages de modélisation, ce qui est le cas de la plupart des développeurs de logiciel ; ceci explique le manque d utilisation large de ces langages et donc le développement d ontologies, retardant ainsi l adoption des technologies du Web Sémantique. D un autre côté UML [GRO 04] est un langage de modélisation populaire et largement répandu en matière de modélisation conceptuelle. Beaucoup de communautés utilisent UML avec une armada d outils très évolués aussi bien en open source qu en propriétaire. La familiarité des utilisateurs avec UML, la disponibilité des outils UML, l existence de plusieurs modèles de domaines et la similarité de ces modèles aux ontologies, suggèrent qu UML puisse être utilisé pour faire des développements d ontologies. Ceci permettra aussi de créer un lien entre la communauté UML et celle du Web Sémantique [OMG 03c] avec comme bénéfices : La génération de descriptions d ontologies depuis des modèles UML existants ; La génération de modèles UML depuis une ontologie ; L intégration d ontologies standards dans les modèles UML [OMG 06b]. 8

9 Depuis quelques années il y a de plus en plus d intérêt d utiliser des ontologies pour communiquer de la connaissance dans les logiciels systèmes [PAN 05]. Cet intérêt s explique par le fait de vouloir avoir un haut niveau formel de définition des concepts et des relations entre eux, permettant ainsi l automatisation de tâches par les machines. Comme le montre la figure 4, ODM apporte les spécifications normatives suivantes : Un métamodèle compatible MOF2 pour la définition d ontologies. Un profil UML2 pour permettre l utilisation des notations UML pour la définition d ontologies. Un langage de mapping du métamodèle de ODM vers les langages d ontologies web tels que Description Logic, OWL DL. Figure 4. Principe de ODM 5. Le Web et le raisonnement automatique L une des caractéristiques principales des ontologies décrites en OWL DL est qu elles puissent être traitées par un reasoner. L un des services principaux qu offrent un reasoner est de tester si oui ou non une classe est une sous classe d une autre classe. En procédant de la sorte sur toutes les classes d une ontologie, il est possible pour un reasoner d inférer sur toute l hiérarchie de classes dans une ontologie. Un autre service standard qu offre un reasoner est de tester la consistance d une ontologie. En se basant sur les conditions d une classe, le reasoner peut vérifier si oui ou non il est possible pour une classe d avoir une instance. Lors de la création d ontologies assez consistantes (plus de 1000 classes), l utilisation de reasoner pour calculer les relations classe/sous classes devient vitale. Ceci permet une classification simple, on parle alors de classification assertée et de classification inférée. OWL bénéficie des résultats de plus de 15 ans de recherche dans les Logiques de Description (DL) [BAA 03a, HOR 04]. En effet, pour OWL, une sémantique est définie de telle sorte que les gros fragments (expressions) du langage peuvent directement être exprimés en Description Logics [BAA 03b]. Les logiques de descriptions sont une famille qui permet la représentation de connaissance et sont des descendants de la théories des réseaux sémantique et de KL-ONE [BRA 85]. Les logiques de description décrivent les domaines en terme de concepts (classes), roles (propriétés et relations) 9

10 et individuels (instances). Dans la terminologie des logiques de description, un tuple de T-box et de A-box définit une base de connaissance. Un individuel est un objet spécifique nommé. Avec quelques restrictions, on peut voir que les bases logiques de OWL peuvent être caractérisées par les logiques de descriptions de type SHIQ(D n ) [BAA 05]. Cela veut dire qu avec quelques restrictions, les documents OWL peuvent être automatiquement transformés en T-box SHIQ(D n ). La partie RDF des documents OWL peuvent être transformés en A-box SHIQ(D n ) [HAA 03, MEI 04]. La logique SHIQ(D n ) est intéressante pour des applications pratiques parce qu il existe des systèmes d inférence avec un haut niveau d optimisation (par exemple Racer). Dans de tels systèmes, en se basant sur les T-box nous pouvons faire les raisonnements suivants : Consistance de concepts : Est-ce que l ensemble des objets décrits par un concept est vide? Concept subsumé : Y a t-il une relation de sous-ensemble entre des objets définis par deux concepts? Trouver toutes les incohérences entre les concepts définis dans une T-box. Déterminer les parents et les fils d un concept. Avec la terminologies A-box nous pouvons faire les raisonnement suivants : Verifier la consistance d une A-box. Test d instances : Est qu un objet est une instance d un concept? Recherche d instances : Trouver tous les objets d une A-box vérifiant une condition. Calculer le type direct d un objet : trouver le concept d une T-box le plus spécifique pour un individuel. Les logiques de description, avec ses mécanismes d inférence peuvent être utilisés pour résoudre les problèmes actuels dans les bases de connaissance OWL Notre approche : générer des règles métier à partir de modèles sémantiquement enrichis Nous avons expliqué que les règles métier utilisent des modèles. Les modèles MDA ne disent rien sur la sémantique. Par ailleurs le Web Sémantique, avec le concept de traitement automatique, laisse penser à une nouvelle vague d applications très excitantes. Notre approche est de lier modèles et Web Sémantique, en ajoutant de la sémantique aux modèles, dans le but de générer des règles métier (ou faire d autres traitements par exemple fusion de bases de connaissances). La figure 5 illustre notre approche. Pour être plus concrêt, considérons la figure 6. Nous avons d un coté un modèle UML qui exprime le fait que chaque Humain a un père et une mère, qu un père ne peut être que de type Homme et une mère que de type Femme. A droite, nous avons 10

11 Figure 5. Combinaison de modèles MDA et Sémantique Web pour un traitement sur les règles métier son équivalent en OWL. En se basant sur ces assertions, nous aimerions bien pouvoir générer automatiquement la règle métier : Si la mère du Christ s appelle Marie alors Marie est une Femme. Plus généralement, si on a : + <rdf:rdf...> <owl:ontology rdf:about=""/> <owl:class rdf:id="human"/> <owl:class rdf:id="male"> <rdfs:subclassof rdf:resource="#human"/>.. <owl:class rdf:id="female"> <rdfs:subclassof rdf:resource="#human"/>.. <owl:objectproperty rdf:id="hasmother"> <rdfs:domain rdf:resource="#human"/> <rdfs:range rdf:resource="#female"/>... <owl:objectproperty rdf:id="hasfather"> <rdfs:domain rdf:resource="#human"/> <rdfs:range rdf:resource="#male"/>... </rdf:rdf> => IF Christ mother s name is Marie Then Marie is a Woman Figure 6. Un modèle UML et son équivalent OWL d où on génère des règles Alors, on peut générer la règle : Predicat : Domaine1 Domaine2 SI Objet1 Predicat Objet2 ALORS Objet1 est de type Domaine1 ET Objet2 est de type Domaine2 11

12 En somme, pour la génération de règles métier on se base sur les Tboxes (concernant la hiérarchisation des classes et la définition des propriétés : transitive, fonctionnelle, symétrique, etc. ) et les Aboxes (concernant les assertions sur les individus). Notre approche consiste à enrichir sémantiquement un modèle UML en vue d utiliser les techniques du Web Sémantique pour la génération de règles métier. Une fois qu on a enrichi le modèle UML en le transformant par ODM, on obtient à la fin un modèle OWL. Depuis ce dernier, nous utilisons la syntaxe et la sémantique des éléments OWL (T-box et A-box). Pour une propriété on peut définir un ou plusieurs axiomes qui fournissent des caractéristiques additionnelles. OWL supporte les constructions suivantes pour les axiomes sur les propriétés : Les éléments RDF schéma : subpropertyof, doamin et range. Les relations avec les autres propriétés : equivalentproperty et inverseof. Les contraintes globales de cardinalité : FunctionalProperty et InverseFunctionalProperty. Les caractéristiques de propriétés logiques : SymmetricProperty et Transitive- Property La déclaration des individus. La figure 7 montre l architecture de notre approche qui revient, à combiner une sémantique (en OWL/RDF par l intermédiaire de ODM) et un modèle MDA. A partir de celui-ci et avec l utilisation de Java Métadata Interface [PRO 02] (en se basant sur le XMI [OMG 05] généré) ou d un moteur de raisonnement, on génère des règles métier simples. Figure 7. Architecture de notre approche Notre objectif est d utiliser le semantics enrichment dans une finalité de génération de règles métier. Notre procédé consiste : à partir d un modèle en entrée, d utiliser ODM pour générer un modèle d ontologie OWL. Ce modèle d ontologie OWL sera enrichi en utilisant un éditeur graphique d ontologies, qui peut être n importe quel 12

13 outil UML doublé de profil UML pour OWL, afin de rajouter de la sémantique formelle ou informelle. A partir de ces informations on peut envisager 2 possibilités : utiliser JMI pour exploiter le XMI, mais là on perd de l information, ou utiliser les caractéristiques de représentation de la connaissance de OWL/RDF et un moteur de raisonnement pour générer des règles métier en se basant sur les propriétés et les instances. La génération de ces règles métier se fera en utilisant l approche MDA. Nous allons, comme le montre la figure 8, générer les règles métier au format SBVR [OMG 06a] au niveau de la couche CIM puis de descendre vers les couches PIM en utilisant formalisme notre langage ERML, le W3C RIF, PRR de OMG ou RuleML [W3C 05, OMG 03a, RUL ]. Depuis la couche PIM, nous faisons une dernière génération vers la couche PSM afin d avoir un format de règles exécutable. Dans notre prototype, le modèle est un modèle ECore [WU 04] et notre sémantique Figure 8. Architecture de notre approche à travers les couches du MDA est en OWL. Les travaux de l OMG sur ODM vont dans le même sens, c est à dire lier MDA et le Web Sémantique. Cependant, ce futur standard s intéresse uniquement à la façon utiliser UML pour définir des ontologies. ODM est juste un ensemble de méta-modèles (un pour le RDF, un pour OWL, un pour Topic Map et un pour Common Logic) et un profil UML [DUR 04, GA 06, OMG 06b]. Pour nous, ODM arrive au bon moment, juste quand nous nous posions la question à savoir comment utiliser directement notre sémantique en OWL avec un des modèles MOF (ECore dans notre cas). Dans notre prototype nous avons utilisé une implémentation du projet Eclipse de ODM qui est appelée EODM [PRO 06]. 6. Conclusion En matière de systèmes d information, la recherche de flexibilité doit toujours être présente, quelque soit la couche. Le métier d une application est quelque chose qui ne cesse d évoluer et donc avoir une approche capable d intégrer ces changements et ce par des personnes non techniques dans un environnement zéro développement, apporte un plus. Telle est la finalité de l approche par règles métier, la séparation nette entre logique métier et logique système. Cette approche est de plus en plus utilisée 13

14 bien que l extraction des règles métier reste assez laborieuse, d où la recherche d en automatiser une partie. Nous avons présenté une technique d enrichissement sémantique des modèles se basant sur les technologies du Web Sémantique. Cet enrichissement nous permet de générer une partie des règles grâce à un raisonnement automatique. Actuellement nous disposons d un prototype qui génère automatiquement des règles métier au niveau de la couche CIM du MDA dans une syntaxe SBVR proche du langage naturel mais qui n est pas exécutable. L étape suivante sera d aller plus loins dans les couches du MDA afin d obtenir un formalisme exécutable, ceci revient à passer du SBVR (CIM) vers notre formalisme de règles (PIM). Dans nos travaux antérieurs, nous avons développé des translateurs permettant de passer de notre formalisme de règles vers des formats spécifiques à certains moteurs de règles (PSM). Aussi, il nous faudra préciser de manière formelle ce que nous pouvons générer comme règles métier et ce que nous ne pourrons pas avec notre approche. Enfin, nous pouvons noter que l ajout de sémantique aux modèles ouvre d autres opportunités notamment la fusion de bases de connaissances. Remerciements Nous tenons à remercier la société Génigraph (Groupe Génitech) et spécialement l équipe R&D de E-citiz pour leur support. Nous remercions les lecteurs anonymes pour leurs remarques qui nous ont permis d améliorer la présentation de cet article. 7. Bibliographie [BAA 03a] BAADER F., HORROCKS I., SATTLER U., «Description logics as ontology languages for the semantic web», [BAA 03b] BAADER F., CALVANESE D., MCGUINNESS D. L., NARDI D., PATEL- SCHNEIDER P. F., Eds., The Description Logic Handbook : Theory, Implementation, and Applications, Cambridge University Press, [BAA 05] BAADER F., HORROCKS I., SATTLER U., «Description Logics as Ontology Languages for the Semantic Web.», Mechanizing Mathematical Reasoning, 2005, p [BAC 01] BACLAWSKI K., KOKAR M. K., KOGUT P. A., HART L., SMITH J., HOLMES III W. S., LETKOWSKI J., ARONSON M. L., «Extending UML to Support Ontology Engineering for the Semantic Web», Lecture Notes in Computer Science, vol. 2185, 2001, p [BAC 02] BACLAWSKI K., KOKAR M. M., SMITH J. E., WALLACE E., LETKOWSKI J., KOETHE M. R.,, KOGUT P., «UOL : Unified Ontology Language», Assorted paper discussed at the DC Ontology SIG Meeting,, [BLA 05] BLANC X., MDA en action, Eyrolles, France,

15 [BRA 85] BRACHMAN R. J., SCHMOLZE J. G., «An Overview of the KL-ONE Knowledge Representation System.», Cognitive Science, vol. 9, n o 2, 1985, p [BRG ] BRG B. R. G. C., «http :// Web page. [BRO 04] BROCKMANS S., VOLZ R., EBERHART A., LÖFFLER P., «Visual Modeling of OWL DL Ontologies Using UML.», International Semantic Web Conference, 2004, p [CON 01] CONSORTIUM T. A. S., «Action semantics for the uml», OMG Specification (ad/ ), March [CRA 01] CRANEFIELD S., «Networked Knowledge representation and exchange using UML and RDF», Journal of digital information, vol. 1, n o 8, [CRA 04] CRANEFIELD S., PAN J., «Bridging the Gap Between the Model-Driven Architecture and Ontology Engineering», Proc. of AOSE 2004 Workshop,, [DIO 06] DIOUF M., XIONG J., FARENC C., WINCKLER M., «AUTOMATING GUIDE- LINES INSPECTION From Web site Specification to Deployment», CADUI,, [DJU 05] DJURIC D., GASEVIC D., DEVEDZIC V., «Ontology Modeling and MDA.», Journal of Object Technology, vol. 4, n o 1, 2005, p [DUR 04] DURIĆ D., «MDA-based Ontology Infrastructure», Proc. of ComSIS 2004, Vol 1, No 1,, February [FAL 03] FALKOVYCH K., SABOU M., STUCKENSCHMIDT H., «UML for the Semantic Web : Transformation-Based Approaches.», Knowledge Transformation for the Semantic Web, p , [FRI 03] FRIEDMAN-HILL E., JESS in Action, Manning Publications Co, Greenwich, UK, [GA 06] GAĚVI `C D., DJURIÉ D., DEVEDŽIĆ V., Model Driven Architecture and Ontology Development, Springer-Verlag, Berlin, DE, [GRO 04] GROUP T. O. M., «Unified Modeling Language : Superstructure», OMG Specification, February [HAA 03] HAARSLEV V., MOLLER R., «Racer : An owl reasoning agent for the semantic web», [HAL 02] VON HALLE B., Business Rules Applied, John Wiley & Sons, New York, USA, [HAY 97] HAY D., HEALY K. A., «GUIDE Business Rule Project Final Report», rapport, October [HOR 04] HORROCKS I., PATEL-SCHNEIDER P. F., BOLEY H., TABET S., GROSOF B., DEAN M., «SWRL : A Semantic Web Rule Language Combining OWL and RuleML», W3C Member Submission,, [JOU 06] JOUAULT F., ALLILAIRE F., BÉZIVIN J., KURTEV I., VALDURIEZ P., «ATL : a QVT-like transformation language.», OOPSLA Companion, 2006, p [KEN 02] KENDALL E. F., DUTRA M. E., MCGUINNESS D. L., «Towards A Commercial Ontology Development Environment», Proceedings of the 1st International Semantic Web Consference (Posters and Demos), [MEI 04] MEI J., BONTAS E. P., «Reasoning Paradigms for OWL Ontologies», rapport, November 2004, Freie Universität Berlin. 15

16 [OMG 03a] OMG T. O. M. G., «Production Rule Representation (PRR) RFP», OMG Request For Proposal (br/ ), [OMG 03b] OMG T. O. M. G., «Model Driven Archtecture Guide Version 1.0.1», OMG Specification, June [OMG 03c] OMG T. O. M. G., «Request For Proposal for Ontology Definition Metamodel», OMG Request For Proposal, March [OMG 03d] OMG T. O. M. G., «UML 2.0 OCL Specification», OMG Specification, October [OMG 05] OMG T. O. M. G., «MOF 2.0/XMI Mapping Specification, v2.1», OMG Specification (formal/ ), [OMG 06a] OMG T. O. M. G., «Semantics of Business Vocabulary and Business Rules (SBVR)», OMG Specification, March [OMG 06b] OMG T. O. M. G., IBM, SOFTWARE S., «Ontology Definition Metamodel», OMG Specification, June [PAN 05] PAN Y., XIE G., MA L., YANG Y., QIU Z., LEE J., «IBM Research Report : An MDA-based system for Ontology Engineering», rapport n o RC23795, November 2005, IBM Research Division, Yorktown Heights, NY US. [PAS 04] PASSIN T. B., Explorer s guide to the Semantic Web, Manning Publications Co, Greenwich, UK, [PRO 02] PROCESS(JCP) J. C., «Java Metadata Interface (JMI)», Sun Java Specification Request (JSR 40), [PRO 06] PROJECT E., «Eclipse Ontology Definition Metamodel project», Eclipse project, [ROS 97] ROSS R. G., The Business Rule Book, Business Rule Solutions, LLC, Houston, USA, [ROS 03] ROSS R. G., Principles of the Business Rule Approach, Addison-Wesley, Boston, USA, [RUL ] RULEML, «The RuleML initiative». [SMI 04] SMITH W. O. M. K., WELTY C., MCGUINNESS D. L., «OWL Web Ontology Language Reference», W3C Standard, February [TRI ] TRISKELL, «Kermeta project». [W3C 05] W3C, «Rule Interchange Format (RIF)», W3C Workgroup, [WU 04] WU C. G., «Modeling Rule-Based Systems with EMF», Eclipse Corner Article,,