Atelier 4 - conception logique SOA

Atelier 4 - conception logique SOA
Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les principes SOA 31 March 2017 Atelier 4 - conception logique SOA

Definitions Definitions SOA Le terme SOA est apparu en 1996 dans une note de recherche du Gartner : Service-oriented architecture (SOA) is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces. 31. März 2017 | Title of Presentation

Definitions Definitions SOA « A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. » « Paradigme pour organiser et utiliser des fonctionnalités réparties entre plusieurs domaines métiers. Elle offre un moyen uniformisé pour fournir, découvrir, solliciter et utiliser des capacités qui produisent des résultats prévisibles et cohérents avec des pré-conditions mesurables. » 31. März 2017 | Title of Presentation

Definitions Definitions SOA S comme « service » : fonctionnalités rendues par une entité pour une autre afin d’atteindre un résultat donné. O comme « oriented » : façon de concevoir l’architecture pour permettre à un ensemble de services d’interagir afin de résoudre un problème métier A comme « architecture » : organisation d’un système à travers ses fonctionnalités et ses interactions vis à vis de son environnement. SOA est donc avant tout un modèle d’architecture destiné à assurer l’interopérabilité, l’agilité et la réutililisabilité. SOA vise à accroître l’agilité du SI et expose le SI sous la forme de services indépendants et réutilisables via des standards. 31. März 2017 | Title of Presentation

Definitions SOA Architecture SOA : changement de perspective dans la construction des systèmes informatiques : Rapprochement vers les métiers : C’est une approche du SI tirée par les processus qui remet donc la logique métier au cœur des fonctionnalités du SI. Les services métiers sont visibles donc mieux perçus par les responsables de processus : la démarche favorise donc l’implication des métiers dans la construction du SI.  Rationalisation et simplification du SI existant et du SI cible : - Le découplage entre applications, applications / données, données / données minimise les redondances et donc les risques d’incohérence. 31. März 2017 | Title of Presentation

SOA Principles and goals Definitions
Objectives Principles and goals Definitions SOA Value How to deliver the promises of SOA ? SOA Improve Business Agility Increase IT Investments ROI Improve Business knowledge Better align Business & IT Increase IT assets reuse Decrease IT costs Activities Develop & improve Business Modelling across silos Adopt a Business Service design approach Improve Analysis & Design Quality Decrease the number of active systems Identify key value added processes and activities Limit tactical-only approach to SOA (bottom-up) Adopt a standards based modelling approach (UML) Improve architecture lifetime through better reuse Améliorer qualité de l’analyse et du design. Les gens ont cessé de concevoir à partir de l’arrivée du Client / Serveur. Les applications mainframe sont souvent mieux pensées que les applications Client / Serveur qui ont du code métier dans l’IHM Adopter des standards de modélisation. Mais ne pas perdre de vue qu’on ne modélise que pour discuter sur un problème (I.Jacobson). Mais ne pas modéliser est aussi grave que de tout modéliser Identify Business Services & related Business KPI’s Design integration architecture without vendor lock-in Define SOA standards & principles Adopt open standards and mature open source solutions Improve Business Tasks Generosity Increase interoperability through standardized service contracts Improve reusability and extend the scope of services Adopt reliable agile project management methods Classify Business processes, activities & services Increase service composition through orchestration Build a Service Repository Strengthen the governance of IT assets 31. März 2017 | Title of Presentation

Les retours d’expériences SOA : importance d’une méthode EA/SOA
Les Gains de la SOA Accroitre le ROI des investissements IT Accroitre l’Agilité des Organisations Objectifs Accroitre la réutilisation des Assets IT Réduire le gâchis des dépenses IT Accroitre la Connaissance du Métier Accroitre l’alignement des activités Métiers et des services IT Accroitre la qualité des phases d’analyse et conception Réduire la taille du parc applicatif Accroitre la Modélisation du Métier Adopter une démarche de conception (top-down) par les services métiers Adopter une approche par les modèles en UML Augmenter la durée de vie de l’architecture Identifier les processus et activités à valeurs ajoutées Réduire une démarche d’intégration (bottom-up) tactique du Legacy Définir des Principes et Standards pour la SOA Adopter des standards ouverts et des technologies Open-source matures Identifier les services Métiers et indicateurs Qualité et de Performance Adopter une architecture d’intégration non liée à une solution éditeur Pratiques Terrain Accroitre la généricité et la couverture des services Adopter des méthodes de Gestion de Projet Agiles et Rigoureuses Renforcer la généricité des services et étendre les conditions d’utilisation Accroitre l’interopérabilité en standardisant les contrats de service Disposer d’un Référentiel de Services Renforcer la gouvernance des Assets sur tout leur cycle de vie Référencer les processus, activités et services Métiers Accroitre les compositions de services par de l’orchestration

Definitions Definitions Service (standard et définition commune OASIS, Open Group et OMG de novembre .2009) “Les services correspondent à des activités répétables, pouvant être caractérisées comme des possibilités ou des accès à des possibilités, ces possibilités satisfaisant des besoins spécifiques. Ces services sont autonomes, ils sont décrits et les accès et interactions avec les services sont contraints par des politiques et des contrats. Nous convenons que l’implémentation des service est opaque à ses consommateurs qui interagissent avec le service.” Services = concepts Webservices : mode d’implémentation 31. März 2017 | Title of Presentation

Concept de granularité
La granularité est un élément fondamental dans la réussite d’une SOA car elle mesure la qualité et la réutilisabilité des services produits. La granularité est une mesure de la richesse fonctionnelle d’un service. Plus la granularité est forte, et plus le service encapsule une liste importante de fonctionnalités. Par extension, la granularité métier mesure l’agrégation de fonctionnalités et la capacité d’un service à apporter de la valeur au métier. Les règles de conception issue de la méthodologie go-on offrent une méthode générale et des solutions pour atteindre un bon niveau de granularité pour les services.

