Catálogo de publicaciones - libros

This paper presents planning-based service composition algorithms that dynamically interact with a potentially large-scale directory of service advertisements in order to retrieve matching service advertisements on demand. We start with a simple algorithm for untyped services, similar to a STRIPS planner. This algorithm is refined in two steps, first to exploit type information, and second to support partial type matches. An evaluation confirms that the algorithms scale well with increasing size of the directory and that the support for partial type matches is essential to achieve a low failure rate.

Although dynamic programming environments are in widespread use, only basic runtime composition mechanisms are covered by today’s modeling languages. Thus, it is common in real-world development projects that dynamic compositions are not modeled formally and are consequently hard to use, for example together with the model-driven paradigm where formal models are essential to generate source code. In this paper, we propose an approach based on model transformations between the valid structural and behavioral runtime states that a system can have. We use UML 2.0 class and activity diagrams for specifying the structural and behavioral model states and provide a UML 2.0 meta-model extension for describing the valid model transformations between corresponding model states.

Composition is the process of creating new artifacts from a set of input artifacts by combining the content of the input artifacts according to some given specifications. Composition engines are a distinct kind of software component. Like compilers, parsers, and UI-generators, they have their own domain of discourse and base of concepts, their own structure for expressing desired results, their own internal solution structure, and their own set of research problems. Composition applies not only to artifacts representing executable code, but to any sort of artifacts, from build or configuration controls to documentation or UI. While software composition is of interest to an audience wider than that of developers applying aspect-oriented software development (AOSD) approaches, AOSD’s composition of separate concerns or aspects presents more complex requirements than does object-composition. This paper describes a base of concepts suitable for expressing composition and shows how a general composition engine realizing these concepts can be used to effect the composition needs of several existing AOSD approaches.

Software systems with constrained and dynamic environments need to adapt to local and diverse computing environments by providing highly customized services at run-time. In order to address such dynamic changes effectively, composition models addressing complicated composition issues and supporting advanced composition features are required. In order to analyze and identify the required features of composition models supporting dynamic changes, we propose the dimensions of composition models by survey and analysis of existing work. Based on the dimensions, it is possible to provide a road map to improve capability of a composition model for a specific domain such as a dynamic mobile agent domain.

Context-aware applications behave differently depending on the context in which they are running. Since context-specific behavior tends to crosscut base programs, it can advantageously be implemented as aspects. This leads to the notion of aspects whose behavior depends on context. This paper analyzes the issue of appropriate support from the aspect language to both restrict the scope of aspects according to the context and allow aspect definitions to access information associated to the context. We propose an open framework for context-aware aspects that allows for the definition of first-class contexts and supports the definition of context awareness constructs for aspects, including the ability to refer to past contexts, and to provide domain- and application-specific constructs.

Design patterns offer solutions to common engineering problems in programs [1]. In particular, they shape the evolution of program elements. However, their implementations tend to vanish in the code: thus it is hard to spot them and to understand their impact. The problem becomes even more difficult with a “high density of pattern”: then the program becomes easy to evolve in the direction allowed by patterns but hard to change [2]. Aspect languages offer new means to modularize elements. Implementations of object-oriented design patterns with AspectJ have been proposed [3]. We aim at testing the scalability of such solutions in the JHotDraw framework. We first explore the impact of density on pattern implementation. We show how AspectJ helps to reduce this impact. This unveils the principles of aspects and AspectJ to control pattern density.

Aspect-Oriented Programming (AOP) and Component- Based Software Engineering (CBSE) offer solutions to improve the separation of concerns and to enhance a program structure. If the integration of AOP into CBSE has already been proposed, none of these solutions focus on the application of CBSE principles to AOP. In this paper we propose a twofold integration of AOP and CBSE. We introduce a general model for components and aspects, named Fractal Aspect Component (FAC). FAC decomposes a software system into regular components and aspect components (ACs), where an AC is a regular component that embodies a crosscutting concern. We reify the aspect domain of an AC and the relationship between an AC and a component, called an aspect binding, as first-class runtime entities. This clarifies the architecture of a system where components and aspects coexist. The system can evolve from the design to the execution by adding or removing components, aspects or bindings.

This paper presents FROGi, a proposal to support continuous deployment activities inside Fractal, a hierarchical component model. FROGi is implemented on top of the OSGi platform. Motivation for this work is twofold. On one hand FROGi provides an extensible component model to OSGi developers and eases bundle providing. FROGi-based bundles are still compatible with “legacy” OSGi bundles that offer third party services. On the other hand, FROGi benefits from the deployment infrastructure provided by OSGi which simplifies conditioning and packaging of Fractal components. With FROGi, it is possible to automate the assembly of a Fractal component application. Partial or complete deployment is also supported as well as performing continuous deployment and update activities.

The man-machine interface of a small electronic device like a wristwatch is a crucial component, as more and more functions have to be controlled using a small set of buttons. We propose to use Argos, an automaton-based language for reactive systems, and Larissa, its aspect-oriented extension, to show that several interfaces can be obtained from the same set of basic components, assembled in various ways. This is the basis of a quite general component-based development method for man-machine interfaces.

Classboxes are a new module system for object-oriented languages defining a packaging and scoping mechanism for controlling the visibility of isolated extensions to portions of class-based systems. Unlike object-oriented specialization, the class extension mechanisms supported by classboxes preserve the identity of extended classes and, therefore, all clients of extended classes can benefit from the applied extensions. In this paper, we present a language design and a corresponding implementation strategy for classboxes in C#. A particular challenge in incorporating classboxes into C# is to preserve the identity of extended classes as the .NET framework represents classes as metadata type declarations and access to classes by static links into metadata of the host assembly. However, the local refinement of an imported class results in a new metadata type declaration. In order to guarantee the identity of extended classes, new metadata type declarations have to be incorporated into the original metadata of imported classes. But this “re-wiring” has to occur in a manner that is consistent with the Common Language Infrastructure (CLI).