모델의 가변성 검증 방법 및 이를 위한 장치{METHOD OF VERIFY VARIABILITY OF MODEL AND APPARATUS FOR THE SAME}

본 발명은 모델의 가변성 검증에 관한 것으로, 더욱 상세하게는소프트웨어 제품라인 모델의 가변성 검증을 위한 소프트웨어 제품라인 모델의 가변성 검증방법 및 이를 위한 장치에 관한 것이다.

소프트웨어 제품라인(이하 제품라인)이란 공통된 기능을 갖고 있는 소프트웨어 시스템 군을 뜻한다. 제품라인은 초기에 하드웨어 제품의 공정관리 측면에서 공통된 기능을 갖고 있는 하드웨어 제품군을 가리키기 위해 나온 개념이다. 소프트웨어 제품라인은 하드웨어 제품이 아니라 소프트웨어 제품을 대상으로 하여, 소프트웨어 시스템 개발 및 유지보수 측면에서 공통된 기능을 갖고 있는 소프트웨어 제품군을 가리킨다. 같은제품라인에속하는시스템들은공통된기능을많이갖고있기 때문에 시스템을 개발할 때 공통된 기능을 재사용할 수 있는 가능성이 높다.

소프트웨어 제품라인 공학(이하 제품라인 공학)은 시스템 재사용 방법 중 하나로, 시스템 하나를 개발하기 위한 패러다임이 아니라 제품라인을 개발하기 위한 새로운 패러다임을 제시한다. 제품라인 공학은 제품라인에속하는시스템들의공통점과차이점을분석하고, 분석내용을 바탕으로 핵심 자산을개발하고관리하여, 핵심자산으로부터제품라인에 속하는 시스템들을 개발하는 소프트웨어 개발방법이다. 이 때 제품라인의 핵심 자산은 시스템요구사항, 아키텍처디자인, 소스코드컴포넌트, 테스트 케이스 등을 포함한다.

소프트웨어 제품라인 모델(이하 제품라인 모델)은 소프트웨어 제품라인 공학에서 대상 소프트웨어 제품라인을 개발하기 위해 재사용되는 모든 모델을 뜻한다. 제품라인 모델은 제품라인 개발 단계에 따라서 구분된다. 예를 들어, 제품라인 분석 단계에서 산출되는 모델은 제품라인 분석 모델, 설계 단계에서 산출되는 모델은 제품라인 설계 모델, 구현 단계에서 산출되는 모델은 제품라인 구현 모델이다.

제품라인공학에서제품라인에속하는시스템 간의 공통점과 차이점을 체계적으로 분석하고 관리하는 것이 매우 중요하다. 이때, 휘처 모델은 제품라인에 속하는 시스템 간의 공통점과 차이점을 “휘처” 단위로 나타내고, 휘처 사이의 관계를 표현하는 분석 모델이다.

제품라인 운용이 가능한 기반 체제를 구축하기 위해서는, 소프트웨어자산(asset)에 대한 목록 관리, 상호 종속 관계 관리, 가변 요소 관리가 총체적으로 수반되어야 하며, 이를 개별적인 툴이나 방법론들의 조합이 아닌 일관된 체제로 지원하는 수단이 필요하다.

일반적으로 소프트웨어 개발에 적용되는 개발 프로세스에서는, UML(Unified Modeling Language)을 통해 소프트웨어 시스템의 아키텍처를 표현하거나 구현 로직을 기술하였다.

UML은 산업계의 표준으로 자리잡고 있는 소프트웨어 모델링 언어로서, 소프트웨어 분석 및 설계 단계에서 산출되는 다양한 소프트웨어 분석 및 설계 모델을 정의하고 있다.

UML 기반 소프트웨어 제품라인 모델의 가변성을 표현하고 관리하는 종래의 방법은 크게 두 가지로 구분된다. 첫째는 휘처 모델에만 제품라인의 가변성을 표현하고, 휘처와 소프트웨어 제품라인 모델 요소와의 명시적인 대응 관계를 통해서 소프트웨어 제품라인 모델의 가변성을 관리하는 방법이다.

이러한 방법의 가장 큰 문제점은 다양한 소프트웨어 제품라인 모델 내의 가변성이 명시적으로 표현되지 않고, 휘처 모델에 표현된 가변성 정보를 바탕으로 관리만 된다는 점이다.

