ग्राफिकल प्रोग्रामिंग भाषाओं में ओओपी। भाग 2 MOS और OOP

पहले भाग में, मैंने यह दिखाने की कोशिश की कि ग्राफिक भाषाओं के एक अंधेरे कमरे में एक काली ओओपी बिल्ली मौजूद है, भले ही वह बिल्ली नहीं है, लेकिन श्रोडिंगर परत की एक आधी मृत बिल्ली है, जो कि है, यह नहीं है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग की कार्यप्रणाली के कार्यान्वयन का एक उदाहरण दिखाया गया था, जब कोई प्रोग्राम C ++ या Java कोड नहीं है, लेकिन एक Simulink, SimInTech, सिम्युलेशन या SCADE एस्टरेल आरेख - एल्गोरिथम विवरण का कोई ग्राफिकल अंकन।

विज्ञापन सामग्रियों में, मतलाब सिमुलिंक अक्सर एमओएस - मॉडल-आधारित डिज़ाइन शब्द का उपयोग करते हैं। कई ग्रंथों में, वे इस बात पर जोर देते हैं कि एल्गोरिथम का चित्रमय आरेख एक मॉडल है, जो निश्चित रूप से सच है। हालांकि, एमओएस की प्रारंभिक परिभाषा में, मॉडल मुख्य रूप से उस वस्तु का मॉडल है जिसके लिए नियंत्रण प्रणाली विकसित की जाती है, जिसमें नियंत्रण सॉफ्टवेयर भी शामिल है। अधिक MOS कार्यप्रणाली यहाँ वर्णित है। इस प्रकार, जब एमओएस कार्यप्रणाली के अनुसार एक नियंत्रण प्रणाली विकसित करना, प्रबंधन सॉफ्टवेयर के विकास के लिए ओओपी पद्धति का उपयोग करना संभव और आवश्यक है। और मॉडल के साथ समस्या को पूरी तरह से बंद करने के लिए, यहां एक से दूसरे के मतभेदों के साथ एक तस्वीर है। यदि सब कुछ स्पष्ट है, तो आप अब नहीं पढ़ सकते हैं।

उद्योग के नियंत्रण कार्यक्रमों के लिए लागू की गई ग्राफ़िकल भाषाओं और OOP पर लौटते हैं। चित्रमय प्रोग्रामिंग भाषा संचार लाइनों द्वारा जुड़े ब्लॉकों के एक सेट से आरेख के रूप में एक कार्यक्रम रिकॉर्ड प्रदान करती है। एक नियम के रूप में, औद्योगिक प्रोग्रामिंग में, कंपाइलर और बाद में लक्ष्य उपकरण में लोड करने के लिए एक कोड एक स्वचालित कोड जनरेटर द्वारा ग्राफिक सर्किट से बनाया जाता है।

मेरी विशेषता के हिस्से के रूप में, मुझे परमाणु ऊर्जा संयंत्रों के लिए सॉफ्टवेयर के प्रबंधन के साथ काम करना था, जहां सुरक्षा मानकों के साथ सी ++ का उपयोग करने के लिए मना किया जाता है, केवल शुद्ध सी, और कुछ मामलों में भी सी नहीं, लेकिन "लोहा" तर्क, जहां एल्गोरिदम ट्रांजिस्टर पर इलेक्ट्रॉनिक सर्किट पर लागू होते हैं और रिले। और मानकों के पालन की निगरानी कठोर लोगों द्वारा की जाती है।

लेकिन यहां, कोई फर्क नहीं पड़ता कि यह कितना आश्चर्यजनक लग सकता है, विकास अभी भी ओओपी पद्धति का उपयोग कर रहा है। क्योंकि जब आप OOP का उपयोग नहीं कर सकते, लेकिन वास्तव में करना चाहते हैं, तो आप कर सकते हैं। सच है, तो सब कुछ वापस करने की आवश्यकता है, और यह कोई सी ++ और अंतिम कोड नहीं होगा, सुरक्षा और über सहयोगी मानकों के लिए। जैसा कि वे कहते हैं, मछली खाने के लिए, और उल्लंघन के लिए बैठने के लिए नहीं।

