Intent
Be explicit about identifying and documenting interfaces
Motivation
As the complexity of products grows, we need robust decomposition (see Black Box). This in turn requires stability in the interfaces. That's why interfaces need special attention. Having the right interfaces in the right places can make a huge difference in being able to react to changes, robustness and flexibility.
Interfaces exist on many levels: It can be about connecting two physical components. It can be about consuming software libraries. It can be about a combination of hardware and software (e.g. a USB connection). It can be about talking to machines or humans. The key here is to recognize those interfaces that matter with respect to robustness and flexibility, and to document those properly.
Interfaces also go hand in hand with architecture, which provides a framework for placing the interfaces.
Applicability
Use the pattern when:
- You define your architecture and align it with your product description
- You design a product line, or modular product
- You intend on consuming third-party components, especially if they will be exchanged at run time
Structure
We distinguish between physical, signal and software interfaces. Physical interfaces are well understood and typically unproblematic (liquids, gases, forces, electricity, etc,). Signals are typically carried by an electric connection and follow a protocol. Last, software interfaces can be completely independent from physical interfaces and concern the interplay of software.
At a minimum, classify your interfaces properly according to the above criteria and provide an informal description. From there on, you can get as detailed as you need to be, but make sure not to get lost in the details.
On the lower level, you may need to get more formal, by using a language like SysML (systems) or UML (software) for making your interfaces more concise.
User interfaces are yet in a separate class and are generally on the fringe of this pattern. Also, user interface design is typically its own discipline.
Last, support your interface description by providing a graphical map (this is typically part of the architecture). Pick the level of formality that is suited for your environment.
Consequences
The pattern has the following benefits and liabilities:
- Benefits:
- Provides robustness and helps you clarify your architecture
- Provides flexibility
- Limits propagation of changes
- Liabilities:
- Risk of over-architecting too early
Implementation
Depending on the level of formality that you need, you can simply create an informal component description where you list all the interfaces. On the other end of the spectrum, you use a dedicated modeling tool (Enterprise Architect, Cameo, etc.).
Related Patterns