아키텍처
아키텍처는 주로 건축에서 사용되는 말로 건물의 뼈대와 특성을 결정짓는 기본 구조를 의미합니다.
소프트웨어 개발에서 아키텍처는 소프트웨어의 기본 골격이 되는 구조로 시스템 전체에 대한 밑그림을 의미하게 됩니다.
아키텍처의 특징은 다음과 같습니다.
- 소프트웨어의 골격을 나타내는 추상화된 전체 구조를 제공한다.
- 소프트웨어를 이루는 여러 구성 요소들을 다룬다.
- 인터페이스를 통해 소프트웨어의 구성 요소가 어떻게 상호작용하는지를 정의한다.
- 세부 내용보다는 중요 내용만을 다룬다.
- 설계에 적용되는 원칙과 지점이 있다.
아키텍처가 제대로 설계된 소프트웨어는 사용자의 요구사항을 충분히 만족시키고 프로그램의 완성도를 올리며 유지보수를 쉽게 만들어줍니다.
아키텍처를 옳바르게 설계하기 위한 조건은 다음과 같습니다.
- 모든 이해관계자 사이의 의사소통 도구로 사용될 수 있어야한다.
- 구현에 대한 제약 사항을 정의해야 한다.
- 모든 이해관계자의 품질 요구사항을 반영해 우선순위에 따라 시스템 품질 속성을 결정한다.
- 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용이 가능하게 설계한다.
아키텍처의 품질 속성
이해관계자들의 요구사항을 반영해 품질 속성을 결정합니다. 품질 속성에는 사용성, 이식성, 유지보수 용이성 등이 포함됩니다.
다양한 기관에서 품질 속성에 대한 내용을 정의하고 있습니다. 그 중에서 SEI의 SAiP에서 정의한 품질 속성 세 가지를 소개하면 다음과 같습니다.
시스템 품질 속성
-
가용성
가용성은 시스템 실패 없이 시스템이 운용될 수 있는 확률입니다. 즉, 서비스가 장애 발생 없이 서비스를 할 수 있는 능력을 의미합니다. -
변경 용이성
변경 용이성은 사용자가 새로운 요구사항을 요청했을 때 얼마나 쉽게 변경할 수 있는지를 의미합니다. -
성능
성능은 이벤트가 발생했을 때 얼마나 빠르고 효율적으로 이벤트를 처리하는지를 의미합니다. -
보안성
보안성은 허용되지 않는 접근에 대해 대응하는 능력을 의미합니다. 승인되지않은 접근 차단, 외부 공격 감지와 회피 등의 기능을 필요로합니다. -
사용성
사용성은 시스템을 사용할 때 발생할 수 있는 여러 상황을 극복할 수 있도록 설계하는 것을 의미합니다. 시스템에서 도움말을 제공하거나 사용자가 사용하기 쉽게 사용할 수 있도록 설계하는 것을 말합니다. -
테스트 용이성
테스트 용이성은 테스트가 얼마나 효과적으로 수행되고 시간을 단축할 수 있는지 등을 의미합니다.
비즈니스 품질 속성
-
시장 적시성
시장 적시성은 적정한 시기에 소프트웨어를 출시하여 경쟁력을 높이는 것을 의미합니다. 먼저 출시할수록 경쟁자보다 우위를 점할 수 있습니다. -
비용과 이익
비용과 이익은 비용을 많이 들여서 유연한 설계를 할 것인지, 비용을 줄여 이익을 높일지 결정하는 것을 의미합니다. -
예상 시스템 수명
설계 단계에서 시스템 사용 수명을 예측해 반영해야합니다. 이때 확장성, 이식성과 같은 요소를 고려해 설계합니다. -
목표 시장
목표 시장을 설정하면 경쟁 제품과 비교했을 때 기능성이 매우 중요해집니다. 그리고 이식성 또한 중요하게 고려해야합니다. -
신규 발매 일정
일정은 비즈니스적 관점에서 매우 중요한 요소입니다. 일정을 맞추기 위해 유연성과 확장성을 잘 설계해야합니다. -
기존 시스템과의 통합
기존 시스템과 통합할 필요가 있는 경우 기존 시스템에 대한 특성을 잘 알아두어야합니다.
아키텍처 품질 속성
-
개념적 무결성
개념적 무결성은일관성이라고도 표현합니다. 전체 시스템과 그 구성 요소가 일관되도록 구성해야합니다. -
정확성과 완전성
정확성과 완전성은 사용자가 요구하는 기능을 얼마나 충족시키는 가를 의미합니다. -
개발 용이성
개발 용이성은 구축 가능성이라고도 부르며, 전체 시스템을 적절한 모듈로 분할하고 개발해 일정에 맞출 수 있는가와 개발 도중 쉽게 변경할 수 있는 지에 대한 능력을 의미합니다.
4 + 1 아키텍처 관점
4 + 1은 아키텍처를 설명하고 검토하는데 사용되는 대표적인 모델입니다.
이미지 출처
4 + 1 모델은 문제 영역의 시나리오 관점 하나와 해법 영역의 논리적, 프로세스, 개발, 물리적 관점 네 가지로 구성되어 있습니다.
시나리오 관점
시나리오 관점은 최종 사용자가 인식하는 시스템의 기능을 의미합니다. 즉, 시스템이 사용자에게 제공하는 기능에 주목을 합니다.
시나리오 관점은 유스케이스 다이어그램(정적 표현)과 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램(동적 표현)으로 표현됩니다.
논리적 관점
논지거 관점은 시스템 내부를 들여다 보는 관점입니다. 시스템의 기능을 제공하기 위한 클래스나 컴포넌트, 이들의 관계에 주목을 합니다.
논리적 관점은 클래스 다이어그램, 객체 다이어그램(정적 표현)과 상태 다이어그램, 순차-통신 다이어그램, 활동 다이어그램(동적 표현)으로 표현됩니다.
프로세스 관점
프로세스 관점은 실제 구동 환경을 살펴보고 시스템 내부의 구조(관계, 동작, 상호작용)에 주목합니다. 다만 논리적과 다르게 모든 클래스에 집중하는 것이 아닌 독자적으로 제어하는 스레드가 있는 클래스에 집중을 합니다.(시스템의 동시성과 동기화)
프로세스 관점은 논리적 관점에 동일한 방식으로 표현하지만 프로세스와 스레드를 같이 기술하여 시스템의 성능이나 확장성, 효율도 함께 표현합니다.
개발 관점
개발 관점은 서브시스템의 모듈이 어떤 관계를 갖고 설계와 어떻게 연결되는지에 주목을 합니다.
개발 관점은 컴포넌트 다이어그램(정적 표현), 상태 다이어그램, 순차-통신 다이어그램, 활동 다이어그램(동적 표현)으로 표현합니다.
물리적 관점
물리적 관점은 시스템을 구성하는 처리 장치 간의 물리적 배치에 주목합니다.
물리적 관점은 배치 다이어그램(정적 표현), 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램(동적 표현)으로 표현합니다.
아키텍처 스타일
아키텍처를 설계하는데에도 여러 스타일이 있습니다. 기능의 분할/배치에 주목을한 데이터 중심형, 클라이언트-서버, 계층, MVC 스타일와 제어 관계에 집중한 데이터 흐름 스타일이 있습니다.
아키텍처 스타일을 사용하면 다음과 같은 장점이 있습니다.
- 개발 기간 단축과 고품질 소프트웨어 생산
- 수월한 의사소통
- 용이한 유지보수
- 검증된 아키텍처
- 구축 전 시뮬레이션
- 기존 시스템에 대한 빠른 이해
데이터 중심형 스타일
데이터 중심형 스타일은 주요 데이터를 리포지토리(repository)라고 하는 중앙 공간에서 관리됩니다. 따라서 이 스타일에서는 중앙에 리포지토리가 있고 시스템들이 중앙에 접근하는 방식으로 설계됩니다.
데이터 중심형 스타일은 데이터가 모순되지 않고 일관성 있게 관리할 수 있습니다. 그리고 서브시스템의 추가도 쉽다는 장점이 있습니다. 하지만 리포지토리 병목 현상이나 리포지토리의 변경이 서브시스템에 영향을 줄 수 있다는 단점이 있습니다.
클라이언트-서버 스타일
클라이언트-서버 스타일은 네트워크를 이용해 분산 시스템 형태로 데이터와 처리 기능을 클라이언트와 서버에 분할하여 사용하는 스타일입니다. 서브시스템의 요청에 따라 서로 상호작용을 합니다.
서버는 클라이언트에 서비스를 제공하는 역할로 요청을 처리하기 위해 대기합니다. 클라이언트는 사용자와의 대화를 위해 서버가 제공하는 서비스를 요청하는 시스템입니다.
계층 스타일
계층 스타일은 시스템의 기능을 몇 개의 계층들로 나누어 배치하는 스타일입니다. 예를들어 UI층, 비즈니스 로직층, DB층과 같은 방식으로 나눕니다. 하위 계층을 서버로 사용하고 상위 계층을 클라이언트 역할을 하도록 구성하게 됩니다.
각 계층의 응집도가 높고 결합도가 낮아 재사용성과 유지보수성이 좋고, 계층간 분담이 확실해 변경도 쉽습니다.
MVC 스타일
MVC 스타일은 Model, View, Control 세 부분으로 구성되는 스타일입니다. 사용자 인터페이스의 뷰와 로직을 처리하는 모델 이들을 제어하는 컨트롤을 분리하여 서로에 대한 영향이 최소화 됩니다.
데이터 흐름 스타일
데이터 흐름 스타일은 필터와 파이프라는 존재를 두는 스타일 입니다. 필터는 하나의 데이터를 받으면 처리하고 그 결과를 다음 서브시스템으로 보내는 작업을 반복합니다. 파이프는 필터를 거쳐낸 데이터를 다른 필터의 입력부에 연결하는 작업을 수행합니다.
