🕰️ 🧒 👨🏿‍⚖️ هل يعد الإضافات حدثًا؟ 😀 🚟 👩🏼‍🤝‍👩🏻

1. مقدمة

بعد أن سمعت من الشفاه الرسمية أن "الأتمتة هي شيء حدث" [3] ، أدركت أن الأوتوماتة المحدودة هي علامة تجارية كاملة. نحكم على نفسك: في مكتبة Qt ، يتم تنفيذ نموذج حدث من الأتمتة [1] ، في UML هم أيضًا [2] ، نحن ننظر إلى الأوتوماتيكية لحزمة امتداد Simulink-Stateflow لنظام MATLAB [4] (يشار إليها فيما بعد باسم Stateflow) وهناك حول الأحداث ، إلخ. إلخ في هذا السياق ، بيان الدكتوراه AA من المشاغب التفسير بطريقة مختلفة ، لأنه لا شيء يمكن أن يكون ، لأنه لا يمكن أن يكون.

ولكن ، إذا كنت تتذكر نظرية الأتمتة المحدودة (TCA) ، فلا توجد كلمة عن الحدث الآلي في ذلك! ولكن من أجل التناقض مع النظرية ، هناك حاجة إلى حجج قوية. هل هناك أي سبب للشك في احترافية D. Harell ، كمبدع للتدوين الذي تستند إليه لغة UML ، حزمة Stateflow ، في أفكارها ، والتي بدورها ليست غير معروفة لـ A.A. Shalyto؟ في الواقع ، توجد خيارات UML و Stateflow و SWITCH وخيارات البرمجة التلقائية الأخرى ، وبدرجة أو بأخرى ، تعمل بنجاح.

فهل من الممكن إزالة "وصمة عار الأحداث" من نموذج آلة الحالة المحدودة عن طريق فصل "شرحات من الذباب"؟ أي افصل بين نظرية الأتمتة والنماذج الحسابية المشابهة لنماذج د. هاريل. وللنظر إلى أن هذا الأخير ، على الرغم من استخدام مصطلحات نظرية الأتمتة ، يمثل ، بناءً على تنفيذها ، تطوير نموذج من المخططات البرمجية للبرامج.

ملاحظة 1. في هذه الحالة ، نتحدث عن نموذج إدارة البرنامج ، وليس عن نموذج البرنامج نفسه (لمزيد من التفاصيل حول النماذج ، راجع [5]).

لذلك ، أذكر ، مكتبة Qt تنفذ نموذج حدث لآلة الحالة المحدودة ، والتي تم استعارتها من UML. يتم تنفيذ نفس النموذج من قبل Stateflow. أي مصدر الأحداث هو UML ، حيث تستند الأوتوماتة على الترميز الذي اقترحه د. هاريل. لكن إلقاء اللوم على هذا الأخير لإنشاء مثل هذه البرمجة التلقائية لن يكون كذلك ، لأن "الأحداث" هو ميل الأساليب الحديثة لتنفيذ نماذج البرمجيات. يعتمد على آراء موثوقة مثل "الأجهزة المذكورة هي شيء حدث" ، والشعبية العالية للغات والتقنيات مثل UML. بدون شك ، هذا ناتج عن تقليد الآلات وفقًا لمبادئ التشغيل الحالية لأنظمة التشغيل.

لكننا نكرر ، لأنه لا يبدو غريباً ، لكن بالنسبة للبعض قد يصبح خبراً ، في نظرية الأوتوماتة لا يوجد نموذج حدث لأوتوماتون محدود. على الأقل في هذا الجزء منه يعتبر كلاسيكيًا (انظر لمزيد من التفاصيل ، على سبيل المثال ، [6] أو [7]). هناك تناقض واضح بين النظرية والتطبيق. في مثل هذه الحالة ، تحتاج إلى عمل شيء ما مع النظرية أو التأثير بطريقة أو بأخرى على الممارسة. ولكن ، ربما ، المبرمجين على حق في رغبتهم في وضع اللمسات الأخيرة على نموذج لآلة الدولة المحدودة من خلال تضمين مفهوم "الحدث" في ذلك [8 ، 9]؟

لكن كيفية توصيل رغبات المبرمجين بحقيقة أن "أكبر الصعوبات في استخدام منهج الأوتوماتون ترتبط بفهم ميزات عمل الأوتوماتا في أنظمة الأحداث" (انظر [8]). أود أن أفهم أسباب مثل هذه المشاكل ، وفي هذا السياق ، قم بتطبيق آلات الأحداث و / أو ما يماثلها. لهذا الغرض ، للحصول على تفاصيل ، نأخذ تنفيذ الأوتوماتة في كيو تي ونكررها باستخدام نموذج الأوتوماتيكية الكلاسيكية المحدودة.

