MVC 모델_Model, View, controller, 구조스타일, 소프트웨어 아키텍처, 브로커

▣ MVC 모델_Model, View, controller, 구조스타일, 소프트웨어 아키텍처, 브로커

MVC 는 Model, View, Controller의 약자임

 

• Model : 프로그램에서 사용되는 실제 데이터 저장 및 데이터 조작 로직을 처리하는 부분
• View : 사용자에게 실제로 제공되어 보여지는 UI부분
• Controller : 사용자의 입력처리와 흐름 제어를 담당

 ▶ MVC 모델 작동 순서

   1. Controller로 사용자의 입력 들어옴

   2. Controller로 Model에 데이터 업데이트를 하고 Model 호출함

   3. Model은 해당 데이터로 보여줄 View를 업데이트하여 화면에 보여 주게 됨

 

 ▶ MVC 모델 단점

   View와 Model이 서로 의존적

 

 

▣ MVP 모델

 ▶ MVP 모델 작동 순서

   1. View로 사용자의 입력이 들어옴

   2. View는 Presenter에 작업 요청을 하게됨

   3. Presenter에서 필요한 데이터를 Model에 요청함

   4. Model은 Presenter에 필요한 데이터를 응답함

   5. Presenter는 View에 데이터를 응답함

   6. View는 Presenter로부터 받은 데이터로 화면에 보여주게 됨

 

 ▶ MVP 모델 특징

  - MVC의 단점인 View와 Model의 의존성이 없어지게 됨

  - View와 Presenter가 1:1로 강한 의존성을 가지게 됨

  - MVC 모델2라고 하는 경우도 있음

 

▣ 아키텍처 패턴 / 스타일

