urbanisation-si.com

urbanisation-si.com

Modélisation métier


Knowledge Graph et Architecture d’Entreprise (2/2)

Des ontologies modulaires
pour gérer la complexité et la pluridisciplinarité

Un Knowledge Graph, c’est une base de connaissance sous forme de graphe. Pour sa conception, il est crucial de clarifier les questions auxquelles elle devrait pouvoir répondre, ainsi que celles portant sur sa maintenance et son évolution.

 

Une approche clé pour assurer la flexibilité et la maintenabilité d’un Knowledge Graph consiste à le baser sur plusieurs ontologies modulaires inter-reliées, avec un noyau central. Chaque module peut alors être conçu pour traiter des concepts, des relations et des règles spécifiques à un sous-domaine d’expertise, ce qui en facilite la gestion et l’évolution avec les experts du domaine.

 

En reliant ces ontologies modulaires entre elles, on crée un réseau de connaissances. Cela permet de représenter des relations complexes entre les concepts qui transcendent les frontières des différents sous-domaines, offrant ainsi une vue globale et intégrée du domaine métier dans son ensemble. Or c’est typiquement un besoin des descriptions d’architecture de pouvoir représenter des couches d’architecture et leurs correspondances. Ou de présenter des perspectives spécifiques. Par exemple, la gestion des risques, l’architecture applicative, l’architecture des données, l’infrastructure technologique, l’évaluation de la performance…

 

Un noyau central définissant les fondamentaux de l’EA, via les concepts et relations réutilisables pour tous les modules, permettra l’interopérabilité. La référence à une ontologie de haut niveau (top-level) ou des « patrons » de conception servira à ne pas réinventer la poudre pour des problèmes généraux de conception déjà bien connus.

 

Bien entendu, la conception d’un Knowledge Graph d’Architecture d’Entreprise doit suivre les bonnes pratiques. En particulier, réutiliser autant que possible des ontologies existantes et des vocabulaires standards pour éviter la duplication d’efforts et promouvoir la cohérence avec les pratiques établies dans le domaine.

 

Des ontologies pour des Knowledge Graphs agnostiques des cadres de référence

Les concepts décrits dans une ontologie d’Architecture d’Entreprise (ou module), existent indépendamment des cadres de référence ou langages de description. Car si ces derniers sont réutilisables pour les identifier et les définir, ni un glossaire, ni des textes descriptifs, ni des objets graphiques ne spécifient formellement des concepts et des relations. « Things, not strings » : une ontologie définit des choses et les labels donnés aux choses ne suffisent pas pour les définir. Si deux terminologies différentes désignent le même concept, on trouvera un concept et deux labels dans l’ontologie. Quand elles désignent l’une une spécialisation, l’autre une généralisation, on définira les relations de subsomption et les caractéristiques propres des deux concepts. Et si au contraire elles désignent deux choses différentes et disjointes, on doit le définir également.

 

Une ontologie, c’est une représentation sémantique riche des entités et de leurs relations en mesure de suivre l’évolution des connaissances. En utilisant les standards du Web sémantique (RDF, RDFS, OWL), contrairement à certains langages de modélisation plus rigides, les Knowledge Graphs sont flexibles et extensibles. Ils permettent d’ajouter de nouveaux concepts, relations et attributs au fur et à mesure que l’Architecture d’Entreprise évolue, assurant ainsi une représentation toujours à jour et adaptable.

 

Pour prendre l’exemple du langage graphique de description d’architecture ArchiMate, les liens sont limités et certains concepts spécifiques à la stratégie d’offre, au marché, aux situations, aux aspects financiers, ne sont pas dans l’ensemble de ceux prédéfinis.

 

A contrario, un réseau d’ontologies modulaires peut spécifier des concepts dans tous les sous-domaines de gouvernance et de pilotage de l’entreprise et les relier aux capacités de l’entreprise et les composants qui les supportent. Tout Knowledge Graph exploitant ce réseau peut dès lors procurer une représentation plus riche, flexible et contextuelle des éléments clés éclairant les décisions qui engagent l’entreprise.

 

Architecture d’Entreprise et continuum d’ontologies

OntoPortal-Alliance

 

Alliance autour de la technologie OntoPortal

 

La démarche de description d’Architecture d’Entreprise est continue, itérative et incrémentale. On peut difficilement arriver à une architecture unifiée unique qui satisferait à toutes les exigences de toutes les parties prenantes à tout moment et l’idéal d’avoir des documentations et des modèles à jour suivant toutes les perspectives est une utopie dont la mise en œuvre est dystopique.

 

Des plateformes pour réutiliser des ontologies consistantes et cohérentes, ou accéder à des patrons de conception et des outils de développement et de curation pour modéliser et implémenter de nouvelles spécifications, ont été mises en place dans différents secteurs d’industrie. Elles concrétisent une approche réellement FAIR des métadonnées.

 

