Création de diagrammes de classes avec UML

Les diagrammes de classes sont des diagrammes de structure au sein du Unified Modeling Language, abrégé UML. Le langage de modélisation UML est une norme ISO. Il illustre les systèmes de programmation orientés objet. Les processus d’affaires peuvent également être clairement enregistrés. En utilisant des moyens visuels, UML montre les états des systèmes et décrit les interactions entre les éléments du système. La notation définit les formes et les lignes pour 14 types de diagrammes.

La métamodélisation décrit à la fois les éléments individuels du langage de modélisation et le langage lui-même. Il définit des unités linguistiques pour différents niveaux. Une unité de parole dans ce langage visuel est, par exemple, le comportement. Il décrit à la fois une métaclasse et un terme générique pour tous les facteurs dynamiques d’un système. Une autre unité de langage est l’objet, l’élément de base de la programmation orientée objet. Les diagrammes de classes UML modélisent les objets comme des instances de classes. Le diagramme de classes est donc l’un des types de diagrammes les plus importants et les plus fréquemment utilisés en UML.

Les types de diagrammes sont divisés en deux grandes catégories selon leur fonction : les diagrammes de structure et les diagrammes de comportement. Ces derniers ont une sous-catégorie : les diagrammes d’interaction. Ceux-ci ne modélisent pas seulement le comportement général d’un système, mais se concentrent également sur les flux d’informations entre les objets au cours d’un processus. Ceci inclut, par exemple, les diagrammes de séquence. Vous modélisez l’ordre chronologique des messages qui circulent dans un cas d’utilisation détaillé. Les diagrammes de comportement visualisent les processus dynamiques. Un exemple en est le diagramme d’activité. Ceci montre comment les actions individuelles interagissent dans un processus. Les diagrammes structurels, par contre, montrent les états statiques : ils illustrent les éléments d’un système et leurs interdépendances.

Le diagramme de classes affecte des instances d’objets à des classes spécifiques en fonction de leurs propriétés, il existe donc une dépendance hiérarchique. En même temps, il existe des relations entre différentes classes ou entre objets.

Les diagrammes de classes représentent des états avec des éléments de système. Ils montrent les structures jusqu’à la plus petite instance. Par conséquent, ils sont adaptés à la présentation d’architectures logicielles détaillées. Des étapes concrètes de programmation peuvent en être déduites. Certains environnements de programmation supportés par logiciel convertissent ces diagrammes UML directement en trames de code. Le partage d’équipe permet aux développeurs de communiquer entre eux ou avec d’autres décideurs au sein d’une entreprise. Un diagramme UML fournit une vue d’ensemble des structures 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éveloppeurs mettent ensuite en œuvre. Les professionnels de l’informatique peuvent modéliser et modifier efficacement les diagrammes entre eux sans avoir à programmer des environnements ou des processus plus vastes pendant la phase de planification.

Ce sont les domaines d’application des diagrammes de classes :

• Ils décrivent les types au sein d’un système. La représentation graphique peut être transférée dans différents langages et environnements de programmation. Il existe donc indépendamment de l’application future.
• Vous modélisez les architectures logicielles existantes. Si des composants supplémentaires doivent être intégrés, ils visualisent les structures appropriées sur lesquelles de nouveaux composants peuvent être installés. Pour les futurs éléments du système, les diagrammes de classes créent une ligne directrice pour le code du programme. Selon les besoins, cette étape peut être sommaire ou très détaillée.
• Ils représentent des modèles de données. Ils sont adaptés à des systèmes de complexité variable.
• Avec des applications imbriquées, la documentation et la maintenance peuvent devenir très complexes. Les diagrammes de classes fournissent une vue d’ensemble du schéma.
• Ils représentent les exigences logicielles. En tant que fichiers image, ils peuvent être facilement transférés via les canaux internes de l’entreprise. Ils permettent ainsi à des experts de différents départements d’échanger des informations sur l’architecture.
• Le standard UML utilise des diagrammes de classes pour visualiser sa propre notation.

