Lecture 10: ResponsibilitiesKenneth M. AndersonObject-Oriented Analysis and DesignCSCI 6448 - Spring Semester, 20051February 10, 2005 © University of Colorado, Boulder, 20052Goals for this LectureReview content of Chapter 4 from the textbookDiscuss ResponsibilitiesWhat are they?How do we find them?How do we describe them?How do we assign them?February 10, 2005 © University of Colorado, Boulder, 20053ResponsibilitiesThe core of RDD is assigning responsibilities to objectsSo, what is a responsibility?Responsibilities are general statements about software objects; they includeThe actions an object performsThe knowledge an object maintainsMajor decisions an object makes that affect othersFebruary 10, 2005 © University of Colorado, Boulder, 20054Example: Teakettle (I)Consider the design of a teakettleWhat is the right form for a teakettle?A teakettle holds water that can be heated until boilingPeople can safely pick up a teakettle when it is filled with boiling water and pour a cup of teaBy convention, a teakettle whistles when the water boilsThese characteristics can be restated as responsibilitiesPour contents without spilling or splashingHold water that can be heated until boilingIs safe to hold and carry while water is hotNotify when boiling occursFebruary 10, 2005 © University of Colorado, Boulder, 20055Example: Teakettle (II)Did we get this right? It depends on the boundaries we have set for the problem; in conventional terms we have the bases coveredBut some designers like to redefine the problem: “Its not the teakettle that needs to be designed, but the method of heating the water!”Here the teakettle becomes part of the context, rather than the “form being designed”This type of thinking might lead to innovation such as an “instant hot” unit that heats tap water as it flows through itThe trick is to know when to indulge this type of thinking; sometimes it leads to innovation but sometimes it adds unnecessary complexity and expenseFor most people, the conventional teakettle works just fine!February 10, 2005 © University of Colorado, Boulder, 20056Finding ResponsibilitiesUse CasesIdentify system responsibilities stated or implied by use casesplug gaps in use cases by developing lower-level responsibilitiesThemes and Design StoriesFollow “what if…then…and how” chainsIdentify stereotypical responsibilitiesIdentify responsibilities to support relationships between candidatesPatterns (!)February 10, 2005 © University of Colorado, Boulder, 20057Use Cases and ResponsibilitiesUse cases describe our software from the perspective of an outside userThey don’t tell how something is accomplishedWe need to “bridge this gap” by transforming these descriptions into explicit statements about actions, information, or decision-making responsibilitiesBridging the GapIdentify things the system does and the information it managesRestate these things as responsibilitiesBreak them down into smaller parts if necessary and assign them to appropriate objectsFebruary 10, 2005 © University of Colorado, Boulder, 20058Example: University EnrollmentA student can register online for classes by filling out and submitting an online registration form for approval. While filling out the registration form, a student can browse course schedules, cross-listed courses, audit degree requirements, and update personal and financial aid information. The student can also access the “waitlist class” and “drop class” functionsThe system should identify problems as courses are added, such as time conflicts, full classes, lack of prerequisites, etc.February 10, 2005 © University of Colorado, Boulder, 20059Example: ResponsibilitiesGenerate and display an online registration form (something needs to know the structure of the form and how to display it)Provide feedback as the student enters course selections about conflicts or problems (Something needs to check that a student can sign up for a course; a component is also needed to display feedback about the results)Provide capabilities for browsing, auditing degree requirements, and updating personal/financial information (browsing sounds like a big responsibility, auditing sounds like a complex process, updating personal information will require specific boundary, controller, and domain classes)…February 10, 2005 © University of Colorado, Boulder, 200510Example: Specific Scenario1. Student logs in2. System verifies that student is eligible to register and displays reg. form3. Student adds courses to schedule4. System verifies schedule and returns approved courses for confirmation5. Student confirms schedule6. System updates course rosters and confirms successful registrationFebruary 10, 2005 © University of Colorado, Boulder, 200511Example: More responsibilitiesCheck that student is eligible to registerFrom step 2Add student to course rostersFrom step 6Display confirmation of registrationFrom step 6Validate each course in schedule meets constraints such as prerequisites, etc.From step 4February 10, 2005 © University of Colorado, Boulder, 200512Example: Filling in gapsThese directly derived responsibilities have gaps; ask questions and identify additional responsibilitiesHow are prerequisites specified?A relationship between course objects?Possibly need structurer to handle thisWhat states does a student’s schedule go through? “build/submit/confirm”Who manages this life cycle? The schedule object?Does registering happen in “real time”?How much help should the system give to a student when things go wrong?February 10, 2005 © University of Colorado, Boulder, 2005Themes and Design StoriesIn lecture 9, we saw that design stories can be used to identify candidate objects... they can also be used to identify system responsibilitiesLets return to the example design story that discussed an Internet banking application (See page 117-119)13February 10, 2005 © University of Colorado, Boulder, 200514“What if” scenariosAsking “what if” questions can lead to lines of reasoning that identify additional responsibilitiesWhat if the database goes down before my schedule is confirmed?Is the student out of luck? Can the schedule be saved elsewhere and retrieved for later submission?This type of thinking will lead to new candidates with responsibilities to handle this situationFebruary 10, 2005 © University of Colorado, Boulder, 200515Stereotypical ResponsibilitiesAs mentioned before, stereotypes have common sets of responsibilities
View Full Document
Unlocking...