Eclipse-ը որպես տեխնոլոգիական հարթակ 1C:Enterprise Development Tools-ի համար

Հավանաբար Խավարում նա վաղուց հատուկ ներածության կարիք չունի: Շատերը ծանոթ են Eclipse-ին Eclipse Java-ի մշակման գործիքների շնորհիվ (JDT) Հենց այս հայտնի բաց կոդով Java IDE-ն է, որ մշակողների մեծամասնությունը կապում է «Eclipse» բառի հետ: Այնուամենայնիվ, Eclipse-ը և՛ ընդարձակվող հարթակ է զարգացման գործիքների ինտեգրման համար (Eclipse Platform), և՛ դրա հիման վրա կառուցված մի շարք IDE-ներ, ներառյալ JDT-ն: Eclipse-ը և՛ Eclipse Project-ն է՝ վերին մակարդակի նախագիծը, որը համակարգում է Eclipse պլատֆորմի և JDT-ի զարգացումը, և՛ Eclipse SDK-ն՝ այդ զարգացման ստացված արդյունքը: Վերջապես, Eclipse-ը բաց կոդով հիմնադրամ է՝ նախագծերի հսկայական համայնքով, որոնցից ոչ բոլորն են գրված Java-ով կամ կապված են զարգացման գործիքների հետ (օրինակ՝ նախագծեր Eclipse IoT и Խավարման գիտություն) Eclipse-ի աշխարհը շատ բազմազան է:

Այս հոդվածում, որն իր բնույթով ակնարկ է, մենք կփորձենք դիտարկել Eclipse ճարտարապետության որոշ հիմունքներ՝ որպես ինտեգրված զարգացման գործիքներ կառուցելու հարթակ և նախնական պատկերացում տալ Eclipse բաղադրիչների մասին, որոնք կազմում են տեխնոլոգիայի հիմքը: հարթակ «նոր կոնֆիգուրատորի» 1C: Enterprise-ի համար: 1C: Ձեռնարկությունների զարգացման գործիքներ. Իհարկե, նման վերանայումն անխուսափելիորեն կլինի հիմնականում մակերեսային և բավականին սահմանափակ, ներառյալ այն պատճառով, որ մենք կենտրոնանում ենք ոչ միայն Eclipse-ի մշակողների վրա՝ որպես թիրախային լսարանի: Այնուամենայնիվ, հուսով ենք, որ նույնիսկ փորձառու Eclipse մշակողները կկարողանան հետաքրքիր տեղեկություններ գտնել հոդվածում: Օրինակ, մենք կխոսենք «Խավարման գաղտնիքներից» մեկի մասին՝ համեմատաբար նոր և քիչ հայտնի նախագծի մասին։ Eclipse Handly, որը հիմնադրվել և աջակցում է 1C.

Eclipse Architecture-ի ներածություն

Եկեք նախ նայենք Eclipse ճարտարապետության որոշ ընդհանուր ասպեկտներին՝ օգտագործելով օրինակը Eclipse Java-ի մշակման գործիքներ (JDT): JDT-ի ընտրությունը որպես օրինակ պատահական չէ։ Սա առաջին ինտեգրված զարգացման միջավայրն է, որը հայտնվել է Eclipse-ում: Այլ *DT Eclipse նախագծերը, ինչպիսիք են Eclipse C/C++ Development Tooling-ը (CDT), ստեղծվել են ավելի ուշ և փոխառել են ինչպես հիմնական ճարտարապետական ​​սկզբունքները, այնպես էլ անհատական ​​կոդերի հատվածները JDT-ից: JDT-ում ամրագրված ճարտարապետության հիմունքները առ այսօր տեղին են Eclipse հարթակի վրա կառուցված գրեթե ցանկացած IDE-ի համար, ներառյալ 1C:Enterprise Development Tools-ը:

Նախևառաջ, հարկ է նշել, որ Eclipse-ին բնորոշ է բավականին հստակ ճարտարապետական ​​շերտավորում՝ լեզվից անկախ ֆունկցիոնալության տարանջատմամբ հատուկ ծրագրավորման լեզուներին աջակցելու համար նախատեսված ֆունկցիոնալությունից և UI-ից անկախ «հիմնական» բաղադրիչների տարանջատմամբ կապված բաղադրիչներից: աջակցող օգտագործողի միջերեսով:

Այսպիսով, Eclipse պլատֆորմը սահմանում է ընդհանուր, լեզվից անկախ ենթակառուցվածք, իսկ Java-ի մշակման գործիքները Eclipse-ին ավելացնում են լիարժեք Java IDE: Ե՛վ Eclipse պլատֆորմը, և՛ JDT-ը բաղկացած են մի քանի բաղադրիչներից, որոնցից յուրաքանչյուրը պատկանում է կամ UI-ից անկախ «միջուկին», կամ UI շերտին (Նկար 1):

Բրինձ. 1. Eclipse Platform և JDT

Եկեք թվարկենք Eclipse հարթակի հիմնական բաղադրիչները.

• Runtime — Սահմանում է plugin-ի ենթակառուցվածքը: Խավարումը բնութագրվում է մոդուլային ճարտարապետությամբ: Ըստ էության, Eclipse-ը «երկարացման կետերի» և «ընդլայնումների» հավաքածու է։
• Աշխատանքային տարածք — Կառավարում է մեկ կամ մի քանի նախագծեր: Նախագիծը բաղկացած է թղթապանակներից և ֆայլերից, որոնք քարտեզագրված են անմիջապես ֆայլային համակարգին:
• Ստանդարտ վիդջեթների գործիքակազմ (SWT) - Ապահովում է հիմնական ինտերֆեյսի տարրերը, որոնք ինտեգրված են օպերացիոն համակարգին:
• JFace — Ապահովում է մի շարք UI շրջանակներ՝ կառուցված SWT-ի վրա:
• Workbench — Սահմանում է Eclipse UI պարադիգմը՝ խմբագիրներ, տեսակետներ, հեռանկարներ:

Պետք է ասել, որ Eclipse պլատֆորմը տրամադրում է նաև բազմաթիվ այլ օգտակար բաղադրիչներ՝ ինտեգրված զարգացման գործիքներ ստեղծելու համար, այդ թվում՝ Debug, Compare, Search և Team: Հարկ է հատուկ նշել JFace Text-ը, որը հիմք է հանդիսանում սկզբնական կոդի «խելացի խմբագիրներ» ստեղծելու համար: Ցավոք, այս բաղադրիչների, ինչպես նաև UI շերտի բաղադրիչների նույնիսկ հպանցիկ ուսումնասիրությունը հնարավոր չէ այս հոդվածի շրջանակներում, ուստի այս բաժնի մնացած մասում մենք կսահմանափակվենք հիմնական «հիմնական» բաղադրիչների ակնարկով: Eclipse հարթակը և JDT-ն:

Հիմնական Runtime

Eclipse հավելվածի ենթակառուցվածքը հիմնված է OSGi և նախատեսված է նախագծով Eclipse Equinox. Յուրաքանչյուր Eclipse հավելվածը OSGi փաթեթ է: OSGi-ի հստակեցումը սահմանում է, մասնավորապես, տարբերակների և կախվածության լուծման մեխանիզմներ: Այս ստանդարտ մեխանիզմներից բացի, Equinox-ը ներկայացնում է հայեցակարգը ընդլայնման կետեր. Յուրաքանչյուր փլագին կարող է սահմանել իր սեփական ընդլայնման կետերը, ինչպես նաև համակարգին ներմուծել լրացուցիչ գործառույթներ («ընդլայնումներ»)՝ օգտագործելով նույն կամ այլ պլագինների կողմից սահմանված ընդլայնման կետերը: OSGi և Equinox մեխանիզմների ցանկացած մանրամասն նկարագրություն այս հոդվածի շրջանակներից դուրս է: Եկեք միայն նշենք, որ Eclipse-ում մոդուլյարացումը ամբողջական է (ցանկացած ենթահամակարգ, ներառյալ Runtime-ը, բաղկացած է մեկ կամ մի քանի պլագիններից), և Eclipse-ում գրեթե ամեն ինչ ընդլայնում է: Ավելին, այս սկզբունքները ներդրված էին Eclipse ճարտարապետության մեջ OSGi-ի ներդրումից շատ առաջ (այդ ժամանակ նրանք օգտագործում էին իրենց սեփական տեխնոլոգիան՝ շատ նման OSGi-ին):

Հիմնական աշխատանքային տարածք

Գրեթե ցանկացած ինտեգրված զարգացման միջավայր, որը կառուցված է Eclipse պլատֆորմի վերևում, աշխատում է Eclipse աշխատանքային տարածքի հետ: Դա աշխատանքային տարածքն է, որը սովորաբար պարունակում է IDE-ում մշակված հավելվածի սկզբնական կոդը: Աշխատանքային տարածքը քարտեզագրվում է անմիջապես ֆայլային համակարգին և բաղկացած է նախագծերից, որոնք պարունակում են թղթապանակներ և ֆայլեր: Այս նախագծերը, թղթապանակները և ֆայլերը կոչվում են ռեսուրսներ աշխատանքային տարածք. Աշխատանքային տարածքի իրականացումը Eclipse-ում ծառայում է որպես քեշ ֆայլային համակարգի հետ կապված, ինչը հնարավորություն է տալիս զգալիորեն արագացնել ռեսուրսների ծառի անցումը: Բացի այդ, աշխատանքային տարածքը տրամադրում է մի շարք լրացուցիչ ծառայություններ, այդ թվում ռեսուրսների փոփոխությունների ծանուցման մեխանիզմ и հավելյալ շինարարական ենթակառուցվածք.

Core Resources բաղադրիչը (org.eclipse.core.resources plugin) պատասխանատու է աշխատանքային տարածքին և դրա ռեսուրսներին աջակցելու համար: Մասնավորապես, այս բաղադրիչը ապահովում է ծրագրային մուտք դեպի աշխատանքային տարածք ձևով ռեսուրսների մոդելներ. Այս մոդելի հետ արդյունավետ աշխատելու համար հաճախորդներին անհրաժեշտ է ռեսուրսի հղումը ներկայացնելու պարզ միջոց: Այս դեպքում, ցանկալի կլիներ, որ այն օբյեկտը, որն ուղղակիորեն պահում է ռեսուրսի վիճակը մոդելում, հաճախորդի հասանելիությունից թաքցնելը։ Հակառակ դեպքում, օրինակ, ֆայլը ջնջելու դեպքում, հաճախորդը կարող է շարունակել պահել այն օբյեկտը, որն այլևս մոդելում չէ՝ դրանից բխող խնդիրներով: Eclipse-ը լուծում է այս խնդիրը՝ օգտագործելով մի բան, որը կոչվում է բռնակ ռեսուրս. Handle-ը գործում է որպես բանալի (այն գիտի միայն աշխատանքային տարածքում գտնվող ռեսուրսի ուղին) և ամբողջությամբ վերահսկում է մուտքը ներքին մոդելի օբյեկտ, որն ուղղակիորեն պահում է տեղեկատվություն ռեսուրսի վիճակի մասին: Այս դիզայնը նախշի տարբերակ է Բռնակ/Թափ.

