No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Kumbang: A domain ontology for modelling variability in software product families
Abstract
Variability is the ability of a system to be efficiently extended, changed, customised or configured for use in a particular context. There is an ever-growing demand for variability of software. Software product families are an important means for implementing software variability. We present a domain ontology called Kumbang for modelling the variability in software product families. Kumbang synthesises previous approaches to modelling variability in software product families. In addition, it incorporates modelling constructs developed in the product configuration domain for modelling the variability in non-software products. The modelling concepts include components and features with compositional structure and attributes, the interfaces of components and connections between them, and constraints. The semantics of Kumbang is rigorously described using natural language and a UML profile. We provide preliminary proof of concept for Kumbang: the domain ontology has been provided with a formal semantics by implementing a translation into a general-purpose knowledge representation language with formal semantics and inference support. A prototype tool for resolving variability has been implemented.
... From this stage, twelve approaches were identified after the recursive and iterative literature search and analysis of citations described in the section on the detailed qualitative meta-synthesis process. A subsequent web search was performed after studying the documentation and original reports from companies and consulting firms and confirmed the use and existence of these approaches (FODA (Kang et al. 1990), Koalish (Asikainen et al. 2004), KobrA (Atkinson et al. 2000), Kumbang (Asikainen et al., 2007), COVAMOF (Junior et al. 2005), and others). ...
... Koalish is based on the product configuration domain. Kumbang (Asikainen et al., 2007) is a combination of Koalish and feature modelling concepts. It models SPLE from both features and architectural perspectives. ...
... Variability is represented in a Kumbang model that contains a set of Kumbang types and is the description of its instances. Kumbang synthesizes existing methods of variability modelling and provides a basis for the development of VM modelling and tool support from requirements specification to architecture phases (Asikainen et al., 2007), as well as enabling SPL configuration according to specific customer requirements. ...
Variability management (VM) in software product line engineering (SPLE) is introduced as an abstraction that enables the reuse and customization of assets. VM is a complex task involving the identification, representation, and instantiation of variability for specific products, as well as the evolution of variability itself. This work presents a comparison and contrast between existing VM approaches using “qualitative meta-synthesis” to determine the underlying perspectives, metaphors, and concepts of existing methods. A common frame of reference for the VM was proposed as the result of this analysis. Putting metaphors in the context of the dimensions in which variability occurs and identifying its key concepts provides a better understanding of its management and enables several analyses and evaluation opportunities. Finally, the proposed framework was evaluated using a qualitative study approach. The results of the evaluation phase suggest that the organizations in practice only focus on one dimension. The presented frame of reference will help the organization to cover this gap in practice.
... About 25 studies have more than 15 citations, which shows that they have been well accepted within the research community. Although these citation rates are not meant for comparison among studies, two studies stand out: Applications of ontologies in software engineering by Happel and Seedorf [9], with more than 200 citations, and A domain ontology for modeling variability in software product families by Asikainen et al. [71], with more than 100 citations. We expect that the number of citations for the selected studies will continue to grow, especially since all the studies included in the research have been published in the last 10 years. ...
... A Kumbang model is a representation of the variability in an SPL family and it de¯nes a possible set of valid con¯gurations. The approach serves as the basis for developing modeling languages and tool support for variability management [71]. ...
... Ontologies have also penetrated into SPLs, where di®erent approaches have been proposed like using ontologies to enrich feature diagrams [70], as well as reason about architectural elements and features [16] and model variability [71]. We favor ontology modeling over feature modeling and believe that ontologies can be e±ciently used for specifying features and even variability models. ...
One of the main goals of the Software Engineering discipline is to find higher abstraction levels and ways to reuse software in order to increase its productivity and quality. Ontologies, which are typically considered as a technique or an artifact used in one or more software lifecycle phases, may be used to help achieve that goal. This paper provides a systematic literature review of the proposed solutions for applying ontologies in automatic and generative programming. The paper aims to identify ontologies and software development tools, frameworks, prototypes, design patterns and methodologies that use them as development artifacts for source code generation or product derivation. The review provides researchers with the state of the art, while also identifying challenges and gaps that require further exploration and development.
... Software Product Lines (SPLs), sometimes also referred to as software families, imply a set of software products that consist of a common architecture and a set of reusable assets used in systematical production (Asikainen et al., 2007). The SPL discipline focuses on systematic, planned and strategic reuse of core assets in order to produce a number of products that satisfy a particular market segment (Duran-Limon et al., 2015). ...
... However, the authors acknowledge the lack of tools support which still needs to be developed. In order to fully demonstrate the practical applicability of the approach it is also necessary to test it on real software product families in real software development contexts (Asikainen et al., 2007). Czarnecki et al. explored the relation between feature modeling and ontology modeling. ...
... Similar to (Karatas et al., 2014;Asikainen et al., 2007), we favor ontology modeling over feature modeling and believe that ontologies expressivity can be efficiently used for specifying features. We argue that ontologies may be used for feature specification, without the need of mapping them to feature diagrams. ...
One of the main goals of the Software Engineering (SE) discipline is to find higher abstraction levels, ways to reuse software in order to increase its productivity, quality. Ontologies, which are typically considered as a technique or an artifact used in one or more software lifecycle phases, may be used to help achieve that goal. This paper provides a literature review, discussion, analysis of the existing solutions for implementing ontologies in SE. We selected several software development paradigms (including Software Product Lines, Component-Based Development, Generative Programming, Model-Driven Engineering) for our classification, discussion of different approaches proposed in the literature. It was established that ontologies are suitable for providing a common vocabulary to avoid misunderstanding between different parties in SE, requirements specification, features specification, variability management, components specification, components matching, model transformations, code generation. Based on the conducted review, guidelines for further research are given.
... In consequence, the elicitation of domain knowledge is a huge task in SPLE, and most of it is embedded into RA, such as the core common functionality, domain quality properties, architectural style(s) and business rules [6] [11] [13] [26] [30]. On the other hand, ontologies, representing hierarchically organized knowledge [7], have been used to specify and verify consistency of SPL domain knowledge [9] [10] [21] ]22]. ...
... An ontology is an explicit specification of a conceptualization [7]. Ontologies are widely used to capture domain knowledge in an organized and structured way; they are used as SPLE tools to check consistency of the concrete product configurations derived from RA [8] [9]; however, few works consider the direct representation of RA by an ontology [10]. The feature model approach, focused on describing features directly perceived by the user, which are in general functional requirements (FR), is mostly used to build the RA variability model [19]; however non functional requirements (NFR), which are the major responsible of the SPL variability [5], are not deeply considered in this approach. ...
... The OntoSPL ontology is proposed to model ontology-based feature models, and a set of SPARQL queries is presented in different scenarios, that can be executed to automatically reconfigure SPL products specified in OntoSPL. On the specific topic of variability modeling, Kumbang is proposed 5 http://www.w3.org/TR/owl-features/ in [9] as a domain ontology to model the SPL variability, including NFRs; it has been provided with formal semantics by implementing a translation into a general-purpose knowledge representation language with formal semantics and inference support. A prototype tool for solving variability has been implemented. ...
Software Product Lines (SPL) are based on assets reuse for software development and claim to reduce costs and time to market, while increasing the quality of derived products, guaranteeing the SPL evolution. SPL is now a well known approach in academic and industrial practices. The specification of the SPL domain knowledge or SPL area, is crucial to design a reusable and evolutionary Reference Architecture (RA), being RA one of the major SPL artifacts; the concrete software products members of the SPL family in the specific domain, will be derived from this RA. On the other hand, ontologies, representing hierarchically organized knowledge, have been used to specify and verify consistency of the SPL domain knowledge. The goal of this work is to present an ontology, called HIS-RA Ontology, to specify the knowledge imbedded into RA for the Healthcare Information Systems Healthcare Information Systems (HIS) domain, called HIS-RA, which has been defined in previous works, and was specified as a non-directed connected graph (P, R), where P are the components or nodes and R the edges or connectors relating components. HIS-RA has been built by a bottom-up process using the knowledge on existing market products. The HIS-RA Ontology can be used to derive consistency rules for the
construction of valid architectural configurations or feasible solutions (FS), for concrete products, constructed by instantiating HIS-RA. Quality requirements that the HIS-RA functionalities or core of common components must fulfil, are considered in order to guarantee the global quality of concrete products. The design of a semiautomatic FS derivation process using the HIS-RA Ontology presented here and its support tool, is an on-going work.
... In Section 2, we describe the essence of feature models and ontologies. In Section 3, three studies that use feature modeling, ontologies or both of them in SPLs are presented: (Czarnecki et al., 2006), (Johansen et al., 2010) and (Asikainen et al., 2007). In the next section, our approach to connecting feature models and ontologies in SPL is explained and an ex-ample is shown. ...
... In (Asikainen et al., 2007), a domain ontology for modeling the variability in SPL, called Kumbang was proposed. This ontology unifies the feature modeling and the architecture modeling in SPL. ...
... This ontology unifies the feature modeling and the architecture modeling in SPL. Although (Asikainen et al., 2007) uses ontology to represent the features and the architecture of SPL, it should be considered that Kumbang ontology was described using UML. As a result, the power of the semantics description of this language is not the same as OWL languages, considering also the inference mechanisms that can be used in conjunction with OWL. ...
Feature models have been used as a way to describe the variability in Software Product Lines (SPL). Using this model we can show variation points, variants and restrictions between variation points and variants. However, restrictions and relations that can be expressed using this domain modelling technique are unsatisfactory. Our proposal aims to solve this challenge connecting feature models and ontologies as domain modelling technique, which can be used to provide additional information and can also add more semantics in the context of Software Product Lines.
... As the derivation process is still challenging, several authors recognize the importance for automating the analysis of feature models [6] as well as the product architecture derivation process [7], [8], [9], [10], [11], [12]. In this light, we can highlight two types of derivation approaches: copybased and transformation-based. ...
... This method is commonly supported by approaches using an architecture description language (ADL) as modeling language [8]. Other proposals supporting product derivation rely on different techniques, ranging from Boolean expressions [7], [8], [9] to Model-Driven Development like [10], [14] and aspect-oriented programming (AOP) [12]. Because there are still challenges not properly solved in SPL derivation, we describe in the next section the problem statement and goals of our work. ...
... Some other works have addressed the issue of deriving product architectures. Some of these approaches allow the automatic generation of component model configurations [10], [11], [12] and using ADL specifications [8], [9]. Other approaches focus on deriving UML activity and class models [7], [13], [23], [24] using propositional logic, which is recognized as a valid technique to support product derivation. ...
Software product line (SPL) engineering has proven to improve software quality and shorten development cycles, cost and time. In product line engineering, product derivation is concerned with the realization of the variability at the implementation level. However, the majority of research works focuses on instantiating the variants selected in the final product, while the derivation at the architecture level has been poorly explored. As product line engineers often customize the product architecture by hand during the application engineering phase, the derivation and customization processes of the product line architecture (PLA) might be in some cases error-prone. Consequently, in this research we present an Ontology-based product Architecture Derivation (OntoAD) framework which automates the derivation of product-specific architectures from an SPL architecture. Our solution uses a language-independent model to specify the product line architecture and a model-driven engineering approach for architecture derivation activities. We use an ontology formalism to reason about the automatic generation of model-to-model transformation rules based on the selection of features and we illustrate our approach using a voice over IP motivating example. Finally, we report results about scalability and performance regarding the size of the variability model.
... Compared to our previous work, KumbangSec is based on Kumbang [2,25], which is a conceptualization and a tool set for modeling and configuring variability through functional features and components; this study extends Kumbang with security-specific modeling concepts. Preliminary results of KumbangSec has been reported earlier [23,24,26]; however, this paper presents a completely revised conceptualization. ...
... Countermeasures as a characterization of software security [18]. Kumbang [2,25]. Using stable models and answer set programs for product configuration [34,36,37]. ...
... Finally, countermeasure variability has impact, e.g., to other quality attributes. In order to represent all this, our modeling conceptualization defines countermeasure variability through composition, attributes, inheritance, constraints and descriptive countermeasure impacts (Figure 1) [2]. An excerpt from the textual configuration model is also shown. ...
In a software product line, security may need to be varied. Consequently, security variability must be managed both from the customer and product line architecture point of view. We utilize design science to build an artifact and a generalized design theory for representing and configuring security and functional variability from the requirements to the architecture in a configurable software product line. An open source web shop product line, Magento, is used as a case example to instantiate and evaluate the contribution. The results indicate that security variability can be represented and distinguished as countermeasures; and that a configurator tool is able to find consistent products as stable models of answer set programs.
... Some research as described in [6,4,7,17], use approaches based on ontologies to enhance SPL support when developing applications. In these studies the need to add semantic aspects in SPL variability representation is recurrent. ...
... In the SPL context, variability is the ability of the system to be effectively scalable, changeable, customized or configured for use in a particular context [6]. Products incorporating variability may have advantages such as addressing various segments of the market and providing different sets of features according to their needs. ...
... As far as we know, there are few studies in the literature that use ontologies to represent the variability in SPL [6,4,7,17]. Most of them also highlight the deficiencies or 'unsuitability' of a feature model to express the variabilities in a specific application domain. ...
Context:
Most specialized users (scientists) that use bioinformatics applications do not have suitable training on software development. Software Product Line (SPL) employs the concept of reuse considering that it is defined as a set of systems that are developed from a common set of base artifacts. In some contexts, such as in bioinformatics applications, it is advantageous to develop a collection of related software products, using SPL approach. If software products are similar enough, there is the possibility of predicting their commonalities, differences and then reuse these common features to support the development of new applications in the bioinformatics area.
Objectives:
This paper presents the PL-Science approach which considers the context of SPL and ontology in order to assist scientists to define a scientific experiment, and to specify a workflow that encompasses bioinformatics applications of a given experiment. This paper also focuses on the use of ontologies to enable the use of Software Product Line in biological domains.
Method:
In the context of this paper, Scientific Software Product Line (SSPL) differs from the Software Product Line due to the fact that SSPL uses an abstract scientific workflow model. This workflow is defined according to a scientific domain and using this abstract workflow model the products (scientific applications/algorithms) are instantiated.
Results:
Through the use of ontology as a knowledge representation model, we can provide domain restrictions as well as add semantic aspects in order to facilitate the selection and organization of bioinformatics workflows in a Scientific Software Product Line. The use of ontologies enables not only the expression of formal restrictions but also the inferences on these restrictions, considering that a scientific domain needs a formal specification.
Conclusions:
This paper presents the development of the PL-Science approach, encompassing a methodology and an infrastructure, and also presents an approach evaluation. This evaluation presents case studies in bioinformatics, which were conducted in two renowned research institutions in Brazil.
... Software Product Line (SPL), sometimes called software series, which means a group of software products consisting of common architecture and sets the number of reusable assets used in the manufacture of the system (Asikainen et al., 2007) [22]. SPL courses focus on reuse basic assets systematically, planned and strategically in order to produce various products that meet the succeeding conditions specific market segments (Duran-limon et al., 2015) [23]. ...
... Software Product Line (SPL), sometimes called software series, which means a group of software products consisting of common architecture and sets the number of reusable assets used in the manufacture of the system (Asikainen et al., 2007) [22]. SPL courses focus on reuse basic assets systematically, planned and strategically in order to produce various products that meet the succeeding conditions specific market segments (Duran-limon et al., 2015) [23]. ...
One of the main goals of software engineering (SE) discipline is a way to find a higher level of abstraction and reuse software improve productivity and quality. The body is usually considered to be one or more of the technologies or artifacts used software life cycle stages can be used to achieve this goal. This article provides an overview, discussion, and analysis of the literature and implement a new solutions for ontology in se. We chose some examples of software development (including software products line, component development, generative programming and model-driven engineering) for our classification and discussion various methods are proposed in the literature. Confirmed the ontology is suitable for providing general vocabulary that should be avoided misunderstanding between the parties in the se, request specification, functional specification, variability management, component specifications, component conformity, model conversion and code generation. According to the review provides further research.
... Bencomo et. al. (Bencomo, et al., 2008) deal with runtime variability issues dynamically adapting to changing runtime context. OVM model is used for variability specification. ...
... Nevertheless, composition variability is not taken into account explicitly. Combining Koalish with concepts from feature modeling, Kumbang (Asikainen, et al., 2006) is introduced as a domain ontology which is developed as a profile extending the UML metamodel ...
A new meta-model is proposed that establishes a variability specification and system configuration environment for Component Oriented System Engineering Modeling Language (COSEML). Variability is integrated to COSEML that can be viewed as an Architectural Description Language emphasizing the decomposition view. The textual version of this language is also presented and demonstrated with an example specification.
... Conflicts arise when decisions that are locally consistent cannot be applied globally because they violate one or more constraints in the feature model. Product configurations are directly derived from the feature model into coded modules, without considering at all the architectural structure organizing the features, causing further problems with the related architectural documentation, which in SPL is also considered an asset; the analysis of the FODA variability model is done applying constraints programming techniques [26] [27] [28], or ontology-based approaches [21] [29] [30] [38], which are used to verify consistency of variability models and/or represent feature models. However, notice that a feature model is not an architectural model; according to FODA [6], only directly users-perceived, usually FR, are considered. ...
... On the specific topic of variability modeling, Kumbang is proposed in [21] as a domain ontology to model the SPL variability, including a model for NFR, the Quality Attribute (QA) profile. Each ontology in QA represent a quality property or attribute, for example security, including metrics. ...
... To date, several representations of variability, together with mechanisms that facilitate its systematic exploitation, have been reported in the literature, and some efforts have been made to unify the concepts and relations of the field [15]. In order to model such variability, methods can be broadly categorized in two groups: the feature-based group, which comprises methods that model the common and variable features of a product family (an analysis-oriented perspective), and the architecture-based group, which includes methods that describe variability in terms of components, interfaces, connectors and so on (a more design-oriented perspective) [49]. At the requirements engineering (RE) stage the focus is on the first group, that is, languages based on the modelling of features. ...
... These are, namely, Kumbang configurator [49], MODPL Feature plugin [65], Rhizome [66], Questio [59], SREPPLine [67], Domain Analysis CASE tool [68], and the OntoFeature tool [69]. A summary of the modelling languages and tool support for each selected paper is presented in Appendix C. ...
Context: Software product lines (SPLs) have reached a considerable level of adoption in the software industry, having demonstrated their cost-effectiveness for developing higher quality products with lower costs. For this reason, in the last years the requirements engineering community has devoted much effort to the development of a myriad of requirements modelling languages for SPLs.
Objective: In this paper, we review and synthesize the current state of research of requirements modelling languages used in SPLs with respect to their degree of empirical validation, origin and context of use, level of expressiveness, maturity, and industry adoption.
Method: We have conducted a systematic literature review with six research questions that cover the main objective. It includes 54 studies, published from 2000 to 2013.
Results: The mean level of maturity of the modelling languages is 2.59 over 5, with 46% of them falling within level 2 or below -no implemented abstract syntax reported-. They show a level of expressiveness of 0.7 over 1.0. Some constructs (feature, mandatory, optional, alternative, exclude and require) are present in all the languages, while others (cardinality, attribute, constraint and label) are less common. Only 6% of the languages have been empirically validated, 41% report some kind of industry adoption and 71% of the languages are independent from any development process. Last but not least, 57% of the languages have been proposed by the academia, while 43% have been the result of a joint effort between academia and industry.
Conclusions: Research on requirements modeling languages for SPLs has generated a myriad of languages that differ in the set of constructs provided to express SPL requirements. Their general lack of empirical validation and adoption in industry, together with their differences in maturity, draws the picture of a discipline that still needs to evolve.
... In the world of software architecture [3], it could be argued that a software architecture S is a kind of logical architecture, since S is normally regarded as a design level artefact. 1 However, in our view, S often looks more like a physical architecture, particularly when the level of abstraction is low. ...
... Extensions to Koala for configuration definition and generation are provided by Koalish[2] and Kumbang[1]. ...
In system design, the distinction between a logical architecture at design level and the corresponding physical architecture at implementation level is recognised as good practice. In this paper we show how we can define logical architectures in which variation points can be defined explicitly, i.e. as first-class citizens. We solicit feedback and discussion on such an approach to variability in software architectures.
... In the world of software architecture [3], it could be argued that a software architecture S is a kind of logical architecture, since S is normally regarded as a design level artefact. 1 However, in our view, S often looks more like a physical architecture, particularly when the level of abstraction is low. ...
... Extensions to Koala for configuration definition and generation are provided by Koalish[2] and Kumbang[1]. ...
In system design, the distinction between a logical architecture at design level and the corresponding physical architecture at implementation level is recognised as good practice. In this paper we show how we can define logical architectures in which variation points can be defined explicitly, i.e. as first-class citizens. We solicit feedback and discussion on such an approach to variability in software architectures.
... In this paper, we describe Kumbang Modeler, which is a prototype modeling tool for Kumbang. Kumbang [9] is a domain ontology for modeling the variability in software product families. Kumbang includes concepts for modeling variability, from the point of view of the component and feature structures. ...
... Kumbang [9] is a domain ontology for modeling variability in software product families. Kumbang dierentiates between a conguration model, which describes a family and contains variability, and a product description, which is a model of a product individual derived from a conguration model by resolving variability. ...
Variability is the ability of a system to be effciently extended, changed, customized, or configured for use in a particular context. Several methods of modeling variability have been reported. However, tool support is also needed to take full advantage of models. We describe a prototype tool called Kumbang Modeler. Kumbang Modeler enables modeling the variability of a software product family using Kumbang conceptualization and language. The study follows the design science methodology. A user-centered design was applied in the development of Kumbang Modeler, and light-weight usability tests in the evaluation. The usability tests show that a person with knowledge of Kumbang concepts is able to correctly model the variability of a software product family using Kumbang Modeler.
The paper is available at:
http://www.soberit.hut.fi/Svamp/Modeller.pdf
... IEEExplore; 2. ACM Digital library; 3. Citeseer library (Google); 4. ScienceDirect; 5. EI Compendex / Inspec; 6. SpringerLink; and 7. Web of Science). As an indication of inclusiveness, the results were checked for three known relevant papers (i.e., (Svahnberg, van Gurp et al. 2005;Asikainen and Mannisto 2007;Sinnema and Deelstra 2007)). All three relevant papers were found in the search results. ...
... In addition, several works have combined techniques from ontology and SPL engineering. Most of these works consist on the use of ontologies to improve the representation of common and variant software features of SPLs [15], [16]. In other works, ontologies and SPLs have been applied in combination, i.e., to manage cloud service configurations [17]. ...
Global ontologies must provide a balance of reusabilityusability to minimize the ontology reuse effort in different
applications. To achieve this balance, ontology design methods
focus on designing layered ontologies that classify into abstraction
layers the common domain knowledge (reused by most
applications) and the variant domain knowledge (reused by
specific application types). This classification is performed from
scratch by domain experts and ontology engineers. Hence, the
design of reusable and usable ontologies that represent complex
domains takes a lot of effort. Considering how common and
variant software features are classified when designing Software
Product Lines (SPLs), we argue that SPL engineering techniques
can facilitate the domain knowledge classification taking as
reference existing ontologies. In this paper, we show the
experiences of applying SPL and ontology design techniques in
combination to design a reusable and usable global ontology for
the energy domain. Domain experts and ontology engineers
evaluated the proposed method. The results show that SPL
engineering techniques enable a systematic and accurate domain
knowledge classification, thus saving ontology design effort.
... However, the approach does not handle composition variability explicitly. Combining Koalish with concepts from feature modeling, Kumbang [4] is introduced as a domain ontology which is developed as a profile extending the UML metamodel. ...
A key factor for achieving flexible component oriented applications is to make the
components possible to change and adapt instead of creating and using them from
scratch. In order to fulfill various needs in time with little effort, a new metamodel is
proposed that establishes a variability specification and system configuration environment for Component-Oriented Software Engineering Modeling Language (COSEML).
Variability is integrated to COSEML that can be viewed as an Architectural Description Language emphasizing the decomposition view. We refer to this extended version
of COSEML as XCOSEML. The textual version of this domain-specific language
is presented and demonstrated with examples. Moreover, an approach to formally
verify component compositions incorporating variability is proposed which eases
variability-intensive component oriented system development by reducing the complexity of verification. A step by step model transformation approach from XCOSEML
to Featured Transition System (FTS) is used which helps the generation of FTS models, namely required feature model of the variable component composition and its
fPromela specification.
... A major factor affecting the success of a software product line, classic or dynamic, is the variability management activity it incorporates [12]. In the literature there are reports of various variability modeling and management approaches such as feature modeling (e.g., [28]), using UML and its extensions (e.g., [46]), and using domain ontologies (e.g., [4]). Feature modeling stands out as a very popular choice within a wide variety of techniques that can be used for this purpose [11]. ...
Feature modeling has been a very popular approach for variability management in software product lines. Building a feature model requires substantial domain expertise, however, even experts cannot foresee all future possibilities. Changing requirements can force a feature model to evolve in order to adapt to the new conditions. Feather is a language to describe model transformations that will evolve a feature model. This article presents the structure and foundations of Feather. First, the language elements, which consist of declarations to characterize the model to evolve and commands to manipulate its structure, are introduced. Then, semantics grounding in feature model properties are given for the commands in order to provide precise command definitions. Next, an interpreter that can realize the transformations described by the commands in a Feather script is presented. Finally, effectiveness of the language is discussed using two realistic examples, where one of the examples includes a system from a dynamic environment and the other employs a system that has a large feature model containing 1,227 features.
... To support these efforts, a range of variability modelling and management techniques were developed [39,13,22,62,56,55,52]. There has also been foundational work developing a theoretical basis for variability [41,29,18] and cataloguing the range of alternate realisation strategies [58,7,20]. More recently, the impact of this work has extended beyond the software product-family domain, and variability concepts have been harnessed in a range of related areas including ambient intelligent middleware [25], web service-based systems [6], legacy software assets [42], Software-as-a-Service (SaaS) applications [4], mobile services [38], and enterprise architecture [50]. ...
This chapter focuses on delineating the requirements of variability intensive systems based on recent developments in the Internet of Things technologies and applications. IoT opens unprecedented possibilities for real-time information sharing between sensors, devices and systems, enabling intelligent decision-making, tracking, traceability and planning. IoT technologies, such as Ubiquitous Computing, Radio-Frequency Identification, and Wireless Sensor Networks, boost innovative applications for industrial manufacturing
and enterprise systems, Smart Cities, Smart Driving and Transportation, and Smart Environments. Current trends indicate a resurgence of interest in Machine Learning combined with IoT, but also new developments such as Multi-Access Edge Computing. These trends will ultimately lead to a new generation of variability intensive systems with complex, multi-perspective requirements that need to be accommodated. This chapter identifies the range of variability requirements of future IoT systems across multiple dimensions and provides guidance for practitioners on how to identify and realize variability requirements in IoT systems.
https://www.crcpress.com/Software-Engineering-for-Variability-Intensive-Systems-Foundations-and/Mistrik-Galster-Maxim/p/book/9780815348054
... (Laser, Rodrigues, Domingues, Oliveira, & Zorzo, 2015)). Finally, 8% (5 papers) extended the UML notation into UML PLUS (Product Line UML based Software Engineering) method ( (Gomaa, 2013) (Albassam & Gomaa, 2013)); Kumbang ( (Asikainen, Männistö, & Soininen, 2007), ), a modelling language and an ontology for modelling variability in software product line architectures from feature and component points of view; and KumbangSec ( (Myllärniemi, Raatikainen, & Männistö, 2015)). 23% (14 papers) of the selected primary studies described how to represent variability using an ADL, with a number of different ADLs adopted. ...
Variability in software-intensive systems is the ability of a software artefact (e.g., a system, subsystem, or component) to be extended, customised or configured for deployment in a specific context. Software Architecture is a high-level description of a software-intensive system that abstracts the system implementation details allowing the architect to view the system as a whole. Although variability in software architecture is recognised as a challenge in multiple domains, there has been no formal consensus on how variability should be captured or represented. The objective of this research was to provide a snapshot of the state-of-the-art on representing variability in software architecture while assessing the nature of the different approaches. To achieve this objective, a Systematic Literature Review (SLR) was conducted covering literature produced from January 1991 until June 2016. Then, grounded theory was used to conduct the analysis and draw conclusions from data, minimising threats to validity. In this paper, we report on the findings from the study.
... For instance, Asikainen et al. [7] developed WeCoTin, a tool that generates questionnaire-based user interfaces from PCML models. An alternative is Kumbang [1,36], an ontology to express variability taking into account both the feature and the architecture points of view. Felfernig et al. [26] show how to convert a configuration problem into a Constraint Satisfaction Problem (CSP), paving the way for CSP-based configuration engines. ...
Mass customization is a widely embraced paradigm through which engineers, sales people and customers can tailor products to specific needs. One typically achieves this task by using a configurator, i.e. a software application wherein a user can define the product she wants by selecting options and setting parameters. Given their importance, configurators must be dependable and evolvable. Yet, building configurators often constitutes a complex software engineering challenge. In this paper, we report on two configurators developed by a spin-off company of the University of Namur for the retail industry. We highlight the difficulties inherent to such developments and present solutions that can help overcoming them. Finally, we expose open challenges and discuss how future research can address them.
... A domain ontology for chemical process engineering is proposed in [15]. Regarding software systems, a Web service modeling ontology to describe all aspects of Web services is presented in [19], an ontology for scientific software metadata is proposed in [6], and an ontology to model the variability in software product modeling is presented in [2]. ...
Ontologies are critical sources of semantic information for many application domains. Hence, there are ontologies proposed and utilized for domains such as medicine, chemical engineering, and electrical energy. In this paper, we present an improved and extended version of a wind energy ontology previously proposed. First, the ontology is restructured to increase its understandability and coverage. Secondly, it is enriched with new concepts, crisp/fuzzy attributes, and instances to increase its usability in semantic applications regarding wind energy. The ultimate ontology is utilized within a Web-based semantic portal application for wind energy, in order to showcase its contribution in a genuine application. Hence, the current study is a significant to wind and thereby renewable energy informatics, with the presented publicly-available wind energy ontology and the implemented proof-of-concept system.
... Depending on the product line strategy, an organization can choose the appropriate product line adoption approach. There are several approaches for development and analysis of SPLs in the literature [45,48,49] including modeling and configuring variability using ontologies [50,51]. ...
Rapid advances in education domain demand the design and customization of educational technologies for a large scale and variety of evolving requirements. Here, scale is the number of systems to be developed and variety stems from a diversified range of instructional designs such as varied goals, processes, content, teacher styles, learner styles and, also for eLearning Systems for 22 Indian Languages and variants. In this paper, we present a family of software product lines as an approach to address this challenge of modeling a family of instructional designs as well as a family of eLearning Systems and demonstrate it for the case of adult literacy in India (287 million learners). We present a multi-level product line that connects product lines at multiple levels of granularity in education domain. We then detail two concrete product lines (http://rice.iiit.ac.in), one that generates instructional design editors and two, which generates a family of eLearning Systems based on flexible instructional designs. Finally, we demonstrate our approach by generating eLearning Systems for Hindi and Telugu languages (both web and android versions), which led to significant cost savings of 29 person months for 9 eLearning Systems.
... Extensions to Koala for configuration definition and generation are provided by Koalish[2] and Kumbang[1]. ...
In system design, the distinction between a logical architecture at design level and the corresponding physical distributed architecture at implementation level is recognised as good practice. In this paper we show how we can define logical architectures in which variation points can be defined explicitly. Such architectures define families of systems, and should therefore be useful for defining such families in IoT.
... In one representation so called cardinalities were implemented which have to be understood as variables for distinct component occurrences [6,7]. So, the product model can be written as generic kind-of-model or class diagram known from programming and database design. ...
Planning multi-variant products in the early stage of the design process is still a challenge. In the present paper, a specification technique is introduced in order to define multi-variant products using degrees of freedom of shape attributes (in the following shape-DoFs) within the product structure. Our goal is to plan variety actively at the beginning of product development and not to describe variety by change of parameter values of the product's components as introduced in variant trees. Shape-DoFs are classified in the fields of shape attributes (dimension, position, shape as well as their combinations) on the one hand and mandatory or optional components on the other hand. Set up on this taxonomy graphical symbols are introduced to be used in product modeling. As application example, a welded pipe rack based upon the assembly structure modeling the product structure in this way is visualized in the first step. The second step is to translate the shape-DoFs into design parameters and identify relationships between them. The result is a parameter plan, as well as a configuration concept. Both can be seen as basis for CAD-modeling the product as design template which is the third step. In case of our example, Autodesk Inventor (without the ETO-Environment) is used to create the CAD-data. Discussing the effects of the proposed method, it will be shown that different shape-DoFs may cause various impacts in the whole product development process. Regarding these effects, scenarios can be performed in order to identify the cost and resource optimal variation possibilities of the product. In addition, it will be shown that different kinds of modularity according to PINE (e.g. cut-to-fit-modularity) can be predefined in the product model by using shape-DoFs
... La capacidad de cambio de un producto recibe el nombre de variabilidad y permite que un producto sea extendido, personalizado o configurado para su utilización en un cierto dominio [2]. ...
Resumen. El objetivo principal del trabajo es presentar el desarrollo de una arquitectura y su implementación en una aplicación prototipo que permite la utilización de una ontología de gestión de versiones para la integración y ges-tión unificada de variantes y versiones de Familias de Productos. Se propone un modelo de arquitectura compuesto de 3 módulos que se comunican entre sí cumpliendo funciones específicas, haciendo uso de diversas herramientas de la Web Semántica. La herramienta propuesta puede ser utilizada para lograr la gestión de la variabilidad en el tiempo y en el espacio de Familias de Producto en diversos tipos de industrias. En particular, en este artículo se introduce su aplicación, para la gestión de versiones y variantes, de una Familia de teléfonos celulares.
... Figure 6 shows a comparison between FX-MAN and component models that define parametrised architectural templates. These models include: ADLARS [6], MontiArch HV [18], ∆MontiArc [19], KobrA [5], Mae [30],Plastic Partial Components [28], xADL2 [13], Koala [35], Com [27], and Kumbang [4]. Some of these models do not define variation points explicitly, and express variability by other means. ...
... Figure 6 shows a comparison between FX-MAN and component models that define parametrised architectural templates. These models include: ADLARS [6], MontiArch HV [18], ΔMontiArc [19], KobrA [5], Mae [30],Plastic Partial Components [28], xADL2 [13], Koala [35], Com [27], and Kumbang [4]. Some of these models do not define variation points explicitly, and express variability by other means. ...
In software product line engineering, the construction of an ADL architecture for a product family is still an outstanding engineering challenge. An ADL architecture for a product family would define the architectures for all the products in the family, allowing engineers to reason at a higher level of abstraction. In this paper, we outline a component model that can be used to define architectures for product families, by incorporating explicit variation points.
... D'autres outils se sont concentrés sur le processus de création de produits. Ceux-ci sont qualifiés de configurateurs [AMS07] ; car ils permettent la création des configurations qui déterminent les produits. En fonction des choix successifs effectués par l'utilisateur, le configurateur va effectuer une série de déductions et ne présenter que les choix pertinents pour les points de variabilité suivants [BTRC05]. ...
The autonomic adaptation of software application is becoming increasingly important in many domains, including pervasive field. Indeed, the integration fo different application resources (physical devices, services and third party applications) often needs to be dynamic and should adapt rapidly and automatically to changes in the execution context. To that end, service-oriented components offer support for adaptation at the architectural level. However, they do not allow the formalisation of all the design constraints that must be guaranteed during the execution of the system. To overcome this limitation, this thesis modeled the design, deployment and runtime architectures. Also, it proposes to establish links between them and has developed algorithms to check the validity of an execution architecture with respect to its architectural design. This led us to consider the entire life cycle of components and to define a set of concepts to be included in architectures supporting variability. This formalisation can be exploited both by a human administrator and by an autonomic manager that has its knowledge base increased and structured. The implementation resulted in the realization of a knowledge base, providing a studio (Cilia IDE) for the design, deployment and supervision of dynamic applications, as well as an autonomic manager that can update the structure of pervasive applications. This thesis has been validated using a pervasive application called “Actimetry”, developed in the FUI~MEDICAL project.
... Extensions to Koala for configuration definition and generation are provided by Koalish[2] and Kumbang[1]. ...
In system design, the distinction between a logical architecture at design level and the corresponding physical distributed architecture at implementation level is recognised as good practice. In this paper we show how we can define logical architectures in which variation points can be defined explicitly. Such architectures define families of systems, and should therefore be useful for defining such families in IoT
... We have implemented a tool for our model, and we demonstrate its use on an example. Mae [28], Plastic Partial Components [26], xADL [13], Koala [33], Com [25], and Kumbang [3]. Some of these models define some variation points explicitly, i.e. as first-class entities; but none defines the full standard set that appears in feature models: Optional, Alternative (exclusive 'or'), and (inclusive) Or. ...
A Component Model for Defining Software Product Families with Explicit Variation Points.
Ontology-driven software engineering is the scope of the paper. A retrospective analysis of the approaches, models and methods is carried out. In the first section, a brief overview of "classical" technologies, approaches and methods for software engineering is presented. It is shown that the emphasis of research and development is currently shifting from the field of technologies of programming towards the modeling of the software design processes, as well as towards the specifications and testing of the developed systems. It is outlined that the general trend in the domain is the use of methods and tools of ontology modeling of both the design processes per se and the specifications of the developed systems. The second section is devoted to a review of publications in the field of ontology-based software engineering. Such paradigms for modeling software development processes as Software Product Lines, plug-and-play software development - Component-Based Development, model-driven software engineering - Model-Driven Engineering, etc. are discussed. It is shown that ― programming through generation‖, i.e. Generative Programming, is a general approach supporting the considered paradigms. It is shown that R&D in the domain of the semantic models of software engineering is currently focused on a new approach - Ontology-Based (-Driven) Software Engineering. Within the framework of this area, ontology engineering tools are developed along with modeling the software development processes. The scientific and technical perspectives of ontology driven software engineering are specified and discussed in the final part of the paper. In particular, it is outlined that the theoretical foundations of ontology-based modeling of software design processes form the solid basis for shifting the focus from the models of compiling the modules to their pattern-based generation from internal specifications. It is noted that the next trend in the field of OBSE-ODSE will be the usage of machine learning methods and tools to generate ontological models of software design.
Product Configuration Systems (PCS) are software applications supporting the design of products tailored to the individual desiderata of customers. PCS development does not follow the same procedure as traditional software: indeed, due to its nature, specific knowledge needs to be collected, a set of custom engineering stages have thus been built-up. Within these stages, special requirements representation and design artifacts are used notably to deal with features inter-dependencies. More specifically, the Product Variant Master (PVM) has been specifically created for PCS knowledge representation while Class-Responsibility-Collaboration (CRC) cards and a UML Class Diagram are often indispensable for PCS object-oriented design. PCS development projects have gradually started to use agile methods like the Scrum. This paper presents a process fragment for conducting PCS development projects with Scrum; it overviews how the development team of a specific organization adapted the agile process to the PCS context. This process fragment has indeed been built on the basis of practitioners knowledge collected through 5 qualitative interviews (inductive approach) and exhaustively depict the activities performed by the team on PCS development projects of various size and context. Because of the possibility to represent social (role) dependencies, the fragment is visually represented using an i* Strategic Rationale Diagram. The main contribution of the paper is the fragment itself, it is intended to be dynamically used as an initial guidance for PCS development teams willing to conduct projects using Scrum; it can be tailored to any project/sprint and enriched at will.
Ontology integration addresses the problem of reconciling into one single semantic framework different knowledge chunks defined according to its own ontology. This field has been subject of analysis and many consolidated theoretical results are available. Still, in practice, ontology integration is difficult in heterogeneous information systems (HIS) that need to integrate assets already built and running which cannot be changed. Furthermore, in practice, the composed assets are usually not really defined according to an ontology but to a data model which is less rigorous but fit for the purpose of defining a data schema. In this paper, we propose a method for integrating assets participating in a HIS using a domain ontology, aimed at finding an optimal balance between semantic rigour and feasibility in terms of adoption in a real-world setting. The method proposes the use of data models describing the semantics of existing assets; their analysis in order to find commonalities and misalignments; the definition of the domain ontology, considering also other sources as standards, to express the main concepts in the HIS domain; the connection of the local models with this domain ontology; and its abstraction into a metamodel to facilitate further extensions. The method is an outcome of a collaborative software development project, OpenReq, aimed at delivering an ontology for requirements engineering (RE) designed to serve as baseline for the data model of an open platform offering methods and techniques to the RE community. The construction process of this ontology will be used to illustrate the method.
The requirements for a system have many dependencies that can be expressed in the individual requirements managed in an issue tracker or a requirements management system. However, managing the entire body of requirements taking into account all complex dependencies is not well supported. We describe how a feature model based configurator can be used as a tool to help manage requirements data. Data transfer and constructing the needed requirements model can be carried out automatically by relying on a model generator. We implemented a prototype tool for requirements and release management that utilizes a knowledge-based configurator.
The results of a systematic literature review conducted for variability modelling in software component models
are analysed and presented in this article. A well-planned protocol guided the screening of 3230 papers that resulted in the
identification of 55 papers. Reviewing these papers, 23 of them were considered as primary studies related to our research
questions. A comparison framework is introduced to further understand, assess and compare those selected papers.
Observations about the important aspects of component models that support the variability capability are summarised.
Prominent trends and approaches are discussed along with a comparative analysis of the component models. Only a few
component models were found to be explicitly accommodating variability concerns. The identified variability modelling
problems require further research for attaining better reuse capabilities.
With the advent of Component-based software engineering (CBSE), large software systems are being built by integrating pre-built software components. The Semantic Web in association with CBSE has shown to offer powerful representation facilities and reasoning techniques to enhance and support querying, reasoning, discovery, etc. of software components. The goal of this paper is to research the applicability of Semantic Web technologies in performing the various tasks of CBSE and review the experimental results of the same in an easy and effective manner. To the best of our knowledge, this is the first study which provides an extensive review of the application of Semantic Web in CBSE from different perspectives. A systematic literature review of the Semantic Web approaches, employed for use in CBSE, reported from 2001 until 2015, is conducted in this research article. Empirical results have been drawn through the question-answer based analysis of the research, which clearly tells the year wise trend of the research articles, with the possible justification of the usage of Semantic Web technology and tools for a particular phase of CBSE. To conclude, gaps in the current research and potential future prospects have been discussed.
Software product line engineering is a plan-driven paradigm to produce varying software
products. Software product lines typically differentiate the products by their functionality.
However, customers may have different needs regarding performance, security, reliability, or
other quality attributes. Building a software product line that is able to efficiently produce
products with purposefully different quality attributes is a challenging task.
The aim in this dissertation was to study why and how to vary quality attributes purposefully
in a software product line. The study focused on two quality attributes, performance and
security. We conducted a systematic literature review on quality attribute variability,
conducted two case studies on performance variability, and constructed a design theory and
artifacts addressing security variability.
The results indicate that quality attributes can be purposefully varied to serve different
customer needs, to conduct price differentiation, and to better balance product and design
trade-offs. Additionally, quality attributes can be varied to adapt to varying operating
environment constraints. The quality attribute differences can be communicated to the
customers as observable product properties, as internal resources, or as the target operating
environments. In particular, security can be distinguished as countermeasures. In the product
line architecture, quality attribute differences can be designed through software or hardware
design tactics or by relying on indirect variation. Just designing the differences may not be
enough to ensure the product has given quality attributes, but the impact of other variability
may need to be handled at the product-line or product level.
Our contributions are as follows. Instead of focusing on how to represent quality attribute
variability, we focused on understanding the phenomenon of how specific quality attributes
vary. We identified several differences between performance and security variability, for
example, that security is more difficult to distinguish to the customers but more
straightforward to design and derive. We combined design and customer viewpoints: the
reason to vary and the means to communicate to the customers should be analyzed both from
the technical and non-technical viewpoints. Finally, we drew evidence-based generalizable
knowledge from the industrial context.
Context: Software product line engineering has proven to be an efficient paradigm to developing families of similar software systems at lower costs, in shorter time, and with higher quality.
Objective: This paper analyzes the literature on product lines from 1995 to 2014, identifying the most influential publications, the most researched topics, and how the interest in those topics has evolved along the way.
Method: Bibliographic data have been gathered from ISI Web of Science and Scopus. The data have been examined using two prominent bibliometric approaches: science mapping and performance analysis.
Results: According to the study carried out, (i) software architecture was the initial motor of research in SPL; (ii) work on systematic software reuse has been essential for the development of the area; and (iii) feature modeling has been the most important topic for the last fifteen years, having the best evolution behavior in terms of number of published papers and received citations.
Conclusion: Science mapping has been used to identify the main researched topics, the evolution of the interest in those topics and the relationships among topics. Performance analysis has been used to recognize the most influential papers, the journals and conferences that have published most papers, how numerous is the literature on product lines and what is its distribution over time.
La gestión del ciclo de vida de producto (PLM - Product Lifecycle Management) requiere un conjunto de soluciones para representar e integrar la información de una familia de producto. Las soluciones deben considerar los cambios en los requerimientos de los usuarios y del dominio, los cuales pueden ocurrir por diversas causas. Cada cambio modifica la información de producto, generando una nueva versión del mismo. Por lo tanto, la propuesta de este trabajo tiene por objetivo introducir un enfoque basado en ontologías para la gestión de versiones de información de familia de productos a lo largo de su ciclo de vida. Esta propuesta plantea conceptos generales para la captura y representación de los cambios, independientemente del modelo de productos utilizado para la representación de estas familias. Asimismo, se presenta la aplicación del modelo propuesto en dos modelos de productos diferentes: la ontología de productos PRONTO (PRoduct ONTOlogy) y el modelo de características (FM – Feature Model).
This chapter presents the various applications of a set of modular management variability tools (feature model script language for manipulation and automatic reasoning (FAMILIAR)) for different forms of architecture (component, service and plugin based), and at different stages of the software lifecycle, and discusses notions of software production lines (SPLs). It discusses three case studies where variability techniques seemed to be necessary: for different architecture types (component, service oriented and plugin based), for different objectives (re-engineering and development of extensible architecture, combinations in scientific workflows of configurable services, combinations of parametrizable algorithms in a pipeline), with particular problems (for example the need to integrate services originating from different suppliers and the need to integrate the architect's knowledge), and in three different fields (video surveillance, medical imaging and the FraSCAti open source project). The chapter concludes finally by taking some lessons from these studies and drawing some research prospects from them.
This chapter describes the technical means and methods for defining a reference architecture for a software product line. It presents the methods for operating this architecture through, for example, techniques emerging from model and software component engineering, or aspect-oriented programming. Then, the chapter illustrates these concepts and techniques using a case study. Product line engineering aims at rationalizing the development of a set of similar software applications by concentrating on the reuse of component kernel. The ultimate aim of this form of engineering is to improve productivity, i.e. to reduce the cost of development and time taken to put on the market and to increase quality. Variability management and the reference architecture are elements that are specific to the engineering of a product line. Particular attention must be given to them by any business that hopes to implement a software product line.
Planning multi-variant products in the early stage of the design process is still a challenge. In the present paper a specification technique is in-troduced in order to define multi-variant products using degrees of freedom of shape attributes (in the following shape-DoFs) within product structures. Our goal is to plan variety at the beginning of product development actively. Shape-DoFs are classified in the fields of shape attributes (dimension, position, shape as well as their combinations) on the one hand and mandatory or optional com-ponents on the other hand. Set up on this taxonomy graphical symbols are in-troduced for use in product modeling. As application example a pipe rack is modeled.
This article presents a generalized ontology of product configuration as a step towards a general ontology of config-uration, which is needed to reuse and share configuration knowledge. The ontology presented consists of a set of concepts for representing the knowledge on a configuration and the restrictions on possible configurations. The ontol-ogy is based on a synthesis of the main approaches to configuration. Earlier approaches are extended with new concepts arising from our practical experience on configurable products. The concepts include components, attributes, re-sources, ports, contexts, functions, constraints, and relations between these. The main contributions of this work are in the detailed conceptualization of knowledge on product structures and in extending the resource concept with contexts for limiting the availability and use of resources. In addition, constraint sets representing different views on the product are introduced. The ontology is compared with the previous work on configuration. It covers all the principal ap-proaches, that is, connection-based, structure-based, resource-based, and function-based approaches to configuration. The dependencies between the concepts arising from different conceptualizations are briefly analyzed. Several ways in which the ontology could be extended are pointed out.
The development and maintenance of product configuration systems is faced with increasing challenges caused by the growing complexity of the underlying knowledge bases. Effective knowledge acquisition is needed since the product and the corresponding configuration system have to be developed in parallel. In this paper, we show how to employ a standard design language (Unified Modeling Language, UML) for modeling configuration knowledge bases. The two constituent parts of the configuration model are the component model and a set of corresponding functional architectures defining which requirements can be imposed on the product. The conceptual configuration model is automatically translated into an executable logic representation. Using this representation we show how to employ model-based diagnosis techniques for debugging faulty configuration knowledge bases, detecting infeasible requirements, and for reconfiguring old configurations.
Product line software engineering (PLSE) is an emerging software engineering paradigm, which guides organizations toward the development of products from core assets rather than the development of products one by one from scratch. In order to develop highly reusable core assets, PLSE must have the ability to exploit commonality and manage variability among products from a domain perspective. Feature modeling is one of the most popular domain analysis techniques, which analyzes commonality and variability in a domain to develop highly reusable core assets for a product line. Various attempts have been made to extend and apply it to the development of software product lines. However, feature modeling can be difficult and time-consuming without a pre- cise understanding of the goals of feature modeling and the aid of practical guidelines. In this paper, we clarify the concept of features and the goals of fea- ture modeling, and provide practical guidelines for successful product line soft- ware engineering. The authors have extensively used feature modeling in sev- eral industrial product line projects and the guidelines described in this paper are based on these experiences.
Software product families are a means for increasing the ef- ficiency of software development. We propose a conceptualisation for modelling the evolution and variability of configurable software product families. We describe a first prototype of an intelligent tool that allows modelling a software product family on the basis of the conceptualisation and supports the user in interactively producing correct configurations with respect to the model. The implementation is based on an existing general purpose configurator and thus is not application domain specific. We use the Debian Familiar Linux package configuration task over many releases and package versions as an example. Preliminary results show that the conceptualisation can be used to model evolution of such a soft- ware product family relatively easily and the implementation performs acceptably.
An approach for modelling configurable software product families (CSPFs) and for automated configuring of product individuals using the models is presented. It is based on a similar approach for configuring physical products. The conceptual foundation and syntax of the Koalish modelling language used for this purpose are defined. The language extends Koala, a component model and architecture description language, with explicit variation modelling mecha- nisms. Koalish is further provided a formal semantics by defining a translation from it to Weight Constraint Rule Language (WCRL), a form of logic pro- grams. This allows using an existing inference tool for WCRL, smodels, to im- plement the reasoning needed in the configurator. The configurator is able to construct all valid product individuals, with respect to a Koalish model of a CSPF, that satisfy a given set of requirements. The implemented functionality of the configurator has been tested using small-scale toy examples, for which it performs adequately.
Software product lines (or system families) have achieved considerable adoption by the software industry. A software product
line captures the commonalities between a set of products while providing for the differences. Differences are managed by
delaying design decisions, thereby introducing variation points. The whole of variation points is typically referred to as
the variability of the software product line. Variability management is, however, not a trivial activity and several issues
exist, both in general as well as specific to individual phases in the lifecycle. This paper identifies and describes several
variability issues based on practical experiences and theoretical understanding of the problem domain.
A configurable software product family allows the deployment of individual products without customer-specific design or programming
effort. Despite the fact that such software product families have recently gained research interest, there are only few empirical
studies on them. This paper presents some results of a descriptive case study undertaken in two companies that develop and
deploy configurable software product families. The similarities found in comparisons between characteristics of the configurable
software product families were remarkable, although the companies, products, and application domains were different. The study
shows that the configurable software product family approach is already applied in the industry. Furthermore, the approach
seems to be a feasible and even efficient way to systematically develop a family of products and manage the variability within
it.
Reengineering a legacy product line has been addressed very little by current product line research activities. This paper
introduces a method to investigate feature dependencies and interactions, which restricts the variants that can be derived
from the legacy product line assets. Reorganizing the product line assets with respect to new requirements requires more knowledge
than what is easily provided by the classical feature-modeling approaches. Hence, adding all the feature dependencies and
interactions into the feature tree results in unreadable and unmanageable feature models that fail to achieve their original
goals.
We therefore propose two complementary views to represent the feature model. One view shows the hierarchical refinement of
features similar to common feature-modeling approaches in a feature tree. The second view describes what kind of dependencies
and interactions there are between various features.
We show two examples of feature dependencies and interactions in the context of an engine-control software product line, and
we demonstrate how our approach helps to define correct product configurations from product line variants.
Research over the past decade has revealed that modeling software architecture at the level of components and connectors is useful in a growing variety of contexts. This has led to the development of a plethora of notations for representing software architectures, each focusing on different aspects of the systems being modeled. In general, these notations have been developed without regard to reuse or extension. This makes the effort in adapting an existing notation to a new purpose commensurate with developing a new notation from scratch. To address this problem, we have developed an approach that allows for the rapid construction of new architecture description languages (ADLs). Our approach is unique because it encapsulates ADL features in modules that are composed to form ADLs. We achieve this by leveraging the extension mechanisms provided by XML and XML schemas. We have defined a set of generic, reusable ADL modules called xADL 2.0, useful as an ADL by itself, but also extensible to support new applications and domains. To support this extensibility, we have developed a set of reflective syntax-based tools that adapt to language changes automatically, as well as several semantically-aware tools that provide support for advanced features of xADL 2.0. We demonstrate the effectiveness, scalability, and flexibility of our approach through a diverse set of experiences. First, our approach has been applied in industrial contexts, modeling software architectures for aircraft software and spacecraft systems. Second, we show how xADL 2.0 can be extended to support the modeling features found in two different representations for modeling product-line architectures. Finally, we show how our infrastructure has been used to support its own development. The technical contribution of our infrastructure is augmented by several research contributions: the first decomposition of an architecture description language into modules, insights about how to develop new language modules and a process for integrating them, and insights about the roles of different kinds of tools in a modular ADL-based infrastructure.
Construction cost estimators are confronted with the challenging task of estimating the cost of constructing one of a kind facilities. They must first recognize the design conditions of the facility design that are important (i.e., incur a cost) and then determine how the design conditions affect the cost of construction. Current product models of facility designs explicitly represent components, attributes of components, and relationships between components. These designer-focused product models do not represent many of the cost-driving features of building product models, such as penetrations and component similarity. Previous research efforts identify many of the different features that affect construction costs, but they do not provide a formal and general way for practitioners to represent the features they care about according to their preferences. This paper presents the formal ontology we developed to represent construction knowledge about the cost-driving features of building product models. The ontology formalizes three classes of features, defines the attributes and functions of each feature type, and represents the relationships between the features explicitly. The descriptive semantics of the model allow estimators to represent their varied preferences for naming features, specifying features that result from component intersections and the similarity of components, and grouping features that affect a specific construction domain. A software prototype that implements the ontology enables estimators to transform designer-focused product models into estimator-focused, feature-based product models. Our tests show that estimators are able to generate and maintain cost estimates more accurately, consistently, and expeditiously with feature-based product models than with industry standard product models.
This article commences with an elaboration of models of design as a process. It then introduces and describes a knowledge representation schema for design called design prototypes. This schema supports the initiation and continuation of the act of designing. Design prototypes are shown to provide a suitable framework to distinguish routine, innovative and creative design
Research and experimentation in software architectures over the past decade (1992-2002) have yielded a plethora of software architecture description languages (ADLs). Continuing innovation indicates that it is reasonable to expect more new ADLs, or at least ADL features. This research process is impeded by the difficulty and cost associated with developing new notations. An architect in need of a unique set of modeling features must either develop a new architecture description language from scratch or undertake the daunting task of modifying an existing language. In either case, it is unavoidable that a significant effort will be expended in building or adapting tools to support the language. To remedy this situation, we have developed an infrastructure for the rapid development of new architecture description languages. Key aspects of the infrastructure are its XML-based modular extension mechanism, its base set of reusable and customizable architectural modeling constructs, and its equally important set of flexible support tools. The paper introduces the infrastructure and demonstrates its value in the context of several real-world applications.
Two trends have made reuse of embedded software for consumer electronics an urgent issue: the software of individual products becomes more and more complex, and the market demands a larger variety of products at an increasing rate. For that reason, various business groups within Philips organize their products as product families. A third trend is the integration of functions that until now were only found in separate products (e.g. a TV with Dolby Digital sound and a built-in DVD player). This requires software reuse between product families, which (when organized systematically), leads to a product population approach. We have set up such a product population approach, and applied it in various business groups within our organization. We use a component technology that stimulates context independence, and allows the composition of new products out of existing parts. We use an architectural description language to explicitly describe the architecture, and also to generate efficient bindings. We have aligned our development process and organization with the new 'compositional' way of working. The paper outlines our approach and reports on our experiences with it.
We have integrated the feature modeling of Feature-Oriented Domain
Analysis (FODA) into the processes and work products of the Reuse-Driven
Software Engineering Business (RSEB). The RSEB is a use case driven
systematic reuse process: architecture and reusable subsystems are first
described by use cases and then transformed into object models that are
traceable to these use cases. Variability in the RSEB is captured by
structuring use case and object models using explicit variation points
and variants. Traditional domain engineering steps have been distributed
into the steps of the architectural and component system development
methods of the RSEB. But the RSEB prescribes no explicit models of the
essential features that characterize the different versions. Building on
our experience in applying FODA and RSEB to the telecom domain, we have
added explicit domain engineering steps and an explicit feature model to
the RSEB to support domain engineering and component reuse. These
additions provide an effective reuse oriented model as a `catalog'
capability to link use cases, variation points, reusable components and
configured applications
Modern communications equipment is highly modular and can scale to
a wide range of applications. Usually, the equipment's cost and
complexity requires that it be manufactured to order, or at least
assembled-to-order. In this context, orders double as specifications,
describing what should be manufactured as well as how the product should
be installed. Producing a correct and complete order for such equipment
can be challenging when requirements are incomplete, inconsistent, or
when the final product is large and complicated. A good order is
technically correct and meets customer requirements for network capacity
and growth without over-engineering. Incomplete configurations can lead
to cost overruns if the missing elements are discovered during
manufacturing. If they are not, faulty products can result. Either way,
the customers are unhappy. We have tackled the configuration problem for
a number of large telecommunications products. Our Prose configurators
are based on CLASSIC, a description logic-based knowledge representation
system. We have found it to be well suited to our configurator needs.
Because it attempts to provide predictable performance in all cases,
CLASSIC is less expressive than many description logic systems, but it
has been widely used in both industrial applications and academic
systems. Some of our configurators have been in use since 1990. They
have processed more than $4.5 billion in orders and have documented many
benefits, including reduced order processing time, reduced staffing, and
product-knowledge consistency checking
Software product families are an emerging trend that tries to cope with increasing variability and challenges of reuse. Software products are derived from the family in a prescribed way utilising common family assets. The derived product often includes some amount of integrating glue code or even product-specific tailoring. In the domain of traditional, mechanical products, configurable products have been developed. Individual products are configured according to a predefined model, with no need for adaptive or innovative design. When comparing these two approaches, remarkable similarities are found. In a configurable software product family, software products are configured based on a prede-fined configuration model. Building the product usually requires no product-specific programming. The purpose of this thesis was to develop a tool for deriving product individuals from configurable software product families. This tool, called Kumbang Configurator, utilises existing modelling language Kumbang, which combines both feature-based and architecture-based modelling methods. Kumbang Configurator prevents configu-ration errors by checking whether the configuration is consistent and complete. This configuration reasoning employs inference engine smodels. The implementation was validated with two example cases.
s adequate at the level of architecture and what types of formal methods are best suited for the needs of architecture modeling. 6. CONCLUSIONS Software architectures show great potential for reducing development costs while improving the quality of the resulting software. However, this potential cannot be fulfilled simply by explicitly focusing on architectures, just like a new programming language cannot by itself solve the problems of software engineering. A programming language is only a tool that allows (but does not force) developers to put sound software engineering principles and techniques into practice. Similarly, one can think of software architectures as tools that also must be supported with specific techniques to achieve desired properties. As is typically the case with tools, software architectures are much better suited to solving some types of problems than others. Understanding the types of problems to which architectures can be applied most effectiv
Variability is the ability of a system to be efficiently extended, changed, customised or configured for use in a particular context. There is an ever-growing demand for variability of software. Software product families are an important means for implementing software variability. A software product family may contain very large numbers of individual products. Consequently, methods for representing the variability and efficiently reasoning about it are needed. This thesis studies such methods: the goal of the thesis is to define a solid conceptual basis for modelling the variability in software product fami-lies, and to provide the concepts formal semantics in such a way that reasoning on the models is possible using existing inference tools. Major parts of the work have already been completed and documented in a number of publica-tions.
Car Periphery Supervision (CPS) systems comprise a family of automotive systems that are based on sensors installed around the vehicle to monitor its environment. The measurement and evaluation of sensor data enables the realization of several kinds of higher level applications such as parking assistance or blind spot detection. Although a lot of similarity can be identified among CPS applications, these systems are traditionally built separately. Usually, each single system is built with its own electronic control unit, and it is likely that the application software is bound to the controller's hardware. Current systems engineering therefore often leads to a large number of inflexible, dedicated systems in the automobile that together consume a large amount of power, weight, and installation space and produce high manufacturing and maintenance costs. This paper reports on an initiative undertaken by the Bosch Group in applying a product line development approach to develop CPS systems economically. Product line development represents a multi-system engineering approach which takes common and variable aspects between systems in the same application domain into account. It provides a basis to develop a line of products economically based on a common system architecture and reusable components.
Software Product Lines are characterized through common and variable parts. Modeling variability is one of the most important
tasks during the analysis phase. Domain analysis and requirements elicitation will bring up a huge amount of requirements
and dependencies between product characteristics. Feature modeling is one approach to deal with complexity in expressing several
requirements in features and structure them hierarchically in feature diagrams. Unfortunately the requirements and feature
models become very complex as well. An adequate tool support is needed to manage the feature models and to support the linkage
to requirements. Our research group has developed a prototype of a requirements engineering tool that supports the requirements
engineering process for software product lines.
A novel logic program like language, weight constraint rules, is developed for answer set programming purposes. It generalizes normal logic programs by allowing weight constraints in place of literals to represent, e.g., cardinality and resource constraints and by providing optimization capabilities. A declarative semantics is developed which extends the stable model semantics of normal programs. The computational complexity of the language is shown to be similar to that of normal programs under the stable model semantics. A simple embedding of general weight constraint rules to a small subclass of the language called basic constraint rules is devised. An implementation of the language, the smodels system, is developed based on this embedding. It uses a two level architecture consisting of a front-end and a kernel language implementation. The front-end allows restricted use of variables and functions and compiles general weight constraint rules to basic constraint rules. A major part of the work is the development of an efficient search procedure for computing stable models for this kernel language. The procedure is compared with and empirically tested against satisfiability checkers and an implementation of the stable model semantics. It offers a competitive implementation of the stable model semantics for normal programs and attractive performance for problems where the new types of rules provide a compact representation.
In order to enable a smooth transition to product line development for an organization that so far only performed single system development, it is necessary to keep as many of the existing notations and approaches in place as possible.This requires adaptability of the basic variability management approach to the specific situation at hand. In this paper we describe an approach that enables homogenous variability management across the different lifecycle stages, independent of the specific notation. The approach is accompanied by a meta-model and a process for introducing the variability management approach by developing a notation-independent representation. This approach has so far been applied in several cases where our Product Line engineering method PuLSE™ has been introduced into a software development organization.
Most solutions for introducing variability in a software system are singular: they support one particular point in the software life cycle at which variability can be resolved to select a specific instance of the system. The presence of significantly increased and dissimilar levels of variability in today’s software systems requires a flexible approach that supports selection of a system instance at any point in the life cycle—from statically at design time to dynamically at run time. This paper introduces our approach to supporting any-time variability, an approach based on the ubiquitous use of a product line architecture as the organizing abstraction throughout the lifetime of a software system. The product line architecture specifies the variabilities in a system, both in terms of space (captured as explicit variation points) and time (captured as explicit versions of architectural elements). A system instance can be selected at any point in time by providing a set of desired features, expressed as name–value pairs, to an automated selector tool. We introduce our overall approach, discuss our representation and tools for expressing and managing variability, and demonstrate their use with three representative examples of any-time variability.
Physical products come in many variants, and so does the software embedded in them. The software embedded in a product variant
usually has to be optimized to fit its limited memory and computing power. Generative programming is well suited for developing
embedded software since it allows us to automatically produce variants of embedded software optimized for specific products.
This paper reports on our experience in applying generative programming in the embedded domain. We propose an extended feature
modeling notation, discuss tool support for feature modeling, describe a domain-independent system configuration editor, and
comment on the applicability of static configuration in the area of embedded systems.
Software product lines aim at providing the means for achieving large software variability in an effective manner. However, systematic methods and tools are needed for describing and managing the variability so that large variability can be supported and an effective means for deriving product instances can be achieved.
A feature model captures the stakeholder-visible aspects and characteristics of a product line. By revealing a product line’s
inherent commonalities and variabilities, it acts as a key driver in the creation of core assets. Usability and usefulness,
however, are important qualities for a feature model to possess in order to fulfill its role. In our opinion, these qualities
can be ensured by building upon an adequate meta-model. The purpose of this article is to describe an extended meta-model
for feature modeling. Meta-model elements, such as features and inter-feature relations, are presented in detail. We propose
automated model analysis as the way of extracting information encapsulated in a feature model: algorithms are suggested for
the identification of the commonality and variability in the modeled product line and for the automated consistency checking
of products.
Abstract Feature modeling is a key technique for capturing commonalities and variabilities in system families and product lines. In this paper, we propose a cardinality-based notation for feature modeling, which integrates a number of existing extensions of previous approaches. We then introduce and motivate the novel concept of staged configuration. Staged configuration can be achieved by the stepwise specialization of feature models or by multi-level configuration, where the configuration choices available in each stage are defined by separate feature models. Staged configuration is important because in a realistic development process, different groups and different people make product configuration choices in different stages. Finally, we also discuss how multi-level configuration avoids a breakdown,between the different abstraction levels of individual features. This problem, sometimes referred to as “analysis paralysis”, easily occurs in feature modeling because features can denote entities at arbitrary levels of abstractions within a system family. Key words: Software product lines, system families, domain analysis, software configuration
Configurable software product families are a subclass of software product families that are customized in a product individual derivation process without design or programming. This article presents results on analyzing two such families and their derivation processes found in a descriptive case study on software product families. Some characteristics particular to such product families and their derivation seem to emerge: There is a configurable product base that is configured to the customer requirements. The variability has two distinct levels, of which the first is visible to the customer at sales. The derivation process consists of requirements specification, configuring, delivery, installing, and tailoring activities. Derivation is very flexible and efficient. Most derivations can be carried out without programming. The activities primarily require application domain understanding, system administrator skills, and understanding of the family. The product developers can be separated organizationally from product derivators. We further proposed some hypotheses on the success factors for configurable software product families: A large enough number of derivations, understanding and stability of the application domain, and clear software product family – oriented culture and processes. However, very advanced or software product family–oriented software engineering methods or similar methods do not seem a prerequisite for success. We also suggest further research on configurable software product families.
In configuration design parts are selected and
connected to meet customer specifications and engineering
and physical constraints. Specifications include preferences
(e.g., “prefer lower cost to higher performance,
all things being equal”), bounds on various resources
(e.g., “the computer should have four PCI slots”),
and other information to customize a configuration. Constraints
typically arise from exogenous concerns, such as the available
parts, the way parts can interact, and the manufacturing
plant.
The configuration task is commonly defined as composing a complex product from a set of predefined component types while taking into account a set of well-defined restrictions on how components belonging to these types can be combined. Configuration, always a successful artificial intelligence (AI) application area ever since the R1/XCON system of the early 1980s, has recently attracted renewed research interest. This is also demonstrated by an annual series of workshops on configuration that have been held at the AAAI, ECAI, and IJCAI conferences since 1999. Important real-world industrial configuration tasks are encountered in marketing, manufacturing, and design. They usually involve physical products, such as telecommunication switches, computers, elevators, large diesel engines, automation systems, or vehicles (some of which appear as application domains in the articles in this issue), but can also pertain to financial or other services or software.
Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement
for achieving successful software reuse. By examining a class/family of related systems and the commonality underlying those
systems, it is possible to obtain a set of reference models, i.e., software architectures and components needed for implementing
applications in the class. FORM (Feature-;Oriented Reuse Method) supports development of such reusable architectures and components
(through a process called the “domain engineering”) and development of applications using the domain artifacts produced from
the domain engineering. FORM starts with an analysis of commonality among applications in a particular domain in terms of
services, operating environments, domain technologies, and implementation techniques. The model constructed during the analysis
is called a “feature” model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and
OR nodes indicate alternative features selectable for different applications. Then, this model is used to define parameterized
reference architectures and appropriate reusable components instantiatable during application development. Architectures are
defined from three different viewpoints (subsystem, process, and module) and have intimate association with the features.
The subsystem architecture is used to package service features and allocate them to different computers in a distributed environment.
Each subsystem is further decomposed into processes considering the operating environment features. Modules are defined based
on the features on domain technology and implementation techniques. These architecture models that represent an architecture
at different levels of abstraction are derived from the feature hierarchy captured in the feature model. Modules serve as
basis for creating reusable components, and their specification defines how they are integrated into the application (e.g.,
as-;is integration of pre-;coded component, instantiation of parameterized templates, and filling-;in skeletal codes). Our
experiences have shown that for the electronic bulletin board and the private branch exchange (PBX) domains, “features” make
up for a common domain language and the main communication medium among application users and developers. Thus, the feature
model well represents a “decision space” of software development, and is a good starting point for identifying candidate reusable
components.
Software architecture has received much attention in the past few years. This is not a block diagram that gives a rough functional decomposition of the system. It is a multiperspective, quality-based approach to ensuring that software is built to fit its purpose. In this edition of Strategic Software Engineering we will consider how software architecture provides strategic support to the organization.
In a variety of approaches to software development, software artefacts are used in multiple contexts or for various purposes. The differences lead to so-called variation points in the software artefact. During recent years, the amount of variability supported by a software artefact is growing considerably, and its management is developing as a main challenge in the development, usage, and evolution of software artefacts. Areas where the management of variability is evolving as a challenge include software product families [1], component-based software development, object-oriented frameworks, and configurable software products such as planning systems for enterprise resources. For example, in a typical software product family, the number of variation points may easily range in the thousands.
The ICDE system is a platform for capturing and disseminating information that can be used in different application domains.
However, like any generically applicable horizontal technology, its broad appeal is both a strength and weakness. The weakness
stems from the fact that a user organization will need to tailor the technology to suit its application domain (e.g., finance),
and make it easy for their users to learn and exploit. This takes time and money, and is hence a disincentive to adoption.
Feature models are used to specify members of a product-line. Despite years of progress, contemporary tools provide limited support for fea- ture constraints and offer little or no support for debugging feature models. We integrate prior results to connect feature models, grammars, and propositional formulas. This connection allows arbitrary propositional constraints to be defined among features and enables off-the-shelf satisfiability solvers to debug feature models. We also show how our ideas can generalize recent results on the staged configuration of feature models.
During recent years, the amount of variability that has to be supported by a software artefact is growing considerably and its management is evolving into a major challenge during development, usage, and evolution of software artefacts. Successful management of variability in software leads to better customizable software products that are in turn likely to result in higher market success. The aim of this paper is to present software variability management both from a 'problems' and from a 'solutions' perspective by discussing experiences from industrial practice and from applied research in academia. Issues that are addressed include, but are not limited to, technological, process, and organizational aspects as well as notation, assessment, design, and evolution aspects.
During recent years, the amount of variability that has to be supported by a software artifact is growing considerably and its management is developing as a main challenge during development, usage, and evolution of software artifacts. Successful management of variability in software artifacts leads to better customizable software products that are in turn likely to result in higher market success. The aim of this workshop is to study software variability management both from a 'problems' and from a 'solutions' perspective by bringing together people from industrial practice and from applied research in academia to present and discuss their respective experience. Issues to be addressed include, but are not limited to, technological, process, and organizational aspects as well as notation, assessment, design, and evolution aspects.
The authors used generative constraint satisfaction as the basis
for Lava, an automated configuration they developed for the complex
domain of telephone switching systems. They built Lava using Cocos,
their knowledge-based configuration tool
Work is underway to enhance SAP's R/3 business software suite with
a sales configuration engine. With the SCE, which is out in a beta
version to select customers, users will be able to deal with
configurable products on either a laptop or attached to R/3. The author
gives an outlook on the general problem of adding a sales configurator
to SAP's R/3 business software suite and outline specific work to
provide enhanced high-level configuration capabilities in the SCE. The
SCE represents the third generation of sales configuration at SAP. It is
implemented in Java, and, in its present form, runs on a standalone
machine, such as a laptop. It will be an integral part of SAP's
Sales-Force-Automation tool and plans are to reembed it into R/3