Step-wise refinement is a powerful paradigm for developing a complex program from a simple program by adding features incrementally. We present the AHEAD (Algebraic Hierarchical Equations for Application Design) model that shows how step-wise refinement scales to synthesize multiple programs and multiple noncode representations. AHEAD shows that software can have an elegant, hierarchical mathematical structure that is expressible as nested sets of equations. We review a tool set that supports AHEAD. As a demonstration of its viability, we have bootstrapped AHEAD tools from equational specifications, refining Java and non-Java artifacts automatically; a task that was accomplished only by ad hoc means previously.

Software Product Line (SPL) Engineering has proved to be an effective method for software production. However, in the SPL community it is well recognized that variability in SPLs is increasing by the thousands. Hence, an automatic support is needed to deal with variability in SPL. Most of the current proposals for automatic reasoning on SPL are not devised to cope with extra-functional features. In this paper we introduce a proposal to model and reason on an SPL using constraint programming. We take into account functional and extra-functional features, improve current proposals and present a running, yet feasible implementation.

This paper presents a new approach for modular design of highly-entangled software components by statechart diagrams. We structure the components into features, which represent reusable, self-contained services. These are modeled individually by statechart diagrams. For composition of components from features, we need to consider the interactions between the features. These feature interactions, which are well known in the telecommunications area, typically describe special cases or cooperations which only occur when features are combined.

Feature Models are used in different stages of software development and are recognized to be an important asset in model transformation techniques and software product line development. The automated analysis of feature models is being recognized as one of the key challenges for automated software development in the context of Software Product Lines. In our previous work we explained how a feature model can be transformed into a constraint satisfaction problem. However cardinalities were not considered. In this paper we present how a cardinality-based feature model can be also translated into a constraint satisfaction problem. In that connection, it is possible to use off-the-shelf tools to automatically accomplish several tasks such as calculating the number of possible feature configurations and detecting possible conflicts. In addition, we present a performance test between two off-the-shelf Java constraint solvers. To the best of our knowledge, this is the first time a performance test is presented using solvers for feature modelling proposes 1

Feature models have been cited as one of the main contributions to model software product families. However, there is still a gap in product family engineering which is the automated reasoning on feature models. In this paper we describe how to reason on feature models using constraint programming. Although, there are a few attempts to reason on feature models there are two main drawbacks in these proposals: ## none of them associate parameters to features ### none of them use constraint programming as the reasoning base. Using constraint programming endows our proposal with a more powerful reasoning capacity and greater expressiveness than others.

In the domain of embedded software systems the increasing complexity of the functionality as well as the increase in variations caused by product lines requires a modular design process, separating function-based and component-based design. As a consequence, functional integration becomes a central task in the development process, to avoid unforeseen interaction. While currently functional integration often is delayed to module integration, leading to a late detection of interactions, here we suggest a methodical approach to the early integration of functions to construct a logical component-oriented architecture. 1

During the last century, many general purpose programming languages have been developed, all having rigid syntax and often a von-Neuman view of the world. With the rise of model-based development this changes: Featureoriented programming, domain specific languages, and platform-based design use rich and custom syntaxes to capture domain specific abstractions, refinement mappings, and design spaces. In this paper we show how a formalization of rich syntax can be used to compose abstractions, validate refinement maps, and construct design spaces. We describe a tool FORMULA for computing these properties, and present a series of examples from automotive embedded systems. 1.

View) We use the following notation for la beling transitions: {condition} called_function() / action A transition can be initiated by an external event, here called_function(). It may have a condition and it may have an action it initiates. This action may affect another automaton. Note that all three labels may be empty. In case the called function is omitted, we have an internal or spontaneous transition without an external event. For the following forwarding and reply features, we take a more detailed view and show the internal states of the forward and reply functions. The feature Forwarding includes also a function call do_forward which is not detailed here. The reply feature is similar. On a more abstract view, we could also model these by simple transitions as above. Note that we use two small circles to denote the start and end states of this transitions, which are determined upon composition. {forward_active} Forward /do_forward() {forward_inactive} {reply_active} Reply /do_reply() {reply_inactive} Feature Forwarding: forward() Feature Reply: reply() Figure 4: Internal View of Forwarding and Reply Features 3.1. Feature Interactions Interaction handling adapts a feature into the context of another one. With automata, we have two ways to refine a feature A to the new feature B: - The transitions of feature A may be refined. We model this by hierarchical automata. - New transitions from the states of A to states of B triggered by function calls of B. For instance, the above feature MaintenanceMode may have a function enter_maintenance_mode, which can be triggered by a transition in another feature. (See also [PrehoferFIW97] for this kind of feature interactions.) 4 We describe the first case in terms of automata by expanding the transitions labeled by function c...