1.1. Overview

The main authors of the KerML specification document are: • Ed Seidewitz, Model Driven Solutions • Conrad Bock, US National Institute of Standards and Technology (NIST) • Bjorn Cole, Lockheed Martin Corporation • Ivan Gomes, Twingineer • Hans Peter de Koning, DEKonsult • Vince Molnár, Budapest University of Technology and Economics.

KerML is organized in three layers: Root, Core and Kernel, as illustrated by the diagram below. While the Root layer defines language engineering concepts, the Core and Kernel layers define modeling concepts.

The black dots in the class diagram denote association end ownerships according to UML2. For instance, the black dot at the source association end (of the association between the classes Element and Relationship) denotes that this association end is owned by the class Relationship, which means that the class Relationship has a property source with range Element.

Notice that the use of the term "class" in KerML departs from its use in UML. There are two types of Classes in KerML: Structures (representing object types) and Behaviors (representing event/activity/process types), and the instances of Classes are not objects, but occurrences (things that happen over time). In KerML, objects are instances of Structures, while the instances of Behaviors are performances (representing events/activities/processes).

KerML takes the approach of providing a predefined top-level instance for every metamodel classifier. For instance, DataValue is a predefined instance of the classifier DataType such that any user-defined data type is a subtype of it. Instead of declaring

datatype URL;

you can equivalently declare

classifier URL specializes DataValue;

The following diagram provides an overview of KerML's metamodel classifiers and their top-level instances. The arrows with a dashed line denote the is-instance-of relationship. E.g., the predefined classifier Anything is the top-level instance of the metamodel classifier Classifier (consequently, any other instance of Classifier specializes Anything).

1.2. What's New or Different Compared to UML

KerML keeps many of the modeling concepts of UML, but it also changes several of its concepts, introduces new concepts, and changes some of its terminology. In the following subsections, we briefly discuss important KerML elements that are new or depart from UML.

New Terminology

The concept of generalization has been replaced with the inverse concept of specialization. This reflects the fact that it is more common to make statements about specialization compared to generalization.

A number of UML modeling concepts have been renamed in KerML and SysML2. In particular, in SysML2, classifiers are called 'definitions' and features are called 'usages'.

UML classes are called structures in KerML and item/part definitions in SysML2. Recall that in UML, properties are structural features while operations are behavioral features. In SysML2, properties with a data type range are called attribute usages, while properties with a class range are called item or part usages. UML operations are called steps (features with a Behavior range) or expressions (features with a Function range) in KerML and action usages or calculation usages in SysML2.

Stand-Alone Feature Declarations

Like the Web Ontology Language OWL allows declaring stand-alone properties, also KerML/SysML2 allow declaring stand-alone features not included in the declaration of a type that forms their domain, like the following ones:

feature name : String;
feature children[*] : Person;

attribute name : String;
item children[*] : Person;

Such a stand-alone declaration implies that the domain of the feature or (attribute/item/etc.) usage is the most general classifier, which is Base::Anything.

Features of Features

Since features are types and types may have features, KerML/SysML2 allow defining features of features (including the case of attributes of attributes) and provide a convenient syntax for nesting feature declarations, as shown in the following example:

classifier Organization;
classifier Person {
  feature name : String;
  feature employers[*] : Organization {
    feature salary : Real;
  }
}

item def Organization;
item def Person {
  attribute name : String;
  ref item employers[*] : Organization {
    attribute salary : Real;
  }
}

In this example, two classifiers (or item definitions), Organization and Person, are declared. Person is declared together with two features, the attribute name and the item usage employers, in such a way that for employers, an attribute salary is declared. This means that a person can have many employers and for each of them an employer-specific salary corresponding to the following tables representing example populations of the types Person and employers:

Using the form of relational database tables, we get the following population table for the feature Person::employers:

A nested feature definition like the one above can be flattened as follows:

classifier Person {
  feature name : String;
}
feature employers[*] : Organization featured by Person {
  feature salary : Real;
}

Features/Attributes May Represent Inputs or Outputs

A feature/attribute that is declared with the keyword in represents inputs, while a feature/attribute declared with the keyword out (or inout) represents outputs (or both inputs and outputs).

classifier Vehicle {
  composite feature fuelTank {
    out feature fuelFlowOut : Fuel;
  }
  composite feature engine {
    in feature fuelFlowIn : Fuel;
  }
}

In/out features are also used for modeling the parameters of Functions, which are defined as behavior classifiers, the instances of which are its executions/evaluations.

Features May Represent Portions of a Thing

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.)

Examples:

classifier Fuel {
  portion feature fuelPortion : Fuel;
}

classifier Person {
  portion feature childhood : Person;
}

Features/Attributes May Be Read-Only

Values of read only features on each instance of their domain are the same during the entire existence of that instance.

This implies that read-only features must already have a value for an instance of their domain on its creation, so they are mandatory and frozen.

classifier Book {
  readonly feature type : BookTypeEnumerationLiteral;
  feature isbn : String;
}

Semantic Libraries

Unlike the UML, KerML and SysML2 come with Semantic Libraries, which are collections of KerML/SysML2 models that are part of their semantics. The Base library model defines the top-most elements of the specialization hierarchy for all KerML types, including the most general classifier Anything, the most general feature things, and the most general datatype DataValue.

The following fragment from the Semantic Libraries defines abstract classifiers representing the most general Data Type, Class, Association, Structure and Behavior:

abstract classifier Anything;
abstract datatype DataValue specializes Anything;
abstract class Occurrence specializes Anything 
    disjoint from DataValue;
abstract assoc Link specializes Anything;
abstract struct Object specializes Occurrence;
abstract behavior Performance specializes Occurrence 
    disjoint from Object;

Logical Process Modeling

While in UML, process/behavior modeling has been scattered over three different, but overlapping, diagram languages (State Machines, Sequence Diagrams and Activity Diagrams), each of them coming with its own operational semantics and with no integration in the UML metamodel, behaviors are modeled in a uniform and declarative manner in KerML by

1. Viewing behaviors as classes that are instantiated by behavior executions as occurrences, which allows (1) defining behavior properties and parts, including properties for referencing their participant objects, (2) specializing behaviors.
2. Considering the composition of behaviors: while the components of objects are modeled as parts, the components of behaviors are modeled as steps.
3. Logically sequencing the steps of a behavior with the help of successions, which are special connectors, such that each succession defines a temporal precedence constraint.

As in UML, events are not first-class citizens in KerML. In fact, events are not even mentioned at all in the KerML spec, despite the fact that they are considered as a fundamental modeling concept in many other modeling languages, such as BPMN and OntoUML, as well as in many Discrete Event Simulation modeling languages.

Taking an Ontological Perspective

Unlike UML, KerML and SysML2 take an ontological perspective by adopting the concept of occurrences, which are things that happen over time, from the philosophical discipline of Ontology. In KerML and SysML2, not only behavior performances, but also objects are occurrences. This is discussed in the next section.

Viewing Objects as Occurrences

KerML and SysML2 break with the established view (e.g., in UML) that objects are continuants, which persist over time, while events, actions/activities and processes are occurrences, which happen over time. For them, all things, including objects, are occurrences, which means that objects are identified with their histories/lifes.

The UML world view corresponds to a 3D Ontology, referring to the three dimensions of the space, in which objects are extended, while the KerML/SysML2 world view corresponds to a 4D Ontology, in which objects are extended in space and time.

Formal Semantics

While the UML2 specification does not include any formal semantics, 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. 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.

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).

2.1. Types

Types classify things in a modeled system. The set of things classified by a type is the extent of the type, each member of which is an instance of the type. Everything being modeled is an instance of the type Anything from the Base library.

KerML distinguishes between two kinds of types: classifiers and features.

Types are namespaces, enabling them to have members via membership relationships to other elements identified as their members.

Types can be declared to specialize, and to be disjoint from, other types:

type Mammal specializes Animal disjoint from Mineral;
disjoint Person::parents from Person::children;

The symbol :> can be used interchangeably with the keyword specializes.

Unioning, intersecting, and differencing are relationships between a type and a set of other types:

type Person unions Adult, Child;
type A intersects B, C;
type X differences Y, Z;

Differencing specifies that a type classifies everything that is classified by the first of the differenced types but not by any of the remaining types.

2.2. Classifiers

Classifiers are types that classify things in the modeled system, as distinct from features, which model the relations between them

Classifiers are typically declared together with a set of features:

classifier Person {
  feature name : String;
  feature age : Integer;
}

2.3. Features

Features are types that classify how things in a modeled system are related. A feature relates instances in the intersection of the extents of its featuring types (the domain) with instances in the intersection of the extents of its featured types (the co-domain). Instances in the domain of a feature are said to "have values" that are instances of the co-domain. [Note: an alternative, and preferable, term for 'co-domain' is range.]

Features are normally declared with a range (or co-domain) in the body of a type declaration, in which case the type is their domain, as in the following example where the classifier Person is both the domain and the range of the features parents, siblings, children and cousins:

classifier Person {
  feature parents[0..2] : Person;
  feature siblings[*] : Person;
  feature children[*] : Person inverse of parents;
  // a cousin is a child of a parent's sibling
  feature cousins[*] : Person chains parents.siblings.children;
} 

Notice that the features parents, siblings, children and cousins all have the multiplicity * ("many"), which means that they are multi-valued. By default, the multiplicity of a feature is 1, which means that the feature is mandatory and functional (or, in other words, single-valued), having exactly one value. When the value of a feature is a set of values from its range, the feature is non-functional and its multiplicity is either 0..* or n..* where n > 0. Instead of 0..*, which means "neither mandatory nor functional", we can simply write the asterisk symbol *.

A feature that is declared within the body of a type is an owned feature of that type, so it automatically has that type as a featuring type.

The feature cousins is declared by feature chaining to include, for a given person, all persons that are children of siblings of the parents of this person. The feature children is declared by feature inverting to be the inverse of the feature parents. That is, for each pair (p₁, p₂) in the extent of children, the pair (p₂, p₁) is in the extent of parents.

Features can also be declared at the package level independently of a type declaration:

feature name : String;
feature age : Integer featured by Person;

Here, the feature name is declared with the datatype String as its range, and since no explicit domain is declared, the implicit domain is the pre-defined classifier Anything (from the Base library), while the feature age is declared to have the explicit domain Person, as expressed by the clause featured by Person. A package-level feature is always referential and is semantically featured by the base type Anything (which means that a value for it is available within any instance of any type). However, it is not syntactically an "owned" feature of Anything, since it is, by definition, owned by a package. That means that it has no "featuring types".

Type featuring, which can be declared with the keywords featured by, is a relationship between a feature and a type, where the type is a featuring type of the feature. Feature membership is a kind of type featuring that also makes the feature an owned member of the featuring type.

Feature typing is a relationship between a feature and a type that identifies the type as a featured type of the feature, as expressed by the colon in between the feature name "age" and the datatype name "Integer" or, equivalently, by the clause typed by in the following example:

feature age typed by Integer featured by Person;

According to the current semantics of KerML, feature typing is a certain form of specialization, which has the non-intuitive implication that a feature specializes its range. For instance, the feature age declared in the code example above would specialize its range Integer and, consequently, any pairs from the extent of age, like (Tom, 37), would be instances of the datatype Integer, in addition to the "basic instances" representing integers, which is quite strange.

Features may have certain type-level properties such as being unique, ordered, composite, derived, read-only or directed, as shown in the following meta-model fragment:

Notice that the concept of a directed feature (of a Behavior) replaces the UML concept of an operation parameter.

Except for isComposite, all other meta-properties only seem to apply to structural features, also called properties.

Property Value Relationships

A property value relationship (called "feature value" in the spec) is a special kind of binding connector, binding a (possibly initial or default) value to a property.

An example of a bound (as opposed to initial) property value relationship, stating that a property's value is always obtained as the result of the value expression, and in this sense derived is shown in the following example:

classifier TestRecord {
  feature scores[1..*] : Integer;
  derived feature averageScore : Rational = sum(scores)/size(scores);
}

An example of an initial property value relationship, stating that a property's initial value is obtained as the result of the value expression (but may be changed subsequently):

feature count : Natural := 0;

An example of a bound property default value relationship:

feature cutoff : Integer default 0.75 * averageScore;

An example of an initial property default value relationship:

feature engine : Engine default := standardEngine;

These different forms of property value relationships combine the definition of a property (structural feature) with different forms of bindings.

Ordered Sets and Multi-Sets (Bags) as Values of Multi-Valued Features

A multi-valued feature declaration can include either or both of the keywords ordered and nonunique (in either order). For instance, we can declare that the value of a multi-valued feature spouses is a sequence of persons in the following way:

classifier Person {
  feature spouses[*] : Person nonunique ordered;
}

If a feature is ordered, then for any domain instance, the values of the feature can be placed in order, indexed from 1 to the number of values. The default is that the feature is unordered.

If a feature is non-unique, then, for any domain instance, the same range instance may appear more than once as a value of the feature. The default is that the feature is unique.

Subsetting and Redefinition as Special Forms of Specialization

There are also several forms of specialization that apply specifically to features.

1. Subsetting is a relationship between a specific feature (the subsetting feature) and a more general feature (the subsetted feature), where the specific feature may further constrain the featuring types, featured types and multiplicity of the general feature.
2. Redefinition is a kind of subsetting in which the specific feature (the redefining feature) also replaces an otherwise inherited general feature (the redefined feature) in the context of the owning type of the specific feature.

The symbols :> and :>> can be used interchangeably with the keywords subsets and redefines, respectively.

An example of subsetting is the following:

classifier Wheel;
classifier DriveWheel specializes Wheel;
classifier Automobile {
  composite feature wheels[4] : Wheel;
  // Restricts multiplicity and type
  composite feature driveWheels[2] : DriveWheel subsets wheels;
}

An example of redefinition is the following:

classifier WheeledVehicle {
  composite feature wheels[1..*] : Wheel;
}
classifier MotorizedVehicle specializes WheeledVehicle {
  composite feature redefines wheels[2..4];
}

In this example, the effective name of the redefining feature is "wheels", which is the same name as the redefined feature.

2.4. Open Questions

1 Why Should a Feature Specialize Its Range?

TBD

A usage inherits the features from its definition in the same way that a specialized definition inherits from a more general definition element. For example, if a part usage vehicle is defined by a part definition Vehicle, and Vehicle has a mass defined by MassValue, then vehicle inherits the feature mass. In some cases, a usage may have more than one definition element, in which case the usage inherits the features from each of its definition elements, with the same rules for conflicting names as described above for subclassification. [SysML 7.6.1]

2 Questionable example models in the spec

Can a (continuous) mass noun like "fuel" be modeled as a class(ifier) as in the following example (from 7.3.4.2 Feature Declaration)?

classifier Fuel {
  portion feature fuelPortion : Fuel;
}
classifier Tank {
  in feature fuelFlow: Fuel;
  composite feature fuel : Fuel;
}

What are the instances of Fuel? Another question concerns the modeling of fuel flow in the Tank classifier declaration: isn't a fuel flow a fuel quantity per unit of time, and not a fuel quantity?

Another example is the following (from the "SysML v2 Intro Textual Notation" slides):

part def Vehicle {
  attribute mass : Real;
  ref item driver : Person;
  part fuelTank {
    item fuel: Fuel;
  }
}

Here, again, the question is how is Fuel modeled? As a class? There is a comment on the slide that "Items may also model continuous materials that are stored in and/or flow between parts of a system." However, the term "item" is commonly understood as referring to countable things.

3 What are good examples of portion features?

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.)

Are the following good examples of portion features?

// from 7.3.4.2 of KerML
classifier Fuel {
  portion feature fuelPortion : Fuel;
}

classifier Person {
  portion feature childhood : Child;
}

3.1. A Standard Model-Theoretic Semantics of Simple KerML Models

KerML's official semantics departs from the standard model-theoretic semantics for logic-based modeling languages (such as OWL and Alloy), as well as from formalizations of UML class models and ER models in the following way:

1. Since KerML allows features to have features, features cannot be interpreted (like classical properties or binary predicates) as binary relations over the universe U (or subsets of U × U).
2. Due to KerML's peculiar Feature Typing concept, the interpretation/extent of a classifier C includes the interpretations/extents of all features having C as their range, implying that classifiers can no longer be interpreted as subsets of U.
3. Since KerML allows features to have non-unique and ordered collections (multisets and sequences) as values, the interpretations of a KerML model also include a marking set and the set of all sequences formed with elements of U and of the marking set.

As a consequence, KerML's official semantics has lost much of the intuitive and philosophical appeal of standard model-theoretic semantics.

We present a standard model-theoretic semantics of a fragment of KerML, called Simple KerML Models, which do neither allow features to have features nor non-unique/ordered value collections.

For readability, we prefer using the terms object type instead of "structure", action type instead of "behavior", and action instead of "performance". We also call a structural feature a property, a data-valued property an attribute, and a behavioral feature an action step.

While the classical model-theoretic semantics of predicate logic does not make any ontological distinctions among the elements of the universe, the model-theoretic semantics of OWL partitions the universe into data values and objects, whereas the model-theoretic semantics of KerML partitions the universe into data values, objects and actions.

We define a Simple KerML model as a KerML model that only defines

1. data types, object types and action types as classifiers;
2. features for classifiers, but not for features;
3. features with plain value sets.

The following is an example of a Simple KerML model defining the action types BookRoom, CheckIn, Charge, CheckOut and RentHotelRoom, as well as the object types Room and Hotel, such that the action type RentHotelRoom has four action steps, the object type Room has one attribute and the object type Hotel has two attributes and one action step:

behavior BookRoom;
behavior CheckIn;
behavior Charge;
behavior CheckOut;
behavior RentHotelRoom {
  step bookRoom[1] : BookRoom;
  step checkIn[0..1] : CheckIn;
  step charge[1] : Charge;
  step checkOut[0..1] : CheckOut;
}
struct Room {
  feature roomNumber: Natural;
}
struct Hotel {
  feature name: String;
  feature rooms[1..*]: Room;
  step rentHotelRoom[*] : RentHotelRoom;
}

An action step (as an action-valued feature) defined for an object type, such as Hotel::rentHotelRoom, may express the fact that objects of that type can perform actions of the type defined for the step, such as hotels performing rentHotelRoom actions.

The KerML concept of multiplicities is semantically ambiguous: do they refer to history or to snapshot populations?

It has also been raised as an issue for KerML by Conrad Bock [KERML-306].

In the following section, we define a more concise mathematical representation of Simple KerML models as 12-tuples.

Simple KerML Models

A Simple KerML (SK) model defines a vocabulary consisting of the names of classifiers (data types, object types or action types) and classifier features, corresponding to the vocabulary of a predicate logical language consisting of names of constants, functions and predicates. Data literals correspond to constants, classifiers correspond to unary predicates, and classifier features correspond to unary functions (or binary predicates).

For Simple KerML models, we simplify the representation of the start and end times of occurrences by including two corresponding attributes in the definition of the predefined classifier Occurrence. In KerML, all occurrences have a startShot and an endShot, which are special zero-duration suboccurrences, whose occurrence time can be obtained by invoking the library function TimeOf. Consequently, the start time of an occurrence o is TimeOf( o.startShot ), and its end time is TimeOf( o.endShot ).

According to the KerML spec, all occurrences have an endShot, which raises the question, if KerML does not support ongoing occurrences with a moving time horizon?

It has also been raised as an issue for KerML by Conrad Bock [KERML-306].

An SK model, based on a set of predefined classifiers, is a 12-tuple

⟨ DT, OT, AT, Cl, ownF, feat, rng, mul_s, mul_h, sup, CInv, GInv ⟩

specifying:

1. The pairwise disjoint finite sets of names of (predefined and user-defined) data types DT, object types OT and action types AT, which merged together form the set of classifier names Cl, such that, by definition, each of them contains the predefined name of a most general type/classifier: DataValue ∈ DT, Object ∈ OT, Action ∈ AT and { Occurrence, Anything } ⊆ Cl.
2. A function ownF for assigning a set of local names of its owned features to a classifier name C. The function feat is obtained by extending ownF such that subclassifiers inherit the (onwed and inherited) features of their superclassifiers. Full feature names have the form C::f where f ∈ feat(C).
3. A function rng for assigning a range (or co-domain) to any feature C::f with rng(C::f) ∈ Cl.
4. A function mul_s for assigning snapshot multiplicities to features.
5. A function mul_h for assigning history multiplicities to features of occurrence types.

6. A function sup for assigning direct superclassifiers to classifiers C ∈ Cl, such that

   1. Anything ∈ sup*(C), where sup* is the transitive closure of sup,
   2. if C ∈ DT, then sup(C) ⊆ DT and DataValue ∈ sup*(C),
   3. if C ∈ OT, then sup(C) ⊆ OT and { Object, Occurrence } ⊆ sup*(C),
   4. if C ∈ AT, then sup(C) ⊆ AT and { Action, Occurrence } ⊆ sup*(C),
   5. if C' ∈ sup(C), then feat(C') ⊆ feat(C).
7. A set of classifier invariants CInvar, which are ordered pairs of a classifier C and a logical formula F(x) with one free variable x, stating that F(i) holds for all instances i from the extent of C.
8. A set of global invariants GInvar, which are logical sentences (formulas without free variables).

Interpretations

While data values are ahistoric (they exist independently of time), all occurrences (objects and actions) have either been existing for some time in the past and possibly still exist, or exist at present. Occurrences remain in the history (of a modeled system) once they have ceased to "exist". Local universes of discourse (at certain points in time) include not only the present occurrences but all past occurrences as well; they increase as time progresses and new occurrences come into being (see also the discussion of constant versus varying domain semantics in [1]).

An interpretation of an SK model is an octuple

I = ⟨ ⟨Time, <⟩, ct, DV, Obj, Act, Occ, U, I_t ⟩

such that

1. ⟨Time, <⟩ is a linear order of time instants and ct ∈ Time is the current time. We write Time_ct for the set { t ∈ Time : t ≤ ct }.
2. DV is a time-independent (ahistoric) set of data values, which includes strings and numbers.
3. Obj: Time_ct → 2^Obj_ct and Act: Time_ct → 2^Act_ct are functions that assign finite sets of objects Obj_t and actions Act_t to any time instant t ≤ ct such that DV, Obj_t and Act_t are pairwise disjoint. These sets are expanding in time: for all t, t' ≤ ct, if t < t', then Obj_t ⊆ Obj_t' and Act_t ⊆ Act_t'.
4. Likewise, Occ: Time_ct → 2^Occ_ct and U: Time_ct → 2^U_ct are functions that assign a set of occurrences Occ_t and things U_t to any time instant t ≤ ct such that Occ_t = Obj_t ∪ Act_t and U_t = DV ∪ Occ_t.

5. I_t is a time-indexed interpretation function such that for all time instants t, t' ≤ ct:

   1. I_t(Anything) = U_t and I_t(Occurrence) = Occ_t.
   2. I_t(D) = I_t'(D) ⊆ DV for all D ∈ DT, and I_t(DataValue) = DV.
   3. I_t(O) ⊆ Obj_t for all O ∈ OT, and I_t(Object) = Obj_t.
   4. I_t(A) ⊆ Act_t for all A ∈ AT, and I_t(Action) = Act_t.

   5. A feature C::f with mul_s(C::f) = ⟨ l_s, u_s ⟩ and rng(C::f) = R is interpreted as a function I_t(C::f) : I_t(C) → 2^I_t(R) such that for any x ∈ I_t(C) and its feature value set val = I_t(C::f)(x), card(val) ≥ l_s and, if u_s≠ ∗, card(val) ≤ u_s, and

      1. if C is a data type, the feature interpretation function I_t(C::f) is ahistoric: I_t(C::f) = I_t'(C::f),
      2. if C is an occurrence type, then the feature has either an explicitly asserted history multiplicity mul_h(C::f) = ⟨ l_h, u_h ⟩ or an implied (default) history multiplicity mul_h(C::f) = ⟨ 0, * ⟩, and for any o ∈ I_ct(C) and c = card U_i≤ct I_i(C::f)(o), c ≥ l_h, and if u_h≠ ∗, then c ≤ u_h,
      3. the predefined occurrence type features startTime and endTime are interpreted according to their intended semantics: for any occurrence o, st = I_t(startTime)(o) ≤ ct and if o has an end time et = I_t(endTime)(o), then st ≤ et ≤ ct.
   6. The interpretation of classifiers respects their specialization hierarchy: for any classifier C ∈ Cl and any of its supertypes C' ∈ sup(C), I_t(C) ⊆ I_t(C').
   7. The interpretation satisfies all constraints of the model:
      1. for all classifier invariants ⟨C, F(x)⟩ ∈ CInvar, I ⊨ F(a) for all a ∈ C,
      2. for all global invariants S ∈ GInvar, I ⊨ S.

An interpretation I, together with a variable value assignment v : Var → U_ct for a finite set of variables Var, allows to interpret expressions. For instance, for expressions of the form x.f where x is an occurrence variable and f is a feature name:

I_t^v(x.f) = I_t(C::f)(v(x)) where v(x) ∈ C and f ∈ feat(C)

Whenever the range of a feature C::f is an occurrence type C', we can interpret expressions of the form x.f₁.f₂ where f₁ ∈ feat(C) and f₂ ∈ feat(C'), which are called path expressions. The resulting value set I_t^v(x.f₁.f₂) is obtained by merging the value sets I_t(C::f₂)(p) for all p ∈ I_t(C::f₁)(v(x)). In this way, we can interpret path expressions of any length greater than zero.

Satisfaction of Logical Formulas

Finally, we can define how a variable-assignment-enhanced interpretation I_t^v satisfies a logical formula F formed with atomic formulas that are composed with the help of the usual logical operators. The base case of atomic formulas includes the following three forms:

1. Classification atoms have the form C(x) where C is a classifier. They are satisfied by I_t^v if and only if v(x) ∈ I_t(C). Symbolically,

   I_t^v ⊨ C(x) iff v(x) ∈ I_t(C).

