{panel:bgColor=#F8F7EF}
h1. Projet CANAL LECTURE - Analyse globale
*Canal Lecture ou autre chose on verra.*
\\
Auteur : ([|http://])
{panel}
{toc:style=disc\|indent=20px\|minLevel=1}Introduction
L'idée de départ est de séparer le canal "Annonces" en deux :
* gestion de la saisie des annonces : le canal annonce
* gestion de la consultation pour diverses sources d'information en format XML : le canal lecture. Voici des exemples de ce qu'il permet de consulter :
** annonces du portail
** annonces CMS
** flux RSS externes
** site web de formation (concept site d'appui)
** signets de groupes
Le canal lecture permettra d'afficher des annonces classées par thème eux mêmes situés dans des catégories. On envisage de généraliser ce système à l'affichage de sources d'informations au format XML. Voici la correspondance des termes utilisés (Généralité \--> exemple des annonces) :
* Catégorie \--> catégorie
* Thème d'annonce \--> source XML
* annonce \--> item
{note}
{note}
h1. Spécifications générales
\\
h2. Définitions
\\
Voici les différents objets manipulés par le canal lecture :
* _un item_ : c'est une unité d'information indépendante "autonome" diffusée sous la forme d'un élément XML de format libre.
exemple : une annonce de l'université, un item RSS
* _un flux XML_ : c'est un ensemble d'items destinés à être affiché par le Canal Lecture par le biais d'une feuille xslt.
exemple de flux XML utilisés : un flux RSS externe, un flux RSS généré par un CMS d'un site web de formation
* _une source XML_ : c'est l'élément définissant les informations nécessaires à l'obtention et l'affichage d'un _flux XML_.
exemple : un thème d'annonce du canal "saisie d'annonce"
* _un profil de source_ : il définit les caractéristiques d'une source (localisation, droits d'accès,...).
* _une catégorie_ : C'est l'élément englobant d'un ensemble de _profils de sources_.
exemple : "les annonces de l'université", site d'appui
* _un profil de catégorie_ : il définit les caractéristiques d'une _catégorie_ (localisation, droits d'accès,...).
* un _contexte_ : c'est l'élément englobant d'un ensemble de _profils de catégories_. Cette notion est utilisée pour l'interface graphique. Un _context_ est lié à un fragment du portail : lors de la configuration du canal dans le portail, on instanciera un canal Lecture à un fragment donné, avec le contexte fourni en paramètre.
* la visibilité d'un élément (une catégorie ou une source) : pour un utilisateur, c'est le droit de visibilité sur l'élément.
* la disponibilité d'un élément : pour les éléments visibles d'un utilisateur, la disponibilité d'un élément est de savoir si l'utilisateur accède à l'affichage de cet élément et pour quelle raison (il y est abonné ou non, de façon obligatoire ou il en est le propriétaire)
h2. Description des objets manipulés
\\
h3. Un item
\\
Un _item_ n'a pas de contrainte de caractéristique. "item" est un nom générique pour un élément XML. Le nom de cet élément XML n'est pas connu à priori. Seule la _feuille XSLT_ (relative à _l'item_) connait ses spécificités. Si on veut effectuer un zoom sur un _item_, celui-ci devra contenir un lien vers une URL générant le zoom.
h3. Une source
\\
Elle se caractérise par : * un _flux XML_ contenant un ensemble d'_item_s. L'affichage des items se fait grâce à une feuille XSLT conforme au format de l'item. Le repérage de l'item se fait grâce à la définition xpath de l'item.
* les items d'une source sont marqués "lus" ou "non lus"
une _source_ qui peut être _personnelle_ ou _contrôlée_ :
* _une source personnelle_ : la _source XML_ provient de la personnalisation du canal lecture par la saisie libre de l'utilisateur.
* _une source contrôlée_ : la _source XML_ provient de l'ensemble des _sources_ rendues disponibles par l'administrateur du canal. Une _source contrôlée_ a des caractéristiques supplémentaires.
h3. Un profil de Source
\\
# Le profil d'une _source XML personnelle_ se définit par :
* la saisie IHM de l'URL du flux XML
* l'adresse générant le flux
* la recherche automatique de :
** la feuille XSLT
** _l'xpath de l'item
grâce à un \_fichier de mapping
DTD-XSLT_\-_path_ présent au niveau de la config du canal.
# Le _profil d'une_\_source XML
contrôlée_, est récupéré dans le fichier XML de sa _catégorie_ d'appartenance (cf. catégorie) qui fournit : \*\* le _nom_ de la _source_\#\* l' _URL du flux XML_ : (exemple : url d'un thème d'annonce du portail, url d'un CMS ). Cette URL peut être exprimée à l'aide de variables pour permettre l'utilisation d'URL spécifiques à un utilisateur.
Exemple : {ur1Composante}" rel="nofollow"linktype="raw" linktext="http://cms.univ-rennes1.fr/RSS/
{ur1Composante}">[http://cms.univ-rennes1.fr/RSS/]
{ur1Composante}La variable peut être multivaluée et représente ainsi plusieurs URL, d'où la définition simultanée de plusieurs _sources XML_.
Exemple : {ur1Etape}" rel="nofollow"linktype="raw" linktext="http://cms.univ-rennes1.fr/RSS/
{ur1Etape}">[http://cms.univ-rennes1.fr/RSS/]
{ur1Etape}. Pour un étudiant inscrit à plusieurs étapes, on aura plusieurs URL.
** le _contenu individualisé_ : oui ou non - Dans la mesure où la requète est authentifié, le flux XML généré est-il spécifique de l'utilisateur ? Cette information va être utile pour l'optimisation des performances.
** les autres caractéristiques y sont indiquées ou prise en compte facultaivement (cf. chapitre "origine des données") : \**\* l'URL de la \_feuille XSLTet l'xpath. Si
\_l'URL de la \_feuille
XSLT\_ et _l'xpath_ de l'item ne sont pas indiqués, on utilise le _fichier de mapping DTD-XLST-xpath_ présent au niveau de la config du canal.
*** _l'accessibilité_ : _publique_ ou _authentifié_ \- ouverte à tous ou restreinte via une authentification (ex : CAS).
*** les _ensembles de visibilité_ : les ensembles désignés ci-dessous constituent l'ensemble des personnes ayant une visibilité sur la _source XML_ : \**\* _libres_ : un utilisateur de cet ensemble a le droit de s'abonner et de se désabonner de la _source_.
*** _préabonnés_ : en plus du droit d'abonnement et désabonnement, un utilisateur de cet ensemble est abonné automatiquement à la _source_.
*** _forcés_ : un utilisateur de cet ensemble est automatiquement abonné à la _source_ et ne peut pas se désabonner.
Le contenu de ces ensembles peut être défini par l'énumération de groupes existants et/ou par l'énoncé d'une règle d'appartenance, exemple :
_libres_ =
{groupe Portail "Personnels du CRI"}union
{les personnes telles que "EmployeeType"="student"}\\
*** le _timeout_ : c'est le temps maximum d'attente pour l'obtention d'un flux XML.
# L'élément <source-profile> est défini dans la dtd de la category (category.dtd).h3. Une catégorie
\\
# Elle se caractérise par : \*\* un nom
#* une description
#* un ensemble de profils de source\_ XML
_
#* une catégorie peut être _personnelle_ ou _contrôlée_ : \**\* une _catégorie personnelle_ : elle est crée par l'utilisateur dans la personnalisation du canal lecture
#** une _catégorie contrôlée_ : elle provient des \_catégorie_s rendues disponibles par l'administrateur du canal.
Une _catégorie contrôlée_ à des caractéristiques supplémentaires : \**\* _l'éditabilité_ : _modifiable_ ou _figée_ : (facultatif : cf. chapitre "origine des données") possibilité pour l'utilisateur d'y ajouter des \_sources XML
(cf. spécifications générales - mise en forme
détaillée des besoins)\_
#** les \_ensembles de
visibilité\_ : (facultatif : cf. chapitre "origine des données") les ensembles désignés ci-dessous constituent l'ensemble des personnes ayant une visibilité sur la _catégorie_ : \**\* _libres_ : un utilisateur de cet ensemble a le droit de s'abonner et de se désabonner de la _catégorie_
#** _préabonnés_ : en plus du droit d'abonnement et de désabonnement, un utilisateur de cet ensemble est automatiquement abonné à la _catégorie_
#** _forcés_ : un utilisateur de cet ensemble est automatiquement abonné à la _catégorie_ et ne peut pas se désabonner
# L'élément <Category> est défini dans la dtd de la category (category.dtd).h3. Un profil de catégorie
\\
# Pour une _catégorie personnelle_, il n'y a rien à préciser : le profil est vide. # Pour une _catégorie contrôlée_, on définit son _profil_ au niveau de la config du canal. Le _profil d'une catégorie_ doit contenir : \*\* le _nom_ de la _catégorie_\#\* l'URL du fichier XML de la catégorie (avec possibilité de variables)
#* \_l'accessibilité _
#* le _trust-category_ (faire confiance à la catégorie) qui définit pour les caractéristiques suivantes quelle est la priorité des définitions (cf. chapitre "origine des données") : si _trust-catégory_ est à "vrai", les valeurs définies par la _catégorie_ sont prioritaires mais facultatives, celles définies par le _profil_ sont les valeurs par défaut. Si _trust-catégory_ est à "faux", seules les valeurs définies par le _profil_ sont prises en compte.
#* le _ttl_ : temps de rafraichissement d'une donnée distante
#* les caractéristiques liées à _trust-category_ : **\** *{_}l'éditabilité{_}{*}*\#*\* \_les ensembles de
visibilité\_
#** le _timeout_
# L'élément <categoryPdérofile> est défini dans la dtd de la configuration du canal (esup-lecture.dtd)h3. Un contexte
\\
On définit un context au niveau de la config du canal. Il doit contenir : * le _nom_ du contexte
* une _description_ du contexte
* un ensemble de références sur des profils de catégories définis dans le même canal.
* _l'éditabilité_ du contexte (création/suppression, abonnement/désabonnement de catégories )
L'accessibilité et les ensembles de visibilité du context sont gérés au niveau portail : par le biais du fragment associé au contexte.
L'élément contexte est défini dans la dtd de la configuration du canal (esup-lecture.dtd).
h2. Origine des données : récapitulatif
\\
# Voici un schéma récapitulatif sur les données manipulées : !donnees.gif!tab.1 : Manipulation des données par le canal et le serveur distant # Voici trois tableaux récapitulant la récupération des informations pour les profils de sources XML et de catégories :tab.1 : Origine des données concernant les catégories!tab_categorie.gif!tab. 2 : Origine des données concernant les sources XML!tab_source.gif!tab. 3 : <img class="emoticon" src="/images/icons/emoticons/star_yellow.gif" height=32"16" width=32"16" align="absmiddle" alt="" border="0"/> Priorité sur la définition des paramètres liés à <trust-category>!trust-cat.gif! \# Evaluation des ensembles de visibilté : une personne peut apparaître dans deux ensembles de visibilité simultanément. Afin de respecter les priorités, il faut évaluer le contenu des ensembles dans l'ordre suivant : forcés, préabonnés, libres. # La configuration du canal doit contenir les informations suivantes : \*\* la définition des profils de _catégories_ (contrôlée).
#* la définition des contextes
Le fichier de conguration du canal pourrait être de la forme :
{code}<chanelConfig mappingFile=.../mon_fichier>
<context ...> ... </context>
<context ...> ... </context>
...
<categoryProfile ...> ... </categoryProfile>
<categoryProfile ...> ... </categoryProfile>
...
<canal>
{code}\\
h2. Personalisations de l'utilisateur
\\
Tout ce qui est propre à un utilisateur, concernant les catégories et les sources sera enregistré dans le profil de l'utilisateur. Le profil utilisateur contient : * L'état de visualisation des sources et catégories : pliées/selectionnée ou non
* Le marquage d'un item lu ou non lu. Le marquage d'une source ayant des items non lus. Le marquage d'une catégorie ayant de items non lus
* L'ordre de visualisation des sources dans la catégorie, des catégories dans le contexte
* Le mode de visualisation des items
* Le zoom sur la source
* La dimension de la fenêtre de l'arborescence
* Les sources et catégories personnelles, les abonnements aux sources et catégories contrôlées, les importations de sources et catégories controlées
Concernant l'éditabilité des contextes et catégories, le droit d'y créer ses propres catégories ou sources, le droit d'y ajouter des catégories ou sources controllées existantes, rend le système assez complexe. Voici un shéma regroupant toutes les possibilités et les cas que nous avons retenus :
\!contexte-cat-sources.gif\!Différents cas possibles de personnalisation d'un contexteLégende : * 1 : Deux possibilités : \**\* action = s'abonner à une catégorie controlée (aucune condition)
*** action = importer une catégorie controlée (condition : context.edit = managed \| all)
Un contexte peut être vide : il ne peut être relié à aucune catégorie contrôlée. Ainsi cela fournit un contexte entièrement personnalisable pour l'utilisateur du canal.
* 2 : personnalisation
action = créer ou ajouter (si déjà existante) une catégorie personnelle ( si context.edit = personal \| all )
* 3 : s'abonner ou importer une catégorie controlée : cf. 7 ou 8
Une catégorie contrôlée peut elle n'avoir aucune source contrôlée : peut elle être vide ? Oui ? Pour plus de souplesse (ou robustesse) vis à vis du serveur distant qui fournit les catégorie ?
* 4 : personalisation
cf.9 (si categorie : edit = all \| personal)
* 5 : cas usuel : créer ou ajouter (si déjà existante) une source personnelle dans une catégorie personnelle (pas de condition)
action = cf. 9
* 6 : importer une source contrôlée (rendue disponible par le canal) (pas de condition) + cf.10
* 7 : Cas usuel
action = s'abonner à une source contrôlée de la catégorie courante (aucune condition)
* 8 : personnalisation
action = importer source contrôlée (hors catégorie courante) (si categorie.edit = managed \| all )
* 9 : personnalisation
action = créer ou ajouter (si déjà existante) une source personnelle
une source personnelle est indépendante d'un contexte. Elle peut existé même si elle n'apparaît dans aucun contexte
* 10 : on choisit de pouvoir importer une source contrôlée qu'elle soit ou non définie (via une catégorie contrôlée du contexte) dans le contexte courant : on rend disponible les sources controlées définies dans des catégories controlées non disponibles dans le contexte courant.
action = s'abonner à une source contrôlée (rendue disponible par le canal) (si contexte : "edit" = "all")
* 11 : Concernant les sources contrôlées n'appartenant pas à la catégorie contrôlée courante, comme en 10, elles peuvent provenir de différents contextes.
* 12 : Toutes les sources contrôlées rendues disponibles doivent obligatoriement être rattachées à un contexte. On peut imaginer créer un contexte proposant diverses catégories contrôlées, mais qui ne serait pas présenté dans le canal. Ce contexte servirait de "réservoir" à catégories contrôlées pour les personnalisations.
Modification de la caractéristique \_edit \_: * niveau contexte : Edit =nopersonalmanagedallcomportement du contexteContexte non éditable * abonnement/désabonnement possible de cat. contrôlée du contexte courant
* pas d'ajout/création de catégorie personnelle
* pas d'importation de catégories controlées
Contexte éditable : * abonnement/désabonnement possible de cat. contrôlée du contexte courant
* ajout/création possible de catégorie personnelle
* pas d'importation de catégories controlées
Contexte éditable : * abonnement/désabonnement possible de cat. contrôlée du contexte courant
* pas d'ajout/création de catégorie personnelle
* importation possible de catégories controlées
Contexte éditable : * abonnement/désabonnement possible de cat. contrôlée du contexte courant
* ajout/création possible de catégorie personnelle
* importation possible de catégories controlées
* niveau catégorie controlée:Edit =nopersonalmanagedallcomportement d'une catégorie contrôléeCatégorie non éditable : * abonnement/désabonnement possible de sources contrôlées de la cat. courante
* pas d'ajout/création de sources personnelle
* pas d'importation de sources controlées
Catégorie éditable :
* abonnement/désabonnement possible de sources contrôlées de la cat. courante
* d'ajout/création possible de sources personnelle
* pas d'importation de sources controlées
Catégorie éditable :
* abonnement/désabonnement possible de sources contrôlées de la cat. courante
* pas d'ajout/création de sources personnelle
* importation possible de sources controlées
Catégorie éditable :
* abonnement/désabonnement possible de sources contrôlées de la cat. courante
* ajout/création possible de sources personnelles
* importation possible de sources controlées
* niveau catégorie personnelle : on peut toujours créer/ajouter des sources personnelles et importer des sources controlées : pas de type edit.
h2. Gestion de la dynamique des données
\\
* Rafraichissement des profils de \_sources
XML\_ = rafraichir les catégories
Catégorie contrôllée : à chaque affichage de catégorie, si le ttl de la _catégorie_ est dépassé, les profils de sources XML sont rafraichies.
Catégorie personnelle : à chaque session utilisateur, tous les profils de sources (personnels et controllés) sont rafraîchis
(Plus un bouton Refresh pour l'utilisateur ? )
* Rafraichissement d'un _flux XML_ (d'une _source XML_) = rafraichir les sources
source contrôllée : à chaque affichage de la source, si le _ttl_ de la source est dépassé, la source est rafraichie.
source personnelle : à chaque session utilisateur, la source est rafraîchie
(Plus un bouton Refresh pour l'utilisateur ?)
* Rafraichissement des contexts et profils de catégories : lecture du fichier de configuration du canal. Il est lu à chaque démarrage du canal. Puis lors de l'ouverture de chaque session utilisateur, on vérifie la date de dernière modification de la config et on recharge si besoin.
* la gestion de cache sera précisée plus tard.
* Tout ce qui est commun à plusieurs utilisateurs (catégories et sources controllées) sera enregistré dans un cache global. Les profils utilisateurs auront des pointeurs vers le cache global.
h2. Informations supplémentaires
\\
# La conception du canal inclura l'internationnalisation # Toutes les URL mises à disposition par le Canal Annonce sont cassifiées. Le canal Lecture sera donc proxy CAS. # La BDD du canal Lecture ne contient aucun contenu de source. # Interface graphique
A un fragment ou canal sera associé un contexte qui proposera des catégories. Après sélection d'une catégorie, on accède à un ensemble de _sources_. Par défaut, les sources seront dépliées.
Le canal lecture pourrait être un canal transversal : sous un fragment donné, on pourrait avoir un contexte dans lequel une seule (ou plusieurs) _catégorie_ est disponible, dans un autre fragment, on aurait aussi le canal lecture seul mais avec un autre contexte proposant d'autres (ou pas) _catégories_ (utilisable pour les souscription forcées à des thèmes d'annonces par exemple).
L' affichage d'image, le téléchargement de fichiers en lien avec une annonce est géré par le zoom sur un _item_.
Pour consulter les informations diffusées par le canal lecture, l'utilisateur dispose de deux modes (on utilisera les 2 modes des portlets) : \*\* mode _view_ : \**\* Plier ou non les sources et catégories
#* \#*\* Marquer un item lu ou non lu.
#** Choisir le mode de visualisation des items
#** Zoomer sur la source
** mode _edit_ : **\* gestion de la pagination : ordonner les* *{_}sources{_}* *et les* *{_}catégories{_}*\*\* Les sources et catégories personnelles, les abonnements aux sources et catégories contrôlées, les importations de sources et catégories controlées
h2. Interaction du canal avec le système
\\
\!global.gif\!Fonctionnement du canal lecture en interaction avec le système
(Le schéma ci-dessus n'intègre pas la notion de _catégorie_ pour simplifier la représentation.)
# Modèle producteur/consommateur
Le canal de saisie d'annonce et le canal lecture sont dissociés l'un de l'autre et utilisent des bases de données séparées. Ils fonctionnent ensemble sur un modèle de producteur/consommateur.
Problématique conception "producteur-consommateur" / performances (contexte : producteur = canal Annonce, consommateur = canal lecture) : cf. échange de mails.
# Pré-requis attendus pour le canal de saisie des annonces
Le nouveau canal de saisie des annonces devrait être en mesure de mettre à disposition les données suivantes (via des URL): \*\* des _catégorie_s (contenant des profils de_ sources_) : <category>...</category>
#* le flux XML d'une _source_ (ex : un thème d'annonce avec ses annonces au format RSS ou autre XML)
#* le zoom d'un _item_
Chaque _item_ fourni dans un flux XML d'une _source_, devra contenir un lien pointant vers l'URL du zoom de l'_item_.
Pour pouvoir accéder à la _feuille XSLT_, le serveur de _flux XML_ devrait fournir l'un des éléments suivants : \*\* l'URL pointant vers la feuille XSLT (défini dans le profil de la _source_) et la définition xpath de l'item
** ou indiquer la DTD du flux XML
Cette dernière possibilité semble préférable car elle laisse la main au canal Lecture pour le style de l'affichage.
Le canal Annonce ordonne les items d'une source dans le flux XML. Il propose aussi un ordre par défaut pour les sources.
Toutes les URL mises à disposition par le nouveau canal Annonce devraient être cassifiées.
Ergonomie pour le publicateur : la saisie des annonces et la consultation deviennent séparées, il faut malgré tout permettre au rédacteur un moyen de passer aisément de la vue rédacteur à la vue utilisateur : le nouceau canal Annonce pourrait appeler l'URL générant le zoom d'un _item_.
# De la même manière, le canal Signet pourrait aussi exporter un ensemble de signets sous forme de \_source
XML_. # Site d'appui
Dans le contexte du canal lecture, la notion de site d'appui s'implémente par l'abonnement obligatoire à toutes les _sources_ concernées par la formation (ou plusieurs) de l'utilisateur.
Via les attributs de l'ENT, on pourrait obtenir les étapes APOGEE sur lesquelles l'étudiant est inscrit afin de composer les URL des sites web de(s) la (les) formation(s).
(cf spécif romuald)
h1. Spécifications détaillées
\\
h2. Les acteurs
\\
* Utilisateur du canal (utilisateur)
* le portail (portail)
* l'administrateur du canal (admin)
h2. Les cas d'utilisation
\\
Voici l'énumération des cas d'utilisations concernant les catégories : * créer_catégorie
* ajouter_categorie
* supprimer_categorie
* modifier_vue_categorie \**\* choisir_mode_visu_categorie
*** deplacer_source
* éditer_catégorie
* abonner_categorie
* importer_categorie
* desabonner_categorie
* enlever_categorie
* afficher_categorie
* deplier_categorie
* replier_categorie
* rafraichir_categorie
* rafraichir_toutes_categories
Voici l'énumération des cas d'utilisations concernant les sources : * creer_source
* ajouter_source
* supprimer_source
* modifier_vue_source \**\* choisir_mode_visu_source
*** marquer_item_lu/non_lu
*** zoomer/dezoomer_source
* editer_source
* abonner_source
* importer_source
* desabonner_source
* enlever_source
* afficher_source
* rafraichir_source
* deplier_source
* replier_source
* recherche_xslt
Concernant le contexte :
* afficher_contexte
* editer_contexte (ajout/création/suppression de catégories)
* modifier_vue_contexte \*\* deplacer_categorie
* rafraichir_contexte
Autres : * dimensionner_arbre
* authentification
* recuperer_pt_cas
* rafraichir_config_canal
C'est une première énumération des cas d'utilisation apparu nécessaire. Ils seront complétés, modifiés ...lors de la spécification générale.
Concernant les cas d'utilisations dont la mise en oeuvre est manuelle, voici :
* Définir un profil de catégorie contrôlée dans un contexte(<profil-catgory>) par l'édition de la config du canal
* Modifier le profil d'une catégorie contrôlée : édition de la config du canal
* Supprimer un profil de catégorie contrôlée : édition de la config du canal
* Définir un contexte : édition de la config du canal
* Supprimer un contexte : édition de la config du canal
* Ordonner un contexte : édition de la config du canal (l'ordre des catégories est l'ordre de définition dans la config)
h2. Diagrammes uses-cases
\\
Les diagrammes suivants contiennent la description des uses cases ainsi que les relations entre eux : * actions relatives au contexte : uses cases du fichier docs/specifications/uses-cases/uses-cases-context/index.html
* actions relatives aux catégories : uses cases du fichier docs/specifications/uses-cases/uses-cases-category/index.html
* actions relatives aux sources : uses cases du fichier docs/specifications/uses-cases/uses-cases-source/index.html
* tous les enchainements relatifs à la mise à jour des données : uses cases du fichier docs/specifications/uses-cases/uses-cases-rafraichir/index.html
Voici quelques précisions : * Action globale : le contexte du canal est en mémoire ainsi que les profils des catégories.
* Action utilisateur : le profil de l'utilisateur vient s'ajouter au contexte du canal et aux profils de catégories.
* Une catégorie contrôllée définie dans un profil utilisateur implique la définition de son profil dans le contexte du canal. Une source contrôllée définie dans un profil utilisateur implique la définition de son profil dans une catégorie contrôllée elle même définie dans le contexte du canal.
h2. Diagrammes de classe
\\
Il faut se référer aux diagrammes UML de conception/développement, présents dans le répertoire \_docs/uml/classes du
projet.\_ |