Cached accessibility-tree control and code-enforced verification for design entry through a desktop application's user interface
تقدم هذه الورقة نظاماً للتحكم والتحقق من تطبيقات سطح المكتب لبرنامج تصميم الخزائن Mozaik Enterprise، والذي يستخدم شجرة أتمتة واجهة مستخدم مخبأة للتفاعل بكفاءة وفحوصات منطقية مفروضة برمجياً للتحقق من صحة مدخلات التصميم، مع عرض مقاييس الأداء الأولية ونتائج حقن الأخطاء مع الإشارة إلى القيود في تقييم دقة الاستخراج.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم البرمجيات، هناك انقسام مستمر بين كيفية تفاعل البشر مع الحواسيب وكيفية تحدث الآلات مع بعضها البعض. يستخدم البشر الواجهات الرسومية، حيث ينقرون على الأزرار ويكتبون في الصناديق التي تظهر على الشاشة. أما الآلات، فغالبًا ما تفضل التحدث بلغة مباشرة ومنظمة، متجاوزة الطبقة المرئية لإرسال الأوامر مباشرة إلى الكود الأساسي. وعندما تفتقر قطعة برمجية إلى هذه اللغة المباشرة، تصبح "صندوقًا أسود" بالنسبة لأدوات الأتمتة. وهذا يمثل عقبة شائعة في مجال أتمتة العمليات الروبوتية، وهو مجال يتم فيه تدريب بوتات البرامج على أداء مهام متكررة من خلال محاكاة الأفعال البشرية على الشاشة. والتحدي هنا مزدوج: أولاً، يجب على البوت العثور على الزر أو عنصر القائمة الصحيح في مشهد معقد ومتغير من النوافذ؛ وثانيًا، يجب أن يعرف ما إذا كان الإجراء الذي اتخذه قد نجح بالفعل. وبدون خط اتصال مباشر، يكون البوت في الأساس أعمى، يخمن ما إذا كانت النقرة قد استقرت في المكان الصحيح أو ما إذا كانت نافذة جديدة قد ظهرت كما هو متوقع.
لقد تصدى باحث يدعى تياغو ميراندا دي ليو لهذه المشكلة من خلال بناء نظام لأتمتة مهمة محددة ومعقدة: تصميم خزائن المطبخ باستخدام تطبيق ويندوز شهير يسمى Mozaik Enterprise. لا يوفر هذا البرنامج طريقة مباشرة للبرامج الخارجية للتحدث معه، لذا كان على نظام الباحث أن يعمل بالكامل من خلال واجهة المستخدم، تمامًا كما يفعل البشر. تم تصميم النظام لحل مشكلتي الأتمتة الرئيسيتين: التحكم والصحة. وللتعامل مع التحكم، قضى النظام وقتًا في رسم خريطة لهيكل واجهة التطبيق بالكامل، منشئًا خريطة ذهنية لمكان وجود كل زر وقائمة. وبمجرد بناء هذه الخريطة، توقف النظام عن البحث عن الأشياء وبدأ بدلاً من ذلك في التصرف بناءً على قائمة إحداثيات مخبأة، حيث ينقر مباشرة على المواقع المعروفة لعناصر الواجهة. وللتعامل مع الصحة، استخدم النظام نموذج رؤية لـ "قراءة" رسم تصميمي، ثم استخدم قواعد كود صارمة ومكتوبة مسبقًا للتحقق مما إذا كان الكمبيوتر قد بنى بالفعل ما هو مطلوب. الكود، وليس الذكاء الاصطناعي، هو من اتخذ القرار النهائي بشأن ما إذا كان العمل ناجحًا أم لا.
كانت نتائج هذه التجربة مزيجًا من السرعة الواعدة والقيود الكبيرة. نجح النظام في رسم خريطة لواجهة التطبيق، حيث حدد ما يقرب من ألف عنصر متميز، وخزن مواقع حوالي ستمائة منها. وعندما حاول النظام التنقل بين علامات تبويب مختلفة في البرنامج، كان الفرق بين البحث عن علامة التبويب والنقر على موقع مخبأ صارخًا. استغرق العثور على علامة تبويب من خلال الطريقة القياسية ما بين تسع وعشرين إلى سبع وخمسين ثانية، وهي عملية تتضمن البحث في بنية التطبيق الداخلية في كل مرة. ولكن بمجرد تخزين الموقع، استغرق الانتقال إلى علامة التبويب نفسها أقل من ثلث ثانية. وقد أثبت هذا أنه في البيئة المستقرة، يعد تذكر مكان الأشياء أكثر كفاءة بكثير من البحث عنها في كل مرة.
ومع ذلك، كانت قدرة النظام على التكيف هشة. كانت المواقع المخزنة مرتبطة بالحجم والشكل الدقيق للنافذة عند إنشاء الخريطة لأول مرة. فإذا تغير حجم النافذة، أو إذا كانت دقة الشاشة مختلفة، فإن الإحداثيات المخزنة ستشير إلى المكان الخاطئ، وسيفشل النظام. ووجد الباحث أن النظام لا يمكنه إصلاح نفسه تلقائيًا؛ فإذا تغير التخطيط، يجب إعادة بناء الخريطة بأكملها من الصفر. علاوة على ذلك، لم يتحقق النظام مما إذا كانت نقراته قد نجحت بالفعل. فقد كان يبلغ عن النجاح حتى لو لم يستجب التطبيق، لأنه لم يكن لديه طريقة للتحقق من النتيجة دون النظر إلى الشاشة مرة أخرى، وهو ما قد يلغي الغرض من التخزين المؤقت.
عمل الجزء الخاص بالتحقق من النظام، والذي فحص ما إذا كان التصميم يطابق الرسم، عمل بشكل جيد من الناحية النظرية ولكنه واجه عقبات في الممارسة العملية. تم اختبار النظام مع خمسمائة حالة اصطناعية حيث تم إدخال أخطاء متعمدة في البيانات. وفي هذه الاختبارات، حدد الكود كل خطأ مقصود بشكل صحيح، مثل الخزائن المفقودة أو أنواع الأجهزة الخاطئة، ولم يطلق أي إنذار كاذب أبدًا. لقد رفض بنجاح التصاميم التي لا تطابق المتطلبات. ومع ذلك، عندما تم اختبار النظام على محاولات حقيقية غير مبرمجة لبناء الخزائن، كانت النتائج أقل وضوحًا. فشلت خمس محاولات مسجلة لبناء تصميم كامل في مرحلة مبكرة، وتوقفت قبل التحقق من المنتج النهائي. أظهرت السجلات أن النظام لم يستطع عد الخزائن التي كان من المفترض بناؤها بشكل صحيح، مما أدى إلى توقف فوري. وأشار الباحث إلى أن النظام لم يتم اختباره على مجموعة متنوعة من الرسومات الواقعية، وأن المحاولات الحقيقية القليلة المسجلة كانت غير مكتملة.
كما سلطت الدراسة الضوء على دور الذكاء الاصطناعي في هذه العملية. استخدم النظام نموذج ذكاء اصطناعي لتفسير رسومات التصميم، ولكن تم ترك القرار النهائي بشأن نجاح البناء للكود. كان هذا الفصل مقصودًا؛ حيث عمل الكود كحارس صارم، لضمان فحص تفسير الذكاء الاصطناعي مقابل قواعد صلبة. ووجد الباحث أنه بينما يمكن للذكاء الاصطناعي وصف الرسومات، لا يمكن الوثوق به للحكم على النتيجة بمفرده. تم تصميم النظام بحيث إذا ارتكب الذكاء الاصطناعي خطأً، سيقوم الكود باكتشافه. ومع ذلك، أظهرت السجلات أنه في المحاولات الواقعية القليلة، فشل النظام قبل أن يصل حتى إلى المرحلة التي تتم فيها مقارنة وصف الذكاء الاصطناعي بالنتيجة النهائية.
في النهاية، يقدم هذا العمل صورة واضحة لما يمكن تحقيقه عند أتمتة برمجيات ترفض التحدث مباشرة مع الآلات. إن نهج رسم خريطة الواجهة مرة واحدة ثم التصرف بناءً على تلك الذاكرة هو نهج سريع وفعال، ولكنه هش. فهو يعمل فقط طالما ظل البرنامج يبدو تمامًا كما كان عندما تم إنشاء الخريطة. أثبت النظام أن عمليات التحقق التي يفرضها الكود يمكنها التحقق من النتائج بشكل موثوق، لكنه أظهر أيضًا أنه بدون طريقة قوية للتعامل مع التغييرات في الواجهة أو التعافي من الأخطاء، لا يمكن للأتمتة أن تحل محل البشر في بيئة ديناميكية. وخلص الباحث إلى أنه بينما يعمل الأسلوب لنسخة محددة من البرنامج على جهاز محدد، فإنه ليس حلاً عامًا لجميع التطبيقات. يظل النظام بمثابة إثبات للمفهوم، مما يدل على أن الأتمتة ممكنة حتى بدون وصول مباشر، ولكنه يؤكد أيضًا صعوبة جعل مثل هذه الأنظمة قوية بما يكفي للعالم الحقيقي.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.