Développement avec UML

Développement avec UML

Nous avons déjà indiqué au chapitre 1 que la finalité de l’activité de développement était de fournir une solution informatique à un problème posé par un utilisateur, aussi appelé client. Nous avons précisé que le code n’était que la matérialisation de la solution, tandis que le modèle contenait toutes les informations facilitant d’une manière ou d’une autre la construction de la solution.Après cette introduction aux vues essentielles d’un modèle UML (structurelle, comporte- mentale et fonctionnelle) d’une application, il nous reste à présenter la façon dont nous devons utiliser chacune de ces parties afin de réaliser notre objectif : la réalisation de la solution à partir du problème.Pour atteindre cet objectif, l’ingénierie logicielle a identifié depuis plusieurs années deux phases principales à réaliser : l’analyse du problème et la conception de la solution.Grâce à la phase d’analyse, nous savons ce qui doit être intégré dans la solution, mais aussi ce qui ne doit pas l’être, puisque la solution ne doit prendre en compte que ce qui a été identifié lors de l’analyse. Idéalement, une analyse doit être réalisée par l’équipe de développement et validée par le client, lequel certifie ainsi que l’équipe de développe- ment a bien compris son problème.Dans ce cours, nous considérons que le problème du client est spécifié dans un cahier des charges. Le cahier des charges est un document textuel fourni par le client, mais qui n’est pas intégré dans le modèle d’une application. Dans notre contexte, la phase d’analyse consiste à modéliser tous les besoins présents dans le cahier des charges.

Ces deux parties du modèle UML sont suffisantes pour modéliser les besoins du client exprimés dans le cahier des charges. Cependant, afin de bien préciser les liens de cohé- rence entre ces deux parties, nous utilisons aussi la partie comportementale, comme nous l’avons montré au chapitre précédent. Cette partie permet en effet de lier les cas d’utilisa- tion aux interactions; elles-mêmes liées aux classes.Dans le cadre de notre vision schématique du modèle UML d’une application, nous considérons que la phase d’analyse correspond à un niveau d’abstraction que nous appe- lons le niveau besoin.Contrairement à ce que nous pourrions croire, fournir une solution informatique n’est pas ce qu’il y a de plus difficile : c’est juste un problème algorithmique. Par contre, il est bien plus compliqué de fournir la meilleure solution au problème, car, à un problème donné, correspondent bien souvent plusieurs solutions.Prenons l’exemple du tri. Il existe plusieurs façons de trier des éléments (tri itératif, tri à bulles, tri rapide, etc.). Toutes ces solutions résolvent le problème du tri d’un point de vuePour différencier les solutions, deux critères sont bien connus : la complexité en espace et la complexité en temps. Ces critères permettent d’établir un classement des solutions en fonction de la place mémoire qu’elles occupent et du temps qu’elles mettent à réaliser le traitement.

D’autres critères, plus adaptés au monde industriel et au paradigme objet, permettent d’effectuer d’autres classements des solutions. Citons notamment la maintenabilité, la portabilité, la robustesse, la rapidité de développement, le coût de développement, etc. Cette liste non exhaustive de critères montre que la construction d’une solution optimale est loin d’être triviale.Pour être pragmatique, mais aussi pour simplifier la difficulté de la phase de conception, nous considérons dans le cadre de ce cours qu’une conception optimale est une concep- tion qui maximise l’indépendance à l’égard des plates-formes techniques et minimise les dépendances entre les différents objets de l’application.À ces deux objectifs, nous faisons naturellement correspondre les deux niveaux d’abstraction que nous avons introduits au chapitre 8. En effet, nous avons vu que le niveau conceptuel permettait de définir une conception indépendante des plates-formes d’exécution. Nous avons vu en outre au chapitre 4 qu’il était possible de minimiser les relations de dépendance entre les packages du niveau physique.