Discussion :

[kisitomomotene]

Après avoir lus plusieurs post dans ce forum, beaucoup semblent dire que une analyse ou une conception est le garant d'une bonne réussite du développement d'une application.

D'abord personnellement, je pense qu'il est impossible de programmer sans faire au préalable ne serait ce que dans sa tête une analyse ou une conception. On conçoit toujours un plan de son future programme avant de se mettre à le programmer. Mais contrairement à ce que beaucoup me font croire, je ne pense pas que formaliser d'abord son analyse en utilisant un langage comme UML ajoutera quelque chose de plus dans le programme qu'on écrira plus tard. Pour moi UML permet tout au plus de communiquer son idée de conception à d'autres personnes.

Si on a commit une erreur dans son analyse ou dans sa conception, ce n'est pas en utilisant UML qu'on pourra déceler cette erreur. En d'autre terme UML n'est pas une théorie mathématiques avec des théorèmes qui peuvent aider à valider l'analyse qu'on a fait.

Si on a une idée de l'application qu'on veut programmer, on peut exprimer cette idée directement en utilisant un langage de programmation, plutôt qu'en passant par un langage intermédiaire (UML).

D'autre part, on peut bien concevoir un programme (en UML), mais au moment de l'implémentation certaine information qui n'apparaissait pas au moment de la conception rendent la conception initial caduque, ou bien on trouve qu'on pouvait mieux faire, mais on n'a plus le temps de rentrer d'abord modifier sa conception initiale et on finit par écrire un programme qui n'a plus rien à voir avec la conception faite initialement.

J'aimerais savoir concrètement comment UML ou tout autre formalisation de l'analyse/conception aide certaine personne à mieux développer

[m0una]

Si on a commit une erreur dans son analyse ou dans sa conception, ce n'est pas en utilisant UML qu'on pourra déceler cette erreur. En d'autre terme UML n'est pas une théorie mathématiques avec des théorèmes qui peuvent aider à valider l'analyse qu'on a fait.

UML est un langage semi formel, c'est clair qu'il ne peut couvrir tous les aspects du système d'ailleurs on fait souvent des transformations des différents diagrammes UML vers des modèles formels comme petri avant de procéder à la vérification d'un système.. ceci dit UML nous aiderait toujours, à mon avis, de localiser au moins d'où proviennent les erreurs.

[el_slapper]

UML, c'est juste un méthode propre et agréable. Donc mieux, en général, qu'un truc fait à l'arrache sur un bout de torcheballe. Mais c'est tout. Je suis assez d'accord avec le posteur original.

[Franck SORIANO]

Mais contrairement à ce que beaucoup me font croire, je ne pense pas que formaliser d'abord son analyse en utilisant un langage comme UML ajoutera quelque chose de plus dans le programme qu'on écrira plus tard.

Lorsque tu fais ton analyse dans ta tête au départ tu as une vague idée de la façon dont ça va (devrait) fonctionner. Mais tu ne peux pas penser immédiatement à tout. Donc il va y avoir de nombreuses zones d'ombre dans l'analyse.

Si tu fais l'effort de formaliser un peu la conception, si tu essaies de rédiger des documents qui décrivent plus précisément comment les choses vont fonctionner, tu vas automatiquement afiner ton analyse et rentrer d'avantage dans les détails.

Ainsi, le fait de formaliser l'analyse va tout simplement permettre de la relire, de se rendre compte qu'il y a des contradictions avec telle ou telle chose...

Après UML ou autre chose... c'est à voir. UML n'est qu'un langage.

Si tu commences à coder ton idée, tu vas affiner l'analyse au fur et à mesure du codage. Si tu rencontres une incohérence et qu'il faut revoir la modélisation, tu risques d'être obligé de refaire complètement une grande partie du codage...
L'intérêt d'avoir modélisé la conception, c'est que le modèle est moins détaillé que le code. Tu dois en principe pouvoir le faire et le modifier plus rapidement que le code en lui-même. Sans parler du fait qu'il sera sûrement plus lisible que 10 000 lignes de code...

