1सी:एंटरप्राइज़ डेवलपमेंट टूल्स के लिए एक प्रौद्योगिकी मंच के रूप में ग्रहण

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

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

ग्रहण वास्तुकला का परिचय

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

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

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

चावल। 1. ग्रहण प्लेटफार्म और जेडीटी

आइए एक्लिप्स प्लेटफ़ॉर्म के मुख्य घटकों को सूचीबद्ध करें:

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

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

कोर रनटाइम

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

मुख्य कार्यक्षेत्र

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

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

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

चावल। 2. आईरिसोर्स और रिसोर्सइन्फो

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

• हैंडल एक वैल्यू ऑब्जेक्ट है। मूल्य वस्तुएं अपरिवर्तनीय वस्तुएं हैं जिनकी समानता पहचान पर आधारित नहीं है। ऐसी वस्तुओं को हैशेड कंटेनरों में चाबी के रूप में सुरक्षित रूप से उपयोग किया जा सकता है। हैंडल के एकाधिक उदाहरण एक ही संसाधन को संदर्भित कर सकते हैं। उनकी तुलना करने के लिए, आपको बराबर (ऑब्जेक्ट) विधि का उपयोग करने की आवश्यकता है।
• हैंडल किसी संसाधन के व्यवहार को परिभाषित करता है, लेकिन इसमें संसाधन की स्थिति के बारे में जानकारी नहीं होती है (यह संग्रहीत एकमात्र डेटा "कुंजी", संसाधन का पथ) है।
• हैंडल एक ऐसे संसाधन को संदर्भित कर सकता है जो मौजूद नहीं है (या तो एक संसाधन जो अभी तक नहीं बनाया गया है, या एक संसाधन जो पहले ही हटा दिया गया है)। IResource.exists() विधि का उपयोग करके किसी संसाधन के अस्तित्व की जाँच की जा सकती है।
• कुछ ऑपरेशनों को केवल हैंडल में संग्रहीत जानकारी (तथाकथित हैंडल-ओनली ऑपरेशंस) के आधार पर कार्यान्वित किया जा सकता है। उदाहरण हैं IResource.getParent(), getFullPath(), आदि। ऐसे ऑपरेशन के सफल होने के लिए संसाधन का मौजूद होना आवश्यक नहीं है। जिन ऑपरेशनों को सफल होने के लिए संसाधन की आवश्यकता होती है, यदि संसाधन मौजूद नहीं है तो CoreException को फेंक दें।

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

चावल। 3. IResourceChangeEvent और IResourceDelta

संसाधन डेल्टा पर आधारित अधिसूचना तंत्र में निम्नलिखित विशेषताएं हैं:

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

जैसा कि हम जल्द ही देखेंगे, संसाधन मॉडल परिवर्तन अधिसूचना तंत्र के डिजाइन के मुख्य घटक अन्य हैंडल-आधारित मॉडल के लिए भी प्रासंगिक हैं।

जेडीटी कोर

एक्लिप्स कार्यक्षेत्र संसाधन मॉडल एक मौलिक भाषा-अज्ञेयवादी मॉडल है। जेडीटी कोर घटक (प्लगइन org.eclipse.jdt.core) जावा परिप्रेक्ष्य से कार्यक्षेत्र संरचना को नेविगेट करने और विश्लेषण करने के लिए एक एपीआई प्रदान करता है, तथाकथित "जावा मॉडल" (जावा मॉडल). इस एपीआई को अंतर्निहित संसाधन मॉडल एपीआई के विपरीत, जावा तत्वों के संदर्भ में परिभाषित किया गया है, जिसे फ़ोल्डर्स और फ़ाइलों के संदर्भ में परिभाषित किया गया है। जावा एलिमेंट ट्री के मुख्य इंटरफ़ेस चित्र में दिखाए गए हैं। 4.

चावल। 4. जावा मॉडल तत्व

