Embarrassing, but true. Last time I blogged was back in February.
I’m on one of my regular trips to Redmond, and jet lag still means I’m getting up at 4am. Usually on these trips I use the early morning to do a bit of work, then go for a run. However, last trip I stumbled on a tree root when out running and fractured my ankle. It’s the first time I’ve broken a bone, so I didn’t know what to expect. In fact, at first I didn’t really believe the doctor; x-ray looked fine to me. Little did I expect that I’d be back in Redmond 7 weeks later, still limping and definitely unable to run. So I find myself with more time in the morning, and an opportunity to contribute once again to the blogsphere, though any readership I may have had has probably already given up on me.
So what’s there to talk about. As the title suggests, I thought I would touch on the subject of UML and DSLs given a recent post on UML + DSL from Cameron Skinner, who now leads Visual Studio Team Architect. In the article, Cameron talks about a new set of designers that Team Architect are working on, which includes some UML designers, as well as some graphical DSLs. The goal is to ‘make modeling more central to a broader range of people’ as well as to ‘seamlessly connect the two approaches [UML and DSL]’. We’ve found that DSL Tools is very appealing to customers who’ve already bought into modeling. It allows them to create their own customized model driven solutions fairly quickly. However, for those not already into modeling it’s a harder sell (although, we have had customers who have seen what others have produced and decide to build something similar which focuses on their domain). To really get modeling out to a broader audience it’s necessary to have tools that people can use straight out of the box. I’m still convinced that if you want to dramatically increase productivity then you should be using DSLs driving code generators, or further model transformations, or visualizing abstractions discovered from existing artifacts, or some combination of all three. On the other hand, whatever your views are about the effectiveness or not of UML, it has significantly raised the awareness of modeling with a broad audience and it is something that many people are familiar with. So I’m really pleased that Team Architect has now stepped up to drive a strategy that delivers on both sides of the modeling coin, and connects them up.
What is more, I’m really enjoying helping them deliver on this strategy by providing a great platform to build on. Because, as Cameron points out, many of the designers being built by Team Architect (including the UML ones) are being built on the DSL Tools platform. Not only is this further proof for the robustness and flexibility of this platform, it is also helping to drive new features into the platform which will benefit anyone wanting to build their own DSLs. We’re not ready to talk about those features in detail yet, but my list posted a few months ago is still fairly accurate, although there are a couple of additions and some changes in priority. Worth calling out are the features to allow a designer to be extended with new metadata once it has been deployed, and support for designers and models to interact. This will allow the designers delivered by Team Architect to be extended, and for new, third party DSLs to interact with them. Both these are key aspects of connecting UML with DSLs in the UML + DSL story that Cameron speaks about.
Finally, you may also have noticed that Steve is changing his role, by going back to Team Architect in order to help them deliver on the UML + DSL vision. This means that Steve will be more of a consumer of the platform that he helped create, and I’m sure will be driving hard to ensure that it meets his needs. Steve and I still share an office in the UK and will still be working closely together. Should be a fun ride, this.