Architectural Design

6장. 아키텍처 설계

아키텍처 설계

아키텍처 설계 (Architectural Design)

•

시스템 전체 구조 설계

•

시스템 주요 구조 컴포넌트 (Subsystem)들과 상호작용하는 컴포넌트 간의 관계 (Interfaces)

아키텍처 변경

•

아키텍처의 변경은 비용이 많이 든다.

•

애자일 프로세스에선 애자일 개발 프로세스 초기 단계가 전체 시스템 아키텍처 설계에 초점을 맞추어야 한다는 것을 받아들인다.

•

변화에 대응하여 컴포넌트를 리팩토링 (Refactoring)하는 것은 비교적 쉽다.

•

그러나 시스템 아키텍처를 리팩토링하는 것은 대부분의 시스템들을 아키텍처 변화에 따라 수정할 수 있기 때문에 비용이 많이 든다.

아키텍처의 점진적인 개발은 바람직하지 않다.

아키텍처 설계와 요구공학 프로세스의 중첩

•

이상적으로는 요구사항 명세에는 설계가 포함되지 않아야 한다.

•

그러나 주요 아키텍처 컴포넌트들이 시스템의 상위 수준 특징을 반영하기에 컴포넌트들을 식별할 수 있어야 한다.

•

요구 공학 프로세스의 일부로서, 시스템의 기능들과 특징들을 그룹지어 큰 단위의 컴포넌트나 서브시스템과 연결 짓는 추상 시스템 아키텍처를 제안할 수 있어야 한다.

요구공학 프로세스의 일부로서 추상 시스템 아키텍처가 제시되어야 한다.

아키텍처와 기능적 / 비기능적 요구사항

시스템의 개별 컴포넌트 → 기능적 요구 사항을 구현

시스템의 아키텍처 → 비기능적 시스템 특성에 지배적인 영향을 준다.

아키텍처의 명시적 설계와 문서화의 장점

1. 이해당사자 간의 의사소통

상위 수준의 시스템 표현으로 이해당사자 간의 의사소통에 도움

2. 시스템 분석

시스템의 중대한 비기능적 요구사항 (성능, 신뢰성, 유지보수) 등을 만족시킬 수 있는지 분석

3. 대규모 재사용

비슷한 요구사항을 가진 시스템의 아키텍처를 재사용

Tip) 시스템 아키텍처는 간단한 블록 다이어그램을 이용하여 약식으로 나타낼 수 있다. 컴포넌트 (네모상자) + 데이터/제어 신호 (화살표)

아키텍처 설계 과정

아키텍처 설계

•

시스템의 기능적, 비기능적 요구사항을 만족시키기 위한 시스템 구조를 설계하는 창의적인 프로세스

•

정해진 방법은 없다.

•

일련의 활동이라기보다 연속적인 결정이라 여기는 것이 좋다.

아키텍처 및 시스템 특성

아키텍처 스타일과 구조의 선택은 시스템의 비기능적 요구사항에 좌우된다.

비기능적 요구사항 유형과 아키텍처 고려사항

비기능적 요구사항	아키텍처 고려사항
성능	같은 컴퓨터에 배치된 소수의 컴포넌트 안에 중요 작업이 모이도록 한다. 컴포넌트 간 통신을 줄임, 시스템 중복, 부하 분산
보안성	아키텍처에 계층 구조가 사용되어야 한다. 중요한 자산을 가장 안쪽 계층에 두는 계층 구조 사용
안전성	안전 관련 작업이 단일 컴포넌트나 소수의 컴포넌트에 같이 배치되도록 설계한다. 안전 관련 작업을 소수의 컴포넌트에 배치하여 안전 검증 및 대응을 간단하게 한다.
가용성	중복 컴포넌트를 배치, 시스템 중단 없이 컴포넌트 교체 및 갱신
유지보수성	변경이 용이한 독립적인 컴포넌트 사용

아키텍처 뷰

4+1 뷰 모델 (4+1 View model of software Architecture)

뷰	설명
논리적 뷰	객체 또는 객체 클래스로 시스템의 핵심 추상화를 보여준다. 시스템의 논리적 구성을 보여준다.
프로세스 뷰	시스템의 (운영체제)프로세스/쓰레드의 런타임 상호작용을 보여준다. 성능, 가용성 등 비기능적 시스템 특성과 관련
개발 뷰	소프트웨어가 개발을 위해 어떻게 분해되는지 보여준다.
물리적 뷰	시스템 하드웨어와 소프트웨어 컴포넌트들의 배치를 보여준다.
유스케이스 뷰	시스템의 행동(유스케이스 시나리오)을 액터 관점에서 보여준다.

시스템을 바라보는 관점을 위의 5가지처럼 볼 수 있다. 꼭 아키텍처 관점으로만 볼 필요가 없다.

아키텍처 패턴

패턴

•

자주 발생하는 문제 (Problem)에 대한 해법 (Solution)

•

지식의 공유와 재사용을 목적으로 한다.

•

이름, 설명, (적용 가능한 경우)문제, 해법 등으로 구성된다.

아키텍처 패턴 (= 아키텍처 스타일)

•

서로 다른 시스템과 환경에서 시도되고 시험된 바람직한 사례를 양식화하고 추상화한 기술

•

해당 영역에서 성공적이고 바람직한 시스템 구조 사례를 추상화

아키텍처 패턴의 예

모델 뷰 제어기 (Model View Controller) (MVC)

MVC 패턴

구분	내용
설명	시스템 데이터로부터 표현과 상호작용을 분리시켜 3개의 논리적 컴포넌트로 구조화- 모델: 데이터와 이에 대한 오퍼레이션을 관리- 뷰: 사용자에게 데이터를 표현하는 것을 관리- 제어기: 사용자와 상호작용을 관리하고 이를 뷰와 모델에 전달
언제 사용되는가	1. 데이터를 보여주고 상호 작용하는 방법이 여러 가지일 때 사용2. 데이터 표현과 상호작용에 대한 추후 요구사항을 알 수 없을 때
장점	1. 데이터 표현과 무관하게 데이터를 변경 가능하다.2. 동일한 데이터를 서로 다른 방법으로 표현하는 것을 지원한다.3. 뷰의 추가, 변경이 쉽다.
단점	1. 데이터 모델과 상호작용이 단순한 경우 불필요하게 코드가 복잡해질 수 있다.

계층 아키텍처

구분	내용
설명	각각의 기능을 계층으로 시스템을 구성한다. 각 계층은 상위 계층에 서비스를 제공한다.
언제 사용되는가	1. 새로운 기능을 기존 시스템 상에 구축할 경우2. 계층별로 나누어 여러 팀이 독립적으로 개발하는 경우3. 다중 수준 보안이 필요한 경우
장점	1. 인터페이스가 동일하다면 계층을 대체하는 것이 가능2. 시스템의 확실성을 높이기 위해 중복된 기능을 제공할 수 있다.
단점	1. 계층을 명확하게 구분하는 것이 어렵다.2. 바로 아래 계층을 통하지 않고 하위 계층을 사용해야 하는 경우도 존재3. 각 계층의 처리를 거치면서 성능이 저하되는 단점 존재

저장소 아키텍처

구분	내용
설명	시스템의 모든 데이터는 모든 시스템 컴포넌트들이 접근할 수 있는 중앙 저장소에 관리대량의 데이터를 사용하는 시스템은 공유 데이터베이스(저장소)를 중심으로 구성컴포넌트들을 직접 상호작용하지 않고 저장소를 통해서만 상호작용
언제 사용되는가	1. 장기간 저장되어야 하는 대량의 정보를 생성하는 시스템일 경우2. 저장소에 데이터 추가 시 어떤 행동이나 도구의 동작이 필요한 데이터 주도 시스템일 경우
특징	컴포넌트(도구)들을 저장소를 중심으로 배치1. 효율적으로 대량의 데이터를 공유2. 공통적인 저장소 데이터 모델(스키마)를 따라야 한다.
장점	1. 컴포넌들이 독립적이며 다른 컴포넌트들을 알 필요가 없다.2. 데이터가 일관성 있게 관리된다.
단점	1. 저장소가 단일 장애점 (Single point of Failure)이기에 저장소에 문제가 생기면 시스템 전체에 영향을 준다.2. 통신이 저장소에 집중되어 비효율적이다.

