Me ndoshta, nuk ka nevojë për prezantim të veçantë. Shumë e njohin Eclipse falë Eclipse Java development tools (). Kjo IDE e njohur open-source Java asociohet me shumicën e zhvilluesve me fjalën “Eclipse”. Megjithatë, Eclipse është gjithashtu një platformë e zgjerueshme për integrimin e mjeteve të zhvillimit (Eclipse Platform), dhe një seri IDE-sh të ndërtuara mbi të, përfshirë JDT. Eclipse është gjithashtu Projekti Eclipse, një projekt në nivel të lartë që koordinon zhvillimin e Eclipse Platform dhe JDT, si dhe Eclipse SDK – produktu final i kësaj zhvillimi. Për më tepër, Eclipse është një Fondacion open-source me një komunitet të madh projektesh, prej të cilëve shumë prej tyre nuk janë shkruar në Java ose nuk kanë lidhje me mjetet e zhvillimit (p.sh. projektet dhe ). Bota e Eclipse është shumë e pasur.
Në këtë artikull, i cili ka karakter përmbledhës, do të përpiqemi të trajtojmë disa aspekte bazike të arkitekturës Eclipse si një platformë për ndërtimin e mjeteve të integruara të zhvillimit dhe të japim një pasqyrë të komponentëve të Eclipse, të cilët formojnë temelin e platformës teknologjike për ‘Konfiguruesin’ e ri 1C: Enterprise, . Sigurisht, një analizë e tillë do të jetë për shumë aspekte sipërfaqsore dhe mjaft të kufizuar, përfshirë faktin që ne orientoheni jo vetëm tek zhvilluesit Eclipse si audiencë të synuar. Megjithatë, ne shpresojmë se madje edhe zhvilluesit e përvojës në Eclipse do të mund të gjejnë informacion interesant në këtë artikull. Për shembull, do të flasim rreth një nga ‘sekretet e Eclipse’, një projekt relativisht i ri dhe ende i panjohur, , i cili është themeluar dhe mbështetur nga kompania 1C.
Hyrje në arkitekturën Eclipse
Hidhni një vështrim së pari disa aspekteve të përgjithshme të arkitekturës Eclipse përmes shembullit (JDT). Zgjedhja e JDT si shembull nuk është rastësore. Kjo është mjedisi i parë i integruar i zhvillimit që u shfaq në Eclipse. Projektet e tjera *DT të Eclipse, siç është Eclipse C/C++ Development Tooling (CDT), janë krijuar më vonë dhe kanë huazuar si parimet arkitekturore themelore ashtu edhe fragmente të veçanta të kodit burimor nga JDT. Bazat e arkitekturës të vendosura në JDT janë të rëndësishme edhe sot për çdo IDE që është ndërtuar mbi Eclipse Platform, duke përfshirë 1C:Enterprise Development Tools.
Në radhë të parë, duhet të theksohet se Eclipse karakterizohet nga një ndarje arkitekturore e qartë, me ndarjen e funksionalitetit të pavaruara nga gjuha nga funksionalitetet që mbështesin gjuhët e veçanta të programimit, dhe ndarjen e komponenteve ‘kernale’ (core) që nuk varen nga UI nga ato që lidhen me mbështetje për ndërfaqen e përdoruesit.
Kështu, Eclipse Platform përcakton infrastrukturën e përgjithshme, të pavarur nga gjuha, ndërsa mjetet Java shtojnë në Eclipse një IDE Java me funksionalitet të plotë. Si Eclipse Platform ashtu edhe JDT përbëhen nga disa komponente, secila prej të cilave i përket ose “kernale” të pavarur nga UI, ose shtresës UI (shih. 1).
Figura 1. Eclipse Platform dhe JDT
Le të përmendim komponentet kryesore të Eclipse Platform:
- Runtime — Përcakton infrastrukturën e plugin-ve. Eclipse karakterizohet nga një arkitekturë modulare. Në thelb, Eclipse është një koleksion ‘pikash zgjerimi’ dhe ‘zgjerimesh’.
- Workspace — Menaxhon një ose disa projekte. Një projekt përbëhet nga dosje dhe skedarë që shfaqen drejtpërdrejt në sistemin e skedarëve.
- Standard Widget Toolkit (SWT) — Ofron elementët bazikë të ndërfaqes së përdoruesit, të integruar me sistemin operativ.
- JFace — Ofron një sërë kornizash UI të ndërtuara mbi SWT.
- Workbench — Përcakton paradigmat e UI të Eclipse: redaktuesit, pamjet, perspektivat.
Duhet thënë se Eclipse Platform ofron gjithashtu shumë komponente të tjera të dobishme për ndërtimin e mjeteve të integruara të zhvillimit, midis të cilave mund të përmendim Debug, Compare, Search, dhe Team. Duhet përmendur veçmas JFace Text – bërthama për ndërtimin e ‘redaktorëve të zgjuar’ të kodit burimor. Fatkeqësisht, edhe shqyrtimi i shpejtë i këtyre komponenteve, si dhe i komponenteve të shtresës UI nuk është i mundur në kuadër të këtij artikulli, prandaj në pjesën e mbetur të këtij seksioni ne do të kufizohemi në një përmbledhje të komponenteve kryesore ‘kernale’ të Eclipse Platform dhe JDT.
Core Runtime
Infrastruktura e plugin-ve Eclipse bazohet në dhe ofrohet nga projekti . Çdo plugin i Eclipse është një OSGi-bundle. Specifikimi OSGi përcakton, ndër të tjera, mekanizmat e versionimit dhe zgjidhjes së varshmërive. Përveç këtyre mekanizmave standarde, Equinox sjell konceptin e pikës së zgjerimit. Çdo plugin mund të definojë pikat e tij të zgjerimit, si dhe të sjellë funksionalitete të tjera në sistem duke përdorur pikat e zgjerimit të përcaktuara nga ky ose plugins të tjerë. Çdo përshkrim i detajuar i mekanizmave OSGi dhe Equinox kalon përtej kësaj artikulli. Vlen të theksohet se modularizimi në Eclipse ka një karakter total (çdo nën-sistem, përfshirë Runtime, përbëhet nga një ose më shumë plugin), dhe pothuajse gjithçka në Eclipse është një zgjerim. Këto parime ishin vendosur në arkitekturën Eclipse shumë përpara se të implementohej OSGi (në atë kohë u përdor një teknologji e brendshme, e cila ishte shumë e ngjashme me OSGi).
Core Workspace
Gati çdo ambient i integruar i zhvillimit, i ndërtuar mbi platformën Eclipse, punon me Eclipse workspace. Workspace zakonisht përmban kodin burimor të aplikacionit që po zhvillohet në IDE. Workspace shfaqet drejtpërdrejt në sistemin e skedarëve dhe përbëhet nga projekte që përmbajnë dosje dhe skedarë. Këto projekte, dosje dhe skedarë quhen burime workspace. Zbatimi i workspace në Eclipse shërben si një cache në raport me sistemin e skedarëve, duke lejuar një shpejtësi të dukshme në navigimin e pemës së burimeve. Për më tepër, workspace ofron një sërë shërbimesh shtesë, duke përfshirë dhe .
Për mbështetje të workspace dhe burimeve të tij përgjigjet komponenti Core Resources (plugin org.eclipse.core.resources). Në veçanti, ky komponent ofron qasje programore në workspace në formën e modelit të burimeve. për një funksionim të efektshëm me këtë model, klientët kanë nevojë për një mënyrë të thjeshtë për të paraqitur një referencë në burim. Ndërkohë, objekti që ruan direkt gjendjen e burimit në model, do të ishte e dëshirueshme të fshihej nga qasja e klientit. Në të kundërt, në rastin, për shembull, të fshirjes së një skedari, klienti mund të vazhdojë të mbajë objektin, i cili nuk është më në model, me problemet që rrjedhin nga kjo. Eclipse e zgjidh këtë problem duke përdorur atë që quhet handle i burimit. Handle shërben si një çelës (ai di vetëm rrugën drejt burimit në workspace) dhe kontrollon plotësisht aksesin në objektin e brendshëm të modelit, i cili ruan drejtpërdrejt informacionin mbi gjendjen e burimit. Ky dizajn është një variacion i modelit .
Fig. 2 ilustron idiomën Handle/Body në lidhje me modelin e burimeve. Interfaci IResource përfaqëson handle-in e burimit dhe është API, ndryshe nga klasa Resource, e cila implementon këtë interface, si dhe klasa ResourceInfo, që përfaqëson trupin, të cilat nuk janë API. Theksojmë se handle di vetëm rrugën drejt burimit në raport me rrënjën e workspace dhe nuk përmban asnjë referencë në resource info. Objektet e resource info formojnë atë që quhet "pemë elementesh" (element tree). Kjo strukturë të dhënash është plotësisht materializuar në memoria. Për të gjetur një instancë të resource info, përkatëse me ndonjë handle, pemë elementesh duhet të kalojë në përputhje me rrugën që ruhet në këtë handle.
Fig. 2. IResource dhe ResourceInfo
Siç do të shohim më tej, dizajni bazë i modelit të burimeve (mund ta quajmë të bazuar në handle) përdoret në Eclipse edhe për modele të tjera. Ndërkohë, le të paraqesim disa veçori dalluese të këtij dizajni:
- Handle është një objekt vlerë (value object). Objektet e vlerës janë objekte të pandryshueshme (immutable), barazia e të cilëve nuk bazohet në identitet. Këto objekte mund të përdoren në mënyrë të sigurt si çelësa në konteinerat e heshur. Disa instanca të handle mund të referohen në të njëjtin burim. Për t'i krahasuar ato, duhet të përdoret metoda equals(Object).
- Handle përcakton sjelljen e burimit, por nuk përmban informacion mbi gjendjen e burimit (të dhënat e vetme që ai ruan janë "çelësi", rruga drejt burimit).
- Handle mund të referohet në një burim që nuk ekziston (ose një burim që ende nuk është krijuar, ose një burim që është fshirë tashmë). Ekzistenca e burimit mund të kontrollohet me metodën IResource.exists().
- Disa operacione mund të realizohen duke u mbështetur ekskluzivisht në informacionin e ruajtur në vetë handle (operacione të ashtuquajtura vetëm për handle). Shembuj janë IResource.getParent(), getFullPath(), etj. Burimi nuk është domosdoshmërisht për të ekzistuar për të realizuar me sukses një operacion të tillë. Operacionet, për të cilat nevojitet që burimi të ekzistojë për të përfunduar me sukses, hedhin një përjashtim (CoreException) nëse burimi nuk ekziston.
Eclipse ofron një mekanizëm efikas njoftimi për ndryshimet në burimet e workspace (shih fig. 3). Burimet mund të ndryshojnë si rezultat i veprimeve që kryhen në vetë Eclipse IDE, ashtu edhe si rezultat i sinkronizimit me sistemin e skedarëve. Në të dyja rastet, klientët e regjistruar për njoftime marrin informacion të detajuar rreth ndryshimeve në formën e "delta burimore" (resource delta). Delta përshkruan ndryshimet midis dy gjendjeve (nën)pyjeve të burimeve në workspace dhe vetë është një pemë, ku çdo nyje përshkruan një ndryshim të një burimi të caktuar dhe përmban një listë dhelash të nivelit të ardhshëm, duke përshkruar ndryshimet e burimeve fëmijë.
Fig. 3. IResourceChangeEvent dhe IResourceDelta
Mekanizmi i njoftimit i bazuar në delta burimore ka tipare të mëposhtme:
- Një ndryshim i vetëm dhe shumë ndryshime përshkruhen me të njëjtën strukturë, pasi delta ndërtohet mbi parimin e kompozitës rekursive. Klientët e regjistruar mund të trajtojnë njoftimet për ndryshimin e burimeve duke bërë një zbritje rekursive në pemën e deltat.
- Delta përmban informacionin e plotë në lidhje me ndryshimin e burimit, duke përfshirë zhvendosjen e tij dhe/ose ndryshimin e "markerave" të lidhur (siç janë markera për gabimet e kompiluara).
- Duke marrë parasysh se referencat për burimin bëhen përmes handle, delta mund të referencojë natyrshëm një burim të largët.
Siç do ta shohim së shpejti, komponentët kryesorë të dizajnit të mekanizmit të njoftimit për ndryshimin e modelit të burimeve janë të aplikueshëm edhe për modele të tjera të bazuara në handle.
JDT Core
Modeli i burimeve të workspace Eclipse është një model themelor që nuk është varur nga gjuha. Komponenta JDT Core (plugin org.eclipse.jdt.core) ofron API për navigimin dhe analizimin e strukturës së workspace nga perspektiva e Java, e njohur si "modeli Java" (Java model). Ky API përkufizohet në terma të elementeve Java, ndryshe nga API i nëntokës i modelit të burimeve, i cili përkufizohet në terma të dosjeve dhe skedarëve. Interfacet kryesore të pemës së elementeve Java paraqiten në fig. 4.
Fig. 4. Elementet e modelit Java
Modeli Java përdor të njëjtin idiomë handle/body si modeli i burimeve (shih fig. 5). IJavaElement është handle, ndërsa JavaElementInfo luan rolin e body. Interfaci IJavaElement përcakton protokollin e përbashkët për të gjithë elementët Java. Disa nga metodat e tij janë vetëm për handle: getElementName(), getParent(), etj. Objekti JavaElementInfo ruan gjendjen e elementit përkatës: strukturën dhe atributet e tij.
Fig. 5. IJavaElement dhe JavaElementInfo
Modeli Java ka disa dallime në realizimin e dizajnit bazë handle/body në krahasim me modelin e burimeve. Siç u përmend më parë, në modelin e burimeve, pema e elementeve, me nyjet e saj që janë objekte të informacionit të burimit, ruhet plotësisht në memorie. Por në modelin Java mund të ketë një numër shumë më të madh elementesh se në pemën e burimeve, pasi ajo përfshin gjithashtu strukturën e brendshme të skedarëve .java dhe .class: llojet, fushat dhe metodat.
Për të shmangur materializimin e plotë të gjithë pemës së elementeve në memorje, realizimi i modelit Java përdor një cache të kufizuar LRU për informacionin e elementeve, ku çelësi është handle IJavaElement. Objekti i informacionit të elementeve krijohet me kërkesë ndërsa ndodh navigimi në pemën e elementeve. Në këtë mënyrë, elementet më pak të përdorura përzgjidhen nga cache, dhe konsumimi i memories nga modeli mbetet i kufizuar në madhësinë e dhënë të cache. Kjo është edhe një avantazh tjetër i dizajnit të bazuar në handle, i cili e fsheh plotësisht këto detaje realizimi nga kodi i klientit.
Mekanizmi i njoftimit për ndryshimin e elementeve Java është në përgjithësi i ngjashëm me mekanizmin e diskutuar më sipër për ndjekjen e ndryshimeve të burimeve të workspace. Klienti që dëshiron të ndjekë ndryshimet në modelin Java regjistrohet për njoftime, të cilat paraqiten në formën e një objekti ElementChangedEvent, i cili përmban IJavaElementDelta (shih fig. 6).
Fig. 6. ElementChangedEvent dhe IJavaElementDelta
Modeli Java nuk përmban informacion mbi trupat e metodave ose zgjidhjen e emrave, prandaj, për analizën e detajuar të kodit të shkruar në Java, JDT Core ofron një model shtesë (jo të bazuar në handle): (abstract syntax tree, AST). AST paraqet rezultatin e analizës sintaksore të tekstit burimor. Nyjet e AST korrespondojnë me elementet e strukturës së modulit burimor (deklaratat, operatorët, shprehjet, etj.) dhe përmbajnë informacion mbi koordinatat e elementit përkatës në tekstin burimor, si dhe (si opsion) informacion mbi zgjidhjen e emrave në formën e referencave në atë që quhen bindings. Bindings janë objekte që përfaqësojnë entitete të emëruara, siç janë tipet, metodat dhe variablat, që janë të njohura nga kompajleri. Ndryshe nga nyjat e AST, të cilat formojnë një pemë, bindings mbështesin referencat e kryqëzuara dhe në përgjithësi formojnë një graf. Klasa abstrakte ASTNode është një klasë bazë e përbashkët për të gjitha nyjat e AST. Nënklasat e ASTNode korrespondjnë me konstruksione të caktuara sintaksore të gjuhës Java.
Duke pasur parasysh se pemët sintaksore mund të konsumojnë një sasi të konsiderueshme memorie, JDT ka të cache vetëm një AST për redaktorin aktiv. Ndryshe nga modeli Java, AST zakonisht konsiderohet si një model "ndërmjetës", "përkohshëm", ku klientët nuk duhet të mbajnë referenca jashtë kontekstit të operacionit që çoi në krijimin e AST.
Tre modelet e përmendura (Java model, AST, bindings) së bashku përbëjnë bazën për ndërtimin e "mjeteve inteligjente të zhvillimit" në JDT, përfshirë një redaktor të fuqishëm Java me ndihmës të ndryshëm, veprime të ndryshme për përpunimin e kodit burimor (përfshirë organizimin e listës së importeve të emrave dhe formatimin sipas stilit të konfiguruar), mjete kërkimi dhe riformatimi. Në këtë kontekst, modeli Java luan një rol të veçantë, pasi pikërisht ai përdoret si bazë për përfaqësimin vizual të strukturës së aplikacionit që po zhvillohet (p.sh., në Package Explorer, Outline, Search, Call Hierarchy, dhe Type Hierarchy).
Komponentët e Eclipse, të përdorur në 1C:Enterprise Developments Tools
Në fig. 7 janë shfaqur komponentët e Eclipse, të cilët formojnë themelin e platformës teknologjike për 1C:Enterprise Development Tools.
Fig. 7. Eclipse si platformë për 1C:Enterprise Development Tools
Eclipse Platform siguron infrastrukturën bazë. Ne shqyrtuam disa aspektet e kësaj infrastrukture në seksionin e mëparshëm.
(EMF) ofron mjete të zakonshme për modelimin e të dhënave të strukturuara. EMF është integuar me Eclipse Platform, por mund të përdoret edhe veçmas, në aplikacione të zakonshme Java. Shpesh, zhvilluesit e rinj të Eclipse janë tashmë të njohur mirë me EMF, përkundrazi, ndoshta nuk kuptojnë në detaje platformën Eclipse. Një nga arsyet për këtë popullaritet të merituar është dizajni universal, i cili përfshin, ndër të tjera, një API të unifikuar në nivelin e metave, që lejon të punosh në mënyrë të përgjithshme me çdo model EMF. Zbatimet themelore që ofron EMF për objektet e modelit dhe nëndegët e gjenerimit të kodit të modelit bazuar në metamodelin rrisin ndjeshëm shpejtësinë e zhvillimit dhe zvogëlojnë numrin e gabimeve. Gjithashtu, EMF përfshin mekanizma për serializimin e modeleve, ndjekjen e ndryshimeve në model dhe shumë më tepër.
Siç ndodh me çdo mjet të vërtetë universal, EMF është i përshtatshëm për të trajtuar një gamë të gjerë problemesh të lidhura me modelimin, por disa klasat e modeleve (p.sh., modelet bazuar në handle që u përmendën më sipër) mund të kërkojnë mjete më të specializuara për modelimin. Të flasësh për EMF është një detyrë që ndonjëherë është e ndërlikuar, veçanërisht në kufizimet e një artikulli, pasi është një temë për një libër të veçantë, dhe mjaft të trashë. Vlen të theksohet se sistemi i kualitetit për përfshirjen e EMF, ka lejuar që të lindë një gamë e gjerë projektesh mbi modelimin, të cilat janë pjesë e projektit të nivelit të lartë. bashkë me vetë EMF. Një nga këto projekte është Eclipse Xtext.
ofron infrastrukturë për "modelimin tekstual". Xtext përdor për analizimin sintaksor të tekstit burimor dhe EMF për përfaqësimin e ASG (grafi abstrakt sintaksor, i cili, në thelb, është një kombinim i AST dhe bindings), e njohur gjithashtu si "modeli semantik". Gramatika e gjuhës që po modelohet me Xtext përshkruhet në gjuhën e saj të vetme Xtext. Kjo lejon jo vetëm gjenerimin e përshkrimit të gramatikës për ANTLR, por gjithashtu ofron mekanizmin për serializimin e AST (dmth. Xtext siguron si parser ashtu edhe unparser), ndihmës kontekstual, dhe një sërë komponentësh të tjerë gjuhësor. Në anën tjetër, gjuha përshkruese e gramatikës e përdorur në Xtext është më pak fleksibel në krahasim, le të themi, me gjuhën përshkruese të gramatikës në ANTLR. Prandaj, ndonjëherë mund të duhet "të përshtatet" gjuha që po zbatohen për Xtext, gjë që zakonisht nuk është një problem, nëse është fjala për një gjuhë që po zhvillohet nga fillimi, por mund të jetë e papranueshme për gjuhët me një sintaksë të vendosur tashmë. Pavarësisht kësaj, Xtext është aktualisht mjeti më i avancuar, funksionalisht e plotë dhe universale në Eclipse për ndërtimin e gjuhëve të programimit dhe mjeteve për to. Në veçanti, ai është një mjet ideal për prototipimin e shpejtë (gjuha specifike për domain, DSL). Përveç "ndërgjegjes nuk është notuar" si bërthama gjuhësore e bazuar në ANTLR dhe EMF, Xtext ofron shumë komponente të dobishme të nivelit më të lartë, përfshirë mekanizma indeksimi, ndërtimin inkremental, "redaktorin inteligjent", dhe shumë, shumë më tepër, por lë pas modelet e gjuhës së bazuar në handle. Si EMF, Xtext është një temë që meriton një libër të veçantë, dhe me siguri nuk mund të përmendim të gjitha mundësitë e tij tani.
1C:Enterprise Development Tools përdorin aktivisht si EMF-në vetë, ashtu edhe një sërë projektesh të tjera Eclipse Modeling. Në veçanti, Xtext është një nga bazat e mjeteve të zhvillimit për gjuhët 1C:Enterprise, si gjuha e programimit të integruar dhe gjuha e kërkesave. Një tjetër bazë e këtyre mjeteve të zhvillimit është projekti Eclipse Handly, për të cilin do të qëndrojmë më në detaje (nga komponentët e përmendur të Eclipse, ai është ende më pak i njohur).
, nënprojekt i projektit të nivelit të lartë Eclipse Technology, lindi si rezultat i një kontribucioni fillestar të kodit në Fondacionin Eclipse, i bërë nga kompania 1C në vitin 2014. Që atëherë kompania 1C vazhdon të mbështesë zhvillimin e projektit; kontribuesit e Handly janë punonjës të kompanisë. Projekti është i vogël, por zë një nişë mjaft unike në Eclipse: qëllimi kryesor i tij është mbështetje e zhvillimit të modeleve të bazuara në handle.
Parimet themelore të arkitekturës së modeleve të bazuara në handle, si idiomi handle/body, u shqyrtuan më lart në shembullin e modelit të burimeve dhe modelit Java. Aty u theksua gjithashtu se si modeli i burimeve ashtu edhe modeli Java janë baza të rëndësishme për mjetet e zhvillimit Java të Eclipse (JDT). Dhe meqenëse praktikisht të gjitha projektet *DT të Eclipse kanë një arkitekturë të ngjashme me JDT, nuk do të ishte një ekzagjerim të thuash se modelet e bazuara në handle janë themeli i shumë, nëse jo të gjitha IDE-ve, të ndërtuara mbi platformën Eclipse. Për shembull, në Eclipse C/C++ Development Tooling (CDT), ka një model të bazuar në handle për C/C++, i cili luan të njëjtën rol në arkitekturën e CDT si modeli Java në JDT.
Para se të shfaqej Handly, Eclipse nuk ofronte biblioteka të specializuara për ndërtimin e modeleve të gjuhëve të bazuara në handle. Modelet që ekzistojnë tani u krijuan kryesisht me ndihmën e përshtatjes direkte të kodit të modelit Java (e njohur ndryshe si kopjimi/ulli), në rastet kur kjo lejohet Licenca Publike e Eclipse (EPL). (Natyrisht, për shembuj, për projektet e Eclipse vetë, kjo zakonisht nuk paraqet një problem nga pikëpamja ligjore, ndryshe nga produktet me kod të mbyllur.) Përveç papërgjegjshmërisë së saj karakteristike, kjo metodë çon në probleme të njohura: dublim kodi, gabime të introduktuara gjatë përshtatjes, etj. Çfarë është më e keqe, modelet e rezultuese mbeten "gjë në vetvete" dhe nuk shfrytëzojnë potencialin ekzistues për unifikim. Në fakt, identifikimi i koncepteve dhe protokollit të zakonshëm për modelet e bazuara në handle mund të çonte në krijimin e komponenteve të ripërdorshme për punën me to, ashtu si ndodhi në rastin e EMF.
Nuk mund të thuhet se në Eclipse nuk kishte një kuptim të këtyre problemeve. Që në vitin 2005 , duke përmbledhur përvojën e zhvillimit të prototipit CDT, nevojën për krijimin e një infrastrukture të përbashkët për modelet e gjuhëve, përfshirë edhe modelet me bazë handle. Por, siç ndodh shpesh, për shkak të detyrave më të prioritizuara, realisht këto ide kurrë nuk u zbatua. Ndërkohë, faktorimi i kodit të projekteve *DT vazhdon të mbetet një nga temat e paushtruara mirë në Eclipse.
Në një kuptim të caktuar, projekti Handly është menduar të zgjidhë afërsisht të njëjtat probleme si EMF, por për modelet e bazuara në handle, dhe kryesisht për gjuhët (dmth., që përfaqësojnë elementët e strukturës së një gjuhe programimi). Më poshtë janë enumeruar qëllimet kryesore që ishin të vendosura gjatë projektimit të Handly:
- Identifikimi i abstraksioneve kryesore të fushës së subjektit.
- Reduktimi i përpjekjeve dhe përmirësimi i cilësisë së implementimit të modeleve të gjuhëve të bazuara në handle përmes ripërdorimit të kodit.
- Sigurimi i një API të unifikuar në nivelin meta për modelet e rezultuese, që e bën të mundur krijimin e komponenteve të përgjithshme të IDE, të cilat punojnë me modelet e gjuhëve të bazuara në handle.
- Flexibilitet dhe shkallëzim.
- Integrimi me Xtext (në një shtresë të veçantë).
Për identifikimin e koncepteve dhe protokolleve të zakonshme, janë analizuar implementimet ekzistuese të modeleve të gjuhëve të bazuara në handle. Interfaces kryesore dhe implementimet bazë, të ofruara nga Handly, janë paraqitur në fig. 8.
Fig. 8. Interfaces kryesore dhe implementimet bazë të elementeve të Handly
Interface IElement përfaqëson handle-në e elementit dhe është e përbashkët për elementet e të gjitha modeleve, të bazuara në Handly. Klasa abstrakte Element implementon mekanizmin e përgjithshëm handle/body (fig. 9).
Fig. 9. IElement dhe implementimi i përgjithshëm handle/body
Përveç kësaj, Handly ofron një mekanizëm të përgjithshëm për njoftimin e ndryshimeve në elementet e modelit (fig. 10). Siç mund të shihet, në përgjithësi është i ngjashëm me mekanizmat e njoftimit të implementuar në modelin e burimeve dhe modelin Java, dhe përdor IElementDelta për të paraqitur në mënyrë të unifikuar informacionin mbi ndryshimin e elementit.
Fig. 10. Interfacet e përgjithshme dhe implementimet bazë të mekanizmit të njoftimit Handly
Pjesa e mësipërme e Handly (fig. 9 dhe 10) mund të përdoret për të paraqitur pothuajse çdo model të bazuar në handle. Për krijimin e modeleve projekti ofron funksionalitete shtesë – veçanërisht, interfacet e përgjithshme dhe implementimet bazë për elementet e strukturës së tekstit origjinal, të njohura si source elements (fig. 8). Interface ISourceFile paraqet skedarin origjinal, ndërsa ISourceConstruct – elementin brenda skedarit origjinal. Klasa abstracte SourceFile dhe SourceConstruct implementojnë mekanizma të përgjithshëm për të mbështetur punën me skedarët origjinalë dhe elementet e tyre, për shembull, punën me buferat tekstualë, lidhjen me koordinatat e elementit në tekstin origjinal, pajtimin e modelit me përmbajtjen aktuale të buferit të kopjes punuese, etj. Implementimi i këtyre mekanizmave zakonisht është një detyrë mjaft e ndërlikuar, dhe Handly mund të zvogëlojë ndjeshëm përpjekjet për zhvillimin e modeleve të bazuara në handle duke ofruar implementime bazë të cilësisë.
Përveç mekanizmave të lartë të përmendur, Handly ofron infrastrukturën për buferat tekstualë dhe "snapshots", mbështetje për integrimin me redaktorët e kodit burimor (përfshirë integrimin e realizuar "nga kutia" me redaktorin Xtext), si dhe disa komponente UI të zakonshme që punojnë me modelet e bazuara në Handly, si çadra e skemës. Për të ilustruar mundësitë e tij, projekti ofron disa shembuj, përfshirë implementimin e modelit Java në Handly. (Në krahasim me implementimin e plotë të modelit Java në JDT, ky model është qëllimisht pak më i thjeshtë për qartësi më të madhe).
Siç u përmend më parë, një vëmendje e konsiderueshme gjatë projektimit fillestar të Handly dhe zhvillimit të mëtejshëm është kushtuar dhe vazhdon të kushtohet shkallueshmërisë dhe fleksibilitetit.
Në parim, modelet e bazuara në handle shkallëzohen mjaft mirë "me dizajn". Për shembull, idiomi handle/body lejon të kufizohet sasia e memorjes së konsumuar nga modeli. Por ka edhe nuanca. Gjatë testimeve të Handly për shkallueshmëri, u zbulua një problem në implementimin e mekanizmit të njoftimit – kur u ndryshuan një numër i madh elementesh, ndërtimi i delfteve mori shumë kohë. Doli se po i njëjti problem ishte i pranishëm edhe në modelin Java JDT, nga i cili ishin adapptuar më parë kodet përkatëse. Ne e korrigjuam gabimin në Handly dhe përgatitëm një patch të ngjashëm për JDT, i cili u pranuar me mirënjohje. Ky është vetëm një nga shembujt, kur implementimi i Handly në implementimet ekzistuese të modeleve mund të ishte potencialisht i dobishëm, sepse në këtë rast mund të rregullohej një gabim në vetëm një vend.
Për të bërë implementimin e Handly në implementimet ekzistuese të modeleve teknikisht të mundshëm, biblioteka duhet të ketë një fleksibilitet të konsiderueshëm. Problemi kryesor është të ruhet pajtueshmëria prapa me API-në e modelit. Ky detyrë u zgjidh në nëpërmjet ndarjes së qartë të API-së specifike për modelin, e cila është përcaktuar dhe plotësisht e kontrolluar nga zhvilluesi, nga API-ja e unifikuar të nivelit meta, e cila ofrohet nga biblioteka. Kjo jo vetëm që bën të mundur implementimin teknik të Handly në implementimet ekzistuese, por gjithashtu ofron zhvilluesit të modelit të ri një liri të konsiderueshme në projektimin e API-së.
Fleksibiliteti ka edhe aspekte të tjera. Për shembull, Handly nuk imponon shumë kufizime mbi strukturën e modelit dhe mund të përdoret si për modelimin e gjuhëve të zakonshme, ashtu edhe për gjuhët e orientuara ndaj subjektit. Kur ndërtohet struktura e skedarit origjinal, Handly nuk parashikon asnjë formë të caktuar të përfaqësimit të AST, dhe në parim nuk kërkon madje as ekzistencën e AST, duke ofruar kështu pajtueshmëri me praktikisht çdo mekanizëm të analizës sintaksoresh. Në fund, Handly mbështet integrimin e plotë me ambientin e Eclipse, por gjithashtu mund të punojë drejtpërdrejt me sistemet e skedarëve, falë integrimit me (EFS).
Versioni aktual doli më dhjetor 2016. Megjithëse aktualisht projekti është në fazën e inkubacionit dhe API-ja ende nuk është finalizuar, Handly është përdorur tashmë në dy produkte të mëdha komerciale që u guxuan të veprojnë si "adopterë të hershëm", dhe, duhet thënë, deri tani nuk janë penduar për këtë.
Siç u përmend më lart, një nga këto produkte është 1C:Enterprise Development Tools, ku Handly është përdorur që në fillim për modelimin e elementeve të strukturës së lartë të gjuhëve 1C:Enterprise, si gjuha e programimit të integruar dhe gjuha e kërkesave. Produkti tjetër është më pak i njohur për publikun e gjerë. Ky është , një mjedis i integruar projektimi për procesorët e orientuar drejt problemeve (application-specific instruction-set processor, ASIP), i përdorur si brenda vetë kompanisë çeke Codasip ashtu edhe nga klientët e saj, midis të cilëve , , , . Codasip e përdor Handly në prodhim që nga viti 2015, duke filluar nga versioni Handly 0.2. Rrelease-i më i fundit i Codasip Studio përdor versionin 0.5, të lëshuar në qershor 2016. Ondřej Ilčík, i cili udhëheq zhvillimin e IDE në Codasip, është në kontakt me projektin, duke ofruar një feedback të rëndësishëm nga "adopteri i jashtëm". Ai madje ka arritur të gjejë pak kohë të lirë për t'u angazhuar drejtpërdrejt në zhvillimin e projektit, duke realizuar një shtresë UI (~ 4000 rreshta kodi) për një nga shembujt e Handly, modelin Java. Më shumë informacion "nga burimi i parë" për përdorimin e Handly nga adopterët mund të merret në faqen projektit.
Shpresojmë që pas publikimit të versionit 1.0 me garancinë e stabilitetit të API dhe daljen e projektit nga faza e inkubacionit, Handly do të ketë edhe adoptera të rinj. Ndërkohë, projekti vazhdon testimin dhe përmirësimin e mëtutjeshëm të API, duke lëshuar dy "larje të mëdha" në vit – në qershor (në të njëjtën datë si publikimi paralel i Eclipse) dhe në dhjetor, duke ofruar një orar të parashikueshëm në të cilin mund të mbështeten adopterët. Mund të thuhet gjithashtu se shkalla e "gabimeve" të projektit mbetet në një nivel të ulët të qëndrueshëm dhe Handly ka qenë i besueshëm në produktet e adopterëve të hershëm që nga versionet e para. Për njohje më të thellë me Eclipse Handly mund të përdorni dhe .
Burimi: habr.com
