Cours AL - Partie 1 PDF

Architecture Logicielle Pr. Hatim HAFIDDI – INPT ASEDS – INE2 I – Introduction II – Principes de conception III – Points de vues architecturaux IV – Styles architecturaux V – Attributs de qualité A.U : 2024 – 2025 ...

Architecture Logicielle Pr. Hatim HAFIDDI – INPT ASEDS – INE2 I – Introduction II – Principes de conception III – Points de vues architecturaux IV – Styles architecturaux V – Attributs de qualité A.U : 2024 – 2025  OBJECTIFS − Appréhender l’intérêt de l’architecture logicielle − Définir la notion d’architecture − Introduire les principes d’une bonne architecture − Connaitre les principaux styles architecturaux − Concevoir une architecture en se basant sur les styles architecturaux − Documenter une architecture − Introduire les QA et les tactiques architecturales Architecture Logicielle (AL)  EVALUATION Architecture Sujet de recherche 25% (Cours) Examen 50% DAL + BL Mobile || Web (TP) (Homework) Projet final 25% Design Code Présentation Exam Architecture Logicielle (AL) Sujets de recherche SUJETS DE RECHERCHE 1. Modern web app architectures 2. Service Component Architectures (SCA) 3. Real time Architectures 4. SaaS app architectures 5. Patterns MV* 6. Architecting Big Data systems 7. Serverless architectures 8. Product Line Architectures 9. Architecting IoT systems Architecture Logicielle (AL) SUJETS DE RECHERCHE 10.Modern mobile app architectures 11. Architecture refactoring 12. Architecting Blockchain systems 13. Plugin architectures 14. High scalable architectures 15. Architecting Machine/Deep learning systems 16. Reactive Architectures 17. Domain Driven Design (DDD) 18. Hexagonal architectures Architecture Logicielle (AL) INTRODUCTION Motivation Pourquoi une AL ? Architecture Logicielle (AL) INTRODUCTION Motivation – Développement logiciel Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one... In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. – Brooks, 1986 Architecture logicielle comme moyen de gouvernance de cette complexité Architecture Logicielle (AL) INTRODUCTION Motivation – Impact de l’AL Architecture Logicielle (AL) INTRODUCTION Terminologie – Système/Système Logiciel Système /Système Logiciel Architecture Logicielle (AL) INTRODUCTION Terminologie – Système/Système logiciel o Système = Ensemble de composants connectés qui forme un tout ► Fonction(s) à remplir (System purpose) ► Composants et leurs liens (System structure) ► Interaction entre composants (System behaviour) ► Frontières du système avec son environnement (System boundaries) + Entrés/Sorties (Inputs/Outputs) o Système logiciel : composants, connexions et interactions sont des entités logicielles. o Complexité des systèmes au niveau : ► Structure / comportement ► Relations régissant les E/S Architecture Logicielle (AL) INTRODUCTION Terminologie – Modèle o Modèle = Vue simplifiée du système (focus sur un aspect bien particulier) ► Typiquement plusieurs vues pour un système (# aspects) ► Et plusieurs niveaux d’abstraction/granularité o Intérêts des modèles ► Abstraire/Simplifier ► Documenter/Communiquer ► Raisonner/Vérifier (erreurs, omissions, choix conceptuels) ► Construire/Produire (planifier, générer) ► Analyser l’impact du changement Architecture Logicielle (AL) INTRODUCTION Terminologie – Architecture logicielle Architecture Logicielle Architecture Logicielle (AL) INTRODUCTION Terminologie – Architecture Logicielle (AL) o Une multitude de définitions ► http://www.sei.cmu.edu/architecture/start/glossary/community.cfm The structure of the system, which comprise software elements, externally visible properties of those elements, and the relationships among them – Software Architecture in Practice, 2nd edition o Ensemble de modèles de la structure à grande échelle du système (Conception à haut niveau) : ► Les éléments du système ► Les propriétés externes de ces éléments ► Les relations (liens et interactions) entre ces éléments Architecture Logicielle (AL) INTRODUCTION Terminologie – Architecte Logiciel Architecte Logiciel? Architecture Logicielle (AL) INTRODUCTION Terminologie – Architecte Logiciel [An architect is] the person, team, or organization responsible for systems architecture. – IEEE 1471 2000 o Un architecte logiciel est un RÔLE ► Un groupe de personnes (gestion des humains) ► Une seule personne avec probablement d’autres rôles o PRÉREQUIS pour un architecte logiciel ► Appréhender le processus de développement logiciel ► Comprendre le domaine métier ► Bonnes compétences en conception et programmation ► Être conscient du contexte organisationnel (politiques de l’entreprise, # stakeholders et leurs rôles, etc.) Architecture Logicielle (AL) INTRODUCTION Ecosystème de l’architecte Architecture Logicielle (AL) INTRODUCTION AL – Objectifs/Préoccupations o Compromettre les préoccupations des # stakeholders ► Investisseurs (contraintes ressources/délais, rentabilité, etc.) ► Développeurs/testeurs (besoins clairs, maintenance facile, etc.) ► Chefs de projet (organisation / planification) ► Spécialistes marketing (fonctionnalités / Prix compétitif, STM, bonne qualité, etc.) ► Utilisateurs (utilisation/administration facile, sécurité, performance, etc.) ► Support technique (maitrise de la complexité des requêtes techniques) Considérer les FR et NFR des # stakeholders Architecture Logicielle (AL) INTRODUCTION Architecture dans les PDL Spécifications fonctionnelles et techniques Dossier de conception détaillée Code documenté + Rapport des tests unitaires Rapport de validation o Pas de processus Idéal (adaptation au contexte) o L’architecture fait partie des # PDL, principalement de la phase de conception (Architecture VS Conception) Architecture Logicielle (AL) INTRODUCTION Architecture & agilité When walking on water or developing software from a specification can be an easier task? if both are frozen. – Edward V. Berard o Architecture et évolutivité ► Une architecture initiale pour guider le développement ► Itérativement mise à jour (légèrement) lors du développement Architecture Logicielle (AL) INTRODUCTION Exemple d’une MAUVAISE architecture Architecture Logicielle (AL) INTRODUCTION Exemple d’une BONNE architecture Architecture Logicielle (AL) INTRODUCTION Règles d’architecture R.1 – L’architecture logicielle n’est pas une entité figée (gelée). « changer là » si vous en avez besoin R.2 – Une mauvaise conception d’architecture induit davantage de la mauvaise conception d’architecture R.3 – Une architecture floue mène à du code individuel, et à une duplication du code et d’effort R.4 – Une conception architecturale claire conduit à un système cohérent/consistant R.5 – Forte cohésion & Faible couplage => Architecture résistante Architecture Logicielle (AL) INTRODUCTION Dépendance Elément A Depends on Elément B (sous-système, (sous-système, module, etc.) module, etc.) ► Dépendance – Fonctionnement de A nécessite B ► Dépendance Forte – Modification de B entraine une modification de A (Propagation) ► Dépendance Faible – Modification de B n’a pas d’incidence sur A Architecture Logicielle (AL) DÉPENDANCE Exemples Formes classiques de dépendances entre 2 Types (TypeX et TypeY) en OO ► TypeX a un attribut qui réfère à TypeY ► TypeX fait appel aux services de TypeY ► TypeX a une méthode qui référence TypeY (paramètre, variable locale, type retour) ► TypeX est une sous-classe directe ou indirecte de TypeY ► TypeY est une interface et TypeX l’implémente Architecture Logicielle (AL) INTRODUCTION Cohésion & Couplage Pour deux granularités consécutives G+ et G- Cohésion – Pour chaque élément de G+, la cohésion est l’ensemble des dépendances entre ses éléments de G-. ► Degré de dépendances INTRA-élément ► FORTE cohésion VS Faible cohésion Couplage – Degré d’interaction (interconnexion) entre des éléments de G+. ► Degré de dépendances INTER-éléments ► Couplage FAIBLE VS Couplage Fort Architecture Logicielle (AL) COHÉSION & COUPLAGE Cohésion ► Renseigne sur l’étroitesse des liens et de la spécialisation des responsabilités d’un élément ► Un élément avec une faible cohésion ► Couvre # domaines ► Manque de cohérence Architecture Logicielle (AL) COHÉSION Degrés (Niveaux) Degré de cohésion Exemple Tâches complétement différentes (e.g., Connexion Très faible (Very low) BDD et appels RPC) Domaine précis MAIS Tâche très complexe  Composant couvrant tout un domaine Faible (Low) E.g., un seul composant responsable de tous les accès BDD Un composant léger (pas trop de fonctionnalités) MAIS # domaines liés Moyenne (Moderate) E.g., Composant connaissant les employés et les détails financiers Pas trop de responsabilités ET Forte (High) Domaine fonctionnel bien précis ET Collabore avec d’autres composants Architecture Logicielle (AL) COHÉSION Faible cohésion (conséquences) ► Difficulté de compréhension ► Fragilité (fréquence de changements) ► Difficulté de réutilisation ► Introduction de couplage ► Difficulté de maintenance Architecture Logicielle (AL) COHÉSION Solution (Forte cohésion) ► Concevoir des éléments fortement cohésifs ► Sous éléments focalisés sur une tâche commune unique ► Elément avec des responsabilité étroitement liées ► Techniques et principes (Délégation, SRP, ISP, etc.) ► Avec une HC, un élément est difficile à diviser Architecture Logicielle (AL) COHÉSION Exemple Architecture Logicielle (AL) COHÉSION Exemple – Faible cohésion Game fait tout le travail. Comment les tâches A,B et C sont liées entre elles? Si elles ne sont pas fortement liées => FAIBLE cohésion Architecture Logicielle (AL) COHÉSION Exemple – Forte cohésion Déléguer et distribuer les tâches sur d’autres éléments cohésifs Game est ségrégué! Architecture Logicielle (AL) COHÉSION Quelques réflexes Eléments rendant des services de même nature Isoler ce qui est stable de ce qui risque d’évoluer SoC (Separation of Concerns) : Métier vs Technique Corréler par durée de vie des éléments Affecter les responsabilités aux Expert en Infos (Evaluer les alternatives) Une cohésion raisonnablement élevée aide à réduire le couplage Architecture Logicielle (AL) COHÉSION & COUPLAGE Couplage ► Renseigne sur le degré de liaison d’un élément à un autre ► Un élément avec un fort couplage ► Dépend de beaucoup d’autres éléments ► Syndrome « Plat de spaghettis » ► Parfois volontaire : Obfuscation E1 E2 E3 E4 Architecture Logicielle (AL) COUPLAGE Degrés (Niveaux) Non couplé Faiblement Fortement couplé (Pas de dépendances !) couplé (Beaucoup de dépendances) (Peu de dépendances) Architecture Logicielle (AL) COUPLAGE Couplage Fort (Conséquences) ► Un changement dans un élément => changement de de tous ou la plupart des éléments liés ► Maintenance difficile voire impossible ► Les éléments pris isolement sont difficile à comprendre ► Réutilisation difficile Architecture Logicielle (AL) COUPLAGE Solution (Couplage Faible) ► Repenser la cohésion de vos éléments (Assignation des bonnes responsabilités aux bons éléments) ► Introduction d’abstraction (Contrat / Réalisation) ► Techniques et principes (ADP, DIP, etc.) E1 E2 E3 E4 Architecture Logicielle (AL) COUPLAGE Exemple Considérant les classes suivantes : Register Payment Sale Laquelle des 2 classes Register ou Sale devrait créer les objets Payment ? Architecture Logicielle (AL) COUPLAGE Exemple SOLUTION #1 makePayment(mt) 1: create(mt) : Register p : Payment 2: addPayment(p) : Sale Solution en application du patron Creator Architecture Logicielle (AL) COUPLAGE Exemple SOLUTION #2 makePayment(mt) 1: makePayment(mt) : Register : Sale 1.1: create(mt) Payment Architecture Logicielle (AL) COUPLAGE Exemple SOLUTION #1 OU #2 ? Sachant que pour chaque Sale, un Payment lui sera éventuellement associé (Business Model) Design #1 introduit un nouveau couplage entre Register et Payment absent au niveau du Design #2 Design #2 est de ce fait minimise le couplage A noter que ces deux patrons proposent deux # solutions Architecture Logicielle (AL) COUPLAGE A retenir Un faible couplage minimise les dépendances (Réduction de l’impact du changement) Un fort couplage n’est pas problématique en soi ! (Le problème et le fort couplage à des élément instables) Utiliser à bon escient le faible couplage pour pérenniser des parties de votre système (Focus sur les points d’instabilité et d’évolution réels) Ne chercher pas à découpler tout le système (Faible cohésion + pas de collaborations)! Ne pas considérer les principes/patrons isolement (Evaluer les alternatives) Architecture Logicielle (AL) COUPLAGE & COHÉSION A éviter – Elément divin Architecture Logicielle (AL) COUPLAGE & COHÉSION A éviter – Découplage destructif Architecture Logicielle (AL) COUPLAGE & COHÉSION A éviter – Mal sélectionné Architecture Logicielle (AL) COUPLAGE & COHÉSION A faire – Une architecture résistante Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ADP – Acyclic Dependency Principle o Les dépendances entre packages doivent former un graphe acyclique orienté Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ADP – Acyclic Dependency Principle o Compréhension des fonctionnalités d’une unité o Test d’une unité o Réutilisation d’une unité o Correction d’un bug au niveau d’une unité o Analyse du changement sur une unité Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ADP – Acyclic Dependency Principle o Compréhension des fonctionnalités d’une unité [A, B et le C] o Test d’une unité [A, B et le C] o Réutilisation d’une unité [A, A et B ou bien la solution complète] o Correction d’un bug au niveau d’une unité o Analyse du changement sur une unité est simplifié Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP – Dependency Inversion Principle o Module A (plus stable) dépend d’un module de bas niveau B (moins stable) [couplage concret] o Création d’une interface I que le module A utilise (couplage abstrait) et le module B réalise ⇒ Le module A est alors libéré du module B, devenu substituable Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ISP – Interface Segregation Principle Un client ne doit jamais être forcé de dépendre d’une interface qu’il n’utilise pas Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ISP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ISP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ISP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION ISP – Interface Segregation Principle o Signification et objectifs ► Découper les interfaces en responsabilités distinctes ► Quand une interface grossit, se poser la question de son rôle ► Éviter de devoir implémenter des services qui n’ont pas à être proposés par la classe qui implémente l’interface ► Limiter l’impact lors de la modification de l’interface o Avantages ► Le code existant est moins modifié ⇒ augmentation de la fiabilité ► Les classes ont plus de chance d’être réutilisables ► Simplification de l’ajout de nouvelles fonctionnalités Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Open Closed Principle Les entités logicielles doivent être ouvertes pour l'extension, mais fermées à la modification Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Open Closed Principle operation_1() { if (C1) { A // …….. } operation_1() if (C2) { operation_2() // …….. } } La gestion d’un nouveau cas C3 operation_2() { if (C1) { // …….. } if (C2) { Modification de A // …….. } } Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Open Closed Principle A I C1 C2 C3 Réduction des dépendances Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Open Closed Principle A I operation_1 sub_operation_1 operation_2 sub_operation_2 C1 C2 C3 operation_1() { operation_2() { i.sub_operation_1(); i.sub_operation_2(); } } Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Exemple Architecture Logicielle (AL) PRINCIPES DE CONCEPTION OCP – Open Closed Principle o Signification et objectifs Vous devez favoriser l’ajout d’une nouvelle fonctionnalité : ► en ajoutant des classes (Ouvert pour l’extension) ► sans modifier le code existant (fermé à la modification) o Avantages ► Le code existant n’est pas modifié  augmentation de la fiabilité ► Les classes ont plus de chance d’être réutilisables ► Simplification de l’ajout de nouvelles fonctionnalités Architecture Logicielle (AL) PRINCIPES DE CONCEPTION SRP – Single Responsibility Principle Une classe ne doit avoir qu’une seule responsabilité Architecture Logicielle (AL)  PRINCIPES DE CONCEPTION SRP – Single Responsibility Principle o La classe rectangle étant utilisée par : ► GeometricApp : Calculs géométriques ► GraphicalApp : Dessins graphiques & éventuellement le calcul géométrique o Deux responsabilités pour la classe « Rectangle » : ► Inclusion de la GUI dans la GeoApp !! ► Un changement de la GraApp impactant la classe « Rectangle » ⇒ Test et Redéploiement (éventuels) de la GeoApp Architecture Logicielle (AL) PRINCIPES DE CONCEPTION SRP – Single Responsibility Principle o Responsabilités séparées Architecture Logicielle (AL) PRINCIPES DE CONCEPTION SRP – Single Responsibility Principle o Signification et objectifs ► Une responsabilité est une “raison de changer” ► Une classe ne doit avoir qu’une seule raison de changer o Avantages ► Diminution de la complexité du code ► Amélioration de la lisibilité du code ► Meilleure organisation du code ► Les classes ont plus de chance d’être réutilisables Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Correction du TD Les interviews des experts métiers du « transport aérien » ont permis de résumer leur connaissance du domaine par les phrases suivantes : ► Des compagnies aériennes proposent différents vols ► Un vol est ouvert à la réservation et fermé sur ordre de la compagnie ► Un client peut réserver un ou plusieurs vols, pour des passagers différents ► Une réservation concerne un seul vol, et un seul passager ► Une réservation peut être annulée ou confirmée ► Un vol a un aéroport de départ et un aéroport d’arrivée ► Un vol a un jour et une heure de départ et un jour et une heure d’arrivée ► Un vol peut comporter des escales dans des aéroports ► Une escale a une heure d’arrivée et une heure de départ ► Chaque aéroport dessert une ou plusieurs villes Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple {frozen} {frozen} Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple Q.1 – Améliorez ce modèle pour qu’il respecte le principe de forte cohésion (Indication : le pattern de la méta-classe) ► N.B : Un vol est ouvert ou fermé à la réservation sur ordre de la compagnie Q.2 – Proposez un découpage en packages du modèle d’analyse en deux packages Q.3 – Trouvez une solution qui permet de minimiser le couplage entre les deux packages Q.4 - Pour des raisons d’organisation sur le projet, nous avons la contrainte suivante : le package Vols doit dépendre du package Réservations, et non l’inverse. Proposez une modification minimale permettant de se conformer à cette contrainte Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.1) Pattern de la méta-classe Trop de responsabilités, dont certaines ne sont pas propres à chaque instance Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.1) {frozen} Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.2) {frozen} {frozen} Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.3) {frozen} {frozen} Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.3) {frozen} {frozen} Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.3) Architecture Logicielle (AL) PRINCIPES DE CONCEPTION DIP/ADP – Exemple (Q.4) Architecture Logicielle (AL) Etudier d’autres principes (Liskov, Demeter)