Data-flow design techniques and the functional programming style both decompose problems in a data-driven fashion. We propose a method based on data-flow diagrams which yields designs which can be mechanically translated into code written in a functional programming language. Users who specify or design systems with data-flow techniques can effectively execute their specifications or designs with a minimum of additional &sign decisions and without recourse to a programming language. Data-flow diagram elements behave as programming constructs in a “visual pmgramming” language. The paper solves a single problem to illustrate the methodology and show the kind of code produced. 1. A Functional Design Methodology The potential which a functional programming language has for producing programs capable of running on parallel hardware is beginning to be exploited by hardware designers looking to produce experimental parallel machines[l]. Ultimately these promise to turn into extremely fast, widely available computing engines on which many of the substantial processing tasks of the future will be performed. However most programmers would agree that a language like Hopc[2] imposes a “functional programming style” which may not very closely match the types of problems which they are trying to solve. The software crisis is happening in the commercial and industrial arcnas[3], not in research laboratories, and academics and rescarchcrs must be careful not to provide solutions to problems which pcople don’t actually have. What we thought was needed was a functional design methodology which decomposed typical problems in such a way that the functional programming style would suggest itself at the implementation stage. WC were attracted to the family of data driven design methodologies because there appear to be some similarities between the data driven design philosophy and the functional programming philosophy. A data driven design tcchniquc dccomposcs a problem into a network of processes linked by durujbws, this arrangement being represented pictorially as a “data-flow diagram”“, or more usually, a hierarchy of data-flow diagrams. In constructing these designs, no consideration is given to the flow of “control”. Likewise, functional programming languages are characterizcd by an absence of control-flow constructs dictated by the requirement for rcfcrcntial transparcncy[4]. Instead functions are invoked by the existence of their argumznfs (incoming flows) rather than by programmer initiation, and the evaluation model envisages the functional components of a program executing in parallel on a network of processors. A data-flow diagram can be thought of therefore as a circuit diagram for a configuration of processors built to execute the corresponding (functional) program. The problem is that a set of data-flow diagrams is an informal represenmtion of one particular aspect of a program’s design while the ultimate pmgram is formal at least in the sense that there
{"title":"Data-flow design as a visual programming language","authors":"S. Eisenbach, Lee McLoughlin, C. Sadler","doi":"10.1145/75199.75242","DOIUrl":"https://doi.org/10.1145/75199.75242","url":null,"abstract":"Data-flow design techniques and the functional programming style both decompose problems in a data-driven fashion. We propose a method based on data-flow diagrams which yields designs which can be mechanically translated into code written in a functional programming language. Users who specify or design systems with data-flow techniques can effectively execute their specifications or designs with a minimum of additional &sign decisions and without recourse to a programming language. Data-flow diagram elements behave as programming constructs in a “visual pmgramming” language. The paper solves a single problem to illustrate the methodology and show the kind of code produced. 1. A Functional Design Methodology The potential which a functional programming language has for producing programs capable of running on parallel hardware is beginning to be exploited by hardware designers looking to produce experimental parallel machines[l]. Ultimately these promise to turn into extremely fast, widely available computing engines on which many of the substantial processing tasks of the future will be performed. However most programmers would agree that a language like Hopc[2] imposes a “functional programming style” which may not very closely match the types of problems which they are trying to solve. The software crisis is happening in the commercial and industrial arcnas[3], not in research laboratories, and academics and rescarchcrs must be careful not to provide solutions to problems which pcople don’t actually have. What we thought was needed was a functional design methodology which decomposed typical problems in such a way that the functional programming style would suggest itself at the implementation stage. WC were attracted to the family of data driven design methodologies because there appear to be some similarities between the data driven design philosophy and the functional programming philosophy. A data driven design tcchniquc dccomposcs a problem into a network of processes linked by durujbws, this arrangement being represented pictorially as a “data-flow diagram”“, or more usually, a hierarchy of data-flow diagrams. In constructing these designs, no consideration is given to the flow of “control”. Likewise, functional programming languages are characterizcd by an absence of control-flow constructs dictated by the requirement for rcfcrcntial transparcncy[4]. Instead functions are invoked by the existence of their argumznfs (incoming flows) rather than by programmer initiation, and the evaluation model envisages the functional components of a program executing in parallel on a network of processors. A data-flow diagram can be thought of therefore as a circuit diagram for a configuration of processors built to execute the corresponding (functional) program. The problem is that a set of data-flow diagrams is an informal represenmtion of one particular aspect of a program’s design while the ultimate pmgram is formal at least in the sense that there","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"68 5","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1989-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133237848","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}
Any methodology for the design of a complex system needs a basis for specification and verification. This is particularly so for realtime systems since safety and reliability ate extremely important for these systems. As a first step, we provide au operational semantics for the language RT-CDL (Real Time Common Design Language) employing Plotkin’s labeled transition systems using the maximal paraheliim model of Salwicki and Miildner. The language is based on the event-action model and is capable of (i) expressing various timing constraints, (ii) responding to various teal-time exceptions, and (iii) specifying, reasoning, verifying about programs in a compositional manner. We show how to model the behavior of non-buffered broadcasts, durational events, priority, interrupts, and preemptive commands through the semantics. Our approach is compositional and thus provides a firm basis for compositional specification and verification of pmgrams. 1. Motivation and Related Work One of the primary objectives of Ada has been the programmability of real-time embedded systems. However, the definition of Ada [3] allows a high-priority task to wait for a low-priority task for an unpredictable delay. Furthetmore. Ada lacks the power of hamessing the parallelism inherent in mal-time systems. For instance, in Ada, we caunot even interleave some of the operations that am possible in the monitor-based languages--which is a disadvantage at many times. The rendezvous mechanism places a lot of restriction with reference to realizing multiform clocks and harnessing parallelism. Another notable point is that even though the traditional description tools of industrial process control systems arc intrinsically parallel, it is paradoxical that the computerization of these systems results in the progressive replacement of these parallel tools by programming languages involving a great amount of sequential&y. There has been quite a substantial effort in looking for specification/programming languages for real-time distributed systems. However, if we look at requirements for real-time languages [41, we can come to the conclusion that most of these Permission to CODV without fee ah or Dart of this material is eranted provided that the &pies are not made or &stributed for direct com;hercial advantaee. the ACM couvricht notice and the title of the Dubhcation and its date>ppear, and no&% given that copying is by p&uission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/oi specific permi&on. 01989 ACM 0-89791~305-1/89/0500/0075$00.75 languages fall short of expectations. For example, many languages do not provide any explicit means of correctly specifying timing constraints, or are limited to either delay or timeout statement [lo]. This limitation not only reduces the expressive power of languages (and hence cannot be used in certain applications such as switching and digital systems) but also makes it difficult to reason about the
{"title":"An operational semantics of real time design language RT-CDL","authors":"L. Y. Liu, R. Shyamasundar","doi":"10.1145/75199.75212","DOIUrl":"https://doi.org/10.1145/75199.75212","url":null,"abstract":"Any methodology for the design of a complex system needs a basis for specification and verification. This is particularly so for realtime systems since safety and reliability ate extremely important for these systems. As a first step, we provide au operational semantics for the language RT-CDL (Real Time Common Design Language) employing Plotkin’s labeled transition systems using the maximal paraheliim model of Salwicki and Miildner. The language is based on the event-action model and is capable of (i) expressing various timing constraints, (ii) responding to various teal-time exceptions, and (iii) specifying, reasoning, verifying about programs in a compositional manner. We show how to model the behavior of non-buffered broadcasts, durational events, priority, interrupts, and preemptive commands through the semantics. Our approach is compositional and thus provides a firm basis for compositional specification and verification of pmgrams. 1. Motivation and Related Work One of the primary objectives of Ada has been the programmability of real-time embedded systems. However, the definition of Ada [3] allows a high-priority task to wait for a low-priority task for an unpredictable delay. Furthetmore. Ada lacks the power of hamessing the parallelism inherent in mal-time systems. For instance, in Ada, we caunot even interleave some of the operations that am possible in the monitor-based languages--which is a disadvantage at many times. The rendezvous mechanism places a lot of restriction with reference to realizing multiform clocks and harnessing parallelism. Another notable point is that even though the traditional description tools of industrial process control systems arc intrinsically parallel, it is paradoxical that the computerization of these systems results in the progressive replacement of these parallel tools by programming languages involving a great amount of sequential&y. There has been quite a substantial effort in looking for specification/programming languages for real-time distributed systems. However, if we look at requirements for real-time languages [41, we can come to the conclusion that most of these Permission to CODV without fee ah or Dart of this material is eranted provided that the &pies are not made or &stributed for direct com;hercial advantaee. the ACM couvricht notice and the title of the Dubhcation and its date>ppear, and no&% given that copying is by p&uission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/oi specific permi&on. 01989 ACM 0-89791~305-1/89/0500/0075$00.75 languages fall short of expectations. For example, many languages do not provide any explicit means of correctly specifying timing constraints, or are limited to either delay or timeout statement [lo]. This limitation not only reduces the expressive power of languages (and hence cannot be used in certain applications such as switching and digital systems) but also makes it difficult to reason about the","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"46 2 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":"115990195","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}
Gerald B. Williams, Chunka Mui, Vairam Alagappan, Bruce B. Johnson
Research in software engineering is concerned with the enhancement and automation of the processes of building computer application systems. While there is a broad consensus on the problems associated with software development, a specific understanding of the software engineering problem and the appropriate solutions are inevitably driven by the target application domain. Much of the current software engineering research is driven by the development of large scale embedded software systems. Our understanding of the problems is based on a different domain: that of very large information systems (VLIS). In this paper, we identify some significant software engineering problems from the context of developing very large information systems.
{"title":"Software design issues: a very large information systems perspective","authors":"Gerald B. Williams, Chunka Mui, Vairam Alagappan, Bruce B. Johnson","doi":"10.1145/75199.75235","DOIUrl":"https://doi.org/10.1145/75199.75235","url":null,"abstract":"Research in software engineering is concerned with the enhancement and automation of the processes of building computer application systems. While there is a broad consensus on the problems associated with software development, a specific understanding of the software engineering problem and the appropriate solutions are inevitably driven by the target application domain. Much of the current software engineering research is driven by the development of large scale embedded software systems. Our understanding of the problems is based on a different domain: that of very large information systems (VLIS). In this paper, we identify some significant software engineering problems from the context of developing very large information systems.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"70 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":"132038827","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 have been studying a model of software specification design which begins with a trivially simple specification, incrementally elaborates it in a number of parallel “lines” of design, and merges the specifications that result from each of those divergent lines to achieve the fully detailed specification. We employ “evolutionary” transformations that is, transformations whose very purpose is to change meaning to perform the elaborations in the design lines, and thereafter achieve merging by replaying the transformations in a serial order. Merging does not always proceed smoothly: on occasions the different lines of design interfere with one another in some manner, inhibiting the serial replay of their evolutionary transformations. We show that by comparing how the transformations change specification properties (herein we consider the properties of terminology and usage), certain kinds of interference can be detected, and in some cases means to deal with it suggested. L Specification evolution via transformation While traditionally the software design process has started with a specification and worked towards an implementation, we have come to believe that the construction of the starting specification is also an important and complex design process. We have studied a process in which specification construction is incremental the specification is gradualiy evolved from a trivially simple starting point by means of a series of evolutionary steps. We have built mechanisms for performing these via “evolutionary transformations”, akin to the transformations of conventional program transformation work, except they deliberately change the meaning of the specifications to which they are applied. In contrast, conventional transformations generally keep the meaning of the specification constant (so called “correctness-preserving”) while improving efficiency (sometimes they “shrink” the meaning, i.e., when the initial specification admits to alternative implementations, the transformations may be 01969 ACM 0-69791~305-1/69/0500/0169$00.75 allowed to select from among those, but in any event they never introduce new possibilities). Similar research has been done in the area of modifications to type lattices and database schemes: in (21 a classification of possible changes to a type lattice is given, and used to suggest means for adapting existing data and operations on that data accordingly. Similar changes are considered in [lo], where the focus is on constructing methods to handle clashes between objects and programs created under different versions of the type lattice. Recently in (61 it is argued that several machine learning techniques can help in the task of making these same kinds of modifications to databases. 1.1 Parallel lines of design We found that different evolution steps are often independent, or nearly so. This prompted us to apply those steps in parallel, giving rise to several different lines of design. The specifications that result fro
{"title":"Detecting interference when merging specification evolutions","authors":"M. Feather","doi":"10.1145/75199.75226","DOIUrl":"https://doi.org/10.1145/75199.75226","url":null,"abstract":"We have been studying a model of software specification design which begins with a trivially simple specification, incrementally elaborates it in a number of parallel “lines” of design, and merges the specifications that result from each of those divergent lines to achieve the fully detailed specification. We employ “evolutionary” transformations that is, transformations whose very purpose is to change meaning to perform the elaborations in the design lines, and thereafter achieve merging by replaying the transformations in a serial order. Merging does not always proceed smoothly: on occasions the different lines of design interfere with one another in some manner, inhibiting the serial replay of their evolutionary transformations. We show that by comparing how the transformations change specification properties (herein we consider the properties of terminology and usage), certain kinds of interference can be detected, and in some cases means to deal with it suggested. L Specification evolution via transformation While traditionally the software design process has started with a specification and worked towards an implementation, we have come to believe that the construction of the starting specification is also an important and complex design process. We have studied a process in which specification construction is incremental the specification is gradualiy evolved from a trivially simple starting point by means of a series of evolutionary steps. We have built mechanisms for performing these via “evolutionary transformations”, akin to the transformations of conventional program transformation work, except they deliberately change the meaning of the specifications to which they are applied. In contrast, conventional transformations generally keep the meaning of the specification constant (so called “correctness-preserving”) while improving efficiency (sometimes they “shrink” the meaning, i.e., when the initial specification admits to alternative implementations, the transformations may be 01969 ACM 0-69791~305-1/69/0500/0169$00.75 allowed to select from among those, but in any event they never introduce new possibilities). Similar research has been done in the area of modifications to type lattices and database schemes: in (21 a classification of possible changes to a type lattice is given, and used to suggest means for adapting existing data and operations on that data accordingly. Similar changes are considered in [lo], where the focus is on constructing methods to handle clashes between objects and programs created under different versions of the type lattice. Recently in (61 it is argued that several machine learning techniques can help in the task of making these same kinds of modifications to databases. 1.1 Parallel lines of design We found that different evolution steps are often independent, or nearly so. This prompted us to apply those steps in parallel, giving rise to several different lines of design. The specifications that result fro","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"38 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":"133715702","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}
This paper describes developments and experience in the ESPRIT project 1283: “VDM for Interfaces of the PCTE”. It shows the way temporal logic is used in combination with the relational VDM method in order to write interface specifications for large reactive systems. It is shown tlhat in this way a specification can be written both usable for implementors and users of an interface. The ability to dlistinguish within the logic between an internal and an external action appears to be very important.
{"title":"Interface specification with temporal logic","authors":"M. Kooij","doi":"10.1145/75199.75216","DOIUrl":"https://doi.org/10.1145/75199.75216","url":null,"abstract":"This paper describes developments and experience in the ESPRIT project 1283: “VDM for Interfaces of the PCTE”. It shows the way temporal logic is used in combination with the relational VDM method in order to write interface specifications for large reactive systems. It is shown tlhat in this way a specification can be written both usable for implementors and users of an interface. The ability to dlistinguish within the logic between an internal and an external action appears to be very important.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"44 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":"124874171","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 use the Z specification language to specify the designs of two reusable components and their interfaces. The components are based on set:3 and dictionaries from Smalltalk, each of which can provide surprises to users. We prove a significant property of desired behavior of the specifications under the precondition expected by the implementations. Specification and proof played an important role in our understanding of the components.
{"title":"Specifying reusable components using Z: realistic sets and dictionaries","authors":"R. L. London, K. Milsted","doi":"10.1145/75199.75218","DOIUrl":"https://doi.org/10.1145/75199.75218","url":null,"abstract":"We use the Z specification language to specify the designs of two reusable components and their interfaces. The components are based on set:3 and dictionaries from Smalltalk, each of which can provide surprises to users. We prove a significant property of desired behavior of the specifications under the precondition expected by the implementations. Specification and proof played an important role in our understanding of the components.","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"51 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":"131058041","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}
{"title":"Software development using models","authors":"R. D'Ippolito, C. Plinta","doi":"10.1145/75199.75221","DOIUrl":"https://doi.org/10.1145/75199.75221","url":null,"abstract":"","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"23 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":"128566244","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 implementation of the Requirements Apprentice has reached the point where it is possible to exhibit a concrete scenario showing the intended basic capabilities of the system. The Requirements Apprentice accepts ambiguous, incomplete, and inconsistent input from a requirements analyst and assists the analyst in creating and validating a coherent requirements description. This processing is supported by a general-purpose reasoning system and a library of requirements cliches that contains reusable descriptions of standard concepts used in requirements. 1 The Requirements Apprentice The philosophy underlying the Requirements Apprentice (RA) is laid out in detail in [14]. In the interest of brevity, this discussion will not be repeated here. However, it is important to keep in mind the position occupied by the RA in the requirements acquisition process. As illustrated by Figure 1, the RA is intended to assist a requirements analyst. The analyst begins the requirements acquisition process by means of a “skull session” that illicits an informal idea of what. is wanted. A good example of the result of such a skull session is the library database requirement sketch [l] that was used as a benchmark by previous Workshops on Software Specification and Design. Starting from such an informal requirements sketch, the RA aLsist.s an analyst (and through the analyst, the end user) t.o arrive at a more complete and more formal requirement. In I his, the RA continues in the tradition of the SAFE project ]2] and differs from most current work on software requirements tools (e.g., [4, 7, 111) that focuses instead on the validation of a requirement that is already stated in a formal way. Viewed from an artificial intelligence perspective, the problem faced by the RA is essentially one of knowledge acqrhitim. Related systems in this area include KLATJS[.lO] and ROGET[5], which provide automated assistance for arquiring new rules for expert systems. These tools support Pernksion to copy without fee all or pert of this material is granted provided that the copies arc not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy othc&se, or to republish, requires a fee and/or specific permission. l D Analyst + Requirements Knowledge Base
{"title":"The requirements apprentice: an initial scenario","authors":"H. Reubenstein, R. Waters","doi":"10.1145/75199.75231","DOIUrl":"https://doi.org/10.1145/75199.75231","url":null,"abstract":"The implementation of the Requirements Apprentice has reached the point where it is possible to exhibit a concrete scenario showing the intended basic capabilities of the system. The Requirements Apprentice accepts ambiguous, incomplete, and inconsistent input from a requirements analyst and assists the analyst in creating and validating a coherent requirements description. This processing is supported by a general-purpose reasoning system and a library of requirements cliches that contains reusable descriptions of standard concepts used in requirements. 1 The Requirements Apprentice The philosophy underlying the Requirements Apprentice (RA) is laid out in detail in [14]. In the interest of brevity, this discussion will not be repeated here. However, it is important to keep in mind the position occupied by the RA in the requirements acquisition process. As illustrated by Figure 1, the RA is intended to assist a requirements analyst. The analyst begins the requirements acquisition process by means of a “skull session” that illicits an informal idea of what. is wanted. A good example of the result of such a skull session is the library database requirement sketch [l] that was used as a benchmark by previous Workshops on Software Specification and Design. Starting from such an informal requirements sketch, the RA aLsist.s an analyst (and through the analyst, the end user) t.o arrive at a more complete and more formal requirement. In I his, the RA continues in the tradition of the SAFE project ]2] and differs from most current work on software requirements tools (e.g., [4, 7, 111) that focuses instead on the validation of a requirement that is already stated in a formal way. Viewed from an artificial intelligence perspective, the problem faced by the RA is essentially one of knowledge acqrhitim. Related systems in this area include KLATJS[.lO] and ROGET[5], which provide automated assistance for arquiring new rules for expert systems. These tools support Pernksion to copy without fee all or pert of this material is granted provided that the copies arc not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy othc&se, or to republish, requires a fee and/or specific permission. l D Analyst + Requirements Knowledge Base","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"75 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":"114556766","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 we give an example of the use of functional programming language in the specification and development of a program to solve a non-trivial problem. In particular, we show how we can give a direct implementation of a constructive specification (an execuiable specification, in other words) and then show how program transformation can be used to turn this specification into an efficient version of the program, using techniques from a standard library of transformations. We introduce the paper with a short review of functional programming. 1 Functional Programming In this section we introduce the major ideas of functional programming, as exemplified by Miranda ‘[4], (pure) ML [5] and various other languages ([3]). The language which we use here is Miranda, in fact. The process underlying functional programming is one which we learn in elementary school, before we are exposed to micros, BASIC e2 al.. This is the process of calculation. Given an expression like (2 + 3)/(7 2) we learn that we first have to evaluate the sub-expressions (2+3) and (7-2), and then apply the operator ‘1’. This is exactly what we do when we run a functional program we calculate the value of an expression, which may involve operators or functions which are defined by the user. Consider an example. To work out the sum of squares of the first hundred positive integers, we calculate the value of sum-of -squares loowhere sum-of-squares n = n*n t sum-of-squares (n-1) , 01 = 1 , otherwise 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 and 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 specific permission. This operator describes what the sum is, in a natural way if n is greater than one, we square it and add it to the sum up to n-l, if not, the answer is immediate one. Observe that we can read the above not only as a definition, but also a property of the function sum-of-squares. Function definitions are their own descriptions. This is not true of imperative languages, in which a program description has to be written in a logic separate from the language itself. Take an example of evaluation, in which we abbreviate sum-of-squares by SOS: SOS 3 = 3*3 + (SOS 2)
{"title":"Functional programming: executable specifications and program transformations","authors":"S. Thompson","doi":"10.1145/75199.75244","DOIUrl":"https://doi.org/10.1145/75199.75244","url":null,"abstract":"In this paper we give an example of the use of functional programming language in the specification and development of a program to solve a non-trivial problem. In particular, we show how we can give a direct implementation of a constructive specification (an execuiable specification, in other words) and then show how program transformation can be used to turn this specification into an efficient version of the program, using techniques from a standard library of transformations. We introduce the paper with a short review of functional programming. 1 Functional Programming In this section we introduce the major ideas of functional programming, as exemplified by Miranda ‘[4], (pure) ML [5] and various other languages ([3]). The language which we use here is Miranda, in fact. The process underlying functional programming is one which we learn in elementary school, before we are exposed to micros, BASIC e2 al.. This is the process of calculation. Given an expression like (2 + 3)/(7 2) we learn that we first have to evaluate the sub-expressions (2+3) and (7-2), and then apply the operator ‘1’. This is exactly what we do when we run a functional program we calculate the value of an expression, which may involve operators or functions which are defined by the user. Consider an example. To work out the sum of squares of the first hundred positive integers, we calculate the value of sum-of -squares loowhere sum-of-squares n = n*n t sum-of-squares (n-1) , 01 = 1 , otherwise 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 and 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 specific permission. This operator describes what the sum is, in a natural way if n is greater than one, we square it and add it to the sum up to n-l, if not, the answer is immediate one. Observe that we can read the above not only as a definition, but also a property of the function sum-of-squares. Function definitions are their own descriptions. This is not true of imperative languages, in which a program description has to be written in a logic separate from the language itself. Take an example of evaluation, in which we abbreviate sum-of-squares by SOS: SOS 3 = 3*3 + (SOS 2)","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"15 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":"114623133","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}
Software systems can be conveniently described, constructed and managed in terms of their configuration, where configuration is the system structure defined as the set of constituent software components together with their interconnections. A specification of the system configuration can be used both to describe the required system structure and to generate the actual system itself. The performance of these tasks at the configuration level is termed configuration programming, and is best supported by the use of a declarative configuration language and associated support tools. This paper discusses the main principles of this approach and illustrates its practice by describing the support which has been provided in the Conic environment for distributed systems. These concepts are illustrated by using a simple example: a patient monitoring system (PMS).
{"title":"Configuration support for system description, construction and evolution","authors":"J. Kramer, J. Magee, M. Sloman","doi":"10.1145/75199.75204","DOIUrl":"https://doi.org/10.1145/75199.75204","url":null,"abstract":"Software systems can be conveniently described, constructed and managed in terms of their configuration, where configuration is the system structure defined as the set of constituent software components together with their interconnections. A specification of the system configuration can be used both to describe the required system structure and to generate the actual system itself. The performance of these tasks at the configuration level is termed configuration programming, and is best supported by the use of a declarative configuration language and associated support tools. This paper discusses the main principles of this approach and illustrates its practice by describing the support which has been provided in the Conic environment for distributed systems. These concepts are illustrated by using a simple example: a patient monitoring system (PMS).","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"27 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":"124992470","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
扫码关注我们
求助内容：
应助结果提醒方式：