Мүмкін, бұрыннан бері арнайы кіріспе қажет емес. Көптеген адамдар Eclipse Java әзірлеу құралдарының арқасында Eclipse-пен таныс (). Көптеген әзірлеушілер «Eclipse» сөзімен байланыстыратын осы танымал ашық бастапқы Java IDE. Дегенмен, Eclipse әзірлеу құралдарын біріктіруге арналған кеңейтілген платформа (Eclipse платформасы) және оның негізінде құрылған бірқатар IDE, соның ішінде JDT. Eclipse - бұл Eclipse жобасы, Eclipse платформасы мен JDT әзірлеуді үйлестіретін жоғары деңгейлі жоба және Eclipse SDK, сол әзірлеудің нәтижесі. Соңында, Eclipse – барлығы Java тілінде жазылмаған немесе әзірлеу құралдарымен (мысалы, жобалар) байланысты емес жобалардың үлкен қауымдастығы бар ашық бастапқы қор. и ). Тұтылу әлемі өте алуан түрлі.
Табиғатта шолу болып табылатын бұл мақалада біз интеграцияланған әзірлеу құралдарын құру платформасы ретінде Eclipse архитектурасының кейбір негіздерін қарастыруға тырысамыз және технологияның негізін құрайтын Eclipse компоненттері туралы бастапқы түсінік береміз. «жаңа конфигураторға» арналған платформа 1С: Кәсіпорын. . Әрине, мұндай шолу сөзсіз негізінен үстірт және өте шектеулі болады, оның ішінде біз мақсатты аудитория ретінде тек Eclipse әзірлеушілеріне ғана назар аудармаймыз. Дегенмен, тіпті тәжірибелі Eclipse әзірлеушілері мақалада қызықты ақпаратты таба алады деп үміттенеміз. Мысалы, біз салыстырмалы түрде жаңа және аз танымал жоба «Eclipse құпияларының бірі» туралы сөйлесетін боламыз. 1С негізін қалаған және қолдаған.
Eclipse архитектурасына кіріспе
Алдымен мысалды пайдалана отырып, Eclipse архитектурасының кейбір жалпы аспектілерін қарастырайық (JDT). Мысал ретінде JDT таңдау кездейсоқ емес. Бұл Eclipse-те пайда болатын бірінші интеграцияланған әзірлеу ортасы. Eclipse C/C++ Development Tooling (CDT) сияқты басқа *DT Eclipse жобалары кейінірек жасалды және JDT-ден негізгі архитектуралық принциптер мен жеке бастапқы код фрагменттерін алды. JDT-де баяндалған архитектураның негіздері бүгінгі күнге дейін Eclipse платформасының үстіне құрастырылған кез келген дерлік IDE, соның ішінде 1C: Enterprise Development Tools үшін өзекті.
Ең алдымен, Eclipse белгілі бір бағдарламалау тілдерін қолдауға арналған функционалдылықтан тілге тәуелсіз функционалдылықты және UI тәуелсіз «негізгі» компоненттерін байланысты құрамдас бөліктерден бөлумен жеткілікті айқын архитектуралық қабатпен сипатталатынын атап өткен жөн. қолдаушы пайдаланушы интерфейсімен.
Осылайша, Eclipse платформасы жалпы, тілден тәуелсіз инфрақұрылымды анықтайды және Java әзірлеу құралдары Eclipse-ге толық функционалды Java IDE қосады. Eclipse платформасы да, JDT де бірнеше құрамдас бөліктерден тұрады, олардың әрқайсысы UI-ге тәуелсіз «ядроға» немесе UI деңгейіне жатады (1-сурет).
Күріш. 1. Eclipse платформасы және JDT
Eclipse платформасының негізгі компоненттерін тізіп көрейік:
- Жұмыс уақыты — Плагиннің инфрақұрылымын анықтайды. Eclipse модульдік архитектурамен сипатталады. Негізінде, Eclipse - бұл «кеңейту нүктелері» мен «кеңейтімдердің» жиынтығы.
- Жұмыс кеңістігі — Бір немесе бірнеше жобаны басқарады. Жоба файлдық жүйемен тікелей салыстырылатын қалталар мен файлдардан тұрады.
- Стандартты виджет құралдар жинағы (SWT) - Операциялық жүйемен біріктірілген пайдаланушы интерфейсінің негізгі элементтерін қамтамасыз етеді.
- JFace — SWT үстіне салынған бірқатар UI шеңберлерін қамтамасыз етеді.
- Workbench — Eclipse UI парадигмасын анықтайды: редакторлар, көріністер, перспективалар.
Айта кету керек, Eclipse платформасы сонымен қатар түзету, салыстыру, іздеу және топты қоса алғанда, интеграцияланған әзірлеу құралдарын құру үшін көптеген басқа пайдалы компоненттерді ұсынады. Бастапқы кодтың «ақылды редакторларын» құрудың негізі болып табылатын JFace Text-ті ерекше атап өту керек. Өкінішке орай, бұл компоненттерді, сондай-ақ UI қабатының құрамдастарын үстірт тексеру де осы мақаланың аясында мүмкін емес, сондықтан осы бөлімнің қалған бөлігінде біз негізгі «негізгі» компоненттерді шолумен шектелеміз. Eclipse платформасы және JDT.
Негізгі орындалу уақыты
Eclipse плагинінің инфрақұрылымы негізделген және жобамен қамтамасыз етілген . Әрбір Eclipse плагині OSGi бумасы болып табылады. OSGi спецификациясы, атап айтқанда, нұсқаларды құру және тәуелділікті шешу механизмдерін анықтайды. Осы стандартты механизмдерге қосымша Equinox тұжырымдамасын енгізеді кеңейту нүктелері. Әрбір плагин өзінің кеңейтім нүктелерін анықтай алады, сондай-ақ сол немесе басқа плагиндермен анықталған кеңейтім нүктелерін пайдаланып жүйеге қосымша функцияларды («кеңейтімдер») енгізе алады. OSGi және Equinox механизмдерінің кез келген егжей-тегжейлі сипаттамасы осы мақаланың ауқымынан тыс. Айта кетейік, Eclipse-тегі модульдеу толық (кез келген ішкі жүйе, соның ішінде Runtime, бір немесе бірнеше плагиндерден тұрады) және Eclipse-те барлығы дерлік кеңейтім болып табылады. Оның үстіне, бұл принциптер Eclipse архитектурасына OSGi енгізілгенге дейін көп бұрын енгізілген (ол кезде олар OSGi-ге ұқсас өз технологияларын пайдаланған).
Негізгі жұмыс кеңістігі
Eclipse платформасының үстіне салынған кез келген дерлік біріктірілген әзірлеу ортасы Eclipse жұмыс кеңістігімен жұмыс істейді. Бұл әдетте IDE-де әзірленген қолданбаның бастапқы кодын қамтитын жұмыс кеңістігі. Жұмыс кеңістігі тікелей файлдық жүйемен салыстырылады және қалталар мен файлдарды қамтитын жобалардан тұрады. Бұл жобалар, қалталар және файлдар деп аталады ресурстар жұмыс кеңістігі. Eclipse-те жұмыс кеңістігін іске асыру файлдық жүйеге қатысты кэш ретінде қызмет етеді, бұл ресурс ағашының өтуін айтарлықтай жылдамдатуға мүмкіндік береді. Сонымен қатар, жұмыс кеңістігі бірқатар қосымша қызметтерді ұсынады, соның ішінде и .
Негізгі ресурстар құрамдас бөлігі (org.eclipse.core.resources плагині) жұмыс кеңістігін және оның ресурстарын қолдауға жауапты. Атап айтқанда, бұл компонент пішіндегі жұмыс кеңістігіне бағдарламалық қатынасты қамтамасыз етеді ресурстық модельдер. Осы үлгімен тиімді жұмыс істеу үшін клиенттерге ресурсқа сілтеме көрсетудің қарапайым тәсілі қажет. Бұл жағдайда ресурс күйін үлгідегі клиенттік қатынастан тікелей сақтайтын нысанды жасырған жөн. Әйтпесе, мысалы, файлды жойған жағдайда, клиент келесі ақаулармен үлгіде жоқ нысанды ұстауды жалғастыра алады. Eclipse бұл мәселені деп аталатын нәрсені пайдалана отырып шешеді тұтқа ресурс. Дескриптор кілт ретінде әрекет етеді (ол жұмыс кеңістігіндегі ресурсқа жолды ғана біледі) және ресурс күйі туралы ақпаратты тікелей сақтайтын ішкі үлгі нысанына кіруді толығымен басқарады. Бұл дизайн үлгінің вариациясы болып табылады .
Күріш. 2-сурет ресурс үлгісіне қолданылған Handle/Body идиомасын көрсетеді. IResource интерфейсі ресурстың дескрипторын білдіреді және API болып табылады, бұл интерфейсті жүзеге асыратын Ресурс сыныбына және API болып табылмайтын денені көрсететін ResourceInfo сыныбына қарағанда. Біз дескриптор жұмыс кеңістігінің түбіріне қатысты ресурсқа жолды ғана білетінін және ресурс ақпаратына сілтемені қамтымайтынын атап өтеміз. Ресурс ақпаратының нысандары «элемент ағашы» деп аталатындарды құрайды. Бұл деректер құрылымы толығымен жадта материалдандырылған. Дескрипторға сәйкес ресурс ақпаратының данасын табу үшін элемент ағашы сол дескрипторда сақталған жолға сәйкес өтеді.
Күріш. 2. IResource және ResourceInfo
Кейінірек көретініміздей, ресурс үлгісінің негізгі дизайны (біз оны өңдеуге негізделген деп атаймыз) Eclipse-де басқа модельдер үшін де қолданылады. Әзірге осы дизайнның кейбір ерекше қасиеттерін тізіп көрейік:
- Handle - мән нысаны. Мән объектілері теңдігі сәйкестікке негізделмейтін өзгермейтін нысандар болып табылады. Мұндай нысандарды хэштелген контейнерлерде кілт ретінде қауіпсіз пайдалануға болады. Дескриптордың бірнеше даналары бір ресурсқа сілтеме жасай алады. Оларды салыстыру үшін equals(Object) әдісін қолдану керек.
- Дескриптор ресурс әрекетін анықтайды, бірақ ресурс күйі туралы ақпаратты қамтымайды (ол сақтайтын жалғыз деректер – «кілт», ресурсқа жол).
- Дескриптор жоқ ресурсқа сілтеме жасай алады (әлі жасалмаған ресурс немесе әлдеқашан жойылған ресурс). Ресурстың бар-жоғын IResource.exists() әдісі арқылы тексеруге болады.
- Кейбір операцияларды тек дескриптордың өзінде сақталған ақпарат негізінде жүзеге асыруға болады (тек өңдеуге арналған операциялар деп аталады). Мысалдар IResource.getParent(), getFullPath() және т.б. Мұндай операция сәтті болуы үшін ресурстың болуы қажет емес. Табысты болу үшін ресурстың болуын талап ететін әрекеттер, егер ресурс жоқ болса, CoreException шығарады.
Eclipse жұмыс кеңістігінің ресурстарының өзгерістері туралы хабарлаудың тиімді механизмін қамтамасыз етеді (3-сурет). Ресурстар Eclipse IDE ішінде орындалатын әрекеттер нәтижесінде немесе файлдық жүйемен синхрондау нәтижесінде өзгеруі мүмкін. Екі жағдайда да хабарландыруларға жазылған клиенттерге «ресурстардың дельталары» түріндегі өзгерістер туралы толық ақпарат беріледі. Дельта жұмыс кеңістігі ресурсының (ішкі) ағашының екі күйі арасындағы өзгерістерді сипаттайды және өзі ағаш болып табылады, оның әрбір түйіні ресурсқа өзгертуді сипаттайды және еншілес ресурстарға өзгерістерді сипаттайтын келесі деңгейдегі дельталар тізімін қамтиды.
Күріш. 3. IResourceChangeEvent және IResourceDelta
Ресурстардың дельталарына негізделген хабарландыру механизмі келесі сипаттамаларға ие:
- Дельта рекурсивті құрам принципі арқылы салынғандықтан, жалғыз өзгеріс және көптеген өзгерістер бірдей құрылымды пайдалана отырып сипатталады. Абоненттік клиенттер ресурсты өзгерту туралы хабарландыруларды дельталар ағашы арқылы рекурсивті түсіруді пайдалана отырып өңдей алады.
- Дельта ресурстағы өзгерістер туралы толық ақпаратты қамтиды, оның ішінде оның қозғалысы және/немесе онымен байланысты «маркерлердің» өзгерістері (мысалы, компиляция қателері маркерлер ретінде көрсетіледі).
- Ресурс сілтемелері дескриптор арқылы жасалғандықтан, Delta қашықтағы ресурсқа табиғи түрде сілтеме жасай алады.
Жақында көретініміздей, ресурс үлгісін өзгерту туралы хабарландыру механизмін жобалаудың негізгі құрамдастары басқа да тұтқаға негізделген үлгілер үшін де өзекті болып табылады.
JDT ядросы
Eclipse жұмыс кеңістігінің ресурстық үлгісі негізгі тіл-агностикалық үлгі болып табылады. JDT Core құрамдас бөлігі (plugin org.eclipse.jdt.core) жұмыс кеңістігінің құрылымын «Java моделі» деп аталатын Java тұрғысынан шарлау және талдау үшін API ұсынады (Java моделі). Бұл API қалталар мен файлдар тұрғысынан анықталған API негізгі ресурс үлгісінен айырмашылығы Java элементтері тұрғысынан анықталады. Java элементтерінің ағашының негізгі интерфейстері суретте көрсетілген. 4.
Күріш. 4. Java моделінің элементтері
Java моделі ресурс үлгісі сияқты бірдей дескриптор/дене идиомасын пайдаланады (5-сурет). IJavaElement - дескриптор, ал JavaElementInfo дене рөлін атқарады. IJavaElement интерфейсі барлық Java элементтеріне ортақ протоколды анықтайды. Оның кейбір әдістері тек өңдеуге арналған: getElementName(), getParent() және т.б. JavaElementInfo нысаны сәйкес элементтің күйін сақтайды: оның құрылымы мен атрибуттары.
Күріш. 5. IJavaElement және JavaElementInfo
Java моделінде ресурс үлгісімен салыстырғанда негізгі тұтқа/дене дизайнын жүзеге асыруда кейбір айырмашылықтар бар. Жоғарыда атап өтілгендей, ресурс үлгісінде түйіндері ресурс ақпаратының нысандары болып табылатын элемент ағашы толығымен жадта қамтылған. Бірақ Java үлгісі ресурс тармағына қарағанда элементтердің айтарлықтай көп санына ие болуы мүмкін, себебі ол .java және .class файлдарының ішкі құрылымын да көрсетеді: түрлер, өрістер және әдістер.
Жадтағы элементтердің бүкіл ағашын толығымен материалдандырмау үшін Java үлгісін іске асыру элемент ақпаратының шектеулі өлшемді LRU кэшін пайдаланады, мұнда кілт IJavaElement өңдеуі болып табылады. Элемент ақпаратының нысандары элемент ағашы шарлау кезінде сұраныс бойынша жасалады. Бұл жағдайда, ең жиі қолданылатын элементтер кэштен шығарылады және модельдің жадты тұтынуы көрсетілген кэш өлшемімен шектеледі. Бұл дескрипторға негізделген дизайнның тағы бір артықшылығы, клиент кодынан мұндай іске асыру мәліметтерін толығымен жасырады.
Java элементтеріне өзгерістерді хабарлау механизмі жалпы жоғарыда талқыланған жұмыс кеңістігі ресурстарындағы өзгерістерді қадағалау механизміне ұқсас. Java үлгісіндегі өзгерістерді бақылауды қалайтын клиент IJavaElementDelta бар ElementChangedEvent нысаны ретінде ұсынылған хабарландыруларға жазылады (6-сурет).
Күріш. 6. ElementChangedEvent және IJavaElementDelta
Java үлгісінде әдіс органдары немесе атау рұқсаты туралы ақпарат жоқ, сондықтан Java тілінде жазылған кодты егжей-тегжейлі талдау үшін JDT Core қосымша (тұтқаға негізделмеген) модельді ұсынады: (абстрактілі синтаксис ағашы, AST). AST бастапқы мәтінді талдау нәтижесін білдіреді. AST түйіндері бастапқы модуль құрылымының элементтеріне сәйкес келеді (мәлімдемелер, операторлар, өрнектер және т. деп аталатын сілтемелер нысаны байланыстар. Байланыстырулар - компиляторға белгілі типтер, әдістер және айнымалылар сияқты аталған нысандарды көрсететін нысандар. Ағашты құрайтын AST түйіндерінен айырмашылығы, байланыстырулар айқас сілтемені қолдайды және әдетте графикті құрайды. ASTNode дерексіз класы барлық AST түйіндері үшін ортақ базалық класс болып табылады. ASTNode ішкі сыныптары Java тілінің арнайы синтаксистік құрылымдарына сәйкес келеді.
Синтаксис ағаштары жадтың маңызды көлемін тұтына алатындықтан, JDT белсенді өңдегіш үшін тек бір AST кэштейді. Java үлгісінен айырмашылығы, AST әдетте "аралық", "уақытша" үлгі ретінде қарастырылады, оның мүшелеріне AST құруға әкелген операцияның контекстінен тыс клиенттер сілтеме жасамауы керек.
Көрсетілген үш модель (Java үлгісі, AST, байланыстырулар) бірге JDT-де «зияткерлік әзірлеу құралдарын» құру үшін негіз болып табылады, оның ішінде әртүрлі «көмекшілері бар қуатты Java редакторы», бастапқы кодты өңдеуге арналған әртүрлі әрекеттер (импорт тізімін ұйымдастыруды қоса) теңшелген стильге сәйкес атаулар мен пішімдеу), іздеу және рефакторинг құралдары. Бұл жағдайда Java моделі ерекше рөл атқарады, өйткені ол әзірленіп жатқан қолданба құрылымын визуалды түрде көрсету үшін негіз ретінде пайдаланылады (мысалы, Package Explorer, Outline, Search, Call Hierarchy және Түр иерархиясы).
1C: Enterprise Development Tools қолданбасында қолданылатын Eclipse компоненттері
Суретте. 7-суретте 1C: Enterprise Development Tools технологиялық платформасының негізін құрайтын Eclipse компоненттері көрсетілген.
Күріш. 7. Eclipse 1C:Enterprise Development Tools платформасы ретінде
Eclipse платформасы негізгі инфрақұрылыммен қамтамасыз етеді. Біз алдыңғы бөлімде осы инфрақұрылымның кейбір аспектілерін қарастырдық.
(EMF) құрылымдық мәліметтерді модельдеудің жалпы құралын береді. EMF Eclipse платформасымен біріктірілген, бірақ оны кәдімгі Java қолданбаларында бөлек пайдалануға болады. Көбінесе жаңа Eclipse әзірлеушілері Eclipse платформасының қыр-сырын әлі толық түсінбесе де, EMF-пен жақсы таныс. Осындай лайықты танымалдылықтың себептерінің бірі әмбебап дизайн болып табылады, ол басқа нәрселермен қатар, кез келген ЭМӨ моделімен жалпы түрде жұмыс істеуге мүмкіндік беретін біртұтас мета деңгейлі API қамтиды. ЭҚК қамтамасыз ететін модельдік объектілер үшін негізгі іске асырулар және мета-модельге негізделген модельдік кодты генерациялаудың ішкі жүйесі өңдеу жылдамдығын айтарлықтай арттырады және қателер санын азайтады. EMF сонымен қатар үлгілерді сериялау, үлгідегі өзгерістерді қадағалау және т.б. механизмдерді қамтиды.
Кез келген шын мәніндегі жалпы мақсаттағы құрал сияқты, ЭМӨ модельдеу мәселелерінің кең ауқымын шешуге жарамды, бірақ модельдердің кейбір кластары (мысалы, жоғарыда қарастырылған тұтқаға негізделген модельдер) мамандандырылған модельдеу құралдарын қажет етуі мүмкін. EMF туралы айту, әсіресе бір мақаланың шектеулі шегінде, алғыссыз міндет, өйткені бұл жеке кітаптың тақырыбы және өте қалың. ЭМӨ негізінде жатқан жоғары сапалы жалпылау жүйесі жоғары деңгейлі жобаға енгізілген модельдеуге арналған жобалардың тұтас кешенін тудыруға мүмкіндік бергенін атап өтейік. ЭҚК өзімен бірге. Осындай жобалардың бірі - Eclipse Xtext.
«мәтінді модельдеу» инфрақұрылымын қамтамасыз етеді. Xtext пайдаланады бастапқы мәтінді талдауға және алынған ASG (абстрактілі семантикалық график, ол негізінен AST және байланыстырулардың тіркесімі) ұсыну үшін EMF, сондай-ақ «семантикалық модель» деп аталады. Xtext арқылы үлгіленген тілдің грамматикасы Xtext-тің өз тілінде сипатталған. Бұл ANTLR үшін грамматикалық сипаттаманы құруға ғана емес, сонымен қатар AST сериялау механизмін (яғни Xtext талдаушыны да, талдаушыны да қамтамасыз етеді), мәтінмәндік анықтаманы және бірқатар басқа тіл компоненттерін алуға мүмкіндік береді. Екінші жағынан, Xtext-те қолданылатын грамматикалық тіл, айталық, ANTLR-де қолданылатын грамматикалық тілге қарағанда икемді емес. Сондықтан кейде іске асырылған тілді Xtext-ке «бүгу» қажет, бұл әдетте нөлден басталатын тіл туралы айтатын болсақ, бұл проблема емес, бірақ бұрыннан қалыптасқан синтаксисі бар тілдер үшін қолайсыз болуы мүмкін. Осыған қарамастан, Xtext қазіргі уақытта Eclipse-тегі ең жетілген, мүмкіндіктерге бай және бағдарламалау тілдерін және олар үшін әзірлеу құралдарын құруға арналған әмбебап құрал болып табылады. Атап айтқанда, бұл жылдам прототиптеу үшін тамаша құрал (доменге тән тіл, DSL). Жоғарыда аталған ANTLR және EMF негізіндегі «тіл өзегіне» қоса, Xtext көптеген пайдалы жоғары деңгейлі құрамдастарды, соның ішінде индекстеу механизмдерін, қосымша құрылысты, «ақылды редакторды» және тағы басқаларды ұсынады, бірақ өңдеуді қалдырады. негізделген тілдік модельдер. EMF сияқты, Xtext - бұл жеке кітапқа лайық тақырып және біз қазір оның барлық мүмкіндіктері туралы қысқаша айта алмаймыз.
1C: Enterprise Development Tools EMF-тің өзін де, Eclipse Modeling басқа бірқатар жобаларын да белсенді пайдаланады. Атап айтқанда, Xtext ендірілген бағдарламалау тілі және сұрау тілі сияқты 1C: Enterprise тілдерін әзірлеу құралдарының негізінің бірі болып табылады. Бұл әзірлеу құралдарының тағы бір негізі - Eclipse Handly жобасы, біз оны толығырақ талқылаймыз (тізімде көрсетілген Eclipse компоненттерінің ішінде ол әлі де азырақ белгілі).
, Eclipse Technology жоғарғы деңгейлі жобасының қосалқы жобасы, 1 жылы 2014С жасаған Eclipse Foundation бағдарламасына бастапқы код үлесінің нәтижесінде пайда болды. Содан бері 1С жобаның дамуына қолдау көрсетуді жалғастыруда: Қолмен орындаушылар – компания қызметкерлері. Жоба шағын, бірақ ол Eclipse-те ерекше орын алады: оның негізгі мақсаты - тұтқаға негізделген үлгілерді әзірлеуге қолдау көрсету.
Тұтқаға негізделген үлгілердің негізгі архитектуралық принциптері, мысалы, дескриптор/дене идиомалары, мысал ретінде ресурс үлгісі мен Java үлгісін пайдалану арқылы жоғарыда талқыланды. Сондай-ақ ресурс үлгісі де, Java моделі де Eclipse Java әзірлеу құралдары (JDT) үшін маңызды негіз болып табылатынын атап өтті. Барлық дерлік *DT Eclipse жобалары JDT-ге ұқсас архитектураға ие болғандықтан, Eclipse платформасының үстіне салынған барлық IDE-лер болмаса да, тұтқаға негізделген модельдер көптің негізінде жатыр деп айту артық айтқандық болмас еді. Мысалы, Eclipse C/C++ Development Tooling (CDT) дескрипторға негізделген C/C++ үлгісіне ие, ол CDT архитектурасында Java үлгісі JDT-де атқаратын рөлді атқарады.
Handlyге дейін Eclipse дескриптор негізіндегі тіл үлгілерін құру үшін арнайы кітапханаларды ұсынбаған. Қазіргі уақытта бар модельдер негізінен Java үлгі кодын тікелей бейімдеу арқылы жасалған (көшіру/қою), мүмкіндік беретін жағдайларда Eclipse Public License (EPL). (Әрине, бұл, айталық, Eclipse жобаларының өзі үшін заңды мәселе емес, бірақ жабық бастапқы өнімдер үшін емес.) Бұл әдіс өзіне тән кездейсоқтықтан басқа, белгілі проблемаларды енгізеді: қателерге бейімделу кезінде енгізілген кодты қайталау, т.б. Ең сорақысы, алынған модельдер «өзіндік заттар» болып қалады және біріктіру мүмкіндігін пайдаланбайды. Бірақ тұтқаға негізделген тіл үлгілері үшін жалпы түсініктер мен хаттамаларды оқшаулау ЭМӨ жағдайында болған жағдайға ұқсас олармен жұмыс істеу үшін қайта пайдалануға болатын компоненттерді жасауға әкелуі мүмкін.
Бұл Eclipse бұл мәселелерді түсінбеді. 2005 жылы , CDT прототипін жасау тәжірибесін қорытындылау, дескриптор негізіндегі үлгілерді қоса алғанда, тілдік модельдер үшін жалпы инфрақұрылымды құру қажеттілігі. Бірақ, жиі орын алатындай, басымдылығы жоғары міндеттерге байланысты, бұл идеяларды жүзеге асыру оны ешқашан айналып өтпеді. Сонымен қатар, *DT кодын факторизациялау әлі де Eclipse-те дамымаған тақырыптардың бірі болып табылады.
Белгілі бір мағынада Handly жобасы EMF сияқты шамамен бірдей мәселелерді шешуге арналған, бірақ дескрипторға негізделген модельдер үшін және ең алдымен тілдік (яғни, кейбір бағдарламалау тілінің құрылымының элементтерін білдіреді). Handly жобалау кезінде қойылған негізгі мақсаттар төменде келтірілген:
- Пәндік аймақтың негізгі абстракцияларын анықтау.
- Күшті азайту және кодты қайта пайдалану арқылы өңдеуге негізделген тіл үлгілерін енгізу сапасын арттыру.
- Алынған үлгілерге біртұтас мета деңгейлі API қамтамасыз ету, тіл дескрипторына негізделген үлгілермен жұмыс істейтін жалпы IDE құрамдастарын жасауға мүмкіндік береді.
- Икемділік және ауқымдылық.
- Xtext-пен интеграция (бөлек қабатта).
Жалпы тұжырымдамалар мен хаттамаларды бөлектеу үшін тіл дескрипторына негізделген үлгілердің бар іске асырулары талданды. Handly ұсынған негізгі интерфейстер мен негізгі іске асырулар суретте көрсетілген. 8.
Күріш. 8. Жалпы интерфейстер және Handly элементтерінің негізгі іске асырулары
IElement интерфейсі элементтің дескрипторын білдіреді және Handly негізіндегі барлық үлгілердің элементтеріне ортақ болып табылады. дерексіз класс Element жалпыланған тұтқа/дене механизмін жүзеге асырады (Cурет 9).
Күріш. 9. IElement және жалпы дескриптор/денені іске асыру
Сонымен қатар, Handly модель элементтеріндегі өзгерістер туралы хабарлаудың жалпыланған механизмін ұсынады (Cурет 10). Көріп отырғаныңыздай, ол ресурс үлгісінде және Java үлгісінде іске асырылған хабарландыру механизмдеріне кең түрде ұқсайды және элементті өзгерту ақпаратының бірыңғай көрінісін қамтамасыз ету үшін IElementDelta пайдаланады.
Күріш. 10. Handly хабарландыру механизмінің жалпы интерфейстері және негізгі іске асырулары
Жоғарыда талқыланған Handly бөлігін (9 және 10-суреттер) дерлік тұтқаға негізделген үлгілерді көрсету үшін пайдалануға болады. Жасау үшін лингвистикалық модельдер үшін жоба қосымша функционалдылықты ұсынады - атап айтқанда, бастапқы мәтін құрылымының элементтері үшін жалпы интерфейстер және негізгі іске асырулар, деп аталатын бастапқы элементтер (Cурет 8). ISourceFile интерфейсі бастапқы файлды, ал ISourceConstruct бастапқы файлдағы элементті білдіреді. SourceFile және SourceConstruct дерексіз сыныптары бастапқы файлдармен және олардың элементтерімен жұмыс істеуді қолдаудың жалпыланған механизмдерін жүзеге асырады, мысалы, мәтін буферлерімен жұмыс істеу, бастапқы мәтіндегі элементтің координаталарымен байланыстыру, үлгілерді жұмыс көшірме буферінің ағымдағы мазмұнымен салыстыру , т.б. Бұл тетіктерді іске асыру әдетте өте қиын болып табылады және Handly жоғары сапалы базалық енгізулерді қамтамасыз ету арқылы дескрипторға негізделген тіл үлгілерін әзірлеу күш-жігерін айтарлықтай азайтады.
Жоғарыда аталған негізгі механизмдерге қоса, Handly мәтіндік буферлер мен суреттерге арналған инфрақұрылымды, бастапқы код редакторларымен интеграцияны қолдауды (соның ішінде Xtext өңдегішімен қораптан тыс интеграцияны), сондай-ақ кейбір жалпы пайдаланушы интерфейсінің құрамдастарын ұсынады. бастапқы код өңдегіштерімен жұмыс істеу. Оның мүмкіндіктерін көрсету үшін жоба бірнеше мысалдарды, соның ішінде Handly жүйесінде Java үлгісін енгізуді ұсынады. (JDT-де Java үлгісін толық енгізумен салыстырғанда, бұл модель үлкенірек түсінікті болу үшін әдейі жеңілдетілген.)
Жоғарыда айтылғандай, Handly-дің бастапқы дизайны мен одан кейінгі дамуы кезінде ауқымдылық пен икемділікке басты назар аударылды және болып қала береді.
Негізінде, тұтқаға негізделген модельдер «дизайн бойынша» өте жақсы масштабталады. Мысалы, дескриптор/дене идиомасы үлгі тұтынатын жад көлемін шектеуге мүмкіндік береді. Бірақ нюанстар да бар. Осылайша, Handly-ді масштабтауға тестілеу кезінде хабарландыру механизмін жүзеге асыруда мәселе анықталды - элементтердің көп саны өзгерген кезде дельталарды құру тым көп уақытты алды. Дәл осындай мәселе JDT Java үлгісінде болғаны белгілі болды, оның сәйкес коды бір кездері бейімделген. Біз Handly бағдарламасында қатені түзетіп, JDT үшін ұқсас патч дайындадық, ол ризашылықпен қабылданды. Бұл Handly үлгісін бар үлгі іске асыруға енгізу әлеуетті пайдалы болуы мүмкін мысалдардың бірі, себебі бұл жағдайда мұндай қатені тек бір жерде түзетуге болады.
Қолданыстағы модельді іске асыруға Handly енгізуді техникалық мүмкін ету үшін кітапханада айтарлықтай икемділік болуы керек. Негізгі мәселе - API үлгісі бойынша кері үйлесімділікті сақтау. Бұл мәселе жылы шешілді әзірлеуші анықталған және толық бақылайтын үлгіге арналған API интерфейсін кітапхана ұсынған біртұтас мета-деңгейдегі API интерфейсінен нақты бөлу арқылы. Бұл Handly-ді бар іске асыруларға техникалық түрде енгізуге мүмкіндік беріп қана қоймайды, сонымен қатар жаңа үлгіні әзірлеушіге API жобалау кезінде айтарлықтай еркіндік береді.
Икемділіктің басқа да аспектілері бар. Мысалы, Handly модель құрылымына дерлік шектеулер қоймайды және оны жалпы мақсаттағы және доменге тән тілдерді модельдеу үшін пайдалануға болады. Бастапқы файлдың құрылымын құрастыру кезінде Handly AST ұсынудың қандай да бір нақты түрін белгілемейді және, негізінен, AST-тің өзінің болуын талап етпейді, осылайша кез келген дерлік талдау механизмімен үйлесімділікті қамтамасыз етеді. Соңында, Handly Eclipse жұмыс кеңістігімен толық интеграцияны қолдайды, бірақ сонымен бірге оның интеграциясы арқасында файлдық жүйелермен тікелей жұмыс істей алады. (EFS).
Қазіргі нұсқасы 2016 жылдың желтоқсан айында шықты. Қазіргі уақытта жоба инкубация жағдайында және API әлі түпкілікті бекітілмегеніне қарамастан, Handly қазірдің өзінде «ерте қабылдаушылар» ретінде әрекет ету қаупін алған екі ірі коммерциялық өнімде қолданылады және айта кету керек, әлі өкінбе.
Жоғарыда атап өтілгендей, осы өнімдердің бірі 1C: Enterprise Development Tools болып табылады, мұнда Handly басынан бастап кірістірілген бағдарламалау тілі және сұраныс тілі ретінде 1С: Кәсіпорын тілдерінің жоғары деңгейлі құрылымының элементтерін модельдеу үшін қолданылады. . Басқа өнім көпшілікке аз белгілі. Бұл , чехиялық Codasip компаниясының өзінде де, оның клиенттері де пайдаланатын қолданбалы нұсқаулар жинағы процессоры (ASIP) үшін біріктірілген дизайн ортасы, соның ішінде , , , . Codasip Handly-ді Handly 2015 нұсқасынан бастап 0.2 жылдан бастап өндірісте пайдаланады. Codasip Studio бағдарламасының соңғы шығарылымы 0.5 жылдың маусымында шығарылған 2016 нұсқасын пайдаланады. Codasip-те IDE әзірлеуге жетекшілік ететін Онджей Илчик жобамен байланысып, «үшінші тарапты қабылдаушы» атынан маңызды кері байланысты қамтамасыз етеді. Ол тіпті Handly мысалдарының бірі, Java моделі үшін UI деңгейін (~4000 код жолын) жүзеге асыра отырып, жобаны әзірлеуге тікелей қатысу үшін бос уақыт таба алды. Қолданушылардың Handly қолдануы туралы толығырақ ақпаратты бетте табуға болады Жоба.
API тұрақтылығының кепілдігі бар 1.0 нұсқасы шығарылғаннан кейін және жоба инкубациялық күйден шыққаннан кейін Handly-де жаңа қабылдаушылар болады деп үміттенеміз. Әзірге жоба API-ны сынауды және одан әрі жетілдіруді жалғастыруда, жылына екі «негізгі» шығарылымды шығарады - маусымда (бір мезгілде Eclipse шығарылымымен бірдей күн) және желтоқсанда, қабылдаушылар сене алатын болжамды кестені қамтамасыз етеді. Сондай-ақ жобаның «қателік деңгейі» тұрақты түрде төмен деңгейде қалып отыр және Handly алғашқы нұсқалардан бастап ерте қолданушылардың өнімдерінде сенімді жұмыс істеп келеді. Eclipse Handly қосымшасын зерттеу үшін пайдалануға болады и .
Ақпарат көзі: www.habr.com