Separation of Concerns

Abstract:

Building software from reusable components is considered important in reducing development costs. Object-oriented languages such as C++, Smalltalk and Java, however, are not capable of expressing certain aspects of applications in a reusable way. Software engineers may experience difficulties in composing and reusing applications from components, for example if components implement code for multiple views, dynamic inheritance and synchronization. If these aspects have to be programmed, then object-oriented languages may require a considerable amount of redefinition although this may not be intuitively necessary. Several researchers termed these problems as inheritance anomalies, cross-cutting, etc. Aspect-oriented programming aims at addressing these problems by specifying and composing the aspects of a program in a systematic way. Composition-Filters is an aspect-oriented programming technique where different aspects are expressed in Filters as declarative and orthogonal message transformation specifications. The aspect-composition process of the Composition-Filters approach is general. Different aspects can be expressed in filters and then be composed together without building dedicated generators. Composition-Filters can be attached to the objects programmed in different object-oriented languages. This paper first illustrates some practical problems of the conventional object-oriented languages and then introduces Composition-Filters solutions to overcome these problems.

Abstract:

Aspect-oriented technology is a programming paradigm that provides the user with the ability to modularize the representation of crosscutting concerns in order to maximize reusability and ensure flexibility of the software system. In this position paper we present the dynamic Weaver Framework (DWF), which is an aspect-oriented framework that supports the dynamic attachment and detachment of aspects to components at run-time, as well as the capability to add and remove aspects and pointcuts during runtime. This capability is the prime factor that enables us to support reconfigurability of the software system. The need to adapt to environmental changes and cope gracefully with the challenges that may have an impact on performance degradation, safety and liveness properties of the running system requires recongfigurability of both the functional and aspectual properties of the system software.

Abstract:

AOP has matured to become Aspect Oriented Software Development (AOSD) that means the community recognizes the importance of applying aspect orientation to all phases of software development life cycle. Once an initial decomposition of the problem domain identifies software components and the corresponding aspectual properties that cut through these components we would like to be able to express this initial decomposition and carry it to the next life cycle phase. For this refinement process to be effective it must preserve the initial semantics.

In this Position paper we propose an initial discussion on UML profile for AO modeling, which we believe will set the stage for AOSD modeling and hence move us towards a truly aspect oriented software systems. We also initiate the discussions regard modeling the orthogonal concerns in the aspect oriented software system, where loosely coupled concerns in different dimensions can be easily modeled and reasoned about in isolation of the core components and aspectual components.

Abstract:

Code is modularized for many reasons, including making it easier to understand, change, and verify. Aspect-oriented programming approaches extend the kind of code that can be modularized, enabling the modularization of crosscutting code. We conducted an inquisitive study to better understand the kinds of crosscutting code that software developers encounter and to better understand how the developers manage this code. We tracked eight participants: four from industry and four from academia. Each participant was currently evolving a non-trivial software system. We interviewed these participants three times about crosscutting concerns they had encountered and the strategies they used to deal with the concerns. We found that crosscutting concerns tended to emerge as obstacles that the developer had to consider to make the desired change. The strategy used by the developer to manage the concern depended on the form of the obstacle code. The results of this study provide empirical evidence to support the problems identified by the aspect-oriented programming community, and provide a basis on which to further assess aspect-oriented programming.

Abstract:

Quality of service (QoS) is an important requirement of today's distribution infrastructures. The popularity of object-oriented middleware makes QoS provision in those infrastructures desirable. The system-dependent nature of QoS necessitates a clear separation of concerns and insulation from the application objects. In this paper, QoS integration is investigated from two viewpoints. First, based on the aspect-oriented programming, the integration of QoS mechanisms into the application objects is presented, and second, the hierarchical structure of QoS mechanisms is addressed in a reflection-based approach.

Abstract:

Encapsulation has received considerable interest in the context of object-oriented programming. In particular the encapsulation of objects that are composed through inheritance has been discussed repeatedly [Snyder 86, Micallef 88]. Aspect-oriented composition has similar considerations. However, most approaches to aspect-orientation or multi-dimensional composition of concerns do not enforce encapsulation of the implementation details of concerns. This might even lead to the impression that aspect-orientation conflicts with encapsulation. We claim that aspect-orientation and encapsulation are orthogonal, and that it is possible, and desirable, to enforce strong encapsulation in the presence of aspects. We illustrate this by giving an example and showing a (proposed) solution based on the composition filters model.

