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'에 해당되는 글 12건
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
2013.04.26 13:08

이 장에서는 기술적 관점에서 소프트웨어 아키텍처의 중요성에 대해서 이야기한다. 3장은 비즈니스 관점에서 이야기 한다.

이 장의 내용은 누군가에게 소프트웨어 아키텍처링을 왜 해야 하는지를 설득하는데 사용할 수 있는 부분이다. 저자도 우리를 설득하고 있는 것이다. 물론 우리는 이미 아키텍처가 중요하다고 생각하고 이 책을 읽고 있으니 고개를 끄덕여 가면서 저자들의 설득을 받아들여 가면서 읽으면 된다.

 

중요한 이유에 대한 세부 내용은 필자가 본문의 내용을 참조하여 조금 각색하였다.

소프트웨어 아키텍처는 왜 중요한가?

1. An architecture will inhibit or enable a system’s driving quality attributes.

소프트웨어 아키텍처가 어떠하냐에 따라 시스템에 요구되는 품질속성이 가능하기도 하고 그렇지 못하기도 한다.

품질속성은 시스템 수준에서 중요하게 다루어져야 하는 비기능요구이다. 요구사항이라는 것이다. 요구사항을 만족하지 못하는 시스템은 실패한 시스템이다. 품질속성은 시스템 개발의 성공 기준이 되는 것이니 매우 중요하게 다루어져야 한다.

소프트웨어 아키텍처가 등장하기 이전의 시대는 기능이 중심인 시대이다. 물론 지금도 기능이 중요하다. 기본이다. 하지만 모두가 기본을 갖추고 있는 시대가 되면 기본 말고 또 다른 것이 있어야 한다. 그것이 비기능이고, 비기능 중에 대부분을 차지하는 것이 품질속성이다.

2. The decisions made in an architecture allow you to reason about and manage change as the system evolves.

지금은 변화의 시대이다. 시스템 개발을 마치고 릴리즈해서 운영되는 시점부터 곧바로 예상치 못한 변화에 직면하게 된다. 시스템은 변화에 대응하여 쉽게 바꿀 수 있어야 살아남는다.

대상을 바꾸려면 먼저 그 대상을 이해해야 한다. 대상에 대한 이해가 쉬우면 쉬울 수록 변경도 그 만큼 쉬워진다. 변경이 얼마나 쉬운가를 나타내는 품질속성이 수정용이성(modifiability)이다. 품질속성은 아키텍처로 다루어진다. 변화의 시대에 아키텍처가 더 중요해지는 이유이다.

3. The analysis of an architecture enables early prediction of a system’s qualities.

계획은 검증될 수 있어야 한다. 특히 잘못되었을 때 위험이 큰 것일 수록 그렇다. 아키텍처는 시스템 수준에서의 중요한 의사결정임으로 이것이 잘못되었을 때 파급효과는 대단히 클 것이다. 따라서 시스템 개발 초기에 검증이 가능해야 한다. 다행인 것은 아키텍처 평가 방법이 있고, 그 수준도 상당히 높은 수준이라는 것이다.

평가를 하려면 평가대상이 있어야 한다. 시스템은 아직 만들어지지 않았으니 평가대상이 될 수 없다. 평가 시점까지의 시스템에 대한 이해가 평가대상이 될 수 밖에 없다. 시스템의 다양한 이해관계자들이 이해해야 하니 그 수준에서 추상화되어야 한다. 추상화된 결과는 모델로 작성된다. 모델을 가지고 평가한다. 아키텍처 모델이 만들어지고 그것을 기준으로 평가되어야 한다. 검증된 모델은 설계로 반영되어 구현된다.

4. A documented architecture enhances communication among stakeholders.

서로 다른 이해관계자들이 시스템에 대한 공통의 이해 없이, 자신들의 이해관계만을 시스템에 반영하려고 한다면 시스템 개발은 산으로 갈 것이다. 문서화된 아키텍처가 있다면 그들은 아키텍처 문서를 통해 시스템에 대한 공통적 이해를 갖고, 공통의 언어를 사용해서 커뮤니케이션할 수 있게 된다.

5. The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design decisions.

소프트웨어 아키텍처는 시스템 개발 초기에 내려지는 설계결정이다. 초기에 내려지는 설계결정은 그 뒤에 내려지는 설계결정들을 제약한다. 따라서 초기 설계결정에 변경이 생기면 그 파급효과는 대단히 크다.

