Discussion :

[Garulfo]

[...]
Voilà un point qui m'enchante en POO. On part d'une analyse qui descend jusqu'aux diagrammes de classe. Et les solutions exemples traités en UML semblent tellement parfait qu'on se croit dans un rêve.

Je pense que tu fais des cauchemards alors
Ok je me moque un peu. UML c'est comme tout : on peut avoir du bon travail et de la merde. Sauf que «*s'arrêter » aux diagrammes de classe ? Ce n'est pas allé bien loin : quid des diagrammes de séquences, d'activité etc. De plus, UML aura toujours une limitation qui va avec sa souplesse : une sémantique mal définie. On appelle ça dans mon domaine une méthode molle — analogie avec la dualité science molle/dure —. Ça a des avantages mais aussi des désavantages. Lorsque les interprétations peuvent différer sur le comportement de certains diagrammes, c'est dérangeant. En tout cas…

[Keihilin]

Ça a des avantages mais aussi des désavantages. Lorsque les interprétations peuvent différer sur le comportement de certains diagrammes, c'est dérangeant. En tout cas…

+1

D'ailleurs je trouve que l'utilisation réelle qui est faite d'UML est représentative de ce problème.

Si je prend les 10 dernières entreprises dans lesquelles je suis intervenu, 8 utilisaient UML, mais seulement 3 dans une optique de conception, les 5 autres l'utilisaient dans un but de documentation, donc les différents diagrammes étaient réalisés en fin de projet et à partir du code.

[Hephaistos007]

+1

D'ailleurs je trouve que l'utilisation réelle qui est faite d'UML est représentative de ce problème.

Si je prend les 10 dernières entreprises dans lesquelles je suis intervenu, 8 utilisaient UML, mais seulement 3 dans une optique de conception, les 5 autres l'utilisaient dans un but de documentation, donc les différents diagrammes étaient réalisés en fin de projet et à partir du code.

Ce que tu cites, c'est les différents usages d'UML dans un projet. Ce dont parlais Garulfo c'est le manque de sémantique précise d'UML. On appelle ça dans mon domaine une méthode semi-formelle. Pas facile de procéder à des analyses automatique et des preuves sur des diagrammes UML par exemple.

[Keihilin]

Ce que tu cites, c'est les différents usages d'UML dans un projet. Ce dont parlais Garulfo c'est le manque de sémantique précise d'UML.

A mon sens cette dualité d'utilisation est justement due à ce manque de sémantique et de formalisme.

Garulfo parle des interprétations qui peuvent différer sur certains diagrammes, et c'est justement un frein à l'utilisation formelle d'UML pour la conception.

Pour la documentation, l'ambiguïté sur certains diagrammes peut être levée en consultant le code...

[souviron34]

Pour la documentation, l'ambiguïté sur certains diagrammes peut être levée en consultant le code...

ce qui retire une part non négligeable de l'intérêt supposé d'UML

[Keihilin]

ce qui retire une part non négligeable de l'intérêt supposé d'UML

Clairement. Mais cela illustre justement ce à quoi mènent les faiblesses sémantiques d'UML.

[chaplin]

Je reprend:

en POO. On part d'une analyse qui descend jusqu'aux diagrammes de classe

Sauf que «*s'arrêter » aux diagrammes de classe ? Ce n'est pas allé bien loin

Les diagrammes de classe sont traités au chapitre 8 d'un bouquin traitant d'UML2 et c'est le dernier chapitre.
L'établissement des diagrammes de classe est le stade ultime avant le codage pur et simple, mais je n'oublie pas l'aspect iterratif .

Je pense que tu fais des cauchemards alors

Exact, j'ai horreur du flou, car les solutions les plus efficaces sont les plus élégantes, je veux dire par là que le seul plaisir que j'éprouve dans le développement c'est de faire du beau code. Je suis peut être épucurien, mais je constate que les esprits tordus font du code tordu, j'ai pas dit que je codais parfaitement, mais ces diagrammes UML m'appaisent dans leur "beauté" par rapport aux horreurs que j'ai pu voir.

Edit:
Par efficace, il faut comprendre que les utilisateurs changent en permanence d'avis et la POO offre une souplesse dans l'adaptation d'un code que je n'entrevois pas dans un langage procédural, mais je ne doute pas que d'autres y trouvent leur compte et tant mieux pour eux, c'est qu'ils sont très bon .

[Garulfo]

Les diagrammes de classe sont traités au chapitre 8 d'un bouquin traitant d'UML2 et c'est le dernier chapitre.
L'établissement des diagrammes de classe est le stade ultime avant le codage pur et simple, mais je n'oublie pas l'aspect iterratif .

