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]
Envoyé par koala01
Salut,
Répondre avec citation
Partager