410 likes | 579 Views
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
E N D
SOEN 343Software 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 Information 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.
Requirements Design Implementation Design vs. Requirements and 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 complexunlesseffort 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. publicclass MovieTest extends junit.framework.TestCase { … }
TestCase Clase Usage: Test Methods • Write a method for each test. • Method should be declared public void. • Convention: method name starts with “test” public voidtestGetTitle(). • By following the naming convention, individual tests will be picked up automatically (by reflection).
A Test That Always Fails public void testFailure() { fail(); } • Yields junit.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 publicvoid testEmptyVectorSize() { Vector v = new Vector(); assertEquals( “size should be 0”, // msg 0, // 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; publicclass VectorTest extends TestCase { publicvoid testEmptyVectorSize() { Vector v = new Vector(); assertEquals(0, v.size()); } }
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 What is OO Analysis and 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.
The 9 GRASP Principles • Creator • Expert • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication • Indirection • Protected Variations
Object Responsibilities • A responsibility is an obligation of an object in terms of its behavior. • (More on this later)
Principles Design: Larman’s Approach • Methodology based on • Responsibility assignment. • GRASPGeneral Responsibility Assignment Software Patterns. • Input: • Use cases. • Domain model. • Operation contracts. • Larman, Chapter 17.
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 - animals
Test Cases package farm.tests; … publicclassFarmTestextends …{ publicvoidtestGetNumLegs() { 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 publicclassAnimal { private String name; private String kind; public Animal(String aKind, String aName) { kind = aKind; name = aName; } public String getKind() { return kind; } …
Farm Class, publicint getNumLegs() { int result = 0; Iterator it = animals.iterator(); while(it.hasNext()) { Animal a = (Animal) it.next(); if(a.getKind().equals("Duck")) { result += 2; } elseif(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.)
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?