L'approche par les Modèles

Présentation au sujet: "L'approche par les Modèles"— Transcription de la présentation:

1 L'approche par les Modèles
Alain DELFIN Consultant Softeam Stéphane CAILLETTE Ingénieur Softeam Disponible sur : - - Emmanuel PESENTI Consultant Softeam « Un pont entre les îlots de savoir »

2 Plan Qu’est-ce Qu’un modèle ? Pourquoi UML ? Genèse des modèles ?
MDA : Motivations Typologie des modèles de référence Principes Un cas concret 15' : Démonstration Objecteering MDAC Swing 20' : ECHANGES : Annexe : Différentes sources d’information

3 Qu’est-ce qu’un modèle ?
Un abstraction ou une simplification de la réalité, pour bien/mieux comprendre le système à développer. Un modèle ne représente pas toute la réalité, mais au plus /mieux l’aspect économique que l’on souhaite exploiter. Inutile de commenter d’avantage. Les Softeamiens parlent aux Softeamiens Une vue, un diagramme, un plan ne sont pas des modèles mais des représentations du modèle. Il s’agit d’une projection d’un hyper espace (le modèle) afin de simplifier ce que l’on veut présenter.

4 Présentation : Pourquoi UML
Langage formel Langage de langage Enrichissable Simple, Structuré Complet Graphique Du contemplatif au productif Les modèles sont souvent utilisés pour réfléchir, définir la structure gros grain, ou documenter : Ils sont alors contemplatifs et ne permettent aucun gain significatif de productivité. L’approche MDA3 leur donne un caractère « Productif » en permettant la génération automatique de code, et de déploiement, … Par nature, un modèle UML ne peut pas être productif, en effet la modélisation conceptuelle telle que nous souhaitons la pratiquer doit permettre de rester indépendant des langages, et/ou des plates formes de production. Il faut donc spécialiser UML pour qu’il devienne productif : Il faut le profiler. Les profils ne rendent les modèles productifs qui s’ils servent à générer… Il faut donc associer aux profils des règles de génération. Les profils standards proposent quasiment tous, des règles de génération. En UML, un profil est une collection de stéréotypes, de contraintes et de « tagged values » qui permet, de définir précisément de nouveaux concepts à manipuler à partir des concepts de base du langage. La création d’un profil est de l’ordre de la méta modélisation, dans la mesure ou elle enrichit le panel des représentations valides pour un modèle. Cette discipline de création et de maintenance est donc à dissocier de la discipline de modélisation des données concrètes du système d’information à modéliser. Nous verrons plus loin son imbrication dans le processus de productions des modèles. « Extrait Unified Modeling Language de Xavier Blanc » Exemple de stéréotype : Vous souhaitez modéliser le concept Contrat, et après modélisation et validation auprès des intervenants MOE et MOA du projet, vous disposez enfin d’une abstraction correcte qui met tout le monde d’accord. Vient donc alors la question : A quoi sert mon modèle, et qu’est-ce que j’en fais ? Déjà je souhaite préciser qu’il s’agit d’un objet métier, dont l’objectif est de formaliser ce qu’est un contrat d’un point de vue purement conceptuel. Prima-IBCS par exemple précise formellement cela à l’aide du stéréotype <<IBCS ModelElement>>. Ce stéréotype prima hérite du stéréotype MagicDraw <<InvisibleStereotype>> qui lui-même hérite de la méta class UML Elément. Quasiment tous les objets manipulé par prima sont des <<IBCS ModelElement>>. <<Meta class>> est aussi un stéréotype UML, représentant tout objet de l’espace de nommage UML. Ainsi nous pouvons dire qu’un <<IBCS ModelElement>>, est un stéréotype qui peut s’appliquer à tout objet Element ou héritant de Element (Package, classe, association, Attribut, Case Component, Part,… sont des éléments). Concrètement prima à souhaiter formaliser / spécifier / enrichir la représentation possible d’un élément, par un marqueur particulier permettant d’isoler tout élément stéréotypés <<IBCS Model Element>> afin d’y opérer un ou des traitements particuliers, et/ou les isoler d’autres objets stéréotypés. Précisons qu’un même concept peut être porteur de plusieurs stéréotypes, et qu’il est important de préciser dans quels processus de production il est utilisé. Nous attacherons une vigilance particulière à l’objectif nominal d’un stéréotype afin que son usage s’opère en toute indépendance, vis-à-vis d’autres stéréotypes. « Extrait Mission CNP 03/2009: Convention de modélisation des données de E. PESENTI » UML n’est pas une méthode, mais la boite à outil des méthodes Objet (UP, PRAXEME)

