David Evans cs.virginia/~evans

1. 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

2. Menu • What is Engineering? • Can we engineer software? • Small, Fun Programs vs. Big, Important Programs • Managing Complexity • Course Mechanics • PS1, Java Introduction CS 201j Fall 2002

3. What is Engineering? CS 201j Fall 2002

4. Webster’s Definitions en·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. 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 CS 201j Fall 2002

6. Computing Power 1969-2002(in Apollo Control Computer Units) Moore’s Law: computing power doubles every 18 months!

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 CS 201j Fall 2002

8. How is engineering software different from engineering bridges? 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 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 (); } } 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 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 CS 201j Fall 2002

13. Small, Fun Programsvs.Big, Important Programs CS 201j Fall 2002

14. 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 Small, Fun Programs Big, Important Programs CS 201j Fall 2002

15. 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 Small, Fun Programs Big, Important Programs 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 CS 201j Fall 2002

17. How can we manage Complexity? CS 201j Fall 2002

18. Modularity • Divide complex systems into many components • Develop components independently • Assemble them to solve the problem 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 CS 201j Fall 2002

20. How can we make systems dependable? 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 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 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 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 CS 201j Fall 2002

25. Course Mechanics 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 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 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 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 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. 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 CS 201j Fall 2002

32. Programming Systems C++ Program Scheme Program C++ Compiler Scheme Interpreter Object Files Machine CS 201j Fall 2002

33. 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 VM Java Program Why use a virtual machine? Java Compiler Class Files Java Virtual Machine Machine 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 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 alive What abstractions should we use? 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 CS 201j Fall 2002

37. Example Class public 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; … 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; } CS 201j Fall 2002

39. Objects local variable Cell c1 = new Cell (); c1 abstract Cell object Cell object instance variable state: CellState object CS 201j Fall 2002

40. Method Calls <object>.<method> (<parameters>) c1 .getNextState () local variable c1 abstract Cell object this Evaluate c1 to obtain the object it refers to. Set this to point to that object Evaluate the body of the method public CellState getNextState () // EFFECTS: Returns next state value for // this. { return this.state; } CS 201j Fall 2002 (this is optional here)

41. Inheritance We can create a new class that inherits methods and state from another class: public class ExtremeLifeCell extends Cell { … } CS 201j Fall 2002

42. Overriding In 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 (); } } 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 ConwayLifeCell getNextState method is called 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 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 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! CS 201j Fall 2002