1 / 16

Contributions of Dr. David Parnas to the Development of Software Engineering

Contributions of Dr. David Parnas to the Development of Software Engineering. Background History of Computer Technology Career of David Parnas Areas of Contribution The Software Process Software Specifications Parnas Tables Modular Programming Concurrency Ethical Responsibility.

jesse
Download Presentation

Contributions of Dr. David Parnas to the Development of Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Contributions of Dr. David Parnas to the Development of Software Engineering Background History of Computer Technology Career of David Parnas Areas of Contribution The Software Process Software Specifications Parnas Tables Modular Programming Concurrency Ethical Responsibility

  2. 1642 – Pascal assembles first analog computer 1943 – Turring builds first electronic digital computer 1953 – IBM manufactures first 701 Data Processing machine 1976 – Wozniak and Jobs invent first Apple personal computer 1983 – C++, First Object-Oriented Language 1941 – David Parnas born in Plattsburg, NY 1957 – Enters Carnegie Institute of Technology 1960 – Begins teaching electrical engineering and computer science 1965 – Earns Ph.D. in Electrical Engineering 1965 – Present: 40+ years classroom instruction Authors 200+ publications Consultant to many large corporations. Background History of Computers Dr. Parnas’ Career

  3. The Software Process Dr. Parnas Contributions 1. Specification: Define functions and constraints 2. Development: Design and programming 3. Validation: Confirm alignment with customer requirements 4. Evolution: Adaptation to changing requirements • Applied engineering discipline. • Helped to establish 4 main activities in “software process.” • Developed tools to use in each activity.

  4. Software Specifications Dr. Parnas Specification Requirements • The user must be provided with all the information needed to run the software and nothing more. • The implementer must be supplied with all information about the intended use(s) of the software. • Formally documented and complete, especially with regard to the intended user. • Written in terms that are understandable to both user and implementer. • Continually updated and shared.

  5. Types of Specifications Precondition/Postcondition Program Code Input Output • Evolved during mainframe era for batch, top-down programming. • All details of input and output data must be specified. • Program code is primary focus.

  6. Types of Specifications Data Abstract Module 1 Code Module 2 Code Module 3 Code Input Output • Evolved with modular programming. • Only abstract information about data and variables is specified. • All variables passed between modules must be specified. • Only functional relationships between inputs & outputs are required.

  7. Parnas Tables Specifying Functional Relationships Parnas Tables can relate input variables to corresponding functions Input Variables H2 ^ H1 Response Functions H1 G G H2

  8. Parnas Tables Specifying Functional Relationships Example: Relating IQ to males & females of different age groups Input Variables H2 ^ H1 Response Functions H1 (Age Group) G A<5 55<A Male 2A2 G (IQ) (Sex) H2 140-0.1A Female Male IQ grows at a rate of 2A2 through age 5 years. Female IQ declines at a rate of 140-0.1A after age 55 years.

  9. Parnas Tables Specifying Functional Relationships Similarly, Parnas Tables can relate a set of functions to output variables Response Function G Output Variables H1 H2 v H1 G H2

  10. Modular Programming Dr. Parnas Contributions • Strong proponent of modular programming concept • Procedures, Subroutines, Functions in top-down programming languages • Classes & Objects in object-oriented languages. • Parnas Tables & other tools help to exploit advantages • Information Hiding • Development Time • Flexibility

  11. Instruction 1 Instruction 2 Instruction 3 Module 1 Instruction 4 Instruction 5 Instruction 6 Module 2 Modular Programming Advantage #1: Information Hiding Module 1 Code Module 1 Code Module 2 Code Module 2 Code Module 3 Code Input Output Each module satisfies a specific design decision Each module hides its implementation from all other modules

  12. Modular Programming Advantage #2: Reduced Development Time Module 1 Code Module 2 Code Module 3 Code Input Output Sequential Development Example Module 1 Module 2 Module 3 = 1 Programmer, 3 weeks 1 Week + 1 Week + 1 Week It takes 3 weeks to develop entire program. Specifications not critical, since only one programmer involved.

  13. Modular Programming Advantage #2: Reduced Development Time Module 1 Code Module 2 Code Module 3 Code Input Output Simultaneous Development Example Programming Time Module 1 Programmer #1, 1 Week = 3 Programmers, 1 week Module 2 Programmer #2, 1 Week Module 3 Programmer #3, 1 Week Different programmers can work on modules independently. It takes only one week to develop entire program. Specifications are essential to ensure compatibility between modules.

  14. Module 5 Code Modular Programming Advantage #3: Product Flexibility Module 1 Code Module 2 Code Module 3 Code Input Output2 Output3 Output Module 4 Code • New or improved programs can be created quickly • By replacing modules. • Or adding new modules.

  15. Module 5 Code Concurrency An On-Going Challenge for Dr. Parnas Module 1 Code Module 2 Code Module 4 Code Input Output3 • Two or more modules operating simultaneously on the same dataset. • No universal programming solution exists • Two techniques are currently used to simulate concurrency: • Periodic synchronization between modules • Scheduling execution of module elements. • Dr. Parnas & colleagues continue to wrestle with this challenge.

  16. Ethical Responsibility Dr. Parnas Challenge to All Software Engineers • Never rely on external authority for personal decisions. You are responsible for your own actions. • Always consider ethical and moral issues to determine if a given solution will be a benefit to society. • Be certain that you are solving the problem and not just providing a short-term solution to satisfy your supervisor.

More Related