ICSOFT-EA 2015 An Approach for the Semi-automated Derivation …refactoringgames.com/publications/icsoft-2015-slides.pdf · 2019. 4. 8. · instrumenting other testing frameworks
Post on 19-Apr-2021
1 Views
Preview:
Transcript
ICSOFT-EA 2015
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
thorsten.haendler@wu.ac.at
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 2
Outline
Derivation of behavior documentation (in terms of UML interaction models) from runtime tests
Runtime tests reflect exemplary and intended behavior of the system under test (SUT).
Characteristic structure of scenario-based tests provides an option space for configuring views:
resulting in partial models →human-tailored for a specific task.
KaleidoScope
System under Test
UML Sequence Diagrams
Scenario-Test Specification
UML Interaction Models
Stakeholder
selects test-based views
Fig. 1. Deriving tailored models from scenario-based runtime tests.
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 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
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 4
Motivation 1/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., 2013).
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).
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 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, 1992): structured stories describing
sequences of actions and events scenario-based testing (e.g., Ryser and Glinz, 1999):
automated execution and verification of scenarios that describe interactions with or within a software system
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 6
Conceptual Overview
developsuses
TesterDeveloper
Stakeholder
selects test-based view
System under Test
Test Framework
Scenario-Test Specification
Trace Provider
Interaction Model
Sequence Diagram
setup
sd run2
precond.
postcond.
testbody
cleanup
Test Run
Model Builder
Scenario-Test Trace Model
Diagram Editor
TestLog
tests
creates
uses
uses
analyses
analyses returns
1
starts
2
3
4
5
67
8
specifies
Model-to-Model Transformation
1
Fig. 2. Process of deriving tailored UML interaction models from scenario-based runtime tests.
Model-driven approach
transformation based on mappings between the metamodels of scenario-based testing and UML2
Semi-automated derivation
manual selection of views conforming to a scenario-test viewpoint
Our prototype implementation KaleidoScope can derive tailored interaction models from scenario-based runtime tests.
A B
C
DE
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 7
Example 1/5A) System under Test (SUT)
Fig. 3. Exemplary object-oriented system under test (SUT).
Stack-limit: Integer [1]-element: Double [*]
+push(e:Double): Boolean+pop(): Double+size(): Integer+full(): Boolean-getElements(): Double[]+getLimit(): Integer+setLimit(l:Integer)
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 8
Example 2/5B) Scenario-Test Specification
Scenario-Test Specification
Fig. 4a. Excerpt from test specification.
Fig. 4b. Natural-language description.
Exemplary test scenario pushOnFullStack
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 9
Example 3/5C) Test-Execution Trace Model
Fig. 5a. Excerpts from the corresponding test-execution trace model (XMI).
1
1..* 1..*
*
+definition1
11
TestSuite TestCase TestScenario
TestPart TestResult ExpectedResult
Setup Precondition TestBody Postcondition Cleanup
Block AssertionExpression FeatureCallDefinition
+target1
*+callee1 * *
+source1
11
*+caller1
Class
Feature FeatureCall
Instance
ReturnValueArgument
Trace
0..1
0..1
checkedAgainst
{ordered}
{ordered}
/owning Block
/owned Calls
0..1
*1..*
0..1
0..1 0..1 0..1 0..1
+body1..*
1..*
Operation Property
Constructor Destructor
+owningClass1
*+owned Feature
0..1
+definingClass
1
{ord.}
0..11..*
Scenario-Test Framework
Scenario-Test Traces
Block Structure
Fig. 5b. Test-execution trace meta-model.
instance of
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 10
Example 4/5D) Mappings between Test and UML
transML diagram (Guerra et al., 2012) technology- & language-independent and UML compatible
in total, 18 mappings (12 for traces, 6 viewpoint mappings)
mappings refined by OCL constraints
1
OCLinstance=fC.source or instance=fC.target
Scenario-Test Metamodel
UML2 Metamodel Test2UML
Argument
FeatureCall
Feature
Instance
Class
Value
Message
MessageOccurrence
ConnectableElement
Lifeline
Class
+argument
+receiveEv.1
+event*
+cov.1
+repr.1
+type1
+callee1
+target1
1
1 1
1
* *
+owningClass
1
*
+owned Feature
NamedElement
Execution
MessageSort
+start
sendEv.
receiveEv.
synchCall
deleteM.
createM.
+source
1
*
**
*
+caller1
+sendEv.1
1
+signature
1
Trace Interaction
*
fragment*
*
*
*
+fragment*
Constructor
Destructor
*
+covered1
M1
M2
M4
M5
M6
M7
M8
A definition of source or target instance is mapped to a class
A source or target instance is mapped to a connectable element represented by a lifeline
A feature call (fC) is mapped to a message
A calling feature is mapped to a message occurrence as send event
A called feature is mapped to a message occurrence as receive event
A called feature that is neither constructor nor destructor is mapped to execution, signature and message sort
A called constructor is mapped to signature and message sort
M9
M10
A called destructor is mapped to signature and message sort
A trace is mapped to an interaction
M3An argument is mapped to a value
1
OCLclass=fC.source.definition or class=fC.target.definition
OCLargument=fC.argument
OCLfeature=fC.caller
OCLfeature=fC.callee and not (feature. oclIsTypeOf (Constructor) or feature. oclIsTypeOf (Destructor))
OCLconstructor=fC.callee
OCLfeature=fC.callee
OCLdestructor=fC.callee
+defining Class
*
1
OCLinstance=fC.source or instance=fC.target
Scenario-Test Metamodel
UML2 Metamodel Test2UML
Argument
FeatureCall
Feature
Instance
Class
Value
Message
MessageOccurrence
ConnectableElement
Lifeline
Class
+argument
+receiveEv.1
+event*
+cov.1
+repr.1
+type1
+callee1
+target1
1
1 1
1
* *
+owningClass
1
*
+owned Feature
NamedElement
Execution
MessageSort
+start
sendEv.
receiveEv.
synchCall
deleteM.
createM.
+source
1
*
**
*
+caller1
+sendEv.1
1
+signature
1
Trace Interaction
*
fragment*
*
*
*
+fragment*
Constructor
Destructor
*
+covered1
M1
M2
M4
M5
M6
M7
M8
A definition of source or target instance is mapped to a class
A source or target instance is mapped to a connectable element represented by a lifeline
A feature call (fC) is mapped to a message
A calling feature is mapped to a message occurrence as send event
A called feature is mapped to a message occurrence as receive event
A called feature that is neither constructor nor destructor is mapped to execution, signature and message sort
A called constructor is mapped to signature and message sort
M9
M10
A called destructor is mapped to signature and message sort
A trace is mapped to an interaction
M3An argument is mapped to a value
1
OCLclass=fC.source.definition or class=fC.target.definition
OCLargument=fC.argument
OCLfeature=fC.caller
OCLfeature=fC.callee and not (feature. oclIsTypeOf (Constructor) or feature. oclIsTypeOf (Destructor))
OCLconstructor=fC.callee
OCLfeature=fC.callee
OCLdestructor=fC.callee
+defining Class
*
Fig. 6. Excerpt from transML mappings with excerpt from OCL consistency-constraints based on mapping M4.
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 11
Example 5/5E) Resulting Tailored UML Sequence Diagrams
push(1.4)
false
full()
getLimit()
2size()
true
:Stack
getElements()
[3.5, 4.3]
2
test bodysd pushOnFullStack
:TestDriver
:Stack
sd pushOnFullStack
size()
getLimit()
size()
2
2
2
setLimit(2)
test
:TestDriver
setup
scenario
preconditions
push(1.4)false
postcond.
test body
1
2
• calls running from STF to SUT
• calls running from STF to SUT and SUT internal calls
• test scenario pushOnFullStack
• test body of test scenario pushOnFullStack
test engineer /test review
system developer /after code modification
Fig. 7. Exemplary stakeholders/tasks and derived diagrams.
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 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., 2011).
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 13
Option Space for configuring views
t. suite sp. test case
setu
p
cleanup
setu
p
pre
cond.
post
cond.
cleanup
stackTest pushElement
sp. test scenario
test
body
setu
p
pre
cond.
post
cond.
cleanup
pushOnFullStack
STF to SUT
SUT intern.
STF intern.
test parts
callscopes
✓ ✓ ✓ ✓✓
1
2
contains one or many
contains one or many
multiple test runs
Fig. 8. Option space for configuring different views conforming to a scenario-test viewpoint.
For the resulting derived diagrams corresponding to the configurations 1 and 2, see slide 11.
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 14
KaleidoScope 1/3- Derivation Process
Interaction model
System
Sequence diagram
Select view
Scenario-test
Scenario-testspecificationSystem
Test log Runtime
Sequence diagram
Software Engineer
KaleidoScope
Run test
Render diagram
Write system and scenario tests
Build interaction model
Analyse diagram
[more diagrams]
[finish]
Build trace model
STORM Trace Provider Model BuilderVisual Diagram
Editor
data
Runtime data
Trace model
Interaction
specification
View modelTrace model
model
View model
Instrumenting the test framework and extracting execution-trace data
Transforming view and trace models to interaction models
Fig. 9. Process of deriving tailorable UML-based software-behavior documentation with KaleidoScope.
Available for download from our website http://nm.wu.ac.at/nm/haendler
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 15
KaleidoScope 2/3- Used Technologies A
Test Framework: Scenario-based Testing of Object-Oriented Runtime-Models (STORM) (Strembeck, 2011)
Instrumentation: NX/Tcl (object-oriented extension of Tcl) provides introspection techniques (see Neumann and Sobernig, 2015):
→ message interceptors (Mixin and Filter)
→ extraction of trace data by using
callstack introspection (e.g., nx::current) and structural introspection (e.g., info method)
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 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).
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 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
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 18
Summary
Model-driven and semi-automated derivation of behavior documentation (in terms of UML2 interaction models)
Scenario-test viewpoint (different views on the test-execution trace available for configuration)
Prototype implementation KaleidoScope (proof of concept)
Thorsten Haendler, Session 3, ICSOFT-EA 2015Slide 19
Thank you for your attention!
Q&A
top related