Automated Software Development (ASD) are technologies for developing customized programs automatically and compositionally from modules. The foundations of ASD are domain-specific algebras, where each program in the target domain maps to a unique expression. Algebraic identities are used to optimize programs automatically. In this keynote, I trace the history of ASD and present a general theory of modularity for ASD that follows from its tenets.

This demonstration paper presents TouchCORE, a multi-touch enabled software design modelling tool aimed at developing scalable and reusable software design models following the concerndriven software development paradigm. After a quick review of concern-orientation, this paper primarily focusses on the new features that were added to TouchCORE since the last demonstration at Modularity 2014 (were the tool was still called TouchRAM). TouchCORE now provides full support for concern-orientation. This includes support for feature model editing and different modes for feature model and impact model visualization and assessment to best assist the concern designers as well as the concern users. To help the modeller understand the interactions between concerns, TouchCORE now also collects tracing information when concerns are reused and stores that information with the woven models. This makes it possible to visualize from which concern(s) a model element in the woven model has originated.

Korz is a new computational model that provides for context-oriented programming by combining implicit arguments and multiple dispatch in a slot-based model. This synthesis enables the writing of software that supports contextual variation along multiple dimensions, and graceful evolution of that software to support new, unexpected dimensions of variability, without the need for additional mechanism such as layers or aspects. With Korz, a system consists of a sea of method and data slots in a multidimensional space. There is no fixed organization of slots into objects – a slot pertains to a number of objects instead of being contained by a single object – and slots can come together according to the implicit context in any given situation, yielding subjective objects. There is no dominant decomposition, and no dimension holds sway over any other. IDE support is essential for managing complexity when working with the slot space and with subjectivity, allowing the task at hand to dictate what subspaces to isolate and what dominance of dimensions to use when presenting nested views to the user. We have implemented a prototype interpreter and IDE, and used it on several examples. This early experience has revealed much that needs to be done, but has also shown promise. It seems that Korz's particular combination of concepts, each well-known from the past, is indeed more powerful than the sum of its parts.

Many extensions to AspectJ are proposed and prototyped. However, without a supportive language workbench the proper evaluation and production of these extensions is often prohibitively costly. We demonstrate a novel language workbench for creating such extensions, comprising Awesome and Spoofax. The implementation of two advanced extensions to AspectJ are illustrated: explicit join points (EJPs) and closure join points (CJPs). Not only were these extensions fully implemented from scratch with reasonable effort, but also our implementations support advanced features that were omitted in the original prototypes. The demonstration will provide a hands-on overview of the process of implementing EJPs and CJPs in our workbench and how one can implement other extensions with relative ease.

Context-oriented programming (COP) treats context explicitly and provides mechanisms to adapt behavior dynamically in reaction to changes in context at runtime. These languages are desirable to context-sensitive embedded software since such software usually works in various contexts of heterogeneous devices and complex environments. Moreover, a practical development requires proper handling of legacy programs and product lines. To realize these characteristics, we have developed a C# framework called Con-textCS that contains the following features: layer creation at runtime, separation of layer managing program, and the layer with annotation. The article presents the structure of ContextCS.

In Model Driven Development (MDD), invariant checking involves determining whether a model is consistent with invariants defined in a metamodel. Such checking can improve developers' understanding of modeled aspects of complex systems and uncover structural errors in design models during the early stages of software development. General-purpose rigorous analysis tools that check invariants are likely to perform the analysis over the entire metamodel and model. Their scalability thus becomes an issue (e.g., the time used for checking can be up to several hours) with very large metamodels and models (e.g., more than 500,000 elements). In this paper we introduce model slicing within the invariant checking process, and use a slicing technique to reduce the size of checking inputs to improve the scalability of existing invariant checking tools. The evaluation we performed provides evidence that model slicing can significantly reduce the time to perform the invariant checking while preserving the checking results.

Connected objects and monitoring systems continuously produce data about their environment. Dashboards are then designed to aggregate and present these data to end-users. Technologies used to design and implement visualization dashboards are babbling from a software engineering point of view. This paper highlights how this domain could benefit from leveraging separation of concerns and software composition paradigms to support dashboard design.

This paper accompanies a poster submission for the Modularity 2015 conference. The results described in the poster and this overview paper are the accumulation from six years of industry project experience. The projects were multi-year in length with development team sizes of 10 – 20 people, plus the customers. The long project times necessitated the modular structuring of the solution to enable the delivery of partial value as soon as possible. The modular structuring began at the requirements level. The poster lists a brief summary, some of the research questions, the process approaches used and some of the modeling artifacts found useful. There is still work to be done to convert the informal results to a more formal basis in terms of meta-models and cognitive effectiveness.

Programming in a domain specific aspect language (DSAL) typically involves some language workbench for transforming the DSAL code and some AOP composition framework for weaving the transformed code. However, DSAL development remains second-class in two respects. Unlike programming in a general purpose aspect language, compiling DSAL code requires pre-processing that makes the program source code incompatible with existing AOP tools. Unlike defining a domain specific language, defining a DSAL requires weaving semantics whose specification is not supported in the language workbench. In this work we present a DSAL workbench solution in which DSALs are first-class DSLs as well as first-class AOP languages. We illustrate the approach by integrating the Spoofax language workbench and the Awesome composition framework into such a DSAL workbench.

