Framework Design Using Function Generalization: A Binary Tree ...

cabbagepatchtapeInternet και Εφαρμογές Web

5 Φεβ 2013 (πριν από 4 χρόνια και 9 μήνες)

242 εμφανίσεις

Framework Design Using
Function Generalization

H. Conrad Cunningham
1

Pallavi Tadepalli
1
Yi Liu
2



1

Computer & Information Science


University of Mississippi


2

Electrical Engineering & Computer Science


South Dakota State University


2

Outline


Software framework


Motivation


Function generalization


Cosequential processing


Binary tree traversal


Conclusion


Future work


3

Software Framework


Generic application allowing creation of
members of family of related programs


Reusable design expressed as set of
abstract classes and way they collaborate


Common and variable aspects known as
frozen spots

and
hot spots


Framework

Framework
library

User
-
supplied code

(application specific)

Hot spots

Frozen spots


4

Motivation


Nontrivial to identify needed hot spot
abstractions


Difficult to specify hot spot behaviors



Need systematic generalization methodology


Explore

function generalization


incrementally generalize functional structure of
specification to produce general application


executable specification expressed as set of
functions in Haskell


5

Haskell


Purely functional language


forces explicit consideration of computational
effects (no implicit state)


Polymorphic, higher
-
order, first
-
class
functions & user
-
defined algebraic data types


enables generic programming


Concise, equational notation


allows convenient mathematical manipulation

6

Function Generalization


Create executable specification for a
concrete application as Haskell program


Define scope of family


Identify frozen spots and hot spots


Analyze and design each hot spot system


generalize Haskell program for hot spot


transform simple function to generalized function
(e.g., with higher
-
order parameters)


Transform generalized Haskell program to
Java framework

7

Examples

1.
Cosequential processing


2.
Binary tree traversal

8

Cosequential Processing



Coordinates processing of two input sequences
ordered by same total ordering


Create third sequence in incremental steps by
merging and matching input elements


Includes set operations and sequential file update
applications

A1…An

B1…Bn

Cosequential

Processing

C1…Cn

Input
sequences

Output
sequence

9

Binary Tree Traversal




procedure preorder(t)

{ if t null, then return;


perform visit action for root of tree t;


preorder(left subtree of t);


preorder(right subtree of t);

}

21

18

3

20

50

30

1

Preorder
21 18 3 1 20 50 30

10

Cosequential Processing


H. C. Cunningham and P. Tadepalli. “Using
Function Generalization to Design a Cosequential
Processing Framework,” In
Proceedings of the
39th Hawaii International Conference on System
Sciences (HICSS)
, 10 pages, IEEE, January
2006.

11

Process A1
and B1

Cosequential Processing



Coordinates processing of two input sequences
ordered by same total ordering


Create third sequence in incremental steps by
merging and matching input elements


Includes set operations and sequential file update
applications

A1…An

B1…Bn

Cosequential

Processing

C1…Cn

Input
sequences

Output
sequence

Write result
C1 to output

Process Ai
and Bj

Write C2
to output

12

Executable Specification

(Merging two ascending integer
sequences)

merge0 :: [Int]
-
>[Int]
-
>[Int]

merge0 [] ys = ys

merge0 xs [] = xs

merge0 xs@(x:xs’) ys@(y:ys’)


| x < y = x : merge0 xs’ ys


| x == y = x : merge0 xs’ ys’


| x > y = y : merge0 xs ys’


13

Framework Scope



Process two ordered sequences of
values to produce third ordered
sequence


Use ordering to restrict to a few current
values from sequences


Include classic examples:


sequential file update programs


set and bag operations

14

Frozen Spots

1.
Input sequences have same total ordering

2.
Input sequences are immutable

3.
Output sequence has same ordering as input
sequences

4.
Incremental processing


current element from each sequence examined


at least one input sequence advanced by one
element

5.
Appropriate action taken after examining current
elements from each sequence



Represented by merge function in Haskell

15

Hot Spots

1.
Variability in total ordering

2.
Variability in record format

3.
Variability of input and output sequences

4.
Variability of transformations

5.
Variability of source/destination




Represented as additional functions, types,
and class definitions to
merge

function

16

Hot Spot #1

(Variability in total ordering)


Generalizes element type of sequences and
associated comparison operators


Restricts polymorphic type of elements to class
Ord

(
having usual relational operations)


Results in generalized comparisons


merge1 ::
Ord a

=> [
a
]
-
> [
a
]
-
> [
a
]

merge1 [] ys = ys

merge1 xs [] = xs

merge1 xs@(x:xs’) ys@(y:ys’)


| x < y = x:merge1 xs’ ys


| x == y = x:merge1 xs’ ys’


| x > y = y:merge1 xs ys’

17

Hot Spot #1

(Initial prototype as special case)

If
merge1

type variable
a

restricted

to
Int,
then


merge1 xs ys == merge0 xs ys

18

Hot Spot #2

(Variability in record format)


Allows elements of sequences to be records with
keys


Adds
key

extraction function as higher order
parameter


Results in generalized record format