L’alliance OntoPortal autour de l’outil éponyme (https://ontoportal.org) est significative du besoin de promotion de telles plateformes pour « le développement de référentiels d’ontologie – en science et dans d’autres disciplines ».

 

Le parallèle peut être fait avec la notion de Continuum d’Entreprise qu’on trouve dans TOGAF. L’idée est d’organiser des artefacts d’architecture et des actifs de solutions réutilisables afin de maximiser les opportunités d’investissement dans l’Architecture d’Entreprise. Dans cette optique, la construction de plateformes communes aux architectes d’entreprises pour recevoir, héberger, servir, aligner et permettre la réutilisation d’ontologies pour l’EA a tout son intérêt. On devrait y trouver différentes ontologies d’entreprise et des métamodèles génériques à spécialiser ou étendre.

 

Un métamodèle d’entreprise générique
et un langage graphique : EDGY

EDGY-Design-Facets

 

EDGY enterprise design facets

 

Si toute entreprise a sa propre dynamique, toutes les entreprises partagent le fait d’avoir des produits et/ou services, des offres portant sur ces produits, des processus supportant les opérations, des rôles, des acteurs, des applications des SI avec des composants, etc. On peut très bien s’entendre sur un vocabulaire et des axiomes logiques pour exprimer ce genre de choses et leurs liens.

 

Dans ce domaine, l’initiative de la communauté Intersection Group est à souligner. Car elle introduit, avec l’approche « Enterprise Design with EDGY », un langage graphique simple et expressif pour un métamodèle d’entreprise transverse à tous les métiers. En effet, EDGY propose une vue unifiée et consolidée de l’entreprise à des fins de décision collaborative grâce à l’intersection entre trois perspectives : identité, Expérience et Architecture.

 

La première traite de la raison d’être de l’entreprise aussi bien que de sa culture. A ce sujet, le mantra
« culture eats strategy at breakfast » illustre bien l’importance de ces concepts. La seconde se focalise sur l’expérience procurée aux clients et aux autres acteurs. Une manière également pertinente de traiter dynamiquement de la valeur créée pour les parties prenantes. La dernière s’interroge sur comment orchestrer tout cela, en déclinant modèle d’affaires, modèle opératoire et composants d’architecture.

 

Le credo d’EDGY est d’avancer que les connecteurs nécessaires à créer entre des disciplines traitées aujourd’hui de façon trop isolée se trouvent à l’intersection desdites perspectives, où l’on trouvera les concepts de produit, organisation, marque.

 

L’approche EDGY propose les outils pour élaborer une représentation graphique commune, utile et transverse, des éléments clés de l’entreprise à des fins de décision. Cependant, il lui manque encore la dimension formelle des ontologies, pour disposer également d’une base de connaissances sémantiquement riche.

 

Un outil d’EA basé sur des ontologies :
The Essential Project

Essential-Project-Meta-Model

 

Illustration du Meta-Model d’Essential avec zoom sur partie métier

 

Fournir pour la description des composants d’architecture, un métamodèle à base d’ontologies, flexible et extensible, cela existe déjà. Dès 2009, «The Essential Project » a été lancé par l’équipe des consultants d’EAS (Enterprise Architecture Solutions) sur cette base, en modélisant des ontologies sous Protégé. La première version open source d’Essential (visant les capacités essentielles à une pratique d’EA) date de mars 2009. La mise en relation avec les concepts TOGAF n’est arrivée qu’en 2015.

 

Certes, ce sont des demandes des utilisateurs qui ont conduit à la publication d’un mappage TOGAF vers Essential. Reste que, selon EAS, « le métamodèle Essential est, en fait, plus riche en contenu et prend en charge tous les principaux frameworks EA, tout en restant indépendant du framework ».

 

L’outil Essential a été placé « visionnaire » dans le Gartner Magic Quadrant 2023 des outils d’Architecture d’Entreprise. Si l’on consulte Gartner Peer Reviews, il est globalement bien noté. Avec des commentaires tels que ce dernier : « EAS has a powerful metadata repository that can cover multiple dimensions of the architecture. Also, the look and feel is very appealing, with easy to navigate reports ». Certes, à d’autres égards, notamment les représentations graphiques, il offre moins de richesse que d’autres alternatives.

 

Mais si l’essentiel recherché est d’avoir effectivement les bons liens entre composants, pour une bonne analyse d’impact, il correspond. Grâce à son métamodèle à base d’ontologies. Tandis que ceci est rarement capturé sans la moindre ambiguïté par un diagramme, au contraire d’un Knowledge Graph. De plus, si l’on part sur l’usage des technologies RDF et OWl, l’interopérabilité du référentiel d’architecture avec d’autres outils utilisés comme bases de modèles, de documentation ou d’exigence sera de facto facilitée, éventuellement avec un VKG et des outils de conversion conformes à RML.

 

A quand un EAO comme OBO ?

Il manque toutefois un véritable consensus sur des spécifications formelles de conceptions partagées des domaines de connaissance en Architecture d’Entreprise. I.E les ontologies du réseau modulaire évoquées précédemment, avec un moyen de généraliser ou spécialiser certaines. Tout autant qu’un moyen pour les partager (en mode FAIR) ainsi que disposer de services utiles sur tout le cycle de vie du (ou des) Knowledge Graph d’architecture qu’on peut construire à partir de ces spécifications.

 

On sait que dans certains domaines, cela existe, le plus connu étant l’OBO foundry pour la biologie et la biomédecine. Une communauté autour d’OBO a développé de bonnes pratiques autant pour l’évaluation, la curation, la réutilisation des ontologies que pour la constitution d’outils utiles à leur développement. On peut évoquer des outils comme ODK, ROBOT, ou OntoPortal.

 

Comme on peut évoquer de nombreux outils, conformes à RML, qui faciliteront le mapping en RDF de sources de données existantes pour la construction des Knowledge Graphs d’EA en entreprise.

 

Si les bénéfices et les outils existent, une question demeure. Pourquoi nulle communauté d’architecte, éventuellement avec le financement d’une association de standardisation, n’a construit d’EA Ontology foundry ? Est-ce parce que financer une telle démarche serait contre-productif pour certains modèles d’affaires associés aux cadres de références d’EA existants ?

 

Sabine BOHNKÉ

Logo-Semsimo

"Le vrai signe d'intelligence n'est pas la connaissance, c'est l'imagination."
Albert Einstein

 

Compléments de lecture

  

 


06/06/2024
0 Poster un commentaire

Knowledge Graph et Architecture d’Entreprise (1/2)

Un potentiel mal exploité

architecture-entreprise-champ-des-éléments-en-interaction

 

Champ des éléments en interaction pour l’Architecture d’Entreprise

 

L’Architecture d’Entreprise (AE) est une discipline destinée à favoriser, face à des situations en constante évolution, le développement d‘une stratégie d’entreprise conforme à ses finalités ainsi que son exécution ad hoc.

 

Cette discipline est profondément liée aux approches de représentation des connaissances. Il est donc curieux que le potentiel des Knowledge Graphs y soit encore insuffisamment exploité. En effet, ces derniers sont pertinents pour représenter de manière expressive la sémantique d’un système. Ils offrent également des moyens de naviguer entre les concepts de connaissance et leurs interrelations. Cela en suivant des standards du Web sémantique et des modèles et ensembles de données FAIR (Findable, Accessible, Inter-operable, Re-usable).

 

Il est toutefois décevant, au niveau de la couche sémantique, de constater que les essais d’approche des Knowledge Graphs pour l’Architecture d’Entreprise – à quelques exceptions près – se soient cantonnés à des traductions littérales en langage OWL de modèles ou de cadre de référence existants. Or exprimer en OWL les règles et objets de langages tels ArchiMate ou la terminologie de TOGAF, a peu d’intérêt. On restreint ainsi une richesse d’expression sémantique aux contraintes voire incohérences de sources existantes. Les réutiliser à un sens, mais il ne faut pas confondre sources terminologiques et spécification formelle d’une conceptualisation.

 

Pour que l’approche des graphes de connaissances appliquée à l’Architecture d’Entreprise fonctionne, il ne faut pas se tromper de cible. Aussi suivre les bonnes pratiques de construction, tant pour la conception que l’implémentation. Cet article développe aussi bien les enjeux en la matière que les moyens d’y arriver.

 

Architecture d’Entreprise
et représentation des connaissances

Une partie de l’Architecture d’Entreprise consiste à décrire le système entreprise au juste nécessaire dans son environnement. Ce « juste nécessaire » revient à disposer d’informations clés afin de réduire l’incertitude sur les situations en développement. Il s’agit autant de décrire les objectifs stratégiques que les aspects organisationnels, les capacités, les ressources, les processus, les technologies, en d’autres termes, tous les composants essentiels qui structurent l’entreprise, leurs interactions ainsi que leurs évolutions dans un monde ouvert, à des fins décisionnelles. L’idéal étant de pouvoir simuler l’impact de choix sur une représentation de l’entreprise à un instant t.

 

Les descriptions d’architecture servent à acquérir une connaissance utile pour comprendre, choisir et planifier les actions de transformation en continu. L’entreprise est, par ailleurs, un système dynamique complexe. Dès lors, l’approche systémique est de mise. Elle conduit à se concentrer sur les interactions internes entre éléments du système ainsi que leurs relations externes avec l’environnement. Sans oublier, bien sûr, de définir clairement les finalités du système pour identifier des pistes d’évolution conformes aux enjeux stratégiques.

 

Tout cela nécessite de décrire explicitement ce qui est su des éléments et leurs interactions. Donc de collaborer avec des « SME » (Subject Matter Expert) pour éliciter leurs connaissances. Il faut ensuite la formaliser tout en intégrant la nécessité permanente de mise à jour. Dès lors, des outils et procédés de représentation et partage des connaissances sont nécessaires à plusieurs niveaux d’abstraction.

Things, not strings

things-not-strings-example

 

Image extraite de l’article de Amit Singhal « Introducing the Knowledge Graph: things, not strings »

 

Deux erreurs communes depuis des années sont prégnantes dans les systèmes d’information. Modéliser des données pour stockage avant d’expliciter les concepts manipulés et penser plus au couple problème/solution qu’aux enjeux globaux. D’où le fameux « integration spaghetti » du Gartner. C’est à dire un SI constitué d’une mosaïque de systèmes peu évolutifs, peu interopérables, avec de nombreux silos de données.

 

Quand on parle de concepts manipulés, ce sont les objets métiers, concrets ou abstraits de l’univers du discours de l’entreprise. Un constructeur automobile manipulera des concepts liés aux voitures, un assureur, des contrats d’assurance. Les acteurs métiers aujourd’hui évoquent des « données métiers ». En réalité, les données ne sont déjà plus des objets métiers. Ce sont des traductions en formats numériques, de parties de choses utiles au métier. Et souvent, sous la seule perspective à court terme d’un fonctionnement applicatif recherché.

 

Dans le champ de l’Architecture d’Entreprise, il y a nécessairement la description des objets métiers manipulés par les acteurs. Cette description sert autant à définir les capacités à développer qu’à fluidifier les échanges entre systèmes d’information.

 

En 2012, un article de Amit Singhal « Introducing the Knowledge Graph: things, not strings » saluait l’arrivée du Google Knowledge Graph. Things, not strings : tel devrait être également le slogan des échanges entre systèmes d’information.

 

Les choses sur lesquelles on a besoin d’information ne sont pas les chaines de caractères qui les désignent. Pas plus qu’elles ne sont la façon dont on les stocke ou on les transfère. On a besoin d’un niveau de représentation indépendant des plateformes ou des syntaxes des formats d‘échange pour dire que les données qu’on manipule sont bien liées à telle ou telle chose. Des métadonnées connectées dans un « Knowledge Graph » sont typiquement une réponse à ce besoin.

 

Architecture d’Entreprise,
Virtual Knowledge Graph et Data Fabric

using-data-fabric-architecture-to-modernize-data-integration-0

Image extraite de l’article du Gartner
« Data Fabric Architecture is Key to Modernizing Data Management and Integration »

 

Un Knowledge Graph consiste en une ou plusieurs ontologies formelles liées et des ensembles de données cohérents avec celles-ci. En créant les ontologies spécifiant les concepts de l’entreprise, on peut ensuite créer un « Virtual Knowledge Graph » (VKG). Il s’agit du concept autrefois nommé OBDA (Ontology-Based Data Access).

 

En utilisant des ontologies, de la fédération de requêtes SPARQL et du mapping (R2ML), cette approche offre un moyen d’interroger les différentes sources de données distribuées au sein de plusieurs systèmes en fonction des concepts métiers sur lesquels elles ont des informations. Elle permet en outre aux données de rester dans leurs bases d’origine pour une gestion plus agile et plus efficace.

 

Ici, la description, via une spécification formelle, de composants de l’Architecture d’Entreprise, permet d’optimiser la construction d’autres composants d’architecture. Il existe par ailleurs des outils commerciaux et open source pour créer des VKG. Au-delà de la notion de VKG, c’est le concept de Data Fabric qui profite au mieux des Knowledge Graphs. En utilisant la couche sémantique du graphe de connaissance pour établir la provenance, la qualité et le sens des données gérées dans les systèmes d’information de l’entreprise, on s’oriente vers une meilleure vue intégrée et unifiée de ces derniers. Ce que soulignait l’article publié en 2021 sur le site du Gartner « Data Fabric Architecture is Key to Modernizing Data Management and Integration » : « Data fabric must create and curate knowledge graphs ».

 

Architecture d’Entreprise :
cas d’usage des Knowledge Graphs

Certes, la construction et la curation desdits Knowledge Graphs nécessitent des efforts. Cependant, il existe de meilleures pratiques et des outils pour des résultats relativement rapides avec des solutions robustes et évolutives.

 

Deux orientations d’usages des Knowledge Graphs dans le domaine de l’Architecture d’Entreprise sont particulièrement intéressantes. L’une, déjà évoquée, porte sur l’interopérabilité sémantique via la spécification des concepts métiers pour cas d’usage analytique ou transactionnel. L’autre porte sur l’activation dynamique d’un métamodèle des composants d’une entreprise pour guider des changements stratégiques. En spécifiant formellement les composants à connaître, ainsi que leurs interrelations, pour décider et suivre au mieux l’évolution des transformations, on peut construire un graphe de connaissance qui permettrait de réduire les incertitudes liées aux options de changement.

 

Les Knowledge Graphs aident à contextualiser les décisions liées à l’évolution du système d’information en reliant les éléments architecturaux aux facteurs d’influence externes, aux objectifs métier, aux contraintes opérationnelles et aux tendances technologiques. Cette vision holistique guide les décideurs vers des choix plus éclairés et alignés sur les objectifs stratégiques de l’entreprise. Par ailleurs, en spécifiant avec des métadonnées les relations entre les composants, les Knowledge Graphs facilitent l’analyse d’impact des changements. Cela permet de comprendre rapidement comment une modification dans une partie spécifique de l’architecture peut affecter d’autres composants, aidant ainsi à anticiper les conséquences potentielles et à simuler des scénarios pour prise de décision.

 

Mais si l’on veut un Knowledge Graph d’Architecture d’Entreprise, contenant tous les composants de l’entreprise ainsi que leurs liens, comment procéder ? N’est-ce pas un travail trop complexe ?


Vous trouverez des éléments de réponses dans le prochain article
" Knowledge Graph et Architecture d’Entreprise (2/2) ".

 

 

Sabine BOHNKÉ

Logo-Semsimo

 

 

 

 

« La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information. »

Albert Einstein

 

Compléments de lecture

Métamodèle TOGAF - ArchiMate

  

Les critères d'un bon modèle

   


28/05/2024
0 Poster un commentaire

Comment vérifier un modèle ? Exemple de simulation d’un processus métier BPMN

La simulation de modèle donne vie à vos modèles dynamiques grâce à une exécution instantanée et en temps réel. 
Couplé avec des outils pour gérer les déclencheurs, les événements, les contraintes, les règles, les points d'arrêt et les variables de simulation, ainsi que la possibilité de suivre visuellement l'exécution, le simulateur est un moyen puissant de regarder les roues tourner et de vérifier l'exactitude de vos modèles. 

 

theorie-modelisation-simulation

 

(“Theory of Modeling and Simulation” Bernard P. Zeigler)

 

Objectifs de la simulation de modèle

Le principe fondamental de la simulation de modèle est la séparation du modèle et du simulateur. 

 

Le simulateur est défini comme un moteur de règles qui, en fonction d’un référentiel de règles, exécute un modèle qui sert à l’analyse du comportement. 

La relation de simulation permet de vérifier qu’en obéissant aux règles définies dans le modèle de simulation, le simulateur reproduit le comportement spécifié.

Le cadre expérimental spécifie les conditions d’observations du système et les objectifs de la simulation. 

Le système source (le système à modéliser) est une spécification et il peut être réel ou virtuel : il constitue la source de données observables.

Ces données observables forment la base de données de comportement. 

La relation de modélisation permet ainsi d’établir la validité de l’expérience.

 

La simulation a comme objectifs de :

  • tester une hypothèse du modèle du système de référence, de le vérifier ou d’accréditer la théorie qui a servi à le construire,

  • montrer l'aspect dynamique du système de référence,

  • comprendre le fonctionnement du système de référence, en considérant le modèle comme une réplique miniature, qui pourra être étudiée plus facilement,

  • prévoir les évolutions possibles du système de référence en fonction d’évolutions ou de perturbations spécifiques,

  • reproduire artificiellement le fonctionnement d’un système,

  • valider ou d’invalider des hypothèses, 

  • obtenir des informations quantitatives,

  • valider certaines approximations, 

  • évaluer la sensibilité d’un modèle à certaines hypothèses ou à certains paramètres,

  • explorer le comportement d’un système lorsque celui-ci est mal connu ou incompris.

 

 

BPSim

Le WfMC (Workflow Management Coalition) a réalisé la norme BPSim. 
Il définit une spécification pour le paramétrage et l'échange de données d'analyse de processus permettant l'analyse structurelle d'un modèle de processus, permettant l'optimisation de la pré-exécution et de la post-exécution.

BPSim se compose d'un métamodèle et d'un format d'échange pour faciliter la sauvegarde et le transfert de ces données entre différents outils.
Le métamodèle BPSim est réalisé en UML et le format d’échange en XSD.

 

 

Exemple pratique de simulation d’un processus BPMN avec l’outil Enterprise Architect

Environnement prérequis


JRE/JDK Java 8 (version supérieure non testée).
Enterprise Architect (EA) 15.2 (version d’évaluation Ultimate) Sparx Systems

 

 

Modèle BPMN utilisé dans notre illustration de simulation

Conception du modèle BPMN dans EA

Le but est d’illustrer concrètement une simulation BPSim, le modèle BPMN inclut les éléments les plus utilisés sous forme générique.

Comme nous l’avons vu en théorie, on doit relier le simulateur externe au modèle.

Avec EA, il  suffit que le modèle BPMN et l'artefact "Business Process Simulation" de la toolbox se trouve dans un même package. Ainsi à l'exécution de cet artefact correspondant au simulateur, EA trouvera automatiquement le modèle BPMN. 

 

1) Créer un nouveau projet, par exemple “bpsim-simulation-bpmn.eapx”.

 

