002.

Document de conception technique

Table des matières

002.TeDocument de conception technique 0

2
002.Document de conception technique

002.Document de conception technique

Document de conception technique

N'oubliez pas que vous êtes avant tout des architectes de systèmes logiciels. Logiciel de jeu
Les concepteurs sont le meilleur des meilleurs des ingénieurs logiciels. Les concepteurs de jeux conçoivent et
implémenter le gameplay, cela pourrait être un jeu de cartes, ou du papier et des crayons. Programateurs de jeux

fait référence à l'écriture du code qui automatise ce jeu de cartes ou ce jeu de papier et crayon.
Au-delà de simplement écrire du code, les architectes de systèmes de logiciels de jeu conçoivent les systèmes qui sont

puis confié à des développeurs pour être construit.

Nous utilisons la documentation pour planifier, concevoir et communiquer tous les aspects d'un projet, dans notre

cas, un jeu. Les documents de conception du jeu décrivent le jeu, le plan de projet décrit
le processus de construction, et le document de conception technique décrit le logiciel
système qui est le jeu.

Il est important de réaliser que bien que nous lisions ces choses de manière linéaire, du début à la fin, elles sont
rarement, voire jamais, créé de la même manière. Nous commençons souvent par un noyau technique et développons à partir de là.

Si vous avez correctement rédigé vos descriptions de design de jeu, vous avez défini le joueur.
activités et la réponse du jeu. Tous les personnages et objets du jeu, tous les systèmes de combat et
des systèmes de notation ont été élaborés sur des feuilles de calcul avec un niveau de détail que vous pouvez

jouez au jeu sur papier d'ici là.

Le temps de définir les mécaniques de jeu est révolu et il est maintenant temps de traduire le
les activités des joueurs dans les exigences du système logiciel. Nous allons utiliser le prototype
Spécification des exigences logicielles selon IEEE 803-1998. C'est un secteur
cadre standard pour le formatage des exigences du système logiciel. Selon l'IEEE
l'orientation, un document technique bien réalisé sera précis et complet, avec le système
fonctionnalités priorisées par importance, sans ambiguïtés ni incohérences. Le système
la conception et la construction doivent être vérifiablement correspondantes aux règles de jeu, à ce qui a été déployé

système logiciel, avec une trace de vérification documentée qui peut être retracée du début à la fin.
Enfin, la documentation et les processus de développement doivent être suffisamment flexibles pour être
modifiables pour répondre à des découvertes imprévues en cours de route. La plupart d'entre elles sont auto-
évident, et peut être recherché pour des informations supplémentaires, cependant jetons un coup d'œil à certains de
les points saillants.

Que signifie complet ?

002.Document de conception technique 3

002.Document de conception technique

Tous les attributs des exigences et des contraintes fonctionnelles et de performance sont inclus pour tous
composants internes et interfaces externes. Toutes les classes de données sont définies, et toutes les situations
des réponses du système à eux sont décrites, y compris ce qui se passe lorsque des saisies invalides sont
fait. Tous les termes, unités de mesure, sont entièrement définis dans les annexes, et toutes les figures, tableaux,
et les diagrammes sont entièrement annotés. Si TBD est jamais utilisé (et il est fortement recommandé à
cette phase de développement où vous reconnaissez que tous les TBD sont des faiblesses et des menaces pour
le succès du projet,) il devrait toujours être accompagné de la situation qui cause le TDB
et que peut-on faire pour l'éliminer.

De quoi s'agit-il en matière de cohérence ?

Cela concerne l'établissement de la continuité tout au long du projet. Si un niveau inférieur de détail
la description ne correspond pas à une description de haut niveau, alors la construction est par nature cassée. Ce
Il est également important d'établir une piste de vérification - être capable d'établir une traçabilité. Selon
Les directives, il existe trois types d'incohérences.

1. Les caractéristiques spécifiées de quelque chose sont en conflit. Par exemple, le Mage's
les attributs sont prioritaires tels que l'Intelligence, la Ruse et le Pouvoir de Conjuration dans une section, et

