Changes between Version 1 and Version 2 of Documentation/DevelopmentCenter/Architecture


Ignore:
Timestamp:
06/08/10 14:19:02 (12 years ago)
Author:
mkofler
Comment:

Updated architecture description

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/DevelopmentCenter/Architecture

    v1 v2  
    1010The core of HeuristicLab is its algorithm model. It is very easy to understand on an abstract level, but naturally reveals more complexity the deeper one descends into it. However, luckily for most users, understanding more than the abstract level of the core language is not necessary for applying heuristic optimization.
    1111
     12[[Image(core_architecture.jpg, width=350)]]
     13
    1214The algorithm model splits into three distinct models itself:
    13  * [#DataModel]
    14  * [#OperatorModel]
    15  * [#ExecutionModel]
     15 * [#DataModel| Data Model]
     16 * [#OperatorModel| Operator Model]
     17 * [#ExecutionModel| Execution Model]
    1618
    1719[=#DataModel]
    1820=== Data Model ===
    19 In the data model each value is represented as a HeuristicLab 3.3 object that can be saved, restored and viewed. Standard data types
    20 such as integers, doubles, strings, or arrays that do not offr these properties are wrapped in HeuristicLab 3.3 objects. These values are linked to a name by storing them in a '''variable'''. The data type of a variable is not fixed explicitly but is given by the type of the contained value. In a typical heuristic optimization algorithm a lot of different data values and therefore variables are used. Hence, in addition to data values
     21In the data model each value is represented as a HeuristicLab 3.3 object that can be saved, restored and viewed. Standard '''data''' types
     22such as integers, doubles, strings, or arrays that do not offer these properties are wrapped in HeuristicLab 3.3 objects. These values are linked to a name by storing them in a '''variable'''. The data type of a variable is not fixed explicitly but is given by the type of the contained value. In a typical heuristic optimization algorithm a lot of different data values and therefore variables are used. Hence, in addition to data values
    2123and variables, another kind of objects called '''scopes''' is required to store an arbitrary number of variables. To access a variable in a
    22 scope, the variable name is used as an identifer. Thus, a variable name has to be unique in each scope the variable is contained. Finally, these scopes can be hierarchically organized as trees. A scope may have several so-called sub-scopes, much like a metaheuristic
    23 population has many solutions which again might have several components.
     24scope, the variable name is used as an identifer. Thus, a variable name has to be unique in each scope the variable is contained. Finally, these scopes can be hierarchically organized as trees. A scope may have several so-called sub-scopes, much like a metaheuristic population has many solutions which again might have several components.
    2425
    2526[=#OperatorModel]
     
    3132 * define '''which operators are executed next'''.
    3233
    33 Regarding the manipulation of variables, the approach used in the HeuristicLab 3.3 operator model is similar to formal and actual parameters of procedures. Each operator defines parameters for each variable it expects and possibly manipulates. By this means, operators are able to encapsulate functionality in an abstract way: A formal name is dened for a parameter which is used inside the operator. But after instantiating an concrete operator in the GUI and adding it to an algorithm at run time, the user defines the actual name of the parameter. The original code of the operator
    34 does not have to be modied. The implementation of the operator is decoupled from concrete variables and can be reused.
     34Regarding the manipulation of variables, the approach used in the HeuristicLab 3.3 operator model is similar to formal and actual parameters of procedures. Each operator defines '''parameters''' for each variable it expects and possibly manipulates. By this means, operators are able to encapsulate functionality in an abstract way: A formal name is defined for a parameter which is used inside the operator. But after instantiating an concrete operator in the GUI and adding it to an algorithm at run time, the user defines the actual name of the parameter. The original code of the operator does not have to be modied. The implementation of the operator is decoupled from concrete variables and can be reused.
    3535
    3636[=#ExecutionModel]
    3737=== Execution Model ===
    3838Algorithms are represented as operator graphs and executed step-by-step on virtual machines called '''engines'''. In each iteration an engine performs
    39 an operation, i.e., it applies an operator to a scope. As the execution ow of an algorithm is dynamically defined by its operators, each operator may return one or more operations that have to be executed next. These pending operations are kept in a stack. In each iteration, an engine pops the next operation from the top of its stack, executes the operator on the scope, and pushes returned successor operations back on the stack.
     39an operation, i.e., it applies an operator to a scope. As the execution order of an algorithm is dynamically defined by its operators, each operator may return one or more operations that have to be executed next. These pending operations are kept in a stack. In each iteration, an engine pops the next operation from the top of its stack, executes the operator on the scope, and pushes returned successor operations back on the stack.