---

title: MVC Its Past and Present sidebar: auto

이 문서는 MVC 마지막 개정 논문인 The Model-View-Controller (MVC) Its Past and Present를 번역한 문서입니다.

요약

MVC는 1978년에 특정 문제에 대한 설계 솔루션으로 구상되었다. 최상위 목표는 관련 정보 공간에 대한 사용자의 멘탈모델을 지원하고 사용자가 이 정보를 검사하고 편집할 수 있도록 하는 것이었다.

첫 번째 부분에서는 원래 문제를 설명하고 선택한 솔루션에 대해 설명합니다.

두 번째 부분에서는 원래의 아이디어를 설명하고 현재의 당면 과제를 원래 목표까지 포함하도록 범위를 확장합니다. 문헌에서 발견되는 MVC와 관련된 몇 가지 아이디어를 검토하고, 최상위 목표와 특별히 관련이 있는 것으로 보이는 아이디어를 선택합니다.

그것은 모두 요약된 MVC 패턴 언어로 요약되어 있습니다.

공지

This presentation is copyright ©2003 Trygve Reenskaug, Oslo, Norway. All rights reserved. 개인 또는 강의실 사용을 위해 이 작업의 일부 또는 전부를 디지털 또는 하드 카피할 수 있는 권한은 해당 사본이 이익 또는 상업적 이익을 위해 만들어지지 않으며 사본이 첫 페이지에 이 통지 및 전체 인용을 포함하는 경우 수수료 없이 부여된다.

1.소개

이 프레젠테이션은 InfoBOARD 프로젝트의 일부로서 거주 가능한 IT 기술을 만드는 데 도움이 되는 IT 기술을 살펴봅니다 정보 시스템 이 프로젝트의 범위는 다음과 같은 주요 영감의 원천으로 표시됩니다. 이 이야기는 인간과 기계의 사이를 메우는 데 초점을 맞추고 있다.

2. MVC 패턴 언어

다음은 MVC 아이디어를 기반으로 하는 시스템 아키텍처의 패턴 언어의 첫 번째 초안입니다. 패턴은 패턴 커뮤니티가 설정한 엄격한 요구 사항을 충족하지 못할 수 있습니다. 특히

• 구현 경험이 아닌 아이디어를 나타내는 몇 가지 패턴
• 흥미로운 공개 도메인 패턴에 대한 참조는 완료예정입니다.
• 패턴은 한 명의 저자에 의해 작성되었고 지역사회에서 논의되지 않은 반면에, 모든 패턴은 알렉산더의 정신에 있습니다; 모든 패턴은 사람들의 요구와 거주 가능한 정보를 만들고자 하는 욕구에 의해 자극을 받습니다.

MVC 패턴 언어의 이 초안 버전의 패턴은 프리젠테이션과 함께 개발되었습니다. 따라서 패턴은 해당 프레젠테이션 슬라이드로 장식됩니다. 이 첫 번째 패턴 언어는 다음과 같은 패턴으로 구성됩니다.

• P-1: 통합 도메인 서비스(2페이지)
• P-2: 라인 부서에서 도메인 구성 요소 소유(3페이지)
• P-3: 멘탈 객체 모델(4페이지)
• P-4: 개인 정보 시스템(7페이지)
• P-5: 도메인/사용자 매트릭스(8페이지)
• P-6 : 모델/에디터 분리(9페이지)
• P-7: 입력/출력 분리(10페이지)
• P-8: 타스용 공구(MVC/1979)(11페이지)
• P-9: 컴포지트 공구(MVC/1979)(12페이지)
• P-10: 동기식 선택(13페이지)
• P-11: 동기식 모델 및 보기(14페이지)

P-1: 통합 도메인 서비스

컨텍스트

기업은 도메인과 같은 여러 가지 다양한 비즈니스 기능을 처리합니다. 설계, 재료 관리, 계획, 제어 및 재무 등이 그 예입니다.

문제

기업은 이러한 도메인을 통합 정보 시스템으로 지원해야 합니다.

