제품계열공학(Product Line Engineering)

PLE은 어플리케이션을 개발하기 위한 시간과 경제적인 비용을 효과적으로 사용할 수 있는 재사용 기법이다. PLE의 프로세스는 핵심자산 개발과정과 AE 과정으로 구성된다. 핵심자산 개발과정은 목표 도메인의 경제적 가치와 PLE의 범위 정의 후 목표 도메인에 속한 여러 어플리케이션들의 공통성과 가변성을 분석하여 공통적인 휘쳐를 핵심자산으로 모델링하고, 이를 재사용 할 수 있도록 구체화하는 작업이다. AE 과정은 목표 어플리케이션의 요구사항을 분석하여 핵심자산을 요구사항에 맞게 인스턴스화 한다. 핵심자산에서 제공하지 않는 목표 어플리케이션의 일부 기능을 모델링하며 인스턴스화된 핵심자산과 통합하여 어플리케이션을 개발한다. AE의 인스턴스화 활동은 핵심자산으로부터 어플리케이션을 생산하기 위한 성공 여부를 결정한다. 그러나 기존의 PLE 기법들은 핵심자산개발에 크게 치중되어 있으며 AE의 절차 및 지침은 상대적으로 미흡한 실정이다. 특히 AE 과정에서 가장 중요한 활동인 인스턴스화 하는 실용적 절차와 기법이 미비하다. PLE의 넓은 산업계의 적용을 위해서는 AE과정을 위한 체계적 이며 실용적인 수준의 프로세스, 작업 지침, 산출물의 연구가 요구된다.

PLE의 정의

- 소프트웨어를 개발할 때 체계적인 재사용 기법을 적용함으로써 동일 영역에서 다양하게 특화된 소프트웨어를 신속하게 개발할 수 있는 효과적인 매커니즘을 제공하는 접근 방법

- 컴포넌트가 플러그인 될 수 있는 프레임워크를 제공하는 아키텍처를 기반으로 필요한 컴포넌트를 선택적으로 조립함으로써 시장의 요구사항에 맞는 시스템을 생산하는 방식

PLE의 등장 배경

- 컴포넌트 기반의 개발 자체가 재사용성을 높여주지 않음

- 재사용성을 고려해 주의 깊게 개발하지 않으면 컴포넌트를 재사용하기 어려움

PLE의 구성

1. 핵심자산(Core Asset) 개발 과정

- 한 도메인에 속한 여러 어플리케이션들의 공통적인 Feature을 핵심자산으로 모델링하고, 이를 재사용할 수 있도록 구체화하는 작업

- 하나의 시스템 또는 유사한 시스템군의 유지보수성, 이해성, 사용성 및 재사용성 특성에 영향을 미침

2. 어플리케이션 공학(Application Engineering) 과정

- 핵심자산을 각 어플리케니션의 요구사항에 맞게 인스턴스화하여 어플리케이션을 효과적으로 개발하는 과정

- 핵심자산에서 제공하지 않는 목표 어플리케이션의 일부 기능을 모델링하며 인스턴스화된 핵심자산과 통합하여 어플리케이션을 개발함

3. 관리활동(Management)

- 성공적인 제품 계열 생산을 위해 기술적 측면과 관리적 측면에서 핵심 자산 개발과 제품 개발 활동을 관리

PLE의 특징

- 같은 계열의 소프트웨어들에서 공통적인 특징들을 추출하여 고품질의 재사용 가능한 핵심 자산을 만들고 그 안에서 특화될 수 있는 부분을 가변적인 특성으로 모델링함으로써 특정 영역에서 어플리케이션을 개발할 때보다 높은 재사용성을 제공함

- 공통으로 유사한 기능을 가지고 있는 시스템의 집합으로 특정 영역의 요구사항을 만족하는 미리 구축된 핵심 자산으로부터 정해진 방식으로 개발

- 제품 계열 아키텍처의 재사용성을 최대한 높이도록 모델링하는 것이 중요

PLE의 효과

- 여러 어플리케이션들이 공유할 수 있는 핵심자산을 사용하여 소프트웨어의 생산성을 높이고 재사용성을 증대

- 개발비용 감소를 통한 개발 효율성 향상 및 시장 적시성 향상

- 제품계열 역시 컴포넌트의 공급이나 조립과 같은 기술적이면 뿐만 아니라 새로운 요구사항에 맞추어 조립 공정을 바꿀 수 있는 아키텍처가 매우 중요하며, 이러한 변화에 신속히 적응할 수 있도록 조직을 관리하는 것이 필요함

PLE 관련연구

1. Bosch의 AE 프로세스

