Công nghệ nào sử dụng trong việc tạo DSL cho công cụ quy tắc?

Question

Bạn sẽ đề xuất công nghệ nào để tạo DSL cho một Business Rules and Validation Application Block for .NET? Và tại sao?

Kiến trúc khung được thiết lập và được kiểm chứng bằng sản xuất. Tôi chỉ muốn tạo một bộ xử lý .NET để chuyển đổi các quy tắc có thể đọc được của con người thành các thực thi Rule đã biên dịch.

Các tùy chọn mà tôi biết là:

• Sử dụng trình biên dịch đường ống của .NET Boo
• Sử dụng các nhà xây dựng phân tích cú pháp đi kèm với F # - FsLex and FsYacc

Đáng tiếc là không ai trong số những phương pháp cung cấp bất cứ điều gì để xây dựng IDE thân thiện hơn hoặc ít hơn để chỉnh sửa DSL, với cú pháp DSL (sẽ phát triển).

Bất kỳ ý tưởng hoặc gợi ý nào?

Answer 1

của Microsoft thế hệ kế tiếp nền tảng phát triển ứng dụng, có tên mã là Oslo

Làm cho nó dễ dàng hơn cho người dân để viết những điều xuống theo những cách mà có ý nghĩa cho các miền vấn đề họ đang làm việc trong

Oslo dường như bao gồm một công cụ thiết kế trực quan có tên "Quadrant", một ngôn ngữ lập trình có tên là "M" và kho lưu trữ "Oslo" (cơ sở dữ liệu SQL Server) lưu trữ các quy tắc. Vì vậy, nếu tôi đọc chính xác, bạn có thể định nghĩa ngôn ngữ lập trình bằng M, sử dụng Quadrant để xác định và chỉnh sửa quy tắc xác nhận của bạn bằng ngôn ngữ lập trình của riêng bạn và viết một ứng dụng sử dụng kho lưu trữ Oslo. Quy tắc và khối ứng dụng xác thực cho .NET.

Answer 2

Nếu bạn muốn tạo một IDE thân thiện chỉnh sửa DSL, hãy làm cho IDE hoàn toàn đồ họa và biên dịch thành đối tượng .NET (hoặc sử dụng ngôn ngữ keo như IronPython).

Nếu các quy tắc đủ đơn giản, bạn có thể triển khai toàn bộ cấu trúc quy tắc theo đồ họa. Nếu các quy tắc đủ phức tạp, "khả năng đọc của con người" trở thành mục tiêu không thể. Dù bằng cách nào, nếu một tập hợp các lớp .NET hoặc các đối tượng IronPython tạo mã trung gian không phải là "có thể đọc được" đủ, thì rất có thể, bạn muốn một cái gì đó giả mạo hơn một ngữ pháp. Điều đó nói rằng, nếu bạn chỉ muốn tạo một ngôn ngữ đơn giản mà các lập trình viên có thể sử dụng để tạo Quy tắc kinh doanh, hãy sử dụng bất kỳ điều nào ở trên và làm cho cú pháp tối giản đủ để không cần IDE của Visual Studio.

Answer 3

Ngôn ngữ đồ họa cho quy tắc kinh doanh không phải là một ý tưởng hay. Tôi sẽ tránh nó Quy tắc kinh doanh có rất nhiều nếu kiểm tra và vòng trong họ, mà không hình dung tốt.

Bạn nên sử dụng ngôn ngữ văn bản để mô tả quy tắc kinh doanh tốt hơn nhiều.

Để có được trải nghiệm người dùng phenomenial cho mã chỉnh sửa bạn cần:

1. Một phân tích cú pháp phục hồi lỗi tốt
2. Khả năng làm gia tăng tái lập

phục hồi tốt lỗi cho phép bạn để xác định hiệu quả ý định của chương trình từ các cấu trúc không hoàn chỉnh. Điều đó rất quan trọng cho việc thực hiện intellisence.

Khả năng biên dịch lại gia tăng cho bạn khả năng thực hiện biên dịch nền hiệu quả để phản hồi các chỉnh sửa của người dùng.

Cách dễ nhất để khôi phục lỗi tốt là viết trình phân tích cú pháp của bạn bằng tay. Bằng cách đó bạn có thể sử dụng bất kỳ số lượng nào nhìn về phía trước, hoặc các quy tắc algrorithmic, để tìm ra những gì cần làm khi có lỗi cú pháp.

