KR20090088605A

KR20090088605A - 컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는방법, 이를 이용하여 소프트웨어 플랫폼 아키텍처를검증하는 방법 및 그 장치

Info

Publication number: KR20090088605A
Application number: KR1020080013993A
Authority: KR
Inventors: 손경호; 권자근
Original assignee: 삼성전자주식회사
Priority date: 2008-02-15
Filing date: 2008-02-15
Publication date: 2009-08-20
Also published as: EP2245532B1; EP2245532A4; WO2009102104A1; US20090210858A1; JP2011510418A; US8601433B2; KR101470319B1; JP5295269B2; EP2245532A1

Abstract

본 발명은 컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처의 검증 방법에 관한 것으로, 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 단계와 상기 컴포넌트의 조합을 위해 상기 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 단계와 상기 변경된 설정 변수에 기초한 상기 가상 소프트웨어 플랫폼의 실행 결과에 따라 상기 소프트웨어 플랫폼의 정합성을 검증하는 단계를 포함하여, 해당 소프트웨어 제품의 정상적인 조합 구성이 가능한지를 선행적으로 검증함으로써 테스트 비용과 인력 절감을 가능하게 한다.

Description

컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 방법, 이를 이용하여 소프트웨어 플랫폼 아키텍처를 검증하는 방법 및 그 장치{Method and apparatus for generating virtual software platform based on component model and validating software platform architecture using thereof}

본 발명은 컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 방법 및 이를 이용한 소프트웨어 플랫폼 아키텍처의 검증 방법에 관한 것으로, 보다 구체적으로는 컴포넌트 모델을 기반으로 개발되는 소프트웨어의 플랫폼 아키텍처를 검증하기 위해, 직접적인 코드 내부 구현 단계에 앞서 가상 플랫폼(virtual platform) 생성하고 이를 통해 컴포넌트 모델 설계 정보의 무결성과 신뢰성을 점검할 수 있는 방법 및 장치에 관한 것이다.

소프트웨어 개발에 있어서 설계(design) 단계는 구현(implementation) 단계에서 이루어져야 하는 세부 기능을 파악하고, 다양한 구성품이 적절한 방식으로 상호 연동되는 구조를 미리 확인함으로써, 신속하고 오류없는 개발이 이루어지는 것을 돕기 위한 절차이다. 소프트웨어의 규모가 방대해지고 복잡해질수록 이러한 설계 단계에서 자동화된 시스템을 통해 신속성과 정확성을 확보할 필요성이 증대된 다.

CE(Consumer Electronics) 소프트웨어와 같은 임베디드(embedded) 소프트웨어 분야에서는 기능의 융복합 및 신규 기능의 결합이 빈번히 발생하며, 또한 시장 흐름에 따라 신속한 출시가 요구되고 대규모 양산 체제가 필요하는 등의 상황이 발생하므로 소프트웨어의 설계와 구현의 작은 오류까지도 정확히 검출되고 수정되어야 한다. 특히, 구현이 완료된 뒤 사후 테스트에서는 비용이 급격하게 증가하므로, 근래의 테스트 개념은 요구사항 분석 및 설계 단계에서 사전 검증을 통해 이후 단계에서의 오류 발생을 최소화하기 위한 방향으로 진행되고 있다.

CE 소프트웨어 개발에 있어서 재사용성(reusability)과 가변성(variability) 관리를 기반으로 다품종 개발을 효과적으로 지원하기 위한 SPL(Software Product Line) 체제는, 플랫폼 자체에 대한 검증과 설계 정보에 기반한 구현의 자동화를 수행할 수 있는 방법을 필요로 한다.

일반적으로 소프트웨어는 요구사항 분석, 설계, 구현, 테스트, 배포의 순서를 거치면서 하나의 완성품으로 개발된다. 설계에 부합되게 구현되었는지 여부는 테스트 단계에서 TC(Test Case) 작성을 통해 확인한다.

소프트웨어 개발에 있어서 최종 단계로 인식되는 테스트 단계에서, 종래에는 일반적으로 각 단위 기능에 대한 유닛 테스트(unit test), 전체 시스템의 모든 단위 기능을 연동한 통합 테스트(integration test), 성능 및 비기능적 항목들에 대한 시스템 테스트(system test) 등의 범주로 크게 구분되어 진행된다.

즉, 구현 개발이 완료된 소프트웨어 코드에 대한 테스트를 위하여, 소프트웨 어 코드에 대한 유닛 테스트, 통합 테스트, 시스템 테스트 등의 단계를 진행하면서 오류를 수정하고 다시 이를 코드에 반영한다. 이로써 점진적으로 안정화된 소프트웨어 제품으로 수렴해 나가게 된다.

최근에는 소프트웨어의 규모가 방대해지면서, 기존의 개발 프로세스에 따른 테스트 방법의 운용상 한계점을 인식하고 이를 보다 효과적으로 수행하기 위한 기술과 방법들이 연구되고 있다. 이들 중 TDD(Test Driven Development)는 개발 프로세스상의 모든 영역에 걸쳐 테스트를 수행함으로써, 후반부에 집중되는 테스트 및 수정을 위한 막대한 비용 발생을 사전에 제거하는 데에 초점을 맞춘 방법이다. 이와 같은 종래 기술들은 모두 구현 코드에 대한 테스트에 초점을 맞추고 있다.

한편, 다양한 품종의 소프트웨어 제품(software product)을 개발하는 경우에는 공통의 플랫폼을 기반으로 하여 특징적인 부가기능을 구현하는 양상을 보인다. 이러한 소프트웨어의 품질 평가에 있어서 주요 요소들은 플랫폼 자체의 안정성과 더불어 새로운 기능의 신뢰성과도 관련된다. 그러나, CE 소프트웨어 개발에 있어서 종래 기술의 한계점은, 다품종 소프트웨어 제품들이 통합된 플랫폼에 대하여 정교한 설계의 검증이 이루어지기 힘들다는 것이다.

소프트웨어 개발에서 플랫폼은 개별적으로 각 소프트웨어 제품 자체만의 구조를 기술하는 것이 아니라, 기반 플랫폼과 모든 가변 요소들을 통합하는 구조를 표현할 수 있어야 한다. 이를 위해서는 가변성(variability)과 컴포넌트(component), 의존성(dependency), 설정(configuration) 등의 개념이 효과적으로 조합될 수 있는 컴포넌트 모델이 필요하며, 이러한 컴포넌트 모델을 토대로 구현과 더불어 플랫폼의 설계 구조에 대한 검증이 이루어질 수 있어야 한다.

따라서, 본 발명은 상기와 같은 문제점을 해결하기 위하여 고안된 것으로, 본 발명이 이루고자 하는 기술적 과제는 소프트웨어 개발에 있어서 체계적인 컴포넌트 모델을 통해 소프트웨어 플랫폼 아키텍처로부터 구현 자동화를 수행하고, 설계와 구현간의 정합성 검증을 지원하기 위한 방법 및 장치를 제공하는 것이다.

상기 기술적 과제는 본 발명에 따라, 컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 방법에 있어서, 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드를 생성하는 단계와; 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 생성하는 단계를 포함하는 것을 특징으로 하는 생성 방법에 의해 해결된다.

상기 템플릿 코드를 생성하는 단계는, 상기 컴포넌트 중 상위 컴포넌트 및 하위 컴포넌트의 포함관계를 나타내는 디렉토리 구조를 생성하는 단계와; 상기 컴포넌트가 요청하는 다른 컴포넌트의 인터페이스를 나타내는 의존관계를 나타내는 의존성 요소를 반영하는 단계와; 상기 설정 변수에 따라 상기 포함 또는 의존관계에 있는 복수개의 상기 컴포넌트를 선택하는 가변성 요소를 반영하는 단계를 더 포함하는 것이 바람직하다.

상기 빌드 스크립트를 생성하는 단계는, 상기 소프트웨어의 종류를 선택할 수 있는 타입 변수를 정의하는 단계와; 상기 타입 변수에 연동된 하위 설정 변수를 기술하는 단계와; 상기 컴포넌트에 대한 설정 변수 사이의 맵핑 관계에 따라 설정값을 지정하는 단계와; 상기 컴포넌트 각각의 소스 코드의 경로 정보를 설정하는 단계를 더 포함하는 것이 바람직하다.

상기 빌드 스크립트를 생성하는 단계는, 상기 가변성 요소를 반영하도록 상기 빌드 스크립트 내에 조건문 형식의 코드를 추가하는 것이 바람직하다.

상기 가변성 요소는, 소정의 컴포넌트를 상기 빌드 스크립트의 경로로부터 제외시키는 옵션 가변성 또는 상기 설정 변수의 설정값에 따라 소정의 컴포넌트를 선택하는 스위치 가변성을 포함하는 하는 것이 바람직하다.

상기 빌드 스크립트를 생성하는 단계는, 상기 컴포넌트가 복합(composite) 컴포넌트인 경우 하위 컴포넌트에 대한 빌드 스크립트를 재귀적으로 호출하도록 구성되거나, 기본(primitive) 컴포넌트인 경우 자신의 소스 코드에 대한 빌드 프로세스를 기술하도록 구성되는 것이 바람직하다.

