एब्सट्रेक्शन (कंप्यूटर विज्ञान)

The essence of abstraction is preserving information that is relevant in a given context, and forgetting information that is irrelevant in that context.

– John V. Guttag

सॉफ्टवेयर इंजीनियरिंग और कंप्यूटर विज्ञान में, अमूर्तन है:

• भौतिक, स्थानिक या लौकिक विवरणों को हटाने या सामान्य बनाने की प्रक्रिया या अधिक महत्व के विवरणों पर ध्यान केंद्रित करने के लिए वस्तुओं या प्रणालियों के अध्ययन में विशेषता (कंप्यूटिंग); यह प्रकृति में सामान्यीकरण की प्रक्रिया के समान है;
• विभिन्न गैर-अमूर्त वस्तुओं या अध्ययन प्रणालियों की सामान्य विशेषताओं या विशेषताओं को प्रतिबिंबित करके सार और ठोस अवधारणा-वस्तु (दर्शन) का निर्माण- अमूर्तन की प्रक्रिया का परिणाम.

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

कंप्यूटर विज्ञान में अमूर्तन का अमूर्तन (गणित) से गहरा संबंध है, क्योंकि उनका सामान्य ध्यान वस्तुओं के रूप में अमूर्तन के निर्माण पर होता है,लेकिन यह अन्य क्षेत्रों अमूर्त (कला) में उपयोग की जाने वाली अमूर्तता की अन्य धारणाओं से भी संबंधित है।

अमूर्तन का तात्पर्य वास्तविक दुनिया की वस्तुओं और प्रणालियों, संगणना के नियमों या प्रोग्रामिंग भाषाओं के नियमों से भी हो सकता है जो अमूर्तन की विशेषताओं को ले जाते हैं या उनका उपयोग करते हैं, जैसे:

• कंप्यूटर प्रोग्राम के भीतर डेटा संरचनाओं के कामकाजी प्रतिनिधित्व से उपयोग को अलग करने के लिए डेटा अमूर्त करने के लिए डेटा प्रकारों का उपयोग;
• प्रक्रिया (कंप्यूटर विज्ञान) की अवधारणा | प्रक्रियाएं, कार्य, या सबरूटीन जो कार्यक्रमों में नियंत्रण प्रवाह को लागू करने के एक विशिष्ट तरीके का प्रतिनिधित्व करते हैं;
• आमतौर पर एब्स्ट्रैक्शन नाम के नियम जो लैम्ब्डा कैलकुलस के विभिन्न संस्करणों में मुक्त चर और बाध्य चर का उपयोग करके अभिव्यक्ति (गणित) को सामान्यीकृत करते हैं;
• लिस्प (प्रोग्रामिंग भाषा) में डेटा संरचनाओं और कार्यक्रमों के अमूर्त के रूप में एस-अभिव्यक्ति का उपयोग;
• गैर-अमूर्त वर्ग (कंप्यूटर प्रोग्रामिंग) से सामान्य व्यवहार को इनहेरिटेंस (ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ) का उपयोग करके अमूर्त वर्गों में पुनर्गठित करने की प्रक्रिया, वंशानुक्रम (वस्तु-उन्मुख प्रोग्रामिंग) #उपवर्ग और सुपरक्लास|उप-वर्गों पर जैसा कि ऑब्जेक्ट में देखा गया है। -ओरिएंटेड प्रोग्रामिंग|ऑब्जेक्ट-ओरिएंटेड सी++ और जावा (प्रोग्रामिंग भाषा) प्रोग्रामिंग भाषाएं।

तर्क

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

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

एक प्रोग्रामिंग भाषा के भीतर, कुछ विशेषताएं प्रोग्रामर को नए अमूर्त बनाने देती हैं। इनमें सबरूटीन्स, मॉड्यूल (प्रोग्रामिंग), बहुरूपता (कंप्यूटर विज्ञान), और सॉफ्टवेयर घटक शामिल हैं। कुछ अन्य अमूर्तताएं जैसे सॉफ़्टवेयर डिज़ाइन पैटर्न और सॉफ़्टवेयर आर्किटेक्चर#वास्तुशिल्प शैलियाँ और पैटर्न एक अनुवादक (कंप्यूटिंग) के लिए अदृश्य रहते हैं और केवल एक सिस्टम के डिज़ाइन में काम करते हैं।

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

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

अमूर्त विशेषताएं

प्रोग्रामिंग भाषाएँ

Main article: Programming language

विभिन्न प्रोग्रामिंग भाषाएं, भाषा के लिए इच्छित अनुप्रयोगों के आधार पर, विभिन्न प्रकार के अमूर्तता प्रदान करती हैं। उदाहरण के लिए:

• ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं जैसे C++, ऑब्जेक्ट पास्कल, या जावा (प्रोग्रामिंग भाषा) में, अमूर्तता की अवधारणा स्वयं एक घोषणात्मक कथन बन गई है - सिंटैक्स (प्रोग्रामिंग भाषाओं) का उपयोग करते हुए function(parameters) = 0; (सी++ में) या कीवर्ड (कंप्यूटर प्रोग्रामिंग)।abstract औरinterface (जावा में (प्रोग्रामिंग भाषा))। ऐसी घोषणा के बाद, यह प्रोग्रामर की जिम्मेदारी है कि वह घोषणा के ऑब्जेक्ट (कंप्यूटर विज्ञान) को इंस्टेंट करने के लिए एक क्लास (कंप्यूटर विज्ञान) को लागू करे।
• कार्यात्मक प्रोग्रामिंग भाषाएं आमतौर पर कार्यों से संबंधित अमूर्तता प्रदर्शित करती हैं, जैसे लैम्ब्डा अमूर्तन (किसी शब्द को कुछ चर के फ़ंक्शन में बनाना) और उच्च-क्रम वाले फ़ंक्शन (पैरामीटर फ़ंक्शन होते हैं)।
• लिस्प प्रोग्रामिंग भाषा परिवार के आधुनिक सदस्य जैसे क्लोजर, स्कीम (प्रोग्रामिंग भाषा) और सामान्य लिस्प सिंटैक्टिक अमूर्तता की अनुमति देने के लिए मैक्रो (कंप्यूटर विज्ञान) #सिंटैक्टिक मैक्रोज़ का समर्थन करते हैं। अन्य प्रोग्रामिंग भाषाओं जैसे स्काला (प्रोग्रामिंग भाषा) में भी मैक्रोज़, या बहुत समान मेटाप्रोग्रामिंग विशेषताएं हैं (उदाहरण के लिए, हास्केल (प्रोग्रामिंग भाषा) में टेम्पलेट हास्केल है, और ओकैमल में मेटाओकैमल है)। ये एक प्रोग्रामर को बॉयलरप्लेट कोड को खत्म करने, थकाऊ फ़ंक्शन कॉल अनुक्रमों को दूर करने, नए नियंत्रण प्रवाह को लागू करने और डोमेन-विशिष्ट भाषा | डोमेन विशिष्ट भाषाओं (डीएसएल) को लागू करने की अनुमति दे सकते हैं, जो डोमेन-विशिष्ट अवधारणाओं को संक्षिप्त और सुरुचिपूर्ण तरीकों से व्यक्त करने की अनुमति देते हैं। . ये सभी, जब सही ढंग से उपयोग किए जाते हैं, तो इच्छित उद्देश्य को और अधिक स्पष्ट करके प्रोग्रामर की दक्षता और कोड की स्पष्टता दोनों में सुधार करते हैं। वाक्यात्मक अमूर्तन का एक परिणाम यह भी है कि किसी भी लिस्प बोली और वास्तव में लगभग किसी भी प्रोग्रामिंग भाषा को, सिद्धांत रूप में, किसी भी आधुनिक लिस्प में अधिक पारंपरिक प्रोग्रामिंग भाषाओं की तुलना में काफी कम (लेकिन ज्यादातर मामलों में अभी भी गैर-तुच्छ) प्रयास के साथ लागू किया जा सकता है। जैसे कि पायथन (प्रोग्रामिंग भाषा), सी (प्रोग्रामिंग भाषा) या जावा (प्रोग्रामिंग भाषा)।

विनिर्देश विधियाँ

Main article: Formal specification

विश्लेषकों ने सॉफ्टवेयर सिस्टम को औपचारिक रूप से निर्दिष्ट करने के लिए विभिन्न तरीके विकसित किए हैं। कुछ ज्ञात विधियों में शामिल हैं:

• सार-मॉडल आधारित विधि (वीडीएम, जेड);
• बीजगणितीय तकनीकें (लार्च, क्लियर, ओबीजे, एक्ट वन, सीएएसएल);
• प्रक्रिया-आधारित तकनीकें (LOTOS, SDL, एस्टेले);
• ट्रेस-आधारित तकनीकें (विशेष, टैम);
• ज्ञान-आधारित तकनीकें (परिष्कृत, सार)।

विनिर्देश भाषाएँ

Main article: Specification language

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

नियंत्रण अमूर्तन

Main article: Control flow

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

a := (1 + 2) * 5

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

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

1. यह प्रोग्रामर को हर बार समान ऑपरेशन की आवश्यकता होने पर लगातार सामान्य कार्यों को दोहराने के लिए मजबूर करता है
2. यह प्रोग्रामर को विशेष हार्डवेयर और निर्देश सेट के लिए प्रोग्राम करने के लिए बाध्य करता है

संरचित प्रोग्रामिंग

Main article: Structured programming

संरचित प्रोग्रामिंग में जटिल प्रोग्राम कार्यों को स्पष्ट प्रवाह-नियंत्रण और घटकों के बीच इंटरफेस के साथ छोटे टुकड़ों में विभाजित करना शामिल है, जिससे साइड-इफेक्ट्स की जटिलता क्षमता में कमी आती है।

एक सरल कार्यक्रम में, इसका उद्देश्य यह सुनिश्चित करना हो सकता है कि लूप में एकल या स्पष्ट निकास बिंदु हों और (जहां संभव हो) कार्यों और प्रक्रियाओं से एकल निकास बिंदु हों।

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

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

