Cardinality of Annotation.annotates

Can an Annotation specify only one annotated Classifier or more?

Pro 1:

• Works well for MPS, exceptions rare
• Available workaround for exceptional cases: Define a ConceptInterface with the appropriate features, have several Annotations implement that interface and annotate different targets.
• For Annotation A that annotates Concept C, A can also annotate all specializations of C. That provides sufficient flexibility.

Pro 1..*:

• Technically feasible

Decision: Annotation.annotates has a cardinality of 1.

Can we redefine features of extended Annotations?

Annotations specify their multiple and annotates features (#13).
If one Annotation extends another one, what happens to the values of these features?

multiple

Option 1: No Limits

classDiagram

class AnimalOwner {
  <<annotation>>
  multiple = true
}

class Trainer {
  <<annotation>>
  multiple = false
}

AnimalOwner <|-- Trainer

class RunningCoach {
  <<annotation>>
  multiple = true
}

Trainer <|-- RunningCoach

Pro:

• Flexibility

Con:

• Depending on the interpretation, might break contracts: A model checker would assure any node has at most one Trainer. However, RunningCoach is a Trainer, but a node might have several RunningCoaches.

Option 2: Only allow changes from multiple =true to multiple = false

Pro:

• Maintains the contract: A node can have 0..* AnimalOwners, but at most one Trainer.

Con:

• Complex constraints, hard to explain

Option 3: Cannot redefine

In any annotation inheritance hierarchy, the multiple feature can be set exactly once, or only to the same value.

Pro:

• Sufficiently simple

Con:

• Cannot express some cases

annotates

Option A: No limits

classDiagram

class AnimalOwner {
  <<annotation>>
}

class Animal

AnimalOwner --> Animal: annotates

class Trainer {
  <<annotation>>
}

AnimalOwner <|-- Trainer

class Learner

Trainer --> Learner: annotates

Pro:

• Flexibility

Con:

• Trainer breaks the contract of AnimalOwner: We assume an AnimalOwner always annotates an Animal. However, Trainer is a AnimalOwner -- but it annotates a Learner.

Option B: specialization constraint

A sub-annotation MUST annotate a sub-concept of the super-annotation's target.

classDiagram

class AnimalOwner {
  <<annotation>>
}

class Animal

AnimalOwner --> Animal: annotates

class Trainer {
  <<annotation>>
}

AnimalOwner <|-- Trainer

class Learner

Animal <|-- Learner

Trainer --> Learner: annotates

Pro:

• Maintains the contract of AnimalOwner

Con:

• We disallowed specializations in Which parts of a link can be specialized? #8

Option C: Cannot redefine

In any annotation inheritance hierarchy, the annotates feature can be set exactly once, or only to the same value.

classDiagram

class AnimalOwner {
  <<annotation>>
}

class Animal

AnimalOwner --> Animal: annotates

class Trainer {
  <<annotation>>
}

AnimalOwner <|-- Trainer

Trainer --> Animal: annotates

class Doctor {
  <<abstract, annotation>>
  Integer yearsOfExpertise
}

class AnimalDoctor {
  <<annotation>>
}

Doctor <|-- AnimalDoctor

AnimalDoctor --> Animal: annotates

class HumanDoctor {
  <<annotation>>
  String specialization
}

Doctor <|-- HumanDoctor

class Human

HumanDoctor --> Human: annotates

class CSharpDoctor {
  <<annotation>>
}

Doctor <|-- CSharpDoctor

Trainer redefines annotates, but to the same value as for AnimalOwner.

Doctor is abstract, so it doesn't need to specify annotates. Specialized doctors can. CSharpDoctor is invalid because it doesn't define annotates.

Pro:

• Sufficiently simple

Con:

• Constraints are not trivial
• Allowing redefinition with the same value leads to even more complex constraints

Decision: Option 3 + C

• Features (multiple, annotates) cannot be redefined
• Features MUST be defined somewhere in the inheritance hierarchy for any concrete Annotation
• Lower cardinality of features is 0