Commit 3566759a authored by Gerson Sunyé's avatar Gerson Sunyé

Hearthstone, initial commit

parent 76818a42
/target/
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0"
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>org.atlanmod</groupId>
<artifactId>hearthstone</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>hearthstone</name>
<url>http://maven.apache.org</url>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<description>
</description>
<inceptionYear>2018</inceptionYear>
<organization>
<name>Atlanmod</name>
<url>http://atlanmod.org/</url>
</organization>
<developers>
<developer>
<name>Gerson Sunyé</name>
<email>sunye@atlanmod.org</email>
<organization>Université de Nantes</organization>
<organizationUrl>http://www.univ-nantes.fr</organizationUrl>
</developer>
</developers>
<build>
<plugins>
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<version>2.0.0-RC.1</version>
<dependencies>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-pdf</artifactId>
<version>1.5.0-beta.4</version>
</dependency>
<dependency>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctorj-diagram</artifactId>
<version>1.5.18</version>
</dependency>
</dependencies>
<configuration>
<sourceDirectory>src/doc/</sourceDirectory>
<requires>
<require>asciidoctor-diagram</require>
</requires>
<!-- Attributes common to all output formats -->
<attributes>
<sourcedir>${project.build.sourceDirectory}</sourcedir>
</attributes>
</configuration>
<executions>
<execution>
<id>generate-pdf-doc</id>
<phase>generate-resources</phase>
<goals>
<goal>process-asciidoc</goal>
</goals>
<configuration>
<backend>pdf</backend>
<sourceHighlighter>coderay</sourceHighlighter>
<attributes>
<icons>font</icons>
<pagenums/>
<toc/>
<idprefix/>
<idseparator>-</idseparator>
</attributes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
:xrefstyle: short
= Analyse du domaine
Gerson Sunyé <gerson.sunye@univ-nantes.fr>
== Introduction
Hearthstone est un jeu de cartes de combat, où deux adversaires s'affrontent tour à tour.
Le vainqueur sera celui qui amène à 0 ou moins le nombre de points de vie de son opposant.
D'un point de vue fonctionnel, Hearthstone a deux cas d'utilisation (ou fonctionnalités) principaux: la mise en place d'un jeu et jouer un tour.
La <<Main>> illustre les principaux cas d'utilisation du jeu.
[#Main]
.Cas d'utilisation principaux
[plantuml, main-use-cases,png,align=center]
----
@startuml
left to right direction
skinparam packageStyle rectangle
actor Joueur
actor Arbitre
rectangle Harthstone {
Joueur -- (Mise en place)
(Mise en place) -- Arbitre
Joueur -- (Jouer un tour)
(Jouer un tour) -- Arbitre
}
@enduml
----
Ces cas d'utilisation sont décrits dans la section suivante.
== Cas d'utilisation principaux
Dans cette section, nous utilisons les Cas d'utilisation efficaces d'Alistar Cockburn pour spécifier les cas d'utilisation principaux de Herthstone:
. Mise en place et
. Jouer un tour
=== Acteurs
Nous avons considéré deux acteurs, le joueur (et son adversaire, un autre joueur) et l'arbitre.
La notion d'arbitre n'est pas directement présente dans le jeu originel, mais ce rôle nos paraît important pour identifier certains comportements qui ne sont pas réalisés par les joueurs, mais qui sont nécessaires à la progression du jeu.
Joueur:: Le joueur est celui qui joue une partie. La partie comprend deux joueurs, qui sont des adversaires, l'un de l'autre.
Un seul des joueurs commence la partie, l'_initiateur_.
Arbitre:: L'arbitre veille au bon déroulement des parties. Il calcule les effets à appliquer en début et fin de tour.
include::uc-mise-place.adoc[leveloffset=+2]
include::uc-jouer-tour.adoc[leveloffset=+2]
== Classes
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.
=== Cartes et Serviteurs
Nous avons distingué les concepts de carte et de serviteurs.
Bien que physiquement une carte contienne un serviteur, conceptuellement plusieurs cartes se partagent le même serviteur.
Le lien entre serviteurs et cartes est le même que celui du pattern "Item and Descriptors": le serviteur décrit les valeurs initiales de vie et puissance d'une carte, mais ces valeurs sont indépendantes pour chaque carte.
.Cartes et Serviteurs
[plantuml, cartes-serviteurs, png,align=center]
----
@startuml
left to right direction
class Carte {
puissance : Integer
vie : Integer
}
class Serviteur {
puissance : Integer
vie : Integer
effet : Effet
nom : String
}
Carte "*" -- "1" Serviteur
@enduml
----
Contrairement aux serviteurs, les cartes peuvent être dans différents états.
Lorsqu'une carte est crée, elle est placée dans le tas.
Ensuite, lorsqu'un joueur la pioché, elle est placée dans sa main.
Si le joueur décide de la jouer, elle est placée sur le plateau et devient inactive (bien que certaines cartes puissent devenir actives directement).
Les cartes jouées deviennent actives à chaque début de tour.
Elles redeviennent inactives lorsqu'elles sont utilisées pour attaquer.
.Différents états d'une carte
[plantuml, sd-carte, png, align=center]
----
@startuml
[*] --> Entassée
Entassée -> Empoignée : piocher()
Empoignée -> Inactive : jouerCarte()
Inactive -> Active : Début de Tour
Active --> Inactive : attaquer()
Inactive --> [*]
Active --> [*]
@enduml
----
=== Joueurs et Héros
La relation entre Héros et Joueur est similaire à celle entre Serviteur et Carte:
le Héros décrit les caractéristiques d'un joueur.
Un joueur ne peut choisir qu'un seul Héros, tandis que plusieurs joueurs peuvent choisir le même Héros.
.Joueurs et Héros
[plantuml, joueurs-heros, png, align=center]
----
@startuml
left to right direction
class Joueur {
vie : Integer
mana : Integer
stockMana : Integer
}
class Heros {
vie : Integer
armure : Integer
nom : String
}
Joueur "*" ---- "1" Heros
@enduml
----
=== Joueurs et Cartes
Nous avons choisi de représenter les concepts de _main_, _plateau_ et _tas_ comme des associations entre Joueur et Carte.
Chaque joueur a son propre tas de cartes.
Il peut avoir des cartes dans sa main ou sur son plateau.
.Joueurs et Cartes
[plantuml, joueurs-cartes, png, align=center]
----
@startuml
left to right direction
class Joueur {
}
class Carte {
}
Joueur "[0..1]" ---- "[*] main" Carte
Joueur "[1]" ---- "[*] plateau" Carte
Joueur "[0..1]" ---- "[*] tas" Carte
@enduml
----
\ No newline at end of file
= Herathstone
== Introduction
== Domain analysis
Heroes: Wizard, Knight,
Cards: Sort, Serviteur
\ No newline at end of file
[.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
= Cas d'utilisation 2: Jouer un tour
== Description
Les joueurs jouent leurs tours alternativement, plusieurs fois dans une partie.
Le joueur commence son tour par piocher une carte et effectue différentes actions par la suite, jusqu'à la fin de son mana ou jusqu'à ce qu'il passe son tour.
Niveau:: Stratégique
Portée:: Système
Priorité:: Haute
Échéance:: 1e version
== Acteurs principaux
* Le joueur
* L'arbitre
== Acteurs de soutien
* Aucun
== Parties prenantes et intérêts
* Aucun
== Pré-conditions
* L'adversaire a fini son tour
* Le héros du joueur possède encore des points de vie
== Post-conditions
=== Condition finale de réussite
* Le joueur a pioché sa carte et a réalisé autant t'attaques que possible.
* Les attaques ont fait perdre des points à l'adversaire.
=== Condition finale d'échec
=== Garanties minimales
== Événement déclencheur
* Le début d'une partie.
* La fin du tour de l'adversaire.
== Scénario nominal
[arabic]
. Le jouer pioche une carte et la place dans sa main
. L'arbitre applique les effets de début de tour
. Le joueur réalise les étapes suivantes, *sans ordre déterminé*:
.. Le joueur pose une carte de la main sur le plateau
.. Le joueur _choisit une cible_ et utilise une carte du plateau pour _attaquer_.
.. Le joueur _choisit une cible_ et utilise une carte de la main pour _attaquer_.
.. Le joueur utilise le sort spécial de son héros pour attaquer.
. [[pass, 4]] Le joueur passe son tour
. L'arbitre applique les effets de fin de tour.
== Extensions
:xrefstyle: short
<<pass>> : il ne passe pas vraiment
== Variantes
== Fréquence
* Durant une partie, un joueur joue son tour environ 20 fois.
== Hypothèses
* Aucune
== Exigences particulières
== Questions ouvertes
. Aucune
== À faire
[ ] Demander aux étudiants de vérifier ce cas d'utilisation.
== Annexes
= Use Case 1: Mise en place
== Description
Deux joueurs se trouvent pour jouer à Hearthstone.
L'arbitre prépare et distribue les cartes aux deux joueurs.
L'arbitre désigne celui qui commence la partie.
Niveau:: Stratégique
Portée:: Système
Priorité:: Haute
Échéance:: 1e version
== Acteurs principaux
. Les deux joueurs
. L'arbitre
== Acteurs de soutien
* Aucun pour l'instant
== Parties prenantes et intérêts
* Aucun pour l'instant
== Pré-conditions
* L'arbitre et les deux joueurs peuvent communiquer entre eux.
* Le jeu de cartes est complet et disponible.
== Post-conditions
=== Condition finale de réussite
* Chaque joueur a un héros et des cartes dans sa main.
* Chaque joueur a un tas de cartes prêt.
=== Condition finale d'échec
* Les joueurs n'ont pas reçu leurs cartes.
=== Garanties minimales
* Aucune
== Événement déclencheur
Les deux joueurs se retrouvent et souhaitent s'affronter.
== Scénario nominal
[arabic]
. Les deux joueurs et l'arbitre se retrouvent
. Chaque joueur choisit son Héros.
. L'arbitre désigne le joueur qui commencera la partie.
. L'arbitre prépare le tas de cartes.
. L'arbitre distribue 4 cartes à chaque joueur.
. Chaque joueur choisit entre 0 ou 4 cartes à remplacer, parmi celles qu'il a reçu.
. L'arbitre remplace les cartes désignées par chaque joueur.
== Extensions
== Variantes
== Fréquence
* Une partie dure environ 20 minutes.
* Le nombre de parties jouées en même temps est inconu.
== Hypothèses
* Il existe un chemin de communication entre l'arbitre et le deux joueurs et entre les joueurs.
== Exigences particulières
* Aucun
== Questions ouvertes
. Comment l'arbitre choisit le joueur qui commence la partie?
== À faire
[ ] Demander aux étudiants de vérifier ce cas d'utilisation.
== Annexes
== 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