Ensō Introduction

I know that this is just a teaser, but it is the introduction of the paper on Ensō that Tijs and I are writing. If you want to know more or see the code, let me know.

Ensō is a theoretically sound and practical reformulation of the concepts of model-driven software development. Ensō is based on first-class structural descriptions, invertable transformations, generic operations and interpretation.

Structures in Ensō are a specialized kind of graph, whose nodes are either primitive data or collections of observable properties, whose values are either nodes or collections of nodes. From a programming language viewpoint this may seem an odd choice for data representation. However, it is essentially the Entity-Relationship (ER) model, also known as Information Models, which is widely used in the design of relational databases and is also the basis for Class Diagrams in the Unified Modeling Language (UML), which describe the structure of networks of objects. The key point is that structures in Ensō are viewed holistically as graphs, not as individual values or traditional sums-and-products data structures.

A structural description, or schema, specifies some of the observable properties of structures. Schemas are used to check the consistency structures. Some properties can be checked while the structure is being created, but other can only be checked once the structure is complete. Ensō allows modification of structures, which is necessary to create cyclic graphs, but also allows valid structures to be sealed to prevent further changes.

Invertible transformations are used to map one structure into another kind of structure, such that mapping can be inverted to (partially) recover the original structure from the result. One common kind of transformation is called a grammar, which is an invertible transformation between structures and text. Text grammars are invertable because they can be used for parsing and also rendering. Other transformations include Diagram grammars, which map structures into diagrams, were edits on the diagram are reflected in the original structure. Grammars that describe the structure and behavior of user interfaces are used to generate very natural applications. Transformations are also used for querying, template processing, and serialization.

Operations can be guided by schemas or grammars, allowing highly generic operations to be defined for comparison, differencing, merging, projecting and otherwise manipulating cyclic structures. These operations are cyclic maps, which correspond to coinductive transformations. Since schemas and transformations are also structures, they can be merged and transformed using these same generic operations. Transformations on schemas can be applied to instances, to support upgrade and change management of data. The resulting system supports powerful modularity constructs, including feature modules, inheritance, and mixins.

Ensō is based on interpretation rather than code generation. While it is possible to define transformations that generate code in conventional languages, this is rarely (if ever) done in Ensō. Instead all structural descriptions and transformations are interpreted dynamically. Although the current incarnation of Ensō does not include it, we have previously demonstrated that partial evaluation can be applied to Ensō-style interpreters to automatically generate efficient code.

Comments (4)

  1. Sven Apel wrote::

    Dear William,

    your work on Enso is very interesting! It is remarkable that there is a substantial overlap with recent ideas of feature-oriented software development (FOSD) — not only the fact that modularity of features is important, but deeper connections to the FOSD model. I know that you are aware of this connection, but other readers may be interested:

    – Forests are the key data structure in a formal model of FOSD [1]. The goal is similar to yours: be language-independent and represent object collaborations.

    – Recently, forests have been extended to graphs to encode more semantics and to support more automatic reasoning activities [2].

    – Operations on forests (e.g., composition or conflict detection) are defined generically and can be plugged in on demand [3].

    – The entire FOSD model is language-independent and has been used with many different artifact types (e.g., Java, C, Haskell, Alloy programs) [3].

    – FOSD tools (the internal parsers and reasoning tools) are generated based on annotated grammars, whose annotations supply semantic information [3].

    – The entire forest/grammar/annotation-based model has been enriched by adding behavior to features [4].

    It would be very interesting to learn how your programming model relates to these recent FOSD ideas or what different goals you have, also what connection you see to Smalltalk.

    [1] Sven Apel, Christian Lengauer, Bernhard Möller, and Christian Kästner. An Algebraic Foundation for Automatic Feature-Based Program Synthesis. Science of Computer Programming (SCP), 75(11):1022–1047, November 2010.

    [2] Sven Apel, Wolfgang Scholz, Christian Lengauer, and Christian Kästner. Language-Independent Reference Checking in Software Product Lines. In Proceedings of the International Workshop on Feature-Oriented Software Development (FOSD), pages 65–71. ACM Press, October 2010.

    [3] Sven Apel, Christian Kästner, and Christian Lengauer. FeatureHouse: Language-Independent, Automated Software Composition. In Proceedings of the ACM/IEEE International Conference on Software Engineering (ICSE), pages 221–231. IEEE Computer Society, May 2009.

    [4] P. Höfner, R. Khedri, B. Möller. Supplementing Product Families with Behaviour. International Journal of Software and Informatics, 2011. To appear.

    Best

    Sven

    Friday, May 6, 2011 at 2:20 am #
  2. admin wrote::

    Hi Sven,

    I don’t think its very remarkable that there are connections, given that you and Don Batory and I have been working together and talking about these ideas for the last five years. Ensō is related to a lot of different ideas, but there are particularly close relationships relative to our approach to feature modularity. Thank you for the references.

    William

    Friday, May 6, 2011 at 2:59 am #
  3. [I just had to post this example of blog spam -Enso]
    That is a super-peachy-keen post. Thanks for really blathering on like that! Seriously, I don’t think I could have spent more effort wishing for something heavy to fall on me to erase that nonsense from my mind!

    Monday, May 30, 2011 at 12:16 am #
  4. Andreas wrote::

    Hello (William?),

    the ideas described in the third and fourth paragraph of the blog post are sounding like a description of the Eclipse Modeling Framework (EMF) or more specific: Ecore. Maybe that’s naturally, cause EMF/Ecore is also located in the world of Model Driven Software Development …
    I’m excited to see a first public available version of Enso!

    Best regards,
    Andreas Semt

    Sunday, July 24, 2011 at 11:49 am #
Get plugin http://www.fastemailsender.com