C352 New Chap 4

Processus de conception de
systèmes d'information
(C352)

Pascal ANDRÉ, Alain VAILLY
(Université de Nantes)
juin 2016

version imprimable du cours

Chapitre 4
Concevoir la solution
L’étape de conception décrit une solution au problème spécifié dans l'analyse dans le cadre
technique choisi. Elle définit la solution retenue par prise en compte des caractéristiques logiques
d'usage du futur système d'information et des moyens de réalisation, humains, techniques et
organisationnels.
Reprenons l’introduction de Jacques Lonchamp à ce sujet [18] : « La phase de conception
logicielle est l’équivalent, dans le domaine de l’informatique, de la phase de conception que l’on
retrouve dans toutes les disciplines de l’ingénierie traditionnelle (génie mécanique, génie civil,
génie électrique, etc.). Toute conception a pour finalité de penser et de représenter le produit à
réaliser sous une forme abstraite, avant sa production effective. Cependant, la nature immatérielle
du logiciel rend la frontière entre la conception et le produit plus floue que dans l’ingénierie
traditionnelle. La différence entre le plan d’un pont et le pont lui-‐même est plus évidente que la
différence entre un schéma de classes et le programme objet qui l’implante. »
La conception est une vaste activité fondée sur la maîtrise de techniques de mise en œuvre
mais aussi, et surtout, de concepts et pratiques relatifs à la qualité des résultats. La figure 1,
extraite d’un cours de Gerson Sunyé à l’Université de Nantes [26], montre la complexité du
problème.

figure 1-‐ La conception de logiciels, un problème complexe
Pressman consacre un chapitre complet à ces concepts, le chapitre 8 de son ouvrage [20].
Les concepts clés sont l’abstraction, l’architecture, les patrons récurrents (patterns), la séparation
des préoccupations, la modularité, l’indépendance fonctionnelle, etc. Le résultat est un modèle
Chapitre 4 – Concevoir la solution C352 2/72

qui doit être évolutif (changements techniques ou fonctionnels) et couvrir les aspects
complémentaires que sont le modèle des données et la persistance, les traitements et le
parallélisme, les interfaces visuelles, le déploiement dans une vision architecturale qui fasse
apparaître progressivement les détails. Il distingue différents types de conception, comme la
conception architecturale, la conception par composants (ou services), la conception des IHM, la
conception par patterns, la conception d’applications web. Tout cela est imbriqué et dénote la
complexité de l’activité de conception. Selon les auteurs, l’activité de conception est découpée en
deux ou trois activités. Auparavant on distinguait conception générale et conception détaillée
pour le développement classique client-‐serveur sur de gros systèmes, types AS400. Les systèmes
distribués ayant pris l’ascendant, il a été nécessaire d’accorder plus de place à l’organisation
logique du déploiement des applications sur plusieurs dispositifs. La conception générale a été
découpée en deux phases, la conception de l’architecture de l’application et la conception des
éléments de l’architecture, les composants. On trouve donc maintenant souvent trois phases dans
la conception : la conception systémique ou architecturale qui trace les grandes lignes de
l’organisation du système futur en sous-‐systèmes collaborant, la conception préliminaire qui fixe
les composants et leurs interfaces et enfin la conception détaillée qui affine la description pour les
développeurs.
Dans ce cours, on considère que l’analyse technique contribue à la conception générale
selon le modèle 2TUP [22]. On décomposera la conception en deux parties, la conception
préliminaire de la solution et la conception détaillée. La première a pour objectif de donner
l'architecture globale du système et sa décomposition (i.e. les différentes parties) et la seconde
décrit chaque partie du système. Cette spécification du logiciel reste indépendante de tout moyen
de réalisation.
La conception opère sur les vues de conception en lien avec la vue du déploiement et celle
des processus métiers (cf. figure 2) [23]. Il existe d’autres frameworks d’architecture que ce
modèle dit des 4+1 vues fortement associé à UML et au processus unifié (Zachman, ODP-‐RM,
TOGAF, IEEE P1471…) mais il relève plus de l’architecture d’entreprise que de l’architecture
logicielle.

figure 2 -‐ Notation UML : les vues

Ce chapitre concerne la conception préliminaire qui met en évidence une solution applicative
au carrefour du besoin métier et de l’architecture technique choisie, comme le montre la figure 3.
C’est à notre sens l’étape clé dans le développement du logiciel supportant un système
d’information. C’est aussi une étape délicate car on y découvre les écueils entre les choix
fonctionnels et les choix techniques.
C’est une étape de pure ingénierie où on doit combiner l’analyse logique du système avec le
support technique choisi, qui détermine l’architecture de l’application à la fois d’un point de vue
logique (système en couche) et d’un point de vue système (déploiement). C’est donc l’étape la
plus délicate du processus.
Le mot clé à ce niveau est « architecture ». Le résultat doit donc être une vision claire de
l’application, à un niveau suffisamment abstrait pour masquer les détails mais faciliter la
compréhension.
En plus du volet technique, nous nous attacherons à rappeler les éléments de gestion du
projet (organisation, planification, répartition, risques…), du support (configuration, méthode,
documentation…). On conservera bien les éléments clés de la qualité d’un processus à savoir
tracer les décisions (ici de conception) tout au long du cycle de développement. À ce niveau,
interviennent aussi la prise en compte des besoins fonctionnels et non fonctionnels.

Chapitre 4 :
Grandes catégories de solutions
Pattern d’architecture
Framework
Méthode : règles de conception, bonnes pratiques
Gestion de projet agile, itérations…
Plan

I. Introduction................................................................................................................................................ 6
A. Localisation dans le cycle de vie du logiciel........................................................................................... 6
B. Enjeux et risques.................................................................................................................................... 6
C. Processus et résultats .......................................................................................................................... 12
D. Déroulement ....................................................................................................................................... 16
E. Support ................................................................................................................................................ 17
II. Architectures logicielles........................................................................................................................... 18
A. Définitions ........................................................................................................................................... 18

B. Classifications d'architecture : genres, styles et patterns ................................................................... 19
C. Présentation et exemples.................................................................................................................... 25
D. Architecture Web ................................................................................................................................ 29
III. Concevoir l'architecture.......................................................................................................................... 52
A. Démarche dans le processus unifié ..................................................................................................... 52
B. Démarche ATAM ................................................................................................................................. 53
C. Démarche ADD .................................................................................................................................... 54
D. Démarche de Cloux ............................................................................................................................. 55
IV. Gestion de projet.................................................................................................................................... 58
A. Bonnes pratiques................................................................................................................................. 58
B. Gestion des risques.............................................................................................................................. 58
C. Collaboratif & support ......................................................................................................................... 58
V. Un exemple support ................................................................................................................................ 60
A. Architecture technique........................................................................................................................ 60
B. Persistance........................................................................................................................................... 64
C. Présentation et Métier ........................................................................................................................ 64
D. IHM...................................................................................................................................................... 65
E. Gestion de projet et industrialisation .................................................................................................. 65
VI. Conclusion .............................................................................................................................................. 67
VII. Références............................................................................................................................................. 68
VIII. Liste des illustrations ............................................................................................................................ 71


I. Introduction
A. Localisation dans le cycle de vie du logiciel
La conception préliminaire (or architecturale ou système) met en évidence une solution
applicative au carrefour du besoin métier et de l’architecture technique choisie. C’est à notre sens
l’étape clé dans le développement du logiciel supportant un système d’information. C’est une
étape de pure ingénierie où on doit combiner l’analyse logique du système avec le support
technique choisi, qui détermine l’architecture de l’application à la fois d’un point de vue logique
(système en couche) et d’un point de vue système (déploiement). C’est donc l’étape la plus
délicate du processus.

figure 3 -‐ Processus 2TUP
Le mot clé à ce niveau est « architecture ». Le résultat doit donc être une vision claire de
l’application, à un niveau suffisamment abstrait pour masquer les détails mais faciliter la
compréhension. Evidemment la manière de faire varie avec l’approche technologique choisie
(solution distribuée ou pas, sur le web, en mobilité…).
L’élaboration met au point et valide l’architecture du système, c’est-‐à-‐dire qu’à l’issue de
cette étape le cadre de développement est bien défini et la faisabilité est assurée. Elle établit
l’architecture et la planification contrôlée du projet.
B. Enjeux et risques

Selon Jacques Longchamp [18], la conception orientée objet est un art difficile. Dans le cadre
des approches à base de classes, le modèle de conception objet doit décrire les objets et classes
nécessaires, leurs interfaces, leurs regroupements en paquets, ainsi que les relations que ces

éléments entretiennent, en particulier en termes de dépendances. Dans un contexte JEE, les
classes correspondent à beaucoup de concepts différents (servlet, JSP, Java Bean, EJB, entité JPA,
etc.) qu’il faut maîtriser ainsi que les dépendances spécifiques qu’ils impliquent.
La conception doit à la fois être spécifique au problème à résoudre, qu’il faut avoir
minutieusement analysé, et parfois un peu plus générale, pour faciliter l’adaptation aux évolutions
qui se produiront inévitablement.
Nous étudions ici les enjeux à travers les objectifs et les principes, mais aussi les bonnes
pratiques. Puis nous abordons les risques inhérents à la conception préliminaire.
1. Les objectifs
Les objectifs d’une « bonne conception » sont multiples. Elle doit être facile à comprendre
(intelligibilité). La modification des fonctionnalités existantes doit être aussi aisée que possible,
sans reprogrammations excessives (flexibilité), de même que l’implantation de nouvelles
fonctionnalités (extensibilité). Ces évolutions ne doivent pas mettre en péril l’existant
(robustesse, non-‐régression). Certaines parties d’une application doivent pouvoir être reprises
pour en construire d’autres (modularité et réutilisabilité).
Pressman propose un guide pour la qualité de la conception [20], page 219 :
1. A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics (these are discussed later in this chapter), and (3) can be implemented in an
evolutionary fashion, thereby facilitating implementation and testing.
2. A design should be modular; that is, the software should be logically partitioned into elements
or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be implemented
and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.
Selon Pressman, ces qualités ne sont pas dues au hasard mais à l’application de principes
fondamentaux de conception, détaillés sous forme de concepts dans le chapitre 8 de son ouvrage
[20] (Abstraction, Architecture, Patterns, Separation of Concerns, Modularity, Information Hiding,
Functional Independence, Refinement, Aspects, Refactoring, Object-‐Oriented Design Concepts).

2. Les principes
Commentons les principes clés énoncés dans le cours de G. Sunyé [26]
1. La décomposition est une maîtrise de la conception par la décomposition de problèmes en
sous-‐problèmes via l’approche « diviser pour règner » commune aux techniques de conception
ou l’approche de distribution des responsabilités (CRC de Rebecca Wirfs-‐Brock). À l’instar du
découpage en cas d’utilisation, le découpage modulaire produit des modules ni trop gros ni
trop petits.
2. L’abstraction est la maîtrise de la complexité par l’amplification des caractéristiques
importantes et par la suppression des détails moins importants. L’abstraction permet
d’ajourner certaines décisions de conception, reportées à la conception détaillée. Plusieurs
forme d’abstraction existent : fonctionnelle, structurelle, de contrôle, etc. L’abstraction
favorise à la fois la compréhension globale d’un problème et l’organisation (hiérarchique) de la
mise en œuvre. La figure 4 ([20], p. 233) décline la dimension abstraction sur les concepts de
conception.

figure 4 -‐ dimensons du modèle de conception
3. La dissimulation d’informations (information hiding) est un moyen d’abstraction pour la

représentation de données, les algorithmes, les interfaces de bas niveau, la séparation entre
un mécanisme et sa mise en œuvre…
4. La cohérence (cohésion) renforce les liens intra-‐modules dans le découpage modulaire et
porte sur les appels fonctionnels, la répartition en couches, les communications entre
éléments, la relation temporelle, le découpage procédural… On augmente la cohésion. La
cohésion est intimement liée au couplage.

