소프트웨어 아키텍처 : 분석, 평가 방법 : 개념, 정의, 개요

아키텍처 분석과 평가의 정의

아키텍처 분석과 평가라는 용어에 대하여는 표준화된 정의가 존재하지 않습니다. 분석과 평가를 구별 없이 사용하는 경우도 많습니다. 그러나 분석과 평가는 밀접히 관련된 서로 구별되는 개념입니다.

분석은 전체를 그것을 구성하는 부분들로 분리하는 활동으로 물체를 구성하는 요소들을 식별하거나 분리하는 활동, 즉 복합체와 그 요소들 및 그 관계를 상세히 검사하는 활동을 의미합니다. 평가는 가치를 판단하거나 결정하는 활동으로 신중한 조사 학습을 통하여 중요성, 가치 혹은 상태를 판단하는 활동을 의미합니다.

분석은 분해하여 들여다보는 활동이고, 분석을 위해서는 분석관점이 필요하며, 분석은 판단/평가를 위한 원시 데이터를 제공합니다. 반면 평가는 분석의 결과를 종합하여 판단하는 활동이며, 원시 데이터들을 종합하여 궁극적 가치 척도로 매핑합니다.

분석 결과가 중요한 판단으로 이어지기 위해서는 최초의 의도된 판단을 위하여 분석 결과를 반영하는 통합 과정이 있어야 하고, 이것이 평가입니다. 평가안에는 다시 여러 계층의 세부적인 평가가 들어갈 수 있습니다.

아키텍처 분석과 아키텍처 평가 역시 기본적으로는 각각 분석과 평가 활동으로 그 대상을 아키텍처로 한다는 점에서는 같습니다. 아키텍처 분석이 아키텍처에 대하여 주어진 분석 관점에서 어떤 분석 결과를 도출하는 활동입니다. 그러나,  아키텍처 평가는 아키텍처 분석 또는 다른 방법을 통하여 얻어진 데이터를 종합합니다. 그리고, 아키텍처에 대한 중요한 판단을 내리는 활동이라는 점에서 서로 다릅니다.

예를 들어 아키텍처의 품질을 하나씩 판단하는 분석기술을 갖고 있다고 하여도, 아키텍처 전체의 품질을 아는 것은 아닙니다. 이를 위하여는 품질들 전체를 종합적으로 보는 방법이 필요합니다. 아키텍처 평가는 이러한 종합적 평가를 겨냥합니다.

여러 가지 아키텍처 분석/평가 방법들이 제시되어 있습니다. 슬라이드의 아키텍처 분석/평가 방법들은 분석과 평가 요소를 모두 갖고 있습니다. 그러나 지배적인 결과가 아키텍처 분석 결과인지 혹은 아키텍처 평가 결과인지에 따라 이들을  SAAM, ATAM, ARID는 아키텍처 분석방법으로, CBAM, BITAM은 아키텍처 평가방법으로 분류할 수 있습니다.

아키텍처 분석은 아키텍처를 주어진 관점에서 검사 혹은 조사합니다. 그 결과를 정량적 혹은 정성적인 결과로 나타내는 활동으로 정의할 수 있습니다. 이 정의에 따라 아키텍처 분석은 분석대상 아키텍처에 분석 관점을 적용하여 분석 결과를 도출하는 활동입니다.

분석 관점에는 기본적으로 기능적 관점의 사용 시나리오와 품질속성 시나리오가 있고, 그 밖에 아키텍처의 견고성을 시험하기 위한 시나리오도 있습니다. 모든 시스템 요구사항이 분석관점이 될 수 있습니다. 그러나, 품질속성 시나리오가 가장 우선적인 분석 관점을 제공합니다.

그 이유는 아키텍처 드라이버가 아키텍처를 결정하는 데 중심적인 역할을 하였습니다. 따라서 이를 충족시키는 아키텍처를 확보하는 것이 가장 우선적이기 때문입니다. 그러나 아키텍처 설계에 이미 적용한 시나리오만을 분석에 적용한다면, 미처 확인하지 못한 부분을 놓치는 불완전한 분석이 될 수 있습니다.

