Exemple fil conducteur : Système de gestion de conférence

contextes tels que la gestion de projets, le développement de logiciel, la gestion de conférences scientifiques, etc. Nous nous plaçons plus particulièrement dans ce dernier contexte.

Comme les documents sont maintenant rédigés dans un format électronique, la plupart des communautés scientifiques ont récemment établi des politiques et des mécanismes afin de mettre en œuvre la gestion électronique de conférence, notamment en exploitant l'internet comme infrastructure de communication et de coopération (Papagelis et al., 2005).

Pour illustrer la problématique de notre travail, nous avons choisi un système de gestion de conférence (CMS : Conference Management System) comme fil conducteur. Ce système est conçu pour supporter les principales fonctions requises pour la gestion d'une conférence telles que : appel à communication, soumission d'articles, relecture des articles, notification de la décision finale, inscription, etc.

Le choix de cet exemple s’explique d’une part par le fait qu’il est bien connu des chercheurs, d’autre part, par le fait qu’il implique différents acteurs (concepteurs) que l’on peut associer à des modèles hétérogènes.

Nous avons choisi – pour ne pas trop complexifier l’exemple – de représenter le CMS par trois domaines métier. Ces domaines métier sont représentés par des modèles (cf. Figure IV-1) supposés avoir été élaborés séparément par les 3 acteurs suivants :

 Architecte logiciel : responsable de la conception logicielle du CMS ; il produit un modèle de conception logicielle (Software design) exprimé à travers un métamodèle spécifique de conception logicielle,

 Architecte de base de données : responsable de la mémorisation des données ; il crée un modèle (Persistence) exprimé à travers un métamodèle de persistance,  Concepteur de procédés : responsable de la façon de mettre en oeuvre un CMS ;

il crée un modèle (Business process) exprimé à l’aide d’un métamodèle de processus métier.

Figure IV-1: Vue globale des modèles du CMS

Dans les sous-sections suivantes, nous présentons les modèles ainsi que les métamodèles associés. La création du M1C sera abordée dans la section IV.7.

IV.2.1. Modèle de conception logicielle

Dans la Figure IV-2, nous proposons un métamodèle, inspiré d’UML, simple mais suffisant pour la description de la conception logicielle. Il définit des entités, avec leurs propriétés et opérations, ainsi que les associations qui existent entre elles.

Figure IV-2 : Métamodèle de conception logicielle

La Figure IV-3 illustre un aperçu d’un modèle conforme au métamodèle précédent. Il est constitué de quatre types d’utilisateurs (organisateur, auteur, participant et relecteur) avec leurs informations personnelles. La conférence à gérer est décrite par l’intermédiaire de l’entité conference, qui contient différentes propriétés. On peut citer par exemple, le domaine de recherche, la date limite de soumission, la date de notification, le lieu de la conférence, etc. Au sein d’une conférence, plusieurs papiers sont ajoutés via l’opération addPaper(). Un papier, représenté via l’entité paper, est caractérisé par plusieurs propriétés parmi lesquelles : titre, résumé, mots clé, contenu, etc. et un identificateur attribué une fois que le papier a été soumis. Un papier peut être rédigé par plusieurs auteurs d’où l’assosciation nommée writes et il est assigné à plusieurs relecteurs pour évaluation.

Figure IV-3: Modèle de conception logicielle IV.2.2. Modèle de persistance

Le métamodèle proposé (cf. Figure IV-4) représente le socle des éléments d’une base de données relationnelle et les relations entre eux. Le schéma de la base de données regroupe des tables et vues. Ces dernières contiennent des colonnes qui peuvent être aussi des clés primaires ou des clés étrangères.

Figure IV-4 : Métamodèle de persistance

La Figure IV-5 présente le modèle créé. Il contient les tables permettant d’enregistrer les informations propres à un acteur (AuthorTable) telles que son identificateur, le nom de l’organisation à laquelle il est affilié. La table ArticleReviewsTable reflète les données concernant l’évaluation d’un article à savoir une colonne reviews pour les remarques et critiques, une colonne decision pour renseigner l’acceptation ou bien le refus. Dans la même table, une colonne de type clé primaire est utilisée pour énumérer de façon unique les différentes évaluations ainsi qu’une colonne de type clé étrangère permettant d’identifier le relecteur.

IV.2.3. Modèle du processus métier

La gestion d’une conférence peut être vue comme un processus métier que les différents acteurs doivent mettre en œuvre pour garantir son bon déroulement. Le métamodèle choisi (cf. Figure IV-6) est celui de la notation BPM (OMG, 2013). Il comprend les concepts : lane, pool, task, etc.

Figure IV-6: Métamodèle de processus métier

Un extrait du modèle du processus métier (cf. Figure IV-7) montre les différentes phases de gestion du CMS. Pour simplifier, nous avons limité le processus du CMS à un seul acteur (suffisant pour illustrer notre propos) : le relecteur. Quand la date de soumission est dépassée, le président invite les relecteurs à indiquer via le CMS les articles qu’ils souhaitent relire. Le relecteur déclare par la suite ses éventuels conflits d’intérêt.

Dans le processus de la Figure IV-7, l’accent est mis sur la procédure d’évaluation d’articles. Une fois le processus de relecture déclenché, le relecteur choisit un papier parmi ceux qu’il a précédemment sélectionnés. À partir de ce moment, il peut soit faire lui-même l’évaluation soit la sous-traiter à une tierce personne (à cause d’un manque de temps ou de compétences). L’évaluation est saisie ensuite dans un formulaire dans lequel il peut ajouter des commentaires.

Figure IV-7: Modèle de processus métier

Les sections suivantes ont pour objectif de définir la démarche mise en œuvre pour élaborer un modèle contenant les différentes correspondances qui peuvent exister entre les modèles source en exploitant les métamodèles auxquels ils sont conformes. Elles sont illustrées par l’exemple du CMS.