A software component is said to exhibit a high degree of cohesion if the elements in that unit exhibit a high degree of functional relatedness. The notion of coupling is an indication of the strength of interconnections between program units. Highly coupled systems have strong interconnections, with program units depending a great deal upon each other. It is generally assumed that the properties of low coupling and high cohesion are highly desirable in a software component [Cons 79]. But an interesting property of components well engineered for reuse is that they tend to individually have low cohesion and collectively have high coupling.
Consider again the Sort concept. Although the specification states that "<=" must totally order Element, there is absolutely no language support for this. It is conceivable that the "<=" operator could be instantiated with a randomizing operator, arbitrarily returning true or false independent of input. This would lead to a sequence "randomizer" rather than a sequence sorter.
As another example, consider the Recursive_Quick_Sort and Partition algorithms. Clearly the semantics of the Sort concept only make sense when these two algorithms are taken together, as there is no language support for guaranteeing the Partition semantics to the Recursive_Quick_Sort control program. Clearly each of these components need to be used within the context of a generic architecture of components.
This is fine as long as one has a complete and correct generic architecture to access. Unfortunately, problems arise when such an architecture is being developed and tested. Since the complete semantics of a system can only be determined by instantiating all components in a generic architecture, testing the correctness of individual generic components is extremely difficult.
As an example, consider again the Recursive_Quick_Sort and Partition algorithms. In order to test the correctness of the control program, it needs to be instantiated with Partition contentual context. Furthermore, in order to test the correctness of the Partition algorithm, it needs to be instantiated with Element and El_Sequence conceptual context.
An approach to dealing with this problem can be found in the MIL work of Goguen [Gogu 86] and Tracz [Trac 89]. Goguen takes the view that we can specify not only the abstract semantics of a concept, but the abstract semantics of its conceptual context as well. The latter context specifications take the form of theories, which are then mapped to actual conceptual context through a view mechanism.
The examples below take their syntax from Goguen's LIL (Library Interconnect Language). In addition, Tracz uses an extension of LIL, LILEANNA (LIL extended with ANNotated Ada [Trac 89,Luck 84]), to explore ideas similar to those presented in this section.
Associated with the Sort concept are Partially ordered set and Sequence theories:
theory POSet istype Element;
function "<="(L,R: Element) return Boolean;
axioms for all E1,E2,E3: Element =>
E1 <= E2,
(E1 <= E2 and E2 <= E3 -> E1 <= E3),
(E1 <= E2 and E2 <= E1 -> E1 = E2)
end TOSet;
theory Sequence ...
The Sort concept can then be defined as follows:
generictype X is POSet;
type El_Array_Ind is (<>);
type El_Sequence is Sequence;
procedure Sort(Els: in out El_Sequence);
-- effects: modifies Els to contain the original values of
-- Els totally ordered by "<=" of X.
When this is done for each component of a generic architecture, they are effectively decoupled into highly cohesive modules whose semantics are completely determined by the semantics of the concept and context.
The same argument can be made for content and its corresponding contentual context. Work dealing with the verification of generic algorithm correctness has been done in [Muss 88], including a complete example of the verification of a generic partition algorithm.