KR20040004619A

KR20040004619A - 구식 소프트웨어 애플리케이션을 최신의 객체 지향시스템으로 전환하는 방법과 시스템

Info

Publication number: KR20040004619A
Application number: KR10-2003-7014651A
Authority: KR
Inventors: 데이비드 턴드레우; 존 마호니
Original assignee: 컴퓨터 어소시에이츠 싱크, 인코포레이티드
Priority date: 2001-05-11
Filing date: 2002-05-10
Publication date: 2004-01-13
Also published as: US7467375B2; CA2446162A1; ATE476702T1; IL158696A0; ZA200308593B; AU2008201056A1; WO2002093367A1; DE60237200D1; CN1509433A; EP1388054B1; US20030226132A1; BR0209497A; JP2005515518A; EP1388054A1

Abstract

절차적 언어 코드로 작성된 절차적 프로그램을 객체 지향형 프로그램으로 전환하는 방법으로서, 절차적 언어 코드를 검사하고, 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 단계; 검사된 절차적 언어 코드를 중간 코드로서 저장하는 단계; 맵을 이용하여 상기 절차적 언어 코드 중 적어도 한 세그먼트를 처리하는 단계; 처리된 세그먼트를 이용하여 제1 데이터 구조를 생성하는 단계; 제1 데이터 구조에 기초하여 중간 코드를 변경하는 단계; 및 변경된 중간 코드에 기초하여 오브젝트 클래스를 갖는 객체 지향형 프로그램을 생성하는 단계를 포함한다.

Description

구식 소프트웨어 애플리케이션을 최신의 객체 지향 시스템으로 전환하는 방법과 시스템{METHOD AND SYSTEM FOR TRANSFORMING LEGACY SOFTWARE APPLICATIONS INTO MODERN OBJECT-ORIENTED SYSTEMS}

<관련 출원의 상호 참조>

본 출원은, 2001년 5월 11일자로 출원된 "구식 소프트웨어 애플리케이션을 최신의 객체 지향 시스템으로 전환하는 방법과 시스템(METHOD AND SYSTEM FOR TRANSFORMING LEGACY SOFTWARE APPLICATIONS INTO MODERN OBJECT-ORIENCTED SYSTEMS)"이라는 명칭의 미국특허 가출원 제60/290,203호에 기초한 권리를 향유하며, 상기 가출원의 전체 내용은 본 명세서에 참조로서 인용되어 있다.

소프트웨어 애플리케이션을 한 프로그래밍 언어로부터 다른 프로그래밍 언어로 변환(converting)하는 기법과 방식이 다수 존재한다. 그런데, 소프트웨어 애플리케이션을 작성하는 언어는 소프트웨어 애플리케이션의 마크업(markup) 중 단지 일면일 뿐이다. 소프트웨어 애플리케이션은 여러 구성 요소를 갖는 복잡한 시스템이다.

"코드(code)"는 프로그래밍 언어로 작성된 소프트웨어 애플리케이션의 일부로서, 소프트웨어 애플리케이션이 여러 가지 상황 하에서 수행하여할 작업을 위한 명령어(instruction)들을 포함한다. 컴퓨터의 초창기에는, 소프트웨어 애플리케이션이 어셈블리 언어(assembly language)로 작성되었다. 어셈블리 언어의 프로그램은, 어셈블러(assembler)라고 하는 애플리케이션에 의해 기계어(machine language)로 변환되며, 기계어가 컴퓨터의 중앙 처리 장치에서 실행된다. 어셈블리 언어의 연산들은 매우 낮은 레벨이어서, 애플리케이션 작성을 어렵게 하였다. 컴퓨터 기술이 발전함에 따라, 그 대안이 되는 "보다 높은 레벨의" 언어들이 개발되어, 프로그래머는, 복잡한 태스크(task)들을 수행하는 소프트웨어를 보다 쉽게 만들어낼 수 있게 되었다. 컴파일러(compiler)라고 하는 특수한 소프트웨어 애플리케이션이 개발되었는데, 컴파일러는 보다 높은 레벨의 언어를 기계어로 변형하여, 기계어가 컴퓨터에 의해 실행될 수 있게 하였다. 높은 레벨의 언어들은 프로그래머가 코드를 루틴(routine) 또는 프로시저(procedure)라고 하는 코드 블럭들로 조직화할 수 있게 하며, 이 코드 블럭들은, 필요한 경우, 반복해서 사용될 수 있다.

또한, 소프트웨어 애플리케이션은 정보를 운용할 필요가 있다. 따라서, 소프트웨어 개발 툴(tool)은 데이터 구조(data structure)를 선언(declaring)하는 기능을 제공한다. 데이터 구조는, 데이터를, 조직화하고 식별 가능한 방식으로 메모리에 저장하는 방법을 제공하며, 이 데이터는 코드에 의해 실행될 수 있다. 코드는 데이터 구조에 의거하여 실행되는 명령어들을 포함하며, 루틴이라고 하는 세그먼트(segment)들로 분류된다. 초기의 소프트웨어 개발 툴에서는, 데이터 구조와 루틴이 개별적으로 정의되었다. 데이터에 대해 동작하는 임의의 루틴의 순서에 따라, 데이터는 파라미터(parameter)로서 해당 루틴으로 전달되어야 했다. 루틴을 호출하고 파라미터를 전달하는 소프트웨어 작성 방법을 일반적으로 "절차적 프로그래밍(procedural programming)"이라고 한다. 보다 최신의 방법은 "객체 지향(object oriented)" 즉, OO 모델이다. OO 모델은 절차적 모델과는 현격히 다르다.

OO 모델에 있어서, 데이터 구조와 코드 루틴은 "클래스(class)"라고 하는 단일의, 독립적인 데이터 구조로 분류될 수 있다. 클래스는, 메소드(method)라고 하는 루틴과, 개별 타입(type)의 오브젝트(object)가 되는 데이터 구조의 템플릿 정의(template definition)이다. 클래스는 멤버 오브젝트(memeber object)들의 공통의 특성(property)들을 정의한다. OO 프로그램은, 모듈(module) 단위의 재사용 가능한 코드 구조로 인해, 쉽게 작성되고, 변경될 수 있다.

또한, OO 프로그래밍은 상속(inheritance)과 같은 여러 다른 유리한 특징들을 허용한다. 상속은 사용자가 우선, 다른 객체를 부모 클래스(parent class)(또는, "슈퍼 클래스(super class)")로서 기술한 다음, 새로운 객체를 생성할 수 있게 한다. 새롭게 생성된 객체는 그 부모 클래스의 모든 기능들을 바로 획득한다. 그럼에도, 사용자는 어떤 상황에서도 새로운 클래스의 행위(behavior)를 커스터마이징(customizing)할 수 있다.

"유저 인터페이스(user interface)"는 한 개체와 소프트웨어 애플리케이션이상호 작용할 수 있도록 하는 소프트웨어 애플리케이션의 일부이다. 많은 경우, 유저 인터페이스는 "양식(form)"을 이용하여 제작된다. 양식은 사용자에게 표시 장치 상으로 제공되는 "필드(field)" 및 "트림(trim)"의 외형을 지정한다. 필드는 사용자가 데이터를 입력할 수 있는 개개의 영역이다. 트림은, 라벨(label)과 같이 사용자에게 여러 필드들 중 어느 필드를 입력하도록 지시하거나 해당 애플리케이션의 임의의 다른 목적을 제공하는 고정된 정보이다. 종종, 이러한 양식은 코드를 이용하여 구현되지 않는 것도 있다. 한편, 프로그래머가 양식을 상호 작용형으로 구성할 수 있게 하는 소프트웨어 개발 환경의 일부인 "양식 편집기(forms editor)"가 있다. 양식의 정의는 저장소(repository)에 저장되어 있으며, 소프트웨어 개발 환경에서는 애플리케이션을 실행할 때 해당 양식을 표시한다.

1970년대 및 1980년대의 소프트웨어 개발 툴들은 "문자 기반의(character based)" 유저 인터페이스를 사용하였다. 통상적으로, 이러한 유저 인터페이스는 1 라인 당 80 문자 단위로 24 라인의 양식을 표시하도록 규정되었다. 상기 툴들은, 실행되는 양식에 관련된 명령(command)들을 표시하기 위해, 단말기 상에 25번째 라인을 이용하기도 하였다. 보다 최신의 툴들은, 그래픽 유저 인터페이스(graphical user interface : GUI)를 이용하는 양식을 구현할 수 있게 한다. GUI는, 매우 많은 수의 다양한 사용자 제어 수단을 갖는, 보다 복잡한 양식을 구현할 수 있게 한다.