2. Comparison atoms have the form expr₁ # expr₂ where each expr_k is either a data literal (from one of the underlying datatypes), a variable, or a path expression, and # is one of the comparison predicates (=, ≠, <, ≤, >, ≥).

   I_t^v ⊨ expr₁ # expr₂ iff I_t^v(expr₁) I_t(#) I_t^v(expr₂),

   where I_t(#) is the interpretation of the comparison predicate #.

Complex logical formulas formed with the logical operators ¬, ∧, ∨, →, ∀, ∃ are satisfied by a variable-assignment-enhanced interpretation in the usual way.

When a logical sentence (variable-free formula) S is satisfied by an interpretation at a time instant t ∈ Time, we write I_t ⊨ S. When it is satisfied at all time instants t ≤ ct, we write I ⊨ S.

Entailment

An SK model M entails a logical sentence if the sentence is satisfied by all interpretations of the model:

M ⊨ S iff I ⊨ S for all interpretations I of M.

Integrity Constraints

Integrity constraints, as elements of a KerML model, are logical sentences that have to be satisfied by the interpretations of the model. A KerML model may, for instance, define the following types of (integrity) constraints for a classifier:

Range Constraints

require that a feature must have a value from the value space of the type that has been defined as its range. For instance, a value of an attribute declared as feature age : Integer must be an integer. These (implicit) constraints are expressed in a model by specifying a range for the features concerned.

Mandatory Value Constraints

require that a feature must have a value. These constraints are expressed in a model with the help of a feature multiplicity that has a lower bound greater than 0. Notice that the default multiplicity of a feature is 1, implying that it is mandatory and single-valued.

Cardinality Constraints

apply to multi-valued features, only, and can require that the cardinality of a feature's value set is not less than a given minimum cardinality or not greater than a given maximum cardinality, as expressed by the feature's multiplicity.

In addition, there are further types of classifier constraints that only refer to a specific attribute and, therefore, could be expressed within the declaration of the attribute concerned:

Uniqueness Constraints (also called 'Key Constraints')

require that the value of an attribute C::a is unique among all instances of its domain: F(x) ≡ ∀y: C(y) → x.a ≠ y.a. Notice that this is different from declaring a feature to be unique, which requires its value collection to contain no duplicates.

Interval Constraints

require that the value of a numeric attribute a must be in a specific interval [min,max]: F(x) ≡ min ≤ x.a ∧ x.a ≤ max.

Pattern Constraints

require that a string attribute's value must match a certain pattern defined by a regular expression. They allow defining special string data types such as for URLs, email addresses or telephone numbers.

These classifier invariants could be expressed in the simplified way of an annotation appended to the attribute declaration. For instance, UML allows expressing uniqueness constraints with the help of the annotation (property modifier) keyword "key", while it also allows expressing standard identifier (or 'primary key') constraints with the help of the attribute annotation keyword "id" (implying that the attribute is unique and mandatory, and that its values are used as standard identifiers).

An interval constraint could be expressed with the attribute annotation keywords "min" and "max" together with corresponding numbers, while a pattern constraint could be expressed with the attribute annotation keyword "pattern" together with a regular expression.

References

[1] First-order temporal logics, a section of the article "Temporal Logic" by Valentin Goranko and Antje Rumberg, 2024, in Stanford Encyclopedia of Philosophy.

4.1. Data Types

Data types are classifiers that classify data values, which are abstract things that do not exist in time or space.

datatype IdNumber specializes ScalarValues::Integer;

If a data type has features, their values cannot change over time, because different feature values would inherently identify a different data value.

datatype SensorReading {
  feature sensorId : IdNumber;
  feature value : ScalarValues::Real;
}

The KerML library Base includes the predefined data type DataValue, which is the most general data type in the sense that every other data type is a subtype of it. A Kernel-layer data type declaration made with the keyword "datatype" like the following one:

datatype URL;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined data type DataValue:

classifier URL specializes DataValue;

4.2. Occurrence Types ("Classes")

In KerML, Classes are occurrence types:

Classes are classifiers that classify occurrences, which happen in time (and space). Relations between an occurrence and other things can change over time and space, while the occurrence still maintains its identity.

KerML defines two kinds of occurrence types: "Structures" (better called object types) and Behaviors (better called action types). However, the specification does not explain if these occurrence types classify only completed occurrences or both completed and ongoing occurrences.

The KerML library Occurrences includes the predefined Class Occurrence, which is the most general Class in the sense that every other Class is a subtype of it. A Kernel-layer Class declaration made with the keyword "class" like the following one:

class ArrivalEvent;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined Class Occurrence:

classifier ArrivalEvent specializes Occurrence;

4.3. Object Types ("Structures")

In KerML, objects are considered as occurrences (happening over time like processes) and object types are called "Structures", while action types are called "Behaviors":

Structures are Classes that classify objects, which are kinds of occurrences. Structures and Behaviors do not overlap, but Structures can own Behaviors, and the objects they classify can be involved in Behaviors (e.g., they can perform Behaviors).

An example of an object type declaration:

struct Sensor { 
  feature id : IdNumber;
  feature currentReading : Real;
  step updateReading { ... }  // a behavioral feature
}

The KerML library Objects includes the predefined classifier Object, which is the most general object type in the sense that every other object type is a subtype of it. A KerML Structure declaration like the following one:

struct Car;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined object type Object:

classifier Car specializes Object;

4.4. Associations

What is called an association between two (or more) related types in UML and SysML, corresponds to the mathematical concept of a relation as a subset of the Cartesian product of the related types. The instances of an association, called links, represent relationships between individuals and correspond to the tuples of a relation.

The following UML class diagram shows an example of an explicit many-to-many association Ownership that is specialized by a one-to-many association SoleOwnership:

Notice how the Ownership association end owners with multiplicity * ("many") is redefined by the SoleOwnership association end owner with multiplicity 0..1 ("at most one"), expressing the fact that any asset is linked to zero or many legal entities as its owners while it is linked to at most one legal entity as its sole owner.

An association between two types represents a function (in the sense of mathematics) if it has a functional (single-valued) association end. An overview about the different cases of functionality of an association is provided in the following table:

The following tables show an example snapshot population of the classifiers involved in the model shown in the diagram above:

In the KerML spec, associations are characterized as follows:

Associations are classifiers that classify links between things. At least two owned features of an association must be end features representing its association ends, which identify the things being linked by (at the "ends" of) each link (exactly one thing per end, which might be the same thing). Associations with exactly two association ends are called binary associations. The end features of an association identify the participants in the links that are instances of the association and must have multiplicity 1. Associations can also have features that are not end features, which characterize each instance of the association separately from the things it links.

An association is also a relationship between the types of its association ends, called its related types, which might be the same. Links are between instances of an association's related types. For binary associations, the two related types are identified as the source type and the target type. For associations with more than two association ends (called "n-ary" associations), the first related type is the source type and all the remaining related types are target types.

In the following class diagram, the two UML associations Ownership and SoleOwnership from the class diagram above have been turned into KerML associations as link classifiers with the two ends owner and ownedAsset as their properties (or end features), such that their instances are (owner, ownedAsset) value pairs corresponding to binary links.

Notice that the end properties of KerML associations, here: owner and ownedAsset, since they are always single-valued, have the multiplicity 1. Notice also how the corresponding multiplicities of the original class diagram above, which are now marked in yellow, have moved to the UML association ends at the new KerML association classes. These association ends are called cross features in KerML. For instance, * is the cross multiplicity of Ownership::owner, while 0..1 is the cross multiplicity of SoleOwnership::owner.

Consider a binary association A with end properties e₁ typed by E₁ and e₂ typed by E₂. The cross multiplicity of e₁ allows expressing how many A links may, or have to, exist for any instance of E₂.

The model shown in the class diagram above can be expressed in KerML in the following way:

classifier LegalEntity {...}
classifier Asset {...}
assoc Ownership {
  end [*] feature owner : LegalEntity;
  end [*] feature ownedAsset : Asset;
}
assoc SoleOwnership specializes Ownership {
  end [0..1] feature redefines owner;
}

The multiplicities specified between the keywords "end" and "feature", like [*] and [0..1] in the example above, represent the cross multiplicities of the KerML association's end properties. The cross multiplicity [*] of Ownership::owner (and Ownership::ownedAsset) expresses the fact that for any instance of LegalEntity (and Asset), there are zero or more Ownership links. The cross multiplicity [0..1] of SoleOwnership::owner expresses the fact that for any instance of Asset, there is at most one SoleOwnership link. The default cross multiplicity is [*], which means that, by default, there are no cardinality constraints.

Notice that the names of the end features of a KerML association declaration should be singular noun phrases since they are always single-valued, that is, they reference exactly one individual.

The keyword feature, as well as the default cross multiplicity [*], may be omitted from an association end declaration:

assoc Ownership {
  end owner : LegalEntity;
  end ownedAsset : Asset;
}

The KerML library Links includes the predefined association Link, which is the most general association in the sense that every other association is a subtype of it. A Kernel-layer association declaration made with the keyword "assoc" like the following one:

assoc Employment;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined association Link:

classifier Employment specializes Link;

Implicit Associations Expressed by Reference Properties

A referential feature that has classes (representing occurrence types) as its domain and range establishes an implicit binary association between its domain and range. Such a feature may also be called a reference property. In the following example, the reference property ownedAssets establishes an implicit binary association between LegalEntity and Asset.

class LegalEntity {
  feature id : String;
  feature name : String;
  feature ownedAssets[*] : Asset;
}
class Asset
  feature id : String;
  feature name : String;
}

