1Department of Computer Science, University of Sheffield
eXtreme Programming -
Practices
Dr. Marian Gheorghe
2Department of Computer Science, University of Sheffield
Plan
•Example
•Practices
•Conclusions
3Department of Computer Science, University of Sheffield
Example: Customer/order subsystem
Enter customer details (name, reference, address, phone, email); validate; edit
Enter orders by customer (customer reference, order reference, order details, delivery date, invoice reference); validate; edit
4Department of Computer Science, University of Sheffield
Story cards
1. Story name: Enter and validate customer details
Task description: enter customer details and validate (ref. unique, name alphanumeric, phone numeric, address non-empty); if valid record then store it otherwise re-enter it.
Initiating event: a request made through choosing a menu option
5
Story card cont’d
Memory context: customer records exist and will
be updated
Observable result: confirmation of success or
prompting an error otherwise
Related stories: Edit a customer details
Notes: Mandatory
Risk factor: 1(low) / Change factor: 1 (low)
Department of Computer Science, University of Sheffield
6
Department of Computer Science, University of Sheffield
Story card cont’d
Functional tests
Customer with a new reference, arbitrary data but alphanumeric name, non-empty address, numeric phone
Customer with an existing reference
Customer with either non-alphanumeric name or empty address or non-numeric phone
Customer with empty fields (name, reference etc)
7Department of Computer Science, University of Sheffield
More story cards:
2. Edit customer details (validation included)
3. Enter and validate orders by customer
4. Edit orders (validation included)
8Department of Computer Science, University of Sheffield
The twelve sacred tenets of XP
1. Test first programming
Functional test sets; from story cards
Unit test sets (white-box: branch/condition/statement coverage)
Non-functional requirements tested
9Department of Computer Science, University of Sheffield
To get used to testing continuously –
Run unit tests every time a new method/function has been created
Run functional testing every time a new class, or set of functions implementing a story card
10Department of Computer Science, University of Sheffield
2. Pair programming
Any work involving code is done in pairs: two people – one computer
11Department of Computer Science, University of Sheffield
3. On site customer: N/a
4. The planning game
Story cards + cost estimations (how long it takes, how many people involved)
Story cards discussed with the client
Test sets associated with will help to understand some tricky conditions/new aspects; ask the client
12Department of Computer Science, University of Sheffield
5. System metaphor
A read.me file with the file structure of the project + a short description of the components
An X-machine model of the system/subsystem
13
X-machine specification
Department of Computer Science, University of Sheffield
customer_proc
end_customer
pick_up_customer
end_customer
order_proc
end_order
exit
14Department of Computer Science, University of Sheffield
X-machine model
State based model (states in green); with an initial state
Transitions labeled by function names
The model may contain functions which themselves will become X-machines (blue ones)
Hierarchical model
15Department of Computer Science, University of SheffieldDepartment of Computer Science, University of Sheffield
customer_proc:
click_customer
edit_customer
search&display
change_customer
enter_customer enter_detail
validate_data
error
success
end_customer
16
Function component
Takes an input (click a button, enter some data) and a memory value then produces an output and updates the memory side.
Formally:
func_comp:: Input x Memory -> Output x Memory
Department of Computer Science, University of Sheffield
17Department of Computer Science, University of Sheffield
Function components (examples)
click_customer::
customer_btn x λ -> λ x customer_sel
enter_customer::
enter_btn x customer_sel -> λ x customer_sel
enter_detail::
data x customer_sel -> data_echoed x data
where data =(name, reference,address,phone,email)
18Department of Computer Science, University of Sheffield
6. Small, frequent releases
Releases are not prototypes
A release implement a couple of stories
A release is thoroughly tested
Releases are related to
19Department of Computer Science, University of Sheffield
7. Continuous integration
Write small units and test them (unit testing)
Integrate into the system and test it functionally (test first programming)
Suggestion: one pair be responsible for integrating components into an operational system
20Department of Computer Science, University of Sheffield
8. Keep your code as SIMPLE as possible
If it’s not so simple then…
21Department of Computer Science, University of Sheffield
9. Refactoring
Restructuring the code without changing its functionality
Its main use is to simplify the code (Fowler)
-moving methods used in several classes in a new one
-renaming classes, methods, functions
-simplify conditional expressions; reorganise data
22Department of Computer Science, University of Sheffield
Refactoring (cont’d)
Refactoring the test sets accordingly
Changes into code require test sets changes as source code and test sets are the two main deliverables
23Department of Computer Science, University of Sheffield
10. Code standardsShould follow consistent class/method naming conventionsStudy coding standards before starting programming; decide upon a set of rules; show it to your manager
Similar conventions should apply for test sets, story cards, metaphor
24Department of Computer Science, University of Sheffield
11. Collective code ownership
Coding standards help in using the same programming style
Changes might be done by everyone in the team
Suggestion: keep commenting your code with name, date and what has been changed; provide a change notification form
Changes in the documents/story cards will be reflected only in notification forms and CVS variants.
25Department of Computer Science, University of Sheffield
12. 48 hours/week =>
avg of 15hours/week
Use your time adequately
26Department of Computer Science, University of Sheffield
Java coding standards(p.131-)
Each directory containing java files will contain a README file describing briefly these files
Each java source file will contain a single public class or interface
-beginning comment: class name, author, date, version, changes description, changes history
-a specified class structure
27Department of Computer Science, University of Sheffield
Java coding standards(cont’d)
Each method should have a comment associated with
Block comments vs single line comments
One declaration per line + comment
One stmt per line (simplicity)
Layout for class decl, if, for, while, switch, try stmts
28Department of Computer Science, University of Sheffield
Coding standards
Decide which standards you apply
Apply them consistently (you’ll be marked on this basis!)
The standards are there to help you produce simpler and easier to understand code
29Department of Computer Science, University of Sheffield
References
K. Beck, “Extreme programming explained.” Addison-Wesley, 1999
K. Beck & M. Fowler, “Planning extreme programming.” Addison-Wesley, 2000
M. Holcombe, “Extreme programming for real: a disciplined, agile,approach to software engineering”, 2003
M. Holcombe & F. Ipate, “Correct systems: building a business process solution”, Springer, 1998.
30Department of Computer Science, University of Sheffield
Summary
Are the 12 XP practices all applicable to SH projects?
Simplify/apply partially some of them
Enforce others
Strengthen the testing side
Top Related