Cursus de formation à la méthode Praxeme

Synthèse du cursus

(le détail de chaque module est disponible ci-dessous)

• Cette première journée présente aux utilisateurs (MOA) une synthèse des concepts de la SOA ainsi que le cadre général de la méthode d’entreprise.

Pourquoi la SOA ?

• Evolution de l’approche par silos fonctionnels et techniques vers une structuration du système d’information sous la forme de services. Les niveaux de maturité de la SOA (surface, refonte et étendue)
• Exemples de services réutilisables dans un contexte d’assurance (services IHM et illustration d’une intégration de services dans un reporting décisionnel).

Introduction à Praxeme

• La méthode d’entreprise Praxeme : introduction à la topologie du système d’information en huit aspects. Les types de services (présentation, organisation, métier) et les concepts de processus, cas d’utilisation (micro-processus) et activités.
• Urbanisation et architecture logique SOA : la méthode d’entreprise permet d’étendre les travaux d’urbanisation habituelle afin de favoriser le lien entre la cartographie fonctionnelle et la conception orientée objets. Exemple de cartes d’urbanisation (fonctionnelle et par domaines d’objets) dans le contexte d’un projet d’assurance, exemple de graphes d’architecture logique.
• BPM (Business Process Management) et démarche de conception : la méthode d’entreprise permet de mieux situer les travaux de BPM en tirant profit de la modélisation du métier réalisée dans l’aspect sémantique de la topologie. Présentation d’une approche de modélisation des processus qui laisse une plus grande place à l’innovation : comment éviter de reproduire dans les nouveaux processus les modes de travail actuels ? Comprendre les différents niveaux de BPM : workflow, BPM applicatif, orchestration au niveau de l’interconnexion des systèmes, etc.
• La pré-modélisation : introduction à la démarche de spécification fonctionnelle détaillée qui se situe en amont de la modélisation UML. Procédés qui permettent de préparer l’identification de services réutilisables.
• Une méthode partagée entre les utilisateurs et les informaticiens : le besoin d’une notation unifiée (UML) et l’importance de la traçabilité entre les règles (dictionnaire des exigences) et les modèles.
• Le cycle de fabrication : ne pas confondre les procédés de travail individuel (vocation principale de Praxeme) et le processus de travail collectif de type UP, SDM/S, etc. La modélisation progressive de l’organisation et du métier grâce au principe du carottage.

Conceps avancés et valeur économique de la SOA

• Ergonomie : la SOA offre de nouvelles facilités pour organiser le poste de travail. Les ruptures de processus imposés par les silos fonctionnels disparaissent, ce qui laisse la place à une ergonomie plus orientée autour des cas d’utilisation.
• Favoriser l’agilité : comment fabriquer des services dont le comportement pourra s’adapter facilement sans remettre en cause le système ? Présentation de l’ACMS (Agility Chain Management System) qui met en œuvre le Master Data Management (MDM) pour la rationalisation des données de référence et le paramètrage, le Business Rule Management System (BRMS) pour traiter les règles de gestion en langage naturel, ce qui évite une programmation informatique rigide, le Business Process Management (BPM) pour la gestion des processus.
• Batchs et progiciels en SOA. Comment juger de la qualité du système SOA ? Les risques : check-list des points de vigilance. La valeur économique de la SOA.

• Cette session permet aux informaticiens de découvrir la méthode d’entreprise Praxeme à l’occasion d’un cas réel. Ce cas est issu d’un projet de refonte SOA pour une compagnie d’assurance.

Aperçu rapide de Praxeme

