Software Development: Projects

[article] [edit page] [discussion] [history]

From Humanitarian-FOSS Project Development Site


Projects 6-9: OpenMRS Visit Register Module

The OpenMRS Visit Register Module projects with their deadlines are as follows:

Project 9: Module implementation

Due: 15 December 2008.

Project 8: Partial module implementation

Due: 04 December 2008. You must have the following implemented:

  • A form in which the user enters at least a patient's name, visit date, and weight.
  • A simple report that lists the information provided above.

Project 7: Design document

Due: 14 November 2008. A draft must be submitted by 12 November 2008. The document that is due on 14 November must provide the design (strategy, classes, and sequence diagram) for the following use case:

A user submits valid data representing a visit of a patient. The patient is already present in the database.

You will need at a minimum a command object to represent the data and a form controller to process the data; thus, this is essentially the design of the onSubmit method of your form controller. Follow the message passing as far as accessing objects and services in the OpenMRS API; e.g., show messages being sent to Encounter objects or EncounterServices, but do not show the message passing that the Ecounter object does in response.

Developing this design will definitely require a fair amount of exploration and possibly some preliminary coding. The document you submit should assume that the visit data consists of at least a representation of the patient, the date of the visit, height, and weight (even though your specification no doubt indicates that there is more data associated with a visit). Expect to revise this document as you start implementing; the document at the end of the project will almost certainly not be the same as the document that you submit on 14 November.

The design document must be a single self-contained document; however, you may also commit image files, etc. to the repository as appropriate. Please make sure to contact me if this poses problems (e.g., diagrams too bit).

Project 6: Specification document

Due: 07 November 2008. A draft must be submitted by 05 November 2008. This draft must include all user types, entities, and functionality, but need not provide all details for each. This specification document does not need to provide any information about the user interface.

Submissions will be assessed according to the corresponding rubrics from previous projects.

All documents and code will be submitted by committing them to your team repository. Source code must be committed to your repository trunk, though of course you should feel free to use branches for the development. For documents, create a directory named doc at the top level of your trunk directory. Do this before making any branches. Make subdirectories of doc as appropriate (there ought to be at least spec and design directories). You may use whatever document format you like; however, there must be a PDF version of the latest revision of any document (this is not a normal requirement, but I need to be able to read your documents!).

Project 5: Design

Write a design document for your currency converter application that addresses the following use-cases:

  • The conversion form controller is requested for a backing object to use as a command object for the form view (i.e., the formBackingObject message is received by the form controller).
  • A validated command object is submitted to the form controller for processing (i.e., the onSubmit message is received by the form controller).

The design document will be titled Design for ..., similarly to your Specification document. Don't forget to identify team members! The design document will consist of one section for each use-case. Each section will have the following subsections, matching the presentation in the lecture notes:

  1. The statement of the use-case.
  2. The statement of the strategy used to handle the use case.
  3. An identification of the classes involved in the design.
  4. A class diagram showing the relationships between the classes in the design.
  5. A sequence diagram showing the sequence of messages that are passed.

To submit this project, e-mail me a PDF copy of your document. The e-mail must have subject COMP 342 Submission: Project 5 and specify all group members in the message body. I will not accept any document format other than PDF.

Here is the graing rubric I will use to judge your submission, with topics in order of increasing importance:

Presentation Presentation so poor that it renders the document difficult to understand. Poor presentation; diagrams inconsistently presented; spelling or grammatical errors. Adequately-presented; few issues with diagrammatic notation; tone generally professional. Information pleasantly presented; diagrammatic notation consistent; professional tone throughout.
Strategy and class identification Signficant omissions. Passive voice that indicates an important class not being identified or discussed in the strategy. Leaves minor questions about the role of an identified class. Clearly identifies the classes and describes how they interact.
Diagrams Missing diagrams or significant misunderstandings in how to present information in the appropriate diagram. Non-trivial misunderstandings of how to present information in the appropriate diagram. Minor mis-use of diagrammatic notation. All relevant information correctly displayed using diagrammatic notation.

Project 4: Spring

Convert your currency converter application to use the Spring Framework for its model-view-controller and model-form-controller architecture and database management. Similarly to the petstore examples, you should redirect a request for convert.html to a JSP form that allows the user to specify the conversion to perform and, assuming valid input, redirects the user to a success view with logical name results (which of course will be mapped to a JSP). Unlike the petstore examples, you must have a validator for your form that verifies that the user has provided appropriate input; if not, the same page is now displayed, but with appropriate error messages to guide the user. All Java source code must belong to the comp342.currconv package (or subpackages thereof as appropriate). Configure your data source to use the database jdbc:mysql://localhost:3306/currconv with user name currconv and password abcd1234 (so you will have to configure your MySQL installation accordingly).

