We decided that the most appropriate architecture to follow is that of the Model View Controller or MVC. Model-View-Controller (MVC) is a classic design pattern which is often used by applications that need the ability to maintain multiple views of the same data. The MVC pattern relies on a clean separation of objects into one of three categories: The category of models which is responsible for maintaining data, the cate- gory of views for displaying all or a portion of the data, and the category of controllers for handling events that affect the model or view(s)1.
At this point it would be good to identify the problem that urged software engineers to define and design the model view controller architecture in order to acquire a better understanding why MVC is needed. It is a fact that user interfaces attract many change requests over time and it may be the case that different users of the same interface may ask for different changes. Furthermore, user interface technologies change rapidly across time and programmers may want to support different ”look and feel” standards in order to comply with different users’ needs. Additionally they want to encapsulate important core code in packages that should be separated from the interfaces.
They had to design a pattern where an interactive system could be arranged around a model of the core functionality and data. The system should possess separated view components that would present views of the model to the user. Additionally there should be controller components that could accept user input events and translate them into appropriate requests to views and/or model. Finally it should be complemented with a change propagation mechanism which could take care of the propagation of changes to the model.
The solution was the design of the MVC architectural pattern which supports the development of a core model which is independent of style of input or output and gives the programmer the capability to define different views which may be needed for
different parts or for the project as a whole. Each one of these view components is able to retrieve data from the model and to display it and is accompanied by an associated controller component to handle events from users. The separated model component notifies all appropriate view components whenever its data changes.2 In the following picture we could observe a simple representation of MVC architecture.
ahttp://www.pnp-software.com/eodisp/images/mvc-original.png
Figure 6.1: The MVC Architecturea
Our work is designed in a similar manner. We created from the downloaded data the model component and the controller component is the one that is responsible for manipulating the model according to the several mechanisms that we wish to support. Finally the view component is obligated to represent the graphical user interface. The next step is to assign each class of our prototype implementation to the appropriate component and give a small description of the functionality of each class. Our system consists overall from 22 classes that contribute to the final result. These classes are:
1. Thsesis.java: This class is responsible for initializing the main components and includes the main method for our project.
2. initializeTwitterApi.java: This class is responsible to initialize the authentica- tion keys for the twitter API and connect to the author’s account.
3. MyController.java: This class is responsible for the information flow between the nodes of the graph and contains the action listeners for each specific button 2http://www.inf.ed.ac.uk/teaching/courses/sapm
of the Graphical User Interface.
4. hashtag.java: This class is responsible for keeping state of the different subjects that are contained in tweets and of the nodes that are contributing to the different subjects.
5. Spaces.java: This class is responsible for a partial tweet analysis and determines if tweets do contain special Unicode space characters like: line separator, space, paragraph separator, medium mathematical space, etc.
6. regularExpressions.java: This class is responsible for the partial tweet analysis with the aid of regular expressions.
7. Extractor.java: This class is responsible for parsing tweets with the help of spaces.java and regularExpression.java. For example it is able to extract all the mentioned names or hashtags that are contained within a tweet or even different URLs that a node may have included in his/her post.
8. FindCliques.java: This class is responsible to identify cliques on the directed graph of twitter. We have already defined what a Clique in the social networks analysis section is.
9. twitterGraph.java: This class is responsible to identify my twitter graph by following a specific rationale that would have the ability to look at my follow- ers and followees lists and iteratively extract from each single user his/her lists. From these lists it identifies all the actual friends, which we defined in chapter 4, that are also included in my lists.
10. MyLink.java: This class is responsible for defining the nature of the edges be- tween the nodes of the graph.
11. MyNode.java: This class is responsible for defining the nature of the nodes of the graph.
12. relation.java: This class is responsible for building all the needed relations be- tween users with the help of classes: twitterGraph.java, MyLink.java, MyN- ode.java. It also keeps state of who is following whom and state of the commu- nication that users may have among them.
13. Model.java: This class builds the main graph model by integrating together twitterGraph.java, MyLink.java, MyNode.java and relation.java.
14. CalculateDegreeTust.java: This class calculates the incoming vs. outgoing degree of each node and assigns trust values according to the result of the calcu- lation. All results are normalized into the interval [0 1].
15. IntrefaceWithSetupAndRun.java: This class is an Interface that each of the trust mechanisms class should implement according to its needs.
16. IterationsOverNodes.java: This class is responsible for traversing over every node within an iterative procedure and extract useful information from the nodes, like determining how many edges they do have, if the nodes converge, etc., and also contains setters and getters methods that each trust mechanism may define. For example set how many iterations we should perform.
17. RankingUtilities.java: This class contains help methods like: compare, toString, sort, etc. that every trust mechanism could use.
18. TraverseNodesAndRankAbstract.java: This is an abstract class and its main goal is to extract the trust value of each node at a specific time. Many methods could be overridden according to specific needs.
19. calculateTrustFromTweetsAndHITS.java: This class is responsible for down- loading tweets for each particular user and with the help of the classes Spaces.java, regularExpressions.java and Extractor.java to build rules and out of the results of these rules construct weights for each node. After that, the HITS algorithm is applied and with the help of the following classes: IntrefaceWithSetupAn- dRun.java, IterationsOverNodes.java and RankingUtilities.java, calculates the HITS rank for each user.
20. CalculateBetweenessCentrality.java: This class is responsible to calculate the betweeness centrality rank for each node with the help of the following classes: IntrefaceWithSetupAndRun.java, IterationsOverNodes.java and RankingUtilities.java. 21. MyRenderer.java: This class is responsible for changing the colors of the nodes
and edges, for changing the visual shape of the graphs and for the zoom in and zoom out functionality of the graphs.
22. View.java: This class is responsible for the main graphical user interface com- ponent.
At this point we have to group together the classes that refer to the same component. According to what the MVC architecture suggests we divided our classes into three main packages which also contained sub-packages. We tried to make our choice of the classes for each package to conform as much as possible with the needs of the MVC architecture that we described previously. (see table 6.1)
Finaly figures 6.2 and 6.3 present our class and sequence diagram. The most impor- tant classes have been included alongside with some important methods and attributes in the class diagram while the sequence diagram tries to capture the dynamic aspects of the system by presenting the graph initialization mechanism.
The sequence diagram includes the main methods that act as connectors for invok- ing the functionality of other classes. In particular we may see that the main Thesis.java class uses the initialization() method to enable a connection with the social network’s platform. The initializeTwitterApi.java class notifies the twitterGraph.java class to crawl the data. After finishing collecting the data set an answer with a finalize() method is sent back that it has closed the connection with the twitter platform and the initial- izeTwitterApi.java class sets the initial parameters for the view part of our system. The Thesis.java class again invokes the Model.java to build a graph out of the crawled data. But the Model.java needs to have all the relations (which nodes are connected with an edge) ready so and it invokes the relation.java. Subsequently relation.java needs all the nodes and links to be initialized and therefore invokes MyNode.java and MyLink.java and waits for all the data to ”arrive”. After the relation.java finishes with the connection it invokes again the Model.java to continue its work through the method frGraph2() in order for the final model to be build. The final two steps consist of the Controller and the View component which are cooperating for the final visualization of the constructed graph.
6.3
Summary
This chapter described our design methodology for our prototype. Furthermore, we did outline and describe the system’ requirements alongside with our java classes specifi- cations. Additionally, we did comment on our system’s architecture and described the reasons for choosing it. Finally, we did create a class and sequence diagram for the initialization functionality of the prototype.
Table 6.1: MVC class distribution Packages and Classes
Model 1. FindCliques.java 2. Model.java 3. MyLink.java 4. MyNode.java 5. Relation.java 6. twitterGraph.java View 1. MyRenderer.java 2. View.java Controller.TrustMechanisms 1. CalculateBetweenessCentrality.java 2. CalculateDegreeTrust.java 3. InterfaceWithSetupAndRun.java 4. IterationOverNodes.java 5. RankingUtilities.java 6. TravesreNodesAndRankAbstract.java 7. calculateTrustFromTweetsAndHITS.java Controller.TextUtilities 1. Extractor.java 2. Spaces.java 3. regularExpressions.java Controller.Initialization 1. Thesis.java 2. initializeTwitterAPI.java Controller.MyGraphMechanisms 1. MyController.java 2. hashtag.java
Implementation
The design part of the project has now been completed and we shall continue with the implementation section. In this section we are going to focus on the environment and the tools that have been used for the coding part of our project as well as the techniques that we adopted in order to acquire all the needed data for the twitter analysis and for our system. We are also going to comment on general coding techniques that we used in our implementation and we are going to present screenshots of our prototype. The overall implementation needed just over 2800 lines of code and we tried to keep it as clean and structured as possible in case that a future student wishes to build on the provided prototype.
7.1
Environment
In our case the environment is the JRE version of Java Sun software and our prototype can run on each operating system with Java environment pre-installed. There is no need to worry about the operating system as the Java Virtual Machine takes care of every compatibility problem that may arise. Additionally we used the NetBeans IDE to code the whole system. We had to make the choice between Eclipse and NetBeans. The reason why we used this specific IDE is that the NetBeans platform, unlike the Eclipse Platform, is 100 percent pure Java. Eclipse uses native widgets for its graphical user interface, which requires a JNI module to be built for every platform which runs Eclipse. Furthermore, the upshot of this is that NetBeans works on more platforms than Eclipse. An application built on the NetBeans platform can run on Windows, Linux, Solaris, without recompilation.