Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2

Obeo a bien compris qu'en matière de développement d’applications, tout ce qui ne produit pas une fonctionnalité utilisable - dont la conduite de projet ou la modélisation - s’avère une activité parasite, aussi utile semble-t-elle être sur le moment.
N’en déplaise aux markéteurs d’Obeo, le Graal n’est peut-être pas complètement atteint, mais on s’y rapproche.

Notre exemple fictif d'une Institution de Prévoyance (ABIP) projetant de refondre son SI.

Recette pour réussir un outil d'architecture applicative

Débarrassez UML et BPMN de tout ce qui n’a jamais été utilisé, ajoutez un soupçon de diagramme d’activité nommé graphe de tâches, incorporez-y un doigt de diagramme de collaboration BPMN rebaptisé plan d’actions, mélangez avec un zeste de cas d’utilisation avec leurs acteurs. Laissez reposer, préparez le diagramme de classes participantes qui seront packagées. Il est possible, selon les goûts, de l'accompagner de User Stories. Pour finir, agrémentez le tout d’exigences, sans oublier de les lier aux tâches de votre graphe.

Il était une fois la refonte d'un SI...

Regroupement fusionnel

Pour donner un peu de consistance et un soupçon de réalisme à notre fil conducteur, nous avons choisi deux Institutions de Prévoyance AIP et BIP, qui viennent de fusionner et deviennent ABIP. L’architecte d’entreprise, en étroite collaboration avec la DG, a défini la vision de transformation qui soutient les objectifs stratégiques de ABIP. Malgré l’omniprésence d’une infrastructure mainframe IBM antédiluvienne, celle-ci sera conservée en partie, comme le font la plupart des grandes entreprises dans les domaines bancaire et assurantiel : les batches COBOL/CICS pour l’édition des relevés ou le calcul des rentes, sont non seulement maintenus, mais évoluent et sont intégrés dans une architecture orientée services (SOA). Comme dans “2001 : l'Odyssée de l'Espace", un monolithe est omniprésent sous la forme de l'application de prestations réalisée en technologies des années 90.

Une roadmap de migration en méthode agile, basée sur une architecture micro-services (PrevIT), a été validée. Toutes les technologies, outils, framework devront être basés sur l’écosystème Java qui s'interface nativement avec l'environnement mainframe IBM (MVS). La plateforme open source Java Eclipse a été choisie comme outil commun à toutes les parties prenantes. Développé sur ce socle, l’outil d’architecture d’entreprise Obeo SmartEA, remplacera MEGA, dont les coûts de licence obèrent le budget de la DSI. Pour les experts métier, les business analysts, les architectes logiciel et les concepteurs/développeurs, l’outil open source Information System designer (ISD) d'Obeo leur permettra de mieux communiquer. Etant donné les contrats existants avec IBM pour la maintenance des applications sur z/OS, il a été décidé la mise en œuvre d'IBM Cloud Pak for Integration et IBM® Robotic Process Automation, intégrant le moteur de règles métier IBM® Operational Decision Manager.

Le choix de l'ADM de TOGAF

Pour parvenir à ces objectifs, c’est-à-dire la transformation de l’architecture d’entreprise pour avoir une vision globale des aspects stratégiques, métier, organisationnels, et pour maîtriser l’alignement entre le métier et la technique, clé d’un Système d’Information agile, ABIP a choisi le cadre TOGAF.

Dans un contexte de fusion et de refonte du SI, où l’on doit concevoir des solutions dans un laps de temps réduit, après la phase A Vision de l'Architecture, la 1ère itération de définition de l’ADM (Architecture Development Method) se composant des phases : B Métier, C Système d’Information et D Technique, se concentrera sur l’architecture cible et ensuite, dans la 2ème itération, insistera sur l’architecture existante.

Architecture Micro-Services prescrite par TOGAF

La mise en œuvre de l’architecture micro-services (MSA) suivra les préconisations du guide TOGAF :

TOGAF® Series Guide Microservices Architecture (MSA)

et la méthode de conception DDD (Domain Driven Design), voir nos articles :

Le subtil mélange des concepts d'acteurs,
de Cas d'Utilisation (CU), de tâches et d'actions,
pour arriver à la panacée de l'analyse des besoins