Khi bạn sử dụng trình tạo trình phân tích cú pháp để tạo trình phân tích cú pháp, bạn mất rất nhiều tính linh hoạt trong việc xử lý các lỗi cú pháp. Sự linh hoạt đó tạo ra sự khác biệt giữa một expereince intellisence tốt và một cái crapy. Vì vậy, tôi khuyên bạn chỉ cần viết nó bằng tay bằng cách sử dụng đệ quy gốc.

Thực hiện tái biên dịch hiệu quả yêu cầu bạn có thể: 1) Phân tích hợp lý phân tích ngữ nghĩa thành các giai đoạn (ví dụ: C# này sẽ là: đầu tiên xây dựng ký hiệu không gian tên và loại, sau đó giải quyết bằng cách sử dụng câu lệnh) các lớp học, v.v.) 2) Khả năng xây dựng biểu đồ phụ thuộc nhận biết pha 3) Thuật toán xử lý biểu đồ phụ thuộc và làm mất hiệu lực các phần của nó theo các chỉnh sửa của người dùng

Đối với ngôn ngữ lập trình đầy đủ, thực hiện việc biên dịch lại có thể nhận được thực sự phức tạp. Trong trường hợp của bạn, bởi vì bạn đang mô tả các quy tắc kinh doanh, nó có thể được nhiều simpiler cho bạn (hoặc nếu biên dịch là đủ nhanh, bạn có thể thậm chí không cần nó).

Vì vậy, tôi sẽ bắt đầu với trình phân tích cú pháp, sau đó xây dựng sự quan tâm trên đầu trang của nó.

Nếu bạn có thể tránh tích hợp VS, tôi sẽ làm như vậy. Tích hợp vào VS đòi hỏi rất nhiều hệ thống ống nước, và interop có khả năng gây đau đầu. Có một vài công ty bán các điều khiển trình soạn thảo biểu mẫu windows mà bạn nối trình phân tích cú pháp của mình lên tới. Đó là dễ dàng hơn nhiều để tích hợp với hơn VS.

Answer 4

Một giải pháp thay thế thú vị khác là sử dụng các trích dẫn F #.

Báo giá cho phép bạn xử lý một phần của chương trình dưới dạng dữ liệu, vì vậy bạn có thể lấy AST, phân tích và dịch sang ngôn ngữ khác hoặc thực thi theo cách không chuẩn. Cùng với sự linh hoạt của F #, bạn sẽ có thể thể hiện nhiều thứ, vì vậy bạn phải phát triển một thư viện F # DSL/combinator nội bộ để mô tả các quy tắc và một phiên dịch/thông dịch cho F # trích dẫn để chạy chúng.

Không chắc thế nào một quy tắc Bussines có thể trông như thế nào, nhưng bạn có thể viết một cái gì đó như thế này:

let rule = <@ 
    if (exists customer having validEmail) then success 
    else require whatever 
@> 

tôi đã viết một giới thiệu về chủ đề này trên blog của tôi. Unfortunatelly, đã có một số thay đổi lớn trong F # CTP và tôi chưa cập nhật mã nguồn, nhưng nó sẽ cung cấp cho bạn một ý tưởng tốt về những hạn chế của phương pháp này là những hạn chế nào.

• F# Quotations Samples on CodePlex - TomasP.Net

Một ví dụ điển hình của DSL là F # kiểm tra đơn vị framewrok:

• Announcing FsTest - A Testing DSL for F# - Matthew Podwysocki

[EDIT] Chỉ cần làm rõ lý do tại sao tôi nghĩ thi s có thể là một cách tiếp cận tốt:

• Nếu bạn sử dụng Visual Studio để chỉnh sửa DSL (và bạn có thể sử dụng phiên bản Shell với F # được cài đặt miễn phí), bạn sẽ có trải nghiệm chỉnh sửa rất tốt miễn phí. Không chỉ làm nổi bật cú pháp, mà còn là IntelliSense sẽ đề xuất các cấu trúc có thể có và cũng là kiểm tra kiểu nền để phục vụ như kiểm tra ngữ pháp cho DSL của bạn.
• So với các phương pháp tiếp cận khác, đây có lẽ là một trong những cách dễ nhất để triển khai.
• Giới hạn duy nhất là bạn bị giới hạn bởi cú pháp F #. Tuy nhiên, thiết kế ngôn ngữ của riêng bạn thực sự là khó khăn, vì vậy điều này có thể không phải là xấu cả. Đặc biệt là sự linh hoạt của F #.

[/ EDIT]

Hope this helps!

Answer 5

Tôi muốn sử dụng Boo, tôi nghĩ rằng đó hiện là một trong những công cụ linh hoạt nhất để tạo DSL. Có một số very good book về chủ đề. Ayende's và Rodrigo's blog cũng là nguồn cảm hứng tốt.

Giới thiệu về IDE, bạn có thể mở rộng SharpDevelop, hãy xem this.

Answer 6

JetBrains Meta Programming System

Bạn có thể xác định biên tập ngôn ngữ tùy chỉnh và hạn chế khác đối với bất kỳ ngôn ngữ mới, để làm việc với những DSL trở nên thực sự đơn giản. Các chuyên gia tên miền không quen thuộc với lập trình truyền thống có thể dễ dàng làm việc trong MPS với các ngôn ngữ cụ thể theo miền của họ bằng cách sử dụng thuật ngữ tên miền cụ thể.

Answer 7

Tôi là người mới, nhưng OMeta có vẻ như là một công cụ lý tưởng để phát triển DSL. Có vẻ như không phải là một IDE xung quanh nó, nhưng tin tốt là "quy tắc" người ta có thể viết trong OMeta là rất dễ đọc. (Và nó đề cập đến việc đệ quy trái, điều này rất tuyệt vời.)

Hiện tại, việc triển khai OMeta ở ít nhất Javascript (rất thú vị đối với tôi) và Python, có lẽ là những người khác. Đối với C#, Jeff Moser đang làm việc trên một cái mà bạn có thể đọc về trên his blog và xem qua tại CodePlex. Chúc may mắn.

Answer 8

Công cụ chuẩn để xây dựng đường nối DSL là ANTLR - nó là trình tạo trình phân tích cú pháp/trình phân tích cú pháp mạnh mẽ với nhiều ngôn ngữ đích cho đầu ra trình biên dịch. Nó có backends cho C#, Java, C/C++, Python, vv (xem danh sách code generation targets) và cho phép bạn chèn mã tùy chỉnh vào trình biên dịch của bạn bằng ngôn ngữ đích dễ dàng.

Ngoài ra còn có một IDE rất mạnh (ANTLRWorks) và nhiều tài liệu. (Hãy xem The Defenitive ANTLR Reference từ Terrence Parr, tác giả của ANTLR) Để tham khảo về những người khác sử dụng nó, hãy xem trang Testimonlals.

Bạn vẫn cần phải thực hiện hầu hết các hệ thống ống nước cho bản thân IDE, nhưng sẽ dễ dàng hơn nhiều cho khung trình biên dịch mạnh mẽ mà bạn sẽ nhận được từ ANTLR. Đây là trường hợp đối với hầu hết các giải pháp được đăng tại đây ...

Tôi hiện đang sử dụng trình biên dịch được viết bằng ANTLR để xử lý trước DSL của riêng mình thành đầu ra C/C++ và tôi rất hài lòng với nó. Đủ các quảng cáo, bạn nên thử nó cho chính mình :) Hãy vui vẻ!

Answer 9

Ruby là ngôn ngữ tuyệt vời để tạo DSL. Ví dụ: Rake là một tập lệnh xây dựng DSL được viết bằng Ruby.

Với số IronRuby sắp tới, bạn có thể viết tập lệnh gọi mã C# của bạn trực tiếp.

Here'ssomearticles viết DSL trong Ruby.

Answer 10

Boo + OMeta = Boo.OMeta.Parser

Hiện nay phân tích cú pháp đang được phát triển nhưng nó đã có thể được sử dụng để tạo ra các DSL bên ngoài phức tạp. OMeta là công cụ mạnh mẽ cho phép các lập trình viên dễ dàng thực hiện các trình phân tích cú pháp và phân tích từ vựng. Kiến trúc đường ống biên dịch mở rộng của Boo cho phép thay thế Boo.Parser chuẩn với Boo.OMeta.Parser. Nó có thể được sử dụng để mở rộng cú pháp Boo với hầu như bất kỳ loại cú pháp nào. Ví dụ có thể tìm thấy here.

Answer 11

Dự án của tôi meta# đang cố gắng giải quyết vấn đề này.