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

• Let’s walk through a couple of examples to illustrate some design principles.

• #1 Managing Change

Object Oriented Design

• Dog Door example...

4


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....


Dog Door Use Case

6


Review the old design

10

Association

Multiplicity

Now, what might change in our Doggy Door system?


What might change?

4

Hardware (new and modified)

The use case (and the user requirements)

The code (implementation and tests)

…

1

2

3

4


Requirements

Does our use case satisfy these requirements?

9


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.


We have an alternate path thru the use case...

7

Does this make sense to you?How would you improve it?


An improved document

8


Our new design

11


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; }

…


Next issue

• Given that requirements change, how can you anticipate change in your design?

• Answer: ANALYSIS!

15


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?


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


• so have we sufficiently analyzed the bark recognizer?

• and how does it fit into the DogDoor program?

18


UML sequence diagrams make it easier to see

12

Lifeline

Message

Object

Control focus


1. Generalize as much as possible

13


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.


Our solution

16


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?


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?


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?


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


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?


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.


User stories for our main use case

29


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


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.


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.


37


Enough of this analysis stuff

• Where’s the design guidelines???

34


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).


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


What makes a design good?

6

Easy to understand

Flexible, easy to change

Satisfies the requirements (now and in the future)

1

2

3


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


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


Step 1: Talk to Rick

What questions will you ask Rick?

14


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


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


• Fast forward to version 1 of the program...

43


Review of the inventory search application

8


• What if the customer wanted to add a second type of instrument, say mandolins.

• How would the design have to change?

45


• Anything to add?• What else would

have to change?• Anything to

remove?

46


Rather than duplicating code, use an abstract class....


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.


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


Our revised application

14


UML Hints...


Are we done?

• This revised design looks pretty good.

• Are we done?

• Always ask yourself, “what if?”

52


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


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!


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?


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


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


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


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...


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.


• Back to Guitar Heaven...

61


Where are we?

2


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.”


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; }


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)


2

Classes are aboutBehavior

the original Instrument class was made as an abstract class because each instrument type was represented by its own subclass.


• 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.


Our improved design

17


19

WAIT - we just removed the different instrument types.What about their corresponding InstrumentSpec classes???


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?


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.


Our next improvement


Oddly enough, the final

design is...

74


Flexibility and cohesion

28


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.


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

software developmentfaculty.knox.edu/jdooley/sdwebpage/slidesinpdf/l6.2ooad_analysisdesign.pdfunless...

Documents