Création de dia­grammes de classes avec UML

Les dia­grammes de classes sont des dia­grammes de structure au sein du Unified Modeling Language, abrégé UML. Le langage de mo­dé­li­sa­tion UML est une norme ISO. Il illustre les systèmes de pro­gram­ma­tion orientés objet. Les processus d’affaires peuvent également être clai­re­ment en­re­gis­trés. En utilisant des moyens visuels, UML montre les états des systèmes et décrit les in­te­rac­tions entre les éléments du système. La notation définit les formes et les lignes pour 14 types de dia­grammes.

La mé­ta­mo­dé­li­sa­tion décrit à la fois les éléments in­di­vi­duels du langage de mo­dé­li­sa­tion et le langage lui-même. Il définit des unités lin­guis­tiques pour dif­fé­rents niveaux. Une unité de parole dans ce langage visuel est, par exemple, le com­por­te­ment. Il décrit à la fois une mé­ta­classe et un terme générique pour tous les facteurs dy­na­miques d’un système. Une autre unité de langage est l’objet, l’élément de base de la pro­gram­ma­tion orientée objet. Les dia­grammes de classes UML mo­dé­li­sent les objets comme des instances de classes. Le diagramme de classes est donc l’un des types de dia­grammes les plus im­por­tants et les plus fré­quem­ment utilisés en UML.

Les types de dia­grammes sont divisés en deux grandes ca­té­go­ries selon leur fonction : les dia­grammes de structure et les dia­grammes de com­por­te­ment. Ces derniers ont une sous-catégorie : les dia­grammes d’in­te­rac­tion. Ceux-ci ne mo­dé­li­sent pas seulement le com­por­te­ment général d’un système, mais se con­centrent également sur les flux d’in­for­ma­tions entre les objets au cours d’un processus. Ceci inclut, par exemple, les dia­grammes de séquence. Vous modélisez l’ordre chro­no­lo­gique des messages qui circulent dans un cas d’uti­li­sa­tion détaillé. Les dia­grammes de com­por­te­ment vi­sua­li­sent les processus dy­na­miques. Un exemple en est le diagramme d’activité. Ceci montre comment les actions in­di­vi­duelles in­te­ra­gis­sent dans un processus. Les dia­grammes struc­tu­rels, par contre, montrent les états statiques : ils il­lustrent les éléments d’un système et leurs in­ter­dé­pen­dances.

Le diagramme de classes affecte des instances d’objets à des classes spé­ci­fiques en fonction de leurs pro­prié­tés, il existe donc une dé­pen­dance hié­rar­chique. En même temps, il existe des relations entre dif­fé­rentes classes ou entre objets.

Les dia­grammes de classes re­pré­sen­tent des états avec des éléments de système. Ils montrent les struc­tures jusqu’à la plus petite instance. Par con­sé­quent, ils sont adaptés à la pré­sen­ta­tion d’ar­chi­tec­tures lo­gi­cielles dé­tail­lées. Des étapes concrètes de pro­gram­ma­tion peuvent en être déduites. Certains en­vi­ron­ne­ments de pro­gram­ma­tion supportés par logiciel con­ver­tis­sent ces dia­grammes UML di­rec­te­ment en trames de code. Le partage d’équipe permet aux dé­ve­lop­peurs de com­mu­ni­quer entre eux ou avec d’autres décideurs au sein d’une en­tre­prise. Un diagramme UML fournit une vue d’ensemble des struc­tures de système ou des flux de processus planifiés pour ceux qui ne sont pas familiers avec le sujet. Il peut également être utilisé pour formuler les exigences du système, que les dé­ve­lop­peurs mettent ensuite en œuvre. Les pro­fes­sion­nels de l’in­for­ma­tique peuvent modéliser et modifier ef­fi­ca­ce­ment les dia­grammes entre eux sans avoir à pro­gram­mer des en­vi­ron­ne­ments ou des processus plus vastes pendant la phase de pla­ni­fi­ca­tion.

Ce sont les domaines d’ap­pli­ca­tion des dia­grammes de classes :

• Ils décrivent les types au sein d’un système. La re­pré­sen­ta­tion graphique peut être trans­fé­rée dans dif­fé­rents langages et en­vi­ron­ne­ments de pro­gram­ma­tion. Il existe donc in­dé­pen­dam­ment de l’ap­pli­ca­tion future.
• Vous modélisez les ar­chi­tec­tures lo­gi­cielles exis­tantes. Si des com­po­sants sup­plé­men­taires doivent être intégrés, ils vi­sua­li­sent les struc­tures ap­pro­priées sur les­quelles de nouveaux com­po­sants peuvent être installés. Pour les futurs éléments du système, les dia­grammes de classes créent une ligne di­rec­trice pour le code du programme. Selon les besoins, cette étape peut être sommaire ou très détaillée.
• Ils re­pré­sen­tent des modèles de données. Ils sont adaptés à des systèmes de com­plexité variable.
• Avec des ap­pli­ca­tions im­bri­quées, la do­cu­men­ta­tion et la main­te­nance peuvent devenir très complexes. Les dia­grammes de classes four­nis­sent une vue d’ensemble du schéma.
• Ils re­pré­sen­tent les exigences lo­gi­cielles. En tant que fichiers image, ils peuvent être fa­ci­le­ment trans­fé­rés via les canaux internes de l’en­tre­prise. Ils per­met­tent ainsi à des experts de dif­fé­rents dé­par­te­ments d’échanger des in­for­ma­tions sur l’ar­chi­tec­ture.
• Le standard UML utilise des dia­grammes de classes pour vi­sua­li­ser sa propre notation.

