IN3405 Bachelorproject - Final Report

Transcriptie

1 IN3405 Bachelorproject - Final Report chainels - Network Visualisation Hans van den Bogert ( ) Christiaan Titos Bolivar ( ) André Vollering ( ) Technical University Delft, Faculty Electrical Engineering, Mathematics and Computer Science Date: Company: chainels TU Delft Supervisor: G. Gousios chainels Supervisors: E. Buckers, V. Koeman & Dr.Ir. S.I. Suddle Coordinator BSc Project: H.G. Gross

2 i Acknowledgements The last few months we worked on our Bachelor project for Computer Science at the TU Delft. The main objective of this project is letting students experience how it is to work and experience the whole progress of software development. We did our project at chainels a startup company, that is developing a new business to business social media platform. We worked full time on this project for 12 weeks, starting in late April and ending mid Juli This report is the result of our work. We want to thank everyone on the chainels team for their support; especially Erwin Buckers and Vincent Koeman, the two main developers who guided us through the process. Also we want to thank our supervisor, Georgios Gousios, for his comments and thoughts on our progress.

3 ii Nomenclature BCR chain FCR RPC SimpleTest SME Business Chain Recommendation A connection between two companies Friend Chain Recommendation Remote Procedure Call Invoking a procedure i.e. function, on a remote machine and capture its output to be handled on the local machine. A framework for php unit tests and web tests Small and medium enterprises

4 iii Contents 1 Introduction Problem Analysis Current Situation Problem Description Planning Requirements Functional Requirements Nonfunctional Requirements Design Visualization Recommendation Class Diagrams Implementation Visualization Recommendation SIG Feedback Testing Unit Tests Integration Tests Acceptance/User Tests Recommendation Performance Evaluation Creating a Test Set Testing our Algorithms Accuracy Results Running Time Results Conclusions Requirements Evaluation Checklist Recommendations for Future Work System Extensions Optimization Recommendations for CHAINels Conclusion Project Log Process Logs A Screenshots B Problem Description C Plan of Approach D Orientation Report E Requirements Analysis & Design F SiG Feedback

5 iv Summary chainels is a new social network site that focuses on business-to-business relations. chainels found that many companies would be interested in learning more about their business network. A visualization of a company network can provide the user with a clear and simple overview of its network. Our project consisted of creating this network visualization. The visualization should also show the recommended chains of a company. Because the current recommendation algorithm does not provide optimal recommendations (it doesn t take any business logic into account), we also have to design a new recommendation algorithm. We defined three types of visualization for a company: a geographical visualization, a business chain visualization, and statistics. The geographical visualization consists of a map with markers for each company, and lines between those companies representing the chains. The user can filter the companies on industry, chain type and chain creation time. The business chain visualization shows a tree with the companies grouped on either chain type or industry. The statistics show a line graph which shows chains over time, and two pie-charts showing the distribution of chain types and industries. For the implementation of the visualization we used the d3.js javascript library[4]. D3 creates svg elements based on data, and for each element a behavior can be defined using D3. This results in an interactive application. We split the recommendation algorithm into two parts: friend chain recommendations (fcr) and business chain recommendations (bcr). The reason behind this is because these are two very different types of relationships, that don t necessarily have anything to do with each other. For the fcr algorithm we use the Adamic/Adar scoring function to compare two companies. For the bcr algorithm we defined our own score function, based on supply and demand, industry, and distance. Testing our recommendation algorithm we found that it performs considerately better than the current recommendation algorithm. The accuracy of the recommendations is up to 70% higher than the current algorithm.

6 1 Introduction 1 1 Introduction chainels is a business-to-business social media platform. Where other social networks such as Facebook[5] and LinkedIn[12] focus on personal relationships, chainels focuses on companies as an entity. On chainels, companies can make chains with other companies, define supply and demand, write testimonials and more. The website is currently still in development. The chainels team is actively approaching companies (primarily focusing on sme s) to inform them about their new social media platform. Through these talks they found that many companies like to see a visual representation of their business network. chainels themselves agreed with this and the need for a network visualization emerged. chainels also wanted to show chain recommendations in the visualization, which was deemed a logical consequence due to the social nature of the chainels website and a means to further improve the connectedness of the network. Therefore a company recommendation algorithm had to be made, which already existed in some form, but was in need of a complete makeover. Our project consisted of making a visualization of a company network. We defined three main visualizations, each providing the user with a useful, interactive overview of its network. We also designed a new chain recommendation algorithm, aimed at providing relevant business recommendations to the user, as well as providing friend recommendations. The structure of this report is as follows: Section 2 consists of a more detailed description of our assignment and why improvement was needed. In Section 4 we discuss the design of our system and in Section 5 we discuss how we implemented it. In Section 6 we explain how we tested our algorithms and in Section 7 we discuss the results of those tests. And finally, Section 9 consists of a number of recommendations for future work.