5. Le couplage est le degré de liaison entre les modules. Il porte sur les connexités de
communication, les données partagées, le partage de fonctions, le partage de comportements,
les importations… On réduit le couplage.
6. La réutilisabilité est une qualité qui relève plus du processus que du résultat à proprement
parler. On généralise la conception qui devient adaptable pour à la fois répondre à plus de
besoins, favoriser l’évolution, capitaliser sur une ensemble d’applications similaires…). On
augmente la réutilisabilité.
7. La réutilisation est le fait de reprendre d’autres conceptions en les adaptant. On bénéficie de
la réutilisabilité.
8. L’anticipation de l’obsolescence imagine le futur du système conçu. On doit éviter les
technologies encore immatures, les bibliothèques/frameworks spécifiques à un
environnement, les fonctionnalités peu documentées, les logiciels/matériels d’entreprises qui
ne peuvent pas assurer un support à long terme. À l’inverse, on doit planifier les changements
des technologies et utilise des technologies proposées par différents vendeurs.
9. La portabilité garantit une couverture d’utilisation. On doit utiliser différentes plateformes
pour développer et éviter les bibliothèques exclusives à une seule plateforme.
10. La testabilité garantit l’accès aux testeurs. L’état interne d’un composant doit être accessible
par un programme externe (via une interface contrôlée). Toutes les fonctionnalités d’un
composant doivent être contrôlables par un programme externe, sans passer par une interface
graphique.
3. Des bonnes pratiques en lien avec les principes

Toujours dans son cours [26], G. Sunyé rappelle les bonnes pratiques de conception.
• Principe “Open/Closed” [Bertrand Meyer] : les classes (composants) doivent être
ouvertes aux extensions, mais fermées aux modifications.
• Principe de substitution [Liskov] : les sous-‐classes doivent utilisables à travers l’interface
de la super-‐classe sans que les classes-‐clientes soient au courant.
• Principe d’inversion de dépendance : les détails doivent dépendre des abstractions mais
les abstractions de doivent pas dépendre des détails.
• Séparez l’interface de la mise en œuvre.
• Séparez les préoccupations orthogonales : ne connectez pas ce qui est indépendant. C’est
le principe de responsabilité unique (Single Responsability Principle – SRP).
• Spécifiez ce qu’un composant doit faire avant de spécifier comment.
• KISS: Keep it simple, stupid!
• Travaillez sur différents niveaux d’abstraction.
• Concevez pour l’extensibilité.
• Utilisez le prototype rapide.
• Les dépendances entre composants doivent former un graphe orienté acyclique.
• La dépendance entre deux composants doit suivre le sens de la stabilité (un composant
doit toujours dépendre d’un autre plus stable).

Une partie de ces bonnes pratiques se trouve dans les principes de conception SOLID
détaillés dans le chapitre 8 de [18] :
• Single Responsability Principle (SRP) principe de responsabilité unique
• Open-‐Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)
Lonchamp rappelle d’autres principes dans le chapitre 9 de [18] : inversion du contrôle (IOC)
pour réduire les dépendances, injection de dépendances (DI) liée à DIP et IOC qui se fait
manuellement ou dans les frameworks, KISS, DRY (Don’t Repeat Yourself) qui évite la duplication
de code, YAGNI (You Arent Gonna Need It) qui suggère de n’implanter que ce qui est utile…
Inversement, G. Sunyé dénonce les mauvaises pratiques [26] que nous commentons.
• Conception en profondeur. C’est une erreur de développer des parties sans avoir conçu
l’ensemble. Il ne faut pas confondre le fait de développer indépendamment des « users
stories » avec la conception en profondeur. Ce qui est indiqué ici, c’est qu’on ne
commence à prototyper que lorsque les fondations sont solides.
• Raffinement direct des exigences. Ne partir que des exigences, sans tenir compte de
l’architecture technique est des contraintes non fonctionnelles (notamment de
l’intégration aux applications du patrimoine existant) mène à une inadéquation et une
incohérence qui rendront l’application inexploitable.
• Incompréhension des changements potentiels. Ne pas imaginer les scénarios d’évolution
est un risque important pour la vie de l’application.
• Conception trop détaillée. Une conception trop détaillée est un signe de manque
d’abstraction, c’est-‐à-‐dire que les décisions d’implantation sont déjà présentes. La
conception ne sera alors pas évolutive et rémanente dans le temps.
• Conception ambigüe. Une telle conception est mal interprétée à la mise en œuvre et
induira des incohérences si par exemple différentes équipes de développeurs travaillent
en parallèle.
• Décisions de conception non documentées. La mise en œuvre devient dépendante du
concepteur, elle risque d’être ambiguë et incontrôlable. La traçabilité est une garantie de
consolidation. Nous avons fait l’expérience avec des étudiants qui reprenaient des projets
d’autres étudiants et cassaient la conception pour refaire la même car ils avaient compris,
en pratique les choix de conception.
• Conception incohérente. La conception peut être incohérente parce que plusieurs
personnes ont réalisé des parties différentes sans établir des principes communs. On
trouve le même problème dans le codage où en général on édicte des règles de codage.
4. Les risques
Contrairement à l’expression du besoin et son analyse (chapitre 3), les risques se focalisent
plus sur les aspects techniques, notamment la qualité intrinsèque du logiciel, que son adéquation
au besoin. Nous nous trouvons plus dans le « mal faire » que « pas faire ». En effet, via la

traçabilité des exigences, on essaie de s’assurer que ce qui était prévu est réalisé, c’est de la
vérification. Les risques sont évidemment de se tromper dans les choix de conception.
Le premier risque est de choisir une mauvaise architecture technique, pas adaptée au besoin
ou à la vision, imaginée, de l’évolution du système d’information. Ce risque couvre plusieurs
situations à risques :
• Le manque d’expérience des équipes sur les socles technologiques se traduit par des
remises en cause de choix et des erreurs « de casting ». Pour le préparer et le suivre, on
prévoit des formations, l’apport d’experts du domaine dans différentes phases, un
soutien des équipes d’experts et méthodes. On revoit le cycle itératif et incrémental pour
inclure la montée en compétences…
• La technologie n’est pas mature ou la solution n’est pas compatible avec les standards
existants. On s’expose à des problèmes de maintenance. Il faut intégrer des plans
d’évolution plus lourds et éventuellement s’assurer de la compatibilité lord de la reprise
de l’existant dans un autre standard.
• La solution n’est pas compatible avec le patrimoine technique. On doit s’assurer d’être en
phase avec la production (Devops) et l’expertise maison, ainsi que les évolutions
technologiques visées (projet pilote vs industrialisation).
Un second risque est celui de l’incompatibilité entre l’architecture technique et le modèle
issu de l’étude des besoins. Soit l’architecture ne permet de mettre en œuvre la solution logique
de l’analyse soit les contraintes fonctionnelles ne pourront être satisfaites. Pour gérer ce risque on
s’attachera à bien préparer les itérations de l’élaboration avec du prototypage sur les processus
clé du métier (les besoins critiques).
Un troisième risque est celui de la mauvaise qualité de l’architecture applicative, le
croisement entre l’architecture technique et le modèle d’analyse. Ce risque couvre plusieurs
situations à risques :
• Une expérience insuffisante des équipes sur les socles technologiques fait que les mises
en œuvre sont erronées ou de faible qualité. Pour le préparer et le suivre, on prévoit des
phases d’expertise des solutions dans les premières itérations pour vérifier « qu’on est
dans les règles de l’art ». On revoit ici aussi le cycle itératif et incrémental pour inclure la
montée en compétences…
• On doit être capable d’évaluer la qualité de la conception en permanence, la non-‐
régression, etc. On doit mettre en place des techniques et outils pour préparer ce risque
et le gérer.
• Les aspects méthodes de la conception et support d’industrialisation ont une influence
sur la qualité du résultat. Formation, expertise et accompagnement sont à intégrer dans
le cycle pour suivre et gérer ces risques.
• La solution n’est pas compatible avec le patrimoine applicatif. On doit s’assurer d’être en
phase avec les applications de l’entreprise (pas uniquement celles qui sont à la frontière
du périmètre et avec lesquelles on doit communiquer) et les évolutions prévues pour ces
applications. Ce risque est encore plus fort dans la partie persistance et bases de
données.

Evidemment il y a toujours les risques intrinsèques à la gestion de projet (planification,
gestion des ressources et des équipes…). N’étant pas spécifiques à cette phase nous ne l’abordons
pas.
C. Processus et résultats

Nous détaillons les étapes et la forme du résultat.
1. Étapes de la conception [préliminaire]

Selon Pressman, la conception logicielle est un processus itératif dans lequel les besoins sont
traduits dans un plan de construction du logiciel qui devient progressivement une réalité.
« Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. Initially, the blueprint depicts a holistic view of software.
That is, the design is represented at a high level of abstraction—a level that can be directly traced
to the specific system objective and more detailed data, functional, and behavioral requirements.
As design iterations occur, subsequent refinement leads to design representations at much lower
levels of abstraction. These can still be traced to requirements, but the connection is more subtle.”
Il propose ainsi une séquence d’activités génériques pour la conception ([20], p. 222).
La figure 5 montre l’exploitation des modèles d’analyse pour alimenter les modèles de
conception. Contrairement au modèle de la figure 3, l’architecture technique n’est pas mise en
avant et se confond avec l’architecture applicative. Attention, les couches de conception sont plus
des couches d’abstraction que l’ordre des grandes étapes de la conception.
1. Examine the information domain model, and design appropriate data structures for data
objects and their attributes.
2. Using the analysis model, select an architectural style that is appropriate for the software.
3. Partition the analysis model into design subsystems and allocate these subsystems within the
architecture:
o Be certain that each subsystem is functionally cohesive.
o Design subsystem interfaces.
o Allocate analysis classes or functions to each subsystem.
4. Create a set of design classes or components:
o Translate analysis class description into a design class.
o Check each design class against design criteria; consider inheritance issues.
o Define methods and messages associated with each design class.
o Evaluate and select design patterns for a design class or a subsystem.
o Review design classes and revise as required.
5. Design any interface required with external systems or devices.
6. Design the user interface:
o Review results of task analysis.
o Specify action sequence based on user scenarios.

o Create behavioral model of the interface.
o Define interface objects, control mechanisms.
o Review the interface design and revise as required.
7. Conduct component-‐level design.
o Specify all algorithms at a relatively low level of abstraction.
o Refine the interface of each component.
o Define component-‐level data structures.
o Review each component and correct all errors uncovered.
8. Develop a deployment model.
La figure 5 montre l’exploitation des modèles d’analyse pour alimenter les modèles de
conception. Contrairement au modèle de la figure 3, l’architecture technique n’est pas mise en
avant et se confond avec l’architecture applicative. Attention les couches de conception sont plus
des couches d’abstraction que l’ordre des grandes étapes de la conception.

figure 5 -‐ De l'analyse à la conception, selon Pressman
2. Utilisation d’UML
Les modèles utilisés en conception sont une abstraction des modèles finaux, en ce sens on y
fait apparaître les éléments de conception à haut niveau d’abstraction i.e. sans les détails précis.
Nous les qualifions de modèles d’implantation. Ils étaient très développés dans la méthode de
Booch, mais ils le sont moins en UML. Si la technologie cible le permet, on peut utiliser les
diagrammes du niveau logique (chapitre 3) et les spécialiser (une classe en analyse n’a pas le
même degré de précision qu’en conception.
Deux diagrammes sont spécifiques aux couches basses des modèles : le diagramme de
composants et le diagramme de déploiement.

La notation associée est assez pauvre, nous serons donc succincts dans cette partie, et la
liaison avec les autres diagrammes reste assez vague. Des notations spécifiques sont souvent
choisies de manière ad-‐hoc.
a) Diagrammes de composants
Les diagrammes de composants mettent en évidence les composants (logiciels)

