Appendix B. Previous Work on Which KerML is Built or That Influenced It

KerML is built upon the Unified Modeling Language (UML) and the Web Ontology Language (OWL), and it is strongly influenced by a number of previous works that we summarize and review in this section.

The Unified Modeling Language (UML 1997–2015)

The UML consists of a set of visual modeling languages for modeling software systems, the most important of which are

1. Class Models/Diagrams for defining classes together with their attributes, operations and integrity constraints, as well as associations and specializations between classes. Classes define the (information) structure of the objects that instantiate them.
2. Activity Diagrams for defining behaviors consisting of a succession of events and actions, possibly involving objects that participate in them.
3. State Machine Diagrams for defining transitions between (object) states
4. Sequence Diagrams for defining interactions as temporal orderings between message events.

While class models allow describing, or defining, the (information) structure of software systems in a coherent way, the models listed in items 2–4 are supposed to describe, or define, the behavior of software systems. Unlike for structural modeling (with Class Diagrams), UML does not have a common abstract syntax or semantics for its behavior modeling languages. Thus, with three overlapping, but non-integrated behavior modeling languages, UML does not allow coherent behavior modeling.

Since the dynamics of a system does not only consist of the system's actions and activities, but also of other types of events (such as system failures or message arrivals), UML's choice of the term 'behavior modeling' is unfortunate for denoting the modeling of the dynamics of a system. Wikipedia defines that "Behavior is the way a person or animal acts and reacts". In UML, the term 'Behavior' is only defined vaguely and its intended meaning seems to be that a 'Behavior' is an activity consisting of actions and reactions.

According to the UML metamodel, a Behavior is a special kind of Class that classifies behavior executions (or occurrences). In fact, Behavior is an umbrella concept subsuming activities and interactions. The UML spec states (in 13.2.3.1) that

A Behavior is a specification of events that may occur dynamically over time [...]. Every Behavior defines at least one event, the event of its invocation. [...] On each invocation, the subsequent actual sequence of event occurrences due to the invocation, consistent with the specification of the Behavior, is called an execution trace for the Behavior.

[...] an instance of a Behavior is known as a behavior execution. Invoking the Behavior corresponds to instantiating the Behavior, and there is a specific execution trace corresponding to each Behavior execution.

According to the spec (17.2.3.1), an Interaction is a Behavior that focuses on the passing of messages.

Events are not first-class citizens in UML since there is no element for classifying events (such as EventType). The UML spec states that "an Event can be considered a classification of its occurrences, though Events are not actually Classifiers in UML".

KerML has imported or adopted the following elements from UML:

• Classifiers, Features and Specialization. However, in KerML, both Classifiers and Features are Types, which may have Features, while in UML, Classifiers have Features.
• DataTypes, Classes and Associations as special Classifiers. Already in UML 2.5.1, the metaclass Class has been turned into an umbrella concept subsuming both object types and Behaviors (with the strange terminology that also the instances of Behavior classes, executions, are called "objects"). However, in KerML, the instances of a Class are no longer objects, but occurrences, and object types are now called "Structures".
• Connectors as special features of StructuredClassifiers typed by an association allowing to represent interconnections between different parts of a system.
• Behaviors as special Classes that classify behavior executions (called performances in KerML).
• Interactions as special Behaviors.

Recommended reading/resources on UML:

• An excellent overview/summary is provided by uml-diagrams.org.

The Web Ontology Language (OWL 2004–2012)

OWL is a language for

1. defining vocabularies ("ontologies") consisting of (a) classes for classifying things, (b) properties for describing things and (c) integrity constraints for fine-tuning how things can be described;
2. representing knowledge about things with the help of classification and attribution statements expressed in terms of the classes and properties defined in OWL vocabularies.

Basic knowledge about things is expressed in the form of classification statements and attribution (or object-property-value) statements, also called "triples", corresponding to atomic sentences in predicate logic, where classes and properties correspond to unary and binary predicates. OWL has two predefined classes, Thing and Nothing, corresponding to the class of all things and the empty class.

An OWL knowledge base, consisting of a vocabulary and a set of classification and object-property-value statements, corresponds to a set of predicate-logical sentences.

