Executable UML and SysML Workshop

Executable UML and SysML Ed Seidewitz

Agenda
Introduction
Foundation for Executable UML
Extensions for Executable SysML
Appendix: Specifying Execution Semantics

I. Introduction
Objectives
To motivate the need for standardized model execution.
To learn about the latest OMG standards related to model execution.

I. Introduction
Topics
Why Model?
Why Execute Models?
Why Standardize?
A Motivating Example

A. Why Model?
A model is a set of statements in some modeling language made about some system or domain.
Standard modeling languages: Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), Systems Modeling Language (SysML), Service Oriented Architecture Modeling Language (SoaML), etc.
A model may be used to describe a domain or system under study or to specify a (business, software and/or hardware) system to be built.
Descriptive models are generally used for analysis.
Specification models are generally used for engineering.
Models are intended to represent and communicate the results of analyses and proposals for new syntheses.
No model can represent everything – but, to be useful, a model must effectively promote general understanding and communicate important details.

B. Why Execute Models?
A model may specify the behavior of a system, that is, how the system interacts with external entities and changes its state over time.
A behavioral model is executable if it is complete enough that the specified behavior can be enacted or simulated by an automated execution tool.
Model execution may be used to:
Explore possible (desirable and undesirable) behaviors of a system
Validate the behavioral specification for a system
Actually act as the implementation of the system (particularly for business processes or software systems)

Modeling for Software Development
But…
It is hard to validate the correctness of the models before development.
The developers may not follow the models, without providing feedback.
It is hard to keep the models and development artifacts in sync during development (and maintenance).
How it usually works without executable models Developers provide feedback to the architects (maybe) Architects give models to developers Developers create artifacts based on the models (maybe) Architects create the models

Executable Modeling for Software Development The models are the source code. Using a standard-conforming UML modeling tool Using a standard-conforming UML execution tool How it works with executable models Architects validate the models by executing them in a simulated test environment Technologists specify the implementation platform The models are provisioned as executing artifacts on the target platform Architects create the models

Executable Modeling for System Engineering Using a standard-conforming SysML modeling tool Using a standard-conforming SysML execution tool
Execution artifacts could include:
System behavior
Timing
Statistics
Models can include both hardware and software components.
Hardware and software engineers develop components to satisfy the requirements.
Test engineers develop the test environment to verify the requirements.
System engineers analyze, simulate and validate the system design, and allocate requirements to components. System engineers create the models

C. Why Standardize?
Semantic interoperability and consistency across modeling and execution tools requires standardization
UML model execution tools are available, but UML execution semantics have not previously been precisely standardized.
Mentor Graphics BridgePoint
Kennedy-Carter xUML
Rational Rose Real Time and Rhapsody
Kabira Fluency
System engineering model execution tools are available, but have not previously provided a complete, standardized modeling capability
Vitech CORE Enhanced Functional Flow Block Diagrams (EEFBDs)
OMG standards are now filling these gaps
Unified Modeling Language (UML)
Systems Modeling Language (SysML)
Executable UML Foundation (fUML)
UML Action Language (Alf)

Unified Modeling Language (UML)
The Unified Modeling Language (UML) is a graphical language for modeling the structure, behavior and interactions of software, hardware and business systems, standardized by the Object Management Group (OMG).
UML Version 1.1 (first standard) – November 1997
UML Version 2.0 – August 2005
UML Version 2.3 (current standard) – September 2009 (Beta)
UML Version 2.4 – May 2010 (planned)
UML Version 2.5 (spec simplification) – December 2010 (planned)

Systems Modeling Language (SysML)
The Systems Modeling Language (SysML) is a general-purpose modeling language for systems engineering applications that supports the specification, analysis, design, and verification and validation of a broad range of complex systems. These systems may include hardware, software, information, processes, personnel, and facilities.
SysML is a specialized usage or profile of UML.
It is the result of a collaborative effort between OMG and the International Council on System Engineering (INCOSE).
SysML Version 1.0 – September 2007
SysML Version 1.1 – November 2008
SysML Version 1.2 Beta 2 – August 2009

