{"title":"使用基本原理来驱动产品线架构配置","authors":"J. Burge, G. Gannod, Holly L. Connor","doi":"10.1145/1988676.1988683","DOIUrl":null,"url":null,"abstract":"The process of designing and building a software system requires making many decisions. These decisions, the alternatives considered, and the reasons behind the choices comprise the rationale for the completed system. The driving force behind many, if not most, of these decisions is the need to meet the stakeholder requirements for the system being developed. Software product line approaches allow developers to design and develop families of products that share a common platform of behaviors and infrastructure. These approaches are based on assembling a configuration of a set of common features (commonalities) along with a set of product specific features (variabilities) to form a new product with a low amount of effort. In this context, these variabilities represent a wide variety of potential \"design\" alternatives. The goal of our research is to bring the end-user into the process of configuring a software product through the use of system level rationale that maps product line features to system requirements. Specifically, in our approach we specify rationale at the level of a feature diagram. Accordingly, we are taking advantage of the natural correlation between alternative features in a feature diagram and the alternative structure used in design rationale. This allows the end-user to indicate which requirements apply to their product and to have that selection generate a set of product features that satisfy those requirements.","PeriodicalId":325791,"journal":{"name":"Sharing and Reusing Architectural Knowledge","volume":"2016 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2011-05-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":"{\"title\":\"Using rationale to drive product line architecture configuration\",\"authors\":\"J. Burge, G. Gannod, Holly L. Connor\",\"doi\":\"10.1145/1988676.1988683\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"The process of designing and building a software system requires making many decisions. These decisions, the alternatives considered, and the reasons behind the choices comprise the rationale for the completed system. The driving force behind many, if not most, of these decisions is the need to meet the stakeholder requirements for the system being developed. Software product line approaches allow developers to design and develop families of products that share a common platform of behaviors and infrastructure. These approaches are based on assembling a configuration of a set of common features (commonalities) along with a set of product specific features (variabilities) to form a new product with a low amount of effort. In this context, these variabilities represent a wide variety of potential \\\"design\\\" alternatives. The goal of our research is to bring the end-user into the process of configuring a software product through the use of system level rationale that maps product line features to system requirements. Specifically, in our approach we specify rationale at the level of a feature diagram. Accordingly, we are taking advantage of the natural correlation between alternative features in a feature diagram and the alternative structure used in design rationale. This allows the end-user to indicate which requirements apply to their product and to have that selection generate a set of product features that satisfy those requirements.\",\"PeriodicalId\":325791,\"journal\":{\"name\":\"Sharing and Reusing Architectural Knowledge\",\"volume\":\"2016 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2011-05-24\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"1\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Sharing and Reusing Architectural Knowledge\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/1988676.1988683\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Sharing and Reusing Architectural Knowledge","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/1988676.1988683","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Using rationale to drive product line architecture configuration
The process of designing and building a software system requires making many decisions. These decisions, the alternatives considered, and the reasons behind the choices comprise the rationale for the completed system. The driving force behind many, if not most, of these decisions is the need to meet the stakeholder requirements for the system being developed. Software product line approaches allow developers to design and develop families of products that share a common platform of behaviors and infrastructure. These approaches are based on assembling a configuration of a set of common features (commonalities) along with a set of product specific features (variabilities) to form a new product with a low amount of effort. In this context, these variabilities represent a wide variety of potential "design" alternatives. The goal of our research is to bring the end-user into the process of configuring a software product through the use of system level rationale that maps product line features to system requirements. Specifically, in our approach we specify rationale at the level of a feature diagram. Accordingly, we are taking advantage of the natural correlation between alternative features in a feature diagram and the alternative structure used in design rationale. This allows the end-user to indicate which requirements apply to their product and to have that selection generate a set of product features that satisfy those requirements.