Les architectures Une introduction Hafedh Mili. Hafedh Mili Copyright 1999-20042 Plan  Introduction Définitions Architectures et critères de qualité.

Présentation au sujet: "Les architectures Une introduction Hafedh Mili. Hafedh Mili Copyright 1999-20042 Plan  Introduction Définitions Architectures et critères de qualité."— Transcription de la présentation:

1 Les architectures Une introduction Hafedh Mili

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

3 Hafedh Mili Copyright 1999-20043 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”

4 Hafedh Mili Copyright 1999-20044 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

5 Hafedh Mili Copyright 1999-20045 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]

6 Hafedh Mili Copyright 1999-20046 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

7 Hafedh Mili Copyright 1999-20047 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

8 Hafedh Mili Copyright 1999-20048 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

9 Hafedh Mili Copyright 1999-20049 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

10 Hafedh Mili Copyright 1999-200410 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

11 Hafedh Mili Copyright 1999-200411 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)

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

13 Hafedh Mili Copyright 1999-200413 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à.

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

15 Hafedh Mili Copyright 1999-200415 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à.

16 Hafedh Mili Copyright 1999-200416 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.

17 Hafedh Mili Copyright 1999-200417 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

18 Hafedh Mili Copyright 1999-200418 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.

19 Hafedh Mili Copyright 1999-200419 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.)

20 Hafedh Mili Copyright 1999-200420 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.

21 Hafedh Mili Copyright 1999-200421 Structures architecturales (suite)

22 Hafedh Mili Copyright 1999-200422 Structures architecturales (suite)

23 Hafedh Mili Copyright 1999-200423 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à.

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

25 Hafedh Mili Copyright 1999-200425 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).

26 Hafedh Mili Copyright 1999-200426 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)

27 Hafedh Mili Copyright 1999-200427 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

28 Hafedh Mili Copyright 1999-200428 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.)

29 Hafedh Mili Copyright 1999-200429 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

30 Hafedh Mili Copyright 1999-200430 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.

31 Hafedh Mili Copyright 1999-200431 Attributs de qualité: résumé

32 Hafedh Mili Copyright 1999-200432 Attributs de qualité: résumé

33 Hafedh Mili Copyright 1999-200433 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

34 Hafedh Mili Copyright 1999-200434 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é

35 Hafedh Mili Copyright 1999-200435 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.

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

37 Hafedh Mili Copyright 1999-200437 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]

38 Hafedh Mili Copyright 1999-200438 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.

39 Hafedh Mili Copyright 1999-200439 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.

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

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

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

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

44 Hafedh Mili Copyright 1999-200444 Architectures machine virtuelle Interprète À base de règles

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

46 Hafedh Mili Copyright 1999-200446 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”

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

48 Hafedh Mili Copyright 1999-200448 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”)

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

50 Hafedh Mili Copyright 1999-200450 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é”.

51 Hafedh Mili Copyright 1999-200451 Style batch sequential Traitement 1 Traitement 2 Traitement 3 input

52 Hafedh Mili Copyright 1999-200452 Style pipe & filters Filtre 1Filtre 2Filtre 3 input Filtre 4 Pipe tuyau

53 Hafedh Mili Copyright 1999-200453 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é?)

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

55 Hafedh Mili Copyright 1999-200455 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é”

56 Hafedh Mili Copyright 1999-200456 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

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

58 Hafedh Mili Copyright 1999-200458 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.

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

60 Hafedh Mili Copyright 1999-200460 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

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

62 Hafedh Mili Copyright 1999-200462 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

63 Hafedh Mili Copyright 1999-200463 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é

64 Hafedh Mili Copyright 1999-200464 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.

65 Hafedh Mili Copyright 1999-200465 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

66 Hafedh Mili Copyright 1999-200466 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,

67 Hafedh Mili Copyright 1999-200467 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).

68 Hafedh Mili Copyright 1999-200468 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é?

69 Hafedh Mili Copyright 1999-200469 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é)

70 Hafedh Mili Copyright 1999-200470 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