Eclipse tehnoloogilise platvormina 1C:Enterprise Development Tools jaoks

Ilmselt, Eclipse ei vaja enam erilist tutvustust. Paljud tunnevad Eclipse'i tänu Eclipse Java arendustööriistadele (JDT). Just see populaarne avatud lähtekoodiga Java IDE seostatakse enamiku arendajate seas sõnaga “Eclipse”. Kuid Eclipse on ka arendustööriistade integreerimise laiendatav platvorm (Eclipse Platform) ja terve rida selle põhjal ehitatud IDE-sid, sealhulgas JDT. Eclipse on ka Eclipse Project, kõrgema taseme projekt, mis koordineerib Eclipse Platvormi ja JDT arendust, ning Eclipse SDK – selle arenduse tulemus. Lõpuks on Eclipse avatud lähtekoodiga fond, millel on suur projektide kogukond, kusjuures kaugel mitte kõik neist on kirjutatud Java keeles või seotud arendustööriistadega (näiteks projektid Eclipse IoT ja Eclipse Science). Eclipse'i maailm on väga mitmekesine.

Antud artiklis, mille iseloom on ülevaatlik, proovime käsitleda mõningaid Eclipse'i arhitektuuri põhialuseid kui integreeritud arendustööriistade platvormi ning anda esialgne ülevaade Eclipse'i komponentidest, mis moodustavad 1C: Ettevõtte „uue Konfiguratori” tehnoloogilise platvormi aluse, 1C:Enterprise Development Tools. Loomulikult on selline käsitlus paratamatult pinnapealne ja üsna piiratud, sealhulgas seetõttu, et me ei keskendu ainult Eclipse arendajatele sihtrühmana. Siiski loodame, et isegi kogenud Eclipse arendajad leiavad artiklist huvitavat teavet. Näiteks räägime ühest Eclipse'i "saladusest", suhteliselt uuest ja praegu veel vähe tuntud projektist. Eclipse Handly, mis on loodud ja mida toetab ettevõte 1C.

Eclipse'i arhitektuuri tutvustus

Alustame mõnede üldiste aspektide vaatlemist Eclipse'i arhitektuurist näitena Eclipse Java arendustooted (JDT). Just JDT valimine näiteks ei ole juhuslik. See on esimene integreeritud arenduskeskkond, mis ilmus Eclipse'is. Ülejäänud *DT projektid Eclipse'is, nagu Eclipse C/C++ Development Tooling (CDT), loodi hiljem ja laenasid nii põhialuste arhitektuuri kui ka üksikute koodifragmente JDT-st. JDT-sse rajatud arhitektuuri alused on endiselt asjakohased peaaegu iga Eclipse Platformi peal ehitatud IDE jaoks, sealhulgas 1C:Enterprise Development Tools.

Eclipse'i iseloomustab selge arhitektuuriline kihistumine, kus keele-dependeeritud funktsionaalsus eraldatakse keele-sõltumatust funktsionaalsusest, samuti eraldatakse UI-sõltumatud "tuum" komponendid, mis on seotud kasutajaliidese toetamisega.

Eclipse Platform määratleb ühtse, keele-sõltumatu infrastruktuuri, samas kui Java arendustööriistad lisavad Eclipse'ile funktsionaalsuse, et muuta see täisfunktsionaalseks Java IDE-ks. N nii Eclipse Platform kui ka JDT koosnevad mitmest komponendist, millest igaüks kuulub kas UI-sõltumatu "tuuma" või UI kihi alla (vt joonis 1).

Joonis 1. Eclipse Platform ja JDT

Loetlege Eclipse Platformi põhikomponendid:

• Runtime — Määratleb plugin'ite infrastruktuuri. Eclipse'i iseloomustab modulaalne arhitektuur. Tegelikult on Eclipse kogum "laienduspunkte" ja "laiendusi".
• Workspace — Haldate ühte või mitut projekti. Projekt koosneb kaustadest ja failidest, mis kuvatakse otse failisüsteemis.
• Standard Widget Toolkit (SWT) — Pakub põhielemente, mis on integreeritud operatsioonisüsteemiga.
• JFace — Pakub mitmeid UI raamistikku, mis on ehitatud SWT peale.
• Workbench — Määratleb Eclipse'i UI-paradigma: redigeerijad, vaated, perspektiivid.

