Lucas Ontivero: Software Factory

Software Factories Blog

Sat, 08 Sep 2007 17:37:34 GMT

[Tanslate this post to english with google]

He creado un nuevo blog dedicado a todo lo referido a software-factories, patrones, metodologías y todo lo que esté orientado a incrementar la calidad, la productividad y el tiempo de entrega de los productos de software. Seguramente también incluiré algunas ideas y/o traducciones de artículos interesante. Ya he pasado algunos post de este blogs al nuevo. Véanlo en http://software-factories.blogspot.com/

Saludos.

Lucas Ontivero

[Software Factories] Introducción (Parte 2)

Mon, 27 Aug 2007 23:31:52 GMT

Ok. Esta es la parte dos de la introducción.

Realmente no quería caer en el mismo ejemplo de libro pero lo voy a hacer. La manera en que hoy desarrollamos software es exactamente igual a como se hacian los automóviles antes de Mr. Ford. Como era esto? Bueno igual que lo que hacemos hoy, venia un cliente y decía: quiero una auto así, así y así con madera de pino de Groenlandia, cuero de jaguareté y pedales de tutú carreta, entonces se diseñaba el auto de cero, a alguno se le ocurria que lo mejor era un rodado de marfil y aluminio de 23,67 pulgadas, etc. Una vez listo el diseño se ponian con los cerruchos, martillos, un tornito y otras herramientas y en 6 o 7 meses estaba listo. Salian mas o menos bien y costaban caro. Hoy en cambio todos los autos comparten un gran número de componentes comunes entre otras cosas gracias a los estandares. Son estos lo que me permiten enchufar mi televisor en cualquier parte del pais y que siga funcionando o cambiar el cuerito de la grifería sin tener que averiguar medidas.

Esta forma de trabajo se caracteriza por:

Uso intensivo de la mano de obra,
Uso de herramientas demasiado genéricas,
Mínimo reuso y,
Procesos genéricos

De esta manera se producen demoras en los tiempos de entrega, defectos, agujeros de seguridad y retrabajos. Además de imposibilitar la introducción de calidad desde el primer momento en cuanto a aquellos detalles diferenciadores como seguridad, usabilidad, desempeño, mantenibilidad y escalabilidad de los productos (sin causar fatigas por falencias en la arquitectura) entre otros.

Antes de continuar analizando los por qué del surgimiento de este paradigma vamos a definir algunos términos que son muy necesarios como por ejemplo el de Software Factory y luego voy a aclarar algunas cosas que me quedaron en el tintero del post anterior.

Definiciones

Software Factory

Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto pero desgraciadamente esta palabrita "Factory" nos habilita a pensar cualquier cosa. Las analogías que encontramos por todos lados con fabricas de zapatos o electrodomésticos terminan de confirmar nuestras fantasias mal fundadas. No son pocos los que creen que se trata de hacer software como si de automoviles se tratara, simplemente ensamblando algunas partes hechas en una linea de montaje y automatizando, robots mediantes, los detalles como el color de la pintura y otros. Bueno, no es así. La figura que adorna este post también confunde pero está muy buena para reflejar el estado actual del arte :)

Distingamos entre Software Factory como paradigma y como instancia. Como paradigma, es una alternativa a los métodos actuales de construcción que intenta resolver los 5 problemas planteados en el post anterior cuando las aplicaciones a construir comparten características comunes. Como instancia (SCSF por ejemplo), un Software Factory es un conjunto de herramientas, procesos tailorizados, frameworks, patrones y modelos (por lo general embebidos en los frameworks y/o herramientas integradas del IDE) y otros contenidos que usan para trabajar sobre una Linea de Productos. O mejor dicho, un SF es una linea de producto que utiliza un SF Template basado en un SF Schema.

Linea de Productos