이와 함께, 코드와 양식은 태스크를 수행하도록 실행될 수 있는 애플리케이션을 생성한다. 유저 인터페이스를 관리하는 이 프로그램의 한 부분을 "프리젠테이션 로직(presentation logic)"이라고 한다. 이는, 사용자의 입력을 잡아내거나, 프로그램 실행을 기동시키거나, 사용자에게 추가의 정보를 제시하거나, 표시 장치에 변경을 행하는 코드 문장들을 포함한다. 이러한 코드의 나머지 부분은 "비즈니스 로직(business logic)"이라고 한다. 비즈니스 로직은 작업 흐름, 데이터베이스 접근, 트랜잭션, 및 사용자 명령의 결과가 되는 그 외 다른 실행들을 포함한다. 비즈니스 로직과 프리젠테이션 로직은 긴밀히 결합되어 있는 것이 매우 일반적이다.

데이터베이스 관리 시스템(database management system : DBMS)은 데이터베이스에 정보를 저장하고, 데이터베이스의 정보를 변경하며, 데이터베이스로부터 정보를 추출할 수 있는 프로그램의 집합체이다. 데이터베이스로부터 정보를 요청하는 것은 질의(query)의 형식으로 이루어지며, 질의는 일정하게 양식화된 질문이다. 질의를 구성하기 위한 규칙들의 집합이 질의어(query language)라고 알려져 있다. SQL(structured query language)이라고 하는 준 표준화된 질의어가 존재함에도 불구하고, 서로 다른 DBMS는 서로 다른 질의어를 지원한다.

데이터베이스에 저장되어 있는 정보는 다양한 포맷으로 제공될 수 있다. 대부분의 DBMS는, 데이터를 보고서 형식으로 출력할 수 있는 보고서 작성기 프로그램을 포함한다. 보고서 작성기 프로그램은 보고서 생성기라고도 하며, 하나 이상의 파일로부터 정보를 추출하여 그 정보를 특정한 포맷으로 제공하는 데이터베이스 관리 시스템의 일부이다. 보고서 작성기 프로그램은, 소정의 조건을 만족하는 레코드에 대한 선택이 가능하며, 선택된 필드들을 행과 열의 형식으로 표시한다. 데이터는 파이 차트, 바 차트, 및 그 외 다른 도면으로 포맷팅될 수 있다. 보고서 포맷이 생성되면, 포맷 명세가 파일에 저장되어, 향후의 프리젠테이션에 재이용될 수 있다.

관계형 데이터베이스 관리 시스템(relational database management system : RDBMS)은 데이터베이스 관리 시스템(DBMS)의 한 종류로서, 데이터를 관계형 테이블의 형식으로 저장한다. 관계형 데이터베이스는 데이터가 어떤 관계에 있는지 혹은 데이터가 데이터베이스로부터 어떻게 추출될 것인지에 대한 몇 가지 가정을 필요로 할 수 있다. 즉, 동일한 데이터베이스를 여러 다른 방식으로 접근해 볼 수 있다. 관계형 데이터베이스 관리 시스템에서는, 정보가 스프레드시트(spreadsheet)와 같이 행과 열로 정렬된 데이터를 참조하는 테이블의 형식으로 저장된다. 관계형 데이터베이스 관리 시스템의 한 가지 바람직한 장점은 단일 데이터베이스가 수 개의 테이블들에 걸쳐서 전개될 수 있다는 점이다.

소프트웨어 애플리케이션은 소정의 유형의 "아키텍처(architecture)"에 의해 구현된다. 아키텍처는 애플리케이션의 기본적인 인프라스트럭처(infrastructure)를 기술한다. 아키텍처의 한 양상으로는, 서로 연관된 복수의 컴퓨터와 관련된다는 것이다. 단일 계층(single-tier) 소프트웨어 애플리케이션은 모든 애플리케이션 및/또는 시스템이 단일 컴퓨터 상에서 실행되는 것을 말한다. 이는, 소프트웨어 애플리케이션이 다른 소프트웨어 애플리케이션에 발호할 필요가 있는 외부 호출을 포함함을 의미한다. 예를 들면, 소프트웨어 애플리케이션이 데이터를 검색하거나 갱신하기 위해서는 데이터베이스 관리 시스템을 "호출"할 것이다. 단일 계층모델에서는, 소프트웨어 애플리케이션과 데이터베이스 관리 시스템 모두가 단일의 컴퓨터 상에서 실행된다. 유저 인터페이스는, 단지 양식을 표시하여 사용자가 정보를 입력할 수 있게 하고, 그 입력을 "호스트(host)" 컴퓨터에 반환할 수 있는 장치에 불과한 "단순 단말기(dumb terminal)" 상에 표시될 수 있다.

클라이언트/서버(client/server) 애플리케이션 즉, 2 계층(two-tiered) 소프트웨어 애플리케이션은, 한 컴퓨터(즉, 클라이언트) 상에서 소정의 소프트웨어 애플리케이션이 실행되고, 네트워크 연결을 통해서, 또 다른 컴퓨터(즉, 서버) 상에서 실행되고 있는 다른 소프트웨어 애플리케이션으로 외부 호출을 발호하는 것이다.

보다 최근의 아키텍처 신기술은 N 계층(N-tiered) 애플리케이션이다. 이 N 계층 모델에 있어서는, 소프트웨어 애플리케이션의 일부만이 클라이언트 워크스테이션 상에서 실행된다. 이는 지능형 유저 인터페이스(또는, 씬 클라이언트(thin client))인 것이 통상적이다. 소정의 태스크가 수행될 필요가 있는 경우에, 클라이언트는 필요한 비즈니스 로직을 포함하는 "애플리케이션 서버"의 위치를 알아내며, 실제적으로 작업은 이 애플리케이션 서버를 실행하는 컴퓨터 상에서 수행된다. 마찬가지로, 애플리케이션 서버는 상기 클라이언트가 요청한 프로세싱을 완료하기 위해서 데이터베이스 서버와 같은 또 다른 컴퓨터를 접속할 필요가 있을 수 있다. 이와 같이 연쇄적인 이벤트들의 연결은 궁극적으로 무한개의 컴퓨터를 포함할 수 있으므로, 이러한 모델을 N 계층 모델이라고 한다.

오늘날 여러 조직체들이 당면한 과제 중 하나는, 문자 인터페이스를 이용하며 기본적으로 절차적이고 단일 계층의 모델로 구현된 소프트웨어 애플리케이션을 개발하는 데에 상당한 비용과 시간을 투자했다는 것이다. 이러한 애플리케이션을 일반적으로 "구식(legacy)" 애플리케이션이라고 한다. 개발자들은 구식 애플리케이션을 창출해 내었던 기술은 더 이상 배우지 않기 때문에, 구식 애플리케이션을 지원하고 개량하는 것은 중요한 과제가 된다. 또한, 현 사회의 인터넷과 전자 상거래는 그래픽 유저 인터페이스를 이용하며 기본적으로 객체 지향형이고 N 계층 모델을 이용하여 구현되는 시스템을 필요로 한다. 조직체가 기존의 구식 애플리케이션들을 그래픽 유저 인터페이스를 이용하는 최신의 객체 지향형 N 계층 애플리케이션으로 전환할 수 있게 하는 기술은 지금까지 개발되지 않았다. 결국, 조직체는 최신의 툴들을 이용하여 구식 애플리케이션을 완전히 재설계하고 재작성하기 위해 시간을 소모하고 고비용이 드는 과정에 착수해야만 한다.

본 발명에 따른 방법과 시스템은 상술한 문제점들과 그 외 다른 문제점들을 해결한다. 예를 들어, 본 발명에 따른 방법과 시스템은 구식 소프트웨어 애플리케이션을 GUI 기반의 소프트웨어 애플리케이션으로 "전환(transforming)"할 수 있다. 본 발명에 따른 전환 처리는 시스템의 개개의 부분을 변환하고 개량하는 것을 포함한다. 단일 프로세스에 있어서, 구식 소프트웨어 애플리케이션의 문자 기반 유저 인터페이스는 GUI로 전환될 수 있고, 코드와 데이터 구조는 적절한 형태의 오브젝트 클래스로서 통합, 교체, 및 재생(regeneration)되며, 이와 같이 구식 소프트웨어 애플리케이션을 개량하고 부가함으로써, 구식 소프트웨어 애플리케이션을 클라이언트/서버나 N 계층 시스템으로 동작할 수 있게 한다.

