Why Extend the UML Beyond Object and Component Technology?

For years I’ve written that the UML isn’t complete, at least from the point of view of business application development, and that we therefore need to extend it. In fact, I believe that I was the first one in the IT industry to argue this: I can’t remember which was physically published first, but both the first edition of Building Object Applications That Work and an article I wrote reviewing the initial release of the UML published in Object Magazine (the first such UML article they published) came out within a few months of each other. Both the book and the article pointed out the need to include fairly obvious things such as user interface, business process/workflow, and data modeling to the UML so that we could actually model a business application. Since then I’ve expanded on this idea in several publications, but what I’ve never really done is written, at least in one place, about why extending the UML beyond object and component technology is so important to the IT industry. Until now.By extending the UML, we would:

Support the full range of business application development. There’s more to business application development than object/component technology. There are user interfaces on the front end and databases on the back end. We’re now taking a service-oriented architecture (SOA) approach with web services, transaction processing (TP) technologies (e.g. CICS), and even stored procedures that are used to wrap database access. Call me old fashioned, but I think it’s a good idea to model the UI, the database, and services (not to mention a myriad of other aspects) when it makes sense to do so.
Make it a truly unified language. The word “unified” is wonderful marketing rhetoric describing the consolidation of major object-oriented (OO) modeling languages in the mid-1990s. This is a great start, but to have a truly unified modeling language I believe that it should address the other important aspects of development too.
Break down communication barriers. A common language, with a common notation and semantics, promotes communication between people. We’ve seen this work within the object community, now it’s time to do so within the IT community as a whole.
Break down cultural barriers. By having a common, comprehensive modeling language IT professionals will come to understand the issues that other specialists have to deal with. More importantly, they may even realize that being a specialist reduces their overall effectiveness and that they should instead strive to become a generalizing specialist.
Provide direction to developers. Many developers, if they choose to take a formal approach to modeling at all, will focus on UML-based techniques (often class diagrams, sequence diagrams, and use case diagrams from what an informal poll has shown) but not other techniques. I suspect that this is in part due to the effective marketing of the UML tool vendors, in part due to OO books which only cover UML-based techniques, and in part due to over specialization within organizations (e.g. you don’t need to learn how to model data because the data folks do that work). By including non-object/component modeling techniques in the UML they’re at least put on the radar scope of these developers, increasing the chance that they’d pick up the requisite skills to apply them effectively.
Provide guidance to tool vendors. I often see developers struggle to use UML modeling tools effectively. Sometimes their management has forced them to use the modeling tool but they haven’t been given adequate training to use it. Unfortunately there’s not much I can do about that problem other than to advise against it. Other times, however, the developers have the UML skills, they have a good UML tool, yet they still struggle because the tool doesn’t fully reflect what they need to do. Often, the tool is either limited to just the UML or has includes a less-than-stellar implementation of non-UML models (more on this in a minute). For example, if the UML included a physical data modeling profile then O/R mapping tool vendors (see my list of existing O/R mapping tools) might be motivated to build something that maps between a standard class diagram and a standard data model. Right now, although there are a lot of great O/R mapping tools out there, they’re all pretty much limited to a subset of platforms.

There are several significant challenges to this approach:

The UML is arguably too big already. Although the breadth of the UML is still a bit challenged, the depth proves to be quite impressive. The UML exhibits such detail due to the needs of the MDA tool vendors, which is great for them, but most UML practitioners neither need nor want this detail. Most people are happy with the 20% of the UML notation that they already use, struggle to see the point of the other 80%, and really aren’t all that concerned about adding to the UML.
Object purists don’t like the idea. The original goal of the UML was to define a common approach to modeling OO software. That scope was later expanded for component-based software. Some purists feel that the scope of the UML is fine the way that it is.
Non-object purists don’t like the idea. This seems to be a problem withing the data community in particular, although to be fair it’s really a problem with a very small minority within the data community. They see modern technologies and techniques, such as agile software development approaches or object technology itself, as a threat. And you know what, they’re absolutely right: the changes that have been underway within the application development community since the early 1990s are very different that the traditional data management approaches which some people within the data community still prefer. This is one aspect of the unfortunate cultural impedance mismatch between the object and data communities, a mismatch that we’ve been trying to address with the Agile Data method and its surrounding techniques.

Why I think we will see the UML extended:

The tool vendors are extending the UML on their own. You’d be hard-pressed to find a “UML modeling tool” that simply restricted itself to “pure UML”, and that’s perfectly fine. The tool vendors need to meet the actual needs of their clients, and their clients are trying to use their tools to build actual software. This is why you see companies such as IBM, Oracle, and Sybase selling CASE tools which support their own version of “UML data modeling” (respectively, these tools are Rational Software Architect, JDeveloper, and PowerDesigner). Similarly, some UML modeling tools support UI modeling, business process modeling, and web service modeling using their own UML profiles.
The methodologists are extending the UML on their own. Many UML book authors describe their techniques for UI, process, and data modeling using the UML. I cover all three in The Object Primer 3rd Edition (I started writing about all three in Building Object Applications That Work and continued to do so in Process Patterns and The Object Primer 2nd Edition). Craig Larman covers similar ground in Applying UML and Patterns. More specifically, for UI modeling via the UML, Mark Harmelen’s Object Modeling and User Interface Design is a good read. For UML process modeling, there’s Penker and Eriksson’s and Business Modeling with UML. For UML data modeling, we have Robert Muller’s Database Design for Smarties, Naiberg and Maksimchuk’s UML for Database Design, and my own Agile Database Techniques.
The OMG is finally starting to extend the UML. They’ve brought the Business Process Modeling Notation (BPMN) into their fold, indicating movement towards a standardized approach to process modeling via the UML. They’ve also issued an RFP for a data modeling notation in December 2005, which is the first step to developing an industry standard. Unfortunately, the data community has never gone to the effort of defining an industry standard notation (not that you can blame them, it’s a truly thankless task) so there isn’t an existing standards body to work with, unlike with BPMN.

In short, it’s already happening.