An environment for managing evolving product line architectures

Garg, Anshul; Critchlow, Matt; Chen, Ping; Westhuizen, C. Van der; Hoek, André van der

doi:10.1109/icsm.2003.1235443

Cited by 28 publications

(34 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In the literature, there is no other comprehensive method that covers the representation of the complete life cycle of a product family. Instead, the common approach is to focus on a single [9,21], or few development phases [1,10,23].…”

Section: Classification Of Featuresmentioning

confidence: 99%

Observations from the Recovery of a Software Product Family

Lago

Vliet

2004

Software Product Lines

View full text Add to dashboard Cite

Abstract. The problem of managing the evolution of complex and large software systems is well known. Evolution implies reuse and modification of existing software artifacts, and this means that the related knowledge must be documented and maintained. This paper focuses on the evolution of software product families, although the same principles apply in other software development environments as well. We describe our experience gained in a case study recovering a family of six software products. We give an overview of the case study, and report a list of lessons learned, a list of implicit assumptions reconstructed during the case study, and some rules that we think are generally applicable. Our experience indicates that organizing architectural knowledge is a difficult issue. To properly serve the various uses of this knowledge, it needs to be organized along different dimensions. For effective use, tools are required. Our experience also indicates that, next to variability explicitly designed into the product family, there is a "variation creep", caused by different, and evolving, technical and organizational environments of the products. We propose to explicitly model invariabilities, next to variabilities, in software product lines to get a better grip on this variation creep.

show abstract

Section: Classification Of Featuresmentioning

confidence: 99%

Observations from the Recovery of a Software Product Family

Lago

Vliet

2004

Software Product Lines

View full text Add to dashboard Cite

show abstract

“…In particular, we have designed and implemented two automated algorithms: (1) a differencing algorithm for determining the set of changes between two (versions of) a product architecture selected out of an overall PLA, and (2) a merging algorithm with which such changes are merged back into a different location in the PLA. The algorithms complement Ménage, our design environment for managing the evolution of PLAs [8], and enhance it with automated support for propagating changes throughout an evolving PLA.…”

Section: Introductionmentioning

confidence: 99%

“…Figure 1 illustrates our overall approach based on the third scenario discussed in the introduction. First, a PLA is precisely defined (for instance, by using Ménage [8]). This results in a PLA specification from which individual product architectures can then be selected for delivery to customers (PA version 1).…”

Section: Introductionmentioning

confidence: 99%

Differencing and Merging within an Evolving Product Line Architecture

Chen

Critchlow

Garg

et al. 2004

Software Product-Family Engineering

View full text Add to dashboard Cite

Abstract. Propagating changes from one place in a product line architecture (PLA) to another is a difficult problem that occurs in a variety of settings. Currently, no automated tools exist that help an architect in doing so, and performing the task by hand in the face of a large PLA can be error-prone and difficult. To address this problem, we have built a set of tools for automating the process. Our approach breaks down into a two-step solution: (1) automatically determining the difference between two selected (versions of) a product architecture, and (2) automatically merging the difference back into a different location in the original PLA. In this paper, we detail each of these two steps and evaluate our solution on an example word processor PLA.

show abstract

“…However, using an existing experiment line to derive workflows is a less error prone activity and can be performed even by novice scientists. This occurs due to the effective use of composition rules (already adopted in software product lines) [13]. The essence of experiment lines is the systematic and efficient composition of experiments.…”

Section: Modeling a Deep Water Oil Exploitation Experimentsmentioning

confidence: 99%

GExpLine: A Tool for Supporting Experiment Composition

Oliveira

Ogasawara

Seabra

et al. 2010

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Scientific experiments present several advantages when modeled at high abstraction levels, independent from Scientific Workflow Management System (SWfMS) specification languages. For example, the scientist can define the scientific hypothesis in terms of algorithms and methods. Then, this high level experiment can be mapped into different scientific workflow instances. These instances can be executed by a SWfMS and take advantage of its provenance records. However, each workflow execution is often treated by the SWfMS as independent instances. There are no tools that allow modeling the conceptual experiment and linking it to the diverse workflow execution instances. This work presents GExpLine, a tool for supporting experiment composition through provenance. In an analogy to software development, it can be seen as a CASE tool while a SWfMS can be seen as an IDE. It provides a conceptual representation of the scientific experiment and automatically associates workflow executions with the concept of experiment. By using prospective provenance from the experiment, GExpLine generates corresponding workflows that can be executed by SWfMS. This paper also presents a real experiment use case that reinforces the importance of GExpLine and its prospective provenance support.

show abstract

An environment for managing evolving product line architectures

Cited by 28 publications

References 18 publications

Observations from the Recovery of a Software Product Family

Observations from the Recovery of a Software Product Family

Differencing and Merging within an Evolving Product Line Architecture

GExpLine: A Tool for Supporting Experiment Composition

Contact Info

Product

Resources

About