Stuart Kent - Software Modeling and Visualization
Here is a great post from Jos Warmer over on the DSL Tools forum.
He makes some good arguments. Please add your own opinions to the discussion. We'll definitely take note as we think about the next set of features...
Those of you who have downloaded the June CTP of DSL Tools will, by now, be aware of quite a few changes. In particular you'll have noticed that we've replaced the old .dd and .dmd formats with a single .dsl format, and provided a (currently unfinished) designer for this format.
Whilst we're waiting for the documentation to catch up, I thought I would spend a few cycles telling you about the new .dsl format, and provide some insights into some of the thinking behind it.
So where to start. Well, it's probably a good idea for you to take a look at a .dsl file. Follow one of the walkthroughs in the documentation that comes with the kit to get hold of an example.
If you open the file in the xml editor, you'll see that it contains definitions for: classes, relationships, types, shapes, connectors, a designer, a diagram, plus sections to define xml serialization and explorer behavior, and a section to define things called connection builders.
Looking a bit deeper, you'll see that a diagram defines shape maps (various kinds) and connector maps, that is, how shapes and connectors map to classes and relationships for that particular style of diagram.
You'll also see that, as well as referencing the diagram to be used, a designer also defines one or more toolbox tabs, with tools on them.
I'm going to focus in this post, and probably a couple after, on one of the key changes we've made, which is to make a clear distinction between how information in the model gets presented on the diagram, and the actions used to create new parts of the model.
In the old dd format, you defined a shape, a class, and a map from class to shape, then a tool that referred to a shape. In the designer that was generated, using the tool caused an instance of the mapped class to be created together with an instance of the shape to view it. This scheme had the advantage of being simple, but the disadvantage of being very inflexible. Without a lot of custom code, you couldn't define (element) tools that did anything other than create an instance of a class embedded in the object mapped to the diagram with a new shape on the diagram viewing it. A restriction of this scheme was that it forced most classes in a domain model to be directly embedded in the root class.
In the new format, the shape and connector mappings only govern how a diagram views the model: what shapes get created to view what model elements, and what connectors get created to view links of what relationships. The tools, in conjunction with merge directives and connection builders, govern how model elements and links get created in a model. An element tool refers to a class. It causes an element of that class to be created and merged into the model via the element mapped to the diagram or shape that the tool is dragged onto. Merge directives on the class of that latter element define the mechanics of the merge. A connection tool refers to a connection builder, which defines how the element mapped to the shape at the source drop point of the tool gets connected in the model to the element mapped to the shape at the target drop point of the tool.
So we now have a definition in the style of the well-known model-view-controller pattern. Tools are the controllers, and are used to add stuff to the model, whose elements are viewed by shapes and connectors on the diagram, as determined by the shape and connector mappings defined for that diagram.
Combined with the use of paths in the definitions of maps, connection builders and merge directives, plus the ability to flag the need for custom code at various key points, we end up with a very rich and flexible system for defining the interaction between the design surface and the model.
In the next post, I'll walk through an example. But for now, I'll point you at a great post by Alan the reveals some of the details of paths, merge directives and connection builders.
Goto http://msdn.microsoft.com/data/ref/linq/ and download the latest CTP of LINQ. There you'll find a designer for DLINQ that's hosted in Visual Studio. Anything look familiar? Wondering what tools were used to build it? If you haven't guessed by now, here'e another hint: http://msdn.microsoft.com/vstudio/DSLTools/
Sam Guckenheimer has started blogging - http://blogs.msdn.com/sam/
Sam is the chief product planner for Visual Studio Team System. He's also just written a book about it.
I haven't written a blog entry for a while, and the reason is that I've been very busy working on the latest CTP of DSL Tools.
I'm pleased to announce that it is now available.
Details on the DSL Tools web page. When you get to the Visual Studio SDK download the page you'll need to scroll down to find the June 2006 CTP.
We look forward to receiving your feedback.
Existing users of DSL Tools, please take note of the Important information about migrating existing designers:
"To migrate a designer produced with an earlier (though no earlier than November 2005) CTP for Domain-Specific Language Tools to work with this June CTP, you must have both the CTP with which the designer was produced and the June CTP installed on your computer. Therefore, if you have an older designer that you want to migrate, you should NOT uninstall the previous CTP before you install the June release of the Visual Studio SDK, which contains the June CTP of Domain-Specific Language Tools. You can migrate designers from older CTPs to the current one if you have the older CTP on one computer and the current CTP on another computer if you can copy files between the two computers."