CHAPITRE 9

UML, diagrammes de classes

Introduction la programmation oriente objets

95

eivd

Tlcommunications

mjn

9.1

Les diagrammes de classe

Le diagramme de classes constitue un lment trs important de la modlisation : il permet de dfinir quelles seront les composantes du systme final : il ne permet en revanche pas de dfinir le nombre et ltat des instances individuelles. Nanmoins, on constate souvent quun diagramme de classes proprement ralis permet de structurer le travail de dveloppement de manire trs efficace; il permet aussi, dans le cas de travaux raliss en groupe (ce qui est pratiquement toujours le cas dans les milieux industriels), de sparer les composantes de manire pouvoir rpartir le travail de dveloppement entre les membres du groupe. Enfin, il permet de construire le systme de manire correcte ( Build the system right).
9.1.1

Les paquetages

Les paquetages permettent typiquement de dfinir des sous-systmes. Un sous-systme est form dun ensemble de classes ayant entre elles une certaine relation logique. Souvent, un paquetage fait lobjet dune ralisation largement indpendente, et peut tre confie un groupe, ou un individu nayant pas un contact troit avec les responsables dautres paquetages.
Ils regroupent des lments de modlisation, selon des critres purement logiques. Ils permettent d'encapsuler des lments de modlisation (ils possdent une interface). Ils permettent de structurer un systme en catgories (vue logique) et sous-systmes (vue

des composants). Ils servent de "briques" de base dans la construction d'une architecture. Ils reprsentent le bon niveau de granularit pour la rutilisation. Les paquetages sont aussi des espaces de noms.
FIGURE 9.1

Notation utilise pour un paquetage

On peut ouvrir un package; par dfaut, le package choisi est "default".

9.1.2

Les interfaces

Les interfaces reprsentent llment le plus abstrait du diagramme de classes. La manire habituelle pour reprsenter un interface est reprsente la figure9.2, page97. Un

96

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

membre est accompagn de son type, comme il est dusage dans beaucoup de langages de projection.
FIGURE 9.2

Reprsentation dun interface

A cette reprsentation est associe du code, dans le langage de projection choisi. Dans le cadre de ce chapitre, nous utiliserons systmatiquement Java comme langage de projection. Il est bien entendu que la modlisation est largement indpendante du langage de projection; nanmoins, certaines diffrences dimplmentation peuvent apparatre, comme par exemple labsence de la notion dinterface en C++, et son remplacement par la notion de classe abstraite purement virtuelle.
FIGURE 9.3

Traduction de la reprsentation en code Java

Introduction la programmation oriente objets

97

eivd

Tlcommunications

mjn

9.2

Les classes

La notion de classe est essentielle en programmation oriente objets : elle dfinit une abstraction, un type abstrait qui permettra plus tard dinstancier des objets. On distingue gnralement entre classes abstraites (qui ne peuvent pas tre instancies) et classes "normales", qui servent dfinir des objets.
9.2.1

Classes abstraites

Une classe abstraite ne peut donc pas tre utilise pour fabriquer des instances dobjets; elle sert uniquement de modle, que lon pourra utiliser pour crer des classes plus spcialises par drivation (hritage). Une classe abstraite est assez proche de la notion dinterface; dailleurs, la notion dinterface est gnralement implmente par une classe abstraite, dont toutes les mthodes sont purement virtuelles, en C++ (rappelons que C++ ne connat pas la notion dinterface).
FIGURE 9.4

Reprsentation dune classe abstraite

Le + dnote la publication du membre concern. Une classe abstraite peut possder des membres privs ou des attributs privs ou publics; dautre part, les mthodes peuvent faire lobjet dune implmentation, mme si la mthode est purement virtuelle.

FIGURE 9.5

La mme classe abstraite, projete en Java

9.2.2

Classes non abstraites

Une classe "normale" ne contient pas de membres abstraits. Sa reprsentation en UML correspond la figure9.6, page99. 98
Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

FIGURE 9.6

Reprsentation dune classe

Noter les petits signes "cabalistiques" prcdant lidentification des mthodes :

- dnote un membre priv + dnote un membre public # dnote un membre protg

Dailleurs, la projection en Java est parfaitement claire ce sujet (figure9.7, page99).

FIGURE 9.7

Code correspondant

9.2.3

Les relations entre les classes

Les diverses classes possdent des relations de dpendance entre elles. Ces relations possdent en principe un quivalent syntaxique dans le langage de projection. Les principales de ces relations sont numres dans la suite. Il est nanmoins important de noter que certaines relations peuvent ne pas avoir dquivalent dans le langage de projection considr. Ainsi, C++ introduit la notion de template, ou classe paramtrable, qui peut tre modlise en UML, mais qui reprsente une notion inconnue en tant que telle en Java. A linverse, Java permet de dfinir une classe qui implmente un interface, alors que la notion dinterface est inexistante en C++. Dans les deux cas, loutil de modlisation, sil gnre du code, choisira le mode de reprsentation le mieux adapt en considration du langage de projection choisi. Un interface UML pourrait, par exemple, se traduire par une classe abstraite en C++.
9.2.4

