Scoping behavioral variations to dynamic extents is useful to support non-functional requirements that otherwise result in cross-cutting code. Unfortunately, such variations are difficult to achieve with traditional reflection or aspects. We show that with a modification of dynamic proxies, called delegation proxies, it becomes possible to reflectively implement variations that propagate to all objects accessed in the dynamic extent of a message send. We demonstrate our approach with examples of variations scoped to dynamic extents that help simplify code related to safety, reliability, and monitoring.

This paper proposes new composable user-defined operators, named protean operators. They can express various language extensions including user-defined literals such as regular expression literals as well as user-defined expressions. Their expressiveness is equivalent to Parsing Expression Grammar (PEG). The operators have two important features to be parsed in pragmatic time: overloading by return type and a precedence rule for operators. They can be parsed efficiently even if they express user-defined literals since ambiguities in the grammar are removed by these two features. The overloading by return type enables us to consider static types as non-terminal symbols in the grammar. The compiler can use static type information for parsing. It can resolve ambiguities of the rules with the same syntax but a different type. Protean operators with the same return type require programmers to declare the precedence among them. These precedence rules enable completely removing ambiguities from the grammar since all the rules applicable to the same place are ordered. Thus, the expressions including protean operators can be parsed in pragmatic time. We have implemented a language that is a subset of Java but supports protean operators. We present an experiment to show that the programs including user-defined literals cannot be parsed in pragmatic time in existing approaches but can be efficiently parsed in our approach.

Traditionally, object-oriented software adopts the Observer pattern to implement reactive behavior. Its drawbacks are well-documented and two families of alternative approaches have been proposed, extending object-oriented languages with concepts from functional reactive and dataflow programming, respectively event-driven programming. The former hardly escape the functional setting; the latter do not achieve the declarativeness of more functional approaches.

In this paper, we present REScala, a reactive language which integrates concepts from event-based and functional-reactive programming into the object-oriented world. REScala supports the development of reactive applications by fostering a functional declarative style which complements the advantages of object-oriented design.

This paper reports on our experience with providing Information Flow Control (IFC) as a library. Our aim was to support the use of an unmodified Platform as a Service (PaaS) cloud infrastructure by IFC-aware web applications. We discuss how Aspect Oriented Programming (AOP) overcomes the limitations of RubyTrack, our first approach. Although use of AOP has been mentioned as a possibility in past IFC literature we believe this paper to be the first illustration of how such an implementation can be attempted.

We discuss how we built FlowR (Information Flow Control for Ruby), a library extending Ruby to provide IFC primitives using AOP via the Aquarium open source library. Previous attempts at providing IFC as a language extension required either modification of an interpreter or significant code rewriting. FlowR provides a strong separation between functional implementation and security constraints which supports easier development and maintenance; we illustrate with practical examples. In addition, we provide new primitives to describe IFC constraints on objects, classes and methods that, to our knowledge, are not present in related work and take full advantage of an object oriented language (OO language).

The experience reported here makes us confident that the techniques we use for Ruby can be applied to provide IFC for any Object Oriented Program (OOP) whose implementation language has an AOP library.

The traditional modular structure defined by the package hierarchy suffers from the dominant decomposition problem and it is widely accepted that alternative forms of modularization are necessary to increase developer's productivity. In this paper, we propose an alternative form to understand and assess package modularity based on co-change clusters, which are highly inter-related classes considering co-change relations. We evaluate how co-change clusters relate to the package decomposition of three real-world systems. The results show that the projection of co-change clusters to packages follow different patterns in each system. Therefore, we claim that modular views based on co-change clusters can improve developers' understanding on how well-modularized are their systems, considering that modularity is the ability to confine changes and evolve components in parallel.

