1C साठी तंत्रज्ञान प्लॅटफॉर्म म्हणून Eclipse: एंटरप्राइज डेव्हलपमेंट टूल्स

कदाचित, ग्रहण फार पूर्वीपासून विशेष परिचयाची गरज नाही. Eclipse Java डेव्हलपमेंट टूल्समुळे बरेच लोक एक्लिप्सशी परिचित आहेत (जेडीटी). हे लोकप्रिय मुक्त-स्रोत Java IDE आहे जे बहुतेक विकसक "Eclipse" शब्दाशी संबद्ध करतात. तथापि, Eclipse हे दोन्ही विकास साधने (Eclipse Platform) एकत्रित करण्यासाठी विस्तारण्यायोग्य प्लॅटफॉर्म आहे आणि JDT सह त्याच्या आधारावर तयार केलेल्या अनेक IDEs आहेत. Eclipse हा Eclipse प्रोजेक्ट, Eclipse Platform आणि JDT आणि Eclipse SDK, त्या विकासाचा परिणाम म्हणून समन्वय साधणारा उच्च-स्तरीय प्रकल्प आहे. शेवटी, Eclipse एक ओपन-सोर्स फाउंडेशन आहे ज्यामध्ये मोठ्या प्रमाणावर प्रकल्प आहेत, जे सर्व Java मध्ये लिहिलेले नाहीत किंवा विकास साधनांशी संबंधित नाहीत (उदाहरणार्थ, प्रकल्प ग्रहण IoT и ग्रहण विज्ञान). ग्रहण जग खूप वैविध्यपूर्ण आहे.

या लेखात, जे निसर्गाचे विहंगावलोकन आहे, आम्ही एकात्मिक विकास साधने तयार करण्यासाठी एक व्यासपीठ म्हणून ग्रहण आर्किटेक्चरच्या काही मूलभूत गोष्टींकडे पाहण्याचा प्रयत्न करू आणि तंत्रज्ञानाचा पाया तयार करणाऱ्या ग्रहण घटकांची प्रारंभिक कल्पना देऊ. "नवीन कॉन्फिगरेटर" 1C साठी प्लॅटफॉर्म: एंटरप्राइझ. 1C: एंटरप्राइज डेव्हलपमेंट टूल्स. अर्थात, असे पुनरावलोकन अपरिहार्यपणे मोठ्या प्रमाणावर वरवरचे आणि ऐवजी मर्यादित असेल, कारण आम्ही लक्ष्यित प्रेक्षक म्हणून केवळ Eclipse विकासकांवरच लक्ष केंद्रित करत नाही. तथापि, आम्हाला आशा आहे की अनुभवी एक्लिप्स विकसक देखील लेखातील मनोरंजक माहिती शोधण्यात सक्षम होतील. उदाहरणार्थ, आम्ही "ग्रहणाचे रहस्य" बद्दल बोलू, एक तुलनेने नवीन आणि अल्प-ज्ञात प्रकल्प. ग्रहण हाताने, ज्याची स्थापना आणि 1C द्वारे समर्थन केले गेले.

एक्लिप्स आर्किटेक्चरचा परिचय

उदाहरण वापरून प्रथम ग्रहण आर्किटेक्चरच्या काही सामान्य बाबी पाहू Eclipse Java विकास साधने (JDT). उदाहरण म्हणून जेडीटीची निवड अपघाती नाही. Eclipse मध्ये दिसणारे हे पहिले एकात्मिक विकास वातावरण आहे. इतर *DT Eclipse प्रकल्प, जसे की Eclipse C/C++ डेव्हलपमेंट टूलिंग (CDT), नंतर तयार केले गेले आणि जेडीटीकडून मूलभूत वास्तुशास्त्रीय तत्त्वे आणि वैयक्तिक स्त्रोत कोडचे तुकडे दोन्ही घेतले. 1C:एंटरप्राइज डेव्हलपमेंट टूल्ससह ग्रहण प्लॅटफॉर्मच्या शीर्षस्थानी तयार केलेल्या जवळजवळ कोणत्याही IDE साठी JDT मध्ये मांडलेल्या आर्किटेक्चरची मूलभूत तत्त्वे आजपर्यंत संबंधित आहेत.

सर्व प्रथम, हे लक्षात घेतले पाहिजे की ग्रहण हे बर्‍यापैकी स्पष्ट आर्किटेक्चरल लेयरिंगद्वारे वैशिष्ट्यीकृत आहे, ज्यामध्ये विशिष्ट प्रोग्रामिंग भाषांना समर्थन देण्यासाठी डिझाइन केलेल्या कार्यक्षमतेपासून भाषा-स्वतंत्र कार्यक्षमतेचे पृथक्करण आणि संबंधित घटकांपासून UI-स्वतंत्र "कोर" घटक वेगळे करणे. समर्थन वापरकर्ता इंटरफेस सह.

अशा प्रकारे, Eclipse Platform एक सामान्य, भाषा-स्वतंत्र पायाभूत सुविधा परिभाषित करते आणि Java विकास साधने Eclipse मध्ये पूर्ण वैशिष्ट्यीकृत Java IDE जोडतात. एक्लिप्स प्लॅटफॉर्म आणि जेडीटी या दोन्ही घटकांमध्ये अनेक घटक असतात, त्यातील प्रत्येक एकतर UI-स्वतंत्र “कोर” किंवा UI स्तराशी संबंधित आहे (आकृती 1).

तांदूळ. 1. एक्लिप्स प्लॅटफॉर्म आणि जेडीटी

चला ग्रहण प्लॅटफॉर्मच्या मुख्य घटकांची यादी करूया:

