Executable UML: Difference between revisions

Revision as of 10:10, 3 December 2023

Latest revision as of 05:38, 25 June 2025

(One intermediate revision by one other user not shown)

Line 1:

{{Short description|Software development method and a highly abstract software language}}

'''Executable UML''' ('''xtUML''' or '''xUML''') 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".<ref>Mellor and Balcer 2002</ref> The language "combines a subset of the UML ([[Unified Modeling Language]]) graphical notation with executable semantics and timing rules."<ref>Starr 2002, p. 3.</ref> The Executable UML method is the successor to the [[Shlaer–Mellor method]].<ref>G. O'Keefe (2006) "Dynamic Logic Semantics for UML Consistency" in: ''Model-Driven Architecture - Foundations and Applications: Second European Conference, ECMDA-FA 2006, Bilbao, Spain, July 10–13, 2006, Proceedings''. Arend Rensink eds. p. 124</ref>

Executable UML models "can be run, [[software testing|tested]], debugged, and measured for performance.",<ref>Starr 2002, p. 3.</ref> and can be [[compiler|compiled]] into a less abstract [[programming language]] to target a specific [[implementation]].<ref>Mellor and Balcer 2002, section 1.4.</ref> Executable UML supports [[model-driven architecture]] (MDA) through specification of [[platform-independent model]]smodels, and the [[Compiler|compilation]] of the [[platform-independent model]]smodels into [[platform-specific model]]s.<ref>Mellor and Balcer 2002, section 1.5.</ref><ref>Raistrick et al. 2004, sections 2.3.3 and 2.3.4.</ref>

== Overview ==

Executable UML is a higher level of [[abstraction (computer science)|abstraction]] than [[third-generation programming language]]s. This allows [[software developer|developer]]s to develop at the level of abstraction of the application.<ref>Mellor and Balcer 2002, section 1.1.</ref> The Executable UML aims for [[separation of concerns]]. This is supposed to increase ease of [[code reuse|reuse]] and to lower the cost of [[software development]]. This also enables Executable UML domains to be [[cross-platform]]. That means it is not tied to any specific programming language, platform or technology.

Executable UML also allows for translation of [[platform-independent model]]smodels (PIM) into [[platform-specific model]]s (PSM). The Executable UML method enables valuing the model as [[intellectual property]], since the model is a fully executable solution for the problem space.

Actions are specified in [[action (UML)|action language]]. This means that the automatic generation of implementation code from Executable UML models can be output in an optimized form.

Line 69 ⟶ 70:

[[Program optimization|Optimizing]] the ___domain models for target [[implementation]] reasons will reduce the level of [[abstraction (computer science)|abstraction]], adversely affect ___domain independence, and increase the cost of [[code reuse|reuse]]. In executable UML, [[optimization (computer science)|optimization]]s are done by the model [[compilation (programming)|compiler]] either automatically or through ''marking''. Marking allows specific model elements to be targeted for specific lower-level [[implementation]]s, and allows for broader architectural decisions, such as specifying that [[container (abstract data type)|collection]]s of objects should be [[implementation|implemented]] as a [[doubly linked list]].

In [[model-driven architecture|MDA]] terms, the model [[compilation (programming)|compiler]] creates the [[platform-specific model|PSM]]. The separation between the [[platform-independent model|PIM]] and [[platform-specific model|PSM]] in Executable UML disables the ability to [[Round-trip engineering|round-trip engineer]] the model, and deters modifications to the [[platform-specific model|PSM]].<ref>Mellor and Balcer 2002, chapter 9.</ref>

==Executable UML key aspects==