Abstract:

Attempts to evolve a code base in an effective and comprehensible manner can give almost anyone a headache. For example, consider version 2 vs version 3 of FreeBSD's implementation of the Network File System (NFS) [5]. The v2 code base is approximately 10,000 lines, to which the integration of v3 adds over 100 small, scattered clusters of code. Although this code is differentiated from v2 by appropriate compiler-directives and system-wide identifiers, its crosscutting nature adds complexity to the original code, and introduces implicit coupling that poses further challenges for future evolution. This observation is consistent with Lehman and Belady's study showing structural deterioration over successive releases of OS/360 [4]. We are currently trying to determine the material impact aspect-oriented modularity has on the evolution of NFS code. Towards this end, we are studying implementations of versions 2 and 3, along with the specifications of 4 (not yet available in implementation). To date, we have designed an aspect that structures v3 client functionality relative to a v2 implementation for FreeBSD, and are working on OS neutral v4 features that we expect to be highly portable to both FreeBSD and Linux NFS implementations. This short paper presents some of our preliminary work, including (1) an example aspect-oriented implementation of a v4 related feature, replication, developed for a model of NFS, (2) a comparison of this implementation with an interposition approach, and (3) a characterization of how to build highly portable aspect-oriented implementations.

Abstract:

Abstract:

Requirements such as distribution or tracing have an impact on multiple classes in a system. They are cross-cutting requirements, or aspects. Their support is, by necessity, scattered across those multiple classes. A look at an individual class may also show support for cross-cutting requirements tangled up with the core responsibilities of that class. Scattering and tangling make object-oriented software difficult to understand, extend and reuse. Though design is an important activity within the software lifecycle, with well-documented benefits, those benefits are reduced when cross-cutting requirements are present. This paper presents a means to mitigate these problems by separating the design of cross-cutting requirements into composition patterns. Composition patterns require extensions to the UML, and are based on a combination of the subject-oriented model for composing separate, overlapping designs, and UML templates. This paper also demonstrates how composition patterns map to one programming model that provides a solution for the separation of cross-cutting requirements in the code - aspect-oriented programming. This mapping serves to illustrate that separation of aspects may be maintained throughout the software lifecycle.

Abstract:

In practice, object-oriented design models have been less useful throughout the lifetime of software systems than they should be. Design models are often large and monolithic, and the structure of the designs is generally quite different from that of requirements. As a result, developers tend to discard the design, especially as the system evolves, since it is too difficult to keep its relationship to requirements and code accurate, especially when both are changing. This paper presents a different approach to designing systems, based on flexible decomposition and composition, that closely aligns designs with both requirements specifications and with code. We illustrate how this approach permits the benefits of designs to be maintained throughout a system's lifetime.

Abstract:

In order to find the right balance between exibility and expressive- ness, current aspect-oriented technologies provide a predefined set of selection and combination mechanisms to drive the weaving process. If a programmer wants to use specialized mechanisms beyond the possibilities of this set, he must resort to a combination of mapping onto existing mechanisms and hand coding into the application. Establishing a fixed set of mechanisms considerably limits the usefullness of aspect-oriented programming both at weave-time and at run-time. As a result, building advanced reusable systems becomes hard.

In this position paper we propose a first step towards a more open weaving process for AspectJ by introducing a generic way to describe joinpoints through a two step process of enumeration and restriction. By means of some examples, we show that this technique enables very exible deployment decisions. And although the ideas are not fully mature yet, we also try to discuss the advantages and disadvantages of the approach.

Abstract:

Several design patterns are defined to make systems more flexible and extensible. The main goal of this work is to show how the representation of these kinds of patterns, which we refer to as configuration design patterns, can be vastly improved through extensions to the diagrams used to model them. An extension to the UML design notation to better represent configuration patterns is proposed and illustrated through examples of well-known design patterns and real-world frameworks. The article also shows that the proposed representation can be more easily mapped to new implementation techniques such as aspect-oriented programming and subject-oriented programming.

