Product Lines Platform Wiki

The most promising software development paradigm for increasing productivity.

사용자 도구

사이트 도구


process:pl_conceptual_arc

Domain Engineering Process

Conceptual Architecture Design

본 단계에서는 이전 단계인 휘처 모델링 단계에서 작성한 휘처 모델 및 제품라인 요구사항 분석 단계에서 분석한 제품라인의 기능/비기능 요구사항을 바탕으로 제품라인의 개념적 아키텍처 (Conceptual Architecture)를 설계하는 단계이다.

시스템에서 제공하는 논리적인 기능을 구조적으로 구분하고 구분된 기능들 사이의 상호작용을 모델링하기 위한 아키텍처 모델이다. 이 아키텍처 모델은 시스템을 기능적 측면에서 구조적으로 나눠 논리적인 구조로 어떻게 짜임새 있게 표현할 것인가에 대해서 나타내는 것이므로 시스템의 속도, 안전성, 보안성등과 같은 시스템의 비기능적(Non-Functional) 요소(예를 들어, 신뢰성이나 확장성 등)를 충분히 고려하여 구조화가 진행된다. 즉, 제품라인의 개념적 아키텍처는 비기능적인 요소를 고려한 기능상 긴밀한(Cohesive) 컴포넌트들의 구조 관계을 나타낸다.

아래의 <그림>은 개념적 아키텍처의 예를 보여준다. 개념적 아키텍처에서 개발자는 시스템과 외부 개체들 그리고 구분된 개념적인 기능들 사이의 제어와 데이터 흐름을 모델링 할 수 있다.

<그림> 개념적 아키텍처의 예


Subsystem Identification

개념적 아키텍처의 설계시 가장 최상위 개념적 컴포넌트는 서브시스템으로 분류 될 수 있다. 서브시스템을 식별 할 때 Gomaa1)가 소개한 다음의 지침을 사용할 수 있다.

Functionality: 하나의 잘 정의된 기능 또는 밀접한 기능을 수행하는 프로세스들은 같은 
서브시스템에 할당할 수 있다. 왜냐하면 일반적으로 이러한 기능들 사이에는 데이터 트래픽이 
많기 때문에 이들을 다른 노드에 할당하면 시스템 오버해드가 커지기 때문이다.
Server: 클라이언트 (Client) 서브시스템에게 서비스를 제공하는 서버를 서브시스템으로 
정의할 수 있다. 서버는 요청을 만들지 않고, 클라이언트의 요청 (Request)에 대응하는 
역할을 한다. 주로 서버는 데이터 저장소 (Data Store)과 관련된 기능을 제공할 때가 많다.
Agent: 단방향의 서비스를 제공하는 에이전트(Agent)를 서브시스템으로 정의할 수 있다.
에이전트 서브시스템이 서비스를 수행하기 위해서는 다른 서브시스템에 요청을 해야만 한다. 
따라서 에이전트는 클라이언트와 서버 사이의 중개인으로 볼 수 있다.
Proximity to the Source of Physical Data: 물리적 데이터에 빠르게 접근하기 위하여 
물리적 데이터 소스에 근접한 서브시스템을 정의할 수 있다. 특히 물리적 데이터의 접근 
속도가 높을 때일수록 이러한 서브시스템의 정의가 중요하다.
Localized Control: 특정 사이트에 관련된 (Site-Related) 기능이 있는 경우, 이를 하나의 
서브시스템에 할당할 수 있을 때가 있다. 주로 같은 기능이 여러 사이트에서 수행될 수 있는데, 
이 경우, 서브시스템의 각 인스턴스 (Instance)를 독립된 노드에 배포하여 높은 자치성을 갖고 
로컬 제어를 하도록 할 수 있다. 이 경우, 만약 서브시스템이 다른 노드와 비교적 독립적으로 
수행된다면, 다른 노드가 일시적으로 사용가증하지 않더라도 해당 서브시스템이 동작할 수 
있을 것이다.
Performance: 시스템의 성능을 높이고 성능의 예측가능성을 높이기 위하여, 긴급하게 
수행되어야 하는 (Time Critical) 기능이 하나의 서브시스템에서 수행되도록 프로세스를 
할당할 수 있다.
User Interface: 워크스테이션 (Workstation)과 PC가 분산된 환경에서 사용자 인터페이스 
(User Interface)를 제공하는 서브시스템이 독립된 노드에서 작동되어 다른 노드의 
서브시스템과 상호작용할 수 있다. 이 경우 사용자 인터페이스 서브시스템은 액터(Actor) 
역할을 수행한다.

Component Type Identification

개념적 아키텍처 모델을 이용하여 개념적 아키텍처를 설계 할때 식별되고 구조화 되는 개념적 컴포넌트(Conceptual Component)들은 일반적으로 일반적으로 다음과 같은 컴포넌트의 유형으로 분류될 수 있다. 컴포넌트는 유형에 따라서 아래의 <그림>과 같이 계층적 아키텍처 형태로 구분된다. 여기서 정의된 컴포넌트 유형은 이후 설계 객체 모델링 단계에서 식별된 객체들과도 연관된다.

Domain Component Application Task Component
Functional Component
Domain Technology Component
General Component Interface Component Data Sharing/Communication Component
Architecture Platform

<그림> 컴포넌트 유형의 분류와 컴포넌트의 위상

  • Application Task Component: 제어(Control) 및 조정(Coordination) 역활을 수행하는 컴포넌트
  • Functional Component: 서비스 및 오퍼레이션 역활을 수행하는 컴포넌트
  • Domain Technology Component : 특정 도메인에서 사용되는 알고리즘 이나 기술을 구현한 컴포넌트
  • Data Sharing/Communication Component: 메시지 큐, 태스크 동기화 등을 담당하는 컴포넌트
  • Interface Component: 디바이스 드라이버, 사용자인터페이스를 담당하는 컴포넌트
  • Architecture Platform: UNIX pipe, RPC, CORBA등의 범용적인 컴포넌트

Architecture Platform 유형을 제외하고 개념적 아키텍처와 컴포넌트 모델에서 식별된 컴포넌트들은 외에 제시된 컴포넌트 유형으로 구분될 수 있다.

컴포넌트의 유형은 아래와 같이 좀 더 크게 네 가지로도 분류될 수도 있다. 앞의 분류와 비교해 볼때 Application Task ComponentFunctional Component제어 컴포넌트에 속하며, Domain Technology Component연산컴포넌트 분류에 속하게 된다.

  • (사용자) 인터페이스(User Interface) 컴포넌트: 사용자 또는 외부설비 사이의 인터페이스를 담당하는 역할을 수행한다. 사용자의 입력 또는 센서로부터 수집되는 데이터를 제어 컴포넌트로 전달하거나 제어 컴포넌트로부터 생성되는 데이터를 외부의 화면이나 구동기 (Actuator) 로 전달하는 역할을 수행한다. 일반적으로 요구사항이 자주 바뀌기 때문에 변경이 자주 일어나는 특성이 있다.
  • 제어(Control) 컴포넌트: 시스템의 외부에서 전달되는 데이터 또는 이벤트를 기반으로 소프트웨어의 행위를 제어하고, 특정 조건이 만족할 때 서비스 또는 함수를 기동시키는 역할을 수행한다. 소프트웨어의 아키텍처를 결정하는 가장 핵심적인 역할을 수행하며 가장 높은 복잡성을 가진다.
  • 연산(Computation) 컴포넌트: 알고리즘을 수행하여 입력 값에 대한 출력 값을 계산을 수행하는 역할을 담당한다. 일반적으로 다른 컴포넌트에 비해 상대적으로 변경이 적게 일어나는 특성이 있다.
  • 데이터 관리(Data Management) 컴포넌트: 어플리케이션 데이터나 비즈니스 룰을 관리하고 다른 컴포넌트들에게 이를 제공하는 컴포넌트이다. 일반적으로 다른 컴포넌트에 비해 상대적으로 변경이 적게 일어나는 특성이 있다.

See Also

  • Core Assets > Conceptual Architecture
  • Workbench > Architecture Modeling
1) H. Gomaa. A software design method for distributed real-time applications. Journal of Systems and Software, Volume 9, Issue 2, February 1989, pp 81–94.
process/pl_conceptual_arc.txt · 마지막으로 수정됨: 2014/11/25 00:05 저자 edeward