OBJECT FRAMEWORKS FOR REINSURANCE

Abstract: An improved method and system for developing a reinsurance administration system. Developers may build application programs for reinsurance administration with increased re-use of existing functionality and decreased development time. A business process framework may include common functionality for a plurality of business processes and a template for executing steps in the business processes. The business processes may be combined to build one or more application programs. A multi-dimensional reinsurance contract framework may permit the handling of various dimensions of a reinsurance contract such as handling different versions of the reinsurance contract (e.g., yearly periods), handling multi-level specialization hierarchy (e.g., different conditions for different sections of the reinsurance contract), handling the change of conditions within a period, and processing inheritance of contract structure and conditions from an abstract or master reissue contract. An object-oriented condition component framework may represent a condition dimension of a reinsurance contract. The condition component framework may permit the addition and/or modification of condition components of the reinsurance contract.

Description: TITLE: OBJECT FRAMEWORKS FOR REINSURANCE BACKGROUND OF THE INVENTION 1. Field of the Invention The present mvention generally relates to computer software. More particularly, the present invention relates to software frameworks for developmg financial services software. 2 Description of the Related Art Financial services organizanons have come to rely on complex software systems to administer their businesses. Financial service organizations may include, for example, reinsurance organizations. Remsurance may mclude the transfer by a first insurer of all or part of a πsk to a second insurer to provide protection against the πsk, as well as any associated transactions. In other words, reinsurance can be thought of as "insurance for insurance companies " When catastrophic events such as earthquakes, floods, tornadoes, hurricanes, airline accidents, etc occur the insured often file for damage claims to reduce the impact of the loss of property and/or life. The insurance companies, which offer policies to cover for such catastrophic losses, come under severe financial strain to absorb the losses and still maintain the required surplus. The surplus is an msurance company's net worth, i.e. its assets minus its liabilities. Some insurance companies may deplete their surplus too far to be unable to fulfill their obhganons to their policyholders To protect pohcyholders against msolvency of an msurance company, government regulations may require insurance companies to maintain a minimum surplus. The size of an insurance companies surplus is thus considered as an important factor to rate insurance companies. To maintain a surplus and protect against insolvency insurance companies may purchase their own insurance policies, i.e. remsurance policies An msurance company, also known as primary or ceding company, may purchase a remsurance policy from a remsurance company, also known as reinsurer, m much the same way that direct or primary msurance is purchased. The pπmaiy or the first insurer may also be called a cedent, and the secondary or the second insurer may be called a reinsurer. Remsurance organizations may mclude cedents, reinsurers, and any other entities mvolved in reinsurance transactions Remsurance may protect a cedent against catastrophes and cumulative losses and also enable it to accept πsks that exceed its own underwriting capacity. The complexity of the remsurance field tends to require software for remsurance administration to be complex as well Generally speaking, software for reinsurance administranon may be expected to handle πsk selection, portfolio analysis, policy administration, claims, accounting, and other areas vital to the reinsurance field Remsurance profits may depend on analysis of historical information, the ability to predict trends, and the ability to identify cumulative exposures within a current portfolio, and remsurance software may therefore be expected to meet requirements relatmg to those functions. Consequently, the development of a software system for reinsurance administration to meet the above-identified needs may require great time and expense In a changing reinsurance market, a reinsurance company may quickly fall behind its competitors. For example, as reinsurers begm taking on direct πsks, the market may demand integrated solutions. Some reinsurance computer systems may not be able to easily and quickly migrate the graphical user interfaces from a text based display to a color, graphical display. Some reinsurance computer systems may be unable to modify and customize a reinsurance contract, such as adjustment of an msurance penod, changing premium limits, etc. to meet a customer requirement m a prompt manner A reinsurer may need to move quickly against competitors to meet the changing needs of the market or to revitalize a reinsurance product line. Therefore, it would be advantageous for a reinsurer to reduce the time, expense, and πsk associated with a complex product development effort that may require more than one hundred person-years of development time. Even during development, technical and functional requirements may evolve as dozens of potential customers instruct the reinsurer of their customized needs. It would be further advantageous for a reinsurer to have a flexible development process that can meet evolvmg customer requirements m the middle of a development effort. Utilization of object-oπented software design techniques is one approach towards reducmg development time Object-onented software design may mclude the use of objects and classes. An object may mclude an encapsulation of data and methods for manipulating the data. A class may mclude a template for an object. An object is therefore an instance of a class, and an object is created by instantiating it from a class. Object-onented techniques, when used properly, may permit the re-use of previously wπtten program code such as classes. The use of development frameworks is a related approach towards reducmg development tune. As used herem, a "framework" may mclude a set of classes or templates that embodies an abstract design for solutions to a number of related problems. Therefore, there is a need for a system and method for developmg computer programs for reinsurance administranon with decreased development tune and increased flexibility. SUMMARY OF THE INVENTION The present invennon provides vaπous embodiments of an improved method and system for developmg a reinsurance administration system The method and system may be used by developers to build application programs for reinsurance administration with increased re-use of existing functionality and decreased development tune. A busmess process framework may mclude common functionality for a plurality of busmess processes. The busmess process framework may mclude a template for executing the busmess processes. In one embodiment, the method may mclude deπving one or more busmess processes from the busmess process framework. One or more busmess process subclasses may be deπved from one or more abstract busmess process classes, wherem the busmess process framework mcludes the one or more abstract busmess process classes At run-time during the execution of the remsurance administranon system, the busmess process objects may be instantiated as instances of the one or more busmess process subclasses The method may further mclude combining the busmess process subclasses to build one or more application programs, such as application programs for reinsurance administranon In one embodiment, a first busmess process subclass may be configured to invoke a second busmess process subclass The busmess process framework may mclude a plurality of support processes. The method may further mclude identifying one or more of the support processes for each of the busmess process subclasses. The support processes may mclude, for example, support processes for data validation, support processes for performing syntax validation, support processes for secuπty checks, support processes for graphical user mterface elements, and support processes for persistent data storage, and/or support processes for performing precondition checks. In one embodiment, identifying one or more of the support processes for each of the busmess process subclasses may mclude overπdmg one or more of hook methods for each of the busmess process subclasses. The busmess process framework may mclude a plurality of hook methods. The hook methods may permit the developer to access pomts during the execution of the busmess process. By overπdmg the hook methods at vaπous pomts, the developer may identify methods to be performed at vaπous pomts during execution of the busmess process. Overnding one or more of the hook methods for each of the busmess processes may mclude replacmg one or more of the hook methods lnhented from an abstract busmess process class with one or more new methods. The hook methods may mclude, for example, methods to be executed during initialization of the busmess process, methods to be executed pπor to execution of a data entry support process, methods to be executed during execution of data entry without a user mterface, methods to be executed pπor to execution of a database commit support process, and/or methods to be executed pπor to execution of a database rollback support process. As will be apparent to one skilled m the art, many more hook methods may be employed m developmg a busmess process. The common functionality of the busmess process framework may mclude an order for executing steps in a busmess process. The steps in the busmess process may mclude pre-execution, data entry, data validation, pre- commission to a database, commission to the database, and post-commission to the database The common functionality of the busmess process framework may mclude behavior for buttons m a graphical user mterface, formatting and displaying windows in a graphical user mterface, methods or vaπables of the abstract busmess process classes which are inheπted by the busmess process subclasses, loggmg and displaying error messages, committing changes to a database, and or rolling back changes to a database. An object-onented, multi-dimensional reinsurance contract framework may represent a remsurance contract. The multi-dunensional reinsurance contract framework may permit the handling of vaπous dimensions of a reinsurance contract such as handling different versions of the reinsurance contract (e.g., yearly peπods), handling multi-level specialization hierarchy (e.g., different conditions for different sections of the reinsurance contract, handling the change of conditions within a peπod, and processmg mheπtance of contract structure and conditions from an abstract or master reissue contract. The multi-dimensional reinsurance contract framework may capture the vanous dimensions and hide the multi-dimensionality from subsequent domain modeling and the design of additional remsurance contract components. The framework may also encapsulate busmess rules for managing the vaπous dimensions mto an abstract framework. An object-onented condition component framework may represent the condition component or dimension of a reinsurance contract. The condition component framework may permit the addition and/or modification of one or more conditions mcluded in the condition component of the reinsurance contract These conditions may compπse, for example, configuring or changing the premium limits, consolidation conditions, and other conditions for a reinsurance contract The condition component may be implemented as reusable objects The busmess process framework may also mclude an object-onented graphical user mterface software The graphical user mterface may mclude a plurality of displays, along with a navigational tool to enable users to navigate through a hierarchy of displays related to remsurance transaction processmg. Each display may be defined as an object. A display may mclude one or more wmdows and the navigational tool. The one or more windows and the navigational tool may be displayed m a tiled, non-overlapping manner. The navigational tool may mclude one or more tool panels. The navigational tool may also mclude one or more user mterface items such as icons and buttons to enable the user m navigatmg through the hierarchy of displays. Each user mterface item mcluded m the navigational tool may be configured to perform a particular action such as calling a particular display on receiving a user mput. The user may process a reinsurance busmess transaction by accessmg the hierarchy of displays with the navigational tool integrated with the busmess process framework BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is an illustration of a typical computer system which is suitable for implementing vaπous embodiments; Figure 2 is an illustration of a distnbuted computing environment which is suitable for implementing vanous embodiments; Figure 3a is an illustration of remsurance transaction processmg software us g object-onented technology accordmg to one embodiment; Figure 3b is an illustration of a layered architecture of a remsurance administration system accordmg to one embodiment; Figure 4 is an illustration of a development process for developmg a remsurance administration system accordmg to one embodiment; Figure 5 is a flowchart illustrating the development of a remsurance administration system through a busmess process framework accordmg to one embodiment; Figures 6a and 6b are state diagrams illustrating the life of a busmess process accordmg to one embodiment; Figure 7a illustrates one embodiment of an lnhentance view of a hierarchy of busmess objects, Figure 7b illustrates one embodiment of an inheπtance view of a section object; and Figures 8a through 8d illustrate one embodiment of a graphical user mterface for processmg a reinsurance busmess transaction. While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example m the drawings and will herein be descπbed m detail. It should be understood, however, that the drawings and detailed descnption thereto are not mtended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spiπt and scope of the present invention as defined by the appended claims. DETAILED DESCRIPTION OF THE DRAWINGS Figure 1: A Typical Computer System Figure 1 illustrates a typical computer system 150, which is suitable for implementing vanous embodiments. Each computer system 150 typically mcludes components such as a CPU 152 with an associated memory medium such as floppy disks 160 The memory medium may store program instructions for computer programs, wherem the program instructions are executable by the CPU 152. The computer system 150 may further mclude a display device such as a monitor 154, an alphanumeric mput device such as a keyboard 156, and a directional mput device such as a mouse 158 The computer system 150 is operable to execute the computer programs to implement the system and method for developmg a reinsurance transaction processmg system, also referred to as the reinsurance administration system, as descnbed herein. As descπbed herein, one embodiment of the typical the computer system 150 may be a reinsurance transaction processmg system 150. The computer system 150 preferably mcludes a memory medium on which computer programs according to vaπous embodiments may be stored The term "memory medium" may mclude an installation medium, e.g., a CD- ROM, or floppy disks 160, a computer system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile memory such as a magnetic media, e.g , a hard dnve, or optical storage. The memory medium may mclude other types of memory as well, or combinations thereof. In addition, the memory medium may be located in a first computer m which the programs are executed, or may be located in a second different computer, which connects to the first computer over a network (not shown). In the latter instance, the second computer provides the program instructions to the first computer for execution. Also, the computer system 150 may take vaπous forms, including a personal computer system, mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television system or other device. In general, the term "computer system" 150 can be broadly defined to encompass any device having a processor 152, which executes instructions from a memory medium. The memory medium preferably stores software programs for reinsurance administration and/or software programs for developmg a reinsurance administration system as descπbed herein. The software program(s) may be implemented m any of vanous ways, mcludmg procedure-based techniques, component-based techmques, and/or object-onented techniques, among others. For example, the software program may be implemented using ActiveX controls, C++ objects, JavaBeans, Microsoft Foundation Classes (MFC), or other technologies or methodologies, as desired. A CPU, such as the host CPU 152, executing code and data from the memory medium mcludes a means for creating and executing the software program or programs accordmg to the methods and/or block diagrams descπbed below. In Figure 1, an embodiment of a remsurance transaction processmg system may mclude a computer system 150. The term "computer system" as used herem generally mcludes the hardware and software components that m combination allow the execution of computer programs. The computer programs may be implemented in software, hardware, or a combination of software and hardware. A computer system's hardware generally mcludes a processor (CPU 152), memory media, and Input/Output (I/O) devices. As used herem, the term "processor" generally descnbes the logic circuitry that responds to and processes the basic instructions that operate a computer system. A computer system's 150 software generally includes at least one operating system such as Windows NT, which is available from the Microsoft Corporation. The operating system is a specialized software program that manages and provides services to other software programs on the computer system. Software may also mclude one or more programs to perform vaπous tasks on the computer system and vanous forms of data to be used by the operating system or other programs on the computer system. The data may mclude but are not limited to databases, text files, and graphics files. A computer system's software generally is stored m non-volatile memory, such as floppy disks 160, or on an installation medium. A program may be copied into a volatile memory when running on the computer system 150. Data may be read mto volatile memory as required by a program. A server may be defined as a computer program that, when executed, provides services to other computer programs executing m the same or other computer systems. The computer system on which a server program is executing may also be refened to as a server, though it may contain a number of server and client programs. In the client/server model, a server is a program that awaits and fulfills requests from client programs m the same or other computer systems. A server that may be used to process remsurance transactions is the SICS system. The SICS system is supplied by Computer Sciences Corporation. As used herein, the term "channel" generally descnbes any pathway that allows a user to mterface with a computer system. Channels may mclude, but are not limited to, mam office entry systems, branch office entry systems, kiosks, call centers, Internet systems, and electronic data interchange (EDI) systems. A channel may be a computer system. For example, the computer system 150 shown m Figure 1 may be a channel used for a reinsurance office data entry system, a branch office entry system, a client computer system with a web browser or a component of the system used m a call center channel. Each type of channel may require different implementation systems. For example, a kiosk entry system may use a touch-oπented visual screen. Special programming implementations may be needed to transfer data from the kiosk to the computer system. A channel may be implemented so that the channel may only be used for selected types of busmess transactions. A kiosk system may be set up to only process certain busmess transactions, such as providing pncmg quotes for specified remsurance coverage situations. An office data entry system may use a momtor 154, keyboard 156 and pointing device 158 (mouse) to allow for data entry mto a computer system 150. A call center typically mvolves the oral communication of data to a person who enters the data mto a computer system through a keyboard 156 and/or pointing device 158. Electronic data entry systems may transfer data from one computer system to another. The reinsurance transaction processmg system 150 may further mclude a display screen 154 connected to the computer system 150 and a remsurance database (not shown) residmg on an mtemal or external storage. The database may also be referred to as a repository. As used herein, a "database" may mclude a collection of information from which a computer program may select a desired piece of data. As used herem, a "reinsurance database" is used as a synonym for a "database" when mcluded m or coupled to a reinsurance transaction processmg system 150 Remsurance transaction processmg program, also refened to as application program software, may be stored m memory. As used herein, a "reinsurance transaction processmg program", also refened to as a reinsurance program or reinsurance software, may mclude a software program which is configured to execute reinsurance transactions, such as by estimating the value of the reinsurance premium, for example. The reinsurance transaction processmg system 150 may be used by a Reinsurance Company (RC) for vanous embodiments of a system and method for processmg reinsurance transactions. As used herem, a reinsurance Company (RC) mcludes a busmess organization that provides reinsurance products and/or services to customers. More particularly, the reinsurance products may pertain to estimating premiums, damages, etc. For example, estimating a remsurance premium for a reinsurance policy, providmg an estimate for a reinsurance claim filed for property and casualty damage In one embodiment, on incurring property damage to its policyholders, a primary msurance company may file a reinsurance claim (RC) with their reinsurance organization to cover loss of property. A RC may utilize a computer-based reinsurance claim processmg system to process reinsurance claim. In one embodiment, the transaction processmg may mclude estimating a value associated with the filed reinsurance claim. As used herem, an RC busmess transaction may be defined as a service of an RC. Examples of busmess transactions mclude, but are not limited to, reinsurance transactions such as: filing of reinsurance claims, application for additional reinsurance coverage, payment of premiums, application for new remsurance coverage, and customized benefits, etc. For a reinsurance provider, examples of busmess transactions may mclude, but are not limited to, addmg or deleting primary insurance companies, trackmg payables and receivables, estabhshmg new policies/contracts, renewmg policies/contracts, changing policies/contracts, canceling policies/contracts, providmg pncmg quotes for policies, and processmg claims based on policies. Busmess transactions may also mclude services related to customers, reinsurance providers, employers, reinsurance agents, investigators, regulatory agencies, etc As used herem, an RC reinsurance transaction processmg mcludes a senes of instructions executed by a computer system 150 for processmg an RC's busmess transactions. An RC transaction processmg system 150 may mclude one or more processmg tasks. A processmg task may mclude a sequence of one or more processmg steps or an ordered list or a structured list of one or more processmg steps, associated with the busmess transaction to be processed by the RC transaction processmg system. In one embodiment, the sequence of steps may be fixed. In another embodiment the sequence of steps may be established dynamically, m real-time. In one embodiment, the sequence of one or more steps may mclude an initial step, a final step, one or more intermediary steps, etc. In one embodiment, an RC user may select steps to process a reinsurance claim m a sequential manner. In another embodiment, the RC user may select steps to process a reinsurance claim m a random or arbitrary manner Examples of processmg steps may mclude, but are not limited to: receivmg an mput from a user of the RC reinsurance transaction processmg system, reading a value from a database, updating a field m a database, displaying the results of a busmess transaction on a computer screen 154, etc In one embodiment, the reinsurance transaction processmg system utilizes object-onented technology to process reinsurance transaction. In another embodiment, processmg of reinsurance transaction may utilize traditional programming languages and databases to achieve the same result. Reinsurance objects may be defined to represent or model real-world busmess features of reinsurance products and services. Examples of reinsurance objects may mclude, but are not limited to, objects representing the following: a reinsurance claim; an accident report; a settlement; an estimated claim, RC service fac lties, customers, and employees; busmess process such as a new reinsurance application and calculation of a premium; interfaces to external reinsurance organizations; work tasks such as calculations, decisions, and assignments; temporal objects such as calendars, schedulers, and timers; and elemental data necessary to accomplish work tasks such as medical costs, risk factors, automobile repair costs, etc. A reinsurance object may be represented on the computer screen 154 by a graphical icon or by a display listing the properties of the reinsurance object m graphic and/or alphanumenc format. In one embodiment, a reinsurance claim object may be configured to gather and evaluate data for processmg a filed reinsurance claim and to automatically make decisions about the reinsurance claim. The one or more processmg steps associated with the processmg of a reinsurance claim may also be configured as one or more processmg step objects. In one embodiment, a display screen 154, which also may be referred to as a page or a display, may be associated with a processmg step. The display screen may also be represented as an object. Each display screen object may mclude a property to point to a previous display and another property to point to a next display screen. Each property, e g. the next display pointer on a display screen object, may be changed dynamically by usmg methods associated with the display screen object. One display screen object may serve as the starting pomt for processmg reinsurance transaction. In one embodiment, the starting pomt for processmg a reinsurance transaction may mclude acquiring a reinsurance claun number or a reinsurance pohcy identification number from an RC system user. In one embodiment, during the processmg of a reinsurance claun, a busmess rule and/or an RC system user mput may determine that the reinsurance claun processmg needs the execution of additional steps or tasks to continue the processmg of the claim. The RC system user may provide mputs to the reinsurance transaction- processmg program at any display screen 154 associated with a step mcluded m the initial screen. The reinsurance claim processmg software may dynamically modify the number of steps and/or the sequence of their execution to complete the claim processmg transaction An RC system user working at a client system may then iterate through the claim processmg steps and arπve at an estimated value for the reinsurance claim In one embodiment, upon startup, the program may provide a graphical user mterface (GUI) to display transaction processmg related information on display screen 154 It may collect user mputs, entered by usmg user mput devices 156 or 158, and associated with a reinsurance transaction. It may process the user mputs, access a reinsurance database 40, use the contents of the reinsurance database to estimate the reinsurance claun or premium, and store it m memory and/or reinsurance database. The program may display a value of the estimated reinsurance claim or premium on display screen 154. A user may view the display of the estimated reinsurance claun or premium on display screen 154, and may interactively make modifications, additions, and deletions to the estimated reinsurance claun or premium. Computer system 150 may also mclude one or more user mput devices, such as a keyboard 156, for entering data and commands mto the reinsurance transaction-processing program. It may also mclude one or more cursor control devices 158 such as a mouse for usmg a cursor to modify a reinsurance claim viewed on display screen 154. In response to the updating of the estimated reinsurance claun, the reinsurance transaction-processing program may store the updated remsurance claun m the reinsurance database. In one embodiment, the rule definitions, object properties, transaction values, etc. may be constructed and stored during the configuration of the RC system 150. Configuration of the RC system 150 may occur at the time the RC system software program(s) and database(s) are initially installed and set up for processmg RC transactions. Configuration of the RC system 150 may also occur after the initial configuration, which may be performed during the installation of the RC system. A configuration of the RC system that occurs after the initial configuration may be called a reconfiguration of the RC system During reconfiguration, the rule definitions, object properties, transaction values, etc. defined or configured during the initial configuration may be modified or deleted, and new rule definitions, object properties, transaction values, etc. may be added to the RC system 10. Some data may be processed differently m the RC system after a reconfiguration of the RC system than before the reconfiguration. For example, a busmess rule may be defined usmg a different rule structure after a reconfiguration. Thus the resulting algonthm computation returned to a calling program may be different than before the reconfiguration. In one embodiment, the reinsurance transaction processmg system may provide context-sensitive help for the processmg steps. In one embodiment, the context-sensitive help for the step may be automatically mvoked and displayed on display screen 154 when entering the step. In one embodiment, the user may interactively mvoke context-sensitive help for the step by selecting one or more mterface items on the display screen 154 with a cursor control device 158 such as a mouse. In one embodiment, the user may interactively mvoke context-sensitive help for the step by usmg an mput device 156 For example, the user may select one or more keys or a combination of keys on a keyboard to activate context-sensitive help. The context-sensitive help for each processmg step may be unique, although content may appear m the context-sensitive help for two or more processmg steps. In one embodiment, information for the context sensitive help may be accessed from help database, mcluded m database. Help database may mclude one or more one or more documents mcludmg information that may be useful to a user m performing the vanous processmg steps associated with reinsurance transaction processmg. Help database may also mclude one or more tables that provide access to the information m the documents. Each table may mclude a plurality of records or entnes that may be used to locate help information about processmg steps and or the elements m processmg steps m the one or more documents m the help database In one embodiment, a search mterface may be provided m the reinsurance transaction processmg system 150. A user may enter m the search mterface one or more terms to be searched for m help database, mcluded m database for the reinsurance transaction processmg system 150. The user may then initiate the search for the one or more terms. The reinsurance transaction processmg system may then search the help database for entnes mcludmg at least one of the one or more terms. The reinsurance transaction processmg system may locate one or more entnes m the help database that include at least one of the one or more terms. The reinsurance transaction processmg system may then display information on display screen 154 from the located help database entnes. Figure 2: A Distributed Computing Environment Figure 2 illustrates a distπbuted or enterprise computing environment accordmg to one embodiment. A distπbuted computer system or enterprise 100 may mclude a plurality of computer systems, which are interconnected through one or more networks Although one particular embodiment is shown m Figure 2, the distnbuted computer system 100 may mclude a vaπety of heterogeneous computer systems and networks which are interconnected m a vaπety of ways and which run a vanety of software applications and/or operating system software. One or more local area networks (LANs) 104 may be mcluded m the enterpnse 100. A LAN 104 is a network that spans a relatively small area. Typically, a LAN 104 is confined to a smgle building or group of buildings. Each node (ι.e., individual computer system or device) on a LAN 104 preferably has its own CPU with which it executes programs, and each node is also able to access data and devices anywhere on the LAN 104. The LAN 104 thus allows many users to share devices (e.g., printers) as well as data stored on file servers. The LAN 104 may be characterized by any of a vaπety of types of topology (i.e., the geometnc arrangement of devices on the network), of protocols (i.e., the rules and encoding specifications for sending data, and whether the network uses a peer-to-peer or client/server architecture), and of media (e.g., twisted-pair wire, coaxial cables, fiber optic cables, radio waves). As illustrated in Figure 2, the distπbuted computer system 100 may mclude one LAN 104. However, m alternate configurations the distnbuted computer system 100 may mclude a plurality of LANs 104 which are coupled to one another through a wide area network (WAN) 102. A WAN 102 is a network that spans a relatively large geographical area. Each LAN 104 includes a plurality of interconnected computer systems and optionally one or more other devices: for example, one or more workstations 110a, one or more personal computers 112a, one or more laptop or notebook computer systems 114, one or more server computer systems 116, and one or more network printers 118 As illustrated m Figure 2, an example LAN 104 may mclude one of each of computer systems 110a, 112a, 114, and 116, and one printer 118 The LAN 104 may be coupled to other computer systems and/or other devices and/or other LANs 104 through a WAN 102. One or more mainframe computer systems 120 may be coupled to the distπbuted computer system 100 As shown m Figure 2, the mainframe 120 may be coupled to the distπbuted computer system 100 through the WAN 102, but alternatively one or more mainframes 120 may be coupled to the distnbuted computer system 100 through one or more LANs 104. As shown, the mainframe 120 may be coupled to a storage device or file server 124 and mainframe terminals 122a, 122b, and 122c. The mainframe terminals 122a, 122b, and 122c may access data stored m the storage device or file server 124 coupled to or mcluded m the mainframe computer system 120. The distnbuted computer system 100 may also mclude one or more computer systems, which are connected to the distnbuted computer system 100 through the WAN 102: as illustrated, a workstation 110b and a personal computer 112b. In other words, the enterpnse 100 may optionally mclude one or more computer systems, which are not coupled to the distnbuted computer system 100 through a LAN 104. For example, the distnbuted computer system 100 may mclude computer systems, which are geographically remote and connected to the distnbuted computer system 100 through the Internet In one embodiment, the enterpnse or distnbuted computer system 100 mcludes one or more computer systems configured for reinsurance transaction processmg and or developmg reinsurance administration systems The one or more computer systems for reinsurance transaction processmg systems may be typical computer systems 150 as illustrated m Figure 1. Figure 3a is one embodiment of reinsurance transaction processing software using object-oriented technology The reinsurance software program may, m one embodiment, be implemented by usmg an object-onented technology. The object-onented technology may mclude, but not be limited to, an object-onented analysis and design, an object-onented language and an object-onented repository or a database. In one embodiment, the reinsurance software program may be implemented by usmg a legacy programmmg language, such as C. The object- onented programs may mteract with legacy code programs, and vice versa, to process remsurance transactions. In one embodiment, an object-onented program may generate a new software module wntten m legacy code such as C. Java™, Smalltalk and C++ are a few examples of object-onented programmmg languages. In an object- onented programmmg language, data and related methods can be grouped together or encapsulated to form an entity known as an object. The object is the fundamental building block of object-onented programmmg. The data structures within an object may alternately be refened to as the object's state, its properties, its attributes, its fields, or its vanables. In the Java™ Language, the data structures are normally refened to as the vanables of the object. In the Smalltalk object-oriented programmmg language, the data structures may be normally refened to as the properties of the object. The procedures that operate on the vanables are refened to in Java™ and Smalltalk as the methods of the object. The list of methods, associated with the object, may also be refened to as the list of operations. Unlike traditional programmmg, m object-onented programmmg the operations on the variables may only be performed via the methods of the object. The properties and methods of an object may all be refened to as the members of the object. Examples of a few methods that may be used when associated with a reinsurance busmess object, may mclude but not be limited to: a method for creating (setting up) a new busmess (reinsurance policy), a method for renewing (new insurance peπod) a busmess, a method for registering a new claim agamst a busmess, a method for entermg technical bookmg items (premium, claun, commission) agamst one or more busmess(es), a method for registering a remittance (payment) against a busmess partner, etc, etc. In object-onented programmmg, the grouping together of the properties and methods within an object is refened to as encapsulation When the properties relating to an object and the methods that might affect the object are encapsulated within the object, other entities usually do not have direct access to these data and procedures. The other entities instead call on the object itself to mvoke its own methods and thereby operate on its own data The encapsulation of the members of the object thereby provides some protection for the data within the object and prevents unauthorized, unwanted, or unintended manipulation of the data. This is sometimes refened to as data hiding. (The concept of data hiding through encapsulation should be distinguished from the hidmg of properties m Java™ vaπable declarations, as explamed m more detail below.) In the Java™ language, if a user wants to hide the data within an object, the vaπable that contains the data is made pπvate. Pπvate properties within an object may only be accessed by the methods of the object. Because it may, m some cases, be mconvement or impractical to require manipulation of certain data through the methods of the associated object, some properties may be made public These public properties are directly accessible to entities other than the object with which the properties are associated Thus, m practice, the properties within objects normally mclude some that are hidden or inaccessible and some that are public. In the Smalltalk language, properties are always pπvate. However, one can achieve the effect of a public property by providmg a so-called "getter" and "setter" method for this property. These methods then allow (indirect) access to the property from entities other than the object with which the property is associated. All objects m an object-onented programmmg system belong to a class, which can be thought of as a category of like objects, which descnbes the charactenstics of those objects. Each object is created as an instance of the class by a program. The objects may therefore be said to have been instantiated from the class. The class sets out properties and methods for objects that belong to that class. The definition of the class does not itself create any objects. The class may define initial values for its properties, and the class normally defines the methods associated with the class (i.e., mcludes the program code which is executed when a method is mvoked.) The class may thereby provide all of the program code that will be used by objects m the class, hence maximizing re-use of code, which is shared by objects m the class. Figure 3a represents one embodiment of an remsurance object class and an instance of the object class, where the software to create object classes and instances of an object class are mcluded m the reinsurance transaction processmg software 30. Illustrated m Figure 3a, is one embodiment of a customer object class 300 and the creation of an instance 350 of the customer object class i.e., a customer object 300a. The customer class 300 may mclude a class identifier or a name 320, such as customer 321. The customer class 300 may also mclude one or more properties 330 such as name 331, date of birth 332, sex 333, address 334, phone number 335, occupation 336, policy number 337, etc. The customer class 300 may also mclude one or more methods 340 associated with the class 300 such as calculate_age 341, rating_factor 342, accident history 343, etc. For example, the calculate_age method 341, when mvoked, may calculate the cunent age of a customer. The method may return an argument containing the applicant's age. Creating an instance 350 of the customer class 300 may create a customer object 300a. Specific properties 330a associated with the instantiated object 300a, such as object ID = John_Doe 321a, name = John Doe 331a, sex = M 333a, etc. may be configured. Additional examples of object classes may mclude a busmess class, a remsurance contract class, a remsurance policy class, a reinsurance claim class, etc. As another example, a busmess rule may be defined as a class. In most object-onented languages, classes may be hierarchical That is, some classes may be subclasses of a higher class, also known as a superclass. In the Java™ language, the subclass is said to extend the superclass. Alternatively, the superclass is said to be extended by the subclass For the purposes of this disclosure, a subclass is considered to extend all or any of the classes that are above it in the hierarchy. It may also be said that the subclass directly extends the class immediately above it m the hierarchy, and indirectly extends higher classes in the hierarchy. For example, if a parent class is extended by a first subclass and that subclass is m turn extended by a second subclass, the second subclass can be said to extend the parent class as well as the first subclass. Problem solvmg may be accomplished by sendmg message(s) to objects. A message may name a method and may optionally mclude other arguments associated with the method When a message is sent to an object, the method is looked up m the object's class to find out how to perform that operation on the given object. If the method is not defined for the object's class, it may be looked for m its superclass and so on up the class hierarchy until it is found or there is no higher superclass. Message sends may return a result object, which may be an eπor, as m the case where no superclass defines the requested method The hierarchical definition of classes and subclasses based on shared properties and methods is very useful. A subclass includes all the properties and methods in the class of which it is a member (its parent class). The subclass is said to inherit the properties and methods of its parent class. This property is useful in defining subclasses because only those properties and methods that do not appear in the parent class need to be defined in the subclass (although properties or methods which appear in the parent class may be redefined in the subclass.) This allows the code written in the parent classes to be re-used so that the programmer does not have to rewrite or cut and paste code into each new subclass. Methods that are defined in the parent class may, however, be redefined in subclasses. This is refened to as overriding or hiding the previously defined method(s). In Smalltalk, for example, when a class A has a subclass B which overrides a method x defined A, then, when the message x is sent to an instance of class B, class B's implementation of method x will be used. As used herein, A, then, when the message x is sent to an instance of class B, class B's implementation of method x will be used. In some object-oriented languages, by redefining a variable that has already been defined in a superclass, the programmer may hide the previously defined variable (which is distinct from the object-oriented data hiding concept inherent in encapsulation.) In some object-oriented languages, subclasses may inherit properties and methods from several classes. This is called multiple inheritance. If a subclass can only inherit from one parent class, this is called single inheritance. Inheritance may also be dynamic and or shared. Specifically, dynamic inheritance refers to the ability to add, delete, or change parents from objects (or classes) at run-time. Multiple inheritance brings up the possibility for a class to appear as a parent more than once in a class graph (shared or repeated inheritance), and there is then a potential to share that class. The Java™ and Smalltalk languages are characterized by single inheritance, not multiple. Hierarchical class structure also allows the programmer to take advantage of a property refened to as polymorphism. Polymorphism is a mechanism by which various objects may be handled in the same way externally, even though there are differences in the way they are handled internally. In other words, the interface that the different objects present to an external entity is the same for each object, but the details of each object's implementation may vary. This allows objects instantiated from different subclasses to be handled identically even though the subclasses are not identical. For example, assume that a drawing program implements a class for shapes, a subclass for circles, and a subclass for squares, each of which has a method called draw(). While draw() will be implemented differently for the circle subclass and the square subclass, the drawing program does not have to know the details of how a shape will be drawn, or even which of the shapes is to be drawn. The drawing program simply calls the draw() method for the object to be drawn and the implementation defined in the object's class will be used. Figure 3b: Layered Architecture of the Reinsurance Administration System Figure 3b illustrates a layered architecture of a reinsurance administration system according to one embodiment. The reinsurance administration system may include multiple layers or levels. As shown in Figure 3b, the reinsurance administration system may include five layers: an interface layer 302, a business process layer 322, a domain layer 342, a persistency layer 362, and a relational database 382. Each layer may include objects that collaborate in solving the specific responsibilities of the layer. As used herein, an "object" is a unit of functionality that may include both data and methods for operating on the data. In one embodiment, the interface layer 302 may include objects, which are responsible for presenting data to the user or to another system. The objects of the interface layer 302 may be responsible for providing input to the business process layer 322. For example, the interface layer 302 may include objects such as one or more graphical user mterface (GUI) objects 304, one or more world wide web (WWW) objects 306, and one or more electronic data interchange (EDI) objects 308. In one embodiment, the busmess process layer 322 may mclude objects, which are responsible for executing the steps of a logical unit of work. For example, a logical unit of work may mclude executing validation, committing a transaction, and rolling back a transaction. The busmess process layer 322 may mclude objects such as one or more busmess process objects 324, one or more secunty objects 326, and one or more validation objects 328. A busmess process object may be responsible for user access pnvileges or other secuπty issues, obtaining or generating domam data, validation of domam data, and addmg, modifying, and deleting data held by a database. In one embodiment, busmess processes are coordinators and do not generally implement the actual code, which performs basic tasks. The actual code may be implemented m domam objects 344 or m support processes, which are created and used by a busmess process. In one embodiment, the domam layer 342 may mclude objects, which are responsible for holdmg application data and implementing basic busmess functionality. For example, the domam layer 342 may mclude objects such as domam objects 344 and helper objects 346. The domam objects 344 and helper objects 346 may collaborate to provide a concrete representation or definition of the busmess objects 324. The objects m the domam layer may implement reinsurance functionality without reference to implementation details such as persistency and user interfaces. In one embodiment, the persistency layer 362 may mclude objects, which are responsible for enabling communication between the domam layer 342 and the relational database 382. For example, the persistency layer 362 may convert domam objects to rows in the relational tables, may provide an object caching mechanism, and may manage memory transactions. The persistency layer 362 may mclude objects such as one or more objects for transaction handling 364, one or more objects for database access 366, one or more objects for object cachmg 368, and one or more objects for database mapping 370. In one embodiment, the relational database 382 may mclude one or more database tables 384. The relational database may commumcate with the persistency layer 362 through the Open Database Connectivity (ODBC) standard for database access. In one embodiment, the database 382 may be any database which is ODBC- compliant. The database tables 384 may store objects from the other layers m a persistent form Figure 4: Development of a Reinsurance Administration System Figure 4 is an illustration of a development process for developmg a reinsurance administration system according to one embodiment The reinsurance administration system may be developed with software tools such as compilers, object-onented development environments, and other suitable tools. In one embodiment, a Smalltalk development environment may be used. The development process may re-use program code for mcreased efficiency, reduced development time, and reduced cost In step 402, functional requirements may be defined The results of step 402 may mclude at least one use case 404 and a data dictionary 406. As used herem, a "use case" may define a particular busmess function or grouping of busmess functions In other words, use cases may conespond to busmess requirements for the reinsurance admmistration system. In one embodiment, the reinsurance administration system may mclude use cases for "basic" or "support" data such as a reference data administration use case, a system parameter admmistration use case, a secunty admmistration use case, a cunency admmistration use case, a reporting unit admmistration use case, a nsk zone admmistration use case, and a location administration use case. Use cases may also assist a user of the reinsurance admmistration system in carrying out his or her daily work. For example, these use cases may mclude a use case for creating or setting up a new busmess (e.g., a reinsurance policy), a use case for renewmg a busmess (e.g., a new msurance penod), a use case for registering a new claim against a busmess, a use case for entermg technical bookmg items (e.g., premium, claim, commission) agamst one or more busmess(es), and a use case for registering a remittance (i.e., payment) agamst a busmess partner. In step 412, prototyping and GUI design may be performed. The results of step 412 may mclude graphical user interfaces (GUIs) 414 and at least one prototype 416. A prototype may be a demonstration program that may not mclude the complete functionality of the final version of the program, but rather may demonstrate the capabilities planned for the final version. In step 422, modelmg may take place. Step 422 may produce a domam model 424 and a busmess process model 426. The domam model 424 and/or busmess process model 426 may embody one or more use cases as developed in step 402. In step 432, application parts may be implemented and tested. The results of step 432 may mclude at least one new application part 434 An application part may be one or more new parts 434 or a combination of such parts The application part 434 may be placed m a parts inventory 436 with other application parts. The application parts m the parts inventory may be used and re-used to build one or more application programs In one embodiment, the system for developmg a remsurance admmistration system may mclude a vaπety of design patterns and reusable parts in the parts inventory 436 For example, the system for developmg a reinsurance admmistration system may include a general pattern for building "Fmd..." components (e.g., Fmd Busmess, Fmd Busmess Partner, Fmd Clauns, etc.), domam class mediators (for retπevmg items such as cunencies, countnes, states, country groups, etc.), and/or a general pattern for integrating new busmess condition components within the busmess structure. The system for developmg a reinsurance admmistration system may also mclude reusable GUI parts such as a calendar widget for entermg dates, a select/available widget, domam object drop-down lists, and many larger-gram GUI parts that may mclude multiple basic widgets. In step 442, the parts may be assembled to build a computer-executable reinsurance admmistration system 444 Steps 402, 412, 422, 432, and 442 may be repeated a plurality of times to produce a plurality of reinsurance admmistration systems 444 The plurality of remsurance admmistration systems may mclude multiple versions of one reinsurance admmistration system 444 The design process illustrated m Figure 4 may therefore mclude the ability to extend and customize the remsurance admmistration system to accommodate new and specialized requirements. Using Frameworks to Develop a Reinsurance Administration System One or more frameworks may be utilized by a developer to build one or more reinsurance management systems. The frameworks may mclude functionality for solving general and recurring problems. Use of the frameworks dunng development may therefore decrease the time and expense associated with product development. A framework may mclude a collection of classes, which contain logic for solvmg problems that are common to a range of functional requirements To solve a specific requirement which falls within the range of requirements for which a framework was designed, a developer may create subclasses of the classes contained within a framework While the inhented properties of the classes will provide the solutions to the general aspects of the problems to be solved, the developer may implement solutions to special requirements by providing specialized code and data. The developer may add additional behavior by adding methods to the subclasses, and or by making the classes collaborate with other, specialized classes. A framework may provide general methods, called "hook" methods, that may be overridden by the developer to identify what action the system should take at a certain point. Thus, a framework may provide patterns and templates for how to solve common requirements. By doing so, a framework may permit a group of developers to avoid solving the same class of problem in different ways. For example, for most windows in a graphical user interface, a common requirement is that it must be possible to close the windows. Therefore, a common feature of most windows is a "close" button or another means for the user to close the windows. An additional requirement may be that the system should ask the user whether data changes should be saved when the user chooses to close a window. These requirements may be solved by reusable portions of a framework to avoid re-implementing the requirement for each new window. The framework may also provide a hook method that may be overridden by a developer to implement saving data changes upon the closing of a window. The frameworks in the system for developing reinsurance administration systems may include technical frameworks and industry frameworks. Generally speaking, technical frameworks may implement common, general business behavior. Technical frameworks may be reusable in a variety of types of software program applications such as reinsurance administration programs. Technical frameworks may enable developers to focus on implementing business rules. Technical frameworks may enable inexperienced developers to become productive in record time. Industry frameworks may implement common behavior and object models for a particular business area. An object model framework may abstract and encapsulate complex business structures. In one embodiment, the object model framework may capture the multiple dimensions of a contract and hide the multi-dimensional aspect of a contract from subsequent domain modeling. The multiple dimensions of a contract may include multiple reinsurance periods, multiple life cycle phases per insured period, multiple sections per life cycle phase, multiple amendments per life cycle phase, and contract conditions per section and per amendment, wherein the sections may be organized in a hierarchy, in one embodiment, a behavior framework may abstract and encapsulate business rules for managing the multiple contract dimensions into an abstract framework. A behavior framework may provide inherited functional support to core business components. A behavior framework may include support for component-based development. The frameworks may include a business process framework. As used herein, a "business process framework" may include a framework for developing business processes. As used herein, a "business process" may include a computer-based representation of a use case or business function to be performed in a line of business. The business process framework may allow developers to focus their attention on business-specific requirements, while the framework handles common, "technical" requirements. In short, the business process framework may allow a developer to quickly assemble a business process component. The business process framework may include a plurality of high-level business process classes. The high-level business process classes included in the business process framework may include default implementations for hook methods which subclasses may override. In one embodiment, a developer may create a new business process component by subclassing another business process class from an existing business process class. The many classes that together make up a reinsurance software system may be arranged in a hierarchy. At the top of the hierarchy may sits the most general, abstract business process class. This class may be subclassed by one or more other classes, some of which may be abstract. Classes which are not abstract are considered to be concrete. This process of subclassing may go on virtually indefinitely. The hierarchy of (sub)classes need not be balanced; that is, concrete classes may appear at vaπous levels. A class which has multiple subclasses may serve to capture behavior (i.e., logic) that is common to its subclasses. Unlike the concrete classes, the abstract classes are not mtended to be instantiated as objects at runtime. A busmess process class may implement its required behavior by identifying appropnate support processes for its configuration and by overndmg selected hook instance methods provided by the framework (i.e., m one embodiment, the topmost busmess process classes in the hierarchy). As used herem, "support processes" may mclude computer-based processes for performing tasks associated with a busmess process. As used herem, "hook methods" may mclude methods a parent class which provide default methods to be inhented by a child class and which may be overπdden by the child class. The busmess process framework may provide many support process methods, classes, and subclasses which may implement behavior for: precondition checks (for data requirements to start a busmess process), secunty checks (for user access to functions and data), data entry, graphical user interfaces (GUIs), data and syntax validation, persistent data storage, committing changes to a database, rolling back changes to a database, and other suitable functions. As used herem, "support processes for data validation" may mclude support processes for validating data pnor to committing the data to a database. As used herein, "support processes for secuπty" may mclude support processes for controlling the access of a user to particular busmess functions. As used herem, "support processes for persistent data storage" may mclude support processes for storing data m a database or other data storage system. As used herem, "support processes for precondition checks" may mclude support processes for determining whether a busmess process has the necessary initial data to begm its execution. As used herem, "support processes for data entry" may mclude support processes for obtaining data from a user through a user mterface, from another computer-based process on the same computer system, and/or from another computer system over a network. In one embodiment, the busmess process framework may automatically handle requirements such as, for example: opening a specified wmdow, addmg Cancel OK/Save/Help buttons to an open wmdow, providmg the behavior for buttons added to a wmdow, steppmg through the different steps or stages of the busmess process template (e.g., pre-execution, data entry, validation, pre-commit, commit, post-commit) and executing the specific logic that may be specified by a developer for each phase, performing a rollback of objects m memory upon enor or cancellation by a user, performing validation, committing changes to the database, performing wnte-lock checking, and/or loggmg and displaying enor messages Figure 5: Using a Business Process Framework Figure 5 is a flowchart illustrating the use of a busmess process framework by developers to build application programs for remsurance admmistration with mcreased re-use of existing functionality and decreased development time. In vaπous embodiments, the steps shown in Figure 5 may be performed m a different order. In one embodiment, the method may mclude denvmg or subclassmg the plurality of busmess process classes from the busmess process framework m step 502. One or more business process subclasses may be denved from one or more abstract busmess process classes, wherem the busmess process framework may mclude the one or more abstract busmess process classes. In one embodiment, busmess process subclasses may be deπved from concrete busmess process classes as well as abstract busmess process classes The busmess process framework may mclude a plurality of support processes. In step 504, one or more of the support processes may be specified for each of the busmess process subclasses. The support processes may mclude support processes for data validation, support processes for performing syntax validation, support processes for graphical user mterface elements, support processes for persistent data storage, support processes for performing precondition checks, and or support processes for other suitable functions. In one embodiment, identifying one or more of the support processes for each of the busmess process subclasses may mclude overπdmg one or more of the hook methods for each of the busmess process subclasses. The busmess process framework may mclude a plurality of hook methods. The hook methods may permit the developer to access vaπous pomts dunng the execution of the busmess process. In step 506, the developer may ovemde one or more hook methods for a busmess process subclass. By overπding the hook methods, the developer may identify methods to be performed at vanous pomts dunng execution of the busmess process. Ovemding one or more of the hook methods for each of the busmess process subclasses may mclude replacmg one or more of the hook methods deπved from the abstract busmess process classes with one or more new methods for each of the busmess process subclasses The hook methods may include, for example, methods to be executed dunng initialization of the busmess process, methods to be executed pπor to execution of a data entry support process, methods to be executed dunng execution of data entry without a user mterface, methods to be executed pnor to execution of a database commit support process, and/or methods to be executed pnor to execution of a database rollback support process. As will be apparent to one skilled in the art, many more hook methods may be available to be ovemdden by a busmess process subclass. The common functionality of the busmess process framework may mclude an order for executing steps m a busmess process. The steps m the busmess process may mclude pre-execution, data entry, data validation, pre- commit to a database, commit to the database, and post-commit to the database. These steps are further discussed with reference to Figures 6a and 6b The common functionality of the busmess process framework may mclude behavior for buttons m a graphical user mterface, formatting and displaying wmdows m a graphical user mterface, methods or vanables of the abstract busmess process classes which are inhented by the busmess process subclasses, loggmg and displaying enor messages, committing changes to a database, and/or rolling back changes to a database. In one embodiment, a first busmess process subclass may be configured to mvoke a second busmess process subclass In step 510, the busmess process subclasses may be combmed to build one or more application programs, such as application programs for remsurance admmistration The resulting application program(s) may be stored on a storage device When the resulting application program(s) are executed, busmess process objects will be instantiated from the busmess process subclasses created by the developer. Figures 6a and 6b: The Life of a Typical Business Process Figures 6a and 6b are state diagrams illustrating the life of a typical busmess process accordmg to one embodiment. In one embodiment, the busmess process framework may implement a busmess process state transition machine and control the sequencing of steps m a busmess process. A developer may ovemde hook methods to identify methods to be performed at vaπous stages m the sequence of steps m life of the busmess process. In one embodiment, when a new busmess process is created m step 602 by instantiating a busmess process object from the coπesponding class, it will execute the states shown m Figure 6a and stop m the ready state 612 These states or steps may mclude initialization 604, mstallation of a descnption 606, installation of a configuration 608, and transferal of settings from the descnption 610 The busmess process may remain indefinitely m this state until it receives an execute command Once execution starts, there are many paths, which the process can follow, and a common path is illustrated m Figure 6b. If the busmess process uses an interactive GUI mterface for the data entry, then the busmess process may proceed from the ready state 612 through to the execute data entry state 632 and remain there indefinitely until the user chooses to save, cancel, or close. The other steps or states may mclude initial execution 622, getting an edit token if required 624, performing a preconditions check 626, performing a secuπty check 628, and transferring arguments from a parent process 632 Once the user chooses to exit the data entry state 632, the busmess process may execute either a validate 633 and commit 634 or a rollback 636 and then do the finishing actions 638. In one embodiment, performing the secuπty check 628 may mclude determining whether a user has the proper access πghts to access a particular use case Support processes for access secuπty may guarantee no access secuπty, access secuπty on a busmess process level, or access secuπty with domam restπction. A support process for access secuπty on a busmess process level may determine whether the user has the access πght to execute a busmess process, wherem the busmess processes in the reinsurance admmistration system are each linked to a particular access nght. A support process for access security with domam restπction may be similar to a support process for access secuπty on a busmess process level but may also test domam restnctions for the user. As discussed with reference to Figure 5, one or more hook methods may be provided to allow the developer to access clean pomts m the execution of the business process A hooklnitialize method 652 may be executed dunng initialization of the new busmess process This method may be sent before the descnption is available and before any support processes are created A hookPreExecuteDataEntry method 654 may be executed just pπor to the execution of the data entry support process In one embodiment, if the busmess process has an associated wmdow, the wmdow will not be opened until the data entry support process is executed. In one embodiment, invocation of a child busmess process from this hook method 654 is not allowed. In one embodiment, a hookDelegatedExecuteNoDataEntry method 656 may only be used if the busmess process is configured with a CnuNoDataEntry support process and will occur dunng the execute data entry phase 632 This hook 656 is provided to allow a busmess process which operates without a user interface to perform some required processmg before the busmess process commits In one embodiment, invocation of a child busmess process from this hook method 656 is allowed In one embodiment, a hookPreExecuteCommit method 658 may be executed pπor to the execution of the commit support process 634 In one embodiment, invocation of a child busmess process from this hook method 658 is allowed. A hookPreExecuteRollback method 660 may be executed just pπor to the execution of the rollback support process 636. In one embodiment, mvocation of a child busmess process from this hook method 660 is allowed In one embodiment, a plurality of hooks may be used by the developer to modify the complex process of validation 633 Vahdation may mclude syntax vahdation of the busmess process, a domam restπction secunty test, and any additional, busmess-process-specific vahdation that the developer may have specified for the busmess process Syntax vahdation of the busmess process may itself include syntax vahdation of those domam objects the busmess process has specified m one of its hooks, such as hookCompleteSyntaxDescnptor 662 The domam restπction secuπty test may use hooks such as hookDomamObjectsToSecuntyCheckDescπptor 664 to check that the data values entered mto the domam objects) by the user are m accordance with the pnvileges stored in the user's logon profile for the reinsurance administration system The additional, busmess-process-specific vahdation may use hooks such as hookVahdationProcessClass 666 Standard Methods to Override and Standard Classes to Subclass The busmess process framework may mclude a plurality of standard methods that may be overndden and a plurality of standard classes that may be subclassed by developers Several examples are discussed as follows; as will be apparent to one skilled m the art, many more hook methods and classes may be used. A hookComπutProcessClass may provide the functionality to handle the commit and transaction allocation for a busmess process. A hookPreExecuteDataEntry method may be used to set up anything that is needed before the data processmg process is executed. A busmess process that is responsible for the creation of a new object would normally ovemde the hookPreExecuteDataEntry method in order to implement the instantiation of the new object As discussed with reference to Figure 6b, a hookValidationProcessClass, hookDomamObjectsToSecuπtyCheckDescnptor, and hookCompleteSyntaxDescπptor may provide the functionality for domg any necessary validation before any data is to be committed. In one embodiment, data will be committed only once all validation executes successfully A hookGuunterfaceSpecificationlnSession may provide the specification of what the GUI mterface is to look like. From this specification, a wmdow may be built depending on how the busmess process is used. A guiInterfaceWindowLabel may return a string label to use to place on the wmdow that may be scheduled for the busmess process. A hookGuiInterfaceClass may hold all of the functionality that is GUI-specific to how a busmess process is handled Functions such as sorting lists and converting a radio button mto a domam value may be handled by an instance of this class. In one embodiment, for example, any dynamic label of a wmdow label would be handled here. Figure 7a: Illustrates One Embodiment of an Inheritance View of a Hierarchy of Business Objects and Figure 7b: Illustrates One Embodiment of an Inheritance View of a Section Object A typical remsurance contract may mclude, but not be limited to, several attπbutes such as an insured peπod, i.e., a peπod representmg the term of the reinsurance contract, contract conditions, insurance coverage, partners, amendments, premiums, etc. Each attribute may vary independently of the other attπbutes. Thus a reinsurance contract may be viewed to have multiple dimensions dependmg on the number of independent vaπable attπbutes mcluded in the reinsurance contract. For example, the multiple dimensions of a contract may mclude multiple remsurance periods, multiple life cycle phases per insured peπod, multiple amendments per life cycle phase, etc. In one embodiment, the reinsurance transaction processmg software may mclude an object-onented framework, the multi-dimensional remsurance contract framework. In one embodiment, the multi-dimensional remsurance contract framework may permit the handling of the four dimensions of a reinsurance contract. For example, the first dimension may handle different versions of the remsurance contract (e.g., yearly penods). The second dimension may handle multi-level specialization hierarchy (e.g., different conditions for different sections of the remsurance contract) The third dimension may handle the change of conditions within a peπod, potentially only for one section and the fourth dimension may process inheπtance of contract structure and conditions vertically from a parent section to a child section and/or horizontally from a section of one remsurance contract to the same section m another, linked reinsurance contract This framework may use an object model to capture the four dimensions and hide the multi-dimensionality from subsequent domam modelmg and the design of additional reinsurance contract components This framework may also encapsulate busmess rules for managing the four reinsurance contract dimensions mto an abstract framework In one embodiment, the reinsurance transaction processmg software may mclude an object-onented framework to process one or more remsurance business transactions. The object-onented framework 5010 may mclude a collection of classes of objects. In one embodiment, an entire reinsurance busmess transaction or a part thereof may be represented as a contract class. A contract object 536 may be created by instantiating a contract class. In one embodiment, a contract class may be a concrete subclass of a hierarchy of contract classes. The concrete subclass may capture special properties and methods for a specific level of busmess. In one embodiment, a user may configure customized methods and properties associated with the specific level of busmess. Examples of the level of busmess may include assumed busmess, outward cedent's contract, own retention, etc. The remsurance contract object 536 may represent one remsurance contract, including all terms and conditions, all history and all attributes associated with the contract. The reinsurance contract object 536 may mclude properties and methods associated with the reinsurance contract. Examples of properties associated with the remsurance contract object 536 may mclude, but not limited to, reinsurance peπod, life cycle phase per insured peπod, section(s) per life cycle phase, amendment(s) per life cycle phase, contract conditions per section and per amendment. In one embodiment, an insured peπod object 550 may be created by instantiating an insured peπod class. In one embodiment, an insured peπod class may be a concrete subclass of a hierarchy of insured peπod classes. The concrete subclass may capture special properties and methods for a specific level of busmess. If the insured penod is yearly then it may be also refened to as the underwriting year. In one embodiment, the insured penod object 550 may own all terms and conditions, all history and all of its child objects for one calendar penod of the remsurance contract. In one embodiment, a life cycle phase object 552 may be created by instantiating a life cycle phase class. In one embodiment, a life cycle phase class may be a concrete subclass of a hierarchy of life cycle phase classes. Typical life cycle phases mcluded m a remsurance contract may mclude new agreement offered, offer accepted, offer declmed, new quote requested, renewal offered, etc. In one embodiment, the life cycle phase object 552 may own all terms and conditions, all history and all child objects for one phase of one calendar penod of the remsurance contract In one embodiment, a section object 554 may be created by instantiating a section class. In one embodiment, a section class may be a concrete subclass of a hierarchy of section classes. Sections may be organized m a hierarchy. The highest-level section object 554 may also be refened to as the mam or root section 701a m Figure 7b. The root section object 554 may have zero or more child section 702a objects. Each child section object 702a may have zero or more sub-child section objects. Each section object 554 may have a classification 703a with one or more categorization values. Typical categories 704a are mam class of busmess, class of busmess, πsk area country, type of participation, etc. Typical categorization values 705a are casualty, workmen's compensation, aviation, marine, marine hull, marine machinery, etc. The classification of a child section 702a must be a subset of the classification of its parent section. In one embodiment, the section object 554 may own all terms and conditions, all history and all child objects for one section of one phase of one calendar peπod of the reinsurance contract. In one embodiment, an amendment object 560 may be created by instantiating an amendment class. In one embodiment, an amendment class may be a concrete subclass of a hierarchy of amendment classes. In one embodiment, the amendment class may mclude an abstract class and two concrete subclasses of the abstract class The first amendment concrete subclass may be used to define the initial terms and conditions. The second amendment concrete subclass may be used to amend one or more conditions within the insured peπod Amendments may be shared amongst all life cycle phases within an insured peπod. In one embodiment, when a condition, e.g., a premium condition, is amended, the insured period gets divided into a set of non-overlapping effective periods that together make up the insured period. In one embodiment, conditions such as premium, limit, deduction, share, etc. may be amended. Section classification and protection may also be amended. Examples of protection, which may be amended, may include treaty, faculty, proportional/non-proportional protection assignments, retrocession contracts, own retention, etc. In one embodiment, the remsurance transaction processing software may include an object-onented framework, the condition component framework. This framework, i.e., the condition component framework, may permit the addition and or modification of condition components of the remsurance contract. These components may compπse, for example, premium limits, consolidation conditions, and other conditions for reinsurance contracts. In one embodiment, the components may be implemented as reusable objects. In one embodiment, the remsurance framework 5010 may mclude one or more classes that represent contract properties that may be shared. An inheritable object 570 may be created by instantiating an inheritable class. Each inheritable object may have a parent or an owning section. In addition, each inheritable object may be connected to zero or more other sections in inherited or shared mode. Inheπtance may be vertical or horizontal. Vertical inhentance means mheπting from a parent section. Horizontal inheπtance means inheπting from the same section in another, linked reinsurance contract. An inheritable object may be read/viewed both from the context of its owning section and its inheritor sections. An inheritable object may only be edited in the context of its owning section. Examples of shared inheritable objects include a condition object 572, a protection object 592, and a section classification object 582. Figures 8a through 8d - Illustrates One Embodiment of a Graphical User Interface for Processing a Reinsurance Business Transaction A typical reinsurance busmess transaction may mclude, but not be limited to, submitting a quotation for a reinsurance policy, calculatmg a premium associated with a reinsurance policy, issumg a contract for a reinsurance policy, processing a claim, etc. A reinsurance contract may be one embodiment of a reinsurance transaction. A typical reinsurance contract may mclude, but not be limited to, several attπbutes such as an insured peπod, i.e., a period representing the term of the remsurance contract, contract conditions, msurance coverage, partners, amendments, premiums, etc. Each attribute may vary independently of the other attributes. Thus a reinsurance contract may be viewed to have multiple dimensions depending on the number of independent variable attπbutes included in the reinsurance contract. For example, the multiple dimensions of a contract may include multiple reinsurance periods, multiple life cycle phases per insured period, multiple amendments per life cycle phase, etc. In one embodiment, the reinsurance transaction processmg software may include an object-onented framework to process all remsurance busmess transactions. In one embodiment, the graphical user mterface software included in the remsurance transaction processmg software may use objects to manage vanous user interface functions. The ob j ect-onented framework may mclude several classes of objects. In one embodiment, an entire remsurance business transaction or a part thereof may be represented as a remsurance contract object. In one embodiment, the reinsurance transaction processing computer system may include a display screen 154, a user input device such as a keyboard 156 and a graphical user mterface software to interact with the user. Figures 8a through 8d illustrate one embodiment of a display mcluded in a graphical user mterface to manage reinsurance busmess transactions. In one embodiment, the management of a remsurance busmess transaction may mclude the management of a reinsurance contract. Examples of displays used to manage remsurance contracts may mclude, but not be limited to, configuration displays to define initial terms and conditions, displays to modify or amend the contract, displays to compute premiums, tune periods, etc. In one embodiment, a display may be defined as a display class and specific display objects may be created as instances of the display classes. Display Layout In one embodiment, a display or a window may include one or more wmdow panels 804 and a navigational tool 802. In one embodiment, a wmdow panel may occupy a portion of the display screen or an entire display screen. The wmdow panel, which may be also refened to as a window or a panel, may be opened, closed, minimized, maximized, moved, resized, etc. The one or more windows, which may be ananged m a tiled or overlapping manner, may display data 806 associated with the remsurance contract. In one embodiment, the arrangement and/or size of each wmdow may be defined by the user or may be defaulted to a fixed layout by the remsurance system software. In one embodiment, each window may display data associated with the methods and or the properties of an object handled by the reinsurance system software, mcludmg a reinsurance contract object. Some or all of the data displayed may be modifiable by the user. In one embodiment, modifiable data 806 may be displayed on a white background. In one embodiment, non-modifiable data may be displayed on a gray background. In one embodiment, the navigational tool 802 may provide one or more user mterface items 808 such as icons, buttons, pull down menus, etc. to enable the user in navigating through vanous displays. In one embodiment, all graphical user mterface functions accomplished by using the user interface items may also be accomplished by usmg special function keys on a keyboard 156, by a top level pull-down menu, etc. The navigational tool 802, m one embodiment, may mclude one or more tool panels 802a, 802b and 802c. In one embodiment, the position of the navigational tool may remain fixed regardless of the other windows included m the display. Each of the one or more tool panels 802a, 802b and 802c may provide navigational tools associated with displaying a particular reinsurance contract function. For example in one embodiment, a tool panel 802c may include up/down and or left/nght anow buttons 802cb and an associated display field 802ca to assist the user in navigatmg through a section hierarchy. On selecting up/down and or left/πght anow 802cb, the value displayed in the associated display field 802ca may change accordmg to the user selection. If during the navigation process, the user has already reached at the top of a hierarchy then the tool panel 802c, which mcludes the up button 802cb, may be partially disabled or displayed in a lighter color In one embodiment, the mterface item or items may be provided to the user to navigate within a display, for example, to select vaπous ranges for a variable displayed within a tool panel 802. Interface items may be items displayed graphically on the wmdow panel 804 and/or the tool panel 802 portion of the screen (for example, as icons or buttons) and may be selectable usmg input output devices such as a mouse 158, joystick, or anow keys on a keyboard 156. Interface items 808 may also be keyboard selections such as function keys or key combmations For example, a button may be provided that allows the user to scroll down the list of valid entnes m a pull-down menu The navigational tool 802 may be configurable m one embodiment Each of the mterface items 808 such as a button with an icon may represent a particular graphical user mterface function. For example, the user may click on a particular button or icon mcluded in the navigational tool 802 to navigate to a particular display. In one embodiment, clicking of an mterface item 808 mav initiate an action such as performing a calculation, printing of a report, etc. The user may configure the particular tool button by linking the click action to executing a particular graphical user mterface function. In one embodiment, the graphical user interface may mclude a hierarchy of displays related to a reinsurance contract. In one embodiment, by entering a reinsurance contract number mto the display screen the user may access an mitial contract display. In one embodiment, the remsurance software may automatically display a list of all available contracts as the mitial display. The mitial display may represent the highest-level display within the hierarchy of displays. The navigational tool 802 may display the user mterface items 808 to enable the user to select any dimension of the contract. In one embodiment, the dimensions of the remsurance contract may mclude, but not be limited to, an msured peπod 802b, a life cycle phase, a section 802c, an amendment, and inhentable conditions, section classification and protection. In one embodiment, each of the display mcluded m the hierarchy of displays may descπbe a dimension of the remsurance contract. In one embodiment, a user may initiate a business transaction to modify a downstream section, i.e., not the root or the mam busmess section, to an existing reinsurance contract On entermg a valid contract number the mitial display, e.g., a first wmdow, may be displayed on the screen. The user may click on a down arrow 802cb from the section tool panel 802c mcluded m the navigational tool 802, e g select a first mterface item. In response, a second wmdow may be displayed which may include data on the downstream or the child section, i.e., display downstream section data consistent with the user selected down anow input. An authorized user may modify the modifiable data 806 displayed m the second wmdow and on completing the modifications may click on a back anow 802aa mcluded m the tool panel 802a, e.g. selecting the second interface item, to return to the first wmdow. Vanous embodiments may further include receiving or storing instructions and/or data implemented m accordance with the foregoing descnption upon a earner medium Suitable earner media mclude memory media or storage media such as magnetic or optical media, e.g., disk or CD-ROM, as well as signals or transmission media such as electπcal, electromagnetic, optical or digital signals, conveyed via a communication medium such as networks and or a wireless link. Although the system and method of the present invention have been descnbed m connection with several embodiments, the mvention is not mtended to be limited to the specific forms set forth herem, but on the contrary, it is mtended to cover such alternatives, modifications, and equivalents as can be reasonably mcluded within the spiπt and scope of the mvention as defined by the appended claims

