|This article must adhere to the biographies of living persons policy, even if it is not a biography, because it contains material about living persons. Contentious material about living persons that is unsourced or poorly sourced must be removed immediately from the article and its talk page, especially if potentially libellous. If such material is repeatedly inserted, or if you have other concerns, please report the issue to this noticeboard. If you are connected to one of the subjects of this article and need help, please see this page.|
|WikiProject Biography / Science and Academia||(Rated Start-class)|
|WikiProject Ireland||(Rated Start-class, Low-importance)|
Would anyone be so kind as to explain what "technical realism" means in this instance?
Cohesion and Coupling
Parnas is often credited with introducing these concepts, but I've just gone back to the classic 1972 ACM and these concepts, while implicit, are not explicitly mentioned.--RichardVeryard 09:53, 28 September 2006 (UTC)
A review of the ACM Digital Library uncovers a single instance in all of Parnas's writing [Parnas, Schouwen, and Kwan. "Evaluation of safety-critical software," CACM, 33 (6), June 1990] where he used the terms coupling or cohesion--in that instance without attribution. If he is "often credited" where and by whom?Stirrer (talk) 18:18, 18 November 2007 (UTC)
The metrics of coupling and cohesion were originally proposed by Larry Constantine as correctly referred in Coupling_(computer_science). David Parnas did not contribute directly or indirectly to these metrics. The original reference is the seminal 1974 IBM Systems Journal paper Structured Design, which describes nearly 10 years of pioneering research by Larry Constantine. The ideas behind Coupling and Cohesion were initially published in "Segmentation and Design Strategies for Modular Programming." In Barnett and Constantine (eds.), Modular Programming: Proceedings of a National Symposium. Cambridge, MA: Information & Systems Press, 1968 and “The Programming Profession, Programming Theory, and Programming Education,” Computers and Automation 17, 2 (Feb. 1968) pp. 14-19. —Preceding unsigned comment added by 184.108.40.206 (talk) 08:40, 19 November 2007 (UTC)
Information Hiding not being mentioned by Parnas
Contrary to what is stated in the references section, Parnas mentions information hiding in his 1972 ACM article on page 1056 (bottom left) and he refers to himself: Parnas, D. L. Information distribution aspects of design methodology. Tech. Rept., Depart. Computer Science, Carnegie-Mellon U., Pittsburgh, Pa., 1971. Also Presented at the IFIP Congress 1971, Ljubljana, Yugoslavia. - However, I was not able to obtain a copy of that article, but nevertheless, information hiding is mentioned by Parnas in his 1972 ACM article. —Preceding unsigned comment added by 220.127.116.11 (talk) 13:36, 27 March 2009 (UTC)
Software Cost Reduction Project
I think this entry should say something about Parnas's participation in the U.S. Navy's Software Cost Reduction project. I actually came here to look for a reference to an example of the SCR's diagrams for specifying requirements. (See Heitmeyer (2007) "Formal Methods for Specifying, Validating, and Verifying Requirements".) 18.104.22.168 (talk) 14:52, 24 May 2011 (UTC) --RLV
Quotations out of context are not a good idea in any article.
David Parnas is an important researcher, one part of this wikipedia entry, refers to flow-charts against structured programming, because a confusion common in those days.
Structured programming was wrongly taken by many people as programming without GOTOs, because an anecdote about the change of title of the GOTO considered harmful written by E.W.Dijstra, but renamed by N.Wirth (the author of Pascal,Modula, Step wise refinement, programs=data structures + algorithms, etc.)
Structured programming is basically programming by composing (reusable) parts on the basis of a mathematical structure. Data types are mathematical structures, programming structures too. Like deriving theorems from axioms.
Data-flow diagrams do not encourage an structured thinking, the introduction of "structured languages", (i.e. languages with assignment, if-then-else, while, for-next, repeat-until, and subroutines, making much more less use of GOTOs). Did not automatically solved the problem, take into account that the predominant languages of those days used floats, integers, characters, strings, arrays and records in some languages like COBOL. (this before Pascal, Algol existed but was not very known to business applications programmers)
Artificial intelligence on those days was very experimental and the quotation based on cite 4 where Parnas said that Turing Machines and Gödel theorems where irrelevant, could be because many people on those days argued that IA research where looking for impossible goals due to the incompleteness theorem. I could not download the document, the date of the original publication is also omitted.
Turing Machines originated by an engineering thought on how an human computer worked at those days, using the minimal elements. The Universal Turing Machine was the basis for the stored program computer. John Von Neumann new Turing. The famous Gödel theorems are related to arithmetic, and Recursive Functions (a class of functions, mathematical systems, not the simple use of the word to denote a program that calls it self) Seen in that way, I do not believe that Parnas ignored that. But the quotation based on citation 4 seems to be out of context, mixing a his opinion on the AI research with Software Engineering.
For that reason, I think that the quotations are out of context, and should be removed.