Oluline on märkida, et Eclipse Platform pakub palju muid kasulikke komponente integreeritud arendustööriistade loomiseks, sealhulgas Debug, Compare, Search ja Team. Eriti tuleks mainida JFace Text'i – aluseks "intelligentsete" koodiredaktorite loomiseks. Kahjuks on isegi nende komponentide kiire ülevaade, samuti UI-kihi komponendid, selle artikli raames võimatu, seega piirdume järgnevas osas Eclipse Platformi ja JDT peamiste "tuum" komponentide ülevaatusega.

Core Runtime

Eclipse'i pluginainfrastruktuur põhineb OSGi ja selle eest vastutab projekt Eclipse Equinox. Iga Eclipse'i plugin on OSGi-pakk. OSGi spetsifikatsioon määratleb muu hulgas versioonihaldamise ja sõltuvuste lahendamise mehhanismid. Lisaks nendele standardsetele mehhanismidele tutvustab Equinox mõistet laiendamispunkt.. Iga plugin võib määrata oma laienduspunktid ja tuua süsteemi täiendavat funktsionaalsust („laiendused“), kasutades selle sama või teiste pluginatega määratud laienduspunktide süsteemi. OSGi ja Equinox mehhanismide üksikasjalik kirjeldus ületab selle artikli raame. Oluline on märkida, et Eclipse'is on modulariseerimine kõikehõlmav (iga alamsüsteem, sealhulgas Runtime, koosneb ühest või mitmest pluginast) ja praktiliselt kõik Eclipse'is on laiendamine. Need põhimõtted olid Eclipse'i arhitektuuri juurdunud veel enne OSGi rakendamist (sel ajal kasutati oma tehnoloogiat, mis oli mitmeti OSGi sarnane).

Tuumikula

Peaaegu iga integreeritud arenduskeskkond, mis on üles ehitatud Eclipse Platformi põhjal, töötab Eclipse'i tööruumi (workspace) kaudu. Just tööruum sisaldab tavaliselt IDE-s arendatava rakenduse lähtekoodi. Tööruum peegeldub otse failisüsteemis ja koosneb projektidest, mis sisaldavad kaustu ja faile. Need projektid, kaustad ja failid on nimetatud ressurssideks workspace. Workspace'i realiseerimine Eclipse'is toimib nagu vahemälu failisüsteemi suhtes, mis kiirendab oluliselt ressursi puu läbimist. Lisaks pakub workspace mitmeid täiendavaid teenuseid, sealhulgas ressursside muutuste teavitamise mehhanismi ja inkrementeerivate ehitajate infrastruktuuri.

Workspace'i ja selle ressursside toetamise eest vastutab komponent Core Resources (plugin org.eclipse.core.resources). Täpsemalt pakub see komponent programmilist ligipääsu workspace'ile järgmise ressursimudeli. Efektiivseks töötamiseks selle mudeliga vajavad kliendid lihtsat viisi ressursi lingi esitamiseks. Samal ajal oleks soovitav peita kliendi ligipääsu alt objekt, mis otseselt säilitab ressursi oleku mudelis. Vastasel juhul, näiteks faili kustutamise korral, võib klient jätkuvalt hoida objekti, mida mudelis enam ei eksisteeri, mis võib põhjustada mitmeid probleeme. Eclipse lahendab selle ülesande, kasutades nn handle ressurs. Handle toimib võtmena (see tunneb ainult teed ressursile tööruumis) ja kontrollib täielikult ligipääsu mudeli sisemisele objektile, mis salvestab teavet ressursi oleku kohta. See disain on variatsioon mustrist Handle/Body.

Joonis 2 illustreerib Handle/Body idiomi ressursimudeli kontekstis. IResource liides esindab ressursi handle'it ja on API, erinevalt Resource klassist, mis seda liidest rakendab, ja ResourceInfo klassist, mis esindab body't, mis ei ole API. Tõstame esile, et handle tunneb ainult teed ressursile tööruumi juurest ja ei sisalda viidet resource info'le. Resource info objektid moodustavad nn "elementide puu" (element tree). See andmestruktuur on täielikult materialiseeritud mälus. Et leida resource info eksemplar, mis vastab teatud handle'ile, käiakse element tree läbi vastavalt sellele handle'is hoitavale teele.

Joonis 2. IResource ja ResourceInfo

Nagu me hiljem näeme, kasutatakse ressursimudeli põhikujundust (mida võib nimetada handle-põhiseks) Eclipse'is ning teistes mudelites. Aga enne kui toome välja mõned selle disaini eripärad:

• Handle on väärtusobjekt (value object). Väärtusobjektid on muutumatud (immutable) objektid, mille võrdsus ei põhine identiteedil. Selliseid objekte saab ohutult kasutada võtmena hashitud konteinerites. Mitmed handle'i eksemplarid võivad viidata samale resursile. Nende võrdlemiseks tuleb kasutada meetodit equals(Object).
• Handle määratleb ressursi käitumise, kuid ei sisalda teavet ressursi oleku kohta (ainukesed andmed, mida ta salvestab, on „võti”, tee ressursini).
• Handle võib viidata mitteeksisteerivale ressursile (kas ressursile, mis pole veel loodud, või ressursile, mis on juba kustutatud). Ressursi olemasolu saab kontrollida meetodi IResource.exists() abil.
• Mõned operatsioonid võivad olla rakendatud ainult handle'is endas salvestatud teabe alusel (nii nimetatud ainult handle'i operatsioonid). Näiteks on IResource.getParent(), getFullPath jne. Ressurss ei pea eksisteerima, et sellist operatsiooni edukalt täita. Operatsioonid, mille edukaks täitmiseks on vajalik ressursi olemasolu, viskavad erandi (CoreException), kui ressurss ei eksisteeri.

Eclipse pakub tõhusat mehhanismi tööruumi ressursside muutuste teavitamiseks. Ressursid võivad muutuda nii Eclipse IDE-s endas toimuva tegevuse tõttu kui ka failisüsteemiga sünkroonimise tulemusena. Mõlemal juhul antakse teavitustele registreerunud klientidele üksikasjalik teave muudatuste kohta 'ressursi delta' kujul. Delta kirjeldab muudatusi kahe (al)puu tööruumi ressursside oleku vahel ja on ise puu, kus iga sõlm kirjeldab teatud ressursi muutust ning sisaldab nimekirja järgmise tasandi deltadest, mis kirjeldavad alamresursside muudatusi.

Joonis 3. IResourceChangeEvent ja IResourceDelta

Resursi deltadest põhinev teavitamise mehhanism omab järgmisi omadusi:

• Ühtne muudatus ja mitmed muudatused on kirjeldatud sama struktuuriga, kuna delta on üles ehitatud rekursiivse kompositsiooni põhimõttel. Klientide tellijad saavad töötleda ressursside muudatusi teavitusi, rakendades rekursiivset allakäiku deltade puul.
• Deleht sisaldab kogu teavet ressursi muudatuste kohta, sealhulgas selle liikumise ja/või sellega seotud „markerite” muutmise kohta (markerite kujul esitatakse näiteks kompileerimisvead).
• Kuna ressursile viidatakse handle'i kaudu, saab deleht loomulikult viidata ka eemalolevale ressurssile.

Nagu me varsti näeme, on ressursimudeli muutmise teavitamismehhanismi peamised komponendid asjakohased ka teiste handle-põhiste mudelite jaoks.

JDT Core

Eclipse workspace'i ressursimudel on põhialuseks olev keelest sõltumatu mudel. JDT Core komponent (plugin org.eclipse.jdt.core) pakub API-d workspace'i struktuuri navigeerimiseks ja analüüsimiseks Java vaatepunktist, nii nimetatud „Java mudel” (Java mudel). See API on määratletud Java elementide mõistetena, erinevalt ressursimudeli alusele API-st, mis on määratletud kaustade ja failide mõistetena. Java elementide puu peamised liidesed on kujutatud joonisel 4.

Joonis 4. Java mudeli elemendid

