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 - urbanisation-si, modelisation-metier, processus-metier, expression-des-besoins

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

L'éditeur logiciel Obeo propose 2 outils interopérables :
le premier, open source, dédié aux architectes logiciels : Information System Designer
et le second, commercial, dédié aux architectes d’entreprise : SmartEA.
Les applications sont complètement modélisées et leurs codes générés dans ISD,
et, grâce à un connecteur, les modèles peuvent ensuite être exportés dans SmartEA.

Et si l'on inversait les rôles ? Si l'on partait de la documentation pour arriver à la réalisation, au code. Le Doc2Code serait-il né ?

Pour assurer la collaboration entre l'architecte logiciel et l'architecte d'entreprise, il faudra payer. Dommage de ne pas avoir choisi le 2 en 1

Pourquoi choisir ISD ?

ISD est un studio moderne pour l’analyse, la conception et la génération de code d’applications s’interfaçant avec l’outil d’Architecture d’Entreprise SmartEA d'Obeo.

Le studio est une base centrale, collaborative de modélisation
afin de générer la documentation et le code.

L’objectif principal est de permettre aux fonctionnels, architectes applicatifs, concepteurs-développeurs et acteurs DevOps, de partager leurs connaissances et leur compréhension du SI, avec des représentations intelligibles.

La méthode Graal d'analyse métier, ainsi que les autres couches,
seront entièrement abordées dans nos prochains articles.

Information System Designer (ISD) offre à la fois la capture des besoins, les cas d’utilisation, les IHM, les services métiers, les entités métiers, les schémas de base de données.
C’est donc un studio de conception d’applications constitué d’un ensemble de modeleurs pour construire des architectures applicatives.
Il intègre une fonctionnalité nommée scaffolding permettant la transformation de modèles.

D’après Obeo, le pourcentage de code généré avec ses générateurs maison customisés avoisinerait 80 %. Les 20 % restants concernent par exemple l’implémentation des modèles états-transitions et les IHM qu'il ne serait pas rentable de faire générer.

Fiabilité de l'architecture garantie
par les générateurs d’Obeo

Contrairement aux frameworks d’ORM (Object Relational Mapping) comme Hibernate, Eclipse Link ou encore Spring Boot, ISD, à partir d’un modèle inspiré du diagramme de classe UML (voir ci-après NoUML), génère les scripts SQL, les exécute dans le RDBMS, génère le code Java et, cerise sur le gâteau, génère la totalité des tests unitaires.

NoUML, pas tout à fait, disons
un UML pragmatique sans fioritures

Entre norme pour technocrate et simplicité alliée à l'efficacité, Obeo a tranché

Comme déjà décrit dans nos articles :

"NoSQL, NoCode et NoUML ? Faut-il encore modéliser avec UML ? Défauts et qualités de cette norme de l’OMG vieillissante",

Que faut-il garder d'UML ? Quelles seraient les évolutions nécessaires ? Va-t-on vers un reboot d'UML ? Quelles alternatives à UML ?

UML pêche par sa complexité et freine l’Ingénierie Dirigée par les Modèles
(voir la catégorie IDM).

Deux solutions s’offraient à Obeo :

se conformer à la norme en concevant un profil UML, comme par exemple SysML
prendre ses distances en se déclarant NoUML

C’est la deuxième solution qui a été choisie. Comme l’objectif du studio ISD est la conception d’applications, la première solution aurait été compliquée et peu efficiente pour la génération de code.

Obeo a donc choisi, pour se libérer des sévères contraintes et pallier les manques de la norme de l’OMG, la deuxième solution en créant un DSL (Domain-Specific Language) représentant des modèles spécifiques pour représenter visuellement les différents aspects d’une application :

Exigences (absent d’UML, mais présent dans SysML)
Scénarios d’usage
Base de données
Entités de données
Services
IHM et cinématique des écrans (absent d’UML)

Conclusion

Cet outil, interopérable avec SmartEA, permettra d'assurer que les spécifications techniques sont correctement comprises et que les développements sont conformes à l'architecture d'entreprise.

ISD a fait le choix du NoUML en concevant son propre DSL pragmatique et inspiré d’un UML très simplifié.

De la modélisation oui, mais pas trop, juste ce qu’il faut pour pouvoir générer et documenter du code, c'est ce que nous verrons dans nos prochains articles consacrés d'abord à la méthode Graal d'Obeo pour l'analyse métier, puis aux services SOA (Service-Oriented Architecture), aux entités métiers et pour finir les générateurs de codes.

Rhona Maxwel

urbanisation-si.com

@rhona_helena

" Presque aucune part n’est réservée à l’enseignement de la parole proprement dite ; l’écolier apprend à lire, à écrire, à compter, à raisonner, non à parler (…). Ils seront dans la vie la proie de quelque bavard, expert au langage courant "
Jean Zay