S. Apel, Florian Heidenreich, Christian Kästner, M. Rosenmüller
Feature orientation is an emerging paradigm of software development. It supports the automatic generation of large scale software systems from a set of features. A feature is a unit of functionality that satisfies a requirement, represents a design decision, and provides a potential configuration option. The goal of feature-oriented software development (FOSD) is to consider and trace the features of a software system during all phases of the software life cycle from analysis and design to implementation and testing. The aim of the FOSD workshop is to stimulate collaboration between researchers working on FOSD and related areas.
{"title":"Third International Workshop on Feature-Oriented Software Development (FOSD 2011)","authors":"S. Apel, Florian Heidenreich, Christian Kästner, M. Rosenmüller","doi":"10.1109/SPLC.2011.19","DOIUrl":"https://doi.org/10.1109/SPLC.2011.19","url":null,"abstract":"Feature orientation is an emerging paradigm of software development. It supports the automatic generation of large scale software systems from a set of features. A feature is a unit of functionality that satisfies a requirement, represents a design decision, and provides a potential configuration option. The goal of feature-oriented software development (FOSD) is to consider and trace the features of a software system during all phases of the software life cycle from analysis and design to implementation and testing. The aim of the FOSD workshop is to stimulate collaboration between researchers working on FOSD and related areas.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134276913","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We illustrate how to manage variability in a single logical framework consisting of a Modal Transition System (MTS) and an associated set of formulae expressed in the branching-time temporal logic MHML interpreted in a deontic way over such MTSs. We discuss the commonalities and differences with the framework of Classen et al. based on Featured Transition Systems and Linear-time Temporal Logic.
{"title":"Formal Description of Variability in Product Families","authors":"P. Asirelli, M. T. Beek, S. Gnesi, A. Fantechi","doi":"10.1109/SPLC.2011.34","DOIUrl":"https://doi.org/10.1109/SPLC.2011.34","url":null,"abstract":"We illustrate how to manage variability in a single logical framework consisting of a Modal Transition System (MTS) and an associated set of formulae expressed in the branching-time temporal logic MHML interpreted in a deontic way over such MTSs. We discuss the commonalities and differences with the framework of Classen et al. based on Featured Transition Systems and Linear-time Temporal Logic.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"52 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134315513","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
A symposium for doctoral students is organized at SPLC. The purpose of the symposium is to offer expert feedback to students on their thesis work. In addition, the overall aim of the symposium is to improve the quality of doctoral thesis work in the area of software product lines.
{"title":"Doctoral Symposium","authors":"T. Männistö","doi":"10.1109/SPLC.2011.67","DOIUrl":"https://doi.org/10.1109/SPLC.2011.67","url":null,"abstract":"A symposium for doctoral students is organized at SPLC. The purpose of the symposium is to offer expert feedback to students on their thesis work. In addition, the overall aim of the symposium is to improve the quality of doctoral thesis work in the area of software product lines.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116797291","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Gary J. Chastek, P. Donohoe, J. McGregor, Dirk Muthig
The production method for a software product line is the coordinated set of processes, models, and tools chosen to implement the essential product line activities of core asset development and product development. This paper shows how the task of engineering a production method for a product line can be facilitated by applying concepts from the domain of method engineering. A case study of an industrial product line illustrates how its production method was engineered to achieve specific business goals.
{"title":"Engineering a Production Method for a Software Product Line","authors":"Gary J. Chastek, P. Donohoe, J. McGregor, Dirk Muthig","doi":"10.1109/SPLC.2011.46","DOIUrl":"https://doi.org/10.1109/SPLC.2011.46","url":null,"abstract":"The production method for a software product line is the coordinated set of processes, models, and tools chosen to implement the essential product line activities of core asset development and product development. This paper shows how the task of engineering a production method for a product line can be facilitated by applying concepts from the domain of method engineering. A case study of an industrial product line illustrates how its production method was engineered to achieve specific business goals.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115293927","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In software product line engineering (SPLE), commonality and variability across products of a product line domain are captured typically by a feature model. Reusable components are then developed from features. However, mapping features to components remains a complex task requiring a systematic way of exploring and analyzing various concerns arising from inadequate/insufficient domain assumptions. Essentially, those concerns prevent SPLE from achieving various quality attributes. This paper proposes a problem frames-based approach to addressing this problem. An elevator product line example is used to demonstrate the feasibility of the approach.
{"title":"Problem Frames-Based Approach to Achieving Quality Attributes in Software Product Line Engineering","authors":"Tung M. Dao, Hyesun Lee, K. Kang","doi":"10.1109/SPLC.2011.55","DOIUrl":"https://doi.org/10.1109/SPLC.2011.55","url":null,"abstract":"In software product line engineering (SPLE), commonality and variability across products of a product line domain are captured typically by a feature model. Reusable components are then developed from features. However, mapping features to components remains a complex task requiring a systematic way of exploring and analyzing various concerns arising from inadequate/insufficient domain assumptions. Essentially, those concerns prevent SPLE from achieving various quality attributes. This paper proposes a problem frames-based approach to addressing this problem. An elevator product line example is used to demonstrate the feasibility of the approach.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"125 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124202034","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The efficient reuse of requirements is a main challenge in industries that offer products with a high degree of reuse in their components, like the automotive industry. Here, an efficient and effective variability management (VM) that is highly integrated with the requirements specification process is an essential prerequisite for successful reuse of requirements. This paper presents experiences gained while introducing VM-based requirements reuse for natural language specifications at Daimler passenger car development. Here, out-of-the-box approaches were inappropriate due to poor scalability, inappropriate tool support, and the need to use decentralized variability models. As a consequence, we had to modify existing approaches to make them work in our environment. The paper briefly describes these modifications along with observations gained while implementing them in real-world specification processes.
{"title":"Experience with Variability Management in Requirement Specifications","authors":"Ekaterina Boutkova","doi":"10.1109/SPLC.2011.35","DOIUrl":"https://doi.org/10.1109/SPLC.2011.35","url":null,"abstract":"The efficient reuse of requirements is a main challenge in industries that offer products with a high degree of reuse in their components, like the automotive industry. Here, an efficient and effective variability management (VM) that is highly integrated with the requirements specification process is an essential prerequisite for successful reuse of requirements. This paper presents experiences gained while introducing VM-based requirements reuse for natural language specifications at Daimler passenger car development. Here, out-of-the-box approaches were inappropriate due to poor scalability, inappropriate tool support, and the need to use decentralized variability models. As a consequence, we had to modify existing approaches to make them work in our environment. The paper briefly describes these modifications along with observations gained while implementing them in real-world specification processes.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129203492","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Many software product line organizations have been in operation for a sufficiently long time for products and assets to be refurbished and even retired. There is much experience in the management and operation of product lines that has not been communicated. Our goal is to provide information about both strategic and tactical actions needed for the continuing operation of a successful software product line organization. It is time to look beyond the issues of adoption to focus on the care and feeding of the on-going organization.
{"title":"Management and Operation of a Software Product Line","authors":"J. McGregor, Dirk Muthig","doi":"10.1109/SPLC.2011.64","DOIUrl":"https://doi.org/10.1109/SPLC.2011.64","url":null,"abstract":"Many software product line organizations have been in operation for a sufficiently long time for products and assets to be refurbished and even retired. There is much experience in the management and operation of product lines that has not been communicated. Our goal is to provide information about both strategic and tactical actions needed for the continuing operation of a successful software product line organization. It is time to look beyond the issues of adoption to focus on the care and feeding of the on-going organization.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"42 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128735256","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Christian Tischer, Andreas Müller, Thomas Mandl, R. Krause
Software engineering in the automotive domain faces some outstanding challenges in terms of variability and complexity, specific customer relationship with car manufacturers and quickly and continuously changing requirements. Especially power train control systems currently evolve from classic combustions engine focused concepts towards highly divergent solutions like hybrid systems, range extenders or fully electrically driven vehicles. In this context Bosch's business units Diesel Systems (DS) and Gasoline systems (GS) merged their separated engine control unit development organizations, motivated by a growing portion of functionality independent of the combustion engine type and an increasing synergy potential in hardware and software development. As DS and GS software development evolved independently, they established different technical solutions, organizational structures and development processes - even though both adopted product line engineering principles. Since the official start in 2008, DGS-EC (Diesel Gasoline Systems Engine Control) has installed important prerequisites for common, unified software development and achieved many unification targets. This paper gives an insight to the most important experiences of this large scale product line merger, addressing challenges, enablers and solutions concerning organizational setup, process unification, architecture and product line scope definition as well as software technology harmonization.
{"title":"Experiences from a Large Scale Software Product Line Merger in the Automotive Domain","authors":"Christian Tischer, Andreas Müller, Thomas Mandl, R. Krause","doi":"10.1109/SPLC.2011.15","DOIUrl":"https://doi.org/10.1109/SPLC.2011.15","url":null,"abstract":"Software engineering in the automotive domain faces some outstanding challenges in terms of variability and complexity, specific customer relationship with car manufacturers and quickly and continuously changing requirements. Especially power train control systems currently evolve from classic combustions engine focused concepts towards highly divergent solutions like hybrid systems, range extenders or fully electrically driven vehicles. In this context Bosch's business units Diesel Systems (DS) and Gasoline systems (GS) merged their separated engine control unit development organizations, motivated by a growing portion of functionality independent of the combustion engine type and an increasing synergy potential in hardware and software development. As DS and GS software development evolved independently, they established different technical solutions, organizational structures and development processes - even though both adopted product line engineering principles. Since the official start in 2008, DGS-EC (Diesel Gasoline Systems Engine Control) has installed important prerequisites for common, unified software development and achieved many unification targets. This paper gives an insight to the most important experiences of this large scale product line merger, addressing challenges, enablers and solutions concerning organizational setup, process unification, architecture and product line scope definition as well as software technology harmonization.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"61 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127583244","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We propose to integrate performance analysis in the early phases of the model-driven development process for Software Product Lines (SPL). We start with a multi-view UML model of the core family assets representing the commonality and variability between different products, which we call the SPL model. We add another perspective to the SPL model, annotating it with generic performance specifications expressed in the standard UML profile MARTE, recently adopted by OMG. The runtime performance of a product is affected by factors contained in the UML model of the product (derived from the SPL model), but also by external factors depending on the implementation and execution environments. The external factors not contained in the SPL model need to be eventually represented in the performance model. In order to do so, we propose to represent the variability space of different possible implementation and execution environments through a so called "performance completion (PC) feature model". These PC features are mapped to MARTE performance-related stereotypes and attributes attached to the SPL model elements. A first model transformation realized in the Atlas Transformation Language (ATL) derives the UML model of a specific product with concrete MARTE annotations from the SPL model. A second transformation generates a Layered Queueing Network (LQN) performance model for the given product by applying an existing transformation named PUMA, developed in previous work. The proposed technique is illustrated with an e-commerce case study. A LQN model is derived for a product and the impact of different levels of secure communication channels on its performance is analyzed by using the LQN model.
{"title":"Automatic Derivation of a Product Performance Model from a Software Product Line Model","authors":"Rasha Tawhid, D. Petriu","doi":"10.1109/SPLC.2011.27","DOIUrl":"https://doi.org/10.1109/SPLC.2011.27","url":null,"abstract":"We propose to integrate performance analysis in the early phases of the model-driven development process for Software Product Lines (SPL). We start with a multi-view UML model of the core family assets representing the commonality and variability between different products, which we call the SPL model. We add another perspective to the SPL model, annotating it with generic performance specifications expressed in the standard UML profile MARTE, recently adopted by OMG. The runtime performance of a product is affected by factors contained in the UML model of the product (derived from the SPL model), but also by external factors depending on the implementation and execution environments. The external factors not contained in the SPL model need to be eventually represented in the performance model. In order to do so, we propose to represent the variability space of different possible implementation and execution environments through a so called \"performance completion (PC) feature model\". These PC features are mapped to MARTE performance-related stereotypes and attributes attached to the SPL model elements. A first model transformation realized in the Atlas Transformation Language (ATL) derives the UML model of a specific product with concrete MARTE annotations from the SPL model. A second transformation generates a Layered Queueing Network (LQN) performance model for the given product by applying an existing transformation named PUMA, developed in previous work. The proposed technique is illustrated with an e-commerce case study. A LQN model is derived for a product and the impact of different levels of secure communication channels on its performance is analyzed by using the LQN model.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"50 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126253695","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Svein O. Hallsteinsen, M. Hinchey, S. Park, Klaus Schmid
In emerging domains such as ubiquitous computing, service robotics, unmanned space and water exploration, and medical and life-support devices, software is becoming increasingly complex with extensive variation in both requirements and resource constraints. Developers face growing pressure to deliver high-quality software with additional functionality, on tight deadlines, and more economically. In addition, modern computing and network environments demand a higher degree of adaptability from their software systems. Computing environments, user requirements, and interface mechanisms between software and hardware devices such as sensors can change dynamically during runtime. Because it's impossible to foresee all the functionality or variability an SPL requires, there is a need for dynamic SPLs that produce software capable of adapting to fluctuations in user needs and evolving resource constraints. DSPLs bind variation points at runtime, initially when software is launched, to adapt to the current environment, as well as during operation to adapt to changes in the environment. Although traditional SPL engineering recognizes that variation points are bound at different stages of development, and possibly also at runtime, it typically binds variation points before delivery of the software. In contrast, DSPL engineers typically aren't concerned with pre-runtime variation points. However, they recognize that in practice mixed approaches might be viable, where some variation points related to the environment's static properties are bound before runtime and others related to the dynamic properties are bound at runtime. In DSPLs, monitoring the current situation and controlling the adaptation are thus central tasks. The user, the application, or generic middleware can perform these tasks manually or automatically. Although dynamic software product lines build on the central ideas of SPLs, there are also differences. For example, the focus on understanding the market and letting the SPL drive variability analysis is less relevant to DSPLs, whose primary goal is to adapt to variations in individual needs and situations rather than market forces. In summary, a DSPL has many, if not all, of the following properties:• dynamic variability configuration and binding at runtime, • changes binding several times during its lifetime, • variation points change during runtime: variation point addition (by extending one variation point), • deals with unexpected changes (in some limited way), • deals with changes by users, such as functional or quality requirements, • context awareness (optional) and situation awareness, • autonomic or self-adaptive properties (optional), • automatic decision making (optional), and• individual environment/context situation instead of a "market." Given these characteristics, DSPLs benefits from research in several related areas. For example, situation monitoring and adaptive decision making are also characteristics of autonomic computing
{"title":"Fifth International Workshop on Dynamic Software Product Lines (DSPL 2011)","authors":"Svein O. Hallsteinsen, M. Hinchey, S. Park, Klaus Schmid","doi":"10.1109/SPLC.2011.50","DOIUrl":"https://doi.org/10.1109/SPLC.2011.50","url":null,"abstract":"In emerging domains such as ubiquitous computing, service robotics, unmanned space and water exploration, and medical and life-support devices, software is becoming increasingly complex with extensive variation in both requirements and resource constraints. Developers face growing pressure to deliver high-quality software with additional functionality, on tight deadlines, and more economically. In addition, modern computing and network environments demand a higher degree of adaptability from their software systems. Computing environments, user requirements, and interface mechanisms between software and hardware devices such as sensors can change dynamically during runtime. Because it's impossible to foresee all the functionality or variability an SPL requires, there is a need for dynamic SPLs that produce software capable of adapting to fluctuations in user needs and evolving resource constraints. DSPLs bind variation points at runtime, initially when software is launched, to adapt to the current environment, as well as during operation to adapt to changes in the environment. Although traditional SPL engineering recognizes that variation points are bound at different stages of development, and possibly also at runtime, it typically binds variation points before delivery of the software. In contrast, DSPL engineers typically aren't concerned with pre-runtime variation points. However, they recognize that in practice mixed approaches might be viable, where some variation points related to the environment's static properties are bound before runtime and others related to the dynamic properties are bound at runtime. In DSPLs, monitoring the current situation and controlling the adaptation are thus central tasks. The user, the application, or generic middleware can perform these tasks manually or automatically. Although dynamic software product lines build on the central ideas of SPLs, there are also differences. For example, the focus on understanding the market and letting the SPL drive variability analysis is less relevant to DSPLs, whose primary goal is to adapt to variations in individual needs and situations rather than market forces. In summary, a DSPL has many, if not all, of the following properties:• dynamic variability configuration and binding at runtime, • changes binding several times during its lifetime, • variation points change during runtime: variation point addition (by extending one variation point), • deals with unexpected changes (in some limited way), • deals with changes by users, such as functional or quality requirements, • context awareness (optional) and situation awareness, • autonomic or self-adaptive properties (optional), • automatic decision making (optional), and• individual environment/context situation instead of a \"market.\" Given these characteristics, DSPLs benefits from research in several related areas. For example, situation monitoring and adaptive decision making are also characteristics of autonomic computing","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133903552","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：