An Approach for the Semi-automated Derivation of UML Interaction Models from Scenario-based Runtime Tests

Transcription

1 ICSOFT-EA 205 An Approach for the Semi-automated Derivation of UML Interaction Models from Scenario-based Runtime Tests by Thorsten Haendler, Stefan Sobernig, and Mark Strembeck Institute for Information Systems and New Media Vienna University of Economics and Business (WU), Austria

2 Outline Derivation of behavior documentation (in terms of UML System Kaleido under Test Scope interaction models) from runtime UML Interaction UML Sequence Models Diagrams tests selects test-based views Runtime tests reflect exemplary Scenario-Test Stakeholder Specification and intended behavior of the Fig.. Deriving tailored models from scenario-based system under test (SUT). runtime tests. Characteristic structure of scenario-based tests provides an option space for configuring views: resulting in partial models human-tailored for a specific task. Slide 2 Thorsten Haendler, Session 3, ICSOFT-EA 205

3 Structure of the Talk Motivation Conceptual Overview Example System under test (SUT) Scenario-test specification Test-execution trace model Mappings between test and UML Tailored sequence diagrams Option space for tailoring models (scenario-test viewpoint) Prototype implementation KaleidoScope Future Work Summary Slide 3 Thorsten Haendler, Session 3, ICSOFT-EA 205

4 Motivation /2 Behavior documentation, esp. by using graphical models, facilitates communication about and understanding of software systems. Manual creation (and maintainance) is an error-prone and time-consuming task (Rost et al., 203). Multiple approaches exist for reverse-engineering behavioral models automatically from system execution (e.g., UML sequence diagrams: Briand et al., 2003). Problem of model-size explosion (e.g., Sharp and Rountev, 2005; Bennett et al., 2008) Common counter measures are, e.g., techniques of sampling and hiding of model elements (e.g., Hamou-Lhadj and Lethbridge, 2004; Bennett et al., 2008). Slide 4 Thorsten Haendler, Session 3, ICSOFT-EA 205

5 Motivation 2/2 In this approach: We leverage the characteristics of scenario-based runtime tests for deriving tailored interaction models (scenario-test viewpoint) we provide configuration options for the system's stakeholders to fit the models to maintenance tasks (tailoring) test-to-system traceability (behavioral slices) scenarios (e.g., Jacobson, 992): structured stories describing sequences of actions and events scenario-based testing (e.g., Ryser and Glinz, 999): automated execution and verification of scenarios that describe interactions with or within a software system Slide 5 Thorsten Haendler, Session 3, ICSOFT-EA 205

6 Conceptual Overview Fig. 2. Process of deriving tailored UML interaction models from scenario-based runtime tests. specifies develops starts 2 Tester Developer Stakeholder analyses uses System under Test Test Log Test Framework A Trace Provider tests Scenario-Test Specification B Test Run 3 creates Model-to-Model Transformation Scenario-Test Trace Model returns C analyses 8 5 uses sd run2 setup Model-driven approach transformation based on mappings between the metamodels of scenariobased testing and UML2 Semi-automated derivation precond. Sequence Diagram E 4 Diagram Editor testbody postcond. cleanup 7 Model Builder Interaction Model uses selects test-based view 6 D manual selection of views conforming to a scenario-test viewpoint Our prototype implementation KaleidoScope can derive tailored interaction models from scenario-based runtime tests. Slide 6 Thorsten Haendler, Session 3, ICSOFT-EA 205

7 Example /5 A) System under Test (SUT) Stack -limit: Integer [] -element: Double [] +push(e:double): Boolean +pop(): Double +size(): Integer +full(): Boolean -getelements(): Double[] +getlimit(): Integer +setlimit(l:integer) Fig. 3. Exemplary object-oriented system under test (SUT). Slide 7 Thorsten Haendler, Session 3, ICSOFT-EA 205

