1.  Introduction

2.  Background

2.1  Essentials of the Object-Oriented Paradigm

Even though the term instance tends to mean an object built from a class , these two terms are interchangeable.  A class is a template for objects; it has never been alive in its resided system whereas its instances live and absorb in the changes in the system into their states.  Next, we will look at the ways we can connect our objects to build a complete solution.
 

From the information above, we can build an object-oriented model.  How do we know we have built an efficient model?  Consider any card game, like Black Jack.  Should its model contain a general class for cards, or a specific class for each of the cards in a full deck?  Which one is a better choice, only one Card class for all 52 cards in the deck, or one class for Ace-Heart, one for 2-Heart, and so forth?  There are many more of the similar issues to be solved in the steps of modeling.  The concepts presented below will be our keys for decisions on the issues mentioned above.
 

Concept	Meaning
Abstraction	Modeling of an object only on its characteristics being important to solving a particular problem
Encapsulation	The data inside of an object of a class is not accessible by objects of other classes. It is therefore said to be encapsulated from those objects. This means protects an object's variables from being corrupted by other objects.  Information hiding is a process to  enforce encapsulation of objects in which an object's all data and details of its actions that are not its essentials are sealed from the views of others.  Other objects can access only that object's interface, not its implementation.  In this way, an object needs only to know how to send a message to another object asking it to perform some action, not how that object actually performs the action.
Modularity	Decomposing of a problem into units that are cohesive and loosely coupled.
Hierarchy	Compose "A ranking or ordering of abstractions." [Booch]  If two classes' types of data and/or procedures overlap, either a class becomes a parent of another, or they both share the same parent, which is derived from the overlapping information in both class.

A good class must be properly abstracted.  Even though this sounds ambiguous, an object in a model is ambiguous itself.  It does not represent the "correct" real-world object, but the aspects of that object important to problem solving.  For example, what is the least information to make a card in card games unique?  The answer is a face value and a suit.  We do not need to know the deck pattern or the dimension and the font of the cards.  Worst than that, in War we do not need to know a card's suit at all.  A card without a suit cannot be a card for card games in the real world.  However, this issue does not matter for a card game like War in computer.
        Nontheless, reusability is a concern in OOP since this property reduces the effort in building software.  A card without a suit has a low possibility to be reused.  The problem shows sudenly if we want to build software for Black Jack and try to reuse this card class form War.
 

Encapsulation
The first two modeling concepts have great influence toward designs in the object level.  A good model of a real-world object must represent its essentials from the problem solving standpoint.

2.2 Previous Research

1. Different OO methodologies had different OOA/D processes employing different modeling techniques even though they agreed upon the basic concepts of OOP.
2. The modeling of behavior in OOP is more "problematic" than modeling of structure.

1. Composition and decomposition
2. Connection between an object and its model
3. Evaluating and changing models
4. Use their models to solve problems effectively

1. Not be concerned about interactions between classes or not encapsulate interactions
2. Produce data-driven design
3. Understand inheritance relationships between classes, but cannot compose a model back from the broken pieces due to the inheritance hierarchy
4. Not be able to incorporate information to models
5. Not understand the benefits of modeling since they gave the primary concern to programming, and took the designs as the consequence of programming

1. Create the candidate class list.
2. Create details for each class based on its responsibility.
3. Create services and links.
4. Perform integrity checking on the model.

1. Students do not use the OOA/D process.
2. Students do not use abstract classes.
3. Students do not create small, reusable classes.
4. Students could not understand or fix redundancy in model.
5. Students do not use composition to make model more flexible.
6. Students do not create models of "invisible" objects like transactions.
7. Student diagrams are not complete with respect to scenarios.            "

2.3  Coaching

1. Before giving advice, be sure the issue used is one in which the student is weak.
2. When illustrating an issue, only use an example (an alternative move) in which the result or outcome of that move is dramatically superior to the move made by the student.
3. After giving the student advice, permit him to incorporate the issue immediately by allowing him to repeat his turn.
4. If a student is about to lose, interrupt and tutor him only with moves that will keep him from losing.
5. Do not tutor on two consecutive moves, no matter what.
6. Do not tutor before the student has a chance to discover the game for himself.
7. Do not provide only criticism when the tutor breaks in!  If the student makes an exceptional move, identify why it is good and congratulate him.
8. After giving advice to the student, offer him a chance to retake his turn, but do not force him.
9. Always have the Computer Expert play an optimal game.
10. If the students asks for help, provide several level of hints
Hint 1: Isolate a weakness and directly address that weakness.
Hint 2 (what): Delineate what the space of possible moves is at this point in the game.
Hint 3 (why): Select the optimal move and tell him why it's optimal
Hint 4 (how): Describe how to make that optimal move.

We will avoid the second principle since we would like to see the "raw" model of students.  Hints will be given only to help the student advance.  In addition, we plan to modify the third level of hints.  Since students do not learn from only being told [Rappin2], they need to compare different models (both better and worst ones) and justify which one is better or worse and why.  Also with the fourth level of hints, more examples will be introduced to the student to create the picture of "the optimal move".

3.  Framework

3.1  Preparing Interviews

 

Unit 1:	Objects, classes, and abstraction
Unit 2:	Interactions between objects (message passing)
Unit 3:	Information hiding and encapsulation
Unit 4:	Inheritance, Hierarchy, Modularity, and Reusability
Unit 5:	Polymorphism

3.2  Interview Goals

1. Understand the mapping of a real world object to a computer model of that object in the object-oriented paradigm, and be able to apply the characteristics of good design, simplicity and abstraction, in the modeling process
2. Understand the most basic and the most important concepts in OOP, object and class.  In addition, the two components of an object are introduced, attributes and methods

4.  Interviews

4.1 Students and their Backgrounds

Students with no programming experience

1. Brandon is a sophomore in Economics at Vanderbilt University, and has no programming experience.

1. S. J. is a high school student at University School.  He had no programming experience when we began the study in January 2000.  This semester he takes a C++ programming class at school.
2. P. B. is a middle school student at University School.  She has a very limited experience in Visual Basic.
3. Nathan is a sophomore in Computer Science at Vanderbilt University.  He has used C for a year, but has no experience in OOP.

1. R. N. is a junior in Computer Science at Vanderbilt University.  He has been using C for three years.  This semester he takes CS 270 (Programming Languages), which contains an introduction to object-oriented programming.  When we started interviewing him, he had received two OOP lectures using C++ in class.
2. J. J. is a sophomore in Computer Science at Vanderbilt University.  In his freshman year he took CS 101, which spent the later half of the semester teaching object-oriented programming using C++.  He stated that he had been using object-oriented programming for his homework and projects after taking CS 101.

4.2 Interview Summaries and Lesson Development

4.2.1 Interviews # 1 - 3 with S. J.

4.2.1.1  Plan
 

Object and class concepts  (Human example)

Essences of Modeling  (Soda Machine)

4.2.1.2  Results

