A Framework for Designing of Optimization Software Tools by Commercial API Implementation

The customized software development aims to release a software product tailored to the specific user needs. The goal of such software is to best fit the business requirements in an efficient system. This is especially true when business should perform optimization of the used resources. The existence of application programming interfaces in many commercial mathematical programming systems makes it possible to develop custom tailored tools using proven over the years effective methods and algorithms for optimization. In the current paper, a framework for designing of customized software based on the implementation of LINDO API is described. A developed prototype is used for numerical testing of real life optimization problem. The testing results show the applicability of the proposed framework for designing of effective customized optimization tools

Repairing Deep Neural Networks: Fix Patterns and Challenges

Significant interest in applying Deep Neural Network (DNN) has fueled the need to support engineering of software that uses DNNs. Repairing software that uses DNNs is one such unmistakable SE need where automated tools could be beneficial; however, we do not fully understand challenges to repairing and patterns that are utilized when manually repairing DNNs. What challenges should automated repair tools address? What are the repair patterns whose automation could help developers? Which repair patterns should be assigned a higher priority for building automated bug repair tools? This work presents a comprehensive study of bug fix patterns to address these questions. We have studied 415 repairs from Stack overflow and 555 repairs from Github for five popular deep learning libraries Caffe, Keras, Tensorflow, Theano, and Torch to understand challenges in repairs and bug repair patterns. Our key findings reveal that DNN bug fix patterns are distinctive compared to traditional bug fix patterns; the most common bug fix patterns are fixing data dimension and neural network connectivity; DNN bug fixes have the potential to introduce adversarial vulnerabilities; DNN bug fixes frequently introduce new bugs; and DNN bug localization, reuse of trained model, and coping with frequent releases are major challenges faced by developers when fixing bugs. We also contribute a benchmark of 667 DNN (bug, repair) instances

Why and How Java Developers Break APIs

Modern software development depends on APIs to reuse code and increase productivity. As most software systems, these libraries and frameworks also evolve, which may break existing clients. However, the main reasons to introduce breaking changes in APIs are unclear. Therefore, in this paper, we report the results of an almost 4-month long field study with the developers of 400 popular Java libraries and frameworks. We configured an infrastructure to observe all changes in these libraries and to detect breaking changes shortly after their introduction in the code. After identifying breaking changes, we asked the developers to explain the reasons behind their decision to change the APIs. During the study, we identified 59 breaking changes, confirmed by the developers of 19 projects. By analyzing the developers' answers, we report that breaking changes are mostly motivated by the need to implement new features, by the desire to make the APIs simpler and with fewer elements, and to improve maintainability. We conclude by providing suggestions to language designers, tool builders, software engineering researchers and API developers.Comment: Accepted at International Conference on Software Analysis, Evolution and Reengineering, SANER 2018; 11 page

On the Security Blind Spots of Software Composition Analysis

Modern software heavily relies on the use of components. Those components are usually published in central repositories, and managed by build systems via dependencies. Due to issues around vulnerabilities, licenses and the propagation of bugs, the study of those dependencies is of utmost importance, and numerous software composition analysis tools have emerged to address those issues. A particular challenge are hidden dependencies that are the result of cloning or shading where code from a component is "inlined", and, in the case of shading, moved to different namespaces. We present an approach to detect cloned and shaded artifacts in the Maven repository. Our approach is lightweight in that it does not require the creation and maintenance of an index, and uses a custom AST-based clone detection. Our analysis focuses on the detection of vulnerabilities in artifacts which use cloning or shading. Starting with eight vulnerabilities with assigned CVEs (four of those classified as critical) and proof-of-vulnerability projects demonstrating the presence of a vulnerability in an artifact, we query the Maven repository and retrieve over 16k potential clones of the vulnerable artifacts. After running our analysis on this set, we detect 554 artifacts with the respective vulnerabilities (49 if versions are ignored). We synthesize a testable proof-of-vulnerability project for each of those. We demonstrate that existing SCA tools often miss these exposures.Comment: 16 pages, 1 figur

Accessing Inaccessible Android APIs: An Empirical Study

As Android becomes a de-facto choice of development platform for mobile apps, developers extensively leverage its accompanying Software Development Kit to quickly build their apps. This SDK comes with a set of APIs which developers may find limited in comparison to what system apps can do or what framework developers are preparing to harness capabilities of new generation devices. Thus, developers may attempt to explore in advance the normally “inaccessible” APIs for building unique API-based functionality in their app. The Android programming model is unique in its kind. Inaccessible APIs, which however are used by developers, constitute yet another specificity of Android development, and is worth investigating to understand what they are, how they evolve over time, and who uses them. To that end, in this work, we empirically investigate 17 important releases of the Android framework source code base, and we find that inaccessible APIs are commonly implemented in the Android framework, which are further neither forward nor backward compatible. Moreover, a small set of inaccessible APIs can eventually become publicly accessible, while most of them are removed during the evolution, resulting in risks for such apps that have leveraged inaccessible APIs. Finally, we show that inaccessible APIs are indeed accessed by third-party apps, and the official Google Play store has tolerated the proliferation of apps leveraging inaccessible API methods