urbanisation-si.com

Le diagramme des entités métier a pour objectif de modéliser les entités cœur de métier en faisant attention à rester au niveau macroscopique. Cela signifie de ne s'intéresser qu'aux concepts primaires en faisant abstraction de toutes considérations techniques. Plusieurs niveaux d’échelle pourront être réalisés : 1 - uniquement les entités/relations, 2 - ajout des propriétés et 3 - regroupement en domaines.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des administrateurs données et des architectes applicatifs.

1 - uniquement les entités/relations

Ce modèle à « grosses mailles » utilise :

• le stéréotype normalisé « entity », appliqué à l’artefact « classe » d’UML et signifiant un concept métier,
• les associations et les compositions UML en précisant les cardinalités et le nom du rôle joué par l’entité dans l’association.

La mise au point de ce modèle est itérative, il doit être documenté de manière textuelle et pédagogique, expliqué aux parties prenantes et validé.

A ce stade, ce modèle ne doit comporter aucun aspect applicatif voir technique comme par exemple la persistance, l’historique, …

Le piège est d'être trop technique d’un point de vue modélisation.

Comme les utilisateurs ont souvent des préjugés erronés dans certains domaines, la clé de la réussite passera par l'omission des termes à connotation technique (UML, classe, objet, attribut, ...) et par leurs remplacements par des termes plus neutres et proches du jargon métier (cadre, entité, valeur, donnée, ...).

2 - ajout des propriétés

De manière similaire à un cartographe qui augment l’échelle pour avoir une nouvelle carte avec plus de détails (mais avec moins de couverture), on reprend le modèle précédent en précisant les propriétés (attributs UML) significatives pour le métier.

C’est dans la phase suivante « phase C : Architecture des systèmes d’information », dans la modélisation de l’architecture des données que seront réalisés les diagrammes logiques de données concernant les données persistantes et ajoutant bon nombre de précisions sur les entités secondaires et autres raffinements UML.

Avec des outils MDA (Model Driven Architecture), ces modèles logiques et physiques pourront être obtenus automatiquement en dérivant les modèles conceptuels.

Voir à la fin de cet article l'annexe 2 concernant les articles sur le diagramme de classe, d’état et de package UML et sur la dérivation de modèles

Si vous appartenez à cette première génération d’informaticiens, vous connaissez surement cette méthode française désuète qu’était « Merise » avec son MCD (Modèle Conceptuel de Données), MLD (Modèle Logique de Données) et MPD (Modèle Physique de Données).

3 - regroupement en domaines

Après avoir réalisé le modèle macroscopique entités/relations, on regroupe les entités par affinités fonctionnelles en domaines (package UML).

Ceci permet d’avoir une vue globale et synthétique des familles d’entités.

En « zoomant » sur un domaine on obtient le diagramme entités/relations correspondant.

On voit qu’un outil de modélisation est indispensable pour réaliser cette traçabilité et assurer la fonction de référentiel des données métier.

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas

Conclusion

Le diagramme des entités métier permet d’être dérivé afin d’obtenir le modèle logique de données et les composants applicatifs « entité ».

Le modèle des processus métier et des services l’utilise pour représenter les données en entrée/sortie des activités.

L’outil de modélisation doit intégrer entre autres la gestion du référentiel, la traçabilité et la dérivation des modèles.

Rhona Maxwel

@rhona_helena

"Le progrès n’est que l’accomplissement des utopies."

Oscar Wilde

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

• Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio
   
• 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
   
• 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)
   
• 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 
   
• Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst
   
• 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)
   
• Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)
   
• Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas
  
  
• Le diagramme SysML des exigences de la phase A Vision de TOGAF : étape 4.2 de l’étude de cas
  
  
• Le diagramme d’évènements de la phase A Vision de TOGAF : étape 5 de l’étude de cas Modelio
  
  
• Le diagramme des concepts de la solution de la phase A Vision de TOGAF : étape 6 de l’étude de cas Modelio
   
• Le diagramme de chaîne de valeur de la phase A Vision de TOGAF : étape 7 de l’étude de cas Modelio
   
• Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
   
• Le dictionnaire métier de la phase B Architecture métier de TOGAF - étape 9 de l’étude de cas
   
• Le diagramme d’organisation des acteurs de la phase B Architecture métier de TOGAF - étape 10 de l’étude de cas
  
  
• Comment modéliser les flux échangés entre une entreprise et les acteurs externes en phase B architecture métier de TOGAF ? – étape 11 de l’étude de cas
  
  
• Diagramme des rôles joués par les acteurs en phase B architecture métier de TOGAF ? – étape 12 de l’étude de cas
  
  
• Diagramme d’organisation et de localisation en phase B architecture métier de TOGAF – étape 13 de l’étude de cas
  
  
• Diagramme de localisation en phase B architecture métier de TOGAF – étape 14 de l’étude de cas
  
  
• Diagramme de décomposition fonctionnelle en phase B architecture métier de TOGAF – étape 15 de l’étude de cas
  
  
• Diagramme objectifs-services métier en phase B architecture métier de TOGAF – étape 16 de l’étude de cas
  
  
• Diagramme de processus métier en phase B architecture métier de TOGAF – étape 17 de l’étude de cas
  
  
• Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems
  
  
• Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio
  
  
• Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio
  
  
• Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio

Annexe 2 : articles sur le diagramme de classe, d’état et de package UML et sur la dérivation de modèles

• Le dictionnaire métier de la phase B Architecture métier de TOGAF - étape 9 de l’étude de cas
  
  
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe
  
  
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 8ème partie - Etats métiers – UML – Diag. Etats
  
  
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package
  
  
• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (2)
  
  
• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (8)
  
  
• Pour trouver les services logiques, les modèles sémantiques et pragmatiques tu dériveras. (« Praxeme 4ème commandement extrait de la bible de l’aspect logique »).