Mecheng401:MidYearReport

Due Wed 28th May, 5pm

Template/proposed outline can be found on Engineering S: Drive

We should work on separate sections and combine them together by 2pm Wednesday.

The following sections are desired:

• Cover page - Nick

• Executive summary
  • To be done together once all parts have been collated

• Introduction - Nick. I will cover all this area.
  • Objectives
  • Problem identification
  • Approach to solving problem

• Team progress to date - Mark and Shaun
  • Conceptual analysis - Shaun
  • Literature review - Each of us can talk a little about the research we did at the start e.g gears etc
  • Methods - Shaun
  • Results of any brainstorming experiments or testing - Mark
  • Conclusions so far - Mark
  • Description of work planned for semester 2 - Mark

• Contribution
  • Written individually

Please carefully read the handout on the S: drive for a more complete explanation, and where possible follow the style , plan and objectives etc set out in our earlier report/proposal.

Marks Section

Results of any brainstorming experiments or testing

While developing the database application for the Auckland City Council, a couple of prototype interfaces were developed. This was to determine how feasible they were to implement and if they could deliver the required functionality. Both designs were based upon screen diagrams of what how the Council envisioned the system would work. We developed a Java Swing application as well as a JSP web system.

By developing these rapid prototypes we were able to get feedback from the council as well as get a better idea of what was involved in further development of the system.

Java Swing application

Figure 1 Swing Application Main Screen

Figure 2 Swing Application Search Screen

Figure 3 Swing Application Upload Data Screen The first interface we developed was written in Java and using the Swing library. This allows us to produce an application which looks and feels like standard programs users are familiar with. Using Java to write the application meant that development time would be quicker (owing to the relative experience amongst the development team), and the program could be used across different operating systems. This was the type of application the client ultimately envisioned would be produced.

While developing this system we found the interface development would not be as easy as we had hoped. The laboratory computers which were being used for development lacked tools for developing GUI applications. Netbeans IDE is one such tool installed on the lab computers but appeared only to support the Ruby programming language. The GUI work that was done, was produced using an Eclipse IDE plug-in outside of the labs.

At this stage we suggested reducing the hierarchy of information and merging a few of the screens. On the main screen *figure 1* there were three separate links. We proposed first merging the pages for creating a report and uploading data as these largely the same. We then proposed moving the search directly to the front page. This would reduce the number of pages a user would have to navigate through to get to the information they were interested in. This was also in line with creating reports or uploading data, as a search would have to be done anyway to check if a building already existed. The final suggestion we made was changing to a web based system. We had initially considered developing a web interface but the major limitation of this is that it would require a web server to be installed on each machine wanting to run the application. Due to developments with the database, it became apparent that a database server would have to be installed on each users machine. This took away the ability for us to create a light weight executable and as such, installing a web server was not much of an additional hindrance.

JSP web system

Figure 4 JSP System Main Screen

Figure 5 JSP System Structure View Screen The second interface we prototyped was a dynamic web interface written in JSP. This allowed us to generate web pages with Java. The team felt this would be a better approach because they were overall more comfortable developing web based interfaces.

Unlike internet sites, the web pages created by this system would be generated on each user’s machine and not served over the internet. This will allow engineers who are out of the office and conducting IEPs,  to enter the information on a laptop, without being connected to the internet. An added benefit of a web based system is that it could potentially be hosted over the internet and made accessible to any device with an internet connection. This will allow any person with access to the internet, and the appropriate credentials, to conduct IEPs without installing any additional software. When the system is made available to the public, rather than develop an additional system, it would be possible to use the existing web interface with a limited set of access.

