Download ppt - SOEN 343 Software Design

Transcript
Page 1: SOEN 343 Software Design

SOEN 343Software Design

Section H Fall 2006

Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

Page 2: SOEN 343 Software Design

Responsibilities, Principles, Patterns

DesignGood Design, Smells, Evolutionary Design

TDD (Test Driven Design)

RDD (Responsibility Driven Design)

GRASP PrinciplesInformation Expert, Creator, Polymorphism

Page 3: SOEN 343 Software Design

What is Design?Developing a blueprint (plan) for a

mechanism that performs the required task,

… taking into account all the constraints, &

… making trade-offs between constraints when they are in conflict.

Page 4: SOEN 343 Software Design

Design vs. Requirements and Implementation.

Requirements

Design

Implementation

Page 5: SOEN 343 Software Design

Design Levels

• Architectural design...

• Detailed design...

• Implementation (executable designs)

Page 6: SOEN 343 Software Design

Two complimentary approaches to design

• Planned Design vs. Evolutionary Design

• Can we get away with only planned design?

Page 7: SOEN 343 Software Design

Evolutionary Design

• What is the probability that a S/W design will need to be updated?

• Change is inevitable, evolutionary design recognizes this.

• As software is changed, generally it becomes more complex unless effort is made to keep it simple.

Page 8: SOEN 343 Software Design

Evolutionary Design

• Practices– XP– Test driven development (TDD)

• Do not add code unless you have a test failing …

• Important characteristics– “Full” automated test suites– Refactoring

• Help us learn detailed design idioms, patterns, …

Page 9: SOEN 343 Software Design

Prerequisites to Successful Evolutionary Design?

• Testing– … lots of automated testing.

• Refactoring– … keeping the design simple.

• Continuous integration

• Actually, testing is a prerequisite to refactoring.

Page 10: SOEN 343 Software Design

Refactoring

• A refactoring is a change made to the internal structure of S/W to make it easier to understand and less expensive to modify, without changing its observable behavior.

Page 11: SOEN 343 Software Design

Can you pick out a good design?

• What is a good design?– Satisfies user needs.– Is a simple as possible. Kent Beck:

• Runs all tests• Reveals intention.• No duplication.• Fewest number of classes or methods

• … can you smell bad design choices?

Page 12: SOEN 343 Software Design

“Bad Smells”

• Duplication.

• Long method.

• …

• we will be learning more.

Page 13: SOEN 343 Software Design

Test Driven Design

• Write tests first.– Why does it make sense to write tests first?

• TDD in its pure form– Do not add any (product) code unless a test

failing.

Page 14: SOEN 343 Software Design

Test Driven Design

• Enabling technologies– *Unit, e.g.– JUnit

Page 15: SOEN 343 Software Design

JUnit Basics: TestCase Class

• Is a container for related test cases,not just one test case.

• Usage: subclass TestCase.• E.g.

public class MovieTest extends junit.framework.TestCase{ … }

jUnit

framework

TestCase

MyTest

Page 16: SOEN 343 Software Design

TestCase Clase Usage: Test Methods

• Write a method for each test.• Method should be declared public void.• Convention: method name starts with “test”

public void testGetTitle().

• By following the naming convention, individual tests will be picked up automatically (by reflection).

Page 17: SOEN 343 Software Design

A Test That Always Fails

public void testFailure() {fail();

}

• Yieldsjunit.framework.AssertionFailedError

at junit.framework.Assert.fail(Assert.java:47)

at junit.framework.Assert.fail(Assert.java:53)

at MovieTest.testFailure(MovieTest.java:24)

at java.lang.reflect.Method.invoke(Native Method)

Page 18: SOEN 343 Software Design

Most Common: Testing For Expected Values

public void testEmptyVectorSize() {Vector v = new Vector();assertEquals(

“size should be 0”, // msg0, // expected

value

v.size() // actual value

);}

Page 19: SOEN 343 Software Design

Other Assert Methods

• assertEquals(expected_value, actual_value)– i.e. no message provided.

• assertNull(reference_type_expr)– assertNotNull(reference_type_expr)

• assertTrue(boolean_expr)– assertFalse(boolean_expr)

• assertSame(expected_ref, actual_ref)

Page 20: SOEN 343 Software Design

JUnit Example, VectorTest Class

import junit.framework.TestCase;public class VectorTest extends TestCase {public void testEmptyVectorSize() {

Vector v = new Vector();assertEquals(0, v.size());

}

}

Page 21: SOEN 343 Software Design

What is OO Analysis and Design• Object-Oriented

Analysis

– Important domain concepts or objects?

– Vocabulary?

– Visualized in the UP Domain Model

• Object-Oriented Design

– Design of software objects

– Responsibilities– Collaborations

– Design patterns

– Visualized in the UP Design Model

Page 22: SOEN 343 Software Design

Responsibility-Driven Design (RDD)

