Architecture

Introduction

Il s’agit ici de choix génériques, qui peuvent s’appliquer à plusieurs projets.

Vue physique

diagram
Figure 1. diagramme de déploiement (niveau spécification)
diagram
Figure 2. Exemple d’un diagramme de déploiement (niveau instance)

Vue de la fiabilité

diagram
Figure 3. Initialisation du système
diagram
Figure 4. Arrêt du système
diagram
Figure 5. Le joueur 1 se déconnecte
diagram
Figure 6. La partie est finie

Vue du développement

Phase de développement non commencée.

Vue logique

Cette configuration de composants pourrait tout à fait marcher dans un autre projet. On a une database, qui est utilisé par un serveur, et le serveur et les utilisateurs communiquent. Notre façon de communiquer, en mettant plusieurs étapes, permettra une adaptabilité plus facile à chaque type de projet.

Le composant Middleware permet ainsi de prendre l’information des clients, en TypeScript, de le traduire en WebSocket, de le transmettre à la partie serveur Middleware qui lui fera la transcription inverse mais en Java cette fois-ci. Pourquoi en Java ? Le logiciel est prévu comme cela, mais les langages TypeScript et Java ne sont pas obligatoires. Un projet peut reprendre cette structure avec des langages différents.

Vue technique : traduction de UML en code source

Règles de traduction des types de base

Table 1. Traduction des types de base
UML Java TypeScript

Integer

Integer

Number

Boolean

Boolean

Boolean

String

String

String

Real

Float

Number

Map (classe que l’on a rajouté dans le modèle)

Map

Map

Conventions de codage

Java :
Les classes respectent le même profil de nom (exemple : MaClasse). Les méthodes respectent le même profil de nom (exemple : maMethode()). Les noms de variables auront un nom le plus clair possible (exemple : Integer prixEuroPainChocolat = 3;).

TypeScript :
Les méthodes et les variables → pareilles que pour Java.

Règles de traduction des composants

Un composant peut correspondre à une ou plusieurs classes. Cela s’illustre bien avec le composant Game qui aura plusieurs composants et eux-mêmes auront une ou plusieurs classes.

Règles de traduction des classes

Plus de précisions ici : UmlToJava.

Règles de traduction des associations

Une association entre 2 objets représente soit une, soit plusieurs méthodes permettant de mettre en application la fonctionnalité décrite par l’association.