비동기적 프로그램 흐름의 모델링을 갖는 소프트웨어 도구 document_id A220517010439

본 발명은 일반적으로 컴퓨터 소프트웨어 시스템에 관한 것으로서, 보다 구체적으로는 실행에 앞서 컴퓨터 프로그램을 프로세싱하는 컴퓨터 소프트웨어 시스템에 관한 것이다. 컴퓨터 프로그램은 종종 일련의 명령어로서 작성된다. 어떤 명령어는 프로그램이 실행될 때 수행되는 동작을 지정할 수 있다. 다른 명령어는 다른 명령이 실행되는 순서 또는 조건을 지정함으로써 프로그램 흐름을 제어할 수 있다. 또다른 명령어는 프로그램에서의 변수를 나타내는 정보가 프로그램을 실행하는 프로세서에 부속된 메모리에 어떻게 저장되는지 등의 프로그램의 실행의 파라미터를 지정할 수 있다. 고레벨 프로그래밍 언어에서, 명령어는 반드시 소프트웨어가 실행될 플랫폼에 의해 실행될 수 있는 명령어와 일대일 관계로 대응하지 않아도 된다. 오히려, 명령어는 사람이 이해할 수 있는 형태로 되어 있을 수 있다. 이러한 형태의 프로그램은 먼저 프로세싱되어 특정의 플랫폼에 의해 실행되기에 적당한 형태로 되어야만 한다. 다른 프로세서 또는 다른 오퍼레이팅 시스템을 갖는 플랫폼은 프로그램이 적절한 실행을 위해 다르게 표현되도록 요구할 수 있다. 소프트웨어 도구는 보통 프로그램을 특정의 플랫폼에 의해 실행될 수 있는 형태로 변환하는 데 사용된다. 도구의 예로는 컴파일러가 있다. 단순히 각각의 고레벨 명령어를 프로세서가 실행할 수 있는 일련의 명령어로 표현하는 것 이외에, 이들 도구는 프로그램을 최적화하거나 다른 방식으로 그를 프로세싱할 수 있다. 프로그램이 실행을 위해 준비되고 있을 때 프로그램 상에서 수행될 수 있는 프로세싱의 예는 데드 코드(dead code) 제거, 스케쥴링, 코드 이동(code motion) 및 공통 부분식 제거(common sub-expression elimination)가 있다. 프로그램의 프로세싱 시에, 소프트웨어 도구는 종종 코드를 중간 표현으로 변환한다. 중간 표현은 프로그램이 실행될 때 수행되어야만 하는 동작의 알맞은 표현을 제공한다. 또한, 중간 표현은 프로그램이 실행되는 동안 변수들이 사용되는 프로그램의 일부분에 관한 정보를 비롯하여, 정보를 저장하는 데 사용되어질 그 변수들에 관한 정보를 제공한다. 중간 표현은 또한 동작들 간의 프로그램 흐름에 관한 정보를 제공한다. 종종, 중간 표현은 프로그램의 흐름을 "흐름도(flow graph)"로서 기술한다. 흐름도는 블록 및 엣지(edge)를 포함한다. 각각의 블록은 소정의 순서로 실행되어질 명령어의 모음을 나타내며, 따라서 블록에 대한 하나의 시작점 및 하나의 종료점이 있다. 흐름도에서, 엣지는 블록들이 실행되는 순서를 나타내기 위해 블록들을 상호 연결시킨다. 흐름도는 프로그램이 실행될 때 취해질 수 있는 블록을 통과하는 모든 가능한 경로를 나타내는 엣지를 포함한다. 다수의 경로가 각각의 블록에 연결될 수 있다. 프로그램 흐름 및 메모리 요구사항에 관한 정보는 프로그램을 여러 방식으로 프로세싱하는 데 사용될 수 있다. 이 정보는 특정의 플랫폼 상에서 실행하기 위한 프로그램을 구현하는 명령어를 준비하는 데 사용될 수 있거나 플랫폼 독립적인 방식으로 최적화를 행하는 데 사용될 수 있다. 도 1a는 C# 고레벨 프로그래밍 언어로 작성된 프로그램(100)을 나타낸 것이다. 프로그램(100)은 명령어(112, 114) 등의 일련의 명령어를 포함한다. 도 1a의 예에서, 명령어(112, 114)는 변수 Y의 "정의"이다. 본 명세서에서 사용되는 바와 같이, 용어 "정의"는 일반적으로 변수와 연관된 정보를 생성, 수정 또는 다른 방식으로 변경할 수 있는 임의의 명령어를 말한다. 프로그램(100)은 또한 try 보디(try body)의 시작을 정의하는 명령어(120)를 포함한다. 중괄호(121)는 명령어(120)로 시작하는 try 보디의 끝을 정의한다. try 보디는 또한 때로는 "코드의 피보호 영역(protected region of code)"이라고 부른다. try 보디는 때로는 "보호 영역(protecting region)" 또는 "핸들러(handler)"라고도 하는 하나 이상의 코드의 보호 영역과 관련하여 동작할 수 있다. 여기에, 2개의 핸들러, 예외(exception) 핸들러 및 "finally" 핸들러가 예시되어 있다. 예외 핸들러는 또한 "catch 핸들러"라고도 한다. 예외 핸들러는 명령어(122)로 시작하고 중괄호(123)로 끝난다. 프로그램(100)은 또한 try 보디와 연관된 finally 핸들러를 갖는다. finally 핸들러는 명령어(124)로 시작하고 중괄호(125)로 끝난다. 프로그램(100)은 또한 try 보디 밖에 위치하는 명령어(130) 등의 명령어를 포함한다. 핸들러의 동작은 프로그램(100)의 실행을 예시하는 도 1b에 나타내어져 있다. 이 예에서, try 보디(140)는 프로그램(100) 내의 첫번째 실행가능 명령어를 포함한다. 정상 동작 시에, try 보디(140)가 먼저 실행되고, try 보디(140) 내의 명령어들이 그 명령어들에 의해 지정된 순서로 실행된다. finally 핸들러(144) 내의 명령어들은 try 보디(140), 예외 핸들러(142) 및 finally 핸들러(144)로 이루어진 try 영역 내의 마지막 명령어들로서 실행된다. 정상 실행 시에, try 보디(140) 내의 명령어들의 실행이 완료되면, 실행은 finally 핸들러(144)로 넘어간다. finally 핸들러(144) 내의 명령어들이 실행된 후에, try 영역(140) 이후의 프로그램(100) 내의 명령어들이 실행된다. 여기서, 그 명령어들은 영역(150)에 있다. 예외 핸들러(142) 내의 명령어들은 try 보디(140) 내의 명령어들이 실행되는 동안에 예외가 발생하는 경우에만 실행된다. 예외 조건은 프로그램(100)에서 특수 예외 명령어들의 실행에 의해 생성될 수 있다. 그렇지만, 대부분의 경우, 예외 조건은 프로그램(100)을 실행하는 플랫폼에 대해 그 플랫폼에게는 부적법한 동작인 것으로 생각되는 동작을 수행하라고 명령하는 프로그램(100) 내의 명령어의 실행에 의해 야기된다. 부적법한 동작의 예로는 영으로 나누는 것과, 플랫폼에 대해 시스템에 설치되어 있지도 않고 오퍼레이팅 시스템에 의해 예비되어 있지도 않은 주소의 메모리에 액세스하도록 지시하는 명령어가 있다. 예외 핸들러(142)는 비동기적으로 실행되는 것으로 생각될 수 있다. 본 명세서에서 사용되는 바와 같이, 용어 "비동기적"은 결과적으로 제어의 이전을 야기하도록 하기 위한 프로그램 내의 명령어가 아닌 프로그램 실행 동안에 조건에 응답하여 발생하는 예외 등의 이벤트를 기술한다. finally 핸들러(144)도 또한 예외 핸들러(142) 이후에 실행될 수 있기 때문에 비동기적으로 실행되는 것으로 생각될 수 있다. 도 1c는 try 보디(140)로부터 예외 핸들러(142)까지의 가능한 경로를 보다 상세히 나타내고, 따라서 비동기적 이벤트로부터 일어날 수 있는 문제를 나타내는 흐름도이다. try 영역(140) 내의 명령어들 각각은 162, 164, 166, 168, 170 또는 172 등의 블록으로 나타내어져 있다. 엣지(178) 등의 엣지는 블록들 간의 정상적인 흐름을 나타낸다. 엣지(180A, 180B, 182, 184, 186, 188, 190, 192)는 비동기적 엣지를 나타낸다. 비동기적 엣지는 try 보디(140) 내의 임의의 명령어의 실행이 프로그램 흐름을 예외 핸들러(142)로 넘어가도록 야기할 수 있을 가능성을 나타낸다. 엣지(180A)는 try 보디(140) 내의 임의의 명령어의 실행에 앞서 에러가 발생할 수 있을 가능성을 나타낸다. 엣지(180B)는 예외 핸들러(142)의 실행의 종료 시에 발생하는 제어의 이전을 나타낸다. 어떤 종래 기술의 소프트웨어 도구는 try 영역 - 도 1c에 나타낸 바와 같이 핸들러 영역(142)으로 흐름이 넘어갈 수 있는 모든 가능한 명령어로부터의 엣지를 부가함으로써 이 try 영역으로부터 제어의 비동기적 이전이 가능함 - 을 비롯하여 프로그램의 중간 표현을 형성한다. try 영역 내의 모든 명령어로부터의 엣지를 부가하는 것은 프로그램의 불완전한 표현을 프로세싱한 결과로 일어날 수 있는 에러를 피하기 위해 사용되어 왔다. 그렇지만, 도 1c에 나타낸 "모든 가능한 엣지(all possible edges)" 방법을 사용하여 비동기적 엣지를 부가하는 것의 단점은 그 결과 흐름도가 복잡하다는 것이다. 프로그램(100)은 비교적 간단한 프로그램을 나타낸다. 상업적으로 중요한 프로그램은 예시된 것보다 더욱 많은 명령어를 포함할 수 있다. 게다가, 프로그램은 다수의 핸들러가 각각의 영역과 연관되어 있는 다수의 try 영역을 포함할 수 있다. 게다가, try 영역은 다른 try 영역 내에 내포될 수 있다. 다른 복잡한 것으로서, 핸들러의 실행 후에 흐름이 try 보디의 끝으로 복귀할 필요가 없다. 핸들러는 프로그램 흐름을 프로그램 내의 임의의 장소로 또는 프로그램 내의 다수의 장소 중 어느 곳으로라도 바꿀 수 있으며, 그 특정의 장소는 런타임시 조건에 의해 결정된다. 그 결과, 모든 가능한 비동기적 엣지를 흐름도에 부가하는 것은 흐름도를 아주 복잡하게 만든다. 이러한 흐름도에 기초하여 프로그램을 프로세싱하는 것은 따라서 상당한 시간 또는 컴퓨터 자원을 필요로 할 수 있다. 어떤 종래 기술의 소프트웨어 도구에서, 모든 가능한 비동기적 엣지를 부가한 결과로 인한 복잡성은 비동기적 엣지를 갖지 않는 흐름도를 생성하는 것에 의해 회피된다. 그렇지만, 보상하기 위해, 이들 흐름도에 기초하여 프로그램을 프로세싱하는 도구는 모든 가능한 흐름 경로의 정확한 표현에 의존하는 try 영역 내의 명령어들에 대해 동작을 수행하지 않는다. 이와 같이 프로그램을 프로세싱하는 것이 보다 빠르거나 간단할 수 있지만, 소프트웨어 도구의 이점이 달성되지 않는다. 소프트웨어 도구에 의한 프로그램의 프로세싱을 용이하게 해주기 위해 제어의 비동기적 이전을 비롯하여 프로그램을 표현하는 방법을 갖는 것이 바람직하다.