• Detailed object design is usually done from the point of view of the metaphor of:– Objects have responsibilities– Objects collaborate

• Responsibilities are an abstraction.– The responsibility for persistence.

• Large-grained responsibility.

– The responsibility for the sales tax calculation.• More fine-grained responsibility.

Page 23: SOEN 343 Software Design

The 9 GRASP Principles

1. Creator2. Expert3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Protected Variations

Page 24: SOEN 343 Software Design

Object Responsibilities

• A responsibility is an obligation of an object in terms of its behavior.

• (More on this later)

Page 25: SOEN 343 Software Design

Design: Larman’s Approach

• Methodology based on– Responsibility assignment.– GRASP

General Responsibility Assignment Software Patterns.

• Input:– Use cases.– Domain model.– Operation contracts.

• Larman, Chapter 17.

Principles

Page 26: SOEN 343 Software Design

Information Expert

• “… expresses the common ‘intuition’ that objects do things related to the information they have.”

• Assign the responsibility for “knowing” [something] to the object (class) that has the information necessary to fulfill the responsibility.

Page 27: SOEN 343 Software Design

Creator

• Assign to class B the responsibility to create an instance of class A if– B aggregates A objects.– B contains A objects.– B records instances of A objects.– B closely uses A objects.– B has the initializing data that will be passed

to A when it is created.

Page 28: SOEN 343 Software Design

Farm Class Diagram

Animal

- name : String- kind : String

+ Animal ( [in] aKind : String , [in] aName : String )+ getKind ( ) : String

Farm

+ Farm ( )+ add ( [in] animal : Animal ) : void+ getNumberOfLegs ( ) : int

* - animals

Page 29: SOEN 343 Software Design

Test Cases

package farm.tests;…public class FarmTest extends …{

public void testGetNumLegs() { Farm f = new Farm(); f.add(new Animal("Duck", "Donald")); assertEquals(2, f.getNumLegs()); f.add(new Animal("Dog", "Pluto")); assertEquals(6, f.getNumLegs());}

}

Page 30: SOEN 343 Software Design

Animal Class

public class Animal {private String name;private String kind;public Animal(String aKind, String aName) {

kind = aKind;name = aName;

}public String getKind() {

return kind;}

Page 31: SOEN 343 Software Design

Farm Class, public int getNumLegs() {

int result = 0;Iterator it = animals.iterator();while(it.hasNext()) {

Animal a = (Animal) it.next();if(a.getKind().equals("Duck")) {

result += 2;} else if(a.getKind().equals(

"Dog")) {result += 4;

} else { // ?}

}return result;

}

Page 32: SOEN 343 Software Design

Bad Smell in Farm.getNumLegs()?

• Can you fix it?– Hints:

• By Information Expert, who should know about the number of legs of Animals, the Farm or … ?

• Having cascaded if’s (or switch statements) over information from another class is usually a very bad smell in OO.

• Apply Larman’s GRASP principles of Information Expert and Polymorphism.

Page 33: SOEN 343 Software Design

GRASP: Polymorphism Principle

Larman:

• When related alternatives or behaviors vary be type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies.

• (This principle was illustrated last week with the Animal hierarchy.)

Page 34: SOEN 343 Software Design

Farm Example, Solution #1

Animal

- name : String

+ Animal ( [in] aName : String )+ getName ( ) : String+ getNumLegs ( ) : int

Dog

+ Dog ( [in] aName : String )+ getNumLegs ( ) : int

Duck

+ Duck ( [in] aName : String )+ getNumLegs ( ) : int

Farm

+ Farm ( )+ add ( )+ getNumLegs ( )

- animals

*

{ return 2; }

abstract

{ return 4; }

Page 35: SOEN 343 Software Design

Farm Example, Solution #2

Animal

- numberOfLegs : int- name : String

+ getName ( ) : String+ getNumLegs ( ) : int# Animal ( [in] aName : String , [in] aNumberOfLegs : int )

Dog

+ Dog ( [in] aName : String )

Duck

+ Duck ( [in] aName : String )

Farm

+ Farm ( )+ add ( )+ getTotalNumLegs ( )

- animals

*

{ return numberOfLegs; }

Page 36: SOEN 343 Software Design

Practice in Tutorial

• Apply Larman’s GRASP principles of Information Expert and Polymorphism.

Page 37: SOEN 343 Software Design

General Classification of Kinds of Responsibility

– To know.– To do.– To decide.

Page 38: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

• What kind of responsibilities do each of the following “objects” have: …– To know.– To do.– To decide.

Page 39: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

Kind of responsibility for:

• Captain– To know?– To do?– To decide?

Page 40: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

Kind of responsibility for:

• Navigator.– To know?– To do?– To decide?

Page 41: SOEN 343 Software Design

Responsibilities – A Boat Metaphor

Kind of responsibility for:

• Compass.– To know?– To do?– To decide?


Recommended