2) Puis, dans le “root node Model ”, créer un package (clic droit Add View, Package Only), par exemple “BPSim-Simulation-BPMN”.

 

3) Dans ce package, clic droit, Add Diagram, Type : BPMN, BPMN 2.0, Diagram Types : Collaboration.

Au message, sélectionner “Create this Diagram within a new Collaboration Model”, conserver le nom par défaut.

 

Pour cette démonstration, nous prendrons un modèle BPMN générique, comportant 2 pools (P1 et P2), envoi et réception de messages entre les 2, et à l’intérieur de chacun, des séquences d’activités avec des gateways, ce qui peut déjà correspondre à bons nombres de cas réels :

 

modele-bpmn-utilise-pour-la-simulation-bpsim

 

 

Illustration pratique de la simulation

Objectifs

Pour cette illustration BPSim, nous prendrons un entier n, initialisé à 10 au début et qui sera modifié par les activités en ajoutant des valeurs constantes.

 

Les branches des gateways exclusives seront des conditions selon que n soit supérieur ou égal ou bien strictement inférieur à une valeur donnée.
Pour visualiser le chemin parcouru et les activités traversées, nous initialisons le simulateur avec un contrôle de type TriggerCount.
Le TriggerCount définit le nombre de fois que l'objet ou le connecteur doit être traité pendant une exécution de la simulation, de sorte que le cycle de traitement correspond à la demande type pour une chaîne d'actions particulière.