Comparaison Avantages Inconvénients Réutilisation facile
. Faible granularité Avantages Inconvénients Réutilisation facile Pas de valeur ajoutée métier Performances Inintelligible pour les utilisateurs finaux . Forte granularité Avantages Inconvénients Forte valeur ajoutée Réutilisation délicate Performances Compréhensible par les utilisateurs Faible granularité = développeur : confondre module avec un besoin métier Forte granularité = urbaniste

Les erreurs les plus fréquentes
Les services ‘de développeur’ : Ces services ont souvent un granularité très faible car ils exposent des fonctions élémentaires (syndrome des services CRUD) avec très peu de métier : Les performances des applications ainsi construites sont catastrophiques. La valeur ajoutée des services est très limitée. Les utilisateurs finaux ne comprennent pas la finalité des services Les services ‘d’urbaniste’ : Ces services métiers très haut niveau qui souffrent du syndrome du ‘neveu de Rameau’ (ou tour d’ivoire): Les services sont rarement réutilisés Ils accostent difficilement avec la réalité du SI Ils sont difficilement utilisables tels quels et doivent être spécialisés

Definitions Domaine métier
Sous-Domaine Définition : ensemble de processus métier contribuant à une même mission au regard de l’entreprise, selon une certaine stratégie et une certaine politique. Un domaine peut être divisé en sous-domaines, selon le niveau de spécialisation et de clarification. Sous-Domaine etc… Caractéristique majeure d’un domaine : Forte cohésion interne et faible couplage avec les autres domaines. Ce découpage a pour objet de partitionner le métier de l’entreprise en ensembles fortement cohérents communiquant entre eux avec un maximum de flexibilité. 31. März 2017 | Title of Presentation

Definitions Domaine métier Les domaines métier identifiés ne doivent pas dépendre de l’organisation interne de l’entreprise. Les modèles en découlant sont transverses aux différentes entreprises partageant le même métier. Pratique gagnante sur « improve business practices » : Modéliser les domaines métier et faire en sorte que les domaines communiquent entre eux en couplage faible dans une logique SOA Un domaine entier est vendable car réutilisable On peut faire communiquer même dans une autre entreprise. 31. März 2017 | Title of Presentation

Le service métier : façade d’accès aux informations du domaine
Definitions Les enjeux du découpage en domaines métier Structurer et formaliser le modèle des messages échangés entre sous-systèmes. Structurer les appels de services. Structurer le modèle de données en ensembles autonomes et cohérents. avec un principe commun …. Le service métier : façade d’accès aux informations du domaine 31. März 2017 | Title of Presentation

Les enjeux du découpage en domaines métier
Definitions Les enjeux du découpage en domaines métier Service Service Domaine B AUTORISE INTERDIT Service Service DAO Application Domaine A BDD DAO Application BDD 31. März 2017 | Title of Presentation

Les trois mondes et leur reliant
Systèmes de données Domaines métier D1 DN Applications monolythiques DAO Processus métier SE Tâche ST Un processus traverse plusieurs domaines métier. Un processus a un owner qui est son responsable. Cas d’utilisation

Approche structurée garantissant traçabilité et alignement Métier / IT
Méthodologie GO-ON Stratégie métier Objectifs stratégiques Indicateurs Processus métiers Procédures, Acteurs Opérations métiers Entités Métier Règles métier Fonctions dérivation Lorem ipsum Architecture métier dérivation Maquette de l’IHM Champs, actions Expression du besoin Spécifications textuelles Cas d’utilisation Règles organisationnelles Exigences non fonctionnelles Use case y Use case z OK dérivation dérivation Architecture de SI Exigences dérivation dérivation dérivation Services tâche Services entité Règles métier Types compl. messages MLD Tables relations IHM Médiations Processus OK Couche présentation Couche processus Architecture de SI Applications Couche métier Architecture de SI Données No. 17

Niveau de granularité croissant Degré de réutilisation croissant
Définitions : les services métier Ces services dits fonctionnels exécutent de la logique métier. Ils sont au nombre de trois : Niveau de granularité croissant Service processus : Ce service correspond au processus métier de plus haut niveau orchestrant les différents cas d’utilisation du processus métier. Service tâche : Un service tâche correspond à l’implémentation d’un cas d’utilisation avec une orchestration (services et tâches humaines). Service entité : Un service entité est centré sur le métier basant sa frontière fonctionnelle et son contexte sur une ou plusieurs entités métiers. Il est indépendant des processus métiers Degré de réutilisation croissant 18

Principes de conception logique SOA > Types de services de base
Service Processus Service Utilitaire Service Tâche Taux de réutilisation croissant Service Entité Remarque : Sans moteur d’orchestration (ex : BPM), on ne peut espérer avoir une bonne SOA qui assure de la souplesse et de la réutilisabilité 31/03/2017 Concepts et plates-formes SOA

Les services les plus techniques
Les services dits techniques exposent des fonctions élémentaires agnostiques vis-à-vis du contexte d’exécution et du métier. Ces services sont souvent facilement réutilisables mais n’apportent pas de plus value métier réelle. Service médiation : Un service de médiation réalise l’adaptation et la connectivité vers une fonction existante mais qui n’est pas exposée telle quelle sous la forme d’un service. Le service de médiation peut composer d’autres services pour améliorer la granularité du service global. Service utilitaire : Un service utilitaire expose des API élémentaires techniques qui sont utilisées par les services de plus haut niveau. Les services utilitaires ne doivent pas contenir d’éléments relatifs au contexte d’utilisation. 20

Principes de conception logique SOA > Architecture de Service en couche Un modèle de services en couches organise logiquement les services les uns par rapport aux autres selon des critères de conception prédéfinis. Les services sont catégorisés selon le type de logique qu’ils embarquent ; le potentiel de réutilisation de leur logique ; la manière dont leur logique est adhérente à des domaines pré existants dans l’entreprise Nous dénombrons 4 types de services primaires : Le Service de type Processus, un service qui encapsule la logique d’un processus métier informatisé ; Le Service de type Tâche, un service qui réalise une tâche spécifique dans un processus métier ou un cas d'utilisation complet ; Le Service de type Entité, un service qui gère une entité ou un ensemble d'entités fortement couplées ; Le Service de type Utilitaire, un service technique qui est partagé par les autres types de services. 31 March 2017 Atelier 4 - conception logique SOA

