1C:엔터프라이즈 개발 도구를 위한 기술 플랫폼으로서의 Eclipse

아마 식 오랫동안 특별한 소개가 필요하지 않았습니다. 많은 사람들이 Eclipse Java 개발 도구(JDT). 대부분의 개발자가 "Eclipse"라는 단어와 연관시키는 것은 바로 이 인기 있는 오픈 소스 Java IDE입니다. 그러나 Eclipse는 개발 도구(Eclipse Platform)를 통합하기 위한 확장 가능한 플랫폼이자 JDT를 포함하여 이를 기반으로 구축된 여러 IDE입니다. Eclipse는 Eclipse 플랫폼과 JDT의 개발을 조정하는 최상위 프로젝트인 Eclipse 프로젝트이자, 해당 개발의 결과물인 Eclipse SDK입니다. 마지막으로 Eclipse는 거대한 프로젝트 커뮤니티를 갖춘 오픈 소스 기반입니다. 모든 프로젝트가 Java로 작성되거나 개발 도구(예: 프로젝트)와 관련되어 있는 것은 아닙니다. 이클립스 IoT и 이클립스 사이언스). Eclipse의 세계는 매우 다양합니다.

본질적으로 개요인 이 기사에서는 통합 개발 도구를 구축하기 위한 플랫폼인 Eclipse 아키텍처의 기본 사항 중 일부를 살펴보고 기술의 기초를 형성하는 Eclipse 구성 요소에 대한 초기 아이디어를 제공하려고 합니다. "새로운 구성자" 1C: Enterprise를 위한 플랫폼입니다. 1C:엔터프라이즈 개발 도구. 물론 이러한 검토는 필연적으로 Eclipse 개발자에게만 초점을 맞추는 것이 아니라 대상 독자로 초점을 맞추고 있기 때문에 대체로 피상적이고 다소 제한적일 것입니다. 그러나 숙련된 Eclipse 개발자라도 이 기사에서 흥미로운 정보를 찾을 수 있기를 바랍니다. 예를 들어, 상대적으로 새롭고 잘 알려지지 않은 프로젝트인 "Eclipse의 비밀" 중 하나에 대해 이야기하겠습니다. Eclipse Handly, 1C가 설립하고 지원했습니다.

Eclipse 아키텍처 소개

먼저 예제를 사용하여 Eclipse 아키텍처의 몇 가지 일반적인 측면을 살펴보겠습니다. Eclipse Java 개발 도구 (JDT). 예를 들어 JDT를 선택한 것은 우연이 아닙니다. 이는 Eclipse에 등장한 최초의 통합 개발 환경입니다. Eclipse CDT(C/C++ Development Tooling)와 같은 다른 *DT Eclipse 프로젝트는 나중에 생성되었으며 JDT에서 기본 아키텍처 원칙과 개별 소스 코드 조각을 모두 차용했습니다. JDT에 구축된 아키텍처의 기본은 오늘날 1C:Enterprise Development Tools를 포함하여 Eclipse 플랫폼을 기반으로 구축된 거의 모든 IDE와 관련이 있습니다.

우선, Eclipse는 특정 프로그래밍 언어를 지원하도록 설계된 기능과 언어 독립적인 기능을 분리하고, 관련 구성 요소에서 UI 독립적인 "핵심" 구성 요소를 분리하는 상당히 명확한 아키텍처 계층이 특징이라는 점에 유의해야 합니다. 사용자 인터페이스를 지원합니다.

따라서 Eclipse 플랫폼은 언어 독립적인 공통 인프라를 정의하고 Java 개발 도구는 모든 기능을 갖춘 Java IDE를 Eclipse에 추가합니다. Eclipse 플랫폼과 JDT는 모두 여러 구성 요소로 구성되며 각 구성 요소는 UI 독립적인 "코어" 또는 UI 계층(그림 1)에 속합니다.

쌀. 1. Eclipse 플랫폼과 JDT

Eclipse 플랫폼의 주요 구성요소를 나열해 보겠습니다.

• 런타임 — 플러그인 인프라를 정의합니다. Eclipse는 모듈식 아키텍처가 특징입니다. 기본적으로 Eclipse는 "확장 지점"과 "확장"의 모음입니다.
• 작업 공간 — 하나 이상의 프로젝트를 관리합니다. 프로젝트는 파일 시스템에 직접 매핑되는 폴더와 파일로 구성됩니다.
• SWT(표준 위젯 툴킷) - 운영 체제와 통합된 기본 사용자 인터페이스 요소를 제공합니다.
• J페이스 — SWT를 기반으로 구축된 다양한 UI 프레임워크를 제공합니다.
• 워크 벤치 — 편집기, 보기, 관점 등 Eclipse UI 패러다임을 정의합니다.