Abstract:

Designing software systems is difficult. Designing systems that are capable of evolving is even more difficult. Often the system evolves in an unforeseen direction. Practice shows that software systems grow in small evolutionary steps. An evolution usually influences the behavior and the structure of the system. However, it is not desired that the evolution influences one or more modules of the system that are functionally or logically not related to the evolution; the behavior and structure of these modules should be preserved.

In this position paper, we introduce an algebra as a formal foundation for reasoning about evolution. The algebra can be used to express changes in the behavior and structure of the design when it evolves. The aim is to eventually use the algebra to give decision support to the developer during the evolution of a software system.

Abstract:

Several new modularity technologies have been proposed that improve separation of concerns in programming languages. The initial efforts to demonstrate these technologies are usually focused on a single programming language. Since we live in a polyglot world, this proposal addresses the goal of being able to take these new powerful technologies to other languages. The approach uses software generators that create new "weavers" from meta-specifications of programming languages.

Abstract:

In this paper we present a security framework for Bond, a message-oriented distributed object middleware for network computing. Bond Security Framework, BSF, allows developers to exercise performance-security tradeoffs and use the security model best suited for a specific application and for a given environment. BSF consists of an extensible core and a set of well defined security interfaces. Any Bond object can become a secure object when extended with a dynamic property called bondSecurityContext.

Abstract:

Separation of concerns is a basic engineering principle that is also at the core of object-oriented analysis and design methods in the context of the Unified Modeling Language (UML). The UML gives the designer a rich, but somehow disorganized, set of views on her model as well as many features, such as design pattern occurrences, stereotypes or tag values, allowing her to add non-functional information to a model. Aspect-oriented concepts are applied to manage the multitude of design constraints. However, it can then be an overwhelming task to reconcile the various aspects of a model into a working implementation. In this paper, we introduce our UMLAUT framework as a tool for “weaving” aspects when modeling with the UML. This is accompanied with an example of a distributed multimedia application, applying two different weavings: one for implementation, the other one for validation based on model checking technology.

Abstract:

The e programming language enjoys widespread use in the microchip industry with applications to specification, modeling, testing and verification of hardware systems and their operating environments. Unique features of e include a combination of object oriented and constraint oriented mechanisms for the specification of data formats and interdependencies, interesting mechanisms of inheritance, and an efficient combination of interpreted and compiled code. Since the language is also extensible it serves as a living, industrial scale, implementation and application of the aspect oriented programming paradigm. This paper briefly describes the e language highlighting its novel features and their particular suitability to the task of hardware verification, and reports on our experience of aspect oriented programming in this intense commercial setting.

Abstract:

Aspect oriented programming promotes the separation of the different aspects of a system into their natural form. Synchronisation is an important aspect of concurrent object-oriented systems, but treating synchronisation as a single monolithic aspect leads to inflexibility and limited possibilities for reuse. We suggest that synchronisation has a number of different aspects, and introduce the 'synchronisation rings' model which allows the aspects of a synchronised object to be specified independently. By separating the different aspects of synchronisation we can provide flexible, generic implementations of common synchronisation constraints, which can be reused in many different contexts

Abstract:

Abstract:

Enterprise JavaBeans (EJB) provides special functionalities such as transaction, persistence, location transparency and security. These functionalities can be considered as aspects and EJB can be regarded as an aspect-oriented programming (AOP) environment. However, its architecture has no extensibility and flexibility to add or modify aspects, so it is not considered as a general AOP environment and hard to be applied to diverse domains. In this research, a new EJB server, named AES, is designed and implemented. An aspect exists independently of a container, and can be added and updated as needed. A container is changed into a generalized metaobject supporting more aspects in a flexible and extensible way. Also, an EJBObject is changed as a reference aspect supporting various network protocols. To prove flexibility and extensibility of AES, a testing application and user-defined aspects are developed. Finally, overhead for supporting AOP in EJB is measured.

Abstract:

This paper describes research in applications of aspect-oriented programming (AOP) as captured in the AspectJ language. In particular, it compares object-oriented and aspect-oriented designs and implementations of role models.

Sections 1, 2, and 3 provide background information on role models, object-oriented role model implementations, and aspect-oriented programming, respectively. New aspect-oriented designs for role models are explored in sections 4, 5, and 6.

The base reference for this exploration is the Role Object pattern. Although useful for role models, this pattern introduces some problems at the implementation level, namely object schizophrenia, significant interface maintenance, and no support for role composition. Our research has resulted in alternative aspect-oriented designs that alleviate some of these problems.

Section 7 discusses how an agent framework that implements role models has been partially reengineered with aspects. The reengineering addressed concerns that are orthogonal or cross cut both the core and the role behavior. The aspect oriented redesign significantly reduced code tangling, overall method and module count, and total lines of code. These results and other conclusions are presented in section 8.

Abstract:

The Advanced Teaching and Learning Academic Server (Atlas) is a software system that supports web-based learning. Students can register for courses, and can navigate through personalized views of course material. Atlas has been built according to Sun Microsystem's Java™ Servlet specification using Xerox PARC's aspect-oriented programming support called AspectJ™. Since aspect-oriented programming is still in its infancy, littleexperience with employing this paradigm is currently available. In this paper, we start filling this gap by describing the aspects we used in Atlas and by discussing the effect of aspects on ourobject-oriented development practices. We describe some rules and policies that we employed to achieve our goals of maintainability and modifiability, and introduce a straightforward notation to express the design of aspects. Although we faced some obstacles along the way, this combination of technology helped us build a fast, well-structured system in a reasonable amount of time.

Abstract:

We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered throughout the code, resulting in "tangled" code that is excessively difficult to de-elop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they cross-cut the system's basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and reuse of the aspect code. The discussion is rooted in systems we have built using aspect-oriented programming.

Abstract:

This position statement presents the concept of Aspect-Oriented Programming as a promising area of research in programming languages and software engineering.

Abstract:

The design and specification of an extensible class library presents a diffcult challenge: because extensibility comes from allowing the user to override parts of the implementation, more of the internal structure must be exposed to the user than in a typical procedure library. This raises issues in both how the library is designed and how its specification is written. Specification of the CLOS Metaobject Protocol required a combination of new and existing techniques to address these issues. We present those techniques, and discuss their relation to the underlying issues.

Abstract:

The view of abstraction on which software engineering is based does not support the reality of practice: it suggests that abstractions hide their implementation, whereas the evidence is that this is not generally possible. This discrepancy between our basic conceptual foundations and practice appears to be at the heart of a number of portability and complexity problems.

Work on metaobject protocols suggests a new view, in which abstractions do expose their implementations, but do so in a way that makes a principled division between the functionality they provide and the underlying implementation. By resolving the discrepancy with practice, this new view appears to lead to simpler programs. It also has the potential to resolve important outstanding problems surround reuse, software building blocks, and high-level programming languages.

Abstract:

Aspect-oriented programming (AOP) is a new programming technique that allows programmers to modularize crosscutting concerns (behavior that cuts across the typical divisions of responsibility, such as logging). AOP introduces aspects, which encapsulate behaviors that affect multiple classes into reusable modules. With the recent release of AspectJ by Xerox PARC, Java developers can now take advantage of the modularization AOP can provide. This article introduces AspectJ and illustrates the design benefits that result from its use. Share your thoughts on this article with the author and other readers in the discussion forum by clicking Discuss at the top or bottom of the article.

Abstract:

Aspect-Oriented Programming (AOP) is intended to ease situations that involve many kinds of code tangling. This paper reports on a study to investigate AOP's ability to ease tangling related to exception detection and handling. We took an existing framework written in Java, the JWAM framework, and partially reengineered its exception detection and handling aspects using AspectJ, an aspect-oriented programming extension to Java.

We found that AspectJ supported implementations that drastically reduced the portion of the code related to exception detection and handling. In one scenario, we were able to reduce that code by a factor of 4. We also found that, with respect to the original implementation in plain Java, AspectJ provided better support for different configurations of exceptional behaviors, more tolerance for changes in the specifications of exceptional behaviors, better support for incremental development, better reuse, automatic enforcement of contracts in applications that use the framework, and cleaner program texts. We also found some weaknesses of AspectJ that should be addressed in the future.