• Origine de la méthode, mode de fonctionnement autour de la méthode (diffusion, capitalisation).
• Rénovation des systèmes d’information en SOA : l’évolution des silos fonctionnels et techniques vers la structuration en services, la plate-forme SOA, les niveaux de maturité de la SOA (surface, refonte, étendue), l’ACMS (Agility Chain Management System) comme solution pour améliorer l’agilité des services.
• Topologie de la méthode en huit aspects, pré-modélisation et principe de carottage pour la modélisation progressive de l’organisation et du métier.
• Aperçu de l’aspect sémantique (modélisation du métier) avec des exemples issus d’un cas réel. Conception par contrat grâce aux automates à états.
• Aperçu de l’aspect pragmatique (modélisation de l’organisation) avec des exemples issus d’un cas réel. Concepts de processus, cas d’utilisation (micro-processus), activité. Introduction aux cas d’utilisation en approche d’analyse (non optimisé) et en conception (suppression de la redondance des activités).
• Aperçu de l’aspect logique (modélisation des services) avec des exemples issus d’un cas réel. Premier niveau de présentation des principes de dérivation des modèles amont (sémantique et pragmatique) vers les constituants de l’architecture orientée services. Principes de stratification de l’architecture logique. Premières règles importantes de dérivation et exemples. Les règles détaillées de dérivation sont présentées dans le module « Modélisation logique en SOA ».
• Ergonomie et SOA : grâce à la suppression des silos fonctionnels et techniques, on peut envisager l’organisation du poste de travail autour des cas d’utilisation.
• Lotissement et SOA : soit par incrément fonctionnel (classique), soit par incrément architectural autour des constituants de l’architecture SOA (plus innovant) et impact sur la stratégie de conception des tests.
• Batchs et progiciels en SOA.
• Critères qualité attendus du système SOA.

Cas réel avec Praxeme

• Cas réel issu de l’assurance (« Archivage d’un dossier sinistre ») qui illustre la démarche et les livrables de la pré-modélisation (spécification fonctionnelle des besoins), modélisation sémantique et pragmatique, modélisation logique des services.
• Principes de dérivation des modèles amont d’expression des besoins vers les constituants logiques de la SOA.
• Exemple qui illustre l’intégration des technologies d’agilité de BRMS (Business Rules Management) et MDM (Master Data Management) pour la gestion des variantes de services.

• Cette journée permet aux participants de maîtriser les procédés de la modélisation amont qui traitent la conception des besoins. Ces procédés et les livrables associés ne dépendent pas de la SOA. Ils feront l’objet d’une dérivation ultérieure vers l’architecture orientée services selon des règles formelles. Ces règles sont étudiées dans le module « Modélisation logique en SOA ».

Pré-modélisation

• A quoi sert la pré-modélisation ?
• Points de vigilances pour ne pas rater la construction d’un système agile.
• Détails de l’organisation des documentations de SFD (Spécification Fonctionnelle Détaillée) autour des concepts d’activité, de vue, d’acte de gestion (cas d’utilisation ou micro-processus) et de processus (BPM orienté humain ou workflow).
• Rappel sur les tests.

Modélisation sémantique

• Essai d’une modélisation sémantique. L’exemple montre la différence entre une modélisation de données classique et la modélisation sémantique : rôle sur les associations, classe associative, héritage, association réflexive, association ternaire. On commence à évoquer l’extension du modèle vers la prise en compte des opérations et du cycle de vie des objets du métier. On insiste déjà sur le point que la modélisation sémantique se préoccupe exclusivement du métier et écarte les contraintes organisationnelles. Celles-ci seront traitées dans la modélisation pragmatique (principe du respect des niveaux d’abstraction).
• Exigences de la modélisation sémantique pour la partie statique : être capable de valider les modèles, la description des informations et des opérations, prise en compte des contraintes, exemples à partir d’extraits issus d’un cas réel de modèle sémantique.
• Exigences de la modélisation sémantique pour la partie dynamique : formulation du cycle de vie des objets du métier avec les automates à états, rappel sur la notation UML pour les automates, exemples à partir d’extraits issus d’un cas réel de modèle sémantique.
• Structuration du modèle sémantique en domaines d’objets (urbanisation autour des objets métier).
• Gestion des exigences et critères qualité attachés au modèle sémantique.
• Faut-il faire en une seule fois tout le modèle sémantique à l’échelle du SI ? Le principe du carottage.

Modélisation pragmatique

• Modélisation des cas d’utilisation au niveau de l’analyse : comment les concevoir ? Utilisation de l’automate à états pour concevoir de manière formelle la dynamique du cas d’utilisation c'est-à-dire les différents scénarios d’exécution.
• Modélisation des cas d’utilisation au niveau de la conception : optimisation de la vue d’analyse en supprimant la redondance des activités grâce à une meilleure organisation des cas d’utilisation : inclusion, extension, généralisation des cas.
• Modélisation des processus. L’approche fonctionnaliste de la modélisation des processus versus l’approche qui s’appuie d’abord sur le cycle de vie des objets du métier spécifié dans l’aspect sémantique.

