Hand Back Papers

1
Hand Back Papers

• Lab 4 It was a long lab, so you got points for
  nearing completion. However, if you were nowhere
  near done that cost you.
• Quiz Twenty questions / 10 points.
• PA1 25 points. We will talk a BIT more about
  this later in the period.

2
Introduction

• A program must be well designed, thoroughly
  documented, and carefully tested
• A good design is essential to solving any complex
  problem
• Well-designed and well-written code is, to a
  certain extent, self-documenting
• No matter how carefully you design and document a
  program, you need to test it with equal care

3
Software Design with UML

• Programmers use various graphical notations to
  represent analysis and design decisions
• UML Unified Modeling Language
• Dominant graphical scheme currently used in
  object-oriented software development
• An excellent and free UML authoring tool is
  available at http//argouml.tigris.org/

4
UML and Modeling

• UML diagrams come in handy during the initial
  phases of software development
• Help programmer visualize, or model, the
  interactions of human users with proposed system,
  relationships among its classes, and interactions
  among its objects
• UML includes diagrams for almost any occasion
• For example
• Class diagrams
• Use case diagrams
• Collaboration diagrams

5
Use Case Diagrams

• A use case is a narrative, in English, of the
  steps a user takes to perform a single action

6
Use Case Diagrams (continued)

• Use cases should include narratives of
  exceptional conditions and corresponding
  responses

7
Use Case Diagrams (continued)

• Use case diagrams in UML translate narratives of
  use cases into a pictorial representation

8
Use Case Diagrams (continued)

• Use cases and use case diagrams enable the
  programmer to accomplish several things
• Result in a precise statement of the functional
  requirements of the software system, in other
  words, the what it does, from the users
  perspective
• Serve as the basis for writing user
  documentation, in the form of manuals and online
  help systems for the software
• Allow the programmer to determine which classes
  need to be chosen or developed to realize the
  requirements of the system

9
Class Diagrams

• During the discovery of classes for a system,
  their relationships can be modeled with class
  diagrams
• The simplest such diagrams show a relationship of
  association between two classes

10
Class Diagrams (continued)

• Associations do not tell us how classes are
  related
• Programmer can also specify a role that a class
  plays in relation to another

11
Class Diagrams (continued)
12
Class Diagrams (continued)
13
Collaboration Diagrams

• The attributes and operations of a given class
  are often designed to fit into a sequence of
  operations that perform a particular task
• The actors in these scenarios are software
  objects or instances of the systems classes
• A system function or task is broken down into a
  set of method calls on objects, and coordinating
  these becomes the focus of design
• The interactions among objects can be documented
  in a collaboration diagram

14
Collaboration Diagrams (continued)
15
From Collaboration Diagram to Code
16
From Collaboration Diagram to Code (continued)
17
Documentation

• In this section, we examine ways to make
  documentation more systematic and informative
• You will also learn about a tool, pydoc, which
  you can use to generate documentation that can be
  viewed with a Web browser

18
Writing APIs (continued)

• What information should an API include?
• Module its filename, a brief statement of its
  purpose, a summary of the resources that it
  includes
• Class name of class and superclass, a brief
  statement of its purpose
• Might also include a short list of the operations
  available to the client (the classs interface)
• Method its header, a brief statement of what it
  does (not how it does it), the types of arguments
  it expects, and the type of value it returns
• Function same information included for a method

19
Revisiting the Student Class
20
Revisiting the Student Class (continued)
21
Revisiting the Student Class (continued)

• Most of the methods in the Student class are
  accessors
• Accessors are generally the easiest to document,
  especially those that expect no arguments
• A simple statement about the type and meaning of
  the value returned by the method usually suffices
• setScore is the only mutator method
• getScore and setScore call for further attention
• What happens if the reader misses the fact that
  the positions of the scores are counted from 1,
  not 0?

22
Preconditions and Postconditions

• Precondition Statement of what must be true
  before a method is invoked if it is to run
  correctly
• Usually describe the state of any parameters and
  instance variables that a method is about to
  access
• Example

23
Preconditions and Postconditions (continued)

• Postcondition Statement of what will be true
  after the method has finished execution
• Describe the state of parameters and instance
  variables that the method has changed
• Example

24
Testing

• A great deal of time, effort, and money is spent
  trying to prevent software errors from ever
  happening
• In this section, we examine testing, the
  discipline that searches for program errors and
  builds confidence that software works correctly

