on the development of program families n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
On the Development of Program Families PowerPoint Presentation
Download Presentation
On the Development of Program Families

Loading in 2 Seconds...

play fullscreen
1 / 26

On the Development of Program Families - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

On the Development of Program Families. D. L. Parnas. Presentation by Sagnik Bhattacharya Siddharth Dalal. Overview. Families – sets of programs having extensive common properties, better to study than individual programs

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'On the Development of Program Families' - afra


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
on the development of program families

On the Development of Program Families

D. L. Parnas

Presentation by

Sagnik Bhattacharya

Siddharth Dalal

overview
Overview
  • Families – sets of programs having extensive common properties, better to study than individual programs
  • Methods – sequential development, stepwise refinement, module specification
  • Comparison of new methods and their complementary advantages

-A bug in the code is worth two in the documentation.

introduction
Introduction
  • Example Program Families
    • OS Versions
  • Similar to hardware families
  • Traditional Methods – Single Program
  • Comparison of programming techniques in suitability to develop families

-Adding manpower to a late software project makes it later.

why families
Why Families
  • Versions for different applications, different hardware
  • Improvement
  • Difficult non-trivial problem so need methods/tools geared towards design of families

-Alpha. Software undergoes alpha testing as a first step in getting user feedback. Alpha is Latin for "doesn't work."

classical method

1

2

3

4

9

7

5

6

8

Classical Method
  • Sequential Completion – Think like a computer
  • Family members are derived from complete programs
  • Descendants may share undesirable characteristics of ancestors

-Any program that runs right is obsolete.

example sorting
Example: Sorting
  • First, we decide to use Bubble sort :
      • Read the list.
      • while not at end of list
      • compare adjacent elements
      • if second is greater than first
      • switch them
      • get next two elements
      • if at least one switch takes place
      • repeat for entire list
      • Output the sorted list.
example sorting1
Example: Sorting
  • If we decide to use Insertion sort :
      • Read the list.
      • while not at end of list
      • compare adjacent elements
      • if second is greater than first
      • switch them
      • get next two elements
      • if at least one switch takes place
      • repeat for entire list
      • Output the sorted list.
example sorting2
Example: Sorting
  • If we decide to use Insertion sort :
      • Read the list.
      • i = 0;
      • while not at end of list
      • find ith smallest element and put in ith position
      • repeat for entire list
      • Output the sorted list.
new techniques
New Techniques
  • Older version may not be ancestor of newer ones
  • Common design decisions taken early
  • Subfamilies can be developed in parallel

-Bug? That's not a bug, that's a feature.

classical vs new 76 new
Classical vs. New (’76 new)

-Computers can never replace human stupidity.

stepwise refinement sr
Stepwise Refinement (SR)
  • Intermediate stages are programs which are complete except for the definition of certain operators and operand types
  • Design decision = refinement step
  • Possible solutions = leaves = families

-Beta. Software undergoes beta testing shortly before it's released. Beta is Latin for "still doesn't work."

example sorting3
Example: Sorting
  • Step 1:
    • Read unsorted list
    • Sort the list
    • Output sorted list.
  • Step 2:

2a. Scan through list

2b. Perform sorting ops.

  • Step 2:

2a. Divide into 2 sublists.

2b. Sort sublists.

2c. Merge sublists

Bubble sort

Merge sort

Insertion sort

module specification ms
Module Specification (MS)
  • Intermediate stages are specifications of externally visible collective behavior of program groups called modules
  • Decisions which cannot be common properties are identified and a module is designed to hide the decision

-My software never has bugs. It just develops random features.

example sorting4
Example: Sorting
  • Modules :
    • List storage
    • Input
    • Sorting module
    • Output
    • Master Control
how mss define a family
How MSs Define a Family
  • Implementation methods used within modules
    • Create family members by further sub-modules or stepwise refinement
  • Variation in external parameters
    • Family of specifications for different parameters
  • Use of subsets
    • Programs consisting of a subset of programs described by the set of module specs
    • e.g. OS versions like Win2k pro/server/advanced server

-Computer and car salesmen differ in that the latter know when they are lying.

example chess
Example: Chess
  • By Stepwise Refinement
    • Input: Current State of board
    • Select Next Move
    • Change State of Board

-Computer analyst to programmer: "You start coding. I'll go find out what they want."

example chess1
Example: Chess
  • By Stepwise Refinement
    • Input: Current State of board
      • Look ahead n positions (20 billion positions in 3 mins if you’re the 1997 Deep Blue)
      • Select best position
    • Change State of Board

-Computer analyst to programmer: "You start coding. I'll go find out what they want."

example chess2
Example: Chess
  • By Module Specification
    • List Design Decisions
      • Internal representation of board
      • Chess playing module
      • Master Control module
    • Hide Design Decisions
      • Chess playing algorithm

etc.

-Computers are unreliable, but humans are even more unreliable.

comparison
Comparison
  • MS – broader family because design decisions are hidden and can be changed
  • SR – Bound by decisions and so narrower family
  • MS – greater effort – perfect module interface specs required – grants the flexibility to change design decisions later

-Build a system that even a fool can use, and only a fool will use it.

issues for discussion
Issues for discussion
  • Cost
  • Reusability
  • Effort
  • Size of software
  • Testing
families vs system generators
Families vs. System Generators
  • MS and SR are not intended to replace system generators.
  • These methods can simplify a generator’s work.
  • However, a simulator program would not be efficient.

-Failure is not an option, it comes bundled with the software.

which to use
Which to Use?
  • Two methods not equivalent or contradictory, but complementary
  • SR – make sequencing decisions early
  • MS – sequencing decisions????
  • Effort – MS>SR – large/small family
  • Hybrid method?

-Hardware: The parts of a computer system that can be kicked.

conclusion
Conclusion
  • One cannot conclude that modularization is better than stepwise refinement.
  • Lack of evaluation methods.
  • Modular specification implies more cost, but permits production of a broader program family.

-It's not a bug; it's an undocumented feature

tools
Tools
  • SEI Product Line Initiative – http://www.sei.cmu.edu/plp/
  • FAST - http://www.hep.net/chep95/html/slides/it14/it14.pdf
  • RAD Tools
  • Version Control?
  • LEX, YACC????
links
Links
  • N. Wirth, Program Development by Stepwise Refinement – http://www.acm.org/classics/dec95/

-Beware of Programmers who carry screwdrivers.

slide26
“... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly.Thank goodness the two requirements go hand in hand.”
          • Djikstra

-Don't document the program; program the document.