D
D
Author: Jonathan Bridges
Updated: 12/11/2009
The purpose of this project is to aid the client in modeling cognitive dissonance reduction through means of a neural network.
When a person experiences a conflict between two beliefs, or a belief and a behavior, they experience a very uncomfortable feeling, which is cognitive dissonance. For example, if you believe that gorging yourself on fatty foods is bad and unhealthy, but you do just that, then dissonance should occur. You will then be motivated to reduce this unpleasant feeling by not eating the fatty foods, or changing your belief in how bad it is.
Fundamentally a neural network refers to a circuit of biological neurons. However, in this case the circuit and the neurons are all artificial. In the network the neurons are represented by nodes, each with a connection to other nodes, possibly every other node. The node will activate, or "fire", when the sum of its inputs passes a specific threshold, where upon it allows output.
In this project, each node will be paired with another node and placed into its cognition, at north and south poles. These cognitions will represent the various beliefs or behaviors and will themselves contain attributes, such as a resistance to change. The attributes of the cognition affect their nodes, e.g. the cognition’s resistance to change will affect its nodes’ resistance to changing its activation.
The delivered application will allow the user to setup the network's cognitions, including node properties within the cognition. The application will then run through a simulation of cognitive dissonance reduction and give feedback to the user on the level of dissonance at any given time through the simulation.
1

Manager Dr. Hiroshi Fujinoki
Client/User Dr. George Watson
Team Cory Lehan
Tim Meyer
Jarrod Capps
Jonathan Bridge
EMBERS
T IM M EYER
J ARROD C APPS
J ONATHAN B RIDGES
EAM
EADER
C ORY L EHAN
LIENT
SER
D R .
W ATSON
Cory Lehan
•Team Leader
•Customer Interface
•Support
Tim Meyer
•Test Manager
•Process Manager
Jarrod Capps
•Implementation Manager
•Plan Manager
Jonathan Bridges
•Design Manager
•Quality Manager
M ANAGER
D R .
F UJINOKI
2

Author: Jonathan Bridges
Co-Authors: Cory Lehan & Tim Meyer
Updated: 10/27/2009
Dr. George Watson, Department of Marketing and Management, School of Business, SIUE
Neurotic, Computer Science Department, School of Engineering, SIUE
The purpose of this project is to aid Dr. George Watson in modeling cognitive dissonance reduction through means of a neural network. The delivered application will allow the user to setup the cognitions, including node properties within the cognition, which make up the neural network. The application will then run through a simulation of cognitive dissonance reduction and give feedback to the user on what is taking place within the neural network.

Ability to run a simulation of a neural network to model cognitive dissonance reduction. o Create cognitions (each containing two neural network nodes). o Set the properties of the cognitions and nodes.
 Cognition name, weights, node resistances and value. o Optional adjacency matrix for the input, output, and modification of the network. o Saving and Loading of the network. o Start and Pause the simulation.

Be able to monitor the simulation of the neural network. o Intuitive user interface to display all of the required information. o Graphically see the change of dissonance/consonance over time within the network. o Be able to see the properties of specific nodes and connection weights within the network. o Graphical display of the cognitions, their nodes, and the connections between the nodes.

The application software which satisfies the Software Requirements.

Source code and documentation upon request.

Project Plan Document, Design Document, and any future documents for CS 499.
3

During development the project will be reviewed by the client every week or bi-weekly at his discretion. More specifically, the algorithms used to implement the cognitive dissonance reduction must be reviewed and verified to be performing correctly by the client during development of the application.
Team Responsibilities

We will keep in contact with the client, and insure that there is always an open line of communication between our leader and the client.

The team will ensure the client is updated on design decisions during the weekly or biweekly review.

Any documentation or prototypes of the project will be made available to the client.

We will develop the specified software before the Spring 2010 deadline.
Client Responsibilities

The client will be in direct contact with the team, and keep an open line of communication.

They will be receptive to questions related to the software.

The client will be responsible for ensuring the team knows if the cognitive dissonance reduction algorithms are performing correctly or incorrectly during a review.
By signing this contract the project team members and client agree to the terms listed above from ______________ until the end of the Spring 2010 semester. All intellectual rights of the project source code will be held by the team members of Neurotic.
__________________________
Dr. George Watson
Client
__________________________
Cory Lehan
Leader, Interface, Support
__________________________
Tim Meyer
Testing, Process Manager
__________________________
Jarrod Capps
Implementation, Plan Manager
__________________________
Jonathan Bridges
Design, Quality Manager
4

Author: Jonathan Bridges
Updated: 12/11/2009
The hardware requirements for this application are fairly minimal. The application must be able to run in a windows environment capable system. The speed and memory of the system will have little impact on the overall application due to the basic calculations that are performed to update and display the Neural Network. A 1 GHz, or greater, processor would be sufficient to run the final application based off the performance of similar applications on that system. All graphics will be rendered in 2D, and will not require a dedicated video accelerator. Disk storage will also be at a minimum, with a required size no greater than 50 MB.
The application will need to be able to run under the Windows XP 32-bit operating system.
Key Terms
Cognition - The term refers to a faculty for the processing of information - this can be a “belief” or feelings of “responsibility” that a person holds. Within the context of this project, it will act as a container of two neural network nodes.
Resistance - This term is used in relation to the “resistance to change” assigned to a cognition.
Node - Is connected with every other node, and contains a level of activation (how much they are affected by the other nodes). A node can be positive or negative, which simply represents the north or south pole of the cognition it is located at.
Connection - Every connection bridges two nodes together. A connection is assigned a “weight” with increases or decreases the flow between the two nodes.
Cap - A connection which connects a node to itself.
Consonance - The amount of “agreement” between cognitions. In this project’s context, it is the amount of similar activation numbers between nodes.
Dissonance - The amount of “disagreement” between cognitions.
Neural Network
A neural network will be implemented in the manner described by the client and his resource, “Connectionist Models of Social Reasoning and Social Behavior” by Stephen J. Read &
Lynn C. Miller. This will consist of a series of 2 to 8 cognitions, each containing a positive node and a negative node, and connections made between every node, including self connections. All cognitions will contain a resistance property, which affects their resistance to change. Every node will consist of an activation number, which measures their amount of activation. Finally,
5

each connection will contain a weight value for determining the amount of activation that leaks through from one side of the connection to the other.
Neural Network Creation
The neural network will be created by the user of the application. The user should be able to specify the number of cognitions, name the cognitions, and give resistances to them. The user should also be able set the properties of the nodes and the connections between the nodes.
The creation of the neural network can be done from scratch as previously mentioned, or through loading of a previously saved network.
Cognitive Dissonance Reduction Simulation
After the neural network has been created, a simulation of cognitive dissonance reduction must be possible. This will be done through implementing the algorithms described in,
“Connectionist Models of Social Reasoning and Social Behavior”. The simulation can then be run and paused at any time by the user.
Neural Network Monitor
A graphical representation of the created neural network will be displayed to the user, complete with cognitions, nodes, and connections. From the graphical display the user will be able to see properties of the neural network, such as a connection’s weight, or a node’s activation.
During a simulation, the level of dissonance or consonance will be displayed to the user as a graph. The graph display will run alongside the cognitive dissonance reduction simulation, giving updated levels of the dissonance/consonance while the simulation is running. Each update will occur after the update algorithm has been fully applied to every node, thus the simulation time won’t be important.
Due to the vast amounts of information that a user could potentially want to see, individual interface elements in charge of displaying information should be well hidden, but offer an intuitive means to making their information visible in order to cut down on the interface complexity while providing maximum usability. (See Figure 1 for interface mockup)
The update of information during a simulation should be consistent across all avenues of display. For this reason, the slow display of some information vs. others due to performance issues must not be allowed.
6

Figure (1) Interface Mockup
The feature list was generated based off the requirements gathering methods listed in the Gathering Requirements sub-section. Once a list of all the features were generated and agreed upon, a priority was assigned to them based off several factors, including: an early deadline for core functionality, risk analysis, and need of client. Time estimates were created based off past experiences, and are improved (made more accurate) as the project progresses.
Very High
Neural network components with attributes
1 Cognitions, Nodes
2 Connections
3 Update algorithm for iterations
4 Neural network creation wizard
GUI layout
5 File, View, and Help top menu
6 Start, Pause, and Reset buttons
7 Labeled areas for graphical and graph output
Save Network
8 Gather all the attributes of the network for storing
3
-
1
1
-
2
2
4
1
-
2
7

High
Medium
Optional
9 Save attributes to a file in a specific format
Load Network
10 Read in and parse a saved network file
11 Set attributes of the network and generate it
12 Real-time graph output of dissonance
Graphical representation of the neural network
13 Dynamically create based off user created network
14 Cognitions, Nodes
15 Connections between the nodes
16
Change connection graphic based off current positive or negative
connection
Interactive dissonance graph
17 Crosshair selection
18 Zoom, print, menu
Interactive graphical representation
19 cognition/node/connection selection
20 pop-up menu with values of the selection
21 Ability to store past network iterations
-
6
6
3
View of past iterations -
22 Select past iterations by selecting area on dissonance timeline graph 4
23 View past iterations by looking at updated graphical representation 4
24 Be able to manipulate network attributes in graphical representation
25 Real-time graph output of consonance
4
3
26 Real-time graph output of selected nodes
27 Brain graphic of neuron interactions
28 Ability to read in excel adjacency matrix for creation of network
4
12
5
-
1
4
8
4
4
5
-
2
2
2
-
2
8

Author: Jonathan Bridges
Updated: 12/11/2009
The methodology employed for this project is based off certain “Best Practices”, often outlined in agile methodologies. We will maintain consistent reviewing with our customer, and keep the customer involved in the creation of the software to the best of our abilities. Code will also undergo reviews for refactoring in order to improve and maintain the software throughout its development. Unit tests for a block of code will be created before the actual block of code.
Stand-up meetings, parallel to Scrum’s stand-up meetings, between team members will be conducted several times a week, if not every day, in order to keep everyone in the know with how each team member is progressing. Finally, applying Design Patterns to solve problems will be used when appropriate.
Our process for developing the software pulls heavily from an incremental development process. Specifically, our process uses aspects of some agile methodologies, such as Scrum and
XP. We begin by gathering requirements, creating a system structure design, and then dividing the development of the system into incremental stages, with key functionality guiding the separation of iterations. Finally, the last system testing is conducted to prepare for the release.
9

Gather Requirements
Requirements are gathered through several iterations of meeting with the client, developing use cases based off talked about features, and then developing a priority list of features for the client to review. The final priority list of features will be later used in the system design, and when creation a new development iteration. (See Requirements Analysis section for
the generated Feature Priority List)
Design - System Structure
In order to bring focus to the incremental development phase, a system structure design is created. For this project, it will consist of a static class diagram outlining the relationships between elements of the software, and pseudo-code design of the required algorithm for updating the neural network. (See the Software Design section for the static class
diagram and algorithm design)
Incremental Development
The incremental development phase consists of a series of iterations, each building an area of the software, or adding onto a previously built area. A single iteration begins by having a
“Feature-to-Task” meeting in which a list of features are picked from the Feature Priority List based off their priority and estimated time to complete. Next, a design of the software for that particular iteration is created. The implementation of it then commences, alongside unit testing.
Afterwards, system testing is conducted for the particular iteration. Finally, a review of the code, and a final review with the client end the iteration. (See Plan Document for breakdown of
iterations)
10

System Testing
Near the end of every iteration through-out the development, system testing is performed to make sure new additions (if it’s not the first iteration) have not caused any problems to develop in other areas of the system. After the final iteration, however, an overall system test is conducted to provide assurance that each feature described during the requirements analysis acts as it should. (See the Test Plan section of the Plan Document for
detailed testing information)
Review & Release
A final review of the code and overall software functionality is performed, as well as a final review with the client. On completed, the finished product is released.
All team members will keep a log of their activity, in an excel document. Each log entry will consist of the date of the entry, a brief description, and how long the activity lasted (in hours, decimal values allowed). A team member’s log entries are divided by month, with a total of that month’s hours given below it. All logs are accessible from the project website, under the documentation section.
Throughout the development of the software a variety of tools will be used to support our progress. To facilitate development with multiple team members working on the same system, we’ll be using the version control system Subversion. The development environment for our project will be in the NetBeans IDE, due to our programming language choice, Java, and due its integration with Subversion. NetBeans also provides JUnit support, which will be used for
Unit Testing. For generating software reference documentation, Doxygen will be used. Finally, our project will make heavy use of the open source library “JFreeChart” for generating all graph output of the neural network.
The risks in this project will primarily come from three sources.

The first is due to the high dependence on a single algorithm, and not being able to fully test the algorithm until a large portion of the project has been built.

