Lecture 9: Finding ObjectsKenneth M. AndersonObject-Oriented Analysis and DesignCSCI 6448 - Spring Semester, 20051February 8, 2005 © University of Colorado, Boulder, 20052Goals for this LectureReview content of Chapter 3 from the textbookDiscuss the process for discovering candidate objects and roles in a software systemReview techniques that can aid this processDesign StoriesSearch StrategiesComing up with NamesDescribing Candidate Objects and their relationshipsFebruary 8, 2005 © University of Colorado, Boulder, 2005Laying a FoundationWirfs-Brock and McKean compare object design to graphic designGood graphic design requires careful use of color, texture, and shapes to make images “leap off the page”.A bad design muddles what should be emphasizedExample: “chart junk”A good design is more than the sum of its parts.Object designs, likewise, require good abstractions, well-formed objects, and a good overall structureTo create these designs, however, you need a process3February 8, 2005 © University of Colorado, Boulder, 2005A Process for Finding ObjectsInitial strategies for finding objects were a bit naïveTake text that describes the requirements for the system andUnderline nouns ! Objects!Underline verbs ! Methods!This strategy is inadequate because finding good objects involves finding abstractions that are going to be useful for your applicationSome of these abstractions may not have real-world counterpartsAlthough we must determine which domain concepts WILL be included and how they will fit within the overall application4February 8, 2005 © University of Colorado, Boulder, 2005Finding Objects, continuedHowever, this does not mean we can’t be systematic!We can “find objects” viaour knowledge of the application domainour knowledge of “application machinery”lessons learned from other designers (think patterns!)our past design experiences (you’ll get better with each new system)5February 8, 2005 © University of Colorado, Boulder, 2005The Process1.Write a brief design story; Identify what is important about your application2.Use this story to identify several major themes that define some central concerns for your application3.Search for candidate objects that surround and support each theme4.Check that each candidate represents a key domain concept5.Look for candidates that will help your application interact with these key domain concepts6.Name, describe, and characterize each candidate6February 8, 2005 © University of Colorado, Boulder, 2005The Process, continued7.Organize your candidates; Look for clusters of objects that have to work together to solve a problem (use cases can help here)8.Double check to see if each candidate is appropriate9.Defend each candidate’s reasons for inclusion10.When discovery slows, move on to creating responsibilities (chapter 4) and collaborations (chapters 5 and 6)7February 8, 2005 © University of Colorado, Boulder, 2005DiscussionAgain, this process is not meant to be performed in a sequential manner; you may do several steps at once, you might discard several objects at once and start over, etc.Wirfs-Brock and McKean recommend that you do start with a design story, howeverThe goal is to come up with a core set of initial object candidate that represent the fundamental abstractions upon which your system is basedMany additional candidates will be created as you move forward in analysis and design8February 8, 2005 © University of Colorado, Boulder, 2005Find Objects FIRSTYour first candidates should be concrete objects or rolesThese candidates should be “smart”They “do things” in your systemThey may “know things” about your system as well, but they do things in response to what they knowSo, identify distinct objects with clear roles first; then identify their responsibilities and their relationshipsClasses and Interfaces will come later once you have enough concrete objects to understand the key relationships in your designIdentify what objects have attributes and behaviors in common (classes) and what objects have common responsibilities (interfaces)9February 8, 2005 © University of Colorado, Boulder, 2005Getting Started: Design StoriesTo make finding objects easier, create a framework for searching for candidates by writing a story about your applicationThis allows you to identify candidates that “fall into place” and support various aspects of your storyThe story should include not only functionality but your goals with respect to the software under design; what are the “cool things” about what you are trying to do and what things are you unsure about?Try to coalesce information from multiple sources, like use cases, other requirements, system architecture, users, etc.10February 8, 2005 © University of Colorado, Boulder, 2005Design Stories: How to Do ItWrite a rough story—top paragraphs, more or lessDon’t take a lot of time revising and polishing itWhat’s notable about the application? What is it supposed to do?Is it connected to a real-world example?Have you done something similar in the past?If you are a member of a large design teamWrite your own story first; then merge with other team membersTry to identify important themes within each story11February 8, 2005 © University of Colorado, Boulder, 2005Design Stories: ExamplesLets look at the examples in the text bookPage 81 contains a story about Internet banking servicesPage 82 contains a story about an Internet game, KriegspielBoth stories were written quickly: one rambles while the other is more focusedThe key themes for the former areModeling online banking services, flexibly configuring behavior, sharing scare resources among thousands of users, supporting different views of accounts and access privilegesThe key themes for the latter areGame modeling, a computer opponent, partitioning responsibilities across distributed components12February 8, 2005 © University of Colorado, Boulder, 2005Search StrategiesThemes in Design Stories can lead to candidatesCandidates will generally fall into one of these categoriesThe work your system performsThings directly affected or connected to the applicationInformation that flows through your softwareDecision making, control and/or coordination activitiesStructures and groups of objectsDomain ConceptsWhat do these categories remind you of?13February 8, 2005 © University of Colorado, Boulder, 2005Role Stereotypes!As discussed before, objects need to have a clear role and these roles will often
View Full Document
Unlocking...