Projet CANAL LECTURE - Analyse globale

Canal Lecture ou autre chose on verra.
Auteur : (http://)

Introduction

L'idée de départ est de séparer le canal "Annonces" en deux :

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) :

Spécifications générales


Définitions


Voici les différents objets manipulés par le canal lecture :

Description des objets manipulés


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.

Une source


Elle se caractérise par :

Un profil de Source


Le profil d'une source XML personnelle se définit par :

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 :

Les autres caractéristiques y sont indiquées ou prise en compte facultativement (cf. chapitre "origine des données") :

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")

L'élément <source-profile> est défini dans la dtd de la category (category.dtd).

Une catégorie

Elle se caractérise par :

Une catégorie peut être personnelle ou contrôlée :

Une catégorie contrôlée a des caractéristiques supplémentaires :

  1. L'élément <Category> est défini dans la dtd de la category (category.dtd)

Un profil de catégorie

  1. Pour une catégorie personnelle, il n'y a rien à préciser : le profil est vide.
  2. 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 :
  1. L'élément <categoryProfile> est défini dans la dtd de la configuration du canal (esup-lecture.dtd)

Un contexte

On définit un context au niveau de la config du canal. Il doit contenir :

L'accessibilité et les ensembles de visibilité du contexte 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).

Origine des données : récapitulatif


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

Le fichier de conguration du canal pourrait être de la forme :

<chanelConfig mappingFile=.../mon_fichier>
  <context ...> ... </context>
  <context ...> ... </context>
  ...
  <categoryProfile ...> ... </categoryProfile>
  <categoryProfile ...> ... </categoryProfile>
  ...
<canal>


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

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)

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

Gestion de la dynamique des données


Informations supplémentaires


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

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

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

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

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.

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

    Spécifications détaillées


Les acteurs


Les cas d'utilisation


Voici l'énumération des cas d'utilisations concernant les catégories : * créer_catégorie

Voici l'énumération des cas d'utilisations concernant les sources : * creer_source

Concernant le contexte :

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 :


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

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