Cedric Dumoulin. Compilation de présentations de : Jeanine Leguy

Transcription

1 Cedric Dumoulin Compilation de présentations de : Jeanine Leguy

2 Contenu Canevas et Patrons Singleton façade Architectures logiques Retour aux patrons de conceptions Observateurs-Observé MVC Les architectures Physiques (n-tier) Retour au processus de développement avec UML Introduire les objets frontière et contrôle 2

3 3

4 Architecture Logique et architecture physique Architecture logique décrit la structuration en sous-systèmes (paquetages) d un système et leurs dépendances. Architecture physique décrit les composants (code, source, fichier, ) qui composent l application. La normalisation des architectures est grandement facilitée par l'utilisation de Canevas (Framework) et de Patrons (patterns). Ils favorisent : la réutilisation la capitalisation d expérience.

5 5

6 Canevas (framework ) Canevas (fr) == Framework (us) Framework c est un squelette qui peut être utilisé ou adapté pour une famille d applications. Il met en œuvre un modèle. Il comprend un ensemble de classes, souvent abstraites à adapter à des environnements ou contraintes spécifiques. Le framework est plus orienté implémentation que les patrons. se situe au niveau des composants: fichier source, exécutable, fichier XML, répertoires,. par comparaison, le patron se situe au niveau du concept, Un framework utilise des patrons. Exemple de frameworks J2EE, Spring, Struts, GEF 6

7 Patron (patterns) C est une solution générique à un problème (générique), il s agit d une solution éprouvée. Il permet de capitaliser sa propre expérience et celle des autres. Des catalogues de patrons existent, avec leurs descriptions. La bible (par la bande des quatres ): Design Patterns: Elements of Object-Oriented Software, par Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides Design Patterns in Java, 2nd Edition, par Steven John Metsker, William C. Wake Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, par Deepak Alur; John Crupi; Dan Malks Java Design Patterns: 7

8 Patron (patterns) L utilisation de patrons renforce l abstraction. Le patron fournit une solution à un problème (abstrait) indépendant du domaine Il existe différents types de patrons : les patrons d analyse Fournissent des solutions réutilisable pour les étapes d analyse (P.Coad 1995) les patrons architecturaux Model View Controler, DTO,... les patrons de conception (Design Pattern) ex: Singleton, Observateur, Factory, cf Gamma & Co, J2EE 8

9 Patrons de Conception (Design Patterns) Patrons de création Abstract Factory Factory Method Singleton Builder Prototype Patrons de structure Adapter Bridge Composite Decorator Façade Flyweight Proxy Patrons de comportement Template Observer Command Chain-of-responsibility Intepreter Iterator Mediator Memento State Strategy Visitor 9

10 Comment est décrit un patron? Nom Le nom identifiant le patron Problème Quel est le problème récurrent qui se pose? Solution générale Quel solution générale est proposée? Exemple Un exemple illustrant l application du patron 10

11 Patron de conception : Singleton problème: S assurer qu une classe n a qu une seule instance et pouvoir accéder à cette instance Comment le résoudre?? 11

12 Patron de conception : Singleton Solution: On laisse la classe gérer sa propre instance: Rend le constructeur inaccessible => privé Pas d accès direct à l instance => attribut privé une opération publique de type getter /** Un idiom (java) */ public class UnSingleton{ private UnSingleton theinstance ; /** Constructor */ private UnSingleton(){} } public static UnSingleton gettheinstance(){ if (theinstance == null) theinstance = new UnSingleton(); return theinstance; } 12

13 Patron de conception Façade Problème : Vous avez un système complexe, difficile à utiliser, avec beaucoup d interfaces. Solution Fournir une interface unifiée et simplifiée pour utiliser le système La façade sert de point d entré dans le système 13

14 Patron de conception Façade - exemple Une Library, composée de plusieurs classes Peut être complexe si utilise JDBC Une facade offrant des opérations de haut niveau d abstraction sur la Library cache la complexité permet de changer l implémentation de la Library 14

15 15

16 Architectures Logiques en couches 3 couches de bases 16

17 La couche Présentation Prend en charge les interactions utilisateur logiciel Peut être : Une simple ligne de commande Une interface graphique (swing, gef, gmf, ) Un navigateur internet Rôle : visualiser les informations Traduire les commandes de l utilisateur en actions sur les autres couches. 17

