Quale tecnologia utilizzare per creare DSL per il motore delle regole?

Question

Quale tecnologia consiglieresti per creare una DSL per un Business Rules and Validation Application Block for .NET? E perché?

L'architettura del framework è stabilita e testata da una produzione. Voglio solo creare un processore .NET per trasformare regole leggibili da umani in implementazioni di regole compilate.

Le opzioni che io sappia sono:

• Uso gasdotto compilatore di .NET Boo
• Utilizzare i costruttori parser che vengono con F # - FsLex and FsYacc

Purtroppo nessuno di questi approcci fornisce qualsiasi cosa per costruire IDE più o meno amichevoli per la modifica di DSL, data la sintassi DSL (che si evolverebbe).

Qualche idea o suggerimento?

Answer 1

piattaforma di sviluppo di applicazioni Microsoft di nuova generazione, nome in codice Oslo

rende più facile per le persone a scrivere le cose in modi che hanno senso per il dominio del problema si sta lavorando in

Oslo sembra sono costituiti da uno strumento di progettazione visuale denominato "Quadrant", un linguaggio di modellazione denominato "M" e il repository "Oslo" (un database di SQL Server) che memorizza le regole.

Quindi, se leggo correttamente le cose, è possibile definire un linguaggio di modellazione in M, utilizzare Quadrante per definire e modificare le regole di convalida utilizzando il proprio linguaggio di modellazione e scrivere un'applicazione che faccia uso del repository Oslo, generando il proprio Business Regole e blocco di applicazioni di convalida per .NET.

Answer 2

Se si desidera creare un IDE amichevole che modifica i DSL, rendere l'IDE completamente grafico e compilare in oggetti .NET (o utilizzare qualcosa come IronPython come linguaggio di colla).

Se le regole sono abbastanza semplici, è possibile implementare graficamente l'intera struttura di regole. Se le regole sono abbastanza complesse, la "leggibilità umana" diventa un obiettivo impossibile.

In entrambi i casi, se un set di classi .NET o oggetti IronPython che creano il codice intermedio non è "leggibile" abbastanza, allora è probabile che si desideri qualcosa di più a prova di finto di una grammatica.

Detto questo, se si desidera creare un linguaggio semplice che i programmatori possano utilizzare per creare Business Rules, sentitevi liberi di utilizzare uno dei precedenti e rendere la sintassi sufficientemente minimalista da non richiedere l'IDE di Visual Studio.

Answer 3

Un linguaggio grafico per le regole aziendali non è una buona idea. Lo eviterei Le regole di business hanno molti controlli e loop che non visualizzano bene.

Stai molto meglio con un linguaggio testuale per descrivere le regole aziendali.

Per ottenere un'esperienza utente phenomenial per la modifica del codice è necessario:

1. Un parser con recupero di buona errore
2. La capacità di fare ri-compilazione incrementale

recupero Buon errore che permette per determinare in modo efficace l'intento del programmatore da costrutti sintatticamente incompleti. Questo è fondamentale per l'implementazione dell'intelligenza.

La possibilità di eseguire la ricompilazione incrementale offre la possibilità di eseguire un'efficace compilazione in background in risposta alle modifiche dell'utente.

Il modo più semplice per ottenere un buon recupero degli errori è scrivere il parser a mano. In questo modo puoi utilizzare qualsiasi quantità di sguardo in anticipo o regole algoritmiche per capire cosa fare in presenza di errori di sintassi.

Quando si utilizza un generatore di parser per creare il parser, si perde molta flessibilità nell'affrontare gli errori di sintassi. Questa flessibilità fa la differenza tra una buona esperienza intellettiva e una schifosa. Quindi, ti consiglio di scriverlo a mano usando la discesa ricorsiva.

