Approaching the API migration challenge - Uni …laemmel/apimigration/...Henkel, Diwan’s: CatchUp!...

Further acknowledgements for the mentioned API-

usage analysis: Ruwen Hahn & Jürgen Starek (Uni

Koblenz)

Approaching the API migration challenge

Ralf Lämmel (Uni Koblenz)Joint work with Tijs van der Storm (CWI, Amsterdam)

API usage as a form of software asbestos

C++ code for window creation in pre-.NET

HWND hwndMain = CreateWindowEx( 0,

"MainWinClass", "Main Window",

WS_OVERLAPPEDWINDOW | WS_HSCROLL | WS_VSCROLL,

CW_USEDDEFAULT, CW_USEDEFAULT,

CW_USEDDEFAULT, CW_USEDEFAULT,

(HWND)NULL,(HMENU)NULL, hInstance, NULL);

ShowWindow(hwndMain, SW_SHOWDEFAULT);

UpdateWindow(hwndMain);

.NET version

Form form = new Form();form.Text = "Main Window";form.Show();

The API migration problem

Given a couple of “reasonably similar” APIs A and B, provide a transformational approach to the semi-automatic replacement of the use of A by the use of B in any given software project (say, P).

An illustrative domainfor API migration

Some XML APIs

http://www.w3.org/DOM/

www.jdom.org/

www.dom4j.org/

http://xom.nu/

JAXB (not exactly an API)

API migration for XML APIs

!"#$%&'()"$*+,-./0!1$

1&(2*23#4,-./0!1$

567*2"(8"$*+9):*6;/-3+*<$

API migration - Why?

Code modernization - transition to modern API

Code hardening w.r.t. constraints offered by API

API retirement - obsoletion of an aging API

Complexity reduction w.r.t. number of used APIs

API evolution - obsoletion of prior version

Part of platform migration, MDD enabling

...

Paths for API migration

Manual migration using guides

Refactoring-based

Wrapper-based re-implementation

Wrapping + Partial Evaluation

Special purpose transformation

Source code

Byte code

The refactoring-based path to API migration

Pick source- or byte-code transformation.

Derive B by refactoring A mechanically.

Record refactorings in a script S.

Deploy B together with S.

Project P will be converted by replaying S.

Henkel, Diwan’s: CatchUp!Architecture

Henkel, Diwan’s: CatchUp!View for recorded refactorings

Figure 2: Eclipse view for recorded refactorings.

1 public class ClassParser {2 public static final int DEFAULT_BUFSIZE = 8192;3 ...4 public ClassParser(InputStream file,5 String file_name,6 int bufSize) {7 this.file_name = file_name;8 ...9 this.file = new DataInputStream(

10 new BufferedInputStream(file, bufSize));11 }12 ...13 }

Figure 4: ClassParser after refactorings.

of the DEFAULT BUFSIZE constant (alias BUFSIZE in Fig. 3,l. 9) with a use of the parameter bufSize. Fig. 4 shows theresulting version of the ClassParser class.

The recorded refactorings view also allows users to removerefactoring events from the trace (Fig. 2). Sometimes, thelibrary developer knows for sure that a refactoring will nota!ect client code. Such refactoring events are not harmful,but they clutter the refactoring trace, which also serves asa changelog of the API (Section 3.3). The library developertherefore uses his judgment to remove unnecessary eventsfrom the trace. In our example, the “Rename Field” eventdiscussed in the previous paragraph can be removed fromthe refactoring trace: Since it was private in the previ-ous version of the library, and no reference from the clientapplication could be introduced by the refactorings beforethe rename event, the library developer is certain that clientcode cannot reference BUFSIZE at the point when the renameevent happens. Notice that this is true even though BUFSIZEis a public field when it gets renamed.

Now the library developer is ready to release a Version 5.1-1 of the BCEL library (Fig. 1). He saves the refactoring traceas a text file by clicking the “Save” button of the recorded

Figure 5: Eclipse wizard for replaying refactorings.

refactoring view (Fig. 2), and uses Eclipse’s “Export JAR”functionality to generate a new JAR file. He ships both theJAR file and the refactoring trace to the client developer.

3.2 Replaying the refactoringsThe client developer currently uses Version 5.1 of the