• रनटाइम — प्लगइन इन्फ्रास्ट्रक्चर परिभाषित करते. ग्रहण हे मॉड्यूलर आर्किटेक्चरद्वारे वैशिष्ट्यीकृत आहे. मूलत:, ग्रहण हा "विस्तार बिंदू" आणि "विस्तार" यांचा संग्रह आहे.
• कार्यक्षेत्र - एक किंवा अधिक प्रकल्प व्यवस्थापित करते. प्रोजेक्टमध्ये फोल्डर्स आणि फाइल्स असतात ज्या थेट फाइल सिस्टममध्ये मॅप केल्या जातात.
• मानक विजेट टूलकिट (SWT) - ऑपरेटिंग सिस्टमसह एकत्रित केलेले मूलभूत वापरकर्ता इंटरफेस घटक प्रदान करते.
• जेफेस — SWT च्या वर तयार केलेले अनेक UI फ्रेमवर्क प्रदान करते.
• वर्कबेंच — Eclipse UI प्रतिमान परिभाषित करते: संपादक, दृश्ये, दृष्टीकोन.

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

कोर रनटाइम

Eclipse प्लगइन इन्फ्रास्ट्रक्चर आधारित आहे ओएसजी आणि प्रकल्पाद्वारे प्रदान केले जाते ग्रहण विषुव. प्रत्येक Eclipse प्लगइन एक OSGi बंडल आहे. OSGi स्पेसिफिकेशन, विशेषतः, आवृत्ती आणि अवलंबित्व निराकरणासाठी यंत्रणा परिभाषित करते. या मानक यंत्रणेच्या व्यतिरिक्त, इक्विनॉक्स ही संकल्पना सादर करते विस्तार बिंदू. प्रत्येक प्लगइन त्याचे स्वतःचे विस्तार बिंदू परिभाषित करू शकते आणि त्याच किंवा इतर प्लगइनद्वारे परिभाषित विस्तार बिंदू वापरून सिस्टममध्ये अतिरिक्त कार्यक्षमता (“विस्तार”) देखील सादर करू शकते. OSGi आणि Equinox यंत्रणांचे कोणतेही तपशीलवार वर्णन या लेखाच्या व्याप्तीच्या पलीकडे आहे. आपण फक्त लक्षात ठेवूया की एक्लिप्समध्ये मॉड्युलरायझेशन एकूण आहे (रनटाइमसह कोणतीही सबसिस्टम, एक किंवा अधिक प्लगइन्सचा समावेश आहे), आणि एक्लिप्समधील जवळजवळ प्रत्येक गोष्ट एक विस्तार आहे. शिवाय, ही तत्त्वे OSGi ची ओळख होण्याच्या खूप आधी Eclipse आर्किटेक्चरमध्ये एम्बेड केली गेली होती (त्यावेळी त्यांनी त्यांचे स्वतःचे तंत्रज्ञान वापरले, OSGi सारखेच).

कोर वर्कस्पेस

Eclipse प्लॅटफॉर्मच्या शीर्षस्थानी तयार केलेले जवळजवळ कोणतेही एकात्मिक विकास वातावरण Eclipse वर्कस्पेससह कार्य करते. हे कार्यक्षेत्र आहे ज्यामध्ये सहसा IDE मध्ये विकसित केलेल्या अनुप्रयोगाचा स्त्रोत कोड असतो. वर्कस्पेस मॅप थेट फाइल सिस्टमवर आणि त्यात फोल्डर्स आणि फाइल्स असलेले प्रोजेक्ट असतात. हे प्रकल्प, फोल्डर्स आणि फाइल्स म्हणतात संसाधने कार्यक्षेत्र Eclipse मधील कार्यक्षेत्र अंमलबजावणी फाइल सिस्टमच्या संबंधात कॅशे म्हणून काम करते, ज्यामुळे संसाधन वृक्षाच्या ट्रॅव्हर्सलला लक्षणीय गती देणे शक्य होते. याव्यतिरिक्त, कार्यक्षेत्र अनेक अतिरिक्त सेवा प्रदान करते, यासह संसाधन बदलांसाठी सूचना यंत्रणा и वाढीव बिल्डर पायाभूत सुविधा.

मुख्य संसाधन घटक (org.eclipse.core.resources प्लगइन) कार्यक्षेत्र आणि त्याच्या संसाधनांना समर्थन देण्यासाठी जबाबदार आहे. विशेषतः, हा घटक फॉर्ममध्ये कार्यक्षेत्रात प्रोग्रामेटिक प्रवेश प्रदान करतो संसाधन मॉडेल. या मॉडेलसह प्रभावीपणे कार्य करण्यासाठी, क्लायंटला संसाधनाची लिंक सादर करण्याचा एक सोपा मार्ग आवश्यक आहे. या प्रकरणात, क्लायंट ऍक्सेसमधून मॉडेलमधील संसाधनाची स्थिती थेट संग्रहित करणारी ऑब्जेक्ट लपवणे इष्ट असेल. अन्यथा, उदाहरणार्थ, फाइल हटवण्याच्या बाबतीत, क्लायंट पुढील समस्यांसह, मॉडेलमध्ये नसलेली एखादी वस्तू ठेवू शकेल. Eclipse नावाचे काहीतरी वापरून ही समस्या सोडवते हाताळू संसाधन हँडल एक की म्हणून कार्य करते (त्याला केवळ कार्यक्षेत्रातील संसाधनाचा मार्ग माहित आहे) आणि अंतर्गत मॉडेल ऑब्जेक्टवर प्रवेश पूर्णपणे नियंत्रित करते, जे थेट संसाधनाच्या स्थितीबद्दल माहिती संग्रहित करते. हे डिझाइन पॅटर्नची भिन्नता आहे हँडल/बॉडी.

