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}
Extending commercial tools for variability management is the problem addressed in this paper. IBM Rational DOORS is a well accepted tool in the area of requirements engineering and supports an Application Programming Interface (API) called DOORS extension Language (DXL). In this contribution we present a way of extending DOORS for product line requirements engineering based on a DXL plug-in called metadoc feature modeler. Established concepts in the community such as feature diagrams, instantiation of feature models, automatic deficit analysis and issue-based variability are introduced into DOORS. These concepts are abstracted using the DOORS meta-model. As DOORS is directly extended using new components, no special synchronizers are required between feature modeling environment and DOORS (which is a difference with respect to traditional feature modeling tools). We share our experience in using the feature modeler at a medium-sized company.
{"title":"Metadoc Feature Modeler: A Plug-in for IBM Rational DOORS","authors":"A. K. Thurimella, Dirk Janzen","doi":"10.1109/SPLC.2011.17","DOIUrl":"https://doi.org/10.1109/SPLC.2011.17","url":null,"abstract":"Extending commercial tools for variability management is the problem addressed in this paper. IBM Rational DOORS is a well accepted tool in the area of requirements engineering and supports an Application Programming Interface (API) called DOORS extension Language (DXL). In this contribution we present a way of extending DOORS for product line requirements engineering based on a DXL plug-in called metadoc feature modeler. Established concepts in the community such as feature diagrams, instantiation of feature models, automatic deficit analysis and issue-based variability are introduced into DOORS. These concepts are abstracted using the DOORS meta-model. As DOORS is directly extended using new components, no special synchronizers are required between feature modeling environment and DOORS (which is a difference with respect to traditional feature modeling tools). We share our experience in using the feature modeler at a medium-sized company.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"19 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":"115610054","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}
Karina Villela, Sholom G. Cohen, L. Baresi, Jaejoon Lee, Klaus Schmid
Summary of Scarves workshop
丝巾工作坊简介
{"title":"SCArVeS: Services, Clouds, and Alternative Design Strategies for Variant-Rich Software Systems","authors":"Karina Villela, Sholom G. Cohen, L. Baresi, Jaejoon Lee, Klaus Schmid","doi":"10.1109/SPLC.2011.54","DOIUrl":"https://doi.org/10.1109/SPLC.2011.54","url":null,"abstract":"Summary of Scarves workshop","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"31 2 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":"132593997","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}
Agile software development has been gaining increasing attention during the last decade. In agile process models, attention is paid to building the ability to respond to change. This is problematic in view of product line engineering and formal modeling, since traditionally these two require heavy up-front planning. We are presenting our experiences on combining these three in an industrial setting of building a telecommunication network provisioning product line. We avoided the up-front planning by building our modeling toolset in a bottom-up way and improving the toolset whenever required by the needs of the on-going iteration.
{"title":"Bottom-up Modeling for a Software Product Line: An Experience Report on Agile Modeling of Governmental Mobile Networks","authors":"P. Pohjalainen","doi":"10.1109/SPLC.2011.48","DOIUrl":"https://doi.org/10.1109/SPLC.2011.48","url":null,"abstract":"Agile software development has been gaining increasing attention during the last decade. In agile process models, attention is paid to building the ability to respond to change. This is problematic in view of product line engineering and formal modeling, since traditionally these two require heavy up-front planning. We are presenting our experiences on combining these three in an industrial setting of building a telecommunication network provisioning product line. We avoided the up-front planning by building our modeling toolset in a bottom-up way and improving the toolset whenever required by the needs of the on-going iteration.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"83 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":"125758967","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}
Transition from a classic platform reuse approach towards a product line engineering paradigm for existing products is demanding. Existing software design, substantial amount of code, an established development process, organizational set-up of teams and the mindset of involved people must be considered. These factors make the transition challenging compared to a green-field approach, where reusable assets are already developed in a product line spirit. We describe our experience during transitioning to a product line approach in the context of a healthcare imaging platform from the viewpoint of responsible domain engineering architects. Our primary focus is on re-engineering activities to introduce product line engineering practices to an existing legacy system. General product-line challenges not related to re-engineering are omitted in this paper. We recognize additional benefits when applying a hierarchical product line approach in our domain. We conclude with the factors that impact a successful transition to a product-line approach.
{"title":"Re-engineering of a Hierarchical Product Line","authors":"Jörg Bartholdt, Detlef Becker","doi":"10.1109/SPLC.2011.16","DOIUrl":"https://doi.org/10.1109/SPLC.2011.16","url":null,"abstract":"Transition from a classic platform reuse approach towards a product line engineering paradigm for existing products is demanding. Existing software design, substantial amount of code, an established development process, organizational set-up of teams and the mindset of involved people must be considered. These factors make the transition challenging compared to a green-field approach, where reusable assets are already developed in a product line spirit. We describe our experience during transitioning to a product line approach in the context of a healthcare imaging platform from the viewpoint of responsible domain engineering architects. Our primary focus is on re-engineering activities to introduce product line engineering practices to an existing legacy system. General product-line challenges not related to re-engineering are omitted in this paper. We recognize additional benefits when applying a hierarchical product line approach in our domain. We conclude with the factors that impact a successful transition to a product-line approach.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"74 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":"126710346","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}
This tutorial teaches how to define Domain-Specific Modeling languages for product lines: how to identify domain concepts and capture them in the language specification, how to enforce the architecture and coding rules, what options are available for code generation, and what are the industry experiences from companies. The tutorial includes exercises allowing participants to apply the language definition skills learned.
{"title":"Creating Domain-Specific Modeling Languages for Product Lines","authors":"Juha-Pekka Tolvanen, S. Kelly","doi":"10.1109/SPLC.2011.9","DOIUrl":"https://doi.org/10.1109/SPLC.2011.9","url":null,"abstract":"This tutorial teaches how to define Domain-Specific Modeling languages for product lines: how to identify domain concepts and capture them in the language specification, how to enforce the architecture and coding rules, what options are available for code generation, and what are the industry experiences from companies. The tutorial includes exercises allowing participants to apply the language definition skills learned.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"2018 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":"121575864","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}
Kentaro Yoshimura, J. Shimabukuro, Takatoshi Ohara, C. Okamoto, Yoshitaka Atarashi, Shinobu Koizumi, Shigeru Watanabe, K. Funakoshi
This paper reports introducing software product lines (SPLs) into multiple divisions at Hitachi. For any divisions developing software for product families that have many variations, an SPL is the key to improving quality, cost, and development efficiency. To introduce SPLs into multiple business divisions from small embedded systems to large power control systems, we organized an SPL project across organizations. Throughout the project, we have successfully introduced SPLs into multiple divisions and identified common and useful activities such as evaluating legacy systems, training domain experts, and sharing experiences with SPL experts. We also report the lessons learned from our experiences about SPL adoptions.
{"title":"Key Activities for Introducing Software Product Lines into Multiple Divisions: Experience at Hitachi","authors":"Kentaro Yoshimura, J. Shimabukuro, Takatoshi Ohara, C. Okamoto, Yoshitaka Atarashi, Shinobu Koizumi, Shigeru Watanabe, K. Funakoshi","doi":"10.1109/SPLC.2011.14","DOIUrl":"https://doi.org/10.1109/SPLC.2011.14","url":null,"abstract":"This paper reports introducing software product lines (SPLs) into multiple divisions at Hitachi. For any divisions developing software for product families that have many variations, an SPL is the key to improving quality, cost, and development efficiency. To introduce SPLs into multiple business divisions from small embedded systems to large power control systems, we organized an SPL project across organizations. Throughout the project, we have successfully introduced SPLs into multiple divisions and identified common and useful activities such as evaluating legacy systems, training domain experts, and sharing experiences with SPL experts. We also report the lessons learned from our experiences about SPL adoptions.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"79 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":"114992288","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}
David Benavides, M. Leucker, Martin Becker, Rick Rabiser, Karina Villela, Peter Y. H. Wong
This workshop will bring together researchers interested in raising the efficiency and the effectiveness of Software Product Line Engineering by applying innovative analysis approaches and formal methods.
{"title":"Formal Methods and Analysis in Software Product Line Engineering (FMSPLE 2011)","authors":"David Benavides, M. Leucker, Martin Becker, Rick Rabiser, Karina Villela, Peter Y. H. Wong","doi":"10.1109/SPLC.2011.39","DOIUrl":"https://doi.org/10.1109/SPLC.2011.39","url":null,"abstract":"This workshop will bring together researchers interested in raising the efficiency and the effectiveness of Software Product Line Engineering by applying innovative analysis approaches and formal methods.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114795921","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 ability to rapidly respond to customer interest and to effectively prioritize development effort has been a longstanding challenge for mass-market software intensive products. This problem is exacerbated in the context of software product lines as functionality may easily fall over software asset and organizational boundaries with consequent losses in efficiency and nimbleness. In this tutorial, we discuss these challenges; present a case study, Intuit?'s Quickbooks product line that combined agile software development, design thinking and self-organizing teams in a successful approach; and discuss a generalized approach and implications from employing the techniques in your organization.
{"title":"Achieving Speed in Legacy Systems","authors":"J. Bosch","doi":"10.1109/SPLC.2011.59","DOIUrl":"https://doi.org/10.1109/SPLC.2011.59","url":null,"abstract":"The ability to rapidly respond to customer interest and to effectively prioritize development effort has been a longstanding challenge for mass-market software intensive products. This problem is exacerbated in the context of software product lines as functionality may easily fall over software asset and organizational boundaries with consequent losses in efficiency and nimbleness. In this tutorial, we discuss these challenges; present a case study, Intuit?'s Quickbooks product line that combined agile software development, design thinking and self-organizing teams in a successful approach; and discuss a generalized approach and implications from employing the techniques in your organization.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"59 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131980357","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}
Production planning gives early guidance concerning how products should be built and hence how core assets should be designed. The production strategy addresses business goals through product building. The production method implements the production strategy by delineating exactly how a product is built from core assets. The production plan instantiates the production method for a specific product. In this tutorial we will layout production planning in a software product line and provide examples from a number of different product lines.
{"title":"Production Planning in a Software Product Line Organization","authors":"J. McGregor","doi":"10.1145/2364412.2364471","DOIUrl":"https://doi.org/10.1145/2364412.2364471","url":null,"abstract":"Production planning gives early guidance concerning how products should be built and hence how core assets should be designed. The production strategy addresses business goals through product building. The production method implements the production strategy by delineating exactly how a product is built from core assets. The production plan instantiates the production method for a specific product. In this tutorial we will layout production planning in a software product line and provide examples from a number of different product lines.","PeriodicalId":278787,"journal":{"name":"2011 15th International Software Product Line Conference","volume":"62 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-09-08","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125503819","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
扫码关注我们
求助内容：
应助结果提醒方式：