Executable UML Foundation (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.
OMG RFP for the Semantics of a Foundational Subset for Executable UML Models – Issued April 2005
fUML Version 1.0 Beta 1 – November 2008
fUML Version 1.0 Beta 2 – September 2009
fUML Version 1.0 Beta 3 (finalized) – February 2010

UML Action Language (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.
OMG RFP for Concrete Syntax for a UML Action Language – Issued September 2008
Two initial submissions – August 2009
Joint revised submission – February 2010
Second revised submission – May 2010 (planned)

D. A Motivating Example
Simplification of the Hybrid SUV Sample Problem from Annex B of the SysML Specification.
Example behavioral models (using only standard UML without SysML extensions at this point)
State machines
Activities
The goal: automated execution and analysis

Hybrid SUV 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/

“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.

“Provide Power” Activity Other actions provide various data and computational functions.

“Proportion Power” Activity Full executability requires complete specification of all behavior and computation. However, 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.)

The Goal: Automated Analysis

II. Foundation for Executable UML
Objectives
To understand the intent of the fUML standard.
To provide an overview of fUML as the foundational language for executable UML models.
To understand how models are given executable semantics.

II. Foundation for Executable UML
Topics
Executable UML Foundation Standard
The fUML Subset
Foundation Model Library

A. Executable UML Foundation Standard
Submitters and Supporters
Objectives
Key Components
Semantics
Conformance
Semantics of a Foundational Subset for Executable UML Models

Submitters
CARE Technologies
International Business Machines
Kennedy Carter
Lockheed Martin
Mentor Graphics
Model Driven Solutions
Supporters
U.S. National Institute of Standards and Technology
88Solutions Corporation
CEA LIST/LISE
NASA Jet Propulsion Laboratory
Submitters and Supporters (Foundation)

Submitters and Supporters (Action Language)
Submitters
Model Driven Solutions
Mentor Graphics
88solutions Corporation
No Magic
International Business Machines
Visumpoint
Supporters
Ericsson AB

Objectives
To enable a chain of tools that support the construction, verification, translation, and execution of computationally complete executable models based on a foundational subset of UML.
To provide a general and standardized facility for specifying the structural and behavioral semantics of MOF-based modeling languages. Also, the same mechanisms can be used to define the semantics of domain-specific stereotypes defined in profiles as well as the concepts of languages other than UML.

Key Components
Foundational UML Subset (fUML) – A computationally complete subset of the abstract syntax of UML (Version 2.3)
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”

Semantics Composite Structure Semantics Complete Activity Model Semantics State Machine Semantics 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.

Conformance
Fundamental aspects
Syntactic Conformance. A conforming model must be restricted to the abstract syntax subset defined for fUML.
Semantic Conformance. A conforming execution tool must provide execution semantics for a conforming model consistent with the semantics specified for fUML.
Levels (parallel for syntax and semantics)
L1. Kernel, BasicBehaviors, Communications, Loci (semantics only)
L2. IntermediateActivities, BasicActions, IntermediateActions
L3. CompleteStructuredActivities, ExtraStructuredActivities, CompleteActions

B. The fUML Subset
Activities
Actions
Structure
Asynchronous Communication

i. Activities
Activities and Parameters
Actions and Flows
Textual Notation
Tokens
Offers
Control Nodes
Structured Nodes

Activities and Parameters An activity is a specification of behavior as the coordinated execution of subordinate actions, using a control and data flow model. An activity may have input, output and return parameters . The parameters have corresponding activity parameter node on the boundary of the diagrammatic representation of an activity.

Actions and Flows An action is a fundamental unit of executable behavior within an activity. A pin is an activity node that either accepts input to or provides output from an action. An object flow provides a path for passing objects or data. A control flow specifies the sequencing of actions. An activity diagram is a graph structure consisting of activity nodes connected by activity edges.

Textual Notation activity DoSomething(in input: Integer, out output Integer): Integer { output = A(input); return B(); } Alf behavioral notation maps to fUML activity models. The semantics of the Alf notation is defined by its mapping to fUML

Tokens a = DoSomething(1, b); A token is a container for an object, datum or locus of control that may be present at an activity node. The activity is invoked with an argument of 1 for its input parameter. An object token with a value of 1 is placed on the input activity parameter node. The object token flows to the input pin of action A along the object flow. Action A fires and produces an object token on its output pin. The object token flows to the output activity parameter node along the object flow. When it is done, action A produces a control token, which flows to action B along the control flow. Action B accepts the control token and fires, producing an object token on its output pin. The object token flows to the output activity parameter node along the object flow. Values on the output activity parameter nodes are copied to the output arguments.

Offers An output pin offers its tokens to the targets of all outgoing object flows. A single token can only flow to one target. If two competing targets are both ready to accept an offer for the same token, it is indeterminate which will get the token. Note: fUML semantics do not guarantee “liveliness” or “fairness” in the execution of actions competing for tokens. Actions with no control constraints execute concurrently. This means that they may execute in parallel – or they may execute sequentially in any order.

Fork and Join Nodes order = 'Create Order'(); @parallel { 'Fulfill Order'(order); 'Invoice Order'(order); } 'Close Out Order'(order); A fork node copies the tokens it is offered, and offers a copy on each outgoing flow. A join node waits for a token to be offered on all incoming flows and then offers tokens on its outgoing flow. In the Alf textual notation, forks and joins are implicit in the parallel block notation. Note: Alf does not actually provide any notation for competition for tokens on output pins. A fork node is always inserted for multiple flows out of any output pin.

Control Nodes An initial node generates a single control token. A merge node passes on any tokens it receives. A decision node routes tokens based on a decision input value. An activity final node terminates the activity when it receives a token. A control node is an activity node used to coordinate the flow of (the offers for) tokens between other nodes. Note: This construction is necessary so a “card” token is available for each iteration. Note: Since the decision node “gates” control flow, it must be provided with an incoming control token.

Structured Nodes card = 'Select Credit Card'(); do { charge = 'Create Credit Card Charge'(card); if ('Check Charge Approval'(charge)) { declined = false; 'Notify Customer of Approval'(charge); } else { declined = true; 'Notify Customer of Denial'(charge); } } while (declined); A structured node is an activity node used to group subordinate nodes into a control structure. An loop node iterates the execution of its body while a condition is true. By default, the condition is tested after execution of the body. A conditional node executes one clause or another based on the result of a test (or tests). Inputs to the loop node initialize loop variables available across all iterations of the loop. Note: There is no normative UML graphical notation for loop or conditional nodes.

Expansion Regions 'Get Outstanding Orders'(customer) -> select order ('Is Delinquent?'(order)) -> iterate order ('Refer for Collection'(order)); An expansion region is used to apply subordinate actions on all members of an input collection A parallel expansion region applies nested behavior concurrently to all collection elements. An iterative expansion region applies nested behavior sequentially to all collection elements. Alf provides specialized notation that maps to typical uses of expansion regions.

ii. Actions
Invocation Actions
Object Actions
Structural Feature Actions
Link Actions
NOTE: Some of these actions will be discussed in more detail later.

Invocation Actions
Call Behavior
Calling an activity
Calling a primitive behavior
Call Operation
Send Signal
Accept Event
PlaceOrder(customer, product) Max(throttle, limit) count + quantity order.addProduct(product, quantity) vehicle.EngageBrake(pressure) accept (signal: EngageBrake)

Object Actions
Value Specification
Create Object
Destroy Object
Test Identity
Read Self
Read Extent
Read Is Classified Object
Reclassify Object
1 true "Hello" new Order() order.destroy() order == myOrder name != customerName this Order.allInstances() vehicle instanceof Car car hastype Hatchback reclassify order from PendingOrder to ClosedOrder

Structural Feature Actions
Read Structural Feature
Add Structural Feature Value
Remove Structural Feature Value
Clear Structural Feature Value
order.customer order.lineItems->add(item) order.lineItems->remove(item) order.card = null

Link Actions
Read Link
Create Link
Destroy Link
Clear Association
Owns->select person (house=>thisHouse) Owns->add(person=>jack, house=>newHouse) Owns->remove(person=>jack, house=>oldHouse) Owns->clear(jack)

iii. Structure
Structural and Behavioral Models
Classes
Associations

Structural and Behavioral Models
A structural model (e.g., a class model) specifies the relevant instances in a domain that may exist at any one point in time.
Structural semantics define how a structural model constrains allowable instances.
A behavioral model (e.g., an activity model) specifies behavior over time
Behavioral semantics define how a behavioral model changes the state of instances over time.

Classes
Attributes
Data Types
Primitive Types
Operations and Methods
Structural Semantics
Behavioral Semantics
A class is a classifier of objects that persist in the extent of the class, with an identity that is independent of the value of their attributes at any one time.

Classes and Attributes A class may have attributes whose types are primitive, data types or other classes. A referential attribute, whose type is a class, is conventionally notated as an association with a class-owned association end . A bidirectional association results in corresponding referential attributes on both associated classes.

Data Types A data type is a classifier of transient data values whose identity is based on the values of their attributes. Data types may have attributes , but not operations.

Primitive Types
From UML 2 Auxiliary Constructs
Boolean
Integer
UnlimitedNatural
String
To be added for Alf
Bit strings
Real/floating point
Fixed point (?)

Classes: Operations and Methods An operation specifies a behavior that may be synchronously invoked on an instance of a class. A method defines that actual behavior that is invoked.

Classes: Structural Semantics Structural semantics specify how a structural model constrains allowable instances. Objects are instances of classes with values for each attribute. Class-owned association ends are structural features with values, like attributes. fUML does not actually give semantics to an association with class-owned ends, only to the ends as structural features. Note: fUML does provide “reified” semantics for associations that own their own ends, as will be discussed later.

Classes: Behavioral Semantics
Creating an Order
Adding a Line Item
Canceling an Order
Behavioral semantics specify how a behavioral model changes the state of instances over time.

Creating an Order order = new Order (customer, today) Before After @create public Order (customer: Customer, in datePlaced: Date) { this.datePlaced = datePlaced; this.totalAmount = new Money(dollars=>0, cents=>0); this.customer = customer; this.customer.orders->add(this); } A new object is created and the constructor operation is invoked. The constructor initializes the new order’s attribute values… … and adds the order to the customer’s list.

Adding a Line Item Before After order.addProduct (product, 2) public addProduct (in product: Product, in quantity: Integer) { lineItem = new LineItem(product, quantity); this.lineItems->add(lineItem); this.totalAmount = MoneyFunctions::Add (this.totalAmount, lineItem.amount); } The method for the operation creates a new line item object… The addProduct operation is invoked on an existing Order object. … adds the new object to the list of line items for the order… … and updates the total order amount.

Canceling an Order Before After order.cancel() @destroy public cancel() { this.customer.orders->remove(this); } A destructor operation is invoked, after which the order object is destroyed. Because line items are aggregated by composition, they are destroyed, too. References to the destroyed object must be explicitly removed.

Associations
Classes and Associations
Structural Semantics
Behavioral Semantics
An association is a classifier whose instances are links that relate other instances.

Classes and Associations An association (that owns its ends) is a classifier of persistent links between the associated classes, which exist in the extent of the association.

Associations: Structural Semantics Links are now semantic instances of the indicated associations. Structural semantics specify how a structural model constrains allowable instance models.

Associations: Behavioral Semantics
Creating an Order (revised)
Canceling an Order (revised)
Behavioral semantics specify how a behavioral model changes the state of instances over time.

Creating an Order (revised) order = new Order (customer, today) Before After @create public Order (customer: Customer, in datePlaced: Date) { this.datePlaced = datePlaced; this.totalAmount = new Money(dollars=>0, cents=>0); Customer_Order->add(customer, this); } A single action creates a bidirectional link.

Canceling an Order (revised) Before After order.cancel() @destroy public cancel() { } A destructor operation is invoked, after which the order object is destroyed. Links in which the destroyed object participates are now also automatically destroyed.

iv. Asynchronous Communication
Signals and Receptions
Classifier Behaviors
Asynchronous Behavior

Signals and Receptions A signal is a classifier whose instances may be communicated asynchronously. A reception is a declaration of the ability to receive a signal. A signal may have attributes that represent transmittable data. More than one class can receive the same signal.

Classifier Behaviors An active class is one that has a classifier behavior. Only active class may receive signals. A classifier behavior is an autonomous behavior started when an active class is instantiated.

Asynchronous Behavior accept (submission: SubmitCharge); card = submission.card; do { new CreditCardCharge(card, this); accept (response: ChargeApproved) { declined = false; this.customer.ChargeApproved(response.charge); } or accept (response: ChargeDeclined) { declined = true; this.customer.ChargeDeclined(response.charge); } while (declined); The order object accepts a signal to submit a charge. The order object creates a new credit card charge object, which begins its asynchronous behavior. Note: UML semantics require a separate action to start the behavior of a new object. However, Alf notation for creating an active class maps to both create and start object behavior actions. The order object accepts a signal from the charge object that the charge is approved. The order object sends a signal to the customer that the charge is approved.

C. Foundational Model Library
Primitive Behaviors
Boolean Functions
Integer Functions
Unlimited Natural Functions
String Functions
Basic Input and Output
Common Classes
Channels
Reading and Writing Lines
Hello World

Boolean Functions Converts x to a Boolean value. Pre: (lower(x) = “true”) or (lower(x) = “false”) Post: if lower(x) = “true” then result = true else result = false endif Note: The notation “lower(x)” above is not intended to be an invocation of a Foundation Model Library primitive behavior but, rather, is intended to denote that value of the string x with any uppercase letters converted to the corresponding lowercase letters. ToBoolean(x: String): Boolean[0..1] Converts x to a String value. Post: if x then result = “true” else result = “false” endif ToString(x: Boolean): String True if x is false, or if x is true and y is true. Post: result = Not(x) Or (x And y) Implies(x: Boolean, y: Boolean): Boolean True is x is false. Post: if x then result = false else result = true endif Not(x: Boolean): Boolean True if both x and y are true. Post: if x then result = y else result = true endif And(x: Boolean, y: Boolean):Boolean True if either x or y is true, but not both. Post: result = (x Or y) And Not(x And y) Xor(x: Boolean, y: Boolean): Boolean True if either x or y is true. Post: if x then result = true else result = y endif Or(x: Boolean, y: Boolean): Boolean Description Function Signature

Integer Functions Converts x to an Integer value. Pre: x has the form of a legal integer value ToInteger(x: String): Integer[0..1] Converts x to an UnlimitedNatural value. Pre: x >= 0 Post: ToInteger(result) = x ToUnlimitedNatural(x: Integer): UnlimitedNatural[0..1] Converts x to a String value. Post: ToInteger(result) = x ToString(x: Integer): String True if x is greater than or equal to y. Post: result = (x = y) Or (x > y) >=(Integer, Integer): Boolean True if x is less than or equal to y . Post: result = (x = y) Or (x < y) <=(Integer, Integer): Boolean True if x is greater than y. Post: result = Not(x <= y) >(x: Integer, y: Integer): Boolean True if x is less than y. <(x: Integer, y: Integer): Boolean The minimum of x and y. Post: if x <= y then result = x else result = y endif Min(x: Integer, y: Integer): Integer The maximum of x and y. Post: if x >= y then result = x else result = y endif Max(x: Integer, y: Integer): Integer The result is x modulo y. Post: result = x – (x Div y) * y Mod(x: Integer, y: Integer): Integer The number of times that y fits completely within x. Pre: y<>0 Post: if (x * y) >= 0 then ((result * y) <= x) And ((result+1) * y) >x) else ((Neg(result) * y) <= Neg(x)) And ((Neg(result)+1) * y) > Neg(x)) endif Div(x: Integer, y: Integer): Integer[0..1] The absolute value of x. Post: if x < 0 then result = Neg(x) else result = x endif Abs(x: Integer): Integer The value of the multiplication of x and y. Post: if y < 0 then result =Neg (x * Neg(y)) else if y = 0 then result = 0 else result = (x * (y-1)) + x endif endif *(x:Integer, y:Integer): Integer The value of the subtraction of x and y. Post: result + y = x -(x: Integer, y: Integer): Integer The value of the addition of x and y. +(x: Integer, y: Integer): Integer The negative value of x. Neg(x: Integer): Integer Description Function Signature

