@ -24,7 +24,7 @@ Il vous est demandé de réaliser cette application en respectant le calendrier
## Fourni
Le modèle est fourni ainsi qu'une couche d'accès aux données (probablement un stub, mais si je trouve le temps, une base de données locale ou accessible via un service web).
Le **diagramme de classes du modèle** est fourni ainsi qu'une couche d'accès aux données (un **stub accessible via un service web**).
## Calendrier prévisionnel
@ -245,6 +245,100 @@ Il vous est demandé de suivre les conseils donnés en cours quant à l'utilisat
L'utilisation du framework **MVVM Community Toolkit** est interdite pour la partie 2, mais fait l'objet de la partie 3. Une validation de la partie 2 auprès de votre enseignant avant de passer à la partie 3.
## Diagramme de classes du modèle
### ```Person```
Une personne peut représenter un administrateur (peut tout faire), un membre du personnel (*staff*, qui peut valider des emprunts et des retours), un étudiant (qui peut faire des demandes d'emprunt et de retour). Ceci est représenté par l'énumération ```Role``` et ces trois valeurs possibles (```ADMIN```, ```STAFF``` et ```STUDENT```).
Une personne possède également :
- un identifiant unique,
- un email (unique),
- un prénom et un nom de famille.
### ```Equipment```
Un élément de matériel est représenté par la classe ```Equipment```, qui possède :
- un identifiant généré lors de l'insertion dans la base,
- un nom
- une éventuelle description,
- une petite image en base64 (qu'il faudra décoder ou coder lors de la récupération ou de l'ajout/modification d'un élément)
- une grande image en base64
> **Note** :
> Lors de l'utilisation de la web api, une route rendant plusieurs équipements ne *rend* jamais les grandes images. Il faut utiliser une route permettant de récupérer un ```Equipment``` en donnant son id pour obtenir cette valeur.
- des propriétés permettant de connaître le nombre d'exemplaires de cet équipement (le nombre total, le nombre d'éléments en stock, le nombre d'éléments réservés, et le nombre d'éléments empruntables)
- un superviseur (une personne avec le rôle ```Staff```), qui est le responsable/spécialiste de ce matériel
- une collection d'exemplaires (```Copy```, cf. ci-dessous).
> **Note** :
> Lors de l'utilisation de la web api, une route rendant plusieurs équipements ne *rend* jamais la collection d'exemplaires. Il faut utiliser une route permettant de récupérer un ```Equipment``` en donnant son id pour obtenir cette collection.
### ```Copy```
Un exemplaire est représenté par la classe ```Copy```, et possède :
- un identifiant unique,
- l'```Equipment``` auquel cet exemplaire se rapporte,
- un état (```Condition```),
> **Note** :
> L'état représente ... l'état de cet exemplaire (neuf, excellent, très bon état, bon état, usure normale, endommagé, inutilisable)
- une situation (```Situation```)
> **Note** :
> La situtation d'un exemplaire permet d'indiquer s'il est : stocké (et donc empruntable), emprunté (donc non stocké), réservé (à l'IUT mais non empruntable), déstocké (il n'est plus utilisable donc plus empruntable).
### ```Borrowing```
Un emprunt est représenté par une instance de ```Borrowing```, et possède :
- un identifiant unique (généré par lors de l'insertion en base),
- l'exemplaire (```Copy```) emprunté
- l'emprunteur (```Borrower``` de type ```Person```, avec n'importe quel ```Role```)
- le responsable de l'emprunt (```StaffMember``` de type ```Person```, avec le rôle ```STAFF```),
- la date (```BorrowingDate```) et l'état (```OriginalCondition```) au début de l'emprunt,
- la date de retour (```ReturningDate```) et l'état (```ReturnedCondition```) au retour de l'exemplaire
> **Note** :
> La date de retour peut varier jusqu'au retour, en accord avec le responsable de l'emprunt.
> L'état du retour est, au démarrage de l'emprunt, par défaut, celui d'origine, mais pourra être ajusté lors du retour par le membre du personnel responsable de l'emprunt. Cette modification entrainera la modification de l'état de l'exemplaire (```Copy.Condition```).
- un commentaire (pouvant varier pendant l'emprunt).
### ```Reservation```
Une réservation d'exemplaires (pour des TP par exemple), est représentée par la classe ```Reservation```, et possède :
- un identifiant unique (généré lors de l'insertion en base)
- l'exemplaire réservé (```Copy```)
> **Note** :
> Pour simplifier le modèle, pour réserver plusieurs exemplaires, il faut autant d'instances de ```Reservation```.
- l'auteur de la réservation (```Person``` avec le ```Role``` ```STAFF```)
- une date de début de réservation (```StartingDate```) et une date de fin de réservation (```EndingDate```)
- un commentaire (permettant par exemple de donner les créneaux ou le groupe, ce qui pourrait permettre à un collègue d'accepter un emprunt sur un créneau de deux jours si on sait que l'exemplaire ne sera pas utilisé avant).
### ```IDataService```
Il vous est conseillé de faire une interface représentant le service d'accès aux données. Vous pourrez en faire une ou deux concrétisations, parmi :
- un stub (pour tester votre modèle, ou parce que vous avez du mal à faire le suivant...)
- un client consommant le web service fourni.
> **Note** :
> Vous pouvez placer cette couche abstraite dans une autre bibliothèque partagée, utilisée par le modèle. Pour cela, il faudra bien entendu rendre cette couche abstraite générique.
### ```Manager```
Cett façade sera l'interlocuteur privilégié entre votre applications et vos données. Vous pourrez injecter la couche d'accès aux données via constructeur, et utiliser les autres classes du modèle.
Les méthodes de ```Manager``` permettront d'appeler les routes du web service via la couche d'accès aux données (mais pas directement dans le code de ```Manager``` !) et les noms des méthodes pourront donc largement s'inspirer des routes.
```mermaid
classDiagram
@ -298,7 +392,7 @@ classDiagram
Email: string
}
Person --> "1" Role
Equipment --> "1" Person : Staff
Equipment --> "1" Person : Supervisor
class Borrowing {
Id: string
BorrowingDate: DateTime
@ -339,3 +433,122 @@ classDiagram
}
Manager ..> DataService
```
## Web service
Le [web service est accessible ici](https://codefirst.iut.uca.fr/containers/mchSamples_NET-njord).
La documentation **OpenApi** de celui-ci, est [accessible ici](https://codefirst.iut.uca.fr/swagger?url=/documentation/mchSamples_.NET/swagger/TP_MVVM_2024_BackEnd/swagger.json#/default).
## Personnes utilisables
Comme on simule l'annuaire de l'établissement, il n'est pas possible d'ajouter de personnes. Vous pourrez pour vos opérations, utiliser les personnes suivantes :
- **Odin** (```ADMIN```) : odin@uca.fr, mot de passe : Pw1234$
- **Cédric Bouhours** (```STAFF```) : cedric.bouhours@uca.fr, mot de passe : Pw1234$
- **Christelle Mottet** (```STAFF```) : christelle.mottet@uca.fr, mot de passe : Pw1234$
- **Marc Chevaldonné** (```STAFF```) : marc.chevaldonne@uca.fr, mot de passe : Pw1234$
- **Alia Atréides** (```STUDENT```) : alia.atreides@uca.fr, mot de passe : Pw1234$
- **Miles Teg** (```STUDENT```) : miles.teg@uca.fr, mot de passe : Pw1234$
- **Duncan Idaho** (```STUDENT```) : duncan.idaho@uca.fr, mot de passe : Pw1234$
## Conseils
Lors du démarrage de la partie 2, je vous conseille de réaliser les tâches dans cet ordre :
- bibliothèque ```Model``` avec les classes ```Person``` et ```Equipment```
- bibliothèque ```Shared``` avec la couche abstraite de service (permettant de se logger, de se dé-logger et de récupérer la liste d'équipements)
- ajout du ```Manager``` dans le modèle avec injection du service abstrait
- Stub rapide pour vérification et tests
- VM (```ManagerVM``` et ```EquipmentVM```) afin de pouvoir se logger, et afficher la liste des équipements
- DataBinding sur les vues correspondantes
Puis dans un second temps :
- client de la web api
- injection de ce dernier et utilisation
A part, la navigation et l'édition/ajout/suppression, le respect de ces tâches vous permettra d'avoir une bonne vue d'ensemble de l'architecture et de gagner en autonomie pour la suite.
