Appendix D. Frequently Asked Questions (FAQ)

1. What's new or different in KerML/SysML2 compared to UML2?

2. What is the new terminology of "definitions and usages" about?

3. What Is the Temporal Semantics of Multiplicities?

4. Do objects persist or happen over time?

5. Why do KerML/SysML2 not support a general concept of events?
6. Is a predicate-logical semantics preferable over an operational one?
7. Why does a feature specialize its range?

1. What's new or different in KerML/SysML2 compared to UML2?

This question is answered in Section 5.2.

2. What is the new terminology of "definitions and usages" about?

SysML2 defines a new terminology of "definitions and usages" for referring to the general pattern that features may be named by the same name (typically in lowercase) as the classifier defined as their range. For instance, the feature engine : Engine is considered a usage of the definition of the classifier Engine. In this way, the term usage becomes a synonym of the term feature, and the term definition becomes a synonym of the term classifier (allowing to say that "a part usage p1 is defined by the part definition P1" instead of "a part feature p1 is typed by the part type P1").

For instance, in the following example, we have an attribute def DrivingState, declaring a complex data type to be used as the range of one or more attributes, and a part def Engine, both used in the attribute usage attribute drivingState and the part usage part eng within the part def Vehicle:

attribute def DrivingState {
  attribute gearSetting : Integer;
  attribute acceleratorPosition : Real;
}
part def Engine;
part def Vehicle {
  attribute drivingState : DrivingState;
  part eng : Engine;
}

The SysML2 spec claims that the "definitions and usages" terminology facilitates reuse in different contexts. The goal of introducing this new terminology is to improve the usability of SysML. But is this really the case?

It seems confusing, at least for software engineers, to call the definition of a (complex) data type, like DrivingState, an "attribute definition". Rather, the term "attribute definition" normally refers to a definition of an attribute as a data-valued property within a class definition. So, what is normally considered an attribute definition, is called an "attribute usage" in SysML2, while what is called an "attribute definition" in SysML2, is normally considered a data type definition.

For item (or part/action/etc.) type definitions, it seems to make sense, and to improve usability, calling them simply "item (part/action/etc.) definitions" But then, does this also hold for calling an item (part/action/etc.) property/feature definition an "item (part/action/etc.) usage"? And while speaking of a property of a property (or a feature of a feature) is still intelligible, does this also hold for "a usage of a usage"?

There may be an issue of having different backgrounds in different engineering communities. While for software engineers, the terms "type/class definition" and "property definition", as well as the concept that a property/feature is typed by a data type or class, are quite familiar, this may not be the case for other kinds of engineers. Possibly, the goal of the SysML submission team for introducing the "definitions and usages" terminology was to improve the usability of SysML for non-software (such as aerospace/automotive/etc.) engineers. But it can be doubted if this goal has been achieved.

3. What Is the Temporal Semantics of Multiplicities?

KerML multiplicities are special features of types. In the case of classifiers, they allow constraining their number of basic instances. In the case of features, they allow constraining the number of their values, as stated in [KerML 8.4.4.12.1]:

For a Feature, the cardinality is the number of values of the Feature for any specific featuring instance (where duplicate features are included in the count, if the Feature is non-unique).

However, the KerML spec does not state if these cardinalities (the number of basic classifier instances or the number of feature values) are taken at a time, in the sense of snapshot cardinalities, or over time, in the sense of history cardinalities. This distinction, which is also discussed in the section Participation Associations of the book Object Event Modeling and Simulation, has been proposed by (Tauzovich 1991). It has also been raised as an issue for KerML by Conrad Bock [KERML-306].

In the following Object Event class model from OEM&S, a library user participates in (1) zero or more book lending activities over time, and (2) at most one book lending activity at a time.

We'll discuss the issue here only for feature multiplicities. But our discussion and its conclusions also apply to multiplicities of classifiers.

It seems that, by default, the multiplicities of object type features should be interpreted as snapshot multiplicities, while the multiplicities of action type features should be interpreted as history multiplicities. Consider the following example models that illustrate this insight.

Our first example model declares an object type (or "structure") Hotel with two attributes (or data-valued features) and one action step (or action-valued feature):

struct Hotel {
  feature name[1]: String;
  feature rooms[1..*]: Room;
  step rentHotelRoom[*] : RentHotelRoom;
}

What is the intended meaning of the multiplicities 1 and 1..* specified for the features Hotel::name and Hotel::rooms? Do they constrain the cardinalities of the features' value sets at a time, that is, their snapshot cardinality, or rather the cardinality of the features' value sets over time, that is, their history cardinality? In the first case, a hotel must have exactly one name and at least one room at a time. In the second case, a hotel must have exactly one name and at least one room over time, implying that it must not change its name over time and may have no name and no rooms at certain time instants.

For an attribute like Hotel::name, it seems to be clear that the intended meaning of its multiplicity is that it constrains its snapshot cardinality. The same holds for the object-valued feature Hotel::rooms.

But what about the action-valued feature Hotel::rentHotelRoom? For this feature it's not as obvious as for the others if its multiplicity is intended to refer to snapshot or to history cardinalities. Both readings make sense: (1) a hotel may perform zero or many rentHotelRoom actions at a time; (2) a hotel may perform zero or many rentHotelRoom actions over time.

The ambiguity could be resolved by stipulating the snapshot interpretation as the default reading and introduce a new notation (e.g., by prefixing them with "H") for designating history multiplicities, assuming the multiplicity zero-or-more (*) as the default history multiplicity.

Unfortunately, it turns out that a default interpretation would have to be context-dependent, as it would have to be snapshot multiplicities for features of object types, as in the case of Hotel above, and history multiplicities for features of action types, as in the following example of a RentHotelRoom action type (or "behavior") with four action steps:

behavior RentHotelRoom {
  step bookRoom[1] : BookRoom;
  step checkIn[0..1] : CheckIn;
  step charge[1] : Charge;
  step checkOut[0..1] : CheckOut;
}

Here, unlike in the case of object types, the intended meaning is that the action steps' multiplicities constrain the history cardinality, and not the snapshot cardinality, of the step concerned. For instance, a rent-hotel-room action hast exactly one bookRoom step and at most one checkIn step over (its life-) time.

What about data- and object-valued features of action types, e.g., if RentHotelRoom would have an attribute rentalNo and an object-valued feature customer, both with a multiplicity of exactly-one? Is it again not obvious if the multiplicity of these features is intended to refer to snapshot or to history cardinalities? Clearly, the intended reading is that a rent-hotel-room action has exactly one rentalNo and exactly one customer at a time, and not over time. So, unlike for object types, for action types it holds that while multiplicities for action steps suggest a default reading as history multiplicities, multiplicities for data- and object-valued features suggest a default reading as snapshot multiplicities.

Consequently,

1. KerML needs to be extended by adding the conceptual distinction between snapshot multiplicities and history multiplicities (and a suitable syntax for designating these different kinds of multiplicities).
2. It has to be decided if a context-dependent default reading, as discussed above, can be supported for allowing a simpler (undesignated) notation.

4. Do objects persist or happen over time?

This question is answered in Appendix C.

5. Why do KerML/SysML2 not support a general concept of events?

T.B.D.

6. Is a predicate-logical semantics preferable over an operational one?

The formal semantics of KerML's core concepts (types, classifiers and features) is defined in the form of an OWL-style (Tarskian) model-theoretic semantics. Since all other KerML and SysML2 concepts are defined in terms of KerML's core concepts and predefined library elements, the model-theoretic semantics is extended to all of them. For instance, a SysML "action" is defined as a feature the range of which specializes the predefined classifier Performance, and, consequently, also behavors/processes do have a model-theoretic semantics (and not an operational one).

Relative to a given interpretation, classifiers are essentially interpreted, like unary predicates, as a set of individuals from the universe of the interpretation, while features are essentially interpreted, like binary predicates, as binary relations that subset the Cartesian product of their domain and their range. In fact, due to KerML's support of ordered and non-unique features, and due to its adoption of the (puzzling) semantic postulate that features specialize their range, the formal semantics is more complicated.

T.B.D.

7. Why does a feature specialize its range?

KerML/SysML2 allow for nested feature/attribute definitions (features of features) with a contextualized semantics that requires that a feature specializes its range. E.g., the feature Person::income, the extent of which are all ordered pairs (p,i) where p denotes a person and i denotes a positive integer representing the income of p, would be a subtype of Integer, such that any pair (p,i) would be an instance of Integer.

Explanation by Jim Rhyne (Thematix Partners LLC):

In the example used in the document I referenced, "Car" has an owned feature "rollsOn" with co-domain "Wheel". "Wheel" has an owned feature "rotateAround" with co-comain "Hub". "Hub" has owned feature "rimFix" with co-domain "LockLugBolt".  Because this is a composition, the co-domain of "rimFix" is not the set of all "LockLugBolts" but the set of "LockLugBolts" "rimFixed" by "Hubs" that "Wheels" "rotateAround" where "Wheels" are "rolledOn" by "Cars".

This can be represented in a logic language like OWL by defining restriction classes based on the owned feature chain. So, the restriction class "LockLBHub" is the set of "Hubs" whose "rimFix" is some "LockLugBolt". Then "LockLBWheel" is the set of "Wheels" whose "rotateAround" is some "LockLBHub". Finally "LockLBCar" is the set of "Cars" that "rollsOn" some "LockLBWheel".

Think about duplicating this kind of structure for all of the parts of a car and you begin to see the problem about expressiveness.

These subassemblies are reusable. "LockLBWheel" can be reused for "Truck".

But throw variants into this kind of representation and there is a combinatorial explosion of such restriction classes in multiple part hierarchies.

The invention was to transform the M0 model from individuals to sequences of individuals, e.g. (car, wheel, hub, lock lug bolt) is an individual in the co-domain of "rimFixed". Semantically, the co-domain is all of the composition paths that lead to some "LockLugBolt". But, for technical reasons, the co-domain also includes (lock lug bolt) for those individual lock lug bolts in the 1-tail of the sequences beginning with car.

This transformation of the interpretation function eliminates the need to define restriction classes in the syntax; they are logically implied by the owned feature structure. A classifier program might elect to undo this transformation and use DL resolution to determine consistency and establish classifications. But in 2019 Conrad Bock and colleagues at NIST used a "satisfiability modulo theory" solver to demonstrate classification and consistency directly for a subset of KerML.

The transformation also allows the KerML model to add owned features to an owned feature without causing a ripple that updates the definitions of the restriction classes. For example, one might add a "torqueSpecification" owned feature to the "rimFix" owned feature. At the M0 level, this merely adds a number value to the end of the sequences for "rimFix: and these new sequences become the interpretation of "torqueSpecification".

Because "rimFix" has this interpretation, it is also a "Classifier" because it classifies these sequences. Under the interpretation function, model elements that are Classifiers become sequences of length 1, where Features are always interpreted as sequences of length > 1. Thus "rimFix" classifies a subset of "LockLugBolt" because its interpretation contains some of the length 1 sequences that are in the interpretation of "LockLugBolt".

The result is that the semantics of KerML corresponds more directly to the abstract and concrete syntax of the language and does not require the generation of a large number of restriction classes to enable a conventional satisfiability technique.