well behaved objects behaved objects well
play

Well- -behaved objects behaved objects Well Improving your coding - PowerPoint PPT Presentation

Well- -behaved objects behaved objects Well Improving your coding skills 1.0 Main concepts to be covered Main concepts to be covered Testing Debugging Test automation Writing for maintainability 10/11/2005 Lecture 6:


  1. Well- -behaved objects behaved objects Well Improving your coding skills 1.0

  2. Main concepts to be covered Main concepts to be covered • Testing • Debugging • Test automation • Writing for maintainability 10/11/2005 Lecture 6: Wel-behaved Objects 2

  3. We have to deal with errors We have to deal with errors • Early errors are usually syntax errors . • The compiler will spot these. • Later errors are usually logic errors . • The compiler cannot help with these. • Also known as bugs. • Some logical errors have no immediately obvious manifestation. • Commercial software is rarely error free. 10/11/2005 Lecture 6: Wel-behaved Objects 3

  4. Prevention vs vs Detection Detection Prevention (Developer vs vs Maintainer) Maintainer) (Developer • We can lessen the likelihood of errors. • Use software engineering techniques, like encapsulation. • We can improve the chances of detection. • Use software engineering practices, like modularization and documentation. • We can develop detection skills. 10/11/2005 Lecture 6: Wel-behaved Objects 4

  5. Testing and debugging Testing and debugging • These are crucial skills. • Testing searches for the presence of errors. • Debugging searches for the source of errors. • The manifestation of an error may well occur some ‘distance’ from its source. 10/11/2005 Lecture 6: Wel-behaved Objects 5

  6. Testing and debugging Testing and debugging techniques techniques • Unit testing (within BlueJ) • Test automation • Manual walkthroughs • Print statements • Debuggers 10/11/2005 Lecture 6: Wel-behaved Objects 6

  7. Unit testing Unit testing • Each unit of an application may be tested. • Method, class, module (package in Java). • Can (should) be done during development. • Finding and fixing early lowers development costs (e.g. programmer time). • A test suite is built up. 10/11/2005 Lecture 6: Wel-behaved Objects 7

  8. Testing fundamentals Testing fundamentals • Understand what the unit should do – its contract . • You will be looking for violations. • Use positive tests and negative tests. • Test boundaries . • Zero, One, Full. • Search an empty collection. • Add to a full collection. 10/11/2005 Lecture 6: Wel-behaved Objects 8

  9. Unit testing within BlueJ Unit testing within BlueJ • Objects of individual classes can be created. • Individual methods can be invoked. • Inspectors provide an up-to-date view of an object’s state. • Explore through the diary-prototype project. 10/11/2005 Lecture 6: Wel-behaved Objects 9

  10. Test automation Test automation • Good testing is a creative process, but ... • ... thorough testing is time consuming and repetitive. • Regression testing involves re-running tests. • Use of a test rig or test harness can relieve some of the burden. • Classes are written to perform the testing. • Creativity focused in creating these. 10/11/2005 Lecture 6: Wel-behaved Objects 10

  11. Test automation Test automation • Explore through the diary-testing project. • Human analysis of the results still required. • Explore fuller automation through the diary-test-automation project. • Intervention only required if a failure is reported. 10/11/2005 Lecture 6: Wel-behaved Objects 11

  12. Modularization and interfaces Modularization and interfaces • Applications often consist of different modules. • E.g. so that different teams can work on them. • The interface between modules must be clearly specified. • Supports independent concurrent development. • Increases the likelihood of successful integration. 10/11/2005 Lecture 6: Wel-behaved Objects 12

  13. Modularization in a calculator Modularization in a calculator • Each module does not need to know implementation details of the other. • User controls could be a GUI or a hardware device. • Logic could be hardware or software. 10/11/2005 Lecture 6: Wel-behaved Objects 13

  14. Method signatures as an Method signatures as an interface interface // Return the value to be displayed. public int getDisplayValue(); // Call when a digit button is pressed. public void numberPressed(int number); // Call when a plus operator is pressed. public void plus(); // Call when a minus operator is pressed. public void minus(); // Call to complete a calculation. public void equals(); // Call to reset the calculator. public void clear(); 10/11/2005 Lecture 6: Wel-behaved Objects 14

  15. Debugging Debugging • It is important to develop code-reading skills. • Debugging will often be performed on others’ code. • Techniques and tools exist to support the debugging process. • Explore through the calculator-engine project. 10/11/2005 Lecture 6: Wel-behaved Objects 15

  16. Manual walkthroughs Manual walkthroughs • Relatively underused. • A low-tech approach. • More powerful than appreciated. • Get away from the computer! • ‘Run’ a program by hand. • High-level (Step) or low-level (Step into) views. 10/11/2005 Lecture 6: Wel-behaved Objects 16

  17. Tabulating object state Tabulating object state • An object’s behavior is usually determined by its state. • Incorrect behavior is often the result of incorrect state. • Tabulate the values of all fields. • Document state changes after each method call. 10/11/2005 Lecture 6: Wel-behaved Objects 17

  18. Verbal walkthroughs Verbal walkthroughs • Explain to someone else what the code is doing. • They might spot the error. • The process of explaining might help you to spot it for yourself. • Group-based processes exist for conducting formal walkthroughs or inspections . 10/11/2005 Lecture 6: Wel-behaved Objects 18

  19. Print statements Print statements • The most popular technique. • No special tools required. • All programming languages support them. • Only effective if the right methods are documented. • Output may be voluminous! • Turning off and on requires forethought. 10/11/2005 Lecture 6: Wel-behaved Objects 19

  20. Debuggers Debuggers • Debuggers are both language- and environment-specific. • BlueJ has an integrated debugger. • Support breakpoints. • Step and Step-into controlled execution. • Call sequence (stack). • Object state. 10/11/2005 Lecture 6: Wel-behaved Objects 20

  21. Review Review • Errors are a fact of life in programs. • Good software engineering techniques can reduce their occurrence. • Testing and debugging skills are essential. • Make testing a habit. • Automate testing where possible. • Practise a range of debugging skills. 10/11/2005 Lecture 6: Wel-behaved Objects 21

  22. Designing classes Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable

  23. Main concepts to be covered Main concepts to be covered • Responsibility-driven design • Coupling • Cohesion • Refactoring • Static methods 10/11/2005 Lecture 6: Wel-behaved Objects 23

  24. Software changes Software changes • Software is not like a novel that is written once and then remains unchanged. • Software is extended, corrected, maintained, ported, adapted… • The work is done by different people over time (often decades). 10/11/2005 Lecture 6: Wel-behaved Objects 24

  25. Change or die Change or die • There are only two options for software: • Either it is continuously maintained • or it dies. • Software that cannot be maintained will be thrown away. 10/11/2005 Lecture 6: Wel-behaved Objects 25

  26. World of Zuul Zuul World of 10/11/2005 Lecture 6: Wel-behaved Objects 26

  27. Code quality Code quality Two important concepts for quality of code: • Coupling • Cohesion 10/11/2005 Lecture 6: Wel-behaved Objects 27

  28. Coupling Coupling • Coupling refers to links between separate units of a program. • If two classes depend closely on many details of each other, we say they are tightly coupled . • We aim for loose coupling . 10/11/2005 Lecture 6: Wel-behaved Objects 28

  29. Loose coupling Loose coupling Loose coupling makes it possible to: • understand one class without reading others; • change one class without affecting others. • Thus: improves maintainability. 10/11/2005 Lecture 6: Wel-behaved Objects 29

  30. Cohesion Cohesion • Cohesion refers to the the number and diversity of tasks that a single unit is responsible for. • If each unit is responsible for one single logical task, we say it has high cohesion . • Cohesion applies to classes and methods. • We aim for high cohesion. 10/11/2005 Lecture 6: Wel-behaved Objects 30

  31. High cohesion High cohesion High cohesion makes it easier to: • understand what a class or method does; • use descriptive names; • reuse classes or methods. 10/11/2005 Lecture 6: Wel-behaved Objects 31

  32. Cohesion of methods Cohesion of methods • A method should be responsible for one and only one well defined task. 10/11/2005 Lecture 6: Wel-behaved Objects 32

  33. Cohesion of classes Cohesion of classes • Classes should represent one single, well defined entity. 10/11/2005 Lecture 6: Wel-behaved Objects 33

  34. Code duplication Code duplication Code duplication • is an indicator of bad design, • makes maintenance harder, • can lead to introduction of errors during maintenance. 10/11/2005 Lecture 6: Wel-behaved Objects 34

Recommend


More recommend