GLoo: A Framework for Modeling and Reasoning About Component-Oriented Language Abstractions

Abstract

Abstract.The most important contribution to the success or failure of a software project comes from the choice of the programming languages being used and their support in the target environment. The choice of a suitable implementation language is not a guarantor for success, but an unsuitable language may result in a long, error-prone, and costly implementation, often resulting in an unstable product. In this paper, we present GLoo, a framework for modeling and reasoning about open-ended language mechanisms for object-and component-oriented software development. At the heart of GLoo is a small dynamic composition language that provides abstractions to (i) define and/or import reusable software components, (ii) introduce new compositional language abstractions, and (iii) build executable and reusable component-oriented specifications. To demonstrate its flexibility and extensibility, we then present an encoding of the traits concept as an example of how to add support for a new and readily available language abstraction to the GLoo framework.

Applications = Components + GLoo

“…Moreover, due to the ability to define both syntactic and semantics extensions, GLoo is not limited to one specific model for class extensions. New models can be introduced to the GLoo system by defining a corresponding domain sublanguage that offers the required programming abstractions, as if they were native to the GLoo language (e.g., Language-of-Traits [16]). …”

“…In earlier work [16], we have already demonstrated, how GLoo can be used to specify readily available language abstractions that serve as syntactic and semantic extensions to the GLoo framework. In this work, we present an approach for the integration of existing software artifacts.…”

“…However, while our understanding of this technology has grown significantly over the last decade resulting, for example, in the definition of industrial-strength component models like Java Enterprise Beans [19] and the .NET framework [23], most existing component frameworks offer only limited support for the definition of higher-level, scalable, and domain-specific compositional mechanisms that reflect the characteristics and constraints of the components being composed [1,27]. The mismatch between the mechanisms offered by present-day component-oriented techniques and the methodology they are supposed to support is due to an unsuitable use of general-purpose programming languages, which are not tailored to software composition [16,20,21]. Furthermore, Aßmann [5] argues that a comprehensive component-oriented software development approach not only needs to provide abstractions to represent different component models and composition techniques, but it must also provide a systematic method for constructing large software systems.…”

“…Furthermore, Aßmann [5] argues that a comprehensive component-oriented software development approach not only needs to provide abstractions to represent different component models and composition techniques, but it must also provide a systematic method for constructing large software systems. In particular, a specially-designed composition language is required [5,16,20,21] that (i) allows for an efficient integration of heterogeneous software artifacts, (ii) provides support for a problem-oriented software development approach, and (iii) enables software engineers to incrementally construct component-oriented domain abstractions on demand.…”

Component Coordination in GLoo

“…There are two unique aspects to this process: components that encapsulate well-defined functionality and interface code that governs the interaction between these components [7]. The behavior of components can naturally be captured within the framework provided by mainstream, object-oriented programming languages [10]. But what are the effective ways to express interface code?…”