Sur l'aspect statique ok.
Mais ce n'est pas le stade ultime.
Et le fait que ce soit le dernier chapitre d'un livre n'en fait pas une preuve... mais j'aime beaucoup l'argument

Exact, j'ai horreur du flou, car les solutions les plus efficaces sont les plus élégantes, je veux dire par là que le seul plaisir que j'éprouve dans le développement c'est de faire du beau code. Je suis peut être épucurien, mais je constate que les esprits tordus font du code tordu, j'ai pas dit que je codais parfaitement, mais ces diagrammes UML m'appaisent dans leur "beauté" par rapport aux horreurs que j'ai pu voir.

J'ai bien plus vu de l'horreur avec UML que de la beauté. Mais bon je comprend le principe. Attention au terme épicurien: c'est un des termes les plus déformés de son sens premier qui existe, mais là c'est pas si pire.

Edit:
Par efficace, il faut comprendre que les utilisateurs changent en permanence d'avis et la POO offre une souplesse dans l'adaptation d'un code que je n'entrevois pas dans un langage procédural, mais je ne doute pas que d'autres y trouvent leur compte et tant mieux pour eux, c'est qu'ils sont très bon .

Tu nous poses une définition claire. Je pense cependant que tu confonds spécification, modélisation et langage. La modélisation peut être claire, propre, modulaire etc. qu'elle soit entrepris avec une approche OO, par frame, par analyse structurée et j'en passe. Ne confonds pas non plus UML utilisé comme outil de spécifications (conception externe) et UML utilisé comme outil de modélisation de conception interne. Un diagramme de classe peut servir à trois choses par exemple: donner des indications sur les entités dans le monde réel; expliciter le modèle de données d'un point de vue abstrait; fournir une architecture du programme. Ce sont pourtant bien trois artefacts différents. Ils sont potentiellement différents. De plus, on pourrait utiliser une approche par frame en analyse des besoins, spécifier avec un langage de spécification formelle, et écrire la conception avec UML.

Donc, pour résumer, ce n'est pas l'outil mais l'artisan qui fait la beauté du modèle. ^_^

[Garulfo]

A mon sens cette dualité d'utilisation est justement due à ce manque de sémantique et de formalisme.

Garulfo parle des interprétations qui peuvent différer sur certains diagrammes, et c'est justement un frein à l'utilisation formelle d'UML pour la conception.

Pour la documentation, l'ambiguïté sur certains diagrammes peut être levée en consultant le code...

Nous sommes bien d'accord.

Consulter le code alors qu'on a un modèle est contraire au principe de GL. En fait, c'est même signe que notre modèle est mauvais. Cependant tu as raison, c'est ce qui se fait.

En notre époque où les méthodes formelles deviennent de plus en plus présentes en industrie, et de plus en plus nécessaire, c'est à mon avis une évolution « naturelle ». Certains travaux ont pour but de donner un sens formel à des artefacts d'UML.
myweb.lsbu.ac.uk/~mwalusgw/collections.pdf
www.springerlink.com/index/3NWPB0U2H9PJFN0X.pdf
http://wiki.di.uminho.pt/twiki/pub/R...l2informal.pdf
www.springerlink.com/index/3HKX11W2JTLGUPF8.pdf
www.ub.utwente.nl/webdocs/ctit/1/00000026.pdf
www.springerlink.com/index/M626M42J6159U745.pdf

Ça se vois-tu que c'est mon domaine de recherche?

Attention, je n'ai rien contre UML. C'est un outil qui, bien utilisé, s'avère efficace et même élégant (d'accord avec Chaplin). En fait, je pense aussi qu'UML a été une milestone à une époque. Maintenant il faut aller plus loin c'est tout.

[chaplin]

Sur l'aspect statique ok.
Mais ce n'est pas le stade ultime.

On part des uses case, pour établir les diagrammes de séquence système qui seront affinés pour obtenir les classes.
Les diagrammes d'interactivité/collaboration servent à défnir les méthodes de classes.
Les diagrammes d'état permettent de définir des variables d'état (une partie des attributs) voir des classes d'état.

Au final, grâce à cette étude, il faut se décider sur quel langage travailler, ensuite sur quel framework et cette dernière étape va énormément influencer sur le diagramme de classe final car il faudra tenir compte de l'architecture utilisée (framework).

On est d'accord que c'est la théorie, car le plus difficile est d'établir la première ébauche des classes. Il faut peut être pas oublier qu'UML est basé sur des travaux de recherche sur la POO.

