🙋🏾 👨🏻‍🏭 🥡 प्रोग्रामिंग विचारों का भौतिककरण है। 🏚️ 🛒 👩🏻‍🎤

इस लेख की मुख्य थीसिस: सॉफ्टवेयर विकास को मानसिक मॉडल के प्रोग्राम कोड में परिवर्तन के माध्यम से विचारों के भौतिककरण के रूप में देखा जाना चाहिए।
लेख सॉफ्टवेयर इंजीनियरिंग में विचारों को भौतिक बनाने के प्रतिमान का वर्णन करता है (संलग्न। आरपीएसई: सॉफ्टवेयर इंजीनियरिंग के प्रतिमान के रूप में संशोधन)।

लेख का अंग्रेजी संस्करण: आरपीएसई: सॉफ्टवेयर इंजीनियरिंग के प्रतिमान के रूप में संशोधन । संक्षिप्त नाम आरपीएसई का उपयोग बाद में पाठ में वर्णित प्रतिमान को इंगित करने के लिए किया जाता है।

मुख्य परिभाषाएँ

इस लेख के मुख्य बिंदुओं पर चर्चा करने से पहले, आपको इसमें प्रयुक्त मूल शब्दों के अर्थ पर सहमत होने की आवश्यकता है।

सॉफ्टवेयर इंजीनियरिंग

सॉफ्टवेयर इंजीनियरिंग से हमारा तात्पर्य IEEE शब्दकोश [1] से सॉफ्टवेयर इंजीनियरिंग अनुशासन की क्लासिक परिभाषा से है: सॉफ्टवेयर इंजीनियरिंग "सॉफ्टवेयर के विकास, संचालन और रखरखाव के लिए व्यवस्थित, अनुशासित, मात्रात्मक दृष्टिकोण का अनुप्रयोग है"।

मिसाल

इस लेख में प्रयुक्त शब्द प्रतिमान थॉमस कुह्न प्रतिमान [2] की क्लासिक परिभाषा पर आधारित है: एक प्रतिमान समस्याओं का एक चक्र है, अवधारणाओं का एक समूह, आम तौर पर स्वीकृत नियम और कानून, विज्ञान के एक निश्चित क्षेत्र में समस्याओं को हल करने के तरीके।

प्रतिमानों पर अधिक

नीचे दिए गए प्रतिमान की अवधारणा को अधिक सटीक रूप से निर्धारित करने के लिए, कुह्न की पुस्तक के दो प्रसिद्ध उद्धरणों का हवाला देना उपयोगी है:

प्रतिमानों से, मेरा मतलब है कि वैज्ञानिक उपलब्धियों को मान्यता दी जाए जो कुछ समय के लिए वैज्ञानिक समुदाय को समस्याओं और उनके समाधानों के लिए एक मॉडल दें ...

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

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

थॉमस कुह्न ने अपनी पुस्तक में वैज्ञानिक प्रतिमानों पर विचार किया। हालांकि, पुस्तक के पहले संस्करण के जारी होने के तुरंत बाद, प्रौद्योगिकी और सामाजिक जीवन के विभिन्न क्षेत्रों में इस अवधारणा का उपयोग करने की उपयोगिता स्पष्ट है। इस संबंध में, प्रतिमानों पर कई प्रकाशन और ऑटोमोटिव उद्योग में उनके परिवर्तन, शहरी नियोजन, कुछ बीमारियों के उपचार आदि, विशेष और लोकप्रिय साहित्य में दिखाई देने लगे।

सॉफ्टवेयर इंजीनियरिंग और विशेष रूप से इसके महत्वपूर्ण घटक - प्रोग्रामिंग, कोई अपवाद नहीं थे। वर्तमान में कई प्रतिस्पर्धी प्रोग्रामिंग प्रतिमान हैं। विकिपीडिया [3] पर एक अलग लेख, साथ ही साथ [4] जैसी दिलचस्प समीक्षाएं, उनकी गणना के लिए समर्पित हैं।

प्रोग्रामिंग प्रतिमानों की सीमाओं के बारे में

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

इस लेख में वर्णित प्रतिमान, इसके विपरीत, सॉफ्टवेयर विकास के विभिन्न क्षेत्रों और चरणों की एक विस्तृत विविधता के लिए लागू है।

सॉफ्टवेयर परियोजना प्रबंधन प्रतिमानों की सीमाओं पर

