devxlogo

Executable UML: Diagrams for the Future

Executable UML: Diagrams for the Future

The entire history of software engineering is that of the rise in levels of abstraction” said Grady Booch in his talk “The Limits of Software.” Today, we’re at the beginning stages of the next level. Executable UML is the next logical, and perhaps inevitable, evolutionary step in the ever-rising level of abstraction at which programmers express software solutions. Rather than elaborate an analysis product into a design product and then write code, application developers of the future will use tools to translate abstract application constructs into executable entities. Someday soon, the idea of writing an application in Java or C++ will seem as absurd as writing an application in assembler does today. And the code generated from an Executable UML model will be as uninteresting and typically unexamined as the assembler pass of a third generation language compile is today.

This shift is made possible by the confluence of four factors:

  1. The development of the Model Driven Architecture (MDA) standards by the Object Management Group (OMG)
  2. The adoption of the Precise Action Semantics for the Unified Modeling Language specification by the OMG in November of 2001
  3. A proposed profile of UML?Executable UML?supports creating a complete and implementation-neutral self-contained expression of application functionality. Steven J. Mellor and Marc J. Balcer define this profile in their book Executable UML: A Foundation for Model-Driven Architecture
  4. The availability of high-quality Model Compilers and Virtual Execution Environments (VEEs) that provide “out of the box” platforms upon which Executable UML models can execute. These VEEs, which exist today in a somewhat incipient stage, will someday soon reduce low-level system architectures to near-commodity status.

This article reviews these four factors in greater detail and discusses the implications of them relative to the future of software development.

Author Note: It is important to note that Executable UML as described by Mellor and Balcer is one instance, but not the only possible instance, of a method and UML profile showing the viability of Executable UML as a general concept. While a discussion of their book is part of the intent of this paper, it is the wider sense of Executable UML (that also encompasses MDA, Action Semantics, and VEEs) that is the central theme.

Introducing Model Driven Architecture
The word architecture is heavily overloaded in the context of discussing systems and software. An architecture is a description of the fundamental components of a solution and their structural relationships to each other. In the MDA, there’s a distinction between application architecture and systems architecture. Application architecture is the components and structural relationships that exist to specify the functional purpose of the application. Systems architecture is the lower level components and structural relationships that allow the application architecture to execute. It is the separation of the application architecture from the systems architecture that is the fundamental thrust of the MDA.

MDA, as defined by the OMG, essentially calls for the mapping of a Platform Independent Model (PIM) onto a Platform Specific Model (PSM).

MDA, as defined by the OMG, essentially calls for the mapping of a Platform Independent Model (PIM) onto a Platform Specific Model (PSM). A PIM is a complete application specification that is independent of the technology platform upon which it will eventually execute. PIMs map onto PSMs, which provide the systems architecture infrastructure, or “plumbing,” that implements the PIM on a specific technology platform, turning it into an executable application. One way to view this is to think of the PIM as source code for a solution, the mapping function as a compiler, and the PSM as an execution environment. The term Virtual Execution Environment (VEE) conveys a sense of the ultimate intent of the PSM.

Don’t underestimate the benefits of this approach: intellectual capital invested in the PIM is forever protected from changes or advances in the underlying technologies. The PIM lets you model a solution both visually and at a higher level of abstraction. Re-writing applications to take advantage of newer technology (and there will always be a next, greatest technology), will become completely unnecessary. Instead, you simply regenerate the application using a mapping to the newer VEE.

The OMG provides?or will provide?standard PIM-to-PSM mappings for many of the popular technology platforms such as CORBA, J2EE, and .NET. Along with these mappings other OMG standards such as the Meta-Object Facility (MOF), XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM) work in concert to make the MDA a complete and robust approach to software development. The MOF provides a standard repository for UML models and defines a structure that allows a common meta-view of the stored UML models. XMI allows companies to exchange UML models as streams or files with a standard format based on XML. The CWM standardizes how to represent database models, schema transformation models, OLAP, and data mining models.

Adopting Action Semantics for UML
The adoption of the Precise Action Semantics for the UML by the OMG supports the viability of Executable UML. The standard was the work of a large industry consortium comprised of Rational Software, Kabira Technologies, Project Technologies, Kennedy-Carter, and others, in response to a Request for Proposals (RFP) from the OMG. Prior to that adoption the only way to attain 100% code generation from a UML-modeled solution was to use a third generation language or a proprietary language to specify the algorithmic behavior of the solution. In other words, prior to this standard, UML Class Diagrams and State Models could generate data structures and control flow, respectively, but there was no approved standard way to describe the low-level behavior of a given state. Because of this, many CASE tools could generate the shell of an application solution, but programmers were needed to fill in the actual behavior of the states (methods) with either a language like Java or C++ or a proprietary language of the CASE tool vendor.

