CS 589 – Course Project Phase 2

1 INTRODUCTION
In this phase, we are going to have to use our skills on a real problem and a novel platform (yes, that
doesn’t happen in a CS course too often, so enjoy!!!) on our Galileo boards. You are required to implement
your designs on your boards.

2 PRE-REQUIREMENTS
If you are reading this, it means you have submitted your Phase 1 deliverables. At this point, you have a
design that can be implemented as the next step. This phase of the project aims to implement onboard
functionalities. Note that this document is not going to limit your creativity and problem solving skills by
defining strict rules for the implementation and the functionalities. As long as you integrate the basic
functionalities mentioned in the Phase 1 document in your application, you may assume that you have
satisfied the functional requirements. But you must make sure that your design and overall plan indeed
support the requirements. If you think there are any problems with your designs, please contact the TA
before proceeding with the implementation.

3 REQUIREMENTS
The requirements for this project can be divided into functional and non-functional. Functional
requirements are those that were mentioned in the documentation for Phase 1. They will stay the same
throughout the project. Your “functionality grade” is based on the implementation of those requirements.

You also have to deal with non-functional requirements. In this phase, this boils down to the connection
between your design documents and implementation. In turn, this will contribute to the emergence of
the project’s actual non-functional requirements. So, be sure to verify that your programming language
of choice for this project, and, if applicable, your chosen framework or libraries support your design
decisions. In this part, you will be graded based on the logical, unified connection between your designs
and your implementation code.

Since the Galileo boards have a decent amount of computing power, you do not need to worry much
about the performance of your system and its response time. This will only be an issue if your design
and/or implementation have a really pronounced bottleneck. In any case, you have to choose a method
to measure the response time of your application in different situations after your implementation is
complete.
4 SAY “HELLO” TO PRISM
In order to show an example of a logical connection between your design and implementation, we are
going to introduce a case study using the PRISM middleware platform. Consider the following architecture
that covers a set of basic functionalities on a board.

The designer has decided that components in this architecture use message passing to communicate. This
may or may not be the case in your set of decisions. In this case, we can use PRISM. This tool supports the
design. Look at the code below:
This code can be mapped to my design easily. Every component has a handle function that will handle
incoming messages – exactly as the design in this case specifies. This type of implementation has the
added advantage that it would not need much explanation regarding how the code mirrors the design,
because this is mapping is reflected directly in the implementation, as shown above. However, there
maybe be some cases that are not this intuitive. Please include enough explanation for us to understand
your logical mapping in the project.

Since it has been asked multiple times, it is worth reiterating that you are not required to use PRISM or
any other specific middleware or programming language. You can use the option that you think is the
best for the project and a middleware, library, or toolkit that supports your architecture.

5 DELIVERABLES
You will have to turn in two artifacts:

1. the code and

2. its documentation.

5.1 PROJECT CODE

This is you complete project code, comprising all of your onboard functionalities. You can either send us
your version-control link in your documentation (e.g., the Github URL), or you can just compress your
project directory along with your documentation and upload that.

5.2 PROJECT DOCUMENTATION

The documentation should include the details of your implementation discussed in this assignment. Your
choice of programming language, framework, or toolkits, along with your design mapping, are example
such details. If you have done so and have covered these issues in your first homework, just may refer to
it or copy it here as well.