8 Example 2/5 B) Scenario-Test Specification Exemplary test scenario pushonfullstack Fig. 4b. Natural-language description. Scenario-Test Specification Fig. 4a. Excerpt from test specification. Slide 8 Thorsten Haendler, Session 3, ICSOFT-EA 205

9 Example 3/5 C) Test-Execution Trace Model instance of Scenario-Test Framework.. TestSuite.. TestCase TestScenario checkedagainst 0.. TestResult TestPart ExpectedResult Setup 0.. Precondition Postcondition TestBody Cleanup 0.. Block Structure Block /owning Block Feature +owned Feature Operation Expression +body.. /owned Calls.. +caller +callee +definition FeatureCall +source Property Assertion FeatureCallDefinition {ordered} {ordered} Argument ReturnValue {ord.} +target Instance +definingclass Class +owningclass Trace.. Constructor 0.. Destructor Scenario-Test Traces Fig. 5a. Excerpts from the corresponding test-execution trace model (XMI). Slide 9 Thorsten Haendler, Session 3, ICSOFT-EA 205 Fig. 5b. Test-execution trace meta-model.

10 A definition of source or target instance is mapped to a class Class +owningclass +defining Class class=fc.source.definition or class=fc.target.definition ConnectableElement Example 4/5 D) Mappings between Test and UML +source M2 Instance +target +type Class A source or target instance is mapped to a connectable element represented by a lifeline +repr. Lifeline +cov. +covered instance=fc.source or instance=fc.target M3 Argument transml diagram (Guerra et al., 202) technology- & language-independent and UML compatible Scenario-Test Metamodel Class +owningclassfeaturecall +defining Class +source +caller +callee Instance +target argument=fc.argument M A definition of source or target M4 instance is mapped to a class +type Class A feature call (fc) is mapped to a message Message class=fc.source.definition or +receiveev. ConnectableElement A calling feature is mapped to M2 a message occurrence as A source or target instance is send event mapped to a connectable element represented by a lifeline feature=fc.caller or A called feature is mapped to instance=fc.target a message occurrence as receive event +repr. sendev. +sendev. +covered fragment +start receiveev. M3 Argument Value FeatureCall Execution +caller +callee A feature call (fc) is mapped Message to a message feature=fc.callee and not (feature. oclistypeof (Constructor) or feature. oclistypeof (Destructor)) +signature +receiveev. NamedElement A calling feature is mapped to A called constructor is mapped a message occurrence as to signature and message sort send event +fragment M5 M8 Constructor +argument is neither constructor nor destructor argument=fc.argument is mapped to execution, M4 signature and message sort is mapped to a value An argument feature=fc.callee M7 A called feature that sendev. createm. +sendev. synchcall +event Fig. 6. Excerpt from transml mappings with MessageOccurrence excerpt from feature=fc.caller constructor=fc.callee MessageSort fragment M9 Feature M6 consistency-constraints based on mapping M4. deletem. +start A Acalled feature is mapped to called destructor is mapped +owned Destructor Feature Thorsten Haendler, Session 3, ICSOFT-EA 205 a message as sort to signatureoccurrence and message receive event destructor=fc.callee feature=fc.callee M0 M7 +event Lifeline +cov. MessageOccurrence +owned Feature Slide 0 +argument UML2 Metamodel M6instance=fC.source Feature mappings refined by constraints Test2UML M5 class=fc.target.definition in total, 8 mappings (2 for traces, 6 viewpoint mappings) Value An argument is mapped to a value receiveev.

11 Example 5/5 E) Resulting Tailored UML Sequence Diagrams Fig. 7. Exemplary stakeholders/tasks and derived diagrams. sd pushonfullstack test scenario :TestDriver :Stack setlimit(2) test engineer / test review setup size() 2 getlimit() 2 test scenario pushonfullstack preconditions push(.4) false test body size() 2 postcond. sd pushonfullstack test body :TestDriver :Stack 2 push(.4) full() getlimit() 2 size() getelements() system developer / after code modification Slide calls running from STF to SUT Thorsten Haendler, Session 3, ICSOFT-EA 205 false [3.5, 4.3] 2 true calls running from STF to SUT and SUT internal calls test body of test scenario pushonfullstack

