Architecture, Abstraction et Topologie réseau

Présentation au sujet: "Architecture, Abstraction et Topologie réseau"— Transcription de la présentation:

1 Architecture, Abstraction et Topologie réseau
NSY208 CNAM D. BELLEBIA – 11/12/2007

2

3 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

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

5 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

6 2) Patterns : définitions
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

7 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

8 2) Définition dans le domaine logiciel
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 Forces Problème Solution logicielle

9 3) Architecture: définition et patterns
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

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

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

12 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

13 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

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

15 3) Architecture – Layers
Figure reproduite de puis [2]

16 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

17 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

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

19 Plan 4) Patterns : d’abstraction, de création et topologie
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

20 4) Wrapper façade (Enveloppe)
Problème Comment faire pour encapsuler les fonctionnalités de chaque système embarqué en 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 »

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

22 4) Composite Problème Forces
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

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

24 4) Composite

25 4) Fabrique abstraite Problème Forces
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

26 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

27 4) Fabrique Abstraite

28 4) Singleton Problème Forces
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é

29 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

30 4) Visiteur Problème Forces
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

31 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

32 4) Visiteur

33 5) Programmation Orientée Aspect
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

34 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

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

36 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

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

38 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 des poule et du cache Design patterns Authentification et autorisation Gestion des transactions Règles métiers

39 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 Constructeur l’initialisation de l’instance Exceptions occurrence 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);

40 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

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 compte chqèue

44 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, 2003