2.4.3 Caractéristiques comportementales
En plus de leurs caractéristiques structurelles, ECore
peut modéliser les caractéristiques comportementales d'un EClass
comme « EOperation ». Un modèle de base ne donne aucune
indication sur le comportement réel des opérations. Les corps des
opérations doivent être codés à la main dans les
classes Java générées.
page 32
2.4 Le Méta-modèle ECore
EOperation et EParameter illustré dans la Figure 2.7.
FIGURE 2.7 - Concept EOperation et
EParameter
La relation « eOperations » avec EClass est tout
à fait semblable à ceux de « eAttributes » et «
eReferences ».
EOperations sont contenus par un EClass via la
référence de « eOperations », et une
référence de « eAllOperations » est définie pour
inclure les opérations d'une classe et ses supertypes. Aussi EOperation
fait partie d'une association bidirectionnelle, ce qui permet une EOperation
d'obtenir facilement Eclass qui contient via la référence en face
« eContai-ningClass ».
Un EOperation contient zéro ou plusieurs EParameter,
accessibles via « eParameters », qui modélisent les
paramètres d'entrée de l'opération, cette
référence constitue la moitié d'une association
bidirectionnelle; les EParameters peuvent accéder au « EOperation
» auquel ils appartiennent via « eOperation ».
Les deux EOperation et EParameter héritent de
l'attribut « name » et la référence « eType »
de « ETypedElement ». Ces références de « eType
» modélisent le type de retour de l'opération et le type de
paramètre, et peuvent se référer à tout EClassifier
(si EClass ou EDataType).
Enfin, EOperation définit une référence
supplémentaire « eExceptions » à zéro ou
plusieurs EClassifiers.
page 33
2.4 Le Méta-modèle ECore
2.4.4 Classificateurs
Après avoir présenté les
caractéristiques structurelles et comportementales d'ECore, nous allons
maintenant revenir et prendre un regard détaillé sur les classes.
Comme nous l'avons déjà vu, EClass partage une classe de base
avec EDataType, donc nous allons devoir discuter les deux ensembles.
Cette classe de base « EClassifier » agit comme un
objectif commun pour la référence « eType » de
ETypedElement, permettant de spécifier les types de
caractéristiques structurelles, des opérations et des
paramètres, soit des classes ou des types de donnés. Comme la
montre la Figure 2.8
FIGURE 2.8 - Concept EClassifier
EClassifier contribue un certain nombre d'attributs et des
opérations. Aussi, il hérite d'un
attribut name d'ENamedElement. 2.4.4.1 Les
classes
Les aspects uniques de « Eclass » sont illustrés
à la Figure 2.9.
page 34
2.4 Le Méta-modèle ECore
FIGURE 2.9 - Concept EClass
Nous avons déjà discuté les relations
entre EClass et les classes qui représentent les caractéristiques
structurelles et comportementales.
Nous avons vu la référence « eOperations
» de confinement et son contraire « eCon-tainingClass », qui
relient un EClass avec ses EOperations. Nous avons également vu «
eAttributes » et « eReferences », qui ne sont pas
bidirectionnel, mais de même connecter un EClass à ses EAttributes
et EReferences.
EClass définit également une
référence appelée « eAllStructuralFeatures » qui
regroupe les objets accessibles via « eAllAttributes » et «
eAllReferences », il comprend toutes les caractéristiques
structurelles définies et héritées par une classe.
Les deux attributs définis par EClass lui-même
peut être utilisé pour spécifier le type particulier de la
classe en cours de modélisation. Si l'interface est vraie, EClass
représente une interface, qui ne peut pas être instanciée.
Si abstraite est vrai, le EClass représente une classe abstraite,
à partir de laquelle d'autres classes peuvent hériter des
caractéristiques.
ECore comprend un certain nombre de classes abstraites, dont
la plupart nous l'avons déjà vu : ENamedElement, EClassifier,
ETypedElement et EStructuralFeature.
2.4.4.2 Types de données
Alors que les classes définissent plusieurs
caractéristiques structurelles et comportementales, les types de
données représentent un seul élément de
données «simples». Cette dis-
page 35
2.4 Le Méta-modèle ECore
tinction est assez similaire, mais pas identique, qu'entre les
classes et les types primitifs en Java.
En général, il est considéré comme
une mauvaise idée de représenter une classe Java très
complexe en tant que type de données. Au lieu de cela, il est
préférable de modéliser directement la classe EMF avec un
EClass et, par conséquent, de bénéficier de l'assistance
du cadre en matière de sérialisation, la notification et la
réflexion. En règle générale, si ses valeurs ne
peuvent pas être simplement représentées comme une
chaîne sans l'utilisation d'une notation d'imposer la structure, il ne
devrait probablement pas être modélisée comme un type de
données [4].
| 
