Introduction à l’Architecture Logicielle

Présentation au sujet: "Introduction à l’Architecture Logicielle"— Transcription de la présentation:

1 Introduction à l’Architecture Logicielle
Chapitre 1: Introduction à l’Architecture Logicielle Année universitaire 2013/2014 – Semestre 1

2 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

3 Plan Définition de l'architecture logicielle.
L'architecture dans le cycle de vie d’un logiciel. Les responsabilités d'un architecte logiciel. Les nécessités d'une architecture logicielle.

4 Définition: 1.1. L'architecture au sens littéral
Dans le sens originel qu’il a en construction civile, l’architecture désigne: Une compréhension profonde des besoins du bâtiment présents et futurs et des contraintes de l’environnement, y compris les contraintes sociales. Une connaissances approfondie des matériaux à assembler ainsi que leur limites (usinage, vieillissement, rupture, etc.). Une connaissances approfondie des procédés de construction (les méthodes du génie civil, la gestion de projet, l’acquisition) permettant d’organiser l’activité des différents corps de métiers qui concourent à la réalisation et au maintien en conditions du bâtiment. L’architecte est celui qui rassemble et sait mettre en œuvre ces différentes connaissances au services exclusif du but poursuivit par le maître d’ouvrage. L’architecte est un chef d’orchestre qui doit savoir jouer de plusieurs instruments et qui doit surtout connaître la musique.

5 Définition: 1.2. L'architecture logicielle (1/2)
Dans la construction artificielle comme l’est n’importe quel programme informatique, c’est la forme logique qui doit être créée par l’architecte du logiciel (programmeur). Les notions d’automates, de système à états-transitions, de traduction, de machines abstraites sont des formes logiques fondamentales pour organiser et structurer les logiciels. 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.

6 Définition: 1.2. L'architecture logicielle (2/2)
Le modèle d’architecture produit lors de la phase de conception ne décrit pas ce que doit réaliser un système (analyse fonctionnelle) mais plutôt comment il doit être conçu de manière à répondre aux spécifications. L’analyse fonctionnelle décrit le « quoi faire » alors que l’architecture logicielle décrit le « comment faire » 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 néglige les détails des composants qui n'affectent pas l'usage, les relations et les interactions des composants.

7 2. L’architecture dans le cycle de vie (1/3)
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 2. L’architecture dans le cycle de vie (2/3)
Une architecture logicielle peut être considérée comme un plan et comme des lignes directrices pour la réalisation. Aider à l’évolution du développement logiciel, dans le cas où l'évolution est l'une des exigences. 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 2. L’architecture dans le cycle de vie (3/3)
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 3. Les responsabilités d’un architecte logiciel:
L’architecte est fondamentalement quelqu’un qui met de l’ordre, qui crée de la simplicité et qui régule pour organiser le système mis en œuvre. Il a pour tâches: Construire des entités logiquement cohérentes qui traduisent fidèlement l’intuition du sens profond qu’il a des choses qu’il veut modéliser et abstraire. La prise en compte des événements qui déclencherons tels ou tels automatismes programmés. Le choix des technologies. L’ordonnancement correct des opérations qui transforment progressivement les données initiales en résultats exploitables. Les tests et la validité de ses constructions. Chercher les abstractions utiles qui vont diminuer la taille du programme qu’il fabrique par une compréhension profonde de la structure logique et du sens des entités qu’il manipule.

11 4. Les nécessités d’avoir une architecture logicielle (1/7)
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.

12 4. Les nécessités d’avoir une architecture logicielle (2/7)
L'architecture logicielle en tant que moyen pour la communication : Nous avons besoin d'une architecture comme moyen de communication entre les différents intervenants (ou encore les parties prenantes, en anglais : ‘stakeholders’). Un ‘stakeholder’ 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.

13 4. Les nécessités d’avoir une architecture logicielle (3/7)
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)

14 4. Les nécessités d’avoir une architecture logicielle (4/7)
L'architecture logicielle comme une représentation de décisions préliminaires de conception : Une architecture logicielle est une 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é.

15 4. Les nécessités d’avoir une architecture logicielle (5/7)
L'architecture logicielle comme une base à la structure de répartition du travail: Un système est définit en systémique comme un ensemble d’éléments, ouverts sur l’environnement, qui interagissent en vue d’une finalité. Un élément peut lui-même être un système. L'architecture logicielle ne prescrit pas seulement la structure du système en cours d'élaboration mais aussi de tout le système qui le compose. 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.

16 4. Les nécessités d’avoir une architecture logicielle (6/7)
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 la qualité du système.

17 4. Les nécessités d’avoir une architecture logicielle (7/7)
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, il 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 la qualité et d'économiser la main-d'œuvre.

18 Nous nommons ligne de produits (LdP) (Clements et al
Nous nommons ligne de produits (LdP) (Clements et al. , 2001) un ensemble d’applications, partageant des points communs mais exhibant aussi des différences, qui sont développées à partir de composants communs dans un domaine déterminé. Ainsi en maximisant la réutilisation de composants conçus avec soin, il est possible de satisfaire simultanément des critères de qualité et de temps de développement. A partir de ces concepts, une ingénierie des lignes de produits est née et un certain nombre d’approches outillées ont été introduites afin de générer une application en fonction d’un ensemble de choix proposés au développeur. Cette ingénierie a été couronnée de succès dans des domaines divers comme l’automobile, la téléphonie mobile, ou l’imagerie médicale