प्रोग्रामिंग में भूमिका आधारित सूचना मॉडलिंग

प्रस्तावना

यह लेख 2010 के लिए एजुकेशनल टेक्नोलॉजीज जर्नल में प्रकाशित हुआ था। चूंकि, मेरी राय में, प्रोग्रामिंग को सिखाना प्रोग्रामिंग से कम महत्वपूर्ण नहीं है, मैंने इसे हैबर के लिए अनुकूलित करने का निर्णय लिया। इसमें, मैंने "क्यों?" प्रश्न का उत्तर देने का प्रयास किया। मुझे आशा है कि यह न केवल नौसिखिए प्रोग्रामर के लिए उपयोगी होगा, बल्कि पहले से ही आदरणीय गुरु भी होंगे। अगर मैं आपकी रुचि कर सकता हूं, तो कृपया बिल्ली के नीचे स्वागत करें।

संक्षिप्त स्वभाव

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

समस्या का स्रोत

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

हम एक उदाहरण के साथ उपरोक्त वर्णन करते हैं। पुनरावृत्ति का उपयोग करके विषम संख्या n के लिए डबल फैक्टरियल की गणना के लिए एक प्रोग्राम लिखना आवश्यक है। स्मरण करो कि एक डबल फैक्टरियल एन के रूप में एक ही समानता के सभी प्राकृतिक संख्याओं का उत्पाद है, एन तक समावेशी।

इस समस्या के समाधानों में से एक निम्नलिखित पास्कल कार्यक्रम होगा (स्वाभाविक रूप से, मुझे पता है कि कार्यक्रम n> 21 के लिए काम नहीं करेगा, हालांकि, सामान्यता को तोड़े बिना, इसे एक उदाहरण के रूप में इस्तेमाल किया जा सकता है):

 कार्यक्रम oddfactorial;
 crt का उपयोग करता है;
 var n: पूर्णांक;
 समारोह एफ (एन: पूर्णांक): लंबे समय तक;
 शुरू करना
	 अगर n = 1 तो F: = 1
	 अन्यथा 
	 अगर n = 3 तो F: = 3
	 और एफ: = एन * एफ (एन -2);
 अंत;
 शुरू करना
	 ClrScr;
	 दोहराना
		 Readln (n);
	 जब तक विषम (n);
	 लिखो (F (n));
	 readln;
 अंत।

निदान

डेवलपर के दृष्टिकोण से, यह कार्यक्रम पूरी तरह से कार्य को हल करता है, हालांकि, अगर हम उपयोगकर्ता के दृष्टिकोण से समाधान का विश्लेषण करते हैं, तो प्रस्तावित विकल्प को अंतिम रूप देने की आवश्यकता होगी।

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

 कार्यक्रम oddfactorial;
 crt का उपयोग करता है;
 var n: पूर्णांक;
 समारोह एफ (एन: पूर्णांक): लंबे समय तक;
 शुरू करना
	 अगर n = 1 तो F: = 1
	 अन्यथा 
	 अगर n = 3 तो F: = 3
	 और एफ: = एन * एफ (एन -2);
 अंत;
 शुरू करना
	 ClrScr;
	 दोहराना
		 लिखें ('डबल फैक्टरियल की गणना करने के लिए एक विषम संख्या दर्ज करें:');
		 Readln (n);
	 जब तक विषम (n);
	 लिखें ('संख्या के लिए डबल फैक्टोरियल', n, 'बराबर है');
	 लिखो (F (n));
	 readln;
 अंत।

इस प्रकार, उपयोगकर्ता की भूमिका हमें डेटा इनपुट और आउटपुट के सक्षम डिजाइन पर ध्यान केंद्रित करने में मदद करती है, जो हमेशा स्पष्ट नहीं होती है।

पूर्णता की कोई सीमा नहीं है

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

