Un guide complet du diagramme de classes UML

Exemple de classe

Un chien a des états – couleur, nom, race ainsi que des comportements – remuer, aboyer, manger. Un objet est une instance d’une classe.

Notation de classe UML

Une classe représente un concept qui encapsule l’état ( attributs ) et le comportement ( opérations ). Chaque attribut a un type. Chaque  opération  a une  signature . Le nom de la classe est la  seule information obligatoire .

Nom du cours:

• Le nom de la classe apparaît dans la première partition.

Attributs de classe :

• Les attributs sont affichés dans la deuxième partition.
• Le type d’attribut est affiché après les deux-points.
• Les attributs sont mappés sur des variables membres (membres de données) dans le code.

Opérations de classe (méthodes) :

• Les opérations sont présentées dans la troisième partition. Ce sont des services que la classe fournit.
• Le type de retour d’une méthode est affiché après les deux-points à la fin de la signature de la méthode.
• Le type de retour des paramètres de méthode est affiché après les deux-points suivant le nom du paramètre. Mappage des opérations sur les méthodes de classe dans le code

Relations de classe

Une classe peut être impliquée dans une ou plusieurs relations avec d’autres classes. Une relation peut être de l’un des types suivants : (Reportez-vous à la figure de droite pour la représentation graphique des relations).

Type de relation	Représentation graphique
Héritage  (ou généralisation) : Représente une relation « est-un ». Un nom de classe abstrait est affiché en italique. SubClass1 et SubClass2 sont des spécialisations de Super Class. Une ligne continue avec une pointe de flèche creuse qui pointe de l’enfant à la classe parent
Association simple : Un lien structurel entre deux classes de pairs. Il existe une association entre Class1 et Class2 Une ligne continue reliant deux classes
Agrégation :Un type particulier d’association. Il représente une relation « faisant partie de ». Class2 fait partie de Class1. De nombreuses instances (indiquées par *) de Class2 peuvent être associées à Class1. Les objets de Class1 et Class2 ont des durées de vie distinctes. Une ligne continue avec un losange vide à l’extrémité de l’association liée à la classe du composite
Composition :Un type spécial d’agrégation où les parties sont détruites lorsque le tout est détruit. Les objets de Class2 vivent et meurent avec Class1. Class2 ne peut pas se suffire à lui-même. Un trait plein avec un losange plein à l’association liée à la classe de composite
Dépendance : Existe entre deux classes si les modifications de la définition de l’une peuvent entraîner des modifications de l’autre (mais pas l’inverse). La classe 1 dépend de la classe 2 Une ligne pointillée avec une flèche ouverte

Noms des relations

• Les noms des relations sont écrits au milieu de la ligne d’association.
• Les bons noms de relations ont un sens lorsque vous les lisez à haute voix :
  • « Chaque feuille de calcul  contient  un certain nombre de cellules »,
  • « une expression  est évaluée à  une valeur »
• Ils ont souvent une  petite pointe de flèche pour indiquer la direction  dans laquelle lire la relation, par exemple, les expressions sont évaluées en valeurs, mais les valeurs ne sont pas évaluées en expressions.

Relation – Rôles

• Un rôle est un objectif directionnel d’une association.
• Les rôles sont écrits aux extrémités d’une ligne d’association et décrivent le but joué par cette classe dans la relation.
  • Par exemple, une cellule est liée à une expression. La nature de la relation est que l’expression est la  formule  de la cellule.

Navigabilité

Les flèches indiquent si, étant donné qu’une instance participe à une relation, il est possible de déterminer les instances de l’autre classe qui lui sont liées.

Le diagramme ci-dessus suggère que,

• Étant donné une feuille de calcul, nous pouvons localiser toutes les cellules qu’elle contient, mais cela
  • nous ne pouvons pas déterminer à partir d’une cellule dans quelle feuille de calcul elle est contenue.
• Étant donné une cellule, nous pouvons obtenir l’expression et la valeur associées, mais
  • étant donné une valeur (ou une expression), nous ne pouvons pas trouver la cellule dont ce sont les attributs.

Visibilité des attributs de classe et des opérations

Dans la conception orientée objet, il existe une notation de visibilité pour les attributs et les opérations. UML identifie quatre types de visibilité :  public ,  protected ,  private et  package .

Les symboles +, -, # et ~ devant un attribut et un nom d’opération dans une classe indiquent la visibilité de l’attribut et de l’opération.

• + désigne des attributs publics ou des opérations
• – désigne des attributs ou des opérations privées
• # indique des attributs ou des opérations protégés
• ~ désigne les attributs ou les opérations du package

Exemple de visibilité de classe

Dans l’exemple ci-dessus :

• attribut1 et op1 de MyClassName sont publics
• attribut3 et op3 sont protégés.
• attribut2 et op2 sont privés.

L’accès à chacun de ces types de visibilité est indiqué ci-dessous pour les membres de différentes classes.