Intelligence, Ruse et Force dans un autre (étant donné que la Force et le Pouvoir d'Invocation sont
deux objets distincts.)
2. Il y a une disparité logique ou séquentielle dans le flux de processus.
Une section dit que monter de niveau est un événement multiplicatif, le niveau un multiplie la valeur.
de l'attribut par un, niveau deux par 2, niveau trois par 3, etc. Et une autre section
dit, ou le système a été construit de manière additive, de sorte que le niveau un ajoute 1, le niveau deux ajoute 2,

le niveau trois ajoute 3.

ii. Le joueur doit atteindre A avant que B ne soit débloqué. Pourtant, dans une section subséquente, ou

Actuellement, le joueur est capable d'atteindre B sans avoir accompli A.

3. Continuité linguistique, où différentes sections décrivent et définissent la même chose en utilisant
termes différents.

Quelles sont les degrés de nécessité et de stabilité ?

Tout comme la standardisation des descriptions et des définitions du système est essentielle, inculquer un
la compréhension de la nomenclature acceptée est également essentielle pour être clair et sans ambiguïté
communications. Les catégories utilisées sont Essentielles, Conditionnelles et Optionnelles.

1. Les exigences essentielles sont juste cela, le système ne fonctionne pas comme requis sans,
comme une frontière de collision autour d'un objet destiné à subir des dégâts. Ceux-ci sont affichés

bouchons.
2. Les exigences conditionnelles améliorent le système mais ne sont pas essentielles à son fonctionnement.
Améliorer une arme, un bouclier ou un système de propulsion améliore le gameplay, mais le jeu...
les caractéristiques d'identification essentielles restent indépendamment de cette caractéristique.

3. Les options ne sont pas des exigences, mais des éléments non essentiels qui peuvent ou non être.

002.Document de conception technique 4

002.Dossier de conception technique

digne d'intérêt. Dans un projet de jeu, il a été proposé d'avoir un randomiseur qui provoquait un
le pilote éternue, obscurcissant ainsi sa vue et sa concentration, provoquant un défi aléatoire
à la performance.

Pourquoi la vérifiabilité et la traçabilité sont-elles importantes ?

Comment savons-nous d'autre que ce que nous avons construit est ce qui a été décrit à l'origine ? Dans l'industrie, c'est un

énorme. Lorsqu'un système est contracté, de l'argent est en jeu (même sur une base salariale).
Parfois de grandes sommes d'argent. Obligations contractuelles pour de grandes sommes d'argent
attirer des avocats. Avoir un environnement de test et de vérification inébranlable sur votre projet est le
cœur de protection. D'une importance plus pratique, cela garantit que ce qui a été proposé,
contracté, conçu, construit et payé est livré. Pour atteindre cette vérifiabilité, nous liions un
cas de test pour chaque cas d'utilisation.

La traçabilité nous amène là où le caoutchouc rencontre la route. Essentiellement, le flux logique est de
commencez avec votre document de jeu terminé où chaque activité de joueur et réponse de jeu
est clairement défini en détail. N'oubliez pas, si ce n'est pas dans le document de conception du jeu, ce n'est pas dans le

jeu. La liste des activités des joueurs est rédigée du point de vue des joueurs, "Le joueur lance
le jeu, le joueur se connecte, et le joueur choisit un profil existant ou crée un nouveau
un..." Le document de conception technique traduit ces activités du point de vue de l'
système logiciel, « À son lancement, le système présente l'écran de connexion. L'écran contient
un formulaire avec des champs pour collecter le nom d'utilisateur et le mot de passe, ainsi qu'un lien pour s'inscrire à un nouveau