We started with humans as objects under the same class named human.  A human like S. J. himself inherited some properties from his parents.  In addition to being a human, he also was a student.  Thus, he belonged to both student and human classes.  A human was abstract because, for example, if S. J. finished his homework, his teacher was satisfied regardless of the knowledge about how he did it.  By far, the interview went smoothly as we planned.
        Then, we moved on to the soda machine problem.  S. J. introduced the following items as components of a soda machine: a bill slot, a coin counter, a coin storage, a power cord, can slots, and a coin- and can- distributing slots.  The first interview with S. J. stopped here.  For the details of this step, see Appendix B Interview 1.
        In the second interview, S. J. was asked to think why he needs a power cord.  He now said no because a computer already had one.  Then, he was asked to give the description of a soda machine's working process.  Next, he was asked to extract classes and actions out of that description.  He decided to have only one coin counter for both incoming and outgoing coins.  At this point, he was asked to write the details of each class in form of its name, what it does, and what it needs to know to do its jobs.  He wrote all actions without mentioning any information needed by this soda machine.  The second interview ended here.
        In the third interview, we asked S. J. to finish the details of all classes he defined.  Then, we ran into a problem that lasted for the whole interview; he did not see why we needed to define a method for a callee.  For example, his model let the coin acceptor notify the selection buttons to light up.  Thus, he defined the method tellButton() in class CoinAcceptor, but did not define the method to be called, like lightUp(), in class Button.  Trying to limit his thinking to one thing at a time, we let him finish details of all classes.
        After that, we explained to him that an object in a computer cannot do a job for a caller without having the knowledge of doing it.  In addition, it needed to label each of its tasks with different names so that a caller knew what to say to the callee when it wants a particular job to be done.  We exemplify this message-passing concept with a human activity, baking an angle-food cake.
        Suppose that S. J. did not know how to bake one, but we asked him to do so.  This would not be successful since S. J. did not have that knowledge.  However, assume that Krittaya knew how to bake an angle-food cake, and S. J. asked her to do so.  This would be successful because Krittaya had a labeled knowledge, "bake angle-food cake", in her brain.  S. J. said he understood the situation.  Hence, we asked him to take another look at his model, and see if there was something to be improved.
        After being asked to discuss his ideas, he said that he did not think that there was nothing he could do more with his model.  We then gave him a direct hint that the coin acceptor wanted to call the buttons to light up, but the buttons did not have any labeled task that would perform the "lighting up" yet.  S. J.  looked confused then, and selected to say nothing.  We then pointed out two (???) more places that had the same mistakes, and hoped that he would see the common problem they shared.  This made him so nervous that we decided to end the third interview.

4.2.1.3  Discussion

Interviewing with S. J. was difficult to get his thinking process out.  There was no response from him except when he was asked.  All three interviews went very slowly since we were not sure if he needed more time to think or he had no ideas.  Since we preferred to give minimal help, we decided we waited for a minute to see if he had his own idea.  Otherwise, we asked him different questions to help him accomplished a subgoal.  What we learnt with him was that we sometimes should ignore the principle of minimal help and keep the interviewee moving even though we may have to ask many question and tell  straight answers.
        Form this interview, we saw that using the human example did not give S. J. an idea of modeling.  It did not lead to the concepts of simplicity and abstraction, which should be reflected in a good design.  Therefore, S. J. modeled the soda machine problem with high complexity like a physical one in the real world.

4.2.1.4  Summaries

The coaching pattern in S. J.'s interviews for Unit 1 is shown below:
 

Object and class concepts  (Human example)

Essences of Modeling  (Soda Machine)

Message Passing concept  (Baking-cake example)

Problem 1: A programming novice may not be aware that the mapping of a real-world object to a computer one required simplification and abstraction.  Normally, there were some aspects of that object that we were not interested in or we did not have resources to represent them.
A solution: The coaching instructor might ask the student to think how he would make a computer to have those characteristics or properties.  For example, how would a computer return changes?

Problem 2: A programming novice might not see the need for storing state values.  Since our thinking process was automatic to us, a novice might not realize that a machine could not think "automatically".
A solution: Tell the student that a machine has no brain.  Therefore, we need to give it something that helps it keep track of how many cans of various drinks left in order to operate correctly.  There are two main reasons why a soda machine needs this information.  First, we do not want to take a buyer's money without giving him a can.  Think about the situation that a machine may send a "release" command to an empty can slot that does not give any response back to the machine that it runs out of drink.  Second, a machine refiller can calculated easily how many cans a slot needs because he can just, for example, click a button inside the machine and retrieve the number of cans left in each slot.  Instead of counting or estimating, a number of refilled cans can be known exactly within a very short time.

Problem 3:  A programming novice may not see that an interaction between objects must be modeled in a handshaking fashion via a method.  For example, if object A wanted to ask object B to do something.  Object A would signal object B to do that job.  In order that object A could do so, object B must have the method for object A to call (or send out a signal).
A possible solution: Not available at that time.

Noted that we used the term "a possible solution" when there was no solution yet or we had no chance to try it until this point.

4.2.2  Interviews # 4 and 5 with S. J.

4.2.2.1  Plan
 

Object, class, and message passing concepts  (Bouncing Box example)

Feeling Accomplishment  (Complete a small task)

4.2.2.2  Results

We had to assume that S. J. understood the mapping between the design and the code that make the computer works.  The first interview was full of questions since S. J. was to afraid to answer.  Even though we told him explicitly that he did not do anything wrong if his answers are wrong, he still selected to not answer most of the question.  The situation was in the other way around than we expected.  Since he did not talk, we had to talk and ended up telling him most of the answers.
        In the second interview, we move to the code.  We showed him the animation of a box starting from the middle of its resided window moving toward the lower bound in an angle.  When the box touched the inner bottom boundary, it bounced up in a different angle.  The class of the box contained its current coordination in axis's X and Y, and the bouncing angle in both axis's.  Since we would like to avoid the thread mechanism in Java animation, we pointed out to him which part of the code he should ignore.
        To introduce him to the problem, we used a manual animation.  With three sheets of white paper, we drew three boxes in a series of moving downward.  Then, we flipped the sheets to gave him an idea of how an animation was done, which was drawing each box in a different position.  He understood this and showed interest.
        Then, we started to ask him questions about the code.  The first question was what the class BouncingBox is for.  He answered that it is for the moving box.  We expected to hear "creating an object", but we could come back to this problem later.  So, we moved on to the next question, which was what x and y is for.  he selected to be quiet again.  Thus, we asked him to look the the running question again, and asked him where is the starting position of the box.  He said that it was about in the middle.  We asked him to look in the code to see why the box started in the middle.  After scrolling up and down for a while, he accepted that he could not see why.  Since we did not want him to feel disappointed, we explain to him the coordination system of computer screens.  In addition, we showed the mapping by compare the drawing with the coordination setting in the code.  He then understood what x and y were for.
        To illustrate why we need the bouncing angle, we drew boxes moving up in the different angles.  Each box was labeled with the coordination of its top leftmost corner.  Then, we asked him to calculate the differences of two boxes in both axis's X and Y.  At this point he understood that, to make a box move to its right, we must add some number the x, to move up add some number to Y and so on.  Then, we brought him the code and ask him to look at the method moving the box.
        The method run() provided the animation of a moving box.  It looped forever, and inside the loop it checked if the box touch any inner boundary.  This checking is done by another method.  If the testing result showed that the box touched a boundary, run() then called another method, named adjustLocation(), to adjust the direction of the box.  Since S. J. had to leave, we asked him to think how he would alter that method.
        In the next interview, we decided to give him more guidance than self-explanation method.  In this interview we talked most of the time even though the student should be the one that do so.  We needed a change in the strategy.
        As we expected, he did not have any solution when he came back for another interview.  In this step, we understood why S. J. had been quiet for most of the time.  Even though these three methods looked very simple, he did not have the concepts of methods (even functions in the structured paradigm).  Since the code was heavily commented, he knew that there is a line that give the result of checking the touching boundary.  However, he did not understand that the flow left the calling method, went in the called one, and then came back to the calling method again.
        The most confused problem was that S. J. did not understand at all the called methods must be implemented in order to be used by another method.  In addition, he could not follow the jumps of program flow in and out of a method.  We ended the interview to avoid more confusion on both us and S. J.  We suspected that his programming class might effect this problem.  Thus, we asked him to bring his programs he had done at school to us.

4.2.2.3  Discussion

