Changes between Version 8 and Version 9 of Dependency/Functions


Ignore:
Timestamp:
Apr 24, 2012, 12:11:16 PM (13 years ago)
Author:
daniel_h
Comment:

some parts already moved to the ri page

Legend:

Unmodified
Added
Removed
Modified

  • Dependency/Functions

    v8 v9  
    44 
    55== Concerning terminology == 
    6 We say that a module A is '''dependent''' on another '''module''' ''B'' (''A -> B'') if there is 
    7 at least one function call from ''A'' to ''B''. \\ 
    8 A '''cyclic dependency''' appears, when ''B'' is 
    9 also dependent directly (''B -> A'') or indirectly (e.g. ''B -> C -> A'') from ''A''. \\ 
    106 
    11 If one wants to have a deeper analysis and pays more 
    12 attention to the concerning functions, a '''function''' level query should be done. \\ In 
    13 our previous example, no function level cycle appears, unless ''A:foo'' calls ''B:foo'', 
    14 and ''B:foo'' calls ''A:foo''. \\ 
     7We 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''. 
    158 
    16 Note that it is possible to have a cyclic dependency among the modules while having 
    17 no cyclic dependencies among the functions. \\ For example, a function call from 
    18 ''A:foo'' to ''B:foo'', and from ''B:foo2'' to ''A:foo2'' implies a cyclic dependency on the 
    19 module level. \\ 
    20 \\ 
     9Apparently, 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''. 
     10 
     11Note 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 
     12module level, but no one on the function level. 
    2113 
    2214== Possible Analysis == 
    … …  
    4032\\ 
    4133 
    42 Dependency analysis can be done through '''two''' interfaces: \\ 
     34Dependency analysis can be done via the following interfaces: 
     35 * [ErlangShellInterface#Dependencyanalysis Erlang shell] 
     36 * [WebInterface/DependencyExaminations Web interface] 
    4337 
    44 1. ''ri'' (using RefactorErl through console interface) 
    45 2. using the ''web'' interface. (see: wiki:WebInterface/DependencyExaminations) \\ 
    46  
    47  
    48 == The ''ri'' == 
    49  
    50 The two interface functions are: 
    51  
    52 1.  
    53 {{{#!erlang 
    54 ri:draw_dep/1 
    55 }}} 
    56     - for drawing 
    57 2.  
    58 {{{#!erlang 
    59 ri:print_dep/1 
    60 }}} 
    61     - for listing, printing out to the standard output \\ 
    62 \\ 
    63 \\ 
    64 \\ 
    65  
    66 === Options for ''ri'' === 
    67 To call the desired query, the user should give a ''proplist'', stating the different requirements. \\ 
    68    The options and the keys for the functions are: 
    69 * 
    70 {{{#!erlang 
    71 {level, Level} 
    72     Level = mod | func 
    73 }}} 
    74   Stating the level of the query, module or function level. 
    75 * 
    76 {{{#!erlang 
    77 {type, Type} 
    78      Type = all | cycles 
    79 }}} 
    80    The investigation should be done on the whole graph/table, or just on the cycle part (if it exists). \\ 
    81    When listing out the cycles, {{{all}}} gives back the result in their graph node form, while {{{cycles}}} returns with their proper 
    82    names. 
    83 * 
    84 {{{#!erlang 
    85 {gnode, Node | lists(Node)} 
    86     Node = node() | Name 
    87     Name = Module::atom() | Function::string() 
    88 }}}  
    89    Specify a node or nodes (given in a list) as a starting point for the analysis. \\ 
    90      - Module level: the name as an atom \\ 
    91      - Function level: name as string ("Module:Function/Arity"). \\ 
    92      - In both cases the node/nodes can be given as graph nodes as well.\\ 
    93 * 
    94 {{{#!erlang 
    95 {dot, Dot::string()} 
    96 }}} 
    97    The user can stipulate his own name and absolute path or the generated {{{.dot}}} file.  
    98    Unless it is a new absolute path, the {{{.dot}}} file will be placed into 
    99    the {{{./dep_files}}} directory. Only available in the case of draw_dep. 
    100 * 
    101 {{{#!erlang 
    102 {exception, NodeList::lists(Node)} 
    103      Node = node() | Name 
    104      Name = Module::atom() | Function::string() 
    105 }}}  
    106    The exception key gives the user the opportunity to define certain nodes (by stating their name or by giving a gnode) which 
    107    will be exluded from the analysis. 
    108 * 
    109 {{{#!erlang 
    110 {leaves, NodeList::lists(Node)} 
    111      Node = node() | Name 
    112      Name = Module::atom() | Function::string() 
    113 }}}  
    114    Leaves contains those nodes which would be included in the analysis, but their children won't (so this way they become exceptions). 
    115 * 
    116 {{{#!erlang 
    117 {otp, true | false} 
    118 }}} 
    119    The built-in erlang otp modules should be included in the analysis or not. The default value is false. 
    120  
    121 === Examples for listing results === 
    122  
    123  
    124  
    125 * Checking for cycles in module level. \\ 
    126 {{{#!erlang 
    127 ri:print_dep([{level, mod}, {type, all}]). 
    128 }}} 
    129    
    130  
    131 * Checking for cycles in function level, and printing out the whole names of the functions (Module:Function/Arity). \\ 
    132 {{{#!erlang 
    133 ri:print_dep([{level, func}, {type, cycles}]). 
    134  
    135   [['foo:fv4/1','foo:fv4/1'], 
    136   ['test3:p/1','test:fv6/1','test3:p/1'], 
    137   ['cycle4:f4/1','cycle3:f3/1','cycle4:f4/1'], 
    138   ['cycle2:fv2/1','cycle1:fv1/0','cycle2:fv2/1'], 
    139   ['test:fv5/1','test:fv4/2','test:fv5/1'], 
    140   ['cycle4:f5/1','cycle3:f6/1','cycle4:f5/1']] 
    141 }}} 
    142  
    143  
    144 * Checking for cycles in function level, and printing out the graph nodes of the functions (notice the changed "type" in the proplist) \\ 
    145 {{{#!erlang 
    146 ri:print_dep([{level, func}, {type, all}]). 
    147  
    148   {"6 cycle(s)", 
    149   {[[{'$gn',func,28},{'$gn',func,28}],  
    150   [{'$gn',func,29},{'$gn',func,37},{'$gn',func,29}], 
    151   [{'$gn',func,7},{'$gn',func,9},{'$gn',func,7}], 
    152   [{'$gn',func,2},{'$gn',func,1},{'$gn',func,2}], 
    153   [{'$gn',func,36},{'$gn',func,35},{'$gn',func,36}], 
    154   [{'$gn',func,8},{'$gn',func,6},{'$gn',func,8}]]} 
    155 }}} 
    156  
    157 * Checking for cycles in module level from an exact node \\ 
    158 {{{#!erlang 
    159 ri:print_dep([{level, mod}, {gnode, {'$gn', module, 24}}]).  
    160  
    161          {true,[[{'$gn',module,24}, 
    162          {'$gn',module,25}, 
    163          {'$gn',module,24}]]} 
    164 }}} 
    165  
    166  
    167 * Checking for cycles in function level from an exact node given with its whole name \\ 
    168 {{{#!erlang 
    169 ri:print_dep([{level, func}, {gnode, "cycle4:f5/1"}]). 
    170 }}} 
    17138 
    17239== Representation ==