Subject-oriented programming

Abstract: This note presents an overview of this ICSE ‘99 tutorial.

Abstract: Object-oriented applications execute by performing operations on objects. In suites of inter-operating or integrated applications, such as are essential in an enterprise setting, the same objects must be manipulated by multiple applications. Each application generally requires its own particular operations to be supported. For example, a Shipping application might require Truck objects to support a “What is your capacity?” operation, whereas a Transportation application might require them to support a “Set your route” operation.

Abstract: The authors have observed that large software systems are increasingly defined in terms of the features they implement. Consequently, there is a need to express the commonalities and variability between products of a product family in terms of features. Unfortunately, technology support for the early aspect of a feature is currently limited to the requirements level. There is a need to extend this support to the design and implementation level as well. Existing separation of concerns technologies, such as AOP and SOP, may be of use here. However, features are not first class citizens in these paradigms. To address this and to explore the problems and issues with respect to features and feature composition, the authors have formalised the notion of features in a feature model. The feature model relates features to a component role model. Using our model and a composition algorithm, a number of base components and a number of features may be selected from a software product family and a product derived. As a proof of concept, the authors have experimented extensively with a prototype Java implementation of their approach.

Abstract: Current visual programming environments make use of views and tools to present objects. These view-focused environments provide great functionality at the expense of distancing the objects behind the intermediary layers of views and tools. We propose the object-focused model, which attempts to foster the notion that objects themselves are directly available for interaction. Unique, directly manipulable representations of objects make them immediate, and basing functionality on the object rather than on extrinsic tools makes them the primary loci of action. But although immediacy and primacy contribute to the sense of concreteness of the objects, discarding conventional views and tools potentially restrict the functionality of the environment. Fortunately, by being extremely faithful to the notion of concreteness of objects, two principles emerge that allow object-focused environments to match the functionality of view-focused environments. The principle of availability makes functionality of objects accessible across contexts, and the principle of liveliness allows objects to participate in multiple contexts while retaining concreteness. All these elements help make objects seem more real in the objectfocused environment, hopefully lessening some of the cognitive burden of programming by reducing the distance between the programmer’s mental model of objects and the environment’s representation of objects. Programmers can get the sense that the objects on the screen are the objects in the program, and thus can think about working with objects rather than manipulating the environment. 1 INTRODUCTION Visual programming’s attractiveness stems in large part from its immediacy—programmers directly interact with program elements as if they were physical objects. These concrete visualizations of the program on the computer screen shape how programmers visualize the program within their mind, and may give them a foothold from which to think about the program: people find it easier to deal with the concrete than with the abstract. Object-oriented programming languages (even those that rely primarily on textual representations) strive toward the same end by providing objects as the fundamental elements in the program. Objects encapsulate and make concrete the elements of the program, including both the data to be manipulated and the behavior to be applied to them. Again, this paradigm works because most people find it easier to deal with the concrete than with the abstract. Yet while object-oriented programming languages assist the programmer by providing a concrete notion of objects, most programming environments for these languages push the programmer in the opposite direction, back toward the