Java mudel kasutab sama handle/body idiomi kui ressursside mudel (vt joonis 5). IJavaElement on handle ja JavaElementInfo mängib body rolli. IJavaElementi liides määratleb protokolli, mis on ühine kõigile Java elementidele. Mõned selle meetoditest on ainult handle-ettepanekud: getElementName(), getParent() jne. JavaElementInfo objekt salvestab vastava elemendi oleku: selle struktuuri ja atribuudid.

Joonis 5. IJavaElement ja JavaElementInfo

Java mudelil on mõned erinevused baseeruva handle/body disaini rakendamisel võrreldes ressursside mudeliga. Nagu ülalmainitud, on ressursside mudelis element tree, mille sõlmedeks on resource info objektid, täielikult mälus. Kuid Java mudelis võib elementide arv olla märkimisväärselt suurem kui ressursside puus, kuna seal on esindatud ka .java ja .class failide sisemine struktuur: tüübid, väljad ja meetodid.

Kuna vältida kogu elemendi puu materjaliseerimist mälu piiresse, kasutab Java mudeli implementatsioon piiratud suurusega LRU-vahemälu elementinfo jaoks, kus võtmena kasutatakse handle IJavaElementi. Elementinfo objekte luuakse nõudmisel, kui navigeeritakse elemendi puus. Selle käigus tõrjutakse kõige vähem sagedasti kasutatud elemendid vahemälust välja, hoides mudeli mälutarbimise määratud vahemälu suuruses. See on veel üks eelis handle-põhisele disainile, mis peidab neid teostuse detaile täielikult kliendikoodilt.

Java elementide muutmise teavitamise mehhanism on üldiselt sarnane ülaltoodud tööruumi ressursside muutuste jälgimise mehhanismile. Klient, kes soovib jälgida muutusi Java mudelis, registreerib end teavitustele, mis esitatakse ElementChangedEvent objekti vormis, mis sisaldab IJavaElementDelta't (joon. 6).

Joon. 6. ElementChangedEvent ja IJavaElementDelta

Java mudel ei sisalda teavet meetodite kehade või nimede lahendamise kohta, seetõttu pakub JDT Core täiendavat (mitte handle-põhist) mudelit Java koodianalüüsiks: abstraktne süntakspuu (abstraktne süntaksipuu, AST). AST esindab lähte teksti süntaksianalüüsi tulemust. AST sõlmed vastavad lähte mooduli struktuuri elementidele (deklaratsioonid, operaatorid, väljendid jne) ja sisaldavad teavet vastava elemendi koordinaatide kohta lähte tekstis ning (valikuliselt) teavet nimede lahendamise kohta viidete kujul niisugustele seosed. Sidemed on objektid, mis esindavad nimelisi entiteete, nagu tüübid, meetodid ja muutujad, mis on kompilaatorile teada. Erinevalt AST sõlmedest, mis moodustavad puu, toetavad sidemed ristviiteid ja üldiselt moodustavad graafi. Abstraktne klass ASTNode on kõigi AST sõlmede ühine baasklass. ASTNode alamklassid vastavad Java keele konkreetsetele süntaktilistele konstruktsioonidele.

Kuna süntaksipuud võivad tarbida märkimisväärselt palju mälu, salvestab JDT ainult ühe AST aktiivse redaktori jaoks. Erinevalt Java mudelist käsitletakse AST-d tavaliselt kui "vahe" või "ajutine" mudel, mille elementidele ei tohiks klientidel hoida viiteid väljaspool konteksti, mis viis AST loomisele.

Loetletud kolm mudelit (Java mudel, AST, sidemed) moodustavad koos „intelligentsete arendustööriistade” aluse JDT-s, sealhulgas võimas Java redaktor koos erinevate „abimeestega”, erinevad lähtekoodi töötlemise toimingud (sealhulgas nime importimise loendi korraldamine ja vormindamine vastavalt seatud stiilile), otsingutööriistad ja refaktoreerimise tööriistad. Samuti mängib Java mudel erilist rolli, kuna just seda kasutatakse arendatava rakenduse struktuuri visuaalse esitamise aluseks (näiteks Package Exploreris, Outline'is, Search'is, Call Hierarchy's ja Type Hierarchy's).