कुछ लेखकों, उदाहरण के लिए, समीक्षा में [5], सॉफ्टवेयर प्रोजेक्ट्स को प्रतिमानों के आयोजन और संचालन के लिए विभिन्न दृष्टिकोणों या मॉडलों का नाम देते हैं। उदाहरण के लिए, झरना मॉडल, V मॉडल या फुर्तीली मॉडल की तुलना की जाती है। यह संभावना नहीं है कि ये दृष्टिकोण, ऊपर उल्लिखित प्रोग्रामिंग प्रतिमानों के विपरीत, कुहन की परिभाषा के संदर्भ में प्रतिमान कहे जा सकते हैं क्योंकि उनके सापेक्ष सैद्धांतिक सादगी और व्यापक सैद्धांतिक आधार की कमी है।

इस लेख में प्रस्तावित प्रतिमान का अभी भी अपना विकसित सैद्धांतिक आधार नहीं है, लेकिन आज इसके विकास के रास्ते पहले से ही दिखाई दे रहे हैं।

विचारों का भौतिककरण

इस लेख में उपयोग किए गए विचारों (शब्द: संशोधन ) का भौतिक मूल्यांकन कंप्यूटर विज्ञान में संशोधन की शास्त्रीय परिभाषा का एक विस्तार है: "संशोधन वह प्रक्रिया है जिसके द्वारा कंप्यूटर प्रोग्राम के बारे में एक अमूर्त विचार एक स्पष्ट डेटा मॉडल या एक प्रोग्रामिंग भाषा में बनाई गई अन्य भाषाओं में बदल जाता है" [6]।

विचारों की दुनिया, चीजों और भौतिकता की दुनिया के बारे में अधिक

इस लेख में प्रयुक्त सामग्रीकरण की अवधारणा की शास्त्रीय परिभाषा के विस्तार का सार निम्नानुसार परिभाषित किया जा सकता है।

पहले से ही हमारे पास आने वाले दार्शनिक मार्गों में से सबसे पहले, यह आदर्श (विचारों की दुनिया) सामग्री (चीजों की दुनिया) के साथ विपरीत करने के लिए प्रथागत था।

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

एक नियम के रूप में आदर्श की हमारी भावना तैयार करने का प्रयास सफलता की ओर नहीं ले जाता है।
महान रूसी कवि फेडर इवानोविच टाइचचेव ने यह टिप्पणी की:

दिल खुद को कैसे व्यक्त करता है?
आपको और कैसे समझना है?
क्या वह समझेगा कि तुम कैसे रहते हो?
बोला गया विचार झूठ है ... [tered]

यहां तक कि व्यावहारिक विचारों जैसे कि घर के आसपास की मरम्मत या एक परिचित पकवान की एक नई विविधता तैयार करना पहले से तैयार करना मुश्किल है। और केवल विचार-विमर्श या दूसरे को समझाने की कोशिश के बाद, विचार तेजी से स्पष्ट "रूपरेखा" पर ले जाता है।

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

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

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

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

यू = एम + आई

जहाँ सेट M में उनकी घटनाएँ होती हैं, जिन्हें उद्देश्यपूर्ण रूप से पंजीकृत या मापा जा सकता है (भौतिक दुनिया) और मैं - बाकी सब कुछ।

क्या यह सूत्र हमारे आसपास की दुनिया की सभी घटनाओं के लिए लागू है, एक खुला दार्शनिक प्रश्न है। इस लेख में बाद में, हम इस सूत्र के दायरे को सॉफ्टवेयर इंजीनियरिंग की दुनिया से घटना की दुनिया तक सीमित कर देते हैं।

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

यह प्रक्रिया ग्राहकों या डेवलपर्स के मन में भविष्य की प्रणाली के बारे में कुछ विचारों के उद्भव के साथ शुरू होती है। हम इन विचारों और विचारों को एक मानसिक मॉडल कहेंगे।

इंटरमीडिएट मॉडल के बारे में

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

सॉफ्टवेयर इंजीनियरिंग से सटे क्षेत्रों में विचारों का भौतिककरण

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

ये दोनों क्षेत्र लंबे समय से और प्रभावी ढंग से विचारों के भौतिककरण का उपयोग कर रहे हैं। इस संबंध में प्रोग्रामिंग के बारे में जानने के लिए उनके पास बहुत कुछ है।

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

गणित में स्थिति अलग है।

गणित में विचारों के भौतिककरण पर

गणित में विचारों के भौतिककरण के बारे में रोचक तथ्य और विचार पुस्तक] [।] के अनुच्छेद regarding.३ में देखे जा सकते हैं।

गणित का "अंतिम उत्पाद" औपचारिक रूप से सिद्ध गुणों के साथ औपचारिक मॉडल है।

इस दृष्टि से, प्रोग्रामिंग बीच में है। इसे इस प्रकार चित्रित किया जा सकता है:

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

