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