Remembering the Future

For these reasons, we elected to define the Service Connectivity DSL using a purpose-built metamodel, itself defined as a member of a family of related metamodels. This gives us a natural and precise foundation for service connectivity, and gives us a high-fidelity mapping to the underlying implementation artifacts which includes, of course, some amount of code. This is the same conclusion we have reached on other focused development tasks, and led to similar DSLs for the Class Designer and the Logical Data Center Designer described in other postings. Support for extensible DSLs, built as a family, with well-defined mappings between them and other development artifacts has thus become the basis of Microsoft’s model driven development strategy.

 

To summarize, we’d recommend using UML and UML-based tools for

• Sketching,
• White boarding,
• Napkins,
• Documentation,
• Conceptual drawings that do not directly relate to code.

We’d recommend precisely defined DSLs and DSL-based tools for

• Precise abstractions from which code is generated
• Precise abstractions that map to variabilities in frameworks and components
• Precise mappings between DSLs
• Conceptual drawings that have precisely specifiable mappings to other DSLs or to code artifacts.

We’d recommend neither of the above for visual programming of detailed program logic (or at least for many years yet), despite Grady Booch’s optimism about executable UML expressed in an interview for the British Computer Society Bulletin that can be found here.

 

posted on Friday, April 16, 2004 3:44 PM