The Precise Action Semantics for the UML standard provides an unambiguous semantic set of the operations required to specify the behavioral aspects of a UML model to a level of detail such that a self-contained and completely executable application can be generated from that model. The semantic set includes operations that support the synchronous manipulation of objects (create, read, write, delete), the generation and handling of asynchronous events (signals), and the logical constructs that support the specification of algorithms. The modeler specifies these operations using a text-based action language. All that is needed to completely specify the behavioral aspects of the UML model is an action language that follows the semantic standard.

The breakthrough notions of using an action language to specify behavior in a UML model are that:

  • The action language allows modelers to define behavioral specification at a higher level of abstraction.
  • The language is independent of any specific underlying technology in the execution environment.

Note that an action language allows only direct manipulation of UML elements. To accomplish that goal, modelers give up low-level control like pointer manipulation but are also freed from having to clutter up the model with issues like persistence, data storage, or distribution. Instead, application configuration deals with such issues at code generation time. Because an action language?and indeed the entire PIM UML model?is by definition independent of the underlying execution technology, modelers can target the application solution to multiple and diverse execution platforms, even future platforms that did not exist at the time the PIM was developed.

Because action languages exist at such a high level of abstraction they do not entail the steep learning curves of third generation languages.

Unfortunately, the Precise Action Semantics for the UML is a semantic standard only, not a syntactic standard. This was, presumably, based on political expediency, because many members of the submitting consortium supply either CASE or development tools which already contained fully realized action languages with proprietary syntaxes. One point of view maintains that syntax does not matter; however, it’s easy to see that competing syntaxes may constrain the ability of Executable UML to gain mind-share in the development community and may, by extension, retard growth rates in the adoption of MDA technology. On the other hand, because action languages exist at such a high level of abstraction they do not entail the steep learning curves of third generation languages. Therefore, after learning one action language syntax, modelers can easily learn another, because they would be dealing with the same semantic set.

Executable UML: Why the Book Is Important
Although Stephen J. Mellor and his late colleague Sally Shlaer are two of the seminal thinkers behind MDA, they are rarely given credit in either the OMG’s public records or elsewhere. Their early work with the arguably ill-named Recursive Design was completely isomorphic with the principle tenet of MDA, namely that an implementation-neutral yet complete specification or solution could be translated through mapping into a target implementation. Shlaer-Mellor Object-Oriented Analysis (SM-OOA) was an early object development method and notation centered on such a translative approach. It was mildly popular in certain development niches, particularly in the real-time and embedded systems world. The notational consolidation that gave rise to UML effectively delivered a knockout blow to SM-OOA as a notation but perhaps, as we shall see, not as a method. The consolidation of the notational styles and artifacts of Booch, Rumbaugh, and Jacobsen into one “unified” whole?UML?is to the modeling community what paella is to the Spanish kitchen: throw whatever you have into the pot. Unfortunately, what is delicious in a culinary sense has become to the modeling community a rather complex and intertwined set of artifacts that often leaves the novice overwhelmed and may indeed steer developers away from using UML. In an ideal world, given unlimited resources, the full UML can theoretically be used to create the perfect software. In practical terms and in most practice, a subset of UML is sufficient to create useful software for real world needs. This pragmatic approach gives rise to the notion of UML profiles. A UML profile is a subset of UML that is necessary and sufficient for a given development effort.

The consolidation of the notational styles and artifacts of Booch, Rumbaugh, and Jacobsen into one “unified” whole?UML?is to the modeling community what paella is to the Spanish kitchen: throw whatever you have into the pot.

In their book Executable UML: A Foundation for Model-Driven Architecture, Mellor and co-author Balcer offer a profile of UML that is unapologetically equivalent to the artifacts used in SM-OOA, albeit using UML notation. The authors go as far as to say, “Executable UML brings Shlaer-Mellor and UML notation together by using UML notation and incorporating concepts of execution.” In other words, the authors have conceded the notational battle, but still favor translation over elaboration (see the sidebar The Three Amigos). There are a few minor changes, such as the absence of a requirement for identifiers and referential attributes, which differentiate the UML profile defined by Mellor and Balcer from pure SM-OOA. But overall, their UML profile and its usage is essentially SM-OOA: this is not necessarily a bad thing, given the conceptual similarity of SM-OOA and MDA.

The book uses only four artifacts of UML: Packages, Class Diagrams, State Models, and a semantically valid action language. The authors contend that, for a large class of applications, these are the only constructs needed to create a complete, consistent, and verifiable model of an application that can be mapped onto and executed within a VEE. Packages provide the structural elements necessary to separate the various subject matters of an application development effort into domains. To appreciate the use of the other three artifacts, consider the abstract programming model of data, control, and algorithm: Class Diagrams provide the specification of the data, State Models provide the specification of control, and the action language provides the specification of algorithm. Modelers make these specifications are made at a higher level of abstraction than is possible in a third generation language. The intellectual capital captured in the models is protected from the evolution of execution technology because there is a clear separation between the specification of the solution and its implementation. All that is needed to execute the solution is a VEE and the appropriate mapping from the model into that VEE. This mapping is accomplished by the use of a model compiler.

