There has been a dialog between Grady Booch and Alan Cameron Wills on the differences between using UML and DSL's (Domain Specific Langauge). After reading the two blogs, I had a lot of thoughts about the conversation, so I thought that I would share some of them here.

Alan asserts that with DSL you have a model that is designed around the domain that you are designing. In the example given by Alan, he states that when you retrieve the type from a DSL model, you will get the domain specific type name. In UML when you retrieve the type you get the abstract model element type, for example an UML Class. Grady counters the argument by stating that you get is a stereotype of with the domain specific type.

Both arguments are correct. When you read a UML model and you ask a model element for its type, you do receive a UML Class. Then you are able to receive the domain specific type by querying for its stereotypes. Now that I have stated how each argument is correct, I do not understand the point that Alan is trying to make with his argument. In both cases the model element information will have to be translated into some other form to actually produce source code. Whether or not the translation tool has to check for a stereotype or not, does not affect the user of the tool. Alan can be trying to make the argument that it is bad to require the user to add the stereotype to the class in the first place. I see this also as a tool issue. UML does not restrict tool venders from creating new representations for the UML model elements. An example is the Robustness diagram.

Most UML tools have some way to support the Robustness diagram. The model elements on the robustness diagram are specializations of a UML class. Since most UML tools provide special visualizations for Robustness diagram, the user is not required to add the Robustness stereotypes to the UML class.

While on the topic of stereotypes, Alan also states that "You have to understand all of UML (stereotypes,etc) before you can create your language on top of it". I personally can not imagine a way that you could possibly not have a complete understanding of a domain when you go to write a language. Even if you are wanting to write a new DSL you would have to be very knowledgeable about modeling languages. Basically this is not an area for the novice, even if you are writing a domain specific language. So, basically the choice is whether or not to build upon a system that has been used by a number of people, or whether you want to start from scratch.

Alan also makes a point that UML may not be the best choice to represents all domains, such as a visual GUI editor. I tend to agree with him on this point. However, I would also state that I think that the authors of MDA would also agree. OMG has spent a lot of effort designing modeling languages for other domains like data warehouse applications. In the book MDA Explained: The Model Driven Architecture -- Practice and Promise the authors talk about other model types. The sample application that is discussed in the book uses ER diagrams. I am not saying that I do not have any problems or concerns with MDA, for example in MDA Explained the ER diagrams are generated from a Class diagram which I do not see as a realistic approach.  In reality the developer will most likely be given the ER diagram from a database management group.  It will be the developers job to retrieve the information from an existing database instead of designing a database.