Eclipse 플랫폼은 디버그, 비교, 검색 및 팀을 포함하여 통합 개발 도구를 구축하는 데 유용한 다른 많은 구성 요소도 제공합니다. 소스 코드의 "스마트 편집기"를 구축하기 위한 기반인 JFace Text에 대해 특별히 언급해야 합니다. 안타깝게도 이 문서의 범위 내에서는 이러한 구성 요소와 UI 레이어 구성 요소를 대략적으로 살펴보는 것조차 불가능하므로 이 섹션의 나머지 부분에서는 UI 레이어 구성 요소의 주요 "핵심" 구성 요소에 대한 개요만 살펴보겠습니다. Eclipse 플랫폼과 JDT.

핵심 런타임

Eclipse 플러그인 인프라는 다음을 기반으로 합니다. OSGi 그리고 프로젝트에서 제공하는 이클립스 춘분. 각 Eclipse 플러그인은 OSGi 번들입니다. OSGi 사양은 특히 버전 관리 및 종속성 해결을 위한 메커니즘을 정의합니다. 이러한 표준 메커니즘 외에도 Equinox는 다음 개념을 도입했습니다. 확장 포인트. 각 플러그인은 자체 확장 지점을 정의할 수 있으며, 동일하거나 다른 플러그인에서 정의한 확장 지점을 사용하여 시스템에 추가 기능("확장")을 도입할 수도 있습니다. OSGi 및 Equinox 메커니즘에 대한 자세한 설명은 이 기사의 범위를 벗어납니다. Eclipse의 모듈화는 전체적이며(런타임을 포함한 모든 하위 시스템은 하나 이상의 플러그인으로 구성됨) Eclipse의 거의 모든 것이 확장이라는 점만 참고하세요. 더욱이 이러한 원칙은 OSGi가 도입되기 오래 전에 Eclipse 아키텍처에 포함되었습니다(당시에는 OSGi와 매우 유사한 자체 기술을 사용했습니다).

핵심 작업공간

Eclipse 플랫폼 위에 구축된 거의 모든 통합 개발 환경은 Eclipse 작업 공간에서 작동합니다. 일반적으로 IDE에서 개발된 애플리케이션의 소스 코드가 포함되어 있는 작업 공간입니다. 작업공간은 파일 시스템에 직접 매핑되며 폴더와 파일을 포함하는 프로젝트로 구성됩니다. 이러한 프로젝트, 폴더 및 파일을 자원 작업 공간. Eclipse의 작업공간 구현은 파일 시스템과 관련하여 캐시 역할을 하므로 리소스 트리 탐색 속도를 크게 높일 수 있습니다. 또한 Workspace는 다음과 같은 다양한 추가 서비스를 제공합니다. 리소스 변경에 대한 알림 메커니즘 и 증분 빌더 인프라.

핵심 리소스 구성요소(org.eclipse.core.resources 플러그인)는 작업공간과 해당 리소스를 지원하는 역할을 합니다. 특히 이 구성 요소는 다음 형식으로 작업 공간에 대한 프로그래밍 방식의 액세스를 제공합니다. 자원 모델. 이 모델을 효과적으로 사용하려면 클라이언트는 리소스에 대한 링크를 제공하는 간단한 방법이 필요합니다. 이 경우 모델의 리소스 상태를 직접 저장하는 개체를 클라이언트 액세스로부터 숨기는 것이 바람직합니다. 그렇지 않으면 예를 들어 파일을 삭제하는 경우 클라이언트가 더 이상 모델에 없는 개체를 계속 보유할 수 있으며 이로 인해 문제가 발생할 수 있습니다. Eclipse는 다음을 사용하여 이 문제를 해결합니다. 핸들 자원. 핸들은 키 역할을 하며(작업 공간의 리소스에 대한 경로만 알고 있음) 리소스 상태에 대한 정보를 직접 저장하는 내부 모델 개체에 대한 액세스를 완전히 제어합니다. 이 디자인은 패턴의 변형입니다 핸들/본체.