본 발명은 컴퓨터 프로그램의 전환(transformation)에 관한 것이다. 보다 구체적으로, 본 발명은 구식(legacy) 소프트웨어 애플리케이션을 최신의 객체 지향 시스템(object-oriented system)으로 전환하는 방법과 시스템에 관한 것이다.

첨부된 도면과 함께 이하의 상세한 설명을 참조하면 본 발명 및 그에 따른 수많은 장점들을 보다 완전하게 인식하고, 또한 보다 양호하게 이해할 수 있다 :

도 1은 본 발명의 방법과 시스템을 구현할 수 있는 컴퓨터 시스템의 일례를 도시하는 도면.

도 2는 본 발명의 일 실시예에 따른 프로세스 차트예를 도시하는 도면.

도 3은 본 발명의 일 실시예에 따른 구식 언어 문법 트리의 포맷예를 도시하는 도면.

도 4는 본 발명의 일 실시예에 따른 추상 구문 트리의 포맷예를 도시하는 도면.

도 5는 본 발명의 일 실시예에 따른 프로세스의 흐름도.

도 6은 XML 문서로서 표현된 추상 구문 트리의 샘플 표현의 예시도.

본 발명은, 절차적 언어 코드로 작성된 절차적 프로그램을 객체 지향형 프로그램으로 전환하는 방법에 관한 것으로서, 이 방법은, 절차적 언어 코드를 검사(scanning)하고, 검사된 절차적 언어 코드에 기초하여 맵(map)을 생성하는 단계; 검사된 절차적 언어 코드를 중간 코드(intermediate code)로서 저장하는 단계; 맵을 이용하여 절차적 언어 코드 중 적어도 한 세그먼트를 처리하는 단계; 처리된 세그먼트를 이용하여 제1 데이터 구조를 생성하는 단계; 제1 데이터 구조에 기초하여 중간 코드를 변경하는 단계; 및 변경된 중간 코드에 기초하여 오브젝트 클래스를 갖는 객체 지향형 프로그램을 작성하는 단계를 포함한다. 또한, 이 방법은, 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 절차적 언어 코드의 세그먼트를 처리하는 상기 단계를 중지하는 단계; 및 상기 소정의 세그먼트에 기초하여 다른 중간 코드를 변경하는 단계를 포함할 수 있다. 또한, 이 방법은, 절차적 언어에 기초하여 제2 데이터 구조를 생성하는 단계를 포함할 수 있으며, 제2 데이터 구조는 절차적 프로그래밍 언어의 문장의 특성을 식별하는 노드(node)를 갖는 계층 트리(hierarchical tree)일 수 있다. 제1 데이터 구조를 생성하는 단계는, 처리된 세그먼트에 기초하여 제2 데이터 구조에서 노드의 위치를 정하는 단계, 제2 데이터 구조의 노드들을 루트 노드까지 순회(traversing)하는 단계, 및 순회한 노드들의 내용을 제1 데이터 구조에 포함시키는 단계를 포함할 수 있다.

또한, 본 발명은 절차적 언어 코드로 작성된 절차적 프로그램을 객체 지향형 프로그램으로 전환하는 컴퓨터 실행 가능 코드를 포함하는 저장 매체에 관한 것으로서, 상기 저장 매체는, 절차적 언어 코드를 검사하고, 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 코드; 검사된 절차적 언어 코드를 중간 코드로서 저장하는 코드; 맵을 이용하여 절차적 언어 코드 중 적어도 한 세그먼트를 처리하는 코드; 처리된 세그먼트를 이용하여 제1 데이터 구조를 생성하는 코드; 제1 데이터 구조에 기초하여 중간 코드를 변경하는 코드; 및 변경된 중간 코드에 기초하여 오브젝트 클래스를 갖는 객체 지향형 프로그램을 작성하는 코드를 포함한다. 또한, 이 저장 매체는, 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 절차적 언어 코드의 세그먼트의 처리를 중지하는 코드; 및 상기 소정의 세그먼트에 기초하여 다른 중간 코드를 변경하는 코드를 포함할 수 있다. 또한, 이 저장 매체는, 절차적 언어에 기초하여 제2 데이터 구조를 생성하는 코드를 포함할 수 있으며, 제2 데이터 구조는 절차적 프로그래밍 언어의 문장의 특성을 식별하는 노드를 갖는 계층 트리일 수 있다. 제1 데이터 구조를 생성하는 코드는, 처리된 세그먼트에 기초하여 제2 데이터 구조에서 노드의 위치를 정하는 코드, 제2 데이터 구조의 노드들을 루트 노드까지 순회하는 코드, 및 순회한 노드들의 내용을 제1 데이터 구조에 포함시키는 코드를 포함할 수 있다.

또한, 본 발명은, 절차적 언어 코드로 작성된 절차적 프로그램을 객체 지향형 프로그램으로 전환하기 위한 컴퓨터 실행 가능 명령어들을 포함하며, 전송 매체에서 구체화되는 컴퓨터 데이터 신호에 관한 것으로서, 이 컴퓨터 데이터 신호는, 절차적 언어 코드를 검사하고, 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 데이터 신호 부분; 검사된 절차적 언어 코드를 중간 코드로서 저장하는 데이터 신호 부분; 맵을 이용하여 절차적 언어 코드 중 적어도 한 세그먼트를 처리하는 데이터 신호 부분; 처리된 세그먼트를 이용하여 제1 데이터 구조를 생성하는 데이터 신호 부분; 제1 데이터 구조에 기초하여 중간 코드를 변경하는 데이터 신호 부분; 및 변경된 중간 코드에 기초하여 오브젝트 클래스를 갖는 객체 지향형 프로그램을 작성하는 데이터 신호 부분을 포함한다. 또한, 이 컴퓨터 데이터 신호는, 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 절차적 언어 코드의 세그먼트의 처리를 중지하는 데이터 신호 부분; 및 상기 소정의 세그먼트에 기초하여 다른 중간 코드를 변경하는 데이터 신호 부분을 포함할 수 있다. 또한, 이 컴퓨터 데이터 신호는, 절차적 언어에 기초하여 제2 데이터 구조를 생성하는 데이터 신호 부분을 포함할 수 있으며, 제2 데이터 구조는 절차적 프로그래밍 언어의 문장의 특성을 식별하는 노드를 갖는 계층 트리일 수 있다. 제1 데이터 구조를 생성하는 데이터 신호 부분은, 처리된 세그먼트에 기초하여 제2 데이터 구조에서 노드의 위치를 정하는 데이터 신호 부분, 제2 데이터 구조의 노드들을 루트 노드까지 순회하는 데이터 신호 부분, 및 순회한 노드들의 내용을 제1 데이터 구조에 포함시키는 데이터 신호 부분을 포함할 수 있다.

또한, 본 발명은 절차적 언어 코드로 작성된 절차적 프로그램을 객체 지향형 프로그램으로 전환하는 방법에 관한 것으로서, 이 방법은, 절차적 언어 코드를 검사하고, 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 단계; 맵 및 검사된 절차적 언어 코드를 메타데이터(metadata)로서 저장소에 저장하는 단계; 각각의 컴포넌트(component)의 전환된 표현(transformed representation)에 대해 타겟 메타데이터 컨테이너(taget metadata container)의 새로운 셋트를 생성하는 단계; 절차적인 메타데이터 표현을 이용하여 절차적 언어 코드 중 적어도 한 세그먼트를 처리하고, 처리된 세그먼트를 이용하여 제1 추상 구문(abstract syntax) 트리를 생성하는 단계; 제1 추상 구문 트리에 기초하여 타겟 메타데이터 컨테이너를 위치시키는 단계; 및 제1 추상 구문 트리에 기초하여, 오브젝트 클래스를 갖는, 원래의 절차적 프로그램의 객체 지향형 메타데이터 표현을 생성하는 단계를 포함한다. 또한, 이 방법은, 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 절차적 언어 코드의 세그먼트를 처리하는 상기 단계를 중지하는 단계; 및 상기 소정의 세그먼트에 기초하여 또 다른 추상 구문 트리를 변경하는 단계를 포함할 수 있다. 또한, 이 방법은, 절차적 언어에 기초하여 제2 추상 구문 트리를 생성하는 단계를 포함하고, 제2 추상 구문 트리는 절차적 프로그래밍 언어의 문장의 특성을 식별하는 노드를 갖는 추상 구문 트리일 수 있다. 제1 추상 구문 트리의 생성 단계는, 처리된 세그먼트에 기초하여 제2 추상 구문 트리에서 노드의 위치를 정하는 단계, 제2 추상 구문 트리의 노드들을 루트 노드까지 순회하는 단계, 및 순회한 노드들의 내용을 제1 추상 구문 트리에 포함시키는 단계를 포함한다.

