Title: ICS 52: Introduction to Software Engineering
1ICS 52 Introduction to Software Engineering
- Lecture Notes for Summer Quarter, 2003
- Michele Rousseau
- Topic 10
- Partially based on lecture notes written by
Sommerville, Frost, Van Der Hoek, Taylor
Tonne. Duplication of course material for any
commercial purpose without the written permission
of the lecturers is prohibited
2Todays Lecture
- Integration Testing - continued
- Implementation
3Integration testing
- Tests complete systems or subsystems composed of
integrated components - Integration testing should be black-box testing
with tests derived from the specification - Main difficulty is localising errors
- Incremental integration testing reduces this
problem
4Incremental integration testing
5In Reality
- New features may span several components
- A new component can change the pattern of
previously tested component interactions. - New Errors may be revealed
6Testing approaches
- Architectural validation
- Top-down integration testing is better at
discovering errors in the system architecture - System demonstration
- Top-down integration testing allows a limited
demonstration at an early stage in the
development - Test implementation
- Often easier with bottom-up integration testing
- Test observation
- Problems with both approaches. Extra code may be
required to observe tests
7Top-down testing
- How do these apply?
- Architectural Validation
- System Demonstration
- Testing implementation
- Test observation
8Bottom-up testing
- How do these apply?
- Architectural Validation
- System Demonstration
- Testing implementation
- Test observation
9Which Approach to use?
- Top-Down or Bottom Up?
- In practice, most integration involves a
combination of these strategies
10Interface testing
- Takes place when modules or sub-systems are
integrated to create larger systems - Objectives
- detect faults due to interface errors or invalid
assumptions about interfaces - Particularly important for object-oriented
development as objects are defined by their
interfaces
11Object Models
method invocation
method invocation
object
object
object
object
method invocation
object
method invocation
12Interface testing
13Interfaces types
- Parameter interfaces
- Data passed from one procedure to another
- Shared memory interfaces
- Block of memory is shared between procedures
- Remember uses relationships
- Procedural interfaces
- Sub-system encapsulates a set of procedures to be
called by other sub-systems - OO systems
- Message passing interfaces
- Sub-systems request services from other
sub-systems - OO systems, client-server broadcast models..
14Interface Errors
- Interface misuse
- A calling component calls another component and
makes an error in its use of its interface - e.g. parameters in the wrong order
- Interface misunderstanding
- A calling component embeds assumptions about the
behaviour of the called component which are
incorrect - e.g. binary search is data sorted?
15Interface Errors (2)
- Timing errors
- The called and the calling component operate at
different speeds and out-of-date information is
accessed - Real time systems
16Some problems with Interfaces
- Interface faults may only manifest themselves in
unusual situation - e.g. Queue of static length
- Interactions between faults in different modules
may go unnoticed until later
17Interface testing guidelines
- Test Boundary Conditions
- Design tests so that parameters to a called
procedure are at the extreme ends of their ranges - Always test pointer parameters with null pointers
- Try to force a failure
- Use stress testing in message passing systems
(pass more then expected) - In shared memory systems, vary the order in which
components are activated
18Stress testing
- After the system is completely integrated
- Exercises the system beyond its maximum design
load. - Stressing the system test failure behaviour.
- Systems should not fail catastrophically.
- Checks for unacceptable loss of service or data
(want it to fail soft not collapse) - Particularly relevant to distributed systems
- can exhibit severe degradation as a network
becomes overloaded
19Implementation
20A Good Design
- is half the implementation effort!
- Rigor ensures all requirements are addressed
- Separation of concerns
- Modularity allows work in isolation because
components are independent of each other - Abstraction allows work in isolation because
interfaces guarantee that components will work
together - Anticipation of change allows changes to be
absorbed seamlessly - Generality allows components to be reused
throughout the system - Incrementality allows the software to be
developed with intermediate working results
21A Bad Design
- will never be implemented!
- Lack of rigor leads to missing functionality
- Separation of concerns
- Lack of modularity leads to conflicts among
developers - Lack of abstraction leads to massive integration
problems (and headaches) - Lack of anticipation of change leads to redesigns
and reimplementations - Lack of generality leads to code bloat
- Lack of incrementality leads to a big-bang
approach that is likely to bomb
22ICS 52 Life Cycle
Requirements phase
Verify
Implementation phase
Test
23Design/Implementation Interaction
Design (previous lectures)
Implementation (this lecture)
24From Design to Implementation
- Choose a suitable implementation language
- Establish coding conventions
- Divide work effort
- Implement
- Code
- Unit tests
- Code reviews
- Inspections
- Perform integration tests
25Choose a Suitable Language
- 1st Generation
- Machine Language Since the 40s
- 2nd Generation Low Level Early 50s
- Assembly
- Machine specific
26Choose a Suitable Language (2)
- 3rd Generation High Level languages - Mid 50s
- Procedural Languages
- Java Class Libraries
- C/C STL (Standard Template Library)
- Cobol
- Fortran
- 4th Generation language Late 70s
- Databases - SQL
- Visual Basic - Spreadsheets
27Choose a Suitable Language
- Maintain the design picture
- Mapping of design elements onto implementation
- Module inside versus outside
- Does the language enforce a boundary?
- Interfaces!
- Explicit representation of uses relationship
- Just function calls?
- Error handling
- Return values
- Exceptions
28Establish Coding Conventions
- include ltstdio.hgt int lint main(int o,char
O, int I)char c,DO1if(ogt0) for(l0Dl
Dl -10)D l-120Dl- 110while
(!main(0,O,l))Dl 20 putchar((Dl1032) /20
) putchar(10)else co (DI82)10-(Igtl/2)
(DI-lI72)/10-9DIIlt0?0 !(omain(c/10,O,I-
1))((c999 )10-(DI92)10)return o
www.ioccc.org
29Establish Coding Conventions
- Naming
- Avoid confusing characters
- 1, l, L, o, O, 0, S, 5, G, 6
- Avoid misleading names
- Avoid names with similar meaning
- Use capitalization wisely
- Code layout
- White space / blank lines
- Grouping
- Alignment
- Indentation
- Parentheses
30Suggested coding style rules (1)
- Align all curly braces vertically to allow easy
visual matching. - Use four (4) spaces for each indentation.
- Indent all statements contained within compound
statements (if, for, while, , etc). - Use meaningful names for variables, parameters,
subprograms, and classes. (You may use simple
names like i, c, s, or f for general integers,
characters, strings or floats respectively.)
31Suggested coding style rules (2)
- Use the following conventions for identifiers
            Â
