| Guide Utilisateur AROM v2.0 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Chapitre 4. Représentation des entités du système | Avance rapide | Suivant |
Nous avons vu que les structures AROM définissent des intentions. C'est à dire que chaque structure spécifie les propriétés qui la caractérisent au travers de slots. De plus les structures sont organisées hiérarchiquement et une structure hérite de l'intention définie par sa structure mère.
L'intention permet donc d'identifier les propriétés communes aux individus d'un même groupe, la structure. En parallèle, on définit l'extension d'une structure qui correspond à l'ensemble des individus qui appartiennent effectivement à la structure. Ces différents individus, les instances, doivent satisfaire les propriétés de l'intention afin d'appartenir à l'extension d'une structure mais l'inverse n'est pas nécessairement vrai. En effet, même si une entité satisfait les propriétés de l'intention d'une structure, elle ne fait pas pour autant partie de son extension, il faudra qu'elle ait été spécifiquement ajouté à cette extension.
Dans AROM, les structures se divisent en Classes et en Associations. Les instances représentent les individus des structures en général, les objets sont les instances des classes et les tuples représentent les instances des associations.
Un objet AROM est rattaché à une classe spécifique dont l'intention n'est définie qu'au travers de variables. Les objets AROM acceptent des valeurs pour ces variables. Ainsi, un objet qui appartient à une structure définit un ensemble de couples <variable/valeur>. Toutes les variables de la structure ne sont pas obligatoirement valuées mais elles doivent être reconnues. C'est à dire que l'objet doit pouvoir accepter à tout moment une valeur pour cette variable.
Comme nous l'avons vu dans les sections précédentes, les structures AROM sont des entités spécialisables. Aux vues des règles de spécialisation définies dans le modèle AROM, on peut dire que les objets d'une classe sont également objets de ses super-classes. Ainsi, dans l'exemple ci-dessous, les objets des classes Adulte et Enfant sont également des objets de la classe Personne.
On definit donc deux niveaux d'appartenance des instances aux structures, voir figure Extension d'une structure. En effet, l'extension de la classe Personne, dans l'exemple ci-dessous, est constitué de l'ensemble des instances qui lui sont propres ainsi que de l'ensemble des instances propres à chacune de ses sous-classes, Adulte et Enfant. Par instances propres à la structure, on entends instances qui sont directement rattachées à cette strutcure.
La migration permet de faire évoluer un objet AROM dans la hiérarchie des classes. Ainsi, on recherche la classe la plus spécialisée qui accepte l'objet dans son ensemble d'instances propres. Tout objet AROM devant appartenir à une structure, le changement de classe d'appartenance d'un objet sera effectué en une seule opération. Comme nous l'avons vu ci-dessus, pour qu'un objet soit accepté par une classe il faut qu'il satisfasse les propriétés de la nouvelle classe et notamment, qu'il accepte (ou puisse accepter) une valeur pour chacune des variables de cette classe.
Plus précisement, pour chacune des variables déjà connues de l'objet, il faut que la nouvelle classe définisse une variable:
ayant le même identifiant, c'est à dire le même nom.
ayant un CType compatible avec celui définit dans la structure de départ. Ceci est vrai si il est possible de déterminer un CType ancêtre commun à ces deux CTypes.
Néanmoins, la nouvelle classe peut définir de nouvelles variables qui ne seront pas valuées par l'objet.
On retrouve les même caractéristiques pour les tuples que celles décritent ci-dessus pour les objets. Par contre, l'intention des associations AROM est définie au travers de variables et de roles. Par conséquent, les tuples doivent non seulement définir des valeurs pour les variables, comme c'est le cas pour les objets AROM, mais ils doivent également référencer les objets pour les différents roles. En effet, les roles permettent d'identifier les classes qui sont mises en jeu dans une association donnée, les valeurs des roles sont donc des objets de ces classes. De plus, dans un tuple tous les roles doivent nécessairement être définis. Si l'on reprend l'exempele donné ci-dessus et que l'on considère l'association Parent reliant les classes Adulte et Enfant, les tuples de cette association devront définir un objet de la classe Adulte et un objet de la classe Enfant.