Unformatted text preview:

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 infoNew Wiki serverhttp://pixie.cs.uiuc.edu:8080/SEcourseHopefully more reliable, so less admin info hereHW2 was due, should grade by Nov. 10More feedback on projects from TAsProject groups should start meeting TAsHW3 is posted, due next Tuesday, Nov. 7State machines and ADTsCS427 18-3Topics on designPreviouslyComponent-level designModularity and abstractionRefinement, startedTodayRefinement, finishingXP example (for analysis and design)CS427 18-4RefinementApproach to design where you start from a high-level, simple description and then “refine it” with more detailsSome facts from practice Designers bounce between high-level and low-level concernsDesigners sometimes redo previous stepsSteps 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 mythRequirements changeRequirements are incompleteExistence of system changes requirementsAnalysts make mistakesDesigners make mistakesTime reveals better solutionsToo many decisions to note them allCS427 18-8How and Why to Fake ItDocumentation should be structured so that it describes a sequence of refinements with a reason for eachSequence not required to be historicalDesigners can reorganize and rewrite sequence if necessaryResult: clear design that can be reviewedCS427 18-9LessonsIteration is important part of real processGet running code as soon as possible!Hide effects of iteration on the documentationIt is easier to go from design to analysis if the same person does bothDivide work by subsystem, not by RUP roleReorganize subsystems (and group) as the project goes onCS427 18-10Analysis/Design in XPSimilar to RUP except thatEveryone does itLittle written, more oralLess is done up-frontCS427 18-11Analysis in XPGather user stories from customerMake initial object modelFor each user story:Step through user story Note the objects it requires Note the operations it usesClean up the modelCS427 18-12Communication 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 storiesCS427 18-13User 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 18-14XP timeline (1)DevelopersCustomerWrite storiesEstimate storiesPick storiesImplement storiesCS427 18-15XP timeline (2)StartupWrite storiesDevelop metaphorEstimate storiesNormalWrite stories, estimate stories, pick storiesFor each storyWrite testWrite codeRefactorCS427 18-16Estimating storiesRequires requirementsTalk to customerRequires designTalk to other developersRequires experienceWork on projectsCS427 18-17Who is customer?Only one user of systemMany users of system, all similarMany users of system, all differentMass-market softwareCS427 18-18XP does not necessarily Develop complete set of user storiesDevelop consistent model of systemDevelop documentationFor “gold owner”For usersFor maintenance programmersCS427 18-19XP requirementsWhat “Customer” doesTalks with other customersMakes surveysWrites reports, position papers, specs, etc. for management and other customersWrites user storiesCS427 18-20XP 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 doCS427 18-21Objections to XPDeveloper will make too many mistakesToo much reworkNever get around to writing documentationCS427 18-22Strengths of XPLots of communicationMinimize unnecessary paperworkMake at least one customer happyCS427 18-23Modeling 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 farCS427 18-24Why 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 itCS427 18-25The Viking exampleA direct marketing systemSends customized mail and e-mailExample from an OOPSLA Design FestDescription consists of a set of use casesThis 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

U of I CS 427 - Software Engineering I

Download Software Engineering I
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Software Engineering I and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Software Engineering I 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?