5 Introduction : la genèse des modèles
5 Projet Laissez nous concevoir Code Documentations Contrôles Glossaire Dérivations Praxeme Dictionnaire Suivi Test Corba EJB Métriques Spécs * Modèle Code Modèle Le code est le modèle 2 Code Modèle Le code et le modèle coexistent 3 4 Code Modèle le modèle est le code Test Doc Code Qu’est ce qu’un modèle ? 1 1) Aucun niveau d’abstraction Aucune lecture Aucun partage Uniquement du développement 2) On gagne en lecture mais reste une vue de l’implémentation On habille du code avec des modèles Un modèle d’implémentation 3) Différentes préoccupations coexistent, pas seulement celles des développeurs Analyse, conception et code Génération à partir des modèles Saisies additionnelles dans les IDEs 4) Le code est un artéfact final privilégié parmi d’autres (doc, tests, …) Tout se déduit du modèle 5) Le saint graal Pour une information Complète ; Cohérente ; Concrète ; Up to date ; Partagée ; Validable ; Guidé par une méthode Et éventuellement de la génération de code, car le SI, ce n’est pas seulement le système informatique…. Système d’Information Système informatique Les applications

6 MDA : Comment Modéliser
Avec de la matière première Des compétences De la technologie De la motivation Une organisation Pilotage en réseau Rationalisation des moyens Structures de production Indicateurs de Performance Du Formalisme et des Règles Des ateliers de transformations Des objectifs Ambitieux Fédérateurs Réalisables Normés dans le temps Et de la méthode … Standardiser la production de modèles conceptuels Favoriser la réutilisation des modèles Fluidifier les échanges d’information entre domaine Coordonner les contributions d’un réseau d’architecte orienté projet. Organiser la communication et l’irrigation de modèles au sein des projets. Produire des métriques pour Mesurer l’activité de l’équipe. Mesurer la valeur ajoutée de l’équipe. Faciliter la communication à l’aide d’éléments factuel. Exposer les résultats dans un format ou un point de vue attendu (contrat de service) Il faut choisir aussi un format d'échange automatique. On choisit naturellement le dialecte XMI (C'est un XML) permettant une expression textuelle formelle du méta-modèle d'UML, et des concepts métiers spécifiques au présent projet. XMI est à UML, ce que BPMN est à BPEL : Un format XML d'échange auto documenté par son modèle, sous forme de balise, et formalisé par son Métamodèle : Le schéma XSD, lui même un document XML, auto documenté par son modèle : Le schéma de schéma. On se situe alors au niveau du meta meta-modèle, par rapport à notre besoin d'origine, décrit en XMI. Énumérons pèle-mêle, les axes de contributions suivant : - Un axe Chef de Projet, pour la mise en place de l'organisation, la gestion du planning, des indicateurs de performance... - Un axe analyse métier - Un axe Développeur ("Model Centric" et non plus "Code Centric") - Un axe DBA, pour les problématiques de persistances, et d'optimisation des accès aux données. - Un axe de savoir-faire Recette & Homologation - et pourquoi pas un axe Ressources Humaines... MDA permet une gestion multi-axiale d'un projet aussi confortablement que possible

