1 / 29

Introduction

Introduction. Administrative. 70% Exam, 30% Homeworks Must pass exam 4-5 Homeworks Homework grades: 80 is easy, 100 is hard 1-2 Class exercises Lecture in tutorial slot Office hours: by e-mail appointment imaman@cs. An academic course is limited …. We want to emulate Changing requests

warwickd
Télécharger la présentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction

  2. Administrative • 70% Exam, 30% Homeworks • Must pass exam • 4-5 Homeworks • Homework grades: 80 is easy, 100 is hard • 1-2 Class exercises • Lecture in tutorial slot • Office hours: by e-mail appointment • imaman@cs

  3. An academic course is limited … • We want to emulate • Changing requests • Partial/Underspecified requests • Project is never closed – no end point • Large teams • Large code base • Time factor – human memory is limited • Multiple users • Multiple versions • Wide area – many non-overlapping topics • Interfacing with external “things” • Lecture time is limited - cannot present complex code • Too much code vs. too much explanations

  4. Learning this Course • Close to social science/literature • No formulas, no proofs, no right answer • You need to forget a few things • Wide but not deep, no linear order • Extrapolation: from the simple examples to complex scenarios • Requires a different state of mind

  5. Our Context • OOP • Mostly static typing • Performance is not issue • Things everyone can use • You will write slower!

  6. Motivation • We need to deliver good programs • Bugs: results may be catastrophic • Project is 95% done, 80% of the time • Expensive to change: software is not “soft” (!) • In short: programs are complicated • Two issues • Definition of quality • Techniques for achieving quality

  7. A One-Line Summary • Write test!

  8. A Two-Line Summary • Rule #1:Write test! • Rule #2:Programming is a process of trial-and-error process

  9. A Slightly Deeper Summary • Rule #1:Write test! • Rule #2:Programming is a process of trial-and-error process • Rule #3, #4, #5: Turing Church • Rule #6: There is no rule #7

  10. The Turing & Church Rules • A program may contain other programs • You cannot know if a program is doing what you expect it to do • If it can be done at all, it can be done in many ways

  11. Quality in Software ? • #bugs in the present • #bugs in the future • Time to develop • Time to add a feature • Time to learn the code • LOC ? • #Users • Revenues • Conclusions • Many contradicting factors • Measuring is hard

  12. Statistical Correlation • Conduct an experiment • Measure quality once over a large enough sample • Correlate with other properties (that are easier to measure) • Similar to clinical trials • Candidates for “other properties” • Source code metrics, development methodologies, language/technology/tools used • Does not work: Expensive • Sample size is too small compared to variance • Participants must be isolated of new techniques for the duration of the experiment • Hidden bugs • Conclusion: software metrics are very limited • Not surprising: measuring quality seems to be at odds with Turing

  13. Burn Charts • Time is important. let’s describe our progress vs. time • Vertical axis: tasks completed • Horizontal axis: time line

  14. Burn Up

  15. Burn Up Example

  16. Quality in Software • High-quality: A software whose burn curve is linear • Similar to Big-O notation of algorithms • Does not distinguish between two linear curves • Differences in domain, languages, … • States that a flattening is the #1 risk • Can be experienced even in student assignments • Result oriented • Unlike code metrics whose correlation with the net result is indirect (at best) • Requires constant feedback, short iterations • Past is measurable • Provides some confidence for the future

  17. Achieving Linear Burn Up • The reason why people are obsessed with design • A good design => High quality • Two questions • What is design? • How can one achieve good design?

  18. (Intelligent) Code Review • Context • Schedule considerations • Criticality • Legacy • Not all parts of a program should be of the same quality • Readability • “Code is for communication” • Code is read more than written

  19. What is Design (I) • Sufficient information for a craftsman oftypical skill to be able the build the artifact without excessive creativity. • (Guy Steele)

  20. public class Calculator { int x; public A(int n) { x = n; } public int add(int y) { return x + y; } public int sub(int y) { return x – y; }}

  21. Using a Calculator Object • Compute 5 + 9, put result in x • int x = 5 + 9; • int x = new Calculator(5).add(9); • Protocols induce a new programming language

  22. Class IndentingPrinter • public class IndentingPrinter { • private String indentation = ""; • private final StringBuilder sb = new StringBuilder(); • public void inside() { indentation += " "; } • public void outside() { indentation = indentation.substring(2); } • public void print(String s) { • sb.append(indentation).append(s).append('\n'); • } • @Override • public String toString() { return sb.toString(); } • }

  23. Using IndentingPrinter’s Language • public class Book { • private String name; • public Book(String name) { this.name = name; } • public void print(IndentingPrinter p) { p.print("Book: " + name); } • } • public class Library { • private String name; • private List<Book> books = new ArrayList<Book>(); • public Library(String name) { this.name = name; } • public void add(Book b) { books.add(b); } • public void print(IndentingPrinter p) { • p.print("Library: " + name); • for (Book b : books) • b.print(p); • } • }

  24. Class IndentingPrinter (II) • public static class IndentingPrinter { • private final String indentation; • private StringBuilder sb = new StringBuilder(); • public IndentingPrinter() { this("", new StringBuilder()); } • private IndentingPrinter(String indentation, StringBuilder sb) { • this.indentation = indentation; • this.sb = sb; • } • public IndentingPrinter inside() { • return new IndentingPrinter(indentation + " ", sb); • } • public void print(String s) { • sb.append(indentation).append(s).append('\n'); • } • @Override • public String toString() { return sb.toString(); } • }

  25. New Protocol => New Language • // Book remains the same ... • public static class Library { • private String name; • private List<Book> books = new ArrayList<Book>(); • public Library(String name) { this.name = name; } • public void add(Book b) { books.add(b); } • public void print(IndentingPrinter p) { • p.print("Library: " + name); • for (Book b : books) • b.print(p.inside()); • } • }

  26. Which Version do you like better?

  27. What is Design (II) • Design is the language induced by the protocols of the objects that are available at a certain context

  28. “Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another. If you don't understand both sides of an issue, you cannot make an intelligent choice; in fact, if you don't understand all the ramifications of your actions, you're not designing at all. You're stumbling in the dark” • Allen Holub, “Why getter and setter methods are evil”, • http://www.javaworld.com

More Related