Executable UML (xtUML orxUML) is both a software development method and a highly abstract software language. It was described for the first time in 2002 in the book "Executable UML: A Foundation for Model-Driven Architecture".[1] The language "combines a subset of the UML (Unified Modeling Language) graphical notation with executable semantics and timing rules."[2] The Executable UML method is the successor to theShlaer–Mellor method.[3]
Executable UML models "can be run,tested, debugged, and measured for performance.",[4] and can becompiled into a less abstractprogramming language to target a specificimplementation.[5] Executable UML supportsmodel-driven architecture (MDA) through specification of platform-independent models, and thecompilation of the platform-independent models intoplatform-specific models.[6][7]
Executable UML is a higher level ofabstraction thanthird-generation programming languages. This allowsdevelopers to develop at the level of abstraction of the application.[8] The Executable UML aims forseparation of concerns. This is supposed to increase ease ofreuse and to lower the cost ofsoftware development. This also enables Executable UML domains to becross-platform. That means it is not tied to any specific programming language, platform or technology.
Executable UML also allows for translation of platform-independent models (PIM) intoplatform-specific models (PSM). The Executable UML method enables valuing the model asintellectual property, since the model is a fully executable solution for the problem space.
Actions are specified inaction language. This means that the automatic generation of implementation code from Executable UML models can be output in an optimized form.
Executable UML is intended to serve as executable code as well as documentation. The models are a graphical, executable specification of the problem space that is compiled into a targetimplementation. They are also intended to behuman-readable.
Asystem is composed of multiple subject matters, known asdomains in Executable UML terms. Executable UML is used to model a domain at the level ofabstraction of its subject matter independent of implementation concerns. The resulting domain model is represented by the following elements:
Executable UML requires identification of the domains (also known as:aspects[9] orconcerns) of the system. "Each domain is an autonomous world inhabited by conceptual entities"[10] Each domain can be modeled independent of the other domains in the system, enabling aseparation of concerns. As an example, domains for an automated teller system may include the following:
Theseparation of concerns enables each domain to be developed and verified independently of the other domains in the system by the respective domain experts.
The connections between domains are calledbridges. "A bridge is a layering dependency between domains".[11] This means that the domains can place requirements upon other domains. It is recommended that bridges are agreed upon by the different domain experts.
A domain can be marked asrealized to indicate that the domain exists and does not need to be modeled. For example, a data access domain that uses aMySQL database would be marked as realized.
Conceptual entities, such as tangible things, roles, incidents, interactions, and specifications, specific to the domain being modeled are abstracted intoclasses. Classes can haveattributes andoperations.
The relationships between these classes will be indicated withassociations andgeneralizations. An association may require further abstraction as anAssociation Class.
Constraints on the class diagram can be written in both Action Language andObject Constraint Language (OCL).
The Executable UML method limits the UML elements that can be used in an Executable UML class diagram.
An Executable UML class diagram is meant to expose information about the domain. Too much complexity in the statechart diagrams is a good indicator that the class diagram should be reworked.
Classes have lifecycles which are modeled in Executable UML with astatechart diagram. The statechart diagram defines thestates,transitions,events, andprocedures that define a class' behaviour.
Each state has only one procedure that is executed uponentry into that state. A procedure is composed of actions, which are specified in an action language.
The class and state models by themselves can only provide a static view of the domain. In order to have an executable model, there must be a way to create class instances, establish associations, perform operations on attributes, call state events, etc. In Executable UML, this is done using an action language that conforms to the UML Action Semantics.
Action Semantics was added to the UML specification in 2001. The Action Semantics RFP was based on previous work in action languages supporting theShlaer–Mellor method. Existing action languages are Object Action Language (OAL), Shlaer–Mellor Action Language (SMALL), Action Specification Language (ASL), Model Action Specification Language (MASL),[12] That Action Language (TALL), Starr's Concise Relational Action Language (SCRALL), Platform-independent Action Language (PAL) and PathMATE Action Language (PAL). SCRALL is the only one that is a graphical action language.
Once a domain is modeled, it can betested independent of the targetimplementation by executing the model. Each domain can beverified and validated independent of any other domain. This allowserrors detected to be associated with the domain and independent of other system concerns.
Verification will involve such things as humanreview of the models, performed by experts in the relevant domain, and automated checking of the Executable UML semantics. i.e., checking that the Executable UML model complies with the Executable UMLmetamodel.
Validation will typically involve use of an Executable UML tool to execute the model. The execution can occur either before or after model compilation.
In order to support execution on the targetimplementation, the domain model must be translated into a lessabstract form. This translation process is calledmodel compilation. Most modelcompilers target a knownprogramming language, because this allows reuse of existingcompiler technologies.
Optimizing the domain models for targetimplementation reasons will reduce the level ofabstraction, adversely affect domain independence, and increase the cost ofreuse. In executable UML,optimizations are done by the modelcompiler either automatically or throughmarking. Marking allows specific model elements to be targeted for specific lower-levelimplementations, and allows for broader architectural decisions, such as specifying thatcollections of objects should beimplemented as adoubly linked list.
InMDA terms, the modelcompiler creates thePSM. The separation between the PIM andPSM in Executable UML disables the ability toround-trip engineer the model, and deters modifications to thePSM.[13]
Executable UML defines execution semantics for a subset of the UML. Key aspects of the Executable UML subset include the following:
TheObject Management Group has standardized theFoundational UML (fUML), which was strongly influenced by Executable UML.
Action Language for Foundational UML (ALF),[15] is a standard action language specification by theObject Management Group.
| Actors |
|  | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Concepts |
| ||||||||||||
| Diagrams |
| ||||||||||||
| Derived languages | |||||||||||||
| Other topics | |||||||||||||