La modélisation d’un service opérationnel

Cette section présente le méta-modèle de la couche opérationnelle. L’objectif de ce méta-modèle est de décrire la structure statique de l’application qui soutiendra la recherche et le couplage des services qui sont requis par la gestion de modèles. La figure 76 montre le méta-modèle de service opérationnel.

FIGURE 76. MODELE DE SERVICE OPERATIONNEL

Un service opérationnel (voir le paquetage « opService » dans la figure 76) correspond à une application exécutable composée d’autres services de gestion de modèles. Un service de gestion de modèles est un outil de gestion de modèles offert par un fournisseur. Ces services peuvent être fournis par des outils de gestion de modèles (par exemple : un AGL, un outil de modélisation ou un outil de transformation de modèles, etc.).

Les services opérationnels peuvent porter sur un ou plusieurs modèles (par exemple : le modèle des arbres de tâches, le modèle de classes, le modèle de cas d’utilisation, etc.). De la même

façon que dans les couches intentionnelle et organisationnelle, nous avons utilisé ici l’ontologie des produits « OntologyProduct » décrite dans la section 2.2.2.

Nous devons noter que la modélisation de services opérationnels n’est pas nouvelle. Néanmoins, dans notre travail, nous avons voulu augmenter les approches classiques en utilisant les notions telles que : la collaboration, la qualité logicielle et le contexte de l’utilisateur, pour répondre aux besoins que nous avons identifiés en étudiant la méthode Symphony augmentée. Cette étude a montré que divers acteurs (par exemple, spécialistes génie logiciel, spécialistes IHM, ergonomes) travaillent de manière coordonnée sur des modèles différents. Ces conclusions nous amènent à proposer un méta-modèle de services opérationnels associé à divers types de fonctionnalités (section 6.1.1.) et caractérisé par 1) les aspects liés à la conception collaborative (les aspects collaboratifs du travail de conception) (section 6.1.2.), c’est-à-dire les types de collaboration dont les concepteurs de modèles pourraient avoir besoin ; 2) le contexte d’utilisation des concepteurs de modèles et les caractéristiques de l’utilisateur (section 6.1.3.) ; 3) un certain nombre de facteurs de qualité logicielle (section 6.1.4.). Par la suite nous décrirons ces trois aspects.

6.1.1. Les fonctionnalités

Un service opérationnel fournit plusieurs fonctionnalités (voir le paquetage « opFunctionalityFactor » dans la figure 76). La fonctionnalité d’un service opérationnel définit la façon dont un concepteur de modèles pourra effectuer les opérations sur les modèles (par exemple, texte, graphique ou les deux), les langages supportés pour stocker l’information (par exemple XMI, etc.) et les éventuelles opérations de service (par exemple, la création, l’édition, suppression, etc.).

L’étude des différents outils de gestion de modèles (cf. état de l’art, section 1.2.) a mis en évidence l’ensemble des fonctionnalités offertes par les outils. Nous avons synthétisé les fonctionnalités des outils au moyen de cas d’utilisation. Au niveau opérationnel les fonctionnalités offertes par les outils sont représentées par la figure 77. Ces fonctionnalités sont : la gestion de modèles, la transformation de modèles, la vérification de la cohérence, la simulation et les tests.

FIGURE 77. DIAGRAMME DE CAS D’UTILISATION DES FONCTIONNALITES ASSOCIEES A LA GESTION DE MODELES AU NIVEAU OPERATIONNEL

Le cas d’utilisation « manage a model », englobe toutes les fonctionnalités d'édition de modèles, quelque soit leur nature et leur niveau d'abstraction. En ce qui concerne ce cas d’utilisation, nous l’avons spécialisé pour indiquer la collaboration qui peut exister parmi les concepteurs de modèles, qui doivent effectuer des tâches collaboratives, comme par exemple, l'édition partagée d'un modèle.

Les autres cas d’utilisation de la figure 77 se rapportent à la manipulation des modèles, par exemple : le cas d’utilisation « Transformer un modèle » consiste à faire la transformation d’un modèle dans du code ou dans d’autre langage, cette transformation peut être réutilisée par un autre concepteur dans le processus de développement.

6.1.2. Les types de collaboration

Pour supporter les besoins de création d’environnements collaboratifs, un service opérationnel est lié à plusieurs formes de collaboration. La figure 78 montre l’extrait concernant les aspects liés à la collaboration. La collaboration est décrite ici à un niveau opérationnel tel que la centralisation des tâches, l’exécution synchrone, etc.

