04 –Architecture du SI : identifier, décrire et structurer les servicess3.e-monsite.com/2010/10/24/902050392010-cm-ursisoa-04... · 2010. 10. 24. · Urbanisation et SOA se rapprochent

Architecture d’Entreprise et des

Systèmes d’Information

04 – Architecture du SI : identifier, décrire

et structurer les services

Master Informatique et Systèmes

Philippe Declercq 2010-2011Architecture d’Entreprise et des Systèmes d’Information – Architecture du SI 2 Philippe Declercq

Plan du chapitre

L’architecture fonctionnelle du SI1

Concepts et représentation4

Règles et pattern d’architecture fonctionnelle2

L’approche « services » pour urbaniser le SI3

MDA5

Architecture d’Entreprise et des Systèmes d’Information – Architecture du SI 3 Philippe Declercq

Références

� [1] : Le projet d’Urbanisation du SI, Christophe Longépé, édition Dunod

� [2] : Livre orange « Urbanisation et intégration de Systèmes », Valtech

� [3] : SOA – Architecture logique, Softeam� [4] : Architecture Orientée Services (SOA), une politique de

l’interopérabilité, OCTO� [5] : Architecture de Systèmes d’Information, livre blanc, OCTO� [6] : Urbanisation et SOA, SOPRA� [7] : Urbanisation et SOA, quelques bonnes pratiques pour leur

mise en œuvre, AUBAY


1

L’architecture fonctionnelle du SI



� Les processus métier d’un domaine ou de l’entreprise étant décrit, le Système d’Information doit permettre de réaliser ces processus.

� Démarches d’urbanisation : réorganiser le Système d’Information en structurant ses fonctions dans des blocs fonctionnels communicants.

� Démarches SOA : réorganiser le Système Informatique en structurant celui-ci en services.

� Urbanisation et SOA se rapprochent en considérant que l’élément de base d’un bloc fonctionnel est le service.



� Comment passer d’un Système construit sur des applications monolithiques (« en silo »), sur un système « Plat de spaghetti » à un Système urbanisé ?



� Comment structurer le futur Système ? Quelles applications construire ?

� Quelques pistes : � Tout n’est pas dans tout ! � Regrouper ce qui est/semble proche� Identifier ce qui est commun à plusieurs/tous les métiers� …



� La solution : identifier les fonctions du Système d’Information et les « ranger » dans des blocs fonctionnels.

� Construire un plan d’urbanisme ou une architecture fonctionnelle cible

� Exemple : Interfaces et CommunicationInterfaces et Communication Gestion des

Droits d’Accès

Gestion des

Droits d’Accès

Production ou

Liquidation des

Prestations

Production ou

Liquidation des

Prestations

AdministrationAdministration

Accéder les RéférentielsAccéder les Référentiels

RestituerRestituer

SuperviserSuperviser ArchiverArchiver

Identifier /

Authentifier

Identifier /

Authentifier

RecevoirRecevoir

HabiliterHabiliter

EchangesInternes

EchangesInternes

RouterRouter

Gestion des TiersGestion

des TiersGestion / Régulationde l’Offre de Soins

Gestion / Régulationde l’Offre de Soins

Gestion des

Services

Gestion des

Services

ComptabilitéComptabilité Informationnel / Statistique

Informationnel / Statistique

Gestion des Ressources

et des Moyens

Gestion des Ressources

et des Moyens



� Fonction : action d’un produit ou de l’un de ses constituants exprimée exclusivement en termes de finalité (NF X 50-150)

� Quelques règles :� une fonction est formulée par un verbe à l’infinitif suivi

d’un ou plusieurs compléments.� la formulation de la fonction doit être indépendante des

solutions de la réaliser.

� Exemples : contrôler une facture, calculer une plus-value, archiver un dossier, authentifier un utilisateur, …



� L’architecture fonctionnelle est une représentation du Système d’Information qui doit garder une (relative) indépendance par rapport aux technologies.

