KR100985192B1 - 소프트웨어 개발 시스템 - Google Patents

Abstract

본 발명의 일 실시예에 따른 소프트웨어 개발시스템은, 개발자가 단위 업무를 실행하는 적어도 하나의 단말 모듈을 시각적으로 배치하여 서비스 모듈을 작성할 수 있게 하는 소프트웨어 개발 시스템에 있어서, 적어도 하나의 단말모듈을 구비한 서비스 모듈의 모듈 플로우 구성도를 생성하는 모듈 플로우 디자이너와, 상기 모듈 플로우 구성도에 따라 상기 서비스 모듈의 소스코드를 생성하는 소스 생성부와, 상기 서비스 모듈의 메타데이터를 분석하는 메타 관리부와, 상기 서비스 모듈의 메타데이터를 저장하는 메타데이터 저장부를 포함하며, 상기 메타 관리부는 상기 모듈 플로우 구성도의 메타데이터를 이용하여 상기 서비스 모듈의 메타데이터를 생성한다.

모듈, 재사용, 메타데이터, 서비스, 플로우, 업무, 통합개발환경

Description

소프트웨어 개발 시스템{System for developing software}

본 발명은 편리하고 유연성 있는 통합 개발 환경에 관한 것으로, 보다 자세하게는 서비스의 전체 업무 플로우에 필요한 모듈을 플러그인 또는 플러그아웃시켜 조합하는 개발방식에 있어서, 해당 모듈의 변경 영향도 정보를 시각적으로 편리하게 개발자에게 제공함으로써 업무 프로그램의 정확한 작성 및 안정적인 유지보수를 가능하게 해주는 소프트웨어 개발 시스템에 관한 것이다.

금융권 또는 통신권 등의 업무는 매우 복잡하고 변경 요인이 자주 발생한다. 이로 인하여, 내부 시스템 개발에 있어 소요 기간이 길어지고 유지보수에 많은 노력이 필요하게 된다. 이에 따라 사용자 요구 사항을 쉽게 반영하여 필요한 소프트웨어를 신속히 개발할 수 있는 소프트웨어 작성 방식이 요구되고 있다. 즉, 현대의 기업 전산 시스템은 그 복잡도와 규모가 점점 커지고 있으며, 경쟁이 심화되면서 시스템의 신속한 구축, 변경 및 확장의 용이성과 구축비용의 절감 등이 더욱 절실히 요구되고 있는 것이다.

대규모 기업 전산 시스템용 소프트웨어는 분산 시스템으로 운영되어지고 단 계적 디자인의 개념으로 개발되는데, 통상적으로 이러한 소프트웨어는 대부분 3단계(3-Tier) 혹은 다단계(N-Tier) 구조로 개발된다. 일반적으로 단계적 설계에서는 앞 단계에 프리젠테이션 티어, 중간 단계에 비즈니스 로직 티어, 뒤 단계에 데이터서비스 티어를 위치시킨다.

여기서 언급하고자 하는 개발 업무란 중간 단계인 비즈니스 로직 티어의 개발을 대상으로 한다. 전체 업무를 실행 가능한 여러 개의 단위 업무로 분할하고, 실행의 단위가 되는 단위 업무를 다시 여러 개의 모듈로 분할하는 것이 일반적인 개발 방식이다.

최하위 레벨의 단말 모듈을 제외한 대부분의 모듈은 자신보다 하위 레벨의 모듈을 이용 또는 호출하고 있으며, 기본적으로 하위 레벨 모듈의 처리 결과를 바탕으로 자신의 처리 결과를 상위 레벨의 모듈에 제공한다. 이 때, 하위 모듈에 대한 처리 요청 호출은 정적으로 코딩(Static Coding)된 채 컴파일되어 블랙박스(Black Box: Binary Code) 형태로 배포된다.

이미 개발되어 있던 모듈을 서로 조합하여 설계자가 원하는 기능을 수행하는 새로운 소프트웨어를 개발하려면, 처리를 요청하는 상위 레벨의 모듈과 처리 결과를 제공하는 하위 레벨의 모듈 사이에 시그너처(Signature)가 서로 정합되어야 한다. 여기서, 시그너처란 모듈과의 인터페이스, 즉, 모듈 이름[또는 클래스 이름(ID: Identification)과 메소드(Method) 이름], 매개 변수 타입 및 순서 등을 포함한다.

하드웨어와 달리 소프트웨어는 부품에 해당하는 모듈이 많고 다양하므로(거 의 무한대) 미리 그 규격을 정할 수 없으며, 독립적으로 개발된 모듈 사이의 상술한 시그너처 정합 문제를 해결하기 위해서는 모듈 소스 코드를 수정한다거나 수작업으로 글루(Glue) 코드를 개발해야 하는 부담이 있었다. 대한민국 공개특허 특2003-0044959호(발명의 명칭 : 클라이언트 측 메타데이터와 글루 코드를 이용한 컴포넌트 구현 및 조립방법, 이하 '선행기술'이라 함)는 그러한 글루 코드의 일부를 자동적으로 생성함으로써 개발자의 부담을 줄여주는 기술이다. 구체적으로, 상위 모듈(선행기술에서는 '클라이언트 컴포넌트')이 호출할 서비스 리스트를 개발자에게 보여주어 원하는 서비스 호출을 선택하게 하고, 하위 모듈(선행기술에서는 '서버 컴포넌트')이 제공하는 서비스 리스트를 보여주어 호출될 서비스를 선택하게 한다. 이렇게 선택된 두 서비스의 메타데이터를 통해 글루 코드의 기본적 사양 코드가 자동적으로 생성되는데, 개발자는 이러한 기본적 사양 코드에 소정의 중재 코드만을 추가함으로써 글루 코드를 완성할 수 있다.

그러나, 이러한 선행 기술은 모듈의 거대화/복잡화에 따라 부정확성과 상대적으로 느린 실행 속도 등의 문제 때문에 글루 코드의 존재 자체가 문제가 될 수 있고, 프로그램의 작성에는 어느 정도 편의성을 제공할 수 있으나 그 유지보수에는 무용하다는 단점이 있다.

구체적으로, 전술한 프로그램의 유지보수와 관련하여, 종래의 모듈은 자신의 메타데이터에 자신을 하위 모듈로서 이용 또는 호출하는 상위 모듈의 정보를 전혀 포함하지 않기 때문에, 완성된 프로그램에서 하위 모듈의 수정이 필요한 경우에는 개발자가 그 모듈을 개발할 당시의 설계 정보를 구하여 해당 하위 모듈을 이용 또 는 호출하는 모든 상위 모듈을 수작업으로 찾아야 한다는 문제점이 있었다.

그 밖에도 일반적으로 대량의 레코드를 한 번에 처리하는 배치(batch) 업무는 여타의 온라인상에 수행되는 업무와는 별개로 일반적인 코딩 방식으로 작성해 왔었다. 그에 따라 업무 플로우의 가시성을 확보하기 힘들고, 온라인상에서 수행되는 일반적인 업무에서 작성한 모듈을 배치 업무에서 재사용하기도 용이하지 않았다.

본 발명은 상기한 문제점을 개선하기 위한 것으로, 시스템의 전체업무를 구성하는 하위 업무 기능과 관련 데이터를 묶어 모듈로 분할하고, 개별 모듈이 표준 규격을 만족하도록 전체 모듈의 메타데이터를 통합 관리함으로써 개별 모듈의 재사용을 용이하게 하여, 소프트웨어 조합 개발 개념을 더 구체화하는 데에 제1목적이 있다.