Consommateur de Service
Principes de conception logique SOA > Composition entre types de services Consommateur de Service Service Médiation Service Processus La relation entre un consommateur de service et un fournisseur de service (service concret) doit impérativement passer par un service Médiation. Service Processus Service Tâche Service Entité Service Utilitaire AUTORISE NON AUTORISE AUTORISE1 1 Seulement au sein d’un même domaine métier 31/03/2017 Concepts et plates-formes SOA

Architecture de SI – Règles appliquées
IHM Appel inter-module possible OK Couche présentation Appel intra-module uniquement Processus Services tâche Médiations Couche processus Module C Module B Legacy Règles organisation Services entité Services entité Couche métier Module A Module B Règles métier BDD Règles métier BDD DAO DAO 23

La discipline de modélisation métier dans GO-ON

Domaines fonctionnels
La discipline de modélisation métier dans GO-ON Objectifs : Spécifier le fonctionnement du métier après la réalisation du projet, de manière à atteindre les objectifs métier définis Rôles : Stratège métier : Définit les objectifs métier et vérifie l’alignement des processus métier cible avec ces objectifs Analyste métier : Réalise les modèles métier Objectifs métier Domaines fonctionnels impactés Remarque : nous sommes dans un processus SOA, donc orienté « réutilisabilité ». Cette façon de penser commence dès la modélisation métier Modèle de processus métier Modèle de Domaine métier (entités métier) 26

Modélisation métier – Livrables
Définition hiérarchique des objectifs métier du projet Modélisation hiérarchique des fonctions (métiers) de l’entreprise (synonyme de plan d’urbanisme fonctionnel). On identifie les métiers concernés par le projet. Modèle représentant l'activité de l'entreprise (actuelle et cible) en tant que tâches exécutées par des acteurs dans une succession bien définie en produisant, modifiant ou utilisant des entités métier (lien avec le modèle de domaine métier). La modélisation est limitée au périmètre du projet. Modèle objet représentant les informations manipulées par l’entreprise (uniquement sur le périmètre du projet), leurs états et règles métier. Objectifs métier Domaines fonctionnels impactés Modèle de processus métier Modèle de Domaine métier (entités métier) 27

Traçabilité de la tâche du processus au cas d’utilisation (1/2)
Méthodologie GO-ON Un processus métier se décompose en sous-processus jusqu’à atteindre l’élément de granularité que nous appelons la tâche. Nous l’identifions à l’aide des 6 critères ci-dessous (Auteur : Rochfeld – 1977, Chef du projet Merise ) : –Raison d’être unique : Une tâche produit un résultat en réponse à un seul type d’événement déclencheur. –Significative pour l’organisme : La tâche doit avoir une valeur ajoutée pour l’entreprise, quantifiable et mesurable par des processus de gestion. –Unité de responsabilité : La tâche doit être exécutée dans sa totalité sous la responsabilité d’une unique unité organisationnelle. –Uniformité d’action : La logique et le séquencement de la tâche ne doivent pas être impactés par un éventuel changement de ses circonstances d’utilisation. Si les circonstances d’utilisation exigent des façons totalement différentes de procéder, il est alors nécessaire de définir plus d’une tâche. –Unité de temps : Une tâche peut ne produire aucun résultat significatif ou utile si son exécution est interrompue. Si elle est commencée, elle doit être terminée. Si elle est interrompue, elle doit être annulée. –Unité du mode d’automatisation • Raison d’être unique : Une unité de tâche produit un résultat en réponse à un seul type d’événement déclencheur. • Significative pour l’organisme : L’unité de tâche doit avoir une valeur ajoutée pour l’utilisateur, quantifiable et mesurable par des processus de gestion. Certaines sont significatives pour les utilisateurs, mais trop petites pour être suivies dans une perspective d’affaires. Elles doivent être traitées comme des étapes de tâche (activité élémentaire dans une unité de tâche que peut comprendre un utilisateur et qui a une valeur pour lui. Elle est influencée par l’infrastructure technologique et les environnements de travail où elle se déroule.) • Unité de responsabilité : L’unité de tâche doit être exécutée dans sa totalité sous la responsabilité d’une unique unité organisationnelle (service, département…). Un transfert de responsabilité nécessite la définition d’une autre unité de tâche. La responsabilité de l’exécution et du contrôle est le reflet des exigences en matière de compétence, de responsabilité, de sécurité, de niveaux d’autorité et de propriété établies par l’organisme. • Uniformité d’action : La logique et le séquencement de l’unité de tâche ne doivent pas être impactés par un éventuel changement de ses circonstances d’utilisation. Si les plates-formes technologiques (configurations d’infrastructure dans la vue de l’utilisateur) ou les circonstances d’utilisation exigent des façons totalement différentes de procéder, comme l’utilisation d’étapes de tâche différentes ou une séquence différente d’étapes de tâche, il est alors nécessaire de définir plus d’une unité de tâche. • Unité de temps : Une unité de tâche peut ne produire aucun résultat significatif ou utile si son exécution est interrompue. Si elle est commencée, elle doit être terminée. Si elle est interrompue, elle doit être annulée. S’il est prévu qu’un processus demeure en suspens pendant que d’autres événements se produisent, ceci peut influer sur les traitements subséquents, et ce processus doit être divisé en deux unités de tâche ou plus. Le cycle d’exécution d’une unité de tâche doit pouvoir être exprimé par un seul terme - sur demande, par heure, jour, semaine, mois, année. Des processus similaires exécutés à des fréquences différentes peuvent être des unités de tâche séparées, surtout lorsqu’il y a des différences considérables dans les critères de qualité connexes. Le fait de spécifier un cycle d’exécution ne permet toutefois pas d’éviter l’exécution ponctuelle de la tâche. • Unité du mode d’automatisation : Le traitement d’une unité de tâche est soit : -interactive (automatisée) : l’utilisateur interagit avec une interface (un ou plusieurs écrans).Une UT interactive nécessite une intervention directe de l’utilisateur (ou d’un autre système) entre le début et la fin du traitement. Elle peut comprendre les étapes de tâche manuelles. -Entièrement automatisée : aucune intervention de l’utilisateur. Une unité de tâche entièrement automatisée ne nécessite pas d’intervention de l’utilisateur (ou d’un autre système) du début à la fin du traitement. La plupart des unités de tâche entièrement automatisées font partie d’un cycle de production par lots et leur exécution est donc différée. -manuelle (non automatisée) : l’unité de tâche n’est pas informatisée. Une UT manuelle est exécuté par l’utilisateur du début à la fin. Elle ne comporte que des étapes de tâche manuelles. No. 28

