Discussion :

[sphynxounet]

Bonjour,

je voulais juste savoir s'il existait une possibilité de "dessiner" un algorigramme dans Windev. Et éventuellement de passer directement à du code (on peut toujours rêver).

J'ai regardé un peu dans les diagrammes UML mais j'ai pas réussi à le trouver (si ça existe bien sur).

Coder une fonction qui fait des centaines de lignes avec des tests dans tous les sens ça donne mal au crâne à force (et encore je suis pas passé au debug) ...

Merci

[EDM-TAHITI]

Hello,
Ce que tu demande n'est pas possible, au moins jusqu'à la version 11 que je possède... En résumé, tu demandes à Windev de faire un algorythme sous forme graphique de ton analyse de besoins, et de surcroit, de le coder.
Ne crois-tu pas que c'est le rôle de l'analyste de faire ceci, de déterminer le meilleur code pour la résolution de problèmes?
Quand à 'décoder' une fonction qui fait des centaines de lignes, certe, c'est délicat, mais si cette dernière est commentée, indentée dans les pas de programme, il n'est pas si ardue de suivre le code, d'autant que c'est toi qui en possède la philosophie.
Et si l'imbrication des conditions ( si, sinon, sinon si, etc...), utilises alors le 'cas'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
selon hypothèse
 
   cas [hypothèse 1]
 
   cas [hypothèse 2]
 
   autre cas
 
// fin de l'hypothèse
fin

Voilà ce que je peux te dire

[Finar]

Et bien... Le RAD permet à partir de l'analyse (UML, MLD...) de générer un certain nombre de chose automatiquement.

Cependant, ce sera plus pour le coté "fonctionnel" d'une application, et ce sera du code relativement basique : "J'affiche des enregistrements, j'en ajoute, j'en supprime, j'en consulte", des choses de ce genre.

Néanmoins, je n'utilise que peu ces fonctionnalités de génération de code, et je suggère donc un coup d'œil à la documentation, mais dans tous les cas, je doute fort que cela permette de générer en automatique le genre de fonction dont vous parlez :-/

Finar

[sphynxounet]

En résumé, tu demandes à Windev de faire un algorythme sous forme graphique de ton analyse de besoins, et de surcroit, de le coder.

Non j'aimerai pouvoir faire l'algorigramme tout seul comme un grand puis que Windev le passe en code directement. L'algorithme n'est autre que la transposition en code de l'algorigramme. Dans mon cas ce qui est assez contraignant c'est que j'ai pas mal de SI en cascade à cause de tests de cas particuliers. C'est pas évident à coder mais aussi à débuger puisqu'il faut tester chaque cas particulier.

Ne crois-tu pas que c'est le rôle de l'analyste de faire ceci, de déterminer le meilleur code pour la résolution de problèmes?

Bah non c'est le rôle du stagiaire (donc moi ). De plus je ne cherche même pas à établir le meilleur code possible mais au moins à faire en sorte que l'exécution de la procédure ne prenne un temps conséquent.

[mogwai162]

De plus je ne cherche même pas à établir le meilleur code possible mais au moins à faire en sorte que l'exécution de la procédure ne prenne un temps conséquent.

Ah bon ? je crois que tu devrais te renseigner sur le rôle d'un développeur tout stagiaire soit-il.

Il me semble que tu as tout de même d'autres responsabilités que la rapidité du code non ?

[sphynxounet]

Il me semble que tu as tout de même d'autres responsabilités que la rapidité du code non ?

Oui au moins une ... que ça fonctionne

[mogwai162]

Et tu crois vraiment de Windev pourrait te proposer un code qui fonctionne quelque soit ton algorithme ?

C'est du langage de 6° génération ça non ?

[sphynxounet]

Le principe de l'algorigramme c'est d'avoir une représentation graphique d'un algorithme qui est quand même plus simple à lire et éventuellement à modifier.
Après que ce soit en code ou graphiquement, une boucle reste une boucle. Si on définit les variables dont on a besoin, on peut rapidement transposer l'algorigramme en code.

Dans l'absolu un programme pourrait très bien transposer un algorigramme en code.

Quelque part c'est un peu ce que fait Windev avec la description des champs. On va définir des options dans la description sans le faire par code. Mais derrière Windev va modifier les options par code.

[mogwai162]

Bah... Peut être que je me fais trop vieux... Peut-être que je suis comme ceux qui ont râlé quand les L3G sont apparus parce que ne plus programmer en assembleur ou langage machine ce n'était plus programmer.

L'avenir le dira mais en tout cas, au risque de passer pour un vieux con, je suis heureux que ça n'existe pas.

[sphynxounet]

On peut aussi inverser le problème et dire que les jeunes veulent tout et tout de suite

