One reason for the difficulty that novice Object-Oriented programmers have during the transition to the Object-Oriented paradigm is that Object-Oriented Programming introduces a modeling component to the process of designing and building software. A model is any conceptual representation of a real-world system or object. While any program can be considered as a model, it is the explicit focus of Object-Oriented Programming that the structure of the program should match the structure of the real-world system (allowing the program to "speak the language" of the domain). The skills involved in designing, evaluating and building a valid OO model are similar to the modeling skills needed by other engineers in their design processes. These skills include:

• The ability to create a decomposition of a problem domain into more easily managed pieces
• The ability to recompose those pieces back to a coherent whole
• The ability to recognize the connections between the model and the original object
• The ability to evaluate the model for the purposes of predicting the behavior of the object
• The ability to test the validity of the model and change it as necessary

The lack of these skills is one of the primary obstacles students face in learning Object-Oriented methods. The students lack a language in which to discuss design or modeling constructs – in fact, they see such discussion as an impediment towards their "true" goal of typing code.

One way to teach the students modeling skills is by explicitly asking them to model, a process called model-building. In the OO domain, a model-building environment would be a language independent workplace where a student could design, test and evaluate their software models. We are in the process of designing such an environment, called BOOST (Basic Object-Oriented Support Tool).

BOOST differs from existing CASE tools such as Rational Rose or Playground, because it emphasizes support for problems that novices have as they first learn Object-Oriented techniques. This poster will discuss studies that we have done to discover what these novice problems are, along with their implications for the design of a successful model-building tool.

Students taking a sophomore level introduction to Object-Oriented design were asked to solve a moderately complex design problem approximately 1/4 of the way through the class (after they had been introduced to concepts and notation, but before they had completed designs on their own). They were given a half-hour to solve the problem. Student performance will be compared to the design solutions of experienced OO programmers and to the student performance at the end of the quarter. Some students were given supplemental information designed to move them along their modeling process (either a list of candidate classes, or a set of interaction scenarios). Preliminary analysis of the student designs indicates the following:

• Students have a clear understanding of the meaning of inheritance structures, in the sense that they create logical ones.
• Students tend not to pursue or elaborate on other interactions between classes. They don’t distinguish between types of interactions, they tend not to include interactions in their design, and they tend not to create classes that encapsulate interactions (such as transaction classes).
• Student designs are data driven – they elaborate their designs to include attributes not mentioned in the original specification, but not to include helper services not included in the original specification.
• There was no significant difference in the designs of the students that got supplemental information – however, those that got a list of candidate classes tended to have slightly more focused designs.

Students in the same class were given a survey on their process at the end of the quarter. They were asked about what their steps were in doing the two-week design and programming projects. These surveys suggest:

• Even though students grades were equally based on design and implementation, the students see their primary task as programming, and see the design steps as less useful.
• Students do, on average, almost half of their design work after they have completed coding.
• When asked what the usefulness of OOA/D is, A and B students are more likely to respond that it saves time later, while C and D students tend to respond with something vague about giving code direction.

As a result of the above surveys, BOOST will have the following features:

• An emphasis on more responsibility-driven analysis methods, to mitigate the students tendency to be data-driven.
• An emphasis on design patterns "in the small" – two or three class interaction templates that can be easily inserted into student models. These will focus student thinking on the interactions of classes, and hopefully start them thinking about reuse issues during design.
• The ability to do validity checks on the design before coding. These checks would include issues like insuring that classes that will need to interact actually know about each other. This should encourage students to do more design work before starting to code.