SUBJECT

1

Generators

Jun ChenMarch 2003

University of Colorado at Boulder

2

Agenda

Part I: Generator Technology

Part II: GenVoca

Part III: GenVoca vs. AOP

3

Part I: Generator Technology

What are Generators?Technologies for Building GeneratorsVertical, Horizontal, Oblique TransformationsCompositional vs. Transformational GeneratorsKinds of Transformations• Compiler Transformations• Source-to-Source Transformations

Transformation Systems

4

System Specification

System Implementation

Generator

What are Generators?

Generator: A program that takes a higher-level specification of a piece of software and produces its implementation.

• Check Specification

• Complete Specification

• Perform Optimizations

• Generate Implementation

5

Three Issues

Raising the intentionality of system descriptions• Focus on “what is needed”• Avoid implementation details

6

Three Issues

Raising the intentionality of system descriptionsComputing an efficient implementation• Performance Requirements (e.g. response time) • Complex computation inside generators

7

Three Issues

Raising the intentionality of system descriptionsComputing an efficient implementationAvoiding the library scaling problem• Exponential growth • Factoring libraries into components corresponding to

features + Composing using function calls • Avoid “exponential growth”• Poor performance

• Generators: factoring + eliminating calling overhead

8

Three Ways to Build Generators

Developing generators as stand-alone programs from scratch• Effort-intensive

Using the built-in metaprogramming capabilities of a programming lang. (e.g. c++)

•Advantage: easier to write generators, generators could be part of the library•Disadvantage: limited by the host lang., debugging

9

Three Ways to Build Generators

Using a generator infrastructure• The infrastructure provides basic facilities

• A common format for the internal source representation• Operations for encoding transformations• Input/output facilities• Debugging facilities

• An example: Intentional Programming

10

Vertical, Horizontal, Oblique Transformations

Horizontal Transformation

Oblique Transformation

Vertical Transformation

(Forward Refinement)

11

Compositional Generator: vertical transformation

Transformational Generators: vertical transformation + horizontal transformation

Compositional vs. Transformational Generators

12

Kinds of Transformations


System source in a general-purpose lang.

Compile

System Requirements

Manually Implement

Interactive, automated support


Could generate code in C++ or Java if needed

Compile

System source using domain-specific lang.

abstractions

Compile

High-level system specification

System Requirements

Manually Implement


Could generate code in C++ or Java if needed

Compile

System source using domain-specific lang.

abstractions

Compile

System Requirements

Manually Implement

Automating System Implementation

Compiler Transformations

Source-to-Source Transformations

14


Refinements(vertical) – adds implementation details• Decomposition

• An abstract data type(ADT) -> A number of other ADTs

• Choice of representation• Matrix -> Array? Vector? Hash Table?

• Choice of algorithm• Performance

15


Optimizations(horizontal) – improve performance• Structural changes of the code -> code becomes

hard to understand• Inlining – replace the symbol by its definition• Loop fusion – combine two loops into one if two loops

have a similar structure and can be done in parallel

• Beyond conventional compilers• Domain-specific optimizations (domain knowledge)• Global optimizations (cross multiple locations)

16

Source-to-Source Transformations

Restructuring transformations• Editing transformations

• Mechanize some simple editing operations • Ex. converting a code section into a procedure

• Refactoring transformations• Recognize code• Ex. abstraction and generalization

17


Definition • Environments for building transformational

generators• Transformational generators

18

Elements of transformation systems

A common format for the internal program representation• Abstract syntax tree, data and control flow graph

Code analysis facilities• Check the input program and guide transformation

A transformation engine• Apply transformations

Input and output facilities for the internal representation

19

An Example

Parser Transformation Engine

Unparser

Program text e.g., (y+1/y+1)+z AST

Transformed AST 1+z

z

/

x x1

Rewrite Rule

+

y 1 y 1

+

/+ +

1 z

20

Summary: Generator Technology

What are Generators?Technologies for Building GeneratorsVertical, Horizontal, Oblique TransformationsCompositional vs. Transformational GeneratorsKinds of Transformations• Compiler Transformations• Source-to-Source Transformations


21

Part II: GenVoca

GenVoca ApproachGenVoca ModelImplementing GenVoca in C++Composition Validation

22

GenVoca Approach

Build software system generators based on composing object-oriented layers of abstraction.• Stacked layers• Layer above refines the layer below it. Ex.

add new classes

OO framework v.s. GenVoca model

23

Transforming a framework into a GenVoca model (step 1)

Identify layers of abstractions in a framework

C31 C32 C33

C21 C22

C11 C13

Most Refined

24


Turn the hierarchy of layers upside down

C31 C32 C33

C21 C22

C11 C13

Most Refined

25


Treat “the layer below” as a parameter of “the layer” above

C31 C32 C33

C21 C22

C11 C13

26


Provide families of alternative, parameterized layers

27

GenVoca Model

Components and Realms• Component (or layer): an implementation of

abstract data type or feature• Realm: all components that implement the

same abstract data type or featureExample:

S = { a, b, c }T = { d[S], e[S], f[S] }W = { n[W], m[W], p, q[T,S] }

28

Parameters & Transformations• A component has a realm parameter for every

realm that it imports.Example:


Vertical v.s. Horizontal Parameters• Vertical parameters: layer parameters• Horizontal parameters: other parameters

GenVoca Model

29

GenVoca Model

Symmetric Components• Exports the same interface as it imports

Example:S = { a, b, c }T = { d[S], e[S], f[S] }W = { n[W], m[W], p, q[T,S] }

n[W], m[W]

30

GenVoca Model

GrammarExample:


S := a | b | cT := d[S] | e[S] | f[S]W:= n[W] | m[W] | p | q[T,S]