La classe est un élément de modèle dans le diagramme de classes et une spé­cia­li­sa­tion de l’En­cap­su­la­ted­Clas­si­fier et du Be­ha­vio­red­Clas­si­fier. Elle résume beaucoup d’exemples. Les instances d’objets d’une classe ca­rac­té­ri­sent les mêmes ca­rac­té­ris­tiques (attributs) et com­por­te­ments (méthodes). De plus, elles ont la même sé­man­tique, c’est-à-dire qu’elles utilisent les mêmes signes avec la même sig­ni­fi­ca­tion. La classe est donc une sorte de modèle pour ses objets. Elle instancie les objets et définit leur com­por­te­ment dans le système.

Vous ajoutez ces pro­prié­tés à la notation lorsque vous créez un diagramme de classes. En UML, une classe est re­pré­sen­tée par un rectangle avec une ligne continue. Son corps se compose de trois com­par­ti­ments disposés les uns au-dessus des autres. Seule la partie su­pé­rieure doit être modélisée, car vous spécifiez ici le nom de la classe. Les deux autres par­ti­tions peuvent op­tion­nel­le­ment être éti­que­tées avec des attributs (centre) et des opé­ra­tions (bas). Vous attribuez une vi­si­bi­lité dif­fé­rente à ces éléments en écrivant les symboles suivants devant leur nom :

• + = public
• - = privé
• # = protégé
• / = dérivée
• ~ = Paquet
• * = aléatoire

Les pro­prié­tés sont des éléments connectés. Les attributs de classe (ow­ne­dAt­tri­butes) sont toujours des rôles. Ils sont reliés entre eux par des con­nec­teurs. S’ils ont la propriété is­Com­po­site= true (« est composé = true »), ils sont appelés parties.

La propriété UML est une ca­rac­té­ris­tique struc­tu­relle qui a plusieurs domaines d’ap­pli­ca­tion. En plus de la fonction en tant qu’attribut dans une classe, elle peut également re­pré­sen­ter des fins d’as­so­cia­tion.

Le type de propriété est dérivé du nom du clas­si­fi­ca­teur. Si vous le souhaitez, vous pouvez définir une valeur par défaut pour une ca­rac­té­ris­tique. De plus, les mo­di­fi­ca­teurs dé­ter­mi­nent plus en détail le com­por­te­ment d’une ca­rac­té­ris­tique :

• ordonné (notation : isOrdered = true)
• unique (notation : isUnique = true)
• non unique (notation : isUnique = false)
• lecture seule (la ca­rac­té­ris­tique ne peut être lue, notation : is­Rea­dOnly = true)
• Séquence (la ca­rac­té­ris­tique est une col­lec­tion ordonnée, notation : isUnique = faux et isOrdered = vrai)
• As­so­cia­tion (as­so­cia­tion dérivée de sous-ensembles, notation : union)
• ID (ap­par­tient à la dé­sig­na­tion de son clas­si­fi­ca­teur, notation : id)
• Dé­li­mi­ta­tion du caractère (une dé­li­mi­ta­tion qui influence le caractère, notation : propriété-con­trainte)
• Re­dé­fi­ni­tion d’une ca­rac­té­ris­tique (redéfinit une ca­rac­té­ris­tique héritée, nommée, notation : redéfinit [nom de la ca­rac­té­ris­tique])
• Sous-ensemble de la ca­rac­té­ris­tique (symbolise une ca­rac­té­ris­tique qui est un sous-ensemble d’une ca­rac­té­ris­tique nommée, notation : sous-ensembles [nom de la ca­rac­té­ris­tique])

Les opé­ra­tions sont des fonctions com­por­te­men­tales. Ils se pro­dui­sent dans les classes, mais aussi dans les types de données ou les in­ter­faces. Vous appelez di­rec­te­ment l’instance d’une classe. L’opération détermine les aspects suivants d’un appel :

• Nom
• Type
• Pa­ra­mètres
• Con­traintes

L’opération ap­par­tient à son clas­si­fi­ca­teur supérieur. Ceci peut les modifier en re­dé­fi­nis­sant le type ou le paramètre.

Il y a des con­di­tions préa­lables à l’opération. Ces con­di­tions doivent être remplies avant l’exécution de l’opération. Toutefois, UML ne définit pas le com­por­te­ment d’un appel de com­por­te­ment si les con­di­tions préa­lables ne sont pas remplies. Vous dé­fi­nis­sez également les con­di­tions ul­té­rieures qui doivent être remplies lorsque l’opération est terminée. Les con­di­tions cor­po­relles limitent le résultat de sortie à une valeur calculée à partir de leurs spé­ci­fi­ca­tions. Cette valeur doit répondre aux con­di­tions a pos­te­riori. Toutefois, l’opération peut également provoquer une exception pendant son exécution. Dans ce cas, il ne remplit pro­ba­ble­ment pas les con­di­tions post con­di­tion­nelles.

