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 programmationorienté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 :
Les diagrammes de classes UML sont constitués de classes et de leurs instances (objets) ainsi que d’interfaces. Ils établissent des relations hiérarchiques et des associations entre ces éléments. La notation de ce type de diagramme est l’élément de base de la plupart des autres diagrammes de structure. UML 2 définit les diagrammes de structure comme des classificateurs. Dans la métamodélisation UML, les diagrammes de package, les diagrammes de composants et autres sont des sous-classes du diagramme de structure. Cependant, ceci n’est pas modélisé, puisqu’il s’agit d’une classe abstraite. Le diagramme de classes est mieux utilisé comme exemple de diagramme de structure. D’autres diagrammes de cette catégorie utilisent des composants modifiés du diagramme de classes pour leur notation.
En tant que classificateur, UML comprend une métaclasse abstraite. Il est utilisé pour affecter des éléments de modèle dans le langage de modélisation à un concept commun. C’est ce que l’on appelle la généralisation. La norme peut donc être formulée en termes généraux. Si la spécification traite d’un certain élément, seule cette particularité doit être expliquée.
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.
L’instance est l’expression concrète d’un élément abstrait. Elle exécute un comportement prescrit dans les paramètres. Certaines instances sont explicitement nommées par UML. L’objet en fait partie. Les propriétés des instances sont modélisées avec des diagrammes au niveau des instances. Au lieu de dessiner un diagramme de classes, vous pouvez dessiner un diagramme d’objets, par exemple.
Les classificateurs encapsulés étendent les classificateurs dits structurés. Ces derniers se caractérisent par le fait qu’ils peuvent prescrire une structure à l’intérieur et reprendre des éléments connectés. Ces éléments (métaclasse : ConnectableElements) influencent le comportement des classificateurs. Chaque élément associé représente un participant dans le comportement du classificateur. Ils disent aussi qu’ils jouent un rôle. Le classificateur encapsulé dispose d’un port d’amarrage supplémentaire. Cela permet d’isoler le classificateur du système sans perdre la connexion.
Les classificateurs comportementaux ont souvent une connexion à une interface, l’InterfaceRealization. Le classificateur accepte implicitement les conditions de l’interface en prenant en charge la fonctionnalité de l’interface. Vous dessinez l’InterfaceRealization (aussi appelé « Lollipop ») comme un cercle non rempli qui est relié à la classe par une ligne.
Ces métaclasses classifient les objets. La classe est l’expression spécifique de ces métaclasses. De cette façon, elle définit plus précisément la classification et concrétise les composants individuels qui composent la structure et le comportement des objets. Les classes ont des propriétés qui les décrivent (et leurs objets subordonnés). Cela comporte :
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 :
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 :
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 :
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 :
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.
| Type de quantité | Unique | Commandé |
|---|---|---|
| Séquence | Non | Oui |
| Multi-quantité (Sac) | Non | Non |
| Quantité commandée | Oui | Oui |
| Quantité | Oui | Non |
La contrainte doit également être mentionnée ici. Dans les versions antérieures d’UML, cet élément était l’une des relations. Pendant ce temps, UML définit la restriction comme un élément packable. Cela signifie qu’elle peut appartenir directement à un paquet. Elle établit également de telles relations avec d’autres éléments, tels que les classes ou les caractéristiques. Toutefois, cela n’influence pas la notation. La restriction constitue une condition ou une garantie de son propriétaire. Elle peut affecter un ou plusieurs éléments.
L’élément propriétaire doit avoir accès à la restriction. Il vérifie ainsi si la restriction est valable et si elle a été respectée. Cela dépend du propriétaire quand cela se produit. Certains éléments, comme l’opération, vérifient les contraintes avant, pendant et/ou après l’exécution. Il existe des conditions préalables, des conditions corporelles et des conditions postérieures. La spécification du moment où un élément vérifie sa contrainte s’appelle un contexte en UML. Une distinction est faite entre le contexte et la spécification réelle. Ce dernier décrit l’élément qui délimite la contrainte, l’aspect qu’il évalue et le résultat qu’il attend. La spécification exacte est donnée à une contrainte par une spécification de valeur booléenne.
La notation se compose d’une chaîne de texte sous la forme suivante :
<Nom de l’élément restreint> ::= { <Nom de la contrainte> : <expression booléenne> }
UML ne prescrit pas de langage. Vous pouvez choisir dans quelle langue vous souhaitez définir la restriction lorsque vous créez votre diagramme de classes. Utilisez un langage de programmation comme Java, un langage naturel ou un langage lisible par machine comme XML. Le Groupe de gestion des objets, qui définit le standard UML, publie l’Object Constraint Language (OCL). Ce langage définit les contraintes compatibles UML. Son avantage est qu’il s’intègre parfaitement dans la notation.
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.
Depuis UML 2.4 la spécification est définie : l’étiquette d’un stéréotype est écrite avec une lettre majuscule au début, environ <<Type>>. Les autres étiquettes, par exemple pour les propriétés à la fin des associations, sont écrites en minuscules.
Il existe deux types de relations entre la (méta)classe et les stéréotypes. L’extension requise (notation : isRequired = true) définit qu’un stéréotype se connecte à chaque instance de la métaclasse dans le diagramme de classes. L’extension inutile (notation : isRequired = false) permet d’associer librement des instances de la métaclasse à un stéréotype. Vous pouvez également supprimer le stéréotype. Toutefois, une instance particulière ne peut être liée à un stéréotype particulier qu’une seule fois pendant l’exécution.
Si vous voulez supprimer un stéréotype, supprimez le profil qui le définit dans la zone (appliedprofiles) du package parent. Vous pouvez également supprimer l’instance qu’il étend.
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 :
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 :
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 logique métier, aussi appelée logique applicative, décrit la logique d’un système qui traite de l’exécution d’exigences métier réelles. Elle diffère de la logique dictée par l’exécution technique. Dans la programmation orientée objet, la logique métier a produit le concept de l’objet métier. Cela permet de modéliser des processus concrets et des valeurs réelles dans un système d’information.
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.
UML spécifie des stéréotypes par défaut supplémentaires pour d’autres types de graphiques. Leurs domaines d’application et leur notation se trouvent dans la spécification UML 2.5.1, Chapitre 22 : profils standard, Tableau 22.1, Page 680.
Les interfaces sont des classificateurs. Dans leur notation, elles ressemblent aux classes. Contrairement à la classe, il s’agit toutefois de déclarations, c’est-à-dire qu’elles déclarent un certain nombre de fonctions et d’obligations publiques logiquement liées. C’est pour ça qu’elles utilisent un contrat. Si une instance exécute l’interface, elle doit remplir ce contrat. On dit que l’instance offre un service selon le contrat. L’interface elle-même ne forme pas d’instances comme une déclaration.
C’est là que la classe entre en jeu, parce qu’elle instancie. Votre instance utilise des spécifications d’interface. Pour cela, elle doit remplir le contrat de l’interface. En retour, elle utilise l’interface comme toile de fond publique. De plus, un classificateur peut utiliser plusieurs interfaces. Inversement, une interface dessert également plusieurs classificateurs. Dans le diagramme de classes UML, les notations d’interface et de classes sont similaires : un rectangle, éventuellement avec trois zones séparées par des lignes.
Pour montrer qu’une classe utilise une interface, utilisez la notation InterfaceRealization (connue des classificateurs comportementaux). Ceci représente une interface fournie, c’est-à-dire une interface qui exécute directement une instance (Provided Interface). Cette dernière s’applique également aux classes supérieures telles que la composante. Si la classe a un port public, elle fournit l’interface. Vous représentez l’InterfaceRealization avec un cercle qui est relié au classificateur par une ligne.
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.
Les types de données unissent un ensemble d’objets avec leurs opérations. Ils utilisent des fourchettes de valeurs concrètes et les combinent avec leurs opérations spéciales. Les objets peuvent avoir plusieurs types. Leurs valeurs numériques vont des types primitifs aux énumérations plus longues.
Les types de données sont des classificateurs. Vos instances ne vous identifient que par leur valeur. Vous utilisez les types de données pour visualiser les types de valeurs, les types primitifs et les types structurés dans le diagramme de classes UML. Si vous copiez une instance de type de données ou modélisez deux instances du même type de données avec la même valeur, elles sont considérées comme étant les mêmes instances.
Si le type de données possède des attributs, UML le classe comme un type de données structuré. Ses instances ne sont égales que si leur structure et les valeurs de leurs attributs sont identiques.
Les types primitifs n’ont pas de structure subordonnée, mais représentent des valeurs de données atomiques. Ils sont également utilisés dans le diagramme de classes pour les restrictions. Ces types ont généralement une sémantique complexe en dehors de la spécification UML. Cependant, en UML ils n’ont pas d’identité, c’est pourquoi ils ne peuvent être distingués pour la même valeur. Ce sont quelques types primitifs en UML :
Vous écrivez les types primitifs avec l’étiquette <<primitive>> au-dessus du nom du type de données respectif.
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.
L’association est une relation qui relie les tulipes. En informatique, les tulipes sont des ensembles ordonnés de valeurs. La connexion logique et la séquence jouent un rôle important. Il n’est donc pas erroné d’attribuer à l’association une composante structurelle en plus de sa désignation officielle en tant que relation sémantique. L’association est un lien entre les classificateurs. Les éléments de cette relation ont une proximité logique ou physique. Selon le nombre de membres, l’association est appelée binaire (deux instances), ternaire (trois instances) ou n-aire (à partir de quatre instances).
Les extrémités d’association connectent les associations avec les instances du diagramme de classes UML. La fin de l’association a un nom de fin. Ce nom exprime le rôle de l’instance dans la relation respective. Supposons qu’un élève tourne plusieurs versions d’un court métrage pour un séminaire sur le cinéma. Le rôle de l’étudiant en cinéma dans le film serait alors « créateur ». Le rôle du film serait « travail de séminaire ». Inscrivez le nom sous la ligne de lien, dans chaque cas dans le symbole de l’instance qui le décrit. La fin appartient soit à l’association elle-même, soit au classificateur de la fin. Avec plus de deux buts, le rôle appartient à l’association.
La flèche à côté du nom de l’association dans le diagramme de classes supérieures indique la direction de la relation. Dans le diagramme du bas, le point de l’instance « film » indique que la fin de l’association « travail de séminaire » appartient à l’instance « étudiant en cinéma ». Comme la fin de l’association « créateur » n’a pas un tel marquage, il appartient à l’association elle-même. La multiplicité « 1 » indique qu’il existe exactement un cas d’ « étudiant en cinéma ». L’instance « film » a au moins trois formations.
La navigabilité est une propriété finale. Il indique si une instance à cette extrémité de l’association peut être atteinte à partir de l’autre extrémité de l’association. Si l’instance B peut être atteinte par l’instance A, tracez une flèche ouverte sur le bord de l’association dans la direction de l’instance B directement sur le symbole d’instance B. Si l’instance D n’est pas accessible par l’instance C, tracez un X sur la ligne de l’instance D. Si vous ne voulez pas spécifier la navigabilité, ne dessinez pas de notation séparée.
Il existe deux variantes d’association : le lien et l’agrégation.
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 relation dirigée est une classe abstraite. Elle décrit les relations entre une source et une cible. Les deux extrémités de la relation peuvent avoir des éléments multiples. Comme l’association, la relation dirigée n’a pas non plus de notation fixe. Leurs sous-classes forment des formes spécifiques. Celles-ci sont basées sur une ligne allant de la source à la destination. Les cas suivants caractérisent une relation dirigée :
La généralisation est une relation binaire entre classes. Il est dirigé d’une sous-classe à une superclasse, d’une certaine classe à une classe plus générale. La classe particulière (p. ex. dahlia) a la généralisation. Une flèche avec une pointe de flèche fermée mais non remplie pointe de cette source vers la cible. La cible est la classe générale (par ex. fleur composite).
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).
La standardisation UML 2.5 donne peu d’informations sur l’héritage. Cependant, vous pouvez suivre les versions précédentes. UML 2 explique généralement que les classes spécialisées adoptent les caractéristiques et contraintes de leurs superclasses. UML 1.4 spécialisé qui remplace les attributs déclarés dans une sous-classe d’attributs hérités.
La dépendance (Dependency) est une relation entre « fournisseur » et « client » (supplier-client-relationship). Cette relation dirigée décrit qu’un élément dépend d’un autre élément. Il peut aussi y avoir beaucoup d’éléments. Le client a besoin d’un autre élément pour la spécification plus précise ou pour exécuter sa tâche. Sans le prestataire, le client n’a pas de composante structurelle ou sémantique. Par conséquent, les changements de fournisseur peuvent avoir une incidence sur le client. Selon UML 2.5, la sémantique influence toujours l’élément mentionné, mais pas ses instances. Les dépendances jouent un rôle non seulement dans le diagramme de classes UML, mais aussi dansd’autres diagrammes de structure tels que le diagramme des composants ou le diagramme de déploiement.
La dépendance comporte trois sous-catégories :
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 :
Utiliser ces stéréotypes d’abstraction pour établir la relation entre le client et le prestataire. Ce processus peut être bilatéral ou unilatéral et formel ou informel. Le mandant et le fournisseur sont situés dans des diagrammes différents, par exemple dans un diagramme de classes et dans un diagramme de cas d’utilisation.
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 :
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.
Le diagramme de classes est l’un des diagrammes UML les plus populaires, car il affiche les structures du système en détail et de manière claire. En tant que diagramme de structure, il montre le système dans un état statique. Cela donne au téléspectateur une vue d’ensemble des éléments nécessaires dans un système. En outre, vous pouvez représenter les relations entre les éléments constitutifs de votre architecture système. Des objets réels aux classes abstraites avec des profils en expansion, le diagramme de classes UML vous permet de modéliser indépendamment du langage de programmation. Comment promouvoir la compréhension entre les disciplines lors de la mise en œuvre d’un projet.
Si vous avez besoin d’effectuer une programmation orientée objet, de représenter clairement un système et de le rendre accessible à des spécialistes externes, le langage Universal Modeling Language peut vous sembler idéal. UML est un langage de modélisation, mais a beaucoup d’autres utilisations possibles. Depuis l’introduction d’UML 2.0, les diagrammes UML sont également adaptés à la...
Les diagrammes d’activité UML vous permettent d’afficher sous forme de graphique la séquence chronologique des processus système dans la programmation orientée objet. Les diagrammes d’activité montrent quelles actions ont lieu dans quel ordre pour exécuter une activité. Avec un diagramme terminé, vous pouvez créer des blocs de codes à l’aide du transfert XML. Souhaitez-vous cartographier les...
Comparer les outils UML : vous cherchez le meilleur outil de modélisation UML ? Ou avez-vous besoin d’un simple outil pour dessiner des schémas et les partager rapidement avec votre équipe ? Les programmes UML sont très variés. Que vous souhaitiez utiliser un outil UML gratuitement ou que vous soyez à la recherche d’une solution complète pour entreprise : voici les points importants et la...
Les diagrammes de séquence vous aident à afficher le flux de messages au sein d’un système. Si vous voulez comprendre exactement un cas d’utilisation, il est conseillé d’utiliser un diagramme de séquence UML. Dans la programmation orientée objet, par exemple, les diagrammes de séquence conviennent pour vérifier la logique d’un système. Nous présentons ces types de diagrammes et expliquons comment...
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
Voir les packs