तांदूळ. आकृती 2 संसाधन मॉडेलवर लागू केल्याप्रमाणे हँडल/बॉडी मुहावरे स्पष्ट करते. आयआरसोर्स इंटरफेस रिसोर्सच्या हँडलचे प्रतिनिधित्व करतो आणि एक API आहे, रिसोर्स क्लासच्या विपरीत, जो हा इंटरफेस लागू करतो आणि रिसोर्सइन्फो क्लास, जो मुख्य भागाचे प्रतिनिधित्व करतो, जे API नाहीत. आम्ही यावर जोर देतो की हँडलला फक्त वर्कस्पेस रूटच्या सापेक्ष संसाधनाचा मार्ग माहित असतो आणि त्यात संसाधन माहितीची लिंक नसते. संसाधन माहिती वस्तू तथाकथित "एलिमेंट ट्री" बनवतात. ही डेटा रचना पूर्णपणे मेमरीमध्ये साकारली आहे. हँडलशी संबंधित संसाधन माहितीचे उदाहरण शोधण्यासाठी, त्या हँडलमध्ये साठवलेल्या पथानुसार एलिमेंट ट्री ट्रॅव्हर्स केली जाते.

तांदूळ. 2. IRsource आणि ResourceInfo

जसे आपण नंतर पाहणार आहोत, संसाधन मॉडेलचे मूळ डिझाइन (आम्ही याला हँडल-आधारित म्हणू शकतो) इतर मॉडेल्ससाठी देखील ग्रहणात वापरले जाते. आत्तासाठी, या डिझाइनच्या काही विशिष्ट गुणधर्मांची यादी करूया:

• हँडल एक मूल्य वस्तू आहे. मूल्य वस्तू या अपरिवर्तनीय वस्तू आहेत ज्यांची समानता ओळखीवर आधारित नाही. हॅश केलेल्या कंटेनरमध्ये अशा वस्तू सुरक्षितपणे की म्हणून वापरल्या जाऊ शकतात. हँडलची अनेक उदाहरणे एकाच संसाधनाचा संदर्भ देऊ शकतात. त्यांची तुलना करण्यासाठी, तुम्हाला equals(Object) पद्धत वापरावी लागेल.
• हँडल संसाधनाच्या वर्तनाची व्याख्या करते, परंतु त्यात संसाधनाच्या स्थितीबद्दल माहिती नसते (केवळ तो संग्रहित केलेला डेटा "की", संसाधनाचा मार्ग आहे).
• हँडल अस्तित्वात नसलेल्या संसाधनाचा संदर्भ घेऊ शकते (एकतर अद्याप तयार न केलेले संसाधन किंवा आधीच हटवलेले संसाधन). IResource.exists() पद्धत वापरून संसाधनाचे अस्तित्व तपासले जाऊ शकते.
• काही ऑपरेशन्स केवळ हँडलमध्येच साठवलेल्या माहितीच्या आधारे अंमलात आणल्या जाऊ शकतात (तथाकथित हँडल-ओन्ली ऑपरेशन्स). उदाहरणे आहेत IResource.getParent(), getFullPath(), इ. असे ऑपरेशन यशस्वी होण्यासाठी संसाधन अस्तित्वात असणे आवश्यक नाही. ज्या ऑपरेशन्समध्ये यशस्वी होण्यासाठी संसाधन अस्तित्वात असणे आवश्यक आहे ते संसाधन अस्तित्वात नसल्यास CoreException टाकतात.

एक्लिप्स वर्कस्पेस रिसोर्स बदल सूचित करण्यासाठी एक कार्यक्षम यंत्रणा प्रदान करते (आकृती 3). रिसोर्सेस एकतर एक्लिप्स IDE मध्येच केलेल्या क्रियांच्या परिणामी किंवा फाइल सिस्टमसह सिंक्रोनाइझेशनच्या परिणामी बदलू शकतात. दोन्ही प्रकरणांमध्ये, नोटिफिकेशन्सचे सदस्यत्व घेतलेल्या क्लायंटना “रिसोर्स डेल्टा” च्या रूपात होणाऱ्या बदलांबद्दल तपशीलवार माहिती दिली जाते. डेल्टा वर्कस्पेस रिसोर्स (उप-)वृक्षाच्या दोन अवस्थांमधील बदलांचे वर्णन करतो आणि ते स्वतःच एक झाड आहे, ज्यातील प्रत्येक नोड संसाधनातील बदलाचे वर्णन करतो आणि पुढील स्तरावरील डेल्टाची सूची समाविष्ट करतो जी बाल संसाधनांमधील बदलांचे वर्णन करते.

तांदूळ. 3. IResourceChangeEvent आणि IResourceDelta

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

• एकच बदल आणि अनेक बदलांचे वर्णन समान रचना वापरून केले जाते, कारण डेल्टा पुनरावृत्ती रचनाच्या तत्त्वाचा वापर करून तयार केला जातो. सबस्क्राइबर क्लायंट डेल्टाच्या झाडाद्वारे रिकर्सिव्ह डिसेंट वापरून संसाधन बदल सूचनांवर प्रक्रिया करू शकतात.
• डेल्टामध्ये त्याच्या हालचाली आणि/किंवा त्याच्याशी संबंधित "मार्कर" मधील बदलांसह संसाधनातील बदलांबद्दल संपूर्ण माहिती असते (उदाहरणार्थ, संकलन त्रुटी मार्कर म्हणून दर्शविल्या जातात).
• संसाधन संदर्भ हँडलद्वारे केले जात असल्याने, डेल्टा नैसर्गिकरित्या रिमोट रिसोर्सचा संदर्भ देऊ शकतो.

जसे आपण लवकरच पाहणार आहोत, रिसोर्स मॉडेल चेंज नोटिफिकेशन मेकॅनिझमचे मुख्य घटक इतर हँडल-आधारित मॉडेल्ससाठी देखील संबंधित आहेत.