La classe est un élément de modèle dans le diagramme de classes et une spécialisation de l’EncapsulatedClassifier et du BehavioredClassifier. Elle résume beaucoup d’exemples. Les instances d’objets d’une classe caractérisent les mêmes caractéristiques (attributs) et comportements (méthodes). De plus, elles ont la même sémantique, c’est-à-dire qu’elles utilisent les mêmes signes avec la même signification. La classe est donc une sorte de modèle pour ses objets. Elle instancie les objets et définit leur comportement dans le système.

Vous ajoutez ces propriétés à la notation lorsque vous créez un diagramme de classes. En UML, une classe est représentée par un rectangle avec une ligne continue. Son corps se compose de trois compartiments disposés les uns au-dessus des autres. Seule la partie supérieure doit être modélisée, car vous spécifiez ici le nom de la classe. Les deux autres partitions peuvent optionnellement être étiquetées avec des attributs (centre) et des opérations (bas). Vous attribuez une visibilité différente à ces éléments en écrivant les symboles suivants devant leur nom :

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

Les propriétés sont des éléments connectés. Les attributs de classe (ownedAttributes) sont toujours des rôles. Ils sont reliés entre eux par des connecteurs. S’ils ont la propriété isComposite= true (« est composé = true »), ils sont appelés parties.

La propriété UML est une caractéristique structurelle qui a plusieurs domaines d’application. En plus de la fonction en tant qu’attribut dans une classe, elle peut également représenter des fins d’association.

Le type de propriété est dérivé du nom du classificateur. Si vous le souhaitez, vous pouvez définir une valeur par défaut pour une caractéristique. De plus, les modificateurs déterminent plus en détail le comportement d’une caractéristique :

• ordonné (notation : isOrdered = true)
• unique (notation : isUnique = true)
• non unique (notation : isUnique = false)
• lecture seule (la caractéristique ne peut être lue, notation : isReadOnly = true)
• Séquence (la caractéristique est une collection ordonnée, notation : isUnique = faux et isOrdered = vrai)
• Association (association dérivée de sous-ensembles, notation : union)
• ID (appartient à la désignation de son classificateur, notation : id)
• Délimitation du caractère (une délimitation qui influence le caractère, notation : propriété-contrainte)
• Redéfinition d’une caractéristique (redéfinit une caractéristique héritée, nommée, notation : redéfinit [nom de la caractéristique])
• Sous-ensemble de la caractéristique (symbolise une caractéristique qui est un sous-ensemble d’une caractéristique nommée, notation : sous-ensembles [nom de la caractéristique])

Les opérations sont des fonctions comportementales. Ils se produisent dans les classes, mais aussi dans les types de données ou les interfaces. Vous appelez directement l’instance d’une classe. L’opération détermine les aspects suivants d’un appel :

• Nom
• Type
• Paramètres
• Contraintes

L’opération appartient à son classificateur supérieur. Ceci peut les modifier en redéfinissant le type ou le paramètre.

Il y a des conditions préalables à l’opération. Ces conditions doivent être remplies avant l’exécution de l’opération. Toutefois, UML ne définit pas le comportement d’un appel de comportement si les conditions préalables ne sont pas remplies. Vous définissez également les conditions ultérieures qui doivent être remplies lorsque l’opération est terminée. Les conditions corporelles limitent le résultat de sortie à une valeur calculée à partir de leurs spécifications. Cette valeur doit répondre aux conditions a posteriori. Toutefois, l’opération peut également provoquer une exception pendant son exécution. Dans ce cas, il ne remplit probablement pas les conditions post conditionnelles.

La notation pour le diagramme de classe prescrit que les opérations dans un compartiment sont notées dans le corps de la classe. Selon le standard UML, ces informations sont obligatoires. En même temps, UML permet de supprimer toutes les spécifications standards d’une classe. Seul le nom doit être noté.

Un récepteur de signal indique qu’un classificateur 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 informations correspondantes dans le corps de la classe, dans un compartiment sous les opérations.

Il s’agit de ports pour les classificateurs encapsulés. Ils représentent un point d’interaction entre le classificateur et son environnement. Outre les ports, le classificateur encapsulé est un système autonome. Étant donné que ses éléments structurels et comportementaux internes ne sont pas affectés par le reste du système, vous pouvez également définir ce classificateur indépendamment. Tant qu’un système respecte les limites du port, vous pouvez réutiliser le classificateur encapsulé dans différents environnements.