The formal semantics of OWL follows Tarski's model-theoretic semantics of predicate logic where the truth of a sentence is defined relative to an interpretation of its language (given by individual names and predicate names). A predicate-logical interpretation consists of

1. A set of all things in the world (called universe). In OWL, the universe is partitioned into a set of data values D and a set of objects O.
2. An interpretation function I that maps unary predicates to subsets of the universe (their extension) and n-ary predicates to n-ary relations over the universe. In OWL, data types are mapped to subsets of D and classes are mapped to subsets of O, while data-valued properties are mapped to subsets of the Cartesian product of O and D, and object-valued properties are mapped to subsets of the Cartesian product of O and O.

An interpretation satisfies an atomic sentence p(i) stating that p applies to i, where p is a unary predicate and i is an individual name, if I(i) ∈ I(p), that is, p applies to i if the thing denoted by i is in the extension of the predicate p.

An interpretation satisfies a negation (conjunction, disjunction) of a sentence S (and S'), if (1) it does not satisfy S, (2) it satisfies both S and S', (3) it satisfies S or S'.

Since a UML class model corresponds to an OWL vocabulary, we can check if a class model is consistent by checking if the corresponding set of predicate-logical sentences is satisfiable, that is, if there is an interpretation that satisfies all the sentences expressed by the class model.

KerML has imported or adopted the following elements from OWL:

• KerML's predefined (most general) classifier Base::Anything corresponds to OWL's Thing and its predefined (most general) data type Base::DataValue corresponds to OWL's rdfs:Literal.
• The separation of feature definitions from class(ifier) definitions.
• Inspired by OWL, KerML adopts a model-theoretic semantics, remarkably not only for its structural modeling concepts, but also for its behavioral modeling concepts. However, since, unlike OWL, KerML has to support features/attributes with non-unique and ordered value sets, the interpretation of KerML features requires a more complicated approach compared to the interpretation of OWL properties.

• An introduction to predicate logic in CHAPTER 14 of "Foundations of Computer Science" by A. V. Aho and J. D. Ullman.
• W3C's OWL primer.

Ontological Behavior Modeling (2011)

Bock, C. and Odell, J. 2011. Ontological Behavior Modeling, Journal of Object Technology, https://doi.org/10.5381/jot.2011.10.1.a3

This article first explains the idea that in a modeling language like UML, classes should be considered as classifiers that classify their instances, like in the Web Ontology Language OWL, as opposed to the common view that classes are factories for creating instances and encapsulating code. Then, for integrating the scattered behavior modeling sublanguages of UML, several new elements are proposed:

• For capturing the behavioral components of UML Behaviors as special properties/features called 'steps', a new metaclass Step, specializing Property, is proposed. The range/type of a step property is a Behavior. For instance, a ChangeColor Behavior has two steps: step1 is of type Paint (its values are executions of the Behavior Paint ) and step2 is of type Dry.
• For sequencing the steps of a Behavior, Succession connectors are proposed as special features of the Behavior, connecting its steps by defining temporal precedence constraints on the executions/occurrences admitted for it.
• In addition, a predefined classifier BehaviorOccurrence is proposed to represent the most general Behavior. For BehaviorOccurrence, two self-associations, happensDuring and happensBefore, are proposed for capturing corresponding temporal constraints. An occurrence that is the value of a Behavior step (such as a Paint occurrence) is called a suboccurrence. It must hold for each suboccurrence of an occurrence that it happensDuring the occurrence.
• For supporting the modeling concept of instantaneous events, a new metaclass EventType is proposed to be specialized from Class in the UML metamodel. Both behavior occurrences and event occurrences can be associated through the predefined associations happensDuring and happensBefore. By allowing the range/type of a step property to be an EventType or a Behavior, a Behavior may have both event steps and activity steps, corresponding to a (discrete) process. This also allows having the two predefined steps startEvent and endEvent for all Behaviors.
• For supporting the modeling of object flows and message flows, a new predefined class Transfer is proposed to be specialized from BehaviorOccurrence for classifying occurrences that transfer things. It has three properties: source, target and transferredThing. While an object flow transfers objects between BehaviorOccurrences (for example, an object in a factory may flow from a painting occurrence to a drying occurrence), a message flow transfers messages between objects. A new metaclass Flow, specializing both Connector and Step, is supposed to capture types of transfers that can be sequenced via Successions.

The authors remark that their work is partially based on the Business Process Definition Metamodel from 2008, which already includes certain forms of the modeling concepts Behavior, BehaviorOccurrence, Step, Succession, and (Message) Flow.

KerML has adopted the following elements from this work:

• Steps as behavior-typed features (e.g., for breaking down a composite Behavior into a number of steps).
• Successions as special connector features of Behaviors for sequencing their steps.
• The predefined associations HappensDuring and HappensBefore for defining the temporal semantics of occurrences.
• Flows being both Connectors and Steps.

But why has the metaclass EventType not been adopted? A general concept of events is clearly needed for systems modeling.

Four-Dimensional Ontology (2019)

Bock, C. and Galey, C. 2019. Integrating four-dimensional ontology and systems requirements modelling, Journal of Engineering Design, https://doi.org/10.1080/09544828.2019.1642461

The article makes the following claims:

• "The most basic kinds of things in systems are commonly taken to be objects and behaviours, where behaviours are changes to the objects involved in them." However, the more common term associated with changes of objects is "events", which subsumes actions as well as (completed) activities and processes.
• "The phrase ‘occupy space’ is used with objects, and ‘involve objects’ with behaviours, but ultimately both occur in space". However, it is well-known in Ontology that behaviours/processes only indirectly occur in space via their involved objects, which do have spatial properties such as a location and a spatial extent.
• Both objects and behaviours should be treated "as things occurring in both space and time [...] rather than specifying objects only in space and behaviour only in time", because treating "objects as existing in space and behaviours as existing in time, linking them together to provide time to objects and space to behaviours [...] complicates modelling and analysis with unnecessary linkages, such as one-to-one relations between objects and their histories". But why should a one-to-one association between objects and their histories complicate modelling and analysis? Rather, it seems that forcing systems modelers and developers to identify objects with their history, and not allowing them to consider these separately, is complicating modelling and analysis.

KerML has adopted the following elements from this work:

• Occurrence as a general ontological category and library class that is specialized by the library classes Object and Performance. In UML 2.5.1, the term "occurrence" has already been used, but in a more limited way (as, e.g., in "event occurrence" and the umbrella meta-class "OccurrenceSpecification" for Interactions).

Using SysML for Physical Interaction and Signal Flow Simulation (2017)

Bock, C., Barbau, R., Matei, I. and Dadfarnia, M. 2017. An Extension of the Systems Modeling Language for Physical Interaction and Signal Flow Simulation, Systems Engineering, https://doi.org/10.1002/sys.21380

Systems modeling languages must be used in conjunction with analysis tools, in particular, with simulators for physical interaction and numeric signal flow based on ordinary and algebraic differential equation solvers. These kind of simulation tools are often used separately from system modeling tools, leading to inconsistencies that require additional work to eliminate, preventing multidisciplinary concerns from being reflected in the overall system design. As a result, there is an increasing need for integrating physical interaction and signal flow simulation tools and languages into system modeling under a single framework. In this article, we first present an abstraction of the constructs and semantics these simulation tools and languages have in common, based on earlier reviews. Then, we compare SysML to our simulation abstraction to find the parts of SysML closest to simulation modeling, and to identify simulation concepts missing from SysML. This leads to extensions of SysML to bridge the gaps, illustrated with an example application. Next, we address issues in translating extended SysML models to common simulation tools and languages, including the differences between them. Finally, we validate the approach by applying the extension to an example SysML model, automating the translations in software, and showing that the results execute the same way on different simulation platforms.

• Simulation treats movement of physical substances as uninterrupted movement of their conserved characteristics, such as electric charge, momentum, and entropy, rather than individual movement of the substances themselves, such as electrons, steel, and steam. This makes rates of flow independent of the time interval over which flow rates are calculated.

Update of SysPhS for SysML2: https://github.com/usnistgov/saismo/releases/tag/sysphsv2-prerelease1

SysML Extension for Physical Interaction and Signal Flow Simulation (2021)

Bock, C., Barbau, R., Matei, I. and Dadfarnia, M. 2021. SysML Extension for Physical Interaction and Signal Flow Simulation. OMG Specification. https://www.omg.org/spec/SysPhS/1.1/PDF