14004 L6 - © D. Deugo, 2003 – 2008 Lecture 6 Towards Testable Interaction Diagrams (A theoretical lecture with few examples…  )

24004 L6 - © D. Deugo, 2003 – 2008 Where are we at wrt Binder? We have covered: Ch1: Frame of mind for testing Ch 3: Terminology and limitations of testing Ch 5: Test models Section 8.3: Testing UC diagram Ch 14: System scope (patterns) Ch 6: Combinational Models We start today by reading in Section 8.5 that Sequence diagrams of UML are a poor model for developing tests: –“where a properly constructed flow graph will show all possible activation sequences, a sequence diagram is required to show only a single collaboration.”

34004 L6 - © D. Deugo, 2003 – 2008 Testing MSCs? Two questions must be first addressed: –Which MSCs should we test? –How do we generate tests from an MSC? We have argued for traceability between UCs, UCMs and MSCs. –But whereas unbound UCMs are still at system scope, bound UCMs and MSCs introduce classes and instances. This leads to two different testing viewpoints: 1.We must develop tests for detailed scenarios. 2.We must develop test for the classes whose instances are involved in these scenarios. 3.Once we will have code, we will first test the classes (unit testing) and then, and only then, will we execute the tests that proceed from scenarios (integration testing). –The question stands: how to device tests from interaction diagrams. »First decision: to use or not to use consolidated diagrams?

44004 L6 - © D. Deugo, 2003 – 2008 Overview of Gomaa’s COMET Problem Description Use Case Model Static Model of the Problem Domain Object Structuring Dynamic Model –UML ’s sequence and/or collaboration diagrams (augmented) –Statechart Model Consolidation (start of OOD according to Gomaa) Subsystem structuring Structuring System into Tasks –Consideration of Synchronization and Distributed Control Design of Information Hiding Classes Detailed Design Target System Configuration Performance Analysis HDL DDL

54004 L6 - © D. Deugo, 2003 – 2008 Consolidation Consolidation means role integration: –Consolidation can be thought of as superimposition of interaction diagrams »Merging all the scenarios!! –Consolidation can be thought of as the integration of the role state machines associated with a class »Extracting (or synthesizing) a class statechart from all the scenarios in which instances of this class appear. – The use case diagram is very important for such tasks: »We must not forget inter-scenario and inter-UC relationships!!

64004 L6 - © D. Deugo, 2003 – 2008 About Binder’s Integration Patterns Beware!! These patterns are NOT based on MSCs. Instead they pertain to how a tester goes and chooses how to test classes: –Pairwise –All-at-once (BIG BANG) –With respect to dependencies –With respect to layers This is a class-centered viewpoint: we are not there yet!

74004 L6 - © D. Deugo, 2003 – 2008 About Covering Arrays Alan Williams’s approach: –Nice mathematics to come up with the minimal set of permutations of values of a set of parameters to cover all degree n combinations »What looks like a NP-hard problem may not be after all… –Glitches: »If the set of possible values for a parameter gets modified frequently, the method breaks down »The assumption that one can derive an exhaustive set of values for each parameter of the system is problematic: a generative characterization could be more promising but would fall out of this approach.

84004 L6 - © D. Deugo, 2003 – 2008 Binder’s Patterns For Subsystems (chapter 12)

94004 L6 - © D. Deugo, 2003 – 2008 Subsystems Patterns Class Association –Shows how to design a test suite that will exercise the associations defined in a class or object model –Boils down to testing multiplicity of the association… –This is not based on interaction diagrams: postpone for now… Mode Machine –Shows how to model the aggregate state behavior of a cluster and develop a state-based test suite. –Uses FSM-based techniques (ch 6) yet to be discussed… –Boils down to testing consolidated role state machines Controlled Exception –Shows how to design a test suite that will exercise exception handling –The question is why did we separate these scenarios from others… Round-Trip –Shows how to design a test suite that will cover all event-response paths in a sequence diagram –Use UML sequence diagram with minimal branch and loop coverage. »Worth looking at NOW

L6 - © D. Deugo, 2003 – 2008 Round-Trip Scenario Binder (p.579): “Intent: extract a control flow model from a UML sequence diagram and develop a path set that provides minimal branch and loop coverage.” –Why start with a sequence diagram when it is limited to one collaboration?? –What is minimal branch and loop coverage? Consider fig p.580: –A scenario is a path through an interaction diagram –Several errors can occur: p –One advantage: can apply to instances but also to subsystems… –Drawbacks of UML sequence diagrams pp »Don’t handle repetition, recursion and conditions well… »Typically abstracts away parameters… »Does not distinguish inherited messages »Does not handle polymorphism, nor delayed messages –Which ones are relevant to MSCs?

L6 - © D. Deugo, 2003 – 2008 Flow Graph Path Testing Binder’s Round-Trip pattern: –Translate sequence diagram into a flow chart (p.583) –Identify segments: a conditional action ends a segment –Conditions are limited to true/false paths… –Loop predicates are conditions: while vs repeat… –Identify paths: pp »Could lead to combinatorial explosion –Obtain a test suite that exercises every branch – Every loop must be bypassed, or executed one, executed a maximum number of time. –Simple algorithm p to build a table (p.587) –Deal with special cases: polymorphism + exceptions Do we need to do this? –The table format of fig 12.7 p.587 is useful –UCMs handle the rest better than flowcharts!! »Can we tie the path conditions to instances? Why not? –So should we both doing more specific MSC-based tests?