compte ou réinitialiser le mot de passe. Dans la version avec publicité, un espace est prévu à [exact
emplacement de l'écran]…

Soyez conscient que ce sont des exemples pour illustrer l'activité de traduction, et ne sont pas dans le
format standard utilisé. Le format est une liste structurée. Le numéro de référence de chaque élément de la liste
est utilisé pour lier la traçabilité à travers la trace documentaire de la liste d'activité des joueurs dans le jeu
document de conception, à travers le document des exigences du système logiciel, aux tests unitaires,
documents de tests d'intégration, de tests de plateforme et de tests d'acceptation finale de l'utilisateur. Éléments à la ligne

la traçabilité est la piste de vérification.

Développement rapide et utilisation d'un prototype ou d'une preuve de concept pour aider à la conception

processus.

Les prototypes (voir ASTM E1340-96) sont extrêmement utiles dans notre libération post-waterfall. D'abord
est-ce que le jeu est jouable ? Est-il amusant ? Est-il intéressant, captivant et satisfaisant, désiré par ses
joueurs ? Il y a trois principaux avantages du prototypage au-delà de ceux-ci et de la faisabilité du projet.
Ils fournissent des retours rapides, ils affichent des comportements inattendus ainsi que les comportements anticipés.

des aspects soulevant des questions qui peuvent ne pas être anticipées avant plus tard dans le processus. Cela
il est plus difficile de répondre aux surprises plus on avance dans le processus de développement, donc
les systèmes qui commencent par un prototypage sain et des spécifications de conception prennent moins de temps à

complet.

002.Document de conception technique 5

002.Document de conception technique

Un prototype est également un moyen d'extraire les exigences des systèmes logiciels, en expérimentant l'actuel.
le flux de processus est beaucoup plus précis que de le penser. Cela est particulièrement vrai avec de grandes

systèmes complexes et interfaces. Il est parfois plus simple de bricoler une interface
écran basé sur des croquis rapides ou une image mentale, et utiliser une capture d'écran de celui-ci pour le design

documentation. Cela permet également d'expérimenter pour faire évoluer les capacités d'un système.

Le Noyau

Le nom formel du document en dit long - Exigences fonctionnelles du système logiciel

Spécification. Quelles sont les fonctions spécifiques que le système logiciel doit remplir ?
fournir ?

Ce document traduit le point de vue des activités des joueurs en une description détaillée de,
quelles fonctions doivent être effectuées sur quelles données pour produire quels résultats à quel emplacement

et pour qui."(IEEE 830-1998, Sec. 4.7, Paragraphe 2)

La liste des exigences est un point de vue externe du système qui décrit l'externe
comportement du système, pas les processus internes, qui est réalisé lors de la prochaine étape à l'aide de
Outils UML. Conceptions d'objets de jeu comme les classes de personnages et les classes d'objets de jeu, et leur

les attributs sont modélisés dans le Document de Jeu. De ceux-ci viendront finalement les
les plans système traduits en entités de classe de données UML. La liste des exigences structurées
ne dit pas comment quelque chose doit être fait, juste que cela doit se produire.

Voici le plan prototype au format non annoté, donné dans la norme IEEE 830-1998.
Il commence par développer des informations importées des mêmes éléments dans la conception du jeu.
documents. N'oubliez pas que cela est strictement limité à la description du logiciel, pas du marché ou
type de joueur, marché compétitif, ou toute autre information méta de ce type à propos de
jeu.

Table des matières

Introduction

1.1 Objectif

1.2 Portée

1.3 Définitions, acronymes et abréviations

1.4 Références

1.5 Aperçu

2. Description générale

002.Document de conception technique 6

002.Dossier de conception technique

2.1 Perspective du produit

2.2 Fonctions du produit

2.3 Caractéristiques des utilisateurs

2.4 Contraintes

2.5 Hypothèses et dépendances

3. Exigences spécifiques (Voir 5.3.1 à 5.3.8 pour des explications des possibilités)

exigences spécifiques. Voir également l'annexe A pour plusieurs façons différentes d'organiser

cette section du SRS.)

Appendices

Index

Version annotée

Puisque la norme fournit un prototype, il est prévu qu'il soit modifié pour chaque cas particulier
utiliser. La forme suit la fonction. Parfois, tout n'est pas nécessaire. Lorsque c'est le cas
lorsque ces documents sont rédigés en tant que contrats juridiquement contraignants, certaines parties inutiles sont