두 번째 방법은 소프트웨어 제품라인 모델 자체에 직접 가변성을 표현하고 관리하는 방법이다. 이러한 방법은 소프트웨어 제품라인 모델에 가변성이 직접 표현되고 관리되는 장점은 있으나, 다양한 소프트웨어 제품라인 모델 마다 표현되는 가변성 형태가 상이할 수가 있고, 휘처 모델에 표현된 가변성과 소프트웨어 제품라인 모델에 표현된 가변성간의 일관성이 맞지 않을 문제점이 높다.

상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, 소프트웨어 제품라인 모델의 가변성 검증을 위한 제품라인 모델의 가변성 검증 장치를 제공하는데 있다.

상기와 같은 문제점을 해결하기 위한 본 발명의 다른 목적은, 소프트웨어 제품라인 모델의 가변성 검증을 위한 제품라인 모델의 가변성 검증 방법을 제공하는데 있다.

상기한 본 발명의 목적을 달성하기 위한 본 발명의 일 실시예에 따른 가변성 검증 장치는 소프트웨어 제품라인에 속하는 소프트웨어의 특징을 휘처 단위로 표현한 분석 모델인 휘처 모델 및 소프트웨어 개발에 재사용될 수 있는 소프트웨어를 UML 모델 요소 단위로 표현한 분석 및 설계 모델이 UML 모델을 이용하여 UML 모델 요소와 적어도 하나의 휘처로 구성된 대응 관계를 생성하는 대응관계 생성부, 미리 정의된 가변성 규칙을 참조하여 상기 대응 관계에 정의된 휘처의 가변성에 따라 상기 UML 모델 요소의 가변성을 결정하는 결정부 및 상기 결정한 UML 모델 요소의 가변성을 기초로 상기 휘처 모델 및 상기 UML 모델의 가변성을 검증하여 검증 결과를 출력하는 검증부를 포함한다.

상기한 본 발명의 다른 목적을 달성하기 위한 본 발명의 일 실시예에 따른 가변성 검증방법은 소프트웨어 제품라인에 속하는 소프트웨어의 특징을 휘처 단위로 표현한 분석 모델인 휘처 모델 및 소프트웨어 개발에 재사용될 수 있는 소프트웨어를 UML 모델 요소 단위로 표현한 분석 및 설계 모델인 UML 모델을 이용하여 UML 모델 요소와 적어도 하나의 휘처로 구성된 대응 관계를 생성하는 단계, 미리 정의된 가변성 규칙을 참조하여 상기 대응 관계에 정의된 휘처의 가변성에 따라 상기 UML 모델 요소의 가변성을 결정하는 단계 및 상기 결정한UML 모델 요소의 가변성을 기초로 상기 휘처 모델 및 상기 UML 모델의 가변성을 검증하여 검증 결과를 출력하는 단계를 포함한다.

상기와 같은 본 발명에 따른 소프트웨어 제품라인 모델 검증 방법 및 이를 위한 장치를 이용할 경우에는기존에 나와 있는 다양한 UML 모델링 도구 및 휘처 모델링 도구와 연계할 수 있을 뿐만 아니라, 각 모델링 도구가 변경되거나 진화하는 경우에도 이에 쉽게 대응 할 수 있는 장점이 있다.

도 1은 본 발명의 일 실시예에 따른 소프트웨어 제품라인 모델의 가변성 검증 장치의 구성을 나타내는 블록도이다.
도 2는 본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 휘처 모델링부에 의해 생성되는 휘처 모델의 메타 모델 구조를 나타내는 다이어그램이다.
도 3은본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 UML 모델링부에 의해 생성되는 UML 모델의 메타 모델 구조를 나타내는 다이어그램이다.
도 4는 본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 UML 모델링부에 의해 생성되는 UML 모델의 메타 모델 구조의 일 실시예를 나타내는 다이어그램이다.
도 5는 본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 UML 모델 가변성 결정부가 가변성 정보를 결정하는데 사용되는 판단 테이블의 구성을 나타내는 블록도이다.
도 6은 본 발명의 일 실시예에 따른 소프트웨어 제품라인 모델 검증 방법을 설명하기 위한 흐름도이다.
도 7은 본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 휘처 모델링부에 의해 생성되는 휘처 모델의 예를 나타내는 개념도이다.

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

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

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

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

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

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

