Architecture Driver 아키텍처 드라이버

아키텍처 드라이버

 

1. 아키텍처 드라이버란 무엇인가?

  소프트웨어 집약적인 시스템의 아키텍처를 설계하기 위해 아키텍트는 시스템의 기본 구조에 영향을 미칠 가능성이 가장 높은 핵심 요구 사항을 필요로 한다. 이러한 주요 요구사항들은 시스템의 구조를 결정한다. 이를 "아키텍처 드라이버"라고 한다. 즉 Key가 되는 요구사항들이다.

  아키텍처 드라이버는 시스템의 모든 요구사항은 아니지만, 아키텍트가 초기 Design Decisions을 내릴 때 가장 영향력있는 요구사항을 파악하고 포착하려는 초기 시도이다.

  가능하면 최대한 빠르게 아키텍처 드라이버를 밝히는 것이 중요하다. 왜냐하면 초기 아키택쳐 결정은 시스템의 전체 lifetime에 영향을 끼치기 때문이다.

 

  아키텍처 드라이버는 아래와 같이 구성된다.

 - 기능 요구 사항(Functional Requirements) : High-Level 기능 요구사항, 여러 component들의 조합. 

                                                                        ※ Low-Level : Class 하나의 내부 기능

 - 품질 속성(Quality Requirements) : 모든 Quality Requirements는 Architectural Driver이다.

 - 제약사항(Constraints) : 설계가 시작되기전 미리 결정된 Fix된 결정 사양, technical constraints. bussiness constraints 

 

 

2. 불법 주정차 관리 시스템에서의 아키텍처 드라이버를 몇가지 제시해보자.

 - 기능 요구 사항 : 신고자의 신고, 매니저의 업무 배정, 차량주인에게 알람, 과태료 부과

 - 품질 요구 사항 : 정확성, 성능, 가용성, 유지보수성

 

3. 어떻게 하면 아키텍처 드라이버를 아키택처 설계에 반영되도록 할 수 있을까?

  아키텍처 드라이버를 설명하는 방법

 - 기능 요구사항 : Use Case Model, Use case Specification(Scenarios)

 - 품질 요구사항 : 품질 속성 시나리오(Quality Attribute Scenario)

 

 

 

Use case와 QA Scenario

1. Use case model 이란 무엇인가?

  Use case Model은 시스템의 기능적 요구사항을 상세하게 문서화 하는 데 중점을 둔 문서이다. 각 Use case들과 그들 간의 관계, 그리고 관련된 사용자나 외부 시스템(액터)를 포함한다. 

  Use Case Model : Use case Descriptions으로 구성

 

  Use case Model은 Diagram이 아니다. Diagram 1개가 여러종류의 Use Case Model에 사용될 수 있는 것이다. Diagram은 그저 표현법이다. 

  Use Case Diagram은 그래픽 도구로 시스템의 주요 Use case들과 그 Use Case를 수행하는 외부 엔티티간의 관계를 시각적으로 나타낸다.

  Use Case Diagram : 타원현의 Use case들과 액터간의 연결 선으로 구성

 

2. 좋은 Use case를 확인하기 위한 기준은 무엇인가?

 

3. Quality Attribute를 표현하기 위한 6가지 Part

  하나의 기능 요구사항은 여러 개의 품질 요구사항과 연계된다. Quality Attribute는 측정가능하거나 테스트 가능한 시스템의 속성이다. 즉 시스템이 이해관계자(Stakeholders)의 요구를 얼마나 잘 만족시키는지 나타내는 데 사용 된다. 이러한 특성을 명확하게 표현하는 방법이 바로 Quality Attribute Scenarios이다. 

 Quality Attribute Scenarios의 6가지 항목 

 - Stimulus : 자극

 - Artifact : 대상

 - Response : 응답

 - Response Measure : 응답 측정

 - Source of Stimulus : 자극원

 - Environment : 환경

 

4. 각 QA를 만족하기 위한 QA 시나리오의 예

  성능 QA 는 기능이 얼마나 빨라야 하는 지를 설명한다. 

   . 성능 QA 시나리오의 예 : 사용자(Source of Stimulus), 트랜젝션 시작(Stimulus), System(Artifact), 정상 동작일때(Environment), 시스템이 트랜젝션 프로세스를 한다(Response), 평균 2초 지연 이내에(Response Measure)

 

  변경용이성 QA는 기능이 얼마나 변경이 용이한지를 설명한다.

   . 변경용이성 QA 시나리오의 예 : 개발자(Source of Stimulus), 사용자의 UI 변경 요청(Stimulus), Code(Artifact), 디자인 타임에 코드를 수정할 때(Environment), Side Effect 없이 수정이 이루어 지고 Unit Test 된다.(Response), 3시간 이내에(Response Measure)