4 An analogy of software composition and function application

Software components are modules that are replaceable by other modules in a composed software system. The substitutability of a module by another sometimes is and sometimes is not valid. There are two questions: What is the difference between a module and a component and when does a module substitute another?

Substitutability is the essential concept in (discrete) mathematics. It occurs whenever a function argument is replaced by another argument. Translated to the replacement of modules, this gives an answer to the first question.

Let me identify a module with an argument and the composed software system with a function. Then, I characterize the difference between a module and a component as follows.

• A module corresponds to an argument that is considered in isolation and
• a component corresponds to an argument that is considered in the context of a function application.

After having answered the first question, can I now answer the second one? - When does the substitutability of two modules hold? Yes, I can. The answer is: when they are equivalent! The answer sounds trivial. Somebody, who is not familiar with mathematical equivalence, will think that this is just a play on words. No, this is more than a pun. The trick is that equivalence needs to be defined, which involves more than a simple paragraph in a position paper.

In fact, the approach pursued is refinement calculus is more general. Equivalence is weakened to refinement (implication) and substitutability to monotonicity. Equivalence is symmetric and symmetry is unnecessarily restrictive. If two components A and B are equivalent, it means that A may be substituted for B and B may be substituted for A. This is not necessary. Refinement is an order relation that is not symmetric. If component A is a refinement for B then A may substitute B in a composed software system, but not necessarily vice-versa. With refinement, a wider space of feasible replacements than with equivalence is achieved.

Why this generalization? The reason is that the replacement of abstract specifications by concrete implementations is asymmetric. Abstraction and refinement are directed in opposite directions. Abstraction omits details and refinement adds them. The abstraction level or similarly the refinement level corresponds to the degree of non-determinacy.