6장 아키텍처 설계
요구 분석서는 시스템이 해결하려는 문제를 기술한 것이고,
설계는 분석서에 기술된 문제를 해결 방안으로 바꾸는 작업이다.
예) 요구 분석 vs. 설계 : 건축 사례 (교재 그림 6.1)
기본적으로 설계는 창의적인 작업이되, 원리적인 접근과 체계적인 개념도 필요
대규모 소프트웨어를 설계하기 위한 필수 작업
- 소프트웨어 아키텍처 설계
- 서브시스템 간 인터페이스 설계
- 자료 저장소 설계 (파일, 데이터베이스 등)
- 모듈 설계 (시스템 컴포넌트 내부 설계. 알고리즘)
- 사용자 인터페이스 설계 (메뉴, 입력 양식, 출력 화면, 인쇄물 등)
아키텍처 설계
- 소프트웨어 시스템을 구성하는 컴포넌트나 모듈들을 정의하고
그들 사이의 인터페이스를 기술하는 것
- 시스템의 골격, 또는 조직
: 요구사항 분석 단계외 설계 단계의 중요한 연결 역할
- 보통 컴포넌트간 상호작용을 기술하는 다이어그램으로 아키텍처 모델을 표현
실제 아키텍처 예
- MFC
- Linux / Android-Linux
- Android App
- Android platform
아키텍처 예
- 계층 구조 스타일
- 클라이언트-서버 스타일
- MVC 스타일
- 리포지토리 스타일
- 파이프와 필터 스타일
- 등등
두가지 레벨에서 소프트웨어 아키텍처
- Architecture in the small
개별 프로그램의 구조(아키텍처)
- Architecture in the large
복잡한 엔터프라이즈 시스템의 아키텍처
: 다른 시스템, 프로그램, 컴포넌트를 포함하고
여러 컴퓨터들에 분산 배치되어 있으며
여러 회사가 소유하고 관리하는 규모의 시스템에 대한 아키텍처
cf. 용어
- 서브 시스템, 컴포넌트, 모듈
세가지 용어가 유사한 개념
서브 시스템 : 내부에 여러 컴포넌트, 모듈, 또다른 서브 시스템을 포함
컴포넌트 : 독자적으로 동작 가능
모듈 : 프로그래밍언어의 함수, 메소드
아키텍처 설계의 중요성
- 목적 소프트웨어 시스템의 성능, 강건성, 유지보수성 등에 중요한 영향을 끼친다.
- 교재 P.325 사례 (유지보수성 관련)
아키텍처를 명시적으로 모델링하는 것의 장점
- 이해관계자 간의 커뮤니케이션에 유용
- 시스템 분석에 유용
- 소프트웨어 재사용
: 여러 (대규모) 시스템들은 유사한 아키텍처로 구성되어 있다.
e.g., Software product line (SPL) :
동일한 아키텍처의 유사한 시스템들간의 재사용을 높이는 방법
아키텍처를 표현하는 방법
- 가장 흔한 방법: 시스템 구성요소와 관계를 표현하는
간단한 블럭과 화살표나 선분으로 구성된 다이어그램
- UML의 패키지 다이어그램
- 퍼사드 디자인 패턴
6.2 아키텍처 디자인 원리
- 아키텍처 설계는 단순하면서 효율적으로 표현해야 함 (단순성, 효율성)
- 분할 정복
e.g., N. Wirth의 Step-wise refinement
(모듈을 작성하는 Top-down 방법)
- 추상화 (Abstraction)
필요한 특징만 추출하여 표현
e.g., 지하철 노선도
- 모듈화
두 가지 기준
1) 모듈 간 결합도 (coupling)
2) 모듈 내부 응집도 (cohesion)
- 모듈 간 결합도
: 두 모듈이 서로 의존하는 정도를 판단
: 분류
자료 결합 (data coupling) : 모듈 간의 인터페이스가 매개 변수 전달 등의
자료 요소로만 구성된 경우
스탬프 결합 (stamp coupling) : 배열이나 레코드를 전달하되 그 중 일부만
전달하는 경우. 전역 변수 일부만을 사용하여 전달하는 경우
제어 결합 (control coupling) : 제어 흐름 관련 값을 전달하여 다른 모듈의
실행 순서를 제어하는 경우
공통 결합 (common coupling) : 여러 모듈이 공동 자료 영역을 사용하는 경우
내용 결합 (content coupling) : 다른 모듈의 지역 변수나 명령어를 수정하는 경우
: 결합도에 영향을 주는 요소
[교재 표 6.2]
e.g., 이름으로 모듈에 연결되는 형태 --> 결합도를 낮춤
- 모듈 내 응집도
: 하나의 모듈이 하나의 기능으로 되어 있는지를 판단
: 분류
기능적 응집 (functional cohesion)
순차적 응집 (sequential cohesion) : 모듈 안에서 하나의 소작업 결과가
다음 소작업의 입력으로 전달되는 형태
커뮤니케이션 응집 (communication cohesion) : 동일한 입출력 데이터에
대한 오퍼레이션을 모아놓은 형태 (수행 순서와는 무관)
시간적 응집 (temporal cohesion) : 동일한 시점에 수행되는 오퍼레이션을
모아놓은 형태 (예: 초기화 코드를 모두 모아놓은 모듈)
논리적 응집 (logical cohesion) : 모듈의 요소들이 논리적으로 관련있어서
모아놓은 형태 (예: 수학함수 라이브러리)
이유없는 응집 (coincidental cohesion)
6.3 아키텍처 설계 과정
- 주요 과정
1) 아키텍처 설계 목표 설정
: 유지보수, 성능, 보안, 강건성 ...
2) 시스템 타입 결정
: 상호작용 시스템, 이벤트 기반 시스템,
변환형 시스템, 자료 위주의 데이터베이스 시스템
3) 여러 아키텍처 관점에 따라 설계된 내용을 표현
: 모듈 관점
: 컴포넌트와 커넥터 관점
: 시스템과 주변 환경의 배치 관점
6.4 아키텍처 스타일
- 계층 구조 아키텍처 (Layered architecture)
- 클라이언트 서버 아키텍처 (client-server architecture)
- MVC 아키텍처 (model-view-controller)
- 저장소 아키텍처 (repository architecture)
- 파이프와 필터 아키텍처 (pipe and filter architecture)
6.5절과 6.6절은 SKIP