Hritage

Lhritage constitue une relation de spcialisation. Elle est note, en UML, par une flche allant de la classe spcialise vers la classe originale (de la classe vers la superclasse).
Introduction la programmation oriente objets

99

eivd

Tlcommunications

mjn

FIGURE 9.8

Relation dhritage

On notera que la relation inverse nest en principe pas documente; cest que cette relation nest en principe pas connue au moment de la conception dun produit, et quelle est susceptible de changer au cours du temps. De plus, une superclasse nest pas cense dpendre de ses drives : alors, quoi bon le documenter ?

FIGURE 9.9

Code gnr par la modlisation prcdente

9.2.5

Implmentation

Une classe peut implmenter un interface; elle peut aussi en implmenter plusieurs. En notation UML, cette relation est dnote par une flche en traitills (figure9.10, page101)

100

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

FIGURE 9.10

Implmentation dun interface

FIGURE 9.11

Code correspondant

9.2.6

La relation daggrgation

Lorsquun objet en contient dautres, on parle daggrgation. Le diagramme de classes dUML dcrit cette relation par une flche pleine, comme indiqu la figure9.12, page102. Il faut noter que laggrgation est parfois appele "relation de contenance". On peut signaler aussi que UML ne propose pas de reprsentation spcifique pour lhritage priv ou protg, notions propres au langage C++, ce qui de lavis de lauteur est une bonne chose.

Introduction la programmation oriente objets

101

eivd

Tlcommunications

mjn

FIGURE 9.12

Relation daggrgation et code correspondant

La relation daggrgation est souvent (et de manire fort judicieuse) implmente par des membres privs. Il va de soi que ces derniers peuvent tre protgs ou publics.
9.2.7

Relation de dpendance

La notion de dpendance est plus floue que les prcdentes. Il est difficile de faire une nomenclature complte des possibles relations de dpendance. Certains outils de modlisation offrent la possibilit de tracer automatiquement les relations directes : hlas, les relations indirectes sont souvent ngliges, parceque difficiles dtecter; dautre part, le schma rsultant de ces outils est souvent encombr de relations videntes quil et peut-tre mieux valu, pour des raisons de lisibilit, passer sous silence. Cest pourquoi beaucoup doutils laissent lutilisateur le soin de dfinir ce type de relation. La figure9.13, page103 montre un exemple de dpendance, tant bien entendu que ceci nest quun exemple parmi de nombreux autres possibles.

102

Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

FIGURE 9.13

Relation de dpendance et exemple de code correspondant

9.2.8

Commentaires

UML permet dajouter des notes (commentaires) la reprsentation graphique. Les annotations peuvent tre ncessaires pour prciser les intentions du concepteur. Les annotations peuvent tre ou non traduites en commentaires dans le langage de projection: tout dpend de loutil utilis. Certains commentaires de plus peuvent tre insrs de manire systmatique dans les fichiers sources : il en va en particulier ainsi pour le langage de projection Java, qui permet une extraction automatique de la documentation grce ses balises (tag ) de documentation par les commentaires, et son utilitaire javadoc qui se sert de ces balises pour gnrer un fichier HTML.

Introduction la programmation oriente objets

103

eivd

Tlcommunications

mjn

FIGURE 9.14

Commentaires dans le diagramme de classe UML

9.2.9

Strotypes

Un strotype dnote une appartenance une catgorie de classes dtermine. Un dveloppeur peut dfinir ses propres strotypes, mais il est souvent judicieux de parcourir la nomenclature des strotypes standards dfinis par UML, avant de commencer inventer de nouveaux strotypes.
FIGURE 9.15

Exemples de strotypes

Certains outils permettent de colorier de manire spcifique certains strotypes (Together, par exemple). Cette possibilit peut paratre au premier abord un peu vaine : pourtant, elle devient intressante ds que lon utilise un dveloppement laide de "patrons" ( patterns). Le strotype peut en effet identifier un patron dun certain type, et la couleur permet de dtecter plus facilement lutilisation de patrons particuliers. 104
Introduction la programmation oriente objets

eivd

Tlcommunications

mjn

Le strotype na pas dinfluence sur la gnration de code; tout au plus y aura-t-il gnration dun commentaire. En Java, le strotype sera document sous forme de balise de documentation javadoc, ce qui permettra de le faire figurer automatiquement dans la documentation de la classe.
FIGURE 9.16

Code correspondant au strotype de la figure prcdente

package SerialChannel; /** * @stereotype thread */ public class BothWayTermination implements Runnable { public BothWayTermination(Sender snd, Receiver rcv, int bufsize) { } private Sender snd; private Receiver rcv; public void send(byte b) throws SendBufferFullException {} public boolean dataAvailable() { } public boolean acceptData() { } public void run() { } }

Introduction la programmation oriente objets

105

eivd

Tlcommunications

mjn

106

Introduction la programmation oriente objets