Role of reference architectures

A reference architecture is an abstract, idealised architectural model for a whole class of systems in an application domain. It is not taken from any one real system. It describes the main functions, layers and interfaces that a system in that domain should have.

Sommerville separates two kinds of domain-specific architecture:

• Generic models – bottom-up abstractions taken from existing real systems (e.g. a generic compiler model).
• Reference models – top-down, more abstract models derived from a study of the domain; they show an ideal architecture.

Role of reference architectures in system design

1. Starting point for design – designers begin with the reference model and adapt it to their requirements instead of starting from nothing.
2. Standard for comparison – different systems in the domain can be compared against the same reference model.
3. Evaluation – a proposed design can be checked to see whether it covers all the functions the reference model lists.
4. Communication – it gives a common vocabulary for the domain, so teams and vendors understand each other.
5. Interoperability and standards – products built against the same reference model can work together.
6. Reuse of domain knowledge – it captures experience of experts about how such systems should be structured.

Example 1: OSI reference model

The ISO OSI model is a reference architecture for communication systems. It defines seven layers, each using the services of the layer below:

+--------------------+       +--------------------+
| 7 Application      |       | 7 Application      |
| 6 Presentation     |       | 6 Presentation     |
| 5 Session          |       | 5 Session          |
| 4 Transport        |       | 4 Transport        |
+--------------------+       +--------------------+
| 3 Network          |       | 3 Network          |
| 2 Data link        |       | 2 Data link        |
| 1 Physical         |       | 1 Physical         |
+--------------------+       +--------------------+
          |      communications medium     |
          +--------------------------------+

Real protocols (e.g. TCP/IP) do not follow it exactly, but designers use it to place functions (routing in layer 3, reliable delivery in layer 4) and to compare protocol stacks.

Example 2: ECMA reference model for CASE environments

This model describes the services a CASE (software engineering) environment should provide:

• Data repository services – store and manage data items and their relationships.
• Data integration services – manage groups of items and relations between them.
• Task management services – define and run process models.
• Message services – tool-to-tool and tool-to-service communication.
• User interface services – presentation and interaction.

Individual tools plug into "tool slots" and use these services (the "toaster model"). A team building a new CASE environment uses it to check that no service is missing and to compare its environment with others.