1287779617xb Model Engineering

Ingénierie des
Modèles
Cours de Hatem Ben Sta Lille Mars 2008 X. Blanc – Université Paris 6
Plan
 Lundi 18 Octobre : Un curieux besoin de modèles
 Etude d’une application Java
 Etude d’une application WS
 Introduction à UML
 Introduction à l’ingénierie des modèles
 Lundi 25 Octobre : Des modèles productifs
 UML pour la génération de documentation
 UML pour la génération d’application
 Lundi 01 Novembre : Opération sur les modèles
 Utilisation du langage J sur UML
 Lundi 08 Novembre : Modèles et méta-modèle
 Architecture à 4 niveaux
 MOF, JMI
 Lundi 15 Novembre : l’approche MDA
 PIM, PSM, Code
 Modèle de transformation de modèles
 Interopérabilité des modèles
Un curieux besoin de
modèles
Etude d’une application Java
Etude d’une application WS
Introduction à UML
Introduction à l’ingénierie des modèles
Cas 1
Etude d’une application Java
Cas 1
Objectif
 Vous devez fournir un document
expliquant l’application afin qu’une autre
équipe puisse faire évoluer cette
application en y ajoutant une nouvelle
fonctionnalité!
Cas 1
Scénario d’utilisation
Cas 1
Vision Schématique Abstraite
IHM BD
Personne
Cas 1
Classes de l’application
 Repertoire
 Personne
 Adresse
 UIRepertoire
 UIPersonne ?
 UIActionListener
 MyAssistant
Cas 1
IHM BD
UIPersonne Adresses
UIRepertoire Personne
Repertoire
UIActionListener
Cas 1
Méthode Main
public static void main(String[] args) {

UIRepertoire ihm = new UIRepertoire();
}
public UIRepertoire() {
super("Mon Repertoire");
menuListener = new UIMenuActionListener(this);
WindowListener l = new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
?
}
public void windowClosed(WindowEvent e) {
System.exit(0);
}
};
addWindowListener(l);
init();
}
Cas 1
IHM BD
UIPersonne Personne Adresses

UIRepertoire
Repertoire
UIActionListener
MyAssistant
Cas 2
Etude d’une application WS

 Cette application converti un fichier excel
CSV en un fichier XML
Cas 2
Objectif
 Vous devez décrire précisement mais
simplement l’architecture de cette
application
Cas 2
Feuille WSDL
Cas 2
Utilisation de Spy
 Demo
Cas
Synthèse
 Le code n’est pas un bon média de
capitalisation
 L’abstraction nécessite
 Une bonne connaissance technique
 Un format de représentation commun
=> Modéliser
UML
Des Méthodes de modélisation

 L’apparition du paradigme objet à permis
la naissance de plusieurs méthodes de
modélisation
 OMT, OOSE, Booch, Fusion, …
 Chacune de ces méthodes fournie une
notation graphique et des règles pour
élaborer les modèles
 Certaines méthodes sont outillées
UML
Trop de Méthodes
 Entre 89 et 94 : le nombre de méthodes
orientées objet est passé de 10 à plus de 50
 Toutes les méthodes avaient pourtant
d’énormes points communs (objets, méthode,
paramètres, …)
 Au milieu des années 90, G. Booch, I. Jacobson
et J. Rumbaugh ont chacun commencé à
adopter les idées des autres. Les 3 auteurs ont
souhaité créer un langage de modélisation unifié
UML
Historique
Définition en cours par une UML 2.0
commission de révision
Soumission à l’OMG UML 1.x 1999-2002
UML 1.2 Juin 1998

Standardisation par l’OMG
Novembre 1997
Soumission à l’OMG UML 1.1
Septembre 1997
Soumission à l’OMG UML 1.0 Janvier 1997
Version bêta OOPSLA’96 UML 0.9 Juin 1996
OOPSLA’95 Méthode unifiée 0.8 Octobre 1995
Booch’93 OMT-2
Autres méthodes Booch’91 OMT-1 OOSE Partenaires

UML
Aujourd’hui
 UML est le langage de modélisation orienté objet le plus connu et le
plus utilisé au monde
 UML s’applique à plusieurs domaines
 OO, RT, Deployment, Requirement, …
 UML n’est pas une méthode
 RUP
 Peut d’utilisateurs connaissent le standard, ils ont une vision outillée
d’UML (Vision Utilisateur)
 5% forte compréhension, 45% faible compréhension, 50% aucune
compréhension
 UML est fortement critiqué car pas assez formel
 Le marché UML est important et s’accroît
 IBM, Sun, Borland, Microsoft
UML
Diagramme de Classes
 Un diagramme de classes est un graphe de
classes connectés par des relations.
 Un diagramme de classes est une vue
graphique de la structure statique d’un système.
Company
Person
members
Company Employee
0..1 *
UML
Classes
 Une classe représente la structure commune
d’un ensemble d’objets.
 Une classe est représentée par un rectangle qui
contient une chaîne de caractères
correspondant au nom de la classe
 Ce rectangle peut être séparé en trois parties (nom,
attributs, opérations).
 Le nom de la classe doit commencer par un caractère
alphabétique et ne pas contenir le caractère ‘::’
UML
Classes
Employee Person
+name : string
+firstName : string
#id : string
nbPerson : integer
/completeName : string
UML
Attributs
 Une classe peut contenir des attributs
 La syntaxe d’un attribut est :
visibilité nom : type
 La visibilité est:
 ‘+’ pour public
 ‘#’ pour protected
 ‘-’ pour private
 UML définit son propre ensemble de types
 Integer, real, string, …
 Un attribut peut être un attribut de classe, il est alors souligné.
 Un attribut peut être dérivé, il est alors préfixé par le caractère ‘/’
UML
Attributs
Person
Company +name : string

+firstName : string
url [3] : string
#id : string
name : string
nbPerson : integer
/completeName : string
UML
Opérations
 Une opération est un service qu’une
instance de la classe peut exécuter
 La syntaxe d’une opération est:
visibility name(parameter):return
 La syntaxe des paramètres est:
kind name : type
 Le kind peut être:
 in, out, inout
UML
Opérations
Company
url [3] : string

name : string
+makeProfit():real
+getWorkingEmployee(): [*] Employee
Employee
+stopWork():boolean
+startWork(In work:string):boolean
UML
Héritage
 L’héritage est une relation entre un élément plus