UML n’est pas une méthode, Obeo a donc créé la sienne et l’a nommée Graal

En effet, UML ne donne aucune indication sur les niveaux de décomposition d’un cas d’utilisation, ce qui a toujours été problématique quand il s’agissait de régler le curseur sur la bonne granularité d’un artefact de modélisation, quel qu’il soit d’ailleurs. Voir nos articles :

Dans un autre article, nous évoquions la méthode des 10 - 10 (voir notre article :

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?)
Le postulat est de considérer qu'un Use Case est constitué au maximum de 10 scénarios, qui se décomposent en 10 étapes élémentaires. Les scénarios peuvent se modéliser en diagramme de séquence, avec utilisation des fragments comme “opt” pour les options, “alt” pour les scénarios alternatifs, “loop” pour les itérations, etc.

La méthode Graal préconise de :

Représenter les acteurs dans un graphe d'acteurs,
Modéliser l'ensemble des CUs (Use Case Main View) sans les acteurs, qui apparaîtront une fois les Use Case Diagrams réalisés (voir ci-après). On y perd son UML !
Détailler les tâches (Use Case Diagram) effectuées par un acteur pour un cas d'utilisation,
Affiner une tâche en explicitant les types d'actions (Actions Plan), comme les évènements de l'application, ses traitements internes, les vues de l'utilisateur et ses actions, équivalent sans le nommer d'un modèle BPMN.

1- Graphe des acteurs (pour un système), sosie d'UML, mais sans les cas d'utilisation

Après avoir créé un modèle Graal (voir l'annexe 1), un point de vue Graal Methodology est activé.

Le service Gestion des Prestations Prévoyance est composé de 7 gestionnaires et d’un responsable.

Pour le système PrevIT, nous commençons par représenter, dans le cadre de la méthode Graal, le graphe des acteurs sosies des acteurs UML.
Le Gestionnaire Prestation Prévoyance (GPP) crée des dossiers, les instruit et les valide tant que le montant ne dépasse pas 50 000 €. Le Responsable Prestation Prévoyance (RPP) procède aux mêmes tâches que le GPP, mais en plus il contrôle et valide les dossiers d’un montant supérieur à 50 000 €, gère les réclamations et manage son équipe.

2- Vue d'ensemble des Cas d'Utilisation (Use Case Main View), sans les acteurs

On identifie les fonctionnalités du futur système.

Remarque : les acteurs créés dans les "Use Case Diagram ou Task Graph" ont été masqués.

Avec les outils standards UML, il suffit, à partir du référentiel, de faire un drag and drop d’un acteur dans le diagramme de Use Cases, puis de le relier par une association au Use Case désiré.

Totalement impossible avec ISD, d’ailleurs l’icône Actor est absente de la palette du diagramme de Use Case (voir la figure ci-dessus). La démarche est déroutante, quand on a l’expérience des outils standards UML.

Pour associer un acteur représenté dans le graphe des acteurs, il faut, pour chaque Cas d'Utilisation de la vue d'ensemble, créer un “Use Case Diagram” (voir annexe 1).

Voir l'annexe 1 pour la procédure de création.

3- Qui (Acteur) et Quoi (Tâches), ensemble dans un même diagramme
(Use Case Diagram) pour un Cas d'Utilisation de la vue d'ensemble

Use Case Diagram (ou Tasks Graph) "Créer un dossier de prestation prévoyance" pour le CU du même nom. Le picto en bas à droite de la 1ère tâche signifie qu'une vue "Actions Plan" lui est associée
et est accessible par un double clic. Le picto "clé" montre que la tâche réalise des exigences.

Pour chaque CU de la vue d'ensemble (Use Case Main View), il est possible de créer un “Use Case Diagram” qui est en fait, dans la méthode Graal, un graphe de tâches (voir annexe 1), dans lequel vous pourrez associer des tâches à un acteur.

4- Dernier niveau de détail, la vue des actions (Actions Plan),
pour une tâche du Use Case Diagram

Une fois les tâches d'un acteur identifiées, vous pouvez, pour chacune d’entre elles,
créer une vue plan d’actions (Actions Plan).

Un plan d’actions est associé à une tâche. Ce graphe représente, de manière pragmatique, les traitements effectués par l’application, les écrans et les interactions effectuées par l’acteur.
Il s’agit en fait d’un modèle BPMN simplifié, dans lequel on retrouve les principaux types de tâches (évènement, action de l’application, vue utilisateur, action de l’utilisateur, tâche), les gateways, nommées ici opérateurs (and, or, xor, loop) et les transitions (simple, interruptible).

Voir l'annexe 1 pour le mode opératoire.

Packages et classes participantes

Organisation hiérarchique des classes du domaine
(Domain Classes Namespaces Hierarchy)

Cartographie des Capacités de l'entreprise (réalisée avec l'outil open source Archi)

