Bug fixing is expensive and the study of it is a hot research topic in software engineering. During the bug fixing process, developers leverage various software artifacts (e.g., bug reports, commits, log files, source files, etc.) and explore multi-source heterogeneous information (Q&A websites, web resources, software communities, etc.) to reproduce the bugs, locate the bugs, identify candidate fixing solutions, apply the fixes and validate the fixes. The workshop will focus on intelligent bug fixing. Bug fixing process includes bug reproduction, bug localization, bug fixing, bug validation, etc. In this workshop, we solicit highquality contributions in the area of intelligent bug fixing. It is intended to provide timely updates of collecting state-of-the-art technologies that advance intelligent bug fixing using multiple data analytics techniques.
{"title":"Message from the Chairs","authors":"Xiapu Luo, Weiyi Shang, Xiaobing Sun, Lingfeng Bao, Chunrong Fang","doi":"10.1109/ds-rt50469.2020.9213513","DOIUrl":"https://doi.org/10.1109/ds-rt50469.2020.9213513","url":null,"abstract":"Bug fixing is expensive and the study of it is a hot research topic in software engineering. During the bug fixing process, developers leverage various software artifacts (e.g., bug reports, commits, log files, source files, etc.) and explore multi-source heterogeneous information (Q&A websites, web resources, software communities, etc.) to reproduce the bugs, locate the bugs, identify candidate fixing solutions, apply the fixes and validate the fixes. The workshop will focus on intelligent bug fixing. Bug fixing process includes bug reproduction, bug localization, bug fixing, bug validation, etc. In this workshop, we solicit highquality contributions in the area of intelligent bug fixing. It is intended to provide timely updates of collecting state-of-the-art technologies that advance intelligent bug fixing using multiple data analytics techniques.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"65 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125134703","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 design of complex systems requires powerful mechanisms for modeling data, state, communication, and real-time behaviour; as well as for structuring and decomposing systems in order to control local complexity. Timed Communicating Object Z (TCOZ) builds on Object-Z's strengths in modeling complex data and state, and on Timed CSP's strengths in modeling process control and real-time interactions. In this paper, we demonstrate the TCOZ approach to the design and verification of the Teleservices and Remote Medical Care System.
{"title":"TRMCS in TCOZ","authors":"Jing Liu, J. Dong, Jing Sun","doi":"10.5555/857171.857228","DOIUrl":"https://doi.org/10.5555/857171.857228","url":null,"abstract":"The design of complex systems requires powerful mechanisms for modeling data, state, communication, and real-time behaviour; as well as for structuring and decomposing systems in order to control local complexity. Timed Communicating Object Z (TCOZ) builds on Object-Z's strengths in modeling complex data and state, and on Timed CSP's strengths in modeling process control and real-time interactions. In this paper, we demonstrate the TCOZ approach to the design and verification of the Teleservices and Remote Medical Care System.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"35 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2000-11-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130257686","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 notion of feature is widely used to denote the functional structure and visible properties of a software system. More specifically, features are meant to represent a user-centric organization of a software system's functionality. Yet, other than during requirements analysis, features are seldom treated explicitly by most existing tools and methods.This paper argues that a feature-orientation can provide benefits to software developers throughout the software life cycle. We envisage specific applications of the notion of feature that provide a powerful and unifying structure for software life cycle artifacts and activities. We discuss the problems and issues to be addressed, a brief summary of our current research work, and suggestions and directions for future research in a new area we call ``feature engineering''.
{"title":"Feature Engineering","authors":"C. Turner, A. Wolf, A. Fuggetta, L. Lavazza","doi":"10.5555/857205.858311","DOIUrl":"https://doi.org/10.5555/857205.858311","url":null,"abstract":"The notion of feature is widely used to denote the functional structure and visible properties of a software system. More specifically, features are meant to represent a user-centric organization of a software system's functionality. Yet, other than during requirements analysis, features are seldom treated explicitly by most existing tools and methods.This paper argues that a feature-orientation can provide benefits to software developers throughout the software life cycle. We envisage specific applications of the notion of feature that provide a powerful and unifying structure for software life cycle artifacts and activities. We discuss the problems and issues to be addressed, a brief summary of our current research work, and suggestions and directions for future research in a new area we call ``feature engineering''.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128039572","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}
Darwin is a language designed for configuring distributed systems. A system is modelled as a decompositional hierarchy of components with interfaces. Connections are represented as bindings between interfaces. Darwin programs define component types. Configurations of a system are obtained by instantiating these types. Configurations have to comply with a number of constraints on the system structure. It is therefore intuitive to express these constraints in the domain of configurations rather than on the language level. To succeed in this endeavour we need to precisely express the relation between Darwin programs and configurations. We do this in terms of a first-order logic theory of Darwin programs and configurations. Models of the theory provide a straightforward mapping from Darwin programs to configurations and vice versa. Most of the constraints on configurations as well as structural transformations can be specified by adding just a few axioms to the theory. Also the theory enables us to generate Darwin programs from configurations thus allowing for the inclusion of existing systems into new programs.
{"title":"Formalizing System Structure","authors":"Matthias Radestock, S. Eisenbach","doi":"10.5555/857204.858262","DOIUrl":"https://doi.org/10.5555/857204.858262","url":null,"abstract":"Darwin is a language designed for configuring distributed systems. A system is modelled as a decompositional hierarchy of components with interfaces. Connections are represented as bindings between interfaces. Darwin programs define component types. Configurations of a system are obtained by instantiating these types. Configurations have to comply with a number of constraints on the system structure. It is therefore intuitive to express these constraints in the domain of configurations rather than on the language level. To succeed in this endeavour we need to precisely express the relation between Darwin programs and configurations. We do this in terms of a first-order logic theory of Darwin programs and configurations. Models of the theory provide a straightforward mapping from Darwin programs to configurations and vice versa. Most of the constraints on configurations as well as structural transformations can be specified by adding just a few axioms to the theory. Also the theory enables us to generate Darwin programs from configurations thus allowing for the inclusion of existing systems into new programs.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"42 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-03-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126125698","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 paper concerns an approach to software development which is referred to as Component Based Software Engineering (CBSE). The approach is based on the principle of extensive use of preexisting, standard or customizable components in building new systems. CBSE has received considerable attention recently since it promises to bring to software development the engineering discipline that has been long accepted in more mature engineering domains. We describe the design of a specification language intended for support of basic CBSE activities; the Architecture Specification Language (ASL). More specifically, we show how the language design choices have been driven by our understanding and prioritization of the concerns of the key stakeholders involved in the software development process.
{"title":"Concern-driven design for a specification language supporting component-based software engineerin","authors":"W. Kozaczynski, J. Ning","doi":"10.5555/857204.858273","DOIUrl":"https://doi.org/10.5555/857204.858273","url":null,"abstract":"The paper concerns an approach to software development which is referred to as Component Based Software Engineering (CBSE). The approach is based on the principle of extensive use of preexisting, standard or customizable components in building new systems. CBSE has received considerable attention recently since it promises to bring to software development the engineering discipline that has been long accepted in more mature engineering domains. We describe the design of a specification language intended for support of basic CBSE activities; the Architecture Specification Language (ASL). More specifically, we show how the language design choices have been driven by our understanding and prioritization of the concerns of the key stakeholders involved in the software development process.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"171 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-03-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131606576","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}
Swarm is a concurrent programming model which integrates a Linda-like communication medium, the shared dataspace, with a UNITY-like computational model, proof system, and program structure. It generalizes the Linda tuple-space operations by providing more powerful dataspace queries. It generalizes UNITY by permitting content-based access to data, a dynamic set of statements, and the capability to control the execution mode (i.e., synchronous or asynchronous) for arbitrary collections of program statements.
{"title":"Swarming over the software barrier","authors":"H. C. Cunningham","doi":"10.5555/952786.952821","DOIUrl":"https://doi.org/10.5555/952786.952821","url":null,"abstract":"Swarm is a concurrent programming model which integrates a Linda-like communication medium, the shared dataspace, with a UNITY-like computational model, proof system, and program structure. It generalizes the Linda tuple-space operations by providing more powerful dataspace queries. It generalizes UNITY by permitting content-based access to data, a dynamic set of statements, and the capability to control the execution mode (i.e., synchronous or asynchronous) for arbitrary collections of program statements.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"77 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114160460","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 argue that advocates of a formal method have an obligation to explain the relationship between the role of proof in that method and the role of proof in others. Such comparisons are needed to (a) clarify the "method" behind a specific notation, (b) dispel misconceptions invited by the use of similar vocabulary with different meanings, and (c) suggest improvements to existing methods. We illustrate these points by comparing the use of preconditions in Z with that in other formal methods.
{"title":"Preconditions for understanding","authors":"D. Garlan","doi":"10.5555/952786.952823","DOIUrl":"https://doi.org/10.5555/952786.952823","url":null,"abstract":"We argue that advocates of a formal method have an obligation to explain the relationship between the role of proof in that method and the role of proof in others. Such comparisons are needed to (a) clarify the \"method\" behind a specific notation, (b) dispel misconceptions invited by the use of similar vocabulary with different meanings, and (c) suggest improvements to existing methods. We illustrate these points by comparing the use of preconditions in Z with that in other formal methods.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122392157","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 this paper, a formalisation of exceptions to a general rule is proposed. It builds upon the modularisation of theories proposed by the algebraic specification approach, and preserves its engineering principles: modularity and compositionality. It relies on a model-theoretic definition of the "but" conjunctive, whose properties and implementations are explored.
{"title":"On the meaning of \"but\"","authors":"Pierre-Yves Schobbens","doi":"10.5555/952786.952813","DOIUrl":"https://doi.org/10.5555/952786.952813","url":null,"abstract":"In this paper, a formalisation of exceptions to a general rule is proposed. It builds upon the modularisation of theories proposed by the algebraic specification approach, and preserves its engineering principles: modularity and compositionality. It relies on a model-theoretic definition of the \"but\" conjunctive, whose properties and implementations are explored.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"69 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1991-10-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114823707","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}
There is a growing trend to develop software that supports the work of groups, as opposed to individuals. Such software is currently being termed groupwure (Tazelaar 1988), and the technical field is being called computer-supported cooperative work (Greif 1988). One aspect of supporting group work involves coordinating the speaking and actions of teams. A coordinator is software which supports team conversations (Winograd 1988). Coordinators are distinguished from traditional software applications because they contain embedded protocols which describe group work (Holt & Cashmau 1981). This position paper presents guidelines for specifying coordinators. 1. Adaptable Specifications In the past, software engineers interpreted group work as tasks which require coordination. Early coordinators Iike Monster (Holt & Cashman 1981) and XCP (Sluzier & Cashmsn 1984) took the approach of specifying group work as a set of rules which define the work tasks and their interrelationships. Such rule-based specifications have difficulty adapting to particular group work situations. To explain, these specifications sequence work tasks, and so it is diflicult to specify rules without also considering their execution sequence. Not surprisingly, it is sometimes impossible to reliably modify these rules when a work process quickly changes. Croup work is plastic -groups continually redesign they way they work. In fact, the work process of a group is always in a state of flux (Ehn 1988). In order for software to operate effectively in this domain, adaptable specifications must be written. A more flexible approach to specifying coordinators is to define rules for those work tasks that are independent of time. Task sequencing is left up to the group while they do their work. Coordinators like COSMOS (Buckley 1988) have adopted this approach, using a declarative specification language to describe “timeless” work tasks. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication aad its date appear, and notice IS given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specrfic Permission. 2. Specifications Of Conversation Another interpretation of group work is to consider conversation being common to all work activity (Searle 1969, Wmograd & Flores 1986). This interpretation sees work as language which generates action, and action which generates work products. Specifications written from this perspective define how to manage the commitments people make to each other during their work. Examples of these kinds of coordinators ate: CHAOS (DeMichelis 1988), CONTRACT (Mama et. al. May 1987), and The Coordinator (Winograd 1986). Specifications that define structured conversations have the advantage of being less dependent on the actual work being
{"title":"Specifying coordinators: guidelines for groupware developers","authors":"D. Marca","doi":"10.1145/75199.75234","DOIUrl":"https://doi.org/10.1145/75199.75234","url":null,"abstract":"There is a growing trend to develop software that supports the work of groups, as opposed to individuals. Such software is currently being termed groupwure (Tazelaar 1988), and the technical field is being called computer-supported cooperative work (Greif 1988). One aspect of supporting group work involves coordinating the speaking and actions of teams. A coordinator is software which supports team conversations (Winograd 1988). Coordinators are distinguished from traditional software applications because they contain embedded protocols which describe group work (Holt & Cashmau 1981). This position paper presents guidelines for specifying coordinators. 1. Adaptable Specifications In the past, software engineers interpreted group work as tasks which require coordination. Early coordinators Iike Monster (Holt & Cashman 1981) and XCP (Sluzier & Cashmsn 1984) took the approach of specifying group work as a set of rules which define the work tasks and their interrelationships. Such rule-based specifications have difficulty adapting to particular group work situations. To explain, these specifications sequence work tasks, and so it is diflicult to specify rules without also considering their execution sequence. Not surprisingly, it is sometimes impossible to reliably modify these rules when a work process quickly changes. Croup work is plastic -groups continually redesign they way they work. In fact, the work process of a group is always in a state of flux (Ehn 1988). In order for software to operate effectively in this domain, adaptable specifications must be written. A more flexible approach to specifying coordinators is to define rules for those work tasks that are independent of time. Task sequencing is left up to the group while they do their work. Coordinators like COSMOS (Buckley 1988) have adopted this approach, using a declarative specification language to describe “timeless” work tasks. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication aad its date appear, and notice IS given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specrfic Permission. 2. Specifications Of Conversation Another interpretation of group work is to consider conversation being common to all work activity (Searle 1969, Wmograd & Flores 1986). This interpretation sees work as language which generates action, and action which generates work products. Specifications written from this perspective define how to manage the commitments people make to each other during their work. Examples of these kinds of coordinators ate: CHAOS (DeMichelis 1988), CONTRACT (Mama et. al. May 1987), and The Coordinator (Winograd 1986). Specifications that define structured conversations have the advantage of being less dependent on the actual work being ","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1989-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123728163","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 temporal logic [24, 25] or in the logic developed for Unity [10]. External interactions are also modeled as joint actions, without committing to specific communication events between the system and its environment. This means that a joint action system is a closed system containing also a model of its environment. This has an effect on modularity, as will be seen below. For the design process joint action systems provide a framework for stepwise derivation. The initial action system with which this process starts should be simple. Fortunately, the natural ways of structuring action systems support a layered introduction of properties. Bias towards machine architecture or communication primitives does not belong to the initial system, even if the eventual answers to such questions were known from the beginning. No harm is caused at this level by wasteful computations allowed by nondeterminism. Furthermore, the granularity of atomic actions can be coarser than would be feasible in a distributed implementation. Together with independence of communication mechanisms this helps in the avoidance of subtle timing errors. The initial action system is the first baseline for the design process. Being amenable to both formal analysis and experimentation (by simulation and animation), it can be subjected to extensive verification and validation. From this stage the design proceeds by transformations that • refine the atomicity of actions,
{"title":"Action system approach to the specification and design of distributed systems","authors":"R. Kurki-Suonio, Hannu-Matti Järvinen","doi":"10.1145/75199.75205","DOIUrl":"https://doi.org/10.1145/75199.75205","url":null,"abstract":"in temporal logic [24, 25] or in the logic developed for Unity [10]. External interactions are also modeled as joint actions, without committing to specific communication events between the system and its environment. This means that a joint action system is a closed system containing also a model of its environment. This has an effect on modularity, as will be seen below. For the design process joint action systems provide a framework for stepwise derivation. The initial action system with which this process starts should be simple. Fortunately, the natural ways of structuring action systems support a layered introduction of properties. Bias towards machine architecture or communication primitives does not belong to the initial system, even if the eventual answers to such questions were known from the beginning. No harm is caused at this level by wasteful computations allowed by nondeterminism. Furthermore, the granularity of atomic actions can be coarser than would be feasible in a distributed implementation. Together with independence of communication mechanisms this helps in the avoidance of subtle timing errors. The initial action system is the first baseline for the design process. Being amenable to both formal analysis and experimentation (by simulation and animation), it can be subjected to extensive verification and validation. From this stage the design proceeds by transformations that • refine the atomicity of actions,","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1989-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129515993","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
扫码关注我们
求助内容：
应助结果提醒方式：