Vos recrutements informatiques

700 000 développeurs, chefs de projets, ingénieurs, informaticiens...

Contactez notre équipe spécialiste en recrutement

Developpez.com - C
X

Choisissez d'abord la catégorieensuite la rubrique :


Créer une application de A à Z sous C++ Builder
méthodologie

Auteur : Jean-Etienne « JEG » GOUBARD
02/07/2002

I.        REFLECHIR

 

1.    Etude de faisabilité

 Répondre aux questions suivantes :

  • Quelle est la fonctionnalité globale de mon application ?

 Faire un croquis rapide :

 

Exemple pour une application de dessin:

  •  Quelqu’un l’a-t-il déjà fait ?

  • Si oui quelle sera la valeur ajoutée de mon programme par rapport à l’existant ?

  • Pourquoi dois-je la faire ?

  • Suis-je prêt à passer beaucoup plus de temps que prévu pour son développement ?

2.    Rélexion technique

  •   Quels sont les acteurs ?

Qui va pouvoir intervenir sur le déroulement du programme et comment ?

Exemples :

Pour un programme de dessin :

1 utilisateur (dessine)

Pour une programme de gestion de bibliothèque

                        Plusieurs membres (empruntent)

                        Plusieurs visiteurs (listent)

                        Plusieurs bibliothécaires (mettent à jour)

                        1 administrateur (peut intervenir directement sur la base de donnée)

Quelles sont les intercations avec le système ?

o        Gestion de configuration ? (.ini, base de registre)

o        Stockage sur le disque dur ?

o        Dialogue par le port série ?

o        Impression possible ?

o        Affichage textuel, graphique ?

o        Interaction par le clavier, par la souris ?

o       

 

  • Quelles sont les technologies impliquées ?

o       Base de données ?             XML ?

o        Technologie client/serveur ?

o        Base de registre ?

o        directX ?

o       

  •   Se renseigner sur les technologies qui vont être utilisées afin de les maitriser

3.    Décrire plus précisément

 

  • Regrouper les fonctionnalités dans des unités dédiées, refaire des schéma spécifiques.

Garder à l’esprit que toute unité puisse être réutilisée dans une autre application sans avoir à être obliger de la modifier. (ce qui est tout le principe de la progrmmation objet)

Exemple :

      Unité de gestion du port comm :

« ne s’occuppera que d’envoyer et recevoir des suites d’octets »

 

  • Pour chaque unité passive , donner un nom commencant par UN (comme unité) et pour chaque unité active, donner un nom comencant par TH (come thread). J’entends par unités actives (exemple « THportComm »), les entités qui « tournent » continuellement en tâche de fond en attente de leur entrée.

  • Décrire les actions réalisées en intèrne par cette entitiée et les actions qui pourront être effectuées par une autre entité chargée de la piloter

Intèrne :

initialisation

desinitialisation

réceptionner                    « attendre une réponse »

envoyerRéponse              « c’est l’unité qui prend la décision de reporter la réponse reçue à une autre entité »

 

Extèrne :

démarre

arrêter

envoyer

déclarerEmplacementReponse                 « déclare où la réponse recu devra être envoyée par l’unité »

  

4.    Etablir les liens

 

 

  • Etablir une Unité passive « UNmanager » qui sera le cerveau coordinateur de toutes les entités. Le décrire de la même facon que précédemment pour les unités spécifiques.

  • Relier les unités entre-elles avec des flèches symbolisant le mot « utilise » ou bien « pilote », exemple « UNmanager utilise THcommPort ». Les plus expérimentés utiliseront la méthode de description UML à ce stade.

 

  

II.      CHERCHER

 ·         Pour chaque unité, chercher si quelqu’un ne l’a pas déjà faite (avec les sources ou juste une librairie). L’utiliser si possible le cas échéant.

  

III.    IMPLEMENTER

 

1.    Les unités

 

  • Pour chaque unité non importée de l’extérieur, la coder selon la méthode qui suit.

  • Une unité = 1 fichier .h, un fichier .cpp du nom donné à l’unité :

 Exemple : UNmanager.h et UNmanager.cpp

  •  J’écris dans le .h une classe du nom de l’unité sans le UN ou  le TH devant et dont la première lettre est en majuscule.

class CommPort

{

} ;

  •  J’écris toujours dans le .h les constructeurs et detructeurs par défaut…

  •  … Et le prototype des méthodes de la classe (je mets toujours bool quand je suis tenté de mettre void, et je mets toujours __fastcall)

Tout s’écrit en minuscule, hormis le deuxième mot qui prend une majuscule. Jamais de « _ » hormis pour les paramètres des fonctions qui commencent avec.
 

private :

bool __fastcall initialisation() ;

bool __fastcall desinitialisation() ;

 

protected :

bool __fastcall receptionner(byte * _buffer) ;                     

bool __fastcall envoyerReponse(byte * _response) ;

 

public :

bool __fastcall demarrer();

bool __fastcall arreter();

bool __fastcall envoyer(byte * _toSend) ;

bool __fastcall declarerEmplacementReponse(void * _callBack) ;

 

  • Je declare les données que la classe va pouvoir utiliser pour passer d’une fonction à l’autre, elle commencent toujours par une minuscule. 

private :

Byte buffer[4096];

bool demarre;

