KERML — End feature multiplicity textual notation

Background

Consider the flowing simple structure:

struct Car {
  feature carEngine : Engine[1];
  feature carWheels : Wheel[4];
  
  connector carDrive : Drive
    from carEngine to carWheels;
}

The feature multiplicities in this model require that each instance of Car have exactly one Engine and exactly four Wheels. The model also includes a usage of the following association:

assoc Drive {
  end feature driveEngine : Engine[0..1];
  end feature driveWheel : Wheel[2..4];
} 

The Drive end multiplicities require that every Engine is connected to 2 to 4 Wheels, while every Wheel is connected to at most 1 Engine. But each instance of the association Drive is a link between a single engine and a single wheel. The multiplicities of the end features of Drive are thus interpreted differently than those of the features of Car (but consistently with how UML and SysML v1 interpret association end multiplicity). Rather than constraining the values of the end features themselves, the end multiplicities constrain the number of links allowed when the value at one end is held fixed: if a value is given for the driveEngine, then there must be two to four Drive links from that driveEngine to different Wheels; if a value is given for the driveWheel, then there must be zero or one instances between that driveWheel and an Engine.

For example, consider the following usage of Car that explicitly binds all the Car features:

feature myCar : Car {
  feature :>> carEngine = myEngine;
  feature :>> carWheels =
    (leftFrontWheel, rightFrontWheel, leftRearWheel, rightRearWheel);
  
  connector :>> carDrive =
    ( Drive(myEngine, leftRearWheel),
      Drive(myEngine, rightRearWheel)
    );
}

The connector ends of the connector carDrive inherit their end multiplicities from the ends of the association Drive. The above model explicitly binds the carDrive connector to two Drive values:

1. a connection from myEngine to leftRearWheel

2. a connection from myEngine to rightRearWheel

This satisfies the multiplicity constraint for Drive, because the carEngine is linked to two Wheels (presuming leftRearWheel and rightRearWheel are different) and each carWheel is connected to at most one Engine.

Concern

While the semantic interpretation of the multiplicity of end features is different than that of non-end features, the same textual notation is used in both cases. This can be confusing, making it seem like, e.g., each instance of Drive has 0 or 1 driveEngine and 2 to 4 driveWheels, which would be the case for regular features but not for end features.

Proposal

Change the textual notation so that the multiplicity of an end feature is placed immediately after the end keyword, rather than in the usual place for a feature declaration. For example:

assoc Drive {
  end [0..1] feature driveEngine : Engine;
  end [2..4] feature driveWheel : Wheel;
}

This would not require a change in the abstract syntax.