This is a one day workshop presentation, primarily on the new OMG Foundational UML specification for executable model semantics, but also discussing extensions for executable SysML (System Modeling Language) models.

1. Executable UML and SysML Ed Seidewitz

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

16. 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/

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

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

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

20. The Goal: Automated Analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

73. Common Classes

74. Channels

75. 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); }

76. Hello World activity Hello() { WriteLine(&quot;Hello World!&quot;); }

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

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

83. 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…

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

88. Allocating Activities to Blocks Flows across partitions define interfaces between blocks

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

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

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

96. Abstract Syntax: Value Specifications

97. Semantics: Values

98. Representation: Instance Model

99. Interpretation: Instance Model j = evaluate(v)

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

101. Abstract Syntax/Semantics: Behavior

102. Abstract Syntax: Activities

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

104. Model: Simple Activity

105. Representation: Simple Activity

106. Interpretation: Simple Activity Execution (1)

107. Interpretation: Simple Activity Execution (2)