KR100772181B1 - 확장성 생성 언어 스키마 기반 개발도구 연동 방법 및시스템 - Google Patents

Abstract

본 발명은 확장성 생성 언어(Extensible Markup Language: XML) 스키마(Schema)를 이용하여 설계한 확장성 생성 언어 저장소(XML Repository)를 이용한 통합개발도구에서 제공하는 개발도구들을 연동하는 방법 및 시스템에 관한 것으로서, 통합개발도구에서 기존 플러그인 프로그램과 새로운 추가된 플러그인 프로그램간의 연동을 위해, 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 방법에 있어서, 기존의 플러그인 프로그램을 이용하여 작성한 정보들을 저장하는 단계, 상기 저장된 정보를 XML 시키마를 이용하여 XML 데이터 형식으로 변환하는 단계, 및 상기 XML 데이터 형식으로 변환된 정보를 추가된 상기 플러그인 프로그램에 활용하는 단계를 포함하는 플러그인 프로그램 활용 방법 및 시스템을 개시한다.

통합개발도구, XML, 확장성 생성 언어, 스키마, XML 데이터, API(Application Program Interface)

Description

확장성 생성 언어 스키마 기반 개발도구 연동 방법 및 시스템{Method and System for cooperation scheme of the development tools based on Extensible Markup Language(XML) Schema}

도 1은 본 발명이 적용되는 시스템 구성도,

도 2a 내지 도 2z 및 도 3a 내지 도 3e는 본 발명에 따른 확장성 생성 언어(XML) 데이터 형식의 레코드 구조도,

도 4는 통합개발도구에서 본 발명이 적용된 확장성 생성 언어 저장소(XML Repository) 생성 및 사용에 관한 구성도.

본 발명은 확장성 생성 언어(Extensible Markup Language 이하, XML이라 칭함) 스키마(Schema)를 이용하여 설계한 XML 저장소(Repository)를 이용한 통합개발도구에서 제공하는 개발도구들을 연동하는 방법 및 시스템에 관한 것으로서, 보다 상세하게는, 통합개발도구에서 기존 플러그인 프로그램과 추가된 플러그인 프로그 램간의 연동 방법 및 시스템에 관한 것이다.

마크업 언어(Markup language)들은 최근 수년 동안 폭 넓은 인기를 얻어왔다. 마크업 언어의 한 유형인 확장성 생성 언어(Extensible Markup Language 이하, XML이라 칭함)는 다양한 종류의 데이터를 식별, 교환 및 처리하는 방법을 제공하는 보편적인 언어이다. 예를 들어, XML은 여러 종류의 응용 프로그램에 의해 이용될 수 있는 문서들의 생성을 위해 사용된다. XML 파일들의 요소들은 연관된 네임스페이스(name space) 및 스키마(schema)를 갖는다.

XML에서 네임스페이스는 XML 문서의 각 클래스(class)를 유일하게 식별하는데 일반적으로 사용된다. 각 XML 문서는 문서와 관련된 XML의 유형을 용이하게 식별하기 위한 프로세스들을 허용하는 네임스페이스를 사용할 수 있다. 유일한 네임스페이스는 서로 다른 소스들로부터의 마크업 요소들 및 우연히 같은 이름을 갖는 마크업 요소들을 구별하는데 도움을 줄 수 있다.

XML 스키마는 XML 환경 하에서 데이터를 설명하고 검증하는 방법을 제공한다. 스키마는 XML 문서에 있어서 어떤 요소 및 속성이 각 요소들이 어느 위치에 허용되며, 어느 요소가 다른 요소 내에 나타내어지는 지와 같은 내용을 설명하는 데에 사용되는 지를 나타낸다. 스카마의 사용은 파일이 일관된 방법으로 구성됨을 확신케한다. 스키마는 사용자에 의해 생성되며, XML과 같은 연관된 마크업 언어에 의해 일반적으로 지원된다. 스키마를 지원하는 XML 편집기를 사용함으로써, 사용자는 사용자가 생성한 스키마가 부착된 XML 문서를 만들 수 있으며, XML 데이터를 처리할 수 있다.

기존 플러그인 프로그램을 이용하여 통합개발도구에서 사용자가 작성한 프로그램에 대한 정보는 XML 스키마로 정의한 XML 데이터 형식으로 저장한다. 상술한 바와 같이 XML은 현재 산업계 표준으로 많이 사용되고 있으며 XML 관련 기술들이 많이 개발되어 있다.

통합개발도구는 기능이 다양한 소프트웨어 개발 통합 환경을 제공하고, 이를 기반으로 향후 새로운 도구의 개발을 촉진하기 위하여 데이터 개방형 구조를 지원하는 기술이다. 도구들을 통합하는데 필요한 데이터 통합 기술은 도구들 간에 공통으로 사용되는 데이터의 스키마를 정의하고 공유한다. 이와 같이 함으로서 서로 다른 도구들이 데이터를 공유하고, 그래픽 사용자 인터페이스 통합이나 프로시저 통합을 넘어서 유기적인 통합을 이룰 수 있다. 또한 공통 데이터를 활용하거나 확장, 변환하는 새로운 도구의 개발을 촉진할 수 있다.