général et un élément plus spécifique. L’héritage
existe entre des classes, des packages, …
 L’héritage multiple est possible en UML
S hape
Rectangle Circle
UML
Associations
 Les associations binaires connectent deux
éléments entre eux
 Une association binaire est composée de deux
associations ends.
 Une association end est paramétrée par:
 Un nom (le role joué par l’entité connectée)
 Une multiplicity (0, 1, *, 1..*, …)
 Un genre d’aggregation (composite, aggregation,
none)
 De plusieurs propriétés: isNavigable, isChangeable
UML
Associations
students attendedCourses
S tudent Course
* attends *
Un étudiant suit des

Un cours est suivi par cours (0 ou plusieurs). A
plusieurs étudiants (0 ou partir d’un étudiants, il est
plusieurs). possible d’identifier les
cours suivis (navigable).
UML
Associations
Composition
has
S chool Department
1 1..*
Aggrégation 1..*
member
S tudent
UML
Associations
 Les associations N-aire connectent
plusieurs éléments entre eux.
 Les associations N-aire sont très peu
utilisées.
Class
Class1
Class2
UML
Classes-Associations
 Une classe-association est une association qui
est aussi une classe.
 Les classes-associations sont utilisées lorsque
les associations doivent porter des informations
 Il est toujours possible de se passer des
classes-associations.
Company Employee
* 1..*
Job
salary : undefined
UML
Interfaces
 Une interface est la spécification externe (en
terme d’opérations) d’une classe.
 Une interface peut donc contenir des opérations
 Une classe réalise une interface si elle est
capable d’exécuter toutes les opérations de
l’interface
 On utilisera une relation de dépendance pour
exprimer le fait qu’une classe est cliente d’une
interface.
UML
Interfaces
Element
Parser
+addChild(In child:Element)
Engine
+getChildren(): [*] Element
Parser
Element
Engine
UML
Contraintes et Notes
 Il est possible de contraindre ou d’annoter
n’importe quel élément du modèle
 Les contraintes et les notes sont bien
souvent écrites en langage naturel
 Le langage OCL est cependant préconiser
pour décrire des contraintes
 self.age<60
UML
Contraintes et Notes
<<comment>>
Une association n'est pas
une company
Company Employee
* 1..*
ageLimit
{self.age<60}
UML
Packages
 Un package permet de grouper des
éléments
 Un package sert d’espace de désignation
 Un package peut inclure d’autres package
 Un package peut importer d’autres
package
 L’héritage entre package est possible
UML
Packages
UML
Diagramme de Classe - Fin

 Les diagrammes de classes sont les
diagrammes les plus utilisés
 Ils permettent la décrire des programmes objet
 Ils permettent de décrire le schéma logique de bases
de données
 Ils permettent de décrire des relations de concepts
(modèle métier)
 Les diagrammes de classes peuvent être de
différents niveaux d’abstraction
Ing. Modele
A vous de jouer
 Définir le diagramme
de classe d’un tournoi
de foot (type
mondial)
de classe de
l’application
MyAssitant
Ing. Modele
Reverse Engineering
 Le reverse engineering consiste à créer
automatiquement un diagramme de classe
à partir de n’importe quelle application
 Nous avons réalisé un reverse
engineering sur l’application MyAssistant
Ing. Modele
Reverse de MyAssistant
Ing. Modele
A vous de jouer
 Comment marche un
reverse engineering?
Ing. Modele
A vous de jouer
 Pourquoi n’y a-t-il pas
de lien entre répertoire
et personne?
Ing. Modele
Diagramme d’implémentation vs
diagramme conceptuel
 Le diagramme obtenu après reverse
engineering est une copie graphique du
code : c’est un diagramme
d’implémentation
 Le diagramme réalisé en analysant
l’application est un diagramme conceptuel
(ex: le diagramme de MyAssistant réalisé
précédemment)
Ing. Modele
A vous de jouer
 Est-il possible de passer
d’un diagramme
conceptuel à un
diagramme
d’implémentation?
 Et l’inverse ?
Ing. Modele
Comment Modéliser ?
 The choice of what models to create has profound
influence on how a problem is attacked and how a
solution is shaped
 Every model may be expressed at different levels of
precision
 The best models are connected to reality
 No single model is sufficient. Every non trivial system is
best approached through a small set of nearly
independant models
Notation & Méthode

Bilan
 Nécessité de modéliser
 Place de UML
 Modèles vs code
 Nécessité de l’ingénierie de la
modélisation
Des modèles
productifs
UML pour construire

L’atelier Objecteering
L’Electricien et l’Informaticien
Un problème, des besoins
Un composant virtuel
(des entrées des sorties)
Des portes AND, OR, NOR, … UML

Un schéma électrique
Le composant électrique Le programme informatique
Des Modèles plutôt que du Code
 Un modèle est la simplification/abstraction de la
réalité
 Nous construisons donc des modèles afin de
mieux comprendre les systèmes que nous
développons
 Nous modélisons des systèmes complexes
parce que nous somme incapables de les
comprendre dans leur totalité
 Le code ne permet pas de simplifier/abstraire la
réalité
Un problème - Un diagramme
 Diagramme de classes / Class Diagram UML 1.x
 Classe, Opération, Attribut, Association, …
 Diagramme d’objet / Object Diagram
 Diagramme de cas d’utilisation / Use Case Diagram
 Cas d’utilisation, Acteur, ..
 Diagramme de séquence / Sequence Diagram
 Instance, message, relation
 Diagramme de collaboration / Collaboration Diagram
 Diagramme d’état / Statechart Diagram
 Diagramme d’activité / Activity Diagram
 Diagramme de composant / Component Diagram
 Diagramme de déploiement / Deployment Diagram
Diagramme de Cas d’Utilisation
 Un diagramme de cas d’utilisation décrit des
acteurs et leurs relations avec des cas
d’utilisation
 Les diagrammes de cas d’utilisation décrivent
les fonctionnalités d’un système
Acteurs
 Un acteur représente un utilisateur externe
du système
 Un acteur est en relation avec un ou
plusieurs cas d’utilisation
 Il est possible de définir des relations
d’héritage entre Acteurs
Cas d’Utilisation
 Un cas d’utilisation représente une fonctionnalité
du système
 Il est possible de définir des relations de
dépendance entre cas d’utilisation
 Il est possible de définir des relations d’inclusion
