Damien Clauzel - Mot-clé - doxygen2024-03-27T11:37:53+01:00Damien Clauzelurn:md5:6728c0058bb2c4b2870d8dbd71b50f9eDotclearGénération automatique du modèle de trace d'une application instrumentéeurn:md5:02abaa91b87cc51bc10b94dce8d1db312009-09-07T10:46:00+02:002016-01-06T18:06:17+01:00Damien ClauzelIngénierie de l'expérience tracéearchitecturecollecte de tracedoxygendéveloppementgénération de codeimplémentationjavadocmodèle de tracemodélisationproblèmequestiontechniquetrace modélisée <h3>Le problème</h3>
<p>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 :)</p>
<p>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.</p>
<p>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.</p>
<h3>La solution (possible ?)</h3>
<p>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 <a href="http://fr.wikipedia.org/wiki/javadoc" hreflang="fr">javadoc</a> ou <a href="http://fr.wikipedia.org/wiki/Doxygen" hreflang="fr">doxygen</a>.</p>
<p>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.</p>
<p>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.</p>
<h3>Conceptuellement</h3>
<p><ins>idée clé</ins> : 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.</p>
<p>Cette approche serait utilisée, <em>a priori</em>, 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.</p>
<h3>En pratique</h3>
<p>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.</p>
<p>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 »</p>
<pre class="brush: xml">=define "en-tête 1"
@prefix : <http://liris.cnrs.fr/silex/ns/ktbs/>.
@prefix mod: <>.
@prefix xsd: <TODO> .
<> a :TraceModel ;
:hasTemporalDomain :seconds .</pre>
<p>Puis, dans le code de l'application on insère les marqueurs pour la génération du modèle</p>
<pre class="brush: actionscript3">/*
* =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(...) {
...
}</pre>
<p>Et là, c'est le drame car il faut exprimer des choses comme comme le fragment ci-dessous.</p>
<pre class="brush: xml">>:aRange [ a owl:DatatypeRestriction ;
owl:onDatatype xsd:string ;%%%
xsd:pattern "(#|&)[a-zA-Z0-9]{,63}"
]</pre>
<p>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.</p>
<p>Le modèle généré :</p>
<pre class="brush: xml">@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]*"
]
.</pre>https://damien.clauzel.eu/post/2009/09/07/G%C3%A9n%C3%A9ration-automatique-du-mod%C3%A8le-de-trace-d-une-application-instrument%C3%A9e#comment-formhttps://damien.clauzel.eu/feed/atom/comments/30