¿Qué tecnología usar para crear DSL para el motor de reglas?

¿Qué tecnología recomendarías para crear un DSL para un Business Rules and Validation Application Block for .NET? ¿Y por qué?¿Qué tecnología usar para crear DSL para el motor de reglas?

La arquitectura del marco está establecida y probada por una producción. Solo quiero crear un procesador .NET para transformar las reglas legibles para humanos en implementaciones de reglas compiladas.

Las opciones que yo sepa son:

uso de tuberías compilador de .NET Boo
Usar los constructores analizador que vienen con F # - FsLex and FsYacc

Desafortunadamente ninguno de estos enfoques ofrece cualquier cosa para construir IDE más o menos amigable para editar DSL, dada la sintaxis de DSL (que evolucionaría).

¿Alguna idea o sugerencia?

Fuente

2009-02-13 Rinat Abdullin

"demasiado" en el tema? – Svish

Gracias, lo perdí. –

plataforma de desarrollo de aplicaciones de próxima generación de Microsoft, con nombre en código Oslo

hace más fácil para la gente a escribir las cosas de manera que tengan sentido para el dominio del problema que están trabajando en

Oslo parece consiste en una herramienta de diseño visual llamada "Quadrant", un lenguaje de modelado llamado "M" y el repositorio "Oslo" (una base de datos SQL Server) que almacena las reglas.

Así que si leo las cosas correctamente, puede definir un lenguaje de modelado en M, usar Quadrant para definir y editar las reglas de validación usando su propio lenguaje de modelado y escribir una aplicación que haga uso del repositorio de Oslo, generando su Negocio Bloque de aplicaciones de reglas y validación para .NET.

Fuente

2009-02-16 23:42:58

Acabo de utilizar esto para implementar un DSL simple y, aunque los bits aún están un poco crudos, parece prometedor, especialmente con la integración de intellipad. –

He estado retocando con Oslo, y es muy revelador. –

¿No está esto muerto ahora? –

Si desea crear un IDE amigable que edite las DSL, conviértalo completamente gráfico y compile objetos .NET (o use algo como IronPython como lenguaje de pegado).

Si las reglas son lo suficientemente simples, puede implementar toda la estructura de reglas gráficamente. Si las reglas son lo suficientemente complejas, la "legibilidad humana" se convierte en un objetivo imposible.

De cualquier manera, si un conjunto de clases .NET o objetos de IronPython que crean el código intermediario no es "legible para humanos" lo suficiente, entonces es probable que desee algo más a prueba de errores que una gramática.

Dicho esto, si lo que desea es crear un lenguaje sencillo que los programadores pueden utilizar para crear reglas de negocio, no dude en utilizar cualquiera de los anteriores, y crea la sintaxis minimalista suficiente para no necesitar IDE de Visual Studio.

Fuente

2009-02-13 13:41:16 user54650

Un lenguaje gráfico para reglas de negocios no es una buena idea. Lo evitaría Las reglas comerciales tienen muchas verificaciones y bucles, que no se visualizan bien.

Le conviene mucho un lenguaje textual para describir las reglas comerciales.

para conseguir una experiencia de usuario phenomenial para editar el código que necesita:

Un analizador con la recuperación buena error
La capacidad de hacer incrementales recompilación

recuperación Buena error que permite para determinar efectivamente la intención del programador a partir de construcciones sintácticamente incompletas. Eso es crucial para implementar intellisence.

La capacidad de realizar la recompilación incremental le brinda la capacidad de realizar una compilación de fondo eficiente en respuesta a las ediciones de los usuarios.

La forma más fácil de obtener una buena recuperación de errores es escribir su analizador a mano. De esta forma, puede usar cualquier cantidad de anticipación, o reglas algictitmicas, para descubrir qué hacer en presencia de errores de sintaxis.

