Ola bilər, çoxdan xüsusi təqdimata ehtiyac duymur. Eclipse Java inkişaf alətləri sayəsində bir çox insan Eclipse ilə tanışdır (). Məhz bu məşhur açıq mənbəli Java IDE-dir ki, əksər tərtibatçılar “Eclipse” sözü ilə əlaqələndirirlər. Bununla belə, Eclipse həm inkişaf alətlərini (Eclipse Platforması) inteqrasiya etmək üçün genişləndirilə bilən platformadır, həm də JDT də daxil olmaqla onun əsasında qurulmuş bir sıra IDE-dir. Eclipse həm Eclipse Layihəsi, həm Eclipse Platforması və JDT-nin inkişafını əlaqələndirən ən yüksək səviyyəli layihə, həm də bu inkişafın əldə edilmiş nəticəsi olan Eclipse SDK-dır. Nəhayət, Eclipse, hamısı Java-da yazılmamış və ya inkişaf alətləri (məsələn, layihələr) ilə əlaqəli olmayan böyük bir layihə icması olan açıq mənbəli Vəqfdir. и ). Eclipse dünyası çox müxtəlifdir.
Təbiətdə ümumi olan bu məqalədə biz inteqrasiya olunmuş inkişaf alətləri yaratmaq üçün platforma kimi Eclipse arxitekturasının bəzi əsaslarına baxmağa və texnologiyanın əsasını təşkil edən Eclipse komponentləri haqqında ilkin fikir verməyə çalışacağıq. "yeni Konfiqurator" 1C: Müəssisə üçün platforma. . Əlbəttə ki, belə bir baxış istər-istəməz əsasən səthi və kifayət qədər məhdud olacaq, o cümlədən hədəf auditoriyası kimi təkcə Eclipse tərtibatçılarına diqqət yetirmədiyimiz üçün. Bununla belə, ümid edirik ki, hətta təcrübəli Eclipse tərtibatçıları da məqalədə maraqlı məlumatlar tapa biləcəklər. Məsələn, nisbətən yeni və az tanınan layihə olan “Tutulmanın sirrlərindən” biri haqqında danışacağıq. 1C tərəfindən qurulan və dəstəklənən.
Eclipse Arxitekturasına Giriş
Əvvəlcə nümunədən istifadə edərək Eclipse arxitekturasının bəzi ümumi aspektlərinə nəzər salaq (JDT). Nümunə olaraq JDT-nin seçilməsi təsadüfi deyil. Bu, Eclipse-də görünən ilk inteqrasiya olunmuş inkişaf mühitidir. Eclipse C/C++ İnkişaf Alətləri (CDT) kimi digər *DT Eclipse layihələri daha sonra yaradılmışdır və JDT-dən həm əsas memarlıq prinsiplərini, həm də fərdi mənbə kodu fraqmentlərini götürmüşdür. JDT-də təsbit edilmiş arxitekturanın əsasları 1C: Müəssisə İnkişaf Alətləri də daxil olmaqla, Eclipse Platformasının üzərində qurulmuş demək olar ki, hər hansı bir IDE üçün bu günə aiddir.
İlk növbədə qeyd etmək lazımdır ki, Eclipse kifayət qədər aydın memarlıq təbəqəsi ilə xarakterizə olunur, dildən asılı olmayan funksionallıq xüsusi proqramlaşdırma dillərini dəstəkləmək üçün nəzərdə tutulmuş funksionallıqdan ayrılır və UI-dən asılı olmayan "əsas" komponentlər əlaqəli komponentlərdən ayrılır. dəstəkləyən istifadəçi interfeysi ilə.
Beləliklə, Eclipse Platforması ümumi, dildən asılı olmayan infrastrukturu müəyyənləşdirir və Java inkişaf alətləri Eclipse-ə tam xüsusiyyətli Java IDE əlavə edir. Həm Eclipse Platforması, həm də JDT hər biri ya UI-dən asılı olmayan "nüvə" və ya UI qatına aid olan bir neçə komponentdən ibarətdir (Şəkil 1).
düyü. 1. Eclipse Platforması və JDT
Eclipse Platformasının əsas komponentlərini sadalayaq:
- İş vaxtı — Plugin infrastrukturunu müəyyən edir. Eclipse modul arxitektura ilə xarakterizə olunur. Əslində, Eclipse "uzatma nöqtələri" və "uzantılar" toplusudur.
- İş sahəsi — Bir və ya bir neçə layihəni idarə edir. Layihə birbaşa fayl sisteminə uyğunlaşdırılmış qovluq və fayllardan ibarətdir.
- Standart Vidcet Alətlər Dəsti (SWT) - Əməliyyat sistemi ilə inteqrasiya olunmuş əsas istifadəçi interfeysi elementlərini təmin edir.
- JFace — SWT üzərində qurulmuş bir sıra UI çərçivələrini təmin edir.
- Workbench — Eclipse UI paradiqmasını müəyyən edir: redaktorlar, baxışlar, perspektivlər.
Qeyd etmək lazımdır ki, Eclipse Platforması, həmçinin Sazlama, Müqayisə, Axtarış və Komanda daxil olmaqla inteqrasiya olunmuş inkişaf alətlərinin yaradılması üçün bir çox faydalı komponentlər təqdim edir. Mənbə kodunun “ağıllı redaktorlarının” qurulması üçün əsas olan JFace Text-i xüsusi qeyd etmək lazımdır. Təəssüf ki, hətta bu komponentlərin, eləcə də UI təbəqəsinin komponentlərinin kursor şəkildə araşdırılması bu məqalə çərçivəsində mümkün deyil, ona görə də bu bölmənin qalan hissəsində biz özümüzü əsas “əsas” komponentlərin icmalı ilə məhdudlaşdıracağıq. Eclipse Platforması və JDT.
Əsas iş vaxtı
Eclipse plagin infrastrukturu əsaslanır və layihə tərəfindən təmin edilir . Hər Eclipse plagini bir OSGi paketidir. OSGi spesifikasiyası, xüsusən, versiya və asılılıq həlli mexanizmlərini müəyyən edir. Bu standart mexanizmlərə əlavə olaraq, Equinox konsepsiyanı təqdim edir genişlənmə nöqtələri. Hər bir plagin öz genişləndirmə nöqtələrini təyin edə bilər, həmçinin eyni və ya digər plaginlər tərəfindən müəyyən edilmiş genişləndirmə nöqtələrindən istifadə edərək sistemə əlavə funksionallıq (“uzantılar”) təqdim edə bilər. OSGi və Equinox mexanizmlərinin hər hansı ətraflı təsviri bu məqalənin əhatə dairəsindən kənardadır. Yalnız qeyd edək ki, Eclipse-də modullaşdırma ümumidir (Runtime daxil olmaqla istənilən alt sistem bir və ya bir neçə plagindən ibarətdir) və Eclipse-də demək olar ki, hər şey bir uzantıdır. Üstəlik, bu prinsiplər Eclipse arxitekturasına OSGi-nin tətbiqindən çox əvvəl daxil edilmişdir (o zaman onlar OSGi-yə çox oxşar olan öz texnologiyalarından istifadə edirdilər).
Əsas iş sahəsi
Eclipse Platformasının üzərində qurulmuş demək olar ki, hər hansı inteqrasiya olunmuş inkişaf mühiti Eclipse iş sahəsi ilə işləyir. Adətən IDE-də hazırlanmış tətbiqin mənbə kodunu ehtiva edən iş sahəsidir. İş sahəsi birbaşa fayl sisteminə xəritə verir və qovluq və faylları ehtiva edən layihələrdən ibarətdir. Bu layihələr, qovluqlar və fayllar adlanır resurslar iş sahəsi. Eclipse-də iş sahəsinin tətbiqi fayl sistemi ilə əlaqəli bir keş kimi xidmət edir, bu da resurs ağacının keçidini əhəmiyyətli dərəcədə sürətləndirməyə imkan verir. Bundan əlavə, iş sahəsi də daxil olmaqla bir sıra əlavə xidmətlər təqdim edir и .
Əsas Resurslar komponenti (org.eclipse.core.resources plagini) iş sahəsini və onun resurslarını dəstəkləmək üçün məsuliyyət daşıyır. Xüsusilə, bu komponent formada iş sahəsinə proqramlı girişi təmin edir resurs modelləri. Bu modellə effektiv işləmək üçün müştərilərə resursa keçid təqdim etmək üçün sadə üsul lazımdır. Bu halda, modeldə resursun vəziyyətini birbaşa saxlayan obyekti müştəri girişindən gizlətmək arzuolunan olardı. Əks halda, məsələn, faylın silinməsi halında, müştəri daha sonra modeldə olmayan obyekti saxlamağa davam edə bilər. Eclipse adlı bir şeydən istifadə edərək bu problemi həll edir idarə resurs. Dəstək açar rolunu oynayır (yalnız iş yerində resursa gedən yolu bilir) və resursun vəziyyəti haqqında məlumatı birbaşa saxlayan daxili model obyektinə girişi tam idarə edir. Bu dizayn nümunənin bir variasiyasıdır .
düyü. Şəkil 2 resurs modelinə tətbiq edilən Handle/Body idiomunu təsvir edir. IResource interfeysi bu interfeysi həyata keçirən Resurs sinifindən və API olmayan bədəni təmsil edən ResourceInfo sinfindən fərqli olaraq resursun idarəedicisini təmsil edir və API-dir. Biz vurğulayırıq ki, tutacaq yalnız iş sahəsinin kökünə nisbətən resursa gedən yolu bilir və resurs məlumatına keçidi ehtiva etmir. Resurs məlumatı obyektləri sözdə “element ağacı” təşkil edir. Bu məlumat strukturu tamamilə yaddaşda maddiləşdirilir. Dəstəyə uyğun resurs məlumatı nümunəsini tapmaq üçün element ağacı həmin tutacaqda saxlanılan yola uyğun olaraq keçilir.
düyü. 2. IResource və ResourceInfo
Daha sonra görəcəyimiz kimi, resurs modelinin əsas dizaynı (biz onu tutacaq əsaslı adlandıra bilərik) digər modellər üçün də Eclipse-də istifadə olunur. Hələlik bu dizaynın bəzi fərqli xüsusiyyətlərini sadalayaq:
- Dəstək dəyər obyektidir. Dəyər obyektləri bərabərliyi şəxsiyyətə əsaslanmayan dəyişməz obyektlərdir. Bu cür obyektlər hashed konteynerlərdə açar kimi etibarlı şəkildə istifadə edilə bilər. Dəstəyin bir neçə nümunəsi eyni mənbəyə istinad edə bilər. Onları müqayisə etmək üçün equals(Object) metodundan istifadə etməlisiniz.
- Handle resursun davranışını müəyyən edir, lakin resursun vəziyyəti haqqında məlumatı ehtiva etmir (onun saxladığı yeganə məlumat "açar", resursa gedən yoldur).
- Dəstək mövcud olmayan resursa istinad edə bilər (ya hələ yaradılmamış resurs, ya da artıq silinmiş resurs). Resursun mövcudluğu IResource.exists() metodu ilə yoxlanıla bilər.
- Bəzi əməliyyatlar yalnız sapın özündə saxlanılan məlumat əsasında həyata keçirilə bilər (sözdə yalnız tutucu əməliyyatlar). Nümunələr IResource.getParent(), getFullPath() və s. Belə bir əməliyyatın uğur qazanması üçün resursun mövcud olmasına ehtiyac yoxdur. Uğurlu olmaq üçün resursun mövcud olmasını tələb edən əməliyyatlar, əgər resurs mövcud deyilsə, istisna (CoreException) atır.
Eclipse iş sahəsinin resurs dəyişikliklərini bildirmək üçün səmərəli mexanizm təqdim edir (Şəkil 3). Resurslar ya Eclipse IDE-nin özündə həyata keçirilən hərəkətlər nəticəsində, ya da fayl sistemi ilə sinxronizasiya nəticəsində dəyişə bilər. Hər iki halda bildirişlərə abunə olan müştərilərə “resurs deltaları” şəklində dəyişikliklər haqqında ətraflı məlumat verilir. Delta iş sahəsi resursunun (alt) ağacının iki vəziyyəti arasındakı dəyişiklikləri təsvir edir və özü bir ağacdır, hər bir qovşağı resursdakı dəyişikliyi təsvir edir və uşaq resurslarında dəyişiklikləri təsvir edən növbəti səviyyədə deltaların siyahısını ehtiva edir.
düyü. 3. IResourceChangeEvent və IResourceDelta
Resurs deltalarına əsaslanan bildiriş mexanizmi aşağıdakı xüsusiyyətlərə malikdir:
- Delta rekursiv kompozisiya prinsipindən istifadə edilməklə qurulduğundan, tək dəyişiklik və bir çox dəyişikliklər eyni strukturdan istifadə etməklə təsvir olunur. Abunəçi müştərilər, deltalar ağacı vasitəsilə rekursiv enişdən istifadə edərək resurs dəyişikliyi bildirişlərini emal edə bilərlər.
- Delta resursdakı dəyişikliklər, o cümlədən onun hərəkəti və/və ya onunla əlaqəli "markerlər"dəki dəyişikliklər haqqında tam məlumatı ehtiva edir (məsələn, tərtib səhvləri markerlər kimi təqdim olunur).
- Resurs istinadları tutacaq vasitəsilə edildiyindən, delta təbii olaraq uzaq resursa istinad edə bilər.
Tezliklə görəcəyimiz kimi, resurs modelinin dəyişdirilməsi bildiriş mexanizminin dizaynının əsas komponentləri digər tutacaq əsaslı modellər üçün də aktualdır.
JDT nüvəsi
Eclipse iş sahəsi resursu modeli fundamental dil-aqnostik modeldir. JDT Core komponenti (plugin org.eclipse.jdt.core) “Java modeli” adlanan Java nöqteyi-nəzərindən iş sahəsi strukturunda naviqasiya və təhlil etmək üçün API təmin edir.Java modeli). Bu API, qovluqlar və fayllar baxımından müəyyən edilən əsas resurs modeli API-dən fərqli olaraq Java elementləri baxımından müəyyən edilir. Java element ağacının əsas interfeysləri Şəkil 4-də göstərilmişdir. XNUMX.
düyü. 4. Java Model Elementləri
Java modeli resurs modeli ilə eyni tutacaq/bədən deyimindən istifadə edir (Şəkil 5). IJavaElement tutacaq, JavaElementInfo isə bədən rolunu oynayır. IJavaElement interfeysi bütün Java elementləri üçün ümumi olan protokolu müəyyən edir. Onun bəzi üsulları yalnız idarəedicidir: getElementName(), getParent() və s. JavaElementInfo obyekti müvafiq elementin vəziyyətini saxlayır: onun strukturu və atributları.
düyü. 5. IJavaElement və JavaElementInfo
Java modeli resurs modeli ilə müqayisədə əsas tutacaq/gövdə dizaynının həyata keçirilməsində bəzi fərqlərə malikdir. Yuxarıda qeyd edildiyi kimi, resurs modelində qovşaqları resurs məlumat obyektləri olan element ağacı tamamilə yaddaşda saxlanılır. Lakin Java modeli resurs ağacından əhəmiyyətli dərəcədə daha çox elementə malik ola bilər, çünki o, həm də .java və .class fayllarının daxili strukturunu təmsil edir: növlər, sahələr və metodlar.
Yaddaşdakı bütün elementlər ağacını tamamilə həyata keçirməmək üçün Java modelinin tətbiqi element məlumatının məhdud ölçülü LRU keşindən istifadə edir, burada açar IJavaElement idarə edir. element info obyektləri element ağacı naviqasiya edildiyi üçün tələb əsasında yaradılır. Bu halda, ən az istifadə olunan elementlər keşdən çıxarılır və modelin yaddaş istehlakı müəyyən edilmiş keş ölçüsü ilə məhdudlaşır. Bu, belə icra detallarını müştəri kodundan tamamilə gizlədən tutacaq əsaslı dizaynın başqa bir üstünlüyüdür.
Java elementlərində dəyişikliklərin bildirilməsi mexanizmi ümumilikdə yuxarıda müzakirə olunan iş sahəsi resurslarında dəyişiklikləri izləmək mexanizminə bənzəyir. Java modelindəki dəyişiklikləri izləmək istəyən müştəri, IJavaElementDelta ehtiva edən ElementChangedEvent obyekti kimi təqdim olunan bildirişlərə abunə olur (Şəkil 6).
düyü. 6. ElementChangedEvent və IJavaElementDelta
Java modelində metod orqanları və ya adın həlli haqqında məlumat yoxdur, buna görə də Java-da yazılmış kodun ətraflı təhlili üçün JDT Core əlavə (qeyri-rəsmi əsaslı) model təqdim edir: (mücərrəd sintaksis ağacı, AST). AST mənbə mətnin təhlilinin nəticəsini təmsil edir. AST qovşaqları mənbə modulunun struktur elementlərinə (bəyannamələr, operatorlar, ifadələr və s.) uyğun gəlir və mənbə mətnindəki müvafiq elementin koordinatları haqqında məlumatları, həmçinin (seçim kimi) mətndə ad həlli haqqında məlumatları ehtiva edir. sözdə bağlantılar forması bindings. Bağlamalar tərtibçiyə məlum olan tiplər, üsullar və dəyişənlər kimi adlandırılmış obyektləri təmsil edən obyektlərdir. Bir ağac meydana gətirən AST qovşaqlarından fərqli olaraq, bağlamalar çarpaz istinadları dəstəkləyir və ümumiyyətlə bir qrafik təşkil edir. ASTNode mücərrəd sinfi bütün AST qovşaqları üçün ümumi əsas sinifdir. ASTNode alt sinifləri Java dilinin xüsusi sintaktik konstruksiyalarına uyğundur.
Sintaksis ağacları əhəmiyyətli miqdarda yaddaş istehlak edə bildiyinə görə, JDT aktiv redaktor üçün yalnız bir AST yaddaşını saxlayır. Java modelindən fərqli olaraq, AST adətən “aralıq”, “müvəqqəti” model kimi nəzərdən keçirilir, onun üzvləri AST-nin yaradılmasına səbəb olan əməliyyat kontekstindən kənarda müştərilər tərəfindən istinad edilməməlidir.
Sadalanan üç model (Java modeli, AST, bağlayıcılar) birlikdə JDT-də "ağıllı inkişaf alətləri" yaratmaq üçün əsas təşkil edir, o cümlədən müxtəlif "köməkçiləri" olan güclü Java redaktoru, mənbə kodunun işlənməsi üçün müxtəlif tədbirlər (idxal siyahısının təşkili daxil olmaqla). adlar və fərdiləşdirilmiş üsluba uyğun formatlaşdırma), axtarış və refaktorinq alətləri. Bu halda Java modeli xüsusi rol oynayır, çünki məhz inkişaf etdirilən proqramın strukturunun vizual təsviri üçün əsas kimi istifadə olunur (məsələn, Package Explorer, Outline, Search, Call Hierarchy və Tip iyerarxiyası).
1C: Enterprise Development Tools proqramında istifadə olunan Eclipse komponentləri
Şəkildə. Şəkil 7-də 1C: Enterprise Development Tools üçün texnoloji platformanın əsasını təşkil edən Eclipse komponentləri göstərilir.
düyü. 7. Eclipse 1C: Enterprise Development Tools üçün platforma kimi
Eclipse Platforması əsas infrastrukturu təmin edir. Biz əvvəlki bölmədə bu infrastrukturun bəzi aspektlərinə baxdıq.
(EMF) strukturlaşdırılmış verilənlərin modelləşdirilməsinin ümumi vasitələrini təqdim edir. EMF Eclipse Platforması ilə inteqrasiya olunub, lakin adi Java proqramlarında ayrıca istifadə oluna bilər. Çox vaxt yeni Eclipse tərtibatçıları Eclipse Platformasının incəliklərini hələ tam dərk etməsələr də, EMF ilə artıq yaxşı tanış olurlar. Bu cür layiqli populyarlığın səbəblərindən biri universal dizayndır ki, bu da digər şeylərlə yanaşı, hər hansı bir EMF modeli ilə ümumi şəkildə işləməyə imkan verən vahid meta səviyyəli API-ni ehtiva edir. EMF tərəfindən təmin edilən model obyektləri üçün əsas tətbiqlər və meta-model əsasında model kodu yaratmaq üçün alt sistem inkişaf sürətini əhəmiyyətli dərəcədə artırır və səhvlərin sayını azaldır. EMF həmçinin modelləri seriallaşdırmaq, modeldə dəyişiklikləri izləmək və daha çox şey üçün mexanizmləri ehtiva edir.
Hər hansı bir həqiqi ümumi təyinatlı alət kimi, EMF geniş çeşidli modelləşdirmə problemlərinin həlli üçün uyğundur, lakin bəzi model sinifləri (məsələn, yuxarıda müzakirə olunan tutacaq əsaslı modellər) daha ixtisaslaşmış modelləşdirmə vasitələri tələb edə bilər. EMF haqqında danışmaq, xüsusən də bir məqalənin məhdud sərhədləri daxilində nankor bir işdir, çünki bu ayrıca bir kitabın mövzusudur və kifayət qədər qalındır. Yalnız qeyd edək ki, EMF-nin əsasını təşkil edən yüksək keyfiyyətli ümumiləşdirmə sistemi yüksək səviyyəli layihəyə daxil olan modelləşdirməyə həsr olunmuş bütün layihələrin yaranmasına imkan verdi. EMF özü ilə birlikdə. Belə layihələrdən biri Eclipse Xtext-dir.
"mətn modelləşdirmə" infrastrukturunu təmin edir. Xtext istifadə edir mənbə mətni və nəticədə ASG-ni (əslində AST və bağlamaların birləşməsindən ibarət abstrakt semantik qrafik) təmsil etmək üçün EMF-ni təhlil etmək üçün, həmçinin “semantik model” adlanır. Xtext ilə modelləşdirilmiş dilin qrammatikası Xtext-in öz dilində təsvir edilmişdir. Bu, sizə təkcə ANTLR üçün qrammatik təsvir yaratmağa deyil, həm də AST serializasiya mexanizmini (yəni Xtext həm təhlilçi, həm də təhlilçini təmin edir), kontekst işarəsi və bir sıra digər dil komponentlərini əldə etməyə imkan verir. Digər tərəfdən, Xtext-də istifadə olunan qrammatik dil, məsələn, ANTLR-də istifadə olunan qrammatik dildən daha az çevikdir. Buna görə bəzən tətbiq olunan dili Xtext-ə "əymək" lazımdır, bu, sıfırdan inkişaf etdirilən bir dildən danışırıqsa, ümumiyyətlə problem deyil, lakin artıq qurulmuş sintaksisi olan dillər üçün qəbuledilməz ola bilər. Buna baxmayaraq, Xtext hazırda proqramlaşdırma dilləri və onlar üçün inkişaf alətləri yaratmaq üçün Eclipse-də ən yetkin, xüsusiyyətlərlə zəngin və çox yönlü vasitədir. Xüsusilə, sürətli prototipləmə üçün ideal vasitədir (domen üçün xüsusi dil, DSL). ANTLR və EMF-yə əsaslanan yuxarıda qeyd olunan “dil nüvəsinə” əlavə olaraq, Xtext indeksləşdirmə mexanizmləri, artımlı konstruksiya, “ağıllı redaktor” və daha çox şey daxil olmaqla bir çox faydalı yüksək səviyyəli komponentlər təqdim edir, lakin idarəediciləri kənarda qoyur. əsaslanan dil modelləri. EMF kimi, Xtext də ayrıca kitaba layiq bir mövzudur və hazırda onun bütün imkanları haqqında qısaca danışmaq belə çətindir.
1C: Müəssisə İnkişafı Alətləri həm EMF-nin özündən, həm də bir sıra digər Eclipse Modeling layihələrindən fəal şəkildə istifadə edir. Xüsusilə, Xtext daxili proqramlaşdırma dili və sorğu dili kimi 1C: Enterprise dilləri üçün inkişaf vasitələrinin əsaslarından biridir. Bu inkişaf alətləri üçün başqa bir əsas daha ətraflı müzakirə edəcəyimiz Eclipse Handly layihəsidir (sadalanan Eclipse komponentlərindən hələ də ən az tanınır).
, Eclipse Technology yüksək səviyyəli layihəsinin alt layihəsi, 1-cü ildə 2014C tərəfindən Eclipse Fonduna ilkin kod töhfəsi nəticəsində ortaya çıxdı. O vaxtdan bəri, 1C layihənin inkişafına dəstək verməyə davam etdi: Əl işi icra edənlər şirkətin işçiləridir. Layihə kiçikdir, lakin Eclipse-də kifayət qədər unikal yer tutur: onun əsas məqsədi tutacaq əsaslı modellərin inkişafına dəstək verməkdir.
Dəstək/bədən deyimi kimi tutacaq əsaslı modellərin əsas memarlıq prinsipləri yuxarıda resurs modeli və Java modelindən nümunə kimi istifadə edilərək müzakirə edilmişdir. O, həmçinin qeyd etdi ki, həm resurs modeli, həm də Java modeli Eclipse Java inkişaf alətləri (JDT) üçün mühüm təməllərdir. Demək olar ki, bütün *DT Eclipse layihələri JDT-ə bənzər bir arxitekturaya malik olduğundan, tutacaq əsaslı modellərin Eclipse Platformasının üstündə qurulmuş bütün IDE-lərin olmasa da, bir çoxunun əsasını təşkil etdiyini söyləmək böyük şişirtmə olmaz. Məsələn, Eclipse C/C++ İnkişaf Alətləri (CDT), Java modelinin JDT-də oynadığı kimi CDT arxitekturasında eyni rolu oynayan sapa əsaslanan C/C++ modelinə malikdir.
Handly-dən əvvəl Eclipse sapa əsaslanan dil modelləri yaratmaq üçün xüsusi kitabxanalar təklif etmirdi. Hazırda mövcud olan modellər əsasən Java model kodunu birbaşa uyğunlaşdırmaqla yaradılmışdır (a.k.a. copy/paste), imkan verdiyi hallarda Eclipse Public License (EPL). (Aydındır ki, bu, adətən, məsələn, Eclipse layihələrinin özü üçün hüquqi problem deyil, lakin qapalı mənbəli məhsullar üçün deyil.) Bu texnika özünəməxsus təsadüfiliyinə əlavə olaraq, məlum problemləri təqdim edir: səhvlərə uyğunlaşarkən kodun təkrarlanması, və s. Ən pisi odur ki, ortaya çıxan modellər “özlüyündə şeylər” olaraq qalır və birləşmə potensialından istifadə etmirlər. Lakin tutacaq əsaslı dil modelləri üçün ümumi konsepsiyaların və protokolların təcrid edilməsi, EMF vəziyyətində baş verənlərə bənzər, onlarla işləmək üçün təkrar istifadə edilə bilən komponentlərin yaradılmasına səbəb ola bilər.
Eclipse bu məsələləri başa düşmədi. 2005-ci ildə CDT prototipinin yaradılması təcrübəsini ümumiləşdirərək, qulp əsaslı modellər də daxil olmaqla dil modelləri üçün ümumi infrastrukturun yaradılması ehtiyacı. Ancaq tez-tez olduğu kimi, daha yüksək prioritet vəzifələr səbəbindən bu ideyaların həyata keçirilməsi heç vaxt baş vermir. Bu arada *DT kodunun faktorizasiyası hələ də Eclipse-də inkişaf etməmiş mövzulardan biridir.
Müəyyən mənada Handly layihəsi EMF ilə təxminən eyni problemləri həll etmək üçün nəzərdə tutulmuşdur, lakin tutacaq əsaslı modellər və ilk növbədə dil modelləri (yəni, bəzi proqramlaşdırma dilinin struktur elementlərini təmsil edən) üçün. Handly dizaynı zamanı qarşıya qoyulan əsas məqsədlər aşağıda verilmişdir:
- Mövzu sahəsinin əsas abstraksiyalarının müəyyən edilməsi.
- Koddan təkrar istifadə yolu ilə qulp əsaslı dil modellərinin həyata keçirilməsinin keyfiyyətinin artırılması və səylərin azaldılması.
- Yaranan modellərə vahid meta-səviyyəli API təqdim edərək, dil idarəçiliyinə əsaslanan modellərlə işləyən ümumi IDE komponentləri yaratmağa imkan verir.
- Çeviklik və miqyaslılıq.
- Xtext ilə inteqrasiya (ayrı bir təbəqədə).
Ümumi konsepsiyaları və protokolları vurğulamaq üçün dil idarəsinə əsaslanan modellərin mövcud tətbiqləri təhlil edilmişdir. Handly tərəfindən təmin edilən əsas interfeyslər və əsas tətbiqlər Şek. 8.
düyü. 8. Ümumi interfeyslər və Handly elementlərinin əsas tətbiqləri
IElement interfeysi elementin sapını təmsil edir və bütün Handly əsaslı modellərin elementləri üçün ümumidir. Abstrakt sinif Element ümumiləşdirilmiş tutacaq/gövdə mexanizmini həyata keçirir (şək. 9).
düyü. 9. IElement və ümumi tutacaq/bədənin icrası
Bundan əlavə, Handly model elementlərindəki dəyişikliklər haqqında məlumat vermək üçün ümumiləşdirilmiş mexanizm təqdim edir (şək. 10). Gördüyünüz kimi, o, resurs modelində və Java modelində həyata keçirilən bildiriş mexanizmlərinə geniş şəkildə bənzəyir və element dəyişikliyi məlumatının vahid təqdimatını təmin etmək üçün IElementDelta-dan istifadə edir.
düyü. 10. Handly bildiriş mexanizminin ümumi interfeysləri və əsas tətbiqləri
Yuxarıda müzakirə edilən Handly hissəsi (şək. 9 və 10) demək olar ki, hər hansı tutacaq əsaslı modelləri təmsil etmək üçün istifadə edilə bilər. Yaratmaq üçün Dilçilik modellər üçün layihə əlavə funksionallıq təklif edir - xüsusən də ümumi interfeyslər və mənbə mətn strukturunun elementləri üçün əsas tətbiqlər, sözdə mənbə elementləri (şək. 8). ISourceFile interfeysi mənbə faylı, ISourceConstruct isə mənbə faylı daxilindəki elementi təmsil edir. SourceFile və SourceConstruct mücərrəd sinifləri mənbə faylları və onların elementləri ilə işləməyi dəstəkləmək üçün ümumiləşdirilmiş mexanizmləri həyata keçirir, məsələn, mətn buferləri ilə işləmək, mənbə mətndəki elementin koordinatlarına bağlamaq, modelləri işləyən surət buferinin cari məzmunu ilə tutuşdurmaq. və s. Bu mexanizmlərin həyata keçirilməsi adətən olduqca çətin olur və Handly yüksək keyfiyyətli əsas tətbiqetmələri təmin etməklə tutacaq əsaslı dil modellərinin hazırlanması səylərini əhəmiyyətli dərəcədə azalda bilər.
Yuxarıda sadalanan əsas mexanizmlərə əlavə olaraq, Handly mətn buferləri və snapshotlar üçün infrastruktur, mənbə kodu redaktorları ilə inteqrasiya dəstəyi (o cümlədən Xtext redaktoru ilə qutudan kənar inteqrasiya), eləcə də bəzi ümumi UI komponentlərini təmin edir. mənbə kodu redaktorları ilə işləmək, kontur çərçivəsi kimi əllə işləyən modellər. Onun imkanlarını göstərmək üçün layihə Handly-də Java modelinin tətbiqi də daxil olmaqla bir neçə nümunə təqdim edir. (Java modelinin JDT-də tam tətbiqi ilə müqayisədə, bu model daha aydınlıq üçün qəsdən bir qədər sadələşdirilmişdir.)
Daha əvvəl qeyd edildiyi kimi, Handly-nin ilkin dizaynı və sonrakı inkişafı zamanı əsas diqqət miqyaslılıq və çeviklik idi və olmaqda davam edir.
Prinsipcə, tutacaq əsaslı modellər "dizayn baxımından" kifayət qədər yaxşı ölçülür. Məsələn, tutacaq/bədən deyimi modelin istehlak etdiyi yaddaşın miqdarını məhdudlaşdırmağa imkan verir. Ancaq nüanslar da var. Beləliklə, Handly-ni miqyaslılıq üçün sınaqdan keçirərkən, bildiriş mexanizminin tətbiqində problem aşkar edildi - çox sayda element dəyişdirildikdə, deltaların qurulması çox vaxt apardı. Məlum oldu ki, eyni problem JDT Java modelində də mövcud olub, ondan bir vaxtlar müvafiq kod uyğunlaşdırılıb. Biz Handly-də səhvi düzəltdik və JDT üçün oxşar yamaq hazırladıq, bu, minnətdarlıqla qəbul edildi. Bu, mövcud model tətbiqlərinə Handly tətbiqinin potensial olaraq faydalı ola biləcəyi bir nümunədir, çünki bu halda belə bir səhv yalnız bir yerdə düzəldilə bilər.
Handly proqramını mövcud model tətbiqlərinə texniki cəhətdən mümkün etmək üçün kitabxana əhəmiyyətli çevikliyə malik olmalıdır. Əsas problem API modeli üzrə geriyə uyğunluğu qorumaqdır. Bu problem ildə həll edildi Tərtibatçı tərəfindən müəyyən edilmiş və tam nəzarət edilən modelə məxsus API-ni kitabxana tərəfindən təqdim edilən vahid meta səviyyəli API-dən aydın şəkildə ayırmaqla. Bu, Handly-ni mövcud tətbiqlərə tətbiq etməyi texniki cəhətdən mümkün edir, həm də yeni model tərtibatçısına API dizayn edərkən əhəmiyyətli sərbəstlik verir.
Çevikliyin başqa aspektləri də var. Məsələn, Handly modelin strukturuna demək olar ki, heç bir məhdudiyyət qoymur və həm ümumi təyinatlı, həm də domenə xas dilləri modelləşdirmək üçün istifadə edilə bilər. Mənbə faylının strukturunu qurarkən Handly AST təmsilinin hər hansı xüsusi formasını təyin etmir və prinsipcə, hətta AST-nin özünün olmasını tələb etmir, beləliklə, demək olar ki, hər hansı təhlil mexanizmi ilə uyğunluğu təmin edir. Nəhayət, Handly Eclipse iş sahəsi ilə tam inteqrasiyanı dəstəkləyir, eyni zamanda fayl sistemləri ilə inteqrasiyası sayəsində birbaşa işləyə bilər. (EFS).
Cari versiya 2016-cı ilin dekabrında çıxdı. Layihənin hazırda inkubasiya vəziyyətində olmasına və API-nin hələ nəhayət düzəldilməməsinə baxmayaraq, Handly artıq "erkən qəbul edənlər" kimi fəaliyyət göstərmək riskini daşıyan iki böyük kommersiya məhsulunda istifadə olunur və deməliyəm ki, hələ peşman olma.
Yuxarıda qeyd edildiyi kimi, bu məhsullardan biri 1C: Enterprise Development Tools-dur, burada Handly əvvəldən daxili proqramlaşdırma dili və sorğu dili kimi 1C: Enterprise dillərinin yüksək səviyyəli strukturunun elementlərini modelləşdirmək üçün istifadə olunur. . Başqa bir məhsul geniş ictimaiyyətə az məlumdur. Bu , həm Çexiya şirkəti Codasip-in özündə, həm də müştəriləri, o cümlədən, tətbiq üçün xüsusi təlimat dəsti prosessoru (ASIP) üçün inteqrasiya olunmuş dizayn mühiti , , , . Codasip Handly-dən Handly 2015 versiyasından başlayaraq 0.2-ci ildən istehsalda istifadə edir. Codasip Studio-nun ən son buraxılışı 0.5-cı ilin iyununda buraxılmış 2016 versiyasından istifadə edir. Codasip-də IDE inkişafına rəhbərlik edən Ondřej İlčík layihə ilə əlaqə saxlayır və "üçüncü tərəfi qəbul edən" adından həyati rəy təmin edir. O, hətta Handly nümunələrindən biri olan Java modeli üçün UI qatını (~4000 kod sətirləri) həyata keçirərək layihənin işlənib hazırlanmasında birbaşa iştirak etmək üçün bir az boş vaxt tapa bildi. Handly-nin övladlığa götürənlər tərəfindən istifadəsi haqqında daha ətraflı birinci əldən məlumatı səhifədə tapa bilərsiniz layihəsi.
Ümid edirik ki, API sabitliyi zəmanəti ilə 1.0 versiyasının buraxılmasından və layihənin inkubasiya vəziyyətindən çıxmasından sonra Handly-nin yeni qəbulediciləri olacaq. Bu vaxt, layihə API-ni sınaqdan keçirməyə və daha da təkmilləşdirməyə davam edir, ildə iki "əsas" buraxılış - iyunda (eyni zamanda Eclipse buraxılışı ilə eyni tarixdə) və dekabrda, qəbul edənlərin etibar edə biləcəyi proqnozlaşdırıla bilən cədvəl təqdim edir. Onu da əlavə edə bilərik ki, layihənin “səhv nisbəti” davamlı olaraq aşağı səviyyədə qalır və Handly ilk versiyalardan bəri erkən tətbiq edənlərin məhsullarında etibarlı şəkildə işləyir. Eclipse Handly-i daha çox araşdırmaq üçün istifadə edə bilərsiniz и .
Mənbə: www.habr.com