KR20150143473A - 재계산 사용자 인터페이스 내의 신호 캡처 컨트롤 - Google Patents

Abstract

재계산 사용자 인터페이스는 수신된 데이터에 응답하여 디스플레이하는 시각화 컨트롤과 대응하는 이벤트의 검출 시에 대응하는 환경 신호를 캡처하도록 각각 구성된 하나 이상의 신호 캡처 컨트롤을 포함한다. 선언적인 변환들의 변환 체인이 다양한 컨트롤 사이에 위치한다. 신호 캡처 컨트롤에 의해 캡처된 환경 신호의 예로는 이미지, 비디오, 오디오, 방향(orientation), 생체 인식, 위치, 날씨, 또는 환경에 대한 임의의 다른 정보를 들 수 있다. 이러한 신호 캡처 컨트롤을 재계산 사용자 인터페이스에 포함시키면, 캡처된 환경 신호가 변환 체인의 로직 및 다른 데이터에 포함될 수 있다. 또한 이러한 재계산 사용자 인터페이스의 작성을 허용하는 오서링 툴이 기술되어 있다.

Description

재계산 사용자 인터페이스 내의 신호 캡처 컨트롤{SIGNAL CAPTURE CONTROLS IN RECALCULATION USER INTERFACE}

"재계산 문서(recalculation document)"는 다양한 데이터 소스(data source)와 데이터 싱크(data sink)를 보여주는 전자 문서이며, 데이터 소스와 데이터 싱크 사이의 선언적인 변환(declarative transformation)을 허용한다. 다양한 데이터 소스와 데이터 싱크를 상호연결하는 임의의 소정의 변환 세트에 대해, 데이터 소스의 출력이 데이터 싱크에 의해 소비될 수도 있고, 또는 데이터 소스의 출력은 데이터 싱크에 의해 소비되기 전에 변환될 수도 있다. 이들 다양한 변환은 평가되어 결과적으로 재계산 문서를 통해 표현되는 하나 이상의 출력이 된다. 사용자는 코딩에 대해 깊이 알지 않고도 선언적인 변환을 추가, 삭제 및 편집할 수 있다. 이러한 편집은 자동으로 변환이 재계산되게 하며, 하나 이상의 출력에서 변화를 일으킨다.

재계산 문서의 일특정 예로는 셀들의 격자를 포함하는 스프레드시트 문서가 있다. 임의의 소정 셀은 셀 내에 디스플레이되는 특정 값을 출력하도록 평가되는 표현을 포함할 수 있다. 이 표현은 하나 이상의 다른 셀 또는 값과 같은 데이터 소스를 나타낼 수 있다.

통상적으로, 재계산 문서는 이들이 조작되는 환경에 대해 함수적인 의존성을 갖지 않는다. 재계산 문서는, 그 문서가 동서남북 어디를 향해 있는지에 관계없이, 재계산 문서 주위에서 관측가능한 이미지 및 사운드에 관계없이, 위치 및 고도에 관계없이, 날씨에 관계없이, 기타 등등에 관계없이 동일한 것을 수행한다. 재계산 문서는 단순히 환경에 의존하는 함수적인 성능을 갖는 것으로 생각되지는 않았다. 어쨌든, 재계산 문서는 그저 컴퓨터 내에서의 계산, 즉 일종의 가상 세계인 반면에, 환경은 실제 세계이다.

본 명세서에 기술된 적어도 일부 실시예는 수신된 데이터에 응답하여 디스플레이하도록 재구성되는 하나 이상의 시각화 컨트롤을 포함하는 재계산 사용자 인터페이스와 관련된다. 재계산 사용자 인터페이스는 또한 대응하는 이벤트의 검출 시에 대응하는 환경 신호를 캡처하도록 각각 구성된 하나 이상의 신호 캡처 컨트롤을 포함한다. 하나 이상의 선언적인 변환들의 변환 체인이 다양한 컨트롤 사이에 위치한다. 신호 캡처 컨트롤에 의해 캡처된 환경 신호의 예로는 이미지, 비디오, 오디오, 방향(orientation), 생체 인식, 위치, 날씨, 또는 환경에 대한 임의의 다른 정보를 들 수 있다. 이러한 신호 캡처 컨트롤을 재계산 사용자 인터페이스에 포함시키면, 캡처된 환경 신호가 변환 체인의 로직 및 다른 데이터에 포함될 수 있다. 본 명세서에 기술된 적어도 일부 실시예는 이러한 재계산 사용자 인터페이스의 작성을 허용하는 오서링 툴과 관련된다.

본 개요는 청구항의 청구대상의 핵심적인 특징이나 필수적인 특징들을 밝히고자 함이 아니며, 청구항의 청구대상의 범위를 결정하는 데 도움이 되고자 함도 아니다.

상기 및 다른 이점들 및 특징들을 얻을 수 있는 방식을 설명하기 위해, 첨부 도면을 참조하여 다양한 실시예에 대해 보다 구체적으로 설명할 것이다. 이들 도면은 샘플 실시예를 도시한 것일 뿐이며 따라서 본 발명의 범위를 한정하는 것으로 간주되어서는 안 된다는 점을 이해하기 바라며, 실시예들은 첨부 도면을 이용하여 보다 구체적이고 상세하게 설명할 것이다.
도 1은 본 명세서에 기술된 일부 실시예가 실시될 수 있는 컴퓨팅 시스템을 추상적으로 도시한 것이다.
도 2는 예시적인 재계산 사용자 인터페이스를 추상적으로 도시한 것으로, 중간 변환을 갖는 몇 개의 데이터 소스 및 데이터 싱크를 나타내며, 본 명세서에 기술된 보다 넓은 원리들을 설명하기 위해 제공된 특정 예로서 사용된다.
도 3은 도 2의 재계산 사용자 인터페이스와 같은 재계산 사용자 인터페이스를 작성하기 위한 오서링 사용자 인터페이스를 도시한 것이다.
도 4는, 변환 체인에 액세스하며 컴파일된 코드 및 의존성 체인(dependency chain)을 생성하는 컴파일러를 포함하는 예시적인 컴파일 환경을 도시한 것이다.
도 5는 재계산 사용자 인터페이스의 변환 체인을 컴파일하는 방법의 흐름도이다.
도 6은, 입력 데이터에 의존하는 뷰 컴포지션을 구성하는 데이터 구동 컴포지션 프레임워크를 포함하는, 본 발명의 원리가 이용될 수 있는 환경을 도시한 것이다.
도 7은 도 6의 환경의 일례를 나타내는 파이프라인 환경을 도시한 것이다.
도 8은 도 7의 파이프라인의 데이터부의 실시예를 개략적으로 도시한 것이다.
도 9는 도 7의 파이프라인의 분석부의 실시예를 개략적으로 도시한 것이다.
도 10은 도 7의 파이프라인의 보기부의 실시예를 개략적으로 도시한 것이다.

본 명세서에 기술된 실시예는 수신된 데이터에 응답하여 디스플레이하도록 재구성되는 하나 이상의 시각화 컨트롤을 포함하는 재계산 사용자 인터페이스와 관련된다. 재계산 사용자 인터페이스는 또한 대응하는 이벤트의 검출 시에 대응하는 환경 신호를 캡처하도록 각각 구성된 하나 이상의 신호 캡처 컨트롤을 포함한다. 하나 이상의 선언적인 변환들의 변환 체인은 다양한 컨트롤 사이에 위치한다. 신호 캡처 컨트롤에 의해 캡처된 환경 신호의 예로는 이미지, 비디오, 오디오, 방향(orientation), 생체 인식, 날씨, 또는 환경에 대한 임의의 다른 정보를 들 수 있다. 이러한 신호 캡처 컨트롤을 재계산 사용자 인터페이스에 포함시키면, 캡처된 환경 신호가 변환 체인의 로직 및 다른 데이터에 포함될 수 있다. 본 명세서에 기술된 적어도 일부 실시예는 이러한 재계산 사용자 인터페이스의 작성을 허용하는 오서링 툴과 관련된다. 컴퓨팅 시스템에 대해 위에서 논의한 일부 내용은 도 1을 참고하여 설명할 것이다. 그 다음에, 후속 도면을 참고하여 신호 캡처 컨트롤을 포함하는 재계산 사용자 인터페이스를 설명할 것이다.

컴퓨팅 시스템은 이제 다양한 형태를 취해가고 있다. 컴퓨팅 시스템은, 예를 들어, 핸드헬드 장치, 가전, 랩탑 컴퓨터, 데스크탑 컴퓨터, 메인프레임, 분산 컴퓨팅 시스템, 또는 심지어 통상적으로 컴퓨팅 시스템으로 간주되지 않았던 장치도 포함할 수 있다. 본원의 상세한 설명 및 청구범위에서, "컴퓨팅 시스템"이란 용어는, 적어도 하나의 물리적이고 형태가 있는(tangible) 프로세서와, 프로세서에 의해 실행될 수 있는 컴퓨터 실행가능 명령어를 수록할 수 있는 물리적이고 형태가 있는 메모리를 포함하는, 임의의 장치나 시스템을 포함하는 것으로 넓게 정의된다. 메모리는 임의의 형태를 취할 수 있으며 컴퓨팅 시스템의 특성과 형태에 의존할 수 있다. 컴퓨팅 시스템은 네트워크 환경에 걸쳐 분산될 수 있고 복수의 컴퓨팅 시스템을 포함할 수 있다.

도 1에 도시된 바와 같이, 가장 기본 구성에서, 컴퓨팅 시스템(100)은 적어도 하나의 프로세싱 유닛(102)과 메모리(104)를 포함한다. 메모리(104)는 휘발성, 비휘발성, 또는 이 둘의 조합일 수 있는 물리적 시스템 메모리일 수 있다. "메모리"란 용어는 또한 본 명세서에서 물리적 저장 매체와 같은 대용량 저장부를 지칭하는데 사용될 수 있다. 컴퓨팅 시스템이 분산되면, 프로세싱, 메모리 및/또는 저장 능력도 분산될 수 있다. 본 명세서에서 사용되는 용어 "실행가능 모듈" 또는 "실행가능 컴포넌트"는 컴퓨팅 시스템에서 실행될 수 있는 소프트웨어 객체, 라우팅, 또는 메소드를 지칭할 수 있다. 본 명세서에 기술되는 다른 컴포넌트, 모듈, 엔진 및 서비스는 컴퓨팅 시스템에서 실행되는 오브젝트나 프로세스(예컨대, 별도의 스레드들)로서 구현될 수 있다.