I strongly recommend reading the Developing a Spring Framework MVC application step-by-step tutorial and following it from start to finish. That tutorial does a few things that we are not focusing on, and you'll have to work you way through them: it assumes you are using the Eclipse Integrated Development Environment and Ant, and it talks a lot about building testing classes for your application. For the former, you will keep your files properly organized, and will need to compile and build WAR files from the command-line. The latter would be a great idea, but is not necessary. Note that this tutorial also covers using validators for forms. Of course, I am happy to help with any of these issues.

Your submission should consist of a single JAR file that contains at least the directories WEB-INF, db, and src at the top level. It may contain other directories as you feel appropriate, but you may not include libraries for the servlet API, MySQL connector, Jakarta commons logging, or Spring. db must contain a MySQL script for generating the database that your application uses. Your Java source code must all live in subdirectories of src. There must be a subdirectory of WEB-INF named classes; this subdirectory must be empty upon submission.

Here is the grading rubric I will use to judge your submission, with topics in order of increasing importance (this is not to say that Coding style is unimportant---just that your use of the Spring Framework will contribute more to your final grade than your coding style):

Coding style Many major departures from the coding standards. One or two major departures or several minor departures from the coding standards. One or two minor departures from the coding standards. Follows the coding standards in all files.
Submission Did not submit properly at all. Included libraries in the JAR file. classes directory non-empty or unnecessary files included in JAR file. JAR file organized as described above; no extraneous libraries or files in the submission.
Functionality (1) I cannot assemble a functioning WAR file from your submission. I have to make non-trivial changes in your submission in order to

assemble the WAR file; the web application has significant functionality

I can assemble the WAR file with no modifications to your submission, but there are some minor functionality problems. I can assemble the WAR file with no modifications to your submission and there are no functionality problems.
Separation of concerns (2) Many serious mistakes. Several serious mistakes or many smaller mistakes. One or two inappropriate configurations, file locations, or uses of packages. All configuration in appropriate files, files in appropriate places, classes in appropriate packages.
Spring (3) Not using Spring functionality for a major component of the architecture. Inappropriate use of Spring functionality. Some minor mis-uses of Spring functionality. Correct and appropriate use of Spring functionality in all cases.


  1. I will attempt to compile your source code into the classes subdirectory of the WEB-INF directory of your submission using a command-line that compiles all of your source-code simultaneously using a classpath that includes all of the servlet, MySQL connector, Jakarta commons logging, and Spring libraries. I will build the WAR file to contain all top-level directories of your submission except for db and src.
  2. ``Separation of concerns means you understand, e.g., why some Java classes are in one package and others in other packages; why some beans are configured in one configuration file and others in another such file.
  3. Spring functionality consists of using declaratively-configured beans (i.e., beans configured in XML files), the Spring Model-View-Controller and Form classes, and the Spring JDBC wrapper classes.

Project 3: Specification

Sample specification

Grades: Average: 3.2; median: 3.0; standard deviation: .3.

Write a specification for the Currency Converter application that you interviewed me about on 25 September 2008. Below I provide the specification that students in the Spring 2006 offering of COMP 342 wrote. It is reasonable to use this as a template, but it is definitely not perfect. Your specification document must be organized as follows:


The title must be Specification for ..., where ... is the name of the application (make up a nice name). The title must also specify the members of the team submitting the document as well as the date of the document.


This section is a prose narrative describing the application. Give a high-level overview of what the application is intended to do, the intended audience of the application, etc. A good idea is to pretend you are describing the application to your parents when they ask you what you are doing in this class when you see them at Thanksgiving.


This is the heart of the document. It must be broken into the following sections:

  1. Users. Specify and give names to each type of user of the application. Expect to refer back to this section in later sections.
  2. Entities. What are the main type(s) of data manipulated by the application? Give each entity a name and specify the properties/attributes of each entity. Each such property must be named and also be an entity, except those of ``very simple type (like floating point values, strings, etc.). This will look a little like a class definition, but you're really focusing on a user's view of the entity---do not feel that this description constrains how you will define classes in the implementation.
  3. Functions. What are the main functions of the application? Each function gets its own section. It is described first with prose, then specified in terms of input entities and output or results. Specify what user groups are likely to use this function. As with entities, these are the user's view of the functions provided by the application; they may not map directly onto functions in the implementation.
  4. Interface. Specify (narrative form is fine) the interface the various user groups will interact with. You may give pictures of sample interface components if you like.

