Accueil > UML / Enterprise Architect > Analyses d’impact avec Enterprise Architect

Analyses d’impact avec Enterprise Architect

Pourquoi faire des analyses d’impact ?

L’un des intérêts de faire des modèles, je dirais même le seul, est de permettre de répondre rapidement à des questions sur le sujet modélisé. En effet à quoi sert-il de maintenir le modèle d’un système complexe si ce n’est pour tenter de mieux le comprendre ?

Par exemple, si une entreprise définit le modèle de son SI c’est généralement dans le but de faire des analyses d’impact, telles que  :

  • Quels sont les systèmes impactés par une évolution du processus de facturation ?
  • Quels sont les impacts du changement de version de windows sur les processus métier ?
  • Quels sont les flux impactés par la modification des produits ?

On peut imaginer nombre d’autres questions auxquelles il serait utile d’avoir rapidement une réponse afin de faire évoluer le système informatique de cette entreprise dans une direction qui réponde à ses objectifs.

Que proposent les outils ?

Le problème est qu’il n’est généralement pas simple de répondre rapidement à ce type de question. Les outils de modélisation proposent en effet des fonctionnalités de requêtage de modèle assez élémentaires, je dirais même simplistes.

Dès lors que vous désirez faire une requête un tant soit peu compliquée vous passez au minimum quelques heures à la coder. En utilisant Enterprise Architect, coder un parcours de graphe d’éléments en précisant les types d’objets, leurs stéréotypes, les types de relations à parcourir, dans quel ordre, etc. nécessite d’écrire une requête SQL qui est bien loin d’être simple.

Il est hors de question de confier son écriture à quelqu’un qui ne maîtrise pas l’outil. Dans ce cas il devient difficile de répondre rapidement à de nouvelles questions, d’où une réelle perte d’intérêt des modèles. Au final seuls les experts de l’outils finissent par réellement utiliser les modèles, ce qui confine leur intérêt à quelques spécialistes de la modélisation. On est bien loin de l’agilité qui préconise le partage de l’information.

Quelle valeur pour les utilisateurs ?

La question à se poser est celle de la valeur ajoutée d’un modèle pour ses utilisateurs finaux. On pourrait rédiger le besoin sous la forme de la user story suivante :

  • En tant qu’utilisateur du modèle je veux pouvoir formuler simplement une nouvelle question et obtenir rapidement une réponse afin de prendre des décisions concernant le système modélisé.

N’importe quel utilisateur doit donc pouvoir formuler facilement des questions et obtenir rapidement des réponses. Il doit savoir s’il a posé la bonne question ou s’il doit en formuler une nouvelle. Faire plus compliqué perd une bonne partie de la valeur ajoutée fournie par le modèle.

Comment faire ?

Pour répondre à ce besoin nous avons créé un add-in pour Enterprise Architect nommé « Requester ». Son principe est simple : une requête se décrit sous la forme d’un diagramme qui utilise les éléments du modèle.

En voici un exemple. request1

C’est la définition de la requête qui permet de connaître l’ensemble des cas d’utilisation qui réalisent un processus métier de niveau 1.  Pour la créer il suffit de créer un diagramme de requête, d’y placer les objets et liens désirés dans l’ordre, d’indiquer le début et la fin. C’est tout !

requester2Une fois cette requête définie elle apparaît dans la fenêtre d’utilisation du Requester que l’on peut voir ci contre. On la sélectionne  à l’aide de la liste déroulante. Elle possède un titre « BPL1 –> UC » ainsi qu’une description. On peut visualiser la requête elle-même en cliquant sur le bouton « Edit Request » et éventuellement la modifier.

Il ne reste plus alors qu’à sélectionner un élement de type Business Process Level 1 depuis un diagramme ou depuis le browser et à lancer la recherche en cliquant sur le bouton Search.

Une fois la requête lancée sur un modèle de démonstration, le résultat s’affiche sous forme d’un diagramme.requester3

Vous pouvez-remarquer que le résultat de la requête est constituée de chemins complets qui aboutissent à des cas d’utilisation et d’autres qui sont incomplets. C’est parce que la case à cocher « Show partial results » est sélectionnée. Si on la décoche on n’obtient que des chemins complets.

Bien évidemment cela ne fonctionne que dans la mesure où les liens ont été convenablement définis entre les éléments de modélisation dans le modèle. Nous verrons dans un prochain article comment le Requester permet d’assurer cette validité syntaxique.

Il est important de noter que la déclaration d’une requête est indépendante de tout métamodèle ! On peut utiliser des éléments TOGAF, Archimate, VEAF (le framework d’architecture d’entrerprise de Viseo utilisé dans les exemples), votre propre métamodèle, etc.

N’y a-t-il pas un risque de remonter presque tout le modèle dans le résultat ?

Effectivement si l’on créée une requête très longue on risque d’obtenir un résultat décevant car pas suffisamment discriminant.  C’est la raison pour laquelle nous avons ajouté une possibilité de filtrage. A l’heure actuelle il existe seulement la possibilité de « filtrage par parent ». En voici une illustration :

 requester4Par rapport à la version précédente on a ajouté une relation de dépendance stéréotypée « Filter by parent » entre un cas d’utilisation et une application. Lors de l’éxécution de la requête l’outil nécessite que l’utilisateur sélectionne au moins une application dans le modèle et restreint la recherche des cas d’utilisation à celle(s)-ci.

requester5

Si l’on sélectionne l’application Application2 de notre modèle de démonstration voici le résultat que l’on obtient :

requester6

Cette possibilité de filtrage peut se faire sur plusieurs éléments de la requête. On aurait ainsi pu ajouter une filtrage par parent sur les Business Functions. Remarquez que cette requête ne comporte que des chemins complets car on a décoché la case « Show partial results ».

Quel futur pour cet outil ?

Le Requester n’est à l’heure actuelle qu’une version bêta qui demande à être complétée notamment en permettant de définir des critères de recherche plus évolués. Cependant avant de continuer son développement nous pensons qu’il est utile de recueillir le feedback d’utilisateurs d’Enterprise Architect. C’est pourquoi nous le mettons à disposition de ceux qui nous en font la demande à l’adresse suivante support.ea@viseo.com. N’hésitez donc pas à nous contacter si cela vous intéresse.

Categories: UML / Enterprise Architect Tags:
  1. Pas encore de commentaire
  1. Pas encore de trackbacks


− un = 6