Architecture, Abstraction et Topologie réseau DJBELL – 16/11/2010NSY208 CNAM

2

Plan Programmation Orientée Objet Patterns : définitions Architecture: définition et patterns Patterns : d’abstraction, de création et topologie Programmation Orientée Aspect 3

1) Programmation Orientée Objet Concepts –Abstraction : chaque entité est un objet –Encapsulation : données + méthodes –Héritage –Agrégation –Composition / Décomposition 4

1) Programmation Orientée Objet (POO) Promesses –Modularité : données + traitements dans une classe –Réutilisation des classes dans # contextes –Sûreté : grâce à l’encapsulation, la manipulation des données est très encadrée –Extensibilité : du fait de l’héritage les classes peuvent être spécialisées 5

Plan 1) Programmation Orientée Objet 2) Patterns : définitions 3) Architecture: définition et patterns 4) Patterns : d’abstraction, de création et topologie 5) Programmation Orientée Aspect 6) Le TP01 à rendre le 24/12/2007 6

2) Patterns & Définition de C. Alexander Un problème qui se produit encore et encore dans un environnement + Une solution que l’on peut appliquer 1M de fois 7

2) Définition dans le domaine logiciel Problème Forces Solution logicielle Cryptage de donnée Problème: plusieurs algorithmes pour ce tâche Forces: le choix de l’algo. en fonction du contexte Solution : le modèle stratégie qui définit une famille d’algo. avec 1 même interface et qui sont interchangeables 8

Plan 1) Programmation Orientée Objet 2) Patterns : définitions 3) Architecture: définition et patterns 4) Patterns : d’abstraction, de création et topologie 5) Programmation Orientée Aspect 6) Le TP01 à rendre le 24/12/2007 9

3) Architecture - Définition Composants et comportement d’un système Rassembler des informations Concevoir une solution Processus créatif Pragmatisme 10

3) Architecture - Forces Figure reproduite de puis [1] 11

3) Architecture – Layers Problème –Comment établir un faible couplage entre les différents composants d’un système ? Forces –Code non éparpillé –Interfaces stables –Limiter les dépendances –Coût de communication 12

3) Architecture – Layers Solution –Décomposition des systèmes en groupes de tâches secondaires ou sous-systèmes. –3 stratégies de mise en œuvre Ouverte Fermée Par héritage 13

Système d’exploitation (Windows, S60) Serveur (Brazil HTTP ou Bluetooth) 3) Architecture – Layers Couche micronoyau (Noyau, Internes et Externes) Couche application (Espace utilisateur) INTERGICIEL Machine Virtuelle Java 14

3) Architecture – Layers Figure reproduite de puis 15

3) Architecture – Microkernel Problème –Comment organiser les différents éléments d’un système dans une logique d’adaptation ? Forces –Des versions multiples d’un système –Tenir compte des caractéristiques des # plateformes –Séparation entre les fonctionnalités 16

3) Architecture – Microkernel Solution –Système adaptable avec des services de base dans un noyau minimal –Mécanisme de « Plug & Play » pour les autres services –3 modules Micronoyau : gestion des ressources, ordonnancement Services internes : communication réseau Services externes : gestion des traces 17

3) Architecture – Microkernel Figure reproduite de puis [3] 18

Plan 1) Programmation Orientée Objet 2) Patterns : définitions 3) Architecture: définition et patterns 4) Patterns : d’abstraction, de création et topologie 5) Programmation Orientée Aspect 6) Le TP01 à rendre le 24/12/

4) Wrapper façade (Enveloppe) Problème –Comment faire pour encapsuler les fonctionnalités de chaque système embarqué pour former un tout ? Forces –Fonctionnalités sont implantées avec un langage de bas niveau –Forte Hétérogénéité –Il existe une forte contrainte de « Time To Market » 20

4) Wrapper façade Solution –Objet intermédiaire qui va fédérer les services –Façade pour le monde extérieure 21

4) Composite Problème –Comment organiser et regrouper les systèmes et comment fédérer leurs services ? Forces –Une multitude de systèmes -> impossible de tous les identifier –L’utilisateur ne doit pas se soucier pour un service donné, si il est fournit par un seul système ou par un groupe de systèmes 22

4) Composite Solution –Avec des objets simples (feuilles) et des objets containers (composites) -> structure –Une seule interface -> une invocation identique 23

4) Composite 24

4) Fabrique abstraite Problème –Comment faire pour faciliter la création d’instance de chaque type de système ? Forces –Au démarrage, chaque instance crée doit se faire selon les capacités de chaque système –Il faut avoir une famille de systèmes apparentés –Il faut travailler avec des interfaces et non directement les systèmes 25

