Pot ser,
En aquest article, que és de caràcter general, intentarem analitzar alguns dels conceptes bàsics de l'arquitectura Eclipse com a plataforma per construir eines de desenvolupament integrades i donar-nos una idea inicial dels components d'Eclipse que formen la base de la tecnologia. plataforma per al “nou Configurador” 1C: Enterprise.
Introducció a l'Arquitectura Eclipse
Vegem primer alguns aspectes generals de l'arquitectura Eclipse utilitzant l'exemple
En primer lloc, cal tenir en compte que Eclipse es caracteritza per una capa arquitectònica força clara, amb la separació de la funcionalitat independent del llenguatge de la funcionalitat dissenyada per suportar llenguatges de programació específics, i la separació dels components "nuclis" independents de la IU dels components associats. amb interfície d'usuari compatible.
Així, la plataforma Eclipse defineix una infraestructura comuna i independent del llenguatge, i les eines de desenvolupament de Java afegeixen un IDE Java amb totes les funcions a Eclipse. Tant la plataforma Eclipse com el JDT consten de diversos components, cadascun dels quals pertany a un "nucli" independent de la IU o a una capa d'IU (figura 1).
Arròs. 1. Plataforma Eclipse i JDT
Enumerem els components principals de la plataforma Eclipse:
- Temps d’execució — Defineix la infraestructura del connector. Eclipse es caracteritza per una arquitectura modular. Essencialment, Eclipse és una col·lecció de "punts d'extensió" i "extensions".
- Espai de treball — Gestiona un o més projectes. Un projecte consta de carpetes i fitxers que s'assignen directament al sistema de fitxers.
- Kit d'eines de widget estàndard (SWT) - Proporciona elements bàsics d'interfície d'usuari integrats amb el sistema operatiu.
- JFace — Proporciona una sèrie de marcs d'interfície d'usuari construïts a la part superior de SWT.
- Workbench — Defineix el paradigma d'interfície d'usuari d'Eclipse: editors, vistes, perspectives.
Cal dir que la plataforma Eclipse també proporciona molts altres components útils per crear eines de desenvolupament integrades, com ara Depuració, Comparació, Cerca i Equip. Cal fer una menció especial a JFace Text, la base per construir "editors intel·ligents" del codi font. Malauradament, fins i tot un examen superficial d'aquests components, així com dels components de la capa d'interfície d'usuari, no és possible dins de l'àmbit d'aquest article, de manera que a la resta d'aquesta secció ens limitarem a una visió general dels principals components "bàsics" de la Plataforma Eclipse i JDT.
Temps d'execució del nucli
Es basa la infraestructura del connector Eclipse
Espai de treball bàsic
Gairebé qualsevol entorn de desenvolupament integrat construït sobre la plataforma Eclipse funciona amb l'espai de treball Eclipse. És l'espai de treball que sol contenir el codi font de l'aplicació desenvolupada a l'IDE. L'espai de treball s'assigna directament al sistema de fitxers i consta de projectes, que contenen carpetes i fitxers. Aquests projectes, carpetes i fitxers s'anomenen recursos espai de treball. La implementació de l'espai de treball a Eclipse serveix com a memòria cau en relació amb el sistema de fitxers, cosa que permet accelerar significativament el recorregut de l'arbre de recursos. A més, l'espai de treball ofereix una sèrie de serveis addicionals, com ara
El component Core Resources (connector org.eclipse.core.resources) és responsable de donar suport a l'espai de treball i als seus recursos. En particular, aquest component proporciona accés programàtic a l'espai de treball en el formulari models de recursos. Per treballar eficaçment amb aquest model, els clients necessiten una manera senzilla de presentar un enllaç a un recurs. En aquest cas, seria desitjable amagar l'objecte que emmagatzema directament l'estat del recurs al model de l'accés del client. En cas contrari, en el cas, per exemple, d'esborrar un fitxer, el client podria continuar mantenint un objecte que ja no es troba al model, amb els problemes consegüents. Eclipse resol aquest problema utilitzant una cosa anomenada gestionar recurs. Handle actua com a clau (només coneix el camí al recurs a l'espai de treball) i controla completament l'accés a l'objecte del model intern, que emmagatzema directament informació sobre l'estat del recurs. Aquest disseny és una variació del patró
Arròs. La figura 2 il·lustra l'idioma Handle/Body aplicat al model de recursos. La interfície IResource representa el controlador d'un recurs i és una API, a diferència de la classe Resource, que implementa aquesta interfície, i la classe ResourceInfo, que representa el cos, que no són API. Destaquem que el handle només coneix el camí al recurs en relació amb l'arrel de l'espai de treball i no conté un enllaç a la informació del recurs. Els objectes d'informació de recursos formen l'anomenat "arbre d'elements". Aquesta estructura de dades es materialitza completament en la memòria. Per trobar la instància d'informació del recurs corresponent a un identificador, es recorre l'arbre d'elements segons el camí emmagatzemat en aquest identificador.
Arròs. 2. IResource i ResourceInfo
Com veurem més endavant, el disseny bàsic del model de recursos (podríem anomenar-lo basat en mànec) també s'utilitza a Eclipse per a altres models. De moment, enumerem algunes de les propietats distintives d'aquest disseny:
- Handle és un objecte de valor. Els objectes de valor són objectes immutables la igualtat dels quals no es basa en la identitat. Aquests objectes es poden utilitzar de manera segura com a clau en contenidors triturats. Diverses instàncies de maneig poden fer referència al mateix recurs. Per comparar-los, heu d'utilitzar el mètode equals(Object).
- L'handle defineix el comportament d'un recurs, però no conté informació sobre l'estat del recurs (les úniques dades que emmagatzema són la "clau", el camí al recurs).
- El maneig pot fer referència a un recurs que no existeix (ja sigui un recurs que encara no s'ha creat o un recurs que ja s'ha suprimit). L'existència d'un recurs es pot comprovar mitjançant el mètode IResource.exists().
- Algunes operacions es poden implementar basant-se únicament en la informació emmagatzemada al mateix controlador (les anomenades operacions només de maneig). Alguns exemples són IResource.getParent(), getFullPath(), etc. No cal que el recurs existeixi perquè aquesta operació tingui èxit. Les operacions que requereixen que un recurs existeixi per tenir èxit produeixen una CoreException si el recurs no existeix.
Eclipse proporciona un mecanisme eficient per notificar els canvis dels recursos de l'espai de treball (figura 3). Els recursos poden canviar com a resultat de les accions realitzades dins del propi IDE d'Eclipse o com a resultat de la sincronització amb el sistema de fitxers. En ambdós casos, els clients que es subscriuen a les notificacions reben informació detallada sobre els canvis en forma de "deltas de recursos". Un delta descriu els canvis entre dos estats d'un (sub)arbre de recursos d'espai de treball i és en si mateix un arbre, cada node del qual descriu un canvi a un recurs i conté una llista de deltes al nivell següent que descriuen els canvis als recursos secundaris.
Arròs. 3. IResourceChangeEvent i IResourceDelta
El mecanisme de notificació basat en deltas de recursos té les característiques següents:
- Un sol canvi i molts canvis es descriuen utilitzant la mateixa estructura, ja que el delta es construeix utilitzant el principi de composició recursiva. Els clients subscriptors poden processar les notificacions de canvi de recursos mitjançant un descens recursiu a través d'un arbre de deltes.
- El delta conté informació completa sobre els canvis al recurs, inclòs el seu moviment i/o els canvis en els "marcadors" associats a aquest (per exemple, els errors de compilació es representen com a marcadors).
- Com que les referències de recursos es fan a través de la maneta, delta pot fer referència naturalment a un recurs remot.
Com veurem aviat, els components principals del disseny del mecanisme de notificació de canvis en el model de recursos també són rellevants per a altres models basats en maneig.
Nucli JDT
El model de recursos d'espai de treball Eclipse és un model fonamental independent del llenguatge. El component JDT Core (plugin org.eclipse.jdt.core) proporciona una API per navegar i analitzar l'estructura de l'espai de treball des d'una perspectiva Java, l'anomenat "model Java" (Model Java). Aquesta API es defineix en termes d'elements Java, a diferència de l'API del model de recursos subjacent, que es defineix en termes de carpetes i fitxers. Les principals interfícies de l'arbre d'elements Java es mostren a la Fig. 4.
Arròs. 4. Elements del model Java
El model Java utilitza el mateix llenguatge de mànec/cos que el model de recursos (figura 5). IJavaElement és el maneig i JavaElementInfo fa el paper de cos. La interfície IJavaElement defineix un protocol comú a tots els elements Java. Alguns dels seus mètodes són només de maneig: getElementName(), getParent(), etc. L'objecte JavaElementInfo emmagatzema l'estat de l'element corresponent: la seva estructura i atributs.
Arròs. 5. IJavaElement i JavaElementInfo
El model Java té algunes diferències en la implementació del disseny bàsic del mànec/cos en comparació amb el model de recursos. Com s'ha indicat anteriorment, al model de recursos, l'arbre d'elements, els nodes del qual són objectes d'informació de recursos, està totalment contingut a la memòria. Però el model Java pot tenir un nombre significativament més gran d'elements que l'arbre de recursos, perquè també representa l'estructura interna dels fitxers .java i .class: tipus, camps i mètodes.
Per evitar materialitzar completament tot l'arbre d'elements a la memòria, la implementació del model Java utilitza una memòria cau LRU de mida limitada d'informació d'elements, on la clau és handle IJavaElement. Els objectes d'informació d'elements es creen a demanda mentre es navega per l'arbre d'elements. En aquest cas, els elements que s'utilitzen menys sovint s'eliminen de la memòria cau i el consum de memòria del model es manté limitat a la mida de memòria cau especificada. Aquest és un altre avantatge del disseny basat en mànec, que amaga completament aquests detalls d'implementació del codi del client.
El mecanisme per notificar els canvis als elements Java és, en general, similar al mecanisme de seguiment dels canvis als recursos de l'espai de treball comentat anteriorment. Un client que vulgui supervisar els canvis en el model Java es subscriu a les notificacions, que es representen com un objecte ElementChangedEvent que conté un IJavaElementDelta (figura 6).
Arròs. 6. ElementChangedEvent i IJavaElementDelta
El model Java no conté informació sobre els cossos de mètodes o la resolució de noms, de manera que per a l'anàlisi detallada del codi escrit en Java, JDT Core proporciona un model addicional (no basat en maneig):
Com que els arbres de sintaxi poden consumir una quantitat important de memòria, JDT només guarda a la memòria cau un AST per a l'editor actiu. A diferència del model Java, l'AST normalment es veu com un model "intermedi", "temporal", els elements dels quals els clients no haurien de tenir referències fora del context de l'operació que va portar a la creació de l'AST.
Els tres models enumerats (model Java, AST, enllaços) junts formen la base per construir "eines de desenvolupament intel·ligents" a JDT, inclòs un potent editor de Java amb diversos "ajudants", diverses accions per processar el codi font (inclosa l'organització d'una llista d'importació). noms i format segons l'estil personalitzat), eines de cerca i refactorització. En aquest cas, el model Java juga un paper especial, ja que és el que s'utilitza com a base per a una representació visual de l'estructura de l'aplicació que s'està desenvolupant (per exemple, a l'Explorador de paquets, Esquema, Cerca, Jerarquia de trucades i Jerarquia de tipus).
Components d'Eclipse utilitzats a 1C:Eines de desenvolupament empresarial
A la Fig. La figura 7 mostra els components d'Eclipse que formen la base de la plataforma tecnològica per a 1C:Eines de desenvolupament empresarial.
Arròs. 7. Eclipse com a plataforma per a 1C:Eines de desenvolupament empresarial
Plataforma Eclipse ofereix una infraestructura bàsica. Hem analitzat alguns aspectes d'aquesta infraestructura a l'apartat anterior.
Com qualsevol eina de propòsit general veritable, EMF és adequada per resoldre una àmplia gamma de problemes de modelatge, però algunes classes de models (per exemple, els models basats en mànecs comentats anteriorment) poden requerir eines de modelatge més especialitzades. Parlar d'EMF és una tasca ingrata, sobretot dins dels límits limitats d'un article, ja que aquest és el tema d'un llibre a part, i un de més gruixut. Recordem només que el sistema de generalitzacions d'alta qualitat subjacent a l'EMF va permetre el naixement de tota una sèrie de projectes dedicats al modelatge, que s'inclouen en el projecte de primer nivell.
1C: Les eines de desenvolupament empresarial utilitzen activament tant el propi EMF com una sèrie d'altres projectes de modelització d'Eclipse. En particular, Xtext és una de les bases de les eines de desenvolupament per a llenguatges 1C: Enterprise com el llenguatge de programació integrat i el llenguatge de consulta. Una altra base d'aquestes eines de desenvolupament és el projecte Eclipse Handly, del qual parlarem amb més detall (dels components d'Eclipse enumerats, encara és el menys conegut).
Els principis arquitectònics bàsics dels models basats en mànec, com ara l'idioma mànec/cos, es van discutir anteriorment utilitzant el model de recursos i el model Java com a exemples. També va assenyalar que tant el model de recursos com el model Java són fonaments importants per a les eines de desenvolupament Java (JDT) d'Eclipse. I com que gairebé tots els projectes *DT Eclipse tenen una arquitectura similar a JDT, no seria una gran exageració dir que els models basats en mànecs subjacent a molts, si no tots, els IDE construïts sobre la plataforma Eclipse. Per exemple, l'Eclipse C/C++ Development Tooling (CDT) té un model C/C++ basat en mànecs que juga el mateix paper a l'arquitectura CDT que el model Java al JDT.
Abans de Handly, Eclipse no oferia biblioteques especialitzades per construir models de llenguatge basats en manetes. Els models que existeixen actualment es van crear principalment adaptant directament el codi del model Java (també conegut com copiar/enganxar), en els casos en què ho permet Eclipse Public License (EPL). (Òbviament, normalment no és un problema legal per, per exemple, els projectes d'Eclipse en si, però no per als productes de codi tancat.) A més de la seva casualitat inherent, aquesta tècnica introdueix problemes coneguts: la duplicació de codi introduïda per l'adaptació als errors, etc. El pitjor és que els models resultants segueixen sent "coses en si mateixes" i no aprofiten el potencial d'unificació. Però aïllar conceptes i protocols comuns per als models de llenguatge basats en manetes podria conduir a la creació de components reutilitzables per treballar-hi, de manera similar al que va passar en el cas de l'EMF.
No és que Eclipse no entengués aquests problemes. L'any 2005
En cert sentit, el projecte Handly està dissenyat per resoldre aproximadament els mateixos problemes que l'EMF, però per a models basats en mànecs, i principalment els de llenguatge (és a dir, que representen elements de l'estructura d'algun llenguatge de programació). Els objectius principals establerts a l'hora de dissenyar Handly s'enumeren a continuació:
- Identificació de les principals abstraccions de l'àrea temàtica.
- Reduir l'esforç i millorar la qualitat d'implementació dels models de llenguatge basats en maneig mitjançant la reutilització del codi.
- Proporcionar una API de metanivell unificada als models resultants, fent possible crear components IDE comuns que funcionin amb models basats en maneigs de llenguatge.
- Flexibilitat i escalabilitat.
- Integració amb Xtext (en una capa separada).
Per destacar conceptes i protocols comuns, es van analitzar les implementacions existents de models basats en maneigs de llenguatge. Les principals interfícies i implementacions bàsiques proporcionades per Handly es mostren a la Fig. 8.
Arròs. 8. Interfícies comunes i implementacions bàsiques dels elements Handly
La interfície IElement representa el maneig d'un element i és comuna als elements de tots els models basats en Handly. La classe abstracta Element implementa el mecanisme de mànec/cos generalitzat (Fig. 9).
Arròs. 9. Implementació IElement i handle/body genèric
A més, Handly proporciona un mecanisme generalitzat per notificar canvis en els elements del model (Fig. 10). Com podeu veure, és àmpliament similar als mecanismes de notificació implementats en el model de recursos i en el model Java, i utilitza IElementDelta per proporcionar una representació unificada de la informació de canvi d'element.
Arròs. 10. Interfícies generals i implementacions bàsiques del mecanisme de notificació Handly
La part Handly comentada anteriorment (Fig. 9 i 10) es pot utilitzar per representar gairebé qualsevol model basat en mànec. Per crear lingüística models, el projecte ofereix funcionalitats addicionals, en particular, interfícies comunes i implementacions bàsiques per als elements de l'estructura del text font, l'anomenada elements font (Fig. 8). La interfície ISourceFile representa un fitxer font i ISourceConstruct representa un element dins del fitxer font. Les classes abstractes SourceFile i SourceConstruct implementen mecanismes generalitzats per donar suport al treball amb fitxers font i els seus elements, per exemple, treballar amb memòries intermèdies de text, vincular-se a les coordenades d'un element del text font, conciliar models amb el contingut actual d'un buffer de còpia de treball. , etc. La implementació d'aquests mecanismes sol ser tot un repte, i Handly pot reduir significativament l'esforç de desenvolupar models de llenguatge basats en maneigs proporcionant implementacions de base d'alta qualitat.
A més dels mecanismes bàsics enumerats anteriorment, Handly ofereix una infraestructura per a búfers de text i instantànies, suport per a la integració amb editors de codi font (inclosa la integració immediata amb l'editor Xtext), així com alguns components d'interfície d'usuari comuns que treballar amb editors de codi font, com ara el marc d'esquema. Per il·lustrar les seves capacitats, el projecte ofereix diversos exemples, inclosa una implementació del model Java a Handly. (En comparació amb la implementació completa del model Java a JDT, aquest model es simplifica intencionadament una mica per a una major claredat).
Com s'ha assenyalat anteriorment, un enfocament important durant el disseny inicial de Handly i el desenvolupament posterior va ser i continua sent l'escalabilitat i la flexibilitat.
En principi, els models basats en mànec s'escalen força bé "per disseny". Per exemple, l'idioma mànec/cos us permet limitar la quantitat de memòria que consumeix un model. Però també hi ha matisos. Així, quan es va provar Handly per a l'escalabilitat, es va descobrir un problema en la implementació del mecanisme de notificació: quan es van canviar un gran nombre d'elements, la construcció de deltes va trigar massa temps. Va resultar que el mateix problema estava present en el model JDT Java, del qual es va adaptar el codi corresponent. Vam solucionar l'error a Handly i vam preparar un pedaç similar per a JDT, que va ser rebut amb gratitud. Aquest és només un exemple on introduir Handly a les implementacions de models existents podria ser potencialment útil, perquè en aquest cas aquest error es podria solucionar en un sol lloc.
Perquè la implementació de Handly en les implementacions de models existents sigui tècnicament factible, la biblioteca ha de tenir una flexibilitat important. El principal problema és mantenir la compatibilitat enrere en tot el model d'API. Aquest problema es va resoldre a
La flexibilitat també té altres aspectes. Per exemple, Handly no imposa gairebé cap restricció a l'estructura del model i es pot utilitzar per modelar llenguatges de propòsit general i específics de domini. Quan es construeix l'estructura del fitxer font, Handly no prescriu cap forma particular de representació AST i, en principi, ni tan sols requereix la presència d'un AST en si, garantint així la compatibilitat amb gairebé qualsevol mecanisme d'anàlisi. Finalment, Handly admet la integració completa amb l'espai de treball Eclipse, però també pot treballar directament amb sistemes de fitxers gràcies a la seva integració amb
Versió actual
Com s'ha indicat anteriorment, un d'aquests productes és 1C:Eines de desenvolupament empresarial, on Handly s'utilitza des del principi per modelar elements de l'estructura d'alt nivell d'aquests llenguatges 1C:Enterprise com el llenguatge de programació integrat i el llenguatge de consulta. . Un altre producte és menys conegut pel gran públic. Això
Esperem que després del llançament de la versió 1.0 amb garantia d'estabilitat de l'API i que el projecte surti de l'estat d'incubació, Handly tingui nous adoptants. Mentrestant, el projecte continua provant i millorant encara més l'API, llançant dues versions "principals" a l'any: al juny (la mateixa data que la publicació simultània d'Eclipse) i desembre, proporcionant un calendari previsible en el qual els usuaris poden confiar. També podem afegir que la "taxa d'errors" del projecte es manté a un nivell constantment baix i Handly ha estat treballant de manera fiable en els productes dels primers usuaris des de les primeres versions. Per explorar més a fons Eclipse Handly, podeu utilitzar
Font: www.habr.com