도 1은 본 발명의 일 실시예에 따른 소프트웨어 제품라인 모델의 가변성 검증 장치의 구성을 나타내는 블록도이다.

도 1을 참조하면, 소프트웨어 제품라인 모델의 가변성 검증 장치는 휘처 모델링부(110), UML 모델링부(120), UML-휘처 대응 관계 생성부(130), 대응 일관성 검증부(150) 및 UML 모델 가변성 결정부(140)를 포함하여 구성될 수 있다.

휘처 모델링부(110)는 제품라인에 속하는 시스템 간의 공통점과 차이점을 “휘처” 단위로 분석하여 휘처 모델을 생성하고, 생성한 휘처 모델을 UML-휘처 대응 관계 생성부(130) 및 대응 일관성 검증부(150)로 제공한다. 여기서, 휘처 모델은 제품라인에 속하는 소프트웨어 제품 간의 가변성을 표현한 모델이다.

UML 모델링부(120)는 제품라인에 속하는 시스템의 구성 요소를 UML 모델의 UML 모델 요소로 모델링하여 UML 모델을 생성하고, 생성한 UML 모델을 UML-휘처 대응 관계 생성부(130) 및 대응 일관성 검증부(150)로 제공한다.

UML-휘처 대응 관계 생성부(130)는휘처 모델링부(110)로부터 휘처 모델을 제공받고 UML 모델링부(120)로부터 UML 모델을 제공받는다. UML-휘처 대응 관계 생성부(130)는 제공받은 UML 모델의 각 UML 모델 요소에 대해서 UML 모델 요소가 실현시킨 휘처 모델의 휘처를 대응시켜 UML-휘처 대응 관계를 생성하고, 생성한 UML-휘처 대응 관계를 UML 모델 가변성 결정부(140) 및 대응 일관성 검증부(150)로 제공할 수 있다.

예를 들어, UML 모델의 UML 모델 요소 컴포넌트 C1은 휘처 모델의 F1을 실현시킨 것이면 UML-휘처 대응 관계 생성부(130)는 (C1, {F1})의 UML-휘처 대응관계를 생성할 수 있다.

UML 모델 가변성 결정부(140)는 UML-휘처 대응 관계 생성부(130)로부터 UML-휘처 대응 관계를 수신하고, 수신한 UML-휘처 대응 관계를 기초로하여 UML 모델의 각 UML 모델 요소의 가변성 정보를 결정하고, 결정한 가변성 정보를 UML 모델에 적용할 수 있다.

예를 들어, UML 모델 가변성 결정부(140)는 결정한 가변성 정보를 UML 모델링부(120)에 구비된 오픈 API(미도시)를 이용하여 UML 모델에 적용할 수 있다.

대응 일관성 검증부(150)는 휘처 모델링부(110)로부터 휘처 모델을 제공받고, UML 모델링부(120)로부터 UML 모델 가변성 결정부(140)에 의해 가변성 정보가 적용된 UML 모델을 제공받고, UML-휘처 모델 대응부(130)로부터 UML-휘처 대응 관계를 제공받고, 제공받은 휘처 모델 및 UML 모델을 기초로하여 UML-휘처 대응 관계의 일관성을 검증할 수 있다.

예를 들어, 대응 일관성 검증부(150)는 제공받은 휘처 모델 및 UML 모델을 기초로UML-휘처 대응 관계에 해당하는 휘처가 휘처 모델에 포함되어 있지 않다고 판단되면 UML-휘처 대응 관계에 일관성이 없다고 결과를 출력하고, UML-휘처 대응 관계에 해당하는 UML 모델요소가 UML 모델에 정의되지 않았다고 판단되면 UML-휘처 대응 관계에 일관성이 없다고 결과를 출력할 수 있다.

이와 같이, 대응 일관성 검증부(150)가 UML-휘처 대응 관계에 일관성이 깨진다고 판단하면 UML-휘처 모델 대응부(130)는 UML-휘처 대응 관계를 UML 모델 가변성 결정부(140)로 제공하지 않는다.

도 2는 본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 휘처 모델링부에 의해 생성되는 휘처 모델의 메타 모델 구조를 나타내는 다이어그램이다.

