KR101445666B1 - 소프트웨어 개발을 위한 워크벤치 구성 방법 및 이를 이용한 장치 - Google Patents

Abstract

소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법 및 장치에 관한 기술이 개시된다. 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법은, 개발 소프트웨어에 대한 고객의 요구사항을 분석하여 요구사항 분석정보를 산출하는 요구사항 분석단계와, 기존 소프트웨어를 분석하여 개발 소프트웨어와의 공통점과 차이점에 대한 정보를 포함하는 레거시 분석정보를 산출하는 레거시 분석단계와, 요구사항 분석정보 및 레거시 분석정보에 기반한 도메인 분석을 통하여 도메인 분석정보를 산출하는 도메인 분석단계와, 도메인 분석정보를 이용하여 아키텍처를 설계하는 아키텍처 설계단계와, 아키텍처에 기반하여 컴포넌트를 개발하는 컴포넌트 개발단계를 포함한다.

Description

소프트웨어 개발을 위한 워크벤치 구성 방법 및 이를 이용한 장치{METHOD OF CONSTRUCTING WORKBENCH FOR SOFTWARE DEVELOPMENT AND APPARATUS USING THE SAME}

본 발명은 소프트웨어 개발에 관한 것으로, 더욱 상세하게는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법 및 장치에 관한 것이다.

본 발명은 "정보통신산업진흥원의 SW공학 요소기술 연구개발사업 및 한국과학재단을 통한 교육과학기술부의 세계수준의 연구중심대학육성사업(WCU)에 의해 지원되었음"을 밝힙니다.

소프트웨어 기업은 고객의 요구에 맞는 소프트웨어들을 빨리 그리고 많이 내놓고자 제품당 시장진출시간(time to market)을 단축시킴과 동시에 소프트웨어의 품질을 높여야 하는 이중고에 시달리고 있다.

이를 해결하기 위해 소프트웨어 제품라인 공학(software product line engineering)은 하나의 제품을 개발하기 위한 프로세스가 아니라 제품라인을 개발하기 위한 새로운 패러다임을 제시하고 있다. 즉, 소프트웨어 제품라인 방법론을 통하여 소프트웨어를 개발하면, 제품라인의 공통적인 부분과 차이점을 핵심자산(core asset)으로 관리하여 품질을 높이고 핵심자산을 계획된 제품들에 재사용함으로써 재사용성을 보장 받을 수 있다.

그러나 소프트웨어 제품라인 공학을 도입하려면 하나의 소프트웨어를 만드는 것보다 초기 도입비용(up-front cost)이 크고, 시간이 오래 걸릴 수 있다. 또한 기존의 제품들을 가진 기업들은 기존의 제품들에 제품라인을 적용하기를 꺼릴 수 있는 문제점이 있다.

이러한 문제점을 해결하기 위하여 소프트웨어 제품라인의 추출식 접근법(extractive approach)이 논의되고 있다. 추출식 접근법은 기존 제품을 기반으로 제품라인의 핵심자산(core asset)을 개발하는 것으로, 제품라인을 적용 하려고 하는 범위 내의 제품들을 분석하여 공통점과 차이점을 찾아내는 역 공학(reverse engineering)과 제품라인을 핵심자산으로 만들기 위한 리팩토링(refactoring)과정으로 이루어져 있다.

추출식 접근법을 이용한 핵심자산의 개발은 소프트웨어 제품라인의 자산을 위해 기존 제품을 재사용할 수 있다. 즉, 추출식 접근법을 이용한 핵심자산의 개발은 기존 제품을 재사용하지 않고 소프트웨어를 개발하는 것보다 초기 개발비용과 시간을 크게 절약할 수 있고 기존의 자산을 활용할 수 있다는 측면에서 최근에 주목을 받고 있다.

소프트웨어 개발에 있어서, CASE(computer aided software engineering) 도구의 사용은 개발과정의 단순 작업을 자동화해 줌으로써 개발비용과 시간을 크게 줄여줄 수 있다. 특히 방법론을 전체적으로 관리해주고 지원해주는 역할을 하는 관리도구인 "워크벤치(workbench)"는 개발 과정 전체를 관리하고 도와주어 소프트웨어 개발을 효과적으로 지원할 수 있다.

그러나 현재 이러한 추출식 접근법을 효과적으로 지원하는 워크벤치가 없는 실정이다.

상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, 소프트웨어 제품라인의 추출식 접근법을 지원하는 워크벤치를 구성하는 방법을 제공하는데 있다.

상기와 같은 문제점을 해결하기 위한 본 발명의 다른 목적은, 소프트웨어 제품라인의 추출식 접근법을 지원하는 워크벤치를 구성하는 장치를 제공하는데 있다.

상기 목적을 달성하기 위한 본 발명의 일 측면에 따른 워크벤치 구성 방법은, 개발 소프트웨어에 대한 고객의 요구사항을 분석하여 요구사항 분석정보를 산출하는 요구사항 분석단계와, 기존 소프트웨어를 분석하여 개발 소프트웨어와의 공통점과 차이점에 대한 정보를 포함하는 레거시 분석정보를 산출하는 레거시 분석단계와, 요구사항 분석정보 및 레거시 분석정보에 기반한 도메인 분석을 통하여 도메인 분석정보를 산출하는 도메인 분석단계와, 도메인 분석정보를 이용하여 아키텍처를 설계하는 아키텍처 설계단계와, 아키텍처에 기반하여 컴포넌트를 개발하는 컴포넌트 개발단계를 포함한다.

여기에서, 상기 워크벤치 구성 방법은, 요구사항 분석정보, 도메인 분석정보, 아키텍처 중 적어도 하나를 포함하는 자산을 관리하는 자산 관리단계를 더 포함할 수 있다.

여기에서, 상기 워크벤치 구성 방법은, 자산에 기반하여 개발 소프트웨어에 대한 고객의 요구사항에 상응하는 소프트웨어를 개발하는 제품형상 관리단계를 더 포함할 수 있다.

여기에서, 상기 요구사항 분석단계는, 개발 소프트웨어에 대한 고객의 요구사항의 변경이력을 저장할 수 있다.