BCEL library, but he would like to move to Version 5.1-1 (Figure 1). Within the Eclipse IDE, he invokes our pluginby selecting “Update Library” from the main menu. Thisbrings up our replaying wizard (Fig. 5). At the top of the di-alog, the replaying wizard lists the JAR files that the currentproject is using; the library developer selects which JAR file

278

Limitations of refactoring

Assume A and B are “independent” APIs:

A’s code must be refactored into C such that:

C agrees with interface of B.

C is observably equivalent to B.

This entails a proof of program equivalence.

Assume B is successor version of A:

The available refactorings may be insufficient.

B may actually be a re-implementation of A.

Scenario: construct XML tree from collection of persons

<contacts>

<person>

<name>Barack Obama</name>

<age>47</age>

</person>

<person>

<name>John McCain</name>

<age>72</age>

</person>

</contacts>The “builder

scenario”

The builder scenario using the jdom API

! public static Document makeDocument(List<Person> contacts) {

! ! Document document = new Document();

! ! Element root = new Element("contacts");

! ! document.addContent(root);

! ! for (Person p: contacts) {

! ! ! Element person = new Element("person");

! ! ! Element name = new Element("name");

! ! ! name.setText(p.getName());

! ! ! person.addContent(name);

! ! ! Element age = new Element("age");

! ! ! age.setText(new Integer(p.getAge()).toString());

! ! ! person.addContent(age);

! ! ! root.addContent(person);

! ! }

! ! return document;

! } // done

The builder scenario using (W3C’s) dom API

! public Document makeDocument(List<Person> contacts) {

! ! Document document = getDomImplementation().createDocument(

null, "contacts", null);

! ! Element root = document.getDocumentElement();

! ! for (Person p: contacts) {

! ! ! Element person = document.createElement("person");

! ! ! Element name = document.createElement("name");

! ! ! Node nameText = document.createTextNode(p.getName());

! ! ! name.appendChild(nameText);

! ! ! person.appendChild(name);

! ! ! Element age = document.createElement("age");

! ! ! Node ageText = document.createTextNode(

new Integer(p.getAge()).toString());

! ! ! age.appendChild(ageText);

! ! ! person.appendChild(age);

! ! ! root.appendChild(person);

! ! }

! ! return document;

! } // done

API differences

Node construction

dom: uses document object as factory

jdom: leverages regular constructors

Text content

dom: uses designated objects for text nodes

jdom: represents text as strings

Construction of the document also differs ...

Refactoring under attackjdom to dom

Before: Element person = new Element("person");

After: Element person = document.createElement("person");

Refactoring attempt

Introduce instance method createElement.

Implement method as factory method for Element.

Replace constructor call by call to createElement.

A suitable Document instance is needed.

Hide constructor in interface. Not a common refactoring!

Refactoring under attackdom to jdom

Before: Element person = document.createElement("person");

After: Element person = new Element("person");

Refactoring attempt

Replace call to createElement by constructor call.

Elements no longer owned by a document.

Eliminate createElement method.

This is not even a refactoring!

Intermezzo: Inform migration research by API usage analysis

What is the scale of usage frequency for APIs?

How are APIs used in a typical project?

What combinations of APIs occur together?

How frequent are principled usage scenarios?

How frequent are problematic uses?

...

Most used Core Java packages(based on our SourceForge study)

OverallAPIUsage/FRA_of_MostUsedCoreJavaPackages

Partitioning of all method calls(based on our SourceForge study)

OverallAPIUsage/FRA_of_MostUsedPackages

API-usage frequency for Core APIs(based on our SourceForge study)

OverallAPIUsage/FRA_of_CorePackages_XYPlot.eps

1

10

100

1000

10000

100000

1e+06

0 20 40 60 80 100 120 140 160

Fe

atu

re r

efe

ren

ce

s

Packages

API size min/max(based on our SourceForge study)

APISize/MinSizeMaxSize_of_MostUsedAPIs

0

1000

2000

3000

4000

5000

6000

java.lang

java.util

javax.swing

java.awt

java.io

java.sql

javax.xml.stream

org.w3c.dom

javax.swing.text

java.util.logging

java.awt.event

java.net

java.lang.reflect

java.awt.geom

java.text

mindelta

Paths for API migration

Manual migration using guides

Refactoring-based

Wrapper-based re-implementation

Wrapping + Partial Evaluation

Source-code transformation

Byte-code transformation

The wrapper-based path to API migration

