Abstract. Mixin layers are a technique for implementing layered object-oriented subclasses (mixin classes) but scaled to a multiple-class granularity. We describe mixin layers from a programming language viewpoint, discuss checking the consistency of a mixin layer composition, and analyze the language support issues involved. 1

In this paper we present a method of code imple-mentation that works in conjunction with collab-oration and responsibility based analysis model-ing techniques to achieve better code reuse and resilience to change. Our approach maintains a closer mapping from responsibilities in the analy-sis model to entities in the implementation. In so doing, it leverages the features of flexible design and design reuse found in collaboration-based de-sign models to provide similar adaptability and reuse in the implementation. Our approach re-quires no special development tools and uses only standard features available in the C++ language. In an earlier paper we described the basic mech-anisms used by our approach and discussed its advantages in comparison to the framework ap-proach. In this paper we show how our approach combines code and design reuse, describing spe-cific techniques that can be used in the develop-ment of larger applications. 1

To create successful interactive systems, user interface designers need to cooperate with developers and application domain experts in an interdisciplinary team. These groups, however, usually miss a common terminology to exchange ideas, opinions, and values. This paper presents an approach that uses pattern languages to capture this knowledge in software development, HCI, and the application domain. A formal, domain-independent definition of design patterns allows for computer support without sacrificing readability, and pattern use is integrated into the usability engineering lifecycle. As an example, experience from building an award-winning interactive music exhibit was turned into a pattern language, which was then used to inform follow-up projects and support HCI education.

Abstract not found

Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse. By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, i.e., software architectures and components needed for implementing applications in the class. FORM (Feature-Oriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering. FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques. The model constructed during the analysis is called a "feature " model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications. Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during actual application development. Architectures are defined from three different viewpoints (subsystem, process, and module) and have

Copyright © 2006, by the author(s).

object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the right way to solve the problem is to allow objects of classes defined in the same module to have privileged access to each other's representations; we show how to do this for inner classes. This approach allows programmers to express constructs like iterators and yet supports local reasoning about the correctness of the classes, because a class and its inner classes together can be reasoned about as a module. The paper also sketches how we use our variant of ownership types to enable e#cient software upgrades in persistent object stores.

Factory design patterns [9]), and advanced operating system mechanisms (such as explicit dynamic linking and multi-threading [10]). 9 Sample Code The following code illustrates an example of the Reactor object behavioral pattern. The example implements a portion of the logging server described in Section 2. This example also illustrates the use of an object creational pattern called the Accepter (described in [7]). The Accepter pattern decouples the act of establishing a connection from the service(s) provided once a connection is established. This pattern is useful for simplifying the development of connection-oriented network services (such as file transfer, remote login, distributed logging, and video-on-demand). The Accepter pattern enables the application-specific portion of a service to be modified independently of the mechanism used to establish the connection. The code shown below implements the ClientAccepter class. This class performs the steps necessary to accept connecti...

Module and class systems have evolved to meet the demand for reuseable software components. Considerable effort has been invested in developing new module and class systems, and in demonstrating how each promotes code reuse. However, relatively little has been said about the interaction of these constructs, and how using modules and classes together can improve programs. In this paper, we demonstrate the synergy of a particular form of modules and classes—called units and mixins, respectively—for solving complex reuse problems in a natural manner.

In several works on design methodologies, design patterns, programming language design and application frameworks, the need for adequate higher-level program entities that capture the patterns of collaboration between several classes has been recognized. The idea is that in general the unit of reuse is not a single class, but a slice of behavior affecting a set of collaborating classes. The absence of large-scale components for expressing these collaborations makes object-oriented programs more difficult to maintain and reuse, because functionality is spread over several methods and it becomes difficult to get the "big picture". In this paper, we propose Adaptive Plug and Play Components to serve this need. These components are designed such that they not only facilitate the construction of complex software by making the collaborations explicit, but they do so in a manner that supports the evolutionary nature of both structure and behavior. 1 Introduction The step from proc...