Programmers employ crosscutting concepts, such as design patterns and other programming idioms, when their design ideas cannot be efficiently or effectively modularized in the underlying programming language. As a result, implementations of these crosscutting concepts can be hard to change even when the code is well structured. In this article, we describe Arcum, a system that supports the modular maintenance of crosscutting concepts. Arcum can be used to both check essential constraints of crosscutting concepts and to substitute crosscutting concept implementations with alternative implementations. Arcum is complementary to existing refactoring systems that focus on meaning-preserving program transformations at the programming-language-semantics level, because Arcum focuses on transformations at the conceptual level. We present the underpinnings of the Arcum approach and show how Arcum can be used to address several classical software engineering problems.

There are many guidelines for composing programs, but few methodologies take into account the expectations readers have when reading an unfamiliar program. As a result, code that seems well-written and clear to the developer might not be read and interpreted by the reader in the way the programmer expected. We conducted a survey of Java programmers to determine how a program's structure may signal subjective cues to the reader. We found that the use of meaning-preserving program refactorings had a measurable effect on what readers believed the programmer's main intention was.

Today's techniques for controlling access to software artifacts are limited to restricting access to whole files and directories. But when a company's access control policy does not match a project's existing physical modularization, these techniques require either an all-or-nothing approach or re-modularization of the files and directories. The increased maintenance overhead this brings to project administration can lead to unimplemented or insufficient developer access control and an increased risk of insider security incidents (e.g., theft of intellectual property). We have created a tool (GitBAC) to provide access control of software artifacts using a crosscutting concern instead of artifact modularization. Our method provides fine-grained access control of artifacts and accommodates flexible access control policies.

Users have vast amounts of information at their disposal and access to many tools that can compute on that data. Often, no particular program can fulfill a user's needs; or, when such a program exists, it may be too obscure for the user to find. When users encounter this problem, they resort to ad-hoc approaches, such as importing and exporting data to different file formats, as a way to piece together disparate features from several different programs. As a result, users end up manually entering and manipulating data, defeating the purpose of automatic computing machines.

The emergence of aspect-oriented programming (AOP) languages has provided software designers with new mechanisms and strategies for decomposing programs into modules and composing modules into systems. What we do not yet fully understand is how best to use such mechanisms consistent with common modularization objectives such as the comprehensibility of programming code, its parallel development, dependability, and ease of change. The main contribution of this work is a new form of information-hiding interface for AOP that we call the crosscut programming interface, or XPI. XPIs abstract crosscutting behaviors and make these abstractions explicit. XPIs can be used, albeit with limited enforcement of interface rules, with existing AOP languages, such as AspectJ. To evaluate our notion of XPIs, we have applied our XPI-based design methodology to a medium-sized network overlay application called Hypercast. A qualitative and quantitative analysis of existing AO design methods and XPI-based design method shows that our approach produces improvements in program comprehensibility, in opportunities for parallel development, and in the ease when code can be developed and changed.

Crosscutting is an inherent part of software development and can typically be managed through modularization: A module's stable properties are defined in an interface while its likely-to-change properties are encapsulated within the module [19]. The crosscutting of the stable properties, such as class and method names, can be mitigated with automated refactoring tools that allow, for example, the interface's elements to be renamed [9, 18]. However, often the crosscutting from design idioms (such as design patterns and coding styles) are so specific to the program's domain that their crosscutting would not likely have been anticipated by the developers of an automated refactoring system.

Despite the automated refactoring support provided by today's IDEs many program transformations that are easy to conceptualize--such as improving the implementation of a design pattern--are not supported and are hence hard to perform. We propose an extension to the refactoring paradigm that provides for the modular maintenance of crosscutting design idioms, supporting both substitutability of design idiom implementations and the checking of essential constraints. We evaluate this new approach through the design and use of Arcum, an IDE-based mechanism for declaring, checking, and evolving crosscutting design idioms.

The growing popularity of aspect-oriented languages, such as AspectJ, and of corresponding design approaches, makes it important to learn how best to modularize programs in which aspect-oriented composition mechanisms are used. We contribute an approach to information hiding modularity in programs that use quantified advising as a module composition mechanism. Our approach rests on a new kind of interface: one that abstracts a crosscutting behavior, decouples the design of code that advises such a behavior from the design of the code to be advised, and that can stipulate behavioral contracts. Our interfaces establish design rules that govern how specific points in program execution are exposed through a given join point model and how conforming code on either side should behave. In a case study of the HyperCast overlay network middleware system, including a real options analysis, we compare the widely cited oblivious design approach with our own, showing significant weaknesses in the former and benefits in the latter.