Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
étapes qui précedene l'analyse uml
Bonjour ,
voila je suis sur le point de préparer un jeux de carte (qui sera implémenter en ava) .
avant de passer a préparer mes diagrammes (dont je n'est pas une idée claire sur celle que j'aurai besoin) je ne sais pas comment faire pour organiser mon petit travail afin qu'il soit prés pour le modéliser ?
merci d'avance
bonsoir
l'étape qui précéde l'analyse est l'expression des besoins ou la description des exigences avec le cas échéant estimation et planning initial.
Pour t'aider à trouver les diagrammes réalise un plan documentaire
salut,
voila c'est exactement ca. mais je doit exprimer et préciser quoi dans le jeux ?
exprimer les exigences du jeu et préciser les scénarios possibles et imaginables
je prépare les éléments (nombre de cartes,nbr de joueurs,valeurs des cartes)
et les mouvements des cartes?
il faut faire un diagramme de cas d'utilisation et un diagramme d'activité ou de séquence système par cas d'utilisation
salut,
pour l'expression des besoins , est ce que je doit imaginer le déroulement du jeux et le mettre sous forme de doc ?
si c'est le cas je me met a la place d'un joueur et j'imagine tous les actions que je vais effectuer avec le systeme
remarque : un seul joueur VS la machine
A ta place, je difinirais des UCs du type :
- Configurer une partie
- Dérouler une partie
- Jouer un coup
- Simuler un coup (c'est pour différencier cet UC du précédent, dans le sens où ici c'est la machine qui remplace l'homme - attention à ne pas faire de mauvaise interprétation)
- ...
A réfléchir un peu pour l'exhaustivité, la granularité, le nommage et comment les organiser dans un diagramme de UC. Pour t'aider dans cette tâche, regarde si, pour chaque UC que tu auras défini, tu arrives à définir un diagramme de séquence (à privilégier par rapport au diagramme d'activité lorsque le temps à plus d'importance que l'espace) entre le système et le joueur pour chaque UC.
Reste aussi à définir les acteurs (y-a-t'il des joueurs privilégiés dans un cadre multi-joueurs ? ...).
____________
salut,
je savais pas qu'on pouvait passer d'un use case a un diagramme de sequance!
il existe une méthode technique pour ca?
merci d'avance
Pour être plus précis c'est de la description textuelle des UC(un tableau avec quelques colonnes) que tu peux t'inspirer pour faire un diagramme de séquence système(donc boite noir)Envoyé par supzero
La technique de la boite noir ensuite pour chaque message échangé tu fais une boite blanche jusqu'à ce que tu puisses implémenter avec un langage de programmation.
Salut,
j'ai trouvé un document qui explique ce qu'est un diagramme de usecases et ce qu'il faut faire ou ne pas faire :
http://www.modeliosoft.com/en/tutori...al-guides.html.
J'espère que cela t'aidera.
Non, pas de méthode précise et "automatique" (algorithmique), à ma connaissance.
Les use cases permettent de ne pas oublier d'interaction "fondamentale".
Dans ton cas, l'expression des besoins passe par une énumération des règles du jeu. Tu en découlera, si elle sont bien exprimées, assez facilement un premier diagramme de classes, dit "métier" ou "d'analyse". Ce diagramme doit être valable autant pour le cas réél (car ne se base que sur l'expression des règle) que pour ton jeu "virtuel".
Une fois ce "coeur" dégrossi, tu pourra passer à la conception, c'est à dire la réalisation des diagrammes complémentaires qui te guideront dans l'implémentation.
Exemple simple pour un jeu simple : le solitaire.
1) le joueur à devant lui un tableau, composé de colonne de cartes (face visible ou non), de quatre tas "classés" et d'un talon, dont une partie peut être retourné.
2) le joueur peut déplacer n'importe quelle carte, du moment que sa position initiale est "sur le dessus", et que sa destination est :
- soit une colonne dont la dernière carte visible est de couleur inverse (noir ou rouge) et de valeur immédiatement supérieure
- soit un tas classé, de même couleur que la carte, dont la dernière carte est de valeur immédiatement inférieure
etc...
la règle 1) donne la structure fondamentale du coeur :
- class Tableau
- class Carte
- class Pile (ou Colonne)
- class Tas (ou TasTrie ou...)
- class Talon
et les relations, une realtion 0..* ordered entre Pile et Carte, relation de compsition entre Tableau et Tas, Tableau et Talon, Tableau et Pile
La règle 2) va donner plutôt des indications sur des méthodes :
Une méthode boolean doesAccept(in c : Carte); par exemple pour la Pile. On entrevois ici une possiblité de généricité (polymorphisme) entre Tas et Pile. Est-ce pertinent pour la suite de la modélisation ?
Doit-on, peut-être, externaliser ces comportement dans des classes externes, utilisées par Pile et Tas ? A voir...
De la même manière, décrire la règle concernant la manière dont on peut retourner les cartes donnera des indication sur des méthodes correspondantes, etc...
J'espère ne pas avoir répondu trop à côté de la plaque
Répondre avec citation
Partager