Cuando utiliza un generador de analizador para crear su analizador sintáctico, pierde mucha flexibilidad al tratar con los errores de sintaxis. Esa flexibilidad hace la diferencia entre una buena experiencia de intelliscencia y una de crayoterapia. Entonces, te recomiendo que lo escribas a mano usando un descenso recursivo.

La implementación eficiente re-compilación requiere que usted será capaz de: 1) correctamente descomponer el análisis semántico en fases (por algo como C# esto sería: en primer lugar la construcción de espacios de nombres y tipo de símbolos, y luego resolver el uso de declaraciones, a continuación, resolver de base clases, etc.). 2) La capacidad de construir un gráfico de la dependencia de fase-consciente 3) algoritmos para el procesamiento de la gráfica de dependencia, y invalidar partes de ella en respuesta a usuario edita

Por idioma completamente flegged programación, la aplicación de re-compilación puede conseguir muy complicado En su caso, debido a que está describiendo las reglas del negocio, puede ser mucho más simple para usted (o si la compilación es lo suficientemente rápida como para no necesitarla).

Entonces, comenzaría con el analizador sintáctico y luego construiría intellisence encima de él.

Si puede evitar la integración de VS, lo haría. Integrarse en VS requiere MUCHA fontanería, y es probable que la interferencia cause dolores de cabeza. Hay algunas compañías que venden controles de editor de formularios de Windows que conecta su analizador. Son mucho más fáciles de integrar que VS.

Fuente

2009-02-13 14:03:42

Los bucles no son tan difíciles de hacer gráficos como lo son para explicar a los no programadores. He escrito en lenguajes gráficos con bucle pesado y no son tan malos como lo haces sonar. Envox CDP por ejemplo. Para los que no codifican, la solución significa que no hay errores de sintaxis. – user54650

Si alguien no es capaz de decir lo siguiente: foreach (cliente en CustomerList) { CalculateFicoScore (cliente); } ¿Cómo podrán alguna vez comprender una representación gráfica de la misma. Su parte difícil con bucles es el concepto, no la forma en que se muestra. –

Gran parte de la dificultad con la recuperación de errores cuando se utiliza un generador de analizador surge de las ambigüedades (incluidos los conflictos shift-reduce y reduce-reduce) que los analizadores LR y LALR manejan mal. El algoritmo GLR (como lo utiliza MS Oslo) resuelve gran parte de esto de forma natural. – Bevan

Otra alternativa posiblemente interesante es utilizar citas F #.

Las citas le permiten tratar parte del programa como datos, por lo que puede obtener el AST, analizarlo y traducirlo a otro idioma o ejecutarlo de forma no estándar. Junto con la flexibilidad de F #, debería poder expresar muchas cosas, por lo que tendría que desarrollar una biblioteca F # DSL/combinator interna para describir las reglas y un traductor/intérprete para las citas F # para ejecutarlas.

No estoy seguro como una regla Bussines podría ser similar, pero se podría escribir algo como esto:

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

me escribió una introducción a este tema en mi blog. Desafortunadamente, ha habido algunos grandes cambios en el F # CTP y aún no he actualizado el código fuente, pero debería darle una buena idea de cuáles son las posibilidades & de este enfoque.

F# Quotations Samples on CodePlex - TomasP.Net

Un buen ejemplo de DSL es F # framewrok unidad de prueba:

Announcing FsTest - A Testing DSL for F# - Mateo Podwysocki

[EDIT] Solo para aclarar por qué creo que esto s puede ser un buen método:

Si utiliza Visual Studio para los editting DSL (y se puede utilizar la versión de Shell con F # instalada de forma gratuita), obtendrá una muy buena experiencia de edición de forma gratuita. No solo resaltado de sintaxis, sino también IntelliSense que sugerirá las posibles construcciones y también una verificación de tipo de fondo que sirve como comprobador de "gramática" para su DSL.
En comparación con otros enfoques éste es quizás uno de los más fáciles de implementar.
La única limitación es que está limitado por la sintaxis F #. Sin embargo, diseñar tu propio idioma es realmente difícil, por lo que puede no ser nada malo. Especialmente dada la flexibilidad de F #.

[/ EDIT]

Espero que esto ayude!

Fuente

2009-02-13 14:49:19

que haría uso de Boo, creo que es actualmente una de las herramientas más flexibles para la creación de DSL. Hay un very good book sobre el tema. Ayende's y Rodrigo's blogs también son una buena inspiración.

Acerca del IDE, puede ampliar SharpDevelop, eche un vistazo a this.

Fuente

2009-02-13 15:06:59

JetBrains Meta Programming System

Puede definir los editores de idioma personalizadas y otras limitaciones para cualquier nuevo idioma, por lo que el trabajo con esos DSL vuelve muy simple. Los expertos en dominios que no están familiarizados con la programación tradicional pueden trabajar fácilmente en MPS con sus lenguajes específicos de dominio usando terminología específica de dominio.

Fuente

2009-02-16 07:23:55

Soy nuevo, pero OMeta parece una herramienta ideal para desarrollar DSL. No parece haber un IDE a su alrededor, pero la buena noticia es que las "reglas" que uno puede escribir en OMeta son muy legibles. (Y se trata de recursión a la izquierda, que es muy buena).

Actualmente hay implementaciones de OMeta en al menos Javascript (muy emocionante para mí) y Python, tal vez otros. En cuanto a C#, Jeff Moser está trabajando en uno, que se puede leer en his blog y ver más en CodePlex. Buena suerte.

Fuente

2009-02-16 14:57:21 Alan

La herramienta estándar para crear las costuras de DSL es ANTLR - es un potente generador de lexer/analizador con muchos lenguajes de destino para la salida del compilador. Tiene backends para C#, Java, C/C++, Python, etc. (vea la lista code generation targets) y le permite insertar fácilmente código personalizado en su compilador en su idioma de destino.

También hay un muy potente IDE (ANTLRWorks) y gran cantidad de documentación. (Consulte The Defenitive ANTLR Reference de Terrence Parr, el autor de ANTLR) Para referencias sobre quién más lo usa, vea la página Testimonlals.

usted todavía tiene que hacer la mayor parte de la instalación de cañerías para el IDE a sí mismo, pero debería ser mucho más fácil dado el marco compilador robusto que se obtiene de antlr. Este debería ser el caso para la mayoría de las soluciones publicadas aquí ...

Actualmente estoy usando un compilador escrito con ANTLR para preprocesar nuestra propia salida de DSL a C/C++ y estoy muy contento con él. Ya basta de publicidad, deberías probarlo tú mismo :) ¡Diviértete!

Fuente

2009-02-16 16:02:26 VolkA

Ruby es un excelente lenguaje para crear DSL. Por ejemplo, Rake es una DSL de script de compilación escrita con Ruby.

Con la próxima IronRuby es posible escribir scripts que llaman directamente a su código C#.

Here's some articles en la escritura de DSL en Ruby.

Fuente

2009-02-22 14:32:34

Boo + Ometa = Boo.OMeta.Parser

Actualmente el analizador está en desarrollo pero ya se puede utilizar para la creación de DSL externos complejos. OMeta es una poderosa herramienta que permite a los programadores implementar fácilmente analizadores léxicos y analizadores sintácticos. La arquitectura extensible de compilación de compiladores de Boo permite reemplazar Boo.Parser estándar con Boo.OMeta.Parser. Se puede usar para extender la sintaxis de Boo con casi cualquier tipo de sintaxis. El ejemplo se puede encontrar here.

Fuente

2011-05-17 21:15:42

Mi proyecto meta# está tratando de resolver este problema.

Fuente

2011-12-14 14:19:40

¿Qué tecnología usar para crear DSL para el motor de reglas?

Respuesta

Cuestiones relacionadas