Dans Delphi par exemple à partir de la version 2006, il est possible d'avoir les diagrammes de classe à partir du code donnant une vision beaucoup plus claire sur l'architecture d'un programme ou d'un composant. Ici, il s'agit de faire de la rétroconception ou reverse engineering en anglais, j'utilise juste le terme approprié. Avec les outils de refactoring, on peut facilement travailler sur les classes.

Attention au terme épicurien: c'est un des termes les plus déformés de son sens premier qui existe, mais là c'est pas si pire.

L'épicurisme est axé sur la recherche d'un bonheur et d'une sagesse dont le but ultime est l'atteinte de l'ataraxie.

ataraxie: (du grec ἀταραξία, ataraxía signifiant « absence de troubles ») apparaît d'abord chez Démocrite et désigne la tranquillité de l’âme résultant de la modération et de l’harmonie de l’existence.

Au vue de cette définition, je pense ne pas me tromper dans l'emploi du mot épicurien.

Je ne cherche pas à convaincre sur la POO, Je trouve la notation UML très élégante à condition que le concepteur est les idées clairs. Un des objectifs d'UML était de pouvoir faire communiquer des informaticiens avec des non informaticiens et les diagrammes de séquences sont des moyens largement accessibles pour un public novice surtout pour parler de l'aspect métier.

Je pense cependant que tu confonds spécification, modélisation et langage.

UML:Unified Modelling Langage
Un de ses interêt est de se départir du langage, au sens, surtout accomodé pour les langages répondant au paradigme objet. On parle de diagramme de classe, c'est bien un vocabulaire des langages Objets.
Les spécifications sont décris dans les uses case au travers des scénarios, où alors j'ai pas compris la définition du mot spécification.

EDIT:

Un diagramme de classe peut servir à trois choses par exemple: donner des indications sur les entités dans le monde réel; expliciter le modèle de données d'un point de vue abstrait; fournir une architecture du programme. Ce sont pourtant bien trois artefacts différents. Ils sont potentiellement différents

J'avais fait un mois de génie logiciel, et justement la barrière était floue, au sens ou on passe du concept à la modélisation, c'est la partie la plus difficile. Mais les deux derniers cas, sont bien la concrétisation du problème, sauf que dans un logiciel, il peut y avoir plusieurs centaines de classe, donc on se balade sur un damier pour avoir tel ou tel aspect de l'architecture objet.

Diagramme de classe => classes, associations, interfaces, attributs, opérations, généralisations

J'essaye juste de comprendre UML, et si ça peu eclaircir la lanterne à certains, tant mieux. S'il faut faire des tableaux en Excel uml??, ou faire une BDD, c'est SQL au bout du compte, donc pas grand chose à voir avec l'objet même s'il y a une ribambelle d'outils pour mapper les tables. Les SGBDR existent depuis plus longtemps que la POO donc il faut s'y adapter.

[hegros]

... Ne confonds pas non plus UML utilisé comme outil de spécifications (conception externe) et UML utilisé comme outil de modélisation de conception interne. Un diagramme de classe peut servir à trois choses par exemple: donner des indications sur les entités dans le monde réel; expliciter le modèle de données d'un point de vue abstrait; fournir une architecture du programme. Ce sont pourtant bien trois artefacts différents. Ils sont potentiellement différents. De plus, on pourrait utiliser une approche par frame en analyse des besoins, spécifier avec un langage de spécification formelle, et écrire la conception avec UML.

Donc, pour résumer, ce n'est pas l'outil mais l'artisan qui fait la beauté du modèle. ^_^

Pour revenir sur cette histoire d'objet naturel parce que effectivement il y a plusieurs auditions ou lectures. Tu cites un diagramme de classe qui fournit des indications sur des entités du monde réel c'est un modèle de niveau conceptuel à ce stade, dans une approche OO, ces entités sont potentiellement des classes logicielles candidates que l'on implémentera même si certaines finiront par disparaitre et d'autres à apparaître.

C'est à ce sens que 'plus naturel' ne me semble pas un mauvais argument. On passe naturellement du niveau conceptuelle à l'implémentation comme avec l'exemple de la lettre à la poste.

Il ne pourra pas se répandre d'autres langages que UML qui ne soit pas graphique c'est impossible à intégrer dans des équipes de développement et il faut bien faire de la spécification, de l'analyse et de la conception. Chacun a des objectifs différents avec UML à ce sens il offre beaucoup de possibilité et de perspective quand il est utilisé dans un cadre méthologique c'est mieux sinon on fait des modèles jetables parce que pour la documentation c'est beaucoup plus compliqué (à mon sens c'est très peu adapté)