Il est généralement défini pour les éléments Start Event.
Ce TriggerCount définit le nombre de fois que l'élément ou le connecteur doit être traité dans une simulation normale ou personnalisée.

La matérialisation des artefacts activés par la simulation se fait par l’affichage en rouge de la valeur du TriggerCount sur chaque élément traversé. 

 

Création du simulateur BPSim

On a vu précédemment qu'il faut ajouter l'artefact "Business Process Simulation".

 

Sélectionner le package “BPSim-Simulation-BPMN” > Toolbox > Artifacts > Drag & Drop de "Business Process Simulation" dans le package, laisser le nom par défaut > double cliquer dessus pour ouvrir la fenêtre “Configure BPSim”

 

business-process-simulation-fenetre

 

 

L’onglet “Configure” est sélectionné, laisser les valeurs par défaut. 


Ces valeurs représentent :

  • la date de démarrage,
  • la durée qui doit être supérieure à la durée estimée, ici 999 Days, 
  • l’unité de temps (ici minute),
  • le nombre de réplications (1), 
  • la valeur d’initialisation du générateur aléatoire (n’est pas utilisé ici),
  • le langage d’expression (XPath) pour analyser le XML représentant textuellement le modèle BPMN grâce à la norme XMI,
  • les répertoires d’installation de Java 8 (JRE/JDK),
  • le port de communication du simulateur (1799), attention à que ce port ne soit pas déjà occupé.
  • un timestamp.

 

Paramétrage des éléments de modélisation

Dans le pool P1

1) Sélectionner Debut1 > Configure BPSim > onglet Configure > Category > sélectionner Control > dans la colonne à coté Parameter, sélectionner TriggerCount > et enfin dans la colonne Values, saisir 1

 

configuration-debut1-TriggerCount

 

2) Ajouter une propriété n de type entier (int)

Cliquer sur l'icône "Properties" > New Property, saisir n, puis dans Type, sélectionner int

 

configure-bpsim-configure-propriete

 

3) Sélectionner Debut1 > Configure BPSim > onglet Configure >

Category > en dessous de Control, New Parameter, sélectionner Property > n > pour la valeur, cliquer sur le bouton … à droite,  saisir 10 dans Expression

 

configuration-debut1-property-n

 

 

4) De la même manière, sélectionner Activite1 et compléter les 3 colonnes :
Property > n > Values > …. > Expression {n} + 100

 

5) Sélectionner le sequence flow de Passerelle1 à Fin1 
Control > Condition > Values > …. > Expression {n} >= 50

 

6) Sélectionner le sequence flow de Passerelle1 à Fin2 
Control > Condition > Values > …. > Expression {n} < 50

 

Dans le pool P2

7) Sélectionner Activite2 :
Property > n > Values > …. > Expression {n} + 10

 

8) Sélectionner le séquence flow de Passerelle2 à Activite3 
Control > Condition > Values > …. > Expression {n} >= 15

 

9) Sélectionner le séquence flow de Passerelle2 à Activite4 
Control > Condition > Values > …. > Expression {n} < 15

 

10) Sélectionner Activite3 :
Property > n > Values > …. > Expression {n} + 10

 

11) Sélectionner Activite4 :
Property > n > Values > …. > Expression {n} + 1

 

Sauvegarde de la configuration

Cliquer sur l’icône disquette.

 

Pour vérification, cliquer sur l’icône Property (point bleu), vous devez obtenir toutes les propriétés et les conditions appliquées sur les différents éléments du modèle BPMN :

 

fenetre-proprietes-et-conditions-de-la-simulation-bpsim

 

 

Exécution de la simulation BPSim

Dans la partie “Configure BPSim”, sélectionner l’onglet Execute, puis la première icône en dessous à gauche (Run Simulation)

 

 

execution-de-la-simulation-bpsim-du-modele-bpmn

 

Une fois la simulation terminée, vous pouvez arrêter l'affichage, en cliquant sur l'icône représentant un carré (Stop). L'affichage des "TriggerCount" disparaît.

 

Explication :

 

EA indique les éléments activés, accompagnés d’un "1" rouge (TriggerCount 1) et en sombre les autres.

 

Si l'on vérifie manuellement :

  1. P1
  2. n = 10 on envoie n dans P2
  3. Activite1 n = 10 + 100 = 110
  4. P2 reçoit n = 10
  5. Activite2 n = 10 + 10 = 20
  6. Comme n >= 15, on arrive dans Activite3 : n = 20 + 10 = 30
  7. On envoie n dans P1
  8. P1 reçoit n = 30
  9. Comme n < 50, on termine dans Fin2.

 

Exécution pas à pas de la simulation

 

Pour suivre pas à pas l'exécution de la simulation à des fins par exemple de mise au point, il suffit de sélectionner l'onglet Step, pour trouver les boutons de démarrage, d'avancement, de pause et d'arrêt.

 

On peut aussi (3 ème icône en partant de la droite), générer un diagramme de timing et juste à coté, celle pour générer un fichier CSV.

 

A noter que l'onglet Review permet de générer des rapports.

 

 

execution-pas-a-pas-de-la-simulation-bpsim-du-modele-bpmn

 

Validation du modèle BPMN

A côté de la disquette, on peut cliquer sur l’icône de validation, ce qui ouvre un nouvel onglet “System Output”

 

validation-de-la-simulation-bpsim-et-du-modele-bpmn

 

Conclusion

Le simulateur BPSim d’Enterprise Architect nous a permis de voir concrètement une exécution d’un modèle auquel on a associé aux éléments des propriétés, instructions et conditions.

Bien sûr, le simulateur d’EA possède de nombreuses distributions de probabilités (Binomial, Erlang, Gamma, Normal, Poisson, TruncatedNormal, Uniform…) permettant d’avoir des scénarios proches de la réalité.Les ressources, rôles (acteurs), peuvent être associées à des minis-écrans interactifs. 

