ICONIX est une méthodologie de développement hybride qui emprunte plusieurs caractéristiques au Processus Unifié (RUP) et à l’Extreme Programming (XP). A l’instar du RUP, la méthodologie ICONIX est centrée sur les cas d’utilisation. Pareillement, elle utilise UML comme notation pour la production des livrables.

Les livrables à produire dans un projet de développement s’appuyant sur ICONIX sont moins nombreux que ceux du RUP. Cela en fait une méthodologie souple et flexible qui hérite des principaux avantages d’XP.

Dans ICONIX les étapes à parcourir entre le moment où on dispose d’une première définition du besoin de l’utilisateur et le moment où on commence à produire du code exécutable sont réduites au strict nécessaire aussi bien en termes de temps qu’en termes d’efforts.

Des experts comme Ivar Jacobson pensent qu’il est possible de modéliser 80% des problèmes rencontrés avec seulement 20% des éléments de la notation UML. Fondé sur le principe du « minimal yet sufficient », ICONIX n’utilise qu’un sous-ensemble restreint de la notation UML (il faut garder à l’esprit que la modélisation ne doit pas devenir une fin en soi mais plutôt un moyen pour mieux spécifier les besoins des utilisateurs et produire rapidement du code exécutable).

Figure1 : comment passer du point de départ au point d'arrivée en minimisant les délais et les coûts

Dans ICONIX (comme dans RUP), tout le processus de développement est centré sur les cas d’utilisation. Il s’agit d’une excellente démarche pour s’assurer que les livrables des étapes subséquentes reflètent les besoins des utilisateurs.

Pour déterminer les étapes qui permettent de transiter du point de départ vers le point d’arrivée en minimisant les coûts et les délais, les auteurs d’ICONIX proposent un raisonnement déductif en partant du point d’arrivée.

Nous savons, par expérience, que la façon la plus rapide et la moins coûteuse pour produire du code propre est de le générer à partir d’un modèle graphique avec un outil de développement comme Rational Rose. Dans un projet où on utilise un langage de programmation orienté objet avec les éléments de modélisation de la notation UML, la génération de l’ossature du code à partir d’un diagramme de classe est sans conteste la meilleure façon de procéder (Voir figure 2).
 

Figure 2: génération de l'ossature du code à partir d'un diagramme de classe

Une des décisions les plus difficiles à prendre lorsqu’on fait du développement orienté objet est de déterminer à quelle classe du diagramme de classes, il faut associer chacune des fonctionnalités de l’application cible (nous rappelons que dans un langage orienté objet les fonctionnalités sont implémentées dans les méthodes des classes).

Les diagrammes de séquence d’UML sont d’une très grande utilité pour départir les fonctionnalités aux classes. Ils illustrent une partie importante de la dynamique de l’application qu’on veut construire notamment : l’instanciation des classes, le passage des paramètres, les appels de méthodes et l’échange de messages entre les classes. A noter par ailleurs que les diagrammes de séquence permettent de situer la dynamique préalablement citée dans le temps.

Une suite normale serait donc d’ajouter un digramme de séquence à la figure 2 (Cf. figure 2 et 3).
 

Figure 3: Ajout d'un diagramme de séquence

Il reste maintenant à déterminer comment faire le passage du modèle de cas d’utilisation vers le digramme de séquence. Il ne s’agit pas d’une tâche facile étant donné que les deux digrammes précités n’ont pas la même vocation et ne s’arrêtent pas au même niveau de détail (les diagrammes de séquence décrivent en détail le fonctionnement interne du système tandis que les cas d’utilisation considèrent le système comme une boîte noire et se préoccupent plutôt des interactions frontales qui ont lieu entre l’utilisateur et le système).

Pour jeter le pont entre le digramme de cas d’utilisation et le digramme de séquence, les auteurs d’ICONIX proposent d’utiliser les diagrammes de robustesse qui font partie intégrante des premiers travaux d’Ivar Jacobson sur Objectory (nous rappelons que la notation UML est extensible à l’infini. Dès lors, rien n’empêche la création de nouveaux diagrammes pour adresser des besoins particuliers).

NB : Pour en savoir davantage sur les diagrammes de robustesse nous vous recommandons de consulter un appendice d’UML intitulé : Objectory Process-Specific Extensions

Figure 4 : éléments d'un diagramme de robustesse
 

Les diagrammes de robustesse permettent de déduire à partir du modèle de cas d’utilisation les nouveaux éléments de modélisation suivants :

* Les interfaces (boundary elements): page HTML, rapport, fenêtre Windows …
* Les éléments de contrôle: permettent d’ajouter une logique conditionnelle et des scénarios alternatifs au diagramme de robustesse.
* Entité : il s’agit de tout concept qui mérite d’être ajouté au diagramme en raison de sa pertinence sémantique et/ou conceptuelle eu égard au contexte d’affaires pour lequel l’application est conçue (acheteur, vendeur, contrat commercial …).

Cela dit, le modèle de robustesse reprend certains éléments de modélisation qui apparaissent déjà sur le diagramme des cas d’utilisation notamment :

* Les acteurs.
* Une référence à d’autres cas d’utilisation.

L’intérêt de passer par les diagrammes de robustesse est de pouvoir identifier les objets d’affaires, leurs propriétés, leurs méthodes de même que les flux d’informations qu’ils échangent. Cela permet de passer de la définition des besoins- c'est à dire celle fournie par les cas d’utilisation- à une description assez détaillée du fonctionnement du système qui permettra de les satisfaire (toujours dans une optique orientée objet).

A noter que dans ICONIX, les cas d’utilisation sont formulés d’une manière très détaillée et très précise à la différence d’autres méthodes qui les considèrent comme un livrable concis et sommaire à caractère purement exploratoire (en augmentant le niveau de détails projetés par les cas d’utilisation on réduit le laps de temps entre la phase d’analyse des besoins et la phase de codage).

Finalement, afin de mieux documenter les objets d’affaires et de les mettre en relation, les auteurs d’ICONIX proposent d’élaborer un modèle de domaine qu’on peut comparer à un glossaire qui catalogue les concepts relatifs au domaine d’affaires étudié.

Le cheminement complet d’un processus de développement basé sur ICONIX est illustré par la figure 5.

Figure 5: déroulement d'un projet de développement selon ICONIX

Pour en savoir davantage sur ICONIX nous vous recommandons les deux références suivantes:

* Site web: http://www.iconixsw.com/UMLecommerce.html
* Livre: Applying Use Case Driven Object Modeling With Uml: An Annotated E-Commerce
 

Kamal AOUDA

Consultant en TI, MBA

http://www.kamalaouda.com