도면에 도시된 본 발명의 바람직한 실시예들을 설명함에 있어서, 명백한 설명을 위해 특정 용어가 채택되었다. 그러나, 본 발명은 이와 같이 선택된 특정 용어에 한정되도록 의도된 것이 아니며, 각각의 개별 요소들은 유사한 방식으로 동작하는 모든 기술적 균등물을 포함하는 것이다.

도 1은 본 발명의 방법과 시스템을 구현할 수 있는 컴퓨터 시스템의 일례를 예시하는 도면이다. 본 발명의 시스템과 방법은, 예컨대 메인프레임(mainframe), 퍼스널 컴퓨터(personal computer : PC), 핸드헬드(handheld) 컴퓨터, 서버 등의 컴퓨터 시스템 상에서 실행되는 소프트웨어 애플리케이션의 형태로 구현될 수 있다. 이 소프트웨어 애플리케이션은, 예컨대 플로피 디스크, 컴팩트 디스크, 하드 디스크 등의, 컴퓨터 시스템에 의한 로컬 액세스가 가능한 기록 매체에 저장될 수도 있고, 또는 컴퓨터 시스템으로부터 원격으로 위치하며 예컨대 로컬 에어리어 네트워크나 인터넷 등의 유선 혹은 무선 접속을 통해 액세스 가능할 수도 있다.

컴퓨터 시스템은 일반적으로 시스템(100)이라 하며, 중앙 처리 장치(central processing unit : CPU)(102), 랜덤 액세스 메모리(random access memory : RAM) 등의 메모리(104), 프린터 인터페이스(106), 표시 장치(108), LAN 데이터 전송 제어기(110), LAN 인터페이스(112), 네트워크 제어기(114), 내부 버스(116), 및 키보드, 마우스 등의 하나 이상의 입력 디바이스(118)를 포함할 수 있다. 도시된 바와 같이, 시스템(100)은 하드 디스크(120) 등의 데이터 저장 장치에 링크(link)(122)를 통해 접속되어 있을 수 있다.

본 발명의 시스템과 방법은, 구식 애플리케이션을, 그래픽 유저 인터페이스를 이용하는 최신의 객체 지향형 N 계층 애플리케이션으로 전환하는 전환 처리를 수행한다. 이는, 구식 애플리케이션 프로그램 코드를 분석하고, 구식 애플리케이션 프로그램 코드에 기초하여 클래스 및 그의 메소드를 생성함과 함께 그래픽 유저 인터페이스를 생성하는 프로세스를 포함할 수 있다. 어떤 상황 하에서는, 구식 애플리케이션 프로그램 코드 중 일부 세그먼트들은 변환하는 것이 바람직하지 않을 수 있는데, 이러한 경우에 프로세스는 원래의 코드를 모사(transfering)하거나, 새로운 코드로 대체할 수 있다.

도 2는 본 발명의 일 실시예에 따른 프로세스 차트예를 도시하는 도면이다. 일 실시예에서, 전환 처리는 마이닝(mining) 프로세스(140)로 시작하며, 마이닝 프로세스는 발견(discovery)(142), 분석(analysis)(144), 구성(configuration)(146), GUI 스타일 위저드(GUI Style Wizard)(148), 확장 위저드(extension wizard)(150), 애플리케이션 분석 보고(152), 및 작성(154)과, 구식 소프트웨어 애플리케이션에서필요한 모든 리소스(resource)를 수집하고, 이들을 전환하는 데 필요한 그 외의 다른 단계들을 포함할 수 있다. 메타 포맷으로 저장되어 있으면, 메타 컴포넌트들은 전환 프로세스(156)와 전환 1(158)∼전환4(164)에 의해 연산되어, 메타 컴포넌트들이 처리, 재조직화, 개량될 수 있다. 이러한 전환 프로세스에서, 구식 메타 컴포넌트들은 오브젝트 메타 컴포넌트로 전환된다. 최종적으로, 재생 프로세스(166)에서, 확장 단계(168)에서는 마이닝 프로세스(140)에 의한 결과에 기초하여 라이브러리(library)가 구축되고, 재생 단계(170)에서는, 오브젝트 메타 컴포넌트가 소정의 객체 지향 언어로 된 실제의 오브젝트 클래스로서 구현된다.

본 발명의 전환 시스템을 상술한 바와 같은 복수의 프로세스로 나누는 것은, 본 발명의 추가적인 몇 가지 장점들을 제공한다. 제1 장점은 "어느 곳으로부터든지/어느 곳으로든지(from anywhere/to anywhere)"의 전환을 구성한다는 것이다. 이는, 메타 컴포넌트들의 마크업이 전환 시스템에 의해 정의될 수 있기 때문이다. 예를 들면, 소정의 구식 소프트웨어 애플리케이션을 전환하기 위해서는, 구식 컴포넌트를 메타 컴포넌트로서 저장소에 저장할 수 있는 마이닝 프로세스(140)가 제공될 수 있다. 구식 언어 소프트웨어 애플리케이션을 소정의 객체 지향 언어로 전환하기 위해서는, 오브젝트 메타 컴포넌트로부터 희망의 객체 지향 언어로 된 오브젝트 클래스를 생성할 수 있는 전환 프로세스(156) 및 재생 프로세스(166)가 제공될 수 있다. 제2 장점은 전환 결과를 변경하고자 하는 경우에 전환 시스템의 프로세스에 추가의 새로운 단계들을 부가할 수 있다는 것이다.

예를 들면, 소정의 전환 처리를 커스터마이징하기 위해, 프로세스에 "커스터마이징화(customization)" 단계를 부가하는 것이 가능하다. 커스터마이징화 단계에서는, 전환 시스템이 수행하는 다른 단계들 중 한 단계의 전 또는 후의 컴포넌트들 중 임의의 하나 또는 전부에 변경을 행할 수 있다. 이러한 커스터마이징화 단계는 컴포넌트를 부가, 삭제, 변경하는 데 이용될 수 있다. 예를 들면, 하나 이상의 양식에서 소정의 필드를 제거하고, 해당 GUI에 다른 필드 또는 (아이콘 등의) 다른 리소스를 부가하여, 관련되는 오브젝트 코드에 변경을 행하는 것이 바람직할 수 있다. 이러한 인프라스트럭처로 인해, 가능한 여러 다른 장점들이 존재한다.

본 발명에 따른 방법의 또 다른 양상으로는, 구식 소프트웨어 애플리케이션 내의 임의의 단계 또는 프로세스 및 임의의 컴포넌트로부터 재시작이 가능할 수 있다는 것이다. 예를 들면, 프로세싱 중 어느 한 부분에서 전원 장애가 발생한 경우에, 전환 시스템 및 방법은 전원 장애가 발생한 때에 처리되고 있었던 단계 및 컴포넌트로부터 재시작될 수 있다. 이러한 특징을 달성하기 위해서는, 선택된 저장소가 영구적 저장 장치(예를 들면, 데이터베이스 저장소)인 것이 바람직하다.

마이닝, 전환, 재생 프로세스를 예시하는 실시예를 이하 상세히 설명한다.

마이닝 프로세스

마이닝 프로세스(140)는 전환에 필요한 리소스를 발견하고, 이들을 저장소에 저장하며, 전환에 필요한 상기의 리소스 및 그 외 다른 임의의 메타 컴포넌트를 작성한다. 바람직하게는, 마이닝 프로세스(140)는 완전한 전환을 방해할 수 있는, 구식 소프트웨어 애플리케이션에서 발견된 소정의 결함을 보고하는 기능을 갖는다. 이러한 결함으로는, 소스 코드나 양식 정의와 같은 컴포넌트를 놓치는 것이 가장흔하다. 또한, 마이닝 프로세스(140)는, 알려진 전환 처리가 존재하지 않거나, 전환 시스템이 처리하도록 프로그램되어 있지 않은 구식 개발 환경의 기능들을 당면한 경우에 사용될 수 있는 조작자 입력을 제공할 수 있다. 이는, 조작자에게 결함을 수정하고, 프로세스의 나머지가 실행되기 전에 전환 시스템을 개선할 수 있는 기회를 제공하는 것이다.

