Intérêt de l’UML dans un projet informatique

Intérêt de l’UML dans un projet informatique

Pourquoi modéliser le SI??

Le but de la modélisation d’un SI, est de spécifier les besoins et les exigences des acteurs,le système et l’architecture globale.

Nous allons tout au long de cet article, parcourir les différents avantages ou inconvénients de l’UML(standard de modélisation) dans un projet informatique, afin de savoir dans quel(s) cas son utilisation est bénéfique.

1) Pourquoi utiliser l’UML dans le cadre d’un projet informatique?

De nos jours, les outils de modélisation de processus métier (ex BOUML) s’étoffent chaque année et les suites logiciels sont de plus en plus nombreuses. L’usage et les fonctionnalités d’UML diffèrent d’un périmètre à un autre, selon les besoins des clients et des fournisseurs d’applications.

Dans le cadre d’un projet informatique pour le SI, le recours à la modélisation UML procure de nombreux avantages qui agissent sur:

La modularité
L’abstraction
La dissimulation
La structuration cohérente des fonctionnalités et des données

Il permet aussi dans un premier temps de bien définir les besoins clients, et ainsi d’éviter des sur coûts liés à la livraison d’un logicielle qui ne satisfait pas le client (Selon une étude du Standish Group en 1994, pour 53% des logiciels crées, le taux de délai de livraison non respecté est de 120%, on avait 90 % de budgets non tenus, et 60% de non disponibilité de certaines fonctionnalités).

De plus, la modélisation UML permet de vulgariser les aspects liés à la conception et à l’architecture, propres au logiciel, au client. Aussi, elle apporte une compréhension rapide du programme à d’autres développeurs externes en cas de reprise du logiciel et facilite sa maintenance.

Toutefois, il existe aussi des inconvénients quant à l’utilisation d’UML. Pour la plupart, essentiellement liés au dépassement du délai de livraison du logiciel .

Pour pallier à ce problème , le recours à un cycle de projet en spirale est recommandé car il apporte plus d’agilité et une meilleur gestion des risques.

L’utilisation d’UML nécessite par ailleurs, une formation préalable pour connaître ses normes standards, cela peut être un inconvénient pour le client qui n’a pas de compétences dans ce domaine.

Notons aussi, qu’il peut y avoir une mauvaise correspondance entre l’UML et le projet finalisé (Shéma d’élaboration différent au niveau de la conception: l’analyste et le développeur étant deux personnes distinctes).

2) La dimension/type d’un projet a-t-elle un impact sur l’utilisation d’UML (ou sur l’inérêt d’UML) ?

UML est conçu pour modéliser divers types de systèmes, de taille quelconque et pour tous les domaines d’application.

Après avoir présenté les différents avantages et inconvénients de la modélisation d’un système d”informations, nous allons étudier son impact sur différents types et différentes tailles de projets.

D’abord, il faut savoir que le domaine d’activité de l’application à modéliser n’est pas important. Il impliquera juste de bien connaître le métier du client, son vocabulaire ainsi que ses besoins spécifiques. C’est plutôt la taille et la complexité du projet qui vont impliquer ou non l’utilisation de l’UML.

La complexité du projet peut influencer la volonté ou non de modéliser une application SI:

Dans de nombreux projets, l’architecture du logiciel est assez simple car il suit juste une architecture de référence et donc il n’y a pas de besoin important de créer des diagrammes pour représenter et communiquer sur la conception.

Dans certains cas, la conception est communiquée oralement ou en utilisant d’autres notations graphiques, tels que les diagrammes informels et en ligne.

Dans d’autres projets une bonne communication sera indispensable étant donné le nombre de collaborateur associé à la conception de l’application. L’utilisation d’UML sera donc un choix judicieux même si elle constitue un manque de temps dans le début du projet.

Enfin, il est possible que le client souhaite avoir un diagramme UML de son application . Dans ce cas, la question de son utilisation ne se pose pas.

La question est de savoir si le client ou l’équipe de développeur saura lire et comprendre l’UML….En effet, UML a gagné en complexité et en taille au fil des ans. Aujourd’hui il existe 14 différents types de diagrammes, cela peut paraître important et certaines personnes seront réticentes à l’utilisation de l’UML parce qu’elles jugent que l’effort pour gravir la courbe d’apprentissage ne sera pas payant.

Les outils de modélisation de processus métier s’étoffent chaque année et les suites logicielles sont de plus en plus nombreuses. Actuellement, il existe 76 outils conçus pour la modélisation UML dont l’usage et les fonctionnalités diffèrent d’un périmètre à un autre, selon le besoin de l’entreprise. En effet, il n’existe pas un seul meilleur outil, mais le choix de ce dernier est basé sur différents paramètres liés à l’environnement technico-commercial de l’évolution du projet de l’entreprise, notamment la méthodologie, la technologie, les parties du projet à modéliser, la collaboration entre les membres et le niveau d’autonomie souhaité par le système.

L’UML n’est qu’un support de communication, son intérêt dépendra donc surtout des personnes qui communiquent et non du projet en lui même.

3) Retours d’expérience

Après s’être penché sur les avantages et les inconvénients des solutions UML ainsi que sur leur utilisation dans les différents projets ou secteur d’activité, nous allons synthétiser les différents retours d’expérience que nous avons pu recueillir.