d’implémentation et leurs dépendances. Le formalisme est fortement inspiré de la méthode de
Booch, elle-‐même inspirée par la programmation Ada. Il définit des composants, des interfaces et
des relations de dépendance mais aussi des paquetages et des tâches. La notation couvre des
notions de granularité très différentes et un diagramme de composants complet est une image
exacte de l’architecture logicielle du système.
Un composant est une partie de l’implantation d’un système. Les composants représentent
des modules de programmes sources ou compilés. Un objet, une base de données, un paquetage
de classes, une bibliothèque de programmation sont des exemples de composants.
Le diagramme des composants met en évidence les relations de dépendance entre les types
de composants. On retrouve ici la notion de couplage entre modules. L’interface des types de
composants peut être mise en évidence par la même notation que celle du diagramme des
classes. Par exemple, dans la figure 225, le (type de) composant Emprunts accède aux adhérents
via l’interface de consultation des droits. Emprunts et Adhérents dépendent de la base de
données.
Un stéréotype peut être associé aux types de composants. L’usage de stéréotypes prédéfinis
enrichit la notation des diagrammes de composants. Ainsi Rational Rose propose par défaut des
stéréotypes avec une notation graphique associée (Main programs, Packages, Subprograms,
Tasks) et d’autres stéréotypes (EXE, DLL, Applet, Application, etc.). Les paquetages, tâches et sous-‐
programmes, définissent une notation pour la spécification et une pour la notation. La notation
permet ainsi de représenter n’importe quel programme. Le programme principal sert en
particulier à noter les différentes applications du système. Dans la figure 225, on distingue deux
applications différentes pour le système. Un paquetage est une définition de module (interface,
implantation). Par défaut, une classe est déclarée dans un paquetage. Les paquetages peuvent
être génériques. Les sous-‐programmes correspondent à des routines. Par exemple, une
bibliothèque de fonctions est un sous-‐programme. Les sous-‐programmes peuvent être génériques.
Une tâche est un paquetage avec plusieurs flots de contrôle.
En UML 2, la notion de composants s’inspire des architectures logicielles : les ports
permettent de connecter les composants, les ports peuvent proposer plusieurs interfaces. Chaque
interface propose ou requiert des services (sous forme d’opérations). La structure composite est
visuellement représentable par inclusion de "boîtes" qui montre bien l’encapsulation. Noter qu’un
composant UML 2 est aussi une classe. La figure 6 illustre cette notation.

Source : http://www.uml-‐diagrams.org/component-‐diagrams.html
figure 6 -‐ UML 2 : ports et services (composants)
b) Diagrammes de déploiement
Les diagrammes de déploiement définissent la structure matérielle et la répartition des

artefacts de calcul (processus, composants, objets) sur les unités matérielles (les nœuds). Le
diagramme de déploiement est un graphe dont les sommets (appelés nœuds) sont des ressources
de calcul (processeur ou périphérique) et les arcs (non orientés) sont des supports de
communication (réseau par exemple). Par exemple, dans la figure 228, on utilise une architecture
client-‐serveur pour les accès à la base en interne (réseau local) et une architecture 3-‐tier pour les
accès clients. On peut représenter le contenu des nœuds en y incluant des objets ou des instances
de composants. Nous avons simplement annoté les nœuds par les applications afférentes.
En UML 2 des nœuds à deux dimensions possèdent des conteneurs à composants. Le
diagramme de la figure 7 -‐ Diagramme de déploiement UML 2 -‐ Appli Web en illustre la
présentation1

1
http://www.uml-‐diagrams.org/deployment-‐diagrams-‐examples.html

figure 7 -‐ Diagramme de déploiement UML 2 -‐ Appli Web
c) Notations spécifique pour les applications Web
En 2000, Jim Conallen proposait déjà une notation UML spécifique pour les applications Web
[8]. Les exemples sont développés en ASP.NET2. On peut imaginer adapter la notation à J2EE.
3. La validation
À ce stade, la validation est surtout faite sous forme de lecture croisée par des experts. On
peut aussi vérifier la cohérence avec le style architectural et exploiter les métriques de qualité
lorsqu’elles sont disponibles.
D. Déroulement
Bien que dans le livre sur le processus unifié [17], la conception soit un tout, les auteurs
proposent quatre activités séquentielles : conception architecturale (support de déploiement,
décomposition en sous-‐systèmes, classes principales de conception, mécanismes communs –notre
architecture technique), conception des cas d’utilisation (raffinement), conception des classes de
conception (les classes clés), et conception des sous-‐systèmes. L’objectif est d’alimenter les
modèles dans chacune des vues de la figure 2.
Le processus est itératif sur les activités. Le résultat est une description de modèles de
conception couvrant la logique métier issue de l’analyse et les domaines techniques que sont la
persistance et la distribution (concurrence, communication) à travers le déploiement sur les unités
physiques. Ces modèles de conception doivent rester à un niveau d’abstraction élevé
(architecture) et masquer les détails d’implantation (qui seront explicités dans la conception
détaillée).

2
http://phrogz.net/tmp/webuml/whitepaper/ModelingWebApplications.htm

Il est finalement assez difficile de définir les modèles architecturaux du point de vue de
l’abstraction, c’est le principe du « ni trop ni trop peu ». Nous reviendrons sur l’architecture dans
la section II.
1. Activités
Les activités de la conception architecturale consistent à faire correspondre l’architecture
logique, issue de l’analyse et l’architecture technique (cf figure 3). Nous en traçons l’esquisse ici.
Rappelons que les principes de conception de la section Erreur ! Source du renvoi introuvable.
s’appliquent pleinement ici.
a) Découpage en sous-systèmes
On découpe en sous-‐systèmes si plusieurs applications distinctes existent dans le modèle

d’analyse, si plusieurs architectures techniques sont mises en œuvre (par exemple client lourd ou
léger dans une architecture client-‐serveur web), si les programmes sont déployés sur des nœuds
distincts.
Les interfaces entre sous-‐systèmes sont définies.
b) Raffinement des cas d’utilisation
Les cas d’utilisation enrichis lors de l’analyse par des diagrammes de séquences détaillés font
apparaître un niveau de détail supplémentaire relatifs aux concepts de conception (classes, beans,
pages JSP, pages HTML…). Le raffinement se fait à un certain niveau d’abstraction et se poursuivra
dans la conception détaillée. Fixer le niveau d’abstraction est une affaire d’expérience.
2. Processus
Reprenons la description de Pressman ([20], p. 257). « As architectural design begins, the
software to be developed must be put into context—that is, the design should define the external
entities (other systems, devices, people) that the software interacts with and the nature of the
interaction. This information can generally be acquired from the requirements model and all other
information gathered during requirements engineering. Once context is modeled and all external
software interfaces have been described, you can identify a set of architectural archetypes. An
archetype is an abstraction (similar to a class) that represents one element of system behavior. The
set of archetypes provides a collection of abstractions that must be modeled architecturally if the
system is to be constructed, but the archetypes themselves do not provide enough implementation
detail. Therefore, the designer specifies the structure of the system by defining and refining
software components that implement each archetype. This process continues iteratively until a
complete architectural structure has been derived. » Les détails sont donnés en page 258 de [20].
E. Support
Les activités de support sont similaires à celles de l’analyse, sauf pour la partie prototypage
où elles sont proches du développement logiciel.

II. Architectures logicielles
Les architectures logicielles font l’objet de recherches actives dans les années 2000. En sont
issues trois sortes de travaux : les langages de descriptions d’architectures (Architecture
description languages -‐ ADLs) qui sont dédiés uniquement au logiciel, les architectures à
composants (Component-‐Based Systems -‐ CBS) et plus récemment les architectures à services
(Services Oriented Architectures -‐ SOA). Il est évident que nous ne couvrirons pas le domaine,
l’idée est de faire un rapide tour d’horizon pour se faire une idée du sujet et expliciter son
application.
Nous commencerons par définir et illustrer le concept puis nous verrons les styles
architecturaux qui permettent, à l’instar des patterns, de rapidement classer le type d’application.
Nous brosserons ensuite le tableau dans le cadre J22 avant de proposer des éléments pour le cas
fil rouge.
A. Définitions
Citant la norme IEEE 1471-‐2000, Jacques Lonchamp définit ainsi l’architecture.
Définition 1. L’architecture d’un système logiciel3 décrit son organisation générale, exprimée en
termes de ses composants, des relations entre ses composants et avec l’environnement, et
des principes qui gouvernent sa conception et son évolution.
On le voit, l’architecture est à la fois le « blue print » et son mode d’emploi. Elle explique les
choix et la manière de les maintenir.
La difficulté principale dans l’expression d’une architecture logicielle est que qu’il ne
s’agit pas simplement d’abstraction mais souvent de structuration. En effet, au niveau de
l’implantation les concepts principaux sont ceux de la programmation à objets (en plus
de la persistance, des réseaux et des affichages IHM), il n’existe pas de composants ou
services. Dès lors, on doit grouper, reformuler, structurer pour présenter une
architecture. Il y a donc un décalage fort entre l’architecture et sa mise en œuvre.
Dans une des bibles4 sur le sujet [4], Clements et al. suggèrent la définition suivante :
Définition 2. The software architecture of a system is the set of structures needed to reason
about the system, which comprise software elements, relations among them, and properties
of both.
La définition est précisée par un certain nombre de remarques. Bien que les décisions
architecturales importantes soient prises au début, ce n'est pas systématique dans un
développement itératif. L'architecture est un ensemble de structures logicielles et non une seule
structure. Les structures sont de trois types : les modules, les interactions (connexions) et le

3
Comme le fait remarquer Jacques Lonchamp, ce système ne comprend pas que des composants logiciels, il y a aussi
des bases de données, des flux de messages, ou d’événements, des fichiers de configuration, et des éléments
physiques pour le déploiement (serveurs, navigateurs, intergiciels …).
4
L'autre est l'ouvrage de Garlan et Shaw [25].

