Mis à jour le 08/01/2018
  • 30 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours existe en livre papier.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

Vous pouvez être accompagné et mentoré par un professeur particulier par visioconférence sur ce cours.

J'ai tout compris !

UML : présentation (1/2)

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Programmer en orienté objet c'est bien beau, mais au début, c'est un peu difficile. On a du mal à s'y retrouver, on ne sait pas trop comment lier nos classes ni comment penser cet ensemble. L'UML est justement l'un des moyens pour y parvenir. L'UML (pour Unified Modeling Language, ou "langage de modélisation unifié" en français) est un langage permettant de modéliser nos classes et leurs interactions. Concrètement, cela s'effectue par le biais d'un diagramme : vous dessinerez vos classes et les lierez suivant des conventions bien précises. Cela vous permettra ainsi de mieux visualiser votre application et de mieux la penser.

La présentation de l'UML ne sera volontairement pas très approfondie, le but n'est pas de faire de vous des pros de la modélisation, mais juste de vous enseigner les bases afin que vous puissiez être capables de modéliser vous-mêmes.

UML, kézako ?

L'UML est un langage de modélisation objet. Il permet donc de modéliser vos objets et ainsi représenter votre application sous forme de diagramme.
Avant d'aller plus loin, attardons-nous un peu sur la signification d'UML : Unified Modeling Language, « langage de modélisation unifié ». UML n'est pas un langage à proprement parler, plutôt une sorte de méthodologie.

Mais qu'est-ce que c'est concrètement ? À quoi ça pourra bien me servir ?

Grâce à UML, vous pourrez modéliser toute votre application. Quand je dis toute, j'entends par là la plupart de votre application car PHP n'est pas un langage orienté objet : le modèle objet lui a été implémenté au cours des versions (dès la version 4). Grâce à ces diagrammes, vous pourrez donc représenter votre application : son fonctionnement, sa mise en route, les actions susceptibles d'être effectuées par l'application, etc. Ces diagrammes ont été conçus pour que quelqu'un n'ayant aucune connaissance en informatique puisse comprendre le fonctionnement de votre application. Certes, certains diagrammes sont réservés aux développeurs car assez difficiles à expliquer si on ne sait pas programmer : ce sont ces diagrammes que nous allons étudier.

D'accord, je peux modéliser mon application mais en quoi cela va-t-il m'aider ?

Si vous avez un gros projet (et là je ne parle pas forcément de PHP mais de tout langage implémentant la POO), il peut être utile de le modéliser afin d'y voir plus clair. Si vous vous focalisez sur la question « Par où commencer ? » au début du projet, c'est qu'il vous faut un regard plus objectif sur le projet. Les diagrammes vous apporteront ce regard différent sur votre application.

L'UML peut aussi être utile quand on commence à programmer OO mais qu'on ne sait pas trop comment s'y prendre. Par exemple, vous ne savez pas trop encore comment programmer orienté objet de façon concrète. Sachez donc que l'UML va vous être d'une grande aide au début. Ça vous aidera à mieux penser objet car les diagrammes représentent vos classes, vous vous rendrez ainsi mieux compte de ce qu'il est intelligent de faire ou pas. Cependant, l'UML n'est pas un remède miracle et vous ne saurez toujours pas comment vous y prendre pour réaliser votre toute première application, mais une fois que je vous aurai montré et que vous aurez acquis un minimum de pratique, l'UML pourra vous aider.

Enfin, l'UML a aussi un rôle de documentation. En effet, quand vous représenterez votre projet sous forme de diagramme, quiconque sachant le déchiffrer pourra (du moins, si vous l'avez bien construit) comprendre le déroulement de votre application et éventuellement reprendre votre projet.

Bref, que ce soient pour les gros projets personnels ou professionnels, l'UML vous suivra partout. Cependant, tout le monde ne trouve pas l'UML très utile et certains préfèrent modéliser le projet « dans leur tête ». Vous verrez avec le temps si vous avez réellement besoin de l'UML ou si vous pouvez vous en passer, mais pour l'instant, je vous conseille de modéliser (enfin, dès le prochain chapitre).

Il existe plusieurs types de diagrammes. Nous, nous allons étudier les diagrammes de classe. Ce sont des diagrammes modélisant vos classes et montrant les différentes interactions entre elles. Un exemple ? Regardez plutôt la figure suivante.

Diagramme UML modélisant notre dernier TP
Diagramme UML modélisant notre dernier TP

Vous aurez sans doutes reconnu notre dernier TP (avec quelques ajouts) représenté sur un diagramme.

Ce diagramme a l'avantage d'être très simple à étudier. Cependant, il y a des cas complexes et des conventions à connaître car, par exemple, des méthodes abstraites n'ont pas le même style d'écriture qu'une méthode finale. Nous allons étudier les bases, petit à petit, puis, à la fin de ce chapitre, vous serez capable d'analyser complètement un diagramme de classe.

