Software Unit Testing Case Study:

  • Published on
    07-Jul-2015

  • View
    257

  • Download
    4

Embed Size (px)

Transcript

  • 1. Software Unit Testing Case Study:Money Class Conversation Simulation COP 4331 OO Processes for Software Development Dr. David A. Workman School of EE and Computer Science October 2, 2006

2. Hierarchical View of Design main A::One() A::Two() A::Three() B::One() C::One() B::Two() D::One() E::Two() E::One() D::Three() D::Two() Use Case #1 Use Case #3 Use Case #2 3. Design & Testing Principles A D B C Principle 1:Design should be performed top-down foreach functional thread defined by a Use Case;that is,theinterface and detailed design of a module should followthe design of all modules that functionally depend on it.Rationale: By performing interface and detailed designtop-down, we ensure that all requirements flow fromdependent modules toward the modules they depend on.This principle attempts to postpone detailed design decisionsuntil all functional requirements for a module are known. Principle 2: Coding and Unit Testing should be performed bottom-up for a functional thread;that is,the unit testing of a moduleshould precedethe unit testing ofall modules that functionally depend on it.Rationale: By performing unit testing bottom-up, we ensure that all subordinate modules have been verified before verifying the module that depends on them.This principle attempts to localize and limit the scope and propagation of changes resulting from unit testing. 4. Design & Testing Schedules Development Layers for Detailed Design and Coding Development Layers for Unit Testing See Notes Effort Time Development Schedule Build #1 (Integration Test 1) Build #2 (Integration Test 2) Build #3(System Test) 5. Design & Test Example:Discrete Event Simulator Dr. David A. Workman School of EE and Computer Science University of Central Florida March 29, 2007 6. Use Case Diagram: Simulator Simulation System Construct World Specify Input Simulate World Output World Objects Report Simulation Data Initialize Simulation Specify Output Simulation Input File Simulation Log File SimulationUser 7. Simulation Architecture 8. Simulation Architecture: Design Template The Passive layer contains all classes that model problem data and inanimate objects of the simulated world.Agents make direct calls on passive objects, but must account for the simulation time consumed when doing so.Passive objects make direct calls to each other, if necessary.Passive objects may be passed from one Agent to another as part of a instance of some Message subclass. This layer contains all the derived subclasses of Message.These classes are used to pass data for servicing interaction eventsbetween Agents.Only recipient Agent classes know the content and use of instances of these classes.Methods of Agents receiving messages optionally take parameters which are instances of one (or more) of the Passive classes and return an instance of class Message or one of its sub-classes.Instances of the root class Message carry no data and denote signals that require some action on the part of the receiver Agent. Virtual World Message Players Agent Event 2 Passive Class Layer Message Layer Agent Layer (ActiveObjects) Interface and Control Layer EventMgr * 1 Other Subclasses All Active Objects * * All Passive Classes/Objects * * * This layer consists of all active object classes.Active objects must be instances of some subclass of abstract classAgent .The simulation progresses as a result of Events created and serviced by Agents.An Event has four components: a Sender agent, a Recvr agent, an instance of some Message subclass, and an event time.When one Agent wishes to interact with another, it must do so by creating an Event that defines a future time at which the interaction will occur.The message component defines an action to the Recevr agent and possibly data necessary to complete the action.SimModels Classes SimMgmt Classes 9. Simulation Architecture: Student Conversation Conversation Message Players Agent Event 2 Passive Class Layer Message Layer Agent Layer (ActiveObjects) Interface and Control Layer EventMgr * 1 AnswerMsg * * Question Student Answer QuestionMsg SimModels Classes SimMgmt Classes 10. Design Graph:1 0:Main() 4 Reusable Methods 9 New Methods Class Conversation 1:Conversation() Class Agent 2:Agent() 3:operator>>() 4:Get() Class Student 5:Student() 6:Extract() 7:Get() 1 5 6 3 2 7 4 Use Case 1 11. Design Graph:2 0:Main() 5 Reusable Methods 9 New Methods Class Conversation 1:Conversation() 8:Initialize() Class Agent 2:Agent() 3:operator>>() 4:Get() 11: NameOf() 21: ~Agent() Class Student 5:Student() 6:Extract() 7:Get() 13: Initialize() 16: AcceptQuest() 8 20 Class Players 9:Players() 12: setAgent() 14: getAgent() 15: getOther() 20: ~Players() Class Message 10:Message() 9 2 12 13 11 14 15 16 Class SpeakMsg 17: SpeakMsg() 17 10 Class Event 18: Event() 18 Class EventMgr -3 :EventMgr() 19: postEvent() 19 21 Use Case 2 12. Design Graph:3 0:Main() Class Conversation 1:Conversation() 8:Initialize() 22: Insert() Class Agent 2:Agent() 3:operator>>() 4:Get() 11: NameOf() 21: ~Agent() 23: oper() 4:Get() 11: NameOf() 21: ~Agent() 23: oper