Architecture Logicielle Module 1 Introduction Année universitaire 2013/2014 – Semestre 1

Bienvenue Séances: Cours: Notions théoriques Travaux Dirigés (TD): Activités, Exercices, exposés et Projets Notation: Examen (70%): 2H, Cours et Exercices Devoir Surveillé (20 %) : Cours et Exercices Contrôle continu (10%): TDs, Présence, Projet Projet par monôme

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.

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.

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.

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.

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.

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.

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.

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.

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.

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)

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é.

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.

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.

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.