또한, 전체 업무의 실행 단위가 되는 단위 업무에 해당하는 서비스를 구현하는 업무 모듈에 대한 정보를 메타데이터화하여 관리함으로써, 개발된 소프트웨어를 자산화하고 소프트웨어의 재사용성을 향상시키는 데에 제2목적이 있다.

나아가, 재사용하려는 모듈의 수정이 필요한 경우에는 해당 모듈의 변경 영향도 정보를 제공하여 개발자로 하여금 해당 모듈과 관련된 모든 모듈(또는 리소스)을 파악할 수 있게 하고, 이를 통해 해당 모듈뿐만 아니라 관련 모듈까지 적절히 수정할 수 있게 함으로써, 일부 변경으로 인한 전체 시스템의 오류의 발생 가능성을 현저히 줄여 소프트웨어 유지보수의 안정성을 향상시키는 데에 제3목적이 있다.

또한, 배치 업무를 여타의 온라인 업무를 위한 프로그램을 작성하는 것과 유사하게 모듈로서 개발함으로써 업무 플로우의 가시성을 제공하고 용이한 유지보수를 가능하게 할 뿐 아니라, 온라인 모듈을 공유해서 같이 사용할 수 있도록 함으로써 모듈의 재사용성을 향상시키는 데에 제4목적이 있다.

본 발명의 목적들은 이상에서 언급한 목적들로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

상술한 바와 같은 과제를 달성하기 위한 본 발명의 바람직한 일 실시예에 따른 소프트웨어 개발 시스템은, 적어도 하나의 단말모듈을 구비한 서비스 모듈의 모듈 플로우 구성도를 생성하는 모듈 플로우 디자이너와, 상기 모듈 플로우 구성도에 따라 상기 서비스 모듈의 소스코드를 생성하는 소스 생성부와, 상기 서비스 모듈의 메타데이터를 분석하는 메타 관리부와, 상기 서비스 모듈의 메타데이터를 저장하는 메타데이터 저장부를 포함하며, 상기 메타 관리부는 상기 모듈 플로우 구성도의 메타데이터를 이용하여 상기 서비스 모듈의 메타데이터를 생성하는 것을 특징으로 한다.

본 발명의 바람직한 다른 실시예에 따른 소프트웨어 개발시스템은, 실제 업무의 처리를 담당하는 코드로 작성된 단말 모듈 및 상기 단말 모듈이 실행되는 순서를 나타내는 플로우 모듈을 포함하는 서비스 모듈을 작성하고, 상기 플로우 모듈과 상기 단말 모듈이 실행되는 순서를 나타내는 모듈 플로우 구성도를 작성하며, 상기 모듈 플로우 구성도를 출력하는 모듈 플로우 디자이너를 포함하는 통합개발환경, 상기 통합개발환경에서 전달받은 개발 내용을 이용하여 개발에 사용되는 리소스의 메타데이터를 저장하거나, 상기 통합개발환경에서 리소스의 일정한 키 값을 전달받아 상기 키 값과 일치되는 리소스의 메타데이터를 검색하고 상기 검색된 메 타데이터를 상기 통합개발환경에 전달하는 메타 관리부 및 상기 메타데이터가 저장되는 메타데이터 저장부를 포함한다.

이와 같이 본 발명에 의하면, 시스템을 구성하는 단위 업무를 여러 기능으로 분할하고, 각 부분 업무 기능과 관련 데이터를 묶어 모듈들로 분할하며, 이들의 메타데이터를 통합하여 관리함으로써 표준 규격을 만족하도록 모듈을 부품화시켜 이를 재사용하는 것이 가능하게 되고, 그 결과 소프트웨어 개발이 조합 개념으로 발전된다.

또한, 단위 업무 서비스를 구성하는 업무에 관한 모듈들을 메타데이터화하여 관리함으로써, 개발된 소프트웨어를 자산화하고, 소프트웨어의 재사용성이 향상된다.

나아가, GUI상에서 업무의 플로우를 시각적으로 보여주고 편집하게 함으로써 업무에 대한 가시성을 제공하고, 모듈 플로우에 모듈들을 쉽게 플러그인/플러그아웃 할 수 있게 해준다. 이러한 기능을 토대로, 모듈의 추가, 수정 및 제거 등을 용이하게 함으로써 소프트웨어의 유지보수가 용이하게 되며, 변경 영향도 정보를 제공하여 변경된 리소스를 참조하는 모든 리소스를 파악해 줌으로써 영향 받는 리소스를 큰 어려움 없이 모두 변경할 수 있도록 함으로써 잦은 변경으로 인한 프로그램 오류의 가능성을 현저히 줄여 유지보수 기능을 더욱 더 향상시킨다.

이하에서는 먼저 도면을 참조하여 본 발명의 바람직한 실시예에 대하여 설명 하기로 한다.

도 1은 본 발명의 일 실시예에 따른 재사용 가능한 모듈을 이용하는 소프트웨어 개발 시스템(이하 '소프트웨어 개발 시스템'이라 함)의 운영을 개념적으로 나타내는 개략도이다.

소프트웨어 특히 대규모 기업용 소프트웨어의 개발에 있어서, 소프트웨어의 개발자는 본 발명의 일 실시예에 따르는 소프트웨어 개발 시스템(110)을 사용함으로써 일정한 업무를 구현하는 소프트웨어를 손쉽게 개발하고 유지보수할 수 있다.

도 1에서 도시된 바와 같이 개발자는 계좌 이체(100)와 같은 특정한 단위 업무를 구현하는 소프트웨어를 본 발명의 일 실시예에 따른 소프트웨어 개발 시스템(110)을 이용하여 개발할 수 있다. 여기에서 단위 업무라 함은 소프트웨어 사용자의 거래에 관한 요청을 처리하고자, 개발자가 소프트웨어를 통하여 구현하고자 하는 기능의 기본 단위를 의미한다. 본 발명의 일 실시예에서 이러한 업무는 트랜잭션(Transaction) 처리의 기본 단위를 구성하며 서비스로서 구현된다.

은행에서 사용되는 소프트웨어와 관련된 실제 업무의 예로는 고객의 입금 요청, 출금 요청 및 연체 해제 요청 등을 들 수 있다.

소프트웨어 개발 시스템(110)에서는 개발자가 개발하려는 소프트웨어에 의하여 구현하려는 업무에 맞게 기존에 개발된 모듈(120) 중에서 필요한 모듈(120)을 조합한 후, 이를 호출하여 소스를 생성한다. 그 후, 이와 같이 생성된 소스가 컴파일되고, 컴파일되어 생성된 바이너리(binary)가 실행환경으로 디플로이(deploy)된다. 실행환경으로 디플로이된 그 바이너리들이 실행됨으로써 운영환경을 구성하게 된다.

여기서 모듈(120)이라 함은, 전체 소스를 구성하는 하나의 단위로서, 일정한 유형, 특성 등을 지닌 데이터와 이러한 데이터들의 입력 또는 출력에 관한 자체적인 정보 등을 가진 독립된 소스의 조각을 말한다. 이러한 모듈(120)에 관한 자세한 내용은 후술하기로 한다.

개발자 등이 이전에 제작한 적어도 하나의 모듈(120)이 일정한 저장매체에 저장되어 있으며, 개발자는, 소프트웨어 개발 시스템(110)을 통해, 개발하고자 하는 소프트웨어에 의하여 구현되는 계좌 이체(100)와 같은 업무에 적합한 모듈을 위 저장된 모듈(120) 중에서 검색하고, 이를 조합한 후에 필요한 프로그램 소스(소프트웨어)를 생성할 수 있다.

