아키텍쳐 서술의 추천 프랙티스

출처 : http://2005elc.elancer.co.kr/eTimes/page/eTimes_printFm.html?str=c2VsdW5vPTg0Ng==

1.아키텍쳐 서술의 추천 프랙티스 2005/12/13

---

　IT시스템에 대한 요구의 다양화, 아키텍쳐의 대규모화와 복잡화에 대응하기 위해서는 현실 세계나 시스템화 대상을 다양한 각도로 표현하는 방법이 필요하다. 이번엔 Zachman 체제나 UML의 각종 다이어그램 등에도 볼 수 있는 시스템 표현의 체계화 기반기술의 하나인「뷰포인트」를 취급한다.

　뷰포인트는 시스템 표현 모델의 적절한 이용 문맥을 정의하는 시점이라고 할 수 있다. 이것은 IT시스템의 stakeholder(이해관계자)에 대해서 적절한 문맥으로 시스템 표현을 실시하기 위해서 필요한, 시스템 표현 모델 체계화의 골조를 정의한다.

　아키텍트가 UML을 이용해 시스템 구축을 하는 경우,「어느 UML 다이어그램을 어느 순서로 정의해 나가야 할까」를 결정하는 골조가 개발 방법론이다. 아키텍트는 경험 원칙이나 채용하는 개발 방법론에서 정해진 순서에 따른다. 뷰포인트는 이러한 경험 원칙이나 프랙티스에 따르는 부분을 가능한 한 명확하게 정의된 골조를 준비해, 소프트웨어 개발에 공학적 어프로치를 적용해 나가려는 컨셉이있다.

◆아키텍쳐 서술의 추천 프랙티스

　소프트웨어 아키텍쳐에는 다양한 정의가 존재한다. 그 이유는 아키텍쳐를 표현하는 방법이 한개로는 정해지지 않기 때문이다. 아키텍쳐 자체가 복수의 각도에서 표현을 조합하지 않으면 엄밀한 정의를 할 수 없는 이유때문이다.

　건축물을 설계하는 경우, 통상 3 방향에서 본 시점에서의 도면이 필요하다. 또, 상세한 구조도, 배수관이나 전기 배선도, 소재나 부품표 등 많은 부대적인 도면도 필요하다. 시각적으로 뛰어난 관점에서는, 입체적인 3 차원 도면도 있으면 더욱 좋을 것이다. 이와 같이 완성해야 할 물리적인 건축물은 한개여도, 그것을 적절히 표현하기 위한 도면은 한개가 아니다.

　그러면 어떤 도형을 사용할지, 복수의 도형을 어떻게 조합할지를 명확하게 규정하려면 어떻게 해야 할까. 각각의 도형은 그 도형으로 표현하고 싶은 관심사로 한정하고 다른 관심사는 무시하면 된다. 예를 들면, 지하철 노선도는 지하철의 경로만을 취급하고 지상에 존재하는 도로나 건물의 정보를 취급하지 않는다. 이것은 일종의 관심 분리이다.

　같은 아키텍쳐의 표현에서도 구조를 취급하는 표현, 행동을 취급하는 표현, 배치를 취급하는 표현등이 존재한다. 이러한 관심을 분리 해서 각각의 관심에서 적절한 다이어그램을 적용할 것이 요구된다. 그것을 위해서 UML에서는 많은 다이어그램이 준비되어, Zachman 체제에서 많은 관심을 체계화하는 골조가 정해져 있다.

　이러한 기술 배경에 따라 관심 분리의 원칙과 stakeholder의 시점을 고려해 아키텍쳐 서술을 정의하고 있는 것이, IEEE std 1471-2000아키텍쳐 서술의 추천 프랙티스이다.

●IEEE std 1471-2000아키텍쳐 서술의 개념 모델

　그러면 우선 이 IEEE std 1471-2000의 아키텍쳐 서술을 보자.

그림 1 IEEE std 1471-2000의 아키텍쳐 서술의 개념 모델

모델도로 기록되고 있는 키 컨셉(Stakeholder나 Concern등)의 의미에 대해서는 이후에 게재하는 표 1을 참조해 주었으면 한다. 이 개념 모델을 간단하게 설명하면 다음과 같이 된다. Stakeholder(이해관계자)의 Concern(관심)의 표현은, 그것을 표현하는 Model(모델) 정의를 규정하는 Viewpoint(뷰포인트)를 선택해 실시한다. 즉, 1. Stakeholder(이해관계자)는 1개이상의 Concern(관심)을 가지고 그러한 Concern을 표현하기 위한 Viewpoint(뷰포인트)를 선택한다. 2. Viewpoint의 선택은 Concern을 표현하는 Model(모델) 정의의 규정을 부여할지 말지를 판단해서 결정한다. 이 Viewpoint는 Concern의 표현에 적절한 관심 분리를 부여하는 Library Viewpoint(라이브러리화 된 뷰포인트)에서선택한다. 복수의 Mission(목적)을 가진 Environment(제약 조건)를 가지는 System(시스템화 대상)에 대한 Architecture(아키텍쳐)를 구축한다. 구축되는 Architecture는 Architecture Description(아키텍쳐 서술)로 정의된다. 아키텍쳐의 정의에는 정의 한 아키텍트가 설명 책임을 가진 Rationale(이유 부여)을 수반한다. 여기서, 3. 아키텍쳐(Architecture)는 복수의 Model를 사용한 View(뷰)로서 표현된다. 4. 게다가 복수의 View로 아키텍쳐가 기술되어(Architectural Description), Model 정의의 규정을 부여하는 Viewpoint에 의해서 View는 관심 분리의 원칙에 따른다. 5. Viewpoint에 의한 관심의 분리는 Stakeholder의 다차원적인 요구에 골조를 부여한다. Software Factories는 이 일련의 Viewpoint 골조를 개발 기반기술에 적용하고 있다.

　그림 1은 IEEE std 1471-2000의 아키텍쳐 서술의 개념 모델을 정의하고 있다.

　이 그림에서는 키 컨셉과 그 관계를 메타 모델 표현으로서 정의하고 있다. 이 모델 자체는 어느 시스템이 단일 아키텍쳐로 구축되는지, 한 아키텍쳐가 단일 아키텍쳐 서술로 정의되는 지도 가정하고 있지 않다. 즉 시스템이 복수 아키텍쳐, 예를 들면 파이프라인과 이벤트 드리븐 아키텍쳐로 구축되어도, 각각의 아키텍쳐의 기술법을 통일해야 하는 강제력을 가지지 않는다.

　그림 1의 키 컨셉을 정리한 것이 다음의 표 1이다.

키 컨셉	의미
Stakeholder： 이해관계자	시스템의 아키텍쳐의 이해관계자 .예를 들면 아키텍트, 프로그래머, 시스템 운용자, 데이타베이스 관리자, 최종 사용자, 경영자, 프로젝트 매니저, 비즈니스 분석자 등. 각각 다른 관심을 가지고 있어, 서로의 요구에 모순이나 부정합이 존재한다
Concern： 관심	기능 요구와 비기능 요구, 정적인 구조와 동적인 동작, 개념/논리/물리 레벨의 관점, 표시와 정보, 시큐러티나 성능, 서비스 내용과 서비스 배치 등, 개발과 관계되는 요소, 조건을 분할해 고려하는 경우의 스코프
Viewpoint： 뷰포인트	뷰를 기술, 분석하기 위한 모델(뷰포인트 언어)과 모델에 적용하는 모델링 수법, 분석 수법등의 규정. 아키텍쳐 서술에서는 1개이상의 뷰포인트을 선택한다
View： 뷰	(복수의) stakeholder의 (복수의) 관심에서 본 시스템 전체의 표현. 1개이상의 모델로 표현된다
Model： 모델	기법. 예를 들면 UML 다이어그램, DSL등의 표현. 1개이상의 뷰에 속하는 것도 있다
표 1 IEEE std 1471-2000의 키 컨셉(발췌)

　예를 들면, Web 어플리케이션에서 구축되는 서적 구입 사이트는 아키텍트의 관심으로서, Web 서버상의 UI프로세스, Web 페이지 레이아웃 정의, 비즈니스 논리의 컴퍼넌트 구조, 비즈니스 논리의 오브젝트의 순서(동작), 컴퍼넌트 배치, 데이터 액세스층, 데이타베이스의 테이블 정의등에서 구축된다.

　이 경우에는 UI프로세스등이 모델로, 이러한 모델을 모아 아키텍쳐가 서술된다. 모델은 복수의 stakeholder의 관심의 표현과 관계된다. 여기서의 컴퍼넌트 배치 모델은 아키텍트의 관심 모델로서 뿐만이 아니라 시스템 운용자의 관심 모델로서도 이용된다.

◆stakeholder에 의한 관심 분리

　여기서 좀 더 stakeholder의 관심의 표현을 보고 가자. 그림 2는 stakeholder에 의한 관심 분리의 예이다. 이 그림에서는 각각의 stakeholder의 역할에 따라서 필요로 하는 아키텍쳐 서술의 표현법이 다른 것을 나타내고 있다.

그림 2 stakeholder에 의한 관심의 분리

stakeholder의 역할에 따라 관심이 다르기 때문에 그 관심을 표현하는 모델도 다르다. 이 예에서는 비즈니스 분석자의 관심인 비즈니스 요구를 개념 레벨의 유스 케이스 모델로 표현한다. 같이 프로그래머는 구현해야 할 코드의 논리 모델을 구현에 활용한다. 데이타베이스 관리자는 관리 대상 데이타베이스의 데이터 모델로부터 데이터 구조를 파악한다.

　아래와 같이 stakeholder의 관심은 다양한 관점으로 분류할 수 있다.

(1) 관심을「정적 구조와 동적 행동」으로 분류하면 정적 구조에서는 아키텍트의 관심을 표현하는 비즈니스 논리의 컴퍼넌트 구조나, 시스템 운용자의 관심을 표현하는 컴퍼넌트 배치가 포함된다. 또, 동적 동작에는 아키텍트의 관심을 표현하는 비즈니스 논리의 오브젝트 순서도나, 시스템 운용자의 관심을 표현하는 메세지 제휴가 포함된다.

(2) 관심을「정보 도메인」으로 분류하면 아키텍트의 관심을 표현하는 데이타베이스 테이블 정의나, 비즈니스 분석자의 관심을 표현하는 정보 엔티티이다.

(3) 관심을「논리 레벨과 물리 레벨」로 분류하면 논리 레벨에는 아키텍트의 관심을 표현하는 비즈니스 논리의 컴퍼넌트 구조가 포함되고, 물리 레벨에는 데이타베이스 관리자의 관심을 표현하는 데이타베이스 정의가 포함된다.

　이것들 3 종류의 관심의 분류법은 각각

(1) UML 다이어그램의 정적/동적 모델(=정적 구조와 동적 동작)

(2) EA(Enterprise Architecture)의 비즈니스/정보/어플리케이션/기반구조(=정보 도메인)

(3) 개발 라이프 사이클의 개념/논리/물리 레벨

로 관심을 분류해 stakeholder의 관심 모델을 선택해서 표현하는 예이다.

　관심 분류법을 이정도로 한정하지 말고 아키텍쳐 서술에 적절한 관심을, 적절한 분류법을 기준으로해서 선택하면 좋겠다*1. 이 분류법은 아키텍쳐 서술에 필요한 모델의 편성을 규정하는 뷰포인트가 결정한다.

*1 예를 들면, Philippe Kruchten씨의 “4+1” 뷰 모델( 「The 4+1 View Model of Architecture」, IEEE Software, vol. 12, No. 6, November 1995, pp. 42-50이나 ISO/IEC 10746-2의 「Reference Model for Open Distributed Processing」(RM-ODP)은 다른 분류법을 정의하고 있다.