휘처 모델(210)은 제품라인에 속하는 시스템 간의 공통점과 차이점을 휘처(220) 단위로 나타내고, 휘처 사이의 관계를 표현하는 분석 모델이다. 휘처 모델(210)은 휘처(220)와 휘처 관계(230)으로 구성된다.

휘처 모델(210)의 휘처(220)는 필수휘처(240), 선택휘처(250), 택일휘처(260)의 세가지 타입이 있다. 필수휘처(240)는 부모(270) 관계에 있는 휘처(202)가 선택되면 반드시 선택되어야 하는 자식(280) 휘처를 의미한다. 예를 들어, 제품라인에 속하는 모든 시스템에 포함되는 휘처이다.

선택휘처(250)는 소프트웨어 제품라인 내의 소프트웨어 제품에 따라 선택될 수도 있고, 선택되지 않을 수도 있는 자식(280) 휘처를 의미한다. 예를 들어, 선택(205)타입의 휘처는 제품라인에 속하는 일부 시스템에만 선택적으로 포함되는 휘처이다.

택일(260)타입의 휘처는 같은 택일그룹에 속하는 휘처 중 단 하나만 제품라인에 속하는 시스템에 들어가야 하는 휘처이다.

또한 휘처 관계(230)에는 휘처들을 계층적으로 구조화시키는 역할을 하며, “포함관계”, “추상화-상세화 관계”와 같은 구조적인 관계가 있을 수 있다. 또한 어떤 휘처가 시스템에 포함될 때 다른 어떤 휘처가 함께 시스템에 포함되어야 하는 “필요 관계”, 어떤 휘처가 시스템에 포함될 때 다른 어떤 휘처가 시스템에 포함되면 안되는 “배제 관계”와 같은 규칙이 있을 수 있다.

도 3은본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 UML 모델링부에 의해 생성되는 UML 모델의 메타 모델 구조를 나타내는 다이어그램이다.

도 3을 참조하면, UML 모델(310)은 UML 모델 요소(320)로 구성되며, UML 모델 요소(320)는 요소 관계(360)는 다 대 일(many-to-one)또는 다 대 다(many-to-many)의 관계를 가질 수 있고, UML 모델 요소(320)와 복합 요소(350)는 전체-부분(whole-part)”의 집합 연관 관계를 가진다.“전체”클래스와“부분”클래스는 선으로 연결되며, 전체 클래스인 복수 요소(350)쪽에 빈 마름모꼴이 도시된다.

복합 요소(350)와 요소 관계(360)는 UML 모델 요소(320)와 상속 관계를 가진다. 즉, UML 모델 요소(320)는 슈퍼 클래스이고, 복합 요소(350)와 요소 관계(360)는 서브 클래스이며, 서브 클래스인 복합 요소(350)와 요소 관계(360)는 슈퍼 클래스인 UML 모델 요소(320)로부터 속성값인 스테리오타입(330) 및 태그값(340)과 다른 메타 요소와의 관계, 예를 들어 UML 모델과 UML 모델 요소와의 집합 연관 관계를 상속받을 수 있다. 복합 요소(350)와 요소 관계(360)는 UML 모델 요소(320)와 선으로 연결되며, 슈퍼 클래스인 UML 모델 요소(320)쪽에 속이 빈 화살표 머리가 도시된다.

UML 모델 요소(320)는 스테레오타입(330)과 태그값(340)을 속성으로 가지고 있다. 이러한 속성값은 UML 모델 요소(320)의 가변성을 표현할 때 사용된다.

도 4는 도 4는 본발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 UML 모델링부에 의해 생성되는 UML 모델의 메타 모델 구조의 일 실시예를 나타내는 다이어그램이다.

도 4를 참조하면, UML 모델링부(120)는 UML 모델링부(120)는 제품라인내시스템 중 서브 시스템 S1(400)에 포함된 각각 구성 요소를 모델링하여 UML 모델(300)을 생성할 수 있다.

여기서, 서브 시스템 S1(400)은 제 1 컴포넌트 C1(410), 제 2 컴포넌트 C2(420), 포트 P2(430), 제 1 컴포넌트 C1(410)와 포트 P2(430)를 연결하는 커넥터 Con1(440), 제 1 컴포넌트 C1(410) 와 제 2 컴포넌트 C2(420)를 연결하는 커넥터 Con2(450)를구성 요소로 하고, 제 1 컴포넌트 C1(410)은 커넥터 Con1(440)을 통해 포트 P2(430)와 연결되는 포트 P1(460), 커넥터 Con2(450)를 통해 포트 P4(480)와 연결되는 포트 P3(470)를 구성 요소로 하고, 제 2 컴포넌트 C2(420)은 커넥터 Con2(250)를 통해 제 1 컴포넌트 C1(410)와 연결되는 포트 P4(480)를 구성 요소로 한다.

UML 모델링부(120)는 제품라인 모델을 다양한 형태의 UML 모델(301)로 생성한다. 다양한 형태의 UML 모델은 서브 시스템 모델, 패키지 모델, 클래스 모델 등을 포함하며, 도 4 는 이 중 서브 시스템 모델을 나타낸 것이다. 서브시스템 모델에서는 서브 시스템(410) 및 컴포넌트(420)를 복합 요소(350)의 서브 클래스로 모델링한다. 이에 따라, 서브 시스템(410) 및 컴포넌트(420)는 복합 요소(350)의 슈퍼 클래스인 UML 모델 요소(320)의 속성값인 스테레오타입(330) 및 태그값(340)을 상속받아 스테레오타입(330) 및 태그값(340)을 속성값으로 가질 수 있다.

UML 모델링부(120)는 포트(430)를 UML 모델 요소(320)로 모델링함으로써, 포트(430)는 UML 모델 요소(320)의 속성값인 스테레오타입(330) 및 태그값(340)을 상속받아 스테레오타입(330) 및 태그값(340)을 속성값으로 가질 수 있다.

UML 모델링부(120)는 커넥터(440)를 요소 관계(360)로 모델링함으로써, 커넥터(440)는 요소 관계(360)의 슈퍼 클래스인 UML 모델 요소(320)의 속성값인 스테레오타입(330) 및 태그값(340)을 상속받아 스테레오타입(330) 및 태그값(340)을 속성값으로 가질 수 있다.

도 5는 본 발명의 일 실시예에 따른 소프트웨어 제품라인 모델의 가변성 검증 장치의 UML 모델 가변성 결정부가 가변성 정보를 결정하는데 사용되는 판단 테이블의 구성을 나타내는 블록도이다.

도 5를 참조하면, UML 모델 가변성 결정부(140)는 UML-휘처 대응 관계 생성부(130)로부터 대응 일관성 검증부(150)에 의해 검증된 UML-휘처 대응 관계를 수신하고, UML 모델 요소 가변성 생성 규칙을 기초로하여 UML-휘처 대응 관계에서 UML 모델 요소의 가변성 정보를 결정하고, 결정한 가변성 정보를 UML 모델에 적용할 수 있다.

예를 들어, UML 모델 가변성 결정부(140)는 UML-휘처 대응 관계 생성부(130)로부터 대응 일관성 검증부(150)에 의해 검증된 UML-휘처 대응 관계인 (C1, {F1})를 수신하고, UML 모델 요소 가변성 생성 규칙을 기초로하여 UML-휘처 대응 관계 (C1, {F1})에서F1의 타입이 Optional이라고 판단하여, 컴포넌트 C1의 가변성 정보를 Optional로 결정하고, 결정한 컴포넌트 C1의 가변성 정보를 UML 모델에 적용할 수 있다.

여기서, UML 모델 요소 가변성 생성 규칙은 판단 테이블(602)을 포함하고 있으며, 판단 테이블(602)은 UML-휘처 대응관계, 가변성 결정 조건 및 결과를 포함할 수 있다. UML-휘처 대응관계는 UML 모델 요소와 휘처 집합이 대응된 대응 관계가 저장될 수 있고, 가변성 결정 조건은 UML-휘처 대응관계의 휘처 집합에 포함된 휘처의 가변성이 저장될 수 있고, 결과는 가변성 결정 조건에 따라 결정된 UML 모델 요소의 가변성 결과가 저장될 수 있다.

도 6은 본 발명의 일 실시예에 따른 소프트웨어 제품라인 모델 검증 방법을 설명하기 위한 흐름도이다.

