Les inconvénients d'UML
Le langage de modélisation unifié (UML) est un langage de modélisation logiciel mettant l'accent sur les graphiques et le mouvement. C'est le langage standard de l'industrie pour la modélisation et la conception de logiciels, selon Sparx Systems. Cependant, certains développeurs et sociétés de conception de logiciels peuvent rencontrer des problèmes lors de l'utilisation d'UML. Les inconvénients de l'utilisation d'UML incluent l'ajout de tâches à la portée de travail d'un projet et l'utilisation excessive de diagrammes UML.
Heure
Un inconvénient que certains développeurs peuvent rencontrer lors de l'utilisation d'UML est le temps nécessaire pour gérer et maintenir les diagrammes UML. Pour fonctionner correctement, les diagrammes UML doivent être synchronisés avec le code du logiciel, ce qui nécessite du temps pour la configuration et la maintenance, et ajoute du travail à un projet de développement logiciel. Les petites entreprises et les développeurs indépendants peuvent ne pas être en mesure de gérer la quantité de travail supplémentaire nécessaire pour synchroniser le code.
Qui en bénéficie
Il n'est pas toujours clair à qui profite un diagramme UML. Selon un article publié sur le site Web d'Eiffel Software, UML n'est pas avantageux pour les développeurs de logiciels, principalement parce que les développeurs de logiciels travaillent avec du code, pas avec des images ou des diagrammes. Les diagrammes UML peuvent être utiles aux chefs de projet ou aux cadres pour illustrer le fonctionnement d'un outil logiciel, mais il peut être plus facile de dessiner le diagramme sur un tableau blanc ou une feuille de papier, plutôt que de prendre le temps d'apprendre le langage UML.
Les diagrammes peuvent devenir accablants
Lors de la création d'un diagramme UML en conjonction avec le développement de logiciels, le diagramme peut devenir écrasant ou trop compliqué, ce qui peut être déroutant et frustrant pour les développeurs. Les développeurs ne peuvent pas cartographier chaque scénario pour un outil logiciel dans le diagramme, et même s'ils essaient de le faire, le diagramme devient désordonné. Une façon pour les développeurs de lutter contre ce problème consiste à n'inclure que des faits de base et des informations de haut niveau dans les diagrammes UML, selon un article sur Stack Overflow de Stefano Borini, chimiste quantique et développeur UML.
Trop d'accent sur le design
UML met beaucoup l'accent sur la conception, ce qui peut être problématique pour certains développeurs et entreprises. L'examen d'une portée logicielle dans un diagramme UML peut conduire les parties prenantes du projet logiciel à sur-analyser les problèmes, ainsi que la perte de concentration en consacrant trop de temps et d'attention aux fonctionnalités logicielles. Les entreprises ne peuvent pas résoudre tous les problèmes avec un outil logiciel à l'aide d'un diagramme UML. En fin de compte, elles n'ont qu'à commencer à coder et à tester. Brody Gooch, co-créateur d'UML, a déclaré que la vision originale d'UML était un "langage graphique pour aider à raisonner sur la conception d'un système au fur et à mesure qu'il se déroule". Si les gens s'accrochent à l'aide d'un diagramme pour identifier et résoudre les problèmes, cela peut retarder le travail réel qui doit être fait pour résoudre les problèmes.