Enfin, des calendriers permettent de planifier et gérer les durées et le déclenchement des activités pour plus de réalisme.


Le simulateur supporte aussi la norme DMN (Decision Model and Notation) pour la modélisation des règles métier.

Et pour être complet, on pourrait simuler un processus BPMN avec des tâches de type “Business Rule” qui seraient par exemple un modèle DMN avec des tables de décision et des règles de calculs.

 

N’hésitez pas à partager votre expérience sur le sujet de la simulation BPMN et à nous dire quels outils vous utilisez en postant un commentaire à la fin de cet article.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 


Il dit non avec la tête
mais il dit oui avec le cœur

et malgré les menaces du maître
sous les huées des enfants prodiges
avec les craies de toutes les couleurs
sur le tableau noir du malheur
il dessine le visage du bonheur.

 "Le cancre", Jacques Prévert

 

 

Pour en savoir plus sur 

BPMN

BPMN 2 : les concepts de base des processus métiers

 

BPMN pour les nuls : les collaborations

 

BPMN : l'antisèche pour rester incollable en modélisation de processus

 

BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

 

BPMN

 

 

DMN

DMN - L'antisèche de la notation complète des composants d'un DRD (Decision Requirement Diagram) : notation de la décision

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions

 

DMN

 


01/12/2022
0 Poster un commentaire

Méta-physique ? Non, méta-modélisation !

La sortie récente de la version 5 du Camunda Modeler, permettant de modéliser les processus métier avec la notation BPMN, nous donne l’occasion de faire un rappel sur la notion de méta-modèle, qui se cache souvent derrière le modèle.

 

four-russian-dolls

 

Un méta-modèle pour quoi faire ?

 

3U

 

Les 3U pour la Modélisation, l’Exécution et le Pilotage d’un processus métier

 

  • Un modèle est Utile.
    Si vous n’en êtes pas convaincu, alors vous ne butinez pas sur le bon site ! Car la mise en œuvre de l’Urbanisation du Système d’Information et de l’Architecture d’Entreprise avec méthode, pour une entreprise agile et résiliente, prônée par urbanisation-si.com, est basée sur la modélisation.

 

  • Un modèle doit être Utilisable.
    C’est cet aspect d’un modèle qui est détaillé plus bas dans cet article et qui s’appuie, selon nous, sur la normalisation grâce à un méta-modèle. Et cela permet de passer éventuellement de la modélisation statique à la modélisation dynamique.

 

  • Un modèle est-il Utilisé ?
    Un modèle de processus métier peut être directement utilisé avec la plate-forme adéquate. Souvent, il est toutefois nécessaire d’ajouter quelques artefacts, comme des formulaires de saisie.
    Utiliser un modèle reste la manière la plus efficace de s’assurer que la pratique du processus métier correspond à la théorie. Le modèle de processus est alors indissociable de la réalité. Le processus métier va pouvoir être piloté.
    Un dispositif optionnel comme le BAM – Business Activity Monitoring – permet de compter le nombre d’instances d’un processus métier (combien sont terminés, combien sont en cours, combien sont en erreur, etc.) et de mesurer leurs durées.

 

 

Utilisabilité d’un modèle

 

Intéressons nous plus particulièrement ici à l’utilisabilité d’un modèle. L’utilisation d’un langage ou une notation de modélisation normalisée facilite la réalisation, le partage, la compréhension d’un modèle. Ceci est particulièrement vrai avec la notation BPMN, qui permet notamment aux analystes métier et aux informaticiens de partager des modèles de processus métier et permet même directement leur exécution grâce à un BPMS.

 

Pyramide de modélisation

 

Concernant les langages et les notations de modélisation, la normalisation ne s’appuie pas seulement sur la publication de spécifications détaillées, pour diffuser et partager les éléments de représentation : elle repose également sur un système pyramidal complexe, mais cohérent, de (méta) modélisation.

 

PyramideModélisation

 

La pyramide de modélisation de l’OMG

 

La largeur de chaque niveau est proportionnelle à son nombre d’occurrences. En fait, le nombre d’occurrences se réduit de façon drastique quand le niveau augmente.

 

Niveau M0 : C’est le monde réel (ou imaginé), constitué d’instances qui doivent être représentées par le modèle de niveau 1. Si l’on veut représenter les êtres humains, cela fera plus de 7 milliards d’instances.

 

Niveau M1 : C’est le modèle que nous connaissons tous. Ce modèle représente généralement une partie du monde réel, par exemple, un diagramme de collaboration BPMN qui représente un processus métier. Ce modèle peut également représenter un système qui n’existe pas encore). Il existe sans doute dans le monde entier des centaines de milliers de modèles.

 

Niveau M2 : Le méta-modèle est beaucoup moins connu. Les modèles utilisant un langage ou une notation normalisée respectent généralement un méta-modèle. Tous les langages et notations de l’OMG – Object Management Group – notamment sont fournis avec un méta-modèle. Par exemple, celui de la notation BPMN. Ce méta-modèle est surtout utilisé par les éditeurs de logiciel. Il existe plusieurs dizaines de méta-modèles.

 

Niveau M3 : Le méta-méta-modèle est encore moins connu. Il fixe les règles de représentation des méta-modèles. Il existe très peu de méta-méta-modèles : je n’en connais que deux Ecore et MOF.

 

Pas de niveau M4 : A nos lecteurs qui seraient taraudés par l’idée qu’un méta-méta-méta-modèle (oui, je compte le nombre de « méta » sur mes doigts) serait sans doute nécessaire pour fixer les règles de représentation des méta-méta-modèles, soyez rassurés ! En effet, les méta-méta-modèles possèdent une caractéristique appelée méta-circularité, qui leur permet de se définir eux-mêmes. « Seulement » 4 niveaux numérotés de 0 à 3, donc.

 

Pas de méta-modèles dans les applications de dessin

 

Vous pouvez réaliser un diagramme de collaboration BPMN avec l’application Microsoft PowerPoint (vous trouverez quelques formes simples dans la section Organigrammes), mais vous serez rarement certain que votre modèle BPMN est conforme au méta-modèle. En effet, PowerPoint est, pour la partie graphique, une simple application de dessin qui vous permet d’agencer puis de relier les symboles BPMN n’importe comment. Parmi les applications Microsoft, il vaudra mieux utiliser Visio Professionnel pour réaliser des diagrammes BPMN sérieux, car validés par le méta-modèle BPMN.

 

Utilisation du méta-modèle

 

Les vraies applications de modélisation utilisent le méta-modèle de deux façons différentes :

 

  • En temps réel, pour déduire automatiquement la nature de certains éléments de modélisation. Ainsi, avec un outil de modélisation BPMN, quand on relie deux tâches, la connexion se fera automatiquement avec un flux de séquence (trait plein) si ces deux tâches sont dans le même pool ou bien avec un flux de message (trait pointillé), si ces deux tâches sont dans deux pools différents,

 

  • A postériori, pour valider le modèle avec le méta-modèle. La plupart des outils de modélisation BPMN disposent d’une fonction de validation du modèle et il est fortement conseillé de l’utiliser, afin de ne partager que des modèles valides, ce qui contribue grandement à la compréhension et à la diffusion d’un langage ou d’une notation normalisée.

 

Bonnes pratiques

 

Certains outils vont plus loin que la validation avec le méta-modèle. Signavio Process Manager par exemple peut vérifier également si les bonnes pratiques sont bien appliquées, en l’occurrence celles définies dans le livre de référence de Bruce Silver : BPMN method and style: with BPMN implementer’s guide (2. edition), Cody-Cassidy Press (2011).

 