déploiement (placement dans l'organisation, le développement, l'installation et l'exécution).
L'architecture est une abstraction. Chaque système logiciel possède une architecture.
L'architecture inclut le comportement (évolution et traitements). Toutes les architectures ne sont
pas bonnes, les auteurs consacrent de nombreux chapitres aux critères qualitatifs d'évaluation.
L'architecture étant une abstraction complexe, il est nécessaire de l'observer de différents points
de vue. On retrouve ici l'idée de la figure 2 que nous ne développons pas plus ici.
Il ne faut pas confondre architecture (système) avec architecture (d'entreprise). Les deux
disciplines incluent le logiciel mais ne se résument pas à cela. L'architecture système vise
à définir la correspondance entre les fonctionnalités et les composants matériels et
logiciels. La seconde décrit la structure et le comportement d'une organisation
(processus, flux d'information, organisation...)5.
S’il n’est besoin de montrer la difficulté à saisir le sujet, soulignons que J. Printz, qui consacre
un ouvrage complet à l’architecture logicielle [21] ne déclare tenter une définition qu’à la page 59
de son ouvrage, définition qu’il ne donne pas formellement en synthétisant et analysant les
définitions les plus courantes pour y voir plutôt des règles d’architecture.
B. Classifications d'architecture : genres, styles et patterns

Pour faciliter tant la lecture que l'utilisation, il est intéressant de classer les modèles
d'architectures. A ce sujet, on cite couramment les styles architecturaux et les patterns
architecturaux, la distinction entre les deux est parfois floue. Avant de les aborder, faisons un
détour par le genre architectural.
1. Le genre architectural
Le genre architectural proposé par Grady Booch et repris par Pressman [20], qui correspond
plus à un type d'application qu'un type (un style) d'architecture6.
• Artificial intelligence—Systems that simulate or augment human cognition, locomotion, or other
organic processes.
• Commercial and nonprofit—Systems that are fundamental to the operation of a business
enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing data, for
connecting users of that data, or for presenting data at the edge of an infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia artifacts.
• Devices—Systems that interact with the physical world to provide some point service for an
individual.
• Entertainment and sports—Systems that manage public events or that provide a large group
entertainment experience.
• Financial—Systems that provide the infrastructure for transferring and managing money and
other securities.
• Games—Systems that provide an entertainment experience for individuals or groups.

5
Revoir le chapitre 2 de ce cours à ce sujet.
6
On retrouve de telles classifications dans les standards de l'OMG.

• Government—Systems that support the conduct and operations of a local, state, federal, global, or
other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical research.
• Military—Systems for consultation, communications, command, control, and intelligence (C4I) as
well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic software services.
• Platforms—Systems that sit just above operating systems to provide advanced services.
• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point service.
2. Le style architectural
Les styles architecturaux décrivent une certaine philosophie d'organisation selon Lonchamp
[18]. La classification initiale est due à Garlan et Shaw [25] n'a guère bougé même si des variations
existent. Le style est à la fois une grille de lecture et un guide de construction.
Pressman [20] distingue cinq styles, ceux de Lonchamp [18] sont peu ou prou les mêmes.
• L'architecture basée sur les données (dépôt de donnée) dans laquelle la base de donnée
est centrale, les autres composants l'invoquent pour consulter, ajouter, modifier ou
supprimer des données (figure 8). Une variante existe, appelée tableau noir, dans laquelle
des traitements sont déclenchés sur le dépôt -‐ solveur de problème par exemple).

figure 8 -‐ style architectural centré sur les données
• L'architecture flots de données dans laquelle les composants autonomes agissent sous
l'impulsion de données. Des variantes existent comme les traitements batch, tubes et
filtres (figure 9), ou la boucle de contrôle. Ces variantes sont souvent des patterns.

figure 9 -‐ style architectural flots de données
• L'architecture appel et retour avec flot de contrôle unique qu'on retrouve dans le
classique découpage fonctionnel hiérarchique (figure 10).

figure 10 -‐ style architectural appel et retour
• Architectures orientées objets dans lesquelles les composants encapsulent données et

traitements. Peu détaillées chez Pressman [20], elles le sont plus chez Lonchamp [18] qui
les nomme composants distribués et distingue les architectures clients-‐serveurs, les
architectures pair à pair (P2P), les architectures à base de messages, les objets distribués,
les architectures orientées services.
• Architectures en couche, dans lesquelles les composants font appel à des composants de
plus bas niveaux pour offrir des services à des composants de plus haut niveau, on les
retrouve dans l'organisation des protocoles de communication en réseaux ou dans un
rangement des interfaces vers les données pour le web (figure 11). Elles sont appelées
architectures hiérarchiques chez Lonchamp [18], pour qui l'architecture en couche est
une variante, d'autres variantes sont proposées : architecture n-‐tier.

figure 11 -‐ Style architectural en couches
On retrouve régulièrement des architectures en couches pour les logiciels système et

réseaux. À titre d’exemple, prenons une architecture SOA où l’exploitation des services apparaît
en haut tandis que la mise en œuvre est en bas.

Source : http://eprints.cs.univie.ac.at/2366/1/porto-‐soa.pdf
figure 12 -‐ Architecture SOA en couches
3. Le patron architectural
Les patterns architecturaux décrivent des assemblages précis pour résoudre un problème
particulier dans un contexte donné [18], à l'instar des patterns de conception que nous
aborderons dans le chapitre suivant. Plusieurs classifications existent ([13], [24]). Reprenons celle
de Lonchamp [18] qui lui-‐même reprend [24].
• Patrons généraux d'organisation
o layers,
o pipes and filters,
o blackboard,
o shared repository,
• Patrons de systèmes interactifs

o MVC,
o PAC (Presentation-‐Abstraction-‐Control) ou MVC hiérarchique,
• Patrons de systèmes distribués, catégorie très riche où on retrouve des design patterns.
o infrastructures de distribution (message channel message router, publisher-‐subscriber,
broker, proxy...)
o gestion d'événements (reactor, proactor...),
o interfaces (introspection, extension, dynamic invocation...),
o composants (whole-‐part, master-‐slave, composite...),
o gestion du contrôle,
o concurrence et synchronisation,
o interactions (observer, command...),
o adaptation et extension,
o gestion de ressources,
o accès aux bases de données...
• Patrons de systèmes évolutifs
o micro-‐noyau,
o réflexive.
Dans son ouvrage sur la conception web avec UML [8], Conallen propose trois patterns
architecturaux pour le web :
• Client web léger avec un navigateur standard sur le poste client. Derrière, il existe de
nombreuses variantes d'organisation de la logique métier sur le serveur.

figure 13 -‐ Pattern client web léger

• Client web lourd avec une application cliente prenant en charge une partie de la logique
métier (HTML dynamique, applet Java, contrôles ActiveX...).

figure 14 -‐ Pattern Client lourd
• Livraison web pour des applications distribuées avec en plus d'HTML pour la
communication client serveur, des protocoles IIOP ou DCOM ou maintenant des services
web.

figure 15 -‐ Pattern livraison Web
C. Présentation et exemples

Lorsque l’architecture est complexe, on utilise des notations hiérarchiques telles que les
structures en blocs (figure 16) ou en couche (figure 17). L'objectif est bien de montrer une vue
explicite et pédagogique sur un ensemble éminemment complexe. Les parties hautes sont proches
des utilisateurs et parties basses proches du matériel. Dans [21], J. Printz traite les architectures
d’un point de vue abstrait.

source: http://www.ibm.com/support/knowledgecenter/SSWSR9_11.4.0/com.ibm.mdmhs.overview.doc/architecture.html?lang=fr
figure 16 -‐ Architecture et concepts pour InfoSphere MDM (blocs)

http://immobilis.developpez.com/articles/dotnet/architecture-‐multicouche-‐asp-‐net/
figure 17 -‐ Architecture multi-‐couche ASP.NET

En exploitant les notations UML, on trouvera des paquetages (dossiers, packages) ou des
diagrammes de composants pour montrer les modules. On utilise aussi les diagrammes de
déploiement pour mettre en évidence la répartition (revoir à ce titre la section I.C.2). Nous nous
contentons ici de commenter quelques exemples issus de la littérature.
Les exemples de Conallen (figure 13, figure 14 et figure 15) utilisent des simples paquetages
pour établir les composants et leurs dépendances sur une architecture n-‐tier.
Dans la figure 7, ce sont des composants et des relations qui matérialisent les modules sur
un déploiement.
Dans le cas YAPS, Yet Another Pet Store, développé par Antonio Goncalves dans [14]7,
l’architecture logique de l’application YAPS proposée propose 5 couches et 6 blocs sous forme de
paquetages stéréotypes en composants comme le montre la Erreur ! Source du renvoi
introuvable..

figure 18 -‐ YAPS architecture en 6 couches
L’architecture technique projette cette architecture logique sur un ou plusieurs

emplacements physiques à travers le diagramme de déploiement (Erreur ! Source du renvoi
introuvable.).

7
Nous la reverrons en détail au chapitre 6.

figure 19 -‐ YAPS Architecture technique
Dans [19], J. Molière propose une description épurée des couches sans détailler les
composants logiciels (figure 20). Il s'agit plus d'une architecture technique qu'applicative même si
cette dernière, implicite du point de vue des modèles dans l'ouvrage, est supportée dans la même
organisation.

figure 20 -‐ Architecture Web J2EE en 5 couches
• Client Navigateur, Applets, Java Web Start...

• Présentation de données partie serveur d’application Web rendant possible l’accès de
clients riches ou légers,
• Services métiers composants fonctionnels,
• Services techniques composants gérant la persistance, la concurrence, les transactions...
• Stockage SGBD, XML, fichiers.

Dans le blog de Thibaut Delcroix, une comparaison est proposée pour les architectures SOA
et non SOA (figure 21). L’approche SOA promeut une architecture plus modulaire et moins
monolithique et donc a priori plus apte aux changements.

http://www.thibaut-‐delcroix.fr/blog/article-‐34-‐introduction-‐a-‐la-‐soa-‐ou-‐architecture-‐orientee-‐services.html
figure 21 -‐ Architecture SOA et non SOA
D. Architecture Web
Brossons un rapide tour d’horizon des architectures Web avant d’en voir les principales
mises en œuvre.
1. Introduction
Les architectures Web correspondent à une forme particulière de client-‐serveur8 en (au
moins) trois tiers, le tiers client (présentation), le tiers intermédiaire (applicatif ou métier) et le
tiers ressources (bases de données, autres applications). Elles sont détaillées dans le chapitre 14
[18]. La figure 22 illustre cette architecture abstraite.

8
Le côté serveur occupe les deux derniers tiers.

figure 22 -‐ Architecture Web
En pratique, il existe une grande variété de solutions (composants) qu’il faut choisir et faire
cohabiter au mieux [18]. Toute l’expérience des développeurs web (et notamment J2EE) consiste à
maîtriser ces solutions, techniques et autres frameworks.
Pour la conception de solutions web, on s’attachera à mettre en évidence des patterns qui
résolvent de manière standard les problèmes associés à ce type de conception (voir le chapitre 5 à
ce sujet). J. Lonchamp met ainsi en évidence quelques patterns pour une architecture Web J2EE
dans l’exemple de la figure 23.

figure 23 -‐ Patterns pour une architecture Web
À ce sujet, citons un poste du blog octo9 : « Les applications Web évoluent. Depuis les
premiers sites en HTML statique jusqu’aux applications AJAX de ces dernières années, en passant
par les multiples technologies de sites Web dynamiques (PHP, ASP, Java, Rails…), les architectures
applicatives et les outils pour les mettre en place connaissent régulièrement des avancées majeures
et des points de ruptures. ». Le schéma de la figure 24 illustre l’évolution des architectures
d’applications Web dans lequel la part côté client monte avec le temps.

9
http://blog.octo.com/les-‐nouvelles-‐architectures-‐front-‐web-‐et-‐leur-‐impact-‐sur-‐les-‐dsi-‐partie-‐1/

figure 24 -‐ Evolution des architectures Web
Les nouvelles architectures facilitent l’intégration d’applications standards avec celles du

web mobile (responsive) comme l’illustre la figure 25.

figure 25 -‐ Applications Web et Mobiles

Dans ce cours nous ne nous attardons pas sur les technologies mobiles. Consulter ([9],
[10]) pour en savoir plus à ce sujet.
2. Framework Web
Dans un article introductif10, Gunjan Samtani et Dimple Sadhwani expliquent et illustre la
notion de framework pour les applications Web, en lien avec les Web services. Synthétiquement,
les fonctions attendues sont celles de la figure 26 : gestion des contenus, des communications via
les réseaux, de la persistance, de la sécurité, des transactions, etc.

figure 26 -‐ Fonctions d'un framework web
Deux grandes catégories de frameworks se sont imposées pour les applications web : J2EE
de Sun et ASP.NET de Microsoft.
3. ASP.NET
ASP.NET est une solution pour créer des sites Web basés sur les standards HTML5, CSS3 et
JavaScript dans le monde Windows.
L’architecture de la version 4.5 est donnée dans la figure 2711. Elle est basée sur le
framework à composants .NET et le langage de description de pages web avec des contrôles.

10
http://nws.noaa.gov/oh/hrl/hseb/docs/ApplicationFrameworks.pdf
11
http://www.dotnet-‐tricks.com/Tutorial/aspnet/SaJc221013-‐Understanding-‐Detailed-‐Architecture-‐of-‐ASP.NET-‐
4.5.html

figure 27 -‐ Architecture ASP.NET

L’architecture évolue pour prendre en compte les nouvelles technologies, à savoir la
mobilité du côté clients et le cloud du côté serveur12. La version 2015 est illustrée par la figure 28
et la figure 29.

figure 28 -‐ Evolution ASP.NET

12
https://blogs.msdn.microsoft.com/cesardelatorre/2014/11/18/what-‐is-‐net-‐core-‐5-‐and-‐asp-‐net-‐5-‐within-‐net-‐2015-‐
preview/

figure 29 -‐ Architecture ASP.NET 5
Le langage Visual Basic intègre les éléments de la solution (figure 30).

figure 30 -‐ Architecture de développement ASP.NET 5
4. J2EE
Nous invitons le lecteur à consulter notre introduction au sujet13.
Citons wikipedia14. Java Enterprise Edition, ou Java EE (anciennement J2EE), est une
spécification pour la technique Java d'Oracle plus particulièrement destinée aux applications
d’entreprise. Ces applications sont considérées dans une approche multi-‐niveaux. Dans ce but,
toutes les implémentations de cette spécification contiennent un ensemble d’extensions au
framework Java standard (JSE, Java Standard Edition) afin de faciliter notamment la création
d’applications réparties. La figure 31 illustre le positionnement de J2EE par rapport à JSE, le
framework Java.

13
http://pagesperso.lina.univ-‐nantes.fr/~andre-‐p/download/dvtj2ee.pdf
14
https://fr.wikipedia.org/wiki/Java_EE

figure 31 -‐ Positionnement de J2EE par rapport à Java
Un serveur d’application J2EE implante la spécification. Le web client communique avec le

serveur en HTTP tandis que les applets et applications le font avec RMI, de même que la
communication entre servlets et EJB.

http://tekslate.com/distributed-‐systems-‐j2ee-‐architecture/
figure 32 -‐ Architecture J2EE

Différents composants peuvent être contenus dans une implémentation Java EE :
• Servlet : Composant représentant le C (Controller) du paradigme MVC,
• Portlet : Conteneur Web (extension de l’API Servlet),
• JavaServer Pages (JSP) : Framework Web,
• Java Standard Tag Library (JSTL) : bibliothèque de balises pour les JSP,
• JavaServer Faces (JSF) : Java Server Face, Framework Web,
• EJB : Composants distribués transactionnels,
• JNDI : API de connexion à des annuaires, notamment des annuaires LDAP, et espace de noms
d’objet (ENC),
• JDBC : API de connexion à des bases de données,
• Java Message Service (JMS) : API de communication asynchrone par message,
• JCA : API de connexion, notamment à des PGI,

• JavaMail : API de gestion des mails,
• JMX : Extension d’administration des applications,
• JPA : API de gestion de la persistance des données,
• JTA : API de gestion des transactions,
• Java API for XML Processing (JAXP) : API d’analyse XML,
• JAXM : API de communication asynchrone par XML,
• JAX-‐RPC / JAX-‐WS : API de communication synchrone par XML, par exemple à l’aide du protocole
SOAP,
• JAXB : API de sérialisation par XML,
• JAXR : API de gestion des registres XML, permettant d’enregistrer des Web Services en ebXML,
• Java RMI : API de communication distante entre des objets Java,
• Java IDL : API de communication entre objets Java et objets non Java, via le protocole CORBA.

figure 33 -‐ Architecture de Java EE 5 [14]
Les serveurs d’application peuvent être open-‐source (JBoss, JRun, JOnAS, Geronimo,
OpenEJB, JFox, Tomcat…) ou payants (Websphere IBM, WebLogic BEA, Oracle Application
Server…).
Les serveurs d'applications sont certifiés (source wikipedia) selon leur compatibilité avec la
norme Java EE 7 :
• Oracle GlassFish Server Open Source Edition 4.03,4
• TmaxSoft TMAX JEUS 85
• RedHat Wildfly 8.0.06
ou la norme Java EE 6 :

• Oracle GlassFish Enterprise Server v3, basé sur le serveur open-‐source GlassFish
• Oracle WebLogic Server 12c de Oracle Corporation
• JBoss AS 7.x (profil web uniquement pour la version 7.0.x), JBoss AS 6 (profil web uniquement)7
• JEUS 7, un serveur d'applications de TmaxSoft
• Apache Geronimo 3.0
• IBM WebSphere Application Server 8.0
• IBM WebSphere Application Server Community Edition 3.0, basé sur Apache Geronimo
• Fujitsu Interstage Application Server

• Caucho Resin 4.0.17 (profil web uniquement)
Le modèle d’architecture d’entreprise de la figure 34 met en évidence les différentes

couches et composants associés, celui de la figure 35 met en évidence le fonctionnement de type
MVC.

http://www.oracle.com/technetwork/java/javaee/appmodel-‐135059.html
figure 34 -‐ Modèle d’architecture d’entreprise

http://www.commentcamarche.net/j2ee/j2ee-‐intro.php3
figure 35 -‐ MVC et J2EE
15
Un exemple d’implantation d‘architecture pour web services sous Eclipse est commenté dans un article sur JST . Il
permet de se faire une idée de l’envers du décor.
5. Comparaison
Une comparaison des deux frameworks est proposée16 qui permet de mesurer la complexité
des couches logicielles et la variété des solutions.

15
https://eclipse.org/webtools/jst/components/j2ee/api/j2ee_models_overview.html
16
https://msdn.microsoft.com/en-‐us/library/aa478961.aspx

figure 36 -‐ Comparaison ASP.NET -‐ J2EE
Les deux frameworks ne sont pas directement compatibles mais les solutions sont
intégrables comme le montre la figure 37.

http://nws.noaa.gov/oh/hrl/hseb/docs/ApplicationFrameworks.pdf
figure 37 -‐ Intégration de frameworks via les services web
Nous n’avons pas vu d’études récentes sur l’utilisation, les deux plateformes étaient
réparties de manière équilibrée. Avec le mobile et Android, Java devrait prendre l’avantage.
6. Quelques exemples commentés

La plupart des ouvrages traitant de conception pour les architectures web montrent d’un
côté les architectures techniques J2EE ou .NET et de l’autre la conception détaillée à base de
scénarios faisant apparaître des éléments des différentes couches mais peu montrent
l’architecture applicative, c’est-‐à-‐dire le mapping du métier sur l’architecture technique. Ce sont

alors des architectures indirectes. Examinons quelques exemples tirés de la littérature ou du web.
Nous verrons aussi des contre-‐exemples.
a) Exemples
Comme exemple d’architecture indirecte, citons [8] où Conallen met en avant les 3 patrons
de conception mais la conception en ASP.NET apparait dans des diagrammes de conception
détaillée, avec une notation UML spécifique pour le web via les stéréotypes. Il y a donc une sorte
de rupture.
Dans [15], Kadima va jusqu’à détailler les méta-‐modèles EJB pour de la transformation mais
la mise en œuvre ne présente pas de vue architecturale.
Dans [14], une présentation par composants UML et nœuds de déploiement est proposée
pour déployer des composants sur l’architecture technique J2EE (figure 19 reprise ci-‐après). Le
serveur physique comporte une base de données et un serveur d’applications. Ce dernier est
composé d’un conteneur de servlets et d’un conteneur d’EJB. Pour la partie web, on retrouve les
JSP, JSF et JSTL, alors que le conteneur d’EJB héberge les beans. L’application YAPS couvre diverses
implantations de J2EE avec des clients lourds ou légers et une interface de service Web avec des
partenaires. Les services web sont déployés sur les serveurs des partenaires.

Dans [20], Pressman établit d’abord un diagramme de contexte architectural pour
l’application SafeHome (figure 38) avant de décrire les composants et leurs relations (figure 39).

figure 38 – Diagramme de contexte architectural pour l’application SafeHome
Les composants sont responsables des liens avec le contexte.

figure 39 – Structure architecturale de application SafeHome avec les composants de premier niveau
La figure 40 donne un exemple d’architecture multi-‐couches représentée avec UML. Elle

donne une sorte de patron de représentation de l’architecture.

http://www.uml-‐diagrams.org/multi-‐layered-‐application-‐uml-‐model-‐diagram-‐example.html
figure 40 -‐ Exemple d’architecture multi-‐couches en UML
On trouve sur le même site un exemple de déploiement pour le web qui illustre bien le
problème de la répartition sur le réseau de nœuds de déploiement (figure 41).

http://www.uml-‐diagrams.org/web-‐application-‐clusters-‐uml-‐deployment-‐diagram-‐example.html
figure 41 -‐ Clustered deployment of J2EE web application
Dans [4], différents patterns architecturaux sont présentés, notamment une mise en œuvre
J2EE (figure 42 -‐ Architecture n-‐tier du système Adventure Builder) SOA (figure 43) pour un
système appelé Adventure Builder, OPC signifie ici ‘Order Processing Center’, qui centralise les
requêtes.

figure 42 -‐ Architecture n-‐tier du système Adventure Builder

figure 43 -‐ Architecture SOA du système Adventure Builder
Bien que ce ne soit pas le propos, mais tout de même lié aux contraintes non fonctionnelles
de l’application, nos recherches nous ont conduit à ce croisement entre architecture technique et
sécurité. Cela fait partie des préoccupations à inclure dans la conception. Les contrôles
apparaissent à tous les niveaux et entre les couches logicielles.

https://msdn.microsoft.com/en-‐us/library/ff648647.aspx
figure 44 -‐ Architecture et sécurité
De même, bien que ce soit en dehors de notre périmètre, la délocalisation dans le cloud a
aussi une influence sur l’architecture. Sans entrer dans les détails, on ajoute des couches
supplémentaires pour des données (figure 45) ou des services distants (figure 46).

https://www.safaribooksonline.com/library/view/mastering-‐aws-‐development/9781782173632/ch08s04.html
figure 45 -‐ Migration dans le Cloud
Il est évident que plus l’application a un périmètre important (nombre de fonctions et

nombre d’usagers) ou bien plus elle est répartie sur des dispositifs physiques différents
plus l’architecture est complexe et aussi plus les aspects non fonctionnels prennent de
l’importance. La répartition est mise en œuvre par de l’intergiciel (middleware).

http://www.ibm.com/developerworks/cloud/library/cl-‐ibm-‐leads-‐building-‐web-‐app-‐hosting-‐cloud-‐solutions-‐trs/index.html
figure 46 -‐ Exemple d'architecture logicielle pour le Cloud
Toujours à titre d’illustration, car nous ne détaillons pas ces architectures, les applications
mobiles mobilisent aussi beaucoup de dispositifs et de couches logicielles. La figure 47 met en
évidence ces dispositifs et les logiciels qui y sont attachés. Le middleware est assuré par des
communications entre services.

https://aws.amazon.com/fr/blogs/aws/innovative-‐social-‐gaming-‐and-‐location-‐based-‐services-‐startup-‐in-‐the-‐cloud/
figure 47 -‐ Architecture pour applications mobiles
Ce qui précède n’est qu’un échantillon un peu aléatoire. Voyons aussi d’autres exemples qui
ne représentent pas vraiment le concept d’architecture.
b) Contre-exemples
De manière plus détaillée, les architectures sont explicitées par des diagrammes UML
comme l’illustre la figure 48, due à Conallen qui montre via des éléments stéréotypes (spécialisés)
les composants de conception d’une application Web. Néanmoins cette vue correspond plus à de
la conception détaillée qu’architecturale de par son niveau de détail.