이하, 먼저 플러그인 프로그램에 대해 알아본 후 플러그인 프로그램을 추가할 경우 발생하는 문제점에 대해 알아보기로 한다. 플러그인(plug in)의 의미는 '플러그를 꽂다'이지만, 컴퓨터 분야에서는 웹 브라우저의 일부로서 쉽게 설치되고 사용될 수 있는 프로그램을 말한다. 플러그인 프로그램은 독립적으로는 실행되지 못하고 반드시 브라우저와 함께 동작한다는 특성을 갖는다. 넷스케이프 브라우저를 통해 사운드나 동영상을 재생하거나, 다른 기능들을 수행해 주는 추가 프로그램들을 다운로드하여 설치하고, 또 정의할 수 있도록 한 것이 시초가 되었다. 이러한 프로그램을 처음에는 헬퍼(helper) 응용 프로그램이라고 불렀는데, 브라우저와는 별개로 실행되었으며 이를 위해 새로운 창을 여는 것이 필요했다.

이에 비해 플러그인 프로그램은 브라우저에 의해 자동으로 인식된다. 마치 웹 브라우저에서 직접 실행하는 것과 같은 효과를 제공하기 때문에 매우 편리하다. 멀티미디어를 웹에서 구현하는 데에 유용하게 쓰인다. 플러그인 프로그램의 종류는 수백 가지에 이르며 대부분 무료로 이용할 수 있다. 인터넷의 특정 사이트나 PC 통신의 공개자료실에 가면 쉽게 구할 수 있다. 애니메이션, 동영상, 음향, 그래픽, 문서 등의 자료파일을 사용자의 컴퓨터에 다운로드하지 않고도 실행할 수 있는데, 많이 알려진 플러그인 프로그램으로는 리얼플레이어, 미디어플레이어, 스트림웍스, 비보 액티브, VDO 라이브, 쇼크웨이브, 아크로벳 등이 있다.

통상적으로 통합개발도구에서 새롭게 플러그인 프로그램을 추가할 때, 기존에 추가한 플러그인 프로그램을 이용할 수 있는 한계가 있다. 즉, 통합개발도구에서 새로운 기능이 필요하여 새로운 플러그인 프로그램을 추가할 때 기존 통합개발도구에서 제공하는 기능을 이용하여 기작성한 사용자 프로그램에 대한 유용한 정보들을 활용하지 못하고 사용자 프로그램에 대한 정보들을 추출할 수 있는 기능을 중복해서 개발해야 하는 어려움이 있다.

상술한 바와 같은 문제점을 해결하기 위한 본 발명의 목적은, 플러그인 프로그램을 지원하는 통합개발도구에서 새로운 플러그인 프로그램을 추가할 때 기존에 개발된 플러그인 프로그램에서 작성한 정보들을 활용할 수 있는 플러그인 프로그램 활용 시스템 및 방법을 제공함에 있다.

본 발명의 다른 목적은 기존에 개발된 플러그인 프로그램에서 작성한 정보들을 활용함으로써, 효율적으로 개발 도구를 연동할 수 있는 플러그인 프로그램 활용 시스템 및 방법을 제공함에 있다.

본 발명의 또 다른 목적은 기존에 개발된 플러그인 프로그램에서 작성한 정보들을 새로 추가된 플러그인 프로그램에서 활용함으로써, 새로운 정보를 작성하는데 소요되는 시간을 단축시킬 수 있는 플러그인 프로그램 활용 시스템 및 방법을 제공함에 있다.

상기와 같은 목적은 본 발명의 실시예에 따라, 플러그인 프로그램을 이용하여 생성한 통합개발도구를 추가된 플러그인 프로그램에서 활용하기 위한 플러그인 프로그램 활용 시스템으로서, 저장된 확장성 생성 언어(Extensible Markup Language: XML) 데이터를 독출하고, 상기 독출한 XML 데이터를 전달하는 XML 데이터 입출력 모듈; 상기 XML 데이터 입출력 모듈로부터 상기 독출된 XML 데이터를 수신하고, 추가된 상기 플러그인 프로그램에 대한 접근 권한 여부를 판단하고, 상기 판단 결과 접근 권한이 없으면 상기 플로그인 프로그램의 접근을 차단하는 응용 프로그램 인터페이스(API); 및 상기 API로부터 전달받은 XML 데이터를 파싱하여 XML 레코드로 변환하는 XML 파서를 포함함을 특징으로 한다.

또한, 상기와 같은 목적은 본 발명의 실시예에 따라, 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 시스템에 있어서, 기존의 플러그인 프로그램을 이용하여 작성한 정보들을 저장하고 있는 상기 통합개발도구와, 상기 통합개발도구에 저장된 정보를 XML 시키 마를 이용하여 XML 데이터 형식으로 변환하며, 상기 XML 데이터 형식으로 변환된 정보를 추가된 상기 플러그인 프로그램에 활용하는 XML 리포지터리를 포함하는 것을 특징으로 한다.

한편, 상기와 같은 목적은 본 발명의 실시예에 따라, 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 방법에 있어서, 기존의 플러그인 프로그램을 이용하여 작성한 정보들을 저장하는 단계와, 상기 저장된 정보를 XML 시키마를 이용하여 XML 데이터 형식으로 변환하는 단계와, 상기 XML 데이터 형식으로 변환된 정보를 추가된 상기 플러그인 프로그램에 활용하는 단계를 포함하는 것을 특징으로 한다.

또한, 상기와 같은 목적은 본 발명의 실시예에 따라, 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 방법에 있어서, 기존의 플러그인 프로그램을 이용하여 작성한 정보들을 XML 시키마를 이용하여 XML 데이터 형식으로 변환하는 단계와, 상기 XML 데이터 형식으로 변환된 정보를 다양한 속성을 갖는 XML 레코드로 변환하는 단계와, 상기 변환된 XML 레코드를 추가된 상기 플러그인 프로그램에 활용하는 단계를 포함하는 것을 특징으로 한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예에 대한 동작 원리를 상세하게 설명한다. 하기에서 본 발명을 설명함에 있어 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술 되는 용어들은 본 발명의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운영자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서의 전반에 걸친 내용을 토대로 내려져야 할 것이다.

