Pomme Courge Mobylette

Soit un projet java 1.4 de 160 KLOC. Mission du jour, le faire basculer sur java 5 et avoir des listes fortement typées, des List<Truc> au lieu de List.

Durée de modification manuelle de code : 2 heures.

J'ai simplement modifié mes templates de génération. Pour chaque élément de modèle, j'ai une description (dans un langage type JSP) de comment il doit se générer, à quoi cela doit ressembler. Ils me servent à générer les signatures de méthode, mais aussi leur contenu, dont une description haut niveau est contenu dans le modèle.

Durée totale de régénération du projet : 12 heures .... Bon, c'est peut être optimisable. Dans le même temps, ça faisait des mois que j'avais pas lancé ça, je vais pas y passer des heures sur un truc rarement lancé.

J'ai déjà expliqué la brique de base de l'extension UML : le stéréotype. Mais il y a une notion plus générale dans les extensions UML : le profil, ou "UML profile" en anglais.

Un profil est un regroupement d'extensions UML destinée à un domaine particulier, que ce soit technique ou business. Ce profile contiendra des stéréotypes ajoutant de la sémantiques (et des données) aux éléments UML, mais aussi (suivant l'outils), des éléments UML dédiés à cette modélisation, comme des types de base.

Pour que ce soit plus clair, je vais prendre l'exemple des EJB. Dans les EJB, il y a des métadonnées rajoutées aux classes sous forme d'annotations java. Lorsque l'on a un EJB entity (donc avec persistance), il va falloir exprimer des choses sur ses relation. La relation "Many-to-Many" est-elle inversé (méta-attribut de type booléen), quel est le type de cascade lors de liens entre objets (méta-attribut de type énuméré). Pour exprimer ça en UML, cela donne la création d'un stéréotype <<ManyToMany>>, et sur ce stéréotype deux attributs que sont inverse et cascade. Pour typer cascade, il y aura en plus un énuméré CascadeType ayant pour littéraux ALL, PERSIST, MERGE, REMOVE et REFRESH.

Maintenant, les outils UML n'offrent pas tous la même finesse de définition de profils. Pour certains, on ne peux que rajouter des stéréotypes sous formes de champs textes, mais à l'autre bout, comme prévu dans la norme UML d'ailleurs, un profil est un package, et peut donc techniquement apporter tout ce qu'un package peut contenir.

UML est un langage permettant de modéliser des systèmes d'information. La version standard est très passe partout, et permet déjà une modélisation poussée. Mais il y a des cas où on se retrouve avec des besoins spécifiques dans la modélisation. Que ce soit pour des raisons techniques ou méthodologiques

Technique, parce que certains éléments UML vont avoir une particularité du point de vue de leur utilisation. Ce la peut être via un framework par exemple : une classe sera implémentée par un EJB, une autre sera supportée par le mécanisme de sérialisation.

Méthodologique, parce qu'un élément peut avoir un rôle particulier du point de vu de la méthodologie utilisée pour la conception. Dans le cadre d'une méthode SOA, cela peut être la mise en avant d'un service par rapport au reste de l'application.