Re-implement interface of A in terms of B.

Use Adapter Design Pattern.

The wrapper-based path: Wrap jdom as dom

public class Node {

! protected org.jdom.Content content;

! ...

}

public class Element extends Node {

! ...

! public void appendChild(Node node) {

! ! org.jdom.Element elt = (org.jdom.Element)content;

! ! elt.addContent(node.content);

! }

! ...

}

The wrapper-based path: Wrap dom as jdom

public class Content {

! protected String text = null;

! protected org.w3c.dom.Node domNode = null;

! ...

! /*package*/ void build(Element parent) {

! ! domNode = parent.domDocument().createTextNode(text);

! ! parent.domElement().appendChild(domNode);

! }

}

public class Element extends Content {

! private String name = null;

! private List<Content> kids;

! ...

! public void addContent(Content elt) {

! ! kids.add(elt);

! ! if (domNode != null) {

! ! ! elt.build(this);

! ! ! domNode.appendChild(elt.domNode);

! ! }

! }

}

Parenting leads to DOM tree

construction

Virtual builder to turn

deferred object into DOM object

Discussion of wrapping

Pros

P only needs a trivial if any transformation.

Existing test harness directly applies.

Cons/Limitations

A’s interface continues to be used in P.

Hence, wrapping is not universally applicable.

Fully equivalent re-implementation is hard.

Possible inefficiency because of semantic gap.

Wrapping with partial evaluation

The path

Inline adapters and methods.

Perform constant propagation and friends.

Challenges

Overall: readable and efficient code!

API-specific laws and analyses needed.

API usage scenarios need to be understood.

API protocols

Some related work

Systä et al.’s API scenarios

Antkiewicz, Czarneck et al.’s FSMLs

XML API scenarios

Dynamic and static traces

Context-free grammars as API protocols

Attribute grammars as API protocols

Outlook


!"#$%& '( )*+,-&."/&0 ),1,& 213-"+&

!"#$%&' ()* $&&+ ,-.&%/ *01.-&. 2&343 567869:7;<=3 >#" #1"

)!!"#)?(8 ,& 1*& !"#"$%&&' ()*+,%-* .'#-/*0"1*2 2@AB=

56;8 67<3 C+ &**&+?&8 @AB ')!* &)?( '&0(#. ?)%% 0# )+ )?D

0-#+ #E ) *0)0& )+. &)?( "&?&-F&. '&0(#. ?)%% 0# ) 0")+*-0-#+3

G(& "&*1%0-+4 *0)0& ')?(-+& -* */+0(&*-H&. $)*&. #+ *?&+)"D

-#* "&!"&*&+0-+4 0(& 1*)4& #E 0(& AIC3 G(1* -0 "&!"&*&+0* 0(&

$&()F-#" #E 0(& AIC3

G(& *-H& #E 0(& 4&+&")0&. *0)0& ')?(-+& .&!&+.* #+ 0(&

%&+40( )+. *-'-%)"-0/ #E 0(& -+!10 *?&+)"-#*3 J-0(#10 4&+&"D

)%-H)0-#+*8 &F&"/ '&0(#. ?)%% -* 0")+*%)0&. 0# -0* #,+ *0)0&

()F-+4 #+& #104#-+4 0")+*-0-#+ 2-3&3 "&01"+ #E 0(& ?)%%=3

K1"-+4 0(& 4&+&")%-H)0-#+ !"#?&**8 *0)0&* ?)%%-+4 0(& *)'&

'&0(#. )"& '&"4&. -E !#**-$%&3 L&?)1*& #E 0(& '&"4-+48 0(&

*/+0(&*-H&. *0)0& ')?(-+& ,-%% )??&!0 &M&?10-#+ !)0(* 0()0

)"& +#0 -+?%1.&. -+ 0(& #"-4-+)% -+!10*3 B#'&0-'&*8 -+ ?)*&

#E 34*25*#*2%&"1%-"3#8 *#'& #E 0(& +&, !)0(* ')/ +#0 $&

,)+0&.3

@AB ?)+ $& "1+ &-0(&" -+ )+ )10#')0-? #" -+ )+ -+0&")?D

0-F& '#.&3 J(&+ "1+ -+ )+ )10#')0-? '#.&8 @AB E#"'*

'-+-')% *0)0& ')?(-+&8 0(1* !#**-$%/ "&*1%0-+4 -+ #F&"4&+D

