Today Chair of Software Engineering • We try to put Software Engineering in an historical Software Engineering perspective Prof. Dr. Bertrand Meyer Dr. Manuel Oriol Dr. Bernd Schoeller • We present several methods and ideas that can help you build software in a practical way Lecture 2: Software Engineering • We show what most people software engineers remember Fundamentals of Software Engineering (sic!) Software Engineering, lecture 2: Fundamentals 2 Software Engineering Where it all started Two Notions are Important: Software Programs Achievements: Internet, Personal Computers, Augusta Ada King, Information Society… Countess of Lovelace (1815 – 1852) Engineering: “First Computer Programmer” Building Process Achievements: Pyramids, Eiffel Tower, Bridges, Cars… Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 In notes on the analytical engine Bugs? “...an analyzing process must equally have been performed in • “It has been just so in all of my inventions. The first step order to furnish the Analytical Engine with the necessary is an intuition, and comes with a burst, then difficulties operative data; and that herein may also lie a possible arise—this thing gives out and [it is] then that "Bugs"—as source of error. Granted that the actual mechanism is such little faults and difficulties are called—show unerring in its processes, the cards may give it wrong themselves and months of intense watching, study and orders.” labor are requisite before commercial success or failure is certainly reached.” in • Thomas Eddison, in a letter, 1878 (wikipedia, Software Sketch of The Analytical Engine Invented by Charles Bugs) Babbage by L. F. Menabrea with notes upon the Memoir by the translator Ada Augusta, Countess of Lovelace Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 1
More bugs… At that time… • Harvard Architecture separates data and program: Program on punched tape Data in memory Mark II operator William "Bill" Burke, 1947, Pasted into log book by Grace Hopper -> coined term Debug Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 How to make programs that do not bug? Main Idea • That’s the real question… • Idea: When your actual code is too close to the machine, it is hard to debug How to read: (x86 asm) cseg segment para public 'CODE' Change the Programming Language! • assume cs:cseg,ds:cseg start: jmp start1 msgstr db 'Enter Fahrenheit ' crlf db 13,10,'$’ Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 The example of FORTRAN First idea • FORTRAN 53 (32 instructions) • FORTRAN 58 • In structured programming (Böhm&Jacopini’66, added procedures! Dijkstra’69), a program is always expressible as the control-flow instructions: • FORTRAN IV (1962) Added logical expressions and logical IF (before only arithmetical IF) Concatenation (blocks) • FORTRAN 66 Selection (if, switch…) ANSI standard Repetition (loops) • FORTRAN 77 One entry-point ELSE, DO WHILE (before GOTO was used)… • FORTRAN 90 and 95 GOTO, Modules, abstract data types, What is missing? Multiple entry points • FORTRAN 2003, 2008 Objects, procedure pointers Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 2
Why does it help? This translate into… • It is easier to understand the code • Procedural programming Easier to prove that it works (Dikstra thought that code should show a proof) • The unit is the procedure and it groups individual statements Easier to maintain • Programmers do not use destructuring instructions (goto) Easier to write • Top-down approach for designing • Top-down design and programming Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 Top-Down approach Example • Also called “Divide and Conquer” • A program that removes the comments of source code • Best example: Stepwise refinements (Wirth’75, http://sunnyday.mit.edu/16.355/wirth- refinement.html) • The idea is to consider the problem in its entirety and state it simply • Then decompose into smaller units in a recursive manner • When not possible to decompose anymore, code the smaller units Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 Example (2) Example (3) • A program that removes the comments of source code • A program that removes the comments of source code Read the file Read the file Remove comments Open the file Store the modified file back Read line by line and put in an array of strings Remove comments Iterate through the array, in each line, remove the comment Store the modified file back Iterate through the array, store each line Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 3
Example (4) Example (5) • A program that removes the comments of source code Read the file Open the file Read line by line and put in an array of strings Remove comments • Write the code! Iterate through the array, in each line look for first sequence “--” remove the rest of the line Store the modified file back Iterate through the array, store each line Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 Evaluation Bottom-up Approach • Advantages: • The idea is to make the small parts first and let the environment assemble them Code is modular Skeletons illustrate the use Programmers do not miss a part of the implementation • As an example, PROLOG programs are a specification of the inferences. The system deduces the facts • Disadvantage: The program works at the end only Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 Top-down AND Bottom-up And the world became Objects • Most of the current approaches actually mix the two • Breakthrough with Simula 67 approaches: • Coupling data types and code Top-down for the design • Objects deal with reuse Bottom-up, by using libraries or composing components • Objects deal with modularity • Objects model naturally some paradigms (e.g. GUI, libraries) Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 4
Modularity Reuse • Easy extensions with inheritance. • Classes are whole units they allow the co-localization of code and relevant data • Generics help reuse the code across types • Deferred (abstract) classes help enforce that • Strong types help with the possible mismatches • Client relationship helps to encapsulate • Libraries shorten development time • Easy graphical representation Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 Design by Contracts Languages only are not the solution… • Design by contracts is the next step towards correctness • The fact is that bugs are still found in most (if not all) of the code and the data (in Eiffel, Java/JML, Spec#) programs, classes… • Invariants check data at each method call • As an example automated tools find bugs in (almost) all classes • Preconditions ensure that the application is in a valid state before a call • Postconditions ensure that the code proceeded in a good manner Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 Bugs found by AutoTest in Eiffel classes Other factors • The fact is that bugs are still found in most (if not all) programs, classes… • The final programmer code is not the only parameter to • As an example: consider when executing the code: the operating system, the libraries, the runtime system • What is needed is not easily identifiable • Programmers can make mistakes Software Engineering, lecture 2: Fundamentals 2 Software Engineering, lecture 2: Fundamentals 2 5
Recommend
More recommend