Traçabilité de la tâche du processus au cas d’utilisation (2/2)
Méthodologie GO-ON Notre méthodologie préconise un approche par les cas d’utilisation (use case driven), conformément à UP qu’elle intègre. Un Use Case est une séquence de transactions avec un système dont l’objectif est de produire un résultat mesurable pour un acteur particulier (Ivar Jacobson). D’après Craig Larman (référence mondiale en modélisation UML), un cas d’utilisation doit se conformer au EBP Test (test du PME). PME (processus métier élémentaire) : Une tâche accomplie par une personne dans un endroit à un moment, en réponse à un événement métier, qui ajoute de la valeur ajoutée et laisse les données dans un état cohérent => Il est donc possible d’associer à une tâche automatisable (interactive ou entièrement automatisée) d’un processus métier un cas d’utilisation du modèle d’analyse, en assurant ainsi la traçabilité entre les vues « métier » et « exigences » ! Use case y Use case z

Traçabilité de la tâche du processus au « service tâche »
Méthodologie GO-ON Au niveau de la discipline d’analyse, à tout cas d’utilisation correspond une classe de type « control » représentant la logique applicative du cas d’utilisation (principe euristique de Jacobson). Au niveau SOA, c’est le service de type « tâche » qui va s’apparenter au cas d’utilisation et au « contrôleur ». La traçabilité est assurée de la tâche au use case, et du use case au service SOA l’implémentant. Remarque : les trois typologies de services SOA que nous utilisons (entity service, task service & orchestrated task service) sont d’après la catégorisation faite par Thomas Erl, référence mondiale en matière SOA. Use case y Use case z control Services tâche No. 30

Traçabilité de l’objet métier au « service entité »
Méthodologie GO-ON Traçabilité de l’objet métier au « service entité » Nous assurerons la traçabilité du modèle des objets métier (MOM) venant de la pure modélisation métier au modèle d’analyse UML des classes du système. Nous avons à ce sujet des règles déjà définies pour projecter le MOM dans l’outil de modélisation UML. Ainsi, la première itération du modèle d’analyse dans RSA serait directement produite depuis ce modèle des objets métier. Les modèles de classes d’analyse et de conception ont néanmoins vocation d’être raffinés pour les besoins d’un projet (et aussi : application de patterns d’analyse, de GRASP, de design patterns…). => Les règles GO-ON nous permettent par ailleurs de dériver les « services entité » des objets métier, en assurant ainsi la traçabilité aussi à ce niveau. Entités Métier Règles métier Services entité

Méthodologie GO-ON

Modélisation Visuelle
Permet de mieux mémoriser et communiquer Rechercher et la modification dans les grandes lignes du système en ignorant les détails de la programmation Les langages visuels : Impliquent au moins 50% du cerveau. Sont naturels et faciles pour notre cerveau. => Utiliser les diagrammes UML !

Description textuelle Diagramme de classes global
Démarche classique Description textuelle Diagramme de classes global 34

Exemples Diagramme de séquence système du UC « Gérer son panier »
L’Internaute enregistre les ouvrages l’intéressant dans un panier virtuel (voir UC Rechercher des ouvrages). Le Système lui affiche l’état de son panier. Chaque ouvrage qui a été préalablement sélectionné est présenté sur une ligne, avec son titre, son auteur et son numéro ISBN. Son prix unitaire est affiché, la quantité est positionnée à « 1 » par défaut, et le prix total de la ligne est calculé. Le total général est calculé par le Système et affiché en bas du panier avec le nombre d’articles. L’Internaute continue ses achats (voir UC Rechercher des ouvrages). Extensions : 2.a : Le panier est vide Le système affiche message d’erreur («Votre panier est vide») et lui propose de revenir à une recherche d’ouvrage (voir le cas d’utilisation Chercher des ouvrages). 4.a : L’acteur modifie ou supprime les quantités des lignes. Il revalide le panier en demandant la mise à jour du panier Le cas d’utilisation reprend à l’étape 2 du scénario nominal. 4.b : L’Internaute demande devis pour commander par courrier. Système : fournit devis imprimable à joindre au règlement récapitulant commande et total à payer. 4.c : L’Internaute souhaite commander en ligne 1. Le Système l’amène sur la page d’identification 2a. L’Internaute s’identifie en tant que client (voir UC S’authentifier) 2b. L’Internaute visiteur demande à créer un compte client (voir le cas d’utilisation « Créer un compte client ») Diagramme de séquence système du UC « Gérer son panier » Description textuelle du UC « Gérer son panier » 35

Démarche : ajout de la dimension « Architecture métier »
Description textuelle Processus métiers Procédures, Acteurs Opérations métiers Entités Métier Règles métier Diagramme de classes global 36

Démarche : ajout de la dimension « Architecture métier »
(ex : ARIS) Architecture métier (ex : ARIS) Description textuelle Processus métiers Procédures, Acteurs Entités Métier Règles métier UML modeler (ex : RSA) UML modeler UML modeler Diagramme de classes global 37 37

Exemples Diagramme de classes du domaine ou MOM (Modèle Objets Métier)
Diagramme de classes participantes du Use Case « Gérer son panier » 38

Diagramme d’interaction (séquence) du Use Case « Gérer son panier »
Exemple de modèle d’analyse : diagramme de séquence Diagramme d’interaction (séquence) du Use Case « Gérer son panier »