Surprisingly, the code for a robot world S. J. gave us contained only method calls to order a robot moved right, left, up and down.  Why did he not know he was calling methods of objects?  S. J.'s complaint that his instructor had never let them do anything other than what being told.  Worse than that, his instructor has never mentioned a function or a method at all.
        We examined his C++ program form class, and found that all programs had no methods or any object-oriented components at all.  He also gave us a robot-world code, which was written in the same fashion as C++.  S. J. said that it was a different application than Visual C++, but he could not remember the name.  This robot-controll code had the extension "kpp" containing robot object instantiations and method calling of the robot objects.  S. J. had never seen how the robots functioned.  He knew only that, if his code contained "robot1.moveRight();", the robot would move right one grid cell.
        When we thought more about this code and the way the course was taught, we became certain that it was the reason of his misunderstanding.  S. J. could not understood the need to have methods in OOP because of these pieces of code just directly call some hidden methods and everything was done without his knowledge.  For S. J., he did not understand that, in his code, he called methods of an object.  Moreover, he did not know that the methods he called had their implementation somewhere.
        The problem seemed to be the effect from not starting from the right place.  In stead of learning the transferring of a real world model to a computer one, he started by putting pieces together with no knowledge of what piece was for.  He was thought that he program would work if he followed his instructor, and that to move a robot put its name in a line, follow with a dot and moveRight(), moveLeft(), moveUp(), or moveDown(), and end it with a semicolon.  Why did he write a line like this?  He did not know.  Nevertheless, this black box teaching might be a very efficient one if the instructor revealed the robot object later, and showed the students how these moving jobs of the robot were done.
        From the other aspect, S. J. might really understand things that we told him.  Then, the problem might be at the application of knowledge.  This problem was well known that a student could listen and understand an explanation, but he might not be able to apply that knowledge to a slightly different problem.
        Frankly, he made us feel like he expected us to teach him, and he would be here just to listen regardless of the fact that we explained to him since the beginning that we would like to see him explore the knowledge domain.  We realized that this kind of learning was new to a high school student like him.  However, the lack of intention we saw seemed to be the biggest problem in his learning, especially when the learning from self-explnation required the will to explore reasons for doing things.

4.2.2.4  Summary

The learning by self-explanation could not be applied to a student that wanted to learn by listening.  Nonetheless, this did not meant that self-explanation was useless to our interview.  The problem here was how to initiate the will to learn in a student.  S. J. was interested in the animation problem, but was not interested to explore the domain.  Therefore, he could not come up with his own ideas.
        The execution flow was another problem of S. J.  Since he did not have any background more than canned programming, the discontinuous flow disturbed him.  We had checked his programs for school work again and found some use of functions.  This fact raised a serious question; what was S. J. problem in his computer class at school, receiving inadequate teaching or not paying enough attention in the class?
        Another obvious problem in learning OOP of S. J. here was the message passing concept.  Note that this problem of S. J. should be classified into the beginning programmer class more than the programming novice one according the reasons explained in the discussion.  The list of his problems were given below:

Problem 4: A student changing from the structured paradigm may not see the necessity of having methods in OOP.
A possible solution: We need an example that required many interactions between object yet not complex.

Problem 5: A student did not understand the flow of execution.
A possible solution: An execution simulation

Another factor in this interview was the bouncing box example.  This bouncing box, despite the simple design, was complicate.   It involved a non-physical object (a box) in a virtual world (a window) resulting in the difficulty to imagine how it worked.  Prof. Biswas suggested the Lucky Seven  slot machine as a replacement.  Later on Leelawong had helped a middle school student to program in Visual Basic using this slot machine as the first exercise, and it went well.  (The report of this tutoring was not presented since Leelawong did not introduce any OOP concepts in the help session.)  Thus, we decided to change the first exercise to this problem.
        Leelawong suggested a token exchanger to be the second exercise since it could be reuse in the soda machine exercise.  In addition, we could use this machine model later on the conduct the concept of reusability.

4.2.3  Interviews # 6 and 7 with R. N.

4.2.3.1  Plan
 

Introductory to Modeling  (Creating a wooden box)

Object and class concepts  (Lucky Seven slot machine)

Knowledge Concretion  (Token Exchanger)

4.2.3.2  Results

R. N.'s first model contains three bars, a main class, and a random number generator.  The idea of having a separate random-number generator was superb from the reusability aspect, which we intended to introduce later in the interview series.  We asked R. N. to explain the reasons of having each components to us.  During explaining, R. N. mentioned that his model has 5 classes.  We waited until he finished, and then told him that actually his model has only three classes but five objects.  He suddenly said that he has three bars but one class.  Since he seemed to see the relationship between classes and objects, we strengthened that with the explanation that a class is the prototype of similar objects.
        Next, he was asked to write down the details of each class.  He felt nervous and could not write anything on his notepad.  We determined that he intended to write C++ code, and did not know where to start.  Thus, we told him that we would like to see pseudocode not a code, and he should start from designing each object.  Our assumption must be right because he started to work on his notepad after hearing that.
        He began the details by defining class main, which contained three Barinput objects.  The most interesting result was that then he defined another class called "class 2 object slot machine", which returned three randomly-generated numbers.  Finally he defined "class 3 object 1" for the random number generator.  We asked him at this point why he wrote "object" explicitly when declaring each class.  He discussed that it is for extension in the future in the case that we needed more objects.  We corrected him by explaining that a class served as a prototype of each object of that type.  He seemed to understand.  Since he already accomplished the first subgoal, we asked R. N. to sketch a model for the token exchanger problem.
        In the second interview, we first asked R. N. to finish his model for the Token Exchanger problem.  Since we had kept his original design for writing a report, we handed it back to him.  Instead of looking at his design from the previous interview, he started to design his model from scratch.  He then explained when writing that he was going to write the definition of an object.  We tried to remind him that he should write the class to be the prototype of his objects.  He stated that it did not matter; he could say "class" if we liked.
        We felt unsure sure whether R. N. understand the relationship between an object and its class correctly, which meant that our first subgoal was not fulfilled.  Thus, we asked him, "What are the differences between an object and a class?".  He said that there was no different between them and these two words were interchangeable.  We had tried many real-life examples with him to convince him that his misunderstanding was not only the problem in selecting the right terminology.  The list below showed the examples we used:

1. An instruction book for building a car versus a car built according to that instruction book
2. An announcement versus its copies from a copy machine
3. A teller versus Miss Daisy that works behind a teller counter

4.2.3.3  Discussion

R. N. had two misunderstandings:

1. Design was not important.  Code was the solution.
2. Aggregation and inheritance are viewed as a part of the decomposition process in structured programming

4.2.3.4  Summary

The introductory of modeling did not convince R. N. enough to get over his "homework instinct".  In addition, the Lucky Seven problem may be another problem in itself since it did not convey the concepts of classes and objects to R. N.  Despite this fact, this problem gave the student the feeling of accomplishment because it was easy to understand and model.
        Unfortunately, we spent so much time to straighten R. N. that he felt unsatisfied because he was sure he was right.  We had to take this into our consideration that we needed to give a student the feeling of advancement and success to encourage him to learn more.  In addition, sometimes we might have to back up and put that conflict aside if it would not cause any complication to the next subgoal.
        The problems in learning OOP from these two interviewed were listed below:

Problem 6: A student did not see that good designs increased the quality of programs, which was determined from four aspects -- utility, reliability, performance, and correctness [Schach].
A possible solution: Let the student solve a large, complicate problem without mentioning any design process.  When he was confused, we could offered him the design guideline discussed in the background section.

Problem 7: A student was confused between the inheritance and aggregation relationships.
A possible solution: We might give the student a decomposition tree containing both aggregation and inheritance branches.  Let him label each branch with either is_a or has_a.

4.2.4  Interviews # 8 with S. J.

4.2.4.1  Plan

We decided to redo Unit 1 with S. J. using the revised version presented in 4.2.2.1.

4.2.4.2  Result