이하의 단계들은 마이닝 프로세스(140)에 의해 수행될 수 있는 단계들의 예이다. 설명될 단계들 각각은 소정의 전환 방법에 이용될 수도 있고 그렇지 않을 수도 있다. 또한, 각각의 전환 방법에는, 프로세스에 의해 생성된 출력을 변경하는 구성 값들의 세트가 제공될 수 있다. 예를 들면, 어떤 구성 값은 구해진 컴포넌트를 특정 패턴에 기초하여 재지정될 수 있다. 구성 값들 각각은 조작자에 의해 오버라이딩(overriding)될 수 있는 디폴트 셋팅(default setting)을 가질 수 있다.

발견

발견 단계(142)는 구식 소프트웨어 개발 환경을 조회하여, 특정 애플리케이션에 포함된 컴포넌트의 카탈로그(catalog)를 알아낸다. 발견 단계는 검사되는 컴퓨터에 제공되는 운영 시스템에 따라 예컨대 물리적 메모리 블럭 및 가상 메모리 페이지 등의 적절한 논리적 메모리를 검사할 수 있다. 검사된 컴포넌트는 소스 코드, 양식 정의, 애플리케이션 구조, 관련된 데이터베이스의 스키마(schema), 양식, 프레임, 프로시저, 기록 정의, 전역 변수, 상수, 호스트 루틴 등을 포함할 수 있으나, 이에 한정되지는 않는다. 이러한 컴포넌트들은 저장소에 메타 컴포넌트로서 저장되는 것이 바람직하다. 또한, 소스 코드 컴포넌트의 경우, 소스 코드는 "토근화(tokenized)"되어 있을 수 있고, 혹은 기본적인 프로그래밍 기호의 열로 나누어져 있을 수 있다. 이 컴포넌트들의 복사본을 메타 컴포넌트로서 저장소에 저장한다. 저장소에서는 검색, 변경, 저장이 반복적으로 행하여진다. 저장소는 메모리 캐쉬, 파일 시스템, 데이터베이스, 그 외 다른 적절한 정보 저장 장치일 수 있다.

분석

분석 단계(144)에서는, 메타 컴포넌트의 정보 전부가 분석되고, 각 컴포넌트에 대한 맵이 작성된다. 맵은 각각의 루틴과 해당 루틴 내의 섹션이 토큰 스트림 내에서 시작하고 정지하는 위치에 대한 정보를 포함한다. 또한, 각각의 컴포넌트에 관한 메트릭(metric)이 애플리케이션 분석 보고(152)를 작성하는 데 사용될 수 있다.

검증(validation)

검증 과정에서는, 구식 애플리케이션의 모든 컴포넌트에 대한 상호 참조(cross reference)가 생성된다. 상호 참조는 한 컴포넌트가 참조하는 (모듈, 데이터 소스, 양식 등의) 모든 컴포넌트의 리스트를 제공한다. 그러면, 저장소는 구식 환경의 모든 컴포넌트가 저장소에 저장되어 있는지가 확실한지 검사한다. 어떤 컴포넌트들이 누락되었음을 발견한 경우에는, 조작자에게 그 결함을 처리할 수 있도록 통지한다. 처리는 참조되지 않은 컴포넌트로 계속되는데, 참조되지 않은 컴포넌트를 참조하는 컴포넌트는 완전히 전환되지 않는다.

구성

구성 단계(146)에서는, 분석 단계(144)로부터의 정보가 초기 구성을 설정하는 데 사용된다. 구식 애플리케이션 그 자체를 설명하는 이러한 구성은 메타 컴포넌트에 저장된다. 메타 컴포넌트는 전환 프로세스(156)를 제어한다. 이러한 파라미터들 중 일부는 검증 과정 시에 변경될 수 있다.

GUI 스타일 위저드

GUI 스타일 위저드(148)는 디폴트 사양을 오버라이딩함으로써 결과로 얻게 되는 그래픽 유저 인터페이스를 커스터마이징하는 기능을 조작자에게 제공한다. 이 위저드는 모든 그래픽 양식에 적용될 커스텀 메뉴 바, 툴 바, 버튼 바 정의를 생성하여, 결과로 얻게 되는 애플리케이션에 일관성 있는 외형과 분위기를 제공한다.

확장 위저드

확장 위저드(150)는 전환 프로세스(156)에 의해 애플리케이션용의 새로운 파운데이션 클래스 라이브러리(foundation class library), 비즈니스 오브젝트 라이브러리, 및 프론트 엔드 라이브러리(front-end library)가 생성될 수 있는 기회를 조작자에게 제공한다. 이러한 새로운 오브젝트 라이브러리들은 구식 소프트웨어 애플리케이션에서 구한 스키마 사양에 따라 구축되어, 새로운 애플리케이션의 새로운 특징과 기능들을 개발하는 데 필요한 시간을 크게 감소시킬 수 있다. 만일 본 단계가 실행되지 않는다면, 전환 처리에서는 상술한 라이브러리들을 생성하지 않게 된다.

애플리케이션 분석 보고

애플리케이션 분석 보고(152)는 구식 인프라스트럭처 전체에 대한 종합적인보고로서, 모든 리소스의 상호 참조 및 각각의 컴포넌트에 대한 상세한 정보 및 메트릭을 포함하는 것이 바람직하다. 또한, 애플리케이션 분석 보고는 상술한 문제 영역의 리스트를 제공한다. 메트릭은, 구식 애플리케이션의 컴포넌트의 종류와 총 수, 소스 코드의 총 라인 수, 각각의 모듈을 구성하는 루틴의 수와 정의, 애플리케이션에 의해 제공되는 모든 명령의 컴파일(compilation) 등을 포함한다.

작성

작성 단계(154)에서는, 전환 처리에서 사용될 수 있는 모든 추가적인 타겟 OO 메타 컴포넌트들이 저장소에 생성된다. 전환 프로세스의 이전의 실행에 의해 메타 컴포넌트가 저장소에 존재하는 경우에는, 이 메타 컴포넌트를 삭제하고 새로운 메타 컴포넌트를 생성한다.

전환 프로세스

전환 프로세스(156)는 오브젝트 메타 컴포넌트를 생성하기 위해 현재 저장소에 저장되어 있는 구식 메타 컴포넌트를 조작하는 메커니즘을 제공한다. 전환 프로세스(156)는 구식 애플리케이션 전체가 다단계 병렬 프로세스로 전환될 수 있는 전환 처리를 수행한다. 전환 프로세스(156)에 있어서, (코드의 예에서는) 임의의 소정의 소스 문장, 또는 양식 일부분, 또는 구식 소프트웨어 애플리케이션의 한 컴포넌트의 임의의 다른 부분은, 하나 이상의 컴포넌트(또는 프로시저)가 소정의 방식으로 변경될 수 있는 규칙을 잠재적으로 유발시킬 수 있다. 예를 들면, "프레임(frame : 프레임은 유저 인터페이스를 필요로 하는 프로시저로서, 관련 양식을 구비하고 있음)"의 전환 시, 전환 프로세스(156)는 파라미터를 발견할 수 있다. 이 파라미터는 프레임을 대체하기 위해 생성되는 오브젝트 클래스의 속성이 된다. 프레임의 처리가 중지되고, 저장소로부터 해당 오브젝트 클래스가 검색되면, 속성이 오브젝트 클래스에 부가되고, 오브젝트 클래스는 저장소로 반환되며, 소스의 처리가 재개된다. 마찬가지로, 프레임 양식 정의의 처리에 있어서도, 양식에 필드가 있는 경우, 마찬가지의 방식으로 속성이 해당 오브젝트 클래스에 부가된다. 본 프로세스에서는, 조건에 따라, 한 컴포넌트(프로시저)로부터 다른 컴포넌트로 코드 블럭 전체를 이동시킬 수 있는 보다 복잡한 트랜잭션(transaction)이 그 외에 다수 존재한다.

