Conception

Bonjour à tous,

depuis que j'ai commencé à programmer tout seul dans mon coin, à chaque
fois que je crée une classe, je pars directement sur la programmation de
ladite classe, et donc inévitablement je perds du temps à la modifier parce
que je n'ai pas assez réfléchi sur sa conception.

Je me dis qu'il est donc grand temps de passer plus de temps à réfléchir
sur la classe pour améliorer la prog en elle-même.

Je voulais donc savoir comment vous procédez, et sur quels critères (qui
appelle la classe, avec quelles autres classes elle interagit...) vous vous
basez sur le papier pour définir votre classe.

Et si vous aviez des liens là dessus, j'avoue que je suis preneur...

Merci d'avance

Mike

Dans le déroulement du cycle de développement logiciel, ceci s'appelle la phase
de conception. Aujourd'hui c'est UML le standard.
Il faut faire, au moins, un diagramme de classes pour montrer les dépendances
entre ces classes (association, agrégations, héritage). Faute de ce diagramme
(et surtout de cette réflexion) tu vas passer ton temps à faire et défaire des
classes si tu ne réfléchis pas globalement à l'a conception de ton logiciel. Il
existe des outils pour effectuer la conception UML (en général très chers). Il
existe des versions d'évaluation gratuites (http://www.borland.fr/together/).

Jacti

Je me dis qu'il est donc grand temps de passer plus de temps à réfléchir
sur la classe pour améliorer la prog en elle-même.

Je voulais donc savoir comment vous procédez, et sur quels critères (qui
appelle la classe, avec quelles autres classes elle interagit...) vous
vous
basez sur le papier pour définir votre classe.

Pas facile de consacrer le temps que l'on veut à bien concevoir chacune de
ses classes... Surtout que moi même j'ai bcp de mal à tout bien identifier
ce qu'il faut lors de l'analyse UML. Sur la papier c'est beau c'est nickel,
mais une fois qu'on passe à la réalisation, y'a toujours un truc auquel t'as
pas pensé, et souvent je me demande comment c'était possible d'y penser sans
se plonger à la réalisation.
Moi je suis débutant aussi, mais j'ai amélioré ma "conception bonne du 1°
coup" sans pour autant consacrer un temps démesuré à l'analyse depuis que:
- je commence par choisir dans quel module sera ma classe à partir du graphe
des dépendances de mes modules (ça évite de découvrir que tu viens de coder
des références croisées...)
- je me crée un programme (uniquement sur papier parfois) de test / exemple
d'utilisation (comme si la classe était déjà prête) afin de bien réfléchir à
comment je vais l'utiliser / montrer son utilisation (principe du
développement orienté par les tests, assez contraignant, mais très payant en
ce qui me concerne, surtout au moment de retouches / évolutions)
- à décrire son comportement sous forme de commentaires avant de s'attaquer
à sa réalisation (exprimer en français l'utilisation / le fonctionnement de
ta classe permet parfois de faire ressurgir des problèmes / incohérences /
inutilités)
- pour les classes sérialisées, je commence par rédiger un XML tel que
j'aimerais le voir sur le disque à la fin. Ca aide à bien décomposer /
structurer la hiérarchie des classes je trouve (plus pratique que l'UML à
mon avis pour réfléchir sur l'aggregation).
L'UML je m'en sert pour visualiser les dépendances (très utile à mon avis),
la hiérarchie des classes biensûr, et aussi les cardinalités. Je modélise
pas les fonctions / variables membres en UML, doxygen est là pour ça (j'ai
pas d'outil spécialisé genre Rational Rose, je travaille avec Dia).
Voilà ce que j'ai tiré de ma courte expérience. En espérant t'aider.

--
Aurélien REGAT-BARREL

Aurelien REGAT-BARREL wrote:

Je me dis qu'il est donc grand temps de passer plus de temps
à réfléchir sur la classe pour améliorer la prog en
elle-même.

Je voulais donc savoir comment vous procédez, et sur quels
critères (qui appelle la classe, avec quelles autres classes
elle interagit...) vous vous basez sur le papier pour
définir votre classe.

Pas facile de consacrer le temps que l'on veut à bien
concevoir chacune de ses classes... Surtout que moi même j'ai
bcp de mal à tout bien identifier ce qu'il faut lors de
l'analyse UML. Sur la papier c'est beau c'est nickel, mais une
fois qu'on passe à la réalisation, y'a toujours un truc auquel
t'as pas pensé, et souvent je me demande comment c'était
possible d'y penser sans se plonger à la réalisation.

Plusieurs choses peuvent aider ici. Essaie, par exemple, de
dérouler des scénarios en jouant à être les classes. Et rien ne
remplace une bonne revue de la conception -- tout le monde
oublit quelque détails de temps en temps, mais c'est assez rare
que deux personnes oublissent tous les deux exactement les mêmes
choses.

Moi je suis débutant aussi, mais j'ai amélioré ma "conception
bonne du 1° coup" sans pour autant consacrer un temps démesuré
à l'analyse depuis que:

- je commence par choisir dans quel module sera ma classe à
partir du graphe des dépendances de mes modules (ça évite de
découvrir que tu viens de coder des références croisées...)

- je me crée un programme (uniquement sur papier parfois) de
test / exemple d'utilisation (comme si la classe était déjà
prête) afin de bien réfléchir à comment je vais l'utiliser /
montrer son utilisation (principe du développement orienté par
les tests, assez contraignant, mais très payant en ce qui me
concerne, surtout au moment de retouches / évolutions)

C'est une bonne démarche une fois qu'on connaît la rôle et la
responsabilité de la classe. De toute façon, il va falloir des
tests unitaires. Mais pour écrire les tests unitaires (ou des
exemples d'utilisation), il faut d'abord bien savoir ce que la
classe doit faire, et ce qu'elle ne doit pas faire.

- à décrire son comportement sous forme de commentaires avant
de s'attaquer à sa réalisation (exprimer en français
l'utilisation / le fonctionnement de ta classe permet parfois
de faire ressurgir des problèmes / incohérences / inutilités)

Au minimum : la rôle et les responsabilités de la classe dans
l'application. (Je parle ici des classes applicative ; définir
la rôle de quelque chose comme std::vector n'a pas forcement
beaucoup de sens.) Une signalisation des modèles de conception
concernés est en général aussi assez intéressant. Éventuellement
aussi des dépendances : les autres classes ou des autres
sous-systèmes dont la classe se sert. Et les invariantes, bien
que souvent, ça se relève plutôt de la documentation interne.
(C-à-d que c'est à l'implémentation de la classe, et non à
son utilisateur, de les maintenir.)