La notation pour le diagramme de classe prescrit que les opé­ra­tions dans un com­par­ti­ment sont notées dans le corps de la classe. Selon le standard UML, ces in­for­ma­tions sont obli­ga­toires. En même temps, UML permet de supprimer toutes les spé­ci­fi­ca­tions standards d’une classe. Seul le nom doit être noté.

Un récepteur de signal indique qu’un clas­si­fi­ca­teur est prêt à accepter un signal. Il définit également les types de signaux que les instances de la classe acceptent. Le récepteur de signal porte le même nom que son signal. Vous notez les in­for­ma­tions cor­res­pon­dantes dans le corps de la classe, dans un com­par­ti­ment sous les opé­ra­tions.

Il s’agit de ports pour les clas­si­fi­ca­teurs en­cap­su­lés. Ils re­pré­sen­tent un point d’in­te­rac­tion entre le clas­si­fi­ca­teur et son en­vi­ron­ne­ment. Outre les ports, le clas­si­fi­ca­teur encapsulé est un système autonome. Étant donné que ses éléments struc­tu­rels et com­por­te­men­taux internes ne sont pas affectés par le reste du système, vous pouvez également définir ce clas­si­fi­ca­teur in­dé­pen­dam­ment. Tant qu’un système respecte les limites du port, vous pouvez réu­ti­li­ser le clas­si­fi­ca­teur encapsulé dans dif­fé­rents en­vi­ron­ne­ments.

En outre, UML autorise plusieurs points d’ancrage par clas­si­fi­ca­teur. Vous pouvez définir des règles dis­tinctes pour chaque port. Le port est une propriété du clas­si­fi­ca­teur, vous dé­fi­nis­sez donc ses règles dans la zone Pro­prié­tés. Cela inclut les services que le clas­si­fi­ca­teur offre à son en­vi­ron­ne­ment et les services dont il a besoin. Vous dif­fé­ren­ciez les dif­fé­rents flux d’in­for­ma­tion en iden­ti­fiant le port utilisé pour eux.

Les ports eux-mêmes ont aussi des pro­prié­tés. Lorsque le port exécute les fonctions publiées du clas­si­fi­ca­teur, il affiche la propriété isService. Si isService = true, le port est considéré comme un composant in­dis­pen­sable des fonctions du clas­si­fi­ca­teur encapsulé qui sont visibles de l’extérieur. Avec isService = false, le port n’est pas l’une des ca­rac­té­ris­tiques es­sen­tielles et peut donc être modifié ou supprimé tout comme les autres fonctions internes.

Les ports in­te­ra­gis­sent avec les in­ter­faces. Il existe des in­ter­faces fournies et né­ces­saires (voir « In­ter­faces » ci-dessous). L’interface qui est connectée au port spécifie les in­te­rac­tions qui passent par le port. Comme le site d’amarrage est une propriété, il a un type. La valeur d’is­Con­ju­ga­ted sert de médiateur entre le type et l’interface du port. Si la valeur est vraie, l’interface requise peut être dérivée di­rec­te­ment du type de port ou de l’ensemble des in­ter­faces que le type de port im­plé­mente. Dans ce cas, une interface fournie est dérivée du nombre d’in­ter­faces. Si is­Con­ju­ga­ted est vrai, l’interface fournie est dérivée du type.

Lorsqu’un clas­si­fi­ca­teur encapsulé génère une instance, des instances cor­res­pon­dantes sont créées pour chacun de ses ports. Un port tient l’instance en fonction de son type et de sa mul­ti­pli­cité (voir ci-dessous). Les instances sont appelées points d’in­te­rac­tion UML. Chaque instance possède des ré­fé­rences uniques qui dis­tin­guent les dif­fé­rentes demandes de fonctions com­por­te­men­tales adressées à ses ports.

Ports avec la propriété is­Be­ha­vior = true envoie une requête à l’instance du clas­si­fi­ca­teur encapsulé. La requête adopte le com­por­te­ment spécifié de l’instance. Les ports de com­por­te­ment ne dirigent pas les requêtes vers l’intérieur de votre clas­si­fieur. Si aucun com­por­te­ment n’est défini dans le diagramme de classes pour cela, les messages sont perdus sur ces ports.

Modéliser un port comme un petit carré sur le cadre du clas­si­fieur auquel il ap­par­tient. Dessinez l’interface requise ou fournie sur le port. Si vous ne spécifiez aucune ca­rac­té­ris­tique spéciale pour le port, dessinez l’interface sans le port.

Les con­nec­teurs dé­fi­nis­sent les con­nexions entre deux ou plusieurs instances. Le cahier des charges permet leur com­mu­ni­ca­tion. Con­trai­re­ment aux relations telles que les as­so­cia­tions, les con­nec­teurs ne con­nec­tent que les instances qui sont définies comme pièces de connexion. Modéliser les con­nec­teurs en tant que bords avec au moins deux ex­tré­mi­tés. Ils re­pré­sen­tent les instances par­ti­ci­pantes qui at­tri­buent un type aux éléments liables.

Un autre paramètre important est la mul­ti­pli­cité. Ce paramètre spécifie le nombre d’instances qu’une classe struc­tu­rée peut former. Il limite également les attributs et les opé­ra­tions. C’est une partie de la structure interne, c’est un élément prescrit dans le corps de la classe. Vous le saisissez après les attributs et les opé­ra­tions. Topologie ap­par­tient également à cette section. Les nœuds (instances d’objets) se con­nec­tent aux réseaux to­po­lo­giques par des voies de com­mu­ni­ca­tion (Com­mu­ni­ca­tion­Paths).

