La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

No. 121 May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les.

Présentations similaires


Présentation au sujet: "No. 121 May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les."— Transcription de la présentation:

1 No. 121 May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les principes SOA

2 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.

3 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. »

4 Definitions SOA S comme « service » : fonctionnalités rendues par une entité pour une autre afin datteindre un résultat donné. O comme « oriented » : façon de concevoir larchitecture pour permettre à un ensemble de services dinteragir afin de résoudre un problème métier A comme « architecture » : organisation dun système à travers ses fonctionnalités et ses interactions vis à vis de son environnement. SOA est donc avant tout un modèle darchitecture destiné à assurer linteropérabilité, lagilité et la réutililisabilité. SOA vise à accroître lagilité du SI et expose le SI sous la forme de services indépendants et réutilisables via des standards.

5 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.

6 Definitions SOA Activities Objectives Increase IT Investments ROI Improve Business Agility Improve Business knowledge Better align Business & IT Limit tactical-only approach to SOA (bottom-up) Adopt a Business Service design approach Design integration architecture without vendor lock-in Increase interoperability through standardized service contracts Increase service composition through orchestration Identify key value added processes and activities Develop & improve Business Modelling across silos Identify Business Services & related Business KPIs Improve Business Tasks Generosity Classify Business processes, activities & services SOA Value How to deliver the promises of SOA ? Increase IT assets reuse Adopt a standards based modelling approach (UML) Improve Analysis & Design Quality Define SOA standards & principles Improve reusability and extend the scope of services Build a Service Repository Improve architecture lifetime through better reuse Decrease the number of active systems Adopt open standards and mature open source solutions Adopt reliable agile project management methods Strengthen the governance of IT assets Decrease IT costs Principles and goals

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

8 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 limplémentation des service est opaque à ses consommateurs qui interagissent avec le service.

9 La granularité est un élément fondamental dans la réussite dune SOA car elle mesure la qualité et la réutilisabilité des services produits. La granularité est une mesure de la richesse fonctionnelle dun service. Plus la granularité est forte, et plus le service encapsule une liste importante de fonctionnalités. Par extension, la granularité métier mesure lagrégation de fonctionnalités et la capacité dun 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. Concept de granularité

10 AvantagesInconvénients Réutilisation facilePas de valeur ajoutée métier Performances Inintelligible pour les utilisateurs finaux No. 10 Comparaison AvantagesInconvénients Forte valeur ajoutéeRéutilisation délicate Performances Compréhensible par les utilisateurs. Faible granularité. Forte granularité

11 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 durbaniste : Ces services métiers très haut niveau qui souffrent du syndrome du neveu de Rameau (ou tour divoire): 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 No. 11 Les erreurs les plus fréquentes

12 Definitions Domaine métier Définition : ensemble de processus métier contribuant à une même mission au regard de lentreprise, 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. DOMAINE Sous-Domaine etc… Sous-Domaine Caractéristique majeure dun domaine : Forte cohésion interne et faible couplage avec les autres domaines. Ce découpage a pour objet de partitionner le métier de lentreprise en ensembles fortement cohérents communiquant entre eux avec un maximum de flexibilité.

13 Definitions Domaine métier Les domaines métier identifiés ne doivent pas dépendre de lorganisation interne de lentreprise. 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.

14 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 daccès aux informations du domaine

15 Definitions Les enjeux du découpage en domaines métier Service Domaine A DAO Service Application Service Domaine B DAO Service Application INTERDIT AUTORISE BDD

16 Applications monolythiques Les trois mondes et leur reliant D1DN Domaines métier ST Processus métier Systèmes de données Cas dutilisation DAO SE Tâche

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

18 Définitions : les services métier Service processus : Ce service correspond au processus métier de plus haut niveau orchestrant les différents cas dutilisation du processus métier. Service tâche : Un service tâche correspond à limplémentation dun cas dutilisation 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 Niveau de granularité croissant Degré de réutilisation croissant Ces services dits fonctionnels exécutent de la logique métier. Ils sont au nombre de trois :

