OOPSLA 2001 DesignFest®
TaskThe Viking is the name of a Direct Marketing system. The
requirements to this system are available as (written) scenarios or simple
stories, each assigned with a priority. You can find the full material
In brief: The Viking system supports campaigns to sell products to
customers. The customers are contacted via letters. The letters are
personalized for each customer based on a template for a particular campaign.
The customers have sets of interests w.r.t. the products. The previous
sellings are used both for selecting and addressing cutomers. Criteria
for selecting and personalizing are required to be very flexible.
The task of the DesingFest team is to develop a design documentation as
a prerequisite for the CodeFest team that wants to implement the system
during the following days.
The Viking DesignFest Team
Jill M. Aden;
Eagan, MN, U.S.
Timothy R. Platt;
Tampa, FL, U.S.
Hasselt, Belgium - Moderator
Ilmenau, Germany - Recorder
ExperienceAll of our team brought in a strong experience in
object-oriented design and development. Additional skills were such as
eXtreme Programming, teaching OO methods, Client/Server systems, project
management, Design Patterns and different OO modeling methods.
ExpectationsTo introduce our team to you, we tell you something
about our own expectations to this DesignFest event:
We expected to
get to know each other, to work as a team and to develop a nice design
solution together. During this work we expected to learn more about the
design ideas and the design process of others. And, of course,
we expected to have fun during this day.
Our team: Jill, Tim, Matt ....
.... and Hein
Our 'Process'After the short introduction and a discussion about our
expectations we defined our procedure:
1. Analysis of the classes
Design of the static structure
3. Design of the behaviour of the system
4. Documentation of results
Due to the limited time (we had the whole
Sunday from 9 am to 5 pm) we decided to keep the design (and the system)
as simple as possible. We agreed to consider the priorities of the
requirements - eventually we would cut some things off.
Our 'Method'After beeing acquainted with the requirements we defined
our 'methodology' for designing and documenting. We made a mixture
CRC, the popular Class Responibility Collaboration Scheme,
and of the UML class diagram. We used CRC for analizing and for
expressing behavioural aspects. The UML notation was used for expressing the
static structure, and especially the relations and multiplicities between
entities - with the Entity Relationsship Modeling ERM in mind.
ResultsOur major design decisions:
uncomplete requirements we had to make some assumptions:
- the classes (see below),
- something 'magic' to enable flexibility for selecting and personalizing:
the use of XML expressions (with existing solutions for defining and
evaluating XML in mind to simplify implementation)
Have a look at our products:
- the volume of letters to customers is low or moderate
- letters consist just of text, no graphics
- for Story 4: the search criteria is not associated with the template.
- the class diagram
with type information
- system sceleton (generated by Together/J):
|Looking back, we worked in a quite concentrated way and produced
results in a form our CodeFest team could work with - hopefully. We had
very interesting discussions. Even if we tried to prevent discussions
about 'philosophy' - in the end this was the most interesting
aspect for us: to get to know other's way of thinking, other's mixture
of design methods.
Our Lessons Learned list:
- Requirements are inconsistent
- we should have a customer to talk to
- the use of CRC was a good decision
- mixing methodologies works well - enabling adaptation to specifics
of the project and to team skills
- we should have had a stronger contact to the CodeFest
Finding the right expression.
We had a lot of fun during DesignFest,
and we stayed in contact during the
rest of OOPSLA 2001. Our advice to you: Try it out yourself!
last changed Dec 6th, 2001, Matt