여기에서, 상기 레거시 분석단계는, 객체 설계복원, 프로세스 설계복원, 가변성 분석, 설계품질 평가 중 적어도 하나를 수행하여 기존 소프트웨어를 분석할 수 있다.

여기에서, 상기 도메인 분석단계는, 컨텍스트 모델링, 도메인 오브젝트 모델링, 가변성 모델링 중 적어도 하나를 수행하여 도메인 분석정보를 산출할 수 있다.

여기에서, 상기 아키텍처 설계단계는, 도메인 분석정보를 이용하여 개념적 아키텍처, 프로세스 아키텍처, 컴포넌트 아키텍처, 배치 아키텍처 중 적어도 하나를 포함하는 아키텍처를 산출할 수 있다.

여기에서, 상기 컴포넌트 개발단계는, 소스코드에 대한 편집, 리팩토링, 표준화를 수행할 수 있다.

상기 목적을 달성하기 위한 본 발명의 다른 측면에 따른 워크벤치 구성 장치는, 개발 소프트웨어에 대한 고객의 요구사항을 분석하여 요구사항 분석정보를 산출하는 요구사항 분석부와, 기존 소프트웨어를 분석하여 개발 소프트웨어와의 공통점과 차이점에 대한 정보를 포함하는 레거시 분석정보를 산출하는 레거시 분석부와, 요구사항 분석정보 및 레거시 분석정보에 기반한 도메인 분석을 통하여 도메인 분석정보를 산출하는 도메인 분석부와, 도메인 분석정보를 이용하여 아키텍처를 설계하는 아키텍처 설계부와, 아키텍처에 기반하여 컴포넌트를 개발하는 소스코드 개발부를 포함한다.

여기에서, 상기 워크벤치 구성 장치는, 공개도구들과 COTS컴포넌트를 포함하는 지원도구들을 합병할 수 있다.

여기에서, 상기 워크벤치 구성 장치는, 소프트웨어 개발을 위한 CASE 도구인 통합 개발환경(IDE)에 공개도구들과 COTS 컴포넌트를 포함하는 지원도구들을 병합할 수 있다.

여기에서, 상기 워크벤치 구성 장치는, 플러그인(plug-in) 가능한 공개도구 또는 COTS컴포넌트들을 이용해 워크벤치를 구성할 수 있다.

상기와 같은 본 발명의 실시예에 따른 워크벤치 구성 방법 및 그 장치를 이용할 경우에는, 소프트웨어 제품라인의 추출식 접근법을 지원하기 위한 워크벤치 구성 방법을 통해 실제 워크벤치 개발을 하기 위한 가이드 라인을 제공할 수 있다.

또한, 워크벤치 구현을 통해 지원도구 부재로 인해 소프트웨어 제품라인을 도입을 주저하던 기업들이 소프트웨어 제품라인을 효율적으로 적용할 수 있는 장점이 있다.

도 1은 본 발명의 실시예에 따른 워크벤치 모델을 추출식 접근법의 각 단계를 중심으로 모델화한 개념적 모델에 대한 개념도이다.
도 2는 본 발명의 실시예에 따른 워크벤치 모델의 각 기능을 담당하는 컴포넌트와 컴포넌트 간의 관계를 나타내는 워크벤치의 물리적 모델에 대한 블록도이다.
도 3은 본 발명의 실시예에 따른 요구사항 분석부의 기능을 설명하는 개념도이다.
도 4는 본 발명의 실시예에 따른 도메인 분석부의 기능을 설명하는 개념도이다.
도 5는 본 발명의 실시예에 따른 아키텍처 설계부의 기능을 설명하는 개념도이다.
도 6은 본 발명의 실시예에 따른 소스코드 개발부의 기능을 설명하는 개념도이다.
도 7은 본 발명의 실시예에 따른 자산 관리부의 기능을 설명하는 개념도이다.
도 8은 본 발명의 실시예에 따른 제품형상 관리부의 기능을 설명하는 개념도이다.
도 9는 본 발명의 실시예에 따른 테스트부의 기능을 설명하는 개념도이다.
도 10은 본 발명의 실시예에 따른 레거시 분석부의 기능을 설명하는 개념도이다.
도 11은 본 발명의 실시예에 따른 워크벤치 구성 방법에서 지원도구들을 수동적으로 합병하는 것을 나타내는 개념도이다.
도 12는 본 발명의 실시예에 따른 워크벤치 구성 방법에서 통합 개발환경에 수동적으로 합병하는 것을 나타내는 개념도이다.
도 13은 본 발명의 실시예에 따른 워크벤치 구성 방법에서 플러그인 아키텍처를 이용한 구성을 나타내는 개념도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

본 발명에 따른 워크벤치는 소프트웨어 제품라인의 추출식 접근법을 수행하기 위해 방법론 프로세스 전반에 걸친 모든 작업과 관리를 지원하는 도구를 의미할 수 있다.

본 발명은 소프트웨어 제품라인의 추출식 접근법을 위한 워크벤치의 개념적, 물리적 모델 및 워크벤치의 구성 방법을 제공한다.

도 1은 본 발명의 실시예에 따른 워크벤치 모델을 추출식 접근법의 각 단계를 중심으로 모델화한 개념적 모델에 대한 개념도이다.

도 1을 참조하면, 워크벤치의 개념적 모델은 소프트웨어 제품라인 방법론과 추출식 접근법 프로세스 분석을 통한 모델로, 워크벤치 모델을 추출식 접근법의 각 단계를 중심으로 모델화한 것이다.

본 발명의 실시예에 따른 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법은 요구사항 분석단계(S100), 레거시 분석단계(S200), 도메인 분석단계(S300), 아키텍처 설계단계(S400), 컴포넌트 개발단계(S500), 자산 관리단계(S600), 제품형상 관리단계(S700) 및 테스트 단계(S800)를 포함할 수 있다.

요구사항 분석단계(S100)에 따른 요구사항 분석정보는 테스트 케이스의 작성을 위한 테스트 단계(S800)와 도메인 분석을 위한 도메인 분석단계(S300)로 보내진다.

