Last modified 4 years ago Last modified on 03/20/13 17:16:40

Organisation du projet COMETE

Cette section présente une vue d'ensemble de l'architecture du projet COMETE.

Si vous prenez contact avec le projet pour la première fois, nous vous suggérons de commencer par vous familiariser avec les raisons d'être du projet COMETE, et ce qu'il est et n'est pas.

Implantation actuelle

Le schéma ci-après donne un aperçu de l'implantation actuelle du projet COMETE, avec les modules partiellement ou complètement achevés.

Organisation des modules et leurs interactions

Le diagramme suivant illustre l'architecture visée au terme du projet et montre de façon plus détaillée, les interactions entre les différents modules informatiques.

GraphViz image
Module de COMETE
Un module de code, généralement implanté en Java sous la forme de services web, faisant partie de l'architecture de COMETE (qu'il ait ou non été écrit par COMETE). Une installation du système déploie normalement la majorité de ces modules. Vous pouvez cliquer sur chaque module pour obtenir directement sa description. Pour connaître son état d'avancement et le code sur lequel il est basé, consultez le tableau des modules que vous trouverez plus bas. La couleur de fond dénote l'état du module:
  • Rouge: Aucun code existant
  • Jaune: Module basé sur du code existant nécessitant des modifications importantes, ou module en cours d'implantation
  • Vert: Module externe ne nécessitant pas de travaux majeurs, ou module essentiellement complété.
Liens hachurés avec flèche pleine
Indique que le module interagit avec un autre à l'aide d'un protocole bien défini, qui communique avec les autres à l'aide d'un protocole précis indiqué sur l'étiquette du lien. Si vous cliquez sur l'étiquette, vous obtiendrez la description du protocole dans la liste des protocoles définis ou utilisés par COMETE. La flèche est importante : elle indique la direction du flux de contrôle, c'est à dire que le module au départ du lien pilote l'interaction avec le module au point d'arrivée du lien.
Liens en gras avec flèche vide
Indique qu'un module est soit une spécialisation du module pointé par le lien (héritage au sens orienté-objet du terme), ou que le module est un sous-module du module pointé par le lien (composition). Dans les deux cas, on s'attend généralement à ce que les codes des deux modules soient liés directement au niveau du code. Il est à noter que le fait qu'il n'y ait pas de sous-module d'illustré dans le diagramme ne signifie pas que le module n'est pas composé de sous-modules, mais simplement que ceux-ci n'ont pas d'interaction importante avec les autres modules ou l'extérieur.
Data Storage System
Un logiciel chargé du stockage persistant des données, normalement une base de données ou un ECMS (Enterprise Content Management System).
External system
Un système accessible par Internet, avec lequel COMETE a à interagir, mais qui n'est pas sous le contrôle de l'organisation qui déploie COMETE.

Il est à noter qu'en plus des APIs illustrés plus haut pour communiquer entre les modules de l'architecture, COMETE utilise un grand nombre de formats et de standards pour communiquer avec l'extérieur, ou dans l'implantation interne d'un module. Vous trouverez la description de ces standards et les hyperliens vers leur documentation sur la page Standards, protocoles et formats applicables au projet COMETE

Interactions

