Executable UML

Executable UML, often abbreviated to xtUML [Example usage: http://www.techonline.com/community/tech_topic/37519] or xUML [Example usage: http://www.kc.com/xuml.php] , is the evolution of the Shlaer-Mellor method to UML. Executable UML graphically specifies a system using a profile of the UML. The models are testable, and can be compiled into a less abstract programming language to target a specific implementation. Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", Preface, Addison Wesley, 2002] [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", chapter 1.4 Model Compilers, Addison Wesley, 2002] Executable UML supports MDA through specification of platform-independent models, and the compilation of the platform-independent models into platform-specific models. [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", chapter 1.5 Model Driven Architecture, Addison Wesley, 2002]

Usage of Executable UML

Executable UML is used to model the domains in a system. Each domain is defined at the level of abstraction of its subject matter independent of implementation concerns. The resulting system view is composed of a set of models represented by at least the following:
* The "domain chart" provides a view of the domains in the system, and the dependencies between the domains.
* The "class diagram" defines the classes and class associations for a domain.
* The "statechart diagram" defines the states, events, and state transitions for a class or class instance.
* The "action language" defines the actions or operations that perform processing on model elements.

Domain Chart

:See also: Aspect (computer science), Concern (computer_science)

Executable UML requires identification of the domains (also known as: aspects [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", chapter 3.5 Domains and Aspects, Addison Wesley, 2002] or concerns) of the system. "Each domain is an autonomous world inhabited by conceptual entities" [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", chapter 2.1.1 Domain Identification, Addison Wesley, 2002] Each domain can be modelled independent of the other domains in the system, enabling a separation of concerns. As an example, domains for an automated teller system may include the following:
* The application domain model of the automated teller's business logic.
* The security domain model of various issues regarding system security (such as authentication and encryption).
* The data access domain model of methods for external data usage.
* The logging domain model of the various methods through which the system can or must log information.
* The user interface domain model of the user interactions with the system.
* The architecture domain model of the implemented of the Executable UML model on the system's hardware and software platforms.

The "separation 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 called "bridges". "A bridge is a layering dependency between domains" [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", chapter 3 Bridges, Addison Wesley, 2002] . 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 as "realized" to indicate that the domain exists and does not need to be modeled. For example, a data access domain that uses a MySQL database would be marked as realized.

Class diagram

:See also: Class diagram

Conceptual entities, such as tangible things, roles, incidents, interactions, and specifications, specific to the domain being modeled are abstracted into "classes". Classes can have "attributes" and "operations".

The relationships between these classes will be indicated with "associations" and "generalizations". Some associations may require further abstraction as an "Association Class".

Constraints on the class diagram can be written in both Action Language and Object Constraint Language (OCL).

The Executable UML profile limits which UML elements 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.

tatechart Diagram

:See also: Finite State Machine, State diagram

Classes have lifecycles which are modeled in Executable UML with a statechart diagram. The statechart diagram defines the "states", "transitions", "events", and "procedures" that define a class' behaviour.

Each state has only one procedure that is executed upon entry into that state. A procedure is composed of actions, which are specified in an action language.

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. Action languages have been around much longer than that in support of the Shlaer-Mellor method. Some existing action languages are Object Action Language(OAL), Shlaer-Mellor Action Language(SMALL), Action Specification Language(ASL), 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.

Model testing and execution

:See also: Software verification, Debugging

Once a domain is modelled, it can be tested independent of the target implementation by executing the model. Each domain can be verified and validated independent of any other domain. This allows errors detected to be associated with the domain and independent of other system concerns, and lowers the cost of verification and validation.

Verification will involve such things as human review of the models, performed by experts in the relevant domain, and automated checking of the Executable UML semantics. e.g., whether or not the Executable UML is compilable, whether or not each class attribute has a type, etc.

Validation will typically involve use of an Executable UML tool to execute the model. The execution can occur either before or after model compilation.

Model compilation

In order to support execution on the target implementation, the domain model must be translated into a less abstract form. This translation process is called "model compilation". Most model compilers target a known programming language, because this allows reuse of existing compiler technologies.

Optimizing the domain models for target implementation reasons will reduce the level of abstraction, adversely affect domain independence, and increase the cost of reuse. In executable UML, optimizations are done by the model compiler either automatically or through "marking". Marking allows specific model elements to be targeted for specific lower-level implementations, and allows for broader architectural decisions, such as specifying that collections of objects should be implemented as a doubly-linked list.

In MDA terms, the model compiler creates the PSM. The separation between the PIM and PSM in Executable UML disables the ability to round-trip engineer the model, and deters modifications to the PSM. [Mellor, S; Scott, K; Uhl, A; Weise, D: "MDA Distilled: Principles of Model-Driven Architecture", chapter 9, Section "Model Compilers", Addison Wesley, 2004]

Executable UML profile

Executable UML is a profile of the UML, defining execution semantics for a subset of the UML.

Some of notable aspects of the Executable UML profile include the following:
* No support for implementation specific constructs, like aggregation and composition. [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", Frequently Asked Questions, Addison Wesley, 2002]
* Generalizations are always notated as {complete, disjoint}.
* Associations between classes are "always" named, have verb phrases on both ends specifying the roles, and have multiplicity specified on both ends.
* Multiplicities on association ends are restricted to 0..1 (zero to one), * (zero to many), 1 (exactly one), or 1..* (one to many).
* Data types are restricted to the following core data types: boolean, string, integer, real, date, timestamp, and arbitrary_id, or one of the following domain-specific data types: numeric, string, enumerated, and composite. Domain-specific numeric and string data types can represent subsets of the core data types. The domain-specific composite data type is to always be treated as a single unit. e.g., a "MailingAddress" data type could be declared, but city information couldn't be extracted from it.
* Constraints on the Executable UML models can either be represented as Object Constraint Language (OCL) or action language.
* Domains are represented as a Package, and bridges are represented as a Dependency.

Advantages of Executable UML

The intended advantages of Executable UML are as follows:
* Executable UML is a higher level of abstraction than 3GLs. This allows developers to develop at the level of abstraction of the application. [Mellor, S; Balcer, M: "Executable UML: A foundation for model-driven architecture", chapter 1.1 Raising the Level of Abstraction, Addison Wesley, 2002]
* The Executable UML allows for true separation of concerns. This significantly increases ease of reuse and lowers the cost of software development. This also enables Executable UML domains to be cross-platform and not tied to any specific programming language, platform or technology.
* Executable UML allows for translation of Platform-independent models into Platform-specific models. This eliminates the labor-intensive task of elaborating the PIM into a PSM.
* Executable UML enables easy exchange and reuse of knowledge by using the industry standard UML. Since the final model is a fully executable solution for the problem space, it can be valued as intellectual property.
* Executable UML closes the disconnect between documentation and programming language, as the models are a graphical, executable specification of the problem space that is compiled into a target implementation.
* Since actions are specified in action language, the automatic generation of implementation code from Executable UML models can leverage this complete, semantic-level knowledge of behavior to perform self-optimization, producing implementations that are far more efficient than other forms of code generation.

ee also

* Model-driven architecture
* Model Driven Engineering
* Shlaer-Mellor
* Unified Modeling Language
* Aspect (computer science)
* Software factory
* Code generation
* [http://www.ooatool.com/References.html Executable UML References]

Notes

References

*
*
*

External links

*
*
*
*
*
*
*
* [http://www.pathfindermda.com/MDAdemo.html "Animated Introduction - Executable UML through MDA Explained (4 minutes)"] at PathfinderMDA.com
*

Discussion Groups

*
*