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).
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'ObjetBhérite de l'ObjetA, ou encore ObjetBest unObjetA.
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.
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'ObjetAa unObjetC (donc une seule instance d'ObjetC est présente dans ObjetA).
Voici le code Java correspondant à ce diagramme.
Fichier ObjetA.java
public class ObjetA{
protected ObjetC obj = new ObjetC();
public ObjetC getObject(){
return obj;
}
}
Fichier ObjetB.java
public class ObjetB extends ObjetA{
}
Fichier ObjetC.java
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.
Ce diagramme est identique au précédent, à l'exception de l'
ObjetD. Nous devons le lire comme ceci : l'ObjetAest 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
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
public class ObjetB extends ObjetA{
}
Fichier ObjetC.java
public class ObjetC{
}
Fichier ObjetD.java
public class ObjetD{
}
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 ».
0 commentaires:
Enregistrer un commentaire