Fall 2011 Contest Problem

Message Based Testing

This season’s programming contest problem falls under the domain of message based testing. Contest participants will be asked to implement a system that can send and receive various types of messages across a network.

Problem Context

It is extremely common for components inside of large systems to communicate with each other by sending messages. Imagine that the combat system on a naval ship is comprised of a decision component, a weapon control component, and a radar component. If the radar has no activity, the weapon control and the radar would regularly send status messages to the decision component to let it know that they are online and functioning properly. When the radar detects a threat, it would begin sending messages to the decision component relating the position of the threat. The decision component would begin sending messages to the weapon control to load one of the weapons and aim at the threat. If the decision component decides that the threat is close enough to engage based upon the messages from the radar component, the decision component will send a message to the weapon control to launch the weapon.

Before these messaging components are introduced into a real system they need to be rigorously tested to make sure that the right message is sent under the right circumstance. Can you imagine what would happen if a one component was expecting a distance in feet from another component, but got a distance in meters instead? Or if a weapon launch message was accidently sent twice?

Problem Description

The system that you implement should have two principal parts: one component for sending messages and another component for receiving them. Ideally, these two components would sit on different machines and communicate across a network using TCP sockets, but it is also acceptable to run both components on the same machine for testing and development purposes.

In order to get the system to understand the structure of different types of messages, both the send and receive components will need to accept a message definition file as input, which will be in xml schema format (.xsd). Here is an example of a message definition that describes a ‘time message’ with three attributes (hour, min, sec) that are all of the ‘short’ data type:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

<xs:element name="idt_time_message">
            <xs:element name="hour" type="xs:short"/>
            <xs:element name="min" type="xs:short"/>
            <xs:element name="sec" type="xs:short"/>


Once the sending component has been supplied with the message definition, it should start sending messages. For each message sent, the sending component will need to read the data for a single message stored in an xml file, generate a transmittable version of the message, and send the message to the receive component across the network. Here is an example of an xml file for a ‘time message’ containing the time of 10:35pm and 47 seconds:

<?xml version="1.0"?>

Once the receiving component has been supplied with the message definition, it should be ready to receive messages. As each message is received, it should be added to the display in real time.

Requirements Traceability

Your software solution is expected to include a small number of required functionalities in order to be considered a valid entry in the contest. On top of implementing the following requirements, you will be asked to document each requirement accomplished by writing a one sentence 'test case' that illustrates how this functionality was tested by your team.

    [Standard Requirements]
  1. The sending component shall accept an xml schema file (.xsd) as input (command line or gui) to define a message structure.
  2. The receiving component shall accept an xml schema file (.xsd) as input (command line or gui) to define a message structure.
  3. The sending and receiving components shall support messages that are comprised of the following simple data types: boolean, byte, short, int, long, float, double, and string.
  4. The sending component shall form a transmittable message based upon the message definition.
  5. The sending component shall read an xml file as the source of a message’s data.
  6. The sending and receiving component shall connect to each other with TCP sockets using an IP address and port number.
  7. The sending component shall send the transmittable message to the receiving component.
  8. The receiving component shall receive the transmittable message from the sending component.
  9. The receiving component shall display the contents of each message received in real time.

    [Bonus Requirements]
  10. The sending and receiving components shall support messages that include simple objects comprised of primitive data types (one level of nesting in xml data file – for an example see ‘status message’).
  11. The receiving component shall read an xml file (accepted through command line or gui) as the source of an expected results message.
  12. The receiving component shall form an expected result message based upon data.
  13. The receiving component shall compare the contents of the message received from the sending component with the contents of the expected results message and indicate if they are the same.

Tool Selection

Part of the process of innovation is to consider existing tools and their impact on your problem. When software engineers encounter a problem that has already been solved, they do not solve the problem again, but instead reuse previous stable solutions. In this spirit, we encourage you to seek out and include technologies that will contribute to your solution. Nothing is off-limits as long as it can be legally integrated into your solution between the command line input and the command line output, and legally delivered electronically with your submission.

Design Architecture and Documentation

With a loose set of requirements, this contest is also meant to be an exercise in design architecture. As each group will approach the problem differently, it is important that all participants provide documentation that will allow the judging panel to understand your solution and properly execute your software. Be sure to describe execution details, important directory hierarchy information, location of test images, additional software/library dependencies, and other information that might be important for users of your system.


All participating teams are required to prepare a presentation that will be given on Saturday, January 7, 2012 at Washington-Lee High School as a part of the contest awards ceremony. Presentations should be prepared using Microsoft Power Point or a similar presentation medium, and should focus on how the team has addressed the requirements, problem solution, implementation, execution (demonstration), and their delivery. The presentation will factor into each team’s final score, and can be an excellent way to include less technical individuals on a team.

Your Submission

Your submission should include your solution implement in the Java programming language and any additional libraries or tools that you see fit. Your solution should be submitted through the submission section of this website and will be evaluated based upon performance, correctness, maintainability, usability, elegance and various aspects of your delivery. All submissions are due by 11:59pm on December 27th, 2011 and must include:

  • All source code and compiled classes
  • Additional libraries or tools
  • Software documentation
  • Requirements traceability documentation

Example files

For your benefit, three example message definitions and datasets have been provided:

     File: IDT_fall_2011_contest_xml.zip
     File: IDT_fall_2011_contest_xml_with_namespace.zip*

* second zip file contains namespace tags in data xml in case you are using a parser that requires this attribute.