구분	내용	개념도	사례
블랙보드 (Blackboard)	- 해결 전략이 알려지지 않은 문제에 유용 - 블랙보드(blackboard) : 솔루션의 객체를 포함하는 구조화된 전역 메모리 - 지식 소스(knowledge source): 자체 표현을 가진 특수 모듈 - 제어 컴포넌트 (control component) : 모듈 선택, 설정 및 실행을 담당		음성인식 차량식별 신호해석
저장소 구조 (Repository Architecture) 스타일	- 서브 시스템이 단일 중앙 저장소의 자료를 접근하고 변경 - 서브시스템들이 독립적이고 중앙 자료 저장소를 이용하여 상호 대화, 여러 모듈에서 사용함 - 중심이 되는 문제에 대해 논증되고 유지되는 복잡한 정보를 갖고 있는 어플리케이션에 적합한 스타일로 리파지토리 시스템은 speech 그리고 pattern 인식 같은 전통적으로 단일 프로세스의 복잡한 변환을 요구하는 어플리케이션을 자주 사용됨		데이터 베이스 시스템
Data Flow (Pipes and Filters) 스타일	- 서브시스템이 입력 데이터를 받아 처리 -> 결과를 다른 시스템에 보내는 작업이 반복 - 서브 시스템은 필터, 사이의 연결관계는 파이프 - 각 필터는 입력 파이프에 받은 데이터의 내용과 형식만을 알고 그것을 생성한 필터에 대하여는 모름 - 파이프와 필터 구조는 변경 가능하며, 필터는 다른 필터와 교환될 수 있고 다른 목적으로 재구성 - 데이터의 스트림을 처리하는 시스템을 위한 구조를 제공하며 입력되는 데이터가 해당 필터에 관련이 되면 처리를 하고 아니면 그냥 흘러보내는 구조에 유용함. 파이프와 필터 아키텍처로서 가장 잘 알려진 예는 Unix와 Shell을 들 수 있음. Unix는 연결 컴포넌트를 위한 표기법의 제공과 pipe를 구현하기 위한 런 타임 메커니즘의 제공으로 이 스타일을 지원함		파이프 필터   컴파일러   처리흐름
MVC 구조 (Model/View/ Controller) 스타일	- 모델(Data관리), View(UI관리), 제어(상호작용 정의)로 분리 - Data를 여러 개의 View로 표현하거나, View와 Controller가 Data보다 자주 변경될 경우 적합 - 상호작용 어플리케이션을 세개의 컴포넌트로 구분함. 모델 컴포넌트는 핵심 기능성과 데이터를 포함하며 뷰는 사용자에게 정보를 보여주고 컨트롤러는 사용자 입력을 다룸 예를 들어 핵심데이터를 다양한 그래프 형태로 보여주는데 사용됨		웹 어플   동일 모델에 대한 다양한 뷰   Front 페이지
클라이언트 /서버 (Client/Server) 스타일	- 서버는 클라이언트라 불리는 서브시스템에 서비스를 제공 - 클라이언트: 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 데이터 수집 - 서버: 트랜잭션을 수행하고 데이터의 일관성을 보장 - 여러 컴포넌트들을 걸쳐서 데이터와 데이터를 처리하는 프로세싱 부분이 분산되어 있는 어플리케이션에 적용하기 유용함. 하나 이상의 인터페이스를 통해 서비스가 제공되며 하나의 중앙 서버나 여러대의 분산 서버와도 통신이 가능함		3-tier 클라이언트-서버 모델
계층 구조 (Layered) 스타일	- 각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용 - 추상화의 성질을 이용한 구조 프레젠테이션 계층  (Presentation layer) 애플리케이션 계층  (Application layer) 비즈니스 논리 계층  (Business logic layer)  = 도메인 계층 (Domain layer) 데이터 접근 계층 (Data access layer)  = 영속 계층 (Persistence layer)		데스크톱 어플리케이션   OSI 7 Layers,   TCP/IP 5 Layers
마스터 슬레이브 패턴	- 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산 - 슬레이브가 반환한 결과값에서 최종 결과값을 계산		하둡   분산 시스템
브로커 (Broker) 패턴	- 메시지 기반 분산 시스템 - 브로커는 컴포넌트 간 제어를 조정, 컴포넌트들은 원격 서비스 실행을 통해 상호 작용 - 서버는 자신의 기능들(서비스 또는 메세지)을 브로커에 전송(publish) - 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리디렉션하거나 메시지를 수신 - 중앙에 HUB라는 브로커를 두고 지국의 모든 통신은 HUB의 중개 하에 이루어짐. HUB는 메시지 라우팅(전달)을 담당함 - 지국에는 Agent가 설치됨. Agent는 메시지 변환을 담당함 - 장점은 신뢰성 있는 전달이 가능하다는 것이지만 단점은 모든 통신이 중앙의 HUB가 관여하므로 속도가 덜어짐		Kafka   RabbitMQ   ActiveMQ
Peer-To-Peer 패턴	- Peer는 클라이언트로서 상대 Peer에게 서비스를 요청할 수도 있고, 서버로서 각 Peer 에게 서비스를 제공할 수 있음 - Pear는 클라이언트 또는 서버 혹은 둘 모두로서 동작할 수 있으며, 시간이 지남에 따라 역할이 유동적으로 바뀔 수 있음		P2P 기반 파일 / 멀티미디어 공유 서비스
이벤트 버스 패턴	- 이벤트 소스 (event source) - 이벤트 리스너 (event listener) - 이벤트버스(event bus), 채널 - 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행(publish) - 리스너는 특정 채널에서 메시지를 구독 (subscribe) - 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받음 - 버스기반 아키텍처는 중앙의 HUB가 없기 때문에 Agent가 해야할 역할이 늘어남 - 지국 각각이 서로 통신하므로 속도가 빠르고 확장성이 좋지만 신뢰성이 브로커기반보다 낮음		안드로이드
인터프리터 (Interpreter)	- 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계 - 특정 언어로 작성된 문장 혹은 표현식이라고 하는 프로그램의 각 라인을 수행하는 방법을 지정 - 기본 아이디어는 언어의 각 기호에 대해 클래스를 만드는 것		SQL Parser,   통신프로토콜   정의 언어
MVVM 패턴 (Model-View-View Model)	- Model, View, Viewmodel, Binder로 구성 - Model은 도메인 모델(데이터)를 관장하고, View는 실제 사용자에게 보이는 Presentation Layer를 담당 - Binder에 의해 View model에서 제공하는 Business logic의 결과를 사용자에게 제공		WPF (Windows Presentation Foundation)   Android 에서 사용

 

