Nu: Enabling Modularity in Multilingual, Multienvironment, Distributed Systems

The contribution of this work is a novel aspect-oriented programming model that we call Nu. The Nu programming model adds only one new concept, join point dispatch, to the object-oriented programming model. No new programming language constructs are added. The constructs in existing aspect languages are expressed in terms of join point dispatch resulting in a significant simplification of aspect languages. We make two claims about the potential benefits of our approach. First, that it will enable transparent modularization of even those crosscutting concerns that transcend the language and environment boundaries. Second, that it will simplify the AOP language model resulting in the ease-of-use, ease-of-learning, and reduced cost to build supporting tools

Building scalable software systems in the multicore era

Software systems must face two challenges today: growing complexity and increasing parallelism in the underlying computational models. The problem of increased complexity is often solved by dividing systems into modules in a way that permits analysis of these modules in isolation. The problem of lack of concurrency is often tackled by dividing system execution into tasks that permits execution of these tasks in isolation. The key challenge in software design is to manage the explicit and implicit dependence between modules that decreases modularity. The key challenge for concurrency is to manage the explicit and implicit dependence between tasks that decreases parallelism. Even though these challenges appear to be strikingly similar, current software design practices and languages do not take advantage of this similarity. The net effect is that the modularity and concurrency goals are often tackled mutually exclusively. Making progress towards one goal does not naturally contribute towards the other. My position is that for programmers that are not formally and rigorously trained in the concurrency discipline the safest and most productive way to get scalability in their software is by improving modularity of their software using programming language features and design practices that reconcile modularity and concurrency goals. I briefly discuss preliminary efforts of my group, but we have only touched the tip of the iceberg

Gang-of-Four Design Patterns: A Case Study of the Unified Model and the Eos Programming Language

In earlier work, we showed that the AspectJ notions of aspect and class can be unified in a new module construct that we called the classpect, and that this new model is simpler and able to accommodate a broader set of requirements for modular solutions to complex integration problems. We embodied our unified model in the Eos language design. The main contribution of this article is a case study, which considers the implementation of the Gang-of-Four (GOF) design patterns in Eos to analyze the effect of new programming language constructs on these implementations. We also compare these implementations with the AspectJ\u27s implementation. Our result shows that the Eos implementation showed improvement in 7 out of 23 design patterns, and are no worse in case of other 16 patterns. These improvements were mainly manifested in being able to realize the intent of the design patterns more clearly. The design structures realized in the Eos implementation provide supporting evidence for the potential benefits of the unified model

Design Patterns in Eos

In earlier work, we showed that the AspectJ notions of aspect and class can be unified in a new module construct that we called the classpect, and that this new model is simpler and able to accommodate a broader set of requirements for modular solutions to complex integration problems. We embodied our unified model in the Eos language design. The main contribution of this paper is a case study, which considers the implementation of the Gang-of-Four (GOF) design patterns in Eos to analyze the effect of new programming language constructs on these implementations. We also compare these implementations with the AspectJ\u27s implementation. Our result shows that the Eos implementation showed improvement in 7 out of 23 design patterns, and are no worse in case of other 16 patterns. These improvements were mainly manifested in being able to realize the intent of the design patterns more clearly. The design structures realized in the Eos implementation provide supporting evidence for the potential benefits of the unified model

A case for explicit join point models for aspect-oriented intermediate languages

Aspect-oriented languages mostly employ implicit language-defined join point models, where well-defined points in the program are called join points and declarative predicates are used to quantify them. The primary motivation for using an implicit join point model is obliviousness and ease of quantification. A design choice for aspect-oriented intermediate languages is to mirror the source language model. In this position paper, I argue that an explicit join point model is better suited at the intermediate language level and sketch a preliminary solutio

Capsule-oriented programming

Explicit concurrency should be abolished from all higher-level programming languages (i.e. everything except - perhaps- plain machine code.). Dijkstra [1] (paraphrased). A promising class of concurrency abstractions replaces explicit concurrency mechanisms with a single linguistic mechanism that combines state and control and uses asynchronous messages for communications, e.g. active objects or actors, but that doesn\u27t remove the hurdle of understanding non-local control transfer. What if the programming model enabled programmers to simply do what they do best, that is, to describe a system in terms of its modular structure and write sequential code to implement the operations of those modules and handles details of concurrency? In a recently sponsored NSF project we are developing such a model that we call capsule-oriented programming and its realization in the Panini project. This model favors modularity over explicit concurrency, encourages concurrency correctness by construction, and exploits modular structure of programs to expose implicit concurrency

Inferring Concise Specifications of APIs

Modern software relies on libraries and uses them via application programming interfaces (APIs). Correct API usage as well as many software engineering tasks are enabled when APIs have formal specifications. In this work, we analyze the implementation of each method in an API to infer a formal postcondition. Conventional wisdom is that, if one has preconditions, then one can use the strongest postcondition predicate transformer (SP) to infer postconditions. However, SP yields postconditions that are exponentially large, which makes them difficult to use, either by humans or by tools. Our key idea is an algorithm that converts such exponentially large specifications into a form that is more concise and thus more usable. This is done by leveraging the structure of the specifications that result from the use of SP. We applied our technique to infer postconditions for over 2,300 methods in seven popular Java libraries. Our technique was able to infer specifications for 75.7% of these methods, each of which was verified using an Extended Static Checker. We also found that 84.6% of resulting specifications were less than 1/4 page (20 lines) in length. Our technique was able to reduce the length of SMT proofs needed for verifying implementations by 76.7% and reduced prover execution time by 26.7%

Modular Compilation Strategies for Aspect-Oriented Constructs

In our previous work, we presented an aspect-oriented intermediate language, named Nu, to preserve design modularity in object code. Nu is based on two primitives: bind and remove. We showed that maintaining modularity in object code significantly improved the incremental compilation time of aspect-oriented programs. The key contribution of this work is a set of compilation strategies to Nu for a number of AspectJ constructs such as control flow (cflow and cflowbelow), instantiation (perthis, pertarget, percflow, percflowbelow) and dynamic checks (if, this, target, args), as well as composition operators (&& and ||). The motivation was to determine if these high-level language constructs need to be supported in the intermediate language. Our compilation strategies are modular and textually local. To compile a construct in a module, only the information about that module\u27s implementation and the specification of other modules referenced in that module are needed. The generated intermediate code for a construct in a source module is confined to a single module in the object code. We show that our compilation strategies improve incremental compilation time of aspect-oriented programs. We also analyze our intermediate language with respect to constructs that are not directly supported

A Cyberinfrastructure for BigData Transportation Engineering

Big Data-driven transportation engineering has the potential to improve utilization of road infrastructure, decrease traffic fatalities, improve fuel consumption, decrease construction worker injuries, among others. Despite these benefits, research on Big Data-driven transportation engineering is difficult today due to the computational expertise required to get started. This work proposes BoaT, a transportation-specific programming language, and it's Big Data infrastructure that is aimed at decreasing this barrier to entry. Our evaluation that uses over two dozen research questions from six categories show that research is easier to realize as a BoaT computer program, an order of magnitude faster when this program is run, and exhibits 12-14x decrease in storage requirements

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