소프트웨어 아키텍처 및 아키텍처 모델링

2020년 KAIST-MOOC 클라우드 서비스 아키텍처 강의(1)

강의 직접 보러가기 → 클릭

목차

[소프트웨어 아키텍처 설계]
- 아키텍처 드라이버
- 품질속성
- 아키텍처 설계문제 분석
[아키텍처 모델링]
- 컴포넌트, 커넥터, 인터페이스
- 아키텍처 스타일
- 소프트웨어 아키텍처를 보는 관점 체계

소프트웨어 아키텍처 설계

• 소프트웨어 아키텍처: 소프트웨어 시스템이 요구되는 기능과 품질을 궁극적으로 갖도록 소프트웨어 시스템을 용이하게 구축하고, 지속적인 사용과 개선을 위하여 필요한 진화성을 갖도록 하는 소프트웨어 시스템의 구조와 이어지는 개발에 관한 중요한 결정이다. → 용이성과 진화성
• 아키텍처 설계 → 상세 설계 → 시스템 구현
• Input: [아키텍처적으로 중요한]시스템 요구사항 + 특히 중요한 것들
  → 기능요구사항
  → 비기능요구사항: 품질요구사항 + 제약사항(개발이 지켜야하는 준수사항)
  Output: 아키텍처 문서 + 아키텍처 가이드라인(유지보수 및 진화 관리)

1. 시스템 아키텍처 설계: SW, HW로 이루어진 시스템 전체에 대한 설계
2. 소프트웨어 아키텍처 설계(HW보다 SW의 비용이 높은 경우 시스템 아키텍처 설계에 영향을 주게 됨)
3. 소프트웨어 상세 설계

[ 아키텍처 설계 근본 원리 12가지 ]

1. 해결해야할 문제를 정제하고 식별
   1) 아키텍처 드라이버
   2) 품질속성, 검증가능성, 품질속성 시나리오
   3) 문제해결
2. 결과가 어떤 모습을 가져야하는지 판단
   6) 소프트웨어 아키텍처를 보는 관점 체계
   5) 아키텍처 스타일
   4) 컴포넌트와 커넥터
3. 본격적인 아키텍처 설계에 적용되는 원리(합성[경험적 지식+창의적 아이디어]과 분석의 방법)
   7) 아키텍처 설계 결과
   8) 설계의 일반원리
   9) 아키텍처 패턴
   10) 품질 속성 설계전략
   11) 아키텍처의 분석
4. 설계가 끝나고 그 결과물을 평가하는데 사용되는 원리
   12) 아키텍처 평가

아키텍처 드라이버

아키텍처 드라이버: 아키텍처적으로 중요한 요구사항
→ 선정된 아키텍처 드라이버: 아키텍처 설계의 출발점으로 선택된 것들

품질 요구사항이나 제약사항으로부터 나온다.
→ 서비스의 기능보다는 품질, 성능이 아키텍처를 결정

기능요구사항: 아키텍처에 직접적으로 영향을 주지 못함
제약사항: 구체적인 방식으로 아키텍처에 영향을 미침
품질요구사항: 미묘한 방법으로 아키텍처 결정에 영향을 줌
(ex.기능중심으로 시스템을 나누는 것 → 개발 및 유지보수 용이)
(명시적으로 요구되지 않아도 개발자는 품질 속성을 추구)

품질속성

품질속성: 요구사항 그룹

품질(성능, 수정용이성, 개발 시간, 개발팀의 협력수준)
1) 시스템 품질
2) 개발 과정의 품질: 요구사항으로부터 명시적으로 잘 언급되지 않는 것 → 품질 속성들이 시스템과 시스템 개발에 영향을 미치고 있다는 것을 인식해야 함

[ 품질 속성의 검증 가능성 ]

• 품질 속성은 검증 가능해야 한다.
  → 시스템이 달성했는지 확인할 수 있는 형태로 구체적이고 정량적으로 작성
• 시스템 개발이 완료된 뒤 시스템과 개발에 적용되어 충족되었는지 검증되어야 함
  → 개발자와 고객이 같은 해석을 하도록 모호성 없이 기술되어야 한다.

[ 품질 속성 시나리오 : 6PartScenario ]

검증 활동: 어떤 자극을 대상에 가하고 그 반응을 측정하여 측정 결과가 기대한 수준에 도달하는지 확인하여 판단함
→ 개발자가 하는 시스템 시험
→ 고객이 하는 인수시험을 위한 시험 요구사항

1. 자극
2. 대상
3. 반응
4. 반응 측정
5. 자극 발생 원천
6. 환경

