Présentation du travail réalisé

L'intégrale du rendu concernant les spécifications est ici. Dans la page ci dessous est exposé par ordre chronologique l'élaboration des documents que vous trouverez dans le tarball. Nous vous invitons à consulter le repository pour plus de renseignements et une chronologie plus détaillée. Le lien vers le repository se trouve sur la droite du bandeau.

Élaboration du cahier des charges

Pour constituer ce cahier des charges nous nous sommes basé sur les exigences disponibles sur l'extranet. Nous avons ensuite élaboré des hypothèses quand à l'utilisation de l'application. Cette phase a façonnée la vision que nous avions de l'application et de ses fonctionnalités. Le document complet est disponible ici.

Arbre de fonctionnalités

L'arbre de fonctionnalités à été élaboré pour énumérer toutes les action possibles. Même si il ne se plie à aucune forme normée, il brille par son principal atout : être intelligible et sans fioritures.

Voici une portion de l'arbre de fonctionnalités qui porte sur la gestion des paramètres de l'application :

Automates à états

Les automates à états ont été réalisés au début du projet. Ils nous ont principalement servit à mieux nous approprier le fonctionnement général de certaines parties de l'application. Tous les automates à états n'ont pas été réalisés par manque de temps. Ils ont néanmoins aidé à une conception plus rapide des diagrammes de séquences.

Voici l'image de l'automate à états associé à l'opération de login :

Diagramme de cas d'utilisation

Le diagramme de cas d'utilisation est l'un des premiers documents que nous avons décidés de réaliser. En effet, il permet d'avoir une vue d'ensemble sur ce que nous allons devoir réaliser dans la phase de codage. Ces diagrammes nous ont étés particulièrement utiles pour réaliser les diagrammes de séquences.

Le diagramme de cas d'utilisation complet est disponible ici.

Diagrammes de séquence

Les diagrammes de séquence ont étés répartis sur l'ensemble des personnes travaillant sur le projet. Ils nous a fallu beaucoup de temps pour les réaliser. Un diagramme n'est pas long à créer mais il faut réfléchir à tout les cas possibles. L'autre facteur qui a fait qu'on y a passé beaucoup de temps est le nombre de diagrammes. Même à 4, 18 diagramme de séquence, c'est plutôt long à réaliser. Cependant, ces diagrammes nous sont et nous seront surement encore nécessaires par la suite donc, le temps accordé à cette tâche sera bénéfique pour la phase de codage.

Voici un exemple tiré de la liasse des diagrammes de séquence, il s'agit de l'opération d'envoi ou de sauvegarde (en fonction de la présence d'une connexion au serveur).

IHM

Le dessin de l'IHM à été réalisé d'après l'arbre de fonctionnalitées. Les logiciels de dessin Gimp et Inkscape ont étés utilisés pour dessiner l'IHM. L'IHM est simple et composée de boutons suffisament gros pour être lisible facilement sur un petit écran. Elle est également intuitive pour être facilement prise en main.

Diagramme de classes

Le diagramme de classe à prit beaucoup de temps à être fait car on ne pouvait pas commencer par ça. En effet, au début nous n'avions pas les idées assez clair sur ce que devait être ou ne pas être l'application. Il a donc fallu réaliser plusieurs autres documents intermédiaires notamment pour savoir comment on allait présenter l'application (son interface graphique), comment l'application allait sauvegarder les données... etc. Une fois tout cela définit, on a pu commencer le diagramme petit à petit. Nous avons eu l'occasion d'avoir de nombreuses (et longues !) discussions par Skype pour régler des petits détails (mais importants tout de même).

La classe MailType hérite d'une classe de l'API fournie afin d'ajouter la gestion des types de mails. L'héritage nous permet de donner un type au mails parmi mails reçus, envoyés et brouillons. En outre, la classe MailType, qui implémentera l'interface Serializable, nous permet de sauvegarder l'objet MailType sans avoir recours à une serialization manuelle.

Présentation de l'application pour le client

Pour présenter l'application à un éventuel client nous sommes partit du fait que le client ne connaissait que très peu de choses techniques. Nous avons donc réalisé un diaporama qui expose de manière très imagée les principales fonctionnalités et les atouts majeurs de notre application.

L'image ci dessous représente le fonctionnement hors connexion de notre application. Une explication orale reste nécessaire pour comprendre la symbolisation.

Suggestion de présentation orale associée à l'image ci-dessus :

Comme on peut le constater le serveur est inaccessible. Mais cela ne signifie pas pour autant que vous ne pouvez pas utiliser l'application. En effet, la gestion des messages et des brouillons est toujours disponible. Un des changements majeurs est la sauvegarde en local des mails. Ces mails enregistrés seront envoyés au serveur dès que la connexion pourra être rétablie.

Présentation des outils utilisés

Pour pourvoir mener à bien l'étape des spécifications nous avons utilisé plusieurs outils

• Skype nous a permis d'être en contact fréquent et de pouvoir débattre ainsi que de s'organiser rapidement et efficacement.
• Dia nous a permis de réaliser tous les diagrammes. Il était convenu d'utiliser bouml mais nous avons eu des péripéties insurmontables.
• Git & GitHub nous on permis de centraliser toutes les données et d'établir une liste des choses à faire. Je ne vais pas m'attarder sur l'utilisation et les avantages de Git ni de GitHub. Cependant je voudrais vous exposer la "TODO List" que nous avons utilisé, elle est disponible ici.

L'utilisation du bug tracker intégré à GitHub nous a donc servi de système d'assignation de tâches. En effet il est suffisament flexible pour un usage en réalisations de tâches multiples :

Il est également efficace car joindre une personne n'est pas utile pour savoir ce qui reste à faire :

Auteurs

Nous étions 4 à travailler ensemble sur les spécifications de l'application

• Titouan De Kerautem (TitouanDeKerautem)
• Guillaume Claudic (zipang29)
• Thibault Guittet (alan-mushi)
• Eflamm Olivier (Capitaineflamm)

Rédaction de la page et des articles

Guillaume Claudic :

Diagramme de cas d'utilisation

Diagrammes de séquences

Diagramme de classes

Thibault Guittet :

Présentation du travail réalisé

Élaboration du cahier des charges

Arbre de fonctionnalités

Automates à états

Présentation de l'application pour le client

Outils utilisés

Mise en forme (contrainte des droits d'administration)

Titouan De Kerautem :

IHM