Commit 0d9dafde authored by Gerson Sunyé's avatar Gerson Sunyé

Initial commit

parent f3791bbf
= Project 2019: Risk
== Objectifs
L’objectif de ce projet est de concevoir et de mettre en oeuvre un logiciel réparti permettant de jouer à des parties de Risk.
Cette application pourra être utilisée par entre 2 et 6 joueurs par partie.
Pour développer cette application, vous devez réaliser l'analyse du domaine (Chapitre 1), en vous basant sur différentes sources d'information:
* https://fr.wikipedia.org/wiki/Risk#Vue_générale_et_règles_principales[Les règles du jeu (Wikipedia)].
* https://sourceforge.net/projects/domination/[Les sources du jeu Open Source Domination].
* Le règles du jeu officiel ou toute autre source d'information dont vous disposez.
Ensuite, vous devez lire attentivement la spécification des exigences (Chapitre 2), qui vous aideront à concevoir la solution.
Vous commencerez par la spécification des besoins (Chapitre 3), pour réaliser ensuite la conception préliminaire (Chapitre 4).
== Prérequis
Pour réaliser ce projet, vous devez maîtriser les langages et outils suivants:
. UML, le langage de modélisation unifié.
. OCL, le langage d'expression de contraintes de UML.
. Les langages Java et TypeScript.
. Les outils de test unitaire JUnit et Jasmine
. Apache Maven, l'outil pour la gestion et l'automatisation de production des projets logiciels Java et npm, le gestionnaire de paquets officiel de Node.js.
== Organisation
. La réalisation du projet sera faite par des groupes d'au plus 4 étudiants.
. Pour réaliser le projet, chaque groupe doit créer une divergence (Fork) de ce dépôt. Le projet final doit être rendu **uniquement** par une demande de fusion (Merge request).
. Les rapports doivent être rédigés en https://asciidoctor.org[Asciidoc], suivant les squelettes de document proposés.
== Livrables
Le projet se compose de plusieurs livrables, qui doivent être finis à des échéances différentes.
A part pour l'échéance finale, toutes les autres échéances sont indicatives.
Vous n'êtes pas obligés de procéder de façon séquentielle, vous pouvez améliorer les livrables en même temps.
Livrables à fournir:
. Chapitre 1, l'analyse du domaine (15 octobre 2019)
. Chapitre 3, la conception préliminaire (25 octobre 2019)
. Chapitre 4, la conception détaillée (15 novembre 2019)
. Le code source et les tests unitaires de l'application: (20 décembre 2019)
== Critères d'évaluation
Les critères qui seront utilisés pour évaluer le travail rendu son les suivants:
* Le respect des exigences logicielles.
* La qualité du dossier de conception rendu.
* La précision, la correction et la clarté de la conception: diagrammes, descriptions textuelles, etc..
* La qualité et la pertinence des tests.
* La cohérence entre la conception et le code.
* La qualité du code.
== Préparation
Le projet utilise deux technologies qui ne sont pas vues en cours: Spring et Angular.
Pour vous préparer, suivez les tutoriels suivants:
* https://angular.io/tutorial/[Tutoriel Angular]
* Tutoriels Spring:
** https://spring.io/guides/gs/accessing-data-jpa/[Accessing Data with JPA]
** https://spring.io/guides/gs/accessing-data-mysql/[Accessing data with MySQL]
** https://spring.io/guides/gs/messaging-stomp-websocket/[Using WebSocket to build an interactive web application]
== Compilation du rapport
Vous pouvez utiliser Maven pour compiler le rapport de développement.
Pour cela, utilisez la commande suivante:
[source,shell]
----
mvn process-resources
----
La version PDF du rapport sera disponible dans le dossier `./target/doc/`
\ No newline at end of file
# Project Risk
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>fr.alma</groupId>
<artifactId>risk</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>risk</name>
<url>http://maven.apache.org</url>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-pdf</artifactId>
<version>1.5.0-beta.5</version>
</dependency>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-diagram</artifactId>
<version>1.5.18</version>
</dependency>
</dependencies>
<configuration>
<sourceDirectory>src/doc</sourceDirectory>
<outputDirectory>target/doc</outputDirectory>
<backend>pdf</backend>
<requires>
<require>asciidoctor-diagram</require>
</requires>
</configuration>
<executions>
<execution>
<id>generate-pdf</id>
<phase>generate-resources</phase>
<goals>
<goal>process-asciidoc</goal>
</goals>
<configuration>
<backend>pdf</backend>
<doctype>book</doctype>
<sourceHighlighter>coderay</sourceHighlighter>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
</plugin>
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<version>2.0.0-RC.1</version>
</plugin>
</plugins>
</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj</artifactId>
<version>2.1.0</version>
</dependency>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-pdf</artifactId>
<version>1.5.0-beta.5</version>
</dependency>
</dependencies>
</project>
= Analyse du domaine
== Introduction
=== Objectif
// Décrire l'objectif de ce chapitre.
Ce chapitre constitue le premier livrable d’une série de quatre chapitres destinés à fournir une analyse et une conception par objets complètes répondant au cahier des charges qui nous a été fourni.
Ce document présente l’ensemble de la démarche suivie ainsi que les résultats obtenus lors de la phase de l'analyse du domaine de notre système.
Il se décompose en plusieurs parties.
Dans la première partie, nous présentons de manière détaillée l’ensemble des cas d’utilisation que nous avons dégagés lors de l’analyse.
Nous utiliserons pour cela le canevas proposé par Cockburn que nous compléterons par des instantanés ainsi que par des post-conditions exprimées en OCL (Object Constraint Language) et quelques scenarii.
Cette partie constitue une étape clé de la phase de l'analyse du domaine.
Dans la deuxième partie, nous présentons le diagramme de classes métiers (i.e. diagramme de classes au niveau analyse) que nous avons construit à partir de l’analyse réalisée.
Ce diagramme fournit une vue statique et synthétique du domaine de notre projet.
Cette partie constitue également une étape clé de la phase de spécification des besoins.
Dans la troisième er dernière nous fournissons le dictionnaire des données que nous avons construit suite à l'analyse du domaine.
Il s’agit d’un listing de l’ensemble des termes relatifs au domaine étudié ainsi que leur définition précise.
Dans une quatrième et dernière partie,
=== Organisation du chapitre
Ce chapitre est organisé en $n$ sections. Dans le première section, nous décrirons....
== Cas d'utilisation
=== Mise en place d'un jeu
include::use-case-template.adoc[leveloffset=+2]
== Modèle de classes du domaine
[plantuml, domain-classes, png]
----
@startuml
Class01 <|-- Class02
Class03 *-- Class04
Class05 o-- Class06
Class07 .. Class08
Class09 -- Class10
@enduml
----
=== Invariants
[source,ocl]
----
context Etudiant::age() : Integer
post correct: result = (today - naissance).years()
context Typename::operationName(param1: type1, ...): Type
post: result = ...
context Typename::operationName(param1: type1, ...): Type
post resultOk: result = ...
----
== Dictionnaire de données
include::terms.adoc[]
== Conclusion
= Conception détaillée
== Le composant WebServer
== Le composant WebClient
\ No newline at end of file
= Spécification des composants
Ce livrable correspond à la "conception préliminaire" du projet. Il comprend la division de la solution en différents composants, l'explication des fonctionnalités attendues de chaque composant, la spécification des interfaces fournies par chaque composant, ainsi que des diagramme de séquence qui valident ces interfaces.
== Objectif
Préciser les objectifs de ce chapitre.
== Organisation du chapitre
Cette section décrit le contenu du reste du chapitre et explique comment le document est organisé.
== Description des composants
Établir les frontières du système.
Division du système en composants.
Décrire le comportement souhaité des composants.
== Le composant `Game Server`
Décrire succinctement le comportement du composant.
=== Spécification des interfaces
==== Spécification de l'interface A
Présentation de l'interface en UML (ou HUTN).
Description du comportement de chaque opération.
Spécification éventuelle des pré-conditions en OCL.
==== Spécification de l'interface B
== Le composant `Web Client`
Décrire succinctement le comportement du composant.
=== Spécification des interfaces
==== Spécification de l'interface A
Présentation de l'interface en UML (ou HUTN).
Description du comportement de chaque opération.
Spécification éventuelle des pré-conditions en OCL.
==== Spécification de l'interface B
== Interactions
Objectif: décrire, à haut-niveau, la collaboration entre les composants majeurs, en faisant référence aux besoins.
Utiliser des interactions, c'est à dire, des diagrammes de séquence et des diagrammes de communication.
** Ne vous limitez pas à une seule interaction par cas d'utilisation
=== Mise en place d'un jeu
==== Interaction: cas nominal
==== Interaction: cas A
==== Interaction: cas B
=== Tour d'un joueur
==== Interaction: cas nominal
==== Interaction: cas A
==== Interaction: cas B
This diff is collapsed.
[.small]
[width="100%",cols="34%,33%,33%",]
|===
|*Term*
|*Short Description*
|*Meaning*
| [[port, Port]] Port
| a
| ax
| [[publication,Publication]] Publication
| Activity
| Registers a Service with a DNS Responder.
| Registration
|
| See <<publication>>
| Package
|
| Minimum size = 9,000 bytes
| ((One-Shot Multicast DNS Queries))
| bla
| bla
| ((Continuous Multicast DNS Querying))
| bla
| bla
| [[service-instance-name, Service Instance Name]] Service Instance Name
| a
| a
| [[service-type, Service Type]] Service Type
| bla
| bla
|===
\ No newline at end of file
== Use Case Template
Version 1.20
*Instructions for removing the ‘Hints, Guidelines and Examples’ from
this document*
After you have completed the Use Case document, you may want to remove
the hints and guidelines provided in the document.
To remove the hints: (This procedure applies to Microsoft Word XP and
higher)
[arabic]
. Click on any text formatted as Hint.
. Then, click the right mouse button.
. A pop-up menu will appear, choose ‘Select text with similar
formatting’
. All Hint text will now be selected in the document.
. *Ensure that none of the text that you have entered is in the
selection.*
. Press the _Delete_ key to remove the _Hints , Guidelines and
examples._.
=== Revision History +
[cols=",,",options="header",]
|===
|Date |Author |Description of change
| | |
| | |
| | |
| | |
| | |
| | |
| | |
|===
Use Case Template. Copyright (c) 2004-2005 TechnoSolutions Corporation
(Learn more about “TopTeam for Use Cases” at
http://www.technosolutions.com[[.underline]#www.technosolutions.com#])
Permission is hereby granted, free of charge, to any person obtaining a
copy of this document and its associated documentation, to use the
document on their projects for any commercial or non-commercial purpose.
However you may not publish, distribute, sublicense, and/or sell copies
of this document.
THE DOCUMENT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
DOCUMENT OR THE USE OR OTHER DEALINGS IN THE DOCUMENT. TECHNOSOLUTIONS
CORPORATION MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS
DOCUMENT FOR ANY PURPOSE. +
*Use Case:* <Enter Use Case name here>
<Enter a short name for the Use Case using an active verb phrase.
e.g. Withdraw Cash, Register Customer, Rent Video, Calculate Sales Tax,
etc.>
*Id*: UC- <Enter value of Id here>
<Enter a unique numeric identifier for the Use Case. e.g. UC-113>
*Description*
<Enter description here>
<Briefly describe this use case.
e.g. Customer brings selected video(s) to the sales counter for the
purpose of renting them. Store clerk processes the rental payment,
records the rented video(s) against customer’s account, and hands over
the video(s) to the customer.>
*Level:* <Enter Use Case Goal Level here>
<Enter the goal level of this Use Case. Specify whether the Use Case
level is - High Level Summary, Summary, User Goal, Sub-Function, Low
Level>
*Primary Actor*
<List the Primary actor here>
<List the Actor who’s goal is being satisfied by this Use Case and has
the primary interest in the outcome of this Use Case.
e.g. Store Clerk>
*Supporting Actors*
<List supporting actors here>
<List the Actors who have a supporting role in helping the Primary Actor
achieve his or her goal.
e.g. Customer, Store Manager>
*Stakeholders and Interests*
<List Stakeholders and their interests here>
<List the various entities who may not directly interact with the system
but they may have an interest in the outcome of the use case.
Identifying stakeholders and interests often helps in discovering hidden
requirements which are not readily apparent or mentioned directly by the
users during discussions. +
e.g. In a Use Case ‘Generate Salary Stub’, the entity Internal Revenue
Service(IRS) has no direct interaction, however, it sure has interest in
ensuring that the proper tax deduction has been made from the employee’s
salary. This can be written as follows: +
+
Internal Revenue Service – Has interest in ensuring that the tax
deduction is made from each employee’s salary as per the tax table.>
*Pre-Conditions*
<List Pre-Conditions here>
< List the system state/conditions which must be true before this Use
Case can be executed.
e.g. Store Clerk must be logged in to system.>
*Post Conditions*
[.underline]#Success end condition#
<List success end condition here>
<Enter the successful end condition of the Use Case where the Primary
Actor’s goal is satisfied.
e.g. Video is rented to the customer and customer is charged for the
rental. Rental store’s inventory is updated to reflect the rented
video.>
[.underline]#Failure end condition#:
<List failure end condition here>
< Enter the failure end condition of the Use Case if the Primary Actor’s
goal has not been achieved.
e.g. Customer is unable to rent the video. Rental Store’s video
inventory remains unchanged.>
[.underline]#Minimal Guarantee#
<List minimal guarantee here>
< The guarantee or assurance that this Use Case provides to all Actors
and Stakeholders to protect their interest regardless of whether the Use
Case ends with success or failure.
e.g. For Withdraw Cash (ATM Use Case), minimal guarantee could be,
Customer is logged out of the ATM system. +
This minimum guarantee ensures that the system will ensure that no
unauthorized withdrawals can be made from the ATM thus protecting the
interest of the Bank Customer as well as the Bank’s stakeholders. >
*Trigger*
<List Use Case trigger here>
<The event that starts this Use Case.
Example
For _Rent Video_ Use Case - Customer brings the Video to the sales
counter.
For _Withdraw Cash_ Use Case - Customer inserts the bank card into the
ATM machine.>
=== Main Success Scenario
[arabic]
. <Enter steps here>
. <Enter steps here>
. <Enter steps here>
<Enter the Main flow of events. i.e. The steps narrating/illustrating
the interaction between Actors and the System. Describe Actor’s
actions/stimuli and how the system responds to those stimuli. Describe
the ‘happy path/day’ scenario, meaning the straight and simple path
where everything goes ‘right’ and enables the primary actor to
accomplish his or her goal. Main flow/path should always end with a
success end condition.>
=== Extensions
<Enter Extensions and their steps here>
<Enter any extensions here. Extensions are branches from the main flow
to handle special conditions. They also known as Alternate flows or
Exception flows. For each extension reference the branching step number
of the Main flow and the condition which must be true in order for this
extension to be executed.
Example of an Extension in Rent Video Use Case:
4a. In step 4, if the customer has accumulated late returns fee greater
than ten dollars
{empty}1. System will prompt for payment of the dues
{empty}2. Customer pays the dues
{empty}3. Store clerk adds the amount to the total
{empty}4. Use Case resumes on step 4.
>
=== Variations
<Enter variations here>
<Enter any data entry or technology variations such as – different
methods of data input, screen/module invocation, etc.
e.g. +
3’. In step 3, instead of reading Video Id using a bar code scanner, the
store clerk may enter it directly using the keyboard.>
*Frequency:* <Enter Frequency of execution here>
< How often will this Use Case be executed. This information is
primarily useful for designers.
e.g. enter values such as 50 per hour, 200 per day, once a week, once a
year, etc.>
*Assumptions*
<Enter any assumptions, if any, that have been made while writing this
Use Case.
e.g. For _Withdraw Cash_ Use Case(ATM system) an assumption could be: +
The Bank Customer understands either English or Spanish language.>
=== Special Requirements
<Enter any special requirements such as Performance requirements,
Security requirements, User interface requirements, etc. Examples:
Performance
{empty}1. The ATM shall dispense cash within 15 seconds of user request.
User Interface
{empty}1. The ATM shall display all options and messages in English and
Spanish languages.
{empty}2. The height of letters displayed on the display console shall
not be smaller than 0.5 inches. (Reference - Americans with Disabilities
Act, Document xxx, para xxx).
Security
{empty}1. The system shall display the letters of PIN numbers in a
masked format when they are entered by the customer. +
i.e. Mask the PIN with characters such as ****. Rationale – This is to
ensure that a bystander will not be able to read the PIN being entered
by the customer.
{empty}2. The ATM system will allow user to Cancel the transaction at
any point and eject the ATM card within 3 seconds. Rationale – In case
the customer in duress/in fear of own security he/she needs to quickly
get away.
{empty}3. The ATM system shall not print the customer’s account number
on the receipt of the transaction.
>
=== Issues
[arabic]
. {blank}
<List any issues related to the definition of the use case.
Example
1.What is the maximum size of the PIN that a use can have? >
=== To do
[arabic]
. {blank}
<List any work or follow-ups that remain to be done on this use case.
Example
{empty}1. Obtain the sales tax table for computation of tax on video
rentals from user.
{empty}2. Need to ensure that we have covered all parties under the
‘Stakeholders and Interests’ heading. >
To learn more about “TopTeam Analyst for Use Cases” visit
http://www.technosolutions.com[[.underline]#www.technosolutions.com#]
:includedir: _chapters
= Projet 2019 : Risk
== Auteurs
[options="header"]
|===
| Nom | Adresse
| Auteur_1 | auteur_1@etu.univ-nantes.fr
| Auteur_2 | auteur_2@etu.univ-nantes.fr
| Auteur_3 | auteur_3@etu.univ-nantes.fr
| Auteur_4 | auteur_4@etu.univ-nantes.fr
|===
== Introduction
Description du projet
== Organisation du document
// Chapters:
include::{includedir}/analyse-domaine.adoc[leveloffset=+1]
include::{includedir}/exigences.adoc[leveloffset=+1]
include::{includedir}/conception-preliminaire.adoc[leveloffset=+1]
include::{includedir}/conception-detaillee.adoc[leveloffset=+1]
== Conclusion
Points forts de votre projet
Limites (points faibles) de votre projet
public class RiskServer {
public static void main(String[] args) {
System.out.println("Risk Server");
}
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment