Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
1Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Ingénierie des modèlesa. Définir et capitaliser
Raphaël MarvieLIFL - IRCICA
Université de Lille [email protected]
http://www.lifl.fr/~marvie
2Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Menu
IntroductionModélisation et méta-modélisation
• Systèmes, modèles, méta-modèlesMeta Object Facility
• Standard de l’OMG pour la méta-modélisationStructuration des méta-modèles
• Séparation des préoccupationsConclusion
3Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Introduction
4Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Les technologies
La semaine d’un concepteur logiciel• Lundi: C et sockets• Mardi: C et RPC• Mercredi: Java et Servlets• Jeudi: Java, C++ et CORBA• Vendredi: Java et CCM• Samedi: C# et web services• Dimanche: Prozac et Tranxène
5Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Il n’y a pas de capitalisationde la définition du système
6Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Les concepts des technologies
• Avant 1980: Les procédures• Procédures et fonctions
• 1980-1995: Les objets• Objet, classe, méthode, attribut
• Depuis 1995: Les composants• Composant, package, container, framework, etc.
7Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Et demain?
8Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
La guerre des intergiciels
• Sun microsystems• Java = runtime universel
• Object Management Group• CORBA = intergiciel universel
• Microsoft et al• Web services = interopérabilité universelle
9Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Match nul, balle au centre
10Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
L’évolution des technologies
• Il n’y a pas de technologie idéale• Ni aujourd’hui, ni jamais
• Nouvelle technologie => nouveaux problèmes• S’attendre à l'inattendu
• L’évolution ne peut être arrêtée• Ce qui ne serait pas si cool
• La meilleure technologie est celle à venir…
11Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Problème
• La logique métier est mélangée avec le codetechnique• Vrai pour toutes les technologies
• L’évolution des applications n’est pas simple• Garder la logique métier• Jeter le code technique
• Nécessite de s’abstraire des technologies
12Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Une solution
• Séparation des préoccupations• Préoccupations métier• Préoccupations techniques
• Modélisation des systèmes• Description abstraite des préoccupations métiers• Réutilisation dans différentes contextes (technologies)
• Peut être pas idéal, mais semble être un bon pari
13Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Des modèles aux systèmes
• Capitalisation de la définition des systèmes
• Utilisation de standards de modélisation
• Règles de projections• A définir pour chaque technologie• A faire évoluer avec les technologies
• Amélioration de l’évolution et de l’intégration dessystèmes
14Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Modélisation et méta-modélisation
15Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Modèles
« Un modèle est une abstraction d’unsystème »• La description de ce système
16Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Systèmes et modèles
Un modèle est uner e p r é s e n t a t i o nsimplifiée d’une partiedu monde appelée lesystème
Modèle
Système
Espace de modélisation
Le monde
Est décrit par
17Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Substitution
Un modèle doit répondreà toute question relativeau système
Un modèle doit répondreexactement de la mêmemanière que le système
Modèle
Système
A1 = Ask ()
A1 = A2Représente
A2 = Ask ()
18Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Spécificité (i)
Un modèle pourun objectifparticulier.
Tout modèle estincomplet.
19Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Spécificité (ii)
Différentsmodèlespeuvent êtredéfinis pour unmême système.
20Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Exemple: Serveur Web
Serveur Service
Page HTML CGI Servlet
Serveur Utilisateur
Admin Abonné
*
*
21Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Méta-modèles
« Un méta-modèle définit une abstraction,ses concepts »• Les règles de définition des descriptions
Le métamodèle est la légende de la carte.
22Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Système, modèle et méta-modèle
Un méta-modèledéfinit la relationentre un modèleet un système.
Les règles dedéfinition desdescriptions
Modèle
Système
Espace de modélisation
Le mondeEst décrit par
Méta-modèle
23Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Méta-modèle simple de Java
Parameter
Method
Attribute
type
attributes
methods
type
JavaXXS
Class
super
24Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Promotion de modèle
Serveur Service
Page HTML CGI Servlet
*
Notre modèle de serveur web devient un métamodèle pour
modéliser des serveurs web…
25Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Spécificité et objectifs
• Tout comme un modèle un métamodèle estspécifique à un objectif
• Pour chaque domaine de modélisation ilfaut un métamodèle
• Domain Oriented Modeling
26Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Le Meta Object Facility
27Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Des instances aux méta-modèles
Modèle
Système
Méta-modèle
Méta-Méta-modèle M3Package, Entity, Association
M2Class, Method, Attribute
M1PhilosopherFork
M0Nietzsche, Platon, Kantfork1, fork2, fork3
28Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Méta-modèles et grammaires
• M3: Méta-méta-modèle, EBNF, XML• Concepts pour définir des éléments de niveau M2
• M2 :Méta-modèle, BNF Java, DTD XML• Concepts pour définir des éléments de niveau M1
• M1: Modèle, source Java, document XML• Descriptions d’éléments de niveau M0
• M0: Instance, programme Java, données• Représentation informatique du monde réel
29Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Pile de méta-modélisation (OMG)
• Un unique méta-modèle• Meta Object Facility (MOF)• Concepts de méta-modélisation
• Un ensemble de méta-modèles• Pour différents besoins / domaines• Compatibles puisque définis avec le MOF
• Un grand nombre de modèles• Décrivant un grand nombre de systèmes• Définis avec les concepts de leurs uniques méta-modèles
30Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
D’un paysage de systèmes…
T3
T1 T2
T4
Telecom
E3
E1 E2
E4
Embeded
B3
B1 B2
B4
E-Business
31Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
…A un paysage de méta-modèles
T1
M2 Telecom
MOF
M2 Embeded M2 Business
T2
T3 T4
E1 E2
E3 E4
B1 B2
B3 B4
32Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Meta Object Facility
• Méta-méta-modèle méta-circulaire• Suffit à sa propre définition
• Les concepts pour la définition de M2• Plus d’une vingtaine (MOF 1.4)
• Concepts essentiels• Classe (+méthodes et attributs)• Association• Références• Package
33Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Classes MOF
• Description des types de méta-objets• Les concepts des méta-modèles
• Structure des classes MOF (nommées)• Attribut: contenant (type de base / classe)• Opération: comportement associé
• Utilisation• Composition: via attributs ou associations• Héritage: généralisation (multiple et sans
surcharge)
34Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Association MOF
• Mise en relation de deux classes d’un M2• Définit un lien entre instances de M1
• Structure des associations• Sans identité, opération ou attribut• Contient exactement deux terminaisons
• Nécessairement des classes• Arité multiple possible
• Peut être navigable (+références) etmodifiable
35Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Références MOF
• Association: interactions orientées requêtes• Demande à un type d’association les éléments en
relations (calcul % type de lien)• Attribut: interactions orientées navigation
• Opérations de type get() et set() sur les attributs• Profiter des avantages des deux à la fois
• Définition d’associations• Définition de références: classe vers l’autre
terminaison de l’association (~ attribut)
36Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Packages MOF
• Permet de définir des méta-modèles• Regroupement des éléments définissant le M2• Permet aussi de structurer les méta-modèles
• Peut contenir• Classes, associations, packages, etc.
• Au niveau M1• Les packages sont représentés par des instances
• Conteneurs de méta-données• Point d’entrée sur leur contenu
37Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Composition de méta-modèles (i)
• Compositions de packages
• Import• Récupérer les définitions d’un autre package• Utilisées comme si définies localement
• Imbrication• Définir des sous packages (inner classes java)• 1 sous-package ne peut être importé / hérité
38Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Composition de méta-modèles (ii)
• Généralisation (héritage)• Acquiert tous les éléments du package hérité• Multiple et substitution possibles• Sans réelle sémantique (sic)
• Regroupement• Forme d’importation• Lie fortement l’importé et l’importeur• Impact sur le cycle de vie à l’utilisation
39Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Remarques sur le MOF
• Expression de méta-modèles• Pas de syntaxe particulière pour le MOF• UML, XMI (XML Metadata Interchange),
MODL (Meta Object Definition Language)
• Utilisation de méta-modèles• Projections vers IDL ou Java (JMI)• Production de référentiels de manipulation de
modèles (fabrication d’outils)
40Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Structuration des méta-modèles
41Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Séparation des préoccupations
• Les méta-modèles doivent être structurés• Décomposition des problèmes• Séparation des préoccupations [Parnas72]
• Proposition• Un plan pour le cœur de métier (méta-modèle)• Un plan par préoccupation (méta-modèle)• Des règles d’utilisation
• Annotation du cœur de métier par les préoccupations• Intégration des différentes préoccupations
42Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Plans et vues
Cœur de métier
Préoccupation2 Préoccupation3Préoccupation1
Intégration
«annote»
«regroupe»
43Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Pattern de méta-modélisation
«uses»
«inherits»
Pattern
Base
Concern Base
ConcernAnnotation
Integration «inherits»
44Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Applications réparties
Component
Provided Required
Port
Connection
offers uses
from to
Utilisation de composants• cœur de métier
Un composant• offre des ports
• utilise des ports
Une connexion entre• un port fourni• un port requis
Base
45Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Préoccupation (base)
Interface
Archive
isImplementedBy
isDefinedBy
Définition des conceptsrelatifs à la préoccupation
Développement: mise enœuvre des composants
Une archive contient• une interface
• une ou plusieurs implémentations
ImplBase
Implementation
46Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Préoccupation (annotation)
ImplBase::Archive
Component
isImplementedBy
Définition des liens entreconcepts de base et depréoccupations
Définition d’associations liant• concepts de base (hérités)• concepts relatifs à lapréoccupation (importés)
ImplAnnot
47Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Intégration (définition)
ImplAnnot
Application
«Inherits»
Définition du méta-modèle del’application comme l’uniondes méta-modèlesd’annotation
Méta-modèle d’application• hérite des méta-modèlesd’annotation• contient tous les concepts(base et préoccupations)
LocAnnot
48Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Intégration (extrait)
ImplBase::Archive
Component
isImplementedBy
Application
LocBase::HostrunsOn
49Ingénierie des modèles (a) © 2003-2005, Raphaël Marvie
Conclusion
• Modélisation• Fournir des descriptions abstraites des systèmes
• Méta-modélisation• Définir les abstractions adaptées aux besoins
• Capitaliser la logique métier des systèmes• Pérenniser la conception des systèmes• Pérenniser la définition des préoccupations