Notez les mul­ti­pli­ci­tés comme suit :

<mul­ti­pli­cité> : <plage de mul­ti­pli­cité> [<dé­sig­na­tion de commande> , <iden­ti­fiant unique>]

La plage de mul­ti­pli­cité spécifie une valeur fixe ou une plage de début à fin :

• 0 = la classe ne forme pas d’instances (se produit rarement)
• 0..1 = soit aucune instance, soit une seule instance
• 1 ou 1...1 = exac­te­ment une instance
• 0..* ou seulement * = aucune instance ou plus avec valeur ouverte
• 1...* = une ou plusieurs instances avec valeur ouverte

L’ordre et l’unicité peuvent être exprimés par un ensemble (quantité) ou par des termes in­di­vi­duels séparés par des virgules. Selon la manière dont les nœuds du set sont uniques ou commandés, le set reçoit une des­crip­tion type. Dans la notation, vous décrivez les tailles in­di­vi­duelles comme étant com­man­dées/non com­man­dées ou uniques/non uniques.

Vous notez certains éléments res­treints dans l’UML comme texte, par exemple, un attribut d’une classe dans le diagramme de classes. Vous notez la res­tric­tion derrière l’élément de texte entre crochets courbes. Si le pro­prié­taire est un élément que vous re­pré­sen­tez comme un symbole, placez la res­tric­tion le plus près possible du symbole ; il devrait être évident que les deux éléments ont une relation sé­man­tique. Vous pouvez rendre la connexion encore plus claire en écrivant la res­tric­tion dans une icône de bloc-notes et en la con­nec­tant à son pro­prié­taire avec une ligne poin­til­lée.

Si la res­tric­tion affecte deux éléments, connectez les pro­prié­taires avec une ligne poin­til­lée. Vous écrivez la res­tric­tion entre pa­ren­thèses courbes dessus. Si vous placez une pointe de flèche à une extrémité, cela indique la position du pro­prié­taire dans une col­lec­tion d’éléments con­traints. La flèche pointe de la première position vers la seconde. Si plus de deux éléments ont la res­tric­tion, utilisez l’icône du bloc-notes et associez chaque élément à la res­tric­tion.

Les bords font également partie des éléments res­tric­tifs. Si vous modélisez plus de deux bords du même type, faites glisser la ligne poin­til­lée de con­trainte à travers tous les bords qui re­pré­sen­tent les éléments impliqués.

Les sté­réo­types dé­fi­nis­sent les ex­ten­sions des mé­ta­classes. Selon la spé­ci­fi­ca­tion UML, ils ap­par­tien­nent aux profils. Si un sté­réo­type décrit des pro­prié­tés sup­plé­men­taires de plusieurs mé­ta­classes, il ne peut décrire qu’une seule instance de la mé­ta­classe à la fois pendant l’exécution. Parmi les mé­ta­classes, le sté­réo­type joue un certain rôle. Parce qu’il ne peut jamais rester seul. Ils mo­dé­li­sent un sté­réo­type toujours en con­jonc­tion avec le clas­si­fi­ca­teur qu’il développe. Vous connectez la mé­ta­classe au sté­réo­type en mo­dé­li­sant une extension.

UML définit certains sté­réo­types de classes qui étendent votre diagramme de classes UML. Six sté­réo­types sont standards. Trois sté­réo­types, souvent utilisés mais pas nor­ma­li­sés, sont ceux avec lesquels vous mettez en œuvre le modèle « Model-View-Con­trol­ler » (MVC) en UML. Les trois sté­réo­types non standards sont :

• L’entité (notation : <>) : le sté­réo­type Entité définit une classe ou un objet. Chaque instance re­pré­sente une col­lec­tion de données. Il s’agit souvent de données système qui doivent être stockées pendant une période plus longue. L’entité assume le rôle du modèle à partir du modèle MVC. UML connaît ce sté­réo­type, mais l’affecte par défaut aux dia­grammes de com­po­sants. La notation fré­quem­ment utilisée n’énumère pas la spé­ci­fi­ca­tion. Ils mo­dé­li­sent l’entité comme un cercle reposant sur une courte ligne.
• La limite (notation : <>) : la limite est un sté­réo­type pour une classe ou un objet. Il cor­res­pond à peu près à l’élément View du motif MVC. La limite modélise la limite de votre système, par exemple une interface uti­li­sa­teur. Ils sont gé­né­ra­le­ment re­pré­sen­tés sous la forme d’un cercle, à partir duquel une ligne bifurque vers la gauche, qui rencontre une ligne verticale.
• L’élément de contrôle (notation : <>) : l’élément de contrôle re­pré­sente les mêmes éléments que le con­trô­leur sous MVC. Des classes ou objets avec des éléments de modèle sté­réo­ty­pés qui cor­res­pon­dent au com­por­te­ment du système ou qui con­trô­lent les flux. Dans le standard UML, le sté­réo­type <> assume des tâches si­mi­laires. Dessinez une instance de contrôle sous la forme d’un cercle avec une flèche ouverte sur la ligne.