entre cas d’utilisation
 Il est possible de définir des relations d’héritage
entre cas d’utilisation
Diagramme de Cas d’Utilisation
M agisterTest1
Bill customer
Place order <<include>>

Customer
Validate user
<<include>>
Ship order
<<extend>> Check Password
CommercialCustomer
Ship partial order
Cas d’Utilisation -Fin
 Les diagrammes de cas d’utilisation sont
souvent employés
 Ils permettent de décrire le système de façon très
abstraite
 Ils offrent une vue fonctionnelle (par opposition à une
vue Orienté Objet)
 Ils sont très simples …
 La difficulté consiste à passer des cas
d’utilisation aux classes
A vous de jouer
de cas d’utilisation de
yahoo!
de cas d’utilisation de
Air Senegal
Diagramme de Séquence
 Un diagramme de séquence représente une
interaction entre plusieurs éléments
 Les éléments interagissent par envoi de
messages
 Les éléments interagissant sont des instances
jouant des rôles.
Instances
 Un diagramme de séquence met en œuvre des
instances
 Instance de classe, Instance d’acteur
 Graphiquement une instance se distingue de son type
car elle est soulignée
 Il est possible de définir des instances sans préciser leur
classe
 La durée de vie des instances est définie sur l’axe
vertical du diagramme
 Graphiquement l’activité d’une instance se voit grâce à
un rectangle sur l’axe du temps
Messages
 Creation: Une instance peut créer une autre instance
grâce à un message de création
 Destruction: Une instance peut détruire une autre
instance grâce à un message de destruction
 Message de Séquence: Une instance peut envoyer un
message de séquence à une autre instance pour
demander l’exécution d’une opération
 Message Asynchrone: Une instance peut envoyer un
message asynchrone à une autre instance (événement)
 Branche de messages: Il est possible de spécifier des
conditions sur l’envoi de message (if then else)
Diagramme de Séquence
Diagramme de Séquence - Fin
 Les diagrammes de séquence sont de plus en
plus utilisé
 Ils permettent de décrire la dynamique d’un système
 Ils permettent de faire le lien entre les diagrammes de
cas d’utilisation et les diagrammes de classes
 La sémantique de ces diagrammes est encore
un peu flou
 Les techniques de génération de code n’exploitent
pas encore très pleinement ces diagrammes
A vous de jouer
de séquence d’un
examen scolaire
Diagramme d’Objets
 Un diagramme d’objet représente la vue
statique d’un ensemble d’instance de
classes
Diagramme de Collaboration
 Un diagramme de collaboration représente la
vue statique et la vue dynamique d’un ensemble
d’élément
 Une collaboration définit des rôles (et non pas
des classes!)
Diagramme d’Etat
 Un diagramme d’état représente la vue
dynamique d’un ensemble d’éléments
sous forme d’état
Diagramme d’Activité
 Un diagramme d’activité représente la vue
dynamique d’un ensemble d’éléments sous de
flux d’exécution
Diagramme de composant
 Un diagramme de composant représente
les composants logiciels d’un système
Diagramme de déploiement
 Un diagramme de déploiement représente la
façon dont déployer les différentes éléments
d’un système
Le Besoin d’Organisation
 Un modèle UML représente un système et son
environnement
 Les diagrammes UML offrent différentes vues d’un
même modèle
 Certains diagrammes sont complémentaires, d’autres
non
 Certains diagrammes sont très abstrait, d’autres non
 Il est nécessaire de définir une organisation entre les
diagrammes (Une méthode)
Objectif: Gagner du temps

La méthode IL (pédagogique)
1. Cahier des charges
2. Analyse (Quoi ?)
 Identifier les Actors et les Use Case
 1 Diagramme de Séquence / Use Case
 Diagramme de Classe
3. Conception (Comment ?)
 Diagramme de Séquence
 Diagramme de Classe
Exemple: Mini Bibliothèque
 Le système doit permettre aux abonnés
d’emprunter des livres.
 L’inscription est annuelle.
 Une personne non abonnée ne peut pas
emprunter de livres.
Use Case Diagram
M agisterTest1
S'Abonner
Personne
Vérifier les empruns
Emprunter Un Livre <<include>>

<<include>>
<<include>> Authentifier
Se désabonner
Abonné
Sequence Diagram
System:
Instance1:Abonné
chercher le livre
authentification
emprunter
vérifier les empruns
Class Diagram
Bibliothèque références Livre

0..1 *
0..1 1
* exemplaires
Exemplaire
*
Conception = Comment ?
 On considère souvent que la conception
doit être un raffinement de l’analyse.
L’idée est que l’on doit facilement tracer
les liens entre classes d’analyse et
classes de conception
 Les classes de conception serviront à la
génération du code
Objecteering UML Modeler
 Atelier UML
 Tout les diagrammes UML1.4
 Module de production
 Génération Java, C++, C#
 Génération de Documentation
 Génération SQL
 Génération IDL, EJB,
…
Modèle vs Diagramme
M agisterTest1
S'Abonner
Personne
Vérifier les empruns
Emprunter Un Livre <<include>>

<<include>>
<<include>> Authentifier
Se désabonner
Abonné
Base contenant tous les

éléments du modèle
Créer un nouveau projet
Editeur de modèles
Vue hierarchique
de tous les
éléments du
modèle.
Vue de tous les

diagrammes du
modèle.
Vue graphique
d’un diagramme.
Console.
Module de Production
JavaModule
Objecteering Java
Configuration des
module de production
Utilisation du module
Java
Opération sur les
modèles
Profil et Module Objecteering

Le Langage J
Outils Objecteering
 UML Modeler
 Edition de modèle UML
 Utilisation de module Objecteering
 UML Profil Builder
 Création de module Objecteering
Codage des production
Règles d'implémentation
(langage J)
Expert Informaticien
Transformation
de modèle - Profile UML
Expert du domaine Modélisation du problème Modélisation de l'implémentation
Profile Builder
 PAR LES MENUS :
 Programmes\Objecteering\Objecteering UML
Profile Builder
Création d’un projet de profil
1) cliquer dans l’icône
« new »
ou l’item « new »
Du menu File
3’) ou par
navigation
2) Renseigner le
nom du projet
3) saisir sa
localisation
Fenêtre Principale
Barre de menus
Barre de raccourcis des menus