The second risk involves how the graphical portion of the application will work alongside the Graph (JFreeChart) section and all in conjunction with the ever updating data supplied by the neural network.

Finally, the last risk is due to the time constraints imposed by requiring a basic version of the application early in development, so that the client can finish writing a paper to be presented at the BRIMS conference.
11

In dealing with the first risk, we have designed a pseudo-code form of the algorithm, and made its development a priority for our first development iteration. To combat the second risk we have obtained good documentation on the JFreeChart library ($30 Developer Guide, complete with many source code examples), have worked on a design for the graphical portion, and have implemented a simple JFreeChart graph in our High-Fidelity prototype using dummy data (See below for additional info on JFreeChart). This will also aid us in making better predictions on when project milestones can be achieved, which should allow us to finish the project on time. (See Plan Document for more details on the project timeline)
JFreeChart Analysis
To insure the chart generating library will provide all of the functionality we need to meet the requirements, a simple example has been implemented into the high-fidelity prototype which tests its ability to dynamically generate data, clear all data, and allow the user to select specific points in the graph which in turn will send an event to other modules to display different information based on the point selected.
Example code to test some functionality: public void update( double newDomainValue) { domain .setTickLabelsVisible( true ); range .setTickLabelsVisible( true ); iterations .add( iteration , newDomainValue); iteration ++; if ( iteration > UPPER_RANGE ) { domain .setRange( LOWER_RANGE , iteration );
}
} public void clearData() { plot .setDomainCrosshairValue(0); domain .setTickLabelsVisible(false); range .setTickLabelsVisible(false); iterations .clear(); iteration = 0; domain .setRange( LOWER_RANGE , UPPER_RANGE );
} public double getDomainAtCrosshair() { return plot .getDomainCrosshairValue();
}
12

Author: Jonathan Bridges
Updated: 12/12/2009
A static class diagram is used to show the overall system design, with the corresponding relationships among the various elements of the software. The system will be incrementally developed through iterations (see Plan Document for specifics on each iteration), and much of the specific design for each element (i.e. a class in the diagram) has been left for these iterations. However, several major design decisions are shown here, which will act as a guide through the iterative development phase.
Keeping with good Object Oriented Design principles, like encapsulate what varies, the design pattern “Observer” was applied so that the interface elements responsible for displaying information about the Neural Network would be updated whenever new information was available, and only those display elements being viewed by the user would be updated. As well, using this pattern allows new means of displaying the data to be designed and integrated easily into the project at a later date.
In addition, the design pattern “Singleton” was applied to the NeuralNetworkData class to allow a global access to the data generated by the neural network for any element in the system. (See next page for static class diagram)
13

Static Class Diagram of System
«interface»
JPanel
«interface»
Observer
+update()
*
-observers
1
-subject
«interface»
Subject
+registerObserver()
+removeObserver()
+notifyObservers()
NeuralNetworkDisplay
-networkData : Subject
+initializeComponents()
+update()
DissonanceGraphDisplay
-networkData : Subject
+initializeComponents()
+update()
-dataset
1
NeuralNetworkData
-uniqueInstance : NeuralNetworkData
-observerList : ArrayList<Observer>
+getInstance()
+registerObserver()
+removeObserver()
+notifyObservers()
+addIteration()
1 -dataset
NeuralNetworkCreator
+createNeuralNetwork() : NeuralNetwork
-network 1
NeuralNetwork
-creates
+addCognition()
+connectCognitions()
+calculateDissonance()
+updateToNextIteration()
1
* -iterations
-generates
NeuralNetworkIteration
-cognitions : ArrayList<Cognition>
-dissonance : float
2..*
Cognition
-positiveNode : Node
-negativeNode : Node
+addConnectionToPositiveNode()
+addConnectionToNegativeNode()
1 2
Node
-activation : float
+addConnection()
1
*
Connection
-weight : float
Author: Jonathan Bridges
14

Because the graphical representation of the neural network will need to be taken into account when creating the other components of the system, an initial design has been created to better understand how we will make use of JOGL (the graphics library) for its display.
Static Class Diagram of the NeuralNetworkDisplay
15

