상호 작용 지향 아키텍처

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

  • 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 구성 요소가있는 응용 프로그램에 적합합니다.

장점

  • 멀티 태스킹 및 멀티 뷰 지원

  • 에이전트 재사용 및 확장 성 지원

  • 새 에이전트를 쉽게 플러그인하거나 기존 에이전트를 변경

  • 여러 에이전트가 서로 다른 스레드 또는 서로 다른 장치 또는 컴퓨터에서 병렬로 실행되는 동시성 지원

단점

  • 표현과 추상화 사이의 제어 브리지와 에이전트 간의 제어 통신으로 인해 오버 헤드가 발생합니다.

  • 느슨한 결합과 에이전트 간의 높은 독립성으로 인해 올바른 에이전트 수를 결정하기가 어렵습니다.

  • 각 에이전트의 제어에 의한 프리젠 테이션과 추상화의 완전한 분리는 에이전트 간의 통신이 에이전트의 제어간에 만 이루어지기 때문에 개발 복잡성을 유발합니다.