Discussion :

[stripitu]

bonjour à tous
puis je utiliser les diagrammes de UML (j'ai juste besoin des diagrammes de cas d'utilisation, les diagrammes de séquence et les diagrammes d'activité) sans avoir une application Orienté Objets ?
je développe avec C

[Nip]

La reponse est simple: oui tu peux, meme si UML est optimise pour les langages objets.
Tu peux entre autre modeliser le comportement dynamique par les diagrammes d'activite, d'etats de collaboration et autres... . Mais tu peux aussi etendre UML de facon a representer tes fichiers sous forme de diagramme de classe, avec les differentes fonctions incluses, permettant d'avoir une vue d'ensemble de la structure du systeme.

[ego]

Pour information, on peut faire de l'objet en C.
Il suffitde regarder le code de truc comme X-Windows ou Motif.
D'autre part, les premiers compilateurs C++ passaient pas une traduction en C avant la compilation effective; donc.......

Autre point, rien ne t'empêch de faire une conception objet et passer ensuite à une implémentation en C.
Dans ma boite, on fait même de l'UML pour passer ensuite à COBOL.

[Luc Orient]

... Dans ma boite, on fait même de l'UML pour passer ensuite à COBOL.

Là je demande à voir ...

[Joshua Beharia]

Hello,

Ego ça m'interesse le passage d'UML à Cobol ! Mais je pense que vous avez établis des règles internes à ta boite pour faire ceçi donc je ne m'attend pas à ce que tu nous lances toute la science mais bon... ;op

Sinon, pour ton problème stripitu, saches que je bosse constament avec UMl afin de réaliser des applications RT en C(en C Objet en suivant des règles de transformation).

Mais il peut arriver et se n'est pas rare, que l'on fasse toute une étude en UML en suivant une méthode (que je peux pas citer dézo) et que lors du passage en phase d'implémentation, on décide de ce qui va être objet ou pas.

@+

[ego]

Sans tout vous dire, mais en fait il n'y a rien d'extraordinaire, pensez simplement que les opérations des classes UML se transforment en programme COBOL. Pour certains types de classes, c'est plutôt la classe qui donne naissance à un programme COBOL et les opérations se transforment en "code fonction" passé en paramètre du dit programme.
Pour l"héritage, je vous passe la solution, mais elle correspond à une mise en oeuvre des capacités de COBOL (redefine) déjà en place avant l'arrivée d'UML. La différence est que maintenant on "sait" pourquoi on mettait en place cette solution avant (les gens savaient mais n'avaient pas conscience que leur solution pouvait provenir d'une modélisation objet avec héritage)

Donc rien d'impossible techniquement, c'est plus une question de culture

[Luc Orient]

... Donc rien d'impossible techniquement, c'est plus une question de culture

Là je suis bien d'accord ...
Mais jusqu'à présent, et pour ce que j'ai pu en voir pour la partie modélisation des données, il y a loin de la coupe aux lèvres ...
Et puis, je dois vous faire un aveu : l'entreprise à laquelle vous faites allusion, je la connais plutôt bien puisque j'y travaille aussi ...
Les échos que j'ai eu, certes limités et sans doute partiaux, me font penser que pour UML sur la modélisation des données sur le Mainframe, il y a encore du chemin à faire ...

[Joshua Beharia]

Je suis d'accord sur le fait que UML ne te permet pas de tout faire.
Le prob sur l'évolution d'Uml c'est que les évolutions ne vont pas dans le sens du développement mais dans le sens des sociétés qui participent à l'évolution d'uml.
Donc dans ce cas, on arrive à un ensemble assez bizarre qui te permet de faire tout et n'importe quoi, il suffit de regarder certaines définitions de UML2.0 pour le voir...

[ego]

Peut être mais par exemple, on en se pose pas la question quand on parle de Merise dans un contexte COBOL, pourriez-vous m'expliquer alors la différence fondamentale entre Merise/Cobol et UML/Cobol ?

Je ne vois personnellement AUCUNE différence si ce n'est des peurs souvent non fondées sur un réel retour d'expérience (peurs que je comprend par ailleurs).

Pour "Luc Orient", saches qu'ils y a des projets dans notre boite, donc, qui font UML/Cobol et il n'y a pas de problème si ce n'est la montée en compétence et les difficultés liées à une gestion du changement. Les difficultés rencontrées auraient été les mêmes, j'en suis totalement certains, si on avait fait du Merise; car le problème est en vérité ailleurs. Le problème est la formalisation précise et non ambigue de ce que l'on attend d'un logiciel et là c'est clairement pas simple quand on a l'habitude de s'appuyer sur de longues phrases en français forcément ambigues.