Les types de classes d’analyse en UML
Couche présentation applicative métier Pour le modèle d’analyse, le RUP propose 3 types de classes : <<boundary>> : classes qui servent à modéliser les interactions entre le système et ses acteurs (utilisateurs et systèmes externes) Ex : Distributeur, Interface guichet <<control>> : classes utilisées pour représenter la coordination, l’enchaînement, les transactions et le contrôle d’autres objets – elles sont en général reliées à un cas d’utilisation particulier Ex : Retrait. Peut aussi encapsuler le contrôle lié à un UC. <<entity>> : classes servant à modéliser des informations durables et souvent persistantes Ex : Compte

Diagramme de séquence type :

Gestion de panier virtuel sur le site amazon.fr
Exemple de modèle d’analyse : diagramme de classes Gestion de panier virtuel sur le site amazon.fr

Gestion de panier virtuel sur le site amazon.fr
Exemple de modèle d’analyse : diagramme de séquence Gestion de panier virtuel sur le site amazon.fr

Constitution des vues statiques et dynamiques
L’analyste ou le concepteur se sert de la spécification des services pour valider et affiner les diagrammes de classes et vice versa. C’est par l’itération continue qu’on arrive à un modèle stable et optimal. Cette spécification permet notamment de remonter les associations les rôles, et les cardinalités, en les validant.

Identification des services
Démarche de conception Services candidats Services validés La phase d’identification des services est assurée en amont lors de la phase d’analyse métier et de gestion des exigences. Cette identification des services alimente un portefeuille de services candidats qui sont validés lors de la démarche de conception.

Démarche : ajout de la dimension « SOA »
IHM OK Description textuelle Services tâche SOA Services entité Tables relations Diagramme de classes global 46

Méta modèle de GO-ON : lien entre analyse UML & SOA

Atelier 5 - conception logicielle SOA
Exemple sur un cas métier concret : > Lien Classes & Services entité 31 March 2017 Atelier 5 - conception logicielle SOA

Exemple sur un cas métier concret : > Lien Use case & Services tâches

SOA Analyst – Service Analysis & Modelling Tasks List
Review Business Goals Complete Models Specify Target System Specify GUI/Workflow 2. Identify Target Domains 7. Complete Business Processes Models 1. Review Project Objectives 12. Specify GUI StoryBoard 3. Review Business Domain/Syst Objectives 8. Assess Activities /Tasks Granularity 6. Identify Actors & Use Cases 13. Specify GUI MAPS/Portlets Business Architecture View Requirements View 4. Identify Business Processes 10. Complete Ontology Models 9. Detail Use Cases Dependencies 15 Specify User Stories for GUI Features 5. Review Business Domain/Syst Models 14. Complete Business Rules 11. Specify Use Cases in Essential Form 16. Specify Workflow Rules Apply Agile Modelling Identify Existing Assets Identify Candidate Services Specify Services 17. Refine Entity Modelling 21. Identify Existing Services 25. Identify Atomic Services 29. Specify Atomic Services 18. Apply Patterns (GRASP, …) 22. Identify needed Service Consolidation Effort 26. Identify Service Composition 30. Specify Service Composition IS Application & Data View 19. Refine Behaviour Modelling 23. Identify Existing Appli. Components 27. Identify Processes as a Service 31. Specify Processes as a Service 20. Check Consistency Static/Dynamic Models 24. Identify needed Appli. Comp. Refactoring Effort 28. Identify Composite Appli. Part as a Service 32. Specify Composite Appli. Part as a Service 31 March, 2017 HGA Review November 2008 No. 51 31 March, 2017 HGA EA-SOA - Enterprise Methodology No. 51

Introduction to the concept of pattern
Patterns d’analyse Introduction to the concept of pattern “Patterns” are an essential technique in the object oriented paradigm. A Pattern can be seen like a generic model solving a recurring problem. The fact of knowing and of indexing the patterns makes it possible to constitute a whole of proved reliable solutions, reusable in different contexts, therefore founded on experiment. They appear in the form of named pairs (problem+solution). There are different types of patterns, most famous being the design patterns of GoF (Gang of Four), but there are also: analysis patterns, programming patterns, architectural patterns and else.

The GRASP : General Responsibility Assignment Software Patterns
Patterns : GRASP The GRASP : General Responsibility Assignment Software Patterns 1. Faible couplage 2. Forte Cohesion 3. Expert 4. Createur 5. Controleur 6. Polymorphisme 7. Pure Fabrication 8. Indirection 9. Protection des Variations Craig Larman

Patterns : GRASP Faible couplage Il s’agit plus d’un principe d’appréciation qu’un règle ou un pattern. Ce principe est souvent appliqué inconsciemment par les bons concepteurs, voire les bons développeurs. Il faut trouver le subtil équilibre entre les GRASPs pour avoir un ensemble de classes satisfaisant les propriétés suivantes : Cohésives Rétilisable Compréhensibles Maintenables Booch : La modularité est la propriété d’un système qui a été décomposé en un ensemble de modules cohésifs et faiblement couplés. 54

Forte Cohesion Patterns : GRASP
Comment concevoir les classes de façon à augmenter leur réutilisabilité sans qu’elles ne soient trop complexes ? => Affecter responsabilités pour garder une cohésion de haut niveau. Cohésion: Mesure de la pertinence avec laquelle les responsabilités (méthodes & données) d’une classe sont reliées. Les classes de faible cohésion font des choses trop hétérogènes, et vont en corolaire souffrir des syndromes suivant : Difficiles à appréhender Non réutilisables Difficiles à maintenir fragiles – Très affectées par le changement 55

Expert Patterns : GRASP
The most general purpose responsibility assignment principle? Assign a responsibility to the information expert — the class with the information necessary to fulfill the responsibility Related to another fundamental responsibility assignment strategy central to object-oriented design: “Do It Myself” (Coad) A Loan calculates its own due date Closely related to and also known as: “Put services with attributes” (Coad) “That which knows, does it” (Seive) 56

Creator Who should create an instance of a particular class?
Patterns : GRASP Creator Who should create an instance of a particular class? Consider assigning Class B the responsibility to create an instance of class A if one of the following is true: B contains A B aggregates A B records A B closely uses A B is the “creator” of A instances This pattern supports low coupling 57

