Projet bibliothèque - “Dedal”

Projet bibliothèque - “Dedal”

 Master 2 MIAGE - Systèmes d’information distribués

[pic 1]

Réalisé par :

Année scolaire : 2017-2018

Table des

 matières

1. Résumé        3

2. Introduction        4

3. Présentation du projet        5

4. Modélisation de la gestion de la bibliothèque        6

4.1 Diagramme de cas d’utilisations        6

4.2 Diagramme de classes        6

4.3 Diagrammes d’activité        10

4.3.1 Diagrammes concernant l’application en général        10

4.3.2 Diagramme concernant la partie “jeu” de l’application        11

4.4 Diagrammes de séquences        12

5. Mise en place de la solution fonctionnelle        13

5.1 Architecture logicielle        13

5.2 Technologies employées        15

5.3 Fonctionnement de l’application        16

5.3.1 Écran d'accueil        16

5.3.2 Écran des règles        17

5.3.3 Écran à propos        18

5.3.4 Écran de jeu        19

6. Conclusion        20

1. Résumé

L’architecture logicielle est cruciale pour la pérennité d’une application. En effet, les phases de conception, développement et maintenance doivent être régies par des méthodes qui permettent l’exploitation de cette application par des personnes externes au projet.

Le projet “Dedal” consiste à modéliser un jeu de dés à un joueur et à réaliser son implémentation en langage Java via les frameworks de notre choix en s’appuyant sur la démarche de conception UML réalisée durant les cours de patrons d’analyse et de conception.

2. Introduction

Le projet vise à automatiser un jeu de dés à un joueur. En effet, il est difficile de garder en mémoire ou sur un support papier son score le plus élevé et de calculer les scores intermédiaires sans faire d’erreurs.

L’automatisation permet :

• de s’abstenir d’utiliser des vrais dés
• d’éviter les cas de triches
• de stocker le meilleur score
• de calculer les scores intermédiaires

Le document sera structuré de manière analogue :

• présentation du projet
• modélisation du jeu de dés
• mise en place de la solution fonctionnelle

3. Présentation du projet

L’objectif de ce projet est de réaliser une application qui permet joueur à un jeu de dés à un joueur. Cette application devra lorsque c’est pertinent implémenter les design patterns étudiés en cours.

La modélisation s’est effectuée dans l’ordre par le biais de diagrammes UML suivants :

• diagramme de cas d’utilisations
• diagramme de classes
• diagrammes d’activité
• diagrammes de séquences
• diagrammes d’états-transition

Le but de cette conception est de la respecter le plus fidèlement possible lors de la phase d’implémentation. Cependant, il est impossible d’avoir réalisé une conception parfaite dès la première phase (omission de fonctionnalité, définition incomplète d’une fonctionnalité, etc.) c’est pourquoi, nous devons maintenir la conception à jour tout au long de notre développement.

Le système doit être utilisable sur les principaux systèmes d’exploitation à savoir Mac OS X, Windows & Linux. Il doit également offrir une bonne expérience utilisateur via une interface simple et épurée. Le cahier des charges nous impose l’utilisation de Java que nous avons décidé de couplera la librairie JAVA FX compte tenu des besoins.

4. Modélisation de la gestion de la bibliothèque

4.1 Diagramme de cas d’utilisations

[pic 2]

4.2 Diagramme de classes

Une image du rapport en entier est jointe à ce document. Le diagramme de classe étant conséquent nous l’avons disséqué.

Le patron Observable Observer est utilisé pour la relation entre le joueur et le dé (à titre pédagogique) :

• le Player (joueur) est un observer (observateur)
• le Dice (dé) est un observable (sujet)

[pic 3]

Cette image correspond donc a la partie modèle du patron MVC associée à celle ci-dessous.

La patron Fabrique est utilisé notamment pour l’accès aux données (comme abordé en cours), nous utilisons :

• une base de données postgresql
• des fichiers (JSON)
• une base clé / valeur avec redis

[pic 4]

Nous remarquons qu’un des contrôleur du jeu utilise l’accès au données.

Ci-dessous nous avons la partie contrôleur du patron MVC

[pic 5]

Remarques :

Les éléments suivant ne sont pas représentés :

• classes techniques (contrôleurs et stockage)
• packages
• les vues qui sont des fichiers, et non des classes

4.3 Diagrammes d’activité

4.3.1 Diagrammes concernant l’application en général

[pic 6][pic 7]

4.3.2 Diagramme concernant la partie “jeu” de l’application

[pic 8]

4.4 Diagrammes de séquences

Ce diagramme de séquence représente le fonctionnement de notre application du lancé de dés jusqu’à l’enregistrement du score du joueur.

...