> Le Site du Zéro - Informatique

> Cours

> Tutoriels

> Programmation

> Java

> Apprenez à programmer en Java

> Java Orienté Objet

> Apprendre à modéliser

> Lecture du tutoriel

Apprendre à modéliser

Par

cysboy

Mise à jour : 12/02/2010

Difficulté : Facile Facile

96 702 visites depuis 7 jours, dont 1 256 sur ce chapitre classé 4/786

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...

Retour en haut

Sommaire du chapitre :

UML, mais qu'est-ce donc ?
Modéliser un objet
Modéliser les interactions entre objets

Retour en haut

UML, mais qu'est-ce donc ?

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 :

boUML
Together
Poseidon
Pyut
...

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 :

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

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...

Retour en haut

Modéliser un objet

À 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 :

numero de type int
nom de type String
et bool de type boolean.

Et comme méthodes :

getNom() qui retourne une chaîne de caractères
setNom() qui ne renvoie rien
afficher() qui renvoie elle aussi une chaîne de caractères.

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.

Retour en haut

Modéliser 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.

Fichier ObjetA.java

Code : Java

public class ObjetA{
   protected ObjetC obj = new ObjetC();
   
   public ObjetC getObject(){
     return obj;
   }
}

Fichier ObjetB.java

Code : Java

1
2
3

public class ObjetB extends ObjetA{
  
}

Fichier ObjetC.java

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 :

Fichier ObjetA.java

Code : Java

public class ObjetA{
   protected ObjetC obj = new ObjetC();
   protected ObjetD[] objD = new ObjetD[10];
 
   public ObjetC getObject(){
     return obj;
   }
 
   public ObjectD[] getObjectD(){
      return objD;
   }
}

Fichier ObjetB.java

Code : Java

1
2
3

public class ObjetB extends ObjetA{
  
}

Fichier ObjetC.java

Code : Java

1
2
3

public class ObjetC{
  
}

Fichier ObjetD.java

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.

Retour en haut

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 !

Retour en haut

Retour en haut

14 commentaires pour "Apprendre à modéliser"

Note moyenne : 3.57 / 4 (1025 votes)

Pseudo	Commentaire
alatox	# Posté le 25/09/2009 à 18:14:17
Avis : Bon	C'est un résumé vraiment et tu ne présentes pas toutes les associations, tu ne différencies pas agrégation et composition... Je pense que cours sur UML officiel serait très intéressant car là encore, c'est très très résumé.
Tenebrous	# Posté le 06/09/2010 à 16:00:48
Études : ISAT Charleroi	Je me pose exactement la même question que Nabla21. Une petite explication ? So I said, "This is very obviously a Piero della Francesca."
TSprog	# Posté le 15/11/2010 à 20:40:46
	Désolé de vous dire ça mais il ya une erreur flagrante au début de se cours : "UML est le sigle signifiant Unified Modeling Language" jusque la c'est juste , mais aprés la contradiction : "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." UML est un Language , se n'est pas une methode , une methode pour en etre une il faut qu'elle rassemble de critére 1- un formalisme 2- un modéle Uml n'est qu'un formalisme Orienté Objet ,il lui manque un modéle ,il n'a rien avoir avec merise qui est une méthode fonctionnelle . les professionel travaille plutot avec UP,XP,.. qui sont des METHODES , ou meme des patrons ....
plune23	# Posté le 05/01/2011 à 19:00:21
	Euh, je peux comprendre que pour quelqu'un de familier avec ce genre de truc UML est d'une simplicité déconcertante mais honnêtement, j'ai strictement rien compris à ce tuto. Selon moi, il est très incomplet. 1_ On sait pas trop à quoi ça sert ? 2_ Tu mets 3 flèches sans vraiment expliquer le pourquoi du comment. En gros le tuto se résume à :"Si c'est comme ça, faut faire ça avec tel flèche !". 3_ Est-ce une convention propre aux outils UML, à la méthode ou juste à argoUML. Si je résume ce que j'ai compris, ça donne : _ Si B hérité de A, flèche 1. _ Si C est appelé une seule fois dans A, flèche 2. _ Si D est appelé plusieurs fois dans A, flèche 3. Est-ce valide pour les classes ou aussi pour les séquences, les cas d'utilisation ? Si c'est le cas, je vais oublier ce chapitre parce que ça m'embrouille plus qu'autre chose tout ça. Merci beaucoup en tout cas.
Toldo171	# Posté le 19/10/2011 à 14:02:44
Le bonheur, c'est l'ignorance Études : Ecole Centrale de Lyon	Citation : plune23 Euh, je peux comprendre que pour quelqu'un de familier avec ce genre de truc UML est d'une simplicité déconcertante mais honnêtement, j'ai strictement rien compris à ce tuto. Selon moi, il est très incomplet. 1_ On sait pas trop à quoi ça sert ? 2_ Tu mets 3 flèches sans vraiment expliquer le pourquoi du comment. En gros le tuto se résume à :"Si c'est comme ça, faut faire ça avec tel flèche !". 3_ Est-ce une convention propre aux outils UML, à la méthode ou juste à argoUML. Si je résume ce que j'ai compris, ça donne : _ Si B hérité de A, flèche 1. _ Si C est appelé une seule fois dans A, flèche 2. _ Si D est appelé plusieurs fois dans A, flèche 3. Est-ce valide pour les classes ou aussi pour les séquences, les cas d'utilisation ? Si c'est le cas, je vais oublier ce chapitre parce que ça m'embrouille plus qu'autre chose tout ça. Merci beaucoup en tout cas. Ma réponse est peut-être un peu tardive, mais pourra servir dans le futur. 1_ UML est un langage permettant de modéliser et de définir la structure du programme que tu veux créer. Par exemple, si tu est engagé par un commanditaire pour créer un quelconque logiciel, UML servira d'interface de dialogue entre le commanditaire et toi. Ce langage servira au commanditaire à spécifier son besoin, et facilitera ton travail de codage. UML peut aussi être utilisé dans la phase de conception du logiciel, quand tu travailles avec ton papier et ton crayon pour définir la structure de ton programme. Il simplifie alors considérablement l'implémentation. 2_ UML est régi par de très nombreuses conventions. Effectivement, suivant le type de relation entre deux classes, il faut "faire avec telle ou telle flèche". 3_ Ces conventions sont propres au langage UML. ArgoUML est juste un logiciel permettant de créer des schémas UML, mais un papier et un crayon peuvent très bien suffire. 4_ Les diagrammes de séquences et d'utilisation sont d'autres types de diagrammes UML. UML regroupe de nombreux types de diagrammes : - Diagrammes de séquences, - Cas d'utilisation, - Diagrammes de classes, - Diagrammes d'architecture, - Diagrammes de déploiement, - ... (il y en a encore 2 ou 3, je ne les ai pas tous en tête). Chaque diagramme a son propre rôle. L'auteur a ici détaillé succinctement (bel oxymore !) la syntaxe des diagrammes de classes. Chaque type de diagramme a sa propre syntaxe, et sa propre utilité. Par exemple, les diagrammes de séquence représentent des exemples d'interactions entre les acteurs et les composants d'un système (qui peuvent être des objets !), selon un ordre chronologique. J'espère que ma réponse est claire, et qu'elle servira à au moins une personne ! Envie de bonne musique ?