Le sens critique des utilisateurs humains est toutefois toujours nécessaire pour peaufiner la modélisation. Par exemple, il est recommandé que chaque tâche soit renseignée avec un verbe d’action, suivi d’un complément d’objet direct (Exemple : Préparer commande). Le validateur contrôle que chaque tâche est renseignée (c.-à-d. non vide), mais n’effectue pas une analyse syntaxique du contenu.

 

Validation BPMN avec Camunda Modeler

 

Camunda Modeler, outil gratuit et largement utilisé, dont nous apprécions la facilité d’installation, même quand on ne dispose pas des droits Administrateur sur son PC, ne dispose pourtant pas d’une fonction de validation. Les utilisateurs motivés pourront remédier à cette lacune en installant le module d’extension Linter.

 

Il convient, en plus du Camunda Modeler, d’installer git et node.js, puis à partir du sous-répertoire ..\camunda-modeler\resources\plugins\, de lancer la commande suivante pour installer ce module :

npx degit github:camunda/camunda-modeler-linter-plugin camunda-modeler-linter-plugin

 

Dans le menu Plugins de Camunda Modeler, il suffit d’activer BPMN Linter qui effectue la validation en temps réel. Les erreurs les plus courantes sont alors aussitôt signalées et affichées directement sur l’élément concerné. Mais il est parfois préférable d’attendre la fin de la modélisation (on peut désactiver provisoirement BPMN Linter).

 

BPMN_KO

 

BPMN_OK

Diagramme de collaboration BPMN réalisé avec Camunda Modeler et le plugin Linter

 

Conclusion

 

Ce principe général de méta-modélisation, illustré dans cet article avec la notation BPMN, s’applique à d’autres notations et langages, notamment UML. Pour passer facilement de la théorie à la pratique, il suffit d’avoir un outil de modélisation adapté, qui va masquer la complexité du méta-modèle, grâce à sa fonction de validation des diagrammes notamment.

 

Thierry BIARD

 

“Il importe en peinture, que le portrait ressemble au modèle, mais non pas le modèle au portrait.” (Paul-Jean Toulet)
(Note de Thierry Biard : Il est amusant de noter qu’en peinture, sculpture et photographie, le modèle est le personnage du monde réel lui-même et non sa représentation – le portrait)

 

Compléments de lecture

MOF - ECORE - MDA

Métamodèle TOGAF - ArchiMate

Application des métamodèles

Les critères d'un bon modèle

   


01/06/2022
0 Poster un commentaire

Le PILI était-il un bon modèle ?

En fin d’année 2021, la RATP a mis en vente aux enchères du mobilier réformé, au profit d’une œuvre caritative (belle initiative). Parmi les 215 lots mis en vente figuraient quatre PILI :

Panneaux Indicateurs Lumineux d’Itinéraires.

Rien à voir avec la sauce piquante à base de piment pour relever le goût de votre pizza, donc.

 

image003

 

Lorsque j’étais enfant, j’aimais beaucoup appuyer sur l’un des 300 boutons chromés, un pour chaque station de métro de destination, afin d’allumer l’itinéraire le plus direct pour s’y rendre (à partir de la station où je me trouvais) :

 

image004

 

Positionnées sur le plan du métropolitain parisien, plus de 300 ampoules et, derrière ce plan, sans doute plusieurs kilomètres de câble électrique !

 

Après l'évocation de ce bon souvenir, empreint de nostalgie, la déformation professionnelle a rapidement repris le dessus :

Le PILI était-il un bon modèle ?

Voici une définition concise : un bon modèle doit représenter au mieux une partie du monde réel.
Sur quels critères plus précis peut-on s'appuyer pour déterminer un bon modèle ?

 

En 2017, j’avais publié une liste de 7 critères établie par Mader et al. 2007 pour qualifier un bon modèle :

 

- Il a un objet de modélisation clairement spécifié :

Oui, modéliser le réseau du métropolitain parisien.


- Il a un objectif clairement spécifié :

Oui, afficher l'itinéraire le plus rapide pour se rendre d'une station à une autre.


- Il est simple (le critère le plus difficile ?) :

Oui, pas besoin de mode d'emploi. Un seul "clic" sur le bouton de la station de destination suffit.

 

- Il est véridique :

Oui, la réalité du terrain est bien représentée.

(les ampoules pour représenter les différentes correspondances d'une seule station sont toutefois décalées. Exemple ci-dessus : Châtelet Les Halles)


- Il est traçable :
Oui, mais ce critère n'est pas primordial ici (peu d'évolutions du réseau)


- Il est extensible et réutilisable :

Non, le PILI n'était pas extensible : difficile d'ajouter une nouvelle station, voire une nouvelle ligne.

Par contre, il était réutilisable : près de 200 PILI furent déployés (soit dans 2 stations de métro sur 3)

 

- Il est conçu pour l’interopérabilité et le partage :

Non pour l'interopérabilité : pas d’actualisation possible pour signaler un incident ou une station fermée

Oui pour le partage : les PILI connurent un grand succès populaire, sans doute grâce à leur simplicité.

 

Les PILI obtiennent une note de 6/7 avec cette liste de critères ! Belle performance. 

 

Les PILI possédaient d'autres propriétés :

  • Maintenance très délicate en cas de panne,

mais malgré cet inconvénient, apparemment gérable :

  • Longévité exceptionnelle, de 1937 à 2016 approx.
    (sans doute liée à la stabilité du réseau)

 

Qui d'autre conçoit des modèles compris par les utilisateurs finaux
et utilisés pendant presque 80 ans ?image002

Panneau métropolitain de style Guimard

 

Il y a quelques années, la RATP avait repris le principe du panneau interactif sur son site web : le plan complet du réseau s’affichait et il suffisait de poser le pointeur de sa souris sur une ligne pour que leurs autres lignes s’estompent aussitôt.

 

Aujourd’hui, ce plan complet est complètement statique... Et chaque ligne (avec ses stations et ses correspondances) s’affiche désespérément à l’horizontale, sans rapport avec la réalité du terrain :

 

Plan metro ligne 4, agrandir le plan

La réponse est donc oui, le PILI était un bon modèle

Sans aucun doute meilleur que le modèle actuel publié sur le site web.

 

 

Malgré leurs caractéristiques impressionnantes (hauteur : 160 cm ; largeur 185 cm ; poids : 120 kg) nécessitant un grand salon, ces quatre PILI - sans aucune garantie de bon fonctionnement - ont tous trouvé acquéreurs à des prix compris entre 2.650 et 2.850 € ! Le prix qu’une très grande TV 4K UHD.

 

L’un des rares inconvénients du PILI, présenté dans le post ci-dessus, était son manque d’interopérabilité : pas d’actualisation possible pour signaler un incident ou une station fermée. Cet inconvénient a disparu grâce aux sites web, aux applications mobiles et aux réseaux sociaux : il est possible désormais d’actualiser rapidement les informations auprès des usagers (info trafic). Mais cette possibilité ne conduirait-elle pas vers certains excès ? Voici un exemple, réel et extrême.

 

Le 21 septembre 2022, des travaux sur la ligne D du RER ont entrainé la fermeture de 8 stations. Une douzaine de bus, voire le RER C, étaient proposés pour se substituer au RER D. Voici le plan avec les itinéraires de substitution qui ont été proposés aux usagers sur le réseau social Twitter :

  

PILI-vs-application-mobile

 

Plusieurs qualificatifs, la plupart flatteurs, peuvent s’appliquer à ce plan : spectaculaire, coloré, exhaustif, détaillé, précis, voire extravagant, limite usine à gaz, non ?

 

Par contre, euh, comment dirais-je : il valait mieux ne pas avoir à se déplacer en transport en commun à ce moment-là ! Un indice pour tenter de vous y retrouver : la légende est incomplète ; un fin trait noir semble relier une seule et même station de bus. C’est d’ailleurs étonnant que les représentations des lignes de bus 401 et 402 soient scindées en trois tronçons. En fin connaisseur du protocole de communication HTTP, j’aurais personnellement évité la ligne de bus 404, de peur de ne pas arriver à destination 😉

 