When the prototype of the web interface (####) was shown to the client and mechanical students, concern was raised about how to more effectively search for buildings, e.g. by postal code. The mechanical students also expressed concern about how the information will be entered. A limitation of the web interface is that it will be difficult to represent tabular data in a sortable form, as desired for the search results.

Conclusions so far

The sky is falling.

Description of work planned for semester 2

By xx xx xx, the end of semester 1, we should have a functional web interface capable of recoding an IEP. From this working base, semester two will involve improving upon the existing interface by adding functionality around searching, logging in, and dealing with attachments. Finally the most academically challenging part of the project will be implemented, which is to synchronise a central database with the databases installed on each of the site engineers computers.

Interface work

The current search interface only supports a few query fields such as house number, unit number, road name and structure id. This will be expanded upon in an advanced search query page with query fields for each possible field of information. A login system will be implemented that will restrict access to the creation of IEP reports and modifying information, to council workers with credentials. Lastly the ability to add attachments with accompanying user notes will be added. Every building will have photos attached to it and possibly a number of additional documents such as building plans. A system involving a page of thumbnail previews for photos, and a navigation view for attachments will be added. If time permits, the ability to annotate photos with notes or indicators will be added.

Database synchronisation

The main task for semester two will be to synchronise a central database with databases created on each of the site engineer’s machines. Using logs created by PDStore, the modifications to each localised database will be sent to a central database. These logs will need to be interpreted and the transactions replayed on the main database. When two transactions conflict a suitable method of resolving the conflict will have to be investigated.

---

Section of Shaun

Conceptual Analysis

On a conceptual level, the project consists of creating a data-retrieving and storing system with three different login privileges. The main components are the central database, which holds the building information, user interface through which the users can enter or search for information and the server layer that connects the user interface to the database. After some discussion it was decided that some form of 3-tier architecture needs to be used (see Figure X). Therefore, the initial challenge was to decide what technology should be utilised to implement each of the major components of the system; the database, server and interface. Some of the options yielded by the initial research phase included Google Gear, Adobe Air and Lotus Notes. Brief descriptions of the findings are described in section X.X. After carefully considering each of the possible options it was decided that none of these available packages served the project’s purpose. The main functionality required by the system was the capability to retrieve and store building information offline and the automatic updating and synchronising of the main database when the user goes online after making some changes to the offline local database. Since this functionality was not the main focus of the researched technologies, it was concluded that the system will be independently developed. As previously described the chosen technologies of implementation were Firebird database coupled with PDStore, and JSP/Servlet for implementing the user interface and server-side processing. Figure X shows how the proposed technologies fit in together to create the required 3-tier architecture for the system.

• PDStore: Database management layer created by Dr. C. Lutteroth allows…

• Firebird Database: this free database was chosen because it supports all the functionalities required by the system and PDStore is configured to work with Firebird by default

• JSP/Servlet: Java and JSP is free to use and all the team members have prior experiences working with JSP and Servlets. Therefore, Tomcat server will be used as the application server. Tomcat allows server side interpretation of Java classes and JSP scripts.

In summary, the conceptual 3-tier design was used as a starting point to decide what technology is appropriate for each of the components. The technology was carefully chosen after comparing different options, ensuring all the requirements can be met, and putting the individual components produced the basis of the overall architecture that can be used to begin developing the prototype.

Research

Google Gears Google Gears allows offline viewing of websites. Basically, it saves the contents of designated websites in the local database so when the user tries to view the content offline, locally saved webpage content is loaded instead of the browser trying to directly access the online content. It consists of three major components.

• Local Server: This decides, depending on the user-defined mode, whether the web browser should access the saved data from the local database or access the Internet content directly

• Database: This local database saves the content of designated website content. When the Local Server directs the browser to the database, the saved content is displayed.

• Worker Thread Pool: Handles synchronization. If the user made changes to the local database, which means the main database and the local database are inconsistent, the Worker Thread Pool runs in the background, automatically updating any changes made to the main database. This function allows the users to make changes even when in offline mode.

Google Gears seemed to be the most appropriate technology for the purpose of this project. However, its functionalities are more in favour of simple web browsing purposes. Since our system relies heavily on information storage and retrieval using the central and local databases, more database-centric technology was required to implement the desired system.

Methods

The implementation methods are largely divided into four segments

• Work environment setup: The implementation is collaborated amongst the team members through a SVN server. The code repository is setup in a way that all members can read and write to the folders. The major development is carried out using ObjectWeb Lomboz for JavaEE Development. It is simply the Eclipse IDE with added features that allows easy development environment setup. For our purpose, it was necessary to run a local Tomcat server so we may run the JSP and Java files. Lomboz comes pre-packaged with a Tomcat server so there is no need for separate installation.

• User interface: User interface refers to the part of the system with which the users directly interacts. Since the system is a web-based, the interface is implemented with HTML and CSS. Dreamweaver program is used to generate HTML components and CSS files. The ultimate goal for the UI component is to make the system as appealing and user-friendly as possible while preserving all the necessary requirements.

• Information retrieval and storage: Information retrieval and the storage are the two most important functionalities of the system. The building information is stored into the Firebird database through PDStore. The website forms are setup in a way that any user input is saved as a Java bean. When submission is made to the database, the values contained within the beans are transferred into the database.

• Database:

(picture for each bullet point... easier with pictures I think)

IEP - storing/retrieving example

An example of building information storage and retrieval can be portrayed through the IEP process. In order to assess the seismic grade, which indicates the level of earthquake-readiness, building information is entered into forms after which the grade is calculated automatically. The building information can include the date of construction, type of soil, date of design and seismic zone. Some buildings will already have existing building information stored in the database so these values are pre-populated into the forms. The users can then complete the form in order to calculate the seismic grade. The information can then be transferred into the main database for future reference and further planning. Figure X shows a typical storing/retrieving process involving multiple forms. JavaScript is used on form components to automatically calculate values or generate constraints. For example, Figure X shows how the checkbox Drawings (note type), when checked generates an additional field below for the users to enter in the Drawing Types. These dynamic form generation and calculations are implemented using JavaScript. In order to persist field values across different web pages, Java Beans are used. The Beans contain user defined values of form fields. An example of a conceptual Java Bean instance is shown in Figure X. Once the form fields are filled out, the information is submitted to the main database through the PDStore layer. The stored data can later be retrieved using the search functions on the website.

Nick's section

Introduction

The introduction should concisely provide the following information:

Objectives of your project: concise statement of your client’s needs, constraints, and resources

Our client is the Auckland City Council (ACC), and our contact is Patrick Cummiskey, a special projects officer???

The Building Act 2004 states that territorial authorities such as city councils must have in place a plan for dealing with earthquake prone buildings. Therefore, the ACC needs a way of identifying which buildings are earthquake prone to aid in their decision making process.

In order to identify these buildings, the council workers have to survey likely buildings in the Auckland region to assess and classify them according to certain criteria set out in the Building Act 2004. This initial analysis process is known as the Initial Evaluation Procedure (IEP).

Currently the IEP's are done manually and they are both time consuming and costly. They are stored persistently on paper, with printed photos and plans attached.

This project aims to research, design and implement a software system to support the process of data input, data analysis and report generation for the IEP.

The constraints are that the system must be available for use by council staff or contractors 'on site' with a laptop, that is with no Internet connection, and that changes made by multiple users can be merged and stored together on a central database. It must be possible to carry out multiple IEPs on a building, and have the results of that IEP available forever after.

The resources that we have available are all being provided by the University of Auckland, and are limited to computing resources, including a subversion server where we can store our code. If or when this project is deployed, it is assumed that the ACC will have a physical machine connected to the local network and/or Internet, where a central database and web server can be hosted.

The objectives of this application are 2 software components:

1) A web based interface for inputting and viewing building data, searching on this data, and performing the IEP process.