쌀. 그림 2는 자원 모델에 적용된 핸들/본문 관용구를 보여줍니다. IResource 인터페이스는 이 인터페이스를 구현하는 Resource 클래스와 본문을 나타내는 ResourceInfo 클래스가 API가 아닌 것과 달리 리소스의 핸들을 나타내는 API입니다. 핸들은 작업공간 루트에 상대적인 리소스 경로만 알고 리소스 정보에 대한 링크는 포함하지 않는다는 점을 강조합니다. 리소스 정보 개체는 소위 "요소 트리"를 형성합니다. 이 데이터 구조는 메모리에서 완전히 구체화됩니다. 핸들에 해당하는 리소스 정보 인스턴스를 찾기 위해 해당 핸들에 저장된 경로에 따라 요소 트리를 탐색합니다.

쌀. 2. IResource 및 ResourceInfo

나중에 살펴보겠지만 자원 모델의 기본 디자인(핸들 기반이라고 부를 수도 있음)은 Eclipse에서 다른 모델에도 사용됩니다. 지금은 이 디자인의 몇 가지 독특한 속성을 나열해 보겠습니다.

• 핸들은 값 개체입니다. 값 개체는 동일성이 ID를 기반으로 하지 않는 불변 개체입니다. 이러한 객체는 해시된 컨테이너의 키로 안전하게 사용될 수 있습니다. 핸들의 여러 인스턴스가 동일한 리소스를 참조할 수 있습니다. 이를 비교하려면 equals(Object) 메서드를 사용해야 합니다.
• Handle은 리소스의 동작을 정의하지만 리소스 상태에 대한 정보는 포함하지 않습니다(여기에 저장되는 유일한 데이터는 리소스 경로인 "키"입니다).
• 핸들은 존재하지 않는 리소스(아직 생성되지 않은 리소스 또는 이미 삭제된 리소스)를 참조할 수 있습니다. IResource.exists() 메서드를 사용하여 리소스의 존재 여부를 확인할 수 있습니다.
• 일부 작업은 핸들 자체에 저장된 정보만을 기반으로 구현될 수 있습니다(소위 핸들 전용 작업). 예를 들면 IResource.getParent(), getFullPath() 등이 있습니다. 이러한 작업이 성공하기 위해 리소스가 존재할 필요는 없습니다. 성공하려면 리소스가 있어야 하는 작업에서 리소스가 없으면 CoreException이 발생합니다.

Eclipse는 작업공간 리소스 변경 사항을 알리는 효율적인 메커니즘을 제공합니다(그림 3). 리소스는 Eclipse IDE 자체 내에서 수행된 작업의 결과 또는 파일 시스템과의 동기화의 결과로 변경될 수 있습니다. 두 경우 모두 알림을 구독하는 클라이언트에게는 "리소스 델타" 형식의 변경 사항에 대한 자세한 정보가 제공됩니다. 델타는 작업공간 리소스(하위) 트리의 두 상태 간의 변경 사항을 설명하며 그 자체가 트리입니다. 각 노드의 각 노드는 리소스 변경 사항을 설명하고 하위 리소스 변경 사항을 설명하는 다음 수준의 델타 목록을 포함합니다.

쌀. 3. IResourceChangeEvent 및 IResourceDelta

리소스 델타를 기반으로 하는 알림 메커니즘에는 다음과 같은 특징이 있습니다.

• 델타는 재귀적 구성 원리를 사용하여 구축되므로 단일 변경 사항과 많은 변경 사항은 동일한 구조를 사용하여 설명됩니다. 구독자 클라이언트는 델타 트리를 통한 재귀 하강을 사용하여 리소스 변경 알림을 처리할 수 있습니다.
• 델타에는 리소스 이동 및/또는 이와 관련된 "마커"의 변경 사항을 포함하여 리소스 변경 사항에 대한 전체 정보가 포함됩니다(예: 컴파일 오류는 마커로 표시됨).
• 핸들을 통해 리소스 참조가 이루어지기 때문에 델타는 자연스럽게 원격 리소스를 참조할 수 있습니다.

곧 알게 되겠지만, 자원 모델 변경 알림 메커니즘 설계의 주요 구성요소는 다른 핸들 기반 모델과도 관련이 있습니다.

JDT 코어