In this example, the implicit association is represented in a unidirectional way with references from LegalEntity to Asset but not vice versa. However, an implicit association can also be represented in a bidirectional way by declaring a pair of mutually inverse reference properties like so:

class LegalEntity {
  feature id : String;
  feature name : String;
  feature ownedAssets[*] : Asset;
}
class Asset
  feature id : String;
  feature name : String;
  feature owners[*] : LegalEntity inverse of LegalEntity::ownedAssets;
}

Notice that without declaring one of the two features ownedAssets and owners to be the inverse of the other, they would formally not represent the same association in a bidirectional way, but rather two different unidirectional associations.

Association Structures

Association Structures are both Associations and Structures, classifying link objects, which are both links and objects. As objects, link objects can be created and destroyed, and their non-end features can change over time. However, the values of the end features of a link object are fixed and cannot change over its lifetime (that is, they are effectively read only).

Example:

assoc struct ExtendedOwnership specializes Ownership {
  feature revaluations[*] ordered : MonetaryValue;
}

The KerML library Objects includes the predefined Association Structure LinkObject, which is the most general Association Structure in the sense that every other Association Structure is a subtype of it. A Kernel-layer Association Structure declaration made with the keyword "assoc struct" like the following one:

assoc struct Employment;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined Association Structure LinkObject:

classifier Employment specializes LinkObject;

4.5. Connectors and Bindings

Connectors are features that are typed by associations, having values that are links. Like an association, a connector has end features, known as its connector ends. Each connector end redefines an association end from each of the associations that type the connector and subsets a feature that becomes a related feature of the connector. Connectors typed by binary associations are called binary connectors.

A connector is also a relationship between its related features. For binary connectors, the two related features are identified as the source feature and the target feature, which might be the same.

These principles are described by the following meta-model, which redefines the range of a Connector feature to be an association:

Notice that, in addition to regular connectors, there are also two special kinds of connectors:

1. binding connectors for binding the value of one feature to the value of another feature;
2. successions for temporally sequencing behavior steps.

In the following example, a Mounting association between the object types Axle and Wheel classifies links between an axle and a wheel, such that an axle is linked to two wheels, as shown in the following class diagram and the corresponding KerML code.

Notice that the cross multiplicity [2] of the end property mountedWheel expresses the constraint that for any instance of Axle, there are exactly two Mounting links linking the axle to two different wheels.

struct Axle {...}
struct Wheel {...}
assoc Mounting {
  end [1] mountingAxle : Axle;
  end [2] mountedWheel : Wheel;
}

The corresponding connector property mount of the object type WheelAssembly has exactly two values, namely one mountingAxle-mountedWheel link for each of the two wheels of a wheel assembly mounted to the same axle:

struct WheelAssembly {
  composite feature axle : Axle;
  composite feature wheels[2] : Wheel;
  connector mount[2] : Mounting {
    end mountingAxle references axle;
    end mountedWheel references wheels;
  }
}

Notice that the related features referenced by connector ends are specified using the keyword references, denoting a special form of subsetting.

Connectors can be thought of as "instance-specific" associations, because their values (which are links) are each limited to linking things identified via related features on the same instance of the connector's domain.

Any value a connector (such as mount) is a link instantiating its typing association (Mounting), for which the participants are values of the related features (axle and wheels) of the connector.

Instead of explicitly declaring connector ends in the body of a connector, they can also simply be listed between parentheses, in which case the connector ends are matched in order to corresponding association ends:

struct WheelAssembly {
  composite feature axle : Axle;
  composite feature wheels[2] : Wheel;
  connector mount[2] : Mounting (axle, wheels);
}

A special notation can be used for a binary connector, in which the source-related feature is referenced after the keyword from, and the target-related feature is referenced after the keyword to:

struct WheelAssembly {
  composite feature axle : Axle;
  composite feature wheels[2] : Wheel;
  connector mount[2] : Mounting from axle to wheels;
}

KerML allows using an even simpler syntax for defining such a connector:

struct HalfAxleAssembly {
  composite feature halfAxle : HalfAxle;
  composite feature wheel : Wheel;
  connector halfAxle to wheel;
}

However, since this simplified syntax for defining binary connectors does not specify a name nor an underlying association, it is implied that a connector defined in this way is single-valued and typed by the most general binary association BinaryLink, which is predefined in the library Links.

Connector ends may also be declared with cross multiplicities. In this case, the given cross multiplicity redefines the cross multiplicity that would otherwise be inherited from the association end corresponding to the connector end.

Bindings

Binding connectors (or simply bindings) are single-valued binary connectors that require their source and target features to have the same values on each instance of their domain. Unlike for a regular single-valued binary connector, the value of a binding is not a link object (an occurrence in space and time), but rather a (kind of abstract) binary link, typically between an output and an input feature. A binding is implicitly typed by the library association SelfLink, which links things in the modeled universe to themselves.

A binding connector is declared using the keyword binding by specifying a binding equation, as in the following example:

struct Vehicle {
  composite feature fuelTank {
   out feature fuelFlowOut : Fuel;
  }
  composite feature engine {
    in feature fuelFlowIn : Fuel;
  }
  binding fuelFlowBinding of fuelTank.fuelFlowOut = engine.fuelFlowIn;
}

If no name is needed, the declaration of a binding connector can be simplified by just specifying the binding equation, like so:

  binding fuelTank.fuelFlowOut = engine.fuelFlowIn;

4.6. Questions

1 Unnamed connector example

In section 7.4.6.2 Connector Declaration, there is the following example containing an unnamed binary connector declaration:

struct WheelAssembly {
  composite feature axle[1] : Axle;
  composite feature wheels[2] : Wheel;
  connector axle to wheels;
}

How is an unnamed connector used (e.g., in a path expression)? Doesn't the example specify a single connection only between one of the two wheels and the axle?

5.1. Behaviors, Steps and Successions

In KerML, the actions of a system are considered as performances of the system's "behaviors" and their types are called "Behaviors":

Behaviors are classes that classify performances, which are kinds of occurrences that can be spread out in disconnected portions of space and time. The performance of behaviors can cause effects on other things, including their existence and relations, some of which might be accepted as input to or provided as output from the behavior.

Behaviors can have steps, which are features typed by behaviors, allowing the containing behavior to coordinate the performance of other behaviors. Steps can be ordered in time using succession connectors. They can also be connected by item flows to model things flowing between the output of one step and the input of another. Steps can also nest other steps to augment or redefine steps inherited from their behavior types.

Features declared in the body of a behavior with a direction are considered to be the owned parameters of the behavior. Features with direction in are input parameters, those with direction out are output parameters, and those with direction inout are both input and output parameters.

The following example models a behavior with three action steps:

behavior Focus { in scene: Scene; out image: Image; }
behavior Shoot { in image: Image; out picture: Picture; }
behavior TakePicture {
  in scene : Scene;
  out picture : Picture;
  binding focus.scene = scene;
  step focus : Focus;
  succession focus then shoot;
  flow focus.image to shoot.image;
  step shoot : Shoot;
  binding picture = shoot.picture;
  step takePictureWithAutoFocus : TakePicture {
    in feature unfocusedScene redefines scene;
    step redefines focus : AutoFocus;
    out feature focusedPicture redefines picture;
  }
}

As shown in the example above, a step can have substeps declared in its body.

Notice that a step is a 'composite' feature: since for each performance of its owning behavior, its performance must happen during that performance, so it must end before, or at the same time when, the performance of their owning behavior ends. The same reasoning applies to the behavior connector concepts of bindings, successions and item flows: their link occurrences must also happen during the performance of their owning behavior.

The KerML library Performances includes the predefined Behavior Performance, which is the most general Behavior in the sense that every other Behavior is a subtype of it. A Kernel-layer Behavior declaration made with the keyword "behavior" like the following one:

behavior Drive;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined Behavior Performance:

classifier Drive specializes Performance;

Successions of Action Steps

A succession is a special type of connector that can be used for connecting successive action steps of a behavior. It is declared using the keyword succession together with the keywords first and then, as in the following example:

behavior TakePicture {
  step focus : Focus;
  step shoot : Shoot;
  succession controlFlow first focus then shoot;
}

Successions are single-valued binary connectors that require their source and target features to be behavioral. Unlike a regular connector instance, a succession instance is not a link object (an occurrence in space and time), but rather a kind of abstract binary link.

Normally, a succession is not explicitly typed by an association, which semantically implies that it is typed by the HappensBefore association that is predefined in the Occurrences library.

Successions between steps require the occurrence values of steps to be ordered in time such that for any occurrence of a behavior composed of two steps in succession, the first step suboccurrence happens before the then step suboccurrence.

The declaration of a succession can be simplified by omitting its name, like so:

  first focus then shoot;

As for connector ends on regular connectors, constraining multiplicities can also be defined for the connector ends of successions, as shown in the following example.

