All systems must have some way to separate and protect their internals from the external environment, because without such protection, leaving the internals open to the destructive forces of environment, the system will cease to exist very quickly.

For open systems such boundary should not only protect the system, but also allow it to interact with its environment (e.g. pass information, energy and matter in a controlled manner and safely for the system).

In the case of natural organisms such boundary is for example cell membrane or skin of more complex organisms, and in case of software systems such border is formed out of the interfaces through which the system interacts with the other systems.

The same way, as with the natural organisms, it is also with the software systems – when the boundary of the system is broken (or lost) it leads to quick destruction (or death) of the system.

All systems must have some way of separating and protecting their internals from the external environment, because without such protection, leaving the internals of the system open to the destructing forces of the environment, the system will cease to exist very quickly. For open systems such boundary should not only protect the system, but also allow it to interact with its environment – pass information, energy and matter in a controlled manner, which is safe for the system (so that nothing dangerous and potentially destroying will be able to enter the system). When the border between external world and internals of the organism is broken or removed, all organisms cease to exist (i.e. die) and will be decomposed – same is the case with the software systems, and to be able to talk about a specific software system at all, we need to define (and control over time) the system scope (i.e. define what are the parts of the software system and what are not).

Additionally to allow software system to interact with its environment in a controlled manner, we need similar mechanisms like in the case of other open systems (incl. natural organisms), which allow software system to exchange information with the external environment in a controlled and safe manner.

• In case of natural organisms such boundary is cell/plasma membrane for the cells, epidermis for plants and skin for the animals, later being rather complex and large organ.
• In case of social systems like states, such boundary is defined border together with the border guard and customs organizations.
• In case of the software systems, such boundary is composed of the interfaces offered to external systems (which could be software systems, hardware systems, users, etc.) for connections, and such components of the software system that connect directly to external systems.

If software systems need to maintain the control over their internals and avoid destruction/corruption by external forces, they need to enforce that all exchange of information between the software system and its environment happens through the well-guarded and strict interfaces. As soon as the interfaces are bypassed and software system internals are directly accessed and manipulated from its environment without any restrictions, or software system internals are accessing ts environment without any control, the software system starts to “die” (i.e. gradually corrupt to the point where it cannot be maintained anymore and must be replaced by some other system).

What is an interface

There are many definitions for the interface:

• An interface is a boundary across which two elements meet and interact or communicate with each other [CMU SEI].
• Interface is an interconnection and inter-relationships between, for example, people, systems, devices, applications, or the user and an application or device [Open Group TOGAF 9.2].
• An external active structure element, called an interface, represents a point of access where one or more services are provided to the environment [Open Group ArhiMate 3.2].
• An Interface is a kind of Classifier that represents a declaration of a set of public Features and obligations that together constitute a coherent service. An Interface specifies a contract; any instance of a Classifier that realizes the Interface shall fulfill that contract [OMG UML 2.5.1].
• Interface is [IEEE SE VOCAB]
• a shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics, or
• a hardware or software component that connects two or more other components for the purpose of passing information from one to the other, or
• an abstraction of the behavior of an object that consists of a subset of the interactions of that object together with a set of constraints on when they can occur.

As we can see, interface is most often seen as the boundary of a system or a special component, through which the environment can interact with the system and which is abstracting (or mediating) the behavior of the system for the environment (i.e. interface is providing a “language” and the mechanism to communicate with the system and request/access the services it provides).

From the differences of these definitions it comes clear that in some sense the interface can be also viewed as a contract between two systems, because it embodies a set of conventions which both systems must follow for the interaction to be successful.

This duality comes from the fact that there are two kinds of (architectural) structures in the software systems [CMU SEI], which should not be mixed:

• module structures, which reflect how the software systems code (which has to be constructed or procured) is structured, and
• component and connector structures, which reflect how the software system elements (components) are structured and connected (via connectors) at run-time.

If we look at these structures, then both these have interfaces, but:

• in module structures interface defines what is available (visible) to other modules, it is the mean of communication between the developers:
  
  
  
• in component and connector structures:
  • component interface, called port, defines the potential interactions (behavior) of component with its environment, and
  • connector interface, called role, defines the ways how connector can be used (specifying protocol of interaction – i.e. prescribing what patterns of events or actions are allowed to take place over the connector).
    
    
    

There could be only one module interface of given type (signature) per one module, but there could be many component and connector interfaces of same type per components and connectors.

Following rules apply for the component and connector structures:

• Attachments can be made only between compatible ports and roles – components can be attached only to connectors, not to other components and vice versa.
• In case of interface delegation component ports can be associated with one or more ports in an “internal” structure (similarly for the roles of a connector) – this allows us to progress from the “black-box” view to the component to the “white-box” view.

Characteristics of an interface

There are several important characteristics that an interface as the boundary and a contract between two systems must define.

When looking at the interface as a contract between two systems, interface must answer the following questions:

• Services – what services or functions can be accessed through the interface (i.e. operations, actions, …)
• Content – what data flows through the Interface (i.e. entities, attributes, value sets, …)
• Quality of Data – what are requirements on data that flows through the Interface (i.e. consistency, completeness, …)
• Protocol – what is the order and nature of (inter-)actions taking place at the interface (i.e. synchronous conversation, asynchronous conversation, …)
• Quality of Service – what are the requirements to the actions taking place at the interface (i.e. timeliness, security, …)

All these questions need to be answered by the description of the interface.

Although in some sense the interface, which connects two systems together as a contract between those systems, is positioned between these two systems, it still usually belongs to one of these systems.

Which of the two systems “owns” the interface and therefore defines the contract between two systems, is the decision that the systems designers have to make:

• interface can be “owned” by the system that provides the services to the other system, in which case it is usually called provided interface, or
• interface can be “owned” by the system that requires the services from the other system, in which case it is usually called required interface.
  

Why we need interfaces

As was described above, module interfaces are needed for communication between the developers – defining these things that are visible to the developers using the module, while hiding all other information about the module, isolating this way the developers, who will use the module from the developers who will develop and maintain the module.

Component and connector interfaces are needed to control the information and control flows between the elements of the running software system, and this way support isolation of components, modifiability, reusability, and help manage the complexity in the run-time structures of the software system.

...