Executable UML and SysML Workshop

February 2010

Copyright © 2010 Data Access Technologies, Inc.(Model Driven Solutions)

A division of Data Access Technologies, Inc.

Executable UML and SysML

Ed Seidewitz

Page 2 Copyright © 2010 Data Access Technologies, Inc.

(Model Driven Solutions)February 2010

Agenda

I. Introduction

II. Foundation for Executable UML

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

A. Why Model?

B. Why Execute Models?

C. Why Standardize?

D. 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)



Developers provide feedback to the architects(maybe)

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 modelsArchitects give models to developers

Developers create artifacts based on the models(maybe)

Architects create the models



Executable Modeling for Software Development

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

The models are the source code.

Using a standard-conforming UML

modeling tool


modeling tool


execution tool


execution tool

How it works with executable models



• Hardware and software engineers develop components to satisfy the requirements.

• Test engineers develop the test environment to verify the requirements.

Executable Modeling for System Engineering

System engineers analyze, simulate and validate the system design, and allocate

requirements to components.

Using a standard-conforming SysML

modeling tool


modeling tool


execution tool


execution tool

System engineers create the models

Execution artifacts could include:• System behavior• Timing• Statistics

Execution artifacts could include:• System behavior• Timing• Statistics

Models can include both hardware and

software components.

Models can include both hardware and

software components.



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.

A state machine abstracts system behavior into a finite number of states.

The system is modeled as having discrete transitions between the states.

The system is modeled as having discrete transitions between the states.

A transition may trigger further system behavior…A transition may trigger further system behavior…

…or system behavior may be dependent on the current state/

…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 activity specifies behavior as the coordinated execution of a set of subordinate actions.

An action in one activity may call another activity.

An action in one activity may call another activity.

Data and control flow between the various actions.

Data and control flow between the various actions.



“Provide Power” Activity

Other actions provide various data and computational functions.

Other actions provide various data and computational functions.



“Proportion Power” Activity

Full executability requires complete specification of all behavior and computation.

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

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




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.




Topics

A. Executable UML Foundation Standard

B. The fUML Subset

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

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

2. 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”



Composite Structure

Semantics

Composite Structure

Semantics

Complete Activity Model

Semantics


Semantics

State Machine Semantics


Semantics

Non-Executable

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

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

Interaction Model

Semantics

Foundational SemanticsFoundational Semantics

fUML operational semantics are specified as an execution model written in fUML itself.

fUML operational semantics are specified as an execution model written in fUML itself.

Base SemanticsBase Semantics

The base semantics of the subset of fUML used in the execution

model are specified using formal logic.

The base semantics of the subset of fUML used in the execution

model are specified using formal logic.



Conformance

• Fundamental aspects1. Syntactic Conformance. A conforming model must be restricted to

the abstract syntax subset defined for fUML.2. 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, IntermediateActionsL3. CompleteStructuredActivities, ExtraStructuredActivities,

CompleteActions



B. The fUML Subset

i. Activities

ii. Actions

iii. Structure

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

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.

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.

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.

An object flow provides a path for passing objects or data.

A control flow specifies the sequencing of actions.

A control flow specifies the sequencing of actions.

An activity diagram is a graph structure consisting of activity nodes connected by activity edges.

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();}

activity DoSomething(in input: Integer, out output Integer): Integer { output = A(input); return B();}

Alf behavioral notation maps to fUML activity models.

Alf behavioral notation maps to fUML activity models.

The semantics of the Alf notation is defined by its mapping to fUML

The semantics of the Alf notation is defined by its mapping to fUML



Tokens

a = DoSomething(1, b);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.

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.

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.

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.

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.

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.

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.

Action B accepts the control token and fires, producing an object token on its output pin.



Values on the output activity parameter nodes are copied to the output arguments.

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.

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.

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.

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.

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);

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

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.

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.

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 NodesAn initial node generates a single control token.

An initial node generates a single control token.A merge node

passes on any tokens it receives.

A merge node passes on any tokens it receives.

A decision node routes tokens based on a decision input value.

A decision node routes tokens based on a decision input value. An activity final

node terminates the activity when it receives a token.

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.

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

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);

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.

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.

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.

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

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.

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.

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));

'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

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.

A parallel expansion region applies nested behavior concurrently to all collection elements.

An iterative expansion region applies nested behavior sequentially 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.

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

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

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.

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.

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.

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.

A method defines that actual behavior that is invoked.



Classes: Structural Semantics

Structural semantics specify how a structural model constrains allowable instances.

Structural semantics specify how a structural model constrains allowable instances.

Objects are instances of classes with values for each attribute.

Objects are instances of classes with values for each attribute.

Class-owned association ends are structural features with values, like attributes.

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.

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.

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.Behavioral semantics specify how a behavioral model changes the state of instances over time.



Creating an Order

order = new Order (customer, today)

Before After

@createpublic 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);}

@createpublic 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.

A new object is created and the constructor operation is invoked.

The constructor initializes the new order’s attribute values…

The constructor initializes the new order’s attribute values…

…and adds the order to the customer’s list.…and adds the order to the customer’s list.



Adding a Line Item

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

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 method for the operation creates a new line item object…

The addProduct operation is invoked on an existing Order object.

The addProduct operation is invoked on an existing Order object.

…adds the new object to the list of line items for the order…

…adds the new object to the list of line items for the order…

…and updates the total order amount.

…and updates the total order amount.



Canceling an Order

Before Afterorder.cancel()

@destroypublic cancel() { this.customer.orders->remove(this);}

@destroypublic 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.

Because line items are aggregated by composition, they are destroyed, too.

References to the destroyed object must be explicitly removed.

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

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.

Links are now semantic instances of the indicated associations.

Structural semantics specify how a structural model constrains allowable instance models.

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

@createpublic Order (customer: Customer, in datePlaced: Date) { this.datePlaced = datePlaced; this.totalAmount = new Money(dollars=>0, cents=>0);

Customer_Order->add(customer, this);}

@createpublic 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.A single action creates a bidirectional link.



Canceling an Order (revised)

Before Afterorder.cancel()

@destroypublic cancel() { }@destroypublic cancel() { }



Links in which the destroyed object participates are now also automatically 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 ReceptionsA signal is a classifier whose instances may be communicated asynchronously.

A signal is a classifier whose instances may be communicated asynchronously.

A reception is a declaration of the ability to receive a signal.

A reception is a declaration of the ability to receive a signal.

A signal may have attributes that represent transmittable data.

A signal may have attributes that represent transmittable data.

More than one class can receive the same signal.

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.

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.

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);

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 accepts a signal to submit a charge.

The order object creates a new credit card charge object, which begins its asynchronous behavior.

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.

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

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

Function Signature Description

Or(x: Boolean, y: Boolean): Boolean True if either x or y is true.Post: if x then result = true else result = y endif

Xor(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)

And(x: Boolean, y: Boolean):Boolean True if both x and y are true.Post: if x then result = y else result = true endif

Not(x: Boolean): Boolean True is x is false.Post: if x then result = false else result = true endif

Implies(x: Boolean, y: Boolean): Boolean True if x is false, or if x is true and y is true.Post: result = Not(x) Or (x And y)

ToString(x: Boolean): String Converts x to a String value.Post: if x then result = “true” else result = “false” endif

ToBoolean(x: String): Boolean[0..1] 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 endifNote: 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.



Integer FunctionsFunction Signature Description

Neg(x: Integer): Integer The negative value of x.

+(x: Integer, y: Integer): Integer The value of the addition of x and y.

-(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 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)) + xendif endif

Abs(x: Integer): Integer The absolute value of x.Post: if x < 0 then result = Neg(x) else result = x endif

Div(x: Integer, y: Integer): Integer[0..1] The number of times that y fits completely within x.Pre: y<>0Post: 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

Mod(x: Integer, y: Integer): Integer The result is x modulo y.Post: result = x – (x Div y) * y

Max(x: Integer, y: Integer): Integer The maximum of x and y.Post: if x >= y then result = x else result = y endif

Min(x: Integer, y: Integer): Integer The minimum of x and y.Post: if x <= y then result = x else result = y endif

<(x: Integer, y: Integer): Boolean True if x is less than y.

>(x: Integer, y: Integer): Boolean True if x is greater than y.Post: result = Not(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 or equal to y.Post: result = (x = y) Or (x > y)

ToString(x: Integer): String Converts x to a String value.Post: ToInteger(result) = x

ToUnlimitedNatural(x: Integer): UnlimitedNatural[0..1] Converts x to an UnlimitedNatural value.Pre: x >= 0Post: ToInteger(result) = x

ToInteger(x: String): Integer[0..1] Converts x to an Integer value.Pre: x has the form of a legal integer value



Unlimited Natural Functions


Max(x: UnlimitedNatural, y: UnlimitedNatural): UnlimitedNatural The maximum of x and y.Post: if x >= y then result = x else result = y endif

Min(x: UnlimitedNatural, y: UnlimitedNatural): UnlimitedNatural The minimum of x and y.Post: if x <= y then result = x else result = y endif

<(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 True if x is greater than y.Post: result = Not(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 or equal to y.Post: result = (x = y) Or (x > y)

ToString(x: UnlimitedNatural): String Converts x to a String value. The value “unbounded” is represented by the string “*”.Post: ToUnlimitedNatural(result) = x

ToInteger(x: UnlimitedNatural): Integer[0..1] Converts x to an Integer value.Pre: x <> unbounded

ToUnlimitedNatural(x: String): Integer[0..1] Converts x to an Integer value.Pre: (x has the form of a legal integer value) Or (x = “*”)Post:if x = “*” then result = unboundedelse result = ToUnlimitedNatural(ToInteger(x))



String Functions


Concat(x: String, y: String):String 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)

Size(x: String):Integer The number of characters in x.

Substring(x: String, lower: Integer, upper: Integer): String[0..1] 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))



Common Classes



Channels



Reading and Writing Lines

activity ReadLine (out errorStatus: Status[0..1]): String {

return StandardIntputChannel.allInstances().readLine(status);

}

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);

}

activity WriteLine (in value: String, out errorStatus: Status[0..1]) {

StandardOutputChannel.allInstances().writeLine(result, status);

}



Hello World

activity Hello() {

WriteLine("Hello World!"); }

activity Hello() {

WriteLine("Hello World!"); }




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.




Topics

A. SysML Semantics

B. Streaming

C. Timing

D. Blocks and Partitions

E. State Machines



Composite Structure

Semantics

Composite Structure

Semantics


Semantics


Semantics

A. SysML Semantics



Non-Executable

Model Semantics

Non-Executable

Model Semantics

Interaction Model

Semantics

Interaction Model

Semantics

Foundational SemanticsFoundational Semantics

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

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

SysML also defines a profile consisting of stereotypes used to tag

standard UML model elements to give them SysML-specialized meaning.

SysML also defines a profile consisting of stereotypes used to tag

standard UML model elements to give them SysML-specialized meaning.



Building on the Foundation

There are two main ways to build on the semantic foundation provided by fUML.

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

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



Based on the sample activity in Annex B.4.8.1 of the SysML Specification

…[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

Execution without Streaming[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.The execution of the activity is shown by its execution trace.



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 drivePoweroutput 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 transModeCmdoutput 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 drivePoweroutput 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

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 A duration constraint on the duration between the firing of the action and the placing of tokens on its output pin.

A duration constraint on the duration between the firing of the action and the placing of tokens on its output pin.



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 BlocksFlows across partitions define interfaces between blocks



Allocated Block StructureAn internal block diagram shows the composite structure of the Power Subsystem.

An internal block diagram shows the composite structure of the Power Subsystem. Each component block

has behavior as allocated from the activity model.

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.

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



ModelsA model makes statements in a modeling language about a system under study.A model makes statements in a modeling language about a system under study.

UML Instance Model

UML Class Model

First order statements

“There is a person whose name is Jack.”

”There is a house. The person is the owner of the house.”

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

Second order statements

“Every person has a name.”

“Some people own houses.”



Metamodeling and Semantics

X : anX

anXX.java "instance of"

Class InstanceSpecification

: InstanceSpecification: Class +classifier

"interpretation"

<<instanceOf>>

"interpretation"

<<instanceOf>>

"interpretation"

"interpretation"

<<instanceOf>>

+classifier

M1

M0

M2

M1

“interpretation”

“interpretation”"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.



Denotational Mapping

evaluate(specification: ValueSpecification): Value

Abstract Syntax Element

(Representation)

Abstract Syntax Element

(Representation)

Semantic Model Element

(Interpretation)

Semantic Model Element

(Interpretation)



Abstract Syntax: Value Specifications



Semantics: Values



Representation: Instance Model



Interpretation: Instance Model

j = evaluate(v)j = evaluate(v)



Semantics: Extensional Values

There are concepts in the semantic model that

have no explicit representation in the

abstract syntax.

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.

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))))

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

• 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