Patterns : GRASP Controller The Controller serves as a wrapper for the domain layer and receives and delegates events Also an example of GoF Façade Example : use case controller ! 58

Controller Patterns : GRASP UI Controller Domain Objects onClick()
borrowResource() Controller Domain Objects 59 59

Patterns : GRASP Polymorphism 4. stop()‏ 2. stop()‏ 3. stop()‏ 60

Patterns : GRASP Pure fabrication Q: When the use of Expert and other patterns leads to problems in coupling and cohesion, what to do? A: Assign a highly cohesive set of responsibilities to an artificial class not representing anything in the problem domain to support High Cohesion, Low Coupling, and reuse 61

Patterns : GRASP Indirection Q: How can one decouple objects so that Low Coupling is supported and reuse potential remains high? A: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled The intermediary creates an indirection between the other components or services The mediator (intermediate object) is often completely artificial Example : Use Case controllers, Façade… 62

Protect from Variations
Patterns : GRASP Protect from Variations Q: How to design objects such as variations generate no side effects on other elements? A: Identify points where variability or predictable instability may arise. Assign responsibilities in order to create « stable interfaces » around them Also known as : Information hiding Open-Closed Principle (B. Meyer) 63

Patterns : Relations between the GRASPs & the 10 design principles
Management of the evolutions & dependences between classes Management of the application stability Organization in modules

Les quatre risques qui pénalisent les développements (1/2)
Rigidité : chaque évolution est susceptible d'impacter de nombreuses parties de l'application. Développement de + en + coûteux, ce qui introduit des risques au cours du développement (c'est au moment où les échéances de livraison approchent et où la pression monte sur le projet que l'application devient la plus difficile à modifier). Coût des modifications élevé => le logiciel a peu de chances d'évoluer après sa mise en production. Fragilité : la modification d'une partie de l'application peut provoquer des erreurs dans une autre partie de l'application. Logiciel peu robuste, et coût de maintenance élevé. Modifications de plus en plus risquées => Idem. 65

Les quatre risques qui pénalisent les développements (2/2)
L'immobilité : il est difficile d'extraire une partie de l'application pour la réutiliser dans une autre application. Le coût de développement d’une application toujours élevé puisqu'il faut repartir de zéro à chaque fois. La viscosité : terme employé par Martin pour exprimer deux concepts sur l’environnement & la conception 1/ Si lors des changements, les développeurs violent la conception de départ, elle sera dégradée => Viscosité des environnement qui sont alors lents et inefficaces. 2/ Si la compilation d’un logiciel est longue, les développeurs préfèrent ne remplacer qu’une petite partie sans préserver la cohérence du code de depart. 66

Clé du problème : gestion des dépendances
Les quatre problèmes ci-dessus trouvent le plus souvent leur source dans une multiplication des dépendances : tous les modules de l'application (classes, packages) finissent par dépendre les uns des autres, ce qui aboutit progressivement à l’effet « plat de spaghetti ». Tous les principes de conception que nous allons présenter dans les slides suivants permettent de contrôler les dépendances des modules de l'application. Un contrôle strict des dépendances est en effet indispensable pour aboutir aux qualités recherchées de : Robustesse : les changements n'introduisent pas de régressions. Extensibilité : il est facile d'ajouter de nouvelles fonctionnalités. Réutilisabilité : il est possible de réutiliser certaines parties de l'application pour construire d'autres applications 67

Les dix principes fondamentaux de conception objet (1/3)
Gestion des évolutions & dépendances entre classes Principe d'ouverture/fermeture: Open-Closed Principle (OCP) "Un module doit être ouvert aux extensions & fermé aux modifications." Principe de substitution de Liskov : Liskov Substitution Principle (LSP) "Les méthodes qui utilisent des objets d'une classe doivent pouvoir utiliser des objets dérivés de cette classe sans même le savoir." Principe d'inversion des dépendances : Dependency Inversion Principle (DIP) « A. Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau. Tous deux doivent dépendre d'abstractions ». « B. Les abstractions ne doivent pas dépendre de détails. Les détails doivent dépendre d'abstractions ». Principe de séparation (ou de ségrégation) des interfaces : Interface Segregation Principle (ISP) "Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas." 68

Organisation de l'application en modules Principe d'équivalence livraison/réutilisation : Reuse/Release Equivalence Principle (REP) : "La granularité en termes de réutilisation est le package. Seuls des packages livrés sont susceptibles d'être réutilisés". Principe de réutilisation commune : Common Reuse Principle (CRP) "Réutiliser une classe d'un package, c'est réutiliser le package entier.« Principe de fermeture commune Common Closure Principle (CCP) "Les classes impactées par les mêmes changements doivent être placées dans un même package." 69

Gestion de la stabilité de l'application Principe des dépendances acycliques : Acyclic Dependencies Principle (ADP) "Les dépendances entre packages doivent former un graphe acyclique. " Principe de relation dépendance/stabilité : Stable Dependencies Principle (SDP) "Un package doit dépendre uniquement de packages plus stables que lui." Principe de stabilité des abstractions Stable Abstractions Principle (SAP) "Les packages les plus stables doivent être les plus abstraits. Les packages instables doivent être concrets. Le degré d'abstraction d'un package doit correspondre à son degré de stabilité." 70

Les design principles : exemples
OCP : exemple Figure +surface() EnsembleFigures +calculerSurfaces() De nouveaux types de figures, qui se dessinent différemment, peuvent être ajoutés sans modifier calculerSurfaces(). Cette classe est donc ouverte aux extensions, mais fermée aux modifications en réponse à l’ajout de nouvelles formes. * Circle +surface() Square +surface() +surface() public void calculerSurface() { for each Figure f in the Set f.surface(); } Principes fondamentaux de conception 71

Les design principles : exemples
LSP : exemple Non-conforme Conforme void resize(Rectangle r) { while(r.getHeight() <= r.getWidth()) { r.setWidth(r.getWidth() + 1); } } 72