مثل هذا التنفيذ التلقائي للحدث ضروري لتقييم و / أو التغلب على "الميزات" المذكورة. سيؤدي استخدام النموذج الكلاسيكي إلى توسيع نظرية الأتمتة إلى ممارسة "برمجة الأحداث" أيضًا. وفي النهاية ، لن يؤدي التناظرية المستندة إلى طراز آخر إلى توسيع مجال تطبيق نماذج آلة الحالة المحدودة فقط.

2. الأحداث والإشارات والهوية بين الجنسين من automata

في UML ، يعتبر الحدث "ظاهرة مهمة لها موقع معين في الزمان والمكان ... وتستتبع عواقب معينة" [10]. حدث في نظرية الأتمتة هو مجموعة فرعية من أحرف الإدخال الممثلة بأحرف الأبجدية الناتجة (هناك حتى مفهوم جبر الأحداث في TCA) [6]. نفس الشيء الذي يسبب انتقال الأوتوماتون يسمى إشارات الإدخال في نظرية الأوتوماتا. إنها العواقب و "السبب ، انتقال الأوتوماتون من حالة إلى أخرى. في هذه الحالة ، تكون إشارات الخرج هي "استجابة الأوتوماتون لإشارات المدخلات". يشير كلاهما إلى "مثيلات الوقت التي تحددها التحولات المقابلة في الأوتوماتون" [6]. في UML ، تكون الإشارة (الإشارة) بمثابة "كيان مسمى يستخدم كوسيلة للاتصال بين الأشياء "[10].

وبالتالي ، فإن أسماء المصطلحات هي نفسها ، ولكن المعنى المستثمر فيها مختلف. على الرغم من أنه إذا قمت بإعادة ترتيبها ، يمكنك العثور على تشابه: يتضح أن الأحداث في UML تتوافق مع إشارات آلات الحالة المحدودة في TCA. ولكن ، ربما ، يتم إخفاء كيانات مختلفة تحت مصطلح "آلة الدولة المحدودة"؟ دعنا نحاول معرفة ذلك ، بدءا من الأحداث ...

الحدث الآلي هو التلقائي السلبي ، ل يعمل فقط في لحظة وصول الأحداث. في المقابل ، يمثل الأوتوماتون الكلاسيكي النموذج النشط. إنه يعمل دون الرجوع إلى أي شيء (لمزيد من التفاصيل حول التشغيل الآلي السلبي والنشط ، انظر [9]). هنا تتسابق العلاقة مع اثنين من المتسابقين ، حيث يتم قيادة الأول بواسطة الركلات (الأحداث) ، والثاني يعمل بمفرده.

على عكس [8] ، لن نربط في البداية لحظات حدوث الأحداث مع بداية التشغيل التلقائي. لذلك سنبقى في إطار نظرية الأتمتة ، والتي تحدد الطبيعة غير المتزامنة لعمل الأوتوماتة فيما يتعلق بالبيئة الخارجية. إنه يتحدث فقط عن الوقت المنفصل ، الذي يتم فيه تغيير الحالات لفترة زمنية تعسفية صغيرة ، ولكن لا تساوي صفرًا ، في الوقت الفعلي. وسبب التحولات هو الحالة الحالية وإشارات إدخال الجهاز ، حيث تكون العواقب هي تثبيت حالة جديدة وقيم إشارات الخرج الخاصة بالجهاز (لمزيد من التفاصيل حول تعريف الآلات ، انظر [6]).

تتميز نظرية Automata بالمرونة في تحديد الوقت المنفصل ، وهو نموذج في الوقت الفعلي. لذلك ، يمكن أن يكون للدورة الزمنية المنفصلة قيمة ثابتة أو عائمة لفاصل زمني حقيقي ، ووفقًا لهذا ، تسمى الأجهزة متزامنة أو غير متزامنة. في الوقت نفسه ، يمكن أن يكون للفاصل الزمني المرتبط بالساعة أي قيمة ، بما في ذلك قيمة صغيرة بلا حدود ، ولكنها لا تساوي الصفر.

ملاحظة 2. نموذج آلة الحالة المحدودة هو أحد النماذج الرسمية القليلة التي تتضمن في تعريفها نموذجًا في الوقت الحقيقي بشكل واضح.

نتيجةً لذلك ، تسمح السرعة "غير المحدودة" رسميًا للتشغيل التلقائي النشط بمعالجة أي حدث على أنه إشارة إدخال محتملة (من حيث UML ، الحالة [11] تتوافق معها). سوف يحتاج الجهاز فقط إلى "التقاط" مثل هذه الأحداث / الإشارات وإيقافها مؤقتًا. كل هذا في الواقع يحدد بروتوكول العمل المشترك للوسط والجهاز. يجب أن يحل البروتوكول أيضًا مشكلة التعرف على الأحداث المتطابقة المتلقاة. بدون هذا ، على سبيل المثال ، يمكن اعتبار رمزين متطابقين ، يتم استلامهما واحدًا تلو الآخر ، كواحد.

