Architecture
Vue physique
Vue de la fiabilité
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
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.