Detailed Design Phase 2
H.O.P.E.
Version 1.0
November 27, 2011
SE 6v81 .002 – Think For You (TFY)
Caitlin Fowler
Eric Blackburn
Frank (Zhenzhou Sun)
Frederico Araujo
Owolabi Legunsen
Sam Shaw
Sean Wilson
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
http://www.utdallas.edu/~sas071100/hope
TFY
Software Detailed Design
Version 1.0
Revision History
Version
0.1
0.2
0.3
0.4
0.5
1.0
Changes
Used an existing template to structure the document. Added
detailed design analysis branched from the original architecture
document.
Added database modifications.
Updated with latest issues discussion
Update class diagram to reflect changes in configuration settings
Added AHP tables
Prepped for turn in.
Date Modified
11/25/2011
11/26/2011
11/27/2011
11/27/2011
11/28/2011
11/29/2011
Page 2 of 36
TFY
Software Detailed Design
Version 1.0
Table of Contents
Revision History
2
Table of Contents
3
1.
5
2.
Introduction
1.1
Purpose
5
1.2
Evolution of this document
5
1.3
References
5
1.4
Definitions, acronyms, and abbreviations
5
1.5
Detailed Design representation
5
1.6
Detailed Design goals and constraints
6
Detailed Design process
6
2.1
Methodology
6
2.2
State of the art and Scientific Research
6
2.3
Issues resolution
6
3.
Design patterns
6
4.
Detailed Design view points
8
4.1 Static perspective
4.1.1
Contextualizer class diagram
4.1.2
Package dependencies
8
8
9
4.2
Interaction perspective
9
4.3
Functional perspective and business rules
10
5.
Database design
11
6.
Traceability matrix
11
7.
References
12
Appendix A. Activity diagrams
13
A.1 AHP Process: sort icons
13
A.2 AHP Process: update weights
15
A.3 Time Criterion: get normalized statistics
17
Appendix B. Detailed design issues
19
B.1 Frequency Sorting Detailed Issues (FSDI)
19
B.2 Analytical Hierarchy Process Detailed Issues (AHPDI)
22
Page 3 of 36
TFY
Software Detailed Design
Version 1.0
B.3 Time Sorting Detailed Issues (TSDI)
25
B.4 Research into enabling/disabling AHP context criteria
28
B.5 Not enough weight to shift from losing criteria
32
B.6 Large Amounts of Criteria Means Larges Amounts of Priority Shifting
33
B.7 Abstract AHP Process
34
Appendix C Database changes
35
C.1 Changes made to existent HOPE tables
35
C.2 New tables to support AHP
35
Page 4 of 36
TFY
Software Detailed Design
Version 1.0
1. Introduction
1.1 Purpose
This document provides the detailed design of the context-aware sorting feature that will extend the
current version of the H.O.P.E. application. Multiple design viewpoints are presented to highlight
particular aspects of the system as seen from various perspectives.
1.2 Evolution of this document
See Revision History section for the document’s revision history.
1.3 References
Project Plan:
Project plan containing expected deliverables, deadlines, and project organization (please refer to latest
version).
WRS:
Requirements specification document (please refer for latest version).
Software Architecture:
Software architecture document (please refer for latest version).
HOPE Website:
http://www.utdallas.edu/~rym071000/index.html
(all the mentioned documents can be found in this website)
1.4 Definitions, acronyms, and abbreviations
H.O.P.E. – Helping Our People Easily
SAAM – Software Architecture Analysis Method
1.5 Detailed Design representation
This document presents the detailed design of the new context-aware sorting feature for the H.O.P.E.
application using multiple viewpoints. These views are based largely on the system’s underlying model
as expressed in Unified Modeling Language (UML).
Page 5 of 36
TFY
Software Detailed Design
Version 1.0
1.6 Detailed Design goals and constraints
This section lists the detailed design goals and constraints with respect to the new context-aware sorting
feature for the H.O.P.E. application.




The designed modules should be modular, cohesive, and coupling should be reduced to data
coupling (low coupling).
Design classes should be open, with modular and extensible methods in order to ease future
extensions and maintenance.
Known design patterns should be used and best OO design practices should be followed in order to
enhance understandability.
Provide at least state-of-the-art solutions for the algorithms and strategies applied for the contextaware decision making process.
2. Detailed Design process
2.1 Methodology
The methodology used during the detailed design activity followed, to a certain extent,
requirement and architectural specification analysis, systematic decision making including
several tradeoff analysis, issues and conflict resolution meetings, scientific research and an
OOAD approach. The purpose of this practice is to weight the benefits and drawbacks of design
decisions, while providing an agile way to determine among the best alternatives.
2.2 State of the art and Scientific Research
TFY has dedicated considerable amount of work on scientific research in order to identify, use
and possibly advance the state-of-the-art in terms of adaptive application and user modeling.
The core of the decision making process of our feature is based on a hybrid approach using AHP
(Analytical Hierarchical Process), genetic algorithms, and context information (i.e., frequency of
use, time). Part of this research is captured and documented in the appendices (A and B) of this
document.
2.3 Issues resolution
For the issues identified during the detailed design activity and their resolution, please refer to
the Appendix B.
3. Design patterns
This section summarizes the major design patterns that were applied in our design. The
diagrams illustrated here are informal and purely explanatory sketches and are not meant to be
our final design artifacts. For the design artifacts, please refer to Section 4.
Page 6 of 36
TFY
Software Detailed Design
Version 1.0
Adapter (wrapper). Convert the interface of one class into another interface clients expect.
Adapter allows classes to work together that otherwise cannot because of incompatible
interfaces. Figure 1 partially illustrates how the Contextualizer class adapts the interface of the
AHP class, so that the HOPE application activities (i.e., ThingsActivity, ActionsActivity) can make
use of the services provided by the context-aware feature.
Contextualizer
AHP
Client
+FindAll(in table)
+sort(in table, in iconsInfos) : List<IconInfo>
AHP.sort(...)
Figure 1 – Contextualizer class designed as an adapter for the AHP services
Template method. Define the skeleton of an algorithm in an operation, deferring some steps to
subclasses. Figure 2 illustrates how the onIconClick() method was designed as a template
method, letting the subclasses of the Contextualizer class redefine certain steps of the
algorithm for handling click events without changing the algorithm's structure.
Contextualizer
+onIconClick(in table : string, in icon : string)
#updateStatistics(in table : string, in selectedIcon : string)
ThingsContextualizer
#updateStatistics(in table : string, in selectedIcon : string)
...
updateStatistics(...)
...
ActionsContextualizer
#updateStatistics(in table : string, in selectedIcon : string)
Figure 2 – onIconClick() designed as a template method
Strategy. Defines a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from clients that use it. Figure
3 illustrates its application.
Page 7 of 36
TFY
Software Detailed Design
Version 1.0
AHP
+sort(in iconInfos : List<IconInfo>, in table : string) : List<IconInfo>
+update(in iconInfos : List<IconInfo>, in table : string, in selectedIcon : string)
1
#criterionArray
*
Criterion
+normalizeRatings(in iconInfos : List<IconInfo>) : List<IconInfo>
+getIndex(in iconInfos : List<IconInfo>, in selectedIcon : string) : int
Concrete strategies
TimeCriterion
FrequencyCriterion
+normalizeRatings(in iconInfos : List<IconInfo>) : List<IconInfo>
+getIndex(in iconInfos : List<IconInfo>, in selectedIcon : string) : int
+normalizeRatings(in iconInfos : List<IconInfo>) : List<IconInfo>
+getIndex(in iconInfos : List<IconInfo>, in selectedIcon : string) : int
Figure 3 – Strategy pattern applied to the different algorithms used by AHP
Observer. Define a one-to-many dependency between objects so that when one object
changes state, all its dependents will be notified and updated automatically. This pattern was
applied to intercept the user click events. As it was already in use on the legacy classes
ThingsActivity and ActionsActivity, it was only necessary to extend the event handler delegate
method to make the necessary calls to the Contextualizer class methods that handle user clicks.
Design guidelines. Other design guidelines followed to ensure high quality of OO design were
Information expert, High cohesion (single responsibility), Low coupling (data level dependency),
Controller, and Creator.
4. Detailed Design view points
4.1 Static perspective
This section details the static perspective of the package contextualizer in terms of classes and
dependencies with other packages.
4.1.1 Contextualizer class diagram
Page 8 of 36
TFY
Software Detailed Design
Version 1.0
com.utdallas.hope.contextualizer
1
com.utdallas.hope :: ActionsActivity
com.utdallas.hope :: ThingsActivity
1
1
1
1
1
ActionsContextualizer
1
1
ThingsContextualizer
1
com.utdallas.hope :: Things
+findAllThings() : List<IconInfo>
+findAllThingsBy(in action : string) : List<IconInfo>
+onVerbsThingsClick(in verb : string, in thing : string)
#updateStatistics(in table : string, in selectedIcon : string)
+findAllActions() : List<IconInfo>
+findAllActionsBy(in thing : string) : List<IconInfo>
+findAllCommentsBy(in thing : string) : List<IconInfo>
+onThingsVerbsClick(in thing : string, in verb : string)
+onThingCommentClick(in thing : string, in comment : string)
#updateStatistics(in table : string, in selectedIcon : string)
1
com.utdallas.hope :: Actions
1
1
AHP
Contextualizer
#config
1
#db : SQLiteDatabase
1
+onIconClick(in table : string, in icon : string)
#updateStatistics(in table : string, in selectedIcon : string)
#AHP
1
-db : SQLiteDatabase
+sort(in iconInfos : List<IconInfo>, in table : string) : List<IconInfo>
+sort(in iconInfos : List<IconInfo>, in table : string, in subtable : string) : List<IconInfo>
+update(in iconInfos : List<IconInfo>, in table : string, in selectedIcon : string)
+update(in iconInfos : List<IconInfo>, in table : string, in subtable : string, in selectedIcon : string)
1
1
#criterionArray
ContextualizerConfiguration
+isEnabled : bool
+ timeBlock1StartHour : short
*
IconInfo
+id : string
+name : string
+icon : string
+text : string
+statistics
Criterion
+normalizeRatings(in iconInfos : List<IconInfo>) : List<IconInfo>
+getIndex(in iconInfos : List<IconInfo>, in selectedIcon : string) : int
TimeCriterion
FrequencyCriterion
+normalizeRatings(in iconInfos : List<IconInfo>) : List<IconInfo>
+getIndex(in iconInfos : List<IconInfo>, in selectedIcon : string) : int
+normalizeRatings(in iconInfos : List<IconInfo>) : List<IconInfo>
+getIndex(in iconInfos : List<IconInfo>, in selectedIcon : string) : int
Figure 4 – Class diagram showing details of the context-aware sorting feature
4.1.2 Package dependencies
com.utdallas.hope
com.utdallas.hope.contextualizer
com.utdallas.hope.database
Figure 5 – Package dependencies for the context-aware HOPE application
4.2 Interaction perspective
This section details the interaction and collaboration perspective of the package contextulizer.
Two main scenarios are shown: sort process for icons and icon click event handling for usage
statistics gathering. Other scenarios can be easily based on these (see Figure 6 and Figure 7 ).
Page 9 of 36
TFY
Software Detailed Design
Version 1.0
Figure 6 – SD showing detailed interactions after user clicks on sort button
Figure 7 – SD showing how user clicks are handled by the contextualizer
4.3 Functional perspective and business rules
For the functional perspective and business rules of the context-aware sorting feature, please
refer to the Appendix A. The following activities are described in the appendix:



