Composing Software from Multiple Concerns: A Model and Composition Anomalies

Constructing software from components is considered to be a key requirement for managing the complexity of software. Separation of concerns makes only sense if the realizations of these concerns can be composed together effectively into a working program. Various publications have shown that composability of software is far from trivial and fails when components express complex behavior such as constraints, synchronization and history-sensitiveness. We believe that to address the composability problems, we need to understand and define the situations where composition fails. To this aim, in this paper we (a) introduce a general model of multi-dimensional concern composition, and (b) define so-called composition anomalies

Aspect-Oriented Programming using Composition-Filters

Software engineers may experience problems in modeling certain aspects while applying object-oriented techniques [4, 10, 11]. Composition-Filters are capable of expressing various different kinds of aspects in a uniform manner. These aspects are, for example, inheritance and delegation [1] and atomic delegation [2], multiple views, dynamic inheritance and queries on objects [3], coordinated behavior and inter-object constraints [5], real-time [6] and composing real-time and synchronization together [9], synchronization [8] and distributed synchronization [7], and client-server architectures [10]

Deriving Design Aspects from Conceptual Models

Two fundamental issues in aspect orientation are the identification and the composition of aspects. We argue that aspects must be identified at the requirement and the domain analysis phases. We also propose a mechanism for gradually composing aspects throughout the software development process. We illustrate our ideas for the design of a transaction framework

An Analysis of Composability and Composition Anomalies

The separation of concerns principle aims at decomposing a given design problem into concerns that are mapped to multiple independent software modules. The application of this principle eases the composition of the concerns and as such supports composability. Unfortunately, a clean separation (and composition of concerns) at the design level does not always imply the composability of the concerns at the implementation level. The composability might be reduced due to limitations of the implementation abstractions and composition mechanisms. The paper introduces the notion of composition anomaly to describe a general set of unexpected composition problems that arise when mapping design concerns to implementation concerns. To distinguish composition anomalies from other composition problems the requirements for composability at the design level is provided. The ideas are illustrated for a distributed newsgroup system

Simple and Effective Type Check Removal through Lazy Basic Block Versioning

Dynamically typed programming languages such as JavaScript and Python defer type checking to run time. In order to maximize performance, dynamic language VM implementations must attempt to eliminate redundant dynamic type checks. However, type inference analyses are often costly and involve tradeoffs between compilation time and resulting precision. This has lead to the creation of increasingly complex multi-tiered VM architectures. This paper introduces lazy basic block versioning, a simple JIT compilation technique which effectively removes redundant type checks from critical code paths. This novel approach lazily generates type-specialized versions of basic blocks on-the-fly while propagating context-dependent type information. This does not require the use of costly program analyses, is not restricted by the precision limitations of traditional type analyses and avoids the implementation complexity of speculative optimization techniques. We have implemented intraprocedural lazy basic block versioning in a JavaScript JIT compiler. This approach is compared with a classical flow-based type analysis. Lazy basic block versioning performs as well or better on all benchmarks. On average, 71% of type tests are eliminated, yielding speedups of up to 50%. We also show that our implementation generates more efficient machine code than TraceMonkey, a tracing JIT compiler for JavaScript, on several benchmarks. The combination of implementation simplicity, low algorithmic complexity and good run time performance makes basic block versioning attractive for baseline JIT compilers

Aspect-oriented interaction in multi-organisational web-based systems

Separation of concerns has been presented as a promising tool to tackle the design of complex systems in which cross-cutting properties that do not fit into the scope of a class must be satisfied. Unfortunately, current proposals assume that objects interact by means of object-oriented method calls, which implies that they embed interactions with others into their functional code. This makes them dependent on this interaction model, and makes it difficult to reuse them in a context in which another interaction model is more suited, e.g., tuple spaces, multiparty meetings, ports, and so forth. In this paper, we show that functionality can be described separately from the interaction model used, which helps enhance reusability of functional code and coordination patterns. Our proposal is innovative in that it is the first that achieves a clear separation between functionality and interaction in an aspect-oriented manner. In order to show that it is feasible, we adapted the multiparty interaction model to the context of multiorganisational web-based systems and developed a class framework to build business objects whose performance rates comparably to handmade implementations; the development time, however, decreases significantly.Comisión Interministerial de Ciencia y Tecnología TIC2000-1106-C02-0

Towards a Java Subtyping Operad

The subtyping relation in Java exhibits self-similarity. The self-similarity in Java subtyping is interesting and intricate due to the existence of wildcard types and, accordingly, the existence of three subtyping rules for generic types: covariant subtyping, contravariant subtyping and invariant subtyping. Supporting bounded type variables also adds to the complexity of the subtyping relation in Java and in other generic nominally-typed OO languages such as C# and Scala. In this paper we explore defining an operad to model the construction of the subtyping relation in Java and in similar generic nominally-typed OO programming languages. Operads, from category theory, are frequently used to model self-similar phenomena. The Java subtyping operad, we hope, will shed more light on understanding the type systems of generic nominally-typed OO languages.Comment: 13 page

Second ECOOP Workshop on Precise Behavioral Semantics (with an Emphasis on OO Business Specifications)

Business specifications are essential to describe and understand businesses (and, in particular, business rules) independently of any computing systems used for their possible automation. They have to express this understanding in a clear, precise, and explicit way, in order to act as a common ground between business domain experts and software developers. They also provide the basis for reuse of concepts and constructs ("patterns") common to all - from finance to telecommunications -, or a large number of, businesses, and in doing so save intellectual effort, time and money. Moreover, these patterns substantially ease the elicitation and validation of business specifications during walkthroughs with business customers, and support separation of concerns using viewpoints.Comment: 21 pages, 0 figure