1. EE422C Software Design and Implementation II Vallath Nandakumar Fall 2015

2. 2 Lecture 1 Announcements Read syllabus before next class Topics for today Introductions course/syllabus overview Java

3. 3 Websites Canvas: courses.utexas.edu My Home Page: ece.users.utexas.edu/~vallathn Course web-page: accessible from my home page Slides: will be posted Handouts: Programming Assignments: Subversion repository...

4. 4 The teaching team Instructor Vallath Nandakumar (vallathn@austin.utexas.edu)vallathn@austin.utexas.edu Office hours: Th 12:30-1:00pm (first week) TBD for later weeks First time teaching this class, and first time in EE PhD in EECS from UC Berkeley Several years in Tektronix, AMD in chip design Graduate TA Jocelyn Egner (jocelynegner@utexas.edu)jocelynegner@utexas.edu Office hours: TBD Undergraduate TA Xavier Salazar (x.salazar1729@utexas.edu) Office hours: See web page

5. Contacting the teaching staff Post on Piazza if the question might be of general interest. Email the instructor or instructors. Go to office hours. Emailing through Canvas is not encouraged, unless it is a response to something the instructor has sent, or a comment that the instructor has made on Canvas. 5

6. Piazza Used to make some instructor announcements Students may ask follow-on questions or make comments. Important for students to read these instructor announcements in a timely manner. Students may post notes, discussions, or ask questions. Students may share allowed assignment-related material. May use Piazza to find partner for group assignments. 6

7. iClicker Register your iClicker remote at iClicker.com Bring your iClicker to every lecture. Answer at least 3/4 of the questions to get credit for that day. If you have questions, email me with your iClicker remote ID and your UT EID. 7

8. Discussion Sections Will be conducted by the TA’s Might have graded quizzes Arrive on time, and leave only at the end Come prepared with questions for TA’s about the assignments etc. 8

9. 9 EE422C in Context software design and implementation II (in java) software engineering systems software other non ECE areas other ECE areas introductory programming in C embedded systems

10. 10 goals for this class (1) how to create appropriate abstractions (e.g., procedural and data) to solve complex programming problems a practical understanding of a variety of common data structures when and where they are applicable, and how to use them knowledge of the advanced constructs of a high level programming language (java)

11. 11 goals for this class (2) a good understanding of basic software engineering principles and practices how to analyze a problem? how to design a system? how to write good code (conforming to style standards)? how to design and test for correctness? how to analyze program performance? prepare you to use this knowledge in future courses that require you to develop software/hardware systems

12. 12 high points of syllabus prerequisite, EE312C programming if no prereq or doesn't seem prereq met, see me you are responsible for all materials presented in classes, whether you attend or not material presented in class is in addition to the book. the purpose of the lecture notes is to help you listen in class ONLY textbook: data structures and problem solving using java, 4th edition by mark allen weiss, ISBN 0321541405.

13. 13 schedule highlights today is our first formal lecture there will be two in-class exams, and a final exam programming assignments (6-7) will come out throughout the semester

14. 14 java programming our first topic of study is java; what’s different from C (or C++) we will be doing all programming assignments in the java programming language computer resources available you can also get a Java compiler and do assignments at home; but your code must compile/execute on ENS machines

15. 15 assignments and grading (1) assignments will be 6-7 programs programs to be completed independently unless i state otherwise we might do some pair and/or team programming Two in-class exams during the semester may have pop quizzes any time grades made up of: 65% exams/quizzes 35% assignments/exercises, iClicker

16. 16 assignments and grading (2) exam grades may be curved if warranted assignments turned in late will NOT be accepted your program must compile and run successfully on the ENS lab configuration when graded assignments are normally graded on a 35 point scale each assignment may have different criteria partial credit may be given correctness, style, performance, etc. will be scored

17. 17 syllabus all the remaining details of the course policies, rules, grading criteria, and procedures are in the syllabus document on the class blackboard page - read it for next week and be prepared to ask questions

18. 18 questions about course administration?

19. iClicker question The purpose of iClicker is to: A.Wake you up B.Make sure you understand just-taught concepts C.Encourage attendance D.All of the above 19

20. what is software engineering? SWE is to CS as ChemE is to chemistry SWEs use a disciplined approach to the development of software-driven systems SWE ! = programmer; SE is a relatively new field of study that applies to all types of systems that are developed as usable products there are many different jobs that SWEs do it is a challenging career because of the inherent problems of software - as well as the rate of change in computing technologies, and the ever broadening range of applications

21. 21 software is complex malleable intangible abstract solves complex problems interacts with other software and hardware consequently, often software is buggy

22. 22 what is a bug? etymology [wikipedia] perhaps first use of term in hardware engineering to describe mechanical failures, e.g., 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 Edison, 1878