S. J.'s first model contained numbers from 0 to 9, one handle, and one display screen.  Then, he refined the model to contain three number windows when asked where he would display the numbers.  One problem was arise: he did not define an object of the slot machine itself to contain all components he created.  We asked him whose these components belonged to.  He looked confused and selected to not answer us.  As learnt from R. N. that we should not corner a student, we decided to gave him more hint.  We asked him what he saw if he stood in front of a Lucky Seven machine.  At this point, he realized he had not modeled the machine itself yet.
        S. J. let the machine perform all actions, generate three random numbers, display them, and find out the result (win or lose).  The interesting point was that he suggested the machine keeping the winning number as a variable, which made the model more flexible.  When he was filling in the details, the same problem on methods was arise.  He wanted to just put all steps inside the class boundary.  We explained to him that every job of an object must be a labeled one so that it could be used by other objects.  S. J. was more confused.  Hence, we ended the interview to prevent more damage, and to give ourselves a time to find another plan.

4.2.4.3  Discussion

These two interviews with S. J. went the same way as his first two.  We needed to ask a lot of questions to find out the problems from S. J.  As learnt from the first three interviews, S. J. excluded the change slots and a power cord from the model right from the beginning.
        One more problem of S. J. that we could not solve yet was how to convince him to see that a class needed methods to work.  We could not introduce methods in the same way as structured functions.  recall that we had a function in the structured paradigm to group up pieces of reused code.  Methods in OOP were more than that as explain in Section 2.1.

4.2.4.4  Summary

We determined that his very limited knowledge in structured programming using C++ confused him.  For the last three interview, we could not lead him over the concept of message passing.  We decided to use the alternate plan involving code.  Since he had seen only programs in the structured paradigm, we should create an opportunity for him to see some simple, short programs in the OOP in the next interview.  Even though S. J. saw the code of the bouncing box, he seemed to be so confused with it that he could not learn anything at that time.

4.2.5  Interviews # 9 with S. J.

4.2.5.1  Plan

In this interview, we aimed to improve S. J. in two aspects:

1. Abstraction in computer models
2. Importance of methods to objects

4.2.5.2  Results

As usual, we talked most of the time, and S. J. avoid to answer questions.  We started by letting him to look at that short code of the Lucky Seven game, and asking him where the start point of working for this program was.  He gave the right answer, the main() method, since most of his programs at school contained only that function.  However, he did not know why.
        To convince him to see the reason, we asked him where he usually started when reading a book.  We sensed from him that he thought it was a silly question, but he could not answered it.  We had to asked more if he normally jumped to chapter 5 and started from there and come back to read chapter 1 later.  Then, he said that we must started from chapter 1.
        We then linked this book-reading example to the program.  A computer needed to know where it should start reading his program also, and it looked for the main() method to start with.  We tried to send a message to S. J. that the main() function is not everything of a program; it just had a reason to be in most of programs.  Nonetheless, we could not know whether he received our message until he worked on another exercise.
        Then, we look into the main() method itself.  He was confused by the Lucky Seven object initiation.  Since in Java, the main() method must be inside a class also, we put it in the LuckySeven class boundary for ease in maintenance.  However, this confused S. J. that why a class instantiated an object in itself.  We told him that main() is not a part of the class itself, but it was just a place to start.  He seemed to take it, and we did not figure out a better thing to do at that time.  We planned to go back and discuss more on it later.  The only problem to be focused on at this time was the object instantiation.
        We told him to look at the object instatiation like a type.  We exemplified this using the int type.  We asked him if he could write in a program, "int = 5;".  He said no.  Note that when he was quiet or said "no", He frequently was just unsure about his answer, not that he did not have any idea.  We asked him more if he ad any solution to this mistake.  He selected to be quiet again.  Thus, we gave him another small piece of code, "int a = 5;".  Then, he approved its correctness.
        We asked him what made him think differently on this two pieces.  He did not give any answer.  We then asked him to compare character by character, and tell us what was different between these two lines.  He said "a".  At this point, he was sure enough to tell us that a was a variable but int was not.  We hinted more that int was a type, and, when we wrote "int a;", we declare a to be an integer.  We told him that the Lucky Seven object instantiation was the same thing as "int a = 5;".  Without that instantiation, it was like "int = 5;", which he knew was wrong.  He seemed to buy it so that we moved to the next line of code.
        The next line in the program was the calling to the spin() method of an object of class LuckySeven.  Here the same problem for the last three interviews showed up again, but we had a plan for it.  We would let him finish the spin() method, and let him change the code in the way that he though it was the best.  We helped him translate his writing into code because we did not intend to teach him how to write a Java program.
        When he finished the method, we ran it and let him play the game a couple of times.  Then, we asked him to remove the line in main() that call method spin(), and recompile and rerun the program.  There was no screen output like the first version.  He was stunned, and had no answer when we asked him how we could play the game again.  Next, we removed the spin() method's signature.  We asked S. J. if that would make the slot machine work again.  He said "yes".  The program was unsuccessfully compiled.
        We asked to him to reason why, when the code looked so familiar to programs he had done at school, it did not work.  We waited for a while, receiving no answer, and proceeded to explain.  Certainly, the nature of OOP required that every line of code must be put in a method.  Why was it that way?  Because a computer, which no nothing about the LuckySeven object entered the main() method.  It first got to know the object of class LuckySeven, and then .. what?  Then, there was nothing more to do in main(); there was no more code.  The computer exited the program.  So, the line that call the spin() method told the computer that it has one more thing to do, which was making the LuckySeven object spin.
        At the end of the interview, S. J. suggested that integers should be objects of class Integer.  We were glad to hear this comment.  It indicated that he understood the concept of objects and classes, but still lacked of the basic computer knowledge, which we were not interested in.

4.2.5.3  Discussion

Lyons suggested that we should separate the main() method from the LuckySeven class to get rid of S. J. confusion.  He would see that the main() method was not a must for a class unlike code in the structured paradigm.
        Even though S. J. understood the mechanism of this program, he indicated that an object was not neccessary in the environment by removing the object instantiation and the method signature.  Therefore, we needed to develop another exercise that show him the necessity of having objects from the same template (class).

4.2.5.4  Summary

Even though we tried not to do any programming in our interviews, it was proved by this one that sometimes programming was a good alternative to show a student right or wrong.  When we said that a computer could not do this, it sounded unreasonable because of lacking of visible evidents.  Conversely, letting the student experience by himself that a certain siuation did not work was very convincing.
        Since S. J.'s result indicated the problem with our example involving only single class and single object. we develped two exercise in the card game domains, War and Black Jack.  See Appendix A for the details of these games.

4.2.6  Interview # 10 with J. J.

4.2.6.1  Plan

JJ decreed that he was familiar with OOP through C++ and so he was first asked to model the Lucky Seven example, foregoing an introduction to OOP design and principles. This example gave us a good idea of how much OOP JJ understood. After he had finished with the Lucky Seven model he was asked to begin working on the 21 card game example to clarify some points.

4.2.6.2  Results

JJ began the Lucky Seven model by creating three Bar objects. Each Bar object contained a method which generated a random number between 0-9. It would have been satisfactory to stop here and test whether any of the Bars are 7. However, he proceeded to create a Group object that contained all of the bar objects. The Group object checked each bar for a 7. This extra grouping step was unexpected and it was difficult to determine whether or not he understood objects. We decided at this point to began working on the 21 card game.
        First he created two Hand objects. The Hand class has methods which may receive two cards, wait, ask for another card, add, and compare. He then created a Dealer class which has methods to give a card, wait, and hold. In order to play the game the Dealer first deals two cards and a Hand receives the two cards. Then the Dealer deals another two cards and the other Hand receives the cards. We decided to stop here as it became evident that his model was going to require handshaking, which complicated the problem beyond the scope that we intended. This type of behavior is common among students with no programming experience who feel the need to model events in the program in the exact order in which they happen in the real world.

4.2.6.3  Discussion

