Seguruenik, aspaldi ez du aurkezpen berezirik behar. Jende askok ezagutzen du Eclipse Eclipse Java garapen tresnei esker (). Garatzaile gehienek "Eclipse" hitzarekin lotzen duten kode irekiko Java IDE ezagun hau da. Hala ere, Eclipse garapen-tresnak integratzeko plataforma hedagarria da (Eclipse Platform), eta bere oinarrian eraikitako IDE ugari, JDT barne. Eclipse Eclipse Proiektua da, Eclipse Plataformaren eta JDTren garapena koordinatzen duen goi-mailako proiektua, eta Eclipse SDK, garapen horren emaitza. Azkenik, Eclipse kode irekiko fundazio bat da, proiektu-komunitate handi batekin, guztiak ez Javan idatziak edo garapen tresnekin erlazionatuta (adibidez, proiektuak). и ). Eclipse-ren mundua oso anitza da.
Artikulu honetan, izaera orokorrean, Eclipse arkitekturaren oinarri batzuk aztertzen saiatuko gara garapen integratuko tresnak eraikitzeko plataforma gisa eta teknologiaren oinarria osatzen duten Eclipse osagaien hasierako ideia bat ematen. 1C “Konfiguratzaile berriaren” plataforma: Enterprise. . Jakina, berrikuspen hori ezinbestean azalekoa izango da eta nahiko mugatua izango da, besteak beste, Eclipse-ren garatzaileei ez gabiltzalako soilik xede publiko gisa. Hala ere, espero dugu Eclipse-ren garatzaile esperientziadunek ere artikuluan informazio interesgarria aurkitzea. Esaterako, “Eclipseren sekretuetako” bati buruz hitz egingo dugu, proiektu berri samarra eta ezezaguna. , 1C-k sortu eta lagundu zuena.
Eclipse Arkitekturaren sarrera
Ikus ditzagun lehenik Eclipse arkitekturaren alderdi orokor batzuk adibidea erabiliz (JDT). JDT adibide gisa aukeratzea ez da ustekabekoa. Hau da Eclipse-n agertzen den lehenengo garapen-ingurune integratua. *DT Eclipse beste proiektu batzuk, hala nola Eclipse C/C++ Development Tooling (CDT), geroago sortu ziren eta oinarrizko arkitektura-printzipioak eta banakako iturburu-kode zatiak JDTtik maileguan hartzen dituzte. JDTn ezarritako arkitekturaren oinarriak gaur egun garrantzitsuak dira Eclipse Plataformaren gainean eraikitako ia edozein IDErentzat, 1C:Enterprise Development Tools barne.
Lehenik eta behin, kontuan izan behar da Eclipse-k geruza arkitektoniko nahiko argia duela bereizten duela, hizkuntzatik independentea den funtzionaltasuna programazio-lengoaia espezifikoak onartzeko diseinatutako funtzionaltasunetik bereizten dela, eta UI-tik independenteak diren "nukleoa" osagaiak lotutako osagaietatik bereizten direla. erabiltzailearen interfaze lagungarriarekin.
Horrela, Eclipse Plataformak hizkuntzaz kanpoko azpiegitura komun bat definitzen du, eta Java garapen tresnek Java IDE osoko ezaugarri bat gehitzen diote Eclipse-ri. Eclipse Plataformak eta JDTak hainbat osagai dituzte, eta horietako bakoitza UI-ren independentea den "nukleoa" edo UI geruza bati dagokio (1. Irudia).
Arroza. 1. Eclipse Plataforma eta JDT
Zerrenda ditzagun Eclipse Plataformaren osagai nagusiak:
- Runtime — Pluginaren azpiegitura definitzen du. Eclipse arkitektura modularra du ezaugarri. Funtsean, Eclipse "luzapen puntuen" eta "luzapenen" bilduma da.
- Lan eremua — Proiektu bat edo gehiago kudeatzen ditu. Proiektu bat fitxategi-sistemara zuzenean mapatzen diren karpetak eta fitxategiak osatzen dute.
- Widget tresna estandarra (SWT) - Sistema eragilearekin integratutako erabiltzailearen interfazearen oinarrizko elementuak eskaintzen ditu.
- JAurpegia — SWTren gainean eraikitako UI-esparru ugari eskaintzen ditu.
- Workbench — Eclipse UI paradigma definitzen du: editoreak, ikuspegiak, perspektibak.
Esan beharra dago Eclipse Plataformak beste osagai erabilgarriak ere eskaintzen dituela garapen integratuko tresnak eraikitzeko, besteak beste, Araztu, Konparatu, Bilatu eta Taldea. Aipamen berezia egin behar zaio JFace Text - iturburu-kodearen "editore adimendunak" eraikitzeko oinarria. Zoritxarrez, artikulu honen esparruan ezinezkoa da osagai hauen eta baita UI geruzen osagaien azterketa apur bat egitea ere, beraz, atal honen gainerakoan, "nukleo" osagai nagusien ikuspegi orokor batera mugatuko gara. Eclipse Plataforma eta JDT.
Core Runtime
Eclipse pluginaren azpiegituran oinarritzen da eta proiektuak emandakoa . Eclipse plugin bakoitza OSGi sorta bat da. OSGi zehaztapenak, bereziki, bertsioak egiteko eta mendekotasunak konpontzeko mekanismoak definitzen ditu. Mekanismo estandar horiez gain, Equinox-ek kontzeptua aurkezten du hedapen-puntuak. Plugin bakoitzak bere hedapen-puntuak defini ditzake, eta funtzionalitate gehigarriak ("luzapenak") ere sartu ditzake sisteman, plugin berak edo beste batzuek definitutako luzapen-puntuak erabiliz. OSGi eta Equinox mekanismoen deskribapen zehatza artikulu honen esparrutik kanpo dago. Kontuan izan dezagun Eclipse-n modularizazioa erabatekoa dela (edozein azpisistema, Runtime barne, plugin bat edo gehiagoz osatuta dago), eta Eclipse-n ia guztia luzapen bat dela. Gainera, printzipio horiek Eclipse arkitekturan txertatuta zeuden OSGi sartu baino askoz lehenago (garai hartan teknologia propioa erabiltzen zuten, OSGi-ren antzera).
Core Laneko Espazioa
Eclipse plataformaren gainean eraikitako ia garapen-ingurune integratu guztiek Eclipse lan-eremuarekin funtzionatzen dute. IDEan garatutako aplikazioaren iturburu-kodea izan ohi duen lan-eremua da. Lan-eremua fitxategi-sistemara zuzenean esleitzen da eta karpetak eta fitxategiak dituzten proiektuek osatzen dute. Proiektu, karpeta eta fitxategi hauei deitzen zaie baliabideak lan-eremua. Eclipse-ko lan-eremuaren inplementazioak fitxategi-sistemari dagokionez cache gisa balio du, eta horrek baliabideen zuhaitzaren zeharkatzea nabarmen bizkortzea ahalbidetzen du. Horrez gain, laneko espazioak zerbitzu gehigarri batzuk eskaintzen ditu, besteak beste и .
Core Resources osagaia (org.eclipse.core.resources plugina) lan-eremua eta bere baliabideak babesteaz arduratzen da. Bereziki, osagai honek inprimakiko lan-eremurako sarbide programatikoa eskaintzen du baliabide ereduak. Eredu honekin modu eraginkorrean lan egiteko, bezeroek baliabide baterako esteka aurkezteko modu erraz bat behar dute. Kasu honetan, komenigarria litzateke ereduan baliabidearen egoera zuzenean gordetzen duen objektua bezeroen sarbidetik ezkutatzea. Bestela, adibidez, fitxategi bat ezabatzearen kasuan, bezeroak ereduan jada ez dagoen objektu bat eusten jarrai lezake, ondoriozko arazoekin. Eclipse-k arazo hau konpontzen du izeneko zerbait erabiliz kudeatzeko baliabidea. Heldulekuak gako gisa jokatzen du (laneko eremuko baliabidearen bidea bakarrik ezagutzen du) eta barne-ereduaren objekturako sarbidea erabat kontrolatzen du, baliabidearen egoerari buruzko informazioa zuzenean gordetzen duena. Diseinu hau ereduaren aldaera bat da .
Arroza. 2. irudiak Heldulekua/Gorputza hizkera irudikatzen du baliabide ereduari aplikatzen zaion moduan. IResource interfazeak baliabide baten heldulekua adierazten du eta API bat da, Interfaze hau inplementatzen duen Resource klaseak ez bezala, eta gorputza adierazten duen ResourceInfo klaseak ez dira APIak. Azpimarratzen dugu heldulekuak lan-eremuaren erroarekiko baliabidearen bidea bakarrik ezagutzen duela eta ez duela baliabideen informaziorako estekarik. Baliabideen informazio-objektuek "elementuen zuhaitza" deritzona osatzen dute. Datu-egitura hau memorian erabat gauzatzen da. Helduleku bati dagokion baliabidearen informazio instantzia aurkitzeko, helduleku horretan gordetako bidearen arabera zeharkatzen da elementuen zuhaitza.
Arroza. 2. IResource eta ResourceInfo
Aurrerago ikusiko dugunez, baliabide-ereduaren oinarrizko diseinua (heldulekuan oinarrituta dei genezake) Eclipse-n beste ereduetarako ere erabiltzen da. Oraingoz, zerrenda ditzagun diseinu honen ezaugarri bereizgarri batzuk:
- Heldulekua balio-objektua da. Balio-objektuak aldaezinak diren objektuak dira, zeinen berdintasuna identitatean oinarritzen ez den. Horrelako objektuak segurtasunez erabil daitezke giltza gisa hashed edukiontzietan. Helduleku-instantzia anitzek baliabide bera erreferentzia egin dezakete. Horiek alderatzeko, berdin(Object) metodoa erabili behar duzu.
- Heldulekuak baliabide baten portaera definitzen du, baina ez du baliabidearen egoerari buruzko informaziorik (gordetzen dituen datu bakarrak "gakoa" da, baliabiderako bidea).
- Heldulekuak existitzen ez den baliabide bati erreferentzia egin diezaioke (edo oraindik sortu ez den baliabide bati, edo dagoeneko ezabatu den baliabide bati). Baliabide baten existentzia egiazta daiteke IResource.exists() metodoa erabiliz.
- Eragiketa batzuk heldulekuan bertan gordetako informazioan oinarrituta soilik inplementa daitezke (helduleku-soilik eragiketak deiturikoak). Adibideak IResource.getParent(), getFullPath(), etab. Baliabidea ez da existitu behar eragiketa horrek arrakasta izateko. Arrakasta izateko baliabide bat existitzea eskatzen duten eragiketek CoreException bat botatzen dute baliabidea existitzen ez bada.
Eclipse laneko baliabideen aldaketak jakinarazteko mekanismo eraginkorra eskaintzen du (3. irudia). Baliabideak alda daitezke Eclipse IDE-n bertan egindako ekintzen ondorioz edo fitxategi-sistemarekin sinkronizatzearen ondorioz. Bi kasuetan, jakinarazpenetara harpidetzen diren bezeroei aldaketei buruzko informazio zehatza ematen zaie "baliabideen delta" moduan. Delta batek lan-esparruko baliabideen (azpi)zuhaitz baten bi egoeraren arteko aldaketak deskribatzen ditu eta berez zuhaitz bat da, nodo bakoitzak baliabide baten aldaketa deskribatzen du eta hurrengo mailan delta zerrenda bat dauka, haurraren baliabideen aldaketak deskribatzen dituena.
Arroza. 3. IResourceChangeEvent eta IResourceDelta
Baliabideen deltan oinarritutako jakinarazpen-mekanismoak ezaugarri hauek ditu:
- Aldaketa bakarra eta aldaketa asko egitura bera erabiliz deskribatzen dira, delta konposizio errekurtsiboaren printzipioa erabiliz eraikitzen baita. Harpidedun bezeroek baliabideen aldaketaren jakinarazpenak prozesatu ditzakete jaitsiera errekurtsiboa erabiliz, delten zuhaitz baten bidez.
- Deltak baliabidearen aldaketei buruzko informazio osoa du, haren mugimendua eta/edo harekin lotutako "markatzaileen" aldaketak barne (adibidez, konpilazio-erroreak markatzaile gisa adierazten dira).
- Baliabideen erreferentziak heldulekuaren bidez egiten direnez, deltak modu naturalean erreferentzia egin dezake urruneko baliabide bat.
Laster ikusiko dugunez, baliabide-ereduaren aldaketaren jakinarazpen-mekanismoaren diseinuaren osagai nagusiak heldulekuetan oinarritutako beste ereduetarako ere garrantzitsuak dira.
JDT Core
Eclipse lan-esparruko baliabide-eredua oinarrizko hizkuntza-agnostiko eredua da. JDT Core osagaiak (plugin org.eclipse.jdt.core) lan-eremuaren egitura Java ikuspegitik nabigatzeko eta aztertzeko API bat eskaintzen du, "Java eredua" deritzona (Java eredua). API hau Java elementuen arabera definitzen da, azpian dagoen baliabide-ereduaren APIaren aldean, zeina karpeta eta fitxategien arabera definitzen den. Irudian agertzen dira Java elementuen zuhaitzaren interfaze nagusiak. 4.
Arroza. 4. Java ereduko elementuak
Java ereduak baliabideen ereduaren helduleku/gorputz hizkera bera erabiltzen du (5. irudia). IJavaElement heldulekua da eta JavaElementInfo gorputzaren papera betetzen du. IJavaElement interfazeak Java elementu guztientzat komuna den protokolo bat definitzen du. Bere metodo batzuk heldulekuak soilik dira: getElementName(), getParent(), etab. JavaElementInfo objektuak dagokion elementuaren egoera gordetzen du: bere egitura eta atributuak.
Arroza. 5. IJavaElement eta JavaElementInfo
Java ereduak oinarrizko helduleku/gorputzaren diseinuaren ezarpenean desberdintasun batzuk ditu baliabideen ereduarekin alderatuta. Goian adierazi bezala, baliabideen ereduan, elementuen zuhaitza, zeinaren nodoak baliabideen informazio-objektuak diren, guztiz memorian dago. Baina Java ereduak baliabideen zuhaitzak baino elementu kopuru nabarmen handiagoa izan dezake, .java eta .class fitxategien barne egitura ere adierazten duelako: motak, eremuak eta metodoak.
Memorian elementuen zuhaitz osoa guztiz materializatzeko, Java ereduaren inplementazioak elementuen informazioaren LRU cache tamaina mugatukoa erabiltzen du, non gakoa IJavaElement heldulekua den. elementuen informazio-objektuak eskatuz sortzen dira elementuen zuhaitzean nabigatzen den heinean. Kasu honetan, gutxien erabiltzen diren elementuak cachetik kanporatzen dira, eta ereduaren memoria-kontsumoa zehaztutako cache-tamainara mugatuta geratzen da. Heldulekuan oinarritutako diseinuaren beste abantaila bat da, bezeroaren kodearen ezarpen-xehetasunak guztiz ezkutatzen dituena.
Java elementuen aldaketak jakinarazteko mekanismoa, oro har, goian aztertutako lan-eremuko baliabideen aldaketak jarraitzeko mekanismoaren antzekoa da. Java ereduaren aldaketak kontrolatu nahi dituen bezero batek jakinarazpenetara harpidetzen du, eta IJavaElementDelta bat daukan ElementChangedEvent objektu gisa irudikatzen dira (6. irudia).
Arroza. 6. ElementChangedEvent eta IJavaElementDelta
Java ereduak ez du metodoen gorputzei edo izenen ebazpenari buruzko informaziorik, beraz, Javan idatzitako kodearen azterketa zehatza egiteko, JDT Core-k eredu gehigarri bat eskaintzen du (kudeatzailean oinarritutakoa ez dena): (sintaxi-zuhaitz abstraktua, AST). AST iturburu-testua analizatzearen emaitza adierazten du. AST nodoak iturburu-moduluaren egiturako elementuei dagozkie (adierazpenak, eragileak, esamoldeak, etab.) eta iturburu-testuan dagokion elementuaren koordenatuei buruzko informazioa dute, baita (aukera gisa) izenaren ebazpenari buruzko informazioa ere. deituriko esteken forma loturak. Loturak entitate izendatuak adierazten dituzten objektuak dira, esate baterako, motak, metodoak eta aldagaiak, konpilatzaileak ezagutzen dituena. Zuhaitz bat osatzen duten AST nodoek ez bezala, loturak erreferentzia gurutzatuak onartzen dituzte eta, oro har, grafiko bat osatzen dute. ASTNode klase abstraktua AST nodo guztien oinarrizko klase komuna da. ASTNode azpiklaseak Java hizkuntzaren eraikuntza sintaktiko zehatzei dagozkie.
Sintaxi-zuhaitzek memoria kopuru handia kontsumi dezaketenez, JDT-k AST bakarra gordetzen du editore aktiboarentzat. Java eredua ez bezala, AST normalean "tarteko" eredu "aldi baterako" gisa ikusten da, zeinaren kideek ez diete erreferentziarik egin behar bezeroek ASTren sorrera ekarri zuen eragiketaren testuingurutik kanpo.
Zerrendatutako hiru ereduek (Java eredua, AST, loturak) elkarrekin JDT-n "garapen tresna adimendunak" eraikitzeko oinarria osatzen dute, Java editore indartsu bat barne, "laguntzaile" ezberdinekin, iturburu kodea prozesatzeko hainbat ekintza (inportazio zerrenda bat antolatzea barne). izenak eta estilo pertsonalizatuaren araberako formatua), bilaketa eta birfactorizazio tresnak. Kasu honetan, Java ereduak protagonismo berezia betetzen du, bera baita garatzen ari den aplikazioaren egituraren irudikapen bisualaren oinarri gisa erabiltzen dena (adibidez, paketeen arakatzailea, eskema, bilaketa, deia hierarkia eta Mota hierarkia).
1C-n erabiltzen diren Eclipse osagaiak: Enterprise Developments Tools
Irudian. 7. irudian 1C:Enterprise Development Tools plataforma teknologikoaren oinarria osatzen duten Eclipse osagaiak erakusten dira.
Arroza. 7. Eclipse 1C:Enterprise Development Tools plataforma gisa
Eclipse Plataforma oinarrizko azpiegiturak eskaintzen ditu. Aurreko atalean azpiegitura honen alderdi batzuk aztertu ditugu.
(EMF) datu egituratuak modelatzeko bitarteko orokorra eskaintzen du. EMF Eclipse plataformarekin integratuta dago, baina Java aplikazio arruntetan bereizita ere erabil daiteke. Askotan, Eclipse-ren garatzaile berriek dagoeneko ondo ezagutzen dute EMF, nahiz eta oraindik ez dituzten Eclipse Plataformaren konplexutasunak guztiz ulertzen. Merezitako ospe horren arrazoietako bat diseinu unibertsala da, besteak beste, meta-mailako API bateratua barne, edozein EMF eredurekin modu orokorrean lan egiteko aukera ematen duena. EMF-k emandako eredu-objektuen oinarrizko inplementazioek eta meta-ereduan oinarritutako eredu-kodea sortzeko azpisistemak garapen-abiadura nabarmen handitzen dute eta errore-kopurua murrizten dute. EMF-k ereduak serializatzeko, ereduaren aldaketak jarraitzeko eta askoz gehiago ere baditu.
Benetan helburu orokorreko edozein tresna bezala, EMF egokia da modelizazio-arazo ugari konpontzeko, baina eredu-klase batzuek (adibidez, goian aztertutako heldulekuetan oinarritutako ereduak) modelizazio-tresna espezializatuagoak behar ditzakete. EMFri buruz hitz egitea esker oneko zeregina da, batez ere artikulu baten muga mugatuen barruan, hau liburu bereizi baten gaia baita, eta nahiko lodi batena. Kontuan izan dezagun EMFren azpian dagoen kalitate handiko orokortze-sistemak modelizazioari eskainitako proiektu sorta oso baten jaiotza ahalbidetu zuela, goi-mailako proiektuan sartzen direnak. EMF berarekin batera. Horrelako proiektu bat Eclipse Xtext da.
"testua modelatzeko" azpiegitura bat eskaintzen du. Xtext erabilerak sorburu-testua analizatzeko eta EMF, ondoriozko ASG (grafiko semantiko abstraktua, funtsean AST eta loturen konbinazioa dena), "eredu semantikoa" ere deitzen zaio. Xtext-ek modelatutako hizkuntzaren gramatika Xtext-en berezko hizkuntzan deskribatzen da. Horri esker, ANTLRrako gramatika deskribapena sortzeaz gain, AST serializazio-mekanismo bat (hau da, Xtext-ek analizatzaile bat eta desanalizatzaile bat eskaintzen ditu), testuinguru-iradokizun bat eta beste hizkuntza-osagai batzuk ere eskura ditzakezu. Bestalde, Xtext-en erabiltzen den gramatika-hizkuntza ez da hain malgua, demagun, ANTLR-n erabiltzen den gramatika-hizkuntza baino. Hori dela eta, batzuetan beharrezkoa da inplementatutako hizkuntza Xtextera "makurtzea", normalean ez da arazoa hutsetik garatzen ari den hizkuntza bati buruz ari bagara, baina onartezina izan daiteke dagoeneko finkatuta dagoen sintaxia duten hizkuntzentzat. Hala eta guztiz ere, Xtext gaur egun Eclipse-ko tresnarik helduena, ezaugarri aberatsena eta polifazetikoa da haientzako programazio-lengoaiak eta garapen-tresnak eraikitzeko. Bereziki, prototipo azkarra egiteko tresna ezin hobea da (Domeinuaren hizkuntza espezifikoa, DSL). ANTLR eta EMF-n oinarritutako goian aipatutako "hizkuntza-nukleoa"z gain, Xtext-ek goi-mailako osagai erabilgarriak eskaintzen ditu, besteak beste, indexatzeko mekanismoak, eraikuntza inkrementala, "editore adimenduna" eta askoz, askoz gehiago, baina kudeatzaileak kanpoan uzten ditu. oinarritutako hizkuntza ereduak. EMF bezala, Xtext liburu bereizia merezi duen gaia da, eta nekez hitz egin dezakegu oraintxe bertan bere gaitasun guztiei buruz laburki ere.
1C:Enterprise Development Tools-ek aktiboki erabiltzen ditu EMF bera eta Eclipse Modeling beste hainbat proiektu. Hain zuzen ere, Xtext 1C:Enterprise lengoaietarako garapen tresnen oinarrietako bat da integratutako programazio-lengoaia eta kontsulta-lengoaia bezala. Garapen tresna hauen beste oinarri bat Eclipse Handly proiektua da, zeina zehatzago eztabaidatuko dugun (zerrendatutako Eclipse osagaien artean, oraindik gutxien ezagutzen dena da).
, Eclipse Technology goi-mailako proiektuaren azpiproiektua, 1C-k 2014an Eclipse Fundazioari egindako hasierako kode ekarpenaren ondorioz sortu zen. Orduz geroztik, 1C-k proiektuaren garapenean laguntzen jarraitu du: Handly committers enpresako langileak dira. Proiektua txikia da, baina Eclipse-n nitxo nahiko berezia hartzen du: heldulekuetan oinarritutako modeloen garapena laguntzea da bere helburu nagusia.
Heldulekuan oinarritutako ereduen oinarrizko arkitektura-printzipioak, hala nola heldulekua/gorputza hizkera, goian eztabaidatu ziren baliabide eredua eta Java eredua adibide gisa erabiliz. Era berean, baliabide eredua eta Java eredua Eclipse Java garapen tresnetarako (JDT) oinarri garrantzitsuak direla adierazi du. Eta *DT Eclipse proiektu ia guztiek JDT-ren antzeko arkitektura bat dutenez, ez litzateke gehiegikeria handirik izango esatea heldulekuetan oinarritutako ereduak Eclipse Plataformaren gainean eraikitako IDE askoren azpian daudela esatea. Esate baterako, Eclipse C/C++ Development Tooling (CDT) heldulekuetan oinarritutako C/C++ eredua du, CDT arkitekturan Java ereduak JDTn egiten duen funtzio bera betetzen duena.
Handly baino lehen, Eclipse-k ez zuen heldulekuetan oinarritutako hizkuntza ereduak eraikitzeko liburutegi espezializaturik eskaintzen. Gaur egun dauden ereduak batez ere Java ereduaren kodea zuzenean egokituz sortu dira (kopia/itsatsi). ahalbidetzen duen kasuetan Eclipse Public License (EPL). (Jakina, normalean ez da arazo legal bat, esate baterako, Eclipse proiektuak berez, baina ez kode itxiko produktuetarako.) Berez berezko zoriztasunaz gain, teknika honek arazo ezagunak sartzen ditu: akatsetara egokitzean sartutako kodea bikoiztea. etab. Okerrena da ondoriozko ereduek "gauzak berez" izaten jarraitzen dutela eta ez dutela bateratzeko ahalmena aprobetxatzen. Baina heldulekuetan oinarritutako hizkuntza ereduetarako ohiko kontzeptuak eta protokoloak isolatzeak hauekin lan egiteko osagai berrerabilgarriak sortzea ekar lezake, EMF-ren kasuan gertatu zenaren antzera.
Ez da Eclipse-k gai hauek ulertu ez zituela. 2005ean bueltan , CDT prototipoa garatzeko esperientzia laburbilduz, hizkuntza ereduetarako azpiegitura komun bat sortzeko beharra, heldulekuetan oinarritutako ereduak barne. Baina, askotan gertatzen den bezala, lehentasun handiagoko zereginak zirela eta, ideia horien ezarpena ez zen inoiz lortu. Bitartean, *DT kodearen faktorizazioa Eclipse-n garatu gabeko gaietako bat da oraindik.
Zentzu jakin batean, Handly proiektua EMFren arazo berdinak gutxi gorabehera konpontzeko diseinatuta dago, baina heldulekuetan oinarritutako ereduetarako, eta batez ere lengoaiarako (hau da, programazio-lengoaia batzuen egiturako elementuak irudikatzeko). Handly diseinatzean ezarritako helburu nagusiak jarraian zerrendatzen dira:
- Irakasgaiaren abstrakzio nagusien identifikazioa.
- Esfortzua murriztea eta heldulekuetan oinarritutako hizkuntza ereduen ezarpenaren kalitatea hobetzea, kodea berrerabiltzearen bidez.
- Sortutako ereduei meta-mailako API bateratua eskaintzea, hizkuntza heldulekuetan oinarritutako ereduekin lan egiten duten IDE osagai komunak sortzea posible eginez.
- Malgutasuna eta eskalagarritasuna.
- Xtext-ekin integratzea (geruza bereizi batean).
Kontzeptu eta protokolo komunak nabarmentzeko, hizkuntza heldulekuetan oinarritutako ereduen inplementazioak aztertu ziren. Handly-k eskaintzen dituen interfaze nagusiak eta oinarrizko inplementazioak irudian agertzen dira. 8.
Arroza. 8. Interfaze komunak eta Handly elementuen oinarrizko ezarpenak
IElement interfazeak elementu baten heldulekua adierazten du eta Handlyn oinarritutako eredu guztietako elementuetan komuna da. Element klase abstraktuak helduleku/gorputz mekanismo orokortua inplementatzen du (9. irudia).
Arroza. 9. IElement eta helduleku/gorputzaren ezarpen generikoa
Horrez gain, Handly-k ereduko elementuen aldaketen berri emateko mekanismo orokor bat eskaintzen du (10. irudia). Ikus dezakezunez, baliabideen ereduan eta Java ereduan inplementatutako jakinarazpen-mekanismoen antzekoa da, eta IElementDelta erabiltzen du elementu-aldaketaren informazioaren irudikapen bateratua emateko.
Arroza. 10. Handly jakinarazpen-mekanismoaren interfaze orokorrak eta oinarrizko ezarpenak
Goian aztertutako Handly zatia (9. eta 10. irudiak) heldulekuetan oinarritutako ia edozein eredu irudikatzeko erabil daiteke. Sortzeko linguistikoa ereduak, proiektuak funtzionalitate gehigarriak eskaintzen ditu, batez ere, interfaze komunak eta oinarrizko inplementazioak sorburu-testuaren egituraren elementuetarako, deiturikoak. iturriko elementuak (8. irud.). ISourceFile interfazeak iturburu-fitxategi bat adierazten du, eta ISourceConstruct-ek iturburu-fitxategiko elementu bat adierazten du. SourceFile eta SourceConstruct klase abstraktuek iturburu-fitxategiekin eta haien elementuekin lan egiteko mekanismo orokortuak ezartzen dituzte, adibidez, testu-bufferekin lan egitea, iturburu-testuko elementu baten koordenatuetara lotzea, ereduak lan egiten duten kopia-buffer baten uneko edukiarekin bateratzea. , etab. Mekanismo hauek ezartzea nahiko erronka izan ohi da, eta Handly-k heldulekuetan oinarritutako hizkuntza-ereduak garatzeko ahalegina nabarmen murriztu dezake kalitate handiko oinarrizko inplementazioak eskainiz.
Goian zerrendatutako oinarrizko mekanismoez gain, Handly-k testu-buffer eta argazkietarako azpiegitura bat eskaintzen du, iturburu-kode-editoreekin integratzeko laguntza (Xtext editorearekin kanpoko integrazioa barne), baita UI osagai arrunt batzuk ere. iturburu-kodeen editoreekin lan egin.Eredu errazak, esate baterako, eskema-markoa. Bere gaitasunak ilustratzeko, proiektuak hainbat adibide eskaintzen ditu, besteak beste, Handly-n Java ereduaren inplementazioa. (JDT-n Java ereduaren inplementazio osoarekin alderatuta, eredu hau nahita zertxobait sinplifikatu da argitasun handiagoa lortzeko.)
Lehen esan bezala, Handlyren hasierako diseinuan eta ondorengo garapenean arreta handi bat eskalagarritasuna eta malgutasuna izan zen eta izaten jarraitzen du.
Printzipioz, heldulekuetan oinarritutako modeloak nahiko ondo eskalatzen dira "diseinuz". Esaterako, heldulekua/gorputzaren idiomak modelo batek kontsumitzen duen memoria kopurua mugatzeko aukera ematen du. Baina ñabardurak ere badaude. Horrela, Handly eskalagarritasuna probatzerakoan, jakinarazpen-mekanismoaren ezarpenean arazo bat aurkitu zen: elementu ugari aldatzen zirenean, deltak eraikitzeak denbora gehiegi behar zuen. Arazo bera zegoen JDT Java ereduan, eta hortik egokitu zen behin dagokion kodea. Handly-n akatsa konpondu genuen eta JDTrako antzeko adabaki bat prestatu genuen, esker onez jaso zena. Hau adibide bat besterik ez da non Handly sartzea lehendik dauden ereduen inplementazioetan baliagarria izan daitekeen, kasu honetan akats hori leku bakarrean konpondu baitezake.
Handly inplementatzea lehendik dauden ereduen inplementazioetan teknikoki bideragarria izan dadin, liburutegiak malgutasun handia izan behar du. Arazo nagusia API ereduan atzerako bateragarritasuna mantentzea da. urtean konpondu zen arazo hau Garatzaileak definitutako eta guztiz kontrolatutako ereduaren API espezifikoa argi eta garbi bereiziz liburutegiak eskaintzen duen meta-mailako API bateratutik. Honek, teknikoki, Handly lehendik dauden inplementazioetan ezartzeaz gain, eredu berriaren garatzaileari askatasun handia ematen dio APIa diseinatzerakoan.
Malgutasunak beste alderdi batzuk ere baditu. Adibidez, Handly-k ez du ia murrizketarik ezartzen ereduaren egituran eta erabilera orokorreko zein domeinuko hizkuntza espezifikoak modelatzeko erabil daiteke. Iturburu-fitxategiaren egitura eraikitzean, Handly-k ez du AST irudikapen forma jakinik agintzen eta, printzipioz, ez du AST bera egotea ere eskatzen, horrela ia edozein analisi-mekanismorekin bateragarritasuna bermatzen du. Azkenik, Handly-k Eclipse lan-esparruarekin integrazio osoa onartzen du, baina fitxategi-sistemekin ere zuzenean lan egin dezake bere integrazioari esker. (EFS).
Egungo bertsioa 2016ko abenduan atera zen. Proiektua gaur egun inkubazio-egoeran dagoen arren eta APIa oraindik behin betiko konpondu gabe dagoen arren, Handly dagoeneko erabiltzen da bi produktu komertzial handitan, "early adopters" gisa jarduteko arriskua hartu zutenak, eta, esan beharra daukat, ez damutu oraindik.
Goian esan bezala, produktu horietako bat 1C:Enterprise Development Tools da, non Handly hasiera-hasieratik erabiltzen den 1C:Enterprise hizkuntzak barneko programazio-lengoaia eta kontsulta-lengoaia gisako goi-mailako egiturako elementuak modelatzeko. . Beste produktu bat publiko orokorrarentzat ez da hain ezaguna. Hau , aplikazioaren instrukzio-multzo prozesadore espezifikorako (ASIP) diseinu-ingurune integratua, Codasip Txekiar enpresan bertan zein bere bezeroek erabiltzen dutena, besteak beste. , , , . Codasip 2015az geroztik Handly erabiltzen ari da ekoizpenean, Handly 0.2 bertsiotik hasita. Codasip Studio-ren azken bertsioak 0.5ko ekainean kaleratutako 2016 bertsioa erabiltzen du. Ondřej Ilčík, Codasip-en IDE garapena zuzentzen duena, proiektuarekin harremanetan dago, eta ezinbesteko iritzia ematen du "hirugarrenen adoptatzailea"ren izenean. Nahiz eta denbora libre bat aurkitu ahal izan zuen proiektuaren garapenean zuzenean parte hartzeko, UI geruza bat ezarriz (~ 4000 kode lerro) Handly adibideetako baterako, Java eredu batentzat. Adoptatzaileek Handly-ren erabilerari buruzko lehen eskuko informazio zehatzagoa orrialdean aurki daiteke proiektua.
Espero dugu 1.0 bertsioa kaleratu ondoren API egonkortasunaren bermearekin eta proiektuak inkubazio egoera utzi ondoren, Handly-k adoptatzaile berriak izango dituela. Bitartean, proiektuak APIa probatzen eta hobetzen jarraitzen du, urtean bi bertsio "nagusi" kaleratuz: ekainean (aldi berean Eclipse kaleratzearen data bera) eta abenduan, erabiltzaileek fida dezaketen egutegi aurreikusgarria eskainiz. Era berean, proiektuaren "akats-tasa" maila baxuan jarraitzen duela eta Handly-k fidagarritasunez lan egin duela lehen bertsioetatik hasitako erabiltzaileen produktuetan. Eclipse Handly gehiago arakatzeko, erabil dezakezu и .
Iturria: www.habr.com