Skip to content

JAVA comme outil de modélisation

February 20, 2010

Dans un projet informatique, la modélisation présente souvent une part importante et prépondérante situé au moment de définir le projet et  son contenu. C’est particulièrement vrai dans un cycle en V. JAVA ne pourrait-il pas remplir la fonction de modélisation et surpasser les outils comme Merise ou UML?

Mélanger la conception et le développement semble être une aberration complète puisque dans la plupart des cas on sépare la phase de conception de celle de réalisation. Cependant, à y regarder de plus près, je ne suis plus si sûr de l’utilité de cette séparation.

Tout d’abord, avouons une chose: le langage JAVA a beaucoup évolué. Le vieux J2EE de grand-papa avec ses EBJ s’est transformé en une plateforme pas forcément légère mais, en tous cas, facile à manipuler. Avec l’apparition des annotations, les vieux fichiers XML de configuration (bien trop éloignés du code source auquel ils se rattachaient) ont disparus. Tout est devenu limpide.

Du coup, un projet JAVA devient très lisible: le code est épuré. De plus, il y a bien séparation (dans des packages différents) des différentes classes spécialisées: d’une part les entités qui représente la base de données, de l’autre les DAO (Data Access Objects) et enfin les objets métiers les Services.

Et bien voilà, on a une belle vision conceptuelle rien qu’en jetant un coup d’œil au code:

  • 1 entité = 1 table. On peut représenter le modèle conceptuel.
  • 1 process = 1 méthode du Service. On représente les processus de l’application.
  • Le reste du code, c’est la présentation. C’est la partie encore mal modélisée où l’on va retrouver les écrans.

Vous allez vous moquer de moi en disant: « c’est bien gentil tout ça, mais où est la documentation? Les spécifications? Le planning? La vision de l’architecture technique? ». Lisez donc la suite…

La documentation

C’est la partie la plus importante d’un projet avec le revers de la médaille. Avoir une bonne documentation facile d’accès, régulièrement mise à jour (ô douces utopies…) et pas trop indigeste.

Le cahier des charges

Il y a bien sûr l’expression des besoins et le cahier des charges. Ces documents devraient rester au niveau de la MOA (maîtrise d’ouvrage) dans des fichiers de traitement de texte. Effectivement, ce n’est pas le rôle de JAVA d’intervenir dans cette définition. On remarquera d’ailleurs qu’il n’y a pas vraiment d’outils bien définis pour cette expression qui se veut très large.

Le cahier des charges,  c’est finalement le synopsis du projet. Il va surtout permettre de définir l’ampleur du projet.

Les spécifications fonctionnelles

Les spécifications fonctionnelles expriment le détail de ce que doit faire le programme informatique. Souvent, il s’agit là encore de fichiers textes agrémentés de graphiques. Souvent rédigés par les utilisateurs en collaboration avec des rédacteurs spécialisés (la maîtrise d’ouvrage, les business analysts dans le monde de la finance).

Là encore, chaque processus sera traduit en JAVA par une méthode contenu dans un Service. Le service est simplement une interface JAVA qui détermine ce que devra faire le code (qui sera implémenté plus tard dans un ServiceImpl). Ainsi, il suffit de recopier le paragraphe contenant les spécifications dans un commentaire JAVA pour conserver de manière centralisée la définition du processus à réaliser. Ainsi, on pourra déterminer les données en entrée et en sortie nécessaires qui seront les paramètres de la méthode JAVA déclarée juste après.

public interface UserService {
  /**
   * Création d'un nouveau compte. L'administrateur
   * doit pouvoir créer de nouveaux utilisateurs pouvant
   * accéder à l'application.
   * L'administrateur spécifie différentes données afin
   * de créer le compte:
   * <ul>
   *   <li>le nom complet de l'utilisateur</li>
   *   <li>son login</li>
   *   <li>son mot de passe</li>
   * </ul>
   *
   * @param name le nom complet de l'utilisateur.
   * @param login <i>login</i> de l'utilisateur
   * @param password mot de passe (ne peut pas
   *    être <code>null</code>
   * @return le compte utilisateur créé ou
   *    <code>null</code> en cas d'erreur.
   */
  public User createNewUserAccount( User request, String name, String login, String password );
}

