Unified Modeling Language

J'écris mes modèles en notation UML. Je décris surtout l'organisation générale en modules et les interfaces entre les modules. Pour le reste je préfère commenter abondamment le code, et utiliser les générateurs de documentation et les browsers de classes.

En 1993, j'ai été très heureux de pouvoir utiliser la méthode OMT pour décrire l'architecture de mes applications.

UML en est le digne descendant et j'en suis très satisfait.

Cependant, il ne faut pas croire qu'il s'agisse d'un langage de développement et tomber dans la modélisation pour la modélisation.

J'ai participé à un gros projet utilisant l'environnement intégré Rational Rose pendant 18 mois, avec ses possibilités de génération de code. Cela rendait les équipes assez improductives. Contrairement aux promesses des vendeurs du produit, le Reverse Engineering marchait fort mal, l'outil ne comprenait pas la STL, etc ...

Pour l'instant je préfère encore dessiner mes modèles avec SmartDraw et utiliser les environnements de développement traditionnels.

Modélisation

Le but d'une application est de satisfaire un besoin. La modélisation est nécessaire pour y arriver.

Un modèle est une simplification de la réalité. Nous construisons des modèles pour que nous puissions comprendre le système que nous développons. Nous construisons des modèles parce qu'il est impossible de comprendre un système complexe d'un bloc.

Il ne viendrait à l'idée de personne de construire un immeuble ou une machine sans plans. Par contre, parce que le logiciel n'est matérialisable, et parce que sa modélisation est très difficile, de nombreuses applications sont développées en l'absence de modèles.

Lorsque le modèle existe, il arrive que le développement ne le suive pas parce que:

  • La méthode utilisée est trop lourde.
  • Le modèle a été trop affiné au début, et n'est pas valide (ne correspond pas à la réalité)
  • On a séparé les concepteurs et les développeurs.
  • Les techniques de programmation utilisées ne correspondent pas au modèle.

Un modèle satisfaisant:

  • Est simple. La qualité d'un modèle ne se juge pas à son volume.
  • Doit être critiqué et amélioré constamment.
  • Sert de support de dialogue entre les développeurs.
  • Permet d'obtenir des réactions des clients avant que l'application ne soit en fonctionnement.

Quelques fragments de modèles pour faire joli, mais je sais bien qu'ils prouvent seulement que je connais le jargon et que je sais dessiner.


images/model_statediagram.gif

Diagramme d'état d'un relais radio.


images/Model_Journal.jpg

Classes constituant le Journal.

Rôle:

  • Le Logger utilise une collection JData d'Events.
  • Le TimeStamper permet de dater les Events.
  • Le Formatter permet d'adapter la présentation.

images/java_CadreAppli.jpg

Le rôle des différents composants Swings d'une application Java.


images/java_graphicsobjectDiagram.jpg

Application Java Graphique avec des composants Swing.

Les JButton signalent qu'ils sont cliqués par l'intermédiaire d'instances de classes anonymes.