- Agile MDA
- What is Agile MDA?
- Building an Executable UML Model
- Executing an Executable Model
- Translating a Model
- Merging Models Together
- Model Compilers
- Adding Code Bodies
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building an Executable UML Model
Executable UML is a profile of UML that defines execution semantics for a carefully selected streamlined subset of UML. (See Mellor and Balcer [1] for a definitive description.) The subset is computationally complete, which is why an executable UML model can be directly executed. Modeling rules are enforced not by convention but by execution: Either a model compiles and runs, or it doesn't.
All diagrams (e.g. class diagrams, state diagrams, action specifications) are "projections" or "views" of an underlying model. For example, several class diagrams may provide different views of an underlying class model. One such view might show all the subclass relationships but not show associations, while another might show associations but not subclassing relationships. Similarly, state diagrams are views of an underlying state model.
Some kinds of UML models do not support execution, such as use case models. They may be used freely to help build the executable UML models, but code generators and virtual machines do not process them.
The essential components of executable UML are illustrated in Figure 1, which shows a set of classes and objects that use state machines to communicate. Each state machine has a set of actions triggered by the state changes. The actions execute data access and functional computations, and may also send signals that induce further state changes.
A complete set of actions for creating objects, sending signals to them, accessing data about instances, and executing general computations makes UML a computationally complete specification language. Because executable UML is computationally complete, it can be used as a PIM to specify any subject matter in the system.
)
Figure
1: The primary projections of Executable UML
The difference between an ordinary boring programming language and a UML action language is analogous to the difference between assembly code and a programming language. They both specify completely the work to be done, but they do so at different levels of language abstraction. Programming languages abstract away details of the hardware platform so you can write what needs to be done without having to worry about the number of registers on the target machine, the structure of the stack or how parameters are passed to functions, etc. Action languages abstract away details of the software platform so you can write what needs to be done without worrying about distribution strategies, list structure, remote procedure calls and the like. For example, action languages do not concern themselves with the cardinality of the data structures, treating everything as a set. It is only when it comes time to transform these structures into implementation do we select an appropriate physical data structure. Similarly, with the patterns of access to data; we generate only what we need after examining whether a type of access is actually used.
As the existence of standards made programs portable across multiple hardware platforms, so too does the existence of an executable UML standard make models portable across multiple software platforms. Defining the subset as a standard is a work in progress.