Diagrammes de classes UML
Diagrammes de classes UML
UML est une norme complexe de description de programmes informatiques développée par un consortium d'entreprises et de laboratoires, l'OMG. La norme officielle 1.5 est disponible sur leur site. Une nouvelle norme 2.0 est aussi en développement. Ces spécifications sont particulièrement techniques et indigestes.
Ce langage compte pas moins de douze différents types de diagrammes permettant de décrire l'architecture et le fonctionnement d'un programme informatique. L'apprentissage de l'utilisation de ce langage de formalisation nécessiterait un cours complet. De plus, il existe de subtiles différences entre les versions du langage. Nous ne vous demandons pas d'apprendre tout cela par vous-même !
Dans le cadre du projet, il ne vous est demandé qu'un seul type de diagramme : le diagramme de classe, qui présente les relations entre vos différentes classes. Il n'est pas non plus exigé que vos diagrammes respectent parfaitement la syntaxe UML ; il suffit qu'ils ressemblent à des diagrammes de classe et que votre architecture soit compréhensible.
L'un des intérêts majeurs d'UML est son indépendance vis-à-vis du langage choisi pour l'implémentation, avec pour seule contrainte qu'il soit orienté objet (par exemple Java, mais aussi C++, Eiffel, Objective C, OCaml, SmallTalk, Ruby, C#, ...). Ne vous attachez donc pas trop aux exemples Java fournis.
N'importe quelle information qui ne rentre pas vraiment dans les catégories suivantes, par exemple un morceau de code d'implémentation.
La représentation contient trois compartiments :
Voir un exemple Java pour ce diagramme.
Une association est une relation entre deux classes. On la décrit à l'aide :
Voir un exemple Java pour ce diagramme.
Une flèche triangulaire vide décrit une dérivation. La classe dérivée est la classe de base, mais avec des propriétés additionnelles ou modifiées. Elle spécialise ou étend la superclasse plus générale.
Une flèche d'héritage en tirets indique qu'une classe raffine ou implémente une interface.
L'interface elle-même est indiquée soit en précisant le stéréotype « interface » dans le nom de la classe, soit en utilisant des coins arrondis.
Marque la présence d'une classe interne à une autre.
Une classe utilise une autre classe, mais sans que la ressource soit un membre de l'utilisateur. Si la classe de ressource est modifiée, il y a peut-être des méthodes à modifier dans l'utilisateur. La ligne est souvent stéréotypée par « crée » ou « modifie ».
La destruction du tout ne détruit pas les parties.
La destruction du tout détruit les parties. Rare en Java.
Cette introduction est bien sûr incomplète mais devrait vous suffire. La lecture des chapitres concernant les diagrammes de classes du cours cité précédemment vous apportera plus de détails si vous le souhaitez.
Voici le diagramme de classe du squelette fourni pour le projet (aussi disponible en PDF) :
