Presentation is loading. Please wait.

Presentation is loading. Please wait.

SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler

Similar presentations


Presentation on theme: "SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler"— Presentation transcript:

1 SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

2 Responsibilities, Principles, Patterns Design Good Design, Smells, Evolutionary Design TDD (Test Driven Design) RDD (Responsibility Driven Design) GRASP Principles Information Expert, Creator, Polymorphism

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

4 Design vs. Requirements and Implementation. Requirements Design Implementation

5 Design Levels Architectural design. Detailed design. Implementation (executable designs)

6 Two complimentary approaches to design Planned Design vs. Evolutionary Design Can we get away with only planned design?

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

8 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, …

9 Prerequisites to Successful Evolutionary Design? Testing –… lots of automated testing. Refactoring –… keeping the design simple. Continuous integration Actually, testing is a prerequisite to refactoring.

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

11 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?

12 “Bad Smells” Duplication. Long method. … we will be learning more.

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

14 Test Driven Design Enabling technologies –*Unit, e.g. –JUnit

15 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 { … }

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

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

18 Most Common: Testing For Expected Values public void testEmptyVectorSize() { Vector v = new Vector(); assertEquals( “size should be 0”, // msg 0, // expected value v.size() // actual value ); }

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

20 JUnit Example, VectorTest Class import junit.framework.TestCase; public class VectorTest extends TestCase { public void testEmptyVectorSize() { Vector v = new Vector(); assertEquals(0, v.size()); }

21 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

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

23 The 9 GRASP Principles 1.Creator 2.Expert 3.Controller 4.Low Coupling 5.High Cohesion 6.Polymorphism 7.Pure Fabrication 8.Indirection 9.Protected Variations

24 Object Responsibilities A responsibility is an obligation of an object in terms of its behavior. (More on this later)

25 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

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

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

28 Farm Class Diagram - animals

29 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()); }

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

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

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

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

34 Farm Example, Solution #1

35 Farm Example, Solution #2

36 Practice in Tutorial Apply Larman’s GRASP principles of Information Expert and Polymorphism.

37 General Classification of Kinds of Responsibility –To know. –To do. –To decide.

38 Responsibilities – A Boat Metaphor What kind of responsibilities do each of the following “objects” have: … –To know. –To do. –To decide.

39 Responsibilities – A Boat Metaphor Kind of responsibility for: Captain –T–To know? –T–To do? –T–To decide?

40 Kind of responsibility for: Navigator. –To know? –To do? –To decide?

41 Responsibilities – A Boat Metaphor Kind of responsibility for: Compass. –T–To know? –T–To do? –T–To decide?


Download ppt "SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler"

Similar presentations


Ads by Google