documenté comme étant convenu par toutes les parties comme non nécessaire. Une mention de ceux-ci est faite

dans le cadre du document, et ils sont pris en compte en saisissant les détails du
accords de leur libération.

Voici comment la liste des activités des joueurs dans un document de conception de jeu est organisée selon
conformément aux directives de l'IEEE 830-1998. Il est utilisé pour dériver directement le cœur technique du système.

exigences.

Table des matières

1. Introduction – Les deux premières sections sont similaires à un résumé exécutif et sont de haut niveau.
niveaux d'introduction de choses qui seront remplies de détails plus tard dans des réglages de documents ultérieurs.
i. Objectif – Haute Concept/Genre, description du gameplay au plus haut niveau, ensemble des fonctionnalités.
ii. Portée – Qu'est-ce qui fait partie de cela et qu'est-ce qui n'en fait pas partie ? Plateformes, contraintes et limitations.

Par exemple, le projet est-il phasé, de sorte que cet ensemble de développement inclut
construction de la version solo du jeu uniquement, en préparation pour le suivant
phases de mise en œuvre des LAN et des MMOG ?
iii. Définitions, acronymes, abréviations - Évident, tout terme que quelqu'un
les personnes extérieures à l'équipe doivent comprendre.

Références

002.Document de conception technique 7

002.Donnée de conception technique

v. Aperçu du document des exigences. Une vue à 20 000 pieds de la structure du document
pour référence facile.

2. Description générale - Cette vue d'ensemble du système est destinée à décrire le

paramètres techniques (les modèles diagrammés sont un bon complément.)

2.1 Perspective produit – Détails de la plateforme, par exemple, si ce jeu fait partie d'un ensemble plus large

système de jeu, tel qu'un jeu multijoueur en ligne décontracté, hébergé sur un serveur central, avec
connexions peer to peer entre les appareils des joueurs, y compris les téléphones, les tablettes, les ordinateurs personnels, les consoles,

et des systèmes de jeu dédiés, comment les composants construits dans ce projet s'intègrent-ils et
interface avec le reste des composants ?

2.2 Fonctions du produit – Comment les composants de ce projet interagissent-ils avec les composants
en dehors de lui-même, le cas échéant.

2.3 Caractéristiques de l'utilisateur - Quels dispositifs d'interface spécialisés sont nécessaires, tels que Kinnect, Wii,

pavé tactile, joystick, contrôleur spécialisé, etc.

2.4 Contraintes – Exemple : si multi-plateforme, certaines fonctionnalités sont-elles limitées sur certaines ?

2.5 Hypothèses et dépendances

3. Exigences spécifiques

3.1 Exigences d'interface externe - Si quelque chose, qu'est-ce que cette unité de développement envoie à
d'autres et comment. Par exemple, si le résultat de ce projet est un client tablette pour un réseau hébergé
jeu, et est développé en parallèle avec le logiciel serveur, comment cela interopère-t-il
avec le serveur et d'autres pairs sur différentes plateformes telles que les téléphones et les consoles ?

3.1.1 Interfaces utilisateur

3.1.1.1 Caractéristiques logiques (fonctions effectuées) de chaque instance où le système

et l'interaction des utilisateurs. Diagrammes de mise en page, captures d'écran, arbres de menu, contenus d'entrée et de rétroaction.

