You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
64 lines
8.0 KiB
64 lines
8.0 KiB
L'architecture de l'application LOLAPP a été conçue en prenant en compte plusieurs aspects clés pour assurer sa robustesse et sa maintenabilité.
|
|
Pour faciliter la compréhension de son fonctionnement, la description de cette architecture a été divisée en six parties distinctes : les Patrons de conception utilisés, les Composants, la Modélisation des dépendances, les Couches d'architecture, les Interfaces et les Flux de données importants.
|
|
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
1-Patrons de conception utilisés :
|
|
|
|
Modèle-Vue-VueModèle (MVVM) : L'application utilise le modèle MVVM pour séparer les préoccupations en utilisant les composants suivants :
|
|
Modèles : Les classes telles que Champion, Ability et Utilisateur représentent les modèles de données de votre application.
|
|
Vues : Les pages telles que Main, Strat, Register et Login représentent les vues de l'application.
|
|
Vue-Modèles : Je n'en ai pas utilisé.
|
|
|
|
Injection de dépendances : L'injection de dépendances est utilisée pour gérer les dépendances entre les différents composants de l'application, améliorant ainsi la modularité et la testabilité du code.
|
|
|
|
|
|
Ces patrons de conception permettent de mettre en place une architecture claire et bien organisée, favorisant la séparation des préoccupations et facilitant la maintenance et l'évolutivité de votre application.
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
2-Composants :
|
|
|
|
DataContractPersistance :
|
|
DataContract : Cette classe spécifie les contrats de données à utiliser. Elle peut définir les propriétés et les méthodes nécessaires pour la sérialisation et la désérialisation des objets de données.
|
|
DataToPersist : Cette classe spécifie les données à persister. Elle regroupe les objets Champion et Utilisateur dans des listes pour faciliter leur gestion et leur utilisation.
|
|
Stub :
|
|
Stub : Cette classe spécifique est utilisée pour charger des données. Elle implémente des méthodes qui retournent des données pré-définies pour le chargement de l'objet Champion.
|
|
Modele :
|
|
Ability : Cette classe représente les capacités dans l'application. Elle contenient des propriétés telles que le nom, la description et le nom de l'image.
|
|
Champion : Cette classe représente les champions utilisés dans l'application. Elle contenient des propriétés telles que le nom, les capacités associées et d'autres informations spécifiques au champion.
|
|
IPersistanceManager : Cette interface spécifie les opérations de base pour charger et sauvegarder les données des champions et des utilisateurs. Elle définit des méthodes telles que "Chargdon" et "Sauvdon".
|
|
Manager : Cette classe contient le gestionnaire utilisé dans l'application. Elle implémente l'interface IPersistanceManager et coordonne les opérations de chargement et de sauvegarde des données mais permet aussi l'enregistrement et le login d'utilisateur.
|
|
Strategie : Cette classe représente les stratégies utilisées dans l'application. Elle contenient des propriétés telles que le nom de la stratégie, les champions associés et d'autres informations pertinentes.
|
|
Utilisateur : Cette classe représente les utilisateurs de l'application. Elle contenient des propriétés telles que le nom d'utilisateur, le mot de passe et les stratégies associées à l'utilisateur.
|
|
View :
|
|
Main : Cette page représente l'écran principal de l'application et contient les éléments liés aux champions. Elle peut afficher la liste des champions disponibles et permettre à l'utilisateur de sélectionner un champion et voir ses informations.
|
|
Strat : Cette page contient les éléments liés aux stratégies de l'utilisateur. Elle peut afficher les stratégies existantes de l'utilisateur, permettre la création de nouvelles stratégies et la suprésion des stratégies existantes.
|
|
Register : Cette page représente l'écran d'inscription de l'application. Elle peut afficher les champs nécessaires pour que l'utilisateur crée un compte, tels que le nom d'utilisateur et le mot de passe. Une fois que l'utilisateur remplit les informations requises et les soumet, la classe Manager gère la création du compte et la persistance des données dans la base de données.
|
|
Login : Cette page représente l'écran de connexion de l'application. Elle permet à l'utilisateur de saisir ses identifiants (nom d'utilisateur et mot de passe) pour accéder à son compte. Une fois les informations d'identification soumises, la classe Manager vérifie leur validité et autorise l'accès à l'application.
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
3-Modélisez les dépendances :
|
|
|
|
Les dépendances sont représentées dans le diagramme de classes avec les flèches de dépendance entre les différents composants.
|
|
Par exemple, les classes du paquetage "Stub" dépent des classes "IPersistanceManager, "IPersistanceManager" est l'interface de "Manager", "Ability" est agréée dans "Champion" et "Champion" dans "Strategie"...
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
4-Couches d'architecture :
|
|
|
|
Dans l'architecture de l'application LOLAPP, nous pouvons identifier les couches suivantes :
|
|
La couche de présentation (View) : Cette couche est responsable de l'interface utilisateur de l'application.
|
|
Elle affiche les données et permet à l'utilisateur d'interagir avec l'application.
|
|
|
|
La couche de logique métier (Modele) : Cette couche contient les classes qui représentent le modèle de l'application, telles que les classes Champion, Strategie et Utilisateur.
|
|
Elle gère la logique métier de l'application, comme la création de comptes, la gestion des champions et des stratégies.
|
|
|
|
La couche d'infrastructure (DataContractPersistance et Stub) : Cette couche fournit des fonctionnalités d'accès aux données et de persistance.
|
|
Les classes du paquetage DataContractPersistance sont responsables de la sérialisation et de la désérialisation des objets de données, tandis que les classes du paquetage Stub fournissent des données simulées pour le chargement initial.
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
5-Interfaces :
|
|
|
|
IPersistanceManager : Cette interface spécifie les méthodes de base pour charger et sauvegarder les données des champions et des utilisateurs.
|
|
Les classes qui implémentent cette interface, comme la classe Manager, doivent fournir une implémentation pour ces méthodes.
|
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
6-Flux de données :
|
|
|
|
Les flux de données importants dans l'application inclut :
|
|
Le flux de données lors de la création d'un compte utilisateur, où les informations saisies par l'utilisateur sont envoyées à la classe responsable de la création du compte et de la persistance des données, le Manager.
|
|
Le flux de données lors du chargement initial des champions et des utilisateurs, où les données sont soit chargées à partir de la base de données, soit à l'aide de la classe Stub.
|
|
Le flux de données lors de la création, de la modification ou de la suppression d'une stratégie par l'utilisateur, où les informations sur la stratégie sont transmises à la classe Utilisateur. |