한편, 본 발명의 다른 분야에 따른 기술적 과제는 컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처의 검증 방법에 있어서, 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 단계와; 상기 컴포넌트의 조합을 위해 상기 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 단계와; 상기 변경된 설정 변수에 기초한 상기 가상 소프트웨어 플랫폼의 실행 결과에 따라 상기 소프트웨어 플랫폼의 정합성을 검증하는 단계를 포함하는 것을 특징으로 하는 검증 방법에 의해 해결된다.

상기 설정 변수의 설정값을 변경하는 단계는, 상기 컴포넌트에 구비된 가변성 요소를 설정하는 단계와; 상기 설정에 따라 상기 가상 소프트웨어 플랫폼을 빌드하는 단계를 더 포함하는 것이 바람직하다.

상기 검증하는 단계는, 상기 소프트웨어 플랫폼의 설계 정보로부터의 획득된 호출 그래프 및 상기 실행으로 인한 함수 호출의 그래프를 비교하는 단계와; 상기 비교 결과에 기초하여 상기 소프트웨어 플랫폼의 의존성 또는 무결성을 판단하는 단계를 더 포함하는 것이 바람직하다.

상기 검증하는 단계는, 상기 소프트웨어의 제품 명세(product specification)의 내용과 상기 실행으로 인한 상기 컴포넌트의 디렉토리 구성을 비교하는 단계와; 상기 비교 결과에 기초하여 상기 변경된 설정값에 따른 소프트웨어의 제품에 대한 상기 설계 정보를 검사하는 단계를 더 포함하는 것이 바람직하다.

상기 컴포넌트 모델의 구성 요소인 컴포넌트, 인터페이스, 연결, 가변성 중 적어도 하나 이상의 구성 요소에 대한 목록을 관리하는 단계를 더 포함하는 것이 바람직하다.

상기 컴포넌트 모델의 구성 요소에 대한 목록을 관리하는 단계는, 상기 컴포넌트에 구비된 가변성 요소에 대응하는 변수를 정의하기 위한 언어 구문을 처리하는 단계를 더 포함하는 것이 바람직하다.

한편, 본 발명의 또 다른 분야에 따른 기술적 과제는 컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 장치에 있어서, 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드를 생성하는 코드 생성부와; 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 생성하는 빌드 스크립트 생성부를 포함하는 것을 특징으로 하는 생성 장치에 의해서도 해결된다.

한편, 본 발명의 또 다른 분야에 따른 기술적 과제는 컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처의 검증 장치에 있어서, 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 가상 플랫폼 생성부와; 상기 컴포넌트의 조합을 위해 상기 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 가상 플랫폼 설정부와; 상기 변경된 설정 변수에 기초한 상기 가상 소프트웨어 플랫폼의 실행 결과에 따라 상기 소프트웨어 플랫폼의 정합성을 검증하는 아키텍처 검증 관리부를 포함하는 것을 특징으로 하는 검증 장치에 의해서도 해결된다.

상기 컴포넌트 모델의 구성 요소인 컴포넌트, 인터페이스, 연결, 가변성 중 적어도 하나 이상의 구성 요소에 대한 목록을 관리하는 컴포넌트 모델 관리부를 더 포함하는 것이 바람직하며, 상기 컴포넌트 모델 관리부는 상기 컴포넌트에 구비된 가변성 요소에 대응하는 변수를 정의하기 위한 언어 구문을 처리하는 컴포넌트 언어 기술자를 더 포함하는 것이 바람직하다.

나아가 본 발명은 컴포넌트 모델 기반의 가상 소프트웨 플랫폼을 생성하는 방법 및 이를 이용한 소프트웨어 플랫폼 아키텍처의 검증 방법을 구현하기 위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록 매체를 포함한다.

본 발명에 의한 소프트웨어 플랫폼 아키텍처의 검증 방법 및 장치에 따르면, 다음과 같은 효과가 인정된다.

첫째, 본 발명은 다양한 소프트웨어 제품을 통합하는 소프트웨어 플랫폼 설계에 대한 검증에 있어서, 컴포넌트 모델이 포함하고 있는 설계 정보로부터 가상 플랫폼의 생성과 검증을 자동화할 수 있는 기술을 제안하고 있다. 따라서 종래의 소프트웨어 검증이 소프트웨어 플랫폼 아키텍처에 대해 이루어지지 못하고, 개별 코드에 대한 구현 후 테스트에 한정되었던 제약사항을 극복할 수 있다.

둘째, 소프트웨어 플랫폼은 방대한 소스 코드, 빌드 스크립트, 라이브러리 들의 집합체이며, 요소들의 조합으로 특정 요구에 부합하는 소프트웨어 제품의 개발이 가능하도록 하는 방식이 컴포넌트 모델의 목적이다. 컴포넌트 모델로 소프트웨어 제품의 구성 정보를 기술하고, 이로부터 해당 소프트웨어 제품의 정상적인 조합 구성이 가능한지를 선행적으로 검증함으로써, 테스트 비용과 인력 절감을 가능하게 한다.

셋째, 소프트웨어 플랫폼 설계 정보인 컴포넌트 모델로부터 가상 플랫폼이 생성되며, 가상 플랫폼은 실제 구현에 필요한 모든 토대를 갖추고 있어, 소프트웨어 구현에 있어서의 동기화와 정확성을 극대화할 수 있다.

넷째, 주요 S/W 설계 툴과 연계하여 기존 UML(Unified Modeling Language) 기반의 S/W 개발 프로세스상에서 관리하기 어려웠던 소프트웨어 플랫폼의 검증 기능을 확보할 수 있다.

본 발명과 본 발명의 동작상의 이점 및 본 발명의 실시에 의하여 달성되는 목적을 충분히 이해하기 위해서는 본 발명의 바람직한 실시예를 예시하는 첨부 도면 및 도면에 기재된 내용을 참조하여야 한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예에 대해 상세히 설명한다.

본 발명은 컴포넌트 모델을 기반으로 개발되는 CE 소프트웨어의 플랫폼 아키텍처를 SPL(Software Product Line) 측면에서 검증하기 위해, 직접적인 코드의 내부 구현 단계에 앞서 가상 플랫폼(virtual platform)의 생성(generation) 및 설정(configuration)을 통하여 컴포넌트 모델의 설계 정보에 대한 무결성과 신뢰성을 점검할 수 있는 방법 및 장치를 제공한다.

즉, 재사용성과 SPL 운영을 위한 컴포넌트 모델 기반 즉, CBSE(Component-Based Software Engineering)를 기반으로 하는 CE 소프트웨어 개발에 있어서 소프트웨어 플랫폼 아키텍처로부터 구현 자동화를 수행하고 설계와 구현간의 정합성 검증 및 관리를 지원하기 위한 해결방안을 제시한다.

도 1은 본 발명의 일 실시예에 따른, 소프트웨어 플랫폼 아키텍처의 검증 장치의 구성 모듈을 나타낸다.

소프트웨어 플랫폼 아키텍처의 무결성(integrity)와 신뢰성(reliability) 검증을 위해 본 발명은 기본적으로 가상 플랫폼 생성부(120), 가상 플랫폼 설정부(130), 아키텍처 검증 관리부(140)를 포함하며, 컴포넌트 모델 관리부(110)를 더 포함할 수 있다. 여기서, 가상 플랫폼 생성부(120)는 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 모듈이며, 가상 플랫폼 설정부(130)는 컴포넌트의 조합을 위해 상기 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 모듈이며, 아키텍처 검증 관리부(140)는 변경된 설정 변수에 기초한 가상 소프트웨어 플랫폼의 실행 결과에 따라 소프트웨어 플랫폼의 정합성을 검증하는 모듈이며, 컴포넌트 모델 관리부(110)는 컴포넌트 모델의 구성 요소인 컴포넌트, 인터페이스, 연결, 가변성 중 적어도 하나 이상의 구성 요소에 대한 목록을 관리하는 모듈이다.

상기 각 구성 모듈에 대한 구체적인 설명 및 하위 모듈에 대한 설명에 앞서, 본 명세서에서 사용되는 용어의 개념을 설명하면 다음과 같다.

설정 변수(Configuration Variable): 컴포넌트 모델로 기술된 소프트웨어 플랫폼 구성에 있어서 가변성(variability)을 표현하기 위해 사용된 변수이다.

가변성 포인트(Variability Point): 소프트웨어 제품을 구성하는데 있어서 가변적인 특성 또는 해당 특성이 존재하는 부분을 말한다.

소프트웨어 제품 라인(Software Product Line: SPL): 소프트웨어 제품은 기 본적으로 공통요소와 가변요소들을 모두 포함하는 소프트웨어 플랫폼으로부터, 개발 요구사항에 따라 선별적으로 조합된 요소들로 구성되는데, 이들 다양한 소프트웨어 제품들은 공통요소를 가지고 있으므로 소정의 제품군(product family)을 구성하게 된다. SPL은 이와 같이 소프트웨어 플랫폼으로부터 다양한 제품을 개발하기 위한 소프트웨어 요소 관리 및 구성 체계를 의미한다.