जावा मॉडल संसाधन मॉडल के समान हैंडल/बॉडी मुहावरे का उपयोग करता है (चित्र 5)। IJavaElement हैंडल है, और JavaElementInfo बॉडी की भूमिका निभाता है। IJavaElement इंटरफ़ेस सभी जावा तत्वों के लिए सामान्य प्रोटोकॉल को परिभाषित करता है। इसकी कुछ विधियाँ केवल हैंडल के लिए हैं: getElementName(), getParent(), आदि। JavaElementInfo ऑब्जेक्ट संबंधित तत्व की स्थिति को संग्रहीत करता है: इसकी संरचना और विशेषताएँ।

चावल। 5. IJavaElement और JavaElementInfo

संसाधन मॉडल की तुलना में जावा मॉडल में बुनियादी हैंडल/बॉडी डिज़ाइन के कार्यान्वयन में कुछ अंतर हैं। जैसा कि ऊपर उल्लेख किया गया है, संसाधन मॉडल में, तत्व वृक्ष, जिसके नोड संसाधन जानकारी ऑब्जेक्ट हैं, पूरी तरह से मेमोरी में समाहित है। लेकिन जावा मॉडल में संसाधन वृक्ष की तुलना में काफी बड़ी संख्या में तत्व हो सकते हैं, क्योंकि यह .java और .class फ़ाइलों की आंतरिक संरचना का भी प्रतिनिधित्व करता है: प्रकार, फ़ील्ड और विधियाँ।

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

जावा तत्वों में परिवर्तनों को सूचित करने का तंत्र सामान्यतः ऊपर चर्चा किए गए कार्यक्षेत्र संसाधनों में परिवर्तनों को ट्रैक करने के तंत्र के समान है। जावा मॉडल में परिवर्तनों की निगरानी करने का इच्छुक ग्राहक सूचनाओं की सदस्यता लेता है, जिन्हें एक ElementChangedEvent ऑब्जेक्ट के रूप में दर्शाया जाता है जिसमें IJavaElementDelta (चित्र 6) होता है।

चावल। 6. एलिमेंटचेंज्डइवेंट और IJavaElementDelta

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

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

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

1C:एंटरप्राइज़ डेवलपमेंट टूल्स में उपयोग किए गए ग्रहण घटक

चित्र में. चित्र 7 एक्लिप्स घटकों को दिखाता है जो 1C:एंटरप्राइज़ डेवलपमेंट टूल्स के लिए प्रौद्योगिकी प्लेटफ़ॉर्म की नींव बनाते हैं।

चावल। 7. 1सी:एंटरप्राइज़ डेवलपमेंट टूल्स के लिए एक मंच के रूप में ग्रहण

ग्रहण मंच बुनियादी ढांचा उपलब्ध कराता है. हमने पिछले अनुभाग में इस बुनियादी ढांचे के कुछ पहलुओं को देखा।

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

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

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

1सी: एंटरप्राइज डेवलपमेंट टूल्स सक्रिय रूप से ईएमएफ और कई अन्य ग्रहण मॉडलिंग परियोजनाओं दोनों का उपयोग करते हैं। विशेष रूप से, Xtext ऐसी 1C:एंटरप्राइज़ भाषाओं के लिए अंतर्निहित प्रोग्रामिंग भाषा और क्वेरी भाषा के रूप में विकास उपकरणों की नींव में से एक है। इन विकास उपकरणों का एक अन्य आधार एक्लिप्स हैंडली प्रोजेक्ट है, जिस पर हम अधिक विस्तार से चर्चा करेंगे (सूचीबद्ध एक्लिप्स घटकों में से, यह अभी भी सबसे कम ज्ञात है)।

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

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

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

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

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

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

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

चावल। 8. हैंडली तत्वों के सामान्य इंटरफेस और बुनियादी कार्यान्वयन

IElement इंटरफ़ेस एक तत्व के हैंडल का प्रतिनिधित्व करता है और सभी Handly-आधारित मॉडल के तत्वों के लिए सामान्य है। अमूर्त वर्ग एलिमेंट सामान्यीकृत हैंडल/बॉडी तंत्र को लागू करता है (चित्र 9)।

