Cuál es el marco de trabajo de las DSL Tools en VS 2005?

GarethJ (J. Gareth?) mantiene referencias vivas a preguntas y respuestas de soporte en el uso de Visual Studio 2005 (y otros, supongo). Un grupo de ellas se refieren al uso del toolbox de DSL dentro del VS 2005. No quiero desconocer que cualquier esfuerzo de construcción de software es trabajoso, y se puede decir con seguridad que no existen las herramientas automáticas que reemplacen el trabajo de análisis e interpretación de los desarrolladores. Pero intuyo en el intercambio de preguntas y respuestas que este conjunto está distante de los principios que dicen sustentarlo. Evidentemente un IDE hubiera sido una respuesta de automatización en la época en que Bob Bemer explicó sus ideas de una Fábrica de Software, pero, aunque el proyecto esté instalado, parece que todavía estamos en la versión o.1.

Materiales de JavaOne 2005 disponibles

Si le interesa Java, J2EE, o la interoperabilidad entre Java y .NET, puede consultar los papeles técnicos de la conferencia 2005 de la comunidad JavaOne, soportada por Sun. Debo dar gracias al blog de Juanjo Navarro, de donde tomé el enlace (Juanjo en el enlace del título de esta nota).

EAI-ERP: Parte de situación

El 13 de julio, IStart publica un breve artículo acerca de la evolución de las Aplicaciones de misión crítica en el mundo: "la consolidación continuará".

Bernd Fisher: Generación de código certificable