AHP Process: sort icons (appendix A1)
AHP Process: update weights (appendix A2)
Time criterion: get normalized statistics (appendix A3)
Page 10 of 36
TFY
Software Detailed Design
Version 1.0
5. Database design
The database modifications made to the existent H.O.P.E. database are documented in the
Appendix C.
6. Traceability matrix
Error! Reference source not found. shows the traceability between the specified requirements and the
etailed design specification (cross reference with issues documented in Appendix B).
Table 1 – Traceability matrix
D ID
Issues Domain
3.2.3.1
3.2.3.3
FR ID
AHPDI 2.2.1
AHPDI 2.2.6
Issues FR
3.3.1.5
FSDI 2.1.1
FSDI 2.1.2
AHPDI 2.2.2
AHPDI 2.2.3
AHPDI 2.2.4
TDSI 2.3.1
3.3.1.5
3.3.3.11
3.3.3.11
3.3.3.11
3.3.2.9
NFR ID
Issues NFR
3.4.8.1
3.4.7.1
DD ID
FDSI 2.1.1
AHPDI 2.2.5.1
AHPDI 2.2.5.1
Detailed Design Issue
AHPDI 2.2.5
TDSI 2.3.3
Issues Detailed Design
FSDI 2.1.3
FSDI 2.1.4
TDSI 2.3.2
Page 11 of 36
TFY
Software Detailed Design
Version 1.0
7. References
[1] Armentano, M., Amandi, A.: Modeling sequences of user actions for statistical goal
recognition, Springer Netherlands, User Modeling and User-Adapted Interaction. 1-31
[2] Zakaria, N., Dahlan, H., and Hussin, A.: Deriving priority in AHP using evolutionary computing
approach. WSEAS Trans. Info. Sci. and App. 7, 5 (May 2010), 714-724.
[3] Zakaria, N., Dahlan, H., and Hussin, A.: Deriving priority in AHP using evolutionary computing
approach. WSEAS Trans. Info. Sci. and App. 7, 5 (May 2010), 714-724.
[4] Wikipedia, Moving average, http://en.wikipedia.org/wiki/Moving_average. Accessed 14October-2011.
Page 12 of 36
TFY
Software Detailed Design
Version 1.0
Appendix A. Activity diagrams
A.1 AHP Process: sort icons
Figure 8 and Figure 9 show the business rules for the AHP process (Analytical Hierarchy
Process), process of getting a sorted list of icons based of criterion and priority weights.
Figure 8 – AHP process: sort icons, part 1
Page 13 of 36
TFY
Software Detailed Design
Version 1.0
Figure 9 – AHP process: sort icons, part 2
Page 14 of 36
TFY
Software Detailed Design
Version 1.0
A.2 AHP Process: update weights
Figure 10 and Figure 11 show the business rules for the AHP, process of updating the priority
weights associated with a set of criteria.
Figure 10 – AHP process: update weights, part 1
Page 15 of 36
TFY
Software Detailed Design
Version 1.0
Figure 11 – AHP process: update weights, part 2
Page 16 of 36
TFY
Software Detailed Design
Version 1.0
A.3 Time Criterion: get normalized statistics
Figure 12 and Figure 13 show the business rules for the Time Criterion process of getting the
normalized values of the options ready to be returned to the AHP process.
Figure 12 – Time criterion: get normalized statistics, part 1
Page 17 of 36
TFY
Software Detailed Design
Version 1.0
Figure 13 – Time criterion: get normalized statistics, part 2
Page 18 of 36
TFY
Software Detailed Design
Version 1.0
Appendix B. Detailed design issues
This appendix details (informal) discussions that permeated the requirement and architectural
specification translation into the detailed design activity for the context-aware sorting feature.
B.1 Frequency Sorting Detailed Issues (FSDI)
2.1.1.Will the frequency statistic continue to increase each time the option is selected? See
3.3.1.5
O1: No, there will be a ceiling value that an option can reach.
O2: Yes, there is no ceiling to the frequency statistic.
Solution: O1
Rationale: O2 is an issue because if the user selects option A from the set {A, B, C} 50 times
in a row, then the frequency value will be anchored down to the past habits of a user’s life
even though the user selects option B the next 25 times. The order would remain the
same. To closer reflect the idea that changing habits are important, there needs to be a
cap, O1, which allows for frequently selected options to be considered important while
allowing that importance to fade quicker than the speed that O2 would provide.
2.1.1.1.
What should the frequency ceiling value be?
O1: 10.
O2: 50.
O3: 100.
O4: More than 100.
O5: Consider the previous options and perform testing to determine the right
setting.
O6: Regard any option selected as the number time the amount that is incremented
by selecting an option.
Solution: O2, O5, O6
Rationale: Without precedence for the way the frequency statistic adjustment
algorithm works, the best option is to test the effects in order to get a feel of a
ceiling that is not too high or too low. Too low of a ceiling and there is a bias towards
the present and too high of a ceiling has a bias towards the past. O5 allows testing to
be done in order to gain more perspective on the best value for the feature. Still,
this testing will take time to complete and is likely to be part of future work. Due to
the time constraints of the class project, 50 is selected as the initial ceiling for the
following reasons. The increment amount is 1, see FSDI 2.1.2.1, and that means if a
user was to select an option 50 times in a row in order to reach the ceiling as fast as
possible. This provides room to breathe without requiring too much time for
another option to catch up. The assumption is that any list of options is not likely to
have more than 30, so 50 allows each option to have some breathing room amongst
each other, if the ceiling was 10 then the options are likely to be close to each other
in value. Also, 50 allows for a habit to have breathing room in which the option can
remain high on the list even when it is not selected for a couple of turns, as long as
the option was close to the ceiling before. Again, the behavior estimates here still
Page 19 of 36
TFY
Software Detailed Design
Version 1.0
need to be validated with testing and tweaking and due to class time restrictions this
will have to be future work.
2.1.2.How much weight does the frequency statistic gain when an option is selected?
(See FR 3.3.1.5)
O1: increment by a constant.
O2: Randomly increment the value by various amounts.
O3: increment by a percentage.
Solution: O1
Rationale: O2 is not ideal do to not needing a randomness factor to the frequency statistic.
There is a need for some sort of constant gain so that all selected options gain importance
in a predictable way. The predictable growth of importance allows for the HOPE user to
experience a reflection of their choices made in a way that can be predicted and guided if
so chosen. Furthermore, if increasing by a percentage, creates issues with allowing new
options to surpass older choice habits. The goal of the option is to adapt to the present
more than supporting older behavior. Therefore, increasing by an integer provides both
predictable growth of the frequency statistic and allows for new choice habits to catch up
to older habits.
2.1.2.1.
What constant is used for incrementing?
O1: Increment the value by 1.
O2: Increment the value by 2.
O3: Increment the value by 3.
O4: Increment the value by 4.
O6: Perform testing on and adjustable parameter to identify an incremental value that
builds a variance of frequency statistics amongst the list of options an option is a part of.
Solution: O1, O6
Rationale: Therefore, the debate is how much value is gained when an option is
selected. The criteria depend on a couple of other variables. Because there is a ceiling
to the frequency statistic, there isn’t a worry that the frequency statistic will grow out of
control. Still, history should still be considered important. Therefore, a happy median
between increasing by more than 1 and by not increasing by too much is needed. The
choice of what is best can be somewhat subjective and might need to be changed if
user’s report that the value is too high or low. So, the start shall be incrementing by 1.
The likelihood of needing to change this is low, more than anything this is the parent
decision that the decrement amount and the ceiling will be dependent on. So, those
values should be considered for an adjustment before the increment value needs to be.
2.1.3. If the frequency statistic has a ceiling, what keeps all the options from eventually reaching
the ceiling and all sharing the same frequency importance from there on? See FDSI 2.1.1
O1: Let the values reach the ceiling and do nothing.
O2: Reset the frequency statistic values for all options within the list of options for that
view.
O3: decrement by an amount for all options within the list of options for that view each
time an option is selected in order to prevent all options from reaching the ceiling.
Solution: O3
Page 20 of 36
TFY
Software Detailed Design
Version 1.0
Rationale: A ceiling is important to keep one option from being selected so often that a
recent habit of selecting other options is not reflected soon enough to be useful to the
user. The goal in the previous sentence is to have a reflection of habits, therefore O1
and O2 allow habit information to be loss by either eventually not having any habit
reflected (O1) and (O2), or allowing options that are never used to catch back up to the
frequency statistic of old habits (O2). Therefore, O3 lets old habits decrease in
importance while not letting any set of habits have the max frequency statistic value at
1 time if only one item actually gains an amount when selected. Also, though old habits
eventually can reach zero, this process can be done at a speed that is not as quick as O1
and O2.
2.1.3.1.
How much should be decremented from each option, those available amongst
the selected option?
O1: Decrement by a constant.
O2: Randomly decrement the value by various amounts.
O3: Decrement by a percentage.
O4: Zero is the smallest value for the frequency statistic that a value can reach.
Solution: O3
Rationale: O2 is not ideal do to not needing a randomness factor to the frequency
statistic. There is a need for some sort of constant gain so that all selected options
gain importance in a predictable way. The predictable growth of importance allows
for the HOPE user to experience a reflection of their choices made in a way that can
be predicted and guided if so chosen. The same goes for the need of predictable
behavior with regards to the decrease in importance of a statistic. Therefore, the
debate is how much value is decremented when an option is selected. This criterion
depends on a couple of other variables. Because there is a ceiling to the frequency
statistic, there isn’t a worry that the frequency statistic will grow out of control. Still,
history should still be considered important. Therefore, O3 is selected to make sure
that the value decreases but resist going to zero even if the option is not used in a
long time.
2.1.3.2.
How much should the percentage decrease be?
O1: 1%
O2: 5%
O3: 10%
O4: More than 10%
O5: Continue testing in order to set the appropriate amount.
Solution: O3, O5
Rationale: A concern arises where an option isn’t selected for a while and how far it
should fall. A good measure backdrop is to consider the largest number of options
presented to a HOPE user like the target user. With the highest settings, assume the
target user for the frequency setting has the high setting on due to that target user
having trouble interacting with small buttons, then only 6 options are shown at one
time. The goal is for these 6 to be highly representative of the user’s habits based on
frequency of choices. With O3, if the user doesn’t select an option that has just
reached the ceiling value, 50 at the time of this decision, the amount of clicks to
reach a value of around 25 is 7 clicks of other options in a row. To reach a value of 1
takes around 35 clicks of other options. Therefore, option 3 only allows for recent
Page 21 of 36
TFY
Software Detailed Design
Version 1.0
selections to reside towards the top of the amount of time for an option to become
almost reset, value of 1, is a long enough time to ensure that the user doesn’t want
that item in all likelihood for the next access of that list of options. For the sake of
listing the other testing results:
1% decrease to 25
13 clicks
decrease to 1 75 clicks
5% decrease to 25
7 clicks
decrease to 1 35 clicks
10% decrease to 25
3 clicks
decrease to 1 15 clicks
5% seems to be a happy medium with 10% changing too much too quickly and 1%
changing too slow and likely pooling values towards the ceiling value because if
the increment is 1 and 1% of 50 is .5, then the incrementing by is a net increase
still when an option is at 50 -.5 +1 = 50.
2.1.3.3.
Is there a need to have the frequency statistic primed because of the
decrementing design ?
O1: No, let the increment value be the first value given to any option when that
option is chosen.
O2: Yes, start the frequency statistic at the ceiling.
O3: Yes, start the frequency statistic at ceiling/2
Solution: O1
Rationale: O1 can solve the issue of the need to prime the frequency statistic. Rather
than deal with this by using O2 or O3 and priming the frequency statistic, testing will
be performed on the increment/decrement value relationship and how the value can
better resolve the priming concerns, that options would clutter around the bottom
of the frequency statistic range and be unable to scatter amongst each other to have
a distribution related to user’s habits.
2.1.4.How will frequency rankings be normalized for the AHP process? (see AHPDI 2.2.5.1)
O1: Divide each option’s frequency statistic by the ceiling value.
O2: Sum up the all the frequency statistics and divide by that number.
Solution: O1
Rationale: The true relationship between option’s frequency statistic is from 0 to the ceiling.
Therefore, with the normalization requiring a 1 to 0 scale, 1 being ranked the highest, (see
AHPDI 2.2.5.1) the ceiling allows for an option to reach the value of 1 and no option can be less
than zero. O2 doesn’t allow a value of 1 to be reached.
B.2 Analytical Hierarchy Process Detailed Issues (AHPDI)
2.2.1.What is a weight of a criterion? (See 3.2.3.1)
O1: A fraction of the total 100 percent influence that all the criteria have in predicting
the likelihood that a user will select an icon.
O2: Ranking of the order in which the criteria will be applied to sorting the icons.
Solution: O1
Rationale: The hierarchy process refers to weights (priorities) [reference] as being a
subset of the total 100 percent of possible influence. This will be kept to stay in-line
with the process.
Page 22 of 36
TFY
Software Detailed Design
Version 1.0
2.2.1.1.
Can the sum of the priority percentage be something other than 100%?
O1: Yes, can be more than 100%
O2: Yes, can be lower than 100%
O3: No, the sum of the priority percentages shall always be 100%
Solution: O3
Rationale: The hierarchy process refers to priorities as being a subset of the total 100
percent of possible influence. This will be kept to stay in-line with the process.
2.2.2.When does a criteria priority increase? (See 3.3.3.11)
O1: When a criteria correctly guesses the user’s selection by placing it at the top of its list.
O2: When a criteria is in the top half of the criteria compared, with the top half composed of
the criteria that put the option selected closest to the top of their respective list.
O3: When a criterion is the top criterion compared, with the top composed of the criterion
that put the option selected closest to the top of their respective lists.
Solution: O2
Rationale: The priority shifting should be based on a “fitness function” where the successful
criteria increase in influence and the unsuccessful criteria decrease in influence [1]. The
success of a criterion is whether or not the criteria has correctly guessed the user’s choice
before the choice is made. While O3 is similar to O2, the point of AHP is to utilize the
combination of multiple criteria, therefore there should be more than 1 criteria that should
be able to have success.
Reference: [1] Zakaria, N., Dahlan, H., and Hussin, A.: Deriving priority in AHP using
evolutionary computing approach. WSEAS Trans. Info. Sci. and App. 7, 5 (May 2010), 714724.
2.2.2.1.
Can a priority be over 100%?
O1: Yes
O2: No
Solution: O2
Rationale: The sum of the priorities can’t be over 100%, and individual criteria can’t
have more than 100% of influence. This sticks with the traditional process of the
analytical hierarchy process model.
2.2.3.When does a criteria priority decrease? (See 3.3.3.11)
O1: When a criteria incorrectly guesses the user’s selection by placing it not at the top of its
list.
O2: When a criterion is in the bottom half of the criteria compared, with the bottom half
composed of the criteria that put the option selected closest to the top of their respective
list.
O3: When a criterion is the bottom criterion compared, with the bottom composed of the
criterion that put the option selected farthest to the top of their respective lists.
Solution: O2
Rationale: The priority shifting should be based on a “fitness function” where the successful
criteria increase in influence and the unsuccessful criteria decrease in influence [2]. The
success of a criterion is whether or not the criteria has correctly guessed the user’s choice
Page 23 of 36
TFY
Software Detailed Design
Version 1.0
before the choice is made. While O3 is similar to O2, the point of AHP is to utilize the
combination of multiple criteria, therefore there should be more than 1 criteria that should
be able to have success.
Reference: [2] Zakaria, N., Dahlan, H., and Hussin, A.: Deriving priority in AHP using
evolutionary computing approach. WSEAS Trans. Info. Sci. and App. 7, 5 (May 2010), 714724.
2.2.3.1.
Can a priority be under 100%?
O1: Yes
O2: No
Solution: O2
Rationale: The sum of the priorities can’t be under100%, and individual criteria can’t
have less than 0% of influence. This sticks with the traditional process of the
analytical hierarchy process model.
2.2.3.2.
What if a criterion would become negative if it lost in the priority shifting
equation?
O1: A criteria can only decrease down to zero.
O2: A criteria can become negative.
Solution: O1
Rationale: The criteria priorities can’t be over 100% total and allowing negative’s
into the priority mix would allow over 100% priority ratings.
2.2.4.When does a criteria priority remain the same? (See 3.3.3.11)
O1: When a criterion correctly guesses the user’s selection by placing it at the top of its list.
O2: When a criterion is in the top half of the criteria compared, with the top half composed
of the criteria that put the option selected closest to the top of their respective list.
O3: When a criterion incorrectly guesses the user’s selection by placing it not at the top of
its list.
O4: When a criterion is in the bottom half of the criteria compared, with the top half
composed of the criteria that put the option selected closest to the top of their respective
list.
O5: When a criterion is in the middle, only when odd set of criteria, of the criteria
compared, with the top half composed of the criteria that put the option selected closest to
the top of their respective list.
Solution: O5
Rationale: There is a need to deal with an odd set of criteria, and by definition if the
criterion neither is in the top, winners, or the bottom, losers, list then the criterion is neutral
and should not win or lose.
2.2.5. Can criterion be able to have sub-criteria? See ofr 3.4.8.1
O1: Yes
O2: No
Solution: O1
Rationale: A criteria may not be fully realized unless it is further broken down into subcriteria. Sub-criteria are not foreign to the analytical hierarchy process. Though the AHP
Page 24 of 36
TFY
Software Detailed Design
Version 1.0
doesn’t have to worry about the sub-criteria, the parent of the main criteria should be
responsible for providing an overall decision in the parent criteria so that the main AHP doesn’t
worry how that decision was derived.
2.2.6.What is the returned result from a criterion, such as frequency, used by an option set in
the analytical hierarchy process? (See D 3.2.3.3)
O1: Sorted list of options ready to be displayed.
O2: Unsorted list of options with the weights calculated after going through the criteria process.
O3: Location of an option’s rank.
Solution: O2, O3
Rationale: To remain quick, the amount of sorting needs to be kept to a minimal. Therefore,
sorting needs to be done at the end of the analytical hierarchy process. Therefore, the criteria
feature only needs to return the unsorted list with a set of values that can be used to rank the
returned list of items. Still, to determine the location, rank, of the option chosen by the user in
order to complete a priority shifting function based on which criteria had the option as the
highest ranked, the AHP process needs the criteria to report back this information.
2.2.6.1.
Do the criteria need to adjust their values determined by the criteria feature in
order to meet a standard format?
O1: Yes
O2: No
Solution: O1
Rationale: Different criteria will have different ways of ranking their options. In order
for AHP to calculate a total score accumulated from each of the criteria ranking systems,
a common language is needed in order to accurately compare options when performing
a sort at the end of the AHP process. Therefore, a ranking from 1 to 0 is required. This
can be a form of normalization with 1 meaning the highest rank and 0 the lowest rank in
the criteria.
2.2.6.1.1.
Is AHP responsible for the normalization or the maker of the criteria?
O1: AHP
O2: Criteria
Solution: O2
Rationale: Different criteria will have different ways of ranking their options. To best
represent the options in a 1 to 0 scale the domain experts, a criterion’s developers,
should develop a normalization process to translate the criterion’s ranking system.
B.3 Time Sorting Detailed Issues (TSDI)
2.3.1.Will block time related to an option contain an updated timestamp from the last time the
particular option was selected during that block time? (See FR 3.3.2.9)
O1: Yes, each time the user selects an option, the timestamp is updated.
Page 25 of 36
TFY
Software Detailed Design
Version 1.0
O2: No, each time the user selects an option, a timestamp composed of the average of
previous timestamps is updated by processing it using a moving weight average.
Solution: O2
Rationale: History is important in order to perceive patterns. In order to do that some
historical information needs to be gathered. Moving weight averages have the ability to
move in value with bias towards present or past information.
2.3.1.1.
Is the moving weight average biased towards the present or the past? (See FR
3.3.2.9)
O1: Present
O2: Past
Solution: O2
Rationale: The idea is to predict the user’s habits. Sometimes behavior moves outside
of the normal habit, if the timestamp value was to adjust to fast to an out of the
ordinary time choice then past data would become irrelevant. Therefore, while
adjusting to the present choice time, the moving weight average should provide a
resistance to non-habit choices. O2 provides this protection. For example, the likely
used algorithm from a exponential moving average function would be
with Yt as the current time and St
as the currently stored timestamp value. In this situation “a” would be equal to 10% or
so [3]. This way, if it is currently 5:50 am and the user selects option A that is typically
selected at 12:01 am then the new timestamp would be updated to 12:36 am. If the
current time was 12:30am with the current timestamp as 12:01am then the updated
time would be 12:04 am. Testing would likely be needed to extensively pin down the
best “a” value for the equation, but for now due to time constraints “a” shows good
signs of being flexible to updated habits without discarding the past data because of
abnormal situations.
Reference: [3] Moving average, http://en.wikipedia.org/wiki/Moving_average.
2.3.2. How will time’s rankings be normalized for the AHP process? (see AHPDI 2.2.5.1)
O1: Divide each option’s calculated difference from the current time by the maximum amount
of distance possible in minutes.
O2: Sum up the all the time differences and divide by that sum.
Solution: O1
Rationale: The true relationship between option’s time difference from the current time is from
0 to the maximum amount of time difference that an option can be. Therefore, with the
normalization requiring a 1 to 0 scale, 1 being ranked the highest, (see AHPDI 2.2.5.1) the ceiling
allows for an option to reach the value of 1 and no option can be less than zero. O2 doesn’t
allow a value of 1 to be reached. There is one issue, time has an issue where lower time
differences should be ranked higher instead of lower. To deal with this role reversal issue for
high and low numbers, an inverse function is needed to make the low difference values into the
higher values on the 1 to 0 scale.
Page 26 of 36
TFY
Software Detailed Design
Version 1.0
2.3.2.1.
How will the rankings of time be inversed?
O1: Subtract each time difference from the largest possible difference to obtain an inverse
value. This would be done before normalizing into a 1 to 0 range.
O2: Calculate the normalized values and then subtract the values from 1 in order to get the
inverse values.
Solution: O1 or O2
Rationale: There are two viable options and the choice will most likely depend on the
architecture of the design and therefore both options are still left as a choice to the detailed
design team and implementation team.
2.3.2.2.
Should the rankings be exacerbated to put more relevance on options that are
closer to the current time?
O1: Yes.
O2: No.
Solution: O1
Rationale: The natural calculation of the difference between an option’s timestamp and
the current time does produce a scale in order to rank options, but options at are 30
minutes or closer to the current time are much more likely to be of interest to the user than
options more than 30 minutes. Therefore, producing an exacerbated spread of the values
that puts more value for options that are closer to the current time is important in order to
better differentiate values in the normalization process.
2.3.2.2.1.
An easy method to use for emphasizing is to put the normalized value to
the power of some number in order to take use of the property of putting
values less than 1 and more than zero to a power more than 1. What should
that power be?
O1: 2
O2: 3
O3: 4
O4: 5
Solution: O3
Rationale: An ideal distribution would set options that are 30 minutes or more away
from the current time to be 80 percent as important or less than options that are a zero
distance from the current time. Furthermore, this function shouldn’t make options 30
minutes away less than 60 percent as important.
Options 30
minutes
away 60
minutes
away 120
minutes
away
normalized
and normalized
and normalized
and
exacerbated value.
exacerbated value.
exacerbated value.
O1: 2
.89
.79
.6
O2: 3
.84
.7
.47
O3: 4
.8
.62
.37
O4: 5
.75
.55
.28
Page 27 of 36
TFY
Software Detailed Design
Version 1.0
The test was done with a maximum value of difference between the current time and an
option’s time set to 540 minutes, 9 hrs. The test show that O3 is the first number that
meets the desired behavior. Furthermore, test on 60 and 120 minutes show that the
function has a quick shifting of the value that puts much more emphasis on values closer
to the current time than those that are even 1 hour away. O3 has been chosen.
2.3.3.How will time adapt to daylight savings time? (see NFR 3.4.7.1)
O1: Reset all time data and adjust the PDST 1 hour according to the daylight savings time
change.
O2: Adjust all time data and the PDST 1 hour according to the daylight savings time change.
Solution: O2
Rationale: Deleting information is not ideal in order to maintain a smooth experience with the
sorting feature. If time abruptly changed without the user’s choice, this would cause the
sorting feature to change abruptly. Also, O1 also requires going throughout the database to
make adjustments. Therefore, O2 is not too much more complex.
B.4 Research into enabling/disabling AHP context criteria
Issue regarding the ability to turn a criterion on and off so that AHP doesn’t have to consider a
criterion upon user choice. The idea that could work in a simple manner is to redistribute an
option’s priority weight amongst the remaining criteria by summing up the total criteria weight
of the On criteria and then finding out what percentage of that total each criteria has. Use that
percentage to allocate the priority weight of the criteria that has been turned Off in order to
maintain the relative weights amongst the criteria that are still on. In order to re-introduce the
criteria back into the On criteria pool the criteria would start off with a priority weight of zero,
or some other standard value that would not mess up the weights of the other criteria that
were already On.
The following email thread discuss an attempt to keep the AHP process applied to all criteria,
On and Off, in order to preserve the information gathered by the AHP process. Too many
exceptions occurred during any attempt to produce an algorithm that could provide the desired
behavior. Furthermore, a discussion reviewed whether the ability to turn Off and On a criterion
was necessary. The team decided that the AHP’s goal is to take away the need for the user to
manipulate such a setting, which would likely to be difficult to fully understand a settings
impact on the application’s sorting results, and the user would likely not be using such a setting
often if at all. Therefore, the simpler algorithm is always available if the setting is ever desired,
but the following emails provide some information that might be useful towards future work
for an algorithm that is able to preserve AHP information when a criterion is turned off.
Frederico Araujo <[email protected]>
Eric Blackburn <[email protected]>
On Thu, Oct 27, 2011 at 12:03 PM, <[email protected]> wrote:
Page 28 of 36
TFY
Software Detailed Design
Version 1.0
No, the problem is: what it A continues to always beat B and C. B and C will never change from being
both 50% percent in ur method even if b is always beating C for example.
Sent from my iPhone
On Oct 27, 2011, at 11:41 AM, Frederico Araujo <[email protected]> wrote:
Perfect! So, this should also work for the case where A is turned off, correct? We would have [A. B, C] =
[99, 1, 0] which normalized following the approach I sent would be [NB, NC] = [49, 51]. Problem solved?
On Thu, Oct 27, 2011 at 11:35 AM, <[email protected]> wrote:
The activity diagram talks about the need to sloth off any losers that have a rating of zero. Kind of like a
recursive cal. So, after slothing off C, removing it from the equation of priority weight shifting, you are
left with B and A. Now run the shift weight alg with just B and A. So B =1% and A =99%. C remains at
0%.
Sent from my iPhone
On Oct 27, 2011, at 11:04 AM, Frederico Araujo <[email protected]> wrote:
Eric, a question: without any criteria turned off (OFF is empty), how the AHP would update the weights
in the following case:
Initially, [A, B, C] = [100, 0, 0]. Assume that in the next iteration the "winners" are B, A, C in this order
(meaning that B wins, followed by A and C). How should the AHP algorithm update the weights ([A, B, C]
= [?, ?, ?]) ?
On Wed, Oct 26, 2011 at 10:50 PM, Frederico Araujo <[email protected]> wrote:
Sure, we can do that and keep thinking about an alternative. Thanks!
On Wed, Oct 26, 2011 at 10:16 PM,<[email protected]> wrote:
Any added criteria, those turned back On, could just start off at zero. While I would like a better alg, we
will always have the simple version to fall back on if we can't crack this nut. So we can keep trying and
rely
on
the
safety
net
if
needed.
Sent from my iPhone
On Oct 26, 2011, at 10:01 PM, Frederico Araujo <[email protected]> wrote:
Just an update: now I realize that this is almost what you had proposed initially... =) the only difference
is that we apply the redistribution in a different moment and under certain conditions... initially you had
proposed to make a clean start.
On Wed, Oct 26, 2011 at 9:48 PM, Frederico Araujo <[email protected]> wrote:
An idea. Each time we reach the situation where the summation of weights in ON is 0, we can
"redistribute" the weights among the criteria (ON and OFF) evenly... I will keep think while I make the
dinner =)
Page 29 of 36
TFY
Software Detailed Design
Version 1.0
On Wed, Oct 26, 2011 at 9:32 PM,<[email protected]> wrote:
Yes, the Abrupt changes issue was solved from what I had time to test on your alg. I started putting
more time towards the issue of Off criteria influencing the ability for On criteria to gain priority when Off
criteria are still winning the battle behind the scenes.
Tricky problem.
Sent from my iPhone
On Oct 26, 2011, at 9:27 PM, Frederico Araujo <[email protected]> wrote:
Hey Eric,
I see... there is the problem of the update for weights too. My prior email solved the normalization issue
to avoid abrupt changes, correct? I will try to think about something. Just got back from church. I am
gonna eat something first and if I can think about something I will let you know.
Thanks
Fred
On Wed, Oct 26, 2011 at 9:15 PM, Eric Blackburn <[email protected]> wrote:
Sorry for the last email, I meant to say:
Still, if we continue to keep all criteria involved in the process, when A is turned off, how can B and C
possibly win when A is still winning and maintaining 100%? Seems like it would stay 100% A 0% B 0%
C if B and C can't beat A while B is maybe always beating C. I have tried to come up with some odd sort
of solution for this, but have yet to be able to crack this behavior.
On Wed, Oct 26, 2011 at 6:56 PM, Frederico Araujo <[email protected]> wrote:
read this version please...
also, the idea remains the same as we discussed yesterday: we use this to normalize the weights that
are used in the ranking or multi-objective function. For the real persisted weights, we just keep the
normal AHP processes to the entire set of criteria, even when some are turned off.
I believe that the algorithm should work if we follow a slightly different approach. First, take a look on
the tables behind. Case 1 illustrates the case where criteria A, B, and C are active (or turned ON in the
configuration settings). Case 2 illustrates the case where criteria B and C are active and A is inactive (the
user turned OFF the criterion on the configuration settings).
AHP
Snapshot
1
2
3
4
5
6
7
8
9
Case 1: ON={A, B, C} OFF={}
WA
WB
WC
100
0
0
99
0
1
98
0
2
97
0
3
96
0
4
95
1
4
94
2
4
93
3
4
91
4
5
WB
0
0
0
0
0
1
2
3
4
Case 2: ON={ B, C} OFF={A}
WC
NWB
0
50
1
49.5
2
49
3
48.5
4
48
4
48.5
4
49
4
49.5
5
49.5
NWC
50
50.5
51
51.5
52
51.5
51
50.5
50.5
Page 30 of 36
TFY
Software Detailed Design
Version 1.0
As pointed by Eric, we are going to run into problems if we do the simple normalization over the
proportions among the weights of the criteria belonging to the set ON. For instance, in AHP snapshot 2
we would have WB being normalized to 0 and WC being normalized to 100%. This is certainly not what
we wanted (too big of a change in just one step of the AHP process).
Now, what if we take another route? Let us call NWB and NWC the normalized weights of the criteria B
and C respectively. Let us follow what Eric previously suggested, which was distributed the sum of the
weights of the criteria belonging to the set OFF among the weights of the criteria belonging to the set
ON. The resulting NWB and NWC are shown in the table. It seems more reasonable. Now we notice that
NWC increased in importance compared to NWB, but not abruptly as compared to the prior example.
Notice that this logic behaves well to any combination of weights and that the weights belonging to the
set ON remains normalized. Also, it’s a simple normalization process:
Let ON and OFF be sets as mentioned above (note that 𝑂𝑁 ∩ 𝑂𝐹𝐹 = ∅)
For a given snapshot, let 𝑟 =
∑ 𝑤𝑒𝑖𝑔ℎ𝑡(𝑂𝐹𝐹)
#(𝑂𝑁)
which means that r is the result of the summation of
the weights of the criteria belonging to OFF divided by the number of criteria in the set ON.
Now, we just compute the normalized weights as: 𝑁𝑊𝑥 = 𝑊𝑥 + 𝑟 for x belonging to ON
Regards,
Fred
On Wed, Oct 26, 2011 at 6:42 PM, Frederico Araujo <[email protected]> wrote:
Sorry for the late response Eric. Today was a very busy day. Please see the attached document and let
me know if it helps solving the issue.
Regards,
Fred
On Wed, Oct 26, 2011 at 9:36 AM, Eric Blackburn <[email protected]> wrote:
I included only Fred and Owolabi in order to get some feedback. I have a question concerning Fred's alg
in which we have a scenario 100% A 0% B 0% C are the three active context. Well, if the user turns
off A, we said that B and C have equal weight, but we don't change the values at the moment. So, now
B has a relative 50% weight and C has a 50% weight with A off.
Here are the concerns. If B was to win the prediction race and the weight distribution becomes 99%
A 1% B 0% C, with A turned off still, then B just jumped up to 100% priority with respect to C. 1/1 = 1
for B and 0/1 = 0 for C. This is a huge jump, we had only wanted an adjustment by 1% or so. This type of
large adjustments is too much to effectively adjust the weights in a smooth manner.
Also, what if B and C can never beat A, even with A turned off Fred's alg was supposed to retain info
about the AHP weights with disregard to the the fact that a criteria is turned off. If A never loses even
with itself turned off, then B and C are always equally weighted. This is a contradiction to the desire to
have only B and C considered in the priority weight shifting race, because the user said to turn off
criteria A but with A influencing the behavior of the algorithm then B and C are being taken over by A's
dominance.
These two concerns are something I will try to solve somewhat, but I have yet to be able to. I am
Page 31 of 36
TFY
Software Detailed Design
Version 1.0
starting to lean again towards a situation in which if A is turned off then we compute some sort of
distribution of A's weight to the remaining active criteria. If A is turned back On at some point, A would
start out with a zero priority weight. While this is a crude method and loses some information, it is able
to meet the need to allow only B and C to be considered in the priority race that the A wouldn't still
always win in the case mentioned above. Furthermore, this method doesn't suffer from the issue of
large priority shifts that as the case mention above where "99% A 1% B 0% C, with A turned off still,
then B just jumped up to 100% priority with respect to C" .
The user is unlikely to be turning off and on the priority weights very often, and I mean I think it will be
done very rarely. Therefore, I think my simpler method is the way to go unless we can solve the
concern's with Fred's alg.
So, let me know if there are solutions to my concerns or if I am misunderstanding something with the
math.
B.5 Not enough weight to shift from losing criteria
If the following setup
Criteria sorted by
success of predicting
this user’s current
selection.
A
B
C
D
E
F
Priority
95
1
1
1
2
1
Then question is how to distribute the weights.
Instead of doing the original method A+3 B+2 C+1 D-1 E-2 F-3 we can’t because the weights are
too low on the losing side so that E and F would become negative if this was done. Instead,
gather the resources to be had, at most 1 from D, at most 2 from E and at most 3 from F and
put them into a pull.
Now, this method gives 4 points that can be redistributed amongst the winners.
One way :
A+1 B+1 C+1
A+1
If the following setup
Criteria sorted by Priority
success of predicting
this user’s current
selection.
Page 32 of 36
TFY
Software Detailed Design
A
B
C
D
E
F
95
1
1
1
1
1
Criteria sorted by
success of predicting
this user’s current
selection.
A
B
C
D
E
F
Priority
Version 1.0
A+1 B+1 C+1
95
1
1
1
2
2
A+1 B+1 C+1
A+1 B+1
If there are more resources then then the normal behavior would be accomplished
A+1 B+1 C+1
A+1 B+1
A+1
B.6 Large Amounts of Criteria Means Larges Amounts of Priority Shifting
Another issue is dealing with how to handle having several criteria and these causing potentially
large shifts as the number of criteria increase with the previous function.
One way to deal with the amount of shifting is to introduce new values into the equation each
time an option is added, so 1 C = 100pts, 2 C equal 200 pts and so on.
That way the relative distribution is a slow process. The only point is that there is a 100% of
resources in the system and that never goes down or up.
So with 200pts in the system, that is a .5 percent shift with only 2 options.
If four options 400 pts
A
200 +2
B
50 +1
C
100 -1
D
50 -2
Page 33 of 36
TFY
Software Detailed Design
Version 1.0
So, that would be a .75 percent swing in the system.
If 40 criteria, that is 4000 pts in the system,
Which would be
+20, +19….+1
-1, -2…..-20
So +20, +19….+1 = 210 pts shift which is a 5 percent shift which seems ok. What is the
amount of pts added to the system for each criteria added can be updated if this was not
enough at some point. Currently, I think 100 pts is fine for each critieria added. So, with our 2
criteria the system will have 200 pts in the ahp equation with 200 representing what 100% is.
B.7 Abstract AHP Process
Figure 14 - Abstract representation of AHP Process according to Detailed Design Issue Document choices.
Page 34 of 36
TFY
Software Detailed Design
Version 1.0
Appendix C Database changes
C.1 Changes made to existent HOPE tables
For each table in the database previously containing a frequency column, new columns have been
added to account for the additional context utilized by this feature. In the following table, they are
highlighted in grey:
Column name
_id
Name
Icon
Text
Frequency
Plural
Parent
timeblock1datestamp
timeblock1statistic
timeblock2datestamp
timeblock2statistic
timeblock3datestamp
timeblock3statistic
timeblock4datestamp
timeblock4statistic
Data type
Integer
Text
Text
Text
Integer
Text
Text
Datetime
Datetime
Datetime
Datetime
Datetime
Datetime
Datetime
Datetime
C.2 New tables to support AHP
For each table in the database containing a criterion statistics such as frequency, a row is added to the
following table with the table name being associated with the main_table attribute in the following:
Database Table
Column name
_id
main_table
Frequency
Time_Of_Day
Frequency
AHP_bidirectional_weights
Data type
Integer Primary Key AutoIncrement Not Null
Text Not Null
Int default 100 Not Null
Int default 100 Not Null
Integer
"CREATE TABLE AHP_bidirectional_weights (_id INTEGER PRIMARY KEY
AUTOINCREMENT NOT NULL, main_table TEXT Not Null , subtable TEXT NOT NULL ,
Frequency INTEGER NOT NULL DEFAULT (100), Time_Of_Day INTEGER NOT NULL
DEFAULT (100))"
Page 35 of 36
TFY
Software Detailed Design
Version 1.0
For each bidirectional table, such as verbs_things, and for each category in
the table, verbs in this case, there is a row added where the table name is
set as the main_table and the category is set as the subtable.
Database Table
Column name
_id
main_table
subtable
Frequency
Time_Of_Day
Frequency
AHP_Priority_Weights
Data type
Integer Primary Key AutoIncrement Not Null
Text Not Null
Text Not Null
Int default 100 Not Null
Int default 100 Not Null
Integer
"CREATE TABLE AHP_Priority_Weights (_id INTEGER PRIMARY KEY AUTOINCREMENT NOT
NULL, main_table TEXT NOT NULL , Frequency INTEGER NOT NULL DEFAULT (100),
Time_Of_Day INTEGER NOT NULL DEFAULT (100))"
Page 36 of 36