Product Lines Platform Wiki

The most promising software development paradigm for increasing productivity.

사용자 도구

사이트 도구


assets:featuremodel

Feature Model

휘처모델은 도메인 전문가와 일반 사용자, 개발자 간의 의사소통 수단으로 도메인 내 여러 시스템의 공통점과 차이점을 AND/OR 그래프로 도식화한 도메인 분석 모델이다. 아래의 <그림1>은 자동차 도메인의 휘처를 휘처모델로 분석화하여 도식화한 예이다.

<그림1>휘처모델의 개념


1.휘처유형

도메인 내의 공통적인 특성은 필수(Mandatory) 휘처로 표현되고, 시스템 사이의 구별되는 차이점은 선택적(Optional) 휘처, 택일적(Alternative) 휘처, 다중선택(Multiple Choice) 휘처로 표현된다.1)

예를 들어 <그림1>에서 “Transmission”은 필수 휘처, “Air Conditioning”은 선택적 휘처, “Manual”과 “Automatic”은 택일적 휘처로 구분된다.

  • 필수 휘처는 시스템들 사이의 공통적인 특성을 나타내고 휘처모델에서 특별한 표기법을 가지지 않는다.
  • 선택적 휘처는 시스템에 따라서 선택되거나 선택되지 않는 휘처로 휘처이름 위에 동그라미로 표현된다.
  • 택일적 휘처는 여러휘처들 가운데 하나만 선택되는 것을 나타내는 것으로 후보 휘처들 가운데 반드시 하나는 선택되어야 함을 의미한다. 휘처모델에서는 관계있는 휘처들 끼리 반원(Arc)으로 표현된다.
  • 한편 “Electric”, “Gasoline”, “Diesel”은 다중선택 휘처로서 휘처들 가운데 적어도 하나가 선택되어야 한다는것을 나타낸다. 휘처모델에서는 검은색 바탕의 삼각형으로 표기된다.

2.휘처범주

휘처는 기능(Capability), 운영환경(Operating Environment), 도메인기술(Domain Technology), 그리고 구현기술(Implementation Technology) 네 가지 범주로 구분된다. <그림1>의 모든 휘처는 기능 범주에 속해 있다.

  • Capability (CA) : 이 범주로 구분되는 휘처는 서비스, 오퍼레이션, 비기능적 측면의 성격을 가진다. 서비스는 시스템 사용자가 인지할 수 있고 그들의 요구사항을 충족시킬 수 있는 시스템의 주요 기능을 나타내고, 오퍼레이션은 서비스를 제공ㅇ하기 위해 필요한 시스템 내부 기능을 의미한다. 비기능적 요소는 서비스와 오퍼레이션으로 인지 할 수 없는 표현, 시스템능력, 품질요구사항, 비용, 시스템 사용법등이 해당된다.
  • Operation Environment (OE) : 이 범주로 구분되는 휘처는 도메인 내의 시스템이 사용되고 운영되는 환경을 나타내는 것으로 크게 하드웨어 요소와 소프트웨어 요소가 있다. 시스템은 다른 하드웨어와 운영체제, 혹은 외부 시스템과 인터페이스하거나 다양한 종류의 디바이스와 인터페이스하며 작동되고, 운영 환경 휘처는 이러한 제품라인의 컨텍스트(즉, 컴퓨팅 환경 및 인터페이스)를 포함한다. 외부 시스템과 통신하기 위해 사용되는 프로토콜은 운영환경 휘처로 분류된다.
  • Domain Technology (DT) : 이 범주로 구분되는 휘처는 도메인 분석가와 설계자가 도메인에 특화된 문제를 모델화 하거나 서비스와 오퍼레이션을 구현하기 위한 도메인에 특화된 기술을 의미한다. 도메인 이론이나 방법, 분석패턴, 법률, 표준안 등이 그 예이다.
  • Implementation Technology (IT) : 이 범주로 구분되는 휘처는 도메인 기술 휘처보다 일반화되어 여러 도메인에서 범용적으로 사용될 수 있는 기술을 의미한다. 이 휘처는 능력 계층의 휘처와 도메인 기술 휘처를 구현하기 위해서 사용되는 설계 및 구현 결정 사항을 나타내는데, 설계 패턴(Design Pattern), 아키텍처 스타일, 추상 데이터 타입(Abstract Data Type: ADT), 동기화 방법 등이 그 예가 될 수 있다.

3.휘처 사이의 관계

휘처들 사이의 관계에는 구성관계(Composed-of), 일반화/특수화 관계(Generalization/Specialization), 구현관계(Implemented-by)가 존재한다. 어떤 휘처가 다른 여러가지 휘처들로 구성이 될때 이들을 구성관계라고 하며 실선으로 표현한다. 반면에 하나의 휘처가 다른 휘처들의 추상화된 개념이라면 이들 휘처 사이는 일반화/특수화 관계로 정의하고 점섬으로 표현한다. 그리고 하나의 휘처가 다른 휘처를 구현하는데 사용되는 경우에는 구현관계로 정의하고 굵은 실선으로 표현단다. 구현관계는 주로 기능휘처와 구현과 관련된 휘처들(도메인 기술 또는 구현기술 범주에 포함되는 휘처를 의미한다.)을 연결하기 위해서 사용한다.


4.합성 규칙(Composition Rules)

합성규칙(Composition Rules)은 휘처모델 그 자체만으로 표현되지 못하는 가변휘처들 사이의 제약을 주기 위한 규칙을 의미한다. 합성규칙은 Require 관계와 Mutually Exclude 관계로 정의된다.

  • Require Composition Rule : 어떤 휘처가 다른 휘처와 선택 의존성이 있어 이 휘처를 선택하기 위해서는 다른 휘처의 존재를 필요로 함을 의미한다. 필요관계는 단방향성을 가지기 때문에 휘처 A가 휘처 B를 필요로 한다고해서 휘처 B가 휘처 A를 필요로 하는 것은 아니다. 이 관계는 아래와 같이 표기된다.
'Smoke' requires 'Smoke Sensor'
  • Mutually Exclude (Mutex) Composition Rule : 어떤 휘처가 다른 휘처와 함께 존재 할 수 없어 휘처 선택 시 다른 휘처를 배제해야 할 경우에는 이 규칙으로 정의된다. 상호배제관계는 양방향성을 가지기 때문에 휘처 A가 휘처 B를 상호배제 한다면, 반대의 경우도 마찬가지로 상호배제 관계가 된다. 이 관계는 아래와 같이 표기된다.
'calibration' mutex 'fixing'

이러한 규칙들은 휘처 선택시 일관된 선택을 할 수 있도록 도와주며, 휘처 선택의 효율성을 증진시킬 수 있다. 합성규칙은 선택적 휘처와 택일적 휘처 사이에 적용가능하다.


5.휘처모델의 예

<그림2> Home Integration System 휘처모델의 일부

위의 <그림2>는 HIS 시스템에 대한 휘처모델의 일부를 보여준다. HIS의 기능휘처는 서비스휘처(예: Intrusion, Fire, Flood, Message 등)와 운영환경 휘처(예: Intrusion Detection, Intrusion Action, Fire Detection 등)로 구성되어 있다. 이 가운데 Flood와 Message는 제품에 따라 선택 가능한 휘처로 설정된 것을 확인 할 수 있다.


See Also

1) 휘처모델링 도구에 따라서 다중선택 휘처를 지원하지 않는 경우가 있다.
assets/featuremodel.txt · 마지막으로 수정됨: 2014/05/23 22:54 저자 wiki_admin