OOP की परिभाषा द्वारा एक वास्तविक वस्तु बनाने के लिए, हम डेटा संरचनाओं और प्रसंस्करण योजनाओं को एक ही ऑब्जेक्ट में बांधते हैं, इसे एनकैप्सुलेशन कहा जाता है। और चूंकि हम विश्वसनीय एनपीपी सिस्टम के लिए C ++ का उपयोग नहीं कर सकते हैं, हमें कोड बनाते समय यह सब पार्स करना चाहिए। जैसा कि पिछले लेख की टिप्पणियों में बताया गया है, पहले C ++ Front संकलक ने उसी तरह से काम किया, इसने OOP C ++ कोड को शुद्ध C में अनुवाद किया।

ग्राफिकल भाषा में ओओपी के कार्यान्वयन के पहले संस्करण में , हमने एक विशेष ब्लॉक बनाया जिसमें एक ग्राफिकल गणना योजना थी। आरंभीकरण के दौरान, यह ब्लॉक क्लास स्कीम (विधि) को एक विशिष्ट "क्लास उदाहरण" के लिए बाध्य करता है - एक विशेष तरीके से नामित चर का एक सेट।

ग्राफिकल प्रोग्रामिंग भाषाओं में OOP कार्यप्रणाली के दूसरे अवतार पर विचार करें। चित्रा 1 सेंसर प्रसंस्करण एल्गोरिथ्म के संचालन को दर्शाता है।

चित्रा 1. सेंसर प्रसंस्करण कार्यक्रम।

यह एक वर्ग विधि है। यह डेटाबेस में अपनी श्रेणी "सेंसर" से मेल खाती है - खेतों के दिए गए सेट के साथ एक सार वर्ग और KBA31CFO1 वर्ग विशिष्ट सेंसर का एक उदाहरण है। इस सेंसर के लिए, क्षेत्रों में विशिष्ट मूल्य हैं, कुछ फ़ील्ड उपयोगकर्ता द्वारा निर्धारित किए जाते हैं, कुछ फ़ील्ड की गणना कार्यक्रम के निष्पादन के दौरान की जाती है। तस्वीर देखें 2

चित्रा 2. खुली श्रेणी "सेंसर" के साथ सिग्नल डेटाबेस।

अब तक, सब कुछ पहले अवतार में है, जहां हमने सर्किट पर यूनिट स्थापित करते समय एक विशिष्ट सेंसर के लिए डिजाइन योजना के बंधन का गठन किया। "अंतर कहां है?" - आप पूछें। और अंतर ब्लॉक के अंदर है। अगर पहले संस्करण में एक डिज़ाइन आरेख था, जिसे ब्लॉक की प्रत्येक स्थापना के साथ कॉपी किया गया था, तो इस संस्करण में अंदर कुछ इस तरह दिखता है:

चित्रा 3. एक वर्ग उदाहरण के एक ब्लॉक उदाहरण के अंदरूनी।

डिज़ाइन योजना के बजाय, केवल डेटा ट्रांसमिशन और रिसेप्शन ब्लॉक के अंदर "दिखाया गया" है।
और गणना स्वयं चित्रा 1 से आरेख में कहीं और होती है। कुछ मामलों में, गणना आरेख में ब्लॉकों का उपयोग नहीं करना संभव है, यह एकल डेटाबेस में संवेदक वर्ग के उदाहरणों के लिए पर्याप्त है। ग्राफिक भाषाओं में एनकैप्सुलेशन को लागू करने का यह दूसरा तरीका है। चाल यह है कि चित्र 1 के आरेख के सभी ब्लॉक सदिश हैं, और वे एक संकेत नहीं, बल्कि गणना योजना में इस प्रकार के सभी सेंसर से संकेतों के एक वेक्टर की प्रक्रिया करते हैं। यदि आप संचार लाइन पर परिणाम प्रदर्शित करने के मोड को सक्षम करते हैं, तो हम देखेंगे कि प्रत्येक संचार लाइन में एक अंक नहीं है, लेकिन 4 नंबर का एक वेक्टर (डेटाबेस में सेंसर की संख्या के अनुसार) है।

