Seguruenik,
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.
Eclipse Arkitekturaren sarrera
Ikus ditzagun lehenik Eclipse arkitekturaren alderdi orokor batzuk adibidea erabiliz
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
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-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.
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.
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).
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
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
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.
Egungo bertsioa
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
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