상호 작용 지향 아키텍처

상호 작용 지향 아키텍처의 주요 목표는 데이터 추상화 및 비즈니스 데이터 처리에서 사용자 상호 작용을 분리하는 것입니다. 상호 작용 지향 소프트웨어 아키텍처는 시스템을 세 개의 주요 파티션으로 분해합니다.

Data module − 데이터 모듈은 데이터 추상화 및 모든 비즈니스 로직을 제공합니다.
Control module − 제어 모듈은 제어 및 시스템 구성 작업의 흐름을 식별합니다.
View presentation module − View presentation 모듈은 데이터 출력의 시각적 또는 오디오 프레젠테이션을 담당하며 사용자 입력을위한 인터페이스도 제공합니다.

상호 작용 지향 아키텍처에는 두 가지 주요 스타일이 있습니다. Model-View-Controller (MVC) 및 Presentation-Abstraction-Control(PAC). MVC와 PAC는 모두 세 가지 구성 요소 분해를 제안하며 다중 대화 및 사용자 상호 작용이있는 웹 응용 프로그램과 같은 대화 형 응용 프로그램에 사용됩니다. 제어 및 조직의 흐름이 다릅니다. PAC는 에이전트 기반 계층 구조이지만 MVC에는 명확한 계층 구조가 없습니다.

모델-뷰-컨트롤러 (MVC)

MVC는 주어진 소프트웨어 애플리케이션을 상호 연결된 세 부분으로 분해하여 정보의 내부 표현을 사용자에게 제공하거나 사용자로부터받은 정보에서 분리하는 데 도움을줍니다.

기준 치수	함수
모델	기본 데이터 및 비즈니스 로직 캡슐화
제어 장치	사용자 작업에 응답하고 애플리케이션 흐름을 지시합니다.
전망	모델에서 사용자에게 데이터를 형식화하고 표시합니다.

모델

모델은 애플리케이션의 데이터, 로직 및 제약을 직접 관리하는 MVC의 핵심 구성 요소입니다. 이는 원시 애플리케이션 데이터와 인터페이스를위한 애플리케이션 로직을 유지하는 데이터 구성 요소로 구성됩니다.

독립적 인 사용자 인터페이스이며 애플리케이션 문제 도메인의 동작을 캡처합니다.
도메인 별 소프트웨어 시뮬레이션 또는 애플리케이션의 중앙 구조 구현입니다.
상태가 변경되면 연결된보기에 알림을 제공하여 업데이트 된 출력을 생성하고 컨트롤러는 사용 가능한 명령 집합을 변경합니다.

전망

보기는 다이어그램이나 차트와 같은 그래픽 형식으로 정보의 출력을 나타내는 데 사용할 수 있습니다. 데이터의 시각적 표현을 제공하는 프레젠테이션 구성 요소로 구성됩니다.

모델의 요청 정보를보고 사용자에게 출력 표현을 생성합니다.
관리를위한 막대 차트 및 회계사를위한 표보기와 같이 동일한 정보에 대한 여러보기가 가능합니다.

제어 장치

컨트롤러는 입력을 받아 모델 또는 뷰에 대한 명령으로 변환합니다. 모델을 수정하여 사용자의 입력을 처리하는 입력 처리 구성 요소로 구성됩니다.

연결된 모델과보기 및 입력 장치 간의 인터페이스 역할을합니다.
모델의 상태를 업데이트하기 위해 모델에 명령을 보내고 모델의보기 표시를 변경하기 위해 연관된보기에 명령을 보낼 수 있습니다.

MVC-나

시스템이 두 개의 하위 시스템으로 나누어 진 MVC 아키텍처의 간단한 버전입니다.

The Controller-View − 컨트롤러보기는 입력 / 출력 인터페이스 역할을하며 처리가 완료됩니다.
The Model − 모델은 모든 데이터 및 도메인 서비스를 제공합니다.

MVC-I Architecture

모델 모듈은 데이터 변경 사항을 컨트롤러보기 모듈에 알려 그래픽 데이터 디스플레이가 그에 따라 변경되도록합니다. 컨트롤러는 또한 변경시 적절한 조치를 취합니다.

컨트롤러-뷰와 모델 간의 연결은 (위 그림과 같이) 컨트롤러-뷰가 모델을 구독하고 모델이 변경 사항을 컨트롤러-뷰에 알리는 구독-알림 패턴으로 설계 될 수 있습니다.

MVC-II

MVC–II는 뷰 모듈과 컨트롤러 모듈이 분리 된 MVC-I 아키텍처의 향상된 기능입니다. 모델 모듈은 데이터베이스에서 지원하는 모든 핵심 기능과 데이터를 제공하여 MVC-I에서와 같이 적극적인 역할을합니다.

보기 모듈은 데이터를 제공하는 반면 컨트롤러 모듈은 입력 요청을 받아들이고 입력 데이터의 유효성을 검사하고 모델,보기, 연결을 시작하고 작업을 디스패치합니다.

MVC-II Architecture

MVC 애플리케이션

