Software Engineering Prof. Dr. Bertrand Meyer Dr. Manuel Oriol Dr. - - PowerPoint PPT Presentation

▶
software engineering
SMART_READER_LITE
LIVE PREVIEW

Software Engineering Prof. Dr. Bertrand Meyer Dr. Manuel Oriol Dr. - - PowerPoint PPT Presentation

Nov 18, 2023 194 likes •735 views

Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer Dr. Manuel Oriol Dr. Bernd Schoeller Lecture 2: Software Engineering Fundamentals Today We try to put Software Engineering in an historical perspective We

slide-1
SLIDE 1

Software Engineering

  • Prof. Dr. Bertrand Meyer
  • Dr. Manuel Oriol
  • Dr. Bernd Schoeller

Chair of Software Engineering

Lecture 2: Software Engineering Fundamentals

slide-2
SLIDE 2

Today

  • We try to put Software Engineering in an historical

perspective

  • We present several methods and ideas that can help you

build software in a practical way

  • We show what most people software engineers remember
  • f Software Engineering (sic!)

Software Engineering, lecture 2: Fundamentals 2

slide-3
SLIDE 3

Software Engineering

Two Notions are Important:

  • Software
  • Programs
  • Achievements: Internet, Personal Computers,

Information Society…

  • Engineering:
  • Building Process
  • Achievements: Pyramids, Eiffel Tower, Bridges,

Cars…

Software Engineering, lecture 2: Fundamentals 2

slide-4
SLIDE 4

Where it all started

Software Engineering, lecture 2: Fundamentals 2

Augusta Ada King, Countess of Lovelace (1815 – 1852) “First Computer Programmer”

slide-5
SLIDE 5

In notes on the analytical engine

“...an analyzing process must equally have been performed in

  • rder to furnish the Analytical Engine with the necessary
  • perative data; and that herein may also lie a possible

source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong

  • rders.”

in Sketch of The Analytical Engine Invented by Charles Babbage by L. F. Menabrea with notes upon the Memoir by the translator Ada Augusta, Countess of Lovelace

Software Engineering, lecture 2: Fundamentals 2

slide-6
SLIDE 6

Bugs?

  • “It has been just so in all of my inventions. The first step

is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs"—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.”

  • Thomas Eddison, in a letter, 1878 (wikipedia, Software

Bugs)

Software Engineering, lecture 2: Fundamentals 2

slide-7
SLIDE 7

More bugs…

Software Engineering, lecture 2: Fundamentals 2

Mark II operator William "Bill" Burke, 1947, Pasted into log book by Grace Hopper -> coined term Debug

slide-8
SLIDE 8

At that time…

  • Harvard Architecture separates data and program:
  • Program on punched tape
  • Data in memory

Software Engineering, lecture 2: Fundamentals 2

slide-9
SLIDE 9

How to make programs that do not bug?

  • 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' assume cs:cseg,ds:cseg start: jmp start1 msgstr db 'Enter Fahrenheit ' crlf db 13,10,'$’

Software Engineering, lecture 2: Fundamentals 2

slide-10
SLIDE 10

Main Idea

  • Change the Programming Language!

Software Engineering, lecture 2: Fundamentals 2

slide-11
SLIDE 11

The example of FORTRAN

  • FORTRAN 53 (32 instructions)
  • FORTRAN 58
  • added procedures!
  • FORTRAN IV (1962)
  • Added logical expressions and logical IF (before only

arithmetical IF)

  • FORTRAN 66
  • ANSI standard
  • FORTRAN 77
  • ELSE, DO WHILE (before GOTO was used)…
  • FORTRAN 90 and 95
  • Modules, abstract data types,
  • FORTRAN 2003, 2008
  • Objects, procedure pointers

Software Engineering, lecture 2: Fundamentals 2

slide-12
SLIDE 12

First idea

  • In structured programming (Böhm&Jacopini’66,

Dijkstra’69), a program is always expressible as the control-flow instructions:

  • Concatenation (blocks)
  • Selection (if, switch…)
  • Repetition (loops)
  • One entry-point

What is missing?

Software Engineering, lecture 2: Fundamentals 2

GOTO, Multiple entry points

slide-13
SLIDE 13

Why does it help?

  • It is easier to understand the code
  • Easier to prove that it works (Dikstra thought that

code should show a proof)

  • Easier to maintain
  • Easier to write
  • Top-down design and programming

Software Engineering, lecture 2: Fundamentals 2

slide-14
SLIDE 14

This translate into…

  • Procedural programming
  • The unit is the procedure and it groups individual

