1 / 41

SOEN 343 Software Design

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

gemma-ware
Download Presentation

SOEN 343 Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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?

More Related