후술하는 설명에서, 실시예들은 하나 이상의 컴퓨팅 시스템에 의해 수행되는 동작을 참조하여 기술된다. 이들 동작이 소프트웨어로 구현되면, 그 동작을 수행하는 관련 컴퓨팅 시스템의 하나 이상의 프로세서가 컴퓨터 실행가능 명령어를 실행했다는 것에 응답하여 컴퓨팅 시스템의 조작을 지시한다. 예를 들어, 이들 컴퓨터 실행가능 명령어는 컴퓨터 프로그램 제품을 형성하는 하나 이상의 컴퓨터 판독가능 매체에 수록될 수 있다. 그러한 조작의 일례는 데이터의 조작을 포함한다. 컴퓨터 실행가능 명령어(및 조작된 데이터)는 컴퓨팅 시스템(100)의 메모리(104)에 저장될 수 있다. 컴퓨팅 시스템(100)은 또한, 컴퓨팅 시스템(100)이 예컨대 네트워크(110)를 통해 다른 메시지 프로세서와 통신할 수 있게 하는 통신 채널(108)을 포함할 수 있다. 컴퓨팅 시스템(100)은 또한 디스플레이(112)를 포함하며, 이 디스플레이는 사용자에게 시각적 표현을 디스플레이하는데 사용될 수 있다.

본 명세서에 기술된 실시예는, 아래에 보다 상세히 설명하는 바와 같이, 예컨대 하나 이상의 프로세서 및 시스템 메모리와 같은 컴퓨터 하드웨어를 포함하는 특수 목적 또는 범용 컴퓨터를 포함하거나 이용할 수 있다. 본 명세서에 기술된 실시예들은 또한 컴퓨터 실행가능 명령어 및/또는 데이터 구조를 반송 또는 저장하는 물리적 및 기타 컴퓨터 판독가능 매체를 포함한다. 이러한 컴퓨터 판독가능 매체는 범용 또는 특수 목적 컴퓨터 시스템에 의해 액세스될 수 있는 임의의 이용가능 매체일 수 있다. 컴퓨터 실행가능 명령어를 저장하는 컴퓨터 판독가능 매체는 물리적 저장 매체이다. 컴퓨터 실행가능 명령어를 반송하는 컴퓨터 판독가능 매체는 전송 매체이다. 따라서, 예를 들어, 본 발명의 실시예는 적어도 두 종류의 컴퓨터 판독가능 매체, 즉 컴퓨터 저장 매체 및 전송 매체를 포함할 수 있다.

컴퓨터 저장 매체는, RAM, ROM, EEPROM, CD-ROM, 또는 다른 광 디스크 저장부, 자기 디스크 저장부 또는 기타 자기 저장 장치, 또는 컴퓨터 실행가능 명령어 또는 데이터 구조의 형태로 원하는 프로그램 코드 수단을 저장하는데 사용될 수 있고 범용 또는 특수목적 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함한다.

"네트워크"는 컴퓨터 시스템 및/또는 모듈 및/또는 기타 전자 장치 사이에서 전자 데이터의 전달을 가능하게 하는 하나 이상의 데이터 링크로서 정의된다. 네트워크 또는 다른 통신 연결(유선, 무선 또는 유선 또는 무선의 조합)을 통해 컴퓨터에 정보가 전달되는 경우, 컴퓨터는 이 연결을 전송 매체로서 간주한다. 전송 매체는, 컴퓨터 실행가능 명령어 또는 데이터 구조의 형태로 원하는 프로그램 코드 수단을 반송하는데 사용될 수 있고 범용 또는 특수 목적 컴퓨터에 의해 액세스될 수 있는 네트워크 및/또는 데이터 링크를 포함할 수 있다. 이들의 조합이 또한 컴퓨터 판독가능 매체의 범위 내에 포함될 수 있다.

또한, 다양한 컴퓨터 시스템 컴포넌트에 도달하면, 컴퓨터 실행가능 명령어 또는 데이터 구조 형태의 프로그램 코드 수단은 자동으로 전송 매체에서 컴퓨터 저장 매체로 (또는 그 역으로) 전달될 수 있다. 예를 들어, 네트워크 또는 데이터 링크를 통해 수신된 컴퓨터 실행가능 명령어 또는 데이터 구조는 네트워크 인터페이스 컨트롤러(예컨대, "NIC") 내의 RAM 내에 버퍼링될 수 있고, 그 후 최종적으로 컴퓨터 시스템 RAM 및/또는 컴퓨터 시스템에 있는 난휘발성(less vlatile) 컴퓨터 저장 매체로 전달될 수 있다. 따라서, 컴퓨터 저장 매체는 전송 매체를 또한 (또는 주로) 이용하는 컴퓨터 시스템 컴포넌트에 포함될 수 있다.

컴퓨터 실행가능 명령어는, 예컨대, 프로세서에서 실행될 경우에, 범용 컴퓨터, 특수 목적 컴퓨터, 또는 특수 목적 프로세싱 장치로 하여금 소정의 기능 또는 기능 그룹을 수행하게 하는 명령어를 포함한다. 컴퓨터 실행가능 명령어는, 예를 들어, 이진수, 어셈블리어와 같은 중간 포맷 명령어, 또는 심지어 소스 코드일 수도 있다. 청구대상은 비록 구조적 특징 및/또는 방법론적 동작에 특정된 언어로 기술되었지만, 첨부된 청구항에 정의된 청구대상은 반드시 기술된 특징 또는 전술한 동작으로 제한되지는 않는다는 것을 이해해야 한다. 오히려, 기술된 특징 및 동작은 청구항을 구현하는 예시적인 형태로 개시된다.

당업자는 본 발명이 개인용 컴퓨터, 데스크탑 컴퓨터, 랩탑 컴퓨터, 메시지 프로세서, 핸드헬드 장치, 멀티 프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능 가전, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 모바일 전화기, PDA, 페이저, 라우터, 스위치 등을 포함하는 많은 유형의 컴퓨터 시스템 구성을 갖는 네트워크 컴퓨팅 환경에서 실시될 수 있음을 이해할 수 있을 것이다. 본 발명은 또한 (유선 데이터 링크, 무선 데이터 링크, 또는 유선 및 무선 데이터 링크의 조합에 의해 )네트워크를 통해 링크되는 로컬 및 원격 컴퓨터 시스템이 모두 태스크를 수행하는 분산 시스템 환경에서 실시될 수도 있다. 분산 시스템 환경에서, 분산 시스템 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치에 위치할 수 있다.

상세한 설명 및 청구범위에서, "재계산 사용자 인터페이스"는 사용자가 상호작용할 수 있고 하나 이상의 데이터 소스 및 하나 이상의 데이터 싱크가 존재하는 환경에서 나타나는 인터페이스이다. 또한, 하나 이상의 데이터 소스와 데이터 싱크 사이에 각각 선언적으로 정의될 수 있는 변환들로 이루어진 세트가 존재한다. 예를 들어, 하나의 데이터 소스의 출력이 변환에 공급되고, 그 후 변환으로 인한 결과가 데이터 싱크에 제공되어, 결국 시각화에 있어 몇몇 종류의 변화가 사용자에게 제공될 수 있다.

이들 변환은 특별한 코딩 지식을 갖고 있지 않은 사용자가 변환을 정의하는 선언문을 기록할 수 있다는 의미에서 "선언적(declarative)"이다. 변환이 선언적으로 정의되므로, 사용자는 선언적인 변환을 변경할 수 있다. 이에 따라, 재계산이 수행되고, 결과적으로 상이한 데이터가 데이터 싱크에 제공될 수 있을 것이다.

재계산 사용자 인터페이스의 전형적인 예로 스프레드시트 문서가 있다. 스프레드시트 문서는 셀들로 이루어진 격자를 포함한다. 처음에, 셀은 비어있으며, 따라서 스프레드시트 프로그램의 임의의 셀은 사용자에 의해 입력된 선언적 표현의 의미와 컨텍스트에 따라 데이터 소스 또는 데이터 싱크로 될 가능성을 갖는다. 예를 들어, 사용자는 소정 셀을 선택하고 그 셀에 표현을 타이핑할 수 있다. 이 표현은 그 셀에 할당될 표현된 스칼라 값만큼 단순할 수 있다. 이 셀은 나중에 데이터 소스로서 사용될 수 있다. 소정 셀에 있어서의 이 표현은 입력 값이 하나 이상의 다른 셀로부터 취해지는 방정식 형태일 수 있다. 이 경우, 소정 셀은 변환의 결과를 디스플레이하는 데이터 싱크이다. 그러나, 작성을 계속하는 동안, 이 셀은 작성자(author)에 의해 선언적으로 작성된 또 다른 변환에 대해 데이터 싱크로서 사용될 수도 있다.

스프레드시트 문서의 작성자는 명령형 코드에 대한 전문가일 필요가 없다. 작성자는 단순히 변환을 정의하는 선언문을 작성하고, 대응하는 데이터 싱크 및 데이터 소스를 선택할 것이다. 아래에서 설명하는 도 6 내지 10은 보다 일반화된 재계산 사용자 인터페이스가 기술되는 보다 일반화된 선언적 작성 환경을 제공한다. 후술하는 환경에서, 시각화된 컨트롤은 데이터 소스 및 데이터 싱크 역할을 모두 할 수 있다. 또한, 선언적 변환은 이들 컨트롤의 간단한 조작에 의해 보다 직관적으로 작성될 수 있다.

도 2는 예시적인 재계산 사용자 인터페이스(200)를 추상적으로 도시한 것으로, 본 명세서에 기술된 보다 광범위한 원리를 설명하기 위해 제공된 특정 예를 도시한 것이다. 재계산 사용자 인터페이스(200)는 단지 일례로, 본 명세서에 기술된 원리들은 임의의 재계산 사용자 인터페이스에 적용되어 수많은 다양한 애플리케이션에 대해 수많은 다양한 재계산 사용자 인터페이스를 생성한다.

재계산 사용자 인터페이스(200)는 몇몇 선언적인 변환(211 내지 215)을 포함한다. 변환(211 내지 216)을 나타내는 각 화살표들 주위의 점선 원은 이들 변환이 각각 선언적인 형태임을 나타낸다.

도 2의 특정 예에서, 변환(211)은 제각기의 데이터 소스(201) 및 데이터 싱크(202)를 포함한다. 한 변환에서의 데이터 싱크는 다른 변환에서는 데이터 소스가 될 수도 있다. 예를 들어, 변환(211)에서의 데이터 싱크(202)는 변환(212)에서는 데이터 소스 역할을 한다. 또한, 변환은 복수의 데이터 소스를 가질 수도 있다. 따라서, 변환 체인은 계층적으로 형성될 수 있으며, 따라서 상당히 복잡할 수 있다. 예를 들어, 변환(212)은 데이터 소스(202) 및 데이터 싱크(203)를 포함한다. 데이터 싱크(203)는 2개의 데이터 소스를 포함하는데, 즉, 변환(212)에서의 데이터 소스(202)와 변환(214)에서의 데이터 소스(205)를 포함한다. 이것은 하나의 변환이 2개의 데이터 소스(202, 205)를 데이터 싱크(203)로 안내함을 나타낸다. 변환(213)은 데이터 소스(204) 및 데이터 싱크(205)를 포함한다.