도 1은 본 발명에 따른 통합개발도구를 기반으로 플러그인 프로그램을 지원하는 XML 리포지터리(Repository)를 포함하는 블록 구성도이다. 이하, 도 1을 이용하여본 발명의 일 실시 예에 따른 통합개발도구를 기반으로 플러그인 프로그램을 지원하는 XML 리포지터리에 대해 상세하게 알아보기로 한다.

상기 도 1을 참조하면, 블록 구성도는 통합개발도구(200)를 기반으로 플러그인 형식으로 연결된 새로운 플러그인 프로그램B(120)와 통합개발도구(200)에 이미 연결되어 있던 플러그인 프로그램A(100) 및 플러그인 프로그램A(100)와 플러그인 프로그램B(120)를 연결하는 XML 리포지터리(110)를 도시하고 있다. 또한, 통합개발도구(200)는 편집기(210), 컴파일러(202), 디버거(203)를 포함한다.

그리고 상기 도 1을 참조하면, 새로 통합개발도구에 추가할 플러그인 프로그램B(120)는 XML 리포지터리(110)를 이용하여 기존에 작성한 사용자 프로그램에 대한 정보를 활용할 수 있다. 즉, 플러그인 프로그램B(120)는 통합개발도구에 있는 플러그인 프로그램A(100)에 의해 XML 리포지터리(110)에 저장한 사용자 프로그램에 대한 정보를 활용하여 저렴한 개발 비용으로 더 발전된 기능을 통합개발도구에 추가할 수 있다.

XML 리포지터리(110)는 XML 스키마(121)와 XML 데이터(122), 그리고 XML 데이터(122)를 처리하는 XML 파서(123)를 기반으로 구성되며, 자바 응용 프로그램 인 터페이스(JABA API)(112), C/C++ 응용 프로그램 인터페이스(API)(111), XML 레코드 XML 데이터 입출력(I/O) 모듈(113)을 포함한다. XML 파서(123)는 XML 스키마(121)의 내용을 참조하여 XML 데이터(122)의 내용과 형식을 검증하여 작성된 XML 데이터를 처리할 수 있도록 지원한다. XML 데이터 I/O 모듈(113)은 물리적으로 저장된 XML 파일을 읽어서 사용자에게 제공하거나 사용자로부터 주어진 정보를 XML 형태로 파일에 저장하는 기능을 담당한다. XML 스키마는 XML 파일의 구조를 설명하는 메타데이터로서 스키마를 바탕으로 XML 파일에 대한 입/출력을 수행한다. 또한, 스키마를 변경하거나 확장함으로써 데이터 정보 저장소를 변경하거나 확장할 수 있다.

공통 데이터 저장소에 대한 응용 프로그램 인터페이스(Application Program Interfaces 이하, API라 칭함) 역할을 하는 JAVA API(112), C/C++ API(111)는 공통 데이터에 접근할 경우 반드시 거쳐야 하는 데이터이다. 즉, 공통 데이터에 접근하기 위해서는 반드시 JAVA API(112), C/C++ API(111)을 거쳐야 한다. 즉, JAVA API(112), C/C++ API(111)는 공통 데이터를 생성하고, 읽고, 쓰고, 지우는 기능을 제공하고 정보에 대한 접근 권한을 검사해서 권한이 없는 경우에 접근을 차단한다.

도 2a 내지 도 2z 및 도 3a 내지 도 3e는 본 발명에 따른 XML 리포지터리에서 다루는 XML 데이터의 형식을 정의하는 XML 스키마 내용을 도식화한 것이다. 이하, 도 2a 내지 도 2z 및 도 3a 내지 도 3e를 참조하면, XML 리포지터리에서 다루는 XML 데이터의 형식을 정의하는 XML 스키마 내용에 대해 상세하게 알아보기로 한다. 즉, XML 데이터를 이용하여 XML 파서에서 생성하는 XML 리코드의 다양한 구조를 도시하고 있다.

상기 도 2a는 복수 개의 엔트리(Entry) 레코드를 저장하기 위해 XML 스키마를 이용하여 엔트리 엘리먼트를 정의한 내용을 도시하고 있다. 여기서 엔트리 엘리먼트는 대표 엔트리 포인트가 존재하는 테이블들에 대한 정보를 저장하기 위해 table_id, entry_name, entry_rid로 구성된 세 가지 속성(attribute)을 정의한다. table_id는 테이블 아이디를 의미하며, entry_name은 엔트리 이름을 의미하며, entry_rid는 테이블의 해당 엔트리 포인트를 의미한다.

상기 도 2b는 프로젝트에 대한 정보를 저장하기 위해 PrjInfo 엘리먼트를 정의한 내용을 도시하고 있다. 여기서 PrjInfo 엘리먼트는 프로젝트에 대한 전반적인 정보를 저장하기 위해 language, name, working_dir, src_top_dir, phase, progress, version, is_clone, org_path, clone_path, regression_path, is_regression로 구성된 속성을 정의한다. Language는 프로그램의 사용 언어를 의미하며, name은 프로젝트의 이름을 의미하며, working_dir는 작업 디렉토리를 의미한다. 또한, src_top_dir는 소스 프로그램의 top 디렉토리를 의미하며, phase는 단계를 의미하며, progress는 작업 도중 정지된 시점의 progress 값을 의미한다. version은 버전을 의미하며, is_clone 클론 프로젝트에 대한 설정값을 의미하며, org_path는 클론 프로젝트인 경우 원본 프로젝트의 경로값을 의미하며, clone_path는 원본 프로젝트인 경우 클론 프로젝트의 경로값을 의미한다. regression_path는 원본 프로젝트인 경우 regression된 프로젝트의 경로값을 의미하며, is_regression은 regression 프로젝트에 대한 설정값을 의미한다.

