아키텍처평가검증

 1. 소프트웨어구조(Architecture)의 중요성

 1) 시스템품질속성의 사용 또는 억제하는 기준이 된다.(성능, 변경용이성, 보안, 재사용성)

 2) 시스템품질을 예측할 수 있도록 한다.

 3) 시스템 초기의 설계 결정 사항을 기술한다.

 4) 개발 시 제약사항을 정의한다.

 5) 이해당사자와의 의사소통 수단이 된다.

 6) 개발 조직구조를 결정한다.

 7) 변경에 대한 원인 파악과 관리를 가능하게 한다.

 8) 비용과 일정을 정확하게 예측하도록 한다.

 9) 점진적인 개발으 가능하게 한다.

 10) 변경가능하고 재사용 가능한 모델을 제공한다.

 11) 독립적으로 개발된 컴포넌트들의 통합을 가능하게 한다.

 12) 훈련의 기반이 된다.

 2. 구조평가의 목적

 - 시스템이 특정목적(품질속성)에 부합하는 가를 확인한다.

 - 위험을 분석하여 과제의 실패를 사전에 방지한다.

 - 이해관계자와 프로젝트 참여자들간의 커뮤니케이션을 향상시키고 공감대를 끌어낸다.

3. ATAM 정의(Architecture Tradeoff Analysis Method)

 - 품질속성에 기반하여 아키텍처 TradeOff를 분석하고 이에 대한 위험요소를 찾아내는 아키텍처 평가방법

 Business Driver --> Quality Attribute --> Scenario                              ->

 Software Architecture --> Architectural Approaches --> Architectural Decisions  -> Analysis --> Tradeoffs, Sensitivity Points, Non Risks, Risks --> Risk Themes --> impact 

4. ATAM 절차

 - 아키텍처가 품질 목표를 만족하는지 여부와 품질 목표간에 발생하는 충돌에 대해서도 분석함

 소개(Presentation)

 1. ATAM소개 : 평가선임자가 참석자들에게 평가 방법에 대해 설명함

 2. Business Driver소개 : 프로젝트 대표자가 사업 목표와 중요한 아키텍처 요구사항에 대해 설명함

 3. 아키텍처 소개 : 아키텍트가 사업목표를 달성하기 위해 설계한 구조에 대해 설명함

 분석(Analysis)

 4. 아키텍처 접근 방법 식별 : 아키텍트가 아키텍처 접근방법을 식별

 5. 품질속성 Utility Tree 작성 : Utility Tree 를 기반으로 시스템이 획득해야 하는 품질 속성을 도출하고 정의함.

 6. 아키텍처 접근방법 분석 : 품질 속성 시나리오를 기반으로 아키텍처 접근 방법을 분석함.

 검증(Verification)

 7. 시나리오 브레인스토밍 & 우선순위 결정 : 브레인스토밍으로 시스펨이 획득해야 하는 품질 속성을 도출하고 정의함.

 8. 아키텍처 접근방법 분석 : 품질속성 시나리오를 기반으로 아키텍처 접근방법을 분석함.

 보고(Report)

 9. 결과보고 : 평가팀은 ATAM 평가를 통해 수집한 정보를 이해관계자들에게 보고함.

5. CBAM(Cost Benefit Analysis Method)

1) 시나리오를 취함 : 우선순위 1/3 선정

2) 시나리오 수정 :QA response goal levels로 worst, current desired, best 분류

3) 시나리오 우선순위 : 투표로 우선순위 결정

4) 사용성 할당 : level별 사용성 점수 산정 

5) Architecture Strategy 개발 및 영향 시나리오, 기대응답값 매핑 (후보구조)

6) 사용성값을 매핑값에 할당

7) Architecture Strategy 별 Total Benefit 계산 

8) Calculate Return : benefit/cost와 AS의 우선순위화

9) AS 선정 

6. SW지표분석

1) Cyclomatic Complexity(CC)

- if 분기(decision points) +1 

2) Robert C.Martin Metrics

- A(Abstractness) : 패키지가 얼마나 추상화 되었는가?(비율 1/3)

- Ca(Afferent Couplings):다른 패키지에 의해 얼마나 사용되고 있는가?

- Ce(Efferent Couplings): 다른 패키지를 얼마나 사용하고 있는가?

- I(Instability)불안정 : Ce/(Ca+Ce)

- D(Distance) D=|A+I-1|

 Ca가 작으면 I가 1에 가까워진다. A는 0에 가까울 수록 좋다. : 다른 패키지에 참조가 적으면 불안정하며 추상화가 안 될수록 좋다.

 Ca가 크면 I가 0에 가까워진다. A가 1에 가까울 수록 좋다. : 다른 패키지에 참조가 많으면 안정적이며 추상화가 많이 될 수록 좋다.

3) Chidamber&Kemerer Metrics

- Weighted Methods per Class(WMC) : 클래스 내의 모든 CyClomatic Complexity를 더한 값

- Depth of Inheritance Tree(DIT) : 클래스의 상속 깊이

- Number of Children in Tree(NOC) : 자식 클래스의 수

- Coupling between Objects(CBO) : 객체간 결합도(결합된 클래스 수) : 사용하거나 사용된거-생성자 제외

- Response for Class : 클래스가 제공하는 함수 + 클래스가 사용하는 함수 (생성자 포함)

- Lack of Cohesion in Methods(LCOM) : Method가 사용하는 변수들이 겹치는 정도(겹치지 않는 Method pair=5, 겹치면 =1 ., LCOM= 5-1=4)

                                      얼마나 응집도가 부족한가? 값이 낮으면 합쳐야 함..

7. 의존성 분석

- Class A implements interfaceA

- classA contains classB : classB 선언

- classA.b is of type classB : classB b;

- classA.getB() returns classB : return b;

- DSM(Dependency Structure Matrix), Composition View

- Dependency Injection : interface를 통해 구현시점에 변경값을 넣어준다 : 구현변경이 시스템에 영향을 주지 않음.

 -DIP(Dependency Inversion Principle): client와 service interface를 하나의 pkg.로 묶으면 service 구현이 해당 pkg.에 의존하게 된다.

                                       기존엔 client가 service를 참조 하고 있었으나 pkg.를 묶어 i/f를 service에 제공하여 구현하게 한다.

              예) M/W에서 HAL과 Application을 참조하여 구현하는게 아니라 M/W에서 HAL, App interface를 관리하여 HAL/App이 M/W에 의존하게 한다.

                  하드웨어 변경에 독립을 갖게 된다.

                  추가) 하이레벨모듈(어플리케이션)은 로우레벨모듈을 의존하던 것에서 하이레벨은 로우레벨의 추상(추상클래스,인터페이스)에 의존하고 

                  로우레벨모듈은 로우레벨 추상에 의존하게 되는 형태(느슨한 연결, 로우레벨 변경이 하이레벨로 전파되는것을 막음)

- Deploy Hell : Component간 Dependency 사용이 복잡해져 Version up발생시 의존성이 연쇄적으로 일어나는 현상