Abstract:

We present an object-oriented language framework for distributed programming called D. D uses the aspect oriented programming approach to allow the code for the basic functionality of a distributed application to be written without having to explicitly deal with distribution and synchronization. Separate code deals with those issues.

The D language framework consists of: (i) Jcore, an object-oriented language used to express the basic functionality and the activity of the system; (ii) Cool, a language used to express coordination of threads; and (iii) Ridl, a language used to express remote access strategies. A special tool called an Aspect Weaver™ takes the programs written in the different languages and combines them together to produce an executable program with the specified distributed behavior. D builds on existing object-oriented languages, and aggressively adheres to syntactic separation of distribution concerns. D program texts are less tangled and therefore simpler and more reusable than their equivalents written in Java.

Abstract:

Most software systems are inflexible. Reconfiguring a system's modules to add or to delete a feature requires substantial effort. This inflexibility increases the costs of building variants of a system, amongst other problems.

New languages and tools that are being developed to provide additional support for separating concerns show promise to help address this problem. However, applying these mechanisms requires determining how to enable a feature to be separated from the codebase. In this paper, we investigate this problem through an exploratory study conducted in the context of two existing systems: gnu.regexp and jFTPd. The study consisted of applying three different separation of concern mechanisms---Hyper/JTM, AspectJTM, and a lightweight, lexically-based approach---to separate features in the two packages. In this paper, we report on the study, providing contributions in two areas. First, we characterize the effect different mechanisms had on the structure of the codebase. Second, we characterize the restructuring process required to perform the separations. These characterizations can help researchers to elucidate how the mechanisms may be best used, tool developers to design support to aid the separation process, and early adopters to apply the techniques.

Abstract:

The artifacts constituting a software system often drift apart over time. We have developed the software reflexion model technique to help engineers perform various software engineering tasks by exploiting--rather than removing--the drift between design and implementation. More specifically, the technique helps an engineer compare artifacts by summarizing where one artifact (such as a design) is consistent with and inconsistent with another artifact (such as source). The technique can be applied to help a software engineer evolve a structural mental model of a system to the point that it is "good-enough" to be used for reasoning about a task at hand. The software reflexion model technique has been applied to support a variety of tasks, including design conformance, change assessment, and an experimental reengineering of the million-lines-of-code Microsoft Excel product. In this paper, we provide a formal characterization of the reflexion model technique, discuss practical aspects of the approach, relate experiences of applying the approach and tools, and place the technique into the context of related work.

Abstract:

Determining whether a new software development technique is useful and usable is a challenging task. Various flavors of empirical study may be used to help with this task, including surveys, case studies, and experiments. Little guidance is available within the software engineering community to help choose among these alternatives when assessing a new and evolving software development technique within some cost bounds. We faced this challenge when assessing a new programming technique called aspect-oriented programming. To assess the technique, we chose to apply both a case study approach and a series of four experiments because we wanted to understand and characterize the kinds of information that each approach might provide. In this paper, we describe and critique the evaluation methods we employed, and discuss the lessons we have learned. These lessons are applicable to other researchers attempting to assess new programming techniques that are in an early stage of development.

Abstract:

The artifacts comprising a software system often "drift" apart over time. Design documents and source code are a good example. The software reflexion model technique was developed to help engineers exploit—rather than remove—this drift to help them perform various software engineering tasks. More specifically, the technique helps an engineer compare artifacts by summarizing where one artifact (such as a design) is consistent with and inconsistent with another artifact (such as source). The use of the technique to support a variety of tasks—including the successful use of the technique to support an experimental reengineering of a system comprising a million lines-of-code —— identified a number of shortcomings. In this paper, we present two categories of extensions to the technique. The first category concerns the typing of software reflexion models to allow different kinds of interactions to be distinguished. The second category concerns techniques to ease the investigation of reflexion models. These extensions are aimed at making the engineer more effective in performing various tasks by improving the management and understanding of the inconsistencies the drift between artifacts.