Eclipse 작업공간 자원 모델은 기본적으로 언어에 구애받지 않는 모델입니다. JDT Core 구성요소(플러그인 org.eclipse.jdt.core)는 소위 "Java 모델"이라고 불리는 Java 관점에서 작업공간 구조를 탐색하고 분석하기 위한 API를 제공합니다(자바 모델). 이 API는 폴더 및 파일 측면에서 정의되는 기본 자원 모델 API와 달리 Java 요소 측면에서 정의됩니다. Java 요소 트리의 주요 인터페이스는 그림 4에 나와 있습니다. XNUMX.

쌀. 4. Java 모델 요소

Java 모델은 자원 모델과 동일한 핸들/본문 관용구를 사용합니다(그림 5). IJavaElement가 핸들이고, JavaElementInfo가 바디 역할을 합니다. IJavaElement 인터페이스는 모든 Java 요소에 공통적인 프로토콜을 정의합니다. getElementName(), getParent() 등 일부 메소드는 핸들 전용입니다. JavaElementInfo 객체는 해당 요소의 상태(구조 및 속성)를 저장합니다.

쌀. 5. IJavaElement 및 JavaElementInfo

Java 모델은 리소스 모델과 비교하여 기본 핸들/본문 디자인 구현에 몇 가지 차이점이 있습니다. 위에서 언급한 것처럼 리소스 모델에서 노드가 리소스 정보 개체인 요소 트리는 완전히 메모리에 포함됩니다. 그러나 Java 모델은 .java 및 .class 파일의 내부 구조(유형, 필드 및 메소드)도 나타내기 때문에 리소스 트리보다 훨씬 더 많은 수의 요소를 가질 수 있습니다.

메모리의 전체 요소 트리가 완전히 구체화되는 것을 방지하기 위해 Java 모델 구현에서는 요소 정보의 제한된 크기 LRU 캐시를 사용합니다. 여기서 핵심은 IJavaElement 핸들입니다. 요소 정보 개체는 요소 트리를 탐색할 때 요청 시 생성됩니다. 이 경우 가장 자주 사용되지 않는 항목이 캐시에서 제거되고 모델의 메모리 소비는 지정된 캐시 크기로 제한됩니다. 이는 클라이언트 코드에서 구현 세부 사항을 완전히 숨기는 핸들 기반 디자인의 또 다른 장점입니다.

Java 요소에 대한 변경 사항을 알리는 메커니즘은 일반적으로 위에서 설명한 작업공간 리소스에 대한 변경 사항을 추적하는 메커니즘과 유사합니다. Java 모델의 변경 사항을 모니터링하려는 클라이언트는 IJavaElementDelta(그림 6)가 포함된 ElementChangedEvent 개체로 표시되는 알림을 구독합니다.

쌀. 6. ElementChangedEvent 및 IJavaElementDelta

Java 모델에는 메서드 본문이나 이름 확인에 대한 정보가 포함되어 있지 않으므로 Java로 작성된 코드를 자세히 분석하기 위해 JDT Core는 추가(핸들 기반이 아닌) 모델을 제공합니다. 추상 구문 트리 (추상 구문 트리, AST). AST는 소스 텍스트를 구문 분석한 결과를 나타냅니다. AST 노드는 소스 모듈 구조의 요소(선언, 연산자, 표현식 등)에 해당하며 소스 텍스트의 해당 요소 좌표에 대한 정보와 (옵션으로) 이름 확인에 대한 정보를 포함합니다. 소위 링크의 형태 바인딩. 바인딩은 컴파일러에 알려진 형식, 메서드, 변수 등 명명된 엔터티를 나타내는 개체입니다. 트리를 형성하는 AST 노드와 달리 바인딩은 상호 참조를 지원하며 일반적으로 그래프를 형성합니다. 추상 클래스 ASTNode는 모든 AST 노드에 대한 공통 기본 클래스입니다. ASTNode 하위 클래스는 Java 언어의 특정 구문 구조에 해당합니다.

구문 트리는 상당한 양의 메모리를 소비할 수 있으므로 JDT는 활성 편집기에 대해 하나의 AST만 캐시합니다. Java 모델과 달리 AST는 일반적으로 AST 생성으로 이어진 작업 컨텍스트 외부에서 클라이언트가 해당 멤버를 참조해서는 안 되는 "중간", "임시" 모델로 간주됩니다.