The neural network will need to be updated through its iterations by an algorithm provided in “Connectionist Models of Social Reasoning and Social Behavior”. However, this algorithm is only provided with loose mathematics, and through a verbose explanation. To help mitigate the risk of not fully understanding the algorithm, a pseudo-code version has been created to aid us in mapping the algorithm to our neural network implementation. update { create next iteration; with current iteration { for(... Node ;)
} thisIteration.SetNodeToNextIteration(nextIteration.Node[i]);
} calculateConsonance {
} float consonance; for(... Node i) { for(... Connection j) { consonance += Node[i].con[j].weight *
Node[i].activation *
Node[j].activation;
}
}
Node.SetNodeToNextIteration(node) { float total = 0; for(... Connection i) {
} total += con[i].weight * con[i].toNode.activation; total += Cognition.resistance; if(total < 0) node.activation = activation + total
* (activation - FLOOR); else node.activation = activation + total
* (CEILING - activation);
Author: Cory Lehan
Co-Authors: Tim Meyer & Jonathan Bridges
16

Author: Jonathan Bridges
Updated: 12/5/2009
All comments will follow the Javadoc standard, with the exception of method authors, which will be used for generating documentation references with Doxygen. All class files will contain a comment header, listing the filename, and a description. All classes will contain a comment header with a description and an author if only one person is working on the class. All methods will contain a comment header with a description, and list any parameters, return types, and its author if not listed in the class header, in Javadoc fashion.
Example:
/**
* Clears the Dissonance Level graph of data.
* @param evt button is pushed.
* @author Jonathan Bridges
*/ private void clearButtonActionPerformed(ActionEvent evt) { dissonanceGraphOutput .clearData(); clearButton .setEnabled( false );
}
To insure control flow and blocks of code can be easily identified, as well as for consistency, certain indentation will be used. Brackets after a method declaration, or control statement will start on the same line, and finish on the line after the last line of code for that method or control statement. As well, any block of code within a method, or control statement will be indented by 4 spaces in the standard “hanging paragraph” style.
Example:
/**
* Opens dialog box for loading a previously saved network.
* @param evt the action event performed
*/ private void loadButtonActionPerformed(ActionEvent evt) { int returnValue = fileChooser .showOpenDialog( null ); if (returnValue == JFileChooser.
APPROVE_OPTION ) { selectedFile = fileChooser .getSelectedFile();
}
}
17

Class, method, and variable names will use the standard convention of “camel casing” to display multiple words. In the case of the methods and variable names, the first letter is lowercase, while in the case of a class the first letter is uppercase. All names should inherently explain their purpose/use through their name, and single letters should be avoided other then when used to iterate through a collection.
Class names should have noun or noun phrase names like Customer, or Account. A class name should not be a verb. Method names should generally contain verbs, or verb phrases like getAccountTotal, or deletePages.

The font used for all documentation will be Calibri, with the body having a size of 11.

Subsection headers will use size 14 bold, with the specified green color.

Section headers will contain a light green background, and green bars on the bottom and top of the 16 point size bold text. Where applicable, they should contain an author and updated (date) section underneath.

There should be an indentation under a subsection header.

Code samples in documentation should preserve the font, color, and format that it displays within the NetBeans IDE.

A blank space should be placed between each section, and subsection.

All new sections should start on a new page.
18

Author: Jonathan Bridges
Updated: 12/5/2009
Our team will strive to maintain open communications with our client. Anyone involved in the project may get caught up in a busy schedule and this can cause a communication disconnect between the client and the team when no one is actively attempting to contact the other. To prevent this, a scheduled bi-weekly meeting at the client’s discretion will be conducted to keep them involved in the development process, and their voice heard by our project team.
With a team size of four, there needs to be a consideration for keeping track of each team member’s accomplishments so that credit goes to the right person, and so that areas of the project can be owned by a member and keep others from intruding on work assigned specifically to them. To accomplish this, all work no done by the team as a whole, be it assigned or unassigned, should contain an “author” tag somewhere to indicate who is responsible for the work. In the case of multiple authors, a main author needs to be assigned (simply called the author) and those that helped may be assigned as “co-authors”.
While this project is, by itself, meant to develop a specified piece of software for a client, it is also part of the Senior Project two-semester course within the Computer Science department. This means that all team members will rely on each other for part of their grade within these courses. For this reason, all members should put forth their best effort to offer quality work to the project that will take into account not just their own expectations, but the expectations of their fellow team members.
19