Managing Enrollment Policies for Insurance Plans

OOPSLA 2001 DesignFest® Problem

The DesignFest Team

Jay Coskey
Ralf Reissing - moderator
Leif Rilbe - recorder
Sanjay Shitole
Judy Zeitler

The Result

The models we produced are here.

The Process

We introduced ourselves briefly. Each participant received a copy of the problem statement. We proceeded to read the problem statement individually. One participant wrote down candidate classes on sticky notes during the reading.

Evolving the Analysis Model

After the reading, we proceeded by spreading out the candidate classes (the sticky notes) on a large sheet of paper. We talked briefly aobut each candidate class so as to make sure everyone in the group had the same understanding of what they represented.

The initial list  of candidate classes look something like this (I didn't think of recording this list at that point in time, so it might be not completely accurate):

At this stage we talked with the domain expert (i.e. the author of the problem statement). We then found some additional candidates, and changed the names of some candidates in order to reflect the terminology used by the domain expert.

After this the list of candidates looked something like this:

At some point we also introduced a few new classes not directly present in the problem statement:

The rationale for the Profile classes had mostly to do with the cost calculations for different benefits. In order to support new costing schemes, with possibly new bases for calculations, there must be a specific place in the model where such new calculation bases can be introduced wihtout too much disruption. The Profile classes provide this specific place.

Now we played around a little bit with our candidate classes trying to figure out what this problem was really all about. Basically we did this by trying to figure out how the classes related to eachother, association names and cardinalities. There were two main sets of issues:

  1. how to represent the possible choices that could be made by different participants (i.e. the agreement between the customer and the insrurance company)
  2. how to represent the choices actually made by each participant (i.e. the agreement between the participant and the insurance company)
At this point it seemed that we had some problems with the Benefit and Option classes. When they were used for representing the participant choices, they had a cardinality of one or more per participant. When they were used for representing the possible choices, they really should only exist once, regardless of the number of participants (since the Benefits and Options are agreed upon between the insurance company and the customer, well before the first participant ever enters into the system.). We resolved this by dividing each of these classes into two separate ones1. We also did this for the Work/Life Event class. Thus:

After this we were rather confident about our class associations and proceeded to draw a these on out large sheet of paper. We only considered the names and cardinalities of the associations (much like the conceptual perspective mentioned in "UML Distilled", by Martin Fowler).

We now went on to think about how the different use cases could be implemented with our identified classes. Each team member was assigned two use cases. We took some time to read through the assigned use cases and think identify how the main responsibilities could be divided among our identified classes. Then we presented this to the other team members verbally. This worked out without any major holes being identified and so we felt pretty content that our analysis-level model was ok.

Getting to Design

Having reached a pretty stable analysis model, we started to look more closely into the more central issues on a more detailed level. We did this by examining use cases 3-9 which all deal with participants managing their elections. The most complex problem here was the rules that  govern how participants may change their election after different work/life events occurr. This also opens issues to with how and when to enforce these rules.

Here we made a few general decisions/observations:

Team Experiences

At the end of the session, we made a short reflection brainstorm. Issues that came up:

Recorder's Reflections