जेडीटी कोर

एक्लिप्स वर्कस्पेस रिसोर्स मॉडेल हे मूलभूत भाषा-अज्ञेयवादी मॉडेल आहे. JDT कोर घटक (plugin org.eclipse.jdt.core) जावा दृष्टीकोनातून कार्यक्षेत्र संरचनेचे नेव्हिगेट आणि विश्लेषण करण्यासाठी API प्रदान करते, तथाकथित "जावा मॉडेल" (जावा मॉडेल). हे API जावा घटकांच्या संदर्भात परिभाषित केले आहे, मूळ स्त्रोत मॉडेल API च्या विरूद्ध, जे फोल्डर आणि फाइल्सच्या संदर्भात परिभाषित केले आहे. जावा एलिमेंट ट्रीचे मुख्य इंटरफेस अंजीर मध्ये दर्शविले आहेत. 4.

तांदूळ. 4. Java मॉडेल घटक

Java मॉडेल संसाधन मॉडेल (आकृती 5) प्रमाणेच हँडल/बॉडी आयडियम वापरते. IJavaElement हे हँडल आहे आणि JavaElementInfo शरीराची भूमिका बजावते. IJavaElement इंटरफेस सर्व Java घटकांसाठी सामान्य प्रोटोकॉल परिभाषित करतो. त्याच्या काही पद्धती फक्त-हँडल आहेत: getElementName(), getParent(), इ. JavaElementInfo ऑब्जेक्ट संबंधित घटकाची स्थिती संग्रहित करते: त्याची रचना आणि गुणधर्म.

तांदूळ. 5. IJavaElement आणि JavaElementInfo

संसाधन मॉडेलच्या तुलनेत मूलभूत हँडल/बॉडी डिझाइनच्या अंमलबजावणीमध्ये Java मॉडेलमध्ये काही फरक आहेत. वर नमूद केल्याप्रमाणे, संसाधन मॉडेलमध्ये, एलिमेंट ट्री, ज्याचे नोड्स संसाधन माहिती ऑब्जेक्ट्स आहेत, पूर्णपणे मेमरीमध्ये समाविष्ट आहेत. परंतु Java मॉडेलमध्ये संसाधन वृक्षापेक्षा लक्षणीय प्रमाणात मोठ्या प्रमाणात घटक असू शकतात, कारण ते .java आणि .class फाइल्सची अंतर्गत रचना देखील दर्शवते: प्रकार, फील्ड आणि पद्धती.

मेमरीमधील घटकांचे संपूर्ण झाड पूर्णपणे साकार करणे टाळण्यासाठी, Java मॉडेल अंमलबजावणी घटक माहितीचा मर्यादित आकाराचा LRU कॅशे वापरते, जेथे की हँडल IJavaElement आहे. घटक माहिती वस्तू मागणीनुसार तयार केल्या जातात कारण घटक वृक्ष नेव्हिगेट केला जातो. या प्रकरणात, कमीत कमी वारंवार वापरल्या जाणार्‍या वस्तू कॅशेमधून काढून टाकल्या जातात आणि मॉडेलचा मेमरी वापर निर्दिष्ट कॅशे आकारापर्यंत मर्यादित राहतो. हँडल-आधारित डिझाइनचा हा आणखी एक फायदा आहे, जो क्लायंट कोडमधून असे अंमलबजावणी तपशील पूर्णपणे लपवतो.

Java घटकांमध्‍ये बदल सूचित करण्‍याची यंत्रणा सर्वसाधारणपणे वर चर्चा केलेल्या वर्कस्पेस संसाधनांमध्‍ये बदल ट्रॅक करण्‍याच्‍या यंत्रणेसारखीच असते. Java मॉडेलमधील बदलांचे निरीक्षण करू इच्छिणारा क्लायंट अधिसूचनांचे सदस्यत्व घेतो, ज्यात ElementChangedEvent ऑब्जेक्ट म्हणून प्रस्तुत केले जाते ज्यामध्ये IJavaElementDelta (आकृती 6) असते.

तांदूळ. 6. ElementChangedEvent आणि IJavaElementDelta

जावा मॉडेलमध्ये मेथड बॉडी किंवा नेम रिझोल्यूशनबद्दल माहिती नसते, म्हणून Java मध्ये लिहिलेल्या कोडच्या तपशीलवार विश्लेषणासाठी, JDT Core अतिरिक्त (नॉन-हँडल-आधारित) मॉडेल प्रदान करते: अमूर्त वाक्यरचना वृक्ष (अमूर्त वाक्यरचना वृक्ष, AST). AST स्त्रोत मजकूर पार्स करण्याचा परिणाम दर्शवतो. एएसटी नोड्स स्त्रोत मॉड्यूलच्या संरचनेच्या घटकांशी संबंधित असतात (घोषणा, ऑपरेटर, अभिव्यक्ती, इ.) आणि स्त्रोत मजकूरातील संबंधित घटकाच्या निर्देशांकांबद्दल माहिती तसेच (पर्याय म्हणून) नावाच्या रिझोल्यूशनबद्दल माहिती असते. तथाकथित लिंक्सचे स्वरूप बंधनकारक. बाइंडिंग्स हे ऑब्जेक्ट्स आहेत जे कंपाइलरला ज्ञात असलेल्या प्रकार, पद्धती आणि व्हेरिएबल्स सारख्या नामित घटकांचे प्रतिनिधित्व करतात. AST नोड्सच्या विपरीत, जे झाड बनवतात, बाइंडिंग क्रॉस-रेफरन्सिंगला समर्थन देतात आणि सामान्यतः आलेख तयार करतात. अमूर्त वर्ग ASTNode हा सर्व AST नोड्ससाठी सामान्य बेस क्लास आहे. ASTNode उपवर्ग जावा भाषेच्या विशिष्ट सिंटॅक्टिक रचनांशी संबंधित आहेत.

