Outline: Software Design. Goals History of software design ideas Design priniples Design methods Life belt or leg iron? (Budgen) Copyright Nany Leveson, Sept. 1999
A Little History... At first, struggling with programming languages, small programs, math algorithms. Worried about giving instrutions to mahine (effiieny) "Think like a omputer" Found that life yle osts depend far more on how well ommuniates with people than how fast it runs. Separated the two and more emphasis began on How to write software to ommuniate algorithms and struture to humans How to struture design proess itself. Copyright Nany Leveson, Sept. 1999
Strutured Programming Goal: mastering omplexity Dijkstra, Hoare, Wirth: Constrution of orret programs requires that programs be intelletually manageable Key to intelletual manageability is the struture of the program itself. Disiplined use of a few program building bloks failitates orretness arguments. Copyright Nany Leveson, Sept. 1999
Strutured Programming (2) Restrited ontrol strutures Levels of abstration Stepwise refinement Program families Abstrat data types System struture: Programming-in-the-large vs. programming-in-the-small Modularization Minimizing onnetivity Copyright Nany Leveson, Sept. 1999
Restriting Control Strutures Dijkstra: 3 main mental tools Enumerative reasoning Mathematial indution Abstration (e.g., variable, proedure, data type) 1. Restrit programs to onstruts that allow us to use these mental aids. Sequening and alternation (enumeration) Iteration and reursion (indution) Proedures, maros, and programmer-defined data types SESX Small proedures 2. Make program struture fit problem struture. Copyright Nany Leveson, Sept. 1999
Levels of Abstration 1968: Dijkstra paper on his experienes with T.H.E. Multiprograming system Designed using "levels of abstration" System design desribed in layers Higher levels ould use servies of lower levels Lower levels ould not aess higher levels Lowest level implemented first Provided a "virtual mahine" for implementation of next level Proess ontinued until highest level ompleted. A "bottom up" tehnique Copyright Nany Leveson, Sept. 1999
Stepwise Refinement Wirth (1971): "Divide and onquer" A top-down tehnique for deomposing a system from preliminary design speifiation of funtionality into more elementary levels. Program onstrution onsists of sequene of refinement steps. Use a notation natural to problem as long as possible. Refine funtion and data in parallel. Eah refinement step implies design deisions. Should be made expliit. Copyright Nany Leveson, Sept. 1999
Prime Number Program Copyright Nany Leveson, Sept. 1999 begin var table p; fill table p with first 1000 prime numbers print table p end Assumes type "table" and two operators Design deisions made: All primes developed before any printed Always want first 1000 primes Deisions not made: Representation of table Method of alulating primes Print format
Program Families Copyright Nany Leveson, Sept. 1999 Basi premise: Software will inevitably exist in many versions Different servies for slightly different markets Different hardware or software platforms Different resoure tradeoffs (speed vs. spae) Different external events and devies Bug fixes Think of development as a tree rather than a line Never modify a ompleted program Always begin with one of intermediate forms Continue from that point making design deisions Order of deisions important in how far have to bak up. Make early deisions only those that an be shared by all family members Put off deisions as long as possible.
Abstrat Data Types Copyright Nany Leveson, Sept. 1999 Defines a lass of objets ompletely haraterized by operations available on those objets. Really just programmer-defined data type Built-in types work same way Allows extending the type system Pasal, Clu, Alphard, Ada Want language to protet from foolish uses of types (strong typing or automati type onversion) Criteria: 1. Data type definition must inlude definitions of all operations appliable to objets of the type. 2. User of ADT need not know how objets of type are represented in storage 3. User of ADT may manipulate objets only through defined operations and not by diret manipulation of storage representation.
System Struture Copyright Nany Leveson, Sept. 1999 DeRemer and Kron (1976): Struturing a large set of modules to form a system is an essentially distint and different intelletual ativity from that of onstruting the individual modules (programming in the large, MILs) Ativity of produing detailed designs and implementations is programming in the small. Modularization Want to minimize, order, and make expliit the onnetions between modules. Combining modularity with hierarhial abstration turned out to be a very powerful ombination (part-whole and refinement abstrations)
Module Speifiation Copyright Nany Leveson, Sept. 1999 Started to distinguish between design and "pakaging" Design is proess of partitioning a problem and its solution into signifiant piees. Pakaging is proess of lustering piees of a problem solution into omputer load modules that run within system time and spae onstraints without unduly ompromising integrity of original design. Optimization should only be onsidered in pakaging and are should be taken to preserve design struture. Reuse Assumed hundreds of reusable building-blok modules ould be abstrated and added to program libraries. Why didn t happen?
Copyright Nany Leveson, Sept. 1999 Stepwise Refinement vs. Module Speifiation SR: Intermediate steps are programs that are omplete exept for implementation of ertain operators and operands. MS: Intermediate stages are not programs. Instead they are speifiations of externally visible olletive behavior of program groups alled modules. Similarities Preise representation of intermediate stages in program design. Postponement of deisions: Important deisions postponed until late stages or onfined to well-delineated subset of ode.
Copyright Nany Leveson, Sept. 1999 Stepwise Refinement vs. Module Speifiation (2) Differenes Deision Making SR: Deision-making order ritial. May have to baktrak more than really want. Sequening deisions made early beause intermediate reps are programs. MS: May be easier to reverse deisions without repeating so muh work. Sequening deisions made last. Effort SR: Less work than either lassial approah (beause keeps omplexity in ontrol) or MS. MS: Signifiant amount of extra effort beause only works if external harateristis of eah module suffiiently well speified that ode an be written without looking at implementation of other modules. In return, get independent development potential.
Minimizing Connetivity Copyright Nany Leveson, Sept. 1999 Yourdan; Constantine and Myers Cohesion: relationship between funtions a module provides Coupling: relationship between modules, intermodule onnetions Intermodule Frition Smaller modules tend to be interfaed by "larger surfaes" Replaement of module with large interfae auses frition, requiring rewrites in other modules. Uses relationship Primary goal: loality of visibility
Minimizing Connetivity (2) Copyright Nany Leveson, Sept. 1999 Advantages of reduing onnetivity (oupling) Independent development (deisions made loally, do not interfere with orretness of other modules). Corretness proofs easier to derive Potential reusability inreased. Redution in maintenane osts (less likely hanges will propagate to other modules) Comprehensibility (an understand module independent of environment in whih used). Some studies show less error-prone.