솔루션

각 비즈니스 도메인에 대해 별도의 도메인 서비스를 생성합니다. 예를 들어 이러한 각 서비스는 공통 데이터 베이스 또는 긴밀하게 연결된 상호 작용 서비스를 통해 내부적으로 긴밀하게 통합되어야 한다. 도메인 간의 통합은 도메인 서비스 외부에 있는 메커니즘을 통해 이루어집니다. 도메인 서비스는 여러 비즈니스 조직 및 여러 기업에 걸쳐 있을 수 있습니다.

영향력

• 대규모 도메인 서비스는 다루기 어렵고, 설계하기 어렵고, 구현하기 어렵고, 수정하기 어려울 수 있습니다.
• 소규모 도메인 서비스는 전체 시스템의 단편화를 유도하고 도메인 간의 통합을 어렵게 만듭니다.

알려진 사용

이는 시스템 아키텍처에 대한 일반적인 접근 방식입니다. 도메인 서비스를 애플리케이션이라고 합니다. 기능 간의 통합은 종종 특별하다.

See also

P-2: LINE DEPARTMENT OWNS DOMAIN COMPONENTS (page 3)

History

August 2003: First draft of this pattern

P-2: 라인 부서에서 도메인 구성 요소 소유

컨텍스트

비즈니스 도메인은 종종 라인 조직의 여러 책임 부서에 걸쳐 있습니다. 예를 들어 선박 건설 도메인은 스팬 계약, 주 설계, 상세 설계 및 워크샵을 수행할 수 있다. 설계 도메인 서비스는 전체적으로 제공되지만, 많은 라인 부서와 책임 영역에 걸쳐 있습니다.

문제

일반적으로 새 도메인 서비스 또는 수정된 도메인 서비스의 사양 중에는 다른 부서에 문의합니다. 개별 부서의 영향은 제한적인 경향이 있는데, 그 이유는 전체 명세서가 종종 상충되는 이해관계를 절충하기 때문이다. 부서와 개인에게 그들의 책임과 권위를 맞추기 위해서 그들의 정보에 대한 더 나은 통제권을 주는 것은 바람직해 보입니다.

솔루션

각 도메인 서비스를 여러 상호 작용하는 도메인 구성 요소로 분해하여 각 구성 요소가 라인 구성에 하나의 소유자를 갖도록 합니다. 이런 식으로 각 부서는 그것에 중요한 전체 서비스의 일부를 관리합니다. 각 구성요소의 내부는 로컬로 제어되는 반면 전체 관심사는 인터페이스 제어를 통해 관리됩니다.

영향력

• 사업 영역 서비스의 분해는 개인 소유자를 강화하는 동시에 전체를 약화시킨다.
• 현 라인 조직과 긴밀하게 연결된 도메인 서비스 아키텍처로 인해 조직을 변경하기가 어렵습니다.
• 개인별 특이사항과 밀접하게 연계된 도메인 서비스 아키텍처는 이동 시 어려움을 일으킬 수 있습니다.
• 컴퓨팅 효율성이 저하되고 보안 위험이 가중될 수 있습니다.
• 하위 계층의 중앙 소유권과 상위 계층의 로컬 소유권이 있는 다계층 솔루션을 고려할 수 있습니다.

Known Uses

이 패턴의 알려진 구현은 없다.

See also

• http://www.c2.com/cgi/wiki?DistributionOfComponents.
• P-4: PERSONAL INFORMATION SYSTEMS (page 7)
• P-5: DOMAIN/USER MATRIX (page 8)

History

1973: Ideas first presented at the ICCAS Conference in Tokyo, Japan. [Ree-73] August 2003: First draft of this pattern

P-3: 멘탈 객체 모델

컨텍스트

