KERML_ — Time and space life/slice/portion modeling patterns are missing

Clause 7.3.4.2 (Feature Declaration) and 8.3.3.3.3 (Feature) say

Portion features are composite features where the values cannot exist without the whole, because they are the “same thing” as the whole. (For example, the portion of a person's life when they are a child cannot be added or removed from that person's life.)

isPortion : Boolean
Whether the values of this Feature are contained in the space and time of instances of the domain of the Feature and represent the same thing as those instances.

and Clause 9.2.4.1 (Occurrences Overview) includes an extended description of time and space modeling in occurrences. But the specification does not explain how to model things (objects and performances) at specific times or places, versus over time or space. For example, cars are driven by one person at a time, but potentially many people over time. How should these multiplicities be specified? See other examples in comments on KERML-204.

Add the concept of variable features

This resolution introduces the concept of "variable features", which are features of occurrences whose values may vary over time. This is specified semantically by making the domain of a variable feature (i.e., its featuring type) the snapshots of its owning type, rather the owning type itself. Therefore, a variable feature can have different values on different snapshots of an occurrence, effectively "varying over time". The multiplicity of a variable feature is relative to each snapshot, rather than to the life of the occurrence.

A variable feature is notated in the concrete syntax using the new keyword var.

// An instance of a Vehicle is a Life by default.
struct Vehicle {
    // This feature has a single value for the Vehicle's life.
    //  It is not a feature of its timeslices or snapshots.
    feature id : VehicleId [1];

    // This feature can have a different single value on each snapshot of a Vehicle.
    var mileage : Distance [1];
}

A feature that is specified as variable can, nevertheless, be further specified as constant, meaning that it does not actually change its value over the duration of its featuring occurrence (this replaces the previous concept of "readonly"). This can be useful for asserting that a feature has values that are the same over only some of the time an occurrence exists, even though it could potentially vary at other times.

struct Vehicle {
    feature id : VehicleId [1];
    var mileage : Distance [1];

    portion parked :> timeSlices [*] {
        // When a Vehicle is parked, its mileage does not change.
        const :>> mileage;
    }
}

Updates to the abstract syntax to achieve these semantics include the following.

1. Add property isVariable to Feature. (isReadonly is renamed to isConstant.)
2. Remove the Featuring superclass of FeatureMembership and TypeFeaturing. Instead of FeatureMembership being a kind of Featuring, it implies TypeFeaturing in two different cases.
   • If isVariable = false, then FeatureMembership implies a TypeFeaturing relationship from its ownedMemberFeature to its owningType. This duplicates the current semantics for FeatureMembership.
   • If isVariable = true, then FeatureMembership implies a TypeFeaturing relationship from its ownedMemberFeature to a Feature representing the snapshots of its owningType. This Feature is an ownedRelatedElement of the implied TypeFeaturing, and it is constructed to redefine Occurrences::Occurrence::snapshots and be featured by the owningType of the FeatureMembership. This achieves the semantics of variable features.
3. Add operation isCompatibleWith to Type and Feature. For a non-Feature Type, isCompatibleWith is the same as specializes. A Feature, however, isCompatibleWith another Feature not only if it specializes the other Feature, but also if the two Features have a common redefinedFeature and the first Feature is accessible from a featuringType of the other Feature. This allows the snapshots featuringType of one variable Feature to be considered to semantically specialize the similar featuringType of another variable Feature, for the purposes of validation, without there having to be an actual Specialization relationship between them.

This resolution also resolves the following related issues:

• KERML_-47 Read only, misleading keyword, metaproperty name
• KERML_-154 Space and time slice descriptions are the same
• KERML_-159 n>2-ary link ends not readonly