패턴과 아키텍처 패턴
패턴- 소프트웨어 시스템에 대한 지식을 표현하고 공유하고 재사용하는 방법
- 객체지향 설계 패턴, 구조 설계를 위한 패턴, 사용성 패턴, 형상관리 패턴 등
아키텍처 패턴- 서로 다른 시스템과 환경에서 시도되고 시험된 바람직한 사례를 양식화하고 추상화한 기술
- 설명 기술과 다이어그램을 섞어서 사용하는 표준 방법으로 기술 가능
- 패턴에 관련된 상세한 내용 포함
모델 뷰 제어기(MVC) 패턴의 구성
<개념적 뷰>
- 웹 기반 시스템에서 상호 작용 관리의 기반
- 대부분의 언어 프레임 워크에서 지원
- 예 : 런타임 시스템 아키텍처
아키텍처 설계의 기본
- 분리와 독립의 개념
- 변경에 의해 영향받는 범위를 작게 만듦
- 변경에 의해 영향받는 범위를 작게 만듦
- MVC 패턴
- 시스템의 요소들을 분리하여 독립적으로 변경될 수 있도록 함
- 시스템의 요소들을 분리하여 독립적으로 변경될 수 있도록 함
- 계층 아키텍처 패턴
- 분리와 독립을 이루는 또 다른 방법
계층 아키텍처
- 시스템의 기능은 분리된 계층으로 구성
- 각 계층은 바로 아래 계층에서 제공하는 기능과 서비스에만 의존
- 각 계층은 바로 아래 계층에서 제공하는 기능과 서비스에만 의존
- 계층적인 접근은 시스템의 점증적 개발 지원
- 계층이 개발될 때 그 계층에서 제공하는 서비스의 일부는 사용자에게 제공 가능
- 계층이 수정돼도, 인접한 계층만 영향받음
- 인터페이스가 변경되지 않으면, 확장 기능을 가지는 새로운 계층으로 기존의 계층 대체 가능
- 멀티 플랫폼 구현 제공이 쉬움
- 계층화된 시스템이 기계 의존성을 지역화
계층 아키텍처 패턴
- 설명
- 시스템을 계층으로 구성하고 각 계층은 관련된 기능을 수행
- 각 계층은 상위 계층에 서비스를 제공
- 가장 아래 계층은 시스템 전체에서 사용되는 핵심 서비스를 나타냄
- 사용 시기
- 새로운 기능을 기존 시스템 위에 구축할 때
- 개발을 여러 팀으로 나누어서 하고 각 팀이 기능 계층에 대한 책임이 있을 때
- 다중 수준 보안이 필요할 때
- 장점
- 인터페이스가 유지된다면 전체 계층을 대체하는 것이 가능
- 시스템의 확실성을 향상하기 위해 중복된 기능이 각 계층에 제공될 수 있음
- 단점
- 계층을 명확하게 분리하는 것이 어려움
- 상위 수준 계층이 바로 아래 계층을 통하지 않고 하위 수준 계층과 직접 상호작용할 수도
→ 성능 저하문제 발생
- 예
- 학교에서 모든 과목의 학습을 지원하는 디지털 학습 시스템의 계층 모델
범용 계층 아키텍처
저장소 아키텍처
- 상호 작용하는 컴포넌트들의 집합이 어떻게 데이터를 공유하는지 기술
- 공유 데이터베이스 또는 저장소 중심으로 구성
- 대량에 데이터를 사용하는 시스템들이 해당 패턴 사용
- 한 컴포넌트에서 생성된 데이터가 다른 컴포넌트에서 사용되는 응용분야에 적합
- 저장소를 여러 대의 기계에 분산시키는 것이 어려울 수 있음
저장소 아키텍처 패턴
- 설명
- 시스템의 모든 데이터는 모든 시스템 컴포넌트들이 접근할 수 있는 중앙 저장소에서 관리됨
- 컴포넌트들은 직접 상호작용하지 않고, 저장소를 통해서만 상호작용
- 사용시기
- 장기간 저장되어야 하는 대량의 정보를 생성하는 시스템을 가지고 있을 때
- 저장소에 데이터 추가 시, 동작이 필요한 데이터 주도 시스템에서도 사용 가능
- 장점
- 컴포넌트들이 독립적이고, 다른 컴포넌트들의 존재를 알 필요가 없음
- 한 컴포넌트에 의한 변경이 모든 컴포넌트로 전파
- 모든 데이터는 한 장소에 일관성 있게 관리됨
- 단점
- 저장소의 문제가 전체 시스템에 영향을 줌
- 모든 통신이 저장소를 통하도록 구성 → 비효율일 수도 있음
IDE를 위한 저장소 아키텍처
- 모델 주도 개발을 지원하는 여러 가지 도구들을 포함하는 IDE
- 버전 관리 환경 : 소프트웨어 변경을 기록하고 이전 버전으로 돌아가는 것이 가능
- 저장소가 수동적이고 제어는 저장소를 사용하는 컴포넌트의 책임
- 다른 접근법 : 블랙보드 모델 → 특정 데이터가 사용 가능하게 되면 컴포넌트들을 동작
- 저장소의 데이터가 비구조적일 때 적절
클라이언트-서버 아키텍처
- 클라이언트
- 서버에 의해 제공되는 서비스를 요청-응답 프로토콜을 이용하는 원격 프로시저 호출을 통해 접근
- 가용 서버와 서버가 제공하는 이름을 알아야 할 수도 있음
- 서버
- 클라이언트가 보내오는 요청을 처리하고 응답
- 클라이언트 식별 할 필요 없음
- 장점
- 분산 아키텍처 ← 가장 중요한 장점
- 효과적인 구성법 : 여러 분산 프로세서가 있고 네트워크로 연결된 시스템
클라이언트-서버 아키텍처 패턴
- 설명
- 시스템이 각 서비스가 독립적인 서버에 의해 제공되는 서비스들의 집합으로 표현
- 시스템이 각 서비스가 독립적인 서버에 의해 제공되는 서비스들의 집합으로 표현
- 사용 시기
- 공유 데이터베이스에 있는 데이터를 여러 지역에서 접근해야 할 때 사용
- 서버는 중복이 가능하므로 시스템의 부하변동이 클 때도 사용 가능
- 장점
- 서버가 네트워크 상에 분산될 수 있다.
- 일반적인 기능은 모든 클라이언트가 사용 가능하며 모든 서비스에 의해 구현될 필요 없음
- 단점
- 각 서비스가 단일 장애점이므로 서비스 거부 공격(DoS)에 민감
- 성능이 시스템뿐만 아닌 네트워크에도 영향받음 → 성능 예측 어려움
- 서버를 다른 기관에서 소유하면 관리 문제가 발생할 수 있음
영화 라이브러리를 위한 클라이언트-서버 아키텍처
파이프 필터 아키텍처
- 기능적 변환들이 입력을 처리하여 출력을 생성
- 입력 데이터는 출력으로 바뀔 때까지 변환들을 통해 흘러감
- 변환이 입력 데이터 흐름으로부터 처리할 수 있는 데이터를 필터링함
- 변환은 순차적 혹은 병렬적으로 실행될 수 있음
- 데이터는 각 변환에 의해 항목별로 처리되거나 일괄처리될 수 있음
- 일괄처리 시스템과 임베디드 시스템에 적합
- 사용자 상호작용이 제한되어 있는 시스템에 적합
- 대화 시 시스템은 처리될 데이터 흐름이 필요하기 때문에 부적합
파이프 필터 아키텍처 패턴
- 설명
- 시스템에서 데이터 처리는 각 처리 컴포넌트가 분리되어 있으며 한 가지 종류의 변환을 수행하도록 구성
- 데이터는 처리를 위해 한 컴포넌트에서 다른 컴포넌트로 흐른다.
- 사용 시기
- 입력으로부터 출력을 생성하기 위해 개별적인 단계를 거치는 데이터 처리 애플리케이션에서 사용
- 입력으로부터 출력을 생성하기 위해 개별적인 단계를 거치는 데이터 처리 애플리케이션에서 사용
- 장점
- 이해하기 쉽고 변환의 재사용을 지원
- 워크플로 유형은 많은 비즈니스 프로세스의 구조와 일치
- 순차적 또는 병행 시스템으로 구현 가능
- 단점
- 데이터를 주고받는 변환 간에 데이터 전송 형식이 일치해야 함
→ 호환되지 않는 데이터 구조를 사용하는 아키텍처 컴포넌트는 재사용 X - 각 변환은 입력을 분석하고 약속된 형식을 맞추어 출력을 생성
→ 시스템 부담 증가
- 데이터를 주고받는 변환 간에 데이터 전송 형식이 일치해야 함
아키텍처 패턴 추가 예시
중앙 집중식 제어 모델
- 한 컴포넌트가 컨트롤러로 지정되고 다른 컴포넌트의 실행 관리를 담당
- 실행 방식에 따라 두 가질 나뉨(순차적/병렬)
콜-리턴 모델(순차 시스템에만 적용 가능)- 하향식 서브루틴 모델
- 구조의 맨 위에서 제어가 시작, 서브루틴 호출을 통해 트리의 하위 레벨로 전달
관리자 모델(동시시스템에 적용 가능)- 시스템 관리자 - 다른 프로세스의 시작, 중지, 조정 및 스케줄링을 제어
- 프로세스 - 다른 프로세스와 병렬로 실행할 수 있는 구성요소 또는 모듈
- 관리 루틴이 일부 상태 변숫값에 따라 순차 시스템에도 적용 가능
콜-리턴 모델
- 동작 방식
- 제어는 계층 구조의 상위 수준 루틴에서 하위 수준 루틴으로 전달,
다음 루틴이 호출 지점으로 돌아감 - 실행 중인 서브루틴은 제어에 대한 책임이 있으며,
다른 루틴을 호출하거나 부모에게 제어를 반환 가능
- 제어는 계층 구조의 상위 수준 루틴에서 하위 수준 루틴으로 전달,
- 모듈 수준에서 기능이나 개체를 제어하는 데 사용
- 장점 : 제어 흐름 분석, 입력에 대한 반응 파악 비교적 간단
- 단점 : 정상 동작에 대한 예외 처리 다루기 어색
실시간 시스템을 위한 중앙 집중식 제어 모델
이벤트 기반 제어
- 외부에서 생성된 이벤트에 의해 구동
- 이벤트는 이진 신호뿐 아니라 메뉴에서 입력한 매우 큰 값일 수도 있음
- 이벤트의 타이밍 - 그 이벤트를 처리하는 프로세스의 제어 범위를 벗어남
- 두 가지 이벤트 기반 제어 모델
브로드 캐스트 모델- 네트워크에 분산된 구성 요소를 통합하는데 효과적인터럽트 구동 모델- 엄격한 타이밍 요구 사항이 있는 실시간 시스템에서 사용
브로드캐스트 모델
- 컴포넌트는 어떠한 이벤트를 필요로 하는지 결정(관심 있는 이벤트)
- 이벤트가 발생하면 그 이벤트를 다룰 수 있는 컴포넌트로 제어가 전달
- 제어 정책이 이벤트 및 메시지 처리기에 포함되지 않음 → 중앙 집중식 모델과의 차이
- 동작 방식
- 컴포넌트가 이벤트를 처리할 수 있음을 나타내는 이벤트를 생성
- 이벤트 핸들러는 이벤트를 감지하고 이벤트 레지스터를 참조하여
관심을 선언한 컴포넌트들에게 인터페이스를 전달- 이벤트 핸들러는 지점 간 통신 지원
- 컴포넌트는 다른 컴포넌트에 명시적으로 메시지를 보낼 수 있음
- 컴포넌트는 다른 컴포넌트에 명시적으로 메시지를 보낼 수 있음
- 이벤트 핸들러는 지점 간 통신 지원
- 장점 : 진화가 비교적 간단
- 단점 : 이벤트 처리 여부 및 처리되는 시기를 컴포넌트가 알지 못함
인터럽트 구동 제어 모델
- 외부에서 생성된 이벤트를 매우 빠르게 처리해야 하는 실시간 시스템에 적합
- 중앙 집중식 관리 모델과 결합될 수 있음
- 중앙 집중식 관리 모델과 결합될 수 있음
- 외부 인터럽트가 인터럽트 핸들러에 의해 감지되는 실시간 시스템에서 독점적으로 사용
→ 이후 처리를 위해 다른 구성 요소로 전달
- 인터럽트가 수신되면 하드웨어 스위치 제어가 즉시 핸들러로 전송
- 인터럽트 핸들러는 인터럽트 신호된 이벤트에 응답하여 다른 프로세스를 시작/중지 가능
- 각 유형에 대해 정의된 처리기가 있는 알려진 수의 인터럽트 유형이 있음
- 각 유형의 인터럽트는 핸들러의 주소가 저장된 메모리 위치와 연관
- 각 유형의 인터럽트는 핸들러의 주소가 저장된 메모리 위치와 연관
- 하드웨어에 의해 인터럽트 수가 제한되는 경우
- 해당 모델을 사용하여 개발된 시스템을 변경하기 어려울 수 있음
- 제한에 도달하면 다른 유형의 이벤트를 처리할 수 없음
- 여러 유형의 이벤트를 단일 인터럽트에 매핑하여 이 제한 해결 가능
- 장점 : 이벤트에 대한 매우 빠른 응답 구현 가능
- 단점 : 프로그래밍이 복잡하고 검증하기 어려움