من الناحية الرسمية ، فإن الفروق الدقيقة في معالجة الأحداث ليست مهمة (انظر نفس ملخصات الأوتوماتيكية) ، ولكن في التطبيق العملي للخوارزميات التي يتم إنشاؤها بواسطة نوع نموذج الحدث ، يجب أن تؤخذ في الاعتبار. في حالة مكتبة Qt ، يتم إخفاء المحاسبة الخاصة بهم في فئات تنفيذ automaton. علاوة على ذلك ، سنأخذ في الاعتبار الاختلافات بين الحدث والأوتوماتة الكلاسيكية باستخدام مثال تطبيق أبسط آلة حاسبة من [1] ، حيث يتم تقديم "تنفيذ الحدث" الخاص به. على عكس هذا الحل ، سيتم إنشاء طرز مكافئة بناءً على آلة الحالة المحدودة الكلاسيكية.

3. نماذج الحاسبة

لذلك ، دعونا نبدأ ... نسميها إشارات الأحداث ، أو حدث الأوتوماتة العادي ... أو بترتيب عكسي و / أو العكس؟ هتاف اشمئزاز! الخلط. باختصار ، الكامل "glocky cuzdra shteko budlanula" وشيء "تجعيد الشعر". لمعرفة من هو من وماذا وماذا يسمي ، الطريقة الأضمن هي اختيار "bokra" و "bump it" ... مثل هذا "bokor" سيكون برنامج "الحاسبة الآلية".

3.1. نموذج آلة حاسبة نشطة

في التين. 1 يوضح النموذج الأصلي لآلة حاسبة الفئة من [1]. في المظهر ، يبدو وكأنه آلة تجريدية كلاسيكية مع عدم وجود مخرج. الفرق هو أن كيو تي تربط الإجراءات عندما تدخل وتخرج من حالة. عند الإخراج ، يتم تشغيلها بواسطة إشارة الخروج () ، وعند دخول الحالة ، بواسطة الإشارة () المدخلة. لكننا نلاحظ أن هذه الإجراءات لا يتم تمثيلها في الرسم البياني بأي طريقة.

إذا قارنا النموذج في الشكل. 1 مع آلية تلقائية مع حالة مجردة (أسماءها الأخرى هي بنية تلقائية ومنطقية) ، يمكن للمرء بسهولة أن يرى أن الإجراءات عند الخروج من الولاية تتوافق مع إشارات Mealy automaton ، والإجراءات عند مدخلها هي إشارات Moore automaton.
الملاحظة 3. علاوة على ذلك ، عند النظر في تطبيق البرنامج للنموذج ، لن نتحدث عن الإشارات والأحداث والشروط ، وما إلى ذلك ، ولكن عن تصرفات automata ، على افتراض أنها ترتبط على مستوى البرنامج ببعض إجراءات البرنامج ، والتي في الحالة العامة ممثلة وظائف البرنامج.

ما يسمى بآلية Mili-Moore المدمجة (أو الأوتوماتون المختلط بشكل مختلف [12]) ، أي ما يعادل الأوتوماتون في الشكل. يظهر الشكل 1 في الشكل 2 ، حيث تظهر أيضًا الوظائف المقابلة لإشارات الدخل والإخراج الخاصة بآلية التشغيل الآلي على يمين الرسم البياني.

الشكل 1. آلة حاسبة الحدث الرسم البياني

الشكل 2. عد مايلي مور آلة حاسبة الطبقة الأوتوماتيكية

بالنسبة إلى نموذج مشابه لنظام التشغيل الآلي في الشكل 2 ، فإننا نعني بإجراءات الإدخال / الإخراج التقديرات والإجراءات التي تمثل طرق وظائف البرنامج لفئات [التشغيل التلقائي]. يتنبأ بتحليل الحالة الحالية لعناصر الذاكرة (المتغيرات ، خصائص الفئة) بأي حال من الأحوال (هذا مهم!) دون التأثير عليهم ، ولكن اعتمادًا على قيمتها ، قم بإرجاع قيمة منطقية. لا تُرجع الإجراءات ذات القيمة ، ولكن يتم تغيير عناصر الذاكرة.
من التين. 2 ويترتب على ذلك أن نموذج الآلة الحاسبة ، مثل "الصندوق الأسود" ، يحتوي على أربع قنوات إدخال وسبع قنوات إخراج من حيث عدد المسندات والإجراءات. من السهل أن نرى أنه بالمقارنة مع الأوتوماتون المجرد ، والذي بحكم تعريفه لا يحتوي على أكثر من مدخلات واحدة وقناة إخراج واحدة ، فإن الأوتوماتون الهيكلي الذي يحتوي على العديد من القنوات هو أكثر عالمية ومرونة وملاءمة.

