1 Introduction¶
1.1 Scope¶
The UML Testing Profile (U2TP) is an OMG standard, defined as an extension of the UML language for modeling software tests. The current document describes how to use Modelio with the module implementing this U2TP extension.
For further information on how to use Modelio, the main Modelio user guide should be consulted.
The Modelio U2TP module is based on the analysis of the UML Testing Profile specification version 1.0 from 05.07.07.
1.2 Intended Audience¶
The document is dedicated to software (test) engineers who intend to create models describing test architectures and behaviors.
1.3 References¶
Reference
Description
UML Testing Profile
UML Testing Profile specification version 1.0 from 05.07.07
http://www.omg.org/cgi-bin/doc?formal/05-07-07.pdf
Modelio
Modelio CASE Tool, http://www.modelio.org
SOFTEAM R&D Team web-site
1.4 Requirements¶
To use this profile, you need at least:
Modelio 2, downloadable from http://modelio.org;
the file U2TP_x.yy.zz.jmdac, available in one of the U2TP bundles which can be downloaded from http://forge.modelio.org/projects/utp/files.
2 Deployment¶
After the Modelio Free Edition installation, start the modeler and create a simple UML project.
Figure 1: Creating default UML Project with Modelio.
Go to the MDA menu and choose Install a module (cf. Figure 2).
Figure 2: Module Deployment.
You will be led to mdastore folder. Proceed to the location of the U2TP module (cf. Figure 3).
Figure 3: Module Folder.
Choose U2TP_x.yy.zz.jmdac and click Open.
· U2TP_x.yy.zz.jmdac ? contains UML Testing Profile (compatible with Modelio Enterprise edition).
Once the module is installed, you will see that a hierarchy of U2TP elements has been created in the project. These elements are grayed out, so you can not modify them (cf. Figure 4 and Figure 5).
Figure 4: U2TP types.
Figure 5: U2TP stereotypes.
**
**
3 Commands¶
3.1 Element creation commands¶
The following commands are shown when right-clicking on a model element in the UML navigator.
Commands shown when right-clicking on a UML Package element (cf. Figure 6):
Table 1 Commands on UML Package
Command
Description
Test Package
Creates a Package intended to contain test elements.
When you select several UML packages and right-click, the command creates:
-a package named from the name of the first selected package with Test as suffix;
-import dependencies to the selected UML packages;
-a class diagram showing the imports between the test package and the UML packages.
Figure 6 Commands on UML Package
Commands shown when right-clicking on a Test Package element (cf. Figure 7):
Table 2 Commands on Test Package
Command
Description
Test Component
Creates a Component with U2TP Test Component stereotype.
When you select one test package and right-click, the command creates:
-a Component named and stereotyped TestComponent.
Test Context
Creates a Class with U2TP Test Context stereotype.
When you select one test package and right-click, the command creates:
-a Class named and stereotyped TestContext with one attribute for the arbiter and one for the scheduler;
-an internal structure containing internal parts related to the elements imported from the UML package (the SUT) and related to the test components;
-a composite structure diagram showing the SUT elements.
If you do not want to test particular elements, you only have to delete them on the diagram.
Figure 7 Commands on Test Package
Commands shown when right-clicking on a Test Context element (cf. Figure 8):
Table 3 Commands on Participant
Command
Description
Test Case
Open the wizard for creating an operation which describes a test case.
This operation is stereotyped TestCase and returns a Verdict.
Figure 8 Commands on Test Context
3.2 Test case wizard¶
The test case wizard (cf. Figure 9) is opened when clicking the Create a Test Case command.
Table 4 Test case creation fields
Field
Description
Test Case Name
The name of the test case.
Test Objective
A textual description of the test objective of this test case.
The description is a comment linked to the operation by a dependency stereotyped TestObjective.
Create a sequence diagram
When ticked, initialize a sequence diagram with the internal parts of the text context (the SUT and the different test components). This includes creation messages and the expected verdict of the scenario.
Figure 9: Test case creation wizard.
**
**
4 The bank ATM example¶
In this section, a method is described for specifying tests thanks to the UML testing profile module. The bank ATM system example from the UML testing profile specification is used as a support. You can import this example by unzipping into Modelio workspace the BankATMExample.zip file contained in the Tests folder of UMLTestingProfile[src]x.y.zz.zip.
4.1 The bank ATM system¶
Figure 10: the Bank ATM system packages.
The bank ATM system is a network of international banks and ATMs (Automated Teller Machines). Especially, this system allows a customer to deposit money on his account from an ATM located anywhere in the world. The figures from Figure 10 to Figure 15 show the different public packages of the system and their content.
Figure 11: Content of the ATM package.
Figure 12: Content of the Bank package.
Figure 13: Content of the HWControl package.
Figure 14: Content of the SWIFTNetwork package.
Figure 15: Content of the Money package.
4.2 Specification of tests¶
4.2.1 Testing the Money package content¶
The purpose of these tests is to validate the behavior of the Money and MoneyBag classes (cf. Figure 15). Prior to any test cases specifications, you need to describe the test context.
right click on the Money package create a test package. The MoneyTest package and diagram are created;
right click on the MoneyTest package and create a test context. Name it MoneySuite. The test context will appear in the MoneyTest Diagram;
for the test cases, we need to manipulate two instances of Money. In the TestContext diagram, you can see that only one money internal part has been created. Name it money1;
thanks to Modelio facilities, clone the money internal part and name it money2. Unmask this new internal part on the test context diagram and check that it is stereotyped SUT.
We can now specify the first test case whose objective is to check that two amounts of the same currency are well added. For this:
right click on MoneySuite and create a test case. The wizard is opened;
name the test case addSameMoney and describe the test case objective, e.g. “ensure that the Money class returns an object of type Money with the correct amount and currency” (cf. Figure 16);
Figure 16: addSameMoney() test case.
- Click OK to validate the wizard content;
On the MoneyTest diagram, you can check that a test objective has been generated with the content you specified (cf. Figure 19).
Furthermore, the generated sequence diagram corresponding to the test case is opened. It is pre-filled with lifelines and creation messages according to the test context internal parts. It also contains a state invariant specifying the expected result (verdict) of the test case.
for this test case, remove the lifeline of the MoneyBag;
select the creation message to the money1 part and fill its argument property field with the values passed to the Money() constructor, e.g. 20, “USD”; do the same with money2 and e.g. 50, “USD” values;
create a synchronous message from moneysuite to money1 and select the add operation. Specify money2 as argument;
7. select the return message and say its name to be add(–): new Money(70, “USD”). This specifies the expected result of the message;
8. check that the result is conforming to the Figure 17.
You can now exercise yourself to specify the addDifferentMoney() test case like on Figure 18. The test objective is “ Ensure that the Money class returns an object of type MoneyBag with the currencies of the two Money objects that were added during the call to the add operation”.
Figure 17: Specification of the addSameMoney() test case.
Figure 18: Specification of the addDifferentMoney() test case.
Figure 19: Money test context specification.
4.2.2 Testing the ATM package content¶
The purpose of the tests is to validate the scenario wherein someone deposits some money on his account from an ATM. This requires to identify his credit card and to initiate communication with the bank network. In this scenario, the system under test (SUT) is the BankATM component. Other required components are emulated thanks to test components.
To specify tests involving elements of the ATM package, you only have to:
right click on the ATM package and select the Create a Test Package command. The ATMTest package and diagram are created;
right click on the ATMTest package and create two test components that will appear in the ATMTest Diagram:
Name the former HWEmulator. From the diagram, add it a port named hwCom and attach the IHardware provided interface and the IATM required interface,
Name the latter BankEmulator. From the diagram, add it a port named bankCom and attach the IBank provided interface;
After this step, you should have something like on the Content of the ATMTest package.Figure 20. Next,
- right click on the ATMTest package to create a test context. Name it ATMSuite. Open the related TestContext diagram. It shows the generated internal parts of the test context. You can connect these parts with links to refine the internal structure (cf. Figure 21) but it is not mandatory for the following;
Figure 20: Content of the ATMTest package.
Figure 21: Internal parts of ATMSuite.
right click on ATMSuite to create a test case. The wizard will be opened;
name the test case invalidPIN and describe the test case objective, e.g. “Verify that if a valid card is inserted, and an invalid pin-code is entered, the user is prompted to re-enter the pin-code.”;
click OK to validate the wizard content;
specify the sequence of synchronous and asynchronous messages of the test case by filling the sequence diagram the same way as on the Figure 22;
To specify the start and stop timer actions as well as the validation action, first add a state invariant on the diagram; then apply the related stereotype:
select the state invariant,
select the “Annotations” tab,
click “Add stereotype”,
select the stereotype you want to apply and validate (cf. Figure 23);
Figure 22: Specification of the invalidPIN test case.
Figure 23: Menu for adding a stereotype.
To show the stereotype icon, right-click on the state invariant and proceed to the option like on the Figure 24;
To specify the duration constraint {0..3}, select the constraint icon from the diagram palette and attach it to the isPinCorrect synchronous message. To do so, you click first on the ‘Synchronous message’ arrow, secondly on the ‘Reply message’ arrow and finally somewhere on the diagram where the constraint should appear.
Figure 24: Menu for showing the stereotype icon.
