Section 11.1. INTRODUCTION


11.1. INTRODUCTION

It is well accepted that complex software systems should be developed as sets of manageable pieces, where each piece ideally addresses a single concern. These pieces are then composed together to achieve the desired behavior of the application. However, carving a complex system up into suitable pieces may be far from trivial since concerns typically overlap and interfere. Tarr and coworkers [32] argue that we cannot achieve this separation in a single-paradigm language due to the single dominant dimension of separation supported by the language. For instance, while object-oriented programming separates everything into objects, concerns like persistence and synchronization are not naturally represented as objects, so they get tangled into several objects in the application. The fact that each concern cannot be factored out into a single abstraction leads to components incorporating several varying aspects. This hinders their reusability in other contexts.

AOP and related approaches offer various techniques and mechanisms that make it easier to factor out concerns into composable software artifacts [13]. Many of these approaches attempt to augment a host language with features or tools that compensate for the shortcomings of the dominant paradigm.

We propose, instead, to ask a different question, namely: Is there a simple programming model that can serve as a good basis for defining arbitrary kinds of composable abstractions?

Such a model should be capable of expressing not only conventional programming abstractions, such as procedures, objects, classes, and modules, but also higher-order abstractions, such as (for example) mixins, metaclasses, wrappers, and coordination abstractions.

As a typical example, consider a generic readers/writers synchronization policy. Although it is reasonably straightforward in most programming languages to implement such a policy for a given data abstraction, it can be difficult to impossible to implement a generic policy as a composable software artifact that can be applied in a straightforward way to any existing data abstraction.

Furthermore, we seek to raise the level of abstraction so that instead of "wiring" software components together at a low level, we are able to plug them together using high-level connectors. A compositional style (also referred to in the literature as an "architectural style" [28]) specifies a set of component interfaces, connectors to plug together components, and rules governing valid compositions of components. In short, we seek to make the way in which software systems are composed explicit and manipulable so they can be easily understood and adapted.

We propose forms as a suitable foundation for developing composable software abstractions. Forms unify extensible records, services, and first-class namespaces. On one hand, they offer a familiar mechanism for modeling various kinds of data abstractions as records. On the other hand, they offer a fine degree of control in manipulating, extending, and composing the namespaces available to running applications. A service is just an abstraction over a form, that is, a function that takes a form as an argument and returns a form. Since a service is also a form, forms offer a suitable basis for modeling high-order software abstractions. Forms can thus be conveniently used to model composable namespaces that both provide and require sets of services.

Piccola [4, 23] is an experimental composition language based on forms. In addition to forms and services, Piccola provides agents (concurrent processes) and channels (unbounded buffers providing non-blocking send and blocking receive services) as core mechanisms. With these basic mechanisms, Piccola can be used to easily express the kind of composable abstractions we are targeting.

In Section 11.2, we provide a brief overview of Piccola and its design rationale. In particular, we show how forms, agents, and channels support a layered approach to defining compositional styles. In Section 11.3, we present a non-trivial example of composing mixin layers with forms. In Section 11.4, we briefly survey some of the ways in which forms support software composition. We conclude in Section 11.5 with some remarks concerning the current status of Piccola and ongoing work.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net