의견.png

"아키텍처패턴"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(특징)
11번째 줄: 11번째 줄:
 
* '''이벤트-버스 패턴''' (Event-bus pattern) : 이 패턴은 주로 이벤트를 처리하며 이벤트 소스 (event source), 이벤트 리스너 (event listener), 채널 (channel) 그리고 이벤트 버스 (event bus)의 4가지 주요 컴포넌트들을 갖는다. 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행하며 (publish), 리스너는 특정 채널에서 메시지를 구독한다 (subscribe). 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받는다.
 
* '''이벤트-버스 패턴''' (Event-bus pattern) : 이 패턴은 주로 이벤트를 처리하며 이벤트 소스 (event source), 이벤트 리스너 (event listener), 채널 (channel) 그리고 이벤트 버스 (event bus)의 4가지 주요 컴포넌트들을 갖는다. 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행하며 (publish), 리스너는 특정 채널에서 메시지를 구독한다 (subscribe). 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받는다.
 
* '''모델-뷰-컨트롤러 패턴''' (Model-view-controller pattern. '''MVC''') : MVC 패턴이라고도 하는 이 패턴은 대화형 애플리케이션 (interactive application)을 다음의 3 부분으로 나눈다.
 
* '''모델-뷰-컨트롤러 패턴''' (Model-view-controller pattern. '''MVC''') : MVC 패턴이라고도 하는 이 패턴은 대화형 애플리케이션 (interactive application)을 다음의 3 부분으로 나눈다.
:모델 (model) — 핵심 기능과 데이터를 포함한다
+
  모델 (model) — 핵심 기능과 데이터를 포함한다
:뷰 (view) — 사용자에게 정보를 표시한다 (하나 이상의 뷰가 정의될 수 있음)
+
  뷰 (view) — 사용자에게 정보를 표시한다 (하나 이상의 뷰가 정의될 수 있음)
:컨트롤러 (controller) — 사용자로부터의 입력을 처리한다
+
  컨트롤러 (controller) — 사용자로부터의 입력을 처리한다
이는 정보가 사용자에게 제공되는 방식과 사용자로부터 받아 들여지는 방식에서 정보의 내부적인 표현을 분리하기 위해 나뉘어진다. 이는 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능케한다.
+
:이는 정보가 사용자에게 제공되는 방식과 사용자로부터 받아 들여지는 방식에서 정보의 내부적인 표현을 분리하기 위해 나뉘어진다. 이는 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능케한다.
 
* '''블랙보드 패턴''' (Blackboard pattern) : 이 패턴은 결정 가능한 해결 전략이 알려지지 않은 문제에 유용하다. 이 패턴은 3가지 주요 컴포넌트로 구성된다.
 
* '''블랙보드 패턴''' (Blackboard pattern) : 이 패턴은 결정 가능한 해결 전략이 알려지지 않은 문제에 유용하다. 이 패턴은 3가지 주요 컴포넌트로 구성된다.
:블랙보드 (blackboard) — 솔루션의 객체를 포함하는 구조화된 전역 메모리
+
  블랙보드 (blackboard) — 솔루션의 객체를 포함하는 구조화된 전역 메모리
:지식 소스 (knowledge source) — 자체 표현을 가진 특수 모듈
+
  지식 소스 (knowledge source) — 자체 표현을 가진 특수 모듈
:제어 컴포넌트 (control component) — 모듈 선택, 설정 및 실행을 담당한다
+
  제어 컴포넌트 (control component) — 모듈 선택, 설정 및 실행을 담당한다
모든 컴포넌트는 블랙보드에 접근한다. 컴포넌트는 블랙보드에 추가되는 새로운 데이터 객체를 생성할 수 있다. 컴포넌트는 블랙보드에서 특정 종류의 데이터를 찾으며, 기존의 지식 소스와의 패턴 매칭으로 데이터를 찾는다.
+
:모든 컴포넌트는 블랙보드에 접근한다. 컴포넌트는 블랙보드에 추가되는 새로운 데이터 객체를 생성할 수 있다. 컴포넌트는 블랙보드에서 특정 종류의 데이터를 찾으며, 기존의 지식 소스와의 패턴 매칭으로 데이터를 찾는다.
 
* '''인터프리터 패턴''' (Interpreter pattern) : 이 패턴은 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용된다. 이는 주로 특정 언어로 작성된 문장 혹은 표현식이라고 하는 프로그램의 각 라인을 수행하는 방법을 지정한다. 기본 아이디어는 언어의 각 기호에 대해 클래스를 만드는 것이다.
 
* '''인터프리터 패턴''' (Interpreter pattern) : 이 패턴은 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용된다. 이는 주로 특정 언어로 작성된 문장 혹은 표현식이라고 하는 프로그램의 각 라인을 수행하는 방법을 지정한다. 기본 아이디어는 언어의 각 기호에 대해 클래스를 만드는 것이다.
 