대부분의 제품은 제품 릴리스의 증분 단계에서 개발됩니다. 명시적인 전체 모델은 없으며, 대부분의 제품에는 모든 제품 기능을 포함하는 참조 매뉴얼이 없습니다. 많은 개발자들이 앞에 모델을 만드는 것을 어려워합니다. 시스템 구조는 코드 형태로 직접 형성될 때 진화합니다. 이것은 시스템 개발이 미지의 영역으로의 전환이라는 개념을 뒷받침합니다. 많은 버전의 시스템은 개발자들이 요구 사항을 이해한다고 느끼기 전에 아마도 출시되었을 것입니다. 그리고 이러한 이해는 사용자들의 이해와 요구사항이 깊어지고 진화하기 때문에 움직이는 목표입니다.

정보 시스템을 사용자가 관리할 수 있도록 하는 방법은 세 가지가 있습니다.

1. 사용자가 수행할 수 있는 각 작업에 대해 팝업을 제공합니다. 이 접근법의 문제점은 초보자들이 지금 당신의 퍼지우그 ID를 입력하라는 어휘를 이해하지 못할 수도 있다는 것입니다. 경험이 많은 사용자는 시스템 설계자가 고려하지 않는 작업을 자주합니다. 그리고 전문가들은 팝업이 번거롭고 사용이 느리다고 생각합니다.

2. 도움 시스템 제공 우리는 같은 어휘의 어려움을 발견합니다. 게다가, 모든 세부사항에 대한 도움을 제공하는 것은 대개 불가능합니다. 대부분의 도움말 시스템에는 모든 메뉴 항목과 대화 상자 요소에 대한 항목도 없습니다. 이 해결책들 중 어느 것도 만족스럽지 않습니다. 아티팩트를 관리할 수 있는 유일한 방법은 사용자가 시스템의 멘탈모델을 구축하는 것입니다. 하지만, 만약 정신적 모델이 처음부터 공예품 안으로 만들어지지 않았다면 이것은 불가능합니다. 나중에 생각해보면, 그것은 실패할 운명입니다. 어떤 기준들은 우리 사업에서 일반적으로 받아들여집니다. UML은 시스템 아키텍처 및 설계를 위한 표준 모델링 언어입니다. 그러나 나는 특별히 사용자의 정신적 모델을 구축하고 실행하는 것을 목표로 하는 모델링 언어에 대해서는 알지 못합니다.

문제

문제는 사용자에게 실행 가능한 멘탈모델을 만들 수 있는 권한을 부여하는 것이다. 정보 시스템의 경우, 이는 사용자가 사용자와 시스템 설계자 간에 공유할 수 있는 모델링 언어를 내부화해야 함을 의미합니다.

두가지 문제가 있다. 첫째, 이 모델링 언어의 본질은 무엇인가? 둘째, 어떻게 시스템을 설계할 수 있는가 하면 사용자가 시스템에 자신의 멘탈모델이 반영되어 있는 것을 볼 수 있습니다. 첫 번째 패턴은 여기서 다룰 것이며 두 번째 패턴은 다른 패턴(아래의 "참조"에서 더보기)으로 분류할 것입니다.

멘탈모델은 개인의 마음속에 존재하는 요소로부터만 만들어질 수 있습니다. 애플의 데스크톱 은유는 잘 알려진 환경을 묶는 하나의 예입니다. 이것은 오늘날의 복잡한 정보 시스템에 충분하지 않습니다. 많은 사람들이 현재 정보 시스템의 사용자이지만, 그들의 멘탈모델은 단편적이고 종종 부정확합니다. 과제는 시스템 설계자가 시스템을 설계할 때 사용할 수 있고 사용자가 강력하고 정확한 멘탈모델을 구축하기 위해 사용할 수 있는 "세계의 지식"으로 모델링 언어를 설정하는 것입니다.

솔루션

