घटक-आधारित सॉफ्टवेयर इंजीनियरिंग



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

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

घटक घटनाओं का उत्पादन या उपभोग कर सकते हैं और घटना-संचालित आर्किटेक्चर (ईडीए) के लिए उपयोग किए जा सकते हैं।

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

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

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

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

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

घटकों को प्रतिस्थापित करने वाले इंजीनियरों के लिए लिस्कोव प्रतिस्थापन सिद्धांत के रूप में, घटक बी तुरंत घटक ए को प्रतिस्थापित कर सकता है, यदि घटक बी कम से कम कौन सा घटक ए प्रदान करता है और उपयोग किए गए घटक ए से अधिक का उपयोग नहीं करता है।

सॉफ़्टवेयर घटक अक्सर वस्तु (कंप्यूटिंग)  (कक्षा ([[कंप्यूटर विज्ञान)]] नहीं) या वस्तुओं के संग्रह ( ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग  से) का रूप लेते हैं, कुछ बाइनरी या पाठ्य रूप में, कुछ इंटरफ़ेस विवरण भाषा (IDL) का पालन करते हैं ताकि घटक कंप्यूटर में अन्य घटकों से स्वायत्त रूप से मौजूद हो सकता है। दूसरे शब्दों में, एक घटक अपने स्रोत कोड को बदले बिना कार्य करता है। यद्यपि घटक के स्रोत कोड का व्यवहार अनुप्रयोग की व्यापकता के आधार पर बदल सकता है, जो इसके लेखक द्वारा प्रदान किया गया है।

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

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

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

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

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

इतिहास
यह विचार कि सॉफ़्टवेयर को घटक बनाया जाना चाहिए - पूर्वनिर्मित घटकों से निर्मित - सबसे पहले जर्मनी के Garmisch-Partenkirchen, जर्मनी में सॉफ्टवेयर इंजीनियरिंग पर नाटो सम्मेलन में डगलस मैक्लॉयय के संबोधन के साथ प्रमुख हुआ, 1968, मास प्रोड्यूस्ड सॉफ्टवेयर कंपोनेंट्स शीर्षक। तथाकथित सॉफ्टवेयर संकट का मुकाबला करने के लिए सम्मेलन की शुरुआत हुई। McIlroy का बाद में यूनिक्स ऑपरेटिंग सिस्टम में पाइपलाइन (यूनिक्स) का समावेश इस विचार के लिए एक बुनियादी ढांचे का पहला कार्यान्वयन था।

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

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

आईबीएम ने 1990 के दशक की शुरुआत में अपने आईबीएम सिस्टम ऑब्जेक्ट मॉडल | सिस्टम ऑब्जेक्ट मॉडल (एसओएम) के साथ पथ का नेतृत्व किया। एक प्रतिक्रिया के रूप में, Microsoft ने जोडकर परनिगरानी और उद्देश् य (OLE) और घटक वस्तु मॉडल (COM) के साथ घटक सॉफ़्टवेयर के वास्तविक परिनियोजन का मार्ग प्रशस्त किया। कई सफल सॉफ़्टवेयर घटक मॉडल मौजूद हैं।

2021 में ओपन-सोर्स टूलचैन Bit ने सॉफ्टवेयर एप्लिकेशन, उत्पादों, सेवाओं और सिस्टम में घटकों के विकास और संरचना के लिए एक मुफ्त बुनियादी ढांचा प्रदान किया।

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

घटक मॉडल
एक घटक मॉडल उन गुणों की परिभाषा है जो घटकों को संतुष्ट करना चाहिए, घटकों की संरचना के लिए तरीके और तंत्र। पिछले दशकों के दौरान, शोधकर्ताओं और चिकित्सकों ने विभिन्न विशेषताओं वाले कई घटक मॉडल प्रस्तावित किए हैं। मौजूदा घटक मॉडल का वर्गीकरण में दिया गया है। घटक मॉडल के उदाहरण हैं: एंटरप्राइज JavaBeans (EJB) मॉडल, घटक वस्तु मॉडल (COM) मॉडल, .NET Framework|.NET मॉडल, X-MAN घटक मॉडल, और कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर आर्किटेक्चर (CORBA) घटक मॉडल।