<ref name='ap_synopsis'>minigrammer,〈[https://mingrammer.com/translation-10-common-software-architectural-patterns-in-a-nutshell/]〉, 2017년 9월 10일</ref>
 
<ref name='ap_synopsis'>minigrammer,〈[https://mingrammer.com/translation-10-common-software-architectural-patterns-in-a-nutshell/]〉, 2017년 9월 10일</ref>

2020년 8월 12일 (수) 10:28 판

아키텍처 패턴(architectural pattern)은 주어진 문맥 안에서 소프트웨어 아키텍처의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책을 의미한다.아키텍처 패턴은 소프트웨어 디자인 패턴과 비슷하지만 더 넓은 범위에 속한다. 아키텍처 패턴은 소프트웨어 공학의 다양한 문제를 해결하는데, 예를 들어 컴퓨터 하드웨어 성능 제한, 비즈니스 위험의 최소화와 고가용성을 들 수 있다. 일부 아키텍처 패턴은 소프트웨어 프레임워크 안에 구현되어 있다.[1]

특징

소프트웨어 아키텍처 패턴은 다음과 같이 10가지로 구성되며 각각의 특징을 가지고 있다.

  • 계층화 패턴(Layered pattern) : 계층화 패턴은 하나의 프로그램을 그룹 또는 서브 프로그램으로 계층화(구조화) 하기 위한 패턴이며, 각 계층은 추상화 개념을 가진다. 그리고 또한 각 계층은 상위계층에 서비스를 제공한다.
  • 클라이언트-서버 패턴(Client-server pattern) : 이 패턴은 하나의 서버와 다수의 클라이언트, 두 부분으로 구성된다. 서버 컴포넌트는 다수의 클라이언트 컴포넌트로 서비스를 제공한다. 클라이언트가 서버에 서비스를 요청하면 서버는 클라이언트에게 적절한 서비스를 제공한다. 또한 서버는 계속 클라이언트로부터의 요청을 대기한다.
  • 마스터-슬레이브 패턴 (Master-slave pattern) : 이 패턴은 마스터와 슬레이브, 두 부분으로 구성된다. 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산하고, 슬레이브가 반환한 결과값으로부터 최종 결과값을 계산한다.
  • 파이프-필터 패턴 (Pipe-filter pattern) : 이 패턴은 데이터 스트림을 생성하고 처리하는 시스템에서 사용할 수 있다. 각 처리 과정은 필터 (filter) 컴포넌트에서 이루어지며, 처리되는 데이터는 파이프 (pipes)를 통해 흐른다. 이 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있다.
  • 브로커 패턴(Broker pattern) : 이 패턴은 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용된다. 이 컴포넌트들은 원격 서비스 실행을 통해 서로 상호 작용을 할 수 있다. 브로커 (broker) 컴포넌트는 컴포넌트 (components) 간의 통신을 조정하는 역할을 한다.
  • 피어 투 피어 패턴 (Peer-to-peer pattern) : 이 패턴에서는, 각 컴포넌트를 피어 (peers)라고 부른다. 피어는 클라이언트로서 피어에게 서비스를 요청할 수도 있고, 서버로서 각 피어에게 서비스를 제공할 수도 있다. 피어는 클라이언트 또는 서버 혹은 둘 모두로서 동작할 수 있으며, 시간이 지남에 따라 역할이 유동적으로 바뀔 수 있다.
  • 이벤트-버스 패턴 (Event-bus pattern) : 이 패턴은 주로 이벤트를 처리하며 이벤트 소스 (event source), 이벤트 리스너 (event listener), 채널 (channel) 그리고 이벤트 버스 (event bus)의 4가지 주요 컴포넌트들을 갖는다. 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행하며 (publish), 리스너는 특정 채널에서 메시지를 구독한다 (subscribe). 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받는다.
  • 모델-뷰-컨트롤러 패턴 (Model-view-controller pattern. MVC) : MVC 패턴이라고도 하는 이 패턴은 대화형 애플리케이션 (interactive application)을 다음의 3 부분으로 나눈다.
 모델 (model) — 핵심 기능과 데이터를 포함한다
 뷰 (view) — 사용자에게 정보를 표시한다 (하나 이상의 뷰가 정의될 수 있음)
 컨트롤러 (controller) — 사용자로부터의 입력을 처리한다
이는 정보가 사용자에게 제공되는 방식과 사용자로부터 받아 들여지는 방식에서 정보의 내부적인 표현을 분리하기 위해 나뉘어진다. 이는 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능케한다.
  • 블랙보드 패턴 (Blackboard pattern) : 이 패턴은 결정 가능한 해결 전략이 알려지지 않은 문제에 유용하다. 이 패턴은 3가지 주요 컴포넌트로 구성된다.
 블랙보드 (blackboard) — 솔루션의 객체를 포함하는 구조화된 전역 메모리
 지식 소스 (knowledge source) — 자체 표현을 가진 특수 모듈
 제어 컴포넌트 (control component) — 모듈 선택, 설정 및 실행을 담당한다
모든 컴포넌트는 블랙보드에 접근한다. 컴포넌트는 블랙보드에 추가되는 새로운 데이터 객체를 생성할 수 있다. 컴포넌트는 블랙보드에서 특정 종류의 데이터를 찾으며, 기존의 지식 소스와의 패턴 매칭으로 데이터를 찾는다.
  • 인터프리터 패턴 (Interpreter pattern) : 이 패턴은 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용된다. 이는 주로 특정 언어로 작성된 문장 혹은 표현식이라고 하는 프로그램의 각 라인을 수행하는 방법을 지정한다. 기본 아이디어는 언어의 각 기호에 대해 클래스를 만드는 것이다.

[2]


각주

  1. 위키백과,〈[1]
  2. minigrammer,〈[2]〉, 2017년 9월 10일

참고자료

  • 위키백과,〈[3]
  • minigrammer,〈[4]〉, 2017년 9월 10일

같이 보기


  의견.png 이 아키텍처패턴 문서는 프로그래밍에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.