Abstract:

Reengineering large and complex software systems is often very costly. Reflexion models let software engineers begin with a structural high-level model that they can selectively refine to rapidly gain task-specific knowledge about the source code. The authors describe how a Microsoft engineer used this technique in an experimental reengineering of Excel.

Abstract:

Software engineers often use high-level models (for in-stance, box and arrow sketches) to reason and communicate about an existing software system. One problem with high-level models is that they are almost always inaccurate with respect to the system’s source code. We have developed an approach that helps an engineer use a high-level model of the structure of an existing software system as a lens through which to see a model of that system’s source code. In particular, an engineer defines a high-level model and specifies how the model maps to the source. A tool then computes a software reflexion model that shows where the engineer’s high-level model agrees with and where it differs from a model of the source.

The paper provides a formal characterization of reflexion models, discusses practical aspects of the approach, and relates experiences of applying the approach and tools to a number of different systems. The illustrative example used in the paper describes the application of reflexion models to NetBSD, an implementation of Unix comprised of 250,000 lines of C code. In only a few hours, an engineer computed several reflexion models that provided him with a useful, global overview of the structure of the NetBSD virtual memory subsystem. The approach has also been applied to aid in the understanding and experimental reengineering of the Microsoft Excel spreadsheet product.

Abstract:

It is difficult to design software to meet its goal on quality attributes, because there are many factors related to quality attributes, and the relationships between these factors and quality attributes are quite complicated. However, we do not have a systematic way to design software considering quality attributes. Consequently, we have many troubles in the attainment of required quality attributes in actual software development. We are examining a design method, aspect-oriented design (AOD) based on the idea of "aspect-oriented-ness" proposed in the programming community as aspect-oriented programming. In AOD, aspects corresponding to quality attributes are considered separately, software architectures suitable for each aspect are designed independently and woven into the final architecture. In this paper, we introduce our approach and demonstrate the effectiveness of the approach using an example.

Abstract:

Separation of concerns is at the core of software engineering, and has been for decades. This has led to the invention of many interesting, and effective, modularization approaches. Yet many of the problems it is supposed to alleviate are still with us, including dangerous and expensive invasive change, and obstacles to reuse and component integration. A key reason is that one needs different decompositions according to different concerns at different times, but most languages and modularization approaches support only one "dominant" kind of modularization (e.g., by class in object-oriented languages). Once a system has been decomposed, extensive refactoring and reengineering are needed to remodularize it.

Multi-dimensional separation of concerns allows simultaneous separation according to multiple, arbitrary kinds (dimensions) of concerns, with on-demand remodularization. Concerns can overlap and interact. This paper discusses multi-dimensional separation of concerns in general, our particular approach to providing it, called hyperspaces, and our support for hyperspaces in Java™, called Hyper/J™.

Abstract:

Despite the well-known benefits of separation of concerns, and despite the presence of mechanisms to achieve separation of concerns in all modern software formalisms, software artifacts continue to exhibit properties associated with poor separation of concerns. Comprehensibility degrades over time; impact of change is high; reuse and traceability are limited.

We have hypothesized that these limitations are largely caused by the tyranny of the dominant decomposition: existing languages and formalisms generally provide only one, dominant dimension along which to separate concerns (e.g., by object or by function). Achieving many software engineering goals depends on the ability to separate all concerns of importance. We therefore introduced the notion of multi-dimensional separation of concerns: simultaneous separation according to multiple, potentially overlapping concerns.

This paper explores the structure of the space of concerns, to which we referashyperspace, partially formalizing our earlier model. We discuss how the model facilitates the identification and encapsulation of those portions of a system pertaining to a given concern, whether or not that concern is dominant, and how it helps identify, introduce, change and remove concerns during evolution. We also show how this approach promotes two crucial aspects of evolvability: traceability and limited impact of change.

Abstract:

This paper presents A-TOS, an aspect-oriented reflective middleware for distributed programming. It provides a very special kind of entities called aspect components that implement global and transversal properties of (distributed) applications like security, fault tolerance, transactions, and so on. Since the application code does not directly refer to the aspect components, A-TOS achieves clean and powerful separation of concerns based on a wrapping composition model. Its adaptability and aspect distribution capabilities make it well suited to aspect-oriented programming in a distributed environment.