소프트웨어 컴포넌트(Software Component): 소프트웨어 제품은 수많은 소스 코드(source code)와 빌드 스크립트(build script), 라이브러리(library) 등으로 구성된다. 소프트웨어 컴포넌트는 물리적인 코드 파일(code file)이나 스크립트(script) 또는 디렉토리(directory) 단위 자체를 나타내는 것이 아니라, 기능적 측면에서 분할된 단위이다. 따라서 여러 개의 디렉토리가 하나의 컴포넌트가 될 수도 있고, 하나의 소스 코드가 하나의 컴포넌트로 규정될 수도 있다.

기본/복합 컴포넌트(Primitive/Composite Component): 단위 컴포넌트를 기본 컴포넌트(primitive component)라고 하며, 이들 기본 컴포넌트들을 조합하여 복합 컴포넌트(composite component)를 구성할 수 있다.

제공/요청 인터페이스(Provide/Require Interface): 컴포넌트간의 연결 관계를 기술함에 있어서, 특정 컴포넌트가 공급하는 기능들은 제공 인터페이스(provide interface)로 표현하고, 특정 컴포넌트가 다른 컴포넌트의 기능을 사용할 경우는 요청 인터페이스(require interface)로 표현한다. 이하 컴포넌트 모델을 나타내는 도면에 있어서, 제공 인터페이스인 경우에는 "ip"(interface provided), 요청 인터페이스인 경우에는 "ir"(interface required0라는 접두사(prefix)를 사용하여 표 시한다.

루트 복합 컴포넌트(Root Composite Component): 소프트웨어 제품 자체는, 내부에 기본 컴포넌트와 서브 복합(sub composite) 컴포넌트들을 가지는 가장 큰 규모의 최상위 복합 컴포넌트라고 할 수 있다. 이를 루트 복합 컴포넌트라고 지칭한다.

FLC(Functional-Level Component): 컴포넌트 모델 설계에 필요한 논리적인 단위로서, 전체 시스템을 구성하는 각 기본 컴포넌트와 복합 컴포넌트들은 모두 FLC에 속한다.

BLC(Build-Level Component): FLC의 실제 구현체로서의 컴포넌트 단위로, 기본 컴포넌트(primitive component)들에 대해서만 대응관계를 가진다. 컴포넌트의 조합에 있어서, 하나의 FLC는 자신의 기능을 구현한 적어도 하나 이상의 BLC와 맵핑(mapping)된다.

CDL(Component Description Language): FLC 컴포넌트 구성을 기술하기 위한 규정이다. 기본 컴포넌트의 경우는 제공 인터페이스 또는 요청 인터페이스 정보만으로 표현되나, 복합 컴포넌트의 경우에는 하위 컴포넌트의 상호 연결 관계 및 설정 변수의 정보 등이 추가로 표현된다.

IDL(Interface Description Language): 모든 기본 컴포넌트들이 공급하는 제공 인터페이스들은 실제 어떠한 기능들을 포함하는지 상세 내역을 기술하여야 하며, 이들 정보들이 IDL에 표현된다.

BCDL(Build-Level Component Description Language): FLC 구성이 CDL에 의해 표현된다면, 각 컴포넌트들의 실제 구현체인 BLC의 정보는 BCDL을 통해 표현된다. BCDL은 특정 컴포넌트의 구현을 위한 소스, 라이브러리, 빌드 정보 등을 포함한다.

도 1를 참조하면, 컴포넌트 모델 관리부(110)는 소프트웨어 플랫폼 아키텍처 설계에 있어 컴포넌트 모델을 기반으로 구성되는 모든 요소들을 관리하는 모듈이다. 컴포넌트 모델 관리부(110)는 컴포넌트 핸들러(Component Handler, 111), 인터페이스 핸들러(Interface Handler, 112), 연결 핸들러(Connection Handler, 113), 가변성 핸들러(Variability Handler, 114)와 연계하여 컴포넌트 모델 요소인 컴포넌트, 인터페이스, 연결, 가변성 각 요소의 추가, 변경, 제거 등의 목록을 관리하며, 플랫폼 아키텍처 전체 구성 정보를 관리한다.

컴포넌트 핸들러(111)는 컴포넌트 모델 관리부(110)를 통해 관리되는 컴포넌트 모델의 구성 요소 정보들 중, 컴포넌트 요소들의 목록 및 특성 정보를 관리하는 모듈이다.

소프트웨어 플랫폼 내의 각 컴포넌트는 기본적으로 기본 컴포넌트 및 복합 컴포넌트로 구성되며, 복합 컴포넌트는 계층적인 디렉토리 구조와 더불어 서브 시스템 구성을 반영하게 된다. 컴포넌트 핸들러(111)는 이들 컴포넌트들간 연동 정보를 파악하고 관리한다.

인터페이스 핸들러(112)는 컴포넌트 모델 관리부(110)를 통해 관리되는 컴포넌트 모델의 구성 요소 정보들 중, 인터페이스 요소들의 목록 및 특성 정보를 관리하는 모듈이다.

인터페이스는 컴포넌트가 제공하는 기능과 필요로 하는 기능을 함수 집 합(function set)으로 기술하는 요소이며, 컴포넌트간 상호작용을 위한 도구가 된다. 인터페이스 핸들러(112)는 인터페이스 요소의 목록 및 컴포넌트와 인터페이스간의 연결 정보를 관리한다.

연결 핸들러(113)는 컴포넌트 모델 관리부(110)를 통해 관리되는 컴포넌트 모델의 구성 요소 정보들 중, 컴포넌트간의 의존관계를 표현하는 연결 요소들의 목록 및 특성 정보를 관리하는 모듈이다.

연결은 인터페이스간의 연결 자체를 의미하는 것으로, 컴포넌트 모델 내에서 실제 연동 관계의 존재를 나타내는 요소이다. 연결 핸들러(113)는 연결 요소의 목록 및 정보를 관리한다.

가변성 핸들러(114)는 컴포넌트 모델 관리부(110)를 통해 관리되는 컴포넌트 모델의 구성 요소 정보들 중, 가변성 요소들의 목록 및 특성 정보를 관리하는 모듈이다.

가변성은 소프트웨어 플랫폼의 공용부와 가변부를 구분할 수 있는 요소이며, 가변성이 설정된 컴포넌트를 다양하게 선택함으로써 소프트웨어 플랫폼 설계 정보 내에 모든 컴포넌트들이 통합될 수 있는 기반을 제공한다. 가변성 핸들러(114)는 가변성 요소의 목록 및 각 가변성의 설정 조건 정보를 관리한다.

컴포넌트 언어 기술자(Component Language Descriptor)(115)는 컴포넌트 모델을 기술하기 위한 언어 처리를 담당하는 모듈이다. 기본적으로 기본 컴포넌트 및 복합 컴포넌트의 구성 정보를 포함하며, 가변성 포인트에 대응하는 변수를 정의하는 구문 형식을 지원한다. 가변성 포인트가 포함된 복합 컴포넌트에 있어서 표 현되는 구문 블록으로서, 구체적으로 "contains"는 복합 컴포넌트가 내부에 포함하는 하위 컴포넌트 목록을 나타내고, "provides"는 컴포넌트의 제공 인터페이스로서 복합 컴포넌트의 경우에는 하위 컴포넌트들로부터 제공되는 제공 인터페이스들의 목록을 나타내고, "requires"는 컴포넌트의 요청 인터페이스로서 복합 컴포넌트의 경우에는 하위 컴포넌트들로부터의 요청 인터페이스들의 목록을 나타내고, "connects"는 제공/요청 인터페이스간의 연결 관계를 기술하고, "configuration-variables"는 가변성 포인트에 대응될 변수와 값의 목록을 기술한다.

컴포넌트 언어 기술자(115)는 CDL(Component Description Language), IDL(Interface Description Language), BCDL(Build-level Component Description Language), PCL(Product Configuration Language)들의 구문 처리 및 생성을 담당한다.

가상 플랫폼 생성부(120)는 소프트웨어 플랫폼 아키텍처 설계의 신뢰성을 검증하기 위한 가상 플랫폼 생성을 담당하는 모듈이다. 컴포넌트 모델로 구성된 소프트웨어 플랫폼의 설계 구조에 따라, 컴포넌트 의존성과 가변성 설정 등의 요소가 모든 설정 경로(configuration path)를 만족할 수 있는지를 검증한다. 이를 위해 기본적으로 컴포넌트별 소스 코드 및 빌드 스크립트를 생성하고, 가변성 요소의 설정에 따른 구성을 준비한다.

가상 플랫폼 생성부(120)는 필요한 구성 항목들을 파악하고, 코드 생성부(121)나 빌드 스크립트 생성부(122)와 같은 연동 모듈들에게 생성 작업을 요청하는 기능을 수행한다. 가상 플랫폼 생성부(120)는 아키텍처 검증 관리부(140)로부 터의 플랫폼 검증 요구에 의해 동작된다.

코드 생성부(121)는 가상 플랫폼 생성부(120)와 연동하여, 컴포넌트 모델에 대응하는 실제 물리적인 소스 코드의 구성과 생성을 담당하는 모듈이다.

코드 생성부(121)는 도 4부터 도 9까지의 각 작업들과 관련되며, 실제 디렉토리 생성, 소스 코드 내부의 조건문(conditional statement) 처리, 컴포넌트 의존성에 따른 헤더 포함(header inclusion), 함수 호출 무결성 확인(function call integrity check) 코드 추가 등의 기능을 수행한다.

빌드 스크립트 생성부(122)는 가상 플랫폼 생성부(120)와 연동하여, 컴포넌트 모델에 대응하는 물리적인 빌드 스크립트 구성과 생성을 담당하는 모듈이다.

빌드 스크립트 생성부(122)는 도 10부터 도 16의 각 작업과 관련되며, 컴포넌트별 빌드 스크립트의 생성 및 빌드 스크립트 내부의 조건문 처리 등의 기능을 수행한다. 빌드 스크립트 생성은 컴포넌트 모델의 가변성 구성 형태를 반영하여 계층적 구성을 가진다.

가상 플랫폼 설정부(130)는 컴포넌트 모델의 가변성을 특정 상태로 설정하고, 이때의 플랫폼 구성이 설계에 따라 정상적으로 실행될 수 있는지를 확인하기 위한 설정과 빌드(build) 기능을 담당한다.

설계 정보의 검증 측면에서 모든 내부 구현이 완료된 시점의 테스트와는 다른 개념으로서, 가변성에 따라 조합 구성된 컴포넌트 소스 코드와 빌드 스크립트들이 오류를 발생시키지 않는지를 확인함으로써 검증을 수행하는 것이다.

가상 플랫폼 설정부(130)는 아키텍처 검증 관리부(140)로부터의 플랫폼 검증 요구에 따라, 가상 플랫폼 생성부(120)를 통한 가상 플랫폼이 생성된 이후에 동작하게 된다.

아키텍처 검증 관리부(140)는 소프트웨어 제품 목록별로 컴포넌트 모델에 포함된 설정 변수의 설정에 대해, 각각 설계에 부합하는 정상적인 컴포넌트 조합 및 빌드가 가능한지를 확인하여 플랫폼 검증을 담당한다.

가상 플랫폼 생성부(120)와 가상 플랫폼 설정부(130)를 통해, 가상 플랫폼의 생성과 설정을 수행토록 하여 그 결과를 분석 판단한다.

의존성/무결성 확인부(141)는 의존성/무결성 확인부(Dependency Integrity Checker)는 소스 코드들간 함수 호출 관계가 설계한대로 이루어지는지 여부를 판단하는데, 설계 정보로부터의 호출 그래프 및 실제 호출에 의해 기록된 호출 그래프를 비교함으로써 판단한다.

가상 제품 검증부(142)는 가상 플랫폼의 설정과 필드가 수행되면, 각 제품 명세(specification)를 기술한 PCL 설정에 따라 설계한대로 적절한 컴포넌트를 포함하는지 여부와 설정 변수의 설정이 정상적으로 이루어졌는지 여부를 확인한다.

도 2는 본 발명의 다른 실시예에 따른, 컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 방법을 설명하기 위한 플로우 차트이다.

본 발명의 실시예에 따른, 가상 소프트웨어 플랫폼을 생성하는 방법은 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드를 생성하는 단계(210)와 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 생성하는 단 계(220)를 포함한다. 각 단계에 대한 설명은 이하 도 4 내지 도 16을 참조하여 상세히 설명하도록 한다.

도 3은 본 발명의 다른 실시예에 따른, 컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처의 검증 방법을 설명하기 위한 플로우 차트이다.

본 발명의 실시예에 따른, 소프트웨어 플랫폼 아키텍처의 검증 방법은 소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 단계(310)와 컴포넌트의 조합을 위해 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 단계(320)와 변경된 설정 변수에 기초한 상기 가상 소프트웨어 플랫폼의 실행 결과에 따라 소프트웨어 플랫폼의 정합성을 검증하는 단계(330)를 포함한다.

나아가 상기 검증 방법은 컴포넌트 모델의 구성 요소인 컴포넌트, 인터페이스, 연결, 가변성 중 적어도 하나 이상의 구성 요소에 대한 목록을 관리하는 단계 더 포함할 수 있다.

본 발명의 실시예인 소프트웨어 플랫폼 아키텍처 검증이란, 소프트웨어 제품의 설계 정보들이 모두 포함된 통합 플랫폼의 구성 정보에 대한 신뢰성을 확인하는 것을 의미한다. 여기서 신뢰성이란, 통합된 플랫폼의 구성으로부터 개별 제품의 도출이 가능함을 가리킨다.

소프트웨어 플랫폼의 설계 구성 정보는 해당 플랫폼을 기반으로 하는 소프트 웨어 제품의 조합(composition)을 위한 설정 요소 및 상기 설정 정보의 표현을 위한 가변성 요소로 기술되며, 컴포넌트 모델은 이들 요소를 체계적으로 연동 관리할 수 있는 기반이 된다.

설계 정보로부터 구현을 진행하는 하향식(Top-Down) 프로세스에 있어서, 소프트웨어 플랫폼의 설정이 수행되어 각 소프트웨어 제품에 적합한 컴포넌트 조합이 이루어지는지 여부를 확인하는 작업은 컴포넌트 자체의 내부 구현보다 선행되어야 한다. 설계 정보만을 이용하여 아직 생성되지 않은 소프트웨어 플랫폼을 검증해야 하는 상황에서, 가상(virtual) 소프트웨어 플랫폼의 필요성이 대두된다.

소프트웨어 플랫폼 아키텍처 검증에 수반되는 절차에는 가상 플랫폼을 생성하는 단계와 가상 플랫폼을 설정하는 단계가 있다. 가상 플랫폼을 생성하는 단계는 아키텍처 설계 정보에 기반하여 컴포넌트 모델의 가상적인 골격 구조를 생성하는 단계를 말하며, 가상 플랫폼을 설정하는 단계는 아키텍처 설계 정보에 기반하여 소프트웨어 제품 조합을 구성하는 단계를 말한다.

본 발명을 구성하는 각 모듈간 상호작용을 통하여 소프트웨어 플랫폼 아키텍처의 설계 구성정보인 컴포넌트 모델의 검증을 수행하는 전체 동작 절차는 다음과 같다.

1) 컴포넌트 모델 관리부(Component Model Manager, 110)는 소프트웨어 플랫폼 설계를 담당하는 사용자에 의해 컴포넌트 모델 편집 및 변동 내역을 관리하고, 컴포넌트 언어 기술자(Component Language Descriptor, 115)를 통해 변경된 컴포넌트 모델을 기술한다.

