Changes between Version 2 and Version 3 of Dependency

Timestamp:

Mar 19, 2012, 11:45:19 PM (13 years ago)

Author:

manualwiki

Comment:

dep. changes

Dependency

@@ -224 +224 @@
 
 === Optional ''Other'' category ===
-Let's think about function blocksin the first sense as mentioned in the beginning, so every directory with its absolute path gives a different function block.  The Other category is a special collector name for those modules which cannot be divided into any function block. Practically this covers those modules which do not have directories (for example, usually erlang). This category can be taken into consideration as a false function block, so
+Let's think about function blocks in the sense that every directory with its absolute path gives a different function block.  The Other category is a special collector name for those modules which cannot be divided into any function block. Practically this covers those modules which do not have directories (for example, usually erlang). This category can be taken into consideration as a false function block, so
 a new option was introduced for eliminating this category. With this the dependencies with ''Other'' category are skipped, the tool takes into consideration only the real connections.
 
@@ -250 +250 @@
 
 Explanation of figure:
-* Hexagon nodes (eg.: cycle1, erlang, test2) - representing  function blocks as number (colour: ''black'')
+* Hexagon nodes (eg.: {{{cycle1, erlang, test2}}}) - representing  function blocks as number (colour: ''black'')
 * Dotted edge, normal arrowhead - indicates that a fb calls another fb (colour: ''black'')
 * Dotted edge, special arrowhead - cyclic edge (colour: ''red'')
+
+=== Using function block analysis from the web interface ===
+The usage of function block analysis is described in !!! TODO add ref.!!!
+
+=== Defining function blocks with regular expressions ===
+Function blocks can be filtered by the means of regular expressions.
+An interface function, called {{{ri:fb_regexp/1}} is provided and its parameters are the following:
+* {{{ {type, Type} }}} \\
+  {{{ Type = list | get_rel | cycle | draw }}}
+  * {{{list}}} Prints out every function block which matches the
+    basic regular expression.
+  * {{{get_rel}}} Decides whether there is a connection between
+    the two given function blocks.
+  * {{{cycle}}} Checks for cycles in the dependencies between the
+    given function block list.
+  * {{{ draw }}} Prints out the entire graph or creates a subgraph
+    drawing from the given function block list.  Output file is
+    {{{fb_relations.dot}}} or can be user defined with the ''dot''
+    key.
+
+* {{{ {regexp, Value} }}} \\
+  {{{ Value = File::string() | [RegExp::string()] }}}
+  
+  If this option (tuple) is not given, the program works with a basic
+  regular expression.  The basic rule: {{{<function block>/common/<service>/ebin}}} or
+  {{{<function block>/common/<service>/lib/ebin}}}. \\
+  The regular expression saved for this:
+  {{{ (/)[0-9a-zA-Z_./]+/common/[0-9a-zA-Z_.]+/(lib/)?(ebin)$ }}}
+  
+
+  * {{{ Value }}} - If the regular expression is given in a file
+    then every single regexp has to be defined in a separate line and
+    must follow the Perl syntax and semantics as the http://www.erlang.org/doc/man/re.html
+    erlang module resembles so. However, the user can give the regular expressions in a list
+    as well. If there is an error with a regular expression in the
+    file or in the list, it prints out the regexp, the error
+    specification, and the position. The most usual regexp is ".*"
+    (the Perl syntax does not allow simply "*", because this symbols
+    means possible unlimited repetition of characters declared before
+    it, and there are no characters declared before it)
+
+Examples:
+*  {{{ri:fb_regexp([{type, draw}, {dot, test.dot}]).}}}
+*  {{{ri:fb_regexp([{type, list}, {regexp, "regexp"}]).}}}
+*  {{{ri:fb_regexp([{type, list}, {regexp, "^/home/[a-z./]+}]).}}}
+
+
+=== User defined function blocks ===
+One can make his own function block in the following three ways:
+1. Giving the exact modules (with their name) which should be in
+  one function block.
+2. Regular expressions covering the structure of the directories.
+3. By regular expressions covering the structure of the directories
+  and the structure of the name of the files.
+
+Example:
+{{{ refusr_fb_regexp:re([{type, list}, {fb, [[cycle1, cycle2],"/home/user/[a-zA-z]*", "/home/user/[a-zA-z./]*/.*_ui.erl"]}]). }}}
+
+
+'''Optimisations'''
+
+For efficiency and time improving reasons, the result of the queries
+are saved into {{{dets}}} tables for the further queries.
+
+
+The results of previous queries are saved into dets tables (in the {{{dep_files}}} directory).  This means that if
+the same query is run, the execution time may decreases significantly.
+At first run, a digraph is built as in the previous version, only it
+is saved later.If there was a whole database dependency check, than the tool works from that dets
+table instead of building a new subgraph, which also improves time
+efficiency. Due to this, it is strongly advised that if one knows that
+a lot of different node queries will be done, a whole check should be
+run in the first place. 
+The saves are available until the
+database is unchanged. At the moment the hash value of the database is
+changed, the existing dets tables are deleted. The deletion does not
+effect the ''.dot'' files, although it is significant to remember
+to save them somewhere else from the ''dep_files'' directory,
+because the next call for draw function will overwrite the
+corresponding ''.dot'' file. This could be prevented by using the
+feature, that the user can define his own dot file name and absolute
+path.