RoadMap for Unit Implementation - PowerPoint PPT Presentation

1 / 24
About This Presentation
Title:

RoadMap for Unit Implementation

Description:

1. Confirm the detailed designs you must implement ... of knowing the types of names exceeds the awkwardness of strange-looking names. ... – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0
Slides: 25
Provided by: bost99
Category:

less

Transcript and Presenter's Notes

Title: RoadMap for Unit Implementation


1
RoadMap for Unit Implementation
1. Define coding standards
Architecture
For each ... framework package
...application package
For each class
Requirements
5. Release for inte- gration -- see chpt. 9
2. Implement methods -- see section tbd
Detailed design - pseudocode? - flowcharts?
4. Perform unit testing -- see chpt. 8
3. Inspect class -- see section tbd
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
2
  • 1. Confirm the detailed designs you must
    implement
  • code only from a written design (part of the SDD)
  • 2. Prepare to measure time spent, classified by
  • residual detailed design detailed design review
    coding coding review compiling repairing
    syntax defects unit testing (see chapter 7)
    repairing defects found in testing
  • 3. Prepare to record defects using a form
  • default major (requ. unsatisfied), trivial, or
    neither
  • default error, naming, environment, system,
    data, other
  • 4. Understand required standards
  • for coding
  • for the personal documentation you must keep
  • see the case study for an example
  • 5. Estimate size and time based on your past
    data
  • 6. Plan the work in segments of 100 LOC

Prepare forImplementation
One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
3
USDP Subsystem Interfaces
Implementation subsystem
Denotes interface to the subsystem
file EncounterCast.java
Indicates that EncounterCast handles the
packages inteface
Denotes interface to the class
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
4
USDP Implementation Model Constituents
Design model
Implementation model
file impl.jar
compress
AnotherClass
Implementation subsystem
trace
Area
file Area.java
file readme.txt
Same nominal interface provided by design class
and implementation component
compilation
explain
file Area.class
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5
Implement Code 1/2
One way to ...
  • 1. Plan the structure and residual design for
    your code
  • (complete missing detailed design, if any)
  • note pre- and post-conditions
  • note the time spent
  • 2. Self-inspect your design and/or structure
  • note time spent, defect type, source (phase),
    severity
  • 3. Type your code
  • do not compile yet
  • try methods listed below
  • apply required standards
  • code in a manner that is easiest to verify
  • use formal methods if appropriate

See the code inspection checklist (figure tbd in
section 6) for details commonly required for
method class construction.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
Implement Code 2/2
One way to ...
  • 4. Self-inspect your code -- do not compile yet
  • convince yourself that your code does the
    required job
  • the compiler will never do this for you it
    merely checks syntax!
  • note time spent, defects found, type, source,
    severity
  • 5. Compile your code
  • repair syntax defects
  • note time spent, defect type, source, severity ,
    and LOC.
  • 6. Test your code
  • apply unit test methods in chapter 7
  • note time spent, defects found, type, source,
    severity

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
Applications of Enforce Intentions
  • If a member is not intended to be used by other
    functions, enforce this by making it private or
    protected etc.
  • Use qualifiers such as final and abstract etc. to
    enforce intentions

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
8
Think Globally, Program Locally
  • Make all members ...
  • as local as possible
  • as invisible as possible
  • attributes private
  • access them through more public accessor
    functions if required.
  • (Making attributes protected gives objects of
    subclasses access to members of their base
    classes -- not usually what you want)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
Exceptions 1
  • Catch only those exceptions that you know how to
    handle
  • or handle part throw
  • outer scope can do so, e.g.,
  • myMethod() throws XYZException
  • ...
  • calledFunction() // throws XYZException
  • Be reasonable about exceptions callers must handle

After Horstmann
10
Exceptions 2 (Hortsmann)
  • Dont substitute the use of exceptions for issue
    that should be the subject of testing
  • e.g. null parameters (most of the time)
  • Consider providing
  • a version throwing exceptions, and
  • a version which does not (different name)
  • accompanied by corresponding test functions.
  • e.g., pop empty stack

11
God løsning
  • public String trimWithErrorHandling(String s)
  •         if (s null)
  •             return ""
  •         return s.trim()

12
Dårlig løsning
  • public String trimThrowsException(String s)
    throws java.lang.NullPointerException
  •         return s.trim()
  •    

