séparation des préoccupations.. module modèles, objets et composants

Séparation des préoccupations

. .


Module Modèles, Objets et Composants


. . - 2 -

Organisation du cours

• 2 parties• Principes généraux

• Étude d’aspectJ


. . - 3 -

Première partie

Vous avez dit préoccupation ?

Pourquoi et comment séparer les préoccupations


. . - 4 -

Qu’est-ce qu’une préoccupation ?

• But particulier, concept, domaine d'intérêt

• Un logiciel contient :

–Des préoccupations “métier”Effectuer des paiements : débiter un montant d'un compte définiEffectuer des réservations

–Des préoccupations “système” (ou techniques)Traçage, Identification / authentification, Sécurité (confidentialité), Performances, etc


. . - 5 -

Des applications de plus en plus complexes• Volume grandissant (Data, Code)• Évolutivité grandissante (reorganisations, compétition, …)• Hétérogénéité grandissante (langages, concepts, …)

Des objets « pluridisciplinaires »• Les objets n’ont pas à charge que leur travail

• Les objets « collaborent » pour atteindre un but plus général

• Souvent ces collaborations peuvent être décrites élégamment en utilisant la POO et en se référant à des design patterns

Pourquoi la séparation des préoccupations ?


. . - 6 -

Un exemple : Tomcat

• En rouge, les lignes de code concernées par le parsing

• Bonne modularisation : code concentré en un seul endroit

XML parsing

Copyright © aspectj.org


. . - 7 -

URL pattern matching

• En rouge, les lignes de code pour gérer la correspondance d’URLs

• Bonne modularisation : code concentré en 2 endroits

Un exemple : Tomcat



. . - 8 -

TraceUn exemple : Tomcat

• En rouge, les lignes de code pour tracer l’exécution

• Mauvaise modularisation : le code est mélangé, éparpillé et redondant



. . - 9 -

Pari perdu

"Because of the wonderful unifying properties of the object paradigm, the transition from procedural technology to object technology will bring huge conceptual simplification to the software engineering field. Since everything will be considered as an object, we shall observe a dramatic reduction in the number of necessary concepts."

All together, circa 1980

Le paradigme Objetpromettait la simplification ...

• Application difficile à concevoir, à coder• Code difficile à comprendre

• une structure non explicitée (qui n’est pas un objet)

• la base structurelle est altérée• Code difficile à maintenir, à faire évoluer

• trouver tous les bouts de code impliqués• gérer la consistance d’un changement

Copyrigth © Jean Bezivin, UML’03


. . - 10 -

Évolution des paradigmes pour gérer la réutilisation

Technologie“procedurale”

Technologie“composant”

Technologie“objet”

Objects,Classes,

Smalltalk, C++, ...

Procedures,Pascal, C, ...

Composants, Containers

Interfaces in et out,EJB, CCM, …

1980 1995

Raffinement Composition par assemblage

Séparation despréoccupations

Encapsulation et Spécialisation

Travail collaboratif Prolifération des concepts

Émergence de nouvelles

formes de programmation


. .

Aspect Oriented Programming (AOP)

Projet fondateur du Xerox Alto research Center 2 noms : Cristina Videira Lopes, Gregor Kiczales. Un site : http://aosd.net/


. . - 12 -

Objectif

Séparer les concepts et minimiser les dépendances entreeux pour éviter ou minimiser les entrelacements de code(couplage faible des classes entre elles)

• avoir un code plus petit, plus naturel avec moins d’imbrications

• faciliter les modifications, le « debug » par une vision séparée de chaque concept

• répercuter au minimum la modification d’un concept sur les autres

• réutiliser, enlever, remettre des concepts plus facilement


. . - 13 -

Vocabulaire

cross-cutting? Certaines préoccupations des logiciels affectent ou nécessitent la collaboration d’un groupe d’objets. Elles cross-cut (coupent orthogonalement) l’architecture de base des objets

aspect? Un aspect est une préoccupation qui cross-cut (coupe) l’application

weaving?Générer un code comportant à la fois le code de base et les aspects (on parle aussi de « tissage »)


. . - 14 -

public class Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { return loc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { return loc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { return dim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { return dim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); }

}

interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ;}

class AdjustableLocation { protected double x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronized double get_x() { return x_; } synchronized void set_x(int x) {x_ = x;} synchronized double get_y() { return y_; } synchronized void set_y(int y) {y_ = y;} synchronized void adjust() { x_ = longCalculation1(); y_ = longCalculation2(); }}

