Personal tools
You are here: Home → Community → Help Center → Reference Manuals → Modelling with RiskAnalytics → Glossary

Glossary

Note: Return to reference manual view.

WORK IN PROGRESS: This manual contains descriptions needed by users and developers.

1. Model

A model is a flexible net of components and describes the business object relations. We keep the model separate from the parameterization, structure, simulation templates and results.

Further readings:

2. Component

PillarOne internal models are composed of components. We try to keep them as simple as possible in order to improve testability and reusability. Every component has to be derived from the abstract class org.pillarone.modelling.components.Component. This class handles the common behaviour for all components such as receiving input and sending output, validation and execution.
Output preparation

Every component has to overwrite the abstract procedure doCalculation(). It is called once a component has received all input and therefore all data is available in order to execute the calculations and prepare the output of the component.

 

Further readings:

3. Channel

Channels are used to transmit packets between components.

They are defined in a model or in a composed component. Channels are type safe and their "ports" have to be defined in the component.

As a naming convention properties of incoming ports start with 'in' (receivers), outgoing ports with 'out' (senders). A channel is defined in the following way:

[receiving component].[in...] = [sending component].[out...]
Further readings:

4. Parameterization

Parameters can be set in the user interface. As a naming convention their name starts with 'parm'.

In order to avoid noisy user interfaces and to reduce the implementation effort for a new component, the parameterization view is generated.

5. Composed Component

Composed components include at least one other component.

Components should be as simple as possible in order to provide a high flexibility in its usage. Simple and small components have one disadvantage: When connecting components to a model developers will always have to start from scratch - quite a waste of time!

In order to avoid restarting for every model from scratch, a developer may create building blocks derived from org.pillarone.modelling.components.ComposedComponent.

Examples for such building blocks may be found i.e. in the package domain/lob and domain/reinsurance/program.

A composed component is somehow similar to a model, as it contains several components, statements defining wiring but no specific algorithms implementing any formulas.

Furthermore each composed components adds a hierarchy level in the user interface, as its sub components are added below them in the tree.

6. Dynamic Composed Component

A dynamic composed component contains at least one component of a specific type. The cardinality of components is not defined in the model as usual but within the parameterization.

The cardinality of required components of a certain is not always fix in a model. As an example the number of contracts may vary depending on the reinsurance program and the application user should be able to change it.

All dynamic composed components have to be derived from org.pillarone.modelling.components.DynamicComposedComponent. 

Document Actions