Types de relations UML : association, dépendance, généralisation

Étudions-les en détail

Types de relations entre diagrammes de classes UML

Association

C'est un ensemble de liens qui relient les éléments du modèle UML. Il définit également combien d’objets participent à cette relation.

Dépendance

Dans une relation de dépendance, comme son nom l’indique, deux ou plusieurs éléments dépendent les uns des autres. Dans ce type de relation, si nous apportons une modification à un élément particulier, il est alors probablement possible que tous les autres éléments soient également affectés par le changement.

Généralisation

On parle aussi de relation parent-enfant. En généralisation, un élément est une spécialisation d’un autre composant général. Il peut lui être substitué. Il est principalement utilisé pour représenter l’héritage.

Réalisation

Dans une relation de réalisation d'UML, une entité dénote une certaine responsabilité qui n'est pas mise en œuvre par elle-même ni par l'autre entité qui les met en œuvre. Cette relation se retrouve principalement dans le cas de interfaces.

Association

Il s'agit d'une relation structurelle qui représente que les objets peuvent être connectés ou associés à un autre objet à l'intérieur du système. Les contraintes suivantes peuvent être appliquées à la relation d'association.

• {implicite} – Les contraintes implicites précisent que la relation n'est pas manifeste ; il est basé sur un concept.
• {commandé} – Les contraintes ordonnées spécifient que l'ensemble des objets à une extrémité d'une association est d'une manière spécifique.
• {changeable} – La contrainte modifiable spécifie que la connexion entre divers objets du système peut être ajoutée, supprimée et modifiée selon les exigences.
• {addOnly} – Il précise que les nouvelles connexions peuvent être ajoutées à partir d'un objet qui se situe à l'autre extrémité d'une association.
• {congelé} – Il précise que lorsqu'un lien est ajouté entre deux objets, alors il ne peut pas être modifié tant que la contrainte gelée est active sur le lien donné ou une connexion.

Nous pouvons également créer une classe qui possède des propriétés d'association ; on l'appelle classe d'association.

Association réflexive

L'association réflexive est un sous-type de relation d'association en UML. Dans une association réflexive, les instances d'une même classe peuvent être liées les unes aux autres. Une instance d’une classe est également appelée un objet.

L'association réflexive indique qu'un lien ou une connexion peut être présent au sein des objets d'une même classe.

Prenons un exemple de classe fruit. La classe des fruits comprend deux instances, comme la mangue et la pomme. L'association réflexive indique qu'un lien entre la mangue et la pomme peut être présent car ce sont des instances de la même classe, comme le fruit.

Association dirigée

Comme son nom l’indique, l’association dirigée est liée à la direction du flux au sein des classes d’association.

Dans une association dirigée, le flux est dirigé. L'association d'une classe à une autre classe s'effectue dans un seul sens.

Il est indiqué par une ligne continue avec une pointe de flèche.

Exemple :

On peut dire qu'il existe une relation d'association dirigée entre un serveur et un client. Un serveur peut traiter les requêtes d'un client. Ce flux est unidirectionnel, il circule uniquement du serveur vers le client. Par conséquent, une relation d’association dirigée peut être présente au sein des serveurs et des clients d’un système.

Dépendance

En utilisant une relation de dépendance dans UML, on peut comprendre comment diverses choses à l'intérieur d'un système particulier dépendent les unes des autres. La dépendance est utilisée pour décrire la relation entre divers éléments UML qui dépendent les uns des autres.

Stéréotypes

• "lier" – Bind est une contrainte qui spécifie que la source peut initialiser le modèle à un emplacement cible, en utilisant les paramètres ou les valeurs fournis.
• "dériver" – Cela signifie que l'emplacement d'un objet source peut être calculé à partir de l'objet cible.
• «ami» – Il précise que la source a une visibilité unique dans l'objet cible.
• "exemple de" – Il spécifie que l'instance d'un classificateur cible est l'objet source.
• «instancier» – Il spécifie que l'objet source est capable de créer des instances d'un objet cible.
• "affiner" – Il précise que l'objet source possède des valeurs absolues exceptionnellestraction que celle de l'objet cible.
• "utiliser" – Il est utilisé lorsque des packages sont créés en UML. Le stéréotype d'utilisation décrit que les éléments d'un package source peuvent également être présents à l'intérieur du package cible. Il décrit que le package source utilise certains éléments d'un package cible.
• "remplaçant" – précise que le client peut se substituer au fournisseur au moment de l'exécution.
• "accéder" – Il précise que le package source accède aux éléments du package cible qui est également appelée fusion privée.
• "Importer" – Il spécifie que la cible peut importer l'élément d'un package source tel qu'il est défini dans le cible qui est également appelée fusion publique.
• "permis" – précise que l'élément source a accès à l'élément fournisseur quelle que soit la visibilité déclarée du fournisseur.
• "étendre" – Vous aide à spécifier que la cible peut étendre le comportement de l'élément source.
• "inclure" – Vous permet de spécifier l'élément source qui peut être inclus dans le comportement d'un autre élément à un emplacement spécifié. (identique à un appel de fonction en c/c++)
• "devenir" – Il précise que la cible est similaire à la source avec des valeurs et des rôles différents.
• "appel" – Il spécifie que la source peut invoquer une méthode objet cible.
• "copie" – Il précise que l'objet cible est indépendant, copie d'un objet source.
• "paramètre" – le fournisseur est un paramètre des opérations du client.
• "envoyer" – le client est une opération qui envoie au fournisseur une cible non spécifiée.