클라이언트-서버 아키텍처

구분	내용
설명	분산 네트워크 환경의 주요 아키텍처시스템이 각 서비스가 독립적인 서버에 의해 제공되는 서비스들의 집합으로 표현한다.
언제 사용되는가	1. 공유 데이터베이스에 있는 데이터를 여러 지역에서 접근해야 할 경우 사용한다.2. 서버는 중복이 가능하므로 시스템의 부하 변동이 클 경우에도 사용 가능
특징	클라이언트 서버 아키텍처를 구성하는 컴포넌트1. 서비스를 제공하는 서버(프로세스)의 집합2. 서비스를 요청하는 클라이언트(프로세스)의 집합3. 클라이언트와 서버를 연결하는 네트워크클라이언트와 서버 상호작용1. 클라이언트는 서버를 찾을 수 있어야 한다.2. 클라이언트는 HTTP, 원격 프로시저 호출 등의 프로토콜을 이용하여 서버에 서비스를 요청
장점	1. 서버가 네트워크 상에 분산이 가능하다.2. 분산 아키텍처이므로 서버 추가, 통합, 업그레이드가 쉽다.
단점	1. 각 서비스가 단일 장애점 (Single point of Failure)이므로 서비스 거부 공격 (DoS)에 취약하다.2. 네트워크에도 영향을 받기 때문에 성능을 예측하기 어렵다.

파이프 필터 아키텍처

구분	내용
설명	시스템에서 데이터 처리는 각 처리 컴포넌트 (Filter)가 분리, 한 가지 종류의 변환을 수행하도록 구성한다.입력 데이터를 기능적 변환 (Transformation)으로 처리하여 출력 데이터를 생성한다.데이터가 변환을 통해 흘러간다.변환은 순차적 또는 병렬적으로 실행한다.
언제 사용되는가	사용자 상호 작용이 제한되어 있는1. 일괄처리 시스템2. 임베디드 시스템
장점	1. 이해하기 쉽고 변환의 재사용을 지원한다.2. 워크 플로 유형은 다수의 비즈니스 프로세스 구조와 일치한다.3. 변환을 추가하여 기능을 변경하는 것이 쉽다.4. 순차적 혹은 병행 시스템으로 구현 가능하다.
단점	1. 시스템 부담을 증가시키며 호환되지 않는 데이터 구조를 사용하는 아키텍처 컴포넌트는 재사용이 불가능하다.2. 데이터를 주고 받는 변환 간에 데이터 형식이 일치해야 한다.

아키텍처 패턴 정리

아키텍처 패턴 목록

MVC (Model View Controller)

계층 아키텍처 (Layered Architecture)

저장소 아키텍처 (Repository Architecture)

클라이언트-서버 아키텍처 (Client-Server Architecture)

파이프 필터 아키텍처 (Pipe and Filter Architecture)

애플리케이션 아키텍처

•

비즈니스 또는 조직의 필요를 만족시키기 위한 것이다.

•

같은 유형의 시스템을 개발할 때 공통적인 아키텍처 구조가 재사용될 수 있다.

트랜잭션

원자성을 가지며 트랜잭션이 수행되면 트랜잭션 내 모든 작업들이 완료되어야 한다.

트랜잭션 처리 시스템

사용자 서비스 요청을 비동기적으로 처리하는 대화식 시스템

정보 시스템

사용자 인터페이스가 웹 브라우저로 구현된 웹 기반 시스템

정보 시스템 아키텍처

주로 다단 클라이언트-서버 아키텍처를 사용한다.