meureun, geus lila saprak diperlukeun euweuh bubuka husus. Seueur jalma anu kenal sareng Eclipse berkat alat pangembangan Eclipse Java (). Ieu mangrupikeun IDE Java open-source anu populer anu paling seueur pamekar dikaitkeun sareng kecap "Eclipse". Nanging, Eclipse mangrupikeun platform éksténsif pikeun ngahijikeun alat pangembangan (Platform Eclipse), sareng sajumlah IDE anu diwangun dina dasarna, kalebet JDT. Eclipse mangrupikeun Proyék Eclipse, proyék tingkat luhur anu koordinat pamekaran Eclipse Platform sareng JDT, sareng Eclipse SDK, hasil anu dikirimkeun tina pamekaran éta. Tungtungna, Eclipse mangrupikeun Yayasan open-source sareng komunitas proyék anu ageung, henteu sadayana ditulis dina Java atanapi aya hubunganana sareng alat pangembangan (contona, proyék. и ). Dunya Eclipse pisan rupa-rupa.
Dina tulisan ieu, anu mangrupikeun tinjauan di alam, urang bakal nyobian ningali sababaraha dasar-dasar arsitektur Eclipse salaku platform pikeun ngawangun alat pangembangan terpadu sareng masihan ide awal ngeunaan komponén Eclipse anu ngawangun pondasi téknologi. platform pikeun "Configurator anyar" 1C: perusahaan. . Tangtosna, ulasan sapertos kitu pasti bakal sakitu legana deet sareng rada terbatas, kalebet sabab kami henteu ngan ukur museurkeun kana pamekar Eclipse salaku pamiarsa target. Nanging, kami ngarepkeun yén pamekar Eclipse anu berpengalaman bakal tiasa mendakan inpormasi anu pikaresepeun dina tulisan éta. Contona, urang bakal ngobrol ngeunaan salah sahiji "Rahasia Eclipse", hiji proyék kawilang anyar jeung saeutik-dipikawanoh. , anu diadegkeun sareng dirojong ku 1C.
Bubuka Arsitéktur Eclipse
Hayu urang tingali sababaraha aspék umum arsitektur Eclipse ngagunakeun conto (JDT). Pilihan JDT salaku conto teu kahaja. Ieu mangrupikeun lingkungan pangembangan terpadu munggaran anu muncul dina Eclipse. Proyék *DT Eclipse séjén, sapertos Eclipse C/C++ Development Tooling (CDT), didamel engké sareng nginjeum duanana prinsip arsitéktur dasar sareng fragmen kode sumber individu ti JDT. Dasar arsitéktur anu aya dina JDT relevan dugi ka ayeuna pikeun ampir sadaya IDE anu diwangun dina luhureun Eclipse Platform, kalebet 1C: Alat Pangembangan Perusahaan.
Anu mimiti, kudu dicatet yén Eclipse dicirikeun ku layering arsitéktur anu cukup jelas, kalayan pamisahan fungsionalitas basa-bebas tina fungsionalitas anu dirancang pikeun ngadukung basa program khusus, sareng pamisahan komponén "inti" bebas UI tina komponén anu aya hubunganana. kalawan panganteur pamaké ngarojong.
Ku kituna, Eclipse Platform ngahartikeun infrastruktur anu umum, mandiri basa, sareng alat pamekaran Java nambihan IDE Java anu lengkep ka Eclipse. Duanana Eclipse Platform sareng JDT diwangun ku sababaraha komponén, anu masing-masing milik boh "inti" UI-independen atanapi lapisan UI (Gambar 1).
Sangu. 1. Eclipse Platform jeung JDT
Hayu urang daptar komponén utama Eclipse Platform:
- Runtime - Nangtukeun infrastruktur plugin. Eclipse dicirikeun ku arsitéktur modular. Intina, Eclipse mangrupikeun kumpulan "titik ekstensi" sareng "ekstensi".
- Ruang gawé - Manages hiji atawa leuwih proyék. Proyék diwangun ku polder sareng file anu dipetakeun langsung kana sistem file.
- Alat Widget Standar (SWT) - Nyadiakeun elemen panganteur pamaké dasar terpadu kalayan sistem operasi.
- JFace - Nyadiakeun sababaraha frameworks UI diwangun dina luhureun SWT.
- Workbench - Nangtukeun paradigma Eclipse UI: éditor, pandangan, sudut pandang.
Perlu disebatkeun yén Eclipse Platform ogé nyayogikeun seueur komponén anu mangpaat pikeun ngawangun alat pangembangan terpadu, kalebet Debug, Bandingkeun, Pilarian, sareng Tim. Sebutan khusus kedah dilakukeun tina JFace Text - dasar pikeun ngawangun "éditor pinter" kode sumber. Hanjakalna, sanajan pamariksaan sakedapan komponén-komponén ieu, ogé komponén lapisan UI, teu mungkin dina wengkuan artikel ieu, ku kituna dina sésa bagian ieu urang bakal ngawatesan diri kana tinjauan ngeunaan komponén "inti" utama. Platform Eclipse sareng JDT.
Inti Runtime
Infrastruktur plugin Eclipse dumasar kana sarta disadiakeun ku proyék . Unggal plugin Eclipse mangrupikeun bungkusan OSGi. Spésifikasi OSGi netepkeun, khususna, mékanisme pikeun vérsi sareng résolusi kagumantungan. Salian mékanisme standar ieu, Equinox ngenalkeun konsép titik ékspansi. Unggal plugin bisa nangtukeun titik extension sorangan, sarta ogé ngenalkeun fungsionalitas tambahan ("ekstensi") kana sistem ngagunakeun titik extension ditetepkeun ku plugins sarua atawa séjén. Sakur katerangan lengkep ngeunaan mékanisme OSGi sareng Equinox teu aya dina lingkup tulisan ieu. Catet yén modularisasi dina Eclipse jumlahna (subsistem naon waé, kalebet Runtime, diwangun ku hiji atanapi langkung plugins), sareng ampir sadayana dina Eclipse mangrupikeun ekstensi. Sumawona, prinsip-prinsip ieu dipasang dina arsitéktur Eclipse jauh sateuacan ngenalkeun OSGi (dina waktos éta aranjeunna ngagunakeun téknologi sorangan, sami sareng OSGi).
Inti Workspace
Ampir sagala lingkungan ngembangkeun terpadu diwangun dina luhureun Eclipse Platform jalan kalawan workspace Eclipse. Ieu teh workspace nu biasana ngandung kode sumber tina aplikasi dimekarkeun dina IDE. Workspace peta langsung ka sistem file sarta diwangun ku proyék, nu ngandung polder jeung payel. Proyék, polder, sareng file ieu disebut sumberdaya rohangan gawé. Palaksanaan workspace di Eclipse boga fungsi minangka cache dina hubungan jeung sistem file, nu ngamungkinkeun pikeun nyata nyepetkeun traversal tina tangkal sumberdaya. Salaku tambahan, ruang kerja nyayogikeun sajumlah jasa tambahan, kalebet и .
Komponén Sumberdaya Inti (org.eclipse.core.resources plugin) tanggung jawab pikeun ngadukung ruang kerja sareng sumberna. Hususna, komponén ieu nyadiakeun aksés programmatic ka workspace dina formulir model sumberdaya. Pikeun dianggo sacara efektif sareng modél ieu, klien peryogi cara anu saderhana pikeun nampilkeun tautan kana sumber daya. Dina hal ieu, éta bakal desirable pikeun nyumputkeun obyék anu langsung nyimpen kaayaan sumberdaya dina modél ti aksés klien. Upami teu kitu, dina kasus, contona, ngahapus file, klien tiasa teras-terasan nahan objék anu henteu aya dina modél, sareng masalah anu salajengna. Eclipse ngarengsekeun masalah ieu nganggo anu disebut gagang sumberdaya. Cecekelan tindakan minangka konci (eta ukur terang jalur ka sumberdaya di workspace nu) tur lengkep ngadalikeun aksés ka objék model internal, nu langsung nyimpen informasi ngeunaan kaayaan sumberdaya. Desain ieu variasi pola .
Sangu. angka 2 illustrates cecekelan / awak idiom sakumaha dilarapkeun ka model sumberdaya. Antarbeungeut IResource ngagambarkeun cecekelan sumberdaya sarta mangrupa API, Teu kawas kelas Resource, nu implements panganteur ieu, jeung kelas ResourceInfo, nu ngagambarkeun awak, nu teu API. Urang ngantebkeun yén cecekelan ukur terang jalur ka sumberdaya relatif ka akar workspace sarta henteu ngandung tumbu ka info sumberdaya. Objék info sumberdaya ngabentuk anu disebut "tangkal unsur". Struktur data ieu sagemblengna materialized dina mémori. Pikeun manggihan inpo sumberdaya misalna pakait cecekelan a, tangkal unsur traversed nurutkeun jalur disimpen dina cecekelan éta.
Sangu. 2. IResource jeung ResourceInfo
Sakumaha anu bakal urang tingali engké, desain dasar modél sumberdaya (urang tiasa nyebatna dumasar kana cecekelan) dianggo dina Eclipse pikeun modél sanésna ogé. Pikeun ayeuna mah, hayu urang daptar sababaraha sipat has desain ieu:
- Cecekelan mangrupakeun obyék nilai. Objék niléy nyaéta obyék anu teu bisa dirobah anu sarua henteu dumasar kana identitas. Objék sapertos kitu tiasa aman dianggo salaku konci dina wadah hashed. Sababaraha conto cecekelan tiasa ngarujuk kana sumberdaya anu sami. Pikeun ngabandingkeun aranjeunna, anjeun kedah nganggo metode anu sami (Objék).
- Cecekelan ngahartikeun paripolah sumberdaya a, tapi teu ngandung émbaran ngeunaan kaayaan sumberdaya (hiji-hijina data eta nyimpen teh "konci", jalur ka sumberdaya nu).
- Handle tiasa ngarujuk kana sumber daya anu teu aya (boh sumber daya anu henteu acan diciptakeun, atanapi sumber daya anu parantos dihapus). Ayana sumberdaya bisa dipariksa ngagunakeun métode IResource.exists ().
- Sababaraha operasi bisa dilaksanakeun dumasar solely on informasi disimpen dina cecekelan sorangan (disebut cecekelan-hijina operasi). Contona nyaéta IResource.getParent (), getFullPath (), jsb. Sumberdaya henteu kedah aya pikeun operasi sapertos kitu suksés. Operasi anu merlukeun sumberdaya a aya pikeun suksés ngalungkeun CoreException lamun sumberdaya teu aya.
Eclipse nyadiakeun mékanisme efisien pikeun ngabéjaan parobahan sumberdaya workspace (Gambar 3). Sumberdaya tiasa robih salaku hasil tina tindakan anu dilakukeun dina Eclipse IDE sorangan atanapi salaku hasil tina sinkronisasi sareng sistem file. Dina duanana kasus, klien nu ngalanggan bewara disadiakeun kalawan inpo wincik tentang parobahan dina bentuk "sumberdaya deltas". A délta ngajelaskeun parobahan antara dua nagara bagian sumberdaya workspace (sub-) tangkal jeung sorangan tangkal, unggal titik nu ngajelaskeun parobahan sumberdaya sarta ngandung daptar délta dina tingkat salajengna nu ngajelaskeun parobahan sumberdaya anak.
Sangu. 3. IResourceChangeEvent jeung IResourceDelta
Mékanisme béwara dumasar kana délta sumberdaya ngagaduhan ciri-ciri ieu:
- Parobahan tunggal sareng seueur parobihan dijelaskeun nganggo struktur anu sami, sabab délta diwangun nganggo prinsip komposisi rekursif. Klién palanggan tiasa ngolah béwara parobahan sumberdaya nganggo turunan rekursif ngaliwatan tangkal délta.
- Délta ngandung émbaran lengkep ngeunaan parobahan sumberdaya, kaasup gerakan sarta / atawa parobahan dina "spidol" pakait sareng eta (Contona, kasalahan kompilasi digambarkeun salaku spidol).
- Kusabab rujukan sumberdaya dijieun ngaliwatan cecekelan, délta alami bisa nuduhkeun sumberdaya jauh.
Salaku baris geura-giru urang tingali, komponén utama desain model sumberdaya mékanisme bewara robah oge relevan pikeun model dumasar-cecekelan séjén.
JDT Inti
Modél sumberdaya ruang kerja Eclipse mangrupikeun modél basa-agnostik dasar. Komponén JDT Core (plugin org.eclipse.jdt.core) nyayogikeun API pikeun nganapigasi sareng nganalisa struktur ruang kerja tina sudut pandang Java, anu disebut "model Java" (Modél Java). API ieu dihartikeun dina watesan elemen Java, sabalikna tina model sumberdaya dasar API, nu diartikeun dina watesan polder jeung file. Antarmuka utama tangkal unsur Java dipidangkeun dina Gbr. 4.
Sangu. 4. Unsur Modél Java
Modél Java ngagunakeun cecekelan sarua / idiom awak salaku model sumberdaya (gambar 5). IJavaElement mangrupikeun cecekelan, sareng JavaElementInfo maénkeun peran awak. Antarbeungeut IJavaElement ngahartikeun protokol umum pikeun sakabéh elemen Java. Sababaraha métode na ngan cecekelan: getElementName (), getParent (), jsb. Obyék JavaElementInfo nyimpen kaayaan unsur anu saluyu: struktur sareng atributna.
Sangu. 5. IJavaElement jeung JavaElementInfo
Modél Java boga sababaraha béda dina palaksanaan cecekelan dasar / desain awak dibandingkeun model sumberdaya. Sakumaha didadarkeun di luhur, dina modél sumberdaya, tangkal unsur, anu titik-titik mangrupa objék info sumberdaya, sagemblengna dikandung dina mémori. Tapi modél Java tiasa gaduh jumlah elemen anu langkung ageung tibatan tangkal sumberdaya, sabab éta ogé ngagambarkeun struktur internal file .java sareng .class: jinis, widang, sareng metode.
Pikeun ngahindarkeun lengkep materializing sakabéh tangkal elemen dina mémori, palaksanaan model Java ngagunakeun cache LRU ukuran kawates info elemen, dimana konci éta cecekelan IJavaElement. obyék info unsur dijieun dina paménta salaku tangkal unsur ieu navigated. Dina hal ieu, item nu pangsaeutikna sering dipaké digusur tina cache, sarta konsumsi memori model urang tetep dugi ka ukuran cache dieusian. Ieu kaunggulan sejen tina desain basis cecekelan, nu lengkep hides rinci palaksanaan misalna tina kode klien.
Mékanisme pikeun ngabéjaan parobahan unsur Java sacara umum sami sareng mékanisme pikeun nyukcruk parobahan sumber daya ruang kerja anu dibahas di luhur. A klien wishing pikeun ngawas parobahan dina model Java ngalanggan bewara, nu digambarkeun salaku objék ElementChangedEvent nu ngandung hiji IJavaElementDelta (Gambar 6).
Sangu. 6. ElementChangedEvent jeung IJavaElementDelta
Modél Java teu ngandung émbaran ngeunaan badan métode atawa resolusi ngaran, jadi pikeun analisis lengkep kode ditulis dina Java, JDT Core nyadiakeun model tambahan (non-cecekelan basis): (tangkal sintaksis abstrak, AST). AST ngagambarkeun hasil parsing téks sumber. Titik AST pakait sareng unsur struktur modul sumber (deklarasi, operator, ekspresi, jsb) sareng ngandung inpormasi ngeunaan koordinat unsur anu aya dina téks sumber, ogé (salaku pilihan) inpormasi ngeunaan resolusi ngaran dina wangun Tumbu ka disebut meungkeut. Bindings mangrupakeun objék nu ngagambarkeun entitas ngaranna, kayaning jenis, métode, jeung variabel, dipikawanoh ku compiler nu. Teu kawas titik AST, nu ngabentuk tangkal, bindings ngarojong cross-rujukan jeung umumna ngabentuk grafik. Kelas abstrak ASTNode nyaéta kelas dasar umum pikeun sakabéh titik AST. Subkelas ASTNode pakait sareng konstruksi sintaksis khusus tina basa Java.
Kusabab tangkal sintaksis bisa meakeun jumlah signifikan memori, JDT cache ngan hiji AST pikeun redaktur aktip. Beda sareng modél Java, AST biasana ditingali salaku modél "panengah", "samentara", unsur-unsur anu klien henteu kedah nahan rujukan ka luar konteks operasi anu nyababkeun nyiptakeun AST.
Tilu model didaptarkeun (model Java, AST, bindings) babarengan ngawangun dadasar pikeun ngawangun "parabot ngembangkeun calakan" dina JDT, kaasup pangropéa Java kuat kalawan sagala rupa "helpers", sagala rupa lampah pikeun ngolah kode sumber (kaasup pangatur daptar impor. nami sareng pormat dumasar kana gaya anu disaluyukeun), milarian sareng alat refactoring. Dina hal ieu, modél Java maénkeun peran anu khusus, sabab éta anu dianggo salaku dasar pikeun ngagambarkeun visual ngeunaan struktur aplikasi anu dikembangkeun (contona, dina Package Explorer, Outline, Search, Call Hierarchy, sareng Hierarki Tipe).
Komponén Eclipse anu dianggo dina 1C: Parabot Pangembangan Perusahaan
Dina Gbr. Gambar 7 nunjukkeun komponén Eclipse anu ngawangun pondasi platform téknologi pikeun 1C: Parabot Pangembangan Perusahaan.
Sangu. 7. Eclipse salaku platform pikeun 1C: Enterprise Development Tools
Platform Eclipse nyadiakeun infrastruktur dasar. Urang nempo sababaraha aspék infrastruktur ieu dina bagian saméméhna.
(EMF) nyadiakeun sarana umum modeling data terstruktur. EMF diintegrasikeun sareng Eclipse Platform, tapi ogé tiasa dianggo nyalira dina aplikasi Java biasa. Seringna, pamekar Eclipse énggal parantos terang pisan sareng EMF, sanaos aranjeunna henteu acan ngartos pinuh ku intricacies tina Platform Eclipse. Salah sahiji alesan pikeun popularitas anu pantes sapertos kitu nyaéta desain universal, anu kalebet, antara lain, API tingkat meta ngahiji, anu ngamungkinkeun anjeun damel sareng modél EMF sacara umum. Palaksanaan dasar pikeun objék modél anu disayogikeun ku EMF sareng subsistem pikeun ngahasilkeun kode modél dumasar kana modél meta sacara signifikan ningkatkeun laju pangwangunan sareng ngirangan jumlah kasalahan. EMF ogé ngandung mékanisme pikeun serializing model, tracking parobahan model, sarta loba deui.
Sapertos alat-alat anu leres-leres umum, EMF cocog pikeun ngarengsekeun rupa-rupa masalah modeling, tapi sababaraha kelas model (contona, model dumasar cecekelan anu dibahas di luhur) tiasa meryogikeun alat modél anu langkung khusus. Ngobrol ngeunaan EMF mangrupikeun tugas anu henteu ngahatur nuhun, khususna dina watesan kawates hiji tulisan, sabab ieu mangrupikeun topik buku anu misah, sareng anu rada kandel. Hayu urang ngan dicatet yén sistem kualitas luhur generalisasi dina dasar EMF diwenangkeun kalahiran sakabeh rentang proyék dedicated ka modeling, nu kaasup dina proyék tingkat luhur. babarengan jeung EMF sorangan. Salah sahiji proyék sapertos nyaéta Eclipse Xtext.
nyadiakeun infrastruktur "modeling téks". Xtext ngagunakeun pikeun parsing téks sumber jeung EMF pikeun ngagambarkeun ASG dihasilkeun (grafik semantik abstrak, nu dasarna mangrupakeun kombinasi antara AST jeung bindings), disebut oge "model semantik". Tata basa nu dimodelkeun ku Xtext digambarkeun dina basa Xtext sorangan. Hal ieu ngamungkinkeun anjeun henteu ngan ukur ngahasilkeun déskripsi grammar pikeun ANTLR, tapi ogé pikeun ménta mékanisme serialisasi AST (nyaéta Xtext nyayogikeun parser sareng unparser), petunjuk kontéks, sareng sajumlah komponén basa anu sanés. Di sisi séjén, basa grammar dipaké dina Xtext kirang fléksibel ti, sebutkeun, basa grammar dipaké dina ANTLR. Ku alatan éta, sakapeung perlu "ngabengkokkeun" basa anu dilaksanakeun kana Xtext, anu biasana henteu janten masalah upami urang nyarioskeun ngeunaan basa anu dikembangkeun ti mimiti, tapi panginten henteu tiasa ditampi pikeun basa anu ngagaduhan sintaksis anu parantos mapan. Sanaos ieu, Xtext ayeuna mangrupikeun alat anu paling dewasa, beunghar fitur, sareng serbaguna dina Eclipse pikeun ngawangun basa pamrograman sareng alat pangembangan pikeun aranjeunna. Khususna, éta mangrupikeun alat idéal pikeun prototyping gancang (basa domain-spésifik, DSL). Salian "inti basa" anu disebatkeun di luhur dumasar kana ANTLR sareng EMF, Xtext nyayogikeun seueur komponén tingkat luhur anu kapaké, kalebet mékanisme indéks, konstruksi incremental, "editor pinter", sareng seueur deui, tapi nyéépkeun handle- model basa dumasar. Sapertos EMF, Xtext mangrupikeun subjek anu pantes pikeun buku anu misah, sareng urang boro tiasa nyarios sakedap ngeunaan sadaya kamampuanna ayeuna.
1C: Parabot Pangembangan Perusahaan aktip ngagunakeun EMF sorangan sareng sajumlah proyék Eclipse Modeling anu sanés. Khususna, Xtext mangrupikeun salah sahiji pondasi alat pangembangan pikeun 1C: Basa perusahaan sapertos basa pamrograman sareng basa query anu diwangun. Dasar séjén pikeun alat pamekaran ieu nyaéta proyék Eclipse Handly, anu bakal urang bahas sacara langkung rinci (tina komponén Eclipse anu didaptarkeun, éta masih paling henteu dipikanyaho).
, subproyék tina proyék tingkat luhur Eclipse Technology, muncul salaku hasil tina kontribusi kode awal ka Eclipse Foundation anu dilakukeun ku 1C di 2014. Saprak harita, 1C terus ngarojong ngembangkeun proyék: Handly committers mangrupakeun karyawan pausahaan. Proyék ieu leutik, tapi ngeusian Ecological anu rada unik dina Eclipse: tujuan utamina nyaéta pikeun ngadukung pamekaran modél dumasar-cecekelan.
Prinsip arsitéktur dasar model dumasar-cecekelan, kayaning gagang / awak idiom, dibahas di luhur ngagunakeun model sumberdaya jeung model Java salaku conto. Éta ogé dicatet yén modél sumber daya sareng modél Java mangrupikeun pondasi penting pikeun alat pangembangan Eclipse Java (JDT). Sarta saprak ampir kabéh *proyék DT Eclipse boga arsitéktur sarupa JDT, eta bakal moal exaggeration hébat disebutkeun yen model dumasar cecekelan underlie loba, lamun teu kabeh IDEs diwangun dina luhureun éta Platform Eclipse. Contona, Eclipse C / C ++ Development Tooling (CDT) gaduh model C / C ++ dumasar cecekelan anu maénkeun peran anu sami dina arsitéktur CDT salaku modél Java dina JDT.
Sateuacan Handly, Eclipse henteu nawiskeun perpustakaan khusus pikeun ngawangun modél basa dumasar kana cecekelan. Modél anu ayeuna aya didamel utamina ku langsung adaptasi kode modél Java (alias copy/paste), dina kasus dimana eta ngamungkinkeun Lisensi Publik Eclipse (EPL). (Jelas, ieu téh biasana lain masalah hukum, sebutkeun, proyék Eclipse sorangan, tapi henteu pikeun produk sumber katutup.) Salian haphazardness alamiah na, téhnik ieu ngenalkeun masalah well-dipikawanoh: duplikasi kode diwanohkeun ku nalika adaptasi jeung kasalahan. jsb. Anu langkung parah nyaéta modél anu dihasilkeun tetep "hal dina diri" sareng henteu ngamangpaatkeun poténsial pikeun ngahijikeun. Tapi ngasingkeun konsép sareng protokol umum pikeun modél basa dumasar kana cecekelan tiasa nyababkeun nyiptakeun komponén anu tiasa dianggo deui pikeun damel sareng aranjeunna, sami sareng anu kajantenan dina kasus EMF.
Ieu sanés yén Eclipse henteu ngartos masalah ieu. Balik deui ka 2005 , nyimpulkeun pangalaman ngembangkeun prototipe CDT, kudu nyieun infrastruktur umum pikeun model basa, kaasup model dumasar-cecekelan. Tapi, sakumaha mindeng kajadian, alatan tugas prioritas luhur, palaksanaan gagasan ieu pernah meunang sabudeureun eta. Samentara éta, faktorisasi kode *DT masih salah sahiji topik underdeveloped dina Eclipse.
Dina rasa anu tangtu, proyék Handly dirancang pikeun ngarengsekeun masalah anu sami sareng EMF, tapi pikeun modél dumasar cecekelan, sareng utamina dina basa (nyaéta, ngalambangkeun unsur-unsur struktur sababaraha basa pamrograman). Tujuan utama anu disetél nalika ngarancang Handly dibéréndélkeun di handap:
- Idéntifikasi abstraksi utama wewengkon subjek.
- Ngurangan usaha jeung ngaronjatkeun kualitas palaksanaan model basa dumasar cecekelan ngaliwatan pamakéan ulang kode.
- Nyadiakeun API meta-tingkat hasil ngahijikeun Tatar kana model hasilna, sahingga mungkin mun nyieun komponén IDE umum anu dianggo kalayan model basis cecekelan basa.
- Kalenturan sareng skalabilitas.
- Integrasi sareng Xtext (dina lapisan anu misah).
Pikeun nyorot konsép sareng protokol anu umum, palaksanaan modél dumasar kana cecekelan basa dianalisis. Antarmuka utama sareng palaksanaan dasar anu disayogikeun ku Handly dipidangkeun dina Gbr. 8.
Sangu. 8. Interfaces umum tur palaksanaan dasar elemen Handly
Antarbeungeut IElement ngagambarkeun cecekelan hiji unsur sarta umum pikeun elemen sadaya model Handly basis. Kelas abstrak Unsur implements cecekelan generalized / mékanisme awak (Gbr. 9).
Sangu. 9. IElement jeung cecekelan generik / palaksanaan awak
Salaku tambahan, Handly nyayogikeun mékanisme umum pikeun ngabéjaan ngeunaan parobahan dina elemen modél (Gbr. 10). Sakumaha anjeun tiasa tingali, éta sacara lega sarupa mékanisme bewara dilaksanakeun dina model sumberdaya sarta model Java, sarta ngagunakeun IElementDelta pikeun nyadiakeun ngagambarkeun hasil ngahijikeun Tatar informasi robah unsur.
Sangu. 10. Antarmuka umum sareng palaksanaan dasar mékanisme bewara Handly
Bagian Handly dibahas di luhur (Gbr. 9 jeung 10) bisa dipaké pikeun ngagambarkeun ampir sagala model dumasar-cecekelan. Pikeun nyiptakeun linguistik model, proyék nawarkeun fungsionalitas tambahan - hususna, interfaces umum jeung palaksanaan dasar pikeun elemen struktur téks sumber, nu disebut elemen sumber (Gbr. 8). Antarbeungeut ISourceFile ngagambarkeun file sumber, sareng ISourceConstruct ngagambarkeun unsur dina file sumber. Kelas abstrak SourceFile sareng SourceConstruct ngalaksanakeun mékanisme umum pikeun ngadukung damel sareng file sumber sareng unsur-unsurna, contona, damel sareng panyangga téks, ngabeungkeut koordinat unsur dina téks sumber, nyumponan modél sareng eusi ayeuna tina panyangga salinan anu tiasa dianggo. , jsb. Nerapkeun mékanisme ieu biasana cukup tangtangan, sarta Handly bisa nyata ngurangan usaha ngembangkeun model basa dumasar-cecekelan ku nyadiakeun palaksanaan basa kualitas luhur.
Salian mékanisme inti nu didaptarkeun di luhur, Handly nyadiakeun infrastruktur pikeun panyangga téks na snapshots, rojongan pikeun integrasi jeung redaktur kode sumber (kaasup integrasi out-of-the-box jeung redaktur Xtext), kitu ogé sababaraha komponén UI umum nu. dianggo sareng éditor kode sumber. Model anu gampang sapertos kerangka kerangka. Pikeun ngagambarkeun kamampuanana, proyék éta nyayogikeun sababaraha conto, kalebet palaksanaan modél Java di Handly. (Dibandingkeun jeung palaksanaan pinuh ku model Java di JDT, model ieu ngahaja rada disederhanakeun pikeun kajelasan gede.)
Sakumaha anu kacatet sateuacana, fokus utama dina rarancang awal Handly sareng pamekaran salajengna nyaéta sareng tetep dina skalabilitas sareng kalenturan.
Sacara prinsip, model dumasar cecekelan skala cukup alus "ku desain". Contona, idiom cecekelan / awak ngidinan Anjeun pikeun ngawatesan jumlah memori dihakan ku model. Tapi aya ogé nuances. Ku kituna, nalika nguji Handly pikeun scalability, masalah kapanggih dina palaksanaan mékanisme bewara - nalika sajumlah badag elemen anu robah, ngawangun deltas nyandak teuing waktos. Tétéla yén masalah anu sami aya dina modél JDT Java, dimana kode anu saluyu sakali diadaptasi. Kami ngalereskeun bug di Handly sareng nyiapkeun patch anu sami pikeun JDT, anu ditampi kalayan syukur. Ieu ngan hiji conto dimana ngenalkeun Handly kana palaksanaan modél anu tos aya tiasa berpotensi mangpaat, sabab dina hal ieu bug sapertos kitu tiasa dibenerkeun dina hiji tempat.
Pikeun ngalaksanakeun palaksanaan Handly kana palaksanaan modél anu aya sacara téknis, perpustakaan kedah gaduh kalenturan anu signifikan. Masalah utama nyaéta pikeun ngajaga kasaluyuan mundur dina modél API. Masalah ieu direngsekeun dina ku jelas misahkeun API model-spésifik, diartikeun tur pinuh dikawasa ku pamekar, ti ngahijikeun Tatar API meta-tingkat disadiakeun ku perpustakaan. Ieu mah ngan saukur ngajadikeun éta téhnisna mungkin pikeun nerapkeun Handly kana implementations aya, tapi ogé méré pamekar modél anyar kabebasan signifikan nalika ngarancang API.
Kalenturan ogé ngagaduhan aspék anu sanés. Contona, Handly maksakeun ampir euweuh larangan dina struktur modél sarta bisa dipaké pikeun modél duanana basa tujuan umum jeung domain-spésifik. Nalika ngawangun struktur file sumber, Handly henteu resep naon waé bentuk perwakilan AST khusus sareng, prinsipna, henteu meryogikeun ayana AST sorangan, sahingga mastikeun kasaluyuan sareng ampir mékanisme parsing. Tungtungna, Handly ngadukung integrasi lengkep sareng ruang kerja Eclipse, tapi ogé tiasa langsung damel sareng sistem file berkat integrasina sareng (EFS).
Vérsi ayeuna kaluar dina Désémber 2016. Sanaos kanyataan yén proyék éta ayeuna aya dina kaayaan inkubasi sareng API henteu acan tungtungna dibenerkeun, Handly parantos dianggo dina dua produk komérsial ageung anu nyandak résiko akting salaku "pengguna awal", sareng, kuring kedah nyarios, teu acan kaduhung.
Sakumaha anu kacatet di luhur, salah sahiji produk ieu nyaéta 1C: Parabot Pangembangan Perusahaan, dimana Handly dianggo ti mimiti ngamodelkeun unsur-unsur struktur tingkat luhur sapertos 1C: Basa Perusahaan salaku basa pamrograman sareng basa query anu diwangun. . produk sejen kirang dipikawanoh ku masarakat umum. Ieu , lingkungan desain terpadu pikeun prosésor instruksi-set khusus aplikasi (ASIP), dianggo boh dina perusahaan Czech Codasip sorangan sareng ku klienna, kalebet , , , . Codasip geus ngagunakeun Handly dina produksi saprak 2015, dimimitian ku versi Handly 0.2. Pelepasan panganyarna tina Codasip Studio nganggo versi 0.5, dirilis dina Juni 2016. Ondřej Ilčík, anu mingpin pamekaran IDE di Codasip, aya hubungan sareng proyék éta, nyayogikeun tanggapan anu penting atas nama "pengguna pihak katilu". Anjeunna malah bisa manggihan sababaraha waktu luang pikeun langsung ilubiung dina ngembangkeun proyék, nerapkeun lapisan UI (~ 4000 garis kode) pikeun salah sahiji conto Handly, model Java. Inpormasi anu langkung rinci ngeunaan pamakean Handly ku anu nganggo tiasa dipendakan dina halaman proyék.
Urang ngaharepkeun sanggeus sékrési versi 1.0 kalawan jaminan stabilitas API jeung proyék ninggalkeun kaayaan inkubasi, Handly bakal boga adopters anyar. Samentara éta, proyék terus nguji sarta salajengna ngaronjatkeun API, ngaleupaskeun dua "utama" Kaluaran per taun - dina Juni (tanggal sarua jeung release Eclipse simultaneous) jeung Désémber, nyadiakeun jadwal diprediksi yén adopters bisa ngandelkeun. Urang ogé tiasa nambihan yén "tingkat bug" proyék tetep dina tingkat anu konsistén rendah sareng Handly parantos tiasa dipercaya dina produk anu diadopsi awal ti saprak versi anu munggaran. Pikeun langkung ngajalajah Eclipse Handly, anjeun tiasa nganggo и .
sumber: www.habr.com