12 Scenario-Test Viewpoint - Structure of Scenario-based Tests Characteristics of scenario-based testing: Scenario-test parts (test suite, test case, test scenario, as well as assertion and exercise blocks) Feature-call scopes (calls running from STF to SUT, calls internal to the SUT, and calls internal to the STF) A view stipulates elements to be selected or not resulting in partial interaction models human-tailorable for a specific task. All views conform to a viewpoint (see, e.g., Clements et al., 20). Slide 2 Thorsten Haendler, Session 3, ICSOFT-EA 205

13 Option Space for configuring views STF intern. STF to SUT SUT intern. sp. test scenario cleanup postcond. test body pushonfullstack precond. cleanup postcond. pushelement precond. stacktest setup sp. test case cleanup call scopes contains one or many t. suite setup test parts contains one or many setup multiple test runs 2 For the resulting derived diagrams corresponding to the configurations and 2, see slide. Fig. 8. Option space for configuring different views conforming to a scenario-test viewpoint. Slide 3 Thorsten Haendler, Session 3, ICSOFT-EA 205

14 KaleidoScope /3 - Derivation Process KaleidoScope Software Engineer STORM Scenario-test System specification Write system and scenario tests Run test System Scenario-test specification Test log Runtime data Visual Diagram Editor Trace Provider Model Builder Runtime data Build trace model Trace model View model Instrumenting the test framework and extracting executiontrace data Trace model Build interaction model Select view Interaction model View model Sequence diagram Interaction model Render diagram Analyse diagram Sequence diagram Transforming view and trace models to interaction models [more [finish] diagrams] Fig. 9. Process of deriving tailorable UML-based software-behavior documentation with KaleidoScope. Available for download from our website Slide 4 Thorsten Haendler, Session 3, ICSOFT-EA 205

15 KaleidoScope 2/3 - Used Technologies A Test Framework: Scenario-based Testing of ObjectOriented Runtime-Models (STORM) (Strembeck, 20) Instrumentation: NX/Tcl (object-oriented extension of Tcl) provides introspection techniques (see Neumann and Sobernig, 205): message interceptors (Mixin and Filter) extraction of trace data by using callstack introspection (e.g., nx::current) and structural introspection (e.g., info method) Slide 5 Thorsten Haendler, Session 3, ICSOFT-EA 205

16 KaleidoScope 3/3 - Used Technologies B Trace and view models are transformed to UML interaction models by using Query View Transformation operational (QVTo) mappings (in total 24 mapping actions). All models are stored and processed in their Ecore/XMI representation, which makes it possible to import the models via XMI-compliant diagram editors (e.g., Eclipse Papyrus). Slide 6 Thorsten Haendler, Session 3, ICSOFT-EA 205

17 Future Work Derivation of other model types structure models (e.g., UML class models) component-based architecture documentation (e.g., inter-component interactions) Extension of prototype integration of other filtering/abstraction techniques (e.g., constructor hiding, identification of loops) instrumenting other testing frameworks (e.g., JBehave using AspectJ) Application in large-scale projects usability for stakeholders/tasks Slide 7 Thorsten Haendler, Session 3, ICSOFT-EA 205

18 Summary Model-driven and semi-automated derivation of behavior documentation (in terms of UML2 interaction models) Scenario-test viewpoint (different views on the testexecution trace available for configuration) Prototype implementation KaleidoScope (proof of concept) Slide 8 Thorsten Haendler, Session 3, ICSOFT-EA 205

19 Thank you for your attention! Q&A Slide 9 Thorsten Haendler, Session 3, ICSOFT-EA 205