Jean-Marc Prieur's Blog : DSL Tools

An Article about DSLs and WPF : “Provide an improved user experience to your DSLs”

jmprieur — Tue, 22 Sep 2009 09:01:55 GMT

Pascal Recchia and Anthony Guérot from Mexedge just published a new article: "Provide an improved user experience to your DSL's" about how to use WPF with your DSLs even in Visual Studio 2008. The technology they use is similar to what we ship in the DSL Tools for Visual Studio 2010.
http://www.netfxfactory.org/blogs/papers/archive/2009/09/20/provide-an-improved-user-experience-to-your-dsls.aspx

The article has been published with 2 videos:
http://www.netfxfactory.org/videos/stepbystep.wmv
http://www.netfxfactory.org/videos/airtraffic.wmv

the code is available from:
http://www.netfxfactory.org/files/airtraffic.zip

And the article is even available in PDF format:
http://www.netfxfactory.org/docs/Provide_an_improved_user_experience_to_your_DSLs.pdf

Very nice!

Copy / Cut / Paste of model elements

jmprieur — Wed, 22 Jul 2009 03:43:09 GMT

Behavior in previous versions of the DSL Tools

In previous versions of the DSL Tools, the copy/cut/paste of model elements did not work very well. There were limitations, and even bugs that prevented very elaborate scenarios. In case you are interested, you can have to the posts on the forum describing these problems, and the pain there was in this area. Some people in the community were successful on some models (See for instance Pascal Recchia and Anthony Guérot’s article on toolbox prototypes, which uses the copy/paste mechanism: http://netfxfactory.org/blogs/papers/archive/2008/06/25/snip-your-dsl-into-prototypes.aspx), but the feature needed reworking and this is what we had done.

New behavior in VS2010

From the VS2010 DSL SDK, the copy/paste as an image is available to all the new designers, and it’s easy to provide the feature for existing migrated designers.

What is the behavior for the DSL user?

The DSL user will be able to copy model elements, compartments items, or anything that the DSL Author thought about, or cut them, and paste them in a compatible shape, in the same, or in different designers. and this in a very natural way.

How does the DSL author control this?

If you create a new graphical designer, you don’t need to do anything, the copy/paste is enabled by default.

If you migrate an existing designer, you can benefit from this new feature very simply:

Having opened the DslDefinition.dsl, go to the DSL Explorer; in the Editor node, you’ll find a new property named “Enable Copy Paste”,
Set “Enable Copy Paste” to CopyPasteOnly (the default is NoGeneratedCopyPaste in case of migrated designers because we did not want to break your designers in case you were successful in implementing the copy/paste already, and CopyPasteOnly for new designers)
On each domain role, determine if you want the “copy closure” to pass trough the role. For this you have a property named “Propagates Copy” that values:
- Do Not Propagate Copy, if you don’t want to “navigate” through the role when copying from the opposite domain class
- Propagate Copy To Link Only, if you want to copy the link, but not the targeted domain class
- Propagates Copy To Link And Opposite Role Player, if you want to copy the link, and the targeted domain class

In new designers, the default is Propagates Copy To Link And Opposite Role Player for embeddings, and Do Not Propagate Copy for the others
Transform All Templates

Example on the DSL class diagram template

More concretely. Let’s take the example of a class diagram unfolded form a Class diagram DSL template. The following screen shot shows a portion of the domain model (Class has attributes), and you can see that being an embedding, by default, Propagates Copy is set for the Attributes role to Propagates Copy To Link And Opposite Role Player.

What this means is each time you copy a ModelClass, you’ll copy its attributes at the same time, which is, really what most people expect.

Now let’s go a bit further, and change the behavior a bit. Let’s assume we have a base class Moveable, and copy the derived class (Plane), and paste it on the diagram. By default, you end up with a new class (Plane1) whose attributes and methods were cloned:

Now let’s assume that, as a DSL author, I want, each time we copy and paste a class (such as Plane), the inheritance, if any, to be copied as well (thus keeping the link with the base class):

To achieve this I need to:

Figure out which role I navigate through when I copy Plane to get the inheritance: this is Superclass.
Change the PropagateCopy property value of the Superclass role to Propagate Copy To Link Only
Transform all templates
Rebuild

Now, when the designer user copies the class “Plane”, he gets a clone, with the inheritance relationship still linking to the same base class … just what I wanted.

Moveable decorators

jmprieur — Thu, 16 Jul 2009 16:15:05 GMT

Behavior in previous versions of the DSL Tools

In previous versions of the DSL Tools, such as, in the DSL Class diagram which is provided as a sample, you could very easily end-up with a very cluttered diagram:

New behavior

With the moveable decorators feature, the DSL author can choose let the decorators on a connector be moveable by the user.

How the DSL author enables the moveable decorators?

In the DslDefinition.dsl file, select the decorators of the connector that you want to let moveable. Note in the picture below that I selected the four decorators of the AssociationConnector
In the Properties window, change the IsMoveable property to True
Transform All templates and rebuild

What is the behavior for the user?

Having letting the decorators on this connector being moveable, the designer’s user will now be able to drag each of them to the position of his/her choice:

If the user selects a decorator, it will be visualized with a segment from the original location to the moved location

If the user selects the connector, all the segments from the connector to the moved position will be displayed:

If the user wants to reset the location of a moved decorator to its original location, there is a contextual command

which let the decorator get it’s original location

Improvements for Beta2

In Beta1, the segments from the connector to the decorators are visible even if the displayed text is empty, which a few customers have found to be is a bit confusing. Therefore, in Beta2 these lines will be invisible if the text is empty, and the empty decorators won’t be selectable.

Sticky toolbox items

jmprieur — Thu, 16 Jul 2009 14:16:36 GMT

Behavior in previous versions of the DSL Tools

In previous versions of the DSL Tools, each time you wanted to create a shape or a connector, you had to:

go to the toolbox, and click on the domain shape / connector that you wanted to create
Come to the design surface to :
- click where to put the shape,
- or to click on a shape and then drag to another shape, or just click a second time on this second shape, to create a relationship
And you needed to do start over to 1. for every shape / connector instance you wanted to create.

Alternatively, and for shapes only, you could double click on the corresponding toolbox item, and such a shape would be added to the design surface to a location chosen by the designer itself. This behavior wa

From version for VS2001 Beta1 of the DSL SDK

From now on, you have the opportunity to choose to enable the sticky toolbox items. If you don’t, you’ll still have the same behaviour as previously.

How a DSL author enables it:

Having opened the DslDefinition.dsl, go to the DSL Explorer; in the Editor node, you’ll find a new property named “Uses Sticky Toolbox Items”,
Set “Uses Sticky Toolbox Items” to true (the default is False)
Transform All Templates

What is the behavior for the DSL user:

Once this behavior is activated, the DSL user will be able to double-click on the items in the toolbox and create as many instances of the shape / connectors as he/she wants.
In order to leave the sticky toolbox mode, just press the ESC key, or click on the “Selection” tool in the toolbox

Note that:

If the sticky toolbox are activated, the user cannot any longer double-click on a shape in the toolbox to create a single shape as is the case when the sticky toolbox are not activated

New sample demonstrating the Domain Model Extensibility

jmprieur — Sat, 27 Jun 2009 02:42:29 GMT

We just published a new sample demonstrating how to extend a DSL after it has shipped.

The sample presents a DSL to explain the architecture of a multi-Tiered application. Each tier is made of components, which have ports. Connections are made between output ports and input ports. What is new is that a Domain Model Extension will add a “Security Extension” thus providing to the toolbox new items (an Audit Log), to a Tier new decorators, to Ports three new Domain properties related to the HTTP security, new validation methods, and new rules. I’m pretty sure you’ll like this sample very much,

To learn more about Domain Model extensibility, please go to http://code.msdn.microsoft.com/DslTools or click on the following direct links:

Domain Model Extensibility -Sample documentation

Domain Model Extensibility -Sample code

Enjoy !

New Beta1 sample available: ImsLocks.

jmprieur — Tue, 23 Jun 2009 10:46:26 GMT

Today we made a new Beta1 sample available on the Code Gallery (http://code.msdn.microsoft.com/DslTools). This sample, named ImsLocks, explains how a DSL author can prevent the DSL user from editing partially or completely his designer. This can be used for instance to provide a read-only reader for a model, or an annotation/review tool. This also browses you through the new Microsoft.VisualStudio.Modeling.Immutability namespace:

It’s important to note that:

In previous versions of the DSL Tools we used to use mainly the Default partition for both the model elements and the presentation elements. This is no longer the case! We now have one partition for the Model elements, and one partition for the presentation elements, thus enabling the finer grain control of the independent locking of presentation as a whole, and model as a whole. This is underlying the IMS Locks DSL Tools feature in Visual Studio 2010
now, before any modification to a Model Element or a Presentation Element, the IMS (In Memory Store) Gets and verifies the Locks permissions of the ModelElement / PresentationElement, of the partition it is located in, and of the Store itself. The DSL Author can implement the ILockingPolicy interface to provide a service to refine these locks.

Check out the documentation and the code to know more about this sample that shows how to make some parts of a model read-only by:

Creating a CustomLockingPolicy class implementing ILockingPolicy and add it to the services of the DocData
Creating a means of updating the Locks
Making use of the locks (to provide useful feedback to the user of the DSL

Enjoy!

A ModelBus sample is now available !

jmprieur — Mon, 01 Jun 2009 22:19:25 GMT

I’m excited to announce you that we just posted a first DSL SDK 2010 Beta1 sample available from http://code.msdn.microsoft.com/DslTools. This sample demonstrates the use of the ModelBus.

the source code is available here StateMachineOverModelBus.zip and its documentation here.

Enjoy !

Announcing the Visual Studio 2010 DSL SDK Beta 1

jmprieur — Fri, 22 May 2009 10:59:09 GMT

After the Visual Studio 2010 SDK announcement yesterday, it’s my turn to be excited to announce the availability, today, of the Visual Studio 2010 DSL SDK Beta1!

A separate download? Why?

Visual Studio 2010 ships with the DSL Tools and T4 runtime in the box in every edition since it is used by other tools in Visual Studio, such as the Linq to SQL designer. The DSL Tools SDK (for the DSL authoring experience) is shipped separately and depends on and exploits features in the Visual Studio SDK. This is the DSL SDK. This is a slight departure from Visual Studio 2008 where DSL Tools authoring shipped inside the VS SDK. Shipping separately gives us more flexibility on when we ship, in particular allows us to make more frequent improvements.

What is new?

In Visual Studio 2010, the F5 experience is improved, and deployment of a DSL considerably simplified, exploiting the extension manager in the Visual Studio platform and the new facilities in the Visual Studio SDK top create a VSIX package which is a simple zip archive that unpacks itself into the User’s extensions folder.
Visual Studio 2010 Beta1 also brings 11 new DSL features:

Different models can now interact with each other, (and with Visual Studio Team System Architecture UML designers), using the ModelBus. A DSL author can choose to generate a ModelBus adapter, that will expose his model to other models or tools.
Databinding support has been added, allowing Windows.Forms and WPF form-based designers to be created by binding a standard winform or WPF-based UI directly to DSL models. This enables developers to quickly create designers such as the .ResX or .settings designers in Visual Studio.
It is now possible to have completely or partially read only models, which can be used for instance by reviewing and commenting tools.
A number of UI enhancements have been added, including :

moveable labels for connectors,
sticky toolbox (when the user double-clicks on an item in the toolbox,it’s not necessary to return to the toolbox for repeated applications of the tool),
quick navigation and editing of compartments with the keyboard
Copy and paste of diagram elements to images (in Bitmap and .wmf/emf)
Copy and paste of model elements in or between diagrams

The notion of DslLibrary has been introduced. This enables factorizing and componentizing DSLs (for instance having several domain models have the same base-domain class). The authoring for this feature will not be present in Beta1
The DSLs can now be extended by third parties after they have deployment. The authoring for this feature will not be present in Beta1

A migration tool is included to help DSL authors migrate there existing DSLs from Visual Studio 2008 and the associated VSSDK. (For more details, see the documentation and a video)

Where can I find Samples and Documentation?

For samples and Beta 1 documentation, visit the following page on Code Gallery: http://code.msdn.microsoft.com/DslTools. There is already the Read Me, and the online What's new. Be also sure to read the information in the download page, to help you getting started. We will progressively post samples there about the new features, so stay tuned, this is where the information will be available!

You will also have more information visiting the blogs of several members off the DSL Tools team:

I wish you to enjoy this Beta1 as much as we enjoyed building it

Another T4 editor, by Tangible Engineering

jmprieur — Thu, 16 Apr 2009 23:48:13 GMT

Until now, I have been using Clarius’s T4 editor. However, Oleg recently wrote a post where he presents an overview of a new T4 editor he has been using:Tangible engineering’s T4 editor. I did not have time to download it, busy as we are preparing the Beta1 of Visual Studio, but this is definitively something I want to do …

[DSL Tools] Reference relationships and compartment shapes

jmprieur — Sat, 30 Aug 2008 07:33:05 GMT

Presentation of the problem:

Deleting behaviour with compartments representing embeddings

Most of the time, in the DSL Tools, you map compartments in compartment shapes to embedding relationships.

And then, deleting a compartment item in the compartment shape indeed removes the model element which was displayed as this compartment item, which makes sense.

Deleting behaviour with compartments representing reference relationships

Now let's suppose you have are mapping a compartment not to an embedding, but to a reference relationship. You might think that deleting a compartment item will only delete the link between the instance represented by the compartment shape and the instance represented by the compartment item. But it turns out that it also deletes the instance represented by the compartment item.

There are scenarios, where you would like first behaviour. This posts explains why it is so, and how to proceed to have only the link deleted, not the target model element.

A case study: what it does, and what we would want

The domain model

we have 2 domain classes ClassA and ClassB, linked thru a Reference relationship (many-many) named ClassAReferencesClassB
ClassB is represented as a geometric shape ClassBShape
ClassB is represented by a compartment shape ClassAShape, which displays the ClassBs referenced by the instance of ClassA through ClassAReferencesClassB
the same ClassAReferencesClassB is also represented by a connector, so that we really see what is happening there.

Figure 1: the domain model (please, click the image to enlarge)

Opening the DSL Details tool window, and clicking on the mapping line between ClassA and ClassAShape, in the Compartment Maps tab, we use the path editor as we usually do and end-up with the following, which really means that in the Bs compartment, we are:

requesting to represent ClassB instances, which we get though the ClassAReferencesClassB relationship navigating though the ClassB role (Displayed elements collection path)
Then we want to display the Name of each ClassB (Display property).

Figure 2: The mapping between ClassA and the compartment shape representing it.

Running our designer - what it does

After transforming all templates, and running the editor, you create a ClassA , a ClassB , and connect them through the connector, in order to get this (the ClassB1 instance also appears in the compartment, since the relationship is mapped both to the compartment and the connector)

Figure 3: Running our designer - starting point

Now, let's try to delete ClassB1 from the compartment (Using the Del key or the contextual Delete command). You end-up with this:

the ClassB1 represented instance was deleted (after all the Delete command was targeting it), removing the link, of course
consequently the ClassB1 shape was deleted

Figure 3: Running our designer - what Delete does on the compartment item

Running our designer - What we would like

That said. You were maybe expecting that, considering you were using a Reference relationship and not an embedding, you would end-up with only deleting the link between ClassA1 and ClassB1 and not the ClassB1 instance. It turns out that this scenario is of interest, but this is not what you requested. You really sent the Delete command to the ClassB1 instance, hence the result.

How to get what we want

In fact, to tell you the truth, I thought myself this behaviour was a bug :-), until Stuart explained me about the command being directed to the ClassBs instances and not to the link. Then, you can very easily achieve our desired behaviour specifying the right things in the DSL Details window on the shape map (and not writing any custom code)

Here is how we should proceed.

Still in the Compartment Maps tab of our mapping between ClassA and ClassAShape, we need to express that we want to deal not with ClassB instances but with a collection of ClassAReferencesClassBlinks form the instance of ClassA represented by the compartment shape to the related ClassB instances.

The Displayed elements collection path should, therefore be ClassAReferencesClassB.ClassB
This can be understood as the same code construct as ClassAReferencesClassB.GetLinksToClassB(ClassA1) which returns collection of ClassAReferencesClassB. This is really an instance of the link that will be presented as a compartment item, and thus, deleting it will delete the link, not the targeted ClassB.
Now, we need to specify what to display (namely the Name property of the ClassB instance accessed through the link). For that, given an instance of ClassAReferencesClassB, we need to get an instance of ClassB (just in order to access its property). We express this in the Path to display property field as ClassAReferencesClassB!ClassB which means getting the ClassB property of the ClassAReferencesClassB instance, that is getting a ClassB instance.
The last step is to provide the Display property, here Name

Figure 4: how to express we want to deal with links

Running our designer - We get what we want

After transforming all templates, and running the designer the first thing is you get exactly the same appearance as before (even if now the compartment items represent links and not model element instances). This is no surprise because we did all we could for that, but it's work noting it

Figure 5: Running our new designer - apparently this is like before

But this, time, deleting the ClassB1 compartment item, we end up with the following expected result:

Figure 6: Running our new designer - the delete command now delete the link, not the targeted shape

Conclusion

In this post, we learnt why, when mapping a compartment to a reference relationship, deleting compartment items deletes the targeted model element with the usual mapping, and how to change the mapping so that it only deletes the link.

To get more information about the path syntax, you can review Overview of Domain Path Syntax . When I started with the DSL tools, I also found this post by Alan very useful.