Բրինձ. Նկար 2-ը ցույց է տալիս Handle/Body բառապաշարը, ինչպես կիրառվում է ռեսուրսի մոդելի համար: IRResource ինտերֆեյսը ներկայացնում է ռեսուրսի բռնիչը և հանդիսանում է API, ի տարբերություն Resource դասի, որն իրականացնում է այս ինտերֆեյսը, և ResourceInfo դասի, որը ներկայացնում է մարմինը, որոնք API-ներ չեն: Մենք շեշտում ենք, որ handle-ը գիտի միայն ռեսուրսի ուղին աշխատանքային տարածքի արմատի համեմատ և չի պարունակում ռեսուրսի տեղեկատվության հղում: Ռեսուրսների տեղեկատվական օբյեկտները կազմում են այսպես կոչված «տարրերի ծառ»: Այս տվյալների կառուցվածքը ամբողջությամբ նյութականացված է հիշողության մեջ: Բռնակին համապատասխանող ռեսուրսի տեղեկատվության օրինակը գտնելու համար տարրի ծառը անցնում է այդ բռնակում պահվող ուղու համաձայն:

Բրինձ. 2. IRResource և ResourceInfo

Ինչպես կտեսնենք ավելի ուշ, ռեսուրսների մոդելի հիմնական դիզայնը (մենք կարող ենք այն անվանել բռնակի վրա հիմնված) օգտագործվում է Eclipse-ում նաև այլ մոդելների համար: Առայժմ, եկեք թվարկենք այս դիզայնի մի քանի տարբերակիչ հատկություններ.

• Բռնակը արժեքային օբյեկտ է: Արժեքային օբյեկտները անփոփոխ օբյեկտներ են, որոնց հավասարությունը հիմնված չէ ինքնության վրա: Նման առարկաները կարող են ապահով կերպով օգտագործվել որպես բանալի հաշված տարաներում: Բռնակի բազմաթիվ օրինակներ կարող են հղում կատարել նույն ռեսուրսին: Նրանց համեմատելու համար հարկավոր է օգտագործել հավասար (Object) մեթոդը։
• Handle-ը սահմանում է ռեսուրսի վարքագիծը, բայց չի պարունակում տեղեկատվություն ռեսուրսի վիճակի մասին (միակ տվյալը, որը պահում է «բանալին» է՝ դեպի ռեսուրս տանող ճանապարհը):
• Handle-ը կարող է վերաբերել ռեսուրսին, որը գոյություն չունի (կամ ռեսուրս, որը դեռ չի ստեղծվել, կամ ռեսուրս, որն արդեն ջնջվել է): Ռեսուրսի առկայությունը կարելի է ստուգել IResource.exists() մեթոդի միջոցով։
• Որոշ գործողություններ կարող են իրականացվել՝ հիմնվելով միայն բռնակում պահվող տեղեկատվության վրա (այսպես կոչված՝ միայն բռնակով գործողություններ): Օրինակներ են IResource.getParent(), getFullPath() և այլն: Նման գործողության հաջողության համար ռեսուրսը պետք չէ գոյություն ունենալ: Գործողությունները, որոնք պահանջում են ռեսուրսի գոյությունը հաջողության հասնելու համար, գցում են CoreException, եթե ռեսուրսը գոյություն չունի:

Eclipse-ն ապահովում է աշխատանքային տարածքի ռեսուրսների փոփոխությունների ծանուցման արդյունավետ մեխանիզմ (Նկար 3): Ռեսուրսները կարող են փոխվել կամ Eclipse IDE-ում կատարված գործողությունների արդյունքում, կամ ֆայլային համակարգի հետ համաժամացման արդյունքում: Երկու դեպքում էլ ծանուցումներին բաժանորդագրված հաճախորդներին տրամադրվում է մանրամասն տեղեկատվություն փոփոխությունների մասին «ռեսուրսների դելտաների» տեսքով: Դելտան նկարագրում է աշխատանքային տարածքի ռեսուրսի (ենթածառի) երկու վիճակների միջև փոփոխությունները և ինքնին ծառ է, որի յուրաքանչյուր հանգույց նկարագրում է ռեսուրսի փոփոխությունը և պարունակում է հաջորդ մակարդակի դելտաների ցանկ, որոնք նկարագրում են երեխայի ռեսուրսների փոփոխությունները:

Բրինձ. 3. IResourceChangeEvent և IResourceDelta

Ռեսուրսների դելտաների վրա հիմնված ծանուցման մեխանիզմն ունի հետևյալ բնութագրերը.

• Մեկ փոփոխություն և բազմաթիվ փոփոխություններ նկարագրված են նույն կառուցվածքով, քանի որ դելտան կառուցված է ռեկուրսիվ կազմի սկզբունքով։ Բաժանորդների հաճախորդները կարող են մշակել ռեսուրսների փոփոխության ծանուցումները՝ օգտագործելով ռեկուրսիվ ծագումը դելտաների ծառի միջով:
• Դելտան պարունակում է ամբողջական տեղեկատվություն ռեսուրսի փոփոխությունների մասին, ներառյալ դրա շարժը և/կամ դրա հետ կապված «մարկերների» փոփոխությունները (օրինակ, կոմպիլյացիայի սխալները ներկայացված են որպես նշիչներ):
• Քանի որ ռեսուրսների հղումները կատարվում են բռնակի միջոցով, դելտան, բնականաբար, կարող է հղում կատարել հեռավոր ռեսուրսին:

Ինչպես շուտով կտեսնենք, ռեսուրսների մոդելի փոփոխության ծանուցման մեխանիզմի նախագծման հիմնական բաղադրիչները տեղին են նաև բռնակի վրա հիմնված այլ մոդելների համար:

JDT Core

Eclipse աշխատանքային տարածքի ռեսուրսի մոդելը հիմնարար լեզվաագնոստիկ մոդել է: JDT Core բաղադրիչը (plugin org.eclipse.jdt.core) ապահովում է API՝ Java-ի տեսանկյունից աշխատանքային տարածքի կառուցվածքը նավարկելու և վերլուծելու համար, այսպես կոչված «Java մոդելը» (Java մոդելը) Այս API-ն սահմանվում է Java-ի տարրերով, ի տարբերություն հիմքում ընկած ռեսուրսների մոդելի API-ի, որը սահմանվում է թղթապանակների և ֆայլերի առումով: Java տարրերի ծառի հիմնական միջերեսները ներկայացված են Նկ. 4.

