BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
2013.04.30 12:45

이번 장에서는 technical, project life cycle, business, professional 컨텍스트에서 소프트웨어 아키텍처를 살펴본다.

 

기술(technical) 컨텍스트에서의 아키텍처

어떤 아키텍처는 품질 속성을 달성하게 하기도 하고 그렇지 않게 하기도 한다.

기술 컨텍스트는 소프트웨어 시스템 구현에 대해 관심을 갖는 컨텍스트이다.

소프트웨어 시스템은 요구사항을 만족하도록 개발되어야 한다. 무엇을 어떻게 할 것인가에 대한 것으로 '무엇을 할 것인가'에 대한 것이 기능요구이고 '어떻게 할 것인가'에 대한 것이 비기능요구이다.

어떻게 할 것인가는 다양한 대안이 있을 수 있다. 그래서 '얼마나 잘'이 등장한다.

비기능요구에는 제약사항과 품질속성이 있다. 제약사항은 반드시 지켜야 하는 것이로 차이가 나는 것이 아니다. 품질이라는 것은 정도가 있는 것으로 '얼마나 잘'에 해당한다.

기능요구에 의해 기능구조가 등장하고 비기능요구에 의해 비기능구조가 등장한다. 기능요구는 도메인으로 부터 나온 것으로 도메인구조를 반영하는 것이 가장 좋다.

도메인으로 부터 기능구조가 나오니 시스템의 차이는 비기능구조에서 나온다. 얼마나 잘하느냐의 차이는 비기능구조에서 나온다는 것이다.

비기능요구 중에서 차이를 만드는 것은 품질속성임으로 품질속성은 비기능구조를 결정하는 키가 되는 것이다.

저자들은 기능성에 대해서 다음과 같이 언급한다.

Why is functionality missing from the preceding list? It is missing because the architecture mainly provides containers into which the architect places functionality. Functionality is not so much a driver for the architecture as it is a consequence of it.

여기에서 기능성은 비기능요구로 분류되는 기능성으로 범위를 좁여해야 맞는 이야기가 된다. 사용 시나리오를 갖는 기능요구는 위에서 필자가 설명한 것과 같이 기능구조를 만든다.

필자는 오늘날 소프트웨어 개발 환경을 변화의 시대라고 생각하기 때문에 품질속성 중에서 변경용이성을 중요한 속성으로 손 꼽는다. 이러한 이유로 변경에 쉽게 대응할 수 있는 아키텍처를 좋은 아키텍처로 꼽는다.

도메인은 소프트웨어 시스템이 존재하는 이유가 되기 때문에 도메인의 변화는 소프트웨어가 받아들여야 하는 중요한 변화가 된다. 도메인구조(기능구조)가 시스템 아키텍처로 반영되어야 변화에 대응할 수 있다는 것이다. 좋은 아키텍처는 기능구조(도메인구조)가 코어가 되고 비기능구조가 이를 뒷받침해야 한다. 필자는 이러한 이유로 기능구조에 비기능구조로 색깔(애스펙트)을 입힌다라고 표현하기도 한다.

기술환경은 아키텍처에 영향을 준다.

 

프로젝트 생애주기(project life cycle) 컨텍스트에서의 아키텍처

어떤 개발 프로세스나 생애주기모델이든간에 소프트웨어 아키텍처를 만들때는 다음과 같은 액티비티들을 포함해야 한다.

1. Making a business case for the system
2. Understanding the architecturally significant requirements
3. Creating or selecting the architecture
4. Documenting and communicating the architecture
5. Analyzing or evaluating the architecture
6. Implementing and testing the system based on the architecture
7. Ensuring that the implementation conforms to the architecture

 

비즈니스 컨텍스트에서의 아키텍처

아키텍처나 시스템은 장난삼아 만들지 않는다. 아키텍처는 비즈니스 목표를 위해 만들어진다.

어떤 비즈니스 목표는 품질 속성에 대한 요구사항을 끌어내기도 하고 어떤 것은 아키텍처 결정을 직접적으로 끌어내기도 하며 어떤 것은 비아키텍처적인 해결책을 끌어내기도 한다.

개발조직은 아키텍처에 영향을 주는 많은 비즈니스 목표에 기여한다.

 

전문성(직업, professional) 컨텍스트에서의 아키텍처

전문성 컨텍스트에서는 아키텍트가 어떤 책임(duties), 기술(skills), 지식(knowledge)를 가져야 하는지에 관심을 갖는다.

 

이해관계자(stateholders)

소프트웨어 시스템에는 시스템 성공에 대해 관심을 갖는 많은 이해관계자들이 존재한다. 표 3.1은 다양한 이해관계자들과 그들의 관심사를 열거하고 있다.

 

아키텍처에 영향을 주는 것과 받는 것은 무엇인가?

아키텍트는 다양한 컨텍스트(비즈니스, 기술, 프로젝트)의 이해관계자들의 이해관계와 전문성 컨텍스트에서 요구되는 것들에 의해 영향을 받아 아키텍처를 만든다. 왜 다양한 컨텍스트가 아키텍처에 영향을 미쳤겠는가? 당연히 아키텍처에 의해 영향을 받기 때문이 아니겠는가?

 

아키텍처는 아키텍트의 경험에 한계를 갖기 때문에 성공적인 아키텍처 프랙티스들의 예들이 필요하다. 아키텍처는 시스템 초기에 내려지는 중요한 설계 결정이기 때문에 초기에 평가되어야 하고, 너무 늦지 않게 설계 결정의 결함을 발견하고 바로 잡기 위해서는 아키텍처 중심의 점진적 개발이 되어야 한다.

 

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

티스토리 툴바