चावल। 9. IElement और सामान्य हैंडल/बॉडी कार्यान्वयन

इसके अलावा, हैंडली मॉडल तत्वों में परिवर्तन के बारे में सूचित करने के लिए एक सामान्यीकृत तंत्र प्रदान करता है (चित्र 10)। जैसा कि आप देख सकते हैं, यह मोटे तौर पर संसाधन मॉडल और जावा मॉडल में लागू अधिसूचना तंत्र के समान है, और तत्व परिवर्तन जानकारी का एकीकृत प्रतिनिधित्व प्रदान करने के लिए IElementDelta का उपयोग करता है।

चावल। 10. हैंडली अधिसूचना तंत्र के सामान्य इंटरफेस और बुनियादी कार्यान्वयन

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

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

जैसा कि पहले उल्लेख किया गया है, हैंडली के प्रारंभिक डिजाइन और उसके बाद के विकास के दौरान एक प्रमुख फोकस स्केलेबिलिटी और लचीलेपन पर था और जारी रहेगा।

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

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

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

वर्तमान संस्करण हैंडली 0.6 दिसंबर 2016 में सामने आया। इस तथ्य के बावजूद कि परियोजना वर्तमान में ऊष्मायन की स्थिति में है और एपीआई अभी तक अंतिम रूप से तय नहीं किया गया है, हैंडली का उपयोग पहले से ही दो बड़े वाणिज्यिक उत्पादों में किया गया है जिन्होंने "प्रारंभिक अपनाने वालों" के रूप में कार्य करने का जोखिम उठाया है, और, मुझे कहना होगा, अभी तक पछतावा मत करो.

जैसा कि ऊपर बताया गया है, इन उत्पादों में से एक 1C:एंटरप्राइज़ डेवलपमेंट टूल्स है, जहां Handly का उपयोग शुरुआत से ही ऐसी 1C:एंटरप्राइज़ भाषाओं की उच्च-स्तरीय संरचना के तत्वों को अंतर्निहित प्रोग्रामिंग भाषा और क्वेरी भाषा के रूप में मॉडल करने के लिए किया जाता है। . एक अन्य उत्पाद के बारे में आम जनता को कम जानकारी है। यह कोडासिप स्टूडियो, एप्लिकेशन-विशिष्ट इंस्ट्रक्शन-सेट प्रोसेसर (एएसआईपी) के लिए एक एकीकृत डिज़ाइन वातावरण, जिसका उपयोग चेक कंपनी कोडासिप के भीतर और उसके ग्राहकों द्वारा किया जाता है, जिसमें शामिल हैं एएमडी, एवीजी, मोबाइलये, सिग्मा डिजाइन. कोडासिप 2015 से हैंडली 0.2 संस्करण से शुरू होकर उत्पादन में हैंडली का उपयोग कर रहा है। कोडसिप स्टूडियो की नवीनतम रिलीज़ जून 0.5 में रिलीज़ संस्करण 2016 का उपयोग करती है। कोडासिप में आईडीई विकास का नेतृत्व करने वाले ओन्ड्रेज इलिक, परियोजना के संपर्क में हैं, और "तृतीय पक्ष अपनाने वाले" की ओर से महत्वपूर्ण प्रतिक्रिया प्रदान कर रहे हैं। वह हैंडली उदाहरणों में से एक, जावा मॉडल के लिए यूआई परत (कोड की ~ 4000 लाइनें) को लागू करने, परियोजना के विकास में सीधे भाग लेने के लिए कुछ खाली समय खोजने में भी सक्षम था। गोद लेने वालों द्वारा हैंडली के उपयोग के बारे में अधिक विस्तृत प्रत्यक्ष जानकारी पृष्ठ पर पाई जा सकती है सफलता की कहानियां परियोजना।

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

स्रोत: www.habr.com