상술한 병렬 처리를 용이하게 하기 위해서는, 구식 소프트웨어 애플리케이션과 새로운 애플리케이션 양자로부터의 컴포넌트의 중간(intermediate) 표현을 관리하는 기능을 갖는 일시적 저장 장치 및 중간 애플리케이션(또는 "메타 애플리케이션(meta-application)")이 제공되어야 한다. 메타 애플리케이션은 특정 소프트웨어 개발 환경의 특정한 구현을 시도하기보다는 임의의 소프트웨어 개발 환경에서 구한 구성 개념(construct)을 포함하기 때문에 편리하다. "메타 컴포넌트(meta-component)"를 조작함으로써, 구식 소프트웨어 애플리케이션으로부터 새로운 애플리케이션으로 전환하는 프로세스가 마이닝, 전환, 재생의 3개의 구별된 프로세스로 분류될 수 있다.

전환 프로세스(156)의 일 실시예를 4개의 전환 처리로서 설명한다.

전환 1

전환 1 엔진(158)은 구식 소스 코드를 분해하고, 이를 용이하게 조작할 수있는 구조의 포맷으로 조직화하는 역할을 한다. 컴포넌트들의 소스 코드는 분석 단계 시에 생성된 맵을 가이드로서 이용하여 분해된다. 각각의 파라미터 및 변수 선언과 각각의 소스 문장은 분해되고, 조직화되어, 내부 포맷으로 번역된다. 이는 다양한 방식으로 수행될 수 있다. 한 가지 방식으로는, 한 컴포넌트의 구식 소스 코드를 특성 트리 데이터 구조로 분해하는 것이 있다. 특성 트리는 트리의 임의의 노드에 무한개의 식별자나 특성을 저장할 수 있는 계층적 구조이다. 이러한 분해는 여러 단계를 통해서 달성된다.

제1 단계는 구식 프로그래밍 언어의 문법 표현을 계층적 특성 트리의 형태로 전개한다. 전환하기 이전에, 도 3에 도시된 예와 같이, 구식 프로그래밍 언어의 특징을 표현하는 구식 프로그래밍 언어 문법이 작성된다. 구식 프로그래밍 언어가 지원하는 각각의 다른 유형의 문장(예컨대, FOR-ENDFOR, CALL, PROMPT 등)이 구식 프로그래밍 언어 내에서 식별된다. 문장들은 동일한 유형의 문장들을 그룹화함으로써 계층적으로 그룹화된다. 예를 들면, FOR-ENDFOR와 WHILE-ENDWHILE은 "루프 제어(loop controls)"라고 간주된다. 단일의 루트 노드(200)가 특성 트리용으로 생성된다. 루트 노드(200)에서는, 모든 문장에 대해 공통인 특성이 트리에 생성된다. 예를 들면, "라인 번호(Line Number)"는 모든 문장에 대해 공통인 특성일 수 있다. 루트 노드 아래에는, 분류 노드(classification node)(202)들이 트리에 생성되어, 상술한 문장에서 전개된 계층성을 표현한다. 각각의 분류 노드(202)에서는, 해당 노드의 문장들에 대해 공통인 특성이 구현된다. 예를 들면, "루프 카운터(Loop Counter)"는 모든 루트 제어에 대해 공통인 속성일 수 있다. 최종적으로,개개의 특정 문장을 표현하는 문장 노드(204)가 적절한 분류 노드(202)에 생성된다. 그 문장에만 해당되는 특성이 해당 문장 노드에 생성된다. 이러한 방법에서는, 적어도 하나의 공통되는 특성이 각각의 문장 노드(204)에서 그 문장에만 해당되는 디폴트 값(문장 유형)으로 정의되어야 한다.

전환 1(158)에서는, 추상 구문 트리라고 알려진 또 다른 종류의 트리가 각각의 컴포넌트마다 전개된다. 추상 구문 트리는 완전히 분해된 소스 코드를 포함하도록 설계된 특화된 버전의 계층적 특성 트리이다. 추상 구문 트리의 일례가 도 4에 도시되어 있다. 루트 노드(250)가 생성되어, 루트 노드(250)에 컴포넌트 전체를 식별하는 특성이 정의된다. 루틴 노드(252)는 컴포넌트 내에 존재하는 각각의 코드 블럭에 대해 생성된 것이다. 여러 다른 유형의 코드 블럭들을 포함하는 분류 노드(도시되지 않음)는 재생 프로세스(166)에 장점을 제공하는 경우에 생성될 수 있다 (이에 대해서는 이후에 설명할 것이다). 각각의 루틴 노드(252)는 루틴을 식별하는 파라미터를 정의하고 있다. 섹션 노드(254, 256, 258)는 루틴 노드(252) 아래에 생성되고, 그 루틴의 서로 다른 섹션들을 식별한다. 파라미터 노드(254), 지역 변수 노드(256), 문장 노드(258)의 3 유형의 섹션이 전형적이다.

또한, 전환 1(158)은 마이닝 프로세스(140)의 분석 단계(144) 시에 생성된 맵을 이용한다. 맵은 각각의 루틴과 그 루틴 내의 섹션이 토큰 스트림 내에서 시작하고 정지하는 위치에 대한 정보를 포함한다. 코드의 파라미터 섹션의 제1 토큰에서 시작하면, 전환 1(158)은 완전한 선언 문장을 찾을 때까지 토큰을 처리한다. 다음으로, 파라미터 섹션 노드(254)에 선언 노드(260)를 부가한다. 그 노드에서,파라미터로서 선언되는 변수를 완전히 정의하는 특성을 정의한다. 이는, 지역 변수 섹션과 문장 섹션에 반복된다. 전환 1(158)이 문장 유형을 식별하면, 도 3에 도시된 구식 언어 문법 트리에서 그 문장을 표현하는 노드의 위치를 정한다. 루트 노드를 포함하여 그에 이르기까지, 문장을 정의하거나 임의의 분류 노드의 특성과 같은 특성들 모두를 복사한 트리를 순회(traversing)한다. 그 다음, 컴포넌트 특성 트리의 문장 노드에 이러한 특성들을 정의한다. 다음으로, 전환 1(158)은 문장들을 파싱(parsing)하고, 각각의 특성의 디폴트 값을 문장에서 구한 정확한 값으로 치환한다.

또한, 전환 1(158)은 문장 간의 관계를 유지한다. 예를 들면, FOR 문장 다음과 그에 대응하는 ENDFOR 문장 이전의 문장은 FOR 문장 노드의 자식(child) 노드로서 생성된다. 이러한 네스팅(nesting)은 필요한 경우만큼 깊게 진행될 수 있다. 이러한 방식으로 코드를 네스팅하는 것은 전환 이후에 코드 블럭들 전체를 이동시키는 데 편리함을 제공한다. 상기한 프로세스가 완료되면, 완전하고 조직화된 버전의 구식 소스 코드가 생성되어, 이제 실행 가능하다. XML 문서로 표현된 추상 구문 트리의 화면예가 도 6에 도시되어 있다.

전환 2

전환 2 엔진(160)은 구식 양식을, 재생 처리 시에 그래픽 인터페이스를 생성하는 데 사용될 수 있는 오브젝트 메타 컴포넌트로 전환하는 역할을 한다. 이는 전환 1(158)에서 조작된 구식 소스 코드에 대한 방식과 유사한 방식으로 달성될 수 있다. 이 프로세스는 그래픽 인터페이스 양식 템플릿 트리와, OO 클래스 계층 트리의 2개의 참조 특성 트리를 이용한다.

그래픽 인터페이스 양식 템플릿 트리는 빈(empty) 그래픽 인터페이스 양식의 표현을 포함한다. 이 양식의 루트 노드는 해당 양식의 기본적인 특징의 상세를 포함한다. 이 특성 트리는 3개의 루트 노드를 포함할 수 있다. 제1 루트 노드는 "윈도우(window)"를 기술하는 특성을 포함한다. 윈도우는 그래픽 유저 인터페이스에 대한 정보를 표시하기 위한 영역이다. 제2 루트 노드는 메뉴 바에 대한 플레이스홀더(placeholder)를 포함한다. 메뉴 바는 통상적으로 윈도우의 최상단부에 배치되는 특정 영역으로서, 사용자가 일련의 명령들 중에서 선택할 수 있게 한다. 제3 루트 노드는 윈도우 내용 자체를 기술하는 자식 노드들을 포함한다. 보다 효율적인 프로세스를 창출하기 위해서는, 윈도우 내용의 디폴트 구성을 특성 트리에 제공하여야 한다. OO 클래스 계층 트리는 목표로 하는 객체 지향 소프트웨어 개발 환경의 클래스 계층을 기술한다. 이 특성 트리는 구식 언어 문법 트리와 실질적으로 유사하게 생성된다. 모든 OO 모델 소프트웨어 개발 환경은 "시스템" 또는 기 구성된 클래스 계층(built-class hierarchy)을 갖는다. 이 클래스 계층은 개발 환경을 구성하는 파운데이션 클래스 오브젝트를 정의한다. OO 클래스 계층 트리는 그 계층 내에서 각각의 클래스의 각각의 속성을 기술하는 특성 트리를 구현함으로써 생성된다.