사용자의 모델링 언어가 상호 작용하는 물체의 개념에 기초하도록 합니다. (참고: UML 구성요소는 UML 클래스의 하위 클래스이므로 객체가 구성요소의 인스턴스뿐 아니라 클래스도 될 수 있습니다. 이는 객체가 복합적일 수 있고 다른 객체가 캡슐화될 수 있음을 의미합니다.) 예를 들어, 활동 계획 및 제어 시스템을 고려합니다. 리소스, 제품 및 활동을 시스템에서 개체로 표시할 수 있습니다. 계획 및 기타 프로세스는 이러한 개체 간의 상호 작용을 통해 실현할 수 있습니다.

사용자의 멘탈모델을 구축하는 데 사용되는 언어는 사용자의 수동적 단어(즉, "자기 증명") 내에 있어야 합니다. 이 언어의 정교함은 만약 정교한 언어가 "세상의 지식"이 된다면 증가할 수 있습니다. 일반적으로 알려진 이러한 언어는 UML 프로파일 또는 필요한 경우 새로운 언어가 될 수 있습니다. 위의 문단에서 언급한 바와 같이, 요구사항이 시간이 지남에 따라 진화하기 때문에 새로운 시스템을 설계하는 것은 악명 높을 정도로 어렵습니다. 해결책은 모델링 언어가 프로그래밍 언어가 되도록 하는 것일 수 있습니다. UML은 프로그래밍 언어가 되는 것에 매우 가깝습니다. 이 모델링/프로그래밍 언어는 첫 번째 실험부터 요구사항의 진화 및 수많은 출시 주기를 통해 제품 수명 전 단계에서 사용될 수 있습니다. OMG는 MDA(모델 기반 아키텍처)를 개발합니다. 이 계획은 유망하며 사용자 멘탈모델과 프로그램을 동시에 발전시키는 데 일반적으로 알려진 언어와 방법의 시작이 될 수 있습니다. 마지막으로, 충분히 강력한 언어가 충분히 알려지면, 사용자 스스로 프로그램을 읽고 쓰는 것을 위해 길이 열릴 것입니다.

영향력

사용자들은 그들의 전문 분야 내에서 정교한 경향이 있다. 그러므로 실제 요구사항은 대개 상당히 복잡하다. 이는 모델과 모델링 언어에 큰 부담을 줍니다. 사람들은 주제를 마스터하기 위해 온 힘을 다 습니다. 공식 모델링 언어는 강하게 좌뇌입니다. 이것은 우뇌 현상을 모델링하는 것을 어렵게 만듭니다. 이러한 불일치는 범용 모델링/프로그래밍 언어 개발 중에 신중하게 고려해야 합니다.

알려진 사용

물체 기반의 모델링 언어가 사람들이 받아들일 수 있다는 두 가지 징후가 있습니다. 하나는 1978년 제록스 파에서 실험한 것인데, 그 곳에서 우리는 새로운 반도체 생산 시설을 위한 계획 시스템을 개발하였다. 그 시설 관리자는 실리콘 웨이퍼, 공정 및 장비 측면에서 생각하고 있었습니다. 스몰토크 개발자가 스몰토크 객체와의 상호작용을 고려하고 있을 때 관리자와 개발자의 의사소통은 매우 원활히 이루어졌고, 객체 모델이 사용자에게 정보 시스템을 효과적으로 제어할 수 있다는 우리의 믿음을 확인시켜 주었습니다.

또 다른 지표는 우리 회사 Taskon이 90년대에 은행에서 여러 프로세스 모델링 프로젝트를 수행했다는 것입니다. 우리는 항상 객체 모델이 사용자 커뮤니티에 자연스러움을 느꼈으며, 자신의 프로세스에 대해 정확히 생각할 수 있도록 했습니다.

See also

P-4: PERSONAL INFORMATION SYSTEMS (page 7)

History

1977: Ideas first presented at the IFIP Conference in Toronto, Canada. [Ree-77] August 2003: First draft of this pattern

P-4: 개인 정보 시스템

컨텍스트

기업은 사람과 기계가 수행하는 역할을 정의하는 라인 조직을 가지고 있습니다. 각 역할에는 관련된 책임, 권한 및 역량 집합이 있습니다. 역할의 예로는 설계자, 회계사, 기계 운영자가 있습니다.