http://flylib.com/books/en/2.141.1.110/1/
figure 48 – Vue conceptuelle des composants d’implantation
Il en est de même pour l’exemple de la figure 49 qui met plus en évidence une
« collaboration » d’éléments de l’application que l’architecture et la manière de catégoriser les
éléments.

http://doi.ieeecomputersociety.org/cms/Computer.org/dl/trans/ts/2010/01/figures/tts20100100962.gif
figure 49 – Organisation d’éléments de l’architecture (formulaires, jsp…)

La figure 50 met bien en évidence des composants dans le framework, mais là encore ils sont
plus près de la conception détaillée qu’architecturale.

http://www.codingthearchitecture.com/images/2014/20140709-‐techtribesje-‐webapp.png
figure 50 -‐ Composants dans une architecture Spring
L’exemple suivant illustre l’architecture d’entreprise qui inclut celle des applications et la
vision des processus métier.

http://enterprisearchitect.blogs.ilrt.org/
figure 51 -‐ Enterprise Architecture at Bristol

c) L’art de bien présenter et représenter
Terminons par une série sur l’art de visualiser des architectures17, en lien avec le concept de
cartographie. La figure 52 montre le côté visuel et schématique des présentations. Finalement, ce
qui prime est le point de vue exprimé et que l’idée soit bien communiquée et comprise.

figure 52 -‐ Des visions architecturales
À titre d’exemple, l’application PetClinic illustre la prise en compte du framework Spring

pour construire une application Web en Java. C’est une architecture en couches basée sur le
patron MVC avec des contrôleurs pour gérer l’application et un service qui implante la logique
métier en lien avec des dépôts de données. La figure 53 illustre l’architecture. Elle manque
d’abstraction au sens des diagrammes vus précédemment mais a l’avantage d’être en phase avec
les développements et donc évolutive. Elle est aussi trop détaillée.

17
https://leanpub.com/visualising-‐software-‐architecture/read