[Garulfo]

[...]
Les spécifications sont décris dans les uses case au travers des scénarios, où alors j'ai pas compris la définition du mot spécification.[...]

Visiblement tu ne sais pas exactement ce qu'est une spécification effectivement. Mais n'en soit pas vexé, tu es étudiant non ? Tu as donc le temps d'apprendre. Je ne dis pas que tu as tout faux non plus. La spécification définie le comportement externe attendu. Les cas d'utilisation ne sont pas des spécifications. Ils ne définissent qu'une liste de besoin fonctionnel avec des scénarios. Mais ils manquent de détails. Il faut entre autre définir les entités en jeu, leurs descriptions, les flux de données externes etc. Le diagramme de classe peut servir à des parties de cela. Mais on parle, ici d'un comportement externe. Or, toi tu parles du DC comme architecture d'un point de vue interne.

Bon en tout cas, ça sort du sujet, et malheureusement je n'ai pas le temps de détailler… de manière amusante, il faut que je revoie et finisse la préparation de mon cours de la session prochaine : analyse des besoins et spécification

[chaplin]

Je suis un eternel étudiant .

L'exemple de Keihilin illustre bien qu'on peut utiliser UML de différente manière:

Si je prend les 10 dernières entreprises dans lesquelles je suis intervenu, 8 utilisaient UML, mais seulement 3 dans une optique de conception, les 5 autres l'utilisaient dans un but de documentation, donc les différents diagrammes étaient réalisés en fin de projet et à partir du code.

.. selon qu'on est plus ou moins à l'aise avec UML dans un cadre professionnel voir pas du tout, donc connaître un peu ou pas du tout UML ne nuit pas à la programmation.

Ils ne définissent qu'une liste de besoin fonctionnel avec des scénarios.

Je dirais qu'un use case définit un besoin fonctionnel au travers de scénarios qui ne sont que des séquences d'actions avec des conditions, c'est à dire qu'en fonction de celle-çi on aura des scénarios différents.

Si on poste une enveloppe, c'est un besoin fonctionnel, une action, mais qui est finalement un use case.

[hegros]

Que du théorique. Spécifications et besoins c'est pareil à 80%.


La seule différence qui a est que pour la définition des besoins on va quand même faire une analyse de la valeur et comparer/évaluer des scénarios ensuite c'est de la spécification.

La différence existe dans les cycles en cascades...

[chaplin]

Hegros, que penses tu de mes propos, j'ai pas l'impression d'être à côté de la plaque sans aller non plus dans le détail. Il existe 13 types de diagramme en UML, mais combien en utilise-t-on réellement ?

[hegros]

Chaplin il y a des éléments intéressants dans lesquels on se rejoint, d'autres assez détaillés reste relativement flou dans une telle discution car les mots sont les premiers ennemis des informaticiens lorsqu'il n'y a aucune terminologie et glossaire/vocabulaire définit en commun (d'une équipe à l'autre on pourrait avoir des définitions différentes sur un même domaine d'un forum à l'autre aussi )

Pour uml, j'utilise tous les diagrammes dont j'ai besoin donc cela peut-être les 13 ensuite comme dis précédemment c'est la démarche de développement qui compte le plus et c'est à l'assurance qualité de définir ce qui doit être produit fi des modèles jetables. Avec UML cela prends du temps à modèliser donc quand le résultat ne fournit pas de valeur ajoutée mais bon c'est également vrai avec d'autres langages ou méthodes il faut donc trouver un équilibre enfin c'est mon avis

[Garulfo]

Que du théorique. Spécifications et besoins c'est pareil à 80%.[...]

Non pas vraiment. Et c'est aussi vrai sur le plan industriel. La spécification présente un ensemble de solutions qui ont pour but de résoudre un ensemble de besoin. Que ce soit les différentes normes, la littérature ou même l'utilisation industriel d'entreprise comme CGI, Matra, Siemens, Alsthom, Hydro Qc, etc. tous font cette distinction quand même.

Si tu trouves une référence qui dit le contraire, je serais intéressé — et vraiment intéressé — de la voir.

Je suis un eternel étudiant .
[...]
Je dirais qu'un use case définit un besoin fonctionnel au travers de scénarios qui ne sont que des séquences d'actions avec des conditions, c'est à dire qu'en fonction de celle-çi on aura des scénarios différents.

Si on poste une enveloppe, c'est un besoin fonctionnel, une action, mais qui est finalement un use case.