It was difficult to determine if JJ understood the difference between classes and objects with these examples. He did not show that he knew how to handle objects nor their interaction. The classes he built were more like header files in C as opposed to classes in OOP. His classes contained no objects; they merely had methods which represented events. For example, the Dealer class could deal two cards (an action) and the Hand class could receive two cards (an action) but nowhere did he define what cards were nor where they came from.

4.2.6.4  Summary

These examples succeeded  in determining how much OOP JJ knew, but failed as teaching examples. The Lucky Seven example, albeit simple, offered too many different possible solutions. For example,  creating a Group object to hold the Bars is not incorrect; after all the Bars in a slot machine are actually held within the case. This Group is not needed but beginners feel compelled to create it because that is how it is done in the real model. Moreover,  it is difficult to model pulling the handle in the computer, or representing the actual slot machine. However, these are things that beginners want to model. It is difficult to explain (and understand) why these things are not needed in the computer. Thus it has been decided that it is simpler to create a better example and remove the Lucky Seven example.
        The Black Jack card game is a good example because it contains multiple objects, multiple classes, and object interaction. The game is a bit elaborate, especially for a first example, and can be simplified to some extent. By dealing only one card to each player, with the player having the higher card being the winner, the game still contains multiple objects and classes but is easier to understand and model. This game is known as War and downsizes the number of cards each player gets to one, eliminates any 'waiting,' and eliminates a comparison to 21. It is also the hope that this new model will be easier to analyze. That is, it should be more apparent whether or not the student knows how to create and use objects properly.

Problem 8: An intermediate programmer may not know what a class is nor how to properly define one. Being used to procedural programming, the student may get class confused with a header file. In C header files simply defined the functions (analogous to methods) that were available. While a class does have methods it also has much more. A class also comprises objects and defines the objects properties.
A Possible Solution: By declaring the necessary objects and then building their classes it should become apparent that a class is closely associated with the object and ultimately defines all of the objects attributes (as well as the methods it may call). It is not recommended to begin by defining the class for the object as the student may become loss as to what that class is supposed to do as well as what the object is supposed to do.

Problem 9: Students new to modeling may not know how to model some events and/or may excessively model events.
A Possible Solution: Avoid examples that are impossible to model in the computer. If this is not possible then simply state that these do not need to be included in the student's model for simplification reasons.

4.2.7  Interview # 11 with J. J.

4.2.7.1  Plan

A brief overview of OOP concentrating on objects and classes was given to JJ. After this introduction he was asked to model the War card game example in its entirety starting with the objects needed and then building up their classes. After all of his objects' classes were built he was asked how to play his game, concentrating on object interaction.

4.2.7.2  Results

Initial objects: Player(2), Card(52), FaceValue, Suit, Hand(2), and Deck. Player(s) hold a Card. Card is taken from a Deck containing 52 Cards. Face is the value of the Card and Suit is the suit of the Card. Hand is the card that each player has. The first class defined was the Card class. Properties included a char suit and an int facevalue. When asked what the difference between his suit and facevalue properties in the Card class and the Suit and FaceValue objects in War was, he became confused. We asked him whether suit and facevalue were properties that belonged to a card or if they were distinct objects. He knew that they belonged to a card and so he removed the Suit and FaceValue objects from the War class. Methods of the Card class include PutIntoHand() and Compare().
        The next class was Player. He did not know how to define a player; he knew that players received cards and then compared cards with each other but did not know how to express this so it was skipped. The Deck class was created as having 52 Cards with the method GiveCard(). We inquired what the final class, Hand, was supposed to do and he answered that it is all of the cards that the player currently has. Since each player will only have one card at any time he realized that it didn't make sense to have a Hand, and so he removed it.
        In the War class, first two cards were created, a and b, followed by two Players, x and y. Then a Deck d was created. Card a <- d.GiveCard(). and Card b <- d.GiveCard. This looks good so far. He understood that the Deck object can return a card. Moreover, from previous programming experience, he knew that he first needed to create two 'blank' cards in the War class and set them equal to the cards returned from the deck. However, then he tried Player x to draw Card a from Deck d.
        Having a player draw the card doesn't make sense because the cards were created in the War class and not the Player class. When asked how he planned on having the Player draw the card he realized that he already had a Card and that he didn't really need a player to draw it. This was already done by d.GiveCard(). Also, now that he knew how to draw the card he didn't really need a player any more. He first created a Player because intuitively this is how the game is played. In the real world, cards can't be drawn without someone physically drawing them. The way JJ modeled his Deck he didn't need anyone to draw the card, he could simply call deck.GiveCard() and it would return the next card. Since he didn't have players any more, he needed a way to compare the cards. He previously created a Compare() method in the Card class which now served as his medium to compare the cards. He called a.Compare(b) to find the winner.

4.2.7.3  Discussion

In the beginning JJ thought that everything had to be an object and that a class was just a collection of objects.  Classes were more than just collections of objects.  As well as containing objects, classes also contained methods which served as ways to modify the objects.  The point at which he realized that classes had properties that defined the object is when he included facevalue and suit in the Card class and removed the FaceValue and Suit objects. He now understood that objects had certain methods like Compare() which gave him a way to compare cards without having an external source (players).
        It is interesting to note that he initially included Compare() in the Card class. This in itself was not unusual as most students realize that cards can be compared and so include it in the Card class. However, JJ did not include Compare() in his Player class initially. In fact he did not even include a Draw() method.  When detailing the game, he wanted to have the player draw the card, which was an expected action.  It was difficult to say why he saw that a player should draw the card but then he did not need to compare the cards. The way in which it worked out was that he removed the player altogether and simply had the deck deal the card and the cards compare themselves. It was very good that he was able to break free of the real world model and lay out a schematic of how a computer would handle the game.

4.2.7.4  Summary

War had only a few objects which makes the model simple, but at the same time it was complex because the objects must interact with one another. As the student began to model more deeply into the problem, he began to realize the difference between real world models and computer models. This was an important concept and one that was difficult to explain.

Problem 10: An intermediate programmer may be subject to the "Is a" and "Has a" fallacy. As is the case with JJ, he first wanted to create a Suit object and also wanted to include suit in the Card class.
A Possible Solution: Create an example which exposes the student to the Is_a/Has_a fallacy. In this manner the student will become confused as to when an object should be part of a class as a property or should be an independent object itself. This confusion can be cleared up by asking him how the real world is represented. For example, a card Has a suit and so suit should be part of the Card class. A card is not a suit and suit is not independent of the card.

4.2.8  Interviews # 12 with S. J.

4.2.8.1  Plan

We set to explore the possiblitiy of the robot problem domain with S. J. by giving him some other model than his to him to compare.  He was expected to use both models to solve the same problem, the Wobbler [Brown AI book].  This means would give him the idea of what was called a good model.  The alternate plan was the card game, War, which was tested to be successful with JJ.

4.2.8.2  Results

We started with designing a robot.  S. J.'s design was exactly the same as the given one in his class at school, which was:

class Robot {

moveForward()
turnRight()
turnLeft()

}

class Robot {

moveLeft()
moveRight()
moveUp()
moveDown()

}

Who does what
Who does what to whom
Who askes whom to do what

4.2.8.3  Discussion

The problem with the robot world was S. J.'s own perspective.  He already beleived in the programs he saw at school, which concealed most of the mechanism of the game.  Therefore, his creativity was fogged with the pre-image of a problem.
        With the card game exercise, S. J. seemed to start in the right direction, but still failed to link all objects to work together (the composition step).

4.2.8.4  Summary

Even though the robot problem did not yeild a positive result with S. J., it was an interesting domain that juveniles would enjoy to work in.  The problem with this problem would be how to show the student that an object could have no actions of its own, but only gave services to the others.
        There were more details that S. J. should define in this card game before starting to translate it to the code.  However, we did not have enough time to get into it.  In addition, we felt that he was bored by no programming.  Hence, next time we would let him start to code, and see if he would think more about his system integrity.

