Archive for novembre 2007

Les différents diagrammes UML

novembre 4, 2007

UML est un langage de modélisation semi-graphique issu des travaux de l’OMG (Object Management Group).

UML a évolué a fil du temps. En mars 2005 est sorti la version 2.0. L’OMG désire avec cette nouvelle majeure relever le défit du MDA. La dernière version est la 2.1.1 de février 2007. Notons que la version 1.4.2 d’UML est devenu une norme ISO sous le sigle ISO/IEC 19501:2005. Remarquez le prix 328 francs suisse pour une spécification qui n’est même pas de l’ISO initialement.

UML2 comporte 13 types de diagrammes, c’est trois de plus que UML1. Le diagramme de collaboration (UML1) est devenu le diagramme de comportement (UML2). Sur ces 13 types de diagrammes, 6 sont considéré comme structurels et 7 comportementaux. Le diagramme suivant de classification sur trouve dans la norme UML de l’OMG.

diagrammes UML

Le modèle de conception DTO

novembre 1, 2007

Suite à un projet récent, je me suis intéressé au modèle de conception (design pattern) DTO (Data Transfert object) ou parfois connu sous le nom de Value object. Je n’ai pas trouvé de transposition de ce terme en français, appelons objet de transfert.

Ce modèle de conception est exposé sur le site de Martin Fowler. Il est à l’origine de ce pattern. En fait il s’agit d’exposer au niveau de la couche de présentation des objets simples qualifié dans le jargon java de POJO (Plain old java object) ce qui signifie objet simple. En effet souvent au niveau de la couche métier, les objets sont complètement noyé par des contraintes techniques. Prenons l’exemple des EJB2, les objets métiers deviennent 4 objets qui doivent implémenter certaines interfaces (bref c’est l’horreur). Sur le site de Sun blueprints, on peut trouver une explication complète. Dans la pratique ce pattern est assez lourd, rend le modèle objet complexe et augmente le travail du développeur. Mais au final, la couche présentation peut être propre.

Cependant, le monde des frameworks Java semble maintenant aller vers des conceptions non intrusives. C’est à dire qu’un objet métier reste un seul objet simple non pollué par des contraintes techniques (exemple EJB3 ou Spring). Donc dans ce cas, il est possible d’exposer au niveau de la présentation ces objets et le pattern DTO est inutile.

Martin Flower répond aux critiques concernant ce pattern, sa loudeur. Ce modèle n’est pas mauvais en soi, il simplement parfois utile et dans d’autres cas inutiles. Un exemple d’utilisation est lorsque le modèle objet et le modèle au niveau de la présentation sont différents.