Pour avoir programmé en assembleur je dirai que si le langage est dépassé comparé à des langages de POO, il reste tout de même un langage puissant, preuve en est une news sur les OS où un membre expliquait qu'il existe un OS stable et fonctionnel programmé en assembleur et qui tient sur une disquette.

L'idée de transposer un algorigramme en algorithme revient au même que de définir un diagramme de classes et que Windev (ou autre) le transpose en classes avec leurs propriétés et leurs méthodes.

[=JBO=]

Bonjour sphynxounet,

Je n'ai pas de proposition pour ton algorigramme et sa traduction automatique.

Cependant, ce qui suit m'interpelle...

Coder une fonction qui fait des centaines de lignes avec des tests dans tous les sens ça donne mal au crâne à force (et encore je suis pas passé au debug)

Une fonction de plusieurs centaines de lignes...

Par expérience, je serai tenté de dire qu'un "algorithme à rallonge" est la conséquence d'une analyse trop superficielle du problème.
La formalisation du problème peut réduire considérablement l'algorithme, surtout s'il s'agit d'une succession de SI ALORS SINON imbriqués.

Par exemple (là je vais être abstrait, forcément), l'analyse des différentes situations peut revenir à déterminer une matrice des cas possibles avec les critères correspondant.
Ensuite l'algorithme simplifié se limite à déterminer l'ensemble des critères qui sont vérifiés, ce qui permet de désigner rapidement la cellule de la matrice correspondant au cas.

Bon courage.
_

[sphynxounet]

Bon pour faire simple je suis en train de faire une fonction globale de détection de surfaces : j'ai un champ image, j'ai d'autres champs image dans le premier et je dois déterminer toutes les surfaces libres disponibles.

J'ai cherché sur internet des exemples mais ça n'existe pas tout simplement parce que l'algo est assez lourd et que personne ne s'amuse à partager son code.

Si j'ai pas mal de tests c'est qu'à la base j'avais fait une boucle assez simple mais dont je savais qu'elle augmenterai considérablement le temps de traitement surtout si j'avais plusieurs obstacles assez grands.
Du coup je l'ai supprimée et je me retrouve à traiter tous les cas possibles. Si pour 1 obstacle y a pas trop de problèmes, rien que d'avoir 4 ou 5 obstacles qui ont en plus des abscisses ou ordonnées communes ça commence à devenir chaud bouillant.

Edit : en tout j'en suis à 540 lignes. Y a plus qu'à debug ...

[dvdbly]

[...]
Pour avoir programmé en assembleur je dirai que si le langage est dépassé comparé à des langages de POO, il reste tout de même un langage puissant, preuve en est une news sur les OS où un membre expliquait qu'il existe un OS stable et fonctionnel programmé en assembleur et qui tient sur une disquette.[...]

D'abord, l'assembleur n'est pas dépassé !
C'est comme si tu disais que l'alphabet était dépassé depuis que tu sais faire des phrases...
L'utiliser répond à des besoins spécifiques certes, mais il n'est certainement pas dépassé, ne serait-ce que parce que c'est le seul moyen in fine de dialoguer avec un proc., même si tu te payes les services d'un "interprète".

[sphynxounet]

Bah oui l'alphabet est dépassé car on est passé aux phrases. Certes l'alphabet c'est marrant au CP mais ensuite tu utilises des mots et des phrases pour t'exprimer, à moins que tu t'amuses à épeler encore chaque lettre de chaque mot que tu prononces. L'alphabet a été le précurseur de notre façon de nous exprimer aujourd'hui certes et il est important de l'apprendre pour comprendre comment nous exprimer. Mais il faut savoir évoluer avec son temps.