टेक्नोलॉजीज

 * व्यावसायिक वस्तु (कंप्यूटर विज्ञान) प्रौद्योगिकियां
 * नई
 * विशिष्ट डोमेन के लिए घटक-आधारित सॉफ्टवेयर फ्रेमवर्क
 * उन्नत घटक रूपरेखा
 * अर्थ सिस्टम मॉडलिंग फ्रेमवर्क (ESMF)
 * एसेट मैनेजमेंट के लिए एमएएसएच आईओटी प्लेटफॉर्म
 * उपभोक्ता इलेक्ट्रॉनिक्स में सॉफ्टवेयर के लिए कोआला घटक मॉडल विकसित किया गया
 * प्रतिक्रिया (जावास्क्रिप्ट पुस्तकालय)
 * सॉफ्टवेयर संचार वास्तुकला (JTRS SCA)
 * घटक-उन्मुख प्रोग्रामिंग
 * बंडलों को ओस्गी सर्विस प्लेटफॉर्म द्वारा परिभाषित किया गया है
 * माइक्रोसॉफ्ट से कंपोनेंट ऑब्जेक्ट मॉडल (ओसीएक्स/एक्टिवएक्स/कॉम) और वितरित घटक वस्तु मॉडल
 * TASCS - उन्नत वैज्ञानिक घटक सॉफ्टवेयर के लिए प्रौद्योगिकी के लिए SciDAC केंद्र
 * एफिल (प्रोग्रामिंग भाषा)
 * सन माइक्रोसिस्टम्स (अब Oracle Corporation) से एंटरप्राइज़ JavaBeans
 * प्रवाह आधारित प्रोग्रामिंग
 * ऑब्जेक्टवेब से भग्न घटक मॉडल
 * मिडगार्ड (सॉफ्टवेयर) और पीएचपी के लिए मिडकॉम घटक ढांचा
 * ओबेरॉन (प्रोग्रामिंग लैंग्वेज), घटक पास्कल  और  ब्लैकबॉक्स घटक बिल्डर
 * वन-आईआईएसटी से घटक आधारित मॉडल संचालित डिजाइन की आरसीओएस (कंप्यूटर विज्ञान) विधि
 * ObjectWeb से SOFA घटक प्रणाली
 * ई> Microsoft .NET में नाम स्थान
 * एकता टेक्नोलॉजीज द्वारा विकसित यूनिटी (गेम इंजन)।
 * एपिक गेम्स द्वारा विकसित अवास्तविक इंजन
 * OpenOffice.org ऑफिस सूट से यूनिवर्सल नेटवर्क ऑब्जेक्ट्स
 * बोरलैंड और इसी तरह के मुफ्त लाजर (सॉफ्टवेयर) पुस्तकालय से क्रॉस प्लेटफॉर्म के लिए विजुअल कंपोनेंट लाइब्रेरी और कंपोनेंट लाइब्रेरी।
 * Mozilla Foundation की ओर से XPCOM
 * यौगिक दस्तावेज़ प्रौद्योगिकियाँ
 * ओबेरॉन (ऑपरेटिंग सिस्टम) और ब्लैकबॉक्स कंपोनेंट बिल्डर में सक्रिय दस्तावेज़
 * केपार्ट्स, कहाँ  यौगिक दस्तावेज़ प्रौद्योगिकी
 * ऑब्जेक्ट लिंकिंग और एम्बेडिंग (OLE)
 * ओपनडॉक
 * वितरित कंप्यूटिंग सॉफ्टवेयर घटक
 * माइक्रोसॉफ्ट से नेट रीमोटिंग
 * 9P (प्रोटोकॉल) बेल लैब्स से प्लान 9 के लिए विकसित प्रोटोकॉल वितरित किया गया, और इन्फर्नो (ऑपरेटिंग सिस्टम) और अन्य सिस्टम द्वारा उपयोग किया गया।
 * CORBA और CORBA घटक मॉडल वस्तु प्रबंधन समूह से
 * डी-बस freedesktop.org संगठन से
 * Microsoft से वितरित घटक ऑब्जेक्ट मॉडल और घटक ऑब्जेक्ट मॉडल (और COM+) के बाद के संस्करण
 * आईबीएम से डीएसओएम और सिस्टम ऑब्जेक्ट मॉडल (अब रद्द कर दिया गया)
 * ज़ीरोसी से इंटरनेट संचार इंजन
 * सन माइक्रोसिस्टम्स से चल देना
 * दोस्त कंप्यूटर विज्ञान के स्वीडिश संस्थान से
 * OpenOffice.org से यूनिवर्सल नेटवर्क ऑब्जेक्ट्स (यूएनओ)।
 * वेब सेवाएं
 * प्रतिनिधित्ववादी स्थिति में स्थानांतरण
 * ज़ोप कॉर्पोरेशन से ज़ोप
 * AXCIOMA (वितरित, रीयल-टाइम और एम्बेडेड सिस्टम के लिए घटक ढांचा) [https:// द्वारा www.remedy.nl उपाय आईटी]
 * COHORTE isandlaTech द्वारा मजबूत और भरोसेमंद वितरित सेवा-उन्मुख घटक-आधारित अनुप्रयोगों को निष्पादित करने और प्रबंधित करने के लिए क्रॉस-प्लेटफ़ॉर्म रनटाइम
 * DX-MAN सर्विस मॉडल
 * सामान्य प्रोग्रामिंग एल्गोरिदम को डेटा प्रतिनिधित्व से अलग करने पर जोर देती है
 * इंटरफ़ेस विवरण भाषाएँ (IDLs)
 * ओपन सर्विस इंटरफेस परिभाषाएँ (OSIDs)
 * कंपोनेंट ऑब्जेक्ट मॉडल और कॉरबा दोनों का हिस्सा
 * प्लेटफ़ॉर्म-स्वतंत्र घटक मॉडलिंग भाषा
 * एसआईडीएल - वैज्ञानिक इंटरफ़ेस परिभाषा भाषा
 * बेबेल मिडलवेयर साइंटिफिक प्रोग्रामिंग लैंग्वेज इंटरऑपरेबिलिटी सिस्टम का हिस्सा (SIDL और बैबल सामान्य घटक वास्तुकला  और SciDAC TASCS सेंटर की मुख्य प्रौद्योगिकियां हैं - ऊपर देखें।)
 * विश्वव्यापी वेब संकाय (W3C) से SOAP इंटरफ़ेस विवरण भाषा
 * डब्ल्यूडीडीएक्स
 * XML-RPC, SOAP का पूर्ववर्ती
 * नियंत्रण का उलटा (आईओसी) और सादा पुराना सी ++/जावा ऑब्जेक्ट (पीओसीओ/पीओजेओ) घटक ढांचे
 * पाइपलाइन (सॉफ्टवेयर)
 * यूनिक्स ऑपरेटिंग सिस्टम

यह भी देखें

 * व्यापार का तर्क
 * मॉड्यूलर प्रोग्रामिंग
 * सेवा घटक वास्तुकला (एससीए)
 * सॉफ्टवेयर कम्युनिकेशंस आर्किटेक्चर (JTRS SCA)
 * तृतीय-पक्ष सॉफ़्टवेयर घटक
 * वेब सेवा
 * वेब घटक

अग्रिम पठन

 * Brad J. Cox, Andrew J. Novobilski (1991). Object-Oriented Programming: An Evolutionary Approach. 2nd ed. Addison-Wesley, Reading ISBN 0-201-54834-8
 * Bertrand Meyer (1997). Object-Oriented Software Construction. 2nd ed. Prentice Hall.
 * George T. Heineman, William T. Councill (2001). Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley Professional, Reading 2001 ISBN 0-201-70485-4
 * Richard Veryard (2001). Component-based business : plug and play. London : Springer. ISBN 1-85233-361-8
 * Clemens Szyperski, Dominik Gruntz, Stephan Murer (2002). Component Software: Beyond Object-Oriented Programming. 2nd ed. ACM Press - Pearson Educational, London 2002 ISBN 0-201-74572-0

बाहरी संबंध

 * Why Software Reuse has Failed and How to Make It Work for You by Douglas C. Schmidt
 * What is the True essence and reality of CBD? (Evidence to show existing CBD paradigm is flawed)
 * comprehensive list of Component Systems on SourceForge
 * Brief Introduction to Real COP (Component Oriented Programming) by Using a small GUI application as an example