Բրինձ. 4. Java Model Elements

Java մոդելն օգտագործում է նույն բռնակ/մարմնի արտահայտությունը, ինչ ռեսուրսի մոդելը (Նկար 5): IJavaElement-ը բռնակն է, իսկ JavaElementInfo-ն խաղում է մարմնի դերը: IJavaElement ինտերֆեյսը սահմանում է բոլոր Java տարրերի համար ընդհանուր արձանագրություն: Դրա որոշ մեթոդներ միայն handle-ով են՝ getElementName(), getParent() և այլն: JavaElementInfo օբյեկտը պահպանում է համապատասխան տարրի վիճակը՝ նրա կառուցվածքը և ատրիբուտները:

Բրինձ. 5. IJavaElement և JavaElementInfo

Java մոդելը որոշ տարբերություններ ունի հիմնական բռնակի/մարմնի դիզայնի իրականացման մեջ՝ համեմատած ռեսուրսների մոդելի հետ: Ինչպես նշվեց վերևում, ռեսուրսների մոդելում տարրերի ծառը, որի հանգույցները ռեսուրսի տեղեկատվական օբյեկտներ են, ամբողջությամբ պարունակվում է հիշողության մեջ: Բայց Java մոդելը կարող է զգալիորեն ավելի մեծ թվով էլեմենտներ ունենալ, քան ռեսուրսների ծառը, քանի որ այն նաև ներկայացնում է .java և .class ֆայլերի ներքին կառուցվածքը՝ տեսակներ, դաշտեր և մեթոդներ:

Հիշողության մեջ տարրերի ամբողջ ծառի ամբողջական նյութականացումից խուսափելու համար Java մոդելի ներդրումն օգտագործում է տարրերի տեղեկատվության սահմանափակ չափի LRU քեշ, որտեղ բանալին IJavaElement-ի կարգավորիչն է: տարրի տեղեկատվական օբյեկտները ստեղծվում են ըստ պահանջի, քանի որ տարրի ծառը նավարկվում է: Այս դեպքում ամենաքիչ օգտագործվող տարրերը դուրս են մղվում քեշից, և մոդելի հիշողության սպառումը մնում է սահմանափակված քեշի նշված չափով: Սա բռնակի վրա հիմնված դիզայնի ևս մեկ առավելություն է, որն ամբողջությամբ թաքցնում է իրականացման նման մանրամասները հաճախորդի կոդից:

Java տարրերի փոփոխություններին ծանուցելու մեխանիզմը ընդհանուր առմամբ նման է վերը քննարկված աշխատանքային տարածքի ռեսուրսների փոփոխություններին հետևելու մեխանիզմին: Հաճախորդը, որը ցանկանում է վերահսկել Java մոդելի փոփոխությունները, բաժանորդագրվում է ծանուցումների, որոնք ներկայացված են որպես ElementChangedEvent օբյեկտ, որը պարունակում է IJavaElementDelta (Նկար 6):

Բրինձ. 6. ElementChangedEvent և IJavaElementDelta

Java մոդելը չի ​​պարունակում տեղեկատվություն մեթոդի մարմինների կամ անվան լուծման մասին, ուստի Java-ում գրված կոդի մանրամասն վերլուծության համար JDT Core-ը տրամադրում է լրացուցիչ (ոչ բռնակի վրա հիմնված) մոդել. վերացական շարահյուսական ծառ (վերացական շարահյուսական ծառ, ՀՍՏ): AST-ը ներկայացնում է սկզբնաղբյուր տեքստի վերլուծության արդյունքը: AST հանգույցները համապատասխանում են աղբյուրի մոդուլի կառուցվածքի տարրերին (հայտարարություններ, օպերատորներ, արտահայտություններ և այլն) և պարունակում են տեղեկատվություն սկզբնաղբյուր տեքստում համապատասխան տարրի կոորդինատների մասին, ինչպես նաև (որպես տարբերակ) տեղեկություններ անվան լուծման մասին: կապերի ձևը այսպես կոչված կապեր. Կապակցումներն այն օբյեկտներն են, որոնք ներկայացնում են անվանված սուբյեկտներ, ինչպիսիք են տեսակները, մեթոդները և փոփոխականները, որոնք հայտնի են կոմպիլյատորին: Ի տարբերություն AST հանգույցների, որոնք կազմում են ծառ, կապանքները աջակցում են խաչաձև հղումներին և, ընդհանուր առմամբ, կազմում են գրաֆիկ: ASTNode-ի վերացական դասը ընդհանուր բազային դաս է բոլոր AST հանգույցների համար: ASTNode ենթադասերը համապատասխանում են Java լեզվի հատուկ շարահյուսական կառուցվածքներին:

Քանի որ շարահյուսական ծառերը կարող են սպառել զգալի քանակությամբ հիշողություն, JDT-ն ակտիվ խմբագրի համար պահում է միայն մեկ AST: Ի տարբերություն Java մոդելի, AST-ը սովորաբար դիտվում է որպես «միջանկյալ», «ժամանակավոր» մոդել, որի անդամները չպետք է մատնանշվեն հաճախորդների կողմից AST-ի ստեղծմանը հանգեցրած գործողության համատեքստից դուրս:

