BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
195,318 Visitors up to today!
Today 34 hit, Yesterday 86 hit
daisy rss
2013.04.14 07:48
우리가 이 책을 읽어 나가기 위해서는 두 가지 가정에 대한 확신이 있어야 한다.

- 소프트웨어 아키텍처라는 것이 성공적인 소프트웨어 시스템을 개발하는데 중요하고,

- 우리가 배워서 적용할 만한 지식이 한 권의 책으로 채울 만큼 있다.

저자들 또한 그러한 확신이 있기 때문에 이 책을 썼을 것이다. 저자들은 우리가 이 두 가정에 확신을 갖고, 제공되는 지식을 학습한 후, 우리 스스로 적용할 수 있기를 바랄 것이다.

소프트웨어 시스템은 조직의 비즈니스 목표를 만족하기 위해 구축된다. 아키텍처는 비즈니스 목표와 최종 결과로서의 시스템 사이의 다리 역할을 해 준다. 추상적인 비즈니스 목표로 부터 구체적인 시스템을 구축하는 것은 복잡할 수 있다. 복잡성을 제거하거나 줄여서 우리가 다룰 수 있는 수준으로 만들기 위해서 우리는 뭔가가 필요하다. 이 책에서는 그 뭔가를 아키텍처라고 하는 것이다.

소프트웨어 아키텍처는 설계되고 분석되고 문서화되고 구현될 수 있다.

복잡성을 다루는 최고의 방법은 모델링이다. 복잡성을 다루고자 하는 소프트웨어 아키텍처는 태생적으로 소프트웨어 모델링이 중요한 기술로 요구된다.

 

이 장에서는 소프트웨어 공학 관점에서 아키텍처를 살펴보는데 집중할 것이다.

소프트웨어 아키텍처가 무엇인가에 대해서는 다양한 정의가 존재한다. 저자들은 다음과 같은 정의를 택하고 있다. 필자도 이 정의를 제일 나은 정의로 꼽는다. 

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.


두 번째 판의 정의에 'needed to reason about the system'을 추가했다. 구조들 중에서 어떤 것이 아키텍처 구조인가를 설명하기 위해서 추가한 부분으로 보인다. 

이 정의에 대한 세부적인 설명에서는 어떤 구조가 아키텍처 구조인가를 설명할 때 reasoning을 등장시킨다. 아래에 갈색 부분은 필자의 이해 수준에서 좀 더 직관적이도록 풀어보았다. 물론 누가 읽느냐에 따라 본문의 내용에 비해 전혀 직관적으로 느껴지지 않을 수도 있을 것이다.

 

아키텍처는 소프트웨어 구조들의 집합이다.

구조는 관계에 의해 함께 묶여진 요소들의 집합이다. 소프트웨어 시스템은 많은 구조로 구성되어진다. SEI 방식의 소프트웨어 아키텍처는 일반적으로 세 개의 범주로 구조를 나눈다.

첫 번째는 시스템을 구현 단위로 나누는 구조들이다. 이 책에서는 구현단위를 모듈(module)이라고 한다. 모듈은 특별한 책임들을 할당받고 팀에 할당되는 작업의 기본이 된다. 물론 모듈이 복잡하면 서브 팀들에 할당될 수도 있다.

분할(decomposition)은 모듈 구조의 한 종류이다. 모듈 구조는 정적(static) 구조이고, 시스템의 기능이 구현 팀에 어떻게 할당되는지에 중점을 둔다.

두 번째는 시스템의 기능을 수행하기 위해 런타임시에 구성요소들이 어떻게 상호작용할 것인가를 나타내는 동적 구조이다. 이 책에서는 이 런타임 구조를 컴포넌트 커넥터(component-and-connector, C&C) 구조라고 부른다. 이 책에서 컴포넌트라는 용어는 항상 런타임 실체를 나타낸다.

세 번째는 소프트웨어 구조를 시스템 조직, 개발, 설치, 실행 환경에 매핑을 기술하는 구조들이다. 예를 들어 모듈은 팀에 개발을 위해 할당되고, 구현과 통합과 시험을 위해 파일 구조의 위치에 할당된다. 컴포넌트는 실행을 위해 하드웨어에 배치된다. 이들 매핑들은 할당(allocation) 구조라고 불린다.

 

모든 구조가 아키텍처 구조는 아니다.

소프트웨어 시스템에는 다양한 이해관계자들이 있다. 소프트웨어 시스템은 그들의 이해관계를 만족 시켜줄 수 있는 특성들(properties)을 가져야 한다. 시스템 특성들은 이해관계자들의 이해관계를 만족시켜줄 수 있음을 나타내는 근거(reasoning)로 작용한다. 이것들과 관계된 구조만이 아키텍처 구조이다.

아키텍처는 추상이다.

시스템에 대한 reasoning으로 사용되지 않는 요소와 관계는 감춘다.

소프트웨어 아키텍처는 세부적인 사항들을 감추고, 시스템에 대해서 어떤 요소가 있고, 그들이 어떻게 정렬되며 어떻게 상호작용하며 그들의 특성이 어떻게 시스템 reasoning을 지원하는지를 설명한다.

모든 소프트웨어 시스템은 소프트웨어 아키텍처를 갖는다.

아키텍처에 대한 설명이 없을 수는 있다.

아키텍처는 행위(behavior)를 포함한다.

아무것도 하지 않는 시스템은 존재 가치(reasoning)가 없다. 그렇다고 모든 행위를 포함해야 한다는 것은 아니다.

한 요소의 행위가 다른 요소들에게 영향을 주거나 전체로서 시스템의 수용(acceptability)에 영향을 주는 행위는 소프트웨어 아키텍처의 부분으로서 고려되어져야 하고 문서화되어야 한다.

모든 아키텍처가 좋은 아키텍처는 아니다.

어떤 아키텍처는 시스템의 행위나 품질 속성이나 생애주기와 관련된 요구사항을 만족시켜주지만, 그렇지 못한 아키텍처도 있다.

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret

티스토리 툴바