Navigateur
Boîte de propriétés
Console
Barre de status
Création d’un profil
3) cliquer sur le bouton
« Créer un profil fils » 1) Expanser
le profil « default »
2) Expanser
le profil « external »
4) Donner le nom du
nouveau profile (ex:
Scan)
Référencement au concept UML
 Le code J s’attache sur les concepts UML!
1) Sélectionner le nouveau profil
2) Cliquer sur l'icône « Créer

une référence de méta-classe »
3) Sélectionner « Class »
dans la liste déroulante
Création d’un opération J (1)
1) Sélectionner la méta-classe
2) Cliquer sur l'icône
« Ajouter une opération J »
3) Donner le nom
de la nouvelle opération
(ex: AfficherStatus)
Création d’un opération J (2)
1) Double-cliquer sur l ’opération
2) Modifier les caractéristiques

de l ’opération
Saisie d’une opération J (1)
1) Sélectionner l'opération
3) Double cliquer sur l'icône « Jcode »
2) Sélectionner l‘onglet « items » de la boite de propriétés

Saisie d’une opération J (2)
Saisir le code
StdOut.write("La classe <",Name,"> a pour visibilité " , Visibility);
Création d’un module
1) Sélectionner le projet
2) Cliquer sur l'icône

« Créer un module »
Caractéristiques d’un module
1) Saisir le nom MonModule
2) Saisir le libellé Mon Premier Module
3) Saisir la version
4) Éventuellement un commentaire
de la release
5) Éventuellement la compatibilité
Avec une autre version
Lien avec les profils (1)
1) Sélectionner le module
2) Cliquer sur l ’icône
« Référencer le profile UML »
3) Rechercher tous les profiles disponibles
Cours de Hatem Ben Sta Lille Mars 2008

X. Blanc – Université Paris 6
4) sélectionner le(s) profile(s) et valider
Lien avec les profils (2)
Créer une commande
1) Sélectionner le module
2) Cliquer sur
l'icône « Créer
une Commande »
3) Remplir les propriétés

de la commande
•Profile
•Méthode
Cours de Hatem Ben Sta Lille Mars 2008 J X. Blanc – Université Paris 6
Créer un projet un Test
1) cliquer sur le Menu « Test »
puis « Create a test project »
2) Entrer le nom du projet de test
3) Cliquer sur « OK »
Tester la commande
1) Sélectionner une classe
puis faire « clic droit »
2) Vérifier le résultat dans la console
Pourquoi packager un module ?
 OBJECTIF :
 PERMETTRE L’INSTALLATION DU MODULE SUR LES
BASES DU SITE
 AVOIR LE MODULE SOUS FORMAT FICHIER (.prof) POUR
L’ECHANGER
 LE PACKAGING D’UN MODULE PEUT CONTENIR :
 RESSOURCES : ICÔNES DE STÉRÉOTYPES, DE PRODUITS
DE GÉNÉRATION, …
 FICHIERS : TRADUCTION DES MESSAGES, DTD XMI, …
 BINAIRES ET SCRIPTS : EXÉCUTABLES DÉCLENCHÉS
DEPUIS DES MÉTHODES J POUR TOUS TYPES DE
TRAITEMENTS : parsers, wizards, …
Packager (1)
Packager (2)
Lieu de stockage physique
du module packagé
Code en mode read only

Versions majeure et
mineure du module XXXXXXX
Release du module
Ressources liées aux modules
Manque le fichier de traduction des messages
Manque la documentation du module

Packager (3)
Module packagé
Répertoire des
Ressources du
module
Un répertoire pour
Chaque version
Livraison d’un module
 Double clic sur le fichier .prof
 Résultat dans fenêtre DOS
Selection d’un module
1) Lancer Objecteering
2) Menu « Tools » item « modules »
3) Sélectionner le module 4) Ajouter
5) Valider
Le langage J
 LE LANGAGE J EST LE LANGAGE SUPPORT
DE OBJECTEERING / UML PROFILE
BUILDER.
 IL PERMET :
 DE PILOTER ET DE PARAMÉTRER L'OUTIL
OBJECTEERING,
 DE PARTICULARISER LES GÉNÉRATEURS
EXISTANTS,
 D'ÉCRIRE DE NOUVEAUX GÉNÉRATEURS.
J EST UN LANGAGE OBJET DÉDIÉ À LA

MANIPULATION DE MODÈLES.
Les classes de J
 Classes « mères » (Object, MetaClass, …)
 Classes de base (int, float, boolean, String,
enumerate)
 Classes entrée/sortie (stream, outStream,
inStream)
 Classes des concepts UML (Class, Attribute,
Operation, ...)
Les classes « Mères »
 La classe « Object »
Object
 Toutes les classes du langage J héritent de la classe « Object »
 Elle définit deux opérateurs : == (égalité) et != (différent)
 La classe « Object [ ] »

]
 La classe Object[] représente un ensemble d’objets.
 Elle définit un constructeur « [] » qui est défini sur toutes les
classes de J.
 ex: Attribute [ ], String [ ], …
Classes de Base
« int »
 GÈRE LES ENTIERS.
 LES OPÉRATEURS :
 < « inférieur »
 <= « inférieur ou égal »
 > « supérieur »
 >= « supérieur ou égal »
 + « addition »
 - « soustraction »
 * « multiplication »
 / « division »
 % « modulo » (reste de le division entière)
 LES MÉTHODES :
 float toFloat() conversion en « float »
 String toString() conversion en « String »
Classes de Base
« String »
 GÈRE LES CHAÎNES DE CARACTÈRES.
 LES OPÉRATEURS :
 < « inférieur »
 <= « inférieur ou égal »
 > « supérieur »
 >= « supérieur ou égal »
 + « concaténation »
 LES MÉTHODES :
 int size() : renvoie la taille de la chaîne
 substitute (in String ToSubstitute, in String NewValue) : remplace toutes les occurrences
de « ToSubstitute » par « NewValue »
 toUpper() : conversion en majuscule
 toLower() : conversion en minuscule
 int findFirst (in String Pattern, in int StartIndex) : renvoie la position de la première
occurrence de « Pattern » à partir de « StartIndex » ou -1 si « Pattern » n’est pas trouvé
Les Classes« entrée/sortie » (1)
 « stream » (stream, outStream, inStream) : utilisée pour gérer les
entrée/sorties.
 trois instances prédéfinies de outStream pour les sorties standards :