Թվարկված երեք մոդելները (Java մոդել, AST, կապեր) միասին հիմք են հանդիսանում JDT-ում «խելացի զարգացման գործիքներ» ստեղծելու համար, ներառյալ հզոր Java խմբագիր տարբեր «օգնականներով», տարբեր գործողություններ՝ ելակետային կոդի մշակման համար (ներառյալ ներմուծման ցուցակի կազմակերպումը: անուններ և ձևաչափում ըստ հարմարեցված ոճի), որոնման և վերամշակման գործիքներ: Այս դեպքում Java մոդելը հատուկ դեր է խաղում, քանի որ հենց դա է օգտագործվում որպես մշակվող հավելվածի կառուցվածքի տեսողական ներկայացման հիմք (օրինակ՝ Package Explorer, Outline, Search, Call Hierarchy և Տիպի հիերարխիա):

Eclipse բաղադրիչները, որոնք օգտագործվում են 1C:Enterprise Developments Tools-ում

Նկ. Նկար 7-ը ցույց է տալիս Eclipse բաղադրիչները, որոնք կազմում են 1C:Enterprise Development Tools-ի տեխնոլոգիական հարթակի հիմքը:

Բրինձ. 7. Eclipse-ը որպես հարթակ 1C:Enterprise Development Tools-ի համար

Eclipse հարթակ ապահովում է հիմնական ենթակառուցվածքը. Մենք նայեցինք այս ենթակառուցվածքի որոշ ասպեկտներին նախորդ բաժնում:

Eclipse Modeling Framework (EMF) ապահովում է կառուցվածքային տվյալների մոդելավորման ընդհանուր միջոց: EMF-ը ինտեգրված է Eclipse պլատֆորմի հետ, բայց կարող է օգտագործվել նաև առանձին Java-ի սովորական հավելվածներում: Շատ հաճախ, Eclipse-ի նոր մշակողները արդեն լավ ծանոթ են EMF-ին, թեև դեռևս լիովին չեն հասկանում Eclipse պլատֆորմի բարդությունները: Նման արժանի ժողովրդականության պատճառներից մեկը ունիվերսալ դիզայնն է, որը ներառում է, ի թիվս այլ բաների, միասնական մետա մակարդակի API, որը թույլ է տալիս ընդհանուր ձևով աշխատել ցանկացած EMF մոդելի հետ: EMF-ի կողմից տրամադրված մոդելային օբյեկտների հիմնական իրականացումները և մետա-մոդելի վրա հիմնված մոդելային կոդի ստեղծման ենթահամակարգը զգալիորեն մեծացնում է զարգացման արագությունը և նվազեցնում սխալների քանակը: EMF-ը պարունակում է նաև մոդելների սերիականացման մեխանիզմներ, մոդելի փոփոխություններին հետևելու և շատ ավելին:

Ինչպես ցանկացած իսկապես ընդհանուր նշանակության գործիք, EMF-ը հարմար է մոդելավորման խնդիրների լայն շրջանակի լուծման համար, սակայն մոդելների որոշ դասեր (օրինակ՝ վերը քննարկված բռնակով մոդելները) կարող են պահանջել ավելի մասնագիտացված մոդելավորման գործիքներ: EMF-ի մասին խոսելն անշնորհակալ գործ է, հատկապես մեկ հոդվածի սահմանափակ սահմաններում, քանի որ սա առանձին գրքի թեմա է, այն էլ՝ բավականին հաստ: Նշենք միայն, որ EMF-ի հիմքում ընկած ընդհանրացումների բարձրորակ համակարգը թույլ է տվել մոդելավորմանը նվիրված մի շարք նախագծերի ծնունդ, որոնք ներառված են վերին մակարդակի նախագծում: Eclipse մոդելավորում EMF-ի հետ միասին: Նման նախագծերից մեկը Eclipse Xtext-ն է:

Eclipse Xtext ապահովում է «տեքստի մոդելավորման» ենթակառուցվածք: Xtext օգտագործում ANTLR սկզբնաղբյուր տեքստի և EMF-ը վերլուծելու համար՝ ստացված ASG-ը (վերացական իմաստային գրաֆիկ, որն ըստ էության AST-ի և կապերի համակցություն է), որը նաև կոչվում է «իմաստային մոդել»: Xtext-ի կողմից մոդելավորված լեզվի քերականությունը նկարագրված է Xtext-ի սեփական լեզվով։ Սա թույլ է տալիս ոչ միայն ստեղծել ANTLR-ի քերականական նկարագրություն, այլև ստանալ AST սերիալացման մեխանիզմ (այսինքն՝ Xtext-ը տրամադրում է և՛ վերլուծիչ, և՛ վերլուծիչ), համատեքստի հուշում և մի շարք այլ լեզվական բաղադրիչներ: Մյուս կողմից, Xtext-ում օգտագործվող քերականական լեզուն ավելի քիչ ճկուն է, քան, ասենք, ANTLR-ում օգտագործվող քերականական լեզուն: Հետևաբար, երբեմն անհրաժեշտ է «թեքել» իրականացված լեզուն Xtext-ին, ինչը սովորաբար խնդիր չէ, եթե մենք խոսում ենք զրոյից մշակվող լեզվի մասին, բայց կարող է անընդունելի լինել արդեն հաստատված շարահյուսություն ունեցող լեզուների համար: Չնայած դրան, Xtext-ը ներկայումս Eclipse-ում ամենահասուն, առանձնահատկություններով հարուստ և բազմակողմանի գործիքն է՝ ծրագրավորման լեզուներ և նրանց համար մշակման գործիքներ ստեղծելու համար: Մասնավորապես, այն իդեալական գործիք է արագ նախատիպերի պատրաստման համար տիրույթի հատուկ լեզուներ (տիրույթի հատուկ լեզու, DSL): Ի հավելումն ANTLR-ի և EMF-ի վրա հիմնված վերոհիշյալ «լեզվի միջուկին», Xtext-ը տրամադրում է ավելի բարձր մակարդակի շատ օգտակար բաղադրիչներ, ներառյալ ինդեքսավորման մեխանիզմները, աստիճանական կառուցումը, «խելացի խմբագրիչը» և շատ ու շատ ավելին, բայց բաց է թողնում կարգավորիչները. հիմնված լեզվական մոդելներ. Ինչպես EMF-ը, Xtext-ը առանձին գրքի արժանի թեմա է, և մենք դժվար թե կարողանանք նույնիսկ համառոտ խոսել դրա բոլոր հնարավորությունների մասին հենց հիմա:

