Advanced Metamodel Features

This tutorial covers advanced M2 metamodel features that let you build richer, more expressive modelling languages. You’ll extend the Farquind Org Map with class generalization, owned elements, and display templates.

Prerequisites: You’ve completed Adding Properties to Your Metamodel and have the Farquind Org Map metamodel with Person, Team, System, properties, and enumerations.

1. Class Generalization (Superclasses)

Generalization lets one element type inherit from another — sharing properties, notation, and behaviour. This avoids duplicating property definitions across similar types.

Create a superclass

Suppose you want both Person and Team to share a common Description property. Rather than adding it to both, create a superclass:

1. In the People & Teams layer, create a new element type called Organisational Entity
2. Add a property: Description (String, 0..1)
3. This element type will serve as the abstract superclass — you can mark it as abstract in the Properties panel so it doesn’t appear in the Palette for direct instantiation

Set up generalization

1. Select the Person element type
2. In the Properties panel, find the Superclasses field
3. Add Organisational Entity as a superclass
4. Repeat for the Team element type

Now both Person and Team inherit the Description property from Organisational Entity. When a user creates an M1 Person or Team, the Description field appears automatically alongside their own properties (Title, Department, etc.).

Inherited properties in action

In your M1 model, select any Person or Team instance. The Properties panel shows both:

• Own properties defined directly on the element type (Title, Department for Person)
• Inherited properties from the superclass (Description from Organisational Entity)

Inherited properties behave identically to own properties — they can be edited, appear in catalogs, and render in diagram compartments.

2. Owned Elements and Compartments

Owned elements (also called subordinate elements) are elements that live inside a parent element and appear in a compartment on diagrams. The classic example is attributes inside an entity in a data model.

Define an owned element type

Suppose you want System elements to show their key interfaces as a list inside the node on diagrams.

1. In the Technology layer, create a new element type called Interface
2. Configure its notation (smaller default size, no standalone palette entry needed)
3. Add a property: Protocol (String, 0..1)

Configure the parent to accept owned elements

1. Select the System element type
2. In the Properties panel, find the Notation section
3. Look for Subordinate Types configuration
4. Add a subordinate type entry:
   • ID: interfaces
   • Label: Interfaces
   • Classifier: Interface (the owned element type you just created)
   • Display template: {name} : {Protocol}

Add a compartment to the notation

Still on the System element type’s notation, add a compartment:

1. The existing compartments show name (the element name)
2. Add a new compartment:
   • Content type: subordinates
   • Subordinate type ID: interfaces
   • Label: Interfaces
   • Show label: true

Test in M1

1. In your M1 model, select FQ Vessels
2. Right-click > New Owned Element (or look for the Interface option)
3. Create interfaces: Telemetry API, Fleet Dashboard API, Alert Webhook
4. Set Protocol values: REST, GraphQL, Webhook

On the diagram, FQ Vessels now renders with a compartment showing:

┌─────────────────────┐
│      FQ Vessels      │
├─────────────────────┤
│ Interfaces           │
│ Telemetry API : REST │
│ Fleet Dashboard : GQL│
│ Alert Webhook : Hook │
└─────────────────────┘

The display template {name} : {Protocol} controls how each owned element renders in the compartment.

3. Display Templates

Display templates control how owned elements render inside their parent’s compartment. They use {propertyName} placeholders that are replaced with actual property values.

Template syntax

• {name} — the element’s name
• {PropertyName} — a property value by name
• {PropertyName? [suffix]:} — conditional: only show the suffix if the property has a value
• Literal text is included as-is

Examples

Template	Renders as
{name}	Telemetry API
{name} : {Protocol}	Telemetry API : REST
{name}{Protocol? ({Protocol}):}	Telemetry API (REST) or Alert Webhook if no protocol

4. Relationship Multiplicities

Multiplicities specify how many instances of each end can participate in a relationship — similar to cardinality in data modelling.

Configure multiplicities on a relationship type

1. Select the Belongs To relationship type
2. In the Properties panel, look for the Show Multiplicities toggle in the notation section
3. Enable it

When multiplicities are enabled, edges display source and target multiplicity labels on the diagram (e.g., “1” at the Team end, “0..*” at the Person end — one team has many members).

Multiplicity values are set on individual M1 relationship instances via the Properties panel — Source Multiplicity and Target Multiplicity fields.

What You’ve Learned

• How to create superclass element types and set up generalization for property inheritance
• How to define owned element types that live inside parent elements
• How to configure compartments on parent element notation to display owned elements
• How display templates control the rendering of owned elements in compartments
• How to enable and use relationship multiplicities

Next Steps

• Setting Up Your Organisation — Configure your Farkitect organisation and invite team members
• How to define owned element types — Quick reference for the owned elements workflow