Catégorisation sur plusieurs niveaux de modélisation

Les deux concepts suivants permettent de catégoriser des éléments, sur plusieurs

niveaux de modélisation. Nous les présentons dans la suite sous forme de patrons

exprimés dans le formalisme P-Sigma.

a)Powertype

Le concept du Powertype a été introduit par (Odell, 1994) et repris par Brian

Henderson-Sellers dans de nombreux articles sur la modélisation de processus,

notamment (Henderson-Sellers et Gonzalez-Perez, 2005b).

Identifiant Powertype

Classification Générique ^ Produit

Contexte Ne nécessite aucun patron pour être appliqué.

Problème Ce patron supporte la spécialisation dynamique en permettant aux

sous-types d’une classe d’être définis comme des instances d’une

autre classe par rapport à un discriminant donné.

Force Il est possible de partitionner une classe en sous-classes en utilisant le

sous-typage. Avec cette approche, chaque sous-type est implémenté

comme une classe qui (i) doit être définie au moment de la

conception et (ii) ne peut pas porter d’attributs valués.

En définissant des sous-types comme des clabjects, les avantages des

sous-types en tant que classes sont maintenus et combinés avec les

avantages des sous-types en tant qu’objets, c'est-à-dire la capacité

d’être créés à l’exécution et de porter des attributs valués.

Solution

Modèle

La classe Powertype représente la classe qui permet de catégoriser les

éléments instances de la classe PartitionedType. Le Powertype est

représenté du côté du rond noir. Chaque sous-type introduit est

implémenté comme un clabject, qui incorpore une face objet

(instance du powertype) et une face classe (sous classe du type

partitionné). Dans le clabject (oval gris), le Powertype est instancié et

le PartitionedType est spécialisé. Seuls les attributs du Powertype

sont valués.

Au dernier niveau, la sous-classe Subclass est instanciée, les attributs

hérités de PartitionedType sont valués.

Les niveaux de modélisation M2, M1 et M0 sont positionnés

différemment par rapport aux exemples précédents : c’est ainsi que

(Gonzalez-Perez et Henderson-Sellers, 2006) les placent dans

l’architecture de l’OMG.

Cas

d’Application

Il est possible de distinguer les arbres (Tree) de leur espèce

(TreeSpecies). Le powertype TreeSpecies permet donc de partitionner

l’ensemble des arbres. TreeSpecies a un attribut name et Tree a un

attribut height.

Le powertype TreeSpecies est instancié dans le clabject. L’attribut

name est valué.

la sous-classe Sugar Maple (érable). Cette sous-classe est ensuite

instanciée pour représenter un érable Sm1 en particulier, qui fait une

hauteur de 8.1 pieds.

Conséquence

d’application

Avec ce patron, le sous-typage n’est plus limité au moment de la

conception. Les sous-types des classes peuvent être introduits

dynamiquement selon les besoins.

Alternative Materialization (Dahchour et al., 2002)

Tableau 2-3. Patron Powertype.

b)Materialization

Le patron Materialization a été introduit par (Dahchour et al., 2002).

Identifiant Materialization

Classification Générique ^ Produit

Contexte Ne nécessite aucun patron pour être appliqué.

Problème Ce patron permet de lier des classes d’éléments abstraits avec des

classes d’éléments plus concrets. Les éléments abstraits permettent de

catégoriser les éléments concrets.

Force Les avantages de ce patron sont :

– la séparation des classes d’éléments abstraits et des classes

d’éléments plus concrets.

– la propagation des attributs de la classe d’éléments abstraits

vers la classe d’éléments concrets.

Solution

Modèle

Le patron est composé de deux classes principales :

– AbstractClass qui correspond à la classe d’éléments les plus

abstraits et qui catégorise les éléments de ConcreteClass,

– ConcreteClass qui correspond à la classe d’éléments plus

concrets.

La classe la plus concrète est modélisée par l’étoile.

Différents types d’attributs sont définis dans la classe AbstractClass :

– attributeAC de type (T1) : cet attribut sera instancié et valué

dans la classe instance de Clabject, Instance, et propagé à la

sous-classe SubClass et à l’objet instance de SubClass.

– attributeAC2 (T2mono) est un attribut permettant de définir

un domaine de valeurs possibles dans l’objet instance

d’AbstractClass. L’attribut et son domaine sont propagés dans

Subclass. L’objet instance de Subclass aura pour propriété une

seule des valeurs définies dans le domaine (dans l’exemple ci

dessous « alt1 »).

– attributeAC2M de type (T2multi) a les mêmes caractéristiques

que le type T2mono à l’exception du fait que plusieurs valeurs

peuvent être choisies dans l’objet instance de Subclass (ici

« op1 » et « op2 »).

– attributeAC3 (T3inst) permet de générer 3 attributs

mono-valués dans la classe Subclass du Clabject. Ces attributs

seront instanciés par l’objet instance de Subclass.

La classe AbstractClass doit être systématiquement instanciée dans le

clabject. Ses attributs doivent être valués.

La classe ConcreteClass est systématiquement spécialisée dans le

clabject. Les attributs valués de l’objet du clabject Instance sont

propagés vers la sous-classe Subclass. Les attributs de type T3inst

sont propagés sous forme d’attributs mono-valués.

L’objet du dernier niveau InstanceSC est une instance de la

sous-classe Subclass. Tous les attributs sont valués, dont les attributs

hérités de ConcreteClass.

Cas

d’Application

La classe d’éléments abstraits CarModel permet de décrire n’importe

quel modèle de voiture. La classe d’éléments concrets Car permet de

