Be Realistic About the UML: It’s Simply Not Sufficient

The UML is Not Sufficient

AM’s Multiple Models principle tells you that you need to have many modeling techniques in your intellectual tool kit if you want to be effective as a developer. The article Artifacts for AM presents an overview of many common modeling artifacts, including but not limited to those of the Unified Modeling Language (UML), and as you can see there is a wide selection of models available to you. Each model has its strengths and weaknesses, therefore no single model is sufficient for all of your software development needs. Although the UML is in fact quite robust, the reality is that it isn’t sufficient for your modeling needs. For example, when I design the user interface of an application I generally like to create a user interface flow diagram, an example of which is shown in Figure 1. This diagram enables my team to explore how users will interact with the system from a birds-eye view, and thus ask very important usability questions long before we’ve built the user interface. Unfortunately the UML currently doesn’t include such a diagram yet, and it may never include one, so if you limit your modeling repertoire to the artifacts defined by the UML you forgo the potential productivity enhancements of this technique. Similarly it is quite common for business application developers to create data models representing the physical design of their database yet the UML does not yet have this sort of model either – I have shown how to include data modeling into object development efforts. A new UML Profile for Physical Data Modeling is published at AgileData.org (the good news is that in December 2005 the OMG announced an RFP for data-oriented models).

Figure 1. A diagram representing navigational flow within a user interface.

Although the UML defines an important collection of models, I highly suggest adopting them in accordance with the practice Apply Modeling Standards, the reality is that the UML has narrowed the range of discussion within the modeling community. Yes, sometimes it is possible to use UML diagrams in situations for which they really weren’t intended, for example it is quite common to use UML Activity diagrams to model business processes as you see in Figure 2, this often proves less than ideal. (In February 2006 the OMG officially adopted the BPMN, which I suspect is the first step to inclusion in the UML).

Figure 2. A business process depicted with a UML Activity diagram.

Similarly, the UML does not yet provide a standard way of modeling web service “wiring diagrams” nor does it say anything about security threat modeling.

In my opinion the UML is not sufficient for the needs of business application development, although it is an important part of the overall picture.Even the RUP, which comes from the same organization that first proposed the UML, explicitly includes non-UML artifacts such as business rules, data models, and user interface flow diagrams.My suggestion is to use the UML as a base collection of modeling techniques which you then supplement with other techniques to meet your initiative‘s unique needs.Furthermore, I wouldn’t replace the UML with other artifacts, although I am convinced that my own class modeling notation (The Object Primer 1st Edition, 1995 ) is superior to that of the UML’s the reality is that my notation isn’t in common use and therefore by using it I would make my diagrams difficult for others to understand and thus reduce communication on my team.

Forget About Executable UML (For Now)

Ever wish you could draw a few diagrams, press a button, and have a working software system that meets your needs? Sound like magic? Perhaps, but that’s a major part of the Executable UML vision. The basic idea is that you will use a CASE tool to develop detailed UML diagrams and then supplement them by specifications written in a formal language, presumably the OMG’s Object Constraint Language (OCL). The basic idea behind Executable UML is that systems can be modeled at a higher level of abstraction than source code, simulated to support validation of your efforts, and then translated into efficient code. This higher-level of abstraction should help to avoid premature design, enable you to change your system as your requirements evolve, and to delay implementation decisions until the last minute. In my opinion this sounds great in theory, but unfortunately there are several problems to making this work in practice:

1. The UML isn’t sufficient. The UML is clearly not sufficient for business application development, as I argue above, so trying to generate a system only from UML models at the present moment simply won’t suffice. The implication is that tool vendors will need to add their own proprietary extensions to the UML to make this work, which is exactly what existing tool vendors are doing. This is no longer executable UML anymore, it’s executable models, and more appropriately we should be talking about executable modeling (xModeling) instead.
2. Integrating a collection of tools to support Executable UML is currently difficult. Let’s assume that one or more tool vendors decide to implement the Executable UML vision and fill in the gaping holes inherent in the UML. How would they make it work? Ideally, some companies would focus strictly on building a good modeling tool and others focus on taking the output from those tools to produce a working executable on a given platform. Some vendors would produce plug-ins for J2EE environments, others for .NET environments, and others yet for mainframe environments. To support this we would need a common standard for sharing information between tools, the OMG’s XML Metadata Interchange (XMI) standard comes to mind, although because XMI is based on the OMG’s UML and Common Warehouse Metamodel (CWM) on its own it isn’t yet sufficient for fully specifying software from end-to-end. Although the CWM provides insight for specifying persistence-related information we still need to specify other aspects of a system, such as its user interface. Because there isn’t a complete standard in place the various vendors will to add their own unique extensions making multi-vendor tool integration difficult.
3. A single vendor approach will likely prove too narrow. Another approach would be for a tool vendor to support both modeling and code generation features in their tool, something perfectly reasonable in theory. But, because of the wide range of platforms, and range of design options within those platforms, the tool vendors will need to focus on a single niche. Perhaps one vendor will specialize in generating J2EE development supporting Java Server Pages (JSPs), servlets, Enterprise JavaBeans (EJBs), and relational databases. Perhaps another will specialize in generating Java-based fat-client applications whereas another generates a Win32 fat client application. The implication is that organizations that develop for several platforms will need several major development tools, tools that must be purchased and supported often at great expense. Furthermore, the wide range of required functionality of such a tool makes it difficult for vendors to specialize and focus on a single aspect of the Executable UML vision, likely resulting in slower improvement in the overall development environment.

I have no doubt that we will begin to see some interesting tools emerge over the next few years based on the Executable UML vision. In fact, several CASE tool vendors do this now in specific niches and are doing quite well., But I suspect that this vision will fall just as short as other similar visions have done in the past – we will always need programmers. Would such a tool be agile? Potentially. If it is possible to build a tool that is easy to use, that generates software that is sufficient for your environment, and that provides better value for your investment (in accordance to the principle maximize stakeholder ROI) than does other approaches to development then I would have to say yes. Do I expect to see any tool that meets these requirements anytime soon? No. Perhaps my experiences in the 1980s when CASE tool vendors bombarded the IT industry with similar promises has made me a little jaded, but my expectation is that the complexity of software development and the pace of technological change will outstrip the ability of tool vendors to generate reasonably efficient source code to meet my current needs. In other words, I fully expect the cobbler’s children to go without shoes, or in this case for developers to go without “ultimate tools”, for quite some time.

You might find my MDA page to be of interest.