&")%-H)0-#+*3 J(&+ "1+ -+ -+0&")?0-F& '#.&8 @AB )*N* 0(&

1*&" -E ?&"0)-+ 4&+&")%-H)0-#+* )"& 0# $& )%%#,&. #" +#0 -+ 0(&

"&*1%0-+4 *0)0& ')?(-+&3 J& ?)+ *)F& 0(& O1&*0-#+* 2)+. ?#"D

?&** $/ '#.-E/-+4 0(& )+*,&"*3 J& 0"&)0 0(& )!!%-?)0-#+*

)+. AIC )* $%)?N $#M&*8 0(1* "&O1-"-+4 +# !"-#" N+#,%&.4&

#+ 0(& AIC -+F#?)0-#+ #".&"*3 G(1*8 ,& "1+ @AB -+ )10#D

')0-? '#.&3

0&"&. 0")?& -+ >-43 7 )+. )+#0(&" #+& -+.-?)0-+4 ) ?)%% #E

)3.6*&&"#5.,55*0-"3# -+*0&). #E )37335&*.*%28/8 -* !"&D

*&+0&. -+ >-43 P3

!"# $%&'( )*+,-.%*/+01%,2 3*%/ 40+0'$+561,'- 7+58 0% 4'9:',5' ;1+<*+/-

C+ *0&! Q #E 0(& !"#?&** ,& 4&+&")0& 0(& 1*)4& *?&+)"-#*

1*-+4 -+E#"')0-#+ #+ 0(& !)"0-?-!)+0* -+F#%F&. -+ 0(& *)'D

!%& -+0&")?0-#+* )+. -+E#"')0-#+ */+0(&*-H&. -+ 0(& *0)0& ')D

?(-+&3 G(& %)00&" -* +&&.&. &343 E#" -.&+0-E/-+4 0(& ?#''#+

$&()F-#")% !)00&"+* 2-+?%1.-+4 %##!*= )* ,&%% )* #!0-#+)% )+.

)%0&"+)0-F& $&()F-#"*3 G(&*& $&()F-#"* )"& 0")+*%)0&. -+0#

?#""&*!#+.-+4 R@S7 *0"1?01"&. -+0&")?0-#+ E")4'&+0* 2-3&3

93$:"#*);2%5$*#-0=3

>#" #1" '#.&% 0")+*E#"')0-#+ !1"!#*&* ,& 10-%-H& #+& #E

0(& ,-.&%/ ).#!0&. %)+41)4&*8 +)'&%/8 A0%)* G")+*E#"')D

0-#+ S)+41)4& 2AGS= 5T<3 G(& 0")+*E#"')0-#+ 4&+&")0&* )

*&O1&+?& #E &M?()+4&. '&**)4&* $&0,&&+ %-E&%-+&* $/ +)FD

0")+*E#"')0-#+ "1%&*3

')?(-+& )+. R@S7 *&O1&+?& .-)4")' ?#+*0"1?0*3 @#*0 #E

0(& 0")+*E#"')0-#+ "1%&* )"& %-*0&. -+ G)$%& 68 ,(&"& *0)0&

')?(-+& ?#+*0"1?0* )"& 4-F&+ #+ 0(& %&E0 ?#%1'+ )+. ?#""&D

*!#+.-+4 R@S7 '&0)'#.&% ?#+?&!0* )"& %-*0&. #+ 0(& "-4(0

?#%1'+3 >-"*0 #E )%%8 0(& 0")+*E#"')0-#+ 4&+&")0&* ) 93&&%:<

32%-"3#8 )+ =#-*2%8-"3#8 0,# 9&%00*0 2A!!%-?)0-#+ )+. AIC=8

0,# >236*2-"*0 "&E&""-+4 0# 0(& 4&+&")0&. 9&%00*08 )+. 0,#

?"@*&"#*0 "&!"&*&+0-+4 0(& ?"&)0&. >236*2-"*03 >#" &)?( )?D

0-#+ #E *0)0&8 ) *&+0!*00%5* )+. ) "&!%/!*00%5* )"& ?"&)0&.

E#" ) */+?("#+#1* ?)%%3 A *-'-%)" 0")+*E#"')0-#+ !"#?&** -*

)!!%-&. 0# 0"-44&"* #E 0")+*-0-#+*3

!"#"$ %#&'()$ *%+, !$-.$)&$ /(#01#2

B0)0& @)?(-+& U#%%)$#")0-#+8 C+0&")?0-#+8

S-E&%-+&8 U%)**8 I"#!&"0/