7 2 Problem Analysis 2 2 Problem Analysis 2.1 Current Situation Team chainels started out as an idea of dr.ir. S.I. Suddle, and the site was developed as a Bachelorproject by Erwin Buckers and Vincent Koeman. Their project took place in the summer of 2011, and they have continued working on chainels since then. The persons we had contact with and/or worked with on this project are: dr.ir. S.I. Suddle, the CEO of chainels and the company contact for the TU Delft, Erwin Buckers and Vincent Koeman, the two developpers. We met with the two developpers regularly (weekly or more) to discuss our progress, decisions and questions. We also worked with Willem Buijs, the designer, to discuss the look and feel of our application System Back-end chainels is developed in object-oriented php. The relevant classes for us are the Company and Chains classes. A Company has a number of attributes: an id, address, industry and supply & demand labels. A Chain between two companies has the attributes type (Friend, Supplier, Customer or Other), time of creation and a private flag (a private chain is invisible to all other companies). The current recommendation algorithm simply checks for chains of chains and then counts the number of occurrences of a company, returning a list of the companies with the most occurrences. This doesn t give optimal recommendations because it doesn t take into account any business logic. The above classes have their corresponding data saved in a database called Redis[17]. This nosql[21] database keeps all data in-memory. The data is retrieved through keys which have corresponding values. Due to low overhead and the ommittance of relatively slow persistent storage like harddisks and the near-linear scaling of Redis, it provides a future proof solution for data storage. Front-end chainels uses a BigPipe[3] system to load the webpages. With BigPipe a webpage consists of pagelets, small parts of the complete page (for example, the menu bar), these pagelets are then loaded one by one, in a certain order. The visualization and the recommendations will be located in the Chain pagelet (2). The html isn t hand coded, it is generated with php. The idea for the network visualization was to generate a simple graph in php using graphviz[6]. The development team at chainels made a small start with this, before assigning this functionality to a bachelorproject. 2.2 Problem Description As mentioned in the introduction, through their talks with companies, chainels found that many of those companies would be interested in seeing a visual representation of their business network. Especially small businesses like to have this information available to them, so they can show it to others, or analyze their own network. chainels doesn t have such a visualization, but they want to have such a visualization. The new recommendation, which is needed because the current algorithm produces sub-par recommendations, should take into account business information, such as supply/demand, to be able to provide useful new business contacts or opportunities for companies. No trivial complete solutions exist and as such an algorithm must be invented for the specific case of chainels, albeit using preexisting sub-solutions.

8 2 Problem Analysis Planning We divided the project into 4 phases. An orientation phase, a design phase, an implementation phase and the final phase (working on report and presentation). In Figure 1 the planning is visualized in a Gantt chart. In the orientation phase we researched current visualization techniques, existing libraries we could use, and how recommendation algorithms work. This phase was concluded with the orientation report in Appendix D. The design phase consisted of defining the requirements, use-cases, and designing our recommendation d d d d d d algorithm (Appendix E). We then planned a 5 week implementation phase, using scrum as a development e d d d d d d d d de d d method. d e d d e d de e d d e d d e d e e d de e d d e d d e d & / K / & // & /s Z & /// Fig. 1: Project planning

9 3 Requirements 4 3 Requirements This section contains an overview of the requirements made in the Requirements Analysis Document (RAD). The full RAD document can be found in Appendix E. 3.1 Functional Requirements General 1. The company must be able to see a simple geographical graph. 2. The visualization can be toggled to full screen. 3. The user can switch between different kinds of visualizations/graphs. (if there are multiple). 4. The user can click on a company in the graph (represented as a node) and then see the business card of that company (with a link to its page). 5. On the geographical visualization the different kind of industries and the different chain types must be distinguished by color. 6. When there is an older (<IE9) browser, the user will be shown a message to upgrade to a new browser Internal (analysis) 7. There are three different main visualizations (a) Geographical (b) Company chain (c) Statistics 8. For each main visualization, the user can choose a different view. 9. There must be a simple geographical graph. 10. Each graph has a timeline with a slider. Sliding to a different date will update the visualization to show only the chains up to that date. 11. For each graph there must be a zoom functionality. 12. The user can filter different kinds of chain types. 13. The user can see his recommended chains in the geographical graph. 14. In the statistics visualization there is a view of the distribution of chains by industries. 15. In the statistics visualization there is a view of a graph which contains the number of chains over time External 16. A visitor and a user on a company page see a geographical graph of the company network. 17. The nodes that are chained to both companies are marked.

10 3 Requirements Recommended Chains 18. The recommendation algorithm must take into account the industry, supply and demand, location, chain type and possibly competition. 19. Private chains may not be used in the algorithm, to ensure privacy. 20. The recommendation algorithm must give relevant recommendations that looks further than only recommending friends of friends, which is the case in the current implementation. 3.2 Nonfunctional Requirements 21. The user-interface must fit in the current design of chainels. 22. The system must be able to process large amount of users (in the order of tens of thousands). 23. The graphs must be able to display large amount of companies and chains in a convenient and clear way. 24. The network visualization application must be compatible with the modern Internet browsers (IE9+, Firefox, Chrome, etc).

