1.4.
Dynamically Composed Component
Up one level
Composed components consisting of a flexible number of subcomponents, all of which must be of the same type. The number of subcomponents is defined with the parameterization. According the available records in a database the same number of subcomponents are instantiated.
Concept
- A dynamic composed component is similar to a composed component
in the sense that it contains components and different in the sense
that it contains a flexible number of a component of a specific type.
The type of these component has to be defined in the function
abstract Component getDefaultSubComponent()
- Currently all sub components have the same generic name.
- The wire() and doCalculation() methods follow exactly the same concepts as for a composed component.
- The abstract class DynamicComposedComponent handles adding, removing, naming and other checks for all derived class. The components are administered using a list of component called componentList.
- This concepts enables a data driven modelling. The PODRA modell actually contains six void containers (underwriting, claims generators, correlations, event correlations, lines of business and reinsurance program). As the wiring itself is fix such models typically include several filter components for allocation.
The drawback of such models are the lower performance and the higher risk of parameterization errors.
Step by step example
We create a dynamically composed component containing reinsurance contracts.
- Create a new Groovy class in the corresponding package (Line 1, 2).
(Domain classes can be found in src/groovy/org/pillarone/modelling/domain)
Composed components have to be defined in a Groovy class as wiring would not work with a Java class in the current implementation. - The class has to extend org.pillarone.riskanalytics.core.components.DynamicComposedComponent (Line 2)
- The
DynamicReinsuranceProgram has an arbitrary number of
ReinsuranceContract. Their default instantiation is defined in
getDefaultSubComponent(). The method is called whenever an application
user right clicks on the reinsurance program and adds a new contract.
- Finally it is necessary to define the default name (Line 12-14).
1: package org.pillarone.modelling.domain.reinsurance.programs
...
2: class DynamicReinsuranceProgram extends DynamicComposedComponent {
...
3: public ReinsuranceContract getDefaultSubComponent() {
4: ReinsuranceContract newContract = new ReinsuranceContract(
5: parmInuringPriority: 0,
6: parmContractStrategy:
7: ReinsuranceContractStrategyFactory.getContractStrategy(
8: ReinsuranceContractType.TRIVIAL, [:]))
9: newContract.name = getName(newContract)
10: return newContract
11: }
12: protected String getDynamicComponentName() {
13: "contract"
14: }
...
The wire() method of the DynamicReinsuranceProgram looks rather complicated. The complexity is related with the fact, that the inuring priority parameter of the contracts allows the application user to define any order of the contracts. Furthermore merger components are required to make sure contracts get the correct net information if several contracts have the same inuring priority. The complexity is not related to the concept of dynamic composed components.
