Smantique d UML MOF Laurent Henocque http laurent

  • Slides: 48
Download presentation
Sémantique d' UML, MOF Laurent Henocque http: //laurent. henocque. free. fr/ Enseignant Chercheur ESIL/INFO

Sémantique d' UML, MOF Laurent Henocque http: //laurent. henocque. free. fr/ Enseignant Chercheur ESIL/INFO France http: //laurent. henocque. perso. esil. univmed. fr/ mis à jour en Novembre 2007

Licence Creative Commons Cette création est mise à disposition selon le Contrat Paternité-Partage des

Licence Creative Commons Cette création est mise à disposition selon le Contrat Paternité-Partage des Conditions Initiales à l'Identique 2. 0 France disponible en ligne http: //creativecommons. org/licenses/by-sa/2. 0/fr/ ou par courrier postal à Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Références Normatives • • • L'infrastructure UML http: //www. omg. org/cgi-bin/doc? formal/05 -07 -05

Références Normatives • • • L'infrastructure UML http: //www. omg. org/cgi-bin/doc? formal/05 -07 -05 La superstructure UML http: //www. omg. org/cgi-bin/doc? formal/05 -07 -04 OCL http: //www. omg. org/cgi-bin/doc? ptc/05 -06 -06

Autres références • Ce support de cours s'appuie sur des exemples concrets mis à

Autres références • Ce support de cours s'appuie sur des exemples concrets mis à disposition librement sur internet par différentes sources – http: //www. rational. com – http: //www. visualuml. com – http: //uml. free. fr – http: //www. sparxsystems. com. au/resourc es/uml 2_tutorial/index. html

Objectifs • Présenter l'organisation d'UML sur la base de couches d'abstractions successives et illustrer

Objectifs • Présenter l'organisation d'UML sur la base de couches d'abstractions successives et illustrer l'utilisation bootstrappée de la méthode

Préambule • UML est un formalisme de modélisation dont la sémantique et la syntaxe

Préambule • UML est un formalisme de modélisation dont la sémantique et la syntaxe sont formellement décrites • UML permet de décrire des modèles possédant également cette propriété • La méthode est "bootstrappée" : un fragment essentiel d'UML (le méta modèle) est utilisé pour "auto" décrire la méthode (via un méta modèle) • Seul le méta modèle est dépourvu de justifications autres qu'intuitives

Modélisation = Syntaxe • Une méthode de modélisation permet de définir des syntaxes •

Modélisation = Syntaxe • Une méthode de modélisation permet de définir des syntaxes • Une syntaxe décrit un ensemble (infini) de constructions possibles • Par exemple, un modèle décrira que tous les véhicules ont des roues, éventuellement un moteur, de type diesel ou essence, etc. . .

Modélisation = Syntaxe sous contraintes • Par un relatif abus de langage, la documentation

Modélisation = Syntaxe sous contraintes • Par un relatif abus de langage, la documentation UML place sous la rubrique sémantique les règles de bonne formation (well formedness rules) qui s'ajoutent aux descriptions essentiellement graphiques • Dans ce cadre figurent les contraintes additionnelles portant sur le modèle (dites de bonne formation) : par exemple le fait qu'une voiture de plus de 150 chevaux possède exactement des freins à disque ventilés

4 niveaux de modélisation

4 niveaux de modélisation

Niveau 1 : les instances ou objets • Les instances sont les objets actuellement

Niveau 1 : les instances ou objets • Les instances sont les objets actuellement réalisés lors de l'exécution d'un programme • Le rôle du modèle est de définir quelles sont les états possibles et admissibles des objets manipulés par l'application à tout moment

Niveau 1 : les données • Les instances sont les objets réalisés lors de

Niveau 1 : les données • Les instances sont les objets réalisés lors de l'exécution d'un programme, ou stockées dans des bases de données • Imaginons un système de gestion de données boursières. La base conserve les données numériques associées aux actions Action("Air France", 3. 78€) Action("TF 1", 7. 47€). . .

Niveau 2 : le modèle • C'est la description des classes, de leurs relations,

Niveau 2 : le modèle • C'est la description des classes, de leurs relations, et des contraintes qui servent de "modèle" pour la création d'instances du niveau 1 • L'utilisation d'un modèle permet de contrôler la validité des états du système, et de le documenter