Maintenant de toute façon, si tu dois travailler en équipe dans un projet un tant soit peu important, tu n'auras pas le choix.
Tu devras produire de la documentation technique pour que le code soit maintenable, pour communiquer l'architecture du code et de l'application aux autres développeurs...
Tu devras également faire valider les grandes lignes des choix de conceptions par un comité technique ou autre... Tu devras réclamer un budget pour réaliser un projet...
Dans tout ces cas de figures, il faudra que tu ais des éléments concrêts à communiquer aux décideurs. Il faudra les convaincres que ta solution est viable, que l'estimation des coûts est réaliste et qu'il serait difficile de faire mieux.
Tu ne peux pas leur donner le code tout fait et leur dire débrouillez vous.
Tu ne peux pas non plus te présenter les mains dans les poches et dire : "faite moi confiance, tout est très claire dans ma tête...".

Après bien sûr, tout est une question d'échelle. Si c'est pour un petit projet avec une conception triviale, le problème est différent.

[_Xavier_]

UML, c'est juste un méthode propre et agréable.

Un langage ou une méthode ?

[el_slapper]

Un langage ou une méthode ?

l'éternel débat. Strictement parlant, tu as raison, c'est un langage, mais la manière dont il s'utilise s'apparente à une méthode de modélisation.

[Maximil ian]

Je pense qu'UML et les autres méthodes/langages de modélisation ont deux utilités fondamentales :

- Vecteur de communication d'un modèle. Que le diagramme UML soit placé dans un dossier de conception, d'architecture ou tracé sur un tableau lors d'une discussion sur le vif, le but est le même : faire circuler entre différents participants au projet un modèle représentant une partie de l'application ou de son comportement, soit directement, soit de façon différée via un document qui sera ensuite relu.

- Aide à l'architecture et au design du code. Certains développeurs ont une intelligence visuelle et spatiale plus marquée que d'autres. Ils pensent mieux leur code et les interactions entre modules ou objets en traçant des schémas sur un bout de papier avant. D'autres en ont moins besoin et commencent directement à développer en recherchant un effet "emergent design".

Donc pour répondre à ta question, oui la formalisation de la conception peut aider à mieux programmer. Attention cependant, plus la formalisation est poussée plus le risque de désynchronisation avec le code et des documents entre eux est grand.

Par contre tu mentionnes l'analyse, c'est quelque chose de complètement différent. Ce travail consiste 1) à étudier l'existant et 2) à recueillir le besoin du client, exprimé oralement ou à l'écrit, puis le transformer en spécifications qui peuvent prendre des formes multiples. Là ça n'aide pas à mieux programmer, c'est juste que sans une liste des fonctionnalités attendues de l'application il n'y a rien à programmer !

[kisitomomotene]

Par contre tu mentionnes l'analyse, c'est quelque chose de complètement différent. Ce travail consiste 1) à étudier l'existant et 2) à recueillir le besoin du client, exprimé oralement ou à l'écrit, puis le transformer en spécifications qui peuvent prendre des formes multiples. Là ça n'aide pas à mieux programmer, c'est juste que sans une liste des fonctionnalités attendues de l'application il n'y a rien à programmer !

ça depends la spécification des besoins, certain la considèree comme faisant partie de l'analyse, d'autre ne n'inclut même pas comme faisant partie de l'analyse. Dans tous les cas l'analyse n'est pas identique à la spécification des besoins.
Dans la spécification des besoins, le système peut apparaître comme un boite noire, on sait ce que le système fait, et non comment il le fait.
Par contre une analyse aborde le comment mais en restant dans les limites du métier. En d'autre terme un expert métier doit pouvoir comprendre et valider au besoin un document d'analyse. les termes techniques comme "transaction", "design pattern", "EJB", etc ne doivent pas figurer dans un document d'analyse.
La conception fait introduire des notions de technique informatique dans la description du "comment" du traitement.

En résumé, un document de spécification doit pouvoir être compris voir même rédigé par des utilisateurs du futur système, un document d'analyse doit pouvoir doit pouvoir être compris voir même rédigé par un expert métier, un document de conception doit être rédigé par un développeur uniquement.