나열된 세 가지 모델(Java 모델, AST, 바인딩)은 다양한 "도우미"가 포함된 강력한 Java 편집기, 소스 코드 처리를 위한 다양한 작업(가져오기 목록 구성 포함)을 포함하여 JDT에서 "지능형 개발 도구"를 구축하기 위한 기반을 함께 형성합니다. 사용자 정의된 스타일에 따른 이름 및 형식), 검색 및 리팩토링 도구. 이 경우 Java 모델은 개발 중인 애플리케이션 구조의 시각적 표현(예: 패키지 탐색기, 개요, 검색, 호출 계층 구조)의 기초로 사용되므로 특별한 역할을 합니다. 계층 구조를 입력합니다.

1C:엔터프라이즈 개발 도구에 사용되는 Eclipse 구성요소

그림에서. 그림 7은 1C:Enterprise Development Tools용 기술 플랫폼의 기반을 형성하는 Eclipse 구성 요소를 보여줍니다.

쌀. 7. 1C:엔터프라이즈 개발 도구용 플랫폼으로서의 Eclipse

이클립스 플랫폼 기본적인 인프라를 제공합니다. 이전 섹션에서 이 인프라의 일부 측면을 살펴보았습니다.

Eclipse 모델링 프레임 워크 (EMF)은 구조화된 데이터를 모델링하는 일반적인 수단을 제공합니다. EMF는 Eclipse 플랫폼과 통합되어 있지만 일반 Java 애플리케이션에서 별도로 사용할 수도 있습니다. 새로운 Eclipse 개발자는 아직 Eclipse 플랫폼의 복잡성을 완전히 이해하지 못하더라도 이미 EMF에 대해 잘 알고 있는 경우가 많습니다. 이러한 당연한 인기의 이유 중 하나는 보편적인 디자인입니다. 여기에는 무엇보다도 일반적인 방식으로 모든 EMF 모델을 사용할 수 있는 통합 메타 수준 API가 포함되어 있습니다. EMF에서 제공하는 모델 객체의 기본 구현과 메타 모델을 기반으로 모델 코드를 생성하는 서브시스템은 개발 속도를 크게 높이고 오류 수를 줄입니다. EMF에는 모델 직렬화, 모델 변경 추적 등을 위한 메커니즘도 포함되어 있습니다.

진정한 범용 도구와 마찬가지로 EMF는 광범위한 모델링 문제를 해결하는 데 적합하지만 일부 모델 클래스(예: 위에서 설명한 핸들 기반 모델)에는 보다 전문적인 모델링 도구가 필요할 수 있습니다. EMF에 대해 이야기하는 것은 특히 한 기사의 제한된 범위 내에서 감사할 일이 아닙니다. 왜냐하면 이것은 별도의 책과 다소 두꺼운 책의 주제이기 때문입니다. EMF의 기반이 되는 고품질 일반화 시스템을 통해 최상위 프로젝트에 포함된 모델링 전용 프로젝트 전체가 탄생할 수 있었습니다. 이클립스 모델링 EMF 자체와 함께. 그러한 프로젝트 중 하나가 Eclipse Xtext입니다.

이클립스 Xtext "텍스트 모델링" 인프라를 제공합니다. Xtext 사용 앤트러 소스 텍스트를 구문 분석하고 결과 ASG(본질적으로 AST와 바인딩의 조합인 추상 의미 그래프)를 표현하기 위한 EMF("의미 모델"이라고도 함) Xtext가 모델링한 언어의 문법은 Xtext 고유의 언어로 기술됩니다. 이를 통해 ANTLR에 대한 문법 설명을 생성할 수 있을 뿐만 아니라 AST 직렬화 메커니즘(즉, Xtext는 파서와 파서 해제기를 모두 제공), 컨텍스트 힌트 및 기타 여러 언어 구성 요소를 얻을 수 있습니다. 반면에 Xtext에서 사용되는 문법 언어는 ANTLR에서 사용되는 문법 언어보다 유연성이 떨어집니다. 따라서 때로는 구현된 언어를 Xtext로 "구부러야" 할 필요가 있는데, 이는 처음부터 개발되는 언어에 대해 이야기하는 경우 일반적으로 문제가 되지 않지만 이미 확립된 구문이 있는 언어에는 허용되지 않을 수 있습니다. 그럼에도 불구하고 Xtext는 현재 Eclipse에서 프로그래밍 언어 및 개발 도구를 구축하기 위한 가장 성숙하고 기능이 풍부하며 다재다능한 도구입니다. 특히 신속한 프로토타이핑에 이상적인 도구입니다. 도메인별 언어 (도메인별 언어, DSL). 위에서 언급한 ANTLR 및 EMF 기반의 "언어 코어" 외에도 Xtext는 인덱싱 메커니즘, 증분 구성, "스마트 편집기" 등을 포함하여 많은 유용한 고급 구성 요소를 제공하지만 핸들은 제외됩니다. 기반 언어 모델. EMF와 마찬가지로 Xtext도 별도의 책으로 다룰 가치가 있는 주제이며 현재로서는 그 모든 기능에 대해 간략히 설명하기조차 어렵습니다.