figure 53 -‐ Application PetClinic
Nous avions vu auparavant le diagramme de contexte (figure 38). Celui-‐ci peut être affiné
comme le montre la figure 54 (ce n’est pas le même exemple) en mettant en évidence une partie
de l’architecture applicative.

figure 54 -‐ Diagramme de contexte détaillée du cas techribes

Le composant ContentUpdater peut lui-‐même être décrit plus finement pour mettre en
évidence ses interactions avec les autres composants (figure 55). La question est de savoir si cela
relève de la conception détaillée ou pas.

figure 55 -‐ Contenu du composant ContentUpdater du cas techribes
En raffinant, notamment sur l’architecture technique en Spring, on obtient le diagramme de

la figure 56, similaire à celui de la figure 50.

figure 56 -‐ Diagramme détaillé des composants spring du cas techribes

III. Concevoir l'architecture
Nous donnons ici quelques éléments issus de différentes approches pour concevoir son
architecture. Il s’agit d’un processus itératif par nature qui est évidemment facilité par
l’expérience à la fois du métier et de la technique. Nous verrons que les principes convergent.
A. Démarche dans le processus unifié

Dans le processus unifié [23] p. 232, la conception architecturale est confiée aux architectes.
Elle consiste à mettre en évidence les modèles de conception et de déploiement en identifiant à
partir de l’analyse les éléments suivants : nœuds et réseau du déploiement, sous-‐systèmes et leurs
interfaces classes fondamentales et mécanismes génériques de conception (persistance,
distribution, performance. La figure 57 schématise cet objectif. Elle met en évidence une
traçabilité assez directe entre l’analyse et la conception architecturale bien que cette activité soit
confiée aux architectes et non aux analystes ou aux concepteurs.

figure 57 -‐ Modèles de la conception architecturale -‐ RUP
Rappelons que l’architecture est un des fondements du processus unifié.
Le processus de mise au point est itératif, une version est proposée dans la figure 58 ; il est
aussi itératif sur l’ensemble du processus de développement. La figure 5818 montre que l’on part
toujours d’un existant architectural.

18
Il s’agit d’un document IBM et non pas d’un document RUP.

http://slideplayer.com/slide/7482510/
figure 58 -‐ Processus de définition d'une architecture dans le RUP
B. Démarche ATAM
Regardons maintenant l’approche de Pressman ([20], p. 262) qui reprend une méthode
d'analyse proposée par le SEI. Citons :
An Architecture Trade-‐Off Analysis Method
The Software Engineering Institute (SEI) has developed an architecture trade-‐off analysis
method (ATAM) that establishes an iterative evaluation process for software architectures. The
design analysis activities that follow are performed iteratively:
1. Collect scenarios. A set of use cases is developed to represent the system from the user’s point
of view.
2. Elicit requirements, constraints, and environment description. This information is determined as
part of requirements engineering and is used to be certain that all stakeholder concerns have
been addressed.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios and
requirements. The architectural style(s) should be described using one of the following
architectural views:
o Module view for analysis of work assignments with components and the degree to
which information hiding has been achieved.

o Process view for analysis of system performance.
o Data flow view for analysis of the degree to which the architecture meets functional
requirements.
4. Evaluate quality attributes by considering each attribute in isolation. The number of quality
attributes chosen for analysis is a function of the time available for review and the degree to
which quality attributes are relevant to the system at hand. Quality attributes for architectural
design assessment include reliability, performance, security, maintainability, flexibility,
testability, portability, reusability, and interoperability.
5. Identify the sensitivity of quality attributes to various architectural attributes for a specific
architectural style. This can be accomplished by making small changes in the architecture and
determining how sensitive a quality attribute, say performance, is to the change. Any attributes
that are significantly affected by variation in the architecture are termed sensitivity points.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in
step 5. The SEI describes this approach in the following manner:
Once the architectural sensitivity points have been determined, finding trade-‐off points
is simply the identification of architectural elements to which multiple attributes are
sensitive. For example, the performance of a client-‐server architecture might be highly
sensitive to the number of servers (performance increases, within some range, by
increasing the number of servers). . . . The number of servers, then, is a trade-‐off point
with respect to this architecture.
These six steps represent the first ATAM iteration. Based on the results of steps 5 and 6, some
architecture alternatives may be eliminated, one or more of the remaining architectures may be
modified and represented in more detail, and then the ATAM steps are reapplied19.
Cette méthode reprend le principe du développement orienté par l'architecture, un des
principes de la méthode RUP.
C. Démarche ADD
Bass et al. consacrent le chapitre 17 de leur ouvrage [4] à la conception de l’architecture.
Leur stratégie de conception architecturale est basée sur trois idées, la décomposition, la
conception des besoins prioritaires, la génération et le test.
• Décomposition. On décompose en sous-‐systèmes, composants, modules et autres
éléments mais on doit conserver la qualité globale définie par plusieurs attributs tels que
la disponibilité, la performance, l’évolutivité… pour lesquels les auteurs proposent des
tactiques. Par ailleurs s’appuyer sur des patterns facilite la décomposition.
• Conception des besoins prioritaires. Certains besoins sont significatifs du point de vue
architectural, convertibles en attributs qualité. Un processus de consultation permet de
les exhiber (business goals) et les prioriser.

19
The Software Architecture Analysis Method (SAAM) is an alternative to ATAM and is well-‐worth examining by those
readers interested in architectural analysis. A paper on SAAM can be downloaded from
www.sei.cmu.edu/publications/articles/saam-‐metho-‐propert-‐sas.html.

• Génération et le test. On pose des hypothèses (existant, frameworks, patterns et
tactiques, décomposition de domaine, checklist) et on teste la qualité de l’architecture
selon la checkist. C’est un processus itératif.
La méthode ADD (Attribute-‐Driven Design Method) met en œuvre ces idées dans un
processus itératif :
a) Choisir la partie du système à concevoir.
b) Identifier les besoins significatifs du point de vue architectural (ASR) de cette partie
c) Créer et tester la conception de cette partie.
d) Inventorier les besoins restant et sélectionner pour l’itération suivante
e) Recommencer en a) jusqu’à ce que les ASR soient satisfaits.
http://www.sei.cmu.edu/library/assets/klein1.pdf
Notons aussi que de nombreux conseils sont disséminés dans l’ouvrage tant sur l’adaptation
de l’architecture à son contexte que les qualités attendues d’une architecture logicielle en
proposant des tactiques adaptées à chacune de ces qualités.
D. Démarche de Cloux

P.-‐Y. Cloux consacre le chapitre 6 de son ouvrage [7] à l’élaboration de l’architecture. À
l’instar des autres auteurs, il intègre la conception d’architecture dans un processus itératif,
d’amélioration continue en l’occurrence (figure 59).

figure 59 -‐ Spirale d'amélioration continue de l'architecture et du processus de développement
La démarche proposée par P.-‐Y. Cloux est descendante. Elle part du système d’information
dans son ensemble, d’un existant, en identifiant les risques associés au changement. Elle est
schématisée dans la figure 60. Une première phase d’analyse de l’architecture d’entreprise sous
l’angle de l’intégration doit produire une liste des risques d’intégration, un plan d’intégration, une
préconisation en matière de modèle d’architecture. Cette matière sert ensuite à la conception de
l’architecture.

figure 60 -‐ Démarche d'élaboration de l'architecture (Cloux)
Cette démarche s’inscrit dans celle plus large du processus unifié, la figure 61 montre les
interactions entre les deux démarches.

figure 61 -‐ Conception d'architecture et RUP
La mise au point de l’architecture se faite entre la création (inception) et l’élaboration. Le

processus de développement et le travail sur l’architecture sont des activités parallèles comme le
montre la figure 62.

figure 62 -‐ Processus de développement et mise au point de l'architecture
Le résultat, l’architecture applicative, doit s’intégrer avec l’architecture d’entreprise. D’un

point de vue concret, cela signifie que les interfaces de systèmes connexes soient compatibles.

IV. Gestion de projet
Les éléments de gestion de projet spécifique à cette étape sont liés à la bonne collaboration
entre analystes, architectes et concepteurs.
A. Bonnes pratiques
Les bonnes pratiques s’inspirent directement des principes de conception de la section
Erreur ! Source du renvoi introuvable.. Les qualités de la conception architecturale sont discutées
en détail dans [4].
On notera que ce qui prime pour le modèle d’architecture est la ‘communicabilité’ de la
solution pour les développeurs et l’intégrabilité dans le système d’information pour les décideurs
et urbanistes.
B. Gestion des risques

Nous avons abordé en partie ces points dans la section III avec le côté crucial de cette étape
dont les conséquences sont fondamentales pour tout le développement.
Une mauvaise architecture impactera le reste du projet voire même le conduira à l’échec.
Évidemment une bonne expérience de l’architecture technique diminue fortement le risque.
La bonne gestion des itérations est celle qui conduite à bonifier les incréments en limitant la
régression.
C. Collaboratif & support

A la base, on utilise plutôt des outils de communications20 de type éditeur vectoriel de dessin
pour construire les diagrammes, à l’exemple de Visio.
Cependant des outils sophistiqués de type MDA tels que Enterprise Architect (Sparx
Systems), Rational Software Architect Designer (IBM), Capella (Thalès), Archimate, Obeo
Designer…
Il existe aussi des langages spécifiques (ADL) et des outils supports pour ces ateliers (plutôt
des prototypes). Ils ont l’avantage de fournir un niveau de description uniforme, abstrait et
souvent vérifiable. La difficulté est de les connecter aux modèles de conception détaillée et aux
applications « concrètes ». Le standard AADL (Architecture Analysis and Design Language)21
permet de s’attaquer aux propriétés des architectures (figure 63 -‐ AADL un langage commun pour
les architectures logicielles), il peut s’intégrer dans une démarche dirigée par les modèles [27].
Archimate22 est une solution adaptée aux architectures d’entreprise qui comprend la couche
applicative.

20
Certains préconisent du NoUML -‐ http://www.infoq.com/fr/articles/agile-‐software-‐architecture-‐sketches-‐NoUML
21
http://www.aadl.info/
22
http://www.archimatetool.com/

figure 63 -‐ AADL un langage commun pour les architectures logicielles

V. Un exemple support
Dans le chapitre précédent, nous avons établi le modèle d’analyse de l’application en fixant
les grands fonctions (et les contraintes non-‐fonctionnelles). On s’intéresse ici à la conception
préliminaire qui va fixer les grandes lignes d’une technologie, même si le choix des frameworks
reste ouvert. L’application des patterns d’architecture et le détail de l’analyse technique sont
reportés au module projet. Nous traçons ici les grandes lignes d’une conception architecturale à
savoir l’architecture en couche, la mapping du modèle logique vers l’architecture technique (dans
les grandes lignes), les composants et le déploiement. On suit une organisation générale
présentée sous forme de paquetages dans la figure 64.

figure 64 -‐ Organisation de la conception
Nous ne discutons que légèrement les aspects gestion de projet et industrialisation dans la
mesure où les aspects planification et organisation ne sont pas fondamentaux pour ce qui n’est
finalement qu’un prototype.
A. Architecture technique
Pour l’application du cas fil rouge, on peut reprendre l’architecture technique Web autour
de Java J2EE de la figure 20 et y placer des solutions concrètes et des frameworks (figure 65)

figure 65 -‐ Architecture Web J2EE en 5 couches pour le cas bancaire

• Client léger Navigateur
• Serveur d’application J2EE Tomcat, Websphere, Jrun, Jboss comprenant le serveur Web
(servlet, JSP), Eclipse -‐ Lomboz (plugin J2EE)
• Couche métier EJB, MVC (Struts)
• Couche technique persistance (Hibernate)...
• Couche BD Oracle, MySQL, SQL Server, PostGresSQL : JDBC
1. Choix des frameworks

