UML: Once More with Meaning


Published on

The Unified Modeling Language (UML) has arguably succeeded in becoming the most commonly used modeling notation for software development. But “modeling” in the software community seems largely to mean simply drawing pictures, either to represent the problem domain or to blueprint a solution, without a precise enough meaning to fully specify the functionality of the system being developed. As a result, the UML standard,S up to and including UML 2.4.1, do not define the semantics of UML models at all precisely.

Nevertheless, there has also long been an interest in models that are more precise, even to the extent that they may be executed in their own right. It has taken a while for this viewpoint to penetrate into the mainstream of UML usage. But there has been in a great deal of work in recent years toward the standardization of the formal semantics of UML models – the “meaning” behind the pictures: the Foundational UML (fUML) specification adopted in 2008; the Action Language for fUML (Alf), adopted in 2010; the UML 2.5 specification (which includes a semantics conformance point for the first time); and the Precise Semantics of UML Composite Structures.

This presentation reviews the state of this work and the implications in practice of bringing real meaning to UML.

Published in: Software, Technology, Education
1 Comment
  • Very nice presentation.
    However, I have noted a few discrepancies with regards to the early days of UML. I still have a document from OMG dated 1 September 1997 (UML Summary version 1.1; ad/97-08-03) that provides the following dates for the earliest versions:
    Draft version 0.8 of the 'Unified Method', the precursor to UML: October 1995
    [Objectory joined Rational in the fall of 1995]
    UML 0.9: June 1996
    UML 0.91: October 1996
    OMG issues an RFP for UML in 1996
    UML 1.0 from the 'UML Partners' was provided in January 1997 as a response to the OMG RFP. Other companies also submitted independent RFP responses.
    UML 1.1 was published in September 1997, unifying all RFPs.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

UML: Once More with Meaning

  1. 1. Copyright © 2013 Ivar Jacobson International SA. All rights reserved UML: Once More with Meaning Vienna University of Technology Ed Seidewitz 24 June 2013
  2. 2. UML Prehistory: Object-Oriented Analysis and Design (1) 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.
  3. 3. UML Prehistory: Object-Oriented Analysis and Design (2) 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.
  4. 4. Unified Modeling Language v1.x 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.
  5. 5. Unified Modeling Language v2.x 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 Latest formal version “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
  6. 6. Unified Modeling Language v2.5 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 2013 – UML 2.5 Finalized (planned) “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
  7. 7. Executable Modeling Before UML Before UML, there were already a number of approaches to modeling with precise, executable semantics. 1998, 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.
  8. 8. Foundational UML (fUML) 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 Formal (based on UML 2.3) 2012 – fUML 1.1 Beta (based on UML 2.4.1)
  9. 9. Composite Structure Semantics Complete Activity Model Semantics State Machine 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. 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.
  10. 10. fUML Key Components • 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”
  11. 11. Action Language for fUML (Alf) 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 Beta (based on UML 2.4.1 and fUML 1.1)
  12. 12. Alf Key Components • 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
  13. 13. Ordering Example: Class Model
  14. 14. Using Alf to Define a Method An operation specifies a behavior that may be synchronously invoked on an instance of a class. A method defines the actual behavior that is invoked.
  15. 15. Order: Classifier Behavior A state machine abstracts system behavior into a finite number of states. The system is modeled as having discrete transitions between the states. A transition may trigger further system behavior or system behavior may be dependent on the current state. Order is an active class whose classifier behavior is responsible for handling ordering functionality.
  16. 16. Using Alf to Define an Activity (1) An activity specifies behavior as the coordinated execution of a set of subordinate actions. An action in one activity may call another activity. Data and control flow between the various actions. Other actions provide various data and computational functions. Full executability requires complete specification of behavior and computation. This is often much more easy to specify using a textual notation.
  17. 17. Using Alf to Define an Activity (2) namespace Order::Order_Behavior; private import Utilities::Time::CurrentDate; private import Utilities::Currency::Add; activity EstablishCustomer(in checkOut: CheckOut) { this.lineItems = checkOut.items; Customer_Order.addLink(checkOut.customer, this); this.datePlaced = CurrentDate(); this.totalAmount = this.lineItems.amount->reduce Add; this.SubmitCharge(checkOut.card); }
  18. 18. 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.
  19. 19. The models are validated in a development/test environment The Goal: Programming in UML The models are deployed in a production environment Developers create fully executable models It’s just programming, only better! Developers iteratively execute, test and update the models
  20. 20. Implementations • fUML Implementations – Open Source Reference Implementation (Academic Free License 3.0) – Cameo Simulation Toolkit for MagicDraw from NoMagic – 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) – Alf for Papyrus Eclipse UML Tool (Ongoing)
  21. 21. Ongoing Work • fUML Version 1.2 • Alf Version 1.1 • Precise Semantics of UML Composite Structures • Additional “Precise Semantics” RFPs – State machines – Interactions – Complete activities/process modeling
  22. 22. Addendum: Specifying Execution Semantics • Execution Model • Semantics of Values • Semantics of Behavior • Execution Semantics and Base Semantics • Execution Environment
  23. 23. Execution Model • Visitor Pattern – Evaluations of Value Specifications – Executions of Behaviors – Activations of Activity Nodes • Strategy Pattern – Polymorphic Dispatching SVP – Event Dispatching SVP – Nondeterminism 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. 24. Denotational Mapping evaluate(specification: ValueSpecification): Value Abstract Syntax Element (Representation) Semantic Model Element (Interpretation)
  25. 25. Abstract Syntax: Value Specifications
  26. 26. Semantics: Values
  27. 27. Representation: Instance Model
  28. 28. Interpretation: Instance Model j = evaluate(v)
  29. 29. Semantics: Extensional Values There are concepts in the semantic model that have no explicit representation in the abstract syntax.
  30. 30. Abstract Syntax/Semantics: Behavior
  31. 31. Abstract Syntax: Activities
  32. 32. Semantics: Activities Additional semantic concepts have specifically to do with dynamic behavior.
  33. 33. Model: Simple Activity
  34. 34. Representation: Simple Activity
  35. 35. Interpretation: Simple Activity Execution (1)
  36. 36. Interpretation: Simple Activity Execution (2)
  37. 37. 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).
  38. 38. Execution Environment • Locus – Manages extents – Provides pre-instantiated discoverable services • Executor – Evaluates value specifications – Executes behaviors (synchronously) – Starts behaviors or active objects (asynchronously) • Execution Factory – Creates visitor objects – Registers strategies – Registers primitive types and primitive behaviors