따라서 분석에서는 선정된 아키텍처 드라이버 이외에 선정되지 않은 아키텍처 드라이버도 활용해야 합니다. 품질속성 시나리오가 사용 시나리오를 기반으로 만들어지기 때문에 품질속성 시나리오에 이용된 사용 시나리오는 따로 분석 관점으로 두지 않아도 됩니다.

하지만, 그렇지 않은 경우에는 아키텍처 드라이버에 반영되지 않은 사용 시나리오도 활용하여 사용 시나리오들의 시스템에서의 실행 가능성을 완전히 검증해야 합니다.

 

 

ATAM 분석

ATAM은 민감점, 품질속성들 간의 상충점, 위험요인들을 분석결과로 도출하고, 효과적인 분석을 위하여 시나리오의 우선순위를 활용하며, 철저한 분석을 위하여 경험에 의존하는 품질속성별 질문들을 도출하여 활용합니다. 민감점은 특정한 품질속성 응답을 얻는 데 필수적인 컴포넌트의 성질 혹은 컴포넌트 간의 관계의 성질입니다.

 

소프트웨어 아키텍처 : 분석, 평가 방법 : 개념, 정의, 개요

 

예를 들어 메시지의 처리에 소요되는 시간은 그 일에 관련된 가장 낮은 우선순위 프로세스에 민감할 수 있습니다. 상충점은 두 개 이상의 품질속성에 영향을 미치는 성질로 하나의 품질이 높아지거나 낮아질 때 다른 품질들이 이에 따라 낮아지거나 높아지는 관계에 있음을 의미합니다.

예를 들어 암호화 수준을 높일 경우 보안성은 높아지지만 더 많은 처리시간을 요구하여 성능이 낮아지게 됩니다. 위험요인은 아직까지 확정되지 않은 아키텍처적인 결정 혹은 이미 확정되었습니다. 그러나, 그 결과를 완전히 이해하지 못한 아키텍처적인 결정입니다.

 

 

분석 대상 시스템

아키텍처 분석의 대상이 되는 시스템은 전장에 있는 병사들의 이동, 전략 및 작전을 제어하도록 하는 전장제어시스템인 BCS시스템입니다. 이 시스템의 여러 업무 목표는 다양한 품질속성들을 요구합니다. 

 

소프트웨어 아키텍처 : 분석, 평가 방법 : 개념, 정의, 개요

 

Commander 체계는 외부의 지휘통제체계와 통신하며 동시에 여러 명의 Soldier 체계와 통신합니다. 시스템은 Commander가 기능을 수행하지 못할 경우를 대비하여 Soldier 중 하나를 백업으로 지정하고 있습니다. BCS는 가용성을 위하여 유사시에 Soldier1이 Commander 역할을 떠맡을 수 있도록 평상시에 Commander 데이터를 Commander로부터 받아둡니다. Commander에게 문제가 발생할 경우 Soldier1이 그 역할을 대신하도록 하는 전략을 채택하고 있습니다.

BCS의 성능전략은 Commander와 각 Soldier가 독립적으로 통신하도록 하는 것입니다. 예를 들어 Commander가 Soldier2와 통신하기 위하여 Commander로부터 Soldier2로 가는 메시지를 Soldier1이 전달해주면서 동시에 Soldier2로부터 Commander에게 가는 메시지도 전달하는 직렬 통신 방법도 고려할 수 있을 것입니다.

그러나 BCS에서는 Soldier1부터 Soldier4까지의 각 Soldier가 독립적으로 Commander와 통신하는 아키텍처를 선택하여
직렬 통신하는 경우보다 Commander와 각 Soldier 간에 메시지 전달에 소요되는 시간을 단축하였습니다.

BCS는 가용성을 위하여 하나의 Soldier를 Backup으로 지정해 두고 있습니다. 만일 그 Backup마저 장애가 발생할 수 있습니다. Commander의 역할을 수행하는 시스템 컴포넌트가 더 이상 존재하지 않게 되고, 시스템은 정상적으로 동작할 수 없게 됩니다.

 

 