Unlimited Natural Functions Converts x to an Integer value. Pre: (x has the form of a legal integer value) Or (x = “*”) Post: if x = “*” then result = unbounded else result = ToUnlimitedNatural(ToInteger(x)) ToUnlimitedNatural(x: String): Integer[0..1] Converts x to an Integer value. Pre: x <> unbounded ToInteger(x: UnlimitedNatural): Integer[0..1] Converts x to a String value. The value “unbounded” is represented by the string “*”. Post: ToUnlimitedNatural(result) = x ToString(x: UnlimitedNatural): String True if x is greater than or equal to y. Post: result = (x = y) Or (x > y) >=(UnlimitedNatural, UnlimitedNatural): Boolean True if x is less than or equal to y . Post: result = (x = y) Or (x < y) <=(UnlimitedNatural, UnlimitedNatural): Boolean True if x is greater than y. Post: result = Not(x <= y) >(x: UnlimitedNatural, y: UnlimitedNatural): Boolean True if x is less than y. Every value other than “unbounded” is less than “unbounded”. <(x: UnlimitedNatural, y: UnlimitedNatural): Boolean The minimum of x and y. Post: if x <= y then result = x else result = y endif Min(x: UnlimitedNatural, y: UnlimitedNatural): UnlimitedNatural The maximum of x and y. Post: if x >= y then result = x else result = y endif Max(x: UnlimitedNatural, y: UnlimitedNatural): UnlimitedNatural Description Function Signature