� Horizon urbanisation = long terme � stabilité par rapport aux évolutions des technologies.



� Exemple : à partir d’un objectif stratégique : Faire rire !



� Décrire le(s) processus :

1 - SALUER

3 - METTRE LA TÊTEDANS LA GUEULE

2 - TOURNER

4- S'ECHAPPER



� Identifier les fonctions qui supportent le(s) processus

TOURNER

ENTRAÎNER

TRANSFORMER

TRANSFORMER

ALLER& VENIR

ALLER& VENIR


2

Les règles et pattern d’architecture fonctionnelle



� Vision de Longépé ([1])

� 3 types de blocs fonctionnels : zone, quartier, îlot.� Zone : 1er niveau de découpage du SI.� Quartier : regroupement de composants homogènes

quant à la nature de l’information traitée.� Îlot : entité remplaçable du SI, correspondant à une

finalité fonctionnelle et comprenant des traitements et des accès à des données pour cette finalité.

Zone

Quartier

Îlot



� Les règles d’urbanisme de Longépé ([1]) :► R1 : Règle d’unicité des blocs fonctionnels► R2 : Règle d’asynchronisme des îlots► R3 : Un bloc comporte obligatoirement une prise► R4 : Toute communication entrante ou sortante d’un bloc

passe par sa prise► R5 : Seules les prises communiquent avec le gestionnaire

de flux► R6 : Une donnée est sous la responsabilité d’un îlot et

d’un seul Zone

Quartier

Îlot



� D’après Longépé [1], un Système d’Information doit comporter au moins les zones suivantes :� une zone d’échange (la prise du SI),� une zone gisement de données,� une zone référentiel de données,� une zone pilotage unique,� une zone opération par métier principal de l’entreprise,� une zone ressource unique.



� Les pattern d’architecture fonctionnelle d’OCTO ([5]) :� Le pattern Royaume-Emissaire� Le pattern NOYAU� Le pattern Référentiel

� Autres pattern de OCTO ([4]) :� Modélisation document� Processus implicite/explicite� Agrégation IHM



� Zoom sur la zone référentiel, une zone primordiale et prioritaire dans la mise en œuvre de l’urbanisation.

� Définitions : référentiel de données :► Ensemble structuré d'informations, utilisé pour l'exécution d'un

logiciel, et constituant un cadre commun à plusieurs applications.► Ensemble cohérent de données ayant une définition sémantique

commune et répondant au besoin de langage commun entre plusieurs acteurs appartenant à des entités organisationnelles différentes ou à une même entité

� Le besoin de gérer des données de référence provient souvent d’une situation où plusieurs ensemble de données co-existent et où leur multiplicité pose des problèmes de cohérence.



� L’existence de plusieurs bases de données relatives à un même ensemble d’information se heurte, plus ou moins tôt, à un ensemble de problèmes critiques :► Conflit d’identité. Le même objet possède des identités différentes

selon les sources de données. (ex : le client X est identifié par la clé X1 dans un référentiel et X2 dans un autre).

