Ta remarque me fait penser à quelque chose : Comment modéliser ce type de choses en UML ?
Très simple: on ne fait pas. Enfin, je suppose qu'on peut faire un workaround en créant une "classe" qui n'a pas de nom. C'est moche, mais bon, UML est quand même super dogmatique, donc ça force a faire des trucs moches (comme en java ou il faut créer une classe avec une méthode statique pour le main(), parce que sinon spas de l'objet pur... heureusement que le rididule ne tue pas!)
Je pense que pour des langages non objet, UML est assez peu utile en effet. En tout cas, moi ce que j'utilise le plus dans UML, ce sont les diagrammes de classe, qui n'ont évidemment aucun intérêt dans ce type de situation. Par contre je suppose que tu dois pouvoir utiliser d'autres diagrammes (diagramme d'état-transition peut-être?) pour ce genre de choses: je suppose que ça peut servir de hack potable... mais bon, franchement, je n'en vois pas plus que ça l'intérêt.
C'est d'ailleurs valable pour UML de manière générale, je vois ça comme un truc pour faire des jolis dessins pour le chef, histoire qu'il ait l'impression de comprendre ce qu'il se passe.
Comme je l'ai dis, je n'utilise que les diagramme de classe pour ma part, et encore (sauf pour amuser la galerie, dans ces cas la je trouve le diagramme de cas d'utilisation utile, ça remplit les slides...), je ne fait jamais de diagramme complet, ça ne me sers qu'a avoir une vue de haut niveau, pratique pour prendre du recul, réfléchir à l'architecture, ce genre de trucs, mais ça finis souvent désynchronisé de toute façon, et comme on ne peux pas y mettre les fonctions, ben, je m'emmerde pas avec ça.
Après, je ne suis pas non plus un expert UML... je préfère passer mon temps à coder voire écrire de la doc, je trouve ça plus utile (et c'est dans la doc qu'UML à un petit intérêt, mais juste petit).
[^] # Re: l'héritage et les exemples pourris
Posté par freem . En réponse au lien « Clean code » : performances lamentables. Évalué à 2.
Très simple: on ne fait pas. Enfin, je suppose qu'on peut faire un workaround en créant une "classe" qui n'a pas de nom. C'est moche, mais bon, UML est quand même super dogmatique, donc ça force a faire des trucs moches (comme en java ou il faut créer une classe avec une méthode statique pour le main(), parce que sinon spas de l'objet pur... heureusement que le rididule ne tue pas!)
Je pense que pour des langages non objet, UML est assez peu utile en effet. En tout cas, moi ce que j'utilise le plus dans UML, ce sont les diagrammes de classe, qui n'ont évidemment aucun intérêt dans ce type de situation. Par contre je suppose que tu dois pouvoir utiliser d'autres diagrammes (diagramme d'état-transition peut-être?) pour ce genre de choses: je suppose que ça peut servir de hack potable... mais bon, franchement, je n'en vois pas plus que ça l'intérêt.
C'est d'ailleurs valable pour UML de manière générale, je vois ça comme un truc pour faire des jolis dessins pour le chef, histoire qu'il ait l'impression de comprendre ce qu'il se passe.
Comme je l'ai dis, je n'utilise que les diagramme de classe pour ma part, et encore (sauf pour amuser la galerie, dans ces cas la je trouve le diagramme de cas d'utilisation utile, ça remplit les slides...), je ne fait jamais de diagramme complet, ça ne me sers qu'a avoir une vue de haut niveau, pratique pour prendre du recul, réfléchir à l'architecture, ce genre de trucs, mais ça finis souvent désynchronisé de toute façon, et comme on ne peux pas y mettre les fonctions, ben, je m'emmerde pas avec ça.
Après, je ne suis pas non plus un expert UML... je préfère passer mon temps à coder voire écrire de la doc, je trouve ça plus utile (et c'est dans la doc qu'UML à un petit intérêt, mais juste petit).