The design of a continually-evolving system deteriorates in proportion to the frequency of evolution as much as the complexity of evolution. Here we introduce a design paradigm, Temporal Control Flow Rule-based Architecture (TeCFRA), with a vision to support dynamic evolution in software architecture. TeCFRA provides this support especially when new rules for existing business processes co-exist with old rules. TeCFRA also strives to attain a higher precision level in change-impact analysis.

This extended abstract overviews our modularity vision along a technical-organizational-ecosystem dimension. Our goal is to explore the benefits that modularity could provide to software vendors in the rapidly changing landscape of mobile game development. Our research suggests a promising synergy between the software ecosystem and modularity communities.

Attempts to architect more flexible software often results in the opposite - brittle software fraught with complexity. Something is missing. Complexity is the beast we must tame, and modularity is part of the answer. In this keynote, we'll examine the challenges of traditional approaches to software architecture, probe the paradox of architecture, and explore the inextricable link between structural and temporal architectural decisions. From the highest level applications and services to the code that exists in the bowels of the system, we expose the advantages of a modular architecture. Come learn new ways that large software systems can be organized to increase flexibility, reusability, adaptability, maintainability, testability, and extensibility. Come discover the importance of modularity!

Software systems are increasingly being built as compositions of reusable artifacts (components, frameworks, toolkits, plug-ins, APIs, etc) that have non-trivial usage constraints in the form of interface contracts, underlying assumptions and design composition rules. Satisfying these constraints is challenging: they are often not well documented; or they are difficult to integrate into the software development process in ways that allow their identification by developers; or they may not be enforced by existing tools and development environments. Aspect-Oriented Programming has been advocated as an approach to represent and enforce software constraints in code artifacts. Aspects can be used to detect constraint violations, or more pro-actively, to ensure that the constraints are satisfied without requiring the developer's attention. This paper discusses our experience using aspects to document and enforce software constraints in an industrial application, specifically TDE/UML, a model-driven software testing tool developed at SIEMENS. We present an analysis of common constraints found in our case study, a set of primitive aspects developed to help the enforcement of software constraints, and show how AOP has been incorporated into existing software development and governance approaches in the TDE/UML project. We conclude with a discussion of strengths and limitations of AspectJ in supporting these constraints.

Hardware-design requirements are becoming increasingly complex. Accordingly, the hardware developer is also beginning to use modern programming languages instead of traditional hardware description languages. However, modularity of the current hardware design has not changed from that of the traditional design. In this paper, we first conducted empirical investigation by interviews with real-world developers of circuit products, and confirmed that there exist cross-cutting concerns in actual products. The cross-cutting concerns fall into two types: one in common with software development and one specific to hardware design. In light of these results, this paper proposes ASystemC, an AOP extension for the hardware description language SystemC. ASystemC provides AOP features based on the AspectJ-like pointcut-advice mechanism. The design principle of ASystemC is practicality; we designed ASystemC to accept existing SystemC source code, and to weave aspects by using source-to-source conversion that outputs human-readable SystemC code. This design allows a user to utilize not only existing codes but also the existing knowledge and development process, as much as possible. As a result, ASystemC does not require modification of the existing source code review process and source analysis/manipulation tools, even if there is a developer unfamiliar with ASystemC in a development team. In addition, we confirmed the practicality and fiexibility of ASystemC through case studies: estimation of circuit size by using simulation, feature-configurable products and LTL verification. These cases are abstracted from actual problems in our products. They require not only code-level changes but also structural changes.

The Java programming language offers several basic constructs for concurrent programming. Despite covering everything needed from a functional point of view, the constructs are difficult to use since they require a lot of infrastructural statements besides the real logic. This makes concurrent programming errorprone and difficult to reuse. It seems that abstractions are needed to ease the pain and to better support reusability.

This paper explores how to use and benefit from aspect-orientation (AO), particularly the AspectJ language, in this respect. AO promises a high potential for reuse due to a higher level of modularization since crosscutting concerns can better be modularized in aspects. This paper confirms higher reuse by presenting a collection of reusable aspects for solving specific problems in concurrent programming.

Having AspectJ-based implementations for recurring problems, this paper also summarizes some interesting experiences and takes the chance to present an industrial view on some criticisms of aspect-orientation.

Byteman is a flexible, dynamic advice injection tool for Java. It uses an Event Condition Action rule script language to structure placement and control execution of injected Java code fragments. The Byteman agent can be loaded at application startup or into a running application and rules can be loaded, unloaded and reloaded while the application continues running.

