Rapport de Stage

Michel JANTON
Etudiant Ingénieur-Maître
Université de La Rochelle
RAPPORT DE STAGE
JUIN 1994
TABLE DES MATIERES
TABLE DES MATIERES..................................................................................................................2
Avant propos.......................................................................................................................................3
I _ DESCRIPTION DU "DEFI FRANCAIS 95".............................................................................. 4
1.1 La Coupe America..........................................................................................................4
1.2 Le Secteur Tactique et Stratégie.....................................................................................4
1.3 Le Secteur Analyse Performance ...................................................................................5
II APERCU DU SUPPORT INFORMATIQUE DU SECTEUR ANALYSE................................... 6
2.1 Matériel ......................................................................................................................... 6
2.2 Logiciels......................................................................................................................... 6
III BORLAND C++ version 4.0......................................................................................................... 8
IV LE LANGAGE C++....................................................................................................................11
4.1 l'aspect objet................................................................................................................ 11
4.2 L'héritage...................................................................................................................... 11
4.3 Les fonctions virtuelles.................................................................................................13
V LA PROGRAMMATION SOUS WINDOWS............................................................................ 14
5.1 Concepts de base:......................................................................................................... 14
5.2 Gestion des événements:.............................................................................................. 14
5.3 Les ressources:..............................................................................................................15
VI LOGICIEL DESSINS DE SCHEMAS TACTIQUES (D.S.T.)................................................17
6.1 Généralités....................................................................................................................17
6.2 Description du Logiciel................................................................................................ 17
6.3 Réalisation du Cahier Des Charges.............................................................................. 17
6.4 Développement.............................................................................................................18
6.4 Problèmes rencontrés................................................................................................... 20
VII LOGICIEL D'ANALYSE DES PHASES TRANSITOIRES................................................... 21
7.1 Généralités sur l'analyse des données........................................................................... 21
7.2 Description du logiciel et cahier des charges............................................................... 21
7.3 Développement du logiciel...........................................................................................22
7.5 Phase de validation et évolution du logiciel................................................................. 28
VIII ENSEIGNEMENT RECU PAR CE STAGE.......................................................................... 30
8.1 Sur le développement de logiciel................................................................................. 30
8.2 Sur le fonctionnement d'une société............................................................................. 31
Postface.............................................................................................................................................32
 
    

2
Avant propos
Dans le cadre de la troisième année de l'Institut Universitaire Professionnalisé de
Génie Informatique de La Rochelle, j'ai effectué un stage de fin d'étude au sein du "Défi
Français", à la base nautique de Sète. Ce stage a débuté fin Mars 1994 et s'est achevé fin
Août.
Le "Défi Français" a pour but de préparer avec l'équipe du "Team Marc Pajot Canal+", l'America's Cup, importante compétion nautique qui se déroule tout les trois ans
et dont la prochaine édition aura lieu à San Diego (Californie), durant l'année 1995.
D'ampleur internationale, cette compétition regoupe, outre la France, l'Espagne,
l'Australie, la Nouvelle Zélande, le Japon et les Etats-Unis, tenant de la coupe. Demifinaliste en 1987 et en 1992, l'équipe regroupée autour de Marc Pajot s'est donné les
moyens de remporter la coupe en 1995.
En particulier, un très important travail de recherche a été mené par les concepteurs
des bateaux.
Le sujet principal de mon stage était le développement de logiciels en langage C++ et
sous environnement Windows. J'ai ainsi participé à la réalisation du logiciel "Dessin de
Schémas Tactiques" et du logiciel "Analyse des Phases Transitoires", logiciel de post
traitement de données.
Je tiens à remercier Monsieur Frédérique GRIZAUD, responsable du secteur
Analyse du "Défi Français", pour m'avoir accueilli au sein de son équipe, et Monsieur
Philippe BARIOD, mon Maître de stage qui m'a encadré et conseillé tout le long de ces
cinq mois.
Je tiens aussi à remercier Monsieur Hervé GUILLERMET qui m'a fait découvrir le
"Défi" et m'a accompagné durant ce stage.
 
    

3
I _ DESCRIPTION DU "DEFI FRANCAIS 95"
1.1 La Coupe America
Ancienne compétition nautique, l'America's Cup recouvre non seulement des enjeux
sportifs, mais aussi des enjeux économiques et techniques.
L'america's Cup se déroule en deux étapes.
Dans un premier temps, les "Challenger", c'est-à-dire les équipages non américains,
dispute la Coupe Vuitton .
Le vainqueur de cette coupe aura alors la possibilité de disputer l'America's Cup
contre le bateau américain, qui se sera montré le meilleurs lors de courses entre Defender,
soit les équipages américains, détenteurs du titre.
Sur le plan sportif, la compétition se présente sous la forme de séries de régates
opposant deux adversaires (Match Racing). Les bateaux utilisés sont des ACC, avec un
équipage de 16 personnes. Ces bateaux, par les hautes technologies utilisées employées
pour leur réalisation, sont comparables aux F1 du monde automobile.
C'est pourquoi la Coupe est très représentative du niveau technologique des
compétiteurs et que tous les grands pays industriels aimeraient y briller afin d'imposer leur
rang de grande puissance. Ainsi, ce n'est sûrement pas un hasard si, depuis leur victoire très
symbolique sur les Britanniques en 1851, les Américains n'ont perdu qu'à une seule reprise
la Coupe, exploit réalisé par les Australiens en 83. La remarquable prestation des Japonais
réalisée pour leur première participation en 92 est aussi très significative de l'enjeu. Ces
derniers seront d'ailleurs de très sérieux concurrents en 95.
Le Défi Français s'est lui aussi organisé afin d'être compétitif en 95. Ainsi, un très
important travail en Recherche et Développement a été mis en oeuvre pour obtenir un
bateau performant, et ceci dès la fin de la dernière coupe. Ceci permet de penser que le
Défi a mis toutes les chances de son côté afin de pouvoir remporter la prochaine édition de
l America's Cup, qui aura lieu à San Diego en 1995.
Ci-dessous, je décris les deux secteurs du "Défi" dans lesquels j'ai été amené à
travailler.
1.2 Le Secteur Tactique et Stratégie
C'est dans ce secteur qu'a débuté mon stage.
Ce secteur a pour rôle de fournir des outils d'aide tactique en navigation, l'objectif
finale étant l'élaboration d'un logiciel embarqué d'aide à la décision. Ce logiciel fournira
aux navigants des informations sur le parcours, la météo et sur l'adversaire. Le
développement a été confié à Philippe Bariod, qui travaille en collaboration avec Bertrand
Pacé et Thierry Péponnet, tacticiens du "Team", ainsi qu'avec Christian Dumard,
navigateur, et la cellule météo.
En préambule à ce logiciel, P. Bariod et moi-même avons développé un logiciel,
baptisé "Dessin de Schémas Tactiques". Ce logiciel permet aux tacticiens de réaliser les
schémas des cas rencontrés en match racing. A terme, on espère constituer une
 
    

4
bibliothèque sur support informatique qui aidera à la réflexion des choix tactiques, à terre
ou durant les régates, par l'intermédiaire du logiciel embarqué.
1.3 Le Secteur Analyse Performance
Ce secteur, dirigé par Frédérique Grizaud, a notamment réalisé toutes les campagnes
de mesures effectuées sur les bateaux laboratoires ("lab1" et "lab2") qui sont des ACC à
l'échelle 1/2. Il a effectué ensuite les mesures sur F3 et F4, le nouveau ACC du "Défi",
arrivé à Sète mi Juillet.
Le rôle de ce secteur peut se diviser en 3 parties qui sont:
_ l'installation et la maintenance de l'électronique embarquée
_ le développement du logiciel d'acquisition des données
_ l'analyse à terre des données
C'est pour cette dernière partie qu'il m'a été demandé de développer un logiciel
permettant de retracer les trajectoires à partir des données enregistrées et de pouvoir
visualiser sous forme de graphes tous les paramètres.
 
    