레거시 분석단계(S200)는 기존 제품들을 분석한 레거시 분석정보를 도메인 분석단계(S300)로 보낼 수 있다.

도메인 분석단계(S300)를 통한 도메인 분석정보는 아키텍처 설계를 위한 정보가 되고, 아키텍처 설계단계(S400)의 아키텍처는 컴포넌트 개발단계(S500)에서 활용된다.

자산 관리단계(S600)는 요구사항 분석단계(S100)의 요구사항 분석정보(요구사항 명세), 도메인 분석 단계의 도메인 분석정보(도메인 모델들), 아키텍처 설계단계(S400)의 설계도 및 컴포넌트 개발단계(S500)의 컴포넌트들과 같은 자산을 관리의 대상으로 한다.

제품형상 관리단계(S700)는 자산관리 단계의 정보를 기반으로 제품형상 관리를 수행한다.

상술한 각 단계를 더욱 상세하게 설명하면 아래와 같다.

요구사항 분석단계(S100)는 크게 요구사항 명세기능과 요구사항 버전관리기능을 수행할 수 있다. 요구사항 명세는 방법론이나 프로젝트마다 그 항목이 달라질 수 있고, 상황에 따라 정형명세를 요구할 수 있다. 즉, 요구사항 명세기능을 담당하는 컴포넌트는 워크벤치를 구성하고자 하는 사용자에 의해서 바뀌어질 가능성이 높다.

요구사항 버전관리기능은 요구사항의 변경이력(history)을 기록하는 것에 상응할 수 있다. 고객의 요구사항은 개발 중 또는 제품이 나온 이후에도 변경될 수 있다. 이러한 고객의 요구사항의 변화를 데이터로 남기는 것은 소프트웨어의 유지보수 관점에서 매우 중요하다. 특히 소프트웨어 제품라인에서는 여러 개의 소프트웨어를 관리하기 때문에 제품의 요구사항 변화에 따른 자산의 변화에 민감하여야 한다.

레거시 분석단계(S200)는 추출식 접근법에서만 존재하는 단계로 기존의 제품들을 분석하여 시스템의 구조를 파악하고 제품들을 제품라인화 하기 위해 제품의 공통점과 차이점을 분석할 수 있으며, 제품라인의 자산으로 변경할 대상을 선정할 있다.

따라서, 레거시 분석단계(S200)는 객체 설계복원, 프로세스 설계복원, 가변성 분석, 설계품질 평가 등의 기능을 수행하는 것이 필요하다.

객체 설계복원은 소스코드로부터 클래스 다이어그램(class diagram)으로 역 공학하여 소스코드 전체를 보지 않고 소프트웨어의 정적인 구조를 분석하려는 것이다.

프로세스 설계복원은 소스코드로부터 호출과 반환(call and return)관계를 보여주거나 혹은 시퀀스 다이어그램(sequence diagram)으로 변환하는 기능을 수행할 수 있다.

설계품질 평가는 소프트웨어 공학에서 소스코드의 품질을 평가하기 위한 대표적인 메트릭(metric)을 이용하여 소스코드의 품질을 평가할 수 있다.

가변성 분석은 제품들의 소스코드를 비교하여 공통점과 차이점을 가려낼 수 있고, 이를 기반으로 제품라인의 공통자산 부분과 가변적인 부분을 찾아 가변성 모델링에 도움을 줄 수 있다.

도메인 분석단계(S300)는 컨텍스트 모델링, 도메인 오브젝트 모델링, 가변성 모델링의 기능을 수행할 수 있다.

대부분의 도구에서는 가변성 모델링 한가지만을 제공하고 있었지만 소프트웨어를 개발하는 환경에 따라 다른 도메인 모델링 기능을 제공해야 하는 경우를 대비하여 몇 개의 지원도구들은 다른 도메인 모델링 기능을 제공하고 있었다.

도메인 분석단계(S300)에서 가변성 모델링을 위한 기능만 제공하는 것은 개발 시 다른 도메인 모델을 사용해야 하는 환경에서 그 모델링 기능을 갖춘 도구를 이용할 수밖에 없는 문제점이 있다. 이는 워크벤치의 정의에 어긋나기 때문에 가변성 모델링 이외에도 대표적인 도메인 모델링을 도메인 분석단계(S300)에 추가할 수 있다.

컨텍스트 모델은 제품들과 외부개체들 간의 관계를 나타내는 모델로 도메인의 영역이 확연하게 드러나는 모델이고, 도메인 오브젝트 모델은 시스템의 정적인 구조를 나타내는 모델로 구현을 위한 컴포넌트 아키텍처의 초석이 될 수 있다.

가변성 모델은 제품 간의 공통점과 차이점을 분석하는 모델이다.

또한, 상술한 모든 모델링 기능에서는 각 모델을 그리고 또 그 모델의 개체와 관계를 명세하는 기능을 제공할 수 있다.

아키텍처 설계단계(S400)는 개념적 아키텍처, 프로세스 아키텍처, 컴포넌트 아키텍처, 배치 아키텍처 등 네 가지의 대표적인 아키텍처를 제공할 수 있다.

개념적 아키텍처는 시스템의 개념적 구조를 설계하고, 프로세스 아키텍처는 시스템의 흐름에 대하여 설계할 수 있다. 컴포넌트 아키텍처는 구현을 위한 설계이고, 배치 아키텍처는 위의 소프트웨어 설계를 컴포넌트 아키텍처를 기반으로 물리적인 기계(machine)의 어떠한 컴포넌트를 수행하게 하는가를 결정할 수 있다.

컴포넌트 개발단계(S500)는 시스템의 구현단계에서 필요한 기능들을 포함할 수 있다.

소스코드 편집은 소프트웨어를 개발하기 위해 소스코드를 작성하는데 도움을 주는 기능을 수행할 수 있다.

리팩토링은 기존 제품들의 소스코드를 제품라인 자산화하는 과정에서 소스코드를 리팩토링하는데 사용될 수 있다.

