Chapter 5. Introduction

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

5.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 and SysML2 allow declaring stand-alone (package-level) 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;
}

Properties May Represent Inputs or Outputs

A feature/property that is declared with the keyword in represents inputs, while a feature/property 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;
}

Properties May Be Variable or Constant

Values of a variable feature may vary in time over the duration of a featuring instance. A constant feature is [...] constrained to have the same values over the entire duration of a featuring instance. [KerML 7.3.4.2]

This implies that constant features must already have a value for an instance of their domain on its creation, so they are mandatory and frozen. In the following example, the birth date of a person may not be changed, while the name may be changed:

classifier Person {
  var feature name : String;
  constant feature birthDate : Date;
}

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 takes an ontological perspective by adopting the concept of occurrences, which are things that happen over time, from the philosophical discipline of Ontology. A KerML occurrence

Viewing Objects as Occurrences

KerML breaks 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. In KerML, also 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).