5
II APERCU DU SUPPORT INFORMATIQUE DU SECTEUR ANALYSE
2.1 Matériel
Le matériel utilisé provient d'UNISYS, fournisseur officiel du "Défi".
Pour le développement, j'ai utilisé un PC 486DX66, possédant un disque dur de 340
Mo et 16 Mo de mémoire vive. Les autres machines du secteur étaient du même type avec
une configuration semblable.
On possède par ailleurs un disque de 2 go qui contient les données enregistrées à
chaque sortie des bateaux et un lecteur de bande qui permet de les archiver.
Un lecteur CD-ROM est aussi utilisé notamment pour charger le logiciel "Borland
C++".
Enfin, un modem permet d'envoyer des fax, se connecter au Minitel ou encore
'envoyer vers l'extérieur des fichier via une messagerie.
La plus part des machines sont reliés par un réseau éthernet, ce qui permet d'échanger
facilement des données et partager l'imprimante, le CD-ROM ou encore le modem. On
peut noter que tout ceci se fait pour un coût relativement faible puisque qu'une carte
éthernet coûte entre 1000 et 1500F suivant les configurations.
2.2 Logiciels
DOS 6.0 :
Cette version du DOS permet notamment le transfert de données entre deux disques
dures de machines différentes, via la liaison série (interlink).
Windows 3.11:
Toutes les machines fonctionnent avec Windows 3.11, qui permet le fonctionnement
en réseau. L'installation de ce système d'exploitation est particulièrement simple, ainsi que
la gestion du réseau. En contre partie de la simplicité d'utilisation, ce gestionnaire de réseau
offre moins de possibilités que par exemple un réseau Novell. En effet Windows 3.11
permet que de mettre en réseau les fichiers et non pas les applications.
Borland C++
Ce logiciel a été choisi pour développer tous les logiciels utilisés par le "Défi", dans
la mesure où tous les programmeurs ont adopté le C++ et programment des applications
Windows.
Excell et Access
Ces deux logiciels font partie de l'"Office Pack" de MicroSoft, qui contient en plus
Word, Power Point (dessin) et Project. Il est à noter le très faible coût de cette ensemble de
logiciels, qui n'ont plus de concurrent sur le marché.
 
    

6
Access a été choisi pour créer la base de données. Simple, avec une interface très
conviviale, Access permet de consulter rapidement la base et d'obtenir toutes les
informations qui sont nécessaires.
Excell est utilisé pour analyser des données de quantité moyenne, en utilisant
notamment ses grands choix de graphes.
Sch 1: Architecture matérielle du secteur analyse
 
    