이상에서 살펴본 소프트웨어 개발 시스템(110)의 운영에 관하여 이하에서 보다 자세하게 설명하기로 한다.

도 2는 본 발명의 일 실시예에 따른 소프트웨어 개발 시스템(110)의 블록도이다.

본 발명의 일 실시예에 따른 소프트웨어 개발 시스템(110)은 크게 통합개발환경(200), 통합개발엔진(210) 및 저장부(220)를 포함하며, 통합개발환경(200)은 모듈 플로우 디자이너(201), 맵퍼(202), DBIO(203) 및 스튜디오(204)를 구비하고, 통합개발엔진(210)은 메타 관리부(211), 소스 생성부(212) 및 인터페이스 관리부(213)를 구비하며, 저장부(220)는 메타데이터 저장부(221) 및 소스 저장부(222)를 구비한다.

본 실시예에서 사용되는 각각의 블록은 소프트웨어 또는 FPGA, ASIC과 같은 하드웨어 구성요소를 의미하며, 이러한 블록은 각각 소정의 기능을 수행한다. 그러나 본 발명의 일실시예에 따른 블록이 소프트웨어 또는 하드웨어에 한정되는 것은 아니다. 이러한 블록은 어드레싱할 수 있는 저장 매체에 저장되어 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세스를 재생시키도록 구성될 수도 있다. 일예로서 블록은 객체지향 소프트웨어 구성요소, 클래스 구성요소 및 태스크 구성요소와 같은 소프트웨어 구성요소나, 프로세스, 함수, 속성, 프로시저, 서브루틴, 프로그램 코드의 세그먼트, 드라이버, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조, 테이블, 어레이 및 변수 등으로 구성될 수 있다. 구성요소와 블록 안에서 제공되는 기능은 더 작은 수의 구성요소 및 블록으로 결합되거나 추가적인 구성요소 및 블록으로 더 분할될 수 있다.

통합개발환경(200)을 이용하여, 개발자는 GUI 환경에서 특정한 기능을 구현하는 소프트웨어 개발에 필요한 모듈(120)을 새로 정의하거나, 이미 정의된 모듈(120)을 서로 조합함으로써 신규 소프트웨어를 제작할 수 있다. 또한 이미 정의된 모듈(120)의 소스를 직접 수정할 수도 있는데, 이러한 통합개발환경(200)은 모듈 플로우 디자이너(201), 맵퍼(202), DBIO(203) 및 스튜디오(204)를 구비한다.

통합개발환경(200)은 키보드, 마우스 또는 터치스크린 등과 같은 입력 수단과 연결되어 있으며, 개발자는 구현하려는 소프트웨어에 사용되는 모듈(120)에 관한 정보 등과 같은 일체의 정보를 입력 수단을 통하여 통합개발환경(200)에 입력할 수 있다. 이러한 정보를 입력하는 데에 있어, 편리성을 도모하기 위하여 GUI 환경 이 제공되며, 또한 다이얼로그 박스 등을 각각의 상황에 맞춰 팝업시켜 이러한 다이얼로그 박스에 일정한 정보를 입력할 수 있도록 하여, 개발자의 편의를 도모한다.

또한 통합개발환경(200)은 모니터, 평판 디스플레이 패널 또는 터치스크린 등과 같이 시각적으로 일정한 정보를 개발자에게 제공할 수 있는 출력 수단과 연결되어 있다. 이러한 출력 수단을 통하여 특정한 업무를 구현하는 소프트웨어에 사용되는 모듈(120)에 관한 정보 등 일체의 정보가 개발자에게 실시간으로 제공된다.

모듈 플로우 디자이너(201)에서 개발자는 종래에 개발된 모듈을 시각적으로 드래그 앤 드랍(Drag and Drop)하여 연결함으로써, 새로운 단위 업무에 대한 모듈 플로우를 새로이 작성할 수 있다.

여기서 모듈 플로우라 함은 단위 업무를 구성하는 모듈이 실행되는 순서를 의미하며, 모듈 플로우 구성도는 모듈 플로우를 시각적으로 표현하는 수형도를 의미한다.

도 3은 본 발명의 일 실시예에 따른 서비스를 구성하는 모듈들의 모듈 플로우를 나타내는 개략도이다.

이러한 모듈 플로우를 설명하기 위하여 우선 본 발명의 일 실시예에 따르는 소프트웨어 개발 시스템(110)에서 사용되는 서비스와 서비스 모듈의 개념을 먼저 설명할 필요가 있으며, 이하에서 이를 상술하기로 한다.

본 발명의 일 실시예에 따르면, 전체 업무 중 실행 단위가 되는 단위 업무에 해당하는 서비스에는 하나의 업무를 수행하기 위해 필요한 일체의 기능이 모두 포 함된다. 즉, 하나의 단위 업무는 시스템 선처리, 업무 선처리, 개별 업무 처리, 업무 후처리, 시스템 후처리 순으로 구현되며, 이러한 단위 업무에 대응하는 서비스 모듈은 시스템 선처리 모듈, 업무 선처리 모듈, 서비스 모듈, 업무 후처리 모듈, 시스템 후처리 모듈을 포함한다.

특히, 상술한 서비스 모듈은 서비스의 구성 내용 중, 각 서비스 별로 수행하는 고유의 개별 업무를 구현하며, 각 개발자는 주로 이 서비스 모듈을 중점적으로 개발한다. 간단하게 정리하면, 서비스 모듈은 전체 서비스를 구성하는 모듈 중 시스템 선처리 모듈, 시스템 후처리 모듈, 업무 선처리 모듈 및 업무 후처리 모듈을 제외한 것이다. 이러한 서비스 모듈에 관하여 후술하기로 한다.

도 3에서 도시된 입금 서비스 모듈(300)은 시스템 선처리 모듈(310), 업무 선처리 모듈(320), 서비스 모듈인 입금 처리 모듈(330), 업무 후처리 모듈(340) 및 시스템 후처리(350) 모듈로 구성된다.

시스템 선처리 모듈(310)은 시스템 선처리 업무를 수행하는 모듈로서, 본 발명의 일 실시예에 따른 소프트웨어 개발 시스템(110)을 이용하여 개발하는 전체 업무의 각 단위 업무에 해당하는 각 서비스에 대하여 공통적으로 선행해서 처리해야 하는 선처리 업무를 구현하는 모듈을 의미한다.

예를 들어 은행 업무 시스템을 개발하는 경우, 모든 은행 업무 서비스에 대해 실행 가능 시간과 불가능 시간을 지정할 수 있다. 이렇게 지정된 시간을 기준으로, 각 서비스에 대해 특정 시점에 실행 가능 여부를 판단하여 실행 여부를 공통적으로 제어하는 로직을 시스템 선처리 모듈(310)에 포함하도록 한다. 그리고, 각 서비스를 실행할 때 맨 처음 시스템 선처리 모듈(310)을 실행하도록 하여, 특정 시간에 실행 요청이 들어오면 지정된 실행 가능 시간을 체크함으로써, 지정된 실행 가능 시간에는 서비스를 실행하도록 하나, 실행 불가 시간에는 서비스를 수행하지 못하도록 제어한다. 이러한 시스템 선처리 모듈(310)은 모든 서비스에 대해 공통적으로 작성하여, 개별 서비스들은 이를 공유하여 사용한다.

업무 선처리 모듈(320)은 특정 업무 그룹에 있어서, 예컨대 은행의 수신 업무 팀의 각 단위 업무에 공통적으로 선행해서 실행되는 사항을 구현하는 모듈을 말한다. 수신 업무 팀의 모든 서비스에서 선행하여 실행되는 공통적인 업무로서, 그 수신 업무 팀의 고객 원장을 읽는 업무가 이에 해당하며, 수신 업무 팀에서는 수신 그룹의 고객 원장을 읽는 업무 선처리 모듈을 하나 개발하여 공유함으로써, 동일 업무 그룹에서 수행하는 각 서비스 내의 업무 처리에 있어서 이를 공유하여 실행한다.