19 Principes de conception logique SOA > Types de services de base No. 1921/05/2014Concepts et plates-formes SOA Service Tâche Service Utilitaire Service Processus Taux de réutilisation croissant Service Entité Remarque : Sans moteur dorchestration (ex : BPM), on ne peut espérer avoir une bonne SOA qui assure de la souplesse et de la réutilisabilité

20 Les services dits techniques exposent des fonctions élémentaires agnostiques vis-à-vis du contexte dexécution et du métier. Ces services sont souvent facilement réutilisables mais napportent pas de plus value métier réelle. Service médiation : Un service de médiation réalise ladaptation et la connectivité vers une fonction existante mais qui nest pas exposée telle quelle sous la forme dun service. Le service de médiation peut composer dautres 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 dutilisation. Les services les plus techniques

21 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 quils embarquent ; –le potentiel de réutilisation de leur logique ; –la manière dont leur logique est adhérente à des domaines pré existants dans lentreprise Nous dénombrons 4 types de services primaires : –Le Service de type Processus, un service qui encapsule la logique dun 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. No May 2014Atelier 4 - conception logique SOA

22 Principes de conception logique SOA > Composition entre types de services No. 2221/05/2014Concepts et plates-formes SOA Consommateur de Service Service Médiation Service Processus Service TâcheService EntitéService Utilitaire Service Processus AUTORISENON AUTORISE Service Tâche AUTORISEAUTORISE 1 NON AUTORISE Service Entité AUTORISE NON AUTORISE Service Utilitaire AUTORISE AUTORISE 1 1 Seulement au sein dun même domaine métier La relation entre un consommateur de service et un fournisseur de service (service concret) doit impérativement passer par un service Médiation.

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

24 No May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les principes SOA

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

26 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 lalignement des processus métier cible avec ces objectifs Analyste métier : Réalise les modèles métier Modèle de processus métier Modèle de Domaine métier (entités métier) Domaines fonctionnels impactés Objectifs métier La discipline de modélisation métier dans GO-ON

