sysmlsysml2

Why is feature typing a form of specialization in KerML/SysML?


SysML v2 is based on the new Kernel Modeling Language (KerML).

In KerML, feature typing relates a feature (such as Person::employer) to its co-domain (such as Organization).

As a type, a feature semantically corresponds to a binary relation formed as a subset of the Cartesian product of its domain and its co-domain.

In KerML, feature typing is a form of specialization, instead of a plain relationship. This implies that its special type, the feature concerned, specializes its general type, the feature's co-domain. That is, employer specializes Organization, and consequently, any employer pair, such as (Tom, IBM), is an instance of Organization, which is strange.

What is the reason for this non-standard construction in KerML's metamodel?


Solution

  • In KerML, features indeed represent relationships, but semantically, they classify sequences (for now, let us interpret this as some kind of navigation). If you look at them this way, navigating through the employer feature gets you to a set of Organizations, which is a subset of all the things classified as Organization. Therefore, employer is a kind of Organization.

    Furthermore, one of the new features of SysML v2 is usage-oriented modeling, which lets you specialize a type in the context of its usage without creating a new, more special definition. This is supported by features being types and specializing their featured types. For example, you could say that (in addition to everything inherited from Organization), employer also has a feature salary.

    Long story:

    In ontologies, semantics are generally given in terms of classification. The set of elements classified by a type is called its extent. The set of things being classified is generally referred to as the universe (often extended by the set of all possible pairs of those things, or in KerML, N-tuples that we call sequences). The mapping from the model elements to the extents is called an interpretation. The semantics is then given by defining axioms and instantiating them for every model element. his results in a set of assertions about the extents and their relationships, allowing us to check if a given universe and interpretation satisfies the model.

    The fact that features specialize their featured types means that the extent of Organization will contain sequences of length two (and more). There is an axiom that if this is the case, the extent must also contain the 1-tail of these sequences (i.e., if Tom's employer is IBM, IBM is an Organization). However, IBM itself is not an employer. It can be the value of an employer (when it is paired with a person), but not an employer itself.

    The less intuitive part is that the extent of Organization will now contain both IBM and Tom's employer (the value of which is also IBM, but the instance of the feature is actually a pair now). The extent of salary will contain triples: a person, an organization, and a number. We can see that this allows employers of different people to have different salaries assigned to them, even if they are the same company.

    To understand this, we have to observe that the KerML semantics is defined similarly to other ontologies, and it is not reduced to a labeled graph, as one might expect, but to assertions about the presence or absence of navigations on such a graph (but this interpretation is not mandatory). So the semantics really says that if you look at your universe and your interpretation (which is a function from model elements to sets of sequences, without providing further interpretation), you have to:

    The above assumes you want to include IBM and Tom in your universe. As noted above, the semantics will only give you assertions that you can use to check if your universe and interpretation satisfy the model. It will not (or only very rarely) force you to include something in any of them, let alone instruct you on how to build them.