7
III BORLAND C++ version 4.0
On utilise le logiciel "Borland C++ 4.0" pour développer les différentes applications.
Voici les différents outils mis à la disposition du programmeur:
L'éditeur:
On peut choisir entre différents éditeurs, suivant les habitudes, notamment pour les
raccourcis claviers et les indexations. On peut aussi noter que l'éditeur identifie
automatiquement les commentaires, les constantes et les mots clé, et modifie leur couleur
ce qui rend le texte beaucoup plus lisible.
Le gestionnaire de projet:
C'est lui qui effectue le "makefile" de l'application, déchargeant ainsi le
programmeur.
Ce dernier réalise l'arbre des différents modules de façon visuelle.
Le Déboggueur:
Il est particulièrement convivial et facile d'utilisation, puisque je n'ai pas eu besoin
d'utiliser la documentation pour m'en servir.
On peut notamment mentionner que:
_ pour mettre des points d'arrêt, il suffit de placer le curseur à la ligne désirée et cliquer sur
un bouton de la barre d'outil. Le même bouton permet d'enlever un point d'arrêt. De plus
cette opération peut être faite dynamiquement, pendant l'exécution du programme.
_ il existe des boutons pour exécuter pas à pas, pour exécuter jusqu'à la position du
curseur.
_ on peut visualiser dans une fenêtre la valeur des variables.
_ on peut inspecter toutes les variables membres d'une même classe.
Par ailleurs, un outil spécifique à Windows, "WinSight", permet de visualiser tous les
messages reçus par les différentes fenêtres.
La bibliothèque OWL:
Cette bibliothèque est une version orientée objet de l'API de Windows.
Elle contient ainsi les classes de base pour utiliser et manipuler les objets d'interfaces,
comme TWindow ou TDialog. Elle facilite nettement la programmation Windows.
"AppliExpert" et "ClassExpert"
Ce sont des logiciels générateurs de code.
Ces deux outils aident considérablement le développeur.
AppliExpert crée automatiquement l'ossature d'une application typique de Windows,
en écrivant notamment les classes de base, (correspondant aux fenêtres, à l'Application...),
en y incluant un menu par défaut, en gérant les impressions.
AppliExpert crée un fichier de ressource, où il inclut les Menus, les boites de
dialogues standards, les icônes, etc.
ClassExpert permet de gérer les classes de l'application .
Ainsi, il peut créer des classes dérivées à partir de classes courantes (TDialog,
TWindow, TEdit...). On peut alors facilement surcharger les fonctions virtuelles et les
fonctions correspondant soit aux commandes du ou des menus, soit aux messages. Le
 
    

8
programmeur n'a plus qu'à écrire le code des fonctions, ClassExpert se chargeant d'écrire
les déclarations.
ClassExpert s'avère très efficace pour implémenter les classes correspondant aux
boites de dialogue créés dans les ressource , puisque qu'il crée la classe et permet d'inclure
tous les objets de contrôle associé à cette boite.
L'intérêt de ces outils est évident:
_ ils réduisent le nombre de lignes à écrire
_ ils évitent certaines erreur dû à des oublis
_ ils standardisent l'organisation du code, facilitant ainsi sa lecture et sa maintenance.
Malgré les progrès apportés, on note certaines lacunes:
_ on ne peut créer, et donc manipuler, n'importe quelle classe. seules des classes dérivées
de certaines classes de base peuvent l'être. En faite, la majorité des classes de l'application
doivent être écrite par le programmeur.
_ la gestion des classes n'est pas toujours simple. Ainsi, ClassExpert se bloque parfois
lorsque l'on veut enlever ou ajouter des classes.
Ainsi, ces outils nous laissent un peu sur notre fin, et semblent très en dessous des
possibilités offertes par "AppliBuilder" de "NextStep"
Resource Workshop (RW):
Cet outil permet de construire des objets d'interface, tel que les fenêtres de dialogue,
contenant les objets de contrôle (bouton, case d'édition, texte...), dessins (bitmap) pour les
icônes et boutons d'outils, les menus. C'est l'équivalent d'InterfaceBuilder de "NextStep".
Ainsi, le programmeur crée l'interface de son application en ayant directement son aspect
visuel. RW se charge de créer un fichier ASCII contenant toutes les informations
concernant les objets. On peut aussi sauvegarder des objets dans des fichiers à part, afin
d'être réutilisés dans d'autres applications.
A tous les objets, peut être associé un identificateur, qui est lui même associé à un
nom par l'intermédiaire d'un " #define ", contenu dans un fichier ".rh". Cet identificateur
est alors passé en paramètre lors de la création de l'objet dans le programme.
RW peut être utilisé seul, mais il est beaucoup plus intéressant de l'utiliser avec
AppliExpert car alors le .rh est automatiquement créé et mis à jour, et de plus, on peut créer
automatiquement le code associé aux objets "dialogue", directement accessible par
ClassExpert.
RW est, à mon sens, un outil indispensable puisqu'il permet d'avoir rapidement une
idée de l'interface de l'application, qui peut facilement être modifié, tout cela sans écrire
une ligne de code. De plus, l'association de l'objet d'interface avec l'objet de
programmation C++ est très simple. On peut néanmoins regretter que la manipulation des
identificateurs ne soit pas totalement transparent. En effet, pour éviter des conflits, le
programmeur doit parfois fixer lui-même ces identificateurs. Par ailleurs l'importation
d'objets n'est pas toujours facile. Il semble que le plus simple est d'utiliser le copier-coller,
mais celui-ci n'effectue pas la mise-a-jours du fichier rh.
En conclusion, on peut dire que les outils utilisés sont plutôt performants. On note
notamment la grande convivialité du logiciel, obtenu par ces barres d'outils et ses menus
flottants (contextuels) qui rend très rapidement accessible les différentes commandes.
 
    

9
On remarque aussi la tendance à programmer en manipulant simplement les objets, le
programmeur n'ayant plus qu'à décrire et construire, de manière plus ou moins visuelle, les
objets et à écrire les méthodes (comportement) spécifiques.
Néanmoins, on peut regretter le manque de documentations et la faiblesse des
explications fournies par "Borland".
 
    

10
IV LE LANGAGE C++
Le langage C++ est un langage orienté objet, particulièrement bien adapté pour
développer des applications utilisant une interface graphique comme Windows. Il reste
suffisamment proche du C, et peut être facilement utilisé par programmeurs plus habitués
au C.
Ainsi, toutes les applications développées par le défi ont été écrites en C++.
Ce langage présente de nombreux avantages, outre qu'une certaine prépondérance
dans le monde de l'informatique.
4.1 l'aspect objet
Cet aspect détermine une façon de développer et facilite l'organisation du code.
Une classe représente un objet.
Un objet a certaines caractéristiques, définies par ses variables.
Un objet a un comportement, défini par ses fonctions membres. Elles permettent de
manipuler l'objet et ses variables.
Cette approche facilite la programmation pour notamment deux raisons:
_ lors de la conception, les données correspondent aux objets informatiques, ce qui permet
une analyse "naturelle" du projet.
_ Le fait de regrouper les données simplifie ensuite leur manipulation. En effet, le
programmeur n'a, alors, plus qu'à utiliser les fonctions membres pour gérer l'objet sans
avoir besoins de considérer l'ensemble des paramètres (encapsulation).
Ceci implique une bonne analyse des différents objets et une certaine rigueur dans
l'écriture des fonctions membres, pour respecter l'encapsulation des données.
Il me semble néanmoins important de respecter l'aspect objet du C++ pour tirer
meilleure partie de ce langage.
4.2 L'héritage
C'est un des apports les plus significatifs du C++ .
Il permet principalement à une classe de récupérer simplement les données d'une
classe de base et ses fonctions membres, et donc de réutiliser du code.
Ainsi, on est très fréquemment amené à dériver les classes d'ObjectWindows,
notamment celles gérant les différentes fenêtres afin d'avoir des classes spécifiques.
On peut aussi créer des classes génériques à l'aide de l'héritage, ce qui permet de
gérer des ensembles d'objets de classes différentes par l'intermédiaire de leur classe de base
commune.
L'exemple ci-dessous est extrait du logiciel de Dessins Tactiques. "TObjet"
représente la classe de base des objets utilisés par l'applications, TBouee et TBateauCourse
sont des classes dérivées. On peut noter que les données communes comme "position",
"taille" et "orientation" sont regroupés dans la classe de base et non pas besoin d'être remis
dans les classes dérivées.
 
    

11
class TObjet
{
protected:
TPoint position;
float taille;
float orientation;
TRect zone_occupee;
int type;
t_courbe courbe;
int rayonOutline;
TPoint trace[MAX_PTS];
public:
TObjet();
virtual void dessiner(TDC* dc);
virtual void dessinerCourbe(TDC* dc) {courbe.Dessiner(dc);} ;
virtual void dessinerOutline(TDC*dc, int nbPts);
virtual void FaireGlisser(TDC* dc,TPoint point);
virtual void FairePivoter(TDC* dc,float angle);
virtual void SetPosition(TPoint point);
virtual void SetOrientation(float n_orientation);
void SetOutline(int Le_f_outline, int Le_rayonOutline);
void SetFlagNumero(int val);
void SetNumero(int Le_numero) {numero= Le_numero;};
BOOL PointDansObjet(const TPoint& point) {return zone_occupee.Contains(point);};
TRect GetZoneOccupee(){return zone_occupee;};
void SetCourbe(t_courbe La_courbe) {courbe= La_courbe; f_avecCourbe= 1;};
};
class TBouee: public TObjet
{
int type_bouee;
public:
enum {BOUEE_ISOLEE, BOUEE_DEPART, BOUEE_ARRIVEE,
BOUEE_SOUS_VENT};
TBouee();
TBouee(int le_type_bouee,TPoint point,float angle=0,float n_taille=1);
int GetTypeBouee() {return(type_bouee);};
void dessiner(TDC* dc);
void dessinerOutline(TDC* dc, int nbPts);
};
BOUEE_AU_VENT,
class TBateauCourse: public TObjet
{
TPoint dessinVoile[21];
int type_bateau;
int amure;
int formeVoile;
int angleVoile;
public:
TBateauCourse(); // barlins
TBateauCourse(int le_type,TPoint point=TPoint(0,0),float angle=0,float n_taille=1) ;
void dessiner(TDC* dc);
void FaireGlisser(TDC* dc,TPoint point);
void SetReglage(int Le_reglage, int dirVent);
void SetMastLine(int val);
void SetEngagement(int val);
 
    

12
int GetTypeBateau() {return(type_bateau);};
int GetAngleVoile() {return(angleVoile);};
private:
void CalculerAngleVoile(int dirVent);
void CalculerDessinVoile(TPoint dessinVoile[], int&nbPts);
};
4.3 Les fonctions virtuelles
Ces fonctions sont utilisées par les classes de bases, permettant aux classes dérivées
de surcharger ces fonctions afin de déterminer leur propre comportement.
Ainsi, on peut utiliser la fonction comme étant la fonction de la classe de base, mais
dont le comportement correspond à la fonction dérivée. Dans l'exemple précédent, la
fonction "Dessiner()" est déclaré virtuelle, puis surchargée dans les classes dérivées, ceci
permet dans le code de dessiner un objet sans savoir la classe exacte de l'objet. Le code
peut alors s'écrire:
class TSchema
{
TObjet** tableau;
int nb_objets;
int taille;
public:
TSchema();
~TSchema();
TObjet* Rechercher(TPoint point, TDC* dc);
void Ajouter(TObjet* un_objet);
void dessiner(TDC* dc);
};
void TSchema::dessiner(TDC* dc)
{
for (int i=0; i<nb_objets; i++)
{
tableau[i]->dessiner(dc); // appel a la dessiner propre à chaque classe dérivée de TObjet
}
}
 
    

13
V LA PROGRAMMATION SOUS WINDOWS
5.1 Concepts de base:
L'élément essentiel d'une application est ... sa fenêtre. C'est à travers elle que
l'utilisateur communique avec l'application. Ainsi, contrairement à une application
classique, une application Windows est organisée de manière à ce que ce soit l'utilisateur
qui commande l'application et non pas l'inverse.
L'application doit alors gérer par des fonctions (handler) les messages envoyer par
l'utilisateur par l'intermédiaire de la souris ou du clavier. Ces messages proviennent
essentiellement:
_ de la sélection d'un menu
_ d'un mouvement, d'un clic ou double clics de la souris
_ d'un clic dans un bouton
_ de l'entrée de texte dans une fenêtre texte.
_ ...
5.2 Gestion des événements:
Cette gestion se fait principalement au niveau des objets représentant les fenêtres, en
créant une table de réponse. Cette table indique que l'objet réagit à cet événement et précise
la fonction à exécuter.
Voici un exemple de table de réponse:
// GESTION DES MESSAGES RECU PAR LA FENETRE PRINCIPALE
DEFINE_RESPONSE_TABLE1(FenDst,TWindow)
//ev menu fichier
EV_COMMAND(CM_FICHIERNOUVEAU,CmNouveau),
EV_COMMAND(CM_FICHIERSAUVER_SOUS,CmSauverSous),
EV_COMMAND(CM_FICHIEROUVRIR,CmOuvrir),
EV_COMMAND(CM_FICHIERFERMER,CmFermer),
EV_COMMAND(CM_FICHIERINFOSCARACTERISTIQUES,CmInfos),
EV_COMMAND(CM_FICHIERRECHERCHER,CmRechercher),
EV_COMMAND(CM_FICHIERIMPRIMER,CmImprimer),
EV_COMMAND(CM_FICHIERCHOIX_IMPRIMANTE,CmChoixPrt),
//ev souris
EV_WM_LBUTTONDOWN,
EV_WM_RBUTTONDOWN,
EV_WM_MOUSEMOVE,
EV_WM_LBUTTONUP,
EV_WM_RBUTTONUP,
EV_WM_LBUTTONDBLCLK,
EV_WM_CHAR,
//divers
EV_WM_ACTIVATE,
END_RESPONSE_TABLE;
Les premiers messages proviennent du menu. Les noms des fonctions répondant aux
événements "souris" sont standardisés, c'est pourquoi on ne les indique pas dans la table.
De plus, certaines fonctions des classes de base d'ObjectWindows sont des handlers. Elles
sont en généralement déclarées virtuelles pour pouvoir être surchargées. C'est ainsi le cas
 
    

14
de la fonction Paint, associée à ev_paint qui est appelée lorsque la fenêtre doit être
redessinée.
5.3 Les ressources:
Windows permet de créer et de stocker des objets d'interface indépendamment du
code de l'application (et donc de manière statique).
Ces objets sont essentiellement:
_ des dessins bitmap (Icône)
_ Les menus
_ les boites de dialogue (Apparence, boutons, texte ...)
_ chaînes de caractères utilisées par les barres d'état.
Exemple de fichier de ressources:
/****************************************************************************
exemple.rc
produced by Borland Resource Workshop
*****************************************************************************/
#include <exemple.rh>
BITMAP_1 BITMAP
{
'42 4D 66 01 00 00 00 00 00 00 76 00 00 00 28 00'
'00 00 14 00 00 00 14 00 00 00 01 00 04 00 00 00'
'00 00 F0 00 00 00 00 00 00 00 00 00 00 00 00 00'
'00 00 10 00 00 00 00 00 00 00 00 00 80 00 00 80'
'00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80'
'00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF'
'00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF'
'00 00 FF FF FF 00 EE EE EE EE EE EE EE EE EE EE'
'44 4C EE EE EE EE EE EE EE EE EE EE 23 10 EE EE'
'EE EE EE EE EE EE EE EE 88 C8 EE EE EE EE EE EE'
'EE EE EE EE 00 31 EE EE EE EE EE EE EE EE EE EE'
'10 25 EE EE EE EE EE 00 0E EE EE EE 99 55 EE EE'
'EE EE E0 99 90 EE EE EE 10 25 EE EE EE EE 09 FF'
'F9 0E EE EE 9D 44 EE EE EE E0 99 99 99 90 EE EE'
'22 26 EE EE EE E0 99 9F 99 90 EE EE 00 01 EE EE'
'EE E0 9F 99 9F 90 EE EE 19 A2 EE EE EE EE 09 99'
'99 0E EE EE 20 02 EE EE EE EE E0 99 90 EE EE EE'
'44 4C EE EE EE EE EE 00 0E EE EE EE 01 03 EE EE'
'EE EE EE E9 EE EE EE EE 22 44 EE EE EE EE EE 99'
'EE EE EE EE 41 26 EE EE EE EE 99 9E EE EE EE EE'
'21 91 EE EE EE EE EE EE EE EE EE EE 02 54 EE EE'
'EE EE EE EE EE EE EE EE 45 F4 EE EE EE EE EE EE'
'EE EE EE EE 0B 0A'
}
#include "..\..\..\bc4\include\owl\editfile.rc"
 
    

15
DIALOG_1 DIALOG 45, 50, 189, 124
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CLASS "bordlg"
CAPTION "DIALOG_1"
FONT 8, "MS Sans Serif"
{
CONTROL "", -1, "BorShade", BSS_VDIP | BSS_LEFT | WS_CHILD | WS_VISIBLE, 135, 0, 1, 124
CONTROL "", IDOK, "BorBtn", BS_DEFPUSHBUTTON | WS_CHILD | WS_VISIBLE | WS_TABSTOP,
144, 14, 37, 25
CONTROL "", IDCANCEL, "BorBtn", BS_PUSHBUTTON | WS_CHILD | WS_VISIBLE |
WS_TABSTOP, 144, 49, 37, 25
CONTROL "", IDHELP, "BorBtn", BS_PUSHBUTTON | WS_CHILD | WS_VISIBLE | WS_TABSTOP,
144, 84, 37, 25
COMBOBOX IDC_COMBOBOX1, 11, 28, 84, 33, CBS_DROPDOWNLIST | WS_TABSTOP
LTEXT "Paramètres", -1, 13, 15, 60, 8
CONTROL "Radio", IDC_RADIOBUTTON1, "BorRadio", BS_AUTORADIOBUTTON | WS_CHILD |
WS_VISIBLE | WS_TABSTOP, 10, 58, 82, 10
CONTROL "Radio", IDC_RADIOBUTTON2, "BorRadio", BS_AUTORADIOBUTTON | WS_CHILD |
WS_VISIBLE | WS_TABSTOP, 11, 77, 81, 10
CONTROL "Check", IDC_CHECKBOX1, "BorCheck", BS_AUTOCHECKBOX | WS_CHILD |
WS_VISIBLE | WS_TABSTOP, 11, 100, 76, 10
}
IDM_EDITFILE MENU
{
POPUP "&File"
{
MENUITEM "&New", CM_FILENEW
MENUITEM "&Open...", CM_FILEOPEN
MENUITEM "&Save", CM_FILESAVE
MENUITEM "Save &As...", CM_FILESAVEAS
MENUITEM SEPARATOR
MENUITEM "E&xit", CM_EXIT
}
POPUP "&Edit"
{
MENUITEM "&Undo\aAlt+BkSp", CM_EDITUNDO
MENUITEM SEPARATOR
MENUITEM "&Cut\aShift+Del", CM_EDITCUT
MENUITEM "C&opy\aCtrl+Ins", CM_EDITCOPY
MENUITEM "&Paste\aShift+Ins", CM_EDITPASTE
MENUITEM "&Delete\aDel", CM_EDITDELETE
MENUITEM "C&lear All\aCtrl+Del", CM_EDITCLEAR
}
 
    

16
VI LOGICIEL DESSINS DE SCHEMAS TACTIQUES (D.S.T.)
6.1 Généralités
Ce logiciel permet de créer des schémas de situations en régate. Outre, la possibilité
de réaliser facilement de tels schémas, le logiciel fournit un moyen de stoker et de
s'échanger les schémas. Par ailleurs, les documents pourront être plus tard utilisés en
régates.
L'une des exigences à ce logiciel était la rapidité de sa réalisation, afin que les
tacticiens puissent en disposer le plus tôt possible. Ainsi, on a planifié son développement
sur un mois. En fait, il nous a fallu, à P. Bariod et moi-même, environ 40 jours pour obtenir
une première version utilisable.
Ma participation avec P. Bariod à la conception de ce logiciel m'a permis de m'initier
aux outils de développement, à "Borland C++" et à la programmation sous Windows.
6.2 Description du Logiciel
Le logiciel permet d'abord de placer des bateaux de course à différentes positions, la
trajectoire entre deux positions étant tracée automatiquement. De même les voiles
s'adapteront suivant la position du bateau et pourront être modifiés ensuite. D'autres objets
comme les bateaux comités, les bateaux spectateurs et les bouées pourront être ajoutés au
schéma. Chaque objet graphique peut être bougé et orienté à l'aide de la souris. De même,
on peut modifier la trajectoire.
Par ailleurs, l'utilisateur peut insérer des commentaires et "faire parler" les bateaux à
l'aide de bulle.
Les "laylines" (lignes correspondant aux trajectoires optimal) et les cercles autours
des bouées pourront être dessiné automatiquement.
Le schéma contient des informations caractéristiques qui sont en outre la date, le nom
de l'auteur, la référence à la règle.
On pourra de plus sauvegarder le schéma avec toutes ses informations et l'imprimer.
Ce logiciel doit être convivial et facile d'utilisation. De plus il doit respecter les
habitudes et conventions utilisées en match racing.
6.3 Réalisation du Cahier Des Charges
Le cahier des charges a été élaboré par P. Bariod avec les tacticiens du "Team".
L'interface (menu, fenêtre, boites de dialogue) a été définie à partir des idées des
futurs utilisateurs après avoir été clarifiées et organisées par P. Bariod.
Ce dernier a de plus défini les objets informatiques correspondants aux objets
graphiques qui pourront être dessinés ainsi que l'objet "conteneur". Il a en plus spécifié
certains algorithmes.
Il est à noter que, excepté quelques détails mineurs, le cahier des charges n'a pas été
modifié durant le développement.
 
    

17
6.4 Développement
Pour le développement, nous nous sommes répartis les tâches.
Ainsi il m'a été confié:
_ la réalisation du menu de la fenêtre principale
_ l'implémentation de différentes boites de dialogues
_ l'implémentation des objets graphiques et leur manipulation
_ l'implémentation des bulles et des commentaires
_ la gestion des barres de défilement
_ la réalisation des commandes de zoom (avant, arrière et tout).
_ l'impression du schéma et des informations caractéristiques
P. Bariod a pour sa part réalisé:
_ l'implémentation de l'objet contenant l'ensemble des objets graphiques
_ le tracé des trajectoires
_ le tracé des voiles
_ le tracé des laylines, des cercles.
_ la sauvegarde du schéma
_...
Ci-après est décrit de façon plus détaillée le travail que j'ai réalisé dans ce logiciel.
a_ Menu et boites de dialogue
Il s'agit d'une part de créer les ressources et d'autrepart d'écrire le code permettant
d'utiliser ces objets.
Le menu est composé de 4 menus déroulant:
_ menu fichier (nouveau, ouvrir, sauver, imprimer ...)
_ menu édition ( ajouter un objet, insérer un bateau, supprimer ...)
_ menu option (laylines, cercle, vent...)
_ menu zoom
Les différentes boites de dialogue sont:
_ la fenêtre de contrôle des objets
_ la fenêtre permettant de choisir une vue de départ
_ la fenêtre permettant de saisir les informations caractéristiques
_ les diverses fenêtres permettant de modifier les options
La réalisation des ressources se fait par Resource Workshop. Ceci est assez rapide.
L'écriture du code est par contre un peu plus long. En effet, si pour les menus il suffit
de créer une table de réponse, pour les boites de dialogue, il faut systématiquement
implémenter des classes dérivées de TDialog, contenant les différents objets de contrôles,
ainsi que les fonctions permettant de recueillir les données.
La fenêtre la plus complexe à réaliser fut la fenêtre de contrôle puisque elle devait
être interactive avec la fenêtre principale, obligeant à contrôler toutes les événement reçus
par cette boite.
Les différents menus et boites de dialogue se trouvent en annexe.
 
    

18
b_ Les objets graphiques
Les différents types d'objets sont:
_ les bateaux Défi
_ les bateaux adversaires
_ les bateaux comité
_ les bateaux juges
_ les bateaux WindJudge
_ les bateaux spectateurs
_ les bouées
_ les flèches
( voir leur représentation en annexe).
Chaque objet peut être bougé, tourné et agrandi, ce qui nous oblige de les représenter
sous forme vectoriel. Ainsi, chaque point de l'objet est calculé en fonction de sa position,
de son orientation et de sa taille.
La manipulation des objets se fait soit à l'aide de la souris, soit par la fenêtre de
contrôle.
Les fonctions permettant de gérer les objets avec la souris sont:
void EvLButtonDown(UINT, TPoint&);
void EvRButtonDown(UINT, TPoint&);
void EvMouseMove(UINT, TPoint&);
void EvLButtonUp(UINT, TPoint&);
void EvRButtonUp(UINT, TPoint&);
c'est à dire les handlers aux événements souris.
Par ailleurs, tous ces objets son dérivée de TObjet, classe générique, ce qui permet de
pouvoir les stocker et les manipuler facilement.
c_ Les bulles et les commentaires
Ces objets dérivent aussi de TObjet, puisqu'ils font aussi partie du schéma. Il peuvent
ainsi être bougés, voir tournés pour la bulle.
La difficulté supplémentaire provient de l'insertion du texte, qu'il faut redessiner dans
le schéma, tout en adaptant le contour du texte ou du commentaire. Pour cela, on utilise
une fenêtre de saisie, qui permet de saisir le texte et d'écrire simultanément dans la fenêtre
principale. Afin que la fenêtre de saisie puisse indifféremment servir pour les bulles et les
commentaires, j'ai utilisé une classe générique dont j'ai fait dériver les objets bulle et
commentaire.
d_ Les barres de défilement:
Ces barres permettent de se déplacer dans le schéma et pas se limiter à la taille de la
fenêtre.
La représentation de ces barres est déjà inclue dans la classe de base TWindow. Pour
pouvoir les manipuler, il suffit de leur associer un objet TScroller et de surcharger les
fonctions membres virtuels "HScroll()" et "VScroll()", qui sont les fonctions répondant aux
événements reçus par les barres.
e_ Zoom
Les commandes de zoom permettent d'agrandir ou de diminuer la zone visualisée
ainsi que d'avoir une vue de l'ensemble du schéma.
Pour cela, il faut modifier l'échelle et l'origine utilisées pour les tracés (repère
logique). Ceci s'est avéré un peu plus difficile à mettre en œuvre que prévu, car il fallait
que le zoom s'effectue par rapport au centre de la fenêtre, afin qu'il n'y ait pas une
 
    

19
impression de décalage pou l'utilisateur. Par ailleurs on devait s'assurer que la position des
barres de défilement restait cohérente lors des changements d'origine.
f_ Impression:
Pour l'impression, on a voulu laisser à l'utilisateur la possibilité de placer le schéma
où il le désirait sur la feuille, afin qu'il puisse être inséré dans un autre document.
Le code pour réaliser l'impression est assez simple puisque la classe TPrintOut de
OWL encapsule tout ce qui est "driver" et configuration d'impression. Il a suffi de réécrire
la fonction PrintPage, dans laquelle on écrit vers l'imprimante de la même façon que si on
écrivait vers la fenêtre.
L'impression se compose en fait du schéma et des informations caractéristiques ce
qui m'a obligé de diviser la fenêtre en deux parties, en modifiant le "viewport" ( zone
d'affichage physique).
6.4 Problèmes rencontrés
La principale difficulté rencontrée venait de mon manque de connaissance de
Borland et de bibliothèque OWL, ainsi que de l'API de Windows. J'ai dû en effet passer
beaucoup de temps à rechercher les fonctions et à savoir comment les utiliser correctement.
C'était notamment le cas lorsqu'il fallait modifier les échelles et les origines ou lorsqu'il
fallait retrouver le centre de la fenêtre. Souvent cela portait sur des détails anodins.
Sur le plan des méthodes de travail en général, une certaine rigueur était nécessaire
dans l'écriture du code, dans la mesure où ce code était réutilisé par P. Bariod. Ainsi, les
fonctions devaient être, évidement fiables mais aussi devaient permettre de manipuler les
objets en toute sécurité. On retrouve ainsi la notion d'encapsulation des données, l'idéal
étant que ces données puissent être manipulées uniquement par les fonctions membres.
Ceci n'a pas été toujours le cas, néanmoins la fusion des différentes parties s'est faite sans
grande difficulté.
 
    

20
VII LOGICIEL D'ANALYSE DES PHASES TRANSITOIRES
7.1 Généralités sur l'analyse des données
Actuellement les données sont sauvegardées sous le format "ockam", la centrale
d'acquisition utilisée sur les bateaux. Ce sont des relevés réalisés au 1/4 s. Ces fichiers
restent difficilement exploitables. D'abord, leur taille est très importante (entre 4 et 12 Mo),
ensuite il contient des erreurs dû à des pertes d'octets sur le bus. Enfin, la fréquence
d'échantillonnage n'est pas toujours exactes ce qui rend difficile de dater les données avec
précision.
Jusqu'à présent, on a utilisé des fichiers de données échantillonnées à 30s, qui sont
les points moyennés des points "1/4s". Ces points "30s" sont suffisants pour l'études des
performances en régime stable du bateau et permet d'avoir ces caractéristiques globales.
Mais ces données deviennent insuffisantes pour analyser des manoeuvres dont la durée est
en général inférieure à la minute.
Or, en régate, seulement 20% du temps se fait en régime stabilisé pour 80% en
régime transitoire, d'où l'intérêt de pousser plus loin l'analyse et de développer des outils
permettant d'étudier aisément les points au "1/4" de seconde.
7.2 Description du logiciel et cahier des charges
Le problème provient du fait qu'on ne sait pas exactement comment analyser une
manoeuvre et en particulier on ne sait elles vont être les valeurs caractéristiques à calculer.
Par conséquent, le logiciel devra permettre d'abord une analyse qualitative, puis une
analyse quantitative qui devra être affinée.
Pour l'analyse qualitative, on désire pouvoir afficher la trajectoire et chaque
paramètre mesurés sur le bateau (vitesse, angle de barre, vent, gîte ...) sous forme de
courbe. On veut aussi pouvoir se déplacer avec un curseur sur la trajectoire et comparer les
valeurs des différents paramètres à la position donnée.
Pour l'analyse qualitative, on va procéder de la manière suivante:
a) on définit 3 temps sur la trajectoire (graphiquement dans une première version),
correspondant au début du virement (t0), à la fin de la montée au vent (t1), à la fin de la
relance (t2).
b)on calcule:
_ entre t0 et t2, la perte de VMG (gain sur l'axe du vent) par rapport à une trajectoire
rectiligne, les minima et maxima de la vitesse du bateau, de l'angle au vent apparent et de
la barre.
_ entre t0 et t1, le taux de giration, la perte de vitesse, le gain au vent et le rayon de
courbure
_ entre t1 et t2, la perte au vent, l'accélération et le rayon de courbure.
 
    

21
De plus, on veut pouvoir calculer entre 2 temps les accélérations, les rayons de
courbure ainsi que le VMG.
Sur les graphes, on veut pouvoir calculer les minima , maxima et les moyennes de
chaque courbe.
Par ailleurs, le logiciel sera amené à évoluer. Ainsi, la construction du logiciel devra
être suffisamment général pour pouvoir ajouter par la suite de nouveaux outils d'analyse.
7.3 Développement du logiciel
a_ L'interface utilisateur
Les fenêtres:
J'ai choisi d'utiliser une interface multi-documents, qui se compose d'une fenêtre
principale et de fenêtres filles, qui peut être icônisées et déplacées à l'intérieure de le
fenêtre mère. De plus, une barre d'outils et une barre d'état sont insérées à la fenêtre
principale. La barre d'outils contient notamment les boutons permettant de se déplacer sur
la courbe, alors que la barre d'état permet de fournir des informations sur les commandes
sélectionnées.
Sch 2: Apparence générale de l'application
Les menus:
Il y a 3 menus différents suivant que soit la fenêtre principale, une fenêtre contenant
un graphe ou une fenêtre contenant une trajectoire qui est sélectionnée.
Le menu principale est composée:
_ d'un menu Fichier, permettant d'ouvrir des fichiers "30s" ou "1/4s", d'imprimer ou de
sortir de l'application.
_ d'un menu Fenêtre permettant d'organiser la position des fenêtres
_ d'un menu donnant des informations sur le logiciel.
 
    

22
A ce menu de base, vient s'ajouter pour les fenêtres filles un menu graphe et un menu
outils, dont le contenu diffère suivant qu'il s'agit d'une fenêtre graphe ou d'une fenêtre
trajectoire.
Fenêtre "trajectoire" et fenêtre "graphe"
La fenêtre graphe contient d'une part une ou plusieurs courbes de paramètres
provenant soit de la même manoeuvre soit de manoeuvres différentes et d'autre part des
valeurs des paramètres au temps fixé par le curseur.
La fenêtre trajectoire contient en plus du tracé de trajectoire, l'affichage des valeurs
de la barre, de la vitesse du bateau, de son cap, de la force du vent et sa direction.
Fenêtres de dialogue
Elles sont au nombre de 3, auxquelles viennent s'ajouter les fenêtres permettant
d'afficher les résultats.
L'une permet de choisir le paramètre à afficher dans une fenêtre graphe.
Une autre sert à modifier l'échelle des graphes et offre la possibilité de choisir
différentes option (échelle optimum, échelle identique pour chaque courbe ...).
Enfin, la dernière sert à saisir les temps soit directement au clavier, soit à l'aide du
curseur.
En annexe, est représentée chaque boîte de dialogue, ainsi que les menus.
b_ Organisation des données
L'objet TParametre
C'est l'objet de base qui encapsule les données. Il contient notamment le tableau de
données en eux-mêmes, ainsi que des attributs permettant de définir le paramètre temps.
Celui est déterminée par l'équation: t = début + i.delta_t, i étant l'indice du tableau des
données.
Il contient en plus des informations sur l'origine du paramètre, c'est-à-dire le nom du
bateau sur lequel a été enregistré les données, la date et l'heure de la manoeuvre.
L'objet TCourbe
Il est composé de un ou deux paramètres, correspondant à la composante Y et X de la
courbe. Si X est initialisé à NULL, Y est représenté en fonction de son paramètre temps.
Il possède aussi les attributs xmin, ymin, xmax et ymax pour définir les limites de la
courbe et des axes. Si l'indicateur "f_autoscale" est vrai alors les minima et maxima
correspondent à ceux des deux paramètres X et Y.
Les objets de type "Doc" et "View"
Chacune des entités "Trajectoire" et "Graphe" sont divisées en deux couches, une
couche "visualisation" et une couche "document".
La couche "document" sert à encapsuler les données sous forme de liste soit de
paramètres, soit de courbes. La couche "Visualisation" est utilisée pour représenter le
document à l'écran.
 
    

23
Sch 3: Objets Trajectoire et Graphe
Lecture des données
La lecture des données se fait soit dans un fichier "30s" (d'extension db1), soit dans
uns fichier "1/4s" (d'extension pai). Pour cela, j'ai défini deux objets "Document", TTrjDoc
et TTrj2Doc, le deuxième dérivant du premier.
Les fichiers PAI sont composés d'une première série de colonnes comportant les
paramètres jugés indispensables aux différents calculs. A ces paramètres, peuvent s'en
ajouter d'autres qui pourront être utilisés par la suite.
Les fichiers DB1 ont par contre un nombre fixé de champs dont certains peuvent être
vide. Dans ce cas là, la fonction GetVal() de TParametre retourne zéro.
A partir des paramètres lus, on calcule "X", "Y" et "Courbure".
Ces paramètres peuvent par la suite être recopiés dans un objet TGraphDoc à l'aide
de la boîte de dialogue "AddParam". Le fait de faire une recopie au lieu d'utiliser une
référence assure aux objets graphes une parfaite autonomie.
sch 4: Ajout de courbes
 
    

24
c_ Gestion du temps
Déplacement des curseurs
La barre d'outils contient des boutons plus un curseur qui permet de balayer toute la
durée d'une manoeuvre. Un point rouge sur la trajectoire et une barre rouge sur le graphe
permet de visualiser la position courante. Un déplacement du curseur entraine la mise-àjour de ces marques, ainsi que des valeurs des paramètres affichés.
sch 5: Modification du temps courant
Saisie des temps
L'utilisateur va être amené à sélectionner des temps soit pour analyser les
manoeuvres soit pour définir l'intervalle de calcul. Ceci se fait par l'intermédiaire de la
boîte de dialogue, "TDTemps". Elle permet de visualiser les temps enregistrés et de les
modifier, soit directement au clavier, soit à l'aide du curseur, le temps s'affichant
simultanément dans la barre d'outils et dans la fenêtre de dialogue.
Par Ailleurs, pour bien visualiser la position choisie, on affiche des marques sur le
graphe ou sur la trajectoire.
sch 6: système de saisie des temps
 
    

25
d_ Algorithmes de calculs
Calcul de la trajectoire
La trajectoire tracée correspond à "l'estime", c'est-à-dire celle déduite de la vitesse et
du cap du bateau. Or, comme la vitesse est en fait une vitesse mesurée par rapport à l'eau,
on obtient une trajectoire dite de surface.
Celle-ci est différente de la trajectoire sur le fond à cause du courant. Il est à
remarquer que la trajectoire fond peut être mesuré par un GPS.
Pour le calcul, on utilise les approximations:
X(t+dt) ~ X(t) + X'(t).dt
Y(t+dt) ~ Y(t) + Y'(t).dt
d'où les formules de récurrences:
X0 = 0
Xn = Xn-1 + Vxn . delta_t
Y0 = 0
Yn = Yn-1 + Vyn . delta_t
avec
Vx = VitBateau . sin (AngleCompas)
Vy = VitBateau . cos(AngleCompas)
Il faut noter que ce calcul ne fait pas intervenir l'angle de dérive qui peut faire varier
la direction du bateau de deux ou trois degrés par rapport à son cap.
comparaison estime/gps
0.8
0.6
0.4
0.2
0
-0.2
-0.4
-0.6
-0.8
-0.4
-0.2
0
0.2
0.4
0.6
0.8
Sch 7
 
    

26
Calcul des dérivées première et seconde
J'utilise la formule de Taylor:
f(t+dt) = f(t) + f'(t)dt + f''(t)dt²/2 + o(dt²)
f(t-dt) = f(t) - f'(t)dt + f''(t)dt²/2 + o(dt²)
d'où
f'(t) = (f(t+dt) - f(t-dt)) / (2dt) + ε avec | ε | < | fmax - fmin | . dt
f''(t) = ( f (t+dt) + f (t-dt) - 2f (t) ) / dt² + ε
avec | ε | < | fmax - fmin | . dt²
Calcul des accélérations et du rayon de courbure
L'accélération tangentielle correspond à la dérivée de la norme de la vitesse.
L'accélération radiale se calcule par la formule:
ar = v . (dθ/dt)
où θ correspond à l'angle de compas.
Le rayon de courbure se calcule par la formule:
Vitesse = R * (dθ/dt)
d'où R = v / (dθ/dt)
Calcul du VMG (Velocity Made Good)
Le VMG est la composante de la vitesse suivant l'axe du vent, axe orienté suivant la
direction d'où vient le vent et peut se calculer par la formule:
VMG = (distance/ delta_t) * cos (TrueWindAngle) (cf sch ci-dessous )
sch 8: Calcul du VMG
 
    

27
Il existe déjà un paramètre VMG "instantanée" fourni par la centrale d'acquisition
Ockam. Mais celui devient très approximatif à cause du temps de réponse des capteurs, lors
des manoeuvres.
Pour calculer le VMG dans un virement on décide de prendre:
_ comme direction du vent, la moyenne entre la direction mesurée au début de la
manoeuvre et celle mesurée à la fin.
WindDir = (WindDir0 + WindDir1) / 2
_ comme distance, on prend
d = √ (x1 -x0)² + (y1 - y0)²
où P(x0,y0) et P(x1,y1) sont les positions estimées.
Ce calcul ne tient pas compte du courant ni pour la direction du vent ni pour la
distance parcourue. Ceci n'est pas gênant dans la mesure où on désire avec le VMG
connaître le comportement propre du bateau, donc indépendamment du milieu extérieur.
7.5 Phase de validation et évolution du logiciel
Une fois le développement achever, je suis passé à une phase de validation du
logiciel consistant à déterminer et rectifier tous les défauts et mal fonctionnements du
logiciel. Cette phase définit de plus des modifications ou ajouts plus importants pour que le
logiciel soit plus performant.
Notamment, je prévois d'apporter des modifications aux niveaux de la lecture de
données et dans l'analyse des résultats.
Lecture des données
Actuellement, le fichier PAI est créé par un autre logiciel, CORRECT10, écrit par P.
BARIOD en 1992. Ce logiciel permet d'extraire une manoeuvre, connaissant son heure de
début, d'un fichier "Ockam". Cette manipulation devient vite fastidieuse vue le nombre
importants de manoeuvres qu'on ne peut extraire qu'un par un. De plus, il est difficile de
connaître l'heure de début des manoeuvres à moins de les noter sur l'eau. L'utilisation d'un
fichier "30s" s'avère pas suffisamment précis pour détecter facilement une manoeuvre.
Lorsque le système d'acquisition "VME" sera mis en place, on prévoit de lire un
fichier "1/4s" et de créer des fichiers "PAI" directement avec le logiciel, ce qui rendra le
tâche plus facile.
Analyse des manoeuvres
Dans sa forme première, le logiciel permet de choisir une partie de trajectoire
définissant l'intervalle de calcul et effectuer une analyse de la manoeuvre. Les résultats
peuvent être imprimés. De plus, deux fenêtres "résultat" peuvent être simultanément
affichées ce qui permet de faire des comparaisons entre deux manoeuvres.
 
    

28
Cette analyse reste néanmoins limitée. Il semble en effet indispensable de pouvoir
analyser l'ensemble des manoeuvres. Pour cela, on prévoit de mettre en place une base de
données, réalisée à partir des résultats. Cette base de données devrait permettre d'effectuer
des statistiques et de définir des valeurs de référence.
Ceci implique de sauvegarder les résultats soit dans un fichier, soit directement dans
la base.
On avait aussi prévu de pouvoir sauvegarder des courbes qui serviraient de référence
à d'autre trajectoire. Mais ceci ne semble pas à priori d'une utilité primordiale.
Par contre, il semble intéressant d'améliorer l'analyse qualitative en permettant
d'afficher dans une même fenêtre deux trajectoires. Ceci implique de pouvoir synchroniser
les manoeuvres.
 
    

29
VIII ENSEIGNEMENT RECU PAR CE STAGE
8.1 Sur le développement de logiciel
Durant ce stage, j'ai pu me rendre compte de toutes les difficultés du développement,
de la réalisation du cahier des charges jusqu'à la mise au point du logiciel. Ci-dessous, j'ai
fait la synthèse des différentes remarques importantes pour le développement.
Le cahier des charges et l'analyse
De la réalisation du cahier des charges dépend tout ce qui suit. Cette étape demande
une collaboration étroite entre le programmeur et les utilisateurs, afin de définir les
fonctionnalités du logiciels. Il s'agit souvent d'établir des compromis entre les besoins et les
délais demandés pour pouvoir se fixer des objectifs raisonnables. Le programmeur doit
aussi mettre au clair les différentes idées des utilisateurs, en fonctions de ces connaissances
en objet d'interface et manipulations de données informatiques.
Ceci demande principalement de l'expérience. Il ne faut négliger aucune des
différentes phases et pouvoir estimer leur durée respective.
La phase d'analyse est aussi primordiale. Elle détermine les différents objets et
modules à implémenter. Une bonne ou mauvaise analyse peut faire gagner ou perdre
beaucoup de temps. Elle doit notamment être aussi exhaustive que possible afin de pouvoir
écrire le maximum de code et limiter les compilations. Il semble en effet désastreux pour le
rendement d'ajouter sans cesse des bouts de codes entre deux compilations.
Elle doit par ailleurs être suffisamment bien construite pour pouvoir apporter des
améliorations futures.
La construction d'interface graphiqhe
L' interface n'est pas à négliger puisqu'elle détermine la manière dont va pouvoir être
utiliser le logiciel. Celle-ci doit être suffisamment conviviale et simple, afin que
l'utilisateur ne soit pas gêner dans sa tâche.
Ceci demande souvent du temps pour être mis au point.
Il faut pouvoir se mettre à la place de l'utilisateur, qui n'est lui n'est en générale pas
informaticien et n'a pas les mêmes habitudes.
Enfin sa réalisation nécessite une bonne connaissance de la bibliothèque utilisée en
l'occurrence "OWL" et "API" et donc de passer beaucoup de temps à se documenter.
L'écriture du code
Le code doit pouvoir être lu et réutiliser le plus aisément possible par un autre
développeur. Dans cette perspective, il est souhaitable d'utiliser des conventions.
Ces conventions portent sur la syntaxe (placement des virgules, des points virgules,
accolades), sur les noms des variables et des classes, qui doivent par ailleurs suffisamment
expressifs.
On aura aussi soins de mettre des commentaires, si nécessaire.
 
    

30
sch 9 : les différentes phases de développement
8.2 Sur le fonctionnement d'une société
Problème d'organisation
L'objectif du Défi n'étant pas productif, le financement des différents secteurs est un
peu particulier. Néanmoins le fonctionnement est semblable aux autres sociétés, avec tous
les problèmes de délais à respecter, de budget à ne pas dépasser, aux problèmes clientsfournisseurs.
Bien que faisant partie intégrante du "Défi", le secteur Analyse essaie de fonctionner
de manière autonome, avec son propre budget et sa propre organisation. Il est ainsi amené à
considérer les autres secteurs ("Team", concepteurs, voilerie ...) comme ses "clients".
Ceci permet de travailler avec une équipe restreinte, d'une dizaine personnes, ce qui
favorise la communication et simplifie le côté administratif. Malgré tout, la logistique reste
un problème permanent.
Problèmes de communication
La communication est primordiale dans une société.
Ainsi régulièrement étaient organisées des réunions de travail ou briefing au niveau
du secteur et au niveau de l'ensemble du "Défi".
Les briefing du secteur permettent de faire le bilan du travail de chacun et de se
refixer de nouveaux objectifs. Ceci est particulièrement important pour la motivation de
chacun et pour le travail effectué corresponde bien aux différents besoins.
Les briefing généraux permettent de voir l'avancement de l'ensemble du "Défi". Ils
servent aussi à présenter l'activité de chaque secteur. Il est en effet important que tous les
secteurs soient sensibilisé à l'activité des autres dans la mesure où ils sont souvent amenés
à collaborer.
L'exemple du problème de la qualité des mesures pour cela très significatif.
En effet, plusieurs secteurs sont concernés, les navigants qui peuvent juger sur le
bateau si les mesures semblent correctes, les électroniciens qui savent si les capteurs sont
bien étalonnés et enfin l'analyste qui traite les données. Or chacun a sa vision du problème
mais aucun n'a la vue d'ensemble.
 
    

31
Seul une collaboration étroite entre les différents secteurs peut résoudre pleinement le
problème.
Postface
Participer au "Défi Français", a été une expérience particulièrement passionnante,
tant sur le plan technique que sur le plan humain.
J'ai ainsi pu apprendre la programmation sous Windows, interface qui est devenu un
standard dans le monde et dont l'utilisation risque encore de se renforcer avec la nouvelle
version 4.0. Sûrement plus important, j'ai aussi appris à gérer un projet dans le temps, à me
fixer des objectifs et à les atteindre dans les délais demandés.
Mais l'expérience humaine a été a mon avis encore plus enrichissante.
En effet, participer à un challenge d'envergure international a été extrêmement
motivant. Chaque personne que j'ai rencontré au "Défi", navigants, techniciens ou
ingénieurs, travaille avec la même passion pour atteindre leur but commun à tous: rapporter
la Coupe de l'America en Europe.
L'esprit de travail était très stimulant, et ceci malgré un contexte économique
difficile.
J'espère pouvoir garder un tel esprit dans la suite de ma carrière professionnelle.
 
    

32