선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 초점을 맞추었다. 기존의 방법들에서 사용된 학생 프로그램과 프로그래밍 지식 외에 추가로 제공되는 테스트 데이터로 프로그램 자체를 실행시켜 얻은 중간 결과라는 다이나믹한 정보를 활용하여, 프로그램 해석과 오류분석의 효율성을 높이고 초보자들이 이해하기 쉽게 구체적이고 실례에 바탕을 둔 설명을 제공하는 오류분석 방식을 제안하고자 한다.
- 이들은 각자의 프로그램 이해 방법론에 입각하여 초보자의 프로그램을 분석하여 해석이 되어지는 프로그램은 맞는 프로그램으로 받아들이고 해석이 되지않는 부분을 오류로 판정하고 그 원인을 찾는데 초점을 맞추었다. 따라서 가능한 넓은 범위의 프로그램을 이해할 수 있는 방법론을 제시하고 어떻게 효율적인 오류지적이 가능한 가에 연구의 초점이 있었다. 여기서는 일반적인 방법론으로 프로그램을 이해하도록 지식표현이나 추론에 관한 연구가 제시되었고, 이를 바탕으로 해석되지 않는 부분을 오류로 판단하였는데, 이러한 오류를 어떻게 판단할 것인가와 그 오류에 대해 어떻게 적절한 조언을 제공할 것인가에 연구의 초점이 맞추어져 있었다[3-5].
제안 방법
- 실행부는 초기 입력 자료로 주어진 테스트 데이터를 가지고 학생의 프로그램을 실행시키며, 그 과정에서 변수들의 값의 변화나 입출력된 데이터 값을 모두 저장해 둔다. 플랜정합부는 초기 입력자료로 주어진 과제명세서 (Programming Task Description)0!] 있는 요구사항에 근거하여 플랜 매칭을 시도하고, 그 차이점들을 프로그램 실행 결과를 이용하여 오류를 분석하게 된다.
- 본 연구에서는 기존에 제시된 해석방법론 중에서 C/C++언어와 같은 절차적 언어 (Procedural Language)에 적합한 플랜 정합법을 기반으로, 초보자를 위한 오류검증 기능의 보완에 초점을 맞추었다. 기존의 방법들에서 사용된 학생 프로그램과 프로그래밍 지식 외에 추가로 제공되는 테스트 데이터로 프로그램 자체를 실행시켜 얻은 중간 결과라는 다이나믹한 정보를 활용하여, 프로그램 해석과 오류분석의 효율성을 높이고 초보자들이 이해하기 쉽게 구체적이고 실례에 바탕을 둔 설명을 제공하는 오류분석 방식을 제안하고자 한다.
- 이를 위해 플랜 간 위치 관계를 제한해서, 입력을 받아들이는 반복문 내의 특정 영역(8~11번 코드)에서만 비슷한 연산문을 찾도록 하여 제대로 된 결과를 효과적으로 찾자는 것이 프라우스트의 플랜 표현의 의도라 하겠다. 본 연구에서는 플랜 간의 위치관계를 대신하여 연관관계를 나타내주는 방안으로 두 플랜 사이에 공통으로 사용되는 변수가 취하는 값을 검토하는 조건 검사를 대신 사용하자는 것으로, 그림 1의 형태와 대비하여 요약하여 표현하면 그림 2와 같다.
- 있는 방법은 없는가? 이를 위해서는 과연 위치정보에 의해 유지된 내용이 무엇인지, 이를 유지하면서 단점을 없앨 수 있는 추가적인 정보는 없는 지를 먼저 살펴보도록 하자.
- 된다. 즉, 플랜 간의 강한 위치관계라는 연관 관계의 표현 방식을 줄이는 대신, 프로그램 실행 결과를 이용하여 플랜 간 공통변수에 대한 조건이만족되었는지를 조사함으로써 서로간의 인과관계를 표시할 수 있게 되었다. 또한 플랜 정합 과정에서 발생하는 차이점을 실행 과정의 중간값을 이용하여 프로그램 자체의 정보로 뒷받침된 오류 검증이 가능하게 됨으로써 유연하게 플랜간의 관계를 표시할 수 있으면서 분석 과정의 효율성과 효과를 높일 수 있게 되었다.
- 이 문제들에는 문자열 처리라든지, 숫자의 조건 및 변형 처리에 대한 문제, 출력문 위주의 문제 등 다양한 문제를 포함하고 있다. 프로그램의 형태는 'For/while'문을 사용한 단순한 반복문에서 'switch-case'를 사용한 구조라든지, 숫자 문자를 정수로 바꾼다든지, 문자 및 정수 배열 (array) 사용, 복잡한 조건식이나 산술식이 포함된 프로그램을 가지고 테스트하였다. 실험 결과는 표 1에 정리하였다.
- 인식하고 있다. 플랜의 위치 관계를 지정하는 연결사를 활용하여 플랜간의 가능한 결합 관계를 표현하고 이를 이용하여 예상되는 플랜의 위치를 알고 빠른 프로그램 해석에 적극적으로 활용하였다. 플랜 내 매칭의 오류를 플랜 간 위치 관계와 연결지어 사용자에 효과적인 메시지를 제공하는 데도 활용하고 있다[8].
- 플랜정합 방법론에 프로그램 실행 결과를 결합 시킴으로써 효과적인 디버깅이 가능함을 보이기 위해 초보자용 C언어 프로그래밍 오류분석 시스템인 익스버그 (Ex出 ug: Execution guided deBugger)를 구현하였다. 시스템의 구성은 아래 그림 3과 같다.
대상 데이터
- 적용 대상은 ", 'while; 'for', 'do-while' 문과 같은 조건문의 조건식에서 예상 가능한 매칭의 차이가 발생한 경우에 실행 결과를 이용하여 매칭의 차이를 검증하는 전략인 것이다. '(data != 0)'이 실행된 경우의 모든 'data' 값에 대해서 '(data > 0)'을 적용해 보아 두 조건식의 결과가 차이가 나면 조건 연산자 적용을 잘못하여 오류가 발생한 것으로 판정하고, 이 때의 'data' 값을 오류를 발생시킨 예제 데이터로 제시하게 된다.
- 실제 프로그램 오류 분석 능력을 평가하기 위해 프라우스트에서 사용된, 강우량 문제, 와 '알기 쉬운 C언어'[11] 교재에 있는 연습문제 13가지에 대해서 예제 프로그램 총 397개를 수집하여 테스트 하였다. 이 문제들에는 문자열 처리라든지, 숫자의 조건 및 변형 처리에 대한 문제, 출력문 위주의 문제 등 다양한 문제를 포함하고 있다.
성능/효과
- 그림 1의 예제 뿐만 아니라 'goto'문과 같이 특수한 형태의 경우에도 실질적으로 반복문임을 파악해서 해석이 가능하게 된 것이다. 따라서 합계 플랜의 표현에 영향을 미치는 일이 없이 위치 정보에 의한 방식보다 적은 수효의 플랜으로 보다 많은 플랜 간의 결합관계를 해독할 수 있다는 장점이 있다.
- 즉, 플랜 간의 강한 위치관계라는 연관 관계의 표현 방식을 줄이는 대신, 프로그램 실행 결과를 이용하여 플랜 간 공통변수에 대한 조건이만족되었는지를 조사함으로써 서로간의 인과관계를 표시할 수 있게 되었다. 또한 플랜 정합 과정에서 발생하는 차이점을 실행 과정의 중간값을 이용하여 프로그램 자체의 정보로 뒷받침된 오류 검증이 가능하게 됨으로써 유연하게 플랜간의 관계를 표시할 수 있으면서 분석 과정의 효율성과 효과를 높일 수 있게 되었다. 사용자에게 제공하는 오류에 대한 설명 메시지도 고울간의 인과 관계를 활용하여 오류의 원인과 그 여파를 구체적으로 지적해줄 수 있으며, 예제와 반례를 제시하여 설명함으로써 초보자가 이해하기 쉬운 설명을 제공해 줄 수 있게 되었다.
- 분석에 성공한 357개의프로그램 중에서 오류가 없이 제대로 작성된 프로그램의 수효는 128개 이며, 오류를 포함하고 있는 것은 229개였으며 이를 수작업으로 분류한 결과 오류의 수효는 총 679개 였다. 익스버그는 이 오류 중 81%에 해당하는 552개에 대해서 제대로 지적해 냈으나, 19%인 127개에 대해서는 지적을 하지 않았다 (구현되지 않은 고울이 있다고 지적하면서 테스트 데이터로 검사할 것을 권고하는 경우는 버그를 지적한 것으로 판정하지 않았으며, 이를 포함하는 경우 지적율은 90%이상이 된다).
- 또한 플랜 정합 과정에서 발생하는 차이점을 실행 과정의 중간값을 이용하여 프로그램 자체의 정보로 뒷받침된 오류 검증이 가능하게 됨으로써 유연하게 플랜간의 관계를 표시할 수 있으면서 분석 과정의 효율성과 효과를 높일 수 있게 되었다. 사용자에게 제공하는 오류에 대한 설명 메시지도 고울간의 인과 관계를 활용하여 오류의 원인과 그 여파를 구체적으로 지적해줄 수 있으며, 예제와 반례를 제시하여 설명함으로써 초보자가 이해하기 쉬운 설명을 제공해 줄 수 있게 되었다.
- 두 번째 문제점은 플랜간에 위치에 따른 연관 관계를 갖게 됨으로써, 한 플랜의 해석은 타 플랜의해석 결과가 주어져야 끝낼 수가 있으며, 이는 연관된 플랜의 해석과 연계 해석해야 하므로 연관된 플랜의 깊이와 넓이에 따라 검토해야 할 탐색 공간의 크기가 기하급수적으로 증가할 가능성을 안고 있다. 세번째 문제는, 연관된 플랜들의 해석에 있어서 초기에 내린 결론이 잘못되어진 경우 그 후의 플랜들의 해석에 오류가 전파될 가능성이 크다는 점이다. 따라서 초기 선정된 플랜의 해석에 신중을 기해야 하며, 가능한 여러가지 해석이 나타나지 않아야 탐색공간을 줄이며 일관된 해석이 가능하게 된다.
- 하겠다. 앞에서 언급한 바대로 개별 플랜의 해석에 있어서는 해석해야 할 코드의 범위의 확대로 탐색 공간이 커질 가능성이 있으나 프로그램 크기에 비례하는 산술 급수의 증가이며, 연관된 플랜 간의 해석에 따른 트리 탐색이 없어진 관계로기하급수적인 탐색의 증가가 없어져서 전체적인 해석에 있어서 효율성이 증대되었다 하겠다.
- 위의 예에서 입력값 검사 검사 플랜과 합계 플랜 간에는 공통변수를 매개로 해서 인과 관계가 성립한다는 것을 새로운 표현방식에서는 알 수 있다. 이를 이용하면 입력값검사 플랜의 해석 과정에서 오류가 발견되었고 합계 플랜의 해석과정에서 종료값이 더해지는 연산에 사용된 것을 발견하면, '입력값검사의 오류 결과로 합계 계산에 잘못된 값이 사용되었다'라는 설명이 가능하게 된 것이다. 즉, 위치 관계를 고려해서 오류 전파 가능성이 있다고 설명하는 것보다는 인과관계에 의해 구체적인 사례를 바탕으로 오류의 원인을 설명할 수 있게 된 점이 장점이라 하겠다.
- 이를 프라우스트의 실험결과와 비교하면 버그의 지적율에서는 81%대 94%로 상대적으로 떨어지나, 허위 경보에 대해서는 36개 (5%) 대 66개 (11%)로 상대적으로 절반 이하로 줄어든 결과를 보여주고 있다. 익스버그의 지적율이 떨어진 것은 아직 개선의 여지가 있다는 점을 반영하는 것으로 판단할 수 있으나, 또 하나 상대적으로 보수적인 오류 판정 전략에 따른 결과이기도 하다.
- 그림 1과 형태는 비슷하나 구조가 다른 프로그래 'do-while'문을 이용하여 형태가 약간 다르나 구조는 비슷한 프로그램, 'goto'문을 사용하여 형태와 구조가 모두 다른 프로그램을 제시하여 학생들의 경우 다양한 형태로 프로그램을 작성하는 것을 보여주고 있다. 이처럼 프로그램의 형태와 구조가 다양함에도 불구하고 합계를 구하는 플랜의 형태는 4개의 프로그램에서 모두 동일한 형태를 취하고 있었으며 (그림 2에서 3번과 18번의 밑줄친 코드), 특정 값을 만날 때까지 입력값을 받아 들이는 부분도 약간의 차이는 있으나 예상이 가능한 패턴들로 4개의 프로그램에서 모두 찾아볼 수 있었다. 이처럼 동일하거나 비슷한 플랜들을 사용하면서도 외관상 전체적인 구조의 차이가 보이는 여러 개의 프로그램을 해독하고 프로그램에 포함된 오류를 지적하기 위해서는 프로그래밍 플랜을 찾아내는 것 뿐만 아니라 플랜들 간의 가능한 결합 관계를 표현하고 실제 결합된 형태를 파악하는 능력이 중요해진다.
- 된다. 즉, 종료값 '99999'가 합계 구하는 연산에 사용된 예가 있으면 'Sentinel-ReadProcess-While Plan, 구현의 잘못에 따라 합계 계산에 종료값이 잘못 사용되는 오류가 야기되었다는 것을 예제 데이터를 제시하여 설명할 수 있게 되는 것이다. 만일 오류를 확인해 주는 예제가 나타나지 않는 경우에는 매칭과정의 오류 종류와 내용에 따라서 판정을 내리게 된다.
- 프로그램 397개 중에서90%에 해당하는 357 개의 프로그램에 대해 익스버그는 분석을 정상적으로 완료하였다. 이에는 'goto'나 'case, 문 및 배열의 사용을 포함한 다양한 형태의 프로그램이 포함되어 있다.
- 프로그램 실행 결과를 이용하면 패턴 매칭에서 야기된 플랜 간의 강한 연관관계를 줄이고 플랜 매칭을 효율적으로 할 수 있게 된다. 즉, 플랜 간의 강한 위치관계라는 연관 관계의 표현 방식을 줄이는 대신, 프로그램 실행 결과를 이용하여 플랜 간 공통변수에 대한 조건이만족되었는지를 조사함으로써 서로간의 인과관계를 표시할 수 있게 되었다.
후속연구
- 둘째로는 플랜 간의 인과관계가 좀 더 명확하게 표현됨으로써 이를 이용한 오류의 설명도 보다 구체적이고 직접적으로 가능해 졌다는 점이다. 위의 예에서 입력값 검사 검사 플랜과 합계 플랜 간에는 공통변수를 매개로 해서 인과 관계가 성립한다는 것을 새로운 표현방식에서는 알 수 있다.
- 먼저 제기된 조건이 제대로 구현되었는지 여부를 검사할 수 있는 방법이 제시되어야 할것이다. 이를 위해서는 테스트 데이터로 프로그램을 실행하면서 중간 값을 저장해 두었다가, 필요 시 조건이 만족되었는지 여부를 검사할 수 있어야 할 것이다.
- 그림 1의 예제를 가지고 설명을 한다면, 합계를 구하는 플랜의 덧셈 문이 8번 라인의 덧셈문과 일치하는 지를 검토할 때, 실제로 8번 라인이 실행되면서 더해지는 'rain'변수의 중간값이 모두 저장되어 있어야 하고 그 값들이 모두 종료값，99999'는 아닌지 검사할 수 있어야 한다. 이를 위해서 프로그램이 실행이 가능하여 하고, 주어진 테스트 데이터를 바탕으로 프로그램 실행 루틴에서 변수 값의 변화와 조건문에서 검토되는 변수들의 중간 값이 모두가 저장되어져야 할 것이 다.
- 검사할 수 있는 방법이 제시되어야 할것이다. 이를 위해서는 테스트 데이터로 프로그램을 실행하면서 중간 값을 저장해 두었다가, 필요 시 조건이 만족되었는지 여부를 검사할 수 있어야 할 것이다. 그림 1의 예제를 가지고 설명을 한다면, 합계를 구하는 플랜의 덧셈 문이 8번 라인의 덧셈문과 일치하는 지를 검토할 때, 실제로 8번 라인이 실행되면서 더해지는 'rain'변수의 중간값이 모두 저장되어 있어야 하고 그 값들이 모두 종료값，99999'는 아닌지 검사할 수 있어야 한다.
- 따라서 합계를 구하는 연산문의 해석과정에서 더해지는 변수의 값이 입력값인지, '99999'는 아닌 지를 살펴보아 두 플랜 간의 조건 검사가 유지 됐는지를서는 덧셈 연산문의 더해지는 값에 대해 입력값인지, 특정한 값은 아닌지를 검사할 수 있는 방법이 필요하다. 프로그램을 실행하면서 중간 결과를 저장해 놓으면 이를 이용해서 필요 시점에서 더해지는 값들을 살펴보아 판단할 수 있을 것이다. 프로그램 실행 결과가 필요한 이유는 여기에 있다.
- 향후 과제로는 플랜의 해석 과정에서 코드 매칭을 이용함에 따라 형태적 변화를 흡수하지 못하고 코드만 차이가 있는 비슷한 플랜을 양산하는 문제점을 안고 있다. (조건식이나 복잡한 계산식의 경우 전처리를 통해 일부 표준화를 이루었으나 의미는 같으면서 형태가 약간 차이가 있는 각기 다른 플랜으로 정의해야 한다).
※ AI-Helper는 부적절한 답변을 할 수 있습니다.