Architect 공부 9일차 - 아키텍처 구성의 흐름

아키텍처란

 

요구사항에 맞춰 시스템이 어떻게 구성되고 동작하는지에 대한 표현

 

S/W 분야에서 아키텍처에 대해 딱 떨어지는 정의는 없는 것 같다.

각자만의 해석이 일부 들어간 개념과 느낌으로 의사소통 한다고 생각된다.

그렇기에 내가 생각하는 아키텍처에 대해 개념을 잡고 가려한다.

 

---

 

간단하게 말하면 시스템에 대한 구성도 정도로 표현할 수 있다.

하지만 단순하게 표현된 결과물보다는, 아키텍처가 도출되기 까지의 과정에도 충분한 의미가 있다고 생각한다.

 

과정을 대략적으로 살펴본다면

 

1) 이해 관계자들의 불편으로부터 해소를 위한 니즈가 생겨나고

 

2) 고객들도 자신의 진짜 필요한 것을, 요구사항이 뭔지 몰라 요구공학을 통해

   다양한 방법 (워크샵, 브레인 스토밍, 인터뷰, 설문조사, 시나리오 기법) 으로 시스템에 필요한 요구사항들을 도출한다.

※ Architectural Driver(AD) : 아키텍처를 디자인하기 위한 핵심 요구사항

2024.05.08 - [IT/Architect 공부] - Architect 공부 6일차 - 요구공학 및 품질속성

 

3) 기능적 요구사항과 비 기능적 요구사항이 나오고, 이를 다양한 UML로 표현하여

    이해관계자들이 동일한 시각을 갖는지, 올바르게 선정되었는지 확인한다.

기능적 요구사항 : 시스템이 제공해야하는 서비스와 기능에 대한 정의 ( 입력값과 출력값이 명확 )

비기능적 요구사항 : 시스템의 품질과 제약사항에 대한 정의 ( 입력, 출력에 영향을 줄 수 있는 요소들 )

 

4) 기능적 요구사항은 주로 유스케이스 모델로 표현하고, 비 기능적 요구사항은 품질 속성이 추출되어 이해관계자들에 의해 우선순위가 결정된다. 각 품질속성에 대해 시나리오를 작성해 보고, 이를 충족할 수 있는 잠재적 방법들을 탐색한다.

( Deisng Approach )

 

※ 품질속성과 관련된 ISO (국제 표준 기준)는 기능성,신뢰성,사용성,효율성,유지보수성,이식성 6가지의 특성이 정의된 ISO-9126과 이를 개정해 호환성과 보안성이 추가된 ISO-25010이 있다.

 

5) 품질속성은 결정된 우선순위에 따라 핵심 품질속성을 충족할 수 있는 디자인 후보들에 대한 비교 및 결정을 한다. 
( Architectural Decision )

 

6) 이렇게 아키텍처에 포함될 디자인이 결정되면 이를 설계하고, 주요 이해관계자들이 이해할 수 있는 다양한 시점의 View로 표현한다. ex: 4+1 View, 3 View

 

7) 최종적으로 요구사항이 잘 반영되었는지 평가를 통한 아키텍처를 검토한다.

 

※ 아키텍처 평가 방법

ㅁ SAAM (Software Architecture Analysis Model) 

. 시나리오 중심

. 현재 없는 기능에 대한 간접 시나리오를 개발하고, 이를 충족하기위해 변화해야하는 대안 아키텍처를 찾는다.

  직/간접 시나리오에 가중치를 두고, 투표 및 비교 평가 등으로 현재 아키텍처와 대안 아키텍처에서 시나리오를 얼마나 충    족하는지 판단한다.

. Modifiability와 Functionality에 집중

 

ㅁ ATAM(Architecture Tradeoff Analysis Method)

. SAAM을 발전 시킨것으로 아키텍처 별 Tradoff 를 분석하여 평가하는 방법

. 성능, 사용성, 가용성, 확장성, 보안성 등의 다양한 항목 기준

 

ㅁ CBAM(Cost Benefit Analysis Method) 

. 비용과 이익 등 경제적인 측면에서 아키텍처를 평가하는 기법