Macneil Shonle

Modular software design with crosscutting interfaces

Aspect-oriented programming (AOP) languages such as AspectJ offer new mechanisms and possibilities for decomposing systems into modules and composing modules into systems. The key mechanism in AspectJ is the advising of crosscutting sets of join points. An aspect module uses a pointcut descriptor (PCD) to declaratively specify sets of points in program executions. Our approach employs crosscut programming interfaces, or XPIs. XPIs are explicit, abstract interfaces that decouple aspects from details of advised code

Information hiding interfaces for aspect-oriented design

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.

XAspects: an extensible system for domain-specific aspect languages

Current general aspect-oriented programming solutions fall short of helping the problem of separation of concerns for several concern domains. Because of this limitation good solutions for these concern domains do not get used and the opportunity to benefit from separation of these concerns is missed. By using XAspects, a plug-in mechanism for domain-specific aspect languages, separation of concerns can be achieved at a level beyond what is possible for object-oriented programming languages. As a result, XAspects allows for certain domain-specific solutions to be used as easily as a new language feature.

Modular aspect-oriented design with XPIs

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.

AspectBrowser for Eclipse: a case study in plug-in retargeting

A powerful feature of Eclipse is its plug-in architecture for incorporating third-party tools. An important source of plug-ins is standalone tools that were developed prior to the release of Eclipse. However, such tools inevitably incorporate features that Eclipse provides natively, requiring rework to rehost those features to Eclipse.In our retarget of the AspectBrowser application to Eclipse, we found not only an unexpected number of deeply ingrained features that needed to be rehosted, but also numerous GUI and architectural mismatches between AspectBrowsers version of these features and Eclipses. By judiciously resolving these issues, we were able to minimize their impact on the AspectBrowser base code, and still reap significant benefits from Eclipses high level of plug-in integration. For example, AspectBrowser is able to function as a viewer for any existing plug-in that produces Eclipse resource markers.This paper describes the insights gained from retargeting AspectBrowser to Eclipse and provides guidelines to those retargeting tools to Eclipse. We also reflect on the importance of recent improvements to Eclipse in this process, and what additional improvements could be made.

Beyond refactoring: a framework for modular maintenance of crosscutting design idioms

Despite the automated refactoring support provided by todays 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.

Star diagram with automated refactorings for Eclipse

One of the powerful features of the Eclipse JDT plug-in is its refactoring feature. Yet, because many refactorings are global and architectural in nature, the textual presentation of refactorings presents challenges for designers. We have designed and implemented the visual Star Diagram automated refactoring plug-in to ease such refactorings. This paper motivates and introduces star-diagram-based refactorings, demonstrates that new tools can be implemented on top of existing JDT refactorings, and reflects on the challenges that the JDT refactoring API presents in supporting novel extensions. In this last category, we found it difficult to build on the refactoring API to introduce more general refactoring semantics and visualizations of refactoring opportunities.

Addressing common crosscutting problems with Arcum

Crosscutting is an inherent part of software development and can typically be managed through modularization: A modules 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 interfaces 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 programs domain that their crosscutting would not likely have been anticipated by the developers of an automated refactoring system. The Arcum plug-in for Eclipse enables programmers to describe the implementation of a crosscutting design idiom as a set of syntactic patterns and semantic constraints. Arcum can process declarations of related implementations and infer the refactoring steps necessary to transform a program from using one implementation to its alternatives. As a result, automating refactoring for domain-specific crosscutting design idioms can be easy and practical. This paper presents a case study of how Arcum was used to mitigate four classic software engineering problems that are exacerbated by crosscutting: library migration, debugging, programmer-defined semantic checking, and architectural enforcement.

When refactoring acts like modularity: keeping options open with persistent condition checking

Oftentimes the changes required to improve the design of code are crosscutting in nature and thus easier to perform with the assistance of automated refactoring tools. However, the developers of such refactoring tools cannot anticipate every practical transformation, particularly those that are specific to the programs domain. We demonstrate Arcum, a declarative language for describing and performing both general and domain-specific transformations. Because Arcum works directly with declarative descriptions of crosscutting code it can ensure that code written or modified after the transformation also satisfies the designs requirements. As a result, preconditions and postconditions are persistently checked, making the crosscutting code (such as the use of a design idiom or programming style) behave more like a module with respect to checkability and substitutability. Bringing such capabilities into the IDE allows for code to be decomposed closer to the programmers intentions and less coupled to specific implementations.

Programming from the Reader's Perspective: Toward an Expectations Approach

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 programs 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 programmers main intention was.