문제

개인은 여러 도메인과 관련된 태스크를 수행합니다. 예를 들어 설계자는 자신이 담당하는 설계 영역 부분뿐만 아니라 참조 목적을 위해 설계 영역의 다른 부분에도 완전히 접근해야 합니다. 설계자는 또한 재료 관리 서비스의 자재 사용 가능 여부, 회계 서비스의 시간표 작성, 계획 및 관리 서비스에 대한 보고서 진행 여부 등을 확인할 수 있습니다. 개인은 다양한 업무에서 자신을 지원할 수 있는 업무 지향적 도구가 필요합니다.

솔루션

다양한 작업을 지원하는 개별 도구를 제공합니다. 이러한 도구를 사용자의 모든 작업을 지원하는 개인 컴퓨터에 내장할 수 있습니다. 필요에 따라 각 도구가 하나 이상의 도메인 서비스에 액세스하도록 합니다.

영향력

• 작업이 자주 변경되는 경향이 있으며, 특수 도구가 필요할 수 있는 비상 상황이 발생하는 것으로 알려져 있습니다.
• "우리 회사의 유일한 안정적 특징은 변화한다는 것입니다." 두 세력 모두 신속하고 저렴한 도구 개발을 요구합니다. 이는 단순성 또는 (반)자동 도구 생성을 통해 실현할 수 있습니다.

사람들의 일은 종종 복잡합니다. 이것은 강력한 도구가 필요합니다. 사람들의 과제는 종종 여러 가지 영역을 포함합니다. 따라서 이 도구는 여러 도메인에 걸친 통합 지점입니다. 4계층은 View, Application Model, Domain Model 및 Infrastructure라고 하는 4계층도 참조하십시오.

알려진 사용

노르웨이 엑시 제품은 업무, 자원 및 생산을 위해 자동으로 생성된 맞춤형 도구가 사용자를 배경 정보 시스템에 연결하는 유연한 관리 솔루션을 신속하게 구현합니다.

참조

P-5: 도메인/사용자 매트릭스(8페이지)

역사

• 1999년 6월: TOOLS 유럽 99 키노트: "T. Reenskaug: 컴포넌트 기반 개발 - 트루 오브젝트 방향".
• 2003년 8월: 이 패턴의 초안

P-5: 도메인/사용자 매트릭스

컨텍스트

P-2: 라인 세부 사항 도메인 구성 요소(3페이지)는 각 도메인 서비스를 여러 도메인 구성 요소로 분해하도록 지시했습니다. P-3: 멘탈 객체 모델(4페이지)과 P-4: 개인 정보 시스템(7페이지)은 사용자의 정신 모델이 사용자 인터페이스를 통해 액세스할 수 있고 도메인 서비스의 실제 성격과 일치하지 않을 수도 있는 객체 모델이어야 한다고 제안했습니다.

문제

도메인 서비스는 효율성과 정보 무결성을 위해 구현되는 반면 최적의 멘탈모델은 사용자와 그의 직무에 따라 달라진다. 도메인 서비스가 다른 사용자의 멘탈모델에 해당한다는 보장은 없다. 만약 그들이 그렇게 한다면, 아무 문제가 없다. 만약 그들이 그러지 않는다면, 우리는 그 차이를 메워야 한다.

솔루션

도메인 구성 요소에서 일반 정보 및 동작을 추출합니다. 중앙 집중식으로 제어되는 백그라운드 도메인에서 일반적인 정보와 동작을 구현합니다. 슬라이드에 나와 있는 것처럼 도메인 서비스 구성 요소 위에 비즈니스 개체의 새 계층을 만듭니다. 각 비즈니스 객체가 필요에 따라 도메인 서비스를 사용하여 시스템이 사용자의 정신적 모델을 구현한다는 착각을 일으키게 합니다. ("비즈니스 객체"라는 용어는 OMG 이니셔티브에서 사용됩니다. 여기서 이 용어는 OMG 용도와 일치하지 않을 수 있습니다.)