Una linea de productos se refiere a un tipo de aplicación que puede agruparse o identificarse como perteneciente a una familia de productos como por ejemplo sistemas de CRM, software de seguros, software para entidades bancarias, de control aereo y cualquier otro. Es decir, pueden agruparse de distintas maneras, por segmento de negocios, tipo de soluciones, plataforma, etc. Lo importante es poder identificar aquellas características comunes. Tres aspectos claves de una linea de productos son: los alcances, la variabilidad y la extensibilidad. Los alcances determinan que tipo de soluciones pueden construirse a partir de la linea de productos y define por lo general la arcitectura base para la familia de aplicaciones, la variabilidad hace referencia a las parte comunes definidas en los alcances y aquellas que son variables por medio de configuración de la linea y la extensibilidad determina los puntos en los que es posible añadir funcionalidades.

Software Factory Schema

Un Software Factory Schema es un modelo general que por lo general utiliza grillas, gráficos o cualquier otro artefacto para describir cuales son los productos de trabajo, los pasos a seguir para construirlos, las relaciones existentes entre ellos. Esta es una herramienta para entender y posiblemente automatizar el funcionamiento del SF. Por ejemplo, un SF Schema puede describir los paquetes que se utilizan, la distribución f'isica de los componentes y como los distintos miembros de los equipos se relacionan con cada uno de estos aspectos. Un SF Schema se compone de Viewpoints que no son otra cosa que la descripción de todos los assets que intervienen en la generación de un aspecto del software que se desea desarrollar. Por ejemplo, un view point para la creación de un smart client podría ser la generación de la UI, en este caso el view point especificaría el conjunto de cosas necesarias para realizarlas, desde una clase base Form, diseñadores, DSL para especificar la navegabilidad entre formularios, herramientas de generación de algunos aspectos o plantillas, guias necesarias que intervienen es este punto, etc. Podría decirse que es la colección de todos los puntos de vista de un SF o el plano conceptual de este. Este plano tiene forma de arbol y cada rama trata un aspecto particular de la solución que a su vez se divide en otras ramas que los analizan desde otros puntos de vista. La definición de Viewpoint de la IEEE está en IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

Software Factory Template

Una vez que tenemos los planos conceptuales del Software Factory que queremos construir debemos.... construirlo!! Es decir, ya sabemos que assets necesitaremos, como serán, donde intervendrán, como se relacionarán, etc. Ok, ahora hay que hacerlos. Esto es, crear los frameworks, las guias, los asistentes, los DSLs, procesos y todos los demás asstes descritos en el esquema he integrarlos (en lo posible) al IDE. Cada vez que se construye un nuevo producto, cada desarrollador puede (y debería) contribuir con el SF añadiendo sus plantillas, snippets, instructivos, frameworksy cualquier otro asset. Para más información acerca de estos últimos dos temas les recomiendo la edición número 9 de la revista The Architecture Journal y en especial el artículo de Tom Fuller "Fundamentos para los pilares de las Fábricas de Software".

Lo que me quedó en el tintero

Algo que me quedó en el tintero es el tema de las metodologias cuyo problema resumia como "o (son) muy formales o (son) uy ágiles". Greenfield y Short plantean (lo que a muchos nos parece obvio) que existen dos tendencias extremas con sus pros y contras. A diferencia de lo que uno podría esperar, Greenfield y Short no creen que una metodología más formal sea más MADURA, por el contrario, entienden que son inmaduras por extremistas.

En cuanto a los desarrolladores

Luego vamos a ver como distinguen entre "tipos" de desarrolladores (este "tipos" es mio, en realidad habla del valor de los desarrolladores y distingue entre ellos a aquellos que pueden construir los Software Factories y aquellos que los utilizan) y que importancia tienen estos dentro del proceso de desarrollo. Continuo planteando este tema porque cuantas veces hemos escuchado a gerentes de sistemas/Producers/Produc Manager/Team Leadres decir cosas como "Yo quiero/necesito poder sacar a uno (desarrollador) y poner a otro y que los proyectos continuen en marcha"?. La verdad creo que estas palabras (quiero/necesito) expresan un deseo. Sí, es una expresión de deseo! pero es un deseo genuino y entendible. Yo, en el lugar de esas personas querria exactamente lo mismo pero también entiendo que eso es un intento un poco necio de negar la realidad.