Modéliser une classe

Première approche

Nous allons commencer en douceur par analyser une simple classe modélisée. Nous allons prendre notre classe News simplifiée (voir la figure suivante).

Notre classe News modélisée
Notre classe News modélisée

Nous avons donc ici une simple classe. Commençons par analyser celle-ci.

  • En haut, en gras et gros, nous avons le nom de la classe (ici, News).

  • Ensuite, séparé du nom de la classe, vient un attribut de cette classe : il s'agit de id précédé d'un #, nous verrons ce que ça signifie juste après.

  • Enfin, séparée de la liste d'attributs, vient la liste des méthodes de la classe. Toutes sont précédées d'un +, qui a, comme le #, une signification.

Nous allons commencer par analyser la signification du # et des +. Je ne vous fais pas attendre : ces signes symbolisent la portée de l'attribut ou de la méthode. Voici la liste des trois symboles :

  • Le signe + : l'élément suivi de ce signe est public.

  • Le signe # : l'élément suivi de ce signe est protégé.

  • Le signe - : l'élément suivi de ce signe est privé.

Maintenant que vous savez à quoi correspondent ces signes, regardez à droite de l'attribut : suivi de deux points, on peut lire int. Cela veut dire que cet attribut est de type int, tout simplement. int est le diminutif de integer qui veut dire entier : notre attribut est donc un nombre entier.

À droite des méthodes, nous pouvons apercevoir la même chose. Ceci indique le type de la valeur de retour de celle-ci. Si elle ne renvoie rien, alors on dit qu'elle est vide (= void). Si elle peut renvoyer plusieurs types de résultats différents, alors on dit qu'elle est mixte (= mixed). Par exemple, une méthode __get peut renvoyer une chaîne de caractères ou un entier (regardez la classe Personnage sur le premier diagramme).

Encore une dernière chose à expliquer sur ce diagramme : ce qu'il y a entre les parenthèses suivant le nom des méthodes. Comme vous vous en doutez, elles contiennent tous les attributs ainsi que leur type (entier, tableau, chaîne de caractères, etc.). Si un paramètre peut être de plusieurs types, alors, comme pour les valeurs de retour des méthodes, on dit qu'il est mixte.

Ensuite, il y a des conventions concernant le style d'écriture des attributs, des constantes et des méthodes.

  • Sans style d'écriture particulier, la méthode est « normale », c'est-à-dire ni abstraite, ni finale (comme ici). Si la méthode est en italique, cela signifie qu'elle est abstraite. Pour montrer qu'une méthode est finale, on le spécifie en stéréotype (on place le mot leaf entre chevrons à côté de la méthode).

  • Si l'attribut ou la méthode est souligné, cela signifie que l'élément est statique.

  • Une constante est représentée comme étant un attribut public, statique, de type const et est écrite en majuscules.

Exemple récapitulant tout ça (voir la figure suivante).

Exemple de classe modélisée
Exemple de classe modélisée

Exercices

Maintenant que vous savez tout cela, je vais vous donner quelques attributs et méthodes et vous allez essayer de deviner quels sont ses particularités (portée, statique ou non, abstraite, finale, ou ni l'un ni l'autre, les arguments et leur type...).

Exercice 1 : -maMethode (param1:int) : void

Correction : nous avons ici une méthode maMethode qui est abstraite (car en italique). Elle ne renvoie rien et accepte un argument : $param1, qui est un entier. Sans oublier sa visibilitée, symbolisée par le signe -, qui est privée.

Exercice 2 : #maMethode (param1:mixed) : array

Correction : nous avons ici une méthode maMethode ni abstraite, ni finale. Elle renvoie un tableau et accepte un argument : $param1, qui peut être de plusieurs types. Sans oublier sa visibilitée, symbolisée par le signe #, qui est protégée.

Exercice 3 : +<<leaf>> maMethode() : array

Correction : cette fois-ci, la méthode est finale (signalée par le mot leaf). Elle ne prend aucun argument et renvoie un tableau. Quant à sa visibilité, le signe + nous informe qu'elle est publique.

Les différents codes (italique, soulignements, etc.) rentreront dans votre tête au fil du temps, je ne vous impose pas de tous les apprendre sur-le-champ. Référez-vous autant que nécessaire à cette partie en cas de petits trous de mémoire. ;)

Maintenant que vous savez analyser un objet, il serait bien de savoir analyser les interactions entre ceux-ci, non ?

Modéliser les interactions

Nous attaquons la dernière partie de ce chapitre. Nous allons voir comment modéliser les interactions entre les objets que l'on a modélisés. Jusqu'à présent, nous savions comment les reconnaître, mais l'avantage de la POO est de créer un ensemble d'objets qui interagissent entre eux afin de créer une véritable application.

L'héritage