상기 도 2c는 사용자 소스 프로그램에 대한 설정 정보를 저장하기 위해 SrcConfig 엘리먼트를 정의한 내용을 도시하고 있다. 여기서 SrcConfig 엘리먼트는 소스 프로그램에 대한 설정 정보를 저장하기 위해 link_flag, compile_flag, include_list, Libraries, test_scope, packages, test_target, include_main, src_compile_info로 구성된 속성을 정의한다. Link_flag는 링크 정보를 의미하며, compile_flag는 공통 컴파일 플래그를 의미하며, include_list는 C/C++프로젝트 경우 공통 Include 디렉토리 경로를 의미한다. Libraries는 라이브러리 목록을 의미하며, test_scope는 테스트 범위에 대한 설정을 의미하며, packages는 Java 패키지들의 목록을 의미한다. test_target은 NULL이면 함수 테스팅을 의미하며, 아닌 경우는 클래스 이름을 의미한다. include_main는 main 함수의 API 포함 여부를 의미하며, src_compile_info는 소스 파일 목록을 의미한다.

상기 도 2d는 사용자 소스 프로그램에 대한 개략적인 정보를 저장하기 위해 SrcInfo 엘리먼트를 정의한 내용을 도시하고 있다. SrcInfo 엘리먼트는 소스 프로그램에 대한 개략적인 정보를 저장하기 위해 src_file, compile_flag, include_list, include_src_list, flag로 구성된 속성을 정의한다. src_file은 파일 이름에 대한 절대 경로를 의미하며, compile_flag는 컴파일 옵션을 의미하며, include_list는 include 목록을 의미한다. include_src_list는 소스 파일에 포함되어 있는 include 목록을 의미하며, flag는 소스 프로그램 분석에 대한 상태값을 의미한다.

상기 도 2e는 include 파일들에 대한 정보를 저장하기 위해 IncludeSrc 엘리먼트를 정의한 내용을 도시하고 있다. 여기서 IncludeSrc 엘리먼트는 프로그램 시 필요한 include 파일들에 대한 정보를 저장하기 위해 file, lines, included로 구성된 속성을 정의한다. File은 include 파일의 절대 경로를 의미하며, lines는 프로그램 내 줄 정보 목록을 의미하며, included는 include 목록을 의미한다.

상기 도 2f는 시스템별 기본 자료형의 파티션(Partition) 정보를 저장하기 위해 SyswidePtt 엘리먼트를 정의한 내용을 도시하고 있다. SyswidePtt 엘리먼트는 시스템별 기본 자료형의 파티션을 저장하기 위해 type_name, Kind, ptt, next로 구성된 속성을 정의한다. type_name 타입 이름을 의미하며, Kind는 종류를 의미한다. ptt는 파티션 정보를 의미하며, next는 다음 SysedirPtt 레코드를 가리기는 포인터를 의미한다.

상기 도 2g는 시스템 환경변수에 대한 정보를 저장하기 위해 key, kind, ivalue, fvalue, svalue, flag, next로 구성된 속성을 정의한다.

상기 도 2h는 Scope 엘리먼트를 정의한 내용을 도시하고 있다. Scope 엘리먼트는 프로그램 스코프에 대한 정보를 저장하기 위해 global_seq, kind, name, file_name, defining, using, aliasing, friend, defined, used, aliased, granting_friendship, entity, dependent_type, cv_list로 구성된 속성을 정의한다. global_seq는 해당 scope의 번호를 의미하며, kind는 scope 종류를 의미하며, name은 scope 이름을 의미한다. file_name은 scope가 클래스나 함수일 경우, scope가 정의된 파일 이름을 의미하며, defining은 scope에서 정의하는 scope, type, var의 벡터를 의미하며, using은 scope에서 using declaration이나 using directive에 의해 사용하는 scope, type, var의 벡터를 의미한다. aliasing은 scope에서 alias하는 scope의 벡터를 의미하며, friend는 scope에서 friend로 선언되는 함수의 scope의 벡터를 의미하며, defined는 scope가 정의되는 scope를 의미하며, used는 scope가 using declaration이나 using directive에 의해 사용되는 scope의 벡터를 의미한다. aliased는 scope가 alias되는 scope의 벡터를 의미하며, granting_friendship는 scope가 freindship을 받는 scope의 벡터를 의미하며, entity는 kind가 클래스, 함수인 경우 해당 entity를 의미하며, dependent_type는 Kind가 temporary인 경우 scope가 dependent한 template param type을 의미한다. cv_list는 해당 scope에 대한 cv_type들의 벡터를 의미하며, next는 다음 scope에 대한 포인터를 의미한다.

상기 도 2i는 프로그램 내 Alias 정보를 저장하기 위해 Alias 엘리먼트를 정의한 내용을 도시하고 있다. Alias 엘리먼트는 이를 위해 global_seq, name, aliasing, aliased로 구성된 속성을 정의한다. global_seq는 해당 scope의 번호를 의미하며, name은 이름을 의미하며, aliasing은 name에 저장된 이름을 aliasing하는 scope를 의미하며, aliased는 name에 저장된 이름이 alias되는 scope를 의미한다.

상기 도 2j는 함수에 대한 정보를 저장하기 위해 Function 엘리먼트를 정의한 내용을 도시하고 있다. Function 엘리먼트는 func_no, type, name, qual_name, key_no, body, num_of_eh, exception_spec, num_of_ptt, modifier, flag, return, parameter, template_argument, template_param_list, self_scope, ffg, org_func, constant_list, next, previous로 구성된 속성을 정의한다. func_no는 함수 번호를 의미하며, type은 해당 함수 타입으로의 링크를 의미하며, name은 함수 이름을 의미한다. qual_name은 defined qualified 함수 이름을 의미하며, key_no는 함수의 대표번호를 의미하며, body는 함수의 body AST(Abstract Syntax Tree)를 의미한다. num_of_eh는 해당 함수의 exception hander의 개수를 의미하며, exception_spec은 exception 처리 가능한 타입의 벡터 num_of_ptt는 파티션 개수를 의미하며, return은 함수의 return 인자를 의미한다. parameter는 함수의 parameter 인자의 벡터를 의미하며, template_argument는 template function instance의 경우, instantiate 된 함수의 템플릿 argument(일반 type, or value)의 벡터를 의미하며, template_param_list는 template 함수 parameter 타입(template_param)의 벡터를 의미한다. self_scope는 해당함수의 scope를 의미하며, ffg는 해당 함수의 ffg를 의미하며, org_func은 원본 프로젝트에서 해당 함수의 function record를 의미한다. constant_list는 해당 함수에서 식별된 상수 리스트를 의미하며, next는 다음 함수에 대한 포인터를 의미하며, previous는 이전 함수에 대한 포인터를 의미한다.

상기 도 2k는 변수에 대한 정보를 저장하기 위해 Var 엘리먼트를 정의한 내용을 도시하고 있다. Var 엘리먼트는 global_seq, name, type, defined, file_name, ptt, flag, modifier, sub_variable, num_of_ptt, internal_num_of_ptt, line으로 구성된 속성을 정의한다. global_seq는 해당 scope의 번호를 의미하며, name은 변수 이름을 의미하며, type은 type 포인터를 의미한다. defined은 변수 정의된 scope를 의미하며, file_name은 변수가 정의된 파일을 의미하며, ptt는 파티션 벡터를 의미한다. sub_variable은 structure(union)타입일 경우 sub variable의 vector, num_of_ptt와 internal_num_of_ptt는 파티션 개수를 의미하며, line은 변수가 정의된 줄 정보를 의미한다.

상기 도 2l은 프로그램 내 클래스에 대한 상속 정보를 위해 Inherit 엘리먼트를 정의한 내용을 도시하고 있다. Inherit 엘리먼트는 super, modifier, sub로 구성된 속성을 정의한다. Super는 super class type에 대한 포인터를 의미하며, modifier는 위에서 언급한 함수에 대한 내용을 참조하며, sub는 sub class type에 대한 포인터를 의미한다.

상기 도 2m은 시험 데이터를 생성하는데 필요한 파티션 정보를 저장하기 위해 Partition 엘리먼트를 정의한 내용을 도시하고 있다. Partition 엘리먼트는 kind, flag, lower, upper, values로 구성된 속성을 정의한다. Kind는 파티션 종류를 의미하며, lower는 파티션이 range인 경우 lower value에 대한 포인터를 의미하며, upper는 upper value에 대한 포인터를 의미한다. values는 파티션이 value인 경우 value 값을 의미한다.

상기 도 2n은 프로그램 내 상수값을 저장하기 위해 Constant 엘리먼트를 정의한 내용을 도시하고 있다. Constant 엘리먼트는 Kind, string_value, int_value, float_value, next, previous로 구성된 속성을 정의한다. Kind는 상수의 종류를 의미하며, string_value는 상수 종류가 문자열인 경우 값을 의미하며, int_value는 상수 종류가 정수형인 경우 값을 의미한다. float_value는 상수 종류가 실수형인 경우 값을 의미하며, next는 다음 상수값에 대한 포인터를 의미하며, previous는 이전 상수값에 대한 포인터를 의미한다.

상기 도 2o는 함수에 대한 제어 흐름 그래프 내용을 저장하기 위해 FFG 엘리먼트를 정의한 내용을 도시하고 있다. FFG 엘리먼트는 func_no, func_name, file_name, callee, node, flag, function, back_edge, group, start_line, end_line, next로 구성된 속성을 정의한다. func_no는 함수 번호를 의미하며, func_name은 함수 이름을 의미하며, file_name은 소스 파일 이름을 의미한다. callee는 callee record 벡터를 의미하며, node는 ffg node 벡터를 의미하며, function은 해당 함수 레코드를 의미한다. back_edge는 해당 함수를 destination으로 갖는 Edge 레코드 목록을 의미하며, group은 해당 함수를 destination으로 갖는 constant 레코드 목록을 의미하며, start_line, end_line은 줄 번호 정보를 의미한다. next는 다음 함수 제어 흐름 그래프에 대한 포인터를 의미하며, previous는 이전 함수제어흐름 그래프에 대한 포인터를 의미한다.

상기 도 2p는 제어 흐름 그래프의 각 노드에 대한 정보를 저장하기 위해 FFGNode 엘리먼트를 정의한 내용을 도시하고 있다. FFGNode 엘리먼트는 node_no, node_name, outgoing, fanout, start_line, end_line, coverage_count, end_type으로 구성된 속성을 정의한다. node_no는 Node 번호를 의미하며, node_name는 Node의 이름을 의미하며, outgoing은 internal edge의 벡터를 의미한다. fanout은 external edge의 벡터를 의미하며, start_line은 소스 코드의 시작라인을 의미하며, end_line은 소스 코드의 끝 라인을 의미한다. coverage_count는 Node coverage의 횟수를 의미하며, end_type은 함수의 ending type을 의미한다.

