Using twinning to adapt programs to alternative APIs

Nita, Marius; Notkin, David

doi:10.1145/1806799.1806832

Cited by 62 publications

(45 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Nita and Notkin [20] develop techniques to allow developers to adapt their applications to alternative APIs. They provide a way for developers to specify a mapping between a source and a target API, following which a source to source transformation automatically completes the transformations necessary to adapt the application to the target API.…”

Section: R Wmentioning

confidence: 99%

Inferring likely mappings between APIs

Gokhale

Ganapathy

Padmanaban

2013

2013 35th International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

Abstract-Software developers often need to port applications written for a source platform to a target platform. In doing so, a key task is to replace an application's use of methods from the source platform API with corresponding methods from the target platform API. However, this task is challenging because developers must manually identify mappings between methods in the source and target APIs, e.g., using API documentation.We develop a novel approach to the problem of inferring mappings between the APIs of a source and target platform. Our approach is tailored to the case where the source and target platform each have independently-developed applications that implement similar functionality. We observe that in building these applications, developers exercised knowledge of the corresponding APIs. We develop a technique to systematically harvest this knowledge and infer likely mappings between the APIs of the source and target platform. The output of our approach is a ranked list of target API methods or method sequences that likely map to each source API method or method sequence. We have implemented this approach in a prototype tool called Rosetta, and have applied it to infer likely mappings between the Java2 Platform Mobile Edition and Android graphics APIs. I. ISoftware developers often wish to make their applications available on a wide variety of computing platforms. The developer of a gaming app, for instance, may wish to make his app available on smart phones and tablets manufactured by various vendors, on desktops, and via the cloud. The key hurdle that he faces in doing so is to port his app to these software and hardware platforms.Why is porting software a difficult problem? Consider an example: suppose that we wish to port a Java2 Platform Mobile Edition (JavaME)-based game to an Android-powered device. Among other tasks, we must modify the game to use Android's API [10] (the target platform) instead of JavaME's API [21] (the source platform). Unfortunately, the process of identifying the API methods in the target platform that implement the same functionality corresponding to that of a source platform API method is cumbersome. We must manually examine the SDKs of the source and target APIs to determine the right method (or sequence of methods) to use. To add complexity, there could be multiple ways in which a source API method can be implemented using the target's API methods. For example, the fillRect() method in JavaME's graphics API, which fills a specified rectangle with color, can be implemented using either one of these two sequences of methods in Android's graphics API: setStyle();drawRect() or as moveTo();lineTo(); lineTo();lineTo();lineTo();drawPath() (we have omitted class names and the parameters to these method calls).One way to address this problem is to populate a database of mappings between the APIs of the source and target platforms. In this database, each source API method (or method sequence) is mapped to a target API method (or method sequence) that implements its f...

show abstract

Section: R Wmentioning

confidence: 99%

Inferring likely mappings between APIs

Gokhale

Ganapathy

Padmanaban

2013

2013 35th International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

show abstract

“…Clone refactoring is also possible [14]. Unavailable/Different APIs: Because hand-held devices could only support a limited JVM, a process similar to migrating to a different language [15] or alternative APIs offered by the available class libraries [16] could be a solution. Similarly, applications developed for Linux Debian must use different libraries when being ported to devices with Maemo 10 .…”

Section: Issues Not Addressed By Momsmentioning

confidence: 99%

MoMS: Multi-objective miniaturization of software

Ali

Antoniol

et al. 2011

2011 27th IEEE International Conference on Software Maintenance (ICSM)

View full text Add to dashboard Cite

Abstract-Smart phones, gaming consoles, and wireless routers are ubiquitous; the increasing diffusion of such devices with limited resources, together with society's unsatiated appetite for new applications, pushes companies to miniaturize their programs. Miniaturizing a program for a hand-held device is a time-consuming task often requiring complex decisions. Companies must accommodate conflicting constraints: customers' satisfaction with features may be in conflict with a device's limited storage, memory, or battery life. This paper proposes a process, MoMS, for the multi-objective miniaturization of software to help developers miniaturize programs while satisfying multiple conflicting constraints. It can be used to support the reverse engineering, next release problem, and porting of both software and product lines. The process directs the elicitation of customer pre-requirements, their mapping to program features, and the selection of the features to port. We present two case studies based on Pooka, an email client, and SIP Communicator, an instant messenger, to demonstrate that MoMS supports optimized miniaturization and helps reduce effort by 77%, on average, over a manual approach.

show abstract

“…These techniques may also be used in conjunction with our access control model to provide a crosscut of a codebase that suits the requestor's access level. Nita and Notkin propose a method for developers to specify code-level mappings between code alternatives instead of requiring redundant updating [18]. GitBAC protects target code through the specification of mutually exclusive fragments based on requestor credentials.…”

Section: Related Workmentioning

confidence: 99%

GitBAC: Flexible access control for non-modular concerns

Robinson

Niu

Shonle

2011

2011 26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011)

View full text Add to dashboard Cite

Abstract-Today's techniques for controlling access to software artifacts are limited to restricting access to whole files and directories. But when a company's access control policy does not match a project's existing physical modularization, these techniques require either an all-or-nothing approach or re-modularization of the files and directories. The increased maintenance overhead this brings to project administration can lead to unimplemented or insufficient developer access control and an increased risk of insider security incidents (e.g., theft of intellectual property). We have created a tool (GitBAC) to provide access control of software artifacts using a crosscutting concern instead of artifact modularization. Our method provides fine-grained access control of artifacts and accommodates flexible access control policies.

show abstract

Using twinning to adapt programs to alternative APIs

Cited by 62 publications

References 27 publications

Inferring likely mappings between APIs

Inferring likely mappings between APIs

MoMS: Multi-objective miniaturization of software

GitBAC: Flexible access control for non-modular concerns

Contact Info

Product

Resources

About