Ces trois sté­réo­types peuvent aussi être dessinés comme une simple classe. Dans le rectangle, notez le nom du sté­réo­type respectif. Les mo­dé­li­sa­teurs utilisent prin­ci­pa­le­ment ces formes dans les dia­grammes de séquence. Si vous voulez en savoir plus sur les dia­grammes de contrôle des fron­tières d’entités, lisez notre article sur le diagramme de séquence avec UML.

Ces sté­réo­types stan­dar­di­sés con­vien­nent aux dia­grammes de classes :

• Focus (<>)
• Aide (<>)
• Type (<>)
• Classe d’ap­pli­ca­tion (<>)
• Méta-classe (<>)
• Uti­li­taire (<>)

La classe focus définit la logique métier de base ou le flux de contrôle des classes d’aide. Ceux-ci sup­por­tent la classe focus, qui connecte un ou plusieurs as­sis­tants. Elle définit im­pli­ci­te­ment les classes de soutien en éta­blis­sant une relation de dé­pen­dance avec elles (voir « La relation dirigée » ci-dessous). Si elle utilise des classes d’aide, elle les définit ex­pli­ci­te­ment. Le standard UML re­com­mande ce sté­réo­type en par­ti­cu­lier pour la phase de con­cep­tion, lorsque vous re­pré­sen­tez les flux de contrôle entre com­po­sants ou dé­fi­nis­sez la logique métier de base.

La classe d’aide agit gé­né­ra­le­ment en com­bi­nai­son avec la classe de fo­ca­li­sa­tion. Elle prend gé­né­ra­le­ment en charge les classes qui sont d’une im­por­tance cruciale pour le système. À cette fin, elle exécute des flux de contrôle se­con­daires et définit la logique sub­si­diaire. Si la classe aide supporte une classe focus, la dé­fi­ni­tion est explicite. Vous utilisez une relation de dé­pen­dance pour définir im­pli­ci­te­ment la classe prise en charge.

La classe type définit un domaine pour les objets de gestion. Elle spécifie également les opé­ra­teurs de ces objets. Le sté­réo­type de type peut avoir des attributs et des as­so­cia­tions. Toutefois, il ne décrit pas l’exécution physique de l’objet.

Certains langages de pro­gram­ma­tion (par exemple Java ou C++) n’au­to­ri­sent qu’une seule classe pour chaque instance. Avec UML, cependant, vous pouvez assigner une instance à plusieurs classes. La classe d’ap­pli­ca­tion construit un pont entre ces deux mondes. Ce sté­réo­type restreint la classe UML. Il détermine qu’une instance sous lui ne peut réaliser qu’une seule classe. La classe d’ap­pli­ca­tion peut im­plé­men­ter plusieurs types dif­fé­rents à cette fin. Pour exécuter avec succès un clas­si­fi­ca­teur qui lui est affecté, elle doit remplir deux con­di­tions : elle doit fournir toutes les opé­ra­tions du clas­si­fi­ca­teur et elles doivent avoir le com­por­te­ment défini pour le clas­si­fi­ca­teur. Toutefois, il n’est pas né­ces­saire que les attributs physiques et les as­so­cia­tions cor­res­pon­dent.

Puisque les formes de classe et de mé­ta­classe ne diffèrent pas, l’étiquette Metaclass indique qu’il s’agit du sté­réo­type Me­ta­classe. Les instances de cette classe sont elles-mêmes des classes. Avec ce sté­réo­type, vous tra­vail­lez à un niveau plus élevé d’abs­trac­tion.

La classe utility n’a pas d’instances. Elle n’identifie qu’une col­lec­tion d’attributs et d’opé­ra­tions nommés. Ils sont toujours statiques. Les attributs statiques ne changent pas lorsqu’ils sont appelés. Les opé­ra­tions statiques sont utilisées pour les entités ou les types d’entités. Si vous utilisez la classe uti­li­taire, vous devez spécifier les valeurs et les opé­ra­tions cor­res­pon­dantes dès le départ, car elles ne changent plus. Le sou­lig­ne­ment identifie ces éléments.

Il y a aussi des In­ter­faces Requises (Required In­ter­faces). Elles vi­sua­li­sent une relation de dé­pen­dance (voir « Relations » ci-dessous). Un élément a besoin d’un autre élément pour remplir toute la portée de ses propres fonctions. Dans ce cas, un clas­si­fi­ca­teur (ou une de ses instances) a besoin d’une interface. L’In­ter­fa­ceU­sage spécifie les exigences d’interface. Une ligne continue relie le clas­si­fi­ca­teur à un demi-cercle ouvert. Ceci symbolise l’interface. Notez le nom de l’interface aux deux re­pré­sen­tants sous le (demi)cercle.

Si une classe hérite d’une interface à une classe su­bor­don­née, modélisez l’interface qui la lie à la classe ou instance su­bor­don­née. Afficher la relation hié­rar­chique avec l’accent cir­con­flexe (^), par exemple, comme ^Interface 1.