---

2015년 47번

정답 : 4번

A 모델, B 뷰, C 제어

- 컨트롤러에서 모델로 '변경'함수 호출 : 컨트롤러는 모델의 데이터를 변경할 수 있음

- 컨트롤러에서 뷰로 '생성과 변경'함수 호출 : 컨트롤러는 사용자 UI인 뷰를 생성하고 필요하다면 UI 내용 중 일부를 변경할 수 있음

- 모델에서 뷰로 '변경통지' 함수 호출 : 모델은 자기가 관리하는 데이터의 변경이 발생되었을 때 사용자 UI인 뷰에게 이를 통지할 수 있음

 

---

2014년 50번

정답 : 2번

MVC모델은 같은 모델에 대하여 여러가지 뷰가 필요한 상호작용 시스템에 적합한 구조임

저장소 구조 (Repository Architecture) 스타일	- 서브 시스템이 단일 중앙 저장소의 자료를 접근하고 변경 - 서브시스템들이 독립적이고 중앙 자료 저장소를 이용하여 상호 대화, 여러 모듈에서 사용함 - 중심이 되는 문제에 대해 논증되고 유지되는 복잡한 정보를 갖고 있는 어플리케이션에 적합한 스타일로 리파지토리 시스템은 speech 그리고 pattern 인식 같은 전통적으로 단일 프로세스의 복잡한 변환을 요구하는 어플리케이션을 자주 사용됨		데이터 베이스 시스템
Data Flow (Pipes and Filters) 스타일	- 서브시스템이 입력 데이터를 받아 처리 -> 결과를 다른 시스템에 보내는 작업이 반복 - 서브 시스템은 필터, 사이의 연결관계는 파이프 - 각 필터는 입력 파이프에 받은 데이터의 내용과 형식만을 알고 그것을 생성한 필터에 대하여는 모름 - 파이프와 필터 구조는 변경 가능하며, 필터는 다른 필터와 교환될 수 있고 다른 목적으로 재구성 - 데이터의 스트림을 처리하는 시스템을 위한 구조를 제공하며 입력되는 데이터가 해당 필터에 관련이 되면 처리를 하고 아니면 그냥 흘러보내는 구조에 유용함. 파이프와 필터 아키텍처로서 가장 잘 알려진 예는 Unix와 Shell을 들 수 있음. Unix는 연결 컴포넌트를 위한 표기법의 제공과 pipe를 구현하기 위한 런 타임 메커니즘의 제공으로 이 스타일을 지원함		파이프 필터   컴파일러   처리흐름
MVC 구조 (Model/View/ Controller) 스타일	- 모델(Data관리), View(UI관리), 제어(상호작용 정의)로 분리 - Data를 여러 개의 View로 표현하거나, View와 Controller가 Data보다 자주 변경될 경우 적합 - 상호작용 어플리케이션을 세개의 컴포넌트로 구분함. 모델 컴포넌트는 핵심 기능성과 데이터를 포함하며 뷰는 사용자에게 정보를 보여주고 컨트롤러는 사용자 입력을 다룸 예를 들어 핵심데이터를 다양한 그래프 형태로 보여주는데 사용됨		웹 어플   동일 모델에 대한 다양한 뷰   Front 페이지
클라이언트 /서버 (Client/Server) 스타일	- 서버는 클라이언트라 불리는 서브시스템에 서비스를 제공 - 클라이언트: 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 데이터 수집 - 서버: 트랜잭션을 수행하고 데이터의 일관성을 보장 - 여러 컴포넌트들을 걸쳐서 데이터와 데이터를 처리하는 프로세싱 부분이 분산되어 있는 어플리케이션에 적용하기 유용함. 하나 이상의 인터페이스를 통해 서비스가 제공되며 하나의 중앙 서버나 여러대의 분산 서버와도 통신이 가능함		3-tier 클라이언트-서버 모델

 