stdOut, stdErr, stdFile.
La Classe Stream n’offre pas de service
La Classe OutStream
 représente le flux de sortie
 boolean open(in String FileName) : ouvre le fichier « FileName » en
écriture
 write (in basic_class p1, in basic_class p2, ...) : écrit dans le fichier
la liste des valeurs passées en paramètres
 close () : ferme le fichier
 existFile (in String FileName, out boolean answer)
Les Classes« entrée/sortie » (2)
La Classe InStream
 représente le flux d’entrée
 boolean open(in String FileName) : ouvre le
fichier « FileName » en lecture
 read (in String buffer) : lit « buffer » dans le
fichier
 close () : ferme le fichier
 existFile (in String FileName, out boolean
answer) : teste l’existence du fichier
Les Classes de concepts UML
 J permet d’accéder à toutes les
informations de tout élément du modèle
 Classe:
 Name, Visibility, …
 PartAttribute, PartOperation
Les opérations J
 L’appel d’une opération se fait avec le
symbole « . »
 Ex: StdOut.write
 Possibilité de diffuser une opération sur un
ensemble
 Ex: ParOperation.<write()
 Polymorphisme supporté
Méthodes anonymes
Concaténation de tous les attributs d'une
classe dans une chaîne de caractères.
Class:printAttribute ( ) {
String line;
PartAttribute // diffusion aux attributs
{ // début de la méthode anonyme
// nous sommes ici dans un contexte d’ « Attribute »
String buffer = "," + Name; // variable locale
line = line + buffer; // accès à une variable englobante
} // fin de la méthode anonyme
// de retour dans un contexte de « Class »

StdOut.write("the ", Name, " class's attributes are ", line, NL);
}
Les ensembles (1)
 FACILITER LA NAVIGATION DANS UN MODÈLE
 les classes d’un package
 les méthodes d’une classe
 les paramètres d’une méthode
 …
 NOTATION
Les ensembles sont définis par la classe « class of the elements [
] », telle que Object[], String[], Class[], etc.
 DÉCLARATION
La déclaration suivante, permet d'obtenir un ensemble vide
d'objets « Object » :
Object[] E;
Les ensembles (2)
 ORDRE DES ÉLÉMENTS
 Les ensembles sont ordonnés.
 L'ordre d'insertion des éléments dans l'ensemble sera l'ordre de parcours de ces
éléments lors d'une diffusion ou de l'application de méthodes anonymes.
 Par exemple, l'ordre des méthodes d'une classe est accédé dans l'objet
« PartOperation » dans l'ordre où celles-ci apparaissent dans le modèle, de
même que pour les paramètres d'une méthode (IOParameter), …
 AFFECTATION ENTRES ENSEMBLES
 Les ensembles sont considérés comme des classes de base.
 L'affectation entre ensembles recopie donc la valeur d'un ensemble dans un
autre ensemble.
 ENSEMBLE VIDE
 Le service « notVoid » permet de tester si un ensemble est vide ou pas.
If (notVoid (mySet)) // ensemble non vide
else // ensemble vide
Les ensembles (3)
 ACCÈS AU IÈME ÉLÉMENT
J n’autorise pas les instructions du type « E[i]=V; » ou
« v=E[i]; ».
 Les services suivants doivent êtres utilisés :
 Object:getItemSet (inObject[] pSet, in int pIndex, out Object

pElt) : Renvoie dans l’objet « pElt » le « pIndex » ième élément de l’ensemble
« pSet » .
 Le 1er élément a l’index 0.
 Les types de « pSet » et « pElt » peuvent être plus précis (String[] and String
par exemple)
 Object:setItemSet (inout Object[] pSet, in int pIndex, in Object
pElt) : Remplace le « pIndex » ième élément de l’ensemble « pSet » par l’objet
« pElt ».
Les ensembles (4)
 « size » : renvoie le nombre d’éléments de l’ensemble
Exemple :
PartAttribute .size(); // ou PartAttribute .length();
 « addElement »
addElement : ajoute un élément dans l’ensemble
Exemple :
PartOperation.<select(Visibility == Public) { E.addElement (this); }
 add : concatène deux ensembles

« add »
Exemple :
E1.add(E2); // les éléments de E2 sont ajoutés à la fin de E1
 « retract »
retract : retire le dernier élément d’un ensemble
Exemple :
E1.retract(); // le dernier élément est enlevé de l’ensemble
« select » sur les ensembles
 « select »
select
 Faire une sélection sur les occurrences d'un ensemble, selon
l'expression booléenne fournie en paramètre.
 Le résultat est un sous-ensemble de l'ensemble initial.
 Sur ce résultat, il est possible d'appliquer soit une méthode
anonyme, soit un nouveau "select", soit une diffusion
3 exemples équivalents :
PartOperation.<select(Visibility == Public) { display (); }//1: méthode Anonyme
PartOperation.<select(Visibility == Public).<display ();//2: diffusion de display()
Operation [] E = PartOperation.<select(Visibility == Public);

E.<display(); //3: variable intermédiaire
« while » sur les ensembles
 « while »
while :
 arrêter la scrutation d'un ensemble, lorsqu'une certaine condition
est atteinte.
 parcourt toutes les occurrences jusqu'à obtention de la condition
d'arrêt de scrutation.
Ces 2 exemples sont équivalents :
PartAttribute.<while(Name != "Size") { StdOut.write(Name); }
boolean found;
PartAttribute.<while(found) {
found = Name == "Size";
if (not(found) ) { StdOut.write(Name); }
}
Structure de contrôle (1)
 « If »