2) 컴포넌트 모델 관리부(110)는 컴포넌트 모델에 포함된 구성 요소 각각의 정보를 독립적으로 관리할 수 있도록 컴포넌트 핸들러(Component Handler, 111), 인터페이스 핸들러(Interface Handler, 112), 연결 핸들러(Connection Handler, 113), 가변성 핸들러(Variability Handler, 114)를 통해 구성 요소별 목록 및 세부정보를 분석하도록 한다.

3) 아키텍처 검증 관리부(Architecture Validation Manager, 140)를 통해 컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처 검증을 수행한다. 아키텍처 검증 관리부(140)는 가상 플랫폼 생성부(Virtual Platform Generator, 120)에게 작업을 요청한다.

4) 가상 플랫폼 생성부(120)를 통해 컴포넌트 모델에 기반한 템플릿 코드(template code) 및 빌드 스크립트(build script) 생성 작업이 이루어진다.

5) 가상 플랫폼 생성부(120)의 요청에 의해, 코드 생성부(Code Generator, 121)는 계층 구조에 따른 디렉토리 및 소스 코드 생성, 가변성 설정의 반영, 의존성 설정의 반영 작업을 수행한다.

6) 가상 플랫폼 생성부(120)의 요청에 의해, 빌드 스크립트 생성부(Build Script Generator, 122)는 가변성 설정 및 계층 구조에 따른 빌드 스크립트를 생성한다. 생성되는 빌드 스크립트에는 전체 플랫폼 설정을 위한 빌드 스크립트와 각 컴포넌트별 빌드 스크립트들이 모두 포함된다.

7) 가상 플랫폼의 생성 완료 후에는, 아키텍처 검증 관리부(140)를 통해 가상 플랫폼 설정부(Virtual Platform Configurator, 130)에게 가상 플랫폼의 설정 및 소프트웨어 제품 생성 검증을 요청한다.

8) 가상 플랫폼 설정부(130)는 빌드 스크립트들 가운데 Makefile.config_decision에 기술된 소프트웨어 제품 설정을 위한 최상위(top-level) 설정 변수의 설정값을 변경하고 빌드(build)를 수행한다.

9) 의존성/무결성 확인부(Dependency Integrity Checker, 141)는 빌드 완료된 소프트웨어 제품의 실행 파일을 호출하여, 템플릿 함수(template function)들의 호출 그래프(call graph)가 설계 구성에 부합하는지를 확인한다.

10) 가상 소프트웨어 플랫폼의 빌드 수행 후, 가상 제품 검증부(Virtual Product Verifier, 142)는 소프트웨어 제품의 명세(product specification)를 정의한 PCL 기술 내용과 실제 디렉토리 구성을 비교한다.

