1 / 26

Evolution-enabled application-programming interfaces

Evolution-enabled application-programming interfaces. Ralf L ämmel Data Programmability Team Microsoft, Redmond. Edited for online publication. API asbestos and its remedy. C++ code for window creation in pre-.NET HWND hwndMain = CreateWindowEx( 0, "MainWinClass", "Main Window",

nancey
Télécharger la présentation

Evolution-enabled application-programming interfaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Evolution-enabled application-programming interfaces Ralf Lämmel Data Programmability Team Microsoft, Redmond Edited for online publication

  2. API asbestos and its remedy 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(); Source of the term “software asbestos”: Klusener, Lämmel, Verhoef: “Architectural modifications to deployed software”, 2005, Science of Computer Programming

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

  4. Evolutionary API transformationsWhy 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.

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

  6. API asbestos:My first .NET program Sigh! Main.cs(…,…): warning CS0618: 'System.CodeDom.Compiler.CodeDomProvider.CreateGenerator()‘ is obsolete. Use CodeDom API for program generation CodeCompileUnit compileUnit = new CodeCompileUnit(); // ... build some cool code objects CSharpCodeProvider provider = new CSharpCodeProvider(); ICodeGenerator gen = provider.CreateGenerator(); IndentedTextWriter tw = new … // create a text writer gen.GenerateCodeFromCompileUnit(compileUnit, tw, new CodeGeneratorOptions());

  7. Typical developer support

  8. Elimination of the obsolete pattern CodeCompileUnit compileUnit = new CodeCompileUnit(); // ... build some cool code objects CSharpCodeProvider provider = new CSharpCodeProvider(); // ICodeGenerator gen = provider.CreateGenerator(); IndentedTextWriter tw = new … // create a text writer provider.GenerateCodeFromCompileUnit(compileUnit, tw, new CodeGeneratorOptions()); That is, we get rid of the extra generator object, and directly use the Generate… method of the provider object.

  9. How to …? • Find offending “Create” calls. • Get a handle on factory (provider). • Find all uses of created generator. • Setup provider itself as generator. CodeCompileUnit compileUnit = new CodeCompileUnit(); // ... build some cool code objects CSharpCodeProvider provider = new CSharpCodeProvider(); // ICodeGenerator gen = provider.CreateGenerator(); IndentedTextWriter tw = new … // create a text writer provider.GenerateCodeFromCompileUnit(compileUnit, tw, new CodeGeneratorOptions());

  10. More API asbestos:My second .NET program Sigh! Main.cs(…,…): warning CS0618: 'System.Xml.Schema.XmlSchema.Compile(System.Xml. Schema.ValidationEventHandler)' is obsolete: 'Use System.Xml.Schema.XmlSchemaSet for schema compilation and validation.' Use Schema object model (SOM) for schema processing XmlSchema schema = new XmlSchema(); // … do something cool with the schema schema.Compile( new ValidationEventHandler( ValidationCallbackOne));

  11. An attempted modernization XmlSchema schema = new XmlSchema(); // … do something cool with the schema XmlSchemaSet set = new XmlSchemaSet(); set.Add(schema); set.ValidationEventHandler += new ValidationEventHandler( ValidationCallbackOne); // schema.Compile( // new ValidationEventHandler( // ValidationCallbackOne)); set.Compile(); How to get this right? Is the above guess correct anyway?

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

  13. 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

  14. 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

  15. Untyped (DOM-based) XML functionality

  16. Typeful XML functionality

  17. 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

  18. 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

  19. What about refactoring?

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

  21. 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.

  22. 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

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

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

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

  26. 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?

More Related