Architecture logicielle - Définition
La liste des auteurs de cet article est disponible ici.
L'architecture une question de point de vue
La description d'un système complexe comme un logiciel informatique peut être faite selon plusieurs points de vue différents mais chacun obéit à la formule de Perry et Wolf : Architecture = Elements + Formes + Motivations. Selon le niveau de granularité, les éléments peuvent varier en tailles (lignes de code, procédures ou fonctions, modules ou classes, paquetages ou couches, applications ou systèmes informatiques), ils peuvent varier en raffinement (ébauche, solution à améliorer ou solution finale) et en abstraction (idées ou concepts, classes ou objets, composants logiciels). Les éléments peuvent également posséder une temporalité (une existence limitée dans le temps) et une localisation (une existence limitée dans l'espace).
Si les éléments sont, en général, représentés par des rectangles ou des ovales, les formes sont quant à elles constituées, la plupart du temps, d'éléments reliés par des droites ou des flèches. La sémantique des liens détermine la majeure partie de la sémantique du diagramme et l'aspect du système qui y est décrit.
Principaux types de liens
La dépendance fonctionnelle, signifie que l'élément source nécessite l'élément de destination pour réaliser ses fonctionnalités.
Le flot de contrôle, signifie que l'élément de destination prendra le contrôle de l'exécution après la terminaison de l'élément source.
La transition d'état, signifie que le système passera de l'état source à l'état de destination.
Le changement d'activité, signifie que le système réalisera l'activité de destination après l'activité source.
Le flot de données, signifie que l'information s'écoule de l'élément source vers l'élément de destination.
Le lien de communication, signifie que deux éléments échangent de l'information.
La composition, signifie que l'élément source est composé d'une ou de plusieurs données du type de l'élément de destination.
L'héritage (généralisation), signifie que l'élément source possède l'ensemble des données et des comportements de l'élément de destination.
L'envoi de message, signifie que l'élément source envoie un message à l'élément de destination.
Les modèles d'architecture
Indépendamment de la forme que prend un diagramme d'architecture, celui-ci ne représente toujours qu'un point de vue sur le système considéré, le plus important étant les motivations. En effet, à quoi sert de produire un diagramme s'il est inutile (pas utilisé) ou si les raisons des choix architecturaux sont vagues et non-explicités. Pour éviter de formuler les motivations pour chaque diagramme, l'architecte produira les différents diagrammes en fonction d'un modèle de conception et réutilisera des patrons de conception éprouvés.
Un modèle de conception (ou d'architecture) est composé d'un ensemble de points de vue, chacun étant composé d'un ensemble de différentes sortes de diagrammes. Il propose également des moyens pour lier les différentes vues et diagrammes les uns aux autres de manière à naviguer aisément, il s'agit des mécanismes de traçabilité architecturale. La traçabilité doit également s'étendre aux spécifications systèmes et même jusqu'aux besoins que ces spécifications comblent. La devise des trois pères fondateurs d'UML est « Centré sur l'architecture, piloté par les cas d'utilisation et au développement itératif et incrémentiel ». Cette devise indique clairement qu'aucune décision architecturale ne doit être prise sans que celle-ci ne soit dirigée (pilotée) par la satisfaction des spécifications systèmes (cas d'utilisation).
Le modèle conventionnel
Ce diagramme décrit, à gauche, les spécifications systèmes qui sont également représentées par des diagrammes (Entités-Relations, Flux de données, États-Transitions). Et à droite, nous avons les différentes activités de conception prenant comme intrants les livrables de la phase d'analyse. Nous voyons que l'architecture logicielle traditionnelle nécessiterait de produire au moins quatre vues distinctes : une architecture des données (conception des données), une architecture fonctionnelle et/ou modulaire (conception architecturale), une autre architecture fonctionnelle et/ou modulaire pour les interfaces utilisateurs (conception des interfaces) et une architecture détaillée (ordinogrammes, états-transitions) des différents modules (conception des composants).
La pyramide exprime que chaque couche est bâtie sur la précédente. En effet, les composants réalisant les fonctionnalités du logiciel doivent manipuler des éléments de données qui doivent donc être préalablement décrits. De même, les composants réalisant les interfaces utilisateurs doivent utiliser les fonctionnalités du logiciel préalablement décrites. Et finalement, la création de l'architecture détaillée de chacun des composants du logiciel nécessite, évidemment, que ceux-ci soient préalablement inventés.
Ce modèle d'architecture impose une séparation claire entre les données, les traitements et la présentation.
Modèle d'analyse ou modèle d'architecture?
Puisque l'analyse produit également des diagrammes, il est naturel de se questionner, en effet, quand se termine l'analyse et quand commence l'architecture ? La réponse à cette question est fort simple : les éléments des diagrammes d'analyse correspondent à des éléments visibles et compréhensibles par les utilisateurs du système, alors que les éléments des diagrammes d'architectures ne correspondent à aucune réalité tangible pour ceux-ci.
Le modèle des 4 + 1 vues
Le modèle de Kruchten dit modèle des 4 + 1 vues est celui adopté dans l'Unified Process. Ici encore, le modèle d'analyse, baptisé vue des cas d'utilisation, constitue le lien et motive la création de tous les diagrammes d'architecture.
La vue des cas d'utilisation
La vue des cas d'utilisation est un modèle d'analyse formalisé par Ivar Jacobson. Un cas d'utilisation est défini comme un ensemble de scénarios d'utilisation, chaque scénario représentant une séquence d'interaction des utilisateurs (acteurs) avec le système.
L'intérêt des cas d'utilisation est de piloter l'analyse par les exigences des utilisateurs. Ceux-ci se sentent concernés car ils peuvent facilement comprendre les cas d'utilisation qui les concernent. Cette méthode permet donc d'aider à formaliser les véritables besoins et attentes des utilisateurs; leurs critiques et commentaires étant les briques de la spécification du système.
Chaque cas d'utilisation est représenté par un diagramme de cas d'utilisation, chacun des scénarios de celui-ci étant décrit par un ou plusieurs diagrammes dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.
La vue logique
La vue logique constitue la principale description architecturale d'un système informatique et beaucoup de petits projets se contentent de cette seule vue. Cette vue décrit, de façon statique et dynamique, le système en termes d'objets et de classes. La vue logique permet d'identifier les différents éléments et mécanismes du système à réaliser. Elle permet de décomposer le système en abstractions et est le cœur de la réutilisation. En effet, l'architecte récupérera un maximum de composants des différentes bibliothèques et cadriciels (framework) à sa disposition. Une recherche active de composants libres et/ou commerciaux pourra également être envisagée.
La vue logique est représentée, principalement, par des diagrammes statiques de classes et d'objets enrichis de descriptions dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.
La vue des processus
La vue des processus décrit les interactions entre les différents processus, threads (fils d'exécution) ou tâches, elle permet également d'exprimer la synchronisation et l'allocation des objets. Cette vue permet avant tout de vérifier le respect des contraintes de fiabilité, d'efficacité et de performances des systèmes multitâches.
Les diagrammes utilisés dans la vue des processus sont exclusivement dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.
La vue de réalisation
La vue de réalisation permet de visualiser l'organisation des composants (bibliothèque dynamique et statique, code source...) dans l'environnement de développement. Elle permet aux développeurs de se retrouver dans le capharnaüm que peut être un projet de développement informatique. Cette vue permet également de gérer la configuration (auteurs, versions...).
Les seuls diagrammes de cette vue sont les diagrammes de composants.
La vue de déploiement
La vue de déploiement représente le système dans son environnement d'exécution. Elle traite des contraintes géographiques (distribution des processeurs dans l'espace), des contraintes de bandes passantes, du temps de réponse et des performances du système ainsi que de la tolérance aux fautes et aux pannes. Cette vue est fort utile pour l'installation et la maintenance régulière du système.
Les diagrammes de cette vue sont les diagrammes de composants et les diagrammes de déploiement.
