Epoux et amants

19 décembre 2007

J’ai beaucoup apprécié la réflexion de Xavier Blanc au MDDay expliquant que quand il demandait à ses étudiants de lui implémenter ça en java :

Epoux
On lui écrivait ça :

public class H {
  public F f;
}
public class F {
  public H h;
}

Ce qui s’apparente plutôt à l’implémentation de ça :

Amants


Ca pose évidemment le problème de l’expressivité de Java, qui reste assez loin sur certains aspects (la notion d’association par exemple) de celle d’UML. Les conséquences ne sont pas que philosophiques : derrière cette boutade, il y a tout le probléme d’interprétation de l’analyse fonctionnelle en conception technique (il y a un dessin qui circule depuis longtemps sur « ce que le client a demandé, ce que la MOA a compris, ce que le développeur a réalisé, ce dont l’utilisateur avait besoin » avec une balançoire qui se termine par un pneu accroché par une corde : ça parle de la même chose !).

Comment ne pas perdre (trop) d’information lorsqu’on implémente un modèle ? Une des solutions serait de donner au langage cible le même niveau d’expressivité qu’UML.

Xavier disait par provocation que lui, ne savait pas implémenter effectivement son modèle UML en java. Bien évidemment, il exagérait ;-) Si on accepte d’implémenter des beans et non plus de simples classes java, on doit pouvoir y arriver.

Je me suis amusé à faire une tentative. Et, pour un modèle aussi simple, ça fait tout de même beaucoup de code !

public class H {
  private F f;

  public void setF(F f) {
    if (this.f != f) {
      if (this.f != null) {
        this.f.setH(null);
      }
      this.f = f;
      if (f != null) {
        f.setH(this);
      }
    }
  }

  public F getF() {
    return f;
  }
}
public class F {
  private H h;

  public void setH(H h) {
    if (this.h != h) {
      if (this.h != null) {
        this.h.setF(null);
      }
      this.h = h;
      if (h != null) {
        h.setF(this);
      }
    }
  }

  public H getH() {
    return h;
  }
}

C’est évidemment le cas le plus simple : dès que les relations sont multi-valuées (et donc qu’on à affaire à des collections en Java), ça se gâte sérieusement. Suivant les contraintes (ordered, set) et les cardinalités des inverses, il y a un paquets de combinaisons différentes et de templates de codes associés.

En attendant que java (ou C#) supporte la notion d’association (!) tous ces cas doivent être « templatés » si on veut produire un code dont la sémantique soit la même que celui d’UML (ce qui est généralement le cas d’un modèle de domaine à partir duquel on produit des entités).

J’essaierai de développer certains cas dans un prochain post.

6 Responses to “Epoux et amants”

  1. alagNo Gravatar Says:

    Avec qq anotations bien senties et un framework pas trop lourd on peut faire des miracles.
    Mais je suis d’accord, on prefererait se passer de « miracle ».

  2. GregNo Gravatar Says:

    Des annotations « frameworkisées » doivent pouvoir faire l’affaire. Le problème c’est… qu’elles n’existent pas aujourd’hui sur étagère !
    Un beau boulot pour un stagiaire pas trop manche. Avis aux amateurs…

  3. alagNo Gravatar Says:

    Pourquoi un stagiaire ? Au contraire, c’est l’occasion de lancer une belle initiative (si elle n’existe pas) avec qq compétences bien senties.

  4. GregNo Gravatar Says:

    Sous quelle forme ? Un projet Open Source ?

  5. MD Blog » Blog Archive » Epoux et amants (2) Says:

    […] post fait suite au premier du même nom qui s’intéressait à l’implémentation de relation UML en java. On avait vu […]

  6. mabroukNo Gravatar Says:

    et pourquoi ne pas représenter la relation elle-même plutôt que de rester dans une modélisation objet trop scolaire ?

    quelque chose de la forme :

    public class Couple {
    private Personne h;
    private Personne f;

    public Personne getH() {
    return h;
    }

    public Personne getF() {
    return f;
    }

    public Couple(Personne h, Personne f) {
    super();
    this.h = h;
    this.f = f;
    h.setCouple(this);
    f.setCouple(this);
    }
    }

    public class Personne {
    private Couple couple;

    public Personne getH() {
    return couple.getH();
    }

    public Personne getF() {
    return couple.getF();
    }

    public void setCouple(Couple couple) {
    this.couple = couple;
    }

    public Couple getCouple() {
    return couple;
    }
    }

    cela me parait être plus proche de ce que l’on voulait représenter dans le modèle uml, non ?

Leave a Reply

buy sale viagra
buy viagra online price
buy discount levitra
buy sale viagra
viagra 100 mg
buy cheap cialis
buy viagra
cheapest levitra
buy viagra online
buy viagra usa
buy viagra online
buy now viagra
buy price viagra
buy now levitra
buy discount viagra
cheap viagra online
buy viagra fedex
buy viagra overnight
buy viagra las vegas
generic viagra
cheap price viagra
Pfizer viagra free samples
generic cialis
cialis black reviews
buy cheap cialis
free madonna ringtones
cheapest cialis
buy now viagra online