[TUTO de A à Z] Penser son programme avant de le coder

Bonjour,

La plupart du temps quand on débute en programmation, on procède comme ceci pour créer son logiciel:

- Ouvrir SZ (ou VS)
- Créer un nouveau projet winforms
- Réfléchir à ce que l'on veut faire comme logiciel en essayant différents composants graphiques (treeview, toolstrip, tabcontrol...)
- Réfléchir à un algorithme en temps réel pour chacun des évènements / chacune des fonctions.
- Créer des fonctionnalités au fur et à mesure que l'on programme

Cette façon de procéder est plutôt adaptée pour les petits projets: bloc-notes, générateur de mot de passe, utilitaire... en revanche elle s'avère contre-productive
pour les plus gros projets .

Par exemple j'ai créé un logiciel qui permet rapidement de convertir une proportion (ex: 4/3 = 8/6) en utilisant la règle de trois:




Dans ce cas là, la réflexion autour de la création du logiciel est basique: faire une règle de 3 en fonction du champ qui est resté vide.



Ici pour calculer D par exemple, je vais faire D=(BxC)/A soit D=(7x3)/5=21/5.

Dans ce genre de cas, on as pas besoins de trop planifier le développement du programme: l'algorithme est tellement simple qu'il n'a pas besoins d'être décortiqué.

[information] Retenez que, dès que plusieurs controls (button, textbox...) ou fonctions font appels à un même enchainement d'action avec des paramètres différents,
alors il est nécessaire de penser son programme avant de l'élaborer sur ordinateur . [/information]

Nous allons apprendre dans ce tutoriel une méthodologie globale pour créer des projets de moyenne ou grande envergure (P.M.G.E pour raccourcir ).

1 - Que veut t'on faire ?

La base pour créer un P.M.G.E est de définir en premier ce que l'on veut créer.

Évidemment, il faut avoir un projet certain dans lequel on pourra s'impliquer dans le temps (par exemple, ne pas passer d'un tableur à un lecteur multimédia )...
Mais il faut également définir TOUTES les fonctionnalités du logiciel.

Prenons l'exemple d'un logiciel qui permet d'éditer une bibliothèque de film (Filmotech ci-dessous, j'ai pris une capture au pif sur internet et je ne garantis rien sur la qualité du film ):



La technique générale consiste à évoquer les fonctionnalités générales puis les fonctionnalités des fonctionnalités puis les fonctionnalités des fonctionnalités des fonctionnalités... qui vont déboucher sur du code .

Pour ce logiciel par exemple on part d'une fonctionnalité qui découle de ce qu'on veut créer: Gérer une bibliothèque de film.

Cogitons pour en dégager une hiérarchie:



Mon début de hiéarchie... cétipabo ?
Au passage, je vous recommande fortement l'outil (open source et gratuit) qui m'a permit de faire cette hiérarchie: Freemind

[attention]Remarquez que je ne suis pas allé jusqu'au bout dans chacune des branches mais c'est ce qu'il faudrait faire dans l'idéal:
que les dernières fonctionnalités que vous évoquez soient réalisables avec le moins d'actions possibles ! [/attention]
[erreur]
Cette technique demande d'être très à l'aise avec les fonctions de bases (se connecter à une bdd, créer et écrire un fichier, gérer les
champs vides...) donc c'est pour ça qu'il est recommandé de passer par des petits projets avant d'attaquer les grands ![/erreur]

2 - Comment doit t'on le faire ?

Après avoir dégagé les fonctionnalité de base, vous devez retranscrire ce travail en code (ou algo avec SZ).

Vous pouvez dans un premier temps utiliser une approche fonctionnelle, càd associer à chaque fonctionnalité de base une fonction (qui peut être crée dans SZ depuis SZ2012 je crois...).

[information]Une fonction est une sorte de machine qui peut recevoir 0, 1, 2,...,+inf d'éléments et renvoyer 0 ou 1 valeurs.

Par exemple la fonction addition reçois 2 nombres a et b, elle les additionnes et elle met le résultat dans la variable c. [/information]

La difficulté de cette étape est de transcrire des fonctionnalités de base comme "Générer un fichier XML à partir de l'interface de la fiche" en fonction.

Il faut définir de cette fonctionnalité 3 choses:

• Définir si il y a une entrée, si oui laquelle ou lesquelles
  
• Définir si il y a une sortie, si oui laquelle
  
• Définir l'algorithme à utiliser
  

En partant de l'exemple "Générer un fichier XML à partir de l'interface de la fiche" (GFXPIF):

• L'entrée: Toutes les variables qui contiennent des infos sur le film (nom, réalisateur, année, affiche, résumé...)(étant donné que on doit sauvegarder ce contenu)
  
• La sortie: On dit si le fichier c'est bien créé (pour éviter que l'utilisateur n'ait de mauvaises surprise )
  
• L'algorithme:
  

  Code:

  CONTENU est une variable de type texte
