Software Development

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

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

Algorithms start • 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 read search value index to 1st element index to next elt N all array elements examined ? element = search value ? N Y Y report success report failure done

Programming Language Levels 110100011000000100111010 • 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

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

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

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) 0 7 8 31 exp fraction

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 there var age: integer; height, weight: real; codger: boolean;

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;

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

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

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

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

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

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;

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

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

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

Sample Pascal Program

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

Compilation Process Source Program Lexical Analysis lexical units Syntax Analysis Syntax parse trees Optimization Intermediate Code Gen Semantics int. text Code Generation machine code Object Program

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

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

Software Lifecycle Models • “Classic” model is waterfall model

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

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

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

Software Lifecycle Models (continued) • Interactive design/debugging environment example

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

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

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

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

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%)

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

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

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

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

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”

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

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

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

Software Development