Multiplicité

Le nombre d’objets de chaque classe qui participent aux relations et à la multiplicité peut être exprimé comme suit :

• Exactement un – 1
• Zéro ou un – 0..1
• Beaucoup – 0..* ou *
• Un ou plusieurs – 1..*
• Nombre exact – par exemple 3..4 ou 6
• Ou une relation complexe – par exemple 0..1, 3..4, 6.* signifierait n’importe quel nombre d’objets autre que 2 ou 5

Exemple de multiplicité

• Exigence : Un étudiant peut suivre plusieurs cours et plusieurs étudiants peuvent être inscrits à un cours.
• Dans l’exemple ci-dessous, le  diagramme de classes  (à gauche) décrit l’énoncé de l’exigence ci-dessus pour le modèle statique tandis que le diagramme d’objets (à droite) montre l’instantané (une instance du diagramme de classes) de l’inscription au cours pour les cours Génie logiciel et Gestion de base de données respectivement)

Exemple d’agrégation – Ordinateur et pièces

• Une agrégation est un cas particulier d’association désignant une hiérarchie « consiste en »
• L’agrégat est la classe parent, les composants sont les classes enfants

Exemple d’héritage – Taxonomie cellulaire

• L’héritage est un autre cas particulier d’une association dénotant une hiérarchie « en quelque sorte »
• L’héritage simplifie le modèle d’analyse en introduisant une taxonomie
• Les classes enfants héritent des attributs et des opérations de la classe parent.

Diagramme de classes – Exemple d’outil de diagramme

Un diagramme de classes peut également avoir des notes attachées aux classes ou aux relations. Les notes sont affichées en gris.

Dans l’exemple ci-dessus :

Nous pouvons interpréter la signification du diagramme de classes ci-dessus en lisant les points comme suit.

1. Shape est une classe abstraite. Il est indiqué en italique.
2. La forme est une super-classe. Cercle, Rectangle et Polygone sont dérivés de Forme. En d’autres termes, un cercle est une forme. Il s’agit d’une relation généralisation/héritage.
3. Il existe une association entre DialogBox et DataController.
4. La forme fait partie de Window. Il s’agit d’une relation d’agrégation. La forme peut exister sans fenêtre.
5. Point fait partie de Circle. Il s’agit d’une relation de composition. Point ne peut pas exister sans cercle.
6. La fenêtre dépend de l’événement. Cependant, Event ne dépend pas de Window.
7. Les attributs du cercle sont le rayon et le centre. Il s’agit d’une classe d’entités.
8. Les noms de méthode de Circle sont area(), circum(), setCenter() et setRadius().
9. Le paramètre radius dans Circle est un paramètre in de type float.
10. La méthode area() de la classe Circle renvoie une valeur de type double.
11. Les attributs et les noms de méthodes de Rectangle sont masqués. Certaines autres classes du diagramme ont également leurs attributs et leurs noms de méthode masqués.

Traiter avec un système complexe – diagramme à classes multiples ou à classe unique ?

Inévitablement, si vous modélisez un grand système ou un grand domaine d’activité, vous devrez prendre en compte de nombreuses entités. Devrions-nous utiliser plusieurs ou un seul diagramme de classes pour modéliser le problème ? La réponse est:

• Au lieu de modéliser chaque entité et ses relations sur un seul diagramme de classes, il est préférable d’utiliser plusieurs diagrammes de classes.
• La division d’un système en plusieurs diagrammes de classes facilite la compréhension du système, en particulier si chaque diagramme est une représentation graphique d’une partie spécifique du système.

Perspectives du diagramme de classes dans le cycle de vie du développement logiciel

Nous pouvons utiliser des diagrammes de classes dans différentes phases de développement d’un  cycle de vie de développement logiciel  et généralement en modélisant des diagrammes de classes dans trois perspectives différentes (niveaux de détail) au fur et à mesure que nous avançons :

Perspective conceptuelle : Les diagrammes sont interprétés comme décrivant des choses dans le monde réel. Ainsi, si vous adoptez la perspective conceptuelle, vous dessinez un diagramme qui représente les concepts du domaine à l’étude. Ces concepts seront naturellement liés aux classes qui les implémentent. La perspective conceptuelle est  considérée comme indépendante de la langue .

Perspective de spécification : Les diagrammes sont interprétés comme décrivant des abstractions logicielles ou des composants avec des spécifications et des interfaces mais sans engagement pour une implémentation particulière. Ainsi, si vous prenez le point de vue des spécifications, nous  examinons les interfaces du logiciel , pas l’implémentation.

Perspective d’implémentation : Les diagrammes sont interprétés comme décrivant des implémentations logicielles dans une technologie et un  langage particuliers . Ainsi, si vous prenez la perspective de la mise en œuvre, nous  examinons la mise en œuvre du logiciel .