Depuis la création de Clariprint, à l’issu d’un calcul, l’utilisateur voit, soit un résultat exploitable, soit la mention « impossible à calculer ». Il en ressort que l’utilisateur n’est pas capable de comprendre directement pourquoi un calcul est « impossible », donc incapable d’agir avec certitude sur :
• les caractéristiques du produit dont il souhaite le chiffrage (en phase d’exploitation)
• les données machines ou papier qu’il doit modifier pour calculer le produit (en phase de
paramétrage des données)
Il est donc obligé de procéder à taton, par exemple en modifiant les spécifications du produit jusqu’à ce qu’il obtienne un calcul valide.
D’autre part, quand un calcul abouti, certains utilisateurs experts souhaitent vérifier la logique de l’optimisation afin de s’assurer que le calculateur n’est pas passé à côté d’une meilleure solution, ou afin de comprendre ce qui a entravé le cheminement vers une solution pressentie comme bonne.
Enfin, bien qu’il existe des traces écrites dans un fichier log, elles sont activables uniquement dans le paramétrage du serveur de calcul, nécessite le redémarrage de celui-ci, de se connecter en ssh au serveur pour visionner les logs à la console. Cette procédure, très chronophage, nécessite les compétences d’un développeur, or l’analyse du cheminement et de la pile d’appel est souvent indispensable à la rédaction d’un rapport de bogue ou simplement à la détermination des paramètres manquants ou bloquants dans le paramétrage technique des machines ou des supports.
Donc les objectifs de cette opération sont de résoudre ces problèmes, plus précisément :
1/ être capable en moins de 100 caractères d’exprimer de manière intelligible pour un utilisateur de profil deviseur ou fabricant en imprimerie, une raison à l’impossibilité de calcul (il ne s’agit pas d’être exhaustif mais concis et précis)
2/ produire un log simplifié du cheminement du calculateur :
a/ à l’attention des utilisateurs de profil deviseur ou fabricant en imprimerie,
b/ qui soit accessible directement depuis l’interface graphique,
c/ qui soit hiérarchisé (sous la forme d’un arbre dépliable)
d/ qui met en évidence les points de blocage
3/ de produire un log étendu du cheminement du calculateur :
a/ à l’attention des utilisateurs avancés (gestionnaire d’exploitation chez le client, support Clariprint,
développeurs Clariprint)
b/ qui reprend l’arborescence du log simplifié en la complétant avec les appels fonctionnels jugés
pertinents, les itérations jugées pertinentes (boucle de contrôle « For ») et les interceptions
d’exceptions jugées pertinentes (bloc de traitement encadré par « try » … « catch »)
Les verrous technologiques et incertitudes
Comment instrumenter le code du calculateur sans l’alourdir ?
Comment déterminer à priori le domaine d’utilisation d’une machine au regard du support
choisi afin de pré-filtrer les impossibilités métiers en amont de la recherche de solution ?
Comment gérer les impossibilités métiers dans un arbre de recherche alternant les branches
complémentaires et les branches concurrentes afin de remonter à l’utilisateur une erreur pertinente
et intelligible ?
Comment minimiser le volume des données du log ?
Quel est l’impact sur le temps de calcul si on systématise la génération du log ?
Le plan de l’opération est le suivant :
1/ customisation du langage Claire et de son compilateur pour créer des « call-back » pour les nouvelles instructions « tfor », « ttry »
2/ création d’un module contrôleur des « front logs » exploitant des « call-back » pour générer des lignes de traces pour les instructions « tfor », « ttry » et « tcall »
3/ création d’apis pour hiérarchiser le log par chapitre et ajouter des commentaires
4/ étape 1 de l’instrumentation du code du calculateur pour tests de génération de logs
5/ création du visualiseur de log : code qui interprète le log et génère dynamiquement une page html
6/ création d’une procédure de pré-contrôle de l’adéquation des données d’un environnement de calcul (parc-machine, papier etc …) aux spécifications de la demande
7/ Instrumentation du code du calculateur pour détecter les points de blocage, les signaler par des erreurs dans le log, interrompre le calcul ou pas suivant l’apparition du blocage dans un groupe de branche concurrente ou complémentaire.
8/ afficher l’erreur la plus pertinente si le calcul n’a pas abouti
Conclusion :
Même si les résultats gagnent encore à être plus lisible pour les utilisateurs finaux, cette opération est un succès au-delà de toute espérance. Dans le cadre de cette étude nous nous sommes rapidement heurté à l’inadéquation initiale de la conception du calculateur
de Clariprint avec les objectifs visés. Ceci nous a conduit a repensé certaines parties qui au final ont profité à la robustesse de la solution et même à réduire le temps moyen de réponse grâce à des pré-contrôles systématiques.