Les architectures Une introduction Hafedh Mili

Hafedh Mili Copyright Plan  Introduction Définitions Architectures et critères de qualité de systèmes, Styles architecturaux Architectures pour le lien application - interface

Hafedh Mili Copyright Introduction Client: “J’ai besoin d’un système de commerce électronique pour la vente de mes produits Ingénieur: “Hum… je peux assembler des composantes qui trient, qui gèrent des files, des listes, etc. Client: “Comment ces composantes là vont répondre à mes besoins” Ingénieur: “à un très bas niveau. Il faudra voir comment on va les utiliser”

Hafedh Mili Copyright Architecture (introduction) Le génie logiciel souffre d’un manque de concepts intermédiaires entre objectifs stratégiques et … structures de données L’architecture intègre les exigences fonctionnelles avec les exigences d’affaire d’une organisation

Hafedh Mili Copyright Architectures: une 1ère définition Une architecture est l’expression des premières décisions de conception concernant la décomposition d’un système en parties [Bass, Clements & Kazman,99] L’architecture d’un logiciel définit le logiciel en terme de composantes et d’intéractions entre composantes [Shaw & Garlan, 96]

Hafedh Mili Copyright Architecture: une confluence d’influences Développement et maintenance: faible coût, préserver les emploies Usager final: fonctionnalités, performance, sécurité, fiabilité architecte Client: faible coût d’acquisition, d’opération, et d’évolutrion Marketing: fonctionnalité, faible prix de vente, time-to-market, différentiation

Hafedh Mili Copyright ABC: Architecture Business Cycle [Bass et al., 1999] Client et usager final Organization Environnement technique Expérience de l’architecte Exigences (propriétés) Architecture Systeme

Hafedh Mili Copyright Les influences L’architecture influence la structure organisationnelle de développement et réciproquement Peut influencer le client (sacrifier quelques fonctionnalités pour d’autres qualités) Fait évoluer l’expérience de l’architecte Peut faire évoluer les objectifs stratégiques

Hafedh Mili Copyright Cycle de développement Business case Exigences Concevoir/sélectionner l’architecture Décrire et communiquer l’architecture aux stakeholders (joueurs) Analyser/évaluer l’architecture Implanter le système en se basant sur l’architecture Vérifier que l’implantation est conforme à l’architecture

Hafedh Mili Copyright Comment faire une bonne architecture (processus)? Vision (une personne ou un petit groupe) Exigences techniques claires, et une priorization des propriétés désirées, Bien documentée et bien circulée/communiquée Architecture doit être analysée et évaluée pour propriétés quantitatives (throughput) et qualitatives (ouverture, évolutivité) Doit supporter le développement incrémental à partir d’une skelette

Hafedh Mili Copyright Qu’est ce qu’une bonne architecture? (produit) Fonctionnalité distribuée selon les principes de la “séparation of concerns” et dissimulation de l’information, Doit supporter le développement en // Doit isoler les spécificités de la plateforme ou de produits commerciaux, Doit être simple/uniforme, Doit séparer les modules qui produisent des données de ceux qui les consomment, Doit séparer la structure de modules de la structure de tâches Doit affecter les tâches aux processeurs de façon flexible (voire dynamique)

Hafedh Mili Copyright Plan Introduction  Définitions Architectures et critères de qualité de systèmes Styles architecturaux Architectures pour le lien application - interface

Hafedh Mili Copyright Définitions L’architecture d’un programme ou système informatique est: la structure ou l’ensemble des structures du système, qui est (sont) composée(s) de composantes logicielles Les propriétés visibles de ces composantes, Les relations entre ces composantes là.