Como por ahí nombro los libros o cito los autores y no quiero poner palabras mias en sus bocas les recomiendo que los lean. Aunque en este punto es coveniente citarlos de manera textual.

"Unfortunately, the industry has a tendency to become overly prescriptive, assuming that developers are naive and uninformed, and attempting to use formal processes to prevent them from making mistakes by telling them what to build, how to build, and what skills are required to perform certain tasks."

El problema mayor que describe esta frase no es sobre lo de "ingenuos" o "ignorantes" sino que producen una infrautilización de las capacidades de las personas. Esto a veces constrasta con lo que se busca en un aspirante para un puesto como desarrollor, que esté muy capacitado, que pueda demostrar logros, que pueda plantear soluciones innovativas, que sea proactivo, etc.

Steve Jobs, fundador de Apple Computer, dice en una frase célebre:

"No tiene sentido contratar a personas inteligentes y después decirles lo que tienen que hacer. Nosotros contratamos a personas inteligentes para que nos digan qué tenemos que hacer."

Por otro lado, las metodologías ágiles no son la solución tampoco porque tienen sus problemas y no son aplicables a todas las realidades o mejor dicho, se aplican a un esquema muy particular de trabajo, gente, clientes, proyectos y demás.

Que solución se plantea? Ahí viene:

Process Framework

La solución planteada no sorprende a nadie. La clave es preservar la agilidad mientras se mantiene la posibilidad de escalar la complejidad introducida por el tamaño y la distribución geográfica de los proyectos. Lo verdaderamente importantes es como esta posibilidad va tomando forma real mediante la implementación del paradigma de Software Factories.

Los autores siguen diciendo que el problema de las metodologias formales es que son demasiado abstractas en el sentido que para poder utilizarse deben ser tailorizadas a cada proyecto o necesidad particular. La idea detrás de esta crítica, que no lo es tal, es tailorizar los procesos a una familia de productos concreta.

Es decir, enfocar los procesos hacia las tareas puntuales de todo el ciclo de vida de una familia de productos (o product line -este concepto es importantísimo y lo explicaré mas aelante). Así, por ejemplo, debería por cada actividad facilitarse los recursos necesarios como wikis, links a documentación importante (pero facilmente accesible y no en un archivo de Word o Excel que sabe dios donde está o que se tarda más en abrirse que en buscarlo por otros medios), información de contactos, guias específicas (instructivos) sobre como realizar tarea, checklists aplicables a la tarea, estilos de codificación, detalles de cual/es es/son el/los próximo/s paso/s en el desarrollo, herramientas, políticas, etc. Todo esto debería estar integrado al IDE y en lo posible automatizado.

Como hecho un tanto anecdótico debo resaltar que Microsoft provée el MSF for CMMI Process Improvement Guidance el cual abarca las prácticas relacionadas a las areas claves cubiertas por CMMI nivel 3.

Los Procces Frameworks se componen de dos conceptos: Constraint-Based Scheduling y Active Guidance.

Constraint-Based Scheduling se refiere a dividir (o abordar) un proceso en mini procesos para la construcción de artefactos o tangibles particulares. Cada uno de estos mini procesos define: los requerimientos para producir la salida, los recursos, los pasos a seguir y las decisiones claves que pueden requerirse en cada momento. Lo de Constraint hace referencia a que entre cada uno de los mini procesos existen precondiciones y postcondiciones que deben matchaer entre ellas y a las restricciones propias del scheduling del proyecto.

Active Guidance se refiere en parte a lo que ya mencioné arriba, que en cada paso de una actividad se brinde la información necesaria para realizarla. Esto debe ser estar facilmente accesible, facilmente entendible y en tiempo real, apoyado en asistentes, plantillas autodescriptivas y que asistan al desarrollador, recomendandole acciones, documentación y ejemplos a la vez que monitorizan el cumplimento de los constraints establecidos.

[Software Factories] Introducción (Parte 1)

Fri, 24 Aug 2007 20:12:01 GMT

