Evaluating Design Through Modification

Ed C. Epp
Department of Mathematics and Computer Science
University of Portland
epp@up.edu

Abstract

A valuable evaluation of design aspects of student's programs occur when students are required to modify their designs to accommodate new program functionality or data sizes. Students must document their modifications. The more localized their modification, the better the design.

Why Design is Hard for Students

When a student first walks into a physics class, they know about a great deal of physics because they have experienced gravity since they began to walk, have seen the refraction of light through water droplets, and they have thrown Frisbees. Thus, when they enter a physics class, they have a lifetime of experience to build upon.

Many students have also worked with computers since they learned to walk. They know what a disk drive is and that more RAM is good. However, computer science is an artificial science. Unlike nature, the science of computers has been carefully hidden away within a box for ease of use. The design and algorithms that drive these boxes are so prized that they are carefully hidden from competing commercial enterprises. Although students have learned about using a computer since they were in grade school, it is unlikely they have learned any computer science. As a result, when students walk into their first class they may think that computer science is synonymous with using a spreadsheet or surfing the Web. But this is not computer science. Because students have so little experience with computer science, they must start from the very beginning. We must assume they know nothing about it. In particular, we must assume the have no understanding of software design and design evaluation.

In physics we start teaching theory on the first day. We look at formal models of how the universe is designed. There is a lifetime of experience from which to reap examples that put theory in context. Since students have little experience with computer science, it is important to build that context first before we spend much time on theory.

Owen Astrachan has done a good job of summarizing what is important for a student to know to become a good designer. In his position paper for this workshop two years ago (see Astrachan,) he outlined the following requirements for the first year.

Moving on to Evaluating Designs.

The beginning part of a student's first course is primarily spent mastering language features that support encapsulation. These early designs are so primitive that their evaluation is straight forward. We can look at student code and design documents to determine whether they follow fundamental heuristics (see Riel.) For example, we can look for repeated code. We can access how cohesive their classes are. We can look at how operations are distributed over various classes.

Design issues become more interesting when we begin to introduce object design patterns. One effective means to evaluate a design is to ask a student to take an existing implementation and modify it. For example, we can ask students to implement additional views of a software model. We can ask them to add more nodes to a network or more objects to a simulation.

Part of a student's task is to document all code changes. We can use this information to evaluate their designs. It is more important to record how distributed those changes are than how many lines of code are actually changed. If most of the code modifications are localized to small sections of program, they have a good design. The more distributed code changes, the poorer the design.

 

References

Owen Astrachan, Object Design in the First Year: An Oxymoron., position paper for this workshop in 1996.

Gamma, Helm, Johnson, and Vlissides, Design Patterns: Elements for Reusable Software , Addison-Wesley , 1995.

See Arthur J. Riel, Object-Oriented Design Heuristics , Addison-Wesley 1996.

Biography

Ed C. Epp received his Ph.D. in computer science from the University of Massachusetts at Amherst in 1992. He has be teaching a the University of Portland since 1989. Recently he has been working on a book call Prelude to Patterns in Computer Science Using Java under contract from McGraw-Hill.