27 Modélisation métier – Livrables Définition hiérarchique des objectifs métier du projet Modélisation hiérarchique des fonctions (métiers) de lentreprise (synonyme de plan durbanisme 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 lentreprise (uniquement sur le périmètre du projet), leurs états et règles métier. Modèle de processus métier Modèle de Domaine métier (entités métier) Domaines fonctionnels impactés Objectifs métier

28 No. 28 Traçabilité de la tâche du processus au cas dutilisation (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 lidentifions à laide 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 lorganisme : La tâche doit avoir une valeur ajoutée pour lentreprise, 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é dune unique unité organisationnelle. –Uniformité daction : La logique et le séquencement de la tâche ne doivent pas être impactés par un éventuel changement de ses circonstances dutilisation. Si les circonstances dutilisation exigent des façons totalement différentes de procéder, il est alors nécessaire de définir plus dune 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 dautomatisation

29 Traçabilité de la tâche du processus au cas dutilisation (2/2) Méthodologie GO-ON Notre méthodologie préconise un approche par les cas dutilisation (use case driven), conformément à UP quelle intègre. Un Use Case est une séquence de transactions avec un système dont lobjectif est de produire un résultat mesurable pour un acteur particulier (Ivar Jacobson). Daprès Craig Larman (référence mondiale en modélisation UML), un cas dutilisation 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 dassocier à une tâche automatisable (interactive ou entièrement automatisée) dun processus métier un cas dutilisation du modèle danalyse, en assurant ainsi la traçabilité entre les vues « métier » et « exigences » ! Use case y Use case z

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

31 Traçabilité de lobjet métier au « service entité » Méthodologie GO-ON Nous assurerons la traçabilité du modèle des objets métier (MOM) venant de la pure modélisation métier au modèle danalyse UML des classes du système. Nous avons à ce sujet des règles déjà définies pour projecter le MOM dans loutil de modélisation UML. Ainsi, la première itération du modèle danalyse dans RSA serait directement produite depuis ce modèle des objets métier. Les modèles de classes danalyse et de conception ont néanmoins vocation dêtre raffinés pour les besoins dun projet (et aussi : application de patterns danalyse, 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é

32 Méthodologie GO-ON

33 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 !

34 Démarche classique Diagramme de classes global Description textuelle

35 Exemples Diagramme de séquence système du UC « Gérer son panier » 1.LInternaute enregistre les ouvrages lintéressant dans un panier virtuel (voir UC Rechercher des ouvrages). 2. 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 darticles. 3. LInternaute continue ses achats (voir UC Rechercher des ouvrages). Extensions : 2.a : Le panier est vide Le système affiche message derreur («Votre panier est vide») et lui propose de revenir à une recherche douvrage (voir le cas dutilisation Chercher des ouvrages). 4.a : Lacteur modifie ou supprime les quantités des lignes. Il revalide le panier en demandant la mise à jour du panier Le cas dutilisation reprend à létape 2 du scénario nominal. 4.b : LInternaute demande devis pour commander par courrier. Système : fournit devis imprimable à joindre au règlement récapitulant commande et total à payer. 4.c : LInternaute souhaite commander en ligne 1. Le Système lamène sur la page didentification 2a. LInternaute sidentifie en tant que client (voir UC Sauthentifier) 2b. LInternaute visiteur demande à créer un compte client (voir le cas dutilisation « Créer un compte client » ) Description textuelle du UC « Gérer son panier »

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

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

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

39 Exemple de modèle danalyse : diagramme de séquence Diagramme dinteraction (séquence) du Use Case « Gérer son panier »

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

41 Diagramme de séquence type :

42 Exemple de modèle danalyse : diagramme de classes Gestion de panier virtuel sur le site amazon.fr

43 Exemple de modèle danalyse : diagramme de séquence Gestion de panier virtuel sur le site amazon.fr

44 Constitution des vues statiques et dynamiques Statique Dynamique Lanalyste ou le concepteur se sert de la spécification des services pour valider et affiner les diagrammes de classes et vice versa. Cest par litération continue quon 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.

45 Identification des services Démarche de conception Services candidats Services validés La phase didentification des services est assurée en amont lors de la phase danalyse 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.

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

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

48 No May 2014Atelier 5 - conception logicielle SOA Exemple sur un cas métier concret : > Lien Classes & Services entité

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

50 No May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les principes SOA

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

52 Patterns danalyse 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.

53 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

54 Patterns : GRASP Faible couplage Il sagit plus dun principe dappréciation quun 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é dun système qui a été décomposé en un ensemble de modules cohésifs et faiblement couplés.

55 Patterns : GRASP Forte Cohesion Comment concevoir les classes de façon à augmenter leur réutilisabilité sans quelles 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) dune 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

56 Patterns : GRASP Expert 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)

57 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

58 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 !

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

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

61 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

62 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…

63 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)

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

65 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.

66 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 dune application toujours élevé puisqu'il faut repartir de zéro à chaque fois. La viscosité : terme employé par Martin pour exprimer deux concepts sur lenvironnement & 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 dun logiciel est longue, les développeurs préfèrent ne remplacer quune petite partie sans préserver la cohérence du code de depart.

67 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 à leffet « 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

68 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."

69 Les dix principes fondamentaux de conception objet (2/3) 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."

70 Les dix principes fondamentaux de conception objet (3/3) 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é."

71 Les design principles : exemples Principes fondamentaux de conception OCP : exemple Figure +surface() Circle +surface() Square +surface() EnsembleFigures +calculerSurfaces( ) * public void calculerSurface() { for each Figure f in the Set f.surface(); } 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 à lajout de nouvelles formes. +surface()

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

73 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.

74 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

75 The meta-class pattern : If a given class Class has too much responsibilities, and some dont 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.

76 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.

77 The Entity-Role pattern : 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. 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.

78 No May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les principes SOA

79 Principes de conception logique SOA No May 2014Atelier 4 - conception logique SOA 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 Après avoir fait lanalyse et la modélisation des services au niveau logique, on prend en compte les 8 SOA design principles. Remarque : 4 de ces principes sont orientés build, 4 sont orientés run

