소프트웨어 아키텍처 스타일: Difference between revisions
From IT Wiki
(새 문서: 분류:소프트웨어 공학 ;Software Architecture Style * 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시...) |
No edit summary |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 10: | Line 10: | ||
! 예시 | ! 예시 | ||
|- | |- | ||
| | | [[계층형 아키텍처 스타일|계층형 스타일]] | ||
스타일 | | | ||
| * SW를 계층 단위(Unit)로 분할 | * SW를 계층 단위(Unit)로 분할 | ||
* 각 계층은 모듈들의 응집된 집합 | * 각 계층은 모듈들의 응집된 집합 | ||
* 계층간의 관계는 사용가능의 관계로 표현 | * 계층간의 관계는 사용가능의 관계로 표현 | ||
Line 18: | Line 18: | ||
* 장점 : 정보은닉의 원칙 적용 → 높은이식성 | * 장점 : 정보은닉의 원칙 적용 → 높은이식성 | ||
* 단점 : 추가적인 실행시 오버헤드(너무 많은 계층으로 성능 감소 발생) | * 단점 : 추가적인 실행시 오버헤드(너무 많은 계층으로 성능 감소 발생) | ||
| | | [[파일:계층형 아키텍처 스타일 예시.png|150px]] | ||
|- | |- | ||
| MVC | | MVC | ||
스타일 | 스타일 | ||
| * 모델 : APP의 핵심기능 및 적절한 데이터 캡슐화 | | | ||
* 모델 : APP의 핵심기능 및 적절한 데이터 캡슐화 | |||
* 뷰 : 사용하게 될 데이터를 엑세스하기 위한 기능 제공 | * 뷰 : 사용하게 될 데이터를 엑세스하기 위한 기능 제공 | ||
* 컨트롤러 : 이벤트로서 사용자의 입력사항 처리 | * 컨트롤러 : 이벤트로서 사용자의 입력사항 처리 | ||
Line 32: | Line 33: | ||
Server | Server | ||
스타일 | 스타일 | ||
| * 여러 컴포넌트에 걸쳐서 데이터와 데이터를 처리하는 어플리케이션에 적합 | | | ||
* 여러 컴포넌트에 걸쳐서 데이터와 데이터를 처리하는 어플리케이션에 적합 | |||
* 컴포넌트는 다른 컴포넌트에게 서비스 요청 함으로써 커뮤니케이션 | * 컴포넌트는 다른 컴포넌트에게 서비스 요청 함으로써 커뮤니케이션 | ||
* n-Tier 클라이언트 서버 모델(3-Tier) | * n-Tier 클라이언트 서버 모델(3-Tier) | ||
Line 42: | Line 44: | ||
Filters | Filters | ||
스타일 | 스타일 | ||
| * 데이터 스트림 처리 시스템을 위한 구조 | | | ||
* 데이터 스트림 처리 시스템을 위한 구조 | |||
* 컴포넌트:필터, 커넥터:파이프 | * 컴포넌트:필터, 커넥터:파이프 | ||
* 필터는 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송 | * 필터는 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송 | ||
Line 52: | Line 55: | ||
Subscribe | Subscribe | ||
스타일 | 스타일 | ||
| * 컴포넌트는 발생된 이벤트를 통해 의사소통 | | | ||
* | * 컴포넌트는 발생된 이벤트를 통해 의사소통 | ||
* 출판자 : 이벤트 발생 컴포넌트 | |||
* 구독자 : 이벤트 수신 컴포넌트 | * 구독자 : 이벤트 수신 컴포넌트 | ||
* 장점 : 컴포넌트 분리로 독립성 우수 | * 장점 : 컴포넌트 분리로 독립성 우수 | ||
Line 60: | Line 64: | ||
| Peer-To-Peer | | Peer-To-Peer | ||
스타일 | 스타일 | ||
| * 클라이언트/서버 스타일에 대칭적 특징추가 | | | ||
* 클라이언트/서버 스타일에 대칭적 특징추가 | |||
* 컴포넌트는 클라이언트와 서버역할 모두수행 | * 컴포넌트는 클라이언트와 서버역할 모두수행 | ||
* 장점 : 분산컴퓨팅 어플 구축시 유연성 제공 | * 장점 : 분산컴퓨팅 어플 구축시 유연성 제공 | ||
| | | | ||
|- | |- | ||
| | | [[칠판형 아키텍처 스타일|칠판형 스타일]] | ||
스타일 | | | ||
| * 블랙보드, 지식자원의집합, 컨트롤컴포넌트로 구성 | * 블랙보드, 지식자원의집합, 컨트롤컴포넌트로 구성 | ||
* 결정적 해결전략이 존재하지 않는 문제 해결에 유용 | * 결정적 해결전략이 존재하지 않는 문제 해결에 유용 | ||
* 장점 : 다양한 접근법, 유지보수성,가변성,재사용 가능한 지식자원 | * 장점 : 다양한 접근법, 유지보수성,가변성,재사용 가능한 지식자원 | ||
* 단점 : 테스팅 어려움, 완전한 해결책 미보장 | * 단점 : 테스팅 어려움, 완전한 해결책 미보장 | ||
| | | [[파일:칠판형 아키텍처 스타일 예시.png|150px]] | ||
|- | |- | ||
| Repository | | Repository | ||
스타일 | 스타일 | ||
| * 적어도 하나의 저장소에 지속성을 갖는 데이터 저장, 이 데이터를 여러 모듈에 사용 | | | ||
* 적어도 하나의 저장소에 지속성을 갖는 데이터 저장, 이 데이터를 여러 모듈에 사용 | |||
* 예) 데이터베이스시스템 | * 예) 데이터베이스시스템 | ||
* 장점 : 대량 데이터 저장, 공유모델 발행 가능, 중앙집중화 관리 | * 장점 : 대량 데이터 저장, 공유모델 발행 가능, 중앙집중화 관리 | ||
* 단점 : 데이터모델의 사전 동의 필요, 데이터 분산의 어려움 | * 단점 : 데이터모델의 사전 동의 필요, 데이터 분산의 어려움 | ||
| | | | ||
|- | |||
| [[브로커 아키텍처 스타일|브로커 스타일]] | |||
| | |||
* 외부에 분산된 컴포넌트에 값을 전달하고 응답을 받아서 전달해주는 브로커 이용 | |||
* 장점 : 위치 투명성, 연동 용이, 재사용 컴포넌트 확보 용이 | |||
* 단점 : 성능 불이익, 장애 대처 어려움, 디버깅 어려움 | |||
| [[파일:브로커형 아키텍처 스타일 예시.png|150px]] | |||
|} | |} | ||
== 참고 문헌 == | == 참고 문헌 == | ||
* 소프트웨어 아키텍처(이덕우) | * 소프트웨어 아키텍처(이덕우) |
Latest revision as of 22:29, 11 March 2020
- Software Architecture Style
- 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 아키텍처가 만족시켜야 하는 시스템 품질 속성을 달성할 수 있는 방법을 체계화 한 것
- 아키텍처를 구성하는 컴포넌트와 커넥터 종류와 이것들이 결합하는 방법 정의
- 아키텍처 설계시 이용 가능한 베스트 프랙티스
구분 | 특징 | 예시 |
---|---|---|
계층형 스타일 |
|
|
MVC
스타일 |
|
|
Client
Server 스타일 |
|
|
Pipe &
Filters 스타일 |
|
|
Publish
Subscribe 스타일 |
|
|
Peer-To-Peer
스타일 |
|
|
칠판형 스타일 |
|
|
Repository
스타일 |
|
|
브로커 스타일 |
|
참고 문헌[edit | edit source]
- 소프트웨어 아키텍처(이덕우)