상기 도 2q는 제어 흐름 그래프의 각 Edge에 대한 정보를 저장하기 위해 Edge 엘리먼트를 정의한 내용을 도시하고 있다. Edge 엘리먼트는 coverage_count, destination, back_node, flag로 구성된 속성을 정의한다. coverage_count는 edge coverage count를 의미하며, destination은 edge의 목적지를 의미하며, back_node는 해당 edge를 external edge로 가지는 노드 레코드를 의미한다.

상기 도 2r은 external Edge에 대한 정보를 저장하기 위해 EeInfo 엘리먼트를 정의한단 내용을 도시하고 있다. EeInfo 엘리먼트는 from_ffg, from_node, scope, eedge_index, file_name, to_func_name으로 구성된 속성을 정의한다. from_ffg는 external edge를 가지는 제어 흐름 그래프에 대한 포인터를 의미하며, from_node는 external edge를 가지는 Node에 대한 포인터를 의미하며, scope는 node의 scope 정보를 의미한다. eedge_index는 해당 노드에서 external edge의 index를 의미하며, file_name은 파일 이름 정보를 의미하며, to_func_name은 external edge의 target이 되는 함수들의 이름 목록을 의미한다.

상기 도 2s는 프로그램 소스 코드에 대한 시험을 진행할 때 필요한 Suite 엘리먼트를 정의한 내용을 도시하고 있다. Suite 엘리먼트는 script, stdin, next로 구성된 속성을 정의한다. script는 테스트 스크립트에 대한 포인터를 의미하며, stdin는 표준 입력 스트림을 처리함을 의미하며 , next는 다음 suite를 가리키는 포인터를 의미한다.

상기 도 2t는 테스트 수행을 위한 스크립트 정보를 처리하기 위해 Script 엘리먼트를 정의한 내용을 도시하고 있다. Script 엘리먼트는 스크립트 이름을 나타내는 name, 작업 벡터를 의미하는 task로 구성된 속성을 갖는다.

상기 도 2u는 시험 태스크 정보를 저장하기 위해 Task 엘리먼트를 정의한 내용을 도시하고 있다. Task 엘리먼트는 태스크 번호를 의미하는 task_no와 스텝의 vector를 의미하는 steps으로 구성된 속성을 갖는다.

상기 도 2v는 함수 호출을 단위로 하는 시험 수행 스텝 정보를 저장하기 위해 Step 엘리먼트를 정의한 내용을 도시하고 있다. Step 엘리먼트는 수행 객체에 대한 포인터를 가리키는 object, 호출 함수의 포인터를 저장하는 function, 반환 이름을 저장하는 return, 인자들 이름을 저장하는 variables, expected_outcome, input_data로 구성된 속성을 정의한다.

상기 도 2w는 로그 정보를 저장하기 위해 Log 엘리먼트를 정의한 내용을 도시하고 있다. Log 엘리먼트는 각 수행 테스트 결과를 저장하기 위해 result, api_block_cvrg, focus_block_cvrg, total_block_cvrg, api_branch_cvrg, focus_branch_cvrg, total_branch_cvrg, focus_function_cvrg, total_function_cvrg, total_cvrg로 구성된 속성을 정의한다.

상기 도 2x는 테스트 수행 케이스별 결과를 저장하기 위해 TestCaseLog 엘리먼트를 정의한 내용을 도시하고 있다. TestCaseLog 엘리먼트는 case_result, task_result, script, data_select, stdin, output_file, coverage, diagnosis, sequence_file로 구성된 속성을 정의한다.

상기 도 2y는 작업에 대한 로그를 기록하기 위해 TaskLog 엘리먼트를 정의한 내용을 도시하고 있다. 작업에 대한 로그를 기록하기 위해 TaskLog 엘리먼트는 case_id, task_id, result, step_result로 구성된 속성을 정의한다.

싱기 도 2z는 작업 각 수행 단계별 로그를 기록하기 위해 StepLog 엘리먼트를 정의한 내용을 도시하고 있다. StepLog 엘리먼트는 Result, actual_outcome, input_data, expected_outcome로 구성된 속성을 정의한다.

상기 도 3a는 테스트 수행 후 분석 결과를 저장하기 위해 Diagnosis 엘리먼트를 정의한 내용을 도시하고 있다. Diagnosis 엘리먼트는 테스트 수행 결과에 대한 내용을 저장하기 위해 error_type, last_function, last_block, api_block_cvrg, focus_block_cvrg, total_block_cvrg, api_branch_cvrg, focus_branch_cvrg, total_branch_cvrg, focus_function_cvrg, total_function_cvrg로 구성된 속성을 정의한다.

상기 도 3b는 시험 데이터나 시험 예측/실제 결과 등을 표현하기 위한 시험 값 정보를 저장하기 위해 ActualValue 엘리먼트를 정의한 내용을 도시하고 있다. ActualValue 엘리먼트는 Name, kind, ivalue, fvalue, svalue로 구성된 속성을 정의한다.

상기 도 3c는 제어 흐름 그래프를 바탕으로 시험 수행을 모니터링한 커버리지 결과를 저장하기 위해 CvrgData 엘리먼트를 정의한 내용을 도시하고 있다. CvrgData 엘리먼트는 func_no, node_cvrg, iedge_cvrg, eedge_cvrg, next로 구성된 속성을 정의한다.

상기 도 3d는 테스트 수행 시 에러 정보를 저장하기 위해 ErrorLog 엘리먼트를 정의한 내용을 도시하고 있다. ErrorLog 엘리먼트는 error_case, script_name, error_type, last_func_no, last_block_no, next로 구성된 속성을 정의한다.

상기 도 3e는 IUTNO 엘리먼트를 정의한 내용을 도시하고 있다. IUTNO 엘리먼트는 Name, no, next로 구성된 속성을 정의한다.

