A test generator for model-based testing · A Test Generator for Model-Based Testing Ella...
11
A test generator for model-based testing Citation for published version (APA): Roubtsova, E. E., & Roubtsov, S. (2014). A test generator for model-based testing. In B. Shishkov (Ed.), 4th International Symposium on Business Modeling and Software Design (BMSD 2014) , 24-26 June, 2014 Luxembourg, Grand Duchy of Luxembourg, (pp. 103-112). SCITEPRESS-Science and Technology Publications, Lda.. Document status and date: Published: 01/01/2014 Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: • A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal. If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement: www.tue.nl/taverne Take down policy If you believe that this document breaches copyright please contact us at: [email protected] providing details and we will investigate your claim. Download date: 08. Jul. 2020
Transcript of A test generator for model-based testing · A Test Generator for Model-Based Testing Ella...
A test generator for model-based testing
Citation for published version (APA):Roubtsova, E. E., & Roubtsov, S. (2014). A test generator for model-based testing. In B. Shishkov (Ed.), 4thInternational Symposium on Business Modeling and Software Design (BMSD 2014) , 24-26 June, 2014Luxembourg, Grand Duchy of Luxembourg, (pp. 103-112). SCITEPRESS-Science and Technology Publications,Lda..
Document status and date:Published: 01/01/2014
Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)
Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne
Take down policyIf you believe that this document breaches copyright please contact us at:[email protected] details and we will investigate your claim.
Download date: 08. Jul. 2020
A Test Generator for Model-Based Testing
Ella Roubtsova1 and Serguei Roubtsov2
1Open University of the Netherlands2Technical University Eindhoven, The Netherlands
[email protected], [email protected]
Keywords: Model Based Testing, Test Generator, Case Management Solutions.
Abstract: The idea of software testing by software itself drives the attempts of creation of model based testing ap-proaches. Model based testing relies on models, that encode the desired behaviour of a system, the relevantbehaviour of its environment; however, both the static and the behaviour models are not directly applicablefor model based testing. The models should be different from implementation and possess the observationalconsistency allowing preservation behaviour of parts in the behaviour of the whole. The models need to bebuilt into a tool for preparation of the model and data for test generation. This paper proposes to use protocolmodels for model based testing. A protocol model presents the external behaviour. Unlike other modellingapproaches, the Protocol Modelling semantics incorporates data into the model. This property gives us advan-tages for the choice of the strategy of test generation. The main contribution of the paper is a combination ofalgorithms for test generating from a protocol model. The preparation of a protocol model for test generationand the results of test generation are illustrated with an example.
1 INTRODUCTION
What is a software test? It is a procedure or a se-quence of actions that allows one to prove that thesoftware meets the requirements. A test may comefrom requirements directly or may be generated (Fig-ure 1) from a model different from the implementa-tion model, as it is suggested in the UML test pro-file (UML, 2005).
Requirements ModelSystem
Under Test
Test
Case
Test
Script
Test
Selection
Verdict
FeedbackFeedback
Feedback
Figure 1: Model-Based Testing.
Development of a dedicated test generation modelis often considered by system developers as unnec-essary overhead, unless the model provides obviousreduction of testing effort. The choice of a behaviourmodelling method with right properties facilitates re-duction of testing effort and simplifies further systemmaintenance.
The right properties of the modelling method de-pend on the application domain. In this paper, wefocus on the domain of Case Management Solutions
(CMS), that covers the systems that “coordinate a ser-vice request in finance, health, legal, citizen or humanresources-related matters, on behalf of a subject suchas a customer, a citizen, or an employee” (Davenportand Nohria, 1994; Aalst van der and Weske, 2005).The domain of Case Management Systems (CMSs)has been defined in an OMG document. ”A Case isa proceeding that involves actions taken regarding asubject in a particular situation to achieve a desiredoutcome... Case management planning is typicallyconcerned with determination of which Tasks are ap-plicable, or which follow-up Tasks are required, giventhe state of the Case. Decisions may be triggered byevents or new facts that continuously emerge duringthe course of the Case, such as the receipt of newdocuments, completion of certain Tasks, or achievingcertain Milestones. Individual Tasks that are plannedand executed in the context of the Case might be pre-defined procedural Processes in themselves, but theoverall Case cannot be orchestrated by a predefinedsequence of Tasks. Representation of the circum-stances and the decision factors in a Case model re-quires references to data about the subject of the Case.Modeling of constraints and guidance on the actionsto be taken in a Case requires the specification of rulesthat reference the data in the CaseFile.... A new Casemodel may be defined as entirely at the discretion of
103
human participants initially, but it should be expectedto evolve as repeatable patterns and best practicesemerge.” (OMG, 2013) A CMS supports communica-tion of the system with different business actors. Thesystem reaction to the requests of actors is determinis-tically defined by business rules. It should not containimplementation details. Business rules are formulatedusing visible states of the system expressed with data.Therefore, the behaviour modelling method should(1) result in a deterministic models,(2) present only visible system states and(3) enable expressions with relevant data and datatransformation.The distinguished property of these systems is the fre-quent need of change and subsequent testing due tothe changes of law regulations and business optimiza-tion. Modelling approaches which facilitate indepen-dent modelling of a change and its composition withthe old model can reduce modelling and testing effort.
In this paper, we address the problem of model-based testing of CMSs. First, we analyse the mod-elling techniques in order to select the one that isthe most suitable for CMSs. Second, we propose amethod of using the chosen modelling technique fortest generation and the corresponding algorithms.
2 MODELLING APPROACHESTO MODEL-BASED TESTING
The first research question that we answer in the paperis: Is there a modelling approach most suitable to thedomain of Case Management Systems?
We start our analysis with the approaches stan-dardised in the UML (OMG, 2003).
2.1 Modelling Approaches in the UML
Use Cases are used to describe the scenarios of inter-actions between the system and the environment. UseCases are presented in a combination of the naturallanguage and informal diagrams. The informal andpartial use case does not cover system requirements,does not use data, does not support the compositionof models.
Interaction Diagrams (Sequence Diagrams andCommunication Diagrams) can be used to express in-teraction of communicating objects during their life-time. Normally, one such diagram presents one se-quence of interaction. If decision points are used, aninteraction diagram can present a restricted numberof sequences. A set of interaction diagrams usuallypresents only a subset of possible sequences. Com-position of interaction diagrams is not defined in the
UML. The suggestions for ”mechanical” composi-tion (Roubtsova and Kuiper, 2003; Greenyer et al.,2008; Hanenberg et al., 2007) do not guarantee thespecification of complete behaviour.
Activity Diagrams provide a flow based model-ing medium, similar to Petri Nets (Petri and Reisig,2008). They are used to show “the sequence andconditions for coordinating behaviors” rather than be-haviours of objects. (OMG, 2003). This means thatActivity Diagrams are not suitable for representingthe behavior of an object model and, as a conse-quence, the separate modelling of requirements is notalways possible.
State Machines exist in two variants: BehavioralState Machines (BSM) and Protocol State Machines(PSM) (OMG, 2003).
A Behavior State Machine usually presents behav-ior of one class. “Behavior is modeled as a traversalof a graph of state nodes interconnected by one ormore joined transition arcs that are triggered by thedispatching of series of (event) occurrences. Duringthis traversal, the state machine executes a series ofactivities associated with various elements of the statemachine.” (OMG, 2003) A transition label e[g]/a in-cludes an event e that triggers the transition, a guardg that restricts the condition of a transition firing andthe action a that happens if the transition takes place.The composition semantics for BSMs defines an eventqueue which holds the incoming event instances un-til they are dispatched, an event dispatcher mecha-nism that selects event instances from the queue, andan event processor which processes dispatched eventinstances according to the general semantics of theUML state machines. Event instances being results ofsome actions within the system or in the environmentare conveyed to one or more BMSs (OMG, 2003). Anevent is received by a BMS if it is placed on the eventqueue of the BMS. An event is dispatched when it isremoved from the queue and delivered to the state ma-chine for processing. If an event is dispatched, it mayresult in one or more transitions. If no transition isenabled, then the event is discarded. Finally the eventis consumed and it is no longer available for process-ing. The consumption of events depends on the activestate of a state machine. If an event triggers a tran-sition in the current state, it is dispatched and con-sumed. “A state may specify a set of event types thatmay be deferred in the state. An event instance thatdoes not trigger any transition in the current state willnot be dispatched if its type matches with the typeof one of the deferred events. Instead it remains inthe event queue while another not deferred messageis dispatched instead” (OMG, 2003). In other words,
• if an event recognized by a machine that enables
Fourth International Symposium on Business Modeling and Software Design
104
a transition in its current state, then it can be con-sumed;
• if an event recognized by a machine that does notenable a transition in the current, an this event isincluded in the list of deferred events for this state,it is kept in a queue for later processing;
• otherwise the event is discarded (McNeile andRoubtsova, 2009).
This means that processing of an event by differentmachines is asynchronous and the result of processingis non-deterministic. If an event can cause firing oftwo transitions, which transition can happen first isnot defined.
Thus, BSMs do provide complete behavior de-scriptions and can provide model based executionneeded for MBT. However, BSM do not result in de-terministic models and do not meet our requirementsfor the modelling method for MBT of CMS.
The UML Protocol State Machines (PSMs) areused to express the transitions that a classifier can trig-ger. A PSM is a way to define a life cycle of an ob-ject, or an order of the invocation of its operations.PSMs can express usage scenarios of object classesand interfaces. The effect actions of transitions arenot specified in a PSM transition as the trigger itselfis the operation. However, pre- and post- conditionsare specified, so that the label of a transition is ofthe form [precondition] event/ [postcondition]. Theoccurrence of an event that a PSM cannot handle isviewed as a precondition violation, but the consequentbehavior is left open. “The interpretation of the recep-tion of an event in an unexpected situation (currentstate, state invariant, and pre-condition) is a semanticvariation point: the event can be ignored, rejected, ordeferred; an exception can be raised; or the applica-tion can stop on an error. It corresponds semanticallyto a pre-condition violation, for which no predefinedbehavior is defined in UML” (OMG, 2003). UnlikeBSMs, PSMs can (to a limited extent) be composed.“A class may have several protocol state machines.This happens frequently, for example, when a classinherits several parent classes having protocol statemachine, when the protocols are orthogonal.” (OMG,2003). However, the semantics of composition forPSMs is undefined.
As a result of the above analysis we conclude thatnone of the UML behaviour modelling approaches aresatisfying enough to meet the requirements to mod-elling Case Management Systems.
2.2 Outside the UML
The MBT approaches often experiment with labeledtransition systems with different semantics. For ex-
ample, the Labelled Transition Systems (LTSs) usedby Kervinen at al. (Kervinen et al., 2006) (s0,S,E,T )( s0 is an initial state; S - a set of states; E is a setof events; T ⊆ S×E × S) is a deterministic model.There is no state in which any output transition sharethe same action name. The LTSs can be composed us-ing the CSP parallel composition (Hoare, 1985). Alsothere are rules of matching events that are used forsynchronous composition.
LTSs used by Kervinen at al. (Kervinen et al.,2006) meet most of our requirements to the modellingmethod for CMS. Such LTSs are able to provide thebasis of MBT implementation. The shortcoming istheir abstraction from data.
The Protocol Modelling technique (McNeile andSimons, 2006) overcomes the above mentioned short-comings of LTSs. Protocol Modelling uses the CSPparallel composition (Hoare, 1985) extended by A.McNeile to enable the composition of models withdata (McNeile and Simons, 2006). It is provenin (McNeile and Roubtsova, 2008) that protocol mod-els possess the property called observational consis-tency. This property means that a protocol machinemay be added to and deleted from the model or lo-cally changed and the trace behaviour of other proto-col machines is not affected by the behaviour of of theadded, deleted or modified protocol machines (Mc-Neile and Roubtsova, 2008). We argue that, poten-tially, observational consistency of protocol modelscan reduce the modelling and testing effort when theCMS is changed.
3 PROTOCOL MODELLING FORMBT
Our second research question is: How can a protocolmodel be used for test generation?
3.1 What is a Protocol Model?
The building blocks of a Protocol Model are proto-col machines and events. They are instances of corre-spondingly protocol machine types and event types.
A protocol machine type is an LTS extended toenable modelling with data:
PMi = (s0i ,Si,Ei,Ai,CBi,Ti), where
• s0i is the initial state;
• Si is a non-empty finite set of states.
• Ei is a finite set of recognized event types ei, com-ing from the environment.
A Test Generator for Model-Based Testing
105
• Ai is a finite set of attributes of different types.The set can be empty.
• CBi(PM1, ...,PMn,E1, ...,Em) =
(PM1, ...,PMn,E1, ...,Em)
is a callback function for updating the values ofthe attributes, states and events of the protocolmachines of the protocol model. PM1, ...,PMnare the protocol machines of the protocol model.E1, ...,Em are events of the protocol model. Thedefault callback function (the absence of the call-back) does not change the model elements.
• Ti ⊆ Si×Ei×Si a finite set of transitions:t = (sx,e,sy), sx,sy ∈ Si, e ∈ Ei. The set of tran-sitions can be empty. The states may be updatedwithout callback functions. The values of the at-tributes, states and events may be updated usingthe callback function only as a result of a transi-tion, i.e. as a result of an event acceptance.
In order to facilitate reuse, protocol machinescome in two variants: Objects and Behaviours. Be-haviours cannot be instantiated on their own but mayextend functionality of objects. In a sense, objectswith included behaviours are similar to mixins inprogramming languages (Bracha and Cook, 1990).
An event type is a tuple
e = (EventName,Ae,CBe)
• Ae is a finite set of attributes of the event.
• CBe(PM1, ...,PMn,E1, ...,Em) =
(PM1, ...,PMn,E1, ...,Em)
is a callback function corresponding to this event.A default callback function (the absence of it)does not changes the model elements. The call-back function for an event is used if the event cal-culates attributes of generates other events fromthe state of the model.
An example of a protocol model is shown in Fig-ure 2. It is a model of a small case managementsystem for handling a document. Unique documentparts are submitted to a document. When all partshave been submitted, the document can be submit-ted. to a document by participants of a project. Thereare four protocol machines in Figure 2: OBJECTPart with included BEHAVIOUR Duplicate Checkand OBJECT Document with included BEHAVIOURDocument Submittable. The protocol machines aredescribed textually as sets of their attributes, statesand transitions. A behaviour protocol machine is al-ways included into at least one object protocol ma-chine. The INCLUDES relation is shown on the topof Figure 2 graphically as an arc with a half-dashed
submitted
Create Part Submit Part
Part
created
Create Doc
DocumentCreate Part,
Submit Part
createsunique
Create Part
Duplicate Check
public class DuplicateCheck extends Behaviour {
public String getState() {
String myName=getString("Name");
Instance[] existingIns = this.selectInState(this.getObjectType(), "@any");
for (int i = 0; i < existingIns.length; i++)
if (existingIns[i].getString("Name").equals(myName) &&
!existingIns[i].equals(this))
return "duplicate";
return "unique";
}
}
public class DocumentSubmittable extends Behaviour {
public String getState() {
boolean allSubmitted =true;
Instance[] myParts = this.selectByRef("Part", "Document");
if (myParts.length==0)
{allSubmitted = false;}
for (int i = 0; i < myParts.length; i++) {
if ((myParts[i].getState("Part").equals("created")))
allSubmitted = false;
}
return allSubmitted ? "submittable" : "not submittable";
}
public String getDocumentStatus() {
return this.getState("DocumentSubmittable");
}
}
OBJECT Part
NAME Name
INCLUDES Duplicate Check
ATTRIBUTES Name: String,
STATES created ,submitted
TRANSITIONS @new* Create Part= created,
created*Submit Part=submitted
BEHAVIOUR !Duplicate Check
STATES unique, duplicate
TRANSITIONS @any*Create Part=unique
OBJECT Document
NAME Name
INCLUDES DocumentSubmittable
ATTRIBUTES Name:String,
STATES created, submitted, cancelled
TRANSITIONS @new*CreateDoc=created,
created*CreatePart=created,
created*SubmitDoc=submitted
BEHAVIOUR !DocumentSubmittable
# Ensures that a document cannot be
#submitted if it has unfinished Parts
ATTRIBUTES !Document Status: String
STATES submittable, not submittable
TRANSITIONS submittable*SubmitDoc=@any
EVENT Create Part
ATTRIBUTES
Part: Part,
Name: String,
Document: Document
EVENT Submit Part
ATTRIBUTES
Part :Part,
Document: Document
EVENT CreateDoc
ATTRIBUTES
Document:Document,
Name:String,
EVENT SubmitDoc
ATTRIBUTES
Document: Document,
submittable
Submit
Doc
Document
Submittable
submitted
Submit Doc
Figure 2: Protocol Model of a Document that consists ofParts.
arrowhead. Each of behaviours has the correspondingcallback presented as a small Java function. The call-back of the behaviour Duplicate check returns statesunique or duplicate. The callback of the behaviourDocument Submittable returns the state submittable,not submittable. There are four event types in themodel presented with their attributes: Create Part,Create Doc, Submit Part and Submit Doc.
3.2 Data Handling and Its Use for MBT
Within the Protocol Modelling, the callback functionsare the instruments for data handling. In the Mod-elScope tool (McNeile and Simons, 2000) supportingexecution of protocol models, the callbacks are codedas small Java classes with methods changing and/orreturning the values of attributes and states of in-
Fourth International Symposium on Business Modeling and Software Design
106
stances of protocol machines. They may also changeattributes of events and generate event instances.
Usually transitions t ∈ Ti of a protocol machinePMi enable updates of its own states of the state setSi. On the other hand, protocol machines can readthe states of each other, although cannot change them.This property creates dependencies of protocol ma-chines. The dependency means that one protocol ma-chine needs to read the state of another machine tocalculate its own state and/or the attributes. Such cal-culated states are called derived states, which distin-guishes them from the ”stored” states denoted in themodel (McNeile and Simons, 2006). Callback func-tions CBi are used to update attributes and calculatederived states.
There are two possibilities in dependent machines:(1) The pre-state of a transition can be calculated. Thepre-state is similar to a guard calculated in the UMLstate machines. BEHAVIOUR Document Submittableis an example of a pre-state.(2) The predicted after-state of a transition can becalculated and used to allow or refuse the event.This predicted after-state is a unique feature of Pro-tocol modelling. Both behaviour protocol machinesin Figure 2 have the after-states. For example, BE-HAVIOUR Duplicate Check derives state unique orduplicate after event CreatePart and enables the eventonly if the Part has a unique name. If an event is notenabled, the protocol machine is rolled back to theprevious state of the model.
As the state of a dependent machine is changedby the corresponding callback, not by a transition,the dependency between protocol machines needs tobe taken into account for test generation. Using theinformation in the callbacks, the derived states of aprotocol machine can be visualised in the model withthe corresponding stored states with the same names.The state changes, coded in the callbacks, can be pre-sented as transitions. The transformed in such a wayprotocol machines with derived states, are called con-nected forms (McNeile and Roubtsova, 2012). Theyhave been used for workflow analysis of protocolmodels. We propose to use them for test generation.Currently, we perform the model transformation as amanual procedure.
For example, the callback Duplicate Check ex-tends behaviour BEHAVIOUR Duplicate Check.
The state duplicate may appear during the pro-ceeding of event CreatePart but it should be rolledback. This means that there is no continuation of thetest possible with the duplicated Part. In such a situa-tion, the ModelScope tool generates an error message.The working protocol model of BEHAVIOUR Dupli-cate Check contains only one transition (Figure 2).
BEHAVIOUR !DuplicateCheck
STATES unique, duplicate
TRANSITIONS @any*CreatePart=unique,
Using the information from the callback we createthe connected form being a non-deterministic proto-col machine intended to be used for test generation. Itcontains two transitions for event CreatePart and thethird transition for the event SubmitPart possible onlyin state unique:BEHAVIOUR !DuplicateCheck
STATES unique, duplicate
TRANSITIONS @any*CreatePart=unique,
@any*CreatePart=duplicate,
unique*SubmitPart=unique
3.3 Analysis of CSP ParallelComposition and It Use for MBT
Another observation concerns the use of the CSPcomposition.
A protocol model contains only the protocol ma-chine types serving as patterns for creating instancesof protocol machines. In the initial state, a protocolmodel PM is a CSP parallel composition of the pro-tocol machines each of which corresponds to a pro-tocol machine type in the initial state @new. The in-stances of protocol machines of each type are createdas a result of an acceptance of an event that transitsthe machine from the state @new to some state of themachine life cycle.
In any state, a system model PM is a CSP paral-lel composition of finite set of instances of protocolmachines.
nPM = ‖PMi = (s0,S,E,A,CB,T ), n ∈ N.
i = 1
A Protocol Model PM is also a protocol machine,the set of states of which is the Cartesian product ofstates of all composed protocol machines (McNeileand Simons, 2006):
ns0 =
⋃s0
i is the initial state;i = 1
nS = ∏Si is the set of states;
i = 1n
E =⋃
Ei is the set of events;i = 1n
A =⋃
Ai is the set attributes of all machines;i = 1
nCB =
⋃CBi is the set of callbacks of all machines.
i = 1
A Test Generator for Model-Based Testing
107
The set of transitions T of the protocol model isdefined by the rules of the CSP parallel composi-tion (Hoare, 1985). The rules synchronise transitionsTi of protocol machines. Namely, a Protocol Modelhandles only one event at a time. An event can be ac-cepted only if all protocol machines having this eventin their alphabets are in the state where they can ac-cept this event. Otherwise the event is refused.
As a protocol machine can contain several in-stances of a certain type, tests should be able to dif-ferentiate them. This is possible since each OBJECThas a NAME attribute by which it can be identified. Inour example in Figure 2 all events have only one linkto object Part. This means that only one instance isused.
Similarly, any BEHAVIOUR can be included inseveral objects. In such cases the corresponding ob-ject model contains INCLUDES statement (see Figure2) with the name of included BEHAVIOUR type. Al-though BEHAVIOUR does not have a NAME attribute,it can be uniquely identified in tests by the NAME at-tribute of the host OBJECT.
4 TEST GENERATION
Our proposed Protocol Model Based test generationtechnique consists of the following steps:- Creation of object models for all individual protocol ma-chines;- Iterative generation of the System Protocol Machine, us-ing the CSP composition;- Generation of test traces for the system protocol machine.
4.1 Creation of Object Models forIndividual Protocol Machines
Our test generation starts with building object modelscontaining all such ’first class’ model elements as pro-tocol machines (objects and behaviours), events andcallbacks as well as their attributes, states, transitions.These models are built by parsing the system protocolmodel textual representations in Figure 2.
4.2 Iterative Generation of the SystemProtocol Machine
The fact that the CSP parallel composition of protocolmachines is a protocol machine allows us to imple-ment the iterative algorithm for generating the systemprotocol machine from the models of objects and be-haviours obtained at the first step (Algorithm 1).
Algorithm 1: Algorithm for CSP parallel composition ‖ ofall protocol machines.
GIVEN:Set of Protocol machines from the protocol model{PMi}, i = 0, ...nRESULT: CSP parallel composition of all protocol machines ofthe protocol model SystemPM = ‖PMi i = 0, ...nAlgorithm:SystemPM = PM0i = 1while (i <n) do
Algorithm 2 for CSP composition ‖ of two Protocol Ma-chines
SystemPM = SystemPM‖PMii++
end while
Algorithm 2: Algorithm for CSP composition ‖ of two Pro-tocol Machines.
GIVEN:Object (behaviour) O1 :Transitions O1 : xi ∗A = x j. Set of events E1. Set of states S1.Object (behaviour) O2 :Transitions O2 : yk ∗A = xh. Set of events E2. Set of states S2.RESULT: CSP parallel composition O1‖O2.Algorithm:Find E1 ∩E2.for Each e ∈ E1 ∩E2 do
Find transitions of O1 : O1.xi ∗ e = O1.x j , labeled by e.Find transitions of O2 : O2.yk ∗ e = O2.yh, labeled by e.Construct the transition of the composition of O1‖O2 :O1.xi;O2.yk ∗ e = O1.x j;O2.yh.Add the initial and end states of the transition to the set of
states of O1‖O2.Add e to the set of events of O1‖O2.
end forfor Each a /∈ E1 ∩E2 do
Find transitions of O1 : O1.xi ∗a = O1.x j labeled by a;for All states of O2 : y do
Construct transition of O1‖O2 : O1.xi;O2.y ∗ a =O1.x j;O2.y;
Add initial and end states of the transition to the set ofstates of O1‖O2
Add a to the set of events of O1‖O2end forFind transitions of O2 : O2.yk ∗a = O2.xh labeled by a;for All states of O1 : x do
Construct transitions of O1‖O2 : O1.x;O2.yk ∗ a =O1.x;O2.yh;
Add initial and end states of the transition to set of statesof O1‖O2
Add a to the set of events of O1‖O2end for
end for
The Algorithm 2 for CSP composition ‖ of twoProtocol Machines reflects the synchronization ofprotocol machines. The rules of the CSP compositionsay that an event is accepted by the Protocol Model ifit is accepted by both protocol machines if they bothcontain this event in their event sets, otherwise it isrefused. This means that if the transitions of two pro-tocol machines are labeled with the same event, thentheir initial and final states are united to produce asynchronised transition. If an event belongs to the setof only one of protocol machines (in the set of two),then the state of this machine is changed according to
Fourth International Symposium on Business Modeling and Software Design
108
Traces for OBJECT Part & BEHAVIOUR !DuplicateCheck 1)Part.@new&!DuplicateCheck.@new*CreatePart=Part.created&!DuplicateCheck.unique--> Part.created&!DuplicateCheck.unique*SubmitPart=Part.submitted&!DuplicateCheck.unique--> | 2)Part.@new&!DuplicateCheck.@new*CreatePart=Part.created&!DuplicateCheck.duplicate-->
Traces for OBJECT Document & BEHAVIOUR Document Submittable & OBJECT Part & BEHAVIOUR !DuplicateCheck 1)Document.@new&DocumentSubmittable.@new&Part.@new&DuplicateCheck.@new*CreateDoc=Document.created&DocumentSubmittable.notSubmittable&Part.@new&DuplicateCheck.@new--> Document.created&DocumentSubmittable.notSubmittable&Part.@new&DuplicateCheck.@new*CreatePart=Document.created&DocumentSubmittable.notSubmittable&Part.created&DuplicateCheck.unique-->
Document.created&DocumentSubmittable.notSubmittable&Part.created&DuplicateCheck.unique*SubmitPart=Document.created&DocumentSubmittable.submittable&Part.submitted&DuplicateCheck.unique-->Document.created&DocumentSubmittable.submittable&Part.submitted&DuplicateCheck.unique*SubmitDoc=Document.submitted&DocumentSubmittable.submittable&Part.submitted&DuplicateCheck.unique--> | 2)Document.@new&DocumentSubmittable.@new&Part.@new&DuplicateCheck.@new*CreateDoc=Document.created&DocumentSubmittable.notSubmittable&Part.@new&DuplicateCheck.@new--> Document.created&DocumentSubmittable.notSubmittable&Part.@new&DuplicateCheck.@new*CreatePart=Document.created&DocumentSubmittable.notSubmittable&Part.created&DuplicateCheck.duplicate-->
Figure 3: Traces of the Part with Duplicate check and the model of a Document with one Part.
its transition, and the state of the other machine re-mains unchanged.
4.3 Generation of Test Traces for theSystem Protocol Machine
To generate tests we use the set of transitions ofSystemPM obtained at the previous step. The precon-ditions are the following:- Each unique trace has to start from the transition in whichthe initial state of each object is @new. This way a test casecan cover the whole life cycle of the objects involved in atrace.- Each possible transition in a particular trace has to be re-peated only once. This way we decrease the number of teststeps while still providing complete transition coverage.
Algorithm 3 : Generation of test traces for the protocolmodel.
GIVEN: Transitions T of SystemPM: (x,e,y),x,y ∈ S, e ∈ ERESULT: test case traces for SystemPMAlgorithm:Initial state of the system l =”all objects in state @new”.for each t ∈ T do
if The input state of t x⊆ l thenAdd t to the set of transitions Tj, j = 0, ...,k possible inthe initial state ”all objects in state @new”
end ifend forfor Each Tj , j= 0,...,k do
Apply the Algorithm for Transition Tree Generation for TjMake a trace by Traversing Transition Tree for Tj
end for
Algorithm 4: Transition Tree Generation recursively makesa tree of traces starting with the initial transition Tj.
GIVEN:Transitions T of SystemPmTransition T j for which precondition 1 holdsResult: test case traces for Tj as an initial transitionAlgorithm:Add Tj to a tree as a noderemove Tj from T /* to enforce precondition 2*/for each t ∈ T do
if initial state t = end state of Tj thenTransition Tree Generation for t
end ifend for
Traversing Transition Tree from the initial transi-tion Tj is straight forward. Each trace starts from theinitial transition and stops in a leaf for which no tran-sition exists with the initial state equal to the end statein the current leaf. Termination is assured because ateach step in the trace the corresponding transition isremoved from the finite set T .
4.4 Results of Test Generation
We implemented the above algorithms as a Java ap-plication. As we already mentioned, changeability isan immanent feature of Case Management Systems.In order to support testing of changeability, the tracescan be built evolutionary. The task of regression test-ing (Myers, 2004) is selecting the minimal set of testsrequired to cover a particular change. Reducing theregression testing can contribute significantly in de-creasing the overall testing effort.
Let us assume, that the model for OBJECT Partwith BEHAVIOUR Duplicate Check was created first.After that it was extended to a composed model OB-JECT Document, BEHAVIOUR Document Submit-table, OBJECT Part, BEHAVIOUR !DuplicateCheck.
Traces for OBJECT Part with BEHAVIOUR Du-plicate Check are shown on the top of Figure 3.Traces for the composed model OBJECT Document,BEHAVIOUR Document Submittable, OBJECT Part,BEHAVIOUR !DuplicateCheck are show on the bot-tom of Figure 3.
As we can see, lines 2 and 3 of the trace 1 of thecomposed model include the trace 1 of the OBJECTPart with BEHAVIOUR Duplicate check. The statesof OBJECT Document, BEHAVIOUR Document Sub-mittable are not changed in this trace. Similarly, line2 of trace 2 includes the trace 2 of OBJECT Part, BE-HAVIOUR Document Submittable. This means thatthere is no need to repeat the tests of OBJECT Part,BEHAVIOUR Duplicate check for regression testing.The property of observational consistency of ProtocolModels works for reduction of regression testing.
A Test Generator for Model-Based Testing
109
Trac
es f
or
OB
JEC
TPar
t&B
EHA
VIO
UR
!Du
plic
ateC
hec
k 1
)Par
t.@
new
&!D
up
licat
eCh
eck.
@n
ew*C
reat
ePar
t=P
art.
crea
ted
&!D
up
licat
eCh
eck
.un
iqu
e--
>
Par
t.cr
eate
d&
!Du
plic
ateC
hec
k.u
niq
ue
*Su
bm
itP
art=
Par
t.su
bm
itte
d&
!Du
plic
ateC
hec
k.u
niq
ue
-->
| 2
)Par
t.@
new
&!D
up
licat
eCh
eck.
@n
ew*C
reat
ePar
t=P
art.
crea
ted
&!D
up
licat
eCh
eck
.du
plic
ate
-->
Tr
aces
fo
r O
BJE
CTD
ocu
men
t&O
BJE
CTD
ocu
men
tSu
bm
itta
ble
&
OB
JEC
TPar
t1&
OB
JEC
TDu
plic
ateC
hec
k1&
OB
JEC
TPar
t2&
OB
JEC
TDu
plic
ateC
hec
k2
1)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*C
reat
eD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ate
Ch
eck1
.@n
ew&
Par
t2.c
reat
ed
&D
up
licat
eC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.un
iqu
e*Su
bm
itP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.su
bm
itte
d&
Du
plic
ateC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.@n
ew&
Du
plic
ate
Ch
eck1
.@n
ew&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*C
reat
ePa
rt[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
Par
t2&
Par
t1.c
reat
ed&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.su
bm
itte
d&
Du
plic
ateC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Do
c=D
ocu
men
t.su
bm
itte
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eC
hec
k2.u
niq
ue-
->
| 2)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*C
reat
eD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ate
Ch
eck1
.@n
ew&
Par
t2.c
reat
ed
&D
up
licat
eC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.un
iqu
e*Su
bm
itP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.su
bm
itte
d&
Du
plic
ateC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.@n
ew&
Du
plic
ate
Ch
eck1
.@n
ew&
Par
t2.s
ub
mit
ted
&D
up
lica
teC
hec
k2.u
niq
ue
*Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ated
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e-->
| 3
)Do
cum
ent.
@n
ew&
Do
cum
entS
ub
mit
tab
le.@
new
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*Cre
ate
Do
c=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
lica
teC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew
*C
reat
ePar
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eC
hec
k1.@
new
&P
art2
.cre
ate
d&
Du
plic
ate
Ch
eck2
.un
iqu
e-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.cre
ated
&D
up
licat
eC
hec
k2.u
niq
ue*
Sub
mit
Par
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ated
&D
up
licat
eCh
eck1
.un
iqu
e&P
art2
.su
bm
itte
d&
Du
plic
ateC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
lica
teC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Do
c=D
ocu
men
t.su
bm
itte
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eC
hec
k2.u
niq
ue
-->
| 4)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*C
reat
eD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
pli
cate
Ch
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eC
hec
k2.@
new
*C
reat
ePar
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eC
hec
k1.@
new
&P
art2
.cre
ate
d&
Du
plic
ate
Ch
eck2
.un
iqu
e-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.cre
ated
&D
up
licat
eC
hec
k2.u
niq
ue*
Sub
mit
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Pa
rt2
.cre
ated
&D
up
licat
eC
hec
k2.u
niq
ue*
Sub
mit
Par
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Do
c=D
ocu
men
t.su
bm
itte
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eC
hec
k2.u
niq
ue
-->
| 5)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*C
reat
eD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ate
Ch
eck1
.@n
ew&
Par
t2.c
reat
ed
&D
up
licat
eC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.un
iqu
e*C
reat
ePar
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
reat
ed
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.d
up
licat
e&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.un
iqu
e*Su
bm
itP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ated
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e-->
| 6
)Do
cum
ent.
@n
ew&
Do
cum
entS
ub
mit
tab
le.@
new
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*Cre
ate
Do
c=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eC
hec
k2.@
new
*C
reat
ePar
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eC
hec
k1.@
new
&P
art2
.cre
ate
d&
Du
plic
ate
Ch
eck2
.du
plic
ate
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.du
plic
ate
*Cre
ate
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
reat
ed&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed
&D
up
lica
teC
hec
k2.d
up
licat
e-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.c
reat
ed&
Du
plic
ate
Ch
eck2
.du
plic
ate
*Su
bm
itP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Pa
rt2
.cre
ated
&D
up
licat
eC
hec
k2.d
up
licat
e-->
| 7
)Do
cum
ent.
@n
ew&
Do
cum
entS
ub
mit
tab
le.@
new
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*Cre
ate
Do
c=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eC
hec
k2.@
new
*C
reat
ePar
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eC
hec
k1.@
new
&P
art2
.cre
ate
d&
Du
plic
ate
Ch
eck2
.du
plic
ate
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.du
plic
ate
*Cre
ate
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
reat
ed&
Du
plic
ateC
hec
k1.d
up
licat
e&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.du
plic
ate-
->
| 8)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*C
reat
eD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ate
Ch
eck1
.un
iqu
e&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*C
rea
teP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.un
iqu
e-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.c
reat
ed&
Du
plic
ate
Ch
eck2
.un
iqu
e*
Sub
mit
Par
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ated
&D
up
licat
eCh
eck1
.un
iqu
e&P
art2
.su
bm
itte
d&
Du
plic
ateC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art2
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Do
c=D
ocu
men
t.su
bm
itte
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eC
hec
k2.u
niq
ue
-->
| 9)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*C
reat
eD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ate
Ch
eck1
.un
iqu
e&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*C
rea
teP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art
1.c
reat
ed
&D
up
licat
eCh
eck1
.un
iqu
e&P
art2
.cre
ated
&D
up
licat
eCh
eck2
.un
iqu
e--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.c
reat
ed&
Du
plic
ate
Ch
eck2
.un
iqu
e*
Sub
mit
Par
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Pa
rt2
.cre
ated
&D
up
licat
eC
hec
k2.u
niq
ue*
Sub
mit
Par
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e*S
ub
mit
Do
c=D
ocu
men
t.su
bm
itte
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eC
hec
k2.u
niq
ue
-->
| 10
)Do
cum
ent.
@n
ew&
Do
cum
entS
ub
mit
tab
le.@
new
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*C
reat
eDo
c=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
>
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ate
Ch
eck1
.un
iqu
e&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*C
rea
teP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.d
up
lica
te--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.c
reat
ed&
Du
plic
ate
Ch
eck2
.du
plic
ate
*Su
bm
itP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ate
Ch
eck2
.du
plic
ate-
->
| 11
)Do
cum
ent.
@n
ew&
Do
cum
entS
ub
mit
tab
le.@
new
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*C
reat
eDo
c=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
>
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ate
Ch
eck1
.un
iqu
e&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ateC
hec
k1.u
niq
ue
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*Su
bm
itP
art[
Par
t1]=
Do
cum
en
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
Par
t1&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Pa
rt2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*Cre
ateP
art
[Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue-
->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Pa
rt2
.cre
ated
&D
up
licat
eC
hec
k2.u
niq
ue*
Sub
mit
Par
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
en
tSu
bm
itta
ble
.su
bm
itta
ble
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.s
ub
mit
ted
&D
up
licat
eCh
eck2
.un
iqu
e--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.s
ub
mit
ted
&D
up
lica
teC
hec
k2.u
niq
ue
*Su
bm
itD
oc=
Do
cum
ent.
sub
mit
ted
&D
ocu
me
ntS
ub
mit
tab
le.s
ub
mit
tab
le&
Par
t1.s
ub
mit
ted
&D
up
licat
eCh
eck1
.un
iqu
e&P
art2
.su
bm
itte
d&
Du
plic
ate
Ch
eck2
.un
iqu
e-->
| 1
2)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*
Cre
ateD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eC
hec
k2.@
new
*C
reat
ePar
t[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
reat
ed
&D
up
licat
eC
hec
k1.u
niq
ue&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.un
iqu
e&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*
Sub
mit
Par
t[P
art1
]=D
ocu
me
nt.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.@
new
&D
up
lica
teC
hec
k2.@
new
-->
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Pa
rt2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*Cre
ateP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.su
bP
art1
&P
art1
.su
bm
itte
d&
Du
plic
ateC
hec
k1.u
niq
ue&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.d
up
licat
e-->
| 1
3)D
ocu
men
t.@
new
&D
ocu
men
tSu
bm
itta
ble
.@n
ew&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*
Cre
ateD
oc=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eC
hec
k2.@
new
*C
reat
ePa
rt[P
art1
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
reat
ed
&D
up
licat
eC
hec
k1.d
up
licat
e&P
art2
.@n
ew&
Du
plic
ateC
he
ck2
.@n
ew--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*
Cre
ateP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ated
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.c
rea
ted
&D
up
licat
eCh
eck2
.un
iqu
e-->
D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.c
reat
ed&
Du
plic
ateC
hec
k2.u
niq
ue*
Sub
mit
Par
t[P
art2
]=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.s
ub
Par
t2&
Par
t1.c
reat
ed&
Du
plic
ateC
hec
k1.d
up
licat
e&P
art2
.su
bm
itte
d&
Du
plic
ateC
hec
k2.u
niq
ue-
->
| 14
)Do
cum
ent.
@n
ew&
Do
cum
entS
ub
mit
tab
le.@
new
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ateC
hec
k2.@
new
*C
reat
eDo
c=D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.@
new
&D
up
licat
eCh
eck1
.@n
ew&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
>
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.@n
ew&
Du
plic
ateC
hec
k1.@
new
&P
art2
.@n
ew&
Du
plic
ate
Ch
eck2
.@n
ew*
Cre
ateP
art[
Par
t1]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ate
d&
Du
plic
ate
Ch
eck1
.du
plic
ate&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew--
> D
ocu
men
t.cr
eate
d&
Do
cum
entS
ub
mit
tab
le.n
otS
ub
mit
tab
le&
Par
t1.c
rea
ted
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.@
new
&D
up
licat
eCh
eck2
.@n
ew*
Cre
ateP
art[
Par
t2]=
Do
cum
ent.
crea
ted
&D
ocu
men
tSu
bm
itta
ble
.no
tSu
bm
itta
ble
&P
art1
.cre
ated
&D
up
licat
eCh
eck1
.du
plic
ate&
Par
t2.c
reat
ed
&D
up
licat
eCh
eck2
.du
plic
ate-
->
|
Figu
re4:
Trac
esge
nera
ted
from
the
Prot
ocol
Mod
el.
Fourth International Symposium on Business Modeling and Software Design
110
For the realistic testing of the model contains Doc-ument that may be submitted if all its Parts, we needat least two Parts. The submission of these parts cantake place in different order. In the protocol modelthe number of parts and the submittability is calcu-lated in the callback. Using the information from thecallback we build the connected form of the protocolmodel and generate from it the test cases. The gener-ator produces 14 traces that include the traces of thePart with Duplicate Check. Figure 4 shows the traces.
The traces 1,3,4,8,9,11 (black) include the firsttrace of the OBJECT Part with BEHAVIOUR Dupli-cate check for both Parts.
The traces 2,5,6,7,10,12,13,14 (blue) are termi-nated by the BEHAVIOUR Duplicate Check of one ortwo Parts and do not result in submitted Document.The tests of the OBJECT Part with BEHAVIOUR Du-plicate Check are again included into the tests of thenew model and should not be repeated. There arelines where the states of other objects and behavioursare not changed. This means that the tests of initialmodel should not be repeated as regression tests ofthe extended model.
5 CONCLUSION AND FUTUREWORK
The first research question we addressed in this paperwas to find a modelling approach that meets the re-quirements for model-based testing of highly change-able Case Management Solutions.
As the result of our analysis, we found that theProtocol Modelling technique has the most promisingproperties as it uses the CSP parallel composition ex-tended with data and possesses the property of obser-vational consistency preserving behaviour of the partsin behaviour of the whole model.
Our second research question addressed themethod of using the Protocol Modelling for test gen-eration. We developed a method that combines thetechnique for manual preparation of a protocol modeland the algorithms for automatic test generation froma protocol model. The experiments using our methodshow that protocol modelling decreases the mod-elling and testing efforts for regression testing (My-ers, 2004) of CMSs. The protocol model presents theexternal behaviour of a system under the testing. It isdifferent from the system implementation and there-fore does not cause error propagation from the systemmodel and code into the tests. Such model changes asbehaviour extensions are easily localised as new pro-tocol machines. This reduces the modelling effort forMBT. Thanks to the property of observational consis-
tency a change in the model preserves the tests of theold parts of the system. This reduces the effort for re-gression testing (Watkins and Simon, 2010). A smallillustration of our experiments has been shown in thepaper.
The contribution of this paper is shown in Figure 5as boxes 3 and 4. Our algorithms form parts of theProtocol Model-Based testing tool chain, that we aregoing to apply for Case Management Systems.
1.Protocol Model with CallBacks
3.Object Model Generation
by parsing of the prepared Protocol Model
(contribution of this paper)
2. Protocol Model Preparation
(connected forms, instances)
4.Test Generation
(contribution of this paper)
5.Test Execution. Analysis of the Test Execution
Set of Requirements
Figure 5: Protocol Model-Based Testing Methodology.
In future work we are also considering the follow-ing research directions:
(1) Partitioning a protocol model into the groupsof independent protocol machines with disjoint setsof recognised events. The theory of Protocol Mod-elling identifies the trace-independent protocol ma-chines and has a proof of observational consistencyfor them (McNeile and Roubtsova, 2008). Thus, theindependent sets of protocol machines should result inindependent sets of traces. Each such a group of pro-tocol machines can be used to produce related testswhich can be tested separately. This would again fa-cilitate the reduction of testing effort if any of suchsets change. In future work we will present our al-gorithm of partitioning of protocol machines and themethods for selection of a test strategy using parti-tioning of protocol machines.
(2) Automation of the model preparation and pro-duction of test scripts from our test traces. Un-
A Test Generator for Model-Based Testing
111
like other modeling methods, the protocol modelingmakes use of callbacks that calculate data and states.Running the callbacks during the process of the gen-eration of tests scripts from the test traces, generationof which is described in this paper, we are going tobuild executable tests.
REFERENCES
Aalst van der, W. and Weske, M. (2005). Case Handling: anew paradigm for business process support. Data &Knowledge Engineering, 52(2):129–162.
Bracha, G. and Cook, W. (1990). Mixin-based inheri-tance. OOPSLA/ECOOP ’90 Proceedings of the Eu-ropean conference on object-oriented programmingon Object-oriented programming systems, languages,and applications, pages 303–311.
Davenport, T. and Nohria, N. (1994). Case Managementand the Integration of Labor. Sloan Management Re-view.
Greenyer, J., Rieke, J., Travkin, O., and Kindler, E. (2008).TGGs for Transforming UML to CSP: Contribution tothe ACTIVE 2007 Graph Transformation Tools Con-test. University of Paderborn,Technical Report tr-ri-08-287.
Hanenberg, S., Stein, D., and Unland, R. (2007). Fromaspect-oriented design to aspect-oriented programs:tool-supported translation of JPDDs into code. InAOSD, pages 49–62.
Hoare, C. (1985). Communicating Sequential Processes.Prentice-Hall International.
Kervinen, A., Maunumaa, M., Paakkonen, T., and Katara,M. (2006). Model-Based Testing Through a GUI.volume 3997 of Lecture Notes in Computer Science,pages 16–31.
McNeile, A. and Roubtsova, E. (2008). CSP parallel com-position of aspect models. AOM’08, pages 13–18.
McNeile, A. and Roubtsova, E. (2009). Composition Se-mantics for Executable and Evolvable BehaviouralModeling in MDA. BM-MDA’09,ACM DL:ISBN:978-1-60558-503-1, pages 1–8.
McNeile, A. and Roubtsova, E. (2012). Motivation andguaranteed completion in workflow. LNBIP, 142:16–42.
McNeile, A. and Simons, N. (2000). http://www.metama-xim.com/.
McNeile, A. and Simons, N. (2006). Protocol Modelling.A Modelling Approach that Supports Reusable Be-havioural Abstractions. Software and System Model-ing, 5(1):91–107.
Myers, G. (2004). The Art of Software Testing. Wiley.OMG (2003). Unified Modeling Language: Superstructure
version 2.1.1 formal/2007-02-03.OMG (2013). Case Management Model
and Notation (CMMN). FTF Beta 1.http://www.omg.org/spec/CMMN/121101.
Petri, C. and Reisig, W. (2008). Petri net, volume 3. Schol-arpedia: 3(4):6477.
Roubtsova, E. and Kuiper, R. (2003). Process Semanticsfor UML Component Specifications to Assess Inheri-tance. Electr. Notes Theor. Comput. Sci., 72(3):145–159.
UML (2005). Testing profile. formal/05-07-07,Version 1.0.Watkins, J. and Simon, M. (2010). Testing IT. 2nd ed. Cam-
bridge University Press.
Fourth International Symposium on Business Modeling and Software Design
112