Les alternatives de conception ne justifient que sur les couches intermédiaires. Pour les
couches finales les solutions sont assez classiques.
• En effet pour la base de donnée on utilisera l'une quelconque des solutions, pour notre
cas MySQL et PostGresSQL sont adaptés.
• Pour le navigateur, en client léger, les questions qui peuvent se poser concerne l'usage de
Javascript (usage de bibliothèques récentes ou pas).
Concernant les couches intermédiaires, on utilisera un support MVC. La principale
préoccupation est l'accès aux données et la concurrence entre traitements parallèles. De
nombreux exemples et tutoriaux existent autour de Struts et Hibernate. Pour l'ouverture de
l'application vers des clients lourds ou les échanges avec d'autres applications les EJB sont une
bonne alternative. Le dernier critère à prendre en compte est la facilité à produire le lien XML
entre les éléments d'expression du traitement sur le serveur d'application et le serveur Web.
Les solutions récentes visent à produire automatiquement les éléments à partir

d'annotation dans le code Java. Ce qui nous rapproche alors du modèle d'analyse.
Il y a un effort d'abstraction mais il est vite rentable car écrire et maintenir manuellement les fichiers de configuration
XML est une tâche fastidieuse et source d'erreurs.
2. Représentation
On peut utiliser un diagramme de paquetage pour représenter les couches logicielles ou des
diagrammes de composants ou de déploiement. La figure 66 montre un exemple pour J2EE/
Spring/Hibernate sous forme de paquetages tandis que la figure 67 utilise aussi des composants.
Nous avions aussi vu en figure 7 un exemple avec des nœuds de déploiement.

http://www.uml-‐diagrams.org/spring-‐hibernate-‐uml-‐package-‐diagram-‐example.html
figure 66 -‐ An example of UML package diagram for Spring and Hibernate data access classes

http://www.uml-‐diagrams.org/web-‐application-‐uml-‐manifest-‐diagram-‐example.html
figure 67 -‐ Example of manifestation diagram for web application
Il serait raisonnable de ne pas mélanger les notations, néanmoins ce qui prime c'est la
lisibilité des schémas.

3. Cas Compte-bancaire
Nous proposons un diagramme de déploiement pour l’application « compte bancaire » dans
la figure 68.

figure 68 -‐ Diagramme de déploiement du cas Compte bancaire
La lecture de ce schéma appelle plusieurs remarques.

• C’est une esquisse. Cette représentation laisse une marge quant aux choix des
frameworks de la couche métier notamment.
• Compte-‐tenu du contexte restreint par l’analyse dans cette itération (version) nous ne
prenons en compte que deux rôles : le client et le conseiller.
C’est un choix arbitraire dans ce cours. En principe, la conception devrait être la plus large possible pour
mettre limiter les problèmes d’ajout de nouvelles fonctionnalités. On travaille en « largeur d’abord »
même si les fonctions ne sont pas mise en œuvre ensuite dans la conception détaillée.
• Nous considérons deux applications, une pour le client et l’autre pour le conseiller. Nous
aurions pu faire une seule application mais dans ce cas le croisement des règles fixant les
fonctionnalités autorisées par rôle (gestion des accès) vient à l’encontre des exigences
non fonctionnelles de sécurité. Ce découplage des actions se retrouvera dans un
découplage des diagrammes de séquence de la gestion des comptes. Il simplifie l’écriture
des applications mais correspond aussi à une perspective dans laquelle le poste du
conseiller soit une application riche Swing qui communique via un protocole RMI ou JMS
avec des EJB ou bien une solution par webservice (SOAP) (voir figure 19).
• Ces applications sont structurées en composants logiciels que nous n’avons pas définis ici.
Le degré de granularité et le nombre de diagrammes dépendent évidemment à la fois de la taille du
périmètre de l’application et du degré de décision atteint sur les composants techniques. Ce degré est
faible dans l’itération courante du cas que nous traitons.

• Nous avons simplifié en considérant un seul composant d’authentification associé à une
base de données. Ici aussi la prise en compte de la sécurité nous conduit à penser que
deux bases sont plus sûres pour limiter les risques d’intrusion et limiter les conséquences
d’une intrusion.
• Les bases de données sont relationnelles. En pratique on indique directement le SGBD.
• Le serveur est Apache, mais on peut prendre glassfish ou un autre selon la technologie
choisie pour les frameworks métier.
Détaillons maintenant les différentes préoccupations majeures de la conception.
B. Persistance
La persistance couche en fait plusieurs couches, et la présentation peut varier d'un auteur à
l'autre.
• La couche la plus basse est celle de la base de données. Nous devons fournir le schéma de
la base. Le modèle de la base sera mis en évidence dans la conception détaillée. On peut
en tracer les grandes lignes mais c’est tout.
• La couche d'accès aux données (DAO) se fait en une ou deux couches :
o Hibernate pour la connexion à la base via le connecteur Java JDBC.
o L’accès aux données sera mis en œuvre avec JPA qui permet les annotations du code
pour générer la couche d'accès aux données.
On utilise une base de données relationnelles avec un connecteur hibernate. L’accès aux
données sera mis en œuvre avec JPA.
C. Présentation et Métier

Dans la mesure où les contraintes non fonctionnelles du prototype ne sont pas très fortes,
on peut rester sur une architecture simple au choix :
• Struts 2 / Hibernate
• JSF(JSTL)/JPA/Hibernate2324
• Spring / Hibernate / JPA
On pourra lire un article qui illustre l'intégration de JSF Spring Hibernate 25 comme le montre
la figure 69.
Une archive des exemples est rattachée aux code source de ce chapitre.

23
un tutorial sur le sujet https://openclassrooms.com/courses/creez-‐votre-‐application-‐web-‐avec-‐java-‐ee
24
http://orm.bdpedia.fr/introjpa.html
25
http://www.journaldev.com/7122/jsf-‐spring-‐hibernate-‐integration-‐example-‐tutorial

figure 69 Intégration JSF Spring Hibernate
Le serveur d’application est relativement libre.
D. IHM
L’IHM se traduit par l’usage d’un navigateur Web léger.
Une certaine liberté est laissée quand à l’usage de techniques autour de Javascript et de
chargements partiels de pages. On pourra utiliser la technologie AJAX pour améliorer la gestion du
mode client-‐serveur. On peut utiliser des frameworks comme Angular JS ou React pour enrichir la
partie cliente et l’ouvrir vers le mobile.
Cet aspect sera abordé dans la conception détaillée, l’idée est de reprendre les diagrammes
de séquence et d’y ajouter les objets techniques.
E. Gestion de projet et industrialisation

L’aspect gestion de projet n’est pas fondamental à ce niveau abstrait de description sur le
projet fil rouge qui sera mis en œuvre dans le projet.
On retrouve les éléments donnés dans le chapitre 3 et notamment le développement itératif
et incrémental. Dans les itérations de la phase d'élaboration (cycle RUP) le rôle des architectes est
fondamental pour cette étape de conception préliminaire, en lien avec les analystes et les
développeurs. On doit valider le croisement possible entre les modèles métier et l'architecture
technique. La gestion des risques est liée d'une part à l'expérience sur cette architecture et d'autre
part à l'adéquation entre les besoins et le potentiel de l'environnement technique.
L’aspect industrialisation est abordé par la mise en place du support qu'il faut expérimenter
à ce niveau du processus de développement avant de passer à l'échelle par la suite. L'architecture
technique sera mise en évidence et expérimentée par un prototype.
Nous donnons les grandes lignes de l’outillage.
• On utilisera un outil pour gérer les modèles UML et leur traçabilité avec le code. On
utilisera si possible un outil permettant le MDA pour maintenir la cohérence (traçabilité)
entre le code et les modèles mais aussi pour gérer la cohérence entre les différents
aspects du code (au moins le MVC) et la transformation des modèles dans ces aspects.
• On utilisera un support pour la gestion de version de préférence SVN ou GIT.
• On utilisera un outil pour la configuration et l’intégration continue à base de Maven par
exemple.
• On utilisera des IDE Java (Eclipse qui a un fort potentiel MDA), IDEAJ ou Netbeans qui ont
une bonne intégration de Maven. Ces IDE ont aussi des plugins dédiés aux frameworks de
présentation des données qui incluent les traitements automatisés de génération de
fichiers de configuration ou de code par exemple Spring boot pour initialiser un projet
Spring, JPA Tools pour générer le mapping BDD/Hibernate, etc.
• Dans l’idéal, il faudrait aussi un outil pour gérer la traçabilité des besoins. Les versions
performantes sont souvent des outils chers (HP Quality Center vs. IBM Rational Quality
Manager) mais on trouvera des solutions plus simples et gratuites.

VI. Conclusion
La mise au point d’une architecture applicative est une activité à risque comme le rappellent
Bass et al. « The right architecture paves the way for system success. The wrong architecture
usually spells some form of disaster. ». L’architecture est importante car elle représente les
décisions amont de la conception (les plus difficiles à changer, les plus critiques, la base de la
communication entre participants). Elle concerne les propriétés importantes que sont la
performance, l’évolutivité, la fiabilité, la sécurité, etc. La conception architecturale est un facteur
clé pour la réutilisation systématique.
Bien que souvent perçue comme un raffinement de l’analyse, c’est le cas de la conception
détaillée, nous la voyons plus comme une correspondance (mapping) ou une transformation (au
sens large ou même au sens MDA) entre le modèle logique de l’analyse et l’architecture technique
dans laquelle elle doit s’insérer.
Si l’architecture représente bien l’idée d’un modèle en largeur, sa mise au point relève plus
d’un processus itératif en profondeur ou la sélection d’éléments prioritaires et le prototypage (à
défaut de disposer métriques de qualité) constituent des moyens pour approcher la meilleure »
architecture.
Cette dernière doit s’intégrer avec les autres applications de l’entreprise et donc se fondre
dans l’architecture d’entreprise. Une vision SOA facilite largement l’intégration des applications
dans le système d’information et les processus de l’entreprise ; on parle alors d’urbanisation et
d’alignement (revoir le chapitre 2 à ce sujet).
Concrètement on s’appuie sur des frameworks techniques, la difficulté est alors de les
choisir et de les intégrer. Une bonne pratique est aussi de s’appuyer sur des patrons
architecturaux que l’on doit combiner harmonieusement. Ces patrons garantissent des attributs
de la qualité des architectures.
On s’appuie aussi sur des outils pour faciliter la communication entre les acteurs du
développement, tous concernés par le travail des architectes.


VII. Références
[1] D. Alur, D. Malks, and J. Crupi. Core J2EE Patterns: Best Practices and Design Strategies.
Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001.
[2] P. André and A. Vailly. Conception de systèmes d’information ; Panorama des méthodes et
des techniques, volume 1 of Collection Technosup. Editions Ellipses, 2001. ISBN 2-‐7298-‐
0479-‐X.
[3] P. André and A. Vailly. Développement de logiciel avec UML2 et OCL; cours et exercices
corrigés, volume 6 of Collection Technosup. Editions Ellipses, 2013. ISBN 9782729883539.
[4] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-‐Wesley
Professional, 3rd edition, 2012.
[5] D. Broemmer and F. Mac. J2EE Best Practices: Java Design Patterns, Automation, and
Performance. John Wiley & Sons, Inc., New York, NY, USA, 2002.
[6] X. Blanc. MDA en action -‐ Ingénierie logicielle guidée par les modèles. Architecte logiciel.
Eyrolles, 1 édition, 2005. ISBN 2-‐212-‐11539-‐3.
[7] P. Cloux. RUP, XP Architectures et outils. Industrialiser le processus de développement.
InfoPro (Paris). Dunod, 2003.
[8] Jim Conallen. Concevoir des applications Web avec UML. Eyrolles, 2000. ISBN 2-‐212-‐09172-‐9,
1e édition.
[9] F. Daoust and D. Hazaël-‐Massieux. Relever le défi du Web mobile : bonnes pratiques de
conception et développement. Eyrolles, 2011.
[10] J. Fontanel, P. Lacomme, and L. Ren. Les web services : Concevoir et utiliser des applications
2.0 C#, Java, PHP, API JavaScript, Android SDK, iOS SDK... Technosup (Paris). Ellipses, 2013.
[11] A. Fron. Architectures réparties en Java -‐ 2e éd. : Internet des objets avec SOAP, RMI,
CORBA, JMS, sockets et services web. Etudes et développement. Dunod, 2012.
[12] D. Guignard, J. Chable, E. Robles, and N. Sorel. Programmation Android : De la conception
au déploiement, avec le SDK Google Android 2. Blanche. Eyrolles, 2011.
[13] M. Fowler. Patterns of Enterprise Application Architecture. Addison-‐Wesley Signature Series
(Fowler). Pearson Education, 2012.
[14] A. Goncalves. Java EE 5. Série Les cahiers du programmeur, Eyrolles, 2 edition, 2005. ISBN 2-‐
212-‐11574-‐1. ISBN 9782212126587
[15] H. Kadima. MDA -‐ Conception orientée objet guidée par les modèles. InfoPro. Dunod, 1
edition, 2005. ISBN 2-‐10-‐007356-‐7.
[16] A. Kleppe, J. Warmer, and W. Bast. MDA Explained: The Model Driven Architecture: Practice
and Promise. Object Technology Series. Addison-‐Wesley, 1 edition, 2003. ISBN 0-‐321-‐19442-‐
X.

