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

From Vigyanwiki
एकीकृत मॉडलिंग भाषा 2.0 में अभिव्यक्त दो घटकों का एक उदाहरण। चेकआउट घटक, जो ग्राहक के आदेश को सुविधाजनक बनाने के लिए जिम्मेदार है, को ग्राहक के क्रेडिट/डेबिट कार्ड (बाद में प्रदान की जाने वाली कार्यक्षमता) को चार्ज करने के लिए कार्ड प्रोसेसिंग घटक की आवश्यकता होती है।

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

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

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

घटकों की परिभाषा और विशेषताएं

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

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

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

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

कई सॉफ्टवेयर घटकों का एक सरल उदाहरण - एकीकृत मॉडलिंग भाषा 2.0 में प्रस्तुत एक काल्पनिक अवकाश-आरक्षण प्रणाली के भीतर चित्रित।

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

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

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

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

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

एक ऐसे सॉफ़्टवेयर घटक को लिखने के लिए महत्वपूर्ण प्रयास और जागरूकता की आवश्यकता होती है जो प्रभावी रूप से पुन: प्रयोज्य हो। घटक की जरूरत है:

  • पूरी तरह से दस्तावेज
  • अच्छी तरह से परीक्षण किया
    • मजबूत - व्यापक इनपुट-वैधता जाँच के साथ
    • उपयुक्त त्रुटि संदेश या वापसी कोड वापस करने में सक्षम
  • जागरूकता के साथ डिजाइन किया गया है कि इसे अप्रत्याशित उपयोगों के लिए रखा जाएगा

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

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


इतिहास

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

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

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

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

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

आर्किटेक्चर

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

घटक मॉडल

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

टेक्नोलॉजीज

यह भी देखें

संदर्भ

  1. Foukalas et al "Protocol Reconfiguration Using Component-Based Design"
  2. Wallace, Bruce (May 19, 2010). "हर घटक के लिए एक छेद, और उसके छेद में हर घटक". Existential Programming. There is no such thing as a Component
  3. McIlroy, Malcolm Douglas (January 1969). "बड़े पैमाने पर सॉफ्टवेयर घटकों का उत्पादन किया" (PDF). Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968. Scientific Affairs Division, NATO. p. 79.
  4. Rainer Niekamp. "Software Component Architecture" (PDF). Gestión de Congresos - CIMNE/Institute for Scientific Computing, TU Braunschweig. p. 4. Retrieved 2011-07-29. The modern concept of a software component largely defined by Brad Cox of Stepstone, => Objective-C programming language
  5. Raphael Gfeller (December 9, 2008). "Upgrading of component-based application". HSR - Hochschule für Technik Rapperswill. p. 4. Retrieved 2011-07-29. 1990, IBM invents their System Object Model. 1990, as a reaction, Microsoft released OLE 1.0 OLE custom controls (OCX)[permanent dead link]
  6. 6.0 6.1 Crnkovic, I.; Sentilles, S.; Vulgarakis, A.; Chaudron, M. R. V. (2011). "सॉफ्टवेयर घटक मॉडल के लिए एक वर्गीकरण ढांचा". IEEE Transactions on Software Engineering. 37 (5): 593–615. doi:10.1109/TSE.2010.83. S2CID 15449138.
  7. Lau, Kung-Kiu; Wang, Zheng (2007). "सॉफ्टवेयर घटक मॉडल". IEEE Transactions on Software Engineering. 33 (10): 709–724. doi:10.1109/TSE.2007.70726. ISSN 0098-5589.
  8. Lau, Kung-Kiu; Velasco Elizondo, Perla; Wang, Zheng (2005). Heineman, George T.; Crnkovic, Ivica; Schmidt, Heinz W.; Stafford, Judith A.; Szyperski, Clemens; Wallnau, Kurt (eds.). "सॉफ्टवेयर घटकों के लिए बहिर्जात कनेक्टर्स". Component-Based Software Engineering. Lecture Notes in Computer Science (in English). Springer Berlin Heidelberg. 3489: 90–106. doi:10.1007/11424529_7. ISBN 9783540320494. S2CID 17971442.
  9. MASH defines assets as people, property and information and management as monitoring, control and configuration. Presented at the 2013 IEEE IoT conference in Mountain View MASH includes a full IDE, Android client and runtime. "MASH YouTube channel"
  10. A component-oriented approach is an ideal way to handle the diversity of software in consumer electronics. The Koala model, used for embedded software in TV sets, allows late binding of reusable components with no additional overhead. [1]
  11. Component model for embedded devices like TV developed by Philips based on paper by van Ommering, R.: Koala, a Component Model for Consumer Electronics Product Software [2] Archived 2014-08-09 at the Wayback Machine
  12. Arad, Cosmin (April 2013). पुनर्विन्यास योग्य वितरित प्रणालियों के लिए प्रोग्रामिंग मॉडल और प्रोटोकॉल (PDF). ISBN 978-91-7501-694-8. {{cite book}}: |work= ignored (help)
  13. Arellanes, Damian; Lau, Kung-Kiu (2017). "पदानुक्रमित सेवा संरचना के लिए बहिर्जात कनेक्टर्स" (PDF). 2017 IEEE 10th Conference on Service-Oriented Computing and Applications (SOCA). Kanazawa: IEEE: 125–132. doi:10.1109/SOCA.2017.25. ISBN 9781538613269. S2CID 31211787.


अग्रिम पठन

  • 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


बाहरी संबंध