Extreme Programming - Practices: Dr. Marian Gheorghe

eXtreme Programming Practices Dr.
Marian Gheorghe
Department of Computer Science, University of Sheffield
Example Practices Conclusions
Pla n
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
Story card contd 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)
Story card contd 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
X-machine specification
customer_proc
end_custome r pick_up_customer order_proc exit end_custome r end_order
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
customer_proc:
search&display edit_custome r change_custome click_customer r enter_customer enter_detail end_customer success error validate_data
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 its 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 (contd)
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 standards

Should follow consistent class/method naming conventions Study 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(contd)

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 (youll 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. AddisonWesley, 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

Extreme Programming - Practices: Dr. Marian Gheorghe

Uploaded by

Copyright:

Available Formats

Extreme Programming - Practices: Dr. Marian Gheorghe

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Extreme Programming - Practices: Dr. Marian Gheorghe

Uploaded by

Copyright:

Available Formats

eXtreme Programming Practices Dr.

Department of Computer Science, University of Sheffield

Example Practices Conclusions

Department of Computer Science, University of Sheffield

Example: Customer/order subsystem

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Story card contd Functional tests

Department of Computer Science, University of Sheffield

More story cards:

Department of Computer Science, University of Sheffield

The twelve sacred tenets of XP 1.Test first programming

Department of Computer Science, University of Sheffield

To get used to testing continuously

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

3. On site customer: N/a

Story cards discussed with the client

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

end_custome r pick_up_customer order_proc exit end_custome r end_order

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Function components (examples)

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

8. Keep your code as SIMPLE as possible

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

10. Code standards

Department of Computer Science, University of Sheffield

11. Collective code ownership

Department of Computer Science, University of Sheffield

12. 48 hours/week => avg of 15hours/week

Department of Computer Science, University of Sheffield

Java coding standards(p.131-)

Department of Computer Science, University of Sheffield

Java coding standards(contd)

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Department of Computer Science, University of Sheffield

Simplify/apply partially some of them

Department of Computer Science, University of Sheffield

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.