Archive for the ‘Modélisation’ Category

Violet UML Editor, un éditeur de diagramme UML

mai 5, 2008

Violet UML Editor est un outil simple pour écrire rapidement des diagrammes UML. Son ambition est bien moins importante que les outils de modélisation UML comme BOUML ou ArgoUML. Il s’agit d’un outil libre, sous licence GPL. Le site web est http://alexdp.free.fr/violetumleditor. La dernière version est la 0.21.1 datant de l’été 2007.

Un point assez agaçant pour est que cet outil fonctionne sous Java 6. Je travaillais en Java 5. J’ai du passer à cette version du langage Java, et configurer quelques variables d’environnement sur mon poste pour évaluer cet outil. L’utilisation est assez simple. Il suffit d’utiliser la commande java -jar com.horstmann.violet-0.21.1.jar ou double cliquer sur l’archive. Il s’agit alors d’une application graphique Java autonome.

Il existe une version pour l’EDI Eclipse : Violet UML Editor Plugin for Eclipse. En fait, il suffit de mettre le jar utilisé pour l’application autonome dans le répertoire plugins d’Eclipse. Le fonctionnement similaire à l’application Java autonome est tout à fait correct .

Un avantage de cet outil est sa simplicité. Il démarre rapidement. Il est très facile à prendre en main. Son interface graphique est soignée. Il est facile à comprendre qu’avec un outil aussi simple, il est difficile d’aller très loin. En effet, il permet de dessiner les diagrammes UML, mais il n’existe pas de projet UML et d’existence des éléments en dehors des graphiques. Il n’est pas possible de générer du code ou de faire une démarche MDA avec un tel outil.

Cet outil est libre, il est donc possible de recompiler les sources. Les différentes versions sur le site de sourcefourge comportent à la fois l’archive jar et le code source. Il est également possible d’utiliser le code source présent sur dépôt CVS. Le projet utilise en effet ce gestionnaire de versions. La commande suivante permet de récupérer le code source.

cvs -z3 -d:pserver:anonymous@violet.cvs.sourceforge.net:/cvsroot/violet co -P Violet

La compilation du projet n’a pas posé de problème particulier. J’ai utilisé la tache ant (build.xml) trouvé dans le code source. Dans ce fichier, j’ai du corrigé le répertoire eclipsedir (en fait le répertoire plugin d’Eclipse). Pour que la tâche ant fonctionne correctement, il faut mettre dans la variable d’environnement JAVA_HOME, le répertoire du jdk version 6. Notons l’absence de test unitaire. Cependant comme il s’agit d’un outil purement graphique, écrire des tests unitaires n’est pas forcement une tâche évidente. Surprise, en regardant le fichier build.xml, il est possible de recompiler le projet pour la version 5 du langage Java !

<javac srcdir= »${srcdir} » destdir= »${builddir} » deprecation= »true » debug= »true » source= »1.5″ target= »1.5″>

Voici deux images, la première représente Violet UML en application autonome et la seconde l’apparition de Violet UML dans les menus d’Eclipse.

L’antipattern « Anemic Domain Model »

avril 7, 2008

Un « antipattern », par opposition au « pattern » est une mauvaise pratique métier. Dans le cas présent, il s’agit d’une mauvaise pratique de modélisation où le modèle métier (Domain Model) ne contient pas de méthodes métier. Il est décrit sur le site de Martin Fowler.

Les classes métier ne contiennent que des attributs et les méthodes « accesseurs » ou getters et setters associées aux attributs. La logique métier se trouve alors dans la « couche service » et les objets métier ne servent que de stockage de données. Cet antipattern est selon Martin Fowler très courant dans le monde J2EE.

Les points négatifs de cet antipattern sont nombreux. En premier, il s’agit d’une approche anti-objet, un objet contient à la fois des données et des traitements, ici il ne reste que les données. Le second point noir Une difficulté de maintenance des règles métier. Enfin cette approche ne permet pas une réutilisation des objets métiers.

Les réseaux de Petri

décembre 29, 2007

Le réseau de Petri est un outil de modélisation mathématique. Il a été introduit en 1962 dans la thèse de Carl Adam Petri. On le rencontre en informatique notamment dans les méthodes formelles et dans la modélisation des workflows.

Un réseau Petri est composé de deux types de noeuds : les places (notées S) et les transitions (notées T). Des arcs orientés (F) relient les places et les transitions. Il n’est pas possible de relier directement des places entre elles, même chose pour les transitions. C’est pourquoi on parle de graphe bipartite orienté.

En plus de S T et F, il faut ajouter trois autres éléments Mo, W et K à la définition du réseau de Petri. Mo est le marquage initial, le nombre de jetons dans les places. W est la consommation ou la production de jetons par un arc, consommation si l’arc va d’une place vers une transition et production dans le cas contraire. Attention au cours de l’évolution rien ne garantit que le nombre de jetons reste constant. Enfin K est la limite de capacité des places.

Même s’il est possible d’avoir une représentation graphique, le réseau de Petri est très formel. Le réseau est un 6 uplet (S,T,F,Mo,W,K). M est une fonction de S vers l’ensemble des entiers, W de F vers l’ensemble des entiers non nuls et K de S vers l’ensemble des entiers non nuls. Si à première vue tout cela peut paraître complexe, ce formalisme est très simple par rapport aux formalismes de modélisation des processus dans les outils de workflows.

Une simplification du modèle des réseaux de Petri aboutit aux automates finis. Une autre simplification est de ne tenir compte que des 4 premiers paramètre (S,T,F,Mo).

Je me place plus en tant qu’informaticien ou du moins utilisateur des mathématiques, je préfère donc la version graphique. J’ai trouvé une applet qui permet de construire et de simuler l’évolution des réseaux de Petri. Dans cette applet les transitions sont représentées par des carrés, souvent le formalisme est d’utiliser un trait.

L’exemple suivant est fait avec cette applet. J’appuie sur les transitions t1, t1, t2 et t2 pour obtenir ces résultats successifs.

Exemple d’utilisation de l’applet

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

BOUML le modeleur UML

décembre 2, 2006

BOUML est un modeleur UML2 distribué sous licence GPL. Pendant longtemps, le manque d’outils accessibles à des prix raisonnables a limité la possibilité de faire sérieusement de la modélisation UML. Maintenant, plusieurs projets libres sérieux commencent à changer cette situation. Un autre projet libre est ArgoUML, plus ancien. Je l’ai longtemps utilisé mais je pense passer à BOUML. En effet ce dernier est écrit en C++, on sent la différence avec ArgoUML écrit en java. Une partie de la documentation de BOMUL existe en français, actuellement il existe trois tutoriels, cependant le manuel de référence reste en anglais. Enfin. Le projet avance régulièrement et la dernière version est la 2.19.4 qui date du 28/11/2006. il s’agit donc d’un outil à tester.
bouml.PNG