diff --git a/src/doc/_chapters/analyse-domaine.adoc b/src/doc/_chapters/analyse-domaine.adoc index 7768477ececc202478a1ae356ed0f1f69b603ab7..f290fed2702155d09981978d4772385bb37a4935 100644 --- a/src/doc/_chapters/analyse-domaine.adoc +++ b/src/doc/_chapters/analyse-domaine.adoc @@ -1,77 +1,139 @@ = Analyse du domaine - + == Introduction +Le jeu de Risk est un jeu de conquête de territoire qui se déroule sur une carte de 42 territoires. Le but étant de réussir sa mission ou de conquérir tout les territoires tout en défendant ceux déjà acquis. +A chaque fois qu'un joueur se retrouve sans territoire, il est éliminé de la partie. + === 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. +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. +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. +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. +Dans la troisième et 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 -Dans une quatrième et dernière partie, +Ce chapitre est organisé en $n$ sections. Dans la première section, nous décrirons l'analyse du domaine de notre jeu de Risk. Nous nous baserons sur les règles officielles du jeu de Risk, avec cependant quelques modifications +que nous vous présenterons en début de section. -=== Organisation du chapitre +D'un point de vue fonctionnel, le jeu de Risk a deux cas d'utilisations, la mise en place d'un jeu et le déroulement d'un tour. +Nous allons détailler ces deux cas par la suite. -Ce chapitre est organisé en $n$ sections. Dans le première section, nous décrirons.... +== Cas d'utilisation +Comme cité plus haut, nous nous sommes basés sur les règles officielles (source: http://jeuxstrategie.free.fr/Risk_complet.php) mais avec quelques modifications. +Nous les détaillerons au fur et à mesure des cas d'utilisations mais ces changements concernent principalement l'attaque entre deux territoires. +Le jeu peut se jouer de 2 à 6 joueurs, la seule chose qui changera en fonction de l'augmentation du nombre de joueurs sera le nombre d'armées attribuées à chacun en début de partie. +Le jeu comporte 3 types de pions "armées", de valeurs respective 1,5 et 10. +Il comprends également 58 cartes, dont 14 cartes objectifs, et 42 cartes territoires, de type (canon, France). + +include::init-game.adoc[leveloffset=+2] + +''' == Cas d'utilisation -=== Mise en place d'un jeu +include::deroulement-tour.adoc[leveloffset=+2] -include::use-case-template.adoc[leveloffset=+2] +== Modèle de classes du domaine +La description des cas d'utilisation nous a permis d'identifier plusieurs classes conceptuelles, que nous décrivons ci-dessous. +Bien que présentées ici dans leur version finale, les classes sont passées par plusieurs itérations et ont été raffinées surtout grâce à l'analyse des post-conditions des cas d'utilisation. +Avant de présenter la totalité des classes, nous allons décrire certains points que nous avons jugés importants. -== Modèle de classes du domaine +=== Continent et territoire + +Nous avons séparés les territoires des continents, en effet un continent étant composé d'un nombre N de territoires, +les distingués sera utile pour décider si un Joueur possède l’entièreté d'un continent ou non. Un continent contient donc une collection de territoires; +Tandis qu’un territoire est composé d'un joueur, implanté sur ce dernier, ainsi qu'un nombre d'armées appartenant au dis Joueur. -[plantuml, domain-classes, png] +.Continents et Territoires +[plantuml, continent-territoires, png,align=center] ---- @startuml -Class01 <|-- Class02 -Class03 *-- Class04 -Class05 o-- Class06 -Class07 .. Class08 -Class09 -- Class10 -@enduml ----- +left to right direction + +class Continent { + tabTerre : Collection of Territoire +} -=== Invariants +class Territoire { + continent : Continent + joueurActu : Joueur + nbArmee : Integer +} -[source,ocl] +Continent "*" -- "1" Territoire +@enduml ---- -context Etudiant::age() : Integer -post correct: result = (today - naissance).years() -context Typename::operationName(param1: type1, ...): Type -post: result = ... +Lorsqu'un territoire est crée il est associé et intégré à un continent. Les seules actions possibles sont des actions +d'ajout d'armée, de retrait d'armée ou de changement de Joueur actuel. -context Typename::operationName(param1: type1, ...): Type -post resultOk: result = ... ----- +=== Cartes, Cartes Objectif, Cartes Territoires, Joueur et Tas +Pour cette section, nous avons choisis de séparé les différents type de cartes, il y aura tout d'abord une interface Carte, qui contiendra +un attribut description. Cet attribut prendra comme valeur un nom de territoire, mais peut également prendre la valeur du nom d'un des joueurs pour une carte objectif par exemple. +Chaque carte est tout d'abord insérée dans le tas qui leur correspond avant d'être distribuée. -== Dictionnaire de données - -include::terms.adoc[] +.Carte, Cartes Objectif, Cartes Territoires et Tas +[plantuml, carte-Cobjectif-Cterritoire-joueur-tas, png,align=center] +---- +@startuml +left to right direction + +interface Carte { + description : String +} + +class Cobjectif implements Carte { + +} + +class Cterritoire implements Carte { + arme : String +} + +class Joueur { + nom : String + nbArmee : Integer + cartesObj : Collection of Carte + cartesTerre : Collection of Carte + conquis : Collection of Territoire +} + +class Tas { + paquetObj : Collection of Carte + paquetTerre : Collection of Carte +} + +Tas "*" -- Carte +Joueur "*" -- Cobjectif +Joueur "*" -- Cterritoire +Joueur "*" -- "[0..1]" Territoire +Joueur "*" -- Continent +@enduml +---- +Chaque carte sera instancié en fonction des données dans une base de donnée qui sera interrogée par le serveur avec Spring, +Puis ajoutée au paquet correspond dans le Tas. +Un joueur pourra perdre ou gagner des territoires, de même pour les cartes territoires qu'il possède et pour les continents. == Conclusion - diff --git a/src/doc/_chapters/deroulement-tour.adoc b/src/doc/_chapters/deroulement-tour.adoc new file mode 100644 index 0000000000000000000000000000000000000000..3ab17a623592ac21d876eec4ef5a3499fff00789 --- /dev/null +++ b/src/doc/_chapters/deroulement-tour.adoc @@ -0,0 +1,106 @@ +== Déroulement d'un tour + +*Use Case 2:* Actions effectuées au cours d'un tour + +La partie a commencer, chaque Joueur va ainsi pouvoir faire une suite d'actions +et le système pourra réagir en fonction de ces derniers. + +*Description* + +Le système commence par donner au Joueur dont c'est le tour, un nombre d'armée égale à +la valeur entière du nombre d'armée qu'il possède divisé par 3. Ensuite s'il possède un ou plusieurs +continents entiers, il reçoit un certain nombre d'armées en fonction du continent: + +-Océanie: 2 armées supplémentaires, + +-Amérique du sud: 2 armées supplémentaires, + +-Afrique: 3 armées supplémentaires, + +-Europe: 5 armées supplémentaires, + +-Amérique du nord: 5 armées supplémentaires, + +-Asie: 7 armées supplémentaires. + +Ensuite, si le Joueur a plus de 3 cartes territoires dans sa main il peut, s'il le souhaite, échanger avec le système un nombre d'armées en +échange des types d'armes présentes sur ses cartes territoires: + +-Avec trois fantassins: 3 armées supplémentaires, + +-Avec trois cavaliers: 5 armées supplémentaires, + +-Avec trois canons: 8 armées supplémentaires, + +-Avec 1 canon, 1 cavalier, 1 fantassin: 10 armées supplémentaires. + +Si dans la combinaison, le Joueur possède l'un des territoires marqués sur l'une des trois cartes, il reçoit 2 armées supplémentaires par territoires possédés. +Pour finir, *si le Joueur possède 5 cartes territoires dans sa main*, il est obligé de faire l'échange cité précédemment. + +Une fois que les armées ont été attribuées, le Joueur peut les placer où il le souhaite sur ses territoires. +Le Joueur peut effectuer différentes actions qui seront listées par la suite, jusqu'à ce qu'il ait gagné, +ou qu'il ne puisse/souhaite plus attaquer ou se déplacer. + +*Acteurs principaux* + +Les acteurs principaux de ce use case sont : + + -le système qui va donner les cartes ou les armées. + + -les Joueurs (de 2 à 6), qui vont s'attaquer, ou déplacer leurs armées. + +*Pre-Conditions* + +La partie n'est pas finie. +Le Joueur est encore dans la partie, c'est à dire qu'il lui reste des armées. +Avant de pouvoir effectuer une action, le Joueur doit recevoir ses nouvelles armées. +Avant de pouvoir attaquer, le Joueur doit avoir 2 armées ou plus sur le territoire attaquant. +Le Joueur ne peut attaquer un territoire que si le territoire avec lequel il souhaite attaquer est adjacent. +Si le Joueur a déjà effectué un déplacement, il ne peut pas en effectuer un autre. +Le Joueur ne peut pas effectuer un déplacement d'un territoire vers un autre uniquement si celui-ci lui appartient et s'il est adjacent, +De plus il faut qu'il lui reste au moins une armée sur le territoire de départ. + +*Post Conditions* + +Le Joueur ne peut plus effectuer d'actions. + +*Déclenchement* + +C'est au tour du Joueur. + +*Scénario Nominal* + +2.1 Le Joueur a reçu toutes les armées qui lui sont dues par le système. + +2.2 Le Joueur peut maintenant réaliser les étapes suivantes dans l'ordre voulu: + + a- Le Joueur peut effectuer un déplacement en respectant les règles énoncées ci-dessus. + + b- Le Joueur peut attaquer d'un territoire vers un autre territoire adjacent en respectant les règles ci-dessus. + S'il gagne le territoire (il a vaincu toutes les armées adverses), il déplace les armées engagées restantes lors de la bataille + Sur le territoire conquis et gagne une carte territoire. + Le Joueur peut enchaîner les attaques sans ordre précis incluant les territoires conquis. + +2.3 Si le Joueur vient d'éliminer un adversaire en détruisant la dernière armée dans le dernier territoire de cet adversaire, + Il récupère alors les cartes de ce dernier et peut les échanger contre des armées avec le système pour les placer où il le souhaite. + +*Extensions* + +2.2.b : + +Pour cette extension nous allons distingués le Joueur attaquant de celui qui défend. +Le Joueur attaquant peut engager entre [1,3] armées, il lancera donc un nombre de dés égales aux armées engagées dans la bataille. +Le défenseur quant à lui, ne peux engager au maximum que un nombre de dés compris entre [1,2], et ce, même si il a plus de 2 armées sur son terrain. +On vas alors comparer les deux dés les plus fort de chacun des Joueurs un à un jusqu'à ce qu'un des Joueurs ne puisse plus engager de dés, +Auquel cas l'attaque de l'assaillant s'arrête. +Ce qui nous donne trois cas de figures possibles: + +-L'assaillant a le dés le plus fort, le défenseur perd une armée. + +-Le défenseur a le dés le plus fort, l'assaillant perd une armée. + +-les deux dés sont égaux, l'assaillant perd une armée. + +*To do* + +Mettre en place le déroulement d'une partie. diff --git a/src/doc/_chapters/init-game.adoc b/src/doc/_chapters/init-game.adoc new file mode 100644 index 0000000000000000000000000000000000000000..8d50c067d9d351bad671cb7cb811166c090232e5 --- /dev/null +++ b/src/doc/_chapters/init-game.adoc @@ -0,0 +1,55 @@ +== Mise en place d'un jeu + +*Use Case 1:* Initialisation de la partie + +Le nombre de joueurs étant fixé, le système va attribuer les pions et les cartes en fonctions du nombre de ces derniers. + +*Description* + +Au tout début de la partie, le système va tout d'abord attribuer une couleur d'armée à chaque joueurs. +Il va ensuite attribuer une carte objectif à chaque joueurs puis va distribuer les armées: + +-2 joueurs: 40 armées chacun, + +-3 joueurs: 35 armées chacun, + +-4 joueurs: 30 armées chacun, + +-5 joueurs: 25 armées chacun, + +-6 joueurs: 20 armées chacun. + +Le système va alors distribuer *toutes* les 42 cartes objectifs aux joueurs, +qui vas ensuite pouvoir placer ses armées sur chacun des territoires qui lui ont été attribués (tout en gardant minimum 1 armée sur chaque territoire) + +*Acteurs principaux* + +Les acteurs principaux de ce use case sont : + + -le système qui va organiser l'ensemble de la partie. + + -les joueurs (de 2 à 6), qui vont s'affronter. + +*Pre-Conditions* + +Il doit y avoir un nombre de joueurs compris entre [2,6]. +Aucune armée ne doit être présente sur le terrain, et aucun joueur ne doit avoir de cartes. + +*Post Conditions* + +Chaque joueur a le même nombre d'armée posée sur le plateau. +Tous les territoires appartenant aux joueurs doivent avoir au moins une armée. +Tous les territoires sont occupés par au moins une armée. + +*Déclenchement* + +Une nouvelle partie vient d'être lancée quand tous les joueurs sont prêts. + +*Hypothèses* + +Comment le système choisit le joueur qui commence en premier +Comment les territoires des joueurs avec leurs armées seront représentés ? + +*To do* + +Mettre en place le bon déroulement de ce cas d'utilisation. diff --git a/src/doc/_chapters/terms.adoc b/src/doc/_chapters/terms.adoc deleted file mode 100644 index f4532da14a1c25384530e9fa861a4265eff21f66..0000000000000000000000000000000000000000 --- a/src/doc/_chapters/terms.adoc +++ /dev/null @@ -1,40 +0,0 @@ -[.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 <> - -| 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 diff --git a/src/doc/_chapters/use-case-template.adoc b/src/doc/_chapters/use-case-template.adoc deleted file mode 100644 index d8f7700eaec29afa56e5a71cb300c0a932ac03d0..0000000000000000000000000000000000000000 --- a/src/doc/_chapters/use-case-template.adoc +++ /dev/null @@ -1,312 +0,0 @@ -== 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:* - - - -*Id*: UC- - - - -*Description* - - - - - -*Level:* - - - -*Primary Actor* - - - - - -*Supporting Actors* - - - - - -*Stakeholders and Interests* - - - -