Software Architecture: 어떻게 설계 할 것인가?

 

개요

여기서 설명하려는내용은 [1]에서 설명하는 Architecture 설계 방법이다. Software System의 요구사항(Requirement)를 만족하기 위해서 이를 분류하고, 이중에서 Quality Attribute, 특히 Architecture에 중요한 요구 사항(Architecture Significant Requirement, ASR)를 만족시키는 구조를 설계하는 방법을 설명한다. 

Architecture와 요구 사항(Requirement)

Software System의 요구 사항(Requirement)은 텍스트 요구 사항(Textual Requirement), 모형(Mockup), 기존 시스템(Existing System), 유즈 케이스(Use Case), 유저 스토리(User Story) 등 다양한 형태로 제공된다. 요구 사항이 어디서 왔든 상관없이 모두 다음과 같이 구분된다. [1]

1. 기능 요구 사항(Functional Requirement FR): 이러한 요구 사항은 시스템이 수행해야하는 작업과 런타임 자극에 어떻게 반응하거나 반응해야 하는지를 설명합니다.

2. 품질 속성 요구 사항(Quality Attribute Requirement, QA): 이러한 요구 사항은 기능 요구 사항(FR) 또는 전체 제품에 대한 자격 확인(Qualification)이다. 기능 요구 사항의 자격은 기능이 얼마나 빨리 수행되어야하는지, 오류 입력에 대해 얼마나 탄력적이어야하는지 등의 항목입니다. 전체 제품의 자격은 제품을 배포하는 데 걸리는 시간 또는 운영 비용의 제한과 같은 항목입니다.

3. 제약 조건(Constraint): 이는 자유도가 0 인 설계 결정이다. 즉, 이미 결정이 나 있는 디자인 결정이다. 예를 들어, 특정 프로그래밍 언어를 사용하거나 특정 기존 모듈을 재사용하거나 시스템 서비스가 기반으로 해야 하는 경영층의 지시를 포함한다. 이러한 선택은 아마도 건축가의 관점에서 볼 수 있지만, 새로운 언어로 직원을 양성 할 수 없거나, 소프트웨어 공급 업체와 비즈니스 계약을 맺었거나, 서비스 상호 운용성이라는 비즈니스 목표를 추진할 수 밖에 없는 등의 광범위한 요인으로 인해 이러한 설계 결과를 강제하게 된다.

 

[2]에서는 이러한 Requirement들을 Architectural Driver로 이야기 하고 있다. 그리고 이런 것들이 결국 Architecture에 영향을 미친다고 볼 수 있다.

 

 

 

 

이러한 종류의 요구 사항 각각에 대한 아키텍처의 "대응"은 무엇인가?

1. 기능 요구 사항(Functional Requirement)은 설계 전반에 걸쳐 적절한 책임(Responsibility)을 순차적으로 부여함으로써 만족된다. 즉, 아키텍처 요소에 책임을 할당하는 것은 아키텍처 설계의 기본적인 결정이다.

2. 품질 속성(Quality Attribute) 요구 사항은 아키텍처에 설계된 다양한 구조와 해당 구조를 채우는 요소의 동작 및 상호 작용에 의해 충족됩니다. 

3. 설계 결정(Design Decision)을 수락하고 영향을받는 다른 설계 결정(Design Decision)과 조화를 이루면 제약 조건(Constraint)이 충족됩니다.

 

Architectural Significant Requirement

어떤 요구 사항은 다른 것보다 Architecture에 훨씬 더 큰 영향을 미친다. 이러한 구조적 중요 요구 사항 (Architecturally Significant Requirement, ASR)은 이와 같이 아키텍처에 큰 영향을 주는 요구 사항이다. ASR을 모른다면 성공적인 아키텍처를 설계 할 수는 없다. ASR은 아키텍처가 시스템에 제공해야하는 품질 속성(Quality Attribute) 요구 사항의 형태를 취한다. Architecture에 사용할 패턴(Architecture Pattern, Architecture Style) 또는 전술(Tactics)을 선택할 때마다 품질 속성(Quality Attribute) 요구 사항을 충족해야하므로 Architecture가 변경됩니다. 그러므로 QA 요구 사항이 더 어렵고 중요할수록 아키텍처에 큰 영향을 미쳐 ASR이 될 가능성이 커진다. 다음은 ASR을 추출하는 방법들이다[2]. 필요한 경우, 이후에 상세히 살펴 보도록 한다.

 

• Requirement 문서에서 ASR을 추출
• Stakeholder 인터뷰를 통해 ASR을 추출
• 비즈니스 목표(Business Goals) 이해를 통한 ASR 수집
• Utility Tree를 통한 ASR의 추출
• 여러 방법의 연결

 

Architecture와 Quality Attribute 

선택된 ASR인 Quality Attribute들과 다른 요구 사항들을 기반으로 Architecture 설계하는 방법을 [2]의 17장에서 설명한다. 이는 아키텍처를 설계하기 위한 전략(Design Strategy)와 이러한 아이디어를 하나로 패키징하는 방법, 즉 속성 중심 설계(Attribute Driven Design, ADD)을 설명한다.

 

 

디자인 전략은 아래와 같은 절차를 포함한다

• Decomposition: 충분히 시스템 내의 모듈을 분해 해야 한다. 
• ASR에 대한 설계: 도리어 다른 Requirement들에 영향이 없는지 확인해야 한다.
• 가설(Hypothesis) 생성과 테스트를 통한 확인

 

 

속성 중심 설계, ADD는 5 단계 방법이다.

1. 디자인 할 시스템 요소를 선택한다.
2. 선택된 요소에 대한 ASR을 식별한다.
3. 선택한 요소에 대한 설계 솔루션을 생성한다. : 여기서 여러 솔루션들에 대해서 비교가 필요하다.
4. 나머지 요구 사항을 재고하고 다음 반복을위한 입력을 선택한다.
5. 모든 ASR이 충족 될 때까지 1-4 단계를 반복한다.

 

위의 방법, 특히 ADD는 실재 예를 보면서 이해하는 것이 필요하다. 특히, 위의 절차는 지속적으로 반복하여 요구 되는 요구 사항들과 Quality Attribute들을 만족할 때까지 반복하여 최종 Architecture가 설계 되도록 해야 한다.

 

마무리 하며...

구조 설계에는 명확한 답이 있어 보이지는 않는다. 하지만, 새로운 방법들이 제안되고 있다. 이런 것들은 추후 검토하고 추가하기로 한다. 예를 들자면, 

ADD 3.0 및 예제 문서들[3]이 그 예이다. 위에 예들을 이해하기 위해서는 예를 많이 살펴 보는 것이 좋고, 그 후에 실재로 설계를 진행해 보는 것이 좋다.

References

[1] Len Bass, et. al., "Software Architecture in Practice, Third Edition," Addison Wisely, 2012

[2] Mohamad Kassab, "Software Architectural Patterns in Practice: An Empirical Study," https://slideplayer.com/slide/13920131/

[3] Rick Kazman, et. al., "Designing Software Architectures: A Practical Approach," Addison Wisely, May 2016