Architecture
Introduction
|
Le but de ce chapitre est de spécifier l’architecture d’une famille de produits, dont le projet 7 Wonders en fait partie. Il s’agit ici de choix génériques, qui peuvent s’appliquer à plusieurs projets. |
Vue physique
|
La vue physique a pour but de décrire comment devrait être déployé le logiciel selon des nœuds logiques. Ainsi que de définir comment ou plutôt par quel moyen les différents nœuds vont communiquer entre eux. Et enfin le dernier but de cette vue est de donner les différentes contraintes de déploiement, comme quelles librairies sont utilisées, quels sont les besoins matériels. |
|
Pour décrire la vue physique, vous allez vous appuyer sur deux diagrammes :
|
|
Décrivez les nœuds logiques, ainsi que les artefacts qui peuvent être déployés sur ces nœuds. Vous pouvez profiter de ce diagramme pour expliquer le protocole de communication entre les nœuds. |
|
Expliquez ce diagramme, si les artefacts déployés sont différents, vous pouvez le montrer. |
Vue de la fiabilité
|
Dans cette partie, vous allez présenter les différents choix architecturaux pour assurer la fiabilité du système. Vous devez aussi présenter les prévisions de fonctionnement dans des conditions limite : * Comment le système est initialisé ? * Comment le système est arrêté ? * Comment sont gérés les failles et le redémarrage du système ? |
|
Utilisez des diagrammes d’activité UML pour décrire l’initialisation et l’arrêt du système. |
Vue du développement
|
Décrivez ici l’organisation du code source. Plutôt que décrire les paquetages Java ou Typescript, décrivez plutôt les artefacts Maven et les modules Node.js. |
|
Utilisez un Diagramme de paquetages pour décrire l’organisation du code source. |
Vue logique
|
L’objectif de la vue logique est de décrire les différents composants qui jouent un rôle commun dans les différents projets qui respectent une même architecture. |
Vue technique : traduction de UML en code source
|
Expliquez, dans cette section, l’ensemble de règles que vous utiliserez par la suite pour traduire les diagrammes de conception UML en code source Java et TypeScript. |
Règles de traduction des types de base
| UML | Java | TypeScript |
|---|---|---|
Integer |
Integer |
Number |
Boolean |
Boolean |
Boolean |
String |
String |
String |
Real |
Float/Double |
Number |
Conventions de codage
Le projet respecte les conventions de codage standards de la programmation orienté objet, notamment pour le nommage : pascal case pour le nom des classes, camel case pour le nom des fonctions. De plus, le front-end du projet utilise les extensions Prettier et ESlint pour Nuxt et TypeScript afin de garatir une homogénéité du code source.
Règles de traduction des composants
Côté serveur
Chaque composant devient un package dont l’organisation est la suivante : un controller pour recevoir et gérer les requêtes du client, un service pour effectuer les opérations, un repository pour effectuer les requêtes à la base de données, dans le cas où ce serait nécessaire. Pour gérer les types de données, un sous-dossier dtos existe. Il contient les classes pour le typage des données renvoyées au client, pour valider les données reçues par le serveur et mapper le résultat des requêtes de la base de données.
Côté client
Les composants seront divisés selon ce qui correspond à la logique de mise en oeuvre des changements de l’interface et ce qui relève de la communication client/serveur.
On veillera à séparer opérations de requêtes au serveur et de communication web socket dans un dossier services/api à part. Les logiques de changements UI et UX de l’interface seront effectuées directement dans la classe TypeScript associée à la page ou au composant Vue concerné.
Les interfaces représentant les types de données seront incluses dans services/interfaces.