Relationships and Constraints
In many drawing tools, a line between two boxes is just a line — a visual connector with no meaning. In Farkitect, relationships are first-class model elements with their own types, properties, and rules.
Relationships Are Elements
Section titled “Relationships Are Elements”A relationship in Farkitect is a model element, just like any other. It has:
- A name — descriptive label (e.g., “FQ Vessels serves Fleet Dashboard”)
- A classifier — the M2 relationship type it’s an instance of (e.g., “Serving”)
- A source and target — the two elements it connects
- Properties — typed fields defined by the M2 relationship type (e.g., “Service Level”)
- A presence in the Explorer — relationships appear in the tree as children of their parent package
This means relationships are:
- Queryable — you can filter, catalog, and export them
- Persistent — they exist in the model independently of any diagram
- Typed — the M2 type determines their notation, constraints, and properties
On a diagram, relationships render as edges connecting two nodes. But the edge is a visual representation — the relationship itself lives in the model.
Relationship Types
Section titled “Relationship Types”At the M2 level, relationship types define:
| Aspect | What it controls |
|---|---|
| Notation | Line pattern (solid/dashed/dotted), end markers, line and label colours (light and dark) |
| Verbs | Source-to-target and target-to-source descriptions (“serves” / “is served by”) |
| Constraints | Which element type combinations are valid |
| Properties | Typed fields that instances carry |
| Multiplicities | Whether to show cardinality labels on diagram edges |
Some metamodels define many relationship types (ArchiMate has 11), others just a few. The number and specificity of relationship types depends on how precisely the metamodel wants to model connections.
Pair-Wise Constraints
Section titled “Pair-Wise Constraints”Constraints are the mechanism that gives relationships structural meaning. A pair-wise constraint says: “This relationship type is only valid between these specific source and target element types.”
For example, in the ArchiMate metamodel:
- A Serving relationship is valid from an Application Component to an Application Service — but not between two Business Actors
- A Flow relationship is valid between Application Components — but not from a Business Actor to a Technology Node
Constraints are defined as valid pairs: a list of (source type, target type) combinations. When a user tries to draw a relationship on the Canvas, Farkitect checks the constraints and only allows valid combinations.
Why constraints matter
Section titled “Why constraints matter”Without constraints, any relationship type could connect anything to anything. This leads to models that look structured but are actually meaningless — like a sentence with correct grammar but no sense.
Constraints enforce the structural rules of your modelling language. They prevent:
- Nonsensical connections (a person doesn’t “serve” another person in an ArchiMate sense)
- Accidental misuse (selecting the wrong relationship type from the picker)
- Inconsistency (different modellers using different conventions)
Seeing an element type’s constraints
Section titled “Seeing an element type’s constraints”You don’t have to open each relationship type to find out what an element type can connect to. Select the element type in the Explorer and the Context panel lists every relationship type it can take part in, grouped by verb and direction, including rules inherited from its supertypes. Select a relationship type to see its Constraints, one allowed pair per line. See Workspace — Context.
Unconstrained relationships
Section titled “Unconstrained relationships”Not all relationship types need constraints. A general-purpose Association relationship might intentionally allow any source/target combination — it’s a way of saying “these two things are related” without specifying how. The metamodel designer decides.
Source and Target
Section titled “Source and Target”Every relationship has a source and a target — a directionality that gives the connection meaning:
- The source is where you start drawing on the Canvas
- The target is where you end
- The source-to-target verb describes the forward direction (“serves”, “manages”, “belongs to”)
- The target-to-source verb describes the reverse (“is served by”, “is managed by”, “has member”)
The source-to-target verb also names new relationships: connecting FQ Vessels to Fleet Dashboard with a Serving relationship names it FQ Vessels serves Fleet Dashboard. See Name a relationship.
Some relationship types are visually directed (arrow at the target end). Others are undirected (no markers on either end). The directionality is semantic — it affects which end the constraint checks apply to — regardless of whether there’s a visual arrow.
Relationships on Diagrams vs in the Model
Section titled “Relationships on Diagrams vs in the Model”A relationship can appear on multiple diagrams — just like an element. If FQ Vessels serves Fleet Dashboard, that relationship might appear on:
- An Application Cooperation diagram
- A detailed FQ Vessels internal view
- A dashboard architecture diagram
It’s the same model relationship rendered in three different visual contexts. Removing the edge from one diagram doesn’t delete the relationship — it just removes it from that view.
To delete a relationship from the model entirely, delete it from the Explorer or use Ctrl+Delete / Cmd+Delete on the Canvas.