Order Matcher Design Session Report, Team 9


The Problem

The group met for a half-day on Tuesday (the third day of the conference) and worked on Stock Exchange Order Matcher problem.


The Team

The team consisted of four designers, a moderator and a recorder.

The group happened to be very homogenous in the sense that everybody were even-tempered and were listening very appreciatively to each other's ideas. The moderator was not only making sure that the group was making progress, but was also participating in the process of design. The people in the group met for the first time at the DesignFest® session. They felt that it would have been useful to meet informally beforehand, just to get to know each other a little.

The Process

In the beginning of the session each designer was given a copy of the problem description and the group took about an hour to read the document through. At one point the moderator wanted everybody to stop and start the analysis, but the majority of the group preferred to carry on with reading for a while longer. Although it worked out well for this particular group to take time in the beginning of the design session to read the problem description, it might be good to hand out the problems to the designers the night before the session, so that everybody can take as much time as they want to get acquainted with it. The Order Matcher problem appeared to be quite complicated even in the simplified version that described the process of matching bid and sell orders at a stock exchange according to certain rules, and of executing trades once the match was made.

In the beginning of the analysis the group came up with a list of questions to the domain expert to clarify some issues they had with the problem. Among important priorities of the design there was one particular requirement the domain expert was very keen on being addressed (stop trading) and he was able to have the group pay special attention to it when answering the group's questions. The analysis discussion was quite a gratifying experience because everybody in the group were very involved. The group spent appropriate amount of time doing it - just enough to understand the problem for the purposes of the limited design they could come up with in such a short time.

The design part started with enumerating the objects that might be included in the model and just listing them on the board. Not all of them made it to the final version of the design. Everybody agreed that they would like to try working with CRC cards, since no-one in the group had tried that before. What ended up happening was that the Moderator was writing down on the cards according to the suggestions that were coming from the group. As someone at the DesignFest Panel pointed out later, they ended up being rather C cards, than CR cards - there hardly were any responsibilities written down on them, although the responsibilities were discussed in some details. The group then used the cards creating a class collaboration diagram of sorts by arranging the cards on the table in respect to how they were supposed to interact with each other.

Objects discussed as candidates for the design

The group also came up with the list of patterns used in the design, which was probably partly influenced by the fact that the moderator was Ralph Johnson. In fact he was the one who suggested doing it. The suggestion was met with enthusiasm, and since all the participants were comfortable with design patterns, the group used the pattern language throughout the session to communicate ideas very efficiently. It was one of the greatest experiences of this design session to realize how efficient design patterns may be, not only for solving problems but also for communicating ideas to one's fellow designers..

Patterns Used

There was another team working on the Order Matcher problem at the same time. About two thirds of the time into the session the teams went to peek at each other's design. Both sides seemed to be impressed with the design of the others and also with the fact that they were quite close in ideas.

The moderator then suggested to divide the team into two groups: one dealing with drawing object model and the other working on an algorithm for the matching rule. Somewhere along the line the Recorder became involved in the design process and ended up participating in working on the matching rule algorithm, so this report does not describe the process of drawing the object model. The notes for the algorithm were written using SmallTalk notation, since that seems to be Ralph's language of choice. It appeared, that the three people who worked on the object model were more interested in the conceptual design and how it addressed the problem as a whole, while those who worked on the algorithm, were also interested in working out the details.

Class Diagram

class diagram

'Fudge' Areas of the design

In the last 15 minutes the group discussed which issues of the problem were not addressed. There was one point in the problem description that the group was supposed to be addressing as part of the design (the performance implications of the design). Characteristically, the moderator suggested to deal with it in the end of the session, and it ended up one of those "fudge" areas that "we did not have time to deal with". The other, not unpredictable "fudge" area was documentation and that was probably partly the fault of the recorder, who got so involved in the design discussion that was forgetting to write things down, although the main ideas were after all put down on paper.

Conclusion

The DesignFest was a very satisfactory experience and would be highly recommended to both very experienced and not so experienced software designers. After comparing half-day and full-day teams' results during the panel it was felt that no matter how much time one has for designing object models, about half time into it one realizes that one is only done with analysis of the problem and still has to come up with the actual design.


Report prepared by Elena Volynskaya.