Je vient de me demander si pensez qu'un diagramme UML pourrait s'avérer utile.
Dans cette idée, j'ai cherché un générateur de code source à partir de diragrammes UML et je n'ai trouvé que boUML qui soit portable (utilise la lib QT).
Je voudais savoir ce que vous en pensez, et si vous pensez qu'il vaut mieux que nous codions le parser nous mêmes ou en utilisant flex et yacc?

Tout dépend si on souhaite adopter une philosophie oriantée objet ou non (personnellement, je ne suis pas trop pour...)

Le diagramme UML ne releve pas simplement d'une hiérarchie de classe, mais de relation. Il peut également être utilisé pour décrire les cas d'utilisation, les variables globales, etc... ce qui peut être utilisé pour un langage non objet.

Le choix de l'UML n'impose pas un langage objet.

Sinon, d'un point de vue personnel, je suis plutot pour un langage objet. Cela facilitera la programmation modulaire.

Je sent un troll arriver la

Hihi... je crois qu'y a un topic avec nos arguments sur les langages non-objet/objet:
http://www.progboards.com/sujet-1299_baston_generale__.php

Sinon, je pense qu'on peut malgré tout se servir de l'UML pour les cas d'utilisation & co, ca permettra de structurer le travail et de le répartir entre les différents membres, surtout si l'on souhaite vraiment coder un IDE a long terme, en fait.

J'ai changé d'avi.
Manifestement, ce sera plus simple de coder en C et avec les techniques de programmation modulaire.
Notre projet n'est pas suffisement complexe pour que l'UML apporte plus qu'il ne retire, et idem pour l'orienté objet.
Qu'en pensez-vous?

Je sais pas. Argumente ^^ car là, c'est un peu flou.

Ben...
Penses-tu avoir un interêt quelconque à utiliser des classes dans le parser?
Idem, pour le traducteur, je n'arrive pas à en voir l'intérêt...

Ok, exemple pour le parser.
Tu as un identifiant. Mais au début tu ne sais pas ce que c'est (label, nom de fonction, nom de sub, variable ?). Donc tu peux déjà avoir une classe Identifiant avec un certain nombre de classe fille.

De plus, l'UML n'a jamais rien retiré, il ne fait qu'apporté. Donc, cela n'enlève strictement rien d'utiliser l'UML.

Et puis l'objet permet de faire de l'encapsulation facilement, ce qui facilite la programmation modulaire.

Donc, on fait une analyse UML?
Ou juste le diagramme des classes (ce qui est à mon avis le seul truc vraiment intéressant, dans UML, le reste ne servant qu'à générer le sus-mentionné diagramme des classes) ?

Je pense que faire au moins un diagramme de classe (si on utilise des classes, bien entendu) est un bon moyen de voir les relations existants entre les différents type d'objets.

J'ai essayé umbrella comme modéleur UML, mais il n'arrete pas de planter.Je vais essayer un autre. ArgoUML, j'ai déjà testé, mais je n'aime pas du tout l'interface. Quelqu'un connait un autre modeleur UML tournant sous Linux et Windows, de préférence...