Archimate : Les relations

Introduction

Pour Archimate®, une relation est une connexion entre un élément source, et un élément cible. Archimate® propose également la notion de jonction (ou connecteur), permettant de relier deux relations.

Une relation répond à quelques contraintes :

• Une relation doit avoir exactement une source, et une cible (relation 1-1),
• Il ne peut exister de relation entre deux relations,
• Si des relations sont reliées entre elles, elles doivent être du même type,
• Une chaîne de relations de même type reliant deux éléments entre eux, est valide, si une relation directe équivalente (du même type) est valide.

Le modèle Archimate® inclut 11 relations, classées en 4 catégories :

• Les relations structurelles (Structural relationships) chargées de modéliser les constructions, ou compositions statiques,
• Les relations de dépendances (Dependency relationships) décrivent comme certains composants en supportent d’autres, ou sont utilisés par d’autres,
• Les relations dynamiques (Dynamic relationships) sont utilisées pour indiquer des liens de cause à effet,
• Les autres relations (Other relationships) sont les relations qui ne tombent dans aucune autre des catégories.

Les relations sont les suivantes :

Avant de commencer, je rappelle dans la figure 1, les différents types d’éléments, classés par « aspect », et par couche.

Les relations structurelles

Les relations structurelles sont au nombre de 4 : Réalisation, Affectation, Agrégation, Composition. Graphiquement, ces relations peuvent toutes être représentées de deux manières différentes, avec une variante, soit 3 représentations graphiques possibles (voir figure 2)

• Soit les éléments cibles, et les éléments sources sont graphiquement séparés,
• Soit les éléments sources sont graphiquement, à l’intérieur des éléments cibles.

Définitions

Je donne les définitions originales en anglais ici, et les explications plus bas en français.

Composition / Composition

Comme son nom l’indique, la relation de composition indique qu’un élément est composé d’un ou plusieurs autres éléments.

La relation de composition

• se fait toujours entre éléments du même type,
• suppose une dépendance entre les éléments : Les enfants ne peuvent pas avoir d’existence indépendamment du parent.

Dans le cas de la figure 4, le node est composé d’un équipement, et d’un logiciel.

Aggregation / Agrégation

La relation d’Agrégation indique qu’un élément est un assemblage ou le regroupement d’autres éléments.

Contrairement à la relation de composition, la relation d’Agrégation n’implique pas la notion de dépendance entre les éléments. Il faut interpréter cette relation comme un regroupement de différents éléments pour former un ensemble cohérent. Comme pour la relation Composition, la relation Agrégation se fait toujours entre éléments du même type.

Assignment / Affectation

La relation d’affectation est utilisée pour montrer une responsabilité. Elle relie les éléments sources qui ont la charge de faire une action sur les éléments cibles. La relation est toujours orientée des éléments structurels actifs vers les éléments comportementaux.

La relation affectation signifie que la source ou une partie de la source est assignée à la totalité de la cible.

