The ThingML approach, which was inspired by UML, addresses the challenges of distribution and heterogeneity in the Internet of Things. This model-driven, generative approach has been continuously evolved and applied to cases in different domains, including a commercial e-health solution.The challenge of writing, deploying, and evolving software for the Internet of Things (IoT) is often underestimated. 1 From a software engineering viewpoint, IoT applications have two main characteristics. The first is distribution over a large range of processing nodes. The second is high heterogeneity of the processing nodes and the protocols used between them. A rich collection of software engineering literature exists for each characteristic. However, not much research has addressed the combination of the two, which presents three specific challenges.First, in large IoT applications, distribution occurs across many heterogeneous nodes, which play different complementary roles to process data close to the sources and respond in a decentralized way. Most research in distributed systems, telecommunications, or even sensor networks has focused on scaling to very high numbers of nodes but has dealt with only a few types and roles among those nodes (for example, clientserver, peer tracker, sensor gateway server, and so on). 2 This homogeneity keeps the software complexity manageable because it allows developing and deploying similar code on large sets of nodes. But this isn't the case with IoT software, which must scale in not only the number of nodes but also the number of types of nodes and platforms, from microcontrollers up to the cloud.Second, for IoT systems to deliver their full potential, developers must leverage the diverse resources and decentralized computing power that heterogeneous nodes provide. Many tools and techniques hide this heterogeneity to enable developers to write applications that execute the same way on different platforms (OSs, web browsers, mobile devices, and so on). 3 In IoT applications, part of the heterogeneity isn't accidental and must remain explicit and exploitable by developers. This way, developers can, for example, take advantage of IoT nodes' deep-sleep modes, which typically differ among platforms, to save power.Third, in the IoT vision, applications are no longer isolated, proprietary silos of devices and software. 4 Rather, they must combine things readily available in the environment: some generic, some applicationspecific, and some legacy things. So, IoT applications are meant to run on shared hardware, and developers should pay special attention to avoiding unwanted interactions between applications.Consequently, industrializing IoT applications proves challenging at all development phases and requires teams of developers with a broad range of competences from electronics and microcontrollers to cloud and data mining. The ThingML (Internet-of-Things Modeling Language) approach aims to facilitate collaboration between service developers and platform experts so that together they can prod...

Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application’s code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that are packaged with the application’s compiled code but that are actually not necessary to build and run the application. They artificially grow the size of the built binary and increase maintenance effort. We propose DepClean, a tool to determine the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is as follows: 2.7% of the dependencies directly declared are bloated, 15.4% of the inherited dependencies are bloated, and 57% of the transitive dependencies of the studied artifacts are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts to 1/4 of its current count. Our qualitative assessment with 30 notable open-source projects indicates that developers pay attention to their dependencies when they are notified of the problem. They are willing to remove bloated dependencies: 21/26 answered pull requests were accepted and merged by developers, removing 140 dependencies in total: 75 direct and 65 transitive.

Neutral program variants are alternative implementations of a program, yet equivalent with respect to the test suite. Techniques such as approximate computing or genetic improvement share the intuition that potential for enhancements lies in these acceptable behavioral differences (e.g., enhanced performance or reliability). Yet, the automatic synthesis of neutral program variants, through program transformations remains a key challenge.This work aims at characterizing plastic code regions in Java programs, i.e., the code regions that are modifiable while maintaining functional correctness, according to a test suite. Our empirical study relies on automatic variations of 6 real-world Java programs. First, we transform these programs with three stateof-the-art program transformations: add, replace and delete statements. WeWe would like to thank Amine Benelallam and Paul Bettega for their feedback on this work.

The Maven Central Repository provides an extraordinary source of data to understand complex architecture and evolution phenomena among Java applications. As of September 6, 2018, this repository includes 2.8M artifacts (compiled piece of code implemented in a JVM-based language), each of which is characterized with metadata such as exact version, date of upload and list of dependencies towards other artifacts.Today, one who wants to analyze the complete ecosystem of Maven artifacts and their dependencies faces two key challenges: (i) this is a huge data set; and (ii) dependency relationships among artifacts are not modeled explicitly and cannot be queried. In this paper, we present the Maven Dependency Graph. This open source data set provides two contributions: a snapshot of the whole Maven Central taken on September 6, 2018, stored in a graph database in which we explicitly model all dependencies; an open source infrastructure to query this huge dataset.

Maven artifacts are immutable: an artifact that is uploaded on Maven Central cannot be removed nor modified. The only way for developers to upgrade their library is to release a new version. Consequently, Maven Central accumulates all the versions of all the libraries that are published there, and applications that declare a dependency towards a library can pick any version. In this work, we hypothesize that the immutability of Maven artifacts and the ability to choose any version naturally support the emergence of software diversity within Maven Central. We analyze 1,487,956 artifacts that represent all the versions of 73,653 libraries. We observe that more than 30% of libraries have multiple versions that are actively used by latest artifacts. In the case of popular libraries, more than 50% of their versions are used. We also observe that more than 17% of libraries have several versions that are significantly more used than the other versions. Our results indicate that the immutability of artifacts in Maven Central does support a sustained level of diversity among versions of libraries in the repository.