[정보처리기사 실기] 아키텍처 스타일

아키텍처 스타일

---

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

IEEE 1471

---

ANSI / IEEE 1471-2000의 약어

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

특징

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

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

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

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

구성요소

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

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

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

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

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

저장소 구조(Repository Architecture)

---

중앙자료구조(Central Data Structure)와 독립된 컴포넌트(Component)로 구성된 아키텍처

큰 데이터의 이동 및 공유에 적합, 컴포넌트간의 통신은 이뤄지지 않음

장점

• 대량의 데이터를 저장하는데 효과적
• 컴포넌트의 추가 · 삭제가 편리
• 중앙 집중화를 통해 데이터 관리가 용이, 보안적인 측면이 뛰어나다

단점

• 저장소에 오류가 발생하면 시스템 전체에 문제가 발생
• 데이터의 분산이 어려움

MVC 구조(Model / View / Controller Architecture)

---

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

구성요소

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

장점

• 동일한 모델에 대해 다양한 뷰를 제공
• 효율적인 모듈화가 가능
• 모델과 뷰의 구분으로 사용자 인터페이스에 대한 요구 사항을 적용시키는데 용이

단점

• 간단한 애플리케이션에 적용하기에는 복잡
• 모델이 자주 변경되는 경우 업데이트 요청이 많아 뷰의 갱신이 따라가지 못함

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

---

클라이언트와 서버로 나뉘는 아키텍쳐를 말함

하나의 서버에 다수의 클라이언트가 접속하는 일대다 관계로 구성

서버는 하나의 중앙 서버 또는 분산된 여러 서버가 존재할 수 있음

구성

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

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

특징

• 새로운 서버의 추가 및 업그레이드가 용이
• 데이터가 서버에 집중되어 데이터 관리가 용이, 보안적인 측면이 뛰어남
• 서버에 네트워크 트래픽과 데이터가 집중되어 처리 비용이 급증할 수 있음

계층 구조(Layered Architecture)

---

계층적으로 조직화가 가능한 애플리케이션에 적합한 아키텍처

각 계층이 특정 측면만을 전문적으로 다루기 때문에 응집력 있는 설계가 가능

설계를 더욱 쉽게 이해할 수 있게함. 대표적으로는 OSI 7계층이 있음

• 상위 계층은 하위 계층의 서비스 제공자가 되고, 하위 계층은 사위 계층의 클라이언트의 입장에 섬
• 복잡한 문제를 점진적이고 순차적으로 분할하여 구현할 수 있음
• 특정 계층만을 교체해 시스템을 개선하는 것이 가능하나, 동작이 변경될 경우 단계별 재작업이 필요
• 구축 시 레이어의 적절한 개수나 규모를 결정하는 것에 어려움이 있음

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

---

데이터의 흐름을 점진적으로 처리하는 시스템을 위한 아키텍처

프로세싱을 위한 시스템이 각 필터에 캡슐화 되어 있으며, 데이터는 인접 필터 사이의 파이프를 통해 전달되는 형태

• 각 필터들은 상호 독립적이며 자신 앞의 필터나 뒤에 있는 필터에 대한 정보를 알 수 없움
• 모든 데이터의 처리 순서는 파이프 구조와 가각의 필터를 통해 조정 가능한 이벤트에 의해 통제됨

장점 

• 설계자는 몇 개의 필터들을 간단히 조합하여 시스템의 입 · 출력 행위를 이해할 수 있음
• 새로운 필터를 기존의 구조에 추가하거나 통합하는 것이 간으
• 각 필터의 독립적인 구조로 인해 다양한 시스템에 적용할 수 있는 재사용성을 가짐
• 각 필터들의 독립적인 수행이 가능해 동시 수행(Concurrency)으로 효율증진을 노릴 수 있음
• 응답성(throughput)이나 데드락(deadlock)과 같은 특수한 분석들을 지원

응답성(throughput)

지정된 시간동안 처리할 수 있는 데이터의 양

데드락(Deadlock)

둘 이상의 프로세스가 자원의 한계로 인해 처리되지 못하고 대기해 있는 상태

파싱(parsing)

입력 데이터를 시스템 구조에 맞게 분석 및 해부하는 과정

단점

• 상태 정보를 공유하는데 유연하지 못함
• 각 필터 간 공통된 특성이 적어 각 필터가 전송받은 데이터를 다시 파싱(Parsing)해야 하는 경우가 발생할 수 있음