소프트웨어 아키텍처의 품질 속성 특징과 문제점, 시나리오(with 예시)

소프트웨어 아키텍처에서 품질 속성(Quality attribute)은 가장 중요한 요소입니다. 이번 글에서는 소프트웨어 아키텍처의 품질 속성 특징과 문제점, 그리고 문제점을 극복하기 위한 품질 속성 시나리오를 예시와 함께 알아보겠습니다.

 

품질 속성(Quality Attribute)과 소프트웨어 아키텍처(Software Architecture)

소프트웨어 아키텍처에서 말하는 품질(Quality)은 품질 속성(Quality Attribute) 입니다. 품질 속성은 아키텍처에 있어서 가장 중요한 요소이며, 소프트웨어 아키텍처에서 3가지 특징을 가지고 있습니다.

• 기능과 품질은 상호 독립적(Orthogonal) 관계이다.
• 품질 속성은 반드시 소프트웨어 아키텍처 설계 초기에 반영되어야 한다.
• 아키텍처의 품질 속성 간에는 Trade-off가 존재한다.

※ Orthogonal : 어떤 두 개념이 상호 간에 관계없이 독립적으로 존재하는 것

※ Trade off : 서로 대립되는 요소 사이의 균형

 

기능과 품질이 상호 독립적이라는 의미는 두 개의 다른 시스템이 있다면, 서로 같은 기능을 구현할 수 있다는 의미입니다. 두 개의 시스템이 서로 다른 구조를 가지고 있는 것은 품질 속성이 다르기 때문입니다.

 

품질 속성이 초기 설계에 반영되어야 하는 이유는 소프트웨어의 특성 때문입니다. 소프트웨어의 품질 속성은 이해하기도 어렵고 구현하기도 어렵습니다. 따라서 개발이 진행되거나 완료된 시점에서 품질 속성을 추가하기가 매우 어렵습니다.

 

또한  설계 단계에서 품질 속성이 반영되어야 소프트웨어 품질을 향상할 수 있습니다. 소프트웨어 제품의 품질 속성은 초기 설계 단계에서 정하는 것이 설계 원칙입니다.

 

아키텍처의 품질 속성 간에 Trade-off가 존재한다는 것은 아키텍처 구성이 특정 품질을 높이지만 다른 품질은 낮출 수도 있다는 의미입니다. 예를 들어 아키텍처에 미들웨어를 두는 것은 유지보수에는 도움이 되지만, 성능을 저하시키기도 합니다.

 

 

소프트웨어 품질 속성의 문제점

소프트웨어의 품질 속성은 사람들마다 생각하는 바가 다릅니다. 어떤 사람에게 품질 속성은 사용성이고, 또 어떤 사람에게는 성능이 되기도 합니다. 이 외에도 품질 속성은 이식성, 재사용성, 유지보수, 성능, 가용성 등등이 될 수 있습니다.

 

사람마다 품질 속성에 대해서 사용하는 용어가 다르고, 각자가 생각하는 품질 속성의 개념이 다르니 문제가 발생합니다.

 

용어와 개념이 통일되지 않으니 각자가 이해하는 바가 다르고 의사소통이 안됩니다. 또한 요구사항과 문제를 어떤 품질 속성으로 해결할 수 있는지 정할 수 없게 됩니다. 결국 소프트웨어 아키텍처에 품질 속성을 반영하기 어려워집니다.

 

이런 문제점들을 해결하는 방법이 품질 속성 시나리오입니다.

 

품질 속성 시나리오와 구성요소

품질 속성 시나리오란 소프트웨어 시스템이 일정한 환경과 상황에서 내외부 자극에 의해 예상되는 반응과 작동에 대한 구체적인 과정과 예상되는 결과입니다. 품질 속성 시나리오에는 자극의 근원, 자극, 환경, 대상, 응답, 응답 측정 등 6가지 구성 요소가 있습니다.

• 자극의 근원(Source) : 자극, 입력, 반응 등을 일으키는 주체 또는 시스템
• 자극(Stimulus) : 시스템의 반응에 필요한 이벤트. 품질 시나리오를 시작하는 역할
• 환경(Environment) : 시나리오 진행 동안 시스템이 놓이는 운영 환경, 조건 등
• 대상(Artifact) : 행위가 시나리오를 통해 특성화되는 대상으로 시스템의 일부
• 응답(Response) : 자극에 대한 결과 또는 외부적으로 보이는 행위 등
• 응답 측정(Response Measure) : 성공의 기준. 성공적인 반응에 대한 기준은 구체적이고 측정 가능해야 함

품질 속성 시나리오의 구성요소와 흐름

 

