Product Lines Platform Wiki

The most promising software development paradigm for increasing productivity.

사용자 도구

사이트 도구


process:feature_modeling

Domain Engineering

Feature Modeling

본 단계에서는 이전 단계인 MPP Development에서 분석한 MPP를 바탕으로 제품라인에 속하는 제품들의 특성을 분석/추출하여 휘처 모델로 구조화하는 단계이다.

제품라인을 분석하여 개발할 때 휘처 모델링의 중요성과 의미는 다음과 같다.

  • 제품라인에 속해 있는 제품들 사이의 공통점과 차이점을 분석하게 해 준다.
  • 공통점으로 분석된 휘처는 재사용의 가능성이 높은 부분을 나타낸다.
  • 차이점으로 분석된 휘처는 아키텍처 및 컴포넌트에서 변화를 수용해야 하는 부분을 나타낸다.
  • 휘처들의 의미를 표준화하고 하나의 모델로 집약함으로써 의사소통의 매체로 사용한다.
  • 휘처 모델을 이용하여 제품 라인의 도메인을 명확히 한다.
  • 휘처들 사이의 관계가 가시화된다.

본 단계에서 작성된 휘처 모델은 다음 단계들에서 자산을 개발할 때 Configuration Parameter로 사용된다.

휘처 모델링은 다음의 하위 활동으로 구성된다.

  1. 도메인 정의: 제품라인 대상 도메인을 선택하고 범위를 정의하는 활동
  2. 휘처의 추출: 정의된 도메인으로부터 제품라인 휘처들을 추출하는 활동
  3. 휘처의 분류: 추출한 휘처들을 능력, 운영환경, 영역기술 및 구현기술 휘처로 분류하는 활동
  4. 휘처의 구조화: 분류된 휘처들을 휘처 모델로 구조화하는 활동
  5. 휘처의 정련: 작성한 휘처 모델을 검토하고 정제하는 활동

1. 도메인 정의

도메인 정의는 휘처 모델링을 하기에 앞서 고려해야 하는 준비 단계이며, 도메인 선택, 도메인 범위 결정, 도메인 분석팀 구성과 도메인 사전 작성으로 구성된다.

가. 도메인 선택

도메인 정의의 첫 번째 단계는 성공적인 제품라인 공학이 되기 위해 도메인 범위를 적절히 결정하는 것이다.

제품들 간에 공통점이 많고 도메인 전문가와 가용 문서가 있는 도메인을 선택할 것: 
일반적으로 도메인 공학은 단일 제품을 개발하는 것보다 오랜 개발 시간과 많은 초기 투자비용을
요구한다. 제품들 간에 공통점이 많고 합리적으로 도메인을 선택하는 것은 경제적이고 성공적인 
소프트웨어 제품라인 공학을 위한 좋은 출발 방법이다. 고려해야 할 제품라인을 가능한 작게 
구성한 다음 단계적으로 도메인의 제품라인을 추가하는 방법이 좋다.
제품 인도 스케줄이 고정된 제품은 도메인에서 배제할 것: 
도메인 내 제품 인도 스케줄이 고정된 제품이 포함되어 있다면 관리자가 도메인 분석을 충실히 
하기 보다는 제품을 예정된 시점에 인도하는 일에 더 우선순위를 둘 것이다. 그러므로 인도 
스케줄이 고정된 제품은 성공적인 휘처 모델링을 위해서 배제되어야 한다.

나. 도메인 범위 결정

도메인이 선택된 이후에는 도메인 분석가들과 정보를 공유해서 도메인 범위를 명확히 해야 한다. 도메인 분석가와 정보 제공자가 인식하는 도메인 범위가 다르면, 휘처 추출시 혼란을 가져올 수 있다. 휘처 분석에 앞서 도메인 범주에 대한 이해를 일치시키는 작업은 매우 중요하다.

만약 도메인 내 운영 환경의 차이가 많다면 도메인의 범위를 줄일 것: 
도메인 내 운영 환경(예: 주변 하드웨어)의 차이를 이해하는 것은 올바른 도메인 범위를 결정
하는 데에 도움이 된다. 만일 주변 하드웨어(예: 다른 종류의 디바이스)의 차이점이 많다면 
이를 공통된 하드웨어로 추상화해서 인식하는데 어려움이 있을 수 있다.

다. 도메인 분석 팀 구성

