By 2030 for each filled position in Software Engineering, two positions would remain unfilled. This already apparent loss of productivity has the software industry scrambling to fill the missing positions with citizen developers---technical people with little or no programming skills---who would be using No-Code platforms to program various software solutions in specific domains. However, currently available platforms have fairly limited abstractions, lacking the flexibility of a general purpose programming language.

Even code that is free of smells may be at high risk of forming them. In such cases, developers can either perform preventive refactoring in order to reduce this risk, or leave the code as is and perform corrective refactoring as smells emerge. In practice, however, developers usually avoid preventive refactoring during the development phase, and when code smells eventually form, other developers who are less acquainted with the code avoid the more complex corrective refactoring. As a result, a refactoring opportunity is missed, and the quality and maintainability of the code is compromised. In this work, we treat refactoring not as a single atomic action, but rather as a sequence of subactions. We divide the responsibility for these subactions between the original developer of the code, who just prepares the code for refactoring, and a future developer, who may need to carry out the actual refactoring action. To manage this division of responsibility, we introduce a set of annotations along with an annotation processor that prevents software erosion from compromising the ability to perform the refactoring action.

Large and medium scale software projects often require a source code revision control (RC) system. Unfortunately, RC systems do not perform well with obliviousness and quantification found in aspect-oriented code. When classes are oblivious to aspects, so is the RC system, and the crosscutting effect of aspects is not tracked. In this work, we study this problem in the context of using AspectJ (a standard AOP language) with Subversion (a standard RC system). We describe scenarios where the crosscutting effect of aspects combined with the concurrent changes that RC supports can lead to inconsistent states of the code. The work contributes a mechanism that checks-in with the source code versions of crosscutting metadata for tracking the effect of aspects. Another contribution of this work is the implementation of a supporting Eclipse plug-in (named XRC) that extends the JDT, AJDT, and SVN plug-ins for Eclipse to provide crosscutting revision control (XRC) for aspect-oriented programming.

Language Oriented Programming (LOP) is a paradigm that puts domain specific programming languages (DSLs) at the center of the software development process. Currently, there are three main approaches to LOP: (1) the use of internal DSLs, implemented as libraries in a given host language; (2) the use of external DSLs, implemented as interpreters or compilers in an external language; and (3) the use of language workbenches, which are integrated development environments (IDEs) for defining and using external DSLs. In this paper, we contribute: (4) a novel language-oriented approach to LOP for defining and using internal DSLs. While language workbenches adapt internal DSL features to overcome some of the limitations of external DSLs, our approach adapts language workbench features to overcome some of the limitations of internal DSLs. We introduce Cedalion, an LOP host language for internal DSLs, featuring static validation and projectional editing. To validate our approach we present a case study in which Cedalion was used by biologists in designing a DNA microarray for molecular Biology research.

In the Adaptive Object-Model (AOM) architectural style, user-defined domain entities and their relationships, attributes and behavior are described by externally stored metadata. AOM implementations reify the domain entities at runtime by interpreting the metadata. Users change the object model by editing the metadata to reflect changes in the domain. This paper describes a pattern for incorporating model changes into an AOM production system without taking the system off-line. Dynamic evolution of the object model is done during loading of a domain object. The Dynamic Model Evolution pattern is applicable when a system needs to keep running, and the alternative of updating the entire object model at the time a new version comes online is too time consuming to be a practical option.

The simultaneous use of multiple aspect languages has the potential of becoming a significant one, as new aspect- oriented frameworks are developed and existing ones expand to incorporate features of others. A key challenge in combining multiple aspect-oriented languages is identifying and resolving adverse feature interactions. These interactions occur due to the incompatible and inconsistent treatment of aspects, join points, and advice across different languages. In this paper, we analyze the root cause of this feature interaction problem. We classify common features of aspect languages, describe how these features may interact when using different aspect languages in tandem, and concretely illustrate how these interactions may be resolved. Our work allows AOP users and tool developers to reason about the occurrence of such adverse and unexpected feature interactions, and to apply several patterns for resolving these problems.

Domain specific aspect-oriented language extensions offer unique capabilities to deal with a variety of cross cutting concerns. Ideally, one should be able to use several of these extensions together in a single program. Unfortunately, each extension generally implements its own specialized weaver and the different weavers are incompatible. Even if the weavers were compatible, combining them is a difficult problem to solve in general, because each extension definesits own language with new semantics. In this paper we present a practical composition framework, named Awesome, for constructing a multi-extension weaver by plugging together independently developed aspect mechanisms. The framework has a component-based and aspect-oriented architecture that facilitates the development and integration of aspect weavers. To be scalable, the framework provides a default resolution of feature interactions in the composition. To be general, the framework provides means for customizing the composition behavior. Furthermore, to be practically useful, there is no framework-associated overhead on the runtime performance of compiled aspect programs. To illustrate the Awesome framework concretely, we demonstrate the construction of a weaver for a multi-extension AOP language that combines Cool and AspectJ. However, the composition method is not exclusive to Cool and AspectJ-it can be applied to combine any comparable reactive aspect mechanisms.

