Channels ▼
RSS

Design

Generative and Transformational Techniques in Software Engineering


The Men from Austin, Texas

I have two interests in transformation systems:

  • To capture complex requirements and move these into code with minimal risk.
  • To find a way to semi-automatically refactor large C++ applications.

I had identified two tutorials, each addressing one of these concerns directly. And by coincidence, both came from Austin, Texas. Don Batory presented his work on Feature-Oriented Programming (FOP), and Ira D. Baxter on DMS system, a commercial transformation and refactoring system.

Batory's work with features is outstanding because it is both broad in scope but applicable to real-life problems. This makes it look very usable, although there's still room for growth. The principal idea is to build a system (of potentially many programs) by mixing features together. He describes a feature as something that adds characteristics; later bringing in a more formal functional framework where features have their algebra, can be encapsulated, and can be composed together. Once all features for a system have been described, optimization transforms them into something usable. He showed how features described in a domain-specific language (DSL) can be mapped to propositional formula (a logic system). System-wide constraints are added as equations and a logic solver or optimizer can then be used to find system implementation that matches the features. This equational approach also allows mismatches in features (for instance, trying to iterate backwards on a list) to be detected by the system as overconstraints. FOP is implemented in the AHEAD system developed by his group.

Baxter presented DMS, a system for practical software maintenance. He reminded us that all software development has a life cycle, and at some point maintenance costs explode. This is where his company saves the day with a powerful transformation system. Different transformations are used for different problems such as migrating to another language, or to another system, restructuring an application, optimizing it, or performing a documentation extraction. The list goes on because the transformations are fully programmable with a lexer, parser, rule-based, and procedural rewrite system, attribute grammar system, and pretty printer. An attribute grammar is what you could use to perform cross-procedure usage or dataflow analysis to understand how one part of your program is affected by another.

One example of DMS's use involved porting 6000 C++ components from a legacy system to CORBA/RT in 15 months. Interestingly, Ira emphasized that the solution process that he proposes is iterative and yet also fits into a waterfall type process: The transformations are run over and over until "they got it right". The twist is that the original source application can continue to evolve until the rewrite team is ready, at which point the transformation is applied and the whole team can migrates to the new source basis. Listening to him, a vision takes shape where source code can be like putty and continuously reshaped by transformation rules. Finally Ira mentioned that other commercial transformation systems (JANUS, Refine5) exist as well.

Hands-on Generative and Transformational Techniques

The use and building of transformation technology were addressed through two tutorials and technical presentations. Tom Mens (University of Mons-Hainaut) talked about graph transformation and Erik Meijer (Microsoft) presented a strong case for focusing on workable solutions.

Model management is typically done interactively, such as with a UML editor. We were lucky to have Tom Mens to talk about graph transformation (GT) in the context of model refactoring. Many models are represented as graphs and GT is all about changing the graph in order to change the model. He introduced the use of GT in the AGG and Fujaba GT tools (I've included a reference to AGG in Table 1). Mens explained how graph theory could be used to show the potential impact of a transformation but also to help identify transformation compatibility and incompatibilities to allow differential change management and collaborative work on models.

Table 1

Staying at a practical level, Erik Meijer focused on workable solutions. Meijer has contributed to the development of Haskell and is a member of Microsoft's Visual Basic team where he tackles "real problems". He presented two such problems--mapping objects to XML-XSD and mapping objects to relational DBs. He presented these in the context of transformations techniques. We learned that:

  • XSD XML schemas have many details and extra care must be taken to interpret them.
  • That to a database person two classes have the same types if they share the same sets of all possible values.
  • To beware of NULLABLE elements in comparisons.

And the list goes on and on. We also learned about Cw, a research language based on C# that integrates database like operations and enumerable types (streams). Later, he showed how much can be built with just a few type transformations such as renaming a field, inlining a type, or merging two types. Finally he ended his tutorial by making the case for giving up the use of languages with only static typing. He argued that dynamic types can be more expressive and solve many problems better. As a long time C++ developer, I will admit that I thought this was heresy but as I write this I admit that I am intrigued.

Table 2

The technical presentation demonstrated both commercial and academic systems. I did not manage to go to all the presentations (they ran in parallel and I was often on the phone with work) so in all fairness I include a reference to each one.

I will add that Mark van den Brand's ASF+SDF tool (Table 1) is the heavyweight reference among academic tools and that I have heard much good of the TXL system. I did see the MetaBorg presentation by Martin Bravenboer and it is extremely impressive, allowing a DSL to be integrated into an existing language framework (such as Java) with full type checking with a minimal amount of definitions.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video