영향력

공통 도메인 논리 및 정보를 비즈니스 개체로, 라인 조직의 관리 하에 이동하는 경향이 있을 수 있습니다. 유지보수를 간소화하고 중앙 제어를 유지하기 위해 로컬 로직과 정보를 도메인 서비스로 이동하는 경향이 있을 수 있습니다.

참조

• P-6: 모델/에디터 분리(9페이지)
• P-7: 입력/출력 세션(10페이지)

역사

1973년 8월: 위의 수치는 2003년 8월: 첫 번째 패턴 버전.

P-6 : 모델/에디터 분리

컨텍스트

사용자는 비즈니스 객체(8페이지의 P-5)를 연구하고 상호 작용하기를 원합니다.

문제

사용자는 비즈니스 개체에 존재하는 정보를 검사하고 편집할 수 있습니다.

• 이러한 개체는 사용자 인터페이스를 포함하는 노드에서 직접 액세스할 수 없습니다.
• 너무 복잡해서 직접 볼 수 없음
• 각 버전은 동일한 정보에 대해 서로 다른 프레젠테이션 및 작업을 수행해야 할 수 있습니다.

솔루션

각 비즈니스 개체를 사용자와 도메인 서비스에 가까운 두 부분으로 나눕니다. 우리는 이러한 객체들을 각각 Editor와 Model이라고 부릅니다. Model은 사용자의 심적 모델을 반영하여 정보와 동작으로 사용자의 객체 모델을 고정합니다. Editor는 프리젠테이션 및 사용자 작업을 담당합니다. 모델은 에 정의된 대로 Facade로 구현될 수 있습니다.

Editor는 예를 들어 Java Swing 구성요소로 직접 코딩될 수 있으며, Java Bean일 수도 있고, GUI 페인트 또는 모델 코드에 반영되어 자동으로 생성될 수도 있습니다.

영향력

• 강력하고 이해할 수 있는 모델링 언어가 사용자의 멘탈모델의 생성과 실현을 촉진합니다.
• 복잡한 사용자가 필요한 경우 정교한 편집자가 필요합니다. 자동 또는 반자동 편집기 생성은 다양한 사용자 작업에 대한 신속한 적응을 촉진합니다.

See also

• P-7: INPUT/OUTPUT SEPARATION(MVC/1980) (page 10)
• P-9: TOOL AS A COMPOSITE (MVC/1979) (page 12)
• P-11: SYNCHRONIZE MODEL AND VIEW (page 14)

History

• 1979: This idea was part of the original MVC. [MVC-1], [MVC-2]
• May 2001: MVC pattern written for Mogul patterns workshop.
• August 2003: Above pattern refactored and revised

P-7: 입력/출력 분리 (MVC/1980)

컨텍스트

9페이지의 P-6에 설명된 편집기는 입력과 출력을 동일한 객체에 결합합니다.

문제

Editor의 입력 및 출력 측면은 기술적으로 매우 다르며 상호 종속성이 거의 없습니다. 단일 개체에서 이러한 개체를 조합하면 이 개체를 불필요하게 복잡하게 만드는 경향이 있습니다.

솔루션

Editor 객체에 두 개의 객체가 포함되도록 합니다. 즉, 프레젠테이션을 담당하는 View 객체와 사용자로부터 입력을 수신하고 해석하는 Controller 객체가 포함됩니다. 그림에는 Smalltalk-80 솔루션을 설명하는 UML 공동 작업 모델이 나와 있습니다.

이 그림은 SmallTalk 클래스 라이브러리에서 가져온 클래스 계층의 예를 보여 줍니다.

영향력

• 간단한 경우 Model, View 및 Controller 역할을 동일한 개체로 수행할 수 있습니다. 예: 스크롤 막대.
• View(보기) 및 Controller(컨트롤러) 역할은 매우 긴밀하게 연결되어 있을 때 동일한 객체에 의해 수행될 수 있습니다. 예: 메뉴.
• 일반적으로 세 개의 다른 물체에 의해 연주될 수 있습니다. 예: 객체 지향 설계 모델.

