Example Systems viewed Transformationally

A correspondence between example system mechanisms and that of transformation systems was established and is summarized in the following table:

 
Table 1: Transformational view of several generic architecture systems

Discovering how the instance systems fit into the transformational perspective led to a number of insights about how or why the various systems worked. As examples:

• System ``inputs'' mixed different kinds of knowledge needed by a transformation system. This suggests that generic architecture systems are likely to have mixed input information whose parts can be classified, which helps explain why such input information is needed to enhance automation or output quality. The sample systems mixed, to some degree, specification and control knowledge in their inputs:
  • Functional specification:
    Sinapse: PDEs
    Predator/P++: Name/signature of desired system function
    RESOLVE: Predicate calculus specification of behavior supplied by a component.

  • Control knowledge:
    Sinapse: Decision resolutions controlling synthesis process
    Predator/P++: Explicit specification of choice of refinement of sub-components
    RESOLVE: Not in specification [user interactively selects from catalog]

• One can't hide from control knowledge; it is present in all the systems in different forms.
  • Sinapse has explicit control knowledge, built into the system
  • Predator/P++ uses supplied control-knowledge to apply component refinements
  • Resolve leaves choice of refinement to the user. But he must choose.

• The key notion of refinement appears in each system in different forms, with differing levels of robustness. How robustness is ensured is important if we wish to trust systems produced by generic architecture schemes.
  • For each Sinapse abstraction, there are multiple sets of transforms that refine the abstraction consistently; set members are applied incrementally.

  • For each Predator abstraction (``realm''), there is a set of components, each being a monolithic refinement. Each refinement may introduce new abstractions which must be further refined; if the new subcomponents are refined correctly, then the refinement is itself correct.

  • RESOLVE specifications are monolithically refined only when Goguen-style constraints are satisfied.

  Sinapse has multiple sets of transforms for which selected subsets must be applied consistently. Consistent transforms are applied individually, interleaved with other actions, i.e., the refinement step is not monolithic. This is accomplished by establishing an explicit intent, recorded by the resolution of a design decision, and only selecting transforms which are marked as consistent with that intent. A similar method was used for the Draco transform system [Neighbors84] in which applied transforms asserted they provided certain properties by posting a tag symbol representing those properties, and potentially applicable transforms required the presence of transform-specific tag symbols to become truly applicable. This method for consistent refinement is documented in [Katz93].

  Some Predator components, while having the same conceptual specification and identical signatures by virtue of being members of the same ``realm'', do not always provide the functionality required by a true refinement. This is handled by a (proposed) mechanism which notes when a particular subcomponent is used, and ensures that only compatible components are used to refine other parts of that component. The transformational perspective allowed us to recognize that this was similar if not identical to the Draco tagging method. So two systems, Sinapse and Predator, use essentially the same idea present in a third. This hints that this idea may be somehow fundamental, or least a standard heuristic.

  A second consequence of the transformational perspective is an insight into how refinements are packaged. Predator packages refinements as entire, consistent components, ensuring that refined Predator specifications lead to working code. The price for this is that if one has n transforms, A, B, C,... N, which taken individually are not refinements, but which taken in pairs (often) form consistent refinements, they must be encoded as (up to) N squared monolithic refinements. There is a trade-off between flexibility (application of smaller transforms in a larger variety of ways) vs. reuse of useful compositions (application of a larger transform known to be useful). In order to factor monolithic refinements into smaller transforms, one must be able to express the constraints between the smaller transforms in order to have the option of the trade-off. It would convenient if sets of transforms chosen to form an incomplete refinement somehow constrained further choices to compatible transforms in a manner less ad hoc than the Draco tagging method.

  RESOLVE has such a mechanism. Components have import/export interface specifications and an implementation. Components depend on explicit properties rather than directly on other components. Refinement of a module part by use of a consistent component then creates a composite which has its own import/export specifications, which continue to reflect the component's property dependencies. This method appears to scale well: rather than worrying about the interactions of all the (exponentially large) possible subsets of N components, one can instead simply state necessary formal properties. The price for this is that one needs a theorem prover to verify that properties match instead of a simpler tag matching mechanism.

• Optimizations may be required for efficient code generation.
  • Sinapse offers many because of the performance demanded by supercomputing tasks. The Sinapse authors believe in the Draco model of a repeated refine-then-optimize cycle to remove redundancies introduced by juxtaposed refinements, and to perform optimizations at high levels of abstraction where they can be easily detected.

  • Predator uses relatively simple optimizations that appear mostly in the form of partial evaluation of conditional expressions. The most complex optimizations (and the most important) are those involving query optimizations, which involve the selection of which data structure to traverse and the factoring of predicates to avoid repeated subpredicate evaluation.

  • RESOLVE does currently not provide any automated method for optimizing a particular composition of refinements beyond inlining. The RESOLVE philosophy is that the best performance gains are to be had by choosing the most appropriate refinement at each step, rather than a posteriori optimization of a completed series of refinements.

  This implies that the choice of each refinement, a manual process in RESOLVE, is an important way of tailoring the performance of the resulting product [Murali92].

It is remarkable that these insights were obtained even though two of the systems examined were designed without a transformational model in mind.