Title: RoadMap for Unit Implementation
1RoadMap 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.
3USDP 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.
4USDP 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.
5Implement 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.
6Implement 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.
7Applications 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.
8Think 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.
9Exceptions 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
10Exceptions 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
11God løsning
- public String trimWithErrorHandling(String s)
- if (s null)
- return ""
- return s.trim()
-
12Dårlig løsning
- public String trimThrowsException(String s)
throws java.lang.NullPointerException -
- return s.trim()
-
13Implement 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.
14Names 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.
15Names 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.
16Names, 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.
17Documenting 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.
18Documenting 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.
19Initializing 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.
20Inspect 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.
21Inspect 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.
22Inspect 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.
23Inspect 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.
24Personal 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.