DesignLab '96

Automation: A Flexible Manufacturing System

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.


The Problem

We worked on the Factory Automation problem.


Results Presented in the Team Poster

The team took about 15 minutes to first define a development process that would aid in budgeting the already short design time.

Development Process Chosen by the Team

  1. Read the requirements and discuss issues with the customer
  2. Identify the participants
  3. Define the static relationships*
    • classes and associations
    • static model diagram
  4. Use cases / dynamic relationships defined*
    • dynamic model diagram / interaction diagrams
  5. Document the work

* There were iterative cycles used between steps 3 and 4

Requirements Understanding Task

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:

Identifying the Participants and the Static Diagram

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.

Use Case #1 Interaction Diagram

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.

Use Case #2 Interaction 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.

Documentation Manufacturing

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.

Post Mortem

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.


Team Reflections

  1. Did the process work for us?
    • Unanimous YES!
  2. What part of the process failed us more than any other?
    • During the requirements analysis trying to identify the participants, our team got stuck on trying to identify where the data elements for the system need to go. The team got hung up on the database due to confusion about the context of the problem. We had a problem in that we never defined an architecture for the system and based our thought on a physical model presented by the customer. The database turned out to be a red herring that we treated as a fudge area and deferred the database details to a later point of the design. OO provided us the ability to abstract the issue of the database until later in the design process.
  3. What external to the process worked for us?
    • Management (moderator & recorder) kept the group focused
    • Management was not involved in the design
    • The team used small groups to decompose sub-problems of already agreed on use cases
    • We scoped out much of the flexibility
    • We skirted about the issues dealing with the hierarchy
    • We ended up doing more AnalysisFest instead of DesignFest®
  4. What external to the process failed for us?
    • The air conditioning in the room did not work, but the heat did!
    • Tooling
      • The flip chart pages were not as flexible as a white board would have been when making changes to a drawing
      • It was difficult to layout the drawings first on paper


Reflections of the Moderator

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


Design Team


Report prepared by Bradford G. Van Treuren on November 11, 1996.