11) 최종적으로 아키텍처 검증 관리부(140)는 의존성/무결성 확인부와 가상 제품 검증부의 점검 결과를 바탕으로, 해당 소프트웨어 플랫폼의 설계 검증 결과를 판단한다.

가상 소프트웨어 플랫폼 생성 과정은 소프트웨어 플랫폼 아키텍처 구성을 위한 컴포넌트 모델 설계가 이루어진 후, 아키텍처 검증 관리부에 의해 검증 기능이 요청되어 실행되는 각 단계를 나타내는 것으로서 아래에서 각 항목들을 세부적으로 살펴보도록 한다.

도 4는 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 물리적 디렉토리 구조를 나타낸다.

컴포넌트 사이의 물리적 디렉토리 구조(420) 생성하는 과정은 컴포넌트 모 델(410)로 설계된 소프트웨어 플랫폼 구조에 따라, 계층적인 형태로 각 컴포넌트의 정의 및 컴포넌트의 경로와 배치를 결정하는 절차이다.

컴포넌트 모델은 최상위 복합 컴포넌트인 루트 복합 컴포넌트를 최상위 디렉토리로 설정하고, 그 내부 설정의 계층 구조에 따라 순차적으로 하위 컴포넌트들에 대한 디렉토리를 생성하게 된다. 최하위에 놓여지는 각 기본 컴포넌트들은 가상 플랫폼 생성시의 조건 설정에 따라, 헤더 파일(header file)과 소스 파일(source file)을 위한 별도 하위 디렉토리를 가질 수도 있다.

여기서, 도 4는 소프트웨어 플랫폼으로서의 최상위 복합 컴포넌트 T 및 내부 컴포넌트 설정에 따른, 디렉토리 구조를 생성하는 예를 나타내고 있다. 하위 컴포넌트는 상위 컴포넌트의 디렉토리 내부에 생성되어 배치되며, 이때 생성된 상대 경로(path)는 이후의 BLC(Build-Level Component)를 정의하는데 있어 참조 정보로 사용된다.

도 5는 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 BLC 적용예를 나타낸다.

도 5에서는 BLC 정보를 기술하기 위한 BCDL과 파일리스트(filelist) 문서들의 내부 기술 형식을 나타내고 있다. 컴포넌트 조합 측면에서 볼 때, BLC는 자신 이외의 상대 경로가 기입되지 않은 기본형 BCDL 및 파일리스트를 먼저 생성한 후 BLC 컴포넌트 저장소(repository)에 저장된다(510). 이후 컴포넌트 모델 내에 배치됨으로써 상대 경로가 지정되고, BCDL과 파일리스트는 상대 경로를 반영한 형태로 수정되어 해당 소프트웨어 플랫폼 구조 내에서의 유일한 위치를 부여받게 된 다(520). 이렇게 함으로써, 새로운 소프트웨어 플랫폼을 위한 컴포넌트 모델 설계시에는 또 다른 상대 경로를 반영한 BCDL과 파일리스트가 생성될 수 있다.

도 6은 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 템플릿 코드를 나타낸다.

각 컴포넌트에 대응되는 디렉토리 구조가 생성됨과 동시에, 각 디렉토리 내부에는 해당 컴포넌트의 기능을 구현하는 템플릿 코드의 생성이 자동적으로 이루어지게 된다. 이들 코드는 컴포넌트의 기능을 정의한 IDL(Interface Definition Language)의 함수 집합(function set)들을 기술한다(610). 각 컴포넌트의 템플릿 코드는 헤더 파일과 소스 파일의 쌍으로 구성되는데(620), 기본적으로 함수 집합 목록들이 헤더 파일에 나열되고 소스 파일 내에는 각 함수의 구현을 위한 비어 있는 구문 블록들이 나열된다.

도 6는 A1 컴포넌트에 대한 템플릿 코드의 생성예를 나타낸다. A1 컴포넌트는 I_A1 인터페이스를 제공하고 있으며, I_A1.IDL에서 I_A1 인터페이스는 func1_A1, func2_A1, func3_A1 함수 집합을 포함하는 것으로 정의되어 있다. 템플릿 코드 중 헤더 파일(A1.h)은 인터페이스 정의에 따라 세 개의 함수 목록을 포함하고 있으며, 소스 파일(A1.cpp)은 실제 내부의 구현 없이 각 함수에 대한 블록만을 포함하게 된다. 이때 생성된 템플릿 파일 목록들은 이후의 BLC(Build-Level Component)를 정의하는데 있어서 참조 정보로 사용된다.

도 5을 다시 참조하면, BLC를 기술하기 위한 BCDL 및 파일리스트 내부에, 해당 BLC를 위한 헤더 파일과 소스 파일 목록이 포함되어 있다. 이들 파일 목록 자 체는 디렉토리 구조의 변화와는 관계없이 항상 일정하게 유지되며, 디렉토리 구조를 반영한 상대 경로만이 파일 목록 앞에 추가된다.

도 7은 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 컴포넌트 의존성을 나타낸다.

제공 인터페이스(ip)와 요청 인터페이스(ir) 사이의 연결로 표현되는 컴포넌트간의 의존성(dependency)관계는(710), 실제 코드에서는 헤더 파일 참조 및 함수 호출(function call)로 나타나게 된다. 즉, 특정 컴포넌트의 함수를 사용하는 다른 컴포넌트의 소스 코드 내부에는, 대상 컴포넌트의 헤더 파일에 대한 참조와 해당 함수에 대한 호출이 포함된다(720).

도 7에는 참조 관계를 가지는 컴포넌트들의 템플릿 코드 내부를 나타내고 있다. A2 컴포넌트는 A1 컴포넌트가 제공하는 I_A1 인터페이스를 요청하고 있으며, B1 컴포넌트는 I_A2 인터페이스를 요청하고 있다. 각 컴포넌트의 템플릿 코드 내부에는 참조 대상 컴포넌트의 헤더 파일을 "include" 구문으로 포함하는 형태로 기술된다.

도 8은 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 옵션 가변성(option variability)을 나타낸다.

본 발명이 제안하는 컴포넌트 모델 기반의 가상 플랫폼 생성은, 최종적으로 템플릿 코드들의 빌드를 통해 오류 발생 여부를 확인함으로써 소프트웨어 플랫폼 아키텍처를 검증하는 것이다. 이를 위해서 템플릿 코드의 빌드 작업을 수행할 수 있는 빌드 스크립트(build script)의 생성이 자동적으로 이루어져야 한다.

컴포넌트 모델에서 가변성은 "옵션(Option)"과 "스위치(Switch)" 두 가지로 구분할 수 있다. 이들 중 옵션 가변성은 지정된 컴포넌트가 설정 변수의 설정값에 따라, 소프트웨어 제품의 컴포넌트 조합에 포함되지 않을 수도 있음을 의미한다(810). 이것은 빌드 스크립트를 통해, 해당 컴포넌트의 소스 코드에 대한 빌드 경로를 제외시키는 방식으로 처리될 수 있다. 이러한 옵션 가변성을 반영하기 위해서 빌드 스크립트 내에 조건문(conditional statement)을 포함시킨다(820).

도 8에서는 옵션 설정된 컴포넌트 A1과 B2에 대해, 빌드 스크립트 내부에서 대상 컴포넌트들의 경로가 제어되도록 컴포넌트 모델의 설정 변수를 반영한 예이다.

도 9는 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 스위치 가변성(switch variability)을 나타낸다.

스위치 가변성은 2개 이상의 컴포넌트로부터 제공되는 인터페이스 중 조건에 따라 택일하여 요청 인터페이스와 연결하기 위한 용도로 사용된다.(910) 스위치 가변성 자체로는, 선택되지 않은 인터페이스와 컴포넌트를 컴포넌트 조합 구성에서 제외시키지 않는다. 즉, 스위치로 연결되는 컴포넌트들은 모두 컴포넌트 조합에 포함되며, 다만 설정 변수의 설정값에 따라 실제로 이용되는 인터페이스가 달라지게 될 뿐이다. 즉, 상기 설명한 옵션 가변성을 별도로 지정하지 않은 경우에 빌드 스크립트 경로로부터 제외되지는 않는다(920).

도 9는 스위치 설정된 컴포넌트 A1과 A2가 상호 배타적으로 B1 컴포넌트와 연결될 수 있는 구성에서, 실제 B1이 참조하는 헤더 파일들에 대한 템플릿 코드를 표현한 예이다. ipI_A1과 irI_A의 인터페이스는 호환성이 있으며, ipI_A2와 irI_A의 인터페이스도 호환성이 있어서 연결 가능하다고 전제한다.

도 10은 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 빌드 스크립트 생성 구조를 나타낸다.

