Dibe, ji mêj ve ne hewceyî danasîna taybetî ye. Bi saya amûrên pêşkeftina Java-yê ya Eclipse gelek kes bi Eclipse nas dikin (). Ev Java IDE-ya çavkaniya vekirî ya populer e ku pir pêşdebiran bi peyva "Eclipse" re têkildar dike. Lêbelê, Eclipse hem platformek berfireh e ji bo yekkirina amûrên pêşkeftinê (Platforma Eclipse), hem jî hejmarek IDE-yên ku li ser bingeha wê hatine çêkirin, di nav de JDT. Eclipse hem Projeya Eclipse ye, projeya asta jorîn a ku pêşkeftina Platforma Eclipse û JDT-yê hevrêz dike, hem jî Eclipse SDK, encama peydakirî ya wê pêşkeftinê ye. Di dawiyê de, Eclipse Weqfek çavkaniyek vekirî ye ku bi civatek mezin a projeyan re, ne hemî di Java-yê de têne nivîsandin an bi amûrên pêşkeftinê re têkildar in (mînak, proje и ). Cîhana Eclipse pir cihêreng e.
Di vê gotarê de, ku di xwezayê de serpêhatî ye, em ê hewl bidin ku li hin bingehên mîmariya Eclipse wekî platformek ji bo avakirina amûrên pêşkeftina yekbûyî binêrin û ramanek destpêkê ya pêkhateyên Eclipse yên ku bingeha teknolojiyê pêk tînin bidin. platforma ji bo "Configuratora nû" 1C: Enterprise. . Bê guman, vekolînek wusa bê guman dê bi gelemperî rûkal û bi sînor be, di nav de ji ber ku em ne tenê li ser pêşdebirên Eclipse wekî temaşevanên armancê disekinin. Lêbelê, em hêvî dikin ku tewra pêşdebirên Eclipse yên bi ezmûn jî dê di gotarê de agahdariya balkêş bibînin. Mînakî, em ê li ser yek ji "veşartiyên Eclipse", projeyek nû û kêm-naskirî biaxivin. , ku ji hêla 1C ve hate damezrandin û piştgirî kirin.
Destpêka Mîmariya Eclipse
Werin em pêşî li hin aliyên giştî yên mîmariya Eclipse bi karanîna mînakan binihêrin (JDT). Hilbijartina JDT wekî nimûne ne tesadufî ye. Ev yekem hawîrdora pêşkeftina yekbûyî ye ku di Eclipse de xuya dike. Projeyên din ên *DT Eclipse, wek Eclipse C/C++ Amûrên Pêşveçûn (CDT), paşê hatin afirandin û hem prensîbên mîmarî yên bingehîn û hem jî perçeyên koda çavkaniya kesane ji JDT deyn kirin. Bingehên mîmariya ku di JDT-ê de hatine danîn heya roja îro ji bo hema hema her IDE-ya ku li ser Platforma Eclipse hatî çêkirin têkildar e, di nav de 1C: Amûrên Pêşveçûna Pargîdaniyê.
Berî her tiştî, divê were zanîn ku Eclipse bi qatbûnek mîmarî ya pir zelal ve tête diyar kirin, digel veqetandina fonksiyona serbixwe-zimanî ji fonksiyonê ku ji bo piştgirîkirina zimanên bernamesaziyê yên taybetî hatî çêkirin, û veqetandina hêmanên "bingehîn" ên serbixwe-UI ji pêkhateyên têkildar. bi navbeynkariya bikarhênerê piştgirî.
Ji ber vê yekê, Platforma Eclipse binesaziyek hevpar, serbixwe-ziman diyar dike, û amûrên pêşkeftina Java-ê Java-ya-ya-ya-taybetmendî li Eclipse zêde dikin. Hem Platforma Eclipse û hem jî JDT ji çend hêmanan pêk tê, ku her yek ji "bingehek"-serbixwe ya UI-yê an qatek UI-yê ye (Wêne 1).
Birinc. 1. Platforma Eclipse û JDT
Ka em beşên sereke yên Platforma Eclipse navnîş bikin:
- Runtime - Binesaziya pêvekê diyar dike. Eclipse ji hêla mîmariya modular ve tête diyar kirin. Di bingeh de, Eclipse berhevokek "xalên dirêjkirinê" û "dirêjkeran" e.
- Qada xebatê - Yek an çend projeyan bi rê ve dibe. Projeyek ji peldank û pelên ku rasterast bi pergala pelan ve têne nexşandin pêk tê.
- Amûra Widget Standard (SWT) - Hêmanên navbeynkariya bikarhêner a bingehîn a ku bi pergala xebitandinê re yekbûyî peyda dike.
- JFace - Hejmarek çarçoveyên UI yên ku li ser SWT hatine çêkirin peyda dike.
- Karker - Paradîgmaya Eclipse UI diyar dike: edîtor, dîtin, perspektîf.
Pêdivî ye ku were gotin ku Platforma Eclipse di heman demê de ji bo avakirina amûrên pêşkeftina yekbûyî, di nav de Debug, Compare, Search, and Team, gelek hêmanên din ên kêrhatî jî peyda dike. Pêdivî ye ku bi taybetî behsa JFace Text were kirin - bingeha avakirina "edîtorên jîr" ên koda çavkaniyê. Mixabin, tewra lêkolînek hûrgilî ya van hêmanan, û her weha pêkhateyên qata UI, di çarçoveya vê gotarê de ne mumkin e, ji ber vê yekê di mayî ya vê beşê de em ê xwe bi nerînek li ser pêkhateyên sereke yên "bingehîn" sînordar bikin. Platforma Eclipse û JDT.
Core Runtime
Binesaziya pêveka Eclipse li ser bingehê ye û ji hêla projeyê ve hatî pêşkêş kirin . Her pêveka Eclipse pakêtek OSGi ye. Taybetmendiya OSGi, bi taybetî, mekanîzmayên ji bo guhertokirin û çareseriya girêdayîbûnê diyar dike. Ji bilî van mekanîzmayên standard, Equinox têgehê destnîşan dike xalên berfirehbûnê. Her pêvek dikare xalên dirêjkirina xwe diyar bike, û di heman demê de fonksiyonên zêde ("berfireh") bi pergalê re bi karanîna xalên dirêjkirinê yên ku ji hêla heman an pêvekên din ve hatine destnîşankirin destnîşan bike. Her danasîna berfireh a mekanîzmayên OSGi û Equinox li derveyî çarçoweya vê gotarê ye. Ka em tenê bala xwe bidin ku modularîzasyona di Eclipse de bi tevahî ye (her binepergalek, tevî Runtime, ji yek an çend pêvekan pêk tê), û hema hema her tişt di Eclipse de dirêjkirinek e. Wekî din, ev prensîb di mîmariya Eclipse de demek dirêj berî danasîna OSGi hatine bicîh kirin (di wê demê de wan teknolojiya xwe, pir dişibihe OSGi bikar anîn).
Cihê Karê bingehîn
Hema hema her hawîrdora pêşkeftina yekbûyî ya ku li ser Platforma Eclipse hatî çêkirin bi cîhê xebatê Eclipse re dixebite. Ew cîhê xebatê ye ku bi gelemperî koda çavkaniyê ya serîlêdana ku di IDE-yê de hatî pêşve xistin vedihewîne. Nexşeya cîhê xebatê rasterast bi pergala pelan re nexşe dike û ji projeyên ku peldank û pelan vedihewîne pêk tê. Ev proje, peldank û pelan têne gotin çavkaniyên qada xebatê. Pêkanîna cîhê xebatê di Eclipse de bi pergala pelê ve wekî cache kar dike, ku ev gengaz dike ku bi girîngî lezkirina dara çavkaniyê bileztir bike. Digel vê yekê, cîhê xebatê hejmarek karûbarên din peyda dike, di nav de и .
Parçeya Çavkaniyên Navendî (org.eclipse.core.resources pêvek) berpirsiyar e ku cîhê xebatê û çavkaniyên wê piştgirî bike. Bi taybetî, ev hêman di formê de gihîştina bernamekirî ya cîhê xebatê peyda dike modelên çavkaniyê. Ji bo ku bi vê modelê re bi bandor bixebitin, xerîdar hewceyê rêyek hêsan in ku girêdanek bi çavkaniyekê re pêşkêş bikin. Di vê rewşê de, dê were xwestin ku meriv tiştê ku rasterast rewşa çavkaniyê di modelê de ji gihandina xerîdar vedişêre veşêre. Wekî din, di doza, mînakî, jêbirina pelek de, xerîdar dikaribû bi pirsgirêkên paşerojê ve girtina tiştek ku êdî di modelê de nema ye, bidomîne. Eclipse vê pirsgirêkê bi karanîna tiştek bi navê çareser dike destik kanî. Handle wekî kilît tevdigere (ew tenê riya çavkaniyê di cîhê xebatê de dizane) û bi tevahî gihandina objeya modela hundurîn kontrol dike, ku rasterast agahdariya di derbarê rewşa çavkaniyê de hilîne. Ev sêwirandin guhertoyek nimûneyê ye .
Birinc. Xiflteya 2 îdyoma Handle/Body ku li modela çavkaniyê tê sepandin nîşan dide. Navbera IResource destana çavkaniyekê temsîl dike û API ye, berevajî çîna Çavkaniyê, ku vê navberê bicîh tîne, û çîna ResourceInfo, ku laş, ku ne API ne, temsîl dike. Em tekez dikin ku handle tenê riya çavkaniyê li gorî koka cîhê xebatê dizane û girêdanek bi agahdariya çavkaniyê re nagire. Tiştên agahdariya çavkaniyê bi navê "dara hêmanê" ava dikin. Ev sazûmana daneyê bi tevahî di bîranînê de tête çêkirin. Ji bo dîtina mînaka agahdariya çavkaniyê ya ku bi destikê re têkildar e, dara elementê li gorî riya ku di wê destikê de hatî hilanîn tê derbas kirin.
Birinc. 2. IRResource û ResourceInfo
Wekî ku em ê paşê bibînin, sêwirana bingehîn a modela çavkaniyê (dibe ku em jê re binavkirî-based binav bikin) di Eclipse de ji bo modelên din jî tê bikar anîn. Heya nuha, werin em hin taybetmendiyên cihêreng ên vê sêwiranê navnîş bikin:
- Handle tiştekî nirx e. Tiştên nirxî tiştên neguhêrbar in ku wekheviya wan ne li ser nasnameyê ye. Tiştên weha dikarin bi ewlehî wekî mifteyek di konteynerên heşdî de bêne bikar anîn. Gelek mînakên destikê dikarin heman çavkaniyê referans bikin. Ji bo berhevkirina wan, hûn hewce ne ku rêbaza wekhev (Object) bikar bînin.
- Handle tevgera çavkaniyekê diyar dike, lê di derheqê rewşa çavkaniyê de agahdarî nagire (tenê daneya ku ew hildide "kilît", riya çavkaniyê ye).
- Handle dibe ku ji çavkaniyek ku tune be (an çavkaniyek ku hîn nehatiye afirandin, an çavkaniyek ku jixwe hatî jêbirin) vebêje. Hebûna çavkaniyekê dikare bi rêbaza IResource.exists() were kontrol kirin.
- Hin operasyonan tenê li ser bingeha agahdariya ku di destikê de hatî hilanîn (navê operasyonên tenê-tenê) têne bicîh kirin. Nimûne IResource.getParent (), getFullPath (), hwd. Ji bo ku operasyonek weha biserkeve ne hewce ye ku çavkanî hebe. Operasyonên ku hewce dike ku çavkaniyek hebe ku biserkeve heke çavkanî tune be îstîsnayek (CoreException) derdixe.
Eclipse ji bo agahdarkirina guhertinên çavkaniya cîhê xebatê mekanîzmayek bikêr peyda dike (Wêne 3). Çavkanî dikarin wekî encama kiryarên ku di hundurê Eclipse IDE-ya xwe de têne kirin an jî wekî encama hevdengkirina bi pergala pelê re têne guhertin. Di her du rewşan de, xerîdarên ku dibin aboneyê ragihandinê de agahdariya berfireh di derheqê guheztinên di forma "deltayên çavkaniyê" de têne peyda kirin. Delta guherînên di navbera du rewşan dara çavkaniyek cîhê xebatê (bine) vedibêje û bi xwe darek e, her girêka wê guherînek li ser çavkaniyekê vedibêje û navnîşek deltayên di asta pêş de vedihewîne ku guhertinên li ser çavkaniyên zarokan vedibêje.
Birinc. 3. IResourceChangeEvent û IResourceDelta
Mekanîzmaya ragihandinê ya li ser bingeha deltayên çavkaniyê xwedî taybetmendiyên jêrîn e:
- Guherînek yekane û gelek guhertin bi karanîna heman avahiyê têne diyar kirin, ji ber ku delta bi karanîna prensîba pêkhatina vegerê hatî çêkirin. Xerîdarên aboneyê dikarin agahdariya guhertina çavkaniyê bi karanîna daketina paşverû ya di nav dara deltayan de bişopînin.
- Delta agahdariya bêkêmasî li ser guheztinên çavkaniyê vedihewîne, tevî tevgera wê û/an guheztinên di "nîşankerên" ku pê re têkildar in (mînak, xeletiyên berhevkirinê wekî nîşanker têne destnîşan kirin).
- Ji ber ku referansên çavkaniyê bi navgîniyê ve têne çêkirin, delta dikare bi xwezayî çavkaniyek dûr referans bike.
Wekî ku em ê di demek nêzîk de bibînin, hêmanên sereke yên sêwirana mekanîzmaya ragihandinê ya guheztina modela çavkaniyê ji bo modelên din ên bi destan jî têkildar in.
JDT Core
Modela çavkaniya cîhê xebatê ya Eclipse modelek bingehîn a ziman-agnostîk e. Parçeya JDT Core (plugin org.eclipse.jdt.core) API-yek peyda dike ku ji perspektîfek Java-yê strukturên cîhê xebatê vegere û analîz bike, bi navê "modela Java" (Modela Java). Ev API li gorî hêmanên Java-yê, berevajî modela çavkaniyê ya bingehîn API-ya ku di nav peldank û pelan de tê destnîşan kirin, tê destnîşankirin. Têkiliyên sereke yên dara hêmana Javayê di Fig. 4.
Birinc. 4. Elements Model Java
Modela Java-yê wekî modela çavkaniyê heman destikê/bedenê bikar tîne (Wêne 5). IJavaElement destek e, û JavaElementInfo rola laş dilîze. Navbera IJavaElement protokolek hevpar a hemî hêmanên Java-ê diyar dike. Hin rêbazên wê tenê bi destan in: getElementName (), getParent (), hwd. Tişta JavaElementInfo rewşa hêmana têkildar hilîne: avahî û taybetmendiyên wê.
Birinc. 5. IJavaElement û JavaElementInfo
Modela Java-yê di pêkanîna sêwirana desta/laşê bingehîn de li gorî modela çavkaniyê hin cûdahiyên xwe hene. Wekî ku li jor hate destnîşan kirin, di modela çavkaniyê de, dara elementê, ku girêkên wê tiştên agahdariya çavkaniyê ne, bi tevahî di bîranînê de ye. Lê modela Java dikare ji dara çavkaniyê hejmareke girîngtir hêmanan hebe, ji ber ku ew avahiya navxweyî ya pelên .java û .class jî temsîl dike: celeb, zevî û rêbazan.
Ji bo ku bi tevahî dara hêmanan di bîranînê de nehêle, bicîhkirina modela Java-ê cache LRU ya hûrgelê ya agahdariya hêmanan bikar tîne, ku li wir mifteya IJavaElement e. Dema ku dara hêmanê tê rêve kirin, tiştên agahdariya elementê li gorî daxwazê têne afirandin. Di vê rewşê de, tiştên ku herî kêm têne bikar anîn ji cache têne derxistin, û vexwarina bîranîna modelê bi mezinahiya cache ya diyarkirî re sînordar dimîne. Ev avantajek din a sêwirana-based destikê ye, ku bi tevahî hûrguliyên pêkanînê yên weha ji koda xerîdar vedişêre.
Mekanîzmaya agahdarkirina guhertinên li hêmanên Java-yê bi gelemperî dişibihe mekanîzmaya şopandina guheztinên çavkaniyên cîhê xebatê ku li jor hatî nîqaş kirin. Xerîdarek ku dixwaze guheztinên di modela Java-yê de bişopîne, dibe aboneya ragihandinan, ku wekî objeyek ElementChangedEvent ku IJavaElementDelta-yê vedihewîne têne destnîşan kirin (Wêne 6).
Birinc. 6. ElementChangedEvent û IJavaElementDelta
Modela Java-yê di derheqê laşên rêbazê an çareseriya navan de agahdarî nagire, ji ber vê yekê ji bo analîzkirina hûrgulî ya koda ku li Java-yê hatî nivîsandin, JDT Core modelek pêvek (ne-destêk) peyda dike: (dara hevoksaziya razber, AST). AST encama parkirina nivîsa çavkaniyê nîşan dide. Nodên AST bi hêmanên strukturên modula çavkaniyê re têkildar in (daxuyan, operator, biwêj, hwd.) û agahdariya li ser koordînatên hêmana têkildar di nivîsa çavkaniyê de, û her weha (wek vebijark) agahdariya li ser çareseriya navan dihewîne. forma girêdanên bi navê bindings. Girêdan ew tişt in ku hebûnên bi navkirî temsîl dikin, wekî celeb, rêbaz û guhêrbar, ku ji berhevkerê re têne zanîn. Berevajî girêkên AST, yên ku darek çêdikin, girêdan piştgirîya xaça referansê dikin û bi gelemperî grafiyek çêdikin. Çîna razber ASTNode ji bo hemî girêkên AST çîna bingehîn a hevpar e. Bin-classên ASTNode bi avahiyên hevoksaziya taybetî yên zimanê Java re têkildar in.
Ji ber ku darên hevoksaziyê dikarin hejmarek girîng bîranînê bixwin, JDT tenê yek AST ji bo edîtorê çalak vedişêre. Berevajî modela Java-yê, AST bi gelemperî wekî modelek "navber," "demkî" tête dîtin ku endamên wê ji hêla xerîdar ve li derveyî çarçoweya operasyona ku bû sedema afirandina AST-ê neyên referans kirin.
Sê modelên navnîşkirî (modela Java, AST, girêdan) bi hev re bingehek ji bo avakirina "alavên pêşkeftina aqilmend" li JDT pêk tînin, di nav de edîtorek Java-ya hêzdar bi cûrbecûr "alîkar", kiryarên cihêreng ji bo hilanîna koda çavkaniyê (tevî organîzekirina navnîşek importê. nav û formatkirina li gorî şêwaza xwerû), amûrên lêgerîn û vesazkirinê. Di vê rewşê de, modela Java-yê rolek taybetî dilîze, ji ber ku ew e ku wekî bingehek ji bo temsîla dîtbarî ya strukturê serîlêdana ku hatî pêşve xistin tête bikar anîn (mînakî, di Package Explorer, Outline, Search, Call Hierarchy, û Tîpa Hiyerarşî).
Parçeyên Eclipse di 1C: Amûrên Pêşveçûnên Pargîdaniyê de têne bikar anîn
Di Fig. Wêneyê 7 hêmanên Eclipse nîşan dide ku bingeha platforma teknolojiyê ji bo 1C: Amûrên Pêşveçûna Pargîdaniyê pêk tîne.
Birinc. 7. Eclipse wekî platformek ji bo 1C: Amûrên Pêşveçûna Enterprise
Platforma Eclipse binesaziya bingehîn peyda dike. Me di beşa berê de li hin aliyên vê binesaziyê nihêrî.
(EMF) rêgezek giştî ya modelkirina daneyên sazkirî peyda dike. EMF bi Platforma Eclipse re yekgirtî ye, lê dikare di serîlêdanên Java-ya birêkûpêk de jî ji hev veqetîne. Pir caran, pêşdebirên nû yên Eclipse jixwe bi EMF-ê re baş nas dikin, her çend ew hîn jî tevliheviyên Platforma Eclipse bi tevahî fam nakin. Yek ji sedemên populerbûna wusa hêja sêwirana gerdûnî ye, ku di nav tiştên din de, API-a meta-asta yekbûyî ye, ku dihêle hûn bi her modelek EMF-ê re bi rengek gelemperî bixebitin. Pêkanîna bingehîn ji bo tiştên modelê yên ku ji hêla EMF ve têne peyda kirin û bine-pergala ji bo hilberîna koda modelê ya li ser bingeha meta-modelê bi girîngî leza pêşkeftinê zêde dike û hejmara xeletiyan kêm dike. EMF di heman demê de mekanîzmayên ji bo serialîzekirina modelan, şopandina guhertinên modelê, û hêj bêtir vedihewîne.
Mîna her amûrek bi rastî gelemperî, EMF ji bo çareserkirina cûrbecûr pirsgirêkên modelkirinê maqûl e, lê hin çînên modelan (mînakî, modelên ku li jor hatine behs kirin) dibe ku pêdivî bi amûrên modelkirinê yên pisportir hebe. Axaftina li ser EMF karekî spasdar e, nemaze di nav tixûbên tixûbdar ên gotarekê de, ji ber ku ev mijara pirtûkek cihê ye, û pir qelew e. Ka em tenê bala xwe bidin ku pergala kalîteya kalîteya gelemperî ya ku di binê EMF-ê de ye destûr da jidayikbûna gelek projeyên ku ji modelkirinê re hatine veqetandin, ku di projeya asta jorîn de cih digirin. ligel EMF bixwe. Projeyek weha Eclipse Xtext e.
binesaziyek "modelkirina nivîsê" peyda dike. Xtext bikar tîne ji bo parskirina metna çavkanî û EMF ji bo temsîlkirina ASG-ya encam (grafika semantîk a razber, ku bi eslê xwe berhevokek AST û girêdanan e), jê re "modela semantîk" jî tê gotin. Rêzimana zimanê ku ji hêla Xtext ve hatî model kirin bi zimanê Xtext-ê bi xwe tê vegotin. Ev dihêle hûn ne tenê ji bo ANTLR ravekirinek rêzimanê biafirînin, lê di heman demê de mekanîzmayek serialîzasyona AST-ê jî bistînin (ango Xtext hem parserek û hem jî neparserek peyda dike), îşaretek kontekstê, û hejmarek beşên din ên zimanî. Ji hêla din ve, zimanê rêzimanê ku di Xtext-ê de tê bikar anîn ji, bêje, zimanê rêzimanê ku di ANTLR de tê bikar anîn kêmtir nerm e. Ji ber vê yekê, carinan hewce ye ku zimanê hatî pêkanîn Xtextê "biçim", ku bi gelemperî ne pirsgirêk e heke em behsa zimanek ji nû ve hatî pêşve xistin, lê dibe ku ji bo zimanên xwedan hevoksaziyek jixwe sazkirî neyê pejirandin. Tevî vê yekê, Xtext niha di Eclipse de ji bo avakirina zimanên bernamekirinê û amûrên pêşkeftinê ji bo wan amûra herî gihîştî, bi taybetmendî û pirreng e. Bi taybetî, ew ji bo prototîpkirina bilez amûrek îdeal e (zimanek-taybetî, DSL). Ji bilî "bingeha ziman" a jorîn a ku li ser bingeha ANTLR û EMF-ê hatî behs kirin, Xtext gelek hêmanên asta bilindtir ên kêrhatî peyda dike, di nav de mekanîzmayên nîşankirinê, avakirina zêde, "edîtorek biaqil", û pir, pir bêtir, lê rêgezê ji holê radike- modelên zimanên bingehîn. Mîna EMF, Xtext mijarek hêjayî pirtûkek cihê ye, û em nekarin niha bi kurtî li ser hemî kapasîteyên wê jî biaxivin.
1C: Amûrên Pêşkeftina Pargîdaniyê hem EMF bixwe û hem jî hejmarek projeyên din ên Modelkirina Eclipse bi çalak bikar tînin. Bi taybetî, Xtext yek ji bingehên amûrên pêşkeftinê ye ji bo zimanên weha 1C: Enterprise wekî zimanê bernamesaziyê û zimanê pirsê yê çêkirî. Bingehek din a van amûrên pêşkeftinê projeya Eclipse Handly ye, ku em ê bi hûrgulî nîqaş bikin (ji pêkhateyên Eclipse yên ku hatine navnîş kirin, ew hîn jî ya herî kêm tê zanîn).
, projeyek projeya asta jorîn a Teknolojiya Eclipse, di encama tevkariya koda destpêkê ya Weqfa Eclipse ya ku ji hêla 1C ve di 2014-an de hatî çêkirin derket holê. Ji hingê ve, 1C piştgiriya pêşveçûna projeyê berdewam kir: Handly committers karmendên pargîdaniyê ne. Proje piçûk e, lê ew di Eclipse de cîhek bêhempa digire: Armanca wê ya sereke piştgirîkirina pêşkeftina modelên bi destan e.
Prensîbên mîmarî yên bingehîn ên modelên-based destikê, wek îdyoma destikê/laş, li jor bi karanîna modela çavkaniyê û modela Java-yê wekî mînak hatine nîqaş kirin. Her weha destnîşan kir ku hem modela çavkaniyê û hem jî modela Java bingehên girîng ên amûrên pêşkeftina Eclipse Java (JDT) ne. Û ji ber ku hema hema hemî projeyên *DT Eclipse xwedan mîmariyek mîna JDT-yê ne, ne zêdegaviyek mezin e ku meriv bibêje ku modelên-based destan di binê gelekan de ne, heke ne hemî IDE-yên ku li ser Platforma Eclipse hatine çêkirin. Mînakî, Amûra Pêşveçûna Eclipse C/C++ (CDT) xwedan modelek C/C++-ya-based e ku di mîmariya CDT de heman rola ku modela Java di JDT-ê de dike dilîze.
Beriya Handly, Eclipse pirtûkxaneyên pispor ji bo avakirina modelên ziman-based handle pêşkêş nekir. Modelên ku niha hene bi taybetî bi rasterast adaptasyona koda modela Java-yê (ango kopî / paste) hatine afirandin, di rewşên ku destûrê dide Lîsansa Giştî ya Eclipse (EPL). (Eşkere ye, ev bi gelemperî ji bo projeyên Eclipse bixwe ne pirsgirêkek qanûnî ye, lê ne ji bo hilberên çavkaniya girtî.) Ji xeynî bêserûberiya xweya xwerû, ev teknîk pirsgirêkên naskirî derdixe holê: Dubarekirina kodê ku ji hêla adaptasyona xeletiyan ve hatî destnîşan kirin, etc. Ya xerabtir ev e ku modelên ku têne encamdan "tiştên bi xwe" dimînin û ji potansiyela yekbûnê sûd wernagirin. Lê veqetandina têgeh û protokolên hevpar ên ji bo modelên ziman-bingeha destan dikare bibe sedema afirandina pêkhateyên ji nû ve bi kar anîn ji bo xebata bi wan re, mîna ya ku di doza EMF de qewimî.
Ne ew e ku Eclipse van mijaran fêm nekir. Vegere 2005 , kurtkirina ezmûna pêşxistina prototîpa CDT, pêdiviya afirandina binesaziyek hevbeş ji bo modelên zimanî, di nav de modelên bi destan. Lê, wekî ku pir caran diqewime, ji ber karên pêşîn ên bilindtir, pêkanîna van ramanan qet li dora wê neçû. Di vê navberê de, faktorkirina koda *DT hîn jî yek ji mijarên nepêşkeftî yên Eclipse ye.
Di wateyek diyar de, projeya Handly ji bo çareserkirina hema hema heman pirsgirêkan wekî EMF-ê hatî çêkirin, lê ji bo modelên bi destan, û di serî de yên zimanî (ango, hêmanên avahiya hin zimanên bernamekirinê temsîl dike). Armancên sereke yên ku dema sêwirana Handly têne destnîşan kirin li jêr têne navnîş kirin:
- Naskirina abstraksyonên sereke yên qada mijarê.
- Kêmkirina hewildan û başkirina kalîteya pêkanîna modelên ziman-based bi navgîniya ji nû ve karanîna kodê.
- API-a meta-asta yekbûyî ji modelên encam re peyda dike, ku gengaz dike ku pêkhateyên IDE yên hevpar ên ku bi modelên bingehîn-based ziman re bixebitin biafirînin.
- Flexibility û scalability.
- Yekbûnek bi Xtext re (di qatek cûda de).
Ji bo ronîkirina têgeh û protokolên hevpar, pêkanînên heyî yên modelên destan-based ziman hatin analîz kirin. Têkiliyên sereke û pêkanînên bingehîn ên ku ji hêla Handly ve têne peyda kirin di Fig. 8.
Birinc. 8. Têkiliyên hevpar û pêkanînên bingehîn ên hêmanên Handly
Navbera IElement destana hêmanekê temsîl dike û ji hêmanên hemî modelên bingehîn ên Handly re hevpar e. Elementa çîna abstrakt mekanîzmaya destikê/laşê giştîkirî pêk tîne (Hêjî. 9).
Birinc. 9. IElement û generic handle / pêkanîna laş
Wekî din, Handly mekanîzmayek giştî peyda dike ji bo agahdarkirina li ser guheztinên hêmanên modelê (Hêjîrê. 10). Wekî ku hûn dibînin, ew bi gelemperî dişibihe mekanîzmayên ragihandinê yên ku di modela çavkaniyê û modela Java de hatine bicîh kirin, û IElementDelta bikar tîne da ku nûneriyek yekgirtî ya agahdariya guhartina elementê peyda bike.
Birinc. 10. Têkiliyên gelemperî û pêkanînên bingehîn ên mekanîzmaya ragihandinê ya Handly
Beşa Handly ya ku li jor hatî nîqaş kirin (Hêjîr. 9 û 10) dikare were bikar anîn da ku hema hema her modelên-based destikê temsîl bike. Ji bo afirandinê zimannasî modelan, proje fonksiyonên zêde pêşkêşî dike - bi taybetî, navgînên hevpar û pêkanînên bingehîn ên ji bo hêmanên avahiya nivîsa çavkaniyê, ya ku jê re tê gotin. hêmanên çavkaniyê (Hêjî. 8). Navbera ISourceFile pelek çavkaniyek, û ISourceConstruct hêmanek di nav pelê çavkaniyê de temsîl dike. Dersên razber SourceFile û SourceConstruct mekanîzmayên gelemperî bicîh dikin ku piştgirî bidin xebata bi pelên çavkaniyê û hêmanên wan re, mînakî, xebata bi tamponên nivîsê, girêdana bi koordînatên hêmanek di nivîsa çavkaniyê de, hevahengkirina modelan bi naveroka heyî ya tamponek kopî ya xebatê re. , hwd. Bicîhanîna van mekanîzmayan bi gelemperî dijwariyek e, û Handly dikare bi peydakirina pêkanînên bingehîn ên qalîteya bilind hewildana pêşvebirina modelên ziman-based destikê bi girîngî kêm bike.
Digel mekanîzmayên bingehîn ên ku li jor hatine navnîş kirin, Handly binesaziyek ji bo tamponên nivîsê û dîmenên wêneyê, piştgirî ji bo yekbûna bi edîtorên koda çavkaniyê re (tevî yekbûna derveyî bi edîtorê Xtext re), û her weha hin hêmanên UI yên hevpar ku bi edîtorên koda çavkaniyê re bixebitin. Ji bo ronîkirina kapasîteyên xwe, proje çend mînakan peyda dike, di nav de pêkanîna modela Java di Handly de. (Li gorî pêkanîna bêkêmasî ya modela Java-yê di JDT de, ev model bi mebest ji bo zelaliyek mezintir hinekî hêsankirî ye.)
Wekî ku berê hate destnîşan kirin, di dema sêwirana destpêkê ya Handly û pêşkeftina paşîn de girîngiyek girîng li ser pîvanbûn û nermbûnê bû û berdewam dike.
Di prensîbê de, modelên-based destikê "ji hêla sêwiranê" ve pir baş têne pîvandin. Mînakî, biwêja destek / laş dihêle hûn mîqdara bîranîna ku ji hêla modelê ve tê vexwarin sînordar bikin. Lê nuans jî hene. Bi vî rengî, dema ceribandina Handly ji bo pîvandinê, di pêkanîna mekanîzmaya ragihandinê de pirsgirêkek hat dîtin - dema ku hejmareke mezin ji hêmanan hatin guhertin, avakirina deltayan pir dem girt. Derket holê ku heman pirsgirêk di modela JDT Java de hebû, ku ji kîjan koda têkildar carekê hate adaptekirin. Me di Handly de xeletî rast kir û ji bo JDT-ê ku bi spasdarî hate pêşwazî kirin pezek wusa amade kir. Ev tenê mînakek e ku danasîna Handly di pêkanînên modela heyî de dibe ku potansiyel bikêr be, ji ber ku di vê rewşê de xeletiyek wusa dikare tenê li cîhek were rast kirin.
Ji bo ku bicîhkirina Handly di pêkanînên modela heyî de ji hêla teknîkî ve gengaz be, pêdivî ye ku pirtûkxane xwedan nermbûnek girîng be. Pirsgirêka sereke ev e ku meriv lihevhatina paşverû li seranserê modela API-ê biparêze. Ev pirsgirêk di nav de hate çareser kirin bi eşkere veqetandina API-ya-taybetî ya modelê, ku ji hêla pêşdebirker ve hatî destnîşan kirin û bi tevahî tê kontrol kirin, ji API-ya meta-asta yekbûyî ya ku ji hêla pirtûkxaneyê ve hatî peyda kirin. Ev ne tenê ji hêla teknîkî ve pêkanîna Handly di pêkanînên heyî de gengaz dike, lê di heman demê de dema sêwirana API-ê azadîyek girîng dide pêşdebirê modela nû.
Flexibility aliyên din jî hene. Mînakî, Handly hema hema ti sînoran li ser strukturê modelê ferz nake û dikare ji bo modelkirina zimanên hem-armanca gelemperî û hem jî yên domain-taybet were bikar anîn. Dema ku strukturê pelê çavkaniyê ava dike, Handly tu formek taybetî ya nûnertiya AST destnîşan nake û, di prensîbê de, hebûna AST bixwe jî hewce nake, bi vî rengî lihevhatina hema hema bi her mekanîzmaya parskirinê re misoger dike. Di dawiyê de, Handly bi cîhê xebatê Eclipse re entegrasyona tevahî piştgirî dike, lê di heman demê de bi saya yekbûna xwe bi pergalên pelan re rasterast kar dike. (EFS).
Guhertoya niha di Kanûna 2016an de derket. Tevî vê rastiyê ku proje naha di rewşek înkubasyonê de ye û API hîna di dawiyê de nehatiye rast kirin, Handly jixwe di du hilberên bazirganî yên mezin ên ku xetera tevgerîna wekî "bicihkerên destpêkê" digirin tê bikar anîn, û, divê ez bibêjim, hê poşman nebin.
Wekî ku li jor hate destnîşan kirin, yek ji van hilberan 1C: Amûrên Pêşveçûna Pargîdaniyê ye, ku Handly ji destpêkê ve ji bo modelkirina hêmanên avahiya asta bilind a zimanên weha 1C: Enterprise wekî zimanê bernamekirinê û zimanê lêpirsînê yê çêkirî tê bikar anîn. . Berhemek din ji raya giştî re kêm tê zanîn. Ev , hawîrdorek sêwirana yekbûyî ya ji bo pêvajoyek rêza rêwerzan-taybet-serîlêdanê (ASIP), ku hem di hundurê pargîdaniya Czech Codasip bixwe de û hem jî ji hêla xerîdarên wê ve tê bikar anîn, di nav de , , , . Codasip ji 2015-an vir ve Handly di hilberînê de bikar tîne, bi guhertoya Handly 0.2 dest pê dike. Daxuyaniya herî dawî ya Codasip Studio guhertoya 0.5-ê, ku di Hezîrana 2016-an de hatî berdan bikar tîne. Ondřej Ilčík, ku pêşengiya pêşkeftina IDE li Codasip dike, bi projeyê re di têkiliyê de ye, li ser navê "pejirvanê partiya sêyemîn" bertekên girîng peyda dike. Tewra wî karî hin wextê belaş peyda bike da ku rasterast beşdarî pêşkeftina projeyê bibe, ji bo yek ji mînakên Handly, modelek Java, qatek UI (~ 4000 rêzikên kodê) bicîh bîne. Agahiyên berfirehtir ên destê yekem di derbarê karanîna Handly ji hêla pejiranderan ve li ser rûpelê têne dîtin rêvename.
Em hêvî dikin ku piştî serbestberdana guhertoya 1.0 bi garantiya aramiya API-yê û proje ji rewşa înkubasyonê derkeve, Handly dê xwediyê pejirankerên nû be. Di vê navberê de, proje ceribandin û çêtirkirina API-yê didomîne, her sal du serbestberdanên "mezin" derdixe - di Hezîranê de (heman tarîxa serbestberdana hevdemî ya Eclipse) û Kanûnê, bernameyek pêşbînîkirî peyda dike ku pejirankar dikarin pê bispêrin. Di heman demê de em dikarin lê zêde bikin ku "rêjeya xeletiyê" ya projeyê di astek bi domdarî nizm de dimîne û Handly ji guhertoyên yekem û vir ve bi pêbawer di hilberên pejirandî yên pêşîn de dixebite. Ji bo ku hûn Eclipse Handly bêtir lêkolîn bikin, hûn dikarin bikar bînin и .
Source: www.habr.com