[MOTEUR] Rapport 2A

Voila ici nous regrouperons notre blabla pour le rapport 2A.

- Date limite : 14 février (au hasard pour avoir une deadline)

(au hasard pour avoir une deadline : c'est pour le 11 février )
Enfin, voilà la première pierre de blabla posée sur l'édifice du rapport : une petite idée de ce que pourrait être le plan :


I.Présentation
- Nous, les tuteurs, le client, le groupe
- Les exigences du client, les contraintes


II. Travail réalisé en première année
- La répartition des groupes
- L'étude de l'existant
- Le cahier des charges
- Les essais de MCD de base de données


III. Travail réalisé en deuxième année
- La base de données (avec un joli MCD et les explications)
- Touuut le code (avec un diagramme UML ?)
- L'évolution par rapport au cahier des charges de 1A
- Les fonctionnalités que l'on a implémenté
- Les problèmes qu'on a eu
- La répartition des tâches


IV. Et après ?

- Ce qu'il reste à faire
- Si c'était ce qu'on avait prévu
- Un autre groupe pourrait le reprendre ?


Je vais commencer un fichier word que je mettrai sur Dropbox un peu plus tard. Je mettrai le lien dès que ça sera fait.
(Parce que ce qui est bien alors les automatisations de Word, c'est que même si vous me dites "Oh non ça c'est de la merde faut pas le mettre", j'ai pas besoin de tout casser)
Je reprends le même genre que le rapport de l'année dernière pour la page de couverture

Voici donc le lien vers le fichier :
https://www.dropbox.com/s/8an0kl0cajoulpd/Rapport%202A.docx

J'ai fais quelques mises à jour mais on va trouver une autre méthode pour partager notre avancement que le forum car c'est un peu le bordel.

Bon autre question existentielle : On le fait avec word ou latek le rapport ?

Qui sait se servir de Latex dans le groupe ? x)

Pour les diagrammes UML, il faudrait qu'on utilise tous le même logiciel.
Donc, windesign, argoUML ou dia ?

https://2img.net/image.noelshack.com/fichiers/2013/06/1360431516-mcd.png

Hop

C'est pas terriblement beau, mais c'est le meilleur que nous ayons.

J'ai laissé de coté quelques tables d'importance mineure, sinon ça devenait vraiment surchargé.

Je te mets là ce que j'ai rajouté (et je vais corriger les fautes) :

Annexe :

Dans exemple de scripts, j'ai rajouté ça :

Exemples de script :

Lebouscript exemple = new Lebouscript(“hit $0 2d6”,creature);

hit : permet de faire des dégâts à une créature.
$0 : renvoie au premier argument (ici, creature).
2d6 : simule le lancer de deux dès à six faces.

Donc ici, la créature “creature” sera touchée avec les points définis par le lancer de deux dès à 6 faces.

Lebouscript exemple2 =
new Lebouscript(“if fort_save $1 12 ability_score_modifier $0 ability_score "CHA" hit $1 1d6
else hit $1 4d6 endif”,creature1,creature2);

if... else... endif : bloc de condition.
ability_score_modifier $0 ability_score “CHA” : récupère le modificateur de charisme du premier argument (ici, creature1).
fort_save $1 : fait effectuer un jet de sauvegarde au deuxième augment (ici, creature2).
12 : ajoute 12 à la valeur qui suit (ici, le modificateur de charisme).
hit $1 1d6 : touche le deuxième argument (creature2) avec un nombre de dégâts défini par une simulation d’un lancer d’un dé à six faces.
hit $1 4d6 : touche le deuxième argument (creature2) avec un nombre de dégâts défini par une simulation d’un lancer de quatre dés à six faces.

Ici, le script récupère le modificateur de Charisme de la première créature, y ajoute 12, et fait effectuer un jet de sauvegarde ayant ce degré de difficulté à la deuxième créature.
Si elle réussit, elle subit des dégâts calculés par une simulation d’un lancer d’un dé à six faces. Sinon, la simulation est faite avec quatre dès à six faces.


Glossaire :

Données de base :

Points de vie : lorsqu’ils arrivent à zéro, la créature ne peut plus faire d’actions.

Classe d’armure : difficulté que les adversaires ont à toucher le personnage.

Bonus de base à l’attaque : habileté au combat qui augmente selon le niveau de la créature.

Initiative : permet de définir l’ordre de passage de la créature lors d’un combat.


Fabrique : patron de conception qui permet d’instancier un objet dont le type est dérivé d’une classe abstraite. La classe abstraite n’est alors pas connue par la classe utilisant le patron.

Jet de sauvegarde : Permet à la créature visée d’éviter tout ou une partie des dégâts, selon la réussite du jet.

Partie 3.5 : utilitaires

Nous avons également utilisé des patterns de programmation pour simplifier certaines tâches. Par exemple, la création des bonus et des malus a été faite sous le patron fabrique, car les objets crées à partir de cette classe sont importants, et les modifications sur la classe abstraite utilisée pour faire le moule des bonus et des malus ne seront répercutés que sur la fabrique.

MAJ des liens précédents avec les ajouts de Lucie + le diagramme de gantt du groupe interface dans les annexes

Rapport, page 2 :
les nombreux tests de l’application qu’il a accomplis.

Rapport, page 4 :
médiéval-fantastique contrôlé par le maître du jeu.

Rapport, page 9 :
nombre important de personnes. Pour cela, nous avons décidé en première année de mettre en place un nombre important de moyens de communication.
=> Répétition, faudrait virer le nombre important pour les moyens de communication

Rapport, page 9 :
refaire la mise en page du bloc sur la communication

Rapport, page 14 :
refaire la mise en page du texte sur la base de données

Rapport, page 22 :
refaire la police du dernier paragraphe dans le 3.5

Annexe, page 1 & 2 :
juste mettre le titre et le diagramme de gantt sur la même page


Sinon, j'ai rien trouvé de plus

Voici la petite explication du diagramme de classe des objets
(Je t'envoye un mail avec les images)

Comme montré sur la figure 3, on peut voir que les classes Gear et Weapon héritent d’Item, ce qui signifie que Gear et Weapon possèdent les mêmes caractéristiques et éléments qu’Item, avec en plus certains ajouts.
La classe ItemAppearance permet de définir la forme de l’objet. Elle est donc liée à la table Item car un objet de cette classe possède un ItemAppearance.
Héritant d’Item, la classe Gear possède donc toutes ses caractéristiques et quelques supplémentaires. Elle possède un ArmorType, qui permet de définir l’endroit où se met l’équipement sur le corps de la créature. Elle possède également un GearMat, qui est le matériel utilisé pour créer l’objet.
La classe Weapon possède également les caractéristiques de la classe Item et un élément de GearMat. Elle possède un élément WeaponType qui permet de définir le type d’arme, c’est-à-dire arme contondante, perçante…

Ces symboles sont des entités.
Ils représentent des données contenues dans la base.



Ces symboles sont des associations.
Elles représentent comment les entités sont en relation les unes aux autres.



Ceci est un type d'association particulier : une contrainte d'intégrité fonctionnelle.
On l'utilise pour une relation dont l'une des entités est associée à une seule autre.



Ce symbole représente un héritage. Une entité hérite d'une autre si elle a tous ses
attributs et associations, mais elle peut en avoir plus.

J'vais poser surement une question con hein , mais dans l'schéma comment tu montre qu'une créature à une race ? Là j'crois lire qu'une classe a une race ...


EDIT : N'hésitez pas a dire que j'vous en ai trop demandé

IL FAUT CORRIGER UN MAXIMUM DES CONSEILS AVISES DE LA FICHE.
https://docs.google.com/document/d/1WaBe-U3Fo7Lg_fREiav2pXdEjJ_1YI9zQR_iQMQ-Www/edit?usp=sharing

Vous mettez vos corrections ici.

Dans la partie « Les besoins du client », vous faites allusion à une version de règles (3.5). Il serait bien d’avoir plus amples informations sur les différentes versions :
-) Combien existe-il de version de ce jeu ?
- Pourquoi la version 3.5 ?
- Avantages et inconvénients par rapport aux autres versions ?
- Possibilité d’évolution vers une autre version ?


Dans la partie « Travail d’analyse », vous parlez d’éléments à intégrer dans le jeu, mais de quel type d’élément s’agit-il ?


Dans le cahier des charges, vous catégorisez bien les systèmes. Au contraire, certaines puces méritent davantage d’explications, par exemple :
- « Système de simulation de lancer de dés (d3, d4, d6, d8, d10, d12, d20, d100). », que signifie la parenthèse ?
- « Les personnages pourront faire des coups ou des échecs critiques. », il existe réellement des échecs critiques ?


Il serait intéressant de développer sur le sujet des « versions additionnelles », pourquoi avez-vous fait ce choix ? Avantages, inconvénients ? Pourquoi développer plusieurs versions si elles ne sont pas toutes terminées ?


Vous introduisez votre projet en 2 groupes distincts (Moteur et Interface), mais à plusieurs endroits dans votre rapport vous utilisez le nom de « groupe règles ». Donc il y a 3 groupes ou 2 ?


Dans votre cahier des charges, vous utilisez un code couleur et un style italique contradictoire. En effet, vous mettez en rouge ce qui est fonctionnel, la couleur rouge n’est pas adaptée à un élément fonctionnel.


Les diagrammes 2 et 3 sont très peu lisibles à cause d’un manque de résolution.
Dans certaines parties et diagrammes, vous utilisez de l’anglais sans même traduire pour les personnes ne comprenant cette langue étrangère.


Dans votre projet, il existe 3 types d’objets : armure, arme ou objet, vous utilisez 2 fois le même mot « objet », l’un pour le type et l’autre pour le nom. Il y a confusion pour la suite de la lecture entre le type ou le nom.
Vous développez les types armure, arme mais pas objet, il serait recommandé d’apporter davantage de détail sur ce type.


Votre base de données est compliquée à comprendre, il manque une sorte de dictionnaire des données et d’exemples pour mieux comprendre.


Vous développez une partie sur « l’interface de programmation » mais à quoi sert réellement cette interface ?


Certains mots sont définis uniquement dans le glossaire (SVN, patterns…), il est embêtant de devoir tout le temps tourner les pages de votre rapport pour trouver la définition. Il manque la définition de « Quadriciel » et « Framework » dans le glossaire.


La partie sur le langage de script n’est pas évidente à comprendre (surtout avec l’annexe) pour un non-informaticien.


Pour finir, il serait bien de définir le but et le fonctionnement des tests unitaires :
- Comment les mettre en place ?
- Résultat des tests
- Correction des erreurs

Dans l’ensemble c’est un rapport agréable à lire pour une personne extérieure au projet, il est riche en contenu et en explication. Bonne hiérarchisation des différentes parties et évolutions du projet.

D'après Mathieu, il y a une faute d'orthographe à un moment :

Page 7, au début du cahier des charges

".... additionné à .... nous a permis" => mettre "nous ont permis"

Autre indication de Mathieu :

3.2 : utilisation de caduque, est-ce que c'est vraiment ce que nous voulions dire ?

si caduque a bien le même sens qu'obsolète ou faussé alors oui c'est ce que je voulais mettre.

Je peux traduire le MCD en français si nécessaire.

ça peut être sympa ça ferait un truc moins dur à comprendre je pense.

Après pour les diagrammes de classe, je préfère mettre la traduction des mots dans l'explication (comme je l'ai mis sur le Google doc )

J'ai envoyé un mail à Alban avec les figures 2 et 3 améliorées pour qu'elles soient plus lisibles

Voilà le MCD en français :

https://2img.net/image.noelshack.com/fichiers/2013/08/1361378520-mcd.png