Utilisez la notation de l’interface rec­tan­gu­laire, tracez un bord entre les deux nœuds. Dans le diagramme de classes, les bords mo­dé­li­sent les relations entre classes, instances ou com­po­sants. UML prescrit dif­fé­rentes lignes et flèches pour dif­fé­rentes fonctions et relations. Dans ce cas, connectez une classe avec l’interface requise à l’aide d’une flèche poin­til­lée avec une pointe ouverte. Donnez à la flèche l’étiquette <<use>>. Une interface fournie est reliée à une classe par une flèche en poin­til­lés avec une pointe fermée et non remplie. La flèche pointe toujours dans la direction de l’interface.

L’énu­mé­ra­tion est un type de données. Elles re­pré­sen­tent la valeur du dé­nom­bre­ment sous la forme d’un symbole de lettre de dé­nom­bre­ment. Comme vous pouvez le voir dans l’image ci-dessus, c’est sim­ple­ment un nom qui symbolise une certaine valeur. C’est à vous de choisir. Dans la liste « Rose Type », par exemple, le nom « Tea Roses » re­pré­sente le nombre de tea roses qu’un fleuriste a dans son as­sor­ti­ment. Dans le diagramme de classes, dessinez ce clas­si­fi­ca­teur avec le symbole de la classe, un rectangle. Le nom et l’étiquette <<enu­me­ra­tion>> sont dans l’en-tête. Ils séparent la zone de la tête du corps par des lignes ho­ri­zon­tales en com­par­ti­ments.

Comme pour les autres classes, l’énu­mé­ra­tion réserve les sections su­pé­rieures pour les attributs et les opé­ra­tions. Si celles-ci sont restées vides, laissez les deux dé­par­te­ments en dehors du diagramme. Dans la partie in­fé­rieure, entrez les symboles de votre lettre d’énu­mé­ra­tion. Par exemple, la liste des espèces de roses chez un fleuriste se compose de la tête intitulée « espèces de roses » ou « Rose Type » dans notre exemple en anglais et du corps avec une liste : roses thé, roses noisette, roses gallica, roses bourbon, roses cannelle.

Les dia­grammes de classes re­pré­sen­tent les relations entre les éléments du système. De cette façon, le spec­ta­teur peut voir de quels com­po­sants le système a besoin et comment ils s’in­fluen­cent mu­tuel­le­ment. La relation élément UML est une classe abstraite. Elle re­pré­sente l’idée d’une relation entre les com­po­sants du système. Par con­sé­quent, cet élément n’a pas de notation distincte. Cependant, ses ca­rac­té­ris­tiques ont des détails spé­ci­fiques qui les dis­tin­guent.

En UML, les relations sont comprises comme des bords entre nœuds. De cette façon, vous modélisez gé­né­ra­le­ment les relations avec une ligne ou avec des va­ria­tions de celle-ci, comme la flèche.

La dé­fi­ni­tion UML pour les sous-classes et instances de relations a changé ra­di­ca­le­ment d’UML 1 à UML 2. À l’origine, par exemple, il y avait des relations sé­man­tiques, struc­tu­relles et dirigées. UML a affecté trois relations concrètes (as­so­cia­tion, res­tric­tion et dé­pen­dance) aux relations sé­man­tiques. Sous UML 2, les li­mi­ta­tions sont main­te­nant des éléments packables, les as­so­cia­tions dé­fi­nis­sent certaines sources comme des relations struc­tu­relles et sé­man­tiques. La dé­pen­dance fonc­tionne main­te­nant sous des relations dirigées.

Il reste à voir comment la norme changera dans les versions futures. Dans ce qui suit, nous ex­pli­quons les dia­grammes de classes selon UML 2.5. En con­sé­quence, la relation mé­ta­classe a deux sous-classes : la relation dirigée et l’as­so­cia­tion.

Le sous-type Com­po­si­tion (Composite Ag­gre­ga­tion) décrit la relation entre une com­po­si­tion de parties et une partie unique de celle-ci. Si le système supprime le tout (la com­po­si­tion), il détruit également la pièce in­di­vi­duelle. Si, par exemple, un arbre est la chose entière, alors une feuille en fait partie. Si l’arbre est victime d’un feu de forêt, le feu détruit également les feuilles. Par exemple, lorsque vous créez un diagramme de classes et re­pré­sen­tez cette relation, vous tracez une ligne continue entre les instances. Modéliser un losange noir sur le côté de la com­po­si­tion (dans cet exemple : l’instance « arbre »). Cette page est aussi appelée fin d’agré­ga­tion.

Le deuxième sous-type d’agré­ga­tion est l’agré­ga­tion frac­tion­née (abrégée en agré­ga­tion simple). Cette relation asy­mé­trique existe entre une propriété (Property) et une instance qui re­pré­sente un ensemble d’instances. La connexion doit être faite di­rec­te­ment. Sinon, une instance de com­po­si­tion pourrait être in­ter­pré­tée comme faisant partie d’elle-même. Ceci peut se produire si vous modélisez la relation de dé­pen­dance de façon cyclique. La propriété partagée peut ap­par­te­nir à plusieurs com­po­si­tions. En même temps, leur instance peut exister in­dé­pen­dam­ment de la com­po­si­tion. Dans ce cas, si le système supprime une com­po­si­tion (ou la totalité), la substance peut toujours exister. Par con­sé­quent, cette relation est con­si­dé­rée comme faible par rapport à la com­po­si­tion.

L’as­so­cia­tion propose également une par­ti­cu­la­rité : la classe as­so­cia­tion. C’est à la fois une question de classe et de relation. Ceci vous permet d’affecter des attributs à la classe d’as­so­cia­tion dans le diagramme de classes.