En outre, UML autorise plusieurs points d’ancrage par classificateur. Vous pouvez définir des règles distinctes pour chaque port. Le port est une propriété du classificateur, vous définissez donc ses règles dans la zone Propriétés. Cela inclut les services que le classificateur offre à son environnement et les services dont il a besoin. Vous différenciez les différents flux d’information en identifiant le port utilisé pour eux.

Les ports eux-mêmes ont aussi des propriétés. Lorsque le port exécute les fonctions publiées du classificateur, il affiche la propriété isService. Si isService = true, le port est considéré comme un composant indispensable des fonctions du classificateur encapsulé qui sont visibles de l’extérieur. Avec isService = false, le port n’est pas l’une des caractéristiques essentielles et peut donc être modifié ou supprimé tout comme les autres fonctions internes.

Les ports interagissent avec les interfaces. Il existe des interfaces fournies et nécessaires (voir « Interfaces » ci-dessous). L’interface qui est connectée au port spécifie les interactions qui passent par le port. Comme le site d’amarrage est une propriété, il a un type. La valeur d’isConjugated 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 directement du type de port ou de l’ensemble des interfaces que le type de port implémente. Dans ce cas, une interface fournie est dérivée du nombre d’interfaces. Si isConjugated est vrai, l’interface fournie est dérivée du type.

Lorsqu’un classificateur encapsulé génère une instance, des instances correspondantes sont créées pour chacun de ses ports. Un port tient l’instance en fonction de son type et de sa multiplicité (voir ci-dessous). Les instances sont appelées points d’interaction UML. Chaque instance possède des références uniques qui distinguent les différentes demandes de fonctions comportementales adressées à ses ports.

Ports avec la propriété isBehavior = true envoie une requête à l’instance du classificateur encapsulé. La requête adopte le comportement spécifié de l’instance. Les ports de comportement ne dirigent pas les requêtes vers l’intérieur de votre classifieur. Si aucun comportement 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 classifieur auquel il appartient. Dessinez l’interface requise ou fournie sur le port. Si vous ne spécifiez aucune caractéristique spéciale pour le port, dessinez l’interface sans le port.

Les connecteurs définissent les connexions entre deux ou plusieurs instances. Le cahier des charges permet leur communication. Contrairement aux relations telles que les associations, les connecteurs ne connectent que les instances qui sont définies comme pièces de connexion. Modéliser les connecteurs en tant que bords avec au moins deux extrémités. Ils représentent les instances participantes qui attribuent un type aux éléments liables.

Un autre paramètre important est la multiplicité. Ce paramètre spécifie le nombre d’instances qu’une classe structurée peut former. Il limite également les attributs et les opérations. 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érations. Topologie appartient également à cette section. Les nœuds (instances d’objets) se connectent aux réseaux topologiques par des voies de communication (CommunicationPaths).

Notez les multiplicités comme suit :

<multiplicité> : <plage de multiplicité> [<désignation de commande> , <identifiant unique>]

La plage de multiplicité 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 = exactement 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 individuels 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 description type. Dans la notation, vous décrivez les tailles individuelles comme étant commandées/non commandées ou uniques/non uniques.

Vous notez certains éléments restreints dans l’UML comme texte, par exemple, un attribut d’une classe dans le diagramme de classes. Vous notez la restriction derrière l’élément de texte entre crochets courbes. Si le propriétaire est un élément que vous représentez comme un symbole, placez la restriction le plus près possible du symbole ; il devrait être évident que les deux éléments ont une relation sémantique. Vous pouvez rendre la connexion encore plus claire en écrivant la restriction dans une icône de bloc-notes et en la connectant à son propriétaire avec une ligne pointillée.

Si la restriction affecte deux éléments, connectez les propriétaires avec une ligne pointillée. Vous écrivez la restriction entre parenthèses courbes dessus. Si vous placez une pointe de flèche à une extrémité, cela indique la position du propriétaire dans une collection d’éléments contraints. La flèche pointe de la première position vers la seconde. Si plus de deux éléments ont la restriction, utilisez l’icône du bloc-notes et associez chaque élément à la restriction.

