From OpenTTCN DocZone
Home | Developer's corner | Knowledge base | Working documents | Documentation | Tutorials | Training | How do I | Frequently asked questions | Technical support |
Creating adapter with SDK for Java
In this article we will talk about creating the most simple TTCN-3 compliant adapter using standard mappings of TTCN-3 TRI and TCI-CD interfaces to Java language that are supported by OpenTTCN Java SDK.
The example that we build in this article is in many respects similar to the example from Creating adapter with C SDK, so we will be doing some cross-referencing here to the existing material whenever needed.
A bit of terminology
TTCN-3 adapter is a piece of software implemented by the end user of the SDK. TTCN-3 adapter is responsible for:
- encoding and decoding;
- sending and receiving protocol frames to and from the SUT.
What do we need
In this article we assume development under Windows platform. This affects our build scripts, directory separator notation etc. This does not mean however that we write non-portable Java code here.
To be able to develop and compile our adapter example in Java, we will need the following:
- OpenTTCN Tester for TTCN-3, preferably the latest stable release (2.56.0 at the time of writing). We will need the runtime for Windows and OpenTTCN Java SDK.
- Latest Java SE Development Kit (JDK). You need to have at least JDK version 1.5.0, also known as J2SE 5.0; we recommend using version 1.6.0 (JDK 6) or later.
- Any decent text editor. While you are free to use any IDE of your liking like JBuilder from Borland/CodeGear or Eclipse, we would prefer to build our example in a way that is not biased towards any particular IDE, as there is no clear market winner in this area at the time of writing. Based on this article, you can set up a Java project using your favourite Java IDE and create an adapter in a familiar environment if you would like doing so.
Although in theory execution of Java-based code does not depend on the underlying runtime platform, in many practical cases it does. Since OpenTTCN Java SDK uses Java Native Interface (JNI) internally, it comes with a Windows DLL as a part of the bundle. This DLL is used by the OpenTTCN Java SDK JAR library through JNI. This means that while your adapter code remains portable (as long as it remains pure Java), the bundle currently limits execution of your Java code to a certain platform (Windows). Please write us to support@openttcn.fi if this is an issue and tell us what other platforms you would like to see in the "Supported" list for OpenTTCN Java SDK.
Creating Main.java
In the following we assume that all our adapter development is done in the following folder:
C:\wikiex\java_example01
Let's create SimpleAdapter\src subfolder structure in the java_example01 folder. We will put all our Java source code to the src folder. Here is its full path:
C:\wikiex\java_example01\SimpleAdapter\src
Now let's add Main.java to the src folder, with the following content:
package com.openttcn.wikiex.simple;
import com.openttcn.sdk.api.StartHere;
import com.openttcn.sdk.api.GeneralFailure;
public class Main {
private static final int SLEEP_INTERVAL_IN_MILLIS = 100000;
private static void sleepForever() {
while (true) {
try { Thread.sleep(SLEEP_INTERVAL_IN_MILLIS); } catch (Exception e) { }
}
}
public static void main(String[] args) {
try {
StartHere.initialize();
// Register the adapter to OpenTTCN server:
StartHere.registerSelfToSession("simple");
// Enable printout of library diagnostic information:
StartHere.setVerbose(true);
}
catch (GeneralFailure e) {
System.err.println("Error: " + e.getErrorCode() + ": " + e.getMessage());
System.exit(1);
}
System.out.println("Init OK!");
sleepForever();
}
}
As you can see, we have two API function calls in the code snippet above, StartHere.initialize() and StartHere.registerSelfToSession(). The first one initializes the SDK library. This includes establishing a communication path between the adapter, a dedicated process in its own right, and OpenTTCN server containing TTCN-3 runtime environment. The second one registers this adapter into particular session so that OpenTTCN runtime knows where to find the adapter when necessary.
Both interface functions are proprietary and are needed for initial adapter setup, an issue that is outside of the scope of the TTCN-3 standard. In the following we will be writing mostly standard-compliant adapter code. Proprietary extensions will be needed for the purpose of filling in gaps in the TRI/TCI specification.
Setting up the build environment
In the following we assume that you have installed OpenTTCN SDK for Java to the following directory:
C:\Program Files (x86)\OpenTTCN\JavaSDK
Your actual build environment may slightly differ from the settings presented in this tutorial if your OpenTTCN SDK for Java installation directory is different.
We will create a simple Windows batch file to compile our Java source code. Add the compile.bat file with the following content to the C:\wikiex\java_example01\SimpleAdapter folder:
javac -classpath "C:\Program Files (x86)\OpenTTCN\JavaSDK\lib\OTSDK.jar" -d classes src\*.java
Create the classes folder next to the src folder. This where the javac compiler output will go.
This concludes setting up the build environment for our Java project. Quite simple, isn't it.
Now try compiling the adapter by running the compile.bat script. It should compile like a breeze, provided you have the javac compiler in your path.
Preparing to run the adapter for the first time
Add the start_adapter.bat file next to compile.bat with the following content:
start java -classpath "C:\Program Files (x86)\OpenTTCN\JavaSDK\lib\OTSDK.jar;classes" -Djava.library.path="C:\Program Files (x86)\OpenTTCN\JavaSDK\lib" com.openttcn.wikiex.simple.Main
We also need to start OpenTTCN server using the ot command and create a session named simple using the session command. This is done exactly in the same way as it is described in the main article of this section.
Running the adapter for the first time
Run the start_adapter.bat script. Windows may pop up a security alert. If so, click "Unblock". Adapter tries to set up a network connection with the local OpenTTCN server installation, hence the alert.
If everything goes fine, you should see a terminal window with the following text message: "Init OK!" Now you can type session status simple from the command line. You should be able to see the following fragment of output:
Adapters ----------------------------------------------------------------------------- Name Status Description TRI ALIVE TRI SUT and platform adapter
This means that we have our adapter successfully registered to the simple session with TRI role and the adapter is reachable from within the session (has alive status).
Adding default callback handlers
Now we need to create a skeleton of our adapter code. Remember that one of the adapter roles is handling various test execution (TE) requests, including requests to send a frame to the SUT. In the adapter this is done by implementing callback handlers that are invoked by the SDK library in the background when a relevant request arrives from the TE.
For now, let's add some dummy default implementation of these callbacks. For this we will need to add one more source file to the src directory, TriCommunicationSA.java. It will contain implementation of the SUT adapter including calls to network interface code.
Content of TriCommunicationSA.java:
package com.openttcn.wikiex.simple;
import com.openttcn.sdk.tri.Factory;
public class TriCommunicationSA extends com.openttcn.sdk.tri.TriCommunicationSA {
public org.etsi.ttcn.tri.TriStatus triSend(
org.etsi.ttcn.tri.TriComponentId componentId,
org.etsi.ttcn.tri.TriPortId tsiPortId,
org.etsi.ttcn.tri.TriAddress address,
org.etsi.ttcn.tri.TriMessage sendMessage) {
return Factory.createTriStatus(org.etsi.ttcn.tri.TriStatus.TRI_ERROR);
}
}
Surprisingly, this is enough to get started even with most of the real world test suites that you are going to deal with. As you see, here we implement one important callback handler from the standard TRI interface that is invoked when the TE wishes to send a frame to the SUT:
In addition, we will need to add TciCDProvided.java source file to the src directory and add implementation of the following encoding and decoding handlers from the standard TCI interface:
Content of TciCDProvided.java:
package com.openttcn.wikiex.simple;
public class TciCDProvided
implements org.etsi.ttcn.tci.TciCDProvided {
public org.etsi.ttcn.tri.TriMessage encode(
org.etsi.ttcn.tci.Value value) {
return null;
}
public org.etsi.ttcn.tci.Value decode(
org.etsi.ttcn.tri.TriMessage message,
org.etsi.ttcn.tci.Type decodingHypothesis) {
return null;
}
}
Now when we added skeletons of TRI SA and TCI CD handlers, let's register them in the SDK library in the main() function. Add the following section of code to Main.java after StartHere.registerSelfToSession("simple");:
com.openttcn.sdk.tri.StartHereSA.
setCallbackHandler(new TriCommunicationSA());
com.openttcn.sdk.tri.StartHerePA.
setCallbackHandler(new com.openttcn.sdk.tri.TriPlatformPA());
com.openttcn.sdk.tci.StartHereCD.
setCallbackHandler(new TciCDProvided());
This also registers default implementation of TRI PA handler that does nothing useful. Since we are not planning to implement TTCN-3 external functions this time, we did not add our own version of TriPlatformPA class to our codebase as we did for TriCommunicationSA. We use default implementation provided by the SDK library instead.
Everything should compile OK and "Init OK!" message should show up when your start new version of the adapter.
Now we can move forward and add real content to our dummy adapter implementation. To do this, we need to agree on what kind of protocol and SUT we are testing.
SUT definition
To simplify our example, we will be testing a simple imaginary protocol with a few defined frames, simple behaviour, and simple network interface. Let us call this protocol R2-D2. This protocol is UDP-based.
For precise protocol definition, please read the main article of this section.
In our test configuration we will be testing a server, meaning that SUT has server role and test harness simulates a client. Frame exchange between the two peers, client and server, uses UDP communication.
TTCN-3 message type definitions
Replace all occurrences of C:\wikiex\example01 with C:\wikiex\java_example01 and follow the instructions contained in the main article of this section.
Adding example test case
Building test suite
Running test case (first try)
Now launch the adapter if it is not running using start_adapter.bat, and run the test case that we have just added by typing the following from the command line:
tester run simple TC_R2D2_001
The tester command shall complain with this kind of error message:
mtc : {15:07:09.375} : // VERDICT TC_R2D2_001 TEST CASE ERROR: E4205: triSend() return status is not TRI_OK.
Indeed, we return TRI_ERROR from triSend() to indicate that we did not implement TTCN-3 send request.
We also did not implement proper encoding of the message content and address field.
If you look at the debug output of the adapter window, you may get an impression that TciCDProvided.encode() (shown as tciEncode()) is called twice after triSend(), once for the address field, and second time for the message content. This is misleading. Actually, the TciCDProvided.encode() callback is called twice before the triSend() callback is called.
The conclusion is that the adapter debug output gives you only a rough idea about actual sequence of calls as it is seen by the end user implementing the adapter.
You can disable debug output by commenting out the following statement in Main.java:
StartHere.setVerbose(true);
Creating encoder
Currently, functionality for encoding message content and address field is not implemented in our version of TciCDProvided.encode(). Before we go for implementing triSend(), we need to implement the encoding part first, because triSend() receives message and address parameters in already encoded form.
As you can see, the TTCN-3 standard puts you in quite tight framework. Your triSend() handler always receives important parameters in encoded form, even if the business logic of your adapter implementation makes this undesirable. Such inconvenience may occur more often than it seems at first sight. For example, if you rely on a third-party library for communicating with the SUT, it may be more convenient to have the message in abstract form during triSend() call, and then extract abstract fields from the message container and supply them to the third-party library API than doing all frame encoding by yourself.
With encoding of the address field it is the same. We do not really need address in encoded form, because it is not an integral part of the payload of our protocol frame. We would prefer having it in abstract form in triSend(), because we are going to use socket API for sending UDP frames, and it accepts destination IP address and UDP port as parameters.
Different tools find different workarounds for this awkward peculiarity of the TTCN-3 standard. Some may even go as far as introducing new non-standard signatures of callback functions that pass value parameters in unencoded form. While such approach clearly simplifies end user life, it also raises concerns about portability of adapter implementation.
OpenTTCN decided to keep the standard set of callback interfaces as it is and introduce a workaround at a different, less noticeable level.
The idea behind such workaround is to return opaque representation of the TCI value encapsulated into TriMessage instead of performing diligent encoding of such value and returning result of encoding. This opaque representation is stored in Java byte array, a format directly suitable for TriMessage. The triSend() handler can later relatively easily recover abstract TCI value from this byte array. Here is a code snippet how to do the workaround in the encoder:
public org.etsi.ttcn.tri.TriMessage encode(
org.etsi.ttcn.tci.Value value) {
return com.openttcn.sdk.tri.Factory.
createTriMessage(((com.openttcn.sdk.tci.Value) value).opaque);
}
Now the code inside triSend() handler can recover original TCI value quite easily:
com.openttcn.sdk.tci.Value addrValue = new com.openttcn.sdk.tci.Value(); addrValue.opaque = address.getEncodedAddress();
And it can now process abstract TTCN-3 value in unencoded form. You may need to use specific subclass of the Value base class in the code fragment above.
So for our encoder we make two decisions:
- pass address field in unencoded form to triSend() using the programming trick described above
- encode message content as normally and pass encoded frame to triSend()
TTCN-3 TCI value introspection and construction API is a proper topic for a separate article, so for now we simply present the Java code of the encoder and leave it to the reader as an exercise to figure out what it does.
Here is the code that needs to replace the earlier version of encode() in TciCDProvided.java:
public static final int MAX_BUFFER_SIZE = 4096;
public org.etsi.ttcn.tri.TriMessage encode(
org.etsi.ttcn.tci.Value value) {
int len = 0;
org.etsi.ttcn.tci.Type valType = value.getType();
String typeName = valType.getName();
int typeClass = valType.getTypeClass();
if (typeClass == org.etsi.ttcn.tci.TciTypeClass.ADDRESS) {
return com.openttcn.sdk.tri.Factory.
createTriMessage(((com.openttcn.sdk.tci.Value) value).opaque);
}
if (typeName.equals("Message")) {
byte[] buffer = new byte[MAX_BUFFER_SIZE];
len = 0;
org.etsi.ttcn.tci.Value typeCodeField =
((org.etsi.ttcn.tci.RecordValue) value).getField("typeCode");
int typeCode =
((org.etsi.ttcn.tci.IntegerValue) typeCodeField).getInteger();
buffer[len++] = (byte) typeCode;
org.etsi.ttcn.tci.Value payload =
((org.etsi.ttcn.tci.RecordValue) value).getField("payload");
if (!payload.notPresent()) {
org.etsi.ttcn.tci.Value lenField =
((org.etsi.ttcn.tci.RecordValue) payload).getField("len");
int length =
((org.etsi.ttcn.tci.IntegerValue) lenField).getInteger();
buffer[len++] = (byte) (length >> 8);
buffer[len++] = (byte) (length >> 0);
org.etsi.ttcn.tci.Value contentField =
((org.etsi.ttcn.tci.RecordValue) payload).getField("content");
String content =
((org.etsi.ttcn.tci.CharstringValue) contentField).getString();
byte[] contentAsBytes = null;
try {
contentAsBytes = content.getBytes("US-ASCII");
}
catch (java.io.UnsupportedEncodingException e) {
System.err.println("Error: Unrecognized encoding.");
return null;
}
System.arraycopy(
contentAsBytes, 0, buffer, len, contentAsBytes.length);
len += contentAsBytes.length;
}
byte[] finalArray = new byte[len];
System.arraycopy(buffer, 0, finalArray, 0, len);
return com.openttcn.sdk.tri.Factory.createTriMessage(finalArray);
}
System.err.println("Error: Unrecognized message type: " + typeName + ".");
return null;
}
Sending frame to the SUT
Now everything is ready to add proper implementation of the triSend() handler to our code. It should basically extract IP address and UDP port of the SUT from the sutAddress parameter that effectively contains abstract TCI value opaque representation, and then send encoded data frame contained in the sendMessage parameter to the SUT using extracted address fields. Does not sound overhelming, isn't it?
Here is a new triSend() handler for TriCommunicationSA.java that does all this:
public org.etsi.ttcn.tri.TriStatus triSend(
org.etsi.ttcn.tri.TriComponentId componentId,
org.etsi.ttcn.tri.TriPortId tsiPortId,
org.etsi.ttcn.tri.TriAddress address,
org.etsi.ttcn.tri.TriMessage sendMessage) {
com.openttcn.sdk.tci.RecordValue
addrValue = new com.openttcn.sdk.tci.RecordValue();
addrValue.opaque = address.getEncodedAddress();
byte[] ipAddr = new byte[4];
int[] portNumberHolder = new int[1];
int result =
Utilities.extractHostAndPortFromAddress(
ipAddr, portNumberHolder, addrValue);
if (result != 0) return Factory.createTriStatus(
org.etsi.ttcn.tri.TriStatus.TRI_ERROR);
java.net.InetAddress inetAddr = null;
try {
inetAddr = java.net.InetAddress.getByAddress(ipAddr);
}
catch (java.net.UnknownHostException e) {
System.err.println("Error: Invalid IP address format.");
return Factory.createTriStatus(
org.etsi.ttcn.tri.TriStatus.TRI_ERROR);
}
result = Utilities.sendDatagramPacket(
inetAddr,
portNumberHolder[0],
sendMessage.getEncodedMessage());
return Factory.createTriStatus((result == 0) ?
org.etsi.ttcn.tri.TriStatus.TRI_OK :
org.etsi.ttcn.tri.TriStatus.TRI_ERROR);
}
To use this code, you will need to add Utilities.java file to the src directory.
SUT implementation
SUT implementation is available both in source (C/C++) and binary form. Main article of this section explains how to download, install, and run the SUT. Replace all occurrences of C:\wikiex\example01 with C:\wikiex\java_example01 and follow the instructions contained in the main article of this section before moving forward. You do not have to recompile the SUT because the downloadable package already contains the SUT binary.
Running test case (second try)
Follow the instructions contained in the main article of this section. You can launch the adapter using start_adapter.bat script. Because we have been developing our Java adapter so that it can be used interchangeably with the C SDK adapter developed in the main article, your test results should look the same.
Creating UDP port listener thread
Now when we have the sending channel working, we need to implement a subsystem listening for incoming frames from the SUT. This is typically done by launching a dedicated thread that uses DatagramSocket.receive(), a standard Java API function call. This function blocks until a UDP frame arrives from the remote peer.
To launch a dedicated thread, we will implement Java Runnable interface and instantiate a new Thread object as explained in Sun's concurrency tutorial.
First, let's add SocketListener.java file containing implementation of the Runnable interface with the following content:
package com.openttcn.wikiex.simple;
public class SocketListener implements Runnable {
public static final int MAX_BUFFER_SIZE = 65536;
public void run() {
if (Utilities._socketDesc == null) {
Utilities._socketDesc = Utilities.bindSocketToAnyPort();
if (Utilities._socketDesc == null) {
System.err.println("Error: Cannot bind socket.");
return;
}
}
org.etsi.ttcn.tci.TciCDRequired cd =
com.openttcn.sdk.tci.StartHereCD.getRequestServer();
org.etsi.ttcn.tri.TriCommunicationTE te =
com.openttcn.sdk.tri.StartHereSA.getRequestServer();
java.net.DatagramPacket packet =
new java.net.DatagramPacket(
new byte[MAX_BUFFER_SIZE], MAX_BUFFER_SIZE);
/* Loop forever */
while (true) {
/* Receive a packet from the SUT */
try {
Utilities._socketDesc.receive(packet);
}
catch (Exception e) {
// Error during receiving, try again:
continue;
}
org.etsi.ttcn.tci.RecordValue sutAddr =
(org.etsi.ttcn.tci.RecordValue)
cd.getTypeForName("address").newInstance();
java.net.InetAddress srcAddr = packet.getAddress();
String host = srcAddr.getHostAddress();
sutAddr.setField("host",
com.openttcn.sdk.tci.Utilities.charstringToTciValue(host));
int port = packet.getPort();
sutAddr.setField("portField",
com.openttcn.sdk.tci.Utilities.intToTciValue(port));
org.etsi.ttcn.tri.TriAddress sutAddrEncoded =
com.openttcn.sdk.tri.Factory.createTriAddress(
((com.openttcn.sdk.tci.Value) sutAddr).opaque);
byte[] buffer = new byte[packet.getLength()];
System.arraycopy(packet.getData(),
packet.getOffset(), buffer, 0, packet.getLength());
org.etsi.ttcn.tri.TriMessage msg =
com.openttcn.sdk.tri.Factory.createTriMessage(buffer);
org.etsi.ttcn.tri.TriPortId p =
com.openttcn.sdk.tri.Factory.
createTriPortId("tsiPort"); /* port name is hard-coded */
te.triEnqueueMsg(p, sutAddrEncoded, null, msg);
}
}
}
As you might have noticed, we do the same trick with handling SUT address field as we did on the sending side of the adapter in TciCDProvided.encode(). Instead of delegating to TciCDProvided.decode() construction of decoded address given some pseudo-encoding, we construct the address abstract value already here and then put the resulting TCI value opaque representation into TriAddress that is passed later to TciCDProvided.decode().
Name of the test system interface port to which we send the frame is hard-coded ("tsiPort"). It is taken from the SystemInterfaceType component type definition of our example test suite.
This is not everything what we need to do for our UDP port listener thread. Not only we need to create its implementation, but we also need to create the thread and start it. Therefore we need to add the following block of code to our Main.java before System.out.println("Init OK!"); line:
Thread t = new Thread(new SocketListener()); t.start();
Creating decoder
Now if you compile the adapter, start it and run the test case while the SUT is also running, you should see this kind of test case error in the test log:
adapter : {15:18:25.961} : // VERDICT TC_R2D2_001 TEST CASE ERROR: E4207: Adapter error: triEnqueueMsg(): No message content, message will not be sent.
This may sound like magic, but the idea is simple: SDK library complains that there is no decoded abstract TTCN-3 message to be enqueued into the port queue. Indeed, recall we have had only a dummy implementation of TciCDProvided.decode() in TciCDProvided.java so far that always returns null. Hence "no message content" error message.
This also means that our UDP port listener has received a response from the SUT and attempted to enqueue it into the TSI port message queue. This is good news to see it working.
Now we need to add the decoder for the received frame to finalize our adapter implementation. Here is a replacement for the dummy implementation of decode() in TciCDProvided.java. Note how we handle values of address type:
public org.etsi.ttcn.tci.Value decode(
org.etsi.ttcn.tri.TriMessage message,
org.etsi.ttcn.tci.Type decodingHypothesis) {
org.etsi.ttcn.tci.TciCDRequired cd =
com.openttcn.sdk.tci.StartHereCD.getRequestServer();
String typeName =
(decodingHypothesis != null) ? decodingHypothesis.getName() : "";
if (typeName.equals("address")) {
com.openttcn.sdk.tci.RecordValue
addrValue = new com.openttcn.sdk.tci.RecordValue();
addrValue.opaque = message.getEncodedMessage();
return addrValue;
}
if (decodingHypothesis == null) {
/* Assuming decoding of value of Message type */
byte[] buffer = message.getEncodedMessage();
int len = buffer.length;
if (len == 0) {
System.err.println("Error: Message content is too short.");
return null;
}
if (len == 2) {
System.err.println("Error: Message content is malformed.");
return null;
}
org.etsi.ttcn.tci.Value typeCode =
com.openttcn.sdk.tci.Utilities.intToTciValue((int) buffer[0]);
org.etsi.ttcn.tci.RecordValue result =
(org.etsi.ttcn.tci.RecordValue)
cd.getTypeForName("Message").newInstance();
result.setField("typeCode", typeCode);
if (len > 2) {
int length =
((((int) buffer[1]) & 0xFF) << 8) |
((((int) buffer[2]) & 0xFF) << 0);
org.etsi.ttcn.tci.IntegerValue lenField =
(org.etsi.ttcn.tci.IntegerValue)
cd.getTypeForName("uint16").newInstance();
lenField.setInteger(length);
byte[] contentBuffer = new byte[len - 3];
System.arraycopy(buffer, 3, contentBuffer, 0, len - 3);
String contentAsStr = null;
try {
contentAsStr = new String(contentBuffer, "US-ASCII");
}
catch (java.io.UnsupportedEncodingException e) {
System.err.println("Error: Unrecognized encoding.");
return null;
}
org.etsi.ttcn.tci.Value contentField =
com.openttcn.sdk.tci.Utilities.
charstringToTciValue(contentAsStr);
org.etsi.ttcn.tci.RecordValue payload =
(org.etsi.ttcn.tci.RecordValue)
cd.getTypeForName("Payload").newInstance();
payload.setField("len", lenField);
payload.setField("content", contentField);
result.setField("payload", payload);
}
return result;
}
System.err.println("Error: Unrecognized type: " + typeName + ".");
return null;
}
Running test case (third try)
It works now! The test case passes, meaning that we have implemented everything correctly. Here is the output of the tester run command:
C:\wikiex\java_example01\TestSuite>tester run simple TC_R2D2_001
*****************************************************************************
*** RUNNING TEST CASE TC_R2D2_001
Tester : {17:04:08.726} : // Time: 17:04:08.726. Date: 04/Dec/2007. MOT version: TC: 2.57.0.RC3.0.
mtc : {17:04:08.756} : // CASE TC_R2D2_001 STARTED
mtc : {17:04:08.756} : T_GUARD.start(10.0); // Timer is started: duration 10 s.
mtc : {17:04:08.768} : map(mtc:p, system:tsiPort);
mtc : {17:04:08.792} : p.send(Message GreetingRequest := { typeCode := 1, payload := { len := 13, content := "Hello, world!" } }) to { host := "127.0.0.1", portField := 7431 };
mtc : {17:04:08.825} : p.receive(Message GreetingResponse := { typeCode := 2, payload := { len := 15, content := "Hello, mankind!" } }) from { host := "127.0.0.1", portField := 7431 };
mtc : {17:04:08.864} : p.send(Message GreetingRequest := { typeCode := 1, payload := { len := 17, content := "Hello, gentlemen!" } }) to { host := "127.0.0.1", portField := 7431 };
mtc : {17:04:08.896} : p.receive(Message GreetingResponse := { typeCode := 2, payload := { len := 11, content := "Reformulate" } }) from { host := "127.0.0.1", portField := 7431 };
mtc : {17:04:08.896} : setverdict(pass);
mtc : {17:04:08.901} : // CASE TC_R2D2_001 FINISHED
mtc : {17:04:08.901} : // VERDICT TC_R2D2_001 PASS
*****************************************************************************
*** TEST EXECUTION SUMMARY
Pass Fail Inconc None Error Total Duration
1 0 0 0 0 1 00:00:01
C:\wikiex\java_example01\TestSuite>
What next
There are many ways to improve the adapter code that we have developed up to this moment. Things to consider:
- encoding and decoding of invalid frames using
Rawdata type definition; - adding support for multiple test system interface ports; currently we have the only one tsiPort port, what greatly simplified our design; having more TSI ports may mean more UDP port listeners, more threads, and more complexity;
- integrating adapter code with GUI test management software, if this is required by your project;
- disabling debug output to improve overall system performance;
- etc.
You can download the final version of the adapter, test suite and the SUT that we developed in this article, all in one package, by following this link.
Views
Personal tools
- Copyright © 2007-2008 OpenTTCN Ltd. All Rights Reserved