Some additional comments:

  • All narrative components of your specification must be written in grammatically correct English. There must be no typographical errors.
  • The sections, subsections, etc. of the Specification must be properly numbered. Use cross-referencing to help the reader as appropriate.
  • Specification document for PUMA is the specification document written in the Spring 2006 offering of COMP 342. You should use it as a rough template, but it is not perfect. Under the rubric below, this specification would probably be scored as 3.5/5; the major problem is that it is missing section on the specification (it wasn't required in Spring 2006!) and there are some minor grammatical mistakes.
  • You may e-mail me additional questions about the application. Responses will be private (i.e., you will not see responses to questions asked by other teams). I will endeavor to answer such e-mails promptly. However, I only promise to answer questions that are submitted by 11:59pm Thursday, 02 October by 5:00pm Friday, 03 October. I am unlikely to answer questions on the weekend.
  • To submit this project, e-mail me a PDF copy of your document. The e-mail must have subject COMP 342 Submission: Project 3 and specify all group members in the message body. I will not accept any other document format other than PDF.
  • Grading rubric: I will judge your submission along the following lines:
    Description Difficult to understand the purpose of the application or what it does. Omissions of functionality. Leaves minor questions about the use of the application. Provides a complete description of the application.
    Specification Missing sections or major functionality. Incomplete specifications, significant inconsistencies or incompleteness. All users, entities, etc. specified; some small problems with inconsistencies or incompleteness. Complete and consistent specification.
    Grammar and spelling Many serious mistakes. Several serious mistakes or many smaller mistakes. Some small mistakes. No mistakes.
    Expression/tone Very difficult to understand; tone not appropriate for technical writing. Hard to follow or poor word choices; tone somewhat unprofessional. Generally easy to read and understand; tone generally professional. Clear and concise; tone consistently professional.
    Organization/layout Very hard to find information; layout works against using the document. Difficult to find information; layout inconsistent or not visually pleasing. Little effort needed to find information; layout reasonable, consistent, and generally pleasing. Easy to find information; layout attractive and consistent.

Project 2: Servlets and JDBC


Grades: Average: 3.5; median: 4.0; standard deviation: .9.

For this project, adapt your currency converter so that instead of hard-coding conversion rates into your source code, you retrieve them from a database. In particular, you must create a database named username_currconv, where username is your MySQL username. This database will have at least two tables:

  • A table that describes currencies. The columns of this table will be things like full name of the currency and abbreviation (look things up on You must also provide columns that specify the Unicode value and HTML entity for the currency symbol. You must have at least one currency in the table that has no Unicode value of HTML entity, at least one that has a Unicode value but no HTML entity, and at least one that has both a Unicode value and an HTML entity. When you display the currencies, you must use the Unicode value and/or HTML entity if it is available.
  • A table that describes conversion rates. Each row of the table corresponds to the conversion rate from one of the currencies in the previous table to one of the currencies in the previous table. You do not need to have every possible combination of currency. You must use foreign-key constraints to ensure that the currencies mentioned in this table correspond to currencies that appear in the previous table.

You may need to hard-code your username and password while you are developing. When you submit, leave your username, but delete your password; when I test your submission, I will create a temporary account on my MySQL installation with your username and no password. Be sure to use database connections appropriately. Do not create a new connection for every query to the database; instead use sessions as appropriate to re-use database connections. Your submission for this project will consist of a JAR file which, at the top level, contains the WEB-INF, web, src, and db directories, where WEB-INF is populated with necessary files and directories, web contains any JSP files that you use,

src contains all your Java source code, and db contains an SQL script that generates and populates your database. I will compile your source code myself and put the output in WEB-INF/classes, then build the WAR file and install it.

To create the SQL script that generates your database, after you have created and populated your database, execute the following at the command-line:

$ mysqldump --result-file=currconv.sql -u username -p username_currconv

This will ask for your MySQL password, and then write the SQL to currconv.sql.

Project 1: Servlets and Java Server Pages

Grades: Average: 3.9; median: 4.0; standard deviation: .8.

For this project, you will write a Servlet/JSP-based web application for a currency converter. The initial page will provide a form for the user to fill out in which s/he can specify a starting currency and amount and select from at least four other currencies to convert to. The user must be able to select any non-empty subset of currencies. Upon pressing the submit button, a new page should be displayed indicating the value in the new currencies. The design is mostly up to you, with the following restrictions:

  • The initial page will be accessed from the Converter resource of your web app (which you will presumably map to an appropriate servlet class in the web app descriptor file).
  • The form submission will will either POST or GET the submission to a resource in your web app, which will load a second page and associate a bean to it with the conversion results.

You may hard-code the available currencies and conversion rates. I recommend skimming through the relevant reference documentation and tutorials on the "Useful Documentation" page so that you know what is available to you in case you get stuck. To submit this project, each team should e-mail me the following in a single message:

  1. A WAR file named currconv.war that is your complete servlet. I should be able to upload and deploy this WAR file to my Tomcat instance and run your servlet by pointing my browser to localhost:8080/currconv/Converter.
  2. A JAR file named currconv-src.jar that contains your source code. If you follow my suggestions for a <a href="dev.shtml">directory hierarchy</a>, you can create the jar file with the command jar cvf currconv-src.jar src executed in the project1 directory.
  3. Be sure in your e-mail to specify the members of the team.

A couple of final notes:

  • Do not send me ZIP files! Wesleyan's e-mail server is particularly stupid, and assumes every ZIP file is a virus, and therefore automatically removes them from e-mails.
  • As for all projects, this one must meet the coding standards in the document in the Handouts section.
Personal tools