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

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

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

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

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

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)들은 일반적으로 일반적으로 다음과 같은 컴포넌트의 유형으로 분류될 수 있다. 컴포넌트는 유형에 따라서 아래의 <그림>과 같이 계층적 아키텍처 형태로 구분된다. 여기서 정의된 컴포넌트 유형은 이후 설계 객체 모델링 단계에서 식별된 객체들과도 연관된다.

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

• 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 Component와 Functional Component는 제어 컴포넌트에 속하며, Domain Technology Component는 연산컴포넌트 분류에 속하게 된다.

• (사용자) 인터페이스(User Interface) 컴포넌트: 사용자 또는 외부설비 사이의 인터페이스를 담당하는 역할을 수행한다. 사용자의 입력 또는 센서로부터 수집되는 데이터를 제어 컴포넌트로 전달하거나 제어 컴포넌트로부터 생성되는 데이터를 외부의 화면이나 구동기 (Actuator) 로 전달하는 역할을 수행한다. 일반적으로 요구사항이 자주 바뀌기 때문에 변경이 자주 일어나는 특성이 있다.

• 제어(Control) 컴포넌트: 시스템의 외부에서 전달되는 데이터 또는 이벤트를 기반으로 소프트웨어의 행위를 제어하고, 특정 조건이 만족할 때 서비스 또는 함수를 기동시키는 역할을 수행한다. 소프트웨어의 아키텍처를 결정하는 가장 핵심적인 역할을 수행하며 가장 높은 복잡성을 가진다.

• 연산(Computation) 컴포넌트: 알고리즘을 수행하여 입력 값에 대한 출력 값을 계산을 수행하는 역할을 담당한다. 일반적으로 다른 컴포넌트에 비해 상대적으로 변경이 적게 일어나는 특성이 있다.

• 데이터 관리(Data Management) 컴포넌트: 어플리케이션 데이터나 비즈니스 룰을 관리하고 다른 컴포넌트들에게 이를 제공하는 컴포넌트이다. 일반적으로 다른 컴포넌트에 비해 상대적으로 변경이 적게 일어나는 특성이 있다.

• Core Assets > Conceptual Architecture
• Workbench > Architecture Modeling