Changes between Version 1 and Version 2 of Documentation/DevelopmentCenter/Architecture
- Timestamp:
- 06/08/10 14:19:02 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Documentation/DevelopmentCenter/Architecture
v1 v2 10 10 The 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. 11 11 12 [[Image(core_architecture.jpg, width=350)]] 13 12 14 The 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] 16 18 17 19 [=#DataModel] 18 20 === 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 datatypes20 such as integers, doubles, strings, or arrays that do not off r 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 values21 In the data model each value is represented as a HeuristicLab 3.3 object that can be saved, restored and viewed. Standard '''data''' types 22 such 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 21 23 and 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. 24 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 population has many solutions which again might have several components. 24 25 25 26 [=#OperatorModel] … … 31 32 * define '''which operators are executed next'''. 32 33 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. 34 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 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. 35 35 36 36 [=#ExecutionModel] 37 37 === Execution Model === 38 38 Algorithms 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 o wof 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.39 an 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.