13
Implement Error Handling
One way to ...
  • 1. Follow agreed-upon development process
    inspect
  • 2. Consider introducing classes to encapsulate
    legal parameter values
  • private constructor factory functions to create
    instances
  • catches many errors at compile-time
  • 3. Where error handling is specified by
    requirements, implement as required
  • use exceptions if passing on error handling
    responsibility
  • 4. For applications that must never crash,
    anticipate all possible implementation defects
    (e.g., use defaults)
  • only if unknown performance better than none
    (unusual!)
  • 5. Otherwise, follow a consistent policy for
    checking parameters
  • rely mostly on good design and development
    process

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Names 1
  • Use concatenated words
  • e.g., cylinderLength
  • Begin class names with capitals
  • Variable names begin lower case
  • Constants with capitals
  • as in MAX_NAME_LENGTH
  • use static final
  • -- but consider method instead

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Names 2
  • Data members of classes with an underscore
  • as in _timeOfDay
  • or equivalent
  • to distinguish them from other variables
  • since they are global to their object
  • Use get, set., and is for accessor methods
  • as in getName(), setName(), isBox()
  • latter returns boolean
  • additional getters and setters of collections
  • e.g., insertIntoName(), removeFromName().

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
Names, ctd.
  • Consider preceding with standard letters or
    combinations of letters
  • e.g., C.. for classes
  • as in CCustomer etc.
  • useful when the importance of knowing the types
    of names exceeds the awkwardness of
    strange-looking names.
  • or place these type descriptors at the end
  • And/or distinguish between instance variables,
    local variables and parameters
  • _length, length and aLength

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
17
Documenting Methods 1
  • what the method does
  • why it does so
  • what parameters it must be passed (use _at_param
    tag)
  • exceptions it throws (use _at_exception tag)
  • reason for choice of visibility
  • known bugs

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
Documenting Methods 2
  • test description, describing whether the method
    has been tested, and the location of its test
    script
  • history of changes if you are not using a CM
    system
  • example of how the method works
  • pre- and postconditions
  • special documentation on threaded and
    synchronized methods

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
19
Initializing Attributes
Attributes should be always be initialized, think
of private float _balance 0 Attribute may be
an object of another class, as in private
Customer _customer -- Traditionally done using
the constructor, as in private Customer
_customer new Customer( "Edward", "Jones"
) Problem is maintainability. When new
attributes added to Customer, all have to be
updated. Also accessing persistent storage
unnecessarily.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
20
Inspect Code 1 of 5 Classes Overall
One way to ...
  • C1. Is its (the class) name appropriate?
  • consistent with the requirements and/or the
    design?
  • sufficiently specialized / general?
  • C2. Could it be abstract (to be used only as a
    base)?
  • C3. Does its header describe its purpose?
  • C4. Does its header reference the requirements
    and/or design element to which it corresponds?
  • C5. Does it state the package to which it
    belongs?
  • C6. Is it as private as it can be?
  • C7. Should it be final (Java)
  • C8. Have the documentation standards been
    applied?
  • e.g., Javadoc

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
21
Inspect Code 2 of 5 Attributes
  • A1. Is it (the attribute) necessary?
  • A2. Could it be static?
  • Does every instance really need its
    own variable?
  • A3. Should it be final?
  • Does its value really change?
  • Would a getter method alone be preferable (see
    section tbd)
  • A4. Are the naming conventions properly applied?
  • A5. Is it as private as possible?
  • A6. Are the attributes as independent as
    possible?
  • A7. Is there a comprehensive initialization
    strategy?
  • at declaration-time?
  • with constructor(s)?
  • using static?
  • Mix the above? How?

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
22
Inspect Code 4 of 5 Method Headers
  • MH1. Is the method appropriately named?
  • method name consistent with requirements /or
    design?
  • MH2. Is it as private as possible?
  • MH3. Could it be static?
  • MH4. Should it be be final?
  • MH5. Does the header describe methods purpose?
  • MH6. Does the method header reference the
    requirements and/or design section that it
    satisfies?
  • MH7. Does it state all necessary invariants?
    (section tbd)
  • MH8. Does it state all pre-conditions?
  • MH9. Does it state all post-conditions?
  • MH10.Does it apply documentation standards?
  • MH11.Are the parameter types restricted? (see
    section tbd)

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
23
Inspect Code 5 of 5 Method Bodies
  • MB1. Is the algorithm consistent with the
    detailed design pseudocode and/or flowchart?
  • MB2. Does the code assume no more than the
    stated preconditions?
  • MB3. Does the code produce
    every one of the postconditions?
  • MB4. Does the code respect the required
    invariant?
  • MB5. Does every loop terminate?
  • MB6. Are required notational standards
    observed?
  • MB7. Has every line been thoroughly checked?
  • MB8. Are all braces balanced?
  • MB9. Are illegal parameters considered? (see
    section tbd)
  • MB10. Does the code return the correct type?
  • MB11. Is the code thoroughly commented?

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
24
Personal Software Documentation
  • Source code
  • Personal defect log
  • defects types
  • personal phase during which they were injected
  • personal phase during which they were removed.
  • The personal phases are
  • 1. Additional detailed design (if applicable)
  • 2. Code (record defects injected and/or detected
    -- and repaired -- in source code detected before
    submission to the compiler)
  • 3. Compile (record defects detected and repaired
    upon attempted compilation)
  • 4. Unit test
  • Some unit testing could be performed by QA,
    which would not be part of this documentation
  • Time log
  • time spent on additional detailed design, coding,
    compiling, testing
  • Engineering notebook
  • includes status of additional detailed design (if
    applicable) and code,
  • incidents, noteworthy development issues

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Write a Comment
User Comments (0)
About PowerShow.com