A?0-#+ #E B0)0& @&**)4&8 V!&")0-#+ #E U%)**

G"-44&" #E ) 0")+*-D

0-#+

@&**)4&8 V!&")0-#+ #E U%)**

@1%0-!%& #104#-+4

0")+*-0-#+* E"#' )

B0)0&

A%0&"+)0-F& U#'$-+&.>")4D

'&+0 2%&-=

B0)0& ,(-?( )"&

1++&?&**)"/ 0# $&

!)**&. 0("#14(

V!0-#+)% U#'$-+&.>")4D

'&+0 236-=

S##! *0"1?01"& S##! U#'$-+&.>")4'&+0

2&336=

4156& 7( 2188"+#. 9&,:&&+ ),1,& 213-"+&1+0 ;2<= )&>$&+3& ?"1#%1@ AB+.,%$3,.

G(& 4&+&")0&. '&**)4&* )"& 4"#1!&. $/ .-EE&"&+0 N-+.*

#E -+0&")?0-#+ E")4'&+0*3 >#" -+*0)+?&8 ?#+*-.&" ) *-01)0-#+

,(&"& 0(&"& )"& '1%0-!%& #104#-+4 0")+*-0-#+* E"#' ) *0)0&8

0()0 -* 0# *)/8 0(& 1!?#'-+4 *0)0&* )"& +)F-4)0&. )%#+4 .-ED

E&"&+0 !)0(*3 G(&+8 0(& 4&+&")0&. &F&+0* )"& 4"#1!&. $/

)%0&"+)0-F& E")4'&+0* 0# )%%#, #+& ?(#-?& E#" &)?( !)0(3

,-0( )?01)% +)'&* #E 0(& ?)%%&. ?%)**&*3

J(&+ 4&+&")0-+4 0(& 1*)4& *?&+)"-# E#" 0(& */+0(&*-H&.

*0)0& ')?(-+& 2>-43 P= )??#".-+4 0# 0")+*E#"')0-#+ "1%&*8

)?0-#+* 7335&*.*%28/.*24"8*A=$6& )+. 5*-7335&*.*%28/<


!"#$%& '( )%*+&,, -.&%."&/

!"# $%&'()%*+ ,)-.( /*01)2-'%1*

!"#$%&'(&$) %*# +#,#-.$% &$'/+0.%&/$ .$" "&1%&$)2&1*&$)

%*.% '+/0 %*# %(3&4.,,( ,.+)# .0/2$% /' 2$&$%#+#1%&$) &$'/+5

0.%&/$ &$4,2"#" &$ %*# %+.4#1 .+# 4*.,,#$)&$) %.1617 8&125

.,&9.%&/$ %#4*$&:2#1; %(3&4.,,( 21#" &$ %*# "($.0&4 .$.,(5

1&1 .33+/.4*#1 .$" %//,1 <=; >?; >@; >AB; 3+/-&"# /$,( ,&05

&%#" 1233/+% '/+ /-#+4/0&$) %*&1 3+/C,#07 D'%#$; #7)7 E*#$

).%*#+&$) %+.4# &$'/+0.%&/$ '/+ /2+ 32+3/1#1; 4.3%2+&$) /$,(

!$ .""&%&/$ %/ ,&0&% %*# .0/2$% /' %+.4# &$'/+0.%&/$; E#

*.-# %/ 1/0#*/E "&1%&$)2&1* %*# .33,&4.%&/$ .$" FG! 3.+%17

H/ "/ %*.%; E# 21# . IJK 0/"#, L4.,,#" M

%/ 13#4&'( &$%#+#1%&$) 4,.11#1 .$" /3#+.%&/$1; .$" %*# +/,#1

%*#( 3,.(7 N2+%*#+; %*# 4,.11#1 .+# "&-&"#" &$%/ %E/ 3.465

.)#1 L0.+6#" E&%* 1%#+#/%(3#1 OFG!P .$" OFGGPM7 Q24*

0/"#, 4.$ :2&%# #.1&,( C# 4+#.%#" 21&$) +#-#+1# #$)&$##+&$)