النموذج في التين. 2 يمكن تبسيطها بواسطة حالات "الإلتصاق" 1 و 2. للقيام بذلك ، تحتاج أولاً إلى تحويل الإضافات الأصلية إلى إنسان آلي. نحصل عليه من خلال تحميل الأقواس التي تدخل في حالة الإشارات بالإشارات التي تمثلها إشارات رؤوس الأوتوماتيكية مور. بعد ذلك ، تصبح عملية الإلتصاق ظاهرة. تظهر نتيجة لحالات الإلتصاق للحالة 2 ، والتي أصبحت الآن أولية ، في الشكل. 3.

الشكل 3. نتيجة التحول والإلتصاق لحالات الأوتوماتون في الشكل 2

شرح الإجراء y1 و nTypeButtons المتغير. في المجموع ، يقومون بتنفيذ بروتوكول يحاكي الأحداث. يحدد المتغير nTypeButtons نوع رموز الإدخال الخاصة بالتقسيم الآلي بتقسيمها إلى رموز رقمية ورموز العملية ورمز "إعادة التعيين" والرمز "متساوي". قيمتها مساوية للصفر تعني عدم وجود أحرف إدخال (لا يتم الضغط على أحد مفاتيح الحاسبة). بعد معالجة الرمز ، هذا يعني أيضًا أن رمز الإدخال يتم إدراكه تلقائيًا. هذا يمنع الاستجابة لحرف الإدخال.

يظهر رمز فئة الآلة الحاسبة التي تم إنشاؤها في إطار بيئة برمجة المكونات المرئية التلقائية (VKPa) [5] في القوائم 1 ، 2.

قائمة 1. رأس فئة FCalculator

#include "lfsaappl.h" enum Buttons { digit0 = 0, digit1, digit2, digit3, digit4, digit5, digit6, digit7, digit8, digit9, opPlus, opMinus, opCancel, opEqual, opNone }; class FCalculator : public LFsaAppl { public: void MooreAction(); LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FCalculator(pTAppCore, nameFsa, pCVarFsaLibrary); } FCalculator(TAppCore *pInfo, string strNam, CVarFsaLibrary *pCVFL); virtual ~FCalculator(void); public: void digitButtonPressed(int button); void operationButtonPressed(int button); private: void s1Entered(); void s2Entered(); void s3Entered(); void s3Exited(); void s5Entered(); void s5Exited(); private: int Rf, Rb; Buttons transitionButton, Op; int nTypeButtons; // 0 - none; 1 - digit button; 2 - operation button; void doOp(Buttons op); protected: int x1(); int x2(); int x3(); int x4(); void y1(); void y3(); void y5(); void y6(); void y7(); void y8(); void y9(); void y10(); int nState{2}; };

دعنا نفسر. في VKPa ، يرث أي فئة automaton خصائص فئة التشغيل التلقائي الأساسي LFsaAppl. تنشئ طريقة Create () نسخًا من الفئات المضمنة في المكتبات الديناميكية للعمليات التلقائية. تتداخل طريقة MooreAction () الافتراضية عند تحديد نموذج Moore الآلي ، وتحديد الإجراءات المرتبطة بحالات التشغيل التلقائي. تعتبر الأساليب x [n] و y [n] بمثابة المسندات والإجراءات المرتبطة بقنوات الإدخال / الإخراج الخاصة بالتلقائية. يتم تمثيل خوارزمية سلوك الفئة [التلقائية] من خلال جدول النقل (انظر قائمة 2) ، والذي يتكون من مجموعة من سلاسل من النوع LArc. يكرر باقي الكود رمز حاسبة الفئة المصدر.