ये परतें एक घटक के कार्यान्वयन विवरण और उसके मिश्रित आंतरिक तरीकों को दूसरों से अलग करने का प्रभाव उत्पन्न करती हैं। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग इस अवधारणा को अपनाती है और इसका विस्तार करती है।

डेटा अमूर्त

Main article: Abstract data type

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

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

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

मैनुअल डेटा अमूर्त

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

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में अमूर्तन

Main article: Object (computer science)

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

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

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

C++ एक और चरम का उदाहरण देता है: यह सामान्य प्रोग्रामिंग और विधि ओवरलोडिंग और संकलन-समय पर अन्य स्थैतिक बाइंडिंग पर बहुत अधिक निर्भर करता है, जिसके बदले में कुछ लचीलेपन की समस्याएं होती हैं।

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

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

public class Animal extends LivingThing
{
     private Location loc;
     private double energyReserves;

     public boolean isHungry() {
         return energyReserves < 2.5;
     }
     public void eat(Food food) {
         // Consume food
         energyReserves += food.getCalories();
     }
     public void moveTo(Location location) {
         // Move to new location
         this.loc = location;
     }
}

उपरोक्त परिभाषा के साथ, कोई भी प्रकार की वस्तुएं बना सकता है Animal और उनकी विधियों को इस प्रकार कॉल करें:

thePig = new Animal();
theCow = new Animal();
if (thePig.isHungry()) {
    thePig.eat(tableScraps);
}
if (theCow.isHungry()) {
    theCow.eat(grass);
}
theCow.moveTo(theBarn);

उपरोक्त उदाहरण में, classAnimalएक वास्तविक जानवर के स्थान पर प्रयुक्त एक अमूर्तन है,LivingThingका एक और अमूर्तन (इस मामले में एक सामान्यीकरण) हैAnimal.

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

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

वस्तु-उन्मुख डिज़ाइन

Main article: Object-oriented design

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

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

विचार

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

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

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

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

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

अमूर्तन, अमूर्त व्याख्या की मूल अवधारणा है। मॉडल जाँच आम तौर पर अध्ययन किए गए सिस्टम के अमूर्त संस्करणों पर होती है।

अमूर्तता का स्तर

Main article: Abstraction layer

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

डेटाबेस सिस्टम

Main article: Database management system

चूँकि डेटाबेस सिस्टम के कई उपयोगकर्ताओं के पास कंप्यूटर डेटा-संरचनाओं के साथ गहराई से परिचित होने की कमी है, डेटाबेस डेवलपर्स अक्सर निम्नलिखित स्तरों के माध्यम से जटिलता को छिपाते हैं:

डेटाबेस सिस्टम का डेटा अमूर्त स्तर

भौतिक स्तर: अमूर्तता का निम्नतम स्तर बताता है कि कोई सिस्टम वास्तव में डेटा कैसे संग्रहीत करता है। भौतिक स्तर जटिल निम्न-स्तरीय डेटा संरचनाओं का विस्तार से वर्णन करता है।

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

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

स्तरित वास्तुकला

Main article: Abstraction layer

अमूर्तता के विभिन्न स्तरों का डिज़ाइन प्रदान करने की क्षमता

• डिज़ाइन को काफी सरल बनाएं
• विभिन्न भूमिका निभाने वालों को अमूर्तता के विभिन्न स्तरों पर प्रभावी ढंग से काम करने में सक्षम बनाना
• सॉफ़्टवेयर कलाकृतियों की पोर्टेबिलिटी का समर्थन करें (आदर्श रूप से मॉडल-आधारित)

सिस्टम डिज़ाइन और व्यवसाय प्रक्रिया मॉडलिंग दोनों इसका उपयोग कर सकते हैं। कुछ सॉफ्टवेयर मॉडलिंग विशेष रूप से ऐसे डिज़ाइन तैयार करते हैं जिनमें अमूर्तता के विभिन्न स्तर होते हैं।

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

यह भी देखें

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

अग्रिम पठन

• Harold Abelson; Gerald Jay Sussman; Julie Sussman (25 July 1996). Structure and Interpretation of Computer Programs (2 ed.). MIT Press. ISBN 978-0-262-01153-2. Archived from the original on 26 February 2009. Retrieved 22 June 2012.
• Spolsky, Joel (11 November 2002). "The Law of Leaky Abstractions". Joel on Software.
• Abstraction/information hiding – CS211 course, Cornell University.
• Eric S. Roberts (1997). Programming Abstractions in C A Second Course in Computer Science.
• Palermo, Jeffrey (29 July 2008). "The Onion Architecture". Jeffrey Palermo.
• Vishkin, Uzi (January 2011). "Using simple abstraction to reinvent computing for parallelism". Communications of the ACM. 54 (1): 75–85. doi:10.1145/1866739.1866757.

बाहरी संबंध

• SimArch example of layered architecture for distributed simulation systems.