소스코드 생성은 특정 모델에서 소스코드로 변환되는 것을 의미하는 것으로, 예를 들면, 컴포넌트 아키텍처 설계를 기반으로 객체의 스켈레톤 코드(skeleton code)를 생성할 수 있다. 이러한 기능은 필수적인 기능은 아니지만 설계에서 구현으로 넘어가는 과정에서 기계적인 작업을 줄여주어 개발의 속도를 높일 수 있다.

소스코드 표준화는 소프트웨어를 개발할 때 작성하는 소스코드 작성 기준을 통일하는 것을 의미한다. 소스코드 표준화를 할 경우, 자신이 개발하지 않은 부분을 같은 프로젝트를 수행하고 있는 다른 사람들이 쉽게 소스코드를 이해할 수 있도록 한다.

자산 관리단계(S600)는 자산 명세와 자산 간의 관계를 설정하는 기능을 수행한다. 자산 명세를 설정하는 기능은 앞에서 개발된 자산들을 관리하기 위한 단위로 나누고 이를 명세할 수 있다. 자산 간의 관계를 설정하는 기능은 자산 간의 추적성을 위한 것이다. 이러한 기능은 자산을 관리하는 데 큰 도움이 되며 소프트웨어 제품라인의 유지 보수에도 큰 도움이 된다.

제품형상 관리단계(S700)는 앞에서 구성한 제품라인의 자산을 토대로 사용자가 원하는 휘처들을 선택하여 그 휘처들을 만족하는 제품을 생성할 수 있다.

제품형상 관리를 위하여 제품생성 및 가변성 모델과의 동기화의 기능을 수행할 수 있다.

예를 들어, 제품생성은 휘처 모델(Feature Model)에서 원하는 휘처들을 선택하면 그 휘처에 해당하는 구현 컴포넌트를 기반으로 매크로 프로세싱(macro processing)을 통하여 제품을 생성할 수 있다.

여기서, 제품을 생성하는 방식은 매크로 프로세싱을 이용하였지만 패키지 합병 메커니즘(package merge mechanism)과 부분클래스(partial class)를 이용한다면 단순히 패키지의 선택으로도 수행 가능하다.

가변성 모델과의 동기화는 가변성 모델에서의 휘처 선택이 제품 형상관리에 그대로 반영되도록 항상 동기화를 이루어야 하는 것을 의미한다. 그렇지 않다면 가변성 모델에서 선택한 휘처들을 제품 생성단계에서 신뢰할 수 없게 된다.

테스트 단계(S800)는 개발과정의 여러 곳에서 수행되는 단계로써 테스트 케이스 관리, 가변성 모델 검증, 제품형상 관리검증, 단위 테스트의 기능을 수행하는 것이 필요하다.

테스트 케이스(test case)관리는 요구사항을 기반으로 테스트 케이스를 명세하고, 테스트 수행결과를 기록하여 테스트를 체계적으로 관리하기 위한 기능을 수행한다. 가변성 모델 검증과 제품형상 관리검증은 각 단계에서 사용하는 두 기능의 유효성을 검증할 수 있다. 단위 테스트는 각 컴포넌트가 제품을 구성하기 이전에 그 컴포넌트의 기능을 모두 정상적으로 수행하는지를 점검하기 위한 테스트이다.

도 2는 본 발명의 실시예에 따른 워크벤치 모델의 각 기능을 담당하는 컴포넌트와 컴포넌트 간의 관계를 나타내는 워크벤치의 물리적 모델에 대한 블록도이다.

워크벤치의 개념적 모델을 통해 추출식 접근법을 지원하기 위한 워크벤치의 기능들에 대하여 상술하였다.

도 2를 참조하여, 워크벤치의 구현적 측면을 고려한 물리적 모델을 제시함으로써 워크벤치를 구체화한다.

물리적 모델은 각 기능을 담당하는 컴포넌트와 컴포넌트 간의 관계를 설명한다.

요구사항 분석부(100)(Requirements Manager)는 요구사항에 대한 분석을 수행하고,

도메인 분석부(200)(Domain Model Component)는 도메인 오브젝트 모델 편집부(210)(Domain Object Model Editor), 컨텍스트 모델 편집부(220)(Context Model Editor), 가변성 모델 편집부(230)(Variability Model Editor)를 포함한다.

특히, 가변성 모델 편집부(230)는 feature, variant, decision 등 가변성 모델링 방법에 따라 그 모델의 매니저가 바뀔 수 있다. 예를 들어, 휘처 기반의 모델링을 위해서는 휘처 모델 편집부(Feature Model Editor)를 사용할 수 있다.

아키텍처 설계부(300)(Architecture Design Component)는 아키텍처의 설계 기능을 수행한다. 아키텍처 설계부(300)는 아키텍처 설계에서 지원하는 네 개의 아키텍처를 지원하기 위하여 개념 관점 편집부(310)(Conceptual View Editor), 프로세스 관점 편집부(320)(Process View Editor), 컴포넌트 관점 편집부(330)(Component View Editor), 개발 관점 편집부(340)(Deployment View Editor)를 포함하여, 다른 아키텍처가 필요하다면 해당 아키텍처 편집부를 아키텍처 설계부(300)에 등록하여 사용하는 방법으로 구현될 수 있다. 이는 개발하고자 하는 소프트웨어에 따라 요구되는 아키텍처 종류가 달라질 수 있으며, 이러한 방법을 이용하면 워크벤치에 아키텍처를 추가하는 부담을 줄일 수 있다.

소스코드 개발부(600)(Source Code Development Component)는 컴포넌트 개발을 지원하고, 컴포넌트 생성부(610)(Component Generator), 소스코드 편집부(640)(Source Code Editor), 리팩토링 관리부(630)(Refactoring Manager) 및 소스코드 표준화 관리부(620)(Source Code Standardization Manager)를 포함한다.

자산 리포지터리(500)(Asset Repository)는 자산 관리부(510)(Asset Manager)및 자산 저장부(520)를 포함하고, 자산 저장부(520)는 자산들(요구사항, 도메인 분석정보, 아키텍처 등)을 저장할 수 있다. 여기서, 자산 관리부(510)는 자산들의 관리를 수행할 수 있다.