La sous-classe spécifie la classe générale. Cela signifie également que la sous-classe partage certaines pro­prié­tés avec la su­per­classe en termes de contenu aussi bien que de structure, prin­ci­pa­le­ment les éléments de base. Cette cir­cons­tance s’appelle l’héritage. La classe des dahlias, par exemple, partage l’in­flo­res­cence en forme de capitule avec le composite de la classe su­pé­rieure. Une ca­rac­té­ris­tique spé­ci­fique du genre dahlia est ses huit paires de chro­mo­somes, les autres plantes n’ont gé­né­ra­le­ment que deux paires de chro­mo­somes. Les dif­fé­rentes espèces de dahlias pré­sen­tent donc des ca­rac­té­ris­tiques d’aspect plus diverses.

UML permet im­pli­ci­te­ment l’héritage multiple. Cela vous permet de modéliser plusieurs sous-classes qui ont à la fois des su­per­classes communes et dif­fé­rentes. Par ailleurs, il existe plusieurs niveaux de gé­né­ra­li­sa­tion. Vous pouvez afficher ces relations à l’aide de la notation par flèche ou vous pouvez imbriquer les sous-classes dans leurs su­per­classes. Pour ce faire, vous modélisez toutes les sous-classes associées dans le corps de la su­per­classe.

Le set de gé­né­ra­li­sa­tion vous aide à gérer une synthèse dans le diagramme de classes. L’ensemble est un élément packable. Les paquets en UML sont des con­te­neurs pour des éléments nommés qui ont des si­mi­li­tudes sé­man­tiques et qui peuvent changer ensemble. Un paquet est un espace de noms et non une classe. Toutefois, vous pouvez associer le set de gé­né­ra­li­sa­tion à un clas­si­fi­ca­teur. Celui-ci s’appelle un type de pouvoir.

Vous modélisez le type de pouvoir sous la forme d’une chaîne de ca­rac­tères à l’arête de gé­né­ra­li­sa­tion dans ce for­mu­laire : {[is­Co­ve­ring Property],[is­Dis­joint Property]} [Nom du type d’ali­men­ta­tion]. La propriété is­Co­ve­ring spécifie si l’ensemble est complet. Les valeurs sont complètes ou in­com­plètes. La propriété is­Dis­joint indique si les clas­si­fi­ca­teurs partagent des instances communes. Les valeurs sont soit disjoints (pas de che­vau­che­ment), soit over­lap­ping (che­vau­che­ment existant).

L’abs­trac­tion relie des éléments à dif­fé­rents niveaux. Al­ter­na­ti­ve­ment, il montre des pers­pec­tives dif­fé­rentes. Les éléments nommés dans cette relation de dé­pen­dance re­pré­sen­tent le même concept. Selon le standard UML, l’élément le plus spé­ci­fique est le client, qui dépend du four­nis­seur, l’élément le plus abstrait. Ainsi, l’extrémité de la flèche doit être à la sous-classe et le haut à la su­per­classe. UML permet également la notation inverse. Si vous pensez qu’il est plus logique que l’élément abstrait soit dépendant de sa sous-classe, dessinez la flèche sur l’élément plus spé­ci­fique.

L’abs­trac­tion a deux sous-classes : la réa­li­sa­tion (Rea­li­za­tion) et la ma­ni­fes­ta­tion (Ma­ni­fes­ta­tion).

Nous avons déjà mentionné la réa­li­sa­tion en ce qui concerne les in­ter­faces. L’(In­ter­fa­ce­Rea­li­za­tion) est une spé­ci­fi­ca­tion de la réa­li­sa­tion. Il décrit une relation entre le clas­si­fi­ca­teur et l’interface. Le clas­si­fi­ca­teur utilise l’interface pour offrir un service à son client. L’interface exécute ce service. Pour cela, le clas­si­fi­ca­teur doit remplir le contrat stipulé par l’interface. La notation des in­ter­faces fournies et requises se trouve dans la section « In­ter­faces ».

La subs­ti­tu­tion (Subs­ti­tu­tion) est une autre relation qui spécifie la réa­li­sa­tion. Il existe entre un clas­si­fi­ca­teur de rem­pla­ce­ment et un clas­si­fi­ca­teur de contrat. Le clas­si­fi­ca­teur de rem­pla­ce­ment remplit le contrat de l’autre clas­si­fi­ca­teur. Pendant la durée du contrat, les instances du clas­si­fi­ca­teur de rem­pla­ce­ment peuvent remplacer les instances du clas­si­fi­ca­teur de contrat. Con­trai­re­ment à la spé­cia­li­sa­tion, il n’y a pas de si­mi­li­tude struc­tu­relle entre les éléments de subs­ti­tu­tion. Vous notez la subs­ti­tu­tion comme un bord de dé­pen­dance (flèche poin­til­lée avec une pointe ouverte) dans le diagramme de classes et ajoutez le mot-clé <<subs­ti­tute>> au bord.