앞서 옵션 가변성을 반영하기 위해서 빌드 스크립트 내에 조건문을 포함시킨 바 있다. 전체 빌드 스크립트 생성의 계층적 구조는 도 10과 같이 이루어진다. 소프트웨어 플랫폼에 대한 컴포넌트 모델에서는, 상위 설정 변수들이 하위 설정 변수들과 맵핑 관계를 통해 설정 작업을 대행할 수 있다. 각 소프트웨어 제품에 대한 설정 변수 설정 및 FLC-BLC간 맵핑 작업은 PCL(Product Configuration Language)로 기술된다. SPL(Software Product Line) 측면에서 소프트웨어 플랫폼에 대한 컴포넌트 모델의 상위 설정 변수는, 소프트웨어 제품 타입 또는 모델 타입으로 취급할 수 있다.

이하, 도 11부터 도 16에서와 같이 빌드 스크립트의 생성은 컴포넌트 모델의 구조적인 특성을 반영하여, 각각 config_decision, config_option, config_mapping, config_path 및 각 컴포넌트별 빌드 스크립트로 구성된다. 아래에서 실시예를 통해 makefile에 대한 상세 구성을 설명한다. makefile 이란, 전체 빌드 프로세스를 시작하기 위한 출발 지점으로서, 빌드 경로의 최상위 경로 및 빌드 결과물의 위치 정보를 기술한다.

Makefile.config_decision: 최상위 설정 변수의 설정값을 선택할 수 있는 결정 포인트(decision point) 역할을 담당한다.

Makefile.config_option: 최상위 설정 변수와 맵핑 관계에 있는 설정 변수들 가운데, 직접적으로 제품의 특성으로서 분류된 항목들의 설정값 집합을 기술하는 역할을 담당한다.

Makefile.config_mapping: 컴포넌트 모델 내의 다른 모든 설정 변수 간의 맵핑 관계에 따라 최하위 설정 변수들의 설정값을 기술하고, 이와 더불어 기본 컴포넌트들의 조합 여부를 함께 기술하는 역할을 담당한다.

Makefile.config_path: 해당 소프트웨어 플랫폼 내의 모든 컴포넌트들에 대한 소스 코드의 경로 정보를 기술하는 역할을 담당한다.

Makefile: 복합 컴포넌트의 경우 하위 컴포넌트들에 대한 빌드 스크립트(makefile)를 재귀적으로 호출하는 구성을 가지며, 기본 컴포넌트는 자신의 소스 코드에 대한 빌드 프로세스를 기술하는 빌드 스크립트 구성을 가진다.

이하, 도 11 내지 도 16에서 살펴보겠지만 위의 각 빌드 스크립트들은, 도 10에서의 참조 번호 1010 내지 1050의 순서로 상위 빌드 스크립트를 참조하여 실행에 필요한 변수 및 설정 정보를 파악할 수 있다. Makefile의 경우는 "include" 구문을 이용하여 자신보다 선행하는 makefile을 참조한다.

도 11은 소프트웨어 제품 선택을 위한 빌드 스크립트인 makefile.config_decision 구성의 실시예를 나타낸다.

도 11은 소프트웨어 플랫폼으로부터 특정 소프트웨어 제품을 위한 컴포넌트 조합을 수행할 수 있도록, 해당 제품 타입을 선택하여 기술할 수 있는 Makefile.config_decision의 구성을 나타내고 있다. 소프트웨어 플랫폼 설계 정보 를 담고 있는 컴포넌트 모델은, 최상위 컴포넌트의 CDL로 기술된다(1110). PRODUCT_TYPE 변수는 소프트웨어 제품에 따라 설정값이 달라지게 될 하위 변수들의 값들을 분류하여 연동시키고 있으며, PRODUCT_TYPE 변수가 가질 수 있는 값들의 목록대로 Makefile.config_decision 내에는 ②와 같이 주석 처리된 형태의 실행 라인이 추가된다. PRODUCT_TYPE 변수로 설정된 기본값(default value)은 ①과 같이 주석이 없는 실행 라인으로 추가된다(1120).

도 12는 소프트웨어 제품 설정을 위한 빌트 스크립트인 makefile.config_option 구성의 실시예를 나타낸다.

도 12는 최상위 컴포넌트의 CDL(1210) 내에 포함된, PRODUCT_TYPE의 각 값에 연동된 하위 변수들의 설정 목록을 기술하는 Makefile.config_option의 구성을 나타내고 있다. 이때, ④와 같이 매크로(macro)를 설정하기 위한 실행 라인이 추가되는데, 이 단계에서는 PRODUCT_TYPE의 설정값이 반영된 매크로가 선언된다. 매크로는 빌드 스크립트 내에서 선언되어 소스 파일 내부에서 참조하여 활용할 수 있는 운영체제의 매커니즘이다. ①은 선행되는 Makefile.config_decision을 참조함으로써, 어떠한 PRODUCT_TYPE이 선택되었는지를 확인할 수 있다(1220).

도 13은 설정 변수의 맵핑을 위한 빌드 스크립트인 makefile.config_mapping 구성의 실시예를 나타낸다.

도 13은 최상위 컴포넌트에 포함된 하위 컴포넌트(1310)들에 분포된, 다른 설정 변수들 사이의 맵핑 관계에 따른 설정값을 기술하는 Makefile.config_mapping을 나타내고 있다. ①은 선행되는 Makefile.config_option에서 결정된 설정값들을 참조하기 위해 포함된다. ②와 ③은 각각 복합 컴포넌트와 기본 컴포넌트를 위해 생성된 설정 변수들의 구성을 보여주고 있다. ②는 CDL 구성과 동일한 형태로, 상위(Level1) 설정 변수의 설정값에 따라 하위(Level2) 설정 변수들이 가지게 되는 값들을 지정하고 있다. 소프트웨어 플랫폼 내의 모든 복합 컴포넌트에 대한 설정 변수의 맵핑 관계가 이와 같은 방식으로 모두 기술된다. ③은 가장 하위에 위치하게 되는 기본 컴포넌트의 가변성 조정을 위한 설정 변수와 그 설정값에 따른 매크로 설정을 나타내고 있다. 컴포넌트에 대한 가변성은 기본적으로 컴포넌트의 조합 과정에 참여 여부를 표현하기 위한 옵션 가변성을 확장한 것이다. 즉, 계층적 구조와 설정 변수간의 관계를 통해, 최종적으로 하위의 기본 컴포넌트가 포함되는지를 결정하기 위한 것이다. 해당 기본 컴포넌트가 포함되는 설정값의 경우, ④와 같이 매크로를 선언함으로써 소스 파일 내부에서 참조하여 활용할 수 있다. 이때, 매크로들을 누적하여 포함하기 위해 "DEFINE" 변수는 "+="을 사용한다(1320).

도 14는 컴포넌트 빌드 경로를 위한 빌드 스크립트인 makefile.config_path 구성의 실시예를 나타낸다.

도 14는 각 컴포넌트의 실제 소스 코드가 위치한 경로를 지정해 주기 위한 Makefile.config_path의 구성을 나타내고 있다. ①은 선행되는 Makefile.config_mapping을 참조하기 위해 포함된다. ②는 소스 코드를 빌드하기 위한 운영체제의 컴파일러(compiler)를 지정하고 있으며, ③은 최상위 컴포넌트가 위치하게 될 실제 시스템 내에서의 경로 및 빌드 과정에 필요한 경로 정보를 기술한다. ②와 ③은, 가상 플랫폼 생성부가 제공하는 사용자 입력 도구를 통해 설정 할 수 있다. ④는 복합 컴포넌트의 경로 정보의 구성을 나타내고 있는데, 최종적으로 빌드되어 생성될 라이브러리 파일 목록 역시 설정 변수의 설정에 따라 포함되는지 여부가 결정되도록 자동적으로 설정된다. 여기서도 하위 컴포넌트의 라이브러리를 누적하여 포함하기 위해 "+="을 사용한다. ⑤는 기본 컴포넌트의 경로 정보 구성을 나타낸다. 이들 경로 정보는 각 복합 컴포넌트 및 기본 컴포넌트의 개별 makefile 내부에 사용되어, 필요한 위치 정보를 제공하게 된다.

도 15는 복합 컴포넌트의 makefile 구성의 실시예을 나타낸다.

도 15를 참조하면, 상위(Level1)의 복합 컴포넌트는 하위(LevelN)에 포함된 컴포넌트들의 설정 변수 설정값에 따라, 해당 컴포넌트의 makefile 호출 여부가 결정되도록 자동 구성된다. ①은 빌드 대상 소스 코드들의 위치 경로를 파악하기 위해 포함된다. ②는 makefile의 기본 진입 경로로서 일반적인 "all" 빌드 타겟(build target)을 포함시킨 것이며, 실제로는 ③의 해당 컴포넌트 이름과 동일한 빌드 타겟을 가리킨다. ④는 생성된 라이브러리 파일을 제거하기 위한 빌드 타겟이다.

도 16은 기본 컴포넌트의 makefile 구성의 실시예을 나타낸다.

도 16을 참조하면, 기본 컴포넌트는 ①에서 경로 정보 참조를 위해 Makefile.config_path를 포함하고 있으며, ②에서는 자신의 경로에 존재하는 소스 파일 목록 및 헤더 파일 참조를 위한 경로를 구성하고 있다. ③에서는 라이브러리 파일의 생성을 실행하며, ④에서는 라이브러리 파일 제거를 위한 실행 라인을 구성한다.