7 Focus : Les indicateurs de performances
Des hommes une équipe Focus : Les indicateurs de performances On a atteint la cible avec succès, mais on aurait pu l’atteindre plus vite, à l’aide d’information de pilotage au fil de l’eau Définition Objectif Limite Liste des mesures Liste des KPI Sur l’activité globale, je suis bon Je le sais et je le prouve … Marginalement, sur l’activité OMEGA, je peux faire mieux. D’ailleurs, j’ai identifié des leviers d’amélioration… Un indicateur de performance clé (KPI) - est une mesure quantifiable des performances d'une activité économique. - contiennent des métadonnées qui fournissent des informations sur la manière de les restituer et de les interpréter. Nom, Description, Description de l’objectif à mesurer, Ensemble de définition (au sens mathématique), Les Décisions/Actions à entreprendre dans le cas des mesures critiques. - Nous souhaitons utiliser des KPI, regroupés en tableau de bord, pour obtenir une synthèse historique rapide et précise de l'activité de modélisation. Ces métriques ont un triple objectif : - Aider les architectes à suivre leurs objectifs de couverture et de qualité. - Mesurer l’activité globale de l’équipe et de sa valeur ajoutée - Faciliter la communication ascendante à l’aide d’éléments factuel. Les limites des PKI Pour ADD un KPI - est un ensemble de calculs associés à un groupe de mesures pour évaluer les performances de la modélisation.  identifier les groupes de mesures, puis déduire leur KPI Liste des mesures pour ADD - M01 : Le nombre de terme dans le glossaire par bloc fonctionnel. - M02 : Le nombre de lien de tracabilité entre un terme sémantique et un concept métier. - M03 : Le nombre de diagramme par bloc fonctionnel. - M04 : - M04 : Le nombre moyen des consultations du glossaire par jour (mois par mois) par rôle (ARCH;ETUD;PROD;MOA;AUTR). - M05 : Le nombre de bloc total couvrant le SI (Cartographie). - M06 : Le nombre de bloc couvert par la modélisation (Cartographie). - M08 : Le nombre d’artéfacts intermédiaires générés ou dérivés. - M07 : Le nombre de liens attribués au X premiers concepts métiers clés de la CNP. - M08 : Le nombre de flux dans lequel un concepts métiers clés de la CNP parmi les X, est présent. - M09 : - M10 : - M11 : - M12 : Liste des PKI pour ADD - Couverture, documentation, Normalisation des schémas, non redondance, structuration des modèles … - Indices de communication transversale - Indice de suivi de projet - Indice de satisfaction des projet vis-à-vis de FIAP2/ADD.

8 MDA : Motivations Faire évoluer les systèmes de façon flexible
Réutiliser les travaux d’architecture, de codage, …les bonnes pratiques, les standards Les modèles sont plus pérennes que le code Les modèles permettent l’échange à tous les niveaux ce que le seul code ne permet pas Le travail en équipe est plus efficace que le travail d’un ensemble d’acteurs isolés Minimiser l’effort de conception aval en modélisant en amont l’ensemble des exigences de solutions métiers. Assurer la traçabilité des exigences métiers Assurer l’intégrité et la cohérence entre les phases projet Différents axes De tout temps, les projets les plus complexes ont requis une quantité importante d'information, apportées par des personnes différentes, ayant des compétences différentes, sur des phases et des moments différents. Aujourd'hui le management moderne sait que pour être efficace, il faut pouvoir gérer conjointement toutes ces compétences. Le pilotage de Projet de type MDE est là pour organiser l'approche multi-axiale, des compétences, de façon fluide, en favorisant au maximum les formalismes de chacun. Les uns feront de la spécification de contrainte en OCL, d'autres établiront  le schéma d'un processus en BPML, certains préféreront utiliser UML, d'autres coderont des spécifications en java. Enfin les uns et les autres s'attacheront à éditer des notes en langage humain, avec l'éditeur de leurs choix pourvu qu'elles soient rattachées à des concepts formels préalablement modélisés, et eux même multi- dimensionnellement documentés. Au final on obtient un creuset d'informations d'horizon bien différentes, toutes mues au service d'un même projet d’entreprise, formalisées dans un format standard unique: Celui du projet, compréhensible et modifiable, par tous. Le projet à son cycle de vie, et avance par itérations et générations successives. A tout moment l'état d'avancement peut avancer ou reculer en fonction du degré de maturité du projet et de la compréhension qu'en ont chacun des contributeurs. Pour cela, il faut aussi choisir un langage de communication humain (Le Français et/ou l'Anglais).