도 5를 참조하면, 전환 2(160)는 구식 양식을 표현하는 저장소로부터 메타 컴포넌트를 검색한다 (단계 S350). 구식 양식을 대체하는 그래픽 인터페이스 양식을 표현하는 새로운 특성 트리가 생성된다 (단계 S352). 이는, 먼저 그래픽 인터페이스 양식 템플릿을 복사함으로써 이루어진다. 전환 2(160)는 메타 컴포넌트를 검사하고 (단계 S354), 검사된 코드가 지정된 데이터 엔트리 필드가 아니면 (아니오, 단계 S356), 구식 문자 양식의 각각의 아이템(필드, 트림 등)에 대하여, 전환 2(160)는 그 그래픽 양식으로서 어떤 대체 오브젝트를 배치할 것인지를 결정한다 (단계 S358). 상기 결정이 행하여지면, 프로세스는 OO 클래스 계층 트리에서 오브젝트 클래스를 살펴보고, 루트 노드까지 트리 전체를 순회하면서 그 경로를 따라 특성을 수집함으로써 모든 특성을 수집할 수 있다 (단계 S360). 다음으로, 필드 노드를 추상 구문 트리의 양식 섹션에 생성하고, 상기 노드에서는 복사된 특성들이 구식 양식으로부터 판독된 값들로 대체될 디폴트 값으로 정의된다 (단계 S362). 구식 양식의 모든 아이템들이 처리되면, 남은 것은 그래픽 인터페이스를 완전하게 기술하는 것이다.

2가지의 다른 프로세스가 그래픽 인터페이스의 생성 시에 구현될 수 있다. 먼저, 구식 양식에서 지정된 데이터 엔트리 필드가 있으면 (예, 단계 S356), 양식의 처리는 중지되고 (단계 S364), 그 양식에 관련된 소스 코드를 대체할 오브젝트 클래스의 메타 컴포넌트가 검색되며, 그 필드의 정의와 부합되는 속성을 해당 오브젝트에 부가한다 (단계 S366). 이는, 여러 구식 소프트웨어 개발 환경에서 양식 상의 필드들이 양식의 소스 코드에서 함축적으로 선언된 변수이기 때문에 수행되는 것이다. OO 모델에서는, 이들이 오브젝트의 속성으로 선언된다. 다음으로, 구식 양식의 처리 후에는, 양식의 소스 코드에 대해 전환 1(158)에서 생성된 추상 구문 트리를 검사한다. 특히, 구식 소스에서 구한 사용자 명령을 찾는다. 만일 사용자명령을 찾은 경우에는, 여러 GUI 제어(버튼, 툴바 아이콘, 또는 메뉴 바 명령) 중 임의의 하나를 GUI 스타일 위저드로부터의 입력에 기초하여 그래픽 유저 인터페이스 특성 트리 상에 생성할 수 있다. 그 다음, 하나 이상의 "이벤트(event)"가 구식 양식에 대해 새로운 코드 로직을 표현하는 추상 구문 트리에 부가된다. 이와 같이 부가된 "이벤트"는, 새로운 GUI 양식 제어를, 구식 애플리케이션의 메뉴 명령과 연관되는 로직의 전환된 표현인 오브젝트 클래스에서 생성된 메소드와 연관된다.

전환 3

전환 3(162)에 있어서는, 각각의 구식 소스 코드 컴포넌트의 추상 구문 트리가 저장소로부터 검색된다. 또한, 대응하는 오브젝트 메타 컴포넌트도 검색된다. 추상 구문 트리의 모든 루틴 노드의 경우, 오브젝트 메타 컴포넌트에 "메소드(method)" 노드를 생성한다. 메소드는 오브젝트에 따라 실행될 수 있는 오브젝트의 소스 코드이다. 전환 3(162)는 우선 루틴의 임의의 파라미터들를 취하고, 이들을 메소드의 파라미터로서 선언한다.

지역 변수에 대해서도 마찬가지로 행한다. 다음으로, 문장들을 처리한다. 구식 문장 타입 각각에 따라, 전환 3(162)는 문장들을 변환하는 방법과, 변환된 문장들을 어디에 둘지를 결정한다. 많은 경우, 이 엔진은 루틴 전체 또는 그 일부를 완전히 다른 오브젝트로 전부 이동시키도록 결정할 수 있다. 이는 구식 소프트웨어 개발 언어의 특징이 새로운 소프트웨어 개발 환경으로 쉽게 번역되지 않는 경우에 발생한다.

전환 3(162)의 또 다른 부분은 구식 소프트웨어 애플리케이션의 절차적 컨텍스트(context)를 오브젝트 컨텍스트로 전환시키는 것이다. 이는 2가지 특성을 갖는다. 첫번째는, 절차적 환경에서, 한 컴포넌트는 다른 컴포넌트를 "호출"함으로써 그 컴포넌트를 불러낸다(invoke). OO 모델에서는, 프로시저를 호출하기 보다는, 오브젝트의 인스턴스(또는 복사본)를 생성하여, 그의 메소드들 중 하나를 불러낸다. 전환 3(162)가 어떤 종류의 구식 호출 문장과 직면할 때마다, 처리를 중지하고, 호출된 오브젝트를 정의하는 오브젝트 메타 컴포넌트를 검색하며, 그 파라미터를 해당 호출에 대해 검증한다. 어떤 경우에는, 오브젝트가 조정을 필요로 할 수 있다. 그러면, 호출하는 컴포넌트에서는, 호출 문장을 여러 다른 문장으로 대체한다. 제1 문장은 오브젝트 요청 매개자(Object Request Broker : ORB)이다. ORB는 요청에 기초하여 다른 오브젝트의 생성을 관리하는 작업을 하는 특수 오브젝트이다. 부가되는 후속의 문장은 전환된 컴포넌트 전부에 공통인 특수 메소드를 호출하여 처리될 오브젝트를 "불러오거나(invoke)" 개시한다.

절차적 컨텍스트로부터 오브젝트 컨텍스트로부터의 전환의 제2 특징은 절차적 소프트웨어 개발 툴과 OO 소프트웨어 개발 툴 간의 구문상의 차이이다. 문장의 처리 중에, 각각의 토큰은, 클래스의 속성으로 변환된 것에 참조가 있는지의 여부를 알아보도록 체크된다. 참조가 있는 경우에는, 적절한 변수가 참조되도록 소스에 적절한 변경을 행한다.

전환 4

전환 4(164)는 본 실시예에서의 전환 처리이다. 전환 4는 남아 있을 수 있는 각종의 사소한 문제들을 해소하는 것이지만, 전환 3(162)에서 수행된 프로세싱 전부와 병렬로 처리되지 않을 수 있다.

재생 프로세스

재생 프로세스(166)는 마이닝 프로세스(140)의 역이다. 재생 프로세스(166)에서는, 전환 프로세스(156) 시에 생성된 오브젝트 메타 컴포넌트가, 새로운 소프트웨어 개발 환경에 배치할 실제의 오브젝트 클래스를 생성하는 데 사용된다. 또한, 새로운 그래픽 인터페이스 양식과 그 외 다른 임의의 필요한 컴포넌트가 생성되어, 새로운 소프트웨어 개발 환경에 배치된다.

확장

확장 단계(168)는 마이닝 프로세스(140) 시에 실행되는 확장 위저드에 의해 특정되는 파운데이션 클래스 라이브러리, 비즈니스 오브젝트 라이브러리, 프론트 엔드 라이브러리를 새롭게 구축한다.

재생

재생 단계(170)에서는, 실제 오브젝트 클래스와 GUI 양식이 이들을 포함하는 사양에 따라 오브젝트 메타 컴포넌트로부터 생성된다.

상술한 원리의 관점에서 본 발명에 대한 수많은 추가의 변형 및 변경이 가능하다. 그러므로, 이후의 특허청구범위의 범주 내에서 본 발명이 상술한 실시예들 이외의 다른 실시가 가능하다는 것을 이해하여야 한다.

