Architecture des Systèmes

d’Information

Chapitre 1 : Introduction

CHIKHI Nacim Fateh

 Le Génie Logiciel

 Le génie logiciel (GL) est une démarche d’ingénierie qui

traite tous les aspects de la production de logiciels
 „Du cahier des charges jusqu'aux activités de maintenance

 Le GL vise à assurer la production de logiciels en

respectant les aspects :
 „Coût, échéance, qualité

Chapitre 1 – Introduction 2
 Architecture logicielle

 C’est une discipline, un processus et un produit.

 Plusieurs définitions :
 L’architecture d’un système logiciel est définie comme l’organisation
fondamentale du système, qui s’incarne dans ses composants, les relations
entre eux et avec leur environnement, et les principes qui guident sa
conception et son évolution (IEEE 1471).
 L’architecture d’un système logiciel est l’ensemble des structures
nécessaires pour raisonner à propos du système, qui comprennent les
éléments logiciels, les relations entre eux et les propriétés de chaque (SEI).
 L'architecture logicielle est l'ensemble des décisions de conception qui, si
elles sont prises de manière incorrecte, peuvent entraîner l’échec du projet
(E. Woods).
 C’est une conception de haut niveau.

Chapitre 1 – Introduction 3
 L’architecture logicielle : une
abstraction

 La discipline de l'architecture logicielle est centrée sur

l'idée de réduire la complexité par l'abstraction et la
séparation des préoccupations.
 Une architecture logicielle est une abstraction d’un
système complexe qui sélectionne certains détails et en
écarte d'autres.
 L’architecture s’intéresse à la partie publique des
éléments qui composent le système, c’est-à-dire leurs
interfaces.
 Les éléments écartés sont dits non-architecturaux. Ils
correspondent en général aux détails d’implémentation
des éléments constituant l’architecture.
Chapitre 1 – Introduction 4
 Tout système possède une
architecture

 On peut montrer que chaque système comprend des

éléments et des relations entre eux pour permettre un
certain type de raisonnement.
 Dans le cas le plus trivial, un système est lui-même un
élément - une architecture inintéressante et probablement
inutile, mais une architecture néanmoins.
 Cela n’implique pas que l’architecture soit connue de tous.
 C’est pourquoi il est important de distinguer entre
l’architecture d’un système et la représentation de cette
architecture.

Chapitre 1 – Introduction 5
 Utilité d’une architecture logicielle

 Compréhension : facilite la compréhension des grands

systèmes complexes en donnant une vue de haut-niveau de
leur structure et de leurs contraintes. Les motivations des
choix de conception sont ainsi mis en évidence
 Réutilisation : favorise l’identification des éléments
réutilisables, parties de conception, composants,
caractéristiques, fonctions ou données communes
 Construction : fournit un plan de haut-niveau du
développement et de l’intégration des modules en mettant en
évidence les composants, les interactions et les dépendances

Chapitre 1 – Introduction 6
 Utilité d’une architecture logicielle
(suite)

 Évolution : met en évidence les points où un système peut être

modifié et étendu. La séparation composant/connecteur
facilite une implémentation du type « plug-and-play »
 Analyse : offre une base pour l’analyse plus approfondie de la
conception du logiciel, analyse de la cohérence, test de
conformité, analyse des dépendances
 Gestion : contribue à la gestion générale du projet en
permettant aux différentes personnes impliquées de voir
comment les différents parties du système seront agencées.
L’identification des dépendances entre composants permet
d’identifier où les délais peuvent survenir et leur impact sur la
planification générale

Chapitre 1 – Introduction 7
 Importance de l’architecture logicielle :
point de vue technique

 L’architecture détermine si un attribut qualité du système va être

atteint ou non.
 Les décisions prises concernant l’architecture permettent de
raisonner et de gérer le changement lorsque le système évolue.
 L’analyse d’une architecture permet de prédire assez tôt les
attributs qualité du système.
 Une architecture bien documentée améliore la communication
entre les parties prenantes.
 L’architecture abordera très tôt dans le projet les décisions les
plus importantes qui seront difficiles à changer par la suite.
 L’architecture définit un ensemble de contraintes pour
l’implémentation.

Chapitre 1 – Introduction 8
Importance de l’architecture logicielle :
point de vue technique (suite)

 L’architecture est l’élément clé qui permet à l’architecte et au

chef de projet de raisonner sur le coût et le planning du projet.
 Le développement basé architecture focalise beaucoup plus
sur l’assemblage de composants logiciels que sur leur
création.
 En limitant les choix conceptuels, l’architecture canalise la
créativité des développeurs en réduisant la complexité de la
conception et donc du système.
 L’architecture peut être utilisée pour former un nouveau
membre de l’équipe.

Chapitre 1 – Introduction 9
Importance de l’architecture logicielle :
point de vue métier

 Un système est développé pour satisfaire des besoins métier.

 L’architecture du système doit être en phase avec les besoins
métier.
 L’architecture peut influencer la structure organisationnelle
d’une entreprise et vice versa.

Chapitre 1 – Introduction 10
 Architecture vs Conception

 Au niveau modèle
 Paquetages, composants et relations
 Niveau de décision plus abstrait
 Les décisions qui doivent être prises à l’avance.
 Les décisions qui sont très couteuses à changer pendant le
