Découpage en catégories

Le découpage en catégories constitue la première activité de l’étape d’analyse (il s’affine bien sûr de manière itérative au cours du projet). Il se situe sur la branche gauche du cycle en Y et succède à la capture des besoins fonctionnels. Enfin d’analyse des besoins, nous obtenons un découpage fonctionnel exprimé à travers les cas d’utilisation organisés dans le modèle de spécification fonctionnelle. Pour passer à l’analyse, nous allons changer radicalement l’organisation du modèle et nous fonder sur les principes de l’approche orientée objet, notamment sur celui d’encapsulation. À cet effet, nous allons passer d’une structuration fonctionnelle via les cas d’utilisation et les packages de cas d’utilisation, à une structuration objet via les classes et les catégories. La classe représente une entité de structuration trop petite dès lors qu’on s’attaque à un projet réel. Au-delà d’une douzaine de classes, il est utile de regrouper les classes fortement couplées en unités plus grandes. Le couplage s’exprime à la fois structurellement par des associations, des agrégations, des compositions ou des généralisations, mais aussi dynamiquement par les interactions qui se produisent entre les instances des classes. Bien sûr, plus le nombre de classes devient important, et plus cette structuration s’avère indispensable. G. Booch [Booch 96] a introduit le concept de catégorie pour nommer ce regroupement de classes qui constitue la brique de construction du modèle structurel d’analyse.

QU’EST-CE QU’UNE CATÉGORIE ?

Le terme catégorie n’appartient pas en standard au langage UML qui comporte en revanche le concept plus général de package. Pour notre part, nous avons conservé ce terme, afin de différencier les catégories qui structurent un modèle construit sur des classes, du concept plus générique de package. Nous représentons graphiquement les catégories comme des stéréo- types de packages. Le découpage fonctionnel induit par les cas d’utilisation permet de trouver les classes fondamentales du projet par le biais des diagrammes des classes participantes. Il faut cependant considérer que l’on a seulement identifié des classes candidates pour l’analyse, et non les concepts métier stables de l’entreprise. En effet, les diagrammes des classes participantes capturent le vocabulaire employé dans les cas d’utilisation, mais chaque terme n’a pas encore fait l’objet d’une définition élaborée au vu du problème de l’entreprise. Ces désavantages tiennent au fait que les concepts sont dilués dans les fonctions et ne représentent pas la problématique que doit résoudre le logiciel. À l’inverse, une approche objet offre à l’analyste la possibilité de consolider la définition des concepts, en termes de représentation à la fois structurelle et comportementale, puis de réutiliser ces définitions. Le découpage initial fonctionnel doit donc être remis en cause si l’on veut profiter des bénéfices de l’approche objet ; le découpage en catégories devient alors la base du modèle structurel d’analyse.

G. Booch recommandait déjà dans [Booch 96] de décomposer un système en catégories contenant une moyenne d’une douzaine de classes. Or, si nous faisons la moyenne des catégories de SIVEx, nous obtenons seulement 4 classes pour ce découpage préliminaire. D’où vient ce décalage ? N’oublions pas qu’il s’agit de classes candidates, issues d’une première itération d’analyse. Or, les catégories dont parle Booch sont des catégories de conception : elles ont subi de nombreuses itérations et incluent, en supplément, beau- coup de concepts techniques comme l’IHM ou l’accès aux données, qui apportent nettement plus de classes (voir chapitres 9 à 11).Au chapitre 4, nous avons indiqué qu’un package (et donc une catégorie) constitue un espace de nommage, et qu’il peut contenir des éléments UML, des diagrammes, voire d’autres packages. Cette relation de contenance est une relation de composition au sens UML. Cela signifie d’une part que tout élément UML est déclaré et possédé par un seul package. D’autre part, si le package est supprimé du modèle, tout élément inclus est également détruit.