1C:엔터프라이즈 개발 도구는 EMF 자체와 기타 여러 Eclipse 모델링 프로젝트를 모두 적극적으로 사용합니다. 특히 Xtext는 내장 프로그래밍 언어 및 쿼리 언어와 같은 1C:Enterprise 언어용 개발 도구의 기반 중 하나입니다. 이러한 개발 도구의 또 다른 기반은 Eclipse Handly 프로젝트입니다. 이에 대해 더 자세히 논의할 것입니다(나열된 Eclipse 구성 요소 중 아직 가장 잘 알려져 있지 않음).

Eclipse HandlyEclipse Technology 최상위 프로젝트의 하위 프로젝트인 은 1년 2014C가 Eclipse Foundation에 대한 초기 코드 기여의 결과로 등장했습니다. 그 이후로 1C는 프로젝트 개발을 계속 지원해 왔습니다. 커미터는 회사 직원입니다. 이 프로젝트는 규모가 작지만 Eclipse에서 다소 독특한 틈새 시장을 차지하고 있습니다. 주요 목표는 핸들 기반 모델 개발을 지원하는 것입니다.

핸들/본체 관용어와 같은 핸들 기반 모델의 기본 아키텍처 원칙은 리소스 모델과 Java 모델을 예로 사용하여 위에서 논의되었습니다. 또한 리소스 모델과 Java 모델 모두 Eclipse JDT(Java 개발 도구)의 중요한 기반이라는 점도 언급했습니다. 그리고 거의 모든 *DT Eclipse 프로젝트에는 JDT와 유사한 아키텍처가 있으므로 핸들 기반 모델이 Eclipse 플랫폼 위에 구축된 모든 IDE는 아니더라도 많은 IDE의 기초가 된다고 해도 과장이 아닐 것입니다. 예를 들어, Eclipse CDT(C/C++ Development Tooling)에는 JDT의 Java 모델과 동일한 역할을 CDT 아키텍처에서 수행하는 핸들 기반 C/C++ 모델이 있습니다.

Handly 이전에는 Eclipse가 핸들 기반 언어 모델을 구축하기 위한 특수 라이브러리를 제공하지 않았습니다. 현재 존재하는 모델은 주로 Java 모델 코드(일명 복사/붙여넣기)를 직접 적용하여 생성되었으며, 허용되는 경우 EPL(Eclipse 공개 라이선스). (분명히 이것은 일반적으로 Eclipse 프로젝트 자체에서는 법적 문제가 아니지만 폐쇄 소스 제품에서는 그렇지 않습니다.) 본질적인 우연성 외에도 이 기술은 잘 알려진 문제를 야기합니다. 오류에 적응할 때 발생하는 코드 중복, 등. 더 나쁜 것은 결과 모델이 "그 자체"로 남아 있고 통일 가능성을 활용하지 못한다는 것입니다. 그러나 핸들 기반 언어 모델에 대한 공통 개념과 프로토콜을 분리하면 EMF의 경우와 유사하게 해당 모델을 사용하기 위한 재사용 가능한 구성 요소가 생성될 수 있습니다.

Eclipse가 이러한 문제를 이해하지 못했다는 것은 아닙니다. 2005년에 다시 마틴 애슐리만, CDT 프로토타입 개발 경험을 요약하면, 주장하다 핸들 기반 모델을 포함하여 언어 모델을 위한 공통 인프라를 만들어야 합니다. 그러나 자주 발생하는 일이지만 우선 순위가 높은 작업으로 인해 이러한 아이디어의 구현은 결코 이루어지지 않았습니다. 한편 *DT 코드의 인수 분해는 Eclipse에서 아직 개발되지 않은 주제 중 하나입니다.

어떤 의미에서 Handly 프로젝트는 EMF와 거의 동일한 문제를 해결하도록 설계되었지만 핸들 기반 모델과 주로 언어 모델(예: 일부 프로그래밍 언어 구조의 요소를 나타냄)에 대한 것입니다. Handly를 디자인할 때 설정한 주요 목표는 다음과 같습니다.

