Patrons d`architecture des Systèmes d`Information

Transcription

P7 : Projet Bibliographique
Dans le cadre du Mastère ASIG
Patrons d’architecture des Systèmes d’Information
Serveur
Base de données
Clients
Mortier Mélanie
15 mai 2008
Mastère ASIG / Projet bibliographique 2008
1
TABLE DES MATIERES
INTRODUCTION
7
1
8
2
3
ARCHITECTURE D’UN SYSTEME D’INFORMATION
1.1
NIVEAU PROCESSUS / ARCHITECTURE METIER
9
1.2
NIVEAU FONCTIONNEL / ARCHITECTURE FONCTIONNELLE
9
1.3
NIVEAU APPLICATIF / ARCHITECTURE APPLICATIVE
9
1.4
NIVEAU TECHNIQUE / ARCHITECTURE TECHNIQUE
9
QU’EST-CE QU’UN PATRON D’ARCHITECTURE ?
11
2.1
DIFFERENCIER LE PATRON D’ARCHITECTURE DU PATRON DE CONCEPTION
11
2.2
L’UTILITE DES PATRONS D’ARCHITECTURE
12
2.3
LES DIFFICULTES LIEES A LA DESCRIPTION DES PATRONS D’ARCHITECTURE
13
LES DIFFERENTES CLASSIFICATIONS DES PATRONS D’ARCHITECTURE
15
3.1
LES STYLES ARCHITECTURAUX
16
3.2
LA CLASSIFICATION PAR « VUES »
16
3.2.1 Définitions
3.2.2 Les différentes « vues »
3.2.2.1
La « vue en couche »
3.2.2.2
La « vue des flux de données »
3.2.2.3
La « vue centrée sur les données »
3.2.2.4
La « vue adaptation »
3.2.2.5
La « vue interface utilisateur »
3.2.2.6
La « vue interaction entre composants »
3.3
16
17
17
18
18
18
19
19
LE TRIPLET PROBLEME/CONTEXTE/SOLUTION
19
3.3.1 Un exemple de classification suivant 4 catégories de problèmes
3.3.2 La description d’un patron d’architecture suivant le triplet
problème/contexte/solution
3.4
4
19
21
LA CLASSIFICATION PAR LES QUALITES DES SYSTEMES
22
LES PATRONS D’ARCHITECTURE FREQUEMMENT UTILISES POUR LES SIG
4.1
4.1.1
4.1.2
LES PATRONS D’ARCHITECTURE DANS LES SIG
25
« Architecture en couches »
« Pipes & Filtres » et « batch séquentiel »
25
28
CONCLUSION
25
30
2
TABLE DES ILLUSTRATIONS
FIGURE 1 : LES QUATRE NIVEAUX D’ABSTRACTION DES SI
8
FIGURE 2 : ARCHITECTURE EN COUCHES (« LAYERS »)
25
FIGURE 3 : PATRON CLIENT SERVEUR
27
FIGURE 4 : PATRON ARCHITECTURE 3TIERS
28
FIGURE 5 : PATRON PIPES ET FILTRES
29
3
GLOSSAIRE ET SIGLES UTILES
MVC
Model View Controller
PAC
Présentation Abstraction Contrôle
SI
Système d’Information
SIG
Système d’Information Géographique
SEI
Software Engineering Institute
QAW
Quality Attribute Workshop
ATAM
Architecture Trade-off Analysis Method
POSA
Pattern-Oriented Software Architecture
BDD
Base de données
O.O.
Orienté Objet
OS
Operating System
4
REMERCIEMENTS
Remerciement à Mr Olivier Boudeville du département SINETICS de chez EDF recherche et
développement pour ses conseils concernant les choix bibliographiques autour de ce sujet.
Egalement remerciement au centre de documentation de l’ENSG, plus particulièrement à
Mme Anne-Marie Ancel pour m’avoir aidé à trouver les ouvrages dont j’avais besoin.
5
RESUME
Il est question dans ce rapport des patrons d’architecture utilisés pour les systèmes
d’information en général et pour les systèmes d’information géographique en particulier.
Nous verrons les problématiques associées à l’étude des patrons d’architecture. Ceci nous
amènera à considérer l’utilité de ces patrons pour choisir une architecture appropriée pour
son système d’information. Cela se traduit notamment par l’étude des qualités associées
aux patrons d’architecture. Ensuite nous aborderons les différentes classifications des
patrons d’architecture. Pour finir, nous décrirons les patrons d’architecture les plus
utilisés dans le domaine du SIG.
Mots-clés : patrons d’architecture, système d’information, système d’information
géographique, qualité.
6
INTRODUCTION
Ce rapport vient concrétiser un projet bibliographique dans le cadre du mastère
architecture des systèmes d’information géographique. Nous avons choisi de présenter une
étude des patrons d’architecture des systèmes d’information (SI) en général et ceux des
SIG en particulier. Cette étude devrait être approfondie. Ce sujet bien qu’étudié plus
fréquemment dans les filières informatiques trouve également une place dans le monde
des SIG. En effet, n’oublions pas que les systèmes d’information géographique (SIG) sont
un type particulier de SI, permettant de manipuler, gérer, mettre à jour… de l’information
géographique.
7
1 ARCHITECTURE D’UN SYSTEME D’INFORMATION
Nous nous intéressons ici à l’architecture logicielle des systèmes d’information.
L’architecture logicielle décrit de manière symbolique les composants du SI et les relations
entre ces différents composants.
Avant de parler de patrons d’architecture, il est intéressant de situer à quel niveau
d’abstraction du système d’information ces derniers se situent. En effet, il existe plusieurs
niveaux d’abstraction dans un SI que nous décrirons brièvement : le niveau processus, le
niveau fonctionnel, le niveau applicatif et enfin le niveau technique.
Figure 1 : Les quatre niveaux d’abstraction des SI
SOURCE : HTTP://SICIAE.UNIV-PARIS1.FR/URBA/PUBLIREPORT/SCLHUMBERGERSEMA.PDF
8
1.1 NIVEAU PROCESSUS / ARCHITECTURE METIER
L’architecture métier décrit la distribution (cartographie) des processus métiers de
l’entreprise pris en charge par le SI sur des composants de type applications ainsi que les
interactions entre les différents composants.
Il existe plusieurs standards de modélisations pour décrire ces processus métiers dont le
Business Process Reengineering (BPR) et le Business Process Management (BPM) entre
autre. Nous ne verrons pas ces différentes modélisations ici, car ce n’est pas le sujet de
cette étude.
Un architecte métier doit connaître les processus métiers de l’entreprise, ses aspects
organisationnels et stratégiques, connaître les besoins fonctionnels et non fonctionnels des
acteurs de l’entreprise, vis-à-vis du SI, et enfin, maîtriser les règles d’urbanisme des SI.
Voici un exemple de processus pour une banque : gestion des comptes par Internet.
1.2 NIVEAU FONCTIONNEL / ARCHITECTURE FONCTIONNELLE
L’architecture fonctionnelle décrit les blocs fonctionnels et leurs points d’échanges. Les
processus sont projetés sur des fonctions qui aident à réaliser ces processus.
L’exemple précédent peut se traduire en terme de fonctionnalités: gérer les comptes,
gérer les sessions, gérer les périphériques d’impression…
1.3 NIVEAU APPLICATIF / ARCHITECTURE APPLICATIVE
L’architecture applicative permet de réaliser l’architecture fonctionnelle. Les fonctions
sont projetées sur des applications. A ce niveau d’abstraction on peut envisager d’utiliser
l’outil de modélisation UML.
1.4 NIVEAU TECHNIQUE / ARCHITECTURE TECHNIQUE
C’est le niveau d’abstraction qui nous intéresse car c’est ici qu’on évoque les patrons
d’architecture. L’architecture technique permet de réaliser l’architecture applicative.
L’objectif est de décrire les types de systèmes à mettre en place et comment réaliser
l’intégration de ces systèmes.
9
Un architecte technique doit connaître pour choisir une architecture :
• Les besoins fonctionnels définis par l’architecture métier
• Les besoins non fonctionnels du SI (ou qualités recherchées)
• Les
techniques
de
développement
et
maîtriser
les
techniques
d’intégration
d’applications.
10
2 QU’EST-CE QU’UN PATRON D’ARCHITECTURE ?
2.1 DIFFERENCIER LE PATRON D’ARCHITECTURE DU PATRON DE CONCEPTION
L’étude des patrons d’architecture est une discipline qui est encore en évolution. La
distinction entre la notion de patron d’architecture (architectural pattern) et de patron de
conception (design pattern) est parfois difficile à établir. Ceci d’autant plus que certains
patrons d’architecture peuvent être déclinés en patrons de conception.
Dans [3], une définition distincte pour chacune de ces notions est proposée :
« An architectural pattern expresses a fundamental structural organization schema for
software systems. It provides a set of predefined subsystems, specifies their
responsibilities, and includes rules and guidelines for organizing the relationships between
them. »
« A design pattern provides a scheme for refining the subsystems or components of a
software system, or the relationships between them. It describes a commonly-recurring
structure of communicating components that solves a general design problem within a
particular context. »
Deux autres définitions tirées de la « software engineering radio » vont également dans ce
sens:
« Architectural Patterns are concerned with strategic aspects of a system. They have a
global impact on the whole implementation of a system. »
« Design Patterns are concerned with technical aspects of an implementation. They have a
local impact on specific parts of the implementation of a system. »
« Architectural Patterns are on a higher level of abstraction than Design Patterns. »
Ce que nous pouvons dégager de ces définitions c’est que les patrons de conception
(design patterns) sont plus proches de préoccupations locales liées à l’implémentation du
SI (codes) que ne le sont les patrons d’architecture (architectural pattern).
Les patrons de conception sont présentés comme indépendants d’un langage de
programmation ou de modèles de programmation. Les patrons d’architecture se situent à
un niveau plus élevé d’abstraction.
11
Les patrons d’architecture décrivent l’organisation du SI en donnant les sous-systèmes qui
le composent, ainsi que les relations entre ces sous-systèmes, leurs responsabilités, et
inclus un ensemble de règles et de modèles à suivre pour organiser les relations entre
elles.
2.2 L’UTILITE DES PATRONS D’ARCHITECTURE
L’idée pour un patron d’architecture est de décrire une architecture de système qui a déjà
fait ses preuves pour résoudre un problème dans un contexte particulier.
Pour décrire ce patron il est nécessaire d’utiliser un vocabulaire de base commun, qui
puisse être compris de manière non ambiguë par les architectes des SI, il en va de même
pour sa représentation graphique.
Cependant, comme nous l’avons évoqué plus haut, l’étude des patrons d’architecture est
encore récente et aucune formalisation officielle n’a été fournie aux architectes. A l’heure
actuelle, il existe parfois plusieurs termes pour désigner un même patron d’architecture
et, plus gênant, il n’existe pas encore de vocabulaire et de représentation officiels uniques
pour les patrons malgré des efforts d’unification réalisés depuis les années 1990. Nous
reparlerons des difficultés liées à la description des patrons d’architecture dans la section
suivante.
Le but d’un patron d’architecture est de permettre aux architectes expérimentés de
réutiliser des architectures connues, qui ont été validées par l’expérience. En effet,
avec la complexité croissante des systèmes et le besoin de les faire évoluer, les
architectes des systèmes d’information ont de manière informelle commencé à structurer
leurs systèmes et à utiliser des termes génériques pour désigner des architectures déjà
largement utilisées.
Avec un vocabulaire unifié et des représentations graphiques communes, les architectes
peuvent partager leurs idées concernant leur architecture SI et sur celles d’autres
architectes, qui auront pris la peine de documenter leur système. Le but étant pour les
architectes expérimentés et les architectes en formation de se comprendre.
Les patrons ont donc un rôle important dans la construction de nouveaux systèmes
d’information, ils permettent de ne pas tout réinventer mais au contraire de s’inspirer de
12
modèles d’architectures devenus courants. Il reste alors au soin de l’architecte qui a choisi
un patron d’architecture de l’adapter à son problème particulier en suivant les grands
principes du patron.
2.3 LES DIFFICULTES LIEES A LA DESCRIPTION DES PATRONS D’ARCHITECTURE
La jungle des descriptions des patrons d’architecture demande au novice un apprentissage
du vocabulaire qui n’est pas standardisé. De plus, il existe quelques méthodes qui
proposent une validation du choix du patron d’architecture, mais elles ne sont pas
officielles et restent marginales face aux choix d’architecture par des ingénieurs
architectes expérimentés.
La difficulté majeure reste donc que plusieurs « écoles » subsistent et proposent leur
classification des patrons d’architectures suivant différentes philosophies et avec
différentes représentations :
• Pour certains ils peuvent être regroupés en styles architecturaux et définis par une
approche composants/connecteurs ;
• Pour
d’autres
les
patrons
d’architecture
doivent
être
définis
comme
un
triplet problème/contexte/solution ;
• Certains préfèrent les associer à des « vues » ;
• Et récemment des essais pour les classer suivant leurs qualités ont été menés.
Nous allons maintenant voir les classifications évoquées ci-dessus ainsi que les définitions
des patrons d’architecture classés suivant les différentes écoles.
Nous
nous
intéresserons
plus
particulièrement
à
la
classification
des
patrons
d’architectures par les qualités recherchées dans les SI car ces qualités détermineront la
pertinence du choix du patron par rapport à un autre.
13
Nous remarquerons qu’il existe d’autres classifications des patrons d’architecture, mais
nous ne les donnerons pas toutes.
14
3 LES DIFFERENTES CLASSIFICATIONS DES PATRONS
D’ARCHITECTURE
Nous avons choisi de présenter quatre classifications de patrons d’architecture. Et nous
verrons également quels patrons d’architecture s’y inscrivent. Il existe de nombreuses
classifications des patrons d’architecture car il n’en existe pas d’officielle. Nous en avons
quatre pour avoir un aperçu de la complexité de ce sujet en gardant à l’esprit qu’il
faudrait plus de temps pour cerner les tenants et aboutissants des patrons d’architecture.
Cependant, rappelons que tous les patrons d’architecture existants ne sont pas recensés
dans ce rapport. De plus, nous parlons ici de patrons d’architecture « purs », alors que
dans les systèmes d’information il est possible que plusieurs patrons coexistent. Il faudrait
alors étudier les différentes combinaisons de patrons réalisables et voir si nous pouvons les
classer à leur tour, si la classification s’y prête...
Les deux premières classifications sont plus orientées sur les solutions proposées. Les deux
suivantes tentent d’accorder leur attention à la solution mais également aux problèmes
auxquels doivent répondre les patrons d’architecture.
Chaque classification à des avantages et des inconvénients. Certaines sont plus répandues
et donnent une idée organisée des patrons existants, d’autres sont nouvelles mais tentent
d’introduire une validation dans le choix du SI, d’autres encore se placent d’un point de
vue particulier.
15
3.1 LES STYLES ARCHITECTURAUX
Cette classification est assez répandue. Elle fait appel à UML pour représenter ses patrons.
Elle définit les patrons d’architecture en terme de composants et de connecteurs, ces
derniers reliant les composants entre eux.
Voici une liste non exhaustive de styles architecturaux:
Style flux de données : avec les patrons « pipes & filtres » et « batch séquentiel ».
Style requête-réponse ou aussi appelé « call and return » avec les patrons « décomposition
fonctionnelle »
ou
« décomposition
en
programme
principal
et
subroutines »,
« architecture O.O. » et « architecture en couches » dont le « Client Serveur ».
Style composants indépendants avec les « systèmes évènementiels » et « processus
communicants ».
Style centrés sur les données : « hypertext system », « blackboards ».
Un style architectural définit un vocabulaire de composants, de types de connecteurs et
met en place des contraintes sur la manière dont ils doivent être assemblés.
Pour beaucoup de styles il peut exister un ou plusieurs « modèles sémantiques » qui
spécifient comment déterminer les propriétés d’ensemble du système à partir des
propriétés de ses parties.
3.2 LA CLASSIFICATION PAR « VUES »
3.2.1 Définitions
Une « vue architecturale » est une représentation qui comprend des éléments du système
et les relations entre les divers éléments. Nous verrons quels peuvent être ses éléments.
Le « point de vue » permet de communiquer les vues sans ambiguïté grâce à la description
des types d’éléments et de relations, ainsi qu’à des informations sur les données.
16
Une « vue » peut être désignée comme une instance d’un « point de vue » pour un
système particulier, car les éléments et les relations contenues dans la « vue » sont des
instances de types correspondants d’éléments et de relations contenus dans le « point de
vue ». Une « vue » porte ses préoccupations sur un aspect précis du système que ce soit les
interfaces, les flux de données, les adaptations possibles pour le système…
Un patron d’architecture définit également des éléments et des relations qui sont
organisés pour résoudre un problème particulier sous une certaine perspective. En fait, un
patron d’architecture peut être considéré comme une spécialisation d’un « point de vue »
dans la mesure où il propose une sémantique spécifique pour les types d’éléments et les
relations qui le composent, tout en leur posant des contraintes.
Voyons comment les patrons d’architecture peuvent s’associer aux « vues ».
Là encore il existe plusieurs approches. Nous choisissons d’exposer l’une de ces approches.
Ici, chaque patron d’architecture est associé à une vue primaire. Mais il existe des cas où
un même patron peut être utilisé dans une seconde ou troisième vue. Par exemple quand
deux patrons d’architecture issus de différentes vues sont combinés dans un même
système, ces patrons peuvent être aperçus dans chaque vue.
Les vues que nous reprenons contiennent deux types d’éléments : les composants et les
connecteurs entre les différents composants, comme pour les styles architecturaux. Mais
dans d’autres vues, d’autres types d’éléments peuvent être introduits.
Les premières vues que nous présentons sont proches des styles architecturaux, mais des
différences surviennent assez vite comme nous pouvons le constater.
3.2.2 Les différentes « vues »
3.2.2.1 La « vue en couche »
La « vue en couches » s’intéresse à la façon dont un système complexe peut être
décomposé en parties ou couches qui interagissent entre elles. On compte dans les
patterns architecturaux de cette vue : le patron des « systèmes en couches », et celui des
« couches unidirectionnelles ».
17
Les préoccupations de cette vue sont de savoir comment les différentes parties (couches)
peuvent rester indépendantes tout en travaillant ensemble et bien sûr comment les
qualités sont-elles supportées dans cette vue.
3.2.2.2 La « vue des flux de données »
La « vue des flux de données » traite de comment un flux de données est successivement
traité et transformé par ses composants. Les patrons associés sont les « pipes et filtres »
ainsi que le « batch séquentiel ».
Les préoccupations de cette vue sont les suivantes : quels sont les éléments qui réalisent
les transformations, quels sont les éléments qui portent les flux de données, comment ces
éléments sont connectés, comment les attributs de qualités sont-ils supportés ?
Les éléments qui réalisent les transformations sont des composants indépendants qui ont
des données en entrée et en sortie. Les éléments qui portent les flux de données sont les
connecteurs, qui ont eux aussi des données en entrée et en sortie.
3.2.2.3 La « vue centrée sur les données »
La « vue centrée sur les données » est appropriée quand l’intérêt se porte sur comment
une base de données centrale est accessible par différents composants. Les patrons
concernés sont les « repositories » et « blackboards ».
Les préoccupations de cette vue sont comment les données sont partagées, accessibles et
mises à jour. Comment les données sont distribuées, si le stockage est actif ou passif, les
éléments qui accèdent aux données communiquent-ils entre eux directement ou par
l’intermédiaire des données partagées ?
La base de données et les éléments qui y accèdent sont des composants. La base de
données est indépendante des composants et les composants entre eux sont généralement
indépendants. Il peut y avoir plusieurs bases de données.
3.2.2.4 La « vue adaptation »
La « vue adaptation » traite de comment s’adapte un système pendant son évolution avec
les patrons « microkernel », « reflection » et « interceptor ».
Dans la vue adaptation le système est perçu comme un noyau invariable et une partie
modifiable/adaptable qui peut changer au cours du temps suivant les différentes versions
du système.
18
3.2.2.5 La « vue interface utilisateur »
La « vue interface utilisateur » montre la structure des composants qui offrent une
interface à l’usager. Les patrons de cette vue sont le « Model View Controller » ou MVC,
« présentation/abstraction/contrôle » et « C2 ».
3.2.2.6 La « vue interaction entre composants »
La « vue interaction entre composants » s’oriente sur comment les composants individuels
échangent des messages mais conservent leur autonomie. Les patrons évoqués sont
« l’invocation explicite » aussi appelée « processus communicants », « l’invocation
implicite » aussi appelée « système évènementiel », le « Client Serveur », le « PEER-TOPEER ».
Il existe encore d’autres vues moins utilisées. Nous ne les évoquerons donc pas ici.
3.3 LE TRIPLET PROBLEME/CONTEXTE/SOLUTION
3.3.1 Un exemple de classification suivant 4 catégories de problèmes
Dans cette classification, la description d’un patron d’architecture est présentée comme
un couple problème/solution qui dépend d’un contexte. Le patron doit répondre à une
attente, autrement dit à un problème particulier.
Il est important de bien identifier les problèmes pour en dégager les besoins et d’y
apporter les solutions adaptées. Au fur et à mesure, l’analyse doit devenir de plus en plus
fine pour aboutir à une solution technique. De part l’attachement à l’analyse des
problèmes et de leur solution, le patron choisi sera « validé » pour répondre au problème.
Pour
classer
les
patrons
d’architecture
suivant
cette
philosophie
problème/contexte/solution, nous devons définir des catégories de problèmes, ces quatre
catégories sont reprises de [3] :
Structurer le système : comment décomposer le système en parties qui vont coopérer ? On
compte pour résoudre ce problème les patrons d’architecture en « couches », les « pipes
et filtres » et le patron « blackboard ».
19
Le patron en « couches » aide à structurer les applications qui peuvent être décomposées
en groupes de sous tâches dans lesquels chaque groupe de sous tâches fait parti d’un
niveau d’abstraction particulier.
Un exemple du patron en couches bien connu est celui des protocoles réseaux avec ses
sept couches (physique, liaison, réseau, transport, session, présentation et application)
Le patron « pipes & filtres » offre une structure pour les systèmes qui traitent des flux de
données. Chaque étape du traitement du flux de données est encapsulée dans un filtre.
Le patron « blackboard » est utilisé lorsqu’aucune stratégie de solution déterminée n’est
connue. Dans le « blackboard » plusieurs sous systèmes spécialisés assemblent leurs
connaissances pour construire une solution partielle ou approximée. Ce patron est
notamment utilisé dans la reconnaissance d’image.
Systèmes distribués : pour les systèmes qui ont des composants placés dans différents
processus ou dans plusieurs sous-systèmes et composants. Les patrons relatifs à cette
catégorie sont les patrons « broker », « pipes et filtres » et « microkernel », client serveur,
reactor.
Le patron « microkernel » est intéressant pour des systèmes qui requièrent des évolutions,
des
changements.
Un cœur
fonctionnel minimal
est
séparé
de
fonctionnalités
supplémentaires et de parties spécifiques du système. Le patron « microkernel » a été
développé pour concevoir de petits OS et leurs extensions avec de nouveaux services.
Le patron « broker » peut être utilisé pour les structures distribuées avec des composants
découplés qui interagissent par « remote service invocations ». Un composant « broker »
est responsable de la coordination de la communication, de la transmission des erreurs et
des exceptions…
Systèmes interactifs : pour les systèmes qui demandent une interaction avec l’humain en
désirant conserver le cœur fonctionnel indépendant de l’interface utilisateur. Le but pour
ses systèmes est de permettre de changer l’interface sans affecter les applications du
système. On utilise les patrons « Model View Controller »
MVC et « Présentation
Abstraction Control » PAC pour ses systèmes.
20
Le patron « MVC » partage une application en trois composants. Le composant « model »
contient les fonctionnalités centrales ainsi que les données. Le composant « view » donne
les informations à l’utilisateur et le composant « controller » se charge de contrôler les
entrées données par l’utilisateur. L’ensemble « view » et « controller » représente
l’interface. Ces deux parties doivent garder une cohérence lorsque l’interface est
modifiée.
Le patron « PAC » défini une architecture sous la forme d’une hiérarchie d’agents
coopérants. Chaque agent est en charge d’un aspect d’une fonctionnalité et est composé
de trois composants : la présentation, l’abstraction et le contrôle. Cette décomposition
sépare les aspects de l’interaction humain-ordinateur de l’agent de son cœur fonctionnel
et sa communication avec d’autres agents. Les librairies Smalltalk utilisent ce patron
d’architecture.
Systèmes adaptables : pour les systèmes qui doivent prévoir des évolutions, adaptations de
leurs applications on parlera des patrons « microkernel » et « reflection ».
Le patron « reflection » offre un mécanisme pour faire changer la structure et le
comportement d’une architecture logicielle dynamiquement. Il supporte des modifications
d’aspects fondamentaux, comme les mécanismes de fonction d’appel. Dans ce patron une
application est divisée en deux parties. Une partie fournit des informations concernant les
propriétés du système sélectionné et rend le logiciel conscient de lui-même (méta
niveau). L’autre partie comprend la logique de l’application (niveau de base).
Cette classification est incomplète car si l’on rajoute de nouveaux patrons d’architecture
il faudra sans doute rajouter des catégories de problèmes.
3.3.2 La description d’un patron d’architecture suivant le triplet
problème/contexte/solution
Nous allons ici décrire de manière simplifiée le patron d’architecture « layers » ou en
« couches ».
Contexte : On a un système complexe qui doit être décomposé.
21
Problème : Nous avons un système qui est caractérisé par des applications, fonctionnalités
de hauts et bas niveaux. Les applications de haut niveau s’appuient sur celles de bas
niveau. Nous voulons que des changements dans une couche n’aient pas de répercussion
sur le système entier. Les parties/couches du système doivent pouvoir être remplacées
sans affecter le système entier. Les composants complexes doivent être re-décomposés.
Les responsabilités similaires doivent être groupées pour aider à la compréhension du
système et sa maintenabilité…
Solution : Il faut structurer le système en un nombre approprié de couches et commencer
par la couche de plus bas niveau. Ce sera la couche 1, la base du système. Puis on continue
avec la couche de niveau supérieur…jusqu’à la couche de niveau supérieur N. Les services
rendus par la couche J sont composés en partie des services de la couche J-1, c'est-à-dire
que les services de la couche J dépendent de la couche J-1.
Nous remarquerons que le problème a été simplifié par mes soins et que la solution ne dit
pas comment faire les couches, ni si telle ou telle couche sera complexe…
3.4 LA CLASSIFICATION PAR LES QUALITES DES SYSTEMES
Cette classification prend appui sur le modèle du couple « problème/solution » évoqué
précédemment en ajoutant une notion de qualités recherchées. Le problème et la solution
s’expriment par des besoins fonctionnels et non fonctionnels.
Un besoin fonctionnel doit répondre à une fonctionnalité exprimée durant la phase de
l’analyse métier, tandis qu’un besoin non fonctionnel correspond à des qualités que l’on
peut associer soit au système en général ou plus précisément à chacune des
fonctionnalités.
Parmi ces qualités on compte :
• La robustesse : le système donne-t-il des résultats similaires si l’on modifie un peu ses
paramètres ?
• La performance : le système doit répondre à des critères de performance (temps de
réponse, ressources utilisées). On peut parler de performance en terme de temps ou de
place utilisée.
• La flexibilité : le système a-t-il la possibilité d’évoluer facilement, les efforts pour le
modifier devront-ils être importants ?
• La portabilité : le système peut-il être intégré dans un autre environnement facilement ?
22
• La sécurité : quel niveau de sécurité doit être mis en place pour protéger les données du
SI ? On remarquera que ce besoin peut également être assimilé à un besoin fonctionnel.
• L'interopérabilité : le SI a-t-il la capacité à communiquer et à utiliser les ressources de
systèmes extérieurs ?
• La compatibilité exprime la possibilité, pour un SI, de fonctionner correctement dans un
environnement ancien (compatibilité descendante) ou plus récent (compatibilité
ascendante).
• La validité exprime la conformité des fonctionnalités du SI avec celles décrites dans le
cahier des charges.
• La vérifiabilité exprime la simplicité de vérification de la validité.
• L'intégrité exprime la faculté du SI à protéger ses fonctionnalités et ses données d'accès
non autorisés.
• La fiabilité : le SI est-il en mesure de gérer ses erreurs de fonctionnement pendant
l’exécution ?
• La maintenabilité exprime la simplicité de correction et de modification du SI.
• La réutilisabilité exprime la capacité de concevoir le SI avec des composants existants
tout en permettant la réutilisation simple de ses propres composants pour le
développement d'autres SI.
• L'efficacité exprime la capacité du SI à exploiter au mieux ses ressources.
• La transparence exprime la capacité pour un SI de masquer à l'utilisateur (humain ou
machine) les détails inutiles à l'utilisation de ses fonctionnalités.
• La simplicité d'utilisation ou aussi l’ergonomie décrit la facilité d'apprentissage et
d'utilisation du SI par les usagers.
On peut encore trouver d’autres qualités, mais nous ne les décrirons pas toutes ici.
Rajoutons que le système doit bien évidemment remplir les fonctionnalités métiers.
Pour évaluer l’importance de ces qualités pour le choix du SI, des buts peuvent être
assignés pour chaque qualité et fonctionnalité désirée avec une priorité : élevée, moyenne
ou faible. Cela permet de guider le choix d’une solution suivant les besoins non
fonctionnels. Les priorités sont déterminées par des experts au moyen des votes ou des
consensus.
« Un patron décrit à la fois un problème qui se produit très fréquemment dans votre
environnement et l’architecture de la solution à ce problème de telle façon que vous
23
puissiez utiliser cette solution des milliers de fois sans jamais l’adapter deux fois de la
même manière» C. Alexander
La validation d’un patron d’architecture consistera alors à prouver que :
• La solution préserve le comportement décrit et désiré pour répondre à la partie
problème.
• La solution doit respecter les qualités désirées spécifiées au préalable.
Ainsi les architectures en couches permettent la réutilisabilité des « layers » pour d’autres
systèmes d’information et également de pouvoir changer une couche sans devoir changer le
reste du SI. Donc la maintenabilité, la réutilisabilité et la flexibilité comptent parmi les qualités
de ce patron d’architecture.
Par contre la performance est amoindrie car le système doit communiquer entre les couches,
vérifier des messages, retransmettre les éventuelles erreurs.
Cette classification est à faire.
24
4 LES PATRONS D’ARCHITECTURE FREQUEMMENT
UTILISES POUR LES SIG
Dans cette partie nous allons décrire les patrons d’architecture les plus utilisés dans le
domaine des SIG ainsi que pour des exemples de systèmes d’information bien connus.
4.1 LES PATRONS D’ARCHITECTURE DANS LES SIG
4.1.1 « Architecture en couches »
Ce type de système est organisé de manière hiérarchique, chaque couche effectue un
service pour la couche de dessus et sert de client pour la couche de dessous. Dans certains
systèmes les couches intérieures sont cachées de toutes les couches sauf des couches
adjacentes.
Les connecteurs sont les protocoles qui déterminent la façon dont les couches
interagissent.
Exemple : Protocoles de communication en couches pour des systèmes de base de données
et OS.
Figure 2 : Architecture en couches (« layers »)
25
Avantages de ce patron d’architecture:
• Possibilité de partitionner un problème en une séquence incrémentale de niveau
d’abstraction (couche).
• L’amélioration : chaque couche interagit avec deux autres couches, le changement d’une
fonction d’une couche affectera au maximum deux couches (comme pipes).
• La réutilisabilité : différentes implémentations d’une même couche pourvu qu’elles
supportent la même interface aux couches adjacentes. Cela mène à la possibilité de
définir des couches d’interfaces standards. OSI ISO modèle et X Window System
Protocols.
Inconvénients :
• Difficultés à structurer le problème en couches d’abstraction.
• Et même si on peut structurer logiquement en couches pour des raisons de performance
on peut être obligé de rapprocher les couches.
• Difficultés de trouver les bons niveaux d’abstraction en particulier pour les modèles
standardisés. Difficulté à définir les protocoles de communication en OSI ISO parce que
de nombreux protocoles font le pont entre plusieurs couches.
Exemple de l’architecture Client Serveur
Cette architecture a été évoquée dans la classification par « vues » (« vue interaction
entre composants ») mais aussi dans la classification par style architectural comme un
exemple de patrons pour les « systèmes en couches ».
Cette architecture est classiquement utilisée dans les SIG pour permettre à plusieurs
utilisateurs : les clients, d’accéder à une base de données (BDD) commune. Les accès à la
BDD sont gérés par le serveur.
26
Figure 3 : Patron client serveur
Cette architecture est utilisée quand deux types de composants différents ont besoin de
communiquer. Ces composants sont indépendants les uns des autres. Les composants de ce
patron d’architecture sont le client et le serveur. La base de données dans cette
architecture deux couches ou 2-Tiers est incluse dans le serveur.
Le client initialise la communication pour demander un service au serveur. Le serveur est à
l’écoute du/des client(s) et doit être capable de répondre à plusieurs clients.
Il existe également des architectures 3-Tiers. Cette architecture est similaire à
l’architecture « client serveur » si ce n’est que le client demande à un serveur
d’application une requête, le serveur d’application joue alors le rôle de client pour le
serveur de base de données.
27
Figure 4 : Patron Architecture 3Tiers
4.1.2 « Pipes & Filtres » et « batch séquentiel »
Chaque composant a un ensemble de données en entrée et un ensemble de données en
sortie. Un composant lit un flux de données en entrée et produit un flux de données en
sortie. Les données subissent des transformations dans les filtres (composants) et sont
acheminées de filtre en filtre par les pipes (connecteurs). Les filtres doivent être
indépendants. Une autre particularité importante est qu’un filtre ne connaît pas l’identité
du filtre en amont et en aval.
Ce type de patron est utilisé dans la gestion des pipelines.
28
Un système de batch séquentiel est un cas particulier de pipeline. Le traitement des
données ne peut commencer que quand le flux des données en entrée est bien arrivé dans
le filtre…
L’exemple le plus connu d’architecture pipes et filtres sont des programmes écrits dans le
noyau d’UNIX. Les compilateurs eux aussi, bien que les phases ne soient souvent pas
incrémentales c'est-à-dire qui caractérisent une opération (sur un ensemble de données)
qui ne concerne que les données qui ont été ajoutées depuis la dernière manipulation.
Avantages de ce patron d’architecture :
• Bien comprendre la chaîne de traitement des données en examinant le comportement de
chaque filtre.
• La réutilisation des filtres.
• La maintenance et l’amélioration du système est facilitée : de nouveaux filtres peuvent
être introduits, les anciens filtres peuvent être remplacés par des filtres améliorés.
• Permet des analyses spéciales : throughput (débit) et deadlock (verrou mortel) analyses.
Inconvénients :
• Les systèmes pipes et filtres conduisent à une organisation des processus en lot « batch
organisation of processing ». Ces systèmes ont un caractère de transformation des
données, ils ne sont pas bons pour faire des applications interactives.
Figure 5 : Patron pipes et filtres
29
CONCLUSION
Nous avons vu que le sujet des patrons d’architecture est complexe. Des universités telles
que l’université de Carnegie Mellon située à Pittsburgh, sont très actives dans ce domaine.
Nous avons ici présenté les rudiments des patrons d’architecture avec un petit état des
classifications existantes qui est loin d’être exhaustif et des patrons d’architecture connus
dans le monde des systèmes d’information géographique. Nous avons pu aborder
également la complexité pour différencier les patrons d’architecture et les patrons de
conception et mis en évidence que les qualités des SI sont des éléments important à
prendre en compte pour déterminer quelle architecture choisir. Malheureusement, faute
de vocabulaire et de représentation officielle, les patrons d’architecture ne sont pas
encore réutilisés au mieux de leur potentialité.
30
BIBLIOGRAPHIE
[1] MARY SHAW, DAVID GARLAND. Software Architecture: Perspectives on an Emerging
Discipline. Prentice-Hall: 1996, 242 p.
[2] LEN BASS, PAUL CLEMENTS, RICK KAZMAN. Software Architecture in practice: Second
Edition. Addison Wesley, Etat unis: janvier 2005, 528 p.
[3] FRANCK BUSCHMANN, REGINE MEUNIER, HANS ROHNERT, PETER SOMMERLAD, MICHAEL
STAL. Pattern-Oriented Software Architecture: A system of patterns. Wiley, Angleterre:
1996, 467 p.
[4] FRANCISCA LOSAVIO, NICOLE LEVY, PARINAZ DAVARI, FRANÇOIS COLONNA. PatternBased Architectural Design Driven by Quality Properties: A Platform to Model Scientific
Calculation. Springer Berlin / Heidelberg, 2005. (extrait d’un livre)
Styles d’architectures basés sur les attributs. [Référence du 6 avril 2008], URL du site :
http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.ht
ml
Patrons d’architecture selon Wikipédia. [Référence du 6 avril 2008], URL du site :
http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)
Architectural Patterns Revisited – A pattern Language. [Référence du 6 avril 2008], URL du
site : http://www.infosys.tuwien.ac.at/Staff/zdun/publications/ArchPatterns.pdf
Des généralités sur l’architecture logicielle, les critères de qualité, les styles
architecturaux…
[Référence
du
8
mai
2008],
URL
du
site :
http://fr.wikipedia.org/wiki/Architecture_logicielle
31

Patrons d`architecture des Systèmes d`Information

Transcription

Documents pareils

FICHE 5 : PATRON D`UN PAVE ET D`UN CUBE EXERCICE 1

Les 11 patrons du cube que nous avons

Introduction « Pourquoi est-ce que je me défoncerais pour un patron

35 heures.qxp - Confédération nationale du travail

Rassemblement unitaire au HAVRE Samedi 7 Juin // 14h30

Kit découverte Réalisez 3 patrons modèles à partir d`un même

autonome en design et confection de vêtement Date d`affichag

communiqué de presse

Patron de jupe au choix Patron de robe