कारण सिंटॅक्स ट्री मोठ्या प्रमाणात मेमरी वापरू शकतात, JDT सक्रिय संपादकासाठी फक्त एक AST कॅश करते. Java मॉडेलच्या विपरीत, AST हे सामान्यत: "मध्यवर्ती," "तात्पुरते" मॉडेल म्हणून पाहिले जाते ज्याच्या सदस्यांना AST ची निर्मिती करणाऱ्या ऑपरेशनच्या संदर्भाबाहेर क्लायंटद्वारे संदर्भित केले जाऊ नये.

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

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

अंजीर मध्ये. आकृती 7 ग्रहण घटक दर्शविते जे 1C: एंटरप्राइज डेव्हलपमेंट टूल्ससाठी तंत्रज्ञान प्लॅटफॉर्मचा पाया तयार करतात.

तांदूळ. 7. 1C साठी प्लॅटफॉर्म म्हणून ग्रहण: एंटरप्राइज डेव्हलपमेंट टूल्स

ग्रहण प्लॅटफॉर्म मूलभूत पायाभूत सुविधा प्रदान करते. आम्ही मागील भागात या पायाभूत सुविधांच्या काही बाबी पाहिल्या.

एक्लिप्स मॉडेलिंग फ्रेमवर्क (ईएमएफ) संरचित डेटा मॉडेलिंगचे सामान्य माध्यम प्रदान करते. EMF Eclipse Platform सह समाकलित केले आहे, परंतु नियमित Java ऍप्लिकेशन्समध्ये देखील स्वतंत्रपणे वापरले जाऊ शकते. बर्‍याचदा, नवीन एक्लिप्स डेव्हलपर आधीपासूनच ईएमएफशी परिचित आहेत, जरी त्यांना अद्याप ग्रहण प्लॅटफॉर्मची गुंतागुंत पूर्णपणे समजली नाही. अशा योग्य लोकप्रियतेचे एक कारण म्हणजे सार्वत्रिक डिझाइन, ज्यामध्ये इतर गोष्टींबरोबरच, एक युनिफाइड मेटा-लेव्हल एपीआय समाविष्ट आहे, जे तुम्हाला कोणत्याही EMF मॉडेलसह सामान्य पद्धतीने कार्य करण्यास अनुमती देते. EMF द्वारे प्रदान केलेल्या मॉडेल ऑब्जेक्ट्ससाठी मूलभूत अंमलबजावणी आणि मेटा-मॉडेलवर आधारित मॉडेल कोड व्युत्पन्न करण्यासाठी उपप्रणाली विकासाची गती लक्षणीयरीत्या वाढवते आणि त्रुटींची संख्या कमी करते. EMF मध्ये मॉडेल्सची क्रमवारी लावणे, मॉडेलमधील बदलांचा मागोवा घेणे आणि बरेच काही करण्याची यंत्रणा देखील समाविष्ट आहे.

कोणत्याही खरोखर सामान्य-उद्देश साधनांप्रमाणे, EMF मॉडेलिंग समस्यांच्या विस्तृत श्रेणीचे निराकरण करण्यासाठी योग्य आहे, परंतु मॉडेलच्या काही वर्गांना (उदाहरणार्थ, वर चर्चा केलेले हँडल-आधारित मॉडेल) अधिक विशेष मॉडेलिंग साधनांची आवश्यकता असू शकते. EMF बद्दल बोलणे हे एक कृतघ्न कार्य आहे, विशेषत: एका लेखाच्या मर्यादित मर्यादेत, कारण हा एका स्वतंत्र पुस्तकाचा विषय आहे आणि त्याऐवजी जाड आहे. आपण फक्त हे लक्षात घेऊया की EMF अंतर्गत असलेल्या सामान्यीकरणाच्या उच्च-गुणवत्तेच्या प्रणालीने मॉडेलिंगला समर्पित प्रकल्पांच्या संपूर्ण श्रेणीच्या जन्मास अनुमती दिली, जे उच्च-स्तरीय प्रकल्पात समाविष्ट आहेत. ग्रहण मॉडेलिंग EMF स्वतः सोबत. असाच एक प्रकल्प म्हणजे Eclipse Xtext.