La valeur de ca­rac­té­ris­tique décrit une relation entre un artefact et un ou plusieurs éléments de modèle. UML définit les artefacts comme des clas­si­fi­ca­teurs. Ils sym­bo­li­sent des instances concrètes et physiques telles que les dossiers d’archives. L’ex­pres­sion signifie qu’un artefact exécute di­rec­te­ment un élément connecté. In­ver­se­ment, il peut sym­bo­li­ser le fait que des éléments soient impliqués dans la création de l’artefact. La spé­ci­fi­ca­tion est un élément du diagramme de dé­ploie­ment et n’est men­tion­née ici que par souci d’ex­haus­ti­vité. Ils né­ces­si­tent la même notation que les rem­pla­ce­ments. Le mot-clé est <<manifest>>.

L’abs­trac­tion définit aussi certains sté­réo­types. Les sté­réo­types ap­par­tien­nent aux profils UML. Si une mé­ta­classe existante doit être étendue pour un projet, un profil est défini pour celui-ci. La classe sté­réo­type est toujours utilisée avec la méta-classe, car un profil ne modifie que ce qui existe ou ajoute de la ter­mi­no­lo­gie. Depuis UML 2.4.1, UML a écrit des sté­réo­types avec des ma­jus­cules au début. Les sté­réo­types standard pour une abs­trac­tion sont :

• Dériver (<<Derive>>) : un élément dérive d’un autre élément. C’est gé­né­ra­le­ment le même type.
• Affiner (<<Refine>>) : un élément donne des in­for­ma­tions plus dé­tail­lées pour une classe qui existe également dans l’autre élément. Les éléments sont situés à dif­fé­rents niveaux d’abs­trac­tion. Par exemple, un modèle au niveau de la direction affine sa classe « Employés » par rapport à la classe « Employés » au niveau de la con­cep­tion.
• Pister (<<Trace>>) : dif­fé­rents modèles expriment dif­fé­rents aspects d’un système. Vous utilisez le mappage ou le traçage pour suivre les éléments qui re­pré­sen­tent le même concept dans dif­fé­rents modèles. Vous pouvez utiliser la trace pour suivre l’évolution des éléments et des spé­ci­fi­ca­tions.

Le dé­ploie­ment montre la relation entre un artefact et son uti­li­sa­tion prévue. Dans le diagramme UML, le bord de dé­ploie­ment d’un ou plusieurs artefacts pointe vers la cible de dé­ploie­ment. Le mot-clé pour le bord est <<deploy>>. Vous pouvez également appliquer cette dé­pen­dance au niveau des instances. Vous pouvez aussi modéliser l’artefact dans le corps de la cible. Pour ce faire, dessinez l’artefact sous forme de symbole ou dressez la liste des artefacts fournis. Cette dé­pen­dance fait partie de la notation des dia­grammes de dé­ploie­ment.

L’uti­li­sa­tion décrit une relation dans laquelle le client a besoin du four­nis­seur pour accomplir ses tâches ou effectuer des opé­ra­tions. L’uti­li­sa­tion im­plé­mente donc la dé­pen­dance générale comme une instance. Cette dé­pen­dance façonne certaines relations concrètes :

• Utiliser (<<use>>) : un élément utilise un autre élément, mais les par­ti­ci­pants exacts dans la relation et l’avantage exact ne sont pas définis en détail.
• Créer (<<create>>) : un clas­si­fi­ca­teur client ou un de ses éléments struc­tu­rels ou com­por­te­men­taux crée une ou plusieurs instances du clas­si­fi­ca­teur four­nis­seur.
• Appeler (<<call>>) : une opération appelle une autre opération. La cible peut être n’importe quelle opération dans l’en­vi­ron­ne­ment de l’opération source, même les clas­si­fi­ca­teurs parents.
• Envoyer (<<send>>) : une opération est la source, c’est-à-dire le client. Votre cible est un signal. La dé­pen­dance modélise donc que l’opération envoie le signal cible.
• Interface requise (Required Interface -----C) : con­trai­re­ment à l’interface fournie, l’interface requise n’existe pas dans le clas­si­fi­ca­teur. Il détermine les services dont un clas­si­fi­ca­teur a besoin pour exécuter ses fonctions pour son client. La dé­pen­dance existe entre le clas­si­fieur et l’interface. Pour en savoir plus à ce sujet, consultez la section « In­ter­faces ».

La liaison de modèle est la dernière relation di­rec­tion­nelle utilisée dans le diagramme de classes. Lorsque vous créez un diagramme de classes, il peut parfois être utile de créer des modèles pour vos classes. Pour les classes, les modèles sont cons­ti­tués de pa­ra­mètres de modèle. Ces pa­ra­mètres ap­par­tien­nent à la signature du modèle. La signature détermine l’ensemble ordonné de pa­ra­mètres dans le modèle. Les classes de modèle qui ne né­ces­si­tent pas de pro­prié­tés in­di­vi­duelles fonc­tion­nent plus ef­fi­ca­ce­ment lorsque vous utilisez des modèles. Toutefois, si vous voulez qu’une classe ait des pa­ra­mètres fixes, utilisez le lien modèle. La relation existe entre un élément lié et la signature du modèle dans un modèle cible.

L’élément lié est mo­dé­li­sable, c’est-à-dire qu’il peut devenir un modèle ou être lié à d’autres modèles. L’élément est lié parce qu’il a une connexion à un modèle. Ce lien décrit la structure de l’élément en rem­pla­çant les pa­ra­mètres formels du modèle par des pa­ra­mètres de valeur.