Pour reprendre le refrain à la mode actuellement, il convient (parfois) de privilégier la marche ou le vélo !

 

 

urbanisation-si_logo

 

Thierry Biard

urbanisation-si.com

 

 

« L’artiste imprime à son œuvre un sceau de personnalité alors que l’ingénieur est amené à se considérer comme l’artisan d’une œuvre impersonnelle. »

Fulgence Bienvenüe (1852-1936), père du Métropolitain

 


18/02/2022
0 Poster un commentaire

Modélisation métier : méthode des processus métier orientés objectifs

modelisation-metier-diagramme-ishikawa.png

 

La méthode des processus métier orientés objectifs ( http://urbanisation-si.eklablog.com ) utilise les concepts du diagramme d’Ishikawa (plus connu sous le nom de diagramme d’arrêtes de poisson ou encore diagramme de cause à effet) qui consiste à identifier l’objectif final puis les sous-objectifs permettant de l’atteindre et ainsi de suite de manière récursive. 

Ne subissez plus les changements extérieurs, mais soyez en mesure de les accueillir à tout instant !

Les plus performants d’entre nous sont conscients du fait qu'avantage concurrentiel et service de premier ordre ne résultent pas de ce qu’on fait, mais de la manière de le faire. Et que les positions de force peuvent s’inverser rapidement du fait de l’évolution constante des environnements financier, réglementaire et métier. Le BPM (Business Process Management) permet une amélioration notable du retour sur investissement. Parmi les sociétés qui ont mis en œuvre des solutions de BPM :

• 100 % ont amélioré leur productivité,

• 95 % ont amélioré la qualité de leur service,

• 82 % ont réduit leurs coûts d’exploitation,

• 82 % ont réduit la durée de leurs cycles de traitement.

Le climat opérationnel actuel est très imprévisible. Les entreprises se préparent pour un type de situation, et c’est une autre qui se présente. Le coût de cette préparation (ou de l’absence de préparation) à des situations difficiles peut être extrêmement élevé. Une solution consiste à adopter la gestion des processus métier orientée objectifs permettant par la mise en œuvre d’une méthodologie efficace et de la technologie associée d’offrir aux entreprises toute la souplesse requise pour s’adapter aux environnements fonctionnels imprévisibles. Elle apporte d’énormes avantages, notamment :

• création plus rapide et à moindre frais des processus via la réutilisation des composants,

• implication des utilisateurs fonctionnels dans la conception des processus,

• contexte plus favorable pour le contrôle des processus,

• souplesse permettant de résoudre les problèmes au moment où ils se produisent, plutôt qu’après,

• possibilité d’adaptation dynamique aux nouvelles conditions de fonctionnement.

La méthode des processus métier orientés objectifs utilise les concepts du diagramme d’Ishikawa (plus connu sous le nom de diagramme d’arrêtes de poisson ou encore diagramme d’objectifs/sous-objectifs) qui consiste à identifier l’objectif final puis les sous-objectifs permettant de l’atteindre et ainsi de suite de manière récursive. A chaque sous-objectif va correspondre des composants de processus que l’on pourra réutiliser à la manière de composants objets ou de services dans SOA (Service Oriented Architecture). On peut ainsi réorchestrer le processus en appliquant des règles exécutées par un moteur. Les composants peuvent avoir des contraintes d’ordonnancement comme des tâches dans un projet classique ainsi que des durées maximales d’exécution.

Cette agilité suprême existe et n’est pas de la science-fiction mais pour réussir le projet et parvenir au retour sur investissement escompté encore faut-il une réelle implication de la direction capable de mobiliser et de fédérer tous les acteurs du SI.

 

"On ne possède jamais réellement les choses. On ne fait que les tenir un instant. Si l’on est incapable de les laisser aller, ce sont elles qui nous possèdent."
Antony de Mello

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


17/09/2015
0 Poster un commentaire

Modélisation métier : outils mindmap, mon préféré

outil-mindmap-freeplane-fonctions-2.jpg

 

On a vu dans l'article précédent : 

https://www.urbanisation-si.com/modelisation-metier-mindmap-ne-vous-perdez-plus-dans-votre-cheminement-de-pensee-mettez-de-l-ordre-dans-vos-idees

l'intérêt à utiliser les cartes mentales ( mindmap ) pour organiser, comprendre et mémoriser des concepts complexes et nouveaux. C'est généralement ce qu'on doit faire en ingénierie des exigences ou l'on doit modéliser les processus métier et identifier les besoins en adéquation avec la stratégie de l'entreprise.

C'est bien beau de faire des mindmap avec des crayons de couleur et une gomme mais c'est quand même mieux d'utiliser un outil informatique.

Parmi les outils open source gratuits, j'en ai retenu 3 :

Historiquement le 1er outil digne de ce nom a été FreeMind qui a imposé son format repris par l'ensemble des outils concurrents. L'outil est intuitif, ergonomique, on peut directement concevoir des mindmap sans lire de documentations rébarbatives.

Un fork, c'est à dire un groupe de développeurs de FreeMind est parti pour créer un concurrent XMind. Des fonctionnalités nouvelles ont été apportées et l'environnement a été légèrement relooké. Je trouve cependant que les 2 produits se ressemblent comme 2 frères jumeaux. Si vous tenez au standard autant prendre l'original, le vrai, l'unique FreeMind.

Je gardais le meilleur pour la fin, car ma préférence va à Freeplane. L'outil est 100 % compatible FreeMind, mais son ergonomie est nettement plus moderne. Il utilise tous les widgets tendances que l'on retrouvent dans l'ensemble des "clicodromes". La prise en main est immédiate.

Nous verrons prochainement différents métamodèles de mindmap glanés de ci de la sur internet pour pouvoir les transformer vers d'autres métamodèle comme KAOS, SysML, UML, ... 

 

"La vie est un défi à relever, un bonheur à mériter, une aventure à tenter."
Mère Teresa

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


08/09/2015
0 Poster un commentaire

Modélisation métier : Mindmap, ne vous perdez plus dans votre cheminement de pensée, mettez de l'ordre dans vos idées !

urbanisation-si-mindmap-definition-interet-1.png

 

Une des difficultés majeures de l'ingénierie logicielle est de comprendre les processus métier qui constituent le milieu dans lequel vont évoluer les futurs systèmes et de capturer les besoins des utilisateurs.

Le gouffre entre les métiers et les techniciens entraîne des incompréhensions de part et d'autre et donc de potentiels dysfonctionnements ou un mauvais alignement sur les exigences.

Il existe une technique éprouvée lisible par l'ensemble des protagonistes d'un projet, permettant d'organiser de nombreux concepts complexes : les Mind Map.  

Les Mind Map sont considérés, tant par le monde académique que par le monde industriel, comme de puissants outils pour l’élicitation des exigences.

L’ingénierie des exigences est reconnue comme un processus social qui se caractérise par des prises de décisions permanentes entre de nombreux participants (gestionnaires, utilisateurs finaux, et analystes du système).

Lors de la phase de recueil des exigences, le développement logiciel est plus un travail artisanal qu’une réelle discipline d’ingénierie. À cet égard, la cognitive humaine joue un rôle essentiel pour la compréhension des problèmes humains et organisationnels dans l’ingénierie des exigences, et sert à identifier les moyens d’amélioration de la qualité de la perception visuelle du modèle de spécification produit

Une Mind Map, encore appelée topogramme, schéma heuristique ou carte mentaleest un diagramme utilisé pour voir, classifier et organiser des concepts, ainsi que pour générer de nouvelles idées. Elle est utilisée pour connecter des mots, des idées et des concepts à une idée ou un concept central. Elle est similaire à un réseau sémantique ou à une carte cognitive, mais sans les restrictions sur les types de connections utilisées.

Toutes les Mind Map sont articulées autour d'un noyau central, elles mettent en œuvre des lignes, des symboles, des mots, des couleurs et des images illustrant des concepts simples et faciles à mémoriser. L'élaboration d'une Mind Map permet de transformer une longue liste de données rébarbatives en un diagramme attrayant, coloré, logique et hautement structuré, en harmonie avec le fonctionnement naturel du cerveau.

Une Mind Map est un diagramme radial qui, à l’aide d’un vocabulaire (c’est à dire d’un ensemble de mots-clés), peut représenter et modéliser de manière cognitive un concept ou un domaine spécifique.

Les principaux bénéfices de l’utilisation de ce type de représentation sont :

  • organisation des idées et des concepts,
  • mise en accent de mots significatifs,
  • association entre éléments d’une branche,
  • regroupement d’idées,
  • support à la mémoire visuelle et à la créativité,
  • déclenchement d’innovations.
  • rend plus facile pour l’esprit humain le traitement de l’information, tout en réduisant la charge cognitive nécessaire pour absorber les concepts du domaine et leurs objectifs.

La Mind Map constitue un miroir externe de votre propre réflexion naturelle, facilitée par un processus graphique puissant, lequel fournit une clé universelle permettant de débrider le plein potentiel du cerveau humain.

Les cinq caractéristiques essentielles d'une Mind Map sont les suivantes:

  • Le sujet ou thème de la Mind Map est symbolisé par une image centrale.
  • Les idées ou rubriques principales sont disposées autour de l'image centrale sous forme de branches.
  • Chaque branche s'accompagne d'une image-clé ou d'une expression-clé dessinée ou imprimée sur la ligne qui lui est associée.
  • Les idées périphériques sont représentées en tant que "rameaux" de la branche connexe.
  • L'ensemble des branches forme un arbre dont les nœuds sont liés les uns aux autres.

 

"L'homme sans patience, c'est comme une lampe sans huile."

Alfred De Musset

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


07/09/2015
0 Poster un commentaire

Modélisation de système : quand un analyste fonctionnel parle chinois avec un développeur

modelisation-metier-diagramme-etat-uml-dialogue-sourd.png

J'ai surpris un jour cette conversation téléphonique entre un analyste fonctionnel et un développeur.

Il essayait en vain de lui expliquer ce qui arrivait quand on annulait une annulation.

Tout le monde était plié de rire tellement cela devenait un dialogue surréaliste.

Du pure Devos ! Il était impossible de conserver le fil de pensée tellement les phrases étaient longues, pire que du Proust !

Cela ressemblait a peu près à ceci : "quand tu annules une annulation d'une ligne d'un dossier fermé, la ligne se réactive et peut passer dans l'état à traiter si avant d'avoir été annulée elle était calculée, mais si elle était révisée et si le batch est passé alors elle repasse à "à réviser" et sinon à "à payer" à moins que le gestionnaire ait demandé le calcul manuel, à ce moment là il faut demander la validation auprès du responsable de la gestion à moins qu'elle ait été bloqué et qu'on a forcé le calcul, ... , il ne faut oublier bien sur de ré-ouvrir le dossier ...

N'importe qui aurait perdu le fil au bout de la 2 ème ou 3 ème condition. Les capacités cognitives de l'esprit humain sont limités, d'autant plus si les règles sont énoncés par téléphone.

Comment une telle situation est-elle apparue ?

Par manque d'un langage formel de modélisation commun à tous les acteurs du projet, une sorte d'espéranto.

En l'occurrence ici, aucun diagramme d'état UML n'avait été réalisé.

Dans les spécifications Word, on avait certes la liste des états, dans certaines présentations Powerpoint quand on réussissait à mettre la main dessus, figuraient certaines transitions possibles mais sans les événements déclenchant les transitions donc inutilisables et en plus toujours incomplètes sur le plan des scénarios.

Un diagramme d'état permet pour une entité, de montrer toutes les transitions possibles entre ses états métiers, quels sont les événements produisant ces changements d'état et qu'elle est son comportement dans un état donné.

Cela n'a rien à voir avec un ésotérisme technique. Tout ce que représente le diagramme d'état relève bien du métier. 

Imposer l'utilisation d'un tel outil permet de se donner un cadre de pensée commun, de ne rien oublier et d'avoir sur un schéma (qui vaut mieux qu'un long discours, surtout au téléphone !) l'exhaustivité des transitions d'états avec leurs événements déclencheurs.

