copyright © 2013 ivar jacobson international sa. all rights reserved uml: once more with meaning...

Download Copyright © 2013 Ivar Jacobson International SA. All rights reserved UML: Once More with Meaning University of Maryland Model-Based System Engineering

If you can't read please download the document

Upload: terence-scott

Post on 17-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

  • Slide 1
  • Copyright 2013 Ivar Jacobson International SA. All rights reserved UML: Once More with Meaning University of Maryland Model-Based System Engineering Colloquium Ed Seidewitz 15 April 2013
  • Slide 2
  • UML Prehistory: Object-Oriented Analysis and Design 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. 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.
  • Slide 3
  • 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.
  • Slide 4
  • 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
  • Slide 5
  • 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
  • Slide 6
  • 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)
  • Slide 7
  • 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.
  • Slide 8
  • 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
  • Slide 9
  • 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)
  • Slide 10
  • 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
  • Slide 11
  • Hybrid SUV Example: Operational States 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/
  • Slide 12
  • Using Alf to Define a State Machine Behavior
  • Slide 13
  • Hybrid SUV Example: Accelerate Activity 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.
  • Slide 14
  • Hybrid SUV Example: Provide Power Activity Other actions provide various data and computational functions.
  • Slide 15
  • Using Alf to Specify an Action After a certain level of detail, it is much more convenient to use a textual rather than graphical notation (whether mathematical constraints or procedural action language.)
  • Slide 16
  • Using Alf to Define an Activity (1) The original Alf statements can then be preserved in a comment element stereotyped as a TextualRepresentation. Alf statements in the body of an opaque action may be compiled into an activity.
  • Slide 17
  • Using Alf to Define an Activity (2) namespace Hybrid SUV; private import Alf::Library::IntegerFunctions::Min; activity ProportionPower( in battCond: Integer, in accelPosition: Integer, in speed: Integer, out eThrottle: Integer, out gThrottle: Integer, out transModeCmd: TransModeCommand) { //@parallel { throttle = (accelPosition * battCond) / GetMaxBattLevel(); eThrottle = Min(throttle, GetMaxEThrottle()); gThrottle = Min(accelPosition - throttle, GetMaxGThrottle()); transModeCmd = new TransModeCommand(); transModeCmd.level = speed / GetTransModeConv(); }
  • Slide 18
  • The Goal: Automated Execution and Analysis
  • Slide 19
  • Hardware and software engineers develop components to satisfy the requirements. Test engineers develop the test environment to verify the requirements. The Goal: Model Based System Engineering System engineers analyze, simulate and validate the system design, and allocate requirements to components. Using standard- conforming modeling tools Using a standard- conforming model execution tools System engineers create the models Execution artifacts could include: System behavior, timing and statistics Execution artifacts could include: System behavior, timing and statistics Models can include both hardware and software components. Using standard-based model interchange
  • Slide 20
  • Implementations fUML Implementations Open Source Reference Implementation (Academic Free License 3.0) http://fuml.modeldriven.org http://fuml.modeldriven.org Cameo Simulation Toolkit for MagicDraw from NoMagic https://www.magicdraw.com/simulation https://www.magicdraw.com/simulation Advanced Modeling | UML Simulation and Execution (AM|USE) by LieberLieber for Enterprise Architect from Sparx Systems http://www.lieberlieber.com/model-engineering/amuse/product-overview/ http://www.lieberlieber.com/model-engineering/amuse/product-overview/ Alf Implementations Open Source Reference Implementation (GNU General Public License 3.0) http://alf.modeldriven.org http://alf.modeldriven.org Alf for Papyrus Eclipse UML Tool (Ongoing)
  • Slide 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