Identifier Convention Examples
class names capitalize each word Circle, FilledCircle
class member names and methods lowercase first word, capitalize all other words (no underscores) draw(), drawLine(), centerX, centerY, radius
named constants all caps, use underscores to separate words PI, MAX_BUFFER_SIZE
32Suggested coding style rules (3)
- Use white space around every binary operator
- (e.g, x y instead of xy)
- and around function arguments
- (e.g, put( x, y ) instead of put(x,y)).
- Keep subprograms simple.
- Keep compound statements simple. At most three
simple statements per statement list.
33Suggested coding style rules (4)
- Avoid over parenthesization, e.g, return x 1
instead of return (x 1) - Comment each function, each class, and each class
member (describing it's purpose).
34Divide Work Effort
- Assign different modules to different developers
- Assignments can be incremental
- Assignments change
- Illness
- New employees
- Employees who quit
- Schedule adjustments
- Star programmers
- Interfaces are tremendously important
- Contracts among modules
35Coding
- FIRST MAKE IT WORK CLEANLY
36Coding
- FIRST MAKE IT WORK CLEANLY
37Code Optimizations
- Only make optimizations to a cleanly working
module if absolutely necessary - Performance
- Memory usage
- Isolate these optimizations
- Document these optimizations
Empirical evidence has proven that these
optimizationsare rarely needed and that if they
are needed, they areonly needed in a few
critical places
38Defensive Programming
- Make your code robust and reliable
- Use assertions
- Use tracing
- Handle, do not ignore, exceptions
- Contain the damage caused
- Garbage in does not mean garbage out
- Anticipate changes
- Check return values
- Plan to be able to remove debugging aids in the
final, deliverable version
Do not sacrifice any of these when facing a
deadline
39Comments
- Self documenting code does not exist!
- Meaningful variable names, crisp code layout, and
small and simple modules all help - but they are not enough
- Every module needs a description of its purpose
- Every function needs a description of its
purpose, input and output parameters, return
values, and exceptions - Every piece of code that remotely may need
explanation should be explained
40V-Model of Development and Testing
41Unit Tests
- Developer tests the code just produced
- Needs to ensure that the code functions properly
before releasing it to the other developers - Benefits
- Knows the code best
- Has easy access to the code
- Drawbacks
- Bias
- I trust my code
- I always write correct code
- Blind spots
42Code Reviews (Walk-throughs)
- Developer presents the code to a small group of
colleagues - Developer describes software
- Developer describes how it works
- Walks through the code
- Free-form commentary/questioning by colleagues
- Benefits
- Many eyes, many minds
- Effective
- Drawbacks
- Can lead to problems between developer and
colleagues
43Your Tasks
- Read and study slides of this lecture
- Read and study Chapters 19 and 20 of Sommerville