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)의 두 가지 측면을 해결

-  대부분의 이디엄은 특정 언어에 국한되어 있기 때문에 기존 프로그래밍 경험으로부터 유래

-  종종 동일한 이디엄이 서로 다른 프로그래밍 언어마다 다르게 나타나기도 하고, 때로는 하나의 이디엄이 특정 프로그래밍 언어에서는 유용하지만 다른 프로그래밍 언어에서는 유용하지 않은 경우도 있음

댓글