Supporting both intraclass and interclass crosscutting through model extension. It has been demonstrated that certain design concerns, such as access control, synchronization, and object interactions cannot be expressed in current OO languages as a separate software module [4, 7]. These so-called crosscutting concerns generally result in implementations scattered over multiple operations. If a crosscutting concern cannot be treated as a single module, its adaptability and reusability are likely to be reduced. A num-ber of programming techniques have been proposed to express cross-cutting concerns, for example, adaptive programming [9], AspectJ [8], Hyperspaces [10], and Composition Filters [1]. Here, we present the Composition Filters (CF) model and illustrate how it addresses evolving crosscutting concerns.

Abstract not found

The design of components for open systems has led to the study of new systems and their properties, like the independently extensible systems. Most of these systems try to facilitate the design of components by incorporating new features, services and utilities that solve the basic problems of open systems: heterogeneity, partial knowledge of the components, and dynamic changes in the system's configuration. However, our approach is not focused on the system, but on the components themselves. The present paper defines the properties that components of those systems should have, and introduces a components' design methodology based on the modular addition of properties. 1 Introduction There is now an increasing interest in the study of Open Systems, and in particular in the Independently Extensible systems [21] as the base for a component market. In this market users are able to buy or rent reusable components o# the shelf and compose them to build their applications. Extensibl...

liver the mail to its destination. An important requirement here is that only the "system objects" are allowed to invoke the approve and deliver operations. In addition to the previously mentioned concerns, a mail object has therefore an additional concern: "multiple-views". Each mail object has a user-view and a system-view that restrict the operations of the mail object with respect to the clients of the mail object. To implement the mail object, each concern must be mapped to an OO concept. For example, views can be implemented as operations. The operation approve, for instance, can be executed if the operation checkSystemView returns True. This implementation, however, blurs the separation of the multiple-views concern because the views are then realized within the operations of objects. The problem appears if we want to extend/modify the mail object. For example, we may further partition the user view as sender and receiver views. We may extend the sender and receiver views to gro

Aspect oriented programming (AOP) is a recent programming paradigm where programmers express and reason separately about the different concerns that affect the basic object behavior. Although it has been successfully applied to deal with concerns such as synchronization and real-time in the area of object-oriented concurrent and real-time programming, the coordination aspect presents more difficulties than may appear at first glance because multi-object coordination involves synchronized interaction among several active objects. Consequently, the coordination algorithm is spread among sets of objects making them more difficult not only to extend and reuse but also to reason about the coordination algorithm by itself. In this position paper we propose several question about how AOP can deal with the coordination aspect. We present two modeling problems related with this aspect to be discussed during this workshop and we provide a solution in order to cope with this issue. Our s...

This paper presents a new approach for modular design of highly-entangled software components by statechart diagrams. We structure the components into features, which represent reusable, self-contained services. These are modeled individually by statechart diagrams. For composition of components from features, we need to consider the interactions between the features. These feature interactions, which are well known in the telecommunications area, typically describe special cases or cooperations which only occur when features are combined.

Abstract not found

It is generally acknowledged that separation of concerns is a key requirement for effective software engineering: it helps in managing the complexity of software and supports the maintainability of a software system. Separation of concerns makes only sense if the realizations in software of these concerns can be composed together effectively into a working program. The ability to compose systems from independently developed components that can be adapted and extended easily is a long-standing goal in the software engineering discipline. However, both research and practice have shown that composability of software is far from trivial and fails repeatedly. Typically this occurs when components exhibit complex behavior, in particular when multiple concerns are involved in a single component. We believe that, to address the composability problems, we need a better understanding of the requirements involved in successful composition, and in addition define the situations where composition fails. To this aim, in this paper we (a) introduce a general model of composing systems from multiple concerns, (b) introduce a number of requirements for design-level composability and (c) define a category of composability problems that are inherent for given composition models, which we term as composition anomalies.

A considerable number of language mechanisms have been proposed during the last several years, to specify and implement concurrent object-oriented programs. The major concern of these proposals is to design an expressive language that provides extensible concurrent processing and synchronization features. Almost all these efforts, however, have focused on the multiple-clientsingle-server model where each server determines its synchronization semantics without cooperating with other objects. We believe that object-oriented concurrent languages must not only support a single-server model, but cooperatively synchronizing servers as well. We refer to this as multi-server synchronization. This paper first classifies multi-server synchronization in five categories. The intention here is to define a framework for evaluating current approaches and identifying the requirements for designing new languages. In addition, this paper presents a composable multi-server synchronization technique, adopting the concept of composition-filters. 1.

Large and complex real-time systems can benefit significantly from a component-based development approach where new systems are constructed by composing reusable, documented and previously tested concurrent objects. However, reusing objects which execute under real-time constraints is problematic because application specific time and synchronization constraints are often embedded in the internals of these objects. The tight coupling of functionality and real-time constraints makes objects interdependent, and as a result difficult to reuse in another system.