Au niveau des fonctions, il ne faut jamais commencer à écrire du
code sans avoir précisé le contrat -- ce que la fonction doit
faire, et ce qu'elle ne fait pas. Les pré- et post-conditions
aident ici, mais ne sont pas toujours suffisamment en soi. (En
revanche, il faut absolument préciser le domaine des paramètres,
ainsi que la sémantique dans le cas des valeurs spéciales, du
genre pointeur NULL.)

- pour les classes sérialisées, je commence par rédiger un XML
tel que j'aimerais le voir sur le disque à la fin. Ca aide à
bien décomposer / structurer la hiérarchie des classes je
trouve (plus pratique que l'UML à mon avis pour réfléchir sur
l'aggregation).

Ça me semble plutôt un détail de l'implémentation. Je me sers
souvent de l'idiome du pare-feu de compilation, et je me permets
d'ajouter ou d'enlever des membres données à volenté.

Une exception, évidemment, c'est quand la rôle de la classe,
c'est de représenter un enregistrement, ou un ensemble de
données semblable. Dans les applications commerciales, ce n'est
pas rare de commencer par la schéma de données dans la base de
données. (J'ai même l'impression que ça arrive trop souvent --
les schémas doivent dépendre aussi au moins en partie de ce
qu'on veut faire.)

L'UML je m'en sert pour visualiser les dépendances (très utile
à mon avis), la hiérarchie des classes bien sûr, et aussi les
cardinalités. Je modélise pas les fonctions / variables
membres en UML, doxygen est là pour ça (j'ai pas d'outil
spécialisé genre Rational Rose, je travaille avec Dia). Voilà
ce que j'ai tiré de ma courte expérience. En espérant t'aider.

Ne mésestîme pas l'utilité des scénarios. Personnellement, je
les trouve d'une importance primordiale pour s'assurer que la
conception tient debut. Par la suite, ils sont aussi intéressant
pour celui qui veut comprendre la dynamique de ton programme.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jacti wrote:

depuis que j'ai commencé à programmer tout seul dans mon
coin, à chaque fois que je crée une classe, je pars
directement sur la programmation de ladite classe, et donc
inévitablement je perds du temps à la modifier parce que je
n'ai pas assez réfléchi sur sa conception.

Je me dis qu'il est donc grand temps de passer plus de temps
à réfléchir sur la classe pour améliorer la prog en
elle-même.

Je voulais donc savoir comment vous procédez, et sur quels
critères (qui appelle la classe, avec quelles autres classes
elle interagit...) vous vous basez sur le papier pour
définir votre classe.

Et si vous aviez des liens là dessus, j'avoue que je suis
preneur...

Dans le déroulement du cycle de développement logiciel, ceci
s'appelle la phase de conception. Aujourd'hui c'est UML le
standard.

Attention : l'UML, c'est un langage qui sert à exprîmer la
conception, de la même façon que le C++ est un langage qui
exprîme l'implémentation. C'est aussi facile de faire une
mauvaise conception en UML que de faire une mauvaise
implémentation en C++. Savoir faire de jolis dessins ne sert à
rien sans savoir ce qu'il faut y mettre.

D'un certain côté, l'UML, c'est encore pire que le C++, parce
qu'il n'y a pas de problème à le faire compiler, et on ne
l'exécute jamais. Ce que le C++ punit d'un core dump, l'UML
laisse passer comme une lettre à la poste.

En revanche, comme tu dis, c'est le standard. Il n'y a pas (ou
plus) de guerres de langages dans le domaine de la conception.

Il faut faire, au moins, un diagramme de classes pour montrer
les dépendances entre ces classes (association, agrégations,
héritage). Faute de ce diagramme (et surtout de cette
réflexion) tu vas passer ton temps à faire et défaire des
classes si tu ne réfléchis pas globalement à l'a conception de
ton logiciel.

Voilà le mot clé : une reflexion globale. L'UML est le langage
dans lequel on exprîme le résultat de cette reflexion ; il n'est
pas la reflexion.

Il existe des outils pour effectuer la conception UML (en
général très chers). Il existe des versions d'évaluation
gratuites (http://www.borland.fr/together/).

Qu'est-ce qu'il vaut ?

J'ai actuellement l'utilisation d'une version officielle de
Together ; jusqu'ici, il faut dire que je préfère de loin
Rational Rose, mais il faut dire qu'ils n'ont acheté le projet
qu'une fois la conception finie -- je n'ai donc pas pu
l'utiliser où il l'aurait fallu. Ce qui colore probablement mon
avis.

Note aussi que ce soit Together ou Rational Rose, il s'agit d'un
produit extrèmement complet et complexe, avec énormement de
facilités de customisation. Il faut donc un certain temps pour
en devenir réelement efficace ; que l'utilisation dépasse ce
qu'on pourrait faire avec un outil simple de dessin. Et qu'une
fois que tu le maîtrises, et que tu t'y sens à l'aise, qu'il
faut revenir en arrière et rélire la doc, pour ajouter des
fonctionnalités supplémentaires à ton répertoire.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

L'UML je m'en sert pour visualiser les dépendances (très utile
à mon avis), la hiérarchie des classes bien sûr, et aussi les
cardinalités. Je modélise pas les fonctions / variables
membres en UML, doxygen est là pour ça (j'ai pas d'outil
spécialisé genre Rational Rose, je travaille avec Dia). Voilà
ce que j'ai tiré de ma courte expérience. En espérant t'aider.

Ne mésestîme pas l'utilité des scénarios. Personnellement, je
les trouve d'une importance primordiale pour s'assurer que la
conception tient debut. Par la suite, ils sont aussi intéressant
pour celui qui veut comprendre la dynamique de ton programme.

Effectivement je m'en sers jamais. Faut dire qu'on a survolé ça à l'école,
et c'était pour montrer que quand le bonhome clic sur OK, ben ça fait Ok,
une débilité absolue selon moi.
J'ai pas été sensibilisé sur cette utilisation des scénari avec les classes
et je réalise que c'était un peu ce que j'essayais de faire dans mes
commentaires "en français" (expliquer l'utilisation type de la classe) et
c'est ce qui m'avais permis de trouver des nomalies.
Merci du conseil ;-)

--
Aurélien REGAT-BARREL

Moi je vous conseil d'essayer Entreprise Architect de chez sparxsystems.
Je trouve ça carrément plus convivial que Rose et surtout beaucoup moins
cher. Je ne connais pas l'outil Borland.
JB