David Parnas | Middle Road Software (original) (raw)
Prof. David Lorge Parnas, Ph.D., P.Eng.(Ontario);
Dr.h.c.: ETH Zürich,Louvain,Lugano,TU Wien
Fellow: RSC,ACM,CAE,GI,IEEE; MRIA;
Professor Emeritus, CAS, Engineering, McMaster University,
Hamilton, Ontario Canada
Professor Emeritus, CSIS, University of Limerick
Limerick, Ireland
Physical Address:
Ottawa Ontario K1V 1V5
Canada
http://www.amadon.ca/Public/information.htm
Address: Ottawa, Ontario, Canada
less
Uploads
Papers by David Parnas
Lecture Notes in Computer Science, 1975
2009 Ninth International Conference on Quality Software, 2009
Summary form only given: On the road to a successful software product, there are key milestones t... more Summary form only given: On the road to a successful software product, there are key milestones that you should not skip. Each of them is a chance to see if you are on the right path and to correct your direction if you are not. Each milestone is a document that records key design decisions in a way that allows them to be reviewed and analyzed. The meaning of each document must be precisely defined and there must be no ambiguity. If the document is vague and subject to many interpretations, it can lead you down a path from which recovery is difficult. This talk proposes and illustrates a set of software documents that can serve as precise (and immovable) milestones. It discusses how they can be analyzed and used to guide the project on the rest of its trip to completion. To obtain the necessary precision, and to make analysis possible, the documents are mathematical expressions but written in a way that makes them easy to read.
This paper discusses modularization as a mechanism for improving the flexibility and comprehensib... more This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a “modularization ” is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom-positions are discussed. The unconventional decomposi-tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
State Machines have been used to specify the case study "Light Control System". The ASM... more State Machines have been used to specify the case study "Light Control System". The ASM-approach allows one to specify system at different levels of abstraction. One can start with a high level description (u derstandable by the customer) and refine it (defining all used functions) to a deta iled version which is executable by a tool. It seems that functional programming and ASM are a good combination to achieve this goal. AsmGofer is an extension of Gofer wich allows one to define functions and ASMrules with the full power of functional programming. The system also supports building graphical user interfaces, so one can combine the (ex cutable) ASMspecification with an animation showing information abo ut the ASM-state. The tool has also been used for making Boerger/Schulte’s ASM for the Java Virtual Machine executable. Software Requirements Specification of the Light Contr ol System Egon Börger, Elvinia Riccobene, Joachim Schmid Universita' di Pisa, Pisa – Italy We p...
This paperdiscusses theorganization ofsoftware thatis inherently complex because ofverymanyarbitr... more This paperdiscusses theorganization ofsoftware thatis inherently complex because ofverymanyarbitrary details thatmust beprecisely right forthesoftware tobecorrect. Weshowhowthesoft- waredesign technique knownasinformation hiding, orabstraction, can besupplemented byahierarchically structured document, whichwe call amoduleguide. Theguide isintended toallow bothdesigners and maintainers toidentify easily theparts ofthesoftware thattheymust understand, without reading irrelevant details aboutother parts ofthe software. Thepaperincludes anextract fromasoftware moduleguide toillustrate ourproposals. IndexTerms-Abstract interfaces, information hiding, modular struc- ture ofsoftware, software engineering. I.INTRODUCTION MsORE thanfive years ago,anumberofpeople atthe NavalResearch Laboratory becameconcerned about whatwepreceived tobeagrowing gapbetween software en- gineering principles being advocated atmajor conferences and thepractice ofsoftware engineering atmanyindustrial and government...
: This is the notebook from the updated edition of the well-received course originated by the Nav... more : This is the notebook from the updated edition of the well-received course originated by the Naval Research Laboratory and taught annually for the past six years. It is a two-week technical course for personnel managing a software project or designing software. The purpose of the course is to improve the participant's ability to evaluate software requirements, specifications, design, correctness, and maintainability. Its purpose is not to transform the participant into an expert software designer. The course concentrates on technical problems of software design. It introduces generally accepted design practices, as well as software design research that may result in practical design applications in the near future. Design for ease of maintenance is emphasized. All course material is unclassified. Topics covered include information-hiding modules (modules that isolate the effects of changes), abstract interfaces (a technique for designing the interfaces of information-hiding mod...
TYPES DEFINED AS CLASSES OF VARIABLES 44D. L. Parnas , John E. Shore l, David Weiss i
Software Fundamentals, May 17, 2001
Proceedings of the 3rd International Conference on Software Engineering, May 10, 1978
Software Fundamentals, May 17, 2001
ABSTRACT
Communications of the Acm, Apr 1, 1966
ABSTRACT
Lecture Notes in Computer Science, 1975
2009 Ninth International Conference on Quality Software, 2009
Summary form only given: On the road to a successful software product, there are key milestones t... more Summary form only given: On the road to a successful software product, there are key milestones that you should not skip. Each of them is a chance to see if you are on the right path and to correct your direction if you are not. Each milestone is a document that records key design decisions in a way that allows them to be reviewed and analyzed. The meaning of each document must be precisely defined and there must be no ambiguity. If the document is vague and subject to many interpretations, it can lead you down a path from which recovery is difficult. This talk proposes and illustrates a set of software documents that can serve as precise (and immovable) milestones. It discusses how they can be analyzed and used to guide the project on the rest of its trip to completion. To obtain the necessary precision, and to make analysis possible, the documents are mathematical expressions but written in a way that makes them easy to read.
This paper discusses modularization as a mechanism for improving the flexibility and comprehensib... more This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a “modularization ” is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decom-positions are discussed. The unconventional decomposi-tion, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
State Machines have been used to specify the case study "Light Control System". The ASM... more State Machines have been used to specify the case study "Light Control System". The ASM-approach allows one to specify system at different levels of abstraction. One can start with a high level description (u derstandable by the customer) and refine it (defining all used functions) to a deta iled version which is executable by a tool. It seems that functional programming and ASM are a good combination to achieve this goal. AsmGofer is an extension of Gofer wich allows one to define functions and ASMrules with the full power of functional programming. The system also supports building graphical user interfaces, so one can combine the (ex cutable) ASMspecification with an animation showing information abo ut the ASM-state. The tool has also been used for making Boerger/Schulte’s ASM for the Java Virtual Machine executable. Software Requirements Specification of the Light Contr ol System Egon Börger, Elvinia Riccobene, Joachim Schmid Universita' di Pisa, Pisa – Italy We p...
This paperdiscusses theorganization ofsoftware thatis inherently complex because ofverymanyarbitr... more This paperdiscusses theorganization ofsoftware thatis inherently complex because ofverymanyarbitrary details thatmust beprecisely right forthesoftware tobecorrect. Weshowhowthesoft- waredesign technique knownasinformation hiding, orabstraction, can besupplemented byahierarchically structured document, whichwe call amoduleguide. Theguide isintended toallow bothdesigners and maintainers toidentify easily theparts ofthesoftware thattheymust understand, without reading irrelevant details aboutother parts ofthe software. Thepaperincludes anextract fromasoftware moduleguide toillustrate ourproposals. IndexTerms-Abstract interfaces, information hiding, modular struc- ture ofsoftware, software engineering. I.INTRODUCTION MsORE thanfive years ago,anumberofpeople atthe NavalResearch Laboratory becameconcerned about whatwepreceived tobeagrowing gapbetween software en- gineering principles being advocated atmajor conferences and thepractice ofsoftware engineering atmanyindustrial and government...
: This is the notebook from the updated edition of the well-received course originated by the Nav... more : This is the notebook from the updated edition of the well-received course originated by the Naval Research Laboratory and taught annually for the past six years. It is a two-week technical course for personnel managing a software project or designing software. The purpose of the course is to improve the participant's ability to evaluate software requirements, specifications, design, correctness, and maintainability. Its purpose is not to transform the participant into an expert software designer. The course concentrates on technical problems of software design. It introduces generally accepted design practices, as well as software design research that may result in practical design applications in the near future. Design for ease of maintenance is emphasized. All course material is unclassified. Topics covered include information-hiding modules (modules that isolate the effects of changes), abstract interfaces (a technique for designing the interfaces of information-hiding mod...
TYPES DEFINED AS CLASSES OF VARIABLES 44D. L. Parnas , John E. Shore l, David Weiss i
Software Fundamentals, May 17, 2001
Proceedings of the 3rd International Conference on Software Engineering, May 10, 1978
Software Fundamentals, May 17, 2001
ABSTRACT
Communications of the Acm, Apr 1, 1966
ABSTRACT