Hace un tiempo que estoy estudiando sobre Software Factories, mas precisamente, leyendo los libros: "Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools" de Jack Greenfield y Keith Short y "Practical Software Factories in .NET: From Theory to Practice—A Primer, Reference, and Case Study" de Gunther Lenz y Christoph Wienands. Ademas de leer todo lo que diga "Software Factories" en google.

Según sitan todas las fuentes, y en especial referencia al CHAOS Report, son muy pocos los proyectos de desarrollo de software que se consideran exitosos (alrededor del 30%) mientras que el 50% tuvo problemas de irse del presupuesto, tiempo de entrega y calidad. La porción restante fueron cancelados durante el ciclo de vida del desarrollo. El informe le asigna una minúscula importancia a los aspectos técnicos aislados como causal de los fracasos en la terminación e implementación exitosa de los proyectos aunque es evidente que ellos se deben a la manera en que se construye el software, y esta es una tarea eminentemente técnica. Es decir, si se simplificara dramáticamente la tarea de desarrollo seguramente la calidad, la productividad, los costos y tiempos de entrega se dispararían a niveles mas deseables que los actuales. Y esto es un problema de "como se hace" (Técnica).

Haciendo una comparación entre nuestra industria y otras de diciplinas ingenieriles mas maduras como la mecánica, electrónica y/o civil, Jack Greenfield y Keith Short dicen que fallamos al desarrollar software porque:

Razón 1 - One-off development

Cada proyecto se construye desde CERO e independientemente de otros sistemas similares. Los Assets (no encuentro una palabra mejor pero llamemosles componentes o mejor "tangibles") de estos sistemas no se crearon con el prop'osito de ser reutilizables. Esto encuentra varias razones:

hacer algo reutilizable requiere una IDENTIFICACION y ANALISIS de aquellas características comunes que puedan servir en un futuro cercano.
hacer algo reutilizable requiere que se DISEÑE con ese propósito en mente,
que se CONSTRUYA,
que se VERSIONES y MANTENGA,
que se DOCUMENTE (si no se documenta no es reutilizable por más que se cumpla todo lo anterior)

En otras palabras, hacer un tangible reutilizable es una inversión que hay que analizar.

Una de las formas de reutilización mas común en la actualidad es la dupla copy/paste, que desde mi punto de vista es la peor práctica de todas. Mejores resultados tenemos en la reutilización de componentes en binario o ILs como el Framework .NET, Componentes COM/Activex, los paquetes Java y las .lib en C sin perjuicio de crear nuestros propios binarios para reutilizarlos en esa forma.

Otro problema con la reutilización de fuentes es que el código es mas facil escribirlo que leerlo y eso hace que al leerlo, al no tener la documentación de este (casi nunca la tenemos), al no estar pensado para reutilizarlos facilmente y al no sernos "agradable" la "estética" del código, se nos cruce el pensamiento "Por dios! quien hizo esta porquería!?. Hay que hacerlo de nuevo". Esto es reinventar la rueda. Más allá del hecho de si servía o no, el tema es que habrá dos fuentes con multitud de características similares que bien podrian haberse hecho de una manera mas inteligente.

Razón 2 - Monolithic systems and increasing systems complexity
Los sistemas monolíticos son aquellos en los que sus componentes están fuertemente acoplados y no permiten tratarlos de manera sistemática porque un cambio en una parte produce la necesidad de hacer cambios en muchos de los componentes con los que se relaciona. El problema se observa con mayor claridad al tener que mantener, extender y adaptar el sistema a los cambios en los requerimientos post

implementación. Como contrapartida de los sistemas monolíticos tenemos los sistemas pluggeables.

Razón 2 - Working at low levels of abstraction
Este tema ya lo toqué en otros post sobre Domain Specific Language y NBusiness. Veamos como se desarrolla un software: Nos llegan los requerimientos de nuestro Program Manager/Team Leader y, despues de las reuniones de rutina, en que nos comentan hasta como se peina el cliente, empezamos con un pequeño brainstorn personal o con algún grosso amigo (hoy en dia esto lo hacemos casi desde CERO).

