Product Lines Platform Wiki

The most promising software development paradigm for increasing productivity.

사용자 도구

사이트 도구


process:pl_com_design

Domain Engineering Process

Component Model Design

본 단계에서는 아키텍처 설계과정에서 컴포넌트 모델을 이용하여 구조화된 재사용 컴포넌트 (Reusable Component)를 설계하고 개발한다.

설계 객체 모델링 단계에서 식별한 객체는 재사용 컴포넌트를 만들기 위한 기본 단위이다. 재사용 컴포넌트는 소프트웨어를 보다 적응성 있게 하고 큰 단위의 재사용을 가능하게 한다. 즉, 객체 단위의 컴포넌트의 재사용은 재사용 수준이 낮을 뿐 아니라, 객체가 변화는 경우에 영향 받는 다른 객체도 함께 변경되어야 하므로, 대규모 소프트웨어 시스템을 개발 시에는 이러한 객체의 변경에 대해 대처하기가 매우 힘들어 지게 된다. 그러므로, 서로 밀접한 관련이 있는 객체를 찾고 이들의 변화 가능성을 예측하여, 표준화된 인터페이스를 가지면서 적응성이 강한 재사용 컴포넌트를 만드는 것이 중요하다.

재사용 컴포넌트 개발에 있어 고려해야 할 중요 사항은 다음과 같이 요약된다.

  • 유형에 따른 컴포넌트 분류와 계층적인 컴포넌트 모델 설계
  • 파라미터를 이용한 컴포넌트의 적응성 및 유연성을 높여야 한다.
  • 표준화된 인터페이스를 제공하여 인터페이스가 같은 컴포넌트끼리는 서로 바꾸어 사용할 수 있게 하여야 한다.
  • 서로 밀접하게 관련된 객체를 하나의 컴포넌트로 패키지화 함으로써 한 객체의 변화가 영향을 미치는 부분을 하나의 컴포넌트 내로 한정시켜야 한다.

Hierarchical Component Model

컴포넌트 모델은 프로세스 컴포넌트의 내부 설계구조에 대해서 나타낸다. 컴포넌트 모델을 개발할때는 휘처모델에서 모든 레벨의 휘처가 사용된다. 그리고 컴포넌트 모델의 계층관계는 일반적으로 휘처모델의 계층관계를 따르게 된다.

컴포넌트 모델을 설계할때 방법론에서 제한하는 가이드라인은 다음과 같다.

"컴포넌트 유형에 따라 사용자 인터페이스, 제어, 연산 및 데이터 컴포넌트를 분리한다."
시스템의 행위를 가시화하기 위해서 사용자 인터페이스, 제어, 연산 및 데이터 관리 유형의 
컴포넌트를 분리해야 한다. 인터페이스 컴포넌트와 같이 변경이 자주 일어나는 컴포넌트를 
다른 컴포넌트로부터 분리시킴으로써, 다른 컴포넌트에 영향을 미치지 않고 해당 컴포넌트를 
쉽게 변경할 수 있기 때문에 자산 컴포넌트의 유지보수성이 높아진다. 또한, 연산 컴포넌트와 
데이터 관리 컴포넌트와 같이 자주 변경이 일어나지 않는 컴포넌트들을 독립적으로 
테스트하고 재사용할 수 있기 때문에 자산의 재사용성이 높아진다.

재사용 컴포넌트로 식별될 수 있는 컴포넌트의 유형에 대한 좀 더 자세한 설명은 개념적 아키텍처 설계의 내용을 참고한다.

"각 컴포넌트를 유연하게 통합하는 연결 메커니즘을 제공해야 한다."

Koala등의 방법은1)2) 제품라인 아키텍처를 명세하는 언어 및 컴포넌트를 통합하는 메커니즘을 제공한다.

"복잡한 시스템의 행위가 가시화 되어야 한다."
제어 컴포넌트를 인터페이스와 연산 컴포넌트로 부터 분리한 이후에 제어행위를 명세할 수 있는
방법을 제공하는 것이 좋다. 컴포넌트의 행위를 개발자가 직접 코드순준에서 개발을 하게되면
시스템 행위가 가시적이지 못하고 그 결과 시스템에 대한 이해도 및 유지보수의 어려움이 발생한다.