입금 처리 모듈(330)은 서비스 모듈로서, 입금 업무 처리라는 입금 서비스의 고유 업무를 처리하는 전체 로직을 포함한다. 이 전체 업무의 로직을 구현하기 위하여, 서비스 모듈은 모듈이 실행되는 순서를 나타내는 플로우 모듈과 모듈 플로우 구성도의 단말 노드에 위치할 수 있는 여러 단말 모듈들을 연결하고, 이들을 조합하여 구성하게 된다. 모듈 플로우 구성도의 단말 노드에 관련된 사항은 이하에서 설명하기로 한다.

모듈의 분류는 공유 여부에 따른 분류와 단말 노드에 위치할 수 있느냐에 따른 분류가 가능하다.

공유 가능한 모듈이란 한 번 정의된 후에도 다시 재사용될 수 있는 모듈을 말한다. 공유가 불가능한 모듈은 재사용 대상이 되지 않는데, 주로 특정한 서비스 또는 업무에서만 사용될 수 있는 모듈을 말한다.

또한, 앞서 언급한 모듈 플로우 구성도에서 최하위에 위치한 단말 노드에 위치할 수 있는 모듈은 실제 업무의 처리를 실행하는 코드로 작성되는데, 단말 노드에 오는 모듈을 단말 모듈이라 한다. 이에 반해 단말 노드에 위치할 수 없는 플로우 모듈은 주로 모듈 사이의 실행 순서에 대한 코드(또는 로직)로써 구성된다는 차이가 있다.

입금 처리 모듈(330)과 같은 서비스 모듈은 처리하는 전체 업무 내용을 하나의 모듈로 작성하기에는 너무 많고 큰 내용이므로, 부분적으로 여러 개로 그룹핑하여 분할 처리할 수 있는데, 그 분할 처리의 업무 단위가 되는 것이 비즈니스 모듈이다. 비즈니스 모듈은 전체 업무를 처리하는 서비스 모듈의 일부를 구성하는 부분 모듈이나, 그 자체도 꽤 큰 내용이므로 플로우 모듈 및 단말 모듈 또는 다른 비즈니스 모듈의 조합을 통해서 구성되는 것이 일반적이다.

비즈니스 모듈도 모듈 플로우 구성도의 단말 노드에 위치할 수 있으므로 선택적으로 단말 모듈로 분류되는 경우가 있다. 이러한 비즈니스 모듈은 입력 및 출력 매개변수만 일치하도록 하여 호출하면 어디에서든 재사용할 수 있도록 작성되는 것이 일반적이다.

업무 후처리 모듈(340)은 서비스 모듈이 고유의 개별 업무를 실행한 이후에 실행되는 모듈로서, 특정 업무 팀의 각 서비스에 공통적으로 처리해야 하는 업무를 수행하는 모듈을 말한다. 예를 들어, 고객 원장의 변경된 사항을 한번에 DB에 반영하는 등의 일을 처리하는 것 등이 이에 해당한다.

시스템 후처리 모듈(350)은 상술한 시스템 선처리 모듈(310)과 반대로 각각의 서비스에 대해 마지막 단계에서 공통적으로 실행되는 모듈을 말한다. 이러한 시스템 후처리 모듈(350) 또한 시스템 선처리 모듈(310)과 마찬가지로 전체 업무에 대해 공통적으로 작성하여 전체 서비스에서 공유하도록 한다. 시스템 후처리에는 예컨대, 각 서비스의 기본적인 업무 처리를 완료하고, 최종적으로 거래의 완료나 롤백 등의 처리를 수행하는 것 등이 있다.

모듈 플로우 디자이너(201)에서는 특정한 서비스를 구성하는 서비스 모듈에 관한 모듈 플로우 구성도를 화면에 출력하여, 개발자로 하여금 시각적으로 서비스 모듈의 전체적 구성을 확인할 수 있게 한다. 이에 관하여는 후술하는 도 4a의 설명에서 상술한다.

도 4a는 본 발명의 일 실시예에 따른 입금 서비스 모듈(400)의 모듈 플로우가 모듈 플로우 디자이너(201)를 통해 개략적으로 출력된 화면이다.

입금 서비스 모듈(400)은 입금 서비스를 구성하는 모듈 중에서, 타 서비스 또는 타 업무와 공유되는 공유 모듈에 해당하는 시스템 선처리/후처리 모듈과, 업무 선처리/업무 후처리 모듈을 제외한 입금 서비스 고유의 업무를 처리하는 모듈이다.

입금 서비스 모듈(400)은 입금 업무의 처리를 담당하는 서비스 모듈이며, 플로우 모듈과 여러 개의 단말 모듈의 조합을 통하여 구성된다. 다시 말하면, 이너 모듈(inner module), 루프 모듈(roof module), 분기 모듈 등의 플로우 모듈과 실제 업무를 처리하는 코드를 담고 있는 비즈니스 모듈, DBIO 모듈, 외부 모듈 등 단말 모듈의 조합에 의하여 서비스 모듈이 구성되는데, 이하에서는 이러한 모듈들에 관하여 상세히 설명하기로 한다.

DBIO 모듈은 DB 처리에 관련된 코드를 포함하는 모듈이다. DB에 저장된 고객 정보 등의 조회, 추가, 변경, 삭제 등을 처리하는 코드를 포함하는 모듈인데, 이에 관하여는 후술하는 DBIO(203)의 설명에서 자세히 다루기로 한다.

외부 모듈은 외부 툴에서 정의된 모듈로서, 개발자는 모듈 플로우 디자이너(201)를 통해 이러한 외부 모듈까지 용이하게 사용할 수 있다. 룰 엔진 등과 같은 외부 엔진에서 정의된 모듈이 그 예가 될 수 있다. 외부 모듈을 본 발명의 일 실시예에 따른 소프트웨어 개발 시스템(110)에 사용하기 위해서는 외부 모듈과 내부 모듈 사이의 인터페이스를 맞춰야 하는데, 이에 관하여는 후술하는 인터페이스 관리부(213)에서 상술하기로 한다.

플로우 모듈은 서비스를 구현하는 모듈의 실행 순서를 모듈 개념으로 통칭하는 것으로, 이너 모듈, 루프 모듈 및 분기 모듈 등으로 분류할 수 있다. 이너 모듈은 모듈 플로우 구성도의 시작 노드에서 단말 노드에 이르기까지의 실행되는 모듈의 순서에 관한 로직만을 포함하는 모듈이다. 이너 모듈은 주로 비즈니스 모듈의 플로우 제어를 포함하는 모듈이나, 사용자의 필요에 따라 해당 비즈니스 모듈을 포함할 수도 있다. 이너 모듈 중에 루프를 포함하는 이너 모듈은 루프 모듈, 분기 로직을 포함하는 이너 모듈은 분기 모듈이라고 한다.

공유 여부에 따른 분류 관점에 각각의 모듈을 살펴보면 다음과 같다. 공유되는 모듈에는 서비스 모듈, 비즈니스 모듈, 이너 모듈, DBIO 모듈, 외부 모듈이 있으며, 이들은 모두 모듈 플로우 구성도의 단말 노드에 위치할 수 있다. 공유되지 않는 모듈에는 플로우 모듈에 해당하는 루프 모듈과 분기 모듈이 있으며, 이들은 단말 노드에 위치할 수 없다. 전술한 바와 같이, 단말 노드에 위치할 수 있는 다른 모듈과는 달리 비즈니스 모듈은 모듈들의 실행 순서를 나타내는 플로우 모듈을 포함할 수 있고, 플로우 모듈의 일종인 이너 모듈은 비즈니스 모듈을 포함하는 경우에 한해서 단말 노드에 위치할 수 있다.