9 Présentation : Typologie de Modèle
Plusieurs acteurs  plusieurs points de vues  plusieurs modèles CIM (Computational Independent Model) Indépendant de tout système informatique C’est le modèle métier ou le modèle Pérenne dans le temps PIM (Plaform Independent Model) Indépendant de de la plate-forme technique. Modèle informatique qui représente une vue partielle d’un CIM Représente la logique fonctionnelle du métier Il décrit le système, à l’aide des classes et de OCL PSM (Platform Specific Model) Dépendant de la plate-forme technique Sert de base à la génération de code Est un module de transformation ou de dérivation Se nomme MDAC en Objecteering MDA : CIM, PIM, PSM Le CIM (Computational Independent Model) : Selon OMG, le CIM est indépendant de tout système informatique. C’est le modèle métier ou le modèle du domaine d’application. Le CIM permet la vision du système dans l’environnement où il opèrera, mais sans rentrer dans le détail de la structure du système, ni de son implémentation. Il aide à représenter ce que le système devra exactement faire. Il est utile, non seulement comme aide pour comprendre un problème, mais également comme source de vocabulaire partagé avec d'autres modèles. L’indépendance technique de ce modèle lui permet de garder tout son intérêt au cours du temps et il est modifié uniquement si les connaissances ou les besoins métier changent. Le savoir faire est recentré sur la spécification CIM au lieu de la technologie d’implémentation. Dans les constructions des PIM (Platform Independent Model) et des PSM (Platform Specifique Model), il est possible de suivre les exigences modélisées du CIM qui décrivent la situation dans lequel le système est utilisé, et réciproquement. Le PIM (Plaform Independent Model) : Selon OMG, le PIM est indépendant de toute plate-forme technique (EJB, CORBA, .NET,…) et ne contient pas d’informations sur les technologies qui seront utilisées pour déployer l’application. C’est un modèle informatique qui représente une vue partielle d’un CIM. Le PIM représente la logique métier spécifique au système ou le modèle de conception. Il représente le fonctionnement des entités et des services. Il doit être pérenne et durer au cours du temps. Il décrit le système, mais ne montre pas les détails de son utilisation sur la plate-forme. A ce niveau, le formalisme utilisé pour exprimer un PIM est un diagramme de classes en UML qui peut-être couplé avec un langage de contrainte comme OCL (Object Constraint Language). Il existe plusieurs niveaux de PIM. Le PIM peut contenir des informations sur la persistance, les transactions, la sécurité,… Ces concepts permettent de transformer plus précisément le modèle PIM vers le modèle PSM. Le PSM (Platform Specific Model) : Selon OMG, le PSM est dépendant de la plate-forme technique spécifiée par l’architecte. Le PSM sert essentiellement de base à la génération de code exécutable vers la ou les plates-formes techniques. Le PSM décrit comment le système utilisera cette ou ces plates-formes. Il existe plusieurs niveaux de PSM. Le premier, issu de la transformation d’un PIM, se représente par un schéma UML spécifique à une plateforme. Les autres PSM sont obtenus par transformations successives jusqu’à l’obtention du code dans un langage spécifique (Java, C++, C#, etc.) Un PSM d’implémentation contiendra par exemple des informations comme le code du programme, les types pour l’implémentation, les programmes liés, les descripteurs de déploiement. Le trois types de modèle ci-dessus sont proposés par OMG. Ils existent seulement comme une source de référence. Pour modéliser un système, on utilise des outils de modélisation comme : Objecteering, ArgoUML, Magic Draw,… En réalité, on commence le processus MDA par modéliser un modèle PIM. Puis on raffine le PIM pour obtenir un PSM. Enfin, on génère le code source à partir de PSM.