25
What to Test

• There are several features of a programs
  behavior that we might want to consider
• Is the program user friendly?
• Is the program robust?
• Is the program reliable?
• Does the program provide acceptable performance?
• In this section we confine our attention to a
  more minimal sense of program correctness
• A correct program produces the expected outputs
  when operating on inputs that fall within
  specified limits

26
Three Approaches to Choosing Test Data

• Haphazard Bang on the program with a few inputs
  until it breaks, fix bugs, and call it correct
• Not very effective
• Black-box Partition inputs in clusters of
  equivalent data (if program works correctly on a
  set of values from a cluster, it works well for
  all values in cluster)
• Also test for values on boundaries between
  clusters
• Easy to overlook some clusters
• Number of clusters can be so large that we cannot
  possibly consider them all

27
Three Approaches to Choosing Test Data (continued)

• White-box Attempt to concoct test data that
  exercise all parts of our program
• You examine the code closely and then formulate
  the test data, but the task can be difficult
• Code coverage
• Tip Combine black-box testing with white-box
  testing

28
When to Test

• Four points during coding at which test data can
  be used
• Unit testing Write code that instantiates an
  object of the desired type and then run a series
  of methods that subject it to a thorough workout
• Integration testing After classes have been
  tested in isolation, confirm that they work
  together properly
• Acceptance testing Test under conditions
  identical to those in which it will eventually be
  used
• Regression testing Keep test data for later use
  (e.g., to test modifications to program)

29
Proofs of Program Correctness

• Testing cannot actually demonstrate the programs
  correctness
• We can prove that a program is correct in a
  strictly mathematical sense
• Quite tedious
• May lead to invalid proofs if not enough
  mathematical background
• Can we automate the process of determining
  program correctness?
• It is impossible, not just difficult, to write a
  program that can solve the halting problem

30
Unit Testing in Python

• Kent Beck developed one of the first tools for
  the unit testing of classes (for Smalltalk)
• Beck and Erich Gamma wrote junit and pyunit
• A unit test consists of a set of test cases for a
  given class
• Each test case is a method that runs tests on an
  individual method in the class
• The tests take the form of assertions
• A test suite can be run whenever a change is made
  to the class under development

31
Unit Testing in Python (continued)
32
Unit Testing in Python (continued)
33
Unit Testing in Python (continued)
34
Unit Testing in Python (continued)
35
Unit Testing in Python (continued)
36
Unit Testing in Python (continued)

• The TestCase class includes a significant number
  of methods that you can use to make assertions
  about your code

37
Unit Testing in Python (continued)

• Although unit tests are ideal for testing
  individual classes, to a certain extent they can
  also be used during integration testing
• By developing and running a good unit test for
  each class, programmer can focus on writing code
  and leave the testing to an automated assistant
• Test-driven development encourages detection of
  errors early in the coding process and increases
  the likelihood of thorough white-box testing

38
Testing of PA1

• Demo of UnitTesting
• Issues to address
• Read specification and follow it (Patron OBJECT
  not name)
• Ask if you dont understand
• Think about the complete action(s) needed
  (returnMe())
• Why say
• if checkOut()True
• When its equivalent to say
• if checkOut()

39
Summary

• UML is the leading graphical notation for
  depicting the structure and behavior of OO
  software systems
• A use case describes the steps performed during
  an single interaction of a user with a SW system
• A class diagram shows the relationships among the
  classes of a software system
• A collaboration diagram shows interactions among
  objects required to complete a task in a SW
  system
• Preconditions and postconditions form the subject
  of an agreement between the author of a method
  and its client

40
Summary (continued)

• You can enforce a precondition by raising an
  exception if that precondition is not satisfied
• Complete documentation of a method includes
  information about any preconditions,
  postconditions, and exceptions that it might
  raise
• Generate Web-based documentation for a Python
  resource by running the pydoc tool
• Black-box testing Programmer selects test data
  that produce expected results for normal inputs
  and abnormal inputs

41
Summary (continued)

• White-box testing Select test data that exercise
  all of the possible execution paths in a given
  resource
• Unit test Subjects a class to a thorough workout
• Pyunit provides a tool for automating unit tests
• Integration testing examines the behavior of
  cooperating classes that have been unit tested
• Acceptance testing subjects a software system to
  examination under realistic conditions
• Regression testing is performed when any part of
  a software system is repaired or extended