Extension Patterns - INSPIRE data specification extensions

The Purpose of Patterns

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the designers or programmers can use to solve common problems when building a system.

Software design patterns falls into multiple categories such as structural and behavioural patterns. Structural pattern show relationships between classes that are static. In our extension design context, we define several new categories of design patterns. Based on the information given for each pattern, you will be able to make informed choice about how to design your model extension, and how to make it INSPIRE compatible.

Types of Patterns for INSPIRE Extensions

Model extension design as described in the extension methodology is a hierarchical top-down process, where you first design a wide scope, and then drill down to make individual aspects concrete. We start at the level of the entire model, then proceed with adding classes, and then define these classes in detail by adding properties. For each of these phases, there are different patterns you can apply:

Patterns for Model compliance: These patterns define restrictions you can apply to ensure compliance of your model to INSPIRE and to other frameworks where you want to comply to.
Patterns for adding classes and properties: These patterns describe how one or multiple classes are linked to classes in the INSPIRE data specification you'd like to extend. If in another language they describe which language features you use to implement them, and what consequences there are on a conceptual and implementation level.
Patterns for modifying properties: Property modification patterns describe how you can extend individual properties, e.g. by adding new constraints or by extending code lists. They also include consequences there are on a conceptual and implementation level.

Patterns for Model compliance

These patterns define restrictions you can apply to ensure compliance of your model to INSPIRE and to other frameworks. You might also have a set of national or regional regulations that fit this description, so make sure you capture those as a specific Model compliance pattern for your work as well.

Patterns for adding classes and properties

These patterns describe how one or multiple classes are linked to classes in the INSPIRE data specification you'd like to extend. They allow you to add new classes and also to add properties. The patterns describe which language features you use to implement them, and what consequences there are on a conceptual and implementation level.

If you are wondering when to use which of these patterns, here is a table summarizing the indicators when to use which pattern. Answer each of the questions and pick the pattern where the balance between + and - is the most positive. When multiple patterns get the same score, use the one to the top of the list, as these are generally easier to implement.

Pattern Name	When to use	When not to use
Association	Do your associated objects have different lifespans? Is there a many-to-many relationship between your objects? Are your objects maintained in different systems or managed by different organisations?	Do you need strong coupling because one part can't exist without the other meaningfully? Are you associating more than two classes?
Inheritance	Do you want to create an association from an existing INSPIRE class? Is there a semantic `is-a` relationship between your class and the INSPIRE class, and both classes are in the same domain? Do you want to automatically keep your model compatible when the INSPIRE superclasses change?	Do you want to limit complexity brought in via the superclass? Should your class have an equal relationship with multiple INSPIRE classes (or other classes from a local standard)?
Aggregation	Is there a whole-part relationship between the objects? Is the lifecycle of the parts linked to more than one whole? Inheritance is not applicable because the ```is-a``` statement is not true?	Do you want to relate objects that are equal peers (e.g. neighboringHouse)? Do the objects have a fully dependant lifecycle?
Composition	Is there a whole-part relationship between the objects? Is there exactly one whole that contains one or more part objects? Is the lifecycle of the composed objects identical?	Do you need a many-to-many relationship between the whole and parts? Do you control the part object's lifecycle?
Multiple Inheritance	Does your new class have to be compatible with an INSPIRE class and local standard classes? Do you want to use a common set of properties with consistent property names to new multiple subclasses of INSPIRE classes?	Does one of the other patterns also satisfy your requirements? Do you want to inherit from multiple classes from the same hierarchy? Do you need to bring in only a single property or a set of unrelated properties from the mixin(s)? Do you need the mixin conceptual relationship to be visible in the logical schema as well?

Patterns for modifying properties

Property extension patterns describe how you can modify individual properties, e.g. by adding new constraints or by extending code lists. They also include consequences there are on a conceptual and implementation level.