재계산 사용자 인터페이스는 시각화 컨트롤을 가질 필요가 없다. 이것의 한 예는, 정상적인 경우에 계산에 대해 사용자에게 디스플레이되는 정보 없이 변환 기반 계산을 수행하고 소스 데이터를 사용하고 싱크 데이터를 업데이트하기 위한 재계산 사용자 인터페이스이다. 예를 들어, 재계산 사용자 인터페이스는 배경 계산을 지원할 수 있다. 두 번째 예는 프로세스 컨트롤 예에서의 밸브와 같은 외부 액츄에이터를 조작하는 출력 컨트롤을 갖는 재계산 사용자 인터페이스이다. 이런 컨트롤은 그들의 상태가 변환 계산 및 온 신호 입력의 결과에 의해 제어된다는 점에서 디스플레이 컨트롤과 유사하다. 그러나, 여기서는, 출력이 디스플레이에 대한 시각화보다는 장치에 대한 제어 신호이다. 예를 들어, 로봇을 제어하는 재계산 사용자 인터페이스를 고려해보자. 이 재계산 사용자 인터페이스는 서보 위치 및 속도, 초음파 거리 측정 등과 같은 입력 로봇 센서에 의존하는 로봇 액션 및 동작에 대한 규칙을 가질 수 있다. 또는 밸브 위치, 유량 변화 등과 같은 장비 센서로부터 신호를 취하는 재계산 사용자 인터페이스에 기초하여 프로세스 컨트롤 애플리케이션을 고려해보자.

본 명세서에 기술된 원리에 따르면, 데이터 소스/싱크(201 내지 205) 중 하나 이상은 신호 캡처 컨트롤일 수 있다. 또한, 데이터 소스/싱크(201 내지 205) 중 하나 이상은 시각화 컨트롤일 수 있다. 시각화 컨트롤은 자신의 파라미터 중 하나 이상의 파라미터에 따라 소정의 방식으로 디스플레이하는 컨트롤이다. 그 파라미터는, 예컨대 변환(211 내지 215)에 의해 표현된 변환 체인과 같은 변환 체인으로부터의 출력 데이터를 수신함으로써 설정될 수 있다.

재계산 사용자 인터페이스는 시각화 컨트롤을 가질 필요가 없다. 이것의 한 예는, 정상적인 경우에 계산에 대해 사용자에게 디스플레이되는 정보 없이 변환 기반 계산을 수행하고 소스 데이터를 사용하고 싱크 데이터를 업데이트하기 위한 재계산 사용자 인터페이스이다. 예를 들어, 재계산 사용자 인터페이스는 배경 계산을 지원할 수 있다. 두 번째 예는 프로세스 컨트롤 예에서의 밸브와 같은 외부 액츄에이터를 조작하는 출력 컨트롤을 갖는 재계산 사용자 인터페이스이다. 이런 컨트롤은 그들의 상태가 변환 계산 및 온 신호 입력의 결과에 의해 제어된다는 점에서 디스플레이 컨트롤과 유사하다. 그러나, 여기서, 출력은 디스플레이로의 시각화보다는 장치로의 제어 신호이다.

한편, 신호 캡처 컨트롤은 이벤트의 검출 시에 환경 신호를 캡처하도록 구성된다. 캡처된 환경 신호는 사용자에게 디스플레이될 수도 있고, 또는 변환 체인에 대한 입력으로서 제공될 수 있으며, 따라서 변환 체인에 의해 생성된 출력 데이터에 영향을 미친다. 신호 캡처 컨트롤에 의해 캡처될 수 있는 환경 신호의 예로는 이미지, 비디오, 오디오, 사운드 레벨, 방향, 위치, 생체인식, 기상(예컨대, 온도, 햇빛 수준, 강수, 습도, 대기압, 바람), 가속도, 압력, 중력, 태양 위치, 달의 배향, 화자의 신원, 이미지 또는 비디오 내에서의 사람이나 물체의 아이덴티티 또는 그 집합, 및 임의의 다른 가능한 환경 신호를 들 수 있다. 일부 실시예에서, 컨트롤은, 이벤트의 검출 시에 환경 신호를 캡처하도록 구성된 신호 캡처 컨트롤과, 컨트롤의 파라미터들 중 하나 이상에 의존하는 시각화된 특징을 갖는 객체를 렌더링하도록 구성된 시각화 컨트롤일 수 있다.

신호 캡처 컨트롤은 소정의 이벤트 검출 시에 센서가 신호를 캡처하도록 하기 위해 적절한 환경 센서와 통신할 수 있다. 예를 들어, 신호 캡처 컨트롤이 이미지를 캡처할 경우, 신호 캡처 컨트롤은 이벤트가 검출될 때 사진을 찍기 위해 카메라를 활성화할 수 있다. 마찬가지로, 비디오 카메라, 리코더, 소음 측정기(sound meter), 나침반, 가속도계, 또는 임의의 다른 적절한 센서와 같은 다른 센서가 신호 캡처 컨트롤에 결합된 센서로서 사용될 수 있다.

검출된 이벤트는 임의의 사전결정된 이벤트일 수 있다. 그 예로 사용자 이벤트를 들 수 있다. 예를 들어, 사용자는 환경 신호가 대응하는 센서에 의해 캡처되게 하기 위해 소정의 방식으로 신호 캡처 컨트롤의 시각화된 표현과 실제로 인터페이스할 수 있다. 이벤트는 다른 신호 캡처 컨트롤로부터의 출력에 의존할 수도 있다. 예를 들어, 이벤트는 다른 신호 캡처 컨트롤에 의해 캡처된 환경 신호가 소정 범위 내에 포함되는 동안 사용자가 소정의 방식으로 특정 컨트롤과 인터페이스하는 것일 수 있다. 이벤트는 또한 신호 캡처 컨트롤에 의해 변환 체인으로부터 소정 데이터를 수신하는 것일 수 있다. 이벤트는 환경 신호를 캡처하기 위해 신호 캡처 컨트롤을 트리거링한다.

변환 체인의 나머지에 의해 포함된 로직을 갖는 그러한 신호 캡처 컨트롤의 액션은 다양한 시나리오를 가능하게 한다. 특히, 그러한 환경 신호는 추가 데이터와 함께 포함될 수 있다. 이것은 환경 신호가 스프레드시트와 같은 통상의 재계산 사용자 인터페이스를 사용하여 승인되기 전에는 절대로 시나리오를 허용하지 않는 데이터(예컨대, 비즈니스 데이터) 및 로직(예컨대, 비즈니스 로직)과 함께 포함될 수 있게 한다. 이제 이들 원리가 현대 세계에 적용할 수 있는 유틸리티를 설명하기 위해 무수한 시나리오들 중 몇몇 시나리오를 설명할 것이다.

보안 서비스 시나리오에서, 서비스 제공자의 임무는 고객의 집을 살펴보고 필요한 보안 장치를 확인하는 것이다. 제공자는 사진촬영을 할 수 있는 모바일 장치를 이용하여 집을 살펴본다. 하나의 방에서, 제공자는 슬라이딩 도어의 사진을 촬영하고, 보안 장치를 도어의 이미지에 드래그하여 드롭하는데, 보안 장치는 사진에 보여진 집의 해당 부분을 안전하게 하는데 필요할 수 있는 장치를 나타낸다. 각 사진은 또한 나침반 출력 및 GPS 위치와 연관되고, GPS 위치의 출력 또한 각 사진과 연관된다. 제공자는 계속해서 보안 장치를 사진들(각 사진은 방향 및 위치 정보를 가짐)에 드래그하여 그 위에 드롭한다. 배경에서 실행되는 비즈니스 로직은 장치의 각 카테고리의 수를 카운트한다. 장치의 수가 현재의 서비스 레벨에 대한 사전결정된 한도를 초과하면, 팝업 시각화(visualization)가 나타나고, 보다 많은 장치를 고려하도록 보안 서비스가 업그레이드되어야 하는지 문의한다. 서비스 제공자는 고객에게 그들이 원하는 바를 문의하고, 고객은 서비스를 업그레이드하기로 선택한다. 그러면, 서비스 제공자는 업그레이드하기로 선택하고 그 집의 보안 장치의 할당을 완료한다.

그 후 결과가 인스톨러에 제공된다. 1주일 후, 인스톨러 오리엔테이션 및 글로벌 위치확인 정보가 인스톨러를 각각의 보안 감지 위치로 안내한다. 인스톨러는 이미지를 사진의 위치 및 방향으로 안내된 후에 인스톨러가 보고 있는 것과 비교함으로써 정확한 위치를 확인한다. 인스톨러가 그 위치에 있으면, 팝업 시각화가 나타나며 그 보안 감지 위치에 필요한 장치 리스트를 제공한다. 이것은 모든 보안 감지 위치에 대해 계속되며, 고객은 예상 위치에 필요한 그리고 기대되는 모든 보안 장치를 제공받고, 따라서 고객 및 계약을 만족시킨다.

이 예에서, 촬영된 이미지 및 각 이미지에 대한 방향 및 위치 정보는 캡처된 환경 신호의 예를 나타낸다. 보안 장치의 아이덴티티 및 카운트는 비즈니스 데이터의 예들을 나타내고, 현재의 보안 장치의 목록이 어느 정도의 서비스에 속하는 지에 대한 판정은 비즈니스 로직의 일례이다.

다른 인터뷰 시나리오에서는, 슈퍼바이저가 직원의 분기 평가를 수행하고 있다. 회사 정책에 따라서, 직원에 대해 요청되는 다수의 특정한 문제가 존재한다. 인터뷰가 기록된다. 인터뷰의 시작 시에, 녹음기가 활성화되면, 질문되어야 하는 질문의 각 번호에 대해 팝업이 나타난다. 면접관이 질문들 중 하나를 질문하기 시작하면, 면접관은 녹음 위치를 나타내는 "시작(Begin)" 컨트롤을 활성화한다. 직원이 질문에 대답을 마치면, 슈퍼바이저는 자신이 직원에 대답에 대한 평가를 나중으로 미루기를 원한다면 "완료(Complete)" 컨트롤을 누르고, 아니면 직원의 대답에 대한 슈퍼바이저의 인상을 나타내는 소정의 등급(1 내지 10)을 누른다. 어느 방법이든, 녹음에는 대답의 종료와 함께 태그가 붙고, 디스플레이에서 팝업이 제거된다. 이것은 물어볼 질문이 더 이상 없을 때까지 계속된다.

