FRep API Discussion

Here are some UML-diagrams regarding proposed FRep API.
We can start our discussions here as well.

Core classes

Core structures are shown in “FRepBase-with-namespace”. frep is a namespace where only FRep related functionality is placed (other structures are more generic ones used by the core components). New operations (functions) are supposed to be derived from OPERATION_T<T, ID, PARAMS_DESC, RESULTS_DESC>. OPERATION_NODE_T<T> will automatically handle child nodes and their results based on the description provided by the aggregated operation. Main idea is to divide responsibilities between different classes. Operation only cares about its internal and input parameters (not where they come from). It evaluates some results based on those parameters and can provide the results if needed. Node is an element helping to traverse the tree and connect parameters of the operations. Thus it doesn’t care about actual operations, their parameters and the way results are evaluated. I think we need to try to keep our interfaces stable and compact. We might need to have parallel hierarchies for different components (i.e. responsible for serialization, tree pruning, scripting etc). But it might be beneficial compared to problems with bloated interfaces and deep inheritance due to shared responsibilities in a base class.

Dynamic diagram (class interactions)

“FRep-Dynamic” is a sequence diagram showing how a node helps to traverses a tree. It starts with modifying a context (e.g. Affine transform operation), triggering evaluations of “independent” and “dependent” child nodes. Child nodes retrieve context modified by their parent and provide it to their operation. Most concrete operations redefine only one method (e.g. only modifyContext or just compute), while base class OPERATION_BASE_T has default implementations for all of them (basically doing nothing). Description provided through base interface OPERATION_BASE_T is enough for a node to trigger its child nodes in the right order and collect their results. Results are provided as input parameters to the operation stored in current node. Node can also provide results of its operation further if needed.

Inner representation

“FRep-Tree-Horizontal” demonstrates internal representation of a simple tree. It shows how parameters of the operations were implicitly connected by the nodes.


PS You can also examine and modify the diagrams using Dia

PPS Quick reminder of UML notation can be found at

FRep API based modeller in progress

Discussion in progress (as by the end of January 2009)

fhfint_frep_api_discussion.txt · Last modified: 2009/01/29 09:24 by denis
This site contains HyperFun and other software that is free to use and modify under the provisions of the CGPL agreement unless otherwise stated.
Project hosted by the Digital Materialization Group
HyperFun CGPL Creative Commons License Valid CSS