Many instructors believe that only after students have acquired experience in modifying existing designs should they then progress to creating new designs from scratch. In this position paper, four advantages of modifying existing object designs are put forward. First, it would encourage those instructors who believe in teaching design via modification of existing designs to introduce object design into the first year curriculum. Second, object design modification can be used to teach abstract concepts like cohesion and coupling to first year students. Third, object design modification can assist in clarifying the issue of design versus implementation. Fourth, students can be exposed to a greater variety of different good designs in a course that is based on design modification.
Until 1993, all the Software Engineering textbooks I wrote were traditionally organized. That is, the books were structured around a major term project. For the practical part of the course, students working in teams specified, designed, and implemented this term project. Soon after the publication of [Schach, 1993] I received e-mail from an instructor at a four-year college. He complained that it was all very well for students at a Top-25 school to be required to build a complete product from scratch. In his opinion, however, his students did not have the creativity to do that. What he wanted was a textbook that contained a complete software product, together with a set of problems that required the students to modify that product. He felt that his students first had to learn to modify an existing product before they could learn how to build a new one.
I discussed this idea with instructors at a number of different schools and also with professional software engineers working in the industry. To my surprise, there was overwhelming support for the approach. So, when I wrote [Schach, 1996a], I included both the traditional term project as well as the requested complete case study. The case study includes all the phases of software production. It incorporates requirements analysis, object-oriented analysis, a software production management plan, object-oriented design, detailed design, and implementation in C++. At the end of each chapter are a number of exercises that require the student to modify the case study. For example, at the end of the chapter on object-oriented analysis, one exercise asks the student to add specified additional classes to the analysis and to decide whether the result is an improvement or an unnecessary complication. With regard to the design, in one exercise the student is asked to redesign the project using a different design method also taught in the textbook.
The response to this approach to the teaching of software engineering has been extremely positive. Instructors at a broad variety of schools have adopted the approach of teaching the creative skills of software engineering by first requiring their students to modify a well-designed, complete project. In particular, students learn how to design by modifying the design in the textbook. The approach has been so successful that I have also used it in my latest book, a software engineering text using Java that will be published later this year [Schach, 1997].
It may be argued that these instructors are unduly pessimistic and that their students are indeed capable of designing from scratch without first having to modify existing designs. That may well be the case. The key point, however, is that there are a large number of college instructors who firmly believe that their students first have to learn to modify existing designs before they can be taught how to create new designs. Thus, any attempt to persuade those instructors to introduce object design in the first year will fail unless they are offered textbooks that include good object designs together with exercises to modify those designs.
There are additional reasons why object design should taught in this way. First, consider the concepts of cohesion and coupling, first published in [Stevens, Myers, and Constantine, 1974]. Cohesion and coupling were introduced within the context of module design. However, these two concepts are equally applicable to the design of objects [Binkley and Schach, 1996; Schach, 1996b]. Cohesion and coupling are abstract concepts and, hence, are hard to teach to students in general and to first-year students in particular. Thus, if an instructor gives a lecture to first-year students on the cohesion and coupling of objects, he or she will generally find it difficult to persuade the class that cohesion and coupling are essential concepts. It will be even harder to convince the students that abstract concepts like cohesion and coupling can have a direct effect on the maintainability of software. After all, first-year students have little or no practical experience of software maintenance. For them, maintenance is generally as abstract a concept as cohesion or coupling. Thus, it seems likely that the entire lecture on cohesion, coupling, and maintenance will essentially be a waste of time and effort.
Now suppose that a first-year student is given Object Design OD1 and asked to modify it in some way. Object Design OD1 consists of objects with high cohesion that are only weakly coupled to one another, so the required modification will be relatively straightforward. Next, the student is given Object Design OD2
and is asked to make the same modification. Object Design OD2 is functionally equivalent to OD1, but consists of objects with low cohesion that are tightly coupled to one another. Even though the student will now be familiar with the application area (as a consequence of having performed the required changes to OD1), he or she will find that performing the same modification to OD2 will be considerably more complex than before. Thus, the student will learn the impact of cohesion and coupling on maintenance through hands-on experience. Also, all three concepts will now be concrete, and hence more easily understood and remembered.
Another reason for the importance of teaching object design via design modification is the issue of design versus implementation. More and more first-year students come to college with programming experience, either learned formally at high school courses or informally from attempting a computing task such as setting up a complex World Wide Web home page. For such a student, the border between design and implementation is a hazy one and, if assigned the task of designing an object, it is quite likely that the student will hand in lines of code, rather than a design. However, if the student is assigned the task of modifying an existing design, the distinction between design and implementation will be clear. In all probability, what will be handed in will be at the same level of abstraction as the original design. There will be far less temptation to go beyond the design task and perform an implementation.
There is yet another strength of object design modification. In a first-year course that is based on design modification, the student can be exposed to a far greater variety of different object designs than in a course in which the student has to create designs from scratch. After all, it usually takes less time to understand and modify a good design that has been put together for the purpose of teaching a specific aspect of object design than to create a design. I am making two claims in this position paper. First, there is a considerable group of instructors who would not be prepared to teach object design to first year students unless there are textbooks available that include design modification exercises. Second, design modification is a good way of teaching object design. However, I am not suggesting that the only way that object design should be taught to first-year students is via design modification. On the contrary, I believe that there are many ways to teach object design effectively, and that a good course will incorporate a variety of these ways. However, one of those ways should always be design modification.
[Binkley and Schach, 1996] Aaron A. Binkley and Stephen R. Schach, "A Comparison of Sixteen Quality Metrics for Object-Oriented Design," Information Processing Letters, Vol. 57 (No. 6, June 1996), pp. 271-275.
[Schach, 1993] Stephen R. Schach, "Software Engineering," Second Edition, Richard D. Irwin, Chicago, 1993.
[Schach, 1996a] Stephen R. Schach, "Classical and Object-Oriented Software Engineering," Third Edition, Richard D. Irwin, Chicago, 1996.
[Schach, 1996b] Stephen R. Schach, "The Cohesion and Coupling of Objects," Journal of Object-Oriented Programming, Vol. 8 (No. 8, January 1996), pp. 48-50.
[Schach, 1997] Stephen R. Schach, "Software Engineering with Java," Richard D. Irwin, Chicago (to be published in October, 1996).
[Stevens, Myers, and Constantine, 1974] W. P. Stevens, G. J. Myers, and L. L. Constantine, "Structured Design," IBM Systems Journal, Vol. 13 (No. 2, 1974), pp. 115-139.
Dr. Stephen R. Schach is an Associate Professor of Computer Science at Vanderbilt University. In addition, he is a software engineering consultant with over 25 years of computer experience. He consults for industry and gives seminars worldwide on CASE, the object-oriented paradigm, software reuse, and software metrics. Since 1979 he has taught software engineering topics to a wide variety of client companies, including IBM, Hewlett-Packard, and NEC. Dr. Schach has published over 80 refereed technical papers in areas such as CASE, software engineering, software testing, software maintenance, and the object-oriented paradigm. His latest books are "Classical and Object-Oriented Software Engineering," Third Edition (Richard D. Irwin, 1996), and "Software Engineering with Java," to be published by Richard D. Irwin in October 1996.