Les bords font également partie des éléments restrictifs. Si vous modélisez plus de deux bords du même type, faites glisser la ligne pointillée de contrainte à travers tous les bords qui représentent les éléments impliqués.

Les stéréotypes définissent les extensions des métaclasses. Selon la spécification UML, ils appartiennent aux profils. Si un stéréotype décrit des propriétés supplémentaires de plusieurs métaclasses, il ne peut décrire qu’une seule instance de la métaclasse à la fois pendant l’exécution. Parmi les métaclasses, le stéréotype joue un certain rôle. Parce qu’il ne peut jamais rester seul. Ils modélisent un stéréotype toujours en conjonction avec le classificateur qu’il développe. Vous connectez la métaclasse au stéréotype en modélisant une extension.

UML définit certains stéréotypes de classes qui étendent votre diagramme de classes UML. Six stéréotypes sont standards. Trois stéréotypes, souvent utilisés mais pas normalisés, sont ceux avec lesquels vous mettez en œuvre le modèle « Model-View-Controller » (MVC) en UML. Les trois stéréotypes non standards sont :

• L’entité (notation : <>) : le stéréotype Entité définit une classe ou un objet. Chaque instance représente une collection 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éotype, mais l’affecte par défaut aux diagrammes de composants. La notation fréquemment utilisée n’énumère pas la spécification. Ils modélisent l’entité comme un cercle reposant sur une courte ligne.
• La limite (notation : <>) : la limite est un stéréotype pour une classe ou un objet. Il correspond à peu près à l’élément View du motif MVC. La limite modélise la limite de votre système, par exemple une interface utilisateur. Ils sont généralement représenté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 représente les mêmes éléments que le contrôleur sous MVC. Des classes ou objets avec des éléments de modèle stéréotypés qui correspondent au comportement du système ou qui contrôlent les flux. Dans le standard UML, le stéréotype <> assume des tâches similaires. Dessinez une instance de contrôle sous la forme d’un cercle avec une flèche ouverte sur la ligne.

Ces trois stéréotypes peuvent aussi être dessinés comme une simple classe. Dans le rectangle, notez le nom du stéréotype respectif. Les modélisateurs utilisent principalement ces formes dans les diagrammes de séquence. Si vous voulez en savoir plus sur les diagrammes de contrôle des frontières d’entités, lisez notre article sur le diagramme de séquence avec UML.

Ces stéréotypes standardisés conviennent aux diagrammes de classes :

• Focus (<>)
• Aide (<>)
• Type (<>)
• Classe d’application (<>)
• Méta-classe (<>)
• Utilitaire (<>)

La classe focus définit la logique métier de base ou le flux de contrôle des classes d’aide. Ceux-ci supportent la classe focus, qui connecte un ou plusieurs assistants. Elle définit implicitement les classes de soutien en établissant une relation de dépendance avec elles (voir « La relation dirigée » ci-dessous). Si elle utilise des classes d’aide, elle les définit explicitement. Le standard UML recommande ce stéréotype en particulier pour la phase de conception, lorsque vous représentez les flux de contrôle entre composants ou définissez la logique métier de base.

La classe d’aide agit généralement en combinaison avec la classe de focalisation. Elle prend généralement en charge les classes qui sont d’une importance cruciale pour le système. À cette fin, elle exécute des flux de contrôle secondaires et définit la logique subsidiaire. Si la classe aide supporte une classe focus, la définition est explicite. Vous utilisez une relation de dépendance pour définir implicitement la classe prise en charge.

La classe type définit un domaine pour les objets de gestion. Elle spécifie également les opérateurs de ces objets. Le stéréotype de type peut avoir des attributs et des associations. Toutefois, il ne décrit pas l’exécution physique de l’objet.