The Relationship Between Model Compilers and VEEs
To understand what a VEE does, you should first understand the relationship between the modeled application and the low-level architecture that supports its execution. One way to visualize this is with the UML package diagram shown in Figure 1.

Figure 1: This UML package diagram shows the relationship between a modeled application and the low-level architecture that supports it.

To become executable, the modeled application, or PIM, depends upon the architectural services of the PSM. The UML profile used to create the executable model places specific requirements upon the PSM. In other words, each UML element that is part of that profile must be somehow supported via the mapping into an element of the PSM that can be part of the execution environment. The mapping itself is typically referred to as model compiling and the mapping mechanism a model compiler. The main purpose of the model compiler is to translate each modeled element of the PSM into an element that can be executed within the architectural framework of the VEE.

The simplest example of a mapping is perhaps that of a Class Diagram. Consider the (admittedly simplistic) Class Diagram shown in Figure 2.

Figure 2: You can use even this simplistic Class Diagram to begin to explore the mapping problems faced by model compiler developers.

Using that diagram, you can start to examine some possible mappings and entertain some of the issues faced by the model compiler developers. First of all, to what should a UML class be mapped so that it can run in an execution environment? The obvious choices might be a Java class or a C++, but there is no reason why the data attributes could not be mapped to a C structure and the methods mapped to C functions. (A perversely clever model compiler developer could even devise a scheme to translate a UML model into a COBOL program.) The point is that the choice of mappings is directly related to the capabilities of the execution environment. Given a UML profile and an desired execution environment, mapping is a complex but not intractable problem. This simple example is only intended to show the conceptual thrust of mapping a UML model to an execution environment. There are obviously many more issues involved with mapping all the elements of a given UML profile into a VEE: event (signal) handling; mechanisms to create, store, and access data; state (method) execution; etc.

After establishing the mappings, additional mechanisms must extract the necessary information from a CASE tool, perform the actual mapping of the extracted elements, generate the code for the target environment, build the executable entity and provide the architectural framework of the VEE itself. In addition, depending on the features of the model compiler and the execution environment, configuration support can be provided, for example, to let an administrator specify particular classes as being persistent or non-persistent, how many separate processes should be used to run the application, and how the classes should be allocated across those processes. The model compiler developer must also decide how to support persistence (if required), and distributed processing, and how to physically generate and receive signals. These low-level facilities are part of the systems architecture provided by the VEE, and although they are of concern to the model compiler developer, they should not normally be areas of concern for the application modeler. This separation of responsibilities is analogous to a third generation language developer not typically caring exactly how the compiler creates an executable from his or her source code. There may be an academic interest in the compiler technology, but that academic interest has little to do with the actual intent of the program or the real world need it addresses.

Most of the issues and decisions that are faced by the model compiler developer are germane to the realm of systems architecture or what is often referred to as “the plumbing”. Successful application execution depends on these low-level facilities and mechanisms. The spirit of the MDA and the vision of Executable UML presented here clearly advocate a separation of the application and systems architecture. A few vendors offer off-the-shelf Model Compilers/VEEs today; most of them were?not surprisingly?members of the consortium that submitted the OMG-adopted Precise Action Semantics for the UML. While this paper does not review these products, the Kabira Technologies’ ObjectSwitch, Project Technologies’ BridgePoint, and Kennedy-Carter’s iUML/xUML offerings follow the Executable UML paradigm described here.

One effect of wide adoption of Executable UML will be a marked division of labor and skill sets within the developer community. Modelers well versed in both the UML and in domain-specific knowledge will build applications; developers with lower-level technical skills and deep knowledge of computer science will build model compilers and VEEs.

The model compiler and its associated VEE are, in effect, a reusable systems architecture. This simple fact leads to the conclusion that such reusable systems architectures will eventually approach near commodity status, much like relational database managers (RDMS) and third generation language compilers are today. Twenty years ago it was not unusual for an application development team to write their own RDMS for a new project. Today that would be viewed as absurd as, say, writing a web server in assembler language. Unless the execution demands of the given application are very unusual, most development teams in the future will buy an appropriate model compiler and VEE off-the-shelf and leave the plumbing to the VEE vendors.

Companies will be able to protect their strategic investments and software assets by modeling their intellectual property in models that are immune to advancements in execution technology. When a technology breakthrough occurs, developers will take advantage of it by devising a new mapping to the new technology, not by totally rewriting applications.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist