Cached accessibility-tree control and code-enforced verification for design entry through a desktop application's user interface
Cet article présente un système de contrôle et de vérification d'une application de bureau pour le logiciel de conception de meubles Mozaik Enterprise qui utilise un arbre d'automatisation de l'interface utilisateur mis en cache pour une interaction efficace et des contrôles de logique imposés par le code afin de valider les saisies de conception, rapportant des mesures de performance préliminaires et des résultats d'injection de fautes tout en notant des limites dans l'évaluation de la précision de l'extraction.
Article original sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Dans le monde du logiciel, il existe un fossé persistant entre la manière dont les humains interagissent avec les ordinateurs et la façon dont les machines communiquent entre elles. Les humains utilisent des interfaces graphiques, cliquant sur des boutons et tapant dans des zones de saisie qui apparaissent à l'écran. Les machines, en revanche, préfèrent souvent parler un langage direct et structuré, contournant la couche visuelle pour envoyer des commandes directement au code sous-jacent. Lorsqu'un logiciel manque de ce langage direct, il devient une « boîte noire » pour les outils d'automatisation. C'est un obstacle courant pour l'automatisation robotisée des processus (RPA), un domaine où des robots logiciels sont entraînés pour effectuer des tâches répétitives en imitant les actions humaines sur un écran. Le défi est double : premièrement, le robot doit trouver le bon bouton ou l'élément de menu dans un paysage complexe et changeant de fenêtres ; deuxièmement, il doit savoir si l'action qu'il vient de réaliser a réellement fonctionné. Sans une ligne de communication directe, le robot est essentiellement aveugle, devinant si un clic est tombé au bon endroit ou si une nouvelle fenêtre est apparue comme prévu.
Un chercheur nommé Tiago Miranda de Leão a abordé ce problème en construisant un système pour automatiser une tâche spécifique et complexe : la conception de meubles de cuisine à l'aide d'une application Windows populaire appelée Mozaik Enterprise. Ce logiciel n'offre pas de moyen direct pour que des programmes externes puissent lui parler, de sorte que le système du chercheur a dû fonctionner entièrement via l'interface utilisateur, tout comme un humain le ferait. Le système a été conçu pour résoudre les deux problèmes principaux de l'automatification : le contrôle et la correction. Pour gérer le contrôle, le système a d'abord passé du temps à cartographier toute la structure de l'interface de l'application, créant une carte mentale de l'emplacement de chaque bouton et menu. Une fois cette carte établie, le système a cessé de chercher des éléments pour agir à partir d'une liste de coordonnées mises en cache, cliquant directement sur les emplacements connus des éléments de l'interface. Pour gérer la correction, le système a utilisé un modèle de vision pour « lire » un dessin de conception, puis a utilisé des règles de code strictes et pré-écrites pour vérifier si l'ordinateur avait réellement construit ce qui était demandé. Le code, et non l'intelligence artificielle, a pris la décision finale de savoir si le travail était réussi.
Les résultats de cette expérience ont été un mélange de rapidité prometteuse et de limitations significatives. Le système a réussi à cartographier l'interface de l'application, identifiant près de mille éléments distincts, et a stocké les positions d'environ six cents d'entre eux. Lorsque le système a tenté de basculer entre différents onglets dans le logiciel, la différence entre la recherche d'un onglet et le clic sur un emplacement mis en cache était flagrante. Trouver un onglet via la méthode standard prenait entre vingt-neuf et cinquante-sept secondes, un processus qui impliquait de chercher dans la structure interne de l'application à chaque fois. Une fois l'emplacement mis en cache, cependant, le basculement vers ce même onglet prenait moins d'un tiers de seconde. Cela a démontré que, pour un environnement stable, se souvenir de l'endroit où se trouvent les choses est bien plus efficace que de les chercher à chaque fois.
Cependant, la capacité d'adaptation du système était fragile. Les positions mises en cache étaient liées à la taille et à la forme exactes de la fenêtre lors de la création de la carte. Si la taille de la fenêtre changeait, ou si la résolution de l'écran était différente, les coordonnées mises en cache pointeraient vers le mauvais endroit, et le système échouerait. Le chercheur a constaté que le système ne pouvait pas s'auto-réparer ; si la disposition changeait, toute la carte devait être reconstruite de zéro. De plus, le système ne vérifiait pas si ses clics fonctionnaient réellement. Il signalait un succès même si l'application ne répondait pas, car il n'avait aucun moyen de vérifier le résultat sans regarder à nouveau l'écran, ce qui annulerait l'intérêt de la mise en cache.
La partie vérification du système, qui vérifiait si la conception correspondait au dessin, fonctionnait bien en théorie mais faisait face à des obstacles en pratique. Le système a été testé avec cinq cents cas synthétiques où des erreurs ont été délibérément injectées dans les données. Lors de ces tests, le code a correctement identifié chaque erreur intentionnelle, telle que des meubles manquants ou des types d'appareils erronés, et n'a jamais déclenché de fausse alerte. Il a rejeté avec succès les conceptions qui ne correspondaient pas aux exigences. Pourtant, lorsque le système a été testé sur des tentatives réelles et non scriptées de construction de meubles, les résultats étaient moins clairs. Cinq tentatives enregistrées de construction d'un design complet ont toutes échoué à un stade précoce, s'arrêtant avant que le produit final ne puisse être vérifié. Les journaux ont montré que le système ne parvenait pas à compter correctement les meubles qu'il était censé construire, entraînant un arrêt immédiat. Le chercheur a noté que le système n'avait pas été testé sur une grande variété de dessins du monde réel, et que les rares tentatives réelles enregistrées étaient incomplètes.
L'étude a également mis en évidence le rôle de l'intelligence artificielle dans ce processus. Le système a utilisé un modèle d'IA pour interpréter les dessins de conception, mais la décision finale sur la réussite de la construction a été laissée au code. Cette séparation était intentionnelle ; le code agissait comme un gardien strict, garantissant que l'interprétation de l'IA soit vérifiée par rapport à des règles rigoureuses. Le chercheur a constaté que, bien que l'IA puisse décrire les dessins, elle ne pouvait pas être considérée comme fiable pour juger le résultat par elle-même. Le système était conçu de telle sorte que si l'IA commettait une erreur, le code la détecterait. Cependant, les registres ont montré que, lors des quelques tentatives réelles, le système avait échoué avant même d'atteindre l'étape où la description de l'IA était comparée au résultat final.
En fin de compte, ce travail offre une image claire de ce qui est possible lors de l'automatisation de logiciels qui refusent de parler directement aux machines. L'approche consistant à cartographier l'interface une seule fois, puis à agir sur la base de ces souvenirs, est rapide et efficace, mais elle est fragile. Elle ne fonctionne que tant que le logiciel ressemble exactement à ce qu'il était lors de la création de la carte. Le système a prouvé que les contrôles imposés par le code peuvent vérifier les résultats de manière fiable, mais il a également montré que sans un moyen robuste de gérer les changements d'interface ou de se rétablir après des erreurs, l'automatisation ne peut pas encore remplacer un humain dans un environnement dynamique. Le chercheur a conclu que, bien que la méthode fonctionne pour une version spécifique du logiciel sur une machine spécifique, elle n'est pas une solution générale pour toutes les applications. Le système reste une preuve de concept, démontrant que l'automatisation est possible même sans accès direct, mais souligne également la difficulté de rendre de tels systèmes assez robustes pour le monde réel.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.