merge2 :: Ord b =>
(a
-
> b)
-
> [a]
-
> [a]


-
> [a]

merge2
key

[] ys = ys

merge2
key

xs [] = xs

merge2
key

xs@(x:xs’) ys@(y:ys’)


|
key x

<
key y

= x:merge2 key xs’ ys


|
key x

==
key y

= x:merge2 key xs’ ys’


|
key x

>
key y

= y:merge2 key xs ys’

19

Hot Spot #2

(Keyless version is special case)


If
id

is the identity function, then



merge2 id xs ys


== merge1 xs ys



20

Hot Spot #3

(Variability of input and output


sequences)


Allows different element format in each sequence


Requires separate
key

extraction functions for each


Introduces transformation functions


Results in independent sequence formats


merge3
kx ky tx ty

xs ys = mg xs ys


where


mg [] ys =
map ty ys


mg xs [] =
map tx xs


mg xs@(x:xs’) ys@(y:ys’)


|
kx x

<
ky y

=
tx x

: mg xs’ ys


|
kx x

==
ky y

=

tx x

: mg xs’ ys’


|

kx x

>

ky y

=
ty y

: mg xs ys’

21

Hot Spot #3

(Multikey version is special case of


single key version)


If
xs

and
ys

have the same type, then



merge3 key key id id xs ys


== merge2 key xs ys

22

Hot Spot #4

(Variability of transformations)


Enables use of more general
transformations on input


Introduces explicit
state
to record ongoing
computation


Adds accumulating parameter to maintain
local state throughout processing


Transforms
state

to output at end of input
sequence processing

23

Variable Sequence
Transformations

merge4b kx ky
tl te tg nex ney ttx tty


res s

xs ys = mg
s

xs ys


where


mg
s

[] ys =
res (foldl tty s ys)


mg
s

xs [] =
res (foldl ttx s xs)


mg
s

xs@(x:xs’) ys@(y:ys’)


| kx x < ky y = mg
(tl s x y)

xs’ ys


| kx x == ky y = mg
(te s x y)



(nex s xs) (ney s ys)


| kx x > ky y = mg
(tg s x y)

xs ys


24

Hot Spot #4

(Progress requirement)

For each call of
mg


if (kx x == ky y) then


(length (nex s xs) < length xs) ||


(length (ney s ys) < length ys)


else True


25

Hot Spot #4

(Backward recursive version special


case of forward recursive version)

merge4b kx ky


(
\
ss x y
-
> ss ++ [tx x])

--

tl


(
\
ss x y
-
> ss ++ [tx x])

--

te


(
\
ss x y
-
> ss ++ [ty y])

--

tl


(
\
ss xs
-
> tail xs)


--

nex


(
\
ss ys
-
> tail ys)


--

ney


(
\
ss x
-
> ss ++ [x])


--

ttx


(
\
ss y
-
> ss ++ [y])


--

tty



ss xs ys


== ss ++ merge3 kx ky tx ty xs ys

26

Hot Spot #5

(Variability of source/destination)


Allows diverse sources for inputs and
destination for output


No changes to
merge4b

except its use


sequences already represented as pervasive
polymorphic list data type


supply different input sequence arguments


use result by different function

27

Transformation to Java
Framework



Drive using shape of Haskell program


Use design patterns (Template, Strategy,
etc.)


Construct cosequential framework


recursive legs become main while loop


nonrecursive legs become post
-
loop code


interfaces and classes represent various hot
spot generalizations


java.lang.Comparable

for
Ord



Keyed

for key extraction functions

28

Cosequential Processing
Framework in Java

public final void merge() // template method

{
advXs(); advYs();

// uses Interators and Keyed


while(xsNotEmpty && ysNotEmpty)


{ int cmpxy = xKey.
compareTo(yKey);

// Ord as Comparable


if (cmpxy < 0)


{
transLt();

advXs(); } // tl


else if (cmpxy == 0)


{
transEq(); advEqXs(); advEqYs();

} // te, nex, ney


else


{
transGt();

advYs(); } // tg


}


while (xsNotEmpty) {
transYsEmpty();

advXs(); } // ttx


while (ysNotEmpty) {
transXsEmpty();

advYs(); } // tty


finish();

// res

}

29

Applications of Cosequential
Framework



Implemented master
-
transaction file update
program (bank account)


30

Binary Tree Traversal


H. C. Cunningham, Y. Liu, and P. Tadepalli.
“Framework Design Using Function
Generalization: A Binary Tree Traversal Case
Study,” In
Proceedings of the ACM SouthEast
Conference
, pp. 312
-
318, March 2006.

31

Binary Tree Traversal




procedure preorder(t)

{ if t null, then return;


perform visit action for root of tree t;


preorder(left subtree of t);


preorder(right subtree of t);

}

21

18

3

20

50

30

1

Preorder
21 18 3 1 20 50 30

32

Executable Specification

data BinTree a


= Nil | Node(BinTree a) a BinTree a)


preorder :: BinTree a
-
> [a]

preorder Nil = []

preorder (Node l v r)


= v : preorder l ++ preorder r


33