3주 후에, 평가를 인사부에 넘길 기한이 되고, 슈퍼바이저는 녹음기록으로 돌아간다. 팝업 시각화가 나타나서 슈퍼바이저에게 슈퍼바이저가 인터뷰 과정 동안 10개의 대답 중 6개에 대해 등급을 매겼고, 10개의 대답 중 4개에 대해 등급 매기기를 연기했음을 보여준다. 나머지 4개에 대해 하나씩, 사용자는 시각화를 선택하는데, 이는 녹음의 일부분(그 질문에 대한 시작 태그에서 시작하여 그 질문의 종료 태그에서 종료하고, 두 태그는 인터뷰 과정 동안 생성됨)이 슈퍼바이저에게 제시되게 한다. 슈퍼바이저는 녹음기록을 다시 들어보고, 인터뷰의 해당 부분에 대한 등급을 매긴다.

여기서, 캡처된 신호는 오디오 기록이었다. 비즈니스 데이터는 인터뷰 과정 동안 제기된 각 질문의 시작과 종료 및 슈퍼바이저에 의해 할당된 등급이었다. 비즈니스 로직은 인터뷰 동안 질의된 소정 질문이 있었다는 것이었다.

제3 시나리오는 유서 작성에 관한 것이다. 유서를 완성하면, 사용자는, 작성자가 건강한 정신(sound mind) 상태인지의 여부에 대한 평가를 할 수 있게 하기 위해 몇몇 질문을 받는다. 이들 질문은, 건강한 정신의 누군가가 작성자의 자녀의 신원과 같은 소정의 방식으로 대답할 수 있는 질문들을 포함할 수 있다. 질문의 시작 시에, 작성자의 비디오가 촬영될 수도 있다. 프로그램 자체가 작성자의 행동을 평가하고 작성자의 정신의 건강에 대한 견해 및 부정적인 판정에 대한 이유를 제공할 수도 있다. 그 후 비디오는 유서의 나중 처리를 위해 유서와 통합하여 이용가능하게 만들어질 수 있다. 따라서 법원은 비디오를 평가하여 그 유서가 유효한지의 여부를 판정할 수 있다.

어쨌든, 목격자가 유서를 목격하게 되면, 프로그램은 첫 번째 목격 사진을 촬영할 수 있다. 두 번째 목격자가 이 유서를 목격하게 되면, 프로그램은 제2의 목격 사진을 촬영할 수 있다. 목격자가 동일인이거나 또는 유서 자체의 작성자인 것으로 드러나면, 비즈니스 로직은 유언 작성 과정을 실패시키거나 또는 정정을 요청할 수 있다.

이 예에서, 캡처된 신호는 소정의 질문에 대답하는 유언 작성자의 비디오 및 오디오와, 목격자의 이미지이다. 비즈니스 로직은 작성자가 건강한 정신을 가져야 한다는 것 또는 적어도 소정 질문에 대한 작성자의 대답의 비디오가 녹화되어야 한다는 것이다. 또한, 비즈니스 로직은 유서의 두 목격자가 상이한 개인이어야 할 것과 유서의 작성자와 달라야 할 것이다.

제4 예에서, 셀폰을 휴대하는 사용자가 낮에 운동하기 위해 달리기를 하기로 결정한다. 스마트폰 내의 재계산 사용자 인터페이스 소프트웨어는 사용자의 심박수가 에어로빅 운동 영역으로 이동하였다는 신호와 사용자가 비자동차(즉, 보행) 도로 위를 달리기 속도(말하자면, 4-6 mph)로 이동하고 있음을 알 것이다. 이것으로부터, 재계산 사용자 인터페이스 내의 규칙에 따라, 사용자가 운동하고 있다는 추론이 이루어지고 운동에 적합한 재계산 문서가 로딩된다. 이것은 예를 들어 사용자 운동 통계(소모한 칼로리, 현재 속도, 심박수 차트와 심박수, 지상 고도 차트 등)를 디스플레이하는 컨트롤을 포함할 수 있다. 다른 규칙에 기초하여, 사용자의 심박수가 자신의 연령에 비해 고위험 영역에 진입함이 검출되면, 문서는 경고 소리를 내고 사용자가 가슴 통증을 느끼기 시작하면 도움을 청할 링크 및 구급차를 호출하기 위한 버튼과 함께 경고 페이지를 디스플레이하도록 업데이트할 수 있다. 따라서, 신호를 검출함으로써, 문서 소프트웨어는 디스플레이되는 것과 사용자에게 이용가능할 액션을 변경하여 디스플레이된 정보 및 액션이 사용자의 현재 활동에 적합하게 한다.

따라서, 환경 신호의 캡처 및 로직(예컨대, 비즈니스 로직) 및 데이터(예컨대, 비즈니스 데이터)와 환경 신호의 통합에 의해 재계산 사용자 인터페이스를 사용하여 이전에는 가능하지 않았던 유용한 여러 풍부한 시나리오가 실현될 수 있다.

(도 1의 컴퓨팅 시스템(100)과 같은)컴퓨팅 시스템은 또한, 하나 이상의 컴퓨터 판독가능 매체 상에 제공되는 컴퓨터 실행가능 명령어를 실행하여, 오서링 사용자 인터페이스가 오서링을 용이하게 하는 방식으로 재계산 사용자 인터페이스 오서링 시스템을 조작할 수도 있다.

예를 들어, 도 3은 신호 캡처 컨트롤의 라이브러리(310)를 포함하는 사용자 인터페이스(300)를 도시한 것이다. 도 3의 라이브러리(310)에는 3개의 다른 타입(311, 312, 313)의 신호 캡처 컨트롤이 도시되어 있다. 그러나, 생략부호(314)는 라이브러리(310)에 임의의 개수의 신호 캡처 컨트롤 타입이 있을 수 있음을 나타낸다. 사용자 인터페이스(300)는 또한 시각화 컨트롤의 라이브러리(320)를 포함한다. 라이브러리(320)에는 4개의 상이한 타입(321, 322, 323, 324)의 시각화 컨트롤이 도시되어 있다. 그러나, 생략부호(325)는 라이브러리(320)에 임의의 수의 시각화 컨트롤 타입이 있을 수 있음을 나타낸다. 즉, 전술한 바와 같이, 신호 캡처 컨트롤은 시각화 컨트롤 역할을 할 수도 있는데, 이 경우 신호 캡처 컨트롤과 시각화 컨트롤 사이를 반드시 구별할 필요는 없다.

사용자 인터페이스(300)는 또한 재계산 사용자 인터페이스가 작성되는 모델 작성 영역(330)을 포함한다. 신호 캡처 컨트롤들 중 하나 이상 및 시각화 컨트롤들 중 하나 이상을 선택하고 선택된 컨트롤을 모델에 배치하기 위해 컨트롤 메커니즘(340)이 제공된다. 이러한 메커니즘의 일례는 컨트롤을 모델 작성 영역(330)으로 드래그하여 드룹하는 것이다. 그렇게 함으로써, 대응하는 컨트롤의 인스턴스가 모델 내에 생성된다.

사용자 인터페이스(300)는 또한 모델 내의 컨트롤들 사이에서 변환이 생성되도록 하는 변환 생성 메커니즘(350)을 포함한다. 변환은 작성자에 의해 직접 선언적으로 정의될 수도 있고 컨트롤들 중 하나 이상을 간접적으로 조작함으로써 선언적으로 정의될 수도 있다.

이와 같이, 재계산 사용자 인터페이스, 및 이를 작성하기 위한 오서링 시스템을 설명하였다. 본 명세서에 기술된 원리는 동작이 증명되는 방식에 제한되지 않지만, 이제 동작이 증명되는 방법의 예들을 도 4 및 5를 참고하여 설명할 것이다.

도 4는 변환 체인(401)에 액세스하는 컴파일러(410)를 포함하는 예시적인 컴파일 환경(400)을 도시한 것이다. 변환 체인(401)의 일례는 도 2의 변환 체인이다. 컴파일러(400)는 변환들(211 내지 215) 각각을 분석할 수 있다. 이들 변환은 선언적이며, 따라서 그 의존성은 변환들이 명령형 컴퓨터 언어를 사용하여 표현될 경우보다 더 쉽게 추출될 수 있다.

이 분석에 기초하여, 변환들에서 참조된 엔티티들 간의 의존성 그래프(412)가 생성된다. 기본적으로, 의존성은 이벤트를 나타내는 소스 엔티티와, 타겟 엔티티의 평가가 그 이벤트에 의존함을 나타내는 타겟 엔티티를 갖는다. 이벤트의 일례는 사용자가 재계산 사용자 인터페이스와 어떠한 방식으로 상호작용하는 사용자 이벤트일 수 있다. 다른 예로서, 이벤트는 소스 엔티티가 평가되면 그 의존관계의 타겟 엔티티가 평가되어야 하는 엔티티간 이벤트일 수 있다.

그 후, 컴파일러는 의존성 그래프(412)에 기초하여 하위 레벨 실행 단계를 생성한다. 하위 레벨 실행 단계는, 예컨대, 명령형 언어 코드(imperative language code)일 수 있다. 명령형 언어 코드(411)는 변환 체인 내의 각 변환의 컴파일을 포함한다. 예를 들어, 하위 레벨 코드(411)는 변환 체인 내의 각 변환의 컴파일을 나타내는 요소(421)를 포함하는 것으로 도시되어 있다. 도 2의 컨텍스트에서, 요소(421)는 각 변환들(211 내지 215)의 컴파일을 포함할 것이다. 하위 레벨 코드(211)는 또한 다양한 기능(422)을 포함한다. 기능은 의존성 그래프 내의 각각의 의존성에 대해 생성된다. 이들 기능은 명령형 언어 기능일 수 있다.

명령형 언어 런타임이 의존성 그래프에 리스트되는 이벤트를 검출하는 경우, 컴파일된 기능(422) 내의 대응 기능이 또한 실행된다. 따라서, 모든 변환이 적절히 컴파일되고 특정 이벤트에 대한 각각의 의존성이 전용 기능에 의해 적용되면, 선언적 재계산 사용자 인터페이스가 명령형 언어 코드로서 적절히 표현된다.

이와 같이, 명령형 재계산 사용자 인터페이스를 컴파일하기 위한 효과적인 메커니즘을 설명하였다. 또한, 런타임은 보다 광범위한 해석기보다는 의존성 그래프를 구비한다.

도 4 및 5에 대해 기술된 환경은 재계산 사용자 인터페이스의 컴파일을 허용할뿐만 아니라 재계산 사용자 인터페이스에 대한 변화의 증가로 인해 더 많은 컴파일이 이루어지도록 허용한다. 이것은, 해석기가 최종 생산에 이용될 것을 요구하지 않고 또한 증가하는 변화들 사이에 재계산 사용자 인터페이스의 완전한 재컴파일을 요구하지 않으면서, 사용자가 보다 빨리 재계산 사용자 인터페이스의 동작을 검증할 수 있게 하는 오서링 경험을 용이하게 한다.