String Functions The substring of x starting at character number lower , up to and including character number upper. Character numbers run from 1 to Size(x). Pre: (1 <= lower) And (lower <= upper) And (upper <= Size(x)) Substring(x: String, lower: Integer, upper: Integer): String[0..1] The number of characters in x. Size(x: String):Integer The concatenation of x and y . Post: (Size(result) = Size(x) + Size(y)) And (Substring(result, 1, Size(x)) = x) And (Substring(result, Size(x)+1, Size(result)) = y) Concat(x: String, y: String):String Description Function Signature

Common Classes

Channels

Reading and Writing Lines activity ReadLine (out errorStatus: Status[0..1]): String { return StandardIntputChannel.allInstances().readLine(status); } activity WriteLine (in value: String, out errorStatus: Status[0..1]) { StandardOutputChannel.allInstances().writeLine(result, status); }

Hello World activity Hello() { WriteLine("Hello World!"); }

III. Extensions for Executable SysML
Objectives
To understand how the semantic specification for a UML profile like SysML can be built on the fUML foundation.
To provide an overview of some of the key semantic extensions required for SysML.

III. Extensions for Executable SysML
Topics
SysML Semantics
Streaming
Timing
Blocks and Partitions
State Machines

A. SysML Semantics Composite Structure Semantics Complete Activity Model Semantics State Machine Semantics Non-Executable Model Semantics Interaction Model Semantics Foundational Semantics SysML also defines a profile consisting of stereotypes used to tag standard UML model elements to give them SysML-specialized meaning. SysML is base on a UML subset that does not include all of fUML (e.g., it does not include structured activity nodes), but it includes capabilities not in fUML (e.g., composite structure, state machines, streaming, etc.) UML for SysML