Pour ces besoins spécifiques, UML a introduit un concept appelé le stéréotype. Il permet, rajouté à un élément, de sous-classer celui ci pour le spécialiser, comme on dériverais une classe existante. Voici un exemple avec l'artifact. L'artifact est un élément UML représentant un élément externe, souvent un fichier. Sauf qu'ici, on veut le caractériser plus finement comme étant un fichier jar, et en plus ayant une classe principale. Pour cela, je crée un stéréotype, et l'applique sur mon élement artifact qui représente mon fichier jar. Le stéréotype apporte en plus une information complémentaire (l'attribut main-class), spécifique a ce nouteau type.

On voit sur ce schéma la notation d'un steréotype. Comme un keyword, il s'agit du nom du stereotype encadré de "<<" et de ">>".

A retenir: le stéréotype est la brique d'extension de base d'UML, pour spécialiser un élément UML vers quelque chose de plus fin.

ma gallery d'images personnelle commençait à se faire vieille. Manque de fonctionnalités flagrante (principalement pas de captcha anti-bots qui commençait à me pourrir certains commentaires), look un poil vieillot. Il était temps de bouger. Par chance, ma debian fourni le choix entre gallery1 et gallery2. En ce matin de jour férié, je me suis lancé. apt-get install gallery2.

Pour commencé, j'ai installé gallery2 en parallèle du 1. Afin de la configurer a vide déjà. Le wizard de configuration se lance pour la configuration de base, et à la fin, j'avais une gallery en état de marche. Je me logge en administrateur, et là, tout en bas, un petit bouton : "importer depuis gallery V1". Je fais, je lance sélectionne le tout, et après un bon quart d'heure, j'ai récupéré mes albums, avec les commentaires, et toutes mes photos à jours.

A partir de là, ce n'est plus que de la configuration simple. choix d'un thème, réinsertion de mes pubs dans les pages (le système de template est super clair au passage). Juste un truc à penser dans les redirections pour garder les anciennes urls.

Ayé, j'ai une nouvelle gallery toute propre et toute belle :)

Comme je l'ai déjà expliqué, UML n'est pas une méthode, mais un langage permettant d'exprimer des systèmes. Nulle part, c'est expliqué comment faire avec UML comment faire pour construire un système. Comparaison gratuite : un tournevis permet de monter l'armoire ikea, mais ne diras pas comment le faire. C'est pour cela qu'il y a des processus de développements qui utilisent UML comme notation.

Le RUP (Rational Unified Process) est le plus connu de ces processus. Sorti chez rational à l'époque, il est maintenant dans le giron d'IBM. Il s'agit d'un processus de développement destiné au développement logiciel, qui, par certains cotés, est proche des méthodes agiles, à savoir que l'on se concentre sur ce qui est d'un intérêt direct pour le client et qu'il s'agit d'un processus itératif, et surtout guidé par les risques.

Dans le RUP, le développement logiciel se divise en 4 phases

L'inception est une phase de vérification du projet. On doit comprendre le système à construire, identifier les risques (techniques ou non) et en déduire les coûts et les méthodes de développement précis à appliquer. A la fin de cette phase, on sait ce que l'on va faire, et quels sont les outils que l'on va utiliser. On sait également quels sont les risques, risques que l'on tacheras d'éliminer dès que possible.

L'élaboration. Seconde phase, raffinant la première, allant plus loin dans les détails. Cette phase aboutiera à la conpréhension fine des exigences, à la suppression des risques en concevant et en implémentant l'architecture de référence. C'est une phase où une première version du soft gros grain, ou l'élaboration d'un prototype vont permettre d'investiguer sur les risques techniques pour les réduire.

La construction. C'est la phase d'implémentation proprement dite. C'est ici que l'on développeras toutes les fonctionnalités du projet, en utilisant un certains nombre d'itérations fonctionnelles, le logiciel devenant de plus en plus riche fonctionnellement au fur et à mesure des versions.

La transition. On prépare le logiciel à sortir. Ce n'est pas parce qu'il est écrit que tout s'arrête. Il faut encore préparer la documentation, former les utilisateurs, préparer les outils marketings au besoin. Cette phase permet également de préparer les prochaines évolutions liées à la maintenance du logiciel. La phase de transition dure donc toute la vie du logiciel une fois celui-ci réalisé.

Pour en savoir plus sur le RUP, je conseilles le livre "guide pratique du RUP", par Per Kroll et Philippe Kruchten. Ecrit par les auteurs du RUP, ce livre montre son application dans des applications d'exemple. Simple à lire, très didactique, une vraie réussite... mais introuvable. Et non, je ne vend pas le mien.

Il y a un outil que j'ai jamais utilisé pendant mes études d'informatique. Et a priori, vu le nombre de personnes que je vois débuguer au print dans les forums, je suis très loin d'être le seul. C'est un manque courant. On voit les gens rajouter des quantités de traces monstrueuses et les éplucher pour retrouver d'où viens leur problème.

Et le nombre de traces peut être assez impressionnantes. Sans compter que certains bugs peuvent être influencés par des traces (on a tous vu des printf planter un programmes pour cause de mémoire corrompue plus avant).

D'où cet article sur comment utiliser un debugger, pour mieux comprendre ce qui se passe. Je montre avec Eclipse sur un programme java, mais le principe est le même pour tous les langages, seul l'outil change.

Lire la suite

Eclipse, la plate forme logicielle d'IBM est sortie en version 3.3. Bien que se présentant pas défaut sous la forme d'un IDE java, cet outil est un outil beaucoup plus complet, permettant le développement d'application clientes d'entreprises, notamment grâce à ses nombreux framework ouverts, comme RCP pour la structure applicative, EMF pour la gestion des modèles de donnée, GEF/GMF pour les affichage de données graphiques.

Lire la suite

source : http://xkcd.com/

Toute personne travaillant autour d'eclipse a déjà entendu parlé d'EMF, au moins par sa fréquence de mise à jour. Mais quel est donc cet EMF (pour Eclipse Modeling Framework), à quoi cela sert-il, et qui a besoin de l'utiliser ?

Lire la suite

Une question d'axel aujourd'hui, qui me demande Quelle est la différence entre un métamodèle et un profil UML ? Ce blog est interractif, allons-y

Un metamodèle est un modèle qui va permettre d'exprimer des modèles. Le métamodèle UML permet d'exprimer un modèle UML, il va vous dire qu'une classe peut contenir une opération, qu'un héritage à forcément deux cotés, ou qu'un instance instancie un seul objet. Mais on peut faire un métamodèle pour de nombreux systèmes (métamodèle des processus, métamodèles de langages), ce n'est pas spécifiquement lié à UML.

Un profil par contre, est une notion UML. Le profil est le mécanisme standard d'extension à UML. Il exprime des notions permettant d'adapter UML à un domaine particulier.

• Stereotype : Va permettre d'étendre une métaclasse UML pour en affiner le concept. Un composant pourra devenir un <<EJB>>
• Tagged value : Va rajouter une information complémentaire à une metaclasse, généralement liée à un stereotype. Par exemple pour mon <<EJB>> une tagged value pourra exprimer son nom JNDI

Il existe tout un ensembles de profils existant, pour la modélisation EJB, pour la modélisation de processus ou d'applications web.

Et le rapport entre les deux ? Un métamodèle peut se mapper sur un profil pour étendre UML. On peut créer un métramodèle EJB, permettant de décrire une application utilisant les EJB, puis les concepts de ce métamodèle seront converti en Stereotypes et Tagged Values.

A noter que je pense que tout métamodèle ne peux s'exprimer sous la forme d'un profil. Comme la base, et notamment les relations entre objets sont figées par les relations UML existantes, si le metamodèle dérive trop par rapport à UML, on se retrouve a devoir réutiliser des associations UML pour des concepts totalements différents de ceux pour laquelle elles ont été prévues. D'autres outils peuvent êtres plus efficaces dans ce genre de cas, que ce soit des outils MOF ou une implémentation EMF.

Revenons un peu à not' java. On a vu que le framework de collections était composé d'un ensemble d'interfaces et d'implémentations. Ces implémentations sont des implémentations générales, toutes les implémentations du framework de collection sont en lecture/écriture et non synchronisées. Il y a bien le cas de Vector, mais elle est là depuis java 1.0, et je rappelle que le framework est apparu avec java 2.

Donc, il y a un réel besoin de décorer les collections pour les syncrhoniser, ou les mettre en read only. Ou une autre décoration, peut importe, le principe est le même. Et cela se fait par l'utilisation d'un pattern décorateur. Le rôle de ce pattern est de rajouter de manière transparente pour l'utilisateur des capacités (ou en supprimer) à un objet.

Pour utiliser ce principe, il y a une classe très pratique : java.util.Collections. Les méthodes statiques de cette classe permettent de réaliser une décoration de collection simplement. Par exemple, si je veux une liste synchronisée, je vais pouvoir utiliser :

List synchronized list = Collections.synchronizedList (new ArrayList ());

Bien évidemment, on peut mixer les décorations. Comme pour faire une collection synchronisée et read only :

List synchronized list = Collections.synchronizedList (Collections.unmodifiableList (new ArrayList ()));

Bien évidemment, en cas de besoin, on peut créer ses propres décorations que l'on pourra utiliser en plus. Par exemple, j'en ai déjà implémentée une qui faisait de la vérification de cardinalité sur la collection.

En couche 1, on avait déclaré un élément, maintenant il va falloir l'instancier.

Dans le framework, il y a toute une liste de collections concrètes. Les différences ? Principalement l'organisation interne. Il y a des listes d'éléments, des stockages sous forme d'arbre ou de map. Donc à voir si le but doit être sur l'insertion, la recherche d'un element ou leur suppression.

Le framework de collection est une bibliothèque de types collections apparus dans java 2 il y a fort longtemps. Le but était de repartir des anciens Vector et Hashtable pour avoir tout un ensemble de conteneur dédiés au différents besoin, mais également configurable.

La base, c'est de ne manipuler que les interfaces. Toute déclaration, que ce soit en tant qu'attribut ou paramètre, utilise le concept d'interface pour manipuler les données. On parle de type abstrait, on a donc les classiques List, Map, Queue, Set. Le choix d'une de ces interface dépend de la façon dont on va utiliser les données. Les différences conceptuels sont tels que le choix devient fortement structurant. Doit-on garder les éléments triés ? l'ordre est-il important ? Ce sont ces questions qui vont déclencher le choix d'une interface ou d'une autre.

Le choix de la collection concrète viens ensuite, lorsque l'on doit s'occuper des contraintes techniques

Ah, j'oubliais. Les listes sont génériques maintenant. On peut donc préciser le type des éléments que l'on met dedans. On déclarera une List<Personne> par exemple. Fini de dériver les listes ou de créer des adapters de validation de type.

Le site du collection framework sur le site de sun

C'est, selon pas mal de processus de développement, le premier diagramme que l'on utilise lors du développement d'un système. Son but est d'exprimer, d'une manière simple, le rôle d'un système, ce qu'il doit faire et les éléments qui interagissent avec lui. C'est généralement utilisé en phase de recueil des exigences, par interview des utilisateurs. C'est également un diagramme qui est simple et permet d'avoir des retours de non-informaticiens.

Voici un exemple de diagramme :

La première chose que l'on voit est un ensemble de use case (les patates). Un use case est une fonctionnalité du système modélisé, sur laquelle on pourra plus tard accrocher un scénario plus complexe. Traditionnellement, on les nommera avec des termes "d'action", car le système FAIT quelque chose dans ce cas.

Ensuite, on a des acteurs. Un acteur est un élément externe au système, mais qui interagit avec le système. On pense tout de suite aux utilisateurs en tant que personnes, mais ce n'est pas que ça. Par exemple un capteur mécanique ou un autre système peuvent parfaitement être un acteur. Enfin, signalons qu'il est généralement inutile de faire des liens entre les acteurs, on modélise le système, pas ce qui est autour. Dans l'exemple ci-dessus, inutile de faire hériter modérateur d'utilisateur, ça ne regarde pas mon système.

Enfin dernier cas, ce rectangle qui traine sur le diagramme. C'est ce que l'on appelle le "system boundary", la frontière du système, qui marque les limites du système à modéliser. Il existe également des liens entre les uses cases, destiner à extraire certain sous-ensemble que l'on invoquera lors de plusieurs uses cases. Il y a deux type de liens, <<includes>> qui permet de faire sortir une sous-partie d'un cas d'utilisation (taper son mot de passe est l'exemple bateau), et <<extends>> qui permet de faire de "l'héritage" de use case.

Pour terminez, n'oubliez pas que les dessins sont bien gentils, mais largements insuffisants. Tout cas d'utilisation se doit d'être bien documenté, avec des explication précises, des préconditions (pour poster, un contributeur ne doit pas être banni) et être validé par des cycles de revue.

L'anglais !