참조

• P-8: 타스크(MVC/1979)용 공구(11페이지)
• P-10: 동기식 선택 (13쪽)

역사

• 1980: 이것은 Smalltalk-80 클래스 라이브러리의 MVC입니다.
• 2003년 8월 : 위에서 발췌한 패턴의 최초 초안

P-8: 작업용 툴(MVC/1979)

컨텍스트

사용자의 심적 모델을 반영하는 전면이 있는 사용자와 모델 객체.

문제

사용자에게 하나 이상의 작업을 수행하기 위한 도구를 제공합니다. 이 도구는 사용자가 모델과 직접 상호작용하는 착각을 일으켜야 한다.

솔루션

필요한 편집자가 포함된 도구 개체로 사용자 인터페이스를 생성합니다. 일부 또는 모든 편집자는 그림과 같이 View-Controller 조합으로 분할할 수 있습니다(10페이지의 P-7 참조).

영향력

• 간단한 경우, 툴은 단일 Editor로 구성될 수 있다. 그런 다음 이 편집기는 도구 역할도 수행합니다.
• 복잡한 작업에 여러 편집자가 필요할 수 있으며, 이를 조정하려면 별도의 도구 개체가 필요합니다.

참조

• P-9: 컴포지트 공구(MVC/1979)(12페이지)
• P-10: 동기식 선택 (13쪽)
• P-11: 동기식 모델 및 뷰(14페이지)

역사

• 1979년 : 이것은 원래의 MVC[MVC-1]입니다.
• 2001: 모굴 패턴 워크샵을 위해 작성된 MVC 패턴 초안
• 2003년 8월 : 위에서 발췌한 패턴의 최초 초안

P-9: 컴포지트 툴(MVC/1979)

컨텍스트

사용자는 상호 연결된 개체의 구조로 복잡한 모델 빌드를 검사하고 운영할 수 있습니다. 예를 들어, 여러 활동 및 리소스로 구성된 프로젝트를 생각해 보십시오. 해당 모델은 슬라이드 왼쪽에 도해되어 있으며, 다양한 측면을 동시에 나타낼 수 있습니다.

문제

사용자 인터페이스를 구성해 이 요구사항을 간단하고 일반적인 방법으로 지원한다.

솔루션

시스템을 네 가지로 구분하여 이러한 역할을 수행하는 명확하게 구분합니다.

1. 목표와 과제를 가진 사용자.
2. 사용자의 멘탈모델의 상태, 구조 및 행동을 나타내는 모델.
3. 적절한 방식으로 관련 정보를 표시하고 해당 시 이 정보의 편집을 지원하는 하나 이상의 편집자
4. 편집자를 설정하고 조작을 조정하는 도구 (예: 여러 편집기에서 볼 수 있는 모델 객체 선택). 복잡한 편집기는 다시 보기와 컨트롤러로 세분될 수 있습니다.

알려진 용법.

이 패턴은 OOram 역할 모델링 도구 및 기타 프로그램에서 광범위하게 사용되었습니다. 그것은 또한 Exie 제품에서도 사용된다.

참조

• P-8: 타스크(MVC/1979)용 공구(11페이지)
• P-10: 동기식 선택 (13쪽)
• P-11: 동기식 모델 및 뷰(14페이지)

역사

• 1979년: 이것은 원래의 MVC입니다.
• 2001: 모굴 패턴 워크샵을 위해 작성된 MVC 패턴 초안
• 2003년 8월 : 위에서 발췌한 패턴의 최초 초안

P-10: 동기식 선택

컨텍스트

우리는 같은 물체의 다른 View를 보여주는 Tool를 가지고 있습니다.

문제

사용자는 View 중 하나에서 하나 이상의 개체를 선택합니다. 선택한 객체가 표시되는 모든 View에 선택 사항이 나타나야 객체 모델 착각을 유지할 수 있습니다.