The analysis patterns :
The interest of the analysis patterns of Martin Fowler, is to transfer the concept of re-use from the code to the model. Only more frequently used will be presented here. We can distinguish three: the “composite” pattern, the “meta-class” pattern and the “entity-role” pattern.

The “Composite” pattern :
The goal of this pattern is to model tree structures to represent composite / component hierarchies. It permits client to manage in the same way leafs and nodes of a tree. Example: Windows

The “meta-class” pattern :
If a given class “Class” has too much responsibilities, and some don’t depend on each instance. If the responsibilities are the same for identified sets of instances, and each set seems to represent a type or a model shared by instances => add a class “TypeClass”. “TypeClass” will endorse the common responsibilities of these sets of instances which share similarities. “Class” and “TypeClass “will be related by a 1_* association. Example: In this example, only “registrationNumber” and “mileage” are attributes which can be considered specific for each instance (each car). Height and volume : attributes which value is shared by many sets of Car instances. Obviously, for each car model, you will have the same height and the same volume. We can thus create a class “CarModel” which will take those attributes.

The “Entity-Role” pattern :
An entity can be represented by many objects. : A central one which represents the entity Other which represents roles of the entity The entity-role pattern proposes to create a class for each role and to move the right properties to it, and to keep a link between the original class considered as the entity and the “role” classes. This permits to have different views of a same concept and to make diagrams more understandable, more maintainable, and more reusable. It is also possible that the different roles will be dispatched in different packages.

The “Entity-Role” pattern :
This solution is more modular The different roles can be owned by different packages (categories) The number of properties of a class is reduced and more relevant, ensuring better cohesion. Each role can be considered like an interface on the entity object, but each one can have both attributes and associations, and implements its own operations. Some of the responsibilities and the behavior of the entity object can be delegated to the roles. This allows an object to play different roles for different « clients », and change role during its lifecycle.

Principes de conception logique SOA
Après avoir fait l’analyse et la modélisation des services au niveau logique, on prend en compte les 8 SOA design principles. 1 - Expose un contrat standard 2 - Est autonome des autres services 3 – Se couple de manière lâche 4 - Se compose 5 - Se réutilise 6 – Se découvre 7 - Communique par messages standards 8 – Sans état Remarque : 4 de ces principes sont orientés build, 4 sont orientés run 31 March 2017 Atelier 4 - conception logique SOA

> 1 – Expose un contrat de service standard
Idée maîtresse : Standardiser contrat, notamment les objets utilisés par le service. Ce principe encapsule des recommandations. But : que le composant soit une boîte noire, Items de sécurité, éléments permettant d’archiver dans un CENTRASITE (par exemple). Les services expriment leur but et leurs capacités au travers d’un contrat de service. Le contrat de service standardisé exige que des considérations spécifiques soient prises lors de la conception de l'interface technique publique d'un service afin d’évaluer la nature et la quantité d’information publiée comme la partie du contrat officiel d'un service. Concevoir le contrat : comment le service expriment sa fonctionnalité, comment types de données & messages sont définis et comment les politiques sont validées. Objectif : optimiser les contrats de service du point de vue de la granularité et du respect des standards pour s’assurer que les points d’accès des services sont cohérents, fiables et gouvernables. La séparation claire entre le contrat de service et l'implémentation du service assure l'interopérabilité et facilite le déploiement. En règle générale, la description de la structure des messages est définie selon des Schémas XML qui permettent simplement de valider les données échangées entre le consommateur de service et le fournisseur de service. 31 March 2017 Atelier 4 - conception logique SOA

> 2 - Autonomie L’autonomie, quand on parle de logiciel, représente l’indépendance avec laquelle un programme peut contenir sa propre logique. Pour un service, l'autonomie est la qualité qui représente sa capacité à implémenter sa logique indépendamment de tout autre service. Ce principe repose sur l’indépendance du service vis-à-vis des autres services et par rapport à son environnement d’exécution. Son niveau d’isolation et de normalisation sont pris en compte pour atteindre les objectifs d’autonomie nécessaires (notamment pour les services fréquemment réutilisés) Pour qu’un service puisse être implémenté de manière fiable et consistante, il doit posséder un niveau de contrôle suffisant sur son environnement d’exécution et les ressources qu’il utilise. 31 March 2017 Atelier 4 - conception logique SOA

> 3 – Couplage lâche Le couplage désigne la connexion ou la relation qui existe entre deux éléments. La mesure du degré de couplage est comparable à un niveau de dépendance. Ce principe met en évidence la création d'un type spécifique de relation à l’intérieur et à l'extérieur des frontières du service, qui met l'accent sur la réduction des dépendances entre le contrat de service, son implémentation et ses consommateurs de service. Le principe de couplage lâche promeut une conception qui assure l’indépendance en cas d'évolution de la logique d'un service (son implémentation) tout en garantissant toujours l'interopérabilité de base avec ses consommateurs. Les formes de dépendances à éviter concernent le contrat et sa logique sous jacente, l’implémentation de la logique du service avec un vendeur particulier, le consommateur et l’implémentation du service  31 March 2017 Atelier 4 - conception logique SOA

> 4 – Se compose Ce principe vise à assurer que les services sont conçus pour pouvoir participer à des compositions même si ne sont pas identifiées à l’origine. Plusieurs services peuvent être composés pour former un service de plus haut niveau. La composition de service est nommée Chorégraphie.. On ne peut composer 2 services qu’à partir du moment où ils appartiennent au même domaine métier ; la composition de services entre deux domaines métier ne peut être pris en charge que par une orchestration externe aux deux domaines. 31 March 2017 Atelier 4 - conception logique SOA

