At OOPSLA '96 two different types of designers came together to test their OO skills. The first set of designers came prepared with the problem statement known to them prior to attending the Design Fest Workshop. The second set of designers only knew the category to which they would be designing (e.g., Automation). Another experiment was made this year that was not attempted last year. Some of the design groups met for a full day on Sunday, October 6, 1996 to work on the problem. The remaining design teams met only for a half day on Tuesday, October 8, 1996 to work on the same problems the first team had. Assisting each small design team were the problem author, a moderator, and a recorder.
This page reports the results for the only design team working on the Automation problem. The team met for the half day session and had no advance knowledge of the problem.
We worked on the Factory Automation problem.
The team took about 15 minutes to first define a development process that would aid in budgeting the already short design time.
* There were iterative cycles used between steps 3 and 4
The team spent about an hour reading the requirements document and asking questions to the customer to clarify any unclear or open issues about the problem statement. As an artifact from this task the team diagramed the physical layout of a typical production cell described by the problem statement. This diagram is shown below:
The team then proceeded to identify the participants in the problem domain and identify the static relationships with each. We first created a sheet for every major player and identified each of the attributes corresponding to that player. We later transferred this knowledged to the static diagram shown below. The time taken to create a draft of the static and dynamic diagrams took about 1.5 hours.
Concurrently with the static analysis/design, the team began to document the flow of the use cases found within the requirements document. Once we had a clear enough static model to move on, the team broke up into two smaller sub-teams that each tackled a different use case. The following diagram represents the information found for the first use case. There are also two exception cases described on this same diagram.
The interaction diagram showing the loading of a machine from a parts bin is depicted in the diagram shown below. The sub-team working on this problem was done before the other sub-team. This sub-team moved on to the Documentation Manufacturing 10 minutes early.
Once we completed the draft diagrams we were comfortable with we created new diagrams that would be used for the poster session. The time spent was about 15 minutes.
The remaining time the team had was spent on analyzing the experience and recording our comments for others to share in our experience. The next major section describes what we found.
As the moderator, I was charged with the task of guiding the group in the process, but definitely not in the content of the design. My role was to help them stay focused and to keep the team from wasting time down side tracks or arguments. I accomplished my role by using the process to define milestones where the team was to be at specific times. I then kept reminding them how much time was left for particular tasks.
My team was a great team and worked well with each other. This was the first time any of them met. This made for some interesting team dynamics. I found people to be more polite in this team than in other teams I have been a part of. I also found this team more willing to compromise when necessary. Let me illustrate. The database became a problem entity that was getting out of control very quickly. There were team members that felt the information should be distributed throughout the various pieces of equipment that were responsible for the information. Others felt that the Cell control computer needed to have a centralized repository for the information due to time constraints in requesting the information. I had to step in and summarize what I was hearing as two different design philosophies - distributed vs. centralized information. Once the team was aware of what they were talking about, one of the members realized that they could abstract out the interface for obtaining the information and continue without having to resolve the differences immediately. I'm not so sure this would have gone so smoothly in the real world.
I believe that there was a variety of skill levels on this team. There were definite experts in Design Patterns and novices as well. We never really talked much about Design Patterns during our discussions, but we were identifying concepts that were more common sense as well as published patterns. During the post-mortem, we were able to suggest various patterns that could be used. The main problem we had was that we never really got enough into the design, but were stuck on the analysis of the problem.
In reflecting on what my team accomplished in the 3.5 hours they worked together, I can say that they achieved much. I was most interested in the feedback during the panel session held later that week. Many of the full day teams felt they accomplished just as much as the half day teams because they did not manage their time as well. My team stayed very focused on the issues. I did not have to scold too much.
I am very proud of this team and was happy to serve them. I would encourage anyone interested in learning more about OO Design to participate next year.Bradford G. Van Treuren, Automation Team Moderator