Eclipse'i komponendid, mida kasutatakse 1C:Enterprise Development Tools'is

Kujutisel 7 on näidatud Eclipse'i komponente, mis moodustavad 1C:Enterprise Development Tools'i tehnoloogilise platvormi aluse.

Kujutis 7. Eclipse platvormina 1C:Enterprise Development Tools'i jaoks

Eclipse Platvorm pakub põhistruktuuri. Oleme eelnevas jaotises arutanud selle infrastruktuuri mõningaid aspekte.

Eclipse Modelleerimise Raamistik (EMF) pakub üldisi vahendeid struktureeritud andmete modelleerimiseks. EMF on integreeritud Eclipse Platvormiga, kuid seda saab kasutada ka eraldi tavalistes Java rakendustes. Sage on see, et algajad Eclipse arendajad on juba EMF-iga hästi tuttavad, kuigi nad ei pruugi veel Eclipse Platvormi nüansse täielikult mõista. Üks põhjuseid, miks see on nii austatud, on universaalne disain, mis sisaldab ka ühtset metataseme API-d, mis võimaldab üldiselt töötada igasuguste EMF mudelitega. EMF-i pakutavad mudeli objektide põhiteostused ja mudeli koodigeneratsiooni alamsüsteem meta-mudelist suurendavad oluliselt arendamiskiirust ja vähendavad vigade arvu. Samuti sisaldab EMF mehhanisme mudelite serialiseerimiseks, mudeli muudatuste jälgimiseks ja palju muud.

Nagu igasugune tõeliselt universaalne tööriist, sobib EMF mitmesuguste modelleerimisega seotud ülesannete lahendamiseks, kuid mõned mudeliklassid (nt eespool käsitletud handle-põhised mudelid) võivad vajada spetsiifilisemaid modelleerimisvahendeid. EMF-st rääkida on tänamatu ülesanne, eriti ühe artikli piiratud raames, kuna see on eraldi raamatu teema ja üsna paks. Tuleb märkida, et kvaliteetne üldistuste süsteem, mis EMF-i aluseks on, on võimaldanud luua terve rea modelleerimise projekte, mis kuuluvad ülemise taseme projekti. Eclipse Modeling koos ise EMF-iga. Üks selline projekt on Eclipse Xtext.

Eclipse Xtext pakub „tekstimudeli” infrastruktuuri. Xtext kasutab ANTLR süntaktilise analüüsi jaoks algtekstist ja EMF tulemuse ASG (abstraktse semantilise graafiku, mis sisuliselt ühendab AST ja sidumised), mida nimetatakse ka "semantilise mudeliks". Xtext'i abil modelleeritud keele grammatika on kirjeldatud selle enda Xtext keeles. See võimaldab mitte ainult generaatori grammatika kirjeldust ANTLR-ile, vaid ka AST serialiseerimise mehhanismi (st Xtext pakub nii parserit kui unparserit), kontekstitundlikku vihjet ning mitmeid muid keelekomponente. Teiselt poolt on grammatika kirjeldamise keel, mida Xtext kasutab, vähem paindlik võrreldes näiteks ANTLR-i grammatika kirjeldamise keelega. Seetõttu tuleb mõnikord Xtext'i elluviimiseks "kõverdada" rakendatavat keelt, mis ei ole tavaliselt probleemiks, kui on tegemist nullist arendatava keelega, kuid võib olla vastuvõetamatu juba väljakujunenud süntaksiga keeltele. sellest hoolimata on Xtext praegu kõige küpsem, funktsionaalselt täielik ja universaalne tööriist Eclipse'is programmeerimiskeelte ja nende arendustööriistade ehitamiseks. Eriti sobib see kiire prototüüpimise jaoks. spetsiifiliste domeenide keeled (domain-specific language, DSL). Lisaks eelpool mainitud ANTLR-i ja EMF-i põhjalisele „keele tuumale” pakub Xtext palju kasulikke kõrgema taseme komponente, sealhulgas indekseerimise mehhanisme, inkrementaalset ehitust, „nutikat redaktorit” ja palju muud, kuid jätab kõrvale keele mudelid, mis põhinevad käepidemetel. Nagu EMF, on Xtext teema, mis väärib eraldi raamatut, ja me tõenäoliselt ei suuda isegi pinnapealselt rääkida kõikidest selle võimalustest.

