IWPSE-EVOL '10Pub Date : 2010-09-20DOI: 10.1145/1862372.1862387
Eya Ben Charrada, M. Glinz
{"title":"An automated hint generation approach for supporting the evolution of requirements specifications","authors":"Eya Ben Charrada, M. Glinz","doi":"10.1145/1862372.1862387","DOIUrl":"https://doi.org/10.1145/1862372.1862387","url":null,"abstract":"Updating the requirements specification during software evolution is a manual and expensive task. Therefore, software engineers usually choose to apply modifications directly to the code and leave the requirements unchanged. This leads to the loss of the knowledge contained in the requirements documents and thus limits the evolvability of a software system. In this paper, we propose to employ the co-evolution of the code and its test suite to preserve or restore the alignment between implementation and requirements: when a change has been applied to the code, subsequent changes in the test suite as well as failing tests are analyzed and used to automatically generate hints about the affected requirements and how they should be changed. These hints support the engineer in maintaining the requirements specification and thus ease the further evolution of the software system.","PeriodicalId":443035,"journal":{"name":"IWPSE-EVOL '10","volume":"49 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132797946","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}
IWPSE-EVOL '10Pub Date : 2010-09-20DOI: 10.1145/1862372.1862378
Shinpei Hayashi, M. Saeki
{"title":"Recording finer-grained software evolution with IDE: an annotation-based approach","authors":"Shinpei Hayashi, M. Saeki","doi":"10.1145/1862372.1862378","DOIUrl":"https://doi.org/10.1145/1862372.1862378","url":null,"abstract":"This paper proposes a formalized technique for generating finer-grained source code deltas according to a developer's editing intentions. Using the technique, the developer classifies edit operations of source code by annotating the time series of the edit history with the switching information of their editing intentions. Based on the classification, the history is sorted and converted automatically to appropriate source code deltas to be committed separately to a version repository. This paper also presents algorithms for automating the generation process and a prototyping tool to implement them.","PeriodicalId":443035,"journal":{"name":"IWPSE-EVOL '10","volume":"191 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116459951","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}
IWPSE-EVOL '10Pub Date : 2010-09-20DOI: 10.1145/1862372.1862382
J. Geet, Peter Ebraert, S. Demeyer
{"title":"Redocumentation of a legacy banking system: an experience report","authors":"J. Geet, Peter Ebraert, S. Demeyer","doi":"10.1145/1862372.1862382","DOIUrl":"https://doi.org/10.1145/1862372.1862382","url":null,"abstract":"Successful software systems need to be maintained. In order to do that, deep knowledge about their architecture and implementation details is required. This knowledge is often kept implicit (inside the heads of the experts) and sometimes made explicit in documentation. The problem is that systems often lack up-to-date documentation and that system experts are frequently unavailable (as they got another job or retired). Redocumentation addresses that problem by recovering knowledge about the system and making it explicit in documentation. Automating the redocumentation process can limit the tedious and error-prone manual effort, but it is no 'silver bullet'. In this paper, we report on our experience with applying redocumentation techniques in industry. We provide insights on what (not) to document, what (not) to automate and how to automate it. A concrete lesson learned during this study is that the \"less is more\" principle also applies to redocumentation.","PeriodicalId":443035,"journal":{"name":"IWPSE-EVOL '10","volume":"17 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132455268","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}
IWPSE-EVOL '10Pub Date : 2010-09-20DOI: 10.1145/1862372.1862386
M. V. Amstel, M. Brand, Luc Engelen
{"title":"An exercise in iterative domain-specific language design","authors":"M. V. Amstel, M. Brand, Luc Engelen","doi":"10.1145/1862372.1862386","DOIUrl":"https://doi.org/10.1145/1862372.1862386","url":null,"abstract":"We describe our experiences with the process of designing a domain-specific language (DSL) and corresponding model transformations. The simultaneous development of the language and the transformations has lead to an iterative evolution of the DSL. We identified four main influences on the evolution of our DSL: the problem domain, the target platforms, model quality, and model transformation quality.\u0000 Our DSL is aimed at modeling the structure and behavior of distributed communicating systems. Simultaneously with the development of our DSL, we implemented three model transformations to different formalisms: one for simulation, one for execution, and one for verification. Transformations to each of these formalisms were implemented one at the time, while preserving the validity of the existing ones. The DSL and the formalisms for simulation, execution, and verification have different semantic characteristics. We also implemented a number of model transformations that bridge the semantic gaps between our DSL and each of the three formalisms. In this paper, we describe our development process and how the aforementioned influences have caused our DSL to evolve.","PeriodicalId":443035,"journal":{"name":"IWPSE-EVOL '10","volume":"29 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127140372","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}
IWPSE-EVOL '10Pub Date : 2010-09-20DOI: 10.1145/1862372.1862379
Lile Hattori, M. Lungu, Michele Lanza
{"title":"Replaying past changes in multi-developer projects","authors":"Lile Hattori, M. Lungu, Michele Lanza","doi":"10.1145/1862372.1862379","DOIUrl":"https://doi.org/10.1145/1862372.1862379","url":null,"abstract":"What was I working on before the weekend? and What were the members of my team working on during the last week? are common questions that are frequently asked by a developer. They can be answered if one keeps track of who changes what in the source code. In this work, we present Replay, a tool that allows one to replay past changes as they happened at a fine-grained level, where a developer can watch what she has done or understand what her colleagues have done in past development sessions. With this tool, developers are able to not only understand what sequence of changes brought the system to a certain state (e.g., the introduction of a defect), but also deduce reasons for why her colleagues performed those changes. One of the applications of such a tool is also discovering the changes that broke the code of a developer.","PeriodicalId":443035,"journal":{"name":"IWPSE-EVOL '10","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-09-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115156160","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}