필립 크루첸(Philippe Kruchten)이 1995년에 제안한 이 모델은, 복잡한 소프트웨어 아키텍처를 단 하나의 관점이 아닌 '서로 다른 4개의 관점'과 이들을 검증하고 연결하는'1개의 핵심 관점(유스케이스)'으로 설명하는 프레임워크입니다.
1. 4+1 뷰 모델의 상세 구조
아키텍처 문서는 이해관계자(Stakeholder)마다 보고 싶어 하는 정보가 다르므로 이를 만족시키기 위해 뷰를 분리한 것
논리 뷰 (Logical View)
- 핵심 : 시스템이 사용자에게 어떤 기능(Functional Requirements)을 제공하는가?
- 관점 : 최종 사용자(End-User)의 관점
- 내용 : 시스템의 기능적 요구사항을 클래스, 객체, 관계 등으로 추상화하여 표현
- 설계 : 클래스 다이어그램, 시퀀스 다이어그램 등을 주로 사용
프로세스 뷰 (Process View)
- 핵심 : 시스템이 어떻게 동작(Behavior)하며, 성능과 동시성(Concurrency)을 어떻게 처리하는가?
- 관점 : 시스템 통합자(Integrator), 개발자
- 내용 : 스레드(Thread), 프로세스(Process)의 통신, 동기화, 성능, 가용성 같은 비기능적 요구사항을 다룸
- 설계 : 상태 다이어그램, 활동 다이어그램
구현 뷰 (Implementation View) = 개발 뷰 (Development View)
- 핵심 : 소프트웨어가 개발 환경 안에서 어떻게 구성되는가?
- 관점 : 프로그래머(Programmer), 소프트웨어 관리자
- 내용 : 소스 코드, 라이브러리, 컴포넌트, 서브시스템의 정적인 구조와 의존성 관리, 빌드 순서
- 설계 : 컴포넌트 다이어그램, 패키지 다이어그램
배포 뷰 (Deployment View) = 물리 뷰 (Physical View)
- 핵심 : 소프트웨어가 어떤 하드웨어에 설치되고 매핑되는가?
- 관점 : 시스템 엔지니어(System Engineer), 운영자
- 내용 : 물리적인 노드(서버, 프로세서)와 그 위에 실행되는 소프트웨어 컴포넌트의 매핑, 네트워크 토폴로지
- 설계 : 배포 다이어그램
(+1) 유스케이스 뷰 (Use Case View) = 시나리오 뷰
- 핵심 : 시스템이 실제로 어떻게 사용되는가? (모든 뷰의 기준)
- 관점 : 모든 이해관계자 (사용자, 설계자, 개발자, 테스터)
- 역할 : 앞선 4가지 뷰가 서로 충돌하지 않고 일관성을 가지는지 검증(Validation)하고 주도(Driver)하는 역할
다른 뷰들을 도출해내는 원천
2. 핵심 매핑 테이블
| 뷰(View) | 주 이해관계자 | 핵심 관심사 (Focus) | 관련 UML 다이어그램 (대표) | 성격 |
| 논리 뷰 | 최종 사용자 | 기능적 요구사항 | 클래스, 객체, 시퀀스, 상태 | 기능 중심 |
| 프로세스 뷰 | 시스템 통합자 | 성능, 동시성, 스레드 | 활동, 상태 | 비기능(성능) |
| 구현(개발) 뷰 | 프로그래머 | SW 모듈 구성, 빌드 관리 | 컴포넌트, 패키지 | 정적 구조 |
| 배포(물리) 뷰 | 시스템 엔지니어 | HW 매핑, 토폴로지, 통신 | 배포 | 물리적 구조 |
| 유스케이스 뷰 | 모든 이해관계자 | 아키텍처 검증, 시나리오 | 유스케이스 | 통합/검증 |
3. 기출 포인트 & 오답 함정 피하기
용어 혼동 주의
- 구현 뷰는 '개발 뷰'라고도 불림 (코드 관리 관점)
- 배포 뷰는 '물리 뷰'라고도 불람 (하드웨어 관점)
기능 vs 비기능
- 논리 뷰는 철저히 기능(Functionality)에 집중
- 프로세스 뷰는 성능, 처리량, 동시성 같은 비기능(Non-functional) 품질 속성에 집중
유스케이스 뷰의 위상
- 유스케이스 뷰는 나머지 4개 뷰와 병렬적인 관계가 아님
- 나머지 4개 뷰를 도출하고, 이들이 잘 맞물려 돌아가는지 검증(Check)하는 중심축
- "유스케이스 뷰는 다른 뷰를 주도(Drive)한다"는 표현이 나오면 맞는 말
UML 매핑
- "컴포넌트 다이어그램은 어떤 뷰에서 주로 사용되는가?" ➡ 구현 뷰
- "시스템의 비기능적 요구사항인 성능과 자원 효율성을 다루는 뷰는?" ➡ 프로세스 뷰