Processus de développement de systèmes logiciels

DomainElements package

Le package principal définissant l’ensemble des éléments du domaine est le package DomaineElements. Chaque élément du domaine fait partie du vocabulaire du domaine et contient une ou plusieurs statements (phrases qui référence cet élément du domaine). La description des métaclasses de ce package (présenté à la figure 4.3) est donnée comme suit: DomainStatement représente une description d’un élément du domaine du système. DomainVocabulary est une structure qui regroupe les éléments constituant un conteneur pour ces derniers. Les éléments contenus dans le vocabulaire du domaine sont soit des éléments du domaine (DomainElements) soit des acteurs (Actors). DomainElement est une structure regroupant un ensemble de phrases DomaineStatements dans lesquelles l’élément du domaine en question apparait. En d’autre terme, les phrases dont le « sujet » à le même Terms::Noun que l’attribut name du DomainElement considéré. DomainElementAssociation Définit les relations entre les différents éléments du domaine. NounLink Représente un lien qui pointe vers le nom (Terms::Noun) utiliser comme nom de l’élément du domaine. Pour illustrer les métaclasses décrites ci-haut, nous considérons le cas d’étude AFS. La figure 4.4 schématise les différents éléments qui entre dans la définition des éléments d domaine du cas d’étude AFS. 

Terminology Package

Ce package contient la définition des termes utilisés pour la spécification des exigences. La figure 4.6 illustre le contenue du package Terminology. Chaque terme est présenté avec sa définition ainsi que les relations sémantiques qu’il partage avec d’autres termes. Les relations sémantiques utilisés sont : • TermSpecialisationRelation: cette relation décrit les termes sous la forme d’une structuration hiérarchique. La figure 4.5 illustre cette relation pour les noms ainsi que pour les verbes. • HasSynonym: est une relation de type synonyme. • HasHomonym: est une relation de type homonyme. Cette structuration des termes employés dans les exigences est représentée par une ontologie. Nous nous basons sur une ontologie existante, appelée Wordnet pour les définitions et les relations entre les termes usuels du langage. L’utilisateur précise les termes nouveaux liés au domaine métier dans la spécification du domaine et s’appuie sur Wordnet pour les autres termes usuels du langage. Wordnet1 est le résultat de la combinaison d’un dictionnaire de définitions et un thesaurus. Cette base de donnée lexicale fait le lien entre les noms, verbes, adjectifs et adverbes de la langue anglaise [Miller 1995, Fellbaum 1998, Wolter et al. 2008]. Les termes sont groupés dans des sous-ensembles de synonymes (Synset) dans lequel sont groupés les termes exprimant un même concept. Ces sous-ensembles sont reliés entre eux par des relations sémantiques et lexicales. Le principal type des relations existantes dans Wordnet est la relation synonyme. Chaque synset contient une définition succincte ainsi qu’une ou plusieurs phrases illustrant l’utilisation du terme en question. D’autres bases de données de ce type existent pour d’autres langages européens (par exemple, Wortschatzlexikon 2 pour l’Allemand). Le projet EuroWordNet3 propose une base de données Wordnet multilingue pour plusieurs langues (Allemand, Italien, Espagnole, Germanique, Français, Tchèque et Estonien). Dans le cadre du langage URM, Wordnet est utilisée pour stocker les termes utilisés dans les exigences avec les relations sémantiques qu’ils partagent avec les autres termes de la base de données. L’utilisateur est appelé à enrichir cette terminologie par les termes métiers, leurs définitions ainsi que leurs relations avec les autres termes. L’intérêt d’utiliser une telle ontologie généraliste réside dans le fait de pouvoir référencer l’ensemble des termes utilisés dans la description des exigences et des scénarios des contextes afin de réduire les risques d’ambiguïté sur leurs sens. En effet, chaque élément du domaine est décrit avec sa description au sein de fichiers DSpec. Pour chaque élément on identifie l’ensemble des phrases dans lequel il est le sujet (Terminology::Noun). Chaque phrase est basée sur les termes existant dans le thesaurus généraliste (Wordnet). Ce thesaurus stocke les termes avec leurs changements (inflexions), relations avec les autres termes (homonymes, synonymes) et les classes selon leurs natures grammaticales. Ce mécanisme permet d’utiliser non seulement les phrases identiques, mais des phrases similaires lors de la réutilisation des exigences. Nous illustrons l’utilisation d’une telle spécification du domaine sur le cas d’étude présentés à la section 3.1 dans le chapitre 9.

DISCUSSION ET SYNTHÈSE

Au cours du processus de développement de systèmes logiciels, plusieurs types de modèles sont produits pour capturer les différents aspects importants du futur système. À titre d’exemple, une approche orientée objet utilisant le langage UML génère plusieurs diagrammes UML. La nature hétérogène de ces modèles nous pousse à nous poser la question de la cohérence entre ces différents artefacts. Après l’étude de l’état de l’art, nous avons pu identifier une solution consistant à construire une spécification du domaine. Celle-ci permet de capturer les différentes notions et entités du domaine étudié afin de pouvoir les référencer plus tard dans les modèles de contextes et les exigences. Dans ce chapitre, nous avons présenté un formalisme permettant de construire la spécification du domaine étudié. Cette spécification du domaine nous permettra de définir les éléments constituant la base de connaissance liée au système étudié. Nous avons organisé cette spécification en trois packages: un pour les acteurs, un autre pour les composants du système étudié et un dernier pour regrouper l’ensemble des notions du domaine (messages, arguments, attributs. . . ). Pour les autres termes utilisés dans la spécification des exigences, nous avons réutilisé une ontologie généraliste existante afin de pouvoir déterminer le sens des termes employés et lever les ambiguïtés. De cette façon, nous disposons d’une base commune, référençant les entités et les termes utilisés lors de la spécification des exigences et des scénarios des contextes. Dans le chapitre suivant, nous proposons un langage permettant la spécification des scénarios d’interaction entre le modèle du composant étudié et son contexte tout en s’appuyant sur les entités référencées par une spécification du domaine DSpec.