Ehtimol, uzoq vaqtdan beri maxsus kirishga muhtoj emas. Eclipse Java ishlab chiqish vositalari tufayli ko'p odamlar Eclipse bilan tanish.). Ko'pchilik ishlab chiquvchilar "Eclipse" so'zi bilan bog'langan ushbu mashhur ochiq manbali Java IDE. Biroq, Eclipse ham ishlab chiqish vositalarini (Eclipse Platformasi) integratsiyalash uchun kengaytiriladigan platforma, ham uning asosida qurilgan bir qator IDE, shu jumladan JDT. Eclipse ham Eclipse loyihasi, Eclipse Platformasi va JDT ni ishlab chiqishni muvofiqlashtiruvchi yuqori darajadagi loyiha va Eclipse SDK, bu ishlanmaning natijasidir. Va nihoyat, Eclipse ochiq manbali fond bo'lib, ulkan loyihalar hamjamiyatiga ega bo'lib, ularning hammasi ham Java-da yozilmagan yoki ishlab chiqish vositalariga (masalan, loyihalar) tegishli emas. и ). Eclipse dunyosi juda xilma-xildir.
Tabiatda umumiy ko'rinishga ega bo'lgan ushbu maqolada biz Eclipse arxitekturasining ba'zi asoslarini integratsiyalashgan ishlab chiqish vositalarini yaratish platformasi sifatida ko'rib chiqishga harakat qilamiz va texnologiyaning asosini tashkil etuvchi Eclipse komponentlari haqida dastlabki tasavvurni beramiz. "yangi konfigurator" 1C: Enterprise platformasi. . Albatta, bunday ko'rib chiqish muqarrar ravishda yuzaki va juda cheklangan bo'ladi, shu jumladan, biz maqsadli auditoriya sifatida nafaqat Eclipse ishlab chiqaruvchilariga e'tibor qaratmoqdamiz. Biroq, umid qilamizki, hatto tajribali Eclipse ishlab chiquvchilari ham maqolada qiziqarli ma'lumotlarni topa oladilar. Masalan, biz nisbatan yangi va kam ma'lum bo'lgan "Eclipse sirlaridan biri" haqida gaplashamiz. , 1C tomonidan tashkil etilgan va qo'llab-quvvatlangan.
Eclipse arxitekturasiga kirish
Keling, avval misol yordamida Eclipse arxitekturasining ba'zi umumiy jihatlarini ko'rib chiqaylik (JDT). Misol sifatida JDT ning tanlanishi tasodifiy emas. Bu Eclipse-da paydo bo'lgan birinchi integratsiyalashgan rivojlanish muhiti. Eclipse C/C++ Development Tooling (CDT) kabi boshqa *DT Eclipse loyihalari keyinroq yaratilgan va JDT dan asosiy arxitektura tamoyillari va individual manba kod qismlarini olgan. JDT-da o'rnatilgan arxitektura asoslari Eclipse platformasida qurilgan deyarli har qanday IDE, shu jumladan 1C: Enterprise Development Tools uchun dolzarbdir.
Avvalo shuni ta'kidlash kerakki, Eclipse juda aniq arxitektura qatlamlari bilan ajralib turadi, bunda tilga bog'liq bo'lmagan funksionallikni muayyan dasturlash tillarini qo'llab-quvvatlash uchun mo'ljallangan funksionallikdan ajratish va UI-mustaqil "yadro" komponentlarini bog'langan komponentlardan ajratish. qo'llab-quvvatlovchi foydalanuvchi interfeysi bilan.
Shunday qilib, Eclipse Platformasi umumiy, tildan mustaqil infratuzilmani belgilaydi va Java ishlab chiqish vositalari Eclipse-ga to'liq xususiyatli Java IDE qo'shadi. Eclipse Platformasi ham, JDT ham bir nechta komponentlardan iborat bo'lib, ularning har biri UI-dan mustaqil "yadro" yoki UI qatlamiga tegishli (1-rasm).
Guruch. 1. Eclipse platformasi va JDT
Keling, Eclipse platformasining asosiy komponentlarini sanab o'tamiz:
- Ish vaqti — Plagin infratuzilmasini belgilaydi. Eclipse modulli arxitektura bilan tavsiflanadi. Aslida, Eclipse "kengaytma nuqtalari" va "kengaytmalar" to'plamidir.
- Ish maydoni — Bir yoki bir nechta loyihani boshqaradi. Loyiha to'g'ridan-to'g'ri fayl tizimiga joylashtirilgan papkalar va fayllardan iborat.
- Standart vidjet asboblar to‘plami (SWT) - Operatsion tizim bilan integratsiyalashgan foydalanuvchi interfeysining asosiy elementlarini taqdim etadi.
- JFace — SWT ustiga qurilgan bir qator UI ramkalarini taqdim etadi.
- Workbench — Eclipse UI paradigmasini belgilaydi: muharrirlar, qarashlar, istiqbollar.
Aytish kerakki, Eclipse Platformasi integratsiyalashgan ishlab chiqish vositalarini yaratish uchun boshqa ko'plab foydali komponentlarni, jumladan, disk raskadrovka, solishtirish, qidirish va jamoani ham taqdim etadi. JFace Text-ni alohida ta'kidlash kerak - manba kodining "aqlli muharrirlarini" yaratish uchun asos. Afsuski, ushbu tarkibiy qismlarni, shuningdek, UI qatlamining tarkibiy qismlarini kursoriy tekshirish ham ushbu maqola doirasida mumkin emas, shuning uchun ushbu bo'limning qolgan qismida biz o'zimizni asosiy "asosiy" komponentlarning umumiy ko'rinishi bilan cheklaymiz. Eclipse platformasi va JDT.
Asosiy ish vaqti
Eclipse plaginlari infratuzilmasi asoslanadi va loyiha tomonidan taqdim etiladi . Har bir Eclipse plagini OSGi to'plamidir. OSGi spetsifikatsiyasi, xususan, versiyalarni yaratish va qaramlikni hal qilish mexanizmlarini belgilaydi. Ushbu standart mexanizmlarga qo'shimcha ravishda, Equinox kontseptsiyani taqdim etadi kengaytirish nuqtalari. Har bir plagin o'zining kengaytma nuqtalarini belgilashi mumkin, shuningdek, bir xil yoki boshqa plaginlar tomonidan belgilangan kengaytma nuqtalari yordamida tizimga qo'shimcha funktsiyalarni ("kengaytmalar") kiritishi mumkin. OSGi va Equinox mexanizmlarining har qanday batafsil tavsifi ushbu maqola doirasidan tashqarida. Shuni ta'kidlash kerakki, Eclipse-da modulizatsiya umumiydir (har qanday quyi tizim, shu jumladan Runtime, bir yoki bir nechta plaginlardan iborat) va Eclipse-dagi deyarli hamma narsa kengaytmadir. Bundan tashqari, ushbu tamoyillar Eclipse arxitekturasiga OSGi joriy etilishidan ancha oldin kiritilgan (o'sha paytda ular OSGi-ga o'xshash o'z texnologiyalaridan foydalanganlar).
Asosiy ish maydoni
Eclipse platformasi ustida qurilgan deyarli har qanday integratsiyalashgan ishlab chiqish muhiti Eclipse ish maydoni bilan ishlaydi. Bu odatda IDE da ishlab chiqilgan dasturning manba kodini o'z ichiga olgan ish maydoni. Ish maydoni to'g'ridan-to'g'ri fayl tizimiga mos keladi va papkalar va fayllarni o'z ichiga olgan loyihalardan iborat. Ushbu loyihalar, papkalar va fayllar deyiladi resurslar ish maydoni. Eclipse-da ish maydonini amalga oshirish fayl tizimiga nisbatan kesh bo'lib xizmat qiladi, bu esa resurs daraxti bo'ylab harakatlanishni sezilarli darajada tezlashtirishga imkon beradi. Bundan tashqari, ish maydoni bir qator qo'shimcha xizmatlarni taqdim etadi, jumladan и .
Core Resources komponenti (org.eclipse.core.resources plagini) ish maydoni va uning resurslarini qo'llab-quvvatlash uchun javobgardir. Xususan, ushbu komponent shakldagi ish maydoniga dasturiy kirishni ta'minlaydi resurs modellari. Ushbu model bilan samarali ishlash uchun mijozlarga manbaga havolani taqdim etishning oddiy usuli kerak. Bunday holda, modeldagi resurs holatini bevosita saqlaydigan ob'ektni mijoz kirishidan yashirish maqsadga muvofiqdir. Aks holda, masalan, faylni o'chirib tashlagan taqdirda, mijoz modelda bo'lmagan ob'ektni keyingi muammolar bilan ushlab turishni davom ettirishi mumkin. Eclipse bu muammoni deb nomlangan narsa yordamida hal qiladi Ushlab turing manba. Tutqich kalit vazifasini bajaradi (u faqat ish maydonidagi resursga yo'lni biladi) va resurs holati haqidagi ma'lumotlarni bevosita saqlaydigan ichki model ob'ektiga kirishni to'liq nazorat qiladi. Ushbu dizayn naqshning o'zgarishi .
Guruch. 2-rasmda resurs modeliga qo'llaniladigan tutqich/tana idiomasi tasvirlangan. IResource interfeysi resurs tutqichini ifodalaydi va bu interfeysni amalga oshiradigan Resurs sinfi va API bo'lmagan tanani ifodalovchi ResourceInfo sinfidan farqli o'laroq API hisoblanadi. Biz ta'kidlaymizki, tutqich faqat ish maydoni ildiziga nisbatan resursga yo'lni biladi va manba ma'lumotlariga havolani o'z ichiga olmaydi. Resurs ma'lumotlari ob'ektlari "element daraxti" deb ataladigan narsalarni tashkil qiladi. Ushbu ma'lumotlar strukturasi xotirada to'liq moddiylashtirilgan. Tutqichga mos keladigan manba ma'lumotlari misolini topish uchun element daraxti ushbu tutqichda saqlangan yo'lga ko'ra o'tadi.
Guruch. 2. IResource va ResourceInfo
Keyinchalik ko'rib chiqamiz, resurs modelining asosiy dizayni (biz uni dastakka asoslangan deb atashimiz mumkin) Eclipse-da boshqa modellar uchun ham qo'llaniladi. Hozircha ushbu dizaynning o'ziga xos xususiyatlarini sanab o'tamiz:
- Tutqich qiymat ob'ektidir. Qiymat ob'ektlari tengligi identifikatsiyaga asoslanmagan o'zgarmas ob'ektlardir. Bunday ob'ektlardan xeshlangan konteynerlarda kalit sifatida xavfsiz foydalanish mumkin. Tutqichning bir nechta nusxalari bir xil manbaga murojaat qilishi mumkin. Ularni solishtirish uchun teng (Object) usulidan foydalanish kerak.
- Tutqich resursning harakatini belgilaydi, lekin resurs holati haqida ma'lumotni o'z ichiga olmaydi (u saqlaydigan yagona ma'lumot "kalit", resursga yo'l).
- Tutqich mavjud bo'lmagan manbaga murojaat qilishi mumkin (hali yaratilmagan resurs yoki allaqachon o'chirilgan resurs). Resurs mavjudligini IResource.exists() usuli yordamida tekshirish mumkin.
- Ba'zi operatsiyalar faqat tutqichning o'zida saqlangan ma'lumotlarga asoslangan holda amalga oshirilishi mumkin (faqat ishlov berish operatsiyalari deb ataladi). Misollar IResource.getParent(), getFullPath() va boshqalar. Bunday operatsiya muvaffaqiyatli bo'lishi uchun resurs mavjud bo'lishi shart emas. Muvaffaqiyatli bo'lish uchun resurs mavjudligini talab qiladigan operatsiyalar, agar resurs mavjud bo'lmasa, CoreException ni chiqaradi.
Eclipse ish maydoni resurslarining o'zgarishi haqida xabar berishning samarali mexanizmini taqdim etadi (3-rasm). Resurslar Eclipse IDE-ning o'zida bajarilgan harakatlar natijasida yoki fayl tizimi bilan sinxronizatsiya natijasida o'zgarishi mumkin. Ikkala holatda ham bildirishnomalarga obuna bo'lgan mijozlarga "resurs deltalari" ko'rinishidagi o'zgarishlar haqida batafsil ma'lumot beriladi. Delta ish maydoni resursi (sub-) daraxtining ikki holati o'rtasidagi o'zgarishlarni tavsiflaydi va o'zi daraxt bo'lib, har bir tugun resursdagi o'zgarishlarni tavsiflaydi va keyingi darajadagi deltalar ro'yxatini o'z ichiga oladi, ular bolalar resurslariga kiritilgan o'zgarishlarni tavsiflaydi.
Guruch. 3. IResourceChangeEvent va IResourceDelta
Resurs deltalariga asoslangan bildirishnoma mexanizmi quyidagi xususiyatlarga ega:
- Bitta o'zgarish va ko'plab o'zgarishlar bir xil tuzilma yordamida tasvirlangan, chunki delta rekursiv kompozitsiya printsipi yordamida qurilgan. Abonent mijozlari deltalar daraxti orqali rekursiv tushish yordamida resurs o'zgarishi haqidagi bildirishnomalarni qayta ishlashlari mumkin.
- Delta resursdagi o'zgarishlar, shu jumladan uning harakati va/yoki u bilan bog'liq "markerlar"dagi o'zgarishlar haqida to'liq ma'lumotni o'z ichiga oladi (masalan, kompilyatsiya xatolar markerlar sifatida taqdim etiladi).
- Resurs havolalari tutqich orqali amalga oshirilganligi sababli, delta tabiiy ravishda masofaviy manbaga murojaat qilishi mumkin.
Tez orada ko'rib turganimizdek, resurs modeli o'zgarishi to'g'risida bildirishnoma mexanizmini loyihalashning asosiy komponentlari boshqa tutqichga asoslangan modellar uchun ham tegishli.
JDT yadrosi
Eclipse ish maydoni resurs modeli asosiy til-agnostik modeldir. JDT Core komponenti (plugin org.eclipse.jdt.core) "Java modeli" deb ataladigan Java nuqtai nazaridan ish maydoni tuzilishini navigatsiya qilish va tahlil qilish uchun API taqdim etadi (Java modeli). Ushbu API papkalar va fayllar nuqtai nazaridan aniqlangan asosiy resurs modeli API dan farqli ravishda Java elementlari nuqtai nazaridan aniqlanadi. Java elementlar daraxtining asosiy interfeyslari rasmda ko'rsatilgan. 4.
Guruch. 4. Java modeli elementlari
Java modeli resurs modeli bilan bir xil tutqich/tana idiomasidan foydalanadi (5-rasm). IJavaElement tutqich, JavaElementInfo esa tana rolini o'ynaydi. IJavaElement interfeysi barcha Java elementlari uchun umumiy protokolni belgilaydi. Uning ba'zi usullari faqat ishlov berish uchun mo'ljallangan: getElementName(), getParent() va boshqalar. JavaElementInfo obyekti tegishli elementning holatini saqlaydi: uning tuzilishi va atributlari.
Guruch. 5. IJavaElement va JavaElementInfo
Java modeli resurs modeliga nisbatan asosiy tutqich/tana dizaynini amalga oshirishda ba'zi farqlarga ega. Yuqorida ta'kidlab o'tilganidek, resurs modelida tugunlari resurs ma'lumotlari ob'ekti bo'lgan element daraxti to'liq xotirada joylashgan. Lekin Java modeli resurs daraxtiga qaraganda sezilarli darajada ko'p elementlarga ega bo'lishi mumkin, chunki u .java va .class fayllarining ichki tuzilishini ham ifodalaydi: turlari, maydonlari va usullari.
Xotiradagi elementlarning butun daraxtini to'liq amalga oshirishga yo'l qo'ymaslik uchun Java modelini amalga oshirish element ma'lumotlarining cheklangan o'lchamdagi LRU keshidan foydalanadi, bu erda kalit IJavaElement dastagidir. element ma'lumoti ob'ektlari element daraxti navigatsiya qilinganda talab bo'yicha yaratiladi. Bunday holda, eng kam ishlatiladigan elementlar keshdan chiqariladi va modelning xotira iste'moli belgilangan kesh hajmi bilan cheklangan bo'lib qoladi. Bu tutqichga asoslangan dizaynning yana bir afzalligi bo'lib, u bunday amalga oshirish tafsilotlarini mijoz kodidan butunlay yashiradi.
Java elementlariga o'zgartirishlar haqida xabar berish mexanizmi, odatda, yuqorida muhokama qilingan ish maydoni resurslaridagi o'zgarishlarni kuzatish mexanizmiga o'xshaydi. Java modelidagi o'zgarishlarni kuzatmoqchi bo'lgan mijoz IJavaElementDelta ni o'z ichiga olgan ElementChangedEvent obyekti sifatida taqdim etilgan bildirishnomalarga obuna bo'ladi (6-rasm).
Guruch. 6. ElementChangedEvent va IJavaElementDelta
Java modelida usul tanasi yoki nom rezolyutsiyasi haqida ma'lumot mavjud emas, shuning uchun Java-da yozilgan kodni batafsil tahlil qilish uchun JDT Core qo'shimcha (tutqichga asoslangan bo'lmagan) modelni taqdim etadi: (mavhum sintaksis daraxti, AST). AST manba matnini tahlil qilish natijasini ifodalaydi. AST tugunlari manba moduli strukturasining elementlariga (deklaratsiyalar, operatorlar, iboralar va boshqalar) mos keladi va manba matnidagi tegishli elementning koordinatalari to'g'risidagi ma'lumotlarni, shuningdek (variant sifatida) nomni aniqlash to'g'risidagi ma'lumotlarni o'z ichiga oladi. deb atalmish havolalar shakli bog'lash. Bog'lanishlar - kompilyatorga ma'lum bo'lgan turlar, usullar va o'zgaruvchilar kabi nomlangan ob'ektlarni ifodalovchi ob'ektlar. Daraxtni tashkil etuvchi AST tugunlaridan farqli o'laroq, bog'lanishlar o'zaro bog'lanishni qo'llab-quvvatlaydi va odatda grafikni hosil qiladi. ASTNode mavhum sinfi barcha AST tugunlari uchun umumiy tayanch sinfdir. ASTNode kichik sinflari Java tilining o'ziga xos sintaktik konstruksiyalariga mos keladi.
Sintaksis daraxtlari katta hajmdagi xotirani iste'mol qilishi mumkinligi sababli, JDT faol muharrir uchun faqat bitta ASTni keshlaydi. Java modelidan farqli o'laroq, AST odatda "oraliq", "vaqtinchalik" model sifatida qaraladi, uning a'zolari ASTni yaratishga olib kelgan operatsiya kontekstidan tashqarida mijozlar tomonidan havola qilinmasligi kerak.
Ro'yxatda keltirilgan uchta model (Java modeli, AST, bog'lashlar) birgalikda JDTda "aqlli ishlab chiqish vositalari" ni yaratish uchun asos bo'lib xizmat qiladi, shu jumladan turli xil "yordamchilar" ga ega kuchli Java muharriri, manba kodini qayta ishlash uchun turli xil harakatlar (shu jumladan import ro'yxatini tashkil qilish). moslashtirilgan uslubga muvofiq nomlar va formatlash), qidiruv va refaktoring vositalari. Bunday holda, Java modeli alohida rol o'ynaydi, chunki u ishlab chiqilayotgan dastur tuzilishini vizual ko'rsatish uchun asos sifatida ishlatiladi (masalan, Package Explorer, Outline, Search, Call ierarxiyasi va Ierarxiya turi).
1C: Enterprise Development Tools da ishlatiladigan Eclipse komponentlari
Shaklda. 7-rasmda 1C: Enterprise Development Tools uchun texnologik platformaning asosini tashkil etuvchi Eclipse komponentlari ko'rsatilgan.
Guruch. 7. Eclipse 1C: Enterprise Development Tools platformasi sifatida
Eclipse platformasi asosiy infratuzilmani ta'minlaydi. Biz oldingi bo'limda ushbu infratuzilmaning ba'zi jihatlarini ko'rib chiqdik.
(EMF) tuzilgan ma'lumotlarni modellashtirishning umumiy vositalarini taqdim etadi. EMF Eclipse platformasi bilan birlashtirilgan, ammo oddiy Java ilovalarida alohida foydalanish mumkin. Ko'pincha yangi Eclipse ishlab chiquvchilari Eclipse platformasining nozik tomonlarini hali to'liq tushunmasalar ham, EMF bilan yaxshi tanish. Bunday munosib mashhurlikning sabablaridan biri universal dizayn bo'lib, u boshqa narsalar qatorida har qanday EMF modeli bilan umumiy tarzda ishlashga imkon beruvchi yagona meta-darajali API-ni o'z ichiga oladi. EMF tomonidan taqdim etilgan model ob'ektlari uchun asosiy ilovalar va meta-modelga asoslangan model kodini yaratish quyi tizimi rivojlanish tezligini sezilarli darajada oshiradi va xatolar sonini kamaytiradi. EMF shuningdek, modellarni ketma-ketlashtirish, modeldagi o'zgarishlarni kuzatish va boshqalar uchun mexanizmlarni o'z ichiga oladi.
Har qanday haqiqiy umumiy maqsadli vosita singari, EMF keng ko'lamli modellashtirish muammolarini hal qilish uchun javob beradi, ammo ba'zi modellar sinflari (masalan, yuqorida muhokama qilingan dastakka asoslangan modellar) ko'proq ixtisoslashgan modellashtirish vositalarini talab qilishi mumkin. EMF haqida gapirish, ayniqsa, bitta maqolaning cheklangan doirasidagi noshukur ishdir, chunki bu alohida kitobning mavzusi va juda qalin. Shuni ta'kidlash kerakki, EMF asosidagi yuqori sifatli umumlashtirish tizimi yuqori darajadagi loyihaga kiritilgan modellashtirishga bag'ishlangan bir qator loyihalarni yaratishga imkon berdi. EMFning o'zi bilan birga. Shunday loyihalardan biri Eclipse Xtext.
“matnni modellashtirish” infratuzilmasini taqdim etadi. Xtext foydalanadi manba matnini tahlil qilish va natijada olingan ASGni ifodalash uchun EMF (asosan AST va bog'lanishlarning kombinatsiyasi bo'lgan mavhum semantik grafik), shuningdek, "semantik model" deb ham ataladi. Xtext tomonidan modellashtirilgan tilning grammatikasi Xtextning o'z tilida tasvirlangan. Bu nafaqat ANTLR uchun grammatika tavsifini yaratish, balki AST seriyalash mexanizmini (ya'ni, Xtext ham tahlil qiluvchi, ham tahlil qiluvchini ta'minlaydi), kontekstga ishora va bir qator boshqa til komponentlarini olish imkonini beradi. Boshqa tomondan, Xtext-da ishlatiladigan grammatika tili, aytaylik, ANTLR-da ishlatiladigan grammatika tiliga qaraganda kamroq moslashuvchan. Shuning uchun, ba'zida amalga oshirilgan tilni Xtextga "egish" kerak bo'ladi, bu odatda noldan ishlab chiqilayotgan til haqida gapiradigan bo'lsak, bu muammo emas, lekin allaqachon o'rnatilgan sintaksisi bo'lgan tillar uchun nomaqbul bo'lishi mumkin. Shunga qaramay, Xtext hozirda Eclipse-da dasturlash tillari va ularni ishlab chiqish vositalarini yaratish uchun eng etuk, xususiyatlarga boy va ko'p qirrali vositadir. Xususan, bu tezkor prototiplash uchun ideal vositadir (domenga xos til, DSL). Yuqorida aytib o'tilgan ANTLR va EMFga asoslangan "til yadrosi" ga qo'shimcha ravishda, Xtext ko'plab foydali yuqori darajadagi komponentlarni, jumladan indekslash mexanizmlarini, qo'shimcha qurilishni, "aqlli muharrirni" va boshqa ko'p narsalarni taqdim etadi, lekin qo'llanmani qoldiradi. asoslangan til modellari. EMF singari, Xtext alohida kitobga loyiq mavzu bo'lib, biz hozir uning barcha imkoniyatlari haqida qisqacha gapira olmaymiz.
1C: Enterprise Development Tools EMFning o'zi va boshqa bir qator Eclipse Modeling loyihalaridan faol foydalanadi. Xususan, Xtext o'rnatilgan dasturlash tili va so'rovlar tili kabi 1C: Enterprise tillarini ishlab chiqish vositalarining asoslaridan biridir. Ushbu ishlab chiqish vositalarining yana bir asosi Eclipse Handly loyihasi bo'lib, biz uni batafsilroq ko'rib chiqamiz (Ro'yxatda keltirilgan Eclipse komponentlaridan u hali ham eng kam ma'lum).
, Eclipse Technology yuqori darajadagi loyihasining kichik loyihasi, 1 yilda 2014C tomonidan Eclipse Foundation dasturiga kiritilgan dastlabki kod hissasi natijasida paydo bo'ldi. O'shandan beri 1C loyihani ishlab chiqishni qo'llab-quvvatlashni davom ettirdi: Qo'llab-quvvatlovchilar kompaniya xodimlaridir. Loyiha kichik, ammo u Eclipse-da juda noyob joyni egallaydi: uning asosiy maqsadi dastakka asoslangan modellarni ishlab chiqishni qo'llab-quvvatlashdir.
Tutqichga asoslangan modellarning asosiy me'moriy tamoyillari, masalan, tutqich/tana idiomasi, misol sifatida manba modeli va Java modelidan foydalangan holda yuqorida muhokama qilindi. Shuningdek, resurs modeli ham, Java modeli ham Eclipse Java ishlab chiqish vositalari (JDT) uchun muhim asoslar ekanligini taʼkidladi. Deyarli barcha *DT Eclipse loyihalari JDTga o'xshash arxitekturaga ega bo'lganligi sababli, Eclipse Platformasi tepasida qurilgan barcha IDElar bo'lmasa ham, dastakka asoslangan modellar ko'pchilikning asosini tashkil qiladi, desak mubolag'a bo'lmaydi. Masalan, Eclipse C/C++ Development Tooling (CDT) dastakka asoslangan C/C++ modeliga ega bo'lib, CDT arxitekturasida Java modeli JDTda qanday rol o'ynaydi.
Handlydan oldin Eclipse dastakka asoslangan til modellarini yaratish uchun maxsus kutubxonalarni taklif qilmagan. Hozirda mavjud bo'lgan modellar asosan Java model kodini to'g'ridan-to'g'ri moslashtirish orqali yaratilgan (aka nusxa ko'chirish/joylashtirish), ruxsat bergan hollarda Eclipse Public License (EPL). (Shubhasiz, bu, masalan, Eclipse loyihalarining o‘zi uchun huquqiy muammo emas, lekin yopiq manbali mahsulotlar uchun emas.) Bu usul o‘ziga xos tasodifiylikdan tashqari, taniqli muammolarni ham keltirib chiqaradi: xatolarga moslashishda kodning takrorlanishi, va boshqalar. Eng yomoni, natijada paydo bo'lgan modellar "o'z-o'zidan narsalar" bo'lib qoladi va birlashish potentsialidan foydalanmaydi. Ammo dastakka asoslangan til modellari uchun umumiy tushunchalar va protokollarni izolyatsiya qilish, EMF holatida bo'lgani kabi, ular bilan ishlash uchun qayta foydalanish mumkin bo'lgan komponentlarni yaratishga olib kelishi mumkin.
Eclipse bu muammolarni tushunmagani emas. 2005 yilda , CDT prototipini ishlab chiqish tajribasini umumlashtirib, til modellari, shu jumladan tutqichga asoslangan modellar uchun umumiy infratuzilmani yaratish zarurati. Ammo, tez-tez bo'lganidek, ustuvor vazifalar tufayli bu g'oyalarni amalga oshirish hech qachon amalga oshmadi. Ayni paytda, *DT kodini faktorizatsiya qilish Eclipse-da hali ham rivojlanmagan mavzulardan biri hisoblanadi.
Muayyan ma'noda Handly loyihasi EMF bilan bir xil muammolarni hal qilish uchun mo'ljallangan, lekin dastakka asoslangan modellar va birinchi navbatda til uchun (ya'ni, ba'zi dasturlash tilining strukturasi elementlarini ifodalovchi) uchun. Handly-ni loyihalashda qo'yilgan asosiy maqsadlar quyida keltirilgan:
- Mavzu sohasining asosiy abstraksiyalarini aniqlash.
- Kodni qayta ishlatish orqali dastakka asoslangan til modellarini amalga oshirish sifatini oshirish va harakatlarni kamaytirish.
- Olingan modellarga yagona meta-darajali API taqdim etish, til boshqaruviga asoslangan modellar bilan ishlaydigan umumiy IDE komponentlarini yaratish imkonini beradi.
- Moslashuvchanlik va miqyoslilik.
- Xtext bilan integratsiya (alohida qatlamda).
Umumiy tushunchalar va protokollarni ta'kidlash uchun til boshqaruviga asoslangan modellarning mavjud ilovalari tahlil qilindi. Handly tomonidan taqdim etilgan asosiy interfeyslar va asosiy ilovalar rasmda ko'rsatilgan. 8.
Guruch. 8. Handly elementlarining umumiy interfeyslari va asosiy ilovalari
IElement interfeysi elementning dastagini ifodalaydi va Handly-asosidagi barcha modellarning elementlari uchun umumiydir. Mavhum sinf Element umumlashtirilgan tutqich/tana mexanizmini amalga oshiradi (9-rasm).
Guruch. 9. IElement va umumiy tutqich/tanani amalga oshirish
Bundan tashqari, Handly model elementlaridagi o'zgarishlar haqida xabar berishning umumlashtirilgan mexanizmini taqdim etadi (10-rasm). Ko'rib turganingizdek, u resurs modelida va Java modelida amalga oshirilgan bildirishnoma mexanizmlariga keng o'xshaydi va elementlarni o'zgartirish haqidagi ma'lumotni birlashtirilgan taqdim etish uchun IElementDelta'dan foydalanadi.
Guruch. 10. Handly bildirishnoma mexanizmining umumiy interfeyslari va asosiy ilovalari
Yuqorida muhokama qilingan Handly qismi (9 va 10-rasm) deyarli har qanday tutqichga asoslangan modellarni ifodalash uchun ishlatilishi mumkin. Yaratish uchun lingvistik modellar uchun loyiha qo'shimcha funktsiyalarni taklif qiladi - xususan, umumiy interfeyslar va manba matn tuzilishi elementlari uchun asosiy ilovalar, manba elementlari (8-rasm). ISourceFile interfeysi manba faylni, ISourceConstruct esa manba fayl ichidagi elementni ifodalaydi. SourceFile va SourceConstruct mavhum sinflari manba fayllari va ularning elementlari bilan ishlashni qo'llab-quvvatlash uchun umumlashtirilgan mexanizmlarni amalga oshiradi, masalan, matn buferlari bilan ishlash, manba matnidagi elementning koordinatalari bilan bog'lanish, modellarni ishchi nusxa buferining joriy mazmuni bilan moslashtirish. , va boshqalar. Ushbu mexanizmlarni amalga oshirish odatda juda qiyin va Handly yuqori sifatli bazaviy ilovalarni taqdim etish orqali dastakka asoslangan til modellarini ishlab chiqish harakatlarini sezilarli darajada kamaytirishi mumkin.
Yuqorida sanab o'tilgan asosiy mexanizmlarga qo'shimcha ravishda, Handly matn buferlari va oniy tasvirlar uchun infratuzilmani, manba kodi muharrirlari bilan integratsiyani qo'llab-quvvatlashni (jumladan, Xtext muharriri bilan to'liq integratsiyani), shuningdek, ba'zi umumiy UI komponentlarini taqdim etadi. manba kodi muharrirlari bilan ishlash, kontur ramkasi kabi qulay modellar. Uning imkoniyatlarini ko'rsatish uchun loyiha bir nechta misollarni, jumladan, Handly-da Java modelini amalga oshirishni taqdim etadi. (Java modelining JDT-da to'liq amalga oshirilishi bilan solishtirganda, bu model aniqroq bo'lishi uchun ataylab biroz soddalashtirilgan.)
Yuqorida ta'kidlab o'tilganidek, Handlyning dastlabki dizayni va keyingi rivojlanishida asosiy e'tibor miqyoslilik va moslashuvchanlikka qaratilgan edi va shunday bo'ladi.
Aslida, tutqichga asoslangan modellar "dizayn bo'yicha" juda yaxshi o'lchaydi. Misol uchun, tutqich/tana idiomasi model tomonidan iste'mol qilinadigan xotira miqdorini cheklash imkonini beradi. Ammo nuanslar ham bor. Shunday qilib, Handly-ni miqyosda sinab ko'rishda bildirishnoma mexanizmini amalga oshirishda muammo aniqlandi - ko'p sonli elementlar o'zgartirilganda, deltalarni qurish juda ko'p vaqtni oldi. Ma'lum bo'lishicha, xuddi shu muammo JDT Java modelida mavjud bo'lib, undan tegishli kod bir vaqtlar moslashtirilgan. Biz Handly-dagi xatoni tuzatdik va JDT uchun shunga o'xshash yamoq tayyorladik, u minnatdorchilik bilan qabul qilindi. Bu mavjud model ilovalariga Handly ni kiritish potentsial foydali bo'lishi mumkin bo'lgan bir misol, chunki bu holda bunday xatolik faqat bitta joyda tuzatilishi mumkin.
Handly-ni mavjud modellarni amalga oshirishni texnik jihatdan amalga oshirish uchun kutubxona sezilarli moslashuvchanlikka ega bo'lishi kerak. Asosiy muammo API modeli bo'ylab orqaga qarab muvofiqlikni saqlab qolishdir. Bu muammo yilda hal qilindi Ishlab chiquvchi tomonidan belgilangan va toʻliq nazorat qilinadigan modelga xos APIni kutubxona tomonidan taqdim etilgan yagona meta-darajali APIdan aniq ajratish orqali. Bu nafaqat Handlyni mavjud ilovalarga texnik jihatdan tatbiq etish imkonini beradi, balki yangi modelni ishlab chiquvchiga APIni loyihalashda sezilarli erkinlik beradi.
Moslashuvchanlikning boshqa jihatlari ham bor. Misol uchun, Handly model tuzilishiga deyarli hech qanday cheklovlar qo'ymaydi va umumiy maqsadli va domenga xos tillarni modellashtirish uchun ishlatilishi mumkin. Manba faylining strukturasini yaratishda Handly AST ko'rsatishning biron bir shaklini belgilamaydi va, qoida tariqasida, ASTning o'zi mavjudligini ham talab qilmaydi, shuning uchun deyarli har qanday tahlil qilish mexanizmi bilan muvofiqlikni ta'minlaydi. Va nihoyat, Handly Eclipse ish maydoni bilan to'liq integratsiyani qo'llab-quvvatlaydi, lekin u bilan integratsiyalashgani tufayli fayl tizimlari bilan bevosita ishlashi mumkin. (EFS).
Joriy versiya 2016 yil dekabr oyida chiqdi. Loyiha hozirda inkubatsiya holatida bo'lishiga va API hali oxirigacha tuzatilmaganiga qaramay, Handly allaqachon ikkita yirik tijorat mahsulotida qo'llanilgan bo'lib, ular "erta qabul qiluvchilar" sifatida harakat qilish xavfini o'z zimmalariga olganlar va shuni aytishim kerakki, hali afsuslanmang.
Yuqorida ta'kidlab o'tilganidek, ushbu mahsulotlardan biri 1C: Enterprise Development Tools bo'lib, u erda Handly boshidanoq o'rnatilgan dasturlash tili va so'rovlar tili sifatida 1C: Enterprise tillarining yuqori darajadagi tuzilmasi elementlarini modellashtirish uchun ishlatiladi. . Boshqa mahsulot keng jamoatchilikka kamroq ma'lum. Bu , Chexiyaning Codasip kompaniyasining o'zida ham, mijozlari tomonidan ham qo'llaniladigan amaliy ko'rsatmalar to'plami protsessorining (ASIP) integratsiyalashgan dizayn muhiti, shu jumladan , , , . Codasip Handly-dan Handly 2015 versiyasidan boshlab 0.2 yildan beri ishlab chiqarishda foydalanmoqda. Codasip Studio-ning so'nggi versiyasi 0.5 yil iyun oyida chiqarilgan 2016 versiyasidan foydalanadi. Codasip-da IDE-ni ishlab chiqishga rahbarlik qiluvchi Ondjej Ilčík loyiha bilan aloqada bo'lib, "uchinchi tomon qabul qiluvchi" nomidan muhim fikr-mulohazalarni taqdim etadi. U hatto loyihani ishlab chiqishda bevosita ishtirok etish uchun bo'sh vaqt topib, Handly misollaridan biri, Java modeli uchun UI qatlamini (~4000 qator kod) amalga oshirdi. Handly dasturini qabul qiluvchilar tomonidan qo'llanilishi haqida batafsil ma'lumotni sahifada topishingiz mumkin loyiha.
Umid qilamizki, API barqarorligi kafolati va loyiha inkubatsiya holatidan chiqqan 1.0 versiyasi chiqarilgandan so'ng Handly yangi qabul qiluvchilarga ega bo'ladi. Shu bilan birga, loyiha API-ni sinovdan o'tkazish va yanada takomillashtirishni davom ettirmoqda, yiliga ikkita "asosiy" relizlarni chiqaradi - iyunda (bir vaqtning o'zida Eclipse nashri bilan bir xil sana) va dekabrda, qabul qiluvchilar ishonishi mumkin bo'lgan taxminiy jadvalni taqdim etadi. Bundan tashqari, loyihaning "xatolik darajasi" doimiy ravishda past darajada qolayotganini qo'shishimiz mumkin va Handly birinchi versiyalardan boshlab erta qabul qiluvchilarning mahsulotlarida ishonchli ishlamoqda. Eclipse Handly-ni batafsil o'rganish uchun siz foydalanishingiz mumkin и .
Manba: www.habr.com