(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