개요
여기서는 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가 가져야 하는 내용의 일반적인 셜명이다.
|
시나리오 항목 |
입력 가능 값 |
|
주체(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)
|
시나리오 항목 |
입력 가능 값 |
|
주체 (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
'Software Architecture' 카테고리의 다른 글
| 애자일 소프트웨어 아키텍쳐를 향하여. (0) | 2020.05.25 |
|---|---|
| Software Architecture: ATAM, Architecture Evaluation (0) | 2020.01.22 |
| Software Architecture: 요구 사항은 어떻게 추출하는가? (0) | 2018.10.09 |
| Software Architecture: 어떻게 설계 할 것인가? (0) | 2018.09.30 |
| Software Architecture: 무엇을 설명할 것인가? (2) | 2018.09.29 |