Well, it has been a long time since I last posted here, mainly because I have been working full time on a very interesting project that maybe one day I'll be allowed to tell you about.
Anyway, I was recently invited to see some work going on in research concerning the understanding of web service applications, specifically how do you understand a complex network of communicating services when they go wrong. This work is led by a great team in Hawthorne under John Morar
and really helps in identifying issues. This has led me to consider some comments I made in an earlier post about the differences between domain specific languages and general purpose modeling languages in support of the separation of concerns. My belief is that a general purpose language such as the UML is like a collection of tools, a craftsman's toolbox which provides the skilled craftsman the ability to work on different aspects of a task. For example, I might use one tool for the rough cut of a piece of wood to size, then another for carving, another for polishing and so on. This approach is easy to understand, easy to apply, in the hands of a skilled craftsman; however, it requires the craftsman to know all his tools and when to apply each (hard to use fine sandpaper to rough cut!).
In contrast the domain specific language approach seems to be working towards what some in the industry term "software factories". In this vision there are no craftsman, no master tradesman, journeyman, only task specific production line workers. This vision says that each language seems
to focus only on one concern, service specification, service implementation, service distribution and so on. Developers work on a production line basis where they focus on an area of concern using specific tools. Now, this seems a very attractive proposition, I increase the specialization of my workers, I provide them task specific tools and I (assume) that individual productivity increases. So, why do I have an uncomfortable feeling about this? Am I a digital Luddite?
My personal belief is that software development is not yet
ready for this level of specialization and that really such specialization may increase individual productivity but at the risk of the overall quality of a solution in any but the most trivial of projects. What is needed is a coherent set of views into a problem, not separate models of a problem but views that support a particular concern. So, when looking at distribution I am able to visualize the distribution of the components or services defined in my design view, not a representation of them, but actually the same artifact in a different view. The UML allows this very naturally and one could certainly imagine a set of domain specific languages that could do the same - but they would have to have a common underlying architecture and (one assumes) implementation.
Now, at IBM we have a long history of involvement in both the UML as well as its predecessors, and to some extent its competitors (we are after all a big company!). But right now we have an excellent tooling architecture, based around the open source Eclipse
project that provides not only a base implementation and architecture for the development of modeling languages (the Eclipse Modeling Framework, or EMF
) but we are using this framework in the development of very specific models underlying our open source and commercial tools. This focus on tool specific models is in perfect alignment with our support for the general purpose UML, and in fact we have posted a full implementation
of the UML version 2.0 specification built upon EMF![Read More