도 4를 참고하면, 컴파일 환경(400)은 또한 변환 체인(200 또는 401)을 포함하는 재계산 사용자 인터페이스를 작성하는데 있어 사용자를 돕기 위한 오서링 컴포넌트(431)를 포함한다. 예를 들어, 오서링 컴포넌트(431)는 도 3의 오서링 사용자 인터페이스(300)일 수 있다. 컴파일 환경(400)은 또한 변환 체인(401)의 분석을 통해 의존성 그래프(412)를 생성하도록 구성된 분석 모듈(432)을 포함한다. 분석 모듈(432)은 오서링 컴포넌트(431)를 통해 추가, 삭제, 또는 수정된 선언적인 변환 형태로 변환 체인(401)에 변화가 생길 경우를 검출하는 변화 검출 메커니즘(441)을 포함한다. 변화에 응답하여, 분석 모듈(432)은 변환 체인(401)의 변경된 부분을 재분석하고 의존성 그래프의 하나 이상의 영향 받은 의존성을 식별하도록 구성된다.

그 후 컴파일러(410)는 전체 재계산 사용자 인터페이스를 컴파일하지 않고 하나 이상의 영향받은 의존성을 포함하는 재계산 사용자 인터페이스의 부분을 점점 컴파일함으로써 변환에 반응할 수 있다. 컴파일러는 명령형 언어의 함수의 단위로 재계산된 인터페이스의 부분을 컴파일할 수 있다. 예를 들어, 전술한 바와 같이, 의존성 그래프 내 각각의 의존성에 대해 명령형 언어 함수가 존재할 수 있다. 단지 하나 이상의 영향받은 의존성과 관련된 하나 이상의 함수만 컴파일될 필요가 있다.

분석 모듈(432)은 또한 의존성 그래프 내에 에러가 있는 경우를 검출하는 에러 검출 모듈(442)을 포함한다. 컴파일러(410)는 의존성 그래프에서 검출된 에러가 없는 경우에 점증적 컴파일이 제한될 수 있다. 또한, 사용자는 의존성 그래프에서 검출된 에러가 존재할 경우에 에러를 수정하도록 프롬프트받을 수 있으며, 이에 따라 오서링 컴포넌트(431)로부터의 후속 변화가 에러를 수정할 가능성이 높아지며, 따라서 컴파일이 증가할 수 있다.

점증적 컴파일에 필요한 시간은 전체 프로그램을 컴파일하는데 필요한 시간에 비해 무시할만 하다. 따라서, 오서링 경험이 긴 컴파일 프로세스에 의해 방해받지 않는다. 대신에, 작성자가 변화를 만들고, 결과의 동작이 의도된 것인지를 신속하게 검증할 수 있다(또는 동작이 평가되기 전에 수정될 필요가 있는 에러를 알 수 있다). 따라서 최종 생산에 실질적인 해석기를 이용할 필요 없이 효과적인 증대되는 작성 경험이 제공된다.

이제 비프로그래머가 재계산 사용자 인터페이스를 사용하여 복잡한 동작을 갖는 프로그램을 작성할 수 있게 하는 오서링 파이프라인의 특정 예를 도 6 내지 10을 참고하여 설명할 것이다.

도 6은 대화식 비주얼 컴포지션을 재계산 사용자 인터페이스의 형태로 구축하는데 사용될 수 있는 비주얼 컴포지션 환경(600)을 도시한 것이다. 재계산 사용자 인터페이스의 구축은 데이터 구동 분석 및 분석 결과의 시각화를 이용하여 수행된다. 환경(600)은 뷰 컴포지션(630)의 문제 도메인과 독립적으로 수행되는 로직을 수행하는 컴포지션 프레임워크(610)를 포함한다. 예를 들어, 도시 계획, 분자 모델, 식료품 선반 레이아웃, 기계 성능 또는 조립 분석, 또는 기타 도메인 특정 렌더링을 위해 대화형 뷰 컴포지션을 작성하기 위해 동일한 컴포지션 프레임워크(610)가 사용될 수 있다.

그러나, 컴포지션 프레임워크(610)는 도메인 특정 데이터(620)를 사용하여 그 도메인에 특정한 실제 비주얼 컴포지션(630)을 구축한다. 따라서, 임의의 수의 상이한 도메인에 대한 재계산 사용자 인터페이스를 구축하기 위해, 컴포지션 프레임워크(610) 자체를 재부호화할 필요없이 도메인 특정 데이터(620)를 변경함으로써, 동일한 컴포지션 프레임워크(610)가 사용될 수 있다. 따라서, 파이프라인(600)의 컴포지션 프레임워크는 재부호화 및 재컴파일링하지 않고 데이터를 변경함으로써 잠재적으로 제한없는 문제 도메인 또는 적어도 다양한 문제 도메인에 적용될 수 있다. 그 다음에, 뷰 컴포지션(630)이 적절한 2-D 또는 3-D 렌더링 모듈에 명령어로서 제공될 수 있다. 본 명세서에 기술된 아키텍처는 기존의 뷰 컴포지션 모델을 빌딩 블록으로서 새로운 뷰 컴포지션 모델에 간편하게 포함시키도록 허용한다. 일실시예에서, 복수의 뷰 컴포지션이 통합 뷰 컴포지션에 포함되어 모델에 대해 2개의 가능한 솔루션 사이를 편리하게 비교할 수 있게 된다.

도 7은 컴포지션 프레임워크(610)의 예시적인 아키텍처를 파이프라인 환경(700)의 형태로 도시한 것이다. 파이프라인 환경(700)은 무엇보다도 파이프라인(701) 자체를 포함한다. 파이프라인(701)은 데이터부(710), 분석부(720), 및 보기부(view portion)(630)를 포함하는데, 이들에 대해서는 도 8 내지 10 및 하기 설명을 참고하여 보다 자세히 설명할 것이다. 이제, 일반적인 수준에서, 파이프라인(701)의 데이터부(710)가 다양한 유형의 데이터를 수용할 수 있고 이 데이터를 정규 형태로 파이프라인(701)의 분석부(720)에 제시할 수 있다. 분석부(720)는 데이터를 다양한 모델 파라미터에 결합하며, 모델 분석을 이용하여 모델 파라미터 내의 미지수(unknown)를 구한다. 그 다음에 다양한 파라미터 값이 보기부(730)에 제공되고, 보기부는 모델 파라미터 내의 이들 값을 이용하여 합성 뷰를 구축한다.

파이프라인 환경(700)은 또한 파이프라인(701)의 작성자 또는 다른 사용자 파이프라인(701)에 제공할 데이터를 공식화하고/하거나 선택할 수 있게 하는 오서링 컴포넌트(740)를 포함한다. 예를 들어, 오서링 컴포넌트(740)는 (입력 데이터(711)에 의해 표현된)데이터부(710), (분석 데이터(721)에 의해 표현된)분석부(720), 및 (뷰 데이터(731)에 의해 표현된)보기부(730)의 각각에 데이터를 게공하는데 사용될 수 있다. 다양한 데이터(711, 721, 731)는 도 6의 도메인 특정 데이터(620)의 일례를 나타내며, 이하에서 더 자세히 설명할 것이다. 오서링 컴포넌트(740)는, 예컨대, 데이터 스키마, 모델에 의해 사용될 실제 데이터, 외부 소스 형태로 가져와지는 데이터의 위치 또는 가능한 위치들의 범위, 비주얼 (그래픽 또는 애니메이션) 객체, 비주얼에 대해 수행될 수 있는 사용자 인터페이스 상호작용들, 모델링 문장(예컨대, 뷰, 방정식, 제약), 바인딩 등을 포함하는, 다양한 데이터의 제공을 지원한다. 일실시예에서, 오서링 컴포넌트는 (도 7에는 도시되어 있지 않지만, 도 6의 컴포지션 프레임워크(610)에 의해 표현된)전체 관리자 컴포넌트에 의해 제공된 기능의 단지 일부분이다. 관리자는 (상호작용 이벤트, 외부 데이터 이벤트, 해결기와 같은 임의의 다른 컴포넌트로부터의 이벤트, 운영 체제 등과 같은)이벤트에 응답하여 (데이터 커넥터, 해결기, 뷰어 등과 같은)다른 모든 컴포넌트의 동작을 제어하고 배열하는 총괄적인 관리책임자이다.

도 7의 파이프라인 환경(700)에서, 오서링 컴포넌트(740)는 기존의 파이프라인(701)에 데이터를 제공하는데 사용되는데, 여기서 데이터가 입력 데이터를 정의하는 것으로부터 분석 모델을 정의하는 것(앞에서 "변환 체인"이라고 함), 변환 체인의 결과가 어떻게 뷰 컴포지션에서 시각화되는지를 정의하는 것까지의 전체 프로세스를 드라이브한다. 따라서, 사용자는 파이프라인(701)을 다양한 도메인들 및 문제들 중 어느 하나에 맞게 구성하기 위해 어떠한 코딩을 수행할 필요가 없다. 파이프라인(701)에 제공된 데이터만이, 다른 문제 도메인으로부터의 다른 뷰 컴포지션을 시각화하거나 또는 기존의 도메인에 대해 풀 문제를 아마도 조정하도록, 파이프라인(701)을 적용하기 위해 변경해야하는 것이다. 또한, 데이터는 사용 시간(즉, 실행 시간) 및 작성 시간에 변경될 수 있기 때문에, 모델은 런타임에 수정되고/되거나 확장될 수 있다. 따라서, 모델을 작성하는 것과 모델을 실행시키는 것 사이에 차이가 있다고 해도 그 차이는 적다. 모든 작성은 데이터 아이템을 편집하는 것을 포함하고 소프트웨어는 데이터로부터 그 동작 전부를 실행하기 때문에, 데이터에 대한 모든 변경은 재부호화 및 재컴파일할 필요없이 즉각적으로 동작에 영향을 미친다.

파이프라인 환경(700)은, 또한 사용자가 디스플레이된 뷰 컴포지션과 상호작용하는 경우를 검출한 후 그 응답으로 무엇을 해야 할지를 결정하는 사용자 상호작용 응답 모듈(750)을 포함한다. 예를 들어, 일부 유형의 상호작용은 파이프라인(701)에 제공된 데이터에 아무런 변경도 요구하지 않을 수 있으며, 따라서 뷰 컴포지션에 아무런 변경도 요구하지 않을 수 있다. 다른 유형의 상호작용은 데이터(711, 721, 731) 중 하나 이상을 변경시킬 수 있다. 그러한 경우, 이 새로운 또는 변경된 데이터는 새로운 입력 데이터가 데이터부(710)에 제공되도록 할 수도 있고, 분석부(720)에 의해 입력 데이터의 재분석을 요구할 수도 있고, 보기부(730)에 의해 뷰 컴포지션의 재시각화를 요구할 수도 있다.

따라서, 파이프라인(701)은 데이터 구동 분석 시각화를 무한한 수의 문제 도메인 또는 적어도 다양한 문제 도메인으로 확장하는데 사용될 수 있다. 또한, 사용자는 뷰 컴포지션을 변경하여 다양한 문제를 처리하기 위해 프로그래머일 필요가 없다. 파이프라인(701)의 각각의 데이터부(710), 분석부(720) 및 보기부(730)를 이제 도 10의 데이터부(1000), 도 9의 분석부(900), 및 도 10의 보기부(1000)를 참고하여 각각 차례로 설명할 것이다. 도 8 내지 10으로부터 명확하듯이, 파이프라인(701)은 일련의 변환 컴포넌트로서 구성될 수 있는데, 이들은 각각 1) 일부 적절한 입력 데이터를 수신하고, 2) 그 입력 데이터에 응답하여 (입력 데이터에 대한 변환을 수행하는 것과 같은)일부 액션을 수행하며, 3) 그 다음 변환 컴포넌트에 대한 입력 데이터 역할을 하는 데이터를 출력한다.

도 8은 도 7의 파이프라인(701)의 데이터부(800)의 많은 가능한 실시예들 중 하나를 도시한 것이다. 데이터부(800)의 기능들 중 하나는 도 9를 참고하여 논의되는 파이프라인의 분석부(1100)에 의해 이해된 스키마와 일치하는 정규 포맷으로 데이터를 제공하는 것이다. 데이터부는 이종 데이터(801)에 액세스하는 데이터 액세스 컴포넌트(810)를 포함한다. 입력 데이터(801)는 그 데이터가 정규 형태로 데이터 액세스 컴포넌트(810)에 제시될 수 있다(그러나 그럴 필요는 없다)는 의미에서 "이종(heterogenic)"일 수 있다. 사실, 데이터부(800)는 이종 데이터가 다양한 포맷일 수 있도록 구성된다. 모델들에 의해 액세스되고 조작될 수 있는 상이한 종류의 도메인 데이터의 예로는 텍스트 및 XML 문서, 테이블, 리스트, 계층 구조(트리), SQL 데이터베이스 쿼리 결과, BI(business intelligence) 큐브 쿼리 결과, 다양한 포맷의 2D 드로잉 및 3D 비주얼 모델과 같은 그래픽 정보 및 이들의 조합(즉, 합성물)을 들 수 있다. 또한, 액세스될 수 있는 데이터의 종류는 액세스될 데이터에 대한 정의(예컨대, 스키마)를 제공함으로써 선언적으로 확장될 수 있다. 따라서, 데이터부(800)는 모델로의 다양한 이종 입력을 허용하며, 또한 런타임의 액세스가능한 데이터 타입의 선언적인 확장을 지원한다.

일실시예에서, 데이터 액세스부(800)는 다수의 상이한 데이터 소스로부터 데이터를 획득하는 다수의 커넥터를 포함한다. 커넥터의 주요 기능들 중 하나는 대응하는 데이터를 정규 형태로 배치하는 것이므로, 이러한 커넥터를 이하에서 그리고 도면에서 "정규화기"라고 지칭할 것이다. 각각의 정규화기는 그 대응하는 데이터 소스의 특정 API(Application Program Interface)를 이해할 수 있다. 정규화기는 또한 데이터 소스에 대해 데이터를 판독 및/또는 기록하기 위해 대응하는 API와 인터페이스하는 대응하는 로직을 포함할 수도 있다. 따라서, 정규화기는 외부 데이터 소스와 데이터의 메모리 이미지 사이를 잇는다.

데이터 액세스 컴포넌트(810)는 입력 데이터(801)를 평가한다. 입력 데이터가 이미 정규적이고 따라서 분석부(1100)에 의해 처리가능하면, 입력 데이터는 분석부(1100)에 입력되도록 정규 데이터(840)로서 직접 제공될 수 있다.

그러나, 입력 데이터(801)가 정규적이지 않으면, 적절한 데이터 정규화 컴포넌트(830)가 입력 데이터(801)를 정규 포맷으로 변환시킬 수 있다. 데이터 정규화 컴포넌트(830)는 실제로 데이터 정규화 컴포넌트(830)의 집합인데, 이들 각각은 특정한 특징들을 갖는 입력 데이터를 정규 형태로 변환시킬 수 있다. 정규화 컴포넌트(830)의 집합은 4개의 정규화 컴포넌트(831, 832, 833, 834)를 포함하는 것으로 도시되어 있다. 그러나, 생략부호(835)는 다른 개수의 정규화 컴포넌트가 존재할 수도 있으며, 때론 도시된 4개보다 적은 수의 정규화 컴포넌트가 있을 수도 있음을 나타낸다.

입력 데이터(801)는 정규화기 자체뿐만 아니라 상관된 데이터 특징의 식별자도 포함할 수 있다. 그 다음에 데이터부(800)는 상관된 데이터 특징을 등록할 수도 있고 정규화 컴포넌트를 데이터 정규화 컴포넌트 집합(830)에 제공할 수도 있으며, 여기서 데이터 특징이 이용가능한 정규화 컴포넌트에 추가될 수도 있다. 상관된 특징을 갖는 입력 데이터가 나중에 수신되면, 데이터부(810)는 입력 데이터를 상관된 정규화 컴포넌트에 할당할 수 있다. 정규화 컴포넌트는 또한 웹 상의 정의된 컴포넌트 라이브러리와 같은 외부 소스로부터 동적으로 발견될 수 있다. 예를 들어, 주어진 데이터 소스에 대한 스키마가 알려져 있지만 필요한 정규화기가 존재하지 않는 경우, 외부 라이브러리가 발견될 수 있고 필요한 컴포넌트를 포함한다고 가정하면 정규화기는 그러한 외부 컴포넌트 라이브러리로부터 찾아질 수 있다. 파이프라인은 또한 스키마가 아직 알려져 있지 않은 데이터를 분석하고 분석 결과를 알려진 컴포넌트 라이브러리 내의 스키마 정보와 비교하여 데이터의 타입에 대한 동적 판정을 시도하며, 그에 따라 필요한 정규화기 컴포넌트를 찾아낼 수 있다.

이와 달리, 모든 정규화 컴포넌트를 포함하는 입력 데이터 대신에, 입력 데이터는 정규화 변환을 규정하는 변환 정의를 제공할 수 있다. 그 후 집합(830)은 이 변환 정의를 0개 이상의 표준 디폴트 정규화 변환과 함께 변환을 실행하는 대응하는 정규화 컴포넌트로 변환하도록 구성될 수 있다. 이것은 데이터부(800)가 입력 데이터를 소비하고 대응하는 정규화된 데이터를 파이프라인 아래로 더 이상 제공하지 않는 경우의 일례를 나타낸다. 그러나, 아마도 대부분의 경우에는, 입력 데이터(801)로 인해 대응하는 정규화된 데이터(840)가 생성된다.

일실시예에서, 데이터부(810)는 입력 데이터를 입력 데이터의 파일 타입 및/또는 포맷 타입에 기초하여 데이터 정규화 컴포넌트에 할당하도록 구성될 수 있다. 다른 특징들은, 예컨대 입력 데이터의 소스를 포함할 수 있다. 디폴트 정규화 컴포넌트는 지정된 대응하는 정규화 컴포넌트를 갖지 않는 입력에 할당될 수 있다. 디폴트 정규화 컴포넌트는 입력 데이터를 정규화하기 위한 규칙 세트를 적용할 수 있다. 디폴트 정규화 컴포넌트가 데이터를 정규화할 수 없으면, 디폴트 정규화 컴포넌트는 입력 데이터에 대한 스키마 정의를 제공하도록 사용자에게 요청하기 위해 도 6의 오서링 컴포넌트(640)를 트리거링할 수도 있다. 스키마 정의가 이미 존재하지 않으면, 오서링 컴포넌트(640)는 사용자를 도와 입력 데이터를 정규 형태로 변환하는데 사용될 수 있는 대응하는 스키마 정의를 생성하기 위해 스키마 정의 보조기를 제시할 수 있다. 데이터가 정규 형태이면, 그 데이터를 수반하는 스키마는 그 데이터에 대해 파이프라인(701)의 나머지가 그 데이터를 해석하기 위해 새로운 코드를 필요로 하지 않는다는 충분한 설명을 제공한다. 대신에, 파이프라인(701)은 액세스가능 스키마 선언 언어를 표현할 수 있는 임의의 스키마에 비추어 데이터를 해석할 수 있는 코드를 포함한다.

여하튼, 정규 데이터(840)는 데이터부(800)로부터의 출력 데이터 및 분석부(1100)로의 입력 데이터로서 제공된다. 정규 데이터는 다양한 데이터 타입을 포함하는 필드를 포함한다. 예를 들어, 이들 필드는 정수와 같은 간단한 데이터 타입, 부동 소수점 수(floating point number), 스트링, 벡터, 어레이, 집합(collection), 계층적 구조, 텍스트, XML 문서, 테이블, 리스트, SQL 데이터베이스 쿼리 결과, BI(business intelligence) 큐브 쿼리 결과, 2D 드로잉 및 3D 비주얼 모델과 같은 다양한 포맷의 정보, 또는 이들 다양한 데이터 타입의 보다 복잡한 조합을 포함할 수 있다. 다른 이점으로서, 정규화 프로세스는 다양한 입력 데이터를 정규화할 수 있다. 또한, 데이터부(800)가 수용할 수 있는 다양한 입력 데이터는 확장가능하다. 본 명세서에서 후술하는 바와 같이 이것은 복수의 모델이 조합되는 경우에 도움이 된다.

도 9는 도 7의 파이프라인(701)의 분석부(720)의 일례를 나타내는 분석부(900)를 도시한 것이다. 데이터부(800)는 정규화된 데이터(901)를 데이터 모델 바인딩 컴포넌트(910)에 제공한다. 정규화된 데이터(901)는 임의의 정규화된 형태, 및 임의의 수의 파라미터를 가질 수 있으며, 여기서 파라미터의 형태 및 개수는 입력 데이터의 조각마다 상이할 수 있다. 그러나, 설명을 위해, 정규 데이터(901)는 필드(902A 내지 902H)를 가지며, 이들은 본 명세서에서 "필드(902)로 통칭될 수 있다.

반면에, 분석부(900)는 다수의 모델 파라미터(911)를 포함한다. 모델 파라미터의 타입 및 개수는 모델에 따라 다를 수 있다. 그러나, 특정 예를 설명하기 위해, 모델 파라미터(611)는 모델 파라미터(911A, 911B, 911C, 911D)를 포함하는 것으로 설명될 것이다. 일실시예에서, 모델 파라미터의 아이덴티티 및 모델 파라미터들 간의 분석 관계는 명령형 코딩을 사용하지 않고 선언적으로 정의될 수 있다.

