no. 121 may 2014atelier 4 - conception logique soa agenda introduction du métier aux services...

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.


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


Agenda

Introduction



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


Opérations métiers




Démarche : ajout de la dimension « Architecture métier »

Entités Métier

Règles métier


(ex : ARIS)

Processus métiers



(ex : ARIS)



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



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»


Agenda

Introduction



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.


Agenda

Introduction



Les principes SOA

Principes de conception logique SOA


Après avoir fait l’analyse et la modélisation des services au niveau logique, on prend en compte les 8 SOA design principles.

Remarque : 4 de ces principes sont orientés build, 4 sont orientés run

> 1 – Expose un contrat de service standard


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


XX

> 3 – Couplage lâche


> 4 – Se compose


> 5 – Se réutilise


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


?

> 7 - Communique par messages standards


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


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.


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



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



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



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.

no. 121 may 2014atelier 4 - conception logique soa agenda introduction du métier aux services...

Documents