10 MDA : les principes Comment passer d’un PIM à un PSM
La transformation de modèle Formaliser les règles de transformation Formaliser le contenu des modèles  Méta Modèle Définir des annotations pour capter les spécificités d’une technologie : les tagged values, les stéréotypes Réunir les annotations compatibles entre elles  les profils UML de l’OMG Persistence, J2EE, … Ajouter les règles de transformation  spécifique aux outils : les MDAC d’Objecteering Principe MDA Le principe de base de MDA est de pouvoir élaborer des modèles de conception logicielle, par transformations, dérivations enrichissements, et générations successives, dans le sens d'une technicité et d'un formalisme croissant. Ainsi pour décrire son métier, ses processus, et ses données associées, il ne serait pas nécessaire dans l'absolue, de connaître un formalisme technique particulier. L'homme de métier devra seulement s'aligner sur un formalisme suffisant pour exprimer clairement les contraintes et nuances de son métier. L'élaboration d'un diagramme des concepts saillants et/ou de cas d'utilisations en UML, ou d'un diagramme de description d'un processus en BPMN ou encore l'approche MAP, doit permettre de faciliter la tache de validation des besoins par la MOA et l'AMOA de façon quasi indépendante de la MOE, et aussi formellement que possible, sans la moindre pollution liée à la technicité de telle ou telle plate- forme de production cible. Proche des considérations et des contraintes métier d'une MOA  le PIM (Platform Independent Model) se résume à l'élaboration d'un modèle des concepts saillants de l'activité métier. Le vocabulaire précis y est fixé, et les règles de gestion de haut niveau y sont mentionnées. La seconde étape est l'enrichissement technique des PIM, afin d'obtenir par génération le niveau PSM (Platform Specific Model, PSM). C'est dans ce modèle que l'on va créer de l'adhérence avec tel ou tel langage de développement. Les techniques employées sont donc principalement: - De l'enrichissement spécifique des PIM par paramétrage  de la cible technique. - De la transformation de modèles pour importer / exporter vers une tiers partie. - Puis la dernière étape est de générer tout ou partie du code de l'application, en présence de tous les modèles intermédiaires précédemment conçus. De cette démarche, naît la notion de données projets intégrées de bout en bout, source d'économie en terme de documentation, par l'élimination naturelle de la redondance polluante d’informations, et par la réutilisation de toute brique informative, d'une étape projet à une autre, d'un profil de population à un autre. Comprendre la démarche Pour être efficace, la démarche MDA doit être appréhendée au plus tôt par chacun des membres de l'équipe projet. Dès la note de cadrage d'un projet, à réception de la lettre de nomination du chef de projet souhaitant appliquer cette démarche dans son équipe, MDA doit/peut entrer en action. MDA est avant tout une démarche, un état d'esprit et une boite à outil, au service d'une méthodologie, d'une gestion de livrable, d'une conduite de projet... Par exemple au moment ou j'écris ces quelques lignes, j'ai moi même une démarche MDE puisque j'utilise un outil permettant d'organiser mes idées, mon raisonnement, ma démarche, sans avoir à me préoccuper du format final dans lequel vous lirez ces mêmes lignes. Vous les lirez probablement au format WORD, PPT, PDF... que je choisirai le moment venu. Le demandeur de mes travaux, à lui-même sans forcement le savoir une démarche MDE, puisqu'il ne m'impose pas d'autres contraintes que celle du résultat, d'un livrable, dans un format qu'il sait lire. Son intérêt est d'avoir le meilleur résultat possible. Pour cela il favorise mon confort et l'expression de mes idées. On comprend bien dès lors que tous les acteurs d'un projet qui apportent une valeur ajoutée tangible, sur leur axe d'expertise métier, sont concernés par le mouvement. MDE/A va leur permettre a chacun de :      - Contribuer au projet en livrant des informations pertinentes au format de son choix. Puiser dans le référentiel projet, les informations administrées et régulées, traduites le cas échéant, dans son format favori, pour permettre de construire itérativement la dimension sur laquelle on est mandaté.

11 MDE : Model Driven Engeniering
Industrialisation de la transformation de modèle Avantages Changer de profiles pour changer de techno Garder l’indépendance métier/techno Ce que propose l’approche MDE MDE propose simplement de mécaniser le processus que les ingénieurs expérimentés suivent à la main. L'intérêt pour MDE a été fortement amplifié par l’initiative MDA que l’OMG (Object Modeling Group) a rendu publique, et qui peut être considéré comme une spécialisation de MDE dans la gestion des dépendances d'un logiciel à une plateforme d'exécution. MDE est une forme d'ingénierie générative, qui se singularise par le fait que tout ou partie d'une application informatique est générée à partir de modèles, comme la programmation générative, la programmation orientée aspects, les usines à logiciel (Software Factories) où encore le MIC (Model Integrated Computing). Pour cela il faut bien sûr que, les modèles et les processus de tissage de la conception soient suffisamment précis et formels, pour être interprétés ou transformés par des machines. Le processus de conception peut alors être vu comme un ensemble de transformations de modèles partiellement ordonné, chaque transformation prenant des modèles en entrée et produisant des modèles en sortie, jusqu'à obtention d'artéfacts exécutables. Ainsi, quand on doit dériver un nouveau produit, qu'il soit une simple évolution d'un produit existant ou une nouvelle variante, on peut se contenter de « rejouer » automatiquement la plus grande partie du processus de conception, en changeant simplement quelques détails ici et là. Ce qu’est MDE Dans le contexte MDE, la notion de transformation de modèle joue un rôle fondamental ; aussi de nombreux outils, tant commerciaux que dans le monde de l'open source sont aujourd'hui disponibles pour faire la transformation de modèles. On peut grossièrement distinguer quatre catégories d'outils : Les outils de transformation génériques de modèles. Les facilitateurs de type scripts intégrés  à l'IDE. Les outils de transformation intégrables à l'IDE. Les outils de méta-modélisation. Avenir de MDE Même s'il existe une longue expérience de l'utilisation de l'ingénierie des modèles dans certains domaines comme les télécoms, sa généralisation à l'ensemble de l'industrie n'en est qu'à ses débuts. Solution d'avenir pour une gestion du processus de génie logiciel contrôlé, elle requiert, en contrepartie, un effort d'abstraction plus important de la part des développeurs mais aussi de toute personne intégrant le projet. Elle permet de conserver/capitaliser le savoir faire de conception proche des centres de décision, grâce aux économies d'échelle dues à l'automatisation.

