miércoles, julio 20, 2005
sábado, julio 16, 2005
Otros trabajos: Patrones en la reingeniería de código OO, por Oscar Nierstrasz
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.
lunes, julio 11, 2005
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:
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...)
- 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.
- 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.
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.
lunes, julio 04, 2005
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.