Project 3

Due date: Thu 2 May

Overview

In this project, you will develop a message-based model of a simple student-response system (classroom clickers).

Objectives

An understanding of
  • message queues
  • message-based service integration
  • patterns of (message-based) enterprise application integration

Project Description and Background

Classroom clickers are a simple, inexpensive way to bring interactivity into the classroom. A clicker is a hardware device that resembles a remote control but includes a small (usually LCD) display in addition to several response keys. Each classroom has its own channel to which students in the room should set their clickers. To query the students, the instructor opens a poll on the instructor console and verbally or visually expresses a multiple-choice question; the students then press the key on their clicker that corresponds to their answer and receive confirmation that their response has been received; the instructor then closes the poll, and no further responses are accepted. This process can then be repeated with other questions as needed.

Further background information is available here:

Functional Requirements

The device you will model in this project is described here.

Your system will have a simple text-based interface (CLI) to control the instructor console and the clickers. Valid commands are
  • clicker N channel C - set the clicker with the given number to transmit on the specified channel
  • clicker N respond R - send the specified response from the clicker with the given number and (asynchronously) report whether or not the system has confirmed that it received the response
  • classroom C open R - open a poll in the specified classroom with the given number of possible answers (numbered from 0 to R - 1)
  • classroom C close - close the poll and print the number of responses for each possible answer
In any one classroom, there can be at most one open poll, but polls in different classrooms can overlap in time. Also assume all clickers have already been registered.

Your system should be configured to include three classrooms numbered 70 through 72 and five clickers numbered 500 through 504. Here is an example session with such a system; system responses are shown in italics.

clicker 500 channel 69
clicker 500 channel 70
registered on channel 70
clicker 500 respond 2
channel 70 not accepting answers
classroom 70 open 5
clicker 500 respond 7
channel 70 received invalid answer from clicker 500
clicker 500 respond 4
channel 70 received valid answer from clicker 500
clicker 501 channel 70
registered on channel 70
clicker 501 respond 2
channel 70 received valid answer from clicker 501
classroom 70 close
responses: {0=0, 1=0, 2=1, 3=0, 4=1}

Architectural and Other Nonfunctional Requirements

Please use the SoccerStadiumActiveMQ example from the repository as a starting point for all aspects of this project, including the text-based interface. Similarly to the example, your system should model classrooms and clickers as separate objects.

Furthermore, the following nonfunctional requirements apply:
  • Communication among components is provided using a suitable message queue implementation. 
  • To increase reusability, the PO(J)Os (components providing the logical functionality) should be architecturally separate from the wrappers that connect them with the message queue and the CLI.
  • The system should include component-level unit tests of the PO(J)Os as well as integration testing of the entire system. (The example above could be one integration test.) To facilitate integration testing, consider developing a console object with methods corresponding to the CLI commands and expected responses. The CLI itself would then become a thin layer on top of this console object.
If using Java, these additional requirements apply:
  • The project is managed using Maven.
  • The system is configured using Spring.
  • Communication among components is provided using ActiveMQ (an embedded instance is recommended) through Spring's JMS support.
If not using Java, you are expected to use a suitable build tool, dependency injection mechanism, and message queue implementation. Please check with the instructor if in doubt.

Deliverables

  • Complete working code, including automated unit tests, checked into the repository
  • Documentation checked in as a README file with the code or in the wiki section covering at least these items:
    • programming language(s) used in the code and version(s) (important), e.g., Groovy 1.7.6
    • list of all external dependencies and, if applicable, installation instructions
    • IDE and operating system used to develop and test the code, e.g., Eclipse 3.6.1 on Mac OS X Snow Leopard
    • project architecture and implementation

Extra Credit

Your project will be considered for extra credit if you configure and demo it in such a way that it is physically distributed, that is, some system components run on two or more physical (or virtual) machines.

Comments