MVC 애플리케이션은 단일 데이터 모델에 여러보기가 필요하고 새롭거나 변경된 인터페이스보기를 쉽게 플러그인 할 수있는 대화 형 애플리케이션에 효과적입니다.

MVC 응용 프로그램은 모듈간에 명확한 구분이있는 응용 프로그램에 적합하므로 다른 전문가를 할당하여 해당 응용 프로그램의 다른 측면을 동시에 작업 할 수 있습니다.

Advantages

사용 가능한 많은 MVC 벤더 프레임 워크 툴킷이 있습니다.
동일한 데이터 모델로 동기화 된 여러보기.
새로운 플러그인 또는 인터페이스보기 교체가 쉽습니다.
그래픽 전문가, 프로그래밍 전문가 및 데이터베이스 개발 전문가가 설계된 프로젝트 팀에서 작업하는 애플리케이션 개발에 사용됩니다.

Disadvantages

대화 형 모바일 및 로봇 애플리케이션과 같은 에이전트 지향 애플리케이션에는 적합하지 않습니다.
동일한 데이터 모델을 기반으로하는 여러 쌍의 컨트롤러와 뷰는 모든 데이터 모델 변경을 비용이 많이 듭니다.
뷰와 컨트롤러의 구분이 명확하지 않은 경우도 있습니다.

PAC (Presentation-Abstraction-Control)

PAC에서 시스템은 많은 협력 에이전트 (트라이어드)의 계층 구조로 배열됩니다. 대화 형 요구 사항 외에도 여러 에이전트의 응용 프로그램 요구 사항을 지원하기 위해 MVC에서 개발되었습니다.

각 에이전트에는 세 가지 구성 요소가 있습니다.

The presentation component − 데이터의 시각적 및 청각 적 표시 형식을 지정합니다.
The abstraction component − 데이터를 검색하고 처리합니다.
The control component − 다른 두 구성 요소 간의 제어 및 통신 흐름과 같은 작업을 처리합니다.

PAC 아키텍처는 프레젠테이션 모듈이 MVC의 뷰 모듈과 같다는 점에서 MVC와 유사합니다. 추상화 모듈은 MVC의 모델 모듈처럼 보이고 제어 모듈은 MVC의 컨트롤러 모듈과 비슷하지만 제어 흐름과 구성이 다릅니다.

각 에이전트의 추상화 구성 요소와 프레젠테이션 구성 요소 간에는 직접적인 연결이 없습니다. 각 에이전트의 제어 구성 요소는 다른 에이전트와의 통신을 담당합니다.

다음 그림은 PAC 디자인의 단일 에이전트에 대한 블록 다이어그램을 보여줍니다.

여러 에이전트가있는 PAC

여러 에이전트로 구성된 PAC에서 최상위 에이전트는 핵심 데이터 및 비즈니스 논리를 제공합니다. 최하위 에이전트는 자세한 특정 데이터 및 프레젠테이션을 정의합니다. 중간 수준 또는 중간 수준 에이전트는 하위 수준 에이전트의 코디네이터 역할을합니다.

각 에이전트에는 고유 한 할당 된 작업이 있습니다.
일부 중급 상담원의 경우 대화 형 프레젠테이션이 필요하지 않으므로 프레젠테이션 구성 요소가 없습니다.
제어 구성 요소는 모든 에이전트가 서로 통신하는 모든 에이전트에 필요합니다.

다음 그림은 PAC에 참여하는 여러 에이전트를 보여줍니다.

Applications

시스템이 계층 적 방식으로 많은 협력 에이전트로 분해 될 수있는 대화 형 시스템에 효과적입니다.
에이전트 간의 결합이 느슨하여 에이전트의 변경 사항이 다른 에이전트에 영향을 미치지 않을 것으로 예상되는 경우에 효과적입니다.
모든 에이전트가 먼 거리에 분산되어 있고 각 에이전트가 데이터 및 대화 형 인터페이스를 통해 고유 한 기능을 가진 분산 시스템에 효과적입니다.
각각의 현재 데이터와 대화 형 인터페이스를 유지하고 다른 구성 요소와 통신해야하는 풍부한 GUI 구성 요소가있는 응용 프로그램에 적합합니다.

장점

멀티 태스킹 및 멀티 뷰 지원
에이전트 재사용 및 확장 성 지원
새 에이전트를 쉽게 플러그인하거나 기존 에이전트를 변경
여러 에이전트가 서로 다른 스레드 또는 서로 다른 장치 또는 컴퓨터에서 병렬로 실행되는 동시성 지원

단점

표현과 추상화 사이의 제어 브리지와 에이전트 간의 제어 통신으로 인해 오버 헤드가 발생합니다.
느슨한 결합과 에이전트 간의 높은 독립성으로 인해 올바른 에이전트 수를 결정하기가 어렵습니다.
각 에이전트의 제어에 의한 프리젠 테이션과 추상화의 완전한 분리는 에이전트 간의 통신이 에이전트의 제어간에 만 이루어지기 때문에 개발 복잡성을 유발합니다.