• Si deux éléments source sont assignés à un même élément cible, l’un OU l’autre peuvent exécuter l’élément cible complet,
• Si la modélisation demande que les deux éléments sources soient requis pour l’exécution de l’élément cible, alors il faut utiliser un connecteur ET (voir paragraphe sur les connecteurs.

Quelques exemples usuels d’utilisation :

• Un rôle métier avec un processus métier,
• Un composant applicatif avec une fonction applicative (application function),
• Une interface métier, avec un service métier,
• Un acteur métier avec un rôle métier,
• Un artifact avec un noeud veut dire que l’artifact (un fichier par exemple) est stocké sur le noeud.

Realization / Réalisation

La relation Réalisation indique qu’un élément joue un rôle important, dans la création, le support, ou la maintenance d’un élément abstrait. Cette relation est utilisée pour montrer la création, l’implémentation d’un élément par un autre.

La figure 11 est un exemple souvent repris, et illustre les différences entre les relations d’affectation et de réalisation :

Les relations de dépendance

Les relations de dépendance visent à décrire la façon dont

• Certains éléments supportent d’autres éléments,
• Ou comment des éléments sont utilisés par d’autres éléments.

Nous avons quatre relations de dépendance : Fournisseur, Accès, Influence, et Association. Contrairement aux relations structurelles, la représentation graphique des relations de dépendance reste unique, et ne comporte pas de version « imbriquée ».

Définitions

Serving / Fournisseur

La définition est assez intuitive : la relation représente le fait qu’un élément fournit ses fonctionnalités à un autre élément.

La page de spécification de Archimate fournit quelques explications complémentaires : La relation Fournisseur décrit la façon dont des services ou des interfaces, offerts par des éléments de comportement ou des éléments actifs, servent des éléments de leur environnement.

Cette explication est un peu trompeuse : il ne s’agit pas d’une règle générale, mais plus d’un cas typique d’utilisation (voir figure 13). La relation Fournisseur ne s’arrête pas aux interfaces et aux services. Elle peut être utilisée entre quasiment tous les éléments des couches Technology, Application, et Business, à l’exception des éléments passifs.

Access / Accès

Cette relation indique la façon dont un élément de comportement (behavior) ou un composant actif (Active Structure) interagit avec un élément passif.

L’interaction peut être la création, l’accès en lecture et/ou écriture, la modification, ou même la suppression d’une donnée, ou d’un objet (contrat, produit, …). La relation peut également être utilisée pour indiquer une association, entre un élément de comportement, et un objet.

Comme le montre la figure 14, par défaut, la relation est représentée par une ligne en pointillé. Mais l’ajout de flèche(s) permet de préciser le type d’accès.

L’exemple de la figure 15 montre deux processus, l’un créant / écrivant les données, l’autres les récupérant.

Influence / Influence

Comme son nom l’indique, cette relation décrit l’influence que peuvent avoir certains éléments, sur la réalisation, ou l’implémentation d’un élément de motivation. On note deux types d’influence

• Les influences « verticales », qui relient les éléments principaux (core elements), et les éléments de motivation,
• Les influences « horizontales » qui relient les éléments de motivation entre eux.

Une relation d’influence peut être utilisée pour montrer une influence positive, tout autant qu’une influence négative. Archimate® permet d’utiliser un attribut pour montrer cela. Cet attribut peut être un signe ++, +, ou -, – , ou un entier de 0 à 10 pour démontrer le niveau d’influence.

La figure 18 reproduit l’exemple donné dans les pages de la spécification d’Archimate® : la demande d’ajout de personnel influence positivement la charge des employés en la réduisant, mais provoque un surcoût (influence négative).

Association / Association

La relation d’association est une sorte de relation générique, qui relie deux éléments, sans donner à ce lien de signification particulière. Cette relation peut être utilisée par exemple, pour construire un premier brouillon d’une modélisation. Cette modélisation peut ensuite être améliorée en remplaçant chacune des relations par une relation spécifique.

Les relations dynamiques

Les relations dynamiques impliquent la notion de temps/de temporalité, dans les dépendances entre les éléments, contrairement aux autres relations qui impliquent une liaison permanente.

Définitions

Trigger / déclenchement

La relation de déclenchement est utilisée pour modéliser une relation de cause à effet entre des éléments “comportement” dans un processus.

Dans une relation de déclenchement, l’élément source doit être intégralement ou partiellement complété, avant que l’élément cible ne puisse démarrer. Malgré le nom de “déclenchement”, il faut noter que relier deux éléments avec cette relation, ne signifie pas, pour autant, que la fin de l’élément source déclenche le départ de l’élément cible.

Flows / Flux

Cette relation permet de modéliser des transferts, ou des flux entre deux éléments. Ces flux peuvent des flux de données, de marchandises, d’argent, …

Contrairement à la relation Access, la relation de flux n’implique pas d’attributs du type Lecture seule ou Lecture/Ecriture, elle suggère à la notion de transmission, comme dans l’exemple de la figure 23.

Autres relations : La relation de spécialisation

Cette relation indique que des éléments enfants, sont d’un genre particulier de l’élément parent.

Contrairement à la relation d’Agrégation, la relation de spécialisation n’implique pas de notion d’ensemble / de sous-ensemble. Cette relation implique plutôt la notion de taxonomie. Pour ceux qui développent en mode objet, on peut faire une analogie avec la notion d’héritage.

Les connecteurs

Les jonctions ou connecteurs ne sont pas des relations a proprement parlé, mais elles permettent de relier des relations du même type.

Un connecteur permet d’indiquer explicitement que

• L’intégralité des éléments participent à la relation, dans le cas du ET,
• Au moins un élément participe à la relation, dans le cas du OU.

Règles d’utilisation :

• Un connecteur peut avoir au moins deux entrées, et une seule sortie,
• Les relations jointes doivent être du même type.

Dérivations

Un peu de math de temps en temps ne peut pas faire de mal … nous allons parler, entre autre, de transitivité.

Dans le langage ArchiMate®, nous pouvons dériver des relations indirectes entre les éléments d’un modèle, sur la base des relations modélisées existantes. Par exemple, dans la figure 27, à gauche, nous avons un élément node qui est composé d’un serveur physique (device), et d’un système d’exploitation (system software), le tout permettant d’héberger une application (application component). Nous pouvons dériver des relations Node -> Composition -> System Software, et System software -> Serving -> Application component, une autre relation du type Node -> Serving -> Application component.

Cette relation « dérivée » permet ensuite d’obtenir une vue simplifiée du schéma (Figure 27 à droite).

D’une manière générale, une relation dérivée (ou dérivation), permet de se passer des éléments intermédiaires qui ne sont pas pertinents à montrer dans un certain modèle ou vue de l’architecture.

Les règles régissant les dérivations sont assez nombreuses, et je ne les passerai pas en revue. Je vous invite à consulter l’annexe B de la documentation de Archimate®.

Résumé et bonnes pratiques

Comme vous avez pu le constater, le choix d’une relation entre deux éléments n’est pas toujours trivial, la différence entre les relations est parfois subtile. Voici quelques conseils pour vous en tirer :

• Les relations structurelles proposent deux représentations graphiques. Utiliser la représentation graphique imbriquée pour l’ensemble des relations peut prêter à confusion : Comment s’avoir laquelle des relations est utilisée ? Pour éviter cette confusion, je n’utilise la version imbriquée que pour une seule des relations (composition),
• Contrairement à la plupart des schémas partagés en exemple dans la littérature, il faut nommer, labeliser, commenter les relations : d’une part cela permet de lever les ambiguïtés, ensuite cela permet une relecture des schémas plus confortable.
• Si vous avez un doute sur la relation à utiliser entre deux éléments, utiliser la relation Association, et donner lui une certaine couleur, pour montrer que vous souhaitez y revenir ultérieurement. Par la suite, vous pourrez redéfinir ces relations une à une, en utilisant le nom, le label ou les commentaires que vous leur avez associé.
• Gardez la définition des relations sous la main. En cas de doute, vous pouvez rapidement y jeter un oeil.

Pour finir, voici un tableau récapitulatif des relations :

Type	Relation	Symbole	Définition	Contrainte
Structure	Composition		Represents that an element consists of one or more other concepts	Same type
Structure	Aggregation		Represents that an element combines one or more other	Same type
Structure	Assignment		Represents the allocation of responsibility, performance of behavior, storage, or execution	Active to Behavior
Structure	Realization		Represents that an entity plays a critical role in the creation, achievement, sustenance, or operation of a more abstract entity
Dependancy	Serving		Represents that an element provides its functionality to another element	No passive element
Dependancy	Access		Represents the ability of behavior and active structure elements to observe or act upon passive structure elements	Active or Behavior to passive
Dependancy	Influence		Represents that an element affects the implementation or achievement of some motivation element	Element to Motivation
Dependancy	Association		Represents an unspecified relationship, or one that is not represented by another Archimate® relationship	Any to Any
Dynamic	Triggering		Represents a temporal or causal relationship between elements	Behavior to Behavior
Dynamic	Flow		Represents transfer from one element to another	Active/Behavior to Active/Behavior
Other	Specialization		Represents that an element is a particular kind of another element	Same type

Ainsi qu’un tableau exhaustif donnant l’ensemble des éléments avec les relations possibles entre eux.

Conclusion

Les relations dans Archimate® sont un peu délicates à définir, du fait de la proximité sémantique de certaines d’entre elles. Il faut donc être vigilant en les utilisant. Leurs représentations graphiques sont très proches, ce qui ne facilite, ni la compréhension, ni la relecture.

Heureusement, la souplesse de ce langage nous permet de réaliser des modélisations par étapes successives. Démarrer une modélisation uniquement avec la relation Association permet d’obtenir des premiers résultats, sans avoir une compréhension détaillée des relations. Ces premiers résultats peuvent être ensuite améliorés, en remplaçant ces relations par les relations adéquates, en commençant par les plus simples ou les plus évidentes, et en finissant par les plus complexes. Une autre recommandation est de bien annoter ces relations pour ne pas en perdre la signification, et pour détecter plus facilement les éventuelles erreurs lors de la relecture.

Cette approche itérative peut être complétée par l’utilisation de patterns prédéfinies, qui permettent de d’accélérer l’apprentissage.