23. 23 first actual case of bug being found harvard mark II

24. ariane-5, 1996 crashed–went off-course 37 sec into flight sequence 24 Photos: ESA/CNES

25. mars polar lander, 1999 crashed–premature shut down at 40 meters altitude 25 Photos: JPL/NASA

26. 26 USS yorktown, 1997 “dead in the water” for 3 hours Photo: navsource.org

27. What is the Heartbleed bug? Exploits a vulnerability in OpenSSL software library, used to implement the Transport Layer Security protocol used in web, instant messaging etc. Exposes user’s passwords, cookies and other data to the attacker. Not a virus. One small bug in Open-Source software that made millions of computers vulnerable.

29. Buffer over-read bug The extra data that is sent back is fetched from the server’s memory, due to the bug. It could include passwords and private keys. Like if someone you had called in to fix your plumbing were to look through your closets for information.

30. When was this bug introduced discovered, and fixed? Introduced in Dec. 2011, by one of the authors (Seggelmann) of the (open-source) software team. Discovered on April 1, by Neel Mehta of Google, and Codenomicon. Fixed right away, but servers have to use the new software.

31. khurshid: assertion-driven error recovery31 warranties–two decades ago ACM SIGSOFT Software Engineering Notes, Vol. 12, No. 3, July 87

32. khurshid: assertion-driven error recovery32 warranties–two decades ago (2) ACM SIGSOFT Software Engineering Notes, Vol. 12, No. 3, July 87

33. khurshid: assertion-driven error recovery33 warranties–today apple “Apple warrants the media on which the Apple Software is recorded and delivered by Apple to be free from defects in materials and workmanship under normal use for a period of ninety (90) days from the date of original retail purchase.” “... THE APPLE SOFTWARE IS PROVIDED "AS IS", WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND...” google “... is provided "as is," with no warranties whatsoever.” microsoft “... the Software will perform substantially in accordance with the accompanying materials for a period of ninety (90) days...”

34. 34 economic impact “The Economic Impact of Inadequate Infrastructure for Software Testing” NIST Report, May 2002 $59.5B annual cost of inadequate software testing infrastructure $22.2B annual potential cost reduction from feasible infrastructure improvements

35. 35 do you know of any correct program? :-)

36. 36 what’s in a name? anomaly bug crash defect error, exception failure, fault, flaw, freeze glitch hole issue...

37. 37 correctness common (partial) properties segfaults, uncaught exceptions resource leaks data races, deadlocks specific properties requirements specification

38. 38 traditional waterfall model requirements analysis design checking implementation unit testing integration system testing maintenance verification

39. 39 phases (1) requirements specify what the software should do analysis: eliminate/reduce ambiguities, inconsistencies, and incompleteness design specify how the software should work split software into modules, write specifications checking: check conformance to requirements

40. 40 phases (2) implementation specify how the modules work unit testing: test each module in isolation integration specify how the modules interact integration testing: test module interactions system testing: test entire system maintenance evolve software as requirements change regression testing: test changes

41. 41 testing effort reported to be >50% of development cost [eg. Beizer’90] microsoft: 75% time spent testing 50% testers who spend all time testing 50% developers who spend half time testing

42. 42 when to test the later a bug is found, the higher the cost orders of magnitude increase in later phases also the smaller chance of a proper fix old saying: test often, test early new methodology: test-driven development write tests before code

43. 43 software still buggy folklore: 1-10 (residual) bugs per 1000 nbnc lines of code (after testing) consensus: total correctness impossible to achieve for complex software risk-driven finding/elimination of bugs focus on specific correctness properties

44. 44 approaches for detecting bugs software testing model checking (static) program analysis

45. 45 software testing dynamic approach run code for some inputs, check outputs checks correctness for some executions main questions test-input generation test-suite adequacy (coverage criteria) test oracles

46. 46 model checking typically hybrid dynamic/static approach checks correctness for all executions some techniques explicit-state model checking symbolic model checking abstraction-based model checking

47. 47 static analysis static approach checks correctness for all executions some techniques abstract interpretation dataflow analysis verification-condition generation

48. 48 current status testing remains the most widely used approach for bug finding validation: are we building the right system? verification: are we building the system right? a lot of recent progress (say last 7-8 years) on model checking and static analysis model checking: from hardware to software static analysis: from sound to practical vibrant research in the area gap between research and practice

49. iClicker question Model-checking and static analysis of programs is hard because of “state-space explosion”. If there is a 1-Mbit memory, the number of states to consider is: A.1 million B.2^(1 million) C.Other 49

50. iClicker question After 1 clock cycle where a memory write can happen, the number of states to explore is: A.2 million B.2^(2 million) C.2^(1 million) * 2 D.Other 50

51. 51 next time basics of java and eclipse hands-on experience with small programs

52. 52 ?/!