소프트웨어 아키텍처는 시스템 개발 초기에 내려져야 하는 중요한 설계결정들을 주의 깊고 체계적으로 다루도록 한다.

6. An architecture defines a set of constraints on subsequent implementation.

상위 수준의 결정이 하위 수준의 결정을 제약한다.

7. The architecture dictates the structure of an organization, or vice versa.

아키텍처는 시스템을 가장 넓은 수준에서의 분할로, 조직구조를 만들때 사용하는 작업분할구조를 반영한다. 따라서 프로젝트 관리자는 개발조직을 구성할 때 아키텍트와 긴밀히 협력해야 한다.

8. An architecture can provide the basis for evolutionary prototyping.

아키텍처가 정의되면, 아키텍처는 뼈대가 되는 시스템으로 분석되고 프로토타입될 수 있다.

9. An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule.

10. An architecture can be created as a transferable, reusable model that forms the heart of a product line.

아키텍처 재사용은 개발주기 초기에 재사용을 적용하자는 것이다. 다양히 컴포넌트나 코드 재사용보다 큰 규모의 재사용이 될 것이다. 제품 군이 있는 경우 아키텍처는 다수의 시스템에서 재사용될 수 있다. 

11. Architecture-based development focuses attention on the assembly of components, rather than simply on their creation.

아키텍처 기반 개발은 컴포넌트를 조립하는데 중점을 둔다. 조립하려면 조립도가 필요하다. 조립도에 해당하는 것이 컴포넌트 아키텍처이다.

12. By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity.

설계 대안이 많다는 것이 꼭 좋은 것은 아니다. 대안이 많다는 것은 그 만큼 복잡하다는 것이다. 대안들이 모두 좋은 것이 아니기 때문에 나쁜 대안을 선택할 수도 있다. 가능하면 복잡하지 않은 수준에서 좋은 대안을 선택할 수 있도록 제약하는 것이 좋다. 아키텍처 패턴들은 이를 위해서 등장한다.

13. An architecture can be the foundation for training a new team member.

새로운 팀 멤버를 훈련하는 기초로 사용될 수 있다. 필자는 개인적으로 이 부분을 가장 중요한 아키텍처의 유용성의 하나로 든다.

 

변경은 세 가지 범주로 구분된다.

단일 요소를 수정하면 되는 변경을 지역적 변경(local change)이라 하고, 다수의 요소를 수정해야 하는 변경을 비지역적 변경(nonlocal change)이라고 한다. 지역적 비지역적 변경은 시스템 수준에서의 의사결정을 바꾸지는 않는다. 시스템 수준에서의 의사결정을 바꾸는 변경을 아키텍처적 변경이라고 한다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.04.18 10:49
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.04.18 10:44

우리는 무엇을 알아야 하는가?

소프트웨어 아키텍처란?

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. A structure is a set of elements and the relations among them.

필자는 수 많은 정의들 중, 이 정의를 가장 뛰어난 것으로 여긴다. 구조라는 단어를 일관적으로 사용하여 이후의 내용들을 진행해 나가는 것은 정말 멋지고 대단하다.

뷰란? 구조와 비교해서

A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. A view is a representation of one or more structures.

관점(view)란 것은 바라보는 주체가 있어야 한다. 이해관계자들이 아키텍처 구조를 바라보는 주체다. 이들이 아키텍처 구조를 읽고 작성한다. 읽고 작성한다는 것은 이해관계자들이 이해할 수 있는 형태로 표현한다는 것이다.

구조는 세 가지 범주로 나뉜다. 어떻게?

Module structures show how a system is to be structured as a set of code or data units that have to be constructed or procured.
Component-and-connector structures show how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors).
Allocation structures show how the system will relate to nonsoftware structures in its environment (such as CPUs, file systems, networks, development teams, etc.).

왜 구조인가?

Structures represent the primary engineering leverage points of an architecture. Each structure brings with it the power to manipulate one or more quality attributes. They represent a powerful approach for creating the architecture (and later, for analyzing it and explaining it to its stakeholders).

더 좋은 뭔가를 만들기 위해서는 더 좋은 결정을 해야 한다. 더 좋은 결정을 하기 위해서는 더 좋은 논의가 있어야 한다. 구체적으로 표현될 수 있는 대상을 기반으로 한다면 더 좋은 논의가 될 것이다.

구조는 요소들과 그 요소들 사이의 관계들의 집합이다. 요소들과 관계들을 구체적으로 표현할 수 있다면 구조는 논의를 위한 구체적인 기반으로 사용될 수 있다.  

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

좋은 것으로 타고난 아키텍처는 없다. 좋은 것으로 평가된 아키텍처가 있을 뿐이다. 특별한 목적에 적합한 것으로 평가된 것이 좋은 아키텍처인 것이다.

그렇다고 아키텍처를 설계할 때 따라야할 규칙이 없는 것은 아니다. 이들 규칙을 적용하는데 실패했다고 해서 자동적으로 아키텍처가 결함을 갖는 다는 것을 의미하지는 않지만, 적어도 좀 더 주의깊게 살펴보라는 경고 신호로서 받아들여야 한다.

 

우리는 다음과 같은 프로세스를 추천한다.

1. 아키텍처는 인정된 기술 리더와 함께하는 한 아키텍처 또는 아키텍처들의 조그만 그룹에서 만들어낸 것이어야 한다. 이렇게 함으로 아키텍트와 개발 팀 사이에 강력한 연결을 가능하게 한다.

2. 아키텍트나 아키텍처 팀은 잘 명세되고, 우선순위가 작성된 품질 속성 요구사항에 기반해야 한다. 이렇게 함으로 개발 지연과 같은 상황에 트레이드 오프(tradeoffs)로 대응할 수 있게 한다.

3. 아키텍처는 뷰를 사용해서 문서화해야 한다. 뷰들은 프로젝트 생애주기 동안의 중요한 대부분의 이해관계자들의 관심사(concerns)를 다루어야 한다. 최소한의 문서로 시작해서 점점 더 정교하게 작성한다. 관심사는 일반적으로 시스템의 구축, 분석, 유지보수, 새로운 이해관계자에 대한 교육과 같은 것과 관련된다.

4. 아키텍처는 시스템의 중요한 품질속성을 만족시킬 수 있는가로 평가해야 한다.

5. 아키텍처는 점진적으로 구현해야 한다. 이렇게 하는 한 가지 방법은 뼈대가 되는 시스템을 만드는 것이다. 커뮤니케이션 경로는 실행되지만 최소의 기능을 갖고 시작하는 것이다. 뼈대가 되는 시스템은 점진적으로 자라게된다. 이때 리팩토링은 필수적이다.

위의 내용을 명령형으로 바꾸어 봤다.

아키텍처 팀과 개발 팀 사이에 강력한 연결을 만들어라.  트레이드 오프로 대응할 수 있도록 품질 속성 요구사항에 우선순위를 작성하고 그것에 기반으로 작업하라. 뷰를 사용해서 문서화하라. 시스템의 중요한 품질속성을 기준으로 평가하라. 뼈대가 되는 시스템을 만들고 점진적으로 구현하라.  

우리는 다음과 같은 구조적 규칙들을 제시한다.

1. 아키텍처는 잘 정의된 모듈들이 특징이 되어야 한다. 모듈의 기능적 책임이 정보 은닉과 관심사 분리의 원리에 의해 할당되어져야 한다.

정보 은닉된 모듈들은 캡슐화해야 한다. 캡슐화를 통해 변화의 파급효과를 차단할 수 있다.

각각의 모듈은 잘 정의된 인터페이스를 가져야 한다. 이들 인터페이스는 개발팀들이 관련된 서로의 팀에 독립적이도록 해야 한다.

2. 여러분의 요구사항이 전례가 없는 것이 아니라면, 여러분의 품질 속성은 잘 알려진 아키텍처 패턴들이나 전술들을 사용해서 달성될 수 있도록 해야 한다.

3. 아키텍처는 상업용 제품이나 도구의 특별한 버전에 의존해서는 안된다.

4. 데이터를 생성하는 모듈은 데이터를 소비하는 모듈과 분리해야 한다.

5. 모듈과 컴포넌트 사이에 일대일 대응을 기대하지 마라.

6. 프로세스를 특별한 프로세서에 쉽게 할당하도록 작성해야 한다. 심지어 런타임에서도.

7. 컴포넌트가 상호작용하는 방법이 적은 것이 특징이 되어야 한다. 시스템은 전체적으로 같은 방법으로 같은 일을 할 수 있도록 해야 한다. 이렇게 함으로 이해도를 높이고 개발 시간을 줄이고 신뢰성을 증대하고 수정가능성을향상 시킨다.

8, 아키텍처는 구체적이고 작은 자원 경쟁 영역들(resource contention areas)을 포함해야 한다. 경쟁에 대한 해결책이 분명히 명시되고, 관리되어야 한다.

예를 들어, 만약 관심사 영역이 네트워크 이용이라면, 아키텍트는 네트워크 트래픽을 최소화하도록 강제하는 개발 팀 지침을 만들어야 한다.

위의 내용을 명령형으로 바꾸어 봤다.

기능적 책임이 정보 은닉과 관심사 분리 원리에 의해 할당되도록 모듈화하라. 모듈은 캡슐화하라. 모듈은 잘 정의된 인터페이스를 갖도록 해라. 아키텍처 패턴이나 전술을 사용하라. 상업용 제품이나 도구의 특별한 버전에 의존하지 않도록 해라. 데이터를 생성하는 모듈과 소비하는 모듈을 분리하라. 모듈과 컴포넌트 사이의 일대일 대응을 기대하지 말라. 프로세스는 프로세서에 쉽게 할당하도록 작성하라. 컴포넌트들 사이의 상호작용에 일관성이 있게 하라. 자원 경쟁이 최소한으로 일어나도록 하라.




 

 

 

 

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.04.17 17:51
어떤 경우에는 특별한 문제를 해결하기 위해 다수의 아키텍처 요소들이 컴포지션(compositions)되기도 한다. 이 컴포지션된 것들이 시간이 지남에 따라 많은 다른 도메인을 넘어 유용한 것으로 알려지면 문서화되고 확산되어진다. 이러한 아키텍처 요소들의 컴포지션을 아키텍처 패턴이라 부른다. 아키텍처 패턴은 시스템이 직면한 몇몇 문제를 해결하기 위한 패키지된 전략을 제공한다.

 

아키텍처 패턴은 어떤 문제를 해결하기 위해 사용되어지는 요소들의 유형과 그들의 상호작용 방식을 기술한다.

패턴들 중의 많은 수가 그들이 사용하는 아키텍처 요소의 유형에 따라 분류된다. 예를 들어, 요소가 모듈인 경우에는 layered 패턴이 있고, 컴포넌트-커넥터인 경우에는 shared-data (또는 repository), client-server이 있고, 할당인 경우에는 multi-tier, competence center, platform 패턴이 있다.

패턴에 대한 자세한 내용은 13장에서 다루어진다.  

Documenting Software Architecture 2nd에서는 많은 수의 아키텍처 패턴들을 상세하게 다루고 있다. 이 책에 대한 세미나 내용은 다음 링크를 참조하면 된다.  http://umlcert.tistory.com/tag/DSA세미나

 

 

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

인간이 한 번에 다룰 수 있는 복잡성은 5개에서 9개 사이라고 한다. 오늘날 시스템의 대부분은 항상 우리의 한계를 넘어서는 복잡성을 가지고 있다. 우리는 우리의 한계를 잘 이해하고 한 번에 다룰 수 있는 수를 줄여야 한다.

어떤 한 아키텍처에 대해 의미있게 커뮤니케이션하기 위해서, 우리는 한 순간에 다루어지는 구조나 구조들을 분명히해야 한다.

소프트웨어 시스템에는 다양한 이해관계자들이 존재하고 그들은 자신의 이해관계에 따라 소프트웨어 시스템을 바라보게 된다. 이해관계자들에 의해 읽혀지고 작성되는 응집된 아키텍처 요소들의 집합을 뷰(view)로 나타낸다.

우리는 이전 글(http://umlcert.tistory.com/664)에서 구조가 관계에 의해 함께 묶여진 요소들의 집합이라고 했다. 구조 자체가 요소들의 집합이라는 것이다. 그런데 뷰도 요소들의 집합이란다. 뭐지?

저자들은 다음과 같이 구조와 뷰의 관계를 정리하고 있다. 

A view is a representation of a structure.

구조를 표현하기 위해 뷰를 사용한다는 것이다.

아키텍트는 구조를 설계하고 뷰로 문서화한다.

구조와 뷰에 대한 정의는 저자들의 오랜 고심의 흔적이 보인다. 마지막 문장은 정말 멋지다.

 

구조는 통찰력(insight)을 제공한다. 

뭔가를 논하려면 논할 수 있는 뭔가가 제공되어야 한다. 이해관계자들은 소프트웨어 시스템에 내려지는 중요한 의사결정들에 대해서 논하고 싶은 것이다. 소프트웨어 아키텍처는 이해관계자들에게 구체적인 구조를 제공함으로 논쟁의 근거와 통찰력을 제공한다.

소프트웨어 시스템에 있어 품질 속성은 중요한 논쟁거리이기 때문에 소프트웨어 아키텍처에 있어 중요한 대상이 된다.

 

구조의 종류

아키텍처 구조는 어떤 아키텍처 결정이냐에 따라 크게 세 개의 범주(모듈, 컴포넌트-커넥터, 할당)로 나누어진다.

1. 모듈 구조는 어떻게 시스템이 코드 집합이나 데이터 유닛들로 구조화 되는지에 대한 의사결정들을 구체화한다(embody). 모듈 구조의 구성요소는 구현 단위인 모듈이다. 모듈 구조는 시스템에 대한 정적 표현이다. 클래스는 객체지향 개발에 있어서 대표적인 구현 단위이다.

모듈 구조는 다음과 같은 질문에 답한다.

- What is the primary functional responsibility assigned to each module?
- What other software elements is a module allowed to use?
- What other software does it actually use and depend on?
- What modules are related to other modules by generalization or specialization(i.e., inheritance) relationships?

모듈 구조는 시스템에 대한 정적 표현으로 기능적 책임이 어떻게 할당 되었는지를 나타내기 때문에 시스템의 기능적 책임이 바뀌게 될 때 직접적인 정보를 제공한다. 이러한 이유로 모듈 뷰는 시스템의 수정가능성(modifiablility)에 대한 근거를 제공할 때 사용될 수 있다.   

2. 컴포넌트-커넥터 구조는 어떻게 시스템이 런타임 행위와 상호작용으로 구조화 되지에 대한 의사결정을 구체화한다. 컴포넌트는 런타임 행위에, 커넥터는 상호작용에 해당하는 요소이다. 컴포넌트-커넥터 구조는 시스템에 대한 동적 표현이다.

컴포넌트-커넥터 구조는 다음과 같은 질문에 답한다.

- What are the major executing components and how do they interact at runtime?
- What are the major shared data stores?
- Which parts of the system are replicated?
- How does data progress through the system?
- What parts of the system can run in parallel?
- Can the system’s structure change as it executes and, if so, how?

컴포넌트-커넥터 뷰는 런타임 시에 대한 것으로 시스템의 런타임 특성들에 대한 근거를 제공할 때 사용될 수 있다.

3. 할당 구조는 어떻게 시스템이 소프트웨어 구조가 아닌 구조(CPUs, file systems, networks, development teams과 같은)와 관련되는지에 대한 의사결정을 구체화한다. 이들 구조는 소프트웨어 요소와 소프트웨어가 만들어지고 실행되는 하나 이상의 외부환경의 요소들 사이의 관계를 보여준다.

할당 구조는 다음과 같은 질문에 답한다.

- What processor does each software element execute on?
- In what directories or files is each element stored during development, testing, and system building?
- What is the assignment of each software element to development teams?

위의 세 가지 범주와 아래의 유용한 구조들에 대해서는 Documenting Software Architecture 2nd에서 매우 상세하게 설명하고 있다. 이 책에 대한 세미나 내용은 다음 링크를 참조하면 된다.

 http://umlcert.tistory.com/tag/DSA세미나

 

유용한 구조들

복잡한 전체는 다수의 부분들로 분할(decomposition structure)되고, 부분들의 협력으로 자신의 책임을 실현한다. 부분들은 협력을 위해 다른 부분을 사용하거나 다른 부분에 의해 사용(use structure)된다. 

모듈이 다른 모듈과 상관 없이 독립적으로 개발되고 수행될 수 있다면 복잡성은 크게 줄어들 것이다. 이렇게 하기 위해서는 기능을 독립적으로 분리하고 이를 조합하는 메커니즘이 필요하다(service structure). 실행 시에 중요하게 고려할 부분은 병행처리와 자원의 사용이다(concurrency structure).

모듈은 개발 조직에 할당되고(work assignment), 구현된다. 모듈은 파일 형태로 구현되기 때문에 파일 구조에 매핑된다(implementation structure). 구현된 모듈은 실행을 위해 배치된다(deployment structure).  

표 1.1은 이들 구조들을 요약해 놓았다.

 

구조들 사이의 관계

어떤 구조의 요소들은 다른 구조의 요소들과 관계를 갖을 수 있다.

 

적을 수록 좋다

투자에 대한 긍정적인 리턴이 있을 때에만 구조에대해 설계하고 문서화하라.

 

어떤 구조를 선택해야 하는가?

시스템의 중요한 품질 속성을 제공하는데 최고의 역할을 하는 구조를 선택하라.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
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
2013.04.12 15:07

1부에서는 다음과 같은 질문에 답하는 것을 목적으로 한다.

소프트웨어 아키텍처 - 그게 뭔데? 그게 필요한 이유는? 어떤 컨텍스트에서 존재해?

1장은 첫 번째 질문에, 2장은 두 번째 질문에, 3장은 세 번째 질문에 답한다.

1장. What Is Software Architecture?
2장. Why Is Software Architecture Important?
3장. The Many Contexts of Software
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.04.10 13:01

저자는 우리에게 무엇을 알려주고 싶을까?

필자가 소프트웨어 아키텍처 책을 쓴다면?

먼저 소프트웨어 아키텍처가 무엇인지를 설명할 것 같다. 그리고 어떻게 하는 것인지(소프트웨어 아키텍팅)를 알려주고 싶을 것 같다. 아마도 대부분의 내용은 소프트웨어 시스템 개발과 직접적으로 관련된 부분들일 것이다. 이 책에서 말하는 기술적(technical) 컨텍스트와 프로젝트(project) 컨텍스트가 이 부분에 해당하는 것 같다.  

저자는 기술적 컨텍스트와 프로젝트 컨텍스트를 넘어서 좀 더 다양한 컨텍스트(business, professional)에서 소프트웨어 아키텍처를 다루고 싶어 한다.

1부에서는 소프트웨어 아키텍처가 무엇인지 왜 중요한지를 설명한다. 다양한 컨텍스트에서 소프트웨어 아키텍처의 역할을 개요적으로 설명한다.

2부에서 4부까지는 개별 컨텍스트 별로 다룬다. 2부에서는 기술적 컨텍스트, 3부에서는 프로젝트 컨텍스트, 4부에서는 비즈니스 컨텍스트를 다룬다. 소프트웨어 아키텍트의 역할은 조직 또는 개발 프로젝트에서 요구되는 것으로 professional 컨텍스트는 3부와 4부에 포함되어 다룰 것 같다.

5부에서는 최근 대두되는 중요한 기술들과 어떻게 아키텍처가 이들 기술과 관련되는지를 설명한다.

 

소프트웨어 개발자인 필자는 저자가 다양한 컨텍스트를 가지고 보든 말든 1부, 2부, 3부에 관심이 있다. 특히 2부에 관심이 많다. 대부분 세미나 참여자들도 그렇다. 이런 이유로 세미나의 비중도 2부가 높을 수 밖에 없다.

 

이 시점에서 각 부와 장의 제목 정도를 읽고 가는 것은 가이드 역할로 충분할 것 같다. 

1부. Introduction

1장. What Is Software Architecture?
2장. Why Is Software Architecture Important?
3장. The Many Contexts of Software

2부. Quality Attributes

4장. Understanding Quality Attributes
5장. Availability
6장. Interoperability
7장. Modifiability
8장. Performance
9장. Security
10장. Testability
11장. Usability
12장. Other Quality Attributes
13장. Architectural Tactics and Patterns
14장. Quality Attribute Modeling and Analysis

3부. Architecture in the Life Cycle

15장. Architecture in Agile Projects
16장. Architecture and Requirements
17장. Designing an Architecture
18장. Documenting Software Architectures
19장. Architecture, Implementation, and Testing
20장. Architecture Reconstruction and Conformance
21장. Architecture Evaluation
22장. Management and Governance

4부. Architecture and Business

23장. Economic Analysis of Architectures
24장. Architecture Competence
25장. Architecture and Software Product Lines

5부. The Brave New World

26장. Architecture in the Cloud
27장. Architectures for the Edge
28장. Epilogue

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
prev"" #1 #2 next

티스토리 툴바