COMPLÉMENTS SUR LES RELATIONS ENTRE CLASSES

COMPLÉMENTS SUR LES RELATIONS ENTRE CLASSES

Considérons les phrases suivantes : 1. Un répertoire contient des fichiers. 2. Une pièce contient des murs. 3. Les modems et les claviers sont des périphériques d’entrée/sortie. 4. Une transaction boursière est un achat ou une vente. 5. Un compte bancaire peut appartenir à une personne physique ou morale. 6. Deux personnes peuvent être mariées. Les phrases 1 et 2 illustrent ce qui différencie l’agrégation de la composition : 1. Un répertoire contient des fichiers. 2. Une pièce contient des murs. « Un répertoire contient des fichiers » : il s’agit au moins d’une agrégation. Voyons si nous pouvons aller plus loin et en faire une composition. Premier critère à vérifier : la multiplicité ne doit pas être supérieure à un du côté du composite. C’est bien le cas dans la première phrase, puisqu’un fichier appartient à un et un seul répertoire. Second critère : le cycle de vie des parties doit dépendre de celui du composite. Là encore, c’est le cas, puisque la destruction d’un répertoire entraîne la destruction de tous les fichiers qu’il contient. Nous pouvons donc parler de composition pour la première phrase. Procédons à la même analyse pour la seconde phrase, « Une pièce contient des murs ». Cette fois-ci, après vérification du premier critère, nous devons abandonner la composition. En effet, un mur peut appartenir à deux pièces contiguës (voire plus). La relation n’est donc qu’une agrégation. Afin de compléter les multiplicités, nous considérons qu’une pièce contient au moins un mur (circulaire !).

EXERCICE 4-1. Relations structurelles entre classes

Déterminez la relation statique appropriée (généralisation, composition, agrégation ou association) dans chaque phrase de l’énoncé précédent. Dessinez le diagramme de classes correspondant. N’hésitez pas à proposer différentes solutions pour chaque phrase.    Les phrases 3 et 4 se modélisent en UML par des relations de généralisation : 3. Les modems et les claviers sont des périphériques d’entrée/sortie ; 4. Une transaction boursière est un achat ou une vente. La seule différence réside dans la formulation de la phrase 4 qui correspond à une spécialisation, alors que celle de la phrase 3 est une généralisation. Cependant, nous pouvons apporter quelques précisions aux deux modèles : • Les super-classes sont abstraites : elles ne s’instancient pas directement, mais toujours par l’intermédiaire d’une de leurs sous-classes ; • L’arbre de généralisation de la phrase 3 est incomplet : il existe de nombreux autres périphériques d’entrée/sortie, comme les écrans, les souris, etc. La phrase 5 n’est pas une simple généralisation : 5. Un compte bancaire peut appartenir à une personne physique ou morale. Figure 4-1. Diagramme de classes des phrases 1 et 2 Figure 4-2. Diagrammes de classes des phrases 3 et 4  En effet, le groupe verbal employé n’est pas « est un » ou « est une sorte de », mais « appartient à ». Il s’agit donc d’une simple association. Une première approche simpliste consiste à décrire deux associations optionnelles, comme cela est illustré par la figure suivante d’un modèle simple, mais peu évolutif, à un modèle souple, mais complexe… Proposez plusieurs solutions pour modéliser la phrase suivante : « un pays a une capitale. » Dessinez les diagrammes de classes correspondants et indiquez les avantages et inconvénients des différentes solutions Une phrase aussi simple que « un pays a une capitale » va nous permettre d’illustrer le caractère hautement subjectif de l’activité de modélisation, et le choix souvent difficile qu’il faut opérer entre simplicité et évolutivité. En effet, nous allons proposer pas moins de quatre solutions différentes à cette question, de la plus simple à la plus sophistiquée… Première solution, la plus compacte possible : une classe Pays avec un simple attribut capitale. C’est suffisant, si nous voulons seulement récupérer le nom de la capitale de chaque pays, et par exemple produire un petit tableau sur deux colonnes, avec les pays classés par ordre alphabétique…Difficile de faire plus simple ! Nous pourrons par la suite compléter facilement le modèle en ajoutant quelques attributs à la classe Pays : nom, langue, monnaie, etc. En revanche, comment faire si nous voulons ajouter des propriétés au concept de capitale : nombre d’habitants, superficie, etc. ? La solution précédente trouve là sa limite, et nous sommes alors obligés de promouvoir capitale au rang de classe. Nous retrouvons ici l’illustration de la différence entre classe et attribut, déjà discutée lors de la question 3-2 du chapitre précédent.