도 4a에서 도시된 바와 같이 입금 서비스 모듈(400)이 수행되면, 입금정보 확인 모듈의 실행, 거래정당성 확인 모듈의 실행, 입금 모듈의 실행, 출력처리 모듈의 실행이 차례로 진행되게 된다. 상위 레벨인 레벨1(410)에 위치하는 각 모듈의 실행은 다시 하위 레벨인 레벨2(420)의 모듈을 호출하여 필요한 처리를 하게 된다. 즉, 레벨1(410)에 해당하는 입금정보 확인 모듈의 실행 시에는 하위 레벨의 필수입력 확인 모듈을 실행한 후, 입금 최대금액 확인 모듈을 실행하여 그 결과를 받은 후에, 동일 레벨의 다음 노드인 거래정당성 확인 모듈을 실행하는 방식으로 처리가 된다.

도 4a에는 플로우 모듈 중에 이너 모듈만이 도시되어 있다. 모듈 플로우 구성도의 단말 노드에 위치하는 모듈은 모듈 플로우 디자이너(201)에서 그 모듈의 종류 별로 구분되어 재사용이 용이하게 표시된다. 비즈니스 모듈, DBIO 모듈, 외부 모듈 등이 이에 해당하는데, 도 4a에 도시된 단말 노드에 위치하는 모듈은 대부분 비즈니스 모듈이다.

이외에도 배치 업무를 실행할 수 있는 단위 업무로 수행하는 배치(batch) 서비스와 배치 서비스 모듈이 있다. 배치 업무는 통상적으로 수행되는 일반 업무와 차이가 있다. 일반적으로 수행되는 업무에서는 보통 한 건의 처리를 하며 거래의 완료(commit) 및/또는 롤백(rollback)을 서비스의 마지막에 일률적으로 자동 처리할 수 있는데 반해, 배치 업무에서는 대량의 레코드를 처리하는 도중에 일정 한도의 건 별로 거래의 완료 및/또는 롤백을 개발자가 직접 제어할 수 있어야 한다. 이러한 배치 업무는 일반적인 업무와 달리, 대량의 파일 처리가 포함될 수 있다.

도 4b 및 도 4c는 각각 본 발명의 일 실시예에 따른 지급 서비스 모듈(430)의 모듈 플로우 구성도 및 이체 서비스 모듈(440)의 모듈 플로우 구성도를 나타내는 도면이다.

도 4b에서는 서비스 모듈인 지급 서비스 모듈(430)과 이를 구성하는 이너 모듈인 상품정보 확인, 계좌정보 조회, 수수료 계산 및 지급 가능금액 계산 모듈이 도시되어 있다. 그리고 각각의 이너 모듈에 포함되는 비즈니스 모듈인 지급 가능금액 확인, 지급 가능여부 확인, 계좌 원장정보 확인, 비밀번호 확인, 수수료 계산, 미결제 타점권 금액계산, 금액 산출 및 지급 오류 처리 모듈이 도시되어 있다.

종래에 작성된 서비스 모듈을 재사용하여 새로운 서비스 모듈을 작성할 수도 있는데, 도 4c는 종래에 작성된 입금 서비스 모듈(400)과 지급 서비스 모듈(430)을 이용하여 새로이 작성된 이체 서비스 모듈(440)을 도시한다.

도 4c에는 이너 모듈인 입금 처리, 지급 처리 및 이체 후처리 모듈이 더 도 시되어 있으며, 일부 이너 모듈은 종래의 서비스 모듈인 입금 서비스 모듈(400) 및 지급 서비스 모듈(430)을 각각 포함하는 것으로 도시되어 있다. 이와 같이 종래에 작성된 서비스 모듈을 재사용함으로써 새로운 서비스 모듈을 손쉽게 구성할 수 있으므로, 개발자는 보다 빠르게 새로운 기능을 구현하는 신규 소프트웨어를 작성할 수 있게 된다.

도 2의 맵퍼(202)에서는 서비스 모듈의 모듈 플로우 구성도에서 서로 연결된 모듈 간의 데이터 전달을 시각적으로 매핑한다. 앞서 살펴본 서비스를 사용하여 하나의 업무를 수행하려면, 호출하는 모듈과 호출되는 모듈 간에는 서로 정보를 주고받아야 한다. 이를 위해, 호출하는 모듈의 변수에서 호출되는 모듈의 변수에 값을 할당하는 것이 필요한데, 기존에는 이러한 부분을 개발자가 직접 코딩으로 처리하였다. 이렇게 직접 개발자가 코딩하지 않더라도, 맵퍼(202)를 통하여 데이터 전달 관계, 즉 데이터 값의 할당 관계를 GUI 상에서 시각적으로 처리할 수 있다.

이러한 맵퍼(202)를 사용함으로써, 개발자는 호출하는 모듈의 변수 또는 모듈에 존재하는 구조체 간의 각 해당 필드로의 매핑을 시각적으로 편리하게 실시할 수 있게 되며, 매핑 관계의 수정이 필요할 경우에는 이를 쉽게 GUI 상에서 변경할 수 있다.

DBIO(203)에서는 DB에 저장된 데이터를 조회, 추가, 변경, 삭제하는 기능을 수행하는 DBIO 모듈을 작성할 수 있다. 이러한 DBIO 모듈의 편집 및 수정은 DBIO(203)를 통해서 수행한다. 모듈 플로우 디자이너(201)에서 화면상에 출력된 DBIO 모듈을 더블 클릭하면, 스튜디오(204)는 연계되어 있는 DBIO(203)를 실행시 켜, 그 DBIO 모듈을 편집할 수 있도록 해준다. 이러한 스튜디오(204)에 관하여는 후술하기로 한다.

도 2의 스튜디오(204)에는 모듈 플로우 디자이너(201), 맵퍼(202) 및 DBIO(203)가 플러그인 되어 있다. 스튜디오(204)는 플러그인 된 모듈 플로우 디자이너(201), 맵퍼(202) 및 DBIO(203)간에 연계 기능을 제공하고, 모듈 등의 소스 코드를 편집하거나 디버깅할 수 있게 해주며, 각 툴에 필요한 전체적인 환경을 설정할 수 있는 기능을 제공한다.

스튜디오(204)가 처음에 실행될 때, 플러그인 된 모듈 플로우 디자이너(201)가 연계되어 실행된다. 모듈 플로우 디자이너(201)를 이용하여 개발자는 새로운 서비스 모듈을 작성하거나, 모듈 플로우 디자이너(201) 화면에 출력된 기 개발된 서비스 모듈의 모듈 플로우 구성도를 편집할 수 있다. 또한 스튜디오(204)에 플러그인 된 맵퍼(202)는 업무 플로우 구성도에서 연결된 모듈 간에 전달할 데이터의 매핑 관계를 GUI형태로 보여주거나 편집하게 해주는 기능을 수행한다.

또한, 스튜디오(204)는 모듈의 코딩이나 기타 코딩이 필요한 부분에 대한 편집 및 디버깅을 지원하며, 추가적으로 모듈 플로우 디자이너(201), 맵퍼(202) 및 DBIO(203)에 필요한 환경 설정을 가능 하도록 하는 기능을 지원한다.

