urbanisation-si.com

Cet article montre la traduction de la modélisation avec le profil UML vers le langage ArchiMate concernant l’identification des exigences et relations avec les objectifs de la phase A Vision de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Explications du diagramme d’identification des exigences et relations avec les objectifs TOGAF avec le profil UML

 
Le diagramme d’identification des exigences et relations avec les objectifs TOGAF avec le profil UML a été expliqué et détaillé dans l’article :

• Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas

Le diagramme TOGAF d’identification des exigences et relations avec les objectifs avec ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF d’identification des exigences et relations avec les objectifs avec le profil UML

Conclusion

Un nombre important de facteurs externes ou internes peuvent impacter les exigences durant le projet : les lois changent, la concurrence est de plus en plus agressive, les utilisateurs ne savent pas ce qu’ils veulent, des nouvelles technologies apparaissent à des fréquences de plus en plus réduites …

La solution est d’itérer le processus et d’intégrer à chaque nouvelle itération, la gestion des exigences et étudier s’il y des changements.

La modélisation des exigences est destinée à fournir une passerelle entre des outils de gestion d'exigences traditionnels et les autres modèles.
On pourra ainsi réutiliser des exigences dans d'autres produits ou projets.

Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.

On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modifications aux exigence réutilisées.

Bien que visuellement différent, les diagrammes modélisent la même sémantique.

Le même ensemble d’informations est bien représenté dans les 2 outils.

Pour plus de précisions sur les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article :   

• ArchiMate : guide complet des éléments de modélisation - 12

 
Rhona Maxwel
@rhona_helena

“C'est une triste chose de songer que la nature parle et que le genre humain n'écoute pas.”
Victor Hugo

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

Cet article montre la traduction de la modélisation des objectifs stratégiques et opérationnels TOGAF avec le profil UML en langage ArchiMate.

Explications du diagramme d’objectifs TOGAF avec le profil UML

Le diagramme d’objectifs TOGAF avec le profil UML a été expliqué et détaillé dans l’article :

• Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)

Le diagramme TOGAF d’objectifs avec ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF d’objectifs avec le profil UML

Le diagramme TOGAF d’affectation des objectifs avec ArchiMate

Pour rappel et à fin de comparaison, le diagramme TOGAF d’affectation des objectifs avec le profil UML

Remarque : le viewpoint Vision

Les 2 diagrammes ArchiMate précédents ("Goals" et "Assigning Goals") font partie du viewpoint Vision.

Pour plus de précisions sur les viewpoint et d'une manière générale sur les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article :

• ArchiMate : guide complet des éléments de modélisation - 12

Conclusion

Bien que visuellement différent, les diagrammes modélisent la même sémantique.

Le même ensemble d’informations est bien représenté dans les 2 outils.

On pourrait trouver que les diagrammes ArchiMate apparaissent plus simples et plus immédiats que les diagramme du profil UML, mais cela reste très relatif.   

Rhona Maxwel
@rhona_helena

“Toutes les inventions des hommes ne sont que des imitations assez grossières de ce que la nature exécute avec la dernière perfection.”
Buffon

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

• Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate - 1

Une étude de cas complète de modélisation TOGAF avec UML, BPMN et SysML a été entièrement détaillée lors de précédents articles.

Il s'agit du projet "Discount Travel for TOGAF" montrant cette modélisation de l'architecture d'entreprise d'une agence de voyage pour gérer un système de réservation.

Nous allons utiliser cet exemple déjà étudié et traduire chaque diagramme UML en ArchiMate, ce qui vous permettra de vous familiariser avec ce langage.

Installation de l'étude de cas ArchiMate

Pour l’installation de l’outil open source Modelio, voir l’article :

• Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

Description de l'étude de cas

Pour la description de l’étude de cas, voir l’article :

• Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation

Comprendre la modélisation ArchiMate

