Modéliser ses objets grâce à UML

Ce contenu est obsolète. Il peut contenir des informations intéressantes mais soyez prudent avec celles-ci.

Dans ce chapitre, nous allons découvrir le principe de modélisation d'objet. Le sigle « UML » signifie Unified Modeling Language, que l'on peut traduire par « langage de modélisation unifié ». Il ne s'agit pas d'un langage de programmation, mais plutôt d'une méthode de modélisation. La méthode Merise, par exemple, en est une autre.

En fait, lorsque vous programmez en orienté objet, il vous sera sans doute utile de pouvoir schématiser vos classes, leur hiérarchie, leurs dépendances, leur architecture, etc. L'idée est de pouvoir, d'un simple coup d'œil, vous représenter le fonctionnement de votre logiciel : imaginez UML un peu comme une partition de musique pour le musicien.

Le but de ce chapitre n'est pas de vous transformer en experts UML, mais de vous donner suffisamment de bases pour mieux appréhender la modélisation et ensuite bien cerner certains concepts de la POO.

Présentation d'UML

Je sais que vous êtes des Zéros avertis en matière de programmation, ainsi qu'en informatique en général, mais mettez-vous dans la peau d'une personne totalement dénuée de connaissances dans le domaine. Il fallait trouver un langage commun aux commerciaux, aux responsables de projets informatiques et aux développeurs, afin que tout ce petit monde se comprenne. Avec UML, c'est le cas.

En fait, avec UML, vous pouvez modéliser toutes les étapes du développement d'une application informatique, de sa conception à la mise en route, grâce à des diagrammes. Il est vrai que certains de ces diagrammes sont plus adaptés pour les informaticiens, mais il en existe qui permettent de voir comment interagit l'application avec son contexte de fonctionnement… Et dans ce genre de cas, il est indispensable de bien connaître l'entreprise pour laquelle l'application est prévue. On recourt donc à un mode de communication compréhensible par tous : UML.

Il existe bien sûr des outils de modélisation pour créer de tels diagrammes. En ce qui me concerne, j'utilise argoUML. Il a le mérite d'être gratuit et écrit en Java, donc multi-plates-formes.

Cependant, il en existe d'autres, comme :

  • boUML,
  • Together,
  • Poseidon,
  • Pyut
  • etc.

Avec ces outils, vous pouvez réaliser les différents diagrammes qu'UML vous propose :

  • le diagramme de use case (cas d'utilisation) permet de déterminer les différents cas d'utilisation d'un programme informatique ;
  • le diagramme de classes ; c'est de celui-là que nous allons nous servir. Il permet de modéliser des classes ainsi que les interactions entre elles ;
  • les diagrammes de séquences, eux, permettent de visualiser le déroulement d'une application dans un contexte donné ;
  • et d'autres encore…

La figure suivante représente un exemple de diagramme de classes.

Exemple de diagramme de classes

Vous avez dû remarquer qu'il représente les classes que nous avons rencontrées dans les chapitres précédents. Je ne vous cache pas qu'il s'agit d'une version simplifiée. En effet, vous pouvez constater que je n'ai pas fait figurer les méthodes déclarées public de la classe Object, ni celles des classes que nous avons codées.

Je ne vais pas vous apprendre à utiliser argoUML, mais plutôt à lire un diagramme. En effet, dans certains cas, il est utile de modéliser les classes et l'interaction entre celles-ci, ne serait-ce que pour disposer de plus de recul sur son travail. Une autre raison à cela est que certains concepts de programmation sont plus faciles à expliquer avec un diagramme qu'avec de longs discours…

Modéliser ses objets

À présent, nous allons apprendre à lire un diagramme de classes. Vous avez deviné qu'une classe est modélisée sous la forme représentée sur la figure suivante.

Classe en UML

Voici une classe nommée ObjetA qui a comme attributs :

  • numero de type int ;
  • nom de type String ;
  • bool de type boolean.

Ses méthodes sont :

  • getNom() qui retourne une chaîne de caractères ;
  • setNom() qui ne renvoie rien ;
  • afficher() qui renvoie également une chaîne de caractères.

La portée des attributs et des méthodes n'est pas représentée ici. Vous voyez, la modélisation d'un objet est toute simple et très compréhensible !

Maintenant, intéressons-nous aux interactions entre objets.

Modéliser les liens entre les objets

Vous allez voir : les interactions sont, elles aussi, très simples à modéliser. En fait, comme vous l'avez vu avec l'exemple, les interactions sont modélisées par des flèches de plusieurs sortes. Nous aborderons ici celles dont nous pouvons nous servir dans l'état actuel de nos connaissances (au fur et à mesure de la progression, d'autres flèches apparaîtront).