11 4 Design 6 4 Design 4.1 Visualization UI Design The pagelet on which the visualization will be situated, consists of three parts: a box that shows the current chains of a company, a list of chain recommendations, and a placeholder for the visualization. This means that our visualization already had a predetermined size and location. It has to be located on the bottom of the pagelet, and it should be no more than 625 pixels wide. In our requirements document we defined the three visualizations: geographical, business chain and statistics. The business chain visualization can be grouped on chain type and on industry. The statistics consists of a line graph showing the number of created chains over time, and two pie charts that show the distribution of chain types and industries. The statistics are viewed more as a "proof of concept", that can be extended later on by chainels. Fig. 2: Mockup of the User interface

12 4 Design 7 Figure 2 shows a mockup of the user interface design of the geographical visualization. The essential elements are the three buttons to switch the visualizations, the companies as nodes, the chains as edges, the filters and the timeline. All these elements are derived directly from the requirements. Appendix E contains the mockups of the other visualization types. Screenshots of the final UI design are located in Appendix A Retrieving data from the back-end To display the different types of visualizations, data will need to be dynamically loaded into the eventual webpage to keep the application running smooth and fast. Dynamically means that no complete page will have to be loaded from the back-end server. A low-level method of doing so has been around in the browser environment for quite some time now known as Ajax[20]. Ajax is a mechanism for already loaded pages to retrieve data (and display if necessary) from a remote server on a need to have basis. So if a user chooses a different visualization, only the visualization data will need to be transferred. A more conventional way, but less efficient, would ve been to refresh the complete page with the only difference that the type of visualization had been changed. It s not hard to see that transferring page layout, pictures and other resource is subpar when considering responsiveness. To have a consistent manner of approaching the back-end through Ajax, a rpc-over-http api has been created, easing the burden of duplicate code between front-end and back-end by making back-end functions available through http requests. More in-depth details can be found in Section Recommendation Designing the recommendation algorithm, we quickly found that companies on chainels have different types of relationships. The most prominent type of relationship is a business relationship, such as supplier-customer, but a company can also have "friend" relationship. For example stores that are located in the same shopping mall, or two companies in the same building. These companies would also make chains with each other, but do not do any business. To make a business recommendation, a company s "friends" are irrelevant, and to make a friend recommendation the business relationships are irrelevant. We therefore need to make two different recommendations. To this end we designed two algorithms, a Friend Chain Recommendation algorithm (fcr) and a Business Chain Recommendation algorithm (bcr) Friend Chain Recommendation Every social network uses some kind of friend recommendation algorithm. In our orientation report (Appendix D) we researched the field of link-prediction algorithms. Link prediction algorithms compute/predict links (edges) in a graph based on observed links. A score function gives a score to a combination of two nodes (i.e.: probability of those two nodes having a link). We concluded that the Adamic/Adar[1] scoring method would be best suited since this function performed best compared to other scoring functions[10]. The Adamic/Adar score function is as follows: score(x, y) = z Γ(x) Γ(y) 1 log Γ(z) With Γ(x) = the neighbours of node x. The way this works is that the rarer features are weighted more heavily. Adamic/Adar who introduced this measure used it to compute how related two home-pages were. In the case of a social network recommendation these features can be seen as neighbours, so it prefers rare neighbours over common ones. Neighbours are defined as rarer if they don t have many friends. To sum this up, the algorithm returns a high score if there are alot of common neighbours that don t have many friends and returns a low score when there aren t any common neighbours or there are a few common neighbours that have alot of friends. (1)

13 4 Design 8 The idea behind this algorithm is that friends share common friends. People with not many friends have most of the time a better relation with their friends, this is why rarer friends are weighted more heavier. To actually calculate the recommendations for a company x, we use Breadth First Search (bfs) to walk through the graph. bfs can skip the first found layer, since those companies are already friends, and can stop after the second layer, since companies in more distant layers share no common neighbours with x, and as a result the score will always be zero. Algorithm 1 Friend Chain Recommendation (fcr) algorithm 1 function FCR( x, mindepth, maxdepth ) 2 Queue q ; 3 s c o r e s ; 4 5 q. enqueue ( x ) ; 6 mark ( x ) ; 7 8 while! q. isempty ( ) 9 y = q. dequeue ( ) ; 10 i f BFSdepth <= maxdepth 11 i f y!= x && BFSdepth >= mindepth 12 s c o r e s [ y ] = adamicadar ( x, y ) ; 13 end i f 14 for a l l c h i l d r e n c in y. getchildren ( ) 15 i f! c. ismarked ( ) 16 c. mark ( ) ; 17 q. enqueue ( c ) ; 18 end i f 19 end for 20 end i f 21 end while 22 return s c o r e s ; 23 end Cold-Start Problem The above algorithm only gives useful scores if there are any preexisting chains, which is not always the case. For example a newly registered user starts without any chains. We ve decided that the recommendations will then be based upon a trivial algorithm that selects the five most geographically nearby companies. The user most likely knows these companies and are therefore adequate friend recommendations Business Chain Recommendation In our orientation phase we found that most recommendation algorithms work purely topologically based (like Adamic/Adar), or use a content based approach such as defining feature vectors of users that can be compared. A topological approach would not be optimal for business recommendations, since it would ignore relevant business data and would also take friend chains into account. A content based approach would work better in this case. Content based approaches look at features of nodes (companies in our case) and use a score function to compare these features and decide if the two nodes are a good match. We therefore need to define a score function, to compare two companies. Which factors (features) to take into account were determined and discussed first. The most obvious factor would be supply and demand. If company x needs computers and the algorithm

14 4 Design 9 recommends a company y that supplies computers, it s a good recommendation. When two companies are compared we use the following function to determine the supply/demand score: sd(x, y) = supply(x) demand(y) + demand(x) supply(y) (2) The second factor is the industry of a company. While this isn t as important as supply and demand, if a trend is seen in the network that two industries α and β frequently work together, it would still be a good recommendation to a company of industry α to be introduced to another company of industry β. This can also strengthen a recommendation based purely on supply and demand. To discover a trend in the network of two industries working together ("matching") we look at the field of association rule learning. Association rules in general work in a way if for example a customer buys milk and bread, and many customers who buy milk and bread also buy eggs, then eggs are recommended. The association rule in this case would be {milk, bread} {eggs}. Pruning association rules is then done via filtering on the "interestingness" of a rule. This is done by calculating the measure of significance. There are numerous ways of calculating this [13]. We selected the four most often used methods: Support Support is the most basic method. The score returned is the amount of occurrences proportionate to the data set. If the support of an item is 0.3, it means the items occurs in 30% of all rules in the dataset. It can be used on single items or association rules themselves. Support(X Y ) = size P (X, Y ) and Support(X) = size P (X) Where X Y is the association rule between items X and Y, and P (X, Y ) is the chance of X and Y occurring together in a rule. Confidence Confidence is one of the more common methods. This function is calculates a relative score. Confidence(X Y ) = P (Y X) = Support(X Y ) Support(X) Lift This function is one of the less common methods. Lift is based upon the idea to see how strong X influences Y. It works almost the same as the confidence rule but instead of dividing by the support of the first item it divides by the support of the first item multiplied by the support of the second item. Lift(X Y ) = Support(X Y ) Support(X) Support(Y ) Conviction Conviction is also one of the less common methods and is based upon the idea that X and Ȳ shouldn t occur together. Conviction(X Y ) = size Support(X) size (1 Confidence(X Y )) To translate the general concept of association rules to our problem of "matching" two industries, we can view a chain between two companies (and thus two industries) as an association rule. If company x of industry α has a chain with company y of industry β, the association rule becomes α β. This simplifies the whole process of association rule mining, since we only have one-to-one rules (a company can only belong to one industry). Those rules are directly useable because they are the chains themselves. Comparing two industries we then can simply look up the "interestingness" of that potential combination and use that result as our score between two industries. Therefore our score function to compare two industries is: iscore(α, β) = interesting(α, β) (3)

15 4 Design 10 Where interesting(α, β) is one of the calculation methods support, confidence, lift or conviction. Which method is chosen in the final implementation should be decided after testing. The complete score function of comparing two companies x and y then becomes: score(x, y) = g i iscore(x.industry, y.industry) + g sd sd(x, y) (4) where g i + g sd = 1 When two companies have the same score, we then use a third factor, distance, to sort those companies. The final bcr algorithm uses the same breadth-first-search algorithm as fcr in Algorithm 1. For the maximum depth we choose 6, because of the "six degrees of separation" principle[22]. 4.3 Class Diagrams Figures 3 and 4 show the (truncated) class diagrams. For the recommendation design, we decided to create an interface class Recommender. This provides an easy way of changing the functionality of the Recommendation algorithm if needed in the future (for example, use an alternative to Breadth First Search), without the need of complicated refactoring.

