[정보처리기사] 아키텍처 패턴

 레이어 패턴

- 각각의 서브시스템들이 계층(Layer)구조를 이룸

- 상위계층은 하위계층에 대한 서비스제공자, 하위계층은 상위계층의 클라이언트

- 서로 마주보는 두계의 계층 사이에서만 상호작용

- 특정 계층만을 교체해 시스템 개선이 가능

- ex) OSI 참조모델

 

 

클라이언트-서버 패턴

- 하나의 서버 컴포넌트+ 다수의 클라이언트 컴포넌트

- 사용자 <-> 클라이언트 <-> 서버

- 서버는 클라이언트 요청에 대비해서 항상 대기상태

- 클라이언트나 서버는 요청-응답때문에 동기화 되는 경우 제외하고는 독립적

 

 

파이프-필터 패턴

- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴(??)

{소스} ---파이프---> [필터] ---파이프---> [필터] ---파이프---> {sink}

- 필터는 재사용성과 추가가 쉬워서 확장이 용이

- 필터 재배치하여 다양한 파이프라인 구축 가능

- 데이터 변환, 버퍼링, 동기화 등에 주로 사용

- ex) unix 쉘

 

 

MVC 패턴

- 3개의 부분으로 구조화

- 모델: 서브 시스템의 핵심 기능과 데이터 보관

- 뷰: 사용자에게 정보 표시

- 컨트롤러: 사용자로부터 받은 입력 처리

- 각 부분은 별도의 컴포넌트로 분리, 서로 영향 없이 개발 가능

- 여러개의 뷰를 만들 수 있음 -> 대화형APP에 적합

 

 

마스터-슬레이브 패턴

- 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할 -> 슬레이브에서 처리된 결과물 다시 돌려받음

- 마스터: 모든 작업의 주체

- 슬레이브: 마스터의 지시에 따라 작업 수행, 반환

- ex) 장애 허용 시스템, 병렬 컴퓨팅 시스템

 

 

브로커 패턴

- 사용자가 원하는 서비스를 브로커에 요청 -> 브로커가 요청에 맞는 컴포넌트와 사용자를 연결

- ex) 분산 환경 시스템

 

 

피어-투-피어 패턴

- 피어를 하나의 컴포넌트로 간주

- 피어는 클라이언트가 될 수도, 서버가 될 수도 있음

- 클라이언트와 서버는 전형적인 멀티스레딩 방식 사용

 

 

이벤트-버스 패턴

- 소스가 특정 채널에 이벤트 메시지 발행(publish) -> 채널 구독한 리스너들이 메시지 받아서 이벤트 처리

- 4가지 주요 컴포넌트: 소스, 리스너, 채널(통로), 버스(채널관리)

 

 

블랙보드 패턴

- 모든 컴포넌트들 -> 공유데이터 저장소, 블랙보드 컴포넌트에 접근 가능

- 검색을 통해 블랙보드에서 데이터 찾기 가능

- 해결책이 명확하지 않은 문제에서 유용

- ex) 음성 인식, 차량 식별, 신호 해석

 

 

인터프리터 패턴

- 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성

- 특정언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계 시 유리