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 werenot surprisinglymembers 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.