2) A database which can store all of the necessary data, and facilitate the merging of multiple sets of IEP data.

Problem identification

Problem identification: concise statement of the specific problem(s) you have been addressing

In the project proposal several specific problems were outlined , the first of which was the identification of the correct technology to use to implement this solution. This problem has been overcome. A Firebird database, coupled with the PDStore data management layer designed and implemented by Dr. C. Lutteroth, will be used to store and merge the building data. We will use

Problem is recording data on a building, performing complex calculations on it, and determining if it is Earthquake prone according to the Building Act 2004. The reports and conclusions generated by this process must be stored and easily search able. Currently they are being stored in hard copy files. This may continue for legal archiving type reasons.

We could create a DB and have council workers enter the data manually, and perform calculations manually, and input the results, but this isn't good enough. Additionally we would like to be able to perform this assessment anywhere and any time, so that it can be done on site, rather than recorded and input later as this is double handling.

It would also be nice if a selected subset of this information was available to members of the public.

The input, storage, manipulation, calculation, displaying, reporting, of building data. Web page to access data.

Approach to solving problems

A concise statement of how you are approaching the problem(s).

The team held irregular meetings with client and other stakeholders, and information generated there drove progress towards the next meeting. Informal requirements were gathered through discussion. The software team members allocated work among themselves and aimed to work together, but often worked apart due to time constraints and other issues. This led to duplication of work, or incorrect work being done due to miscommunication or misunderstanding.

The new approach to completing this project is more structured, with regular student meetings and structured requirements. The first aim is to get a working prototype of the database and IEP application create and distributed to the part 4 Civil Engineering students, who can use it as part of their part 4 project, gathering IEP data. From this we can get feedback to allow us to iteratively continue development and refinement of the product.

The problems we must solve and suggested solutions:

• Data recording, displaying and manipulation.
• JSP web pages, Java code

• Database for storing data and synchronising changes
• Firebird with PDStore

• Synchronisation
• PDStore

My literature review

Considered Adobe AIR as a solution to the database problem. AIR is a framework for developing RIA, or Rich Internet Applications, with powerful features that allow web style applications to run like native desktop applications when not connected to the Internet. It has a build in SQLite database, which can be used for local caching of data. Reasons for deciding not use AIR are:

• It has limited support for direct access of the database
• It is limited to only the SQLite database
• It has security implications with it's new sandbox model that may limit what we can achieve
• The database has no support for merging or synchronising

Database-y stuff

Firebird with PDStore. 4 main tables. One for general information about a building, one to contain specific information for an IEP. There is a one to many relationship here. Other to contain photos and attachments, also one to many??. The general building information table also stores selected key values from the most recent IEP, to allow easier searching and data displaying. Problems were found with learning the PDStore system, as it was unfamiliar to us. Dr Lutteroth helped a lot with explanations, examples and improving the documentation in the code. We cannot use Firebird on the computers in the labs at the University, so Mark has a database running on his home computer which we can access through the Internet.