Reasons for TOSCA derivation and refinement rules Calin

Reasons for TOSCA derivation and refinement rules Calin Curescu 2020 -02 -04

Reasons — For the designer: — To build a readable and intuitive type profile — Where derived types extend existing types in an intuitive way: — add new properties/attributes — modify existing definitions in an “expected” way: — set the type to a derived type — add new constraints but not take old away — For the TOSCA language — Allowing a derived node type to stand in for a base node type in — selection — substitution — Emphasizing the cross-template usage, as only in this case we deal with templates that — are defined at different time-points — have different editing and maintenance restrictions

Selection and Substitution — Selection — A node instantiated in another template should stand in for an “abstract” node in this template — The get functions should work as if the node is of the base type — The capabilities from the base type should exist and work as if the node is of the base type — The interface operations and notifications from the base type should exist — The requirements from the base type should exist — Substitution — Same as the requirements for the selection — In addition the properties of the abstract node of the base type should be enough to be able to provide the relevant inputs to the substitution template — This is not usually true — Proposal: to add a new list form for the “type” keyword in the substitution_mapping section, that allows to specify a set of types that this template can substitute — E. g: [ego. Databse, ego. database. SW]

The capabilities of a derived node — A capability defines a “capability signature” of a node — For a node of a derived type to stand in for a node of a base type — Its capabilities should ”include” the capabilities of the base type — And the node should be identified as providing the capabilities of the base node type to a matching requirement — So we have 2 possibilities: — The “capability” keyword in the requirement definition may match a capability of a derived type — Then a derived type of a node can refine the existing capabilities to their derived types — The “capability” keyword in the requirement definition is strict, matching only the specified type — Then a derived type of a node cannot touch (i. e. refine) the existing capabilities, — Note: in both cases we may add new capabilities when deriving a new node type