ICS 52: Introduction to Software Engineering

1
ICS 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

2
Todays Lecture

• Integration Testing - continued
• Implementation

3
Integration 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

4
Incremental integration testing
5
In Reality

• New features may span several components
• A new component can change the pattern of
  previously tested component interactions.
• New Errors may be revealed

6
Testing 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

7
Top-down testing

• How do these apply?
• Architectural Validation
• System Demonstration
• Testing implementation
• Test observation

8
Bottom-up testing

• How do these apply?
• Architectural Validation
• System Demonstration
• Testing implementation
• Test observation

9
Which Approach to use?

• Top-Down or Bottom Up?
• In practice, most integration involves a
  combination of these strategies

10
Interface 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

11
Object Models
method invocation
method invocation
object
object
object
object
method invocation
object
method invocation
12
Interface testing
13
Interfaces 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..

14
Interface 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?

15
Interface Errors (2)

• Timing errors
• The called and the calling component operate at
  different speeds and out-of-date information is
  accessed
• Real time systems

16
Some 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

17
Interface 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

18
Stress 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

19
Implementation
20
A 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

21
A 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

22
ICS 52 Life Cycle
Requirements phase
Verify
Implementation phase
Test
23
Design/Implementation Interaction
Design (previous lectures)
Implementation (this lecture)
24
From Design to Implementation

• Choose a suitable implementation language
• Establish coding conventions
• Divide work effort
• Implement
• Code
• Unit tests
• Code reviews
• Inspections
• Perform integration tests

25
Choose a Suitable Language

• 1st Generation
• Machine Language Since the 40s
• 2nd Generation Low Level Early 50s
• Assembly
• Machine specific

26
Choose 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

27
Choose 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

28
Establish 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
29
Establish 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

30
Suggested 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.)

31
Suggested 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
32
Suggested 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.

33
Suggested 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).

34
Divide 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

35
Coding

• FIRST MAKE IT WORK CLEANLY

36
Coding

• FIRST MAKE IT WORK CLEANLY

37
Code 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
38
Defensive 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
39
Comments

• 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

40
V-Model of Development and Testing
41
Unit 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

42
Code 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

43
Your Tasks

1. Read and study slides of this lecture
2. Read and study Chapters 19 and 20 of Sommerville