"/$# C( 21&$) %#R%2., ,&1%1 /+ $.0&$) 4/$-#$%&/$17 Q%&,,; %*#

0/"#, E&,, .,1/ )&-# 0/+# &$'/+0.%&/$ .C/2% %*# 1%+24%2+.,;

1%.%&4 1&"# /' %*# .$.,(1#" FG!7

"&%&/$; .,, 4.,,1 &$1&"# /$# 3.46.)# L#7)7 4.,,1 %/ 12C+/2%&$#1

&$1&"# %*# .33,&4.%&/$M .+# /0&%%#"7

M &1 )#$#+.%#" '/+ #.4* %+.4#7 !$ %*# 1#:2#$4# "&.)+.0;

.,, 0#%*/" 4.,,1 /442+ /$,( C#%E##$ %E/ 3.+%&4&3.$%1 L

.$" M7 H*# .4%2., 3.+%&4&3.$% &1 1%&,, 1.-#" %/ C#

,.%#+ 21#" E*#$ 21.)# 14#$.+&/1 .+# 4+#.%#"7 F$ #R.03,# /'

S13#4&.,,( )#$#+.%#" 4,.11#1 L#7)7 !"#$!; %&'()*! .$" +&,%-

%*&!M .+# 212.,,( 3,.4#" &$%/ .33,&4.%&/$T1 3.46.)# *&#+.+5

!"#$%& 0( 1 !"23&%&4 5&6$&7+& 8"9#%9:

4*(; C2% .+# ,/)&4.,,( 3.+% /' %*# FG!7 F,1/; &% 0&)*% C# "&'5

,.+)# 0/"#, E&,, (&#," %/ 2$$#4#11.+( /3#+.%&/$ 4.,,1; E*&,#

L1/0#%&0#1 #-#$ 0.$".%/+(M &$%#+.4%&/$ 3.%%#+$17

!"! 3()+%*+ ,)-.( /*01)2-'%1*

D'%#$; E*#$ %+.4&$) .$ .33,&4.%&/$; E# )#% 14#$.+&/1 3+#5

1#$%&$) /$,( . 3.+%&., -&#E3/&$% /' %*# FG! 21.)#7 N/+ #R.05

3,#; &$ . 4.1# /' &$%#+.4%&-# 3+/)+.01; 21#+T1 4*/&4#1 .''#4%

&$ FG! 21.)#; E# $##" %/ 0#+)# %*# 14#$.+&/1 %/ )#% 0/+#

.442+.%# .$" 4/03,#%# &$'/+0.%&/$ L1%#3 ?M7

:2#$4# "&.)+.01 %/ . 1%.%# 0.4*&$#7 H*&1 %+.$1'/+0.%&/$

Antkiewicz, Czarnecki et al.’s Framework-Specific Modeling Languages

Feature hierarchy ExplanationApplet concept (root feature)[1..1] name (String) mandatory feature with attribute![1..1] extendsApplet essential feature

[0..1] extendsJApplet optional feature[1..1] lifecycleMethods mandatory feature!<1-5> essential or feature group

[0..1] init[0..1] start[0..1] paint optional grouped features[0..1] stop[0..1] destroy

[0..*] parameter optional multiple feature[0..*] name (String) multiple feature with attribute

[0..1] providesParamInfo optional feature[1..1] infoForParams mandatory feature

Figure 2.4: Feature model for the concept applet

the cardinality <0-k> is equivalent to k optional subfeatures. The sample modelin Figure 2.4 contains an or-group with five features, that is, at least one featurefrom that group has to be present in the configuration.

Features may also have a type, which means that a single value of that type canbe associated with a given feature instance in a feature configuration. A featurewith a type is essentially an attribute whose value is set in configuration. Forexample, the sample model in Figure 2.4 contains two features having the typeString. Some attributes may also point to other features in the configuration; werefer to such attributes as reference attributes.

Constraints that cannot be encoded in the hierarchy can be specified separatelyas additional constraints or they can be included in the hierarchy as mandatoryfeatures. For example, a constraint may specify that an instance of an optionalfeature in one part of the hierarchy may require an instance of another optionalfeature in a di!erent part of the hierarchy. More complex constraints may in-volve Boolean expressions and constraints over sets of feature instances [33]. InFigure 2.4, the mandatory feature infoForParams corresponds to the constraint../parameter!../providesParamInfo, that is, whenever at least one instance ofthe feature parameter is present in a feature configuration, an instance of the fea-ture providesParamInfo should also be present. Such a constraint could also bespecified separately as "a:Applet . a/parameter!a/providesParamInfo, thatis, the constraint must hold for every instance of the concept Applet. Note thatboth constraints use path expressions for feature hierarchy navigation, which aresimilar to XPath or Unix file system paths.