Problem 11: An OOP novice Objects may not concern objects with no actions.
A possible solution:

• Let the novice think what kinds of services it could gave.
• Let the novice think of the objects' unique identitites.
• Create a problem involving many activities that require objects to acquire information from others.

• Ask the novice to fill in more details until some confliction raises.
• Let the novice start programming and see the compilation errors.  >From the compilation errors, ask the novice to correct his model.

4.2.9  Interview # 13 with S. J.

4.2.9.1  Plan

We aimed to test the second possible solution of Problem 12; let S. J. program to see his errors.  To reduce the confusion in programming, we would start with a jigsaw-puzzle-liked game.  S. J. would follow these steps:

1. Specify the solution to the War game step by step, each step containing only one action.
2. Assign the performer and the effector(s) of each action.
3. Define objects according to this scenario.

Details of card game

4.2.9.3  Discussion

4.2.9.4  Summary
 

4.2.10  Interview # 14 with Brandon

4.2.10.1  Plan

Since Brandon had no previous programming experience he was given an introduction to OOP. Emphasis was on objects and classes and how this is analogous to the real world. He was then asked to completely model the War card game starting with the objects and building up their classes. Attention was focused on his fundamental understanding of objects and their corresponding classes.

4.2.10.2  Results

Initial objects: Card, Suit, and FaceValue. Card objects were the 52 unique playing cards. Suit is the suit of the card (i.e. hearts, spades, diamonds, and clubs) and  FaceValue is the value of the card (i.e. 2, 3,..., K, A).  The Card class was first defined. It contained two fields, an integer facevalue and a char suit. The class initially had one method, Compare(), which compared the facevalues of two cards and their suits and returned the higher card. Brandon then went on to define the Suit class, but this is where he ran into a roadblock. He did not know what he wanted this class to have. We asked him if he needed both a Suit object and a suit property in Card. He realized that if the Card class already had the property of a suit then he would not need an explicit Suit object. Thus he decided to drop the class. The corresponding FaceValue class was dropped for the same reason.
        The War class: The first thing that needed to be done was to shuffle the cards. However, no cards have yet been created, so he created card1..card52. We inquired as to how he planned on shuffling the cards even if he had 52 cards lying around. He then realized that he needed a deck. The Deck class created 52 Card objects, but when asked how he was going to make the cards unique, he was at a loss. He knew that his Card class had fields for facevalue and suit, but he did not know how to instantiate those fields. He did not realize that the class was a default template for the object, and that once the object was created its properties could be set and/or changed. Therefore, he decided on creating 52 different classes, one for each type of card. The first card class had a facevalue set to 2 and a suit set to clubs. The next card class had a facevalue set to 2 and a suit set to hearts, and so on and so forth. It is probable that if he had known that the properties within classes could be changed after the object was instantiated, then he would have used his original generic Card class, instead of creating 52 independent card classes. As it stood each card class had two methods, Shuffle() and Draw(). Shuffle() randomized the 52 card objects and Draw() returned the top card.
        Back in the War class he next proposed to have the dealer draw a card and give it to the player. We asked him who the dealer and player were and so two more classes had to be defined, Dealer and Player. The Dealer class contained no objects but had three methods initially. The first method, Deal(), returned one card from the top of the deck. The next method, Receive(), received one card. The Compare() method compared the facevalue of two cards and declared the winner. The Player class also contained no objects and had three methods. The methods Receive() and Compare() were the same as in the Dealer class.  The third method, ShowCard(), returned the value of the card. Now that he had a dealer and a player the dealer could draw a card and give it to the player. We asked him how he thought the player should receive the card, but he had no solution as to how to give the card to the player so he thought it was best to simply discard the Receive() method of both the Player and Dealer classes. The dealer then drew another card. Again there was no way to 'give' it to himself so the card was simply created and not changed in any manner. The dealer finally compared the values of the two cards and displayed the result. He was asked which Compare() method he was going to use, as he had created a Compare() method in the Card class, one in the Dealer class, and one in the Player class. He decided to drop the Compare() methods in the Card class and the Player class and have the dealer do it. The only way for the dealer to compare two cards is for the Compare() method in dealer to receive two cards and then return the higher card. In this way the dealer does not even need the player to show his card, so the method ShowCard() in the Player class is not needed. However, he did not see this.

4.2.10.3  Discussion

When we first asked Brandon what objects were needed he responded by including objects for the suit and facevalue. Initially this was not a problem, as it is often difficult for beginners to realize that facevalue and suit are properties and not objects. For this reason, we asked him to create the Card class first hoping he would realize that this is where facevalue and suit belong. Having a dealer and a player are not required in the War world, simply drawing two cards, labeling the first as the player's card and the second as the computer's card, would have been adequate. In modeling, however, creating a dealer and a player are more intuitive and students more often than not create them. Brandon's dealer could only deal cards and compare cards. When he dealt a card, the card was not given to anyone, it simply lay there in the game. Moreover, the Deal() method of the dealer simply called the Draw() method of the deck and returned that card. Thus it was not even necessary to have a Deal() method; the card could have been returned straight from the deck. The other method of dealer, Compare(), compared two cards and returned the higher card. This is a valid implementation since in the real world it is usually the dealer that determines the winner. The Compare() method could have been written in the Card class, eliminating the need for a dealer. The Player never actually did anything in this game. Its only method, ShowCard(), was never called (or needed) and this object could have been eliminated. It does not make sense intuitively to not have a dealer and a player though.
        Students first learning to model often over-model the world. As in Brandon's case, there were many things that overlapped, but eliminating them did not make sense conceptually. It appeared that he understood the fundamental basics of objects and classes. He understood that classes defined the object's properties and that the objects had to be created upon which they then had access to all of the methods of their class. Fundamentally, this is what we were aiming for in this example. The fact that he understood the difference between classes and objects overshadows the fact that he had ambiguous objects and classes.

4.2.10.4  Summary

This example successfully relayed the differences between classes and objects. Forcing the student to create multiple objects and their corresponding classes made it easy to determine whether they understood when objects were needed and how to use them. This example is particularly useful because it made apparent the differences between objects and properties. For example, creating a suit object initially is not a problem, as long as the student soon realizes that the suit needs to be a property of the card, and thus needs to be included in the card class and does not need to be an object in the world. Once an object is created, understanding that the object has all the properties as defined in its class are vital to understanding how to use objects. However, it would be useful to come up with a solution to showing how the properties of the object can be changed after it is created. The class has generic properties which describe the object, but which can be altered during the course of the object's life.

Problem 13: A programming novice might not understand the difference between objects and properties. For example, facevalue is a property of the card and should not be an object.
Solution: Require that the object's class with the property be written first in hopes that the student will realize that the property goes into the class and should not be an object.

Problem 14: A programming novice might not realize that the property fields of a class can be changed after the object is instantiated.
Solution: An example of how real world objects are changed and then how there properties are automatically changed.

Problem 15: A programming novice might over-model the world and contain ambiguous and overlapping methods.
Solution: Point out that simplicity is always easier to understand and model. Our model should be as simple as possible without losing its power.

4.2.11  Interview # 11 with S. J.

4.2.11.1  Plan

In this interview, we expected S. J. to learn how to "compose" his objects together to create a working program through coding.

4.2.11.2  Results

Details of card game

4.2.11.3  Discussion

4.2.11.4  Summary
 
 

4.2.12 Interview # 16 with Nathan

4.2.12.1  Plan

Since Nathan had no previous knowledge of OOP, he was given a brief introduction to OOP concepts focusing on objects and classes. An example of how OOP is modeled in the real world was given and then he was asked to model the War card game in its entirety starting with the objects and building up their classes.

4.2.12.2  Results

