Executable UML: Difference between revisions

Revision as of 14:45, 27 March 2015

Latest revision as of 05:38, 25 June 2025

(30 intermediate revisions by 23 users 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-MellorShlaer–Mellor method]] 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 [[Compilercompiler|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|developersdeveloper]]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 [[Platformplatform-independent model]]smodels (PIM) into [[Platformplatform-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 [[Actionaction (UML)|action 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 target [[implementation]]. They are also intended to be [[human-readable]].

Line 14 ⟶ 15:

== Executable UML building blocks ==

A [[application software|system]] is composed of multiple subject matters, known as ''domains'' in Executable UML terms. Executable UML is used to model a ___domain at the level of [[abstraction (computer science)|abstraction]] of its subject matter independent of implementation concerns. The resulting ___domain model is represented by the following elements:

* The ''___domain chart'' provides a view of the [[aspect (computer scienceprogramming)|___domain]] being modeled, and the dependencies it has on other domains.

* The ''class diagram'' defines the [[class (computer scienceprogramming)|classesclass]]es and class [[association (object-oriented programming)|associationsassociation]]s for the ___domain.

* The ''statechart diagram'' defines the [[Finitefinite-state State Machinemachine|statesstate]]s, 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 Chartchart===

Executable UML requires identification of the domains (also known as: [[aspect (computer scienceprogramming)|aspectsaspect]]s<ref>Mellor and Balcer 2002, section 3.4.</ref> or [[Concernconcern (computer science)|concern]]s) of the system. "Each ___domain is an autonomous world inhabited by conceptual entities"<ref>Mellor and Balcer 2002, p. 14.</ref> Each ___domain can be modeled 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 [[computer security|security]] ___domain model of various issues regarding system security (such as [[authentication]] and [[encryption]]).

Line 26 ⟶ 27:

* The [[data logging|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 [[platform (computing) platform|architecture]] ___domain model of the [[implementation|implemented]] of the Executable UML model on the system's [[computer hardware|hardware]] and [[computer software|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.

Line 46 ⟶ 47:

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.

===Statechart Diagramdiagram===

{{See also|Finite-state State Machinemachine|State diagram}}

Classes have lifecycles which are modeled in Executable UML with a [[state diagram|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 [[Moore machine|entry into that state]]. A procedure is composed of actions, which are specified in an action language.

===Action Languagelanguage===

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 the [[Shlaer-MellorShlaer–Mellor method]] method. Existing action languages are Object Action Language (OAL), Shlaer-MellorShlaer–Mellor Action Language (SMALL), Action Specification Language (ASL), Model Action Specification Language (MASL),<ref name="MASL Source">{{cite web |title=MASL is a Shlaer-Mellor dialect action language and structural modeling language.: xtuml/masl |url=https://github.com/xtuml/masl |publisher=xtUML |access-date=26 October 2019 |date=27 December 2018}}</ref> 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===

Once a ___domain is modeled, it can be [[software testing|tested]] independent of the target [[implementation]] by executing the model. Each ___domain can be [[verification and validation|verified and validated]] independent of any other ___domain. This allows [[software bug|errorserror]]s detected to be associated with the ___domain and independent of other system concerns.

[[static testing|Verification]] will involve such things as human [[peer review|review]] 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 UML [[Meta- (prefix)|metamodelmeta]]model.

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

Line 67 ⟶ 68:

In order to support execution on the target [[implementation]], the ___domain model must be translated into a less [[abstraction (computer science)|abstract]] form. This translation process is called ''model compilation''. Most model [[compilation (programming)|compiler]]s target a known [[programming language]], because this allows reuse of existing [[compiler]] technologies.

[[Program optimization (computer science)|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)|optimizationsoptimization]]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 [[Containercontainer (abstract data structuretype)|collectionscollection]]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 [[Platformplatform-specific model|PSM]]. The separation between the [[Platform-independent model|PIM]] and [[Platformplatform-specific model|PSM]] in Executable UML disables the ability to [[Round-trip engineering|round-trip engineer]] the model, and deters modifications to the [[Platformplatform-specific model|PSM]].<ref>Mellor and Balcer 2002, chapter 9.</ref>

==Executable UML Keykey Aspectsaspects==

Executable UML defines execution semantics for a subset of the UML. Key aspects of the Executable UML subset include the following:

* No support for implementation specific constructs, like aggregation and composition.<ref>Mellor and Balcer 2002, p. xxx.</ref>

Line 77 ⟶ 78:

* 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 typestype]]s 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 within the ___domain. e.g., a ''MailingAddress'' composite data type could be declared, but city information couldn't be extracted from it.

* [[Constraint (information theory)|ConstraintsConstraint]]s on the Executable UML models can either be represented as [[Object Constraint Language]] (OCL) or action language.

== fUML and ALF ==

The [[Object Management Group]] has recently standardized the [[fUML|Foundational UML (fUML)]]., fUMLwhich iswas strongly influenced by Executable UML, but {{em|[[fUML|Foundational UML (fUML)]] is a not the Executable UML that is covered in this article!}} See [[Talk:Executable_UML#Is_fUML_Executable_UML.3F|Discussion]].

Action Language for Foundational UML (ALF),<ref>{{Cite web|url=https://www.omg.org/spec/ALF/|title=Action Language for Foundational UML™ (ALF™)|website=www.omg.org|access-date=2016-12-21}}</ref> is a new standard action language proposedspecification by the [[Object Management Group]].

==See also==

* [[Aspect (computer scienceprogramming)]]

* [[Automatic_programming|Code generation(automaticAutomatic programming)]]

* [[Code_generation_(compiler)|Code generation (compiler)]]

* [[Model-driven architecture]] (MDA)

* [[I-OOA]]

* [[Model-driven architectureengineering]] (MDE)

* [[Shlaer–Mellor method]]

* [[Model-driven engineering|Model Driven Engineering]]

* [[Unified Modeling Language]] (UML)

* [[Shlaer-Mellor]]

* [[Unified Modeling Language]]

== Publications ==

* Gerry Boyd (2003) "[http://www.devx.com/enterprise/Article/10717 Executable UML: Diagrams for the Future]." published at ''devx.com'', February 5, 2003.

* Shayne Flint, and [[Clive Boughton]] (2003) "Executable/translatable UML and Systems Engineering." ''Practical Approaches for Complex Systems (SETE 2003)''.

* Shayne Flint, Henry Gardner, and [[Clive Boughton]] (2004). "[http://crpit.com/confpapers/CRPITV30Flint.pdf Executable/Translatable UML in computing education]." ''Proceedings of the Sixth Australasian Conference on Computing Education-Volume 30''. Australian Computer Society, Inc.

* {{cite book | author=H.S. Lahman| title=Model-Based Development: Applications | publisher=Addison-Wesley Professional | year=2011 | isbn=0-321-77407-8}}

* {{cite book | author=[[Stephen J. Mellor]] & Marc Balcer | title=Executable UML: A Foundation for Model-Driven Architecture | publisher=Addison Wesley | year=2002 | isbn=0-201-74804-5}} [http://www.informit.com/articles/article.aspx?p=28274 Chapter 1] online

* ''Executable and Translatable UML''

* {{cite web | url=http://www.embedded.com/story/OEG20030115S0043 | title=Executable and Translatable UML | accessdate=2006-04-25 | author=[[Stephen J. Mellor]] | publisher=embedded.com | year=2003 }}

* {{citeStephen webJ. |Mellor url=http://www.techonline.com/community/tech_topic/36794 |(2004), title=Introduction to Executable and Translatable UML | accessdate=2006-04-25 | author=[[Stephen J. Mellor]] | publisher=TechOnLine | year=2004 }}

* Stephen J. Mellor (2004), A Framework for Aspect-Oriented Modelling

* {{cite web | url=http://www.cs.iit.edu/~oaldawud/AOM/AOM2003/Stephen-AOSD.pdf | title=A Framework for Aspect-Oriented Modelling | accessdate=2006-04-25 | author=[[Stephen J. Mellor]] | format=PDF | publisher=Project Technology, Inc | year=2004 }}

* {{cite book | author=Chris Raistrick et al. | title=Model Driven Architecture with Executable UML | publisher=Cambridge University Press | year=2004 | isbn=0-521-53771-1|display-authors=etal}}

* {{cite book | author=Leon Starr | title=Executable UML:How to Build Class Models | publisher=Prentice-Hall | year=2002 | isbn=0-13-067479-6}}

==References==

{{reflist|230em}}

==External links==

* http://executableumlbook.com The official web site for "Executable UML: A Foundation for Model-Driven Architecture".

* {{cite web | url=http://tech.groups.yahoo.com/group/executableuml/ | title=executableuml Yahoo! Groups}}

* {{cite web | url=http://tech.groups.yahoo.com/group/ExecutableUMLTools/ | title=Executable UML Tools Yahoo! Groups}}

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

{{UML}}