Efallai, ers amser maith nid oes angen cyflwyniad arbennig. Mae llawer o bobl yn gyfarwydd ag Eclipse diolch i offer datblygu Java Eclipse (). Y IDE Java ffynhonnell agored boblogaidd hon y mae'r rhan fwyaf o ddatblygwyr yn ei gysylltu â'r gair “Eclipse”. Fodd bynnag, mae Eclipse yn blatfform estynadwy ar gyfer integreiddio offer datblygu (Platfform Eclipse), a nifer o DRhA wedi'u hadeiladu ar ei sail, gan gynnwys JDT. Eclipse yw'r Prosiect Eclipse, y prosiect lefel uchaf sy'n cydlynu datblygiad y Platfform Eclipse a'r JDT, a'r Eclipse SDK, sef canlyniad y datblygiad hwnnw. Yn olaf, mae Eclipse yn Sefydliad ffynhonnell agored gyda chymuned enfawr o brosiectau, nad yw pob un ohonynt wedi'u hysgrifennu yn Java nac yn gysylltiedig ag offer datblygu (er enghraifft, prosiectau и ). Mae byd Eclipse yn amrywiol iawn.
Yn yr erthygl hon, sy'n drosolwg ei natur, byddwn yn ceisio edrych ar rai o hanfodion pensaernïaeth Eclipse fel llwyfan ar gyfer adeiladu offer datblygu integredig a rhoi syniad cychwynnol o'r cydrannau Eclipse sy'n ffurfio sylfaen y dechnoleg llwyfan ar gyfer y “Configurator newydd” 1C: Menter. . Wrth gwrs, mae'n anochel y bydd adolygiad o'r fath yn arwynebol i raddau helaeth ac yn gyfyngedig braidd, gan gynnwys oherwydd ein bod yn canolbwyntio nid yn unig ar ddatblygwyr Eclipse fel y gynulleidfa darged. Fodd bynnag, rydym yn gobeithio y bydd hyd yn oed datblygwyr profiadol Eclipse yn gallu dod o hyd i wybodaeth ddiddorol yn yr erthygl. Er enghraifft, byddwn yn siarad am un o “gyfrinachau Eclipse”, prosiect cymharol newydd ac anhysbys. , a sefydlwyd ac a gefnogwyd gan 1C.
Cyflwyniad i Bensaernïaeth Eclipse
Edrychwn yn gyntaf ar rai agweddau cyffredinol ar bensaernïaeth Eclipse gan ddefnyddio'r enghraifft (JDT). Nid yw'r dewis o JDT fel enghraifft yn ddamweiniol. Dyma'r amgylchedd datblygu integredig cyntaf i ymddangos yn Eclipse. Crëwyd prosiectau *DT Eclipse eraill, megis Eclipse C/C++ Development Tooling (CDT), yn ddiweddarach ac maent yn benthyca egwyddorion pensaernïol sylfaenol a darnau cod ffynhonnell unigol gan JDT. Mae hanfodion y bensaernïaeth a nodir yn JDT yn berthnasol hyd heddiw ar gyfer bron unrhyw DRhA a adeiladwyd ar ben y Llwyfan Eclipse, gan gynnwys 1C: Offer Datblygu Menter.
Yn gyntaf oll, dylid nodi bod haeniad pensaernïol eithaf clir yn nodweddu Eclipse, gyda gwahanu ymarferoldeb iaith-annibynnol oddi wrth ymarferoldeb a gynlluniwyd i gefnogi ieithoedd rhaglennu penodol, a gwahanu cydrannau “craidd” UI-annibynnol oddi wrth gydrannau cysylltiedig. gyda rhyngwyneb defnyddiwr ategol.
Felly, mae'r Llwyfan Eclipse yn diffinio seilwaith cyffredin, sy'n annibynnol ar iaith, ac mae'r offer datblygu Java yn ychwanegu IDE Java llawn sylw at Eclipse. Mae'r Llwyfan Eclipse a'r JDT yn cynnwys sawl cydran, pob un ohonynt yn perthyn i naill ai “craidd” UI-annibynnol neu haen UI (Ffigur 1).
Reis. 1. Llwyfan Eclipse a JDT
Gadewch i ni restru prif gydrannau'r Llwyfan Eclipse:
- Amser Cinio - Yn diffinio'r seilwaith ategyn. Nodweddir Eclipse gan bensaernïaeth fodiwlaidd. Yn y bôn, mae Eclipse yn gasgliad o "bwyntiau ymestyn" ac "estyniadau".
- Gweithle — Yn rheoli un neu fwy o brosiectau. Mae prosiect yn cynnwys ffolderi a ffeiliau sy'n cael eu mapio'n uniongyrchol i'r system ffeiliau.
- Pecyn Cymorth Widget Safonol (SWT) - Yn darparu elfennau rhyngwyneb defnyddiwr sylfaenol wedi'u hintegreiddio â'r system weithredu.
- JGwyneb — Yn darparu nifer o fframweithiau UI wedi'u hadeiladu ar ben SWT.
- Workbench — Yn diffinio patrwm UI Eclipse: golygyddion, safbwyntiau, safbwyntiau.
Rhaid dweud bod y Llwyfan Eclipse hefyd yn darparu llawer o gydrannau defnyddiol eraill ar gyfer adeiladu offer datblygu integredig, gan gynnwys Debug, Compare, Search, a Team. Dylid cyfeirio'n arbennig at JFace Text - y sail ar gyfer adeiladu “golygyddion craff” cod ffynhonnell. Yn anffodus, nid yw hyd yn oed archwiliad brysiog o'r cydrannau hyn, yn ogystal â'r cydrannau haen UI, yn bosibl o fewn cwmpas yr erthygl hon, felly yng ngweddill yr adran hon byddwn yn cyfyngu ein hunain i drosolwg o'r prif gydrannau "craidd" o yr Eclipse Platform a JDT.
Amser Rhedeg Craidd
Mae seilwaith ategyn Eclipse yn seiliedig ar ac a ddarperir gan y prosiect . Mae pob ategyn Eclipse yn fwndel OSGi. Mae manyleb OSGi yn diffinio, yn benodol, fecanweithiau ar gyfer fersiwn a datrys dibyniaeth. Yn ogystal â'r mecanweithiau safonol hyn, mae Equinox yn cyflwyno'r cysyniad pwyntiau ehangu. Gall pob ategyn ddiffinio ei bwyntiau estyn ei hun, a hefyd gyflwyno ymarferoldeb ychwanegol ("estyniadau") i'r system gan ddefnyddio pwyntiau estyn a ddiffinnir gan yr un ategion neu ategion eraill. Mae unrhyw ddisgrifiad manwl o fecanweithiau OSGi ac Equinox y tu hwnt i gwmpas yr erthygl hon. Gadewch inni ond nodi bod modiwleiddio yn Eclipse yn gyfanswm (mae unrhyw is-system, gan gynnwys Runtime, yn cynnwys un neu fwy o ategion), ac mae bron popeth yn Eclipse yn estyniad. Ar ben hynny, roedd yr egwyddorion hyn wedi'u hymgorffori ym mhensaernïaeth Eclipse ymhell cyn cyflwyno OSGi (ar y pryd roedden nhw'n defnyddio eu technoleg eu hunain, yn debyg iawn i OSGi).
Gweithle Craidd
Mae bron unrhyw amgylchedd datblygu integredig a adeiladwyd ar ben y Llwyfan Eclipse yn gweithio gyda gweithle Eclipse. Y man gwaith sydd fel arfer yn cynnwys cod ffynhonnell y rhaglen a ddatblygwyd yn y DRhA. Mae gweithleoedd yn mapio'n uniongyrchol i'r system ffeiliau ac yn cynnwys prosiectau, sy'n cynnwys ffolderi a ffeiliau. Gelwir y prosiectau, y ffolderi a'r ffeiliau hyn adnoddau man gwaith. Mae gweithredu'r gweithle yn Eclipse yn storfa mewn perthynas â'r system ffeiliau, sy'n ei gwneud hi'n bosibl cyflymu'r broses o groesi'r goeden adnoddau yn sylweddol. Yn ogystal, mae man gwaith yn darparu nifer o wasanaethau ychwanegol, gan gynnwys и .
Mae'r gydran Adnoddau Craidd (ategyn org.eclipse.core.resources) yn gyfrifol am gefnogi'r gweithle a'i adnoddau. Yn benodol, mae'r gydran hon yn darparu mynediad rhaglennol i'r gweithle yn y ffurflen modelau adnoddau. Er mwyn gweithio'n effeithiol gyda'r model hwn, mae cleientiaid angen ffordd syml o gyflwyno dolen i adnodd. Yn yr achos hwn, byddai'n ddymunol cuddio'r gwrthrych sy'n storio cyflwr yr adnodd yn y model yn uniongyrchol rhag mynediad cleientiaid. Fel arall, yn achos, er enghraifft, dileu ffeil, gallai'r cleient barhau i ddal gwrthrych nad yw bellach yn y model, gyda'r problemau dilynol. Mae Eclipse yn datrys y broblem hon gan ddefnyddio rhywbeth o'r enw trin adnodd. Mae handle yn gweithredu fel allwedd (dim ond y llwybr i'r adnodd yn y gweithle y mae'n ei wybod) ac mae'n rheoli mynediad i'r gwrthrych model mewnol yn llwyr, sy'n storio gwybodaeth yn uniongyrchol am gyflwr yr adnodd. Mae'r dyluniad hwn yn amrywiad o'r patrwm .
Reis. Mae Ffigur 2 yn dangos yr idiom Handle/Corff fel y'i cymhwysir i'r model adnoddau. Mae rhyngwyneb IResource yn cynrychioli handlen adnodd ac mae'n API, yn wahanol i'r dosbarth Adnoddau, sy'n gweithredu'r rhyngwyneb hwn, a'r dosbarth ResourceInfo, sy'n cynrychioli'r corff, nad ydynt yn APIs. Rydym yn pwysleisio mai dim ond y llwybr i'r adnodd sy'n cael ei adnabod o'i gymharu â gwraidd y man gwaith ac nad yw'n cynnwys dolen i wybodaeth am adnoddau. Mae gwrthrychau gwybodaeth adnoddau yn ffurfio “coeden elfen” fel y'i gelwir. Mae'r strwythur data hwn wedi'i wireddu'n llwyr yn y cof. I ddod o hyd i'r enghraifft gwybodaeth adnoddau sy'n cyfateb i handlen, mae'r goeden elfen yn cael ei chroesi yn ôl y llwybr sydd wedi'i storio yn yr handlen honno.
Reis. 2. IResource ac ResourceInfo
Fel y byddwn yn gweld yn ddiweddarach, mae dyluniad sylfaenol y model adnoddau (efallai y byddwn yn ei alw'n seiliedig ar handlen) yn cael ei ddefnyddio yn Eclipse ar gyfer modelau eraill hefyd. Am y tro, gadewch i ni restru rhai o briodweddau nodedig y dyluniad hwn:
- Mae handle yn wrthrych gwerth. Mae gwrthrychau gwerth yn wrthrychau digyfnewid nad yw eu cydraddoldeb yn seiliedig ar hunaniaeth. Gellir defnyddio gwrthrychau o'r fath yn ddiogel fel allwedd mewn cynwysyddion stwnsh. Gall achosion lluosog o ddolen gyfeirio at yr un adnodd. Er mwyn eu cymharu, mae angen i chi ddefnyddio'r dull hafal (Gwrthrych).
- Mae Handle yn diffinio ymddygiad adnodd, ond nid yw'n cynnwys gwybodaeth am gyflwr yr adnodd (yr unig ddata y mae'n ei storio yw'r "allwedd", y llwybr i'r adnodd).
- Gall Handle gyfeirio at adnodd nad yw'n bodoli (naill ai adnodd nad yw wedi'i greu eto, neu adnodd sydd eisoes wedi'i ddileu). Gellir gwirio bodolaeth adnodd gan ddefnyddio'r dull IResource.exists().
- Gellir gweithredu rhai gweithrediadau yn seiliedig yn unig ar wybodaeth sydd wedi'i storio yn yr handlen ei hun (gweithrediadau trin yn unig fel y'u gelwir). Enghreifftiau yw IResource.getParent(), getFullPath(), ac ati. Nid oes angen i'r adnodd fodoli er mwyn i weithrediad o'r fath lwyddo. Mae gweithrediadau sydd angen adnodd i fodoli i lwyddo yn taflu CoreException os nad yw'r adnodd yn bodoli.
Mae Eclipse yn darparu mecanwaith effeithlon ar gyfer hysbysu newidiadau i adnoddau gweithleoedd (Ffigur 3). Gall adnoddau newid naill ai o ganlyniad i weithredoedd a gyflawnir o fewn y DRhA Eclipse ei hun neu o ganlyniad i gydamseru â'r system ffeiliau. Yn y ddau achos, mae cleientiaid sy'n tanysgrifio i hysbysiadau yn cael gwybodaeth fanwl am y newidiadau ar ffurf “resource deltas”. Mae delta yn disgrifio newidiadau rhwng dau gyflwr coeden adnodd gweithle (is) ac mae ei hun yn goeden, gyda phob nod yn disgrifio newid i adnodd ac yn cynnwys rhestr o ddeltâu ar y lefel nesaf sy'n disgrifio newidiadau i adnoddau plant.
Reis. 3. IResourceChangeEvent ac IResourceDelta
Mae gan y mecanwaith hysbysu sy'n seiliedig ar deltas adnoddau y nodweddion canlynol:
- Disgrifir un newid a llawer o newidiadau gan ddefnyddio'r un strwythur, gan fod y delta wedi'i adeiladu gan ddefnyddio'r egwyddor o gyfansoddiad ailadroddus. Gall cleientiaid sy'n tanysgrifio brosesu hysbysiadau newid adnoddau gan ddefnyddio disgyniad ailadroddus trwy goeden o ddeltâu.
- Mae'r delta yn cynnwys gwybodaeth gyflawn am newidiadau i'r adnodd, gan gynnwys ei symudiad a/neu newidiadau yn y “marcwyr” sy'n gysylltiedig ag ef (er enghraifft, mae gwallau crynhoi yn cael eu cynrychioli fel marcwyr).
- Gan fod cyfeiriadau at adnoddau yn cael eu gwneud trwy'r handlen, gall delta gyfeirio'n naturiol at adnodd anghysbell.
Fel y byddwn yn gweld yn fuan, mae prif gydrannau dyluniad y mecanwaith hysbysu newid model adnoddau hefyd yn berthnasol ar gyfer modelau eraill sy'n seiliedig ar handlen.
Craidd JDT
Mae model adnoddau gweithle Eclipse yn fodel iaith-agnostig sylfaenol. Mae cydran JDT Core (plugin org.eclipse.jdt.core) yn darparu API ar gyfer llywio a dadansoddi strwythur y gweithle o safbwynt Java, yr hyn a elwir yn “model Java” (Model Java). Mae'r API hwn wedi'i ddiffinio yn nhermau elfennau Java, yn hytrach na'r model adnodd sylfaenol API, a ddiffinnir yn nhermau ffolderi a ffeiliau. Dangosir prif ryngwynebau'r goeden elfen Java yn Ffig. 4.
Reis. 4. Elfennau Model Java
Mae'r model Java yn defnyddio'r un idiom handlen/corff â'r model adnoddau (Ffigur 5). IJavaElement yw'r handlen, ac mae JavaElementInfo yn chwarae rôl y corff. Mae rhyngwyneb IJavaElement yn diffinio protocol sy'n gyffredin i bob elfen Java. Mae rhai o'i ddulliau yn ymdrin â llaw yn unig: getElementName(), getParent(), ac ati. Mae gwrthrych JavaElementInfo yn storio cyflwr yr elfen gyfatebol: ei strwythur a'i nodweddion.
Reis. 5. IJavaElement a JavaElementInfo
Mae gan fodel Java rai gwahaniaethau yng ngweithrediad y cynllun handlen/corff sylfaenol o gymharu â'r model adnoddau. Fel y nodwyd uchod, yn y model adnoddau, mae'r goeden elfen, y mae ei nodau yn wrthrychau gwybodaeth adnoddau, wedi'i chynnwys yn gyfan gwbl yn y cof. Ond gall y model Java fod â nifer sylweddol fwy o elfennau na'r goeden adnoddau, oherwydd ei fod hefyd yn cynrychioli strwythur mewnol ffeiliau .java a .class: mathau, meysydd, a dulliau.
Er mwyn osgoi gwireddu'r goeden gyfan o elfennau yn gyfan gwbl yn y cof, mae gweithrediad model Java yn defnyddio storfa LRU maint cyfyngedig o wybodaeth elfen, lle mae'r allwedd yn handlen IJavaElement. mae gwrthrychau gwybodaeth elfen yn cael eu creu ar alw wrth i'r goeden elfen gael ei llywio. Yn yr achos hwn, mae'r eitemau a ddefnyddir leiaf yn cael eu troi allan o'r storfa, ac mae defnydd cof y model yn parhau i fod yn gyfyngedig i'r maint storfa penodedig. Mae hyn yn fantais arall o ddylunio sy'n seiliedig ar handlen, sy'n cuddio manylion gweithredu o'r fath yn llwyr o'r cod cleient.
Mae'r mecanwaith ar gyfer hysbysu newidiadau i elfennau Java yn gyffredinol debyg i'r mecanwaith ar gyfer olrhain newidiadau i adnoddau gweithle a drafodwyd uchod. Mae cleient sy'n dymuno monitro newidiadau yn y model Java yn tanysgrifio i hysbysiadau, sy'n cael eu cynrychioli fel gwrthrych ElementChangedEvent sy'n cynnwys IJavaElementDelta (Ffigur 6).
Reis. 6. ElementChangedEvent ac IJavaElementDelta
Nid yw'r model Java yn cynnwys gwybodaeth am gyrff dull neu ddatrysiad enwau, felly ar gyfer dadansoddiad manwl o'r cod a ysgrifennwyd yn Java, mae JDT Core yn darparu model ychwanegol (nad yw'n seiliedig ar ddolen): (coeden gystrawen haniaethol, AST). Mae AST yn cynrychioli canlyniad dosrannu'r testun ffynhonnell. Mae nodau AST yn cyfateb i elfennau o strwythur y modiwl ffynhonnell (datganiadau, gweithredwyr, ymadroddion, ac ati) ac yn cynnwys gwybodaeth am gyfesurynnau'r elfen gyfatebol yn y testun ffynhonnell, yn ogystal ag (fel opsiwn) gwybodaeth am ddatrysiad enw yn ffurf y dolenni i'r hyn a elwir rhwymiadau. Mae rhwymiadau yn wrthrychau sy'n cynrychioli endidau a enwir, megis mathau, dulliau, a newidynnau, sy'n hysbys i'r casglwr. Yn wahanol i nodau AST, sy'n ffurfio coeden, mae rhwymiadau yn cefnogi croesgyfeirio ac yn gyffredinol yn ffurfio graff. Y dosbarth haniaethol ASTNode yw'r dosbarth sylfaen cyffredin ar gyfer pob nod AST. Mae is-ddosbarthiadau ASTNode yn cyfateb i luniadau cystrawennol penodol o'r iaith Java.
Oherwydd bod coed cystrawen yn gallu defnyddio cryn dipyn o gof, mae JDT yn cadw un AST yn unig ar gyfer y golygydd gweithredol. Yn wahanol i'r model Java, mae'r AST fel arfer yn cael ei ystyried yn fodel "canolradd," "dros dro" na ddylai ei aelodau gael eu dal gan gleientiaid y tu allan i gyd-destun y gweithrediad a arweiniodd at greu'r AST.
Mae'r tri model rhestredig (model Java, AST, rhwymiadau) gyda'i gilydd yn sail ar gyfer adeiladu “offer datblygu deallus” yn JDT, gan gynnwys golygydd Java pwerus gydag amrywiol “gynorthwywyr”, gweithredoedd amrywiol ar gyfer prosesu cod ffynhonnell (gan gynnwys trefnu rhestr o fewnforion enwau a fformatio yn ôl yr arddull addasu), chwilio ac ailffactorio offer. Yn yr achos hwn, mae'r model Java yn chwarae rhan arbennig, gan mai hwn sy'n cael ei ddefnyddio fel sail ar gyfer cynrychiolaeth weledol o strwythur y cymhwysiad sy'n cael ei ddatblygu (er enghraifft, yn Package Explorer, Amlinelliad, Chwilio, Hierarchaeth Galwadau, a Hierarchaeth Math).
Cydrannau Eclipse a ddefnyddir yn 1C: Offer Datblygiadau Menter
Yn Ffig. Mae Ffigur 7 yn dangos y cydrannau Eclipse sy'n ffurfio sylfaen y llwyfan technoleg ar gyfer 1C: Offer Datblygu Menter.
Reis. 7. Eclipse fel llwyfan ar gyfer 1C:Enterprise Development Tools
Llwyfan Eclipse darparu seilwaith sylfaenol. Edrychwyd ar rai agweddau ar y seilwaith hwn yn yr adran flaenorol.
(EMF) yn darparu dull cyffredinol o fodelu data strwythuredig. Mae EMF wedi'i integreiddio â'r Llwyfan Eclipse, ond gellir ei ddefnyddio ar wahân hefyd mewn cymwysiadau Java rheolaidd. Yn aml iawn, mae datblygwyr Eclipse newydd eisoes yn gyfarwydd iawn ag EMF, er nad ydynt eto'n deall cymhlethdodau Platfform Eclipse yn llawn. Un o'r rhesymau dros boblogrwydd mor haeddiannol yw'r dyluniad cyffredinol, sy'n cynnwys, ymhlith pethau eraill, API lefel meta unedig, sy'n eich galluogi i weithio gydag unrhyw fodel EMF mewn ffordd gyffredinol. Mae'r gweithrediadau sylfaenol ar gyfer gwrthrychau model a ddarperir gan EMF a'r is-system ar gyfer cynhyrchu cod model yn seiliedig ar y meta-fodel yn cynyddu cyflymder datblygiad yn sylweddol ac yn lleihau nifer y gwallau. Mae EMF hefyd yn cynnwys mecanweithiau ar gyfer cyfresoli modelau, olrhain newidiadau i'r model, a llawer mwy.
Fel unrhyw offeryn pwrpas cyffredinol gwirioneddol, mae EMF yn addas ar gyfer datrys ystod eang o broblemau modelu, ond efallai y bydd angen offer modelu mwy arbenigol ar rai dosbarthiadau o fodelau (er enghraifft, y modelau sy'n seiliedig ar ddolen a drafodwyd uchod). Mae siarad am EMF yn dasg ddiddiolch, yn enwedig o fewn cyfyngiadau cyfyngedig un erthygl, gan fod hon yn destun llyfr ar wahân, ac un eithaf trwchus. Gadewch inni ond nodi bod y system ansawdd uchel o gyffredinoli sy'n sail i'r EMF wedi caniatáu genedigaeth ystod gyfan o brosiectau sy'n ymroddedig i fodelu, sydd wedi'u cynnwys yn y prosiect lefel uchaf. ynghyd â'r EMF ei hun. Un prosiect o'r fath yw Eclipse Xtext.
yn darparu seilwaith "modelu testun". Defnyddiau Xtext ar gyfer dosrannu'r testun ffynhonnell ac EMF ar gyfer cynrychioli'r ASG canlyniadol (graff semantig haniaethol, sydd yn ei hanfod yn gyfuniad o AST a rhwymiadau), a elwir hefyd yn “fodel semantig”. Disgrifir gramadeg yr iaith a fodelwyd gan Xtext yn iaith Xtext ei hun. Mae hyn yn eich galluogi nid yn unig i gynhyrchu disgrifiad gramadeg ar gyfer ANTLR, ond hefyd i gael mecanwaith cyfresoli AST (h.y. mae Xtext yn darparu parser a dad-ddarparwr), awgrym cyd-destun, a nifer o gydrannau iaith eraill. Ar y llaw arall, mae'r iaith ramadeg a ddefnyddir yn Xtext yn llai hyblyg na, dyweder, yr iaith ramadeg a ddefnyddir yn ANTLR. Felly, weithiau mae angen “plygu” yr iaith a weithredir i Xtext, sydd fel arfer ddim yn broblem os ydym yn sôn am iaith yn cael ei datblygu o’r newydd, ond a allai fod yn annerbyniol ar gyfer ieithoedd sydd â chystrawen sydd eisoes wedi’i sefydlu. Er gwaethaf hyn, Xtext ar hyn o bryd yw'r offeryn mwyaf aeddfed, nodwedd-gyflawn, a phwrpas cyffredinol yn Eclipse ar gyfer adeiladu ieithoedd rhaglennu ac offer datblygu ar eu cyfer. Yn benodol, mae'n offeryn delfrydol ar gyfer prototeipio cyflym (iaith parth-benodol, DSL). Yn ogystal â’r “craidd iaith” uchod sy’n seiliedig ar ANTLR ac EMF, mae Xtext yn darparu llawer o gydrannau lefel uwch defnyddiol, gan gynnwys mecanweithiau mynegeio, adeiladu cynyddrannol, “golygydd craff”, a llawer, llawer mwy, ond yn gadael allan handle- modelau iaith seiliedig. Fel EMF, mae Xtext yn bwnc sy'n deilwng o lyfr ar wahân, a phrin y gallwn hyd yn oed siarad yn fyr am ei holl alluoedd ar hyn o bryd.
Mae 1C:Enterprise Development Tools yn defnyddio EMF ei hun a nifer o brosiectau Modelu Eclipse eraill. Yn benodol, Xtext yw un o'r sylfeini offer datblygu ar gyfer 1C:Ieithoedd Menter o'r fath fel yr iaith raglennu adeiledig ac iaith ymholiad. Sail arall ar gyfer yr offer datblygu hyn yw'r prosiect Eclipse Handly, y byddwn yn ei drafod yn fanylach (o'r cydrannau Eclipse a restrir, dyma'r lleiaf hysbys o hyd).
, is-brosiect o brosiect lefel uchaf Eclipse Technology, i’r amlwg o ganlyniad i gyfraniad cod cychwynnol i Sefydliad Eclipse a wnaed gan 1C yn 2014. Ers hynny, mae 1C wedi parhau i gefnogi datblygiad y prosiect: Mae ymroddwyr Handly yn weithwyr i'r cwmni. Mae'r prosiect yn fach, ond mae'n meddiannu cilfach eithaf unigryw yn Eclipse: ei brif nod yw cefnogi datblygiad modelau sy'n seiliedig ar handlen.
Trafodwyd egwyddorion pensaernïol sylfaenol modelau sy'n seiliedig ar handlen, megis idiom handlen/corff, uchod gan ddefnyddio'r model adnoddau a'r model Java fel enghreifftiau. Nododd hefyd fod y model adnoddau a'r model Java yn sylfeini pwysig ar gyfer offer datblygu Eclipse Java (JDT). A chan fod gan bron bob un o'r prosiectau * DT Eclipse bensaernïaeth debyg i JDT, ni fyddai'n or-ddweud mawr i ddweud bod modelau sy'n seiliedig ar handlen yn sail i lawer o DRhA, os nad pob un, sydd wedi'u hadeiladu ar ben y Llwyfan Eclipse. Er enghraifft, mae gan yr Eclipse C/C++ Development Tooling (CDT) fodel C/C++ wedi'i seilio ar ddolen sy'n chwarae'r un rôl ym mhensaernïaeth CDT ag sydd gan y model Java yn y JDT.
Cyn Handly, nid oedd Eclipse yn cynnig llyfrgelloedd arbenigol ar gyfer adeiladu modelau iaith yn seiliedig ar ddolenni. Crëwyd y modelau sy'n bodoli ar hyn o bryd yn bennaf trwy addasu cod model Java yn uniongyrchol (aka copi / past), mewn achosion lle mae'n caniatáu Trwydded Gyhoeddus Eclipse (EPL). (Yn amlwg, nid yw hyn fel arfer yn fater cyfreithiol ar gyfer, dyweder, prosiectau Eclipse ei hun, ond nid ar gyfer cynhyrchion ffynhonnell gaeedig.) Yn ogystal â'i haphazardness cynhenid, mae'r dechneg hon yn cyflwyno problemau adnabyddus: dyblygu cod a gyflwynwyd gan wrth addasu i wallau, etc. Yr hyn sy'n waeth yw bod y modelau canlyniadol yn parhau i fod yn “bethau ynddynt eu hunain” ac nad ydynt yn manteisio ar y potensial ar gyfer uno. Ond gallai ynysu cysyniadau a phrotocolau cyffredin ar gyfer modelau iaith sy’n seiliedig ar ddolenni arwain at greu cydrannau y gellir eu hailddefnyddio ar gyfer gweithio gyda nhw, yn debyg i’r hyn a ddigwyddodd yn achos EMF.
Nid yw'n ffaith nad oedd Eclipse yn deall y materion hyn. Yn ôl yn 2005 , yn crynhoi'r profiad o ddatblygu'r prototeip CDT, yr angen i greu seilwaith cyffredin ar gyfer modelau iaith, gan gynnwys modelau sy’n seiliedig ar ddolenni. Ond, fel sy'n digwydd yn aml, oherwydd tasgau blaenoriaeth uwch, ni lwyddodd rhoi'r syniadau hyn ar waith erioed. Yn y cyfamser, mae ffactoreiddio cod *DT yn dal i fod yn un o'r pynciau annatblygedig yn Eclipse.
Mewn rhai ystyr, mae prosiect Handly wedi’i gynllunio i ddatrys tua’r un problemau ag EMF, ond ar gyfer modelau sy’n seiliedig ar ddolen, a rhai iaith yn bennaf (h.y., yn cynrychioli elfennau o strwythur rhywfaint o iaith raglennu). Rhestrir y prif nodau a osodwyd wrth ddylunio Handly isod:
- Nodi prif dyniadau'r maes pwnc.
- Lleihau ymdrech a gwella ansawdd gweithredu modelau iaith sy'n seiliedig ar ddolenni trwy ailddefnyddio cod.
- Darparu API lefel meta unedig i'r modelau canlyniadol, gan ei gwneud hi'n bosibl creu cydrannau IDE cyffredin sy'n gweithio gyda modelau sy'n seiliedig ar ddolen iaith.
- Hyblygrwydd a scalability.
- Integreiddio â Xtext (mewn haen ar wahân).
Er mwyn amlygu cysyniadau a phrotocolau cyffredin, dadansoddwyd y dulliau gweithredu presennol o fodelau sy'n seiliedig ar drin iaith. Dangosir y prif ryngwynebau a gweithrediadau sylfaenol a ddarperir gan Handly yn Ffig. 8.
Reis. 8. Rhyngwynebau cyffredin a gweithrediadau sylfaenol elfennau Handly
Mae rhyngwyneb IElement yn cynrychioli handlen elfen ac mae'n gyffredin i elfennau o'r holl fodelau Handly-seiliedig. Mae'r Elfen dosbarth haniaethol yn gweithredu'r mecanwaith trin / corff cyffredinol (Ffig. 9).
Reis. 9. I Elfen a gweithrediad handlen/corff generig
Yn ogystal, mae Handly yn darparu mecanwaith cyffredinol ar gyfer hysbysu am newidiadau mewn elfennau model (Ffig. 10). Fel y gwelwch, mae'n weddol debyg i'r mecanweithiau hysbysu a weithredir yn y model adnoddau a'r model Java, ac mae'n defnyddio IElementDelta i ddarparu cynrychiolaeth unedig o wybodaeth newid elfen.
Reis. 10. Rhyngwynebau cyffredinol a gweithrediadau sylfaenol y mecanwaith hysbysu Handly
Gellir defnyddio'r rhan Handly a drafodir uchod (Ffig. 9 a 10) i gynrychioli bron unrhyw fodelau sy'n seiliedig ar ddolen. Am greu ieithyddol modelau, mae'r prosiect yn cynnig ymarferoldeb ychwanegol - yn arbennig, rhyngwynebau cyffredin a gweithrediadau sylfaenol ar gyfer elfennau o strwythur testun ffynhonnell, yr hyn a elwir elfennau ffynhonnell (Ffig. 8). Mae rhyngwyneb ISourceFile yn cynrychioli ffeil ffynhonnell, ac mae ISourceConstruct yn cynrychioli elfen o fewn y ffeil ffynhonnell. Mae'r dosbarthiadau haniaethol SourceFile a SourceConstruct yn gweithredu mecanweithiau cyffredinol i gefnogi gweithio gyda ffeiliau ffynhonnell a'u helfennau, er enghraifft, gweithio gyda byfferau testun, rhwymo i gyfesurynnau elfen yn y testun ffynhonnell, cysoni modelau â chynnwys cyfredol byffer copi gweithredol , etc. Mae gweithredu’r mecanweithiau hyn fel arfer yn dipyn o her, a gall Handly leihau’n sylweddol yr ymdrech i ddatblygu modelau iaith sy’n seiliedig ar ddolenni trwy ddarparu gweithrediadau sylfaenol o ansawdd uchel.
Yn ogystal â'r mecanweithiau craidd a restrir uchod, mae Handly yn darparu seilwaith ar gyfer byfferau testun a chipluniau, cefnogaeth ar gyfer integreiddio â golygyddion cod ffynhonnell (gan gynnwys integreiddio y tu allan i'r bocs gyda golygydd Xtext), yn ogystal â rhai cydrannau UI cyffredin sy'n gweithio gyda golygyddion cod ffynhonnell Modelau ymarferol fel fframwaith amlinellol. Er mwyn dangos ei alluoedd, mae'r prosiect yn darparu sawl enghraifft, gan gynnwys gweithredu'r model Java yn Handly. (O'i gymharu â gweithrediad llawn y model Java yn JDT, mae'r model hwn yn fwriadol wedi'i symleiddio rhywfaint er mwyn sicrhau mwy o eglurder.)
Fel y nodwyd yn gynharach, ffocws mawr yn ystod dyluniad cychwynnol Handly a'i ddatblygiad dilynol oedd, ac mae'n parhau i fod, ar scalability a hyblygrwydd.
Mewn egwyddor, mae modelau sy'n seiliedig ar handlen yn graddio'n eithaf da “yn ôl dyluniad”. Er enghraifft, mae idiom handlen/corff yn caniatáu ichi gyfyngu ar faint o gof a ddefnyddir gan fodel. Ond mae yna hefyd arlliwiau. Felly, wrth brofi Handly am scalability, darganfuwyd problem wrth weithredu'r mecanwaith hysbysu - pan newidiwyd nifer fawr o elfennau, cymerodd adeiladu deltas ormod o amser. Daeth i'r amlwg bod yr un broblem yn bresennol yn y model JDT Java, y cafodd y cod cyfatebol ei addasu unwaith ohono. Fe wnaethom drwsio'r byg yn Handly a pharatoi darn tebyg ar gyfer JDT, a dderbyniwyd yn ddiolchgar. Dyma un enghraifft yn unig lle gallai cyflwyno Handly i weithrediad model presennol fod yn ddefnyddiol, oherwydd yn yr achos hwn gallai byg o’r fath gael ei drwsio mewn un lle yn unig.
Er mwyn gwneud gweithredu Handly i mewn i weithrediad model presennol yn dechnegol ymarferol, rhaid bod gan y llyfrgell hyblygrwydd sylweddol. Y brif broblem yw cynnal cydnawsedd yn ôl ar draws y model API. Cafodd y broblem hon ei datrys yn trwy wahanu'n glir yr API model-benodol, wedi'i ddiffinio a'i reoli'n llawn gan y datblygwr, oddi wrth yr API lefel meta unedig a ddarperir gan y llyfrgell. Mae hyn nid yn unig yn ei gwneud hi'n dechnegol bosibl gweithredu Handly i mewn i weithrediadau presennol, ond hefyd yn rhoi rhyddid sylweddol i'r datblygwr model newydd wrth ddylunio'r API.
Mae gan hyblygrwydd agweddau eraill hefyd. Er enghraifft, nid yw Handly yn gosod bron unrhyw gyfyngiadau ar strwythur y model a gellir ei ddefnyddio i fodelu ieithoedd pwrpas cyffredinol ac ieithoedd parth-benodol. Wrth adeiladu strwythur y ffeil ffynhonnell, nid yw Handly yn rhagnodi unrhyw fath penodol o gynrychiolaeth AST ac, mewn egwyddor, nid yw hyd yn oed yn gofyn am bresenoldeb AST ei hun, gan sicrhau cydnawsedd â bron unrhyw fecanwaith dosrannu. Yn olaf, mae Handly yn cefnogi integreiddio llawn â gweithle Eclipse, ond gall hefyd weithio'n uniongyrchol gyda systemau ffeiliau diolch i'w integreiddio â (EFS).
Fersiwn gyfredol Daeth allan ym mis Rhagfyr 2016. Er gwaethaf y ffaith bod y prosiect mewn cyflwr deor ar hyn o bryd ac nad yw'r API wedi'i osod yn derfynol eto, mae Handly eisoes yn cael ei ddefnyddio mewn dau gynnyrch masnachol mawr a gymerodd y risg o weithredu fel “mabwysiadwyr cynnar”, a, rhaid i mi ddweud, peidiwch â difaru eto.
Fel y nodwyd uchod, un o'r cynhyrchion hyn yw 1C:Enterprise Development Tools, lle defnyddir Handly o'r cychwyn cyntaf i fodelu elfennau o strwythur lefel uchel 1C:Ieithoedd Menter fel yr iaith raglennu adeiledig ac iaith ymholiad . Mae cynnyrch arall yn llai hysbys i'r cyhoedd. hwn , amgylchedd dylunio integredig ar gyfer prosesydd set gyfarwyddiadau sy'n benodol i gymwysiadau (ASIP), a ddefnyddir yn y cwmni Tsiec Codasip ei hun a chan ei gleientiaid, gan gynnwys , , , . Mae Codasip wedi bod yn defnyddio Handly wrth gynhyrchu ers 2015, gan ddechrau gyda fersiwn Handly 0.2. Mae'r datganiad diweddaraf o Codasip Studio yn defnyddio fersiwn 0.5, a ryddhawyd ym mis Mehefin 2016. Mae Ondřej Ilčík, sy'n arwain datblygiad DRhA yn Codasip, mewn cysylltiad â'r prosiect, gan ddarparu adborth hanfodol ar ran y “mabwysiadwr trydydd parti”. Llwyddodd hyd yn oed i ddod o hyd i rywfaint o amser rhydd i gymryd rhan yn uniongyrchol yn natblygiad y prosiect, gan weithredu haen UI (~ 4000 llinell o god) ar gyfer un o'r enghreifftiau Handly, model Java. Ceir gwybodaeth uniongyrchol fanylach am y defnydd o Handly gan fabwysiadwyr ar y dudalen prosiect.
Gobeithiwn, ar ôl rhyddhau fersiwn 1.0 gyda gwarant o sefydlogrwydd API a'r prosiect yn gadael y cyflwr deori, y bydd gan Handly fabwysiadwyr newydd. Yn y cyfamser, mae'r prosiect yn parhau i brofi a gwella'r API ymhellach, gan ryddhau dau ddatganiad "mawr" y flwyddyn - ym mis Mehefin (yr un dyddiad â'r datganiad Eclipse ar yr un pryd) a mis Rhagfyr, gan ddarparu amserlen ragweladwy y gall mabwysiadwyr ddibynnu arni. Gallwn hefyd ychwanegu bod “cyfradd namau” y prosiect yn parhau i fod ar lefel gyson isel ac mae Handly wedi bod yn gweithio’n ddibynadwy yng nghynnyrch mabwysiadwyr cynnar ers y fersiynau cyntaf un. I archwilio Eclipse Handly ymhellach, gallwch chi ddefnyddio и .
Ffynhonnell: hab.com