Le développeur aura alors un automate à états finis avec l'ensemble des règles sans aucune ambiguïté.

L'urbanisme du SI doit imposer entre autre que les transitions d'états complexes soient obligatoirement modélisées avec un diagramme d'état UML sans quoi on laisse la porte ouverte à l'imagination de chacun et la on peut s'attendre à tout !

 

"La règle d'or de la conduite est la tolérance mutuelle, car nous ne penserons jamais tous de la même façon, nous ne verrons qu'une partie de la vérité et sous des angles différents."
Gandhi

 

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


09/07/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package

 

blog-modelisation-uml-pack.gif

 

 

Détails Domaines métiers – UML – Diag. Package

blog-modelisation-uml-pack2.gif

 

L'urbanisme des Systèmes d'Information impose d'organiser la vue fonctionnelle en blocs autonomes communiquant par messages. Une zone avec un quartier spécifique pour les données à cycle de vie court (comme des prestations d'assurance) et un quartier référentiel de données pour celles à cycle de vie long (des produits commercialisés), doit être représentée dans le Plan d'Occupation des Sols (POS).du SI.

Si on zoom sur ces 2 quartiers, on obtient des diagrammes de classes modélisant les entités métiers (voir l'article sur le modèle métier dans la méthode ultime de modélisation des besoins). Ces entités métiers sont regroupées par appartenance à des domaines fonctionnels (référentiel Individus, référentiel contrats, domaine prestation, cotisation, ...). En UML on représente ces domaines métier par des packages.

Les packages peuvent contenir n'importe quels éléments UML (acteurs, cas d'utilisation, classes, ...) et il appartient au modélisateur de leur donner une sémantique. En modélisation métier ce sont bien sur les domaines fonctionnels et en conception ce sont les packages de compilation et d'exécution.

A part rassembler des entités d'un même domaine fonctionnel, le diagramme de package permet de représenter les dépendances.

Par exemple, le domaine contrat dépendra du domaine produits, le domaine prestation dépendra du domaine contrat, ...

Cette vue offre la possibilité aux experts métiers de vérifier les dépendances entre les domaines fonctionnels. Par exemple les référentiels constituent des socles, ils ne peuvent pas dépendre de domaines fonctionnels qui ne soient pas référentiels..

Ce modèle peut aussi faire apparaître les dépendances  bidirectionnelles ou cycliques (A dépend de  B ; B dépend de C et C dépend de A). Il faudra alors déplacer les entités ambigües situées aux frontières des domaines pour diminuer le couplage. On constate souvent qu'une dépendance entre 2 domaines peut être uniquement la cause d'une relation entre 2 entités situées dans chaque domaine. Cela aurait peut être un sens métier de déplacer une de ces entités dans l'autre domaine ce qui aurait pour effet de supprimer complètement la dépendance entre les 2 packages. En pratique il y a des entités pour lesquelles dés le départ on hésite à les mettre dans tel ou tel domaine. La bonne pratique est donc de les mettre dans le package qui aura pour effet d'introduire le moins de dépendance possible et surtout de supprimer les bidirectionnelles ou les interdépendances.

Le diagramme de packages est donc l'outil de base du cartographe dans la démarche d'urbanisation. La notion d'échelle est donnée par la hiérarchie de packages, limitée par les règles d'urbanisme à 3 ou 4 niveaux. 

Les packages permettent aussi de regrouper les exigences en domaines fonctionnels c'est ce que nous verrons dans un prochain article.

 

"La connaissance s'élabore en détruisant une connaissance antérieure."

Gaston Bachelard

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


14/05/2015
0 Poster un commentaire