behavior TakePicture {
  step focus[*] : Focus;
  step shoot[1] : Shoot;
  // A focus may be preceded by a previous focus
  first [0..1] focus then [0..1] focus;
  // A shoot must follow a focus
  first [1] focus then [0..1] shoot;
}

Declaring successions with suitable step multiplicities allows defining behaviors based on certain temporal constraints similar to "declarative" business process modeling approaches such as DECLARE. For instance, the three most important types of DECLARE constraints, Precedence, Response and Neg-Succession, can be expressed by corresponding succession declarations, as shown in the following table.

In DECLARE, the meaning of constraint templates is provided by a translation to formulas of Linear Temporal Logic (LTL), which includes the temporal operators ◇ standing for "eventually", □ standing for "always", and U standing for "until". For instance, the formula (F U G) stands for "F until G" meaning that at some point in time G holds and all the time before that F holds. While the variables in the propositional temporal logic LTL, like F and G, normally represent sentences, in the context of providing a logical semantics for business processes, they are taken to represent actions or activities. For more about using LTL as a logical semantics for constraint-based business process models see Declarative Process Specifications by Ciccio and Montali, 2022.

An Example of a Weakly Structured Process Model

We consider a simple process type of renting hotel rooms adopted from (Pesic et al 2007) for illustrating process modeling with KerML. Processes of this type consist of seven types of activities: (1) "book room": enter client name, payment data, etc; (2) “check-in”: record client arrival, provide key card, etc; (3) “bill”: for billing the number of nights, room services, laundry services, etc; (4) “provide room service”: provide a room service for the client; (5) “provide laundry service”: provide a laundry service for the client; (6) “charge”: the client is charged the total price of the stay; and (7) “check-out”: client checks out at the reception.

Following the terminology of SysML2, we say "action" instead of "activity".

This hotel room renting process type is only weakly structured since it does not properly sequence all types of actions. But it has a few (dynamic) constraints:

1. Every process has to start with a "book room" action followed by a “check-in” action.
2. Every process must include at least one action of type “bill”, i.e., at least the number of nights will be billed. However, it might be the case that the bill is extended multiple times during a process (due to room services and laundry services provided during the stay).
3. Every action of type “provide room service” or “provide laundry service” must be billed. However, it is possible that several services are billed at once, instead of billing each service separately.
4. When the client “checks-out”, the bill must either have been charged already or will be charged at, or after, check-out.

We start by capturing the seven action types of this process type in the form of KerML Behavior definitions:

behavior BookRoom {
  feature clientName : String;
  feature preferredWayOfPayment: String;
  ...
}
behavior CheckIn {...}
behavior ProvideRoomService {...}
behavior ProvideLaundryService {...}
behavior Bill {...}
behavior Charge {...}
behavior CheckOut {...}

Then we use these action type definitions for defining corresponding action steps in a RentHotelRoom action type definition:

behavior RentHotelRoom {
  step bookRoom[1] : BookRoom;
  step checkIn[0..1] : CheckIn;
  step provideRoomService[*] : ProvideRoomService;
  step provideLaundryService[*] : ProvideLaundryService;
  step bill[1..*] : Bill;
  step charge[1] : Charge;
  step checkOut[0..1] : CheckOut;
  // A room service must be followed by a bill action
  first [0..1] provideRoomService then [1] bill;
  // A laundry service must be followed by a bill action
  first [0..1] provideLaundryService then [1] bill;
}

Notice that this action type definition includes the following constraints:

1. The steps bookRoom and charge are executed exactly once.
2. The steps checkIn and checkOut are executed at most once.
3. The step bill is executed at least once.
4. A provideRoomService action must be followed by a bill action.
5. A provideLaundryService action must be followed by a bill action.

We need to define three more precedence constraints and two more combined follow-up/precedence constraints:

behavior RentHotelRoom {
  ...
  // A check-in must be preceded by a book room action
  first [1] bookRoom then [0..1] checkIn;
  // A room service must be preceded by a check-in action
  first [1] checkIn then [0..1] provideRoomService;
  // A laundry service must be preceded by a check-in action
  first [1] checkIn then [0..1] provideLaundryService;
  // A book room action must be followed by a charge action, and
  // a charge action must be preceded by a book room action
  first [1] bookRoom then [1] charge;
  // A check-in must be followed by a check-out, and
  // a check-out must be preceded by a check-in
  first [1] checkIn then [1] checkOut;
}

Modeling "Control Nodes" as Special Behavior Steps

In classical process modeling languages, such as UML Activity Diagrams or BPMN Process Diagrams, control nodes have been used for branching and merging the "control flow" of a process, that is, the flow of process events. In KerML, branching and merging within a Behavior is specified with the help of steps that are typed by special control behaviors predefined in the ControlPerformances library:

DecisionPerformance

A decision performance has a HappensBefore link as the value of its outgoingHBLink feature, representing the succession that has been selected from those, which have the decision performance behavior as their source. A step that is typed by a DecisionPerformance has values (performances) representing the earlierOccurrence of exactly one HappensBefore link of the successions going out of the step. Successions going out of such steps must have connector end multiplicities of 1 towards the step, and 0..1 away from it.

5.2. Functions and Expressions

Functions are Behaviors with one out parameter designated as the result parameter. Functions classify evaluations, which are kinds of performances that produce results as values of the result parameter. Like all Behaviors, Functions can change things, often referred to as "side effects". A pure Function is one that has no side effects and always produces the same results given the same input values, similarly to a function in the mathematical sense.

Expressions are steps typed by only a single Function, which means that their values are evaluations. An expression whose value is an evaluation with results is said to evaluate to those results. They can be steps in any behavior, but a Function, in particular, can designate one of its expression steps as the result expression that gives the value of its result parameter. Expressions can have their own nested parameters, to augment or redefine those of their Functions, including the result parameter. They can also own other expressions and designate a result expression, similarly to a Function.

The body of a Function may contain the declaration of a result expression at the end, as in the following example:

function Average {
  in scores[1..*] : Rational;
  return : Rational;
  // result expression
  sum(scores) / size(scores)
}

The result of the result expression is implicitly bound to the result parameter of the containing Function. Alternatively, a result expression can be explicitly bound to the result parameter like so:

function Average { 
  in scores[1..*] : Rational;
  return : Rational = sum(scores) / size(scores);
}

The KerML library Performances includes the predefined Function Evaluation, which is the most general Function in the sense that every other Function is a subtype of it. A Kernel-layer Function declaration made with the keyword "function" like the following one:

function MyFun;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined Function Evaluation:

classifier MyFun specializes Evaluation;

Expressions

An expression can be declared as a step using the keyword expr. As for a step, directed features declared in the body of an expression are considered to be parameters of the expression.

Example 1:

function UnaryFunction {in x : Anything; return: Anything;}
function apply {
  in expr fn : UnaryFunction;
  in value : Anything;
  return : Anything = fn( value);
}

Example 2 (shows how an expression can be invoked using a feature chain):

class Stats {
  feature vales[1..*] : Real;
  expr avg { sum(values)/size(values) }
}
feature myStats : Stats {
  redefines feature values = (1.0, 2.0, 3.0);
}
feature myAvg = myStats.avg();

5.3. Interactions

Interactions are behaviors that are also associations, classifying performances that are also links between occurrences. They specify how the linked participants affect each other and collaborate.

Transfers are interactions between two participants that carry items from one occurrence to another, with items optionally identified by output and input features of the source and target occurrence, respectively.

Item flows are steps that are also binary connectors, with values that are transfers. An item flow optionally ensures that items are transferred from an output feature of the connected source feature to an input feature of the target feature. Succession item flows are item flows that are also successions. They identify transfers that happen after their source (that is, after the end of the occurrence where the items come from) and before their target (that is, before the start of the occurrence where the items go to).

Example:

interaction Authorization {
  end feature client[*] : Computer;
  end feature server[*] : Computer;
  composite step login;
  composite step authorize;
  composite succession login then authorize;
}

The KerML library Transfers includes the predefined binary Interaction Transfer, which is the most general binary Interaction in the sense that every other binary Interaction is a subtype of it. A Kernel-layer binary Interaction declaration made with the keyword "interaction" like the following one:

interaction Authorization;

is equivalent to the following Core-layer classifier declaration made with the help of the predefined binary Interaction Transfer:

classifier Authorization specializes Transfer;

Item Flows

An item flow is similar to a binary connector. Unlike a regular binary connector declaration, though, an item flow declaration does not directly specify the related features for the item flow. Instead, the declaration gives the source output feature for the transfer after the keyword from and the target input feature for the transfer after the keyword to. The related features are then determined as the owning features of the features given in the item flow declaration.

In the following example, an item flow connects the out-parameter of an action step focus to the in-parameter of an action step shoot, allowing to transfer images obtained from focus actions as inputs to shoot actions.

