The most promising software development paradigm for increasing productivity.
본 단계에서는 이전 단계인 휘처 모델링 단계에서 작성한 휘처 모델 및 제품라인 요구사항 분석 단계에서 분석한 제품라인의 기능/비기능 요구사항을 바탕으로 제품라인의 개념적 아키텍처 (Conceptual Architecture)를 설계하는 단계이다.
시스템에서 제공하는 논리적인 기능을 구조적으로 구분하고 구분된 기능들 사이의 상호작용을 모델링하기 위한 아키텍처 모델이다. 이 아키텍처 모델은 시스템을 기능적 측면에서 구조적으로 나눠 논리적인 구조로 어떻게 짜임새 있게 표현할 것인가에 대해서 나타내는 것이므로 시스템의 속도, 안전성, 보안성등과 같은 시스템의 비기능적(Non-Functional) 요소(예를 들어, 신뢰성이나 확장성 등)를 충분히 고려하여 구조화가 진행된다. 즉, 제품라인의 개념적 아키텍처는 비기능적인 요소를 고려한 기능상 긴밀한(Cohesive) 컴포넌트들의 구조 관계을 나타낸다.
아래의 <그림>은 개념적 아키텍처의 예를 보여준다. 개념적 아키텍처에서 개발자는 시스템과 외부 개체들 그리고 구분된 개념적인 기능들 사이의 제어와 데이터 흐름을 모델링 할 수 있다.
<그림> 개념적 아키텍처의 예
개념적 아키텍처의 설계시 가장 최상위 개념적 컴포넌트는 서브시스템으로 분류 될 수 있다. 서브시스템을 식별 할 때 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) 역할을 수행한다.
개념적 아키텍처 모델을 이용하여 개념적 아키텍처를 설계 할때 식별되고 구조화 되는 개념적 컴포넌트(Conceptual Component)들은 일반적으로 일반적으로 다음과 같은 컴포넌트의 유형으로 분류될 수 있다. 컴포넌트는 유형에 따라서 아래의 <그림>과 같이 계층적 아키텍처 형태로 구분된다. 여기서 정의된 컴포넌트 유형은 이후 설계 객체 모델링 단계에서 식별된 객체들과도 연관된다.
Domain Component | Application Task Component | |
---|---|---|
Functional Component | ||
Domain Technology Component | ||
General Component | Interface Component | Data Sharing/Communication Component |
Architecture Platform |
<그림> 컴포넌트 유형의 분류와 컴포넌트의 위상
Architecture Platform
유형을 제외하고 개념적 아키텍처와 컴포넌트 모델에서 식별된 컴포넌트들은 외에 제시된 컴포넌트 유형으로 구분될 수 있다.
컴포넌트의 유형은 아래와 같이 좀 더 크게 네 가지로도 분류될 수도 있다. 앞의 분류와 비교해 볼때 Application Task Component
와 Functional Component
는 제어 컴포넌트
에 속하며, Domain Technology Component
는 연산컴포넌트
분류에 속하게 된다.