1 Department of Computer Science, University of Sheffield eXtreme Programming - Practices Dr. Marian...

1Department of Computer Science, University of Sheffield

eXtreme Programming -

Practices

Dr. Marian Gheorghe


Plan

•Example

•Practices

•Conclusions


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


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


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)


More story cards:

2. Edit customer details (validation included)

3. Enter and validate orders by customer

4. Edit orders (validation included)


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


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


2. Pair programming

Any work involving code is done in pairs: two people – one computer


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


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


customer_proc

end_customer

pick_up_customer

end_customer

order_proc

end_order

exit


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



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)


6. Small, frequent releases

Releases are not prototypes

A release implement a couple of stories

A release is thoroughly tested

Releases are related to


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


8. Keep your code as SIMPLE as possible

If it’s not so simple then…


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


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


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


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.


12. 48 hours/week =>

avg of 15hours/week

Use your time adequately


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


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


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


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.


Summary

Are the 12 XP practices all applicable to SH projects?

Simplify/apply partially some of them

Enforce others

Strengthen the testing side

1 Department of Computer Science, University of Sheffield eXtreme Programming - Practices Dr. Marian...

Documents

Transcript of 1 Department of Computer Science, University of Sheffield eXtreme Programming - Practices Dr. Marian...