Introduction To Computer Where do they all go? Programming P - PDF document

Language Levels Introduction To Computer Where do they all go? Programming P High-level Java, C# < Close to problem FORTRAN, COBOL, C++ < System independent Chapter 1 C/C++ P Low-level < Close to system Assembler < Doesn’t reflect problem Machine CS 2250, Chap 1 Slide 1 of 20 CS 2250, Chap 1 Slide 2 of 20 Relationship Between C and C++ Interpreter Operation C++ is (almost) a perfect subset of C Dynamic translation prototypes classes P CPU executes the interpreter const encapsulation inline < Program is data to interpreter inheritance references runtime < Parses each statement in the polymorphism C++ new / delete RTTI program (each every time it is templates executed) Text file Interpreter ctors/dtors < Carries out the program statements overloading P Advantages main object-oriented < Smaller generated code functions ANSI < More portable (machine independent) syntax model operators < Better diagnostics (debugging) C flow of control < Can implement “very high-level” languages organization P 10 to 100 times slower than a compiled program!! compilation libraries < Hybrid systems are 3 to 10 slower CS 2250, Chap 1 Slide 3 of 20 CS 2250, Chap 1 Slide 4 of 20 Compiling Programs The Origins of C Multi-file programs (compare with Fig. 1.10, p. 15) A brief history source compiler or object code assembler files P C was created by Dennis Ritchie in the early 1970s to write a libraries portable version of Unix P C and Unix came together in 1973 on a DEC PDP-11/20 running the 5th edition of Unix P The line between C and Unix is not distinct (although they editor linker are governed by two standards: ANSI and POSIX) executable P ANSI standard < Committee was established in 1983 < Standard adopted 1989 and became available in 1990 runtime < Is the base document for the ANSI C++ standard < Many features of C++ were back-ported to C either because they .c .obj were good features or to avoid gratuitous differences .asm .o CS 2250, Chap 1 Slide 5 of 20 CS 2250, Chap 1 Slide 6 of 20

C Is A Minimal Language Algorithms I Lean and mean A recipe for Fishin’ Cookies P Cream together sugar & shortening P 32 keywords (27 from K&R and 5 added by ANSI) P Ingredients < ½ C shortening P Add eggs P Does not provide OS/kernel services < 1 C Sugar < Networking P Add vanilla & milk and mix < 2 well-beaten eggs < Multiprocessing/Multithreading < 1 tsp vanilla P Sift together flour, baking powder, < Interprocess communication or synchronization < 1/4 C milk & salt; add to liquid and mix P Provides basic programming features < 3 C flour P Roll dough and cut < Variables, expressions, statements, control structures, and < 2 tsp baking powder functions P Bake at 400 N F for 8-10 minutes < 1/4 tsp salt < Minimal compile-time and little run-time error checking < Typed but not strongly so– strict type compatibility is not enforced P Advanced programming features, including I/O, are provided by libraries (also governed by the ANSI standard) CS 2250, Chap 1 Slide 7 of 20 CS 2250, Chap 1 Slide 8 of 20 Algorithms II Flowcharts Newton-Raphson: roots of f(x) = 0 The basic elements P INPUT initial approximation p 0 : tolerance TOL; maximum Terminator Loop Preparation number of iterations N 0 P OUTPUT approximate solution p or message of failure I/O P Step 1 Set i = 1 Predefined process P Step 2 While i < N 0 do steps 3 - 6 P Step 3 Set p = p 0 - f(p 0 ) / f’(p 0 ) Process On-page P Step 4 if | p - p 0 | < TOL then OUTPUT(p) and STOP connector P Step 5 set i = i + 1 Off-page connector P Step 6 set p 0 = p Decision P Step 7 OUTPUT “Method failed after N 0 iterations; STOP Control flow CS 2250, Chap 1 Slide 9 of 20 CS 2250, Chap 1 Slide 10 of 20 Functional Model Algorithms III Newton-Raphson: roots of f(x) = 0 The oldest model INPUT P 0 Start i = 0 TOL P Focuses on how (i.e., the algorithms) to solve N0 a problem P Decomposes problem into functions and OUTPUT function interfaces i < N 0 no Failed P Changes have wide spread effects – global updateInventory( ) yes data makes the program fragile { p 0 = p p = p 0 - f(p 0 ) / f’(p 0 ) Stop P Functions have varying degrees of coupling } through global data < Developed as a unit printReport ( ) OUTPUT < Debug as a unit { i = I +1 no | p - p 0 | < TOL yes p < Validate as a unit } CS 2250, Chap 1 Slide 11 of 20 CS 2250, Chap 1 Slide 12 of 20

Data Driven Models Object Model ‘70s through mid ‘80s State of the art P Data flow Name P Characteristics of functional & data models < Maps data input to data output data P A tool for managing complexity < Design data structures first Data < Design processes / functions last Attributes P Change resilient P Data hiding < Change is localized process < Intra-object functions may be coupled < Packages data and the functions that work on Functions < Extra-object functions are decoupled the data together in a module (a file in C) Behaviors < Data is still in global scope but access is Operations P Natural organization for data and functions data allowed only through the module functions < Objects encapsulate data and functions together Class Notation P Abstract Data Type (ADT) < Supports ADTs: multiple objects of a type may be created (class is < Programmer created data type a type specifier or ADT) < struct in C < Supports data hiding: data access is controlled through key words CS 2250, Chap 1 Slide 13 of 20 CS 2250, Chap 1 Slide 14 of 20 Software Life Cycle Phases Waterfall Model Typical phases IEEE process standard P1074, 1/1/91 (see Fig 1.16, p. 25) explore } concept pre-development process P Requirements system allocation P Analysis } require- ments P Design Development } development design process P Implementation imple- P Validation ment P Maintenance install operation P Retire & support post-development process { mainten- ance retire CS 2250, Chap 1 Slide 15 of 20 CS 2250, Chap 1 Slide 16 of 20 Iterated Waterfall Model Spiral Model Iteration allows corrections & refinements (see Fig 1.16) A contemporary life cycle P Inception P need P Elaboration system < idea is sufficiently < requirements well founded to articulated & P problem domain warrant entering the requirements prioritized elaboration phase < testing planned < strategic/tactical P organization/structure design P Transition P implementation P Construction coding < phased delivery < allocate < move to next resources P validate testing component < requirements & < evaluate evaluation criteria improvements examined maintenance and corrections < Code P fix/update an increment iteration CS 2250, Chap 1 Slide 17 of 20 CS 2250, Chap 1 Slide 18 of 20

Design and Development Common Errors Details on pp. 33 - 39 See pp. 37 - 38 P Analyze the problem P Rushing to code < Outputs P Forgetting to back up program < Inputs P Failing to understand that computers do exactly as told < Formulas < Perform hand calculation P Programming error classifications P Select / develop algorithm < Syntax < Run-time P Write program < Logical P Test and correct CS 2250, Chap 1 Slide 19 of 20 CS 2250, Chap 1 Slide 20 of 20