Stéréotypes au sein de la machine d’État

• "envoyer" – Spécifie que l'opération source envoie l'événement cible.

Généralisation

C'est une relation entre une entité générale et une entité unique présente à l'intérieur du système.

Dans une relation de généralisation, le concept orienté objet appelé héritage peuvent être mises en œuvre. Une relation de généralisation existe entre deux objets, également appelés entités ou choses. Dans une relation de généralisation, une entité est un parent et une autre est un enfant. Ces entités peuvent être représentées par héritage.

En cas d'héritage, un enfant de n'importe quel parent peut accéder, mettre à jour ou hériter de la fonctionnalité spécifiée dans l'objet parent. Un objet enfant peut s'ajouter ses fonctionnalités et hériter de la structure et du comportement d'un objet parent.

Ce type de relation est collectivement appelé relation de généralisation.

Les stéréotypes et leurs contraintes

• "mise en œuvre" – Ce stéréotype est utilisé pour représenter que l'entité enfant est implémentée par l'entité parent en héritant de la structure et du comportement d'un objet parent sans enfreindre les règles. À noter: Ce stéréotype est largement utilisé dans un seul héritage.

La relation de généralisation contient des contraintes telles que complète, incomplète pour vérifier si toutes les entités enfants sont incluses ou non dans la relation.

Réalisation

Dans une relation de réalisation d'UML, une entité dénote une certaine responsabilité qui n'est pas mise en œuvre par elle-même ni par l'autre entité qui les met en œuvre. Cette relation se retrouve principalement dans le cas de interfaces.

La réalisation peut être représentée de deux manières :

• L'utilisation d'un Forme canonique
• Utilisation de l'année forme élidée

Dans le diagramme ci-dessus, les règles métier du compte réalisent l'interface IRuleAgent.

Types de réalisation

1. Forme canonique : Dans une relation de réalisation UML, la forme canonique sert à représenter les interfaces du système. Elle utilise un stéréotype d'interface pour créer une interface, et une relation de réalisation permet de concrétiser cette interface. Dans une forme canonique, la relation de réalisation est représentée par une ligne pointillée avec une flèche ouverte de grande taille. Dans le diagramme ci-dessus, l'interface Iruleagent est réalisée à l'aide d'un objet appelé Account Business Rules.
2. Forme élidée : Réalisation dans le diagramme de classes UML L'interface peut également être représentée sous forme abrégée. Dans ce cas, elle est délimitée par un cercle, également appelé notation en sucette. Lorsqu'elle est implémentée à l'aide d'un élément du système, cette interface crée une structure abrégée. Dans le diagramme ci-dessus, l'interface Iruleagent est représentée sous forme abrégée et implémentée par acctrule.dll.

Composition

Il ne s'agit pas d'une relation UML standard, mais elle est toujours utilisée dans diverses applications.

L'agrégation composite est un sous-type de relation d'agrégation avec les caractéristiques suivantes :

• c'est une association bidirectionnelle entre les objets.
• C'est une relation tout/partie.
• Si un composite est supprimé, toutes les autres pièces qui lui sont associées sont supprimées.

L'agrégation composite est décrite comme une association binaire décorée d'un diamant noir rempli à l'extrémité globale (entière).

Un dossier est une structure contenant n nombre de fichiers. Un dossier est utilisé pour stocker les fichiers qu’il contient. Chaque dossier peut être associé à n'importe quel nombre de fichiers. Dans un système informatique, chaque fichier fait partie d'au moins un dossier à l'intérieur du système d'organisation de fichiers. Le même fichier peut également faire partie d'un autre dossier, mais ce n'est pas obligatoire. Chaque fois qu'un fichier est supprimé du dossier, le dossier reste inchangé tandis que les données liées à ce fichier particulier sont détruites. Si une opération de suppression est exécutée sur le dossier, elle affecte également tous les fichiers présents dans le dossier. Tous les fichiers associés au dossier sont automatiquement détruits une fois le dossier supprimé du système.

Ce type de relation en UML est connu sous le nom de relation d'agrégation composite.

Agrégation

An agrégation L'agrégation est un sous-type de relation d'association en UML. L'agrégation et la composition sont deux types de relations d'association en UML. Une relation d'agrégation peut être décrite simplement comme suit : « un objet d'une classe peut posséder ou accéder aux objets d'une autre classe ».

Dans une relation d'agrégation, l'objet dépendant reste dans la portée d'une relation même lorsque l'objet source est détruit.

Prenons l'exemple d'une voiture et d'une roue. Une voiture a besoin d’une roue pour fonctionner correctement, mais une roue n’a pas toujours besoin d’une voiture. Il peut également être utilisé avec le vélo, le vélo ou tout autre véhicule mais pas avec une voiture en particulier. Ici, l’objet roue a un sens même sans l’objet voiture. Ce type de relation est appelé relation d’agrégation.

FAQ