도 4는 상기 도 2와 도 3에서 정의한 XML 스키마를 기반으로 작성한 XML 데이터를 XML 리포지터리를 이용하여 실제 통합개발도구를 기반으로 개발된 플러그인 프로그램에서의 사용 예를 도식화한 것이다. 이하, 상기 도 4를 참조하여 XML 스키마를 기반으로 작성한 XML 데이터를 XML 리포지터리를 이용하여 실제 통합개발도구를 기반으로 개발된 플러그인 프로그램의 사용 예에 대해 상세하게 알아보기로 한다.

상기 도 4를 참조하면, 개발된 플러그인 프로그램은 실행 단계, 분석 단계, TDP 단계, VDP 단계, TSG 단계, TDG 단계 등의 단계를 수행한다. 이하, 각 단계에 대해 상세하게 알아보기로 한다.

통합개발도구 프로젝트 실행(setup) 단계에서 프로젝트에 대한 정보를 중심으로 Project, TestParam, standard, SrcConfig.xml 파일들을 이용한다. 이 정보들은 프로그램 소스 코드에 대한 분석(PA) 단계를 거쳐서 Constant, Type, Partition, Variable, Function, Scope, Alias, Inherit.xml 등과 같은 파일들을 생성하고 관련 정보들을 저장한다. 또한, TDP(Type Domain Partition), VDP(Variable Domain Partition), TSG(Test Suite Generator), TDG(Test Driver Generator) 단계를 거쳐서 파일들의 정보들이 갱신되며, TSG 단계를 거쳐 Suite.xml과 같은 테스트 슈트에 관한 파일들이 생성된다.

마지막으로 실행 단계를 거쳐 프로그램에 대한 분석 결과들을 Log.xml을 비 롯한 로그 기록 파일들에 기록한다.

한편, 본 발명의 상세한 설명에서는 구체적인 예에 관해 설명하였으나, 본 발명의 범위를 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그리므로 본 발명의 범위는 설명된 실시 예에 국한되지 않으며, 후술되는 특허 청구범위뿐만 아니라 이 특허 청구의 범위와 균등한 것들에 의해 정해져야 할 것이다.

상술한 바와 같이 본 발명은 통합개발도구 내에서 XML Repository를 제공하여 통합개발도구에서 기존에 제공하는 기능들을 수행하는 플러그인 프로그램과 새로운 기능을 추가할 수 있는 플러그인 프로그램을 연동할 수 있는 방안을 제안하고 있다. XML 스키마를 이용하여 설계한 XML 리포지터리는 XML 데이터 형식으로 사용자 프로그램에 대한 정보들을 저장한다. 이를 위해, 통합개발도구에 추가하는 플러그인 프로그램에서 XML 리포지터리를 사용할 수 있는 API를 함께 제공함으로써 플러그인 프로그램 개발자가 XML 리포지터리를 쉽고 편리하게 이용할 수 있는 방안을 제공한다.

또한, XML 리포지터리를 위한 API는 XML 스키마를 이용하여 구성한 XML 리포지터리에 대하여 사용자 프로그램에 관한 정보들을 저장할 수 있는 API, XML 리포지터리에 저장된 사용자 프로그램에 관한 정보들을 검색하고 활용하는 fAPI를 함께 제공하여 효율적으로 개발 도구를 연동할 수가 있다. 즉, 기존에 개발된 플러그인 프로그램에서 작성한 정보들을 새로 추가된 플러그인 프로그램에서 활용함으로써, 새로운 정보를 작성하는데 소요되는 시간과 비용을 단축시킬 수 있게 된다.

Claims (17)

1. 플러그인 프로그램을 이용하여 생성한 통합개발도구를 추가된 플러그인 프로그램에서 활용하기 위한 플러그인 프로그램 활용 시스템에 있어서,

   저장된 확장성 생성 언어(Extensible Markup Language: XML) 데이터를 독출하고, 상기 독출한 XML 데이터를 전달하는 XML 데이터 입출력 모듈;

   상기 XML 데이터 입출력 모듈로부터 상기 독출된 XML 데이터를 수신하고, 추가된 상기 플러그인 프로그램에 대한 접근 권한 여부를 판단하고, 상기 판단 결과 접근 권한이 없으면 상기 플로그인 프로그램의 접근을 차단하는 응용 프로그램 인터페이스(API); 및

   상기 API로부터 전달받은 XML 데이터를 파싱하여 XML 레코드로 변환하는 XML 파서를 포함함을 특징으로 하는 플러그인 프로그램 활용 시스템.
2. 삭제
3. 제 1항에 있어서,

   상기 API는, JABA API, C/C++ API 중 어느 하나임을 특징으로 하는 상기 플 러그인 프로그램 활용 시스템.
4. 제 3항에 있어서,

   상기 API는, 상기 플러그인 프로그램에 관한 정보를 저장하거나, 상기 저장된 정보를 검색하고 활용함을 특징으로 하는 상기 플러그인 프로그램 활용 시스템.
5. 제 1항에 있어서,

   상기 XML 데이터에 대한 구조를 설명하며, 상기 XML 데이터의 입출력 여부를 결정하는 XML 스키마를 더 포함함을 특징으로 하는 상기 플러그인 프로그램 활용 시스템.
6. 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 시스템에 있어서,

   기존의 플러그인 프로그램을 이용하여 작성한 정보들을 저장하고 있는 상기 통합개발도구와,

   상기 통합개발도구에 저장된 정보를 확장성 생성 언어(Extensible Markup Language: XML) 스키마(Schema)를 이용하여 XML 데이터 형식으로 변환하며, 상기 XML 데이터 형식으로 변환된 정보를 추가된 상기 플러그인 프로그램에 활용하는 XML 리포지터리(Repository)를 포함함을 특징으로 하는 상기 플러그인 프로그램 활용 시스템.
