In this paper, we describe a model-driven approach that aids the developer in parallelizing a software program. Information from a dynamic call tree, data dependencies and domain knowledge from the developer are combined in a model transformation process. This process leads to a model of the application where it becomes obvious which parts of the application can be executed in parallel.

Embedded systems with several heterogeneous processors require scheduling techniques that are able to make use of the parallel processors while at the same time keeping resource consumption low. In this paper, we therefore introduce a scheduling algorithm that considers timing and energy requirements for computation and communication and allows deadlines on program parts. The software applications are represented by Synchronous Dataflow Graphs (SDF) as these allow one to represent software concurrency and enable effective scheduling on multi-processor platforms. We suggest a scheduling heuristic that generates a number of possible schedules for an SDF representation of a parallelizable program, ranging from fast schedules with high energy consumption to slow schedules with lower energy consumption. Besides being able to choose only schedules that satisfy a specific global deadline or do not exceed a certain energy consumption, we allow individual constraints on single nodes of the SDF graph. The problems arising from including such constraints into the scheduling and adapting the heuristic accordingly are explained. The performance of our scheduling heuristic is illustrated on randomly generated graphs.

Feature Oriented Design Analysis (FODA) diagrams present the design of feature-oriented software applications. In some cases, however, the actual implementation of such an application does not correspond to the design that was set forward by the FODA diagram. Such discrepancies are referred to as the gap between design and implementation. We present a bottom-up approach for generating FODA diagrams from the changes to the source code. Unlike ordinary FODA diagrams, those diagrams are based on the implementation. Thanks to that, they do not only contain coarse-grained design information, but also incorporate finegrained implementation details, which can be used to bridge between feature-oriented design and implementation.

Software applications are updated frequently during their life cycle. In order to do so, they usually must be shut down, adapted and restarted. This causes periods of unavailability, which is not acceptable for some applications. Dynamic software updates (DSU) -- in which applications are updated at runtime -- is a technique that can be used to update software without the need to restart it. One of the problems of DSU is ensuring state consistency of the active application. Tranquility has been proposed as a necessary and sufficient condition for ensuring state consistency at the granularity of software components. As many object-oriented applications do not have a notion of software components, we aim to introduce tranquility at object granularity.

Feature-oriented programming (FOP) targets the encapsulation of software building blocks as features which better match the specification of requirements. As a result, programmers find it easier to design and compose different variations of their systems. Change-based FOP (CFOP) proposes to specify features as sets of first-class change objects which can add, modify or delete building blocks to or from a software system. First, we show how CFOP supports the modularization of crosscutting functionality. Afterwards, we expose a weakness of CFOP which is a consequence from features holding extensional sets of changes. We elaborate on a solution for that weakness which is based on intensional changes: descriptions that can evaluate to an extension of changes.

To minimize the cost of fixing bugs, they need to be identified as soon as possible. Testing the system is a means to detect such defects. However, when all the tests are run, it is often difficult to locate the precise error that causes a test to fail. We propose to use change-oriented programming as a means to detect bugs in a system while it is being developed. Not only may this technique assists in detecting bugs sooner, it can also be used to provide the developer with fine-grained information about the places in the program and test code that relate to the defect. We believe that this will decrease the probability of introducing bugs in a system and speed up the detection of the bugs that do get in.

Successful software systems need to be maintained. In order to do that, deep knowledge about their architecture and implementation details is required. This knowledge is often kept implicit (inside the heads of the experts) and sometimes made explicit in documentation. The problem is that systems often lack up-to-date documentation and that system experts are frequently unavailable (as they got another job or retired). Redocumentation addresses that problem by recovering knowledge about the system and making it explicit in documentation. Automating the redocumentation process can limit the tedious and error-prone manual effort, but it is no 'silver bullet'. In this paper, we report on our experience with applying redocumentation techniques in industry. We provide insights on what (not) to document, what (not) to automate and how to automate it. A concrete lesson learned during this study is that the "less is more" principle also applies to redocumentation.

Change is inevitable in software development. When several developers are working together on the same project it is possible for conflicts to occur. We propose to make changes explicit and use them to detect conflicts on a change level. We can do this by keeping changes as first class entities. Conflicts can then be detected by merging two sets of change objects and for each change checking if its preconditions are not violated by the changes in the other set.

Modularization is key to support the maintainability of software systems. In some cases, however, maintenance requires certain modules to evolve together. This phenomenon complicates software maintainability and is commonly referred to as co-evolution. In this paper, we tackle co-evolution in the domain of change-based feature-oriented programming (ChOP). In ChOP, feature modules -- each matching the implementation of one requirement -- are specified as sets of first-class change objects. Our solution is based on intensional changes: descriptive changes that are automatically evaluated with respect to the other feature modules before they are applied. We present a maintenance scenario and use it to show how intensional changes avoid co-evolution.

The idea of feature-oriented programming is to map requirements to features, concepts that can be composed to form a software product. Change-oriented programming (ChOP), in which features are seen as sets of changes that can be applied to a base program, has recently been proposed as an approach to FOP. Changes are recorded as the programmer works and can encapsulate any developer action, including the removing of code.Before changes can be combined to form a product, it has to be verified that there are no harmful interactions between selected changes. There exists, however, no formal model of the current approach that may serve as a reference specification for ChOP implementations. In an effort to fill this gap, we propose a formal model of ChOP, which, as we will show, maps to the well-understood notion of feature diagram. Thanks to this, we can reuse a number of results in feature diagram research and apply them to ChOP.