Certains langages de programmation (par exemple Java ou C++) n’autorisent qu’une seule classe pour chaque instance. Avec UML, cependant, vous pouvez assigner une instance à plusieurs classes. La classe d’application construit un pont entre ces deux mondes. Ce stéréotype restreint la classe UML. Il détermine qu’une instance sous lui ne peut réaliser qu’une seule classe. La classe d’application peut implémenter plusieurs types différents à cette fin. Pour exécuter avec succès un classificateur qui lui est affecté, elle doit remplir deux conditions : elle doit fournir toutes les opérations du classificateur et elles doivent avoir le comportement défini pour le classificateur. Toutefois, il n’est pas nécessaire que les attributs physiques et les associations correspondent.

Puisque les formes de classe et de métaclasse ne diffèrent pas, l’étiquette Metaclass indique qu’il s’agit du stéréotype Metaclasse. Les instances de cette classe sont elles-mêmes des classes. Avec ce stéréotype, vous travaillez à un niveau plus élevé d’abstraction.

La classe utility n’a pas d’instances. Elle n’identifie qu’une collection d’attributs et d’opérations nommés. Ils sont toujours statiques. Les attributs statiques ne changent pas lorsqu’ils sont appelés. Les opérations statiques sont utilisées pour les entités ou les types d’entités. Si vous utilisez la classe utilitaire, vous devez spécifier les valeurs et les opérations correspondantes dès le départ, car elles ne changent plus. Le soulignement identifie ces éléments.

Il y a aussi des Interfaces Requises (Required Interfaces). Elles visualisent une relation de dépendance (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 classificateur (ou une de ses instances) a besoin d’une interface. L’InterfaceUsage spécifie les exigences d’interface. Une ligne continue relie le classificateur à un demi-cercle ouvert. Ceci symbolise l’interface. Notez le nom de l’interface aux deux représentants sous le (demi)cercle.

Si une classe hérite d’une interface à une classe subordonnée, modélisez l’interface qui la lie à la classe ou instance subordonnée. Afficher la relation hiérarchique avec l’accent circonflexe (^), par exemple, comme ^Interface 1.

Utilisez la notation de l’interface rectangulaire, tracez un bord entre les deux nœuds. Dans le diagramme de classes, les bords modélisent les relations entre classes, instances ou composants. UML prescrit différentes lignes et flèches pour différentes fonctions et relations. Dans ce cas, connectez une classe avec l’interface requise à l’aide d’une flèche pointillé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 pointillés avec une pointe fermée et non remplie. La flèche pointe toujours dans la direction de l’interface.

L’énumération est un type de données. Elles représentent la valeur du dénombrement sous la forme d’un symbole de lettre de dénombrement. Comme vous pouvez le voir dans l’image ci-dessus, c’est simplement un nom qui symbolise une certaine valeur. C’est à vous de choisir. Dans la liste « Rose Type », par exemple, le nom « Tea Roses » représente le nombre de tea roses qu’un fleuriste a dans son assortiment. Dans le diagramme de classes, dessinez ce classificateur avec le symbole de la classe, un rectangle. Le nom et l’étiquette <<enumeration>> sont dans l’en-tête. Ils séparent la zone de la tête du corps par des lignes horizontales en compartiments.

Comme pour les autres classes, l’énumération réserve les sections supérieures pour les attributs et les opérations. Si celles-ci sont restées vides, laissez les deux départements en dehors du diagramme. Dans la partie inférieure, entrez les symboles de votre lettre d’énumération. 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 diagrammes de classes représentent les relations entre les éléments du système. De cette façon, le spectateur peut voir de quels composants le système a besoin et comment ils s’influencent mutuellement. La relation élément UML est une classe abstraite. Elle représente l’idée d’une relation entre les composants du système. Par conséquent, cet élément n’a pas de notation distincte. Cependant, ses caractéristiques ont des détails spécifiques qui les distinguent.

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

La définition UML pour les sous-classes et instances de relations a changé radicalement d’UML 1 à UML 2. À l’origine, par exemple, il y avait des relations sémantiques, structurelles et dirigées. UML a affecté trois relations concrètes (association, restriction et dépendance) aux relations sémantiques. Sous UML 2, les limitations sont maintenant des éléments packables, les associations définissent certaines sources comme des relations structurelles et sémantiques. La dépendance fonctionne maintenant sous des relations dirigées.

Il reste à voir comment la norme changera dans les versions futures. Dans ce qui suit, nous expliquons les diagrammes de classes selon UML 2.5. En conséquence, la relation métaclasse a deux sous-classes : la relation dirigée et l’association.

Le sous-type Composition (Composite Aggregation) décrit la relation entre une composition de parties et une partie unique de celle-ci. Si le système supprime le tout (la composition), il détruit également la pièce individuelle. 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 représentez cette relation, vous tracez une ligne continue entre les instances. Modéliser un losange noir sur le côté de la composition (dans cet exemple : l’instance « arbre »). Cette page est aussi appelée fin d’agrégation.

Le deuxième sous-type d’agrégation est l’agrégation fractionnée (abrégée en agrégation simple). Cette relation asymétrique existe entre une propriété (Property) et une instance qui représente un ensemble d’instances. La connexion doit être faite directement. Sinon, une instance de composition pourrait être interprétée comme faisant partie d’elle-même. Ceci peut se produire si vous modélisez la relation de dépendance de façon cyclique. La propriété partagée peut appartenir à plusieurs compositions. En même temps, leur instance peut exister indépendamment de la composition. Dans ce cas, si le système supprime une composition (ou la totalité), la substance peut toujours exister. Par conséquent, cette relation est considérée comme faible par rapport à la composition.

L’association propose également une particularité : la classe association. C’est à la fois une question de classe et de relation. Ceci vous permet d’affecter des attributs à la classe d’association dans le diagramme de classes.

La sous-classe spécifie la classe générale. Cela signifie également que la sous-classe partage certaines propriétés avec la superclasse en termes de contenu aussi bien que de structure, principalement les éléments de base. Cette circonstance s’appelle l’héritage. La classe des dahlias, par exemple, partage l’inflorescence en forme de capitule avec le composite de la classe supérieure. Une caractéristique spécifique du genre dahlia est ses huit paires de chromosomes, les autres plantes n’ont généralement que deux paires de chromosomes. Les différentes espèces de dahlias présentent donc des caractéristiques d’aspect plus diverses.

UML permet implicitement l’héritage multiple. Cela vous permet de modéliser plusieurs sous-classes qui ont à la fois des superclasses communes et différentes. Par ailleurs, il existe plusieurs niveaux de généralisation. Vous pouvez afficher ces relations à l’aide de la notation par flèche ou vous pouvez imbriquer les sous-classes dans leurs superclasses. Pour ce faire, vous modélisez toutes les sous-classes associées dans le corps de la superclasse.

Le set de généralisation 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 conteneurs pour des éléments nommés qui ont des similitudes sémantiques 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éralisation à un classificateur. Celui-ci s’appelle un type de pouvoir.

Vous modélisez le type de pouvoir sous la forme d’une chaîne de caractères à l’arête de généralisation dans ce formulaire : {[isCovering Property],[isDisjoint Property]} [Nom du type d’alimentation]. La propriété isCovering spécifie si l’ensemble est complet. Les valeurs sont complètes ou incomplètes. La propriété isDisjoint indique si les classificateurs partagent des instances communes. Les valeurs sont soit disjoints (pas de chevauchement), soit overlapping (chevauchement existant).

L’abstraction relie des éléments à différents niveaux. Alternativement, il montre des perspectives différentes. Les éléments nommés dans cette relation de dépendance représentent le même concept. Selon le standard UML, l’élément le plus spécifique est le client, qui dépend du fournisseur, l’élément le plus abstrait. Ainsi, l’extrémité de la flèche doit être à la sous-classe et le haut à la superclasse. 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écifique.

L’abstraction a deux sous-classes : la réalisation (Realization) et la manifestation (Manifestation).

Nous avons déjà mentionné la réalisation en ce qui concerne les interfaces. L’(InterfaceRealization) est une spécification de la réalisation. Il décrit une relation entre le classificateur et l’interface. Le classificateur utilise l’interface pour offrir un service à son client. L’interface exécute ce service. Pour cela, le classificateur doit remplir le contrat stipulé par l’interface. La notation des interfaces fournies et requises se trouve dans la section « Interfaces ».

La substitution (Substitution) est une autre relation qui spécifie la réalisation. Il existe entre un classificateur de remplacement et un classificateur de contrat. Le classificateur de remplacement remplit le contrat de l’autre classificateur. Pendant la durée du contrat, les instances du classificateur de remplacement peuvent remplacer les instances du classificateur de contrat. Contrairement à la spécialisation, il n’y a pas de similitude structurelle entre les éléments de substitution. Vous notez la substitution comme un bord de dépendance (flèche pointillée avec une pointe ouverte) dans le diagramme de classes et ajoutez le mot-clé <<substitute>> au bord.

La valeur de caractéristique décrit une relation entre un artefact et un ou plusieurs éléments de modèle. UML définit les artefacts comme des classificateurs. Ils symbolisent des instances concrètes et physiques telles que les dossiers d’archives. L’expression signifie qu’un artefact exécute directement un élément connecté. Inversement, il peut symboliser le fait que des éléments soient impliqués dans la création de l’artefact. La spécification est un élément du diagramme de déploiement et n’est mentionnée ici que par souci d’exhaustivité. Ils nécessitent la même notation que les remplacements. Le mot-clé est <<manifest>>.

L’abstraction définit aussi certains stéréotypes. Les stéréotypes appartiennent aux profils UML. Si une métaclasse existante doit être étendue pour un projet, un profil est défini pour celui-ci. La classe stéréotype est toujours utilisée avec la méta-classe, car un profil ne modifie que ce qui existe ou ajoute de la terminologie. Depuis UML 2.4.1, UML a écrit des stéréotypes avec des majuscules au début. Les stéréotypes standard pour une abstraction sont :

• Dériver (<<Derive>>) : un élément dérive d’un autre élément. C’est généralement le même type.
• Affiner (<<Refine>>) : un élément donne des informations plus détaillées pour une classe qui existe également dans l’autre élément. Les éléments sont situés à différents niveaux d’abstraction. 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 conception.
• Pister (<<Trace>>) : différents modèles expriment différents aspects d’un système. Vous utilisez le mappage ou le traçage pour suivre les éléments qui représentent le même concept dans différents modèles. Vous pouvez utiliser la trace pour suivre l’évolution des éléments et des spécifications.

Le déploiement montre la relation entre un artefact et son utilisation prévue. Dans le diagramme UML, le bord de déploiement d’un ou plusieurs artefacts pointe vers la cible de déploiement. Le mot-clé pour le bord est <<deploy>>. Vous pouvez également appliquer cette dépendance 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épendance fait partie de la notation des diagrammes de déploiement.

L’utilisation décrit une relation dans laquelle le client a besoin du fournisseur pour accomplir ses tâches ou effectuer des opérations. L’utilisation implémente donc la dépendance générale comme une instance. Cette dépendance façonne certaines relations concrètes :

• Utiliser (<<use>>) : un élément utilise un autre élément, mais les participants exacts dans la relation et l’avantage exact ne sont pas définis en détail.
• Créer (<<create>>) : un classificateur client ou un de ses éléments structurels ou comportementaux crée une ou plusieurs instances du classificateur fournisseur.
• Appeler (<<call>>) : une opération appelle une autre opération. La cible peut être n’importe quelle opération dans l’environnement de l’opération source, même les classificateurs parents.
• Envoyer (<<send>>) : une opération est la source, c’est-à-dire le client. Votre cible est un signal. La dépendance modélise donc que l’opération envoie le signal cible.
• Interface requise (Required Interface -----C) : contrairement à l’interface fournie, l’interface requise n’existe pas dans le classificateur. Il détermine les services dont un classificateur a besoin pour exécuter ses fonctions pour son client. La dépendance existe entre le classifieur et l’interface. Pour en savoir plus à ce sujet, consultez la section « Interfaces ».

La liaison de modèle est la dernière relation directionnelle 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 constitués de paramètres de modèle. Ces paramètres appartiennent à la signature du modèle. La signature détermine l’ensemble ordonné de paramètres dans le modèle. Les classes de modèle qui ne nécessitent pas de propriétés individuelles fonctionnent plus efficacement lorsque vous utilisez des modèles. Toutefois, si vous voulez qu’une classe ait des paramè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 modélisable, 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 remplaçant les paramètres formels du modèle par des paramètres de valeur.