décrire des exemplaires de voitures. Différents types d’attributs sont

déclarés dans la classe CarModel :

– name et stickerPrice sont des attributs classiques, instanciés

par l’objet FiatRetro.

– #doors et engineSize sont des attributs permettant de définir

des domaines de valeurs, ils sont propagés à la sous-classe

FiatRetro_Cars et sont instanciés par l’objet Nico’s Fiat. Une

seule des valeurs pourra être choisie pour valuer ces attributs.

– autoSound permet aussi de définir un domaine de valeurs,

mais plusieurs valeurs pourront être choisies pour valuer

l’attribut dans l’objet Nico’s Fiat.

– specialEquip permet de définir trois attributs dans la classe

FiatRetro_Cars qui seront instanciés dans l’objet Nico’s Fiat.

La classe CarModel est instanciée dans le clabject, avec l’objet

FiatRetro, qui représente toutes les propriétés possibles du modèle

Fiat Retro. La classe Car est spécialisée dans le clabject par la

sous-classe FiatRetro_Cars qui représente toutes les propriétés qu’aura

chaque voiture du modèle Fiat Retro.

Enfin, la classe FiatRetro_Cars est instanciée, pour créer l’objet

Nico’s Fiat, qui modélise la voiture Fiat Retro de Nico. Cette voiture

a des propriétés spécifiques, comme la date de fabrication

(#manufDate) ou le numéro de série (#serial), héritées de Car, mais

également des propriétés générales à toutes les voitures du modèle

Fiat Retro comme le prix (stickerPrice) ou le nombre de portes

(#doors).

Conséquence

d’application

Les avantages du patron Materialization sont :

– la relation entre des classes d’éléments abstraits avec des

classes d’éléments plus concrets,

– la propagation d’attributs des catégories abstraites vers les

objets concrets.

Alternative Powertype (Odell, 1994)

Tableau 2-4. Le patron Materialization.

Le patron Materialization a le même but et utilise la même technique de modélisation

des clabjects que le Powertype. Il introduit cependant de nouveaux types d’attributs

(T2mono, T2multi, T3inst) qui rendent la modélisation beaucoup plus complexe, mais

aussi plus précise.

c)Exemple et synthèse pour la méta-modélisation des processus d’ISI

La Figure 2-7 présente un exemple d’imitation du patron Powertype pour la

méta-modélisation de processus d’ingénierie de SI. Le powertype Type de phase contient les

attributs permettant de décrire n’importe quelle phase. Le type partitionné Phase permet

de décrire des attributs spécifiques à une phase. Les attributs de Type de phase sont

valués dans le clabject.

Figure 2-7. Exemple d’imitation du patron Powertype.

La Figure 2-8 présente un autre exemple d’imitation du patron Powertype pour les

processus d’ingénierie de SI. Nous utilisons les mêmes attributs et classes que

l’imitation du patron ItemDescription de la Figure 2-3. Comme le spécifie le Powertype,

il faut instancier les attributs du powertype dans le clabject. Le premier problème qui se

pose est l’instanciation des attributs dureeMax et maxPers. Nous souhaitons que ces

attributs soient instanciés au niveau M0, c'est-à-dire au niveau des projets pour qu’à

l’intérieur d’un projet il soit possible, par exemple, de définir que la durée maximale des

phases sera de 50 jours et qu’au maximum 50 personnes seront affectées à une phase.

Ceci n’est pas possible avec cette configuration, car il faudrait refaire un nouveau

modèle de processus (M1) lorsque la durée maximale d’une phase change d’un projet à

l’autre : un modèle de processus où la durée maximale d’une phase serait de 50 jours et

un autre modèle de processus où cette durée serait fixée à 40 jours, par exemple.

Figure 2-8. Exemple insatisfaisant d’imitation du patron Powertype.

Avec le patron Powertype, nous ne pouvons utiliser les concepts Unités de travail et

Catégorie d’unité de travail. Il faut spécifier dès le méta-modèle que des objets pourront

être des phases. Or, nous voulons laisser la liberté aux ingénieurs des méthodes de

choisir les termes les plus adéquats dans leurs modèles de processus, car en particulier,

Phase et Type de phase nous paraissent être des concepts trop précis pour être définis au

niveau des méta-modèles.

D’autre part, l’instanciation des attributs n’est pas aussi flexible que ce que propose

l’Instanciation Profonde. Les attributs sont instanciés au niveau de méta-modélisation

strictement inférieur. Afin de respecter le principe de la méta-modélisation stricte

d’UML, la structure de Powertype et Materialization en est complexifiée : séparation

graphique du clabject en une classe et un objet et séparation du type partitionné et du

powertype effacée au niveau M0. De plus, si l’on souhaite valuer des attributs au niveau

M1, il faudra les placer dans le powertype (ou AbstractClass), et réciproquement, si l’on

souhaite valuer des attributs au niveau M0, il faudra les placer dans le type partitionné

(ConcreteClass). La catégorisation perd alors tout son sens puisque les attributs ne

seront plus affectés à leur classe d’origine, mais en fonction du niveau où l’on souhaite

les instancier.

Les concepts de Powertype et Materialization ne permettent donc pas de répondre

avec satisfaction à nos besoins de catégorisation et de méta-modélisation. Ils permettent

de catégoriser les unités de travail, mais de manière trop spécifique. Nous souhaitons

définir Unités de travail et Catégorie d’unité de travail au niveau des méta-modèles

(M2), ce qui n’est pas possible ici.

Dans le document Méthode, modèles et outil pour la méta-modélisation des processus d'ingénierie de systèmes d'information (Page 40-48)