> 5 – Se réutilise La réutilisation est fortement encouragée dans une architecture SOA et fait partie du processus d’analyse et conception SOA. Ce principe de Réutilisabilité des services souligne le positionnement des services comme ressources de niveau entreprise avec des contextes fonctionnels agnostiques. Pour atteindre cette réutilisabilité , on doit s’ assurer durant la conception que le périmètre du service est correctement défini de manière à le rendre indépendant de son contexte et garantir ainsi sa réutilisation. Note: tous les services ne sont pas réutilisables ; en fonction de sa granularité, un service peut-être réutilisable ou pas. Remarque : la réutilisabilité provient de la généricité sur les tâches & les acteurs. Pour faire du réutilisable et générique au niveau SOA, faire cet effort au niveau cas d’utilisation, (donc tâche d’un processus). Un secret : se poser le problème de la réutilisabilité de l’acteur. Ex : si dans une structure, des gens de secteurs métier différents ont des cursus similaires et sont capables d’être opérationnels rapidement, il est à parier qu’on a ici de la réutilisabilité & de la généricité (ce genre de raisonnement a souvent déjà été fait côté DRH). 31 March 2017 Atelier 4 - conception logique SOA

> 6 – Se Découvre Si l’on souhaite réellement promouvoir la réutilisation des services comme des actifs IT, il est nécessaire de pouvoir les trouver facilement et en comprendre l’utilisation si opportunités de réutilisation il y a. Pour ce faire la conception du service doit intégrer ce qui va alimenter les axes de recherche potentiels via la conception des bonnes taxonomies (pour alimenter un référentiel SOA par exemple) A l’exécution , le service doit aussi pouvoir être découvert dynamiquement afin d’assurer sa transparence d’accès. 31 March 2017 Atelier 4 - conception logique SOA

> 7 - Communique par messages standards
Les services communiquent les uns avec les autres en utilisant des messages. Ces messages sont structurées en données effectives et données techniques de contexte. Les message sont généralement définis par des schémas XML et sont construits en composants les objets canoniques d’échange. 31 March 2017 Atelier 4 - conception logique SOA

> 8 – Sans état Les services doivent au maximum être sans état. Dans le cas où un service aurait à posséder un état, vous devez le concevoir afin de minimiser le temps durant lequel le service conserve cet état afin de le faire revenir le plus rapidement possible sans état (en utilisant un base de donnée par exemple). Cette caractéristique renforce les capacités de réutilisation et de montée en charge d’un service et assure une consommation raisonnée de ressources pour son exécution. 31 March 2017 Atelier 4 - conception logique SOA

Principes de conception logique SOA > Principes structurants du modèle de conception Le modèle de conception contient les actifs IT réels de l’entreprise : c’est le modèle le plus pérenne qui doit être maintenu à jour impérativement. Le modèle de conception n’est pas le détail du modèle d’analyse mais bien un modèle disjoint qui utilise des règles bien précises pour transformer les concepts issus de l’analyse en conception. Remarque fondamentale : On fait la différence (dans GO-ON) entre l’identification d’un service (qui est de l’ordre de la méthodologie) et le fait de décider de l’implémenter en tant que service. C’est un choix d’architecture (prenant en compte les performances, les contraintes de l’architecture…), d’autant que cela est difficile à développer. 31 March 2017 Atelier 4 - conception logique SOA

Type d’environnement d’exécution
Webmethods BPM Weblogic Portal BPM CAF Passerelle B2B SoftwareAG Centrasite IntegrationServer Référentiel SOA Médiateur Weblogic Server IntegrationServer ESB Exécution Service Oracle Base de données Si existants

Contrôleur applicatif
Interactions entre composants logiques pour une interaction utilisateur/Système Service tache  WebService. Chaque opération est une opération de WebService Service Entité  WebService ou Service. Contrôleur applicatif  Contrôleur applicatif du CAF, en passe plat. Service Enablement (Legacy wrapper)  Appel de services existants Service Exécution  Création de nouveaux services (composants DAO pour accès à une base de données) Client IHM Contrôleur applicatif Service tache Service entité Legacy wrapper Service Enablement Service Exécution DAO BDD Si existants

Exemple d’environnement d’exécution possible
webMethods BPM Service Processus WAS Weblogic Portal webMethods ESB+Mediator SI existant Service Tâche Utilisateur IHM Contrôleur WLI Service Exposition webMethods Mediator Service Entité SI existant Appels webservice Appels service (spécifique implémentation) Weblogic Server Service Execution AEL SIMM A définir? PF multi-canal SIMM / 3S BDD Les appels autorisés sont représentées par les flèches. Les autres appels sont prohibés. EDF IVOIRE

Exemple d’environnement d’exécution possible
Page JSP Moteur de BPM Service Processus Webservice Webservice SIMM Service Tâche Utilisateur IHM Contrôleur Service Exposition Service Entité 3S EJB Moteur de règle Service & Webservice Règles paramétrables Service Execution Règles organisationnelle Webservice Règles métier BDD IVOIRE EDF IVOIRE

Activité des composants logiciels
Composant logique Ex. composant logiciel Description IHM Page JSP Gestion des écrans utilisateurs Contrôleur EJB Gestion des enchainements d’écrans utilisateurs, de la session utilisateur, des appels aux services Service processus Moteur BPM Gestion de processus long, corbeille de tâches, déclenchement par un évènement Service tâche WebService WebService de médiation s’appuyant sur des services entité et des services d’exposition. Il effectue des transformations et de la composition de service. Service Entité Service Lorsque le service entité est utilisé uniquement par des services taches, il peut être exposé en service (et non en webservice). S’il est utilisé par un service processus ou un contrôleur, il est exposé en webservice. Il s’appuie sur des services d’exécution et d’exposition. Il effectue des transformations sur les services (sans composition) Service Exposition WebService s’appuyant sur des services (programmes, procédures stockées, etc…) existants. Il effectue des orchestrations de services, des transformations et gère la connectivité avec les applications Service Execution WebService s’appuyant sur des composants de gestion de données en base de données (type DAO) Règle paramétrable Moteur de règles Un moteur de règle permettant d’évaluer des règles suivant des paramètres modifiables via une interface graphique. Les règles son exécutées à partir de service de décision. EDF IVOIRE

Atelier 4 - conception logique SOA

Présentations similaires

Présentation au sujet: "Atelier 4 - conception logique SOA"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Atelier 4 - conception logique SOA

Présentations similaires

Présentation au sujet: "Atelier 4 - conception logique SOA"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back