Factorisation en utilisant l’héritage

Une première analyse a conduit à établir les classes ci-dessous pour l’organisations des banques d’un consortium. Ce n’est qu’un premier jet qu’il faut s’efforcer de corriger : Certains attributs sont redondants

  1. Introduisez des associations entre classes pour limiter la redondance d’informations. On supposera que les associations introduites donnent lieu à des accesseurs (getters, setters) sans qu’il soit nécessaire de les reprendre tous sur le diagramme.

  2. Utilisez l’héritage pour optimiser le modèle. Vous pouvez introduire une nouvelle classe si nécessaire.

Limites de l’héritage (simple)

On dispose de classes PointPlan ainsi que Polygone. Les polygones sont composés de points.

Dans l’implémentation proposée : * L’affichage se fait en mode texte dans la console, en s’appuyant sur la méthode toString() * La comparaison avec un autre polygone se fait en calculant la distance moyenne des sommets à l’origine du repère othonormé, grâce à la méthode distanceOrigine():float de PointPlan. On retourne des valeurs négatives ou positives selon que le point en paramètre est supérieur ou inférieur.

  1. Définir un diagramme de classes avec deux sous-classes de Polygone : l’une affichant un polygone en mode texte, et l’autre l’affichant en mode graphique.

  2. Toujours à partir du diagramme de classes donné plus haut, définir un diagramme avec des polygones de plusieurs types : les PolygoneNbPoints se comparant sur la base de leur nombre de sommets, et les PolygoneOrigine sur la base de la distance des sommets à l’origine

On souhaite maintenant disposer de toutes les combinaisons possibles entre les afficheurs et les comparateurs.

  1. Définir un diagramme de classes définissant toutes les possibilités correspondantes. Que devient ce diagramme de classes si on souhaite ajouter deux manières de comparer les polygones (selon leurs surfaces ou selon leur préimètre) ?

Interfaces

Cette manière de faire est déraisonnable car elle fige une hiérarchie de classes dont la taille explose dès que l’on rajoute une moindre modalité. Ainsi, quand il ne s’agira que de modifier les comportements de méthodes ou d’ajouter des fonctionnalités, on préférera souvent l’utilisation d’interfaces.

  1. Enrichissez le diagramme donné plus haut en définissant une interface AfficheurPolygone. Cette interface est réalisée par deux afficheurs (texte et graphique). La méthode Polygone::afficher() s’appuie sur un afficheur composant désormais le polygone au même titre que les sommets.

  2. Enrichissez encore le diagramme en procédant de même pour les quatre types de comparaisons permises.

Diagramme d’objets

Considérons le diagramme de classes suivant :

La note associée à Segment stipule par une contrainte que du point de vue d’un segment, les assocations avec un triangle ou avec un carré sont mutuellement exclusives (ou exclusif, c’est à dire l’une ou l’autre ou aucune, mais pas les deux).

Considérez maintenant les deux agencements d’objets suivants :

et

Dans ces dessins, si une figure est à l’intérieur d’une autre, cela signifie qu’elle en est composée, au sens de la composition UML.

  1. Un de ces dessins représente un agencement d’objet interdit par le diagramme de classe : lequel et pourquoi (donnez 3 raisons) ?

  2. Dessinez un diagramme d’objets représentant les objets dessinés sur l’autre dessin.

Module d’UML