As software systems are maintained, their architecture often de-grades through the processes of architectural drift and erosion. These processes are often intertwined and the same modules in the code become the locus of both drift and erosion symptoms. Thus, architects should elaborate architecture rules for detecting occur-rences of both degradation symptoms. While the specification of such rules is time-consuming, they are similar across software projects adhering to similar architecture decompositions. Unfortu-nately, existing anti-degradation techniques are limited as they focus only on detecting either drift or erosion symptoms. They also do not support the reuse of recurring anti-degradation rules. In this context, the contribution of this paper is twofold. First, it presents TamDera, a domain-specific language for: (i) specifying rule-based strategies to detect both erosion and drift symptoms, and (ii) promoting the hierarchical and compositional reuse of design rules across multiple projects. The language was designed with usual concepts from programming languages in mind such as, inheritance and modularization. Second, we evaluated to what extent developers would benefit from the definition and reuse of hybrid rules. Our study involved 21 versions pertaining to 5 software projects, and more than 600 rules. On average 45% of classes that had drift symptoms in first versions presented inter-related erosion problems in latter versions or vice-versa. Also, up to 72% of all the TamDera rules in a project are from a pre-defined library of reusable rules. They were responsible for detecting on average of 73% of the inter-related degradation symptoms across the projects.

Modular design is a desirable characteristic of complex software systems that can significantly improve their comprehensibility, maintainability and thus quality. While many software systems are initially created in a modular way, over time modularity typically degrades as components are reused outside the context where they were created. In this paper, we propose an automated strategy to remodularize software based on move refactoring, i.e. moving classes between packages without changing any other aspect of the source code. Taking a complex systems perspective, our approach is based on complex networks theory applied to the dynamics of software modular structures and its relation to an n-state spin model known as the Potts Model.

In our approach, nodes are probabilistically moved between modules with a probability that nonlinearly depends on the number and module membership of their adjacent neighbors, which are defined by the underlying network of software dependencies. To validate our method, we apply it to a dataset of 39 Java open source projects in order to optimize their modularity. Comparing the source code generated by the developers with the optimized code resulting from our approach, we find that modularity (i.e. quantified in terms of a standard measure from the study of complex networks) improves on average by 166+-77 percent. In order to facilitate the application of our method in practical studies, we provide a freely available Eclipse plug-in.

There are a number of constructs to implement context-dependent behavior, such as conditional branches using if statements, method dispatching in object-oriented programming (such as the state design pattern), dynamic deployment of aspects in aspect-oriented programming, and layers in context-oriented programming (COP). Uses of those constructs significantly affect the modularity of the obtained implementation. While there are a number of cases where COP improves modularity, it is not clear when we should use COP in general.

This paper presents a preliminary study on our software development methodology, the context-oriented software engineering (COSE), which is a use-case-driven software development methodology that guides us to a specification of context-dependent requirements and design. We provide a way to map the requirements and design formed by COSE to the implementation in our COP language ServalCJ. We applied COSE to two applications in order to assess its feasibility. We also identify key linguistic constructs that make COSE effective by examining existing COP languages. These feasibility studies and examination raise a number of interesting open issues. We finally show our future research roadmap to address those issues.

In the discussion about the usefulness of static or dynamic type systems there is often the statement that static type systems improve the documentation of software. In the meantime there exists even some empirical evidence for this statement. One of the possible explanations for this positive influence is that the static type system of programming languages such as Java require developers to write down the type names, i.e. lexical representations which potentially help developers. Because of that there is a plausible hypothesis that the main benefit comes from the type names and not from the static type checks that are based on these names. In order to argue for or against static type systems it is desirable to check this plausible hypothesis in an experimental way. This paper describes an experiment with 20 participants that has been performed in order to check whether developers using an unknown API already benefit (in terms of development time) from the pure syntactical representation of type names without static type checking. The result of the study is that developers do benefit from the type names in an API's source code. But already a single wrong type name has a measurable significant negative impact on the development time in comparison to APIs without type names.

The recent popularization of dynamically typed languages, such as Ruby and JavaScript, has brought more attention to the discussion about the impact of typing strategies on development. Types allow the compiler to find type errors earlier and potentially improve the readability and maintainability of code. On the other hand, "untyped" code may be easier to change and require less work from programmers. This paper tries to identify the programmers' point of view about these tradeoffs. An analysis of the source code of 6638 projects written in Groovy, a programming language which features optional typing, shows in which scenarios programmers prefer to type or not to type their declarations. Our results show that types are popular in the definition of module interfaces, but are less used in scripts, test classes and frequently changed code. There is no correlation between the size and age of projects and how their constructs are typed. Finally, we also found evidence that the background of programmers influences how they use types.

