Evolutionenabled applicationprogramming interfaces Ralf Lmmel Data Programmability Team

Evolution-enabled application-programming interfaces Ralf Lämmel Data Programmability Team Microsoft, Redmond

API asbestos and its remedy C++ code for window creation in pre-. NET HWND hwnd. Main = Create. Window. Ex( 0, "Main. Win. Class", "Main Window", WS_OVERLAPPEDWINDOW | WS_HSCROLL | WS_VSCROLL, CW_USEDDEFAULT, CW_USEDEFAULT, (HWND)NULL, (HMENU)NULL, h. Instance, NULL); Show. Window(hwnd. Main, SW_SHOWDEFAULT); Update. Window(hwnd. Main); . NET version Form form = new Form(); form. Text = "Main Window"; form. Show(); Source of the term “software asbestos”: Klusener, Lämmel, Verhoef: “Architectural modifications to deployed software”, 2005, Science of Computer Programming

Table of contents • • • Call to arms More examples Categorization Techniques Show stoppers

Evolutionary API transformations Why is that a worthy research challenge? • • • Improve quality of APIs. Support effective obsoletion. Decrease platform complexity. Orthogonal to model-driven xyz. Improve productivity of developers.

API evolution samples • Code. Dom: program generation • Xml. Schema: XML schema processing • DOM vs. XML binding: API-fication

API asbestos: My first. NET program Use Code. Dom API for program generation Code. Compile. Unit compile. Unit = new Code. Compile. Unit(); //. . . build some cool code objects CSharp. Code. Provider provider = new CSharp. Code. Provider(); ICode. Generator gen = provider. Create. Generator(); Indented. Text. Writer tw = new … // create a text writer gen. Generate. Code. From. Compile. Unit(compile. Unit, tw, new Code. Generator. Options()); Sigh! Main. cs(…, …): warning CS 0618: 'System. Code. Dom. Compiler. Code. Dom. Provider. Create. Generator()‘ is obsolete.

Typical developer support

Elimination of the obsolete pattern Code. Compile. Unit compile. Unit = new Code. Compile. Unit(); //. . . build some cool code objects CSharp. Code. Provider provider = new CSharp. Code. Provider(); // ICode. Generator gen = provider. Create. Generator(); Indented. Text. Writer tw = new … // create a text writer provider. Generate. Code. From. Compile. Unit(compile. Unit, tw, new Code. Generator. Options()); That is, we get rid of the extra generator object, and directly use the Generate… method of the provider object.

How to …? Code. Compile. Unit compile. Unit = new Code. Compile. Unit(); //. . . build some cool code objects CSharp. Code. Provider provider = new CSharp. Code. Provider(); // ICode. Generator gen = provider. Create. Generator(); Indented. Text. Writer tw = new … // create a text writer provider. Generate. Code. From. Compile. Unit(compile. Unit, tw, new Code. Generator. Options()); • • Find offending “Create” calls. Get a handle on factory (provider). Find all uses of created generator. Setup provider itself as generator.

More API asbestos: My second. NET program Use Schema object model (SOM) for schema processing Xml. Schema schema = new Xml. Schema(); // … do something cool with the schema. Compile( new Validation. Event. Handler( Validation. Callback. One)); Sigh! Main. cs(…, …): warning CS 0618: 'System. Xml. Schema. Compile(System. Xml. Schema. Validation. Event. Handler)' is obsolete: 'Use System. Xml. Schema. Set for schema compilation and validation. '

An attempted modernization Xml. Schema schema = new Xml. Schema(); // … do something cool with the schema Xml. Schema. Set set = new Xml. Schema. Set(); set. Add(schema); set. Validation. Event. Handler += new Validation. Event. Handler( Validation. Callback. One); // schema. Compile( // new Validation. Event. Handler( // Validation. Callback. One)); set. Compile(); How to get this right? Is the above guess correct anyway?

Deprecated classes, methods, fields in Java world Source: Henkel & Diwan: “Catch. Up! Capturing and Replaying Refactorings to Support API Evolution” International Conference on Software Engineering, 2005

Burdens implied by API evolution • API producer • Upward compatibility • Extending maintenance • Investments • Tools • Processes • Documentation • API consumer • Re-engineering for eradication • Complexity due to multiple versions

An example for API-fication or translation • Given: a C# program that accesses XML business data through DOM. • Wanted: a converted C# program that uses XML binding instead. • Needed: (This is the naïve version. ) • The relevant XML schema(s) • An XML binding technology • A dedicated C# program transformation • Potentially: IDE component

Untyped (DOM-based) XML functionality

Typeful XML functionality

Kinds of API evolution • • Refactoring Service introduction Service extension Service elimination Service restriction API-fication API translation Example: Replacement of DOM by XML binding • Refactoring: Prepare the introduction of XML binding technology • Translation: Replace DOM patterns by schema-derived object model • Extension: Inject additional validation functionality into the application Compare to kinds of grammar adaptation: Lämmel: “Grammar Adaptation”, Formal Methods Europe, 2001

Techniques for API evolution • • • Weak and strong obsoletion Provision of facades Provision of parallel versions Migration guides, strategies, wizards Byte-code transformations Source-code transformations

What about refactoring?

Record refactorings on the API developer’s site Replay refactorings on the API user’s site Source: Henkel & Diwan: “Catch. Up! Capturing and Replaying Refactorings to Support API Evolution” International Conference on Software Engineering, 2005

So what? We cannot expect in general: • a refactoring suite to be sufficiently expressive, • refactoring to be practical for API developer, • a change scenario to be semantics-preserving.

The envisaged transformation framework Musts • • • Source-code transformation Source-code model with high fidelity Type analysis, simple DFA/CFA Test harness for system under transformation Simple feedback mechanisms Shoulds • • • More advanced user interaction More advanced DFA/CFA/effect analyses API protocols based on temporal logic Security models and other constraints Coverage of multiple (“all”) languages Story for 80/20 conversions

Potential show stoppers • Language issues • Incompleteness issues • Legal issues

Language issues • • • Reflection Threads Side effects Third party frameworks Multitude of languages

Incompleteness issues • API producer can’t convert • API consumer won’t convert

Legal issues • • • How to sell 80/20 solutions? Can we promise correctness? How to prove correctness to client? Development may rely on client code? Support may rely on client code?