In this iteration have set up Hibernate with Eclipse based on a Derby Database on our local machines. At this time we are not sharing a database to allow us to experiment with the database without breaking everyone else's database.
We have written JUnit tests for our core functionality, our model package. These tests all fail as expected. We have chosen to code defensively due to the sensitive nature of our data and the need for it to be accurately represented in the database. The JUnit tests reflect this decision. Our tests will attempt to pass bad data, null data, or the class being tested will have bad data. The exceptions thrown will be handled in the UI.
In this iteration we had planned to implement xml parsing. In our further research into JIST and MIPAV we discovered that this could be done before passing the data to our Java code. Our extractFields method of our XMLImageData will then parse the output file given by MIPAV as a hashtable.
We had planned to implement data correlation in this iteration, but setting up the database took longer than expected. Due to compatibility issues we ended up having to use Hibernate 3. We will implement this in iteration 4
We created a basic JIST module to understand how our module will work with the existing software.
In this iteration we created a basic JIST module that provides the main user interface. The module defines the user's view of the functionality and allows the user to send inputs, such as subject information (age, gender, demographics). We aim to have our module chain with JIST’s other modules for image processing and storage. This involves allowing database administrators to upload data folders, automatically organizing and correlating data and image processing.
We have created a swing GUI that will be the main interface for the database administrator. The GUI is not completly integrated with the Hibernate database. Currently we are able to add users from the database administrator's GUI
The current JIST Application can either be run locally, as we are doing for development, or in a lab setting remotely. For this reason we do not need to implement a client/server interface for JIST. Our addition is the database, which should be run on its own Database Server. We selected Derby as our database since it can also funcion as a database server. In order to create a centralized database we would need to deploy Derby to a dedicated host. Then, on the host, change the hostname in the derby.drda.host property so that is not localhost and therefore accessable from other machines. In order to connect this with our model code we need to change the database connection URL in the hibernate.cfg.xml to the host we chose for Derby. Unfortunalty we do not have access to a machine that could serve as this remote host. So we will continue to use local databases that we periodically sync. On our computers we will run Derby as a database server on localhost. We have included the diagrams for the client/server/server/database interface.
We are still working on integrating Hibernate with JIST. We have implemented database queries using the Hibernate Query Language. Once we connect the user inputs with the database manager, the manager will allow authorized users to dynamically retrieve data used for image processing. We are still working on providing access control (username/password) for the database user.
Alpha Release
The database will have access controls and allow only database administrators to log-in. In this release the database adminstrator will be able to add images, test results, and demographic data to the database. Automatic image processing will not yet be completed, but the data will be corrolated and orgainzed. The database aministrator will also be able to register new users and database administrators.
Users will be able to access the Hibernate database through the JIST interface. We will provide access control from the users to the database. The users will be able to specify image processing algorithms and produce a report.
Beta Release
The program will have all features. If time allows we will implement database versioning.
Please click here for the JavaDoc Documentation
Please click here for the database tables
Please click here and here to download the source code
Interaction Example
The user can use the parameter panel (bottom left) to query the database and receive the data that fit their criteria. The interface have several tabs that contain parameters about various classes of information that relate to the image and experimentation data.
User interface example:
Subject parameters tab:
Image parameters tab:
For now, the module just outputs the user input to a text file. In the future, the user input parameters will be used to query the database.
Please click here for an example output file from this module.
Image headers contain information about various properties of the image such as orientation, resolution, modality, directory etc. The header files need to be parsed to add these information to the database. We have written another module that takes an image (of any format) as an input and parses the header to collect the useful information. In the future, this module will be incorporated into the database management module. For now, it just returns some of the image header content (there are many types of information contained in the header that won't be necessary to the database) in a text file.
Image Header Parser Module:
Please click here for an example output file from this module.