L'assembleur c'est pareil (pour moi) dans le sens ou des compilateurs C sont tout à fait capables de générer des fichiers .asm (et j'ai pas cherché mais si ça setrouve on peut aussi les générer à partir de langage type C++ C# VB.NET Java ...).
Sauf pour les gens qui ne font que de l'assembleur et qui n'ont jamais vu de langage moins machine, programmer en C est quand même (encore une fois à mon avis) un peu plus rapide et facile à lire et même à déboguer.
Si tu prends 2 petits programmes qui font la même chose, 1 en assembleur et 1 en C, théoriquement on comprendra plus rapidement celui écrit en C.

Après si les gens préfèrent se prendre la tête avec des fonctions à 4 lettres et toute une manière de programmer archaïque puisque notepad suffit. Même qu'on peut utiliser un 386 pour faire tourner le programme.

Si les gens veulent continuer à programmer sur des 68HC11 ou des 80C51 libre à eux. Moi quand je vois des petites cartes comme celle proposée à 150$ par Beagleboard, pourquoi je me prendrai la tête avec un langage machine lourd alors qu'on peut très bien faire la même chose avec des langages (et du matériel) plus évolué ?

[dvdbly]

Bah oui l'alphabet est dépassé car on est passé aux phrases. Certes l'alphabet c'est marrant au CP mais ensuite tu utilises des mots et des phrases pour t'exprimer, à moins que tu t'amuses à épeler encore chaque lettre de chaque mot que tu prononces. L'alphabet a été le précurseur de notre façon de nous exprimer aujourd'hui certes et il est important de l'apprendre pour comprendre comment nous exprimer. Mais il faut savoir évoluer avec son temps.

A propos d'alphabet, je vois bien qu'il faut te mettre les points sur les i :
essaye donc de faire des phrases sans alphabet et on en reparlera...

L'assembleur c'est pareil (pour moi) dans le sens ou des compilateurs C sont tout à fait capables de générer des fichiers .asm (et j'ai pas cherché mais si ça setrouve on peut aussi les générer à partir de langage type C++ C# VB.NET Java ...).

Là, pour le coup, je ne vois pas l'intérêt de produire un fichier asm plutôt qu'un fichier objet !?

Sauf pour les gens qui ne font que de l'assembleur et qui n'ont jamais vu de langage moins machine, programmer en C est quand même (encore une fois à mon avis) un peu plus rapide et facile à lire et même à déboguer.
Si tu prends 2 petits programmes qui font la même chose, 1 en assembleur et 1 en C, théoriquement on comprendra plus rapidement celui écrit en C.

Je ne crois pas que cela se conteste. Néanmoins, il reste des cas où l'assembleur est le seul moyen d'optimiser suffisamment son code, le voire seul langage disponible.

Après si les gens préfèrent se prendre la tête avec des fonctions à 4 lettres et toute une manière de programmer archaïque puisque notepad suffit. Même qu'on peut utiliser un 386 pour faire tourner le programme.

Si les gens veulent continuer à programmer sur des 68HC11 ou des 80C51 libre à eux. Moi quand je vois des petites cartes comme celle proposée à 150$ par Beagleboard, pourquoi je me prendrai la tête avec un langage machine lourd alors qu'on peut très bien faire la même chose avec des langages (et du matériel) plus évolué ?

Outre l'aspect pédagogique indiscutable que présente l'assembleur, encore une fois, il y a des cas où l'on a pas le choix...

[mogwai162]

Arrêtez de vous battre ! sales gosses !

De toute manière vous avez raison tous les deux ! Heureusement qu'on a fait mieux que l'assembleur mais il restera toujours utile !

Na !

[sphynxounet]

A propos d'alphabet, je vois bien qu'il faut te mettre les points sur les i :
essaye donc de faire des phrases sans alphabet et on en reparlera...

Bah c'est pas compliqué pour faire des phrases j'utilise des mots
(oui oui je sais et pour faire des mots ... )

Outre l'aspect pédagogique indiscutable que présente l'assembleur, encore une fois, il y a des cas où l'on a pas le choix...

Je sais bien qu'il existe quantité de systèmes embarqués qui utilisent des µproc qui se programment en assembleur. Ca me fait penser au bug de l'an 2000 et les systèmes bancaires en COBOL où il a fallu rappeler des mecs à la retraite ... On change pas tout un système du jour au lendemain.

Faut-il apprendre aux jeunes l'assembleur ? Pourquoi pas au moins ils sauront c'est quoi se prendre la tête juste pour faire clignoter une led ou même pire, un chenillard . Après comme tout ce qui date, l'assembleur est de moins en moins utilisé. S'il peut avoir un côté pédagogique, je doute que son utilisation perdure indéfiniment.

[dvdbly]

[...]Après comme tout ce qui date, l'assembleur est de moins en moins utilisé. S'il peut avoir un côté pédagogique, je doute que son utilisation perdure indéfiniment.

Tout ce qui date, voyons : SQL, TCP/IP, FTP, B-Tree, ... hum, hum... Ah ! oui : clavier, souris, écran, ...

[zouzoukha]

Hello Spynxounet et dvdbly
MATCH NULL
PAUSE

STOP

FINPROGRAMME (discussion)

[sphynxounet]

Arrêtez de vous battre ! sales gosses !

Mais heuuuuu c'est lui qui a commencé d'abord.

Enfin bref, pour en revenir au sujet initial ma procédure fonctionne pas trop mal, il reste quelques détails à régler.
Mais un algorigramme c'est quand même pratique et lisible. Je vois quand on enchaine des tests en cascade parfois on sait plus trop à quel SI correspond un SINON quand on a plusieurs dizaines de lignes entre (même avec les tabulations et non je ne bois pas au travail). Du coup obligé de mettre des lignes de commentaires, j'en ai presque au moins une à chaque test.