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.05.06 13:01

사람들은 이야기를 좋아한다. 이미 시나리오는 기능 요구사항을 명세하는데 널리 사용되고 있고 유용한 것으로 평가되고 있다. 이런 상황에서 품질속성 요구사항을 명세하는데 시나리오를 사용하는 것은 현명한 선택으로 보인다.

당연한 것이 당연한 것이 아닐 수 있다. 필자는 이 책을 포함한 SEI 식의 소프트웨어 아키텍처의 가장 위대한 성과는 품질속성 시나리오라고 평가한다.

 

저자들은 품질속성에 대한 일반화된 시나리오를 템플릿 형태로 제시하고, 이를 general quality attribute scenario라고 부른다.

시나리오는 source of stimulus, stimulus, environment, artifact, response, response measure와 같은 6개의 부분으로 이루어진다.

자극(stimulus)은 시스템 밖의 무엇인가에 의해 생긴다. 자극을 일으키는 그 무엇인가를 자극의 출처(source of stimulus)라고 한다. 시스템이 반응할 필요가 없는 것은 자극이 아니다. 시스템이 반응해야 하는 시스템 밖에서 일어난 일(event)을 자극이라고 한다.

시스템은 아무 때나 외부 자극에 반응하지 않고, 특정한 조건에서만 반응할 수도 있다. 시스템이 수행 중에 처하는 특정한 조건을 시스템이 어떤 환경에 처했을 때인가로 표현하고, 이를 환경(environment)이라고 한다.

시스템은 다양한 구성요소들로 이루어지는데, 특정한 자극에는 일부 시스템 구성요소들만 반응해야 할 때도 있다. 자극에 반영하는 시스템 구성요소를 artifact라고 한다.

자극에 대응해야 하는 시스템 구성요소들이 어떻게 대응해야 하는가를 대응(response)라고 한다.

어떻게 대응해야하는가는 측정가능하고 시험가능해야 함으로 구체적인 기준을 명시해야 한다. 이것을 대응기준(response measure)라고 한다.

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

품질속성은 다양한 방법으로 분류될 수 있을 것이다. 유용한 분류법의 하나는 시스템의 런타임 속성인가 개발 속성인가로 구분하는 것이다.

복잡한 시스템에서는 하나의 품질속성이 고립되어 그 자체만으로 달성되지 않는다. 서로 다른 품질속성들이 서로에게 긍정적이거나 부정적인 영향을 주고 받는다.

아키텍트는 전체 시스템의 목적을 달성하는데 최적화 되도록 품질속성들의 정도를 조정해야 한다. 품질속성은 다양한 이해관계자들에 의해 요구되기 때문에 이를 조정하기 위해서는 먼저 이해관계자들간의 품질속성에 대한 이해가 요구된다.

저자들은 먼저 우리가 품질속성을 어떻게 명세하고, 특별한 품질속성을 달성하도록 하는 아키텍처 결정이 무엇이고 어떤 질문을 함으로 올바른 아키텍처 결정을 내릴 수 있는지를 알려주고 싶어한다.

Our purpose here is to provide the context for discussing each quality attribute. In particular, we focus
on how quality attributes can be specified, what architectural decisions will enable the achievement of particular quality attributes, and what questions about quality attributes will enable the architect to make the correct design decisions.

이후의 절들에서는 이것들을 차례대로 다룬다.

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

이미 앞에서도 이야기 했듯이, 저자들은 기능이 아키텍처를 결정하는데 별 상관이 없는 것으로 이야기하고 있다.

Functionality has the strangest relationship to architecture. First of all, functionality does not determine architecture.

필자는 구조를 기능구조와 비기능구조로 나누어야 하고, 기능구조도 아키텍처에 포함해야 하며기능구조는 도메인구조를 반영해야 한다고 강하게 주장한다.

'도메인구조를 반영해서 기능구조를 만든다'는 말에는 '도메인구조를 이해하고 이를 그대로 반영한다'는 의미가 강해게 암시되는 것 같다. 이 의미를 좀 더 확장하면, 의사결정할 일이 없다는 의미도 될 수 있을 것 같고, 이를 더 확장하면 도메인 구조를 설계하는 것이 아니라 제약사항으로 받아들여진다는 의미가 될 수도 있을 것 같다.

하지만, 현실적으로 도메인에는 소프트웨어 시스템 개발에 사용할 도메인구조가 명시적으로 제시되지 않는다. 도메인구조는 특정한 방법론이나 접근 방법에 의해 논리구조가 결정된다. 논리구조는 얼마나 기술적으로 잘 구현할 것인지가 배제된 것으로 철저하게 기능에 의해 결정된다. 도메인의 변화가 발생했을 때 그 변화를 유의미하게 반영하기 위해서는 도메인구조를 시스템구조로 반영해야 한다. 이 구조가 잘 못 결정되면 수정용이성과 같은 품질속성에도 큰 영향을 미치게 되는 것이다.

소프트웨어 시스템은 도메인에 영향에서 절대 자유로울 수 없기 때문에 도메인구조에 해당하는 기능구조에 큰 영향을 받는다. 이러한 이유로 구조설계의 많은 노력이 기능구조에 들여져야 하는 것이다. 

저자들은 마치 기능을 품질속성 중심으로 결정된 구조에 태우는 것처럼 이야기한다. 저자들의 이러한 설명은 이 책을 통해 공부하는 아키텍처들에게 도메인구조는 버려두고 품질속성에 충실한 구조 만을 만들어내는 우를 범하게 할 수 있다. 이러한 경우에 발생할 수 있는 일반적인 우가 도메인구조를 반영하지 않는 모듈구조일 것이다.

But although functionality is independent of any particular structure, functionality is achieved by assigning responsibilities to architectural elements, resulting in one of the most basic of architectural structures.
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret

티스토리 툴바