القائمة 2. تنفيذ فئة FCalculator

 #include "stdafx.h" #include "FCalculator.h" #include "DlgCalculator.h" #include "ui_cdlgcalculator.h" static LArc TBL_Calculator[] = { //* LArc("1", "2","x1", "y1"), // [0-9] LArc("2", "1","x3", "y1"), // [c] LArc("2", "2","x1", "y1"), // [0-9] LArc("2", "3","x2", "y1"), // [+][-] LArc("3", "1","x3", "y3"), // [c] LArc("3", "3","x2", "y3"), // [+][-] LArc("3", "4","x1", "y3"), // [0-9] LArc("3", "5","x4", "y3"), // [=] LArc("4", "1","x3", "y1"), // [c] LArc("4", "3","x2", "y1"), // [+][-] LArc("4", "4","x1", "y1"), // [0-9] LArc("4", "5","x4", "y1"), // [=] LArc("5", "1","x3", "y5"), // [c] LArc("5", "2","x1", "y5"), // [0-9] LArc("5", "3","x2", "y5"), // [+][-] //*/ /* LArc("2", "2","x1", "y1y7"), // [0-9] LArc("2", "2","x3", "y1y6"), // [c] LArc("2", "3","x2", "y1y8"), // [+][-] LArc("3", "2","x3", "y3y6"), // [c] LArc("3", "3","x2", "y3y8"), // [+][-] LArc("3", "4","x1", "y3y7"), // [0-9] LArc("3", "5","x4", "y3y9"), // [=] LArc("4", "2","x3", "y1y6"), // [c] LArc("4", "3","x2", "y1y8"), // [+][-] LArc("4", "4","x1", "y1y7"), // [0-9] LArc("4", "5","x4", "y1y9"), // [=] LArc("5", "2","x3", "y5y6"), // [c] LArc("5", "2","x1", "y5y7"), // [0-9] LArc("5", "3","x2", "y5y8"), // [+][-] */ // LArc("1", "1","--", "y10"), // SWITCH LArc() }; FCalculator::FCalculator(TAppCore *pInfo, string strNam, CVarFsaLibrary *pCVFL): LFsaAppl(TBL_Calculator, strNam, nullptr, pCVFL) { pTAppCore = pInfo; Rf= 0; Rb = 0; Op = opNone; } FCalculator::~FCalculator(void) { } //   int FCalculator::x1() { if (nTypeButtons != 1) return false; else return true; } //   +, - int FCalculator::x2() { if (nTypeButtons == 0 || nTypeButtons != 2) return false; if (transitionButton != opCancel && transitionButton != opEqual ) return true; else return false; } //  Cancel int FCalculator::x3() { if (nTypeButtons == 0 || nTypeButtons != 2) return false; if (transitionButton == opCancel) return true; else return false; } //  opEqual int FCalculator::x4() { if (nTypeButtons == 0 || nTypeButtons != 2) return false; if (transitionButton == opEqual) return true; else return false; } void FCalculator::y1() { nTypeButtons = 0; } void FCalculator::y3() { s3Exited(); } void FCalculator::y5() { s5Exited(); } void FCalculator::y6() { s1Entered(); } // 1 void FCalculator::y7() { s2Entered(); } // 2, 4 void FCalculator::y8() { s3Entered(); } // 3 void FCalculator::y9() { s5Entered(); } // 5 void FCalculator::y10() { switch(nState) { case 2: if (x1()) { y1();y7(); } if (x3()) { y1();y6(); } if (x2()) { y1();y8(); nState = 3; } break; case 3: if (x3()) { y3();y6(); nState = 2; } if (x2()) { y3();y8(); } if (x1()) { y3();y7(); nState = 4; } if (x4()) { y3();y9(); nState = 5; } break; case 4: if (x3()) { y1();y6(); nState = 2; } if (x2()) { y1();y8(); nState = 3; } if (x1()) { y1();y7(); } if (x4()) { y1();y9(); nState = 5; } break; case 5: if (x3()) { y5();y6(); nState = 2; } if (x1()) { y5();y7(); nState = 2; } if (x2()) { y5();y8(); nState = 3; } break; } } void FCalculator::MooreAction() { // return; string strState = FGetState(); if (strState=="1") { y6(); } else if (strState=="2") { y7(); } else if (strState=="3") { y8(); } else if (strState=="4") { y7(); } else if (strState=="5") { y9(); } } /////////////////////////////////////////////////////////////////////////// void FCalculator::digitButtonPressed(int button) { transitionButton = static_cast<Buttons>(button); nTypeButtons = 1; } void FCalculator::operationButtonPressed(int button) { transitionButton = static_cast<Buttons>(button); nTypeButtons = 2; } void FCalculator::s1Entered() { Rf = 0; Rb = 0; Op = opNone; static_cast<CDlgCalculator*>(this->pCVarFSA->pVFsaDialog)->ui->lcdNumber->display(Rf); } void FCalculator::s2Entered() { if (Rf < 9999999) { Rf = Rf*10 + transitionButton; static_cast<CDlgCalculator*>(this->pCVarFSA->pVFsaDialog)->ui->lcdNumber->display(Rf); } } void FCalculator::s3Entered() { if (Rb != 0) { doOp(Op); static_cast<CDlgCalculator*>(this->pCVarFSA->pVFsaDialog)->ui->lcdNumber->display(Rf); } Rb = Rf; Op = transitionButton; } void FCalculator::s3Exited() { nTypeButtons = 0; if (transitionButton > digit9 && transitionButton < opCancel ) { doOp(transitionButton); Rb = 0; Op = transitionButton; static_cast<CDlgCalculator*>(this->pCVarFSA->pVFsaDialog)->ui->lcdNumber->display(Rf); } else { Rf = 0; } } void FCalculator::s5Entered() { doOp(Op); Op = opNone; Rb = Rf; // added by me static_cast<CDlgCalculator*>(this->pCVarFSA->pVFsaDialog)->ui->lcdNumber->display(Rf); } void FCalculator::s5Exited() { nTypeButtons = 0; if (transitionButton <= 9) { Rb = 0; Rf = 0; } } void FCalculator::doOp(Buttons op) { switch (op) { case opPlus: Rf = Rf + Rb; break; case opMinus: Rf = Rb - Rf; break; default: break; } }

