L’Architecture Logicielle Matière: ABCL, Master-l, Génie logiciel Synthèse faite par: Abdelhafid Benaouda Département d’Informatique, Faculté des Sciences, l. Jniv. Sétif-l, 19000, Algérie Table des matières 2 3. 1 3. 2 4 6 7 8 9. 1 9. 2 10 10. 1 10. 2 103 10. 4 10. 5 10. 6 Introduction or21 Sni* to View PAGF 91 comment le faire . Contexte et motivation La phase de conception logicielle est l’équivalent, en informatique, à la phase de conception en ingénierie traditionnelle (mécanique, civile ou électrique).
Cette phase consiste à réaliser entièrement le produit sous une forme abstraite avant la productlon ffective. Par contre, la nature immatérielle du logiciel (modelé dans l’information et non dans la matière), rend la frontière entre l’architecture et le produit beaucoup plus floue que dans l’ingénierie traditionnelle. L’utilisation d’outils CASE (Computer-aided software engineering) ou la production de l’architecture à partir du code lui-même et de la documentation système permettent de mettre en évidence le lien étroit entre l’architecture et le produit.
L’architecture logicielle constitue le plus gros livrable d’un processus logiciel après le produit (le logiciel lui-même). En effet, la phase de conception evrait consommer autour de 40% de l’effort total de développement et devrait être supérieure ou égale, en effort, à la phase de codage mais il peut être moindre. L’effort dépend grandement du type de logiciel développé, de l’expertise de l’équipe de développement, du taux de réutilisation et du processus logiciel.
Les deux objectifs principaux de toute architecture logicielle sont la réduction des coûts et l’augmentation d loeiciel ; la réduction fait un architecte logiciel ? L’architecture logicielle commence avec un ensemble d’exigences. Elles peuvent être exprimées sous forme de diagrammes, d’organigrammes de rocessus, de modèles ou de listes documentées des tâches opérationnelles afin que le logiciel puisse fonctionner. Généralement, le client ou le partenaire exprimera des exigences moins précises, comme l’ergonomie ou la façon dont certaines interfaces utilisateur doivent fonctionner pour les tâches courantes.
Les exigences doivent aussi inclure des informations sur les logiciels, les systèmes, le matériel et les réseaux existants avec lesquels le nouveau logiciel devra interagir, ainsi que d’autres facteurs comme le plan de déploiement et de maintenance et, évidemment, le budget disponible pour le projet. L’architecte doit prendre en considération les exigences du client. Cependant, le terme « client » comprend généralement trols domaines de responsabilité contradictoires : les exi- 3 L’architecte logiciel gences commerciales, de l’utilisateur et la configuration requise.
Les exigences commerciales définissent généralement une série de facteurs comme les processus commerciaux, les facteurs de performance (la sécurité, la fiabilité et le débit), ainsi que les contraintes de coûts et de budget. Les exigences de l’utilisateur comprennent la conception de l’interface, les ca acités opérationnelles et la onvivialité du logiciel. Les système 1 possède une approche personnelle pour collecter et analyser ces exigences et pour concevoir l’architecture. Toutefois, les questions courantes auxquelles il doit répondre sont : « Comment les utilisateurs travailleront-ils avec l’application ? « Comment l’application sera-t-elle mise en production et gérée « Quelles sont les exigences de qualité de l’application, comme la sécurité, la performance, la concurrence, la mondialisation et la configuration « Comment l’application peut- elle être conçue pour rester flexible et facile à entretenir dans le temps et « Quelles ont les tendances architecturales qui peuvent impacter l’application dès à présent ou après que l’architecture aura été déployée Cette dernière question est à la fois intéressante et importante.
Une bonne conception logicielle ne doit pas seulement répondre aux exigences des clients aujourd’hui, mais aussi dans un avenir prévisible. Cela affecte les décisions prises par l’architecte sur le matériel, les composants, les structures, les plateformes d’exécution, les systèmes logiciels de gestion et de nombreuses autres fonctions intégrées au logiciel ou parmi lesquelles le logiciel doit s’intégrer. Comme la plupart des tâches dans le monde de la conception et du développement logiciel, la conception de l’architecture est un processus préliminaire et itératif.
De nombreuses tâches comme l’analyse des exigences, les recherches techniques et l’identification des objectifs sont généralement effectuées au début du processus. L’étape suivante consiste à identifier les scénarios clés de la conception. Ce sont les premières exigences auxquelles le logiciel doit répondre et les contraintes avec lesquelles il doit fonctionner. À partir de ces informations, l’architecte peut générer une vue ‘ensemble de l’applicatio ‘ensemble englobe des PAGF s 1 l’architecte peut générer une vue d’ensemble de l’application.
Cette vue d’ensemble englobe des détails importants comme le type de l’application (Web, téléphone, ordlnateur de bureau ou Cloud), l’architecture du déploiement (généralement une conception détaillée avec les composants qui communiquent au-delà des frontières matérielles et du réseau), les styles d’architectures appropriés à suivre (sur plusieurs niveaux, serveur client, ou orienté client) et l’implémentation des technologies qui s’adaptent le mieux au scénario. ? partir de là, l’architecte peut commencer à générer des conceptions candidates qul satisfont les exigences les plus importantes identifiées plus haut.
Cette conception est ensuite examinée et testée par rapport aux scénarios clés, conjointement aux commentaires des clients et des versions d’essai et de test pour s’assurer qu’elle constitue une solution optimale. Cela ne se produit pas dès la première tentative, mais comme le cycle est répété, la conception convergera vers les exigences et les scénarios clés. La figure (Fig. 2) illustre cette approche itérative. À mesure que la conception se précise et que les tâches et omposants individuels sont identifiés, l’architecte peut affiner et ajouter des détails ? chaque étape.
Par exemple, après avoir identifié le style architectural et l’approche de déploiement, l’architecte peut prendre des décisions sur la communication entre les couches et les composants. Cela implique le choix d’un protocole en fonction des exigences présentes et futures, et la PAGF 1 schémas, de modèles et de documents qui définissent l’application selon plusieurs perspectives, afin que, une fois combinés, ils fournissent aux développeurs, aux équipes de test, aux administrateurs t à la direction toutes les informations requises pour implémenter la conception.
Ces informations décrivent la structure et l’agencement des composants et des niveaux de l’application, la manière dont les sujets transversaux comme la connexion et la validation sont gérés, le programme des tests et du déploiement, ainsi que la documentation pour assister les développeurs, les administrateurs et le personnel de support. La conception finale doit également spécifier les attributs de qualité que l’application doit atteindre. Ces attributs sont le résultat de décisions et de compromis effectués ar l’architecte en concertation avec le client.
Ils décrivent les exigences de sécurité et le plan d’implémentation de la sécurité, l’évolutivité et les performances requlses une fois déployés sur la plateforme cible, les méthodes d’implémentation de la maintenance et des extensions, ainsi que les fonctions qui permettent l’interopérabilité avec d’autres systèmes. Fig. 1: Exigences d’un client Fig. 2: un processus de conception architecturale itératif De quelles compétences un architecte a-t-il besoin ?
PAGF 7 1 plan initial et un ensemble d’exigences plus précises, permettant ‘économiser ultérieurement du temps et de rénergie. Un architecte logiciel doit également posséder le bagage technique pour comprendre comment les systèmes logiciels modernes, les structures et le matériel peuvent répondre aux exigences, comment les facteurs de systèmes d’exploitation et de mise en reseau peuvent affecter les décisions de conception, et comment les tendances et les changements dans ces domaines peuvent avoir un impact sur la conception.
Après l’analyse initiale des exigences, un architecte logiciel doit aussi utiliser des compétences techniques ? 4 Critères de qualité logicielle ropos des modèles de conception, des normes de communicatlon et de messagerie, des fonctionnalités de code, des questions de sécurité et des contraintes de performance. Tout ceci requiert une connaissance approfondie des technologies qui seront utilisées pour implémenter le logiciel final.
Bien évidemment, un architecte logiciel a également besoin d’une vision. être en mesure d’imaginer comment les systèmes s’assemblent et interagissent, comment ils sont partitionnés et déployés et comment ils interagissent avec les utillsateurs, n’est souvent possible qu’uniquement lorsque l’architecte a à l’esprit une vue ‘ensemble de la solution.
Cela nécessite une approche organisée et une grande attention aux détails pour assembler et comprendre toutes les exigences et contraintes, et les façonner progressiv e conception technique 8 1 de qualité logicielle — L’interopérabilité extrinsèque exprime la capacité du logiciel ? communiquer et ? utillser les ressources d’autres logiciels comme, par exemple, les documents créés par une certaine application. Cinteropérabilité intrinsèque exprime le degré de cohérence entre le fonctionnement des commandes et des modules ? l’intérieur d’un système ou d’un logiciel.
La portabilité exprime la passibilité de compiler le code source et/ou d’exécuter le logiciel sur des plates-formes (machines, systèmes d’exploitation, environnements) différents. — La compatibilité exprime la possibilité, pour un logiciel, de fonctionner correctement dans un environnement ancien (compatibilité descendante) ou plus récent (compatibilité ascendante). — La validité exprime la conformité des fonctionnalités du logiciel avec celles décrites dans le cahier des charges. ?? La vérifiabilité exprime la simplicité de vérification de la validité. L’intégrité exprime la faculté du logiciel à protéger ses onctions et ses données daccès non autorisés. — La fiabilité exprime la faculté du logiciel à gérer correctement ses propres erreurs de fonctionnement en cours d’exécution. La maintenabilité exprime la simplicité de correction et de modification du logiciel, et même, parfois, la possibilité de modification du logiciel en cours d’exécution.
La réutilisabilité exprime la capaclté de concevoir le logiciel avec des composants déjà conçus tout en permettant la réutilisation simple de ses propres composants pour le développement d’autres la iciels. — L’extensibilité exprime I ‘étendre simplement les PAGF g 1 logiciel à exploiter au mieux les ressources offertes par la ou les machines où le logiciel sera implanté. L’autonomie exprime la capacité de contrôle de son exécution, de ses données et de ses communications.
La transparence exprime la capacité pour un logiciel de masquer à l’utilisateur (humain ou machine) les détails inutiles à l’utilisation de ses fonctionnalités. La composabilité exprime la capacité pour un logiciel de combiner des informa- 5 Diminution de la dégradation du logiciel Fig. 3: La dégradation de logiciel en fonction de l’architecture, Inspiré de : Pressman R. S. Software Engineering : A Practitioner’s Approach, Fifth Edition. MCGraw-HiIl. Chapitre 1, p. 8, 2001. ions provenant de sources différentes. — La convivialité décrit la facilité d’apprentissage et d’utilisation du logiciel par les usagers. Diminution de la dégradation du logiciel une architecture faible ou absente peut entrainer de graves problèmes lors de la maintenance du logiciel [8]. En effet, toute modification d’un logiciel mal architecturé peut déstabiliser la structure de celui-ci et entraîner, à la longue, une dégradation (principe d’entropie du loeiciel). Ca it donc concevoir, paGF