मैकेनिकल इंजीनियरिंग, इसके विपरीत, अपेक्षाकृत कुछ अमूर्त मॉडल का उपयोग करता है, लेकिन कई विशिष्ट। उदाहरण के लिए, जिन लोगों के लिए भौतिक वस्तुओं को स्पष्ट रूप से बनाया जा सकता है।

इस दृष्टि से, प्रोग्रामिंग बीच में है।

बीच में प्रोग्रामिंग क्यों है?

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

मॉडल के उपयोग के संदर्भ में सॉफ्टवेयर इंजीनियरिंग पड़ोसी क्षेत्रों से क्या सीख सकता है

पहले गणित पर विचार करें।

संसार का बहुमूत्र

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

आज, हाई स्कूल के छात्रों को पहले से ही पता है कि एक ही समस्या को विभिन्न तरीकों से हल किया जा सकता है (उदाहरण के लिए, ज्यामितीय या बीजगणितीय) और यह कि एक ही गणितीय मॉडल, उदाहरण के लिए, एक बीजगणितीय समीकरण, कई अलग-अलग भौतिक, रासायनिक, आदि का वर्णन करता है। घटना।

मॉडल की आकृति विज्ञान और अवधारणाओं और धारणाओं की निरंतरता

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

मैकेनिकल इंजीनियरिंग में मॉडल

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

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

मौजूदा मॉडल और प्रक्रियाओं की दक्षता की कमी
बड़ी चिंताओं के बाहर इन मॉडलों की प्रसिद्धि की कमी
डेवलपर्स और विशेष रूप से प्रबंधकों के लिए अपर्याप्त शिक्षा
सॉफ्टवेयर इंजीनियरिंग की वास्तविक जरूरतों से विश्वविद्यालय शिक्षा का बैकलॉग।

विचारों के भौतिककरण की परिभाषा और परिभाषा (RPSE)

हमने प्रस्तावित प्रतिमान की एक मूल परिभाषा देने के लिए सभी आवश्यक अवधारणाओं की पहचान की है। यहाँ यह है:

सॉफ्टवेयर विकास, कंप्यूटर पर निष्पादित कोड में मानसिक मॉडल के परिवर्तन के माध्यम से विचारों का भौतिककरण है।

प्रस्तावित प्रतिमान की रूपरेखा में:

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

क्यों सामग्रीकरण और मॉडलिंग नहीं?

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

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

परिभाषा विकल्प

बहुत बार कई लोग एक ही समय में एक समस्या पर काम करते हैं। उनमें से प्रत्येक का अपना मानसिक मॉडल है और संभवतः, इसके मध्यवर्ती मॉडल और कोड टुकड़े हैं।

अक्सर कुछ प्रोग्रामिंग भाषा में कोड वस्तुतः अनुपस्थित होता है, क्योंकि एक नया समाधान बनाने से विन्यासकर्ता या जनरेटर के मुखौटे के प्रबंधन में कमी आती है, जैसे कि SAP या WebSphere जैसे सिस्टम में विकास उपकरण के साथ काम करते समय।

मैन्युअल रूप से लिखित या स्वचालित रूप से उत्पन्न कोड को निष्पादन योग्य कोड में बदलने के विकल्प भी इन दिनों बहुत विविध हो गए हैं।

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

फिर भी, आरपीएसई, अपनी व्यापकता के आधार पर, ऊपर सूचीबद्ध सभी क्षेत्रों पर लागू होता है।

आज एक निश्चित प्रतिमान के बारे में और क्या कहा जा सकता है, क्या यह संभव है कि किसी भी तरह से अधिक सटीक रूप से इसकी आकृति को रेखांकित किया जा सके?

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

RPSE मॉडल को तीन मुख्य श्रेणियों में विभाजित किया जा सकता है:

मानसिक मॉडल
प्रोग्रामिंग भाषाओं में कोड या निष्पादन योग्य कोड के मॉडल के रूप में इसके समकक्ष।
इंटरमीडिएट मॉडल।

इस त्रय में सबसे कम अन्वेषण मानसिक मॉडल हैं। वास्तव में उनके द्वारा क्या मतलब है?

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

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

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

बाइनरी, गणना, संख्यात्मक, स्ट्रिंग, और अन्य मूल्यों के साथ सूची।
ग्राफ़ और नेटवर्क डेटा संरचनाएँ

व्यवहार विवरण मॉडल:

व्यवहार का निर्धारण करने के लिए सात-औपचारिक मॉडल
व्यवहार के निर्धारण के लिए औपचारिक मॉडल (उदाहरण के लिए, राज्य मशीनों को सीमित)

मानसिक मॉडल के सिद्धांत पर

