Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Ingénierie par les modèles : introduction G. Halin Présentation Cours • Ingénie

Ingénierie par les modèles : introduction G. Halin Présentation Cours • Ingénierie par les modèles – Contenu : • IDM et MDA • Manipulation de modèles (EMF , XMI) • Transformation de modèles (ATL) • Application : persistence d’un modèle objet • Travaux – Exercices, – TPs sous Eclipse • Evaluation – Examen Présentation du module 3 • Quiz connaissances • www.kahoot.it Le SI et l’entreprise • Le SI prend de plus en plus de place : – Comment le décrire ? • Trouver une information, un service, une application. – Comment le faire évoluer ? • Modifier un processus, ajouter un service ? • Le SI se complexifie : – Le volume des données et du code augmente, – Les types d’informations à prendre en compte sont variées : • Processus, objets métiers, coût, flux, ressources, applications, .. – Les plate-formes d’exécution évoluent rapidement, – Les technologies sont nombreuses et variées : • Hétérogénéité des concepts manipulés : – Paradigmes, langages, protocoles, systèmes • Volume des spécifications en pleine croissante, • Rythme d’apparition augmente. Le SI et l’entreprise • Les dérives : – Ne rien faire : très coûteux – Complexité gérée par une personne : gros risque et impossible – Course aux nouvelles technologies, à la solution magique : cacher la réalité • Les solutions – Modéliser le SI : plusieurs modèles à étudier – Préconiser dans les méthodes d’urbanisation – Mémoriser les modèles : capitalisation – Echanger les modèles : • Dans l’entreprise : entre les services, les personnes • A l’extérieur de l’entreprise : fournisseur, client • Dans le SI : entre les applications • Pour gérer l’évolution : dans les plateformes de développement – Ingénierie guidée par les modèles Modéliser le SI Modéliser le SI : vue systémique Le contexte de l’entreprise (Vue simplifiée) Entreprise Clients Actionnaires Concurrence Concurrence Concurrence Concurrence Fournisseurs Modéliser le SI Le contexte : les applications, les acteurs A4 A3 A1 A2 Clients Fournisseurs A4 A3 A1 A2 Clients Fournisseurs Système : ensemble d’éléments en interaction dynamique, organisé en fonction d’un but (De ROSNAY). Modéliser le SI Le contexte : les processus métiers P1 P2 P3 Entreprise Système d’information P1 P3 Modéliser le SI : Système d’information et Système informatique Système informatique A4 A3 A1 A2 P2 Clients Fournisseurs 4. Niveau économique Modéliser le SI Le contexte : les différents niveaux P1 P3 3. Niveau organisation (processus métier): système d’information P2 A4 A3 A1 A2 1. Niveau interne : niveau applications 2. Niveau interactionnel : système informatique Prise en compte d’un nouveau besoin • L’apparition d’un nouveau besoin peut être conditionné par l’ensemble des 4 niveaux de contexte – Économique : améliorer les performances – Organisationnel : améliorer l’activité de l’entreprise – Interactionnel : améliorer l’utilisation du système – Interne : améliorer les performances du système • La compréhension des différents contextes est nécessaire • Activité de modélisation Prise en compte d’un nouveau besoin A4 A3 A1 A2 Clients Fournisseurs A5 P1 P2 P3 P4 Prise en compte d’un nouveau besoin • Intégration favorisée par – Bonne compréhension des contextes – Structure évolutive du SI – Bonne formulation des besoins • Mauvaise intégration – Augmente la complexité – Génère de l’entropie (perte d’informations) – Diminue les performances de l’entreprise Formulation du besoin • Ingénierie des besoins – La phase : Etude des besoins – Point de départ : un cahier des charges ou de doléances défini au niveau organisationnel – Définition de la place du Système informatique dans ce document • Le Système informatique est considéré comme une boîte noire • Il est un acteur potentiel • Définition du rôle joué par le système informatique • Il s’inscrit dans un nouveau processus • Activité • Enoncer des nouvelles utilisations du système informatique • Définir les interactions avec le système informatique • Ecriture de scénario décrivant les utilisations • Niveau interactionnel Formulation du besoin P1 P2 P3 P4 Système informatique Compréhension du besoin • Modéliser le besoin avec les artefacts du système – La phase : Analyse – Niveau interactionnel détaillé • Médiatisation du besoin – Les artefacts : • objets d’interface : écran, page, fenêtre, boite de dialogue… • objets dits métiers : client, fournisseur, facture, commande.. • les objets système effectuant les nouveaux services : validation commande, création client … – Les outils : • Scénario plus précis • La boîte noire s’ouvre, elle est « médiatisée » • Modèle du domaine P1 P2 P3 P4 Compréhension du besoin Acteur représenté dans le système Expression de la solution • Modélisation de la nouvelle application – Phase de conception – Proposer des solutions informatiques – Définition d’une architecture – Intégration à l’existant – Niveau interne • Représentation – Architecture matériel – Architecture logicielle – Scénario interne – Modèle du système P1 P2 P3 P4 Expression de la solution A3 Réalisation de la solution • Développement de la solution proposée • Gestion et direction du projet (management) • Programmation • Test • Validation • Déploiement • Maintenance… Modélisation • Utilisation de modèles – Essentiellement graphique – Annoté par du texte – Autre documents : glossaire, index, dictionnaire… • Construire des représentations – Besoins, solutions, application • Objectif – Communication, coordination, maintenance • UML : langage de modélisation • Connaissance UML ? : Kahoot ! Ingénierie guidée par les modèles Principe : – Modéliser l’application indépendamment de la plate-forme – Mise en œuvre de transformation de modèles Code Niveau interactionnel Niveau interne Des objets aux modèles • Le tout objet a connu ses limites : – La traçabilité des concepts d’analyse à la réalisation difficile – Les applications ne sont pas objets : • assemblage complexe de composants • hétérogénéité des technologies n’est pas encapsulée dans un seul objet, • pb accentué avec le Web, les services. – Les patrons ne sont pas des objets : • un patron n’est pas un objet mais un assemblage – Un service n’est pas un objet : • c’est une fonction, • l’architecture par les services est une demande forte actuelle – L’étude des besoins n’est pas objet : • Cas d’utilisation : étude d’une fonction, d’un processus Des objets aux modèles • L’Approche OO a généré des nouveaux paradigmes AOO Cas d’utilisation Patrons de conception Architecture de composants Autres Des objets aux modèles • L’ingénierie des modèles veut fédérer les approches AOO Cas d’utilisation Patrons de conception Architecture de composants Autres IDM Services Applications Processus La proposition de l’OMG* • Passage de l’OMA au MDA (2000) – OMA : Object Management Architecture • Objet distribué, proposition de CORBA – Face à la prolifération des inter-giciels (middleware) – Objectif : • S’abstraire de l’implémentation • Se focaliser sur le modèle – Le modèle est central, – La plateforme d’implémentation est secondaire – MDA : Model Driven Architecture • Proposition d’une architecture pour la définition de modèles – Echangeables – Transformables *OMG : Object Management Group La proposition de l’OMG • De l’intéropérabilité du code à l’intéropérabilité des modèles D’après Jean Bézivin Cobol CORBA, IDL, IIOP, ... Java Workflow MOF, UML, XML, ... UML Software Process CWMI OMA MDA La proposition de l’OMG • La réalité des industriels : – La logique métier est stable – L’évolution des systèmes, des plateformes est constante – Les migrations coûtent chère sans de réel retour sur investissement • Les objectifs – Construire des modèles abstraits du métier et des services associés – Utiliser des outils de transformation des modèles vers les plateformes – Outils de transformation fournis par les plateformes D’après Jean Bézivin • Construire des services indépendants de la plateforme La proposition de l’OMG métamodèle Plateforme Modèles (discipline) Secteur d’activités • Concentration sur un secteur d’activités • Construire des modèles de références pour un service CWM : Common Warehouse métamodel EDOC : Enterprise Distributed Object Computing • Définir des métamodèles adaptés pour construire les modèles • Exemple de métamodèles : – UML : génie logiciel – CWM : génie des données – EDOC : modélisation entreprise – … Le principe et objectif de MDA • Utilisation de modèles – pour la conception d’une application – pour chacune des phases de développement : • Le modèle d’exigences (CIM), • Le modèle d’analyse et de conception (PIM) • Le modèle du code (PSM). • Elaboration de modèles – pérennes, – indépendants des plates-formes d’exécution (J2EE, .Net, PHP, ...), • Génération automatique de la totalité du code • Obtenir un gain significatif de productivité. CIM : Computation Independent Model PIM : Platform Independant Model PSM : Platform Specific Model [Blanc 05] Le modèle d’exigences (CIM) • Le premier modèle pérenne • Modèle indépendant de la programmation • Une base contractuelle validée par le client • En UML, – un diagramme de cas d’utilisation, – La description des cas – un glossaire, – des processus métier (diagramme activité) – une vue systémique de l’application : scénario (diagramme séquence, diagramme activité) • MDA : aucune préconisation quant à l’élaboration de ce modèle • UML + des concepts de spécification précis • Objectif : tracer les liens depuis les exigences vers le code de l’application. uploads/Finance/ ingenieuriedesmodeles.pdf