Je le suis aussi. Mais sinon en quoi ce que tu dis infirme ce que je dis ? Je suis assez d'accord. Un use-case n'est donc pas une spécification.

[hegros]

La spécification présente un ensemble de solutions qui ont pour but de résoudre un ensemble de besoin.

Les solutions ont les élabore en fin de phase d'analyse des besoins c'est comme cela que le définit SDMS (méthodologie de développement de système) utilisé notamment par la bnp et d'autres grands groupes.

Toujours dans SDMS on a une phase de spécification et à ce stade on a déjà en principe retenu depuis longtemps la solution retenue puisque nous avons déjà fais un choix d'architecture ou de progiciel.

Dans ce sens la spécification ne fait que de se focaliser et détaillé la solution préconisé pendant l'expression des besoins. Quand à l'expression des besoins c'est orienté sur l'analyse de la valeur et des délais.

Partant de ta remarque SDMS mélange spécification et expression des besoins (puisqu'on décrit des solutions pendant la pahse de définition des besoins) bien qu'elle les distingue dans le phasage étonnant non ?

[Garulfo]

Les solutions ont les élabore en fin de phase d'analyse des besoins c'est comme cela que le définit SDMS (méthodologie de développement de système) utilisé notamment par la bnp et d'autres grands groupes.

Toujours dans SDMS on a une phase de spécification et à ce stade on a déjà en principe retenu depuis longtemps la solution retenue puisque nous avons déjà fais un choix d'architecture ou de progiciel.

Dans ce sens la spécification ne fait que de se focaliser et détaillé la solution préconisé pendant l'expression des besoins. Quand à l'expression des besoins c'est orienté sur l'analyse de la valeur et des délais.

Partant de ta remarque SDMS mélange spécification et expression des besoins (puisqu'on décrit des solutions pendant la pahse de définition des besoins) bien qu'elle les distingue dans le phasage étonnant non ?

En quoi ma remarque mène à ça ? Je dis juste que la spécification n'est pas la liste des besoins — ni l'expression. Ce sont deux éléments bien distinct.
Il me semble que tu me fais dire des trucs que je ne dis pas ou que tu dénatures mes propos. L'autre possibilité étant que je t'ai mal compris.

Notons bien que je ne connais pas ce que tu nommes SDMS spécifiquement. Cependant, si ce document dit que la spécification d'un système vient après le choix de son architecture, alors ce n'est pas la spécification des besoins dans le sens utilisée en général dans le GL (voir IEEE830-1998, IEEE1233-1998 par exemple, mais je peux te donner une pléthore d'auteur du domaine et de norme militaire ou gouvernementale aussi). Maintenant tout document peut choisir sa nomenclature.
IEEE620.12-1990 nous donne

Specification: A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied.

Tu vois qu'il y a plus que les besoins. Maintenant il y a aussi la spécification des besoins (requirement specification) qui est plus limités aux besoins primaires. Tu parlais de ça peut-être ?

Quand tu dis « dans ce sens la spécification ne fait que de se focaliser et détailler la solution préconisée pendant l'expression des besoins » je suis complètement d'accord. La spécification détaille la solution préconisée. Pour être plus précis, la spécification détaille le comportement externe de la solution préconisée pendant l'expression des besoins. Mais la spécification ne correspond pas à la liste des besoins (ni donc à leur expression). C'est, comme tu l'as bien dit correctement, le détail du comportement externe de la solution devant remplir les besoins. Les besoins sont décrits après la phase d'élicitation (ou forage dans un meilleur français) sous forme de langage naturelle la plupart du temps. La spécification pointe du doigt une solution externe acceptable, et un comportement, laissant libre cours à l'ensemble des solutions internes vérifiant le comportement externe ainsi spécifié.

Si la spécification et l'expression des besoins était la même chose, alors toute solution devrait avoir exactement le même comportement externe. Ce qui n'est pas le cas dans la grande majorité des cas.

Je te proposerais de continuer cette discussion en MP ou bien sur un autre fil de discussion ^_^ Je me trompe peut-être, mais je suis prof de génie logiciel et je travaille aussi en collaboration avec l'industrie. Je pourrais quand même dire des conneries depuis 10 ans je te l'accorde

[hegros]

Notons bien que je ne connais pas ce que tu nommes SDMS spécifiquement. Cependant, si ce document dit que la spécification d'un système vient après le choix de son architecture, alors ce n'est pas la spécification des besoins dans le sens utilisée en général dans le GL (voir IEEE830-1998, IEEE1233-1998 par exemple...

Le phasage c'est définition des besoins, choix architecture, spécification externe, spécification interne,....