This makes Byteman ideal for use in live deployments, simplifying tracing and diagnosis of bugs and investigation and monitoring of performance issues. Byteman is also very useful during all stages of testing. Tests can inject rules into an application or subsystem during test initialisation or as the test progresses, redirecting or breaking the application code at strategic points and validating application behaviour. This limits the need to write harness or mock code, and minimises the extent to which the test distorts normal execution, ensuring that test conditions are as close to live running as possible.

Byteman is being used widely within JBoss to perform unit, integration and system testing. Our customer support team use it to perform tracing, debugging and validation of JVM, JBoss and customer code, both inhouse and in live deployments. We are currently developing an extensible, reconfigurable statistical performance monitoring package for JBoss AS based on Byteman. We expect this to be easily extended by JBoss AS customers to enable monitoring of their own applications.

This paper employs real examples of these use cases to demonstrate how Byteman works. It shows how Byteman makes advice injection simpler, quicker and more interactive than alternative tools without sacrificing power or rigour.

Refactoring code to make it more maintainable and extendable has become a more mainstream practice. Refactoring is the process of changing software without altering its external behavior. It is done in such as way to improve the structure of the code to allow for later extensions or to make maintenance of the code easier. It is important to refactor your code in a disciplined way to minimize disruptions and to allow the system to safely evolve. Improving a systems structure and readability through refactoring enhances its comprehensibility, readability, and maintainability.

This is a half-day tutorial dealing with the relatively new field of modeling language design.

We have a problem: there is a stunning number of programming technologies out there. There are silos of knowledge around these technologies and technical spaces. In fact, it is not even clear that this abundance can still be approached by computer scientists. Q: How can we possibly understand those technologies in an academically valid manner? A: By analogy, examples, and abstraction!

Agile practices liberate us from the straightjackets of top-down design. But, the ease with which requirements can change encou-rages users to overwhelm us with requests for features. The result: Featuritis, which promotes hasty construction of poorly designed software to support those features. The design of an expressive domain model might get lost in the rush to write working code. Adaptive Object-Models support changeable domain modules by casting business rules as interpreted data and representing objects, properties and relationships in external declarations. Now users can change the system domain models themselves as their busi-ness dictates without having to deal with programmers at all. It's the ultimate in agility!

This tutorial discusses aspect-oriented requirements engineering, focusing on scenario-based and goal-oriented requirements models with the Aspect-oriented User Requirements Notation (AoURN). AoURN is an extension of the User Requirements Notation (URN), a recent international modeling standard for requirements engineering published by the International Telecommunication Union. AoURN is a strong candidate for inclusion in future versions of the standard. While the tutorial gives a thorough introduction to AoURN, it places particular emphasis on AoURN's advanced composition mechanisms which enable interleaved and semantics-enhanced compositions. In addition, the impact of aspect-orientation on existing URN analysis capabilities is discussed.

This tutorial will provide an introduction to Ptolemy. Ptolemy is a programming language whose goals are to improve a software engineer's ability to separate conceptual concerns, while preserving encapsulation of object-oriented code and the ability of programmers to modularly reason about their code. In particular, Ptolemy's features are useful towards modularization of cross-cutting concerns. A cross-cutting concern is a requirement whose implementation is spread across and mixed with the code of other requirements. There has been attempts to improve separation of cross-cutting concerns, e.g. by aspect oriented and implicit-invocation languages, but none give software developers textual separation of concerns and modular reasoning at the same time. Ptolemy has both these properties important for scalable software engineering. Ptolemy's event types provide a well-defined interface between object-oriented code and cross-cutting code. This in turn enables separate type-checking and compilation. Ptolemy also provides a novel and practical specification mechanism that we call translucid contracts. A translucid contracts allows developers to reason about the control effects of the object-oriented code and cross-cutting code modularly.

This tutorial will proceed by discussing the goals of the Ptolemy programming language. We will then discuss Ptolemy's programming features and its specification features by way of several hands-on exercises. We will conclude with pointers to ongoing work on design, implementation and verification of Ptolemy programs.

We present ArchE Meter, a tool that supports developers in understanding how the implementation of an aspect-oriented system conforms to its intended layered software architecture. Based on the principles of layered software architectures, ArchE Meter indicates to what extent the implementation of a software system violates its layering structure in terms of three different kinds of violations.

Hist-Inspect is a tool that allows the specification and evaluation of different configurations for detection strategies by means of a domain-specific language. The tool enables to easily adjust thresholds and combination of software metrics as well as compare the performance of conventional and history-sensitive detection strategies. The tool also provides a diverse set of views, including graphical representation of module evolution measures. These views enable the code reviewer to reason about the stability of individual modules, the growth or decline of a particular structural property (e.g. coupling or cohesion), without the burden of recovering all the values for each version under analysis.