If
if (condition1) { // instructions }
if (condition1) {// instructions } else { // instructions }
if (condition1) { // instructions } else if (condition2) { //

instructions } else { // instructions }
Service « eval »
 PERMET D'ÉVALUER DYNAMIQUEMENT UNE CHAÎNE DE
CARACTÈRES, EN CONSIDÉRANT QUE SON CONTENU EST
COMPOSÉ D'INSTRUCTIONS J.
Exemple :
Object:Storage() {
Fic.open ("Example");
Fic.write ("i1 = 15; s1 = "hello"; b1=false");
}
Object:Recover() {
String read_buffer;
outStream Fic;
int i1 = 15;
String s1 = "hello";
boolean b1 = false;
Fic.open ("Example");
Fic.read (read_buffer);
eval (read_buffer);
StdOut.write ("i1=", i1, NL, "s1=", s1, NL "b1=", b1, NL);
}
A vous de jouer
 Faire un mini
générateur de code (un
fichier par classe avec
« public class » Name?
Bilan
 J permet de créer des opérations sur les
Modèles UML
 J permet de rendre les profils UML productifs
 Puissance importante que l’on aimerait avoir en
dehors de UML
 Il est intéressant de sortir du domaine UML
 => Ouverture vers les profiles UML
Profile UML
 Un profile UML permet d’étendre la
sémantique de UML
 Ex : Table RDB plutôt que classe UML
<<table>>
Repertoire
Repertoire
Transformation vers Profile
Personne
Repertoire
{persistence(persistent)}
{persistence(persistent)} repertoire personnes
name : undefined Contient
id : string Contient * firstName : undefined
id : string
{primaryKey(1)}
{primaryKey(1)}
* personne repertoire_of_Contient_FK personnes_of_Contient_FK

habite
0..1 adresse
Adresse
{persistence(persistent)} Repertoire Personne
rue : string
num : integer
ville : string adresse_of_Personne_FK
pays : string
id : string
{primaryKey(1)}
Adresse
Profile UML
 LES STÉRÉOTYPES :
 Ajout de nouveaux éléments de modélisation dans le contexte métier ou
technique
 Exemples : « interface », « entity_bean », …
 Il est possible de stéréotyper tout concept UML (Classe, Attribut,
Association, Use Case)
 LES TAGGED VALUES :
 Annotation des éléments de modélisation
 Exemples : {virtual}, {primary key}, …
 Il est possible d’associer des tagged values à tout concept UML
(Classe, Attribut, Association, Use Case)
 LES CONTRAINTES :
 Préciser les conditions d’emploi des éléments du modèle
 Exemples : {disjoint}, {age >= 18}, …
 Il est possible d’associer des contrainte à tout concept UML (Classe,
Attribut, Association, Use Case)
Exemple Profile
 SQL
 Stereotype
 Table, ForeignKey, PrimayKey
 Contrainte
 Une table ne peut avoir deux PrimaryKey, …
 EJB
 Stereotype
 EJBBean, EJBHomeInterface, …
 Tagged-Value
 Type de l’EJBBean (entity, session)
 Contrainte
 Un EJBBean doit avoir une EJBHomeInterface
Objecteering et les Profiles
 Il est possible de créer des stereoypes,
des tagged value, des contraintes dans un
profil Objecteering
 Il est en J possible de connaître les
stereotypes ou tagged value portés par un
élément (ainsi on peut bénéficier de ces
informations pour être productif)
A vous de jouer
 Construisons un profil
pour modéliser les
LAN?
Modèles et méta-
modèles
MOF
JMI & XMI
UML et Profil
 UML permet de modéliser les applications
Orientées Objet
 Grâce aux profils, il est possible de modéliser
autre chose que des applications orientées objet
(Ex: SQL)
 Cependant, un modèle profilé est toujours un
modèle UML!!!
 Sémantique OO sous-jacente (classes, héritage,
instance, …)
 Manque de liberté
Objectif
 Il serait intéressant de disposer d’autres
langages spécifiques à certains domaines tout
en ayant la même productivité que celle des
modèles UML
 Langage pour modéliser les échanges entre
applications
 Langage pour modéliser les processus
 Langage pour modéliser les éxigences
 Langage pour modéliser les flux bancaires
…
 Question ouverte : est-ce que les profils sont si
contraingnants ?
L’approche modèle de modèles
 Seriez-vous capable de
construire le diagramme
de classes expliquant les
concepts d’un diagramme
de Use Case?
 Seriez-vous capable de
construire le diagramme
de classes d’un
diagramme de classe ?
Modèles et méta-modèles
 Un méta-modèle est une sorte de
diagramme de classes qui définit la
structure d’un ensemble de modèles
 Un méta-modèle est un formalisme
(langage) permettant d’élaborer des
modèles
 Méta-modèle = grammaire
 Modèle = phrase
Le méta-modèle UML Objecteering (1)
Le méta-modèle standard UML 1.4
L’approche modèle de modèles de
modèles
 Seriez-vous capable
de construire le
diagramme de
classes expliquant les
concepts des méta-
modèles?
Méta-modèles et méta-méta-modèle
 Un méta-méta-modèle est une sorte de
diagramme de classes qui définit la
structure d’un ensemble de méta-modèles
 Un méta-méta-modèle est un formalisme
(langage) permettant d’élaborer des
formalismes (langage)
 Méta-méta-modèle = grammaire de
grammaire
 Méta-Modèle = grammaire
Le MOF (Meta Object Facility)
 Le standard MOF est le seul méta-méta-
modèle défini par l’OMG
 Il définit les concepts nécessaires et
suffisants pour élaborer des méta-modèles
Le MOF Méta-meta-modèle /DependsOn
+dependent
0..n
{ordered}
+provider ModelElement
0..n name : String
/ qualifiedName : String
annotation : String
<<reference>> requiredElements : ModelElement
...
{ordered} 0..n <<reference>> container : Namespace
<<reference>> constraints : Constraint
+containedElement
findRequiredElements()
isRequiredBecause()
isFrozen()
isVisible()
Contains
Namespace
<<reference>> contents : ModelElement
...
0..1 lookupElement()
resolveQualifiedName()
+container findElementsByType()
nameIsValid()
+supertype
{ordered} 0..n
Generalizes GeneralizableElement
isRoot : Boolean
isLeaf : Boolean
+subtype isAbstract : Boolean
visibility : VisibilityKind
0..n <<reference>> supertypes : GeneralizableElement
allSupertypes()
lookupElementExtended()
findElementsByTypeExtended()
IsOfType TypedElement
Classifier 1..1 0..n
<<reference>> type : Classifier
+type +typedElements
Le MOF Méta-meta-modèle
Generalizes
+supertype
{ordered} 0..n
GeneralizableElement
isRoot : Boolean
isLeaf : Boolean
+subtype
isAbstract : Boolean
0..n visibility : VisibilityKind
<<reference>> supertypes : GeneralizableElement
allSupertypes()
lookupElementExtended()
findElementsByTypeExtended()
Classifier +type +typedElements TypedElement
1..1 IsOfType 0..n <<reference>> type : Classifier
Class Association DataType

isSingleton : Boolean isDerived : Boolean
ModelElement
Feature TypedElement
Namespace
GeneralizableElement StructuralFeature
AssociationEnd
isNavigable : Boolean
aggregation : AggregationKind
multiplicity : MultiplicityType
RefersTo +referencedEnd isChangeable : Boolean
Classifier
1..1 otherEnd()
+referent 1..1
0..n +exposedEnd
Association Reference
+referrer /Exposes
isDerived : Boolean <<reference>> exposedEnd : AssociationEnd
<<reference>> referencedEnd : AssociationEnd
0..n
ModelElement
Feature
Namespace scope : ScopeKind TypedElement
visibility : VisibilityKind
StructuralFeature
BehavioralFeature
...
isChangeable : Boolean
Operation +operation +except Exception Attribute Reference

isQuery : Boolean isDerived : Boolean <<reference>> exposedEnd : AssociationEnd
CanRaise 0..n
<<reference>> exceptions : Exception 0..n <<reference>> referencedEnd : AssociationEnd
{ordered}
TypedElement
Classifier +type +typedElements
<<reference>> type : Classifier
1..1 IsOfType 0..n
DataType Structure
Field
PrimitiveType StructureType EnumerationType AliasType CollectionType

labels : String multiplicity : MultiplicityType
<<primitive>> <<primitive>> <<primitive>>

Boolean String Integer
(from PrimitiveT ypes) (from PrimitiveT ypes) (from PrimitiveT ypes)
Contained in
Constraint
<<enumeration>> <<enumeration>> <<enumeration>> <<enumeration>> <<enumeration>>

VisibilityKind DirectionKind ScopeKind AggregationKind EvaluationKind
public_vis in_dir instance_level none immediate
protected_vis out_dir class_level shared deferred
private_vis inout_dir composite
return_dir
<<structure>>
MultiplicityType
lower : Integer
upper : Integer
isOrdered : Boolean
isUnique : Boolean
AttachesTo
+modelElement
ModelElement 1..*
1..* +constrainedElement Constrains
0..n
{ordered}
+tag
Constraint TypedElement
Tag
expression : String <<reference>> type : Classifier
tagId : String
language : String +constraint
values : String
evaluationPolicy : EvaluationKind
<<reference>> elements : ModelElement
<<reference>> constrainedElements : ModelElement 0..n
Constant Parameter
value : String direction : DirectionKind
modèles
 Quel est le méta du
MOF?
Architecture à 4 Niveaux
Méta-méta-modèle
MOF
UML SPEM CWM … méta-modèles
Modèle Modèle Modèle modèles

Modèle Modèle Modèle
Modèle Modèle Modèle
UML SPEM CWM
Monde Réel
modèles
 Faire le méta-modèle
pour les LAN?
Statuts des Modèles
 Un modèle est une entité abstraite
 Un modèle est structuré par son méta-modèle
 Un méta-modèle est une entité abstraite
 Un méta-modèle est structuré par le MOF
 Le MOF est une entité abstraite!
 Pour manipuler les (méta*)modèles il faut donc

les représenter sous format informatique
Représentation concrète de modèles
 Textuelle
 Représenter un modèle sous forme de texte
 Objet
 Représenter un modèle sous forme d’objets
 Graphique
 Représenter un modèle sous forme de fichier
SVG (réduction à la représentation textuelle)
Représentation des modèles en XML
 Le standard XMI (XML Metadata
Interchange) permet le passage des
modèles aux documents XML
 Il définit des règles permettant de
construire des schéma XML à partir de
méta-modèle
 Ainsi il est possible d’encoder un modèle
dans un document XML
La passerelle OMG : XMI
XMI dans la pratique
 Tout package va donner la définition d’un
élément
 Toute classe va donner la définition d’un
élément
 Contenu dans un package
 Toute association va donner la définition
d’un élément
 Contenu dans la classe
 …
XMI pour UML
 XMI a été utilisé sur UML pour construire
le Schéma XML des modèles UML
UML dans un document XML
 Les règles XMI peuvent quasiment

s’appliquer sur les diagramme de classe
UML
Représentation des modèles en Objets
 Le standard JMI permet le passage des
modèles aux objets Java
 Il définit des règles permettant de
construire des interfaces Java à partir de
méta-modèle
sous forme d’objet Java
JMI
Méta-modèle Interface Java
modèles Objets Java
JMI dans la pratique
 Tout package va donner la définition d’un
package
 Toute classe va donner la définition d’une
interface
 Contenu dans un package
 Toute association va donner la définition
d’une interface
 Contenu dans la classe
 …
Tester les prototypes
 http://modfact.lip6.fr
L’approche MDA
PIM, PSM, Code

Transformation de modèles
Interopérabilité de modèles
Problème ?
 RPC, DCE, CORBA, DCOM, EJB, .Net, Web
Service, …
 Evolution sans fin des middleware. Les entreprises
subissent ces changements en terme de coût mais
bénéficient de nouveaux avantages.
 « Over the past decade or more, companies have
endured a succession of middleware platforms. »
Jon Siegel, OMG Director of Technology Transfer
Pourquoi c’est un problème ?
 Quelques soient le middleware, la
méthode et les techniques utilisés
(patterns, framework, …); le code métier
est toujours, d’une manière ou d’une
autre, liés à la technique.
 L’évolution est alors problématique car il
faut distinguer le code métier (à préserver)
du code technique (à jeter).
Une Solution
 La solution n’est pas nouvelle : séparation
des préoccupations.
 Il faut séparer la partie métier de la partie
technique.
 Il faut donc s’abstraire de la technique (et
du code)
 Il faut donc modéliser et surtout faire que
le modèle soit productif (!= contemplatif)
Pourquoi cette solution est bonne
 Rien ne permet d’affirmer à 100% que cette solution est
la bonne !
 La pérennité des modèles est meilleure que la pérennité
du code
 la réutilisation du code ne marche pas en terme de coût
 Les techniques de génération de code commencent à
être productives
 parallèle avec C et assembleur
 Les techniques de modélisation sont industrielles (UML)
L’approche MDA
 Elaborer des modèles métiers (PIM) puis les
transformer en modèles techniques (PSM) afin
de pouvoir facilement générer du code.
 La transformation des PIMs en PSMs devra, à
long terme, être entièrement automatique et
réversible.
 La transformation des PSMs devra, à court
terme, être entièrement automatique, réversible
et paramétrable.
PIM vers PSM
Business
requirements
Standards supporting MDA
Analysis & design
standardized PIM Standards for

PIM application areas
standardized
mapping to PSMs
Modification for each required platform
PSM notation
PSM PSM PSM ... Standards for
platforms
Mapping to implementation standardized mapping

to implementation codes
Implemen- Implemen- Implemen-

tation tation tation ・・・
Concepts
 PIM (Plateform Independent Model) : Un PIM est un
modèle métier entièrement indépendant d’une plate-
forme technique. Par exemple, un modèle UML sans
aucun stéréotype est un PIM. Les PIM sont pérenne,
leur durée de vie doit dépasser 10 ans.
 PSM (Plateform Specific Model) : Un PSM est un
modèle lié fortement à une plate-forme technique. Par
exemple, un modèle UML stéréotypé EJB est un PSM.
Les PSMs doivent être générés à partir de PIMs. Ils ne
sont pas pérennes.
Les standards
 MOF (Méta Object Facility) : Langage de définition de
méta-modèles. Règles de mapping vers IDL CORBA
pour permettre la construction de référentiels de
modèles.
 UML (Unified Modeling Language) : Langage de
définition de modèle d’application OO. Largement utilisé,
outillé, connu.
 XMI (XML Metadata Interchange) : Règles permettant de
représenter tout modèle sous format XML.
 JMI : Règles permettant de représenter tout modèle
sous format Java.
 CWM (Common Warehouse Metamodel) : Langage de
définition de modèle de data warehouse.
Des Challenges
 Relations Modèles, Méta-modèles, Méta-
méta-modèle, …
 Transformations de modèles
 Définition de Plates-formes standards
 Méthode MDA (Cycle en Y ?)
 Stratégie
 Evangélisation
! Plan d’actions orienté utilisateur
Un chantier commence
 Le MDA est un chantier qui commence. Il
devrait durer environ 10 ans (ou plus)
 A l’heure actuelle
 UML 2.0
 MOF 2.0
 XMI 2.0
 MOF 2.0 Q/V/T
MOF 2.0 Q/V/T
 Méta-modèle pour la transformation de
modèles
 Appel de proposition de standard
 Huit propositions initiales
Méta-modèle Méta-modèle Méta-modèle

d’entrée MOF2.0 de sortie
(ex : UML) Q/V/T (ex : Java)
Un modèle de
transformation
Un modèle (ex : UML2Java) Un modèle
(ex : Mon (ex : Mon
modèle UML) Exécution modèle Java)
Intéropérabilité
 Considérer les services de modélisation
 Une transformation est un service de
modélisation au même titre que l’exécution de
modèles ou la génération de tests
 Interopérabilité de service
 Proposition de ModelBus
 Redaction d’un RFP en cours
Bilan
Que faut-il retenir ?
Résumé
 Le code n’est que le langage de la machine
 La construction et la maintenance d’applications nécessitent
d’autres langage (différents niveaux d’abstraction, différents
intervenants)
 L’ingénierie des modèles consiste à définir les techniques
nécessaires à la définition et à la mise en production de ces
différents langages
 UML est un langage de modélisation qui entre intégralement dans
l’ingénierie des modèles (c’est même le langage précurseur)
 Il est important de savoir maitriser la diversité des langages de
modélisation
 Il est plus qu’important de rendre ces langages de modélisation
produtifs
Recherche
 Les transformations de modèles
 Des opérations sur les modèles
 Vérification de contraintes
 Exécution / Simulation de modèles
 Interopérabilité des opérations
 Les aspects méthodologiques
 Le déploiement d’application dirigé par les modèles
 Le passage du code aux modèles (Reverse Engineering,
ADM)
 La génération automatique de code
 …
Merci
 N’hésitez pas à me contacter
 Xavier Blanc
 Xavier.Blanc@lip6.fr
 http://modfact.lip6.fr
 http://meta.lip6.fr

1287779617xb Model Engineering

Transféré par

Droits d'auteur :

Formats disponibles

Vous aimerez peut-être aussi

1287779617xb Model Engineering

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1287779617xb Model Engineering

Transféré par

Droits d'auteur :

Formats disponibles

Ingénierie des

Etude d’une application Java

Vision Schématique Abstraite

Vision Schématique Abstraite

public static void main(String[] args) {

Vision Schématique Abstraite

UIPersonne Personne Adresses

Etude d’une application WS

Des Méthodes de modélisation

UML 1.2 Juin 1998

OOPSLA’95 Méthode unifiée 0.8 Octobre 1995

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

Company +name : string

url [3] : string

Un étudiant suit des

Diagramme de Classe - Fin

Notation & Méthode

UML pour construire

Des portes AND, OR, NOR, … UML

Le composant électrique Le programme informatique

Place order <<include>>

<<extend>> Check Password

Objectif: Gagner du temps

Emprunter Un Livre <<include>>

Bibliothèque références Livre

Emprunter Un Livre <<include>>

Base contenant tous les

Vue de tous les

Profil et Module Objecteering

Barre de raccourcis des menus

2) Cliquer sur l'icône « Créer

2) Modifier les caractéristiques

3) Double cliquer sur l'icône « Jcode »

2) Sélectionner l‘onglet « items » de la boite de propriétés

StdOut.write("La classe <",Name,"> a pour visibilité " , Visibility);

2) Cliquer sur l'icône

1) Saisir le nom MonModule

2) Saisir le libellé Mon Premier Module

3) Rechercher tous les profiles disponibles

Cours de Hatem Ben Sta Lille Mars 2008

3) Remplir les propriétés

2) Entrer le nom du projet de test

3) Cliquer sur « OK »

2) Vérifier le résultat dans la console

Code en mode read only

Manque le fichier de traduction des messages

Manque la documentation du module

2) Menu « Tools » item « modules »

3) Sélectionner le module 4) Ajouter

J EST UN LANGAGE OBJET DÉDIÉ À LA

 La classe « Object [ ] »

La Classe Stream n’offre pas de service

// de retour dans un contexte de « Class »

 Object:getItemSet (inObject[] pSet, in int pIndex, out Object

 add : concatène deux ensembles

PartOperation.<select(Visibility == Public).<display ();//2: diffusion de display()

Operation [] E = PartOperation.<select(Visibility == Public);

Ces 2 exemples sont équivalents :

PartAttribute.<while(Name != "Size") { StdOut.write(Name); }