Dice Stuart Kent:
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.El cambio es expresado más claramente por Cameron Skinner, referido por Kent:
Volveremos sobre esto.
There has been some speculation in the press recently around Microsoft's commitment to DSLs now that we are planning on supporting five UML 2.1 diagrams in the Rosario release ( Class, Use Case, Component, Sequence, and Activity diagrams ). Specifically, some articles have been written in a way to lead the reader towards a perception that Microsoft is moving away from DSLs and towards UML. Not at all correct! I wanted to take a moment and set the record straight on this, and start a broader conversation.
Let me first start by making one thing very clear: Microsoft is very committed to our DSL strategy, and in particular to the DSL toolkit that ships as part of the VS SDK. In fact, our UML designers are built on top of that toolkit.
I believe that supporting both approaches to modeling gives developers and Architects alike the "right tool for the right job". For those folks who want to analyze and design their architecture using a standard notation that does not imply an implementation decision, use some UML diagrams. UML is great for describing higher level concepts and for defining the initial glossary that can be used to describe the concepts necessary to facilitate broader communication. For those folks who have decided on an implementation strategy, and do not want to be encumbered by the more general nature of the UML to describe that implementation choice, use DSLs.
In the coming months, you will very likely hear me or others on the team talk about using UML at the "logical" layer and DSLs at the "physical" layer. We are really trying to promote a clean separation between the two approaches, while at the same time, attempt to maintain an understanding of how one can inform the other, and vice versa. In this way, we are hoping to more cleanly support the understanding and intent behind the models at each layer.
So this is not a "DSL vs. UML" conversation. This is a "DSL + UML" conversation. And more importantly, this is about meeting our customers where they are and giving them tools that allow them to get to where they need to be.
The true innovation in this space is going to be how we can seamlessly connect the two approaches, and how we can make modeling more central to a broader range of people.