Cuando tenemoslas ideas y los documentos y llega la hora de hecharle mano al código (en este caso ejemplifico con c# pero podría ser cualquier lenguaje: VB, Java, SQL, XSLT, etc) comenzamos así:

using System.IO;
:
:

public class Product
{
    private string productName;
    public string Name
    { get {...} set {...} }

La pregunta es: puede ser esta la manera más natural de especificar el comportamiento y las cualidades de un componente de catálogo de productos? No estaremos hilando demasiado fino? Es más, me atrevo a preguntar: no debería estar hecho ya por alguien más o es que acaso nadie nunca escribió un producto que trabajase con productos?. Está bien, acepto que para algo así falta mucho, que habria que estandarizar bloques de construcción y un montón de cosas más pero la pregunta inicial sigue en pie. Son los lenguajes de propósito general los adecuados para todos los casos particulares? Claro que no. Aquí es donde entran, entre otras cosas, los DSLs o Lenguajes específicos de un dominio.

Aclaro, como desarrollador siempre pienso en función de lenguajes de programación pero bien podrían ser lenguajes de empaquetado, de testings, de validación, de especificación de requerimientos o cualquier otro.

Como alternativa a este bajo nivel de abstracción se analizan una variedad inmensa de cosas, entre las que ya las DSL, como Model Driver development (MDD) y Model Driver Architectural (MDA). Todos con mayor o menor grado de relación con UML y su posibilidad, gracias a XML o mas precisamente XMI, de automatizar una gran cantidad de tareas de desarrollo como así también elevar el nivel de abstracción.

Este es sin dudas el tema mas interesante si se lo estudia en forma aisladas y es el que mas material tiene escrito (tanto que te cansa).

Razón 3 - Process immaturity
Alguién podrá pensar: "ah no!, ese problema nosotros no lo tenemos. Tenemos CMMI! jajaja". Bueno, la verdad es que esto es para vos también y se resume así: o demasiado formal o demasiado agil.

Veamos por qué:

Los mas agiles:
Ventajas:

responden bien ante los cambios
comunicación en lugar de documentación
desarrollo y corrida en iteraciones pequeñas
los requerimientos se validan continuamente gracias a una comunicación constante con el cliente
continuamente se hace refactorin de las aplicaciones

Fallan:

imposible de escalar a grandes proyectos o muy complejos.
escaza documentación de la arquitectura crean problemas de soporte e integración
equipos distribuidos

Los mas formales:
ventajas:

tienen perfectamente establecidos los roles, artefactos y actividades activities
hacen énfasis en los requerimientos, análisis y diseño
la arquitectura se documenta con modelos

Fallan:

Responden lento a los cambios
perfectamente escalables a grandes proyectos o proyectos complejos

Existen muchas discuciones en torno a este tema. Cual es mejor?. La verdad es que en la práctica, esta elección muchas veces no es posible. Hay muchos aspectos a tener en cuenta además de los arriba mencionados que entran en juego y que condicionan una libre elección de la metodología. Por ejemplo: Si tengo grupos pequeños de gente muy capacitada (que no se me van a ir el mes que viene), expertos en temas puntuales, con experiencia, trabajando juntos, con clientes que confian en nosotros a los cuales podemos llamar o ver en cualquier momento, con proyectos relativamente pequeños; bueno, agil es la respuesta. Ahora, si tenemos clientes con distintos usos horarios, idiomas, o nuestro cliente es un gobierno extranjero, que no nos conoce, que quiere mas que una estimación un presupuesto ajustado, que puede hacernos una auditoría, si cotizamos en bolsa, si tenemos proyectos muy grandes, con mucha gente (que se nos va el mes que viene), o somos una pyme de una provincia del interior de un remoto pais que no conoce nadie llamado Argentina y queremos salir a vender nuestros productos por el mundo: bueno, no queda otra, entrá a http://www.sei.cmu.edu/.

Razón 4 - Rapidly growing demand for software systems
No solo que se incrementó la demanda de software sino que además va creciendo el tamaño y la complejidad del mismo. Los clientes de hoy solicitan funcionalidades o características que hace 2 o 3 años atras ni se les hubiera cruzado por la cabeza. Así que no piensen solo estriban siguiendo la metodología HP (Horse Programming)

Bueno, esto ya está mas largo que un post de Diegum prometo seguir con este tema en próximos post.

Lucas Ontivero

Software Factories y Entity Oriented Languages - solo un DSL

Wed, 25 Apr 2007 03:07:27 GMT

Sin duda, no es posible seguir construyendo software como lo venimos haciendo hasta ahora, reescribiendo bloques de código enteros, con un nivel de abstracción bajísimo y todavia muy lejos del lenguaje natural, tiempos largos, costos altos; lo que resumiendo es calidad pobre . Por eso es que me sumo al pensamiento de quienes aseguran que el Software Factory es el nuevo paradigma a abrazar.

Ahora, sin bien en cuanto a las tareas operativas de desarrollo, un software factory se compone de patrones, frameworks, herramientas y modelos, este tiene un componente distintivo que es la generación automática de mucho, realmente mucho código y en este punto entran los DSL (Domain Specific Language), lenguajes especialmente diseñados para un propósito muy particular como SQL, HTML, UML, COBOL y otros (por favor no piensen en DSL Tools).

La mayoria de los lenguajes que se crearon se diseñaron con un propósito, atacar un conjunto de problemas o facilitar la resolución de situaciones que llevan a la realización de tareas recurrente. Así por ejemplo basta con ver los nombres de algunos de los lenguajes mas renombrados para entender su intención original:

Fortran	Formula Translating
Cobol	COmmon Business-Oriented Language
Basic	Beginner's All-purpose Symbolic Instruction Code
DBase	el nombre es muy sugerente y wikipedia dice: "database management system" (y pensar que me la hacia chala)
Perl	Practical Extraction and Report Language
SQL	Structured Query Language
Prolog	Programation et Logique (yo tampoco sabia que era frances)

De repente hoy existen un gran número de lenguajes de propósito general con frameworks, paquetes, componentes, librerias para todo lo imaginable pero con un poder expresivo que no se compara con el de un lenguaje de propósito particular. Por ejemplo, en DBase III+, Clipper y Fox Pro podemos hacer cosas como esta:

USE CLIENTES
DISPLAY FOR CODIGO > "50000" TO PRINT
(imprimir el listado de todos los clientes cuyo campo codigo es mayor a 50.000)

El problema (y la ventaja) con los lenguajes de propósito general es que nos llevan a trabajar a un nivel de detalle que muchas veces es innecesario, al escribir una clase creamos un campo y debemos decidir si es int, float o double y luego crear la propiedad que la inmensa mayoria de las veces es un simple recibir y devolver el valor crudo del campo, innecesario!. Al pensar en una factura, todo el mundo piensa en un papel, en un impuesto, en la afip mientras que los informáticos pensamos en una cabecera y un conjunto (colección, array, etc) de items con productos, un cliente, y un mapeo a la DB. Estamos acostumbrados a pensar en términos de las herramientas que utilizamos!

Como deberíamos codificar una factura? se me ocurre que de una manera algo mágica considerando "el estado actual del arte" podriamos declararla así:

entity factura
{
     tipo   options ('A' | 'B' | 'C');
     fecha date default systemdate;
     total  numeric calculated sum(item.total);
     descuento numeric range 0, 100;
     cliente ref(cliente);
     component item construction
     {
            cantidad numeric default 1 validate > 0;
            precioUnitario numeric validate >= 0;
            total numeric calculated precioUnitario*cantidad;
            producto ref(producto);
     }
}

No hace falta aclarar que este código es solo un pseudo-código, no obstante puede apreciarse el poder expresivo del lenguaje. Este es un lenguaje orientado a entidades o simplemente un DSL para el desarrollo de entidades de negocio.

El único documento que encontré con Google sobre este tema es el "Entity-Oriented Parsing" de Philip J. Hayes del Computer Science Department, Carnegie.Mellon Llniversity. Aunque concretado en un producto real puede probarse el lenguaje e# del proyecto NBusiness, este permite programar la capa de negocios o de entidad con un nivel de abstracción como el del ejemplo de arriba con no pocas facilidades mas. Además de generar todo el código, se integra a VS (para que programemos con este) y genera un assembly para utilizar el binario (creo que la reutilización del código binario es la mejor opción). Permite crear plantillas, tiene un framework y produce una salida muy buena.

Como conclusión, entiendo que es necesario elevar el nivel de abstracción en el desarrollo de software creando (y utilizando) lenguajes especializados en un dominio del problema.

NBusiness - Contribución al E# language

Tue, 24 Apr 2007 22:45:51 GMT

Hoy entré a ver las novedades sobre NBusiness, un proyecto que me gusta bastante porque entiendo que puede llegar a ser muy bueno, y encuentro que han publicado y puesto a disposición de toda la comunidad la gramática del lenguaje e# que les envié hace ya algún tiempo. Realmente me gustó mucho el gesto y el "Thanks Lucas Ontivero!".

Posteo la gramática abajo. Está hecha para Gold Parser que es un generador de parser para muchos lenguajes entre ellos c#, java, Pascal, Delphi, C, C++ y otros. Permite exportar gramáticas a Yacc (o Bison) y es extremadamente grosso, muy recomendable para quienes tengan que hacer un parser.

! -----------------------------------------------------------------------
! E# Grammar
! -----------------------------------------------------------------------

"Name"      = 'ESharp'
"Author"    = 'Lucas Ontivero'
"Version"   = '.NET'
"About"     = ''
"Case Sensitive" = false
"Start Symbol" = <Program>

! ----------------------------------------------------------------- Sets

{ID Head}   = {Letter} + [_]
{ID Tail}   = {AlphaNumeric} + [_@]
{String Ch} = {Printable} - ["]
{Char Ch}   = {Printable} - ['']
! ----------------------------------------------------------------- Terminals

Identifier = {ID Head} {ID Tail}*

DecLiteral = {Digit}+
RealLiteral = {Digit}* '.' {Digit}+ ( 'E' [+-]? {Digit}+ )?
| {Digit}+ 'E' [+-]? {Digit}+

StringLiteral = '"'( {String Ch} | '\'{Printable} )* '"'

! ----------------------------------------------------------------- Terminals
<Qualified ID> ::= <Qualified ID> '.' Identifier
| Identifier

! ----------------------------------------------------------------- Rules

<Family> ::= family <Qualified ID> '{' <Family Items> '}'

<Template> ::= template Identifier as <Qualified ID> in <Qualified ID> ';'

<Entity> ::= entity Identifier <Entity Opts> <List Entities Opts> '{' <Entity Items> '}'

<Entity Opts> ::= as Identifier
|

<List Entities Opts> ::= ',' <List ID>
|

<List ID> ::= Identifier ',' <List ID>
| Identifier

<Entity Item> ::= <Statement> ';'

<Statement>   ::= <Field>
              | <Relationship>
              | <Validate>
              | <Access>
              | <Authorize>
              | <Action>

<Field>       ::= field <Field Modifiers> <Type> Identifier <Array Dim Opt>

<Relationship>::= relationship Identifier with Identifier <Constraints> as <RelationshipType>

<Validate>    ::= validate Identifier <ValidateRule>
<Action>      ::= action Identifier <Action Item>
<Authorize>   ::= authorize <RuleType> <RuleRol> <AuthorizeAction>

<Access> ::= access <RuleType> <RuleRol> <AccessAction> Identifier

<RuleType> ::= deny
| allow

<RuleRol>     ::= '*'
              | '?'
              | Identifier
              | StringLiteral

<AccessAction>::= set
| get

<AuthorizeAction> ::= create
              | update
              | delete
              | retrieve

<NumericValue>::= DecLiteral
| RealLiteral

<Field Modifiers> ::= nullable
              | readonly
              | auto id
              | id
              |

<RelationshipType> ::= parent
| child
| sibling

<Constraints> ::= on <List Constraint>
|

<Async opt> ::= async
|

<Array Dim Opt> ::= '[' DecLiteral ']'
|