제품형상 관리부(700)(Product Form Management Component)는 제품의 형상을 관리한다. 제품형상 관리부(700)는 컨피그레이션 관리부(710)(Configuration Manager), 제품 생성부(730)(Product Generator) 및 컨피그레이션 관리 검증부(720)(Configuration Management Validator)를 포함하여 구성될 수 있다.

테스트부(900)(Test Component)는 테스트 관리부(920)(Test Manager) 및 유닛 테스트 관리부(910)(Unit Test Manager)를 포함하여 구성되며 테스트 단계(S800)를 수행할 수 있다.

레거시 분석부(400)(Legacy Analysis Component)는 리버스 시퀀스 다이어그램 변환부(410)(Reverse Seq. Diagram Converter), 리버스 클래스 다이어그램 변환부(420)(Reverse Class Diagram Converter), 메트릭 관리부(440)(Metric Manager), 차이 관리부(430)(Diff Manager)를 포함하여 구성될 수 있으며, 추출식 접근법을 위한 기능에 기반하여 레거시를 분석할 수 있다.

상술한 바와 같이 물리적 모델은 개념적 모델의 단계를 통하여 설명될 수 있다. 실제로 워크벤치를 구현하기 위해서, 개념적 모델에서 제안한 기능들을 처리하는 방법과 물리적인 데이터 처리 과정이 필요하다.

도 3은 본 발명의 실시예에 따른 요구사항 분석부(100)의 기능을 설명하는 개념도이다.

도 3을 참조하면, 요구사항 분석부(100)는 상술한 개념적 모델에서 언급한 요구사항 관리의 요구사항 명세와 버전 관리를 지원할 수 있고, 이러한 요구사항은 자산 관리부(510)를 통하여 자산 리포지터리(500)에 저장되어 다른 자산들과 함께 관리될 수 있다.

도 4는 본 발명의 실시예에 따른 도메인 분석부(200)의 기능을 설명하는 개념도이다.

도 4를 참조하면, 도메인 오브젝트 모델 편집부(210)는 도메인 오브젝트 모델을 관리하고 도메인 오브젝트 모델을 그릴 수 있도록 하는 컴포넌트이고, 컨텍스트 모델 편집부(220)는 컨텍스트 모델을 관리하고 컨텍스트 모델을 그리기 위한 컴포넌트이다.

또한, 가변성 모델 편집부(230)는 소프트웨어 제품라인의 가변성을 모델링하기 위한 컴포넌트이다. 컴포넌트는 어떤 방법론을 사용하는가에 따라 그 가변성 모델이 바뀌게 되고 같은 휘처모델이라 하더라도 방법론에 따라 확장된 휘처모델이 존재하므로 그 휘처모델을 따라 휘처모델 컴포넌트를 만들 수 있다.

가변성 모델 검증부(800)(Variability Model Validator)는 가변성 모델의 유효성을 검증하는 컴포넌트로 가변성 모델의 제약사항(constraints)들이 그 가변성 모델에 위배되지 않는지를 검증할 수 있다. 가변성 모델 검증부(800)는 가변성 모델 편집부(230)와 마찬가지로 앞에서 선정한 가변성 모델의 검증부(Validator) 짝을 맞추어 이용할 수 있다.

도 5는 본 발명의 실시예에 따른 아키텍처 설계부(300)의 기능을 설명하는 개념도이다.

도 5를 참조하면, 아키텍처 설계부(300)는 각각의 아키텍처에 대한 설계를 관리하기 위한 컴포넌트로 프로젝트에서 소프트웨어를 설계하기 위한 아키텍처의 컴포넌트를 통하여 워크벤치를 구성할 수 있도록 한다.

추출식 접근법을 위한 워크벤치에서는 대표적인 4개의 아키텍처를 예를 들어 아키텍처 설계단계(S400)를 수행할 수 있다.

본 발명에서 제안한 개념적 아키텍처, 프로세스 아키텍처, 컴포넌트 아키텍처, 배치 아키텍처를 지원하기 위한 개념 관점 편집부(310), 프로세스 관점 편집부(320), 컴포넌트 관점 편집부(330), 개발 관점 편집부(340)에 대하여 더욱 상세히 설명한다.

개념 관점 편집부(310)는 시스템을 기능들을 기반으로 설계하기 위한 컴포넌트로 개념적 아키텍처를 그리기 위한 편집기와 이를 관리해야 하는 부분으로 나누어져 있다. 저장은 위의 다른 모델들과 마찬가지로 XSD와 XML을 이용하여 저장하고 데이터를 교환하는 방식을 사용한다.

프로세스 관점 편집부(320)는 시스템을 데이터의 흐름에 기반을 두어 설계하기 위한 컴포넌트로 프로세스 아키텍처를 그리기 위한 편집기와 이를 관리해야 하는 부분으로 나누어져 있다. 저장은 위의 다른 모델들과 마찬가지로 XSD와 XML을 이용하여 저장하고 데이터를 교환하는 방식을 사용한다.

컴포넌트 관점 편집부(330)는 시스템을 구현을 고려한 객체기반으로 설계하기 위한 컴포넌트로 도메인 분석단계(S300)의 도메인 객체 모델(domain object mode)을 참조하여 컴포넌트 아키텍처를 그리기 위한 편집기와 이를 관리해야 하는 부분으로 나누어져 있다. 저장은 위의 다른 모델들과 마찬가지로 XSD와 XML을 이용하여 저장하고 데이터를 교환하는 방식을 사용한다. 또한, 기존의 레거시에서 추출한 클래스 다이어그램을 활용하여 설계한다면 좀 더 빠른 설계가 가능하다.

