L'autre partie des uses cases (coté concepteur) est aussi disponible sur le FTP en v0.1 .
De la même chose ce pour le moment qu'une ébauche

lien

Temps de réalisation : 45 min

Nouvelle version du diagramme de classe
Petites corrections mineures :

Changement des nommages de liaison entre les classes à l'infinitif

Changement des types des attributs dans chaque classe

Ajout d'attribut qui avait été oublié dans la classe Utilisateur et la classe Arrête

Modification de la multiplicité entre carte et graphe pour permettre à un graphe de représenter plusieurs cartes

disponible ici

Temps de réalisation : 15 min

Postez un commentaire !

Voici les dates butoires que nous nous sommes fixés au niveau du projet

Rapport préliminaire 22 octobre : fait

Analyse

Diagramme de classe 18 octobre : fait

Uses cases : 2 novembre : fait

Diagramme de séquences 3 novembre : en cours

Diagramme état transition 5 novembre : en cours

Finalisation analyse 8 novembre :

Implémentation

Traitement d'image pour les cartes 22 novembre :

Implémentation base de données 22 novrembre :

Calcul de chemin 22 novembre :

Implémentation des classes 22 novembre :

Interface Java-BDD 29 novembre :

Implémentation gestion de profil : 13 décembre

Couche graphique : 5 janvier

Postez un commentaire !

L'analyse a été terminée il y a maintenant presque 2 semaines, je ne met le billet que maintenant car il manquait quelques détails à régler sur certains diagrammes et aussi parce que tous n'étaient pas encore sur le FTP

Donc depuis il a été fait :
Les diagrammes de séquences qui sont disponible ici

Creer Graphe

Modifier Graphe

Supprimer Graphe

ajouter carte

Supprimer Carte

s'identifier

Creer Profil

Modifier Profil

Supprimer Profil

Changer de profil

Saisir Itinéraire

Voir ses Itinéraires

Charger itinéraire (via profil)

Sauvegarder itinéraire dans profil

Temps de Réalisation : 5 heures environ

Les diagrammes d'état transitions suivants

Sommet

Carte

Graphe

Itinéraire

Arrete

Utilisateur

Temps de réalisation : environ 2h30

Et enfin les uses cases disponibles en plusieurs versions
Uses cases simplifiés version utilisateur et concepteur

Temps de réalisation : environ 30 min

uses cases utilisateur version développée
uses cases concepteur version développée
Temps de réalisation : environ 1h30 min

Postez un commentaire !

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 (!)

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

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

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

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