the recommended application evaluation system ( rae ) solves the technical problem of providing a tool to easily and quickly evaluate a recommended application to validate that the recommended application implements a particular functionality . in one implementation , the rae may evaluate recommended applications obtained from the executable examples archive system ( exemplar ). exemplar provides a tool that accepts high - level processing concepts as queries to identify , determine the behavior , rank and return the application logic of hras . exemplar solves an instance of the difficult vocabulary problem that exists when users and developers describe processing concept with different words . exemplar is not limited to basic keyword matching used in queries against application descriptions and comments included with application logic . accordingly , when an application is highly relevant , and where a query contains keywords different from the words used by the developer to describe application logic and api call logic , exemplar nevertheless returns the application as a highly relevant application . exemplar matches high - level processing concepts ( e . g ., expressed using keywords ) with the descriptions of various api calls found in help documents or other trusted descriptive sources . because a typical application invokes api calls from several different libraries , several different people who use different vocabularies often author help documents associated with api calls . the richness of different vocabularies increases the probability of finding matches and producing a long list of potentially relevant applications and api calls . searching help documents or other trusted descriptive sources produces additional benefits . for example , help documents including an api call often indicate where the application logic implements the api call . consequently , exemplar may direct a developer to the location in application logic where an api call implements a high - level processing concept . the developer may then determine the relevance of the application logic and api call logic . in other words , the developer may determine whether the application logic and api call logic actually support the high - level processing concept . although specific components of exemplar and rae will be described , methods , systems , and articles of manufacture consistent with exemplar and / or the rae may include additional or different components . for example , a processor may be implemented as a microprocessor , microcontroller , application specific integrated circuit ( asic ), discrete logic , or a combination of other type of circuits or logic . similarly , memories may be dram , sram , flash or any other type of memory . logic that implements the processing and programs described below may be stored ( e . g ., as computer executable instructions ) on a computer readable medium such as an optical or magnetic disk or other memory . alternatively or additionally , the logic may be realized in an electromagnetic or optical signal that may be transmitted between entities . an example of such a signal is a physical layer ethernet signal bearing tcp / ip packets that include program source code or executable programs . flags , data , databases , tables , and other data structures may be separately stored and managed , may be incorporated into a single memory or database , may be distributed , or may be logically and physically organized in many different ways . programs may be parts of a single program , separate programs , or distributed across several memories and processors . furthermore , the programs , or any portion of the programs , may instead be implemented in hardware . fig1 illustrates the exemplar system environment 100 (“ exemplar environment ” 100 ) in communication with a recommended application evaluation system ( rae ) 128 . the exemplar environment 100 may include an exempla r prototyping and application development ( epad ) user interface 102 , a help content processor 104 , and help content 106 . the exemplar environment 100 also includes an api calls dictionary 108 , expanded search engine 110 , logic repository 112 , heuristic relevance ranking engine 114 , and a logic analyzer 116 . any or all of the elements shown in fig1 may be co - located or distributed and in communication over one or more networks 118 ( e . g ., the internet ). in one implementation , the epad user interface 102 , expanded search engine 110 , heuristic relevance ranking engine 114 and logic analyzer 116 form an exemplar system 124 within the exemplar environment 100 . the exemplar system 124 may include additional or different components . the exemplar system 124 may communicate with the help content processor 104 , help content 106 , api calls dictionary 108 , and logic repository 112 , as well as other systems , through the networks 118 ( e . g ., internet ) as external systems . the logic repository 112 may include application logic 120 and api call logic 122 . the exemplar system 124 accepts high - level processing concepts ( e . g ., “ send secure xml ”) as input and produces output identifying which application logic 120 and api call logic 122 developers may use to prototype and develop new applications implementing the high - level processing concepts . in one implementation , the exemplar environment 100 implements the help content 106 and the logic repository 112 with multiple storage devices ( e . g ., multiple databases on different disk drives ), and interfaces to help content 106 , application logic 120 and api call logic 122 from various available source ( e . g ., local or remote help databases , websites , knowledge exchanges , document repositories , or other sources ). in one implementation , the help content processor 104 may be implemented as a web crawler that traverses available application repositories , and downloads help content 106 ( e . g ., application descriptions ), and logic repository 112 content ( e . g ., application logic 120 , and api logic 122 ). the help content processor 104 may also perform full text indexing on the help content 106 and the logic repository 112 content . the help content processor 104 may further produce an api calls dictionary 108 that includes sets of tuples ( a form of ordered list ) that link selected words from the descriptions of the api calls to the names of the api calls . the description above used the examples of application logic 120 and api call logic 122 . these types of logic may be program source code ( e . g ., c or c ++ code ), for example . however , the exemplar environment 100 may search , analyze , and determine relevance for many other types of logic . as examples , the logic repository 112 may include programs or program components expressed in a visual programming language using graphical program elements and spatial arrangements of text and graphic symbols . the visual programming logic may include icon - based logic , form - based logic , diagram - based logic or other types of visual expression . the visual expression may be consistent with dataflow languages , flow - based programming , domain - specific modelling , or other programming paradigms . in one implementation , the exemplar environment 100 and the rae 128 are present in a rae environment 126 . the rae 128 includes a rae user interface generation logic 130 that comprises rae area logic 132 . the rae area logic 132 comprises concept query display logic 134 , concept distribution display logic 136 , source code display logic 138 and metadata display logic 140 . aspects of the rae 128 are discussed in further detail below . fig2 shows an exemplar data flow diagram 200 . exemplar system 124 accepts a high - level processing concept as input to create an original query 202 that exemplar system 124 may forward to the help content processor 104 . the help content processor 104 may produce a basis api call list 204 from the api calls dictionary 108 by matching the words in the high - level processing concepts ( e . g ., “ send secure xml ”) found in the original query 202 executed to search the help content 106 . the expanded search engine 110 may combine the original query 202 and the basis api call list 204 to form an expanded query 206 . the expanded search engine 110 may execute an expanded search using the expanded query 206 to search through the logic repository 112 to obtain an expanded search result 208 . in one implementation , the logic repository 112 may return the expanded search results 208 to the heuristic relevance ranking engine 114 . the expanded search result 208 may contain a list of potentially relevant applications 210 and potentially relevant api calls 212 that the heuristic relevance ranking engine 114 analyzes using the logic analyzer 116 . in one implementation , the heuristic relevance ranking engine 114 may include the logic analyzer 116 . the logic analyzer 116 may include a parser generator such as antlr (“ another tool for language recognition ”) available from www . antlr . org that provides support for generating data flow graphs and control flow graphs . the logic analyzer 116 may return connectivity rankings 214 , discussed in detail below , to further determine an application heuristic relevance ranking 216 and an api call heuristic relevance ranking 218 . the heuristic relevance ranking engine 114 may return the application heuristic relevance ranking 216 and an api call heuristic relevance ranking 218 to the epad user interface 102 . the expanded search engine 110 may also return a relevant applications list 220 and a relevant api calls list 222 to the epad user interface 102 . the exemplar system 124 may assign an application heuristic relevance ranking 216 to one or more relevant applications found in the relevant applications list 220 to indicate how closely each relevant application supports the high - level processing concept represented by the original query 202 . similarly , exemplar system 124 may assign an api call heuristic relevance ranking 218 to one or more relevant api calls found in the relevant api call list 222 to indicate how closely each relevant api call supports the high - level processing concept represented by the original query 202 . in one implementation , the rae area logic 132 obtains the connectivity rankings 214 , the application heuristic relevance rankings 216 , the api call heuristic relevance rankings 218 , the relevant applications list 220 , and the relevant api call list 222 . the rae area logic 132 may use the connectivity rankings 214 , the application heuristic relevance rankings 216 , the api call heuristic relevance rankings 218 , the relevant applications list 220 , and the relevant api call list 222 to present a recommended application evaluation area , discussed in detail below , to evaluate recommended applications obtained from exemplar 124 . fig3 illustrates an exemplar query interface 300 that may be used to input an original query 202 . the original query 202 may represent a high - level processing concept such as “ compress uncompress zip file ,” as shown in the text entry field 302 . several developers may have implemented the example high - level processing concept “ compress uncompress zip file ” 302 in different ways with various api calls described in the help content 106 , api calls dictionary 108 and logic repository 112 . a user may specify search refinement criteria 304 using interface elements such as a drop down box , menu or user input field . the search refinement criteria 304 may dictate the types of logic of interest ( e . g ., c , c ++, java , or other types of logic ), may dictate the information sources searched ( e . g ., search only compiled help files , or *. doc files ), or may specify other search criteria . the exemplar query interface 300 may include graphical user interface elements ( e . g ., the search button 306 ) used to execute the original query 202 . table 1 shows an example of an original query 202 in the form of a structured query language statement ( sql ) that represents the high - level processing concept “ compress uncompress zip file ” 302 . table 1 shows that the original query 202 will search the help content 106 ( e . g ., java help documents ) to identify a basis api calls list 204 . table 2 shows one example of the help content 106 represented by a fragment of java help documentation released by sun microsystems , inc . that describes the functionality of classes exported from the java . util package . the java . util package defines a number of classes , primarily collections classes that a developer may use when working with groups of objects . referring to table 2 , the help content processor 104 may identify partial matches for the class zipentry to the original query 202 . the help content processor 104 may search the help content 106 and identify a fragment of the help documentation for the zipentry class shown in table 3 . table 3 shows the descriptions of two different methods ( e . g ., getcompressedsize , and setmethod ) for the zipentry class that include the terms compress and uncompress found in the high - level processing concept “ compress uncompress zip file ” 302 . the basis api call list 204 may include the getcompressedsize and setmethod methods . table 4 shows an example of two equivalent forms of an expanded query 206 that expand the original search from the help content 106 ( e . g ., java help documents ) to the logic repository 112 using the basis api call list 204 from the original query 202 . table 4 statement a shows the getcompressedsize and setmethod that may be included in the basis api call list 204 . table 4 statement b shows the expanded query 206 as a nested query , where the original query 202 and the basis api call list 204 ( e . g ., getcompressedsize and setmethod ) drive the outer query that searches the logic repository 112 for potentially relevant applications 210 to obtain the expanded query result 208 including potentially relevant applications 210 and potentially relevant api calls 212 . the expanded query 206 may improve upon the original query 202 by targeting the search performed against the logic repository 112 to obtain application logic 120 with a high probability of including potentially relevant applications 210 and potentially relevant api calls 212 . table 5 shows another example of two equivalent forms of an expanded query 206 that expand the original search from the help content 106 ( e . g ., java help documents ) to the logic repository 112 by combining the original query 202 and the basis api call list 204 to form the expanded query 206 . table 5 statement a shows the getcompressedsize and setmethod ( e . g ., the basis api call list 204 ) combined with the original query 202 . table 5 statement b shows the expanded query 206 as a nested query , where the original query 202 and the basis api call list 204 ( e . g ., getcompressedsize and setmethod ) drive the outer query that searches the logic repository 112 for potentially relevant applications 210 to obtain the expanded query result 208 including potentially relevant applications 210 and potentially relevant api calls 212 . the expanded query 206 may improve upon the original query 202 by targeting the search performed against the logic repository 112 to obtain application logic 120 with a high probability of including potentially relevant applications 210 and potentially relevant api calls 212 . table 6 shows an example of a fragment of logic extracted from the logic repository 112 ( e . g ., potentially relevant application 210 ) that includes a potentially relevant api call 212 ( e . g ., getcompressedsize ). fig4 shows an exemplar system 124 prototyping and application development ( epad ) project area 400 . the epad project area 400 may include a relevant application list display area 402 , relevant api list display area 404 , heuristic relevance ranking results display area 406 , logic display area 408 , and application creation display area 410 . the relevant application list display area 402 may include the relevant application list 220 produced by the exemplar system 124 based on the expanded query 206 search results . the relevant applications list 220 may include a relevant application identifier - 1 412 ( e . g ., a program name , repository identifier , file name , or other program specifier ) of relevant application logic 414 . a user may select any identifier , as indicated by the arrow 416 , to display the relevant application logic 414 ( e . g ., source code for the program ) in the logic display area 408 . the epad user interface 102 may include a keyboard , mouse , a microphone ( or other sensors ), joystick , game pad , or the like for the user to interact with the epad project area 400 . the relevant api list display area 404 may include the relevant api call list 222 returned by exemplar system 124 based on the original query 202 . the relevant api call list 222 may include a relevant api call identifier - 1 418 ( e . g ., a function call name ) and a relevant api call identifier - 2 420 of the relevant api call logic - 1 422 ( e . g ., source code for the function call ) and relevant api call logic - 2 424 , respectively . the epad project area 400 may present the relevant api call identifier - 1 418 and the relevant api call identifier - 2 420 as user selectable , indicated by the arrow 426 , to display and highlight the relevant api call logic - 1 422 and the relevant api call logic - 2 424 in the logic display area 408 . in one implementation , the logic display area 408 may highlight the relevant application logic 414 , and relevant api call logic - 1 422 and relevant api call logic - 2 424 so that the user can further determine the relevance of the logic to the high - level processing concept represented in the original query 202 . the heuristic relevance ranking results display area 406 , shown in fig4 , may include an application relevance threshold 428 , an api call relevance threshold 430 , data flow graph 432 , control flow graph 433 , and an api call graph 434 . the heuristic relevance ranking results display area 406 may display heuristic relevance ranking engine 114 information to assist the user to determine the relevance of user selected logic . as will be described in more detail below , the heuristic relevance ranking engine 114 may determine the application heuristic relevance ranking 216 for the relevant application logic 414 based on the number of relevant api calls ( e . g ., relevant api call logic - 1 422 and relevant api call logic - 2 424 ) found in the relevant application logic 414 in comparison to other relevant application logic 436 identified by exemplar system 124 . for example , the high - level processing concept example “ compress uncompress zip file ” 302 may be entirely implemented in relevant application logic 414 , but only partially implemented in the other relevant application logic 436 . as a result , the heuristic relevance ranking engine 114 may assign the relevant application logic 414 a higher application heuristic relevance ranking 216 than the other relevant application logic 436 . in another implementation , the heuristic relevance ranking engine 114 may determine the api call heuristic relevance rankings 218 of the relevant api call logic - 1 422 and the relevant api call logic - 2 424 , based on analyzing semantics derived from the expanded query 206 and the expanded search result 208 , which establish the behaviour of the relevant api call logic - 1 422 , the relevant api call logic - 2 424 , and the relevant applications logic - 1 414 . the application relevance threshold 428 and api call relevance threshold 430 , shown in fig4 , may be user selectable and / or pre - configured with system default values . in another implementation , exemplar system 124 may determine the application relevance threshold 428 and the relevance threshold 430 based a number of factors ( e . g ., the complexity of the high - level processing concept represented by the original query 202 , and the number of potentially relevant applications 210 and potentially relevant api calls 212 identified by the expanded search result 208 ). exemplar system 124 may use the application relevance threshold 428 and the relevance threshold 430 to further refine the relevant applications list 220 and the relevant api calls list 222 , respectively . in one implementation , the application relevance threshold 428 and the relevance threshold 428 may determine an application heuristic relevance ranking 216 value that the potentially relevant applications 210 must meet to be included on the relevant applications list 220 . the api call relevance threshold 430 may also determine the api call heuristic relevance ranking 218 value that the potentially relevant api calls 212 must meet to be included on the relevant api calls list 222 . for example , an application relevance threshold 428 of 1 may indicate a low relevance requirement ( e . g ., requiring loosely relevant applications , and low application heuristic relevance rankings 216 ) and allow a large number of potentially relevant applications 210 to qualify as relevant applications ( e . g ., relevant application logic - 1 414 ). in another example , an application relevance threshold 428 of 10 may indicate a high relevance requirement ( e . g ., requiring highly relevant applications , and high application heuristic relevance rankings 216 ) and allow only a fewer number of potentially relevant applications 210 to qualify as relevant applications . the heuristic relevance ranking engine 114 may also use the data flow graph 432 and control flow graph 433 to determine the application heuristic relevance ranking 216 and api call heuristic relevance ranking 218 , and visually describe the relationships between the relevant application logic 414 , the relevant api call logic - 1 422 , and the relevant api call logic - 2 424 , discussed in further detail below . the relevant api call logic - 1 422 and the relevant api call logic - 2 424 may be user selectable ( indicated by the arrow 442 ), and provide the user the ability to generate a new application 440 with the selected logic . to that end , the epad project area 400 may implement point - and - click , drag - and - drop functionality for a user to select relevant api call logic - 1 422 and relevant api call logic - 2 424 to generate the new application 440 . the epad project area 400 may also build the new application 440 by combining user selectable other relevant application logic 436 , relevant api call logic - 1 , and relevant api call logic - 2 . the application creation display area 410 may also identify requirements 444 for the high - level processing concept represented by the original query 202 . for example , a developer may desire to identify and confirm the requirements 444 for implementing a high - level processing concept ( e . g ., “ send secure xml ”). in one implementation , exemplar may generate requirements documentation and end user documentation based on the help content 106 related to the other relevant application logic 436 , the relevant api call logic - 1 , and the relevant api call logic - 2 used to build the new application 440 , and identify the requirements 444 in support of the new application 440 . fig5 shows a more detailed view of the exemplar system 124 . the exemplar system 124 may include a communications interface 504 used to communicate with various resources internal and external to exemplar system 124 , memory 506 , and a processor 508 . the processor 508 may execute any of the logic described below . the memory 506 may include the epad user interface 102 that employs the interface logic 510 to generate the exemplar query interface 300 , and the epad project area 400 . the interface logic 510 may include graphics libraries , window rendering calls , and other user interface logic operable to display interface elements , receive input , and pass the input to any particular program logic in the exemplar system 124 . the memory 506 may also include expanded search logic 514 . table 5 , above , shows an expanded query 206 where the search logic 514 forms the expanded query by combining the original query 202 and the basis api call list 204 to form the expanded query 206 . more generally , the expanded search logic 514 combines the original query 202 and the basis logic results 516 to form the expanded query 206 , and executes an expanded search using the expanded query 206 . the basis logic results 516 may include the basis api call list 204 , including zero or more basis api call identifiers ( e . g ., the basis api call identifier - 1 518 ), and a basis application list 520 , including zero or more basis application identifiers ( e . g ., the basis application identifier - 1 521 ). the expanded search logic 514 thereby obtains the expanded search results 208 . the expanded search result 208 may include potentially relevant applications 210 , and potentially relevant api calls 212 that include zero or more potentially relevant application identifiers - 1 522 and zero or more potentially relevant api call identifiers ( e . g ., potentially relevant api call identifier - 1 524 and potentially relevant api call identifier - 2 526 ). fig6 shows other features of the exemplar system 124 . the memory 506 may also include the heuristic relevance ranking engine 114 with the heuristic relevance ranking logic 602 that generates the application heuristic relevance ranking 216 and api call heuristic relevance ranking 218 . the threshold logic 604 may apply the application relevance threshold 428 and api call relevance threshold 430 to the application heuristic relevance rankings 216 and api call heuristic relevance rankings 218 to determine whether potentially relevant applications 210 and potentially relevant api calls 212 qualify for inclusion in the relevant applications list 220 and the relevant api calls list 222 . in other words , the threshold logic 604 may implement comparison logic to determine when potentially relevant logic qualifies as relevant logic . the memory 506 may also include analyzer logic 606 that the processor 508 executes to identify application metadata 608 and api metadata 610 of the potentially relevant applications 210 , and the potentially relevant api calls 212 , respectively . examples of application metadata 608 include application descriptions , application logic comments , application parameter names , and application parameter types of existing applications . similarly , examples of api metadata 610 include api descriptions , api logic comments , api parameter names , and api parameter types . the analyzer logic 606 may generate the data flow graph 432 and control flow graph 433 to obtain the api call graph 434 . the api call graph 434 may include nodes ( e . g ., node - 1 612 and node - 2 614 ) that represent potentially relevant api calls 212 and data flow edges ( e . g ., data flow edge 616 ) between the potentially relevant api calls 212 to indicate data flow . fig7 provides additional examples . the analyzer logic 606 may determine the data flow edge count 618 corresponding to the number of connections between potentially relevant api calls 212 within the potentially relevant application 210 . a graph with ‘ n ’ nodes has as many as n ( n − 1 ) edges between nodes . the data flow edge count 618 provides insight into the degree of connectedness for the data flow graph 432 . the analyzer logic 606 may also assign link values 620 to the edges between nodes , discussed in detail below . in one implementation , the analyzer logic 606 may determine the connectivity rankings 214 ( e . g ., strong connectivity ranking 622 and weak connectivity ranking 624 ) for each connection between the potentially relevant api calls 212 based on common api parameters 626 , discussed in detail below . fig6 further illustrates that memory 506 may include selection logic 628 and application creation logic 630 . the processor 508 may execute the selection logic 628 to allow a user to select relevant application logic 414 , and relevant api call logic ( e . g ., the relevant api call logic - 1 422 and the relevant api call logic - 2 424 ) to develop the new application 440 . in another implementation , selection logic 628 may provide a user drag - and - drop point - and - click functionality to select other relevant application logic 436 to combine with the relevant api call logic - 1 422 , and the relevant api call logic - 2 424 to build the new application 440 . the processor 508 may execute the application creation logic 630 to identify requirements 444 for the high - level processing concept represented by the original query 202 by identifying the help content 106 used to obtain the basis logic results 516 corresponding to the user selected other relevant application logic 436 , relevant application logic 414 , relevant api call logic - 1 422 , and relevant api call logic - 2 424 . in one implementation , the application creation logic may form a query using the other relevant application logic 436 , relevant application logic 414 , relevant api call logic - 1 422 , and relevant api call logic - 2 424 to obtain the help content 106 that describes the requirements 444 . the application creation logic 630 may generate customized requirements documents from the help content 106 corresponding to the user selected other relevant application logic 436 , relevant application logic 414 , relevant api call logic - 1 422 , and relevant api call logic - 2 424 . fig7 shows api call graphs 434 for two different potentially relevant applications ( e . g ., a potentially relevant application a and potentially relevant application b ). the heuristic relevance ranking engine 114 may assign a higher heuristic relevance ranking 216 to the potentially relevant application a than the potentially relevant application b based on the number of potentially relevant api calls 212 , the connectivity rankings 214 and link values 620 assigned to each connection between potentially relevant api calls 212 included in the potentially relevant application a and potentially relevant application b , respectively . in one implementation , the logic analyzer 116 produces the api call graphs 434 . the logic analyzer 116 may identify the application metadata 608 and api metadata 610 of the potentially relevant applications 210 , and the potentially relevant api calls 212 , respectively , to analyze the data flow paths and connectivity between the potentially relevant api calls 212 . the logic analyzer 116 may provide the application metadata 608 and api metadata 610 to the heuristic relevance ranking engine 114 . in an alternative implementation , the heuristic relevance ranking engine 114 may identify application metadata 608 and api metadata 610 , and produce the data flow graph 432 and control flow graph 433 using logic analysis formulas , rules and equations to obtain the api call graphs 434 . the data flow graphs 432 , control flow graphs 433 and api call graphs 434 may be represented as mathematical structures . the logic analyzer 116 may obtain the api call graphs 434 as a result of comparing data flow and control flow between potentially relevant api calls 212 . in one implementation , the logic analyzer 116 may perform control flow analysis on the potentially relevant application 210 to obtain control flow graphs 433 , and perform data flow analysis on the control flow graphs 433 to obtain data flow graphs . the data flow graphs 432 , control flow graphs 433 , and api call graphs may similarly include nodes and edges . the logic analyzer 116 may obtain a control flow graph 433 by logically partitioning a potentially relevant application 210 as a result of parsing the logic of the potentially relevant application 210 into nodes that represent logic that includes api calls . the logic analyzer 116 may assign parsed logic of the potentially relevant application 210 to an assigned node until the logic analyzer 116 identifies a potentially relevant api call or branching logic ( e . g ., if - then , switch - case , and do - while ), and add the assigned node to the control flow graph 433 . where a program includes multiple potentially relevant applications 210 , the logic analyzer 116 may merge the control flow graphs 433 produced for each potentially relevant application into a single control flow graph 433 . the logic analyzer 116 may obtain the api call graph 434 by comparing the edges in the control flow graphs 433 with the edges in the data flow graph 432 . for example , where a control flow graph 433 includes an edge that a data flow graph 432 does not include , the logic analyzer 116 may not include the edge in the corresponding api call graph 434 . however , where a control flow graph 433 includes an edge that the data flow graph 432 also includes , the logic analyzer 116 may include the edge in the api call graph 434 . in one implementation , the logic analyzer 116 may receive user input to determine particular dependencies between api calls . for example , where a potentially relevant application 210 uses a function pointer ( e . g ., a type of pointer used in c , and c ++ languages ) to reference a potentially relevant api call 212 and a hash table ( e . g ., a data structure that associates keys with values ) to store an object that represents a data element passed between api calls , the logic analyzer 116 may receive user input to determine dependencies between api calls because the logic analyzer 116 may otherwise interpret multiple possible dependencies between api calls when in fact only one or a finite set of valid dependencies exists . in another implementation , the logic analyzer 116 may analyze the data flow paths ( e . g ., edges between nodes discussed below ) ( e . g ., link heuristics ) of the potentially relevant applications 210 , and potentially relevant api call logic 212 to determine the connectivity rankings 214 of each connection between potentially relevant api calls 212 . in one implementation , the heuristic relevance ranking engine 114 may determine the application heuristic relevance ranking 216 for the potentially relevant application 210 , shown in fig7 as potentially relevant application a , based on the total number of api calls ‘ n ’ represented by nodes 712 - 720 that represent different potentially relevant api calls 212 found in the potentially relevant application 210 , the total number of connections between the potentially relevant api calls 212 ( e . g ., edges 712 - 720 ) equal to n ( n − 1 ) ( e . g ., data flow edge count 614 ), the quality of the connections ( e . g ., strong connectivity or weak connectivity ), and the type of link ( e . g ., loop link , single link , or no link ) between the potentially relevant api calls 212 . the applications metadata 608 and api metadata 610 may describe the data flow paths between the different potentially relevant api calls 212 ( e . g ., nodes 702 - 710 ) within the potentially relevant application 210 . for example , the logic analyzer 116 may determine common api parameters 626 and logic branches ( e . g ., if - then - else ) found within the potentially relevant application 210 and potentially relevant api calls 212 to generate the data flow graphs 432 , control flow graphs 433 and api call graphs 434 . the logic analyzer 116 may , as fig7 also illustrates , identify the function ( e . g ., k ( x ), j ( x ), s ( y ), p ( y ), f ( x ), and g ( z )) of each potentially relevant api call 212 ( e . g ., 702 - 710 , and 722 ) to determine the connectivity rankings 214 . in one implementation , the logic analyzer 116 may assign a weight w i ( e . g ., connectivity ranking 214 ) to each connection between the potentially relevant api calls 212 ( e . g ., nodes 712 - 720 ). the logic analyzer 116 may assign weak connections a weight of 0 . 5 and strong connections a weight of 1 . 0 depending on multiple factors . for example , edge 712 , edge 716 and edge 720 may represent weak connections between potentially relevant api calls 212 represented by node pairs 702 and 710 , 702 and 704 , and 706 and 708 ( e . g ., function pairs k ( x ) and f ( x ), k ( x ) and j ( x ), and s ( y ) and p ( y ), respectively ). following the above example , where functions k ( x ) and f ( x ) share a common api parameter 626 , but neither function generates the value of the common api parameter 626 then the logic analyzer 116 may assign the connectivity ranking 214 between node pair 702 and 710 , represented by edge 720 , a weak connection weight of 0 . 5 . a weak connection assigned to a node pair ( e . g ., 702 and 710 ) may indicate a low relative probability ( e . g ., in comparison to the connectivity rankings of other node pairs ) that the node pair implements the high - level processing concept represented by the original query 202 . the logic analyzer 116 may use other heuristic analysis methods and tools to determine whether to assign a weak connection to a connectivity ranking 214 . alternatively , edge 714 , and edge 718 may represent strong connections between potentially relevant api calls 212 , represented by node pairs 702 and 708 , and 704 and 706 ( e . g ., function pairs k ( x ) and p ( y ), and j ( x ) and s ( y ), respectively ). the logic analyzer 116 may determine that where function j ( x ) produces variable y , which both j ( x ) and s ( y ) share then the node pair 704 and 706 , represented by edge 714 , may be assigned a strong connectivity ranking 622 . a strong connection assigned to a node pair ( e . g ., 704 and 706 ) may indicate a high relative probability ( e . g ., in comparison to the connectivity rankings of other node pairs ) that the node pair implements the high - level processing concept represented by the original query 202 . the logic analyzer 116 may use other heuristic analysis methods and tools to determine whether to assign a strong connection to a connectivity ranking 214 . the logic analyzer 116 may also assign a link value l ( e . g . link value 620 ) to each connection between potentially relevant api calls 212 . for example , exemplar system 124 may assign a link value l equal to 1 where a loop link ( e . g ., edges 712 - 718 form a loop ) exists between potentially relevant api calls 212 ( e . g ., nodes 702 - 708 ). exemplar system 124 may assign a link value l equal to 0 . 5 where a single link ( e . g ., edge 720 ) exists between potentially relevant api calls 212 ( e . g ., nodes 702 - 708 ). in another implementation , exemplar system 124 may assign a link value l equal to 0 where no link exists between potentially relevant api calls 212 ( e . g ., node 722 represents a potentially relevant api call 212 that does not have a connection with other potentially relevant api calls in a potentially relevant application 210 ). additional , different , or fewer weights may be used . the heuristic relevance ranking engine 114 may use the connectivity rankings 214 and link values 620 assigned to each connection between potentially relevant api calls 212 to determine the application heuristic relevance ranking 216 according to : the logic analyzer 116 may determine an api call heuristic relevance ranking 218 for a potentially relevant api call 212 based on the connectivity ranking 214 and link value 620 assigned to each edge that includes the potentially relevant api call 212 . for example , where m represents the number of node pair including a particular node ( e . g ., 702 and 704 , 702 and 708 , and 702 and 710 ) and the number of edges ( e . g ., 712 , 718 and 720 ) that include the node equals m ( m − 1 ), and the assigned value for each connectivity ranking 214 and link value 620 for each edge that includes the node represent w and l , respectively , the api call heuristic relevance ranking 218 for the node may be determined according to equation 1 above where m substitutes for n : fig8 shows the acts that the exemplar system 124 may take to obtain a relevant application list 210 . the exemplar system 124 may use the interface logic 510 to receive an original query 202 representing a high - level processing concept ( e . g ., “ send secure xml ”) ( 802 ). the help content processor 104 may execute an original search using the original query 202 ( 804 ) to obtain an original search result that includes basis logic results 516 ( e . g ., basis api call list 204 or basis application list 520 ). the basis logic results 516 may include a basis logic ( e . g ., api call ) identifier ( 806 ). the exemplar system 124 may combine the original query 202 with any part of the basis logic list to form an expanded query ( 808 ). the expanded search logic 514 may execute the expanded query 206 to obtain an expanded search result 208 that includes a potentially relevant applications 210 list and potentially relevant api calls 212 list ( 810 ). the potentially relevant logic list may identify potentially relevant logic . the analyzer logic 606 may analyze the potentially relevant logic identified by the potentially relevant application identifiers with respect to the logic repository 112 ( 812 ). the heuristic relevance ranking logic 602 may use the connectivity rankings 214 , and link values 620 to determine the application heuristic relevance rankings 216 and api call heuristic relevance rankings 218 for the potentially relevant applications 210 and potentially relevant api calls 212 using equation 1 or another formulation ( 814 ). the heuristic relevance ranking logic 602 may apply the application relevance threshold 428 and the api call relevance threshold 430 using the threshold logic 604 to determine whether the potentially relevant applications 210 and the potentially relevant api calls meet the application relevance threshold 428 , and api call relevance threshold 430 , respectively ( 816 ). the heuristic relevance ranking logic 602 may add the potentially relevant application 210 to the relevant application list 220 where the potentially relevant application 210 meets the application relevance threshold 428 ( 818 ). the heuristic relevance ranking logic 602 may determine the application heuristic relevance ranking 216 and api call heuristic relevance ranking 218 for each potentially relevant application 210 and potentially relevant api call 212 included the expanded search result 208 ( 820 ). fig9 shows the acts that the exemplar system 124 heuristic ranking engine 114 may take to assign an application heuristic relevance ranking 216 to a potentially relevant application 210 . the analyzer logic 602 may analyze the potentially relevant application 210 and potentially relevant api calls 212 found in the logic repository ( 904 ). the analyzer logic 602 may generate and analyze a data flow graph 432 and control flow graph 433 ( 906 ) used to generate and analyze an api call graph 43 ( 908 ). the analyzer logic 602 may use the data flow graph 432 , control flow graph 433 , and api call graph to determine the link values 650 for the potentially relevant api calls included in a potentially relevant application 210 and assign a connectivity ranking 214 to each connection between potentially relevant api calls 212 ( 910 ). the heuristic relevance ranking logic 602 may determine an application heuristic relevance ranking 216 for each of the potentially relevant applications 210 ( 912 ) ( e . g ., the application heuristic relevance ranking 216 and an api call heuristic relevance ranking 218 may be determined according to equation 1 , as discussed above ). the heuristic relevance ranking logic 602 may determine the application heuristic relevance ranking 216 and api call heuristic relevance ranking 218 for each potentially relevant application 210 and potentially relevant api call 212 included the expanded search result 208 ( 914 ). fig1 shows the processing that the selection logic and application creation logic may take to generate a new application 440 . epad project area 400 may use the selection logic 624 to detect selection of a relevant api call identifier ( e . g ., as indicated by arrows 426 drawn from the relevant api call identifier - 1 418 and the relevant api call identifier - 2 420 to the relevant api call logic - 1 422 and the relevant api call logic - 2 424 ) from the relevant api call list 222 ( 1002 ). the epad project area 400 may present the relevant api call logic ( e . g ., the relevant api call logic - 1 422 and the relevant api call logic - 2 424 ) that implements the relevant api calls ( 1004 ). the epad project area may use the selection logic 624 to detect selection of the relevant api call logic ( e . g ., the relevant api call logic - 1 422 and the relevant api call logic - 2 424 ) and the other relevant application logic 436 to generate a new application 440 ( 1006 ). the epad project area may provide an option to generate the new application 440 , using the application creation logic 626 , following selection of the relevant api call logic ( e . g ., the relevant api call logic - 1 422 and the relevant api call logic - 2 424 ) and the other relevant application logic 436 to generate a new application 440 ( 1008 ). exemplar system 124 may also identify requirements 444 for the high - level processing concept represented by the original query 202 . in one implementation , exemplar system 124 may generate requirements documentation and end user documentation based on the help content 106 related to the other relevant application logic 436 , the relevant api call logic - 1 422 , and the relevant api call logic - 2 424 combined to generate the new application 440 and identify the requirements 444 . fig1 shows a recommended application evaluation system ( rae ) 128 . in one implementation , the rae 128 includes a communications interface 1102 in communication with the network 118 and used to communicate with various resources internal and external to the rae 128 , a memory 1104 , and a processor 1106 . the processor 1106 may execute any of the logic of the rae 128 and / or exemplar 124 . the memory 1106 may include the rae user interface generation logic 130 that generates a rae user interface 1202 , as shown in fig1 , and employs the rae area logic 132 . the rae area logic 132 may include graphics libraries , window rendering calls , and other user interface logic operable to display interface elements , receive input , and pass the input to any particular program logic in the rae 128 . the rae area logic 132 may further include the concept query display logic 134 , the concept distribution display logic 136 , the source code display logic 138 and the metadata display logic 140 . the concept query display logic 134 may include topics 1108 , words 1110 , and concepts 1112 of the original query 202 and / or the expanded query 206 . the concept query display logic 134 accepts the topics 1108 , words 1110 , concepts 1112 , the original query 202 and the expanded query 206 from exemplar , and generates a window in the rae user interface 1202 ( as described in more detail in connection with fig1 ) that presents the topics as selectable focus items for verifying recommended application functionality . the concept distribution display logic 136 may include recommended application representations 1116 of the recommended applications 1118 ( e . g ., hras ). in one implementation , the recommended applications 1118 include the relevant application logic 414 and relevant api call logic ( e . g ., 422 and 424 ) obtained from exemplar based on the original query 202 and / or the expanded query 206 . the recommended application representations 1116 include concept distribution locators 1120 that identify potential implementation locations of one of the topics , concepts and words . exemplar identifies the location ( e . g ., concept distribution locators ) in application logic where an api call implements a high - level processing concept . the concept distribution display logic 136 generates a visualization of a recommended application . the concept distribution display logic 136 may , for example , generate a concept distribution display region 1206 that shows one or more of the modules , source code files , header files , library files , or other recommended application source files . the concept distribution display logic 136 further locates within the recommended application source files the api calls that implement the topics 1108 , words 1110 , concepts 1112 , the original query 202 and the expanded query 206 , selected by an operator . the concept distribution display logic 136 may denote each location with a concept distribution locator 1120 , such as a solid horizontal line with hyperlink functionality through the recommended application source file at the location where the api call exists in the source file . other concept distribution locators 1120 may be used such as geometric shapes ( e . g ., circles , squares ) and ( e . g ., fonts , graphics ( e . g ., lines or pointers ), color and / or sound ). the concept distribution display logic 136 is operable to receive concept distribution locator selections 1122 . the concept distribution display logic 136 may convey the concept distribution locator selection 1122 to the source code display logic 138 . as described in more detail below , the source code display logic 138 generates a source code display region on the user interface which displays the actual code at the selection point . as a result , an operator may evaluate the code to determine whether the code actually implements the search terms selected from the concept query display region . the source code display logic 138 may include source code portions 1124 of a recommended application 1118 . the source code portions 1124 may include the potential implementation location of source code ( e . g ., highlighted concepts 1126 ) for a selected concept distribution locator 1122 . the source code display logic 138 accepts a concept distribution location selection 1122 from the concept distribution display logic 136 . in response , the source code display logic 138 retrieves the recommended application code at the selection point and presents the source code for review in the source code display region . furthermore , the concept distribution display logic 136 highlights source code components in the display such as api calls in the source code that match the concepts selected from the concept query display region . accordingly , an operator may review the source code to determine whether the source code actually does implement the concepts selected from the concept query display region . the source code display logic 138 may include read - only and edit modes that allow the source code display logic 138 to be responsive to source code edits 1128 entered by a developer in the course of evaluating the recommended application 1118 . the metadata display logic 140 may include application metadata 608 and api metadata 610 for the recommended applications 1118 based on the topics 1108 , words 1110 , concepts 1112 , the original query 202 and the expanded query 206 . the metadata display logic 140 may also include concept query statistics 1130 and semantics information 1132 based on the topics 1108 , words 1110 , concepts 1112 , the original query 202 , the expanded query 206 and / or recommended applications 1118 . in one implementation , concept query statistics 1130 and semantics information 1132 are determined by the heuristic relevance ranking engine 114 as a product of determining the api call heuristic relevance rankings 218 of the relevant api call logic - 1 422 and the relevant api call logic - 2 424 , based on analyzing semantics derived from the expanded query 206 and the expanded search result 208 . fig1 shows a recommended application evaluation area 1202 that the rae area logic 132 may be operable to display . the rae area 1202 may include a concept query display region 1204 , a concept distribution display region 1206 , source code display region 1214 and metadata display region 1210 . the concept query display region 1204 displays the topics 1108 , words 1110 , concepts 1112 of the original query 202 and / or the expanded query 206 alone or in combination . the concept query display region 1204 may further include check boxes and / or other selection gui elements so that an operator may select the topics 1108 , words 1110 , and concepts 1112 from the concept query display region 1204 . the concept distribution display region 1206 displays the recommended application representations ( rar ) 1212 and 1214 of a recommended application 1118 . for example , the rar 1212 may represent the source code file that includes the main ( ) function , while the rar 1214 may represent the source code file with an alleged jpeg to bitmap conversion routine . the recommended application representations 1212 and 1214 include concept distribution locators 1216 , 1218 , 1220 , 1222 , 1224 , and 1226 inserted by the concept distribution display logic 136 that identify potential implementation locations in the source code files of the topics 1108 , words 1110 , concepts 1112 , the original query 202 and the expanded query 206 alone or in combination . the concept distribution locators 1216 , 1218 , 1220 , 1222 , 1224 , and 1226 may employ different identifiers ( e . g ., fonts , graphics ( e . g ., lines or pointers ), color and / or sound ) to identify a relationship between the concept distribution locators and the topics 1108 , words 1110 , concepts 1112 of the original query 202 and the expanded query 206 . the source code display region 1208 includes highlighted concepts 1126 ( e . g ., 1228 and 1230 ). in one implementation , the highlighted concepts 1126 ( e . g ., 1228 and 1230 ) include identifiers ( e . g ., fonts , color and / or sound ) to indentify a relationship between the highlighted concepts 1126 and the concept distribution locators ( e . g ., 1216 , 1218 , 1220 , 1222 , 1224 , and 1226 ). the rae area logic 132 may use fonts , color and / or sound ( e . g ., audio queues ) to indicate relationships between the topics 1108 , words 1110 , concepts 1112 , concept distribution locators ( e . g ., 1216 , 1218 , 1220 , 1222 , 1224 , and 1226 ) and highlighted concepts 1126 , as indicated by the arrows 1232 and 1234 . in one implementation , the recommended application representations ( 1116 , 1212 and 1214 ) and / or the concept distribution locators ( e . g ., 1216 , 1218 , 1220 , 1222 , 1224 , and 1226 ) are displayed in response to the selection of a particular topic 1108 , word 1110 , concept 1112 , and / or element of the original query 202 and / or the expanded query 206 . in other words , the recommended application representations ( 1116 , 1212 and 1214 ) and / or the concept distribution locators ( e . g ., 1216 , 1218 , 1220 , 1222 , 1224 , and 1226 ) displayed in the concept distribution display region 1206 may be responsive to selections made in the concept query display region 1204 . fig1 shows an example of the recommended application evaluation area 1202 as shown on a display . the recommended application evaluation area 1202 includes the concept query display region 1204 , concept distribution display region 1206 , a recommended application representation 1214 , and a metadata display region 1210 . the concept query display region 1204 provides term selection elements 1302 that an operator may select to chose the concepts of interest for verification in the recommended applications . the concept distribution display region 1206 shows the location of api calls and other source code components that implement the selected terms . in the example shown in fig1 , the locations are indicated using concept distribution locators : dashed lines ( e . g ., 1304 ) proportionally positioned within graphical representations of the source code files that make up a recommended application . these source code files are labelled recommended application code ( rac ) file 1 ( rac 1 ), rac 2 , rac 3 , rac 4 , and rac 5 in fig1 . the recommended application representation 1214 shows the source code at a specific concept location in a specific source code file , as selected by an operator . thus , when an operator selects , for example , rac 1 , and the concept distribution locator 1304 , the concept distribution display logic 136 responds by retrieving the rac 1 source code at and around the concept location . the concept distribution display logic 136 displays the retrieved code in the recommended application representation 1214 area . furthermore , the concept distribution display logic highlights the sections of code that exemplar &# 39 ; s search techniques determined relate to the search terms shown in the concept query display region 1204 . as shown in fig1 , for example , the concept distribution display logic 136 has highlighted ( using underlining ) the source code components 1306 “ new ” and “. set ” as relevant to the selected search terms “ length ” and “ create ” in the concept query display region 1204 . fig1 shows the processing that the rae area logic 132 may take to evaluate a recommended application . the rae area logic 132 obtains recommended applications for evaluation ( 1402 ). in one implementation , the rae area logic 132 obtains the recommended applications for evaluation from exemplar 124 , where the recommended applications 1118 are hras . the concept query display logic 134 displays the topics , concepts and words of the original query 202 and / or the expanded query 206 executed to identify the recommended applications ( 1404 ). the concept query display logic 134 displays the topics , concepts and words in a concept query display area . the concept distribution display logic 136 displays representations of the recommended applications 1118 , including concept distribution locators 1120 in the concept distribution display region 1206 ( 1406 ). the concept distribution locators 1120 identify potential implementation locations of the topics , concepts and words of the query executed to identify the recommended applications 1118 . when a concept distribution locator 1120 is selected from the concept distribution display region 1206 ( 1408 ) the source code display logic 138 displays a portion of the source code 1124 of the recommended application identified by the concept distribution locator 1120 ( 1410 ) in the source code display region . the metadata display logic 140 displays the metadata generated upon the execution of the query executed to identify the recommended applications ( 1412 ). a developer may use the rae 128 to evaluate the recommended application and portion of source code to validate that the recommended application is a highly relevant application ( 1414 ). the developer may select another recommended application to evaluate ( 1416 ) by selecting another concept distribution locator from the concept distribution display area . the rae 128 greatly reduces the time , cost , and other resource expenditures associated with evaluating a recommended application . the rae 128 produces relevant results starting with high - level processing concepts . a software developer may deploy the highly relevant application into production upon successful evaluation . furthermore , it is noted that the system carries out electronic transformation of data that may represent underlying physical objects . for example , the rae area logic visually transforms source code by adding search term locators and highlighting of relevant code that matches search terms . in addition , the rae may be implemented as a particular machine . for example , the particular machine may include a cpu , memory , and a software library for carrying out the rae area logic noted above . a number of implementations have been described . nevertheless , it will be understood that various modifications may be made without departing from the spirit and scope of the invention . accordingly , other implementations are within the scope of the following claims .