Apprendre à modéliser

Dans ce chapitre nous allons voir le principe de modélisation d'objet.
Ne vous leurrez pas, ça sera assez indigeste, mais faites-moi confiance...

Sommaire du chapitre :

UML est le sigle signifiant Unified Modeling Language : traduisez par "langage de modélisation unifié".
Il ne s'agit pas d'un langage de programmation mais plutôt d'une méthodologie de modélisation comme la méthode merise, etc.

À quoi ça sert ?

Je sais que vous êtes des Zér0s 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 toute connaissance dans le domaine.
Il fallait trouver un langage commun entre les commerciaux, les responsables de projets informatiques, les 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 parties de développement d'une application informatique, de sa conception à la mise en route, tout ceci grâce à des diagrammes. Il est vrai que certains de ces diagrammes sont plus adaptés à des informaticiens, mais il en existe qui permettent de voir comment interagit l'application dans son contexte de fonctionnement... Et dans ce genre de cas, la connaissance de l'entreprise pour laquelle l'application est prévue est de mise. On utilise donc un mode de communication commun à tout le monde : UML.

Il existe bien sûr des outils de modélisation afin de créer de tels diagrammes. Personnellement, j'utilise argoUML mais il en existe d'autres, comme :

ArgoUML a le mérite d'être gratuit et fait en Java... donc multi-plates-formes.

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

Voici un exemple de diagramme de classe :

Vous avez dû remarquer qu'il s'agissait des classes que nous avons utilisées lors des chapitres précédents. Je ne vous cache pas non plus qu'il s'agit d'une version simplifiée... En effet, vous pouvez constater que je n'ai pas mis toutes les méthodes déclarées public de la classe Object ainsi que des classes que nous avons codées.
Je ne vais pas vous apprendre à utiliser argoUML non plus, mais plutôt à savoir lire un diagramme car, dans certains cas, il s'avère pratique de modéliser les classes et l'interaction entres celles-ci. Ne serait-ce que pour avoir plus de recul sur notre travail. Mais aussi parce qu'il y a des concepts de programmation qu'il est plus facile d'expliquer avec un diagramme qu'avec de longs discours...

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

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

Et comme méthodes :

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

Maintenant, voyons les interactions entre objets.

Vous allez voir que les interactions sont aussi très simples à modéliser.
En fait, comme vous avez pu le voir sur l'exemple, les interactions sont modélisées par des flèches de types différents. Nous allons voir maintenant celles que nous pouvons d'ores et déjà utiliser, dans l'état actuel de nos connaissances (au fur et à mesure, nous verrons d'autres flèches).

Regardez ceci :

Sur ce diagramme, vous pouvez voir un deuxième objet qui a lui aussi des paramètres. Mais ne vous y trompez pas, ObjetB possède aussi les attributs et les méthodes de la classe ObjectA. Et d'après vous, pourquoi ?
Car 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.

Nous allons voir une autre flèche d'interaction. Je sais que nous n'avons pas encore vu ce cas de figure, mais il est simple à comprendre.
Comme nous pouvons mettre des objets de type String dans des classes que nous développons, nous pouvons aussi mettre comme variable d'instance, ou de classe, un objet que nous avons codé. Voici un diagramme modélisant ce cas de figure :

Dans cet exemple simpliste, vous voyez que nous avons toujours notre héritage entre un objet A et un objet B mais dans ce cas, l'ObjetA (et donc l'ObjetB) ont une variable de classe de type ObjetC, ainsi qu'une méthode ayant un type de retour ObjetC (car la méthode va retourner un ObjetC).
Vous pouvez lire ce diagramme comme suit :

l'ObjetA a un ObjetC.
Ici, il n'y a qu'un seul objetC : "a UN".

Voici le code Java correspondant à ce diagramme.

Code : Java - .

1

2

3

4

5

6

7

public class ObjetA{

   protected ObjetC obj = new ObjetC();

   public ObjetC getObject(){

     return obj;

   }

}

Code : Java - .

1

2

3

public class ObjetB extends ObjetA{

}

Code : Java - .

1

2

3

public class ObjetC{

}

Il y a encore une dernière flèche que nous pouvons voir car elle ne diffère que légèrement de la première.
Voici un diagramme la mettant en oeuvre :

Nous avons ici le même diagramme que précédemment, à l'exception de l'ObjetD. Ici, nous devons lire le diagramme comme suit :

l'ObjetA est composé d'ObjetD.
Ici, il y aura plusieurs instances d'ObjetD dans ObjetA.

Vous pouvez d'ailleurs remarquer que la variable d'instance correspondante est de type tableau...

Voici le code Java correspondant :

Code : Java - .

 1

 2

 3

 4

 5

 6

 7

 8

 9

10

11

12

public class ObjetA{

   protected ObjetC obj = new ObjetC();

   protected ObjetD[] objD = new ObjetD[10];

   public ObjetC getObject(){

     return obj;

   }

   public ObjectD[] getObjectD(){

      return objD;

   }

}

Code : Java - .

1

2

3

public class ObjetB extends ObjetA{

}

Code : Java - .

1

2

3

public class ObjetC{

}

Code : Java - .

1

2

3

public class ObjetD{

}

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

Voilà, c'en est fini pour le moment. Attendez-vous donc à avoir des diagrammes dans vos prochains chapitres...
Il n'y aura pas de QCM car j'estime qu'il n'y a rien de difficile ici.

Après ce que nous avons vu au cours de ce chapitre et des précédents, nous allons tout de suite voir les classes abstraites !