16 4 Design 11 pkg Recommendation <<interface>> Recommender + getrecommendedfriendchains(company : Company) : array + getrecommendedbusinesschains(company : Company) : array + friendscore(cid1 : String, cid2 : String) : float + businessscore(cid1 : String, cid2 : String) : float - industryweight : float - sdweight : float BFSRecommender + breadthfirstsearchwithscore(root : string, childgetter : function, score : function, mindepth : int, maxdepth : int) : array + friendscore(cid1 : String, cid2 : String) : float + adamicadarscore(array1 : array, array2 : array, frequency : function) : float + businessscore(cid1 : String, cid2 : String, iweight : float, sdweight : float) : float - sortondistance(scores : array, root : Company) : array - sortscore(same : array, root : Company) : array + distance(cid1 : String, cid2 : String) : float AssociationDiagram + filldiagram(method : String) : void + fillwithsupport(links : array) : void + fillwithconfidence(links : array) : void + fillwithconviction(links : array) : void + fillwithlift(links : array) : void + getindustryscore(cid1 : String, cid2 : String) : float SupplyDemand + supplydemandscore(cid1 : String, cid2 : String) : float AssociationRules + getalllinks() : array + createlink(industrykey1 : String, industrykey2 : String, cid1 : String, cid2 : String) : array + calculatesupportrule(industrykey1 : String, industrykey2 : String, links : array) : float + calculateconfidencerule() : float + calculateconvictionrule() : float + calculateliftrule() : float Fig. 3: Class Diagram for the Recommendation component

17 4 Design 12 pkg Visualization + class : String + method : String + arguments : array Ajax_Controller_AbstractController + construct(class : String, method : String, arguments : array) : void + invoke() : void Ajax_Controller_AbstractLoggedInController + cid : String + internal : boolean + invoke() : void + createajaxclass() : void Ajax_Controller_GraphData + createajaxclass() : void GraphData - cid : String - internal : boolean + getgraphdata() : void + plainclass : GraphData Ajax_GraphData + construct(cid : String, internal : boolean) : void + getgraphdata() : void Fig. 4: Class diagram for a part of the RPC framework (not every method of GraphData is shown)