Claims: WHAT IS CLAIMED IS: 1. A earner medium compπsmg program instructions for developmg a remsurance admmistration system, wherem the program instructions are computer-executable to implement a method of: denvmg one or more busmess processes from a business process framework, wherem the busmess process framework compnses common functionality for the one or more busmess processes, and wherem the busmess process framework compnses a plurality of support processes and a plurality of hook methods; identifying one or more of the support processes for each of the busmess processes; combining the busmess processes to build one or more application programs for reinsurance admmistration 2. The earner medium of claun 1, wherein the program instructions are further computer-executable to implement overnding one or more of the hook methods for each of the business processes to access stages m an execution of the busmess process 3 The earner medium of claim 2, wherem denvmg the plurality of business processes from the busmess process framework further compnses denvmg one or more busmess process subclasses from one or more abstract busmess process classes, wherem the busmess process framework comprises the one or more abstract busmess process classes; wherem overπdmg one or more of the hook methods further comprises replacmg one or more of the hook methods inhented from the abstract busmess process classes with one or more new methods. 4. The earner medium of claim 1 , wherem one of the hook methods comprises a method to be executed dunng initialization of one or more of the busmess processes 5 The earner medium of claim 1 , wherem one of the hook methods comprises a method to be executed pnor to execution of a data entry support process 6 The earner medium of claim 1 , wherem one of the hook methods comprises a method to be executed dunng execution of data entry without a user mterface 7 The earner medium of claim 1 , wherem one of the hook methods comprises a method to be executed pnor to execution of a database commit support process 8. The earner medium of claim 1 , wherem one of the hook methods compnses a method to be executed pπor to execution of a database rollback support process. 9. The earner medium of claim 1, wherem one of the hook methods compnses a method to be executed dunng validation of data. 10. The earner medium of claim 1 , wherem denvmg the plurality of business processes from the busmess process framework further compnses denvmg one or more busmess process subclasses from one or more abstract busmess process classes, wherem the busmess process framework compnses the one or more abstract business process classes. 11. The earner medium of claun 1 , wherem identifying one or more of the support processes for each of the busmess processes further compnses ovemdmg one or more of the hook methods for each of the business processes. 12. The earner medium of claim 1 , wherem the busmess process framework further comprises a template for executing the busmess processes. 13. The earner medium of claim 1 , wherem the support processes further comprise support processes for performing precondition checks. 14. The earner medium of claim 1 , wherem the support processes further comprise support processes for performing syntax validation. 15. The earner medium of claim 1 , wherem the support processes further compnse support processes for a graphical user mterface. 16. The earner medium of claun 1 , wherem the support processes for security further comprise a support process for controlling access to a use case as a function of an access right of a user 17. The earner medium of claim 1 , wherem the common functionality of the business process framework compnses behavior for buttons m a graphical user mterface 18. The earner medium of claim 1 , wherem the common functionality of the busmess process framework compnses functionality for formatting and displaying wmdows in a graphical user mterface 19. The earner medium of claim 1 , wherem the common functionality of the busmess process framework compnses methods of abstract busmess process classes which are inherited by business process subclasses. 20. The earner medium of claim 1 , wherem the common functionality of the business process framework compnses an order for executing steps m the busmess processes. 21. The earner medium of claim 20, wherem the steps comprise pre-execution, data entry, data validation, pre-commission, commission, and post-commission. 22. The earner medium of claim 1, wherem the common functionality of the business process framework compnses functionality for loggmg and displaying enor messages. 23. The earner medium of claim 1 , wherem the common functionality of the business process framework compnses functionality for committing changes to a database. 24. The earner medium of claim 1. wherein the program instructions are further computer-executable to implement: configuring a first busmess process to invoke a second business process. 25. The earner medium of claim 1, wherein the program instructions are further computer-executable to implement: storing the one or more application programs on a storage device. 26. The earner medium of claim 1 , wherem the earner medium comprises a memory medium. 27. The earner medium of claim 1 , wherem the earner medium comprises a transmission medium. 28. A method for developmg a reinsurance administration system, the method compnsmg: denvmg one or more business processes from a business process framework, wherem the busmess process framework compnses common functionality for the one or more busmess processes, and wherem the busmess process framework compnses a plurality of support processes and a plurality of hook methods; identifying one or more of the support processes for each of the busmess processes; combining the busmess processes to build one or more application programs for remsurance admmistration. 29. The method of claim 28, further compnsmg ovemdmg one or more of the hook methods for each of the busmess processes to access stages m an execution of the busmess process 30. The method of claun 29, wherem denvmg the plurality of busmess processes from the busmess process framework further compnses denvmg one or more busmess process subclasses from one or more abstract busmess process classes, wherem the busmess process framework comprises the one or more abstract business process classes; wherem ovemdmg one or more of the hook methods further compnses replacmg one or more of the hook methods inhented from the abstract busmess process classes with one or more new methods. 31. The method of claun 28, wherem one of the hook methods comprises a method to be executed dunng initialization of one or more of the busmess processes 32 The method of claim 28, wherem one of the hook methods comprises a method to be executed prior to execution of a data entry support process. 33. The method of claun 28, wherem one of the hook methods comprises a method to be executed dunng execution of data entry without a user mterface. 34. The method of claim 28, wherem one of the hook methods comprises a method to be executed pnor to execution of a database commit support process 35. The method of claim 28, wherem one of the hook methods comprises a method to be executed pnor to execution of a database rollback support process 36. The method of claun 28, wherem one of the hook methods comprises a method to be executed dunng validation of data 37 The method of claun 28, wherem denvmg the plurality of busmess processes from the busmess process framework further compnses denvmg one or more business process subclasses from one or more abstract busmess process classes, wherem the busmess process framework comprises the one or more abstract busmess process classes 38. The method of claim 28, wherem identifying one or more of the support processes for each of the busmess processes further compnses ovemdmg one or more of the hook methods for each of the busmess processes. 39. The method of claim 28, wherem the busmess process framework further compnses a template for executing the busmess processes. 40. The method of claim 28, wherem the support processes further comprise support processes for performing precondition checks. 41. The method of claun 28, wherem the support processes further comprise support processes for performing syntax validation. 42. The method of claim 28, wherem the support processes further comprise support processes for a graphical user mterface. 43. The method of claim 28, wherem the support processes for security further comprise a support process for controlling access to a use case as a function of an access right of a user 44. The method of claun 28, wherem the common functionality of the business process framework compnses behavior for buttons m a graphical user mterface. 45 The method of claim 28, wherem the common functionality of the business process framework compnses functionality for formatting and displaying windows in a graphical user interface 46 The method of claim 28, wherem the common functionality of the busmess process framework compnses methods of abstract busmess process classes which are inherited by business process subclasses 47. The method of claim 28 , wherem the common functionality of the busmess process framework compnses an order for executing steps m the busmess processes 48 The method of claim 47, wherem the steps comprise pre-execution, data entry, data validation, pre-commission, commission, and post-commission 49. The method of claim 28, wherem the common functionality of the busmess process framework compnses functionality for loggmg and displaying enor messages. 50. The method of claim 28, wherem the common functionality of the business process framework compnses functionality for committing changes to a database. 51. The method of claim 28, further compnsmg: configuring a first business process to invoke a second business process. 52. The method of claim 28, further comprising. storing the one or more application programs on a storage device. 53. A system for developmg a reinsurance admmistration system, the system compnsmg: a busmess process framework, wherein the busmess process framework compnses a plurality of hook methods, one or more abstract business process classes, and a plurality of support processes; a plurality of busmess process subclasses derived from the abstract busmess process classes of the busmess process framework, wherem at least one of the busmess process subclasses specifies one or more of the support processes, wherem at least one of the business process subclasses ovemdes one or more of the hook methods, and wherem the busmess process subclasses are configurable to build a computer-executable program for reinsurance admmistration. 54. The system of claim 53, wherem the business process framework comprises common functionality for the plurality of busmess process subclasses, wherein the common tunctionahty of the business process framework compnses methods of the one or more abstract business process classes which are inherited by the one or more busmess process subclasses 55 The system of claim 54, wherem the common functionality further compnses functionality for a graphical user mterface. 56. The system of claim 54, wherem the common functionality further comprises functionality for loggmg and displaying enor messages. 57. The system of claim 54, wherem the common functionality further comprises an order for executing steps m busmess process objects instantiated from the business process subclasses 58. The system of claim 57, wherem the steps compnse pre-execution, data entry, data validation, pre-commission, commission, and post-commission. 59. The earner medium of claun 1 , wherem the support processes comprise support processes for data validation. 60. The earner medium of claim 1 , wherem the support processes comprise support processes for security. 61. The earner medium of claim 1 , wherem the support processes comprise support processes for persistent data storage. 62. The method of claim 28, wherem the support processes comprise support processes for data validation. 63. The method of claim 28, wherem the support processes comprise support processes for secuπty. 64. The method of claun 28, wherem the support processes comprise support processes for persistent data storage. 65. The system of claim 53, wherein the support processes comprise support processes for data validation. 66. The system of claim 53, wherem the support processes comprise support processes for security 67. The system of claim 53, wherem the support processes comprise support processes for persistent data storage. 68. A earner medium comprising program instructions for defining a multi-dimensional remsurance contract, wherem the program instructions are computer-executable to implement a method of idenhfymg a reinsurance contract class of objects to represent the remsurance contract, wherem the remsurance contract comprises one or more dimensions; creating an mstance of the remsurance contract class of objects to identify a remsurance contract object; configurmg one or more properties and one or more methods of the remsurance contract object consistent with the reinsurance contract dimensions to define the reinsurance contract. 69. The earner medium of claim 68, wherein each of the one or more dimensions of the reinsurance contract is represented as a subclass of objects to the reinsurance contract class of objects. 70. The earner medium of claim 69, wherem the subclass of objects is instantiated to create one or more component objects, wherem each of the component objects is a child to the reinsurance contract object, wherem each of the component objects represents a dimension of the one or more dimensions of the reinsurance contract 71. The earner medium of claim 68, wherein a first dimension of the one or more dimensions is an insured peπod, wherem an insured period object descnbes the msured period. 72. The earner medium of claim 68, wherein a second dimension of the one or more dimensions is a life cycle phase, wherem a life cycle phase object describes the life cycle phase. 73. The earner medium of claim 68, wherein a third dimension of the one or more dimensions is a condition, wherem a condition object describes the condition. 74. The earner medium of claim 68, wherein the reinsurance contract object compnses one or more insured peπod objects, wherein each insured period object identifies a particular time period dunng which a particular remsurance contract remains in effect 75. The earner medium of claim 74, wherein each msured period object comprises one or more life cycle phase objects, wherem each life cycle phase object identifies a particular phase in a life cycle of the particular reinsurance contract dunng the particular time period 76. The earner medium of claim 75, wherein each life cycle phase object compnses one or more section objects, wherem the one or more section objects are ananged in a hierarchy starting with a mam section object, wherem the mam section object comprises children section objects. 77. The earner medium ot claim 75, wherein each life cycle phase object comprises one or more amendment objects, wherem the one or more amendment objects are operable to amend one or more condition objects, wherem the one or more amendment objects are shared amongst the one or more life cycle phase objects within the particular tune period 78. The earner medium of claim 68, wherein the reinsurance busmess object compnses one or more uihentable objects, wherein each inheritable object is owned by a section object, wherem each inheπtable object is operable to inherit or share a method or a property from another section object 79. The earner medium of claim 78, wherein the inheritable object comprises a condition object. 80. The earner medium of claim 79, wherein the condition object is amended in context of a section object 81. The earner medium of claim 79, wherein the condition object is connected to other section objects, wherem the condition object inherits properties from the connected other section objects 82. The earner medium of claim 78, wherem the one or more inheritable objects compnses a protection object 83. The earner medium of claim 78. wherein the one or more inhentable objects compnses a section classification object. 84. The earner medium of claim 79, wherem the condition object describes a premium limit condition. 85. The earner medium of claim 79, wherem the condition object describes a share percentage condition. 86. The earner medium of claim 79, wherein the condition object describes a deduction condition. 87. The earner medium of claim 82, wherein the protection object comprises a proportional protection assignment object or a non-proportional protection assignment object 88. The earner medium of claim 83. wherein the section classification object describes a country, a mam class of busmess and a class of business associated with the reinsurance contract 89. The earner medium of claim 68, wherein the program instructions are further computer-executable to implement: storing the defined reinsurance contract in memory 90. The earner medium of claim 68, wherem the earner medium comprises a memory medium 91. The earner medium of claim 68, wherem the earner medium comprises a transmission medium 92 A method for defining a multi-dimensional remsurance contract, wherein the method compnses: identifying a reinsurance contract class of objects to represent the remsurance contract, wherem the remsurance contract comprises one or more dimensions, creating an mstance of the reinsurance contract class of objects to identify a remsurance contract object, configuring one or more properties and one or more methods of the remsurance contract object consistent with the remsurance contract dimensions to define the reinsurance contract 93 The method of claim 92. wherein each of the one or more dimensions of the reinsurance contract is represented as a subclass of objects to the reinsurance contract class of objects 94 The method of claim 93 wherein the subclass of objects is instantiated to create one or more component objects, wherem each of the component objects is a child to the reinsurance contract object wherem each of the component objects represents a dimension of the one or more dimensions of the remsurance contract. 95. The method of claim 92, wherem a first dimension of the one or more dimensions is an insured penod, wherem an insured period object describes the msured penod 96. The method of claim 92, wherein a second dimension of the one or more dimensions is a life cycle phase, wherem a life cycle phase object describes the life cycle phase. 97. The method of claim 92, wherein a thud dimension of the one or more dimensions is a condition, wherem a condition object describes the condition 98. The method of claim 92, wherein the remsurance contract object compnses one or more insured peπod objects, wherem each msured period object identifies a particular time period dunng which a particular reinsurance contract remains in effect 99. The method of claim 98 wherein each msured period object compnses one or more life cycle phase objects, wherem each life cycle phase object identifies a particular phase in a life cycle of the particular reinsurance contract dunng the particular time period 100. The method of claim 99, wherein each life cycle phase object comprises one or more section objects, wherem the one or more section objects are ananged in a hierarchy starting with a mam section object, wherem the mam section object comprises children section objects. 101. The method of claim 99, wherein each life cycle phase object comprises one or more amendment objects, wherem the one or more amendment objects are operable to amend one or more condition objects, wherem the one or more amendment objects are shared amongst the one or more life cycle phase objects within the particular time penod. 102 The method of claim 92 wherein the reinsurance busmess object compnses one or more inhentable objects, wherem each inheritable object is owned by a section object, wherein each inhentable object is operable to lnheπt or share a method oi a property from another section object 103. The method of claim 102, w herein the inheritable object comprises a condition object 104 The method of claim 103, wherein the condition object is amended in context of a section object 105 The method of claim 103 wherein the condition object is connected to other section objects, wherem the condition object inhents properties from the connected other section objects 106 The method of claim 102, w herein the one or more inheritable objects comprises a protection object. 107 The method of claim 102. wherein the one or more inhentable objects compnses a section classification object 108 The method of claim 103, wherein the condition object describes a premium limit condition. 109. The method of claim 103, wherein the condition object descnbes a share percentage condition. 110. The method of claim 103, wherein the condition object describes a deduction condition. 111. The method of claim 103, wherein the protection object comprises a proportional protection assignment object or a non-proportional protection assignment object. 112. The method of claim 107, wherein the section classification object descnbes a country, a mam class of busmess and a class of business associated with the reinsurance contract 113 The method of claim 92, wherein the method comprises storing the defined reinsurance contract in memory 114 A earner medium comprising program instructions for defining a multi-dimensional remsurance contract framework, wherem the program instructions are computer-executable to implement a method of. denvmg one or more business processes from a multi-dimensional reinsurance contract framework, wherem the multi-dimensional reinsurance contract framework comprises a hierarchy of dimensions associated with a reinsurance contract, wherein each of the dimensions describes an attribute of the reinsurance contract; configurmg the one or more business processes to identify each dimension, combmmg the business processes to build a customized reinsurance contract for reinsurance admmistration. 115. A system for reinsurance transaction processing, comprising a remsurance contract framework, a multi-dimensional reinsurance contract framework, a remsurance contract object derived from the reinsurance contract framework, one or more insured peπod objects derived from the multi-dimensional remsurance contract framework, wherem each insured peπod object is a child of the reinsurance contract object, one or more life cycle phase objects derived from the multi-dimensional reinsurance contract framework, wherem each life cycle phase object is a child of one of the insured period objects, one or more amendment objects derived from the multi-dimensional reinsurance contract framework, wherem each amendment object is a child of one of the life cycle phase objects, one or more section objects derived from the multi-dimensional reinsurance contract framework, wherem at least one section object is a child of one of the life cycle phase objects, and wherem the remsurance contract object is configurable for remsurance transaction processmg. 116 The system of claim 1 15, further comprising a computer system to execute the reinsurance contract framework and the multi-dimensional reinsurance contract framework 117 The system of claim 116 wherein the computer system comprises a display device coupled to the computer system to display data 118 The system of claim 117 wherein the display device is a display screen 119 The system of claim 116, wherem the computer system comprises a user mput device coupled to the computer system to enter data 120 The system of claim 119, wherein the user input device is a mouse or a keyboard 121 A earner medium comprising program instructions for amending one or more conditions of a reinsurance contract, wherem the program instructions are computer-executable to implement a method of identifying an inheritable class of objects to represent the one or more conditions of a remsurance contract, wherem the remsurance contract is represented by an remsurance contract object, wherem the reinsurance contract object is a parent of a section object, creating an mstance of the inheritable class of objects to identify a condition object, wherem the condition object is a child of the section object configurmg properties and methods of the condition object consistent with the remsurance contract to define an amended reinsurance contract 122 The earner medium of claim 121, wherein the condition object is amended m context of the section object 123 The earner medium of claim 121, wherein the condition object is connected to other section objects, wherem the condition object inherits properties from the connected other section objects 124 The earner medium of claim 121 wherein the class of inheritable objects compnses a protection class 125 The earner medium of claim 121 wherein the class of inheritable objects comprises a section classification class 126 The earner medium of claim 121 wherein the condition object describes a premium limit condition 127 The earner medium of claim 121 wherein the condition object describes a share percentage condition 128 The earner medium of claim 121 wherein the condition object describes a deduction condition 129 The earner medium of claim 121 wherein configuring the properties and the methods of the condition object consistent with the reinsurance contract comprises idenhfymg a new condition of the inheritable object class, wherein the one or more conditions excludes the new condition, identifying a new subclass of objects to the remsurance contract class of objects, creating a new component object by instantiating the new subclass of objects, wherem the new component object is a child object to the remsurance contract object. 130. The earner medium of claim 124, wherein the protection class comprises a proportional protection assignment subclass or a non-proportional protection assignment subclass. 131. The earner medium of claim 125, wherein the section classification class compnses properties, wherem the properties descnbe a country, a main class of business and a class of business associated with the section classification class. 132. The earner medium of claim 121, wherein the program instructions are further computer-executable to implement: storing the one amended insurance contract in memory. 133. The earner medium of claim 121. wherem the carrier medium comprises a memory medium. 134. The earner medium of claim 121, wherem the earner medium comprises a transmission medium. 135. A method comprising program instructions for amending one or more conditions of a remsurance contract, wherem the method comprises identifying an inheritable class of objects to represent the one or more conditions of a remsurance contract, wherem the remsurance contract is represented by an reinsurance contract object, wherem the remsurance contract object is a parent of a section object, creating an instance of the inheritable class of objects to identify a condition object, wherem the condition object is a child of the section object, configuπng properties and methods of the condition object consistent with the remsurance contract to define an amended reinsurance contract 136. The method of claim 135, wherein the condition object is amended in context of the section object. 137. The method of claim 135, wherein the condition object is connected to other section objects, wherem the condition object inherits properties fiom the connected other section objects 138. The method of claim 135. wherein the class of inheritable objects comprises a protection class. 139. The method of claim 135. wherein the class of inheritable objects comprises a section classification class. 140 The method of claim 135. wherein the condition object describes a premium limit condition. 141. The method of claim 135. wherein the condition object describes a share percentage condition. 142. The method of claim 135, wherein the condition object describes a deduction condition. 143. The method of claim 135. wherein configuring the properties and the methods of the condition object consistent with the reinsurance contract comprises: identifying a new condition of the inheritable object class, wherein the one or more conditions excludes the new condition; identifying a new subclass of objects to the reinsurance conttact class of objects; creating a new component object by instantiating the new subclass of objects, wherem the new component object is a child object to the remsurance contract object. 144. The method of claim 13S, wherein the protection class comprises a proportional protection assignment subclass or a non-proportional protection assignment subclass. 145. The method of claim 139. wherein the section classification class comprises properties, wherein the properties describe a country, a main class of business and a class of business associated with the section classification class. 146. The method of claim 135, wherein the method further comprises: storing the one amended insurance contract in memory. 147. A system for reinsurance transaction processing, comprising: a reinsurance contract framework, a multi-dimensional reinsurance contract framework; a condition component framework; a remsurance contract object derived from the reinsurance contract framework; one or more insured peπod objects derived from the multi-dimensional remsurance contract framework, wherem each insured period object is a child of the reinsurance contract object; one or more life cycle phase objects derived from the multi-dimensional remsurance contract framework, wherein each life cycle phase object is a child of one of the insured period objects; one or more amendment objects derived from the multi-dimensional reinsurance contract framework, wherem each amendment object is a child of one of the life cycle phase objects; one or more section objects derived from the multi-dimensional reinsurance contract framework, wherein at least one section object is a child of one of the life cycle phase objects, one or more condition objects derived from the condition component framework, wherem at least one condition object is a child of one of the section objects; and wherem the one or more condition objects are configurable for the remsurance transaction processing. 148. The system of claim 147. furthei compnsmg a computer system to execute the reinsurance contract framework, the multi-dimensional remsurance contract framework and the condition component framework. 149. The system of claim 148, wherein the computer system comprises a display device coupled to the computer system to display data 150. The system of claim 149, w herein the display device is a display screen 151. The system of claim 148, w herein the computer system comprises a user mput device coupled to the computer system to enter data 152. The system of claim 151. w herein the user input device is a mouse or a keyboard. 153. A earner medium comprising program instructions for a graphical user mterface, wherem the program instructions are computer-executable to implement a method of displaying a first window comprising one or more window panels and a navigational tool, wherem the navigation tool comprises one or more tool panels, wherein each of the one or more tool panels or each of the one or more wmdow panels comprises one or moie interface items for receiving user mputs, wherem the one or more wmdow panels and the one or moie tool panels display data associated with one or more properties and one or more methods of a remsurance contract object, receiving a selection for a first mtei face item, displaying a second window in response to receiving the selection for the first mterface item, wherem the second wmdow comprises one oi more second window panels and the navigational tool, wherem the second wmdow panels and the one or moie tool panels display data consistent with receiving the selection for the first mterface item; receivmg a selection for a second interface item to return to the first window; and wherem a hierarchy of windows comprises the first and second window and wherem the hierarchy of wmdows provides the graphical usei interlace to process a reinsurance business transaction 154. The earner medium of claim 153, wherein the first interface item is an icon 155. The earner medium of claim 153, wherein the first interface item is a button. 156. The carrier medium of claim 153, wherein the reinsurance contract object is configurable to process the reinsurance busmess transaction 157. The earner medium of claim 153, wherein the reinsurance business transaction is a reinsurance contract transaction. 158 The earner medium of claim 153. wherein the reinsurance contract object compnses one or more msured penod objects, wherein each insured period object identifies a particular time period during which a particular remsurance contract remains in effect 159. The earner medium of claim 158. wherem each msured period object comprises one or more life cycle phase objects, wherein each life cycle phase object identifies a particular phase in a life cycle of the particular reinsurance contract during the particular time period. 160. The earner medium of claim 159. wherein each life cycle phase object compnses one or more section objects, wherein the one or more section objects are ananged in a hierarchy starting with a main section, wherem each section object comprises children section objects. 161. The earner medium of claim 159, wherein each life cycle phase object comprises one or more amendment objects, wherein the one oi more amendment objects are operable to amend one or more condition objects, wherein the one or more amendment objects are shared amongst the one or more life cycle phase objects within the particular time peπod. 162. The earner medium of claim 160, wherein each of the one or more section objects compnses one or more inheritable objects, wherein each inheritable object is owned by a section object, wherem each inheritable object is operable to inherit or share a method or a property from another section object. 163. The earner medium of claim 153, wherein the one or more window panels and the navigational tool are tiled together. 164. The earner medium of claim 153, wherein the one or more window panels and the navigational tool are non-overlapping. 165. The earner medium of claim 153, wherein the one or more window panels are user configurable for their size and their shape 166. A earner medium comprising program instructions for developing a remsurance administration system, wherem the program instructions arc computer-executable to implement a method of: deriving one or more business processes from a business process framework; identifying one or more of the support processes for each of the busmess processes. 167. A method for developmg a reinsurance administration system, the method comprising: denvmg one or more business processes from a business process framework; identifying one or more of the support processes for each of the busmess processes. 168. A system for developing a reinsurance administration system, the system compnsmg: a busmess process framework, one or more business process subclasses derived from the business process framework, wherem at least one of the business process subclasses specifies one or more support processes 169. A earner medium comprising program instructions tor defining a multi-dimensional reinsurance contract, wherem the program instructions are computer-executable to implement a method of: identifying a remsurance contract object to represent a remsurance contract havmg one or more dimensions; configurmg the one or more dimensions of reinsurance contract object to define the remsurance contract. 170. A method for defining a multi-dimensional reinsurance contract, the method compnsmg: identifying a lemsurance contract object to represent a reinsurance contract havmg one or more dimensions; configuring the one or more dimensions of reinsurance contract object to define the reinsurance contract. 171. A system for reinsurance transaction processing, comprising- a multi-dimensional reinsurance contract framework, a multi-dimensional reinsuiance contract object derived from the multi-dimensional remsurance contract framework; wherem the multi-dimensional reinsurance contract object is configurable for remsurance transaction processmg. 172. A earner medium comprising program instructions for amending one or more conditions of a reinsurance contract, wherem the program instructions are computer-executable to implement a method of: identifying a condition object to represent the one or more conditions of a remsurance contract; configuring the condition object to define an amended reinsurance contract 173. A method for amending one or moie conditions of a remsurance contract, the method compnsmg: identifying a condition object to represent the one or more conditions of a reinsurance contract; configurmg the condition object to define an amended reinsurance contract 174 A system for reinsurance transaction processing, comprising a remsurance conn act fiamework, a condition component framew ork a reinsurance contract object deπved from the reinsurance contract framework, one or more condition objects derived from the condition component framework, wherem the one or more condition objects are configurable to amend the reinsurance contract object

Inventors: CLEMETSEN TORMOD, EVENSHAUG BJORNAR, SVERDRUP-THYGESON HARALD, WEBER PETER, CLEMETSEN, TORMOD, EVENSHAUG, BJORNAR, SVERDRUP-THYGESON, HARALD, WEBER, PETER
Applicants: SCIENCES CORP COMP, COMPUTER SCIENCES CORPORATION
Application year: 2000
Main classification: G06F9
IPC codes: G06F9