statements

  • Programmers do not use destructuring instructions (goto)
  • Top-down approach for designing

Software Engineering, lecture 2: Fundamentals 2

slide-15
SLIDE 15

Top-Down approach

  • Also called “Divide and Conquer”
  • 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

slide-16
SLIDE 16

Example

  • A program that removes the comments of source code

Software Engineering, lecture 2: Fundamentals 2

slide-17
SLIDE 17

Example (2)

  • A program that removes the comments of source code
  • Read the file
  • Remove comments
  • Store the modified file back

Software Engineering, lecture 2: Fundamentals 2

slide-18
SLIDE 18

Example (3)

  • 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
  • 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

slide-19
SLIDE 19

Example (4)

  • 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
  • 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

slide-20
SLIDE 20

Example (5)

  • Write the code!

Software Engineering, lecture 2: Fundamentals 2

slide-21
SLIDE 21

Evaluation

  • Advantages:
  • Code is modular
  • Skeletons illustrate the use
  • Programmers do not miss a part of the implementation
  • Disadvantage:
  • The program works at the end only

Software Engineering, lecture 2: Fundamentals 2

slide-22
SLIDE 22

Bottom-up Approach

  • The idea is to make the small parts first and let the

environment assemble them

  • As an example, PROLOG programs are a specification of

the inferences. The system deduces the facts

Software Engineering, lecture 2: Fundamentals 2

slide-23
SLIDE 23

Top-down AND Bottom-up

  • Most of the current approaches actually mix the two

approaches:

  • Top-down for the design
  • Bottom-up, by using libraries or composing components

Software Engineering, lecture 2: Fundamentals 2

slide-24
SLIDE 24

And the world became Objects

  • Breakthrough with Simula 67
  • Coupling data types and code
  • Objects deal with reuse
  • Objects deal with modularity
  • Objects model naturally some paradigms (e.g. GUI,

libraries)

Software Engineering, lecture 2: Fundamentals 2

slide-25
SLIDE 25

Modularity

  • Classes are whole units they allow the co-localization of

code and relevant data

  • Deferred (abstract) classes help enforce that
  • Client relationship helps to encapsulate
  • Easy graphical representation

Software Engineering, lecture 2: Fundamentals 2

slide-26
SLIDE 26

Reuse

  • Easy extensions with inheritance.
  • Generics help reuse the code across types
  • Strong types help with the possible mismatches
  • Libraries shorten development time

Software Engineering, lecture 2: Fundamentals 2

slide-27
SLIDE 27

