The Unified Modeling Language (UML) defines the industry standard notation and semantics for properly applying that notation for software built using object-oriented (OO) or component-based technology.  In fact it is difficult to find modeling books or tools that do not use the UML these days.  The UML provides a common and consistent notation with which to describe OO and component software systems, decreasing the learning curve for developers because they only need to learn the one modeling language (in theory at least).  The UML is clearly a step in the right direction, we are no longer fighting the “notation wars” of the mid-1990s, it isn’t perfect.  In this article I argue that the UML as it stands today is not sufficient for the development of business software and that the vision of Executable UML is a little (okay, a lot) ahead of its time.  Perhaps we should define the modeling languages which we use via open source, not via committee.

The UML is Not Sufficient

AM’s Multiple Models principle tells you that you need to have many modeling techniques in your intellectual toolkit 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 www.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.  Although there is a very good effort for business rule modeling, the very earliest we'll see this is in UML 2.1 IMHO (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. 

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.

Recommended Resources

• For a better understanding of the models available to you, visit the Agile Models Distilled page
• Introduction to the Diagrams of UML 2
• Introduction to Object Orientation (OO) and UML
• A UML Profile for Data Modeling
• Why Extend the UML Beyond Object and Component Technology?

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.