A Viking Solution

Problem Description

Experiences recored by Per Kjeldaas:

Started reading the problem, and introduced ourselves. Ghica has extensive experience in OO, UML, Java. She suggested we first go through the process, then leave 1/2 hour at the end for writing up the 2 posters.

We then decided on the classes, and created a static class diagram. Determined that we'd postpone the discussion of the Rule issues, as it was complex and Use Case number 6 had the low priority 9. Decided to use the Property Container Design Pattern for the Pluggable Information that was owned by Customer. This interface supports getPropertyBy(String) and setProperty(String, value), which is implemented by a Hashtable.

The CodeFest group came visiting, and said they would come back for more if they decided to code our design. (They didn't come back.) We discussed whether we needed consistency check between Templates and Pluggable Information for each Customer. Even though it would clearly be needed in a real-world application, it was not a requirement in this case. Then we created the Activity Diagrams, going by priority. We created them up through priority 5. The discussion on Activity Diagrams took quite a bit of time.

A documented assumption is that the default Mailing System is used for each customer unless the User chooses a different one. Another documented assumption is that the Formatter's work is an implementation issue.

This was a good learning experience for us (or at least for me.)

Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.