Xtext ग्रहण एक "टेक्स्ट मॉडेलिंग" इन्फ्रास्ट्रक्चर प्रदान करते. Xtext वापरते एएनटीएलआर परिणामी ASG चे प्रतिनिधित्व करण्यासाठी स्त्रोत मजकूर आणि EMF पार्स करण्यासाठी (अमूर्त सिमेंटिक आलेख, जो मूलत: AST आणि बाइंडिंग्जचे संयोजन आहे), ज्याला "अर्थविषयक मॉडेल" देखील म्हणतात. Xtext द्वारे मॉडेल केलेल्या भाषेचे व्याकरण Xtext च्या स्वतःच्या भाषेत वर्णन केले आहे. हे तुम्हाला केवळ ANTLR साठी व्याकरण वर्णन तयार करण्याची परवानगी देत ​​​​नाही, तर AST सीरियलायझेशन मेकॅनिझम (म्हणजे Xtext पार्सर आणि अनपार्सर दोन्ही प्रदान करते), संदर्भ इशारा आणि इतर अनेक भाषा घटक देखील मिळवू देते. दुसरीकडे, Xtext मध्ये वापरलेली व्याकरण भाषा ANTLR मध्ये वापरल्या जाणार्‍या व्याकरण भाषेपेक्षा कमी लवचिक आहे. म्हणून, काहीवेळा अंमलात आणलेली भाषा Xtext वर "वाकणे" आवश्यक असते, जी आपण सुरवातीपासून विकसित होत असलेल्या भाषेबद्दल बोलत असल्यास समस्या नसते, परंतु आधीपासूनच स्थापित वाक्यरचना असलेल्या भाषांसाठी अस्वीकार्य असू शकते. असे असूनही, Xtext हे सध्या Eclipse मधील प्रोग्रामिंग भाषा आणि त्यांच्यासाठी विकास साधने तयार करण्यासाठी सर्वात परिपक्व, वैशिष्ट्यपूर्ण आणि बहुमुखी साधन आहे. विशेषतः, जलद प्रोटोटाइपिंगसाठी हे एक आदर्श साधन आहे डोमेन-विशिष्ट भाषा (डोमेन-विशिष्ट भाषा, DSL). ANTLR आणि EMF वर आधारित वर नमूद केलेल्या "भाषा कोर" व्यतिरिक्त, Xtext अनेक उपयुक्त उच्च-स्तरीय घटक प्रदान करते, ज्यात अनुक्रमणिका यंत्रणा, वाढीव बांधकाम, एक "स्मार्ट संपादक" आणि बरेच काही, परंतु हँडल सोडले जाते- आधारित भाषा मॉडेल. ईएमएफ प्रमाणे, एक्सटेक्स्ट हा एक स्वतंत्र पुस्तकासाठी पात्र विषय आहे आणि आम्ही सध्या त्याच्या सर्व क्षमतांबद्दल थोडक्यात बोलू शकत नाही.

1C: एंटरप्राइझ डेव्हलपमेंट टूल्स EMF स्वतः आणि इतर अनेक Eclipse मॉडेलिंग प्रकल्प दोन्ही सक्रियपणे वापरतात. विशेषतः, Xtext हा अशा 1C साठी विकास साधनांचा एक पाया आहे: अंगभूत प्रोग्रामिंग भाषा आणि क्वेरी भाषा म्हणून एंटरप्राइझ भाषा. या डेव्हलपमेंट टूल्सचा आणखी एक आधार म्हणजे Eclipse Handly प्रोजेक्ट, ज्याची आपण अधिक तपशीलवार चर्चा करू (सूचीबद्ध केलेल्या Eclipse घटकांपैकी, हे अद्याप सर्वात कमी ज्ञात आहे).

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

हँडल-आधारित मॉडेल्सची मूलभूत वास्तुशास्त्रीय तत्त्वे, जसे की हँडल/बॉडी इडिओम, उदाहरणे म्हणून संसाधन मॉडेल आणि Java मॉडेल वापरून वर चर्चा केली गेली. रिसोर्स मॉडेल आणि जावा मॉडेल हे दोन्ही एक्लिप्स जावा डेव्हलपमेंट टूल्स (जेडीटी) साठी महत्त्वाचे पाया आहेत हे देखील यात नमूद केले आहे. आणि जवळजवळ सर्व *DT Eclipse प्रकल्पांची रचना JDT सारखीच असल्यामुळे, हँडल-आधारित मॉडेल्स ग्रहण प्लॅटफॉर्मच्या शीर्षस्थानी बनवलेले सर्व IDEs नसतील तर अनेकांना अधोरेखित करतात असे म्हणणे अतिशयोक्ती ठरणार नाही. उदाहरणार्थ, Eclipse C/C++ डेव्हलपमेंट टूलिंग (CDT) मध्ये हँडल-आधारित C/C++ मॉडेल आहे जे CDT आर्किटेक्चरमध्ये JDT मध्ये Java मॉडेल करते तशीच भूमिका बजावते.

Handly पूर्वी, Eclipse हँडल-आधारित भाषा मॉडेल तयार करण्यासाठी विशेष लायब्ररी ऑफर करत नाही. सध्या अस्तित्वात असलेली मॉडेल्स प्रामुख्याने Java मॉडेल कोड (उर्फ कॉपी/पेस्ट) चे रुपांतर करून तयार केली गेली आहेत. ज्या प्रकरणांमध्ये ते परवानगी देते ग्रहण सार्वजनिक परवाना (ईपीएल). (साहजिकच, हे सहसा ग्रहण प्रकल्पांसाठी कायदेशीर समस्या नसते, म्हणा, परंतु बंद स्त्रोत उत्पादनांसाठी नाही.) त्याच्या अंतर्निहित गोंधळाव्यतिरिक्त, हे तंत्र सुप्रसिद्ध समस्यांचा परिचय देते: त्रुटींशी जुळवून घेताना कोड डुप्लिकेशन, इ. काय वाईट आहे की परिणामी मॉडेल "स्वतःमध्ये गोष्टी" राहतात आणि एकीकरणाच्या संभाव्यतेचा फायदा घेत नाहीत. परंतु हँडल-आधारित भाषा मॉडेलसाठी सामान्य संकल्पना आणि प्रोटोकॉल वेगळे केल्याने त्यांच्याबरोबर काम करण्यासाठी पुन्हा वापरता येण्याजोग्या घटकांची निर्मिती होऊ शकते, जसे EMF च्या बाबतीत घडले.

एक्लिप्सला हे मुद्दे समजले नाहीत असे नाही. 2005 मध्ये परत मार्टिन एश्लिमन, CDT प्रोटोटाइप विकसित करण्याच्या अनुभवाचा सारांश, युक्तिवाद केला हँडल-आधारित मॉडेल्ससह भाषा मॉडेलसाठी एक सामान्य पायाभूत सुविधा निर्माण करण्याची गरज. परंतु, अनेकदा घडते, उच्च प्राधान्याच्या कामांमुळे, या कल्पनांची अंमलबजावणी कधीच झाली नाही. दरम्यान, *DT कोडचे फॅक्टरायझेशन हा अजूनही Eclipse मधील अविकसित विषयांपैकी एक आहे.