Pour comprendre la modélisation ArchiMate, voir l’annexe "Les mémentos d'ArchiMate" de l’article avec la liste de tous les sujets traités sur ArchiMate :

• ArchiMate : guide complet des éléments de modélisation - 12

Les parties prenantes

La matrice des parties prenantes est détaillée à l’article :

• Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)

Analyser les objectifs

L’étape "Analyser les objectifs" est détaillée dans l’article :

• Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM

Structure complète et mode opératoire de l'étude de cas ArchiMate

Structure

Voir en annexe à la fin de cet article, l’ensemble des constituants de l’étude de cas organisé suivant les couches classiques :

• Motivation
• Business
• Application
• Technology
• Viewpoint

La structure est identique à celle de la modélisation avec le profil UML.

Mode opératoire

De même pour le mode opératoire pour créer les éléments, voir l’article :

• Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst

Conclusion

L’article :

• Quels sont les meilleurs langages et notations de modélisation pour TOGAF ?

synthétisait les avantages et les inconvénients de 2 outils de modélisation TOGAF :

• les normes UML + BPMN + SysML
• ArchiMate le langage spécialement conçu pour l’architecture d’entreprise et le framework TOGAF.

Les 2 outils de modélisation ont beaucoup de point communs.

En ayant étudié la modélisation TOGAF avec les normes UML + BPMN + SysML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons dans les prochains articles ou l’on verra la traduction de chaque diagramme TOGAF avec UML en langage ArchiMate.  

Rhona Maxwel
@rhona_helena

"La jeunesse est un sport que l'on peut - que dis-je : que l'on doit pratiquer toute sa vie."
Henri Jeanson

Annexe : structure de l'étude de cas "Discount Travel" avec ArchiMate, liste complète des entités

Voici l'iconographie complète du langage ArchiMate décrivant :

• les éléments fondamentaux

• les éléments de motivation, de stratégie, de mise en œuvre et de migration

• les relations

Les éléments fondamentaux

Les éléments de motivation, de stratégie, de mise en œuvre et de migration

Les relations

Conclusion

ArchiMate publié par l’Open Group, est un langage de modélisation entièrement dédié à l’architecture d’entreprise et dont les concepts correspondent exactement à ceux de TOGAF.

Avantages :

• Par exemple ArchiMate propose des point de vue tels qu’ils sont spécifiés dans TOGAF.
• Si vous connaissez TOGAF, vous n’aurez aucun mal à maîtriser ArchiMate.
• Vous n’avez aucun profil à télécharger, d’adaptation à faire.
• Beaucoup d’outils existent, en open source comme Archi de l’éditeur Archimatetool, ou commerciaux comme Enterprise Architect de Sparx Systems, ModelioSoft, Obeo SmartEA, Bizzdesign, Visual Paradigm, …

Inconvénients :

Si l’avantage d’ArchiMate est simple et peut être rapidement utilisé, il a aussi un principal défaut :

• il n’est pas aussi complet que les normes OMG. notamment ArchiMate ne détaille pas les processus et règles métier. 
  La bonne pratique utilisée par les éditeurs est de combiner ArchiMate avec BPMN pour modéliser les processus, sachant que BPMN est prêt à l’emploi et ne nécessite pas l’importation de profil.

Dans la prochaine version 10 de TOGAF, il est à parier qu’ArchiMate sera complètement intégré dans le framework.

Rhona Maxwel

@rhona_helena

"Tolérer, c’est prendre sur soi : la tolérance qui prend sur autrui n’en est plus une. Tolérer la souffrance des autres, tolérer l’injustice dont on n’est pas soi-même victime, tolérer l’horreur qui nous épargne, ce n’est plus de la tolérance : c’est de l’égoïsme."
André Comte-Sponville

Les vues sont un mécanisme pour transmettre de manière ciblée des informations sur les zones d’architecture.