솔루션

모든 관련 View를 알고 있는 객체가 선택하도록 합니다. 도구는 이러한 개체의 예입니다. 간단한 예는 ST-80 MVC에서 책임의 분할입니다. 선택 MSC는 슬라이드에 왼쪽의 슬라이드에 표시됩니다. 다음은 OOram이 이러한 패턴을 구현하는 방법을 보여주는 또 다른 MSC입니다.

영향력

• 많은 객체의 선택과 퇴출이 매우 복잡할 수 있습니다.

알려진 사용

이 패턴은 OOram 모델링 도구에서 광범위하게 사용되었으며 Exie 제품에서도 사용됩니다.

참조

해당되지 않음.

역사

2003년 8월: 첫 번째 버전입니다.

P-11: 동기식 모델 및 뷰

컨텍스트

보기는 하나 이상의 모델 개체에서 검색하는 정보를 제공합니다.

문제

뷰는 모델 데이터를 화면 버퍼 및/또는 개인 메모리에 저장합니다. 이러한 데이터는 모델이 변경될 때마다 업데이트해야 합니다.이것은 [GOF]에서 관찰자 패턴의 특별한 경우입니다.

솔루션

뷰가 모델에 종속된 것으로 모델에 등록할 수 있도록 하고 모델이 변경될 때마다 모델에게 승인 메시지를 보내도록 합니다. 오른쪽에는 두 가지 예가 있습니다. 첫 번째는 ST-80 클래스 라이브러리에서 발견된 간단한 업데이트 솔루션입니다. 두 번째는 Views(보기)에 릴리스하기 전에 트랜잭션을 사용하여 변경 사항을 누적하는 OOram 솔루션의 요약입니다.

영향력

스몰토크 변경/업데이트는 스크린에서 많은 성가신 섬광을 일으킬 수 있다. 트랜잭션을 사용하면 각 (복합) 사용자 작업에 대해 업데이트 수를 1개로 줄일 수 있습니다. ChangeParameter를 사용하면 변경된 개체 속성을 식별하여 깜박임을 더욱 줄일 수 있습니다. (보기 및 모형에는 모델의 정보 검색 인터페이스에 공통 단어가 있습니다.) 모형에 모형 지오메트리가 있는 경우 보다 정교한 ChangeParameter는 변경의 영향을 받는 영역도 식별할 수 있습니다(예: 도면의 경우).

알려진 사용

이 패턴은 OOram 모델링 도구에서 광범위하게 사용되었습니다. 그것은 또한 Exie 제품에도 사용된다.

참조

해당되지 않음.

역사

2003년 8월: 첫 번째 버전입니다.

3. 미래

우리가 어디에 있지요? 그리고 우리는 여기서 어디로 가야 할까요?

1. 많은 사용자 인터페이스 문제를 이해하고 있으며, 문헌에서 더 많은 문제를 찾을 수 있습니다.
2. 공구 프로그래밍을 자동화해야 합니다. Naked Objects 프로젝트는 유망한 시작이다.
3. 건축과 사용자와 프로그래머들이 공통적으로 사용하는 언어로 더 많은 작업을 해야 합니다.

많은 주류 개발자들은 우리가 사용자들을 지원하기 위해 필요한 것은 그들의 요구사항과 선호도에 대해 그들에게 친절하게 물어보는 것이라고 믿는다. 나는 우리가 훨씬 더 필요하다는 것을 보여줬다. 우리는 사용자들이 시간이 지나면서 이해하고, 함께 일하고, 발전할 수 있는 시스템 모델이 필요하다. 간단히 말해서, 모든 사용자들은 자신의 거주 가능한 정보 환경을 필요로 한다. InfoBoard 프로젝트의 다음 단계는 인간적인 모델링과 프로그래밍 언어와 환경을 만들기 위해 노력할 것입니다.

원본

• The Model-View-Controller (MVC) Its Past and Present (Trygve Reenskaug, University of Oslo)