데이터 모델 바인딩 컴포넌트(910)는 정규화된 데이터 필드(902)와 모델 파라미터(911) 사이에 개재하여 필드들 사이의 바인딩을 제공한다. 이 경우, 데이터 필드(902B)는 화살표(903A)로 표시된 모델 파라미터(911A)에 바인딩된다. 다시 말하면, 모델 파라미터(911A)를 채우기 위해 데이터 필드(902B)로부터의 값이 사용된다. 또한, 이 예에서, 데이터 필드(902E)는 (화살표(903B)로 표시된 바와 같이)모델 파라미터(911B)에 바인딩되고, 데이터 필드(902H)는 (화살표(603C)로 표시된 바와 같이) 모델 파라미터(911C)에 바인딩된다.

데이터 필드(902A, 902C, 902D, 902F, 902G)는 모델 파라미터들 중 어느 것에도 바인딩되지 않는 것으로 도시되어 있다. 이것은 입력 데이터로부터의 모든 데이터 필드가 항상 모델 파라미터로서 사용되도록 요구되지는 않는다는 것을 강조하기 위한 것이다. 일실시예에서, 이들 데이터 필드 중 하나 이상은 데이터 모델 바인딩 컴포넌트(610)에 정규화된 데이터(정규화된 데이터 또는 어쩌면 임의의 장래의 유사한 정규화된 데이터)로부터의 어느 필드가 어느 모델 파라미터에 바인딩되는지에 대한 명령어를 제공하는데 사용될 수 있다. 이것은 도 7의 분석부(720)에 제공될 수 있는 일종의 분석 데이터(721)의 일례를 나타낸다. 정규화된 데이터로부터의 어느 데이터 필드가 어느 모델 파라미터에 바인딩되는지에 대한 정의는 다양한 방식으로 공식화될 수 있다. 예를 들어, 바인딩은 1) 작성 시간에 작성자에 의해 명시적으로 설정될 수도 있고, 2) 사용 시에 (작성자에 의해 부과된 임의의 조건에 따라)사용자에 의해 명시적으로 설정될 수도 있으며, 3) 알고리즘 경험에 기초한 오서링 컴포넌트(740)에 의한 자동 바인딩 및/또는 4) 바인딩이 알고리즘 방식으로 만들어질 수 없다고 판정될 경우에 바인딩을 지정하기 위해 작성자 및/또는 사용자의 오서링 컴포넌트에 의해 프롬프팅하는 것일 수 있다. 따라서, 바인딩은 모델 로직 자체의 일부로서 분해될 수도 있다.

작성자가 어느 데이터 필드가 어느 모델 파라미터에 맵핑될지를 정의할 수 있게 하는 능력은 작성자가 모델 파라미터를 정의하기 위해 쉽게 다루는 심볼을 사용할 수 있도록 하는 유연성을 작성자에게 제공한다. 예를 들어, 모델 파라미터들 중 하나가 압력을 나타내면, 작성자는 그 모델 파라미터의 이름을 "압력(Pressure)" 또는 "P" 또는 작성자에게 그러한 의미를 느끼게 하는 다른 심볼로 명명할 수 있다. 작성자는 모델 파라미터의 이름을 바꿀 수도 있는데, 일실시예에서, 이것은 데이터 모델 바인딩 컴포넌트(910)가 이전 이름의 모델 파라미터에 대한 바인딩이 새로운 이름의 모델 파라미터에 바인딩되도록 자동으로 업데이트하게 함으로써 원하는 바인딩을 유지할 수 있다. 바인딩에 대한 이 메커니즘은 바인딩이 런타임에 선언적으로 변경되도록 한다.

모델 파라미터(911D)는 이 예에서 모델 파라미터(911D)가 데이터 모델 바인딩 컴포넌트(910)에 의해 값을 할당받지 않음을 강조하기 위해 별표로 표시되어 있다. 따라서, 모델 파라미터(911D)는 미지수(unknown)로 남는다. 즉, 모델 파라미터(911D)는 값을 할당받지 않는다.

모델링 컴포넌트(920)는 다수의 기능을 수행한다. 첫째, 모델링 컴포넌트(920)는 모델 파라미터들(911) 사이의 분석 관계(921)를 정의한다. 분석 관계(921)는 방정식(931), 규칙(932) 및 제약(933)을 포함하는 3개의 일반적인 범주로 분류된다. 그러나, 해결기의 리스트는 확장가능하다. 일실시예에서, 예를 들어, 하나 이상의 시뮬레이션에 대응하는 시뮬레이션 엔진이 해결기로서 제공되고 등록될 경우, 하나 이상의 시뮬레이션이 분석 관계의 일부로서 포함될 수 있다.

본 명세서에서 사용되는 "방정식(equation)"이란 용어는 수학 분야에서 사용할 때의 용어와 같다.

본 명세서에서 사용된 용어 "규칙(rule)"은 하나 이상의 조건이 만족되면(조건부 또는 조건문의 "if" 부분) 하나 이상의 액션이 취해지는(조건문의 결과 또는 "then" 부분) 조건문을 의미한다. 하나 이상의 모델 파라미터가 조건문으로 표현되거나 또는 하나 이상의 모델 파라미터가 결과문으로 표현되면, 규칙은 모델 파라미터에 적용된다.

본 명세서에 사용된 "제약(constraint)"은 하나 이상의 모델 파라미터에 제한이 적용됨을 의미한다. 예를 들어, 도시 계획 모델에서, 특정 주택 요소는 가능한 지정된 전체 구역의 부분집합을 갖는 지도 위치 상의 장소로 제한될 수 있다. 교량 요소는 소정의 최대 길이 또는 소정 개수의 차선 이하로 제한될 수 있다.

모델에 익숙한 작성자는 그 모델에 적용하는 이들 방정식, 규칙 및 제약의 표현을 정할 수 있다. 시뮬레이션의 경우에, 작성자는 모델 파라미터들 사이의 적절한 시뮬레이션 관계를 제공하는 적절한 시뮬레이션 엔진을 제공할 수 있다. 모델링 컴포넌트(920)는 작성자가 방정식, 규칙 및 제약에 대한 자연적인 심볼 표현을 제공하는 메커니즘을 제공할 수 있다. 예를 들어, 열역학 관련 모델의 작성자는 단순히 열역학 교재에서 방정식을 복사하여 붙여넣기할 수 있다. 모델 파라미터를 데이터 필드에 바인딩하는 능력은 (작성자가 신뢰하는 교재에서 사용된 정확한 심볼과 같은)작성자에게 익숙한 어떠한 심볼도 또는 작성자가 사용하고자 하는 정확한 심볼을 작성자가 사용할 수 있게 한다.

모델링 컴포넌트(920)는 또한, 문제를 풀기 전에, 모델 파라미터들 중 어느 것을 풀어야 하는지를 식별한다(즉, 이하에서는 하나의 출력 모델 변수가 있는 경우에는 "출력 모델 변수", 복수의 경우에는 "출력 모델 변수들", 또는 하나 또는 복수의 출력 모델 변수가 있을 수 있는 경우에는 "출력 모델 변수(들)"이라 함). 출력 모델 변수는 미지의 파라미터일 수도 있고, 기지의 모델 파라미터일 수도 있으며, 기지의 모델 파라미터의 값은 솔브 연산(solve operation)의 변화에 따른다. 도 9의 예에서, 데이터 모델 바인딩 연산 후에, 모델 파라미터(911A, 911B, 911C)가 알려지고, 모델 파라미터(911D)는 알려지지 않는다. 따라서, 미지의 모델 파라미터(911D)는 출력 모델 변수들 중 하나일 수 있다. 이에 갈음하여 또는 이에 더하여, 하나 이상의 기지의 모델 파라미터(911A, 911B, 911C)는 출력 모델 변수일 수도 있다. 그 후 가능하다면 해결기(640)가 출력 모델 변수를 구한다. 후술하는 일실시예에서, 솔브 연산이 수행될 수 있도록 충분한 입력 모델 변수가 제공되는 한, 해결기(940)는 단일 모델 내에서도 다양한 출력 모델 변수를 구할 수 있다. 입력 모델 변수는, 예컨대, 그 값이 솔브 연산 동안 변하지 않는 기지의 모델 파라미터일 수 있다. 예를 들어, 도 9에서, 모델 파라미터(911A, 911D)가 입력 모델 변수이면, 해결기는 대신에 출력 모델 변수(911B, 911C)를 구할 수 있다. 일실시예에서, 해결기는 단일 모델 파라미터에 대해 다수의 상이한 데이터 타입 중 임의의 하나를 출력할 수 있다. 예를 들어, (덧셈, 뺄셈 등과 같은)일부 방정식 연산은 피연산자가 정수, 부동 소수점, 벡터, 또는 행렬인지의 여부에 관계없이 적용된다.

일실시예에서, 해결기(940)가 특정한 출력 모델 변수를 구할 수 없는 경우에도, 심지어 실제 수치 결과에 대한 완전한 솔브(full solve)(또는 데이터 타입 구하기)가 가능하지 않더라도, 해결기(900)는 그 출력 모델 변수에 대한 특정 해를 여전히 제시할 수 있다. 이것은 완전한 솔브에 도달하기 위해 어떤 정보가 필요한지에 대해 작성자에게 프롬프트함으로써 파이프라인이 점증적인 개발을 용이하게 하도록 할 수 있다. 이것은 또한 작성 시간 및 사용 시간 사이의 차이를 제거하는 것을 돕는데, 그 이유는 적어도 부분적인 솔브가 다양한 작성 스테이지에 걸쳐 이용가능하기 때문이다. 추상적인 예로서, 분석 모델이 방정식 a=b+c+d를 포함한다고 가정해 보자. 이제, a, c 및 d는 출력 모델 변수이고, b는 알려진 값 5(이 경우에는 정수)를 갖는 입력 모델 변수라고 가정해 보자. 해결 과정에서, 해결기(940)는 출력 모델 변수들 중 하나("d")만 구할 수 있고, 6(정수)의 값을 "d"라고 하는 모델 파라미터에 할당하지만, 해결기(640)는 "c"는 구할 수 없다. "a"는 "c"에 의존하므로, "a"라고 하는 모델 파라미터는 미지수로 남아 있고 구할 수 없다. 이 경우, 정수 값을 "a"에 할당하는 대신에, 해결기는 부분 솔브를 할 수 있고 "c+11"의 문자열 값을 모델 파라미터 "a"에 출력한다. 전술한 바와 같이, 이것은 당업자가 분석 모델을 작성하고 있는 경우에 특히 도움이 될 수 있으며, 모델 파라미터 "a"의 내용에 대한 부분적인 정보를 제공하는 역할을 하며, 또한 "c" 모델 파라미터가 구해지도록 몇몇 추가 모델 분석이 제공될 필요가 있음을 작성자에게 암시하는 역할을 할 것이다. 이 부분적인 솔브 결과는 아마도 당업자가 부분적인 결과를 알 수 있도록 하기 위해 뷰 컴포지션에 일부 방식으로 출력될 수 있다.

