No .111 April 2023 Atelier 4 - conception logique SOA
Agenda
Introduction
Du métier aux services
Raffiner et optimiser les modèles UML : les patterns
Les principes SOA
Definitions
DefinitionsSOA
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.
Definitions
DefinitionsSOA
« 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. »
Definitions
DefinitionsSOA
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.
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.
Definitions
SOAIncrease IT
Investments ROI
Improve Business
Agility
Improve Business
knowledge
Improve Business
knowledge
Better align Business & IT
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 KPI’s
Improve Business Tasks Generosity
Classify Business processes, activities
& services
SOA ValueHow to deliver the promises of SOA ?
Increase IT assets reuse
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
Decrease IT costs
Principles and goals
Les retours d’expériences SOA : importance d’une méthode EA/SOA
Accroitre le ROI des Accroitre le ROI des investissements ITinvestissements IT
Accroitre l’AgilitéAccroitre l’Agilitédes Organisationsdes Organisations
Accroitre la Accroitre la réutilisation des réutilisation des
Assets ITAssets IT
Réduire le gâchisRéduire le gâchisdes dépenses ITdes dépenses IT
Accroitre laAccroitre laConnaissance duConnaissance du
MétierMétier
Accroitre l’alignementAccroitre l’alignementdes activités Métiersdes activités Métiers
et des services ITet des services IT
Adopter une approchepar les modèles en UML
Accroitre la qualitédes phases d’analyse
et conception
Définir desPrincipes et Standards
pour la SOA
Accroitre la généricitéet la couverture
des services
Disposer d’unRéférentiel de Services
Augmenter la duréede vie de l’architecture
Réduire la taille du parcapplicatif
Adopter des standardsouverts et des technologies
Open-source matures
Adopter des méthodesde Gestion de Projet
Agiles et Rigoureuses
Renforcer la gouvernance des Assetssur tout leur cycle de vie
Réduire une démarched’intégration (bottom-up)
tactique du Legacy
Adopter une démarchede conception (top-down)par les services métiers
Adopter une architectured’intégration non liée à
une solution éditeur
Accroitre l’interopérabilité
en standardisant
les contrats de service
Accroitre les compositionsde services par de
l’orchestration
Identifier les processus et activités
à valeurs ajoutées
Accroitre la Modélisation du Métier
Identifier les servicesMétiers et indicateurs
Qualité et de Performance
Renforcer la généricitédes services et étendre
les conditions d’utilisation
Référencer les processus,activités et services
Métiers
Les Gains de laLes Gains de la
SOASOA
Ob
ject
ifs
Ob
ject
ifs
Pra
tiq
ues
Ter
rain
Pra
tiq
ues
Ter
rain
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.”
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.
Concept de granularité
Avantages Inconvénients
Réutilisation facile Pas de valeur ajoutée métier
Performances
Inintelligible pour les utilisateurs finaux
No .10
Comparaison
Avantages Inconvénients
Forte valeur ajoutée Réutilisation délicate
Performances
Compréhensible par les utilisateurs
. Faible granularité
. Forte granularité
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
No .11
Les erreurs les plus fréquentes
Definitions
DefinitionsDomaine métier
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.
DOMAINE
Sous-Domaine
etc…
Sous-Domaine
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é.
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.
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
Definitions
Les enjeux du découpage en domaines métier
Service
Domaine A
DAO
Service
ApplicationApplication
Service
Domaine B
DAO
Service
ApplicationApplicationINTERDIT
AUTORISE
BDD
BDD
Applications monolythiques
Les trois mondes et leur reliant
D1 DN
Domaines métier
ST
Processus métier
Systèmes de données
Cas d’utilisation
DAO
SE
Tâche
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
Objectifsstratégiques
Indicateurs
Processus métiers
Procédures, Acteurs
Opérations métiers
Cas d’utilisation
Règles organisationnelles
Entités Métier
Règles métier
Architecture de SI
Applications
dérivation
Services
entité
Services
tâcheProcessus
OK
IHMTypes compl.
messagesRègles
métier
Expression du besoin
Spécifications textuelles
MLD
Tables relations
dérivation
Architecture de SI
Exigences
Médiations
Couche processus Couche métierCouche présentation
dérivation dérivation
dérivation
Lorem ipsum
Lorem ipsum
Lorem ipsum
Fonctions
Architecture de SI
Données
Exigences
non fonctionnelles
OK
Maquette de l’IHM
Champs, actions
dérivation
dérivation
Définitions : les services métier
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
Ces services dits fonctionnels exécutent de la logique métier. Ils sont au nombre de trois :
Principes de conception logique SOA > Types de services de base
No .1911/04/23 Concepts et plates-formes SOA
Service TâcheService Tâche
Service UtilitaireService Utilitaire
Service ProcessusService Processus
Ta
ux
de
ré
uti
lis
ati
on
cro
iss
an
t
uc Process
Service Entité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é
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.
Les services les plus techniques
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.
No .2111 April 2023 Atelier 4 - conception logique SOA
Principes de conception logique SOA > Composition entre types de services
No .2211/04/23 Concepts et plates-formes SOA
Consommateur de ServiceConsommateur de Service Service MédiationService Médiation Service ProcessusService Processus
Service Processus Service Tâche Service Entité Service Utilitaire
Service Processus AUTORISE NON AUTORISE NON AUTORISE NON AUTORISE
Service Tâche AUTORISE AUTORISE1 NON AUTORISE NON AUTORISE
Service Entité AUTORISE AUTORISE NON AUTORISE NON AUTORISE
Service Utilitaire AUTORISE AUTORISE AUTORISE AUTORISE1
1 Seulement au sein d’un 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.
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âcheMédiations
Couche présentation
Couche
processus
Couche
métier
BDDDAO
BDDDAORègles
métier
Règles
métier
Règles
organisation
Module C
Legacy
No .2411 April 2023 Atelier 4 - conception logique SOA
Agenda
Introduction
Du métier aux services
Raffiner et optimiser les modèles UML : les patterns
Les principes SOA
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
Modèle de
processus métier
Modèle de
Domaine métier
(entités métier)
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Domaines fonctionnels
impactés
Objectifs métier
La discipline de modélisation métier dans GO-ON
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.
Modèle de
processus métier
Modèle de
Domaine métier
(entités métier)
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Domaines fonctionnels
impactés
Objectifs métier
No. 28
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
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
No. 30
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
Services
tâche
control
Traçabilité de l’objet 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 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 !
Démarche classique
Diagramme de classes global
Description textuelle
Exemples
Diagramme de séquence système du UC « Gérer son panier »
1. L’Internaute enregistre les ouvrages l’inté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 d’articles.
3. 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 panierLe 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 ligne1. Le Système l’amène sur la page d’identification2a. 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 »)
Description textuelle du UC « Gérer son panier »
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
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 modele
r
UML modeler (ex : RSA)
Exemples
Diagramme de classes du domaine ou MOM (Modèle Objets Métier)
Diagramme de classes participantes 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
Coucheprésentation
Coucheapplicative
Couchemé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 encapsulerle contrôle lié à un UC.
<<entity>> : classes servant à modéliser des informations durables et souvent persistantes
Ex : Compte
Diagramme de séquence type :
entity1controlboundary
Acteur
entity2
operation metier
operation metier traitement applicatif
action IHM
Exemple de modèle d’analyse : diagramme de classes
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
1. Identifier classes
2. Identifier associations
3. Identifier attributs4. Identifier opérations
5. Valider et affiner modèle
Statique
1. Lister scénarios
2. Formaliser scénarios
3. Automates
4. Spécifier services
5. Affiner services
6. Valider
Dynamique
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 »
Services
entité
Services
tâche
Tables relations
OK
IHM
Description textuelle
Diagramme de classes global
SOA
Méta modèle de GO-ON : lien entre analyse UML & SOA
No .4811 April 2023 Atelier 5 - conception logicielle SOA
class Modèle d'entités Meti...
Marketing
Client
- identifiantCRM: char
+ rechercherDossier()
Dossier
- dateMiseEnService: date- dateValidation: date- identifiantPropositionSIMM: int
+ controlerCompletude()+ controlerDateMiseEnService()+ controlerOperationnalite()+ valider()
Internaute
- login: char- Nom: char- Prenom: int
Prospect
«Service Entité»Serv ice Prospect
+ enregistrer()+ rechercheParID()+ rechercherParTexte()
«Service Entité»Serv ice Client
+ creerClient()+ enregistrer()+ rechercherDossiers()+ rechercherParID()+ rechercherParTexte()+ recupererInformationClient()
«Service Entité»Serv ice Dossier
+ controlerCompletude()+ controlerDtaeMiseEnservice()+ controlerOperationnalite()+ creerDossier()+ enregistrer()+ rechercherParID()+ recupererDonneesDossier()+ valider()
1 *
Exemple sur un cas métier concret : > Lien Classes & Services entité
Exemple sur un cas métier concret : > Lien Use case & Services tâches
uc Use Case Model
Instruire demande de mise en serv ice
Valider propositionSouscrire à la mensualisation
Compléter dossier
«Service Tâche»Logical model::Serv ice
Valider Proposition
+ validerProposition() : int
«Service Tâche»Logical model::Serv ice Mise En
Serv ice
+ contrôlerAuthentification() : void+ contrôlerDateMiseEnService() : void+ validerDossier() : void+ vérifierExistenceDossier() : void
«Service Tâche»Serv ice Compléter
dossier
«Service Tâche»Serv ice Sourcrire à La mensualisation
«extend»«extend»
«include»
No .5011 April 2023 Atelier 4 - conception logique SOA
Agenda
Introduction
Du métier aux services
Raffiner et optimiser les modèles UML : les patterns
Les principes SOA
SOA Analyst – Service Analysis & Modelling Tasks List
No .5111 April 2023 HGA Review November 2008
2. Identify Target Domains
4. Identify Business Processes
3. Review Business Domain/Syst Objectives
Bu
sin
ess
Arc
hit
ectu
re V
iew
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
Req
uire
men
ts Vie
w
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 A
pp
lication
& D
ata 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 System Specify GUI/Workflow
25. Identify Atomic Services
27. Identify Processes as a Service
26. IdentifyService Composition
28. Identify Composite Appli. Part as a Service
Apply Agile Modelling Identify Existing Assets Identify Candidate Services Specify Services
29. SpecifyAtomic Services
31. Specify Processes as a Service
30. Specify Service Composition
32. Specify Composite Appli. Part as a Service
No. 5111 April 2023 HGA EA-SOA - Enterprise Methodology - 2009
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.
Patterns : GRASP
The GRASP : General Responsibility Assignment Software Patterns
1. Faible couplage2. Forte Cohesion3. Expert4. Createur5. Controleur6. Polymorphisme7. Pure Fabrication8. Indirection9. Protection des Variations
Craig Larman
Patterns : GRASP
Faible couplageIl 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.
Patterns : GRASP
Forte CohesionComment 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
Patterns : GRASP
ExpertThe 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)
Patterns : GRASP
CreatorWho 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
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 !
Patterns : GRASP
Controller
Domain Objects
Controller
onClick() UI
borrowResource()
Patterns : GRASP
Polymorphism
4. stop()
3. s
top
()2. s
top(
)
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
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…
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)
Patterns : Relations between the GRASPs & the 10 design principles
Management of the application stability
Management of the evolutions & dependences between classes
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.
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.
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
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 demodules de bas niveau. Tous deux doivent dépendre d'abstractions ». « B. Les abstractions ne doivent pas dépendre de détails. Les détailsdoivent 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."
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."
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é."
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 à l’ajout de nouvelles formes.+surface()
Les design principles : exemples
LSP : exemple
Quadralateral
+ getHeight() : int+ getWidth() : int
<<Interface>>
Rectangle
- height : int- width : int
+ setHeight(h : int) : void+ setWidth(w : int) : void
Square
- side : int
+ setSide(s : int) : void+ getSide() : int
Non-conforme ConformeRectangle
- height : int- width : int
+ setHeight(h : int) : void+ setWidth(w : int) : void+ getHeight() : int+ getWidth() : int
Square
+ setSide(s : int) : void+ getSide() : int+ setHeight(h : int) : void+ setWidth(w : int) : void 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); } }
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 :
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.
No .7811 April 2023 Atelier 4 - conception logique SOA
Agenda
Introduction
Du métier aux services
Raffiner et optimiser les modèles UML : les patterns
Les principes SOA
Principes de conception logique SOA
No .7911 April 2023 Atelier 4 - 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.
Remarque : 4 de ces principes sont orientés build, 4 sont orientés run
> 1 – Expose un contrat de service standard
No .8011 April 2023 Atelier 4 - conception logique SOA
Service Contract
Technical web service contract
WSDL XMLSchema
WSPolicy
ServiceLevelAgreement(SLA)
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).
> 2 - Autonomie
No .8111 April 2023 Atelier 4 - conception logique SOA
XX
> 3 – Couplage lâche
No .8211 April 2023 Atelier 4 - conception logique SOA
> 4 – Se compose
No .8311 April 2023 Atelier 4 - conception logique SOA
> 5 – Se réutilise
No .8411 April 2023 Atelier 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 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).
> 6 – Se Découvre
No .8511 April 2023 Atelier 4 - conception logique SOA
?
> 7 - Communique par messages standards
No .8611 April 2023 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.
No .8711 April 2023 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.
No .8811 April 2023 Atelier 4 - conception logique SOA
Type d’environnement d’exécution
Référentiel
SOA
Référentiel
SOA
Passerelle B2BPasserelle B2BCAFCAF
MédiateurMédiateur
BPMBPM
ESBESB Exécution ServiceExécution Service
Base de donnéesBase de données
Webmethods BPMWebmethods BPMWeblogic PortalWeblogic Portal
IntegrationServerIntegrationServer
SoftwareAG
Centrasite
SoftwareAG
Centrasite
IntegrationServerIntegrationServer
Weblogic ServerWeblogic Server
OracleOracle
Si existantsSi existants
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 applicatifContrôleur applicatif
Service tacheService tache
Service entitéService entité
Legacy wrapper
Service Enablement
Legacy wrapper
Service Enablement Service ExécutionService Exécution
Si existantsSi existants BDDBDD
IHMIHM
uc Acteurs
Client
DAODAO
WL
IW
LI
webMethods MediatorwebMethods Mediator
Weblogic ServerWeblogic Server
WA
SW
AS
webMethods ESB+MediatorwebMethods ESB+Mediator
webMethods BPMwebMethods BPM
Weblogic PortalWeblogic Portal
Exemple d’environnement d’exécution possible
EDF IVOIRE
Co
ntr
ôle
ur
Co
ntr
ôle
ur
Service TâcheService Tâche
Service EntitéService Entité
Ser
vice
Exp
osi
tio
nS
ervi
ce E
xpo
siti
on
Service ExecutionService Execution
SI existantSI existant
BDD BDD
SI existantSI existant
IHM
IHM
uc Acteurs
Utilisateur
Service ProcessusService Processus
AEL SIMMAEL SIMM
PF multi-canalPF multi-canal SIMM / 3SSIMM / 3S
A définir?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)
Exemple d’environnement d’exécution possible
EDF IVOIRE
Co
ntr
ôle
ur
Co
ntr
ôle
ur
Service TâcheService Tâche
Service EntitéService Entité
Ser
vice
Exp
osi
tio
nS
ervi
ce E
xpo
siti
on
Service ExecutionService Execution
SIMMSIMM
BDD IVOIREBDD
IVOIRE
3S3S
IHM
IHM
uc Acteurs
Utilisateur
Service ProcessusService ProcessusPage JSPPage JSP
EJBEJB
Moteur de BPMMoteur de BPM
WebserviceWebservice
Service & WebserviceService &
Webservice
WebserviceWebservice
WebserviceWebservice
Règles paramétrables
Règles paramétrables
Règles organisationnelle
Règles organisationnelle
Règles métierRègles métier
Moteur de règleMoteur de règle
Activité des composants logiciels
EDF IVOIRE
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é WebServiceService
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 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 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.