Transformation Systems as an Explanatory Model for Generic Architectures

One of the major difficulties in comparing such systems is the diversity of terminology, mechanisms, and representations used. In an effort to find commonality, it was proposed that the group use a transformational model of program generation to provide standard vocabulary, concepts, and mechanisms, and attempt to map relations between generic architecture systems via the standard. Part of the reason for this proposal is that one of the systems ( Sinapse) is transformational, and so a straightforward mapping already existed.

A transformational model provides a number of concepts and mechanisms:

Specification language:

used to specify desired properties of the desired instance system. Such a language may consist of atomic symbols representing concepts to implement (e.g., ``database''), or expressions of constraints over desired results (e.g., <In,Out>:In=Out*Out) or some domain specific notation with implicit intent (a partial differential equation with the implicit requirement to solve it).

Synthesis mechanisms:

convert specifications into program abstractions with constraints. This requires the system to choose some set of mechanisms, which when composed, implement the specification. As an example, the system having both an integer enumeration and summing components might notice that the sum of integers 1..n is n*(n+1)/2, and use that fact to generate an integer square root algorithm by enumerating successively larger values of n, summing, and comparing. Synthesis in effect generates a refinement.

Refinement (transformations):

map high-level abstrac- tions to abstractions at a lower level. An example refinement is the conversion of the abstract notion of matrix inverse into more concrete code using multiply nested loops for a Gauss-Jordan procedure.

Optimizations (transformations):

replace configurations of abstractions by ``simpler'' configurations of abstractions at the same abstraction level. As an example, the SQL query:
SELECT cost<50 AND month=March FROM invoices
can be to optimized to SELECT cost<50 FROM (SELECT month=March FROM invoices)
assuming the statistical fact that there are usually fewer records from March than records with low cost value.

Control:

guides application of transforms (any of synthesis, refinement or optimization) to produce the implemented system. Usually a control mechanism chooses among several legal transforms, each introducing certain levels of performance, to optimize for a performance property, such as execution speed or storage requirements.

To produce a desired program, a transformation system accepts a specification, and then, under the guidance of the control mechanism, repeatedly chooses transforms from a library to incrementally convert the original specification into a final specification, representing the desired program. (We remark that any of synthesis, refinement, and/or optimization can be implemented using rewrite rules or arbitrary procedures).

A correspondence to generic architecture systems is obtained when one realizes that any principled composition of instance components must itself have well-understood properties, and therefore both the components and the composition mechanism must have well-defined properties. Oversimplifying, the key property required of an implementation I for a specification S, is that important properties M (for ``meaning'') of the specification are preserved: M(S) <= M(I), i.e., the implementation must have at least the properties required by the specification; this is precisely the notion of refinement used in transformation systems. Any generic architecture system must somehow combine components c1, c2,... to form an I for its input specification S.

The question is then, how can the example systems be described using the conceptual framework of transformation systems?