En el contexto de la 4ta conferencia de Ingeniería de Componentes y Programación Generativa, (Generative Programming and Component Engineering [GPCE'05]), varios temas de mucho interés, y entre ellos, el propuesto por Bernd Fisher: Generación de código certificable. Así se presenta el tema en la informaión previa:

ABSTRACT Code generators based on template expansion techniques are easier to build than purely deductive systems but do not guarantee the same level of assurance: instead of providing correctness-by-construction, the correctness of the generated code depends on the correctness of the generator itself. We present an alternative assurance approach, in which the generator is extended to enable Hoare-style safety proofs for each individual generated program. The proofs ensure that the generated code does not go wrong, i.e., does not violate certain conditions during its execution.

The crucial step in this approach is to extend the generator in such way that it produces all required annotations (i.e., pre-/postconditions and loop invariants) without compromising the assurance provided by the subsequent verification phase. This is achieved by embedding annotation templates into the code templates, which are then instantiated in parallel by the generator. This is feasible because the structure of the generated code and the possible safety properties are known when the generator is developed. It does not compromise the provided assurance because the annotations only serve as auxiliary lemmas and errors in the annotation templates ultimately lead to unprovable safety obligations.

We have implemented this approach and integrated it into the AutoBayes and AutoFilter program generators. We have then used it to fully automatically prove that code generated by the two systems satisfies both language-specific properties such as array-bounds safety or proper variable initialization-before-use and domain-specific properties such as vector normalization, matrix symmetry, or correct sensor input usage.

Otros trabajos: Patrones en la reingeniería de código OO, por Oscar Nierstrasz

Cuál es el alcance real de los lenguajes de dominio (DSL)?

Vinculado al tema de Software Factories, tratado antes está el papel que se le asigne a los lenguajes de dominio (Domain Specific Languages). Entrar más en detalle en ellos es útil para valorar el alcance real de su importancia en la formula SF, así como su viabilidad de articulación con una herramienta de diseño conducido por modelos. Martin Fowler ha venido publicando varios artículos sobre DSLs relacionados a MDA y SF que abren interesantes vías de análisis:
Languages Workbenches: the killer-app for Domain Specific Languages?
Languages Workbenches and Model Driven Architecture
Entre ellos, una referencia a LABRI (Laboratoire Bordelais de Recherche en Informatique) ofrece una visión general del tema, e introduce en las características distintivas de los lenguajes, y da una lista de casos.
Un aspecto fundamental discutido es la factibilidad de construír un DSL, y quién está en condiciones de hacerlo. Cito:

(...) However, they also raise a key issue which, if not addressed, could obstruct the use of DSLs (...): how does one design and implement a DSL? Resolving this issue is critical to make the approach profitable since there is no point in reducing the complexity of program development by shifting all the complexity into the construction and maintenance of a DSL programming environment. Another related question is: who will develop DSLs? Even in the programming language community, only a few people have actually designed a language. A fortiori, we cannot expect software engineers to have the full expertise to build up new languages. Thus, it is crucial that a methodology and tools are provided to make the DSL approach widely accessible.

El laboratorio desarrolló una solución (un framework) llamada SPRINT. Ver el método que crearon para construír un Lenguaje de Dominio, da una idea de su real capacidad de ser una herramienta genérica para colaborar en el proceso de armado de un sistema (Específicamente, quiero saber cómo es de posible crear un DSL para un proyecto específico, con un problema específico, como dice la presentación de Microsoft (Think of a DSL as a small, highly focused language for solving some clearly identifiable problem that an analyst, architect, developer, tester, or system administrator must wrestle with. Developers are already familiar with examples of DSLs; SQL for data manipulation, XSD for XML document structure definition, and so on. Another example from Visual Studio Team Edition for Software Architects is a DSL for modeling the logical structure of datacenter hardware and host software configurations. This DSL and its related graphical designer can be used to validate during design time that applications are configured to match their intended deployment targets, alerting the developer to problems when they can be fixed more cheaply.Good ways to find candidate DSLs are to identify the patterns used by developers, and then to encapsulate them into a modeling language, or to surface the concepts in a software framework as abstractions in a modeling language that can then generate small amounts of code that extend the framework. These techniques allow us to control the amount and complexity of generated code, offering real value to the developers, without the hassles that characterized CASE products.)

Sigue la descripción del marco metodológico a seguir para especificar un DSL según Sprint:

Our methodology is based on a framework outlined in an earlier paper by Thibault and Consel and put into practice in several DSL prototypes (GAL, PLAN-P) and publications . It can be summarized as follows. (For the sake of clarity, the phases of our methodology are presented sequentially. In practice, the whole process needs to be iterated.)

Estos son los pasos a seguir:

Language analysis

Assuming a problem family has been identified, the first step is to analyze the commonalities and the variations in the corresponding program family. This analysis is fueled by domain knowledge. The result of this analysis includes a description of objects and operations that are needed to express solutions to the family of problems, as well as language requirements (e.g., analyzability) and elements of design (e.g., notations).

Interface definitions

The next phase is to refine the design elements of the DSL. To do so, the syntax of the DSL is defined and its informal semantics is developed. The informal semantics relates the syntactic constructs to the objects and operations (i.e., the building blocks) identified previously. Additionally, the domain of objects and the type of operations are formalized, thus forming the signature of semantic algebras.

Staged semantics

The semantics of a GPL is typically split between the compile-time and the run-time actions. These two parts are also referred to as the static and the dynamic semantics of a language. We propose to perform the same separation in the semantics of a DSL. With respect to software architecture concerns, this separation makes stages of configuration explicit.

Formal definition

Once the static and dynamic components of the language have been determined, the DSL is formally defined. Valuation functions define the semantics of the syntactic constructs. They specify how the operations of the semantic algebras (i.e., the building blocks) are combined.

Abstract machine

Then, the dynamic semantic algebras are grouped to form a dedicated abstract machine which models the dynamic semantics of the DSL. From the denotational semantics, the DSL is given an interpretation in terms of this abstract machine. The state of the semantics is globalized and mapped into abstract machine entities (e.g., registers) dedicated to the program family.

Implementation

The abstract machine is then given an implementation (typically, a library), or possibly many, to account for different operational contexts. The valuation function can be implemented as an interpreter based on an abstract machine implementation, or as a compiler to abstract machine instructions.

Partial evaluation

While interpreting is more flexible, compiling is more efficient. To get the best of both worlds, we use a program transformation technique, namely, partial evaluation, to automatically transform a DSL program into a compiled program, given only an interpreter. Writing the language definition as an interpreter allows fast prototyping, and easier maintenance and extension. However, it does not compromise efficiency as partial evaluation is able to remove the interpretation layer overhead, yielding efficient DSL implementations.

Como se ve, construír un DSL, aun con el auxilio de una herramienta que encauce metodológicamente y abrevie pasos, no es una tarea trivial. Sin hablar de que existe un paso previo metodológico no cubierto (Assuming a problem family has been identified...)
Ni cuestiono los DSLs, ni mucho menos el desarrollo de esta herramienta, para aumentar el campo cubierto por DSLs específicos. Sólo pongo en duda con fuerza la posibilidad de que una colección de DSLs sea la alternativa a un modelo de herramienta del tipo MDA.
En forma desnuda, las afirmaciones de Greenfield y Microsoft no son sino una promesa o una especulación comercial, y la cruda verdad es que estamos hablando del Visual Studio usando C# u otro lenguaje .NET, para hacer interfaz con aquellos DSL que existan, cuando el problema se presente,...y el resto es C#, es decir, lo mismo.

El duro trabajo de salir del enfoque procedural

Me inicié en la programación aprendiendo de profesores y mentores que a su vez se iniciaron desde el Assembler y el Fortran hasta el Cobol. Como he reconocido, mi primer contacto con Yourdon fue cuando la programación y el diseño estructurado eran la forma correcta de hacer las cosas. Por lo tanto, a diferencia de los nuevos programadores o analistas o diseñadores, siempre tengo que pensar dos veces un problema: primero la vía "natural" procedural, y luego como mundo de objetos. Andando el tiempo, sin embargo, encuentro que en el mundo diario, es mucho más frecuente encontrar el modo de enfocar un problema orientado a los procesos, que el modo basado en objetos. Dos o tres discusiones en comp.object, el grupo Google que me resulte de mayor interés, me muestran sin embargo que los tropiezos no son sólo míos. En el link que titula esta nota se menciona a uno de estos casos, donde Lahman reenfoca desde el punto de vista de objetos un algoritmo presentado como secuencia de procesos.
Pero el más interesante y valioso de los varios casos sobre lo mismo es el llamado "OOP/OOD Philosopy". Invito a seguir la discusión y poner a prueba sus criterios.