• 주제 영역의 주요 추상화 식별.
• 코드 재사용을 통해 노력을 줄이고 핸들 기반 언어 모델 구현 품질을 향상시킵니다.
• 결과 모델에 통합된 메타 수준 API를 제공하여 언어 핸들 기반 모델과 함께 작동하는 공통 IDE 구성 요소를 생성할 수 있습니다.
• 유연성과 확장성.
• Xtext와의 통합(별도의 레이어)

일반적인 개념과 프로토콜을 강조하기 위해 언어 처리 기반 모델의 기존 구현을 분석했습니다. Handly에서 제공하는 주요 인터페이스와 기본 구현은 그림 8에 나와 있습니다. XNUMX.

쌀. 8. Handly 요소의 공통 인터페이스 및 기본 구현

IElement 인터페이스는 요소의 핸들을 나타내며 모든 Handly 기반 모델의 요소에 공통됩니다. 추상 클래스 Element는 일반화된 핸들/본체 메커니즘을 구현합니다(그림 9).

쌀. 9. IElement 및 일반 핸들/본문 구현

또한 Handly는 모델 요소의 변경 사항을 알리는 일반화된 메커니즘을 제공합니다(그림 10). 보시다시피 이는 자원 모델 및 Java 모델에 구현된 알림 메커니즘과 대체로 유사하며 IElementDelta를 사용하여 요소 변경 정보의 통합 표현을 제공합니다.

쌀. 10. Handly 알림 메커니즘의 일반 인터페이스 및 기본 구현

위에서 설명한 Handly 부분(그림 9 및 10)은 거의 모든 핸들 기반 모델을 나타내는 데 사용할 수 있습니다. 생성을 위해 언어적인 모델인 경우 프로젝트는 추가 기능, 특히 소위 소스 텍스트 구조의 요소에 대한 공통 인터페이스 및 기본 구현을 제공합니다. 소스 요소 (그림 8). ISourceFile 인터페이스는 소스 파일을 나타내고 ISourceConstruct는 소스 파일 내의 요소를 나타냅니다. 추상 클래스 SourceFile 및 SourceConstruct는 소스 파일 및 해당 요소 작업을 지원하는 일반화된 메커니즘을 구현합니다(예: 텍스트 버퍼 작업, 소스 텍스트의 요소 좌표에 바인딩, 작업 복사본 버퍼의 현재 내용과 모델 조정). , 등. 이러한 메커니즘을 구현하는 것은 일반적으로 상당히 어려운 일이며 Handly는 고품질 기본 구현을 제공함으로써 핸들 기반 언어 모델을 개발하는 노력을 크게 줄일 수 있습니다.

위에 나열된 핵심 메커니즘 외에도 Handly는 텍스트 버퍼 및 스냅샷을 위한 인프라, 소스 코드 편집기와의 통합 지원(Xtext 편집기와의 기본 통합 포함) 및 다음과 같은 몇 가지 일반적인 UI 구성 요소를 제공합니다. 소스 코드 편집기를 사용하여 작업하고 개요 프레임워크와 같은 모델을 직접 처리합니다. 해당 기능을 설명하기 위해 프로젝트는 Handly의 Java 모델 구현을 포함하여 여러 가지 예를 제공합니다. (JDT에서 Java 모델의 전체 구현과 비교하여 이 모델은 더 명확성을 위해 의도적으로 다소 단순화되었습니다.)

앞서 언급한 것처럼 Handly의 초기 설계와 후속 개발 과정에서 주요 초점은 확장성과 유연성이었으며 앞으로도 계속 그럴 것입니다.

원칙적으로 핸들 기반 모델은 "설계에 따라" 상당히 잘 확장됩니다. 예를 들어, 핸들/본체 관용구를 사용하면 모델이 소비하는 메모리 양을 제한할 수 있습니다. 그러나 뉘앙스도 있습니다. 따라서 확장성을 위해 Handly를 테스트할 때 알림 메커니즘 구현에서 문제가 발견되었습니다. 즉, 많은 수의 요소가 변경되면 델타 구성에 너무 많은 시간이 걸립니다. 해당 코드를 일단 적용한 JDT Java 모델에도 동일한 문제가 존재하는 것으로 나타났습니다. Handly에서 버그를 수정하고, JDT에서도 비슷한 패치를 준비했는데, 좋은 반응을 얻었습니다. 이는 기존 모델 구현에 Handly를 도입하는 것이 잠재적으로 유용할 수 있는 한 가지 예일 뿐입니다. 이 경우 이러한 버그는 한 곳에서 수정될 수 있기 때문입니다.