एक शैली की अवधारणा अनुकूल चर नामों का उपयोग करना है। हंगरी संकेतन के अनुसार, उदाहरण के लिए, चर के नाम में इसके बारे में जानकारी होनी चाहिए, विशेष रूप से इसके प्रकार के बारे में: चर pszLicFileContents के नाम का अर्थ है कि यह एक संकेतक (p) है, एक निश्चित आकार (sz) के एक स्ट्रिंग के लिए, इसका प्रकार चर pbContentent के नाम पर एन्कोड किया गया है LPBYTE, bVerified चर प्रकार बूल का है।

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

कार्यक्रम का स्रोत कोड बनाना भी इसकी स्पष्टता को बढ़ाने में मदद करता है। पास्कल प्रोग्रामिंग भाषा प्रोग्राम संचालकों को सीमांकक "?" और "" के साथ एक लाइन पर सूचीबद्ध करने की अनुमति देती है, लेकिन यह स्पष्ट है कि ऐसा रिकॉर्ड समझ से बाहर है। हमने जिन उदाहरणों को इंगित किया है, उनमें चर परिभाषा ब्लॉक, लूप, इनपुट और आउटपुट ऑपरेटर इंडेंट हैं। प्रोग्रामिंग भाषाएं हैं, उदाहरण के लिए, पायथन, जो उचित कोड डिज़ाइन के बिना प्रोग्राम को चलाने की अनुमति नहीं देता है।

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

 {गेटलाइन फ़ंक्शन कीबोर्ड से दर्ज की गई लाइनों को पढ़ता है, उन्हें str सरणी में लिखता है, और पढ़ी गई लाइनों की संख्या लौटाता है}
 फ़ंक्शन गेटलाइन्स (var str: array of string): पूर्णांक;
 वर
	 i: पूर्णांक;  {लाइन काउंटर}
 शुरू करना
	 i: = 0;  {काउंटर का प्रारंभ}
 {फ़ाइल के अंत तक पहुंचने तक, अगली पंक्ति पढ़ें और काउंटर बढ़ाएं}
	 जबकि ईओएफ (इनपुट) नहीं है
	 शुरू करना
		 Readln (str [i]);
		 inc (i);
	 अंत;
 {पढ़ी गई पंक्तियों की संख्या लौटाएं}
	 getlines: = i;
 अंत; 

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

ऊपर सूचीबद्ध दृष्टिकोणों के बाद, हमारे द्वारा प्रस्तावित उदाहरण से प्रोग्राम टेक्स्ट को निम्नानुसार संशोधित किया जाना चाहिए:

 कार्यक्रम oddfactorial;
 crt का उपयोग करता है;
 var n: पूर्णांक;
 {DoubleFactorial फ़ंक्शन ने इसे पास की गई संख्या n के दोहरे तथ्य को गिना है}
 समारोह DoubleFactorial (n: पूर्णांक): longint;
 शुरू करना
 {पहले दो स्थितियां दोहरे तथ्य की परिभाषा से ली गई हैं}
	 यदि n = 1 तो DoubleFactorial: = 1
	 अन्यथा 
	 यदि n = 3 तो DoubleFactorial: = 3
 {पुनरावर्ती फ़ंक्शन कॉल}
	 और डबलफैक्टीरियल: = एन * डबलफैक्टीरियल (एन -2);
 अंत;
 शुरू करना
	 ClrScr;
	 दोहराना
		 लिखें ('डबल फैक्टरियल की गणना करने के लिए एक विषम संख्या दर्ज करें');
                 Readln (n);
	 जब तक विषम (n);  {जब तक कोई विषम संख्या दर्ज नहीं होती है तब तक प्रवेश संख्या जारी रहती है}
	 लिखें ('संख्या के लिए डबल फैक्टोरियल', n, 'बराबर है');
	 लिखें (DoubleFactorial (n));
	 readln;
 अंत। 

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

पुनश्च

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

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

अपने लेख में मैंने ROME के ​​सिद्धांतों को संक्षेप में बताने की कोशिश की, जो आपको विभिन्न कोणों से अपने उत्पाद को देखना सिखाते हैं। मुझे उम्मीद है कि किसी के लिए वे उपयोगी होंगे।