Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Material Type: Notes; Professor: Anderson; Class: OO ANALYSIS & DESIGN; Subject: Computer Science; University: University of Colorado - Boulder; Term: Unknown 1989;
Typology: Study notes
1 / 12
This page cannot be seen from the preview
Don't miss anything!
2
Design Stories Search Strategies Coming up with Names Describing Candidate Objects and their relationships
February 8, 2005 © University of Colorado, Boulder, 2005
Good graphic design requires careful use of color, texture, and shapes to make images “leap off the page”. A bad design muddles what should be emphasized Example: “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 structure To create these designs, however, you need a process
Take text that describes the requirements for the system and Underline nouns! Objects! Underline verbs! Methods! This strategy is inadequate because finding good objects involves finding abstractions that are going to be useful for your application Some of these abstractions may not have real-world counterparts Although we must determine which domain concepts WILL be included and how they will fit within the overall application 4
February 8, 2005 © University of Colorado, Boulder, 2005
Many additional candidates will be created as you move forward in analysis and design 8
February 8, 2005 © University of Colorado, Boulder, 2005
These candidates should be “smart” They “do things” in your system They may “know things” about your system as well, but they do things in response to what they know So, identify distinct objects with clear roles first; then identify their responsibilities and their relationships
Identify what objects have attributes and behaviors in common (classes) and what objects have common responsibilities (interfaces)
This allows you to identify candidates that “fall into place” and support various aspects of your story The 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. 10
February 8, 2005 © University of Colorado, Boulder, 2005
The work your system performs Things directly affected or connected to the application Information that flows through your software Decision making, control and/or coordination activities Structures and groups of objects Domain Concepts
If your system performs computations, look for service providers If your system interacts with the outside world, look for interfacers With respect to users, only include them in your object model if you need to treat different types of users in different ways If your system handles lots of events, look for controllers If your system manipulates lots of information, look for structurers
14
February 8, 2005 © University of Colorado, Boulder, 2005
When the name of an object is spoken, designers infer something about the object’s role and
They note that multiple naming systems (roles, patterns, domain concepts) can coexist within a single application
This conveys both a general set of responsibilities and a specific type of behavior Calendar vs. GregorianCalendar vs. JulianCalender
Timer vs. MillisecondTimerAccurateWithinPlusOrMinusTwoMilliseconds (!!)
StringTokenizer, SystemClassLoader, AppletViewer, etc. 16
February 8, 2005 © University of Colorado, Boulder, 2005
even though some OO languages support this Example: having two objects called Processor (each in different packages) that may process different things or “process” in different ways
TransactionProperties vs. Properties as long as the two objects don’t do radically different things
Account vs. Acct
Record name, description, and role stereotypes
See examples on page 94
20
February 8, 2005 © University of Colorado, Boulder, 2005
application layer use case stereotype role object neighborhood abstraction level application theme
Look for powerful abstractions and common roles Car, Boat, Bike, Tractor! Vechicle Look for the right level of abstraction ChessMove vs. PawnMove, RookMove, etc. Discard candidates if they can be replaced by a shared role Book, CDs, DVDs, etc.! InventoryItem 22
