SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler

Slides:



Advertisements
Similar presentations
GRASP Patterns M Taimoor Khan
Advertisements

SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Oct 2, Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu Banerjee.
NJIT 1 GRASP: Designing Objects with Responsibilities Chapter 17 Applying UML and Patterns Craig Larman.
Object-Oriented Analysis and Design
GRASP : Designing Objects with Responsibilities
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Chapter 25 More Design Patterns.
Programmer Testing Testing all things Java using JUnit and extensions.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Lesson 7 Unit Testing /JUnit/ AUBG ICoSCIS Team Assoc. Prof. Stoyan Bonev March, , 2013 SWU, Blagoevgrad.
Computer Science and Engineering College of Engineering The Ohio State University JUnit The credit for these slides goes to Professor Paul Sivilotti at.
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after identifying requirements, create domain model, define responsiblities.
1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Architecture GRASP Realization of use cases in interaction diagrams Design class diagram Design ( how )
Chapter 7: Object Design Examples with GRASP. Objective Design use case realizations. Apply GRASP to assign responsibilities to classes. Apply UML to.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Chapter 17. Initial Object Design Inputs: requirements meetings various Use Cases – 10% complete Key risks addressed with preliminary programming System.
GRASP: Designing Objects With Responsibilities
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Software Engineering 1 Object-oriented Analysis and Design Chap 21 Test-Driven Development and Refactoring.
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Design Patterns. Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Copyright © Craig Larman All Rights Reserved Responsibility-Driven Design with the GRASP Patterns.
Object-Oriented Design Part 2
GRASP: Designing Objects with Responsibilities
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Object Design and Use- Case Realizations with GRASP Patterns.
Introduction to JUnit 3.8 SEG 3203 Winter ‘07 Prepared By Samia Niamatullah.
What to remember from Chap 13 (Logical architecture)
Software Design: Principles, Process, and Concepts Getting Started with Design.
Object-Oriented Analysis and Design Mar 9, 2008.
OO Methodology Elaboration Iteration 2 - Design Patterns -
TK2023 Object-Oriented Software Engineering CHAPTER 12 Introduction to Responsibility-Driven Design.
OO Design Roshan Chitrakar. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
S Ramakrishnan1 Systems V & V, Quality and Standards Dr Sita Ramakrishnan School CSSE Monash University.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Elaboration Iteration 3 – Part 3 - Persistence Framework -
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
Chapter 17 Designing with Responsibilities. Fig
OO Methodology Elaboration Phase Iteration 1- Part 3.
Design. 2 The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary but not sufficient in order.
GRASP: More Patterns for Assigning Responsibilities Presented By Dr. Shazzad Hosain.
Testing in OO Environment The reasons for testing is not any different for any of the design and implementation methodologies, including OO methodology.
General Principles in Assigning Responsibilities Responsibilities Responsibility-Driven Design CRC Cards GRASP.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Elaboration: Iteration 2. Elaboration: Iteration 2 Basics Iteration 1 ends with : All the software has been tested: The idea in the UP is to do early,
SWE 434 SOFTWARE TESTING AND VALIDATION LAB2 – INTRODUCTION TO JUNIT 1 SWE 434 Lab.
GRASP – Designing Objects with Responsibilities
Chapter 12: Collaboration Diagram - PART2
Conception OBJET GRASP Patterns
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
GRASP : Designing Objects with Responsibilities
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2005 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
Object Oriented System Design Responsibilities
Presentation transcript:

SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler

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.

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

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(); } 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 public void 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; 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.Creator 2.Expert 3.Controller 4.Low Coupling 5.High Cohesion 6.Polymorphism 7.Pure Fabrication 8.Indirection 9.Protected Variations

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

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

Farm Example, Solution #2

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

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

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