휘처 모델링의 목적은 시스템 개발 시 공통점과 차이점, 또는 특성을 인식하는 것이다. 따라서 도메인 분석팀을 구성할 때 개발자로만 구성해서는 안 된다. 다양한 이해 당사자 (Stakeholder)들이 각기 다른 관점으로 시스템을 인식하는 것은 도메인의 개념과 특성을 인식하는데 도움이 된다. 예를 들어 시스템 사용자 (End-user)는 도메인 내 제품이 제공하는 서비스와 기능을 식별하는데 도움을 준다. 반면 도메인 전문가 (Domain Expert)는 도메인 내에서 공통적으로 사용되는 기술을 식별하는데 도움을 주고, 개발자 (Developer)는 일반적인 구현 기술을 식별하는데 도움을 줄 수 있다.

다른 제품라인의 전문가를 도메인 분석팀에 포함 시킬 것: 
같은 도메인에 속하는 모든 제품라인을 경험해 본 사람은 거의 없다. 다른 제품라인의 도메인 
전문가들은 제품라인 간의 공통점과 차이점을 식별하고 모델화 하는데 도움을 줄 수 있다. 
그러므로 재사용성이 높은 자산을 만들기 위해서는 다른 제품라인의 도메인 전문가들이 도메인 
분석팀에 포함되어야 한다.

라. 도메인 사전 작성

도메인 분석팀이 구성된 이후 도메인 정의를 위한 마지막 작업은 휘처 모델링을 수행하기 위한 도메인 사전을 준비하는 것이다.

미숙하고 최근 생성된 도메인의 경우 휘처 모델링을 시작하기에 앞서 도메인에서 사용되는 
용어를 표준화하고 도메인 사전을 먼저 만들 것: 
미숙하고 최근 생겨난 도메인에서는 같은 의미를 가지고 있는 다른 용어가 다른 제품라인에서 
사용될 수 있다. 도메인 용어를 표준화 하는 것은 제품라인 공학의 준비 단계에서 중요한 
활동이다. 만일 표준화된 용어가 없다면, 도메인 분석팀은 휘처들 사이의 사소한 의미상의 
차이에 대한 논의로 많은 시간을 소비하게 된다.

도메인 정의는 성공적인 휘처 모델링을 위한 중요한 단계이다. 도메인의 정확한 범위 결정 및 도메인 내 제품의 사용 목적, 다양한 외부 조건, 공통된 도메인 사전에 대한 준비가 없다면 휘처 추출은 도메인 어려워질 수 있고 추출된 휘처들이 무의미해질 수 있다.


2. 휘처의 추출

휘처의 추출은 도메인 전문가와 다양한 문서 (즉 사용자 매뉴얼, 설계 문서, 소스 프로그램)로부터 획득한 도메인 지식을 추상화하는 과정을 포함한다.

휘처를 추출하기 위해서 제품라인에서 사용되는 도메인 용어를 분석할 것: 
우리는 종종 성숙되고 안정된 도메인에서 도메인 전문가들이 표준화된 용어로 그들의 생각이나 
문제점들에 대해 대화하는 것을 들을 수 있다. 휘처 추출을 위해서 이러한 도메인 용어를 
고려하는 것은 도메인 분석가와 정보 제공자 (예: 도메인 전문가, 시스템 사용자) 사이의 
의사소통을 촉진시킨다. 휘처 추출을 위한 가장 효과적이고 효율적인 방법은 표준화된 도메인 
용어를 분석하는 것이다.
휘처를 도메인 내 제품들 간에 구별하기 힘든 세부적인 구현 사항으로 추출하지 말 것: 
능숙한 개발자는 제품들 간에 차이점이 없는데도 불구하고 구현 수준의 기능을 휘처로 
추출하는 경향이 있다. 휘처 모델링의 초점은 시스템 내부의 모든 구현 수준의 기능을 찾는 
요구사항 분석 모델이 아니라, 제품들 간의 공통점과 차이점이 되는 능력 및 운영 환경상의 
휘처와 이를 구현하는 휘처들을 찾는 데에 있다.
휘처 추출 시 제품들 간 차이가 되는 특성을 먼저 도출하고 이해한 후 공통점을 도출할 것: 
소프트웨어 제품라인 상의 제품들은 차이점보다 공통점이 더 많다. 그러므로 공통점을 도출하는 
것은 차이점을 도출하는 것보다 더 많은 작업을 필요로 한다. 차이점을 먼저 도출하는 경우 
공통점을 먼저 도출할 때보다 휘처를 보다 쉽게 추출할 수 있다.

3. 휘처의 분류

<그림> 휘처 카테고리의 예

이번 활동에서는 이전 활동에서 추출한 휘처들을 능력 (Capabilities), 운영환경 (Operating Environment), 영역기술 (Domain Technologies) 및 구현기술 (Implementation Techniques)로 분류한다. 휘처를 분류할 때 <그림>의 카테고리를 가이드라인으로 사용할 수 있다. 이러한 분류를 통해 나누어진 휘처들은 휘처 모델에서 계층적으로 표현된다.


4. 휘처의 구조화

휘처를 추출한 후에는 휘처들 간의 관계를 고려하여 구성관계 및 일반화/특수화 관계, 구현 관계로 구조화한다. 그리고 합성 규칙을 이용하여 휘처 모델 상의 관계로 표현되지 못하는 가변 휘처 선택 시 제약 사항인 휘처 간의 요구 관계 및 상호 배제 관계를 명세 한다.

  • 휘처들을 기능상 호출 계층처럼 구조화 하지 않고 도메인 내 차이점을 표현하도록 구조화한다. 구조적 개발 방법에 친숙한 개발자들은 휘처 모델을 기능적 호출 계층으로 잘못 인식하는 경향이 있다. 즉 개발자들은 휘처를 제품의 모든 기능으로 식별하고 추출된 휘처를 기능 호출 계층으로 구조화하기 쉽다. 하지만 휘처 모델은 휘처들 간의 상호 작용을 표현하기 보다는 도메인 내 공통된 특성이 무엇이고, 제품들 간의 차이가 나는 특성이 무엇인지를 표현하도록 구조화 되어야 한다.
  • 많은 상위 수준의 휘처가 구현 관계로 하위 수준의 휘처들과 연관되어 있을 때 휘처 모델의 복잡도를 줄이기 위해서 하위 수준 휘처와 연관된 가장 근접한 상위 수준 휘처의 공통된 부모 휘처와 연관시킨다. 휘처 모델 상의 상위 수준 휘처들이 여러 개의 하위 수준 휘처들과 구현 관계로 연관되어 있을 때 휘처들 간의 구현 관계가 매우 복잡해질 수 있다. 휘처 모델링의 주요 관점은 휘처들 간의 구현 관계를 표현하는 것이 아니라 도메인 내 공통점과 차이점을 표현하는 것이므로, 하위 수준 휘처들과 연관된 상위 수준 휘처들에서 가장 근접한 부모 휘처와 연관 시키는 것은 복잡성을 줄이는 한 가지 방법이다.

5. 휘처의 정련

휘처 모델은 모델링 작업에 참여하지 않은 도메인 전문가와 도메인 산출물(즉 매뉴얼, 프로그램, 설계 문서, 시스템 등)과 함께 검토되어야 한다. 검토 과정 중에서 필요하다면 휘처 모델을 재구성하고, 휘처를 추가, 수정, 삭제할 수 있다.

  • 휘처 모델 상의 논리적인 경계와 아키텍처 모델 상의 물리적인 경계를 일치시킬 수 있도록 휘처 모델을 정련한다. 제품라인의 소프트웨어는 여러 제품에 의해서 선택되는 휘처들의 집합을 수용할 수 있도록 설계되어야 한다. 선택된 휘처를 독립된 컴포넌트로 설계하는 것은 애플리케이션을 제품라인 소프트웨어로 쉽게 유도할 수 있도록 만든다. 만약 이러한 휘처 모델상의 논리적인 경계와 아키텍처 모델상의 물리적인 경계를 일치시키기 어렵다면, 휘처를 아키텍처상의 컴포넌트와 쉽게 대응될 수 있도록 정련해야 한다. 이러한 정련은 휘처와 아키텍처 상의 컴포넌트 사이의 추적을 용이하게 해서 모듈 구성성을 향상 시킨다.
  • 도메인 내 제품들 사이에 표현되는 차이점이 없을 때까지 추상적 휘처를 정련 한다. 만약 제품들 사이의 차이가 더 이상 존재하지 않는다면 휘처를 하위 휘처로 정련할 필요가 없다. 하지만 비록 휘처들 간의 차이가 없더라도 상위 수준의 다른 휘처들이 같은 하위 휘처를 공유하고 있다면 공유되는 휘처는 좀 더 정련될 여지가 있다.

휘처 정련 과정 중에 한 가지 주의할 사항은 도메인 내 제품들 간의 모든 차이점이 휘처가 되지는 않는다는 점이다. 휘처는 도메인 상의 중요한 특성 및 개념이어야 한다. 만약 도메인 상의 차이점이 중요한 내용이 아니라면 이러한 차이점들은 본 활동에서 제거될 수 있다.


See Also

process/feature_modeling.txt · 마지막으로 수정됨: 2014/11/25 00:05 저자 edeward