Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

- A Unified View of Modeling and Prog... by Ed Seidewitz 478 views
- Programming in UML: An Introduction... by Ed Seidewitz 26305 views
- UML as a Programming Language by Ed Seidewitz 1984 views
- UML: Once More with Meaning by Ed Seidewitz 2561 views
- UML 2.5: Specification Simplification by Ed Seidewitz 7651 views
- Industrial and Academic Experiences... by Marco Brambilla 7902 views

845 views

Published on

UML as an Executable Modeling Language

Presented at the Vienna University of Technology

Published in:
Software

No Downloads

Total views

845

On SlideShare

0

From Embeds

0

Number of Embeds

27

Shares

0

Downloads

21

Comments

0

Likes

3

No embeds

No notes for slide

- 1. Unified Modeling Language as an Executable Modeling LanguageThis Time We Mean It Vienna University of Technology Ed Seidewitz 25 October 2016
- 2. We can model that!We can model that! OOAD orthodoxy (c. 1980s) Organize programs to model the basic concepts of the problem domain. Problem Programming languages (even OOPLs) are not particularly good as problem domain modeling languages. • Too much of a program must focus on implementation details. • As the program grows, the “big picture” gets lost. UML Prehistory Object-Oriented Analysis and Design (1) 2
- 3. We can model that!We can model that! Solution Use a graphical modeling notation for analysis and design. • “Model the problem domain” during analysis. • “Model the solution” in problem domain terms during design. • Use the solution model as a “blueprint” for coding. Consequence “Modeling” in the software community became drawing pictures, for problem domain representation and solution blueprinting. • Precise “meaning” was only to be found in the programs themselves. UML Prehistory Object-Oriented Analysis and Design (2) 3
- 4. We can model that!We can model that! Unified Modeling Language (UML) intended to “unify” the various OOAD graphical modeling languages of the early 1990s. 1995 – UML 0.9 by Booch, Rumbaugh and Jacobson (“3 amigos”) 1996 – UML 1.0 proposed by Rational 1997 – UML 1.1 adopted by Object Management Group (OMG) The intent of OMG standardization was primarily to allow syntactic interchange of models between tools. Unified Modeling Language v1.x 4
- 5. We can model that!We can model that! There was a hope to add semantic interoperability to the UML standard with UML 2. 1999 – UML 2.0 Request for Information (RFI) 2000 – UML 2.0 Requests for Proposal (RFPs) 2003 – UML 2.0 Adopted 2005 – UML 2.0 Finalized 2011 – UML 2.4.1 “However, the presence of numerous variation points in these semantics (and the fact that they are defined informally using natural language), make it impractical to define this as a formal compliance type, since the number of possible combinations is very large.” – UML Superstructure Specification, v2.0 – 2.4.1 Unified Modeling Language v2.x 5
- 6. We can model that!We can model that! The UML 2.5 specification document is reorganized to be “consumable” and to remove redundancy and correct inconsistencies. Primarily focused on semantics descriptions. 2008 – Future Development of UML RFI 2009 – UML Specification Simplification RFP (UML 2.5) 2012 – UML 2.5 Adopted 2015 – UML 2.5 Finalized (current version) “A tool demonstrating semantic conformance provides a demonstrable way to interpret UML semantics, e.g., code generation, model execution, or semantic model analysis.” – UML 2.5 Specification, Semantic Conformance Unified Modeling Language v2.5 6
- 7. We can model that!We can model that! Before UML, there were already a number of approaches to modeling with precise, executable semantics. 1988, 1991 – Shlear-Mellor Object-Oriented Analysis 1988, 1998 – Harel Statecharts 1994 – Real-Time Object-Oriented Modeling (ROOM) In 1998, Stephen Mellor came to an Object Management Group meeting for the first time, to talk about defining an action language for UML with precise semantics. Executable Modeling Before UML 7
- 8. We can model that!We can model that! Foundational UML (fUML) is an executable subset of standard UML that can be used to define, in an operational style, the structural and behavioral semantics of systems. 1998 – Action Semantics for the UML RFP 2003 – UML 1.5 with action semantics formalized 2003 – UML 2.0 adopted 2005 – Semantics of a Foundational Subset for Executable UML Models RFP 2008 – fUML 1.0 Beta (based on UML 2.2) 2010 – fUML 1.0 (based on UML 2.3) 2012 – fUML 1.1 (based on UML 2.4.1) 2016 – fUML 1.2.1 (based on UML 2.4.1) 2017 – fUML 1.3 (based on UML 2.4.1) 2018? – fUML 1.4 (based on UML 2.5) Foundational UML (fUML) 8
- 9. We can model that! Composite Structure Semantics State Machine Semantics Interaction Model Semantics fUML Scope Non- Executable Model Semantics The semantics of fUML provide the foundation for formally specifying the (execution) semantics of the rest of UML. Some areas of UML (e.g., use case and requirements models) may not be best formalized based on an executable semantics foundation. Complete Activity Model Semantics Foundational Semantics 9
- 10. We can model that!We can model that! • Foundational UML Subset (fUML) – A computationally complete subset of the abstract syntax of UML (Version 2.4.1) – Kernel – Basic object-oriented capabilities – Common Behavior – General behavior and asynchronous communication – Activities – Activity modeling, including structured activities (but not including variables, exceptions, swimlanes, streaming or other “higher level” activity modeling) • Execution Model – A model of the execution semantics of user models within the fUML subset • Foundational Model Library – Primitive Types – Boolean, String, Integer, Unlimited Natural – Primitive Behaviors – Boolean, String and Arithmetic Functions – Basic Input/Output – Based on the concept of “Channels” fUML Key Components 10
- 11. We can model that!We can model that! The Action Language for Foundational UML (Alf) is a textual surface representation for UML modeling elements with the primary of acting as the surface notation for specifying executable (fUML) behaviors within an overall graphical UML model. 2008 – Concrete Syntax for a UML Action Language RFP 2010 – Alf 1.0 Beta (based on UML 2.4 and fUML 1.0) 2013 – Alf 1.0.1 (based on UML 2.4.1 and fUML 1.1) 2017 – Alf 1.1 (based on UML 2.4.1 and fUML 1.3) 2018? – Alf 1.2 (based on UML 2.5 and fUML 1.4) Action Language for fUML (Alf) 11
- 12. We can model that!We can model that! • Concrete Syntax – A BNF specification of the legal textual syntax of the Alf language. • Abstract Syntax – A MOF metamodel of the abstract syntax tree that is synthesized during parsing of an Alf text, with additional derived attributes and constraints that specify the static semantic analysis of that text. • Semantics – The semantics of Alf are defined by mapping the Alf abstract syntax metamodel to the fUML abstract syntax metamodel. • Standard Model Library – From the fUML Foundational Model Library • Primitive Types (plus Natural and Bit String) • Primitive Behaviors (plus Bit String Functions and Sequence Functions) • Basic Input/Output – Collection Functions – Similar to OCL collection operations for sequences – Collection Classes – Set, Ordered Set, Bag, List, Queue, Deque, Map Alf Key Components 12
- 13. We can model that! A virtual machine based on concurrent UML activity flow semantics. The target for “compiled” models. Architecture for Executable UML Tooling fUML Execution Engine Model Development Environment Other Tools Target Platform Providing all the capabilities expected in a code-based IDE. In memory or via XMI transfer. Simulation, analysis, optimization, etc. 13
- 14. We can model that! Demo Example: Ordering
- 15. We can model that! OrderLineItem – Textual View
- 16. We can model that! OrderLineItem – getAmount operation
- 17. We can model that! OrderLineItem – After compilation
- 18. We can model that! OrderLineItem - Constructor
- 19. We can model that! Order – Textual representation
- 20. We can model that! Order – getAmount operation
- 21. We can model that! testOrder – Simple test driver
- 22. We can model that! Composite Structure Semantics Complete Activity Model Semantics State Machine Semantics Specifying Execution Semantics Non- Executable Model Semantics Interaction Model Semantics Foundational Semantics fUML operational semantics are specified as an execution model written in fUML itself. Base Semantics The base semantics of the subset of fUML used in the execution model are specified using formal logic. 22
- 23. We can model that! Execution Semantics and Base Semantics (forall (n a xa f xn) (if (and (ExecutableNode n) (buml:activity n a) (classifies a xa f) (property-value xa n xn f) (ipc:subactivity_occurrence-neq xn xa)) (forall (n a xal xa2 xn) (if (and (ExecutableNode n) (buml:activity n a) (classifies a xa1 f) (classified a xa2 f) (property-value xa1 n xn f) (property-value xa2 n xn f) (= (psl:root occ xa1) (psl:root occ xa2)))) Execution Semantics (Operational Specification) Base Semantics (Axiomatic Specification) • Foundational UML (fUML) semantics are specified operationally as a UML Model written in Base UML (bUML). • Base UML semantics are specified axiomatically using Common Logic/Process Specification Language (PSL). 23
- 24. We can model that!We can model that! • Visitor Pattern – Evaluations of Value Specifications – Executions of Behaviors – Activations of Activity Nodes • Strategy Pattern – Polymorphic Dispatching SVP – Event Dispatching SVP – Nondeterminism Execution Model LiteralString LiteralString Evaluation evaluate() Activity Activity Execution execute() DecisionNode DecisionNode Activation run() receiveOffer() fire() Dispatch Strategy dispatch() GetNextEvent Strategy getNextEvent() Choice Strategy choose() FIFOGetNextE ventStrategy FirstChoice Strategy RedefinitionBased DispatchStrategy 24
- 25. We can model that! Execution Environment (1) 25 • Manages extents • Proves pre-instantiated discoverable services • Evaluates value specifications • Executes behaviors (synchronously) • Starts behaviors or active objects (asynchronously)
- 26. We can model that! Execution Environment (2) 26 • Creates visitor objects • Registers strategies • Registers primitive types and primitive behavior execution “prototypes”
- 27. We can model that!We can model that! • fUML Implementations – Open Source Reference Implementation (Academic Free License 3.0) http://fuml.modeldriven.org – Moka for Papyrus Eclipse UML Tool https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution – Cameo Simulation Toolkit for MagicDraw from NoMagic https://www.magicdraw.com/simulation – Advanced Modeling | UML Simulation and Execution (AM|USE) by LieberLieber for Enterprise Architect from Sparx Systems • Alf Implementations – Open Source Reference Implementation (GNU General Public License 3.0) http://alf.modeldriven.org – Alf UI Interation for Papyrus Eclipse UML Tool (incubation) (install from within Papyrus) – Alf Plugin for MagicDraw (beta) (install from within MagicDraw) Implementations 27
- 28. Addendum: Operational Semantics Overview 28
- 29. We can model that! Denotational Mapping evaluate(specification: ValueSpecification): Value Abstract Syntax Element (Representation) Semantic Model Element (Interpretation) 29
- 30. We can model that! Abstract Syntax: Value Specifications 30
- 31. We can model that! Semantics: Values 31
- 32. We can model that! Representation: Instance Model 32
- 33. We can model that! Interpretation: Instance Model j = evaluate(v) 33
- 34. We can model that! Semantics: Extensional Values There are concepts in the semantic model that have no explicit representation in the abstract syntax. 34
- 35. We can model that! Abstract Syntax/Semantics: Behavior 35
- 36. We can model that! Abstract Syntax: Activities 36
- 37. We can model that! Semantics: Activities Additional semantic concepts have specifically to do with dynamic behavior. 37
- 38. We can model that! Model: Simple Activity 38
- 39. We can model that! Representation: Simple Activity 39
- 40. We can model that! Interpretation: Simple Activity Execution (1) 40
- 41. We can model that! Interpretation: Simple Activity Execution (2) 41

No public clipboards found for this slide

Be the first to comment