CS427: Software Engineering IAdministrative infoTopics on designRefinementRefinement mythsRational designTop-down design is a mythHow and Why to Fake ItLessonsAnalysis/Design in XPAnalysis in XPCommunication with customerUser storyXP timeline (1)XP timeline (2)Estimating storiesWho is customer?XP does not necessarilyXP requirementsXP analysisObjections to XPStrengths of XPModeling exampleWhy we model this wayThe Viking exampleUse Case Diagram for The VikingGenerating lettersInitial UML modelTemplateTemplates have componentsCustomizable propertiesUse template to create a letter for a customerSending lettersOne mailing systemCustomers have lettersAdding Customer InformationFocus on customersInterface for creating customerTemplate CreationFocus on templatesBuild templates from textUser interfacesDelivery MonitoringFocus on mailing systemLetters have statusMail delivery failureCustomer selection by criteriaConsdierationsConclusionHints for XPNext: OO Design1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 18-2Administrative infoNew Wiki serverhttp://pixie.cs.uiuc.edu:8080/SEcourseHopefully more reliable, so less admin info hereHW2 was due, should grade by Nov. 10More feedback on projects from TAsProject groups should start meeting TAsHW3 is posted, due next Tuesday, Nov. 7State machines and ADTsCS427 18-3Topics on designPreviouslyComponent-level designModularity and abstractionRefinement, startedTodayRefinement, finishingXP example (for analysis and design)CS427 18-4RefinementApproach to design where you start from a high-level, simple description and then “refine it” with more detailsSome facts from practice Designers bounce between high-level and low-level concernsDesigners sometimes redo previous stepsSteps often done “out of order”CS427 18-5Refinement mythsYou make one pass through the designEach step adds something to the designEach step is independent of the othersYou iterate because you don’t have a methodologyCS427 18-6Rational design“A Rational Design Process: How and Why to Fake It” by David Parnas and P.C. Clemens, IEEE Transactions on Software Engineering, SE-12:2, February 1986.Rational design process - one in which every step has a reasonCS427 18-7Top-down design is a mythRequirements changeRequirements are incompleteExistence of system changes requirementsAnalysts make mistakesDesigners make mistakesTime reveals better solutionsToo many decisions to note them allCS427 18-8How and Why to Fake ItDocumentation should be structured so that it describes a sequence of refinements with a reason for eachSequence not required to be historicalDesigners can reorganize and rewrite sequence if necessaryResult: clear design that can be reviewedCS427 18-9LessonsIteration is important part of real processGet running code as soon as possible!Hide effects of iteration on the documentationIt is easier to go from design to analysis if the same person does bothDivide work by subsystem, not by RUP roleReorganize subsystems (and group) as the project goes onCS427 18-10Analysis/Design in XPSimilar to RUP except thatEveryone does itLittle written, more oralLess is done up-frontCS427 18-11Analysis in XPGather user stories from customerMake initial object modelFor each user story:Step through user story Note the objects it requires Note the operations it usesClean up the modelCS427 18-12Communication with customerXP does not require any written requirements documentsHow do you make sure you are building the system the customer wants?Customer is on the teamTeam writes code only for user storiesCS427 18-13User storyUser story “equivalent” to use caseUser story less detailed than use caseUsually just a sentence or twoDoes not include detailed descriptionHow do developers know what the customer meant by the user story?CS427 18-14XP timeline (1)DevelopersCustomerWrite storiesEstimate storiesPick storiesImplement storiesCS427 18-15XP timeline (2)StartupWrite storiesDevelop metaphorEstimate storiesNormalWrite stories, estimate stories, pick storiesFor each storyWrite testWrite codeRefactorCS427 18-16Estimating storiesRequires requirementsTalk to customerRequires designTalk to other developersRequires experienceWork on projectsCS427 18-17Who is customer?Only one user of systemMany users of system, all similarMany users of system, all differentMass-market softwareCS427 18-18XP does not necessarily Develop complete set of user storiesDevelop consistent model of systemDevelop documentationFor “gold owner”For usersFor maintenance programmersCS427 18-19XP requirementsWhat “Customer” doesTalks with other customersMakes surveysWrites reports, position papers, specs, etc. for management and other customersWrites user storiesCS427 18-20XP analysisWhat the developer doesRead user storiesTalk to each other, play with the design, make sure user story is understoodAsk the customer questionsResult: estimated user stories, developer who thinks he understands what to doCS427 18-21Objections to XPDeveloper will make too many mistakesToo much reworkNever get around to writing documentationCS427 18-22Strengths of XPLots of communicationMinimize unnecessary paperworkMake at least one customer happyCS427 18-23Modeling exampleBuild up model bit by bitLook at one requirement at a timeA new requirement might requireAdding to modelChanging modelModel should support all the requirements you’ve seen so farCS427 18-24Why we model this wayWe can only think about one thing at a timeCriticism is easier than creationAs long as we get the right answer, it doesn’t matter how we got itCS427 18-25The Viking exampleA direct marketing systemSends customized mail and e-mailExample from an OOPSLA Design FestDescription consists of a set of use casesThis example is long; we’ll cover only a part of it!CS427 18-26Use Case Diagram for The VikingU s e rg e n e r a t i n g l e t t e r ss e n d i n g l e t t e r sm a i l s y s t e ma d d i n g c u s t o m e r i n f ot e m p l a t e c r e a t i o nd e l i v e r y m o n i t o r i n gc u s t o m e r s e l e c t i o nl i s t i n f o r m a t i o n s u p p o r tCS427 18-27Generating lettersA
View Full Document