개발 관점 편집부(340)는 시스템이 배치될 환경을 고려하여 여러 대의 컴퓨터에 어떻게 배치하는가를 설계하기 위한 컴포넌트로 배치 아키텍처를 그리기 위한 편집기와 이를 관리해야 하는 부분으로 나누어져 있다. 저장은 위의 다른 모델들과 마찬가지로 XSD와 XML을 이용하여 저장하고 데이터를 교환하는 방식을 사용한다. 배치 아키텍처는 분산시스템일 경우에만 사용되고 하나의 시스템일 경우에는 사용되지 않는다.

도 6은 본 발명의 실시예에 따른 소스코드 개발부(600)의 기능을 설명하는 개념도이다.

도 6을 참조하면, 컴포넌트 생성부(610)는 아키텍처 설계부(300)를 통해 설계된 아키텍처를 기반으로 컴포넌트 자산을 구현할 수 있다.

또한, 소스코드 개발부(600)는 소스코드를 편집하기 위한 소스코드 편집부(640), 기존 제품의 소스코드를 자산으로 만들기 위한 리팩토링을 도와주는 리팩토링 관리부(630) 및 소스코드의 표준화를 해주는 소스코드 표준화 관리부(620)를 포함할 수 있다.

도 7은 본 발명의 실시예에 따른 자산 관리부(510)의 기능을 설명하는 개념도이다.

도 7을 참조하면, 자산 관리부(510)는 자산 관리단계(S600)의 기능들을 지원하기 위한 컴포넌트로써 자산 리포지터리(500)를 통해 현재 가진 자산의 정보를 관리하는 역할과 자산을 만드는 다른 컴포넌트들로부터 등록된 자산을 명세할 수 있다.

자산관리를 CVS(Current Version System)로 하게 되면 각 자산에 관한 버전관리가 가능하고 하나의 저장장소를 가짐으로써 데이터의 일관성을 유지할 수 있다.

도 8은 본 발명의 실시예에 따른 제품형상 관리부(700)의 기능을 설명하는 개념도이다.

도 8을 참조하면, 컨피그레이션 관리부(710)는 형상관리를 돕기 위한 컴포넌트로 형상관리를 위한 제품의 선택사항들을 선택하는 것이 주기능이다. 컨피그레이션 관리부(710)에서 선택한 제품의 선택사항들을 기반으로 제품 생성부(730)에 의하여 컴포넌트 자산을 선정하여 제품을 구성할 수 있다.

제품 생성부(730)는 상술한 바와 같이 컨피그레이션 관리부(710)에서 선택한 선택사항들을 만족하는 제품을 만들기 위하여 컨피그레이션 관리부(710)에 의해서 선택된 정보들을 모아서 그 제품을 구성하고자 해당하는 자산들을 모아서 제품을 구성할 수 있다.

컨피그레이션 관리 검증부(720)는 컨피그레이션 관리부(710)의 선택에 따른 컴포넌트 선택의 유효성을 검증할 수 있다.

도 9는 본 발명의 실시예에 따른 테스트부(900)의 기능을 설명하는 개념도이다.

도 9를 참조하면, 테스트 관리부(920)는 테스트 단계(S800)의 각 테스트를 관리하기 위한 컴포넌트로 자산 관리부(510)와 연결되어 테스트 역시 자산으로 관리될 수 있도록 한다.

다만, 상술한 개념적 모델에서 설명한 테스트 단계(S800)의 가변성 모델의 유효성 검증과 제품형상 관리를 위한 가변성 모델 검증부(800), 컨피그레이션 관리 검증부(720)는 물리적으로는 각각 가변성 모델 편집부(230)와 컨피그레이션 관리부(710)에 연결되어 있고 물리적으로 테스트 관리부(920)와는 떨어져 있다.

즉, 상술한 두 유효성 검증은 테스트 케이스로 기록될 필요가 없고 실시간으로 혹은 모델 검증이 필요한 시기에만 검증하는 것이므로 물리적으로 관계를 갖고 있을 필요가 없다.

유닛 테스트 관리부(910)는 테스트 단계(S800)에서 언급한 단위 테스트(unit test)를 수행한다. 유닛 테스트 관리부(910)는 하나의 모듈에 대한 테스트를 등록하고 각 테스트의 결과를 업데이트하여 그 모듈의 기능을 점검하는 데 이용하는 컴포넌트이다.

도 10은 본 발명의 실시예에 따른 레거시 분석부(400)의 기능을 설명하는 개념도이다.

도 10을 참조하면, 리버스 클래스 다이어그램 변환부(420)는 소스코드를 클래스 다이어그램으로 바꾸어주는 컴포넌트이고 이러한 정보를 컴포넌트 아키텍처로 불러들여서 사용하면 기존 제품 기반의 설계를 참고하여 아키텍처를 설계할 때 도움이 된다.

리버스 시퀀스 다이어그램 변환부(410)는 소스코드를 시퀀스 다이어그램으로 바꾸어주는 컴포넌트를 말하고 이러한 정보를 프로세스 아키텍처와 호환하여 프로세스 아키텍처로 불러들일 수 있다.

메트릭 관리부(440)는 기존 제품들의 소스코드를 평가하기 위한 컴포넌트로 독립적으로 떨어져 있는 도구로 사용되어도 되고 소스코드 개발부(600)에 함께 사용될 수도 있다.

차이 관리부(430)는 기존 제품들의 공통점과 차이점을 소스코드 기반으로 찾아내기 위한 컴포넌트이고 이 컴포넌트도 메트릭 관리부(440)와 마찬가지로 독립적인 도구로 사용되거나 소스코드 개발부(600)와 함께 사용될 수도 있다. 이러한 경우, 다른 기능들도 생각해 볼 수 있는데 공통적인 부분으로 선정된 것과 다른 부분으로 선정된 부분을 원하는 작업 공간에 배치하여 리팩토링을 하기 위한 기본 환경을 만들어 주는 역할을 하는 것이다.

본 발명의 실시예에 따라 워크벤치의 개념적 모델과 물리적 모델을 통하여 워크벤치를 구성하는 방법을 설명한다.

워크벤치는 개발하기 원하는 시스템에 따라 그 모습이 달라질 수 있다. 이러한 모든 기능을 한꺼번에 모아 지원할 수도 있지만 그렇게 할 경우에 워크벤치는 무거워지고 현재 개발되지 않은 워크벤치라면 그 워크벤치를 구성하는 데 드는 비용이 커질 것이다.

