Architecture

1. Introduction

Le but de ce chapitre est de spécifier l’architecture d’une famille de produits, dont le projet Trivial Pursuit en fait partie.

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

2. 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 :

  1. Le diagramme de déploiement, qui ci doit expliquer la plupart des points énoncés précédemment.

  2. Le diagramme de déploiement au niveau des instances, qui respecte les spécifications du diagramme précédent, pour montrer comment seront réparties les instances de ceci.
diagram
Figure 1. Exemple d’un diagramme de déploiement (niveau spécification)

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.
diagram
Figure 2. Exemple d’un diagramme de déploiement (niveau instance)

Expliquez ce diagramme, si les artefacts déployés sont différents, vous pouvez le montrer.

3. 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.
diagram
Figure 3. Initialisation du système

4. 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.
diagram
Figure 4. Organisation des modules

5. 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.

6. Vue des processus

TODO!

7. 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.

7.1. Règles de traduction des types de base

Table 1. Traduction des types de base
UML Java TypeScript

Integer

int

number

Boolean

boolean

boolean

String

String

string

Real

double

number

7.2. Conventions de codage

Expliquez ici les conventions de codage, Java et TypeScript, que les développeurs devront respecter.

7.3. Règles de traduction des composants

Explique ici les règles que vous allez utiliser pour mettre en œuvre les composants UML.

7.4. Règles de traduction des classes

Explique ici les règles que vous allez utiliser pour mettre en œuvre les classes UML.

7.5. Règles de traduction des associations

Expliquez ici les règles qui vous devrez suivre pour mettre en œuvre les associations, agrégations composites et agrégations partagées.

8. Conclusion

Ajoutez une conclusion à la section "architecture" de votre documentation.