도 17은 호출 그래프 무결성 확인(call graph integrity check) 코드의 실시예를 나타낸다.

도 17을 참조하면, 컴포넌트의 소스 코드 파일에는 제공/요청 인터페이스 내부의 각 함수 집합들이 호출하는 타 함수 정보에 따라 함수 호출 코드가 자동 포함된다.

즉, 컴포넌트 모델 설계 단계에서 지정된 각 컴포넌트간의 연동 관계 및 각 함수들이 호출하는 타 함수 목록에 따라(1710), 소스 파일 내부의 해당 함수에는 함수 호출을 위한 콜(call) 구문이 포함된다(1720). 이와 더불어, 각 함수는 자신이 호출될 경우에 호출 추적성을 제공하기 위한 호출 그래프 무결성 확인 코드(call graph integrity check code)를 포함하고 있으며, 구문 형식은 자신이 정의된 컴포넌트와 자신의 함수 이름이 포함된다.

따라서 소프트웨어 플랫폼의 설정과 빌드 이후, 런타임(runtime) 시에 각 함수들이 호출한 함수들에 대한 무결정 확인 코드의 수행 결과가 축적되어 설계 정보와의 일치 여부를 확인하게 된다.

도 18은 호출 그래프 무결성 확인 테이블(call graph integrity check table)의 실시예를 나타낸다.

도 18을 참조하면, 소프트웨어 플랫폼 내의 모든 컴포넌트와 각 컴포넌트가 가지게 되는 함수 목록을 중심으로, 각 함수가 호출하게 되는 타 함수 목록이 나열된다. 만약 호출된 함수가 또 다른 함수를 호출하게 된다면, 목록 내의 해당 컴포넌트와 함수 위치에서 다시 한 번 추적이 이루어진다. 소프트웨어 제품마다 상이 한 컴포넌트 구성 및 가변성으로 인해, 각 제품별로 확인되는 함수 호출의 목록은 달라질 수 있다. 소프트웨어 플랫폼 설계 정보로부터 호출 그래프의 기본 형태가 정의되고, 가상 플랫폼 실행시 추적 경로에 따라 설계된 지점과 다른 지점에서의 호출이 발생하면 호출 무결성 오류를 발생시킨다.

이상에서 살펴본 가상 플랫폼 생성의 각 요소를 종합하여, 소프트웨어 플랫폼 아키텍처 설계 정보로부터 가상 플랫폼을 생성하는 과정을 살펴보면 다음과 같다.

1) 컴포넌트 모델에 포함된 모든 컴포넌트, 인터페이스, 연결, 가변성 요소들을 각각의 컴포넌트 핸들러, 인터페이스 핸들러, 연결 핸들러, 가변성 핸들러를 통해 분석한다.

2) 최상위 컴포넌트로부터 최하위 기본 컴포넌트들에 이르기까지 순차적으로 필요한 생성 작업을 진행한다. 복합 컴포넌트는 해당 이름과 동일한 디렉토리만을 생성하게 되며, 기본 컴포넌트는 컴포넌트 디렉토리와 함께 템플릿 소스 코드를 생성하게 된다.

3) 가변성을 위한 설정 변수가 해당 컴포넌트에 지정되어 있는 경우, 조건문(conditional statement)을 추가한다.

4) 소스 파일 작업 후, 빌드 스크립트 생성이 진행된다.

5) 모든 컴포넌트에 대한 템플릿 소스 코드가 생성되면, 가상 플랫폼 생성이 완료된다.

상기의 가상 플랫폼 생성 과정 중, 특히 빌드 스크립트 생성 과정을 구체적 으로 살펴보면 다음과 같다.

1) 컴포넌트 모델로부터 소프트웨어 제품의 목록 정보를 파악한다.

2) 파악된 소프트웨어 제품 목록 정보에 따라, Makefile.config_decision 스크립트 내에 주석 처리 형태로 모든 제품의 설정 라인을 추가한다. 이때, 목록 정보 중 "default" 항목은 주석 처리가 제거되어, 빌드 실행시 우선 선택 항목으로 동작할 수 있도록 한다.

3) 각 제품 타입의 설정 변수들을 Makefile.config_option 스크립트 내에 제품별로 기술한다.

4) Makefile.config_mapping 스크립트 내에는 Makefile.config_option 스크립트 내에 각 설정 변수와 맵핑 관계에 있는 하위 설정 변수들의 설정값을 기술한다.

5) 각 컴포넌트의 소스 코드 위치 정보를 기술하기 위한 Makefile.config_path 스크립트를 작성한다.

6) 최종적으로 복합 컴포넌트에 대해서는 하위 컴포넌트에 대한 빌드 스크립트를 포함하도록 구성된 빌드 스크립트를 작성하고, 기본 컴포넌트에 대해서는 기본 컴포넌트의 빌드가 이루어질 수 있도록 구성된 빌드 스크립트를 작성하게 된다.

상기와 같이 가상 플랫폼이 생성된 후에는 이를 이용하여 소프트웨어 제품을 조합할 수 있도록 상기 가상 플랫폼을 설정하는 과정이 수행된다.

가상 플랫폼을 설정하는 과정은 소프트웨어 플랫폼 설계 정보에 따라 생성된 가상 플랫폼을, 설계 구성에 따라 다양한 조합으로 설정하여 각 소프트웨어 제품 구성이 정상적으로 이루어질 수 있는지를 확인하는 과정이다.

소프트웨어 플랫폼은 다양한 소프트웨어 제품들의 구성 부품인 컴포넌트들의 집합체이며, 상이한 구성을 가지는 소프트웨어 제품들은 소프트웨어 플랫폼의 구성 설정을 통해 해당 컴포넌트의 조합으로 생성될 수 있다.

생성된 가상 플랫폼의 템플릿 소스 코드와 빌드 스크립트들 내부에는, 소프트웨어 제품별로 상이한 설정을 하기 위한 설정 변수가 반영되어 존재한다. 이들 설정 변수의 설정값을 변경하고 이에 따라 빌드 및 실행 결과를 확인함으로써, 소프트웨어 플랫폼 설계 정보의 오류 검출 및 적합성 검증을 수행할 수 있다.

이하, 소프트웨어 플랫폼 아키텍처 설계 정보에 대한 컴포넌트 모델 검증(validation)을 수행하는 과정을 살펴보면 다음과 같다.

1) 해당 소프트웨어 플랫폼으로부터 생성 가능한 소프트웨어 제품별로 설정과 빌드 과정이 진행된다. 최초 소프트웨어 제품을 위한 설정값으로 Makefile.config_decision 내의 설정 변수를 세팅한다.

2) 빌드가 수행되면, 각 makefile들 사이의 설정 변수 연동 정보 및 소스 코드 경로를 파악하여, 해당 소프트웨어 제품의 설정이 이루어진다.

3) 빌드 결과 해당 소프트웨어를 실행시켜, 함수 호출 흐름을 추적 기록한다.

4) 설계와 동일한 컴포넌트 목록과 함수 호출 흐름이 확인되면, 해당 소프트웨어 제품에 대해서는 설계 정보가 검증되었다고 평가한다.

5) 나머지 제품 타입들에 대해서도 순차적으로 검증을 수행하여, 모든 제품 타입에 대해 설계 정보와 동일할 경우 해당 소프트웨어 플랫폼의 컴포넌트 모델 설계는 이상없이 구성되었다고 판단할 수 있다.

한편, 상술한 본 발명의 방법은 컴퓨터에서 실행될 수 있는 프로그램으로 작성가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다.

또한, 상술한바와 같이 본 발명에서 사용된 데이터의 구조는 컴퓨터로 읽을 수 있는 기록매체에 여러 수단을 통하여 기록될 수 있다.

상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장매체를 포함한다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

도 5는 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 BLC(Build-Level Component) 적용예를 나타낸다.

도 7은 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 컴포넌트 의존성(dependency)을 나타낸다.

도 10은 가상 소프트웨어 플랫폼 생성 과정에서 구현되는 빌드 스크립트 생 성 구조를 나타낸다.

도 15는 복합 컴포넌트(composite component)의 makefile 구성의 실시예을 나타낸다.

도 16은 기본 컴포넌트(primitive component)의 makefile 구성의 실시예을 나타낸다.

상기 몇 개의 도면에 있어서 대응하는 도면 번호는 대응하는 부분을 가리킨다. 도면이 본 발명의 실시예들을 나타내고 있지만, 도면이 축척에 따라 도시된 것은 아니며 본 발명을 보다 잘 나타내고 설명하기 위해 어떤 특징부는 과장되어 있을 수 있다.

Claims

컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 방법에 있어서,

소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드를 생성하는 단계와;

소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 생성하는 단계를 포함하는 것을 특징으로 하는 생성 방법.
제1항에 있어서,

상기 템플릿 코드를 생성하는 단계는,

상기 컴포넌트 중 상위 컴포넌트 및 하위 컴포넌트의 포함관계를 나타내는 디렉토리 구조를 생성하는 단계와;

상기 컴포넌트가 요청하는 다른 컴포넌트의 인터페이스를 나타내는 의존관계를 나타내는 의존성 요소를 반영하는 단계와;

상기 설정 변수에 따라 상기 포함 또는 의존관계에 있는 복수개의 상기 컴포넌트를 선택하는 가변성 요소를 반영하는 단계를 더 포함하는 것을 특징으로 하는 생성 방법.
제2항에 있어서,

상기 빌드 스크립트를 생성하는 단계는,

상기 소프트웨어의 종류를 선택할 수 있는 타입 변수를 정의하는 단계와;

상기 타입 변수에 연동된 하위 설정 변수를 기술하는 단계와;

상기 컴포넌트에 대한 설정 변수 사이의 맵핑 관계에 따라 설정값을 지정하는 단계와;

상기 컴포넌트 각각의 소스 코드의 경로 정보를 설정하는 단계를 더 포함하는 것을 특징으로 하는 생성 방법.
제3항에 있어서,

상기 빌드 스크립트를 생성하는 단계는,

상기 가변성 요소를 반영하도록 상기 빌드 스크립트 내에 조건문 형식의 코드를 추가하는 것을 특징으로 하는 생성 방법.
제4항에 있어서

상기 가변성 요소는, 소정의 컴포넌트를 상기 빌드 스크립트의 경로로부터 제외시키는 옵션 가변성 또는 상기 설정 변수의 설정값에 따라 소정의 컴포넌트를 선택하는 스위치 가변성을 포함하는 하는 것을 특징으로 하는 생성 방법.
제5항에 있어서,

상기 빌드 스크립트를 생성하는 단계는,

상기 컴포넌트가 복합(composite) 컴포넌트인 경우 하위 컴포넌트에 대한 빌드 스크립트를 재귀적으로 호출하도록 구성되거나, 기본(primitive) 컴포넌트인 경우 자신의 소스 코드에 대한 빌드 프로세스를 기술하도록 구성되는 것을 특징으로 하는 생성 방법.
컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처의 검증 방법에 있어서,

소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 단계와;

상기 컴포넌트의 조합을 위해 상기 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 단계와;

상기 변경된 설정 변수에 기초한 상기 가상 소프트웨어 플랫폼의 실행 결과에 따라 상기 소프트웨어 플랫폼의 정합성을 검증하는 단계를 포함하는 것을 특징으로 하는 검증 방법.
제7항에 있어서,

상기 설정 변수의 설정값을 변경하는 단계는,

상기 컴포넌트에 구비된 가변성 요소를 설정하는 단계와;

상기 설정에 따라 상기 가상 소프트웨어 플랫폼을 빌드하는 단계를 더 포함 하는 것을 특징으로 하는 검증 방법.
제8항에 있어서,

상기 검증하는 단계는,

상기 소프트웨어 플랫폼의 설계 정보로부터의 획득된 호출 그래프 및 상기 실행으로 인한 함수 호출의 그래프를 비교하는 단계와;

상기 비교 결과에 기초하여 상기 소프트웨어 플랫폼의 의존성 또는 무결성을 판단하는 단계를 더 포함하는 것을 특징으로 검증 방법.
제9항에 있어서,

상기 검증하는 단계는,

상기 소프트웨어의 제품 명세(product specification)의 내용과 상기 실행으로 인한 상기 컴포넌트의 디렉토리 구성을 비교하는 단계와;

상기 비교 결과에 기초하여 상기 변경된 설정값에 따른 소프트웨어의 제품에 대한 상기 설계 정보를 검사하는 단계를 더 포함하는 것을 특징으로 검증 방법.
제10항에 있어서,

상기 컴포넌트 모델의 구성 요소인 컴포넌트, 인터페이스, 연결, 가변성 중 적어도 하나 이상의 구성 요소에 대한 목록을 관리하는 단계를 더 포함하는 것을 특징으로 하는 검증 방법.
제11항에 있어서,

상기 컴포넌트 모델의 구성 요소에 대한 목록을 관리하는 단계는,

상기 컴포넌트에 구비된 가변성 요소에 대응하는 변수를 정의하기 위한 언어 구문을 처리하는 단계를 더 포함하는 것을 특징으로 하는 검증 방법.
컴포넌트 모델 기반의 가상 소프트웨어 플랫폼을 생성하는 장치에 있어서,

소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드를 생성하는 코드 생성부와;

소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 생성하는 빌드 스크립트 생성부를 포함하는 것을 특징으로 하는 생성 장치.
제13항에 있어서,

상기 코드 생성부는,

상기 컴포넌트 중 상위 컴포넌트 및 하위 컴포넌트의 포함관계를 나타내는 디렉토리 구조를 생성하고, 상기 컴포넌트가 요청하는 다른 컴포넌트의 인터페이스를 나타내는 의존관계를 나타내는 의존성 요소를 반영하고, 상기 설정 변수에 따라 상기 포함 또는 의존관계에 있는 복수개의 상기 컴포넌트를 선택하는 가변성 요소를 반영하는 것을 특징으로 하는 생성 장치.
제14항에 있어서,

상기 빌드 스크립트 생성부는,

상기 소프트웨어의 종류를 선택할 수 있는 타입 변수를 정의하고, 상기 타입 변수에 연동된 하위 설정 변수를 기술하고, 상기 컴포넌트에 대한 설정 변수 사이의 맵핑 관계에 따라 설정값을 지정하고, 상기 컴포넌트 각각의 소스 코드의 경로 정보를 설정하는 것을 특징으로 하는 생성 장치.
제15항에 있어서,

상기 빌드 스크립트 생성부는,

상기 가변성 요소를 반영하도록 상기 빌드 스크립트 내에 조건문 형식의 코드를 추가하는 것을 특징으로 하는 생성 장치.
제16항에 있어서

상기 가변성 요소는, 소정의 컴포넌트를 상기 빌드 스크립트의 경로로부터 제외시키는 옵션 가변성 또는 상기 설정 변수의 설정값에 따라 소정의 컴포넌트를 선택하는 스위치 가변성을 포함하는 하는 것을 특징으로 하는 생성 장치.
제17항에 있어서,

상기 빌드 스크립트 생성부는,

상기 컴포넌트가 복합 컴포넌트인 경우 하위 컴포넌트에 대한 빌드 스크립트를 재귀적으로 호출하도록 구성되거나, 기본 컴포넌트인 경우 자신의 소스 코드에 대한 빌드 프로세스를 기술하도록 구성되는 것을 특징으로 하는 생성 장치.
컴포넌트 모델 기반의 소프트웨어 플랫폼 아키텍처의 검증 장치에 있어서,

소프트웨어 플랫폼의 설계 정보에 따라 적어도 하나 이상의 컴포넌트의 기능을 기술하는 템플릿 코드 및 소프트웨어 종류에 따른 설정 변수가 구비되어 상기 생성된 템플릿 코드의 빌드를 수행하는 빌드 스크립트를 구비하는 가상 소프트웨어 플랫폼을 생성하는 가상 플랫폼 생성부와;

상기 컴포넌트의 조합을 위해 상기 가상 소프트웨어 플랫폼에 구비된 설정 변수의 설정값을 변경하는 가상 플랫폼 설정부와;

상기 변경된 설정 변수에 기초한 상기 가상 소프트웨어 플랫폼의 실행 결과에 따라 상기 소프트웨어 플랫폼의 정합성을 검증하는 아키텍처 검증 관리부를 포함하는 것을 특징으로 하는 검증 장치.
제19항에 있어서,

상기 가상 플랫폼 설정부는,

상기 컴포넌트에 구비된 가변성 요소를 설정하고, 상기 설정에 따라 상기 가상 소프트웨어 플랫폼을 빌드하는 것을 특징으로 하는 검증 장치.
제20항에 있어서,

상기 아키텍처 검증 관리부는,

상기 소프트웨어 플랫폼의 설계 정보로부터의 획득된 호출 그래프 및 상기 실행으로 인한 함수 호출의 그래프를 비교하고, 상기 비교 결과에 기초하여 상기 소프트웨어 플랫폼의 의존성 또는 무결성을 판단하는 것을 특징으로 검증 장치.
제21항에 있어서,

상기 아키텍처 검증 관리부는,

상기 소프트웨어의 제품 명세(product specification)의 내용과 상기 실행으로 인한 상기 컴포넌트의 디렉토리 구성을 비교하고, 상기 비교 결과에 기초하여 상기 변경된 설정값에 따른 소프트웨어의 제품에 대한 상기 설계 정보를 검사하는 것을 특징으로 검증 장치.
제22항에 있어서,

상기 컴포넌트 모델의 구성 요소인 컴포넌트, 인터페이스, 연결, 가변성 중 적어도 하나 이상의 구성 요소에 대한 목록을 관리하는 컴포넌트 모델 관리부를 더 포함하는 것을 특징으로 하는 검증 장치.
제23항에 있어서,

상기 컴포넌트 모델 관리부는,

상기 컴포넌트에 구비된 가변성 요소에 대응하는 변수를 정의하기 위한 언어 구문을 처리하는 컴포넌트 언어 기술자를 더 포함하는 것을 특징으로 하는 검증 장치.
제1항 내지 제12항 중 어느 한 항에 기재된 방법을 구현하기 위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록 매체.