Droši vien, ilgāku laiku vairs nav nepieciešama īpaša prezentācija. Daudzi pazīst Eclipse pateicoties Eclipse Java izstrādes rīkiem (). Šī populārā open-source Java IDE vairumam izstrādātāju asociējas ar vārdu “Eclipse”. Tomēr Eclipse ir arī paplašināma platforma izstrādes rīku integrācijai (Eclipse Platform) un vesels IDE kopums, kas balstīts uz tās bāzes, tostarp JDT. Eclipse ir arī Eclipse projekts, augsta līmeņa projekts, kas koordinē Eclipse Platform un JDT izstrādi, un Eclipse SDK – šīs attīstības rezultāts. Visbeidzot, Eclipse ir open-source fonds ar milzīgu projektu kopienu, no kuriem tālu ne visi ir rakstīti Java vai ir saistīti ar izstrādes rīkiem (piemēram, projekti un ). Eclipse pasaule ir ļoti daudzveidīga.
Šajā rakstā, kas ir pārskata rakstura, mēģināsim apskatīt dažus arhitektūras pamatus, kas padara Eclipse par platformu integrētu izstrādes rīku izveidei, un sniegt sākotnēju priekšstatu par Eclipse komponentēm, kas veido tehnoloģiskās platformas pamatu “jaunajam Konfiguratoram” 1C: Uzņēmumam, . Protams, šāda apskate būs lielā mērā virspusēja un diezgan ierobežota, jo orientējamies ne tikai uz Eclipse izstrādātājiem kā mērķauditoriju. Tomēr ceram, ka pat pieredzējuši Eclipse izstrādātāji varēs atrast rakstā interesantu informāciju. Piemēram, mēs pastāstīsim par vienu no “Eclipse noslēpumiem”, salīdzinoši jauno un maz zināmo projektu , kuru dibinājusi un atbalsta firma 1C.
Ievads Eclipse arhitektūrā
Apskatīsim vispirms dažus vispārīgus aspektus par Eclipse arhitektūru, ņemot piemēru no (JDT). Tieši JDT izvēle kā piemērs nav nejauša. Tā ir pirmā integrētā izstrādes vide, kas parādījās Eclipse. Pārējie *DT Eclipse projekti, piemēram, Eclipse C/C++ izstrādes rīki (CDT), tika izveidoti vēlāk un aizguva gan galvenos arhitektūras principus, gan atsevišķus avota koda fragmentus no JDT. Arhitektūras pamati, kas ieviesti JDT, ir aktuāli joprojām praktiski ikvienai IDE, kas uzbūvēta uz Eclipse Platform, tostarp 1C:Enterprise Development Tools.
Pirmkārt, jāpiezīmē, ka Eclipse ir raksturīga skaidra arhitektūras dalīšana, nod separating valodu neatkarīgo funkcionalitāti no funkcionalitātes, kas domāta konkrētu programmēšanas valodu atbalstam, kā arī UI neatkarīgo "kodolu" (core) komponentu no komponentēm, kas saistītas ar lietotāja interfeisa atbalstu.
Tātad, Eclipse Platform nosaka kopējo, valodu neatkarīgu infrastruktūru, bet Java attīstības rīki pievieno Eclipse pilnfunkcionālu Java IDE. Gan Eclipse Platform, gan JDT sastāv no vairākiem komponentiem, no kuriem katrs pieder vai nu pie UI neatkarīgā "kodola", vai pie UI slāņa (skat. 1. att.).
1. att. Eclipse Platform un JDT
Uzskaitīsim galvenos komponentus Eclipse Platform:
- Runtime — Nosaka spraudņu infrastruktūru. Eclipse ir raksturīga modulāra arhitektūra. Faktiski Eclipse ir kolekcija "paplašinājumu punktu" un "paplašinājumiem".
- Workspace — Pārvalda vienu vai vairākus projektus. Projekts sastāv no mapēm un failiem, kas tieši tiek attēloti uz failu sistēmu.
- Standard Widget Toolkit (SWT) — Nodrošina pamatelementus lietotāja interfeisam, integrētus ar operētājsistēmu.
- JFace — Nodrošina virkni UI ietvaru, kas būvēti uz SWT.
- Darba galds — Nosaka Eclipse UI paradigmu: redaktori, skatījumi, perspektīvas.
Jāatzīmē, ka Eclipse Platform nodrošina arī daudzas citas noderīgas komponentes integrētu izstrādes rīku izveidei, starp kurām var minēt Debug, Compare, Search un Team. Atsevišķi jāpiemin JFace Text – pamats "gudro kodēšanas redaktoru" veidošanai. Diemžēl, pat virspusēja šo komponentu, līdzīgi kā UI slāņa komponentu, apskate šī raksta ietvaros nav iespējama, tādēļ atlikušo šī sadaļas daļu mēs ierobežosim ar galveno "kodolu" komponentu apskatu par Eclipse Platform un JDT.
Core Runtime
Eclipse spraudņu infrastruktūra ir balstīta uz un to nodrošina projekts . Katrs Eclipse spraudnis ir OSGi bundls. OSGi specifikācija nosaka, tostarp, versiju pārvaldības un atkarību risināšanas mehānismus. Papildus šiem standartmehānismiem, Equinox ievieš jēdzienu paplašinājumu punkti. Katrā spraudņā var būt savas paplašināšanas vietas, kā arī tas var pievienot sistēmai papildu funkcionalitāti ("paplašinājumi"), izmantojot paplašināšanas vietas, kuras definējusi šis vai citi spraudņi. Detalizēts OSGi un Equinox mehānismu apraksts nepārsniedz šī raksta ietvarus. Vērts atzīmēt, ka modularizācija Eclipse ir visaptveroša (jebkura apakšsistēma, tostarp Runtime, sastāv no viena vai vairākiem spraudņiem), un praktiski viss Eclipse ir paplašinājums. Turklāt šie principi tika iekļauti Eclipse arhitektūrā jau sen pirms OSGi ieviešanas (tajā laikā tika izmantota īpaša tehnoloģija, kas lielā mērā līdzīga OSGi).
Pamatdarba vide
Praktiski jebkura integrētā izstrādes vide, kas veidota uz Eclipse platformas, darbojas ar Eclipse darba vidi. Tieši darba vide parasti satur izstrādājamā IDE lietojumprogrammas avota kodu. Darba vide tieši atspoguļo failu sistēmu un sastāv no projektiem, kuri ietver mapes un failus. Šie projekti, mapes un faili tiek saukti par resursiem darba vidi. Darba vides realizācija Eclipse kalpo kā kešatmiņa attiecībā pret failu sistēmu, kas būtiski paātrina resursu koka pārgājienu. Turklāt darba vide nodrošina virkni papildu servisu, tostarp un .
Par darba vides un tās resursu atbalstu atbild Core Resources komponente (spraudnis org.eclipse.core.resources). Īpaši, šī komponente nodrošina programmētāju piekļuvi darba videi kā resursu modelim. Lai efektīvi strādātu ar šo modeli, klientiem nepieciešams vienkāršs veids, kā attēlot saiti uz resursu. Šajā gadījumā objekts, kas tieši saglabā resursa stāvokli modelī, vēlams, lai tiktu paslēpts no klientu piekļuves. Citādi, piemēram, faila dzēšanas gadījumā klients varētu turpināt darboties ar objektu, kas vairs nav modelī, radot tādējādi problēmas. Eclipse šo uzdevumu risina, izmantojot tā saukto handle resursam. Handle darbojas kā atslēga (tas zina tikai ceļu uz resursu darba vidē) un pilnībā kontrolē piekļuvi iekšējam modeļa objektam, kurš tieši saglabā informāciju par resursa stāvokli. Šis dizains ir variācija uz patter .
Attēls 2 ilustrē idiomu Handle/Body attiecībā uz resursu modeli. Interfeiss IResource pārstāv resursa handle un ir API, atšķirībā no klases Resource, kas īsteno šo interfeisu, kā arī klases ResourceInfo, kas pārstāv body, kuru API nav. Uzsveram, ka handle zina tikai ceļu uz resursu attiecībā pret workspace sakni un nesatur atsauci uz resource info. Objekti resource info veido tā saukto "elementu koku" (element tree). Šī datu struktūra ir pilnībā materializēta atmiņā. Lai atrastu resource info instance, kas atbilst kādam handle, element tree tiek apstrādāts atbilstoši ceļam, kas šajā handle ir saglabāts.
Attēls 2. IResource un ResourceInfo
Kā mēs vēlāk redzēsim, pamata resursu modeļa dizains (to var nosaukt par handle-based) tiek izmantots Eclipse un citos modeļos. Bet pagaidām uzskaitīsim dažas šī dizaina atšķirīgās īpašības:
- Handle ir vērtības objekts (value object). Vērtības objekti ir nemainīgi (immutable) objekti, kuru vienādību nenosaka identitāte. Šādus objektus var droši izmantot kā atslēgu hash kontaineros. Daudzi handle instances var atsaukties uz to pašu resursu. To salīdzināšanai jāizmanto metode equals(Object).
- Handle nosaka resursa uzvedību, bet nesatur informāciju par resursa stāvokli (vienīgie dati, kurus tas uzglabā, ir "atslēga", ceļš uz resursu).
- Handle var atsaukties uz neesošu resursu (vai nu resursu, kas vēl nav izveidots, vai resursu, kas jau ir izdzēsts). Resursa esamību var pārbaudīt, izmantojot metodi IResource.exists().
- Dažas darbības var tikt īstenotas, pamatojoties tikai uz informāciju, kas glabājas pašā handle (tā saucamās handle-only darbības). Piemēri ir IResource.getParent(), getFullPath() utt. Resursam nav obligāti jāpastāv, lai veiksmīgi izpildītu šādu darbību. Darbības, lai veiksmīgi izpildītu kurām nepieciešams, lai resurss pastāvētu, izmest CoreException, ja resurss neeksistē.
Eclipse nodrošina efektīvu paziņošanas mehānismu par workspace resursu izmaiņām (skat. 3. attēlu). Resursi var mainīties gan, veicot darbības pašā Eclipse IDE, gan arī sinhronizējot ar failu sistēmu. Abos gadījumos, klientiem, kas ir parakstījušies uz paziņojumiem, tiek sniegta detalizēta informācija par izmaiņām, kas tiek attēlota kā 'resursu delta' (resource delta). Delta apraksta izmaiņas starp diviem stāvokļiem (apakš)koku resursu darbvietā un pati ir koks, katrs mezgls kurā apraksta konkrētu resursu izmaiņas un ietver nākamā līmeņa deltas sarakstu, kas apraksta apakšresursu izmaiņas.
3. attēls. IResourceChangeEvent un IResourceDelta
Paziņošanas mehānismam, kas balstīts uz resursu deltām, ir šādas īpašības:
- Viensakārša izmaiņa un vairāku izmaiņu aprakstīšana notiek, izmantojot to pašu struktūru, jo delta tiek veidota, izmantojot rekurvīvo kompozīciju. Klienti-abonenti var apstrādāt resursu izmaiņu paziņojumus, veicot rekurzīvu nolaišanos pa deltas koku.
- Delta satur pilnīgu informāciju par resursa izmaiņām, tostarp tā pārvietošanu un/vai saistīto 'marķieru' (kā marķieros var tikt attēlotas, piemēram, kompilācijas kļūdas) izmaiņas.
- Tā kā saites uz resursu tiek veiktas, izmantojot handle, delta var dabiski atsaukties uz attālo resursu.
Kā mēs drīzumā redzēsim, galvenie paziņošanas mehānisma izmaiņu dizaina elementi ir spēkā arī citu handle-bazētu modeļu gadījumā.
JDT Core
Eclipse workspace resursu modelis ir pamata valodas neatkarīgs modelis. JDT Core komponents (pirmais plug-in org.eclipse.jdt.core) nodrošina API workspace struktūras navigācijai un analīzei Java skatījumā, tā saukto 'Java modeli' (Java model). Šis API ir definēts Java elementu terminos, atšķirībā no apakšējā resursu modeļa API, kas ir definēts mapju un failu terminos. Galvenie Java elementu koka interfeysi ir attēloti 4. attēlā.
4. attēls. Java modeļa elementi
Java model izmanto to pašu idiomu handle/body kā resursu modele (5. attēls). IJavaElement ir handle, bet JavaElementInfo spēlē body lomu. IJavaElement saskarne nosaka protokolu, kas ir kopīgs visiem Java elementiem. Daži no tās metodēm ir tikai handle: getElementName(), getParent() u.c. Objekts JavaElementInfo glabā attiecīgā elementa stāvokli: tā struktūru un atribūtus.
Att. 5. IJavaElement un JavaElementInfo
Java modelē ir dažas atšķirības no handle/body pamatdizaina īstenojumā salīdzinājumā ar resursu modeli. Kā minēts iepriekš, resursu modelī element tree, kuras mezgli ir objekti resource info, pilnībā tiek turēti atmiņā. Taču Java modelī var būt ievērojami vairāk elementu nekā resursu kokā, jo tajā ir iekļauta arī .java un .class failu iekšējā struktūra: tipi, lauki un metodes.
Lai izvairītos no visa elementu koka pilnīgas materializācijas atmiņā, Java modeļa īstenojums izmanto ierobežota izmēra LRU kešatmiņu element info, kurā atslēga ir IJavaElement handle. Element info objekti tiek radīti pēc pieprasījuma, kad notiek navigācija pa elementu koku. Šajā procesā visretāk izmantotie elementi tiek izsisti no kešatmiņas, un modeļa atmiņas patēriņš paliek ierobežots ar noteikto kešatmiņas lielumu. Tas ir vēl viens handle-based dizaina priekšrocība, kas pilnībā noslēpj šādas īstenošanas detaļas no klienta koda.
Java elementu izmaiņu paziņošanas mehānisms vispārīgi ir līdzīgs iepriekš apskatītajam workspace resursu izmaiņu izsekošanas mehānismam. Klients, kurš vēlas izsekot izmaiņām Java modelī, reģistrējas paziņojumiem, kas tiek pasniegti kā objekts ElementChangedEvent, kurā ir IJavaElementDelta (6. attēls).
Att. 6. ElementChangedEvent un IJavaElementDelta
Java modelī nav informācijas par metožu ķermeņiem vai nosaukumu risināšanu, tādēļ detalizētai Java kodu analīzei JDT Core piedāvā papildu (ne handle-based) modeli: (abstraktā sintaktiskā koka, AST). AST atspoguļo avota teksta sintaktiskās analīzes rezultātu. AST mezgli atbilst modulis struktūras elementiem (deklārācijām, operatoriem, izteiksmēm utt.) un satur informāciju par attiecīgā elementa koordinātēm avota tekstā, kā arī (pēc izvēles) informāciju par nosaukumu izšķiršanu, izmantojot tā sauktās bindings. Saistījumi ir objekti, kas attēlo nosauktās entitātes, piemēram, tipus, metodēs un mainīgos, kurus zinām kompīlatoram. Atšķirībā no AST mezgliem, kas veido koku, saistījumi atbalsta krusteniskās atsauces un kopumā veido grafiku. Abstraktais klase ASTNode ir kopējā bāzes klase visiem AST mezgliem. ASTNode apakšklases atbilst konkrētām Java valodas sintaktiskajām konstrukcijām.
Ņemot vērā, ka sintaktiskie koki var patērēt ievērojamu atmiņas daudzumu, JDT kešatmiņā saglabā tikai vienu AST, aktīvajam redaktoram. Atšķirībā no Java modeļa, AST parasti tiek uzskatīts par "starpposmu", "pagaidu" modeli, uz tā elementiem klientiem nevajadzētu saglabāt atsauces ārpus operācijas konteksta, kas noveda pie AST izveides.
Iekļautās trīs modeļi (Java modelis, AST, saistījumi) kopā ir pamats „inteliģento izstrādes rīku” izveidei JDT, starp kuriem ir jaudīgs Java redaktors ar dažādiem „palīgiem”, dažādām avota koda apstrādes darbībām ( tostarp nosaukumu importa saraksta organizēšana un formatēšana, ievērojot pielāgotos stilus), meklēšanas un refaktorizēšanas rīki. Šajā gadījumā Java modelim ir īpaša loma, jo tieši tas tiek izmantots kā pamats vizuālās attēlošanai izstrādājamo lietojumprogrammu struktūrai (piemēram, Package Explorer, Outline, Search, Call Hierarchy un Type Hierarchy).
Eclipse komponenti, kas tiek izmantoti 1C:Enterprise Development Tools
Att. 7 parādīti Eclipse komponenti, kas veido tehnoloģiskās platformas pamatu 1C:Enterprise Development Tools.
Att. 7. Eclipse kā platforma 1C:Enterprise Development Tools
Eclipse Platforma nodrošina pamata infrastruktūru. Mēs apskatījām dažus šīs infrastruktūras aspektus iepriekšējā nodaļā.
(EMF) nodrošina vispārīgus struktūru datu modelēšanas rīkus. EMF ir integrēts ar Eclipse platformu, bet to var izmantot arī atsevišķi, parastās Java lietojumprogrammās. Bieži vien jauni Eclipse izstrādātāji jau labi pārzina EMF, lai gan vēl nesaprot Eclipse platformas nianses. Viens no tā atzinības iemesliem ir universālais dizains, kas ietver arī vispārinātu meta-līmeņa API, kas ļauj vispārināti strādāt ar jebkuru EMF modeli. EMF nodrošinātās pamata implementācijas modeļa objektiem un modeļa koda ģenerēšanas apakšsistēma, pamatojoties uz meta–modeļiem, ievērojami palielina izstrādes ātrumu un samazina kļūdu skaitu. EMF arī ietver modeļu serializācijas mehānismus, izmaiņu izsekošanu modelī un daudz ko citu.
Kā jebkuram patiesi universālam rīkam, EMF ir piemērots plaša spektra uzdevumiem, kas saistīti ar modelēšanu, taču dažiem modeļu veidiem (piemēram, iepriekšminētajiem handle-based modeļiem) var būt nepieciešami specializētāki modeļu modelēšanas rīki. Stāstot par EMF, ir pateicīgs darbs, īpaši viena raksta ierobežoto ietvaru dēļ, jo tas ir ne tikai atsevišķas grāmatas tēma, bet arī gana bieza. Atzīmēsim tikai to, ka kvalitatīva vispārinājumu sistēma, kas pamatota EMF, ir ļāvusi radīt veselu projektu spektru, kas veltīts modelēšanai un kas ietilpst augstākā līmeņa projektā. kopā ar pašu EMF. Viens no šādiem projektiem ir Eclipse Xtext.
nodrošina "teksta modelēšanas" infrastruktūru. Xtext izmanto līzēšanai sākotnējā teksta sintaksei un EMF, lai attēlotu rezultātā iegūto ASG (abstract semantic graph, kas būtībā ir AST un bindings kombinācija), ko dēvē arī par "semantisko modeli". Xtext modelējamā valoda tiek aprakstīta tās pašas Xtext valodas relācijā. Tas ne tikai ļauj ģenerēt gramatikas aprakstu ANTLR, bet arī iegūt AST serializācijas mehānismu (t.i., Xtext nodrošina gan parser, gan unparser), konteksta ieteikumus un virkni citu valodas komponentu. No otras puses, gramatikas apraksta valoda, kas tiek izmantota Xtext, ir mazāk elastīga salīdzinājumā, teiksim, ar gramatikas apraksta valodu ANTLR. Tāpēc dažreiz ir jā"pielāgo" Xtext īstenotajai valodai, kas parasti nav problēma, ja runājam par valodu, kas tiek izstrādāta no nulles, taču var būt nepieņemama jau izveidotām valodām ar sarežģītu sintaksi. Neskatoties uz to, Xtext pašlaik ir visattīstītākais, funkcionāli pilnīgākais un universālākais rīks Eclipse, lai izveidotu programmēšanas valodas un izstrādes rīkus tām. Īpaši tas ir ideāls rīks ātrai prototipa izstrādei. (domain-specific language, DSL). Bez iepriekš minētā "valodas kodola", kas balstīts uz ANTLR un EMF, Xtext piedāvā daudz noderīgu augstāka līmeņa komponentu, tostarp indeksēšanas mehānismus, inkrementālu izveidi, "gudru redaktoru" un daudz ko citu, bet atstāj novārtā valodas handle-based modeļa izstrādi. Tāpat kā EMF, Xtext ir temats, kas pelnījis atsevišķas grāmatas uzmanību, un mēs, visticamāk, nepietiks laika, lai pat virspusēji aplūkotu visas tā iespējas.
1C:Enterprise Development Tools aktīvi izmanto gan EMF pašu par sevi, gan virkni citu Eclipse Modeling projektu. Īpaši Xtext ir viens no rīku pamatiem tādām valodām 1C:Uzņēmums kā iebūvētā programmēšanas valoda un vaicājumu valoda. Cits šo izstrādes rīku pamats ir projekts Eclipse Handly, par kuru mēs vairāk detalizēti runāsim (no iepriekš minētajiem komponentiem Eclipse tas šobrīd ir vismazāk pazīstams).
, augstāka līmeņa projekta Eclipse Technology apakšprojekts radās, pateicoties sākotnējai koda ieguldījuma Eclipse Foundation no uzņēmuma 1C 2014. gadā. Kopš tā laika uzņēmums 1C turpina atbalstīt projekta attīstību: Handly komitēri ir uzņēmuma darbinieki. Projekts ir neliels, taču aizņem pietiekami unikālu nišu Eclipse: tā galvenais mērķis ir atbalstīt handle-bāzētu modeļu izstrādi.
Galvenie arhitektūras principi handle-bāzētām modeļiem, piemēram, handle/body idioma, tika apspriesti iepriekš, izmantojot resursu modeli un Java modeli kā piemērus. Tur tika atzīmēts, ka gan resursu modelis, gan Java modelis ir svarīgi pamati Eclipse Java izstrādes rīkiem (JDT). Tā kā praktiski visi *DT Eclipse projekti ir arhitektūras ziņā līdzīgi JDT, nebūs pārspīlēti teikt, ka handle-bāzētie modeļi ir daļa no daudziem, ja ne visiem IDE, kas balstās uz Eclipse platformu. Piemēram, Eclipse C/C++ izstrādes rīkos (CDT) ir handle-bāzēts C/C++ modelis, kas spēlē tādu pašu lomu architektūrā kā Java modelis JDT.
Pirms Handly parādīšanās, Eclipse nepiedāvāja specializētas bibliotēkas valodu handle-bāzētu modeļu izstrādei. Esošie modeļi tika radīti galvenokārt, tieši pielāgojot Java modeļa kodu (t.i., copy/paste), gadījumos, kad tas ir atļauts Eclipse Public License (EPL). (Saprotams, ka, teiksim, projektiem pašā Eclipse tas parasti nav juridiska problēma, ko nevar teikt par produktiem ar slēgtu avotu.) Bez tam, šai metodikai ir raksturīga nesakārtotība, kas rada labi zināmas problēmas: koda dublēšanu, pielāgošanas rezultātā radušās kļūdas utt. Vēl sliktāk, rezultātā radušies modeļi paliek „lieta paši par sevi” un neizmanto pieejamo potenciālu unifikācijas izveidei. Taču kopīgu jēdzienu un protokolu izdalīšana valodu handle-bāzētajiem modeļiem varētu novest pie atkārtoti izmantojamu komponentu izveides, līdzīgi kā tas notika EMF gadījumā.
Nav iespējams teikt, ka Eclipse šīs problēmas neapzinājās. Vēl 2005. gadā , apkopojot CDT prototipa izstrādes pieredzi, kopējās infrastruktūras izveides nepieciešamība valodu modeļiem, tostarp modeļiem, kas balstīti uz handle. Tomēr, kā tas bieži notiek, prioritāru uzdevumu dēļ šīs idejas līdz realizācijai tā arī netika īstenotas. Starp citu, koda faktorizācija *DT projektiem joprojām paliek viena no nepietiekami izstrādātām tēmām Eclipse.
Noteiktā nozīmē projekts Handly paredzēts risināt līdzīgas problēmas kā EMF, bet modeļiem, kas balstīti uz handle, un vispirms valodu modeliem (t.i., kas attēlo programmēšanas valodas struktūras elementus). Zemāk norādīti galvenie mērķi, kas tika izvirzīti projektējot Handly:
- Pamata abstrakciju izdalīšana priekšmetu jomā.
- Centienu samazināšana un valodu handle-based modeļu realizācijas kvalitātes paaugstināšana, izmantojot koda atkārtotu izmantošanu.
- Vienota API metalīme, kas paredzēta rezultējošajiem modeļiem, padarot iespējamu kopēju IDE komponentu izveidi, kas strādā ar valodu handle-based modeļiem.
- Elastība un mērogojamība.
- Integrācija ar Xtext (atsevišķā slānī).
Lai identificētu kopīgus jēdzienus un protokolus, tika analizētas esošās valodu handle-based modeļu realizācijas. Galvenie interfeisi un pamata realizācijas, ko nodrošina Handly, tiek parādīti attēlā 8.
Att. 8. Kopīgie interfeisi un pamata realizācijas Handly elementiem
Interfeiss IElement attēlo elementa handle un ir kopīgs visām Handly balstītajām modeļu elementiem. Abstraktais klases Element realizē ģenerizētu handle/body mehānismu (att. 9).
Att. 9. IElement un ģenerizētā handle/body realizācija
Turklāt Handly nodrošina ģenerizētu mehānismu par modeļa elementu izmaiņām (att. 10). Kā redzams, tas būtībā ir līdzīgs resursu modeļu un Java modeļu realizētajiem notifikācijas mehānismiem un izmanto IElementDelta, lai vienotā veidā attēlotu informāciju par elementa izmaiņu.
Att. 10. Kopīgie interfeisi un pamata realizācijas Handly notifikācijas mehānismam
Iepriekš apskatītā Handly daļa (att. 9 un 10) var tikt izmantota praktiski jebkuru handle-based modeļu attēlošanai. Lai izveidotu valodu modeļus projekts piedāvā papildu funkcionalitāti – proti, kopīgus interfeisus un pamata realizācijas struktūras elementiem avota tekstā, tā sauktajiem source elements (attēls 8). ISourceFile interfeiss pārstāv avota failu, bet ISourceConstruct – elementu iekš avota faila. Abstraktie klases SourceFile un SourceConstruct realizē ģeneriskus mehānismus, lai atvieglotu darbu ar avota failiem un to elementiem, piemēram, darbu ar teksta buferiem, sasaisti ar elementa koordinātēm avota tekstā, modeļa saskaņošanu ar pašreizējo bufera darba kopijas saturu u.c. Šo mehānismu īstenošana parasti ir gana sarežģīta uzdevums, un Handly var būtiski samazināt piepūli, izstrādājot valodai balstītas modeļus, piedāvājot kvalitatīvas pamata īstenojumus.
Papildus iepriekš uzskaitītajiem pamata mehānismiem, Handly sniedz tekstu buferu un "sīkattēlu" (snapshots) infrastruktūru, atbalsta integrāciju ar avota koda redaktoriem (tostarp realizētu "no kasti" integrāciju ar Xtext redaktoru), kā arī dažus vispārējus UI komponentus, kas strādā ar Handly modeļiem, piemēram, outline framework. Lai ilustrētu savas iespējas, projekts piedāvā vairākus piemērus, tostarp arī Java modeļa īstenojumu uz Handly. (Salīdzinot ar pilno Java modeļa īstenojumu JDT, šis modelis tika apzināti vienkāršot, lai to būtu vieglāk sagatavot.)
Kā jau iepriekš tika minēts, lielāka uzmanība sākotnējā Handly projektēšanā un tā turpmākajā attīstībā tika pievērsta un turpina tikt pievērsta mērogojamībai un elastībai.
Principā, handle-based modeļi ir diezgan labi mērogojami "pēc dizaina". Piemēram, idiomātiskā handle/body ļauj ierobežot modeļa patērēto atmiņu. Bet ir arī nianses. Veicot testus ar Handly mērogojamību, tika atklāta problēma ar notifikācijas mehānisma īstenošanu – mainot lielu skaitu elementu, delta izveide aizņēma pārāk ilgu laiku. Izrādījās, ka tā pati problēma pastāv arī Java modelī JDT, no kura kādreiz tika adaptēts attiecīgais kods. Mēs labojām kļūdu Handly un sagatavojām līdzīgu labojumu JDT, kas tika pieņemts ar pateicību. Tas ir tikai viens no piemēriem, kad Handly ieviešana esošajās modeļu īstenojumos varētu būt potenciāli noderīga, jo šajā gadījumā tādu kļūdu varētu novērst tikai vienā vietā.
Lai padarītu Handly ieviešanu esošajās modeļu realizācijās tehniski iespējamu, bibliotēkai jābūt ievērojamai elastībai. Galvenā problēma ir apgrieztas saderības saglabāšana modeļa API. Šī uzdevuma risinājums tika panākts ar skaidru modeļa specifiskā API nodalīšanu, ko definē un pilnībā kontrolē izstrādātājs, no bibliotēkas nodrošināta apvienota API meta-līmeņa. Tas ne tikai padara Handly ieviešanu esošajās realizācijās tehniski iespējamu, bet arī sniedz jauno modeļu izstrādātājiem ievērojamu brīvību API projektēšanas procesā.
Elastībai ir arī citi aspekti. Piemēram, Handly gandrīz nesniedz ierobežojumus modeļa struktūrai un var tikt izmantots gan vispārējās lietojumprogrammās, gan specializētajos valodās. Veidojot sākotnējā faila struktūru, Handly neuzspiež noteiktu AST attēlošanas formu un principā pat neprasa AST esamību, tādējādi nodrošinot saderību ar praktiski jebkuriem sintaktiskās analīzes mehānismiem. Beidzot, Handly pilnībā atbalsta integrāciju ar Eclipse workspace, taču var darboties arī tieši ar failu sistēmām, pateicoties integrācijai ar (EFS).
Aktuālā versija iznāca 2016. gada decembrī. Neskatoties uz to, ka projekts pašlaik ir inkubācijas stadijā un API vēl nav galīgi apstiprināts, Handly jau tiek izmantots divos lielos komerciālos produktos, kuri riskēja kļūt par “agriem pieņēmējiem” un, jāatzīmē, pagaidām par to nenožēlo.
Kā minēts iepriekš, viens no šiem produktiem ir 1C:Enterprise izstrādes rīki, kur Handly jau no paša sākuma tiek izmantots augsta līmeņa struktūras elementu modelēšanai, piemēram, programmēšanas valoda un vaicājumu valoda. Otrais produkts ir mazāk pazīstams plašai publikai. Tas ir , integrēta problēmas risināšanas procesoru projektēšanas vide (application-specific instruction-set processor, ASIP), ko izmanto gan pašā Čehijas uzņēmumā Codasip, gan tās klienti, tostarp , , , . Codasip izmanto Handly produkcijā kopš 2015. gada, sākot ar versiju Handly 0.2. Pēdējā versija Codasip Studio izmanto 0.5, kas publicēta 2016. gada jūnijā. Ondřej Ilčík, kurš vada IDE izstrādi Codasip, ir sazinājies ar projektu, nodrošinot ārkārtīgi svarīgas atsauksmes no "ārējā adoptētāja". Viņš pat spēja atrast nedaudz brīva laika, lai tieši piedalītos projekta izstrādē, realizējot UI slāni (~ 4000 rindiņas koda) vienam no Handly piemēriem, Java modelim. Sīkāka informācija "no pirmām rokām" par Handly izmantošanu adoptētājiem ir pieejama lapā projekta.
Mēs ceram, ka pēc 1.0 versijas iznākšanas, kas nodrošinās API stabilitātes garantiju un projekta iziešanu no inkubācijas stāvokļa, Handly iegūs jaunus adoptētājus. Pašlaik projekts turpina testēšanu un turpmāko API attīstību, izla dots divas "lielas" versijas gadā – jūnijā (tajā pašā datumā, kad notiek jūnija Eclipse izlaišana) un decembrī, nodrošinot prognozējamu grafiku, uz kuru adoptētāji var paļauties. Vēl var piebilst, ka projekta "bug rate" ir nemainīgi zems, un Handly no pašām pirmajām versijām uzticami darbojas agrīnajos adoptētāju produktos. Papildu iepazīšanai ar Eclipse Handly var izmantot un .
Avots: habr.com
