Sur la qualité du logiciel, le développement web et les systèmes patrimoniaux – partie 2

Hier, j’ai publié sur la base du problème et j’ai décrit en somme ce vers quoi je devais aller. Aujourd’hui, je pousse plus loin en recréant les cas d’utilisation depuis l’implémentation.

Cas d’utilisation d’interface (I)

Sous sa forme la plus simple, les cas d’utilisation d’interface (I) sont les plus aisé à modéliser puisqu’ils correspondent à des points d’entrée bien définis dans l’application pour les opérations utilisateurs.

Ces cas d’utilisation I, je les ais aussi modélisé pour les interfaces de systèmes, soit comme points d’entrée de fonction d’un système tier vers l’architecture principale (le modèle du domaine). Ainsi, en plus des cas d’utilisation d’interface évidents (récupérés depuis le navigateur puisqu’il est question d’une application web), les cas d’utilisation d’interface I système ont été ajoutés.

Ces derniers peuvent être confondus avec les cas d’utilisation service S, cependant par leur nature, il y a réellement une barrière de communication entre le modèle de données et le reste du monde et ce sont les objets que l’on peut regrouper dans ces cas d’utilisation I, les interfaces de systèmes. Les interfaces de système ont donc une nomenclature qui se confond avec les cas d’utilisation de services S de par leur nature (cas d’utilisation en mode requête/mise à jour) cependant ils sont placés de sorte qu’ils viennent se poser comme interface au système ou à une autre composante du système (dans une architecture distribuée client-serveur par exemple).

Un premier jet est donc fait en extractant les cas d’utilisation évident des interfaces graphiques et des points d’entrée du code serveur.

Ce qui est bien avec ce processus inversé, c’est qu’il n’est pas nécessaire d’impliquer un designer graphique pour revenir en arrière pas plus que des prototypes d’écrans utilisateurs ne sont requis. Ils feront tout de même partie de la documentation, cependant ils auront déjà été produit.

Cas d’utilisation de services (S) et requis (R)

Par la suite, la plupart des cas d’utilisation de services (S) et requis (R) peuvent être modélisés à partir des cas d’utilisation I. De plus, certains cas d’utilisation S seront modélisés directement à partir de cas d’utilisation de requis (R) – ils sont dits cas d’utilisation S-Essentiel. Ces derniers ne pourront être modélisés à partir des cas d’utilisation d’interface cas ils n’impliquent pour ainsi dire pas d’interface.

L’important est de cerné tous les requis d’utilisation à partir de ce qui a été implanté. Ce ne devrait pas être bien difficile non plus que ça ne devrait être quelque chose qui révèle des requis inexistants ou non-implémentés, évidemment car sinon on aurait un gros problème.

En somme, on devrait avoir grosso-modo tracé les requis jusqu’aux éléments du modèle, des cas R aux cas S en passant par les cas I. Tous ça nous permettra d’avoir une suite qui descend de ces cas d’utilisation et qui puisse être représenté dans un diagramme de tracabilité des cas d’utilisation.