Building on the Foundation
There are two main ways to build on the semantic foundation provided by fUML.
Translate higher-level constructs into equivalent fUML models.
For example, provide semantics for state machines by specifying how to translate them into equivalent fUML activity models.
Extend the fUML execution model to directly specify the semantics of higher-level constructs.
For example, extend the fUML specification for behavior invocation and action pins to define the semantics of stream parameters.

B. Streaming
Streaming is a property of a behavior parameter that gives the behavior access to from its invoker while the behavior is executing.
Multiple values may arrive through a streaming input parameter during a single behavior execution, not just at the beginning.
Multiple values may be posted to a streaming output parameter during a single behavior execution, not just at the end.

Execution without Streaming … [execute] Activity ProvidePower completed. [addToken] node = out drivePower [addToken] node = out drivePower [addToken] node = out transModeCmd [receiveOffer] node = drivePower [fire] Output activity parameter node drivePower... [addToken] node = drivePower [removeToken] node = out drivePower [addToken] node = drivePower [removeToken] node = out drivePower [receiveOffer] node = transModeCmd [fire] Output activity parameter node transModeCmd... [addToken] node = transModeCmd [removeToken] node = out transModeCmd [execute] Activity Accelerate... [run] Node MeasureVehicleConditions is enabled. [run] Node PushAccelerator is enabled. [run] Sending offer to node MeasureVehicleConditions. [fire] Action MeasureVehicleConditions... [execute] Activity MeasureVehicleConditions... … [execute] Activity MeasureVehicleConditions completed. [addToken] node = out vehCond [receiveOffer] node = ProvidePower [run] Sending offer to node PushAccelerator. [receiveOffer] node = PushAccelerator [fire] Action PushAccelerator... [addToken] node = out accelPosition [receiveOffer] node = ProvidePower [addToken] node = in accelPosition [removeToken] node = out accelPosition [addToken] node = in vehCond [removeToken] node = out vehCond [fire] Action ProvidePower... [execute] Activity ProvidePower... output parameter 'drivePower' has 2 value(s) value[0] = Reference to (Object_@130be8c: GasPower throttle = 6) value[1] = Reference to (Object_@12df081: ElecPower current = 3) output parameter 'transModeCmd' has 1 value(s) value[0] = Reference to (Object_@108d3eb: TransmissionModeCommand) The execution of the activity is shown by its execution trace. Based on the sample activity in Annex B.4.8.1 of the SysML Specification

Execution with streaming … [fire] Action ProvidePower... [execute] Activity ProvidePower... … [addToken] node = out drivePower [receiveOffer] node = drivePower [fire] Output activity parameter node drivePower... [addToken] node = drivePower [removeToken] node = out drivePower output parameter 'drivePower' posts 1 value(s) value[0] = Reference to (Object_@130be8c: GasPower throttle = 6) … [addToken] node = out transModeCmd [receiveOffer] node = transModeCmd [fire] Output activity parameter node transModeCmd... [addToken] node = transModeCmd [removeToken] node = out transModeCmd output parameter 'transModeCmd' posts 1 value(s) value[0] = Reference to (Object_@108d3eb: TransmissionModeCommand) … … [addToken] node = out drivePower [receiveOffer] node = drivePower [fire] Output activity parameter node drivePower... [addToken] node = drivePower [removeToken] node = out drivePower output parameter 'drivePower' posts 1 value(s) value[0] = Reference to (Object_@12df081: ElecPower current = 3) ProvidePower is still executing at this point…

C. Timing
Timing constraints model requirements for how behaviors execute over time.
A time constraint specifies that some event is required to happen within a given time interval.
A duration constraint specifies that the duration between two events must be within a given duration interval.

Execution with timing [fire] Action MeasureVehicleConditions… [execute] Activity MeasureVehicleConditions… … [addToken] node = out vehCond … [fire] Action PushAccelerator... [execute] Activity PushAccelerator… … [addToken] node = out accelPosition … [fire] Action ProvidePower... [execute] Activity ProvidePower... … [addToken] node = out drivePower A duration constraint on the duration between the firing of the action and the placing of tokens on its output pin. 2 sec 1 sec 3 sec Duration t = 0 t = 2 t = 2 t = 3 t = 3 t = 6 Sequential execution t = 0 t = 2 t = 0 t = 1 t = 2 t = 5 Parallel execution

Timing: Additional Considerations
Duration ranges
The constraint on a duration may be that it is within a certain range, rather than exactly equal to a given value.
Probability distribution
A Monte Carlo simulation may select the duration of an action execution on each run to be a random value within a constrained duration range, with some given probability distribution.
Local clocks
The flow of time is modeled by adding the concept of a clock to the fUML execution model.
However, rather than a single global clock, there maybe a number of local clocks that define time coordinates that flow at different rates than each other.
The base fUML execution semantics do not depend on any specific model of time.

D. Blocks and Partitions
In SysML, a block is a modular unit of system description.
SysML blocks are based on UML classes, possibly with composite structure.
An activity partition is a grouping of nodes within an activity that share some common characteristic.
An activity may be partitioned such that the behavior grouped in each partition is allocated to a specific block, which is responsible for carrying out that behavior.
The overall behavior modeled by the full activity then emerges from the interaction between the blocks to which various partitions of the activity have been allocated.

Allocating Activities to Blocks Flows across partitions define interfaces between blocks

Allocated Block Structure An internal block diagram shows the composite structure of the Power Subsystem. Each component block has behavior as allocated from the activity model. Connections between flow ports on the blocks are derived from flows that cross partition boundaries.

Blocks and Partitions: Considerations
Execution semantics for SysML blocks and ports
The semantics of allocation of activities to blocks
The formal relationship between activity object flows and block flow ports

E. State Machines
A state machine abstracts system behavior into a finite number of states and the transitions between those states.
Behavior may be triggered as the effect of a transition or on entry, on exit or while in a state.
State machine semantics are described in detail in the UML Superstructure specification, but this is not formalized.
State machine semantics have been formalized by Harel and others, but these formalizations have not been standardized for UML.
Basic state machine semantics can also be understood by translations to equivalent activity semantics, as formalized in fUML.

Appendix: Specifying Execution Semantics
Background
Models
Metamodeling and Semantics
Denotational Mapping
Approach
Semantics of Values
Semantics of Behavior
Execution Semantics and Base Semantics
Execution Environment

Models A model makes statements in a modeling language about a system under study. First order statements “ There is a person whose name is Jack.” ” There is a house. The person is the owner of the house.” Second order statements “ Every person has a name.” “ Some people own houses.” UML Instance Model UML Class Model

Metamodeling and Semantics X : anX anX X.java "instance of" Class InstanceSpecification : InstanceSpecification : Class +classifier "interpretation" <<instanceOf>> "interpretation" <<instanceOf>> "interpretation" "interpretation" <<instanceOf>> +classifier "interpretation" “ representation"
References
Ed Seidewitz, “What Models Mean,” IEEE Software, September/October 2003.
Ed Seidewitz, “What do models mean?”, OMG document ad/03-03-31.
M1 M0 M2 M1 “ interpretation” “ interpretation”

Denotational Mapping evaluate(specification: ValueSpecification): Value Abstract Syntax Element (Representation) Semantic Model Element (Interpretation)

Abstract Syntax: Value Specifications

Semantics: Values

Representation: Instance Model

Interpretation: Instance Model j = evaluate(v)

Semantics: Extensional Values There are concepts in the semantic model that have no explicit representation in the abstract syntax.

Abstract Syntax/Semantics: Behavior

Abstract Syntax: Activities

Semantics: Activities Additional semantic concepts have specifically to do with dynamic behavior.

Model: Simple Activity

Representation: Simple Activity

Interpretation: Simple Activity Execution (1)

Interpretation: Simple Activity Execution (2)

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 (to be) specified axiomatically using PSL.

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

http://www.slideshare.net	12
http://www.linkedin.com	3
http://www.lmodules.com	1

Executable UML and SysML Workshop

by Ed Seidewitz

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 16

Statistics

Executable UML and SysML Workshop Presentation Transcript