第五章 結論與建議
第二節 建議
根據本次研究之迷思概念診斷與矯正的教學模式進行過程，所面臨的相關問題，提供以下教 學之建議，期望未來若有相關程式設計迷思概念之教學研究時，在資料蒐集與實際教學運用時更 加順利。
一、 迷思概念項目建置更完善
可以將迷思概念的主題與內容建置的更廣闊，加入非初學程式語言的迷思概念部分，或是 可以連結、應用到其它的程式語言。而迷思概念的項目可以有更明確的判斷原則與相關範例，
利於後續的診斷作業。
二、 系統之迷思概念診斷
系統的自動診斷功能，可以配合更多元化的題型，並能正確的診斷迷思概念。可以偵測使用 者輸入的全部程式碼，再篩選出關鍵之程式碼，進行一系列的迷思概念診斷流程。不過由於錯誤 的語法或迷思概念，導致程式無法執行或輸出結果不正確的排列組合狀況非常多，所以在何時判 定語法與何種診斷迷思概念的模式影響甚大。
三、 矯正回饋資料
矯正資料的完善建置，根據每個迷思概念都可以有多元的矯正資料，包含圖文、動畫、概 念圖、流程圖，如可以配合相關的概念，且設計出針對此概念的動手實作輔助教材，也可以具 體讓學生體會到該概念的重點。且矯正資料的給予時機，都盡量在發生此迷思概念當下，即時 的回饋給學習者是有較好的成效。
68
參考文獻
中文部份
陳建偉. (2008). 高三學生液體界面現象迷思概念之研究 A Study of Misconceptions of Liquid Interface Phenomenon of the 12th Graders (pp. 1–120).
彭泰源, & 張惠博. (1999). 國小五年級學童力與運動概念學習之研究.
廖焜熙. (2001). 理化科學概念及過程技能之研究回顧與分析.
英文部份
0zdener, N. (2008). A comparison of the misconceptions about the time-efficiency of algorithms by various profiles of computer-programming students. Computers and Education, 51(3), 1094–
1102. http://doi.org/10.1016/j.compedu.2007.10.008
Akbaş, Y., & Gençtürk, E. (2011). The effect of conceptual change approach to eliminate 9th grade high school students’ misconceptions about air pressure. Kuram ve Uygulamada Egitim Bilimleri,
11(4), 2217–2222.
Anseel, F., Lievens, F., & Schollaert, E. (2009). Reflection as a strategy to enhance task performance after feedback. Organizational Behavior and Human Decision Processes, 110(1), 23–35.
http://doi.org/10.1016/j.obhdp.2009.05.003
Baker, B. S. (1992). A Program for Identifying Duplicated Code. Computing Science and Statistics, 24, 49–57.
Bayman, P., & Mayer, R. E. (1983). A diagnosis of beginning programmers’ misconceptions of BASIC programming statements.
Communications of the ACM, 26(9),
677–679.http://doi.org/http://doi.acm.org/10.1145/358172.358408
Bonar, J., & Soloway, E. (1985). Preprogramming Knowledge: A Major Source of Misconceptions in Novice Programmers.
Human-Computer Interaction, 1(2),
133–161.http://doi.org/10.1207/s15327051hci0102_3
Booth, J. L. (2011). Why Can’t Students Get the Concept of Math ?, (October), 31–35.
Branch, W. T., & Paranjape, A. (2002). Feedback and Reflection: Teaching Methods for Clinical Settings.
Academic Medicine : Journal of the Association of American Medical Colleges, 77(12 Pt 1),
1185–1188. http://doi.org/10.1097/00001888-200212000-0000569
Brandt, C. (2008). Integrating feedback and reflection in teacher preparation. ELT Journal, 62(1), 37–46.
http://doi.org/10.1093/elt/ccm076
Brinko, K. T. (2008). The Practice of Giving Feedback to Improve Teaching. The Journal of Higher
Education, 64(5), 574–593.
Britos, P., Rey, E. J., Rodríguez, D., & García-martínez, R. (2008). Work in Progress - Programming Misunderstandings Discovering Process Based On Intelligent Data Mining Tools, 1–2.
Chen, C.-L., Cheng, S.-Y., & Lin, J. M.-C. (2012). A study of misconceptions and missing conceptions of novice Java programmers, 1–7. Retrieved from http://worldcomp-proceedings.com/proc/p2012/FEC2866.pdf
Chen, M.-P. (2007). The Effects of Instructional Approach and Programming Tools on Novices’
Learning Computer Programming. Journal of Taiwan Normal University: Science Education,
52(1&2), 1–21. http://doi.org/10.6300/JNTNU.2007.52.01
Chick, H. L., & Baker, M. (2005). Investigating Teachers’Responses To Student Misconceptions.
Psychology of Mathematics Education, 2,
249–256. Retrieved from http://www.emis.ams.org/proceedings/PME29/PME29CompleteProc/PME29Vol2Adl_Fre.pd f#page=255Danielsiek, H., Paul, W., & Vahrenhold, J. (2012). Detecting and Understanding Students’
Misconceptions Related to Algorithms and Data Structures. ACM Technical Symposium on
Computer Science Education (2012), 21–26. http://doi.org/10.1145/2157136.2157148
Du Boulay, B. (1986). Some Difficulties of Learning to Program. Journal Of Educational Computing
Research, 2(1), 57–73. http://doi.org/10.2190/3LFX-9RRF-67T8-UVK9
Eckerdal, A., & Thuné, M. (2005). Novice Java programmers’ conceptions of “object” and “class”, and variation theory. ACM SIGCSE Bulletin, 37(3), 89. http://doi.org/10.1145/1151954.1067473 Goldman, K., Gross, P., Heeren, C., Herman, G., Kaczmarczyk, L., Loui, M. C., & Zilles, C. (2008).
Identifying important and difficult concepts in introductory computing courses using a delphi process. ACM SIGCSE Bulletin, 40(1), 256. http://doi.org/10.1145/1352322.1352226
Hancock, C. H. (1940). An evaluation of certain popular science misconceptions. Science Education,
24(4), 208–213. http://doi.org/10.1002/sce.3730240409
Hattie, J., & Timperley, H. (2007). The Power of Feedback. Review of Educational Research, 77(1), 81–
112. http://doi.org/10.3102/003465430298487
Holland, S., Griffiths, R., Woodman, M., Hall, W., Keynes, M., & Kingdom, U. (1997). Avoiding Object Misconceptions. SIGCSE Technical Symposium on Computer Science Education, 29 Issue 1, 131–134.
70
Hwang, W. Y., Shadiev, R., Wang, C. Y., & Huang, Z. H. (2012). A pilot study of cooperative programming learning behavior and its relationship with students’ learning performance.
Computers and Education. http://doi.org/10.1016/j.compedu.2011.12.009
Kaczmarczyk, L. C., Petrick, E. R., East, J. P., & Herman, G. L. (2010). Identifying student misconceptions of programming. Proceedings of the 41st ACM Technical Symposium on
Computer Science Education - SIGCSE ’10,
107–111.http://doi.org/10.1145/1734263.1734299
Lahtinen, E., Ala-Mutka, K., & Järvinen, H.-M. (2005). A study of the difficulties of novice programmers.
ACM SIGCSE Bulletin, 37(3), 14. http://doi.org/10.1145/1151954.1067453
Lwo, L. S., Chang, C. C., Tung, Y. P., & Yang, W. C. (2013). Marine science literacy and misconceptions among senior high school students. Journal of Research in Education Sciences, 58(3), 51–83.
http://doi.org/10.6209/JORIES.2013.58(3).03
Moons, J., & De Backer, C. (2013). The design and pilot evaluation of an interactive learning environment for introductory programming influenced by cognitive load theory and constructivism.
Computers & Education, 60(1),
368–384.http://doi.org/10.1016/j.compedu.2012.08.009
Morales, Z. A. (2014). Analysis of Students ’ Misconceptions and Error Patterns in Mathematics : The Case of Fractions, 1–10.
Perkins, D., & Martin, F. (1986). Fragile knowledge and neglected strategies in novice programmers. In
Empirical studies of programmers
(pp. 213–229). Retrieved from http://books.google.com/books?hl=en&lr=&id=sswoYivNQVUC&oi=fnd&pg=PA213&dq=Fragile+Knowledge+and+Neglected+Strategies+in+Novice+Programmers&ots=afQcU6lc_F
&sig=z1XL1J_F7uXpWMQ6dATyayoRwao
Perkins, D. N., & Simmons, R. (1988). Patterns of Misunderstanding: An Integrative Model for Science, Math, and Programming.
Review of Educational Research, 58(3),
303–326.http://doi.org/10.3102/00346543058003303
Putnam, R. T., Sleeman, D., Baxter, J. A., & Kuspa, L. K. (1986). A Summary of Misconceptions of High School Basic Programmers. Journal of Educational Computing Research, 2(4), 459–472.
http://doi.org/10.2190/FGN9-DJ2F-86V8-3FAU
Ragonis, N., & Ben-Ari, M. (2005). A long-term investigation of the comprehension of OOP concepts by novices.
Computer Science Education, 15(February
2015), 203–221.http://doi.org/10.1080/08993400500224310
Revival, G. (2014). What is a misconception? Common Misconceptions in Basic Mathematics, 1–46.
http://doi.org/10.1038/sj.embor.7400842
71
Rittle-Johnson, B., & Schneider, M. (2015). Developing conceptual and procedural knowledge of mathematics.
Oxford Handbook of Numerical Cognition,
1118–1134.http://doi.org/10.1093/oxfordhb/9780199642342.013.014
Running, D. M., Ligon, J. B., & Miskioglu, I. (2016). Individual Differences in Perception of Applied Music Teaching Feedback. Journal of Composite Materials, 33(10), 928–940.
http://doi.org/0803973233
Rutar, N. (University of M., Almazan, C. (University of M., & Foster, J. (University of M. (2004). A comparison of bug finding tools for Java. International Symposium on Software Reliability
Engineering (ISSRE), 245–256. http://doi.org/10.1109/ISSRE.2004.1
Sanders, K., & Thomas, L. (2007). Checklists for grading object-oriented CS1 programs. ACM SIGCSE
Bulletin, 39(3), 166. http://doi.org/10.1145/1269900.1268834
Sekiya, T., & Yamaguchi, K. (2013). Tracing quiz set to identify novices’ programming misconceptions.
Proceedings of the 13th Koli Calling International Conference on Computing Education Research, 87–95. http://doi.org/10.1145/2526968.2526978
Sirkiä, T., & Sorva, J. (2012). Exploring programming misconceptions: An analysis of student mistakes in visual program simulation exercises. Proceedings - 12th Koli Calling International
Conference on Computing Education Research, Koli Calling 2012,
19–28.http://doi.org/10.1145/2401796.2401799
Spohrer, J. C., & Soloway, E. (1986). Novice Mistakes : Are the Folk Wisdoms Correct ?
Communications of the ACM, 29(7), 10.
Taylor, A. K., & Kowalski, P. (2012). Students ’ misconceptions in Psychology : How you ask matters … sometimes. Journal of the Scholarship of Teaching and Learning, 12(3), 62–77. Retrieved from http://search.proquest.com/docview/1314328305?accountid=13042
Treagust, D. F. (1988). Development and use of diagnostic tests to evaluate students’ misconceptions in science.
International Journal of Science Education, 10(2),
159–169.http://doi.org/10.1080/0950069880100204
Van Den Boom, G., Paas, F., Van Merriënboer, J. J. G., & Van Gog, T. (2004). Reflection prompts and tutor feedback in a web-based learning environment: Effects on students’ self-regulated learning competence.
Computers in Human Behavior, 20(4),
551–567.http://doi.org/10.1016/j.chb.2003.10.001
72 conditional and
loop
Change Variable In Condition
Interpret variables in the conditional part of conditionals as control variables.
Change Variable In Condition 2
Interpret variables in the conditional part of conditionals as the end value of the enclosing loop.
Change Variable In Loop
Interpret variables in conditionals as control variables.
Change Variable In Loop 2
Interpret variables in conditionals as the end value of the enclosing loop.
Change Variable In Simple Loop
Interpret variables in the body of conditionals as control variables.
Neglect(ignore) For Loop
Ignore loop when the body has no control variables.
Regard As Array Interpret substitution to keep the previous values.
Python UUhistle (VPS)
assignment, control structures
, and/or booleans Inverted assignment
The student assigns the value of the left-hand variable to the right-hand side variable, rather than the other way around.
Wrong branch
Even though the conditional evaluates to False, the student jumps to the ‘then’ clause.
Wrong False
As soon as the conditional evaluates to False , the student proceeds to return False from the function.
Conditional into accessed variable
After evaluating the expression, the student assigns its value to divisor.
Conditional into loop control variable
After evaluating the expression, the student assigns its value to i.
functions object-oriented
topics Executing function instead of defining it
The def command defines a new function: the student is supposed to store the function (object) in memory.Instead, the student starts executing the function body.
Unevaluated parameters
The student tries to start the function call before they have evaluated the sum.
Parameter in the wrong frame
The student creates parameter variables in the caller’s frame, not in the callee’s.
Misplacing return value
The student creates the variable result in calculate’s frame instead of returning the value.
Return value into variable
The student assigns the result of the
multiplication back into the variable intermediate.
73 Failing to store return value
After returning a value, the student does not store assign the return value to the caller’s local variable.Instead, they fetch the function call to the evaluation area again.
Assignment copies object
The student creates a new object rather than copying a reference.
Failing to create second object of a class
A new object should be created, but the student instead makes a copy of a a reference to an existing object.
Local variable becomes instance variable
Instead of creating a new local variable to store the reference, the student creates an instance variable for the new object.
Instance variable becomes local variable
Instead of creating a new instance variable for the object, the student creates a new local variable.
Method call without recipient
The student tries to call the method fuel from the Car class before accessing the variable for a reference to the target object.
Assigning reference to uninitialized object
The student assigns the reference to the variable before calling the __init__ method.
Returning self-reference instead of dereferencing it
The student returns self rather than the value of the instance variable __profession.
CS1 programing Java
memory models, and data assignment
T1: Students misunderstand the relationship between language
Semantics to semantics (Student applies real-world semantic understanding to variable declarations.)
elements and underlying memory usage.
All Objects same size (Student thinks all Objects are allocated the same amount of memory regardless of definition and instantiation.)
Instantiated no memory allocation (Student thinks no memory is allocated for an instantiated
Object.)
Uninstantiated memory allocation (Student thinks memory is allocated for an uninstantiated
Object.)
Off by 1 array construction (Student thinks an array's construction goes from 0 to length, inclusive.)
Primitive no default (Student thinks primitive types have no default value.)
Primitives don't have memory (Student thinks primitives without a value have no memory allocated.)
T2: Students misunderstand the process of while loop operation.
T3: Students lack a basic understanding of the Object concept T4: Students cannot trace code linearly.
74 Java(Greenfoot)
object- oriented concepts
Static data members vs. constant data members
Confused the properties of static data members with constant data members
certain programming constructs
Classes vs. Objects
Failed to recognize that classes were actually user-defined data types that could be used to define variables just like built-in data types such as integer and Boolean
Constructors
(1) Erroneously thought that constructors of all classes defined in a project were invoked automatically when the project was opened (2) Defined the constructor(s) of a class as its private member(s) when they should be public members instead
(3) Did not realize that constructors, as a special type of method, did not require a return type Arguments passing for
method calls
Confused formal parameters with actual parameters
Polymorphism
(1) Mistakenly considered that declaring one superclass variable instead of two subclass variables means declaring two variables at the same line
(2) Mistakenly considered that referencing two subclass objects successively by the same superclass variable means substituting two superclass objects for two subclass objects
Access modifiers of methods
Mistakenly considered that a private method could not invoke methods defined in other classes
OOP
Java(BlueJ)
1.Object vs. Class 1.1: The nature of a class as a template
1.1.1 Difficulties in understanding the static aspect of the class definition.
1.1.2 Difficulties in understanding that a method can be invoked on any object of the class.
1.1.3 Misconception: You can define a method that doesn’t access any attribute.
1.1.4 Misconception: You can define a method that adds an attribute to the class.
1.1.5 Difficulties in understanding the classification of methods that we used (constructors, mutators, accessors, ‘‘others’’).
1.1.6 Misconception: You can invoke a method on an object only once.
1.2: Connections between objects and classes.
1.2.1 Misconception: A class is a collection of objects, rather than a template for creating objects.
1.2.2 Misconception: You can define a non-constructor method to create a new object.
1.2.3 Misconception: You can define a method that replaces the object itself.
1.2.4 Misconception: You can define a method that destroys the object itself.
1.2.5 Misconception: You can define a method that divides the object into two different objects.
1.3: Object creation
1.3.1 Difficulties in understanding the process of creating an object.
75 1.4: Identification of objects.
1.4.1 Misconception: Two objects of the same class cannot have equal values for their attributes.
1.4.2 Misconception: Two objects can have the same identifier if there is any difference in the values of their attributes.
1.4.3 Misconception: An attribute value can be used as the object identifier.
1.4.4 Misconception: The object identifier is one of the object’s attributes.
1.4.5 Difficulties recognizing an object due to multiple representations (the set of values of attributes, the BlueJ icon and the graphical rendering).
2.Instantiation and Constructors
2.1: General understanding of instantiation.
2.1.1 Misconception: There is no need to invoke the constructor method, because its definition is sufficient for object creation.
2.1.2 Misconception: Constructors can include only assignment statements to initialize attributes.
2.1.3 Misconception: Instantiation involves only the execution of the constructor method body, not the allocation of memory.
2.1.4 Misconception: Invocation of the constructor method can replace its definition.
2.2: Understanding instantiation in a composed class.
2.2.1 Misconception: If objects of the simple class already exist, there is no need to create the object of the composed class.
2.2.2 Misconception: Creation of an object of a composed class automatically creates objects of the simple class that appear as attributes of the composed class.
2.2.3 Difficulties in understanding where objects of the simple class are created,before the creation of the object of the composed class.
2.3: Understanding instantiation is affected by its implementation
in the
programming language.
2.3.1 Difficulties understanding the empty constructor.
2.3.2 Difficulties understanding objects if their attributes are not explicitly initialized.
2.3.3 Initializing an attribute with a constant as part of its declaration causes confusion in distinguishing between a class and an object.
2.3.4 Initializing an attribute with a constant within the constructor declaration causes confusion in distinguishing between a class and an object.
2.3.5 Misconception: If the attributes are initialized in the class declaration there is no need to create objects.
3.Simple vs.
Composed Classes
3.1: Understanding encapsulation.
3.1.1 Misconception: An object cannot be the value of an attribute.
3.1.2 Misconception: The attributes of the composed class include all the attributes of the objects of a simple class, instead of the objects themselves.
76
3.1.3 Misconception: The attributes of the composed class include all the attributes of the objects of a simple class, in addition to the objects themselves.
3.1.4 Misconception: Methods that are declared in the simple class have to be declared again in the composed class for each of the simple objects.
3.1.5 Misconception: There is no need for mutators and accessors for attributes that are of the simple class within the composed class.
3.1.6 Misconception: To change the value of an attribute of an object of a simple class that is the value of an attribute in an object of a composed class, you need to construct a new object.
3.1.7 Misconception: Methods can only be invoked on objects of the composed class, not on objects of the simple class defined as values in its attributes.
3.2: Understanding modularity.
3.2.1 Misconception: After a composed class is defined, new methods cannot be defined in the simple class.
3.2.2 Methods from the simple class are not used; instead, new equivalent methods are defined and duplicated in the composed class.
3.2.3 Methods in different classes are not distinguished if they have the same signature.
3.3: The class as a collection of objects.
3.3.1 Misconception: Objects of a simple class, used as values of the attributes of a composed class, have to be identical.
3.3.2 Misconception: In a composed class you can develop a method that adds an attribute of a simple class to the composed class.
3.3.3 Misconception: In a composed class you can develop a method that removes an attribute of a simple class from the composed class.
3.4: Understanding information hiding.
3.4.1 Misconception: Attributes of the simple class must be directly accessed from the composed class instead of through an interface.
3.5: Personification.
3.5.1 Misconception: Attributes in a simple class are automatically replicated in the composed class by transferring its meaning.
3.6: Understanding invocation on the implicit object.
3.6.1 Misconception: A method must always be invoked on an explicit object. (We did not teach the use of an explicit ‘‘this,’’ so the students invented an imaginary object upon which to invoke the method.)
4.Program Flow 4.1: Understanding executions of methods.
4.1.1 Misconception: Methods are executed according to their order in the class definition.
4.1.2 Misconception: Every method can be invoked only once.
4.1.3 Difficulties distinguishing when there is a need to explicitly write the identifier of the object.
4.1.4 Difficulties understanding the influence of method execution on the object state.
77
4.1.5 Difficulties understanding the invocation of a method from another method.
4.2: Understanding data flow.
4.2.1 Where do the values of the parameters come from?
4.2.2 To where does the return value of a method go?
4.3: Things happen with no cause.
4.3.1 Misconception: Objects are created by themselves.
4.3.2 Misconception: Attributes values are updated automatically according to a logical context.
4.3.3 Misconception: The system does not allow unreasonable operations.
4.4: ‘‘How does the computer know?’’
4.4.1 How does the computer know what the class attributes and methods are?
4.4.1 How does the computer know what the class attributes and methods are?