1C:Enterprise Development Tools kasutavad aktiivselt nii EMF-i ennast kui ka mitmeid teisi Eclipse Modeling projekte. Eriti on Xtext üks peamisi arendustööriistu selliste 1C:Enterprise keelte jaoks nagu sisseehitatud programmeerimiskeel ja päringukeel. Teine selle arendustööriistade alus on projekt Eclipse Handly, millest me räägime lähemalt (kõikidest loetletud Eclipse komponentidest on see seni kõige vähem tuntud).

Eclipse Handly, alusprojekt kõrgtaseme projektile Eclipse Technology, tekkis 2014. aastal 1C ettevõtte algse koodikontributsiooni tulemusena Eclipse Foundationis. Sellest ajast alates jätkab firma 1C projekti arendamise toetamist: Handly committer’id on ettevõtte töötajad. Projekt on väike, kuid omab üsna ainulaadset nišši Eclipse’is: selle peamine eesmärk on toetada handle-põhiste mudelite arendamist.

Handle-põhiste mudelite peamised arhitektuurilised põhimõtted, nagu handle/body idiom, on varem arutatud ressursimudeli ja Java mudeli näitel. Seal märgiti, et nii ressursimudel kui Java mudel on olulised alused Eclipse Java arendustööriistade (JDT) jaoks. Kuna praktiliselt kõik Eclipse'i *DT projektid jagavad arhitektuuri JDT-ga, ei ole liialdus öelda, et handle-põhised mudelid on paljude, kui mitte kõikide Eclipse'i Platformi peal ehitatud IDE-de aluseks. Näiteks Eclipse C/C++ Development Tooling (CDT) sisaldab handle-põhist mudelit C/C++, mis mängib arhitektuuris CDT sama rolli, mida Java mudel JDT-s.

Enne Handly ilmumist ei pakkunud Eclipse spetsialiseeritud raamatukogusid käepidemepõhiste mudelite loomiseks. Olemasolevad mudelid loodi enamasti Java mudeli koodi otsese kohandamise kaudu (nt kopeerimine / kleepimine), kui see on lubatud Eclipse'i avaliku litsentsi (EPL) alusel. (On selge, et Eclipse'i enda projektide jaoks pole see tavaliselt juriidiliselt probleem, kuid see ei kehti suletud lähtekoodiga toodete kohta.) Lisaks iseloomulikule süsteemitusle toob selline meetod kaasa hästi tuntud probleemid: koodi dubleerimise, kohandamise käigus sisse toodud vead jne. Mis veelgi hullem, saadud mudelid jäävad "asjaks endas" ega kasuta olemasolevat potentsiaali ühtlustamiseks. Nimelt võiks käepidemepõhiste mudelite jaoks üldiste mõistete ja protokollide eristamine viia korduvkasutatavate komponendi loomisele, nagu see juhtus EMF-i puhul.

Ei saa öelda, et Eclipse'is ei oleks neid probleeme mõistetud. Juba 2005. aastal Martin Aeschlimann, kokku võttes CDT prototüübi arendamise kogemust, argumenteeris keelemudelite, sealhulgas handle-põhiste mudelite, ühise infrastruktuuri loomise vajadus. Kuid nagu sageli juhtub, jäi nende ideede elluviimine sagedamate ülesannete tõttu lõpuks tegemata. Vahepeal jääb koodi faktoreerimine *DT-projektide seas endiselt ühel halvasti arendatud teemal Eclipse'is.

Teatud mõttes on projekt Handly suunatud sarnastele ülesannetele nagu EMF, kuid handle-põhiste mudelite jaoks, eelkõige keeleliseks (st programmeerimiskeele struktuurielemente esindavaks). Allpool on loetletud peamised eesmärgid, mis seati Handly projekteerimisel:

