Detecting Object-Oriented Code Smells through Social Network Analysis
यह शोध पत्र सॉफ्टवेयर घटकों और उनकी अंतःक्रियाओं को सामाजिक नेटवर्क के रूप में मॉडल करके और चार जावा ओपन-सोर्स प्रोजेक्ट्स पर सोशल नेटवर्क एनालिसिस (SNA) मेट्रिक्स लागू करके ऑब्जेक्ट-ओरिएंटेड कोड स्मेल्स का पता लगाने के लिए एक नवीन दृष्टिकोण प्रस्तावित करता है ताकि छिपे हुए डिज़ाइन दोषों को उजागर किया जा सके।
मूल पेपर CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
सॉफ्टवेयर अनगिनत छोटी निर्देशों से बना होता है जो एक साथ मिलकर काम करते हैं, ठीक वैसे ही जैसे एक शहर व्यक्तिगत इमारतों और उन्हें जोड़ने वाली सड़कों से बना होता है। जब एक शहर अच्छी तरह से नियोजित होता है, तो यातायात सुचारू रूप से चलता है, और नए मोहल्ले बिना किसी अराजकता के जोड़े जा सकते हैं। कंप्यूटर प्रोग्रामिंग की दुनिया में, इस संगठन को "ऑब्जेक्ट-ओरिएंटेड डिज़ाइन" कहा जाता है, जहाँ कोड को स्व-निहित इकाइयों में समूहीकृत किया जाता है जो एक-दूसरे के साथ परस्पर क्रिया करते हैं। हालाँकि, जिस तरह एक शहर भीड़भाड़ वाले चौराहों या परित्यक्त इमारतों से ग्रस्त हो सकता है, सॉफ्टवेयर में भी "कोड स्मेल्स" (code smells) नामक संरचनात्मक दोष विकसित हो सकते हैं। ये वे त्रुटियाँ नहीं हैं जो प्रोग्राम को क्रैश कर दें, बल्कि ये संकेत हैं कि डिज़ाइन अव्यवस्थित, समझने में कठिन या ठीक करने में मुश्किल होता जा रहा है। यदि इन्हें अनियंत्रित छोड़ दिया जाए, तो ये सॉफ्टवेयर को नाजुक और रखरखाव के लिए महंगा बना देते हैं, जिससे डेवलपर्स को नए फीचर्स बनाने के बजाय गांठें सुलझाने में अधिक समय खर्च करना पड़ता है।
द दशकों से, शोधकर्ताओं ने इन दोषों को स्वचालित रूप से खोजने का प्रयास किया है, अक्सर कोड की पंक्तियों को गिनकर या यह मापकर कि एक एकल खंड कितने वेरिएबल्स का उपयोग करता है। सहायक होने के बावजूद, ये पारंपरिक तरीके कभी-कभी बड़ी तस्वीर को देखने में विफल रहते हैं, क्योंकि वे यह देखने में असमर्थ होते हैं कि सिस्टम के विभिन्न हिस्से जटिल तरीकों से एक-दूसरे पर कैसे निर्भर हैं। किंग सऊद यूनिवर्सिटी के मोहम्मद मद्दह द्वारा हाल ही में किए गए एक अध्ययन में विस्तृत एक नया दृष्टिकोण सुझाव देता है कि सॉफ्टवेयर को केवल फाइलों के संग्रह के रूप में नहीं, बल्कि एक सोशल नेटवर्क के रूप में देखा जाए। इस दृष्टिकोण में, कोड का प्रत्येक 'क्लास' एक व्यक्ति है, और हर बार जब कोड का एक हिस्सा दूसरे का उपयोग करता है, तो वह एक सामाजिक संपर्क होता है। मानव समुदायों में मित्रता और प्रभाव का मानचित्र बनाने के लिए उपयोग किए जाने वाले समान गणितीय उपकरणों को लागू करके, शोधकर्ता ने इन संरचनात्मक कमजोरियों को अधिक स्पष्टता के साथ पहचानने का एक तरीका विकसित किया।
अध्ययन ने जावा भाषा में लिखे गए चार प्रसिद्ध, ओपन-सोर्स सॉफ्टवेयर प्रोजेक्ट्स पर ध्यान केंद्रित किया: JUnit, Spring, Apache Commons BCEL, और Guava। ये प्रोजेक्ट आकार में काफी भिन्न हैं, जो कुछ सौ से लेकर चार हजार से अधिक विशिष्ट कोड इकाइयों तक विस्तृत हैं। इनका विश्लेषण करने के लिए, शोधकर्ता ने पहले इन प्रोजेक्ट्स के भीतर प्रत्येक क्लास को निकाला और यह मानचित्रित किया कि वे आपस में कैसे क्रिया करते हैं। यदि एक क्लास को दूसरे से डेटा या फंक्शन की आवश्यकता थी, तो उनके बीच एक रेखा खींची गई, जिससे कनेक्शनों का एक विशाल जाल बन गया। इस जाल को फिर 'गेफी' (Gephi) नामक एक विशेष विज़ुअलाइज़ेशन टूल में इम्पोर्ट किया गया, जिसने शोधकर्ता को पूरे सॉफ्टवेयर को एक एकल, परस्पर जुड़े हुए मानचित्र के रूप में देखने की अनुमति दी।
एक बार जब सॉफ्टवेयर को नेटवर्क के रूप में मॉडल कर लिया गया, तो शोधकर्ता ने "स्मेल्स" की पहचान करने के लिए विशिष्ट मापों को लागू किया। एक सोशल नेटवर्क में, एक व्यक्ति जो सभी को जानता है और कई चर्चाओं के केंद्र में बैठता है, अत्यधिक जुड़ा हुआ होता है। सॉफ्टवेयर में, एक क्लास जो अन्य बहुत सी क्लासेस के साथ संवाद करती है, अक्सर एक "गॉड क्लास" (God Class) का संकेत देती है—एक ऐसी इकाई जिसने बहुत सारी जिम्मेदारियां ले ली हैं और सब कुछ करने की कोशिश कर रही है। इसके विपरीत, एक व्यक्ति जो किसी को नहीं जानता और मानचित्र के किनारे पर अकेला बैठा है, वह "डेड कोड" (Dead Code) का प्रतिनिधित्व करता है, जो सॉफ्टवेयर का एक ऐसा हिस्सा है जिसका अब उपयोग नहीं किया जाता है। अन्य पैटर्न, जैसे कि लोगों का एक समूह जो केवल आपस में बात करता है लेकिन बाहरी दुनिया से कभी नहीं जुड़ता, या एक अकेला व्यक्ति जो दो अलग-अलग समूहों के बीच एकमात्र सेतु के रूप में कार्य करता है, ने "डेटा क्लासेस" (Data Classes) जैसे दोषों को उजागर किया जो बिना कुछ किए केवल जानकारी रखते हैं, या "शॉटगन सर्जरी" (Shotgun Surgery), जहाँ एक एकल परिवर्तन के लिए कई अलग-अलग स्थानों में संशोधनों की आवश्यकता होती है।
परिणामों ने दिखाया कि यह नेटवर्क-आधारित विधि प्रभावी रूप से स्वस्थ कोड के विशाल बहुमत को फ़िल्टर कर सकती है, जिससे डेवलपर्स के पास निरीक्षण के लिए संदिग्धों की एक बहुत छोटी सूची बच जाती है। अध्ययन किए गए सबसे बड़े प्रोजेक्ट में, जिसमें चार हजार से अधिक क्लासेस थीं, इस विधि ने केवल 17 प्रतिशत को संभावित रूप से समस्याग्रस्त के रूप में चिह्नित किया। लगभग एक हजार क्लासेस वाले एक अन्य प्रोजेक्ट में, इसने लगभग 35 प्रतिशत को ध्यान देने की आवश्यकता के रूप में पहचाना। विज़ुअलाइज़ेशन टूल्स ने इन निष्कर्षों को तत्काल और सहज बना दिया; "गॉड क्लासेस" मानचित्र के केंद्र में बड़े, चमकीले रंग के केंद्रों के रूप में दिखाई दिए, जबकि "डेड कोड" और "अनयूज्ड क्लासेस" छोटे, धुंधले नोड्स के रूप में दिखाई दिए जो किनारों पर धकेले गए थे, अक्सर अपने स्वयं के अलग-थलग द्वीपों में स्थित थे।
यह दृष्टिकोण यह दावा नहीं करता है कि यह मानवीय निर्णय की जगह लेगा या बिना किसी त्रुटि के हर एक दोष की सटीक पहचान करेगा। इसके बजाय, यह एक शक्तिशाली 'ट्राइएज टूल' (triage tool) के रूप में कार्य करता है, जो पूरे कोडबेस की समीक्षा करने के भारी कार्य को सबसे संरचनात्मक रूप से असामान्य हिस्सों की एक प्रबंधनीय सूची तक कम करने का एक तरीका है। केवल कोड की आंतरिक सामग्री के बजाय उसके टुकड़ों के बीच के संबंधों पर ध्यान केंद्रित करके, यह विधि एक पुराने प्रश्न पर एक नया दृष्टिकोण प्रदान करती है। यह सुझाव देती है कि एक सॉफ्टवेयर सिस्टम का स्वास्थ्य अक्सर उसके कनेक्शनों के पैटर्न में दिखाई देता है, और इन पैटर्नों को मैप करके, डेवलपर्स उन छिपी हुई कमजोरियों को ढूंढ सकते हैं जो उनकी डिजिटल रचनाओं की स्थिरता के लिए खतरा बनी हुई हैं, इससे पहले कि वे अनियंत्रित हो जाएं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।