본 방법에서는 시스템의 행위를 좀 더 명확하게 가시화 할 수 있도록 제어 특성에 따라 제어 컴포넌트를 행위 명세 기반으로 개발하고 연산 컴포넌트등과 통합할 수 있는 메커니즘을 제공한다.

"전역제어와 지역제어를 분리한다."
시스템의 일부분을 제어하는 로컬 제어 컴포넌트와 시스템의 상태를 관리하는 글로벌 제어 
컴포넌트를 분리시키고, 글로벌 제어 컴포넌트가 시스템의 상태를 바탕으로 로컬 컴포넌트를 
제어하도록 한다. 글로벌 제어 컴포넌트와 로컬 제어 컴포넌트를 분리시킴으로써 제어 서비스가 
추가되거나 삭제될 때 소프트웨어가 받는 영향을 줄일 수 있다.

글로벌 제어 컴포넌트와 로컬 제어 컴포넌트는 상대적인 개념이며, 시스템은 두 층 이상의 제어 컴포넌트 계층 구조를 가질 수 있다.

<그림> 컴포넌트 분리 원칙을 적용한 컴포넌트 모델의 예

제안된 지침들을 적용한 컴포넌트 모델의 예는 아래의 <그림>과 같다. 예제에서는 세 개 층의 제어 컴포넌트 계층 구조를 가지고 있다. 제어 컴포넌트 C 는 제어 컴포넌트 A 와의 관계에서는 로컬 제어 컴포넌트에 해당되지만, 제어 컴포넌트 D 와의 관계에서는 글로벌 제어 컴포넌트에 해당된다.

프로세스 아키텍처에 정의된 프로세스 컴포넌트 별로 계층적 컴포넌트 모델을 설계하는 과정에서 반복적으로 사용되는 기능을 가진 컴포넌트 또는 모듈을 찾아낼 수 있다. 반복적으로 사용되는 컴포넌트를 전체 컴포넌트 모델에서 아래 계층으로 위치하게 함으로써 재사용성을 증대시킬 수 있다. 이렇게 반복적으로 식별되는 컴포넌트는 높은 재사용성을 위해서 개발시 모듈화(Modularization), 정보은닉(Information Hiding), 데이터 추상화(Data Abstraction)등의 기본적인 소프트웨어공학 원칙이 적용되어야 한다. 추가적으로 재사용 전략을 따라서 코드가 미리 만들어진 컴포넌트를 선택하거나 매개변수를 지원하는 템플릿 또는 완전한 골격의 코드 컴포넌트를 선택하는 등의 방법으로 모듈을 구체화 시킬 수 있다.


Control Component Development

제어 컴포넌트는 사용자 인터페이스로부터 입력을 받아 이를 다른 컴포넌트들에게 전달하고 조율하는 역할을 하기 때문에 아키텍처 드라이버 (Driver)라고 볼 수 있으며, 일반적으로 제어 컴포넌트의 로직이 복잡하고 자주 바뀌기 때문에 개발/유지보수 시 오류가 생기기 쉬운 컴포넌트이다.

행위의 복잡성에 의해서 유지보수성 및 가독성등의 문제를 야기하는 제어 컴포넌트의 행위를 가시화하기 위해 제어 컴포넌트를 시스템의 특성에 따라서 적합한 행위명세를 기반으로 개발하는 방법을 제안한다.

모바일 게임 소프트웨어에서부터 공장 제어 시스템에 이르기까지 다양한 산업체 소프트웨어를 분석한 결과 공통적으로 사용이 되는 제어 컴포넌트 패턴을 찾을 수 있었다. 각 제어 컴포넌트 패턴은 각 어플리케이션 도메인의 성격에 따라서 도출된다. 제어 컴포넌트 패턴은 도메인의 특성에 따라서 다양하게 도출될 수 있지만, 본 방법론에서는 네 개의 제어 컴포넌트 모델에 대해서 소개한다.

  • 상태 (State) 기반 제어 컴포넌트 모델
  • 의사결정 구조 (Decision Structure) 기반 제어 컴포넌트 모델
  • 워크플로우 (Workflow) 기반 제어 컴포넌트 모델
  • 상호작용 시나리오 (Interaction Scenario) 기반 제어 컴포넌트 모델

예를 들어, 공장 제어 시스템의 제어 컴포넌트는 일반적으로 상태 기반 제어 컴포넌트이다. 왜냐하면 공장의 상태에 따라서 외부 이벤트에 반응을 하기 때문이다. 이와 같이 시스템의 상태에 따라서 시스템을 제어하는 컴포넌트는 상태 기반 제어 컴포넌트 명세를 기반으로 개발될 수 있다. 또 다른 예로 모바일 게임 소프트웨어의 제어 컴포넌트는 상호작용 시나리오 기반이다. 왜냐하면 정해진 상호작용 시나리오를 바탕으로 사용자의 입력에 대응하여 게임 화면이 전환되기 때문이다. 이와 같은 시스템은 상호작용 시나리오 기반 제어 컴포넌트 명세로 개발될 수 있다.

이처럼 개발 대상이 되는 소프트웨어의 도메인의 특성에 따라서 적절한 제어 컴포넌트 모델을 선택하고, 각 제어 컴포넌트 모델의 행위 명세 방법을 통해 제어 컴포넌트의 행위를 모델링하고 다른 자산 컴포넌트들을 제어 컴포넌트를 통해 통합할 수 있다.

제품라인의 다양한 요구사항을 만족시키기 위해서 제품라인 제어 컴포넌트 명세에 가변점 (Variation Point)을 넣어서 개발하려는 대상 제품에 따라서 제품라인 제어 컴포넌트 인스턴스가 생길 수 있도록 하여야 한다. 이를 위해서 휘처 모델의 선택 (Optional) 및 택일 (Alternative) 휘처를 제품라인 제어 컴포넌트 명세의 매개변수로 사용하도록 한다. 이를 통하여 휘처 선택에 따라서 제품라인 제어 컴포넌트 명세를 설정 (Configure) 할 수 있게 된다. 어플리케이션 공학 단계에서 개발하려는 제품의 휘처를 선택하면 제품라인 제어 컴포넌트 명세에서 선택되지 않은 휘처에 해당하는 부분은 제외되어 개별 제품의 제어 컴포넌트 명세 인스턴스가 생성된다.


Connector Development

본 방법론은 컴포넌트 설계/개발 시 컴포넌트로부터 컴포넌트 연결 메커니즘을 분리하여 아키텍처에서 컴포넌트 사이의 연결 관계가 느슨하게 연결되도록 하고 (즉, 논리적으로만 연결되도록 함), 구체적인 연결 메커니즘은 프로세스 컴포넌트를 배포(Deployment) 할 때 결정 할 수 있는 방법을 제공한다. 이를 통해서 배포 아키텍처를 유연하게 만들 수 있고, 컴퓨팅 환경에 따라서 프로세스를 네트워크에 분산하는 방식을 쉽게 바꿀 수 있다.

커넥터 개발에 적용할 수 있는 메커니즘의 종류는 아래와 같다3).

Subsystem Level Data Flow Control Flow
Process Level Message Queue Message/Reply Shared Data Event
Programming Interface Level Socket Procedure Call Shared Memory Implicit Invocation
Implementation Level Local Socket Java Socket Local Procedure Call Remote Procedure Call Local Shared Memory Remote Shared Memory Local Observer Pattern Remote Observer Pattern

See Also

1) E. M. Dashofy et al. 2001. A highly-extensible, XML-based architecture description language. WICSA '01, 103-112.
2) R. van Ommering et al. 2000. The Koala component model for product families in Consumer Electronics Software. IEEE Computer. 33, 2 (Mar. 2000), 78-85.
3) K. Kim. Design and implementation of layered connectors for software component composition. Master thesis, Dept. of CSE, POSTECH (1998).
process/pl_com_design.txt · 마지막으로 수정됨: 2014/11/25 00:06 저자 edeward