Modélisation

Éléments constitutifs d'une tâche

Le modèle minimal d'une tâche est composé d'un cycle de vie et d'un titre. Un modèle de tâche correspond à une classe de fragments dont le titre de la tâche est l'intitulé. Par exemple, il est possible de modéliser des tâches à s'auto-attribuer qui s’intituleraient « post-it » ou « notes personnelles ». Le cycle de vie est constitué d'un ensemble à définir d'états et de transitions. Chaque état est associé à un statut de tâche qui peut être soit à venir, soit en cours, soit close. Ce statut est directement exploité par la chaîne éditoriale. Par exemple, si une note personnelle prévoit un état intitulé note ouverte, associé au statut en cours, et un état note fermée, associé au statut close, la note personnelle apparaîtra avec toutes les tâches en cours lorsque son état sera note ouverte et avec toutes les tâches closes lorsque son état sera note fermée.

Les définitions d'une tâche et de son cycle de vie se font respectivement dans une primitive dédiée au sein de SCENARIbuilder. Le schéma et le comportement de cette primitive font partie du méta-modèle de chaînes éditoriales de SCENARIbuilder (appelé modeling). Comme l'ensemble de la suite logicielle Scenari, les sources sont libres et consultables en ligne.

Une instance de la primitive de définition du cycle de vie d'une tâche est illustrée sur la figure 44.

Figure 44 : définition d'un cycle de vie

Éléments facultatifs

En complément, un modèle de tâches peut définir une date de planification et une date d'échéance. Ces propriétés permettent d’ordonnancer les tâches entre elles. Un modèle peut également définir un fil de discussion et référencer des primitives documentaires classiques (primitive de composition ou de ressources). C'est par un lien depuis la partie documentaire du modèle de la tâche qu'un fragment lui est associé. Enfin, il est possible de définir des responsabilités. Une responsabilité correspond à un rôle joué par un utilisateur au sein d'une tâche. Par exemple, une tâche de validation d'un contenu par un expert pourra contenir une responsabilité « expert » et une responsabilité « rédacteur ». La modélisation des responsabilités permet d'associer une responsabilité à un état du cycle de vie. Ainsi, quand la tâche de validation par l'expert sera dans l'état « en attente de validation », elle se retrouvera associée à l'usager ayant la responsabilité « expert ».

Figure 45 : définition des responsabilité dans une tâche

Conventions de modélisation

Dans ce mémoire, nous utilisons les conventions suivantes.

Pour représenter un cycle de vie, nous proposons une notation inspirée des diagrammes d'activité UML (OMG, 2011[1], section 12, pp. 303-434).

  • Un état initial sera représenté par :

  • Un état sera représenté par :

  • Une transition sera représentée par :

  • Un état final sera représenté par :

La notion d'état final correspond à un état du cycle de vie duquel aucune transition ne permet de sortir. Par définition, un cycle de vie pourra donc avoir plusieurs états finaux différents ou ne pas avoir d'état final.

À chaque état du cycle de vie correspond un statut (à venir, en cours, clos). Nous proposons de faire varier la couleur de fond d'un état pour spécifier le statut.

  • Un état avec statut à venir sera représenté par un fond de couleur orangé :

  • Un état avec statut en cours sera représenté par un fond de couleur blanc :

  • Un état avec statut terminé sera représenté par un fond de couleur mauve :

Ainsi, un cycle de vie pourrait se modéliser comme illustré sur la figure 46 :

Figure 46 : exemple de cycle de vie

Un fragment de tâche sera modélisé dans une classe au sein d'un diagramme de classes de le standard cycleUML (OMG, 2011[2], section 7, pp. 21-144). Un stéréotype dédié, différent des trois déjà introduits (composition, meta et ressource) au sein de la section dédiée à la modélisation du premier chapitre, indiquera qu'il s'agit d'une tâche. En outre, afin de prendre en compte le caractère plus fermé de la définition de tâche (mis à part la description qui pointe une primitive documentaire classique, la tâche ne peut contenir qu'un ensemble fini de propriétés), nous proposons de lister les champs pouvant constituer une tâche avec une valeur booléenne pour indiquer son usage ou non dans un modèle donné. Ainsi, dans l'exemple suivant, la tâche de validation comporte un titre, une date d'échéance, un fil de discussion et deux responsabilités intitulées Relecteur et Rédacteur.

Figure 47 : modèle de tâche de validation

La dernière information nécessaire pour représenter l'ensemble du modèle d'une tâche correspond à l'association entre une responsabilité et l'état d'une tâche. Cette association, si elle existe, peut prendre la valeur suiveur, la valeur exécutant ou les deux en mêmes temps. Nous proposons de représenter ces valeurs dans un tableau à double entrée : les responsabilités d'un côté et les états de l'autre.

À valider

À modifier

Terminé

Rédacteur

Suiveur

Exécutant

Aucun

Relecteur

Exécutant

Suiveur

Aucun