Design by Contracts

  • Design by contracts is the next step towards correctness
  • f the code and the data (in Eiffel, Java/JML, Spec#)
  • Invariants check data at each method call
  • 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

slide-28
SLIDE 28

Languages only are not the solution…

  • The fact is that bugs are still found in most (if not all)

programs, classes…

  • As an example automated tools find bugs in (almost) all

classes

Software Engineering, lecture 2: Fundamentals 2

slide-29
SLIDE 29

Bugs found by AutoTest in Eiffel classes

  • The fact is that bugs are still found in most (if not all)

programs, classes…

  • As an example:

Software Engineering, lecture 2: Fundamentals 2

slide-30
SLIDE 30

Other factors

  • The final programmer code is not the only parameter to

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

slide-31
SLIDE 31

How do you develop a project?

  • Code and fix?
  • Design, code and fix?
  • Design, code, test, fix?
  • Design, code, test, document and fix?

Software Engineering, lecture 2: Fundamentals 2

slide-32
SLIDE 32

Suggestions to improve the situation?

  • What would you do to improve the situation?

Software Engineering, lecture 2: Fundamentals 2

slide-33
SLIDE 33

How to reduce the issues?

  • By Describing: Specifying and Documenting
  • By Implementing: Designing and Coding
  • By Assessing: verifying, validating, analyzing, testing,

measuring (both products and processes).

  • By Managing: organizing the work, communicating,

collaborating

  • By Operating: deploying systems and overseeing their

proper functioning.

Software Engineering, lecture 2: Fundamentals 2

slide-34
SLIDE 34

Software Development Process

  • A software development process is a process used to

develop applications.

  • Proponents of the process hope that it reduces the

discrepancies between what the program is supposed to do and what it actually does.

  • There are two main types of processes:
  • Sequential
  • Iterative

Software Engineering, lecture 2: Fundamentals 2

slide-35
SLIDE 35

What is considered?

Software Engineering, lecture 2: Fundamentals 2

Feasibility study Requirements Specification Global design Detailed design Implemen- tation Distribution V & V Prototyping Unit Testing Acceptance Testing System Testing

slide-36
SLIDE 36

Original waterfall model

Software Engineering, lecture 2: Fundamentals 2

Winston Royce, 1970, source: wikipedia, waterfall model

slide-37
SLIDE 37

Sequential Model: Waterfall Model

Software Engineering, lecture 2: Fundamentals 2

Feasibility study Requirements Specification Global design Detailed design Implemen- tation Distribution V & V

slide-38
SLIDE 38

Software Engineering, lecture 2: Fundamentals 2

Waterfall risk profile

Requirements Design Implementation Integration, V&V… Time Potential impact of risk being tackled

  • C. Larman Agile & Iterative Development A Manager guide Addison Wesley 2003 p. 58
slide-39
SLIDE 39

Strength and Weaknesses

  • Advantages:
  • Widely used…
  • Time spent early on helps later on to remove some

unnecessary delays

  • Emphasis on documentation and source code
  • Simple
  • Disadvantages
  • Difficult for big projects to have one phase only
  • Most steps are not easily finished
  • Even Royce advocated for an iterative model in the
  • riginal paper!

Software Engineering, lecture 2: Fundamentals 2

slide-40
SLIDE 40

The sashimi model?

  • The steps are overlapping:

Software Engineering, lecture 2: Fundamentals 2

Distribution Feasibility study Requirements Specification Global design Detailed design Implemen- tation Distribution V & V

Peter DeGrace

slide-41
SLIDE 41

Sequential Model: V-model

Software Engineering, lecture 2: Fundamentals 2

Feasibility study Requirements Specification Global design Detailed design Implemen- tation Distribution Unit Testing Acceptance Testing System Testing Distribution

German Ministry of Defense, 1992

slide-42
SLIDE 42

V-Model (2)

Software Engineering, lecture 2: Fundamentals 2

Source: V-model, wikipedia

slide-43
SLIDE 43

Strength and Weaknesses

  • Advantages:
  • The testing begins very early on in the project
  • The implementation and design are guided by testing
  • Disadvantages
  • It is still a sequential model (requirements do not

change etc…)

Software Engineering, lecture 2: Fundamentals 2

slide-44
SLIDE 44

Sequential Model: Evolutionary Model

Software Engineering, lecture 2: Fundamentals 2

Brooks, 1995

Implemen- tation User Tests Prototyping Implemen- tation Distribution

slide-45
SLIDE 45

Strength and Weaknesses

  • Advantages:
  • The prototype permits an early assessment
  • User test the first prototype and give feedback
  • Disadvantages
  • Code it twice! (sometimes not possible)

Software Engineering, lecture 2: Fundamentals 2

slide-46
SLIDE 46

Iterative Model: Prototype Model

Software Engineering, lecture 2: Fundamentals 2

Implemen- tation User Tests Prototyping Distribution

slide-47
SLIDE 47

Strength and Weaknesses

  • Advantages:
  • The prototype permits an early assessment
  • User test the prototype and give feedback
  • Feedback integrated
  • Disadvantages
  • You have to code it twice! (sometimes not possible)

Software Engineering, lecture 2: Fundamentals 2

slide-48
SLIDE 48

Iterative Model: Spiral Model

Software Engineering, lecture 2: Fundamentals 2

Barry Boehm, 1988

slide-49
SLIDE 49

Characteristics

  • The iterations typically take 6 months to 2 years to

proceed

  • It creates successions of prototypes as well

Software Engineering, lecture 2: Fundamentals 2

slide-50
SLIDE 50

Strength and Weaknesses

  • Advantages:
  • Manages the risk
  • Estimates are more realistic with time
  • Manage changes
  • Software Engineers start working earlier
  • Disadvantages
  • A bit of an overkill for small projects

Software Engineering, lecture 2: Fundamentals 2

slide-51
SLIDE 51

Why did it evolve?

  • Agencies need to control the development and have

accountability for delays

  • The quality of the software is at the core of the

processes

  • People can then rely on a more codified process

Software Engineering, lecture 2: Fundamentals 2

slide-52
SLIDE 52

Today

  • We saw how programming languages evolved to help

programmers avoid writing bugs as much as possible

  • We talked about the emergence of processes for

engineering software

  • We showed processes that are very used in companies

Software Engineering, lecture 2: Fundamentals 2

slide-53
SLIDE 53

Next week

  • Requirements
  • Standards
  • Categories

Software Engineering, lecture 2: Fundamentals 2