Hafedh Mili Copyright Une architecture d’un logiciel de simulation Control Process (CP Noise Model (MODN) Reverb Model ( MODR) Prop Loss Model (PLM)

Hafedh Mili Copyright Ce que le dessin ne disait pas: De quel type de composantes (modules? Processus, tâches), il s’agit? Quelle est la nature des liens (communication, contrôle, échange de données, appel), Plus d’autres questions, une fois qu’on aura répondu à ces deux là.

Hafedh Mili Copyright Styles, modèles de références, et architectures de références Un style architectural est une description d’un type de composantes et d’un patron de contrôle et de communication, Un modèle de référence est une décomposition “fonctionnelle” d’un système (e.g., d’une analyse du domaine) Une architecture de référence est la correspondence d’un modèle de référence à une architecture.

Hafedh Mili Copyright Style, modèle de références, et architectures Modèle de référence Style architectural Architecture de référence Architecture de système

Hafedh Mili Copyright Structures architecturales Structure de modules: un module est une unité de travail avec livrables (interface, code, plan de test). La relation est l’aggrégation/dépendance Structure logique/conceptuelle: les éléments sont des composantes fonctionnelles. La relation est partage/échange de données. Le modèle de référence en est un exemple.

Hafedh Mili Copyright Structures architecturales (suite) Structure de processus/coordination: vue “run-time”, orthogonale aux deux précédentes. Relation: synchronisation, “peut-pas-rouler-sans”, “peut-pas-avec”, etc. Structure physique: l’allocation du logiciel au matériel (systèmes distribués). Composantes: hardware, liens: communication (sert à valider perf., etc.)

Hafedh Mili Copyright Structures architecturales (suite) Structure “uses”: les unités = procédures ou modules, liens = dépendences fonctionnelles/de service. Structure d’appel: appel entre procédures Flux de données: les unités sont des modules, le lien est d’échange de données Flux de contrôle: unités = programmes, modules, ou états. Liens: devient-actif- après. Pour validation comportementale, timing, etc. Structure de classes: classes et héritage.

Hafedh Mili Copyright Structures architecturales (suite)

Hafedh Mili Copyright Structures architecturales (suite)

Hafedh Mili Copyright Structures architecturales (fin) Différents systèmes requièrent différentes combinaisons de structures de représentation Certaines structures peuvent coincider pour le cas de systèmes de petite taille Il faut assurer le lien entre ces structures là.

Hafedh Mili Copyright Plan Introduction Définitions  Architectures et critères de qualité de systèmes Styles architecturaux Architectures pour le lien application - interface

Hafedh Mili Copyright Les attributs de qualité Il faut distinguer entre: Attributs/propriétés du système, qui sont dues à l’architectures, et attributs intrinsèques de l’architecture elle-même, Qualités observables à l’éxécution de celles qui ne le sont pas, Qualité technique versus qualité d’affaires (business quality).

Hafedh Mili Copyright Attributs de qualité visible à l’exécution Performance: temps de réponse à un stimulus, ou taux de traitement Sécurité: capacité du système à résister à l’attaque, et à continuer à offrir un service normal aux usagers légitimes Disponibilité: elle est définie comme: (temps moyen entre pannes)/(temps moyen entre pannes + temps réparation)

Hafedh Mili Copyright Attributes de qualité visibles à l’éxécution Fonctionnalité: capacité du système à faire ce qui etait demandé Utilisabilité: –Facilité d’apprentissage –Efficacité –Facilité de mémoriser les commandes –Prévention d’erreurs –Traitement d’erreur (“recoverability”) –Satisfaction de l’usager

Hafedh Mili Copyright Attributs de qualité non-visibles à l’exécution Modifiabilité: C’est la pté qui dépend le + de l’architecture (localité de changements): –Quatre scénarios d’évolution: Extension ou changement de fonctionnalités, Éliminer certaines fonctionnalités (version “light”) Adaptation à un nouvel environnement (portabilité, voir plus bas) Restructuration (e.g. pour la performance, la réutilisation, etc.)

Hafedh Mili Copyright Attributs de qualité non-visibles à l’exécution (suite) Modifiabilité: (suite) –Quatre envergures de changements: Changement dans une composante, Changement dans plusieurs composantes, Changement dans l’infrastructure, Changement de style. Portabilité: adaptabilité à différents environnements d’opération/exécution

Hafedh Mili Copyright Attributs de qualité non-visibles à l’exécution (suite) Réutilisabilité: on parle de réutilisabilité de composantes (qui dépend de l’architecture), et de réutilisabilité de l’architecture-même, Intégrabilité: permettre à des composantes développées séparément d’inter-opérer (dépend des “interfaces” des composantes) Testabilité: reliée à la controllabilité et observabilité du comportement des composantes.

Hafedh Mili Copyright Attributs de qualité: résumé

Hafedh Mili Copyright Attributs de qualité: résumé

Hafedh Mili Copyright Attributs de qualité orientés- affaires Temps de mise en marché: pression => construction à partir de composantes => architectures ouverte, même si non idéale, Coût: (de développement) Durée de vie projetée du système Marché cible Stratégie de commercialisation: (e.g. version vanille + saveurs => modifiabilité) Integration avec systèmes légataires

Hafedh Mili Copyright Qualités de l’architecture Les (attributs de) qualités vues à date concernent le produit final; différents choix vont permettre d’atteindre ces qualités là plus ou moins bien Les qualités de l’architecture sont intrinsèques, indépendamment de toute qualité qu’elle pourra inculquer à un produit donné

Hafedh Mili Copyright Qualités de l’architecture Intégrité conceptuelle: cohérence, thème dominant, quitte à abandonner certains “features”, Complétude et “correctness”: adresse toutes les exigences, et efficacement, Faisabilité: en tenant compte des ressources, et autres contraintes.

Hafedh Mili Copyright Plan Introduction Définitions Architectures et critères de qualité de systèmes  Styles architecturaux Architectures pour le lien application - interface

Hafedh Mili Copyright Styles architecturaux “Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers”[S+87] “Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client-server model for the structuring of applications”[FO85] We have chosen a distributed object-oriented approach to managing information”[Lin87]

Hafedh Mili Copyright Styles architecturaux Un style architectural est un patron récurrent (commun) d’organisation / architecture de système, Les styles sont généralement décrits par des noms/phrases simples, mais évoquent toute une … architecture! Un style architectural est généralement uniformément appliqué à l’architecture d’un système.

Hafedh Mili Copyright Styles architecturaux Un style architectural est déterminé par: Un ensemble de types de composantes (e.g. dépôt de données, processus, procédure), Une structuration topologique des composantes indiquant leur relations durant l’exécution Un ensemble de contraintes sémantiques sur les composantes et leur interrelations, et Un ensemble de connecteurs (e.g. appel de procédures, interruptions, etc.) pour médier la communication et coordination entre les composantes.

Hafedh Mili Copyright Styles architecturaux 5 classes de styles: Composantes indépendantes, Flux de données Orienté-données, Machine virtuelle “Call-and-return”

Hafedh Mili Copyright Composantes indépendantes Processus Communiquants Systèmes à base d’évènements Invocation implicite Invocation explicite

Hafedh Mili Copyright Architectures en flux de données Séquentiel batch Pipes and filters

Hafedh Mili Copyright Architectures orientées-données Approche repository Approche blackboard

Hafedh Mili Copyright Architectures machine virtuelle Interprète À base de règles

Hafedh Mili Copyright Architectures “call and return” Programme principal et sous-routines Par couches Orientés- objet

Hafedh Mili Copyright Architectures orientées-données Principe: Différents clients accèdent les mêmes données partagées: –Reposoir “passif”de données: style reposoir –Reposoir “actif”: style “blackboard” Objectif principal: Assurer la qualité “intégrabilité des données”

Hafedh Mili Copyright Architectures orientées-données Client 1 Client 3 Client 2 Client 5 Client 4 Données partagées

Hafedh Mili Copyright Architectures orientées-données Les clients sont des modules relativement indépendants (vue structurelle) –Les clients ne doivent pas réagir instantanément aux changements de données => reposoir –Les clients doivent réagir aux changements de données => blackboard Les clients roulent dans des processus séparés (vue “processus”)

Hafedh Mili Copyright Architecture blackboard Client 1 Client 3 Client 2 Client 5 Client 4 Données partagées Module de contrôle donnée

Hafedh Mili Copyright Architectures flux de données Principe: Les données “coulent” entre processus, allant de input versus repôt ultime: –Un élément à la fois: “pipes and filters” –Par lots: “batch sequential” Objectif principal: Assurer la qualité “réutilisation” et “modifiabilité”.

Hafedh Mili Copyright Style batch sequential Traitement 1 Traitement 2 Traitement 3 input

Hafedh Mili Copyright Style pipe & filters Filtre 1Filtre 2Filtre 3 input Filtre 4 Pipe tuyau

Hafedh Mili Copyright Pipe & Filters Pros: Simplicité de conception et de fonctionnement Les filtres sont réutilisables, facilement modifiables, et parallélisables Cons: Forcent une représentation de données “plate” Pas adapté aux applications intéractives Recouvrement d’erreur hum … Si filtre dépend du contexte => buffer (illimité?)

Hafedh Mili Copyright Batch sequential Pros: Plus flexibles dans la composition, Meilleur recouvrement d’erreurs Cons: Pas adapté aux applications intéractives

Hafedh Mili Copyright Architectures machine virtuelle Principe: Le programme à exécuter est traité comme un donnée pour un autre programme visible Objectif principal: Assurer la qualité “portabilité” Assurer la qualité “modifiabilité”

Hafedh Mili Copyright Architectures machine virtuelle Données du programme Programme à interpréter État de l’interprète Interprète entrées Prochaine instruction État du programme Instruction et donnée choisies Sorties

Hafedh Mili Copyright Architectures machine virtuelle Exemples: Systèmes à base de règles, Émulateurs de Java Shells Etc.

Hafedh Mili Copyright Architectures machine virtuelle Pros: TRÈS flexible Peu de programmation, Modifiabilité dynamique de fonctionnalité et de modalité d’exécution. Cons: Performance Difficulté conceptuelle, déboggage, etc.

Hafedh Mili Copyright Architecture par composantes indépendantes Principe: L’application consiste en plusieurs objets ou processus indépendants qui communiquent. Objectif principal: Modifiabilité, Intégrabilité, Scalability

Hafedh Mili Copyright Architectures par composantes indépendantes Architectures orientées événements: –Invocation implicite: publish and subscribe –Invocation explicite: les messages sont envoyés nominativement (mais les composantes ne se contrôlent pas) Architectures par processus communiquants –Communication généralement bi-directionnelle, synchrone ou asynchrone –Exemple: client-serveur

Hafedh Mili Copyright Architectures orientées événements: publish & subscribe Comp 1 Comp 2 Comp 3 Comp 4 Gestionnaire d’évènements

Hafedh Mili Copyright Architecture orientées évènements Pros: Indépendance des composantes, Scalabilité Configurabilité dynamique Cons: Performance, Difficulté conceptuelle pour gérer des intéractions compliquées

Hafedh Mili Copyright Architectures call-and-return Principe: Le contrôle est centralisé, et détenu par une composante à la fois Les composantes sont synchrones Objectif principal: Réutilisation fonctionnelle Scalabilité

Hafedh Mili Copyright Architectures call-and-return Trois Souches: Programme principal et sous-programme: style dominant pendant 30 ans (structure statique = structure dynamique) –Remote procedure call: idem, avec distribution physique Orientée objets: idem, structure statique regroupe données et fonctions. En couches: composantes distribuées en couches.

Hafedh Mili Copyright Analyse des styles architecturaux Pour chaque style, nous devons répondre à: Quel type de composantes et connecteurs Comment le contrôle est géré et passé entre composantes, Comment les données sont échangées Comment le contrôle et les données intéragissent, Quel type de raisonnement est possible

Hafedh Mili Copyright Composantes et connecteurs Composante: un bout de logiciel qui fait de quoi durant l’exécution Connecteur: un méchanisme pour gérer la communication et coordination entre composantes. La relation entre styles et (types de composantes, connecteurs) est dégénérée,

Hafedh Mili Copyright La gestion du contrôle Les questions à adresser: Topologie (linéaire pour P&F, hiérarchique, pour C&R, etc.) Synchronisation (ou manque de): en unison, parrallèle, rendez-vous, etc. Temps de résolution: codage (C&R non- OO), compilation, chargement, exécution (event-based).

Hafedh Mili Copyright Les données Topologie: d’où à où les données cheminent elles Continuité: (continu for P&F, régulier vs. sporadique, etc.) Mode: passées entre composantes vs. partagées, unicast vs broadcast, Temps de résolution: quand est ce que le vis-a-vis dans un échange de données est déterminé?

Hafedh Mili Copyright Intéractions données/contrôle Forme: sont ils isomorphes (si OO, oui!) Directionalité: si isomorphes, est ce données et contrôle vont dans le même sens (P&F, oui, client-serveur, opposé)

Hafedh Mili Copyright Types de raisonnement Différentes styles se prêtent à différents types de validation, Si certaines validations sont critiques, cela peut influencer le choix du style architectural