Có lẽ, từ lâu đã không cần giới thiệu đặc biệt. Nhiều người quen thuộc với Eclipse nhờ các công cụ phát triển Eclipse Java (). Chính IDE Java mã nguồn mở phổ biến này mà hầu hết các nhà phát triển đều liên tưởng đến từ “Eclipse”. Tuy nhiên, Eclipse vừa là một nền tảng có thể mở rộng để tích hợp các công cụ phát triển (Eclipse Platform) vừa là một số IDE được xây dựng trên nền tảng của nó, bao gồm cả JDT. Eclipse vừa là Dự án Eclipse, dự án cấp cao nhất điều phối việc phát triển Nền tảng Eclipse và JDT, vừa là SDK Eclipse, kết quả được chuyển giao của sự phát triển đó. Cuối cùng, Eclipse là một Quỹ nguồn mở với một cộng đồng dự án khổng lồ, không phải tất cả dự án đều được viết bằng Java hoặc liên quan đến các công cụ phát triển (ví dụ: các dự án). и ). Thế giới của Eclipse rất đa dạng.
Trong bài viết này, có tính chất tổng quan, chúng tôi sẽ cố gắng xem xét một số điều cơ bản của kiến trúc Eclipse như một nền tảng để xây dựng các công cụ phát triển tích hợp và đưa ra ý tưởng ban đầu về các thành phần Eclipse tạo thành nền tảng của công nghệ nền tảng dành cho “Bộ cấu hình mới” 1C: Enterprise. . Tất nhiên, việc xem xét như vậy chắc chắn sẽ phần lớn hời hợt và khá hạn chế, bao gồm cả bởi vì chúng tôi không chỉ tập trung vào các nhà phát triển Eclipse với tư cách là đối tượng mục tiêu. Tuy nhiên, chúng tôi hy vọng rằng ngay cả những nhà phát triển Eclipse có kinh nghiệm cũng có thể tìm thấy thông tin thú vị trong bài viết. Ví dụ: chúng ta sẽ nói về một trong những “bí mật của Eclipse”, một dự án tương đối mới và ít được biết đến , được thành lập và hỗ trợ bởi 1C.
Giới thiệu về Kiến trúc Eclipse
Trước tiên chúng ta hãy xem xét một số khía cạnh chung của kiến trúc Eclipse bằng ví dụ (JDT). Việc lựa chọn JDT làm ví dụ không phải ngẫu nhiên. Đây là môi trường phát triển tích hợp đầu tiên xuất hiện trong Eclipse. Các dự án *DT Eclipse khác, chẳng hạn như Công cụ phát triển Eclipse C/C++ (CDT), được tạo sau này và mượn cả nguyên tắc kiến trúc cơ bản cũng như các đoạn mã nguồn riêng lẻ từ JDT. Các nguyên tắc cơ bản của kiến trúc được trình bày trong JDT cho đến ngày nay vẫn phù hợp với hầu hết mọi IDE được xây dựng trên Nền tảng Eclipse, bao gồm các Công cụ phát triển doanh nghiệp 1C:Enterprise.
Trước hết, cần lưu ý rằng Eclipse được đặc trưng bởi sự phân lớp kiến trúc khá rõ ràng, với sự tách biệt giữa chức năng độc lập với ngôn ngữ khỏi chức năng được thiết kế để hỗ trợ các ngôn ngữ lập trình cụ thể và tách biệt các thành phần “lõi” độc lập với UI khỏi các thành phần được liên kết. với giao diện người dùng hỗ trợ.
Do đó, Nền tảng Eclipse xác định một cơ sở hạ tầng chung, độc lập với ngôn ngữ và các công cụ phát triển Java bổ sung một IDE Java đầy đủ tính năng vào Eclipse. Cả Nền tảng Eclipse và JDT đều bao gồm một số thành phần, mỗi thành phần thuộc về một “lõi” độc lập với giao diện người dùng hoặc một lớp giao diện người dùng (Hình 1).
Cơm. 1. Nền tảng Eclipse và JDT
Hãy liệt kê các thành phần chính của Nền tảng Eclipse:
- Runtime - Xác định cơ sở hạ tầng plugin. Eclipse được đặc trưng bởi một kiến trúc mô-đun. Về cơ bản, Eclipse là một tập hợp các “điểm mở rộng” và “các phần mở rộng”.
- Không gian làm việc - Quản lý một hoặc nhiều dự án. Một dự án bao gồm các thư mục và tệp được ánh xạ trực tiếp vào hệ thống tệp.
- Bộ công cụ tiện ích tiêu chuẩn (SWT) - Cung cấp các thành phần giao diện người dùng cơ bản được tích hợp với hệ điều hành.
- JFace - Cung cấp một số khung giao diện người dùng được xây dựng dựa trên SWT.
- Workbench — Xác định mô hình giao diện người dùng Eclipse: trình soạn thảo, khung nhìn, phối cảnh.
Phải nói rằng Nền tảng Eclipse còn cung cấp nhiều thành phần hữu ích khác để xây dựng các công cụ phát triển tích hợp, bao gồm Debug, Compare, Search và Team. Đặc biệt phải kể đến JFace Text - nền tảng để xây dựng các “trình soạn thảo thông minh” mã nguồn. Thật không may, ngay cả việc kiểm tra sơ qua các thành phần này cũng như các thành phần lớp giao diện người dùng cũng không thể thực hiện được trong phạm vi của bài viết này, vì vậy trong phần còn lại của phần này, chúng tôi sẽ giới hạn ở mức tổng quan về các thành phần “cốt lõi” chính của Nền tảng Eclipse và JDT.
Thời gian chạy cốt lõi
Cơ sở hạ tầng plugin Eclipse dựa trên và được dự án cung cấp . Mỗi plugin Eclipse là một gói OSGi. Đặc tả OSGi xác định cụ thể các cơ chế phân giải phiên bản và phụ thuộc. Ngoài các cơ chế tiêu chuẩn này, Equinox còn giới thiệu khái niệm điểm mở rộng. Mỗi plugin có thể xác định các điểm mở rộng của riêng mình và cũng giới thiệu chức năng bổ sung (“tiện ích mở rộng”) cho hệ thống bằng cách sử dụng các điểm mở rộng được xác định bởi cùng một plugin hoặc các plugin khác. Bất kỳ mô tả chi tiết nào về cơ chế OSGi và Equinox đều nằm ngoài phạm vi của bài viết này. Chúng ta chỉ cần lưu ý rằng việc mô-đun hóa trong Eclipse là toàn bộ (bất kỳ hệ thống con nào, kể cả Runtime, đều bao gồm một hoặc nhiều plugin) và hầu hết mọi thứ trong Eclipse đều là phần mở rộng. Hơn nữa, những nguyên tắc này đã được nhúng vào kiến trúc Eclipse từ rất lâu trước khi OSGi ra đời (vào thời điểm đó họ sử dụng công nghệ của riêng họ, rất giống với OSGi).
Không gian làm việc cốt lõi
Hầu hết mọi môi trường phát triển tích hợp được xây dựng trên Nền tảng Eclipse đều hoạt động với không gian làm việc Eclipse. Đó là không gian làm việc thường chứa mã nguồn của ứng dụng được phát triển trong IDE. Không gian làm việc ánh xạ trực tiếp tới hệ thống tệp và bao gồm các dự án chứa các thư mục và tệp. Những dự án, thư mục và tập tin này được gọi là tài nguyên không gian làm việc. Việc triển khai không gian làm việc trong Eclipse đóng vai trò như một bộ đệm liên quan đến hệ thống tệp, điều này giúp tăng tốc đáng kể việc truyền tải cây tài nguyên. Ngoài ra, không gian làm việc còn cung cấp một số dịch vụ bổ sung, bao gồm и .
Thành phần Tài nguyên cốt lõi (plugin org.eclipse.core.resources) chịu trách nhiệm hỗ trợ không gian làm việc và các tài nguyên của nó. Đặc biệt, thành phần này cung cấp quyền truy cập theo chương trình vào không gian làm việc dưới dạng mô hình tài nguyên. Để làm việc hiệu quả với mô hình này, khách hàng cần một cách đơn giản để trình bày liên kết đến một tài nguyên. Trong trường hợp này, nên ẩn đối tượng lưu trữ trực tiếp trạng thái của tài nguyên trong mô hình khỏi quyền truy cập của máy khách. Mặt khác, chẳng hạn như trong trường hợp xóa một tệp, máy khách có thể tiếp tục giữ một đối tượng không còn trong mô hình với các vấn đề tiếp theo. Eclipse giải quyết vấn đề này bằng cách sử dụng một thứ gọi là xử lý nguồn. Handle đóng vai trò như một chìa khóa (nó chỉ biết đường dẫn đến tài nguyên trong không gian làm việc) và kiểm soát hoàn toàn quyền truy cập vào đối tượng mô hình bên trong, đối tượng này lưu trữ trực tiếp thông tin về trạng thái của tài nguyên. Thiết kế này là một biến thể của mẫu .
Cơm. Hình 2 minh họa thành ngữ Handle/Body được áp dụng cho mô hình tài nguyên. Giao diện IResource đại diện cho việc xử lý một tài nguyên và là một API, không giống như lớp Resource, triển khai giao diện này và lớp ResourceInfo, đại diện cho phần thân, không phải là API. Chúng tôi nhấn mạnh rằng phần xử lý chỉ biết đường dẫn đến tài nguyên tương ứng với thư mục gốc của không gian làm việc và không chứa liên kết đến thông tin tài nguyên. Các đối tượng thông tin tài nguyên tạo thành cái gọi là “cây phần tử”. Cấu trúc dữ liệu này được hiện thực hóa hoàn toàn trong bộ nhớ. Để tìm phiên bản thông tin tài nguyên tương ứng với một điều khiển, cây phần tử được duyệt theo đường dẫn được lưu trong điều khiển đó.
Cơm. 2. IResource và ResourceInfo
Như chúng ta sẽ thấy sau, thiết kế cơ bản của mô hình tài nguyên (chúng ta có thể gọi nó là dựa trên tay cầm) cũng được sử dụng trong Eclipse cho các mô hình khác. Bây giờ, hãy liệt kê một số đặc tính đặc biệt của thiết kế này:
- Handle là một đối tượng giá trị. Đối tượng giá trị là đối tượng bất biến mà sự bình đẳng của nó không dựa trên danh tính. Những đối tượng như vậy có thể được sử dụng một cách an toàn làm khóa trong các vùng chứa được băm. Nhiều trường hợp xử lý có thể tham chiếu cùng một tài nguyên. Để so sánh chúng, bạn cần sử dụng phương thức bằng (Object).
- Handle xác định hành vi của tài nguyên, nhưng không chứa thông tin về trạng thái của tài nguyên (dữ liệu duy nhất mà nó lưu trữ là "chìa khóa", đường dẫn đến tài nguyên).
- Xử lý có thể đề cập đến một tài nguyên không tồn tại (tài nguyên chưa được tạo hoặc tài nguyên đã bị xóa). Sự tồn tại của tài nguyên có thể được kiểm tra bằng phương thức IResource.exists().
- Một số thao tác có thể được thực hiện chỉ dựa trên thông tin được lưu trữ trong chính phần xử lý (còn gọi là các thao tác chỉ xử lý). Ví dụ như IResource.getParent(), getFullPath(), v.v. Tài nguyên không cần phải tồn tại để hoạt động như vậy thành công. Các hoạt động yêu cầu tài nguyên tồn tại để thành công sẽ ném CoreException nếu tài nguyên không tồn tại.
Eclipse cung cấp một cơ chế hiệu quả để thông báo các thay đổi tài nguyên không gian làm việc (Hình 3). Tài nguyên có thể thay đổi do các hành động được thực hiện trong chính IDE Eclipse hoặc do đồng bộ hóa với hệ thống tệp. Trong cả hai trường hợp, khách hàng đăng ký nhận thông báo sẽ được cung cấp thông tin chi tiết về những thay đổi dưới dạng “đồng bằng tài nguyên”. Một delta mô tả các thay đổi giữa hai trạng thái của cây (phụ) tài nguyên không gian làm việc và bản thân nó là một cây, mỗi nút trong đó mô tả một thay đổi đối với tài nguyên và chứa danh sách các delta ở cấp độ tiếp theo mô tả các thay đổi đối với tài nguyên con.
Cơm. 3. IResourceChangeEvent và IResourceDelta
Cơ chế thông báo dựa trên vùng đồng bằng tài nguyên có các đặc điểm sau:
- Một thay đổi duy nhất và nhiều thay đổi được mô tả bằng cùng một cấu trúc, vì delta được xây dựng bằng nguyên tắc thành phần đệ quy. Khách hàng đăng ký có thể xử lý các thông báo thay đổi tài nguyên bằng cách sử dụng phương pháp đệ quy gốc thông qua cây vùng đồng bằng.
- Vùng delta chứa thông tin đầy đủ về những thay đổi đối với tài nguyên, bao gồm chuyển động của nó và/hoặc những thay đổi trong “điểm đánh dấu” được liên kết với nó (ví dụ: lỗi biên dịch được biểu thị dưới dạng điểm đánh dấu).
- Vì các tham chiếu tài nguyên được thực hiện thông qua tay cầm, nên delta có thể tham chiếu tài nguyên từ xa một cách tự nhiên.
Như chúng ta sẽ sớm thấy, các thành phần chính của thiết kế cơ chế thông báo thay đổi mô hình tài nguyên cũng phù hợp với các mô hình dựa trên tay cầm khác.
Lõi JDT
Mô hình tài nguyên không gian làm việc Eclipse là một mô hình cơ bản về ngôn ngữ bất khả tri. Thành phần JDT Core (plugin org.eclipse.jdt.core) cung cấp API để điều hướng và phân tích cấu trúc không gian làm việc từ phối cảnh Java, được gọi là “mô hình Java” (mô hình Java). API này được xác định theo các phần tử Java, trái ngược với API mô hình tài nguyên cơ bản, được xác định theo các thư mục và tệp. Các giao diện chính của cây phần tử Java được hiển thị trong Hình 4. XNUMX.
Cơm. 4. Các phần tử mô hình Java
Mô hình Java sử dụng cùng một cách diễn đạt phần xử lý/nội dung như mô hình tài nguyên (Hình 5). IJavaElement là phần điều khiển và JavaElementInfo đóng vai trò là phần thân. Giao diện IJavaElement xác định một giao thức chung cho tất cả các phần tử Java. Một số phương thức của nó chỉ xử lý: getElementName(), getParent(), v.v. Đối tượng JavaElementInfo lưu trữ trạng thái của phần tử tương ứng: cấu trúc và thuộc tính của nó.
Cơm. 5. IJavaEuity và JavaEuityInfo
Mô hình Java có một số khác biệt trong việc triển khai thiết kế tay cầm/thân cơ bản so với mô hình tài nguyên. Như đã lưu ý ở trên, trong mô hình tài nguyên, cây phần tử có các nút là đối tượng thông tin tài nguyên, hoàn toàn được chứa trong bộ nhớ. Nhưng mô hình Java có thể có số lượng phần tử lớn hơn đáng kể so với cây tài nguyên, vì nó cũng thể hiện cấu trúc bên trong của các tệp .java và .class: kiểu, trường và phương thức.
Để tránh hiện thực hóa hoàn toàn toàn bộ cây phần tử trong bộ nhớ, việc triển khai mô hình Java sử dụng bộ nhớ đệm LRU có kích thước giới hạn chứa thông tin phần tử, trong đó khóa được xử lý IJavaElement. các đối tượng thông tin phần tử được tạo theo yêu cầu khi cây phần tử được điều hướng. Trong trường hợp này, các mục ít được sử dụng nhất sẽ bị xóa khỏi bộ đệm và mức tiêu thụ bộ nhớ của mô hình vẫn bị giới hạn ở kích thước bộ đệm được chỉ định. Đây là một ưu điểm khác của thiết kế dựa trên tay cầm, nó ẩn hoàn toàn các chi tiết triển khai như vậy khỏi mã máy khách.
Cơ chế thông báo các thay đổi đối với các phần tử Java nói chung tương tự như cơ chế theo dõi các thay đổi đối với tài nguyên không gian làm việc đã thảo luận ở trên. Một máy khách muốn theo dõi các thay đổi trong mô hình Java đăng ký các thông báo, được biểu diễn dưới dạng đối tượng ElementChangedEvent có chứa IJavaElementDelta (Hình 6).
Cơm. 6. ElementChangedEvent và IJavaElementDelta
Mô hình Java không chứa thông tin về nội dung phương thức hoặc độ phân giải tên, vì vậy để phân tích chi tiết mã được viết bằng Java, JDT Core cung cấp một mô hình bổ sung (không dựa trên tay cầm): (cây cú pháp trừu tượng, AST). AST đại diện cho kết quả phân tích văn bản nguồn. Các nút AST tương ứng với các phần tử trong cấu trúc của mô-đun nguồn (khai báo, toán tử, biểu thức, v.v.) và chứa thông tin về tọa độ của phần tử tương ứng trong văn bản nguồn, cũng như thông tin (dưới dạng tùy chọn) về độ phân giải tên trong hình thức liên kết đến cái gọi là ràng buộc. Các ràng buộc là các đối tượng đại diện cho các thực thể được đặt tên, chẳng hạn như kiểu, phương thức và biến, được trình biên dịch biết đến. Không giống như các nút AST tạo thành cây, các liên kết hỗ trợ tham chiếu chéo và thường tạo thành biểu đồ. Lớp trừu tượng ASTNode là lớp cơ sở chung cho tất cả các nút AST. Các lớp con ASTNode tương ứng với các cấu trúc cú pháp cụ thể của ngôn ngữ Java.
Vì cây cú pháp có thể tiêu tốn một lượng bộ nhớ đáng kể nên JDT chỉ lưu vào bộ nhớ đệm một AST cho trình soạn thảo đang hoạt động. Không giống như mô hình Java, AST thường được xem là mô hình "trung gian", "tạm thời", các phần tử trong đó máy khách không nên giữ các tham chiếu bên ngoài bối cảnh hoạt động dẫn đến việc tạo ra AST.
Ba mô hình được liệt kê (mô hình Java, AST, các liên kết) cùng nhau tạo thành cơ sở để xây dựng “các công cụ phát triển thông minh” trong JDT, bao gồm một trình soạn thảo Java mạnh mẽ với nhiều “trình trợ giúp” khác nhau, các hành động khác nhau để xử lý mã nguồn (bao gồm tổ chức danh sách nhập tên và định dạng theo phong cách tùy chỉnh), công cụ tìm kiếm và tái cấu trúc. Trong trường hợp này, mô hình Java đóng một vai trò đặc biệt, vì nó được sử dụng làm cơ sở cho việc trình bày trực quan cấu trúc của ứng dụng đang được phát triển (ví dụ: trong Package Explorer, Outline, Search, Call Hierarchy và Loại phân cấp).
Các thành phần Eclipse được sử dụng trong 1C:Công cụ phát triển doanh nghiệp
Trong bộ lễ phục. Hình 7 cho thấy các thành phần Eclipse tạo thành nền tảng của nền tảng công nghệ cho các Công cụ Phát triển Doanh nghiệp 1C:Enterprise.
Cơm. 7. Eclipse làm nền tảng cho 1C:Công cụ phát triển doanh nghiệp
Nền tảng Eclipse cung cấp cơ sở hạ tầng cơ bản. Chúng tôi đã xem xét một số khía cạnh của cơ sở hạ tầng này trong phần trước.
(EMF) cung cấp một phương tiện chung để mô hình hóa dữ liệu có cấu trúc. EMF được tích hợp với Nền tảng Eclipse nhưng cũng có thể được sử dụng riêng trong các ứng dụng Java thông thường. Thông thường, các nhà phát triển Eclipse mới đã quen thuộc với EMF, mặc dù họ chưa hiểu đầy đủ về sự phức tạp của Nền tảng Eclipse. Một trong những lý do cho sự phổ biến xứng đáng như vậy là thiết kế phổ quát, bao gồm, cùng với những thứ khác, API cấp độ meta thống nhất, cho phép bạn làm việc với bất kỳ mô hình EMF nào một cách tổng quát. Việc triển khai cơ bản cho các đối tượng mô hình do EMF cung cấp và hệ thống con để tạo mã mô hình dựa trên siêu mô hình giúp tăng đáng kể tốc độ phát triển và giảm số lượng lỗi. EMF cũng chứa các cơ chế để tuần tự hóa các mô hình, theo dõi các thay đổi đối với mô hình, v.v.
Giống như bất kỳ công cụ thực sự có mục đích chung nào, EMF phù hợp để giải quyết nhiều vấn đề về mô hình hóa, nhưng một số loại mô hình (ví dụ: các mô hình dựa trên tay cầm đã thảo luận ở trên) có thể yêu cầu các công cụ mô hình hóa chuyên dụng hơn. Nói về EMF là một công việc vô ơn, đặc biệt là trong giới hạn của một bài viết, vì đây là chủ đề của một cuốn sách riêng và là một cuốn sách khá dày. Chúng tôi chỉ lưu ý rằng hệ thống khái quát hóa chất lượng cao làm nền tảng cho EMF đã cho phép ra đời một loạt các dự án dành riêng cho mô hình hóa, được bao gồm trong dự án cấp cao nhất cùng với chính EMF. Một dự án như vậy là Eclipse Xtext.
cung cấp cơ sở hạ tầng "mô hình hóa văn bản". sử dụng Xtext để phân tích văn bản nguồn và EMF để biểu diễn ASG kết quả (biểu đồ ngữ nghĩa trừu tượng, về cơ bản là sự kết hợp giữa AST và các ràng buộc), còn được gọi là “mô hình ngữ nghĩa”. Ngữ pháp của ngôn ngữ được mô hình hóa bởi Xtext được mô tả bằng ngôn ngữ riêng của Xtext. Điều này cho phép bạn không chỉ tạo mô tả ngữ pháp cho ANTLR mà còn có được cơ chế tuần tự hóa AST (tức là Xtext cung cấp cả trình phân tích cú pháp và trình giải mã), gợi ý ngữ cảnh và một số thành phần ngôn ngữ khác. Mặt khác, ngôn ngữ ngữ pháp được sử dụng trong Xtext kém linh hoạt hơn so với ngôn ngữ ngữ pháp được sử dụng trong ANTLR. Do đó, đôi khi cần phải “bẻ cong” ngôn ngữ đã triển khai thành Xtext, điều này thường không thành vấn đề nếu chúng ta đang nói về một ngôn ngữ được phát triển từ đầu, nhưng có thể không được chấp nhận đối với các ngôn ngữ có cú pháp đã được thiết lập sẵn. Mặc dù vậy, Xtext hiện là công cụ hoàn thiện, giàu tính năng và linh hoạt nhất trong Eclipse để xây dựng các ngôn ngữ lập trình và công cụ phát triển cho chúng. Đặc biệt, nó là một công cụ lý tưởng để tạo mẫu nhanh (ngôn ngữ dành riêng cho tên miền, DSL). Ngoài “lõi ngôn ngữ” dựa trên ANTLR và EMF đã đề cập ở trên, Xtext còn cung cấp nhiều thành phần hữu ích cấp cao hơn, bao gồm cơ chế lập chỉ mục, cấu trúc tăng dần, “trình soạn thảo thông minh” và nhiều hơn thế nữa, nhưng không có phần xử lý- mô hình ngôn ngữ dựa trên Giống như EMF, Xtext là một chủ đề xứng đáng có trong một cuốn sách riêng và hiện tại chúng ta khó có thể nói ngắn gọn về tất cả các khả năng của nó.
1C:Enterprise Development Tools tích cực sử dụng cả EMF và một số dự án Mô hình hóa Eclipse khác. Đặc biệt, Xtext là một trong những nền tảng của các công cụ phát triển cho các ngôn ngữ 1C:Enterprise như ngôn ngữ lập trình và ngôn ngữ truy vấn tích hợp. Một cơ sở khác cho các công cụ phát triển này là dự án Eclipse Handly mà chúng ta sẽ thảo luận chi tiết hơn (trong số các thành phần Eclipse được liệt kê, nó vẫn là thành phần ít được biết đến nhất).
, một tiểu dự án của dự án cấp cao nhất Công nghệ Eclipse, nổi lên do sự đóng góp mã ban đầu cho Quỹ Eclipse do 1C thực hiện vào năm 2014. Kể từ đó, 1C tiếp tục hỗ trợ phát triển dự án: Những người cam kết tận tình là nhân viên của công ty. Dự án này tuy nhỏ nhưng chiếm một vị trí khá độc đáo trong Eclipse: mục tiêu chính của nó là hỗ trợ phát triển các mô hình dựa trên tay cầm.
Các nguyên tắc kiến trúc cơ bản của các mô hình dựa trên bộ điều khiển, chẳng hạn như thành ngữ bộ điều khiển/nội dung, đã được thảo luận ở trên bằng cách sử dụng mô hình tài nguyên và mô hình Java làm ví dụ. Nó cũng lưu ý rằng cả mô hình tài nguyên và mô hình Java đều là nền tảng quan trọng cho các công cụ phát triển Java Eclipse (JDT). Và vì hầu hết tất cả các dự án Eclipse *DT đều có kiến trúc tương tự JDT, nên sẽ không quá lời khi nói rằng các mô hình dựa trên tay cầm làm nền tảng cho nhiều, nếu không phải là tất cả các IDE được xây dựng trên Nền tảng Eclipse. Ví dụ, Công cụ phát triển C/C++ Eclipse (CDT) có mô hình C/C++ dựa trên tay cầm đóng vai trò tương tự trong kiến trúc CDT giống như mô hình Java thực hiện trong JDT.
Trước Handly, Eclipse không cung cấp các thư viện chuyên biệt để xây dựng các mô hình ngôn ngữ dựa trên tay cầm. Các mô hình hiện đang tồn tại được tạo ra chủ yếu bằng cách điều chỉnh trực tiếp mã mô hình Java (còn gọi là sao chép/dán), trong trường hợp nó cho phép Giấy phép Công cộng Eclipse (EPL). (Rõ ràng, đây thường không phải là vấn đề pháp lý đối với bản thân các dự án Eclipse, nhưng không phải đối với các sản phẩm nguồn đóng.) Ngoài tính lộn xộn vốn có của nó, kỹ thuật này còn gây ra các vấn đề nổi tiếng: sao chép mã được đưa ra khi thích ứng với các lỗi, vân vân. Điều tồi tệ hơn là các mô hình thu được vẫn là “bản thân mọi thứ” và không tận dụng được tiềm năng thống nhất. Nhưng việc tách biệt các khái niệm và giao thức chung cho các mô hình ngôn ngữ dựa trên tay cầm có thể dẫn đến việc tạo ra các thành phần có thể tái sử dụng để làm việc với chúng, tương tự như những gì đã xảy ra trong trường hợp EMF.
Không phải Eclipse không hiểu những vấn đề này. Trở lại năm 2005 , tóm tắt kinh nghiệm phát triển nguyên mẫu CDT, nhu cầu tạo cơ sở hạ tầng chung cho các mô hình ngôn ngữ, bao gồm cả các mô hình dựa trên tay cầm. Tuy nhiên, như thường lệ, do các nhiệm vụ có mức độ ưu tiên cao hơn nên việc thực hiện những ý tưởng này không bao giờ thành công. Trong khi đó, việc phân tích nhân tử của mã *DT vẫn là một trong những chủ đề chưa được phát triển trong Eclipse.
Theo một nghĩa nào đó, dự án Handly được thiết kế để giải quyết các vấn đề gần giống như EMF, nhưng dành cho các mô hình dựa trên tay cầm và chủ yếu là các mô hình ngôn ngữ (tức là biểu diễn các thành phần cấu trúc của một số ngôn ngữ lập trình). Các mục tiêu chính đặt ra khi thiết kế Handy được liệt kê dưới đây:
- Xác định các trừu tượng chính của lĩnh vực chủ đề.
- Giảm nỗ lực và cải thiện chất lượng triển khai các mô hình ngôn ngữ dựa trên tay cầm thông qua việc tái sử dụng mã.
- Cung cấp API cấp meta thống nhất cho các mô hình kết quả, giúp tạo các thành phần IDE phổ biến hoạt động với các mô hình dựa trên trình điều khiển ngôn ngữ.
- Tính linh hoạt và khả năng mở rộng.
- Tích hợp với Xtext (trong một lớp riêng biệt).
Để làm nổi bật các khái niệm và giao thức phổ biến, chúng tôi đã phân tích việc triển khai các mô hình dựa trên trình xử lý ngôn ngữ hiện có. Các giao diện chính và cách triển khai cơ bản do Handly cung cấp được hiển thị trong Hình. số 8.
Cơm. 8. Giao diện chung và cách triển khai cơ bản của các phần tử Handy
Giao diện IElement đại diện cho phần điều khiển của một phần tử và chung cho các phần tử của tất cả các mô hình dựa trên Handy. Lớp trừu tượng Element triển khai cơ chế xử lý/thân tổng quát (Hình 9).
Cơm. 9. IElement và cách triển khai phần thân/phần xử lý chung
Ngoài ra, Handly còn cung cấp một cơ chế tổng quát để thông báo về những thay đổi trong các thành phần mô hình (Hình 10). Như bạn có thể thấy, nó gần giống với các cơ chế thông báo được triển khai trong mô hình tài nguyên và mô hình Java, đồng thời sử dụng IElementDelta để cung cấp cách trình bày thống nhất về thông tin thay đổi phần tử.
Cơm. 10. Giao diện chung và cách triển khai cơ bản của cơ chế thông báo Handy
Phần Handly được thảo luận ở trên (Hình 9 và 10) có thể được sử dụng để thể hiện hầu hết mọi mô hình dựa trên tay cầm. Để tạo ngôn ngữ học mô hình, dự án cung cấp chức năng bổ sung - đặc biệt là các giao diện chung và cách triển khai cơ bản cho các thành phần của cấu trúc văn bản nguồn, cái gọi là yếu tố nguồn (Hình 8). Giao diện ISourceFile đại diện cho một tệp nguồn và ISourceConstruct đại diện cho một phần tử trong tệp nguồn. Các lớp trừu tượng SourceFile và SourceConstruct triển khai các cơ chế tổng quát để hỗ trợ làm việc với các tệp nguồn và các phần tử của chúng, ví dụ, làm việc với bộ đệm văn bản, liên kết với tọa độ của một phần tử trong văn bản nguồn, đối chiếu các mô hình với nội dung hiện tại của bộ đệm bản sao đang hoạt động , vân vân. Việc triển khai các cơ chế này thường là một thách thức khá lớn và Handly có thể giảm đáng kể nỗ lực phát triển các mô hình ngôn ngữ dựa trên bộ điều khiển bằng cách cung cấp các triển khai cơ sở chất lượng cao.
Ngoài các cơ chế cốt lõi được liệt kê ở trên, Handly còn cung cấp cơ sở hạ tầng cho bộ đệm văn bản và ảnh chụp nhanh, hỗ trợ tích hợp với trình chỉnh sửa mã nguồn (bao gồm tích hợp ngay lập tức với trình soạn thảo Xtext), cũng như một số thành phần giao diện người dùng phổ biến giúp làm việc với các trình soạn thảo mã nguồn Handy như khung phác thảo. Để minh họa các khả năng của nó, dự án cung cấp một số ví dụ, bao gồm việc triển khai mô hình Java trong Handy. (So với việc triển khai đầy đủ mô hình Java trong JDT, mô hình này được cố tình đơn giản hóa phần nào để rõ ràng hơn.)
Như đã lưu ý trước đó, trọng tâm chính trong quá trình thiết kế ban đầu và quá trình phát triển tiếp theo của Handly vẫn là khả năng mở rộng và tính linh hoạt.
Về nguyên tắc, các mô hình có tay cầm có quy mô khá tốt “theo thiết kế”. Ví dụ: thành ngữ xử lý/nội dung cho phép bạn giới hạn lượng bộ nhớ mà một mô hình tiêu thụ. Nhưng cũng có những sắc thái. Do đó, khi kiểm tra khả năng mở rộng của Handy, một vấn đề đã được phát hiện trong quá trình triển khai cơ chế thông báo - khi một số lượng lớn các phần tử được thay đổi, việc xây dựng vùng đồng bằng mất quá nhiều thời gian. Hóa ra vấn đề tương tự cũng xuất hiện trong mô hình JDT Java, từ đó mã tương ứng đã từng được điều chỉnh. Chúng tôi đã sửa lỗi trong Handly và chuẩn bị một bản vá tương tự cho JDT, bản vá này đã được đón nhận một cách biết ơn. Đây chỉ là một ví dụ trong đó việc đưa Handly vào triển khai mô hình hiện tại có thể hữu ích vì trong trường hợp này, lỗi như vậy có thể được sửa chỉ ở một nơi.
Để việc triển khai Handy vào các triển khai mô hình hiện tại khả thi về mặt kỹ thuật, thư viện phải có tính linh hoạt đáng kể. Vấn đề chính là duy trì khả năng tương thích ngược trên mô hình API. Vấn đề này đã được giải quyết trong bằng cách tách biệt rõ ràng API dành riêng cho mô hình, do nhà phát triển xác định và kiểm soát hoàn toàn, khỏi API cấp meta thống nhất do thư viện cung cấp. Điều này không chỉ giúp có thể triển khai Handly vào các triển khai hiện có về mặt kỹ thuật mà còn mang lại cho nhà phát triển mô hình mới sự tự do đáng kể khi thiết kế API.
Tính linh hoạt cũng có những khía cạnh khác. Ví dụ: Handly hầu như không áp đặt hạn chế nào đối với cấu trúc của mô hình và có thể được sử dụng để lập mô hình cho cả ngôn ngữ có mục đích chung và ngôn ngữ dành riêng cho miền. Khi xây dựng cấu trúc của tệp nguồn, Handly không quy định bất kỳ hình thức biểu diễn AST cụ thể nào và về nguyên tắc, thậm chí không yêu cầu sự hiện diện của chính AST, do đó đảm bảo khả năng tương thích với hầu hết mọi cơ chế phân tích cú pháp. Cuối cùng, Handly hỗ trợ tích hợp đầy đủ với không gian làm việc của Eclipse nhưng cũng có thể làm việc trực tiếp với các hệ thống tệp nhờ tích hợp với (EFS).
Phiên bản hiện tại ra mắt vào tháng 2016 năm XNUMX. Mặc dù thực tế là dự án hiện đang trong giai đoạn ươm tạo và API cuối cùng vẫn chưa được sửa chữa, Handly đã được sử dụng trong hai sản phẩm thương mại lớn có nguy cơ đóng vai trò là "người áp dụng sớm" và tôi phải nói rằng, đừng hối tiếc nữa.
Như đã lưu ý ở trên, một trong những sản phẩm này là 1C:Enterprise Development Tools, trong đó Handly được sử dụng ngay từ đầu để mô hình hóa các thành phần cấu trúc cấp cao của các ngôn ngữ 1C:Enterprise như ngôn ngữ lập trình tích hợp và ngôn ngữ truy vấn . Một sản phẩm khác ít được công chúng biết đến hơn. Cái này , một môi trường thiết kế tích hợp cho bộ xử lý tập lệnh dành riêng cho ứng dụng (ASIP), được sử dụng cả trong chính công ty Codasip của Séc và các khách hàng của nó, bao gồm , , , . Codasip đã sử dụng Handy trong sản xuất từ năm 2015, bắt đầu với phiên bản Handy 0.2. Bản phát hành mới nhất của Codasip Studio sử dụng phiên bản 0.5, phát hành vào tháng 2016 năm 4000. Ondřej Ilčík, người lãnh đạo việc phát triển IDE tại Codasip, đang liên hệ với dự án, thay mặt cho “bên áp dụng bên thứ ba” đưa ra những phản hồi quan trọng. Anh ấy thậm chí còn có thể tìm thấy thời gian rảnh để tham gia trực tiếp vào quá trình phát triển dự án, triển khai lớp giao diện người dùng (~XNUMX dòng mã) cho một trong những ví dụ Handy, một mô hình Java. Thông tin trực tiếp chi tiết hơn về việc sử dụng Handly của người áp dụng có thể được tìm thấy trên trang dự án.
Chúng tôi hy vọng rằng sau khi phát hành phiên bản 1.0 với sự đảm bảo về tính ổn định của API và dự án rời khỏi trạng thái ươm tạo, Handly sẽ có những người áp dụng mới. Trong khi chờ đợi, dự án tiếp tục thử nghiệm và cải tiến hơn nữa API, phát hành hai bản phát hành "chính" mỗi năm - vào tháng XNUMX (cùng ngày với bản phát hành Eclipse đồng thời) và tháng XNUMX, cung cấp lịch trình có thể dự đoán được mà những người áp dụng có thể dựa vào. Chúng tôi cũng có thể nói thêm rằng “tỷ lệ lỗi” của dự án vẫn luôn ở mức thấp và Handly đã hoạt động đáng tin cậy trong các sản phẩm của những người dùng đầu tiên kể từ những phiên bản đầu tiên. Để khám phá thêm về Eclipse Handly, bạn có thể sử dụng и .
Nguồn: www.habr.com