[UML] Besoin d'avis sur mon analyse (pour un Space Invaders)

Bonjour,

Je travaille sur un remake du célèbre Space Invaders. Ce n'est pas très original, mais je préfère me lancer dans un projet (qui parait) simple pour consolider at approfondir mes connaissances.

Le jeu sera développé en C++ à l'aide de la SFML (1.5 dans un premier temps), et de Qt pour les éditeurs. De plus il intégrera des post-effects afin de rendre le jeu plus agréable visuellement.

Bien sûr, avant de coder, j'établis un Game Design Document auquel je me réfère pour fonder mon analyse UML.
J'ai débuté la dite analyse avec ce que j'ai actuellement rédigé du GDD. Mais n'étant pas encore un spécialiste, j'aurais besoin de quelques retours sur celle-ci (conseils, optimisations...).

Voici le lien vers le PDF du GDD (l'analyse débutant à la page 12) : http://www.pdfhost.net/index.php?Act...644b6715ba2824


Merci d'avance ;)



Edit : désolé, je n'avais pas vu la section UML. Si un modo peut déplacer mon post, merci :)

Bonsoir,

Un diagramme de paquetages montre les dépendances entre ceux-ci via des dépendances, et non des relations comme vous l'avez fait. De plus on ne donne pas la raison de ces dépendances. Les paquetages montrent le premier découpage gros grain, il faut de préférence ne pas avoir de dépendances circulaires, c'est à dire que si le paquetage A utilise le paquetage B la réciproque ne doit pas être vraie, y compris indirectement.

De la même façon le lien entre une classe et un paquetage qui ne contient pas celle-ci est une dépendance. Il s'agit bien-sûr d'un affinage des diagrammes de paquetages, mais il est généralement assez peu utilisé car ce niveau intermédiaire est à la fois trop et pas assez précis, mais rien ne vous empêche de l'utiliser si cela vous aide dans votre analyse.

Par contre un paquetage étant à la base un regroupement de classes il serait bon de montrer les classes (au moins les principales) au sein de leur paquetage

De manière générale vos relations sont nommées, ce qui est assez rarement fait, par contre les associations entre classes qui produiront les attributs de mémorisation dans les classes doivent être nommés. On ne sait donc pas si les relations entre classes sont des relations 'simples' ou des associations. De plus vos noms sont souvent une action correspondant d'une certaine façon à la raison de la relation en cause (activer, attaquer, détruire ..), mais les relations ne sont pas faites pour cela car les relations définissent le modèle statique et non le modèle dynamique.

J'ai l'impression qu'il manque un 'moteur' activant votre jeu (une/des classes contrôle), par contre le fait la classe Carte produise des débris et des ennemis me semble bizarre

[/QUOTE]Si un modo peut déplacer mon post, merci :)[/QUOTE]
c'est donc fait

Bonsoir et merci pour votre réponse :)

Je ne comprend pas ce que vous voulez me dire concernant les relations entre packages. J'ai (encore) récemment eu des cours d'UML, et mon prof nous a toujours fait placer une relation. Du moins c'est ce que j'ai noté dans mes corrigés d'exercices. Je ne vois pas ce que vous vous dire par dépendance et comment la représenter.
Par contre, j'ai en effet fait une erreur en ajoutant les raisons.

Les classes de chaque packages sont renseignées à la suite du PDF, dans le digramme de classe non documenté. Le titre (Configuration par exemple) correspond au package auquel elles appartiennent.

Pour les diagrammes de classe, quand vous parlez d'association vous faites référence à l'agrégation ou la composition ? Auquel cas je ne vous comprend pas très bien, je ne fais qu'appliquer ce que l'on m'a appris.
En fait, je n'arrive pas à voir mes erreurs sur ce diagramme :?

Sinon j'ai en effet oublié une (ou des) classe(s) de contrôle (GameEgine en quelque sorte) qui se chargera de faire le lien entre les différentes librairies et de créer les niveaux.
Ce n'est donc pas la Carte qui produira des Debris et Ennemis : elle ne fera que les contenir ;)


