Agile Modeling Guru Scott Ambler names MetaEdit+ "most sophisticated" DSM tool

In his latest Agile Modeling newsletter, titled "Unified or Domain-Specific Modeling languages?" agile modeling guru, Scott Ambler explains the need for both DSMs and UML. While naming MetaEdit+ as the most sophisticated DSM tool, he also claims both approaches can learn from each other and do not or should not strike each other out.

This fits well with the vision MetaCase has for domain-specific modeling where applications are built on top of a software platform and possibly a code generation framework. Although DSM allows building of applications significantly faster than UML-based approaches, UML does prove its value in visualizing code, sketching and documentation.

 

SD's Agile Modeling Newsletter 
By Scott W. Ambler

UNIFIED OR DOMAIN-SPECIFIC MODELING LANGUAGES?

There is a war brewing among modeling methodologists. On one side we have proponents of the Unified Modeling Language (UML) and on the other, people who prefer domain-specific modeling (DSM) languages. The advantage of the UML is that it offers a common modeling language that all IT professionals (at least those using object and/or component-based technology) can use to communicate with each other. The primary advantage of DSMs are that they define a specific point solution to a specific problem; DSMs are focused, they don't try to be all things to all people. Therein lies the root of the brewing argument — should you model using general languages or specific languages? The answer is yes.

Let's compare and contrast the two approaches. The UML was first introduced in 1996 by Rational Corporation, now a division of IBM, and adopted by the OMG in November of 1997. Due to OMG backing, the UML is supported by a large number of tool vendors. DSMs have been around for decades, but only recently gained buzzword status in early 2004 with the book Software Factories (Wiley, 2004) written by a team of people at Microsoft. Most modeling tools support DSMs to some extent (more on this later), although MetaEdit+ from MetaCase (www.metacase.com/) is the most sophisticated while Visual Studio from Microsoft seems to have the most mindshare. In short, both concepts have successful track records and support from multiple vendors.

Neither approach is perfect. UML is a wonderful vision in theory, but in practice, very few developers have taken the time to learn the UML thoroughly. Some at least have a passing knowledge of it, but most appear to have little interest in it. Apparently, the standard language isn't so standard after all. Furthermore, the UML is overly complicated in some areas yet clearly lacking in others — it still doesn't define a standard way to model user interfaces, business rules, or physical database schemas. General consensus within the modeling community is that the real-time community — and to a lesser extent the proponents of the Model- Driven Architecture (MDA) — hijacked the UML 2.0 effort. That was good for them, but the vast majority of us now have trouble staying awake whenever UML is discussed.

With DSMs, you need to adopt one collection of models to model one type of application and a different set for another type. For example, to model a logistics system built with J2EE-based technology, you would need a logistics DSM to model the domain, something to model the user interface, something to model the detailed business logic implemented in the object-oriented Java code, and something to model the database schema (to name a few modeling needs). However, to model a data warehouse, you would need DSMs to model reports, the data-source architecture, and the physical schema of the data warehouse itself. Interestingly, several of the models that I listed are fairly generic (UI models, object models, and data models), indicating that not everything is truly a DSM. The DSM vision often doesn't sit well in organizations that want to minimize the number of development tools they have and the amount of training and education that developers receive. To be fair, the UML-based approach suffers from similar problems, but it's not as explicit as with the DSM approach.

Even the “purest” UML tool vendors support DSMs, even though they may not admit it. If you want to support business application development you need to fill in the gaping holes of the UML. For example, several tool vendors, including both IBM Rational and Oracle, support UML-based data modeling in their CASE tools even though there's no standard definition for doing so. In fact it was just recently, in December 2005, that the OMG even issued an RFP for data modeling. My expectation is that we'll see data modeling officially accepted within the UML sometime in 2007, roughly 10 years too late. Until then data modeling within UML- based tools is effectively an exercise in domain specific modeling, in this case the domain is relational data schemas.

Can the two sides learn from each other? You bet. The UML vision from the OMG could benefit from a bit of reality — UML tool vendors need to focus on building great tools that implement both UML models and DSMs, which enable developers to actually build working software. It should be possible to actually build a business application from end-to-end, including both the front- end user interface and the back-end database, using these tools. The Software Factories vision from Microsoft could benefit from a bit of humility — there's a lot of good stuff in the UML, so my advice to Microsoft is to reuse the UML wherever possible and try to make your DSMs look as UML-ish as possible to improve communication between developers.

Frankly, the industry would be better served if more vendors were to adopt the Agile Modeling vision. Agile modelers follow the practice “Apply the Right Artifact,” and a DSM is more likely to be the right artifact than a general-purpose UML model. However, having a common modeling notation clearly offers the potential for improved communication between developers, as long as that common notation is simple, sufficient, and accepted. I believe that the Software Factories approach, along with a lack of acceptance of MDA, has provided the OMG with a very loud wake up call. They seem to be listening: The RFP for a UML data model seems to be a sign that the OMG is now taking the needs of business application developers seriously, but only time will truly tell.