CIS 542 - Summer 2011

Group Project Description


In this project, you will work with up to two other students to develop a system with "embedded" and "mobile" components. The goal of the project is to create an Android application that is able to get data from and send control information to a remote temperature sensor.

Please note: This document will change over time as the requirements are refined and more details are provided to you. Please ask a member of the instruction staff if you have a question about anything described here.


System architecture
The system shall consist of three major components, described as follows: Note that because of firewall restrictions on the SEAS network, if you are running your middleware component on a Linux machine in the lab, you must use port 3001 for your server, and it can only be accessed by devices on the SEASnet network. Please be sure to discuss this with a member of the teaching staff if you are unsure.


Functional requirements
Your system must fulfill all of the following requirements:


Additional features
In addition to the functional requirements listed above, your group must come up with two other (non-trivial) features to include in your system. One feature must involve sending a control message from the user interface to the sensor; the other feature must involve the processing and/or display of the data that is sent from the sensor to the user interface. Please discuss your additional features with the instructor before proceeding.


Non-functional requirements
In addition to satisfying all of the above requirements, your system should also meet these criteria:

You may assume that all components are "dedicated" to each other, e.g. that your middleware component will never need to serve a different user interface, and that your user interface will never need to connect to a different server.


Because of the short schedule during the summer period, it is important that you make steady, continuous progress towards your final system. Each Thursday there will be a "milestone" that your group should meet, as described below.


Milestone #1: Progress Report (July 28)
During this evening's "lab session", your group will have a 10-minute meeting with the members of the instruction staff. You do not have to do a demo at this time (though you can, if you'd like), but you should by this point have most of the functionality completed, except of course for the Android user interface. That is, you should have an Arduino program that can communicate with your C program (the middleware), which in turn can communicate with a standalone Java application.

During this meeting, be prepared to discuss issues such as:


Milestone #2: Front-End Prototype (Aug 4)
By this point, you should have completed a simple Android app that is able to use the Java code you've written for the previous milestone to get information from the middleware component. Your group will have a 10-minute meeting with the instruction staff in which you will demo the prototype your Android app (either running on the emulator or on the physical device). The prototype should, at the very least, allow the user to see the most recent temperature reading.

During this meeting, you will be asked about:


Milestone #3: Final Presentation (Aug 11)
On the last day of class, your group will present your application and discuss your implementation decisions.

Your demo and presentation should be a maximum of 10 minutes, with an additional 5 minutes at the end for questions and discussion. Please rehearse your demo/presentation and make sure you can complete it in 10 minutes! It is not necessary for every member of your group to speak during the demo.

The point of the demo is to show off your work, to impress the instructor, and to make your classmates feel bad because they're not as smart as you are. A boring nine-minute PowerPoint presentation followed by a one-minute demo of an application that only half works is a surefire way to fail to do any of those things. Try to keep the PowerPoint to 2-3 minutes, and then spend the rest of the time showing all the cool features of your application and discussing how it works. You should do a live demo using the Android emulator (since it's easier to project onto the screen) but also show the app running on the physical device so we know it really works.

After all the demos are completed, students will vote to decide which presentation they thought was best (no, you can't vote for yourselves). Whichever team has the best demo will receive extra credit points. And, obviously, the pride that comes along with being recognized by your peers.


All deliverables are due by Sunday, Aug 14, 11:59pm EDT. Late submissions will be penalized by 10% per day, and may result in a delay in posting your final grade.

Your final deliverables should consist of the following:

Source code
Submit all Arduino, C, and Java source code in three separate tar/zip files (as described below). If you use third-party libraries (which have been approved by the instructor!), only submit those in compiled form. Please be sure that all of your code is well-commented so it is easy for the grader to find where different features are implemented. Remember: happy graders give higher grades!


You must use the following tools to analyze your C program (the middleware): To get meaningful results out of the analysis tools, run your system for at least one hour (yes, seriously) with each tool and exercise the middleware either by actually using your front-end app or -- to reduce insanity levels -- by writing a small Java program to simulate "normal" usage. Note that you may be able to combine the usage of some the analysis tools so that you don't spend five hours doing this.

In your analysis writeup, include all outputs of the different tools and analyze the results. If Helgrind or Memcheck reported an error, did you do anything to fix it? If not, how is the error mitigated/avoided? Does Massif reveal anything unexpected, for instance wasted (un-"useful") memory or potential memory leaks? Are the results from gprof as you expected, or can you improve performance by focusing on some of the more commonly run functions? Does gcov reveal any unexpected execution traces, e.g. error code that you did not realize was being called, or perhaps dead code that is not used? You can, of course, include "before and after" results of the tools if you use their output in order to improve your system.


Technical documentation
This document should explain how your system "works". This should include:


User documentation
This document explains how someone would use your Android application. Do not assume that it is "intuitive"!


Return all hardware
You must return the Arduino board(s), temperature sensor shield, USB cable, and Android device (if your group borrowed one) before you can receive a grade for this assignment.

Academic Honesty

You should be working with the other two members of your group project team, obviously. However, you may not discuss or share solutions with students in any other groups, nor should you be receiving any help from outside sources, including students not taking this course or online resources. If you find help online or use third-party code as part of your solution, you must cite it. Failure to do so will be considered academic dishonesty, and your team will receive a grade of 0 on this assignment (which pretty much means you'll all fail because this is worth 50% of your final grade!).

If you run into problems, please ask a member of the teaching staff for help before trying to find solutions online!


Your score will be out of 100 total points, broken down as follows:


Functionality (40 points)
Each of the ten functional requirements (the eight specified above, plus the two that your group came up with) is worth four points.


Non-functional Requirements (10 points)
Each of the five non-functional requirements (listed above) is worth two points.


Individual Responsibility (10 points)
In your final documentation, please specify which member of the team is responsible for (a) the back-end, (b) the middleware, and (c) the front-end. Please use these three categories -- do not make up your own! -- and only assign one team member per category (unless your group does not have three members, of course). Each part of the system will be assessed on its own and graded based on the quality of the code. Note that you may lose some points for a poorly-implemented solution (e.g. unnecessarily wasting memory, network bandwidth, battery power, etc.) even if the functionality appears to be correctly implemented from the user's point of view.


Presentation/Demo (10 points)
Your presentation should clearly describe: what new features you added; algorithms and data structures you used for processing and storing data; the structure of your communication protocols; the results of your analysis. The demo should show a fully-functional system running on actual hardware with all features implemented.


Analysis (15 points)
Each of the five analysis tools (listed above) is worth three points.


Documentation (15 points)
The technical documentation is worth 10 points; the user documentation is worth 5 points.


All deliverables will be submitted via Blackboard. You should submit a single zip/tar file that contains:

Updated: Mon, July 25, 12:22pm