Merci pour votre aide et pour le déplacement du sujet.
Je tiens compte de vos remarques et attend avec impatience vos explications :)

Bonjour,

au fait j'avais oublié de vous signalez que si vous voulez faire une modélisation plus complète vous devez commencer par les cas d'utilisation (use case)

Citation:

---

Envoyé par Furanku

Je ne comprend pas ce que vous voulez me dire concernant les relations entre packages. ... Je ne vois pas ce que vous vous dire par dépendance et comment la représenter.

---

dépendance = dependency, cela se représente avec une un trait pointillé et une flèche ouverte : - - - - ->

entre les packages on utilise donc des dépendances, le stéréotype donnant la raison de la dépendance

Citation:

---

Les classes de chaque packages sont renseignées à la suite du PDF, dans le digramme de classe non documenté. Le titre (Configuration par exemple) correspond au package auquel elles appartiennent.

---

ok, je n'avais pas vu, il faut dire qu'il ne saute pas aux yeux que digramme de classe non documenté signifie contenu des packages ;)
Vous feriez mieux de 'vraiment' rester au niveau package en indiquant les classes principales placées dans chaque package sans plus d'infos (donc pas de relations etre classes comme c'est le cas actuellement. Vous pouvez indiquer en plus les relations entre packages, cela reste cependant redondant avec les précédents diagramme de packages

Citation:

---

Pour les diagrammes de classe, quand vous parlez d'association vous faites référence à l'agrégation ou la composition ?

---

oui, ou même des associations 'simples', les agrégations et compositions sont des associations spécialisées

Encore une fois un diagramme de classes est statique, si vous voulez montrez le coté dynamique utilisez les diagrammes dédiés

Jusqu'à quel niveau allez-vous aller, seulement analyse ou conception détaillée avec génération de code ?

Merci de ces éclaircissements ;)
C'est ce que je reproche en partie à UML : j'ai eu deux prof différents, un en BTS et un cette année (un vacataire, mais prof de BTS lui aussi). Et aucun des deux ne nous a appris à utiliser UML de la même manière... Chacun semble avoir une vision plus ou moins différente de la chose.

Je reste donc surpris de voir des dépendances dans un Diagramme de Package, quand on m'a appris à ne les utiliser que dans celui des Cas d'Utilisation.

Je vais donc retravailler mes diagrammes selon vos conseils, en n'oubliant pas le moteur de jeu cette fois-ci :D


Sinon je ne compte faire que la partie analyse de mon projet. J'aime coder, mais pas n'importe comment :roll:

sur DVP vous pouvez trouver de la doc sur UML, par exemple UML 2.0 : Cours complet, par Laurent Audibert

Oui j'ai déjà jeté un oeil dessus, et pas mal de points sont différents de mes cours. Je vais me baser sur cette version, et mettre mes cours de côté.

Merci.

J'ai modifié mon Diagramme de Package en tenant compte des conseils donnés ci-dessus.
Je n'ai par contre pas inclus les classes (même principales) afin de ne pas surcharger le diagramme.

Je suis prêt à recommencer si nécessaire, ce projet est là pour m'améliorer :ccool:

j'avoue que le packahe Partie me semble bizarre, de part son nom, et le fait que je joueur n'en fasse pas ... parti (désolé pour le jeu de mot :lol: )

mais comme je ne sais pas vraiment à quoi les différents packages correspondent vraiment il est difficile de juger

continuez donc votre analyse, vous verrez bien au fur de l'avancement si cela colle de toute manière, et re-publiez ici si vous voulez un nouvel état d'avancement

Je suis d'accord, je pense que je vais continuer plus en profondeur l'analyse écrite (GDD) avant de faire les différents diagrammes. J'ai peut-être voulu allé trop vite (l'erreur classique du débutant :lol: ).

Merci encore !
Je repasserai ici une fois que j'aurais plus avancé ;)

Déjà merci pour les Cours et tutoriels pour apprendre UML surtout celui la : Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert