1 “UML compilation” A more formal approach for SysML 2.0 OMG SE DSIG – SysML roadmap meeting Cambridge MA - Sep 24, 2015 Yves BERNARD

Motivations  Potentially conflicting expectations on SysML 2.0. We would like the language to be –“Precise” (i.e. having formal semantics) –“Usable” (i.e. easy to learn, to operate, …) –“Efficient” (i.e. telling more with less)  Issue already solved by the software scientists: languages of the 3rd and 4th generation have the qualities listed above. They: –provide “high level” software concepts (from a software development point of view) –can be “compiled” (i.e. precisely translatable in machine language)  Approach suggested by fUML (cf. clause 7.1)  Could be an alternative to the usage of profiles which – as defined today - raise many practical problem. 2

Basic principle  Language definition –Abstract syntax definition in a true metamodel based on UML or fUML (TBD)  Semantics –The semantics of each SysML metaclass is constrained so that it can be fully defined as a construct of (f)UML metaclasses –Those constructs can be represented by UML::Collaborations and used as building blocks –A SysML model is then a high-level view of a model of which the semantics is fully defined by (f)UML  Notation –No constraint implies by the approach 3

Illustration with the “Allocation” concept  Concept definition Directed cross-association (mapping) of items from various structures or hierarchies of a user model.  Conceptual model 4 Allocate * 1..* from Constraint /allocatedFrom:AllocatedItem[*] /allocatedTo:AllocatedItem[*] Item to 1..1 * 0..1 impliedConstraint 0..1 > context Item::allocatedFrom : Set(Item) derive: Allocate.allInstances()->select(to = self).from->flatten() context Item::allocatedTo : Set(Item) derive: Allocate.allInstances()->select(from = self).to->flatten()

Allocate: as a design pattern 5 Allocate ConstraintItem from to impliedConstraint

Allocation: UML equivalent construct (transformation rule) 6 from:Dependency impliedConstraint:Constraint fromItem:NamedElement toItem:NamedElement to:Dependency supplier client UML_Allocate Allocate from to impliedConstraint

Pattern application  SysML  UML equivalent 7 ItemAItemB > ItemAItemB {true} to from traceability

Traceabilty  Possible solution: using a (single) UML stereotype 8 reference:SysMLElement[1] role: RoleKind[1] SysML > ItemAItemB > Allocate from to impliedConstraint ItemAItemB {true} tofrom > reference=“myAllocation” role=“impliedConstraint” > reference=“myAllocation” role=“to” > reference=“myAllocation” role=“from”

Illustration with the “Interruptible region” concept  Concept definition An Interruptible region is a group of ActivityNodes that supports termination of a portion of an Activity. It identifies as certain ActivityEdges as “interrupting” that have their source within the region and their target outside the region. When a token offered along one of those edge is accepted and traverses that edge, then the execution of all actions of the region is terminated.  Conceptual model 9 InterruptibleReg * 1..* ActivityEdgeActivityNode member * interrupting * source target 1 1 * *

Interruptible Region example UML/SysMLfUML A1 A2 A4 A3 A1 Call IntReg A4 A3 A2 A5 IntReg > P: IntRegInterrupt A3’ A2’ IntRegInterrupt > A2_Int A3_Int >

Interruptible region: view as a design pattern 11 InterruptibleReg ActivityNodeActivityEdge interrupting member * 1..*

Interruptible region: fUML equivalent construct (Simplified) 12 end:ActivityFinal interrupted:ActivityEdge intN:ActivityNode source target fUML_InterruptibleReg InterruptibleReg members interrupting activating:ActivityNode intE:ActivityEdge source target 1..* * IntReg:Activity call:CallBehaviorAction

Conclusions  Advantages of the “compilation” approach –The constraints applicable to UML profile are loosened –All the semantics already defined for UML can be reused –A SysML model can always be interpreted as a UML model –Provides both high-level concepts and precise semantics  Drawbacks –Significant refactoring of the specification –Vague or imprecise concept definitions are not supported Approach with clear benefits but also constraints which have to be understood and accepted. 13