Vous êtes sur la page 1sur 17

Architecture Logicielle

Module 1

Introduction

Année universitaire 2013/2014 – Semestre 1

1
Bienvenue
Séances:
o Cours: Notions théoriques
o Travaux Dirigés (TD): Activités, Exercices, exposés et Projets

Notation:
o Examen (70%): 2H, Cours et Exercices
o Devoir Surveillé (20 %) : Cours et Exercices
o Contrôle continu (10%): TDs, Présence, Projet
Projet par monôme

2
Introduction à l’Architecture Logicielle
Cette introduction donnera une vue d’ensemble sur :

L’Architecture logicielle comme une solution compromis


entre les préoccupations des différentes intervenants
dans le système logiciel.
L’Assurance de la qualité.
Les méthodes pour décrire et évaluer les architectures.
L'influence de l'architecture sur la réutilisation.
Le rapport entre le cycle de vie d'un système et son
architecture.

3
Objectifs de cette leçon
Après avoir étudié ce module, vous devriez être capable de:

-Décrire la place de l'architecture logicielle dans le cycle de vie,

- Expliquer la nécessité d'une architecture,

- Décrire les responsabilités d'un architecte logiciel,

- Expliquer la relation entre les intervenants et l'architecture d'un


système,

- Décrire l’effet des « besoins » en architecture logicielle,

- Expliquer l’effet « des compromis » pour créer une architecture,


- Expliquer la relation entre l'architecture et la réutilisation.
1.1 Qu’est ce que l'architecture logicielle?

1.1.1 Définition
La norme IEEE 1471 définit l'architecture logicielle
comme l'organisation fondamentale d'un système
représenté par ses composants, la relation des
composants du système les uns avec les autres et
avec l'environnement, et les principes et les
directives pilotant leur conception et leur évolution.

5
1.1.1 Définition

Une architecture représente les informations sur les


composants et leurs interactions, mais néglige des informations
sur les composants qui ne se rapportent pas à leur interaction.
Ainsi, une architecture est avant tout une abstraction d'un
système qui supprime (néglige) les détails des composants qui
n'affectent pas l'usage, les relations et les interactions des
composants.
Les détails privés des composants, les détails qui ont à faire
uniquement de l'exécution interne et ne sont pas visibles de
l'extérieur, ne sont pas architecturels.
En bref, une architecture détermine comment les composants
interagissent, pas la façon dont ils sont mis en œuvre.

6
1.1.1 Définition

Chaque système a une architecture, mais il ne s'ensuit pas que


l'architecture est connue à qui que ce soit.

Peut-être les concepteurs du système ont disparu depuis


longtemps, peut-être la documentation n'a jamais été produite,
et peut-être le code source a été perdu.

Cela montre que l'architecture n'est pas la même que la


description d'une architecture.

7
1.1.2 L’architecture dans le cycle de vie

La figure 1.1 montre le cycle


de vie d'un système, et la
place de l'architecture dans
le cycle de vie.
"L'architecture logicielle" fait
la liaison de « l'analyse des
besoins » à la réalisation.
L’architecture peut être
explorée et définie de façon
incrémentale.
Son existence permet de
prédire les aspects de la
qualité avant la réalisation.
L'architecture doit être stable
avant que le développement
majeur commence.
8
1.1.2 L’architecture dans le cycle de vie
Une architecture peut aider à l’évolution du développement,
dans le cas où l'évolution est l'une des exigences.

Une architecture logicielle peut être considérée comme un plan


et comme des lignes directrices pour la réalisation.

La Conformité architecturale est la mesure dans laquelle


l'architecture est réellement utilisée.

La conformité peut être exécutée par la direction. Pour une


conformité optimale, une architecture devrait être bien
documentée. Une architecture devrait aussi énoncer des
principes clairs, par exemple, «pas d’accès à la base de données
à travers une couche servlet ». La Conformité architecturale
devrait également être maintenue dans le temps.
9
1.1.2 L’architecture dans le cycle de vie
La Dégradation architecturale est à l'opposé de la conformité
architecturale au fil du temps:
il est souvent le cas où les logiciels dérivent de l'architecture
d'origine par des opérations de maintenance et de changement.

