Extending FeatuRSEB with Concepts from Systems Engineering

Favaro, John; Mazzini, Silvia

doi:10.1007/978-3-642-04211-9_5

Cited by 4 publications

(4 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Different from the notations proposed by Favaro and Mazzini [4], Gurp et al [15] and Czarnecki et al [2], this notation also indicates that the features should be classified into different types: Domain, Entity, Operational, Domain Technology and Implementation Techniques. The OdysseyFex notation also proposes a different way of representing the relationship between features.…”

Section: A Odyssey-fexmentioning

confidence: 97%

“…There are different approaches for including usability aspects in software product lines, from their manual construction, as previously mentioned, to extending existing methods for software product lines, to include non-functional requisites [9] in possibilities of customization based on abstract models [4]. Using abstract models and even extending already existing models is very costly, with the team having to develop (and/or extend) one more of many models, which ends up being unfeasible considering issues regarding the necessary cost, time and human resources.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Evaluating the Representation of User Interface Elements in Feature Models: an Empirical Study

Rodrigues

Bacelo²,

Silveira

et al. 2016

International Conferences on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

Abstract-Feature models are considered a reference in the majority of Software Product Line (SPL) methods. There are several different feature model notations to represent requirements of an SPL, at a higher or lower level of abstraction. Some notations present properties to distinguish functional, conceptual and non-functional features of an SPL. Non-functional requirements, especially those that involve the construction of user interfaces (UI), are usually not represented in the feature models, since the user interfaces are often created manually for each product. In this paper we present an experimental study performed in order to evaluate the effort required to, as well as the benefits and drawbacks of representing UI elements during the feature modeling of a Financial SPL. To this end, we applied the Odyssey-Fex and UI-Odyssey-Fex notations to design feature models from the perspective of Domain Engineers in the context of undergraduates, M.Sc. and Ph.D. students and software engineers with some expertise in SPL. Our results indicate that the effort to use the notations are similar, but the use of the UIOdyssey-Fex notation provides a better representativeness of UI elements.

show abstract

Section: A Odyssey-fexmentioning

confidence: 97%

Section: Introductionmentioning

confidence: 99%

Evaluating the Representation of User Interface Elements in Feature Models: an Empirical Study

Rodrigues

Bacelo²,

Silveira

et al. 2016

International Conferences on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

show abstract

“…FeatuRSEB [20] and its recent extension FeatuRSEB/Sys [48] extend the original reuse-driven software engineering business (RSEB) [49] by an explicit domain analysis process using feature models. RSEB is a model-driven approach based on use cases which builds sets of related applications from sets of reusable components.…”

Section: Related Workmentioning

confidence: 99%

Modeling Product Line Software Assets Using Domain-Specific Kits

Altintas

Çetin

Doğru

et al. 2012

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Software Product Line Engineering (SPLE) is a prominent paradigm for the assembly of a family of products using product line core assets. The modeling of software assets that together form the actual products is critical for achieving the strategic benefits of Software Product Lines (SPLs). We propose a feature-based approach to software asset modeling based on abstractions provided by Domain-Specific Kits (DSKs). This approach involves a software Asset Metamodel (AMM) used to derive Asset Modeling Languages (AMLs) that define reusable software assets in domain-specific terms. The approach also prescribes a roadmap for modeling these software assets in conjunction with the product line reference architecture. Asset capabilities can be modeled using feature diagrams as the external views of the software assets. Internal views can be expressed in terms of Domain-Specific Artifacts (DSAs) with Variability Points (VPs), where the domain-specific artifacts are created using Domain-Specific Kits. This approach produces loosely coupled and highly cohesive software assets that are reusable for multiple product lines. The approach is validated by assessing software asset reuse in two different product lines in the finance domain. We also evaluated the productivity gains in large-scale complex projects, and found that the approach yielded a significant reduction in the total project effort.

show abstract

“…Favaro and Mazzini extend FeatuRSEB, a method for domain modeling, with SysML constructs [28]. This approach leverages SysML specic diagrams as follows: block diagrams to represent its so called context models and higher level architecture, requirements diagrams for its domain requirement models, and parametric diagrams to document its business decisions.…”

Section: Related Workmentioning

confidence: 99%

Coping with Variability in Model-Based Systems Engineering: An Experience in Green Energy

Trujillo

Garate

Lopez-Herrejon

et al. 2010

Modelling Foundations and Applications

View full text Add to dashboard Cite

Model-Based Systems Engineering (MBSE) is an emerging engineering discipline whose driving motivation is to provide support throughout the entire system life cycle. MBSE not only addresses the engineering of software systems but also their interplay with physical systems. Quite frequently, successful systems need to be customized to cater for the concrete and specic needs of customers, end-users, and other stakeholders. To eectively meet this demand, it is vital to have in place mechanisms to cope with the variability, the capacity to change, that such customization requires. In this paper we describe our experience in modeling variability using SysML, a leading MBSE language, for developing a product line of wind turbine systems used for the generation of electricity.

show abstract

Extending FeatuRSEB with Concepts from Systems Engineering

Cited by 4 publications

References 12 publications

Evaluating the Representation of User Interface Elements in Feature Models: an Empirical Study

Evaluating the Representation of User Interface Elements in Feature Models: an Empirical Study

Modeling Product Line Software Assets Using Domain-Specific Kits

Coping with Variability in Model-Based Systems Engineering: An Experience in Green Energy

Contact Info

Product

Resources

About