Done well, separation of concerns can provide many soft-ware engineering benefits, including reduced complexity, im-proved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both require-ments on the system and on the kind(s) of decompositionand composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along sdngle dimen-sions of composition and decomposition. These characteris-tics lead to a number of well-known and difficult problems. This paper describes a new paradigm for modeling and im-plementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composi-tion and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving well-engineered, evolvable, flexible software artifacts and trace-ability across artifacts.

While the availability of platform-independent code on the Internet is increasing, third-party code rarely exhibits all of the features desired by end users. Unfortunately, developers cannot foresee and provide for all possible extensions. In this paper, we describe load-time transformation, a stage in the program development lifecycle in which classes are modified at load time according to usersupplied directives. This allows the users to select transformations that add new features, customize the implementation of existing features, and apply the changes to all classes in the environment. The Java Object Instrumentation Environment (JOIE) is a toolkit for constructing transformations of Java classes. An enhanced class loader calls user-supplied transformers that specify rules for transforming target classes. We describe some applications of load-time transformation, including extending the Java environment, integrating classes with specialized environments, and adding functionality...

Layered architecture in operating system code is often compromised by execution path-specific customizations such as prefetching, page replacement and scheduling strategies. Pathspecific customizations are difficult to modularize in a layered architecture because they involve dynamic context passing and layer violations. Effectively they are vertically integrated slices through the layers. An initial experiment using an aspect-oriented programming language to refactor prefetching in the FreeBSD operating system kernel shows significant benefits, including easy (un)pluggability of prefetching modes, independent development of prefetching modes, and overall improved comprehensibility. Keywords aspect-oriented programming, software modularity, operating system design 1.

this document.

Object oriented frameworks impose additional burdens on programmers that libraries did not, such as requiring the programmer to understand the method callback sequence, respecting behavior constraints within these methods, and devising solutions within a constrained solution space. To overcome these burdens, we express the repeated patterns of engagement with the framework as a design fragment. We analyzed the 20 demo applets provided by Sun and created a representative catalog of design fragments of conventional best practice. By evaluating 36 applets pulled from the internet we show that these design fragments are common, many applets copied the structure of the Sun demos, and that creation of a catalog of design fragments is practical. Design fragments give programmers immediate benefit through tool-based conformance assurance and long-term benefit through expression of design intent.

In this paper we describe a black-box approach to software system evolution where viewpoints are used to alter a design without modifying the original system. A viewpoint is a model, possibly incomplete, of a domain from a given perspective. We discuss the views-a operator and its semantics, and then apply the concepts to the NACHOS file system as a case study. We believe the approach can be applied to existing object-oriented software systems, and serve as a guide for developing systems which are more easily maintained. This case study is an example of an application of a more general transformational approach to software design and implementation. 1

Multi-paradigm software development is a spontaneous answer to attempts of nding the best paradigm. It was present in software development at the level of intuition and practiced as the \implementation detail" without even mentioning it in the design. Its breakthrough is twofold: several recent programming paradigms are encouraging it, while explicit multi-paradigm approaches aim at its full-scale support.

“There probably isn’t a ‘best ’ way to build the system, or even any major part of it; much more important is to avoid choosing a terrible way, and to have clear division of responsibilities among the parts. ” – Butler Lampson [33] Operating system code is complex. But, while substantial complexity is inherent to this domain, some complexity is caused by modularity problems. The goal of the work proposed here is to explore aspectoriented programming as a means of making this kind of complexity unnecessary. Towards this end, we need to identify aspects of the system, use the proposed mechanisms of AOP to modularize them, and establish the impact this approach has on the code. 1

Abstract not found

Frameworks are a valuable way to share designs and implementations on a large scale. Client programmers, however, have difficulty using frameworks. They find it difficult to understand non-local client-framework interactions, design solutions when they do not own the architectural skeleton, gain confidence that they have engaged with the framework correctly, represent their successful engagement with the framework in a way that can be shared with others, ensure their design intent is expressed in their source code, and connect with external files. A design fragment is a specification of how a client program can use framework resources to accomplish a goal. From the framework, it identifies the minimal set of classes, interfaces, and methods that should be employed. For the client program, it specifies the client-framework interactions that must be implemented. The structure of the client program is specified as roles, where the roles can be filled by an actual client program’s classes, fields, and methods. A design fragment exists separately from client programs, and can be bound to the client program via annotations in