Parmi les interactions, on peut citer l'héritage. Comme montré dans le premier diagramme que vous avez vu, l'héritage est symbolisé par une simple flèche, comme indiqué à la figure suivante.

Exemple de modélisation d'une classe fille et d'une classe mère
Exemple de modélisation d'une classe fille et d'une classe mère

Ce diagramme équivaut au code suivant :

<?php
class Mere
{
  protected $attribut1;
  protected $attribut2;
  
  public function methode()
  {
  
  }
}

class Fille extends Mere
{
  protected $attribut3;
  
  public function __set($nom, $valeur)
  {
  
  }
}

Les interfaces

Vous connaissez également les interactions avec les interfaces. En effet, comme je l'ai déjà dit, une interface n'est rien d'autre qu'une classe entièrement abstraite, elle est donc considérée comme tel. Si une classe doit implémenter une interface, alors on utilisera la flèche en pointillés, comme à la figure suivante.

Exemple de modélisation d'une classe implémentant une interface
Exemple de modélisation d'une classe implémentant une interface

Traduit en PHP, ça donne :

<?php
interface iMaClasse
{
  public function methode1();
  public function methode2();
}

class MaClasse implements iMaClasse
{
  protected $attribut;
  
  public function methode()
  {
  
  }
  
  // Ne pas oublier d'implémenter les méthodes de l'interface !
  
  public function methode1()
  {
  
  }
  
  public function methode2()
  {
  
  }
}

L'association

Nous allons voir encore trois interactions qui se ressemblent. La première est l'association. On dit que deux classes sont associées lorsqu'une instance des deux classes est amenée à interagir avec l'autre instance. L'association entre deux classes est modélisée comme à la figure suivante.

Exemple de modélisation d'une association
Exemple de modélisation d'une association

L'association est ici caractérisée par le fait qu'une méthode de la classe NewsManager entre en relation avec une instance de la classe News.

Attends deux secondes... Je vois des choses écrites sur la ligne ainsi qu'aux extrémités, qu'est-ce que c'est ?

Le mot écrit au centre, au-dessus de la ligne est la définition de la relation. Il est suivi d'un petit symbole indiquant le sens de l'association. Ainsi, on peut lire facilement « NewsManager gère News ».

Ensuite, vous voyez le chiffre 1 écrit à gauche et une astérisque à droite. Ce sont les cardinalités. Ces cardinalités présentent le nombre d'instances qui participent à l'interaction. Nous voyons donc qu'il y a 1 manager pour une infinité de news. On peut désormais lire facilement « 1 NewsManager gère une infinité de News ». Les cardinalités peuvent être écrites sous différentes formes :

  • x (nombre entier) : tout simplement la valeur exacte de x.

  • x..y : de x à y (exemple : 1..5).

  • * : une infinité.

  • x..* : x ou plus (exemple : 5..*).

L'agrégation

La deuxième flèche que je vais vous présenter est l'agrégation. Il s'agit d'une forme d'association un peu particulière : on parlera d'agrégation entre deux classes lorsque l'une d'entre elles contiendra au moins une instance de l'autre classe. Une agrégation est caractérisée de la sorte (voir figure suivante).

Exemple de modélisation d'une agrégation
Exemple de modélisation d'une agrégation

Vous pouvez remarquer qu'il n'y a pas de cardinalité du côté du losange. En effet, le côté ayant le losange signifie qu'il y a obligatoirement une et une seule instance de la classe par relation (ici la classe est NewsCollection).

La composition

La dernière interaction que je vais vous présenter est la composition. La composition est une agrégation particulière. Imaginons que nous ayons une classe A qui contient une ou plusieurs instance(s) de B. On parlera de composition si, lorsque l'instance de A sera supprimée, toutes les instances de B contenues dans l'instance de A sont elles aussi supprimées (ce qui n'était pas le cas avec l'agrégation). Une composition est représentée de la sorte (voir la figure suivante).

Exemple de modélisation d'une composition
Exemple de modélisation d'une composition

Ce chapitre ne se veut pas complet pour la simple et bonne raison qu'il serait beaucoup trop long de faire le tour de l'UML. En effet, un cours complet sur l'UML s'étalerait sur beaucoup de chapitres, et ce n'est clairement pas le but du tutoriel. Si ce sujet vous intéresse, je peux vous renvoyer sur le site uml.free.fr.

En résumé

  • L'UML est un moyen parmi d'autres de modéliser son application afin de mieux s'y retrouver.

  • La modélisation d'une classe et des interactions se réalise en respectant certaines conventions.

  • Il y a association lorsqu'une classe A se sert d'une classe B.

  • Une agrégation est une association particulière : il y a agrégation entre A et B si l'objet A possède une ou plusieurs instances de B.

  • Une composition est une agrégation particulière : il y a composition entre A et B si toutes les instances de B contenues dans A sont supprimées lorsque A est supprimée.

Exemple de certificat de réussite
Exemple de certificat de réussite