따라서, 워크벤치를 만들고자 원하는 사람들이 쉽게 워크벤치를 구성할 수 있도록 하는 워크벤치의 구성 방법을 설명한다.

먼저, 워크벤치를 구성하려면 워크벤치를 사용하기 위한 환경과 도메인을 정해야 한다. 이것이 정해지면 쉽게 기능들을 찾을 수 있게 된다. 이 기능들이 정해지게 되면 그 기능들을 수행할 수 있는 공개도구(open source) 또는 COTS (Commercial, Off-The-Shelf) 컴포넌트를 이용하여 상술한 논리적 모델과 물리적 모델을 참고하여 워크벤치를 구성할 수 있다.

워크벤치를 구성하는 방법에는 첫 번째로 원하는 도구들을 모아 각 도구를 수동적으로 통합하는 방법, 두 번째는 워크벤치의 기반이 되는 통합개발도구를 기반으로 필요로 되는 다른 기능들을 가진 도구를 통합하는 방법, 마지막은 플러그인을 지원하는 통합도구를 기반으로 통합하는 방법이 있다.

플러그인 가능한 통합도구에서 지원하지 못하는 다른 기능들을 가진 플러그인 가능한 도구들을 활용하여 워크벤치를 구성하는 방법이다.

실시예#1-지원도구들을 수동적으로 합병

워크벤치를 구성하는 가장 일반적인 방법은 구성하고자 원하는 워크벤치에 요구되는 기능들을 가진 공개도구들과 COTS컴포넌트를 선정하여 이 도구들을 하나의 작업 환경에서 사용할 수 있도록 각 도구를 원하는 형태로 합병하는 것이다. 이러한 방법은 원하는 도구를 설정하는 방법이기 때문에 기존에 사용하던 개발 환경에 덧붙여 워크벤치를 구성할 수 있고 공개도구를 선택할 수 있는 폭도 넓어진다.

그러나, 여러 개의 도구를 합치려면 각기 다른 데이터 체계를 가진 도구들을 조율해야 할 필요가 있다.

도 11은 본 발명의 실시예에 따른 워크벤치 구성 방법에서 지원도구들을 수동적으로 합병하는 것을 나타내는 개념도이다.

도 11을 참조하면, 각 도구를 통합하는 과정에서 각각의 도구가 맞닿는 부분이 존재한다는 것을 알 수 있다. 이는 모듈 간의 연결을 위해 모듈 내부를 수정하거나 외부의 어댑터 (adapter)를 만들어 다른 모듈과 연결해 주어야 한다는 것을 뜻한다.

다만, 이러한 방법을 사용해서 워크벤치를 구성하는 경우에는 도구의 수에 비례하여 많은 모듈을 수정하거나 어댑터를 만들어야 하는 오버헤드가 발생할 수 있다.

실시예#2-통합 개발환경에 수동적으로 합병

모든 지원도구들을 원하는 부분만 모아서 워크벤치를 구성하는 방법은 도구를 합치는데 드는 큰 비용을 발생시킨다. 그 중에서도 일반적으로 소프트웨어 개발에서 가장 많이 쓰이는 CASE 도구인 통합 개발환경(Integrated Development Environment: IDE)은 이미 공개도구로도 많이 나와있고 워크벤치를 구성하기 위한 물리적 모델에서도 구현된 컴포넌트를 자산으로 관리하는 것을 제외하고 독립적으로 사용되는 특징을 가지고 있어 이를 기반으로 워크벤치를 구성한다면 통합 개발환경을 만들기 위한 노력을 줄일 수 있다.

도 12는 본 발명의 실시예에 따른 워크벤치 구성 방법에서 통합 개발환경에 수동적으로 합병하는 것을 나타내는 개념도이다.

도 12의 통합 개발환경을 기반으로 워크벤치를 구성하면 통합 개발환경이 갖춰진 기능 이외의 기능을 추가하려면 상술한 바와 같이 워크벤치를 구성하기 위한 비용이 들게 된다. 또한, 통합 개발환경의 기능 자체를 바꾸려 한다면 오히려 지원 도구들을 수동으로 합병하는 것보다 더 많은 비용이 들 수도 있으므로 이에 대한 고려가 필요하다.

실시예#3-플러그인 아키텍처를 이용한 구성

도 13은 본 발명의 실시예에 따른 워크벤치 구성 방법에서 플러그인 아키텍처를 이용한 구성을 나타내는 개념도이다.

도 13을 참조하면, 플러그인(plug-in) 가능한 공개도구 또는 COTS컴포넌트들을 이용해 워크벤치를 구성하는 방법이다. Eclipse나 NetBeans 같은 통합개발도구들은 앞에서 말한 플러그인으로 소프트웨어를 추가하는 것이 가능하다. 이러한 플러그인이 가능한 통합개발도구들을 이용하여 워크벤치를 구성한다면 원하는 도구들을 플러그인하는 것으로 원하고자 하는 워크벤치를 쉽게 구성할 수 있다.

도 13을 보면, 각각의 모듈이 통합 IDE에 반듯하게 맞춰지는 것을 볼 수 있다. 이는 각 모듈이 통합 IDE에 합쳐질 때 모듈을 수정하거나 모듈 간의 연결을 위해 어댑터를 제작할 필요가 없다는 것을 의미한다. 하지만, 선택한 통합 개발도구에 플러그인 가능한 것들만 사용 가능하다는 점이 피할 수 없는 제약사항이 있다.

상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