12 MDE : Model Driven Engeniering
Le processus en Y Le processus en arrête de poisson L’application à PRAXEME Analyse Modèles Sémantique + pragmatique Modèles Organisationnel + logique De la méthode, Il faut de la méthode En s'appuyant sur les préceptes méthodologiques (UP / Praxeme, par exemple), il est intéressant de comprendre qu'à la croisée des phases et des discipline, s'enracinent des portions de processus de fabrication dont le résultat tangible peut être obtenu par MDA. Chacune des disciplines classiques (Expression des besoins, Spécifications, implémentation, mise en oeuvre, Test, déploiement, Gestion de la configuration, Direction de projet...), constituent autant d'axes de travail, occupés par un ou plusieurs acteurs. Ces axes ont leurs intérêts et leur légitimité, dans la méthode. L'approche MDA dans cet exemple va faciliter le travail collaboratif des différentes disciplines, en organisant un référentiel projet universel, une sorte de creuset concentrant tous les savoir-faires des contributeurs dans une organisation en étoile, un peu à l'image d'un concentrateur solaire, captant les rayons lumineux des 4 coins cardinaux. Tout naturellement, et parce qu'elle est la boite à outils privilégiée des méthodes agiles, on utilisera UML, pour modéliser, maintenir et standardiser, dans un langage commun, les différents artéfacts, et organiser leurs livraisons documentées. La langue humaine (française, anglaise) doit également faire l'objet d'un choix afin de décrire au mieux les artéfacts successivement formalisés. Traditionnellement, est choisie la langue maternelle de la majorité des contributeurs, et on choisit l'anglais pour l'expression du vocabulaire technique. Les notes et autres documents humain et informels, doivent être rattachés à l'objet métier formalisé dans le référentiel partagé. Sa masse devrait être limitée au minimum, selon une métrique 1/3 2/3. Trop souvent les projets sont formalisés en phases amont à hauteur d'1/10 et les 9/10 sont des informations humaines, interprétables, tronquées, incomplètes et parfois même, sujettes à caution. Quand on décrit un concept en langage humain, les plus bavards d'entre nous, se laisserons bon gré mal gré, déborder par des considérations passionnées (C'est le cas des quelques lignes ci dessus). Ce risque de bavardage en pilotage par les modèles n'existe plus. Le nécessaire et suffisant devient la règle. Le formalisme supprime toute forme d'interprétation possible. En revanche il est admis par le corps professoral, que la bonne compréhension des messages humains, passe par la multiplication des définitions qu'un enseignant serait capable d'en faire. La machine, contrairement à nous n'a besoin que d'une et une seule définition mais formelle. Ce pose alors en aval, la problématique de validation...  Le formalisme au plus tôt est le facteur de réussite de la démarche MDA. Mapping objet relationnel +MPD Framework + EJB Solveur de contraintes implémentation