스튜디오(204)에는 각 툴에 대한 아이콘이 있어서 특정 툴을 직접 띄울 수가 있다. 또한, 각 툴에서 연관되는 다른 툴에 대한 연결 요청 시, 스튜디오(204)에서 이들을 연결해주는 기능을 수행한다. 예를 들어, 모듈 플로우 디자이너(201)에서 모듈 플로우 구성도상의 DBIO 모듈을 더블 클릭하면 DBIO(203)를 띄워서 해당 DBIO 모듈을 편집할 수 있게 해준다.

통합개발엔진(210)은 메타 관리부(211), 소스 생성부(212) 및 인터페이스 관리부(213)를 포함한다.

메타 관리부(211)는 개발에 관련된 메타데이터를 통합적으로 관리하는 기능을 수행한다. 이러한 메타데이터는 통합개발환경(200)에서 개발하는 데에 필요한 다양한 리소스 정보를 포함하며, 그 리소스 정보에는 특히, 모듈 관련 정보, 프로퍼티 정보, 변경 영향도 분석을 위한 의존성 정보 등이 포함된다.

여기서 메타데이터란 소스 코드와 같은 본체 데이터에 관한 구조화된 부가적 데이터를 말하는데, 주로 본체 데이터를 설명해 주는 역할을 하며, 속성정보라고도 불린다. 이러한 메타데이터는 대량의 정보(본체 데이터) 중에서 원하는 정보를 효율적으로 검색 및 이용하기 위해 일정한 규칙에 따라 모듈이나 소스코드와 같은 콘텐츠에 대하여 부여된다. 일반적으로 메타데이터에는 콘텐츠의 위치와 내용, 작성자에 관한 정보, 권리 조건, 이용 조건, 이용 내력 등이 기록되어 있다. 개인용 컴퓨터의 경우에는 본체 데이터를 개략적으로 표현하기 위한 목적과 본체 데이터를 빨리 찾기 위한 목적으로 메타데이터가 사용된다.

데이터를 개략적으로 표현하기 위한 목적으로 사용되는 메타데이터의 예로는 XML 태그가 있다. XML 태그 안에 헤드(head)와 본체(body)가 있는데, 개별 데이터에 해당하는 본체에 부여된 헤드가 상위에서 하위로 나무(tree) 형태의 구조(소위 '데이터의 구조화')를 이루어 전체 데이터를 개략적으로 표현하는 것을 용이하게 한다.

다양한 리소스에 공통적으로 포함되는 주요 메타데이터 정보는 리소스의 물리명, 리소스의 논리명, 리소스의 타입, 리소스의 작성자, 리소스의 권한 정보 등이 있다. 이러한 공통된 정보 외에도 각 리소스는 추가적인 메타데이터 정보를 가질 수 있다. 이 정보는 저장부(220)의 메타데이터 저장부(221)에 저장되어 있는데, 이러한 저장부(220)와 메타데이터 저장부(221)에 대한 사항은 후술하기로 한다.

또한 모듈 플로우를 기반으로 이에 관한 소스를 생성할 때도 관련된 리소스의 메타데이터 정보를 참조하여 그 기반으로 소스 생성부(212)에서 소스를 생성하게 되는데, 이러한 소스 생성부(212)에 관련된 사항은 이하에서 상술하기로 한다.

예컨대, 모듈의 메타데이터 정보는 모듈의 물리명, 모듈의 논리명, 모듈의 타입에 관한 정보(서비스 모듈, 비즈니스 모듈, 플로우 모듈 등과 같은 모듈의 종류에 관한 정보), 모듈의 작성자, 모듈의 권한 정보 등을 포함하고 있다. 모듈의 추가적인 메타데이터 정보로는 그 모듈의 입력 구조체와 출력 구조체 정보 등을 포함한다. 이 정보는 저장부(220)의 메타데이터 저장부(221)에서 필요 모듈의 메타 데이터를 검색할 때에 사용된다. 검색된 모듈의 메타데이터 정보는 모듈 플로우 디자이너(201)에서 드래그 앤 드랍하여 그 모듈을 모듈 플로우 구성도상의 특정 노드에 위치시킬 때도 사용된다. 본 발명의 바람직한 일 실시예에 따르면, 작성된 모듈 플로우를 기반으로 소스를 생성할 때에 소스 생성부(212)는 각각의 모듈에 대한 메타데이터 정보를 이용함으로써 필요한 소스를 자동적으로 생성할 수 있다.

프로퍼티라 함은, 모듈에 수록되어 있는 정보에 관한 것으로서, 예컨대 모듈 을 조합하여 은행에서 사용되는 소프트웨어를 작성하는 경우에, 모듈의 프로퍼티는 입금액, 출금액, 예금주의 성명 또는 예금주의 주민번호 등이 될 수 있다. 프로퍼티 정보는 표준화를 위해 미리 규정한 명명 규칙에 해당하며, 이러한 프로퍼티를 통일적으로 구성함으로써 개발자는 각각의 모듈에 수록되어 있는 정보를 표준화하여 관리할 수 있다.

본 발명의 바람직한 일 실시예에 따른 변경 영향도 분석을 위한 의존성 정보(변경 영향도 분석 정보, 변경 영향도 정보)란, 프로그램의 특정 부분에 변경이 발생 시에, 그 부분을 참조한 각 부분을 모두 추적하여 변경된 사항을 참조했던 곳에 반영하거나 참조한 각 소스를 새로 컴파일하는 것을 가능하게 해주는 정보를 말한다. 예를 들어, 특정 구조체(모듈, 컴포넌트 등)의 한 필드명이 변경될 경우에, 종래에는 그 변경된 구조체를 참조하는 각 소스 또는 모듈을 개발자가 개별적으로 추적하여 변경된 이름이 반영될 수 있도록 해주어야 했고, 이러한 개별적 추적은 유지보수의 비용 및 정확도에 있어 심각한 손실 요인이 되어 왔다. 그러나, 본 발명의 바람직한 일 실시예에 따라 구조체 사이의 관련 정보(의존성 정보)를 메타데이터로 관리하여 전체 프로그램 내에 존재하는 변경 영향도를 분석하고 이를 개발자에게 시각적으로 편리하게 제공하면, 개발자는 변경 영향도 분석 결과를 단순히 참조하는 것만으로도 일부 모듈에 대한 수정 누락을 최소화할 수 있다. 따라서, 프로그램 수행 중에 코어 덤프가 나는 등의 문제가 발생하는 것을 방지할 수 있으므로, 본 발명은 프로그램의 유지보수에 큰 장점을 제공한다.

도 2의 통합개발환경(200)에서 모듈 플로우 등에 관하여 개발자가 개발 내용 을 구성하면, 통합개발환경(200)은 통합개발엔진(210)의 메타 관리부(211)에 개발 내용을 전달한다.

통합개발환경(200)에서 작성되는 개발 내용은 해당 툴에서 취급하는 리소스와 관련된 정보를 포함한다. 예들 들어 DBIO(203)에서 편집하는 DBIO 모듈의 개발 내용은 그 모듈에서 처리하고자 하는 업무를 처리하는 코드 블럭, DB와의 데이터 전달을 위한 구조체, 그 모듈에 대한 이름, 작성자, 권한 등의 메타데이터를 포함한다. 또 하나의 예로, 모듈 플로우 디자이너(201)에서의 개발 내용은 서비스 모듈의 플로우 정보, 서비스 모듈을 구성하는 각 모듈 간의 호출 관계 정보, 모듈 간의 데이터 전달을 위한 데이터 매핑 정보, 일부 직접 작성한 코드 블럭, 서비스 모듈 및 입/출력 구조체에 대한 메타데이터 정보가 포함된다.

