Software Development: Projects

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  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

objects or s, but do not show the message passing that the 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 at the top level of your trunk directory. Do this before making any branches. Make subdirectories of  as appropriate (there ought to be at least  and

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  message is received by the form controller).  

A validated command object is submitted to the form controller for processing (i.e., the  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:   The statement of the use-case. </li>  The statement of the strategy used to handle the use case. </li> 

An identification of the classes involved in the design. </li>  A class diagram showing the relationships between the classes in the design. </li>  A sequence diagram showing the sequence of messages that are passed. </li> </ol>

To submit this project, e-mail me a PDF copy of your document. The e-mail must have subject 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:

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 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  (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 package (or subpackages thereof as appropriate). Configure your data source to use the database with user name  and password

(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,  , and  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.

must contain a MySQL script for generating the database that your application uses. Your Java source code must all live in subdirectories of. There must be a subdirectory of  named  ; 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): 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 problems. 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. Notes: <ol>  I will attempt to compile your source code into the subdirectory of the  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

and. </li>  ``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. </li>  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. </li> </ol>

Project 3: Specification
<p style="text-align:center"> [[media:currconv-spec.pdf |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: 

Title
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.

Description
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.

Specification
This is the heart of the document. It must be broken into the following sections: <ol>  Users. Specify and give names to each type of user of the application. Expect to refer back to this section in later sections. </li>

 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. </li>  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. </li>  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. </li> </ol>

</dl> Some additional comments:   All narrative components of your specification must be written in grammatically correct English. There must be no typographical errors. </li>

 The sections, subsections, etc. of the Specification must be properly numbered. Use cross-referencing to help the reader as appropriate. </li>  [[media:puma-spec.pdf |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. </li> <li> 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. </li> <li> To submit this project, e-mail me a PDF copy of your document. The e-mail must have subject

and specify all group members in the message body. I will not accept any other document format other than PDF. </li> <li> Grading rubric: I will judge your submission along the following lines: </li> </ul>

Project 2: Servlets and JDBC
<p style="text-align:center"> [[media:Project2.zip|Solutions]]

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, where is your MySQL username. This database will have at least two tables: <ul> <li> 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 xe.com. 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. </li> <li>

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. </li> </ul> 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,  ,  , and directories, where  is populated with necessary files and directories, contains any JSP files that you use,

contains all your Java source code, and contains an SQL script that generates and populates your database. I will compile your source code myself and put the output in , 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.

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: <ul> <li> The initial page will be accessed from the resource of your web app (which you will presumably map to an appropriate servlet class in the web app descriptor file). </li>

<li> The form submission will will either  or  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. </li> </ul> 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: <ol> <li> A WAR file named 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

. </li> <li> A JAR file named  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 executed in the  directory. </li>

<li> Be sure in your e-mail to specify the members of the team. </li> </ol> A couple of final notes: <ul> <li> 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. </li> <li> As for all projects, this one must meet the coding standards in the document in the Handouts section. </li> </ul>