Le problème

Maintenir la conception du modèle de trace d'une application de la conception de l'application n'a pour moi pas de sens : on perd du temps à passer de l'un à l'autre, on s'embrouille et c'est une approche préhistorique (ou du moins datant du COBOL :)

On pourrait se dire que disposer d'un modèle de l'application ne présente pas nécessairement un intérêt quand on cherche à obtenir une trace des interactions d'un utilisateur, mais pour moi c'est sauter une étape.

En effet, depuis de nombreux mois plusieurs personnes de l'équipe SILEX travaillent sur des modèles d'interactions. Au delà des problèmes concrets lié à l'expression de modèles conformes au métamodèle, il se pourrait qu'une des choses qui nous freine soit de vouloir réaliser tout de suite un grand pas : on ne sait pas décrire le comportement d'une application, alors qu'on veut décrire le comportement de l'utilisateur dans cette application.

La solution (possible ?)

Plus j'y pense, et plus je me dis que la solution passe peut-être par une génération automatique des modèles de l'application. Le principe serait alors de générer le(s) modèle(s) de l'application à la compilation, sur le même principe que la documentation des API tel javadoc ou doxygen.

On peut songer à quelque chose de similaire au javadoc : avec des marqueurs bien placés dans le code, on génère à la compilation des modèles correspondant à des éléments d'interface.

Du coup, on permet au développeur de structurer les modèles de l'application, tout en permettant à l'utilisateur de concevoir des modèles supplémentaire.

Conceptuellement

idée clé : les API sont un modèle de l'application orienté développeur; le modèle de trace d'interactions est un modèle de l'application orienté utilisateur.

Cette approche serait utilisée, a priori, uniquement pour les applications instrumentées directement dans le code. Éventuellement, peut-être aussi pour les enrichissements d'application à base de plugins, mais il faudrait que j'y réfléchisse.

En pratique

Pour réaliser la génération de modèle d'application, ces questions pratiques se posent : sur quelles fonctions placer les marqueurs de génération d'observés ? Callback/méthode associés aux widgets ? D'une façon générale, très probablement sur les fonctions les plus proches de l'utilisateur, donc au niveau des E/S. L'idée est de ne pas ajouter de code, juste des commentaires contenant les marqueurs.

On commence par définir globalement les propriété communes : références au métamodèle, à l'extension temporelle, etc. On peut songer par exemple à un mécanisme de macro ou de variables (je l'appellerais ici « en-tête 1 »

=define "en-tête 1"
@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .

<> a :TraceModel ;
	:hasTemporalDomain :seconds .

Puis, dans le code de l'application on insère les marqueurs pour la génération du modèle

/*
 * =include "en-tête 1"
 * =type presseTouche
 * =description "décrit la frappe d'une touche dans la zone de saisie"
 * =string "versionDeWeeChat"
 * =string "monPseudo"
 * =string "nomDuCanal"
 */ 
LaFonctionGérantLesFrappesClavierDeLutilisateur(...) {
	...
}

Et là, c'est le drame car il faut exprimer des choses comme comme le fragment ci-dessous.

>:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;%%%
	xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
]

Mais l'idée reste la même : pour moi, les informations permettant la génération du modèle doivent être notées sous forme réduite, juste à côté du code, et sans gêner les développeurs.

Le modèle généré :

@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .

<> a :TraceModel ;
	:hasTemporalDomain :seconds .


mod:presseTouche a :ObserType .


mod:versionDeWeeChat a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange xsd:string ;
.

mod:monPseudo a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange xsd:string ;
.

mod:nomDuCanal a :Attribute ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
		owl:onDatatype xsd:string ;
		xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
	] 
.

mod:nomDuServeur a :Attribute ;
	rdfs:label "Nom du Serveur"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(IPv4|IPv6|hostname)"
	]
.

mod:typeDeTampon a :Attribute ;
	rdfs:label "Type de tampon"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "[0-2]"
	]
.

mod:caractère a :Attribute ;
	rdfs:label "Caractère frappé"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(\*?|STRING)"
	]
.

mod:zoneDeSaisieAvantCaractère a :Attribute ;
	rdfs:label "Contenu de la zonne de saisie avant la frappe clavier"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:zoneDeSaisieAprèsCaractère a :Attribute ;
	rdfs:label "Contenu de la zonne de saisie après la frappe clavier"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:drapeauAway a :Attribute ;
	rdfs:label "Status de présence"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "(0|1)"
	] ## ?? vérifier dans la spec de OWL 2
.

mod:contenuDeLaZoneDeSaisie a :Attribute ;
	rdfs:label "Contenu de la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:contenuDuMasqueDeCouleurDeLaZoneDeSaisie a :Attribute ;
	rdfs:label "Masque de la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern ".*"
	]
.

mod:positionDuCurseurDansLaZoneDeSaisie a :Attribute ;
	rdfs:label "Position du curseur dans la zone de saisie"@fr ;
	:aDomain mod:presseTouche ;
	:aRange [ a owl:DatatypeRestriction ;
	owl:onDatatype xsd:string ;
		xsd:pattern "[0-9]*"
	]
.