18 La couche Infrastructure Pour communiquer avec d autres systèmes ou d autres applications : acteurs systèmes externes, serveurs BD systèmes de messagerie, 18

19 La couche Applicative Composée des services (cas d utilisation) demandés par l utilisateur. Des classes du métier pour lequel l application est destinée. Contient tous les traitements mettant en cause les objets métier 19

20 Découpage en couches (1) Avantages : Découpage conforme à une démarche structurée par les cas d utilisation On peut s occuper d une couche sans avoir à connaître le détail des autres couches Minimise les interdépendances entre couches Favorisent la standardisation (framework), facilite la réutilisation et la substitution (couplage plus faible et mieux contrôlé) La sécurité peut être renforcée 20

21 Découpage en couches (2) inconvénients Plus conceptuelle, plus complexe, plus exigent. Attention aux performances! 21

22 Découpage en couches (3) Principes Une couche s appuient sur les couches inférieurs uniquement Une couche ne peut pas dépendre d une couche de n supérieur. (un objet métier ne doit pas dépendre de la façon dont on le visualise! en particulier un même objet peut avoir différentes visualisations!) Idéal : une couche n ne connaît que la couche n-1. 22

23 Découpage d une couche Une couche peut prendre différentes «incarnations» Exemple: une application peut avoir plusieurs présentations: une couche présentation basée sur une interface graphique (swing ou GTK) une couche présentation basée sur l utilisation d un navigateur web (html, jsp, php ). une interface de commandes en ligne Chaque «incarnation» est contenu dans un paquetage indépendant. 23

24 Autres Découpage en Couches Il existe d autres découpages en couches: 5 couches (modèle de Brown ) == modèle précèdent + couches intermédiaires (logique applicative et Accès données) Objectifs: Réduire encore la complexité Faciliter la réutilisation, la substitution 24

25 La couche IHM (Présentation) Rôle : Gérer le dialogue Humain-machine. C.a.d. Capter, sous forme d événements, les requêtes provenant de l utilisateur (clavier, souris, voix, ) Retranscrire ces événements sous forme d envoi de messages à destination de la couche applicative. Récupérer la réponse. Afficher les résultats Caractéristiques : Peu, voire, pas «d intelligence» Exemple de patrons à utiliser : Singleton, Observateur Exemple de Frameworks réutilisables : Struts, Spring, Technos HTML, PHP 25

26 Couche Applicative Rôle : Implémenter les services (cas d utilisation) demandés par l utilisateur Utilise les services «métier» (propres au domaine de l application, couche inférieure) Utilise les services techniques (authentification, autorisation, ) Caractéristiques : Sollicitée la plupart du temps par l IHM. Moyennement réutilisable Exemple de patrons à utiliser : Singleton, fabriques, commande, chaîne de responsabilités,. 26

27 Couche Métier Rôle : Implémenter les services atomiques métiers propres au domaine et réutilisables par les applications. Permet de capitaliser le savoir faire de la structure en matière de règle de gestion. Caractéristiques : Sollicitée par la couche applicative. Garant de l intégrité des données. Potentiellement réutilisable. Localisation des règles métier, règles de gestion et contrôle de cohérence Exemple de patrons à utiliser : Singleton, fabrique, comportement-état, 27

28 Couche d accès aux données Rôle : Gèrer le fossé difficile à combler entre le modèle objet et le modèle physique support de persistance non objets. Eviter un couplage trop fort entre le modèle «Objets» et le modèle physique de données pas de SQL dans les classes métier, pas de référence à la BD Caractéristiques : Souplesse, fiabilité, efficacité, sécurité, facilité d utilisation. Exemple de patrons à utiliser : Singleton, Pool ( pour le pool de connexion), façade pour cacher les implémentations, factory Exemple de frameworks réutilisable : Hibernate EJB Java Persistance API (JPA) JDBC (à éviter) 28

29 Couche Gestion des données Rôle : Stocker les données de manière persistante. Caractéristiques : Transactionnelle, Efficace. Exemple : Bases de données relationnels, SGBD/R, base de données Objet, fichiers. 29