ये पैटर्न मानसिक पैटर्न का प्रतिबिंब हैं। वास्तविक मॉडल के लिए मानसिक मॉडल की निकटता की डिग्री को मनोविज्ञान या सैद्धांतिक शिक्षाशास्त्र द्वारा निपटा जाना चाहिए। दुर्भाग्य से, लेखक को इस क्षेत्र में गंभीर काम के बारे में पता नहीं है। (इसका मतलब यह नहीं है कि ऐसा काम मौजूद नहीं है)।

सॉफ्टवेयर इंजीनियरिंग को एंड-टू-एंड प्रतिमान की आवश्यकता क्यों है?

एक "क्रॉस-कटिंग" प्रतिमान की उपस्थिति सॉफ्टवेयर बनाने, संशोधित करने और उपयोग करने की प्रक्रिया के प्रतिमान का उपयोग करने वाले प्रतिभागियों के लिए निम्नलिखित संभावनाएं खोलती है:

प्रक्रिया में सभी प्रतिभागियों के लिए समान शब्दावली का उपयोग करने की क्षमता।
नए सॉफ़्टवेयर बनाने की एंड-टू-एंड प्रक्रिया बनाने की क्षमता।
इसकी प्रक्रिया मापदंडों का मूल्यांकन करने की क्षमता, इसके मध्यवर्ती परिणाम और इसका प्रबंधन।

।

प्रतिमान विकास के मुख्य उद्देश्य

सैद्धांतिक समस्याएं

जैसा कि बार-बार नोट किया गया है, जिसमें कुह्न [2] की पुस्तक भी शामिल है, ज्यादातर मामलों में, वैज्ञानिक संभावित समस्याओं को हल करने में लगे हुए हैं, और कम बार वे उन लोगों को लेते हैं जो दृष्टिकोण के लिए बहुत स्पष्ट नहीं हैं। लेकिन ये बिल्कुल हमारे कार्य हैं। यहाँ मुख्य हैं:

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

व्यावहारिक कार्य

सॉफ्टवेयर इंजीनियरिंग के अभ्यास में वर्णित प्रतिमान के विकास और कार्यान्वयन के लिए सैद्धांतिक कार्यों के साथ, कम से कम निम्नलिखित व्यावहारिक कार्यों को हल करना आवश्यक है:

के लिए उपकरणों का निर्माण: ए) मानसिक मॉडल की निकासी और फिक्सिंग। b) मध्यवर्ती मॉडल में मानसिक मॉडल के स्वचालित और स्वचालित परिवर्तन। ग) परिवर्तनशील मॉडल की सामग्री में परिवर्तन के निशान और अनुमान
आवश्यक तकनीकी और शैक्षिक साहित्य और अन्य औसत दर्जे का शैक्षिक सामग्री का निर्माण।
इस विषय पर मंचों और सम्मेलनों का संगठन

निष्कर्ष

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

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

लेखों की एक योजनाबद्ध श्रृंखला में यह पहला लेख है। निम्नलिखित लेखों में मैं मानसिक और मध्यवर्ती मॉडल के बारे में बात करने जा रहा हूं।

साहित्य

1. आईईईई मानक शब्दावली सॉफ्टवेयर इंजीनियरिंग शब्दावली, IEEE एसटीडी 610.12-1990, 1990।
2. कुहन, थॉमस एस। तीसरा संस्करण। शिकागो, आईएल: शिकागो विश्वविद्यालय प्रेस, 1996.
3. प्रोग्रामिंग प्रतिमान: en.wikipedia.org/wiki/Programming_paradigm (राज्य - 08/27/2018)
4. पीटर ए। हेनिंग, होल्गर वोगैनांग तस्चेनबच प्रोग्राममेर्सप्रेचेन। कार्ल हैन्सर वर्लग GmbH एंड कंपनी केजी; Auflage: 2., neu bearbeitete (5. सितंबर 2007)। आईएसबीएन -13: 978-3446407442
5. सॉफ्टवेयर इंजीनियरिंग प्रतिमान और मॉडल सूचना प्रौद्योगिकी निबंध
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (स्थिति - 08.28.2018 )
6. सुधार (कंप्यूटर विज्ञान) en.wikipedia.org/wiki/Reification_ (computer_science) (स्थिति - 08/27/2018)
7. Fedor Ivanovich Tyutchev। Silentium! । (साधना (लैटिन) 1829
8. Borovik, खुर्दबीन के नीचे एलेक्जेंडर गणित :। के गणितीय अभ्यास अमेरिकन सोसायटी गणितीय ISBN- संज्ञानात्मक पहलुओं पर नोट्स ... 978-0821847619: 13

उदाहरण: Geralt

प्रोग्रामिंग विचारों का भौतिककरण है।