13 Praxeme Scoping PRAXEME in a nutshell
Praxeme is an open source enterprise method that intends to bring together the various disciplines for analysing and transforming the enterprise and its systems. Launched in year 2004, the initiative for a public method is backed by many companies and organizations, such as SAGEM, SMABTP, the French Army and the French National Family Funding Office... First of all, Praxeme provides a strong methodological framework, the Enterprise System Topology. This framework identifies eight aspects which enable a comprehensive description of the enterprise, from its strategy toward its transformation. Modelers, enterprise architects, organizers, software designers and architects will find in Praxeme a set of principles and methods, specially modeling techniques. Each aspect deals with a particular "view" of the enterprise or its information system. Praxeme provides us with detailed guidelines for UML modeling and MDA (see figure below). The semantic aspect includes business objects, lifecycle of business objects, business rules, regulation... the business knowledge, regardless to organizational or technical choices. The pragmatic aspect deals with organizational choices, roles, business processes, work habits... Its representation is made of uses cases, processes, and also models of organizational objects. The Praxeme methodology strictly applies the principle known as "separation of concerns". These two aspects are enterprise business oriented, they do not integrate IS architecture such as SOA. The logical aspect shelters SOA style. It is the place for a strong logical architecture through components and services that are directly derived from semantic and pragmatic models. Praxeme proposed methods for SOA comply to MDA (Model Driven Architecture) standard. The software aspect derives from logical models and adds a technical UML profile to target the IT infrastructure, in particular programming languages (Java, C#, COBOL…) and XML. Components can be executed through a framework that is defined by a complete open source specification: the Virtual Engine for Praxeme (VEP). Several implementations of the VEP are possible: .NET, Java (in-house development or via a framework such as Spring), Cobol MVS, etc. To manage and drive projects of Information System overhaul we need a global enterprise method that provides us with the detailed guidelines for each aspect of the information system: semantic, pragmatic, SOA, software, VEP… In the field of methodology, we distinguish three dimensions or chapters: - Product: the "What" the object we want to build or change. (enterprise, organization, IT system, software component, people, values…). - Process: the "How" at a collective level (how should we work together?). - Procedures and methods: the "How" at an individual level (how should I produce what it is required? How to draw a good model? How to design an appropriate solution?). Compared to TOGAF and other Enterprise Architecture repositories, Praxeme offers a theory of architecture and complementary set practices. It particularly insists on the modeling techniques. As an enterprise methodology, Praxeme aims at building a formal complete Enterprise-Architecture with the same rigor as that used to manufacture software. Praxeme teaches us how to find the right level of granularity of SOA services through successive transformations, from upstream aspects to the downstream others. Praxeme is a proven method that brings to us these guidelines. Praxeme is an "open method" that is published under the "creative commons licence". The quality of a method depends on its large scale adoption. Therefore, the openness property is a key point to success. The Praxeme Institute is a not-for-profit association whose goal is to develop and promote the open source method. Emmanuel PESENTI Lettre à Massimo (Gartner) validée par D. VAUQUIER

14 Pourquoi ça pourrait marcher mieux ?
Réversibilité d’un PSM vers un PIM Comment faire évoluer un système par ajout et modification des PIMs sans être pollué par les contingences métiers La ré-application « intelligente » des transformations pour ne pas écraser ce qui a été ajouté après la transformation.

15 Un cas concret Le projet Règlements

16 Modèle sémantique : exemple
Scoping

17 Exemple : Module documentaire Le profil sémantique (scope manager)
Scoping Profil Sémantique Les stéréotypes du profil sémantique offre une grande souplesse de documentation des concepts manipulés dans la modélisation. Qu'ils s'agissent d'éléments de modélisation technique ou conceptuel, chacun peut/doit avoir une définition dans un glossaire. Les règles associées sont des règles de dérivation documentaire. L’objectif est de percevoir simplement toute information informelle permettant de comprendre un concept (Définition, Description, hyperlien vers d’autres termes, …) L'usage que nous avons se limite pour l'instant aux seuls concepts métiers, éligibles à la modélisation standard CNP. Le stéréotype <<Term>>: Un terme est une classe particulière permettant de définir un concept. Historiquement en UML, l’élément Documentation est utilisé pour pouvoir faire cela. De plus cet élément Documentation est bien sur lui-même stéréotypable. Traditionnellement les stéréotype d’une Documentation peuvent être : <<résumé>>, <<définition>>, <<point important>>, ou encore, <<A revoir>>, <<Déprécié>>… En revanche, ces éléments de documentation sont directement rattacher à l’objet qualifier[2]. A des fins organisationnelles, il est plus judicieux d’isoler les termes dans un package (stéréotypé <<IBCS Domain>>) afin de permettre à certains acteurs de les maintenir indépendamment des autres domaines du modèle. De plus cette approche permet de lier à volonté, les termes entre eux selon tout type de lien que l’on souhaiterait utile. Nous en avons pour l’instant retenu deux : Les liens stéréotypés <<SeeOther>> et les liens <<Extends>>. En effet ces deux types de liens appartiennent pleinement au domaine sémantique puisqu’ils ne lient que des termes deux à deux. Le stéréotype <<Allocation>> : Ce type de lien « Usage » permet d’associer plusieurs thème à un même terme et réciproquement d’associer plusieurs terme à un même thème. Le stéréotype <<Trace>>: Ce type de lien « Usage » permet d’associer tout élément de modélisation UML (Classe, package, relation,…) à un terme le définissant. Ce type de lien fait la jointure entre le monde Sémantique et le monde conceptuel

18 Modèle pragmatique(1) : exemple
Scoping

19 Modèle pragmatique(2) : exemple
Scoping

20 Modèle Logique (1) : exemple
Composants et services Scoping Composants et interfaces

21 Modèle Logique (2) : exemple
Scoping Traceabilité Règles - Services Règles de gestions

22 Modèle Logique (3) : exemple
Scoping Traceabilité Sémantique - Logique Automate d’états

23 Génération Documentaire Logique
Scoping

24 Modèle Technique (1) : exemple
Scoping Framework JAMOS La méthodologie est basée sur AMOS (PRAXEME) L’architecture J2EE a été définie par l’équipe technique Les choix techniques sont implémentés dans le framework Le framework SMABTP permet de choisir le type de déploiement au moment du déploiement : Full POJO (Plain Old Java Object ie objet java simple) En EJB, pour les MLOs et Ateliers Le développeur ne choisit plus la méthodologie, l’architecture ou les technologies à mettre en oeuvre (comme dans un projet classique) Le développeur code uniquement en mode POJO (gain de temps par rapport aux EJBs) Le développeur se concentre uniquement sur le fonctionnel

25 Gestion transactionnelle Data Architecture Object (DAO)
Framework MVC (Ecensity Presentation Server) Gestion du contexte IHM Machine Logique Organisationnelle (MLO) Atelier Machine Logique Métier (MLM) MLO Factory Gestion transactionnelle Présentation Organisation Métier Data Architecture Object (DAO) EAI (via MQ) JRules Technique Domaines externes Editique Broker d’intégration Factory Atelier Factory MLM Factory POJO EJB Hibernate SGBD Habilitation Log Configuration EPS SOA Isolation des couches Chaque couche a un rôle bien défini

26 Transformation Logique – Logiciel (1)
Scoping Lien avec le framework JAMOS

27 Transformation Logique – Logiciel (2)
Scoping Implémentation des design patterns

28 Transformation Sémantique – Logique (1)
Scoping Modèle Logique de données SQL

29 Génération Logique – Logiciel (2)
Scoping Mapping O/R - Hibernate

30 Génération Logique – Logiciel (1)
Scoping Fichier de configuration

31 Génération Logique – Logiciel (2)
Scoping Génération pour JRules Paramétrage des règles métier

32 Génération Logique – Logiciel (3)
Scoping Génération Java/J2EE Code Java

33 Démonstration: Utilisation MDAC Objecteering
Objectifs Il s'git d'une démonstration mettant en œuvre une activité traditionnellement coûteuse et difficile: l'IH Produire un très grand nombre de Widgets applicatif sur le modèle MVC implémentant un service particulier (on dit par exemple que le 8565ème service est la fonction log(X) Réutiliser un framework qui a fait ses preuves n-1 fois. Notre ingénieur n'est pas un spécialiste swing, mais il connaît java. C'est un codeur avec une appétence particulière pour l'orienté modèle. (En principe il coute moins cher, mais a un potentiel de progression plus grand prompt à intéresser le client. On déroule le développement marginal en précisant que l'ingénieur a fait son évaluation théorique de coût fixe et qu'il est acquit pour le chef de projet que le développement marginal coûte moins cher qu'un nième développement swing par un spécialiste du modèle d'évènement swing. Il faut désamorcer la bombe à retardement qui consiste à donner de l'eau au moulin du spécialiste isolé. Insister sur la qualité du code généré lisible, dans le respect des patterns state, MVC Donner la parole à celui ou ceux qui prétendraient faire mieux à moins cher :-)

34 MDA : Différentes sources d’information
Sodifrance MDA : Mise en œuvre industrielle Génie logiciel et l’approche par les modèles