Les seuls modules où débute normalement une interaction dans le système sont les suivants :

  • Portal, WorkFlow, LinkedData (Interactions initiées par l'usager)
  • Harvester (Interactions initiées par l'horloge du système)
  • QueryEngine, SQIService, SRUService, OAI_PMHService (Interactions initiées par un dépôt ou système informatique extérieur)

Interaction avec l'usager

Les seuls modules qui interagissent normalement directement avec l'usager avec une interface usager complète sont les modules Portal, WorkFlow?, LinkedData?, SearchUI et HierearchicalNavigationUI.

Un exemple typique d'interaction avec l'utilisateur final est une recherche:

  1. L'usager arrive sur le site de Comète (module Portal), qui demande à !SearchUI de lui fournir l'interface de recherche.
  2. L'usager fournit ses paramètres de recherche, dont le formulaire est transmis à !SearchUI. On peut ensuite suivre le flux de contrôle avec les flèches pleines sur le graphique: !SearchUI => QueryEngine => TripleStoreService => TripleStore, puis la réponse reviendra par le même chemin.

Dans cet exemple, l'usager n'a interagi directement qu'avec les modules Portal et SearchUI.

Un second exemple est l'édition d'une fiche dans un Workflow, qui donnera lieu à la séquence:

  1. WorkFlow => FedoraRepository (demander, puis obtenir les métadonnées)
  2. WorkFlow => MetadataEditor (envoyer les métadonnées et le profil d'application à l'éditeur et présenter l'éditeur à l'usager, puis recevoir les métadonnées modifiées en retour)
  3. WorkFlow => MetadataValidator (envoyer les métadonnées et le profil d'application au validateur, puis recevoir un rapport de validité)
  4. WorkFlow => FedoraRepository (écrire les métadonnées)

Dans cet exemple, l'usager n'a interagi directement qu'avec les modules WorkFlow et MetadataEditor.

Interaction entre les modules

L'un des objectifs architecturaux principaux est d'éviter de coupler étroitement les modules et de s'assurer que les modules n'aient pas à mémoriser l'état d'autres modules. Il est donc très important que les flèches hachurées dans le diagramme précédent soient respectées (ou mises à jour) lors du développement de l'échange d'information entre les modules, afin d'éviter de complexifier l'architecture.

À titre d'illustration, dans la suite du scénario décrit précédemment (recherche), l'usager consulte la fiche de métadonnées de l'un des résultats de recherche. Nous voulons y afficher des informations concernant le dépôt duquel la fiche a été moissonnée. Cette information (le dépôt d'origine) se trouve dans le métamodèle pour la fiche, mais on veut ajouter les détails du dépôt, qui se trouvent dans le module RepositoryRegistry:

  • Nous voulons probablement que cette information soit incluse dans la fiche HTML par le module Metadata lors de la transformation métamodèle->HTML, en demandant au module RepositoryRegistry le document LODE correspondant à l'identifiant du dépôt d'origine.
  • Nous ne voulons pas que cette information soit obtenue directement du TripleStore par le module Portal.

Tableau des modules

Le tableau suivant présente la liste des modules de l'architecture de Comète, avec leur état de développement.

Module Implemented API Implementation Status Codebase
User interface entry point modules
Portal None In progress New code based on EXTJS
LinkedData LinkedData Nearly complete New codebase
Workflow None Not yet started ORI Workflow, itself based on OSWorkflow
Metadata management modules for the resource's metadata whose management is the primary purpose of the project (Learning Objects, theses and pedagogical scenarios represented in applicable metadata standards)
FedoraRepository RISearch External codebase The Fedora Commons Repository software
ApplicationProfile AppProfile Not yet started New codebase
MetadataEditor MetadataEditor Implementation started http://www.ori-oai.org/display/ORIOAImdeditor/ ORIOAImdeditor], itself based on Orbeon
MetadataGroupEditor MetadataEditor Not yet started New codebase
MetadataValidator AVS-REST Not yet started Probably a highly modified Ariadne Validation Framework
Metadata Metadata In progress New code
Metadata management modules for metadata related to, but not directly included in the resources Metadata
Vocabulary Vocabulary In progress New codebase
VocabularyEditor Depends on the editor choice Not yet started External, probably G-MOT
Identity Identity In progress Mostly new code, but reusing external libraries for reading the actual file formats.
IdentityEditor Depends on the editor choice Not yet started Probably Orbeon
Search, navigation and collection management modules
QueryEngine OpenSearch In progress New code
HierarchicalNavigationUI None Nearly complete New code
SearchUI None In progress ORI-OAI Search
Inter-repository communication: Harvesting modules
Harvester Harvester In progress ori-oai-harvest
OAI_PMHClient None Nearly complete ori-oai-harvest
HTMLSpider None Nearly complete New code based on Eureka's implementation
SRUClient None Not yet started To be determined
RegistryManager Registry Nearly complete PALOMA
RepositoryRegistry Registry, IMS LODE Registry Nearly complete ARIADNE Registry
Inter-repository communication: Publishing modules
SQIService SQI Not yet started http://helios.licef.ca/PalomaSuite/fr/ PALOMA]
SRUIService SRU Not yet started To be determined
OAI_PMHService OAI-PMH Nearly complete Fedora OAI Provider Service, itself based on PROAI
Data persistence modules
TripleStore SPARQL Endpoint External codebase Mulgara

Chaque colonne contient l'information suivante:

  • Module: Nom du module, avec un hyperlien vers la page du module. Celle-ci commence avec une courte description de la fonction du module.
  • Implemented API (as a service): Le module implante un API en tant que service, un hyperlien vers la description de cet API.
  • Implementation Status: Indique où en est le module dans son cycle d'implantation. Typiquement: Not started, Implementation started, In progress, Nearly complete
  • Codebase: Si le module est basé sur une base de code externe, quelle est-elle?

Modélisation de l'information gérée par le logiciel

Deux concepts importants touchent presque l'ensemble des modules et nécessitent leur propre page dans le wiki.

Le premier concept est Méta-modèle. Son importance découle du fait que l'un des objectifs fondamentaux du projet est de fournir une base solide à l'exploitation de multiples standards, actuels ou à venir, de métadonnées décrivant des ressources d'intérêt pour les institutions d'enseignement.

L'exploitation de la sémantique des métadonnées d'une façon indépendante de leur format d'arrivée, et tout en ne se limitant pas à une approche du plus petit dénominateur commun, exige le développement d'un méta-modèle très particulier pour représenter ce réseau d'information. C'est donc, tout autant que le code, à cet endroit que se déroule une bonne partie du développement du projet COMETE.

Le second concept est la gestion des collections de ressources. Celle-ci touche directement plusieurs modules, tout particulièrement les modules Vocabulary, QueryEngine et HierarchicalNavigationUI.

Organisation des spécifications et du travail

Les requis du projet sont exprimés sous la forme de User Story. Les User Stories se trouvent dans le Product Backlog (toujours accessible dans le menu de gauche. Il s'agit d'une liste d'énoncés dont l'ordre représente les priorités du projet. Pour bien les comprendre, il est important de lire d'abord la page Comment écrire et prioriser les User Stories du projet.

Chaque User Story est ensuite découpé en tâches (accessibles depuis le User Story), au moment où l'on décide d'y travailler. Les détails de la tâche à accomplir sont inscrits dans la description de la tâche, s'ils n'ont pas de pertinence une fois la tâche complétée, ou dans les spécifications du module ou de l'API approprié si ces informations ont une vie utile plus longue. Pour travailler sur les interfaces usager, voir la liste des futures interfaces usager, contenant des exemples des interfaces des projets existants.

Vu l'envergure très large du projet qui ne permet pas de découper les User Stories suffisamment finement pour être entièrement implantées les unes après les autres, un plan de travail a été établi pour les développeurs de la TELUQ. Celui-ci comporte une liste de tâches relativement petites représentant l'implantation généralement partielle d'une ou plusieurs User Stories. Elles sont triées selon l'ordre prévu de leur démarrage et ne devraient pas être abordées plus de deux ou trois en même temps. L'ordre de ces tâches n'est pas un ordre de priorité, mais un ordre logique généré à partir de celles-ci en fonction des dépendances entre les User Stories, des connaissances des développeurs et de l'ordre logique d'implantation des modules.

Des requis non-techniques sont également disponibles. (Gestion de la qualité, etc.)

Gestion du code source

Le projet utilise le système Git pour la gestion du code source. Vous trouverez toutes les informations nécessaires sur la page Téléchargement de COMETE et gestion du code source pour savoir comment télécharger COMETE, utiliser le logiciel git et comprendre l'organisation du dépôt.

Vous trouverez les instructions pour l'installation de COMETE sur la page Installation

Nous utilisons le système Maven pour la gestion des dépendances et la compilation du code.

Attachments

0.9.8 © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.70985 sec.)