\documentclass[11pt,twoside]{article}\makeatletter \IfFileExists{xcolor.sty}% {\RequirePackage{xcolor}}% {\RequirePackage{color}} \usepackage{colortbl} \usepackage{wrapfig} \usepackage{ifxetex} \ifxetex \usepackage{fontspec} \usepackage{xunicode} \catcode`⃥=\active \def⃥{\textbackslash} \catcode`❴=\active \def❴{\{} \catcode`❵=\active \def❵{\}} \def\textJapanese{\fontspec{Noto Sans CJK JP}} \def\textChinese{\fontspec{Noto Sans CJK SC}} \def\textKorean{\fontspec{Noto Sans CJK KR}} \setmonofont{DejaVu Sans Mono} \else \IfFileExists{utf8x.def}% {\usepackage[utf8x]{inputenc} \PrerenderUnicode{–} }% {\usepackage[utf8]{inputenc}} \usepackage[english]{babel} \usepackage[T1]{fontenc} \usepackage{float} \usepackage[]{ucs} \uc@dclc{8421}{default}{\textbackslash } \uc@dclc{10100}{default}{\{} \uc@dclc{10101}{default}{\}} \uc@dclc{8491}{default}{\AA{}} \uc@dclc{8239}{default}{\,} \uc@dclc{20154}{default}{ } \uc@dclc{10148}{default}{>} \def\textschwa{\rotatebox{-90}{e}} \def\textJapanese{} \def\textChinese{} \IfFileExists{tipa.sty}{\usepackage{tipa}}{} \fi \def\exampleFont{\ttfamily\small} \DeclareTextSymbol{\textpi}{OML}{25} \usepackage{relsize} \RequirePackage{array} \def\@testpach{\@chclass \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else \ifnum \@lastchclass=7 5 \else \ifnum \@lastchclass=8 \tw@ \else \ifnum \@lastchclass=9 \thr@@ \else \z@ \ifnum \@lastchclass = 10 \else \edef\@nextchar{\expandafter\string\@nextchar}% \@chnum \if \@nextchar c\z@ \else \if \@nextchar l\@ne \else \if \@nextchar r\tw@ \else \z@ \@chclass \if\@nextchar |\@ne \else \if \@nextchar !6 \else \if \@nextchar @7 \else \if \@nextchar (8 \else \if \@nextchar )9 \else 10 \@chnum \if \@nextchar m\thr@@\else \if \@nextchar p4 \else \if \@nextchar b5 \else \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi} \gdef\arraybackslash{\let\\=\@arraycr} \def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}} \def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}} \def\abbr{} \def\corr{} \def\expan{} \def\gap{} \def\orig{} \def\reg{} \def\ref{} \def\sic{} \def\persName{}\def\name{} \def\placeName{} \def\orgName{} \def\textcal#1{{\fontspec{Lucida Calligraphy}#1}} \def\textgothic#1{{\fontspec{Lucida Blackletter}#1}} \def\textlarge#1{{\large #1}} \def\textoverbar#1{\ensuremath{\overline{#1}}} \def\textquoted#1{‘#1’} \def\textsmall#1{{\small #1}} \def\textsubscript#1{\@textsubscript{\selectfont#1}} \def\textxi{\ensuremath{\xi}} \def\titlem{\itshape} \newenvironment{biblfree}{}{\ifvmode\par\fi } \newenvironment{bibl}{}{} \newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par } \newenvironment{citbibl}{}{\ifvmode\par\fi } \newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi } \newenvironment{docDate}{}{\ifvmode\par\fi } \newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi } \newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par } \newenvironment{msHead}{\vskip 6pt}{\par} \newenvironment{msItem}{\vskip 6pt}{\par} \newenvironment{rubric}{}{} \newenvironment{titlePart}{}{\par } \newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}} \newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}} \newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}} \newcolumntype{P}[1]{){\arraybackslash}p{#1}} \newcolumntype{B}[1]{){\arraybackslash}b{#1}} \newcolumntype{M}[1]{){\arraybackslash}m{#1}} \definecolor{label}{gray}{0.75} \def\unusedattribute#1{\sout{\textcolor{label}{#1}}} \DeclareRobustCommand*{\xref}{\hyper@normalise\xref@} \def\xref@#1#2{\hyper@linkurl{#2}{#1}} \begingroup \catcode`\_=\active \gdef_#1{\ensuremath{\sb{\mathrm{#1}}}} \endgroup \mathcode`\_=\string"8000 \catcode`\_=12\relax \usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry} \usepackage{framed} \definecolor{shadecolor}{gray}{0.95} \usepackage{longtable} \usepackage[normalem]{ulem} \usepackage{fancyvrb} \usepackage{fancyhdr} \usepackage{graphicx} \usepackage{marginnote} \renewcommand{\@cite}[1]{#1} \renewcommand*{\marginfont}{\itshape\footnotesize} \def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif} \pagestyle{fancy} \usepackage[pdftitle={Students' Understanding of an Object-Oriented Design Task -A Case Study}, pdfauthor={}]{hyperref} \hyperbaseurl{} \paperwidth210mm \paperheight297mm \def\@pnumwidth{1.55em} \def\@tocrmarg {2.55em} \def\@dotsep{4.5} \setcounter{tocdepth}{3} \clubpenalty=8000 \emergencystretch 3em \hbadness=4000 \hyphenpenalty=400 \pretolerance=750 \tolerance=2000 \vbadness=4000 \widowpenalty=10000 \renewcommand\section{\@startsection {section}{1}{\z@}% {-1.75ex \@plus -0.5ex \@minus -.2ex}% {0.5ex \@plus .2ex}% {\reset@font\Large\bfseries}} \renewcommand\subsection{\@startsection{subsection}{2}{\z@}% {-1.75ex\@plus -0.5ex \@minus- .2ex}% {0.5ex \@plus .2ex}% {\reset@font\Large}} \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% {-1.5ex\@plus -0.35ex \@minus -.2ex}% {0.5ex \@plus .2ex}% {\reset@font\large}} \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% {-1ex \@plus-0.35ex \@minus -0.2ex}% {0.5ex \@plus .2ex}% {\reset@font\normalsize}} \renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% {1.5ex \@plus1ex \@minus .2ex}% {-1em}% {\reset@font\normalsize\bfseries}} \def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt} \@tempdima 1.5em \begingroup \parindent \z@ \rightskip \@pnumwidth \parfillskip -\@pnumwidth \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par \endgroup} \def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}} \def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}} \def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}} \def\l@subparagraph{\@dottedtocline{5}{10em}{5em}} \@ifundefined{c@section}{\newcounter{section}}{} \@ifundefined{c@chapter}{\newcounter{chapter}}{} \newif\if@mainmatter \@mainmattertrue \def\chaptername{Chapter} \def\frontmatter{% \pagenumbering{roman} \def\thechapter{\@roman\c@chapter} \def\theHchapter{\roman{chapter}} \def\thesection{\@roman\c@section} \def\theHsection{\roman{section}} \def\@chapapp{}% } \def\mainmatter{% \cleardoublepage \def\thechapter{\@arabic\c@chapter} \setcounter{chapter}{0} \setcounter{section}{0} \pagenumbering{arabic} \setcounter{secnumdepth}{6} \def\@chapapp{\chaptername}% \def\theHchapter{\arabic{chapter}} \def\thesection{\@arabic\c@section} \def\theHsection{\arabic{section}} } \def\backmatter{% \cleardoublepage \setcounter{chapter}{0} \setcounter{section}{0} \setcounter{secnumdepth}{2} \def\@chapapp{\appendixname}% \def\thechapter{\@Alph\c@chapter} \def\theHchapter{\Alph{chapter}} \appendix } \newenvironment{bibitemlist}[1]{% \list{\@biblabel{\@arabic\c@enumiv}}% {\settowidth\labelwidth{\@biblabel{#1}}% \leftmargin\labelwidth \advance\leftmargin\labelsep \@openbib@code \usecounter{enumiv}% \let\p@enumiv\@empty \renewcommand\theenumiv{\@arabic\c@enumiv}% }% \sloppy \clubpenalty4000 \@clubpenalty \clubpenalty \widowpenalty4000% \sfcode`\.\@m}% {\def\@noitemerr {\@latex@warning{Empty `bibitemlist' environment}}% \endlist} \def\tableofcontents{\section*{\contentsname}\@starttoc{toc}} \parskip0pt \parindent1em \def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}} \newenvironment{reflist}{% \begin{raggedright}\begin{list}{} {% \setlength{\topsep}{0pt}% \setlength{\rightmargin}{0.25in}% \setlength{\itemsep}{0pt}% \setlength{\itemindent}{0pt}% \setlength{\parskip}{0pt}% \setlength{\parsep}{2pt}% \def\makelabel##1{\itshape ##1}}% } {\end{list}\end{raggedright}} \newenvironment{sansreflist}{% \begin{raggedright}\begin{list}{} {% \setlength{\topsep}{0pt}% \setlength{\rightmargin}{0.25in}% \setlength{\itemindent}{0pt}% \setlength{\parskip}{0pt}% \setlength{\itemsep}{0pt}% \setlength{\parsep}{2pt}% \def\makelabel##1{\upshape ##1}}% } {\end{list}\end{raggedright}} \newenvironment{specHead}[2]% {\vspace{20pt}\hrule\vspace{10pt}% \phantomsection\label{#1}\markright{#2}% \pdfbookmark[2]{#2}{#1}% \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}% }{} \def\TheFullDate{2020-01-15 (revised: 15 January 2020)} \def\TheID{\makeatother } \def\TheDate{2020-01-15} \title{Students' Understanding of an Object-Oriented Design Task -A Case Study} \author{}\makeatletter \makeatletter \newcommand*{\cleartoleftpage}{% \clearpage \if@twoside \ifodd\c@page \hbox{}\newpage \if@twocolumn \hbox{}\newpage \fi \fi \fi } \makeatother \makeatletter \thispagestyle{empty} \markright{\@title}\markboth{\@title}{\@author} \renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@ \belowdisplayskip \abovedisplayskip \abovedisplayshortskip \z@ plus2\p@ \belowdisplayshortskip 4\p@ plus2\p@ minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 2\p@ plus1\p@ minus1\p@ \parsep 2\p@ plus\p@ minus\p@ \itemsep 1pt} } \makeatother \fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm} \fancyhf{} \setlength{\headheight}{14pt} \fancyhead[LE]{\bfseries\leftmark} \fancyhead[RO]{\bfseries\rightmark} \fancyfoot[RO]{} \fancyfoot[CO]{\thepage} \fancyfoot[LO]{\TheID} \fancyfoot[LE]{} \fancyfoot[CE]{\thepage} \fancyfoot[RE]{\TheID} \hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true} \fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}} \date{} \usepackage{authblk} \providecommand{\keywords}[1] { \footnotesize \textbf{\textit{Index terms---}} #1 } \usepackage{graphicx,xcolor} \definecolor{GJBlue}{HTML}{273B81} \definecolor{GJLightBlue}{HTML}{0A9DD9} \definecolor{GJMediumGrey}{HTML}{6D6E70} \definecolor{GJLightGrey}{HTML}{929497} \renewenvironment{abstract}{% \setlength{\parindent}{0pt}\raggedright \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}} \vskip16pt \textcolor{GJBlue}{\large\bfseries\abstractname\space} }{% \vskip8pt \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}} \vskip16pt } \usepackage[absolute,overlay]{textpos} \makeatother \usepackage{lineno} \linenumbers \begin{document} \author[1]{Andreas Febrian} \author[2]{Oenardi Lawanto} \renewcommand\Authands{ and } \date{\small \em Received: 15 December 2019 Accepted: 4 January 2020 Published: 15 January 2020} \maketitle \begin{abstract} Students must understand a problem accurately to solve it correctly. Unfortunately, numerous studies reported that students only have a partial understanding of the information presented in the problem description, including in computer science. This study assesses students' task and revised-task interpretations when working on an objectoriented design problem. Multiple qualitative case study research was used in this study. Two male1 I. Introduction and two female senior computer science students at Utah State University, USA, volunteered as participants. They were asked to solve five programming problems while thinking aloud, complete surveys, and answer several interview questions. The study found that the participants were able to identify most of the essential information after the initial reading of the problem description. They strategically ignore detailed information that may affect their design decisions and update it throughout their problem-solving enterprise. \end{abstract} \keywords{cognition, problem-solving, programming, self-regulation, self-regulated learning, task interpretation, task revision.} \begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) \textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark} \end{textblock*} \begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) \textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}} \end{textblock*} \let\tabcellsep& \section[{Introduction}]{Introduction}\par and two female senior computer science students at Utah State University, USA, volunteered as participants. They were asked to solve five programming problems while thinking aloud, complete surveys, and answer several interview questions. The study found that the participants were able to identify most of the essential information after the initial reading of the problem description. They strategically ignore detailed information that may affect their design decisions and update it throughout their problem-solving enterprise.\par Index terms: cognition, problem-solving, programming, self-regulation, self-regulated learning, task interpretation, task revision. t was a typical day in a programming lab session; students were working on their task under the observation of several teaching assistants. Several students concentrated on solving the lab problem, some were discussing the best approach to solve it, and some others were waiting for the answer from their peers. Interestingly, some students did not even bother to open and read the lab instruction, regardless of suggestion and encouragement from the assistants. While the motivation for their persistence may vary, reading and rereading a problem is a crucial step to understand and solve it \hyperref[b0]{[1]}- \hyperref[b5]{[5]}.\par To accurately understanding a problem is not an easy task. Several studies reported that students are rarely able to interpret a problem correctly \hyperref[b2]{[2]}, \hyperref[b3]{[3]}, \hyperref[b6]{[6]}- \hyperref[b8]{[8]}.Some studies also reported that students' submitted solutions reveal their incomplete understanding of the 1 This paragraph of the first footnote will contain the date on which you submitted your paper for review. It will also contain support information, including sponsor and financial support acknowledgment. For exam ple, "This work was supported in part by the U.S. Department of Commerce under Grant BS123456." This material is based, in part, upon work supported by the National Science Foundation under Grant No. 1148806. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.\par given tasks \hyperref[b2]{[2]}, \hyperref[b8]{[8]}, \hyperref[b9]{[9]}.Although limited in number, similar phenomena also have been reported in the discipline of computer science (CS).Some CS students were reported incapable of accurately inferring the expected program's behaviors based on a given design brief \hyperref[b10]{[10]}. Other study reported that CS students tend to ignore some assessment criteria while working on their tasks, which then negatively impact their grades \hyperref[b11]{[11]}.\par In this study, we aim to describe the approaches used by senior CS students in understanding an object-oriented (OO) design problem; i.e., their initial task interpretation and the changes. Selfregulated learning (SRL) framework is used to distinguish their cognitive and metacognitive activities during the problem-solving endeavor. The description and analysis results may help instructors to understand better, and encourage students to enhance their strategies in comprehending a design problem. The description may also help students to be more aware of their self-regulation so that they can improve it. \section[{II.}]{II.} \section[{Research Questions}]{Research Questions}\par As mentioned earlier, this study aims to describe senior CS students' approaches to understanding an OO design problem. In more specific, this study intends to assess (1) students' initial explicit and implicit task understanding, (2) how their initial understanding changes during the problem-solving activity, and (3) identify factors that influence those changes. \section[{III.}]{III.} \section[{Relevant Literature}]{Relevant Literature}\par Since this study uses SRL as a framework in analyzing the data, the literature will discuss task understanding (or task interpretation) within the SRL. Additionally, this section also discusses known literature on self-regulation in CS to help readers familiar with existing research in that area. \section[{a) Task Interpretation in Self-Regulated Learning}]{a) Task Interpretation in Self-Regulated Learning}\par Students deliberately self-regulate when working on a task \hyperref[b12]{[12]}, \hyperref[b14]{[13]}. Such activity involves the interplay of interpreting a given task, developing a plan, and executing, monitoring, and adjusting the plan to complete the task \hyperref[b4]{[4]}, \hyperref[b5]{[5]}, \hyperref[b14]{[13]}- \hyperref[b17]{[16]}. Fig. {\ref 1 and Table I} presents the relationship and definition of each SRL activity, respectively. It is clear from Fig. {\ref 1} that task interpretation, which refers to understanding the task and associated process to complete it \hyperref[b18]{[17]}, is the starting point of any SRL activities. Thus, misinterpreting a task may negatively affect follow-up planning, enacting, monitoring, and adjusting activities \hyperref[b19]{[18]}.\par Fig. {\ref 1}: Categories of various self-regulation activities. When interpreting a task, one must consider the explicit and implicit aspects of it. Explicit task interpretation refers to students' understanding of the information presented in the problem description \hyperref[b8]{[8]}, such as written goals, requirements, and constraints. Implicit task interpretation refers to extrapolated information base on the given description \hyperref[b8]{[8]}, for example, relevant concepts and experience to solve the problem. These definitions imply that explicit and implicit task interpretation is distinguishable based on the manner of that specific understanding being acquired (i.e., by identifying or extrapolating).\par Unfortunately, interpreting a task is not easy. Two studies reported that students could only correctly identify 63\% -77\% of valuable information presented in Thermodynamics course problems \hyperref[b3]{[3]}, \hyperref[b7]{[7]}. The accuracy of implicit task understanding is even more unsatisfactory, such that they could only extrapolate 37\% -49\% of the essential information \hyperref[b3]{[3]}, \hyperref[b7]{[7]}. Similar findings have been reported in engineering design \hyperref[b8]{[8]} and electronics lab \hyperref[b2]{[2]}. Consequently, this misinterpretation impedes their problem-solving performance \hyperref[b20]{[19]}- \hyperref[b22]{[21]}.\par Fortunately, several studies \hyperref[b2]{[2]}, \hyperref[b3]{[3]}, \hyperref[b8]{[8]}, \hyperref[b20]{[19]}, \hyperref[b22]{[21]}, \hyperref[b23]{[22]} suggested that students enhance their task understanding throughout their problem-solving enterprise. Theoretically, these refinements occur due to continuous monitoring and adjusting activities \hyperref[b24]{[23]}. Thus, insufficient and inefficient monitoring and adjustment activities may lead to a meager solution. Since SRL is contextual, having sufficient relevant domain knowledge is necessary for efficient monitoring and adjustment activities \hyperref[b4]{[4]}, \hyperref[b8]{[8]}, \hyperref[b20]{[19]}, \hyperref[b25]{[24]}. Moreover, one has to be willing to adopt new interpretations or strategies when it is necessary to do so. \section[{b) Self-Regulation in Computer Programming}]{b) Self-Regulation in Computer Programming}\par Although still limited in number, SRL research in CS is not new. Some scholars believe that it may ease the curve of learning programming and increase student's retention rate \hyperref[b26]{[25]}. In this section, the reported cognitive and meta cognitive characteristics of CS students found in the literature are discussed.\par Most CS students prefer to learn new materials sequentially through visual representation, and then reflect on their progress \hyperref[b27]{[26]}. Most of them are comfortable and competent in dealing with detailed information \hyperref[b27]{[26]},which strengthens their ability to solve complex problems (e.g., developing software systems). Their reflective nature allows them to be appreciative of each task, which, in turn, influences them to be more self-regulated and deliver better outputs \hyperref[b28]{[27]}.\par A study reported that students use numerous SRL strategies instinctively when trying to understand a task, design a solution, and debug a program \hyperref[b29]{[28]}. Engaging in self-regulation activities may improve their performance \hyperref[b28]{[27]}, \hyperref[b30]{[29]}.One study reported that students are sometimes unable to accurately address all the requirements and constraints of a problem \hyperref[b11]{[11]}, which suggested that instinctive self-regulation may not be sufficient in the long run. Students need to be more conscious of using it. Two studies suggested that deepening students' familiarity with various programming concepts and principles (i.e., contexts or knowledge) may increase their SRL quality \hyperref[b11]{[11]}, \hyperref[b20]{[19]}.\par Related to object-oriented (OO) design, a study reported that students are using typically suggested strategies in interpreting an OO design problem, which is by identifying the nouns and verbs found in the task description \hyperref[b9]{[9]}. Although this report seems expected, this finding is important because it describes students ' approaches in design, not just a belief. Based on their understanding, students then decompose the problem and design the solution. Interestingly, students consider problem decomposition as a skill that hard to master \hyperref[b11]{[11]}. Students tend to have incomplete and incorrect knowledge about OO design \hyperref[b9]{[9]}, which, plausibly, impair their decomposition skills. While some students may be aware of their weaknesses and strive to address it, others chose to ignore it. The last group of students tends to feel discouraged when facing a challenge \hyperref[b9]{[9]} and, thus, have a negative learning experience. \section[{IV.}]{IV.} \section[{Research Design}]{Research Design}\par In this section, the research design and its justification were explicated, which include data Selecting strategies to complete the task \hyperref[b5]{[5]} Enacting Strategies Students' cognitive activities employed while completing the task \hyperref[b56]{[54]} collection and analysis methods, and the design problem. \section[{a) Data Collection Method}]{a) Data Collection Method}\par Multiple, in-depth qualitative data were collected from the participants, which aligned with best practices of qualitative study \hyperref[b31]{[30]} and conducting SRL research \hyperref[b5]{[5]}, \hyperref[b32]{[31]}, \hyperref[b33]{[32]}. Multiple data points allowed the researchers to appraise the perception and activities of the participants accurately.\par Five programming problems, five problemspace maps, initial task interpretation survey, and interview question templates, were developed, pilot tested, and used. The programming problems consisted of two practice, one OO, one break, and one algorithm tasks. All except one were related to imperative programming paradigms. The problem-space maps described all correct and possible explicit and implicit task interpretation of each problem. This technique was adopted from expert-novice research about trouble shooting \hyperref[b34]{[33]}. The initial task interpretation survey was used to assess the participants' initial understanding of the task. Table \hyperref[tab_1]{II} presents the survey questions and the associated aspect of task interpretation. The interview question templates were used to formulating confirmatory questions based on the researchers' observation.\par During the data collection, the participants followed a specific protocol when solving each programming problem, and were audio-and videorecorded. The participants observed the following protocol in sequence: (a) reading the problem description aloud, (b) completing initial task interpretation survey while thinking aloud, (c) continue solving the problem while thinking aloud, and (d) answering the interview questions. The programming problems were given in the order written in the previous paragraph. No time limit was set for each problem. The practice problems were used to help the participants familiar with the data collection protocol and address any thinking aloud issues, if any.\par To accurately capture the initial task interpretation, the participants were prohibited from rereading the problem description when completing the survey (i.e., step (a)). The problem-space maps were used to track the participants' thought processes when solving the problem (i.e., step (c)). The interview was semi-structured to ensure its alignment with the research goal yet still providing flexibility in pursuing particular points of interest that emerged during the problem-solving process. \section[{b) Object-Oriented Design Problem}]{b) Object-Oriented Design Problem}\par The OO problem is about designing a digital version of a classic board game, which commonly known as the Monopoly. Unlike the original, this game would be set in Middle-Ages. Given a set of requirements and constraints (see Table \hyperref[tab_1]{III}), the participants should design a game base so that the rest of the team members could move forward smoothly. They are expected to deliver a class diagram. Also, they are allowed to ignore animation and play-testing parts and add their creativity beyond the given requirements and constraints.\par The participants are expected to declare and manage at least one function, five issues, and 4 to 41 variables when solving this problem. It also contains some missing or unspecified information (i.e., implicit task interpretation) and has multiple solutions; all are typical characteristics of a design problem \hyperref[b36]{[34]}- \hyperref[b38]{[36]}. Consequently, the participants are not expected to comprehend the problem in one read. Based on the revised Bloom's Taxonomy \hyperref[b39]{[37]}, this problem belonged to the creation category, where the participants were expected to make a product for a specific purpose. \section[{c) Data Analysis Method}]{c) Data Analysis Method}\par Recorded video/audio files, initial task interpretation survey responses, design solutions, design notes (if any), observed thought processes (i.e., problem-space maps), and interview responses were collected from each participant. All recorded video/audio files were transcribed using the verbatim technique, such that the transcriptions recorded all articulated words and shutters \hyperref[b40]{[38]}. Three additional notations were introduced in the transcriptions to clarify relevant contexts, including square bracket ("[]"), dash ("-"), and capitalizing the first letter for describing the participants' actions, correcting statements, and clarifying programming concepts, respectively. For example, "Since not having a particular idea on The qualitative coding process consisted of two phases. In the first phase, both experts individually coded the transcriptions based on the definition provided in Table \hyperref[tab_0]{I}. After they finished, the coding results were then combined. Some disagreements were expected since the experts worked independently. In the second phase, the experts met face-to-face to discuss and resolve all coding disagreements. All collected data were used to ensure correct interpretations of the participants' statements. Through this process, the experts were able to reach a perfect agreement, with a Kappa score of 1.00 for each transcription, and produced 875 codes.\par To answer the first research question, the initial task interpretation survey responses and the associated recorded video/audio files were used. These data sources were also triangulated against recorded problem-solving approaches and interview responses. This step was necessary since the participants might forget reporting all relevant thought processes when answering the survey.\par To answer the second research question, the answer to the first research question and the codedtranscriptions were used. All problem-solving activities that could not be associated with the initial task interpretation were categorized as adjustment of participants' task understanding. These adjusted interpretations were then triangulated against recorded interview responses.\par To answer the third research question, the list of task interpretation adjustments, coded-transcriptions, and interview responses were used. All statements in the coded-transcription that were associated with the changes were marked. The factors that influence the marked changes were then identified and triangulated against the interview responses.\par V. \section[{The Participants}]{The Participants}\par After the transcribing process completed, the OO-related transcriptions were qualitatively coded by two experts, which were an information technologist and one of the researchers. All experts had experience in developing OO applications. The expert-researcher also had a bachelor's and master's degrees in CS. \section[{Table III: Object-Oriented Problem Requirements and Constraints}]{Table III: Object-Oriented Problem Requirements and Constraints}\par No.\par Requirements and Constraints 1\par The game is meant to be played by either two, three, or four players. 2\par Each player chooses to play as any one of the following characters: King, Warrior, Merchant, or Thief. Each character has unique special abilities and starts with different items and different amounts of money. 3\par The game board will consist of 30 spaces where players can land, arranged in a circle. On some spaces, there are buildings that can be bought and sold. On other spaces, there are shops where players can buy items. In addition, some spaces have specific instructions that players must follow when they land there. 4\par In the original board game, movement is determined by rolling dice, so you must develop an equivalent virtual method of determining the number of spaces each player moves on his or her turn. 5\par On their turn, each player must move, and they can choose to do any of the following: buy the building on the space they are on, sell any building they own, spend money to improve buildings they own, or use one of their character's special abilities. 6\par Items give special benefits to the player. Items include the following: Sword, Potion, Horse, or others. The effects of the item will be different for each character type. 7\par There are three different kinds of buildings: Castle, F d I Th b ildi h diff fourth year, USU CS students have typically completed the introduction to programming, algorithm and data structure, software engineering, event-driven programming, and internship courses. At the end of the research, each participant received a personalized report of his or her task interpretation strategies and suggestions for improvement and a \$40 gift card. Participants responded positively towards the reports and suggestions.\par All participants were Caucasians with GPAs of 3.10 to 3.96 on a 4-point scale. Sorted based on their GPAs, they were Jake, Anne, LStew, and Rusty. The male participants also familiar with logic programming and had spent approximately 4980 hours developing their programming skills.\par The female participants had spent about 2050 hours of programming. Similar to most female CS students \hyperref[b41]{[39]}- \hyperref[b46]{[44]}, they had struggled with CS stereotypes, where CS students are viewed as overtly "focused on CS, asocial, competitive, and male" (p.30) \hyperref[b42]{[40]}. They also suffered from comparing themselves against their peers. L Stew said, "I have to ignore my colleagues and classmates programming 'successes' as that comparison game tends to reduce my selfesteem a lot and negatively impact my problem-solving and programming capabilities." She also said, "I nearly failed a class because I did not believe I was capable of succeeding in it." Fortunately, both participants were able to overcome that challenge and were almost finished with the degree requirements. \section[{VI.}]{VI.} \section[{Findings}]{Findings}\par All participants started with incomplete task understanding, which was expected, as explained earlier. Fortunately, all participants were also aware of it and tried to update their task understanding. Unfortunately, although their final task interpretation was better compared to the initial, it was still incomplete. There are two possible reasons for this result. First, the participants were overwhelmed with the detail of their design. Second, the participants were drawing knowledge from irrelevant experience. Rusty, for example, was using the entity-relationship instead of the class diagram.\par In this section, participants' initial and revisedtask interpretation, and factors that influenced the changes were discussed. \section[{a) Initial Explicit and Implicit Task Interpretation}]{a) Initial Explicit and Implicit Task Interpretation}\par Five questions were asked to assess the initial understanding of the participants (see Table \hyperref[tab_1]{II}). All participants were able to determine the problem goal correctly. Anne, for example, defined the goal as "develop[ing a] class diagram from given constraints." L Stew and Rusty also included design best practices and their interest in the problem goal. Rusty, for example, said the problem goal was "create[ing] a logic layer inside of our program that can function completely without interaction from the graphical user interface or user."Rusty knew that the decoupling of logic and user interface is part of software design best practices, and would like to observe it during the design process.\par No participants had a complete initial understanding of the requirements and constraints, which required explicit and implicit task interpretation. This result was expected, considering the number of requirements and constraints. However, all participants understood that they needed to complete each item listed in Table \hyperref[tab_1]{III}. They also understood that the problem implicitly required them to organize potential classes "in a logical way" since the classes will "interact in a specific way." Anne, LStew, and Rusty also added that exercising creativity, as directed in the problem, would affect their class design.\par In designing the classes, LStew further added that she needed to "avoid common object-oriented programming pitfalls by reducing coupling, reducing interdependencies, and avoiding the diamond of death."Plausibly, this implicit understanding was informed by her interests and experience in OO-design best practices.\par All participants considered OO design principles and UML diagram notations as relevant concepts. Rusty and LStew also added that design practices in writing a class diagram and software usability as essential knowledge and skills. Thus, all participants were able to identify relevant concepts to complete the problem correctly.\par In order to solve the problem, all participants determined that they need to (1) reread the problem description; (2) identify potential classes; (3) draw the class; (4) establish the classes' relationship; and (5) refine the class diagram as necessary. Interestingly, while the male participants concentrated on rereading the problem description on their first step, the females also concerned with identifying and rewriting the requirements and constraints in their own words. Additionally, Rusty and LStew added that they needed to monitor their progress and address creativity issues throughout their problem-solving enterprise. \section[{b) Revising the Initial Task Understanding}]{b) Revising the Initial Task Understanding}\par The participants executed their problem-solving steps carefully. LStew, for example, started by rereading the problem description and developed a list of requirements. She continued by solving the identified requirements that were related to items, characters, special abilities, player actions, spaces, buildings, players, games, and turn. Sometimes, after completing one of the requirements, she adjusted her design. For example, after designing the action-related classes, she revised the item and character classes. LStew also enhanced her design by making it as logical and as clear as possible so people could easily understand how the classes work together.\par When rereading the problem description, the participants were frequently observed as if interpreting it for the first time. These activities were coded as monitoring of task interpretation. Some of these activities triggered them to adjust their task interpretation. Jake, Anne, Rusty, and LStew were observed investing 37.50\%, 50.38\%, 31.12\%, and 36.47\% of their engagement for interpreting the task, respectively, including for monitoring and adjustment. Rusty said during the interview, "The general understanding did not really change because I knew that I was going to be creating this class diagram, but as far as the design decisions, it changed a lot." \section[{c) Factors that Influence the Task Interpretation Revisions}]{c) Factors that Influence the Task Interpretation Revisions}\par As mentioned by Rusty, most of the revisedtask interpretations were somehow related to design decisions, such as classes and their behaviors. When addressing each requirement and constraint, the participants need to consider the best mechanism to incorporate it into their existing design. Such need encourages them to reread the problem description as if they encountered it for the first time. This finding aligned with various reports that argued students were required to employ vast cognitive skills and work with different abstraction levels during a programming design activity \hyperref[b47]{[45]}, \hyperref[b48]{[46]}.\par All participants except Anne were observed updating their task understanding when addressing creativity requirements. For example, after rereading the third requirement (see Table \hyperref[tab_1]{III}), LStew said, "What kind of special instructions could you have if it was a castle versus an inn? I suppose-or a castle versus a fortress? Oh, nothing comes up. Well, a castle can have a king in it, right? ? Okay, so if you are a king and you land on a castle owned by someone else, you get a discount on your rent." The above illustration showed how LStew's interpretation of "specific instruction" evolved as she infused her creativity into the design.\par Unlike the other participants, Anne did not attempt to put creativity into her design. Using the third requirement as an example, Anne addressed it by just creating a class called Instructions that would be used by the Space class. At the beginning of solving the problem, Anne commented, "No one will hire me for my creativity," suggesting she was not confident of that particular skill. \section[{VII.}]{VII.} \section[{Discussion, Conclusion, and Implication}]{Discussion, Conclusion, and Implication}\par The analysis results suggested that the participants were competent in identifying the problem goal, requirements, constraints, relevant concepts, relevant experience, and steps to solve an OO design problem. It is important to note that they were able to identify most of it after the initial reading of the problem. However, due to the problem's extensiveness, they were unable to determine all detailed requirements and constraints.\par During the design, they displayed some attributes of expert problem-solvers (see \hyperref[b49]{[47]}, \hyperref[b50]{[48]}), such as considering possible concerns from various stakeholders. Their awareness of the problem complexity and prior experience in solving OO design problems also inspire a positive behavior; in such, it drove them to be cautious in interpreting the requirements. Thus, it might be beneficial to train students to identify problem characteristics and its complexity as early as possible. Two educational theory may help in this issue, which are Jonassen's problem types \hyperref[b36]{[34]}- \hyperref[b38]{[36]} and Bloom's Taxonomy to define the problem characteristics.\par The analysis results suggested that the participants had a relatively similar approach in solving an OO design problem with extensive requirements and constraints. This approach included rereading the problem description, identifying requirements, identifying classes, determining the classes' relationships, and refining the class diagram. This finding aligned with various arguments that students developed metacognitive knowledge about the tasks based on their problem-solving experience \hyperref[b0]{[1]}, \hyperref[b51]{[49]}, \hyperref[b52]{[50]}. Since these metacognitive knowledge influence students' problem-solving approach \hyperref[b0]{[1]},it might be beneficial for the instructors to check and ensure that students could acquire that knowledge correctly.\par There was self-regulation different between male and female, in such that both female participants listed the requirements and constraints using their own words. However, since all participants unable to identify the requirements and constraints completely, it is impossible to comments more on this difference.\par The findings suggested that the participants' interest and experience influenced their initial and revised-task interpretations. Similarly, when addressing creativity requirements, they also exploited their interest and experience. One study argues that creativity is primarily related to the design process \hyperref[b53]{[51]}. Thus, Anne's discomfort about her creative side might be induced by a lack of exposure to a variety of products, and chances to express her creativity. These issues could be fixed by exposing students to various creative software products and encouraging them to tap into their creative side in several programming assignments.\par The analysis suggested that task interpretation skills might be deteriorated due to being overwhelmed and drawing from irrelevant experience. This findings also suggested that the participants' incorrect assumption of educational tasks might affect their selfregulation. Students need to be aware of this potential danger in their education. \section[{Conclusion}]{Conclusion}\par This study shows that the participants, senior CS students, are capable of drawing explicit and implicit information from an OO-design problem. Most of this information is identified during their initial task interpretation. It is important to note that various contexts influence their task interpretation skills; this is coherent with SRL theory \hyperref[b4]{[4]}, \hyperref[b5]{[5]}, \hyperref[b8]{[8]}, \hyperref[b14]{[13]}, \hyperref[b54]{[52]} and other existing research \hyperref[b20]{[19]}, \hyperref[b22]{[21]}. This study shows how participants' perception of the problem (e.g., domain and complexity) and their experience, interest, and selfefficacy influences their task interpretation (and selfregulation in general). Thus, it is also essential to help students more aware of such contextual information when solving a problem.\par This study also shows that participants' task understanding evolves during their problem-solving endeavor. In terms of solving an OO-design problem, revised-task interpretations are mostly related to design decisions, such as considering the interplay among classes. These senior students also display expert like behaviors where they try to interpolate possible concerns from various stakeholders. All participants also have developed a similar problem-solving approach to OO-design problems. A slight difference exists between males' and females' approach, where the females prefer to develop a list of known requirements and constraints. \section[{IX.}]{IX.} \section[{Limitations}]{Limitations}\par This qualitative multiple case study was not designed to produce generalizable results but rather to capture as much variety of students' task interpretation while solving OO-design problems as much as possible. With such a goal, having four participants was adequate for a qualitative case study research \hyperref[b31]{[30]}. When interpreting the findings, remember that the participants' diversity in this study was limited to their sex. There was a limitation regarding the problem types, such that the research tasks were limited to OO and imperative paradigms. Finally, one study argues that although thinking aloud is commonly used in educational studies, it might also affect students' self-regulation \hyperref[b55]{[53]} and then influence the research results. Unfortunately, there is no known approach to overcome it.\par This paper only focuses on the participants' SR while working on OO design problem. The other unit of analysis is discussed in \hyperref[b22]{[21]}.\begin{figure}[htbp] \noindent\textbf{}\includegraphics[]{image-2.png} \caption{\label{fig_0}}\end{figure} \begin{figure}[htbp] \noindent\textbf{I} \par \begin{longtable}{P{0.32028985507246377\textwidth}P{0.5297101449275362\textwidth}} Strategic Action\tabcellsep Definition\\ Task\tabcellsep Students' understanding of the task\\ Interpretation\tabcellsep and associated process to complete\\ \tabcellsep it [17]\\ Planning\tabcellsep \\ Strategies\tabcellsep \end{longtable} \par \caption{\label{tab_0}Table I :}\end{figure} \begin{figure}[htbp] \noindent\textbf{II} \par \begin{longtable}{P{0.10892448512585812\textwidth}P{0.7410755148741418\textwidth}} Layer\tabcellsep Question\\ Explicit\tabcellsep What is the primary goal of this problem?\\ Explicit \&\tabcellsep In relation to the program that you will\\ Implicit\tabcellsep design, what are the requirements and\\ \tabcellsep constraints that you need to consider?\\ Implicit\tabcellsep What are the programming concepts\\ \tabcellsep related to this problem?\\ Implicit\tabcellsep What are your previous experiences related\\ \tabcellsep to this problem?\\ Implicit\tabcellsep In relation to the program that you will\\ \tabcellsep design, what are the steps (e.g., tasks) that\\ \tabcellsep you need to take?\end{longtable} \par \caption{\label{tab_1}Table II :}\end{figure} \footnote{Year 2020 © 2020 Global Journals Students' Understanding of an Object-Oriented Design Task -A Case Study} \footnote{© 2020 Global JournalsStudents' Understanding of an Object-Oriented Design Task -A Case Study} \backmatter \begin{bibitemlist}{1} \bibitem[ Coll. Rec ()]{b1}\label{b1} \textit{}, \textit{Coll. Rec} 2004. 106 (9) p. . \bibitem[Res (2008)]{b13}\label{b13} \textit{}, J Res . \xref{http://dx.doi.org/10.3102/0002831207312909}{10.3102/0002831207312909}. Mar. 2008. 45 p. . \bibitem[Improv (2008)]{b35}\label{b35} \textit{}, Q Improv . \xref{http://dx.doi.org/10.1111/j.1937-8327.1988.tb00021.x}{10.1111/j.1937-8327.1988.tb00021.x}. Oct. 2008. 1 p. . \bibitem[First]{b57}\label{b57} \textit{Author was born in xx in x. X received the B.S. and M.S. degrees in Computer Science from the X, in X and the Ph.D. degree in X in X}, A First . (Short bio: interests, academic activities, research activities, and professional associations) \bibitem[Second]{b58}\label{b58} \textit{Author was born in xx in x. X received the B.S. and M.S. degrees in Computer Science from the X, in X and the Ph.D. degree in X in X}, B Second . (Short bio: interests, academic activities, research activities, and professional associations) \bibitem[Butler and Cartier ()]{b33}\label{b33} ‘Case Studies as a Methodological Framework for Studying and Assessing Self-Regulated Learning’. L Butler , S C Cartier . \textit{Handbook of Self-Regulation of Learning and Performance}, D H Schunk, J Greene (ed.) (New York, New York, USA) 2018. Routledge. p. . (2nd ed.) \bibitem[Johnson]{b34}\label{b34} \textit{Cognitive Analysis of Expert and Novice Troubleshooting Performance}, S D Johnson . (Perform) \bibitem[Butler et al. (2015)]{b17}\label{b17} ‘Collaborative inquiry and distributed agency in educational change: A case study of a multi-level community of inquiry’. D L Butler , L Schnellert , K Macneil . \xref{http://dx.doi.org/10.1007/s10833-014-9227-z}{10.1007/s10833-014-9227-z}. \textit{J. Educ. Chang} Feb. 2015. 16 (1) p. . \bibitem[Wing (2008)]{b48}\label{b48} ‘Computational Thinking and Thinking About Computing’. J M Wing . \xref{http://dx.doi.org/10.1098/rsta.2008.0118}{10.1098/rsta.2008.0118}. \textit{Philos. Trans. A. Math. Phys. Eng. Sci} Oct. 2008. 366 (1881) p. . \bibitem[Christiaans and Venselaar (2005)]{b53}\label{b53} ‘Creativity in Design Engineering and the Role of Knowledge: Modelling the Expert’. H Christiaans , K Venselaar . \xref{http://dx.doi.org/10.1007/s10798-004-1904-4}{10.1007/s10798-004-1904-4}. \textit{Int. J. Technol. Des. Educ} Jan. 2005. 15 (3) p. . \bibitem[Creswell ()]{b31}\label{b31} J W Creswell . \textit{Qualitative Inquiry and Research Design: Choosing Among Five Approaches}, 2012. SAGE Publications. (3rd ed) \bibitem[Graham and Latulipe (2003)]{b43}\label{b43} ‘CS girls rock: sparking interest in computer science and debunking the stereotypes’. S Graham , C Latulipe . \xref{http://dx.doi.org/10.1145/792548.611998}{10.1145/792548.611998}. \textit{ACM SIGCSE Bull} Jan. 2003. 35 (1) p. 322. \bibitem[Saulnier and Brisson ()]{b21}\label{b21} ‘Design for Use: A Case Study of an Authentically Impactful Design Experience’. C R Saulnier , J G Brisson . \textit{Int. J. Eng. Educ} 2018. 34 (2B) p. . \bibitem[Butler et al. ()]{b14}\label{b14} \textit{Developing Self-Regulating Learners}, D L Butler , L Schnellert , N E Perry . 2017. Toronto, ON, Canada: Pearson Education Inc. \bibitem[Febrian et al. ()]{b22}\label{b22} ‘Do Computer Science Students Understand Their Programming Task?-A Case Study of Solving the Josephus Variant Problem’. A Febrian , Lawanto , Oenardi . \textit{Int. Educ. Stud} 2018. 11 (12) . \bibitem[Hadwin ()]{b54}\label{b54} ‘Do your students really understand your assignments?’. A Hadwin . \textit{LTC Curr. Optim. Learn. Environ} 2006. 11 (3) p. . \bibitem[Kumar ()]{b30}\label{b30} ‘Effects of self-regulated learning in programming’. V Kumar . doi: 10.1109/ ICALT. 2005.131. \textit{Fifth IEEE International Conference on Advanced Learning Technologies (ICALT'05)}, 2005. p. . \bibitem[Cartier and Butler ()]{b15}\label{b15} ‘Elaboration and validation of questionnaires and plan for analysis’. S C Cartier , D L Butler . \textit{Annual Conference of the Canadian Society for The Study of Education}, 2004. \bibitem[Chi et al. ()]{b55}\label{b55} ‘Eliciting Self-Explanations Improves Understanding’. M T H Chi , N De Leeuw , M.-H Chiu , C Lavancher . \xref{http://dx.doi.org/10.1207/s15516709cog1803_3}{10.1207/s15516709cog1803\textunderscore 3}. \textit{Cogn. Sci} 1994. 18 (3) p. . \bibitem[Hadwin et al. ()]{b8}\label{b8} ‘Examining Student and Instructor Task Perceptions in a Complex Engineering Design Task’. A F Hadwin , M Oshige , M Miller , P Wild . \textit{The Sixth International Conference on Innovation and Practices in Engineering Design and Engineering Education}, 2009. \bibitem[Bergin et al. ()]{b28}\label{b28} ‘Examining the role of self-regulated learning on introductory programming performance’. S Bergin , R Reilly , D Traynor . \xref{http://dx.doi.org/10.1145/1089786.1089794}{10.1145/1089786.1089794}. \textit{First International Workshop on Computing Education Research}, 2005. p. . \bibitem[Glaser ()]{b49}\label{b49} ‘Expert knowledge and processes of thinking’. R Glaser . \textit{Enhancing thinking skills in the sciences and mathematics}, D Halpern (ed.) (Ed. Hillsdale, NJ, USA) 1992. Lawrence Erlbaum Associates, Inc. p. . \bibitem[Butler and Winne (1995)]{b4}\label{b4} ‘Feedback and Self-Regulated Learning: A Theoretical Synthesis’. D L Butler , P H Winne . \xref{http://dx.doi.org/10.3102/00346543065003245}{10.3102/00346543065003245}. \textit{Rev. Educ. Res} Jan. 1995. 65 (3) p. . \bibitem[Dinsmore et al. ()]{b32}\label{b32} ‘Focusing the conceptual lens on metacognition, self-regulation, and self-regulated learning’. L Dinsmore , P A Alexander , S M Loughlin . \xref{http://dx.doi.org/10.1007/s10648-008-9083-6}{10.1007/s10648-008-9083-6}. \textit{Educ. Psychol. Rev} 2008. 20 (4) p. . \bibitem[Falkner et al. ()]{b41}\label{b41} ‘Gender Gap in Academia: Perceptions of Female Computer Science Academics’. K Falkner , C Szabo , D Michell , A Szorenyi , S Thyer . \xref{http://dx.doi.org/10.1145/2729094.2742595}{10.1145/2729094.2742595}. \textit{Proceedings of the 2015 ACM Conference on Innovation and Technology in Computer Science Education -ITiCSE '15}, (the 2015 ACM Conference on Innovation and Technology in Computer Science Education -ITiCSE '15) 2015. p. . \bibitem[Outlay et al. (2017)]{b45}\label{b45} ‘Getting IT Together: A Longitudinal Look at Linking Girls' Interest in IT Careers to Lessons Taught in Middle School Camps’. C N Outlay , A J Platt , K Conroy . doi: 10.1145/ 3068838. \textit{ACM Trans. Comput. Educ} Aug. 2017. 17 (4) p. . \bibitem[Gronlund et al. ()]{b39}\label{b39} N E Gronlund , E N Gronlund , C K Waugh . \textit{Assessment of Student Achievement}, 2013. (10th ed. Pearson) \bibitem[Shaft ()]{b29}\label{b29} ‘Helping Programmers Understand Computer Programs: the Use of Metacognition’. T M Shaft . \textit{ACM SIGMIS Database} 1995. 26 (4) p. . \bibitem[Hoffman (ed.) ()]{b50}\label{b50} \textit{How can expertise be defined? Implications of research from cognitive psychology}, R R Hoffman . Exploring Expertise, R. Williams, W. Faulkner, and J. Fleck (ed.) 1996. Edinburgh, Scotland: University of Edinburgh Press. p. . \bibitem[Lewis et al. ()]{b42}\label{b42} ‘I Don't Code All Day': Fitting in Computer Science When the Stereotypes Don't Fit’. C M Lewis , R E Anderson , K Yasuhara . \xref{http://dx.doi.org/10.1145/2960310.2960332}{10.1145/2960310.2960332}. \textit{Proceedings of the 2016 ACM Conference on International Computing Education Research -ICER '16}, (the 2016 ACM Conference on International Computing Education Research -ICER '16) 2016. p. . \bibitem[Renumol et al. (2010)]{b47}\label{b47} ‘Identification of Cognitive Processes of Effective and Ineffective Students During Computer Programming’. V G Renumol , D Janakiram , S Jayaprakash . \xref{http://dx.doi.org/10.1145/1821996.1821998}{10.1145/1821996.1821998}. \textit{ACM Trans. Comput. Educ} Aug. 2010. 10 (3) p. . \bibitem[Falkner et al. ()]{b11}\label{b11} ‘Identifying computer science self-regulated learning strategies’. K Falkner , R Vivian , N J G Falkner . \xref{http://dx.doi.org/10.1145/2591708.2591715}{10.1145/2591708.2591715}. \textit{Proceedings of the 2014 conference on Innovation \& technology in computer science education -ITiCSE '14}, (the 2014 conference on Innovation \& technology in computer science education -ITiCSE '14) 2014. p. . \bibitem[Zimmerman]{b12}\label{b12} ‘Investigating Self-Regulation and Motivation: Historical Background, Methodological Developments, and Future Prospects’. B J Zimmerman . \textit{Am. Educ} \bibitem[Lawanto and Febrian ()]{b20}\label{b20} ‘Investigating the Influence of Context on Students' Self-Regulation during the Capstone Design Course (Accepted)’. O Lawanto , A Febrian . \textit{Int. J. Eng. Educ} 2018. \bibitem[Butler and Cartier ()]{b16}\label{b16} ‘Learning in varying activities: An explanatory framework and a new evaluation tool founded on a model of self-regulated learning’. D L Butler , S C Cartier . \textit{Annual Conference of the Canadian Society for The Study of Education}, 2004. \bibitem[Jonassen ()]{b38}\label{b38} \textit{Learning to solve problems: A handbook for designing problem-solving learning environments}, D H Jonassen . 2010. (Routledge) \bibitem[Jonassen ()]{b37}\label{b37} \textit{Learning to Solve Problems: An Instructional Design Guide}, D H Jonassen . 2004. John Wiley \& Sons. \bibitem[Flavell ()]{b52}\label{b52} ‘Metacognition and cognitive monitoring: A new area of cognitive-developmental inquiry’. J H Flavell . \xref{http://dx.doi.org/10.1037/0003-066x.34.10.906}{10.1037/0003-066x.34.10.906}. \textit{Am. Psychol} 1979. 34 (10) p. . \bibitem[Butler ()]{b18}\label{b18} ‘Metacognition and Learning Disabilities’. D L Butler . \textit{Learning About Learning Disabilities}, B Y L Wong, Ed Toronto (ed.) 1998. Academic Press. p. . (2nd ed) \bibitem[Flavell ()]{b51}\label{b51} ‘Metacognitive Aspects of Problem Solving’. J H Flavell . \textit{The Nature of Intelligence}, L B Resnick (ed.) (Ed. Hillsdale, NJ, USA) 1976. Erlbaum. p. . \bibitem[Butler and Cartier ()]{b5}\label{b5} ‘Multiple Complementary Methods for Understanding Self-Regulated Learning as Situated in Context’. D L Butler , S C Cartier . \textit{Annual Meeting}, 2005. American Educational Research Association. p. . \bibitem[Carver and Scheier ()]{b24}\label{b24} ‘Origins and functions of positive and negative affect: A control-process view’. S Carver , M F Scheier . \xref{http://dx.doi.org/10.1037/0033-295X.97.1.19}{10.1037/0033-295X.97.1.19}. \textit{Psychol. Rev} 1990. 97 (1) p. . \bibitem[Lawanto ()]{b56}\label{b56} ‘Pattern of Task Interpretation and Self-Regulated Learning Strategies of High School Students and College Freshmen during an Engineering Design Project’. O Lawanto . \textit{J. STEM Educ. Innov. Res} 2013. 14 (4) p. 15. \bibitem[Butler and Cartier]{b0}\label{b0} \textit{Promoting Effective Task Interpretation as an Important Work Habit: A Key to Successful Teaching and Learning}, D L Butler , S C Cartier . (Teach) \bibitem[Butler (1995)]{b19}\label{b19} ‘Promoting Strategic Learning by Postsecondary Students with Learning Disabilities’. D L Butler . \xref{http://dx.doi.org/10.1177/002221949502800306}{10.1177/002221949502800306}. \textit{J. Learn. Disabil} Mar. 1995. 28 (3) p. . \bibitem[Wang et al. ()]{b46}\label{b46} ‘Social Perceptions in Computer Science and Implications for Diverse Students’. J Wang , S Hejazi Moghadam , J Tiffany-Morales . \xref{http://dx.doi.org/10.1145/3105726.3106175}{10.1145/3105726.3106175}. \textit{Proceedings of the 2017 ACM Conference on International Computing Education Research -ICER '17}, (the 2017 ACM Conference on International Computing Education Research -ICER '17) 2017. p. . \bibitem[Alharbi et al. (2012)]{b27}\label{b27} ‘Student-Centered Learning Objects to Support the Self-Regulated Learning of Computer Science’. A Alharbi , F Henskens , M Hannaford . \xref{http://dx.doi.org/10.4236/ce.2012.326116}{10.4236/ce.2012.326116}. \textit{Creat. Educ} Oct. 2012. 03 (06) p. . \bibitem[Lawanto and Stewardson (2013)]{b6}\label{b6} ‘Students' interest and expectancy for success while engaged in analysis-and creative design activities’. O Lawanto , G Stewardson . \xref{http://dx.doi.org/10.1007/s10798-011-9175-3}{10.1007/s10798-011-9175-3}. \textit{Int. J. Technol. Des. Educ} May 2013. 23 (2) p. . \bibitem[Rivera-Reyes et al. (2017)]{b2}\label{b2} ‘Students' Task Interpretation and Conceptual Understanding in an Electronics Laboratory’. P Rivera-Reyes , O Lawanto , M L Pate . \xref{http://dx.doi.org/10.1109/TE.2017.2689723}{10.1109/TE.2017.2689723}. \textit{IEEE Trans. Educ} Nov. 2017. 60 (4) p. . \bibitem[Lawanto et al. (2018)]{b3}\label{b3} ‘Students' Task Understanding during Engineering Problem Solving in an Introductory Thermodynamics Course’. O Lawanto , A Minichiello , J Uziak , A Febrian . \xref{http://dx.doi.org/10.5539/ies.v11n7p43}{10.5539/ies.v11n7p43}. \textit{Int. Educ. Stud} Jun. 2018. 11 (7) p. 43. \bibitem[Lawanto et al. ()]{b7}\label{b7} ‘Task Affect and Task Understanding in Engineering Problem-Solving’. O Lawanto , A Minichiello , J Uziak , A Febrian . \textit{J. Technol. Educ} 2018. \bibitem[Isomöttönen and Tirronen (2013)]{b25}\label{b25} ‘Teaching programming by emphasizing self-direction’. V Isomöttönen , V Tirronen . \xref{http://dx.doi.org/10.1145/2483710.2483711}{10.1145/2483710.2483711}. \textit{ACM Trans. Comput. Educ} Jun. 2013. 13 (2) p. . \bibitem[Havenga ()]{b9}\label{b9} ‘The Role of Metacognitive Skills in Solving Object-Oriented Programming Problems: a Case Study’. M Havenga . \textit{TD J. Transdiscipl. Res. South. Africa} 2015. 11 (1) p. . \bibitem[Abdillah et al. (2016)]{b23}\label{b23} ‘The Students Decision Making in Solving Discount Problem’. T Abdillah , S Nusantara , H Subanj , A Susanto , Abadyo . \xref{http://dx.doi.org/10.5539/ies.v9n7p57}{10.5539/ies.v9n7p57}. \textit{Int. Educ. Stud} Jun. 2016. 9 (7) p. 57. \bibitem[Jonassen (2000)]{b36}\label{b36} ‘Toward a design theory of problem solving’. H Jonassen . \xref{http://dx.doi.org/10.1007/BF02300500}{10.1007/BF02300500}. \textit{Educ. Technol. Res. Dev} Dec. 2000. 48 (4) p. . \bibitem[Tigerfish]{b40}\label{b40} ‘Transcription Style Guide’. Tigerfish . \textit{Tigerfish} p. 11. \bibitem[Irani (2004)]{b44}\label{b44} ‘Understanding gender and confidence in CS course culture’. L Irani . \xref{http://dx.doi.org/10.1145/1028174.971371}{10.1145/1028174.971371}. \textit{ACM SIGCSE Bull} Mar. 2004. 36 (1) p. 195. \bibitem[Leiviskä and Siponen ()]{b26}\label{b26} ‘Understanding Why IS Students Drop Out: Toward A Process Theory’. K Leiviskä , M Siponen . \textit{ECIS 2013 Proceedings}, 2013. p. . \bibitem[Peng et al. ()]{b10}\label{b10} ‘Visualizing the Complex Process for Deep Learning with an Authentic Programming Project’. J Peng , M Wang , D Sampson . \textit{Educ. Technol. Soc} 2017. 20 (4) p. . \end{bibitemlist} \end{document}