30 Autre exemple : Les niveaux d un système d information (orienté web) Nom du niveau Responsabilité Technologie d implémentation Présentation Affichage interface utilisateur JSP/ASP/PHP/HTML/DHTML/Ec mascript,flash Application Flux cas d utilisation UI, validation, interaction avec les services Servlets, Script CGI Services Domaine Contrôle transactionnel, logique métier/flux procédural, comportement façade Modèle du domaine, logique domaine/métier, validation sémantique Composant de session : Bean Session, Web Service Composant d entité : Bean entité, simple objet, SDO Persistance Stockage persistant de l état des objets du domaine O/R mappers, BDDOO, EJB CMP/BMP, JDO 30

31 31

32 Patron de Conception Observateurs-Observé Problème : Plusieurs objets hétéroclites doivent recevoir des événements venants d un objet O (changements, modifications ) O ne connaît pas les classes des objets à notifier Utilisé quand la modification d un objet (l observé) peut modifier d autres objets (les observateurs) L observé ne connaît pas forcément les observateurs On veut éviter un couplage trop fort entre l'observé et ses observateurs 32

33 Patron de Conception Observateurs-Observé Solution: L observé propose un service pour ajouter ou enlever des observateurs. Chaque observateur implémente une interface avec une méthode (update()) L observé connaît l interface des observateurs, le nombre d observateurs est quelconque. 33

34 Patron de Conception Observateurs-Observé L observé envoie une notification à chaque fois qu il est modifié. L observateur connaît l observé. transparence: Ajout possible d un observateur sans modifier l observé ni les autres observateurs. Couplage faible L observé possède une liste d observateurs, les observateurs doivent se conformer à l interface, l observé ne connaît pas le vrai type des observateurs. Diffusion La responsabilité de l observé est de notifier, les observateurs donne suite ou pas à cette notification. Un observateur peut demander à être rattaché ou détaché conformément à la «politique» du vrai observé. dépendance 34

35 Patron d Architecture MVC (Modèle Vue Contrôleur) problème : Un modèle (= un ensemble de données) peut être visualiser à l aide de différentes vues. Le modèle peut être modifié à partir de n importe laquelle de ces vues. Quand le modèle est modifié, toutes les vues doivent être rafraichies. visualise et modifie Vue 1 No m Prénom toto modèle (observé) visualise et modifie visualise et modifie Vue 3 No m Vue 2 No m Prénom toto Prénom toto 39

36 Patron d Architecture MVC (Modèle Vue Contrôleur) Solution : On utilise 3 entités : Modèle contient les données à afficher Vue - fait l affichage Contrôleur coordonne les deux Vue Nom observe et modifie contrôleur observe et modifie modèle Le plus connu des patrons d architecture. Utilise le patron de conception observateurs-observé. Prénom toto 40

37 Le modèle Contient les données à afficher et modifier définit la logique de manipulation de ces données. Envoie des événements quand les données sont modifiés Ne connaît ni la vue ni l API du contrôleur On utilise le patron observateurs-observé (le contrôleur est observateur, le modèle est l observé) contrôleur observe et modifie observe et modifie Vue Nom modèle Prénom toto

38 La Vue Est chargé de l affichage à l écran Envoie des événements correspondant aux actions de l utilisateur (click, survol, sélection, ) Ne connaît ni l API du contrôleur, ni le modèle contrôleur observe et modifie observe et modifie Vue Nom modèle Prénom toto

39 Le Contrôleur Contrôle la vue et le modèle assure l interaction entre données et vue. Connaît la vue et le modèle Observe le modèle, modifie la vue en conséquence Observe la vue, modifie le modèle en conséquence contrôleur observe et modifie observe et modifie Vue Nom modèle Prénom toto

40 Relation pattern Observer MVC modèle observe et modifie contrôleur observe et modifie vue observé implémente observateur implémente observateur observé implémente Le contrôleur observe le modèle il modifie la vue quand le modèle change Le contrôleur observe la vue il modifie le modèle quand l utilisateur agit sur la vue Le modèle ou la vue notifient le contrôleur quand ils changent 45