가용성을 위한 대안 아키텍처

새로운 아키텍처 전략을 고안하는 것은 물론 분석활동이 아니라 합성활동에 속합니다. 그러나 분석과 합성은 서로 밀접하게 연결되어 있어서 분석의 결과는 많은 경우 합성으로 가는 아이디어를 제공합니다. 아키텍처 개선을 위하여 이러한 문제점에 대하여 다음의 가용성 관점의 대안을 고려할 수 있습니다.

첫 번째 대안으로 백업이 Commander와 완전히 동기화된 응답하는 능동적 백업일 수 있습니다. 응답하는 백업은 Commander로부터 메시지를 받을 때마다 백업이 응답을 함으로써 메시지가 온전히 수신되었음을 알려줍니다.
두 번째 대안은 백업이 응답하지 않는 수동적 백업이어서 메시지가 온전히 수신되지 않은 경우에도 재송신 요청을 하지 않습니다.

그러나 수동적 백업은 Commander로부터 메시지를 받을 때 응답을 하지 않습니다. 그래서 메시지 트래픽 양을 줄일 수 있습니다. 이 두 가지 대안을 모두 사용하는 일반적인 대안 아키텍처로 n개의 능동적 백업과 m개의 수동적 백업을 사용하는 아키텍처를 고려하면 이 시스템의 가용성은 등식으로 나타낼 수 있습니다.

그러나 가용성이 증가하면서 Soldier를 백업으로 유지하기 위한 통신 오버헤드 또한 함께 증가합니다. 그러므로 가용성과 성능이 상충 관계에 있다고 볼 수 있습니다. 이와 같은 아키텍처 접근방법의 대안이 분석의 결과로서 제시될 수 있습니다.

 

 

성능을 위한 아키텍처

통신성능의 관점에서 BCS 시스템은 Commander와 Soldier 사이에 9600Baud의 대역폭의 통신채널을 갖고 있습니다. 성능분석을 위하여 9600Baud 전송률 모뎀을 사용한다는 점, 다양한 크기의 메시지가 존재한다는 점, Commander 당 최대 25개의 Soldier가 가능하다는 점들을 고려하여야 합니다.

그러면 여러 가지 동작에 소요되는 시간이 계산될 수 있습니다. 이러한 계산 결과 Soldier가 백업이 되는 데 소요되는 총 시간은 216.05초로 Commander의 상태를 백업이 알게 하는데 초당 99.67bits, 즉 시스템의 전체 통신 대역폭의 약 1%가 소요됩니다.

 

 

민감점과 상충 관계

이러한 가용성모델과 성능모델의 구축을 통하여 다음의 분석결과를 얻을 수 있습니다. 첫째로 시스템의 성능을 능동적 백업의 수 n, 수동적 백업의 수 m, 그리고 통신 오버헤드 CO의 함수로 나타낼 수 있으므로 시스템의 성능은 n, m, CO에 민감합니다.

n, m에 의하여 결정되는 통신채널의 지연이 성능과 가용성에 영향을 줍니다. 둘째로 성능과 가용성이 상충관계에 있습니다. 고성능에 대한 요구는 Commander와 백업들 사이에 적은 통신 오버헤드를 요구하는 반면, 높은 가용성은 Commander와 백업들 사이에 높은 통신 오버헤드를 요구하기 때문입니다.

 

 

아키텍처 위험 요인

가용성, 성능, 민감점, 상충관계의 분석 외에 위험요인도 아키텍처 분석에서 빼놓을 수 없는 중요한 분석관점입니다. BCS 시스템의 경우, Commander와 백업 사이의 통신 트래픽이 많은 것을 적군이 탐지하여 공격대상으로 삼을 수 있다는 위험요인을 찾을 수 있습니다.

위험요인이 파악되면 위험요인이 현실화되는 것을 막을 수 있는 완화대책을 수립해야 하는데,  이 위험요인의 경우 위험 완화책으로 여기서 대안 아키텍처로 고려했던 것과 같이 복수의 Soldier 백업을 사용하는 방법이 있습니다.