Claims

절차적 언어 코드(procedural language code)를 갖는 절차적 프로그램을 객체 지향형 프로그램(object-oriented program)으로 전환(transforming)하는 방법에 있어서,

상기 절차적 언어 코드를 검사(scanning)하고, 상기 검사된 절차적 언어 코드에 기초하여 맵(map)을 생성하는 단계;

상기 검사된 절차적 언어 코드를 중간 코드(intermediate code)로서 저장하는 단계;

상기 맵을 이용하여 상기 절차적 언어 코드 중 적어도 한 세그먼트(segment)를 처리하는 단계;

상기 처리된 세그먼트를 이용하여 제1 데이터 구조(data structure)를 생성하는 단계;

상기 제1 데이터 구조에 기초하여 상기 중간 코드를 변경하는 단계; 및

상기 변경된 중간 코드에 기초하여 오브젝트 클래스(object class)를 갖는 객체 지향형 프로그램을 생성하는 단계

를 포함하는 방법.
제1항에 있어서,

상기 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 상기 절차적 언어코드의 세그먼트를 처리하는 상기 단계를 중지하는 단계; 및

상기 소정의 세그먼트에 기초하여 다른 중간 코드를 변경하는 단계

를 더 포함하는 방법.
제1항에 있어서,

상기 절차적 언어에 기초하여 제2 데이터 구조를 생성하는 단계

를 더 포함하고,

상기 제2 데이터 구조는 절차적 프로그래밍 언어의 문장(statement)의 특성(property)을 식별하는 노드(node)를 갖는 계층 트리(hierarchical tree)인 방법.
제3항에 있어서,

상기 제1 데이터 구조를 생성하는 상기 단계는,

상기 처리된 세그먼트에 기초하여 상기 제2 데이터 구조에서 노드의 위치를 정하는 단계,

상기 제2 데이터 구조의 노드들을 루트 노드까지 순회(traversing)하는 단계, 및

상기 순회한 노드들의 내용을 제1 데이터 구조에 포함시키는 단계

를 포함하는 방법.
절차적 언어 코드를 갖는 절차적 프로그램을 객체 지향형 프로그램으로 전환하는 컴퓨터 실행 가능 코드를 포함하는 저장 매체에 있어서,

상기 절차적 언어 코드를 검사하고, 상기 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 코드;

상기 검사된 절차적 언어 코드를 중간 코드로서 저장하는 코드;

상기 맵을 이용하여 상기 절차적 언어 코드 중 적어도 한 세그먼트를 처리하는 코드;

상기 처리된 세그먼트를 이용하여 제1 데이터 구조를 생성하는 코드;

상기 제1 데이터 구조에 기초하여 상기 중간 코드를 변경하는 코드; 및

상기 변경된 중간 코드에 기초하여 오브젝트 클래스를 갖는 객체 지향형 프로그램을 생성하는 코드

를 포함하는 저장 매체.
제5항에 있어서,

상기 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 상기 절차적 언어 코드의 세그먼트의 처리를 중지하는 코드; 및

상기 소정의 세그먼트에 기초하여 다른 중간 코드를 변경하는 코드

를 더 포함하는 저장 매체.
제5항에 있어서,

상기 절차적 언어에 기초하여 제2 데이터 구조를 생성하는 코드

를 더 포함하며,

상기 제2 데이터 구조는 절차적 프로그래밍 언어의 문장의 특성을 식별하는 노드를 갖는 계층 트리인 저장 매체.
제7항에 있어서,

상기 제1 데이터 구조를 생성하는 상기 코드는,

상기 처리된 세그먼트에 기초하여 상기 제2 데이터 구조에서 노드의 위치를 정하는 코드,

상기 제2 데이터 구조의 노드들을 루트 노드까지 순환하는 코드, 및

상기 순환한 노드들의 내용을 상기 제1 데이터 구조에 포함시키는 코드

를 포함하는 저장 매체.
절차적 언어 코드를 갖는 절차적 프로그램을 객체 지향형 프로그램으로 전환하기 위한 컴퓨터 실행 가능 명령어들을 포함하며, 전송 매체에서 구체화되는 컴퓨터 데이터 신호에 있어서,

상기 절차적 언어 코드를 검사하고, 상기 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 데이터 신호 부분;

상기 검사된 절차적 언어 코드를 중간 코드로서 저장하는 데이터 신호 부분;

상기 맵을 이용하여 상기 절차적 언어 코드 중 적어도 한 세그먼트를 처리하는 데이터 신호 부분;

상기 처리된 세그먼트를 이용하여 제1 데이터 구조를 생성하는 데이터 신호 부분;

상기 제1 데이터 구조에 기초하여 상기 중간 코드를 변경하는 데이터 신호 부분; 및

상기 변경된 중간 코드에 기초하여 오브젝트 클래스를 갖는 객체 지향형 프로그램을 생성하는 데이터 신호 부분

을 포함하는 컴퓨터 데이터 신호.
제9항에 있어서,

상기 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 상기 절차적 언어 코드의 세그먼트의 처리를 중지하는 데이터 신호 부분; 및

상기 소정의 세그먼트에 기초하여 다른 중간 코드를 변경하는 데이터 신호 부분

을 더 포함하는 컴퓨터 데이터 신호.
제9항에 있어서,

상기 절차적 언어에 기초하여 제2 데이터 구조를 생성하는 데이터 신호 부분

을 더 포함하며,

상기 제2 데이터 구조는 절차적 프로그래밍 언어의 문장의 특성을 식별하는노드를 갖는 계층 트리인 컴퓨터 데이터 신호.
제11항에 있어서,

상기 제1 데이터 구조를 생성하는 상기 데이터 신호 부분은,

상기 처리된 세그먼트에 기초하여 상기 제2 데이터 구조에서 노드의 위치를 정하는 데이터 신호 부분,

상기 제2 데이터 구조의 노드들을 루트 노드까지 순회하는 데이터 신호 부분, 및

상기 순회한 노드들의 내용을 제1 데이터 구조에 포함시키는 데이터 신호 부분

을 포함하는 컴퓨터 데이터 신호.
절차적 언어 코드를 갖는 절차적 프로그램을 객체 지향형 프로그램으로 전환하는 방법에 있어서,

상기 절차적 언어 코드를 검사하고, 상기 검사된 절차적 언어 코드에 기초하여 맵을 생성하는 단계;

상기 맵 및 상기 검사된 절차적 언어 코드를 메타데이터(metadata)로서 저장소(repository)에 저장하는 단계;

각각의 컴포넌트(component)의 전환된 표현(transforemd representation)에 대해 타겟 메타데이터 컨테이너(taget metadata container)의 새로운 셋트를 생성하는 단계;

절차적인 메타데이터 표현을 이용하여 상기 절차적 언어 코드 중 적어도 한 세그먼트를 처리하고, 상기 처리된 세그먼트를 이용하여 제1 추상 구문(abstract syntax) 트리를 생성하는 단계;

상기 제1 추상 구문 트리에 기초하여 상기 타겟 메타데이터 컨테이너를 위치시키는 단계; 및

상기 제1 추상 구문 트리에 기초하여, 오브젝트 클래스를 갖는, 원래의 절차적 프로그램의 객체 지향형 메타데이터 표현을 생성하는 단계

를 포함하는 방법.
제13항에 있어서,

상기 절차적 언어 코드 중 소정의 세그먼트가 검출되면, 상기 절차적 언어 코드의 세그먼트를 처리하는 상기 단계를 중지하는 단계; 및

상기 소정의 세그먼트에 기초하여 또 다른 추상 구문 트리를 변경하는 단계

를 더 포함하는 방법.
제13항에 있어서,

상기 절차적 언어에 기초하여 제2 추상 구문 트리를 생성하는 단계

를 더 포함하며,

상기 제2 추상 구문 트리는 절차적 프로그래밍 언어의 문장의 특성을 식별하는 노드를 갖는 추상 구문 트리인 방법.
제15항에 있어서,

상기 제1 추상 구문 트리를 생성하는 상기 단계는,

상기 처리된 세그먼트에 기초하여 상기 제2 추상 구문 트리에서 노드의 위치를 정하는 단계,

상기 제2 추상 구문 트리의 노드들을 루트 노드까지 순회하는 단계, 및

상기 순회한 노드들의 내용을 상기 제1 추상 구문 트리에 포함시키는 단계

를 포함하는 방법.