CONTENU=<REAL>%(real)%</REAL>\n<TITRE>%(titre)%</TITRE>\n<ACTEUR>%(acteur)%</ACTEUR>\n...
Créer un nouveau fichier nommé %(film)%.xml dans le dossier machin/mesfilms/ avec comme contenu %(CONTENU)%
Renvoyer 1 si le fichier existe bien, sinon renvoyer zéro.


  On se réfère à la norme du XML tout en plaçant nos éléments (mon xml est un peu pourris remarquez... )
  

Ainsi il vous suffira d'appeler la fonction GFXPIF pour sauvegarder une fiche !

[information]Cette fonction pourra resservir quand on voudra modifier la fiche, n'hésitez pas à adapter votre programme pour que les fonctions
puissent resservir dans plusieurs cas différents. [/information]

3 - Finissons et concluons

Il ne vous reste plus qu'à faire appel aux bonnes fonctions avec les bons paramètres dans les bons évènements. Par exemple, appelez la fonction qui sauvegarde la fiche dans le disque dur quand l'utilisateur clique sur le bouton pour sauvegarder la fiche !
Pensez également à gérer se que renvoie ces fonctions (par exemple, afficher un message d'erreur quand le fichier qui contient le contenu de la fiche n'a pas pu être sauvegardé).



Au final il faut se dire que le meilleurs moyen de surmonter une difficulté est de découper cette difficulté en sous-difficultés jusqu'à ce que les difficultés
prises individuellement soient très simple à résoudre. Les gros projets ne doivent pas être résolus en un bloc mais par une succession de blocs .

J'espère que mon tutos vous a été utile .
A bientôt !

Hey,

assez intéressant de montrer le côté plus théorique je dirais dans la conception d'un programme. En effet on a souvent tendance, quand on débute dans le milieu, à vouloir faire quelque-chose, sans savoir quoi, alors on crée son projet qu'on appelle "Test" ou "Tuto" ou même "fjifzeifzejio" pour les plus impatients, et à réfléchir sur le tas après !
Je sais d'expérience que des fois ça marche, on peut réfléchir sur le tas, mais des fois on a besoin de s'imaginer la situation. Pour mon projet de bac d'info j'avais eu besoin de faire un schéma (j'avais utilisé un outil en ligne je me souviens plus du nom), et ça sert !

Au fait quand tu dis qu'il faut séparer la difficulté en sous-difficultés, ça me fait penser à un philosophe qui a dit ça mais je sais plus qui.. (je me souviens de vraiment rien aujourd'hui faut croire )

Cordialement,
Softwarezatorman

Hello,

Très intéressant comme tutoriel ça permettra au débutants de ne pas ce noyer dans leurs objectifs pour concevoir leurs programmes

Bravo pour ce tuto !

Bonjour,

Merci pour vos retours positif

@Softwarezatorman: Tout à fait et cela reste une vision de la programmation défendable pour les débutants ou ceux qui ont
besoins de créer leur propres petits outils/expérimentation.
Tout est une question de contexte et évidemment les gros projets ne dérogent pas à la règle .

(Rhalala dès que le bac est passé on oublie tout, hein ? )
Pour le philosophe je sais plus non plus qui c'est ... Il me semble que cette formulation vient du raisonnement de la
question "Peut-on tout démontrer ?". En gros, quelque soit ce que l'on veut démontrer, on pourra le démontrer. Car à force
de conceptualiser l'affirmation on arrivera à des affirmations tellement simple que ces affirmations seront naturelle, évidente... et donc rendrons tout le raisonnement censé.

Par exemple:

Polien est bleu car:
1) Polien mange du poisson                      
1)a)Le Poisson c'est bon                                
1)b)Le Poisson contient plein de nutriments

et:

2) la nourriture que l'on mange change notre couleur
2)a) les flamants roses sont roses car ils mangent des crevettes roses

On reconnait un peu le mode de raisonnement de mon tuto !

@Blackorion35: Tout à fait ! ça m'est arrivé tellement de fois d 'abandonner un projet par manque d'organisation !

re,

Super tuto !!! C'est super bien détaillé et même le nom d'un soft en prime !

Par contre, il va falloir arrêter la philo car là vous allez me perdre ......

Bonne continuation

Cordialement,
Le réparateur de PC

Hello ,

Rien à ajouter à ce qui a été dit par les autres : Super tuto

Cordialement ,

Jeremy60800

re,

@Jeremy60800 merci ,@lereparateurdepc: ah ah promis on arrête .

Re,

le bac ça m'a retourné faut croire    (avoir 12 en philo sur un sujet non-traité en cours, donc au full talent, je pense que ça mérite des applaudissements, surtout vu comment j'ai rien foutu de l'année en cours de philo  ).
Effectivement je crois bien que c'est en lien avec cette question que j'ai vu ce raisonnement !
@lereparateurdepc oups, on va éviter de parler philo alors !  

Cordialement,
Softwarezatorman

re,

Bravo !

Re,

Merci !

Cordialement,
Softwarezatorman