I believe that UML is a low level modeling language. UML is great for describing the structure of an application. The sequence diagram and collaboration diagram is also very good at describing interactions between objects. However, in order for the development industry to meet the growing demands for our services, we need to describe applications using higher constructs than classes, interfaces and objects. For example, we need modeling languages that have constructs that describe a web service and an EJB. Once we have the higher constructs defined, the developer can drop a web service onto the diagram, plug in a few ports and BANG the web service has been created.

The previous paragraph sounds a lot like the Software Factories approach. The Software Factories approach creates a new language for each domain. The new domain specific language (DSL) is then used to describe an application. The advantage of the domain specific language approach is that you are no longer using classes, interfaces and objects to describe applications, you are now manipulating constructs that are custom fit for the specific domain that is being developed. As you have probably guessed the software factories approach will require the birth of a number of new languages. Each company that employs developers will also have to employ language specialists to develop and maintain languages needed for their specific domain.

In my opinion, I believe that the Software Factories approach has a lot of good points and a lot of bad points. One area that I disagree with is the break away from UML. I think that the higher constructs can be accomplished by either extending the UML meta model or by using the profile extension mechanism. In order to add the higher level constructs, the profile mechanism will need to be extended. One of the extensions that needs to be made to the profile mechanism is to allow a profile author to specify an alternative representation for a model element. Once "webservice" stereotype is applied to a component, the user will not see a component notation that has the stereotype of a "webservice." The model element instead will be represented as a web service. This concept is not to far fetched. Many UML tools already support the Robustness diagram notation. The Robustness model elements are UML classes that have a stereotype of "boundary," "controller," or "entity." The trick is that the representation of classes with the Robustness stereotypes is not the same as the representation of a class without the stereotype.

The way I see it, most users of modeling tools do not care about how the model element is represented internally. All they care about is how clear the information is represented, and how quickly they can get their work done. By still using an extension mechanism, the burden is moved from the language designers to the tool providers. The stereotypes that have their own representations can be added to a palette. A tool that adds the stereotypes to their palette can also allow the user to quickly drop model elements with the stereotype. The code generation mechanism (or model transformations mechanism) can handle the issues of transforming the classes with the stereotype to source code. Tools can do what ever it takes to limit the reasons why the user has to physically apply stereotypes to a model element.

Lets say that we have written DSLs for the EJB and web service domains. Now we need an EJB that is also a web service. With the DSL approach, we have to create a new language that merges the two languages which means the developer now has to wait until the language expert can create the new language. I would rather have the ability to overlay the concept of a web service onto my EJB object or vise versa. That way the developer would not have to wait for a new language to be created. Then, I could also view my object as a web service or an EJB depending on what the diagram is trying to communicate.

A domain specific language is extremely effectively for its designed use. However, as soon as you start to go beyond the bounds of the languages concepts the language starts to slow you down. Because of the limitations of the language, the developer will either fight the language, switch languages, or again go back to the language developer. In any case, the rate of development will be drastically hindered.

I believe that a shift in our thinking needs to be made. It is time for modeling languages to advance from low level languages to more abstract modeling languages. UML should become to modeling languages what assembly language became to modern programming languages. When it became too complex and too painful to develop using assembly languages, the industry started to develop more advanced languages. The higher level language would still compile down to the assembly language. For a long time the higher languages allowed developers to embed assembly language instructions into an application. More recently, programming languages such as Java and C# no longer allow the developers to embed assembly language instructions, and they no longer compile down to assembly language. The same pattern has to occur in the modeling world as well.

We need to build on top of UML to produce higher level modeling languages. We still need to be able to embed some UML constructs into the higher level modeling languages. The meta data of the higher level languages need to be built on top of the UML meta model, but few users of the modeling tools will know or care about how model information is stored. Just like few developers care what assembly instructions are generated when they compile their source files.

There are two reason why we should build on top of UML. First, UML is already accepted as the modeling standard. Second, UML already has the a powerful extension mechanism. The extension mechanism needs to be enhanced, but is still a very good mechanism.