Bosch의 AE 프로세스는 초기화(Initial)단계와 반복 (Iteration)단계로 구성되어 있다. 초기화 단계는 어플리케이션 멤버의 자산으로부터 초기 소프트웨어 생산물 형상(Initial Software Product Configuration)을 생성한다. 초기화 단계의 접근방법은 조립(Assembly)과 형상선택(Configuration Selection) 두 가지이며, 조립접근은 멤버 간에 공유하는 자산으로부터 초기 소프트웨어 생산물의 형상을 생성하기 위한 방법이다. 형상 선택은 이전 프로젝트의 생산물(Old Configuration)이거나 그의 부분집합(Reference Configuration)을 선택하여 목표 생산물에 맞도록 수정, 추가, 제거, 선택을 통하여 목표 생산물 형상을 생성한다. 초기화 단계의 마지막 활동으로 초기 검증(Initial Validation)은 생산물의 초기 형상에 고객의 요구사항이 충분히 반영되었는지 판단한다. 반복단계에서는 초기화 단계의 산출물인 생산물 초기 형상을 고객의 요구사항이 충분히 구현 될 때까지 반복 수행하여 보완한다. 반복단계는 ‘수정’과 ‘검증’활동을 포함하고 있으며, 검증을 통하여 생산물의 형상과 요구사항 간에 정확성 및 일관성을 판단하여 반복 여부를 결정한다. 적응(Adaptation)활동은 초기화, 반복단계에 적용되며, 적응활동은 ‘생산물을 명세한 적용(Product-Specific Adaptation)’, ‘반응 진화(Reactive Evolution)’, ‘학습에 영향 받는 진화(Proactive Evolution)’로 3가지 단계로 나눈다. 전체적인 AE프로세스를 제시하고 있으나 각 활동들과 지침들이 개념적이며 각 활동에 따른 실용적인 산출물을 제시하지 못하고 있다.

2. PuLSE의 AE 프로세스

PuLSE(Product Line Software Engineering)는 PLE 개발 프로세스로 독일의 IESE에서 개발 했다. 이 프로세스는 배포단계(Deployment Phase), 기술적 컴포넌트(Technical Components), 지원 컴포넌트(Support Components) 3개로 구성되어 있다. 기술컴포넌트는 PuLSE-BC, PuLSE-Eco, PuLSE-CDA, PuLSEDSSA, PuLSE-I, 마지막 PuLSE-EM으로 구성되어 있다. 특히 생산물을 생성하기 위한 기술컴포넌트의 PuLSE-I는 생산물을 명세하며, 생성하여 평가하기 위한 절차로서 5가지의 단계로 되어 있다.

첫 번째 단계는 사용자의 요구사항을 이용하여 새로운 생산품을 인스턴스화 하기 위한 계획을 수립하는 단계이다.

두 번째 단계는 생산공정 모델을 구체화하고 검증 한다. 이 단계에서는 의사결정 모델로부터 도메인 모델을 명세 하고, 사용자 요구사항으로부터 도출된 도메인 모델을 검증한다.

세 번째 단계는 아키텍처를 구체화 하고 검증하는 단계이다. 이 단계는 형상 모델과 생산물 명세서를 통하여 생산물의 아키텍처를 도출한다.

네 번째 단계는 구현이다. 이 단계는 낮은 수준의 디자인이나 코드를 구현하는 단계이다.

마지막으로 사용자에 의해 승인 테스트가 이루어 진다.

PuLSE는 생산물을 생성하기 위한 전반적인 프로세스를 제공하고 있으나 실용적인 지침과 산출물을 제시하지 못하고 있다.

3. KobrA의 AE 프로세스

Kobra는 UML(unified Modeling language)을 이용한 컴포넌트 기반의 PLE 개발 프로세스이다. 이 프로세스는 프래임웍 공학(Framework Engineering)과 AE로 구성 되어있다. 프래임웍 공학에서 범용 프래임웍을 생산 하며 AE에서 범용 프래임웍을 이용하여 하나의 특정 어플리케이션을 개발한다. 프래임웍 공학의 산출물인 범용 어플리케이션은 PLE에 포함된 모든 멤버의 특성을 다 가지고 있다. KobrA에서의 AE 프로세스는 배경구현(Context Realization) 인스턴스화, Komponent 명세화(Komponent Specification)와 Komponent 현실화(Komponent Realization) 인스턴스화로 되어 있다. 배경 구현에서는 컨설턴트들은 고객과 함께 생산물의 특징들을 도출하여 프래임웍 공학에서 개발된 후보 프래임웍과 고객이 요구하는 특징이 얼마나 많이 중복되는지를 확인한다. 프래임웍안에서 Komponent의 명세와 현실화의 인스턴스화를 반복적으로 수행함으로서 명세 Komponent 제약 트리(Specific Komponent Containment Tree)를 생성한다. 모델링을 통하여 생성된 Komponent 제약 트리를 이용하여 하나의 특정한 어플리케이션을 생성한다. KobrA는 구체적이며 상세한 지침을 제공 하고 있으나 실용적인 프로세스를 제시하기 위해서는 좀더 정재 될 필요가 있다.