Балким, эчактан бери атайын киришүүгө муктаж эмес. Көптөгөн адамдар Eclipse Java иштеп чыгуу куралдарынын аркасында Eclipse менен тааныш.). Дал ушул популярдуу ачык булактуу Java IDE көпчүлүк иштеп чыгуучулар "Eclipse" деген сөз менен байланыштырышат. Бирок, Eclipse иштеп чыгуу куралдарын интеграциялоо үчүн кеңейтилүүчү платформа (Eclipse Platform) жана анын негизинде курулган бир катар IDE, анын ичинде JDT. Eclipse - бул Eclipse долбоору, Eclipse платформасын жана JDTди иштеп чыгууну координациялоочу жогорку деңгээлдеги долбоор жана Eclipse SDK, бул иштеп чыгуунун натыйжасы. Акырында, Eclipse бул ачык булактуу Фонд, алардын бардыгы Java тилинде жазылган эмес же иштеп чыгуу куралдарына байланыштуу (мисалы, долбоорлор) и ). Eclipse дүйнөсү абдан ар түрдүү.
Табиятта серептелген бул макалада биз комплекстүү иштеп чыгуу куралдарын куруу үчүн платформа катары Eclipse архитектурасынын кээ бир негиздерин карап чыгууга аракет кылабыз жана технологиянын пайдубалын түзгөн Eclipse компоненттери жөнүндө алгачкы түшүнүктү беребиз. "жаңы конфигуратор" 1С: Enterprise платформасы. . Албетте, мындай карап чыгуу сөзсүз түрдө үстүртөн жана чектелүү болот, анын ичинде биз максаттуу аудитория катары 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 Platform жалпы, тилден көз карандысыз инфраструктураны аныктайт, ал эми Java иштеп чыгуу куралдары Eclipseке толук функционалдык Java IDE кошот. Eclipse Платформасы да, JDT да бир нече компоненттерден турат, алардын ар бири UI-көз карандысыз “өзөккө” же UI катмарына кирет (1-сүрөт).
Райс. 1. Eclipse Platform жана JDT
Eclipse платформасынын негизги компоненттерин санап көрөлү:
- Runtime — Плагин инфраструктурасын аныктайт. Eclipse модулдук архитектурасы менен мүнөздөлөт. Негизи, Eclipse "кеңейтүү чекиттеринин" жана "кеңейтүүлөрдүн" жыйындысы.
- Жумуш мейкиндиги — Бир же бир нече долбоорлорду башкарат. Долбоор түздөн-түз файлдык тутумга түшүрүлгөн папкалардан жана файлдардан турат.
- Стандарттык виджет куралдары (SWT) - Операция системасы менен интеграцияланган колдонуучу интерфейсинин негизги элементтерин камсыздайт.
- JFace — SWT үстүнө курулган бир катар UI алкактарын камсыз кылат.
- Workbench — Eclipse UI парадигмасын аныктайт: редакторлор, көз караштар, перспективалар.
Бул Eclipse Платформасы ошондой эле комплекстүү иштеп чыгуу куралдарын куруу үчүн көптөгөн пайдалуу компоненттерди, анын ичинде мүчүлүштүктөрдү оңдоо, салыштыруу, издөө жана команда менен камсыз кылат деп айтуу керек. JFace Text - булак кодунун "акылдуу редакторлорун" куруунун негизин өзгөчө белгилей кетүү керек. Тилекке каршы, бул компоненттерди, ошондой эле UI катмарынын компоненттерин үстүртөн карап чыгуу бул макаланын алкагында мүмкүн эмес, андыктан бул бөлүмдүн калган бөлүгүндө биз негизги "негизги" компоненттерди карап чыгуу менен чектелебиз. Eclipse платформасы жана JDT.
Core Runtime
Eclipse плагин инфраструктурасы негизделген жана долбоор тарабынан каралган . Ар бир Eclipse плагини OSGi таңгагы болуп саналат. OSGi спецификациясы, атап айтканда, версиялоо жана көз карандылыкты чечүү механизмдерин аныктайт. Бул стандарттык механизмдерден тышкары, Equinox түшүнүгүн киргизет кеңейүү пункттары. Ар бир плагин өзүнүн кеңейтүү чекиттерин аныктай алат, ошондой эле ошол эле же башка плагиндер тарабынан аныкталган кеңейтүү чекиттерин колдонуу менен системага кошумча функцияларды («кеңейтүүлөр») киргизе алат. OSGi жана Equinox механизмдеринин ар кандай деталдуу сүрөттөлүшү бул макаланын чегинен тышкары. Айта кетсек, Eclipseдеги модулдаштыруу жалпы (кандайдыр бир подсистема, анын ичинде Runtime, бир же бир нече плагиндерден турат) жана Eclipseдеги дээрлик бардыгы кеңейтүү. Анын үстүнө, бул принциптер OSGi киргизилгенге чейин эле Eclipse архитектурасына киргизилген (ошол учурда алар OSGiге абдан окшош өз технологиясын колдонушкан).
Негизги иш мейкиндиги
Eclipse платформасынын үстүнө курулган дээрлик бардык интеграцияланган өнүктүрүү чөйрөсү Eclipse жумушчу мейкиндиги менен иштейт. Бул көбүнчө IDEде иштелип чыккан тиркеменин баштапкы кодун камтыган жумушчу мейкиндиги. Иш мейкиндиги түздөн-түз файлдык тутумга түзүлөт жана папкаларды жана файлдарды камтыган долбоорлордон турат. Бул долбоорлор, папкалар жана файлдар деп аталат ресурстар иш мейкиндиги. Eclipseдеги жумушчу мейкиндигин ишке ашыруу файлдык тутумга карата кэш катары кызмат кылат, бул ресурс дарагынын өтүшүн кыйла тездетүүгө мүмкүндүк берет. Мындан тышкары, жумушчу мейкиндиги бир катар кошумча кызматтарды, анын ичинде камсыз кылат и .
Негизги ресурстар компоненти (org.eclipse.core.resources плагини) жумушчу мейкиндигин жана анын ресурстарын колдоо үчүн жооптуу. Тактап айтканда, бул компонент формадагы иш мейкиндигине программалык кирүүнү камсыз кылат ресурстук моделдер. Бул модель менен эффективдүү иштөө үчүн кардарларга ресурстун шилтемесин көрсөтүүнүн жөнөкөй жолу керек. Бул учурда, моделдеги ресурстун абалын түздөн-түз сактаган объектти кардардын кирүүсүнөн жашыруу туура болмок. Болбосо, мисалы, файлды жок кылган учурда, кардар моделде жок болгон объектти андан ары көйгөйлөр менен кармап турушу мүмкүн. Eclipse деп аталган нерсени колдонуп, бул маселени чечет туура ресурс. Handle ачкычтын ролун аткарат (ал жумушчу мейкиндигинде ресурска баруучу жолду гана билет) жана ресурстун абалы жөнүндө маалыматты түздөн-түз сактаган ички моделдик объектке кирүүнү толугу менен көзөмөлдөйт. Бул дизайн үлгү бир вариация болуп саналат .
Райс. 2-сүрөт ресурстук моделге колдонулган Handle/Body идиомасын көрсөтөт. IResource интерфейси бул интерфейсти ишке ашырган Ресурс классынан жана API болбогон денени билдирген ResourceInfo классынан айырмаланып, бул ресурстун туткасын билдирет жана API болуп саналат. Иш мейкиндигинин тамырына салыштырмалуу тутка ресурска баруучу жолду гана билерин жана ресурс маалыматына шилтеме жок экенин баса белгилейбиз. Ресурстук маалымат объекттери "элемент дарагы" деп аталган нерсени түзөт. Бул маалымат структурасы толугу менен эс тутумда материализацияланган. Туткуга туура келген ресурстук маалымат инстанциясын табуу үчүн, элемент дарагы ошол туткада сакталган жолго ылайык өтүлөт.
Райс. 2. IResource жана ResourceInfo
Кийинчерээк көрө тургандай, ресурстук моделдин негизги дизайны (биз аны туткага негизделген деп аташыбыз мүмкүн) Eclipseте башка моделдер үчүн да колдонулат. Азырынча, келгиле, бул дизайндын айрым айырмалоочу касиеттерин санап көрөлү:
- Handle баалуу объект болуп саналат. Нарк объекттери – теңдиги иденттүүлүккө негизделбеген өзгөрүлгүс объекттер. Мындай объекттерди хэштелген контейнерлерде ачкыч катары коопсуз колдонсо болот. Колдонуучунун бир нече инстанциялары бир эле ресурска шилтеме кыла алат. Аларды салыштыруу үчүн, барабар(Object) ыкмасын колдонушуңуз керек.
- Handle ресурстун жүрүм-турумун аныктайт, бирок ресурстун абалы жөнүндө маалыматты камтыбайт (ал сактаган бир гана маалымат бул "ачкыч", ресурстун жолу).
- Handle жок ресурска кайрылышы мүмкүн (же түзүлө элек ресурс, же буга чейин жок кылынган ресурс). Ресурстун бар экендигин IResource.exists() ыкмасы менен текшерсе болот.
- Кээ бир операцияларды туткада сакталган маалыматтын негизинде гана ишке ашырууга болот (бир гана тутка операциялары деп аталган). Мисалдар IResource.getParent(), getFullPath() ж.б. Мындай операция ийгиликтүү болушу үчүн ресурстун болушу шарт эмес. Ийгиликке жетүү үчүн ресурстун болушун талап кылган операциялар, эгер ресурс жок болсо, CoreException ыргытат.
Eclipse иш мейкиндигиндеги ресурстун өзгөрүүлөрүн билдирүү үчүн эффективдүү механизмди камсыз кылат (3-сүрөт). Ресурстар Eclipse IDE ичинде аткарылган аракеттердин натыйжасында же файл системасы менен синхрондоштуруунун натыйжасында өзгөрүшү мүмкүн. Эки учурда тең билдирүүлөргө жазылган кардарларга “ресурстук дельталар” түрүндөгү өзгөртүүлөр тууралуу толук маалымат берилет. Дельта жумушчу мейкиндик ресурсунун (суб-) дарактын эки абалынын ортосундагы өзгөрүүлөрдү сүрөттөйт жана өзү дарак болуп саналат, анын ар бир түйүнү ресурстун өзгөрүшүн сүрөттөйт жана кийинки деңгээлдеги дельталардын тизмесин камтыйт, алар бала ресурстарына болгон өзгөртүүлөрдү сүрөттөйт.
Райс. 3. IResourceChangeEvent жана IResourceDelta
Ресурстук дельтага негизделген кабарлоо механизми төмөнкүдөй мүнөздөмөлөргө ээ:
- Дельта рекурсивдүү курам принцибинин негизинде курулгандыктан, бир эле өзгөрүү жана көптөгөн өзгөрүүлөр бир эле структураны колдонуу менен сүрөттөлөт. Абонент кардарлары дельталар дарагы аркылуу рекурсивдүү түшүү аркылуу ресурсту өзгөртүү эскертмелерин иштете алышат.
- Дельта ресурска болгон өзгөрүүлөр, анын ичинде анын кыймылы жана/же аны менен байланышкан “маркерлердеги” өзгөрүүлөр жөнүндө толук маалыматты камтыйт (мисалы, компиляция каталары маркерлер катары көрсөтүлөт).
- Ресурстук шилтемелер тутка аркылуу жасалгандыктан, дельта табигый түрдө алыскы ресурска шилтеме жасай алат.
Биз жакында көрө тургандай, ресурстук моделдин өзгөрүшү жөнүндө кабарлоо механизминин дизайнынын негизги компоненттери башка туткага негизделген моделдерге да тиешелүү.
JDT Core
Eclipse жумушчу мейкиндигинин ресурстук модели негизги тил-агностикалык модель болуп саналат. JDT Core компоненти (плагин org.eclipse.jdt.core) Java көз карашынан иш мейкиндигинин түзүмүн багыттоо жана талдоо үчүн API менен камсыз кылат, "Java модели" деп аталган (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 менен жакшы тааныш. Мындай татыктуу популярдуулуктун себептеринин бири универсалдуу дизайн болуп саналат, ал башка нерселер менен катар, каалаган EMF модели менен жалпы түрдө иштөөгө мүмкүндүк берген бирдиктүү мета-деңгээлдеги APIди камтыйт. EMF тарабынан берилген моделдик объекттер үчүн негизги ишке ашыруулар жана мета-моделдин негизинде моделдик кодду түзүүнүн подсистемасы иштеп чыгуунун ылдамдыгын олуттуу жогорулатат жана каталардын санын азайтат. EMF ошондой эле моделдерди сериялаштыруу, моделдеги өзгөрүүлөргө көз салуу жана башка көптөгөн механизмдерди камтыйт.
Ар кандай чындап эле жалпы максаттагы курал сыяктуу эле, EMF моделдөө көйгөйлөрүнүн кеңири спектрин чечүү үчүн ылайыктуу, бирок моделдердин кээ бир класстары (мисалы, жогоруда талкууланган туткага негизделген моделдер) көбүрөөк адистештирилген моделдөө куралдарын талап кылышы мүмкүн. EMF жөнүндө сөз кылуу, айрыкча, бир макаланын чектелген чегинде, ырахматсыз иш, анткени бул өзүнчө китептин темасы жана кыйла жоон. ЭМИнин негизиндеги жалпылоолордун жогорку сапаттагы системасы моделдештирүүгө арналган долбоорлордун бүткүл спектрин түзүүгө мүмкүндүк бергендигин белгилей кетели, алар жогорку деңгээлдеги долбоорго киргизилген. EMF өзү менен бирге. Мындай долбоорлордун бири - Eclipse Xtext.
"тексттик моделдөө" инфраструктурасын камсыз кылат. Xtext колдонот баштапкы текстти талдоо үчүн жана натыйжада ASGди көрсөтүү үчүн EMF (абстракттуу семантикалык график, ал негизи AST жана байланыштардын айкалышы), ошондой эле "семантикалык модель" деп аталат. 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 Фондуна алгачкы код салымынын натыйжасында пайда болгон. Ошондон бери 1С долбоордун өнүгүшүнө колдоо көрсөтүүнү улантып келет: Handly committers – бул компаниянын кызматкерлери. Долбоор кичинекей, бирок ал Eclipse'те өзгөчө орунду ээлейт: анын негизги максаты туткага негизделген моделдерди иштеп чыгууну колдоо болуп саналат.
Туткага негизделген моделдердин негизги архитектуралык принциптери, мисалы, тутка/дене идиомасы, мисал катары ресурс моделин жана Java моделин колдонуу менен жогоруда талкууланган. Ал ошондой эле ресурстук модели жана Java модели Eclipse Java өнүктүрүү куралдары (JDT) үчүн маанилүү негиз болуп саналат деп белгиледи. Жана дээрлик бардык *DT Eclipse долбоорлору JDTге окшош архитектурага ээ болгондуктан, туткага негизделген моделдер Eclipse платформасынын үстүнө курулган бардык IDE эмес, көпчүлүктүн негизинде жатат деп айтсак аша чапкандык болбос. Мисалы, Eclipse C/C++ Иштеп чыгуу куралы (CDT) туткага негизделген C/C++ моделине ээ, ал CDT архитектурасында Java модели JDTдегидей роль ойнойт.
Handlyге чейин Eclipse туткага негизделген тил моделдерин куруу үчүн атайын китепканаларды сунуш кылган эмес. Учурдагы моделдер негизинен Java моделинин кодун түз адаптациялоо жолу менен түзүлдү (көчүрмө/паста), жол берген учурларда Eclipse Public License (EPL). (Албетте, бул эреже катары, мисалы, Eclipse долбоорлорунун өзү үчүн юридикалык маселе эмес, бирок жабык булактуу продуктулар үчүн эмес.) Бул ыкма өзүнө мүнөздүү кокустуктан тышкары, жалпыга белгилүү көйгөйлөрдү камтыйт: каталарга ыңгайлашканда, кодду кайталоо, жана башкалар Андан да жаманы, пайда болгон моделдер "өзүндө нерселер" бойдон калууда жана биригүү мүмкүнчүлүгүн колдонбойт. Бирок туткага негизделген тил моделдери үчүн жалпы түшүнүктөрдү жана протоколдорду обочолонтуу, алар менен иштөө үчүн көп жолу колдонулуучу компоненттерди түзүүгө алып келиши мүмкүн, EMF учуруна окшош.
Бул Eclipse бул маселелерди түшүнгөн эмес. 2005-жылы , CDT прототибин иштеп чыгуу тажрыйбасын жалпылоо, тил моделдери үчүн жалпы инфраструктураны түзүү зарылчылыгы, анын ичинде туткага негизделген моделдер. Бирок, адаттагыдай эле, жогорку артыкчылыктуу милдеттерден улам, бул идеяларды ишке ашыруу эч качан ишке ашкан эмес. Ошол эле учурда, * DT кодун факторизациялоо дагы эле Eclipseде өнүкпөгөн темалардын бири болуп саналат.
Белгилүү бир мааниде Handly долбоору болжол менен EMF сыяктуу көйгөйлөрдү чечүү үчүн иштелип чыккан, бирок туткага негизделген моделдер үчүн жана биринчи кезекте тилдик (б.а., кээ бир программалоо тилинин структурасынын элементтерин билдирет). Handlyди долбоорлоодо коюлган негизги максаттар төмөндө келтирилген:
- Предметтик чөйрөнүн негизги абстракцияларын аныктоо.
- Кодду кайра колдонуу аркылуу туткага негизделген тил моделдерин ишке ашыруунун сапатын жогорулатуу жана күч-аракетти азайтуу.
- Натыйжадагы моделдерге бирдиктүү мета-деңгээлдеги API менен камсыз кылуу, тил туткасына негизделген моделдер менен иштеген жалпы IDE компоненттерин түзүүгө мүмкүндүк берет.
- Ийкемдүүлүк жана масштабдуулук.
- Xtext менен интеграция (өзүнчө катмарда).
Жалпы түшүнүктөрдү жана протоколдорду бөлүп көрсөтүү үчүн тил туткасына негизделген моделдердин учурдагы ишке ашырылышы талдоого алынган. Handly тарабынан берилген негизги интерфейстер жана негизги ишке ашыруулар сүрөттө көрсөтүлгөн. 8.
Райс. 8. Жалпы интерфейстер жана Handly элементтеринин негизги ишке ашырылышы
IElement интерфейси элементтин туткасын билдирет жана бардык Handly негизиндеги моделдердин элементтери үчүн жалпы болуп саналат. Абстракттуу класс Element жалпыланган тутка/дене механизмин ишке ашырат (сүрөт 9).
Райс. 9. IElement жана жалпы туткасы/дене ишке ашыруу
Мындан тышкары, Handly моделдин элементтериндеги өзгөрүүлөр жөнүндө кабарлоонун жалпыланган механизмин берет (10-сүрөт). Көрүнүп тургандай, ал ресурстук моделде жана Java моделинде ишке ашырылган кабарлоо механизмдерине кеңири окшош жана IElementDelta элементтерин өзгөртүү маалыматынын бирдиктүү өкүлчүлүгүн камсыз кылуу үчүн колдонот.
Райс. 10. Handly кабарлоо механизминин жалпы интерфейстери жана негизги ишке ашыруулары
Жогоруда талкууланган Handly бөлүгү (9 жана 10-сүрөт) дээрлик бардык туткага негизделген моделдерди көрсөтүү үчүн колдонулушу мүмкүн. түзүү үчүн лингвистикалык моделдер, долбоор кошумча функцияларды сунуш кылат - атап айтканда, жалпы интерфейстер жана баштапкы текст структурасынын элементтери үчүн негизги ишке ашыруу, деп аталган булак элементтери (8-сүрөт). ISourceFile интерфейси баштапкы файлды, ал эми ISourceConstruct булак файлынын ичиндеги элементти билдирет. SourceFile жана SourceConstruct абстракттуу класстары баштапкы файлдар жана алардын элементтери менен иштөөнү колдоо үчүн жалпыланган механизмдерди ишке ашырат, мисалы, текст буферлери менен иштөө, баштапкы тексттеги элементтин координаталары менен иштөө, моделдерди жумушчу көчүрүү буферинин учурдагы мазмуну менен элдештирүү , жана башкалар. Бул механизмдерди ишке ашыруу, адатта, бир топ кыйынчылык болуп саналат жана Handly жогорку сапаттагы базалык ишке ашырууну камсыз кылуу менен туткага негизделген тил моделдерин иштеп чыгуу аракетин бир кыйла азайтат.
Жогоруда саналып өткөн негизги механизмдерден тышкары, Handly текст буферлери жана сүрөттөрү үчүн инфраструктураны, баштапкы код редакторлору менен интеграцияны колдоону (анын ичинде Xtext редактору менен кутудан тышкаркы интеграциялоону), ошондой эле кээ бир жалпы UI компоненттерин камсыз кылат. баштапкы код редакторлору менен иштөө. Контур алкагы сыяктуу моделдер. Анын мүмкүнчүлүктөрүн көрсөтүү үчүн долбоор бир нече мисалдарды келтирет, анын ичинде Handlyде Java моделин ишке ашыруу. (JDTдеги Java моделин толук ишке ашырууга салыштырмалуу, бул модель көбүрөөк түшүнүктүү болуу үчүн атайылап бир аз жөнөкөйлөштүрүлгөн.)
Мурда белгиленгендей, Handly'дин алгачкы дизайны жана андан кийинки өнүгүүсүндөгү негизги көңүл масштабдуулукка жана ийкемдүүлүккө болгон жана болуп кала берет.
Негизи, туткага негизделген моделдер "дизайн боюнча" жакшы масштабда. Мисалы, туткасы/дене идиомасы моделге керектелүүчү эс көлөмүн чектөөгө мүмкүндүк берет. Бирок нюанстар да бар. Ошентип, Handly масштабдуулугу үчүн тестирлөөдө, билдирүү механизмин ишке ашырууда көйгөй табылды - көп сандагы элементтер өзгөргөндө, дельталарды куруу өтө көп убакытты талап кылды. Көрсө, ошол эле көйгөй JDT Java моделинде болгон, андан тиешелүү код бир жолу ыңгайлаштырылган. Биз Handlyдеги мүчүлүштүктөрдү оңдоп, JDT үчүн ушундай патчты даярдадык, ал ыраазылык менен кабыл алынды. Бул Handlyди колдонуудагы моделдин ишке ашырууларына киргизүү пайдалуу болушу мүмкүн болгон бир гана мисал, анткени бул учурда мындай мүчүлүштүк бир эле жерден оңдолот.
Колдонуудагы моделди ишке ашырууну техникалык жактан ишке ашыруу үчүн китепкана олуттуу ийкемдүүлүккө ээ болушу керек. Негизги көйгөй API модели боюнча артка шайкештикти сактоо болуп саналат. Бул маселе жылы чечилди иштеп чыгуучу тарабынан аныкталган жана толугу менен көзөмөлдөнгөн моделге тиешелүү APIди китепкана тарабынан берилген бирдиктүү мета-деңгээлдеги APIден так бөлүп алуу менен. Бул Handlyди учурдагы ишке ашырууга техникалык жактан гана мүмкүн кылбастан, жаңы моделди иштеп чыгуучуга APIди долбоорлоодо олуттуу эркиндик берет.
Ийкемдүүлүктүн башка аспектилери да бар. Мисалы, Handly моделдин түзүмүнө дээрлик эч кандай чектөөлөрдү киргизбейт жана жалпы максаттагы жана доменге тиешелүү тилдерди моделдөө үчүн колдонулушу мүмкүн. Булак файлынын структурасын курууда Handly AST өкүлчүлүгүнүн кандайдыр бир конкреттүү формасын дайындабайт жана, негизинен, ASTтин өзүнүн болушун талап кылбайт, ошентип дээрлик бардык талдоо механизмдери менен шайкештикти камсыз кылат. Акыр-аягы, Handly Eclipse жумушчу мейкиндиги менен толук интеграцияны колдойт, бирок ошондой эле анын интеграциясынын аркасында файл системалары менен түздөн-түз иштей алат. (EFS).
Учурдагы версия 2016-жылы декабрда чыккан. Долбоор учурда инкубация абалында жана API али биротоло бекитиле электигине карабастан, Handly буга чейин эки ири коммерциялык продуктуда колдонулат, алар "эрте кабыл алуучулар" катары иш алып баруу тобокелдигине дуушар болушат жана мен айтышым керек, дагы деле өкүнбө.
Жогоруда белгиленгендей, бул өнүмдөрдүн бири 1C: Enterprise Development Tools болуп саналат, мында Handly 1C: Enterprise тилдеринин орнотулган программалоо тили жана суроо тили катары жогорку деңгээлдеги структурасынын элементтерин моделдөө үчүн башынан эле колдонулат. . Дагы бир продукт жалпы коомчулукка анча белгилүү эмес. Бул , Codasip чех компаниясынын өзүндө жана анын кардарлары тарабынан колдонулган колдонмого атайын нускамалар топтому процессору (ASIP) үчүн интеграцияланган дизайн чөйрөсү, анын ичинде , , , . Codasip 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 андан ары изилдөө үчүн, сиз колдоно аласыз и .
Source: www.habr.com