기존 모델 구현에 Handly를 기술적으로 구현하려면 라이브러리에 상당한 유연성이 있어야 합니다. 주요 문제는 API 모델 전체에서 이전 버전과의 호환성을 유지하는 것입니다. 이 문제는 다음에서 해결되었습니다. 핸디하게 0.5 개발자가 정의하고 완전히 제어하는 ​​모델별 API와 라이브러리에서 제공하는 통합 메타 수준 API를 명확하게 분리합니다. 이를 통해 기존 구현에 Handly를 기술적으로 구현할 수 있을 뿐만 아니라 새로운 모델 개발자가 API를 설계할 때 상당한 자유를 누릴 수 있습니다.

유연성에는 다른 측면도 있습니다. 예를 들어 Handly는 모델 구조에 거의 제한을 두지 않으며 범용 언어와 도메인 특정 언어를 모두 모델링하는 데 사용할 수 있습니다. 소스 파일의 구조를 구성할 때 Handly는 특정 형식의 AST 표현을 규정하지 않으며 원칙적으로 AST 자체의 존재도 요구하지 않으므로 거의 모든 구문 분석 메커니즘과의 호환성을 보장합니다. 마지막으로 Handly는 Eclipse 작업 공간과의 완전한 통합을 지원하지만 다음과의 통합 덕분에 파일 시스템에서도 직접 작업할 수도 있습니다. Eclipse 파일 시스템 (EFS).

현재 버전 핸디하게 0.6 2016년 XNUMX월에 나왔습니다. 프로젝트가 현재 인큐베이팅 단계에 있고 API가 아직 최종적으로 수정되지 않았음에도 불구하고 Handly는 이미 "얼리 어답터" 역할을 하는 위험을 감수한 두 가지 대형 상용 제품에 사용되고 있습니다. 아직 후회하지 마세요.

위에서 언급했듯이 이러한 제품 중 하나는 1C:Enterprise Development Tools입니다. Handly는 처음부터 내장 프로그래밍 언어 및 쿼리 언어와 같은 1C:Enterprise 언어의 상위 수준 구조 요소를 모델링하는 데 사용됩니다. . 또 다른 제품은 일반 대중에게 덜 알려져 있습니다. 이것 코다십 스튜디오, ASIP(Application-Specific Instruction-Set Processor)를 위한 통합 설계 환경으로, 체코 회사인 Codasip 내부와 클라이언트 모두에서 사용됩니다. AMD, AVG, Mobileye, 시그마 디자인. Codasip은 Handly 2015 버전부터 0.2년부터 프로덕션 환경에서 Handly를 사용해 왔습니다. Codasip Studio의 최신 릴리스는 0.5년 2016월에 릴리스된 버전 4000를 사용합니다. Codasip에서 IDE 개발을 이끄는 Ondřej Ilčík은 프로젝트와 접촉하여 "제XNUMX자 채택자"를 대신하여 중요한 피드백을 제공합니다. 그는 Handly 예제 중 하나인 Java 모델에 대한 UI 레이어(~XNUMX줄의 코드)를 구현하면서 프로젝트 개발에 직접 참여할 수 있는 자유 시간도 있었습니다. 입양자들의 Handly 사용에 대한 더 자세한 직접 정보는 해당 페이지에서 확인할 수 있습니다. 성공 사례 프로젝트.

API 안정성이 보장된 버전 1.0이 출시되고 프로젝트가 인큐베이션 상태를 떠난 후 Handly에 새로운 채택자가 있기를 바랍니다. 그 동안 프로젝트는 계속해서 API를 테스트하고 더욱 개선하여 매년 XNUMX월(동시 Eclipse 릴리스와 같은 날짜)과 XNUMX월에 두 개의 "주요" 릴리스를 릴리스하여 채택자가 신뢰할 수 있는 예측 가능한 일정을 제공합니다. 또한 프로젝트의 "버그 비율"이 지속적으로 낮은 수준으로 유지되고 있으며 Handly는 첫 번째 버전부터 얼리 어답터 제품에서 안정적으로 작동해 왔다고 덧붙일 수 있습니다. Eclipse Handly를 더 자세히 탐색하려면 다음을 사용할 수 있습니다. 시작하기 자습서 и 건축 개요.

출처 : habr.com