PDC Day 3 - Domain Specific Languages - the future of Modeling
Bob Muglia's General Session - Windows Server...
I just got out of Bob Muglia's keynote and it was great to see so many cool things happening in the Windows Server product. In particular I was impressed with IIS7 and it's capabilities. They designed an extensibility mechanism in IIS that allows an admin to completely control the modules that are used/loaded for the website as well as capability for a developer to modify the default capabilities of the modules there. What was shown was a different kind of directory listing that actually was a set of thumbnails for the images in the directory listing. Very cool...
Modeling and Visual Studio Team System...
As some of you know we have plans to include the team system modeling technologies API's in the VS SDK. I wanted to attend Jochen Seemann's presentation here at PDC in order to gauge the level of excitement and need for extensibility in order to be certain we provide the best SDK possible. By the size of the crowd (about 1500 people), I'd say that the modeling space is definitely huge and a lot of people are very excited/curious about what we're doing in this space. DSL isn't something to do with broadband or cable-modems. Domain Specific Languages is what we're talking about. Jochen had a quote: "A picture is worth a thousand words...but it's often the case that one doesn't know what the thousand words are." The vision for DSL tools is to instantiate the modeling tools exactly for a custom domain with our tools. We want to give the customer the freedom to express their domain since they are the experts in their domain. The DSL tools are on the web (as of Friday) on the MSDN site at Microsoft.com. You can see some modeling tools today in VS 2005 in the class designer, web service designer and the deployment designer. The DSL tools are designed to provide a toolkit for creating designers for Visual Studio. The DSL tools allow one to use the drawing surface, toolbox, property browser, explorer and validation. The modeling platform includes the following components: In-memory graph database (Domain Model), Drawing Surface (objects (shapes), connectors, auto-layout, routing, all customizable, etc.), Template Engine (for artifact generation), Shell Framework (Visual Studio UI integration - toolbox/menus), Validation Framework (checks constraints and guides user to resolve errors). The roles involved in modeling for software are Architect, Developer and Business Analyst). All of these roles can use MS provided designers, but there are several domains where MS won't provide designers and 3rd parties will provide them. The cool thing is that all of the models based on the platform will be able to work together and link artifacts and designers together.
During the session, Jochen designed a Simple Activity Language. He took 3 steps:
- Define domain model (what do the shapes mean on the drawing surface, properties, states, inheritance relationships and behavior relationships, the meta-model)
- Define the notation (decompose the language to basic units) - describe the shapes and connectors physical properties (text position, icons, colors, etc)
- Define visualizations of the model via the notation elements
This works for really complex models as well as a simple one (like Jochen did on stage). As a side effect of this process you get a real nice specification of the language. To interact with the designer you write code for code/artifact generation, custom serialization, validation/constraints and custom behavior. This code can take advantage of the DSL SDK (that's the thing we want to provide in the VS SDK in the future).
The Toolkit generates a project that is actually a VS Package. It allows the package to launch in the Experimental hive. In the Exp hive we then create diagrams and manipulate the diagram with the design surface according to the model defined in the regular hive. In the demo Jochen then added a property to one of the shapes, rebuilt the model designer and showed again the Exp hive manipulating the designer and see the property he added.
One of the cool things is that the model database is able to be queried via a language and the API generated by the tool for the domain model.
If one can generate a single designer, one can generate multiple designers. What the modeling platform provides is a nice way to make multiple designers work together. A 'software factory' can generate and link these multiple designers. The DSL tools provide a tool window that allows one to create a table consisting of the rows and columns of shapes from two different designer surfaces. The table is then used to add dependencies with a check mark to associate elements from one model to elements from another.
Another cool feature of this toolkit is the linkage with the class diagram and code. With just a couple of clicks one can go from a use case domain shape, to a class object in the class designer to the code.
One of the final thing that Jochen did was to invite a partner (EDS) on stage to show their application which was driven with models during development. The EDS application had a bunch of code generators and stuff from about 4 years ago that generates applications for a 3-tier application using business logic, front end and the database. EDS wrote an add-in that generates a solution based on the models. It uses the API's of the DSL tools and the model. The solution generation add-in creates the front end code, unit tests (including a testing database with random data for testing), database scripts, stored procedures and links everything together using the business logic. The unit tests, by the way, are run by Visual Studio Team System Test.
For the future the DSL toolkit is planned for early 2006. Version 2 will include even tighter VS integration in the next version of VS after VS 2005.
Get more information at https://lab.msdn.microsoft.com/teamsystem/workshop/dsltools
Allen