해결기(940)는 도 9에 단순화된 형태로 도시되어 있다. 그러나, 해결기(940)는 도 10과 관련하여 설명하는 바와 같이 복수의 구성요소 해결기의 연산을 지시할 수 있다. 도 9에서, 모델링 컴포넌트(920)는 (이제 알고 있고 구해진 출력 모델 변수를 포함하는)모델 파라미터를 도 10의 보기부(1000)에 제공될 출력으로서 이용가능하게 한다.

도 10은 도 7의 보기부(730)의 일례를 나타내는 보기부(1000)를 도시하며, 재계산 사용자 인터페이스(500) 내의 시각화된 컨트롤의 예들을 나타낸다. 보기부(1000)는 도 9의 분석부(900)로부터 모델 파라미터(911)를 수신한다. 보기부는 또한 뷰 컴포넌트의 집합을 포함하는 뷰 컴포넌트 저장소(1020)를 포함한다. 예를 들어, 이 예에서 뷰 컴포넌트 저장소(1020)는 뷰 컴포넌트(1021 내지 1024)를 포함하는 것으로 도시되어 있지만, 뷰 컴포넌트 저장소(1020)는 임의의 개수의 뷰 컴포넌트를 포함할 수 있다. 뷰 컴포넌트는 각각 0개 이상의 입력 파라미터를 포함할 수 있다. 예를 들어, 뷰 컴포넌트(1021)는 어떠한 입력 파라미터도 포함하지 않는다. 그러나, 뷰 컴포넌트(1022)는 2개의 입력 파라미터(1042A, 1042B)를 포함한다. 뷰 컴포넌트(1023)는 하나의 입력 파라미터(1043)를 포함하고, 뷰 컴포넌트(1024)는 하나의 입력 파라미터(1044)를 포함한다. 즉, 이것은 단지 일례일 뿐이다. 입력 파라미터는 반드시 그런 것은 아니지만 비주얼 아이템이 렌더링되는 방법에 영향을 미친다. 뷰 컴포넌트(1021)가 어떠한 입력 파라미터도 포함하지 않는다는 사실은 어떠한 모델 파라미터에 대한 참조없이 생성되는 뷰가 있을 수 있음을 강조한다. 변하지 않는 고정된(내장된) 데이터를 포함하는 뷰를 고려해 보자. 이러한 뷰는 예컨대 사용자에 대한 참조 정보를 구성할 수 있다. 또는 모델에 임포트할 아이템들이 선택될 수 있도록 카탈로그를 브라우징하는 방법을 제공하는 뷰를 고려해보자.

각각의 뷰 컴포넌트(1021 내지 1024)는, 대응하는 뷰 컴포넌트 입력 파라미터가 있다면 이를 사용하여 뷰 컴포지션 컴포넌트(1040)에 의해 실행될 경우에, 대응하는 뷰 아이템이 가상 공간(1050)에 위치하게 하는, 대응하는 로직을 포함하거나 이와 연관된다. 이 가상 아이템은 정적 이미지 또는 객체일 수도 있고, 또는 동적인 에이메이션 가상 아이템 또는 객체일 수도 있다. 예를 들어, 각각의 뷰 컴포넌트(1021 내지 1024)는, 실행될 경우에 대응하는 가상 아이템(1051 내지 1054)이 제각기 가상 공간(1050)에 렌더링되게 하는, 대응하는 로직(1031 내지 1034)가 연관된다. 가상 아이템은 단순한 형태로 도시된다. 그러나, 가상 아이템은 형상에 있어서 상당히 복잡할수도 있고 심지어 애니메이션을 포함할 수도 있다. 본 예에서는, 뷰 아이템이 가상 공간에 렌더링될 때, 이것은 뷰 컴포지션 컴포넌트가 충분한 명령어를 작성했음을 의미하며, 렌더링 엔진에 제공될 때 렌더링 엔진이 지정된 위치에 지정된 방식으로 디스플레이 상에 뷰 아이템을 디스플레이할 수 있음을 의미한다.

뷰 컴포넌트(1021 내지 1024)는 예를 들어 도 7의 오서링 컴포넌트(740)를 사용하여 보기부(1000)에 뷰 데이터로서 제공될 수도 있다. 예를 들어, 오서링 컴포넌트(740)는 작성자가 몇몇 기하학적 형태로부터 선택할 수 있게 하거나 또는 다른 기하학적 형태를 작성할 수도 있게 하는 선택기를 제공할 수 있다. 작성자는 또한 각각의 뷰 컴포넌트에 대한 입력 파라미터의 타입을 지정할 수도 있고, 반면에, 일부 입력 파라미터는 보기부(1000)에 의해 부과된 디폴트 입력 파라미터일 수 있다. 각각의 뷰 컴포넌트(1021 내지 1024)와 연관되는 로직은 또한 뷰 데이터를 제공받을 수 있고/있거나 보기부(1000) 자체에 의해 일부 디폴트 기능을 포함할 수도 있다.

보기부(1000)는 모델 파라미터들 중 적어도 일부를 뷰 컴포넌트(1021 내지 1024)의 대응하는 입력 파라미터에 바인딩하도록 구성되는 모델-뷰 바인딩 컴포넌트(1010)를 포함한다. 예를 들어, 모델 파라미터(911A)는 화살표(1011A)로 표시된 뷰 컴포넌트(1022)의 입력 파라미터(1042A)에 바인딩된다. 모델 파라미터(911B)는 화살표(1011B)로 표시된 뷰 컴포넌트(1022)의 입력 파라미터(1042B)에 바인딩된다. 또한 모델 파라미터(911D)는 화살표(1011C)로 표시된 뷰 컴포넌트(1023, 1024)의 입력 파라미터(1043, 1044)에 각각 바인딩된다. 모델 파라미터(911C)는 어떠한 대응하는 뷰 컴포넌트 파라미터에도 바인딩되지 않는 것으로 도시되어 있고, 모든 모델 파라미터가 분석부에 필수적이더라도 이들 모든 모델 파라미터가 파이프라인의 보기부에 의해 사용될 필요는 없음을 강조한다. 또한, 모델 파라미터(911D)는 뷰 컴포넌트의 두 개의 상이한 입력 파라미터에 바인딩된 것으로 도시되어 있는데, 이는 모델 파라미터들이 복수의 뷰 컴포넌트 파라미터에 바인딩될 수 있음을 나타낸다. 일실시예에서, 모델 파라미터와 뷰 컴포넌트 파라미터 사이의 바인딩의 정의는 1) 작성 시간에 작성자에 의해 명시적으로 설정되는 것, 2) 사용 시에 (작성자에 의해 부과된 임의의 조건에 따라)사용자에 의해 명시적으로 설정되는 것, 3) 알고리즘 경험에 기초한 오서링 컴포넌트(740)에 의한 자동 바인딩 및/또는 4) 바인딩이 알고리즘 방식으로 이루어질 수 없다고 판정될 경우에 바인딩을 지정하기 위해 작성자 및/또는 사용자의 오서링 컴포넌트에 의해 프롬프팅하는 것에 의해 공식화될 수 있다.

본 발명은 그 사상 또는 필수적 특징으로부터 벗어나지 않고 다른 특정한 형태로 구현될 수 있다. 기술된 실시예는 모든 면에서 예시적인 것일 뿐 제한적인 것으로 간주되어서는 안 된다. 따라서, 본 발명의 범위는 전술한 상세한 설명에 의해서가 아니라 첨부한 청구범위에 의해 나타내어진다. 청구범위의 균등물의 의미 및 범위 내에 포함되는 모든 변경들이 이들의 범위 내에 포함되어야 한다.

Claims (10)

1. 컴퓨팅 시스템의 하나 이상의 프로세서에 의해 실행될 경우에 상기 컴퓨팅 시스템으로 하여금 재계산(recalculation) 사용자 인터페이스를 조작하게 하도록 구성된 컴퓨터 실행가능 명령어가 저장되어 있는 하나 이상의 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품으로서,
   상기 재계산 사용자 인터페이스는
   이벤트의 검출 시에 환경 신호를 캡처하도록 구성된 신호 캡처 컨트롤(signal capture control)과,
   출력 데이터에 응답하여 디스플레이하도록 구성된 시각화 컨트롤(visualization control)과,
   상기 신호 캡처 컨트롤과 상기 시각화 컨트롤 사이의 하나 이상의 선언적 변환(declarative transformation)의 변환 채널
   을 포함하는 컴퓨터 프로그램 제품.
   
2. 제1항에 있어서,
   상기 신호 캡처 컨트롤이 캡처하도록 구성되는 상기 환경 신호는 이미지인
   컴퓨터 프로그램 제품.
   
3. 제1항에 있어서,
   상기 신호 캡처 컨트롤이 캡처하도록 구성되는 상기 환경 신호는 비디오인
   컴퓨터 프로그램 제품.
   
4. 제1항에 있어서,
   상기 신호 캡처 컨트롤이 캡처하도록 구성되는 상기 환경 신호는 방향(orientation)인
   컴퓨터 프로그램 제품.
   
5. 제1항에 있어서,
   상기 신호 캡처 컨트롤이 캡처하도록 구성되는 상기 환경 신호는 위치인
   컴퓨터 프로그램 제품.
   
6. 제1항에 있어서,
   상기 신호 캡처 컨트롤이 캡처하도록 구성되는 상기 환경 신호는 오디오인
   컴퓨터 프로그램 제품.
7. 제1항에 있어서,
   상기 신호 캡처 컨트롤이 캡처하도록 구성되는 상기 환경 신호는 날씨 데이터인
   컴퓨터 프로그램 제품.
   
8. 제1항에 있어서,
   상기 이벤트는 변환으로부터의 데이터의 수신인
   컴퓨터 프로그램 제품.
   
9. 제1항에 있어서,
   상기 변환 체인은 추가 데이터를 사용하는 로직을 포함하는
   컴퓨터 프로그램 제품.
   
10. 사용자 인터페이스를 제공하도록 구성된 재계산 사용자 인터페이스 오서링(authoring) 시스템으로서,
    신호 캡처 컨트롤들의 라이브러리 -상기 라이브러리 캡처 컨트롤의 인스턴스는 대응하는 이벤트에 응답하여 환경 신호를 캡처하도록 구성됨- 와,
    시각화 컨트롤들의 라이브러리와,
    상기 신호 캡처 컨트롤들 중 하나 이상과 상기 시각화 컨트롤들 중 하나 이상을 선택하고 상기 선택된 컨트롤을 모델(model)에 배치하는 컨트롤 선택 메커니즘과,
    변환들을 선언적으로 표현하고 상기 모델 내에서 변환들을 상기 선택된 컨트롤과 결합하는 변환 메커니즘
    을 포함하는 재계산 사용자 인터페이스 오서링 시스템.

Images