void * callBack();

 

  • Je me déplace dans le .cpp et dans le constructeur je ne mets qu’un appel vers initilisation(), dans le destructeur un appel vers desinitilisation()

  • Dans initialisation(), je commence par mettre le code suivant

try {

 

            …

 

            return true ;

} catch(…) {}

return false ; 

                         puis j’initialise mes données members de classe à la place des « … »

try {

 

            ZeroMemory(buffer, 4096);

            demarre = false;

            callBack = NULL;

           

            return true;

} catch(…) {}

return false;

  •  Idem dans desinitialisation()

  • Règle d’or pour toutes les méthodes qui vont être écrites par la suite :

  • Toujours englober le corps de la fonction d’un bloc try catch.

  • Toujours tester si les arguments de la méthode sont valides (notamment quand passés par pointeurs)

  • Sortir le plus tot possible les cas d’erreurs, par un return (permet d’avoir moins de niveau d’indentation dans son code)

  • Par la suite n’avoir qu’un seul point de sortie pour la fonction.

  • Les variables déclarées dans la fonctions doivent être préfixée d’un « l_ » comme « local » (exemple : int l_variableTemp = 0), les autres sont supposées membres.

  • Préférer les boucles for aux boucles while

  • Ne jamais mettre une boucle sans fin (« while(true) »), sauf dans le corps principal d’une unité active, il doit toujours y avoir une condition qui permette de sortir de la boucle.

  • Chaque nom de fonction doit reflèter ce qu’elle fait. Exemple : « bool __fastcall affichageTableau(int ** _tableau) »
     

  • Je code les setters et les getters, (ce sont les fonctions qui ne font que changer l’état d’une donnée membre privée ou d’en connaître l’état). Toujours commencer par mettre le bloc try catch, pour chaque fonction.
     

bool __fastcall Commport::declarerEmplacementReponse(void * _callBack)

{

            try {

                        If (!_callBack)                  return false;

                        callBack = _callBack;

 

                        return true;

            } catch(…) {}

            return false;

}

  • Codage des autres functions selon le même principe.

2.    L’interface

  • Toujours se mettre à la place d'un utilisateur le plus idiot possible. L'application doit pouvoir faire le maximum des tâches à sa place, moins l'utilisateur plus il est heureux.

  • Et le plus feignant (moins il a cliqué plus il est heureux)

  • La forme principale doit être nommée fmMain, son fichier FMmain.cpp et .h

  • Les formes destinée à être des fenetres filles (au sens MDI du tèrme) doivent s'appeler ffQuelqueChose et le fichier associé FFquelqueChose.cpp et .h

  • Les autres fenêtres non MDI doivent être appelées fsQuelqueChose (FS pour fenetre simple) et le fichier associé FSquelqueChose.cpp et .h

  • La forme principale doit est le propriétaire du Manager d'application.

  • Les composants TEdit sont nommés EDquelqueChose, les composants Label LBquelqueChose, etc...

  • Il faut toujours renommer un composant pouvant être modifié dynamiquement dans le code, et ne pas garder les noms donnés pas C++ Builder par défaut.

  • Les noms donnés à tous les objets graphiques ainsi créés avec l'EDI doivent refléter ce qu'ils font.

3.    Liaison interface - unités

  • Les méthodes de l'interface ne doivent pas exécuter directement du code spécifique, mais appeler une méthode de l'unité dont c'est la spécialité, de tester le résultat et de modifier l'affichage en conséquence.

 Exemple : plutôt que de faire

Void __fastcall fmMain : :BtgoClick()

{

               // initialisation

               For (int i=0 ; i<25; i++)

               donnees[i] = " "  ;

 

               //affichage

               SLaffichage->Items->Clear() ;

               For (int i=0 ; i<25 ; i++)

                          SLaffichage->Items->Add(donnees[i] );

}

faire

Void __fastcall fmMain : :BtgoClick()

{

               donnees.initialize() ;

 

               //affichage

               SLaffichage->Items->Clear() ;

               For (int i=0 ; i<donnees.size() ; i++)

                          SLaffichage->Items->Add(donnees.at(i));

}

ou encore

Void __fastcall fmMain : :BtgoClick()

{

               donnees.initialize() ;

 

               //affichage

               SLaffichage->Clear() ;

               donnees.toStringList(SLaffichage->Items) ;

}

  

IV.   TESTER

  • Tester très régulièrement et s’assurer que ce qui marchait avant et que l’on pense ne pas avoir trop de rapport marche toujours.

  • Tester les unité spécifiques en premier, et chercher à les valider entièrement (méthode publique par méthode publique) avant de les tester dans l’utilisation générale de l’application.

  • Pour chaque problème, tester en mettant des lignes en commentaire jusqu'à trouver à partir de laquelle on a un fonctionnement de l’unité conforme à ce qu’on attend de lui, et rajouter les lignes mises en commentaire les unes après les autres, de façon à trouver celle qui doit être changée.

 

V.     REFACTORISATION

Cette phase correspond à une implémentation qui marche mais dont le code est lourd à lire. Il faut donc réorganiser la façon dont cela a été codé afin de réduire le nombre de lignes ou pour permettre une meilleur réutilisation d’une unité.

  •  Faire une fonction spécifique lorsqu’on voit qu’un morceau de code est dupliqué plus de 2 fois.

Contacter le responsable de la rubrique C