एका विशिष्ट अर्थाने, हँडली प्रकल्प EMF सारख्याच समस्यांचे निराकरण करण्यासाठी डिझाइन केलेले आहे, परंतु हँडल-आधारित मॉडेल्ससाठी आणि मुख्यतः भाषेसाठी (म्हणजे, काही प्रोग्रामिंग भाषेच्या संरचनेचे घटक दर्शविणारे). हँडली डिझाइन करताना सेट केलेली मुख्य उद्दिष्टे खाली सूचीबद्ध आहेत:

• विषय क्षेत्राच्या मुख्य अमूर्ततेची ओळख.
• प्रयत्न कमी करणे आणि कोड पुनर्वापराद्वारे हँडल-आधारित भाषा मॉडेलच्या अंमलबजावणीची गुणवत्ता सुधारणे.
• परिणामी मॉडेल्सना युनिफाइड मेटा-लेव्हल API प्रदान करणे, भाषा हँडल-आधारित मॉडेलसह कार्य करणारे सामान्य IDE घटक तयार करणे शक्य करते.
• लवचिकता आणि स्केलेबिलिटी.
• Xtext सह एकत्रीकरण (स्वतंत्र स्तरामध्ये).

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

तांदूळ. 8. हँडली घटकांची सामान्य इंटरफेस आणि मूलभूत अंमलबजावणी

IElement इंटरफेस घटकाच्या हँडलचे प्रतिनिधित्व करतो आणि सर्व हँडली-आधारित मॉडेलच्या घटकांसाठी सामान्य आहे. अमूर्त वर्ग घटक सामान्यीकृत हँडल/बॉडी मेकॅनिझम लागू करतो (चित्र 9).

तांदूळ. 9. आयएलमेंट आणि जेनेरिक हँडल/बॉडी अंमलबजावणी

याव्यतिरिक्त, हँडली मॉडेल घटकांमधील बदलांबद्दल सूचित करण्यासाठी एक सामान्यीकृत यंत्रणा प्रदान करते (चित्र 10). तुम्ही बघू शकता, हे संसाधन मॉडेल आणि Java मॉडेलमध्ये लागू केलेल्या अधिसूचना यंत्रणेसारखेच आहे आणि घटक बदल माहितीचे एकत्रित प्रतिनिधित्व प्रदान करण्यासाठी IElementDelta वापरते.

तांदूळ. 10. सामान्य इंटरफेस आणि हँडली नोटिफिकेशन यंत्रणेची मूलभूत अंमलबजावणी

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

वर सूचीबद्ध केलेल्या मुख्य यंत्रणांव्यतिरिक्त, हँडली मजकूर बफर आणि स्नॅपशॉट्ससाठी पायाभूत सुविधा प्रदान करते, स्त्रोत कोड संपादकांसह एकत्रीकरणासाठी समर्थन (एक्सटेक्स्ट एडिटरसह बॉक्सच्या बाहेर एकीकरणासह), तसेच काही सामान्य UI घटक जे सोर्स कोड एडिटरसह कार्य करा. हँडली मॉडेल्स जसे की बाह्यरेखा फ्रेमवर्क. त्याची क्षमता स्पष्ट करण्यासाठी, प्रकल्प हँडली मधील Java मॉडेलच्या अंमलबजावणीसह अनेक उदाहरणे प्रदान करतो. (JDT मधील Java मॉडेलच्या पूर्ण अंमलबजावणीच्या तुलनेत, अधिक स्पष्टतेसाठी हे मॉडेल जाणूनबुजून काहीसे सोपे केले आहे.)

आधी नमूद केल्याप्रमाणे, हँडलीच्या सुरुवातीच्या डिझाईन आणि त्यानंतरच्या विकासादरम्यान मुख्य लक्ष स्केलेबिलिटी आणि लवचिकता यावर होते आणि राहील.

तत्वतः, हँडल-आधारित मॉडेल्स "डिझाइननुसार" चांगले मोजतात. उदाहरणार्थ, हँडल/बॉडी आयडिओम तुम्हाला मॉडेलद्वारे वापरल्या जाणार्‍या मेमरीचे प्रमाण मर्यादित करण्यास अनुमती देते. पण बारकावे देखील आहेत. अशाप्रकारे, स्केलेबिलिटीसाठी हँडली चाचणी करताना, अधिसूचना यंत्रणेच्या अंमलबजावणीमध्ये एक समस्या आढळली - जेव्हा मोठ्या संख्येने घटक बदलले गेले, तेव्हा डेल्टा तयार करण्यासाठी खूप वेळ लागला. असे दिसून आले की समान समस्या जेडीटी जावा मॉडेलमध्ये होती, ज्यामधून संबंधित कोड एकदा रुपांतरित झाला होता. आम्ही हँडली मधील बगचे निराकरण केले आणि JDT साठी समान पॅच तयार केला, जो कृतज्ञतापूर्वक प्राप्त झाला. हे फक्त एक उदाहरण आहे जेथे विद्यमान मॉडेल अंमलबजावणीमध्ये हँडली सादर करणे संभाव्यतः उपयुक्त ठरू शकते, कारण या प्रकरणात अशा बगचे फक्त एकाच ठिकाणी निराकरण केले जाऊ शकते.