FIGURE 78. EXTRAIT DU META-MODELE DE SERVICE OPERATIONNEL REPRESENTANT LES TYPES DE COLLABORATION

Une forme de collaboration est caractérisée suivant le modèle de Denver de Salvador [Salvador

et al., 1996] et sur la classification Espace-Temps proposée par Ellis [Ellis et al., 1991]. Le modèle de Denver établit que les utilisateurs peuvent être proches ou éloignés et interagir de façon synchrone

(temps réel) ou asynchrone.

La classification Espace-Temps proposée par Ellis repose sur deux caractéristiques, à savoir oùet quand une action est exécutée par un des utilisateurs par rapport aux autres utilisateurs. Donc, dans le contexte de notre travail, une collaboration est définie en fonction de deux axes : l’espace (« space »), et le temps (« time »). La figure 79 résume les deux axes considérés.

L’espace prend en compte le fait que les tâches sont centralisées ou distribuées. Un service de modélisation qui supporte une tâche distribuée offre une fonctionnalité de modélisation permettant de travailler à plusieurs concepteurs sur un même modèle.

Les tâches peuvent être exécutées dans des espaces partagés ou privés. Finalement, le temps est le moment de la collaboration. Il conduit à distinguer le travail synchrone (même moment de la collaboration réalisée par les différents utilisateurs) du travail asynchrone (moments différents) permettant à chacun de travailler quand il en a la possibilité et/ou la nécessité.

6.1.3. Le contexte d’utilisation

En ce qui concerne le profil de l’utilisateur et le contexte d’utilisation d’un service opérationnel, la figure 80 considère qu’un service opérationnel peut être exécuté dans différents contextes d’utilisation par des spécialistes qui ont divers niveaux d’expertise. Le contexte d’utilisation est modélisé par le profil de l’utilisateur, la plateforme et la modalité d’interaction. Notons que les « compétences » de l’utilisateur ne relèvent pas de ce niveau (indépendantes de l’outil). C’est au niveau organisationnel que nous exprimons à qui est dédié un service organisationnel (cf. figure 69).

FIGURE 80. EXTRAIT DU META-MODELE DE SERVICE OPERATIONNEL REPRESENTANT LE PROFIL DE L’UTILISATEUR ET LE CONTEXTE D’UTILISATION

Un service opérationnel est caractérisé par le niveau d’expertise nécessaire à l’utilisateur. Nous considérons, dans nos travaux, les niveaux d’expertise suivantes : expert, occasionnel et novice.

Le contexte d’utilisation est un espace d’information structuré qui inclut les plateformes logicielle et matérielle exigées par le service. Il est relié à une variété de modalités d’interaction. Nous considérons ici, par exemple, la possibilité d’avoir des services de gestion de modèles qui offrent des modalités graphiques, gestuelles, tactiles, vocales, etc.

Nous prendrons comme exemple l’environnement de modélisation ConcurTaskTress (CTTE), un outil basé sur Java réalisé par le laboratoire HIID-ISTI/CNR de Pise (Italie) [Mori et al., 2002]. Cet outil offre une interaction graphique.

6.1.4. La qualité du logiciel

Pour garantir la qualité dans l’utilisation d’un outil de gestion de modèles, nous avons inclus dans notre approche la notion de qualité logicielle. Un fournisseur d’outils souhaitant intégrer un outil en tant que service opérationnel est donc tenu d’en mesurer la qualité. La qualité logicielle est une appréciation globale d’un logiciel basée sur de nombreux indicateurs. Les définitions de qualité logicielle sont données en termes de « conformité aux besoins ». Nous avons intégré dans notre méta-modèle opérationnel l’ontologie des facteurs de qualité « OntologyQuality ».

Les concepts et termes de qualité que nous avons repris sont issues des critères de qualité de FURPS [Grady, 1992], McCall [McCall et al., 1977], Boehm [Boehm et al., 1978], IEEE 1061[IEEE std 1061, 1992], Dromey [Dromey, 1995], ISO 9126 [ISO std 9126, 1991]. La figure 81 montre l’extrait du méta-modèle de service opérationnel qui représente l’aspect de la qualité du logiciel. La figure ci-dessous montre qu’un service opérationnel est catégorisé par au moins un terme de qualité.

Pour chaque outil, un critère de qualité est apprécié à l’aide d’une évaluation. Cette évaluation peut être exprimée comme une valeur d’excellence. La valeur d’évaluation est évaluée à l’aide d’une classe énumération appelé « EnumValue ».

Par la suite, nous présenterons un formalisme de représentation graphique pour les services opérationnels.