À l’université, j’ai eu de nombreux cours de conception et d’UML et je sais qu’UML peut être utilisé au profit d’un projet logiciel, en particulier pour les cas d’utilisation, mais est-ce vraiment pratique ? J’ai effectué quelques stages en alternance, et il semble que l’UML ne soit pas très utilisé dans l’industrie. Est-ce que cela vaut la peine de consacrer du temps à un projet pour créer des diagrammes de cas d’utilisation ? vaut-il la peine de consacrer du temps à la création de diagrammes UML dans le cadre d’un projet ? Par ailleurs, je trouve que les diagrammes de classes ne sont généralement pas utiles, parce qu’il est plus rapide de regarder le fichier d’en-tête d’une classe. Quels sont les diagrammes les plus utiles ?
Utiliser l’UML, c’est comme regarder ses pieds en marchant. C’est rendre conscient et explicite quelque chose que vous pouvez généralement faire inconsciemment. Les débutants doivent réfléchir attentivement à ce qu’ils font, mais un programmeur professionnel sait déjà ce qu’il fait. La plupart du temps, il est plus rapide et plus efficace d’écrire le code lui-même que d’écrire sur le code, car son intuition de la programmation est adaptée à la tâche.
Mais il ne s’agit pas seulement de ce que vous faites. Que penser du nouvel employé qui arrivera dans six mois et qui devra se familiariser avec le code ? Et dans cinq ans, lorsque tous ceux qui travaillent actuellement sur le projet auront disparu ?
Il est extrêmement utile de disposer d’une documentation de base à jour pour tous ceux qui rejoindront le projet plus tard. Je ne préconise pas de diagrammes UML complets avec des noms de méthodes et des paramètres (beaucoup trop difficile à maintenir), mais je pense qu’un diagramme de base des composants du du système avec leurs relations et leur comportement de base est inestimable.
À moins que la conception du système ne change radicalement, ces informations ne devraient pas changer beaucoup, même si le système est en cours de développement ne devraient pas beaucoup changer, même si l’implémentation est modifiée.
J’ai constaté que la modération est la règle en matière de documentation. Personne ne va lire 50 pages de diagrammes UML complets avec de la documentation sans s’endormir au bout de quelques pages. D’un autre côté, la plupart des gens aimeraient bien lire 5 à 10 pages de diagrammes UML, la plupart des gens aimeraient avoir 5 à 10 pages de diagrammes de classes simples avec quelques descriptions de base de la manière dont le système est inséré.
L’autre cas où j’ai trouvé UML utile, c’est lorsqu’un développeur senior est responsable de la conception d’un composant, mais qu’il confie ensuite la conception à un développeur junior pour qu’il l’implémente.
Dans un système assez complexe, il y a des domaines où un peu d’UML est considéré comme utile.
Les diagrammes utiles pour un système varient en fonction de l’applicabilité.
Mais les plus utilisés sont les suivants
- les diagrammes de classes
- les diagrammes d’état
- les diagrammes d’activité
- les diagrammes de séquence
De nombreuses entreprises ne jurent que par ces diagrammes, tandis que d’autres les rejettent catégoriquement, estimant qu’ils constituent une perte de temps et d’efforts.
Il est préférable de ne pas tomber dans l’excès et de penser à ce qui est le mieux pour le projet sur lequel vous travaillez et de choisir les éléments qui vous intéressent, et de choisir ce qui est applicable et logique.
Selon moi, l’UML et le Rational Unified Process consistent davantage à PARLER de ce que l’on va faire qu’à FAIRE réellement ce que l’on va faire (en d’autres termes, il s’agit d’une grande perte de temps).