Analyse du domaine
Travail à réaliser
- Objectif
-
Description du jeu 7 Wonders sous la forme d’un diagramme de classes conceptuelles et d’actions.
- Moyens
-
Utilisez une approche itérative pour découvrir toutes les classes conceptuelles et les actions du jeu.
Modèle du domaine
|
Décrivez ici les classes conceptuelles du domaine, ainsi que leurs attributs et associations. |
Cas d’utilisation
|
Utilisez le canevas proposé par Alistar Cockburn pour décrire les cas d’utilisation. Additionnellement, utilisez des diagrammes d’activités UML pour illustrer les cas d’utilisation. |
Cas d’utilisation "Mise en place d’une partie"
| Item | Description |
|---|---|
# |
1 |
Cas d’utilisation |
Préparation |
Alias |
Initialisation, Mise en place |
Objectif contextuel |
Installer le plateau, avec les cartes, les plateaux et les pièces pour commencer la partie |
Portée |
Le jeu |
Niveau |
Utilisateur |
Condition de succès |
Le plateau est correctement préparé |
Condition d’échec |
Le plateau est mal préparé (mauvaise distribution des cartes/des pieces etc..) |
Acteurs principaux : |
Les joueurs |
Acteurs secondaires |
--- |
Événement déclencheur |
Début de la partie |
Priorité |
1 |
Fréquence |
Une fois par partie |
Pré-conditions |
|
Post-conditions |
|
Scénario nominal |
|
Extensions |
Préparation pour 2 joueurs |
Alternatives |
--- |
Cas d’utilisation supérieur |
--- |
Cas d’utilisation subordonnés |
--- |
Objectif de performance |
--- |
Problèmes ouverts |
|
Échéancier |
--- |
Contraintes |
--- |
Annexes |
Cas d’utilisation B
Document Information
Document Title |
Title of use case – Verb Noun phrasing is almost always the most appropriate! |
Document Owner |
|
Version |
|
Status |
|
Date |
Brief Description
Insert a 1-2 sentence description of this use case. Be sure to include a starts when / ends when statement to clarify the beginning and ending points of the scope of this process or piece of functionality.
Actors
List any roles or systems involved with this process or use case. A person or system fulfilling a role will be the actor in one of the steps.
Pre-Conditions
List anything that must be true before this process or functionality begins. Preconditions should be states that a system can validate to be true. A common example is that a specific Actor has logged into the System.
Basic Flow
The basic flow is the normal course of events, otherwise called the “happy path.” Ask yourself, what happens most of the time and you’ll discover the steps that belong here. You’ll want your basic flow to cover the full scope of activities between the starts when and ends when.
Create a numbered list of each step below. I recommend using the Word “numbered list” functionality to automatically number the list.
Alternate/Exception Flows
An alternate flow is a variation from the basic flow. Alternatives can be triggered at any step in the basic flow and often reinsert the actors back into the basic flow.
An exception flow is an error, or a negative condition. When an exception is encountered, it prevents the process from finishing through to its conclusion until it’s addressed.
Number your alternate and exception flows to indicate the step at which the variation occurs. For example, a variation on step 3 could be listed as 3a and a second variation as 3b, and so forth.
Describe the alternate functionality and then identify at what step in the basic flow this variation picks back up. For exception flows that result in the use case ending, simply write, “Use Case Ends.”
1a -
Post Conditions
Post-conditions indicate what must be true of the state of the system after the steps of the use case are complete. These should be true for the basic flow and all alternate flows. Exception flows may have different post-conditions or none at all.
Supplemental Requirements
This is a special section I use to hold miscellaneous requirements related to the use case. Often you’ll find BAs including a Business Rules section or other collection of information related to the use case. These may or may not be actual requirements – you’ll want to establish a clear pattern and communicate that clearly and ensure it’s consistent with how your organization documents this type of requirement. I’ve also used this section to capture the most salient decisions and notes so they are stored right with the use case for future consideration.
Visual Model
Many use cases are enhanced by a visual model. A simple work-flow diagram can be used to visually show the sequence of steps and alternate and exception flows. A user interface mock-up can be used to show a possible representation of these user requirements in an interface (or a desired representation). In some organizations, a more formal UML diagram may be appropriate.