Teaching object design to students and programmers as a first course on programming is an ambitious and reasonable direction. While my experience has dealt mostly with those who have had some programming experience, many of the directions that should be followed are the same. The basis of my position is that a curriculum should be followed that provides some language independent object concepts, followed by language-based training and finally with a rigorous object-analysis and design course steeped in exercises, examples and projects where real applicability can be tested. Following this basic curriculum will yield object-oriented designers capable of implementing real systems and moving forward rapidly as new languages, methods and libraries become available
I have been delivering education on object technology within IBM and in academia for the last 8 years. I began by teaching object-oriented fundamental to 3GL programmers, many of whom weren't interested in this 'new fad'. I taught my fundamentals course to literally hundreds of programmers over the years. I have also taught analysis courses, notation courses, tools courses, development process courses, methodology courses, design courses, class library courses and technical vitality sessions that have spanned a range of analysis, design, programming and tools topics
For the last 4 years, I have been teaching object analysis and design, which also includes object fundamentals and concepts, at Winona State University as part of the computer science curriculum
My position on teaching object design is best described by a discussion of what I assert to be a good curriculum for educating students and professionals on object technology. After a short discussion of this curriculum, details on the introductory course objectives and mechanics will be given. An assessment of results is also provided. Specialized topics of interest that support the overall position are provided as well.
A curriculum for object-oriented education should be structured as follows
The enumerated courses are meant to be taught in a sequence, while the bulleted ('*'d) courses are intended to be taught as needed for specific projects, after the completion of the first four. Each course will be discussed briefly, with my positions and recommendations being highlighted as appropriate
This is the introductory course and probably the one of most interest to the workshop participants. This course should be somewhere from 16-32 hours based on the skills of the students. In industry, I've succeeded at teaching this in 16 hours to programmers that have been using structured languages. In academia, the time needed will vary based on the exposure students have had to programming in general
The goals of this course are many. Teaching object-oriented fundamentals
to students whom have little exposure to the details of real procedural
systems means that you can focus on the concepts heavily and introduce
them independent of a procedural comparison. When dealing with experienced
procedural programmers, leave time to do comparisons. Time must also be
allocated for "selling" object techniques. This is best done
by demonstrating the power of the concepts and with explanations of real
projects.
Introducing the basic object model and object concepts is the goal of this
first course. Abstraction, Encapsulation, Inheritance and Polymorphism
are introduced and supported by simple examples. Applications topologies
and development methods are also introduced at this stage.
2. Object-Oriented Language Education
After the relatively short introductory course, I think that it is important to continue the journey to objects by getting control of an object-oriented language. Using anything but Java, C++ or Smalltalk probably doesn't make a lot of sense as there are more available tools and books for these languages. My experience is mostly in the C++ case. In the C++ case, I don't advocate teaching the C-language independent of C++ prior to the object-oriented parts of C++. Specifically, there are pieces of the C++ language that are C holdovers that just don't need to be covered. In fact, they introduce more options and therefore confusion into the design space.
3. Object-Oriented Analysis and Design
This course could be considered part of the first course on object technology or a follow-on to #1 above. However, my experience shows that having exposure to an object-oriented language is key to effectively communicating analysis and design principles. You can teach fundamentals for 2 or 3 days, but after that it is important to be able to encode specific examples using a language
I have effectively used the "Booch" object-oriented notation to teach object-oriented analysis and design. Which notation is used isn't important as long as it is one that is written down and can be studied
offline by the students. It helps when there are tools and books to support the notation. I don't think that it is productive to use adhoc, roll your own, notations. Notations must be handled carefully however. I describe and except a slowly growing set of the notation to be used. I strongly subscribe to using subsets of the notations during analysis. "Booch-Lite" was exactly the right answer for introducing notation. Too much too fast will cause lots of students to do into meltdown. I also don't introduce the tool until students
successfully understand the concepts embodied by the notation. I don't believe that you buy a tool and then figure out the rest. A tool mostly helps capture and keep analysis and design up to date. My general approach in this course is to teach a concept or design approach, demonstrate it with an example (using the notation), and then either have an assignment or in class exercise that further serves to hammer home the ideas.
As I progress from analysis to design in this course, demonstrating the concepts begins to involve code snippets. Again, there is a balance between using psuedo-code and real parsable syntax. I'm currently contemplating switching from C++ to Java for my primary syntax so as to avoid some of the "shock" inherent in the C++ syntax.
NOTE: Special considerations in the corporate world must be made for the data-modelers and process modelers of the past. There isn't time to discuss it here, but techniques to avoid "glorified structs" or a proliferation of "manager" classes are sometimes necessary.
4. Advanced Language/Design Education
This is a course that goes beyond those described previously. In the academic world, it is for upper-level undergraduate or graduate level usage. In industry, it comes after some time has been spent using the design methods and language. These courses are usually specific to the language used for development. These courses are also influenced by the "Patterns" movement. We have experimented with a "Patterns" course as part of our university curriculum.
The above '*' courses are usually tailored for specific organizations or for specific projects that use specific class libraries. My experience in taking these courses and in teaching courses like this is that those with the proper training in the fundamentals will do well and those lacking the right prerequisites will slow down the whole class and sometimes not get it at all.
Other approaches to teaching object design certainly exist. A language centered approach, most exemplified by many Smalltalk-based courses immerse programmers in the language and drive the concepts out while teaching the language syntax and semantics at the same time. I think that this approach is very effective in training programmers to write reasonable OO code in a particular environment. The approach I have outlined will allow better transfer of the skills to other programming languages and class libraries.
Another approach is to teach C, then C++, and then follow that up with object-oriented design in the context of an advanced language course. This method can also be effective, but suffers the liability of training programmers about things in 'C' that the you will purposefully have to forget to do good C++ programming. The investment of this extra time and mindspace is not warranted in my opinion.
Both of the language-oriented approaches described above sometimes fail to teach enough about method, process and architecture, focusing heavily on good coding techniques and practices. These are needed also, however.
Eric Herness is a Senior Programmer with IBM Software Solutions in Rochester, MN. Eric has worked on all aspects of object technology over the last 8 years, teaching, consulting internally, developing systems and doing strategy formulation. Eric is currently involved in business objects and IBM's CORBA support.
Eric Herness is also an adjunct professor at Winona State University. There, he teaches object-oriented courses, including analysis and design.
Eric has business degrees from University of Wisconsin at Eau Claire (undergraduate) and Carlson School of Management - University of Minnesota (MBA).