도 6을 참조하면, 소프트웨어 제품라인 모델의 가변성 검증 장치는 소프트웨어 제품라인의 분석 단계에서 제품간의 특징을 휘처로 표현하여 생성된 분석 모델인 휘처 모델 및, 분석 및 설계 단계에서 제품을 UML 모델 요소로 표현하여 생성된 UML 모델(서브 시스템 모델, 패키지 모델, 클래스 모델 등이 포함됨)을 이용하여 UML 모델 요소와 적어도 하나의 휘처로 구성된 대응 관계를 생성한다(S610).

여기서, 휘처 모델은 소프트웨어 제품라인에 속한 소프트웨어 제품간의 공통점 및 차이점을 휘처 단위로 분석하고, 분석한 휘처 사이의 관계를 표현하는 분석 모델이고, UML 모델은 소프트웨어 제품을 UML 모델 요소 단위로 나타내어 UML 모델 요소 사이의 관계를 표현하는 분석 및 설계 모델이다.

소프트웨어 제품라인 모델의 가변성 검증 장치는 UML 모델 요소 가변성 정보 테이블에서 상기 대응 관계에 포함된 휘처의 가변성 정보에 따라 상기 UML 모델 요소의 가변성 정보를 결정하여 상기 각 UML 모델 요소의 속성값에 적용한다(S620).

여기서, UML 모델 요소 가변성 정보 테이블은 UML 모델 요소와 적어도 하나의 휘처가 대응되어 생성된 대응관계, 휘처의 가변성 정보 및 휘처의 가변성 정보에 따라 결정되는 모델 요소의 가변성 정보를 포함할 수 있다.

소프트웨어 제품라인 모델의 가변성 검증 장치는 결정한 가변성을 기초로 상기 휘처 모델 및 상기 UML 모델의 가변성을 검증하여 검증 결과를 출력한다(S630).

예를 들어, 소프트웨어 제품라인 모델의 가변성 검증 장치는 제공받은 휘처 모델 및 UML 모델을 기초로UML-휘처 대응 관계에 해당하는 휘처가 휘처 모델에 포함되어 있지 않다고 판단되면 UML-휘처 대응 관계에 일관성이 없다고 결과를 출력하고, UML-휘처 대응 관계에 해당하는 UML 모델요소가 UML 모델에 정의되지 않았다고 판단되면 UML-휘처 대응 관계에 일관성이 없다고 결과를 출력할 수 있다.

도 7은 본 발명의 일 실시예에 따른소프트웨어 제품라인 모델의 가변성 검증 장치의 휘처 모델링부에 의해 생성되는 휘처 모델의 예를 나타내는 개념도이다.

도 7을 참조하면, Arcade Game 제품의 휘처 모델은 게임에 대한 다양한 휘처 및 휘처 관계로 구성된다. 각 노드는 필수휘처, 선택휘처 및 택일휘처 중 어느 하나로 표현될 수 있다.

예를 들어, 노드 Game Operation(701)은 Arcade Game 노드(700)의 필수 휘처이고, 노드 Play(702)는 노드 Game Operation(701)의 필수 휘처이고, 동그라미가 함께도시된 노드 Save/load(703)는 노드 Game Operation(701)의 선택 휘처이고, 노드 2D display(705), 노드 3D display(706)는 노드 Graphics display(704)의택일 휘처이다.

즉, Play(702)는 Arcade Game 제품에 필수적으로 포함되는 필수 휘처이고, Save/load(703)는 Arcade Game 제품에 선택적으로 포함되는 선택 휘처이고, 2D display(705), 3D display(706)는 Arcade Game 제품에 둘 중 하나만 포함될 수 있는 택일 휘처이다.

또한, 조상-자손 관계의 노드는 포함관계(Composed-of-relationship), 추상화-상세화 관계(Generalization relationship) 및 구현 관계(Implemented-by relationship) 중 어느 하나로 표현된다.

예를 들어, 노드 Game operation(701)은 노드 Play(702)와 포함관계이고, 노드 Graphics display(704)은 노드 2D display(705) 및 3D display(706)와 추상화-상세화 관계이고, 노드 Arcade Game(700)은 노드 Database(707)와 구현 관계이다.

110: 휘처 모델링부 120: UML 모델링부
130: UML-휘처 대응관계 생성부 140: UML 모델 가변성 결정부
150: 대응 일관성 검증부