• Peamiste valdkonnaabstraktsioonide eristamine.
• Keeltestrateegiate handle-põhiste mudelite rakendamise pingutuste vähendamine ja kvaliteedi tõstmine koodi taaskasutamise kaudu.
• Ühtse API pakkumine, mis tagab meta-taseme tulemuseks olevate mudelite, mis võimaldab luua ühiseid IDE komponente, mis töötavad keele handle-põhiste mudelitega.
• Paindlikkus ja skalaarne lahendus.
• Integratsioon Xtextiga (eraldi kihina).

Ühiskontseptsioonide ja protokollide esile tõstmiseks on analüüsitud olemasolevaid keele-baasil mudeleid. Peamised liidesed ja põhiimplementatsioonid, mida Handly pakub, on nähtavad joonisel 8.

Joonis 8. Ühised liidesed ja põhiimplementatsioonid Handly elementide jaoks

IElement liides esindab elemendi handle'it ja on ühine kõigi Handly-põhiste mudelite elementide jaoks. Abstraktne klass Element rakendab üldist handle/body mehhanismi (joonis 9).

Joonis 9. IElement ja üldine handle/body rakendus

Lisaks pakub Handly üldist mehhanismi mudeli elementide muudatustest teavitamiseks (joonis 10). Nagu näha, sarnaneb see üldjoontes ressursside mudeli ja Java-mudeli teavitamismehanismidega ning kasutab IElementDelta'd, et esitada teavet elemendi muudatuste kohta ühtselt.

Joonis 10. Ühised liidesed ja põhiimplementatsioonid Handly teavitamismehhanismi jaoks

Ülaltoodud Handly osa (joonised 9 ja 10) võib kasutada praktiliselt kõigi handle-põhiste mudelite esindamiseks. Loome keeleseid mudelid pakuvad täiendavaid funktsioone – eelkõige üldisi liideseid ja baasilahendusi algteksti struktuuri elementide jaoks, nii-öelda allikaelemendid (joonis 8). ISourceFile liides esindab algfaili, samas kui ISourceConstruct on element algfailis. Abstraktsed klassid SourceFile ja SourceConstruct rakendavad üldisi mehhanisme algfailide ja nende elementidega töötamiseks, näiteks tekstipuhvereid, elemendi seotust algteksti koordinaatidega, mudelite kooskõlastamist töötava koopia praeguse sisu üle jne. Nende mehhanismide rakendamine on tavaliselt üsna keeruline ülesanne, ning Handly võib oluliselt vähendada keelepõhiste mudelite arendamiseks vajalikku vaeva, pakkudes kvaliteetseid baasilahendusi.

Lisaks ülaltoodud peamistele mehhanismidele pakub Handly tekstivaru ja "snapshootide" infrastruktuuri, toetust integreerimiseks lähtekoodi redaktoritega (sealhulgas "kastist väljas" integreerimine Xtext redaktoriga) ning mõned üldised UI-komponendid, mis töötavad Handly mudelitega, nagu outline framework. Oma võimaluste illustreerimiseks esitab projekt mitmeid näiteid, sealhulgas Java mudeli rakenduse Handly-l. (Võrreldes Java-mudeli täieliku rakendusega JDT-s, on see mudel tahtlikult veidi lihtsustatud, et tagada paremat arusaadavust.)

Nagu eelnevalt mainitud, on Handly algse projekteerimise ja edasise arendamise käigus suurenenud tähelepanu pööratud skaleeritavusele ja paindlikkusele.

Tegelikult on handle-põhised mudelid „disainilt” piisavalt hästi skaleeritavad. Näiteks võimaldab handle/body idiom piirata mudeli mälutarbimist. Kuid on ka nüansse. Näiteks tootlikkuse testimisel avastati Handly skaleeritavuses probleem, mis oli seotud teavitamise mehhanismi rakendamisega – kui muudeti suurt hulka elemente, võttis deltasid koostamine liiga kaua aega. Selgus, et sama probleem oli olemas ka Java-mudelis JDT, millest vastav kood omal ajal kohandatud oli. Parandasime Handly vead ja ettevalmistatud sarnane plaastr JDT jaoks, mis võeti tänuga vastu. See on vaid üks näide, kus Handly kasutuselevõtt olemasolevates mudelites võiks potentsiaalselt kasulik olla, kuna sellise vea saaks sel juhul parandada vaid ühes kohas.

