Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
admin
correlations
css
data_management
engine
html_templates
img
js
menu
project_management
README
bibliography.php
goal_association.php
goal_browse.php
goal_correlations.php
goal_selection.php
index.php
project_model.php
project_model_management.php
project_model_report.php

README

README

Requirements: PHP, MySQL server and database
Contact: andrew.hilts@utoronto.ca (let me know if you have some issues you think I can help with)
**************************************

This software is based on the creation of 'project models'. Project models are essentially a series of nodes and their interrelationships. The models are built when the user selects interesting goals and includes them in his/her project. The project models are generated from these included goals and the system automatically retrieves all contributings elements, which are also included in the project model. The user can then browse and reconfigure the project model using the tree list tool, and generate reports based on them.

See www.designknowledge.org/about.html (essentially chapter 5 of my thesis) for a more detailed high-level description as well as a process and data model.

____________________________________________________\

***********INSTALLATION GUIDE***********************
_________________________________________________________

Unarchive go_dkl.tar.gz into your localhost directory. 

Create new MYSQL database, named whatever you want.

In command line, go to your directory with dkl.sql in it
Run mysql -u -p YOUR_DB_NAME < dkl.sql

WARNING: the database dump contained herein ("dkl.sql") is only the table structure. Contact me at andrew.hilts@utoronto.ca if you would like sample data.

Edit db-permissions.php to reflect your local setup, change 'thesis' to your own db name.

_____________________________________________________

***FILE DESCRIPTIONS*******************
_________________________________________________

db-permissions.phpvery important

***FILES RELATING TO TREE LIST******************************

project_model.php 'Tree-list' tool display page

--retrieve and parse project model into unordered list
--render tree list

***important dependencies for project_model.php***************
treeview.js jQuery plugin for rendering tree list
eval.js Evaluation label propagation
live_queries.phpQueries that retrieve project model, and all other queries used in project
form_processing.php Handle form data, and other processing tasks 
 see line 293 for Q7 file creation; 
 see line 237 for project model configuration
q7_export/q7.phpconverts retrieved SQL rows into Q7 file
jqery.jsjQuery javascript library; powers treeview and eval

****Other important files**********
project_model_management.php index for all project models for that project. Create new models based on project goal inclusions. View reports.
project_model_report.php Calculate reports regarding the commonly found publications or related design features.

_________________________________________________

*****High-Level Description***********
_________________________________________________
MySQL records to tree-list representation

The below outlines the basic means by which retrieved rows from a database containing the following fields are converted into the tree-list representation.

A query retrieves a project model, consisting of rows of the following fields: 
"AggregateGoal, IncludedGoal, Relationship1, IncludedGoal2, Relationship2, DesignFeature".

The records are sorted by each field, starting with the leftmost -- "AggregateGoal", until the rightmost -- "DesignFeature".

In this manner, an algorithm can easily loop through the returned records and construct a hierarchical list. First, create root list items for each distinct (Distinct among its branch siblings. EG: one Library Goal may appear as the child of multiple Aggregate Goals) "AggregateGoal", then create distinct child nodes for each "LibraryGoal" and so on.

In order to be converted into a tree-list as implemented in GO-DKL browser version 3, the output of the above algorithm needs to be an unordered HTML list. EG:

<ul>
  <li>
    Aggregate Goal 1
      <ul>
        <li>Library Goal 1
          <ul>
            <li>Library Goal 3
              <ul>
                <li>Design Feature 1</li>
                <li>Design Feature 2</li>
              </ul>
            </li>
            <li>Library Goal 4
              <ul>
                <li>Design Feature 1</li>
                <li>Design Feature 2</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>Library Goal 2
          <ul>
            <li>Library Goal 6
              <ul>
                <li>Design Feature 7</li>
                <li>Design Feature 4</li>
              </ul>
            </li>
            <li>Library Goal 4
              <ul>
                <li>Design Feature 8</li>
                <li>Design Feature 2</li>
              </ul>
            </li>
          </ul>
        </li>
      </ul>
  </li>
  <li>
    Aggregate Goal 2
      <ul>
        <li>Library Goal 1
          <ul>
            <li>Library Goal 6
              <ul>
                <li>Design Feature 5</li>
                <li>Design Feature 2</li>
              </ul>
            </li>
            <li>Library Goal 3
              <ul>
                <li>Design Feature 3</li>
                <li>Design Feature 1</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>Library Goal 3
          <ul>
            <li>Library Goal 5
              <ul>
                <li>Design Feature 2</li>
                <li>Design Feature 5</li>
              </ul>
            </li>
            <li>Library Goal 9
              <ul>
                <li>Design Feature 8</li>
                <li>Design Feature 6</li>
              </ul>
            </li>
          </ul>
        </li>
      </ul>
  </li>



