Recognition of Business Patterns

Our analysis was heavy on composition and subtyping. The use cases in analysis were documented with pre-state, post-state, and invarients. As we transitioned to design, we created the two-tier object model allocating data and persistence to the lower tier and making the upper tier a composition of the lower tier. The lower tier consisted of generalized objects that could be mapped to by most any application (ex. party, agreement, task). The relationships between objects were standardized and were generally handled by an association object. The subtype structure (reflected in code) was made very shallow by having each object relate to a "type" object that maintained a hierarchial type structure. The net result was a lower tier structure that exhibited clear patterns for data access, navigation, and persistence.

The upper tier reflected objects that would normally be found in the insurance business. For example, Person, Organization, and Household in the upper tier all related to Party in the lower tier. InsuranceApplication, Policy, and Coverage in the upper tier all related to Agreement in the lower tier. Objects in the upper tier contained only two attributes; their own key and the key of the lower tier object they related to. All data access and all navigation was done by eventual delegation(s) to the lower tier. The upper level used OO style subtyping and inheritance. Method overriding and specialization were used heavily.

As interaction diagrams were flushed out, method call patterns were identified and abstracted out. Later, as performance was considered, caching and data grouping schemes were employed. These represented even more patterns. By the end of the effort we were no longer "discovering" patterns, we were using the patterns as our basic building blocks for design and development.