Download
soen 343 software design n.
Skip this Video
Loading SlideShow in 5 Seconds..
SOEN 343 Software Design PowerPoint Presentation
Download Presentation
SOEN 343 Software Design

SOEN 343 Software Design

146 Views Download Presentation
Download Presentation

SOEN 343 Software Design

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. SOEN 343Software 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. Requirements Design Implementation Design vs. Requirements and 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 complexunlesseffort 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. publicclass 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 voidtestGetTitle(). • 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 publicvoid 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; publicclass VectorTest extends TestCase { publicvoid testEmptyVectorSize() { Vector v = new Vector(); assertEquals(0, v.size()); } }

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

  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 • Creator • Expert • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication • Indirection • Protected Variations

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

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

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

  30. Animal Class publicclassAnimal { private String name; private String kind; public Animal(String aKind, String aName) { kind = aKind; name = aName; } public String getKind() { return kind; } …

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

  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 • To know? • To do? • To decide?

  40. Responsibilities – A Boat Metaphor Kind of responsibility for: • Navigator. • To know? • To do? • To decide?

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