Discussion :

[funtix]

Hello,
En C existe t'il une méthode de conception pour éviter les problèmes ?

Quand je debute un projet, je commence par reflechir aux données et types que je vais manipuler. Tout mes efforts portent sur ca. Mais ca ne suffit pas...
En programmation objet, on se concentre sur les futurs objets, les interactions entre eux...
Le C est un language procedurale, est ce que ce sont les fonctions ou les données qui determine le devenir du programme...

Avez vous des liens, des livres ou des conseils a donner?
Merci

[hiko-seijuro]

Moi je fais plus ou moins du C objet de temps à autres sauf pour des routines précises. Je pense qu'il faut que tu t'adaptes à ce que tu veu faire. Si jamais c'est les données qui sont importante ou bien si c'est les opérations

[Emmanuel Delahaye]

En C existe t'il une méthode de conception pour éviter les problèmes ?

Oui

http://bien-programmer.blogspot.com/

[Lunixinclar]

Données ou fonctions? Les deux, Le C fonctionne aussi en approche objet.
Compiles le plus souvent possible, suis une bonne démarche de programmation, printtf est ton sensei. GTK+ est un bon exemple.

[koala01]

Salut,

Pour ce qui est de la logique purement procédurale (et on se comprend sur le fait que, meme en Orienté Objet, le corps d'une fonciton membre tombe dans ce cas de figure: une suite de choses à faire dans un ordre logique...) la méthode qui est, selon moi, la plus adaptée, et surtout la plus facile à tranfsormer en code par la suite (quel que soit le langage utilisé) est sans doute le =>nassichneiderman<=.

Bien que peu connue, elle présente l'énorme avantage de permettre la représentation logique des boucles et des tests, là où le flowchart se transforme en "plat de spagetti" dés que les boucles et/ou les tests commencent à s'imbriquer.

L'idée générale est de se dire que, hormis les test (de type "vrai faux" ou "à choix multiple") et les boucles, tout n'est jamais "qu'action", meme si on se prévoit la possiblité de représenter les appels à nos fonctions personnalisée de manière différente, et de regrouper ces "actions" dans l'ordre logique d'exéctution au sein d'une "pince" représentant la fonction que l'on crée.

Par exemple, l'algorithme de résolution d'une tour de hannoï en nassichneiderman pourrait ressemler à

Ou celui, non récursif, d'ajout d'un élément en fin de liste pourrait ressembler à

avec, bien entendu, les variables et les types qui vont bien avec

L'une des seules limites, qui vient plus de la difficulté que le programmeur a à s'assurer de la gestion correcte, est ce que l'on appelle la gestion de ruptures.

Mais en préparant le travail avec la méthode jackson et en traduisant le résultat obtenu sous forme de nassichneiderman (ce qui n'est pas bien compliqué), meme la gestion des ruptures devient un jeu d'enfant...

[EDIT] le nassichneiderman présente, en outre, l'avantage de permettre une "traduction automatique" en code (et ce, encore une fois, quel que puisse etre le langage de programmation envisagé), dés le moment où l'on a compris qu'il faut travailler par "colone"[/EDIT]

[Thierry Chappuis]

C'est la première fois que j'entend parler du nassichneiderman. Il faudra que je regarde ça un jour, mais je trouve tout de même l'utilisation de pseudo-code plus lisible pour la description des algorithmes.

Thierry

[koala01]

C'est la première fois que j'entend parler du nassichneiderman. Il faudra que je regarde ça un jour, mais je trouve tout de même l'utilisation de pseudo-code plus lisible pour la description des algorithmes.

Thierry

C'est un avis qui se vaut, si ce n'est que, tant qu'à commencer à écrire du code, pourquoi le faire en "pseudo", et non, directement dans le langage utilisé

A titre perso, je seul avantage que je trouve au pseudo code, c'est qu'il ne nécessite aucun dessin...

Mais, d'un autre coté, une fois que l'on est habitué au nassichneiderman (car, comme toute méthode d'algorithmie, il faut un "temps d'adaptation") il est aussi facile à traduire en code qu'un pseudo code et aussi "parlant" qu'un flowchart, le plat de spagetti en moins...

Tu remarqueras en outre au travers de ces deux exemples choisis que tu retrouves "simplement" sous forme graphique tout ce que tu pourrais retrouver dans un pseudo code

Ceci dit, c'est mon avis perso, et je ne forcerai jamais personne à y adhérer... mais je le partage

[HanLee]

A titre perso, je seul avantage que je trouve au pseudo code, c'est qu'il ne nécessite aucun dessin...

Il y a aussi le fait qu'en pseudo code tu peux te permettre des imprécisions, des mots flous, mais dont on comprend le principe, ce qui n'aurait pas été possible avec un vrai langage directement.

Sinon pour moi le nassichneiderman, c'est juste du pseudo code avec une présentation plus élaborée, plus visuelle, donc on comprend le sens plus rapidement.

[koala01]

Sinon pour moi le nassichneiderman, c'est juste du pseudo code avec une présentation plus élaborée, plus visuelle, donc on comprend le sens plus rapidement.

On peut le voir comme cela, mais avec un petit "plus":

Le problème du pseudo code, selon moi, c'est qu'on perd, comme pour n'importe quel autre langage, une dimention de compréhension...

Je ne parle, bien évidemment, pas de l'algorithme que tu crées pour ton usage personnel et que tu maîtrise à force d'y avoir pensé...(quoi, que, revenir dessus apres plusieurs mois risque de poser quelques difficultés )

Je parle de l'algorithme que tu récupères d'une source extérieure, qu'il te faut appréhender, comprendre et utiliser sans forcément disposer du moyen de contacter l'auteur de l'algorithme dans les délais impartis...

En effet, qu'il s'agisse d'un test "vrai faux" ou d'un "test à choix multiple", pour peu que le nombre d'instructions à exécuter de l'un ou de l'autre coté soit important, tu te retrouve avec une vision principalement "verticale" de la logique suivie et presque dans l'impossibilité de mettre les deux côtés "en parallelle"...

j'ai souvenir d'un post qui contenait un code quasi-identique (de nombreuses lignes, en plus) dans un switch comprenant quatre ou cinq case...

Quand j'ai eu le courage de m'attaquer à ce code, il m'a fallu de nombreux allers/retours entre chaque cas pour avoir la certitude de ce que je pressentais, à savoir qu'il n'y avait que deux valeurs (codées en dur, en plus) qui étaient modfiées en fonction du cas envisagé...

En nassichneiderman, la représentation des tests prend la forme de

pour les test "vrai faux" classiques et de

pour les tests "à choix multiples.

Le fait d'avoir les différents cas sous forme de colone permet d'obtenir une vue "en deux dimentions" (verticale, bien sur, mais aussi "horizontale")...

Du fait que une colone= une possiblité, il devient beaucoup plus facile de faire un parallele entre les différentes possiblités envisagées.

Le corollaire de cela, c'est que tu remarqueras beaucoup plus facilement qu'un certain nombre d'instructions est systématiquement présent au début ou à la fin de chaque cas, et que tu pourras donc décider, soit de les sortir du test, soit de les factoriser d'une manière ou d'une autre...

Au final, tu auras un code plus compact et plus réfléchi, sans avoir dû recourrir à des raccourcis qui seraient de nature à rendre la compréhension de la logique plus difficile à "quelqu'un de l'extérieur"...

[TROLLMODE=ON]pseudo, dans le dictionnaire, c'est sinonyme de "faux", de "semblant de", d'herzats...

En y réfléchissant, quel pourrait etre l'avantage de faire "du faux code", au lieu d'en faire tout de suite "du vrai"[TROLLMODE=OFF]

[Thierry Chappuis]

Il faut vraiment que j'approfondisse, parce que pour le moment, tes diagrammes, c'est un peu du chinois pour moi, et je ne sais trop comment les lire. Je vais chercher un ou deux tutoriaux pour me faire un idée.

Thierry

[HanLee]

Le problème du pseudo code, selon moi, c'est qu'on perd, comme pour n'importe quel autre langage, une dimention de compréhension...

Yup bien sûr c'est ce que j'entendais .

Alors qu'avec le pseudo-code, il faut le lire de manière linéaire, là on a un truc organisé, structuré, comme des organigrammes.

Du dessin quoi !

PS : par contre je supporte pas la police utilisée dans tes nassichneidermann .

[Emmanuel Delahaye]

Yup bien sûr c'est ce que j'entendais .

Alors qu'avec le pseudo-code, il faut le lire de manière linéaire, là on a un truc organisé, structuré, comme des organigrammes.

Du dessin quoi !

PS : par contre je supporte pas la police utilisée dans tes nassichneidermann .

Le problème du dessin, c'est que c'est difficile à gérer. Il faut des outils assez lourds, alors que l'algorithme textuel et le pseudocode ne nécessitent que du texte pur.

Un simple éditeur, comme celui qui sert à écrire le code, suffit.

De plus, autant l'apport graphique d'un ordinogramme ou d'un diagramme d'état pour les FSM est incontestable, autant celui d'un nassichneidermann me semble peu probant.

Personnellement, je n'aime pas trop cette représentation. Ce qui manque réellement, c'est un Langage de Description des Algorithmes qui soit normalisé, voire compilable, histoire de maquetter très rapidement...

Le Pascal semble être le plus proche...

[koala01]

Il faut vraiment que j'approfondisse, parce que pour le moment, tes diagrammes, c'est un peu du chinois pour moi, et je ne sais trop comment les lire. Je vais chercher un ou deux tutoriaux pour me faire un idée.

L'astuce, c'est que je dois avoir eu le seul prof qui en aie jamais entendu parler (et je tourve d'ailleurs cela fort désolant)...

Pourtant, honnetement, cette technique est loin "d'être pire" que le flowchart à mon gout...

Bref, tout cela pour dire que le seul site qui en parle... c'est le mien (le lien est donné dans ma première intervention )

Alors qu'avec le pseudo-code, il faut le lire de manière linéaire, là on a un truc organisé, structuré, comme des organigrammes.

Du dessin quoi !

Tout comme l'UML, le flowchart, le jakson et tant d'autres méthodes, qui ont toutes leur centre de prédilection, leurs points forts et leurs point faibles...

PS : par contre je supporte pas la police utilisée dans tes nassichneidermann .

Héhé... ca, ce n'est qu'une affaire de gouts... et, comme on dit: Les égouts et les couloeuvres...

De plus, autant l'apport graphique d'un ordinogramme ou d'un diagramme d'état pour les FSM est incontestable, autant celui d'un nassichneidermann me semble peu probant.

L'apport est sensiblement le meme que le flowchart quand il s'agit de montrer une logique destinée à des instrucitons processeurs ou à de l'assembleur, le tout, en apportant une réponse probante aux capacités des langages de troisième génération (les boucles et les tests "à choix multiple")

L'adage "un petit dessin vaut mieux qu'un grand discours" semble avoir été créé pour les différentes méthodes d'algorithmie...

Le nassichneiderman ne fait pas exception à cette "regle", et est susceptible de combler un manque parmis les autres méthodes.

Personnellement, je n'aime pas trop cette représentation. Ce qui manque réellement, c'est un Langage de Description des Algorithmes qui soit normalisé, voire compilable, histoire de maquetter très rapidement...

Encore une fois, les goûts et les couleurs...

Ceci dit, c'est peut etre, tout simplement, parce que cette représentation est "nouvelle" pour toi qu'elle occasionne une "certaine répulison"...

Par contre, je crois vraiment que le role des méthodes d'algorithmies est, justement, de présenter la logique et non de présenter le résultat...

Un peu comme ce qu'a expliqué HanLee, en laissant la possiblité d'utiliser des mots flous, tout en permettant malgré tout d'en comprendre le sens

Faites cependant attention au fait que j'ai tendance à estimer qu'une bonne méthode d'algorithmie devrait permettre à la personne qui aura en charge de créer le code de l'exécutable de ne plus se poser la moindre question concernant la manière de mettre la logique en branle, et de "restreindre" l'écriture du code en un "simple travail de traduction"... ce que permettent malgré tout le pseudo code et le nassichneiderman (le flowchart aussi, tant que ca reste à un niveau de l'assembleur au maximum... car pour les langages de troisième génération, c'est rapé )

Comprenons nous bien...

J'ai bien conscience que mon discours fait quelques peu "marchand de tapis, pret à tout pour vendre sa marchandise"...

Simplement, j'essaye de présenter une méthode que j'estime valable, en exposant ce que j'estime etre ses points forts et ses avantages par rapport aux autres méthodes, en reconnaissant malgré tout ses limites, mais, comme dit plus haut, je n'obligerai jamais personne à l'utiliser...

[Emmanuel Delahaye]

L'astuce, c'est que je dois avoir eu le seul prof qui en aie jamais entendu parler (et je tourve d'ailleurs cela fort désolant)...
L'apport est sensiblement le meme que le flowchart quand il s'agit de montrer une logique destinée à des instrucitons processeurs ou à de l'assembleur, le tout, en apportant une réponse probante aux capacités des langages de troisième génération (les boucles et les tests "à choix multiple")

L'adage "un petit dessin vaut mieux qu'un grand discours" semble avoir été créé pour les différentes méthodes d'algorithmie...

Le nassichneiderman ne fait pas exception à cette "regle", et est susceptible de combler un manque parmis les autres méthodes.

Je connais bien cette méthode de présentation que j'ai découvert dans les années 90 et certains livres de Pascal en sont remplis, mais il n'empêche que j'ai tendance à privilégier le langage naturel et le pseudo-code, tout simplement par ce que c'est plus clair et que ça correspond mieux à l'esprit des langages 3G. Les petits dessins, c'est compliqué à mettre en oeuvre, et ça ne favorise pas l'abstraction.

Pour moi, c'est une réminiscence de la 'culture du saut' (1G, 2G) et des 'flowchart' et autres ordinogrammes abscons qui en découlent. La grande force des langages 3G créés suite à la reflexion de Wirth (Algol, Pascal, Ada, C, etc.), c'est précisément d'avoir rendu inutile la phase graphique.

Ce que tu proposes, m'a apparu à l'époque (années 90) comme une complication inutile. Avec le recul, ça constitue en fait une régression.

C'est mon avis et je le partage, comme on dit...

D'ailleurs, on peut s'interroger sur le fait qu'une méthode apparue dans les années 90 ne soit pas plus présente en 2006 si elle est si intéressante que ça...

[Emmanuel Delahaye]

Bref, tout cela pour dire que le seul site qui en parle... c'est le mien

C'est étonnant. Je soupçonne une erreur dans la dénomination...

Je vais faire des recherches... Autre problèmes des méthodes graphiques, la recherche... Comment chercher un dessin ?

"Le texte c'est mieux"

EDIT : Gagné : Nassi-Schneidermann (je te conseille de mettre à jour ton site en conséquence). C'est visiblement très allemand comme démarche... Le nom officiel est struktogram (structogramme). On dit aussi GNS (Graphe de NS)

Résultats 1 - 10 sur un total d'environ 15 400 pour nassi-schneidermann . (0,12 secondes)

Have fun

[koala01]

Merci... suite à ton premier poste, je me suis justement posé la question de savoir que j'avais peut etre mal orthographié le mot ...

Je vais donc mettre mon site à jour dés que possible.

Par contre, il est vrai qu'il y a fort peu de site de langue francaise qui en parlent... Serait-ce une vieille réminiscence de l'éternelle rivalité franco germanique (personnellement, je suis Belge, et fier de l'être, donc...)

Par contre, tu dis que cela constitue, à ton gout, une régression...

Pourrais tu justifier cet avis

Personnellement, et en restant purement au niveau procédural de la réflexion, je ne vois pas forcément où se situe cette "régression".

De plus, comme je l'ai dit plus haut, il faut avouer que l'adage du petit dessin qui vaut mieux qu'un grand discours est particulièrement vrai quand il s'agit de transmettre quelque chose d'aussi abstrait, justement, que la réflexion qui permet d'obtenir un résultat donné...

Finalement, qu'il s'agisse d'un schéma électrique, du plan d'un meuble ou d'un immeuble, voire, du plan de montage de la maquette de l'arizona... le "petit dessin", quel que soit son nom et/ou la convention utilisée pour le produire, a toujours fait partie des étapes permettant de faciliter le passage de "l'abstrait" au "concret"...

[Emmanuel Delahaye]

Par contre, tu dis que cela constitue, à ton gout, une régression...

Pourrais tu justifier cet avis

Je pense l'avoir pas mal justifié déjà.

Pour moi, c'est une réminiscence de la 'culture du saut' (1G, 2G) et des 'flowchart' et autres ordinogrammes abscons qui en découlent. La grande force des langages 3G créés suite à la reflexion de Wirth (Algol, Pascal, Ada, C, etc.), c'est précisément d'avoir rendu inutile la phase graphique.

Ce que tu proposes, m'a apparu à l'époque (années 90) comme une complication inutile. Avec le recul, ça constitue en fait une régression.

Que dire de plus ? Retour vers un concept dépassé ? Rendu inutile ? J'ai peur d'être poussé à utiliser des mots excessifs...

De plus, comme je l'ai dit plus haut, il faut avouer que l'adage du petit dessin qui vaut mieux qu'un grand discours est particulièrement vrai quand il s'agit de transmettre quelque chose d'aussi abstrait, justement, que la réflexion qui permet d'obtenir un résultat donné...

Finalement, qu'il s'agisse d'un schéma électrique, du plan d'un meuble ou d'un immeuble, voire, du plan de montage de la maquette de l'arizona... le "petit dessin", quel que soit son nom et/ou la convention utilisée pour le produire, a toujours fait partie des étapes permettant de faciliter le passage de "l'abstrait" au "concret"...

Le dessin est moins abstrait que le texte. C'est le texte qui stimule l'activité neuronale (cerveau gauche, reflexion, logique, analyse). Le dessin s'adresse au cerveau droit (création, esthétique, intuition, émotion...). Il parle aux sens.

Le dessin est complexe à mettre en oeuvre. Si on peut l'éviter, c'est une complication de moins. J'ai l'intention, un jour, d'écrire une application dans laquelle on entre la définition d'une FSM (états, évènements, transitions) sous forme textuelle (éventuellement assistée) et qui sort le schéma automatiquement, ainsi que le code en C...

[granquet]

je decouvre le nassi-schneidermann.

j'en vois pas bien l'interet dans la phase de conception (desolé ); par contre je me dis qu'un debugger qui m'afficherais mon code C avec la meme presentation (ptetre avec un systeme de couleurs pastels ...), me permettrais de voir d'un seul coup d'oeil un espece d'historique de l'execution du code.

[koala01]

Bien que je comprenne et que je respecte ton point de vue, je ne le partage pas... Mais sans doute est-ce du fait de ma formation de base, qui est technique ...

En effet, l'écriture n'est, en définitive, que du dessin, même si l'on n'en a plus forcément conscience.

Qu'il suffise de voir les différents types d'écriture au travers des âges, et je pense tout particulièrement aux hieroglyphes de l'Egypte ancienne, pour s'en convaincre...

Si le distingo est fait entre le dessin et l'écriture, c'est pour la simple et bonne raison que l'écriture permet de représenter des concepts précis: un ensemble de dessins (les lettres) permettent de former des mots, qui, mis dans un certain ordre forment des phrases qui sont compréhensibles par le lecteur.

Mais, si un tel distingo peut etre fait entre le dessin "artistique" et l'écriture, il peut tout aussi bien être fait entre le dessin artistique et tout dessin technique

Si un plan d'architecte, un schéma électrique ou un plan d'atelier de menuiserie prend un sens particulier, c'est parce que c'est la représentation de concepts bien établis, en utilisant des conventions, autant que faire se peut, tout aussi bien établies...

En cela, tu pourras malgré tout remarquer que c'est une caractéristique que tu peux très bien appliquer à l'écriture

La seule différence notable, c'est que, par le seul fait de la présence de conventions précises, on peut se contenter de quelques sigles/nombres/cotes là où l'écriture de la meme chose aurait pris l'allure de discours électoraux: long, emberlificoté au possible et incompréhensible...

Le résultat est qu'une personne peut très bien etre en mesure de dessiner un plan d'atelier, un plan d'architecte ou un schéma électrique en étant tout à fait incapable de fournir le moindre dessin artistique, ou vice versa...

En outre, il n'y a pas de différence entre le fait de faire un schéma pour représenter la logique que devra suivre une fonction pour arriver au résultat qu'on attend d'elle, pour autant que la technique choisie soit adaptée à la "génération" du langage qui sera utilisé, et le fait de faire n'importe lequel des différents diagrammes utilisables en UML.

Mieux, cela s'inscrit parfaitement dans la continuité de la chose...

L'UML est en effet très bien pour modéliser et pour se faire une idée précise, mais générale, de ce qui rentrera en jeu, et à quel moment... Mais il s'arrete, justement, au moment fatidique, à savoir, la logique du traitement du message reçu à fin de déterminer s'il est ou non opportun d'aller plus loin, et/ou fournir un message résultant répondant aux attentes...

A ce titre, toute méthode d'algorithmie, et je le répète, pour autant qu'elle couvre les possiblités offertes par le langage, ne peut être que bénéfique du point de vue du résultat final, en permettant de "pousser la réflexion" jusqu'à son terme.

Je vais peut etre en choquer plus d'un, mais, la fourniture d'un code compilable ou interprétable n'est en définitive que du "simple, pur et emm travail de dactylographie"

Ou du moins, si la réflexion a été menée suffisemment loin, ca peut/devrait le devenir...

Le fait de disposer d'un algorithme correctement pensé et adapté à la génération du langage utilisé (je sais, je me répète sur cette condition, mais il se fait que c'est une condition indispensable ) est normalement de nature à:

• permettre d'éviter toute nécessité de réflechir sur la manière de faire quelque chose (hormis, on se comprend, la synthaxe particulière au langage utilisé)
• permettre d'arriver au résultat voulu dés la premiere compilation/exécution interprétée sans erreur (tout le monde a connu le problème d'un = au lieu d'un ==, d'un ; oublié ou d'un nom de variable mal écrit)

Evidemment, cela sous entend que l'utilisation du flowchart, par exemple, ne sera adaptée pour aucun langage offrant la possiblité des tests à choix multiples ou des boucle (mais parfaitement adapté, par contre, à l'assembleur ou au langage machine).

De la meme manière, le jackson sera particulièrement efficace pour préparer le travail dans la gestion des structures, et le nassi-schneiderman trouvera naturellement sa "niche" auprès des langages de troisième génération...

[Emmanuel Delahaye]

Je vais peut etre en choquer plus d'un, mais, la fourniture d'un code compilable ou interprétable n'est en définitive que du "simple, pur et emm travail de dactylographie"

Je suis d'accord et j'ai parfois insisté sur le fait que 'le code c'est rien' et que le travail intéressant, c'est la conception. C'est l'essence même de ma reflexion des ces dernières années et probablement de mon enseignement futur (je suis formateur indépendant depuis peu).

Je ne serais du tout choqué de concevoir en Langage Formel de Description de Algorithme comme le Pascal et de traduire automatiquement en C (P2C...). Mais finalement comme il existe des compilateurs Pascal, à quoi bon traduire en C ? Pour le maquettage, le Pascal pourrait suffire. Disons pour les cas tordus du code réel... Et puis le Pascal standard est plutôt limité coté I/O.

Par contre Turbo Pascal ou Free Pascal sont très puissants... et OO si on veut (et là, c'est une extension, et non un Pascal++ qui ressemblerait au Pascal avec des tas de pièges...)