Initial Objects: Card and Player. Card objects were the 52 unique playing cards and Player objects were the different players playing the game. The first class he defined was the Card class. The class had two fields, a char suit and an int facevalue. Additionally, the class had two methods, Compare() and Draw(). The next class he defined was the Player class. It had one field, char Name, and two methods, Draw() and Compare(). Lastly he began working on the War class. First he defined two Players, player1 and player2. Next he created 52 Cards. At this point we asked him how he planned on 'drawing' a card since he effectively had 52 cards 'lying' around in his world. This is where he realized that he needed a deck. He moved all 52 cards from the War class to the Deck class. Moreover, he added a GiveCard() method that returned the top card of the deck and a shuffle() method that randomized the cards.
        Back in the War class he created a deck and then called deck.Shuffle(). Next he called deck.GiveCard() twice followed by Player1.Draw() and player1.Compare(). This is where we asked him exactly what his Draw() method in the Card class did. He knew that he wanted his player to draw a card; he was asked what the purpose of having a GiveCard() method in the Deck class was if the player was also going to have a Draw() method in its class. He realized that these were equivalent methods and that the Draw() method of the player class could be removed. We then inquired as to what he planned on doing with his players since effectively he just drew a card from the deck and then it just lay there. Again there was this problem of 'giving' a card to a player and that player 'receiving' the card. This is a difficult concept to reconcile in a program. In the real world there is only one card and it is given from the dealer to the player. Nathan successfully corrected this problem by adding a Card field, My_Card,  to the Player class. He then set equal player1.My_Card to the card returned from deck.GiveCard(). Then he set player2.My_Card equal to another card returned from deck.GiveCard(). This is the correct manner in which to model 'giving' and 'receiving' in a program. This is difficult to see because there are really two cards, one uninitialized card in the player object, and one initialized card drawn from the deck. Now that both players have their cards he called player1.compare(player2.My_Card) and returned the higher card and printed the winner.

4.2.12.3  Discussion

Nathan did not have any insurmountable problems modeling this example. He instinctively understood how to use objects. This may come from the fact that he is comfortable with using structures in C. Some of his objects overlapped methods, such as Compare() and draw(), but once he began to detail how the game was to be played it became obvious which methods he could remove. The fact that he realized that he could move all of the 52 cards to a deck and have the deck deal the card showed that he understood how to use both classes and objects. The other key issue is the problem of synchronization; cards need to be drawn and then given to players. Again, his background in C is probably the reason he understood how to pass the drawn card to the player. The player already had a Card object in his class and once the card was drawn from the deck the player's card was set equal to the drawn card. His programming experience enabled him to put the finishing touches on the model but his underlying knowledge of OOP was clearly learned from the interview.

4.2.12.4  Summary

This example enabled the student to use multiple objects to achieve a goal. As is the case with most card games, some synchronization is required but not more than what a student should instinctively understand. For example, first a card needs to be drawn and given to the first player. Then another card needs to be drawn and given to the second player. Finally both cards need to be compared and a winner pronounced. These are events that require object interaction. Only a fundamental understanding of objects enable the student to correctly model this example. However, nothing more than a fundamental understanding is needed; no advanced process synchronization is required. The War example is an excellent solution for teaching basic OOP principles (objects and classes) and testing the level of understanding gained by the student.

4.2.13  Interview # 17 - 18 with P. B.

4.2.13.1  Plan

We planned to use the revised Unit 1 with the War game as the exercise.  Like S. J., P. B. had a very limited programming experience.  We could expect the same difficulties found when coaching S. J.  Thus, the hints to P. B. would be more straight than those to JJ or Brandon.  We might let P. B. play our puzzle-like game if needed.

4.2.13.2  Results