100: 요구사항 분석부 200: 도메인 분석부
210: 도메인 오브젝트 모델 편집부 220: 컨텍스트 모델 편집부
230: 가변성 모델 편집부 300: 아키텍처 설계부
310: 개념 관점 편집부 320: 프로세스 관점 편집부
330: 컴포넌트 관점 편집부 340: 개발 관점 편집부
400: 레거시 분석부 410: 리버스 시퀀스 다이어그램 변환부
420: 리버스 클래스 다이어그램 변환부 430: 차이 관리부
440: 메트릭 관리부 500: 자산 리포지터리
510: 자산 관리부 520: 자산 저장부
600: 소스코드 개발부 610: 컴포넌트 생성부
620: 소스코드 표준화 관리부 630: 리팩토링 관리부
640: 소스코드 편집부 700: 제품형상 관리부
710: 컨피그레이션 관리부 720: 컨피그레이션 관리 검증부
730: 제품 생성부 800: 가변성 모델 검증부
900: 테스트부 910: 유닛 테스트 관리부
920: 테스트 관리부

Claims (19)

1. 워크벤치 구성 장치에 의해 수행되는 소프트웨어 개발에 있어서,
   개발 소프트웨어에 대한 고객의 요구사항의 변경이력을 저장하고 분석하여 요구사항 분석정보를 산출하는 요구사항 분석단계;
   객체 설계복원, 프로세스 설계복원, 가변성 분석, 설계품질 평가 중 적어도 하나를 수행함으로써 기존 소프트웨어를 분석하여 상기 개발 소프트웨어와의 공통점과 차이점에 대한 정보를 포함하는 레거시 분석정보를 산출하는 레거시 분석단계;
   상기 요구사항 분석정보 및 상기 레거시 분석정보를 이용하여 컨텍스트 모델링, 도메인 오브젝트 모델링, 가변성 모델링 중 적어도 하나를 수행함에 의한 도메인 분석을 통하여 도메인 분석정보를 산출하는 도메인 분석단계;
   상기 도메인 분석정보를 이용하여 아키텍처를 설계하는 아키텍처 설계단계; 및
   상기 아키텍처에 기반하여 컴포넌트를 개발하는 컴포넌트 개발단계를 포함하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법.
2. 청구항 1에 있어서,
   상기 요구사항 분석정보, 상기 도메인 분석정보, 상기 아키텍처 중 적어도 하나를 포함하는 자산을 자산 리포지터리에 저장하여 관리하는 자산 관리단계를 더 포함하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법.
3. 청구항 2에 있어서,
   휘처 모델(Feature Model)에서 상기 자산에 기반하여 상기 개발 소프트웨어에 대한 고객의 요구사항에 상응하는 휘처를 선택하고, 상기 선택된 휘처에 따른 구현 컴포넌트를 기반으로 매크로 프로세싱(macro processing)함으로써, 소프트웨어를 개발하는 제품형상 관리단계를 더 포함하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법.
4. 삭제
5. 삭제
6. 삭제
7. 청구항 1에 있어서, 상기 아키텍처 설계단계는,
   상기 도메인 분석정보를 이용하여 개념적 아키텍처, 프로세스 아키텍처, 컴포넌트 아키텍처, 배치 아키텍처 중 적어도 하나를 포함하는 상기 아키텍처를 산출하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법.
8. 청구항 1에 있어서, 상기 컴포넌트 개발단계는,
   소스코드에 대한 편집, 리팩토링, 표준화를 수행하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 방법.
9. 소프트웨어 개발에 있어서,
   개발 소프트웨어에 대한 고객의 요구사항의 변경이력을 저장하고 분석하여 요구사항 분석정보를 산출하는 요구사항 분석부;
   객체 설계복원, 프로세스 설계복원, 가변성 분석, 설계품질 평가 중 적어도 하나를 수행함으로써 기존 소프트웨어를 분석하여 상기 개발 소프트웨어와의 공통점과 차이점에 대한 정보를 포함하는 레거시 분석정보를 산출하는 레거시 분석부;
   상기 요구사항 분석정보 및 상기 레거시 분석정보를 이용하여 컨텍스트 모델링, 도메인 오브젝트 모델링, 가변성 모델링 중 적어도 하나를 수행함에 의한 도메인 분석을 통하여 도메인 분석정보를 산출하는 도메인 분석부;
   상기 도메인 분석정보를 이용하여 아키텍처를 설계하는 아키텍처 설계부; 및
   상기 아키텍처에 기반하여 컴포넌트를 개발하는 소스코드 개발부를 포함하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
10. 청구항 9에 있어서,
    상기 요구사항 분석정보, 상기 도메인 분석정보, 상기 아키텍처 중 적어도 하나를 포함하는 자산을 자산 리포지터리에 저장하여 관리하는 자산 관리부를 더 포함하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
11. 청구항 10에 있어서,
    휘처 모델(Feature Model)에서 상기 자산에 기반하여 상기 개발 소프트웨어에 대한 고객의 요구사항에 상응하는 휘처를 선택하고, 상기 선택된 휘처에 따른 구현 컴포넌트를 기반으로 매크로 프로세싱(macro processing)함으로써, 소프트웨어를 개발하는 제품형상 관리부를 더 포함하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
12. 삭제
13. 삭제
14. 삭제
15. 청구항 9에 있어서, 상기 아키텍처 설계부는,
    상기 도메인 분석정보를 이용하여 개념적 아키텍처, 프로세스 아키텍처, 컴포넌트 아키텍처, 배치 아키텍처 중 적어도 하나를 포함하는 상기 아키텍처를 산출하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
16. 청구항 9에 있어서, 상기 소스코드 개발부는,
    소스코드에 대한 편집, 리팩토링, 표준화를 수행하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
17. 청구항 9에 있어서, 상기 워크벤치 구성 장치는,
    공개도구들과 COTS컴포넌트를 포함하는 지원도구들을 합병하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
18. 청구항 9에 있어서, 상기 워크벤치 구성 장치는,
    소프트웨어 개발을 위한 CASE 도구인 통합 개발환경(IDE)에 공개도구들과 COTS 컴포넌트를 포함하는 지원도구들을 병합하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.
19. 청구항 9에 있어서, 상기 워크벤치 구성 장치는,
    플러그인(plug-in) 가능한 공개도구 또는 COTS컴포넌트들을 이용해 워크벤치를 구성하는 것을 특징으로 하는 소프트웨어 제품라인 공학의 추출식 접근법을 위한 워크벤치 구성 장치.

Images