decisionking: a flexible and extensible tool for integrated variability modeling
TRANSCRIPT
DecisionKing: A Flexible and Extensible Tool for Integrated Variability Modeling
Deepak Dhungana Paul Grünbacher Rick Rabiser
Christian Doppler Laboratory for Automated Software Engineering Johannes Kepler University
4040 Linz, Austria
Abstract
Variability modeling is at the heart of product line engineering. Variability models entail features and architectural elements, technical customization as-pects, sales and marketing decisions, as well as com-plex traceability information. In this paper we describe DecisionKing, a variability modeling tool that offers a great degree of flexibility and extensibility and allows the creation of variability modeling tools for different domains and organizations. The tool is part of the DOPLER approach (Decision-Oriented Product Line Engineering for Effective Reuse) developed in an in-dustrial research cooperation with Siemens VAI. We report on ongoing tool development and present ex-periences of using DecisionKing.
1. Introduction
Complex software-intensive systems are typically not developed for a single customer [12]. Instead, a product line approach is pursued to increase productiv-ity and reduce time-to-market by fostering the reuse of software assets [19]. Variability modeling is at the heart of Product Line Engineering (PLE) and required for enabling reuse on different levels of granularity and abstraction. Variability modeling is a complex task due to the diversity of core assets and complex inter-dependencies among them. Although various tools and techniques are already available, it remains a big chal-lenge to define a variability modeling approach suit-able for a particular domain or organization. Flexible and extensible ways for capturing and sharing variabil-ity models are thus needed to exploit the enormous potential of product line engineering [8].
In our ongoing research project in cooperation with Siemens VAI – the world’s leading engineering and plant-building company for the iron, steel, and alumi-num industries – we have been experimenting with
different variability modeling techniques and tools in the domain of automation software for continuous casting technology in steel plants. Based on our ex-periences we see two major problems regarding vari-ability modeling: (i) there is a lack of integrated ap-proaches that work well with largely heterogeneous artifacts in different domains and product lines; (ii) there is a lack of flexible and extensible tools that can easily be tailored to diverse organizational needs. More specifically, we have been facing several issues in our industrial research collaboration:
Weak support for domain specific adaptations: Dif-ferent domains are characterized by different types of assets and domain-specific dependencies between these assets. Current variability modeling tools do not provide the full flexibility needed to deal with a flexi-ble set of asset types, attributes, and domain-specific dependencies. They often assume a certain meta-model while real-world product lines require the definition of domain specific meta-models for variability modeling.
Limited support for traceability and integrated PLE: When dealing with assets at different levels of abstraction, the traceability between these levels needs to be properly understood and managed [13]. Existing tools often emphasize one particular level of abstrac-tion or a specific notation. For example, there are nu-merous tools available for feature modeling and sev-eral tools for modeling product line architectures. However, when trying to integrate such tools one finds that establishing traceability between them is hard. A typical traceability problem is that the external vari-ability, i.e., the decisions taken by customers/sales, are often only weakly integrated with internal variability, i.e., decisions taken by engineers [9].
Limited extension mechanisms: It is often difficult to add company-specific extensions to existing product line tools due to a lack of extension mechanisms. An example of such an extension is a plug-in we have de-veloped for our industry partner. This plug-in auto-
matically creates an initial product line architecture model by analyzing configuration files of existing sys-tems. However, adding such an external capability to existing variability modeling tools can be a big burden.
Inadequate support for multi-team modeling: The size and complexity of many software-intensive sys-tems makes it impossible for single developers or small teams to understand the complete variability model as the knowledge required for creating and evolving vari-ability models is distributed among numerous hetero-geneous stakeholders [8] [10]. Existing tools provide only little support for multi-team modeling.
Weak integration with sales processes: A variability model guides the product derivation and configuration process as it links the external variability such as sales and marketing decisions with the internal customiza-tion decisions. Current tools do not provide integrated support for non-technicians using a variability model in product derivation and customization [21].
Weak support for evolution: A variability model has to change over time as the product line assets are con-stantly evolving. For example, changes in the architec-ture can make the variability model inconsistent with the technical solution. Supporting the evolution of variability models to reflect changes in the asset base is success-critical for product line engineering. Existing tools often do not provide automated mechanisms for detecting changes in the assets and potentially outdated elements in the variability models. This issue is even more complicated in multi-team modeling environ-ments.
In our ongoing research collaboration with Siemens VAI we aim at addressing these issues by implement-ing the DOPLER approach. This approach consists of two parts: DOPLERVM (variability modeling) and DO-PLERUCon (User-centered Configuration [22]). This paper gives an overview on the tool aspects of DOPLERVM and is structured as follows: In Section 2 we give an overview of existing product line tools and techniques related to our approach. Section 3 presents our decision-oriented variability modeling approach. Section 4 discusses the modeling capabilities of Deci-sionKing. Section 5 presents the variability mecha-nisms of DecisionKing that make it flexible and exten-sible. Section 6 rounds out this paper with a conclusion and an outlook on further work.
2. Related Work
Various modeling approaches and tools exist that deal with variability on different levels such as re-quirements, design, architecture, implementation, ap-plication, and runtime.
2.1 Modeling approaches
Feature models are widely used for modeling vari-ability on the requirements level. FODA is a well-known notation [16]. Researchers have also been pro-posing variability modeling approaches that focus on the architecture level. Several extensions of architec-ture description languages such as xADL [7] or Ko-ala [3] allow the definition of variants, versions, or optional elements in product line architectures.
Other authors have proposed orthogonal approaches to variability modeling [4]. For instance, Bachmann et al. [4] propose a conceptual model of variation to rep-resent variability in product family development. In their approach, a variation point represents an explicit engineering decision to allow for several alternative variants with regard to selected assets of system devel-opment. The authors differentiate between assets and artifacts; an asset is considered as a package of rele-vant artifacts providing a solution to a given problem. Schmid and John [15] describe a customizable ap-proach to variability management which is independ-ent from specific notations. Their approach is based on decision models which are built by specifying decision variables and constraints between them.
Approaches have also been published that combine existing mechanisms or extend them with new con-cepts. For example, Mezini et al. [17] combine feature-oriented with aspect-oriented programming in order to overcome deficiencies of a solely feature-based ap-proach. Berg et al. [5] propose a unified approach for variability management focusing on traceability of variation across artifacts.
Several authors have investigated the dependencies among different types of artifacts in product line mod-els. For instance, Thiel et al. [23] present an approach for systematically and continuously incorporating and refining variability during core asset development. During the development process designers are in-structed to explicitly map features to architectural variation points and capture those mappings in the product line model.
2.2 Tools
Numerous tools have been proposed to support product line engineers. Here we describe just a few tools for the sake of brevity.
FeaturePlugin [6] [2] is a feature modeling plug-in for Eclipse. It supports cardinality-based feature mod-eling, specialization of feature diagrams, and configu-ration based on feature diagrams. The meta-model of FeaturePlugin can be extended to associate additional
attributes to features, such as priorities, binding times, or implementation status.
Varmod1 by the University of Duisburg-Essen sup-ports the specification of product line variability mod-els based on an orthogonal variability meta-model de-scribed in the OVM-notation.
pure::variants by pure-systems GmbH is a variant and variability management tool for managing soft-ware product lines [20]. It is based on two modeling concepts: feature models and family models. The vari-ability and commonality of a product line is captured in feature models whereas asset modeling is supported by family models describing the software in terms of architectural elements. The family model is extensible; however no specialization hierarchy for the model ele-ments is supported. Components, which are the basic constituents of the family model, can be hierarchically decomposed into further components or into “part ele-ments” that in turn are built from “source elements”. No explicit support is provided to model domain-specific asset types such as hardware resources, data models, development process guidance, libraries, etc.
Gears [18] by Big Lever Software Inc. is a devel-opment environment for maintaining product family artifacts and variability models. Variability is handled at the level of files and captured in terms of features, product family artifacts, and defined products that can be derived from the variability model. The tool sup-ports the identification of common and variable source code files.
3. Integrated Variability Modeling
We have been developing the integrated DOPLERVM approach for variability modeling in co-operation with our industry partner Siemens VAI based on existing research on variability modeling [5] [15] [19]. Figure 1 gives an overview: Variability models are based on the definition of a domain model, i.e., a meta-model specifying the building-blocks for asset models and decision models.
Figure 1: DOPLERVM Overview
The domain meta-model captures domain-specific
asset types and the required types of interdependencies
1 http://www.sse.uni-essen.de/swpl/SEGOS-VM-Tool
(see Section 5.1). Asset models describe existing assets in the product line together with trace links specifying their dependencies. The decision model covers exter-nal and internal variability together with links to the assets (cf. Figure 2).
3.1 Asset and Decision Modeling
DOPLERVM is based on a simple and extensible meta-model which captures the variability of and de-pendencies between assets like features, architectural elements, resources, etc. Assets and decisions represent the main modeling elements (see Figure 2). Users can define new asset types to reflect the specifics of a par-ticular product line. Variation points are captured as decisions and the dependencies among assets and deci-sions are explicitly modeled [11].
Figure 2: Core meta-model [11]
Assets are artifacts that are intended to be part of the
product line. In the case of Siemens VAI we defined asset types for components, documentation, resources, and properties. We distinguish between structural de-pendencies and functional dependencies between as-sets. Whenever an asset is part of another asset or con-tributes in some way to its existence, we refer to it as structural dependency. For example, components have a structural dependency to the subsystem they belong to. Whenever an asset requires another asset in order to be useful we model a functional dependency. This is the case, e.g., when a component serves as input for another component.
Any user intervention that is needed to choose the required assets for a concrete product is a decision. Decisions can be seen as variation points in the asset model. Some decisions need to be taken by customers or sales staff while others are taken by engineers. De-cisions can be linked with each other in two ways: Some decisions are only relevant when taken in a certain order. The hierarchical dependency specifies how the decisions are organized. For example, the user needs to decide if an archiving feature is required, be-fore taking more specific decisions on the type of da-tabase used for archiving. The known consequences of taking decisions are expressed as logical dependencies. Typically, these are business rules that need to be
these are business rules that need to be checked before and after a decision is taken. In order to link assets and decisions, assets specify an inclusion condition which has to be satisfied for a particular asset to be included in the final product. Such a condition is a Boolean ex-pression that can be composed of an arbitrary combi-nation of decisions. These conditions allow the map-ping of user demands to assets. Using decisions and inclusion conditions allows establishing traceability links.
An asset model is based on the domain specific meta-model and consists of concrete assets which be-long to a concrete asset type. Relationships between different asset types are modeled explicitly and repre-sent qualified trace links that are consistent with the meta-model. The traceability information in the models becomes of great value as soon as the variability mod-els are used for product derivation.
3.2 Example
The example depicted in Figure 3 contains three dif-ferent sections of the variability model (i.e., asset mod-els for components, resources, and properties) for Sie-mens VAI’s Runout subsystem of their continuous casting automation software. Each asset specifies an inclusion condition determining when it is part of the derived product.
MetaModel = “vai”; References{ L1ConnectionManager, MarkingMachine} Assets{ Resource RunoutServer{ IncludedIf = (deburrer!=null); } Resource RunoutPropertiesFile{ IncludedIf = (deburrer!=null && l1Link==false); } public Component SensorContainer { Requires { L1ConnectionManager } ContributesTo{RunoutServer} IncludedIf = (deburrerConnectionToL1 && ! weighingMachine); } Component DeburrerDriver{ Requires {SensorContainer} ContributesTo{ RunoutServer } IncludedIf = (deburrer!=null); } Component MarkingNumberHandler{ Requires {MarkingMachine} ContributesTo{ RunoutServer } . . . } Property propMarkingPredecessor{ Key = “...runout.marking.predecessor”; Value = markingPredecessor; ContributesTo{ RunoutPropertiesFile } . . . . } . . . . }
Figure 3: Partial Asset Model of the Runout Subsystem
(XML-tags removed for better legibility)
For example, the Component SensorContainer will only be included in the product if there is a deburrer connection to level 1 and no weighing machine is needed in the plant. These conditions are defined itera-tively while creating the decision model as they refer to the variables defined in the decision model (cf. the Boolean decision deburrerConnectionToL1 in the de-cision model in Figure 4).
An asset model can be created semi-automatically by analyzing the existing asset base. For example, call dependencies as defined in existing system configura-tion files can be utilized to automatically derive re-quires dependencies among assets. When creating dif-ferent asset models, one has to make sure that the as-sets are linked to each other based on the technical restrictions they underlie. In the Siemens VAI case this is ensured by a tool importing Spring XML2 system configuration files.
References{l1Link, logHMIInput, weighingMachine} Decisions{ Group Sales{ public Boolean deburrer{ Question = “Do you need a deburrer?”; Visibility = true; } Boolean deburrerConnectionToL1{ Question = “Is there a connection to the deburrer via the L1 link?”; Visibility = deburrer && l1Link; } public String markingPredecessor{ Question = “What is the predecessor
of the marking machine?”; Visibility = deburrer!=null &&
weighing != null; Constraint = if(markingPredecessor !=
“input”, weighingMachine:=false) }
}
Figure 4: Partial Decision Model of the Runout Subsystem
After creating asset models, decisions that need to
be taken in order to select the required assets for a con-crete product are modeled in a decision model (see Fig. 4). Dependencies among decisions are for exam-ple informed by the marketing and release strategy of an organization. They are however also the result of technical restrictions. Adding inclusion conditions to the assets in the asset model is an important part of decision modeling. For example, the component De-burrerDriver will only be included if a user has de-cided to include a deburrer.
4. Variability Modeling with DecisionKing
We have been developing the DecisionKing tool to support our integrated modeling approach. Decision-King is an application based on the Eclipse platform.
2 http://www.springframework.org/
The tool has been implemented in a highly iterative process with continuous feedback from Siemens VAI engineers. Early versions of our modeling approach were tested using prototypes built with MS Excel.
The suitability, adequacy, and usability of the ap-proach have been tested by engineers of Siemens VAI, who have been using the tool to create variability mod-els for different subsystems of the caster automation software.
Figure 5 shows a snapshot of the modeling shell in DecisionKing. Decisions described in Figure 4 are listed in the left pane. The right pane shows a decision viewer graphically visualizing dependencies among decisions. There are different tabs allowing to import and capture assets into the product line (see Figure 3). For example, the Component tab allows to import components from existing configurations and to spec-ify the links to the decision model. The Document tab is used to organize fragments of the documentation.
Complex relationships between decisions and as-sets are expressed in a simple rule language. We are currently using a self-developed engine which will be replaced in the near future with an off-the-shelf engine to ensure scalability.
4.1 Multi-team modeling support
Feedback from our industry partner shows that the modeling approach works well for capturing variability both from customer/marketing as well as from techni-cal perspectives, but it is unrealistic to assume that such a model can be created and evolved by an indi-vidual or by a small team. The knowledge required to build such a model is typically spread across the minds of numerous heterogeneous stakeholders and different teams responsible for various parts of the system [10].
DecisionKing allows modeling different parts of a large variability model separately and merging the parts into one integrated model later on (see Figure 6). For this purpose, one team may only build the asset model, or even only a partial asset model or decision model. The different parts of the model are then merged using the model merger.
Engineers can mark certain elements in the vari-ability model as “public” meaning that these can be used in other variability models. Other elements are listed as references. A team of stakeholders responsible for a certain variability model can refer to elements of other variability models (even without explicitly stat-
Figure 5: Editing a Decision model in DecisionKing
ing the source to allow a greater degree of flexibility). Engineers then use a model merger matching the refer-ences and exported elements of different models based on name and type to create a complete variability model. Whenever there isn’t enough information available for automatic matching of the elements the model merger relies on the user to resolve issues oc-curring during the merging process.
Figure 6: Merging of variability models using a merger is based on element types and names
In the example depicted in Figure 6, two parts of a
variability model are shown. Model 1 imports DBProcessDisplay, a component defined public in model 2. Similarly model 2 refers to the FileManager component, which is set public by model 1. The vari-ability model merger can combine the two models by resolving these references.
Many problems can occur while merging different models, for example – missing references, multiple occurrences of the same element, or ambiguity in the mapping of referenced elements. When conflicts can-not be resolved automatically our merger relies on in-put from the user.
4.2 Model differencing and evolution
Support for evolution is essential in product line engineering. For instance, it can take more than one year to deploy a steel plant to a customer at Siemens VAI due to the complexity of such projects. The deri-vation of the software within this project is therefore a fairly long process. This means that even during prod-uct derivation the assets (e.g., components and docu-mentation) evolve continuously, e.g., due to updates and changes from other projects at Siemens VAI. The company deploys 20-30 products per year.
It is essential to ensure the consistency of a vari-ability model with the asset base under such circum-stances. The evolution of the architecture and other changes in the asset base can make the variability model invalid. Variability models may change even during a project, just like in the case of our industry
partner. DecisionKing therefore supports comparison of variability models to detect changes automatically. For this purpose, we are currently experimenting with different tree differencing algorithms that can detect changes in variability models. Currently we are ex-perimenting with THP and MDIR algorithms [1]. THP does not detect moves and does not support forc-ing/preventing matches. However, THP is faster than MDIR at detecting renames, inserts and deletes.
5. Variability mechanisms in DecisionKing
It is one of our aims to create a flexible and exten-sible modeling tool that can be used in different do-mains and organizations. Ideally, DecisionKing itself can be seen as a product line offering a number of vari-ability mechanisms such as meta-modeling capabilities and extension points to create domain-specific vari-ability modeling tools.
5.1 Domain-specific meta-models
The tool can be parameterized by creating a domain model defining concrete asset types and relationships to enable the creation of domain-specific variability models according to the meta-model. There are no re-strictions regarding the types of assets that can be de-fined, which makes domain-specific adaptations fairly intuitive. The approach is similar to the approach pur-sued by Grundy et al. [14] to generate domain-specific visual language editors from high-level tool specifica-tions in Eclipse.
Figure 7 shows an example of a domain-model with three types of assets and two types of relation-ships we’ve created for Siemens VAI. The model al-lows DecisionKing to deal with Components, Re-sources and Properties. Figure 3 shows the GUI editor used to define meta-models in DecisionKing.
One can also add arbitrary attributes to asset types. Asset attributes are typed properties of the assets. Apart from the standard types, we have defined a new type “Script”, which refers to code that can be inter-preted by the constraint interpreter used in the model.
The domain model can be changed at any time, i.e. new types of assets, attributes of assets, or relationship types among assets can be added if necessary. Deci-sionKing supports meta-model updates even for al-ready existing variability models, a requirement stated by our industry partner.
In order to validate the concepts we have been de-veloping meta-models for other domains and projects. For example, DecisionKing has been used in another research project to model runtime variability of ser-vices in service-oriented computing.
Metamodel vai { AssetRelationships {Requires, ContributesTo} AssetType Component{ Attributes { String name, description; Script includedIf; } Relations { Requires{Component, Resource} ContributesTo{Component, Resource}
} } AssetType Resource { Attributes { String name, description; Script includedIf;
Double price; } Relations { Requires{Resource} ContributesTo{Component, Resource}
} } AssetType Property { Attributes { String name, description, key; Script includedIf, value; } Relations { ContributesTo{Component, Resource}
} } }
Figure 7: Domain-specific meta-model with concrete asset types and relationships
5.2 Plug-in Architecture
Our second architecture-level variability mecha-nism ensures extensibility. DecisionKing is based on a plug-in architecture allowing arbitrary external tools to communicate and interact with it. This enables users to develop and integrate company-specific functionality. We have used this feature in three cases so far: (i) We can automatically import existing assets and their rela-tionships from existing configurations to populate the variability model (see examples above). (ii) Our lan-guage to describe rules and constraints for relation-ships between decisions and is provided via a plug-in. We intend to replace our current rule language with a more powerful language based on the JBoss3 rule en-gine. (iii) We can use third-party model differencers as demonstrated with a plug-in by [1] we integrated via this mechanism.
6. Conclusions and Further Work
There are several tools and techniques supporting variability modeling in product line engineering. Al-though all these tools represent important and valuable contributions for capturing variability there is still a need for research to improve approaches and tools for capturing and evolving variability models. Different
3 http://labs.jboss.com/portal/
domains deal with different types of assets, and need different variability management mechanisms. There is a lack of flexible and extensible tools that can easily be adapted to organizational needs.
In this paper, we presented DecisionKing, a tool with highly flexible adaptation and integration capa-bilities. In contrast to most other variability modeling tools which integrate modeling and configuration into one, DecisionKing creates variability models, which can be imported by other tools that make use of this model. DecisionKing works independent of the pro-gramming language and the architectural style of the product line. It can be adapted to model variability in different organizational settings. It is based on a plug-in architecture, which also makes it readily extensible.
DecisionKing is currently being used by developers and engineers from Siemens VAI to validate the ap-proach and to provide feedback. Several variability models for subsystems of the continuous casting sys-tem have already been developed using the tool with positive feedback regarding the extensibility of the modeling approach and the flexibility of the tool.
However, users of the tool have also reported us-ability issues, which we will have to address in future work. For example, it is hard to visualize the relation-ships between the model elements due to the size of the models in our predominantly tree-based representa-tion. The graphical representation of variability models is useful; however creating real-world examples cover-ing a high number of elements and complex relation-ships such a graphical notation can get tedious. Cur-rently, we are therefore exploring different visualiza-tion mechanisms for variability models.
Another goal of our research is to integrate Deci-sionKing with tools supporting non-technicians to par-ticipate in the configuration of products [21]. For this purpose, DecisionKing offers an API, which enables easy usage of the variability models by different con-figuration tools. We are also developing a tool called ProjectKing [22] which makes use of the variability models and supports product instantiation and configu-ration by generating customer-/project-specific wiz-ards. Sales managers can use ProjectKing, to define different products and to design sales processes for individual projects. For example, one can define typi-cal products for different customer types (by setting defaults) or model additional guards/recommendations for the sales process.
Acknowledgements
This work has been conducted in cooperation with Siemens VAI and has been supported by the Christian Doppler Forschungsgesellschaft, Austria. We would like to express our sincere gratitude to Klaus Lehner and Christian Federspiel from Siemens VAI for their support and for sharing valuable insights. We thank Marwan Abi-Antoun from Carnegie Mellon University for his support regarding the model differencer. We are also grateful to Thomas Neumayer for his work on the multi-team capabilities.
References
[1] M. Abi-Antoun, J. Aldrich, N. Nahas, B. Schmerl, and D. Garlan, ”Differencing and Merging of Architectural Views,” Proceedings of the 21st IEEE International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan, 2006, pp.47-58.
[2] M. Antkiewicz and K. Czarnecki, “FeaturePlugin: Fea-ture Modeling Plug-In for Eclipse,” presented at the OOPSLA’04 Eclipse Technology eXchange (ETX) Workshop, Vancouver, Canada, 2004.
[3] T. Asikainen, T. Soininen, and T. Männistö, „A Koala-based Ontology of Configurable Software Product Families,” presented at the 18th International Joint Con-ference on Artificial Intelligence (IJCAI) Configuration Workshop, Acapulco, Mexico, 2003.
[4] F. Bachmann, M. Goedicke, J. Leite, R. Nord, K. Pohl, B. Ramesh, and A. Vilbig, “A Meta-model for Repre-senting Variability in Product Family Development,” in Lecture Notes in Computer Science: Software Product-
Family Engineering. Siena, Italy: Springer Berlin / Hei-delberg, 2003, pp. 66-80.
[5] K. Berg, J. Bishop, and D. Muthig, “Tracing Software Product Line Variability – From Problem to Solution Space,” presented at 2005 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries, White River, South Africa, 2005.
[6] K. Czarnecki, M. Antkiewicz, C. Hwan, P. Kim, S. Lau, and K. Pietroszek, “fmp and fmp2rsm: Eclipse Plug-Ins for Modeling Features using model templates,” pre-sented at OOPSLA’05, October 16–20, San Diego, Cali-fornia, USA, 2005.
[7] E. M. Dashofy, A. van der Hoek, and R. N. Taylor, “An Infrastructure for the Rapid Development of XML-based Architecture Description Languages,” presented at International Conference on Software Engineering (ICSE 2002), Orlando, USA, 2002.
[8] D. Dhungana, R. Rabiser, P. Grünbacher, H. Prähofer, C. Federspiel, and K. Lehner, “Architectural Knowl-edge in Product Line Engineering: An Industrial Case Study,” presented at 32nd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Cavtat/Dubrovnik, Croatia, 2006.
[9] D. Dhungana, “Integrated Variability Modeling of Fea-tures and Architecture in Software Product Line Engi-neering,” presented at Doctoral Symposium, 21st IEEE International Conference on Automated Software Engi-neering (ASE'06), Tokyo, Japan, 2006.
[10] D. Dhungana, R. Rabiser, and P. Grünbacher, “Coordi-nating Multi-Team Variability Modeling in Product Line Engineering,” presented at 2nd International Workshop on Supporting Knowledge Collaboration in Software Development (KCSD2006), collocated with the
Figure 8: Meta-model editor
21st IEEE International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan, 2006.
[11] D. Dhungana, R. Rabiser, and P. Grünbacher, “Deci-sion-Oriented Modeling of Product Line Architectures,” presented at Sixth Working IEEE/IFIP Conference on Software Architecture, Mumbai, India, 2007.
[12] J. Estublier and G. Vega, “Reuse and Variability in Large Software Applications,” presented at 10th Euro-pean software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foun-dations of software engineering, Lisbon, Portugal, 2005.
[13] P. Grünbacher, A.F. Egyed, and N. Medvidovic, “Rec-onciling software requirements and architectures with intermediate models”, Journal on Software and System Modeling, vol. 3(3), pp. 235-253, 2004.
[14] J. Grundy, J. Hosking, N. Zhu, and N. Liu, “Generating Domain-Specific Visual Language Editors from High-level Tool Specifications,” presented at 21st IEEE/ACM International Conference on Automated Software Engi-neering, Tokyo, Japan, 2006.
[15] K. Schmid and I. John, “A Customizable Approach to Full-Life Cycle Variability Management,” Journal of the Science of Computer Programming, Special Issue on Variability Management, vol. 53(3), pp. 259-284, 2004.
[16] K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson, “Feature-Oriented Domain Analysis (FODA) Feasibility
Study,” Software Engineering Institute, Carnegie Mel-lon University, USA, 1990.
[17] M. Mezini and K. Ostermann, “Variability Management with Feature-Oriented Programming and Aspects,” Pro-ceedings of the 12th ACM SIGSOFT International Sym-posium on Foundations of Software Engineering (FSE-12), Newport Beach, USA, 2004, pp. 127-136.
[18] C. W. Krueger, “Software Mass Customization,” BigLever Software, Inc., 2005.
[19] K. Pohl, G. Böckle, and F.J. van der Linden, “Software Product Line Engineering: Foundations, Principles and Techniques,” Springer-Verlag, 2005.
[20] pure-systems GmbH, Technical White Paper, Variant Management with pure::variants, http://www.pure-systems.com/fileadmin/downloads/pureconsul_en_04.pdf
[21] R. Rabiser, “Facilitating the Involvement of Non-Technicians in Product Configuration,” presented at Doctoral Symposium, 10th Software Product Lines In-ternational Conference (SPLC), Baltimore, USA, 2006.
[22] R. Rabiser, D. Dhungana, P. Grünbacher, K.Lehner, and C. Federspiel, “Product Configuration Support for Non-Technicians: A Customer-Centered Approach in Soft-ware Product Line Engineering,” to appear in IEEE In-telligent Systems, Special Issue on Configuration, Jan/Feb 2007.
[23] S. Thiel and A. Hein, “Systematic Integration of Vari-ability into Product Line Architecture Design,” Proceed-ings of the 2nd International Conference on Software Product Lines (SPLC), 2002, pp. 130-153.