لاحظ قائمة 2 يحتوي على ثلاثة جداول القفز (علق اثنين من خارج). هذه هي الطريقة التي تتحقق بها إمكانات التحكم المخصص عندما ، بعد إزالة التعليق ، يمكن تغيير سلوك الفصل "بالنقر" دون التأثير على أساليبه وخصائصه. تم تقديم طريقة y10 والخط المقابل في الجدول الانتقالي (راجع السطر المميز بالتعليق SWICH) لنمذجة تقنية SWITCH (انظر مزيد من التفاصيل عنها [9]) في إطار تقنية VKPa. في هذه الحالة ، يتم تصميم سلوك أي آلية تلقائية من خلال استدعاء دوري لمشغل SWITCH ، والذي يحاكي سلوك الأوتوماتون (هنا يعمل VKPa الآلي كبيئة خارجية).

3.2. نموذج الآلة الحاسبة السلبي

نموذج الآلة الحاسبة النشط يمسح باستمرار قنوات الإدخال. بمجرد أن تصبح قيمة nTypeButtons المتغيرة غير صفرية ، يعمل هذا كعلامة على وصول الرمز التالي إلى إدخال الإكمال التلقائي. نتيجة لذلك ، يتم تشغيل الانتقال والإجراء y1 ، وإعادة ضبط متغير nTypeButtons ، مما يحظر إعادة تشغيل الجهاز التلقائي بنفس الحرف.
على عكس نموذج "الحاسبة النشطة" ، لا يمكن لآلية الحدث ، بحكم تعريفها ، إعادة معالجة رمز إدخال. أصبح من الواضح الآن أن "أكبر الصعوبات في استخدام أسلوب automaton ... في أنظمة الأحداث" يبدو أنها تتوقف عن قمع نشاط آلية تلقائية نشطة وربط عملها بالأحداث. نعرض الإجراء الخاص بالتبديل إلى التشغيل التلقائي السلبي باستخدام مثال "الحاسبة النشطة" التي تم إنشاؤها للتو.
تحتوي بيئة VKPa على طريقة تشغيل خطوة بخطوة مقدمة لتصحيح أخطاء العمليات التلقائية. ولكن يمكن استخدامه لمحاكاة آلات الحدث. للقيام بذلك ، 1) قم بتعيين مساحة التشغيل التلقائي التي يتم وضع وضع التشغيل التلقائي فيها خطوة بخطوة (لاحظ ، ليس آلية فصل منفصلة ، ولكن المساحة التلقائية الكاملة التي تحتوي على automata) ، و 2) تتصل بلحظات حدوث الأحداث مع تنفيذ خطوة واحدة منفصلة من تشغيل الفضاء. توضح القائمة 3 كيفية القيام بذلك ، مما يعكس فقط التغييرات التي تم إجراؤها على النموذج (يظل رأس الفصل بدون تغيير).