품질 속성 시나리오 예시

사용성(Usability), 성능(Peformance), 가용성(Availabilty), 상호운용성(Interoperability), 보안성(Security), 변경용이성(Modifiability), 테스트용이성(Testability) 등의 품질 속성 시나리오 예시를 살펴보겠습니다.

 

사용성(Usability) 시나리오 예시

사용자는 새로운 애플리케이션을 다운로드하고, 2분 동안 시험한 후에 생산적으로 사용한다.

 

여기서 자극의 근원은 사용자, 자극은 취소, 환경은 실행 환경, 대상은 시스템, 응답은 동작 취소, 응답 측정은 1초 이내입니다. 그림으로 보면 아래와 같습니다.

사용성 시나리오 예시

 

성능(Performance) 시나리오 예시

정산할 때 사용자는 확률적으로 분당 1000개의 거래를 요청하며, 거래는 평균 2처의 대기시간 내에서 처리된다.

 

여기서 자극의 근원은 사용자, 자극은 다운로드, 환경은 정상 운영환경, 대상은 시스템, 응답은 거래 처리, 응답 측정은 평균 2초 대기 시간입니다. 그림으로 보면 아래와 같습니다.

성능 시나리오 예시

 

가용성(Availability) 시나리오 예시

정상적인 동작 상태에서 예상치 못한 외부 메시지가 수신되자, 프로세스는 메시지가 수신을 운영자에게 알리고 진행 중이던 동작을 중단 없이 계속 수행한다.

 

여기서 자극의 근원은 외부 시스템이며, 자극은 외부 메시지, 환경은 정상 운영환경, 대상은 프로세스, 응답은 운영자에게 알람, 응답 측정은 중단 없음입니다.

가용성 시나리오 예시

 

상호운용성(Interoperability) 시나리오 예시

운송 정보 시스템이 교통관제 시스템에 현재 위치를 전송하고, 교통관제시스템은 위치 정보를 다른 정보와 결합해 구글 맵스에 올려놓고 브로드캐스팅 한다. 위치 정보는 99.9%의 확률로 정확하게 포함된다.

 

여기서 자극의 근원은 운송정보 시스템, 자극은 현재 위치 전송, 환경은 정상 운영환경, 대상은 교통 통제 시스템, 응답은 위치와 다른 정보 결합과 구글 맵스 업로드 후 브로드캐스팅, 응답 측정은 99.9% 정확성입니다.

상호운용성 시나리오 예시

 

보안성(Security) 시나리오 예시

불만을 품은 직원이 임금률을 외부 지역에서 변경 시도하고, 시스템은 감사 추적을 통해 하루 이내에 현재 데이터를 복구 후 부당 변경자를 식별한다.

 

여기서 자극의 근원은 직원, 자극은 임금률 변경 시도, 환경은 정상 운영환경, 대상은 시스템의 임금률 데이터, 응답은 감사 기록 유지, 응답 측정은 하루 이내에 데이터 복구와 부당 변경자 식별입니다.

보안성 시나리오 예시

 

변경용이성(Modifiability) 시나리오 예시

개발자가 시스템의 배경화면을 파란색으로 바꾸기 위해 사용자 인터페이스를 변경하고자 설계 시점에 코드를 변경한다. 3시간 이내에 변경과 테스트가 이루어져야 하고, 이 행위가 시스템 다른 영역에 영향을 주면 안 된다.

 

여기서 자극의 근원은 개발자, 자극은 코드 변경, 환경은 설계 단계, 대상은 코드, 응답은 변경으로 인한 사항 외 영향 없음, 응답 측정은 3시간 이내입니다.

변경용이성 시나리오 예시

 

시험용이성(Testability) 시나리오 예시

테스터는 컴포넌트에 대한 단위 테스트를 수행한다. 이때 전체 경로의 85%는 3시간 내로 시험할 수 있어야 한다.

 

여기서 자극의 근원은 테스터이고, 자극은 단위 테스트, 환경은 개발환경, 대상은 시스템의 컴포넌트, 응답은 컴포넌트의 결과물 출력, 응답 측정은 전체 경로의 85%를 3시간 이내에 달성하는 것입니다.

테스트용이성 시나리오 예시

---

※ 함께 보면 좋은 글

 

1. 소프트웨어 아키텍처 정의, 역할, Desing Mindset

 

소프트웨어 아키텍처 정의, 역할, Design Mindset 알아보기

 

2. 소프트웨어 아키텍트 정의, 하는일, 되는 방법, Design Thinking

 

 

소프트웨어 아키텍트(SA) 정의, 하는 일, 되는 방법, Design Thinking 4가지 원칙 알아보기