오래된 SW 엔지니어의 평생 공부

개요

여기서는 SEI의 Architecture 설계 [1]에서 설명하는 Quality Attribute에 대해서 설명한다. 4.4절에서 설명하는 바와 같이 Quality Attribute가 Quality Scenario로 구체화 된다. 이를 그림으로 표현하면 아래와 같다. ISO 25010의 경우는 이름이나 분류가 다른 경우도 있으니, 참고 바란다.

이 후에는 [1]에서 설명하는 Quality Attribute들 중요서 주요한 몇가지를 Quality Scenario 형태로 설명한다.

성능(Performance)

성능은 Software System이 가지는 중요한 Quality 중의 하나이다. 이는 [1]의 8장에서 설명한다. 아래는 설명하는 Quality Attribute의 상세히 설명하는 Quality Scenario가 가져야 하는 내용의 일반적인 셜명이다.

변경 용이성 (Modifiability)

변경 용이성은 개발 측면에서 추가적인 요구 사항에 대해서 변경하기 효율성을 의미한다. 

가용성(Availability)

기타 Quality Attributes

상호 운영성(Interoperability), 보안성(Security), 시험 용이성(Testability), 사용성(Usability) 뿐만 아니라, 다른 속성도 많다. 이는 설계하려는 Software System의 Domain에 따라 달라지기도 한다. 이야기 한데로, System을 분석하다 보면, 위의 품질 뿐 아니라, 다른 품질 속성이 도입되기도 한다. 여기서는 상세히 다루지 않는다. 필요하면, [1] 혹은 [2]를 참조하기 바란다.

마무리 하며

여기서는 SEI에서 이야기하는 주요 Quality Attribute[1]들에대해서 살펴 보았다. 성능(Performance), 변경 용이성(Modifiability) 그리고 가용성(Availability)를 살펴 보았다. 이외에도 Software System에 따라 다른 Quality Attribute들이 있을 수 있다. 각 Quality Attribute는 Quality Scenario로 표시 될 수 있다. 또한 Quality Attribute들은 때에 따라 Functional Requirement가 될 수 있다.

Quality Attribute를 만족하기 위한 Tactics나 Architecture Style들은 따로 논의 한다. Tactics는 Quality Attribute별로 접근하는 방식을 정리해놓은 것으로 [1]에도 설명이 되어 있다. Architecture Style은 Architecture Pattern이라고도 불리는데, 이는 POSA[3]의 책 시리즈에 잘 설명이 되어 있고, Design Pattern 처럼 종류가 다양하다.

Reference

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

[2] ISO/IEC 25010, https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

[3] Frank Buschmann, et. al., "Pattern-Oriented Software Architecture Volume 1: A System of Patterns Volume 1 Edition", Wiley

개요

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