Autres éléments
1.1.1. Composition
La composition, également appelée agrégation composite, décrit une contenance structurelle entre
instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants. Une
instance de la partie appartient toujours à au plus une instance de l’élément composite. Graphiquement, on ajoute un losange plein (_) du côté de l’agrégat.
Dépendance
Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre les
éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la modification de la cible implique une modification de la source. La dépendance est souvent
stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle
Interfaces
Les classes permettent de définir en même temps un objet et son interface. Le classeur, que nous décrivons dans cette section, ne permet de définir que des éléments d’interface. Il peut s’agir de l’interface complète d’un objet, ou simplement d’une partie d’interface qui sera commune à plusieurs objets.
Le rôle de ce classeur, stéréotypé « interface », est de regrouper un ensemble de propriétés et d’opérations assurant un service cohérent.
Une interface est représentée comme une classe excepté l’absence du mot-clef abstract (car l’interface et toutes ses méthodes sont, par définition, abstraites) et l’ajout du stéréotype « interface ».
Une interface doit être réalisée par au moins une classe. Graphiquement, cela est représenté par un
trait discontinu terminé par une flèche triangulaire et le stéréotype « realize ». Une classe (classe cliente de l’interface) peut dépendre d’une interface (interface requise).
On représente cela par une relation de dépendance et le stéréotype « use ».
Élaboration d’un diagramme de classes
Il y a au moins trois points de vue qui guident la modélisation (Steve Cook et John Daniels) :
– Le point de vue spécification met l’accent sur les interfaces des classes plutôt que sur leurs contenus.
– Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Il s’intéresse
peu ou prou à la manière éventuelle d’implémenter ces concepts et relations et aux langages
d’implémentation.
– Le point de vue implémentation, le plus courant, détaille le contenu et l’implémentation de chaque
classe.
En fonction du point de vue adopté, vous obtiendrez des modèles différents. Une démarche couramment utilisée pour bâtir un diagramme de classes consiste à :
Trouver les classes du domaine étudié. Cette étape empirique se fait généralement en collaboration avec un expert du domaine. Les classes correspondent généralement à des concepts ou des substantifs du domaine.
Trouver les associations entre classes. Les associations correspondent souvent à des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme « est composé de », « pilote », « travaille pour ». Attention, méfiez vous de certains attributs qui sont en réalité des relations entre classes.
Trouver les attributs des classes. Les attributs correspondent souvent à des substantifs, ou des groupes nominaux, tels que « la masse d’une voiture » ou « le montant d’une transaction ». Les adjectifs et les valeurs correspondent souvent à des valeurs d’attributs. Vous pouvez ajouter des attributs à toutes les étapes du cycle de vie d’un projet (implémentation comprise). N’espérez pas trouver tous les attributs dès la construction du diagramme de classes.
Organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage.
Vérifier les chemins d’accès aux classes.
Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première construction. La modélisation objet est un processus non pas linéaire mais itératif.
Diagramme d’objets (object diagram)
Présentation
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue de l’état du système à un instant donné. Un diagramme d’objets permet, selon les situations, d’illustrer le modèle de classes (en montrant un exemple qui explique le modèle), de préciser certains aspects du système (en mettant en évidence des détails imperceptibles dans le diagramme de classes), d’exprimer une exception (en modélisant des cas particuliers, des connaissances non généralisables . . .), ou de prendre une image (snapshot) d’un système à un moment donné. Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits.
Par exemple, le diagramme de classes de la précédente montre qu’une entreprise emploie au moins
deux personnes et qu’une personne travaille dans au plus deux entreprises. Le diagramme d’objets
modélise lui une entreprise particulière (OSKAD) qui emploie trois personnes.
Un diagramme d’objets ne montre pas l’évolution du système dans le temps. Pour représenter une
interaction, il faut utiliser un diagramme de communication ou de séquence.
Représentation
Graphiquement, un objet se représente comme une classe. Cependant, le compartiment des opérations n’est pas utile. De plus, le nom de la classe dont l’objet est une instance est précédé d’un « : » et est souligné. Pour différencier les objets d’une même classe, leur identifiant peut être ajouté devant le nom de la classe.
Enfin les attributs reçoivent des valeurs. Quand certaines valeurs d’attribut d’un objet ne sont pas renseignées, on dit que l’objet est partiellement défini.
Dans un diagrammes d’objets, les relations du diagramme de classes deviennent des liens.
Graphiquement,
un lien se représente comme
La relation de dépendance d’instanciation (stéréotypée « instanceof ») décrit la relation entre un
classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux classes.
La composition, également appelée agrégation composite, décrit une contenance structurelle entre
instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants. Une
instance de la partie appartient toujours à au plus une instance de l’élément composite. Graphiquement, on ajoute un losange plein (_) du côté de l’agrégat.
Dépendance
Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre les
éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la modification de la cible implique une modification de la source. La dépendance est souvent
stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle
Interfaces
Les classes permettent de définir en même temps un objet et son interface. Le classeur, que nous décrivons dans cette section, ne permet de définir que des éléments d’interface. Il peut s’agir de l’interface complète d’un objet, ou simplement d’une partie d’interface qui sera commune à plusieurs objets.
Le rôle de ce classeur, stéréotypé « interface », est de regrouper un ensemble de propriétés et d’opérations assurant un service cohérent.
Une interface est représentée comme une classe excepté l’absence du mot-clef abstract (car l’interface et toutes ses méthodes sont, par définition, abstraites) et l’ajout du stéréotype « interface ».
Une interface doit être réalisée par au moins une classe. Graphiquement, cela est représenté par un
trait discontinu terminé par une flèche triangulaire et le stéréotype « realize ». Une classe (classe cliente de l’interface) peut dépendre d’une interface (interface requise).
On représente cela par une relation de dépendance et le stéréotype « use ».
Élaboration d’un diagramme de classes
Il y a au moins trois points de vue qui guident la modélisation (Steve Cook et John Daniels) :
– Le point de vue spécification met l’accent sur les interfaces des classes plutôt que sur leurs contenus.
– Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Il s’intéresse
peu ou prou à la manière éventuelle d’implémenter ces concepts et relations et aux langages
d’implémentation.
– Le point de vue implémentation, le plus courant, détaille le contenu et l’implémentation de chaque
classe.
En fonction du point de vue adopté, vous obtiendrez des modèles différents. Une démarche couramment utilisée pour bâtir un diagramme de classes consiste à :
Trouver les classes du domaine étudié. Cette étape empirique se fait généralement en collaboration avec un expert du domaine. Les classes correspondent généralement à des concepts ou des substantifs du domaine.
Trouver les associations entre classes. Les associations correspondent souvent à des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme « est composé de », « pilote », « travaille pour ». Attention, méfiez vous de certains attributs qui sont en réalité des relations entre classes.
Trouver les attributs des classes. Les attributs correspondent souvent à des substantifs, ou des groupes nominaux, tels que « la masse d’une voiture » ou « le montant d’une transaction ». Les adjectifs et les valeurs correspondent souvent à des valeurs d’attributs. Vous pouvez ajouter des attributs à toutes les étapes du cycle de vie d’un projet (implémentation comprise). N’espérez pas trouver tous les attributs dès la construction du diagramme de classes.
Organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage.
Vérifier les chemins d’accès aux classes.
Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première construction. La modélisation objet est un processus non pas linéaire mais itératif.
Diagramme d’objets (object diagram)
Présentation
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue de l’état du système à un instant donné. Un diagramme d’objets permet, selon les situations, d’illustrer le modèle de classes (en montrant un exemple qui explique le modèle), de préciser certains aspects du système (en mettant en évidence des détails imperceptibles dans le diagramme de classes), d’exprimer une exception (en modélisant des cas particuliers, des connaissances non généralisables . . .), ou de prendre une image (snapshot) d’un système à un moment donné. Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits.
Par exemple, le diagramme de classes de la précédente montre qu’une entreprise emploie au moins
deux personnes et qu’une personne travaille dans au plus deux entreprises. Le diagramme d’objets
modélise lui une entreprise particulière (OSKAD) qui emploie trois personnes.
Un diagramme d’objets ne montre pas l’évolution du système dans le temps. Pour représenter une
interaction, il faut utiliser un diagramme de communication ou de séquence.
Représentation
Graphiquement, un objet se représente comme une classe. Cependant, le compartiment des opérations n’est pas utile. De plus, le nom de la classe dont l’objet est une instance est précédé d’un « : » et est souligné. Pour différencier les objets d’une même classe, leur identifiant peut être ajouté devant le nom de la classe.
Enfin les attributs reçoivent des valeurs. Quand certaines valeurs d’attribut d’un objet ne sont pas renseignées, on dit que l’objet est partiellement défini.
Dans un diagrammes d’objets, les relations du diagramme de classes deviennent des liens.
Graphiquement,
un lien se représente comme
La relation de dépendance d’instanciation (stéréotypée « instanceof ») décrit la relation entre un
classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux classes.
Commentaires