Niveau 2 : le modèle Record{"Action", Champ(1, "société", String), Champ(2, "prix", Num) } Action("Air

Niveau 2 : le modèle Record{"Action", Champ(1, "société", String), Champ(2, "prix", Num) } Action("Air France", 3. 78€) Action("TF 1", 7. 47€). . .

Niveau 3 : le méta modèle • Le méta modèle définit ce qu'il est

Niveau 3 : le méta modèle • Le méta modèle définit ce qu'il est possible de modéliser. • C'est un modèle également, décrit avec un fragment d'UML, dont les classes portent les noms de "Class", "Relation", . . .

Niveau 3 : le méta modèle Meta. Class{"Record", Meta. Attr("Nom. Classe", String), Meta. Attr("Champs",

Niveau 3 : le méta modèle Meta. Class{"Record", Meta. Attr("Nom. Classe", String), Meta. Attr("Champs", list<Champ>)} Meta. Class{"Champ", Metaattr("num", int), Metaattr("nom", String), Record{"Action", Metaattr("type", Type)}. Champ(1, "nom", String), Champ(2, "prix", Num) }

Niveau 4 : le méta modèle • Le méta modèle est le langage de

Niveau 4 : le méta modèle • Le méta modèle est le langage de définition du méta modèle. • Il est donné sans justification par un ensemble réduit de primitives • Le langage permettant de décrire le méta modèle doit être auto explicatif : un ensemble minimal de primitives capable de "s'autodécrire".

Niveau 4 : le méta modèle • Par exemple une grammaire BNF : MM->[MC]*

Niveau 4 : le méta modèle • Par exemple une grammaire BNF : MM->[MC]* MC->"Meta. Class" "{" SC ", " [MA]*"}" MA->"Meta. Attr" "(" SC ", " Ident ")" SC -> """ Ident """ Meta. Class{"Record", Meta. Attr("Nom. Classe", String), Meta. Attr("Champs", list<Champ>)}

Niveau 4 : méta modèle UML • Dans le cas d'UML, le méta modèle

Niveau 4 : méta modèle UML • Dans le cas d'UML, le méta modèle est un fragment minimal des diagrammes de classes, complété par le langage de contraintes (logique) OCL • Un exemple d'un tel méta modèle est le langage MML + OCL

MML : Méta Modeling Language • On décrit UML avec un fragment de celle-ci

MML : Méta Modeling Language • On décrit UML avec un fragment de celle-ci • Ce fragment doit avoir des propriétés intéressantes : • c'est le plus petit fragment possible capable de se décrire lui-même tout en permettant de décrire UML • MML est un exemple d'une telle tentative • http: //www. cs. york. ac. uk/puml/ • http: //citeseer. ist. psu. edu/674312. html

Méta modèle UML : éléments fondamentaux classe role attributs relation role multiplicité héritage agrégation/composition

Méta modèle UML : éléments fondamentaux classe role attributs relation role multiplicité héritage agrégation/composition

Le méta modèle UML Comprendre la spécification de la méthode UML

Le méta modèle UML Comprendre la spécification de la méthode UML

Le méta Modèle UML • Le méta modèle décrit donc ce que l'on peut

Le méta Modèle UML • Le méta modèle décrit donc ce que l'on peut modéliser. • Il est documenté par UML et forme le manuel de référence d'UML • UML n'est assortie de recommandations graphiques que pour la forme : la seule loi est celle définie par le méta modèle, indépendamment des artéfacts graphiques choisis

Fragment du méta modèle UML : les classes

Fragment du méta modèle UML : les classes

Le Métamodèle = syntaxe des modèles

Le Métamodèle = syntaxe des modèles

Organisation du méta modèle : les Packages

Organisation du méta modèle : les Packages

Packages fondamentaux de "Foundation" • Structure statique des modèles

Packages fondamentaux de "Foundation" • Structure statique des modèles

Core : Backbone 1

Core : Backbone 1

Core : Backbone 2

Core : Backbone 2

Core : Associations 1

Core : Associations 1

Core : Associations 2

Core : Associations 2

Core : Dépendances

Core : Dépendances

Core : Classifieurs

Core : Classifieurs

Core : Elements auxiliaires

Core : Elements auxiliaires

OCL : Règles de bonne formation

OCL : Règles de bonne formation

Core Semantics : exemple 1 • [2] No Attributes may have the same name

Core Semantics : exemple 1 • [2] No Attributes may have the same name within a Classifier. • (Unicité des noms d'attributs dans un Classifier) self. feature-> select(a | a. ocl. Is. Kind. Of(Attribute))-> for. All(p, q | p. name=q. name implies p=q)

Core Semantics : exemple 2 • No Behavioral. Feature of the same kind may

Core Semantics : exemple 2 • No Behavioral. Feature of the same kind may match the same signature in a Classifier. (Deux "méthodes" ne peuvent avoir la même signature) self. feature->for. All(f, g |(( (f. ocl. Is. Kind. Of(Operation) and g. ocl. Is. Kind. Of(Operation)) or (f. ocl. Is. Kind. Of(Method) and g. ocl. Is. Kind. Of(Method)) or (f. ocl. Is. Kind. Of(Reception) and g. ocl. Is. Kind. Of(Reception)) ) and f. ocl. As. Type(Behavioral. Feature). matches. Signature(g) )implies f = g)

Abstraction • Une abstraction est une relation de dépendance entre deux éléments ou ensembles

Abstraction • Une abstraction est une relation de dépendance entre deux éléments ou ensembles d'éléments qui représentent le même concept à deux niveaux d'abstraction, ou selon différents points de vue • Attributs : mapping • Stéréotypes : «derive» , «realize» , «refine» , and «trace»

< un extrait de la documentation > • In the metamodel, an Abstraction is

< un extrait de la documentation > • In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client. Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. • If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The situation is similar if there is more than one supplier element.

Artifact • Un "Artifact" représente un élément physique d'information utilisé ou produit par le

Artifact • Un "Artifact" représente un élément physique d'information utilisé ou produit par le processus du développement logiciel • Par exemple : les modèles, les sources, les scripts et les fichiers binaires exécutables. • Un "Artifact" peut constituer l'implémentation d'un composant déployable

Artifact • Un artifact est un classifier muni d'une agrégation optionnelle avec un ou

Artifact • Un artifact est un classifier muni d'une agrégation optionnelle avec un ou plusieurs composants • En tant que Classifieurs, les Artéfacts peuvent avoir des attributs qui représentent leurs propriétés ( par exemple l'attribut “read-only” ou l'opération “check in”). • Associations : implementation le composant déployable implanté par cet artifact • Les stereotypes de Artifact sont «file» , les sous classes de «file» ( «executable» , «source» , «library» , et «document» ), et «table» . Ces stereotypes peuvent être sous classés : (e. g. , «jar. File» pour les archives Java).

< un extrait de la documentation > • It should be noted that sometimes

< un extrait de la documentation > • It should be noted that sometimes Artifacts may need to be linked to Classifiers directly, without introducing a ‘Component. ’ • For instance, in the context of code generation, the resulting Artifacts (source code files) are never deployed as Components. • In that case, a «derive» Dependency can be used between the Classifier(s) and the generated Artifact.

Association • Une association définit une relation sémantique entre classifieurs. Ses instances (des "Link"s)

Association • Une association définit une relation sémantique entre classifieurs. Ses instances (des "Link"s) sont des ensembles de tuples • Dans le méta modèle, une association est la déclaration d'une relation sémantique entre deux classifieurs, tels que des classes. Une association a au moins deux extrémités (Association. End), chacune connectée à un classifieur

Association (2) • • Attributs : name Associations : connection Stéréotypes : implicit Contraintes

Association (2) • • Attributs : name Associations : connection Stéréotypes : implicit Contraintes standard : xor (une seule association est réalisée pour chaque instance associée) • Tagged Values : persistence : le lien survit il à la disparition de ses extrémités • Features héritables : connection • Features non héritables : name (unique), is. Root, is. Leaf, is. Abstract (liés au modèle entier)

Association. Class • C'est une association qui est aussi une classe : elle possède

Association. Class • C'est une association qui est aussi une classe : elle possède ses propres "features".

Association. End : Attributs • • aggregation (none, aggregate, composite), changeability (changeable, frozen, add.

Association. End : Attributs • • aggregation (none, aggregate, composite), changeability (changeable, frozen, add. Only), ordering (unordered, ordered), is. Navigable (true, false), multiplicity name target. Scope (instance, classifier) visibility

Association. End • Une des extrémités d'une association. Elle est reliée à un classifieur,

Association. End • Une des extrémités d'une association. Elle est reliée à un classifieur, mais porte aussi les informations associées aux rôles (nom, cardinalités, etc) • Stéréotypes : association (le défaut), global (la cible est une variable globale), local (la cible est une variable locale), parameter (la cible est un paramètre), self (la cible est l'objet support "this")

Association. End : associations • qualifier : liste d'attributs de qualification • specification :

Association. End : associations • qualifier : liste d'attributs de qualification • specification : un ou plusieurs qualifieurs qui définissent l'interface de programmation minimale qui doit être supportée par la cible quand l'association est traversée • participant : le classifieur cible • extrémité anonyme de composite : l'association qui possède ce "end"

Attribute • Etc. . .

Attribute • Etc. . .