Sur le diagramme représenté à la figure suivante, vous remarquez un deuxième objet qui dispose, lui aussi, de paramètres. Ne vous y trompez pas, ObjetB possède également les attributs et les méthodes de la classe ObjetA. D'après vous, pourquoi ? C'est parce que la flèche qui relie nos deux objets signifie « extends ». En gros, vous pouvez lire ce diagramme comme suit : l'ObjetB hérite de l'ObjetA, ou encore ObjetB est un ObjetA.

Représentation de l'héritage

Nous allons voir une autre flèche d'interaction. Je sais que nous n'avons pas encore rencontré ce cas de figure, mais il est simple à comprendre.

De la même façon que nous pouvons utiliser des objets de type String dans des classes que nous développons, nous pouvons aussi utiliser comme variable d'instance, ou de classe, un objet que nous avons codé. La figure suivante modélise ce cas.

Représentation de l'appartenance

Dans cet exemple simpliste, nous avons toujours notre héritage entre un objet A et un objet B, mais dans ce cas, l'ObjetA (et donc l'ObjetB) possède une variable de classe de type ObjetC, ainsi qu'une méthode dont le type de retour est ObjetC (car la méthode retourne un ObjetC). Vous pouvez lire ce diagramme comme suit : l'ObjetA a un ObjetC (donc une seule instance d'ObjetC est présente dans ObjetA).

Voici le code Java correspondant à ce diagramme.

Fichier ObjetA.java

1
2
3
4
5
6
7
public class ObjetA{
  protected ObjetC obj = new ObjetC();

  public ObjetC getObject(){      
    return obj;    
  }
}

Fichier ObjetB.java

1
2
3
public class ObjetB extends ObjetA{ 

}

Fichier ObjetC.java

1
2
3
public class ObjetC{ 

}

Il reste une dernière flèche que nous pouvons mentionner, car elle ne diffère que légèrement de la première. Un diagramme la mettant en œuvre est représenté sur la figure suivante.

Représentation de la composition

Ce diagramme est identique au précédent, à l'exception de l'ObjetD. Nous devons le lire comme ceci : l'ObjetA est composé de plusieurs instances d'ObjetD. Vous pouvez d'ailleurs remarquer que la variable d'instance correspondante est de type tableau…

Voici le code Java correspondant :

Fichier ObjetA.java

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class ObjetA{
  protected ObjetC obj = new ObjetC();
  protected ObjetD[] objD = new ObjetD[10];

  public ObjetC getObject(){
    return obj;
  } 
  public ObjetD[] getObjectD(){
    return objD;
  }
}

Fichier ObjetB.java

1
2
3
public class ObjetB extends ObjetA{

}

Fichier ObjetC.java

1
2
3
public class ObjetC{

}

Fichier ObjetD.java

1
2
3
public class ObjetD{

}

Il est bien évident que ces classes ne font strictement rien. Je les ai utilisées à titre d'exemple pour la modélisation.

Voilà, c'en est fini pour le moment. Attendez-vous donc à rencontrer des diagrammes dans les prochains chapitres !

  • UML vous permet de représenter les liens entre vos classes.
  • Vous pouvez y modéliser leurs attributs et leurs méthodes.
  • Vous pouvez représenter l'héritage avec une flèche signifiant « est un ».
  • Vous pouvez représenter l'appartenance avec une flèche signifiant « a un ».
  • Vous pouvez représenter la composition avec une flèche signifiant « est composé de ».