Soutenance mémoire
Qu’est ce qu’une architecture ?
Le terme architecture est issu d’un mot grec qui signifie « chef » ou « principe ». Depuis longtemps, la notion d’architecture est liée à la construction des édifices et des bâtiments complexes comme les pyramides pharaoniques, l’église La Sagrada Familia, et beaucoup d’autres monuments architecturaux que nous avons connus dans notre histoire. Le dictionnaire Larousse [Larousse, 1995] définit l’architecture d’un édifice comme étant sa finalité : « La finalité de tout édifice est la réalisation d’un lieu qui isole ses occupants tout en ménageant des échanges (locomoteurs, thermiques, optiques) avec le milieu extérieur. Le type de l’édifice (parti, matériaux, structure, éventuel décor) est conditionné par les ressources techniques de chaque civilisation confrontées aux conditions physiques du lieu et par le programme (destination) qui lui est assigné ».
Les architectures logicielles en informatique
Depuis la fin des années 1960s, les informaticiens ont emprunté et adapté la notion d’architecture pour l’appliquer dans la construction des systèmes informatiques ; ainsi on a vu apparaître la notion d’architecture logicielle [Naur and Randell, 1969]. Une architecture logicielle en informatique décrit les différents éléments constituant un ou plusieurs systèmes informatiques, leur organisation, interrelation, et interactions. L’architecture d’un système informatique est l’ensemble de ces concepts et propriétés fondamentaux dans son environnement, incarnés dans ses éléments, relations, et les principes de sa conception et son évolution.
Les apports des vues en architecture logicielle
Tout système informatique, qu’il soit simple ou difficile à comprendre, est constitué de plusieurs éléments liés ensemble. Il peut avoir un petit nombre d’éléments, ou peut-être un seul élément, comme il peut avoir une dizaine ou une centaine d’éléments ; cette liaison peut être triviale ou complexe.
En plus, tout système informatique est constitué de plusieurs éléments qui interagissent l’un avec l’autre et avec l’environnement externe au système d’une manière déterministe ou prévisible. Le comportement de ces éléments peut être simple et facile à comprendre, et il peut être de même très compliqué pour qu’il soit compris entièrement par une seule personne. Ce comportement reste toujours existant pour tout système informatique, qu’il soit documenté ou non. En d’autres termes, tout système informatique dispose d’une architecture, qu’elle soit documentée dans une description d’architecture ou non. L’introduction des vues en architecture logicielle a contribué à améliorer en plus le processus de description d’une telle architecture de plusieurs manières [Rozanski and Woods, 2011] :
• la séparation des préoccupations : la séparation des multiples aspects d’un système en plusieurs modèles différents aide durant le processus d’analyse, de conception, etc., en permettant de se focaliser dans chaque étape à un aspect particulier ;
• la communication avec les groupes d’intervenants : la communication entre des groupes d’intervenants avec des préoccupations diverses est un défi pour l’architecte. Les approches basées sur les vues offrent la possibilité aux intervenants de converger assez rapidement vers les descriptions d’architecture qui les intéressent répondant à leurs préoccupations ;
• la gestion de la complexité : considérer simultanément dans un même modèle tous les aspects d’un système induit une complexité qu’un être humain ne peut pas gérer. Le fait de décomposer le modèle en des modèles selon des vues différentes, réduit remarquablement la complexité.
Les limites des approches existantes
Malgré les avantages apportés par les approches d’architecture logicielle multipoints de vue en termes de séparation des préoccupations des systèmes informatiques et de réduction de la complexité, ces dernières souffrent cependant encore de plusieurs limitations, comme :
• la complexité inhérente au sein d’une vue. En effet, les préoccupations primitives de très haut niveau associées à une vue particulière d’une architecture logicielle ne peuvent jamais être traitées directement dans un seul modèle associé à un seul niveau d’abstraction, qui contient tous les détails nécessaires pour mener l’implémentation. Pourtant, on a besoin toujours de développer plusieurs modèles dans plusieurs niveaux d’abstraction pour pouvoir répondre effectivement à ces préoccupations primitives. Ainsi, la présence d’une hiérarchie plate d’une vue architecturale dans laquelle coexistent des modèles de très haut niveau avec des modèles très proches de l’implémentation est toujours inconfortable et déroutante pour les architectes logiciels ;
• les problèmes d’inconsistance qui peuvent avoir lieu entre les différentes vues de l’architecture. Ces problèmes d’inconsistance résultent du fait que les préoccupations du système informatique seront traitées séparément dans plusieurs vues de l’architecture logicielle, sans que les intervenants impliqués dans la construction d’une vue donnée de cette architecture, seront impliqués dans la construction des autres vues ;
• l’absence d’un processus de définition de ces architectures logicielles qui soit complet et adaptable avec les processus de développement logiciels. En effet, la tâche de définition d’architectures logicielles est une tâche vraiment lourde, critique et difficile. Pour cela, un architecte logiciel a toujours besoins de meilleures pratiques (mieux connues en anglais par best practices) rassemblées dans une méthodologie ou un processus de définition complet, afin qu’il soit capable de construire effectivement, et dans une durée acceptable, une architecture logicielle appropriée répondant aux problèmes visés par le système informatique. Normalement, ce processus doit être adaptable avec les différents processus de développement qui peuvent être adoptés durant la construction du système informatique.
La contribution de la thèse
Dans cette thèse, nous proposons une nouvelle approche d’architecture logicielle multipoints de vue, dénotée MoVAL (Model, View, and Abstraction Level based software architecture), qui est basée sur le standard ISO/IEC/IEEE 42010, intitulé « Systems and software engineering – Architecture description » [ISO/IEC/IEEE, 2011]. Cette approche répond aux limites des approches existantes, et elle est caractérisée par les points suivants :
• MoVAL est une approche d’architecture logicielle multipoints de vue ;
• Elle définit pour chaque vue une hiérarchie de niveaux d’abstraction ;
• Les niveaux d’abstraction d’une vue dans MoVAL sont de deux types : (1) les niveaux de réalisation d’une vue et (2) les niveaux de description associés à chaque niveau de réalisation ;
• MoVAL définit différents types de liens architecturaux assurant la cohérence de l’architecture et la résolution des inconsistances affrontées ;
• Dans l’approche MoVAL, un processus de définition d’architecture est présenté pour guider la construction des architectures logicielles.
La notion de point de vue (appelée aussi vue, perspective ou viewtype) revêt des significations diverses suivant les domaines et les travaux en informatique. En général, on s’intéresse aux points de vue dès lors que l’on modélise des systèmes à grande échelle faisant intervenir une grande masse de données, nécessitant la coopération de plusieurs experts de différents domaines de connaissances et points d’intérêts et s’adressant à une vaste panoplie d’utilisateurs. Comme souligné dans [Naja, 1998], un point de vue met en liaison un concepteur, un univers de discours (c’est-à-dire le système à modéliser) et l’objectif que le concepteur cherche à réaliser. Le point de vue permet une représentation partielle du système à modéliser mettant en relief un ou plusieurs aspects de ce dernier et occultant d’autres. Les premiers travaux sur les points de vue s’inscrivent dans le domaine de la représentation des connaissances en Intelligence artificielle. Ici on peut citer les travaux de Minsky [Minksy, 1975] et Lee et al. [Erman and Lesser, 1975] en 1975 suivis des langages de programmation KRL [Bobrow and Winograd, 1977], LOOPS [Bobrow and Stefik, 1983] et ROME [Carré et al., 1990] qui ont tous mis en évidence la nécessité de conférer à un même objet plusieurs représentations.
Les vues en spécification des besoins
La spécification des besoins, ou Software Requirements Specification (SRS), est définie dans le standard IEEE 830-1998 [Board, 1998] comme étant une description du comportement d’un système informatique et les interactions que les utilisateurs peuvent avoir avec ce système. En plus, la spécification des besoins contient les besoins non-fonctionnels imposés par le client comme la performance, la qualité, les contraintes, etc. … . Normalement, deux phases peuvent être distinguées en spécification des besoins, comme l’ont souligné Ross et Schoman [Ross and Schoman Jr, 1977] :
• L’analyse des besoins, qui porte sur la réalisation d’un énoncé textuel des besoins du client, qui est en général ambigu et manque de précisions.
• La définition des besoins, dans laquelle des langages spécifiques pour exprimer ces besoins peuvent être utilisé afin d’avoir un bon cahier des charges caractérisé par les huit qualitatifs suivants, présentés dans le standard IEEE 83-1998 :
– Correct : un cahier des charges est correct si et seulement si tous ses besoins sont des besoins qui doivent être implémentées dans le système ;
– Non-ambigu : un cahier des charges est non-ambigu si et seulement si chacune de ses besoins possède une seule interprétation ;
– Complet : un cahier des charges est complet si et seulement si, il contient tous les besoins fonctionnels et non-fonctionnels du système, une définition de toutes les réponses du système dans les situations valides et non-valides, toutes les références sur les figures, tableaux, diagrammes, et unités de mesure utilisées ;
– Consistent : un cahier des charges est consistent si et seulement s’il ne contient jamais des contradictions entre les besoins qu’il définit et avec les besoins définies dans des documents de plus haut niveau ;
– Classé pour importance et/ou stabilité : un cahier des charges est classé pour importance et/ou stabilité si chacune de ses besoins possède un identificateur indiquant son niveau d’importance ou de stabilité ;
– Vérifiable : un cahier des charges est vérifiable si et seulement si, pour chacune de ses besoins, il existe un processus bien défini et effectif permettant à une personne ou une machine de vérifier si le système satisfait cette besoin ;
– Modifiable : un cahier des charges est modifiable si et seulement si n’importe quel changement sur ses besoins peut être inclut sans affecter son style et structure ;
– Traçable : un cahier des charges et traçable si l’origine de chacune de ses besoins est bien clair, et s’il facilite le référencement de ses besoins dans les documentations futures.
Dans le domaine de spécification des besoins plusieurs approches à base de points de vue ont été proposées depuis les années 1970, comme les travaux de Ross et al., l’approche CORE de Mullery, les approches à base de dialogue, les approches à base d’heuristiques, les travaux de Delugach, et finalement l’approche Preview de Sommerville.
|
Table des matières
1 Introduction
1.1 Qu’est ce qu’une architecture ?
1.2 Les architectures logicielles en informatique
1.3 Les apports des vues en architecture logicielle
1.4 Les limites des approches existantes
1.5 La contribution de la thèse
1.6 Le plan de la thèse
2 Synthèse bibliographique
2.1 Introduction
2.2 Les vues en spécification des besoins
2.2.1 Les travaux de Ross et al
2.2.2 L’approche CORE
2.2.3 Les approches à base de dialogue
2.2.4 Plateforme pour la spécification des besoins à base de points de vue
2.2.5 Les travaux de Delugach
2.2.6 L’approche Preview
2.3 Les vues en modélisation de systèmes
2.3.1 L’approche CÈDRE
2.3.2 L’approche VBOOM
2.3.3 Le standard UML
2.3.4 Les travaux de Dijkman
2.3.5 L’approche VUML
2.4 Les vues en programmation
2.4.1 La programmation orientée sujet
2.4.2 La programmation orientée aspect
2.4.3 La programmation orientée vue
2.4.4 La programmation orientée rôle
2.4.5 La programmation orientée contexte
2.4.6 Les travaux sur la consistance entre les vues
2.5 Les vues en architecture logicielle
2.5.1 Le modèle « 4+1 » View Model
2.5.2 La spécification rationnelle de la description d’architecture (ADS)
2.5.3 Le standard ISO/IEC/IEEE 42010
2.5.4 L’approche Views and beyond (V&B)
2.5.5 L’approche de Rozanski et Woods
2.5.6 Le modèle de Siemens
2.5.7 La plateforme de Zachman
2.5.8 RM-ODP
2.5.9 Les travaux de Rich Hilliard
2.6 Conclusion
3 Analyse comparative et limitations
3.1 L’objectif visé
3.2 Le noyau de l’approche
3.3 Les intervenants adressés
3.4 Statut/nombre de vues
3.5 Catégorisation des vues
3.6 Les styles architecturaux associés aux vues
3.7 La stratification des vues
3.8 L’intégration des vues
3.9 Les relations entre les vues
3.10 Le processus de définition de l’architecture (ADP)
3.11 Les limitations des approches étudiées
3.12 Conclusion
4 MoVAL : Approche et concepts de base
4.1 Introduction
4.2 Positionnement et motivations de notre approche
4.3 SWVE : notre cas d’étude
4.4 MoVAL et les standards
4.5 Définitions de notions de base
4.5.1 Architecture logicielle, description d’architecture et style architectural
4.5.2 Vue et point de vue
4.5.3 Les modèles
4.6 Les extensions apportées par MoVAL
4.6.1 Niveau d’abstraction d’une architecture
4.6.2 L’architecture organisée en une hiérarchie à trois niveaux
4.7 Les diagrammes de visualisation d’une architecture MoVAL
4.7.1 La représentation hiérarchique détaillée
4.7.2 La représentation linéaire
4.7.3 La représentation matricielle de correspondance
4.8 Les liens architecturaux dans MoVAL
4.8.1 Les types de liens architecturaux
4.8.2 Les règles de dérivation des liens architecturaux
4.8.3 La sémantique associée aux liens architecturaux
4.8.4 Tableau récapitulatif des différents types de liens et de leurs caractéristiques
4.9 La cohérence de l’architecture MoVAL
4.9.1 La cohérence structurelle
4.9.2 La cohérence sémantique
4.10 Le méta-modèle de MoVAL
4.11 La configuration architecturale
4.12 Un catalogue de points de vue dans MoVAL
4.12.1 Le point de vue Contexte
4.12.2 Le point de vue Capacités Fonctionnelles
4.12.3 Le point de vue Implémentation Fonctionnelle
4.12.4 Le point de vue Information
4.12.5 Le point de vue Données Logiques
4.12.6 Le point de vue Données Physique
4.12.7 Le point de vue Déploiement
4.13 Conclusion
5 Conclusion