1C:Enterprise Development Tools-ը ակտիվորեն օգտագործում է ինչպես EMF-ն, այնպես էլ Eclipse Modeling-ի մի շարք այլ նախագծեր: Մասնավորապես, Xtext-ը զարգացման գործիքներից մեկն է այնպիսի 1C:Enterprise լեզուների համար, ինչպիսիք են ներկառուցված ծրագրավորման լեզուն և հարցումների լեզուն: Մշակման այս գործիքների մեկ այլ հիմք է Eclipse Handly նախագիծը, որը մենք կքննարկենք ավելի մանրամասն (թվարկված Eclipse բաղադրիչներից այն դեռ ամենաքիչ հայտնին է):

Eclipse HandlyEclipse Technology-ի վերին մակարդակի նախագծի ենթածրագիրն է, որը առաջացել է Eclipse հիմնադրամին 1C-ի կողմից 2014 թվականին կատարված սկզբնական ծածկագրով ներդրման արդյունքում: Այդ ժամանակից ի վեր 1C-ն շարունակում է աջակցել նախագծի զարգացմանը. Handly committers-ը ընկերության աշխատակիցներն են: Նախագիծը փոքր է, բայց Eclipse-ում բավականին յուրօրինակ տեղ է գրավում. դրա հիմնական նպատակն է աջակցել բռնակի վրա հիմնված մոդելների մշակմանը:

Բռնակի վրա հիմնված մոդելների հիմնական ճարտարապետական ​​սկզբունքները, ինչպիսիք են բռնակ/մարմնի բառապաշարը, քննարկվել են վերևում՝ օգտագործելով ռեսուրսի մոդելը և Java մոդելը որպես օրինակ: Այն նաև նշել է, որ և՛ ռեսուրսների մոդելը, և՛ Java մոդելը կարևոր հիմքեր են Eclipse Java զարգացման գործիքների (JDT) համար: Եվ քանի որ *DT Eclipse-ի գրեթե բոլոր նախագծերն ունեն JDT-ին նման ճարտարապետություն, մեծ չափազանցություն չի լինի ասել, որ բռնակներով մոդելների հիմքում ընկած են շատ, եթե ոչ բոլոր IDE-ները, որոնք կառուցված են Eclipse հարթակի վերևում: Օրինակ, Eclipse C/C++ Development Tooling-ը (CDT) ունի բռնակի վրա հիմնված C/C++ մոդել, որը նույն դերն է խաղում CDT ճարտարապետության մեջ, ինչ Java մոդելը JDT-ում:

Մինչ Handly-ը, Eclipse-ը չէր առաջարկում մասնագիտացված գրադարաններ բռնակի վրա հիմնված լեզվական մոդելներ ստեղծելու համար: Ներկայումս գոյություն ունեցող մոդելները ստեղծվել են հիմնականում Java մոդելի կոդը ուղղակիորեն հարմարեցնելու միջոցով (aka copy/paste), այն դեպքերում, երբ դա թույլ է տալիս Eclipse Public License (EPL): (Ակնհայտ է, որ սա սովորաբար իրավական խնդիր չէ, ասենք, Eclipse-ի նախագծերի համար, բայց ոչ փակ կոդով արտադրանքի համար:) Ի լրումն իր բնորոշ պատահականության, այս տեխնիկան ներկայացնում է հայտնի խնդիրներ. և այլն: Ամենավատն այն է, որ ստացված մոդելները մնում են «իրենց իրերը» և չեն օգտվում միավորման ներուժից: Բայց բռնակի վրա հիմնված լեզվական մոդելների համար ընդհանուր հասկացությունների և արձանագրությունների մեկուսացումը կարող է հանգեցնել դրանց հետ աշխատելու համար բազմակի օգտագործման բաղադրիչների ստեղծմանը, ինչպես EMF-ի դեպքում:

Այնպես չէ, որ Eclipse-ը չի հասկացել այս հարցերը: Դեռ 2005թ Մարտին Էշլիման, ամփոփելով CDT նախատիպի մշակման փորձը, վիճել է լեզվական մոդելների համար ընդհանուր ենթակառուցվածք ստեղծելու անհրաժեշտությունը, ներառյալ բռնակի վրա հիմնված մոդելները: Բայց, ինչպես հաճախ է պատահում, ավելի առաջնահերթ խնդիրների պատճառով այդ գաղափարների իրականացումը երբեք չի հանգեցրել դրան: Մինչդեռ *DT կոդի ֆակտորիզացիան շարունակում է մնալ Eclipse-ի թերզարգացած թեմաներից մեկը։

Որոշակի իմաստով Handly նախագիծը նախատեսված է մոտավորապես նույն խնդիրները լուծելու համար, ինչ EMF-ը, բայց բռնակի վրա հիմնված մոդելների և հիմնականում լեզվական մոդելների համար (այսինքն՝ որոշ ծրագրավորման լեզվի կառուցվածքի տարրեր ներկայացնելու համար): Handly-ի նախագծման ժամանակ դրված հիմնական նպատակները թվարկված են ստորև.

• Առարկայական ոլորտի հիմնական աբստրակցիաների բացահայտում:
• Նվազեցնել ջանքերը և բարելավել բռնակի վրա հիմնված լեզվական մոդելների իրականացման որակը կոդի վերաօգտագործման միջոցով:
• Ստացված մոդելներին տրամադրելով միասնական մետա-մակարդակի API՝ հնարավոր դարձնելով ստեղծել ընդհանուր IDE բաղադրիչներ, որոնք աշխատում են լեզվական բռնակի վրա հիմնված մոդելների հետ:
• Ճկունություն և մասշտաբայնություն:
• Ինտեգրում Xtext-ի հետ (առանձին շերտով):