메타 관리부(211)에서는 전달받은 개발 내용에서 특정 메타데이터 정보를 추출하여 해당 리소스에 대한 주요 메타데이터 정보를 저장부(220)의 메타데이터 저장부(221)에 저장한다. 또한, 메타 관리부(211)는 전달받은 개발 내용 중 모듈 플로우 구성도 역시 메타데이터화하여 메타데이터 저장부(221)에 저장하며, 전달받은 개발 내용은 저장부(220)의 소스 저장부(222)에 저장된다.

통합개발환경(200)에서 개발자가 리소스의 일정한 키 값(예를 들어, 리소스명, 리소스 타입 등)을 이용하여 특정 리소스에 대하여 검색을 요청하면, 통합개발엔진(210)의 메타 관리부(211)는 통합개발환경(200)에서 전달받은 리소스의 키 값을 이용하여 관련 메타데이터를 검색한다.

이 후 검색된 관련 메타데이터 정보 외에 추가적인 리소스에 대한 정보가 필 요한 경우에는 검색된 관련 메타데이터 정보를 가공함으로써, 필요로 하는 리소스에 대한 메타데이터를 추출하게 된다. 이와 같은 검색 및/또는 가공된 메타데이터 정보는 통합개발환경(200)을 통해 개발자에게 시각적으로 편리하게 제공되며, 개발자는 그 정보를 바탕으로 원하는 작업을 매우 용이하고 정확하게 진행할 수 있다.

메타 관리부(211)는 변경 영향도 분석을 위한 의존성 정보를 저장하게 되는데, 이 의존성 정보의 생성, 저장 및 활용 과정은 다음과 같다.

전술한 바와 같이, 구조체의 필드가 변경이 되면, 그 구조체를 사용한 모듈(상위 모델) 및 그 모듈의 조상 모듈(차상위 모듈)을 모두 찾아내어 변경 사항을 동일하게 반영해주고 컴파일해서 운영 시스템에 반영해 주어야만, 프로그램 수정으로 인한 오류가 발생하지 않는다. 개별 모듈은 다른 다수의 모듈과 무수한 의존성 관계를 맺을 수 있기 때문에, 종래에는 위와 같은 의존성 검색에만도 매우 많은 시간과 노력이 필요했다.

이러한 문제점을 해결하기 위한 본 발명의 바람직한 일 실시예에 따르면, 개발자가 모듈 플로우 디자이너(201)를 이용하여 모듈 플로우 구성도(예를 들어 도 4a의 구성도)를 작성하고 나면, 모듈 플로우 디자이너(201)는 해당 모듈 플로우 구성도의 전체 순서에 대응하는 간단한 리소스를 자동적으로 편집한 후에 통합개발엔진(210)에게 개발 내용(모듈 플로우 구성도의 형상에 대한 리소스 또는 메타데이터, 위 전체 순서에 대응하는 간단한 리소스 등)의 저장을 요청하게 된다. 이 때, 메타 관리부(211)가 위 모듈 플로우 구성도의 리소스 등을 분석하여 각각의 모듈이 갖는 의존성 정보를 생성하고 이를 메타데이터로서 메타 데이터 저장부(221)에 저 장한다. 본 발명의 바람직한 다른 실시예에 따르면, 메타 관리부(211)는 모듈 플로우 구성도의 화면을 직접 인식하고, 해당 모듈 사이의 도식적 관계를 분석하여 메타데이터를 추출할 수도 있다.

위와 같이 모듈별로 저장된 의존성 정보를 순환적으로 검색하여 연관 관계를 구성하다 보면 그 리소스에 관련된 의존성 관계를 모두 파악하여 변경 영향도 정보를 구성할 수 있게 된다. 통합개발환경(200)에서 특정 리소스에 대한 변경 영향도 분석 요청이 발생할 때, 메타 관리부(211)에서는 저장된 의존성 정보에 관한 메타데이터 정보를 추가적으로 가공하여 그 리소스에 대한 변경 영향도 분석 정보를 구성하여 통합개발환경(200)에 넘겨주게 된다. 통합개발환경(200)에서는 그 결과를 시각적으로 편리하게 개발자에게 제공함으로써, 개발자는 해당 리소스뿐만 아니라 그 리소스에 의해 영향 받는 모든 리소스도 같이 수정할 수 있어, 프로그램 실행 시의 오류를 현저하게 감소시킬 수 있게 한다. 이러한 특성은 프로그램의 유지보수성을 현저히 향상시키는 기능을 한다.

도 5는 임의의 모듈들로 이루어진 모듈 플로우 구성도의 일 실시예를 나타내는 개략적인 도면이고, 도 6은 도 5의 관계에서 모듈D에 대한 변경 영향도 정보를 출력해주는 일 실시예에 따른 실제 화면을 도시한다.

본 발명의 바람직한 일 실시예에 따르면, 메타 관리부(211)는 도 5와 같은 모듈 플로우 구성도(또는 그 메타 데이터) 및 그 리소스를 각각 또는 통합적으로 메타데이터화하여 저장하게 된다. 그리고 위 메타데이터를 이용하여 원하는 모듈(또는 리소스)의 변경 영향도 정보를 구성한다.

도 5와 같은 모듈 플로우에서 모듈D를 변경하거나 혹은 모듈 D를 변경하려 한다면, 모듈D의 조상 모듈인 모듈C 및 모듈H와, 모듈C의 조상 모듈인 모듈B, 모듈B의 조상 모듈인 모듈A, 그리고 모듈H의 조상 모듈인 모듈G에도 변경 사항을 반영하거나 반영하는 것을 검토하여야 한다.

이 경우 개발자가 임의의 키 값, 예를 들어 모듈D에 대한 변경 영향도 정보 요청을 하게 되면 도 6과 같은 변경 영향도 정보를 얻을 수 있다. 즉, 모듈D를 직접 참조하는 모듈C(이러한 직접적 의존성은 'Call Depth=1'로 표시), 모듈C를 참조하는 모듈B(Call Depth=2, 이러한 n차적 의존성은 'Call Depth=n'으로 표시), 모듈B를 참조하는 모듈A(Call Depth=3), 모듈D를 참조하는 모듈H(Call Depth=1), 모듈H를 참조하는 모듈G(Call Depth=2)의 메타데이터를 얻게 된다. 본 발명의 바람직한 일 실시예에 따르면, 개발자로 하여금 각 모듈을 마우스의 커서 등으로 더블 클릭 하거나 다른 여러 방법에 의해 각 모듈의 정보를 더욱 자세히 볼 수 있게 하는 GUI가 제공되며, 이러한 GUI를 통해 모듈의 변경 또는 수정이 훨씬 용이하게 된다. 위 GUI의 예로는 윈도우 형태의 팝업이나 고정적으로 제공되는 스크롤 형태로 모듈 수정창을 들 수 있다.

위 예에서는 특정 모듈들 간의 변경 영향도 정보를 예로 들었지만 이는 모듈과 모듈 사이뿐만 아니라 클래스, 태스크, 프로세스, 함수, 속성, 프로시저 등 여러 구성 요소 사이에도 적용 가능할 것이다.

통합개발환경(200)에서 특정 리소스에 대한 변경 영향도 분석을 요청하면, 메타 관리부(211)에서는 필요한 변경 영향도 정보를 구성하여 통합개발환경(200)에 넘겨주게 된다. 통합개발환경(200)에서는 그 결과를 개발자에게 시각적으로 편리하게 제공함으로써 개발자는 해당 리소스뿐만 아니라 그 리소스에 의해 영향 받는 모든 리소스도 같이 수정할 수 있어, 프로그램 실행 시의 오류를 최소화할 수 있게 한다. 이러한 특성은 프로그램의 유지보수성을 현저히 향상시키는 기능을 한다.

