Product Lines Platform Wiki

The most promising software development paradigm for increasing productivity.

사용자 도구

사이트 도구


assets:architecturemodel

Architecture Model

소프트웨어 제품라인에서 소프트웨어 아키텍처는 가장 중요한 핵심 자산 중에 하나이다. 왜냐하면 시스템을 구성하는 컴포넌트가 같은 아키텍처를 기반으로 운영되어야만 컴포넌트 또는 모듈의 재사용성이 보장 될 수 있기 때문이다.

도메인 엔지니어링 과정에서 설계되는 아키텍처를 흔히 제품라인 아키텍처라고 부른다. 이는 아키텍처에 도메인의 분석 결과가 반영되어 가변정보가 연결되거나 포함되어 있기 때문이다. 이후 어플리케이션 엔지니어링 과정에서는 제품구성정보를 이용하여 이 제품라인 아키텍처로부터 제품을 위한 아키텍처 인스턴스를 생성한다. 이렇게 인스턴스로 생성된 아키텍처를 제품라인 아키텍처와 구분하기 위해서 제품 아키텍처라고 부른다.

FORM 제품라인 방법법에서는 시스템의 밑그림을 그리는 과정인 아키텍처 설계를 위해 기본적으로 아래의 <그림1>과 같은 아키텍처 모델을 제안한다.

<그림1> 아키텍처 모델과 구성요소들 사이의 관계

  • 개념적 아키텍처 모델(또는 서브시스템 아키텍처 모델)
  • 프로세스 아키텍처 모델
  • 배치 아키텍처 모델
  • 컴포넌트 모델

Conceptual Architecture Model

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

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

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

개념적 아키텍처 모델은 <그림3>과 같이 개념적인 컴포넌트(Conceptual Component)단위로 계층적으로 세분화 될 수 있으며 세분화된 계층들 가운데 최상위에서 구분된 기능을 서브시스템(Subsystem)이라고 할 수 있다. 개념적인 컴포넌트를 이용하여 기능의 세분화를 진행하다가 더이상 세부 기능으로 구분할 필요가 없거나 구분될 수 없는 개념적인 컴포넌트를 기능적인 컴포넌트(Functional Component)라고 한다. <그림2>의 예에서 운전제어시스템관리시스템은 필요시 좀 더 세분화된 개념적 컴포넌트로 나눠질 수 있다.

<그림3> 개념적 컴포넌트를 이용한 아키텍처의 세분화 개념


Process Architecture Model

프로세스 아키텍처 모델은 소프트웨어의 기능적인 측면에서 구조적으로 조직화된 개념적 컴포넌트의 동시성(Concurrency) 구조를 표현한다. 즉, 시스템 실행(Run-Time)시의 동적 행위를 표현하는 것으로 시스템이 몇 개의 독립적인 프로세스 컴포넌트로 구성되어 동작할지를 구조적으로 나타낸다.

프로세스 아키텍처를 구성하는 프로세스 컴포넌트(Process Component)는 동시에 실행될 수 있는 단위를 의미하며 구현시에 개발 플랫폼 또는 개발 언어에 따라서 프로그램(Program), 프로세스(Process), 태스크(Task) 또는 쓰레드(Thread) 형태로 구분되고 구현될 수 있다.

프로세스 컴포넌트는 다음과 같은 세가지 속성을 가질 수 있다.

  • 할당된 개념 컴포넌트 (Deployed Conceptual Components): 개념적 컴포넌트들은 기능적인 측면에서의 논리적인 묶음이므로 반드시 묶음 단위로 동시성을 가진다고 할 수 없다. 따라서 하나의 프로세스 컴포넌트에는 한 개 이상의 개념적 컴포넌트가 할당 될 수 있으며 할당된 개념적 컴포넌트들은 하나의 태스크 또는 쓰레드에서 순차적으로 실행된다.
  • 우선순위: 하나 이상의 프로세스 컴포넌트가 공유자원에 대한 접근이 필요한 경우 경쟁조건을 막기 위한 우선순위가 설정 될 수 있다.
  • 실행주기: 주기적으로 수행되어야 하는 프로세스 컴포넌트의 주기를 설정 할 수 있다.

프로세스와 프로세스 사이의 상호작용은 프로세스 커넥터(Process Connector)를 이용하여 연결된다. 프로세스 커넥터는 이후 메시지 통신, 공유데이터, 이벤트 동기화등의 방식으로 구현될 수 있다. 프로세스 통신 커넥터는 개념 컴포넌트들 사이의 연결관계가 프로세스 아키텍처에서 상세화 (Refinement)된 것이다. 그러므로 개념 컴포넌트 사이의 논리적인 상호작용이 존재한다면 프로세스 컴포넌트 사이에도 프로세스 커넥터로 연결이 되어 있어야 한다.

<그림3> 운전제어시스템의 프로세스 아키텍처 예제

<그림3>은 개념적 아키텍처에서 정의된 운전제어시스템에 연결된(Mapping) 프로세스 아키텍처의 예를 보여준다. 예제에서 정의된 프로세스 컴포넌트는 모두 상주 프로세스로 데이터가 입력될 때마다 해당 데이터를 처리한 이후, 상호작용 방식에 따라 연산 결과를 다른 프로세스 컴포넌트로 전달하게 설계되어 있다. 프로세스 컴포넌트들 사이에 통신 방식은 크게 메시지 큐(Message Queue)와 메시지 응답(Message Reply) 방식만 사용되고 있다. 메시지 큐는 비동기 방식이므로 이 방식으로 연결된 프로세스들은 동시에 병렬 수행되고, 메시지 응답은 동기식 방식인 관계로 데이터를 보내는 프로세스 컴포넌트가 데이터를 수신한 프로세스 컴포넌트로부터 응답이 올때까지는 대기하고 있어야 한다.

<그림4> 개념적 컴포넌트와 프로세스 컴포넌트들 사이의 연결 관계

앞서 설명하였듯이 개념적 컴포넌트는 프로세스 컴포넌트들과 맵핑관계를 가진다. 상세화된 한개 이상의 개념적 컴포넌트들은 하나의 프로세스 컴포넌트에 맵핑될 수 있다. <그림4>는 개념적 컴포넌트와 프로세스 컴포넌트 사이의 연결관계를 보여준다. 개념적 컴포넌트 A-1A-2가 하나의 프로세스 컴포넌트 P1에 맵핑되었으며, A-3P2에 맵핑된것을 확인 할 수 있다. P1에 맵핑된 두 개의 개념적 컴포넌트들은 별도의 상호작용 방식이 없다면 순차적으로 실행될 것이다. 무엇보다 중요한 것은 두 아키텍처를 구성하는 컴포넌트들 관계에 대한 일관성을 유지하는 것이다.

프로세스 아키텍처를 설계 할때 방법론에서 제공하는 아키텍처 세분화 지침를 따를 수 있다.


Component Model

컴포넌트 모델은 각 프로세스 컴포넌트의 구현을 위해 도메인 분석 과정에서 식별된 컴포넌트(또는 모듈)들의 통합된 모습을 표현한다. 프로세스 컴포넌트 구현을 위해 필요한 컴포넌트들 사이의 구조적인 관계가 도식화 된다.

컴포넌트들 사이의 구조적인 관계는 <그림5>와 같이 일반적으로 계층적인 아키텍처 스타일(Layered Architecture Style)로 나타난다. 시스템을 구성하는 컴포넌트들의 유형이 계층적이기 때문이다. 컴포넌트 모델을 구성하는 컴포넌트들의 유형은 여기에서 확인 할 수 있다.

컴포넌트 모델을 구성할때 개념적 아키텍처에서 도출된 기능적 컴포넌트(Functional Component)들이 반영이 된다.

<그림5> 컴포넌트 모델의 예

대상 시스템이 객체-지향적으로 개발될 수 있다면 모듈 아키텍처를 설계 할때 방법론에서 제공하는 설계 객체 모델링 지침를 따를 수 있다.


Deployment Architecture

배포 아키텍처(Deployment Architecture)는 소프트웨어가 물리적인 하드웨어 노드에 어떻게 할당되는 가를 나타낸다. 노드(Node), 소프트웨어 요소(Element), 노드 사이의 연결 관계로 정의된다.

  • 노드(Node): 소프트웨어 엘리먼트가 배치될 물리적인 컴퓨팅 장치를 의미한다. 일반적인 데스크탑 컴퓨터 또는 컴퓨팅 파워가 내장된 다양한 모바일 단말 장치도 될 수 있다. 노드의 속성으로 CPU 속성 및 메모리 속성 등이 있고, 노드 사이의 연결관계에는 속성으로 통신 대역폭(Bandwidth), 처리량 (Throughput)등을 할당 할 수 있다.
  • 소프트웨어 요소:는 프로세스 컴포넌트 또는 서브시스템가 될 수 있다. 노드에 프로세스 단위로 시스템을 배포 할 수도 있으며 서브시스템 단위로 배포가 될 수 있다.

시스템 개발과정에서 배포 아키텍처의 상세한 결정은 최대한 늦게 결정이 될 수 있도록 하는 것이 분산환경에서 유연한 시스템으로 동작 할 수 있다.

배포 아키텍처를 설계 할때 방법론에서 제공하는 아키텍처 세분화 지침를 따를 수 있다.


Language for Architecture Modeling

시스템적으로 아키텍처 모델링을 지원하는 방법은 아래의 두가지 이다.

  • ASADAL/PLSE Architecture Modeling : FORM방법론을 최조로 지원하는 ASADAL도구에서 제공하는 아키텍처 모델링 편집환경. 이 도구를 이용하여 아키텍처를 설계할 수 있다. FORM 고유의 표기법을 제공한다.
  • FORM-UML : VULCAN 워크벤치에서 제공하는 모델링 편집 방법 및 환경. UML 표기법을 차용하여 FORM 아키텍처 설계를 할 수 있게 아키텍처에 대한 모델링 방법을 제공한다. 편집도구로 StarUML을 제공하며, StarUML을 이용하여 설계된 아키텍처정보는 다른 워크벤치 도구와 연동이 된다.

See Also

assets/architecturemodel.txt · 마지막으로 수정됨: 2014/11/25 00:03 저자 edeward