Extending CRC cards into a complete design process

• Authors: Kathleen Arnold Gray;Mark Guzdial;Spencer Rugaber
• Venue: Proceedings of the 8th annual conference on Innovation and technology in computer science education
• Year: 2003

Ectropic Design is a feature-oriented, collaborative design method, patterned on Open Source software development. Software evolves ectropically through the continuous augmentation of its features, which are bound to specific program goals. These evolving features are defined in terms of the end-user goals the features achieve and how the features interact, both statically and dynamically, with other features. By binding source code and collaboration technology to identified program goals, Ectropic Design provides developers with the necessary mechanisms to enhance software continuously, while maintaining the conceptual integrity of the program.Ectropic Design is taught as a part of our curriculum's Sophomore required course on Objects and Desig. In the course, we introduce students to CRC cards (Class, Responsibility, Collaborator cards) and scenarios. Traditionally, CRC cards are simply 3x5 index cards, one for each class being considered in a design, annotated with two columns: One for the responsibilities of that class, and the other with the collaborators that the class will need to complete the responsibilities. Scenarios are narrative descriptions of how the system being designed should respond to user-initated events.We have students understand enjoy, and actually use CRC cards in the introductory object-oriented design process. We attempted to teach a more sophisticated design process that would grow upon the students' interest in CRC Cards, and we provided a design tool to support that process. The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture CRC Cards and Scenarios, and it provides a natural mechanism for tying these two design notions to the underlying code the students were writing.The results of using ECode in the class were not as promising as we had hoped. Students did develop much better scenarios than they had in the past, but they did not use the ties to code at all. More importantly, students found that ECoDE actually stifled their collaborations: With current computer monitors, it's much easier to gather around a table full of 3x5 cards than a screen of graphical index cards.Students expressed frustration in having to learn how to use ECoDE, and indicated that they were more comfortable with pencil and paper. An important indicator of the usability of ECoDE was the decision of the student whether to use ECoDE for the final two design submissions ---for it they were free to choose not to use ECoDE. It is interesting to note that 68.5% of the students voluntarily chose to use ECoDE. The top reason given for choosing to use ECoDE was its simplicity in updating their previous design versions. Of the students who chose not to use ECoDE, the reason most frequently given was that they preferred pencil and paper (44%). Subjectively, the subject group documentation was much more detailed in nature. Many of the subject group students demonstrated a clearer personal understanding of their actual design.A high level conclusion of our study could be, "Beginning students will not willingly use a detailed design process", but that is a little too simplistic. The students did appreciate CRC cards and willingly used them. They did also use some of the aspects of the Ectropic Design process, such as the emphasis on scenarios. But simply putting things in a computer tool does not make them better. Student's primary goal is the completion of the program, not the design. The limitations of a one semester course makes it difficult to make it otherwise. It is the challenge of educators to build design tools that will be adopted that meet that goal. Studying ECode has given us some insight on how best to proceed to meet that challenge.