Editions ENI Livres | Vidéos | e-Formations
La modélisation des objets
Introduction
L’objectif de ce chapitre est de vous faire découvrir les techniques UML de modélisation statique des objets.
Cette modélisation est statique car elle ne décrit pas les interactions ou le cycle de vie des objets. Les méthodes sont introduites d’un point de vue statique, sans description de leur enchaînement.
Nous découvrirons le diagramme de classes. Ce diagramme contient les attributs, les méthodes et les associations des objets. Comme nous l’avons vu au chapitre Les concepts de l’approche par objets, cette description est réalisée par les classes.
Ce diagramme est central lors d’une modélisation par objets d’un système. De tous les diagrammes UML, il est le seul obligatoire lors d’une telle modélisation.
Nous étudierons comment le langage OCL (Object Constraint Language ou langage de contraintes objet) peut étendre le diagramme de classes pour exprimer de façon plus riche les contraintes. Ensuite, le diagramme d’objets nous montrera comment illustrer la modélisation réalisée dans le diagramme de classes. Enfin, nous découvrirons comment décrire les objets composés au moyen du diagramme de structure composite.
L’emploi d’OCL, du diagramme d’objets ou du diagramme de structure composite est optionnel. Leur utilisation dépend des contraintes du projet de modélisation.
Découvrir les objets du système par décomposition
Au chapitre La modélisation de la dynamique, nous avons étudié comment découvrir les objets d’un point de vue dynamique. Nous avons présenté les cas d’utilisation sous forme de diagrammes de séquence. Puis nous avons enrichi ces diagrammes au niveau de l’envoi de message pour découvrir les objets du système.
La décomposition des messages fait apparaître les objets du système, car elle conduit à des messages plus fins dont il convient de rechercher le destinataire.
Une autre approche possible est la décomposition de l’information contenue dans un objet. Souvent, cette information est trop complexe pour n’être représentée que par la structure d’un seul objet. Elle doit parfois être également répartie entre plusieurs objets.
Exemple
Dans l’exemple du chapitre La modélisation de la dynamique, le directeur recherche les papiers (dans le sens d’informations) de la jument à vendre dans la base de données de l’élevage. Cette base constitue un objet à grosse granularité composé lui-même d’autres objets, comme les papiers des chevaux, les informations financières et comptables, les documents d’achat et de vente de chevaux. Les papiers d’une jument sont composés, entre autres, de son carnet de vaccination et des papiers de ses descendants. Les papiers des descendants sont partagés par d’autres objets, comme les papiers de leur père étalon. Cette décomposition est guidée par les données et non par des aspects dynamiques. La figure 6.1 illustre la composition de PapiersJument dans le diagramme de classes.
Figure 6.1 - Composition de PapiersJument
Rappelons que la granularité d’un...
La représentation des classes
1. La forme simplifiée de représentation des classes
Les objets du système sont décrits par des classes dont une forme simplifiée de la représentation en UML est donnée à la figure 6.4. Cette représentation est constituée de trois parties.
Figure 6.4 - Représentation simplifiée d’une classe en UML
La première partie contient le nom de la classe.
Rappelons que le nom d’une classe est au singulier. Il est constitué d’un nom commun précédé ou suivi d’un ou plusieurs adjectifs qualifiant le nom. Ce nom est significatif de l’ensemble des objets constituant la classe. Il représente la nature des instances d’une classe.
La deuxième partie contient les attributs. Ceux-ci contiennent l’information portée par un objet. L’ensemble des attributs forme la structure de l’objet.
La troisième partie contient les méthodes. Celles-ci correspondent aux services offerts par l’objet. Elles peuvent modifier la valeur des attributs. L’ensemble des méthodes forme le comportement de l’objet.
Le nombre d’attributs et de méthodes est variable selon chaque classe. Toutefois, un nombre élevé d’attributs et/ou de méthodes est déconseillé. Il ne reflète pas, en général, une bonne conception de la classe.
Exemple
La figure 6.5 montre la classe Cheval comme exemple de la représentation simplifiée d’une classe en UML.
Figure 6.5 - La classe Cheval
Cette forme de représentation des classes est la plus simple car elle ne fait pas apparaître les caractéristiques des attributs et des méthodes en dehors de leur nom. Elle est très souvent utilisée lors d’une première phase de modélisation....
Les associations entre objets
1. Les liens entre objets
Dans le monde réel, de nombreux objets sont liés entre eux. Ce lien correspond à une association qui existe entre les objets.
Exemples
-
Le lien qui existe entre le poulain Espiègle et son père.
-
Le lien qui existe entre le poulain Espiègle et sa mère.
-
Le lien qui existe entre la jument Jorphée et l’élevage de chevaux auquel elle appartient.
-
Le lien qui existe entre l’élevage de chevaux Heyde et son propriétaire.
En UML, ces liens sont décrits par une association, comme un objet est décrit par une classe. Un lien est une occurrence d’une association.
Par conséquent, une association relie des classes. Chaque occurrence de cette association relie entre elles des instances de ces classes.
Une association porte un nom. Comme pour une classe, ce nom est significatif des occurrences de l’association.
Exemples
-
L’association père entre la classe Descendant et la classe Étalon.
-
L’association mère entre la classe Descendant et la classe Jument.
-
L’association appartient entre la classe Cheval et la classe ÉlevageChevaux.
-
L’association propriétaire entre la classe ÉlevageChevaux et la classe Personne.
Les associations que nous avons examinées jusqu’à présent, à titre d’exemple, relient deux classes. De telles associations sont appelées associations binaires. Une association reliant trois classes est appelée association ternaire. Une association reliant n classes est appelée association n-aire. Dans la pratique, la très grande majorité des associations sont binaires et les associations quaternaires et au-delà ne sont quasiment jamais utilisées.
2. La représentation des associations entre les classes
La représentation graphique d’une...
La relation de généralisation/spécialisation entre les classes
1. Les classes plus spécifiques et les classes plus générales
Une classe est plus spécifique qu’une autre si toutes ses instances sont également instances de cette autre classe. La classe plus spécifique est dite sous-classe de l’autre classe. Cette dernière, plus générale, est dite surclasse.
La figure 6.39 illustre ces deux classes ainsi que la relation de généralisation/spécialisation qui les relie.
Figure 6.39 - Sous-classe et surclasse
Exemple
Le cheval est une spécialisation de l’équidé, elle-même spécialisation de l’animal. Le zèbre est une autre spécialisation de l’équidé. Le résultat est la petite hiérarchie illustrée à la figure 6.40.
Figure 6.40 - Hiérarchie de classes
2. L’héritage
Les instances d’une classe sont aussi instances de sa ou de ses surclasses. En conséquence, elles profitent des attributs et des méthodes définis dans la ou les surclasses, en plus des attributs et des méthodes introduits au niveau de leur classe.
Cette faculté s’appelle l’héritage, c’est-à-dire qu’une classe hérite des attributs et méthodes de ses surclasses pour en faire bénéficier ses instances.
UML offre la possibilité de représenter les attributs et les méthodes hérités dans les sous-classes en les faisant précéder du symbole ^.
Rappelons que les attributs et méthodes privés d’une surclasse sont hérités dans ses sous-classes mais n’y sont pas visibles.
Lors d’un héritage, une méthode ou un attribut peuvent être redéfinis dans la sous-classe....
Les différents stéréotypes de classe
Un stéréotype sert à spécialiser un élément d’UML à l’image des stéréotypes de classe «abstract» et «interface». Nous donnons à la suite une liste des principaux stéréotypes de classe.
«abstract» : ce stéréotype indique qu’une classe est abstraite.
«auxiliary» : il s’agit d’une classe secondaire d’un système. Les classes secondaires servent au support des classes principales.
«focus» : il s’agit d’une classe principale d’un système. Ce stéréotype s’oppose au stéréotype «auxiliary».
«implementation class» : une classe d’implantation fournit la réalisation d’une classe «type».
«type» : une classe «type» correspond à un type de données abstrait en introduisant les attributs et les méthodes abstraites, mais sans fournir aucune réalisation. Une telle classe est abstraite et se distingue d’une interface par l’introduction d’attributs.
«interface» : ce stéréotype précise qu’une classe est une interface.
«utility» : ce stéréotype introduit la notion de classe utilitaire qui ne possède que des attributs de classe dotés de la propriété {readOnly}, c’est-à-dire des constantes ainsi que des méthodes de classe. Une telle classe n’a pas vocation à être instanciée.
«enumeration» : une énumération est une classe particulière qui introduit un type de données dont les valeurs sont précisées...
Les classes template
Une classe concrète est un modèle qui peut être instancié pour créer des objets. De façon analogue, une classe template est un modèle de classes. Elle possède des paramètres qui lui confèrent un aspect générique. Ces paramètres sont typés à l’image des paramètres d’une méthode, et ce, en utilisant tous les types disponibles. Le principal type rencontré est Type, un type standard d’UML, comme Integer ou String. Il sert donc à fixer le type d’attributs, de paramètres de méthode, etc.
Type est une classe du métamodèle d’UML. Le métamodèle est un modèle UML où les éléments décrits sont les éléments d’UML. Il contient la description des classes, des types, des associations, des attributs, des méthodes, etc. Ainsi la classe Type décrit tous les types rencontrés dans un modèle UML, y compris dans le métamodèle. Les instances de Type sont notamment les types standard d’UML ainsi que les classes de tout modèle ou du métamodèle. Par exemple, Integer, String, la classe Cheval sont des instances de Type. La classe du métamodèle Class qui décrit les classes et la classe Type elle-même sont aussi des instances de Type. Précisons encore qu’il n’est pas nécessaire de connaître le métamodèle d’UML pour utiliser les classes template.
La valeur de ces paramètres est fixée par une relation de liaison (binding) du template qui montre la liaison entre une classe instanciée et sa classe template. Cette relation de liaison est l’équivalent, pour les classes template, de la relation d’instanciation qui relie un objet à...
Les objets ou instances
1. La représentation des objets
Le diagramme de classes est une représentation statique du système. Il peut également montrer les objets, c’est-à-dire, à un moment donné, les instances créées et leurs liens lorsque le système est actif.
Chaque instance est représentée dans un rectangle qui contient son nom en style souligné et, éventuellement, la valeur d’un ou de plusieurs attributs.
Le nom d’une instance prend la forme :
nomInstance : nomClasse Le nom de l’instance est optionnel.
La valeur d’un attribut est de la forme :
nomAttribut = valeurAttribut Exemple
La figure 6.58 montre l’instance Jorphée, instance de la classe Cheval, dont la description est donnée à la figure 6.8.
Figure 6.58 - Exemple d’objet : la jument Jorphée
2. La relation d’instanciation
La relation d’instanciation décrit le lien qui existe entre une instance et sa classe. Cette relation est décrite dans le nom de l’instance qui est suffixé par le nom de la classe. Il est également possible de préciser cette relation entre l’instance et sa classe en utilisant une relation de dépendance munie du stéréotype «instanceOf». Cette dernière représentation est toutefois moins courante.
Exemple
La figure 6.59 montre l’instance Jorphée et sa classe Cheval. La relation d’instanciation est précisée de deux façons. Tout d’abord, le nom Jorphée est suffixé par le nom Cheval. Ensuite, la figure inclut une relation de dépendance entre Jorphée et la classe Cheval. Cette relation est dotée du stéréotype «instanceOf».
Figure 6.59 - Représentation de la relation d’instanciation...
Le diagramme de structure composite
1. La description d’un objet composé
Le diagramme de structure composite a pour premier objectif de décrire précisément un objet composé. Un tel diagramme n’a pas vocation à remplacer le diagramme de classes mais à le compléter.
Dans le diagramme de structure composite, l’objet composé est décrit par un classificateur tandis que ses composants sont décrits par des parties. Un classificateur et une partie sont associés à une classe, dont la description complète est réalisée dans un diagramme de classes.
Considérons l’objet composé décrit par le diagramme de classes de la figure 6.61. Il possède un composant issu d’une composition forte et un autre issu d’une agrégation.
Figure 6.61 - Objet composé
La figure 6.62 montre le diagramme de structure composite correspondant à cet objet. Les composants sont intégrés au sein du classificateur qui décrit l’objet composé. Les parties possèdent un type qui est la classe du composant. La cardinalité est indiquée entre crochets. Par défaut, elle vaut 1. Un composant issu d’une agrégation est représenté par une ligne en pointillés, un composant issu d’une composition forte est représenté par une ligne continue.
Figure 6.62 - Diagramme de structure composite
Exemple
La figure 6.63 illustre un exemple de diagramme de structure composite décrivant une automobile en tant qu’objet composé. Le diagramme de classes correspondant est représenté en dessous.
Figure 6.63 - Exemple de diagramme de structure composite
Dans le diagramme de structure composite, Moteur, Carrosserie et Roue ne sont pas des classes mais des parties. Une partie...
Conclusion
Dans ce chapitre, nous avons étudié le diagramme de classes. Les classes décrivent les attributs et les méthodes de leurs instances, ainsi que les attributs et méthodes de classe.
Les associations entre objets sont obligatoires lors de la conception d’un diagramme de classes. Elles constituent le socle de l’interaction des instances par les envois de message lorsque le système est actif.
Les relations d’héritage entre les classes sont également indispensables. Elles favorisent la factorisation d’éléments communs et permettent ainsi de réduire conséquemment la taille du diagramme.
L’expression des contraintes en UML, en langage naturel ou en OCL conduit à enrichir encore la sémantique exprimée dans le diagramme.
Enfin, nous avons étudié le diagramme de structure composite qui complète le diagramme de classes en offrant une description plus fine des objets composés.
Exercices
1. La hiérarchie des chevaux
Soit les classes Jument, Étalon, Poulain, Pouliche, Cheval, ChevalMâle et ChevalFemelle ainsi que les associations père et mère. Établissez la hiérarchie des classes en y faisant figurer les deux associations.
Utilisez les contraintes {incomplete}, {complete}, {disjoint} et {overlapping}.
Introduisez la classe Troupeau. Établissez l’association de composition entre cette classe et les classes déjà introduites.
2. Les produits pour chevaux
Modélisez les aspects statiques du texte suivant sous la forme d’un diagramme de classes.
Une centrale des chevaux vend différents types de produits pour chevaux : produits d’entretien, nourriture, équipement (pour monter le cheval), ferrures.
Une commande contient un ensemble de produits avec, pour chacun d’eux, la quantité. Un devis est éventuellement établi avant le passage de la commande. En cas de rupture de stock, la commande peut engendrer plusieurs livraisons si le client le désire. Chaque livraison donne lieu à une facture.