7. 제 6항에 있어서,

   상기 XML 리포지터리는,

   저장된 XML데이터를 독출하하고, 상기 독출한 XML 데이터를 전달하는 XML 데이터 입출력 모듈;

   상기 독출한 XML 데이터를 수신하고, 추가된 상기 플러그인 프로그램에 대한 접근 권한 여부를 판단하고, 상기 판단 결과 접근 권한이 없으면 상기 플로그인 프로그램의 접근을 차단하는 응용 프로그램 인터페이스(API); 및

   상기 API로부터 전달받은 상기 XML 데이터를 파싱하여 XML 레코드로 변환하는 XML 파서를 포함함을 특징으로 하는 상기 플러그인 프로그램 활용 시스템.
8. 제 7항에 있어서,

   상기 XML 데이터에 대한 구조를 설명하며, 상기 XML 데이터의 입출력 여부를 결정하는 XML 스키마를 더 포함함을 특징으로 하는 상기 플러그인 프로그램 활용 시스템.
9. 제 7항에 있어서,

   상기 API는, 상기 플러그인 프로그램에 관한 정보를 저장하거나, 상기 저장된 정보를 검색하고 활용함을 특징으로 하는 상기 플러그인 프로그램 활용 시스템.
10. 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 방법에 있어서,

    기존의 플러그인 프로그램을 이용하여 작성한 정보들을 저장하는 단계;

    상기 저장된 정보를 XML 시키마를 이용하여 XML 데이터 형식으로 변환하는 단계; 및

    상기 XML 데이터 형식으로 변환된 정보를 추가된 상기 플러그인 프로그램에 활용하는 단계를 포함함을 특징으로 하는 상기 플러그인 프로그램 활용 방법.
11. 제 10항에 있어서,

    상기 추가된 상기 플러그인 프로그램에 대한 접근 권한 여부를 판단하고, 상기 판단 결과 접근 권한이 없으면 상기 플로그인 프로그램의 접근을 차단함을 특징으로 하는 상기 플러그인 프로그램 활용 방법.
12. 제 11항에 있어서,

    상기 저장된 정보를 XML 데이터로 변환하는 과정은, 새로운 상기 플러그인 프로그램이 추가되면 수행됨을 특징으로 하는 상기 플러그인 프로그램 활용 방법.
13. 제 11항에 있어서,

    상기 저장된 정보를 XML 데이터로 변환하는 과정은, 새로운 상기 플러그인 프로그램이 추가되기 이전에 수행됨을 특징으로 하는 상기 플러그인 프로그램 활용 방법.
14. 제 10항에 있어서,

    상기 XML 데이터는, 새로운 상기 플러그인 프로그램을 위해 적어도 2개의 형식으로 데이터 구조를 정의함을 특징으로 하는 상기 플러그인 프로그램 활용 방법.
15. 제 14항에 있어서,

    XML 데이터 형식의 구조는,

    프로젝트에 관한 정보를 저장하는 프로젝트 정의, 시스템별 기본 자료형의 파티션을 저장하는 SyswidePtt 정의, 시험 대상 소스에 관한 정보와 컴파일, 링크 정보등을 저장하는 SrcConfig 정의, 시험 진행에 필요한 환경 설정 값들을 저장하는 TestParam 정의, 시험 대상 프로그램에 나타난 함수 정보를 저장하는 함수(Function) 정의, 시험 대상 프로그램에서 다루는 자료형 정보를 저장하는 타입(Type) 정의, 시험 대상 프로그램에 나타난 함수의 형식 인자 정보를 저장하는 Variable 정의, 시험 데이터를 생성하는데 필요한 파티션 정보를 저장하는 Partition 정의, 파티션의 경계값이나 기타 다른 시험에 사용되는 상수 정보를 저장하는 Constant 정의, 함수/자료형 등의 가시범위 정보를 저장하는 Scope 정의, 시험 슈트 정보를 저장하는 Suite 정의, 시험 데이터나 시험 예측/실제 결과 등을 표현하기 위한 시험 값 정보를 저장하는 ActualValue 정의, 시험 수행 결과를 저장하는 Log 정의, 함수에 대한 제어 흐름 그래프를 저장하는 FFG 정의, 및 제어 흐름 그래프를 바탕으로 시험 수행을 모니터링한 커버리지 결과를 저장하는 CvrgData 정의 중 적어도 하나를 포함함을 특징으로 하는 플러그인 프로그램 활용 방법.
16. 플러그인 프로그램을 이용하여 생성한 통합개발도구에 저장된 정보를 추가된 플러그인 프로그램에서 활용하는 방법에 있어서,

    기존의 플러그인 프로그램을 이용하여 작성한 정보들을 XML 시키마를 이용하여 XML 데이터 형식으로 변환하는 단계;

    상기 XML 데이터 형식으로 변환된 정보를 다양한 속성을 갖는 XML 레코드로 변환하는 단계; 및

    상기 변환된 XML 레코드를 추가된 상기 플러그인 프로그램에 활용하는 단계를 포함함을 특징으로 하는 상기 플러그인 프로그램 활용 방법.
17. 제 16항에 있어서,

    상기 추가된 상기 플러그인 프로그램에 대한 접근 권한 여부를 판단하고, 상기 판단 결과 접근 권한이 없으면 상기 플로그인 프로그램의 접근을 차단함을 특징으로 하는 상기 플러그인 프로그램 활용 방법.

Images