قائمة 3. متغير في نهاية المطاف من فئة FCalculator

 static LArc TBL_Calculator[] = { LArc("st", "st","^x12", "y12"), // LArc("st", "1","x12", "y11"), // // ... }; ... //   bool FCalculator::FCreationOfLinksForVariables() { pNet = GetPointerToNet(); //    if (pNet) { string str = pNet->strName; //    //  -  pSV = this->pTAppCore->pSetVarSetting->GetAddressVar(const_cast<char*>(str.c_str())); } return true; } ... // int FCalculator::x12() { if (!pNet) return false; if (!pSV) return false; return true; } ... //    step-by-step void FCalculator::y11() { pSV->bIfStepByStep = true; } //   void FCalculator::y12() { FCreationOfLinksForVariables(); } // ... ///////////////////////////////////////////////////////////////////////////////////////////////////////////////// void FCalculator::digitButtonPressed(int button) { ... pSV->bIfStopAllTasks = false; //     } void FCalculator::operationButtonPressed(int button) { ... pSV->bIfStopAllTasks = false; //     } ...

هنا ، أولاً ، يتم تقديم حالة [أولية] إضافية ، يتم فيها التحقق من الإشارة إلى المساحة التي يوجد بها الجهاز ، والرابط الخاص بالكائن الذي يحدد خصائص المساحة (بما في ذلك وضع التشغيل). ايه يشكل عمل y12. عند تعيين الارتباطات ، يكون هناك انتقال إلى الحالة الأولية [السابقة] لنموذج الحاسبة مع تثبيت وضع التشغيل خطوة بخطوة لمساحة التشغيل التلقائي.

علاوة على ذلك ، يعمل النموذج في وضع التشغيل خطوة بخطوة. يؤدي تنفيذ خطوة واحدة إلى تنفيذ التعليمات البرمجية التي تم إدراجها في معالجات الأحداث المرتبطة بإدخال الحرف التالي (راجع قائمة 3 للتعرف على التغييرات التي تم إجراؤها على أساليب digitButtonPressed و operationButtonPressed).

4. لماذا؟

لماذا اخترع شيئًا ما ، إذا كان هناك ، كما يمكن الافتراض ، نموذج حدث أكثر تقدمًا لـ D. Harel. وكيفية التفكير بطريقة مختلفة إذا تم تشغيله في UML أو Stateflow أو في مكتبة Qt ، إلخ. إلخ وليس هناك الكثير من الذعر حول عيوبها. حسنًا ، دعوا أحداث الإشارات ، وحوّلوا الجهاز النشط إلى جهاز سلبي ... وإذا كان النموذج ، كما يقولون ، مكافئًا رسميًا أيضًا لماكينات ميل / مور الكلاسيكية ، فكيف لا نؤمن بها؟ وهكذا ، إذا كانت كل هذه التصريحات تؤخذ فقط على الإيمان ...

خذ لبداية الحدث (هذا هو بالضبط ما فعلناه أعلاه). يحتوي الهيكل التلقائي الكلاسيكي ، على سبيل المثال ، على العديد من قنوات الإدخال ، يرتبط كل منها بإشارة ، ويمكن معالجتها في وقت واحد / بالتوازي. لكن UML تقول أن "كل كائن يمكنه معالجة حدث واحد فقط في كل مرة" وحتى "إذا حدث حدثان في وقت واحد ، فإن الكائن سيظل يعالجها واحدًا تلو الآخر" [10]. وهكذا ، على مستوى التعريف ، تكون الإشارات والأحداث متكافئة ، ولكن ينهار المثيل في عملية تنفيذ التحولات النموذجية.

النظر في المثال الذي بدأت لاختبار / تعلم أي لغة أو تكنولوجيا. إنه يتعلق بتنفيذ البرنامج لنموذج العنصر AND-NOT. على المستوى الهيكلي ، يتوافق مع "الصندوق الأسود" ، الذي يحتوي على قناتين للدخل ومخرج واحد ، وعلى الخوارزمية ، الأوتوماتون الموضح في الشكل. 4.

التين. 4. نموذج آلي للعنصر وليس

كيف يمكن إنشاء نموذج إجرائي منتظم (انظر القائمة 4) أو كيفية تطبيق آلية في VKPa (انظر القائمة 5) أمر مفهوم ، ولكن كيفية تكرار هذا على أساس الحدث التلقائي لمكتبة كيو تي ليس واضحًا جدًا بسبب مشكلة تنفيذ الانتقال من الحالة "1" إلى الحالة "0" ، والتي تتطلب التحليل المتزامن للعديد من الأحداث.

القائمة 4. تنفيذ كائن النموذج الإجرائي AND-NOT

القائمة 4. تنفيذ كائن النموذج الإجرائي AND-NOT

 class INE { public: INE() {} ~INE(void); bool bX1, bX2, bY; bool f() { return bY = !(bX1&&bX2); } };

قائمة 5. تنفيذ كائن من النموذج التلقائي AND-NOT

 LArc T_INE[] = { LArc("s1", "s0", "x1x2", "y1"), LArc("s0", "s1", "^x1", "y2"), LArc("s0", "s1", "^x2", "y2"), }; class Ine : public LFsaAppl { public: Ine(string strNam = "-"): LFsaAppl(T_INE, strNam) {} ~Ine(void); bool bX1, bX2; protected: int x1() { return bX1; } int x2() { return bX2; } };

لذلك ، دع تطبيق نموذج الحدث لعنصر NAND في إطار فئات Qt automaton يكون "واجبات منزلية" للهابروفين. لا يمكنني إلا أن أذكر قرارها في Stateflow بأنه "كرز على الكعكة". يظهر في التين. 5. يتم استخدام الإغاثة Stateflow هنا ، والتي تسمح بعدم وضع علامة على الانتقال بحدث: إذا لم يتم تحديد اسم الحدث ، فسيحدث الانتقال عند حدوث أي حدث (انظر ملصق الانتقال في [13] للحصول على مثال).

التين. 5. نموذج آلي لعنصر AND-NOT في Stateflow

وبالتالي ، فإن آلات الحالة هي نموذج هجين (نشط غير نشط) للآلة. صحيح ، ليس واضحًا كيف سيتصرف الجهاز في حالة عدم وجود أي أحداث على الإطلاق. يمكن افتراض أنه "سيتجمد" تحسباً للأحداث. وإذا كانوا لن يكونوا؟ أي في النهاية ، لا يزال من غير المرجح أن يكون سلبيًا من طراز الجهاز النشط. على الرغم من أنه فقط في المظهر ، فإنه من الصعب التمييز عن الأخير.

5. الخاتمة

فيما يتعلق بالأحداث ، يمكننا القول أنه نظرًا للنشاط ، فإن تطبيق النموذج الكلاسيكي للأوتوماتية يبدو أفضل من نموذج الأوتوماتة المتزامنة. إذا تحدثنا عن البرمجة التلقائية بشكل عام ، فإن حزمة امتداد Stateflow توضح نوع البرمجة المختلفة تمامًا. ولكن لسوء الحظ ، حتى الآن فقط في المنظور ، ل تبقى المشاكل بسبب نموذج Stateflow الحسابي ، الذي يظل بشكل أساسي رسم تخطيطي للكتلة. يبدو أنه لهذه الأسباب بالتحديد ، بالإضافة إلى الأتمتة ، يتم تمثيل البرمجة المرئية في Statefow بترميز المخططات الانسيابية.

إن معرفة مكان البرمجة التلقائية الحقيقية وأين يكون تقليدها هو أحد أهدافنا الرئيسية. في المقالة السابقة [5] ، حللنا إحدى المهام الأساسية التي تم طرحها - قمنا بصياغة مفهوم برامج التشغيل التلقائي. بعد ذلك ، تحتاج إلى التعامل مع تعريف نموذج إدارة البرنامج الذي يجب أن يكون آليًا محدودًا وأن يكون فعالًا وملائمًا للمبرمجين.

بعد التعامل مع الأحداث ، وضعنا الأساس لمثل هذا العمل. في مقالات أخرى ، سوف نفهم بالفعل تفاصيل النموذج الذي اقترحه د. هاريل. مع تقدمنا قليلاً ، نقول ذلك ، بعبارة صريحة ، شوهت فهم الأتمتة. ولكن ، من ناحية أخرى ، هنا يجب أن نعطيها استحقاقها ، كشفت عن مشكلات لن تسمح ، بدونها ، بتكوين برمجة تلقائية فعالة في إطار النموذج الكلاسيكي الذي من شأنه جذب المبرمجين.

لقد اكتشفنا أعلاه أنه ، على الأقل ، على مستوى الحدث ، لا توجد مشاكل في الأتمتة الكلاسيكية. سوف نفهم أكثر ... في غضون ذلك ، هذه ليست سوى البداية. نحن ننتظر الكثير من الأشياء المثيرة للاهتمام ، ولاحظ أننا لا نتجاوز النظرية الكلاسيكية للآلات. هذا أمر بالغ الأهمية إذا كنا نريد البرمجة الآلية حقا. نتمنى لك التوفيق :)