Ընդհանուր հասկացություններն ու արձանագրությունները ընդգծելու համար վերլուծվել են լեզվական բռնակի վրա հիմնված մոդելների առկա իրականացումները: Handly-ի կողմից տրամադրված հիմնական ինտերֆեյսները և հիմնական իրականացումները ներկայացված են Նկ. 8.

Բրինձ. 8. Handly տարրերի ընդհանուր ինտերֆեյսները և հիմնական իրականացումները

IElement ինտերֆեյսը ներկայացնում է տարրի բռնակը և ընդհանուր է Handly-ի վրա հիմնված բոլոր մոդելների տարրերի համար: Abstract դասի Element-ն իրականացնում է ընդհանրացված բռնակ/մարմնի մեխանիզմը (նկ. 9):

Բրինձ. 9. IElement և ընդհանուր բռնակ/մարմնի իրականացում

Բացի այդ, Handly-ն ապահովում է մոդելի տարրերի փոփոխությունների մասին ծանուցման ընդհանրացված մեխանիզմ (նկ. 10): Ինչպես տեսնում եք, այն ընդհանուր առմամբ նման է ռեսուրսի մոդելում և Java մոդելում ներդրված ծանուցման մեխանիզմներին և օգտագործում է IElementDelta՝ տարրի փոփոխության տեղեկատվության միասնական ներկայացում ապահովելու համար:

Բրինձ. 10. Handly-ի ծանուցման մեխանիզմի ընդհանուր ինտերֆեյսներ և հիմնական իրականացումներ

Վերևում քննարկված Handly-ի մասը (Նկար 9 և 10) կարող է օգտագործվել բռնակի վրա հիմնված գրեթե ցանկացած մոդել ներկայացնելու համար: Ստեղծելու համար լեզվաբանական մոդելներ, նախագիծն առաջարկում է լրացուցիչ ֆունկցիոնալություն, մասնավորապես, ընդհանուր ինտերֆեյսներ և հիմնական իրագործումներ սկզբնական տեքստի կառուցվածքի տարրերի համար, այսպես կոչված. աղբյուրի տարրեր (նկ. 8): ISourceFile ինտերֆեյսը ներկայացնում է աղբյուրի ֆայլը, իսկ ISourceConstruct-ը ներկայացնում է աղբյուրի ֆայլի տարրը: SourceFile և SourceConstruct աբստրակտ դասերն իրականացնում են ընդհանրացված մեխանիզմներ՝ աջակցելու սկզբնական ֆայլերի և դրանց տարրերի հետ աշխատելուն, օրինակ՝ աշխատել տեքստային բուֆերների հետ, կապել սկզբնաղբյուր տեքստի տարրի կոորդինատներին, մոդելները համապատասխանեցնել աշխատանքային պատճենների բուֆերի ընթացիկ բովանդակությանը: և այլն։ Այս մեխանիզմների ներդրումը սովորաբար բավականին դժվար է, և Handly-ն կարող է զգալիորեն նվազեցնել բռնակի վրա հիմնված լեզվական մոդելների մշակման ջանքերը՝ ապահովելով բարձրորակ հիմնական իրականացումներ:

Ի լրումն վերը թվարկված հիմնական մեխանիզմների, Handly-ն ապահովում է ենթակառուցվածք տեքստային բուֆերների և լուսանկարների համար, աջակցություն կոդերի խմբագրիչների հետ ինտեգրման համար (ներառյալ Xtext խմբագրիչի հետ ինտեգրումը), ինչպես նաև UI որոշ ընդհանուր բաղադրիչներ, որոնք աշխատել սկզբնաղբյուրի խմբագիրների հետ: Հեշտ մոդելներ, ինչպիսիք են ուրվագծային շրջանակը: Իր հնարավորությունները ցույց տալու համար նախագիծը տալիս է մի քանի օրինակներ, ներառյալ Java մոդելի ներդրումը Handly-ում: (JDT-ում Java մոդելի ամբողջական ներդրման համեմատությամբ, այս մոդելը միտումնավոր որոշ չափով պարզեցված է ավելի մեծ պարզության համար):

Ինչպես նշվեց ավելի վաղ, Handly-ի նախնական նախագծման և հետագա զարգացման ընթացքում հիմնական ուշադրությունը եղել և շարունակում է մնալ մասշտաբայնության և ճկունության վրա:

Սկզբունքորեն, բռնակի վրա հիմնված մոդելները բավականին լավ են չափվում «ըստ դիզայնի»: Օրինակ, բռնակ/մարմնի արտահայտությունը թույլ է տալիս սահմանափակել մոդելի կողմից սպառվող հիշողության քանակը: Բայց կան նաև նրբերանգներ. Այսպիսով, Handly-ի մասշտաբայնության համար փորձարկելիս խնդիր է հայտնաբերվել ծանուցման մեխանիզմի ներդրման մեջ. երբ մեծ թվով տարրեր փոխվեցին, դելտաների կառուցումը չափազանց շատ ժամանակ պահանջեց: Պարզվեց, որ նույն խնդիրն առկա է JDT Java մոդելում, որից ժամանակին հարմարեցվել է համապատասխան կոդը։ Մենք ուղղեցինք Handly-ի սխալը և պատրաստեցինք նմանատիպ կարկատել JDT-ի համար, որը երախտագիտությամբ ստացվեց: Սա ընդամենը մեկ օրինակ է, որտեղ Handly-ի ներդրումը գոյություն ունեցող մոդելների ներդրման մեջ կարող է պոտենցիալ օգտակար լինել, քանի որ այս դեպքում նման սխալը կարող է շտկվել ընդամենը մեկ տեղում:

