Software Architecture를 위한 Quality Attribute

개요

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

 

 

 

 

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

 

성능(Performance)

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

 

 

 

시나리오 항목	입력 가능 값
주체(Source)	. Event 발생 요인(사용자 요청, 시스템 내부/외부)
자극 (Stimulus)	. Event 도착 패턴 (Event의 주기적/Periodic 도착, 산발적/sporadic 도착, 확률적/Stochastic 도착)
대상(Artifact)	. 시스템의 서비스 또는 시스템의 하나 혹은 그 이상의 콤포넌트
환경 (Environment)	. 다양한 동작 모드(Normal, Emergency, Peak Load, Overload)
반응 (Response)	. 도착한 이벤트의 처리하며 다음 내용을 결정한다.  . 자극을 처리한다.  . 서비스 수준을 변경한다.
측정 (Response Measure)	. 도착 이벤트의 처리시간/양(Latency, deadline, throughput, jitter, miss rate)

 

 

변경 용이성 (Modifiability)

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

 

시나리오 항목	입력 가능 값
주체 (Source)	End user, developer, system administrator
자극 (Stimulus)	기능 추가/삭제/변경하라는 지시 혹은 품질 속성, 용량 혹은 기술의 변경
대상(Artifact)	코드, 데이터, 인터페이스, 콤포넌트, 자원, 설정(Configuration)
환경 (Environment)	실행시간, 컴파일 시간, 빌드 시간, 시동 시간, 설계 시간
반응 (Response)	다음 중 하나 혹은 여러가지:  . 변경을 수행한다.  . 변경을 테스트한다.  . 변경을 배포한다.
측정 (Response Measure)	다음 중 비용:  . 영향받은 대상의 숫자, 크기, 복잡도  . 노력  . 필요한 시간  . 비용 (직접 비용 혹은 기회 비용)  . 이러한 변경을 통해 영향 받는 기능이나 품질 속성  . 새롭게 추가되는 결함

 

가용성(Availability)

가용성은 Software System이 사용자에게 가용한 시근으로 보통 확률로 많이 표시된다. [1]에서도 MTBF / (MTBF + MTTR)로 설명하고 있다. 여기서 MTBF는 Mean Time Between Failure이고, MTTR은 Mean Time To Repair로 하고 있다. 즉, 시스템을 고치는 시간을 제외한 시스템의 사용 가능 시간(MTBF)의 비율을 나타낸다. 여기서 99%의 경우는 Downtime이 연간 3일 15.6시간이고 Cloud에서 동작하는 시스템은 99.9%를 이야기 하는 경우가 많은데 연 8시간 45초로 매우 낮다. 아래는 가용성에 대한 일반적인 Quality Scenario이다.

 

시나리오 항목	입력 가능 값
주체 (Source)	. 결함/실패의 원인 [시스템 내부/시스템 외부][사람, HW, SW, 장비, 환경]
자극 (Stimulus)	. 발생 결함 [Omission, Crash, Incorrect Timing, Incorrect Response]
대상(Artifact)	. 가용성을 위해 요구되는 자원[프로세서/통신채널/자료저장소/프로세스]
환경 (Environment)	. 결함 또는 실패 발생의 시스템 상태   [Normal Operation, Start up, Shutdown, Repair mode, Degraded operation]
반응 (Response)	실패 방지.   실패 인지:   . 실패를 기록한다.   . 사용자 및 다른 시스템을 포함하는 적절한 당사제에게 알린다.  실패 복구:   . 정의된 규칙에 따로 오류, 실패를 유발한 이벤트 소스를 비활성화 시킨다.  . 시스템 중요도에 따라 결정되는 지정된 간격에서 사용할 수 없게 한다.  . 정상 모드 또는 성능 저하 모드에서 계속 작동한다.
측정 (Response Measure)	. 시스템이 사용 가능할 때까지의 시간 간격  . 가용성 시간 (99.999%)  . 보수 시간  . 비정상 모드에서 동작시간 간격

 

기타 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