L’idée forte qui ressort des différents témoignages est la suivante : l’utilisation des solutions de modélisation comme UML dépend des besoins du projet et de sa dimension. Cela dépendra aussi de la politique (manière de gérer et documenter les projets), de la dimension de l’entreprise ainsi que des exigences du client.

Les avis sont partagés et chacun a sa propre utilisation des différents diagrammes UML.

1- Pour la conception logiciel

Jean-Christophe Hurpeau, responsable du développement d’Ortho-Clinical Diagnostics, a adopté UML pour réaliser son second logiciel d’aide au diagnostic destiné aux laboratoires médicaux.

‘ L’absence de modèle se faisait sentir. Le code était, en outre, faiblement documenté et nous n’étions pas à l’abri d’une perte de connaissances due au départ d’un développeur. UML nous a permis de décrire nos besoins et nos spécifications de façon très précise. Nos codes sont toujours en phase avec le modèle, ce qui fait qu’un nouveau technicien n’a besoin que de connaître UML pour comprendre tout de suite la structure du programme. UML nous apporte aussi une qualité certaine. Désormais, notre logiciel est très structuré. ‘

Sophie Houssiaux, chef de projet chez l’éditeur de logiciels Evidian, a participé au choix d’UML il y a six ans.

‘ Nous avions sélectionné UML car cette méthode avait été validée par les organismes de standardisation, et elle constitue effectivement aujourd’hui un standard de fait. L’introduction s’est faite avec douceur : nous avons commencé par former toutes les équipes de développement, environ une centaine de personnes, puis nous avons appliqué UML à trois projets pilotes. Des consultants ont constamment accompagné les équipes, une démarche décisive qui a permis aux gens de bien accepter la nouvelle méthode. UML a ainsi été appliqué à tous les développements orientés objet. Les développeurs écrivent eux-mêmes les spécifications et développent ensuite leur code.‘

Cet intérêt varie selon les entreprises, pour certaines il est recommandé de bien dissocier les personnes qui rédigent les spécifications et qui réalisent les qualifications de celles qui font les développements.

‘ Ils sont libres de choisir leur outil de développement, et d’appliquer les modèles de programmation qui leur permettent d’avancer plus vite.(…) mais lorsqu’on a une démarche qualité comme nous, nous n’en retirons que des avantages. Les gains sont tels qu’ils font oublier les coûts de formation, de temps de familiarisation, le prix des ateliers de développement. ‘

2- Pour l’intégration

Pascal Roques (Valtech Training) : ‘ UML n’est qu’un formalisme ‘

‘ Il ne faut pas attendre d’UML plus qu’il ne peut donner. Ce n’est qu’un formalisme, un langage de modélisation. C’est une boîte à outils pour l’architecte ou le développeur, plutôt qu’une méthode de développement stricto sensu. Il est nécessaire de bien l’appréhender pour l’utiliser correctement car on peut s’en servir pour des choses différentes, comme le métier de l’entreprise ou l’interaction entre composants logiciels.’

L’ utilisation d’UML ‘ varie en fonction du type d’application à réaliser, de sa taille. Par exemple, sur les douze diagrammes que contient UML, quatre ou cinq suffisent à réaliser un petit projet. Il faut savoir qu’un modèle doit avoir un objectif précis. Sinon, il risque de ne pas être adapté à son usage ou même à son lectorat. ’

William Da Cunha (SMILE, intégration)

‘ Chaque diagramme est un outil qui peut être utile s’il est correctement utilisé, dans la bonne situation. De plus, il faut faire attention aux dérives (diagrammes illisibles). Mal utilisé, cela représente une énorme perte de temps.’

Il cite les diagrammes suivants accompagnés de leur utilité :

‘ Le diagramme de déploiement (représente l’architecture physique : serveur, adressage…) est utile lorsque l’architecture est “conséquente” (plusieurs serveurs). Donne une vision de l’infrastructure globale. ’

‘ Le diagramme de cas d’utilisation, à mon sens est le seul diagramme fréquemment utilisé. Utile s’il est associé à des règles de gestion ainsi qu’à des maquettes, lorsque le cas d’utilisation est complexe et que plusieurs acteurs sont concernés. ‘

‘ Le diagramme de classe est peu utilisé par les “intégrateurs” pour une vision globale de l’application. Nous utilisons des solutions existantes que nous adaptons aux besoins du client. Cela représente énormément de “classes” que nous n’avons pas développées. Nous utilisons donc ce diagramme pour des visions partielles (modules) et jamais pour l’intégralité des classes. Ce diagramme est utile pour les JavaBean (génération de code automatique) ainsi que pour mentionner et décrire les DesignPattern utilisés. De plus, il est difficile à maintenir. ‘

‘ Le diagramme d’activité est pratique pour des cas d’utilisation complexe avec plusieurs points de rupture ’

‘ Pour les autres diagrammes, je ne les ai jamais rencontré lors de ma vie professionnelle.’

Conclusion

Le choix d’’utilisation d’UML dépend surtout de la dimension (durée/complexité/acteurs) du projet informatique et de la politique de l’entreprise.

L’utilisation d’UML ne garantit pas le respect des concepts objet : à vous de vous en servir à bon escient. Une bonne utilisation d’UML nécessite une formation.

Les diagrammes UML sont des outils, des supports de communication qui permettent de vulgariser la conception et les fonctionnalités d’une application.

“Un beau dessin vaut mieux qu’un long discourt, seulement s’il est compris par tous de la même manière” D.Longuet