아키텍처 스타일

기존의 시스템이나 애플리케이션을 개발자가 아닌 다른 사람이 유지보수를 해야 하는 경우 서로 설계 방식이 달라 코드를 분석하는데 많은 어려움이 따름. 이를 해결하기 위해 많은 사람들과 신뢰 있는 기관에서 검증된 보편적인 설계 방법의 양식들을 사용하는데, 이것을 아키텍처 스타일이라고 함.

아키텍처 스타일에 있는 여러 설계 방식들을 아키텍처 모델이라고 부르며, 애플리케이션 개발 모델이라고도 부름

 

1. IEEE 1471

ANSI / IEEE 1471-2000의 약어로, 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 요소와 내용들, 이들 간의 관계를 규정하고 있는 국제 표준

- 특징

1) 표준화 : 아키텍처 관련 용어와 개념들을 통일함

2) 중립성 : 모델링 언어와 방법론을 제시하지 않고, 독립적인 메타모델을 제공

3) 유연성 : 표현을 위한 요소들과 관계의 일반화로 규모에 상관없이 시스템 구축에 적용 가능

4) 의사소통 : 이해당사자 간의 의사소통을 지원하고, 다양한 관점에서 표현

- 구성요소

1) Architectural Description(AD) : 시스템 구축 시 아키텍처가 기록되는 방법

2) Stakeholder : 소프트웨서 시스템 개발에 관련된 모든 이해 당사자를 의미 예) 고객, 개발자, 관리자, 마케터

3) Concerns : 시스템의 성능, 유지보수, 보안, 분배 등과 같은 Stakeholder들의 의견과 목표

4) View : Stakeholder들이 가지는 관점으로 전체 시스템을 표현하거나 묘사하는 방법

5) Viewpoint : View를 구성하기 위한 규칙을 정의하는 패턴으로, AD는 하나 이상의 Viewpoint를 선택하여 사용

 

2. 저장소 구조(Respository Architecture)

중앙자료구조(Central Data Structure)와 독립된 컴포넌트(Component)로 구성된 아키텍처. 큰 데이터의 이동 및 공유에 적합하며, 컴포넌트 간의 통신은 이뤄지지 않음

- 장점

1) 대량의 데이터를 저장하는데 효과적

2) 컴포넌트의 추가, 삭제가 편리

3) 중앙 집중화를 통해 데이터 관리가 용이하고, 보안적인 측면이 뛰어남

- 단점

1) 저장소에 오류가 발생하면 시스템 전체에 문제가 발생

2) 데어터의 분산이 어려움

 

3. MVC 구조(Model/View/Controller Architecture)

상호작용 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller)의 세 개의 컴포넌트로 구분하는 아키텍처로, 유저 인터페이스와 비즈니스 로직들을 서로 분리하여 개발하는 방법

- 구성요소

모델(Model)	- 애플리케이션의 핵심 기능을 포함 - 상태 변화 시 컨트롤러와 뷰에 전달
뷰(View)	- 정보 표시를 관리 - 결과물 생성을 위해 모델로부터 정보를 수신
컨트롤러(Controller)	- 사용자로부터 입력을 받아 모델과 뷰에 명령을 전달 - 모델에 명령을 전달해 상태를 변경하고, 뷰에 명령을 보내 표시 방법을 변경

 

- 장점

1) 동일한 모델에 대해 다양한 뷰를 제공

2) 효율적인 모듈화가 가능

3) 모델과 뷰의 구분으로 사용자 인터페이스에 대한 요구 사항을 적용시키는데 용이

- 단점

1) 간단한 애플리케이션에 적용하기에는 복잡

2) 모델이 자주 변경되는 경우 업데이트 요청이 많아 뷰의 갱신이 따라가지 못함

 

4. 클라이언트/서버 구조(Client/Server Architecture)

클라이언트(Client)와 서버(Server)로 나뉘는 아키텍처를 말하며 하나의 서버에 다수의 클라이언트가 접속하는 일대다 관계로 구성되며, 서버는 하나의 중앙 서버 또는 분산된 여러 서버가 존재할 수 있음

- 구성

1) 클라이언트 : 사용자로부터 입력을 받아 서버에 요청을 전달

2) 서버 : 수신된 요청을 수행하고, 데이터의 일관성을 유지

- 특징

1) 새로운 서버의 추가 및 업그레이드가 용이

2) 데이터가 서버에 집중되어 데이터 관리가 용이하고, 보안적인 측면이 뛰어남

3) 서버에 네트워크 트래픽과 데이터가 집중되어 처리 비용이 급증할 수 있음

 

5. 계층 구조(Layered Architecture)

계층적으로 조직화가 가능한 애플리케이션에 적합한 아키텍처. 각 계층이 특정 측면만을 전문적으로 다루기 때문에 응집력 있는 설계가 가능하여, 설계를 더욱 쉽게 이해할 수 있게 해 줌. 대표적으로 OSI 7 계층

- 상위 계층은 하위 계층의 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트의 입장

- 복잡한 문제를 점진적이고 순차적으로 분할하여 구현

- 인접 계층 사이에서만 요청과 응답이 이루어지며, 변경 사항을 적용할 때에도 두 개의 인접 계층에만 영향을 미쳐 원활한 변경이 가능

- 특정 계층만을 교체해 시스템을 개선하는 것이 가능하나, 동작이 변경될 경우 단계별 재작업 필요

- 구축 시 레이어의 적절한 개수나 규모를 결정하는 것에 어려움이 존재

 

6. 파이프 필터 구조(Pipes and Filters Architecture)

데이터의 흐름을 점진적으로 처리하는 시스템을 위한 아키텍처. 프로세싱을 위한 시스템이 각 필터에 캡슐화되어 있으며, 데이터는 인접 필터 사이의 파이프를 통해 전달되는 형태

- 각 필터들은 상호 독립적이며 자신 앞의 필터나 뒤에 있는 필터에 대한 정보를 알 수 없음

- 모든 데이터의 처리 순서는 파이프 구조와 각각의 필터를 통해 조정 가능한 이벤트에 의해 통제

- 장점

1) 설계자는 몇 개의 필터들을 간단히 조합하여 시스템의 입, 출력 행위를 이해할 수 있음

2) 새로운 필터를 기존의 구조에 추가하거나 통합하는 것이 가능

3) 각 필터의 독립적인 구조로 인해 다양한 시스템에 적용할 수 있는 재사용성을 가짐

4) 각 필터들의 독립적인 수행이 가능해 동시 수행(Concurrency)으로 효율 증진을 노릴 수 있음

5) 응답성(throughput)이나 데드락(deadlock)과 같은 특수한 분석들을 지원

- 단점

1) 상태 정보를 공유하는데 유연하지 못함

2) 각 필터 간 공통된 특성이 적어 각 필터가 전송받은 데이터를 다시 파싱(Parsing) 해야 하는 경우가 발생할 수 있음