[17] Philippe Kruchten. The 4+1 view model of architecture. IEEE Softw., 12(6) :42–50, November
1995.
[18] J. Lonchamp. Conception d’applications en Java/JEE, Principes, patterns et architectures.
Sciences sup -‐ Informatique. Dunod, 1 edition, 2014. ISBN 2-‐10-‐071686-‐7.
[19] J. Molière. J2EE. Série Les cahiers du programmeur, Eyrolles, 2 edition, 2005. Ouvrage diffusé
sous licence Creative Commons by-‐nc-‐nd 2.0, ISBN 9782212176407
[20] R. Pressman. Software Engineering : A Practitioner’s Approach. McGraw-‐Hill, Inc., New York,
NY, USA, 7 edition, 2010.
[21] J. Printz and J. Pradat-‐Peyre. Pratique des tests logiciels -‐ 2e éd. : Concevoir et mettre en
œuvre une stratégie de tests. Préparer la certification ISTQB. Etudes et développement.
Dunod, 2014.
[22] P. Roques and F. Vallée. UML 2 en action : De l’analyse des besoins à la conception.
Collection Architecte logiciel. Eyrolles, 2011, ISBN 9782212114621
[23] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Software Development
Process. Object-‐Oriented Series. Addison-‐Wesley, 1999. ISBN 0-‐201-‐57169-‐2.
[24] D. C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann. Pattern-‐Oriented Software
Architecture : Patterns for Concurrent and Networked Objects. John Wiley & Sons, Inc., New
York, NY, USA, 2nd edition, 2000.
[25] M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline.
Prentice-‐Hall, Inc., Upper Saddle River, NJ, USA, 1996.
[26] G. Sunyé, cours de conception logicielle, Université de Nantes.
[27] P. H. Feiler and D. P. Gluch. Model-‐Based Engineering with AADL : An Introduction to the SAE
Architecture Analysis & Design Language. Addison-‐Wesley Professional, 1st edition, 2012.



VIII. Liste des illustrations
figure 1-‐ La conception de logiciels, un problème complexe............................................................................ 2
figure 2 -‐ Notation UML : les vues..................................................................................................................... 3
figure 3 -‐ Processus 2TUP.................................................................................................................................. 6
figure 4 -‐ dimensons du modèle de conception........................................................Erreur ! Signet non défini.
figure 5 -‐ De l'analyse à la conception, selon Pressman ................................................................................. 13
figure 6 -‐ UML 2 : ports et services (composants)........................................................................................... 15
figure 7 -‐ Diagramme de déploiement UML 2 -‐ Appli Web............................................................................. 16
figure 8 -‐ style architectural centré sur les données....................................................................................... 20
figure 9 -‐ style architectural flots de données ................................................................................................ 21
figure 10 -‐ style architectural appel et retour................................................................................................. 21
figure 11 -‐ Style architectural en couches....................................................................................................... 22
figure 12 -‐ Architecture SOA en couches ........................................................................................................ 22
figure 13 -‐ Pattern client web léger ................................................................................................................ 23
figure 14 -‐ Pattern Client lourd ....................................................................................................................... 24
figure 15 -‐ Pattern livraison Web .................................................................................................................... 25
figure 16 -‐ Architecture et concepts pour InfoSphere MDM (blocs)............................................................... 26
figure 17 -‐ Architecture multi-‐couche ASP.NET .............................................................................................. 26
figure 18 -‐ YAPS architecture en 6 couches .................................................................................................... 27
figure 19 -‐ YAPS Architecture technique......................................................................................................... 28
figure 20 -‐ Architecture Web J2EE en 5 couches............................................................................................. 28
figure 21 -‐ Architecture SOA et non SOA ....................................................................................................... 29
figure 22 -‐ Architecture Web .......................................................................................................................... 30
figure 23 -‐ Pattern pour une architecture Web .............................................................................................. 30
figure 24 -‐ Evolution des architectures Web................................................................................................... 31
figure 25 -‐ Applications Web et Mobiles......................................................................................................... 31
figure 26 -‐ Fonctions d'un framework web ..................................................................................................... 32
figure 27 -‐ Architecture ASP.NET .................................................................................................................... 33
figure 28 -‐ Evolution ASP.NET ......................................................................................................................... 33
figure 29 -‐ Architecture ASP.NET 5.................................................................................................................. 34
figure 30 -‐ Architecture de développement ASP.NET 5 .................................................................................. 34
figure 31 -‐ Positionnement de J2EE par rapport à Java .................................................................................. 35
figure 32 -‐ Architecture J2EE ........................................................................................................................... 35
figure 33 -‐ Architecture de Java EE 5 [14] ....................................................................................................... 36
figure 34 -‐ Modèle d’architecture d’entreprise .............................................................................................. 37
figure 35 -‐ MVC et J2EE ................................................................................................................................... 37
figure 36 -‐ Comparaison ASP.NET -‐ J2EE ......................................................................................................... 38
figure 37 -‐ Intégration de frameworks via les services web............................................................................ 38
figure 38 – Diagramme de contexte architectural pour l’application SafeHome ........................................... 40
figure 39 – Structure architecturale de application SafeHome avec les composants de premier niveau ...... 40
figure 40 -‐ Exemple d’architecture multi-‐couche en UML. ............................................................................. 41
figure 41 -‐ Clustered deployment of J2EE web application ............................................................................ 42
figure 42 -‐ Architecture n-‐tier du système Adventure Builder........................................................................ 42
figure 43 -‐ Architecture SOA du système Adventure Builder.......................................................................... 43
figure 44 -‐ Architecture et sécurité ................................................................................................................. 43

figure 45 -‐ Migration dans le Cloud................................................................................................................. 44
figure 46 -‐ Exemple d'architecture logicielle pour le Cloud ............................................................................ 45
figure 47 -‐ Architecture pour applications mobiles ........................................................................................ 45
figure 48 – Vue conceptuelle des composants d’implantation....................................................................... 46
figure 49 – Organisation d’éléments de l’architecture (formulaires, jsp…) .................................................... 46
figure 50 -‐ Composants dans une architecture Spring .................................................................................... 47
figure 51 -‐ Enterprise Architecture at Bristol .................................................................................................. 47
figure 52 -‐ Des visions architecturales ............................................................................................................ 48
figure 53 -‐ Application PetClinicNous avions vu auparavant le diagrde.......................................................... 49
figure 54 -‐ Diagramme de contexte détaillée du cas techribes....................................................................... 49
figure 55 -‐ Contenu du composant ContentUpdater du cas techribes ........................................................... 50
figure 56 -‐ Diagramme détaillé des composants spring du cas techribes....................................................... 51
figure 57 -‐ Modèles de la conception architecturale -‐ RUP ............................................................................ 52
figure 58 -‐ Processus de définition d'une architecture dans le RUP ............................................................... 53
figure 59 -‐ Spirale d'amélioration continue de l'architecture et du processus de développement................ 55
figure 60 -‐ Démarche d'élaboration de l'architecture (Cloux) ........................................................................ 56
figure 61 -‐ Conception d'architecture et RUP ................................................................................................. 56
figure 62 -‐ Processus de développement et mise au point de l'architecture.................................................. 57
figure 63 -‐ AADL un langage commun pour les architectures logicielles ........................................................ 59
figure 64 -‐ Architecture Web J2EE en 5 couches pour le cas bancaire .....................Erreur ! Signet non défini.

C352 New Chap 4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

C352 New Chap 4

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 4 – Concevoir la solution C352 2/72

Chapitre 4 – Concevoir la solution C352 3/72

Chapitre 4 – Concevoir la solution C352 4/72

Chapitre 4 – Concevoir la solution C352 5/72

B. Enjeux et risques

Chapitre 4 – Concevoir la solution C352 6/72

Chapitre 4 – Concevoir la solution C352 7/72

3. La dissimulation d’informations (information hiding) est un moyen d’abstraction pour la

Chapitre 4 – Concevoir la solution C352 8/72

3. Des bonnes pratiques en lien avec les principes

Chapitre 4 – Concevoir la solution C352 9/72

Chapitre 4 – Concevoir la solution C352 10/72

Chapitre 4 – Concevoir la solution C352 11/72

C. Processus et résultats

1. Étapes de la conception [préliminaire]

Chapitre 4 – Concevoir la solution C352 12/72

Chapitre 4 – Concevoir la solution C352 13/72

a) Diagrammes de composants

Les diagrammes de composants mettent en évidence les composants (logiciels)

Chapitre 4 – Concevoir la solution C352 14/72

b) Diagrammes de déploiement

Les diagrammes de déploiement définissent la structure matérielle et la répartition des

Chapitre 4 – Concevoir la solution C352 15/72

c) Notations spécifique pour les applications Web

Chapitre 4 – Concevoir la solution C352 16/72

a) Découpage en sous-­systèmes

On découpe en sous-­‐systèmes si plusieurs applications distinctes existent dans le modèle

b) Raffinement des cas d’utilisation

Chapitre 4 – Concevoir la solution C352 17/72

Chapitre 4 – Concevoir la solution C352 18/72

B. Classifications d'architecture : genres, styles et patterns

Chapitre 4 – Concevoir la solution C352 19/72

Chapitre 4 – Concevoir la solution C352 20/72

• Architectures orientées objets dans lesquelles les composants encapsulent données et

Chapitre 4 – Concevoir la solution C352 21/72

On retrouve régulièrement des architectures en couches pour les logiciels système et

Chapitre 4 – Concevoir la solution C352 22/72

Chapitre 4 – Concevoir la solution C352 23/72

Chapitre 4 – Concevoir la solution C352 24/72

C. Présentation et exemples

Chapitre 4 – Concevoir la solution C352 25/72

Chapitre 4 – Concevoir la solution C352 26/72

L’architecture technique projette cette architecture logique sur un ou plusieurs

Chapitre 4 – Concevoir la solution C352 27/72

• Client Navigateur, Applets, Java Web Start...

Chapitre 4 – Concevoir la solution C352 28/72

Chapitre 4 – Concevoir la solution C352 29/72

Chapitre 4 – Concevoir la solution C352 30/72

Les nouvelles architectures facilitent l’intégration d’applications standards avec celles du

Chapitre 4 – Concevoir la solution C352 31/72

Chapitre 4 – Concevoir la solution C352 32/72

Chapitre 4 – Concevoir la solution C352 33/72

Chapitre 4 – Concevoir la solution C352 34/72

Un serveur d’application J2EE implante la spécification. Le web client communique avec le

Chapitre 4 – Concevoir la solution C352 35/72

ou la norme Java EE 6 :

Chapitre 4 – Concevoir la solution C352 36/72

Le modèle d’architecture d’entreprise de la figure 34 met en évidence les différentes

Chapitre 4 – Concevoir la solution C352 37/72

6. Quelques exemples commentés

Chapitre 4 – Concevoir la solution C352 38/72

Chapitre 4 – Concevoir la solution C352 39/72

Les composants sont responsables des liens avec le contexte.

a) Découpage en sous-systèmes

On découpe en sous-‐systèmes si plusieurs applications distinctes existent dans le modèle

La figure 40 donne un exemple d’architecture multi-‐couches représentée avec UML. Elle