Top Banner
David Evans http://www.cs.virginia.edu/ ~evans CS201j: Engineering Software? University of Virginia Computer Science Lecture 1: Engineering Software, Constructing Poetry and Dancing about Architecture
46

David Evans cs.virginia/~evans

Jan 03, 2016

Download

Documents

gay-morrow

Lecture 1: Engineering Software, Constructing Poetry and Dancing about Architecture. David Evans http://www.cs.virginia.edu/~evans. CS201j: Engineering Software? University of Virginia Computer Science. Menu. What is Engineering? Can we engineer software? - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: David Evans cs.virginia/~evans

David Evanshttp://www.cs.virginia.edu/~evans

CS201j: Engineering Software?University of VirginiaComputer Science

Lecture 1: Engineering Software, Constructing Poetry and Dancing about Architecture

Page 2: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 2

Menu

• What is Engineering?– Can we engineer software?

• Small, Fun Programs vs. Big, Important Programs

• Managing Complexity

• Course Mechanics

• PS1, Java Introduction

Page 3: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 3

What is Engineering?

Page 4: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 4

Webster’s Definitionsen·gi·neer·ing ( n j -nîr ng) n. 1a. The application of scientific and mathematical

principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.

b. The profession of or the work performed by an engineer.

2. Skillful maneuvering or direction: geopolitical engineering; social engineering.

Page 5: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 5

Design Under Constraint“Engineering is design under constraint… Engineering is synthetic - it strives to create what can be, but it is constrained by nature, by cost, by concerns of safety, reliability, environmental impact, manufacturability, maintainability and many other such 'ilities.' ...”

William Wulf

Page 6: David Evans cs.virginia/~evans

Computing Power 1969-2002(in Apollo Control Computer Units)

0

500000

1000000

1500000

2000000

2500000

3000000

3500000

4000000

45000001969

1971

1972

1974

1975

1977

1978

1980

1981

1983

1984

1986

1987

1989

1990

1992

1993

1995

1996

1998

1999

2001

2002

Moore’s Law: computing power doubles every 18 months!

Page 7: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 7

Constraints Software Engineers Face

• Not like those for “real” engineers:– Cost, weight, physics, etc.– Lab machines have ~ 1 million times what

was needed to get to the Moon

• Complexity of what we can understand

• Most important constraint is cost of human effort to get reliability, safety, maintainability

Page 8: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 8

How is engineering software different from engineering

bridges?

Page 9: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 9

• Continuous– Calculus– Testing/analysis is

easy: if the bridge holds for 1M kg, it also probably holds 0.99Mkg

• Discrete– Logic, Discrete

Mathematics– Testing/analysis is

difficult

Bridges Software

Page 10: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 10

• Made of physical stuff– Some costs are

obvious– Changes after

construction are hard

• Made of virtual stuff– All costs are non-

obvious– Changes should be

easy (but they’re not)

Bridges Software

for (int i = 0; i < rows; i++) { for (int j = 0; j < columns; j++) { nextStates [i][j] = getCellAt (i, j).getNextState (); } }

Page 11: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 11

• Obvious when it falls down– Bridge makers get

sued– Architects need

licenses

• Falls down quietly (usually)– Software vendors

blame user, charge for upgrades

– Anyone can make software

Bridges Software

Page 12: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 12

• Requirements are (usually) obvious and easy to describe

• A good design is apparent to everyone immediately

• Requirements are mysterious and hard to describe

• A good design is only apparent to “experts” but has impact later on

Bridges Software

Page 13: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 13

Small, Fun Programsvs.

Big, Important Programs

Page 14: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 14

Small, Fun Programs

• CS101, CS200, etc.• Happy if it works once

– Test by running once

• If it doesn’t work on some input, no big deal

• Simulated in CS201j• Must work on all

possible inputs– Need validation

strategies

• If it doesn’t work on some input millions are lost, people die

Big, Important Programs

Page 15: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 15

Small, Fun Programs

• Written by a few people over a short period of time– Manage complexity

mostly by memory

• Used by a few people over a short period of time

• Written by many people over many years– Can’t rely on memory

to manage complexity

• Used by many people over many years– Needs to be

maintained as requirements change

Big, Important Programs

Page 16: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 16

How Big are Big Programs?

• Largest program in CS200/CS101: – ~500 lines

• F-22 Steath Fighter Avionics Software– 1.5M lines of code

• 5EEE (phone switching software)– 18M lines

• Windows XP – ~50M lines

Page 17: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 17

How can we manage Complexity?

Page 18: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 18

Modularity

• Divide complex systems into many components

• Develop components independently

• Assemble them to solve the problem

Page 19: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 19

Abstraction and Specification

• Ignore details

• Separate what from how

• Need a specification – description of what a component should do

• Components can be built based on what they should do, not how they should do it

Page 20: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 20

How can we make systems dependable?

Page 21: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 21

Analysis

• Use reasoning and tools to check a design is sound

• Use reasoning and tools to check an implementation is sound

• Test systematically

Page 22: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 22

Redundancy

• Express things in more than one way and check they are consistent

• Extreme example:– Space Shuttle

• 5 on-board computers– 4 duplicates running same software– 1 running completely separate implementation (to same

specifications)

• Common example: variable declarations

Page 23: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 23

Design

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

Tony Hoare

Page 24: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 24