Abstract:

Nowadays, the interest in collaborative environments has increased considerably, probably due to current technological advances, especially in Internet computing. However, the lack of a standard reference architecture for the development of these systems makes the development of useful collaborative environments, that can be used in real work, difficult. Our goal is the development of a framework for the construction of collaborative virtual environments. We consider aspect-oriented programming to be very suitable for both the design and implementation of these systems. Thus, we present an aspect-oriented approach for the development of collaborative virtual environments.

Abstract:

The Common Object Request Broker Architecture (CORBA) is the most successful representative of an object-based distributed computing architecture. Although CORBA simplifies the implementation of complex, distributed systems significantly, the support of techniques for reliable, fault-tolerant software, such as group communication protocols or replication is very limited in the state-of-the-art CORBA or even fault-tolerant CORBA. Any fault tolerance extension for CORBA components needs to trade off data abstraction and encapsulation against implementation specific knowledge about a component's internal timing behavior, resource usage and interaction patterns. These non-functional aspects of a component are crucial for the predictable behavior of fault-tolerance mechanisms. However, in contrast to CORBA's interface definition language (IDL), which describes a component's functional interface, there is no general means to describe a component's non-functional properties. We present a genetic framework, which makes existing CORBA components fault tolerant. In adherence with a given, programmer-specified fault model, our framework uses design-time and configuration-time information for automatic distributed replicated instantiation of components. Furthermore, we propose usage of aspect-oriented programming (AOP) techniques to describe fault-tolerance as a non-functional component property. We describe the automatic generation of replicated CORBA services based on aspect information and demonstrate service configuration through a graphical user-interface.

Abstract:

The collaboration-based approach is a powerful means to develop modularized systems by stepwise refinement. In this paper, we introduce a new approach to realize a collaboration-based design. Our approach is based on the well-known observation that the knowledge about inter-object collaborations cannot be localized within objects but crosscuts many objects. Such crosscutting concerns are effectively addressed by applying the separation of concern principle. We have, therefore, employed Aspect-Oriented Programming (AOP) to build collaboration-based designs. In the paper we illustrate and discuss our aspect-oriented approach both for the horizontal (i.e. the collaborations) and vertical (i.e. the refinements) dimensions. Although the example implementations are based on AspectJ0.4beta7 from Xerox PARC, the approach is generic enough to be implemented using other AOP techniques.

Abstract:

Many maintenance tasks address concerns, or features, that are not well modularized in the source code comprising a system. Existing approaches available to help software developers locate and manage scattered concerns use a representation based on lines of source code, complicating the analysis of the concerns. In this paper, we introduce the Concern Graphs representation that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph has been designed to allow an obvious and inexpensive mapping back to the corresponding source code. To investigate the practical tradeoffs related to this approach, we have built the Feature Exploration and Analysis tool (FEAT) that allows a developer to manipulate a concern representation extracted from a Java system, and to analyze the relationships of that concern to the code base. We have used this tool to find and describe concerns related to software change tasks. We have performed case studies to evaluate the feasibility, usability, and scalability of the approach. Our results indicate that Concern Graphs can be used to document a concern for change, that developers unfamiliar with Concern Graphs can use them effectively, and that the underlying technology scales to industrial-sized programs.

Abstract:

An emerging tapestry of computations will soon integrate systems around the globe. It will evolve without central control. Its complexity will be vast. We need new ideas, tools and methods to help map, understand and manage this tapestry. We contribute a light-weight architectural aspect that designers can use without compromising their own architectural preferences. Widespread use could help. The idea is for objects to provide web-based interfaces to object-specific meta-data, state, and monitoring and control services. We discuss applications, implementation, scalability, performance, tradeoffs, and related work.

Abstract:

The concept of information hiding modularity is a cornerstone of modern software design thought, but its formulation remains casual and its emphasis on changeability is imperfectly related to the goal of creating value in a given context. We need better models of the structure and value of information hiding, for both their explanatory power and prescriptive utility. We evaluate the potential of a new theory—developed to account for the influence of modularity on the evolution of the computer industry—to inform software design. The theory uses design structure matrices to model designs and real options techniques to value them. To test the potential utility of the theory for software we represent a model software system in its terms—Parnas's KWIC—and evaluate the results. We contribute an extension to design structure matrices and show that the options results are consistent with Parnas's conclusions. Our results suggest that such a theory does have potential to help inform software design.

Abstract:

Many software engineering principles and concepts that are critical to reasoning about problems in software design (of which software architecture is an important special case) remain ad hoc, idiosyncratic and poorly integrated. I argue that this is due to our lack of a clean theory about how to make software design decisions. In this paper I propose that we should view software design as a process of deciding how to make irreversible capital investment in software assets of uncertain value, and that financial options theory provides a firm, unifying, simplifying and well developed basis for such decision-making. To support this view, I interpret software architecture and other related concepts in options theoretic terms.

Abstract:

Prototype theory is a cognitive theory of categorization that describes many aspects of MDSOC better than the classical theory of hierarchical categories. Prototype theory implies that composition is a more natural means of specifying components than is inheritance. Prototypes are useful in organizing information and workflows in component composition systems.

Abstract:

Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decomposition and composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along single dimensions of composition and decomposition. These characteristics lead to a number of well-known and difficult problems. This paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving well-engineered, evolvable, flexible software artifacts and traceability across artifacts.

Abstract:

The gulf between the user and the developer perspectives leads to diffculties in producing successful software systems. Users are focused on the problem domain, where the system's features are the primary concern. Developers are focused on the solution domain, where the system's life-cycle artifacts are key. Presently, there is little understanding of how to narrow this gulf.

This paper argues for establishing an organizing viewpoint that we term feature engineering. Feature engineering promotes features as first-class objects throughout the software life cycle and across the problem and solution domains. The goal of the paper is not to propose a specific new technique or technology. Rather, it aims at laying out some basic concepts and terminology that can be used as a foundation for developing a sound and complete framework for feature engineering. The paper discusses the impact that features have on different phases of the life cycle, provides some ideas on how these phases can be improved by fully exploiting the concept of feature, and suggests topics for a research agenda in feature engineering.

Abstract:

Aspect-oriented programming (AOP) is a novel topic in the software engineering and languages communities. AOP appears to have the potential to significantly improve the reliability of programs, particularly by modularizing error-handling policies and allowing for easier maintenance and better reuse. In this article, we introduce AspectJ, the first AOP language, and demonstrate how you can use it to construct more reliable software.

Abstract:

The principle of separation of concerns has long been used by software engineers to manage the complexity of softwaresystem development. Programming languages help softwareengineers explicitly maintain the separation of some concerns in code. As another step towards increasing the scopeofconcerns that can be captured cleanly within the code, Kiczales and colleagues have introduced aspect-oriented programming. In aspect-oriented programming, explicit language support is provided to help modularize design decisions that cross-cut a functionally-decomposed program. Aspect-oriented programming is intended to make it easier to reason about, develop, and maintain certain kinds of application code. To investigate these claims, we conducted two exploratory experiments that considered the impact of aspect-oriented programming, as found in AspectJ version 0.1, on two common programming activities: debugging and change. Our experimental results provide insights into the usefulness and usability of aspect-oriented programming. Our results also raise questions about the characteristics of the interface between aspects and functionally- decomposed core code that are necessary to accrue programming benefits. Most notably, the separation provided by aspect-oriented programming seems most helpful when the interface is narrow (i.e., the separation is more complete); partial separation does not necessarily provide partial benefit.

Abstract:

Separating concerns helps developers to get a conceptual grip on large software systems, to reuse parts of the system, and to evolve it. We are interested in separating three generic concerns that are part of any software system: computation, coordination, and configuration. For that purpose we propose a three-layer architecture using two new modeling primitives: coordination contracts to define interactions and coordination contexts to govern system reconfiguration. Each layer is superposed in a transparent way on the layer below, which facilitates the modification of coordination and configuration policies to make the system evolve.