class AdjustableDimension { protected double width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronized double get_width() { return width_; } synchronized void set_w(int w) {width_ = w;} synchronized double get_height() { return height_; } synchronized void set_h(int h) {height_ = h;} synchronized void adjust() { width_ = longCalculation3(); height_ = longCalculation4(); }}

Un exemple de code Java


. . - 15 -




. . - 16 -

public class Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { return loc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { return loc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { return dim.width();} void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException{return dim.height();} void set_height(int h) throws RemoteException {dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust();} void adjustDimensions() throws RemoteException { dim.adjust();}}



. . - 17 -




. . - 18 -




. . - 19 -

Où sont les aspects ?

Synchronisation de Threads et Appels de méthodes à distance

2 notions orthogonales à la définition des classes


. . - 20 -

public class Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { return loc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { return loc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { return dim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { return dim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); }}




thread synchronizationremote interaction


. . - 21 -

OOP vs AOP

Programme orienté objet

Structure et fonctions

Appels distants

Synchronization

Programme avec AOP

Classes del’application

Aspect 1

Aspect 2


. . - 22 -

Exemples classiques d’aspects

• Synchronisation des méthodes entre classes

• Appels à distance (Java RMI)

• Persistance

• Transactions

• Authentification

• Qualités de Services (QoS)

• Performances (Load-balancing, caching, …)

• Réplication

• Migration

• …


. . - 23 -

Concepts de base

Point de jonction (join point) : Les différents types de points de contrôle sur le programme de base (invocation de constructeur, initialisation, appel/réception de méthode, accès à un attribut, …)

Coupe (pointcut) : Un ensemble d’instances de points de jonction où on décide de tisser un aspectpointcut trace(): execution(* *.*(..))

« Advice » :Le code à exécuter associé à une coupeL’advice doit indiquer quand exécuter ce code (avant, après, ou à la place de l’exécution des points de jonction contrôlés)

after() returning: trace() { System.out.println(...)}


. . - 24 -

Des outils supportant l’AOP ...

•Des approches à la compilation/au chargement/à l’exécution

•Des approches par transformation de code/de l’interprète

•Des approches orientées langage/framework/service

•AspectJ, JMangler, AspectS, JAC, Noah, Composition Filters, JBoss AOP, ...


. . - 25 -

Approches par transformation de programmePrincipe du tissage (weaving)

Description des classes de l’application + les aspects à utiliser

weaver Code emmêlé“tangled code”


. . - 26 -

Exemple de code généré

public aspect TraceAspect { private Display display; pointcut trace() : execution(* *.*(..)); after() : trace() { display.print(thisJoinPoint.getSignature()) }}

Public class A {

public void m1() {

// code

}

public void m2() {

// code

}

}

Public class A {

private Display display;

public void m1() { // code display.print(this.getClass().getMethod(« m1 », null));}

public void m2() { // code display.print(this.getClass().getMethod(« m2 », null));}

}


. . - 27 -

Approches par transformation de l’interprète

• Le niveau de base décrit les fonctionnalités de l’application

• Le niveau méta décrit la manière d’interpréter le niveau de base

• Les points de jonctions sont les points où les méta objets exercent un contrôle sur un objet du niveau de base

• Modification du mécanisme d’envoi de messages

Réflexion : la capacité d’une entité à s’auto-représenter et plus généralement à se manipuler elle-même, de la même manière qu’elle représente et manipule son domaine d’application premier [Brian Smith]

Méta objets

Objets de l’application


. . - 28 -

Exemple d’approche par transformation d’interprète : Composition Filters (CF)

• Traite les « aspects » en ajoutant des filtres aux messages associés à un objet ou plusieurs d’objets

• Filtres en entrée et en sortie qui affectent les messages reçus et envoyés

Projet TRESE (Twente Research and Education on Software Engineering)

Chair Software EngineeringDepartment of Computer ScienceUniversity of Twente in The Netherlands.

Un nom : Aksit Un site : http://trese.cs.utwente.nl/pages/pages.php?action=showPageOnly&acronym=intro_aop_cf


. . - 29 -

Représentation du modèle CF


. . - 30 -

Exemples de filtres définis

• Filtre Dispatch : message envoyé à sa cible (exécuté si la cible est inner) si accepté

• Filtre Wait : pour la synchronisation et les appels concurrents (message mis en attente tant qu’il n ’est pas accepté par le filtre)

• Filtre Meta : pour abstraire les interactions entre objets

• Filtre Error : pour restreindre l’accès à un objet (visibilité d’interface)

• Filtre Substitution : pour modifier le message (cible, sélecteur de fonction)

• Filtre Send : pour initier une délégation

filterinterface DisplayFilter beginexternals display : Display; internals logOn : boolean; methods loggingOn(); logginOff(); print(Message); conditions LoggingEnabled;inputfilters

trace : Meta = { LoggingEnabled=>[*]display.print };onoff : Dispatch = { loggingOn, loggingOff };

end filterinterface DisplayFilter;


. . - 31 -

Principe de « superimposition »

Composition par coopération des méta objets (les filtres)


. . - 32 -

public class TraceWrapper extends Wrapper {

private Display display;

public void trace(Interaction i) { proceed(i); display.print(i.getMethod()); }

}

Exemple d’approche par transformation d’interprète : JAC

Projet Jacquardun nom : Pawlakun site : http://jac.objectweb.org/index.html

Objet

Wrapper

interception

proceed

Niveau « méta »

Niveau de base

• Les méthodes du wrapper encapsulent les méthodes métiers (advices)

• Un wrapper est associé à une ou plusieurs méthodes indépendamment des classes

• Les wrappers sont liés/déliés aux objets à l’exécution


. . - 33 -

Composition des wrappers associés à la même coupe

• Composition par coopération des méta objets (les wrappers)

• Propriété jac.comp.wrappingOrder du fichier de configuration jac.prop spécifie l’ordre d’enchaînement:

• règles d’incompatibilité

• règles de dépendance

• …


. . - 34 -

Exemple d’approche par transformation d’interprète : Noah

• Une règle r1 par message m d’un objet o au plus

• Si une nouvelle règle r2 associé au message m est appliquée à o alors on fusionne r1 et r2 pour n’obtenir qu’une seule règle (la fusion préserve la commutativité)

Projet Rainbow2 noms : Dery-Pinna, Blay-fornarinoun site : http://noah.essi.fr/

Objet

Règle d’interaction

interception

proceed

Niveau « méta »

Niveau de base

Interaction trace(Object obj, Display display) { obj.* -> obj._call() // display.print(_call)}


. . - 35 -

AOP et composants

• Un conteneur pour des objets métiers fournit des services techniques (persistance, sécurité, transactions, ...)

• Les composants doivent être configurés pour bénéficier de certains services techniques

• Ces services sont « hardcodés » dans le code source du conteneur et se passent successivement la main par des fonctions non standardisées (ordre pré-établi) => en pratique, les préoccupations sont toujours entrelacées (pour le fournisseur de conteneurs mais pas pour l’utilisateur)

• Lorsque l’on atteint les limites du conteneur (ces services sont en nombre prédéfini), les fonctionnalités supplémentaires doivent être introduites à la main.


. . - 36 -

AOP et points de vue

• Inversion des dépendances = la meilleure manière d'éviter la dispersion des préoccupations • Ce n'est plus le programme qui utilise le service mais le

service qui utilise le programme

• Un aspect dit qu’une classe peut l’avoir et non le contraire

• Un aspect peut concerner plusieurs classes de façons différentes


. . - 37 -

AOP, méta programmation et réflexivité

• D’importantes similarités :

• Le contrôle fourni par la méta programmation et la réflexivité est plutôt de bas niveau, très puissant et dangereux

réservées à des programmeurs avancés

• Les outils d’AOP offrent un plus haut niveau d’abstraction et des gardes-fous (points d’entrée limités)

utilisés par de « simples » programmeurs

support de programmation pour prendre en compte le crosscutting


. . - 38 -

Subject-oriented programming (SOP)

Projet Software by Composition group. Software Development Technology department. IBM Thomas J. Watson Research Center,Hawthorne, New York

Un nom : Harold OssherUn site : http://www.research.ibm.com/sop/


. . - 39 -

Une nouvelle façon de programmer objet

Qu’est ce que la SOP ?SOP basée sur les différents rôles que peut jouer un objetCapture différentes vues d’une seule classe (extension à des ensemble de classes)

Comment programmer par « sujets » ?En déterminant comment diviser un système en sujetset en écrivant les règles de composition nécessaires

Quand utiliser la SOP ?Développement de gros systèmes Intégration et interopérabilité des applications

Extensions non planifiées d’application Applications développées par plusieurs équipesIntégration non planifiée d’applications développées

séparément


. . - 40 -

Scénario de partage de code

• 2 équipes de développement :• L'équipe comptable (paiement)

• L'équipe des ressources humaines (gestion du personnel)

• Les 2 équipes développent en parallèle :• Une classe Employé permet de gérer les informations sur un

employé

• Une classe liste d'employés permet de gérer les employés

• Puis une mise en commun du code par utilisation de sujets et de règles de composition


. . - 41 -

Équipe 1 (paiement) : Classe Employé

class employee { private:

int employee_id; char employee_name[64];int position; int salary;char state[3]; char city[64];

public: virtual void print(); virtual int get_employee_id(); virtual void set_employee_id(int); ...

};


. . - 42 -

Équipe 2 (personnel) : Classe Employé

class employee { private:

int employee_id; char empname[64]; char line1[64]; char line2[64]; char state[3]; char city[64]; char zipcode[9];

public: virtual void output(); virtual void generate_report(); // uses outputvirtual int get_employee_id();virtual void set_employee_id(int); ...

};


. . - 43 -

Équipe 1 (paiement) : Classe Liste d'employés

class employee_list { private:

employee_list* head; employee_list* next; employee* employee_on_list;

public:

virtual void print(); virtual employee_list* insert(employee*);virtual employee_list* get_head(); ...

};


. . - 44 -

Équipe 2 (personnel) : Classe Liste d'employés

class employee_list { private:

employee_list* head; employee_list* next; employee* employee_on_list;employee_list* prior;

public: virtual void print();virtual employee_list* insert(employee*);virtual employee_list* get_head();virtual void remove(); ...

};


. . - 45 -

Mise en commun

• Définitions de sujets pour chaque équipe• L'équipe 1 définit le sujet paiement

• L'équipe 2 le sujet personnel

• Et utilisation de règles de composition• composition spécifiée dans un fichier de règles (.rul)

• nouveau sujet créé par composition


. . - 46 -

Définition de la spécification d’un sujet (label)

Abstraction du programme :

• Opérations Signatures des méthodes

• Classes Les variables d’instances

• Mapping Classe - Opération • Association comportement et classes d’implémentations

• Une opération implique une partie réalisation (points d’entrée dans les implémentations des méthodes)


. . - 47 -

Définition de la spec du sujet Paiement

Subject: Paiement Operations: print(), getXXX(), setXXX(), insert (...), …; Classes: employee with Instance Variables: employee_id, employee_name, ...; employee_list with Instance Variables: head, next, ...; Mapping: Class Employee, Operation Print() implemented by: &Employee::Print(), …;


. . - 48 -

Types de règles de composition

• Règles de correspondance

• Mise en correspondance sans spécifier comment combiner

• Règles implicites : MatchByName et DontMatch

• Règles explicites : Equate et Correspond

• Equate(A, B); Correspond(A, B, B);

• Règles de combinaison

• Join (jointure)

• Replace (remplacement)

• Règles mixtes de correspondance et de combinaison

• ByNameMerge(A, B); MatchByName(A); Join(A); Equate(A, B);

• NoncorrespondingMerge(A, B); DontMatch(A); Join(A); Equate(A, B);

• ByNameOverride(A, B); MatchByName(A); Replace(A); Equate(A, B);


. . - 49 -

Règles de composition pour l’exemple

ByNameMerge(appli, <personnel, paiement>);Fusion implicite des attributs/opérations de même nom (id, ville, accesseurs, …)

Equate(variable appli.employee.employee_name, <personnel.employee.empname, paiement.employee.employee_name>);Force la fusion de 2 attributs/opérations de noms différents (nom de l’employé)

Correspond(operation appli.print, <paiement.print, personnel.output>, <paiement.print>); Force la fusion de 2 opérations de noms différents ( Equate)

Override(realizationset appli.employee_list.insert, <personnel.employee_list.insert, paiement.employee_list.insert>);Quand les implémentations sont différentes : choisi l’implémentation la plus appropriée ([paiement]insert est + complète)


. . - 50 -

Conclusion


. . - 51 -

SOP vs AOP

•Composition• les sujets se composent pour donner un nouveau

sujet

• les aspects ne se composent qu’à travers une application

•Utilisation• les sujets sont des points de vue sur l’application

pour séparer différentes préoccupations « métier »

• les aspects sont orthogonaux à l’applicationpour séparer différentes préoccupations techniques


. . - 52 -

Défis à relever

Une gestion uniforme des préoccupations

Une gestion de la composition des préoccupations


. . - 53 -

Vers une séparation des préoccupations à la conception

Objects,Classes,

Smalltalk, C++,...

Procedures,Pascal,

C,...

1980 1995 2000

Technologie “modèle”

MDA

Transformationde modèles

Raffinement Compositionpar assemblage

Encapsulation etspécialisation

Technologie“procedurale”

Technologie “composant”

Technologie“objet”

Composants,Interfaces in et out,

containers,EJB, CCM

…

Guerre des intergiciels

séparation des préoccupations.. module modèles, objets et composants

Documents