Treat Interfaces Like System Components |
 |
 |
 |
| Written by Graham Stoney | |
|
A typical complex system has multiple components, connected via interfaces. Interfaces tend to be neglected, or their definition left too late in the design process. I think they should be given the same priority as system components, and perhaps even higher priority. In software terms, you might describe this as “treating interfaces as first-class objects”. Interfaces often outlast one or more of the components that connect to them. For example, the Ethernet interface is widely used, and is defined by an international standard. Many companies build Ethernet adaptors which implement this interface. An individual Ethernet adaptor should not be confused with the interface that it implements. Often engineers treat interfaces as though they were “owned” by one or other of the pieces of equipment that they connect. I think this is a mistake; interfaces are owned by the system, and implemented on each system element that use them. Interfaces have requirements that they must meet, and need to be designed in order to efficiently meet the needs of the system in which the operate. Interfaces also impose requirements on the equipment that implement them, and need to be designed with feasibility in mind. There's no point specifying a gigabit Ethernet interface in a system where the components have 8 bit micro-controllers. The illustration below shows how the system design imposes requirements not just on the system components, but also on the interfaces between them:
Interfaces also form natural partitioning boundaries between design teams, subcontractors and off-the-shelf components. They need to be well-defined early in the project for these teams to work concurrently. Interfaces are like system components in that they have requirements, whether you choose to document them as such or not. Interface protocols do not simply arise out of nothing: they are the result of a design process, and design processes work better when the input requirements are well codified and understood. For an example of an interface protocol requirements document, see RFC1547: Requirements for an Internet Standard Point-to-Point Protocol. It describes the requirements for a new link layer protocol that were ultimately satisfied by the PPP protocol defined in RFC1661: The Point-to-Point Protocol (PPP). Note that RFC1547 does not define a protocol; it just describes the characteristics that the protocol must have. Social Bookmark this page:         
|