Several cohesion metrics have been proposed to support development and maintenance activities. The most traditional ones are the structural cohesion metrics, which rely on structural information in the source code. For instance, many of these metrics quantify cohesion based how methods and attributes are related to each other within a given module. Recently, conceptual cohesion metrics have been proposed for computing cohesion based on the responsibilities a given module realizes. Besides different flavors of cohesion, there is a lack of empirical evidence about how developers actually perceive cohesion and what kind of cohesion measurement aligns with developers' perception. In this paper we fill this gap by empirically investigating developers opinion through a web-based survey, which involved 80 participants from 9 countries with different levels of programming experience. We found that: most of the developers are familiar with cohesion; and they perceive cohesion based on class responsibilities, thus associating more with conceptual cohesion measurement. These results support the claim that conceptual cohesion seems to be more intuitive and closer to the human-oriented view of software cohesion. Moreover, the results showed that conceptual cohesion measurement captures the developers' notion of cohesion better than traditional structural cohesion measurement.

Oliveira and colleagues recently developed a powerful model to reason about mixin-based composition of effectful components and their interference, exploiting a wide variety of techniques such as equational reasoning, parametricity, and algebraic laws about monadic effects. This work addresses the issue of reasoning about interference with effectful aspects in the presence of unrestricted quantification through pointcuts. While global reasoning isrequired, we show that it is possible to reason in a compositional manner, which is key for the scalability of the approach in the face of large and evolving systems. We establish a general equivalence theorem that is based on a few conditions that can be established, reused, and adapted separately as the system evolves. Interestingly, one of these conditions, local harmlessness, can be proven by a translation to the mixin setting, making it possible to directly exploit previously established results about certain kinds of harmless extensions.

Semantic specifications of programming languages typically have poor modularity. This hinders reuse of parts of the semantics of one language when specifying a different language -- even when the two languages have many constructs in common -- and evolution of a language may require major reformulation of its semantics. Such drawbacks have discouraged language developers from using formal semantics to document their designs.

In the PlanCompS project, we have developed a component-based approach to semantics. Here, we explain its modularity aspects, and present an illustrative case study. Our approach provides good modularity, facilitates reuse, and supports co-evolution of languages and their formal semantics. It could be particularly useful in connection with domain-specific languages and language-driven software development.

Aspect-oriented programming (AOP) is a popular technique for modularizing crosscutting concerns. In this context, researchers have found that the realization of design by contract (DbC) is crosscutting and fares better when modularized by AOP. However, previous efforts aimed at supporting crosscutting contract modularity might actually compromise the main DbC principles. For example, in AspectJ-style, reasoning about the correctness of a method call may require a whole-program analysis to determine what advice applies and what that advice does relative to DbC implementation and checking. Also, when contracts are separated from classes a programmer may not know about them and may break them inadvertently. In this paper we solve these problems with AspectJML, a new specification language that supports crosscutting contracts for Java code. We also show how AspectJML supports the main DbC principles of modular reasoning and contracts as documentation.

In a software product line (SPL), a collection of software products is defined by their commonalities in terms of features rather than explicitly specifying all products one-by-one. Several verification techniques were adapted to establish temporal properties of SPLs. Symbolic and family-based model checking have been proven to be successful for tackling the combinatorial blow-up arising when reasoning about several feature combinations. However, most formal verification approaches for SPLs presented in the literature focus on the static SPLs, where the features of a product are fixed and cannot be changed during runtime. This is in contrast to dynamic SPLs, allowing to adapt feature combinations of a product dynamically after deployment.

The main contribution of the paper is a compositional modeling framework for dynamic SPLs, which supports probabilistic and nondeterministic choices and allows for quantitative analysis. We specify the feature changes during runtime within an automata-based coordination component, enabling to reason over strategies how to trigger dynamic feature changes for optimizing various quantitative objectives, e.g., energy or monetary costs and reliability. For our framework there is a natural and conceptually simple translation into the input language of the prominent probabilistic model checker PRISM. This facilitates the application of PRISM's powerful symbolic engine to the operational behavior of dynamic SPLs and their family-based analysis against various quantitative queries. We demonstrate feasibility of our approach by a case study issuing an energy-aware bonding network device.

A recent line of work lifts particular verification and analysis methods to Software Product Lines (SPL). In an effort to generalize such case-by-case approaches, we develop a systematic methodology for lifting program analyses to SPLs using abstract interpretation. Abstract interpretation is a classical framework for deriving static analyses in a compositional, step-by-step manner. We show how to take an analysis expressed as an abstract interpretation and lift each of the abstract interpretation steps to a family of programs. This includes schemes for lifting domain types, and combinators for lifting analyses and Galois connections. We prove that for analyses developed using our method, the soundness of lifting follows by construction. Finally, we discuss approximating variability in an analysis and we derive variational data-flow equations for an example analysis, a constant propagation analysis for a simple imperative language.

