Génération dynamique d'interfaces spécifiques dans l'exploitation des processus d'ingénierie logicielle en apprentissage

4.3.2 Le modèle de ROSE du Process Engine

Nous ne nous étendrons pas sur le modèle de ROSE du Process Engine, nous donnerons d'abord une explication sur l'importance des règles.

Si on se refère aux outils CASE qui ont également des règles de validation, on peut se demander à quoi bon refaire tout ceci; mais en y regardant de plus près on verra que les outils CASE s'intéressent à la vérification des artefacts par rapport au langage sous-jacent utilisé. Tandis que la validation des artefacts par rapport au processus consiste à s'assurer que ceux-ci sont conformes au déroulement du processus.

Les règles de validation proviennent essentiellement du package Dependancies de SPEM [OMG 2002]. Celui-ci propose cinq (05) types de dépendances pour un processus :

Precedes Spécifie qu'une Activity (ou un WorkProduct) précède une (ou un) autre.

Import Permet de spécifier qu'un élément du processus est importé pour appartenir à l'élément qui l'importe.

RefersTo Pour spécifier qu'un élément du processus réfère à un autre et s'assurer ainsi qu'ils sont inclus dans le même composant du processus.

Impact Relation entre deux WorkProduct du processus pour spécifier que la modification du premier peut avoir un impact sur le second.

Categorizes Permet de regrouper les éléments du processus de manière statique dans des packages.

Nous préconisons d'utiliser un moteur de règles à l'instar de QuickRules² offrant une interface visuelle pour renseigner les règles sur les artefacts du processus et une interface d'exploitation de ces règles au format XML avec un programme Java. Nous nous réfèrerons donc à la DTD de Quickrules : QRML disponible en Open Source. On pourrait bien évidemment envisager de définir un modèle pour les ROSE du Process Engine et ainsi, ne pas dépendre d'un éditeur quelconque, mais il faudrait égalemment implémenter un moteur de règles conséquent. D'oii l'adoption de la DTD de QuickRules.

4.3.3 Le modèle de ROSE du Process GUI

Le modèle de ROSE du Process GUI dérive un peu de la spécification semi-formelle des interfaces (voir le paragraphe 4.2 et la figure 4.1), nous y avons rajouté des attributs afin de mieux l'étoffer.

<!D O CTYPE Process GUI PUBLIC "processstate. dtd "> <!-- Type Operation -->

<!ENTITY %TOperation (create/read/write/delete)> <!-- Lien Interface XUL -->

<!ENTITY %TView #PCDATA>

<!-- Liste des ElEments du lexique -->

<!-- avec pour chacun les contraintes sur les valeurs --> <!ENTITY %LProp #PCDATA>

<!Interface>

<!ELEMENT Interface (Description, WorkProduct, Operation)> <!ATTLIST Interface id NMTOKEN #REQUIRED> <!ATTLIST Interface name CDATA #REQUIRED> <!ATTLIST Interface visibility NMTOKEN #REQUIRED> <!ATTLIST Interface view %TView #REQUIRED> <!ATTLIST Interface propertylist %LProp #REQUIRED> <!-- Operation -->

<!ELEMENT Operation (Description)>

<!ATTLIST Operation id NMTOKEN #REQUIRED> <!ATTLIST Operation name CDATA #REQUIRED>

²QuickRules , http : // www.quickrules.com

<!ATTLIST Operation visibility NMTOKEN #REQUIRED> <!ATTLIST Operation type %TOperation #REQUIRED>

Ces différents modèles nous ont permis de définir les besoins en acquisition et en exploitation des ROSE dans la suite. Cette démarche est générale et s'intéresse aux éléments à renseigner et exploiter, ainsi qu'aux tâches à réaliser.