La méthode Graal reprend le terme namespace, utilisé dans de nombreuses technologies comme XML, pour désigner les packages UML. Seul le concept de hiérarchie est conservé. Les dépendances entre les namespaces sont automatiquement ajoutées à partir du diagramme des entités métier abordé dans le paragraphe suivant. Toutes les autres relations complexes et rarement utilisées ont été éliminées.

Avec le formalisme UML, on peut créer des classes dans le vide sidéral, sans aucune organisation hiérarchique. Pour pallier ce défaut, la méthode d'Obeo contraint le Business Analyst à créer au moins un namespace pour pouvoir ensuite créer un modèle du domaine avec des classes métier. En UML, cela se traduirait par un diagramme de package.

Les namespaces (package en UML) peuvent modéliser des fonctions ou des domaines métier
de l'entreprise en corrélation en ajoutant les dépendances.

N.B. Le nombre de dépendances entre Prestation Prévoyance et Produit vaut 2
(voir l'annexe 1, le diagramme de classes participantes de Prestation Prévoyance)

Diagramme des entités métier (Domain Classes Diagram)

Le modélisateur qui utilise le diagramme de classes UML doit préciser le destinataire, le contexte et l’objectif. Par exemple, dans un modèle du domaine "Entités métier/Relations" réalisé par les Business Analysts pour le compte de la MOA, les méthodes, les niveaux d’encapsulation, les identifiants techniques, etc. n'y figurent pas, mais rien ne l’interdit.

Dans son Graal du NoUML, Obeo a repris le diagramme de classes UML pour en faire un diagramme de classes du domaine modélisant uniquement les entités métier avec leurs données et leurs relations.

Diagramme de classes du domaine (namespace) "Prestation Prévoyance"

Les classes du domaine "Produit" et les relations avec les autres domaines "Contrat" et "Prestation"

Voir l'annexe 1 pour le mode opératoire.

Conclusion

Avec sa méthode Graal, Obeo s'est bien imprégnée des principes du NoUML. Son implémen-tation au travers de l'outil ISP, permet un usage pragmatique, les modèles sont affinés par de petits incréments, les notations simples facilitent la validation. L'utilisateur peut se focaliser plus aisément sur les aspects qu'il doit modéliser.

Pour l'aspect dynamique du système, la démarche permet de considérer les rôles des acteurs, puis, à une autre étape, les cas d'utilisation. Leur granularité étant toujours problématique, l'utilisateur sera aidé en ayant la possibilité de décomposer suivant 2 niveaux de détails :

les scénarios (Tasks Graph),
les étapes (Actions Plan).

Pour ceux qui le désirent, il est possible d'ajouter des diagrammes de séquence et d'état.

L'aspect statique se compose de diagrammes semblables à UML, mais expurgés des éléments rarement utilisés :

les domaines métier (Namespaces),
les entités métier et leurs relations (Domain Classes).

Dans notre prochain article, nous verrons que Graal a aussi intégré des concepts qui faisaient défaut à UML, comme les exigences et les User Stories. Mais cela est une autre histoire.

Merci pour vos commentaires qui seront les bienvenus, ainsi que vos retours d'expérience heureux ou malheureux, qui pourront profiter à nos lecteurs.

Rhona Maxwel

urbanisation-si.com

@rhona_helena

" L’inertie seule est menaçante. Ne crains pas, ni ne doute,
car le doute est stérile et la crainte est servile. "
Saint-John Perse

Annexe 1 : mode d'emploi

Résumé de l'épisode précédent

Dans notre article :

Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1

nous avions vu les caractéristiques d'ISD, son interopérabilité avec Obeo SmartEA, comment installer ISD et comment créer un "Modeling Project".

Créer un modèle Graal

Menu File ou clic droit sur le Modeling Project > New > Other > IS Designer > Graal Model

Créer un graphe d'acteurs (Actors Graph) pour un Système

Clic droit sur "System" > New representation > Actors Graph > nommer le diagramme

Créer une vue d'ensemble de Cas d’Utilisation (Use Cases Main view) pour un Système

Clic droit sur "System" > New representation > Use Cases Main View > nommer le diagramme

Use Case Main View avec les acteurs, des use case inclus, des compositions de tâches
et la traçabilité vers des exigences.

Les acteurs sont affichés uniquement quand dans la liste déroulant "Layers", l'option "Actors" est cochée (4ème icône à partir de la gauche en dessous de l’onglet de la vue). Les liens entre acteurs et les cas d’utilisation sont déterminés automatiquement à partir des liens entre acteurs et tâches dans un "Use Case Diagram" ou "Task Graph".

Les icônes "Change Diagram edition mode" et "Show/Hide" permettent d'Afficher/Masquer tous types d'éléments.

Le picto en bas à droite du CU "Créer un dossier de prestation prévoyance" signifie qu'un "Use Case Diagram" existe, pour détailler l'acteur et ses tâches. Un double clic suffit pour y accéder. Le picto "clé" sur le CU "Enregistrer un sinistre en attente de justificatifs" signifie qu'il réalise des exigences. Une simple sélection affiche un onglet avec la liste des exigences.

Créer un diagramme (Use Case diagram ou Tasks Graph) pour un cas d’utilisation

Clic droit sur le use case dans la vue d'ensemble > New > Create Use Case Diagram ou dans l'onglet Model Explorer > sélectionner le Modeling Project > la méthode Graal > le conteneur System > sélectionner un use case > clic droit > New Representation > Other > Graal Methodology > Use Case Diagram

Pour affecter un acteur à une tâche, vérifier que le calque “Actors” est bien activé dans le ruban en sélectionnant Actor > drag and drop d'Actor de la palette sur la tâche > choisisser l’acteur qui a déjà été modélisé dans le graphe des acteurs. A ce niveau, il n'est pas possible de créer un nouvel acteur, qui doit être opéré uniquement dans la vue graphe d'acteurs, ce qui plutôt bien en évitant la fonction de création à de multiples endroits.

La vue globale de cas d’utilisation du système est mise à jour automatiquement avec l’acteur.
(Il en va de même pour le graphe de tâches système.)

Créer un plan d’actions (Actions Plan) pour une tâche

Dans un graphe de tâches (ou Use Case Diagram) : clic droit sur une tâche > New > Actions Plan

Similaire à un BPMN, on retrouve la typologie
des principales tâches (Actions), les évènements, les passerelles (Operators)...

Créer des namespaces

Dans l'onglet Model Explorer, sélectionner le Modeling Project > Méthode Graal > conteneur System > Domain Classes Namespaces Hierarchy ou clic droit sur System > New Representation

Remarque : pour visualiser les dépendances entre les namespaces qui seront créées dans le Domain Classes Diagram, il faut activer le calque Dependencies dans la liste Layers, 4ème icône du ruban.

Créer un ”Domain Classes Diagram” (classes participantes ou métier)

Sélectionnez un namespace > clic droit > New > New Domain Classes Diagram

Pour relier des classes appartenant à des namespaces différents il faut :

dans le diagramme Domain Classes Namespaces Hierarchy activer le calque Dependencies,
dans le diagramme Domain Classes Diagram activer le calque External Domain Classes,
sélectionner dans la palette External Domain Class puis le namespace et la classe,
sélectionner dans la palette Relation, cliquer la classe de départ, déplacer la souris jusqu’à la classe d’arrivée.

Annexe 2 : compléments de lecture

ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?

29/08/2023

2 J'aime 0 Poster un commentaire

A découvrir aussi

Retour aux articles de la catégorie Modélisation de système -

⨯

Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 719 autres membres