Processus de développement de système contraint par l’urbanisation d’un système d’information Jacques Simonin*,** – Antoine Beugnard* – Rémi Nédélec*** * Institut Télécom/Télécom Bretagne – ** Lab-STICC UMR CNRS 3192 - UEB Technopôle Brest Iroise F-29238 Brest cedex {jacques.simonin, antoine.beugnard}@telecom-bretagne.eu ***Orange Labs Avenue Pierre Marzin F-22300 Lannion RÉSUMÉ.
L’ingénierie des modèles ou MDE est souvent utilisée en entreprise dans des tâches du processus de développement proches du code. L’objectif de cette étude réalisée pour l’opérateur de télécommunication Orange est de montrer comment les tâches amont du processus de développement préconisé dans l’entreprise peuvent être décrites et outillées par l’utilisation du MDE. La mise en œuvre se traduit par un enchaînement de transformations de modèles intégrant en entrée des modèles d’analyse des exigences du système et produisant en fin d’enchaînement le modèle résultant du codage. Chacune de ces transformations de modèles est constituée de tâches manuelles réservées aux experts telles que la conception des éléments du modèle et de tâches automatisées telles la conception des relations entre éléments du modèle. L’alignement des architectures est pris comme exemple. ABSTRACT.
Model Driven Engineering (MDE) is well-known for the tasks of development process close to implementation. The objective of this study achieved for the telecommunication operator Orange is to show how the early tasks of the development process of the company can be described with MDE. This leads to a sequence of model transformations taking the system requirements analysis models as input and providing implementation models as output. Each model transformation is made of tasks achieved by hand by experts, such as model element design and of automated tasks, such as relationship between model elements design. The alignment of architectures is taken as an example. MOTS-CLÉS :
processus de développement, MDE, architecture dirigée par les modèles, tâche de développement automatisable. KEYWORDS:
development process, model engineering, model driven architecture, automate development task.
1. Introduction Dans un processus de développement, l'approche d'ingénierie des modèles (MDE : Model Driven Engineering) cible généralement l'architecture applicative détaillée, la génération de code utile à l'implémentation et aux tests. Pour l'architecture applicative détaillée, la projection de chaque composant applicatif sur une couche applicative (couche présentation, couche d'accès aux données, etc.) est détaillée à l'aide d'un environnement architectural propre à chaque couche. Les approches MDE (Frankel, 2003) ou MDA (OMG, 2010) favorisent l'intégration d'environnements architecturaux applicatifs durant un processus de développement de système (Guelfi et al., 2004). Concernant les tests, l'approche MDA permet de tester les systèmes générés à partir de transformations de modèles en validant ces transformations (Fleurey et al., 2004). L’étude sur laquelle est fondé cet article vise la généralisation de la mise en œuvre du MDE dans un processus de développement de système. Le contexte est le projet MOPCOM-I auquel participe Orange Labs. Le projet MOPCOM-I, labellisé en mars 2007 par le pôle « images et réseaux » de la région Bretagne, cible l’ingénierie dirigée par les modèles pour la spécification et la conception de système par l’explicitation des processus de développement. Dans ce cadre, un processus MDE est associé à chaque sous-processus du processus de développement préconisé chez Orange. Cette démarche de développement est de type Unified Process (Jacobson, 1999) et est contrainte par l’architecture de l’entreprise définie par Zachman (Zachman, 1987). Nous nous limiterons dans cet article aux activités d’architecture d’entreprise telles que décrites dans la démarche EA4UP (Simonin et al., 2008). Ce travail est réalisé avec l’obligation de respecter le méta-modèle du groupe Orange définissant les concepts propres au développement d’un système dans ce groupe. Le but de cet article est de montrer comment peut être réalisée l’intégration d’une démarche de transformations automatiques de modèles dans un processus très amont de la conception des systèmes d’informations habituellement manuel. Nous montrons donc (1) comment les différents sous-processus sont explicités puis intégrés dans un processus global puis (2) les bénéfices obtenus. Nous décrivons des sous-processus MDE utilisés pour chaque vue d’architecture du développement d’un système/logiciel (International Organization of Standardization, 2001) ainsi que pour la vue d’architecture du cœur de métier de l’entreprise. Les sous-processus du processus de développement visés dans ce cadre par les processus MDE sont : -
l’architecture métier qui représente les procédures mises en œuvre dans l’entreprise en conformité avec son organisation et conformes aux processus du cœur de métier de l’entreprise ; l'architecture fonctionnelle qui a pour objectif de définir les fonctions du système, et leurs répartitions entre différents composants fonctionnels, à
Décomposition du processus de développement suivant un cycle en Y
Décomposition du processus de développement ISO12207
Analyse métier
Non spécifiée
Architecture métier
Non spécifiée
Collecte des exigences
Élicitation des exigences
Analyse fonctionnelle
Analyse des exigences du système Analyse des exigences du logiciel
Architecture fonctionnelle
Conception de l’architecture du système
Analyse infrastructure
Analyse des exigences du système Analyse des exigences du logiciel
Architecture infrastructure
Conception de l’architecture du système
Architecture organique
Conception du logiciel
Architecture organique détaillée Codage
Construction du logiciel
Test
Intégration et essais du logiciel Intégration et essais du système Tableau 1. Correspondance entre la décomposition du processus de développement suivant le cycle en Y et la décomposition du processus de développement décrits dans la norme ISO / IEC 12207
-
-
-
partir des fonctionnalités proposées aux utilisateurs d'un système conformes aux exigences fonctionnelles de ce système, et de la façon la plus cohérente possible avec les fonctions décrites du système d’information (SI) ; l'architecture de l’infrastructure (ou technique) qui a pour résultat de détailler des éléments techniques (existants ou non) satisfaisant les exigences non fonctionnelles du système et ayant pu nécessiter au préalable un prototypage ou un guide de mise en œuvre suivant ces exigences, et de la façon la plus cohérente possible avec les éléments techniques préconisés dans le système informatique ; l’architecture organique qui représente la réalisation des fonctions du système par des composants organiques (ou logiciels). Ces composants organiques sont déployés sur les éléments techniques et sont, le plus possible, des éléments du système informatique existant ; L’architecture organique détaillée qui a pour objectif de détailler la structure interne de chaque composant organique, en général de manière cohérente avec un cadre spécifique à la couche organique du composant ;
-
Le codage qui a pour résultat la construction de chaque élément de la structure interne d’un composant organique.
La correspondance entre la décomposition du processus de développement préconisée chez Orange et la décomposition du processus de développement décrite dans la norme ISO / IEC 12207 est décrite dans le Tableau 1. Cet article ne concerne que les sous-processus grisés. La partie suivante présente l’enchainement des sous-processus MDE qui constituent le processus global de développement puis la partie 3 détaille un exemple d’activité d’un sous-processus MDE décomposée en tâches automatiques et manuelles. La partie 4 explique comment les tâches automatiques et les tâches manuelles se combinent. Enfin, nous concluons en présentant les gains obtenus et les perspectives de ce travail.
2. Processus de développement et MDE Pour la représentation du processus de développement, la modélisation est réalisée avec le langage xSPEM (Bendraou et al., 2007) afin de pouvoir modéliser l’exécutabilité de certaines tâches du développement. Les processus sont découpés dans cette section en sous-processus MDE, eux-mêmes découpés en activités. 2.1. Processus de développement et MDE Le sous-processus MDE, appliqué à la vue métier, complète le cycle de développement préconisé par l’ISO. Il interagit en effet comme contrainte du sousprocessus MDE d’architecture fonctionnelle. L’ajout de la vue métier est un choix des urbanistes d’Orange Labs afin de faciliter la conception de la vue fonctionnelle d’un service de télécommunication. Chaque fonction et chaque dépendance entre fonctions devront alors être alignées respectivement avec une ou plusieurs tâches de la vue métier et avec une succession de tâches dans une procédure de la vue métier. Les éléments associés à chacune des vues correspondent à une description systémique des modèles liés à un processus de développement (Erikson, 1997). L’approche systémique permet de simplifier le méta-modèle de l’entreprise définissant les concepts décrivant un développement. De ce fait, un élément est ici soit une unité, soit une relation entre unités. Par exemple, une unité fonctionnelle peut être une fonction, une donnée fonctionnelle, un composant fonctionnel. La relation entre unités serait respectivement une dépendance entre fonctions (par exemple, « créer la commande d’un produit » dépend de « lire un catalogue »), une dépendance entre données fonctionnelles telles que les relations du modèle entité – relation dans un modèle logique de données ou une dépendance entre composants fonctionnels (par exemple, le composant « Gestion de commande » dépend du composant « Gestion de catalogue »).
Le processus de développement décrit dans la Figure 1 est composé des sousprocessus, conformes au cycle de développement itératif en Y (2TUP : Two Track Unified Process) (Roques, 2004) et à l’approche MDE, suivants : -
Business MDE qui représente la conception MDE de l’architecture métier,
-
Functional MDE qui représente la conception MDE de l’architecture fonctionnelle d’un système,
-
Infrastructure MDE qui représente la conception MDE de l’architecture de l’infrastructure d’un système,
-
Organic MDE qui représente la conception MDE de l’architecture organique d’un système,
-
Detailed Organic MDE qui correspond à la conception détaillée de chaque composant organique conçu lors du sous-processus Organic MDE conformément à l’approche MDE,
-
Implementation MDE qui représente la mise en œuvre de l’approche MDE lors du codage.
Figure 1. Processus de développement découpé en sous-processus définis par le MDE
Les liens entre sous-processus sont justifiés de la manière suivante : -
Business MDE vers Functional MDE qui représente un choix d’Orange de concevoir l’architecture fonctionnelle d’un système non seulement à partir des exigences fonctionnelles spécifiées par le maître d’ouvrage, mais aussi par la connaissance des procédures métier de l’entreprise,
-
Functional MDE vers Organic MDE qui correspond à la réalisation des éléments conçus lors de l’architecture fonctionnelle par des éléments conçus lors de l’architecture organique,
-
Infrastructure MDE vers Organic MDE qui correspond au déploiement des éléments conçus lors de l’architecture organique sur les éléments conçus lors de l’architecture de l’infrastructure,
-
Organic MDE vers Detailed Organic MDE qui représente la description détaillée des éléments conçus lors de l’architecture organique suivant la couche à laquelle ils appartiennent (par exemple, les couches Présentation, Service et Accès aux données),
-
Infrastructure MDE vers Detailed Organic MDE qui représente le cadre (ou framework) suivant lequel chaque élément conçus lors de l’architecture organique est détaillé,
-
Detailed Organic MDE vers Implementation MDE qui correspond au codage des éléments conçus lors de l’architecture organique détaillée,
-
Infrastructure MDE vers Implementation MDE qui correspond à la mise en œuvre d’un environnement spécifique au codage (langage, librairies, etc.).
2.2. Processus de développement et MDA Chaque sous-processus MDE est décomposé en activités suivant l’approche d’architecture dirigée par les modèles ou MDA (Miller et al., 2003). L’originalité de l’utilisation de l’approche MDA est ici liée à l’utilisation d’un PDM modélisant la contrainte de l’urbanisation lors de la transformation d’un PIM en un PSM. Dans l’illustration de la Figure 2, le PIM est le modèle de l’analyse métier (Business Analysis), le PDM est le modèle de l’architecture métier d’entreprise préconisée par les urbanistes chez Orange (EA Business Architecture) et le PSM résultant est le modèle de l’architecture métier d’une procédure (Business Architecture). L’urbanisation est représentée dans notre approche par des modèles cibles associées à la vue métier, à la vue fonctionnelle, à la vue infrastructure et à la vue organique par un PDM. Plus précisément, dans le cas du SI des services de télécommunication urbanisés par Orange Labs, le PDM modélise les activités d’architecture d’entreprise :
-
des procédures métier cibles cohérentes avec la stratégie de l’entreprise pour la vue métier (activité Business EA), par exemple, la procédure de réception d’un message électronique ;
-
un modèle fonctionnel hiérarchique (zone, quartier, îlot, fonction) pour la vue fonctionnelle (activité Functional EA), par exemple, la zone fonctionnelle de messagerie composée d’une dizaine d’îlots fonctionnels tels que la gestion des échanges de message ou la gestion de l’édition d’un message ;
-
des préconisations techniques propres aux services de télécommunication pour la vue infrastructure (activité Infrastructure EA) telles que l’utilisation du protocole SIP pour l’IMS (Cuevas, 2006) ou le choix de technologies liées aux web services (Schulte et al., 1996).;
-
des préconisations applicatives propres aux services de télécommunication pour la vue organique (activité Organic EA) telles que l’utilisation d’un élément de la vue organique réutilisable désigné sous le terme d’enabler (Open Mobile Alliance, 2005) propre aux messageries SMS ou propre aux messageries MMS.
De plus, les transformations de modèle s’enchaînent telles qu’un PSM résultant d’une transformation de modèle devienne le PIM pour une autre transformation de modèle (cf. Figure 2.).
Légende
Figure 2. Enchaînement des transformations de modèles conçus lors des activités composant les sous-processus définis par le MDE
Par exemple, le modèle produit lors de l’activité Business Architecture qui résulte de la conception des procédures métier de l’entreprise est à la fois le PSM résultant de la transformation d’un modèle d’analyse métier contraint par le modèle de la vue métier cible de l’entreprise, mais aussi le PIM avec le modèle d’analyse fonctionnelle (Functional Analysis) de la transformation de modèle dont le résultat est le modèle produit lors de l’activité Functional Architecture.
3. Architecture d’une activité de développement L’architecture d’une activité de développement consiste à découper cette activité en tâches. Chaque tâche a la propriété d’être sous la responsabilité d’un seul rôle. Des concepts définissant un processus de développement sont alors définis comme étant produits et utilisés par ces tâches.
3.1. Activité et tâche Chaque activité est décrite dans un tableau inspiré du modèle de patron de processus de (Storrle, 2001). L’exemple donné dans le Tableau 2 pour l’activité Business Architecture du sous-processus Business MDE comporte en effet les rubriques : -
« Nom » qui représente le nom de l’activité architecturée en tâches,
-
« Classification » précisant le niveau de l’activité dans le processus de développement vu au travers du MDE,
-
« Objectif » qui spécifie l’objectif de l’activité architecturée,
-
« Motivation » qui précise un complément d’objectif de l’activité architecturée,
-
« Applicabilité » représentant les pré-conditions de l’atteinte de l’objectif et de la motivation,
-
« Activité » qui contient une description de l’activité architecturée avec le langage de modélisation de processus SPEM (Software and system Process Engineering Meta-model),
-
« Participants » répertoriant les rôles qui sont responsables de tâches de l’activité architecturée,
-
« Conséquences » représentant les post-conditions de l’atteinte de l’objectif et de la motivation,
-
« Exécution » qui précise l’exécutabilité de certaines tâches architecturant l’activité,
-
« Sous-processus MDE liés » qui indique les sous-processus MDE liés à l’activité architecturée autres que le sous-processus MDE la contenant.
Nom Activité Classification
Objectif
Motivation
Applicabilité
Activité
Business Architecture Niveau: conception de vue métier et approche MDE Phase: conception de l’architecture Sujet: développement de système Scope: conception fondée sur l’EA Conception architecturale de procédures métier avec une traçabilité entre l’analyse métier et l’architecture métier et avec une contrainte de l’architecture d’entreprise métier Conception de l’architecture de procédures métier réalisant des processus du cœur de métier de l’entreprise le plus conformément possible à l’architecture d’entreprise métier. L’architecture d’entreprise métier est conçue, ce qui signifie que les architectes d’entreprise d’Orange ont conçu des préconisations sous forme de modèle de procédures métier, d’acteurs métier et d’entité métier. Le modèle d’analyse métier est spécifié conformément au métamodèle du groupe Orange. L’activité est composée de 4 tâches : - l’alignement métier unitaire (Business Unit Alignment) des tâches d’une procédure sur les activités de processus métier conformément aux procédures et à l’organisation préconisées chez Orange, - l’alignement métier relationnel automatique (Automatic Business Relational Alignment) de la succession de tâches d’une procédure sur la succession d’activités conformément aux procédures et à l’organisation préconisées chez Orange, - la correction de l’alignement automatique par l’architecte métier (Architect Business Relational Alignment), c’est-à-dire de l’ordonnancement des tâches composant la procédure métier, - la validation de l’architecture métier (Architecture Validation) par les architectes d’entreprise métier de l’entreprise. 2 points de décision caractérisent : - la validation ou non de l’architecture par l’architecte métier (Architect validation), - la validation ou non de l’architecture par les architectes d’entreprise métier (EA validation).
Participants
Conséquences
Exécution
Sousprocessus MDE liés
L’architecte métier (Business Architect) qui conçoit les procédures métier à partir des processus décrivant le cœur de métier d’Orange. L’architecte d’entreprise métier (Business Enterprise Architect) qui vérifie la conformité des procédures métier aux préconisations d’architecture d’entreprise métier. Les procédures métier avec leurs tâches et les entités métier produites ou utilisées par ces tâches sont référencées durant la traçabilité assurée par l’activité de conception d’architecture métier. Les éléments unitaires et relationnels sont de plus le plus conforme possible à l’architecture d’entreprise métier d’Orange. Cette activité MDE est essentiellement une activité d’expert avec les tâches d’alignement métier unitaire, de correction de l’alignement automatique par l’architecte métier et de validation de l’architecture métier : - La tâche d’alignement unitaire consiste à aligner des tâches extraites le plus possible de l’architecture d’entreprise métier sur les activités composant le processus métier à architecturer. Chaque tâche créée par l’architecte métier pour cet alignement et qui n’est pas issue de l’architecture d’entreprise métier doit respecter la règle d’architecture d’entreprise eamétier_tâche-rôle. - La tâche de correction de l’alignement automatique par l’architecte métier permet à celui-ci de corriger des successions de tâches générées. automatiquement par la tâche d’alignement métier relationnel automatique. - La tâche de validation de l’architecture métier par les architectes d’entreprise est une tâche d’expert consistant à valider la description de la procédure métier et de l’enchaînement de tâches qui la caractérisent. Sous-processus de Functional MDE (étape suivante).
Tableau 2. Exemple de description d’une activité architecturée sous forme de tâches métier avec l’activité Business Architecture
Dans l’exemple de l’activité de Business Architecture, les tâches d’alignement (par exemple, Business Unit Alignment) sont sous la responsabilité de l’architecte métier alors que la tâche de validation, Architecture Validation, est sous la responsabilité de l’urbaniste métier qui vérifie la cohérence de la procédure conçue par l’architecte métier avec les procédures métier cibles. La règle d’architecture
d’entreprise ea-métier_tâche-rôle fixe pour chaque tâche d’une procédure, un seul rôle responsable de la tâche.
3.2. Activité et concept associé au développement Chaque tâche conçue à partir d’une activité du processus de développement produit ou utilise un concept associé à ce processus. Ce concept est instancié par chaque développeur, par exemple l’instance du concept de processus métier représentant le processus de commande d’un produit spécifié par l’analyste métier. Les concepts manipulés lors de l’activité Business Architecture sont décrits dans la Figure 3.
Figure 3. Description des concepts associés au développement produits et utilisés par les tâches métier de l’activité Business Architecture
4. Exécutabilité des tâches d’une activité de développement Les tâches décrites sont soit manuelles, soit automatisables. Une tâche manuelle est une tâche réservée à un expert. Une tâche exécutable est automatisable à partir de l’implémentation de règles de transformation de modèles. Cette implémentation est ici conforme à la norme QVT de l’OMG (OMG, 2007).
4.1. Tâche manuelle d’initialisation du PSM Cette tâche permet d’initialiser un modèle propre à une transformation de modèle automatisable. La tâche manuelle d’initialisation du PSM est : -
la tâche d’alignement entre unités, par exemple les unités métier (Business Unit Alignment) dans la Figure 3 telles que les tâches ou les données métier.
Une tâche d’alignement entre unités a pour responsable l’architecte de la vue étudiée, la vue métier dans notre illustration. Ce travail d’expert consiste à aligner les unités du PIM sur les unités du PDM afin de concevoir les unités du PSM. Dans notre exemple, les processus (Business process) sont alignés avec les procédures (EA Business procedure) définis par les urbanistes métier pour définir les procédures (Business procedure). La règle respectée est que chaque tâche d’une procédure est déduite d’une activité d’un processus de telle façon que chaque tâche corresponde à une tâche d’une procédure recommandée par les urbanistes métier.
4.2. Tâche exécutable d’enrichissement du PSM La tâche exécutable d’enrichissement du PSM initialisé (cf. 4.1.) est : -
la tâche d’alignement entre les relations entre unités, par exemple la tâche Business Relational Alignment pour l’activité Business Architecture de la Figure 3 avec les successions de tâches ou les dépendances entre données métier.
Une tâche d’alignement automatique entre relations entre unités a pour responsable l’architecte de la vue étudiée, même si son intervention est limitée à l’utilisation d’une transformation de modèles outillée. Ce travail automatisé consiste à aligner les relations entre unités du PIM sur les relations entre unités du PDM afin de concevoir les relations entre unités du PSM. Dans notre exemple, les successions d’activité d’un processus (Business process) sont alignées avec les liens entre tâches des procédures (EA Business procedure) définies par les urbanistes métier. Cet alignement permet de définir les successions entre tâches d’une procédure (Business procedure). La règle respectée est que chaque lien de succession entre tâche d’une
procédure est déduit d’un lien de succession entre activités d’un processus de telle façon que chaque succession de tâches soit cohérente avec une succession de tâches d’une procédure préconisée par les urbanistes métier. La caractéristique d’exécutabilité du Tableau 2 peut alors être complétée par une description en pseudo-code de la transformation de modèle supportant cette tâche exécutable de validation. Par exemple, l’automatisation de l’alignement métier relationnel est fondée sur les modèles suivants : -
PIM = modèle d’analyse métier contenant les processus métier et leurs activités,
-
PDM = modèle d’architecture entreprise métier avec l’organisation de l’entreprise et ses rôles ainsi que les procédures recommandées
-
PSM = modèle d’architecture métier
L’algorithme est le suivant : Début Pour chaque relation de succession entre 2 activités du PIM - Si 2 ensembles de tâches du PSM sont alignés unitairement avec chacune de ces activités alors - S’il existe 2 tâches du PDM correspondantes à une tâche de chacun des 2 ensembles et que ces 2 tâches se succèdent de manière cohérente avec la succession des activités alors - les 2 tâches du PSM conçues à partir des 2 tâches du PDM sont liées - Finsi - Finsi Finpour Pour chaque activité du PIM - Si 2 tâches sont alignées unitairement avec l’activité alors - S’il existe 2 tâches du PDM correspondantes à chacune des tâches et que ces 2 tâches sont liées alors - les 2 tâches du PSM conçues à partir des 2 tâches du PDM sont liées - Finsi - Finsi Finpour Fin
4.3. Tâche manuelle de correction du PSM La tâche manuelle de correction du PSM réservée à un expert est :
-
la tâche de correction d’un modèle généré par une tâche automatique définie dans 4.2. (par exemple, Architect Business Relational Alignment), c’est-à-dire la correction des relations entre unités générées automatiquement par la tâche (Automatic Business Relational Alignment).
La tâche de correction d’un modèle généré automatiquement est aussi sous la responsabilité de l’architecte de la vue étudiée. L’objectif de cette tâche est de permettre à l’architecte de corriger le modèle conçu de façon automatique afin de le rendre cohérent avec les exigences fonctionnelles et / ou les exigences non fonctionnelles du système. Les relations entre unités cibles de la génération automatique sont aussi les cibles de cette tâche de correction du PSM.
4.4. Tâche exécutable de validation du PSM La tâche exécutable de validation du PSM corrigé (cf. §4.3) est : -
la tâche de validation désignée dans notre illustration métier par Architecture Validation qui vérifie le respect des règles d’urbanisme spécifiées par les urbanistes métier. Un exemple de règle métier est qu’une tâche doit être sous la responsabilité d’un rôle métier et d’un seul.
Une tâche de validation consiste uniquement à vérifier que les règles d’urbanisme sont vérifiées dans le modèle des unités résultantes de l’alignement manuel et dans le modèle corrigé par l’architecte (cf. 4.2.). La caractéristique d’exécutabilité du Tableau 2 peut alors être complétée par une description en pseudo-code de la transformation de modèle supportant cette tâche exécutable. Dans notre exemple, l’automatisation de la validation de l’architecture métier est fondée sur les modèles suivants : -
PIM = modèle d’architecture métier,
-
PDM = modèle de règles ciblant les concepts de la vue métier du métamodèle,
PSM = modèle d’architecture métier annoté avec les anomalies rencontrées lors du contrôle du respect des règles métier.
5. Conclusion et Perspectives Nous avons présenté un processus de développement comme un enchaînement de transformations de modèles manuelles (initialisation du PSM (cf. 4.1) et correction du PSM (cf. 4.3)) ou automatiques (enrichissement du PSM (cf. 4.2) et validation du PSM (cf. 4.4)). De nombreux modèles sont utilisés pour décrire
l’analyses des différentes vues (modèles de Business Analysis, de Functional Analysis, d’Infrastructure Analysis) ou de contraintes issues de l’EA assimilées ici à un ensemble de PDM conçus par les urbanistes d’Orange pour le processus de développement (les modèles de Business EA, de Functional EA, d’Infrastructure EA, d’Organic EA.) Les différentes transformations manuelles ou automatiques produisent des PSM qui mènent à l’activité de codage (modèles de Business Architecture, de Functional Architecture, d’Infrastructure Architecture, d’Organic Architecture, de Detailed Organic Architecture.) Ce travail a, tout d’abord, permis de valider l’utilisation du MDE dans des processus très amont du cycle de vie des systèmes. Nous constatons que la réflexion sur les modèles et les processus est un facteur d’amélioration des pratiques, d’autant plus lorsque l’outillage qui accompagne les experts automatise une part de leur travail, rend explicite le partage d’information aux travers des méta-modèles et met en évidence, sans les interdire, les écarts par rapport aux règles d’urbanismes en cours. Cette évaluation qualitative mérite d’être confirmée et appuyée par des expériences complémentaires et une extension de l’application de cette démarche à d’autres étapes du cycle de vie. La démarche décrite suppose néanmoins un niveau qualitatif homogène dans l'ensemble des modèles utilisés (modèles d'urbanisme et d'architecture, principalement). Or, industriellement parlant, ce n'est souvent pas le cas et cela limite le potentiel de la démarche. C'est d'ailleurs la raison principale pour laquelle nous avons commencé par outiller la conception de l’architecture de la vue fonctionnelle (Ahuja, 2010) où l’ensemble des modèles est le plus homogène. Notre choix s’est porté sur SmartQVT (SmartQVT, 2010) pour nos implémentations de transformation de modèles. Le choix complémentaire d’un outillage du processus de développement avec xSPEM, a permis, de plus, d’intégrer l’exécutabilité d’une tâche dans le déroulement d’une activité, et donc d’un sous-processus du processus de développement. Une perspective à court terme est la généralisation de l’outillage des tâches automatisables décrites dans les sous-processus du processus de développement. Enfin, l’approche MDE pour les sous-processus d’essai et d’intégration est une perspective à moyens termes. Un essai pourrait en effet être considéré comme la transformation d’un modèle décrivant le code d’un système en une liste d’erreurs. Cette transformation serait contrainte par l’analyse fonctionnelle d’un système pour les tests fonctionnels et par l’analyse de l’infrastructure d’un système pour les tests de performance et de robustesse. L’intégration pourrait aussi être considérée comme l’activité inverse de l’architecture et donc être contrainte par cette activité.
6. Bibliographie Ahuja A., Simonin J., Nédélec R., « MDA Tool for Telecom Service Functional Design », 4th European Conference on Software Architecture (ECSA), Copenhagen, Denmark, 2010.
Bendraou R., Combemale B., Crégut X., and Gervais. M.-P., « Definition of an eXecutable SPEM2.0 », In 14th APSEC, Japan, IEEE Computer Society, 2007. Cuevas A., Moreno J.I., Vidales P., Einsiedler H., « The IMS Service Platform: A Solution for Next-Generation Network Operators to Be More Than Bit Pipes », IEEE Communications Magazine, vol. 44, no. 8, 2006, pp. 75-81. EriksonD.M., « A Principal Exposition of Jean-Louis Le Moigne’s Systemic Theory. Cybernetics and Human Knowing », vol. 4, no. 2-3, 1997. Fleurey F., Steel J., Baudry B., « Validation in ModelèDriven Engineering: Testing Model Transformations », Proceedings of the SIVOES – Modeva workshop, Rennes, 2004. Frankel D.S., « Model Driven Architecture – Applying MDA to Enterprise Computing », Wiley Publishing Inc, 2003. Guelfi N., Perrouin G., « Using Model Transformation and Architectural Frameworks to Support the Software Development Process: the FIDJI Approach », Midwest Software Engineering Conference, Chicago, USA, 2004, p. 13-22. International Organization of Standardization, « Software Life Cycle Processes », ISO / IEC 12207, 2001. Jacobson I., Booch G., Rumbaugh J., « The Unified Software Development Process ». Addison-Wesley, 1999. Miller J., Mukerji J., « MDA Guide Version 1.0.1 », http://www.omg.org/docs/omg/03-0601.pdf, 2003. OMG, « Query/View/Transformation (QVT) », http://www.omg.org/docs/ptc/07-07-07.pdf, 2007. OMG, « Model Driven Architecture (MDA) », http://www.omg.org/mda/, 2010. Open Mobile Alliance, « OMA Service Environment », OMA-Service-Environment-V1_0_220050803-A, 2005. Roques P., Vallée F., « UML2 en action – De l'analyse des besoins à la conception J2EE », Eyrolles, 2004. Schulte R.W., Natis Y.V., « Service Oriented Architectures – Part 1 », Gartner, 1996. Simonin J., Alizon F., Deschrevel J.-P., Le Traon Y., Jézéquel J.-M., Nicolas B., « EA4UP: an Enterprise Architecture-Assisted Telecom Service Development Method », Proceedings of the 12th IEEE International EDOC Conference, München, Germany, 2008. SmartQVT, « SmartQVT », http://smartqvt.elibel.tm.fr/, 2010. Storrle H., « Describing Process Patterns with UML », Software Process Technology, vol. 2077, 2001, p. 173-181. Zachman J.A., « A Framework for Information Systems Architecture », IBM Systems Journal 26, n° 3, 1987, p. 276-292.