विद्यमान मॉडेल अंमलबजावणीमध्ये हँडली अंमलबजावणी तांत्रिकदृष्ट्या व्यवहार्य करण्यासाठी, लायब्ररीमध्ये लक्षणीय लवचिकता असणे आवश्यक आहे. एपीआय मॉडेलमध्ये मागासलेली सुसंगतता राखणे ही मुख्य समस्या आहे. मध्ये ही समस्या सोडवली गेली हाताने 0.5 लायब्ररीद्वारे प्रदान केलेल्या युनिफाइड मेटा-लेव्हल API पासून, डेव्हलपरद्वारे परिभाषित आणि पूर्णपणे नियंत्रित केलेले मॉडेल-विशिष्ट API स्पष्टपणे वेगळे करून. हे केवळ तांत्रिकदृष्ट्या विद्यमान अंमलबजावणीमध्ये हँडलीची अंमलबजावणी करणे शक्य करत नाही तर नवीन मॉडेल विकसकांना API डिझाइन करताना महत्त्वपूर्ण स्वातंत्र्य देखील देते.

लवचिकतेचे इतर पैलू देखील आहेत. उदाहरणार्थ, हँडली मॉडेलच्या संरचनेवर जवळजवळ कोणतेही निर्बंध लादत नाही आणि सामान्य-उद्देश आणि डोमेन-विशिष्ट भाषा दोन्ही मॉडेल करण्यासाठी वापरली जाऊ शकते. स्त्रोत फाइलची रचना तयार करताना, Handly कोणत्याही विशिष्ट स्वरूपाच्या AST प्रतिनिधित्वाची शिफारस करत नाही आणि तत्त्वतः, स्वतः AST ची उपस्थिती देखील आवश्यक नसते, अशा प्रकारे जवळजवळ कोणत्याही पार्सिंग यंत्रणेशी सुसंगतता सुनिश्चित करते. शेवटी, हँडली एक्लिप्स वर्कस्पेससह पूर्ण एकत्रीकरणास समर्थन देते, परंतु फाइल सिस्टमसह त्याच्या एकत्रीकरणामुळे थेट कार्य करू शकते. एक्लिप्स फाइल सिस्टम (ईएफएस).

चालू आवृत्ती हाताने 0.6 डिसेंबर 2016 मध्ये बाहेर आला. प्रकल्प सध्या उष्मायनाच्या अवस्थेत असूनही आणि API अद्याप निश्चित केले गेले नाही हे तथ्य असूनही, हँडली आधीपासूनच दोन मोठ्या व्यावसायिक उत्पादनांमध्ये वापरली जात आहे ज्यांनी "लवकर दत्तक घेणारे" म्हणून काम करण्याचा धोका पत्करला आहे, आणि, मला म्हणायचे आहे, अद्याप दु: ख करू नका.

वर नमूद केल्याप्रमाणे, या उत्पादनांपैकी एक म्हणजे 1C:एंटरप्राइज डेव्हलपमेंट टूल्स, जिथे हँडलीचा वापर अगदी सुरुवातीपासून अशा 1C च्या उच्च-स्तरीय संरचनेच्या घटकांसाठी केला जातो: अंगभूत प्रोग्रामिंग भाषा आणि क्वेरी भाषा म्हणून एंटरप्राइज भाषा . आणखी एक उत्पादन सामान्य लोकांना कमी माहिती आहे. या कोडसिप स्टुडिओ, ऍप्लिकेशन-स्पेसिफिक इंस्ट्रक्शन-सेट प्रोसेसर (ASIP) साठी एकात्मिक डिझाइन वातावरण, चेक कंपनी Codasip मध्ये स्वतः आणि त्याच्या क्लायंटद्वारे वापरले जाते, यासह AMD, एव्हीजी, मोबाईल, सिग्मा डिझाईन्स. Codasip 2015 पासून उत्पादनात Handly वापरत आहे, हँडली 0.2 आवृत्तीपासून सुरू होते. Codasip स्टुडिओचे नवीनतम प्रकाशन जून 0.5 मध्ये रिलीझ झालेली 2016 आवृत्ती वापरते. Codasip येथे IDE विकासाचे नेतृत्व करणारे Ondřej Ilčík प्रकल्पाच्या संपर्कात आहेत, "तृतीय पक्ष दत्तक घेणार्‍या" च्या वतीने महत्त्वपूर्ण अभिप्राय प्रदान करतात. हँडली उदाहरणांपैकी एक, Java मॉडेलसाठी UI लेयर (कोडच्या ~4000) लागू करून प्रकल्पाच्या विकासामध्ये थेट सहभागी होण्यासाठी त्याला थोडा मोकळा वेळ मिळू शकला. दत्तक घेणार्‍यांद्वारे Handly च्या वापराविषयी अधिक तपशीलवार माहिती पृष्ठावर आढळू शकते यशोगाथा प्रकल्प

आम्ही आशा करतो की API स्थिरतेच्या हमीसह आवृत्ती 1.0 रिलीझ केल्यानंतर आणि प्रकल्प उष्मायन स्थिती सोडल्यानंतर, Handly कडे नवीन स्वीकारकर्ते असतील. यादरम्यान, प्रकल्पाने API ची चाचणी करणे आणि त्यात आणखी सुधारणा करणे सुरू ठेवले आहे, दर वर्षी दोन "मुख्य" रिलीझ - जूनमध्ये (एकाच वेळी ग्रहण रिलीझ सारखीच तारीख) आणि डिसेंबरमध्ये रिलीझ करणे, दत्तक घेणारे विसंबून राहू शकतील असे एक अंदाजे वेळापत्रक प्रदान करते. आम्ही हे देखील जोडू शकतो की प्रकल्पाचा "बग रेट" सातत्याने कमी पातळीवर आहे आणि हँडली पहिल्या आवृत्त्यांपासून सुरुवातीच्या अवलंबकर्त्यांच्या उत्पादनांमध्ये विश्वासार्हपणे काम करत आहे. पुढे एक्लिप्स हँडली एक्सप्लोर करण्यासाठी, तुम्ही वापरू शकता ट्यूटोरियल सुरू करणे и आर्किटेक्चरल विहंगावलोकन.

स्त्रोत: www.habr.com