4) Fabrique Abstraite Solution –Définition d’une interface commune pour la création de famille d’objets apparentés –Les implémentations concrètes de création, peuvent être rajouter au fur et à mesure 26

4) Fabrique Abstraite 27

4) Singleton Problème –Comment garantir que chaque instance de système est unique quelle soit facilement accessible ? Forces –L’intégrité de l’intergiciel dépend de l’unicité de chaque instance –Le constructeur public ne permet de garantir l’unicité 28

4) Singleton Solution –Cacher le constructeur de la classe –Création d’instance se fait à l’aide d’une méthode publique ou l’on vérifie l’existence de la classe 29

4) Visiteur Problème –Comment séparer la structure des opérations applicables dessus ? Forces –Implanter le code de l’opération sur chaque élément de la structure n’est pas envisageable –La structure doit être stable –L’ajout d’une nouvelle opération doit être simple 30

4) Visiteur Solution –Une interface externe à la structure mais qui en connaît tous les éléments –Chaque opération sera codée dans une nouvelle classe dédiée 31

4) Visiteur 32

Plan 1) Programmation Orientée Objet 2) Patterns : définitions 3) Architecture: définition et patterns 4) Patterns : d’abstraction, de création et topologie 5) Programmation Orientée Aspect 6) Le TP01 à rendre le 24/12/

5) Programmation Orientée Aspect (POA) Limites de la POO –Fonctions transversales : exemple de l’intégrité référentielle –Dispersion de code : modification d’une signature d’une méthode, il faut intervenir sur toutes les classes –POA une solution à ces limites : les classes gardent leur rôle primaire (données + traitements) les aspects pour les fonctions transversales 34

5) Programmation Orientée Aspect (POA) Sans aspects Avec aspects Figure reproduite de puis [4] 35

5) Programmation Orientée Aspect (POA) POA : un fondement dans plusieurs paradigmes de la programmation (POO, MDA, etc.) Un complément à la POO et pas 1 remplacement Une nouvelle dimension de modularité Introduit un nouveau processus pour la réalisation des systèmes en deux phases : – les classes pour répondre à logique métier (POJO) – les aspects pour les fonctions transversales 36

5) Programmation Orientée Aspect (POA) Concepts –Concerns : vision du système selon les préoccupations Figure reproduite de puis [5] 37

5) Programmation Orientée Aspect (POA) Tissage –Tissage statique à la compilation –Tissage dynamique à l’exécution Domaines d’application –Traçage, profiling –Programmation par contrats –Optimisation : gestion du cache –Design patterns –Authentification et autorisation –Gestion des transactions –Règles métiers 38

5) Programmation Orientée Aspect (POA) Concepts (suite) –Point de jonction (join point) : point d’exécution autour duquel 1 ou plusieurs aspects peuvent être introduits Méthode appel, début ou fin Attributs lecture écriture Constructeurl’initialisation de l’instance Exceptionsoccurrence d’une erreur Blocs de codes au début à la fin des blocs statique, itératif ou conditionnel protected abstract pointcut subjectChange(Subject s, String eventId); 39

5) Programmation Orientée Aspect (POA) Concepts (suite) –Coupe (crosscut) : ensemble des points de jonction qui correspond à des bloc de code de l’aspect. –Coupe de modification de données –Coupe d’appel de méthodes –Coupe d’exécution de méthode 40

5) Programmation Orientée Aspect (POA) Exemple d’introduction : La banque 41

5) Programmation Orientée Aspect (POA) Exemple d’introduction : La banque 42

5) Programmation Orientée Aspect (POA) La classe Compte (POJO) 43

5) Programmation Orientée Aspect (POA) Logique métier : l’aspect banque 44

5) Programmation Orientée Aspect (POA) Journalisation: Interceptor 45

5) Programmation Orientée Aspect (POA) IHM: MVP 46

Références [1] P. Dyson, A.Longshaw: Architecting Enterprise Solutions, 2004 [2] F. Buschmann, K. Henney, D. C. Schmidt – Pattern-Oriented Software Architecture A Pattern Language for Distributed Computed, Wiley, 2007 [3] B. P. Douglass: Real-Time Design Patterns – Robust Scalable Architecture for Real-Time Systems, Addison-Wesley, 2003 [4] R. Pawlak, J-P Retaillé, L. Seinturier: Programmation orientée aspect pour Java J2EE, Eyrolles, 2004 [5] R. Laddad : AspectJ in Action – Practical Aspect-Oriented Programming, Manning,