Une vue est définie comme une partie d’une description d’architecture qui répond à un ensemble de problèmes connexes et qui est adaptée à des parties prenantes spécifiques.

Une vue est spécifiée au moyen d'un point de vue, qui prescrit les concepts, modèles, techniques d'analyse et visualisations fournis par la vue.

Une vue est ce que vous voyez et un point de vue est l'endroit d'où vous regardez.

• Une description d'architecture comprend une ou plusieurs vues d'architecture.
• Une vue d’architecture répond à une ou plusieurs des préoccupations d’un intervenant du système.
• Une vue d'architecture exprime l'architecture du système en fonction d'un point de vue de l'architecture.
• Un point de vue comporte deux aspects: les préoccupations des parties prenantes et les conventions qu’il établit.
• Un point de vue traite une ou plusieurs préoccupations.
• Une préoccupation peut être prise en compte par plusieurs points de vue.

Le point de vue établit les conventions pour la construction, l’interprétation et l’analyse de la vue afin de répondre aux préoccupations exprimées par ce point de vue.

Les conventions de point de vue peuvent inclure des langages, des notations, des types de modèles, des règles de conception, des méthodes de modélisation, des techniques d'analyse et d'autres opérations sur les vues.

Comment le mécanisme de point de vue est-il utilisé pour créer des vues répondant aux préoccupations des parties prenantes ?

Un architecte est confronté à de nombreux types de parties prenantes et de préoccupations.

Pour choisir les points de vue appropriés, il existe un mécanisme pour la définition et la classification des points de vue qui repose sur deux critères : la finalité et le contenu.

L'architecte communique avec les parties prenantes pour comprendre et documenter leurs préoccupations.

Le mécanisme de point de vue est utilisé pour identifier le but et le contenu et pour aider à définir et classer le point de vue.

Le point de vue régit la construction et la conception de la vue.

La vue est une description de l'architecture répondant aux préoccupations des parties prenantes et est régie par le point de vue.

La création d'un point de vue ArchiMate comprend deux étapes :

1. Sélectionner un sous-ensemble de concepts (éléments et relations) pertinents du métamodèle ArchiMate, en fonction des informations nécessaires pour répondre aux préoccupations des parties prenantes.
    
2. Définir une représentation pour décrire ces concepts d'une manière comprise par les parties prenantes.
   Cela peut être un diagramme qui utilise une notation ArchiMate standard ou personnalisée, un catalogue d'éléments, une matrice montrant les relations entre deux groupes d'éléments, ou une visualisation entièrement différente.

L'application de ce point de vue à un modèle d'architecture signifie que les parties de l'architecture sélectionnées correspondent à l'ensemble de concepts choisi (étape 1) et sont représentées de la manière prescrite à l'étape 2.

Définition et classification des points de vue

Les points de vue sont classés suivant le type d'objectif et le type de contenu, les plus pertinents pour les préoccupations des parties prenantes.

Type d'objectif :

• Conception : les points de vue de conception prennent en charge les architectes et les concepteurs dans le processus de conception, de l’esquisse initiale à la conception détaillée.
  En règle générale, les points de vue de conception sont constitués de diagrammes, comme ceux utilisés, par exemple, dans UML.
   
• Décision : les points de vue d'aide à la décision concernent les responsables dans le processus de prise de décision en offrant un aperçu des relations d’architecture entre domaines, généralement via des projections et des intersections de modèles sous-jacents, mais aussi par des techniques analytiques.
  Des exemples typiques sont les tableaux de références croisées, les cartographies, les listes et les rapports.
   
• Information : les points de vue d'information aide les parties prenantes à la compréhension de l’architecture d’entreprise, afin d’obtenir leur adhésion et de convaincre les opposants.
  Des exemples typiques sont des illustrations, des animations, des dépliants, etc.

Le type de contenu utilise ArchiMate Core Framework pour sélectionner des aspects et des couches pertinents :

