في الجزء الأول ، حاولت أن أوضح أن قطة OOP سوداء في غرفة مظلمة من اللغات الرسومية موجودة ، حتى لو لم تكن قطة ، ولكن قطة نصف ميتة من قشارة Schroedinger ، أي أنها ليست كذلك. تم عرض مثال على تنفيذ منهجية البرمجة الموجهة للكائنات ، عندما لا يكون البرنامج C ++ أو كود Java ، ولكن مخطط Simulink أو SimInTech أو SimulationX أو SCADE Esterel - أي تدوين رسومي لوصف الخوارزمية.
في المواد الإعلانية ، يستخدم Matlab Simulink مصطلح MOS - التصميم القائم على النموذج. في العديد من النصوص ، يشددون على أن الرسم البياني للخوارزمية هو نموذج ، وهذا صحيح بالطبع. ومع ذلك ، في التعريف الأولي لـ MOS ، يكون النموذج في المقام الأول هو نموذج الكائن الذي تم تطوير نظام التحكم به ، بما في ذلك برنامج التحكم. يوصف المزيد من منهجية MOS هنا. وبالتالي ، عند تطوير نظام التحكم وفقًا لمنهجية MOS ، من الممكن والضروري استخدام منهجية OOP لتطوير برامج الإدارة. ولإغلاق المشكلة تمامًا مع الطرز ، إليك صورة بها اختلافات أحدها عن الآخر. إذا كان كل شيء واضحًا ، فلا يمكنك القراءة.
دعنا نعود إلى اللغات الرسومية و OOP كما هو مطبق في برامج التحكم للصناعة. توفر لغة البرمجة الرسومية سجل برنامج في شكل رسم تخطيطي من مجموعة من الكتل المتصلة بخطوط الاتصال. كقاعدة عامة ، في البرمجة الصناعية ، يتم إنشاء رمز للمترجم والتحميل اللاحق في المعدات المستهدفة من دائرة رسوم بيانية بواسطة مولد رمز تلقائي.
كجزء من تخصصي ، اضطررت للعمل مع إدارة البرامج لمحطات الطاقة النووية حيث يُحظر استخدام C ++ مع معايير السلامة ، فقط C النقي ، وفي بعض الحالات لا حتى C ، ولكن المنطق "الحديد" ، حيث يتم تنفيذ الخوارزميات كدوائر إلكترونية على الترانزستورات و تتابع. ويتم مراقبة احترام المعايير من قبل رجال الرقابة القاسية.
لكن هنا ، بغض النظر عن مدى دهشتها ، لا يزال التطوير يستخدم منهجية OOP. لأنه عندما لا يمكنك استخدام OOP ، لكنك تريد ذلك بالفعل ، يمكنك ذلك. صحيح ، إذن يجب إعادة كل شيء ، ولن يكون أي C ++ والرمز النهائي ، لمعايير السلامة و über alles. كما يقولون ، لأكل سمكة ، وليس للجلوس عن الانتهاكات.
لجعل كائن حقيقي من خلال تعريف OOP ، نحن نربط هياكل البيانات ومعالجة المخططات في كائن واحد ، وهذا ما يسمى التغليف. ولأننا لا نستطيع استخدام C ++ لأنظمة NPP الموثوقة ، يجب علينا تحليل كل هذا عند إنشاء الكود. كما هو موضح في التعليقات على المقال السابق ، فإن أول مترجم C ++ Front يعمل بنفس الطريقة ، فقد ترجم رمز OOP C ++ إلى C النقي.
في الإصدار الأول من تنفيذ OOP بلغة رسومية ، أنشأنا كتلة خاصة تحتوي على نظام حساب رسومية. أثناء التهيئة ، ربط هذا الكتلة مخطط الفصل (الطريقة) بـ "مثيل فئة" معين - مجموعة من المتغيرات المسماة بطريقة خاصة.
النظر في التجسيد الثاني لمنهجية OOP في لغات البرمجة الرسومية. يوضح الشكل 1 تشغيل خوارزمية معالجة المستشعر.
الشكل 1. برنامج معالجة الاستشعار.
هذه هي طريقة الصف. يتوافق مع الفئة الخاصة به "مجسات" في قاعدة البيانات - فئة مجردة مع مجموعة معينة من الحقول ومثيل لمستشعر فئة KBA31CFO1 المحدد. بالنسبة لهذا المستشعر ، تحتوي الحقول على قيم محددة ، ويتم تعيين بعض الحقول بواسطة المستخدم ، ويتم حساب بعض الحقول أثناء تنفيذ البرنامج. انظر الموافقة المسبقة عن علم 2
الشكل 2. قاعدة بيانات إشارة مع فئة مفتوحة "الاستشعار".
حتى الآن ، كل شيء كما في النموذج الأول ، حيث قمنا بتشكيل ربط مخطط التصميم بمستشعر محدد عند تثبيت الوحدة على الدائرة. "أين هو الفرق؟" - أنت تسأل. والفرق هو داخل الكتلة. إذا كان هناك في الإصدار الأول مخطط تصميم بداخله ، والذي تم نسخه مع كل تثبيت للكتلة ، فإن الشكل الداخلي في هذا الإصدار يبدو كما يلي:
الشكل 3. الشكل الداخلي للكتلة مثيل مثيل فئة.
بدلاً من مخطط التصميم ، يتم فقط "نقل" نقل البيانات واستقبالها داخل الكتلة.
ويتم الحساب نفسه في مكان آخر ، في الرسم البياني من الشكل 1. في بعض الحالات ، من الممكن عدم استخدام الكتل على الإطلاق في الرسم التخطيطي للحساب ، يكفي وجود مثيلات لفئة المستشعر في قاعدة بيانات الفردي. هذه هي الطريقة الثانية لتطبيق التغليف بلغات الرسوم. الحيلة هي أن جميع الكتل في الرسم البياني للشكل 1 هي ناقلات ، وأنها لا تعالج إشارة واحدة ، ولكن ناقلات الإشارات من جميع أجهزة الاستشعار من هذا النوع في مخطط الحساب. إذا قمت بتمكين وضع عرض النتائج على خط الاتصال ، فسنرى أن كل خط اتصال لا يحتوي على رقم واحد ، ولكن متجه يتكون من 4 أرقام (وفقًا لعدد أجهزة الاستشعار في قاعدة البيانات).
الشكل 4. رسم تخطيطي لمعالجة إشارة أجهزة الاستشعار في وضع عرض القيم.
وبالتالي ، ينفذ نظام معالجة واحد معالجة جميع المستشعرات في المشروع ، حيث تتم معالجة كل مستشعر بمعلماته المحددة في قاعدة البيانات كخصائص لحالة معينة من الفصل. على سبيل المثال ، يأخذ المحدد الحد الأقصى للقيمة من قاعدة البيانات ، والتي تم ضبطها على المستشعرات الثلاثة الأولى وتختلف عن الرابعة. (انظر الشكل 5)
الشكل 5. معلمات كتلة المحدد في مخطط الحساب.
وماذا عن الكود الناتج ، الذي يتم إنشاؤه تلقائيًا وفقًا لهذا المخطط الرائع ، كيف يمكنك أن تتفادى تحف OOP؟ الأمر بسيط: لا غش ولا OOP ، C نقي في الكود. لكل كتلة من مخطط معالجة المتجهات ، سيتم تشكيل دورة توفر أكبر عدد ممكن من العمليات الحسابية كما توجد مثيلات فئة في المشروع. في حالتنا ، هناك 4 أجهزة استشعار ، لذلك نقوم أولاً بتكوين صفائف من البعد "4" من خلال قراءة الإشارات من أجهزة الاستشعار:
}; state_vars->kbastdv104_out_0_[0] = kba31cf001_mf_type; state_vars->kbastdv104_out_0_[1] = kba32cf001_mf_type; state_vars->kbastdv104_out_0_[2] = kba33cf001_mf_type; state_vars->kbastdv104_out_0_[3] = uf40y329084320_mf_type
ثم نقوم بفرز كل الكتل بالترتيب وتشغيلها في حلقة. لكل عنصر من عناصر مجموعة من الأنواع ، سيتم تنفيذ كل مجموعة من الحسابات لجميع أجهزة الاستشعار.
for(i=0;i<4;i++){ locals->v211_out_0_[i] = state_vars->kbastdv125_out_0_[i] && (!(locals->v191_out_7_[i] > 0.5)); locals->v209_out_2_[i] = consts->kbastdv121_a_[i]*state_vars->kbastdv127_out_0_[i]; locals->v209_out_3_[i] = (1)*consts->kbastdv122_a_[i]+(1)*locals->v209_out_2_[i]; … }
بعد الحساب ، نسجل الإشارات لكل مثيل من الفصل:
kba31cf001_mf_xb01 = state_vars->kbastdv207_out_0_[0]; kba32cf001_mf_xb01 = state_vars->kbastdv207_out_0_[1]; kba33cf001_mf_xb01 = state_vars->kbastdv207_out_0_[2]; uf40y329084320_mf_xb01 = state_vars->kbastdv207_out_0_[3];
كما ترون ، لا توجد كائنات في الرمز النهائي. نظيفة وبريئة وآمنة SI. في المثال أعلاه ، فإن تنفيذ OOP بلغة رسومية ، تحسب الدائرة المتجهية جميع المستشعرات من نفس النوع. تتيح لك هذه التقنية تغيير مخطط واحد لتغيير معالجة جميع أجهزة الاستشعار.
فائدة إضافية أخرى لهذا النهج هو التأمين ضد الأخطاء. تخيل: قمت بإضافة جهاز استشعار يدويًا وفي مكان واحد نسيت زيادة التكرار أثناء المعالجة في دورة ما. لن يتمكن أي من محلل الكود الثابت من اكتشاف هذا الخطأ ، فهذا الرمز صحيح. وحتى في العمل قد لا يؤثر هذا على الفور وبشكل واضح.
حسنًا ، في النهاية ، تعدد الأشكال والميراث الموعود به. في الطريقة الأولى ، تلقى المستخدم العديد من المخططات المتطابقة ، والتي يمكنه تحريرها بعد تثبيت كتلة الباطن ، وبالتالي تنفيذ تعدد الأشكال ، وتغيير سلوك مثيل معين من الفصل. أعتقد أن الجميع خمنوا أنه من الممكن تغيير نظام المعالجة لجهاز استشعار معين ، وسوف نحصل على فئة جديدة مع الحقول التي تتطابق ، ولكن الأساليب مختلفة. يمكنك أيضًا إضافة حقول جديدة والحصول على فصل جديد به حقول مختلفة تحتوي على جميع حقول الأصل وأساليب الأصل.
يوضح الشكل 6 مثال على كتلتين من فئات "الوالد" و "الوريث". داخل الكتلة ، يتم حفظ نظام حساب الفئة الأصل. جميع البيانات تذهب إلى كتلة ناقلات شائعة ، على غرار الكتلة في الشكل. 4. تتكرر طريقة الفئة الأصل تمامًا. ومن ثم تحتوي الفئة اللاحقة على حقل إضافي Yatm وإعادة حساب إضافية للقيمة باستخدام كتلة الاستيفاء الخطي.
وبالتالي ، يظل من الممكن تغيير أساليب معالجة الوالد ، والتي سوف تتغير في جميع ورثة الفصول ، وكذلك تخصيص سلوك الوريث بشكل فردي.
الشكل 6. الشكل. تعدد الأشكال في ورثة الصف.
للتلخيص ، يمكننا القول بأن منهجية OOP يمكن استخدامها لإنشاء برامج بلغات البرمجة الرسومية. التجريد ، التغليف ، الميراث ، تعدد الأشكال - كل هذه المبادئ يتم تنفيذها بسهولة وبشكل طبيعي بواسطة أدوات التطوير الصحيحة. من المهم ملاحظة أن الرمز النهائي ، بعد الإنشاء التلقائي من لغة الرسوم ، يظل آمنًا تمامًا C دون أي OOP
في بعض الحالات ، لا تكون نتيجة تطوير برنامج التحكم في شكل رسوم بيانية هي رمز C للتحميل في وحدات التحكم ، ولكن مخطط الدائرة "المنطق الحديدي" ، ولكن التقنية الموضحة أعلاه تعمل بشكل جيد أيضًا.