behavior Focus { in scene: Scene; out image: Image; }
behavior Shoot { in image: Image; out picture: Picture; }
behavior TakePicture {
  in scene : Scene;
  out picture : Picture;
  binding focus.scene = scene;
  binding picture = shoot.picture;
  step focus : Focus;
  step shoot : Shoot;
  succession focus then shoot;
  flow focus.image to shoot.image;
}

6.1. The Indexical Variables self, that and this

In a nested declaration, the special variable self always refers to the instances of the innermost nested element, which, in the example below, would be the evaluations of the constraint. For a feature nested in a containing element, the variable that refers to the instances of the containing element. Therefore, in the following example, the variable that refers to the instances of NegativeInteger such that the constraint requires all of them to be smaller than 0:

attribute def NegativeInteger specializes Integer {
  assert constraint { that < 0 }
}

For a behavioral feature (e.g., an action or constraint) directly or indirectly composed into a structural model, the variable this refers to the instances (items or parts) of the structural context for the behavior [as explained by Ed Seidewitz in a post on the Google Groups forum SysML v2 Release].

However, the variable this may not be aware of the features of its direct type and therefore should be casted to this type if needed, as in the following example:

part def Car {          // <--- "this"
  attribute velocity : Integer;
  action drive {        // <--- "that"
    constraint check {  // <--- "self"
      (this as Car).velocity < 100
    }
  }
}

The variable self is a feature that relates everything to itself. It is also the value of the nested that feature of all other things featured by this thing, as implied by declaring that self chains things.that.

// Kernel Base Libraray fragment
abstract classifier Anything {
  feature self : Anything subsets things chains things.that;
  abstract feature things[1..*] : Anything nonunique {
    feature that : Anything
  }
}

6.2. Occurrences

The predefined class Occurrence is specialized by Object and Performance, corresponding to the specialization of Class (OccurrenceType) by Structure (ObjectType) and Behavior.

Time slices are portions of occurrences that might have feature values and links to other things peculiar to their smaller period of time. The snapshots of occurrences are time slices that take no time. The earliest snapshot of an occurrence is its startShot, the latest is its endShot. All the others happen during its middleTimeSlice. Occurrences with a startShot the same as their endShot take no time and have no middleTimeSlice.

Occurrences are always portions of themselves. An occurrence that is only a portion of itself (a maximal portion) is an instance of the library class Life.

Other important features of Occurrence are:

snapshotOf[0..*]

The occurrences of which this occurrence is a snapshot.

timeSliceOf[1..*]

The occurrences of which this one is a time slice, including this one.

predecessors[0..*]

The occurrences that are completely separate from this one in time (not necessarily in space) and that happen before this one (end earlier than this one starts).

successors[0..*]

The occurrences that are completely separate from this one in time (not necessarily in space) and that happen after this one (start later than this one ends).

innerSpaceDimension

The number of variables needed to identify space points in this occurrence, from 0 to 3, without regard to higher dimensional spaces it might be embedded in. For example, the innerSpaceDimension of a curve is 1, even if it twists in three dimensions.

outerSpaceDimension

For an occurrence of innerSpaceDimension 1 or 2, the number of variables needed to identify their space points in higher dimensional spaces they might be embedded in, from the innerSpaceDimension to 3. For example , an outerSpaceDimension 3 for a curve indicates it twists in three dimensions. An outerSpaceDimension equal to innerSpaceDimension indicates the occurrence is spatially straight (innerSpaceDimension 1 embedded in 2 or 3 dimensions) or flat (innerSpaceDimension 2 embedded in 3 dimensions).

spaceSlices[1..*]

All portions of this occurrence that extend for exactly the same time and some or all the space, relative to spatial location of this occurrence. This means every occurrence is a spaceSlice of itself.

spaceShots[1..*]

All space slices of this occurrence that are of a lower innerSpaceDimension than it.

localClock

A local clock to be used as the corresponding time reference for this occurrence and, by default, all suboccurrences. By default this is the singleton Clocks::universalClock.

7.1. Attributes and Enumerations

In SysML v2, attributes (or, more precisely speaking, attribute usages) are data-valued features, corresponding to data-valued properties in OWL, as opposed to occurrence-valued features, such as item usages or part usages, corresponding to object-valued properties in OWL.

In the simplest case, an attribute is declared with a KerML data type as its range (such as the primitive data types String, Boolean, Integer, Natural, Rational, or Real), as in the following example:

item def Person {
  attribute name : String;
  attribute age : Natural;
}

What is called an attribute definition in SysML2 is, in fact, a data type definition (defining a set of data values). In the following example, an attribute definition is provided by constraining the values of the primitive KerML data type Integer:

attribute def NegativeInteger specializes Integer {
  assert constraint { that < 0 }
}

Notice that the keyword that has to be used here for referring to the instances of the containing definition of NegativeInteger in the constraint body (see also Section 6.1).

Quantity Types and Attributes

The ISQ package of the Quantities and Units Domain Library of SysML v2 provides a number of predefined generic quantity attributes (or, more precisely, attribute usages), like for instance,

attribute length : LengthValue;
attribute mass : MassValue;
attribute time : TimeValue;

Notice that the domain (or featuring type) of these predefined attributes is the classifier Anything, so they are inherited by any classifier whenever the ISQ package is imported in a system model. For more on quantities and units, see 10. Quantity Values and Quantity Types.

Enumerations

An enumeration definition is a kind of data type that defines a (typically small) set of names as its enumerated values, like the names "male" and "female" for the two biological sexes in the following example:

enum def Sex {
  enum male;
  enum female;
}

Since the body of an enumeration definition may only declare enumeration "usages", the declaration of an enumerated value may omit the enum keyword:

enum def Sex { male; female; }

An enumeration definition can be used for declaring an attribute the values of which are limited to the defined set of enumerated values. For instance, in the following example, an instance of the item definition Person must have either "male" or "female" as the value of its sex attribute:

item def Person {
  attribute name : String;
  attribute sex : Sex;
}
item def Female specializes Person {
  attribute redefines sex = Sex::female;
}

Notice how the attribute sex is bound to the specific value "female" by means of redefinition, effectively expressing the constraint that a female person is a person having the sex attribute value "female".

An enumeration definition may subclassify other attribute definitions or KerML data types. However, an enumeration definition must not subclassify another enumeration definition.

In the SysML spec, enumerations are considered as special kinds of variations and its enumerated values as its variants. However, there is no need for, and no gain of, such a treatment. It's preferable to simply stick to the classical view of an enumeration.

7.2. Items and Parts

SysML2 distinguishes between two kinds of objects:

• An object that is neither a system nor a part of a system is an item.
• A part is an item that is a system or a part of a system.

While parts are items that may perform actions, items that are not parts do not perform actions.

The term item is used as a synonym of the KerML term object. Consequently, an item definition, as a kind of occurrence type definition, actually defines an object type, while an item "usage" is an item-valued property.

In the following example, there is an item definition Person and an item property driver:

item def Person;
part def Vehicle {
  attribute mass : Real;
  ref item driver : Person;
}

A system is modeled as a composite part, and its parts may themselves have further composite structure. Parts may have ports that define the connection points at which those parts may be interconnected for allowing flows of signals/messages or of physical substances. Parts may also perform actions and exhibit states.

A part can represent any level of abstraction, such as a purely logical component, a physical component (with a part number), or some intermediate abstraction. Parts can also be used to represent different kinds of system components such as hardware components, software components, facilities, organizations, or users of a system.

In the following example, there are four part definitions (Engine, Wheel, Person and Vehicle), and there are three part usages (eng, wheels, and driver):

part def Engine;
part def Wheel;
part def Person;
part def Vehicle {
  attribute mass : Real;
  part eng : Engine;
  part wheels[4]: Wheel;
  ref part driver[0..1] : Person;
}

Notice that part usages, such as Vehicle::eng and Vehicle::wheels in the example above, are composite features by default, while the part usage Vehicle::driver is declared as a referential (non-composite) feature, which implies that the driver of a vehicle is not necessarily destroyed when the vehicle is destroyed.

7.3. Property Value Relationships

A property value relationship (called "feature value" in the spec) is a special kind of binding connector that binds a (possibly initial or default) value to a property.

An example of a bound property value relationship, stating that a property's value is always obtained as the result of the value expression, and in this sense derived:

derived attribute averageScore : Rational = sum(scores)/size(scores);

Notice that designating a bound property value relationship as derived is not required.

An example of an initial property value relationship, stating that a property's initial value is obtained as the result of the value expression (but may be changed subsequently):

attribute count : Natural := 0;

An example of a bound property default value relationship:

attribute cutoff : Integer default 0.75 * averageScore;

An example of an initial property default value relationship:

part engine : Engine default := standardEngine;

These different forms of property value relationships combine the definition of a property (structural feature) with different forms of bindings.

7.4. Ports

A port represents a connection point that can be connected to another port for enabling transfers (e.g., of signals or physical quantities) between systems or their parts. The features of a port specify what can be exchanged in such transfers.