Multiparty session types allow the definition of distributed processes with strong communication safety properties. A global type is a choreographic specification of the interactions between peers, which is then projected locally in each peer. Well-typed processes behave accordingly to the global protocol specification. Multiparty session types are however monolithic entities that are not amenable to modular extensions. Also, session types impose conservative requirements to prevent any race condition, which prohibit the uni- form application of extensions at different points in a protocol. In this paper, we describe a means to support modular extensions with aspectual session types, a static pointcut/advice mechanism at the session type level. To support the modular definition of crosscut- ting concerns, we augment the expressivity of session types to al- low harmless race conditions. We formally prove that well-formed aspectual session types entail communication safety. As a result, aspectual session types make multiparty session types more flexible, modular, and extensible.

Advanced concurrency abstractions overcome the drawbacks of low-level techniques such as locks and monitors, freeing programmers that implement concurrent applications from the burden of concentrating on low-level details. However, with current approaches the coordination logic involved in complex coordination schemas is fragmented into several pieces including join patterns, data emissions triggered in different places of the application, and the application logic that implicitly creates dependencies among communication channels, hence indirectly among join patterns. We present JEScala, a language that captures coordination schemas in a more expressive and modular way by leveraging a seamless integration of an advanced event system with join abstractions. We validate our approach with case studies and provide a first performance assessment.

Development and maintenance of model transformations make up a substantial share of the lifecycle costs of software products that rely on model-driven techniques. In particular large and heterogeneous models lead to poorly understandable transformation code due to missing language concepts to master complexity. At the present time, there exists no module concept for model transformation languages that allows programmers to control information hiding and strictly declare model and code dependencies at module interfaces. Yet only then can we break down transformation logic into smaller parts, so that each part owns a clear interface for separating concerns. In this paper, we propose a module concept suitable for model transformation engineering. We formalize our concept based on cQVTom, a compact subset of the transformation language QVT-Operational. To meet the special demands of transformations, module interfaces give control over both model and code accessibility. We also implemented the approach for validation. In a case study, we examined the effort required to carry out two typical maintenance tasks on a real-world transformation. We are able to attest a significant reduction of effort, thereby demonstrating the practical effects of a thorough interface concept on the maintainability of model transformations.

While JavaScript is one of the most widely used programming languages not only for web applications but also for large projects, it does not provide a language-level module system. JavaScript developers have used the module pattern to avoid name conflicts by themselves, but the prevalent uses of multiple libraries and even multiple versions of a single library in one application complicate maintenance of namespace. The next release of the JavaScript language specification will support a module system, but the module proposal in prose does not clearly describe its semantics. Several tools attempt to support the new features in the next release of JavaScript by translating them into the current JavaScript, but their module semantics do not faithfully implement the proposal.

In this paper, we identify some of the design issues in the JavaScript module system. We describe ambiguous or undefined semantics of the module system with concrete examples, show how the existing tools support them in a crude way, and discuss reasonable choices for the design issues. We specify the formal semantics of the module system, which provides unambiguous description of the design choices, and we provide its implementation as a source-to-source transformation from JavaScript with modules to the plain JavaScript that the current JavaScript engines can evaluate.

A key problem in metaprogramming and specifically in generative programming is to guarantee that generated code is well-formed with respect to the context-free and context-sensitive constraints of the target language. We propose typesmart constructors as a dynamic approach to enforcing the well-formedness of generated code. A typesmart constructor is a function that is used in place of a regular constructor to create values, but it may reject the creation of values if the given data violates some language-specific constraint. While typesmart constructors can be implemented individually, we demonstrate how to derive them automatically from a grammar, so that the grammar remains the sole specification of a language's syntax and is not duplicated. We have integrated support for typesmart constructors into the run-time system of Stratego to enforce usage of typesmart constructors implicitly whenever a regular constructor is called. We evaluate the applicability, performance, and usefulness of typesmart constructors for syntactic constraints in a compiler for MiniJava developed with Spoofax and in various language extensions of Java and Haskell implemented with SugarJ and SugarHaskell.