The notation we use also supports feature inheritance, which is similar to classinheritance and allows a feature to inherit the subfeatures of another feature [20].

12


Feature hierarchy Feature correspondence explanationApplet <class> concept instance corresponds to a Java class[1..1] name (String) <fullyQualifiedName> value of the feature is a fully

qualified name of the context class![1..1] extendsApplet <assignableTo:’Applet’> feature is present if the

context class is a subtype of Applet[0..1] extendsJApplet <assignableTo:’JApplet’>

[1..1] lifecycleMethods a feature used for grouping, no mapping definition!<1-5>

[0..1] init <methods:’void init()’> each grouped feature corre-sponds to a non-inherited method of the context class

[0..1] start <methods:’void start()’>[0..1] paint <methods:’void paint(Graphics)’>[0..1] stop <methods:’void stop()’>[0..1] destroy <methods:’void destroy()’>

[0..*] parameter <callsReceived:’String getParameter(String)’ lo-cation:’void init()’> clones correspond to calls received

by objects of the context class[0..*] name (String) <valueOfArg:1> value of the feature is the value

of the first argument of the context method call[0..1] providesParamInfo <methods:’String[][] getParameterInfo()’>[1..1] infoForParams <constraint:../parameter requires:../provi-

desParamInfo> constraint

Figure 2.6: Mapping definitions for features from the applet feature model

values can be provided statically or retrieved from other features during FSMLexecution. The first option involves specifying the parameter values directly in themapping definitions. For example, the type name Applet is specified explicitly asa parameter value in <assignableTo: ’Applet’>. The second option involvesspecifying a feature as a parameter, in which case the code pattern correspondingto that feature during FSML execution will be used as the parameter value. Thefeature to be used for the retrieval of the parameter value is specified by an absoluteor relative path expression, such as, ../parameter in Figure 2.6.

In addition to specifying parameters explicitly, parameter values can also be de-termined implicitly using a context mechanism. The context mechanism retrievesthe value for a parameter from the instance of the closest parent feature with therequired mapping type. For example, the mapping type c fullyQualifiedNamerequires a class as the value of its parameter c (cf. Table 2.2). However, the map-ping definition for Applet’s subfeature name is <fullyQualifiedName>; that is,it does not explicitly specify the feature corresponding to a class. Therefore, thecontext mechanism selects Applet as the feature since it is the closest parent with amapping type that matches a class, which means that the class corresponding to aninstance of Applet is used as the parameter value to fullyQualifiedName. That

16

Mapping definition


Figure 2.2: Mapping definitions specify the feature-to-code-pattern correspondence

definition uses a particular mapping type. Mapping types are generic and reusableand they represent di!erent kinds of feature-to-code-pattern correspondences, suchas, a correspondence to Java classes, method calls, or XML elements. Mappingtypes define parameters that are set in mapping definitions to define a particularcorrespondence, such as, a parameter method signature used to specify a correspon-dence to method calls with the given signature. The di!erence between mappingtypes and definitions is similar to the di!erence between SQL language constructs(e.g., select <p> from <t>, where p and t are parameters) and particular SQLqueries (e.g., select * from ’transactions’).

We refer to the feature model together with mapping definitions as the meta-model of an FSML. The metamodel can be used in each of the four main use casesintroduced in Section 1: framework API understanding, completion code analysisand understanding, forward engineering, and completion code evolution. In Fig-ure 2.1, we present framework API understanding and forward engineering usecases directly. Reverse engineering and API constraint checking belong to thecompletion code analysis and understanding use case. Round-trip engineering andmigration belong to the completion code evolution use case. In framework API un-derstanding, the metamodel is inspected manually. In reverse, forward, round-tripengineering use cases the metamodel is interpreted by algorithms for reverse, for-ward, and round-trip engineering, respectively, implemented in the generic FSMLinfrastructure. Migration is performed using specialized forward engineering thatcreates new code patterns in a new application that uses a new version of theframeworks or even an entirely new framework.