• Détails : les vues au niveau détaillé prennent généralement en compte une couche et un aspect de l’architecture de base d’ArchiMate. Les parties prenantes typiques sont un ingénieur logiciel responsable de la conception et de la mise en œuvre d'un composant logiciel ou d'un responsable de processus qui gère l'exécution efficiente des processus.
   
• Cohérence : au niveau cohérence, plusieurs couches ou plusieurs aspects sont générés.
  L'extension de la vue à plusieurs couches ou aspects permet à l'intervenant de se concentrer sur des relations d'architecture telles que processus-utilisations-système (plusieurs couches) ou applications-objets (aspects multiples).
  Les parties prenantes typiques sont les responsables opérationnels chargés de la collecte de services informatiques ou de processus métier.
   
• Vue d'ensemble : le niveau d'abstraction de la vue d'ensemble concerne à la fois de multiples couches et aspects.
  Ces aperçus sont destinés aux architectes d'entreprise et aux décideurs, tels que les DG et les DSI.

Création de la vue

Avec un point de vue choisi, l’architecte peut créer et concevoir une vue.

La vue contient des éléments et des relations du métamodèle ArchiMate.

L'architecte peut concevoir et créer une représentation appropriée de ces éléments et de ces relations, adaptée aux parties prenantes et aux préoccupations en cours d'élaboration.

Exemple :  Point de vue des parties prenantes

Le point de vue des parties prenantes permet à l'analyste de modéliser les parties prenantes, les facteurs internes et externes de changement et leurs évaluations (en termes de forces, faiblesses, opportunités et menaces ; méthode SWOT).

De plus, les liens avec les objectifs initiaux (de haut niveau) qui répondent à ces préoccupations et à ces évaluations peuvent être décrits. Ces objectifs constituent la base du processus d’ingénierie des exigences, y compris l’affinement des objectifs, l’analyse des contributions et des conflits, et la définition des exigences qui permettent d’atteindre les objectifs.

Les éléments :

• Parties prenantes
• Pilote
• Evaluation
• Objectif
• Résultat

Conclusion

Les points de vue sont un moyen de se concentrer sur des aspects et des couches particuliers de l'architecture.

Ces aspects et couches sont déterminés par les préoccupations d’un acteur avec lequel la communication a lieu.

Ce qui devrait et ne devrait pas être visible d'un point de vue spécifique dépend donc entièrement de l'argumentation concernant les préoccupations d'une partie prenante.

Les points de vue sont conçus pour communiquer certains aspects et certaines couches d'une architecture.

La communication autorisée par un point de vue peut être strictement informative, mais en général, elle est bidirectionnelle.

L'architecte informe les parties prenantes et les parties prenantes donnent leur avis (critique ou assentiment) sur les aspects et les couches présentés.

Ce qui est et ce qui ne figure pas dans une vue dépend de la portée du point de vue et de ce qui est pertinent par rapport aux préoccupations de la partie prenante.

Le point de vue est conçu en tenant compte des préoccupations spécifiques d'une partie prenante.

Par conséquent, le critère de sélection utilisé pour déterminer quels éléments et quelles relations doivent apparaître dans une vue est important pour une partie prenante.

Rhona Maxwel
@rhona_helena

"Le pessimisme est d'humeur, l'optimisme et de volonté."
Alain

Voici un résumé des éléments d'implémentation et de migration, ainsi que leurs définitions.

Conclusion

Ces éléments permettront de réaliser les diagrammes :

• “Application migration”,
• “Data migration”

Les étapes intermédiaires de migration applicative aide à l’estimation en spécifiant les composants gardés à l’identique, les nouveaux composants et les nouvelles interfaces d’accès et montre l’obligation de la continuité de service entre les différentes versions.

Les écarts, entre le système avant et après transformation du modèle source en cible seront représentés.

La traçabilité et la vérification que toutes les données d’origine se retrouvent bien dans le système migré, seront modélisées.