EScala is an extension of Scala with support for declarative event-driven programming. It provides mechanisms for declarative definition of events and employs aspect-oriented techniques for exposing implicitly existing events, which reduces the need for explicit triggering of events. EScala provides a conservative integration of declarative events into an object-oriented language. Events are declared as attributes of objects and are subject to inheritance and subtype polymorphism. The language fully preserves encapsulation of objects and modular compilation of classes. Designs based on declarative events are as efficient as conventional event-driven designs.

Attendees of the demonstration will see a live example that illustrates the expressiveness gained by the features of EScala. We will show how events can be defined in a declarative way and how to use such events for defining interactions among objects. We will demonstrate how declarative events can be used to replace observers and so result in more concise and modular design. Finally, we will show how to use the events library with a standard Scala compiler.

Software product line (SPL) engineering has been focused on tailor single products without programming new completion code. Systematic reuse as configuration potentially lead to significant gains but requires the configuration knowledge to be well conducted. However, due to the use of frameworks to relive the development of software systems, it might become difficult to have precise and comprehensible configuration knowledge specifications. First, because the completion code of a specific framework-provided concept might be scattered across and tangled with code implementing other concepts or features. Second, creating an instance of a framework-provided abstraction involves making implementation choices, some of which are stipulated by hidden programming interface and crosscut heterogeneous languages. In this demonstration we present a tool based on Domain Knowledge Modeling Languages. They are used to express models specifying the configuration knowledge of a specific implementation domain and, ensure the consistency and ease the comprehension of framework-based SPL.

In this paper, we describe the features of the ReqSys tool, a tool to verify and map PL-AOVgraph models into feature models.

Aspect-Oriented Programming (AOP) has introduced a complementary set of mechanisms which enhance the modularisation of crosscutting concerns. However, such mechanisms represent new potential sources of faults that may be systematically tackled with mutation testing. In this demonstration we present a tool, named Proteum/AJ, which automates the mutation testing of AspectJ programs. Proteum/AJ supports the main steps of this testing approach and realises a set of requirements for mutation-based testing tools like mutant handling, test case handling and mutant analysis. Our experience in using the tool provided us with evidence on the feasibility of performing mutation testing of AO programs. In this demonstration we are going to share some of this experience with the audience.

Accurate and efficient dynamic analysis tools are needed for understanding and improving performance of programs. However, such tools often produce perturbed and misleading results, since the inserted analysis code may interfere with runtime optimizations performed by the just-in-time compiler. In this work, I present an approach based on aspect-oriented programming (AOP) to dynamically refine the scope of an analysis, gradually reducing the number of intercepted join points at runtime, considering only those that are relevant for the specific analysis. The motivating example is an aspect-based hotspot locator based on execution time profiling.

Although aspect-oriented programming (AOP) aims to improve the software modularity, developers can unwittingly introduce code smells in their programs. Even though a few code smells for AOP have been reported in the literature, there is no evidence whether and how they occur in evolving software projects. There is also little knowledge on their actual impact on architecture degeneration, such as their correlation with architecturally-relevant flaws. Therefore, in this research we investigate which AOP smells occur in evolving software systems and how their (co-)occurrence are usually associated with architecturally-relevant flaws. The basic idea is to equip AOP developers with analysis techniques for the source code that exploit the architectural design information.

The contributions of this research are briefly described as follows: an evaluation framework for model composition effort; practical knowledge about the values that the composition effort variables assume in realistic composition scenarios, i.e., the quantification of the required effort on applying the (semi-)automated composition techniques, detecting conflicts and resolving the emerging conflicts; the identification of specific scenarios of evolution and factors that lead the composition technique to success (lower effort) or fail (higher effort). We also summarize some interesting findings: the higher the number of overlapping parts of the input models is, the higher the composition effort is; conflict propagation between the model elements has a negative impact on the developers' effort; sometimes developers prefer "living with conflicts" instead of spending effort to resolve them; and the resolution of unexpected conflicting changes is influenced by the developers' reputation in the software development team.

The adoption of Aspect Oriented Programming (AOP), and in general, of more sophisticated composition models is a recent trend in software engineering to address the problem of the correct modularization of cross-cutting concerns. However, most of these models are not well-suited for the particular conditions, scale and complexity of the problems inherent to distributed systems. This paper outlines a minimum set of desirable criteria for an aspect oriented model for those systems. We study some problems with existing models and propose a solution inspired by the actor model with aspect mobility and controlled invasiveness.

In previous work we successfully modularized the Java access control architecture. The approach consists in expressing access control using restriction aspects scoped with an appropriate scoping strategy. In this work we briefly explore how restriction aspects and scoping strategies make it possible to express novel and useful access control policies in a direct manner.