[SA강좌] Part 1-6 소프트웨어 아키텍처의 구성요소

소프트웨어 아키텍처의 구성요소에 대해서 상세하게 살표보면 다음과 같은 구성 요소로 이루어짐을 알 수 있다.

• 시스템의 구성요소와 구성 요소 들 사이의 연결 관계
• 시스템의 설계와 진화를 통제하는 원칙과 가이드라인
• 시스템 구성 요소들의 collaboration ( 성과 )
• 시스템이 어떻게 확장되고 수정될 것인가에 대한 결정
• 시스템의 구성 요소들이 가지고 있는 기술

다음 그림은 소프트웨어 아키텍처의 구성요소를 보여준다.

그림 Ⅱ-1. 소프트웨어 아키텍처 산출물

그림 Ⅱ-1를 보면 소프트웨어 아키텍처는 세가지로 구분된다.

Meta-Architecture는 아키텍처를 설계하기 위한 일반적인 지침이다. Meta-Architecture는 소프트웨어 아키텍처가 무엇인지 결정하고 아키텍처를 설계하기 위한 일반적인 의사 결정 트리와 아키텍트의 역할에 대한 정의, 아키텍처 문서에 대한 템플릿으로 구성된다.

소프트웨어 아키텍처는 네 가지 View인 module view, component&connector view, allocation view, code view로 구성된다. 또한 아키텍처 설계의 결과로 컨텍스트 다이어그램, 컴포넌트 명세, 인터페이스 명세가 도출되어야 한다.

View에 대해서는 사람마다 정의하는 방법이 다양하므로 이에 대한 논란은 나중에 하도록 하고, 먼저 그냥 서술해보자. 이 View는 사람들마다 서술하는 방법, 기술하는 방법, 다이어그램의 형태, 박스/라인/인터페이스/컴포넌트의 수준과 깊이/의미등이 다 다르다.

다만, View의 선정 기준과 기술할 때 주의점만 살펴보면된다.

건축물을 설계할때의 조감도 및 설계도, 세부 설계도, 투시도 등등의 형태와 동일하다고 보면 된다, 필요 수준까지만 각자 알아서 그리면 되는 것이다.

일반적인 view는 3가지이다. Allocation View, Component & Connector View, Module View라 이야기하지만 저는 Code view를 하나 더 구분해야 한다고 본다. 너무 상세한 설명은 나중에 거론하기로 하고 하여간 4개의 View가 있다고 보자.

이 부분은 적어도 1개 이상에 대해서 기술하고 몇 개가 적절한 가는 개발자들의 역량과 도메인에 대한 이해, 이전 프로젝트의 경험 및 주요 이슈 사항등의 요소에 의해서 좌우되어진다.

다만, 시스템의 큰 기능, 품질 속성 ( 가용성, 변경성, 보안성, 성능 )의 판단 근거가 되어야 하며, 주요 모둘의 기능이 내/외부와 어떤 연관성을 가지는지 보여야 하고, 시스템의 규모와 범위를 파악할 수 있으면 된다.

또한, 위와 같은 아키텍쳐 기술 정의서를 구축할 때에 타당한 근거를 서술할 수 있으면 된다.

다만, 이 View를 UML 1.x영역에서는 표현하기 힘들었다. 너무 기술에 종속적인 패턴의 설계 혹은 컴포넌트의 배치 레벨에서의 작성이 주였기 떄문이다. UML 2.0울 구성할때에 OMG에서 카네기 멜론 SEI의 아키텍쳐 정의를 상당부분 도입하여서 이 부분들에 대한 기술이 이젠 수월해진 편이다.

OMG는 재미있는 기관이다. 좌우당간…

가이드라인과 정책은 소프트웨어 아키텍처를 결정한 후 아키텍처를 기반으로 프로젝트를 진행하기 위한 가이드라인과 정책을 말한다. 아키텍트는 설계, 코딩, 배포, 통합, 테스트, 툴, 유지보수, 시스템 확장, 시스템 운영에 대한 가이드라인과 정책을 마련해야 한다. 정말 포괄적인 개발정책 부분을 모두 서술하고 결정한다는 것이다.

소프트웨어 아키텍처는 시스템 개발의 여러 구성요소와 관련을 갖는다. 프로젝트 조직, 프로젝트 스케줄, 형상 관리 계획은 소프트웨어 아키텍처에 근거하여 결정된다. 소프트웨어 아키텍처를 설계하는 데는 프로토타입, 프레임워크, 유틸리티 프로그램 등이 영향을 끼친다.