소스 생성부(212)는 통합개발환경(200)에서 현재 작성된 모듈 플로우 구성도에 해당하는 개발 내용에 따르는 소스를 생성해 달라는 요청이 있는 경우에 해당하는 소스를 생성한다.

통합개발환경(200)의 요청이 있으면, 소스 생성부(212)에서는 전달받은 개발 내용을 분석하여 각 리소스에 관련되는 메타데이터 정보를 메타데이터 저장부(221)에서 가져와 필요한 정보를 추가하여 소스를 생성한다. 이렇게 생성된 소스는 저장부(220)의 소스 저장부(222)에 저장된다. 통합개발환경(200)에서 컴파일 요청이 오게 되면, 통합개발엔진(210)에서는 소스 저장부(222)에서 관련 소스를 가져와 컴파일하여 목적(object) 코드를 생성하게 된다.

인터페이스 관리부(213)는 외부 리소스(또는 모듈)를 사용하기 위한 인터페이스를 제공한다. 예를 들어, 서비스 모듈의 플로우를 구성하는데 있어서, 외부 툴(예를 들어, 룰 매니져)에 의해 개발된 외부 모듈(예를 들어, 룰 모듈)을 사용하게 될 경우, 인터페이스 관리부(213)가 외부 모듈에 대한 필요한 정보를 가져다 사용할 수 있도록 한다. 또한, 개발자가 서비스 모듈 플로우를 구성하던 중, 외부 툴에서 개발된 외부 모듈(예를 들어, 룰 모듈)을 드래그 앤 드랍하여 가져다 사용할 때, 인터페이스 관리부(213)가 그 외부 툴에서 제공하는 모듈의 메타데이터 정 보를 획득하여 통합개발환경(200)에 제공한다. 통합개발환경(200)은 인터페이스 관리부(213)에서 제공한 외부 모듈의 메타데이터 정보를 개발자의 요청에 따라 시각적으로 제공할 수 있고, 개발자는 이를 통해 외부 모듈의 사용 안정성을 확보할 수 있다. 또한, 위 메타데이터 정보는 메타데이터 저장부(221)에 저장되어, 소스 생성부(213)가 외부 모듈에 대한 소스를 생성하는 것을 돕는다.

저장부(220)는 일정한 정보를 기억할 수 있는 하드디스크, ROM(Read Only Memerory), RAM(Random Access Memory) 등에 해당하며, 메타데이터 저장부(221) 및 소스 저장부(222)를 구비한다.

메타데이터 저장부(221)에는 본 발명의 바람직한 실시예에 따른 의존성 정보를 포함하여 유용한 모든 메타데이터가 저장된다. 메타데이터에 관하여는 상술한 메타 관리부(211)에 대한 설명에서 기술한 바 있으므로, 여기에서는 자세한 설명을 생략하기로 한다.

소스 저장부(222)에서는 상술한 소스 생성부(212)에서 생성된 소스가 저장된다. 이러한 소스에 관하여는 소스 생성부(212)에 관한 설명에서 상세히 다룬 바 있으므로, 여기에서는 자세한 설명을 생략하기로 한다.

이상 설명한 내용을 통해 당업자라면 본 발명의 기술사상을 일탈하지 아니하는 범위에서 다양한 변경 및 수정이 가능함을 알 수 있을 것이다. 따라서, 본 발명의 기술적 범위는 명세서의 상세한 설명에 기재된 내용으로 한정되는 것이 아니라 특허 청구의 범위에 의하여 정하여져야만 한다.

도 1은 본 발명의 일 실시예에 따른 재사용 가능한 모듈을 이용하는 소프트웨어 개발 시스템의 운영을 개념적으로 나타내는 개략도이다.

도 2는 본 발명의 일 실시예에 따른 재사용 가능한 모듈을 이용하는 소프트웨어 개발 시스템의 블록도이다.

도 3은 본 발명의 일 실시예에 따른 서비스를 구성하는 모듈들의 모듈 플로우를 나타내는 개략도이다.

도 4a는 본 발명의 일 실시예에 따른 입급 서비스 모듈의 모듈 플로우를 나타내는 모듈 플로우 디자이너의 개략적인 출력화면이다.

도 4b는 본 발명의 일 실시예에 따른 지급 서비스 모듈의 모듈 플로우 구성도를 나타내는 도면이다.

도 4c는 본 발명의 일 실시예에 따른 이체 서비스 모듈의 모듈 플로우 구성도를 나타내는 도면이다.

도 5는 특정 모듈들의 의존성 관계의 일 예를 나타낸 개략도이다.

도 6은 도 5 관계의 특정 모듈에 대한 의존성 정보를 출력해주는 일 실시예이다.

<도면의 주요 부분에 대한 부호의 설명>

200 : 통합개발환경 201 : 모듈 플로우 디자이너

202 : 맵퍼 203 : DBIO

204 : 스튜디오 210 : 통합개발엔진

211 : 메타 관리부 212 : 소스 생성부

213 :인터페이스 관리부 220 : 저장부

221 : 메타데이터 저장부 222 : 소스 저장부

Claims (8)

1. 개발자가 단위 업무를 실행하는 적어도 하나의 단말 모듈을 시각적으로 배치하여 서비스 모듈을 작성할 수 있게 하는 소프트웨어 개발 시스템에 있어서,

   적어도 하나의 단말 모듈을 구비한 서비스 모듈의 모듈 플로우 구성도를 생성하는 모듈 플로우 디자이너와,

   상기 모듈 플로우 구성도에 따라 상기 서비스 모듈의 소스코드를 생성하는 소스 생성부와,

   상기 서비스 모듈의 메타데이터를 분석하는 메타 관리부와,

   외부 모듈을 상기 단말 모듈로 사용할 수 있게 하는 인터페이스 관리부와,

   상기 서비스 모듈의 메타데이터를 저장하는 메타데이터 저장부를 포함하며,

   상기 메타 관리부는 상기 모듈 플로우 구성도의 메타데이터를 이용하여 상기 서비스 모듈의 메타데이터를 생성하는

   소프트웨어 개발 시스템.
2. 제 1 항에 있어서,

   상기 메타 관리부는 상기 모듈 플로우 구성도의 메타데이터를 이용하여 상기 서비스 모듈의 메타데이터를 생성하고, 또한 상기 서비스 모듈의 메타데이터를 이용하여 상기 서비스 모듈이 구비한 적어도 하나의 단말 모듈의 변경 영향도 정보를 생성하며, 상기 변경 영향도 정보를 상기 단말 모듈의 메타데이터의 일부로서 상기 메타데이터 저장부에 저장하는 것을 특징으로 하는

   소프트웨어 개발 시스템.
3. 제 1 항에 있어서,

   상기 소스 생성부는 상기 서비스 모듈의 메타데이터 정보를 참조하여 상기 소스를 생성하는 것을 특징으로 하는

   소프트웨어 개발 시스템.
4. 삭제
5. 제 1 항에 있어서,

   상기 단말 모듈은 재사용 가능한 단말 모듈인 것을 특징으로 하는

   소프트웨어 개발 시스템.
6. 제 1 항에 있어서,

   상기 단말 모듈의 메타데이터 또는 상기 서비스 모듈의 메타데이터를 개발자에게 시각적으로 제공할 수 있는 수단을 더 포함하는 것을 특징으로 하는

   소프트웨어 개발 시스템.
7. 삭제
8. 삭제

Images