Work thus far this week

This week, we began brainstorming and writing scenarios on Monday and Tuesday. On Tuesday we started putting together a UML class diagram to help us wrap our heads around the details of what our framework would do in each scenario. We've been thinking about the overall design and all of the classes that we would need for our framework to work in a reasonable fashion. We hope to finish the UML diagram later today and work on getting a couple more scenarios written up.

Scenarios

We need to create scenarios for several calls on the framework. We'll post them here.

Iteration Meeting

We discussed about expounding the "update" use case. How will we append an extra MDO? Will this require changing the framework or extending the framework? There is a possibility that this process needs to be documented for the "application programmer". This lead us to come up with different actors...

• framework developer
• application programmer

Professor Pollice decided our use cases needed to be more detailed, especially on the interaction between our framework and google maps/mapping services/other services during which the use case would be realized.

Added e-mail notification to blog

I added e-mail notification to the blog so now it should be easier to keep updated with our progress.

Some DocumentWorthy Progress

I just committed some code to the SVN repository. I believe it was significant enough for me to post because there are some major changes and additions I made to the code that may not be clear just at glance. Here are my commit bullet points...

• - Added JavaDoc to all existing classes

• - Refactored testing to the appropriate test package instead of using a main method

• - Added GenericDao.java so far for the DAO pattern, more work needs to be done, but it is functional as of now

• - Added log4j properties file and added logging for testing, this also means greater control in hibernate debug messages. By changing the properties files we can turn on logging to a point that every single transaction is shown in the log, it also allows for us to redirect the logging to a file (which will be useful in production)
  

• - Refactored Hibernate Annotation mapping into HibernateUtil.java

• - Added the "new SchemaExport()" line when initializing HibernateUtil so we can programmatically change if the tables are being dropped and recreated. This is in direct response to the original code that would keep dropping and recreating tables. I later found out this was specified in the XML and even though XML and programmatic means may mingle, I decided on deleting the XML config for this particular function and specify this configuration in HibernateUtil.
  

DbUnit for testing and moving datasets

There was the belief that hibernate would make our dataset portable to any underlying database. However, it seems that out-of-the-box, Hibernate does make our framework portable but not the dataset. This meant we would have to either write importers or exporters for our specific schema. Well, it seems that this JUnit extension called DbUnit @ http://dbunit.sourceforge.net/ solves the problem. It is also a maven plugin where it can both export and import large datasets using XML during testing to prevent data corruption. It uses the JDBC driver so it will be DBMS agnostic. Of course this will help us in unit testing as well.

More detailed use cases posted

More detailed use cases for our framework have been posted on SourceForge:
https://sourceforge.wpi.edu/sf/go/doc6265?nav=1

This covers all of the use cases we could think of when going through scenarios where our framework would be used.