Il n’y a rien de choquant à trouver dans la déclaration d’une interface de Service 99,9% de commentaires et 0,1% de déclaration JAVA. Au contraire, c’est certainement le bon ratio.

Le grand intérêt est de conserver les spécifications au niveau du code JAVA.

Les spécifications techniques

En fait, si les spécifications fonctionnelles sont claires, il n’est nul besoin de spécifications techniques. Généralement, le programmeur est capable de prendre en charge directement le développement. Je considererais bien ce cas (mon préféré). Cependant, si une spécification technique est nécessaire, elle s’exprime encore assez fréquemment dans un mode « traitement de texte » bien que les schémas UML soient mieux adaptés (mais personnellement, j’en ai rarement rencontré dans la « vraie » vie). On pourra toujours écrire des balise <img …/> pour intégrer des explications graphiques.

De toute façon, les commentaires concernant l’implémentation viendront directement dans le code d’implémentation ServiceImpl.

Pour le dictionnaire de données, il suffit de bien commenter toutes les entités créées (chaque entité correspond à une table dans la base de données). Il faut non seulement commenter la classe mais également chacune des méthodes (tout au moins les getters!).

Tout d’abord, les commentaires JAVA sont d’un usage remarquablement facile. Vous pouvez documenter votre dictionnaire de données facilement en expliquant chacune des propriétés de votre entité.

Je vous encourage à utiliser la documentation au format HTML pour lister les valeurs possibles (balises <ul> et <li>), et les annotations @Column pour notifier la longueur des champs ou le fait que la colonne est déclarée NOT NULL dans la base de données.

Par ailleurs, les tags de la documentation JAVA sont géniaux:

  • @since: afin de spécifier à partir de quelle version est apparue cette propriété. Il est très intéressant de donner également une référence vers le document qui exprime le besoin utilisateur.
  • @author: afin de spécifier qui a créé cette propriété (par forcément le programmeur mais qui de la MOA a spécifié cette nouvelle donnée).
  • @deprecated: pour signaler que cette donnée ne devrait plus être manipulée mais a été conservée (pour compatibilité ascendante par exemple).
  • @see: pour faire référence à d’autres entités ou méthode ou même une documentation fonctionnelle.

Ainsi, avec JAVADOC (le générateur de documentation), vous obtenez une API non seulement détaillée mais un site WEB dans lequel vous retrouvez directement toute l’information de conception: les processus définis dans les spécifications fonctionnelles ainsi que le dictionnaire des données (attachées aux entités).

Le planning

Voici bien un point difficile à gérer en JAVA. Effectivement, la gestion du planning revient au chef de projet. Et JAVA ne sera sans doute d’aucune aide. À moins de considérer l’avancement par rapports aux processus. On a vu que dans les architectures modernes, on définissait des Services, et que, à l’intérieur de chacun d’eux on déclarait des méthodes. Une fois les spécifications fonctionnelles terminées, on connait le nombre de méthodes.

Le planning consiste à savoir combien de méthodes ont été implémentées. Le ratio du nombre de méthodes implémentées sur le nombre total donne le pourcentage d’avancement. Je ne suis pas certain de la précision de cette technique mais le but de l’exercice, c’est bien de supprimer ce qui n’est pas JAVA?

L’architecture technique

JAVA standardise de plus en plus les architectures techniques. Généralement, toutes les applications (y compris celles utisant des clients lourds plutôt qu’un serveur WEB) utilisent un mapping O/R (Objet/Relationnel) qui nécessite la déclaration de chaque colonne et de chaque table de la base de données en classes de type entité.

Les processus sont centralisés au niveau des Service. Cela permet d’implémenter le processus métier sans se préoccuper de l’interface cliente (WebService, client SWING, Web, etc.).

Conclusion

Je ne suis pas sûr de vous avoir totalement convaincu. Mais pour des projets relativement légers, forcer le développeur à créer la documentation au fur et à mesure de son développement est souvent plus judicieux que de le forcer à créer une documentation en dehors de son outil de développement.

L’un des avantages de cette technique est également de pouvoir accéder très simplement à la documentation pendant la programmation des fonctionnalités puisque la documentation s’ouvre automatiquement dans la plupart des IDE.

Advertisements

From → Other

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: