urbanisation-si.com

urbanisation-si.com

Modélisation métier


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.

 

Thierry Biard

 

« 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

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

blog-modelisation-uml-etat.gif

 

 

Détails Etats métiers – UML – Diag. Etats

blog-modelisation-uml-et2.gif

 

Dans une modélisation métier digne de ce nom, les processus métier sont cartographiés avec le profil Eriksson Penker puis on zoom avec un diagramme d'activité montrant la séquence des activités. Pour chaque activité, on peut spécifier les entités en entrée et en sortie et pour une même entité ses changements d'états. L'aspect évènement ou transition est mis en évidence. Grace à cette vue, on peut se poser la question quel doit être l'état d'une entité en entrée de l'activité et quel est son état en sortie.

UML permet d'avoir différentes vues d'un système. Le diagramme d'état est l'inverse du diagramme d'activité dans le sens ou ce sont cette fois les états qui sont mis en évidences par des rectangles et les évènements/transitions par des flèches.

Le diagramme d'activité permet d'identifier les évènements (acte de gestion par exemple) et le diagramme d'état, les états d'une entité métier qui peut être déjà identifiée dans un diagramme de classe.

La MOA/MOAD ou les experts métiers ne doivent pas avoir peur du diagramme d'état après tout ne font-ils pas ces même diagrammes avec Power Point. Ne sont-ils comme M. Jourdain qui faisait de la prose sans le savoir, mais eux ne feraient-ils pas de l'UML sans le savoir ?

 

"Ferme tes yeux de chair pour contempler d'abord ton image avec l’œil de l'esprit."

Auguste Rodin


14/05/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe

blog-modelisation-diag-clas.gif

 

 

Détails Domaine métier – UML – Diag. Classe

blog-modelisation-metier-2.gif

 

L'urbanisme des Systèmes d'Information (SI) édicte comme règle que la cartographie fonctionnelle comporte une zone données. L'objectif est 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 comme par exemple une "Personne" et de ne pas retenir à ce niveau tout ce qui est secondaire comme "Adresse".

L'outil UML correspondant pour cette modélisation est bien évidemment le diagramme de classe mais utilisé avec parcimonie. 

L'expert métier ou plus volontiers la maîtrise d'ouvrage déléguée (MOAD) ne doit représenter que les entités métiers (classes), les données (attributs) de ces entités, les relations (associations) et les cardinalités (multiplicités).

Et rien d'autres ! Tout les autres raffinements d'UML seront écartés et réservés aux étapes ultérieures plus techniques de la modélisation comme par exemple l'héritage en analyse et les méthodes en conception.

Attention toutefois à ce que ce formalisme ne soit pas rejeté par la MOA (cela ne concerne pas la MOAD qui par définition fait l'interface entre la MOA et la MOE et se doit d'être accompli dans l'art de la modélisation). Si dans le cadre d'urbanisme du SI ou d'un projet, les templates de modèles UML (modèle de modèle = méta-modèle), sont trop abstraits ou trop techniques, s'ils demandent trop d'effort, s'ils ne rentrent pas dans la culture de l'entreprise ou dans la politique de certains dirigeants qui confondent réussite personnelle et réussite du projet, on aura alors un risque non négligeable de rejet de la part des utilisateurs. 

Le piège est d'être trop technique. 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, ...).

Cette méthode avec les outils l'accompagnant doit être conçue et appliquée dès le départ du projet (d'urbanisation du SI ou applicatif), avoir obtenu l'adhésion de tous les acteurs et bien sur cela va sans dire le soutien de la direction générale qui doit montrer sa totale implication.

 

"Quand on aime la vie, on aime le passé, parce que c'est le présent tel qu'il a survécu dans la mémoire humaine."

Marguerite Yourcenar


13/05/2015
0 Poster un commentaire

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité

Rule Flow – UML – Diag. Activité

blog-modelisation-ruleflow-.gif

 

 

Détails du Rule Flow – UML – Diag. Activité

blog-modelisation-ruleflow.gif

 

Dans un précédent article, nous avons vu l'importance de modéliser de manière statique les règles métiers en utilisant les profils qu'offrent les AGL. 

Mais ce n'est que 50 %  du travail car il reste la modélisation dynamique, c'est ce qui s'appelle le rule flow. 

Le rule flow permet l’orchestration des règles c’est la partie qui varie le moins possible. 

La bonne pratique consiste pour chaque tâche à associer des packages de règles, ce qui permet d’en ajouter/modifier/supprimer sans avoir à le faire dans les tâches, elles sont prises en comptes automatiquement. 
L'outil UML utilisé est le diagramme d'activité dans lequel est représenté les tâches (activités) et leur orchestration. L'AGL permet d'assurer la traçabilité entre les règles définies dans le modèle statique et les tâches. Il suffit de mettre des liens de dépendances entre les règles (ou les package de règles) et les activités. 
La vue traçabilité de l'AGL montre toutes les dépendances de manière bidirectionnels et des mesures d'impacts peuvent ainsi être effectuées.
Les règles du Plan d'Occupation des Sols de la vue fonctionnelle imposées par la cadre d'urbanisme du Système d'Information imposent de représenter le référentiel de règles métiers dans un quartier spécifique au coté de celui du référentiel de données métiers transverses situés tous les deux dans la zone référentielle. Faire cette modélisation des règles métiers systématiquement ajoute un peu de charge au départ mais tous les retours d'expérience prouve que l'on peut s'attendre à un retour sur investissement de l'ordre de 20%.

 

"Le commencement de toutes les sciences, c'est l'étonnement de ce que les choses sont ce qu'elle sont."

Aristote


12/05/2015
0 Poster un commentaire