31

GenVoca Model

Type Expressions• describing layer composition, used to model

software systemExample:

S := a | b | cT := d[S] | e[S] | f[S]W:= n[W] | m[W] | p | q[T,S]

System_1 = d [b]System_2 = q [d[a], c]

32

GenVoca Model

Families of Systems• The set of all component compositions

Scalability• Few components, large families of systems

Design Rules and Domain ModelsS = { a, b, c }T = { d[S], e[S], f[S] }d[a], d[b], d[c], e[a], e[b], e[c], f[a], f[b], f[c]

• Type expression, syntax correct, semantics wrong• Domain-specific constrains -> Design rules• Domain model: Realms of components + Design rules

33

An Example – Booch Data Structure

Data Structure Families• Bag: unordered collection of objects• Queue: ordered sequence of objects with FIFO semantics

Data Structure Features for Every Family• Unbounded: No upper bound on total number of objects• Concurrent: A multithread environment, read/write serialized• Managed: Free objects are stored on a list for subsequent

reuse.

Data Structure Features only for Queue• Priority: Objects are sorted based on some priority function

34

An Example – Booch Data Structure

Bag[Concurrent[Size_of[Unbounded[Managed[heap]]]]]Bag

Concurrent

Size_of

Unbounded

Managed

heap Used as a parameter of

Formal parameter

Multiple Parameters

35

Implementing GenVoca Layers in C++

Implement GenVoca layers as class templates containing member classes

Example: LayerA

Template <class LowerLayer>

Class LayerA

{ public:

class ClassA

{ public:

void operationA() //refine operationA()

{ …//LayerA-specific work

lower.operationA();

…//LayerA-specific work

};

void operationB() { lower.operationB(); }; //forward operationB

private:

typedef typename LowerLayer::ClassA LowerLayerClassA;

LowerLayerClassA lower;

};

class ClassB {…};

}

Forwarding Implementation

37

Forwarding Static WrapperTemplate <class Component>

Class Wrapper

{ public:


{ …//wrapper-specific work

component.operationA();

…//wrapper-specific work

};

void operationB() { component.operationB(); }; //forward operationB

private:

Component component;

}

Problem:

propagation of operations

Solution: Inheritance

38

Inheritance-based Static WrapperTemplate <class Component>

Class Wrapper : public Component

{ public:


{ …//wrapper-specific work

Component :: operationA();

…//wrapper-specific work

};

}

Template <class LowerLayer>

Class LayerA

{ private:

typedef typename LowerLayer::ClassA LowerLayerClassA;

typedef typename LowerLayer::ClassB LowerLayerClassB;

public:

class ClassA : Public LowerLayerA

{ public:


{ …//LayerA-specific work

LowerLayerClassA :: operationA();

…//LayerA-specific work

};

};

class ClassB : Public LowerLayerClassB

{…};

}

Inheritance-based Implementation

40

Upward Type Propagation

Scope operator, ::typedef Problem: the layer might have to explicitly pass types they are not interested for themselves.Solution: configuration repository• an “envelop” containing all the layers, types and

constants

41

An Example

R1: A

R2: B,C

R3: D,E

Accessing R3 Possible

Accessing R2 and R3 Possible R1: A

R2: B,C

Config

export:

Global1, Global2

ConfigA::HorizA

ConfigB::HorizB

42

Downward Type Propagation

Idea: put the whole layer hierarchy into the configuration repository.

R1: A

R2: B

Config

export:

R1, R2

Access R1 possible

43

Composition Validation

Problem: syntactically correct composition might be wrong in semantics.Example:

DS_Size: guarded[DS_Size] | concurrent[DS_Size]multiple[DS_Size] | size_of[DS] | …

DS : bounded | unbounded[Memory] | …

guarded[guarded[multiple[concurrent[guarded[concurrent[size_of[bounded]]]]]]]

Solution: Configuration Rules

44

A model – Conditions & Restrictions

Upward and downward propagation of attributes that represent constraints on layers or properties of layersConditions: constraints propagated downwardsRestrictions: constraints propagated upwards

Layer A

Postrestrictions

Prerestrictions

Preconditions

Postconditions

45

Summary : GenVoca

GenVoca ApproachGenVoca ModelImplementing GenVoca in C++Composition Validation

46

Part III: GenVoca vs. AOPRichard Cardone

AOP: a meta-programming model that promotes code reuse by localizing the implementation of design features that cut across multiple functional unit.

GenVoca: a model of hierarchical software construction that enables customized applications to be assembled from interchangeable and reusable components.

47

Difference & Similarity

Difference• Starting point• Focus• Style

Similarity• Basic concepts• Effort required for implementation

48

Fundamental Concepts

AOP• Components, Aspects, Joint Points

GenVoca• Components, Realms, Parameters

49

Implementation

AOP• Aspect language• Weaver (preprocessor)

GenVoca• Type expression• Generator (preprocessor)

50

Focus

AOP• For any existing code base• Support code reuse by applying new features in a

controlled and localized way

Genvoca• Require the definition of standardized realm

interfaces, domain analysis needed• Provide techniques to decompose applications into

reusable and composable components

51

Conclusion

Generators• Automate system implementation• Various levels: compiler, source-to-source• Depending on the needs• Transformation systems

GenVoca• A systematic approach• Issues:

• composition validation (distance)• how to get effective component composition• component changes

52

Sources

“Generative Programming” textbookDon Batory, http://www.cs.utexas.edu/users/dsb/• “Composition Validation and Subjectivity in GenVoca

Generators”, 1997

“On the Relationship of Aspect-Oriented Programming and GenVoca”, Richard Cardone

Education

SUBJECT