Software Developmentfaculty.knox.edu/jdooley/SDWebPage/SlidesInPDF/L6.2OOAD_AnalysisDesign.pdfUnless...
Transcript of Software Developmentfaculty.knox.edu/jdooley/SDWebPage/SlidesInPDF/L6.2OOAD_AnalysisDesign.pdfUnless...
-
Object Oriented Design 1
Software Developmentand Professional Practice
Object-Oriented DesignPart the Second:
(in which we revisit Requirements churn, Analysis, and Design)
-
Intro to Development 2
Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
A number of slides in this file contain figures and data from Head First Object-Oriented Analysis and Design, and are copyrighted by O’Reilly Media, Inc., 2007.
http://creativecommons.org/licenses/by-nc-sa/3.0/http://creativecommons.org/licenses/by-nc-sa/3.0/http://creativecommons.org/licenses/by-nc-sa/3.0/http://creativecommons.org/licenses/by-nc-sa/3.0/
-
Object Oriented Design 3
Object-Oriented Design
• Let’s walk through a couple of examples to illustrate some design principles.
• #1 Managing Change
-
Object Oriented Design
• Dog Door example...
4
-
Object Oriented Design
Managing change...
3
Can you add some hardware to recognize Fido’s bark when he wants go to out and come back in and automatically open the door? That way we don’t need to hear him or find that darn remote that keeps getting lost.
So you’ve made an automated dog door that opens and closes a dog door using a remote control.
But....
-
Object Oriented Design
Dog Door Use Case
6
-
Object Oriented Design
Review the old design
10
Association
Multiplicity
Now, what might change in our Doggy Door system?
-
Object Oriented Design
What might change?
4
Hardware (new and modified)
The use case (and the user requirements)
The code (implementation and tests)
…
1
2
3
4
-
Object Oriented Design
Requirements
Does our use case satisfy these requirements?
9
-
Object Oriented Design
New requirement(s)
• So what’s the new requirement(s)?
10
Can you add some hardware to recognize Fido’s bark when he wants go to out and come back in and automatically open the door? That way we don’t need to hear him or find that darn remote that keeps getting lost.
We need to recognize the dog’s bark.
-
Object Oriented Design
We have an alternate path thru the use case...
7
Does this make sense to you?How would you improve it?
-
Object Oriented Design
An improved document
8
-
Object Oriented Design
Our new design
11
-
Object Oriented Design
Proposed BarkRecognizer code
17
/** * This class represents the bark recognizer that opens the device it * controls if presented with a known bark. * * @author aNewProgrammer */public class BarkRecognizer {
private DogDoor door; /** * Constructor initializes this recognizer by * storing the device it controls and the bark it recognizes. * * @param door- door the recognizer controls */ public BarkRecognizer(DogDoor door) { this.door = door; }
…
-
Object Oriented Design
Next issue
• Given that requirements change, how can you anticipate change in your design?
• Answer: ANALYSIS!
15
-
Object Oriented Design
What is analysis?
2
• A method of studying the nature of something or of determining its essential features and their relations
• A method of exhibiting complex concepts or propositions as compounds or functions of more basic ones
• The evaluation of an activity to identify its desired objectives and determine procedures for efficiently attaining them
What makes something essential in a system?
-
Object Oriented Design
What makes something essential?
5
Customer won’t buy without it
System won’t work without it
Many parts of the system depend upon it
-
Object Oriented Design
• so have we sufficiently analyzed the bark recognizer?
• and how does it fit into the DogDoor program?
18
-
Object Oriented Design
UML sequence diagrams make it easier to see
12
Lifeline
Message
Object
Control focus
-
Object Oriented Design
1. Generalize as much as possible
13
-
Object Oriented Design
14
So any dog bark can open the door. That doesn’t seem correct.
What would you do to change your solution?
Try to change the sequence diagram.
-
Object Oriented Design
Our solution
16
-
Object Oriented Design
Some guidelines for analysis...‣ Make simple classes that work
together by sending and responding to messages
‣ Classes should have one responsibility
‣ Most persistent objects (like the bark) will usually have a class that manages them‣ Create‣ Retrieve‣ Update
‣ Delete
17
So how did you know that you needed the BarkManager class?
-
Object Oriented Design
Other use cases
Bark maintenance (CRUD)
Initialize system
Disable (lock) door
Report activity
1
2
3
4
Now that we’ve analyzed one additional case, what elsemight we think about?
-
Object Oriented Design
21
Use cases seem to require a lot of care to keep them up to date and complete. Are there other ways we can describe the system with a little less effort?
Well, how about user stories?
-
Object Oriented Design
User stories
‣ Describe a single feature or unit of work for a developer
‣ Provides enough information to define the basic need
‣ Should be able to be tested with unit tests
26
-
Object Oriented Design
A typical user story
27
Open the dog door
The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds
What if the door is already open?
-
Object Oriented Design
A typical user story (revised)
28
Open the dog door
The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds. At the end of 5 seconds, the door will close. If the door is already open, then the door will not close until 5 seconds from the current signal reception has elapsed.
-
Object Oriented Design
User stories for our main use case
29
-
Object Oriented Design
User story guidelines‣ If the user story gets too long, break it up into two or more‣ If it won’t fit on an index card, it’s too big
‣ If the user story is trivial, it can probably be combined with another
‣ Make sure there’s enough information for the developer to implement the user story or at least ask intelligent questions about it
‣ If a user story will take too much time (which is relative) to implement, break it up into smaller user stories
30
-
Object Oriented Design
Comparing the techniques
31
Use Cases User StoriesAddress complete goal-oriented sequences of actions the system must perform.
Feature oriented rather than a user’s goal oriented.
Unifies several features or parts of features to provide value. Does not address the class level view.
Can be at a technical level but does not relate features to higher level goals.
Mainly requirements and analysis Can include technical details needed to satisfy requirements.
Explicitly describes multiple paths Does not address paths through the application.
Can be used for large granularity estimation.
Good for individual programmer task estimation.
-
Object Oriented Design
Three things we might have found outfrom using user stories...
‣ There might be multiple dogs
‣ There might be multiple doors
‣ There might be multiple remotes
36
How would this change your design? Draw a UML class diagram to show the improved solution.
-
Object Oriented Design
37
-
Object Oriented Design
Enough of this analysis stuff
• Where’s the design guidelines???
34
-
Object Oriented Design
Our definition of design
5
Software design is the process of planning how to solve a problem through software.
A software design contains enough information for a development team to implement the solution. It is the
embodiment of the plan (the blueprint for the software solution).
-
Object Oriented Design
Common design characteristics
‣ Designs have a purpose‣ They describe how something will work (in a context)
‣ Designs have enough information so that someone can implement them
‣ There are different styles of design‣ Like different types of house architectures
‣ Designs can be expressed at different levels of detail‣ A dog house needs less detail than a skyscraper
4
-
Object Oriented Design
What makes a design good?
6
Easy to understand
Flexible, easy to change
Satisfies the requirements (now and in the future)
1
2
3
-
Object Oriented Design
Another (long, drawn out) example...
• Rick has a guitar store• he wants an inventory program• that can also answer customer’s questions about
what guitars Rick has available• He’s come to you for that program....
38
-
Object Oriented Design
Three steps to great software
1. Make sure the software does what the customer wants
‣ Apply good object-oriented principles
‣ Strive for a maintainable, reusable design
13
-
Object Oriented Design
Step 1: Talk to Rick
What questions will you ask Rick?
14
-
Object Oriented Design
Questions for Rick
Do you only sell guitars?
How will you update the inventory?
How should a search for a guitar really work?
Do you need reports about inventory and sales?
1
2
3
4
16
-
Object Oriented Design
Rick says
Customers don’t alwaysknow all of the
characteristics of the guitar they want.
There’s often more thanone guitar that matches
the customer’s needs.
Customers often look for aguitar in a specific price
rangeI need reports and other
capabilities in myinventory, but my #1problem is finding theright guitar for the
customer.
17
-
Object Oriented Design
• Fast forward to version 1 of the program...
43
-
Object Oriented Design
Review of the inventory search application
8
-
Object Oriented Design
• What if the customer wanted to add a second type of instrument, say mandolins.
• How would the design have to change?
45
-
Object Oriented Design
• Anything to add?• What else would
have to change?• Anything to
remove?
46
-
Object Oriented Design 47
Rather than duplicating code, use an abstract class....
-
Object Oriented Design
12
Abstract classes encapsulate shared behavior and define the protocol for all subclasses
Abstract classes are placeholders for actual implementationclasses. The abstract
class defines behavior, and the subclasses implement that behavior.
The conclusion is:Whenever you find common behavior in two or more places, look to abstract that behavior into a class, and then reuse that behavior in the common classes.
-
Object Oriented Design
It’s not quite this simple‣ Things still need to be done‣ Make the Inventory class use
Instrument rather than Guitar
‣ Add an InstrumentSpec class‣ Abstract base class for
the GuitarSpec
‣ Add a MandolinSpec class derived from InstrumentSpec
‣ Make the Inventory class use InstrumentSpec instead of GuitarSpec
13
-
Object Oriented Design
Our revised application
14
-
Object Oriented Design 51
UML Hints...
-
Object Oriented Design
Are we done?
• This revised design looks pretty good.
• Are we done?
• Always ask yourself, “what if?”
52
-
Object Oriented Design
Ask what if …‣ What if Rick wants to sell more kinds of instruments?
‣ What if Rick wants to sell more than Instruments?‣ Accessories‣ CDs‣ books or e-books
‣ What if the inventory system has to integrate with sales and accounting programs?
21
-
Object Oriented Design
Adding new instruments
22
We need to add newinstrument classes,new spec classes,new enum classes,and new search()methods - one foreach new instrument.
Bad Programmer!
-
Object Oriented Design
23
So, duplicated code and making changes in several places in the code for a single requirements change indicates poor design?
Yup. This is a fundamental principle of good O-O design.
So what next?
-
Object Oriented Design
An aside: Java Design Review...
• What code construct has the dual role of
1. defining behavior that applies to multiple types, and
2. also being the preferred focus of classes that use those types?
56
-
Object Oriented Design
Interface
‣ Defines behavior (it’s a contract about implementation)
‣ No implementation code
‣ Cannot be instantiated
‣ A class can implement multiple interfaces (In languages that support interfaces)
Abstract class‣ Defines behavior
‣ Can have implementation code
‣ Cannot be instantiated
‣ A class can inherit from a single abstract class
‣ Unless the language supports multiple inheritance
3
Two possible answers
-
Object Oriented Design
4
How do I know when to use an interface and when to use an abstract class?
If (almost) all classes implementing the behavior would have the same code, then you can use an abstract class to implement it.
1. Avoid repeating code by using
abstract classes
2. Code to interfaces
-
Object Oriented Design
A Painter Class
7
prepareEasel() and cleanBrushes() are not likely to change
but the type of painting technique is...
Aside, Part 2: Localizing changes in objects that may vary...
-
Object Oriented Design
Encapsulation is your friend
8
Anytime you have behavior that you think is likely to change, you want to move that behavior away from parts of your application that probably won’t change very frequently. In other words you should always try to encapsulate what varies.
-
Object Oriented Design
• Back to Guitar Heaven...
61
-
Object Oriented Design
Where are we?
2
-
Object Oriented Design
3
When we add a new type of instrument we have to change the Inventory class. And we have to add a new search method. That doesn’t seem like good design!
Good point. If we describe searching the inventory in words, we would say that we want to
“search the inventory to see if there are any instruments that match the customer’s specification.”
-
Object Oriented Design
The current search code
4
public List search(GuitarSpec searchSpec) { List matchingGuitars = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext(); ) { Guitar guitar = (Guitar)i.next(); if (guitar.getSpec().matches(searchSpec)) matchingGuitars.add(guitar); } return matchingGuitars; }
public List search(MandolinSpec searchSpec) { List matchingMandolins = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext(); ) { Mandolin mandolin = (Mandolin)i.next(); if (mandolin.getSpec().matches(searchSpec)) matchingMandolins.add(mandolin); } return matchingMandolins; }
-
Object Oriented Design
5
public List search(InstrumentSpec searchSpec) {
List matchingInstruments = new LinkedList();
for (Iterator i = inventory.iterator(); i.hasNext(); ) { Instrument instrument = i.next(); if (instrument.getSpec().matches(searchSpec)) matchingInstruments.add(instrument); }
return matchingInstruments;}
(or an abstract class)
-
Object Oriented Design
2
Classes are aboutBehavior
the original Instrument class was made as an abstract class because each instrument type was represented by its own subclass.
-
Object Oriented Design
• But.... you usually create a subclass because the behavior of the subclass is different than the superclass. In the inventory app....
• the instruments don’t have different behavior.
67
An instrument’s type is not behavior related. It is just another property and can be implemented easily as a field in the
Instrument class.
-
Object Oriented Design
Our improved design
17
-
Object Oriented Design
19
WAIT - we just removed the different instrument types.What about their corresponding InstrumentSpec classes???
-
Object Oriented Design 70
Since some of these properties vary, we want to move them out of the InstrumentSpec class. We need a way to refer to properties and their values, but not have those properties hardcoded into InstrumentSpec.
What type(s) do you think you could use to represent properties and access their values, but not have to change your InstrumentSpec class to support the new properties?
-
Object Oriented Design
20
There’s no need to fear, Captain Data Structures is here!
When you have a set of properties that vary across your objects, use a collection, like a Map, to store those properties dynamically.
You’ll remove lots of methods from your classes, and avoid having to change your code when new properties are added to your app.
-
Object Oriented Design
Our next improvement
-
Object Oriented Design 73
-
Object Oriented Design
Oddly enough, the final
design is...
74
-
Object Oriented Design
Flexibility and cohesion
28
-
Object Oriented Design
31
Way cool! Now we’ve got the ultimate application. Rick’s got to be crazy about what we’ve done. It’s so flexible. We can’t imagine an problems.
Folks, Rick just sent us a letter letting us know that he’s selling music books, accessories, and funny musical greeting cards. He wants to get them in his inventory as soon as possible.
-
Object Oriented Design
Design Homework
‣ Figure out how to meet Rick’s new requirements‣ Change your design if necessary to satisfy the new
requirements‣ Draw a UML diagram to show your design‣ Provide any other documentation you think is appropriate
32