Since the mapping types are only specifications, they are implemented by codequeries for reverse engineering and code transformations for forward and round-tripengineering (cf. Figure 2.2). Mapping definitions provide values of parameters de-fined by mapping types and required by code queries and transformations. The top

9


Figure 2.1: Overview of model-supported engineering of framework-based applica-tions using FSMLs

implemented in the application code as feature configurations. An FSML formal-izes API concepts and constraints as feature models. A framework-specific modelshould conform to an FSML, that is, feature configuration should satisfy all con-straints specified in a feature model. Finally, a framework-specific model containsfeature instances and the application code consists of code patterns that implementdi!erent functionalities of the application. Code patterns can be structural (e.g., afield) and behavioural (e.g., a method call in the control flow of an object, order ofmethod calls).

A framework-specific model represents an application because feature instancesfrom a feature configuration correspond to code patterns that implement themin the application code. In FSMLs, the correspondence relationship between thefeatures and code patterns is specified using mapping definitions as shown on Fig-ure 2.2. The figure is divided into four parts: application, model, FSML, andmapping interpreter, each representing a di!erent entity of the approach. In thefigure, a feature instance represents a code pattern and a code pattern implementsa feature instance. This correspondence is specified using mapping definitions thatprecisely specify what code patterns implement instances of a given feature using apattern expression. Mapping definitions may also specify values of some additionalparameters that may be required by code queries of transformations. Each mapping

8

XML programming scenarios

Visit XML tree

Query and extract from XML tree

Query and transform XML tree

Build XML treeRemember our running example

Trace-based reasoning

Trace = Execution of OO program

Items in the trace:

Object constructions

Method calls

Arguments and results are object identities.

Dynamic trace(Construct Obama with jdom)

oid1 ! new Document()oid2 ! new Element(“contacts”)oid1.addContent(oid2)oid3 ! new Element(“person”)oid4 ! new Element(“name”)oid4.setText(“Barack Obama”)oid3.addContent(oid4)oid5 ! new Element(“age”)oid5.setText(“47”)oid3.addContent(oid5)oid6 ! new Element(“person”)...

Static traces

Analyse usage ...

without running the program,

while approximating all possible runs.

Key ideas:

Symbolic object ids via points-to analysis.

Explicit representation of iteration.

Static trace (Builder scenario with jdom)

oid1 ! new Document()oid2 ! new Element(“contacts”)oid1.addContent(oid2)for all oid3:

oid3 ! new Element(“person”)oid4 ! new Element(“name”)oid4.setText(?)oid3.addContent(oid4)oid5 ! new Element(“age”)oid5.setText(?)oid3.addContent(oid5)

Context-free grammars as API protocols

Language of traces

Nonterminals = protocols

Terminals = method or constructor calls

The context-free API protocol for recursive construction

for the jdom API

import org.jdom.*;

buildTree = Document.new Element.new Document.addContent manyChildren

manyChildren = ( Element.new ( Element.setText | manyChildren ) Element.addContent )*

The context-free API protocol for recursive construction

for W3C’s dom API

import org.w3c.dom.*;

buildTree = DOMImplementation.createDocument Document.getDocumentElement manyChildren

manyChildren = ( Document.createElement ( ( Element.setText Document.createTextNode Element.appendChild ) | manyChildren ) Element.appendChild )*

The skeleton of the protocols

buildTree = manyChildren

manyChildren = ( ! | manyChildren )*

Beyond context-free protocols

Parameterization to model object-id constraints

Wildcards to model non-API actions

Interleaving to relax order constraints

Iterated matching to cover multiple scenarios

Computational models

Attribute grammars

Logic programs

Process algebras

Graph transformation

Conclusion 1/2

API migration - technical/conceptual challenges

Define an appropriate protocol notion.

Match protocols to verify protocol adherence.

Match protocols for API migration.

Fully leverage work on flow analysis.

Deal with semi-automatic status.

Preserve system testability.

...

Conclusion 2/2

API migration - high-level challenges

Show that general migration is feasible.

Make migration technically manageable.

Make migration economically viable.

Thanks!Questions?

Approaching the API migration challenge - Uni …laemmel/apimigration/...Henkel, Diwan’s: CatchUp!...

Documents

Transcript of Approaching the API migration challenge - Uni …laemmel/apimigration/...Henkel, Diwan’s: CatchUp!...