Rhona Maxwel
@rhona_helena

"Le monde ne comprendra jamais que les grands hommes ne sont pas ceux qui gagnent, mais ceux qui n'abandonnent pas quand ils ont perdu."
Cécile Coulon

Ce métamodèle permet de connaître les relations entre les éléments de la couche application et de la couche technologie.

Dans les métamodèles de la norme, les nuances de gris permettent de distinguer les éléments appartenant aux différents aspects du cadre ArchiMate :

• Blanc pour les concepts abstraits (c'est-à-dire non instanciables)
  
  
• Gris clair pour les structures passives
  
  
• Gris moyen pour le comportement
  
  
• Gris foncé pour les structures actives

Il existe deux types de relations entre ces couches : les relations de service et les relations de réalisation.

Relations de service (serves)

Exemple, de la couche technologique vers la couche applicative :

• entre le service technologique (Technology Service = comportement) et les différents types d'éléments d’interactions applicatives (Application Process / Function / Interaction = comportement)
   
• entre l'interface technologique (Technology Interface = structure active) et le composant d'application (Application Component = structure active).

Inversement, de la couche applicative vers la couche technologique  :

• en servant de relations entre le service de l'application (Application Service = comportement) et les éléments d’interactions technologiques (Technology Process / Function / Interaction = comportement),
   
• entre l'interface d’application (Application Interface = structure active) et le nœud de l'application (Node = structure active).

Ces relations représentent les aspects comportementaux et structurels de l'utilisation de l'infrastructure technologique par les applications et vice versa.

Relations de réalisation (realizes)

Exemple :

• du processus technologique ou de la fonction (Technology Process / Function / Interaction = comportement) au processus ou à la fonction d'application (Application Process / Function / Interaction = comportement),
   
• d’un objet technologique (Artifact = structure passive) à l'objet de données (Data Object = structure passive), pour indiquer que l'objet de données est, par exemple, un fichier de données physique
   
• d’un objet technologique (Artifact = structure passive) qui est un exécutable qui réalise un composant d'application (Application Component = structure active). 
  Remarque : dans ce cas, un artefact représente un composant “physique” déployé sur un nœud ; il est modélisé avec une relation d'affectation.
  Un composant d'application (logique) est réalisé par un artefact et, indirectement, par le nœud sur lequel l'artefact est déployé.

Ce métamodèle ne montre pas toutes les relations autorisées: il existe des relations indirectes qui peuvent être dérivées.

En raison des relations dérivées, il est également possible d'établir des relations directement entre les couches métier et technologique.

Par exemple, si un objet métier est réalisé par un objet de données, qui à son tour est réalisé par un objet technologique, cet objet technologique réalise indirectement l'objet métier.

Conclusion

En guise de conclusion, voici un exemple qui montre comment les relations inter-couches intègrent les différentes couches et comment vous pouvez les représenter dans une vue.

Quelques rappels sur les conventions du langage ArchiMate : dans les modèles, il est d’usage d’utiliser les couleurs suivantes pour distinguer les couches :

• Jaune pour la couche métier
  
  
• Bleu pour la couche application
  
  
• Vert pour la couche technologique

En plus des couleurs, une lettre «M» (Motivation), «S» (Strategy), «B» (Business), «A» (Application), «T» (Technology), «P» (Physic) ou «I» (Implementation et Migration) dans le coin supérieur gauche d’un élément peut être utilisée.

La notation standard utilise également une convention avec la forme des coins de ses symboles pour différents types d'éléments :

• Les coins carrés sont utilisés pour désigner les éléments de structure.
  
  
• Les coins arrondis sont utilisés pour désigner les éléments de comportement.
  
  
• Les angles diagonaux sont utilisés pour désigner les éléments de motivation.

Rhona Maxwel
@rhona_helena

"Ce n’est pas le sommeil de la raison qui engendre les monstres, mais la rationalité vigilante et insomniaque."

Gilles Deleuze

Ce métamodèle montre les relations entre la couche métier, la couche application et les éléments de la couche technologique.

Dans les métamodèles de la norme, les nuances de gris permettent de distinguer les éléments appartenant aux différents aspects du cadre ArchiMate :

• Blanc pour les concepts abstraits (c'est-à-dire non instanciables)
  
  
• Gris clair pour les structures passives
  
  
• Gris moyen pour le comportement
  
  
• Gris foncé pour les structures actives

Il existe deux principaux types de relations entre ces couches : les relations de service et les relations de réalisation.

Relations de service (serves)

Par exemple :

• entre le service d'application (Application Service = comportement) et les différents types d'éléments de comportement de l'entreprise (Business Internal Behavior Element = comportement abstrait)
   
• entre l'interface de l'application (Application Interface = structure active) et le rôle de l'entreprise (Business Internal Active Structure Element = structure active abstraite).

Inversement, en servant de relations :

• entre les éléments de service métier (Business Service = comportement) et de comportement applicatif (Application / Process / Function / Interaction = comportement)
   
• entre l'interface métier (Business Interface = structure active) et le composant applicatif (Application Component  = structure active).

Ces relations représentent les aspects comportementaux et structurels du support de l'entreprise par les applications.

Relations de réalisation (realizes)

Par exemple :

• d'un processus d'application ou d'une fonction (Application/Process/Function/Interaction = comportement)  à un processus ou une fonction métier (Business Internal Behavior Element = comportement abstrait)
    
• d'un objet de données (Data Object = structure passive) ou d'un objet technologique (Technology Object = structure passive abstraite) à un objet métier (Business Object = structure passive), pour indiquer que l'objet de données est une représentation numérique de l'objet métier correspondant ou que l'objet technologique est une représentation physique de l'objet métier.

En outre, il peut exister une relation d'agrégation entre un produit et une application ou un service technologique, et un objet de données ou technologique, pour indiquer que ces services ou objets peuvent être proposés directement à un client dans le cadre du produit.

Remarque : ce métamodèle ne montre pas toutes les relations autorisées: il existe des relations indirectes qui peuvent être dérivées.

Conclusion

L’objectif de ces relations est d’assurer la traçabilité entre le métier et les composants applicatifs et techniques afin de vérifier l’alignement du système d’information sur le métier, de fournir des estimations pour les projets futurs et de pouvoir mesurer les impacts en cas d’évolutions et de changements.

Rhona Maxwel
@rhona_helena

"Rien ne va de soi. Rien n'est donné. Tout est construit."
Gaston Bachelard

Cet abrégé donne un aperçu des éléments de modélisation de la couche physique avec leurs définitions.

Résumé des éléments de modélisation de la couche physique

Conclusion

Ces éléments du langage ArchiMate modélisent le déploiement des composants d’application, tous types confondus, dans une architecture technique distribuée.

Ces éléments sont utilisés par les architectes technique avec comme référents les ingénieurs systèmes/réseau pour constitué des modèles à destination des responsables d’exploitation et des développeurs.

Rhona Maxwel
@rhona_helena

"L'homme n'est heureux que de vouloir et d'inventer."
Alain 

Cet aide mémoire donne un aperçu des éléments de la couche technologique, avec leurs définitions.

Résumé des éléments de modélisation d'ArchiMate pour la couche technologique

Conclusion

La couche de technologie est utilisée pour modéliser l'architecture technologique de l'entreprise, définie par le cadre TOGAF comme : la structure et l'interaction des services de plate - forme et les composants technologiques logiques et physiques.

Rhona Maxwel
@rhona_helena

"On ne possède pas le bonheur comme une acquisition définitive. Il s'agit à chaque instant de faire jaillir une étincelle de joie. Ne l'oublions pas : souris au monde et le monde te sourira."
Sœur Emmanuelle