From the early days of computers, researchers have been trying to invent effective and efficient means for expressing software systems through the introduction of new programming languages. In the early days, due to the limitations of the technology, the abstractions of the programming languages were conceptually close to the abstractions of the von Neumann based realization platforms. With the advancement of the technology, computers have been increasingly applied for complex problems in different application domains. This required the challenge of designing programming languages that resemble more the semantics of software rather than the concepts of underlying machinery. To this aim, various new language concepts, such as object-oriented, aspect-oriented, and event-based languages have been introduced. While these languages were successful in enhancing the expression power of languages towards more semantic concerns of application domains, they fail in short in representing emergent behavioral patterns of software effectively. We outline a set of requirements to overcome these shortcomings, and explain the concept of event-based modularization as a possible solution.

Domain specific aspect languages (DSALs) are programming languages that are both domain specific and aspect-oriented. However, DSALs seem to be second-class. On the one hand, language workbenches handle only DSLs that are not aspect-oriented, making it difficult to develop new DSALs. On the other hand, development tools for general purpose aspect-oriented languages do not work with DSALs, making it difficult to use them. In this work we present an approach for building a modular DSAL workbench that produces first-class DSALs. A DSAL is said to be first-class if development tools treat it as a general purpose AOP language. Specifically, this means that first-class DSALs for Java can be used with tools that work with AspectJ. For concreteness, we illustrate the approach by describing our implementation of a DSAL workbench, comprising the Spoofax language workbench and the Awesome composition framework, for programming with first-class DSALs in Java.

Concern-Driven Development builds on the disciplines of model-driven engineering, software product lines and aspect-orientation to define broad units of reuse, so called concerns. The feature model of a concern plays a central role, since it describes the variants encapsulated by a concern, such as, alternative functionality or different design solutions. This paper argues that depending on who is working with the feature model, the encapsulated features and their relationships should be visualized differently: the concern designer is working within the concern module, and therefore needs to see the features of reused concerns that have been selected; the concern user is evaluating if a concern can be reused for a given purpose, and therefore wants to browse the choices that are available.

Unbundling is a phenomenon that consists of dividing an existing software artifact into smaller ones. For example, mobile applications from well-known companies are being divided into simpler and more focused new ones. Despite its current importance, little is known or studied about unbundling or about how it relates to existing software engineering approaches, such as modularization. Consequently, recent cases point out that it has been performed unsystematically and arbitrarily. In this paper, our main goal is to present this novel and relevant concept and its challenges in the light of software engineering, exemplifying it with recent cases. We relate unbundling to standard software modularization, presenting the new motivations behind it, the resulting problems, and drawing perspectives for future support in the area.

Information hiding is an established principle that controls which parts of a module are visible to non-privileged and privileged clients (e.g., subclasses). This aids maintenance because hidden implementation details can be changed without affecting clients. The benefits of information hiding apply not only to code but also to other artifacts, such as specifications. Unfortunately, contemporary formal interface specification languages and their respective runtime assertion checkers (RACs) are inconsistent with information hiding rules because they check assertions in an overly-dynamic manner on the supplier side. We explain how overly-dynamic RACs compromise information hiding and how our client-aware checking technique allows these RACs to use the privacy information in specifications, which promotes information hiding.

To help analyze unexpected behaviour, programming language environments and tools are beginning to support high-fidelity recordings of program executions. Such recordings are typically low-level and difficult to work with directly. Debugging and analyzing these recordings is easier and more powerful if it is possible to simulate executing additional code in the past context of the recording. In prior work we proposed retroactive weaving, the process of evaluating aspects as if they were present during a past execution. This concept is intended as a general framework for introducing additional code and defining the semantics of executing it post-hoc. In this paper we express retroactive weaving as a transformation on aspect-oriented programming languages and their semantics. We demonstrate this transformation by applying it to a simple core aspect-oriented language, and through a definitional interpreter illustrate its interactions with first-class function values, mutable state, and external input and output. In particular a key concern of retroactive weavers is maintaining soundness: behaving consistently with the context of the past execution, and failing if missing information makes this impossible. Retroactive weavers may need to include extra isolation or runtime checks to meet this requirement.

Flow-Based Programming (FBP) is a programming paradigm that models software systems as a directed graph of predefined processes which run asynchronously and exchange data through input and output ports. FBP decomposes software systems into a network of processes. However there are concerns in software systems which do not fit this dominant decomposition. In this paper, we address the cross-cutting-concerns in FBP by using some examples and propose an aspect-oriented extension to FBP.

With an initial motivation based on the security of web applications written in JavaScript, we consider the instrumentation of an interpreter for a dynamic analysis as a crosscutting concern. We define the instrumentation problem — an extension to the expression problem with a focus on modifying interpreters. We then illustrate how we can instrument an interpreter for a simple language using only the bare language features provided by JavaScript.