Get best of the week

OS Sivelkiriya: सॉफ्टवेयर विकास प्रक्रिया

हेलो, हैबर।

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

सॉफ्टवेयर विकास की प्रक्रिया


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

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

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

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

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

डेवलपर्स की बातचीत का संगठन


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

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

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

इंटरफेस के पुराने संस्करण या तो एक दूसरे के साथ संगत हो सकते हैं या नहीं। उदाहरण के लिए, ध्रुवीय निर्देशांक का उपयोग करने के लिए कार्तीय निर्देशांक में स्क्रीन पर बिंदुओं की स्थिति पर विचार करने से आगे बढ़ने के काल्पनिक मामले में, "प्वाइंट स्थिति 1.0" इंटरफ़ेस कार्टेशियन निर्देशांक का उपयोग करता है, जबकि "प्वाइंट स्थिति 2.0" इंटरफ़ेस में ध्रुवीय निर्देशांक में प्रतिनिधित्व होता है। चूंकि इन दो अभ्यावेदन के बीच एक-से-एक पत्राचार होता है, ऑपरेटिंग सिस्टम हमेशा मामलों में निर्देशांक को पुनर्गणना कर सकता है जब उपयोग किए गए इंटरफ़ेस का वास्तविक संस्करण अपेक्षित से भिन्न होता है।

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

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

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

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

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

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

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

श्रृंखला के पिछले लेख यहां उपलब्ध हैं: एक , दो , तीन । पूर्ण पाठ, पहले की तरह, परियोजना की वेबसाइट पर उपलब्ध है ।

More articles:


All Articles