This list is then assigned a method from the Treeview jQuery Plugin, available at http://jquery.bassistance.de/treeview/. EG:

$("\#unordered\_list").treeview();


In GO-DKL browser version 3, while the unordered list structure is as above, additional data is added to the list to provide the feature set described. For example, HTML form elements are present within child list items. These forms carry a unique ID (Across the entire list) that is a string consisting of the parent element id and the child element id (eg: a Library Goal's id). The default value of these form elements is the contribution type between parent and child element. For example, if "Goal1" contributes a 'help' value to "Goal2", the form element within Goal1}'s list item would bear the id "Goal1\_Goal2", and have the default value of "helps". These form elements feature a dropdown list of many contribution values featured in the \textit{i*} syntax. Therefore, by selecting a different value for the form element, the user may change the contribution value between "Goal1" and "Goal2".

***Tree-list evaluation label propagation***


The below evaluation label propagation algorithm was designed to parse the same type of hierarchical unordered HTML list as in the above section. It too, is dependent on the jQuery JavaScript library.

At a conceptual level, the process consists of looping through every leaf node, the Lowest level list item, a design feature in the list. At each leaf node, the treePropagate function is called. This function compiles the contribution values of all sibling leaf nodes and passes that compiled value to the parent element. treePropagate is then recursively called, applying to the parent elements' parent node, and so on. After a branch is complete, the initial loop continues to the next branch leaf node sibling set, where treePropagate is called again.

Contribution values are assigned an integer based on the strength of the contribution. For example, helps} is worth 1 point, while breaks} is -2. The sum of all sibling contribution values is divided by the number of contribution values, resulting in a satisfaction ratio. However, recursive calls of treePropagate} take into account the label assigned to child nodes (propagated from descendants); the value of the child's form element is multiplied by (-)1, depending on the child's label. For example, a denied child that would normally pass a negative value to its parent would pass a positive value. If this ratio is above 30, the parent element is assigned a green label. If it is below -30, the parent is assigned a red label. In between those two, a yellow label is assigned. The contribution value of each leaf node is the currently selected value of the form element present in that node. 

The above evaluation process is called once when the list is loaded, and is repeated when any element in the list changes in value. In this manner, the evaluation labels of list elements are responsive to user interaction.

The key point of interaction is the alteration of contribution values between a child and parent. A user may change the HTML form element's value by selecting a new one from the form element's list. This change is applied to every element in the list with the same unique id string. To accomplish this, the system searches through the DOM (document object model) to find the matching elements. In this manner, a relationship between design feature and library goal (for example) present in multiple branches of the list will all maintain the same value. 

Once a change has been applied to all required elements, the evaluation process is once again called, and the evaluation labels updated throughout the list.

The same process is undertaken when a user selects or deselects a list item; matching items throughout the list will correspondingly be selected or deselected.

****MySQL records to Q7 file***

The process by which a model slice is converted into a Q7 file capable of being opened in Open OME begins similar to the tree-list construction process. The same general query retrieves the same kind of records. To reiterate, those would be rows of the following fields: 
"AggregateGoal, IncludedGoal, Relationship1, IncludedGoal2, Relationship2, DesignFeature". These records are sorted by each field, starting with the leftmost -- "AggregateGoal", until the rightmost -- "DesignFeature".

A program loops through the records, creating arrays for retrieved Aggregate Goals, Library Goals, Design Features, and relationships.

Following this, the unique Aggregate Goals array is looped through, adding entries to an array called "AggregateGoals\_LibraryGoals". An item in that array is created for each relationship between Aggregate Goals and Library Goals. For example, the string stored in an array entry for more users contribute to more topics" helps "participation" would be structured as follows: 

``\nMay more users contribute to more topics => + participation''

In this example, the text "may" is used to tell Open OME's Q7 parser that the next part of the string preceding the operator is a soft goal. The operator "=> +" signifies that the preceding section of the string helps the latter section.

This process is performed for each unique array set (besides relationships). The string for design features contributing to goals begins with "Do" (instead of "May") to delineate it as a design feature.

Following the loops through the arrays which build the unique relationship arrays, each relationship array is exploded into a string, separated by newlines. Another string is created that begins with the text "Placeholder \ & ;" and ends with "\n". In between those elements is the concatenated string of all relationship arrays. Essentially, this process is a workaround that generated a placeholder actor that contains all relationships in the model. It was developed to circumvent Open OME's parsing of the Q7 file soft goals as both soft goals and distinct actors. are then concatenated into one large string that is outputted as a Q7 file.