{"title":"设计可执行的抽象","authors":"G. Holzmann","doi":"10.1145/298595.298864","DOIUrl":null,"url":null,"abstract":"1. ABSTRACT It is well-known that in general the problem of deciding whether a program halts (or can deadlock) is undecidable. Model checkers, therefore, cannot be applied to arbitrary programs, but work with well-defined abstractions of programs. The feasibility of a verification often depends on the type of abstraction that is made. Abstraction is indeed the most powerful tool that the user of a model checking tool can apply, yet it is often perceived as a temporary inconvenience.","PeriodicalId":125560,"journal":{"name":"Formal Methods in Software Practice","volume":"3 4 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1998-03-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"26","resultStr":"{\"title\":\"Designing executable abstractions\",\"authors\":\"G. Holzmann\",\"doi\":\"10.1145/298595.298864\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"1. ABSTRACT It is well-known that in general the problem of deciding whether a program halts (or can deadlock) is undecidable. Model checkers, therefore, cannot be applied to arbitrary programs, but work with well-defined abstractions of programs. The feasibility of a verification often depends on the type of abstraction that is made. Abstraction is indeed the most powerful tool that the user of a model checking tool can apply, yet it is often perceived as a temporary inconvenience.\",\"PeriodicalId\":125560,\"journal\":{\"name\":\"Formal Methods in Software Practice\",\"volume\":\"3 4 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1998-03-04\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"26\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Formal Methods in Software Practice\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/298595.298864\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Formal Methods in Software Practice","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/298595.298864","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
1. ABSTRACT It is well-known that in general the problem of deciding whether a program halts (or can deadlock) is undecidable. Model checkers, therefore, cannot be applied to arbitrary programs, but work with well-defined abstractions of programs. The feasibility of a verification often depends on the type of abstraction that is made. Abstraction is indeed the most powerful tool that the user of a model checking tool can apply, yet it is often perceived as a temporary inconvenience.