18 5 Implementation 13 5 Implementation 5.1 Visualization Making the visualization In the orientation phase we decided on using the d3.js (Data Driven Documents) javascript library[4] for our visualizations. D3 creates svg (Scalable Vector Graphics) elements based on data. svg is an xml based file format, used for creating static or dynamic vector images. Each svg element can be controlled exactly the same way as any other html element, with behaviour based on events such as mouse clicks, mouse overs or scrolling. It also means that each element can be styled using css. D3 lets you easily define these behaviours and styles for each element (in a similar manner as jquery[8]). The data that D3 uses to create svg elements use is in a json-format. Making D3 work is straightforward, simply include the Javascript files in the html page, and make sure there is a div element on the page that will contain the svg element generated by D3. The business chain and statistics visualizations are pure D3. For the geographical visualization we needed an extra library since it required a map that allows for zooming and panning. Polymaps[16] is such a library, it is very similar to D3 as it is written by the same author. Polymaps loads map imagery from a source. We used bing Maps[2] imagery since chainels already used bing Maps. Polymaps is capable of plotting points on the map based on coordinates, so in fact D3 isn t even needed for this. However our visualization also required lines (arcs) between points, and that is not possible in polymaps alone. This is why D3 is also needed for the geographical visualization. Creating the visualization starts in the file visualization.js, seen in Listing 1. InitVis() is called when the html body is loaded. Then we use Modernizr[14] to check whether the browser is compatible (supports svg) and load the appropriate javascript files. The get..() functions are called through buttons on the html page and switch the selected visualization accordingly. Listing 1 Excerpt from visualization.js 1 var companyid ; 2 var baseurl ; 3 4 function initvis (c, u) { 5 companyid = c; 6 baseurl = u; 7 8 Modernizr. load ({ 9 test : Modernizr.svg, 10 yep :// load required javascript files, 11 nope : // show update browser prompt 12 complete : function () { 13 if ( Modernizr. svg ) { 14 initgraph (); 15 } 16 } 17 }); 18 } 19 function getgeo () {...} 20 function getbusiness () {...} 21 function getstats () {...} The actual creation of the visualisation is done in the generate-...-.js files (Listing 2). Here the required data is requested through the d3.json() function. In the callback of that function the svg elements and behaviours are generated and defined.

19 5 Implementation 14 Listing 2 Requesting the data and creating the main svg element (excerpt of generate-pie-chart.js) 1 d3. json ( baseurl + " Ajax / Statistics /" + action, function ( data ) { 2 3 // Creating the main SVG element 4 var vis = d3. select ("# chainmap "). select ( div ) 5. append (" svg : svg ") 6. data ([ data ]) 7. attr (" width ", w) 8. attr (" height ", h) 9. append (" svg :g"); 10 } Retrieving the data - RPC framework The RPC framework needed as explained in section 4.1.2, will work by sending a php function name and if needed its arguments in a special formatted url. E.g. Class/function/arg1/val1/arg2/val2/../.. would retrieve the data for Class->function( arg1 = val1, arg2 = val2 ). Because of the intrinsic differences between an rpc request and the actual back-end code, some glue-code cannot be omitted. To make this mapping beween rpc call and php-code consistent, a (url)router-class parses the url request given by the http-server, and loads the corresponding Ajax_Controller_${Class}-class (where ${Class} is the value parsed from the url) which handles any peculiarities (like object initialization and resource authorization, etc) needed to fulfill the actual function which it delegates to a newly created Ajax_${Class}-object. The wrapper classes Ajax_${Class} on their part retrieve the output of the wanted function from the intended {$Class} and make the output marshallable, in the form of a json encoded string, which will be sent as output to the front-end ready to be parsed by javascript. A sequence diagram has been provided in Figure 5 to give a visual impression of a rpc-request. sd RPC Framework index.php : Router : Ajax_Controller : Actor <<request>> route() : Ajax_Controller : GraphData getclass() : Ajax_Controller_AbstractController <<create>> : Ajax_Controller_GraphData <<return>> invoke() : void <<return>> createajaxclass() : void <<create>> : Ajax_GraphData getgraphdata() : void getgraphdata() : void <<return>> json data <<return>> array Fig. 5: Sequence diagram of rpc-request

20 5 Implementation Integrate into CHAINels The html pages of chainels are completely generated in php. The page where the visualization should appear is generated in the file Chain.php in the chainels source code. The file has a very straightforward structure, it has functions such as getjsfiles() and getcssfiles(). In Visualization.php (Listing 3) we defined similar functions that are then called in Chain.php. Visualization.php also contains all the other functions that are used to generate necessary html elements for the visualizations. Listing 3 Excerpt of Visualization.php 1 class Visualisation { 2 3 public static function getjsfiles ( $company, $account ) 4 { 5 $internal = empty ( $account )? false : ( $company - > getcid () === $account - > getcid ()); 6 if( $internal ) 7 { 8 return array ( dirname ( dirname ( DIR ) ). / graph / javascript / modernizr. js, dirname ( dirname ( DIR ) ). / graph / javascript / visualization.js ); 9 } 10 else 11 { 12 return array ( dirname ( dirname ( DIR ) ). / graph / javascript / modernizr. js, dirname ( dirname ( DIR ) ). / graph / javascript / external - visualization.js ); 13 } 14 } } 5.2 Recommendation Friend Recommendation In Section we ve discussed how we will use bfs as a means to traverse the network graph. The scoring function is injected through means of closures (passing another function reference through parameters of a function-call), this keeps the readability of the original bfs and provides a simple mechanism to inject other scoring functions. This means we can use the same bfs implementation for the fcr as well as the bcr algorithm. Another part which is done through closures is the method used to retrieve the children from a particular node. The scoring function itself following Adamic/Adar s method takes 2 arrays, computes the intersection of those and then retrieves the frequency and then returns a score using the amount of outgoing relations of those intersected nodes.this means that the scoring function retrieves 2 arrays of companies and provides a score based on the number of chains of a common company. The code for the scoring function can be found in listing Business Recommendation Association Rules To calculate the association rules we simply take all the chains in the database and take the industries of those companies so only the rules "industry industry" are left. Calculating the scores of the association rules is not done on every run. We create a 16x16 matrix (there are 16 industries defined) to easily look up the values. This matrix is saved in the Redis database row by row, meaning that for each row, there is a key value pair key i (key 0 value,.., key i value, key i+1 value,..) (where key i is the key of industry i). How the matrix is filled and then saved can be seen in listing 5. For now the function to fill this matrix

21 5 Implementation 16 Listing 4 Excerpt of BFSRecommender.php 1 // generic Adamic / Adar function 2 public static function adamicadarscore ( $array1, $array2, $frequency ) 3 { 4 $commonelements = array_intersect ( $array1, $array2 ); 5 $score = 0; 6 foreach ( $commonelements as $commonelement ) 7 { 8 // note that $frequency is not a variable, but a reference 9 $score += 1 / log10 ( $frequency ( $commonelement ) ); 10 } 11 return $score ; 12 } // based upon domain - model 15 public static function friendscore ( $cid1, $cid2 ) 16 { 17 $array1 = Chains :: getcompanychainsids ( $cid1 ); 18 $array2 = Chains :: getcompanychainsids ( $cid2 ); 19 $frequency = function ( $ccompany ) 20 { 21 return Chains :: amountofchains ( $ccompany ); 22 }; 23 return BFSRecommender :: adamicadarscore ( $array1, $array2, $frequency ); 24 } (filldiagram();) is called manually, in Section 9 we make recommendations on when to run this function. We implemented each of the four "interestingness" functions defined in Section 4.2.2, to be able to later test which function gives the best result. A method is selected by giving filldiagram( $method ); a parameter "lift", "support", "conviction" or "confidence". Listing 5 shows the structure of this class. Supply and Demand The supply and demand score is in a separate class. We defined a very trivial function of comparing supply and demand. The matching is done by comparing the demand of one with the supply of the other one and the other way around. This is done by simply checking whether the two strings are equal. When the matching is done it divides the outcome by the size of the first company s demand and supply, returning a relative score. Combining the two parts The association rules and the supply and demand score get combined within the class BFSRecommender in the function businessscore(). The function takes 4 arguments, the first two are company id s and the last two are the weights (respectively industry weight and supply/demand weight). This method calculates both scores and multiplies them with the associated weight and returns this score. The scores are subsequently sorted on distance if they are equal. The score function is then injected into the bfs algorithm, as described in Section SIG Feedback During the 2nd week of the implementation phase, the code code was submitted to the SIG, Software Improvement Group, which reviewed the code and provided feedback, resulting in some pointers to improve the current codebase. A translated version in English is provided here, followed by sections giving response to the critique points thereafter. The original feedback in Dutch can be found in Appendix F.

22 5 Implementation 17 Listing 5 Excerpt of AssociationDiagram.php 1 class AssociationDiagram 2 { 3 public static function filldiagram ( $method = lift ) 4 { 5 switch ( $method ){...} 6 } 7 8 public static function fillwithconfidence () 9 { 10 foreach ( $industry as $industryfrom ) 11 { 12 // Create each row of matrix 13 foreach ( $industry as $industryto ) 14 { 15 $scores [ $industryto ] = confidence ( $industryfrom, $industryto ); 16 } 17 setindustryscore ( $industryfrom, $scores ); // Save to database 18 } 19 } 20 public static function fillwithlift (){...} 21 public static function fillwithconviction (){...} 22 public static function fillwithsupport (){...} 23 } The codebase scored about 4 stars on our maintainability model, which means that the code is above average. The highest score is not given, because of a lower score for Unit Size, Unit Interfacing and Component Balance. For Unit Size our [SiG] system looks at the percentage of code that is above average in length. The splitting of these methods in smaller chunks provides better maintainabilty, testibility and ease of understanding on first glance. The getbusinessgraphjson - methode in BusinessGraphData is an example of a too long method. Try to look critically at the longer methods in the system and refactor if needed. For Unit Interfacing, we looked at the percentage of code in units with an above average amount of parameters. Usually that signifies a lack of abstraction. Besides that, a large number of parameters usually leads to confusion in the calling of a method and in the most cases it also leads to longer and complexer methods. What is apparent about this system is that inside the AssociationRules -class s methods a variable firstindustrykey as well as SecondIndustryKey is signatured in most methods. It appears these variables form a concept of a Rule. To make it more clear for future code-edits and know what to provide to these methods, it might be worth considering introducing a new type/class for this concept. For component balance, there s been looked at the amount of components and the distribution of the amount code over these components. Both aspects influence the ease of finding some particular functionality within the system. What is apparent in this system is that on the first level distinction has been made between technology type ( hml, javascript, php). Within the html directory however is no html-formatted code, but also php. There appears to be made some distinction in directories for Ajax functionality within the PHP-directory but it appears more distinction in functionality could be made. Especially if the system will grow, we recommend to distribute the code over more components. In general the code scores above average and the existence of test-code is promising at the least. Hopefully the amount of test code will also grow as new functionality is added.

23 5 Implementation Unit Size After review, the unit size of some functions/methods was indeed long. Methods like getbusiness- GraphJSON in the class BusinessGraphData have been refactored and common functionality has been moved outside the method which later on can be re-used Unit Interfacing SIG s review concluded that the method signatures in the AssociationRules -class were unneedingly repetitive among several methods. To be more specific, there were several methods with firstindustrykey and secondindustrykey as their parameters. Their critique is valid, however these methods are not used together. As explained in this report, we implemented four different methods of calculating the industry scores (support, confidence, lift and conviction), to test which one would yield the best result. Only one of these functions will actually be used. If this was a function in any other type-friendly programming language in contrast to php, a tuple would ve been an appropriate parameter. But a complete class seems overkill for such a primitive type as 2 junctioned keys, which are just integers Component Balance The main point of critique is our distribution of code over components, is grouped by technology i.e. directories for php, Javascript and html files. Hardly any namespacing was done, we did introduce functionality separation in the Ajax-rpc subsystem. As our added functionality written for this project, would be placed as an module within chainels source-tree, we initially used this directory layout as it was expected by chainels because it mimicked their current layout. It did feel as an arbitrarily chosen layout then and it does now, however before serious replacement of the components can be made, unit-tests and integral tests need to be up to par before beginning a high level refactoring, this includes the code of chainels. Recommendations for future development on the code base is handled in the separate dedicated section 9. We did however split up the code into two components "graph" (for the visualization part) and "recommendation" (for the recommendation part). In these two components we kept the same structure as described (grouped by technology).

24 6 Testing 19 6 Testing 6.1 Unit Tests We defined unit tests for each class. The unit tests made use of a framework named SimpleTest[18], that was already used by chainels. These unit tests were used to validate that our recommendation algorithms worked to a certain level (calculating values) and that the classes who parsed data for the visualizations, parsed their data to json format correctly. That last part was necessary in the beginning, before we discovered a handy php function called json_encode(). We first tested the Javascript files for the visualization with no dependencies on the classes that provide the data. We did this by using a separate json file Mocking and Current Design Limitations Due to the current database and software structure we couldn t make use of mocks, because almost every class is tightly coupled wih the database and dependent on its results (e.g. auto incrementing keys). A concrete example is that a typical model class like Company currently has knowledge about the inner workings of the database (Redis) to save its own state to the database, this goes directly against the principle of Separation of Concerns [7] and thus makes testing more difficult than it needs to because making a simple mocked object resulted in the need of a complete database. Without having to rewrite the existing codebase, we solved this problem partially by making an array of companies. That set of companies is then saved on-the-fly into the Redis-database (needed due to the tight coupling in the codebase), using chainels existing functionality. Afterwards, certain chains were created among these companies to represent some (sub)sets of connected companies. These steps are the bootstrap we needed to do before actually starting with any test. When the test class ends it calls a function that removes the companies, which were previously added from the database, to keep a clean slate for next tests by guaranteeing database state. The common set of these mocked companies introduced another problem, because individual team members occasionally introduced new data to it to test their own individual test classes edge cases which could make unit tests of other classes fail due to their dependence on the set s state. This problem was quickly noticed and we searched for a way to solve this easily without investing to much time in it. The way it was solved was done by making an external file containing those same companies in a special but straightforward format. The benefit of the external file is that it can be easily adjusted (adding companies, adding relations). In the unit tests we first call the external file and then create the desired relations (chains) set by selecting a relations set within the external file. Listing 6 shows an excerpt from the external file. The external-file solution, is not ideal, but was necessary to circumvent chainels current design limitations. Recommendations to better the existing codebase s current design will be provided in Section 9.

25 6 Testing 20 Listing 6 Excerpt from the external file [0] abouttext = " Bachelorproject!" isinternational = true businessnumber [] = businessnumber [] = NL mission = Eenvoudige software maken voor iedereen companysizekey = 2-5 founded = 2012 basicsupply [] = Screens basicsupply [] = Servers basicsupply [] = Books basicdemand [] = Computer basicdemand [] = Webshop basicdemand [] = Software streetname = Mekelweg streetnumber = 4 zipcode [] = 2628 CD zipcode [] = NL state = Zuid - Holland city = Delft name = Network Visualisation Project industrykey = in industrylabel = Software en Websites countrykey = NL rel [] = "0-3 -3,1-2 -3,3-1 -3,5-0 -3,9-0 -3,8-0 -3,7-8 -3, ,9-6 -3,4-2 -3, ,1-0 -3, " 6.2 Integration Tests Once the unit tests showed that the data classes for the visualization, and the RPC framework worked properly, we integrated the back-end into the front-end (the javascript files). Since then the visualization was tested mostly by user tests (essentially making each user test an integration test). The recommendation algorithm was tested to see whether it performed on accuracy and running time. The results of those tests can be seen in Section Acceptance/User Tests Since the visualization is primarily behaviour based, user testing was key. We user tested after we implemented each new feature, using the Javascript Console available in most browsers, to check for errors. User tests were done also by a few members of chainels itself, this came in handy to see if it worked according to their expectations/needs. After each iteration we got feedback on the application from the chainels team, that we discussed and processed.

26 7 Recommendation Performance Evaluation 21 7 Recommendation Performance Evaluation 7.1 Creating a Test Set We quickly realized that in order to test our recommendation algorithm, we would need a realistic data set, with meaningful relations between companies, real addresses, real industries and matching supply and demand. The problem was this data set didn t exist. We wanted to use the old database, this old database is from the beta phase of chainels and is filled with companies that signed up in that phase. Unfortunately this data set is inappropriate, as many companies simply created chains to try the system out, which meant the relations in this data set were not of any use for us. This is why we decided to create our own data/test set. In total we created 41 companies, companies that we found on the internet, defined supply and demand for each of them and then made chains between them according to supply and demand, just like a real company would probably do. Although the data set is not "real" it is an as realistic as possible data set we could have. Figure 6 shows the test set visualized in a graph Fig. 6: Visualization of the test set 7.2 Testing our Algorithms The fcr algorithm uses Adamic/Adar to provide scores. As this method has already been researched and tested extensively [24, 11], testing this algorithm on its accuracy wasn t a priority for us. For our bcr algorithm we used our own defined test set. For each company whose recommendations are calculated, we first randomly remove a chain, then run the recommendation algorithm, and then check if the top five computed recommendations contains the removed chain. We did this 100 times to calculate the average results. Algorithm 2 shows the test algorithm.