Second Iteration

After gathering feedback from our client regarding our first iteration, we made the changes he requested as well as continuing to add more functionality according to our requirements list. Once our second iteration was complete, we had fulfilled the following requirements:

  • RQ1: The application must be a data dictionary editor
  • RQ2: The application must be able to create a data dictionary (logical and physical) for the required system e.g. for a customer system or for a payroll system
  • RQ4: The application should ensure that the data dictionaries can handle the versioning of systems
  • RQ10: The application must have a screen for loading data dictionaries
  • RQ12: The application must have a screen for loading data
  • RQ14: The application must accept systems and data dictionaries as its data (content for the application)
  • RQ15: The application must define a data model for our data dictionary
  • RQ16: The data dictionary should have have the ability to be augmented (can grow in size)
During the development of the second iteration, two more data models were added - Versions and Tables to join our existing Systems model. There is a relationship between systems and versions, as well as a relationship between versions and tables.

The fact that we now had more than one data model meant that the data models for our application are nested more than 1 level deep. The ‘ruby on rails guide’ recommends that the controllers for these respective databases can’t be nested more than 1 level deep. This is because as the size of the nesting increases, the required commands for the respective controller quickly become complicated. The solution to overcome the issues of deep nesting is to use shallow nesting. This involves using the “:shallow” option when stating the relationship between the controllers in the routing file for the rails application. The actions are collectively scoped under the parent to avoid deep nesting. This becomes more like a hierarchy. In order to construct the routes, the minimal amount of information is required to uniquely identify the resource. “The shallow method of the DSL creates a scope inside of which every nesting is shallow.”

Our home page was mostly unchanged from the first iteration of our application.

We now removed the version number from the "add new system" functionality as this is a separate process, using the newly created "versions" table.

A dropdown menu that has a number of options such as show system, edit system and delete system.

We were able to show a list of all of the systems within the systems table which was done using a search of the table.

We added the ability to add a new table for a specified system. This would use our new table within our database to store this information, linking the systems table with systemID as a foreign key.

We could then display all versions for a particular system.

Client Feedback

Once we were satisfied with our second iteration, we had another meeting with our client in order to get his feedback and note any changes he would like. The results of the meeting were the following:

  1. Remove "created at" and "updated at" attributes in systems and versions lists as the client felt these pieces of information were redundant
  2. A simple '+' icon should be used as an option to add a new system
  3. In the list of systems, the name of the system should link to its version page rather than having a separate button as the client feels this is more intuitive
  4. Use icons for 'edit' and 'delete' buttons as words are not necessary
  5. Add a true/false marker which can indicate which versions are active and which ones are not
  6. Enable users to edit individual fields on a displayed data dictionary

Along with these requests, the client recommended that we no longer focus on parsing a CSV file and instead focus on manual entry by the user. We took all of these comments on board and started development of our third iteration

Go to iteration 3

References used for research in iteration 2

1) Chapter 6-8 Getting Started with Rails- Rails Guides: http://guides.rubyonrails.org/getting_started.html

2) Section 2.7- Nested Resources - Rails Routing from the Outside In- Rails Guides: http://edgeguides.rubyonrails.org/routing.html#nested-resources

3) Nithin Bekal-Avoid Deeply Nested Routes in Rails [14 May 2010]-[Blog]: http://nithinbekal.com/posts/rails-shallow-nesting/