{"title":"软件工程的问题框架方法","authors":"M. Jackson","doi":"10.1109/APSEC.2007.91","DOIUrl":null,"url":null,"abstract":"Software-intensive systems are those in which the computer executing the software is only one of the parts of the system. Problem frames offer a conceptual structure for the development of such systems: that is, a coherent way of analysing the problem to be solved, identifying the concerns and difficulties that it poses, and working towards a solution. This tutorial present the basic ideas of problem frames, illustrating them in the context of a small software-intensive system. The basic ideas of the approach are: 1. to attend both to the hardware/software machine, which is to be developed, and to the other system parts, which constitute the problem world; 2. to distinguish the given properties of the problem world from the requirements, which are the properties that the machine must establish and maintain in the world; 3. to pay careful attention to the phenomena of the problem world; 4. to structure the development problem as a set of subproblems, and to consider each subproblem in isolation before considering the composition of the subproblems and their solutions; 5. so far as possible, to recognise each subproblem as a member of a recognised class for which a solution method is known and whose most important concerns have been identified. Problem frames are not a notation or a calculus or a formalism; nor are they a development method or a process. They can fit with, into, or around specific techniques (such as agile or RUP) and specific notations (such as UML, Petri nets, or DFDs). Problem frames do not promise a prescription for every problem; nor do they promise a complete prescription for any problem. They remind you of things you know already, but may not always pay enough attention to.","PeriodicalId":273688,"journal":{"name":"14th Asia-Pacific Software Engineering Conference (APSEC'07)","volume":"76 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2007-12-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"14","resultStr":"{\"title\":\"The Problem Frames Approach to Software Engineering\",\"authors\":\"M. Jackson\",\"doi\":\"10.1109/APSEC.2007.91\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Software-intensive systems are those in which the computer executing the software is only one of the parts of the system. Problem frames offer a conceptual structure for the development of such systems: that is, a coherent way of analysing the problem to be solved, identifying the concerns and difficulties that it poses, and working towards a solution. This tutorial present the basic ideas of problem frames, illustrating them in the context of a small software-intensive system. The basic ideas of the approach are: 1. to attend both to the hardware/software machine, which is to be developed, and to the other system parts, which constitute the problem world; 2. to distinguish the given properties of the problem world from the requirements, which are the properties that the machine must establish and maintain in the world; 3. to pay careful attention to the phenomena of the problem world; 4. to structure the development problem as a set of subproblems, and to consider each subproblem in isolation before considering the composition of the subproblems and their solutions; 5. so far as possible, to recognise each subproblem as a member of a recognised class for which a solution method is known and whose most important concerns have been identified. Problem frames are not a notation or a calculus or a formalism; nor are they a development method or a process. They can fit with, into, or around specific techniques (such as agile or RUP) and specific notations (such as UML, Petri nets, or DFDs). Problem frames do not promise a prescription for every problem; nor do they promise a complete prescription for any problem. They remind you of things you know already, but may not always pay enough attention to.\",\"PeriodicalId\":273688,\"journal\":{\"name\":\"14th Asia-Pacific Software Engineering Conference (APSEC'07)\",\"volume\":\"76 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2007-12-04\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"14\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"14th Asia-Pacific Software Engineering Conference (APSEC'07)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/APSEC.2007.91\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"14th Asia-Pacific Software Engineering Conference (APSEC'07)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/APSEC.2007.91","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
The Problem Frames Approach to Software Engineering
Software-intensive systems are those in which the computer executing the software is only one of the parts of the system. Problem frames offer a conceptual structure for the development of such systems: that is, a coherent way of analysing the problem to be solved, identifying the concerns and difficulties that it poses, and working towards a solution. This tutorial present the basic ideas of problem frames, illustrating them in the context of a small software-intensive system. The basic ideas of the approach are: 1. to attend both to the hardware/software machine, which is to be developed, and to the other system parts, which constitute the problem world; 2. to distinguish the given properties of the problem world from the requirements, which are the properties that the machine must establish and maintain in the world; 3. to pay careful attention to the phenomena of the problem world; 4. to structure the development problem as a set of subproblems, and to consider each subproblem in isolation before considering the composition of the subproblems and their solutions; 5. so far as possible, to recognise each subproblem as a member of a recognised class for which a solution method is known and whose most important concerns have been identified. Problem frames are not a notation or a calculus or a formalism; nor are they a development method or a process. They can fit with, into, or around specific techniques (such as agile or RUP) and specific notations (such as UML, Petri nets, or DFDs). Problem frames do not promise a prescription for every problem; nor do they promise a complete prescription for any problem. They remind you of things you know already, but may not always pay enough attention to.