3.1.1.2 Spécification de retour d'information pour optimiser l'utilisabilité. (voir critères d'utilisabilité)

3.1.2 Interfaces matérielles – Périphériques et protocoles pris en charge et comment

3.1.3 Interfaces logicielles – Objectif et contenus des objets de données envoyés et reçus, et
comment

3.2.4 Interfaces de communication – protocoles réseau pris en charge

3.2.5 Contraintes de la plateforme – architecture matérielle, mémoire, stockage, sécurité, protocoles,

disponibilité des capteurs, etc.

002.Document de conception technique 8

002.Document de conception technique

3.2 Exigences fonctionnelles – C'est le cœur de ce dont il s'agit. Rappelez-vous que le

Au début de ce document, j'ai mentionné que bien que nous lisions ces choses de manière linéaire
de commencer à s'arrêter, ils sont rarement, voire jamais, écrits de la même manière. Voici le véritable point de départ et

où se concentre la plupart de l'attention durant la phase de collecte des exigences. Cette liste est un
interprétation de la Liste d'Activités des Joueurs, dans la vue du système externe discutée précédemment.
De cette liste sont dérivés le découpage, la modularisation et les schémas de communication.
de l'unité de production.

Il s'agit de la section la plus détaillée du document. Chaque élément doit contenir uniquement
une étape vérifiable. Lorsqu'une interface utilisateur collecte des informations, les informations collectées sont
énuméré ligne par ligne. Cette section est mieux augmentée par des diagrammes annotés qui illustrent le
séquence et flux du processus.

Les numéros des lignes d'articles sont utilisés pour référencer des diagrammes et des cartes de flux de processus, et pour

traçabilité grâce à la piste de audit. Lorsque nous commençons à rédiger les plans pour le système
modules, nous dérivons des cas d'utilisation de cette liste, nous référencions les numéros de section comme pratiques.

Souvent, plus la description est détaillée (Article Sec. 3.2.2.1.4.5), moins les chiffres sont susceptibles.
s'harmoniseront entre les documents. Les numéros de niveau supérieur (Sec. 3.2) sont utilisés comme ils
Il est logique de retracer depuis cette liste, jusqu'au cas d'utilisation, au cas de test, à l'optimisation et
rapports de bogues, au document d'acceptation final.

La pratique standard de l'industrie est d'utiliser des énoncés formulés comme suit : « le système doit... » Dans le
document de conception de jeu, vous avez utilisé des déclarations qui commençaient par : « Le joueur doit... » Cela est

la base de la traduction. Si vous avez bien conçu votre jeu, cette partie se remplit d'elle-même une fois
vous prenez le coup. Il est également temps de réfléchir aux détails.

Enfin, gardez à l'esprit que cela est écrit pour définir les actions fondamentales qui doivent être prises.
place par le code dans la gestion des entrées, et leur traitement, et l'envoi des sorties. Au maximum
niveau de base, gardez à l'esprit la nécessité de réfléchir aux éléments suivants pendant que vous travaillez sur le prochain

Section, 3.2.1.

3.3 Fonctionnalité du module

3.3.1 Vérifications de validité des entrées - doit-il vérifier l'entrée non corrompue et comment.

3.3.2 Séquence des opérations – où ce module est-il placé dans l'ordre d'écoulement

3.3.3 Réponses aux situations anormales, y compris

3.3.3.1 Débordement

3.3.3.2 Installations de communication

3.3.3.3 Gestion des erreurs et récupération

3.3.4 Effet des paramètres – configuration, situation et changements environnementaux

002.Document de conception technique 9

002.Document de conception technique

3.3.5 Relation des résultats aux intrants, y compris

3.3.5.1 Séquences d'entrée/sortie

3.3.5.2 Formules pour la conversion d'entrée en sortie

3.2.1 Nom du sous-système A

3.2.1.1 Énoncé des exigences

3.2.1.2 Énoncé des exigences

3.2.1 Nom du sous-système B

3.2.1.1 Énoncé des exigences

3.2.1.2 Déclaration des exigences

3.2.3 Détails de mise en œuvre physique – Cela se produit lors de la construction du code sur le puits
niveau de code commenté. Les modules de code doivent être référencés en arrière à travers la ligne de
traçabilité du morceau de code à l'utilisation du cas, au cas de test, à la liste des exigences, à l'activité du joueur

liste.

3.4 Exigences de performance - Les attentes pour une performance acceptable

3.3.1 Normes, protocoles et sécurité

3.3.2 Limitations matérielles

3.2.1 Disponibilité

3.2.2 Sécurité

3.2.3 Maintenabilité

3.5 Base de données – Classes et structures de données

MCD

3.5.2 Types de données utilisés par des fonctions spécifiques

3.5.3 Fréquence

3.5.4 Accédé

3.5.5 Vérification d'intégrité

5.5.6 Normes de conservation

3.6 Plan de test

3.6.1 Méthodologies

002.Document de conception technique 10

002.Document de conception technique

3.6.2 Ressources

3.6.3 Résultats

Plans pour le système

Une fois que la liste des exigences est complète et convenue, il est temps de passer à l'étape suivante de
interprétation. Les éléments suivants dérivés de la Section 3 : diagrammes de cas d'utilisation, cas d'utilisation

scénarios
Cas de test et critères d'acceptation.

Exemple de traduction

Notez qu'au niveau le plus élevé, nous décrivons l'écran d'accueil (Fig 1), Créer un compte
(fig 2), Menu Principal du Jeu (Fig 2), Paramètres du Jeu (Fig 3), et Créer un Profil (Fig 4)
interfaces. Pensez aux sous-sections de chacune comme des menus extensibles pour rester organisés. Cela est
présenté pour illustrer comment voir les modules logiques dans les activités des utilisateurs. Dans cet exemple un
Un groupe d'activités est lié les unes aux autres par leur fonctionnalité.

Prototypes d'interface

Fig 1 (Ref 1.2, 1.5) Fig 2 (Ref 1.4.1) Fig 3 (Ref 2.3)

Fig 4 (Réf 3) Fig 5 (Réf 4)

La liste d'activités des joueurs contient des séquences pour le scénario suivant.

Écran d'accueil
i. Le joueur lance le jeu
ii. Le joueur voit l'écran d'accueil contenant
i. Instructions sur la nature de jouer au jeu de manière anonyme ou en tant que joueur enregistré

joueur
i. [Détails]
ii. Instructions pour créer un compte
i. [Détails]
iii. Bouton pour commencer une partie anonymement - [Référence au concept ou à l'élément artistique]

iv. Bouton pour créer un compte - [Référence au concept ou à l'élément artistique]

v. Champs de connexion
i. Nom d'utilisateur

ii. Mot de passe

vi. Bouton Quitter le Jeu [Référence à l'art conceptuel ou à un actif artistique]

iii. Le joueur choisit de rester anonyme

002.Dossier de conception technique 11

002.Document de conception technique

i. Le joueur apparaît dans le monde du jeu au premier point de chemin par défaut.

iv. Le joueur choisit de créer un compte

i. Le joueur voit l'écran d'inscription contenant
Nom
ii. Email
iii. Nom d'utilisateur

Mot de passe
v. Bouton de soumission [Référence à l'art conceptuel ou à un actif artistique]

vi. Bouton Annuler [Référence à un concept artistique ou à un élément artistique]

ii. Réponse du joueur

i. Saisir des informations dans les champs
ii. Cliquez sur Soumettre

L'utilisateur voit l'écran d'accueil

iii. Cliquez sur Annuler

L'utilisateur voit l'écran d'accueil

v. Le joueur choisit de se connecter avec un compte existant

i. Sur l'écran d'accueil, le joueur saisit des identifiants valides
i. Nom d'utilisateur

ii. Mot de passe

iii. Cliquez sur Annuler
L'utilisateur voit l'écran d'accueil

iv. Cliquez sur Soumettre

2. Écran principal du menu du jeu

i. Après une authentification réussie, le joueur voit le menu principal du jeu
i. Bouton démarrer une nouvelle partie [Référence à un concept art ou un élément artistique]

ii. Charger le bouton de jeu existant ] Référence à l'art conceptuel ou à un atout artistique [

iii. Icônes de personnages existants [Référence à l'art conceptuel ou aux ressources artistiques]

i. Bouton Modifier [Référence à l'art conceptuel ou à un élément artistique]

ii. Sélectionnez le bouton [Référence à l'art conceptuel ou à l'élément artistique]

iv. Créer un nouveau personnage bouton [Référence à l'art conceptuel ou à l'actif artistique]

v. Bouton des paramètres du jeu

3. Écran du menu des paramètres du jeu

i. Son
ii. Musique
iii. Graphiques
iv. Réseau
v. Menu Principal
4. Créer l'écran du menu des personnages
i. Classe de personnage
Voleur

002.Document de conception technique 12

002.Document de conception technique

ii. Paladin
iii. Mercenaire
iv. Mage
v. …
ii. Apparence
i. Éditeur d'avatar [Référence à l'art conceptuel ou aux éléments artistiques, dépendant de la présentation]

sur la classe de personnage sélectionnée

ii. …
iii. Équipement
i. Le joueur présente des objets d'équipement initiaux en fonction de la classe de personnage

ii. …

Diagramme de flux de processus.

Fig 6

Maintenant que nous avons établi les critères du document de conception du jeu, il est temps de voir comment cela

traduit dans les exigences système logicielles techniques comme nous en avons discuté.

Exigences fonctionnelles spécifiques du système

1. Au démarrage du système et à la vérification des conditions de fonctionnement, le système logiciel

présentera l'écran d'accueil

2. Options de l'écran d'accueil

Lancer un nouveau jeu anonymement

ii. Créer un compte
iii. Se connecter
i. Nom d'utilisateur

mot de passe
iv. Quitter le jeu
3. Lors du lancement d'un nouveau jeu, le système logiciel doit déplacer le joueur dans
le monde du jeu avec des valeurs d'attributs par défaut et aléatoires
i. Charger un avatar générique
ii. Configurer les attributs de l'avatar
iii. Fournir un équipement d'avatar
iv. Faire apparaître l'avatar au point de départ par défaut
4. Lors de la création d'un nouveau compte, le système logiciel doit présenter une interface pour collecter

informations spécifiées pour le stockage et la récupération immédiats pour l'utilisation du système.

i. Entrées utilisateur

i. Nom
ii. Email
Nom d'utilisateur

002.Document de conception technique 13

002.Document de conception technique

iv. Mot de passe

v. Soumettre
vi. Annuler
ii. Lors de la soumission, le système logiciel devra envoyer les données du profil utilisateur() au

base de données
i. Effectuer la vérification du nom d'utilisateur existant

i. Si le nom d'utilisateur existe déjà, le système logiciel doit afficher

[Nom d'utilisateur déjà existant]
ii. Si le nom d'utilisateur n'existe pas, créez une entrée dans la base de données dans les champs corrects

i. Si l'entrée de la base de données échoue, le système logiciel doit signaler et enregistrer le

détails de l'incident.

Le système logiciel doit afficher un message d'échec de la base de données.

Un rapport d'erreur sera ajouté au journal des événements

Le message doit contenir des informations pertinentes sur l'échec

1. Si l'enregistrement de la base de données réussit, le système logiciel doit afficher

message de confirmation de succès

Si l'utilisateur n'entre pas d'accusé de réception après 10 secondes, le système logiciel doit
afficher l'écran d'accueil

Lors de la reconnaissance de l'entrée de l'utilisateur, le système logiciel affichera l'écran d'accueil.

1. Si l'utilisateur choisit d'annuler le processus d'inscription, le système logiciel

affichera l'écran d'accueil

Cela suffit pour voir comment la traduction a révélé des processus sous-jacents très détaillés.
Nous avons commencé avec les chiffres, mais les étapes supplémentaires ont une traçabilité discontinue.
Des projets extrêmement ambitieux indexeront à travers les documents, mais ce degré de minutie
ne convient pas à l'écriture du code du jeu. Donc, pour la traçabilité, nous assignerons l'ID du cas d'utilisation
de la dernière et la plus détaillée révision de la liste des exigences.

Un processus logique partiel ressemble très différemment aux cartes de conception de jeu. Cela illustre
ce que fait le logiciel, et devrait ressembler à quelque chose comme ceci :

Fig 7

002.Document de conception technique 14

002.Document de conception technique

Relations d'objet de tâche

Il est également temps de réfléchir aux objets logiciels, à leurs noms et à leur emplacement.
placé sur la carte ci-dessus. "profil utilisateur()" n'est pas une erreur d'impression dans 1.4.2, c'est une planification à l'avance pour

le nom d'un objet de code. Il sera nécessaire de createUserProfile(), verifyUserProfile(),

ainsi que d'autres qui viendront à l'esprit. C'est ici que nous commençons la Relation d'Objet de Tâche.
Nous avons maintenant le nom de la tâche et les fonctions qu'elle doit exécuter.

Fig 8.

TOR

Nom de l'objet Fonctions réalisées

creerProfilUtilisateur() collecter les informations de l'utilisateur pour créer un nouveau compte

vérifiez la base de données pour une entrée identique existante

créer un enregistrement correctement nommé dans la base de données

insérer les données correctes dans le champ approprié

maintient les données jusqu'au signal de destruction de validateUserProfile()

envoie un signal pour créerDialogueSuccèsProfilUtilisateur()

validerProfilUtilisateur() sélectionner tous les champs d'enregistrement

comparer tous les champs d'enregistrement aux données aidées par createUserProfile()

vérifier l'état du rapport

Si l'échec se produit, afficher une boîte de dialogue d'erreur contenant le message pertinent.

Si échouent, ajouter un message pertinent au journal des événements avec l'heure de l'incident

timbre
Si réussi, envoyer le signal de destruction à createUserProfile()

Si réussi, envoyer un signal à createUserProfileSuccess()

Les relations entre objets de tâche sont les débuts des cas d'utilisation, car elles définissent le
activités une par ligne que la fonction effectue. Cette liste de base est

Entités de jeu vers entités de données

Dans le jeu, les entités sont décrites dans le document de jeu. Les classes de personnage ont été
créés avec des ensembles d'attributs et de relations. Les systèmes de combat et les systèmes de notation sont
développé et prêt à être converti en objets de code. En commençant par les classes les plus hautes,
Objets, personnages, éléments environnementaux. Tous ceux-ci ont la possibilité d'être
interactif ou non interactif, l'interactivité devient un attribut de toutes les classes. Les objets

002.Document de Conception Technique 15

002.Dossier de conception technique

la classe peut contenir de l'équipement de bataille, de l'équipement de construction, des matériaux de construction, des véhicules, des bonus, tous avec

un certain effet mathématique sur le système de jeu. La classe de personnage contient Paladin,
Mage, Voleur et Mercenaire.

Fig 9

Classes de personnages et leurs attributs issus du document de conception de jeu

Soi
La vie Endurance Force Intellect Wile Discrétion
intérêt
Paladin
7 6 8 5 3 5 4
Puissance

Mage -
4 5 4 8 6 5 7
Sagesse

Voleur
5 5 5 7 9 7 8
Dextérité
Mercenaire 6 6 7 5 4 8 5

Ceci est le début d'un diagramme de classe basé sur le tableau ci-dessus, et montre le
organisation des attributs et des fonctions qui composent les objets de jeu.

Fig 10

Reportez-vous à vos cours et à votre expérience en ingénierie logicielle pour continuer à construire.
vos diagrammes de relations d'entité au fur et à mesure que vous progressez dans le développement recommandé

cycle.

Dans la liste des exigences du système logiciel, les cas d'utilisation sont regroupés par fonction. Dans le

exemple ci-dessus, la fonction était l'interaction avec les fonctions d'inscription et de connexion dans
le module de gestion des comptes joueurs. À partir de la liste TOR, nous élaborons des cas d'utilisation et

Guide-les à travers les étapes suivantes. Assure-toi de vérifier DocSharing pour plus de modèles.

Fig 11

1. Analyser les activités des joueurs et les traduire en exigences système

002.Document de conception technique 16