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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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 »

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

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

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

4) Composite

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

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

4) Fabrique Abstraite

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é

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

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

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

4) Visiteur

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

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

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

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

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

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

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);

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

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

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

5) Programmation Orientée Aspect (POA) Logique métier : l’aspect compte chqèue

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