Changes between Version 4 and Version 5 of Dependency/Functions


Ignore:
Timestamp:
Apr 16, 2012, 8:04:08 AM (13 years ago)
Author:
manualwiki
Comment:

dependency changes

Legend:

Unmodified
Added
Removed
Modified

  • Dependency/Functions

    v4 v5  
     1[[PageOutline]] 
     2 
    13= Module and Function Dependencies = 
    24 
    … …  
    68A '''cyclic dependency''' appears, when ''B'' is 
    79also dependent directly (''B -> A'') or indirectly (e.g. ''B -> C -> A'') from ''A''. \\ 
     10 
     11If one wants to have a deeper analysis and pays more 
     12attention to the concerning functions, a '''function''' level query should be done. \\ In 
     13our previous example, no function level cycle appears, unless ''A:foo'' calls ''B:foo'', 
     14and ''B:foo'' calls ''A:foo''. \\ 
     15 
    816Note that it is possible to have a cyclic dependency among the modules while having 
    917no cyclic dependencies among the functions. \\ For example, a function call from 
    1018''A:foo'' to ''B:foo'', and from ''B:foo2'' to ''A:foo2'' implies a cyclic dependency on the 
    1119module level. \\ 
    12 If one wants to have a deeper analysis and pays more 
    13 attention to the concerning functions, a '''function''' level query should be done. \\ In 
    14 our previous example, no function level cycle appears, unless ''A:foo'' calls ''B:foo'', 
    15 and ''B:foo'' calls ''A:foo''. \\ 
    1620\\ 
    1721 
    1822== Possible Analysis == 
    1923 
    20  
    21 The following examinations can be done considering dependencies:\\ 
    22 * ''Checking'' whether there are ''cycles'', if so, ''listing'' them out 
    23 * ''Printing out'' the cycles, meaning the modules/functions will not be represented by their proper graph node, but with their ''names'' (instead {{{ {'$gn', module, 3} }}} there will be {{{test}}}). 
    24 * Checking for cycle ''from one or more nodes'' as starting points 
    25 * ''Drawing'' the dependency graph 
    26 * Drawing the dependency graph from a starting node 
    27 * Drawing the cyclic part of the dependency graph if one exists (you can also give a cyclic node as a starting node) \\ 
    28 \\ 
     24There are different kind of examinations that can be run considering dependencies. \\ 
     25 
     26First of all, the possibility of ''checking for cycles'' on RefactorErl database. This means 
     27that the program is going to look for loops on the given level, and returns with the path of the cycles. \\ 
     28 
     29If 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. 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. \\ 
     30In every dependency option there is the opportunity to run the examination from a given function/module or a list of them. 
     31 
     32\\ 
     33 
    2934Dependency analysis can be done through '''two''' interfaces: \\ 
    3035 
    31361. ''ri'' (using RefactorErl through console interface) 
    32 2. using the ''web'' interface. \\ 
    33  
     372. using the ''web'' interface. (see: wiki:WebInterface/DependencyExaminations) \\ 
     38 
     39 
     40== The ''ri'' == 
    3441 
    3542The two interface functions are: 
    3643 
    37 1. {{{ri:draw_dep/1}}} - for drawing 
    38 2. {{{ri:print_dep/1}}} - for listing, printing out to the standard output \\ 
     441.  
     45{{{#!erlang 
     46ri:draw_dep/1 
     47}}} 
     48    - for drawing 
     492.  
     50{{{#!erlang 
     51ri:print_dep/1 
     52}}} 
     53    - for listing, printing out to the standard output \\ 
    3954\\ 
    4055\\ 
    … …  
    4257To call the desired query, the user should give a ''proplist'', stating the different requirements. \\ 
    4358   The options and the keys for the functions are: 
    44 * {{{{level, Level} }}}  
    45     {{{Level = mod | func}}} 
     59* 
     60{{{#!erlang 
     61{level, Level} 
     62    Level = mod | func 
     63}}} 
    4664  Stating the level of the query, module or function level. 
    47 * {{{{type, Type}}}} \\  
    48      {{{Type = all | cycles}}} 
     65* 
     66{{{#!erlang 
     67{type, Type} 
     68     Type = all | cycles 
     69}}} 
    4970   The investigation should be done on the whole graph/table, or just on the cycle part (if it exists). \\ 
    5071   When listing out the cycles, {{{all}}} gives back the result in their graph node form, while {{{cycles}}} returns with their proper 
    5172   names. 
    52 * {{{{gnode, Node | NodeList::lists(Node)}, }}} \\ 
    53      {{{Node = node() | Name,}}} \\ 
    54      {{{Name = Module::atom() | Function::string()}}} \\ 
     73* 
     74{{{#!erlang 
     75{gnode, Node | lists(Node)} 
     76    Node = node() | Name 
     77    Name = Module::atom() | Function::string() 
     78}}}  
    5579   Specify a node or nodes (given in a list) as a starting point for the analysis. \\ 
    56      Module level: the name as an atom \\ 
    57      Function level: name as string ("Module:Function/Arity"). \\ 
    58      In both cases the node/nodes can be given as graph nodes as well.\\ 
    59 * {{{{dot, Dot::string()}}}} 
     80     - Module level: the name as an atom \\ 
     81     - Function level: name as string ("Module:Function/Arity"). \\ 
     82     - In both cases the node/nodes can be given as graph nodes as well.\\ 
     83* 
     84{{{#!erlang 
     85{dot, Dot::string()} 
     86}}} 
    6087   The user can stipulate his own name and absolute path or the generated {{{.dot}}} file.  
    6188   Unless it is a new absolute path, the {{{.dot}}} file will be placed into 
    6289   the {{{./dep_files}}} directory. Only available in the case of draw_dep. 
    63 * {{{ {exception, NodeList::lists(Node)} }}} \\ 
    64      {{{Node = node() | Name,}}} \\ 
    65      {{{Name = Module::atom() | Function::string()}}} \\ 
     90* 
     91{{{#!erlang 
     92{exception, NodeList::lists(Node)} 
     93     Node = node() | Name 
     94     Name = Module::atom() | Function::string() 
     95}}}  
    6696   The exception key gives the user the opportunity to define certain nodes (by stating their name or by giving a gnode) which 
    6797   will be exluded from the analysis. 
    68 * {{{ {leaves, NodeList::lists(Node)} }}} \\ 
    69      {{{Node = node() | Name,}}} \\ 
    70      {{{Name = Module::atom() | Function::string()}}} \\ 
     98* 
     99{{{#!erlang 
     100{leaves, NodeList::lists(Node)} 
     101     Node = node() | Name 
     102     Name = Module::atom() | Function::string() 
     103}}}  
    71104   Leaves contains those nodes which would be included in the analysis, but their children won't (so this way they become exceptions). 
    72 * {{{ {otp, true | false} }}} 
     105* 
     106{{{#!erlang 
     107{otp, true | false} 
     108}}} 
    73109   The built-in erlang otp modules should be included in the analysis or not. The default value is false. 
    74110