We started with the advantages of OOP, and then the introductory to modeling as described in Appendix A: Unit1: Tutorial Sketch.  Then, we described the War game.  P. B. suggested that the game was more than we explained.  Even though we preferred to keep the problem simple, letting P. B. do what she knew well might be a faster path to the goal.  When P. B. finished the oral description of the game, we asked her to write down the game scenario.  Her scenario was similar to the others'.
        P. B. first-version scenario (see Appendix B: Interview # 17) was similar to the others'.  She worried very much about the dealer since a player might sheet when performing a war.  However, our concern was that there would existed an inheritance relationship if she had a dealer and a player in the game.
        Next, we asked her to refine the scenario by telling her that every action must have a performer like in the real world.  Then, we went line by line and asked her who get a particular thing get done and to whom by what if have.  At this point, P. B. introduced The Computer into the scenario. The Computer did most of activities, and P. B. seemed to forget that the Computer is another player.  Since we did not want to alter her model but was afraid she would forget the fact later, we suggested her to use the term Dealer instead of Computer.
        Then, P. B. was asked to refine the steps once more time.  This time was to finely define what a computer should do.  Our explanation to her was that a computer is not smart.  It could do only what she tell in clear steps.  For example, it could not split the deck if it had not known that deck before that point.  P. B. showed a great understanding in the improved scenario.
        Finally, we asked P. B. to list the objects in the model.  P. B. listed out two objects: a player and a dealer.  We did not disrupt her but let her define the actions of each objects.  When she finished writing, we asked her what was very important in a CARD game.  She suddenly realized that we needed cards.  However, she did not define any variable to keep the state of a card.
        We showed her a piece of paper and asked her if it was a card.  She said no.  We then asked her what would make it a card.  She seemed lost.  We then give more hint by asking her what she thought of when looking at a card.  She answered the card value and suit.  We explained to her that a computer needed to be able to identify objects in the same way she looked at a card.
        Then, we went into her model for the dealer and ask P. B. why the shuffle( ) method belonged to the dealer. She said that because the dealer shuffled the cards.  We decided to give the solution away and hoped for a good response since P. B. had shown that she had a remarkably thinking process and the ability to explain it.  We asked her frankly what she would think if we said that the shuffle( ) method belonged to the deck, not the cards nor the dealer.  P. B. thought about that for a while, and said that it did not make sense to her.  We then tried the handshaking example, but she still insisted that our solution sounded unreasonable.
        In the second interview, we used the jigsaw-like puzzle as the core of the interview.  Corresponding to her last design from the first interview, we laid out rectangle pieces, which each represented only either a subject, a direct object, an indirect object, or an action.  P. B. now developed a detailed scenario that came very close to a good structured one.  Therefore, P. B. led our discussion went deeply into the action-oriented side.  We tried the move of actions to the object side, not the subject one.  We asked her if she liked the convenience of having a magic deck that could shuffle itself.  She said yes, but rejected that it is not realistic.

4.2.13.3  Discussion

P. B. seemed to vaguely understand the concepts of objects and classes.  However, she was on the right track, and we expected that, when finishing this exercise, she would realize their differences.  P. B. was over-modeling this problem by letting both players flip their top cards on the stacks at the same time.
        We unsuccessfully convinced P. B. using the handshaking scenario and the convenience of having a deck that shuffle itself.  When discussing this with Prof. Biswas, he thought the usefulness of methods we had were from the programming aspect.  We must look at it from a modeling aspect to find an explanation that was reasonable to a non-programmer.

4.2.13.4  Summary

P. B. had the same problem as S. J. that they both did not include the interactions between objects into the models.  The examples that were unsuccessful with S. J. were also unsuccessful to P. B.  Surpassingly, JJ, who was an intermediate programmer, did not concern the interactions also.  Thus, this problem seemed to belong to the OO modeling novices instead of the programming beginners.

We could refine our OOP modeling steps as follows:

1. Write a normal scenario.
2. Refine the scenario so that an action has a performer.
3. Select the objects from all sentences in the scenario using knowledge on basic sentences in English.  List all nouns that are subjects and direct and indirect objects.
4. Define methods for each object.  For each step, a method is assigned to the direct objects in the sentence.

 4.2.14  Interview # 19 with P. B.

4.2.14.1  Plan

The goal of this interview was to find out how a learner saw that methods are necessary for objects.  Richard Holt [Holt94] research caught our attention.  He stated that the most important concept in OOP was information hiding enforcing in objects.  Then, the handshaking example seemed to not make sense for the concept.  Holt also said that an object was a black box, which meant it was encapsulated. Why an object must be encapsulated?  Because there would be some action that trigger the change of an object's state, and the state should be changed by the object itself.
        The state change sounded like a circular explanation in the first place.  However, the fact was true in the real world.  If you heated up water, you performed the action, but it was the water's temperature that was changed not you.  Do you know absorb the heat and put it in the water?  No, the water absorbed the heat and was boiled regardless of the fact that you put it on a range.  Finally, we could look at the problem from a different angle, especially from the real world one.  The next thing to do was to try it.

4.2.14.2  Results

P. B. now accepted that the fact made sense to her, but still had a difficult time looking at the problem from the angle we suggested.  Since her thought for this card game was very concentrated to the players, it was not easy for her to see that in OOP only whose and how a state was changed.  [UML documents]

4.2.14.3  Discussion

We already brought P. B. pass the same problem that S. J. had.  However, there existed one more problem: how to convince a learner to look around?

4.2.14.4  Summary

Now the only problem left was how to convince an OOP beginner to take their minds of from "who does what", and focus on "what is changed on whom" instead.  We thought that our paper puzzle still would be a good help.  Altering all steps written in the active voice to the passive one would give a perfect aspect of what was going on in an OOP model in the OOP fashion.

Our refined steps is shown below in details:

1. Write a normal scenario.
2. Refine the scenario so that each step has only one action.  Since a computer can do one thing at a time, we can give it only one thing to do in each step.
3. Select the objects from all sentences in the scenario using knowledge on basic sentences in English.  List all nouns that are subjects and direct and indirect objects.
4. Define methods for each object.  For each step, a method is assigned to the direct objects in the sentence, which is the one that it state is altered by the subject of the step.

4.2.11  Interview # 15 with S. J.

4.2.11.1  Plan

Finish the program.

4.2.11.2  Results

Details of card game

4.2.11.3  Discussion

4.2.11.4  Summary

At the end of this interview, S. J. still had the problem of not going into detials of defining everything.

5.  Analysis

5.1  Problem Classification

• Are not concerned with state variables.  If they are, they do not know how to implement them.  They don't see the need to predefine attributes. (S. J. and P. B.)
• Methods belong to their performers. (Problem 3: S. J., P. B.)
• No need for methods. (S. J. and PB)
• Properties are fixed once the object is created.

• Do not use OOA/D (RN, JJ, Rappin's paper)
• "Is a" vs. "Has a" (Problems 7 and 10: JJ and R. N., and somewhere)
• Class versus Object

5.1.3 Common problems of both groups

• Have action-oriented thinking. (P. B., S. J., JJ)
• Properties versus Object (i.e., RedCar is a class, class FaceValue) (JJ, Brandon)
• Problems from programming languages (S. J., P. B., and JJ)
• Students new to modeling may not know how to model some events and/or may excessively model events.  Do not know how to abstract (Problem 1: S. J., P. B., B.S., JJ, Nathan)
• Overlapping methods (P. B. and JJ)

5.2  Exercise Analysis

5.3  Learner Analysis

R. N.: From CS 270 class, he had seen an OO example in C++.  At that time, the instructor introduced a class and its object.  In the interviews, he showed that he understood the basic principles of OOA/D.  However, he thought that "object" and "class" were interchangeable.  We spent so much time trying to correct this that he became discouraged and quit.  We realized that a sense of achievement is a driving factor for a student to learn.

JJ: When he first came to us he did not know how to model in OOP.  Albeit he had programming experience, it was difficult for him to covert to the object-oriented paradigm.  By the time the interviews were finished, he could reduce the complexity of his original model to a proper level of abstraction of the problem.

Brandon:  He had no programming experience but he was able to model the example with relative success.  He knew what he wanted each object to do and how it should be defined but he did not realize that each object's variables can be modified over time by its methods.  This is taken for granted in programming and this lack of knowledge prevented Brandon from completing the model.

Nathan:  He did not have any difficulty modeling nor did he stumble while using objects. OOP may be a natural thinking for process for him. Since Nathan was the second to last student interviewed, his success gives us hope that either our example has improved drastically from the beginning and/or we are becoming better coaches.

P. B.:  She has shown a strong potential to be a good learner.  We cannot evaluate of her knowledge on OO modeling yet since we have not finished Unit 1.  The greatest point about her is that she asks when she doubts.  Therefore, we derive more accurate problems on her learning OO modeling.  Conclusively, she helps both us and herself to learn effectively.

5.4  Coaching Evaluation

1. Help too much. Steer student in the right direction before letting them think about the problem enough.
2. Jumping around
3. We improved in coaching skill after each interview

6.  Conclusion

 

Unit 1:	Essentials of modeling, objects, classes, message passing, and encapsulation
Unit 2:	The importance of information hiding and encapsulation
Unit 3:	Inheritance, Hierarchy, Modularity, and Reusability
Unit 4:	Polymorphism

Unit 1 Goal for students: Create an OOP model to solve the problem
Subgoals:

1. How to abstract a problem.
2. How to extract objects from the problem.
3. Derive classes from the nominated objects.
4. Define methods and attributes for each class.
5. Use the classes and its object to build a complete and correct model.

Unit 1 Strategy:

1. Introduction to OOP: Its advantages
2. Introduction to modeling: Why designing not programming
3. A real-world example, War.  A student is asked to:
1. Write a scenario of the game. (Abstraction)
2. Refine the scenario until each step has only one action.
3. Convert each step written in the active sense to the passive sense, omitting the "by" part.  For example, "player shuffles deck" is converted to "deck is shuffled."
4. >From the scenario, list all unique objects.
5. Group similar objects to define classes.
6. Put in details: Define data of each class and the accompanying methods.  Remember that a method belongs to the object it changes.
7. Check the model integrity.  Refine the above process until the model is stable.
4. Testing: Ask the student the following questions:
1. What are the differences between a "class" and an "object"?
2. Does a class need an object to exist?
3. Does an object need a class to exist?
If fails, lead the student back to their model, and ask her why she includes each particular thing into her model.

7.  Reference

 

[Baker]	Baker, Michael. "The Roles of Models in Artificial Intelligence and Educational Research: A Prospective View". International Journal of Artificial Intelligence in Education. 11. 2000.
[Bergin]	Bergin, Joseph. Pedagogical Patterns. "http://csis.pace.edu/~bergin/PedPat1.2.html".
[Booch]	Booch, Grady. Object-Oriented Analysis and Design with Applications. 2nd ed. Redwood City: Benjamin/Cummings Publishing, 1994.
[Chi]	Chi, Michelene T. H, Nicholas de Lefuw, Mei-Hung Chu, and Christian LaVancher. "Eliciting Self-Explanations Improves Understanding", Cognitive Science, volume 18, 1994. pp. 439 - 477.
[Holt94]	Holt, Richard. "Object-Oriented Programming in High Schools the Turing way". Recreating the Revolution: Proceedings of the Annual National Educational Computing Conference (15th).  Boston, 1994.
[Rappin1]	Rappin, Noel. Helping Students Learn To Model by Focusing Complexity of Modeling and Simulation Tools. "http://www.cc.gatech.edu/gvu/edtech/BOOST/proposal.html".
[Rappin2]	Rappin, Noel. BOOST Thesis Proposal Presentation. "http://www.cc.gatech.edu/gvu/edtech/BOOST/proposaltalk/index.htm".
[Rappin3]	Rappin, Noel. A Road Map For OOA and OOD. "http://www.gvu.gatech.edu/edtech/BOOST/designmap.html".
[Rappin5]	Rappin, Noel. On the Design of a Modeling Tool for Students of Object-Oriented Programming. "http://www.cc.gatech.edu/gvu/edtech/BOOST/ESPPaper.html".