41 Avantages du MVC Vue 1 observe et modifie contrôleur observe et modifie No m Prénom toto modèle (observé) observe et modifie observe et modifie contrôleur contrôleur observe et modifie observe et modifie Vue 2 No m Prénom toto Vue 3 No m Prénom toto Il peut y avoir plusieurs vues sur le même modèle Plusieurs contrôleurs peuvent modifier le même modèle Toutes les vues seront notifiées des modifications 46

42 48

43 Architecture Logique vs Physique Architecture Logique Découpage logique de l application ex.: découpage en paquetages Architecture Physique ensemble de ressources physiques nécessaire à l exécution de l application (ordinateurs, ) L architecture logique est répartie sur l architecture physique 49

44 Les architectures centralisées ou 1-niveau (1-tier) Toutes les couches logique sont situées soit sur la même machine un mainframe avec des postes passifs (terminaux) soit sur une machine isolée (stand alone). Même si l architecture logique est bien conceptualisée, le risque de dérive est grand dans les cycles d évolution. dérive vers des interdépendances entre couches 50

45 Les architecture 2-niveaux (2-tiers) Les couches logiques sont séparés sur deux sites Les dispositifs du serveur (BD, service de messagerie, ) sur un site Le reste de l architecture sur les postes client. Permet le partage d information entre utilisateurs => accès simultanés, synchronisation des données. Existe des variantes pour «alléger» le poste client Plus (+) d applicatif sur le site serveur Avantage : facile à utiliser. Inconvénient : déploiement et maintenance difficiles. Attention aux performances! 51