A growing trend in software construction advocates the encapsulation of software building blocks as features which better match the specification of requirements. As a result, programmers find it easier to design and compose different variations of their systems. Feature-oriented programming (FOP) is the research domain that targets this trend. We argue that the state-of-the-art techniques for FOP have shortcomings because they specify a feature as a set of building blocks rather than a transition that has to be applied on a software system in order to add that feature's functionality to the system. We propose to specify features as sets of first-class change objects which can add, modify or delete building blocks to or from a software system. We evaluate this approach by implementing a simple text editor in a feature-oriented way and use the implementation to produce four different program variations. This shows that our approach contributes to FOP on three levels: expressiveness, composition verification and bottom-up feature-oriented development.

A growing trend in software construction advocates the encapsulation of software building blocks as features which better match the specification of requirements. As a result, programmers find it easier to design and compose different variations of their systems. Feature-oriented programming (FOP) is the research domain that targets this trend. We argue that the state-of-the-art techniques for FOP have shortcomings because they specify a feature as a set of building blocks rather than a transition that has to be applied on a software system in order to add that feature's functionality to the system. We propose to specify features as sets of first-class change objects which can add, modify or delete building blocks to or from a software system. We present ChEOPS, a proof- of-concept implementation of this approach and use it to show how our approach contributes to FOP on three levels: expressiveness, composition verification and bottom-up development.

A growing trend in software construction advocates the encapsulation of software building blocks as features which better match the specification of requirements. As a result, programmers find it easier to design and compose different system variations. Feature-oriented programming (FOP) is the research domain that targets this trend. We argue that the state-of-the-art approaches to FOP lack expressiveness because they specify a feature as a set of building blocks rather than a transition that has to be applied on a system in order to add that feature's functionality to the system.We propose to specify features as sets of first-class change objects which can add, modify or delete building blocks to or from a software system. We present ChEOPS, a proof-of-concept implementation of this approach and use it to show how our approach contributes to FOP on three levels: expressiveness, composition verification and bottom-up FOP.

Feature-oriented programming (FOP) is the research domain that targets the encapsulation of software building blocks as features, which better match the specification of requirements. Recently, we proposed change-oriented programming, in which features are seen as sets of changes that can be applied to a base program, as an approach to FOP. In order to express features as sets of changes, those changes need to be classified in different sets that each represent a separate feature. Several classification strategies are conceivable. In this paper we identify three kinds of classification strategies that can be used to group the change objects. We compare them with respect to a number of criteria that emerged from our practical experience.

Patterns have been proved useful in many problem domains. In the do- main of software evolution, only behaviour-preserving patterns (e.g. refactorings) have ever been proposed. This paper proposes to broaden the scope of change pat- terns by means of a reification of any evolution efforts into styles. We define an evolution style as a first-class entity which is specified once and can be applied many times. Evolution styles allow the specification of (non) behaviour-preserving change patterns. We exemplify the use of the evolution style concept by means of two applications which evolve in a style-based way.

This paper revisits a problem that was identified by Kramer and Magee: placing a system in a consistent state before and after runtime changes. We show that their notion of quiescence as a necessary and sufficient condition for safe runtime changes is too strict and results in a significant disruption in the application being updated. In this paper, we introduce a weaker condition: tranquillity. We show that tranquillity is easier to obtain and less disruptive for the running application but still a sufficient condition to ensure application consistency. We present an implementation of our approach on a component middleware platform and experimentally verify the validity and practical applicability of our approach using data retrieved from a case study.

We propose a first-class change model for Change-Oriented Software Engineering (COSE). Based on an evolution scenario, we identify a lack of support in current Interactive Development Environments (IDEs) to apply COSE. We introduce a set of five extensions to an existing model of first-class changes and describe the desired behaviour of change-oriented IDEs to support COSE. With the help of an evolution scenario, we show why those extensions are required. Finally we describe ChEOPS: a prototypical implementation of a change-oriented IDE on top of VisualWorks and illustrate how it supports the extended first-class change model. ChEOPS is finally used to validate COSE as a solution for the shortcomings of existing IDEs.

Implementing context-dependent behaviour of pervasive computing applications puts a great burden on programmers: Devices need to continuously adapt not only to their own context, but also to the context of other devices they interact with. We present an approach that modularises behavioural adaptations into roles. Role selection takes the context of all the devices involved in an interaction into account, ensures an unambiguous scope of adaptation even in the presence of concurrency, and protects the privacy of the devices. Thus, our context-dependent role (CDR) model facilitates expressing interactions between applications in different, possibly conflicting contexts.

In order to support runtime changes, automated testing and refactorings in Agile Software Development (AgSD), we propose to represent changes applied on a system under de- velopment, as first-class objects. We envision the integration of a Change Management System in an existing methodology for AgSD called Advanced Round-Trip Engineering (ARTE). We explain how Change-Oriented ARTE (COARTE) allows capturing, visualising, replaying and rewinding changes that have been applied on the modelling, implementation and runtime views of an ARTE environment, and automatically synchronizes them with the other views. In this setup tests and refactorings can be composed out of changes, while runtime change propaga- tion is realized with different propagation strategies. RESUME.