1 / 42

Analysis/Design in XP

Analysis/Design in XP. Similar to RUP except that everyone does it little written, more oral less is done up-front. Analysis in RUP (and XP). Gather use cases from customer Make initial object model For each use case: step through use case, note the objects it requires

nitara
Download Presentation

Analysis/Design in XP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Analysis/Design in XP • Similar to RUP except that • everyone does it • little written, more oral • less is done up-front CS427

  2. Analysis in RUP (and XP) • Gather use cases from customer • Make initial object model • For each use case: • step through use case, • note the objects it requires • note the operations it uses • Clean up the model CS427

  3. Communication with customer • XP does not require any written requirements documents • How do you make sure you are building the system the customer wants? • Customer is on the team • Team writes code only for user stories CS427

  4. User story • User story equivalent to use case • User story less detailed than use case • usually just a sentence or two, • does not include detailed description • How do developers know what the customer meant by the user story? CS427

  5. XP timeline Customer Write stories Pick stories Implement stories Estimate stories Developers CS427

  6. XP Timeline • Startup • Write stories • Develop metaphor • Estimate stories • Normal • Write stories, estimate stories, pick stories • For each story • write test • write code • refactor CS427

  7. Estimating stories • Requires requirements • talk to customer • Requires design • talk to other developers • Requires experience CS427

  8. Who is customer? • Only one user of system • Many users of system, all similar • Many users of system, all different • Mass-market software CS427

  9. XP does not necessarily • Develop complete set of user stories • Develop consistent model of system • Develop documentation • for “gold owner” • for users • for maintenance programmers CS427

  10. XP Requirements • What “Customer” does • Talks with other customers • Makes surveys • Writes reports, position papers, specs, etc for management and other customers • Writes user stories CS427

  11. XP Analysis • What the developer does • Read user stories • Talk to each other, play with the design, make sure user story is understood • Ask the customer questions • Result: estimated user stories, developer who thinks he understands what to do CS427

  12. Objections • Developer will make too many mistakes • Too much rework • Never get around to writing documentation CS427

  13. Strengths • Lots of communication • Minimize unnecessary paperwork • Make at least one customer happy CS427

  14. Modeling example • Build up model bit by bit • Look at one requirement at a time • A new requirement might require • adding to model • changing model • Model should support all the requirements you’ve seen so far CS427

  15. Why we model this way • We can only think about one thing at a time • Criticism is easier than creation • As long as we get the right answer, it doesn’t matter how we got it CS427

  16. The Viking • A direct marketing system • Sends customized mail and e-mail • http://www.designfest.org/Problems/ Viking/Viking_00.pdf • Description consists of a set of use cases CS427

  17. Use Case Diagram for The Viking CS427

  18. Generating letters A user selects a set of customers to whom they wish to send letters and a template that defines the letter format. The Viking then generates a letter per customer that is based on filling in the “pluggable” information for the template with customer-related information. The user then previews the result of expanding the template list for each of the customers. CS427

  19. Viking selection Letter customers Customer Template letterFor() CS427

  20. Template Dear <<Proper Salutation>> <<Customer Name>> Thank you very much from ordering from us on <<Date of most recent order>>. We recently received several thousand cans of the special ingredient, … If you are interested, please click on http://theHappyViking.com/SpecialOrder/<<special order number>>/Order.html CS427

  21. Viking * selection Letter preview customers * * * Customer Template letterFor() TemplateComponent stringFor() Field name stringFor() Constant value stringFor() stringFor(aCustomer) { return aCustomer.valueOf(name)} CS427

  22. Viking * selection Letter customers * * Customer Template letterFor() * TemplateComponent stringFor() * Property name value Field name stringFor() Constant value stringFor() stringFor(aCustomer) { return aCustomer.valueOf(name)} CS427

  23. Use template to create a letter for a customer letter := empty letter; for each component c of template, add c.stringFor(customer) to letter If c is a constant, c.stringFor() is c.value. If c is a field, c.stringFor(customer) is customer.valueOf(c.name) CS427

  24. Sending letters A user chooses from among the generated letters and decides which ones to send out and by which MailingSystem to send them. The Viking should already have information associated with each customer so it can properly distribute the letter by a particular MailingSystem; the user should not need to enter this information as part of the sending process. CS427

  25. selection Viking Letter * * * customers Customer MailingSystem mail() * Property name value PostalSystem mail() SMTP mail() CS427

  26. * MailingSystem mail() Viking selection * customers * * Customer * Letter PostalSystem mail() SMTP mail() * Property name value A Customer has a property “e-mail address” and “postal address” which are used by the MailingSystems to obtain an address. CS427

  27. Adding Customer Information A user knows of a new customer that she wants to add to The Viking. The user can create a new customer entry and record relevant information (Name, Salutation, Address, Recent Purchase, and anything needed by other parts of The Viking) for that customer. CS427

  28. Viking * customers Customer * Property name value CS427

  29. Interface for creating customer Create New Customer Name: Salutation: Address: E-mail: Recent purchase: Anna Kurn Ms. 712 Maple Ave, Toronto NY E-mail: akurn@fipster.com Recent purchase: #e45 CS427

  30. Template Creation A user creates a new template either from scratch or by copying an existing template. A template needs to support both constant and “pluggable” information, and a user should be able to create a template and preview its appearance. CS427

  31. Viking * Template letterFor() TemplateComponent stringFor() Field name stringFor() Constant value stringFor() CS427

  32. Viking * TemplateParser Template letterFor() TemplateComponent stringFor() Field name stringFor() Constant value stringFor() CS427

  33. User interfaces • Generate letters (select a set of customers and a template) and preview them • Select letters to send and the mailing system to use • Create new customer and enter info • Create new template and preview it CS427

  34. Delivery Montoring A user reviews the letters to see which have been sent and whether any of them have “failed delivery”. If so, the user can choose to resend them either by the same Mailing System or by a different one. Also, to support this story, the Mailing System must be able to tell The Viking which sent letters “failed delivery”. CS427

  35. * MailingSystem mail() Viking * Letter PostalSystem mail() SMTP mail() CS427

  36. * MailingSystem mail() Viking * Letter status PostalSystem mail() SMTP mail() CS427

  37. Mail delivery failure • Some failures are permanent (“no such user”) and some are temporary (“mailbox full”). Need different status for each. • Can have secondary addresses. • “Select permanent failures and send to secondary address” is special case of “select messages and send them” • Need UI for changing status CS427

  38. Customer selection by criteria Upgrade the template from Story#1 to support selecting the set of customers by various search criteria. For example, select all customers who spent more than US$100 on their most recent order, or all customers who have every bought a particular product. CS427

  39. What query language? • SQL? • Dialog box? • What criteria? • Any history? • Orders, products • Change the UI for “select customers” CS427

  40. Conclusion • Only half done • Process to finish is the same • Each step makes progress • Keep track of open issues and make sure they get resolved • Amount you write down depends on how much you remember CS427

  41. Hints for XP • Pair programming • Schedule time (put in plan) • Meet together as much as possible • Testing – use Junit or similar • www.junit.org • http://www.xprogramming.com/software.htm • Refactoring – see refactoring.com CS427

  42. Next time • Hamlet and Maybee – chapter 9, start 10 CS427

More Related