Kuna Handly sisseviimine olemasolevates mudelites oleks tehniliselt võimalik, peab teek olema piisavalt paindlik. Peamine probleem on säilitada mudeli API tagurpidi ühilduvus. See ülesanne on lahendatud Handly 0.5 mudeli API spetsiifilise selge eristamise kaudu, mida määratleb ja kontrollib täielikult arendaja, ning ühise taseme API kaudu, mida pakub raamatukogu. See mitte ainult ei võimalda tehniliselt Handly integreerimist olemasolevatesse rakendustesse, vaid annab ka uue mudeli arendajale märkimisväärse vabaduse API projekteerimisel.

Paindlikkusel on ka teised aspektid. Näiteks ei kehtesta Handly mingeid piiranguid mudeli struktuurile ja seda saab kasutada nii üldotstarbeliste kui ka spetsialiseeritud keelte modelleerimiseks. Algfaili struktuuri ehitamisel ei nõua Handly mingit kindlat AST esitamise vormi ja ei nõua isegi AST olemasolu, pakkudes seega ühilduvust praktiliselt igasuguste süntaksianalüüsi mehhanismidega. Lõpuks toetab Handly täielikku integratsiooni Eclipse'i töökeskkonnaga, kuid võib samuti töötada otse failisüsteemidega, tänu integratsioonile Eclipse'i failisüsteem (EFS).

Praegune versioon Handly 0.6 ilmus 2016. aasta detsembris. Kuigi projekt on praegu inkubeerimise faasis ja API ei ole lõplikult kindlaks määratud, kasutatakse Handlyt juba kahel suurel kommertstootel, mis julgesid astuda "varajaste omaks võtjate" ritta, ja peame ütlema, et nad ei kahetse seda.

Nagu eelnevalt mainitud, on üks nende toodetest – 1C:Enterprise Development Tools, kus Handlyt kasutatakse algusest peale 1C:Ettevõtte kõrgema taseme struktuurielementide modelleerimiseks, sealhulgas sisseehitatud programmeerimiskeele ja päringute keele jaoks. Teine toode on laiemale publikule vähem tuntud. See on Codasip Studio, probleemide lahendamisele suunatud protsessorite integreeritud disainikeskkond (application-specific instruction-set processor, ASIP), mida kasutatakse nii Tšehhi ettevõttes Codasip sees kui ka tema klientide seas, nende hulgas AMD, AVG, Mobileye, Sigma Designs. Codasip kasutab Handly't tootmises alates 2015. aastast, alustades versioonist Handly 0.2. Viimane praegu saadaval olev versioon Codasip Studio's kasutab versiooni 0.5, mis ilmus juunis 2016. Ondřej Ilčík, kes juhib IDE arendust Codasipis, on projektiga pidevalt kontaktis, pakkudes äärmiselt olulist tagasisidet «kolmanda osapoole adopteerijatelt». Ta leidis isegi natuke vaba aega, et otseselt osaleda projekti arendamisel, luues UI kihi (~ 4000 rida koodi) ühe Handly näite, Java mudeli, jaoks. Täiendavat teavet «esimese käe» kasutamise kohta Handly adopteerijatelt saab leida lehelt Edu lood projekti.

Loodame, et pärast versiooni 1.0 väljalaskmist, mis tagab API stabiilsuse, ja projekti inkubatsioonist väljumist, tuleb Handly'le ka uusi adaptereid. Seni jätkab projekt API katsetamist ja edasist täiustamist, andes välja kaks „suur“ versiooni aastas – juunis (sama kuupäeval, mil toimub samaaegne Eclipse'i väljaanne) ja detsembris, tagades ennustatavad ajakavad, millele adapterid võivad toetuda. Samuti võib lisada, et projekti „vea määr“ püsib pidevalt madalal tasemel ja Handly töötab usaldusväärselt varajaste kasutajate toodetes alates esimestest versioonidest. Eclipse Handly'ga edasise tutvumise jaoks saab kasutada Alustamise Õpetus ja Arhitektuuri Ülevaade.

Allikas: habr.com