soen 343 software design
DESCRIPTION
SOEN 343 Software Design. Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html. Responsibilities, Principles, Patterns. Design Good Design, Smells, Evolutionary Design TDD (Test Driven Design) RDD (Responsibility Driven Design) GRASP Principles - PowerPoint PPT PresentationTRANSCRIPT
SOEN 343Software Design
Section H Fall 2006
Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen343h-f06.html
Responsibilities, Principles, Patterns
DesignGood Design, Smells, Evolutionary Design
TDD (Test Driven Design)
RDD (Responsibility Driven Design)
GRASP PrinciplesInformation Expert, Creator, Polymorphism
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.
Design vs. Requirements and Implementation.
Requirements
Design
Implementation
Design Levels
• Architectural design...
• Detailed design...
• Implementation (executable designs)
Two complimentary approaches to design
• Planned Design vs. Evolutionary Design
• Can we get away with only planned 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.
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, …
Prerequisites to Successful Evolutionary Design?
• Testing– … lots of automated testing.
• Refactoring– … keeping the design simple.
• Continuous integration
• Actually, testing is a prerequisite to refactoring.
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.
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?
“Bad Smells”
• Duplication.
• Long method.
• …
• we will be learning more.
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.
Test Driven Design
• Enabling technologies– *Unit, e.g.– JUnit
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
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).
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)
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
);}
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)
JUnit Example, VectorTest Class
import junit.framework.TestCase;public class VectorTest extends TestCase {public void testEmptyVectorSize() {
Vector v = new Vector();assertEquals(0, v.size());
}
}
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
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.
The 9 GRASP Principles
1. Creator2. Expert3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Protected Variations
Object Responsibilities
• A responsibility is an obligation of an object in terms of its behavior.
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
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.
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.
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
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());}
}
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;}
…
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;
}
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.
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.)
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; }
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; }
Practice in Tutorial
• Apply Larman’s GRASP principles of Information Expert and Polymorphism.
General Classification of Kinds of Responsibility
– To know.– To do.– To decide.
Responsibilities – A Boat Metaphor
• What kind of responsibilities do each of the following “objects” have: …– To know.– To do.– To decide.
Responsibilities – A Boat Metaphor
Kind of responsibility for:
• Captain– To know?– To do?– To decide?
Responsibilities – A Boat Metaphor
Kind of responsibility for:
• Navigator.– To know?– To do?– To decide?
Responsibilities – A Boat Metaphor
Kind of responsibility for:
• Compass.– To know?– To do?– To decide?