• Cette journée permet aux participants de maîtriser les procédés de la modélisation logique dans le cadre d’un style d’architecture orientée services (SOA). Ces procédés sont constitués de règles formelles qui assurent la dérivation des modèles amont (sémantique, pragmatique) vers les constituants de l’architecture orientée services.

Principes de départ

• Pourquoi faut-il une modélisation logique ?
• Définition des termes qui forment les constituants de l’architecture logique : fabrique, atelier, machine, service.
• Types de relation dans l’architecture logique.
• Démarche générale de la dérivation des modèles amont vers les services.
• Graphe d’architecture logique : principe de stratification, mode de séquencement des services par propagation et par orchestration, la factorisation des services utilitaires, exemples de graphe d’architecture issus d’un cas réel.
• Dispositifs de gestion des codifications (codiers) et des signaux (gestion des erreurs).

Dérivation du sémantique vers la SOA

• Détail des procédés de dérivation du modèle sémantique vers les constituants SOA : les domaines d’objets, les classes, les relations, les automates à états, les opérations. Les décisions complémentaires autour des ateliers logiques.
• Structures de données : procédé de détachement des attributs de la classe pour former les flux d’information utilisés pour les échanges entre les services, structuration des types de données, localisation des types de données dans le graphe d’architecture logique.
• Détail des automates de la strate métier.

Dérivation du pragmatique vers la SOA

• Détail des procédés de dérivation du modèle pragmatique vers les constituants SOA : les domaines fonctionnels, les cas d’utilisation, les règles d’organisation, les automates à états, les autres objets du modèle pragmatique. Les décisions complémentaires : transaction, structure de données, codification, signaux, etc.
• Détail des automates de la strate de l’organisation.

Conception des services logique

• Algorithme du service : diagramme d’activité, pseudo-code, la manipulation des données, la gestion des signaux (erreurs), l’invocation des services, les foncteurs.
• La démarche de tests.

• Cette journée permet aux participants d’appréhender le socle technique pour déployer la SOA et de disposer d’une check-list détaillée des points à traiter au titre de la négociation logique – technique. Cette négociation est une étape prévue dans la méthode pour fixer les choix techniques qui peuvent avoir un impact sur certains procédés de modélisation logique. Par exemple, si le socle technique permet de gérer les transactions par un simple paramètrage sur les services alors il suffit de prévoir, au niveau de la modélisation logique, une annotation UML « transaction » sur le service logique. Un autre exemple concerne l’utilisation du système de gestion des règles. Dans le cas où le socle technique dispose d’un BRMS (Business Rules Management System) alors les règles de l’organisation en provenance du modèle pragmatique ne sont pas spécifiées en pseudo-code mais directement dans le langage de règles.

Présentation d’un socle technique type d’une architecture SOA

• Framework ou machine virtuelle d’exécution des services avec exemple de la Virtual Engine for Praxeme (VEP). Cette partie de la session permet de fournir un aperçu sur les modèles du logiciel.
• Positionnement de l’ESB (Enterprise Service Bus) par rapport à la machine virtuelle d’exécution des services.
• Les patterns d’implémentation : factory, proxy, gestion des transactions, contextualisation des règles, exemples de code en Java, la chaîne d’agilité avec le MDM (Master Data Management), le BRMS (Business Rules Management System) et le BPM (Business Process Management).
• Les conditions de la réussite du MDA (Model Driven Architecture) : rappel des principes du MDA et exemples, respecter la distinction entre PIM (Platform Independant Model) et PSM (Platform Specific Model), banaliser les interfaces de services, risques à traiter.
• La mire SOA : un outil pour faire un audit du socle technologique.

Check-list de la négociation logique - technique

• Information : persistance, dérivation de l’héritage, historisation, etc.
• Transformation : automate à états, règles, etc.
• Action : gestion des événements, gestion des processus, gestion des transactions, etc.
• Coopération : relations, types de communication, appel de services, etc.
• Constitution : style de l’architecture logique, service, machine, atelier, etc.
• Construction : déploiement, gestion des versions, gestion de la configuration de services, etc.