10
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
Les applications sont de plus en plus larges,
intégrées, et sont mises en œuvre en utilisant une
grande variété de technologies.
Les différentes technologies et disciplines doivent
être orchestrés pour assurer la qualité du produit.
Les attributs de la qualité, comme la fiabilité ou la
facilité d'utilisation ne peuvent être analysés au
niveau du code, mais ils peuvent être analysés au
niveau architectural du logiciel.
L'architecture logicielle a plusieurs fonctions, que
nous décrivons par la suite.

11
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
L'architecture logicielle en tant que moyen pour la
communication :
En premier lieu, nous avons besoin d'une architecture
comme moyen de communication entre les intervenants
(ou encore les parties prenantes, en anglais :
‘stakeholders’).
Un ‘stakeholder’ (autrement dit partie prenante ou
intervenant) est une personne ayant un intérêt légitime
dans la construction d'un système logiciel. Les
intervenants incluent le propriétaire, les utilisateurs
finaux, les développeurs, la gestion de projet et les
responsables, entre autres. Les intervenants sont
représentés dans tous les stades de développement, de
l'utilisation et du support.
12
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
Les propriétaires, les utilisateurs, les développeurs ainsi que de
les chargés de la maintenance, tous sont considérés comme
des intervenants (parties prenantes, stakeholders).
Une architecture logicielle représente une abstraction
commune de haut niveau d'un système qui peut être utilisé par
l'ensemble des acteurs du système comme base pour la
création de la compréhension mutuelle, l’élaboration d'un
consensus, et pour communiquer les uns avec les autres.
Dans le développement de logiciels open source, les
intervenants suivants peuvent être distinguées: les utilisateurs,
contributeurs et membres de comité (comme les
développeurs), les propriétaires (parfois, un projet est détenue
par une société, tandis que le logiciel résultant est open
source) et les fournisseurs (pour les entreprises, soit verser de
l'argent pour un projet, ou allouer aux développeurs de
travailler pendant des heures de travail sur un projet) 13
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
L'architecture logicielle comme une représentation de
décisions préliminaires de conception :
Une deuxième fonction de l'architecture du logiciel est qu'il
s'agit d'une représentation des décisions préliminaires de
conception.
Une architecture logicielle est la plus tôt documentation
des décisions de conception sur ​un système, et ces
premières décisions ont un poids énorme par rapport au
poids du reste des étapes du cycle de vie du système tels
que l’étape de son développement, son déploiement et sa
maintenance. L’architecture est également le premier
point duquel le système à construire pourra être analysé.

14
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
L'architecture logicielle comme une base à la structure de
répartition du travail:
L'architecture logicielle ne prescrit pas seulement la
structure du système en cours d'élaboration.
Cette structure est également gravé dans la structure du
projet de développement.
Parce que l'architecture comprend la décomposition de plus
haut niveau du système, elle est généralement utilisé
comme base pour la structure de répartition du travail.
Ceci impose et dicte les unités de planification,
d'ordonnancement, et fixe l'architecture d’une manière
efficace. Les groupes de développement n'apprécient pas
généralement les responsabilités cédantes, ce qui signifie
qu'il est très difficile de changer l'architecture une fois ces
unités ont commencé leur travail.
15
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
L'architecture logicielle comme un moyen pour évaluer
les attributs de la qualité :
Il est possible de décider que les choix architecturaux
appropriés ont été effectués (c'est à dire que le système
va exposer ses attributs de qualité requises) sans
attendre que le système soit développé et déployé,
parce que l'architecture logicielle permet de prédire les
qualités du système.
Nous en parlerons plus tard dans une leçon dédiée à
l'évaluation de l'architecture.

16
1.1.3 Pourquoi avons-nous besoin de
l’architecture logicielle?
L'architecture logicielle comme une unité de réutilisation :

Une autre fonction de l'architecture du logiciel est qu'il s'agit


d'une abstraction transférable d'un système. Une architecture
logicielle constitue relativement un petit modèle,
intellectuellement perceptible de la structure d'un système et la
manière dont ses composants fonctionnent ensemble. Ce
modèle est transférable entre les systèmes. En particulier, elle
peut être appliquée à d'autres systèmes présentant des
exigences similaires et peut favoriser la réutilisation à grande
échelle. Un exemple de la façon dont l'architecture logicielle
favorise la réutilisation à grande échelle est la construction de
lignes de produits. Une ligne de produits logiciels est une famille
de systèmes logiciels qui partage une architecture commune.
L'approche de la ligne de produits est un moyen d'acquérir de
qualité et d'économiser la main-d'œuvre.

17

Vous aimerez peut-être aussi