Embed Size (px)
Citation preview
학습 목표
l 블랙보드 패턴
l 브로커 패턴
l PAC 패턴
l 마이크로 패턴
l 리플렉션 패턴
2
l 블랙보드 패턴
l 브로커 패턴
l PAC 패턴
l 마이크로 패턴
l 리플렉션 패턴
패턴 중심 소프트웨어 아키텍처
l POSA Patternsl “Pattern Oriented Software Architecture”A System of Patterns
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sornmerlad, Michael Stal, Wiley, 1996
3
패턴 중심 소프트웨어 아키텍처
l 소프트웨어 아키텍처 패턴에 대한 책
l 소프트웨어 개발 초보, 전문가 모두가 읽어야 할 책
l 대규모, 복잡한 소프트웨어 시스템을 특정한 의도로 설계할 때 필요한 지식을 담고 있음
l 전문가의 경험에서 배울 수 있는 내용을 담고 있음
l 소프트웨어 아키텍처 패턴에 대한 책
l 소프트웨어 개발 초보, 전문가 모두가 읽어야 할 책
l 대규모, 복잡한 소프트웨어 시스템을 특정한 의도로 설계할 때 필요한 지식을 담고 있음
l 전문가의 경험에서 배울 수 있는 내용을 담고 있음
4
아키텍처 패턴
l 정의[Buschman 등]l 소프트웨어의 기본 구조를 구성하기 위한 스키마. l 미리 정의된 서브시스템을 제공하고 각 서브시스템의 책임을 정의하며
서브시스템 간의 관계를 조직화하는 규칙화 가이드라인
l 아키텍처 템플릿l 소프트웨어 아키텍처를 만들기 위한 뼈대l 시스템 전반에 걸친 구조적 특성을 정의. 서브시스템의 아키텍처에 영향
을 줌
l 기본 설계 결정l 아키텍처 패턴의 선택은 소프트웨어를 개발할 때 기본이 되는 설계 결정
임
l 정의[Buschman 등]l 소프트웨어의 기본 구조를 구성하기 위한 스키마. l 미리 정의된 서브시스템을 제공하고 각 서브시스템의 책임을 정의하며
서브시스템 간의 관계를 조직화하는 규칙화 가이드라인
l 아키텍처 템플릿l 소프트웨어 아키텍처를 만들기 위한 뼈대l 시스템 전반에 걸친 구조적 특성을 정의. 서브시스템의 아키텍처에 영향
을 줌
l 기본 설계 결정l 아키텍처 패턴의 선택은 소프트웨어를 개발할 때 기본이 되는 설계 결정
임
5
아키텍처 패턴의 카테고리
l 혼돈에서 질서로l 무질서한 객체나 컴포넌트의 집합이 아니라 서브 태스크들로 분할 통제l 계층 패턴, 파이프 라인 패턴, 블랙보드 패턴
l 분산 시스템l 분산 시스템을 아키텍처링l 브로커 패턴, 마이크로 커널, 파이프와 필터
l 상호작용 시스템l HCI를 가진 소프트웨어 시스템을 구조화l MVC, Presentation-Abstraction-Control
l 적응 시스템l 애플리케이션을 확장하는 데 도움, 기능적 요구사항이 변경함에 따라 적
응할 수 있는 구조l 리플렉션 패턴, 마이크로 커널 패턴
l 혼돈에서 질서로l 무질서한 객체나 컴포넌트의 집합이 아니라 서브 태스크들로 분할 통제l 계층 패턴, 파이프 라인 패턴, 블랙보드 패턴
l 분산 시스템l 분산 시스템을 아키텍처링l 브로커 패턴, 마이크로 커널, 파이프와 필터
l 상호작용 시스템l HCI를 가진 소프트웨어 시스템을 구조화l MVC, Presentation-Abstraction-Control
l 적응 시스템l 애플리케이션을 확장하는 데 도움, 기능적 요구사항이 변경함에 따라 적
응할 수 있는 구조l 리플렉션 패턴, 마이크로 커널 패턴
6
블랙보드 아키텍처 패턴
l 명확히 정의된 해법 전략이 아직 존재하지 않은 도메인에서 문제를해결하려 할 때
l 부분적인 해법, 대략적인 해법을 수립하기 위해 특수한 서브시스템의지식을 조합
7
블랙보드 아키텍처 패턴 - 예제
l 음성 인식 시스템l 파형, 분절음, 구절, 구문 등을 판별하기 위하여 전혀 다른 도메인의 지식
이 필요l 일관적인 알고리즘이 없음l 모호하고 잡음 섞인 데이터, 개인적인 차이 등 어려움 가중
8
블랙보드 아키텍처 패턴 - 해법
l 공유 데이터 구조 위에 종합적으로 동작하는 독립적인 프로그램의 모임
l 각 프로그램은 전체 중 특정한 부분을 해결하기 위하여 특수화
l 특수화 된 프로그램은 제각기 독립적
l 중앙 제어 컴포넌트는 현재 처리 과정을 평가하여 특수화 된 프로그램을 조율
l 프로그램들은 블랙보드를 통하여 커뮤니케이션
l 공유 데이터 구조 위에 종합적으로 동작하는 독립적인 프로그램의 모임
l 각 프로그램은 전체 중 특정한 부분을 해결하기 위하여 특수화
l 특수화 된 프로그램은 제각기 독립적
l 중앙 제어 컴포넌트는 현재 처리 과정을 평가하여 특수화 된 프로그램을 조율
l 프로그램들은 블랙보드를 통하여 커뮤니케이션
9
블랙보드 아키텍처 패턴 - 구조
l 컴포넌트l 블랙보드 – 중앙 데이터 저장소l 지식 소스 – 특수한 측면을 해결하는 독립적 서브시스템l 제어 컴포넌트 – 변경을 모니터링하고 다음 동작을 결정
10
블랙보드 아키텍처 패턴 - 동작
11
블랙보드 아키텍처 패턴 - 구현
l “Are any by Feigenbaum and Feldman?” 인식
12
브로커 아키텍처 패턴 - 정의
l 분산 소프트웨어 시스템의 구조화에 적합
l 분리된 컴포넌트들이 원격 서비스를 호출하여 상호 작용
l 브로커 컴포넌트가 통신을 관할, 결과와 예외를 전송
13
브로커 아키텍처 패턴 - 예
l WAN 도시정보 시스템l 호텔, 레스토랑, 사적, 대중교통 정보
14
브로커 아키텍처 패턴 - 문제
l 독립적 협력 컴포넌트들의 이질적 분산 시스템
l 원격 메소드 호출 제공
l Location transparency
l 서비스를 동적으로 추가, 제거, 교환
l 개발자에게 자세한 것 숨김
l 독립적 협력 컴포넌트들의 이질적 분산 시스템
l 원격 메소드 호출 제공
l Location transparency
l 서비스를 동적으로 추가, 제거, 교환
l 개발자에게 자세한 것 숨김
15
브로커 아키텍처 패턴 - 해법
l 네트워크 클라이언트와 서버 컴포넌트 사이에 플랫폼 독립 커뮤니케이션을 제공
l 서버는 브로커에 등록, 클라이언트는 브로커를 통하여 요청
l 객체에 메시지 호출 -> 분산 서비스에 액세스
16
브로커 아키텍처 패턴 - 구조
l 여섯 가지 컴포넌트
message exchange
message exchange
*
marshalunmarhalreceive_resultservice_p
Client Proxy *
marshalunmarshaldispatchreceive_request
Server Proxy1
main_loopsrv_registrationsrv_lookuptransmit_message
Broker1
17
calls1
marshalunmarhalreceive_resultservice_p
calls*
call_service_pstart_task
Client1
marshalunmarshalforward_messagetransmit_message
Bridge
marshalunmarshaldispatchreceive_request
calls*
start_upmain_loopservice_i
Server1
main_loopsrv_registrationsrv_lookuptransmit_message
브로커 아키텍처 패턴 - 구조
l 클라이언트l 사용자 기능 구현l 클라이언트 측 프록시를 통하여 서버에 요청
l 브로커l 서버를 등록, 제거l API 제공, 메시지 전송, 오류 복구
l 클라이언트 프록시l 클라이언트와 브로커 간의 레이어l 특정 시스템에 맞춰진 기능
l 서버측 프록시l 서버 내의 서비스 호출l Unpack, unmashaling
l 브리지l 특정 시스템과 관련된 모든 세부 내용 캡슐화
l 클라이언트l 사용자 기능 구현l 클라이언트 측 프록시를 통하여 서버에 요청
l 브로커l 서버를 등록, 제거l API 제공, 메시지 전송, 오류 복구
l 클라이언트 프록시l 클라이언트와 브로커 간의 레이어l 특정 시스템에 맞춰진 기능
l 서버측 프록시l 서버 내의 서비스 호출l Unpack, unmashaling
l 브리지l 특정 시스템과 관련된 모든 세부 내용 캡슐화
18
브로커 아키텍처 패턴 - 동작
method (proxy) locate_server
server port
marshal
start_upregister_service
: Broker: Client Proxy : Server Proxy: Client : Server
assigned port
19
receive_request
marshal
unmarshal
dispatchmethod (impl.)
resultmarshal
receive_resultunmarshal
result
브로커 아키텍처 패턴 - 사례
l CORBA 구조
InterfaceRepository
IDLCompiler
ImplementationRepository
Client OBJREF
Object(Servant)
in argsoperation()out args +
return
DII IDLSTUBS
ORBINTERFACE
IDLSKEL DSI
Object Adapter
ORB CORE GIOP/IIOP/ESIOPS
20
InterfaceRepository
IDLCompiler
ImplementationRepository
Client OBJREF
Object(Servant)
in argsoperation()out args +
return
DII IDLSTUBS
ORBINTERFACE
IDLSKEL DSI
Object Adapter
ORB CORE GIOP/IIOP/ESIOPS
브로커 아키텍처 패턴 - 장점
l 이식가능성 증진l 클라이언트와 서버로부터 OS, 네트워크의 자세한 사항을 숨김
l 다른 브로커 시스템 간의 상호운용성 지원l 메시지 교환을 위한 프로토콜을 공통으로 맞춘다면 상호운용 가능
l 재사용성 확보l 새로운 애플리케이션 구축 시 기존 서비스의 애플리케이션 기능 재사용
가능
l 위치 투명성l 서버 위치는 브로커의 일, 클라이언트는 위치 알고 있을 필요 없음
l 이식가능성 증진l 클라이언트와 서버로부터 OS, 네트워크의 자세한 사항을 숨김
l 다른 브로커 시스템 간의 상호운용성 지원l 메시지 교환을 위한 프로토콜을 공통으로 맞춘다면 상호운용 가능
l 재사용성 확보l 새로운 애플리케이션 구축 시 기존 서비스의 애플리케이션 기능 재사용
가능
l 위치 투명성l 서버 위치는 브로커의 일, 클라이언트는 위치 알고 있을 필요 없음
21
브로커 아키텍처 패턴 - 단점
l 낮은 효율l IPC를 이용하는 매뉴얼 시스템 보다 느림. 우회 레이어를 사용하기 때문
l 장애 허용성이 낮음l 분산이 아닌 시스템 보다 낮은 장애 허용성. 브로커의 장애는 치명적
l 테스트, 디버깅이 복잡할 수 있음l 상당히 많은 컴포넌트들이 관련되기 때문
22
Presentation-Abstraction-Control 패턴
l 정의l 계층구조를 이룬 에이전트들이 서로 협력하여 상호 작용 시스템 구조를
형성l 각 에이전트를 애플리케이션의 특징 담당l 각 에이전트는 프레젠테이션, 추상, 콘트롤 컴포넌트로 구성
23
Presentation-Abstraction-Control 패턴 - 문제
l 상호작용 시스템l 협력하는 에이전트의 집합l 에이전트 - UI 제공, 데이터 모델 관리, 처리 기능, 예외 처리, 다른 시스
템과 통신
l 각 에이전트는 자체 상태와 데이터 저장
l 상호작용 에이전트는 각각 자체 UI 제공
l 프레젠테이션 측면은 변경이 잦음
l 상호작용 시스템l 협력하는 에이전트의 집합l 에이전트 - UI 제공, 데이터 모델 관리, 처리 기능, 예외 처리, 다른 시스
템과 통신
l 각 에이전트는 자체 상태와 데이터 저장
l 상호작용 에이전트는 각각 자체 UI 제공
l 프레젠테이션 측면은 변경이 잦음
24
Presentation-Abstraction-Control 패턴 - 해법
l 트리 형태의 계층 구조
Data repository
Access to data Top-level PAC agent
25
View coordinatorSpreadsheet
Pie chartBar chart
Bottom-level PAC agent
Bottom-level PAC agent
Presentation-Abstraction-Control 패턴 - 구조
26
Presentation-Abstraction-Control 패턴 - 구조
27
Presentation-Abstraction-Control 패턴 - 동작
28
Presentation-Abstraction-Control 패턴 - 구현
29
마이크로커널 패턴 - 정의
l 변하는 시스템 요구사항에 적응할 수 있는 소프트웨어 시스템 설계
l 최소 핵심 기능을 확장 기능과 특정 고객에 맞추어진 부분으로 분리
l 확장 부분을 플러그 인 하여 협력 관계를 조정
30
마이크로커널 패턴 - 예
l 하이드라 운영체제l 같은 기능을 기반으로 비슷한 프로그래밍 인터페이스를 사용하는 여러
애플리케이션 개발
31
마이크로커널 패턴 - 문제
l 고려할 점l 하드웨어와 소프트웨어의 지속적인 발전에 대비하여 플랫폼 설계l 이식 가능, 확장 가능, 적응 가능
l 다음 사항의 균형l 애플리케이션은 각기 다르면서 유사한 플랫폼을 지원 하여야l 동일 핵심 기능을 어떤 방식으로 사용하느냐에 따라 애플리케이션을 그
룹으로 분류
l 플랫폼의 핵심 기능l 최소한의 메모리 크기를 가진 한 개의 컴포넌트로 분리l 프로세싱 과정에 적은 부하를 가지도록 여러 서비스로 분리
l 고려할 점l 하드웨어와 소프트웨어의 지속적인 발전에 대비하여 플랫폼 설계l 이식 가능, 확장 가능, 적응 가능
l 다음 사항의 균형l 애플리케이션은 각기 다르면서 유사한 플랫폼을 지원 하여야l 동일 핵심 기능을 어떤 방식으로 사용하느냐에 따라 애플리케이션을 그
룹으로 분류
l 플랫폼의 핵심 기능l 최소한의 메모리 크기를 가진 한 개의 컴포넌트로 분리l 프로세싱 과정에 적은 부하를 가지도록 여러 서비스로 분리
32
마이크로커널 패턴 - 구조
33
마이크로커널 패턴 - 구조
l 마이크로 커널l 통신 기능, 리소스 핸들링 중앙 서비스l 시스템 종속적인 요소로 캡슐화l 원자적 서비스 – 메커니즘
l 내부 서버l 추가 서비스 구현, 특정 하드웨어 소프트웨어 종속 캡슐화
l 외부 서버l 자체 클라이언트를 위한 프로그래밍 인터페이스 제공l 자체 뷰
l 클라이언트l 외부 서버에만 어댑터를 통하여 연결
l 마이크로 커널l 통신 기능, 리소스 핸들링 중앙 서비스l 시스템 종속적인 요소로 캡슐화l 원자적 서비스 – 메커니즘
l 내부 서버l 추가 서비스 구현, 특정 하드웨어 소프트웨어 종속 캡슐화
l 외부 서버l 자체 클라이언트를 위한 프로그래밍 인터페이스 제공l 자체 뷰
l 클라이언트l 외부 서버에만 어댑터를 통하여 연결
34
마이크로커널 패턴 - 동작
35
마이크로커널 패턴 - 장점
l 이식성 보장l 외부 서버, 클라이언트 불변l 마이크로 커널 안의 종속된 부분 만을 이식
l 유연성, 확장성l 추가 기능은 외부 서버만 추가하면 됨
l 정책(외부 서버)과 메커니즘(마이크로 커널)의 분리l 분산 마이크로커널
l 규모 쉽게 확대l 신뢰성 지원l 투명성
l 이식성 보장l 외부 서버, 클라이언트 불변l 마이크로 커널 안의 종속된 부분 만을 이식
l 유연성, 확장성l 추가 기능은 외부 서버만 추가하면 됨
l 정책(외부 서버)과 메커니즘(마이크로 커널)의 분리l 분산 마이크로커널
l 규모 쉽게 확대l 신뢰성 지원l 투명성
36
마이크로커널 패턴 - 단점
l 성능 하락l 단일(monolithic) 소프트웨어 보다 성능 저하l 유연성과의 저울질
l 설계와 구현이 복잡l 난이도 높은 작업l 도메인에 대한 깊은 지식(정책과 마이크로커널의 분리를 위한)
37
리플렉션 패턴 - 정의
l 소프트웨어 시스템의 구조와 동작을 동적으로 변경할 수 있는 메커니즘 제공
l 메타 레벨과 기본 레벨로 나누어 기본적인 측면의 변형l 메타 레벨 – 시스템 특성에 대한 정보 제공l 기본 레벨 – 애플리케이션 로직
l 타입구조와 호출 메커니즘과 같은 기본적인 측면의 변형
l 소프트웨어 시스템의 구조와 동작을 동적으로 변경할 수 있는 메커니즘 제공
l 메타 레벨과 기본 레벨로 나누어 기본적인 측면의 변형l 메타 레벨 – 시스템 특성에 대한 정보 제공l 기본 레벨 – 애플리케이션 로직
l 타입구조와 호출 메커니즘과 같은 기본적인 측면의 변형
38
리플렉션 패턴 - 예
l 영속 객체
39
리플렉션 패턴 - 문제
l 변경할 경우 오류가 발생하기 쉽고 비용 많이 소요
l 적응성을 가진 소프트웨어는 복잡한 구조를 가짐
l 변경에 필요한 기술(매개변수화, 서브 클래싱, copy & paste)이 많을수록 다루기 어렵고 복잡
l 변경의 범위는 매우 크다(단축키, 에플리케이션 프레임워크까지)
l 변경할 경우 오류가 발생하기 쉽고 비용 많이 소요
l 적응성을 가진 소프트웨어는 복잡한 구조를 가짐
l 변경에 필요한 기술(매개변수화, 서브 클래싱, copy & paste)이 많을수록 다루기 어렵고 복잡
l 변경의 범위는 매우 크다(단축키, 에플리케이션 프레임워크까지)
40
리플렉션 패턴 - 해법
l 메타 레벨l 소프트웨어의 구조와 동작에 대한 지식을 주기 위한 소프트웨어 자체 설
명 – 메타객체
l 기본 레벨l 애플리케이션 로직 정의l 변경에 독립
l 인터페이스l 메타객체를 조작l 메타객체 프로토콜
l 메타 레벨l 소프트웨어의 구조와 동작에 대한 지식을 주기 위한 소프트웨어 자체 설
명 – 메타객체
l 기본 레벨l 애플리케이션 로직 정의l 변경에 독립
l 인터페이스l 메타객체를 조작l 메타객체 프로토콜
41
리플렉션 패턴 - 구조
l 메타객체l 타입 식별 객체와 유사
42
리플렉션 패턴 - 동작
43
리플렉션 패턴 - 장단점
l 장점l 소스를 임의로 수정l 소프트웨어 시스템의 변경이 쉬움l 다양한 종류의 변경 지원
l 단점l 메타 레벨에 수정할 때 손상 발생 가능성l 컴포넌트의 개수 급격히 증가l 효율성 저하l 잠재적인 모든 변화를 지원하기 어려움l 리플렉션 제공 하지 않는 언어도 있음
l 장점l 소스를 임의로 수정l 소프트웨어 시스템의 변경이 쉬움l 다양한 종류의 변경 지원
l 단점l 메타 레벨에 수정할 때 손상 발생 가능성l 컴포넌트의 개수 급격히 증가l 효율성 저하l 잠재적인 모든 변화를 지원하기 어려움l 리플렉션 제공 하지 않는 언어도 있음
44
237점157점464점
교
Questions?
237점157점464점
교
Questions?