► Conflit de schémas. Le même concept est modélisé de manière différente (ex : le client est modélisé par le champ « customer » d’un coté, et par les deux champs « nom » et « prénom» par ailleurs.

► Conflit sémantique. Le même terme est interprété de manières différentes (ex : un « compte » est un compte courant bancaire dans une application et un identifiant utilisateur permettant de gérer la sécurité des accès pour une autre.

► Conflit de valeur. Le même objet a des valeurs différentes selon les sources (ex : la balance d’un compte courant apparaît différentesuivant les bases dans lesquelles on le consulte).



► Redondance de valeur. Le même concept est dupliqué dans plusieurs applications indépendantes (ex : le tarif catalogue des produits est représenté par N bases avec des recoupements sur certaines catégories de produits).

► Plus grande complexité du SI à assurer la sécurité, en ce qui concerne les habilitations. Dans une configuration de redondance de valeur, le cas classique est d’interdire l’accès à une donnée dans telle base en oubliant d’en interdire l’accès dans telle autre.

► Plus grande complexité du SI à assurer les mises à jour. Dans une configuration de redondance de valeur, nécessité de mettre à jour toutes les bases ou fichiers contenant cette donnée via des passerelles compliquées entre les différentes sources de données.



� Exemple d’acteurs liés aux référentiels :

Référentielbénéficiaires

Mise à jour

Création

Acteur(s) chargéde la création / mise à jour(acteur métier, ou dédié)

Flux externes

Liquidation Service Médical Gestion de dossiersmédico-

administratifs

Gestion des contrats

Services de consultation du référentiel

Données de références / procédures / services

Utilisateurs

InitiateursSous la responsabilité des

GestionnairesContrôleur

Mise à jourMise à jour



� Les référentiels les plus courants au sein des SI :► Référentiels clients,► Référentiels des nomenclatures,► Référentiels des produits,► Référentiel de l’organisation,► Référentiel de sécurité,► Référentiel des règles métier.


Étude de cas : Architecture d’Entreprise

� Étude de cas : MyBestCar

� L’objectif de l’étude de cas est de proposer une architecture d’entreprise de MyBestCar, et un système d’information cible conçu selon une architecture orientée services.

� Travaux à réaliser : Proposer une architecture fonctionnelle pour le Système d’Information de l’entreprise► Étape 3.1


3

L’approche « service » pour urbaniser le SI


L’approche « services » pour urbaniser le SI

� Dans une vision « services » du SI, la brique de base pour construire le SI est le service.

� Les architectures fonctionnelles, applicatives, techniques peuvent intégrer ce nouveau paradigme.



Vision Sopra

Vision Valtech



� Exemples de méta-modèles de la couche fonctionnelle, à base de services :

TOURNER

ENTRAÎNER

TRANSFORMER

TRANSFORMER

ALLER& VENIR

ALLER& VENIR

Cas d’utilisation

Service fonctionnel

Information

Analyse fonctionnelle

Un cas d’utilisation orchestre des

services1..n

Un cas d’utilisation manipuleDes informations

1..n

Cycle de vie des informations

Un Objet de gestion est décrit par un cycle de vie0..1

0..1

0..n0..n



Mais au fait ….

Qu’est ce qu’un service ?

Qu’est ce qu’une architecture orientée service (SOA) ?



� Service : traitement normalisé, mutualisé et référencé au sein de l’entreprise, dont l’interface d’appel est décrite dans un langage neutre (indépendant des technologies), et qui est déployé physiquement sur un serveur ([2]).

� L’interface d’appel d’un service est constituée de 1 à n opérations qui constituent les traitements élémentaires et atomiques proposés par le service.

� Chaque service expose des opérations dont les paramètres sont définis par des classes d’objets pivots.



� Représentation externe/interne d’un service :



� Contrat de service : chaque service est défini selon un contrat, établissant les règles d’usage du service.

� Un contrat de service spécifie un contrat d’interface et une qualité de service attendue et admise par les parties prenantes :► Le contrat d’interface caractérise les conditions d’utilisation et

garantit un service sans état à des fins de mutualisation (type de traitement, données d’entrée et données de sortie, contraintes de sécurité).

► La qualité de service porte sur la disponibilité (éventuelle via la mise en place de solutions dégradées), la réactivité (temps de latence/délai d’exécution, débit), la sécurité et, éventuellement, le coût de fonctionnement.



� Les données d’échange sont les informations véhiculées entre les participants (consommateurs ou fournisseurs de service) à travers l’invocation des opérations de service.

� On parle de modèle d’objets « pivot ».

� A distinguer des données persistantes.



� Quelques caractéristiques d’un service :

1. Couplage faible : les services sont connectés aux clients et autres services via des standards.

2. Langage commun : les données échangées par les services doivent être définies dans un dictionnaire de données commun, définissant l’ensemble des objets pivot en entrée/sorties des services.

3. Composition : tout service doit être composable par les processus.4. Réutilisation : chaque traitement métier doit être offert par un seul

service. Ce besoin de réutilisation doit être traité au niveau d’une gouvernance SOA au sein de l’entreprise.

5. Référencé : chaque service est référencé dans un annuaire de services.6. Sans état : l’exécution d’un service est non-interruptible et ne dépend

pas de son exécution précédente.



� Architecture Orientée Services : style d’architecture logiciellepour lequel les processus métier de l’entreprise sont des composants logiciels paramétrable, orchestrant des tâches avec les acteurs de l’entreprise et des appels à des composants de service pour s’exécuter ([2]).

� 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 (Gartner, 1996).



� L’architecture orientée service se base sur les principes suivants ([3]) :

1. Diviser pour régner : substituer la découpe strictement applicative par une structuration en composants plus réduits et potentiellement plus simples à faire évoluer.

2. Alignement métier : construire et organiser le système à partir des réalités métiers, qui doivent se retrouver dans ses constituants.

3. Neutralité technologique : assurer une indépendance totale entre les interfaces et les implémentations. L’élément qui utilise un service ne doit pas être contraint ni par la technologie d’implémentation, ni par sa localisation (potentiellement distribué).



4. Mutualisation : favoriser la réutilisation de services métiers par plusieurs lignes métiers ou applications. Permettre la construction de services de haut niveau par combinaison de services existants.

5. Automatisation des processus métier : isoler la logique des processus métiers sur des composants dédiés qui prennent en charge les enchaînements et les échanges de flux d’information.

6. Échanges orientés Document : les informations échangées par les services possèdent une structure propre, guidée par les besoins métiers. On privilégie la transmission de contenus complets et utilisables au profit d’accès direct aux structures de type objet ou relationnel.



� Pour que les composants de l’architecture puissent communiquer de façon standard, il est nécessaire de mettre en place un système qui les mettent en relation.

� Le Bus d’entreprise (ou ESB) agit comme la colonne vertébrale reliant ces participants d’une manière banalisée à travers les interfaces de services.



� Convergence des bénéfices attendus de l’urbanisation et de SOA : l’agilité du Système !



� Typologie de services : plusieurs modèles. Exemples :

� Schématiquement, les processus s’appuient sur un ensemble de services de plus bas niveau et d’accès aux données.



� Typologie de services, modèle de Valtech :� Services données : opérations de manipulation d’une classe d’objet

métier et application des règles de gestion associées.� Services composés : opérations nécessitant la manipulation de

divers objets métier par l’utilisation des services Données associés.



� Typologie de services, modèle de Softeam


4

Concepts et représentation


Concepts et représentations

� Pas de modèle standard

� Des notations propriétaires proposées par les outils : MEGA, ARIS, …

� Des profiles UML 2

� SoaML

� Archimate

� Praxeme



ARIS SOA Architect

MEGA



� Il existe des profiles UML 2 pour modéliser les services.

� Exemple : IBMMessage Service

OrderOrder

HeaderHeader BodyBody

Order ServiceProvider

Composition

Order ServicePurchaser

Composition

Order ServicePurchaser

Interaction

Ordering

p : Purchasero : Order Service

Interaction

Ordering

p : Purchasero : Order Service

Policy



� SoaML : Service Oriented Architecture Modeling Language.

� Standard de l’OMG pour la modélisation des architectures de services.

� Un profil UML.

� Version béta "In Process« (décembre 2009).



� ArchiMate : langage de modélisation de l’Open Group pour l’architecture d’entreprise.



� PRAXEME : la description de l’architecture des services se fait en premier lieu dans l’aspect logique.

� L’aspect logique a pour objectif de structurer au mieux le SI.

� Les services sont obtenus par dérivation des modèles amont (sémantiques et pragmatiques).

� PRAXEME opte pour une approche SOA sur ses aspects logique, technique et logiciel.

� PRAXEME recommande UML pour modéliser les services (classe, interface, état, paquetage).


Étude de cas : Architecture d’Entreprise

� Étude de cas : MyBestCar

� L’objectif de l’étude de cas est de proposer une architecture d’entreprise de MyBestCar, et un système d’information cible conçu selon une architecture orientée services.

� Travaux à réaliser : Aspect logique► Étape 3.2


5

MDA


MDA - principes

� MDA : Model Driven Architecture

� Démarche de développement proposée par l’OMG.

� Permet de séparer les spécifications fonctionnelles d’un système des spécifications de son implémentation sur une plate-forme donnée.


MDA - principes

la transformation de celui-ci en modèle indépendant de la plate-forme (Platform Independent Model, PIM) et enfin la transformation de ce dernier en modèle spécifique à la plate-forme cible (Platform Specific Model, PSM) pour l'implémentation concrète du système.

� Élaboration de différents modèles, en partant d'un modèle métier indépendant de l'informatisation (Computation Independent Model, CIM),


MDA - principes

� Exemple de mise en œuvre ([6]) :


MDA - principes

� PRAXEME applique la démarche MDA, en considérant la correspondance suivante :� CIM ≅ aspects sémantique et pragmatique

� PIM ≅ aspect logique

� PSM ≅ aspect logiciel

� Pour mettre en œuvre MDA, il est nécessaire de posséder :� Des techniques de modélisation (règles de construction des

modèles CIM et PIM)� Des techniques de transformation (règles de transformation de du

modèle PIM en modèle PSM).� Et des outils !


MDA – exemples pour une architecture SOA

� Qu’apporte MDA dans le cadre d’une architecture MDA ?

� Sans entrer dans l’étude de l’ensemble des technologies disponibles pour implémenter une SOA, nous retiendrons trois éléments qui participent à la construction d’une SOA :� XSD,� WSDL,� BPEL.



� XSD (XML Schema Definition) : schéma XML qui permet de définir la structure d’un document XML.� Dans une architecture SOA, permet de décrire la structure des

données échangées entre services.� La modélisation des données d’échange peut se faire en UML, ou

dans un langage spécifique à un outil.

Modélisation sous MODELIO Fichier XML



� WSDL (Web Services Description Language) : description la façon dont on peut accéder à un service web.� Définit de manière abstraite et indépendante du langage l'ensemble

des opérations et des messages qui peuvent être transmis vers etdepuis un service web donné.

� Équivalent à l’interface ou le contrat du service.



� WSDL

Modélisation sous MODELIO

Fichier XML



� BPEL (Business Process Execution Language) : pour définir et gérer les orchestrations de processus.� Orchestration : collaboration entre deux ou plusieurs services, mise

en place et/ou gérée (orchestré) par un tiers - en l'occurrence, BPEL.� Ce dernier prend en charge la séquence complète d'invocations des

divers services, ou "collaborateurs".� Chaque processus BPEL dispose par ailleurs de sa propre définition

WSDL. Un processus BPEL est donc un service Web à part entière.� Dans une démarche MDA, le BPEL est généré à partir d’un

diagramme BPMN.� Un service BPEL s’exécute sur un « moteur » BPEL.



� BPEL

Modélisationsous MODELIO

Fichier XML


MDA – exemple d’architecture technique SOA

� Exemple d’architecture technique obtenue :

Station de Travail

Internet

<<access>>

Client

<<access>>

Server

ServeurApplication(WS)

serveurWeb

serveurBPEL

:ML_ProcessusReservation

:ML_Individu

:ML_IHMReservation

Documents

04 –Architecture du SI : identifier, décrire et structurer les servicess3.e-monsite.com/2010/10/24/902050392010-cm-ursisoa-04... · 2010. 10. 24. · Urbanisation et SOA se rapprochent