Framework Scope


Standard kinds of depth
-
first traversals


Flexible visit actions that are functions of
accumulated state along traversal


Other traversals orders (e.g. level by level)


Binary search trees, but not multiway trees
or graphs


34

Frozen Spots

1.
Structure of tree (
BinTree
) not redefined
by clients

2.
Traversal accesses every node once
(unless stopped early)

3.
Traversal performs one or more visit
actions on access to node of tree



Represented by a traversal function in
Haskell

35

Hot Spots

1.
Variability in the visit operation

s action

2.
Variability in ordering of visit action with
respect to subtree visits

3.
Variability in tree navigation technique
(not just left
-
to
-
right, depth first)



Represented as additional functions,
types, and class definitions to traversal
function

36

Hot Spot #1

(Generalizing the visit action)


Represent visit action by update
-
state function
(
us
) passed into traversal function


Accumulate state along traversal path


gaPre ::
(a
-
> b
-
> b)
-
> (b
-
> b)
-
> b



-
> BinTree a
-
> b

gaPre
us un is

t = po t is

where po Nil s = un s


po (Node l v r) s


= po r (po l (us v s))

37

Hot Spot #1

(Initial prototype as special case)


The following identity holds:



gaPre (
\
x y
-
> y ++ [x]) id [] t


== preorder t


38

Hot Spot #2

(Generalizing the visit order)


Allow visit actions at three points (Euler tour traversal)


first arrival (left)


between subtree traversals (bottom)


before final departure (right)


gvTraverse ::
(a
-
> b
-
> b)
-
>


(a
-
> b
-
> b)
-
> (a
-
> b
-
> b)

-
>


(b
-
> b)
-
> b
-
> BinTree a
-
> b

gvTraverse
ul ub ur

un is t = tr t is

where


tr Nil s = un s


tr (Node l v r) s


= ur v (tr r (ub v (tr l (ul v s))))

39

Hot Spot #2

(Single visit action as special case)


The following identity holds:



gvTraverse us id id un is t



== gaPre us un is t

40

Hot Spot #3

(Generalizing the tree navigation)


Pass in tree navigation function (
nav
)


Navigation function generates a list of update
functions


Folding (composition) of list from initial state
generates traversal


traverse
nav
ua ub ud un is t


= compose
(nav ua ub ud un t)

is


where compose fs s


= foldl (flip (.)) id fs s

41

Hot Spot #3

(Euler tour traversal as special case)

euler ua ub ud un t = doEuler t


where doEuler Nil = [un]


doEuler (Node l v r)]


= [(ua v)] ++ doEuler l


++ [(ub v)] +
+ doEuler r


++ [(ud v)]


The following identity holds:


traverse euler ua ub ud un is t


=
= gvTraverse ua ub ud un is t

42

Transformation to Java
Framework



Drive using shape of Haskell program


Use design patterns (Composite, Strategy,
Template, Visitor, etc.)


Construct binary tree traversal framework


use Composite pattern to represent tree


use Strategy pattern to encapsulate higher
order parameters of functions (i.e. state update
functions)


use Visitor pattern to separate tree navigation
from the application of state updates

43

Transformation to Java
Framework


public class Node extends BinTree

{ public Node(Object v, BinTree l, BinTree r)


{ value = v; left = l; right = r; }


… // accept a Visitor object


public void accept(BinTreeVisitor v)


{ v.visit(this); }





private Object value; // instance data


private BinTree left, right;

}

public interface BinTreeVisitor

{ abstract void visit(Node t);


abstract void visit(Nil t);

}

44

Transformation to Java
Framework


public class EulerTourVisitor implements BinTreeVisitor

{ public EulerTourVisitor(EulerStrategy es, Object ts)


{ this.es = es; this.ts = ts; }


public void setVisitStrategy(EulerStrategy es)


{ this.es = es; }


public void visit(Node t) // Visitor hook implementations


{ ts = es.visitLeft(ts,t); // upon first arrival


t.getLeft().accept(this);


ts = es.visitBottom(ts,t); // upon return from left


t.getRight().accept(this);


ts = es.visitRight(ts,t); // upon completion of node


}


public void visit(Nil t) { ts = es.visitNil(ts,t); }


public Object getResult() { return ts; }


private EulerStrategy es; // encapsulate state change ops


private Object ts; // traversal state

}

45

Conclusion


Framework construction followed
function
generalization


Each transformation produced an executable
specification


Appropriate hooks (hot spot abstractions)
defined


Constructed cosequential processing framework
with better understanding of hot spot behaviors


Constructed general binary tree traversal
framework with better understanding of hot spot
behaviors

46

Future Work


Develop better guidelines for generalizing
Haskell programs


Investigate usage of Haskell features like
modules, classes, and monads


Develop better guidelines for creating Java
frameworks from Haskell programs


Conduct case studies of larger programs


Investigate usage of Ruby instead of
Haskell and Java



47

Acknowledgments


Cuihua Zhang (Northeast Lakeview College)


Acxiom Corporation


University of Mississippi


South Dakota State University

48

Discussion



Any questions or comments?