CO3401 Advanced SE Techniques

1
CO3401Advanced SE Techniques

• Module Overview
• Key goals
• correctness
• needs specification
• performance
• responsiveness efficiency
• Test-driven development

2
Lecture Objectives

• You should be able to
• Summarise the module learning outcomes
• Say how the module is assessed
• Discuss program correctness
• Give examples of formal, semi-formal informal
  techniques
• Recognise features of a VDM specification
• Outline test-driven development (TDD)
• See similarities between VDM TDD

3
Administrative Information

• Teaching Staff
• Chris Casey (ccasey_at_uclan.ac.uk Preston)
• Andreas Schenk (schenk_at_spengergasse.at Vienna)
• Ewald Feilmair (e.feilmair_at_eduhi.at Leondig)
• Module Support (via WebCT)
• Web site
• Lecture notes
• Tutorial sheets
• Practical sheets
• Discussion group questions answers
• Revision Material Mind maps, quizzes

4
What is the module about?

• Developing correct systems
• Test-driven development
• Formal methods modelling behaviour
• Formal specification
• Formal design
• Developing efficient systems
• Modelling performance
• Writing responsive programs
• Concurrency
• Designing concurrent programs

5
Module Learning Outcomes

• You should be able to
• Develop interpret specifications in a formal
  notation.
• Evaluate critically the use of models (e.g.
  analytic models, simulations and finite-state
  machines) in the performance analysis of a
  system.
• Analyse concurrency problems in a range of
  applications (e.g. communications,
  multiple-access databases, operating systems)
• Evaluate critically tools and methods for
  real-time software development.
• Design and implement a small concurrent system in
  an appropriate language

6
Assessment

• Coursework 40
• Formal specification
• Implementation of concurrent program
• 3 hour examination 60
• Summer 06 paper a mock paper available
• Previous papers will be useful
• But the style is different
• Whats needed to pass?
• 40 average overall
• At least 35 in both exam and coursework

7
Correctness

• What is correctness?
• Doing what the user needs
• Doing what the specification says
• Striving for correctness
• Getting the specification right
• Formal/semi-formal techniques
• Prototyping
• Designing the program
• Formal/semi-formal techniques prototyping
• Finding and fixing problems
• Testing debugging

8
Development Approaches

• Formal, semi-formal, informal
• JML (Java Modelling Language)
• Formal notation closely integrated with Java
• Formal development process
• RUP (Rational Unified Process)
• Semi-formal development process
• TDD (Test-Driven Development)
• Informal approach used in Extreme Programming (XP)

• Well see JML in depth later in the module.
• TDD is simple and is covered quickly.
• (Perhaps thats a factor to be considered when
  evaluating approaches!)

9
Formal vs. Semi-formal

• Formal precisely defined
• Notation
• Mathematically defined syntax semantics
• Language meaning
• Method
• Using logic mathematical reasoning
• Semi-formal defined informally
• Notation
• Syntax often diagram-based
• Semantics defined in English
• Method
• Using informal reasoning

10
Formal Spec Hangman
Represent as a sequence
Represent as a set
11
JML Hangman
The state of the game

• abstract public class hangmaninterface
• public String target, current
• public int guesses
• public final int limit 10 // arms, legs,
  head, body, base, upright, cross bar, rope
• //_at_ invariant 0 lt guesses guesses lt
  limit
• /_at_ public normal_behavior
• _at_ requires guessesltlimit target.length
  gt 0 !current.equals(target)
• _at_ ensures current.equals(\old(content).repl
  ace('',c))
• _at_ ensures guesses 1\old(guesses)
• _at_ modifies current, guesses
• _at_ also
• _at_ public exceptional_behavior
• _at_ requires guesses limit
• _at_ modifies \nothing
• _at_ signals (Exception b) b.getMessage().equa
  ls("Game Over")
• /

A list of letters
Must be true if the routine is called
The routine must make this true
Value of guesses before the call
Action if pre-condition broken
12
VDM Hangman
A list of letters
The state of the game
Will be true if the routine is called
The routine must make this true
Value of b before the call
13
Semi-formal Methodology RUP

• Rational Unified Process
• Notation UML
• Use Case Diagrams
• Show services provided to users
• Class Diagrams
• Show data structures
• State Transition Diagrams
• Show responses to stimuli
• Development Process
• Iterative Lifecycle
• Architecture-based Design
• Role for diagrams

Are all methodologies semi-formal?
14
Why study Formal Methods?

• Formal methods
• Formal specification
• Formal development
• Formal methods
• Help us to think about programming
• Are used for safety-critical applications
• But
• Formal methods are difficult
• We will look at formal specification
• Formal design is interesting, but too complex
• Formal methods cant replace testing

15
Test-Driven Development

• What is test-driven development?
• Specify program by defining test cases
• Refine test cases to define client needs
• Develop test harness early
• Design program to meet tests
• Tests could be derived from a formal
  specification
• Constantly test developing program
• XP (Extreme Programming) technique
• A prototyping approach to programming
• Minimise documentation

16
JUnit

• Software support for Test-Driven Devt.
• Not essential but makes TDD easier
• Has useful classes reporting methods
• assertEquals(message, expected, actual)
• fail(failure message)
• Automatically generate skeleton tests
• Exercise all methods
• Developer extends to test behaviour
• Run all tests
• Displays failed tests information

17
Junit (in Eclipse)
Success test
Failed test
Test definitely failed
Success test extra message
Information on failure
18
Claimed TDD Benefits

• Improves productivity
• Developers are productive when fixing bugs
• Means more time fixing, not seeking, bugs
• Improves quality
• All non-trivial features are tested
• Code designed to be testable
• Good design through experiment
• Write tests first, test, write code to pass tests
• Use automated support for refactoring
• Alter classes, parameters, variables to better
  design

19
Formal Methods TDD

• Similarities
• Both define behaviour by specifying tests
• Formal Method specify condition for correct
  output
• TDD specify executable test cases
• Assume easier to specify a test than write code
• Differences
• Formal Specification
• Uses special language (e.g. JML) has to be
  learnt
• Post-condition defines behaviour for all inputs
• TDD
• Uses normal development language
• Only defines finite number of behaviours

20
Summary

• Thinking about programming
• Correctness efficiency
• Formal informal development
• Modelling systems
• Representing system behaviour
• Efficiency
• Formal Methods
• Concurrency
• Multiple simultaneous activities
• Problems
• Design