Discussion :

[ox@na]

Bonjour,

J'ai deux questions générales auxquelles je ne peux répondre!!!!

1) Dans quels cas la rétention d'information ne devrait pas être appliquée
aux relations entre modules ? un exemple est le bien venu- Merci.
2) Le changement est partie intégrante du processus de construction logiciel.
Quel est le lien entre le critère de continuité modulaire et l'objectif général
d'extensibilité? avec un exemple si possible - merci.

je vous remercie tous en avance.

[Patriarch24]

Ca sent les question d'examens ça non ?

1) Dans quels cas la rétention d'information ne devrait pas être appliquée aux relations entre modules ? un exemple est le bien venu - Merci.

Si je comprends bien la question, il ne devrait jamais exister de cas ou les informations privées à un module doivent en sortir. Cela casse justement la modularité.

2) Le changement est partie intégrante du processus de construction logiciel.
Quel est le lien entre le critère de continuité modulaire et l'objectif général
d'extensibilité? avec un exemple si possible - merci.

Moi pas comprendre ce que question signifier : critère de continuité modulaire ????

[pseudocode]

Ca sent les question d'examens ça non ?

a priori oui ---> voir ici

Bon ca empeche pas de répondre aux questions...

Premiere remarque, c'est avec ce genre de question que l'on degoute les gens de la conception OO. Genre "l'objet c'est tres complexe, toute une theorie mathematique, vous pouvez pas comprendre".

1) Dans quels cas la rétention d'information ne devrait pas être appliquée aux relations entre modules ? un exemple est le bien venu - Merci.

Réponse: Lorsque les modules communiquent par partage de données.

Exemple: Les architectures Pipe & Filter (genre une chaine de codec)

Le changement est partie intégrante du processus de construction logiciel.

(Faux: le changement est partie intégrante de l'incompetence des parties prenantes a savoir ce qu'elles veulent, mais passons...)

Quel est le lien entre le critère de continuité modulaire et l'objectif général d'extensibilité? avec un exemple si possible - merci.

Réponse: La continuité modulaire est assurée si des petites modifications de spécifications n'amènent pas à revoir l'ensemble de l'architecture (les modifications ne doivent affecter que quelques modules)

exemple : changement de constantes ou de Look'n Feel
contre-exemple: changement des besoins ou des scenarii

[Nip]

Premiere remarque, c'est avec ce genre de question que l'on degoute les gens de la conception OO. Genre "l'objet c'est tres complexe, toute une theorie mathematique, vous pouvez pas comprendre".

Ca je suis bien d'accord, je ne comprends meme pas les questions

Le changement est partie intégrante du processus de construction logiciel.

(Faux: le changement est partie intégrante de l'incompetence des parties prenantes a savoir ce qu'elles veulent, mais passons...)

Euh ca je suis moins d'accord. Il n'y a qu'a regarder en pratique ce que donnerait un processus de construction logiciel sans changement: waterfall, pour ne citer que lui et qui bien sur ne marche pas et ne marchera jamais . C'est pas de l'incompetence, c'est juste ...toute notre vie de developpeur .

[pseudocode]

Euh ca je suis moins d'accord. Il n'y a qu'a regarder en pratique ce que donnerait un processus de construction logiciel sans changement: waterfall, pour ne citer que lui et qui bien sur ne marche pas et ne marchera jamais . C'est pas de l'incompetence, c'est juste ...toute notre vie de developpeur .

Je sais, mais parfois c'est bon de laisser sortir son trop plein de frustration. Comme un certain chef de projet qui a fait une legere modif de spec, au bout de 6 mois de dev: "il faudrait qu'il n'y ai plus une seule IHM, mais deux. La deuxieme déportée a travers le réseau"

[Matthieu Brucher]

Ah, ça, ça sent les specs bien figées, une archi définie bien trop en amont et pas trop capable de subir ces chagements. Je te comprends, pseudocode, et je compâtis !