Handly-ի ներդրումը գոյություն ունեցող մոդելների ներդրման մեջ տեխնիկապես իրագործելի դարձնելու համար գրադարանը պետք է ունենա զգալի ճկունություն: Հիմնական խնդիրն այն է, որ պահպանվի հետընթաց համատեղելիությունը API մոդելում: Այս խնդիրը լուծվեց մ Handly 0.5 հստակ տարանջատելով ծրագրավորողի կողմից սահմանված և ամբողջությամբ վերահսկվող մոդելի հատուկ API-ն գրադարանի կողմից տրամադրված միասնական մետամակարդակի API-ից: Սա ոչ միայն տեխնիկապես հնարավոր է դարձնում Handly-ի ներդրումը գոյություն ունեցող ծրագրերում, այլև նոր մոդելի մշակողին տալիս է զգալի ազատություն API-ի նախագծման ժամանակ:

Ճկունությունն ունի նաև այլ կողմեր: Օրինակ, Handly-ն գրեթե ոչ մի սահմանափակում չի դնում մոդելի կառուցվածքի վրա և կարող է օգտագործվել ինչպես ընդհանուր, այնպես էլ տիրույթին հատուկ լեզուների մոդելավորման համար: Աղբյուրի ֆայլի կառուցվածքը կառուցելիս Handly-ն չի նախատեսում AST ներկայացման որևէ հատուկ ձև և, սկզբունքորեն, նույնիսկ չի պահանջում ինքնին AST-ի առկայությունը, այդպիսով ապահովելով համատեղելիությունը վերլուծման գրեթե ցանկացած մեխանիզմի հետ: Վերջապես, Handly-ն աջակցում է Eclipse աշխատանքային տարածքի հետ լիարժեք ինտեգրմանը, բայց կարող է նաև ուղղակիորեն աշխատել ֆայլային համակարգերի հետ՝ շնորհիվ իր ինտեգրման: Eclipse ֆայլային համակարգ (EFS):

Ընթացիկ տարբերակը Handly 0.6 դուրս եկավ 2016 թվականի դեկտեմբերին։ Չնայած այն հանգամանքին, որ նախագիծը ներկայումս գտնվում է ինկուբացիոն վիճակում, և API-ն դեռ վերջնականապես ամրագրված չէ, Handly-ն արդեն օգտագործվում է երկու խոշոր առևտրային արտադրանքներում, որոնք ռիսկի են դիմում հանդես գալ որպես «վաղ որդեգրողներ», և պետք է ասեմ. դեռ մի զղջացեք դրա համար:

Ինչպես նշվեց վերևում, այդ արտադրանքներից մեկը 1C:Enterprise Development Tools-ն է, որտեղ Handly-ն ի սկզբանե օգտագործվում է նման 1C:Enterprise լեզուների բարձր մակարդակի կառուցվածքի տարրերը մոդելավորելու համար՝ որպես ներկառուցված ծրագրավորման լեզու և հարցումների լեզու: . Մեկ այլ ապրանք ավելի քիչ հայտնի է լայն հասարակությանը. Սա Codasip ստուդիա, ինտեգրված դիզայնի միջավայր կիրառական հրահանգների հավաքածուի պրոցեսորի համար (ASIP), որն օգտագործվում է ինչպես չեխական Codasip ընկերության, այնպես էլ նրա հաճախորդների կողմից, ներառյալ ՀՀ դրամ, AVG, Մոբիլեյը, Սիգմայի նմուշները. Codasip-ը Handly-ն օգտագործում է արտադրության մեջ 2015 թվականից՝ սկսած Handly 0.2 տարբերակից: Codasip Studio-ի վերջին թողարկումն օգտագործում է 0.5 տարբերակը, որը թողարկվել է 2016 թվականի հունիսին: Ondřej Ilčík-ը, ով ղեկավարում է IDE-ի մշակումը Codasip-ում, կապի մեջ է նախագծի հետ՝ ապահովելով կենսական արձագանքներ «երրորդ կողմի որդեգրողի» անունից: Նա նույնիսկ կարողացավ որոշակի ազատ ժամանակ գտնել նախագծի մշակմանը անմիջականորեն մասնակցելու համար՝ իրականացնելով UI շերտ (~ 4000 տող կոդ) Handly-ի օրինակներից մեկի՝ Java մոդելի համար: Որդեգրողների կողմից Handly-ի օգտագործման վերաբերյալ ավելի մանրամասն առաջին ձեռքից տեղեկություններ կարելի է գտնել էջում Հաջողության պատմություններ նախագիծը:

Հուսով ենք, որ API-ի կայունության երաշխիքով 1.0 տարբերակի թողարկումից և ինկուբացիոն վիճակից դուրս գալուց հետո Handly-ն կունենա նոր ընդունողներ։ Միևնույն ժամանակ, նախագիծը շարունակում է փորձարկել և կատարելագործել API-ն՝ թողարկելով տարեկան երկու «հիմնական» թողարկում՝ հունիսին (նույն ամսաթվին, ինչ միաժամանակյա թողարկումը Eclipse) և դեկտեմբերին՝ ապահովելով կանխատեսելի ժամանակացույց, որի վրա կարող են ապավինել ընդունողները: Կարող ենք նաև ավելացնել, որ նախագծի «սխալների մակարդակը» մնում է հետևողականորեն ցածր մակարդակի վրա, և Handly-ն հուսալիորեն աշխատում է վաղ ընդունողների արտադրանքներում առաջին իսկ տարբերակներից ի վեր: Eclipse Handly-ի հետագա ուսումնասիրության համար կարող եք օգտագործել Սկսելու ձեռնարկ и Ectարտարապետական ​​ակնարկ.

Source: www.habr.com