Implementazione efficiente ri-compilazione richiede di essere in grado di: 1) correttamente abbattere analisi semantica in fasi (per qualcosa come C# questo sarebbe: prima di costruire namespace e tipo simboli, quindi risolvere utilizzando le istruzioni, poi risolvere di base classi, ecc.). 2) La possibilità di creare una fase di riconoscere grafico delle dipendenze 3) Algoritmi per l'elaborazione del grafico di dipendenza, e invalidante parti di esso in risposta a utente modifica

Per linguaggio completo flegged programmazione, attuazione ricompilazione riesce davvero difficile. Nel tuo caso, perché stai descrivendo le regole di business, potrebbe essere molto più semplice per te (o se la compilazione è abbastanza veloce potresti anche non averne bisogno).

Quindi, vorrei iniziare con il parser e quindi creare l'intelligenza su di esso.

Se è possibile evitare l'integrazione VS, lo farei. L'integrazione in VS richiede MOLTO impianto idraulico e l'interop potrebbe causare mal di testa. Ci sono alcune aziende che vendono controlli dell'editor di moduli di Windows a cui si aggancia il parser. Questo è molto più facile da integrare rispetto a VS.

Answer 4

Un'altra alternativa interessante è l'utilizzo delle citazioni di F #.

Le citazioni consentono di trattare parte del programma come dati, in modo da poter ottenere l'AST, analizzarlo e tradurlo in un'altra lingua o eseguirlo in un modo non standard. Insieme alla flessibilità di F #, dovresti essere in grado di esprimere molte cose, quindi dovresti sviluppare una libreria F # DSL/combinatore interna per descrivere le regole e un traduttore/interprete per le citazioni di F # per eseguirle.

Non sono sicuro di come una regola di bussines potrebbe apparire come, ma si potrebbe scrivere qualcosa del genere:

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

ho scritto un'introduzione a questo argomento sul mio blog. Purtroppo, ci sono stati alcuni grossi cambiamenti nel C# di F # e non ho ancora aggiornato il codice sorgente, ma dovrebbe darti una buona idea di quali siano le possibili limitazioni di questo approccio.

• F# Quotations Samples on CodePlex - TomasP.Net

Un buon esempio di DSL è F # Unit Testing framewrok:

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

[EDIT] Giusto per chiarire il motivo per cui penso che s può essere un buon approccio:

• Se si utilizza Visual Studio per editting i DSL (ed è possibile utilizzare la versione di Shell con F # installato gratuitamente), si otterrà un'esperienza molto positiva la modifica gratuitamente. Non solo l'evidenziazione della sintassi, ma anche IntelliSense che suggerirà i possibili costrutti e anche un controllo di tipo in background che funge da correttore di 'grammatica' per il tuo DSL.
• Rispetto ad altri approcci, questo è forse uno dei più facili da implementare.
• L'unica limitazione è che sei limitato dalla sintassi F #. Tuttavia, progettare la tua lingua è davvero difficile, quindi potrebbe non essere poi così male. Soprattutto data la flessibilità di F #.

[/ EDIT]

Spero che questo aiuti!

Answer 5

Vorrei usare Boo, penso che sia attualmente uno degli strumenti più flessibili per la creazione di DSL. C'è un very good book sull'argomento. I blog Ayende's e Rodrigo's sono anche una buona fonte di ispirazione.

Informazioni sull'IDE, è possibile estendere SharpDevelop, dare un'occhiata a this.

Answer 6

JetBrains Meta Programming System

È possibile definire editor di linguaggio personalizzato e altri vincoli per qualsiasi nuova lingua, in modo che il lavoro con quelle DSL diventa davvero semplice. Gli esperti di dominio che non hanno familiarità con la programmazione tradizionale possono facilmente lavorare in MPS con i loro linguaggi specifici del dominio utilizzando la terminologia specifica del dominio.

Answer 7

Sono nuovo, ma lo OMeta sembra uno strumento ideale per lo sviluppo di DSL. Non sembra esserci un IDE attorno ad esso, ma la buona notizia è che le "regole" che si possono scrivere su OMeta sono molto leggibili. (E si occupa di ricorsione a sinistra, che è molto interessante.)

Esistono attualmente implementazioni OMeta in almeno Javascript (molto eccitante per me) e Python, forse altri. Per quanto riguarda C#, Jeff Moser sta lavorando su uno, che potete leggere su his blog e vedere oltre CodePlex. Buona fortuna.

Answer 8

Lo strumento standard per la costruzione di giunzioni DSL da ANTLR - è un potente generatore di lexer/parser con un sacco di lingue di destinazione per l'output del compilatore. Ha backend per C#, Java, C/C++, Python ecc. (Vedi la lista) e ti permette di inserire facilmente codice personalizzato nel tuo compilatore nella tua lingua di arrivo.

C'è anche un IDE molto potente (ANTLRWorks) e molta documentazione. (Date un'occhiata a The Defenitive ANTLR Reference da Terrence Parr, l'autore di ANTLR) Per i riferimenti su chi lo usa, vedere la pagina Testimonlals.

È ancora necessario eseguire la maggior parte degli impianti idraulici per l'IDE, ma dovrebbe essere molto più semplice, dato il robusto framework del compilatore che si otterrà da ANTLR. Questo dovrebbe essere il caso per la maggior parte delle soluzioni pubblicate qui ...

Attualmente sto usando un compilatore scritto con ANTLR per preelaborare la nostra uscita da DSL a C/C++ e sono molto soddisfatto. Basta con l'annuncio, dovresti provarlo tu stesso :) Buon divertimento!

Answer 9

Ruby è un ottimo linguaggio per la creazione di DSL. Ad esempio Rake è uno script di compilazione DSL scritto con Ruby.

Con il prossimo IronRuby è possibile scrivere script che chiamano direttamente il codice C#.

somearticles sulla scrittura di DSL in Ruby.

Answer 10

fischio + Ometa = Boo.OMeta.Parser

Attualmente il parser è in fase di sviluppo ma può già essere utilizzato per la creazione dei DSL esterni complessi. OMeta è uno strumento potente che consente ai programmatori di implementare facilmente analizzatori e parser lessicali. L'architettura estendibile della pipeline del compilatore di Boo consente di sostituire Boo.Parser standard con Boo.OMeta.Parser. Può essere usato per estendere la sintassi Boo con quasi ogni tipo di sintassi. L'esempio può essere trovato here.

Answer 11

Il mio progetto meta# sta cercando di risolvere questo problema.