아키텍처 설계문제(아키텍처 전략) 분석

요구사항 들 중 아키텍처 설계를 요구하는 해결책 후보를 도출하는 활동

1. 문제 파악 후 정리
2. 문제의 해결책 도출
3. 해결책 평가
4. 효과 정리

아키텍처 모델링

아키텍처 기본 구성 요소

• 컴포넌트와 커넥터의 이분법
  → 분할정복: 문제의 분할[컴포넌트] + 분할된 문제들의 관계[커넥터]
• 표현력을 높이기 위한 아키텍처 요소들
• 인터페이스

1. 컴포넌트
2. 커넥터: 컴포넌트 간의 상호작용을 실현시키는 요소
   * Communication & coordination: Procedure call, Event, Stream
   * Conversion: Data Access, Adaptor
   * Facilitation: Linkage, Distributor, Arbitrator
3. 인터페이스: 연결동작(컴포넌트와 커텍터들이 연결되어 동작하기 위한 연결 동작이 정의되어 있어야 한다 → 접속 부위에서 일어나는 상호 작용 동작까지 올바르게 정의되어 있어야 기대 동작 구현 가능)
   → 아키텍처 요소가 보내고 받는 메시지들의 리스트 + 누가 어떤 순서로 보내고 받는지 규정
   → Packetizer 컴포넌트 행위를 상태 머신으로 정의
   → Image Pipeline 컴포넌트와 Packet Pipe 커넥터의 행위 정의 생략

아키텍처 스타일

미리 만들어진 부분적인 아키텍처 설계 결정들의 집합
→ 이름, 컴포넌트, 커넥터, 제약사항, 적용 예제, 장단점

소프트웨어 아키텍처를 보는 관점 체계

• S/W 시스템은 그 자체로 무엇인지 특징짓기 어렵다.
  → 특정한 관점을 갖고 그 관점에 집중하여 보려 하면 복잡한 소프트웨어 시스템도 그 방향에서의 모습을 보인다. [ 관점 ]
  → [ 뷰 ] S/W 시스템을 포착하기 위한 시각에서 본 시스템의 모습
• 관점은 시스템이 관심을 갖는 이해당사자에 따라 달라지고 다양하다.

1. 논리적 관점: 시스템개발의 관건이되는 중심적인 문제해결을 겨냥한 관점
   → 컴포넌트: 연산 혹은 처리를 수행하는 요소
   → 커넥터: 그러한 컴포넌트들을 연결하는 요소
2. 모듈 관점: 시스템이 어떤 코드 모듈로 구성되고 그들이 어떻게 연결되어야 하는지를 보이는 관점 [모듈별로 시스템 설계]
   → 메인, Config, Input, Ouput의 코드 모듈들이 식별되어 있다.
   → 컴포넌트: 컴포넌트 & 코드 모듈
   → 커넥터: 모듈들 간의 다양한 연결관계
   → 관심의 대상이 되는 모듈 관계: is-part-of 관계 / depends on 관계 / is a 관계 혹은 is a kind of 관계 [UML 에서 지원: Aggregation(Composition), Dependency, Generalization(subclass)]
3. 실행 관점: 시스템의 실행시 모습에 초점(실행 View는 실행 시에 등장하는 요소들로 구성)
   → 컴포넌트: 프로세스, 쓰레드, 메모리 등 실행시에 동작하는 연산 요소
   → 커넥터: 컴포넌트를 연결하는 실행 시의 상호작용 방식들

• 아키텍처 관점 체계: 아키텍처 관점들의 집합
  → Kruchten의 4+1 관점체계: 논리적 관점, 개발 관점, 프로세스 관점, 물리적 관점, 시나리오
• 고려할 점
  → 무리 없이 실행 가능한 소프트웨어 개발을 위해 실행시의 모습 고려
  → 코드 측면도 중요
• 아키텍처 수준: 개념적 수준(사용시나리오 / 개념적) → 논리적 수준(논리적/모듈) → 물리적 수준(실행/코드) → 배치수준(실행요소배치/코드배치)
• 아키텍처 View 개발
  [View의 형성]
  1) 요구사항 분석: 시나리오 View / 개념 View
  2) 아키텍처 설계
  [View의 사용]
  3) 상세설계: 논리 View / 모듈 View
  4) 구현: 코드 View
  5) 통합 및 시험: 실행 View, 실행 요소 배치 View / 코드배치 View
  → 아키텍처 드라이버별로 적절히 다루어질 수 있는 관점이 달라진다.