développement.
 Pertinente pour les exigences non-fonctionnelles
 Elle inclut:
 Modules
 Bases/technologies de données
 Environnement d’exécution et de déploiement

Chapitre 1 – Introduction 11
 Architecture vs Conception (suite)

 Éléments plus concrets

 Classes
 Méthodes/Fonctions
 Tables de données
 Pertinente pour les exigences fonctionnelles
 Éléments qui peuvent être changés pendant le développement
(phase de maintenance)
 Réingénierie (refactoring)
 Evolution
 Adaptation

Chapitre 1 – Introduction 12
 Architecture vs Conception (suite)

 “All architecture is design, but not all design is architecture”

 L’architecture laisse plusieurs décisions de conception

ouvertes qui seront prises par les concepteurs ou les
programmeurs.

Chapitre 1 – Introduction 13
 Architecture ou Conception ?

 «On veut une couche d’interface graphique, une couche

d’analyse et une couche de stockage des données.»

 «Toutes les nouvelles applications doivent étendre l’interface

Application.»

 «L’application sera disponible comme un service déployé

sur le cloud.»

 «On a besoin d’une base de données NoSQL avec un taux de

disponibilité élevé. »

Chapitre 1 – Introduction 14
 Activités liées à l’architecture dans le
processus de développement

 Quel que soit le processus de développement adopté, on

retrouve les activités suivantes liées à l’architecture :
 Justifier le développement du nouveau système
 Comprendre les besoins importants d’un point de vue
architectural
 Créer ou sélectionner l’architecture
 Documenter et communiquer l’architecture
 Analyser ou évaluer l’architecture
 Implémenter et tester le système en se basant sur
l’architecture
 S’assurer que l’implémentation est conforme à
l’architecture
Chapitre 1 – Introduction 15
Standard ISO/IEC/IEEE 42010-2011

Chapitre 1 – Introduction 16
 Standard ISO/IEC/IEEE 42010-2011
(suite)

 Architecture Description : Une description d'architecture est un

produit de travail utilisé pour exprimer l'architecture d'un système
d'intérêt. Elle décrit une architecture possible pour un système
d'intérêt. Elle peut prendre différentes formes (document, un
ensemble de modèles, etc.)

 System-of-Interest : Le standard ne définit pas ce qu’est un système.

Ca peut être un système logiciel, une entreprise, un système de
systèmes, etc.

 Stakeholders : Les parties prenantes sont des individus, des groupes

ou des organisations préoccupés par le système d'intérêt. Exemples
de parties prenantes: client, propriétaire, utilisateur, consommateur,
fournisseur, concepteur, mainteneur, auditeur, PDG, autorité de
certification, architecte.

Chapitre 1 – Introduction 17
 Standard ISO/IEC/IEEE 42010-2011
(suite)

 Concern : Une préoccupation est tout intérêt dans le système.

Exemples de préoccupations: objectif (du système), fonctionnalité,
structure, comportement, coût, prise en charge, sécurité,
interopérabilité.

 Architecture Viewpoint : Un point de vue d'architecture est un

ensemble de conventions pour la construction, l'interprétation,
l'utilisation et l'analyse d'un type de vue d'architecture. Un point de
vue comprend des types de modèles, des langages et des notations
de points de vue, des méthodes de modélisation et des techniques
analytiques pour encadrer un ensemble spécifique de
préoccupations. Exemples de points de vue : opérationnel,
systèmes, technique, logique, déploiement, processus, information.

Chapitre 1 – Introduction 18
 Standard ISO/IEC/IEEE 42010-2011
(suite)

 Architecture View : Une vue d'architecture exprime l'architecture du

système d'intérêt du point de vue d'une ou de plusieurs parties
prenantes pour répondre à des préoccupations spécifiques, en
utilisant les conventions établies par son point de vue. Une vue
d'architecture se compose d'un ou de plusieurs modèles
d'architecture.

 Architecture Model : Une vue est composée de modèles

d'architecture. Chaque modèle est construit conformément aux
conventions établies par son type de modèle, généralement défini
dans le cadre de son point de vue directeur. Les modèles fournissent
un moyen de partager des détails entre des vues et d'utiliser
plusieurs notations dans une vue.

Chapitre 1 – Introduction 19
 Qu’est-ce-que la description d’une
architecture logicielle ?

 La description de l’architecture logicielle consiste à :

 Décrire l’organisation générale d’un système et sa
décomposition en sous-systèmes ou composants
 Déterminer les interfaces entre les sous-systèmes
 Décrire les interactions et le flot de contrôle entre les sous-
systèmes
 Décrire également les composants utilisés pour implanter les
fonctionnalités des sous-systèmes
 Les propriétés de ces composants
 Leur contenu (classes, autres composants)
 Les machines ou dispositifs matériels sur lesquels ces modules
seront déployés

Chapitre 1 – Introduction 20
 Compétences d’un architecte

 Leardership

 Communication

 Négociation

 Compétences techniques

 Gestion de projet

 Compétences analytiques

Chapitre 1 – Introduction 21
 Pourquoi développer une architecture
logicielle ?

 Pour permettre à toutes les parties prenantes (utilisateur

final, ingénieurs système, développeurs, testeurs, …) de
mieux comprendre le système
 Pour permettre aux développeurs de travailler sur des
parties individuelles du système en isolation
 Pour préparer les extensions du système
 Pour faciliter la réutilisation et la réutilisabilité

Chapitre 1 – Introduction 22