• Aucun résultat trouvé

Différents cas d’héritage

Dans le document UML 2 pour les bases de donnees (Page 84-90)

Différents cas d’héritage peuvent être recensés en fonction des instances des classes [ADI 93].

L’exemple 1-80 décrit une population de postes de travail qui peut être composée :

de postes clients ou serveurs exclusivement (cas A) ;

Figure 1-78 Héritage avec Merise/2

Figure 1-79 Héritage avec UML

Enseignant Chercheur

Personnel nom adresse grade paye

heures_cours nom_labo

association d’héritage

sous-entité ou entité sous-type

sur-entité ou entité sur-type

Enseignant Chercheur

Personnel

liste_cours() liste_publications()

nom adresse grade paye salaire()

heures_cours nom_labo

sur-classe

liens d'héritage

sous-classe

de postes clients, de postes serveurs et de postes isolés qui ne sont ni clients ni serveurs (cas B) ;

de postes clients, de postes serveurs et de postes qui sont à la fois clients et serveurs, mais pas de postes isolés (cas C) ;

de postes clients, de postes serveurs, de postes qui sont à la fois clients et serveurs et de postes isolés (cas D).

Chacun de ces cas d’héritage peut être modélisé à l’aide de contraintes que nous avons étudiées à la section Contraintes. Le tableau 1.7 fait correspondre, pour chaque cas d’héritage, la contrainte à programmer dans les deux formalismes.

Notez que l’absence de contrainte dans un graphe d’héritage n’a pas la même signification dans Merise/2 et pour UML. Le premier autorise qu’une occurrence appartient à plusieurs entités sous-type. UML considère que par défaut un objet n’existe que dans une classe pour un niveau de hiérarchie donné.

Supposons, dans le cadre de notre exemple, qu’un poste de travail soit caractérisé par un numéro de série et un type. Un client sera désigné par une adresse IP et par un masque de

sous-Figure 1-80 Différents cas d’héritage

Tableau 1.7 Héritage : couverture et disjonction

Couverture Non-couverture Non-Disjonction (cas C)

Merise/2 : Totalité (T)

réseau alors qu’un serveur sera défini par un nom et que l’on voudra stocker l’espace disque encore disponible.

Disjonction

Couverture : héritage de partition

L’exemple 1-81 illustre le cas A : les postes de travail sont soit des clients, soit des serveurs.

L’union des clients et des serveurs constitue le parc informatique. On peut dire qu’il y a deux partitions dans le parc informatique.

Bien que Merise/2 préconise le symbole P pour la partition, le diagramme 1-82 utilise le symbole XT (comme dans le cas des associations binaires).

Figure 1-81 Héritage de partition (cas A)

Figure 1-82 Héritage de partition Merise/2 (Win’Design)

client

serveur

Clients

Serveurs Postes

Client Serveur

Poste_travail nserie typeposte

adr_IP masque

nomserv disque XT

Le diagramme 1-83 représente la contrainte prédéfinie UML {complete,disjoint} qui exprime la partition.

On peut également utiliser une programmation OCL sous la forme de trois notes. La première, attachée à la classe Client signifierait qu’un client ne peut pas être serveur. Notez l’utilisation de la fonction allInstances qui retourne pour un type donné l’ensemble de ses instances, incluant aussi les instances de ses sous-classes.

context Client

inv R1 : Serveur.allInstances.noserie->excludes(self.noserie)

La seconde, attachée à la classe Serveur signifierait, d’une manière symétrique, qu’un serveur ne peut pas être client.

context Serveur

inv R2 : Client.allInstances.noserie->excludes(self.noserie) La troisième, attachée à la classe Poste signifierait :

qu’un poste est soit de type client, soit de type serveur (par le fait du ou exclusif). La fonc-tion oclIsKindOf permet de statuer à propos de la nature de la classe d’un type passé en paramètre ;

que le numéro de série est l’identifiant (fonction isUnique).

context Poste inv R3 :

(self.oclIsKindOf(Client) xor self.oclIsKindOf(Serveur)) and (Poste.allInstances.noserie->isUnique(c | c.noserie))

Figure 1-83 Héritage de partition avec UML

Client Serveur

Poste_travail nserie typeposte

adr-IP

masque nomserv

disque {complete,disjoint}

Non-couverture : héritage exclusif

La figure 1-84 illustre le cas B : il existe des postes n’étant ni client, ni serveur (l’union des clients et des serveurs ne compose plus le parc informatique : certains postes en sont exclus).

Merise/2 note cet héritage par le symbole X dans l’exemple 1-82.

Plusieurs notations UML sont possibles : la plus simple et la plus courante consiste à n’utiliser aucune contrainte (cas par défaut), une autre solution met en œuvre la contrainte prédéfinie {incomplete,disjoint}, enfin les adeptes des règles OCL devront utiliser :

R1 et R2 précédemment définies ;

R3 modifiée (qui relâche la contrainte spécifiant qu’un poste est soit client, soit serveur) de la manière suivante.

context Poste

inv R3 : (Poste.allInstances.noserie->isUnique(c | c.noserie)

Non-disjonction

Couverture : héritage de totalité

La figure 1-85 illustre le cas C : il existe des postes de travail considérés à la fois comme client et serveur. L’union des clients, des serveurs et des clients-serveurs compose le parc informatique dans sa totalité.

Merise/2 note cet héritage le symbole T dans l’exemple 1-82.

Le plus simple diagramme UML consiste à utiliser la contrainte prédéfinie {incom-plete,overlapping}. Pour les adeptes du langage OCL, seule la règle R3 doit être

Figure 1-84 Héritage exclusif (cas B)

client

serveur

Clients

Serveurs Postes

présente et modifiée (en relâchant la contrainte qu’un numéro de série est unique puisqu’un poste peut être à la fois client et serveur par le fait du ou inclusif).

context Poste

inv R3 : (self.oclIsKindOf(Client) or self.oclIsKindOf(Serveur))

Dans les faits, la contrainte d’unicité du numéro de série sera toujours vérifiée au niveau de la base de données. Nous verrons au chapitre 2 comment peuvent se traduire les associations d’héritage.

Non-couverture : cas général

L’exemple 1-86 décrit le cas le plus général (les postes de travail peuvent être de toute nature).

Le schéma Merise/2 ne dispose d’aucune contrainte sur le graphe d’héritage.

Le diagramme UML consiste à utiliser la contrainte prédéfinie {incomplete,overlapping}.

Figure 1-85 Héritage de totalité (cas C)

Figure 1-86 Héritage sans contrainte (cas D) Postes

Clients

Serveurs C/S

client

serveur client-

serveur

client

serveur client-

serveur

Postes

Clients

Serveurs C/S

Dans le document UML 2 pour les bases de donnees (Page 84-90)