80 > 1 – Expose un contrat de service standard Les services expriment leur but et leurs capacités au travers dun 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é dinformation 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 sassurer que les points daccè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. No May 2014Atelier 4 - conception logique SOA 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 darchiver dans un CENTRASITE (par exemple).

81 > 2 - Autonomie Lautonomie, quand on parle de logiciel, représente lindé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. Pour quun service puisse être implémenté de manière fiable et consistante, il doit posséder un niveau de contrôle suffisant sur son environnement dexécution et les ressources quil utilise. Ce principe repose sur lindépendance du service vis-à-vis des autres services et par rapport à son environnement dexécution. Son niveau disolation et de normalisation sont pris en compte pour atteindre les objectifs dautonomie nécessaires (notamment pour les services fréquemment réutilisés) No May 2014Atelier 4 - conception logique SOA

82 > 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 à linté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 lindé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, limplémentation de la logique du service avec un vendeur particulier, le consommateur et limplémentation du service No May 2014Atelier 4 - conception logique SOA

83 > 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 à lorigine. 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. No May 2014Atelier 4 - conception logique SOA

84 > 5 – Se réutilise La réutilisation est fortement encouragée dans une architecture SOA et fait partie du processus danalyse 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. No May 2014Atelier 4 - conception logique SOA 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 dutilisation, (donc tâche dun processus). Un secret : se poser le problème de la réutilisabilité de lacteur. 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 quon a ici de la réutilisabilité & de la généricité (ce genre de raisonnement a souvent déjà été fait côté DRH).

85 > 6 – Se Découvre Si lon 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 lutilisation 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 lexécution, le service doit aussi pouvoir être découvert dynamiquement afin dassurer sa transparence daccès. No May 2014Atelier 4 - conception logique SOA

86 > 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. No May 2014Atelier 4 - conception logique SOA

87 > 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 dun service et assure une consommation raisonnée de ressources pour son exécution. No May 2014Atelier 4 - conception logique SOA

88 Principes de conception logique SOA > Principes structurants du modèle de conception Le modèle de conception contient les actifs IT réels de lentreprise : cest le modèle le plus pérenne qui doit être maintenu à jour impérativement. Le modèle de conception nest pas le détail du modèle danalyse mais bien un modèle disjoint qui utilise des règles bien précises pour transformer les concepts issus de lanalyse en conception. Remarque fondamentale : On fait la différence (dans GO-ON) entre lidentification dun service (qui est de lordre de la méthodologie) et le fait de décider de limplémenter en tant que service. Cest un choix darchitecture (prenant en compte les performances, les contraintes de larchitecture…), dautant que cela est difficile à développer. No May 2014Atelier 4 - conception logique SOA

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

90 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) Interactions entre composants logiques pour une interaction utilisateur/Système Contrôleur applicatif Service tache Service entité Legacy wrapper Service Enablement Legacy wrapper Service Enablement Service Exécution Si existants BDD IHM Client DAO

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

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

93 Activité des composants logiciels EDF IVOIRE Composant logique Ex. composant logiciel Description IHMPage JSPGestion des écrans utilisateurs ContrôleurEJBGestion des enchainements décrans utilisateurs, de la session utilisateur, des appels aux services Service processus Moteur BPMGestion de processus long, corbeille de tâches, déclenchement par un évènement Service tâcheWebServiceWebService de médiation sappuyant sur des services entité et des services dexposition. Il effectue des transformations et de la composition de service. Service EntitéWebService Service Lorsque le service entité est utilisé uniquement par des services taches, il peut être exposé en service (et non en webservice). Sil est utilisé par un service processus ou un contrôleur, il est exposé en webservice. Il sappuie sur des services dexécution et dexposition. Il effectue des transformations sur les services (sans composition) Service Exposition WebServiceWebService sappuyant 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 WebServiceWebService sappuyant 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.


Télécharger ppt "No. 121 May 2014Atelier 4 - conception logique SOA Agenda Introduction Du métier aux services Raffiner et optimiser les modèles UML : les patterns Les."

Présentations similaires


Annonces Google