Implementation

Le développement des graphes est maintenant quasi terminé.
Les différentes classes et méthodes ont été écrites, il ne reste plus qu'à interfacer avec la base de données et l'interface, et tester les méthodes.

Temps de réalisation 5-8h

Afin de respecter le cahier des charges et de rendre l'application portable, il était nécessaire de concevoir l'interface graphique de sorte qu'elle s'adapte à une plate forme donnée.

Notre choix d'API s'est donc logiquement porté sur SWING. (concepteur et utilisateur)
Ensuite l'utilisation de gestionnaire de mise en forme est obligatoire (Layout), pour l'interface concepteur j'ai choisi d'utiliser le plus simple : BorderLayout et d'imbriquer des panneaux.

Ainsi dans la fenetre principale se trouve uniquement 2 panneaux et un menu :
Menu situé au nord
Panneau 1 situé au centre (affichage des cartes)
Panneau 2 situé à l'EST

Le panneau 2 utilise aussi un BorderLayout, et est décomposé comme suit :
Un panneau déroulant de "choix" qui sert en fait afficher la liste des cartes disponibles situé au SUD
un panneau d'option qui indique à l'utilisateur quelle action il peut effectuer, il est situé au centre.

Pour l'affichage des cartes, j'ai choisi d'utiliser un composant de type JList à l'intérieur d'un JScrollPane pour permettre de dérouler une liste longue.
Je réfléchis en ce moment à intégrer une barre de recherche de carte pour faciliter la sélection.

Le menu lui est classique on y trouve :
- Un menu fichier
--- nouveau pour recréer une base de données
--- ouvrir pour ouvrir une base de données existante
--- sauvegarder pour sauvegarder la base de données courante
--- charger pour charger une base de données
--- fermer pour quitter l'application

-Un menu carte permettant de gérer les cartes
--- Ajouter pour ajouter une nouvelle carte a la base de données
--- Modifier pour modifier les informations de la carte
--- Supprimer pour effacer la carte de la base de données

-Un menu aide
--- Documentation pour aider a créer les graphes
--- a propos pour les informations sur le programme

Temps de réalisation : 6h

En implémentant les graphes un problème s'est posé. Comment lorsque l'utilisateur sélectionne un sommet sur l'UI, retrouver le sommet correspondant sur le graphe.
Il était évident qu'il fallait parcourir le graphe et cherche un sommet égal a celui sélectionné

Mais comment définir que 2 sommets sont égaux ?

Nous avons fait le choix de dire que :
2 sommets sont égaux si et seulement si leurs coordonnées associées à une carte sont les mêmes.
(en effet 2 sommet de 2 cartes différents peuvent avoit les mêmes coordonnées)

La seconde problématique qui a découlé de ce problème est : comment déterminer qu'un sommet appartient à telle ou telle carte ?

Pour résoudre ce problème nous avons mis en place le système suivant.

- Un graphe global pour toutes les cartes permettant une recherche d'itinéraire complète.
- Un sous graphe spécifique à chaque carte, donc ajout d'un attribut : identifiant de carte dans chaque objet graphe.
- Une valeur spéciale sera assignée à cet attribut pour repérer le graphe global.

Ainsi, lorsque l'utilisateur clique sur un sommet de la carte, on récupère les coordonnées, on fait un parcours du graphe en cherchant des coordonnées égales (la méthode equals a été redéfinie à cet effet) et on propose les options possibles à l'utilisateur sur ce sommet.


Temps de réalisation : 2h

Même si j'avais un peu commencé avant les vacances de noel, c'est pendant que j'ai vraiment attaqué le développement des graphes
Un problème s'est vite posé, comment les implementer en machine et en langage objet correctement.

J'ai opté pour la solution suivante :
On aura les classes suivantes :
* Graphe
* Sommet
* Arrete
* Sommet_ListeVoisins (Qui comprend un sommet et la liste de ses voisins(une liste de SommetArrete)
* SommetArrete qui comprend un sommet et une arrete

L'écriture de toute les méthodes spécifiques à ces classes est en cours.


Temps de réalisation : 1h

Nous nous sommes mis à la recherche d'un moyen de stocker les données du programme, qui soit le plus pratique possible.
Nous avons écarté le choix du fichier par commodité au niveau des multiplicités entre les classes.
Il apparait qu'une base de donnée relationnelle parait mieux adaptée.

Nous avons donc regarder ce qui se faisait en SGBD relationnel. Nous avons d'abord délimiter la recherche : il nous fallait quelque chose qui ne nécessite pas une connexion à un serveur distant pour permettre l'utilisation du programme hors connexion.

Notre choix s'est tout d'abord porté sur Firebird 2.0 qui propose une version embedded (embarquée). Mais nous avons du changer pour un problème de portabilité

En effet nous travaillons sur un java development kit 1.6 et les seuls driver disponible pour cette plateforme était des drivers OBDC. Nous avons pensé qu'il risquerait d'y avoir des problèmes de portabilité sous linux notamment.
Les dernière version de driver JBDC étant actuellement pour un jdk 1.5

Ainsi notre choix final s'est porté sur Java DB ou Apache Derby, la base de donnée fournit en natif avec la version 1.6 de java.
Vu qu'elle est intégrée aucun problème de portabilité ou de driver JBDC et en plus elle propose une version embedded tout comme firebird 2.0

Seul problème sur lequel nous travaillons actuellement, elle ne propose pas une interface d'administration très pratique..
Mais nous avons d'ore et déjà réussi à charger les driver, créer une base s'y connecter et créer quelques tables.
Nous sommes en ce moment en train d'avancer sur les requêtes.

Temps de réalisation : plus de 10h (!)

Nous allons reprendre dans les grandes lignes les conventions adoptés par JAVA à savoir

Attribut de classe : minuscules

Attribut : minuscules

Constante : majuscules

Nom de Classe : Première lettre de chaque mot en majuscule

Objet : minuscule

Nom de méthode : premier mot minuscule et première lettre de chaque mot suivant en majuscule

Methode de Classe(ou statique) : idem

Variable locale : minuscule

Pour l'indendation à chaque bloc d'instruction à la ligne avec
{
indentation ici
}

Temps de réalisation : 10 min

Postez un commentaire !

Pour assurer un travail en équipe cohérent, lisible et compréhensible dans les 2 sens
nous avons décidé de se réunir pour discuter de la mise en place d'une convention d'écriture du code ainsi que de l'indentation.

Donc les conventions d'écriture sont à déterminer pour les éléments suivants (en vrac) :

Attribut de classe (ou statique)

Attribut

Nom de Classe

Objet

Nom de méthode

Methode de Classe(ou statique)

Variable locale

La reflexion pour l'indendation doit porter sur :

Indentation des blocs d'instructions

Accolade


NB : Liste certainement non exhaustive

Postez un commentaire !