Toward Executable UML

Ever wish you could draw a few diagrams, press a button and have the working software system that you need? Sounds like magic? Perhaps, but that simplicity is the essence of the Executable UML (xUML) vision—you'll use a CASE tool to develop detailed UML diagrams, and then supplement them with specifications written in a formal language. The Object Management Group (OMG)'s Object Constraint Language (OCL) is currently the best candidate for that formal language, at least within the object world. However, despite the merit of the xUML concept, I'm not so sure that OCL has a bright future.

"Executable UML models systems at a higher level of abstraction, thus avoiding the costs involved in a premature design," reports Steve Mellor of Project Tech. "It also offers the benefits of early verification through simulation, the ability to translate the UML model directly into efficient code, and the ability to delay implementation decisions until the last minute." In theory, this is a great vision, one that I heard Ivar Jacobson echo in his keynote address at UML World last summer ("Executable Models Are Inevitable," Sept. 2001), but I believe it will be difficult to achieve in practice.

UML for Business: Nothing to Say
In these pages, I've often argued that UML isn't sufficient for business application development. You probably develop software with user interfaces, yet UML currently has nothing to say about user interface modeling. You probably develop software that accesses persistent storage, such as relational databases, yet UML currently has nothing to say about data modeling—Eric Naiburg and Robert Maksimchuk's book, UML for Database Design (Addison-Wesley, 2001), is the closest thing we have yet, but, like many other data modeling schemes, it isn't an official element of UML. This indicates that xUML may be viable—but only if you generate software that has neither a user interface nor database access.

Now assume that one or more tool vendors decides to implement the xUML vision—clearly, executable models are the holy grail of the CASE tool industry—and chooses to fill in the gaping holes inherent in UML. How would they make it work? Ideally, some companies would focus on building a good modeling tool; others would use the output from those tools to create a working executable on a given platform. Some vendors would produce plug-ins for J2EE environments, others would deal with .NET environments and still others would choose mainframe environments. To support this, we would need a common standard for sharing information among tools. The OMG's XML Metadata Interchange (XMI) standard comes to mind; however, it's probably not a viable solution because XMI is based on the OMG's UML, and the Common Warehouse Metamodel (CWM) isn't yet sufficient for fully specifying software from end to end. Because no complete standard is in place, various vendors will add their own unique extensions, making multivendor tool integration difficult.

Many Tools, Many Platforms
Alternatively, a tool vendor might attempt to support both modeling and code generation features in one tool. Perhaps one vendor will specialize in generating J2EE development supporting Java Server Pages (JSPs), servlets, Enterprise JavaBeans (EJBs) and relational databases. Perhaps another might focus on generating Java-based fat-client applications, whereas another may generate a Win32 fat-client application. Multiple platforms require multiple development tools, which must be purchased and supported, often at great expense.

Even if these obstacles are overcome and we've got a tool that actually fulfills the xUML vision, we still need to know how to use it—and how to create the artifacts that the tool supports. This includes the myriad models of the UML and at least one formal modeling language, if we wish to stay reasonably abstract. As I mentioned, the leading formal language contender is OCL, one of the least understood aspects of UML.

Diagrammatic Definition
OCL was designed to support UML diagrams as a formal, logical language to unambiguously define things such as constraints, algorithms and rules. This is important if you wish to define something precisely using models—diagrams are not capable of conveying important subtleties such as uniqueness constraints, formulas, limits and business policies. For example, this class diagram depicts two classes, Student and Seminar, and describes their "waiting list" association. Constraints are depicted on UML diagrams in the format {constraint description}, where the constraint description may be in any format, including both OCL and structured English. In this case, I indicated that the waiting list is in First In, First Out order.

A UML Class Diagram Enhanced With an OCL Constraint Two classes, Student and Seminar, with their "waiting list" association.

OCL can also be used to specify business rules and algorithms. The following code sample presents a well-formedness rule for associations in UML diagrams, taken from OMG document ad/01-08-35: "Initial Submission to OMG RFP's: ad/00-09-01 (UML 2.0 Infrastructure) ad/00-09-03 (UML 2.0 OCL)". The first line defines the context of the constraint, similar to the way you'd define what package a Java class is part of: In this case, this code defines an invariant on associations. The second line defines the name of the constraint, which must be unique within the context. The remaining lines define the "code" for the rule.

context Association_inv
AllAssociationEndsHaveDistinctNames
self.AssociationEnds->forAll(element, element' |
element.name(self.AssociationEndNames) =
element'.name(self.AssociationEndNames) implies
element = element'))

This code sample reveals the reason that OCL hasn't been widely adopted: It's wordy and hard to read. In plain English, the rule simply means that all association ends in an association's namespace have different names—but you must write six lines of OCL code to represent that rule. Imagine the complexity of writing OCL for a business rule described by several paragraphs of English text. Ideally, you could organize your OCL into a collection of "subroutine" statements similar to that presented above, but that isn't always possible.

OCL is also inefficient in specifying requirements-level and analysis-level concepts. When I'm exploring a system's requirements, I prefer to model side-by-side with my project stakeholders, working on use cases or CRC cards, and I doubt that I could teach them how to read OCL, let alone write it. Like other formal and/or business rule languages such as Z, Objective-Z, VDN++ and Ops5, OCL is too difficult for nondevelopers to understand. Structured English or simple prose will always be more effective and easier to use.

Throughout the IT industry, OCL use is negligible—perhaps only one in 100 developers could tell me what OCL stands for, and of those people, only one in 100 could write an OCL statement. I rarely see OCL in client sites' models, and when I do, it's minimal. And, even though it's an excellent resource, I don't see copies of Jos Warmer and Anneke Kleppe's The Object Constraint Language: Precise Modeling With UML (Addison-Wesley, 1999) on people's shelves. Developers quickly adopt the techniques and technologies that offer real-world value-unfortunately, this is what OCL clearly lacks.

Thus, I doubt that OCL will ever be widely used, especially in the business application development community. We'll see some interesting tools based on the xUML vision emerge over the next few years, but I suspect that this vision will fall just as short as similar visions have in the past. Rest assured, programmers will remain indispensable.

I'd like to thank Glen B. Alleman, Marko Boger, Larry Brunelle, Jon Kern, Larry O'Brien, Kirk Wilson and Geri Winters for their OCL insights posted on the Agile Modeling mailing list (www.agilemodeling.com/feed back.htm).