चित्रा 4. देखने के मूल्यों के मोड में सेंसर के संकेत को संसाधित करने का आरेख।

इस प्रकार, एक प्रसंस्करण योजना परियोजना में सभी सेंसर के प्रसंस्करण को लागू करती है, प्रत्येक संवेदक को डेटाबेस में निर्दिष्ट अपने स्वयं के मापदंडों के साथ संसाधित किया जाता है, वर्ग के एक विशेष उदाहरण की विशेषताओं के रूप में। उदाहरण के लिए, सीमक डेटाबेस से अधिकतम मूल्य लेता है, जो पहले तीन सेंसर के लिए समान है और चौथे के लिए अलग है। (अंजीर देखें। 5)

चित्रा 5. गणना योजना में सीमक ब्लॉक के पैरामीटर।

और परिणामस्वरूप कोड के बारे में क्या है, जो इस अद्भुत योजना के अनुसार स्वचालित रूप से उत्पन्न होता है, आप ओओपी कलाकृतियों से बचने का प्रबंधन कैसे करते हैं? यह सरल है: कोड में कोई धोखा और कोई ओओपी नहीं, शुद्ध सी। वेक्टर प्रसंस्करण योजना के प्रत्येक ब्लॉक के लिए, एक चक्र का गठन किया जाएगा जो परियोजना में कक्षा के उदाहरण के रूप में कई गणना प्रदान करता है। हमारे मामले में, 4 सेंसर हैं, इसलिए हम पहले सेंसर से संकेतों को पढ़कर आयाम "4" के एरेज़ बनाते हैं:

/* Index=104 UID=104 GeneratorClassName=TSignalReader Name=buz1.sensor.Macro6.Macro3.Macro157.SignalReader3 Type=    */ }; 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 

फिर हम सभी ब्लॉकों को क्रम में क्रमबद्ध करते हैं और उन्हें एक लूप में चलाते हैं। एक प्रकार की सरणी के प्रत्येक तत्व के लिए, गणना का प्रत्येक ब्लॉक सभी सेंसर के लिए किया जाएगा।

 /* Index=211 UID=211 GeneratorClassName=TAndSrc Name=buz1.sensor.Macro6.And61 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)); /* Index=212 UID=212 GeneratorClassName=TMulDbl Name=buz1.sensor.Macro6.Mul_oper1 Type= */ locals->v209_out_2_[i] = consts->kbastdv121_a_[i]*state_vars->kbastdv127_out_0_[i]; /* Index=213 UID=213 GeneratorClassName=TSumSrc Name=buz1.sensor.Macro6.Add_oper1 Type= */ locals->v209_out_3_[i] = (1)*consts->kbastdv122_a_[i]+(1)*locals->v209_out_2_[i]; … } 

गणना के बाद, हम कक्षा के प्रत्येक उदाहरण के लिए संकेत रिकॉर्ड करते हैं:

 /* Index=776 UID=776 GeneratorClassName=TSignalWriter Name=buz1.sensor.Macro6.Macro3.SignalWriter4 Type=    */ 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]; 

जैसा कि आप देख सकते हैं, अंतिम कोड में कोई ऑब्जेक्ट नहीं हैं। स्वच्छ, निर्दोष और सुरक्षित एसआई। उपरोक्त उदाहरण में, ग्राफिक भाषा में ओओपी का कार्यान्वयन, एक वेक्टर सर्किट एक ही प्रकार के सभी सेंसर की गणना करता है। यह तकनीक आपको सभी सेंसर के प्रसंस्करण को बदलने के लिए एक योजना को बदलने की अनुमति देती है।

