(8.1)Software Development
Why is software important Algorithms Programming language
– levels–data structures– control structures– sample program– compilation process
Software development– software lifecycle models– software maintenance–object-oriented programming– software reliability–practical matters
(8.2)Why is Software Important
Hardware is increasing in capability rapidly– transistor density quadruples every 3 years
»price/performance doubles every three years (Moore’s Law)
–main memory density quadruples every 3 years
–magnetic disk density quadruples every 3 years
Programs that use hardware still– take too long to create– contain too many errors–are difficult to understand and use
“Software crisis” Tremendous opportunities for improved
software technologies
(8.3)Algorithms
Algorithms are recipes– descriptions of what steps are
supposed to be accomplished to solve a particular problem
May be described in many ways– flowcharts– pseudocode (mixture of
natural language and programming language)» read value to search for» point at first array element» while array element isn’t value
being sought and still array elements not examined•point at next array element
» if not found, report failure, else report success
Software development involves creating algorithms and implementing them in a programming language
start
read search value
index to 1st element
report success
done
all array elements examined ?
index to next elt
report failure
element = search value ?
Y Y
N
N
(8.4)Programming Language Levels
Machine language–all binary
Assembly language–1 - 1 correspondence with machine language instructions
–mnemonic op codes and variable names»ADD R3, INCR
–allows precise control of all aspects of computer
op code
addr 1 addr 2
110100011000000100111010
(8.5)Programming Language Levels (continued)
High level language–1 HLL statement generates many (10) machine language statements
–depending on language, much easier for humans to understand»Total := Total + CheckAmount[I];
–more dependent on translator for efficient code»optimized, but programmer has less
control over precise operations
– Java, C, C++, Pascal, FORTRAN, COBOL, Ada, Lisp
(8.6)Programming Language Levels (continued)
Very high level language–each statement generates very many (100) machine language statements
–people using these languages often don’t know they’re programming
– Lotus 1-2-3, Word macros, NextStep, SQL
Every programming language provides–data structures– control structures
And requires a translator–except for machine language
(8.7)Data Structures
Data structures hold the information being used by the program– classified according to the type of information they contain
–also how they are organized or may change
Primitive data structures– typically those types provided by hardware– integer–floating point– character
»encode each character as 7 or 8 bit binary numbers
»ASCII–Boolean
»true or false (0 or 1)
exp fraction
0 7 8 31
(8.8)Data Structures (continued)
Elements that hold data in a program have to be defined (or declared) before they can be used– these elements are referred to as variables
–definitions associate a name for the data item with the type of data being held there
– translator associates name with a memory location»amount of memory depends on type of
information stored therevar age: integer;
height, weight: real;
codger: boolean;
(8.9)Data Structures (continued)
Once declared, values can be assigned to these variables using an assignment statement or operator
The value assigned to a variable can also be an expression
age := 87;
height := 181;
weight := 87.3;
codger := true;
age := currentdate - date_of_birth;
weight := lbs/2.2;
(8.10)Data Structures (continued)
Aggregate data structures–array
»regular structure of elements, all of the same type
»access by specifying array name and subscript value
»primes: array [0..7] of integer;
»primes[3] := 5;
5
(8.11)Data Structures (continued)
Aggregates (continued)– record
»irregular structure of components, which may be of different types
»access by specifying record name and name of component
»city: record» name: array [0..7] of character;
» longitude, latitude: real;
» altitude, population: integer
»end»city.population := 800023
S a n J o s e
800023
(8.12)Data Structures (continued)
Primitive and aggregate data structures are fixed in size once they’re declared
Dynamic data structures can grow and shrink during execution– lists
»consist of nodes»each node contains some information and a pointer to the next node on the list
–binary trees»also consist of nodes
»each node contains information and pointers to left and right children
(8.13)Data Structures (continued)
Dynamic (continued)– stacks
»store information in a Last In, First Out order
»all entries and deletes from same end
–queues»store information in a First In, First Out order
»entries and deletes from opposite ends
(8.14)Control Structures
Control structures determine the order in which instructions are executed by the program–default is sequential–also need
»selection (choose among two or more alternatives)
»repetition (repeat some set of statements a fixed number of times or until some condition is satisfied
if-then-else– choose between two alternative instruction sequences
– if (Speed < 65)– then Fine := 100– else Fine := 1000 – can be nested
(8.15)Control Structures (continued)
Counting loop–uses index variable to count a particular number of iterations»start value, stop value, sometimes
increment–Sum := 0;– for I := 1 to 50 do– Sum := Sum + I;
(8.16)Control Structures (continued)
Logical loop– tests whether a particular condition is true or false; if true, repeat; otherwise, skip statement
– readln (Threshold);–Total := 0;–while Total < Threshold do– begin– readln (Value);– Total := Total + Value– end
(8.17)Control Structures (continued)
Another important control mechanism is subroutine invocation– define a subroutine
» collection of PL statements with a name that should be treated as a group
– cause execution of the subroutine to begin by coding its name in a statement» calling program
suspends execution» subroutine executes
to completion and returns
» calling program continues execution where it left off
(8.18)Control Structures (continued)
Parameters allow data values to be transmitted between the main program and the subprogram
Allows different parts of the same program to reuse code–keeps program size smaller– simplifies maintenance
(8.19)Sample Pascal Program
program LinSearch (Input, Output); type EltArray = array [1..20] of integer; var Values: EltArray; SearchFor: integer; Found: Boolean; J: integer; procedure Search(X: EltArray; Thing: integer; var FoundIt: Boolean); var I: integer; begin I := 1; FoundIt := false; while (not FoundIt) and (I <= 20) do if X[I] = Thing then FoundIt := true else I := I + 1 end; {Search} begin writeln('Enter array values one at a time, followed by return'); for J := 1 to 20 do readln(Values[J]); writeln('Enter a value to search for, followed by return'); readln(SearchFor); Search(Values, SearchFor, Found); if Found then writeln('Search value was in the array') else writeln('Search value was not in the array') end.
(8.20)Fundamental Concepts for Describing PLs
Syntax–what is a grammatically correct construct
Semantics–what is the meaning of a PL statement
We separate these for discussion purposes, but they are closely related– the semantics should follow from the syntax
–both are often intertwined in translators
(8.21)Compilation Process
Source Program
Lexical Analysis
Syntax Analysis
Intermediate Code Gen
Code Generation
Object Program
Optimization
lexical units
parse trees
int. text
machine code
Syntax
Semantics
(8.22)Kinds of Translators
Compilers– translate source code into machine code one time and the machine code executes
Interpreters– translate each source code statement every time it executes
Hybrid systems– translate the source code into a simpler form once, then interpret the translated form
Compilers provide code that executes rapidly, interpreters provide flexibility
(8.23)Software Development
Software has been extremely difficult to produce–on time–within budget–without errors
Partly caused by– complexity
»many interactions–no “standard” parts– changes in customer requirements– lack of management understanding of SW development process
Fight with–disciplined design methodologies– software reuse– configuration management systems
(8.24)Software Lifecycle Models
“Classic” model is waterfall model
(8.25)Software Lifecycle Models (continued)
Requirements analysis and definition– consult with users to establish desired services, constraints and goals
–define so understandable by users and development staff
– composed of» functional requirements = what system
is to do»non-functional requirements =
constraints and standards•eg, character set and response time requirements
–many formal and semiformal specification techniques being used
(8.26)Software Lifecycle Models (continued)
System and software design– system design includes hardware component– software design typically a process of iteratively refining design as problem and solution are better understood»divide and conquer approach until
components are small enough to be implemented
–usually combination of top-down and bottom-up approaches
– several proprietary design methodologies in use»usually involve symbolism and means of
specifying relationships of software components
(8.27)Software Lifecycle Models (continued)
Implementation and unit testing– typically by individuals or small teams
»to minimize coordination overhead
–heavy use of tools (CASE)»profilers»test data generators and drivers» Interactive debuggers
–exhaustive testing impossible
(8.28)Software Lifecycle Models (continued)
Interactive design/debugging environment example
(8.29)Software Lifecycle Models (continued)
System testing– combine individual units, drive test suites
–heavy use of version control systems to create stable “builds”»save changes to allow reconstructing any
version»combine only appropriate version of each
unit for final system release Cost breakdown
– requirements and design - 35% to 45%– implementation - 20% to 30%– testing - 30% to 50%– the later in phases the more it costs to make corrections of errors» factor of 1000 between requirements
phase and system testing phase
(8.30)Software Lifecycle Models (continued)
Most software development methodologies are built around some form of waterfall model. Problems include–difficulty in developing requirements
» if requirements are wrong, wrong system gets developed
– requirements change»either customers don’t get the system they
now want, or system is delayed– customers are often left out of the testing phase»and no evaluation is done other than
meeting specification Two approaches involving iterative design
and implementation are becoming popular
(8.31)Software Lifecycle Models (continued)
Rapid prototyping builds a “mock up” of the proposed system and lets customers evaluate it– use very high level languages– relax performance and error correction/detection
requirements– use prototype to specify final system– developing prototype may be large portion of cost
(8.32)Software Lifecycle Models (continued)
Evolutionary development builds system incrementally– implement some functions needed by customer– let customer use system– modify and expand iteratively– helps solve “80 -20 rule” problem
(8.33)Software Maintenance
“Maintenance” includes any modifications made after the system is released– correcting bugs (17%)
»and often introducing new bugs!»extensive use of regression testing to
try to avoid–adapting system to changes in environment (18%)»new hardware, regulatory requirements,
etc.»additional major functionality
– improving system without adding major new functions (65%)
(8.34)Software Maintenance
Lifetime maintenance costs are often 60% - 75% of overall system costs–maintenance costs 2 to 4 times what original development did
– large SW organizations spend 50% of effort maintaining old systems»system structure deteriorates as it’s
maintained»staff instability means maintenance not
done by people who wrote original»program lifetimes increasing
(8.35)Object-Oriented Programming
A major problem with software development is developing everything from scratch
Object-oriented programming (OOP) encourages reuse
A class is a template for an object
(8.36)Object-Oriented Programming (continued)
An object is a software component that– is an instantiation of a class– is self-contained–has local variables and data structures
» instance variables–has local procedures that operate on instance variables»methods
–methods and instance variables are encapsulated in the object»can’t be separated, can’t be accessed
from outside except– responds to messages from other objects to perform work and return results»messages have parameters
(8.37)Object-Oriented Programming (continued)
Objects and classes form a hierarchy–each object is an instantiation of a class or object above it in the hierarchy»OO languages come with libraries of
base or foundation classes–new objects can easily modify parent objects»they inherit all characteristics of parent»methods can be redefined by new
methods with same name»additional functions can be added by
adding new methods and instance variables
(8.38)Object-Oriented Programming (continued)
OO languages also demonstrate polymorphism–which object a message gets sent to is dynamically determined at runtime
OOP seems to allow faster development, easier maintenance–not a “silver bullet”
(8.39)Software Reliability
Software is inherently unreliable Normal approach to “proving”
reliability is testing–exhaustive testing is impossible
»there are 4.3 billion possible combinations of 2 16-bit integers
»1.2 hours of testing on a 1 MIP machine»78 hours of testing for 3 16-bit inputs
–even testing all paths through a large program is impossible
“Common” bugs are found early in testing or operational life–fixing rare bugs may actually make program less reliable»since may induce new bugs
(8.40)Software Reliability (continued)
Can enhance reliability by fault-tolerant techniques– separately code different versions of software, “vote” on the results»but specification may have been wrong
Other approaches involve–mandating standards for development process
– reduce criticality of software to operation of risky activities
–accept less reliability
(8.41)Practical Matters
Legacy systems are old systems still being used for operations–many are maintenance problems
»eg, two digit year fields– very large, difficult to rewrite, often hardware or OS specific
– stuck with particular processing environment
Downsizing–moving applications off expensive, proprietary central machines to networks of inexpensive, open systems (UNIX)
–many necessary tools are not there yet– loss of control for backups, etc.
Reverse engineering–black box or clean room approaches
Top Related