Restructuring Variability in Software Product Lines using Concept Analysis of Product Configurations

Loesch, Felix; Ploedereder, Erhard

doi:10.1109/csmr.2007.40

Cited by 29 publications

(37 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Some others are based on legacy system documentation [34], textual requirements [10], or identification of similar elements in specific models [76,59]. General similarity detection is also explored with syntactic techniques on source code [24], which only provide similarity information with no feature extraction, or with semantic techniques based on Formal Concept Analysis [38,75,59]. All these approaches share the usage of a single form of input to extract variability information.…”

Section: Extraction Of Architectural Variabilitymentioning

confidence: 99%

Extraction and evolution of architectural variability models in plugin-based systems

et al. 2013

View full text Add to dashboard Cite

Variability management is a key issue when building and evolving software-intensive systems, making it possible to extend, configure, customize and adapt such systems to customers' needs and specific deployment contexts. A wide form of variability can be found in extensible software systems, typically built on top of plugin-based architectures that offer a (large) number of configuration options through plugins. In an ideal world, a software architect should be able to generate a system variant on-demand, corresponding to a particular assembly of plugins. To this end, the variation points and constraints between architectural elements should be properly modeled and maintained over time (i.e., for each version of an architecture). A crucial, yet errorprone and time-consuming, task for a software architect is to build an accurate representation of the variability of an architecture, in order to prevent unsafe architectural variants and reach the highest possible level of flexibility. In this article, we propose a reverse engineering process for producing a variability model (i.e., a feature model) of a plugin-based architecture. We develop automated techniques to extract and combine different variability descriptions, including a hierarchical software architecture model, a plugin dependency model and the software architect knowledge. By computing and reasoning about differences between versions of architectural feature models, software architect can control both the variability extraction and evolution processes. The proSend offprint requests to: posed approach has been applied to a representative, large-scale plugin-based system (FraSCAti), considering different versions of its architecture. We report on our experience in this context.

show abstract

Section: Extraction Of Architectural Variabilitymentioning

confidence: 99%

Extraction and evolution of architectural variability models in plugin-based systems

et al. 2013

View full text Add to dashboard Cite

show abstract

“…Reusability of individual services and composition of services are determined by taking into consideration the different contexts [17] [18]. In [20] and [31] authors provided a formalism to define the context and introduced mechanisms to adapt the service composition at runtime.…”

Section: The Descriptive Variabilitymentioning

confidence: 99%

A Proposal for a Comparison Framework for the Management of Variability in Web Services Composition

Jamouss¹,

Bahri²

2017

JSW

View full text Add to dashboard Cite

Service Oriented Architecture (SOA) is currently considered as one of the most advanced means to realize quickly modular and flexible applications. A key concern for flexibility in SOA is the variability. Several works on variability were conducted. However, few studies have proposed classifications on the variability in the composition of web services. In this article, we propose an original approach to compare the management of variability in web services composition. This approach is based on a framework that considers the variability according to four dimensions namely the form, content, purpose, and life cycle. Each dimension is defined by a set of attributes that characterizes a particular facet of the variability.

show abstract

“…Finally, 25 articles were read thoroughly (step 3). Only three of these were identified to be partially relevant to OSRs and they are [26][27][28] …”

mentioning

confidence: 99%

“…It also provides the rationale behind the deletions. Nevertheless, the article does not include any reference and it is more of a narrative paper that describes how Fortran Community decides on deleting or leaving features in the language.The second article is entitled "Restructuring Variability in Software Product Lines Using Concept Analysis of Product Configurations" [27]. As this title implies, the article talks about variability in SPL.…”

mentioning

confidence: 99%

“…It says that the never used features "are likely to be features that have become obsolete. As these variable features are obviously not needed anymore, they should be removed from the set of offered features" [27]. The reason why these variable features are never used is that they have never been used or implemented in any product configurations and there exist other alternatives that are preferred in the product configurations.…”

mentioning

confidence: 99%

See 1 more Smart Citation

Obsolete software requirements

Wnuk

Gorschek

Zahda³

2013

Information and Software Technology

View full text Add to dashboard Cite

Context. Requirements changes are unavoidable in any software project. Requirements change over time as software projects progress, and involved stakeholders (mainly customers) and developers gain better understanding of the final product. Additionally, time and budget constraints prevent implementing all candidate requirements and force project management to select a subset of requirements that are prioritized more important than the others so as to be implemented. As a result, some requirements become cancelled and deleted during the elicitation and specification phase while other requirements are considered not important during the prioritization phase. A common scenario in this situation is to leave the excluded requirements for being considered in the next release. The constant leaving of the excluded requirements for the next release may simply render them obsolete. Objectives. In this master thesis, a preliminary investigation is conducted to study the phenomenon of obsolete software requirements (OSRs). The major objectives of the thesis are:1. To find if OSRs exist in reality and how serious they are. 2. To define an OSR. 3. To propose processes to discover OSRs and to take possible actions against them when they are discovered. 4. To examine the effects of OSRs on project's type and size. 5. To insert/inject OSRs into the requirements engineering life-cycle. 6. To develop a classification for requirements that can help finding OSRs. 7. To find empirical evidence regarding OSRs in the industry about all the above mentioned objectives. Methods. A systematic literature review (SLR) is conducted to find relevant information about OSRs. The articles were retrieved from a number of sources including Compendex, Inspec, IEEE Xplore, and ACM Digital Library. Besides, a web-based questionnaire was distributed to experts from both of the industry and the academia in order to collect empirical information about OSRs. The data retrieved from the questionnaire was analyzed mainly using descriptive analysis and chi-square test of significance.Results. The phenomenon of OSRs exists in reality and is deemed serious by the questionnaire respondents. Moreover, the thesis suggests a definition for OSRs based on the results of the questionnaire. Another contribution is proposing several processes to find OSRs in the requirements' documents, as well as suggesting possible actions to be taken against them. Additionally, OSRs are found to have negative effects on software projects. These effects vary depending on the project's type and size. Conclusions. In conclusion, the phenomenon of OSRs does exist in reality, and is considered serious by the majority of the questionnaire respondents. The respondents also believe that OSRs have negative effects on software projects depending on the size of the projects (measured in number of requirements) and the type of the project (outsourced, market-driven, and bespoke projects). In addition to, this thesis presents the definition of OSRs based on the experience of the author a...

show abstract

Restructuring Variability in Software Product Lines using Concept Analysis of Product Configurations

Cited by 29 publications

References 11 publications

Extraction and evolution of architectural variability models in plugin-based systems

Extraction and evolution of architectural variability models in plugin-based systems

A Proposal for a Comparison Framework for the Management of Variability in Web Services Composition

Obsolete software requirements

Contact Info

Product

Resources

About