A plethora of aspect mechanisms exist today. All of these diverse mechanisms integrate concerns into artifacts that exhibit crosscutting structure. What we lack and need is a characterization of the design space that these aspect mechanisms inhabit and a model description of their weaving processes. A good design space representation provides a common framework for understanding and evaluating existing mechanisms. A well-understood model of the weaving process can guide the implementor of new aspect mechanisms. It can guide the designer when mechanisms implementing new kinds of weaving are needed. It can also help teach aspect-oriented programming (AOP). In this paper we present and evaluate such a model of the design space for aspect mechanisms and their weaving processes. We model weaving, at an abstract level, as a concern integration process. We derive a weaving process model (WPM) top-down, differentiating a reactive from a nonreactive process. The model provides an in-depth explanation of the key subprocesses used by existing aspect mechanisms.

Studies of Aspect-Oriented Programming (AOP) usually focus on a language in which a specific aspect extension is integrated with a base language. Languages specified in this manner have a fixed, non-extensible AOP functionality. This paper argues the need for AOP to support the integration and use of multiple domain-specific aspect extensions together. We study the more general case of integrating a base language with a set of third-party aspect extensions for that language. We present a general mixin-based semantic framework for implementing dynamic aspect extensions in such a way that multiple, independently developed aspect mechanisms can be subject to third-party composition and work collaboratively. Principles governing the design of a collaborative aspect mechanism are aspectual effect exposure and implementation hiding.

Reflection remains a second-class citizen in current programming models, where it's assumed to be imperative and tightly bound to its implementation. In contrast, most object-oriented APIs allow interfaces to vary independently of their implementations. Components take this separation a step further by describing unforeseeable attributes-the key to pluggable third-party components. This paper describes how reflection can benefit from a similar evolutionary path.

Complex behavior often resists clean modularization in object-oriented languages. Aspect-oriented programming tackles this problem by providing flexible module boundaries that can span and partition classes. However, in order to achieve this flexibility, valuable modularity mechanisms, such as encapsulation and external composition, are lost. The ability to separately compile or reason about a modular unit is also compromised. We propose that this tradeoff is not necessary and that by expressing aspects as part of our modules, we can restore the lost modular properties while maintaining aspectual features. As a concrete demonstration, we present the main features of Aspectual Collaborations and show how these interact to combine modularity with aspectual behavior. The expressiveness of Aspectual Collaborations, AspectJ and Hyper/J are compared using a challenge problem, allowing us to estimate the effectiveness of the approach.

A good object oriented design does not necessarily make a good component based design, and vice versa. What design principles do components introduce? The paper examines component based programming and how it expands the design space in the context of an event based component architecture. We present a conceptual model for addressing new design issues these components afford, and we identify fundamental design decisions in this model that are not a concern in conventional object oriented design. We use JavaBeans based examples to illustrate concretely how expertise in component based design, as embodied in a component taxonomy and implementation space, impacts both design and the process of design. The results are not exclusive to JavaBeans; they can apply to any comparable component architecture.

New approaches propose to deal with the tangling of logical units by extending the object-oriented language to support module (de)composition along more than one dimension of concern. The tutorial will briefly survey Aspect-Oriented Programming (@@@@ectJ tool), Adaptive Programming (the Demeter tool), and Hyper-dimensional Separation of Concerns (the Hyper/J tool). The primary focus of the tutorial, however, will be on A daptive Plug-and-Play Components (AP&PC) [2, 1].

This paper explains how patterns can be used to describe the implementation of other patterns. It is demonstrated how certain design patterns can describe their own design. This is a fundamental reflexive relationship in pattern relationships. The process of assembling patterns by other patterns is named pattern tiling. Tiling enables us to interweave simple understood concepts of patterns into their complex real-life implementation. Several pattern tilings for the Interpreter design pattern are illustrated.

The class of an object is not necessarily the only determiner of its runtime behaviour. Often it is necessary to have an object behave differently depending upon the other objects to which it is connected. However, as it currently stands, object-oriented programming provides no support for this concept, and little recognition of its role in common, practical programming situations. This paper investigates a new programming paradigm, environmental acquisition in the context of object aggregation, in which objects acquire behaviour from their current containers at runtime. The key idea is that the behaviour of a component may depend upon its enclosing composite(s). In particular, we propose a form of feature sharing in which an object "inherits" features from the classes of objects in its environment. By examining the declaration of classes, it is possible to determine which kinds of classes may contain a component, and which components must be contained in a given kind of composite. These relationships are the basis for language constructs that supports acquisition. We develop the theory of acquisition that includes topics such as the kinds of links along which acquisition may occur, and the behaviour of routine (methods) and attribute features under acquisition. The proposed model for acquisition as a hierarchical abstraction mechanism is a strongly typed model that allows static type checking of programs exploiting this mechanism. We compare it to several other mechanisms including inheritance and delegation, and show that it is significantly different than these.