مراجع

1. بوروفسكي أي. Qt4.7. البرمجة العملية C ++. - SPB.: BHV-Petersburg، 2012 .-- 496 p.
2. BUCH G. ، RAMBO J. ، جاكوبسون I. UML. دليل المستخدم. الطبعة الثانية. أكاديميا آي تي: موسكو ، 2007 .-- 493 صفحة.
3. Shalyto A. A. محاضرة جديدة عن البرمجة التلقائية. 2019 ، [المورد الإلكتروني] ، وضع الوصول: www.youtube.com/watch؟v=PPWTxceMutk&feature=youtu.be ، مجانًا. الجاز. روس. (تاريخ العلاج 5 ديسمبر 2019).
4. Stateflow. www.mathworks.com/products/stateflow.html ، مجاني. الجاز. المهندس (تاريخ التداول 7.01.2020).
5. آلة تورينج ، كنموذج لبرامج التشغيل الآلي. habr.com/en/post/481998 ، مجانًا. الجاز. روس. (تاريخ التداول 7.01.2020).
6. مليخوف إيه. الرسوم البيانية الموجهة وآلات الدولة المحدودة. - م: نوكا ، 1971. - 416 ص.
7. KUDRYAVTSEV VB ، Aleshin S.V. ، PODKOLZIN A.S. مقدمة لنظرية الأتمتة - م: العلوم. الفصل. إد. الخيال العلمي. مضاءة ، 1985 .-- 320 ص.
8. توكيل ن. آي. ، شاليتو أ. تنفيذ automata عند برمجة أنظمة الأحداث. "مبرمج" ، 2002. رقم 4. C.74-80.
9. Polikarpova N. ، A. Shalyto A. Automaton البرمجة. 2nd ed.، St. Petersburg.: Peter، 2011 .-- 176 p.
10. رامبو J. ، جاكوبسون أ. ، بوتش جي. أم أل: مرجع خاص. - سانت بطرسبرغ: بيتر ، 2002. - 656 صفحة.
11. غوما H. UML. تصميم النظم في الوقت الحقيقي ، والتطبيقات المتوازية والموزعة: لكل. من الانجليزية - M: DMK Press ، 2002. - 2002. - 704 p.
12. SHALYTO A.A. تبديل التكنولوجيا. خوارزميات وبرمجة مهام التحكم المنطقي. سانت بطرسبرغ: نوكا ، 1998.628 ق.
13. روجاتشيف جي. تدوينات الحالة. bourabai.kz/cm/stateflow13.htm ، مجاني. الجاز. روس. (تاريخ الاستئناف 01.10.2020).

هل يعد الإضافات حدثًا؟