POSA(GoF 디자인패턴외)
태그 :
I. POSA 개요
가. POSA(Pattern-Oriented Software Architecture) 특징
- 1996년에 ‘Pattern-Oriented Software Architecture, Volume 1: A System of Patterns’ 출간 이후 2007년 ‘POSA 5’에 해당하는 ‘Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages 발간으로 모두 다섯 권 분량
- ‘패턴(pattern) 자체’에 대해 다룰 뿐만 아니라 ‘소프트웨어 아키텍처(software architecture)를 위한 패턴’도 다루고 있음
- GoF 디자인 패턴은 디자인 수준의 패턴에 집중하고 있는 반면, POSA는 ‘상위 수준(high-level)의 아키텍처 패턴’, ‘디자인 패턴’, ‘하위 수준(low-level)의 이디엄(idiom)’까지 아우름
- 패턴 시스템: 추상적인 기준에 따라 성격이 다른 상위 항목 아래에 여러 패턴을 모아두지 않고, 구체적인 기준에 따라 패턴들을 분류
- 상호작용 시스템(interactive system), 적응 시스템(adaptable system), 작업 조직화(organization of work), 통신(communication), 액세스 제어(access control) 등 좀 더 기술적 기준에 따라 세분하여 패턴을 분류
나. POSA 구성도
II. POSA 패턴 종류
가. 아키텍처 패턴
- 소프트웨어 시스템의 기본 구조를 구성하기 위한 스키마를 다룸
- 미리 정의된 서브시스템들을 제공하고 각 서브시스템들의 책임을 정의하며 서브시스템들간의 관계를 조직화하는 규칙과 가이드라인을 포함
- 구체적인 소프트웨어 아키텍처를 위한 템플릿(template) 역할
- 애플리케이션의 시스템 전체 구조의 특성(property)을 정의하고 서브시스템들의 아키텍처에 영향을 미침
구분 |
유형 |
설명 |
혼돈에서 질서 |
Layers 아키텍처 패턴 |
- 애플리케이션을 구조화 하기 위해 서브 태스크(Subtask)들을 그룹으로 묶기 위해 분해 - 공통된 추상 레벨에 있는 서브 테스크들끼리 묶어서 그룹으로 분류 - 적용 예: OSI 7 Layer, DB와 OS |
Pipes and Filters 아키텍처 패턴 |
- 데이터 스트림을 처리하는 시스템 구조를 제공 - 각 프로세싱 단계는 필터 컴포넌트로 추상화 - 데이터는 파이프를 통해 연관된 필터들에게 전달됨 - 필터들을 다양하게 재조합하여 시스템을 재구축 할 수 있음 |
|
Blackboard 아키텍처 패턴 |
- 정의되지 않은 도메인에서의 문제를 해결할 때 유용 - 솔루션에 대한 부분적이거나 대략적인 해법을 수립하기 위해 몇 가지 특수한 서브시스템들의 지식을 조합 |
|
분산 시스템 |
Broker 아키텍처 패턴 |
- 분산 소프트웨어 시스템을 구조화 할 때 유용 - 분산 소프트웨어 시스템은 분리된 컴포넌트들이 서로 유기적으로 조합되어 운영되는 시스템으로, 이러한 컴포넌트들 간의 통신을 관장하는 역할을 Broker가 수행 |
상호작용 시스템 |
Model-View-Controller 아키텍처 패턴 |
- Model: 핵심기능과 데이터를 의미 - View: 기능에 의한 데이터의 표현 - Controller: 사용자의 입력에 대한 처리 - View와 Controller는 사용자의 인터페이스를 구성하며, 사용자 인터페이스와 Model간의 일관성 및 정합성을 보장 |
Presentation-Abstraction-Control 아키텍처 패턴 |
- 계층구조를 이루는 에이전트들이 상호작용하는 소프트웨어 시스템에 대한 패턴 - 각각의 에이전트는 하나의 애플리케이션의 특정 부분을 전담하며 에이전트는 프리젠테이션, 추상, 컨트롤로 구성됨 |
|
적응 시스템 |
Microkernel 아키텍처 패턴 |
- 변화하는 시스템에 대한 요구사항을 수용할 수 있도록 하는 패턴 - 시스템에서 가장 최하단에 위치하는 핵심기능을 추출 - 추가된 요구사항에 대해 확장기능으로 정의하여 시스템에 손쉽게 추가할 수 있도록 함 |
Reflection 아키텍처 패턴 |
- 소프트웨어 시스템의 구조와 동작을 동적으로 변경할 수 있는 메커니즘을 제공 |
나. 디자인 패턴
- 소프트웨어 시스템의 서브시스템들이나 컴포넌트들, 혹은 그것들 간의 관계를 정의하기 위한 스키마를 제공
- 특정 정황 내에서 일반적인 설계 문제를 해결하며, 통신하는 컴포넌트들 간의 반복적으로 발생하는 구조를 서술
- 중간 규모(medium-scale)의 패턴으로 아키텍처 패턴보다 규모면에서는 작지만, 특정 프로그래밍 언어나 프로그래밍 패러다임이 종속되는 경향을 나타내지는 않음
- 즉, 프로그래밍 언어나 프로그래밍 패러다임에 독립적임
- 특정 디자인 패턴을 응용할 경우, 소프트웨어 시스템의 기본 구조에 영향을 미치지는 않지만 서브시스템의 아키텍처에는 상당한 영향력을 미칠 수 있음
구분 |
유형 |
설명 |
구조 분해 |
Whole-Part 디자인 패턴 |
- 전체(Whole) 객체를 구성하는 컴포넌트(Part)를 정의 - Whole 객체를 통해 Part 컴포넌트들의 관계를 맺으며, 이 Whole 객체를 통해서만 Part 컴포넌트와 통신 가능 |
작업 조직화 |
Master-Slave 디자인 패턴 |
- 마스터 컴포넌트는 슬레이브 컴포넌트에게 작업을 분산시켜 최종적으로 슬레이브로부터 그 결과를 취합 |
액세스 제어 |
Proxy 디자인 패턴 |
- 실제 컴포넌트가 아닌 대리자를 앞단에 두어 이 대리자를 통해 실제 컴포넌트와 통신 - 실제 컴포넌트의 위치 추상화, 인증 등의 전처리, 후처리에 대한 기능 추가 용이 |
관리 |
Command Processor 디자인 패턴 |
- 사용자의 요청을 하나의 객체로 정의하여 관리하며, Undo/Redo와 같은 처리가 가능 |
View Handler 디자인 패턴 |
- 시스템의 모든 뷰를 관리하는 책임을 분리하여 뷰들 간의 관계성과 연관된 작업을 쉽게 처리할 수 있도록 함 |
|
통신 |
Forwarder-Receiver 디자인 패턴 |
- 분산 시스템의 컴포넌트와 통신을 위해 사용하는 메커니즘 간 결합도를 낮추는 방법으로 캡슐화 역할을 함 - 투명한 IPC를 제공하고 Peer를 분리하기 위해 Forwarder와 Receiver를 분리 |
Client-Dispatcher-Server 디자인 패턴 |
- 클라이언트와 서버 사이에 디스패처 레이어를 도입 - 위치 투명성을 제공하고 클라이언트와 서버 간의 통신에 대한 세부적인 구현을 캡슐화 함 |
|
Publisher-Subscriber 디자인 패턴 |
- 서로 긴밀하게 관계를 맺고 있는 컴포넌트들 간의 상태에 대해 정합성을 유지하는데 용이 - Publisher가 책임을 지고 하나의 변경에 대해 다수의 Subscriber에게 변경을 통지 |
다. 이디엄
- 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴(low-level pattern)
- 주어진 언어의 기능을 사용해서 컴포넌트들 혹은 컴포넌트들 간 관계의 특정 측면을 구현하는 방법을 서술
- 하위 레벨 패턴을 표현하여 설계(design)와 구현(implementation)의 두 가지 측면을 해결
- 대부분의 이디엄은 특정 언어에 국한되어 있기 때문에 기존 프로그래밍 경험으로부터 유래
- 종종 동일한 이디엄이 서로 다른 프로그래밍 언어마다 다르게 나타나기도 하고, 때로는 하나의 이디엄이 특정 프로그래밍 언어에서는 유용하지만 다른 프로그래밍 언어에서는 유용하지 않은 경우도 있음