Skip to main content

Interfaces

What is an interface?

Interfaces are very similar to designs. An interface defines a set of attributes that collectively describe a category of things, such as a type of asset or task. However, you can't create an item from an interface!

The purpose of an interface is to be implemented by related designs, so that they inherit the interface's attributes alongside their own. In this way, an interface lets you standardise parts of your data model by defining a set of generic attributes that can be shared across multiple designs (and even other interfaces).

Continuing our toy example, the Minifigure design below implements the Toy and Lego interfaces, and therefore inherits their attributes (Manufacturer, Min Age, MRP, Model Number). To avoid redefining these generic attributes across multiple designs, they're defined in two interfaces that multiple designs can implement as needed.

An item of the Minifigure design can also be considered an item of the Toy and Lego interfaces.

An example minifigure design with attributes inherited from interfaces
Note

An interface can also implement other interfaces!

Target multiple designs

Another use for interfaces is to target multiple designs at once. When using Alloy's features, you're often prompted to choose a design for the feature to focus on or apply to. By choosing an interface instead, you can target the items of all designs that implement it!

For example, imagine a Playground Assets interface that's implemented by three designs: Swings, Seesaws and Roundabouts. To display items from all those designs on the map, you can define a single layer that queries the Playground Assets interface.

Targeting a single interface can save time and avoid repetition. It also provides flexibility, as any future designs can be incorporated by simply implementing the interface.

Note

When targeting an interface, be aware that only the interface's attributes will be exposed (e.g. if you perform an AQS query on the Defects interface to fetch all defect items, it won't include data for attributes defined in your custom Tree Defects design).

Attributes

Like designs, an interface can have any number of defined attributes.

An attribute is a data field that represents a single characteristic of the concept described by the interface (e.g. dimensions). Link attributes are a special type that can reference items of a specific design/interface (e.g. the Jobs interface has a Fixed Defects attribute that links to the Defects interface).

When a design/interface implements an interface, it inherits all of the interface's attributes. This includes any attributes the interface itself has inherited from other interfaces!

In the following diagram, the Example Custom design directly inherits the black attributes from the Items interface and the green attributes from the Assets interface. However, it also indirectly inherits the red attribute from the Items With Reports interface.

A diagram illustrating direct and indirect attribute inheritance

Appearance

All interfaces have a uniform blue appearance to differentiate them from designs.

Like designs, every interface has:

  • Icon and Colour properties that determine how designs and their items look.

  • Title and Subtitle properties that determine how items of the designs are labelled.

The Inspections interface's properties

However, properties will only be inherited if they're blank on the designs/interfaces implementing the interface!

For example, both designs below implement the above interface. The Generic Inspections design has no properties set, so it inherits them all. However, the Tree Visual Inspections design has values for all its properties, so it inherits none.

Two designs that implement Inspections. One has inherited properties. The other has its own
Two items of the above designs. One has inherited properties. The other has its own

Geometry types

Like designs, every interface has a Geometry attribute that can store coordinate data. By default, the attribute is optional and accepts any geometry types (e.g. point, line, polygon).

Alternatively, you can configure an interface's properties to make geometry Required, so that a value must be entered when creating/editing items of a design that implements the interface. You can also limit the types of geometry that can be stored, including none.

However, geometry properties will only be inherited if they're blank on the designs/interfaces implementing the interface!

Context

Every interface has a Context property that indicates the interface's origin. If set to Customer, it was created by your organisation and can be edited freely. Otherwise, it's a protected system interface.

System interfaces are included with Alloy to provide core functionality and help you get started (e.g. the Defects and Tasks interfaces). While system interfaces can't be edited or deleted, they can be extended with extra attributes.

Details

The possible context types are:

  • Core - the interface is provided with Alloy and required for system functionality. It can't be deleted but you can:

    • edit these properties: Name, Icon, Colour, Title, Subtitle

    • add, edit or remove any custom attributes

    • implement or remove any extra interfaces

  • Module - the interface belongs to an optional module that was installed. Same restrictions as Core.

  • Package - the interface was created by our system architects as part of a custom solution for your organisation. Same restrictions as Core.

  • Customer - the interface was created by your organisation. Therefore, you can freely edit or delete it, providing your user account has permission to do so.

What is a DoDI?

When using Alloy (or reading these guides), you may encounter the term DoDI.

It stands for Design or Design Interface and refers collectively to designs and interfaces, as they share a lot of the same characteristics.