---

2015년 48번

정답 : 2번

나. 전체 시스템에 대한 설계 목표를 파악하고 결정한다. 즉, 전체 시스템의 목표를 요구에서 발견하고 추출한다.

다. 설계 목표와 시스템의 타입을 고려하여 아키텍처 스타일을 선택한다.

마. 적용할 수 있는 아키텍처 스타일이 있다면 이를 적용하여 시스템 표준 아키텍처를 설계하고, 없다면 맞춤형 아키텍처를 설계한다.

가. 서브시스템 사이의 인터페이스를 정의하고 서브시스템 사이의 상호작용을 위한 동작을 작성한다.

라. 설계한 아키텍처가 요구, 설계목표, 설계 원리를 만족시켰는지를 검토한다.

 

목타스서만

 

---

2015년 50번

정답 : 3번

마이크로 오븐 제어 제어 소프트웨어와 같은 임베디드 소프트웨어는 하나의 모듈로서 집약화를 하는 경우가 많기 때문에 계층형 아키텍처에 맞지 않음

 

---

2015년 97번

정답 : 3번

메시지 변환을 하는 것은 지국이 아니라 Agent임

브로커 (Broker) 패턴

- 메시지 기반 분산 시스템 - 브로커는 컴포넌트 간 제어를 조정, 컴포넌트들은 원격 서비스 실행을 통해 상호 작용 - 서버는 자신의 기능들(서비스 또는 메세지)을 브로커에 전송(publish) - 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리디렉션하거나 메시지를 수신 - 중앙에 HUB라는 브로커를 두고 지국의 모든 통신은 HUB의 중개 하에 이루어짐. HUB는 메시지 라우팅(전달)을 담당함 - 지국에는 Agent가 설치됨. Agent는 메시지 변환을 담당함 - 장점은 신뢰성 있는 전달이 가능하다는 것이지만 단점은 모든 통신이 중앙의 HUB가 관여하므로 속도가 덜어짐

Kafka   RabbitMQ   ActiveMQ

이벤트 버스 패턴

- 이벤트 소스 (event source) - 이벤트 리스너 (event listener) - 이벤트버스(event bus), 채널 - 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행(publish) - 리스너는 특정 채널에서 메시지를 구독 (subscribe) - 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받음 - 버스기반 아키텍처는 중앙의 HUB가 없기 때문에 Agent가 해야할 역할이 늘어남 - 지국 각각이 서로 통신하므로 속도가 빠르고 확장성이 좋지만 신뢰성이 브로커기반보다 낮음

안드로이드

 

---

2017년 33번

정답 : 3번

일반적인 컴파일러 구조

소스코드 -> 컴파일러 -> 목적코드 -> 링커 ->실행파일

특정 모듈의 OUTPUT이 다음 모듈의 INPUT으로 사용되며, 중간 과정물을 저장하고 활용하기 위한 아키텍처 스타일은 Pipe & Filter구조와 Repository 구조가 가장 적절함

 

---

2020년 27번

정답 : 4번

MVC 는 Model, View, Controller의 약자임

 

• Model : 프로그램에서 사용되는 실제 데이터 저장 및 데이터 조작 로직을 처리하는 부분
• View : 사용자에게 실제로 제공되어 보여지는 UI부분
• Controller : 사용자의 입력처리와 흐름 제어를 담당

 ▶ MVC 모델 작동 순서

   1. Controller로 사용자의 입력 들어옴

   2. Controller로 Model에 데이터 업데이트를 하고 Model 호출함

   3. Model은 해당 데이터로 보여줄 View를 업데이트하여 화면에 보여 주게 됨

 

 ▶ MVC 모델 단점

   View와 Model이 서로 의존적