Connected ports must conform: each feature of a port at one end of a connection must have a matching feature on a port at the other end of the connection. Two features match if they have conforming definitions and either both have no direction or they have conjugate directions. The conjugate of direction in is out and vice versa, while direction inout is its own conjugate. A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features. [7.12.1]

A port definition is a KerML Structure and, consequently, a port usage, as a non-composite feature, references port objects.

The following example illustrates how the conjugated ports FuelOutPort and FuelInPort match by having the same features with the direction of directed features being reversed:

port def FuelOutPort {
  attribute temperature : Real;
  out item fuelSupply : Fuel;
}
port def FuelInPort {
  attribute temperature : Real;
  in item fuelSupply : Fuel;
}
part def FuelTankAssembly {
  port fuelTankPort : FuelOutPort;
}
part def Engine {
  port engineFuelPort : FuelInPort;
}

Every port definition also implicitly declares a conjugated port definition, which has the same features, except that any directed features have conjugated directions (i.e., in and out are reversed, with inout unchanged). The name of the conjugated port definition is always given by the name of the original port definition with the character ~ prepended, in the namespace of the original port definition. [7.12.3]

Thus, the example above can be rewritten in the following way:

port def FuelOutPort {
  attribute temperature : Real;
  out item fuelSupply : Fuel;
}
part def FuelTankAssembly {
  port fuelTankPort : FuelOutPort;
}
part def Engine {
  port engineFuelPort : ~FuelOutPort;
}

7.5. Connections, Bindings and Interfaces

A connection between two (or more) parts is itself a part in the form of a link object (an instance of an association structure). A connection definition is a part definition that is also a KerML association structure. The features of a connection definition that are not connection ends allow to characterize connections, as shown in the following example:

part def Hub {...}
part def Device {...}
connection def DeviceConnection {
  end [0..1] part hub : Hub;
  end [1..*] part device : Device;
  attribute bandwidth : Real;
}

A connection definition often represents logical connections that abstract away details of how the involved parts are connected. For example, plumbing that includes pipes and fittings may be used to connect a pump and a tank. It is sometimes desired to model the connection of the pump to the tank at a more abstract level without including the plumbing. This is viewed as a logical connection between the pump and the tank.

Alternatively, the plumbing can be modeled as a part where the pump connects to the plumbing, and the plumbing connects to the tank. As a part itself, a connection can contain the plumbing either as a composite feature, or as a reference to the plumbing that is owned by a higher level pump-tank system context. In this way, the logical connection without structure can be refined into a physical connection.

In the following example, a binary Mounting connection association allows connecting an axle to two wheels by requiring that its population includes exactly two links for each instance of Axle linking it to two different instances of Wheel:

part def Axle {...}
part def Wheel {...}
connection def Mounting {
  end [1] part mountingAxle : Axle;
  end [2] part mountedWheel : Wheel;
}

Notice the special syntax for cross multiplicities: while connection ends always have the multiplicity 1, the cross multiplicity [2] of the end mountedWheel specifies that exactly 2 links involving the same axle but different wheels are required in the extent of the connection .

A connection property is a part property that is also a KerML connector.

A connection usage redefines the connection ends from its definition, associating those ends with the specific usage elements that are to be connected. For example, a connection definition could have connection ends that are part usages defined by part definitions Pump and Tank. A usage of this connection definition would then associate corresponding connection ends with specific pump and tank part usages. Supposing that the pump and tank part usages have multiplicity 1, then this means that the single value of the pump usage is to be connected to the single value of the tank usage.

A connection usage that connects parts is often a logical connection that abstracts away details of how the parts are connected. For example, plumbing that includes pipes and fittings may be used to connect a pump and a tank. It is sometimes desired to model the connection of the pump to the tank at a more abstract level without including the plumbing.

In the following example, the connection property mount, which is typed by the Mounting connection association defined above, requires having exactly two values, each one representing a connection between the WheelAssembly's axle and one of its wheels:

part def WheelAssembly {
  part axle : Axle;
  part wheels[2] : Wheel;
  connection mount[2] : Mounting {
    end part mountingAxle references axle;
    end part mountedWheel references wheels;
  }
}

This syntax also allows the declaration of ternary (or n-ary) connection properties:

connection def TwoWheelsMounting {
  end [1] part mountingAxle : Axle;
  end [1] part leftWheel : Wheel;
  end [1] part rightWheel : Wheel;
}
part def WheelAssembly {
  part axle : Axle;
  part leftWheel : Wheel;
  part rightWheel : Wheel;
  connection mount : TwoWheelsMounting {
    end part mountingAxle references axle;
    end part mountedLeftWheel references leftWheel;
    end part mountedRightWheel references rightWheel;
  }
}

There are two shorthand textual notations for connection properties.

1. The related features of the connection property may be identified in a comma-separated list, between parentheses (...), preceded by the keyword connect:

   connection mount : TwoWheelsMounting 
     connect ( mountingAxle ::> axle, 
       mountedLeftWheel ::> leftWheel, 
       mountedRightWheel ::> rightWheel
   )

   Notice that, for brevity, the symbol ::> is used here instead of the keyword references. In the simple case of a single-valued connection property, an anonymous connection declaration (without a name and a type) can be expressed like so

   connect ( axle, leftWheel, rightWheel )

2. If the connection property is typed by a binary connection association, then a further special notation may be used:

   connection mount[2] : Mounting 
     connect mountingAxle ::> axle to mountedWheel ::> wheels;

   In the special case of a single-valued binary connection property, an anonymous connection declaration (without a name and a type) can be expressed like so

   part def DeviceConfiguration {
     part hub : Hub;
     part device : Device;
     connect hub to device;
   }

Bindings

Bindings allow expressing value equalities between two different features. They have been defined in KerML as single-valued binary connectors that require their source and target features to have the same values on each instance of their domain.

part def Vehicle {
  part fuelTank {
    out fuelFlowOut : Fuel;
  }
  part engine {
    in fuelFlowIn : Fuel;
  }
  binding fuelFlowBinding
    bind fuelTank.fuelFlowOut = engine.fuelFlowIn;
}

In the SysML spec, bindings (and successions) are redefined as special kinds of connection "usages". However, there is no need for such a redefinition. It's preferable to simply keep the KerML concept of a binding as a special kind of connector.

Interfaces

An interface definition is a connection definition that connects ports (that is, all of its ends are ports). An interface property ("usage") is a connection property for connecting ports.

In the following example, an anonymous interface property of a DistributedSystem (without a specific type) connects a client port to a server port for allowing request-response signaling:

part def DistributedSystem {
  item def Request;
  item def Response; 
  part client {
    port clientPort;
    action clientBehavior {
      send Request() via clientPort;
      then accept Response via clientPort;
    }
  }
  part server {
    port serverPort;
    action serverBehavior {
      accept Request via serverPort;
      then send Response() via serverPort;
    }
  }
  interface client.clientPort to server.serverPort;
}

8.1. Action Types and Steps

An action (type) definition is a kind of KerML Behavior that classifies action performances. An action step ("usage") is a kind of KerML Step (a behavioral feature). Action definitions and action steps can be composed of subaction steps.

An action definition may declare properties with directions in, out or inout that act as the parameters of a corresponding action expression. If an action step has parameters, then it may also transform the values of its input parameters into values of its output parameters.

An action performance can generate effects on involved objects (items or parts), including their existence and relationships to other things.

Subaction steps can be sequenced and coordinated with the help of (possibly conditional) successions as well as fork/join and decision/merge control nodes, which are viewed as special types of action steps in SysML2. An output parameter of an action step may be bound to an input parameter of a follow-up action step. An input parameter of an action definition or step can also be bound to the input parameter of a nested action step, passing the values of the input parameter into the nested action, and an output parameter of a nested action step can be bound to an output parameter of a containing action definition or step, passing the values of the output parameter out.

The binding of action parameters, however, does not model the case when there is an actual transfer of items between actions that may itself take time or have other properties. Such a transfer can be more properly modeled using a flow connection between the two action steps, in which the transfer source output is an output parameter of the source action step and the transfer target input is the input parameter of the target action step.

Transfers can also be performed using send and accept action steps. In this case, the source and target of the transfer do not have to be explicitly connected with a flow. Instead, the source of the transfer is specified using a send action step contained in some some source part or action type, while the target is given by an accept action step in some destination part or action type (which may be the same as, or different than, the source). A send action step includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across an interface).

Both part types and action types can have perform action steps, which are always referential. In the case of a perform action step of a part type, the referenced action is performed by the containing part (as its performer) during its lifetime. In the case of a perform action step of an action type, the perform action step represents a "call" from the containing action to the performed action.

Timing Constraints

Timing constraints can be expressed within an action type definition like so:

private import Time::TimeOf;
action def A {
   first start;
   then action a1;
   then action a2;
   then done;
   assert constraint {  TimeOf( self.done) - TimeOf( self.start) < 10[s] }  
}

The constraint requires that any action of type A must be completed within 10 s.

8.2. States

T.B.D.