TRIAS Underwriting Software
Komponenten-, Objekt- und Datenmodell
Die TRIAS-Geschäftslogik ist in einzelne Software-Komponenten, die physisch in Form von JAR-Dateien, sog. „Java Archives“, abgespeichert sind, gegliedert. Eine Änderung in der TRIAS-Geschäftslogik betrifft jeweils eine oder mehrere Komponenten. Neue Komponenten können hinzugefügt werden, ohne die Funktionsweise bestehender Komponenten zu beeinträchtigen. Kundenspezifische Aspekte sind in eigenen Komponenten implementiert, so dass jeweils nur die kundenspezifischen Komponenten „angepackt“ werden müssen, wenn es darum geht, die TRIAS-Geschäftslogik an die jeweiligen Verhältnisse des Kunden anzupassen. Im Gegensatz zu einer losen Sammlung von Quelltext-Dateien, die jeweils für die verschiedenen Einsatzszenarien neu kompiliert und zusammengebunden werden, hat der Einsatz von Komponenten den Vorteil, dass der darin enthaltene ausführbare Programmcode unverändert in unterschiedlichen Szenarien und an unterschiedlichen Orten betrieben werden kann. Ein wiederholtes fehleranfälliges Neuarrangieren und Kompilieren der Quelltexte erübrigt sich. Dies ist umso wichtiger, da die Risikoprüfung am „Point of Sale“ praktisch ausschliesslich auf tragbaren Computern mit einem Windows-Betriebssystem von Microsoft betrieben wird, in der Hauptverwaltung dagegen oft auf Mainframes mit Unix oder Unix-ähnlichen Betriebssystemen.Neben den direkt fachlich motivierten und an einer Hand abzählbaren Domänen-Objekten, besteht die TRIAS-Geschäftslogik aus einer Vielzahl von Objekten, die in ihrer Gesamtheit eine komplexe Datenstruktur bilden und derart entworfen sind, dass die unterschiedlichsten Bedürfnisse, insbesondere die flexible Handhabung des Programmcodes, befriedigt werden können. Da die Domänen-Objekte die eigentliche Fachlichkeit repräsentieren, setzt ihr gelungener Entwurf tiefe fachliche Einsicht in den Prozess der Risikoprüfung voraus. Neue fachliche Einsichten schlagen sich sofort im Objektmodell nieder. Aus diesem Grund sollte das Objektmodell in den fachlichen Grundzügen, wie sie in den Domänen-Objekten zum Ausdruck kommen, stabil und statisch entworfen sein, dagegen dort möglichst flexibel, wo fachliche Änderungen und kundenbedingte Unterschiede gewiss oder wahrscheinlich sind. Die Kenntnis darüber setzt langjährige Erfahrung im Umgang mit dem Risikoprüfungsprozess voraus.
Selbstverständlich kennen Objekte keine Komponenten-Grenzen. Deshalb ist es üblich, dass dieselben Objekte in verschiedenen Komponenten zum Einsatz gelangen.
Es mag überraschen, dass die TRIAS-Geschäftslogik kein eigentliches Modell zur Speicherung der persistenten Daten kennt. Aufgrund des konsequenten Einsatzes eines sog. ORM (Object-relational mapping)-Tools, das die Abbildung von Objekten auf Relationen oder auf andere zur persistenten Speicherung von Daten geeignete Entitäten automatisch vornimmt, kennt die TRIAS-Geschäftslogik kein explizites Datenmodell. Das Datenmodell wird vom ORM-Tool automatisch hergeleitet und kann theoretisch je nach eingesetztem Datenbankmanagementsystem auch variieren.