इस दृष्टिकोण का एक और जोड़ा लाभ त्रुटि बीमा है। कल्पना करें: आप मैन्युअल रूप से एक सेंसर जोड़ते हैं और एक जगह आप एक चक्र में प्रसंस्करण के दौरान पुनरावृत्ति की संख्या में वृद्धि करना भूल गए। कोई भी स्थिर कोड विश्लेषक इस त्रुटि का पता लगाने में सक्षम नहीं होगा, कोड सही है। और यहां तक ​​कि काम पर यह तुरंत और स्पष्ट तरीके से प्रभावित नहीं हो सकता है।

खैर, अंत में, वादा किया बहुरूपता और विरासत। पहली विधि में, उपयोगकर्ता को कई समान योजनाएं मिलीं, जिसे वह सबमॉडल ब्लॉक को स्थापित करने के बाद संपादित कर सकता है, और इस तरह, वर्ग के एक विशेष उदाहरण के व्यवहार को बदलते हुए बहुरूपता को बाहर निकालता है। मुझे लगता है कि सभी ने अनुमान लगाया कि किसी विशेष सेंसर के लिए प्रसंस्करण योजना को बदलना संभव है, और हमें एक नया वर्ग मिलेगा जिसमें समान फ़ील्ड हैं, लेकिन विधियां अलग हैं। आप नए क्षेत्रों को भी जोड़ सकते हैं और माता-पिता के सभी क्षेत्रों और माता-पिता के तरीकों वाले विभिन्न क्षेत्रों के साथ एक नया वर्ग प्राप्त कर सकते हैं।

चित्रा 6 "माता-पिता" और "वारिस" वर्गों के दो ब्लॉकों का एक उदाहरण दिखाता है। ब्लॉक के अंदर, मूल श्रेणी गणना योजना बचाई गई है। सभी डेटा अंजीर में ब्लॉक के समान एक सामान्य वेक्टर ब्लॉक में जाता है। 4. मूल वर्ग विधि पूरी तरह से दोहराई जाती है। और फिर उत्तराधिकारी वर्ग के पास एक अतिरिक्त फ़ील्ड Yatm और रैखिक प्रक्षेप प्रक्षेप का उपयोग करके मूल्य का एक अतिरिक्त पुनर्गणना है।

इस प्रकार, माता-पिता के प्रसंस्करण के तरीकों को बदलना संभव है, जो सभी वर्गों-वारिस में बदल जाएगा, साथ ही साथ व्यक्तिगत रूप से वारिस के व्यवहार को भी अनुकूलित करेगा।

चित्रा 6. वर्ग उत्तराधिकारियों में बहुरूपता।

संक्षेप में, हम तर्क दे सकते हैं कि OOP पद्धति का उपयोग ग्राफिकल प्रोग्रामिंग भाषाओं में सॉफ्टवेयर बनाने के लिए किया जा सकता है। अमूर्तता, एनकैप्सुलेशन, विरासत, बहुरूपता - ये सभी सिद्धांत आसानी से और स्वाभाविक रूप से सही विकास साधनों द्वारा कार्यान्वित किए जाते हैं। यह ध्यान रखना महत्वपूर्ण है कि एक ग्राफिक भाषा से स्वचालित पीढ़ी के बाद अंतिम कोड, किसी भी OOP के बिना शुद्ध सुरक्षित रहता है

कुछ मामलों में, नियंत्रण सॉफ्टवेयर को चित्रमय रूप में विकसित करने का परिणाम नियंत्रकों में लोड करने के लिए सी कोड नहीं है, लेकिन सर्किट आरेख "लौह तर्क" है, लेकिन ओओपी के ऊपर वर्णित तकनीक भी ठीक काम करती है।