Course Overview

• This course is about constructing dependable software systems– Managing complexity: modularity, abstraction,

specification– Achieving dependability: analysis, redundancy

• Good design is key– How to divide problems into modules– How to hide details

Page 25: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 25

Course Mechanics

Page 26: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 26

Staff

• Coach: David Evans– Joined UVA in Nov 1999– Call me “Dave” or “Coach”– Research areas: security, programming swarms

• Assistant Coaches– Sol Chea – Serge Egelman – Tiffany Nichols – Mike Peck

Page 27: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 27

Help Available• Me

– Office Hours: Wednesdays 2:30-3:30pm– Always available by email, if I don’t reply in 24 hours,

send again and complain

• TAs– Will post staffed lab hours

• Web site: http://www.cs.virginia.edu/cs201j– Everything goes on the web

• But mainly: your classmates

Page 28: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 28

CS201J

• Experimental Course– National Science Foundation sponsorship– Focus on using lightweight analysis tools

• First time offered– I will probably make lots of mistakes– But…you get to take it in a small class

• Counts as CS201, but doesn’t cover everything in CS201

Page 29: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 29

Honor Code

• Classroom Pledge is Horrible!

• The whole point of being at a University is so you can:– Learn from your classmates– Learn better by teaching your classmates

• Sign and return the CS201j Pledge on Friday

Page 30: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 30

Java

Warning: will quickly introduce lots of new concepts – we will spend a lot more time on many of these later.

Page 31: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 31

Java

• Syntax: a lot like C++ (designed to be easy for C and C++ programmers to learn)

• Semantics (what programs mean): a lot like Scheme

• This class does not focus on details of Java language

Page 32: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 32

Programming Systems

Scheme Interpreter

Scheme Program

C++ Compiler

C++ Program

Machine

Object Files

Page 33: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 33

Java VM

• Portability– If you can implement a Java

VM on your machine, then you can run all Java programs

• Security– A VM can limit what programs

can do to the real machine

• Simplicity– VM instructions can be simpler

than machine instructions

Java Compiler

Java Program

Java Virtual Machine

Class Files

Machine

Why use a virtual machine?

Page 34: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 34

Programming in Java

• Program is divided into classes

• A class:– Defines a new datatype– Defines methods and state associated with

that datatype

• We call a value of a class datatype an object

Page 35: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 35

Problem Set 1• Lots of new concepts, but only a few lines

of code

• Implement a class that simulates Conway’s Game of Life:– If a cell is alive and it has 2 or 3 live

neighbors, it stays alive– Otherwise it dies (overcrowding or isolation)– If dead cell has exactly 3 live neighbors, it

becomes aliveWhat abstractions should we use?

Page 36: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 36

Game of Life Abstractions

• Grid of cells

• Cell– Keeps track of its state– Methods to calculate its next state

• But, this depends on states of its neighbors

• State of a cell– Dead or alive

Page 37: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 37

Example Classpublic class Cell { // OVERVIEW: A Cell is an object that // represents a cellular automaton. // A cell has a current state and // location, and a method for

// determining its next state.private CellState state;…

Page 38: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 38

Some Cell Methods

boolean isAlive()

// EFFECTS: Returns true if the cell is

// alive, false otherwise.

{ return state.isAlive(); }

public CellState getNextState ()

// EFFECTS: Returns next state value for // this.

{ return state; }

Page 39: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 39

Objects

Cell c1 = new Cell (); c1

state:

Cell object

CellState object

abstract Cell object

local variable

instance variable

Page 40: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 40

Method Calls

<object>.<method> (<parameters>)

c1 .getNextState ()c1abstract Cell object

local variable

Evaluate c1 to obtain the object it refers to.Set this to point to that objectEvaluate the body of the method

this

public CellState getNextState () // EFFECTS: Returns next state value for // this. { return this.state; }

(this is optional here)

Page 41: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 41

Inheritance

We can create a new class that inherits methods and state from another class:

public class ExtremeLifeCell extends Cell {

}

Page 42: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 42

OverridingIn the new class, we can replace implementations of methods:

public CellState getNextState () // EFFECTS: Returns the next state for this cell. // The next state will be alive if this cell or any of its neighbors // is currently alive. { if (countAliveNeighbors () > 0) { return CellState.createAlive (); } else { return getState (); } }

Page 43: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 43

Dynamic Dispatch

Cell c;

c.getNextState ();

c could be any subtype of Cell

If c is an ConwayLifeCell, then the ConwayLifeCellgetNextState method is called

Page 44: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 44

PS1

• Create a ConwayLifeCell class that is a subtype of the Cell class

• Override the getNextState method to implement the Game of Life rules

• Because of dynamic dispatch, when you run the simulator with your new class, it will call your getNextState method

Page 45: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 45

Classes, Objects, Dispatch

• Lots of complicate issues to deal with:– When is it safe to override a method?– How do we hide implementation details?– When should we use inheritance?

• We will address these later in the course

Page 46: David Evans cs.virginia/~evans

29 August 2002 CS 201j Fall 2002 46

Charge• This class is about:

– Managing complexity: modularity, abstraction, specification

– Engineering dependability: analysis, redundancy, design

• Before 5pm Friday:– Email registration survey

• Before class Tuesday:– Read and sign CS 201j Pledge– Problem Set 1 Due Remember to take pictures!