Changes between Version 9 and Version 10 of Dependency/Functions
- Timestamp:
- Apr 24, 2012, 1:29:18 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Dependency/Functions
v9 v10 7 7 We say that module ''A'' depends on module ''B'' (''A -> B'') if there is at least one function call from ''A'' to ''B''. There is a ''cyclic dependency'', if ''B'' also depends directly (''B -> A'') or indirectly (e.g. ''B -> C -> A'') on ''A''. 8 8 9 Apparently, dependency can be defined on the function level as well. For instance, in our previous example, function level cycle is only present if ''A:foo'' calls ''B:foo'' and ''B:foo'' calls ''A:foo''.9 Apparently, dependency can be defined on the function level as well. For instance, in our previous example, function level cycle is only present if both ''A'' and ''B'' define functions called ''foo'', such that ''A:foo'' calls ''B:foo'' and ''B:foo'' calls ''A:foo''. 10 10 11 11 Note that it is possible to have a cyclic dependency among modules while having no cyclic dependencies among their functions. For example, function calls from ''A:foo'' to ''B:foo'' and from ''B:foo2'' to ''A:foo2'' imply a cyclic dependency on the 12 12 module level, but no one on the function level. 13 13 14 == Possible Analysis ==14 == Capabilities == 15 15 16 There are different kind of examinations that can be run considering dependencies. \\ 16 Mainly, you can ''check for cycles'' among entities within the !RefactorErl database. This means 17 that the program looks for loops on the given level, and returns with paths of cycles. 17 18 18 First of all, the possibility of ''checking for cycles'' on RefactorErl database. This means 19 that the program is going to look for loops on the given level, and returns with the path of the cycles. \\ 19 In case of vast databases, dependencies can be very complex, and hard to represent. To avoid producing useless, huge dependency graphs, we provide some options that you can use for narrowing down the result. For instance, you can reduce the graph to only contain the cycles, or you can exclude the standard OTP modules from the result. Also, you can ask to only cover dependencies starting from given function(s) or module(s). 20 20 21 If one wants to have a more visual view of the dependencies, there is the ''draw'' option. This will generate a ''.dot'' file, which latter can be converted to a desired image file format. The following picture will show us an example on function level: 21 === Visualisation 22 22 23 [[Image(dep_fun_before.png, 700px)]] 23 If you would like to visualise the result, you can put it into a graph. Namely, we generate a ''.dot'' graph description file, which can be converted to any desired image format. On function level, for example, the graph shows the modules and their functions along with the calls between the functions, while red edges represent cycles. 24 24 25 This illustration shows the functions with their modules and the function calls made from one function to 26 another. With red edges, it is easy to spot the cycles. Using tooltips more information can be gained. Everything related to the representation is explained later, in the wiki:Dependency/Functions#Representation section. 27 28 29 Since in the case of a vast database, the generated picture of dependencies can be very complex and hard to figure out, there are different options how the user can narrow down the result, and get a more easier understandable view. For instance, it is possible just to receive an image of the graph which contains only the cycles, or to exclude the OTP modules from the result. \\ 30 In every dependency option there is the opportunity to run the examination from a given function/module or a list of them. 31 32 \\ 25 == Usage 33 26 34 27 Dependency analysis can be done via the following interfaces: … … 37 30 38 31 39 == Representation==32 == Semantics of dependency graphs == 40 33 41 34 === Function Level === 42 Let's take an example to explain the meaning of the representation of 43 dependency graphs, and work with the example shown in the beginning of the page. 44 A 45 {{{#!erlang 46 ri:draw_dep([{level, func}, {type, all}]) 47 }}} 48 call was made, which generated a ''Graphviz dot file''. \\ 35 36 Function dependency graphs look like the following. 49 37 50 38 [[Image(dep_fun_before.png, 700px)]] 51 39 52 Explanation of the figure: 40 In such graphs, 53 41 54 * ROOT triangle - no actual purpose, functioning as a starting point, only appears in the representation 55 * Rectangle/box nodes (eg.: {{{cycle1, a, test2}}}) - representing modules (colour: ''deep purple'') 56 * Hexagon nodes (eg.: {{{f1/1, apply/3, test2/2}}}) - representing functions (colour: ''black'') 57 * Double octagon nodes - representing opaque nodes (colour: ''black'', label colour: ''gray'') 58 * Solid, continuous edge, normal arrowhead - normal edge indicating the modules from the root, and the 59 modules and their definitions of functions (colour: ''black'') 60 * Dashed edge, normal arrowhead - indicates that a function calls another function ({{{funcall}}}) (colour: ''black'') 61 * Dashed edge, special arrowhead - indicated a function call, but also that it is a cyclic edge (colour: ''red'') 42 * '''ROOT triangle''' represents a formal starting point if no one has been specified 43 * '''Rectangle''' nodes (e.g. {{{cycle1, a, test2}}}) represent modules (''deep purple'') 44 * '''Hexagon''' nodes (e.g. {{{f1/1, apply/3, test2/2}}}) represent functions (''black'') 62 45 46 * '''Solid, continuous edge, normal arrowhead''': to modules from the root, and the from modules to their functions (''black'') 47 * '''Dashed edge, normal arrowhead''' indicates that a function calls another function ({{{funcall}}}) (''black'') 48 * '''Dashed edge, special arrowhead''' indicates a function call, but also that it is a cyclic edge (''red'') 63 49 64 The next figure was made after a 65 {{{#!erlang 66 ri:anal_dyn(). 67 }}} 68 was run, which is a dynamic analyser. Due to its work the call graph changes a bit, 69 new types of nodes and edges are introduced. 50 After performing [DynamicCallAnalysis dynamic call analysis], dynamic function calls are put into the call graph, and this obviously changes some dependency relations. The following figure shows a graph with dynamic function call dependencies. 70 51 71 52 [[Image(dep_fun_after.png, 900px)]] 72 53 73 Explanation of figure, new nodes, edges: 54 In such graphs, 55 * '''Double octagon''' nodes represent opaque nodes (''black''/''gray'') 56 * '''Dotted edge, normal arrowhead''' indicates an {{{ambcall, dyncall}}} or {{{may_be}}} edge (''black'') 74 57 75 * Double octagon nodes - representing opaque, -1 arity nodes (colour: ''black'', label colour: ''gray'') 76 * Dotted edge, normal arrowhead - indicates an {{{ambcall, dyncall, may_be edge}}} (colour: ''black'') 58 Every node and edge has tooltips. In the case of nodes it shows the corresponding graph node within the database, while considering edges it depicts the type of the function call ({{{funcall, may_be, ambcall, dyncall}}}). Static calls are labelled by {{{funcall}}}. 77 59 78 Every node and edge have tooltips. In the case of nodes it shows the 79 adequate graph node, while considering edges it depicts the type of 80 function call ({{{funcall, may_be, ambcall, dyncall}}}). Static calls are labelled by {{{funcall}}}. 60 {{{#!comment és mi van a modulokba vezető éleken...? 61 }}} 62 63 {{{#!comment TODO esetleg egy normális leírás erről a dynanal oldalra 81 64 82 65 {{{Dyncall}}} means unambiguous dynamic calls, when the identifiers … … 95 78 the previous section, concerning drawings). 96 79 97 We note here that tooltips may not be shown under certain browsers 98 (for example Mozilla Firefox 7.0.1). If this happens, please try 99 another browser. 100 80 }}} 101 81 102 82 === Module Level === … … 106 86 ri:draw_dep([{level, mod}, {type, all}]) 107 87 }}} 108 an analogous figure can be achieved. \\88 an analogous figure can be achieved. 109 89 110 90 [[Image(dep_mod.png, 500px)]] 111 91 112 Explanation of figure: 113 * Rectangle/box nodes (eg.: {{{cycle1, erlang, test2}}}) - representing modules (colour: ''deep purple'') 114 * Doubleoctagon nodes (no example on the figure) - representing opaque nodes (colour: ''black'', label colour: ''gray'') 115 * Dotted edge, normal arrowhead - indicates that a module calls another module (colour: ''black'') 116 * Dotted edge, special arrowhead - indicated a module call, but also that it is a cyclic edge (colour: ''red'') 92 In module dependency graphs, 117 93 94 * '''Rectangle''' nodes (e.g. {{{cycle1, erlang, test2}}}) represent modules (''deep purple'') 95 {{{#!comment * '''Double octagon''' nodes represent opaque nodes (''black''/''gray'') 96 }}} 97 * '''Dotted edge, normal arrowhead''' indicates that a module calls another module (''black'') 98 * '''Dotted edge, special arrowhead''' indicates a call loop (''red'') 118 99 119 The tooltip for edges shows a list the function pair: \\ 120 {{{Call = {callee, called}, Tooltip = [] | [Call | Tooltip]}}} \\ 121 Latter makes a connection between the modules with this call. 100 {{{#!comment TODO értelmes magyarázat az itteni tooltipekre 101 }}} 122 102 123 === Examples for the representation of the results===103 === Examples === 124 104 125 126 *127 105 {{{#!erlang 128 106 ri:draw_dep([{level, mod}, {gnode, erlang}]). 129 107 }}} 130 * 108 131 109 {{{#!erlang 132 110 ri:draw_dep([{level, mod}, {gnode, erlang}, {dot, "/home/working/dot/test.dot" }]). 133 111 }}} 134 * 112 135 113 {{{#!erlang 136 114 ri:draw_dep([{level, func}, {gnode, "lists:hd/1"}]). 137 115 }}} 138 * 116 139 117 {{{#!erlang 140 118 ri:draw_dep([{level, mod},{gnode, {'$gn', module, 4}}]). 141 119 }}} 142 * 120 143 121 {{{#!erlang 144 122 ri:draw_dep([{type, cycles}, {level, func}, {gnode, {'$gn', func, 36}}]).