46 Exemples d architecture logique sur architecture physique Architecture centralisée Application Cliente Services (jdbc, mail, jca, etc ordinateur Application Cliente Domaine Services (jdbc, mail, jca, etc ordinateur Architecture client / serveur Application Cliente Application Cliente Domaine Domaine Domaine Services (jdbc, mail, jca, etc Services (jdbc, mail, jca, etc Services (jdbc, mail, jca, etc ordinateur ordinateur ordinateur 52

47 Exemples Serveurs web Navigateur (html, ) Navigateur (html, ) Architecture centralisée Servlet Services (jdbc, mail, jca, etc ordinateur Servlet Domaine Services (jdbc, mail, jca, etc Architecture client / serveur Navigateur (html, ) Servlet Navigateur (html, ) Servlet Domaine Services (jdbc, mail, jca, etc Domaine Services (jdbc, mail, jca, etc Domaine Services (jdbc, mail, jca, etc

48 54

49 Retour au processus de développement avec UML phase: élaboration, activité: Analyse & conception tâches: Définir une architecture physique initiale Définir un modèle de déploiement initial Identifier les couches Identifier les classes d analyse Répartir les classes dans les couches Identification des interactions IHM/applicative 55

50 Définir une architecture initiale Choix de l architecture dépend de différents critères liés à l application : Logiciel mono utilisateur ou multi utilisateurs? Centralisée ou répartie? Quels sont les éléments partagés? Quels sont les dispositifs de sécurité à mettre en place? Quels types de clients? 56

51 Les types de clients Client léger: pas de dispositif spécifique sur le poste client ex: navigateur web Client «allégé» : nécessite l installation d outils pour supporter l application ex: une JRE pour l utilisation d applet. Client lourd: nécessite l installation de «morceaux de l application» sur le poste. généralement réservé aux administrateurs du système Plus les clients sont légers et plus le système est facile à déployer et à maintenir. Le choix du type de client impact directement l architecture. Par exemple client légers => utilisation d un navigateur => appli Web 57

52 Définir un modèle de déploiement initial Utilise les diagrammes de déploiement d'uml: Composé de nœuds et de liens, Permet de répartir physiquement une application. Déployer l architecture logique sur l architecture physique Un nœud correspond à une ressource physique PC, Serveur de BD,., les liens correspondent à des connexions, des supports de communication. 58

53 Identification des couches On commence à identifier les couches physique logique 59

54 Identifier les classes d analyse Inspirées du modèle MVC, Part des classes d analyse on essaie de les classer : <<boundary>>, <<control>>, <<entity>> On peut utiliser des stéréotypes UML pour marquer les classes : <<boundary>>, <<control>>, <<entity>> <<boundary>> <<control>> <<entity>> <<entity>> 60

55 Identifier les classes d analyse Classe <<boundary>> ou <<frontière>> On les trouve entre un acteur (humain) et le système (généralement graphique) La classe est alors une abstraction des écrans identifiés lors de l étape d identification des écrans entre le système et les acteurs système (Interface) Normalement il y a une classe frontière par couple (acteur, CU) Une classe << frontière>> regroupe plusieurs classes écrans. Dans cette activité on ne s occupe pas de l enchaînement des écrans. On suppose que l IHM permet à l acteur de communiquer avec l application. Classe <<control>> contrôle associé à un scénario Au moins une classe <<control>> candidate par scénario, mais cette classe peut se retrouver dans plusieurs scénarios Classe <<entity>> Ce sont les objets métier du système destinés à être sauvegardés. 61

56 Répartition des classes dans les couches Les <<frontière>> : dans la couche IHM et infrastructure (écrans) Les <<contrôle>> dans la couche application Les <<entité>> dans la couche métier. <<boundary>> <<control>> <<entity>> <<entity>> IHM applicatif metier acces infrastructure 62

57 63

58 Diagramme de séquence système (DSS) Diagramme de Séquence Système (DSS) DSS: représentes les interactions acteur <-> système se construit à partir des scénarios Un DSS par scénario une action une interaction dans le DSS : Scolarité : Système Demande de MAJ de candidature Liste des candidatures Sélection d'une candidature Informations sur la candidature Modification Informations sur la candidature Enregistrement 64

59 Identification des interactions couches IHM / Applicative IHM applicatif metier acces infrastructure Part des DSS Pour chaque interaction acteur<->système faire une interaction couches IHM<->Applicative Le DSS représente les opérations systèmes mais masquage des détails de l IHM Les objets de l IHM captureront les requêtes d opérations; appelleront les opérations métiers ne font pas de logique métier!!! Il faut «détailler» le système en introduisant des classes : UI - boundaries classes «écrans» ou capturant les actions de l acteur contrôleur - control : Système : Scolarité Demande de MAJ de candidature Liste des candidatures Sélection d'une candidature Informations sur la candidature Modification Informations sur la candidature Enregistrement 65

60 Interactions IHM Applicative Introductions de contrôleurs IHM applicatif metier acces infrastructure Peut utiliser le pattern «façade» dans la couche applicative façade classe ou interface proposant des services de haut niveaux peut dispatcher vers les objets métiers n est pas un vrai objet métier; mais fait partie de la couche métier ou applicative La façade fournit les opérations système Aussi appelé contrôleur (XxxCtr) L objet façade peut aussi fournir la gestion des enchaînement des écrans (workflow) maintenir les sessions <<boundary>> <<facade>> 66

61 Interactions IHM Applicative Introductions de classes Introduit UI (= boundary) et Ctrl (= control) Reporte les interactions du DSS on les détaille De nouvelles classes apparaissent : Scolarité : Système : scolarité demandemajcandidature listcandidature selectioncandidature infocandidature gerercandidatu reui demandemajcandidature listcandidature selectioncandidature infocandidature gerercandidatu rectrl lireinfo info : Candidature cherchercandidatures cherchercandidature Demande de MAJ de candidature Liste des candidatures modificationinfo modificationinfo modification Sélection d'une candidature Informations sur la candidature Modification Informations sur la candidature Enregistrement 67

62 Interactions IHM Applicative : Exemple Swing (from Presentation) EcranTraitem entventes Presentation Domaine Ventes (from Domaine) Exemple de façades: Registre Quand l application n a que quelques opération, un seul objet peut suffire Les services techniques exposent plusieurs interfaces au moins une par sous-système Registre (from Ventes) Vente (from Ventes) ServicesTechniques Persistance (from ServicesTechniques) FacadeBD (from Persistance) Log4J (from ServicesTechniques) SOAP (from ServicesTechniques) 68

63 Interactions Applicative IHM RAPPEL : Les classes de la couche applicative ne connaissent pas l IHM!!! Utilise le pattern Observateur/Observé Observateur: les objets IHM Observé: les objets métier Les objets métier ne connaissent que l interface Observateur (et pas la classe IHM l implémentant) peuvent notifier l observateur, et donc l IHM lors de changements changement rafraîchissement de la vue 69

64 Lectures Patterns (java)

65 Bibliographie Architecture 3 couches Architecture client-serveur 71