KR20040096577A

KR20040096577A - 실시간 시스템 제어용 컴포넌트 모델

Info

Publication number: KR20040096577A
Application number: KR10-2004-7012718A
Authority: KR
Inventors: 브라이언 스펜서 프랭크; 죤 더블유. 서블렛
Original assignee: 트리디움 인코퍼레이티드
Priority date: 2002-02-15
Filing date: 2003-02-18
Publication date: 2004-11-16
Also published as: EP1474753B1; CA2475050A1; US20030159129A1; AU2003211125A1; EP1474753A4; US7822806B2; WO2003071444A9; US20030158975A1; WO2003071442A1; US20040215740A1; CN101719056B; US7225426B2; EP1474753A1; CN1669020A; WO2003071442A9; WO2003071444A1; AU2003211126A1; JP2006504156A; CN101719056A

Abstract

각각의 컴포넌트가 컴포넌트 타입에 기초하는 컴포넌트 기초 소프트웨어 프로그램이 개시된다. 컴포넌트 타입은 슬롯 정의를 포함하는 베이스 클래스로부터 생성된다. 슬롯 정의는 컴포넌트 타입 오브젝트에서 식별되며 저장된다. 컴포넌트 타입의 하나 이상의 컴포넌트들이 생성된다. 이들 각각은 컴포넌트 타입 오브젝트에 대한 참조와, 컴포넌트 타입 오브젝트에서 속성 슬롯 정의와 연관된 값에 대한 저장 위치를 구비하는 슬롯맵을 포함한다. 속성 슬롯에 대한 값은 저장 위치에 배치됨에 의해 컴포넌트로 기입된다. 또한, 컴포넌트에 대한 고유 이름을 자동적으로 지정하는 방법이 개시된다. 하나의 루트 컴포넌트가 생성된다. 더욱이, 비루트 컴포넌트가 루트 컴포넌트 또는 다른 컴포넌트내에 배치되어, 모든 컴포넌트가 트리 구조를 형성하게 된다. 컴포넌트는 모든 컴포넌트 앤세스터 및 컴포컨트의 이름의 순차적인 리스트를 포함하는 고유 식별 스트링이 할당된다.

Description

실시간 시스템 제어용 컴포넌트 모델{COMPONENT MODEL FOR REAL TIME SYSTEM CONTROL}

커스텀 소프트웨어가 이들의 문제를 해결하도록 여러 다른 시도들이 요구된다. 전형적으로, 이들 문제는 도메인 전문가, 예컨대, 빌딩 자동화 전문가, 공장 자동화 전문가, 및 교통 제어 전문가에 의해 보다 잘 이해된다. 그러나, 도메인 전문가가 예컨대 오브젝트 지향 프로그래밍과 같은 공통 프로그래밍 기술을 이용하기 위한 숙련된 기술을 가지는 경우는 드물다. 오늘날, 도메인 전문가는 소정의 시스템을 구축하는 프로그래머에게 이들의 요건을 특정하고자 한다. 이런 프로세스는 에러가 일어나기 쉬우며, 시간 소모적이고 오류통신이 가득차있다. 문제 공간을 이해하는 도메인 전문가가 소프트웨어 시스템 자체를 구축할 수 있는 능력이 요구된다. 도메인 전문가가 시간이 있는지 또는 전문적인 프로그래머가 되는지를 예상하는 것은 쉽지 않다. 따라서, 비전문가에 의해 커스텀 소프트웨어의 생성을 가능하게 하는 툴(tool)을 제공하는 것이 필요하다. 이상적으로, 이들 툴은 소프트웨어 시스템의 구성 파라미터들, 실행 로직 및 데이터가 그래픽적으로 가시화되게 한다. 그래픽 툴은 도메인 전문가에게 암호화된 프로그래밍 언어 신택스(syntax)를 이해할 필요없이 소프트웨어 시스템을 생성, 모니터링 및 변경할 수 있게 한다.

컴포넌트 지향 시스템은 실세계 요구를 지향하는 어플리케이션을 구축하도록 연결될 수 있는 컴포넌트들로 소프트웨어 기능을 인캡슐레이팅(encapsulating)함에 의해 이들 특징중 일부를 제공하는 새로운 개념의 일부이다. 그러나, 공지된 종래의 접근법은 실제 시스템을 구현하기 위하여 프로그래밍 언어의 지식을 여전히 요구한다. 이런 지점까지, 소프트웨어 컴포넌트는 프로그래밍 능력이 컴포넌트들을 함께 연결할 것을 요구하여 기능적 시스템을 생성한다. 더욱이, 기존의 컴포넌트 기술은 도메인 전문가로 하여금 전체 시스템을 그래픽적으로 가시화하며 실행시간에서 변화하게 허용하지 않는다. 예컨대, 도메인 전문가는 실행 플로우를 변경하거나 또는 실행기간에서 새로운 행위를 부가하길 원하며, 이것이 소프트웨어 시스템상에서 어떤 효과를 가지는지를 안다. 이런 예비적인 프로그래밍 접근법은 소프트웨어가 정지, 재편집 및 재개시될 것을 요구하는 현재의 솔루션에 대면하고 있다. 더욱이, 소프트웨어의 부가, 수정 또는 업데이트는 성능 부가 특징 등을 개선하기 위해 요구된다. 현재 솔루션은 일단 다시 소프트웨어가 임의의 업데이트, 부가 또는 수정을 위해 정지, 재편집 및 재개시될 것을 요구한다. 소프트웨어의 정지는 결정적인 프로세스가 제어되는 일부 환경에서는 특히 다르게 된다. 이런 솔루션의 제공시 다른 특정 문제는 도메인 전문가로 하여금 특정도메인 어플리케이션의 고유 요구에 적응하도록 소프트웨어 컴포넌트를 강화 또는 확장하게 하는 요구에 있다. 역사적으로, 부가 또는 확장은 종래의 프로그래밍 능력 및 지식을 요구한다. 본 발명은 이러한 필요 및 다른 필요를 지향한다.

본 발명은 이하 참고로 합체되는 "COMPONENT MODEL FOR REAL-TIME SYSTEM CONTROL"의 미국 가출원 제 60/357,329호(2002.2.15 출원)로부터의 우선권 이득을 주장한다.

도 1은 컴포넌트 타입의 생성 및 이런 컴포넌트 타입의 여러 컴포넌트 인스탄스(instance)를 도시한 플로우챠트이다.

도 2는 동일한 컴포넌트 타입으로부터 발생된 2개의 컴포넌트를 도시한 블럭도이다.

도 3은 동적 슬롯을 포함하는 컴포넌트 시스템을 도시한 블럭도이다.

도 4는 링크를 포함하는 컴포넌트 시스템을 도시한 블럭도이다.

도 5A는 상세한 구성은 생략된체, 링크를 포함하는 컴포넌트 시스템의 컴포넌트 레벨 요약(abstraction)을 도시한 블럭도이다.

도 5B는 링크가 제거된 도 5A에 도시된 컴포넌트 시스템을 도시한 블럭도이다.

도 6은 효율을 개선하기 위해 재편집된(recompiled) 컴포넌트 시스템의 블럭도이다.

도 7은 트리 구성에서 컴포넌트 시스템을 도시한 블럭도이다.

도 8은 비주얼(visual) 인터페이스의 동작을 도시한 플로우챠트이다.

본 발명의 일면은 그 코드가 기계상에서 실행하기 위한 동일한 컴포넌트 타입의 하나 이상의 컴포넌트들을 포함하는 소프트웨어 프로그램이다. 이런 소프트웨어 프로그램의 컴포넌트는 특정 방법에 의해 발생된다. 이런 방법에서, 베이스 클래스는 프레임웍(framework)에 제공되며, 이런 베이스 클래스는 속성(property) 슬롯 정의인 하나 이상의 슬롯 정의중 적어도 하나를 포함한다. 베이스 클래스에서 모든 속성 슬롯 정의는 식별된다. 이들 속성 슬롯 정의 각각에서, 게더 및 세터(getter and setter) 방법이 위치한다. 슬롯 정의를 저장하도록 구성되는 컴포넌트 타입 오브젝트가 발생된다. 식별된 속성 슬롯 정의는 이런 컴포넌트 타입 오브젝트에 저장된다. 하나 이상의 컴포넌트가 발생된다. 이들 컴포넌트 각각은 슬롯 맵 클래스로부터 예시화되는 슬롯맵 오브젝트(slotmap object)를 구비한다. 각각의 슬롯 맵 오브젝트는 컴포넌트-타입 오브젝트에 저장된 각각의 속성 슬롯 정의에 대한 값을 또한 포함한다. 각각의 값은 단일 컴포넌트와 연관되어, 각각의 컴포넌트에 고유한 데이터를 저장하기 위한 능력을 제공한다.

이런 특징의 컴포넌트의 추가적인 개발에서는 이들 속성 및 데이터 필드를 동적 슬롯을 통해 확장하도록 허용하는 방식으로 설계된다.

본 발명의 다른 특징에서, 컴포넌트 기반 소프트웨어 시스템의 확장에 이름을 자동적으로 지정하는 방법이 제공된다. 이런 방법에서, 루트(root) 컴포넌트가 생성된다. 루트 컴포넌트는 부모(parent)를 가지지 않는다. 하나 이상의 비루트 컴포넌트는 루트 컴포넌트 내에 배치되고, 하나 이상의 다른 루트 컴포넌트는 비루트 컴포넌트내에 배치되어, 모든 비루트 컴포넌트는 부모를 가지며 전체 구조는 트리(tree)를 구성하게 된다. 이런 지점에서, 컴포넌트는 컴포넌트의 모든 앤세스터(ancestor)의 순차적인 리스트와 컴포넌트 명을 포함하는 고유 식별 스트링이 할당된다.

이런 특징의 추가적인 개발에서, 명명 방법론이 컴포넌트의 개별 슬롯을 식별하는 것으로 확장된다.

본 발명의 이들 및 다른 특징과, 이점은 다음의 첨부된 도면 및 바람직한 실시예의 설명을 통해 보다 잘 이해될 것이다.

본 발명의 컴포넌트 모델은 비프로그래머에 적합한 그래픽 환경에서 어플리케이션 개발자로 하여금 소프트웨어 컴포넌트를 확장 및 수정하게 하는 소프트웨어 컴포넌트에 대한 고유 컴포넌트 설계를 제공한다. 컴포넌트 모델 설계는 새로운 슬롯, 예컨대 속성(property), 액션(action) 또는 토픽(topic)이, 전형적으로 요구되는 소프트웨어 코딩 스텝없이 표준 컴포넌트에 부가될 수 있게 한다.

소프트웨어에 대한 컴포넌트 모델 접근법은 소프트웨어 컴포넌트가 최종 사용 어플리케이션에 대해 직접적인 관계를 가지게 생성되게 하며, 그 동안 오브젝트 지향 소프트웨어 설계의 이득을 여전히 이용한다. 이와 같이, 컴포넌트는 순수한 오브젝트 지향 접근법 보다 높은 레벨의 요약을 제공한다. 오브젝트가 소프트웨어 기능들(예컨대, 스트링의 조작, 버퍼 관리 제공, 등)에 적용가능한 행위(behavior)를 인캡슐레이팅하는 경우, 컴포넌트는 최종 어플리케이션 목표의 필요(예컨대, 스케줄을 변경하고, 경보를 검토하며 응답확인(acknowledgement) 커맨드를 디바이스 발행 경보에 다시 전달하기 위하여 사용자 인터페이스 프리젠테이션을 제공하는 것등)를 만족시키기 위하여 오브젝트를 어셈블링한다.

2 레벨의 요약이 존재한다. 하나는 오브젝트 지향 레벨로서 컴포넌트를 구현하는 것을 다루며, 다른 하나는 오브젝트 지향 레벨을 숨기며 컴포넌트의 사용을 통해 특정 실세계 어플리케이션에 관련된 어플리케이션을 생성하는 것을 다룬다. 또한 본 발명의 소프트웨어를 동작하며 수정하는 2 종류의 사람들, 즉 개발자 및 사용자가 있다. 개발자는 오브젝트 지향 개념을 이용하여 본 발명의 컴포넌트 모델을 구현한다. 선택적으로, 개발자는 컴포넌트 레벨상에서 정의되는 기능을 또한 생성한다. 사용자는 일반적으로 오브젝트 지향 구현을 볼 수 없다. 오히려, 사용자는 컴포넌트를 거의 독점적으로 다루며, 컴포넌트 레벨상에서 시스템을 모니터링, 생성 및 수정한다. 물론, 사용자 및 개발자는 동일한 사람일 수 있다.

소프트웨어 프로그램내의 컴포넌트는 컴포넌트 타입을 기초로 생성된다. 컴포넌트 타입은 오브젝트 지향 프로그래밍에서 클래스의 개념과 유사하다. 즉, 이런 타입에 속하는 컴포넌트 인스탄스의 모든 공통 특징을 설명하는 요약이다. 바람직한 실시예에서, 컴포넌트 타입뿐만 아니라 기능과 관련된 대부분의 다른 컴포넌트의 생성은 나이아가라 프레임웍(Niagara^TMFramework)으로 때때로 언급되는 프레임웍에 의해 행해진다. 프레임웍은 컴포넌트 모델의 구현에 관한 여러 유틸리티 기능(예컨대 컴포넌트 타입 및 컴포넌트들을 생성하며, 컴포넌트와 외부 소프트웨어 모듈 사이에 인터페이스를 제공하고, 슬롯을 이에 부가함으로써 컴포넌트를 확장할 수 있는 능력을 제공하는 등)을 수행하는 컴포넌트 기초 소프트웨어내의 소프트웨어 모듈이다. 프레임웍은 또한 초기화(부트스트랩(bootstrap) 페이즈(phase) 동안 및 컴포넌트 실행시간 실행 동안에 포함되는 소프트웨어의 실행 플로우에 제공된다.

오브젝트 지향 프로그램은 해당 클래스에 속하는 인스탄스를 할당하는데 사용되는 템플레이트(template)를 정의하는 클래스들로 이루어진다. 각각의 클래스는 멤버로 불리는 서브부분으로 이루어진다. 멤버는 데이터를 저장하는데 사용되는 필드이거나, 또는 실행가능한 행위를 저장하는데 사용되는 멤버일 수 있다.

본 발명은 오브젝트 지향 프리미티브(primitive)를 이용하여 구축된 컴포넌트를 기술한다. 컴포넌트 모델은 컴포넌트 지향 프로그램을 구축하기 위해 비프로그래머에 의해 사용될 수 있다. 컴포넌트 모델은 해당 타입(오브젝트 지향 클래스와 같은)에 속하는 인스탄스를 할당하는데 사용되는 템플레이트를 정의하는 컴포넌트 타입으로 이루어진다. 각각의 컴포넌트 타입은 슬롯으로 불리는 서브부분(오브젝트 지향 멤버와 같은)으로 이루어진다. 슬롯과 멤버간의 차이는 슬롯에는 매우 높은 레벨의 요약이 존재하여 슬롯이 비프로그래머 또는 컴포넌트 지향 프로그램의 최종 사용자에 의해 직접 사용된다는데 있다.

컴포넌트 모델에는 3가지 타입의 슬롯이 있다. 속성은 데이터 값을 저장하는 슬롯이다. 속성은 구성 데이터를 저장하며, 실시간 상태 정보를 제공하거나 임의의 다른 데이터를 저장하는데 사용된다. 액션은 방법과 유사하다 - 이들은 실행 행위를 저장하는 슬롯이다-. 예컨대, 최종 사용자가 부르는 액션은 "Turn On Fan"일 수 있다. 액션은 또한 순수한 소프트웨어 기능을 구현할 수 있다. 토픽은 제3슬롯 타입이다. 토픽은 이벤트를 표현하는데 사용된다. 토픽은 이벤트가 일어나는 것을 나타내는 것으로 발화(fire)한다.

링크는 특정 종류의 속성 슬롯이다. 링크는 컴포넌트 기초 소프트웨어에서 실행 플로우를 지정하는데 사용된다. 더욱 특히, 링크는 2개의 다른 슬롯들간의 캐주얼 관계를 생성하는데 사용된다. 이런 관계는 다른 기능의 발동에 응답하여 한 기능이 일어나는 것을 예고한다. 오브젝트 모델에서, 이들 관계는 정적 코드(예컨대, 조건 절차 호출)에 의해 통상 정의되며, 재편집없이 변경될 수는 없다. 컴포넌트 모델에서, 링크는 통상 동적 슬롯이며, 이에 따라 실행시간 동안 제거된체 생성되며, 소프트웨어가 재편집될 것을 요구함이 없이 소프트웨어의 실행 플로우를 변경할 수 있다.

컴포넌트 모델이 오브젝트 지향 프로그램으로서 구축되기 때문에, 오브젝트지향 멤버를 이용하여 컴포넌트 모델을 구현할 필요가 있다. 클래스, 멤버, 필드, 및 방법의 용어는 종래의 오브젝트 지향 개념을 참조한다. 컴포넌트 타입, 슬롯, 속성, 액션 및 토픽의 용어는 이들이 본 발명과 관련될 때 컴포넌트 지향 개념을 참조한다.

오브젝트와 컴포넌트간의 큰 차이중 하나는 컴포넌트가 실행시간에서 변경된다는데 있다. 예컨대, 새로운 방법을 오브젝트에 부가하려면, 전형적으로 오브젝트의 클래스를 재편집할 것을 요구한다. 컴포넌트 모델은 컴포넌트에서 슬롯을 정의하게 하며 실행시간에서 새로운 슬롯을 부가하게 한다. 편집된 코드에서 정의된 슬롯은 프로즌(frozen)이다. 프로즌 슬롯은 불변이나, 편집된 코드의 처리 효율을획득한다. 실행시간에서 정의된 슬롯은 동적이다.

오브젝트 지향 프로그래밍에서, 실행 프로그램내의 클래스 정의의 저장은 컴파일러(compiler)에 의해 조작되며, 개발자에게 크게 가시가능하지 않게 된다. 이런 이유로, 오브젝트 지향 프로그래밍에서, 클래스는 요약으로서 통상 언급되며, 실제 데이터 구조로서 언급되지 않는다. 따라서, 대부분의 오브젝트 지향 환경에서 개발자는 클래스 정의가 컴퓨터 메모리에서 물리적으로 어딘가 존재할 필요가 있다는 사실에 의해 혼동됨이 없이 실제 오브젝트의 요약 정의로서 클래스를 안전하게 언급할 수 있다.

본 발명의 컴포넌트 모델에서, 컴포넌트 타입은 저장되며, 컴퓨터 메모리에서 조작되야만 한다. 컴포넌트 타입의 저장은 오브젝트, 즉 컴포넌트 타입 오브젝트에 컴포넌트 타입을 저장함에 의해 프레임웍에 의해 바람직하게 행해진다. 따라서, 컴포넌트 타입 오브젝트는 컴포넌트 타입의 물리적 프리젠테이션(presentation)이다. 컴포넌트에서 컴포넌트 타입 오브젝트까지의 참조는 소정의 컴포넌트가 컴포넌트 타입에 속한다는 사실을 표현하는데 사용된다.

도 1은 컴포넌트 타입 오브젝트를 생성함에 의해 컴포넌트 타입이 생성되는 방법과, 이런 컴포넌트 타입에 기초한 여러 컴포넌트 인스탄스가 발생되는 방법을 예시하는 플로우챠트를 도시한다.

새로운 컴포넌트 타입을 생성하기 위하여, 개발자는 프레임웍에 클래스 정의를 제공할 필요가 있다 - 베이스 클래스(단계 100)-. 바람직한 실시예에서, 개발자는 베이스 클래스를 컴포넌트 기초 소프트웨어에 부가함에 의해 베이스 클래스를제공한다. 베이스 클래스의 멤버를 컴포넌트 모델에서 다른 타입의 슬롯에 매핑하는 미리정의된 세트의 규칙이 있다. 이들 규칙은 예컨대 베이스 클래스의 멤버의 타입 또는 이름에 기초한다. 개발자는 한 세트의 규칙에 따라서 이들 프로즌 슬롯에 대응하는 베이스 클래스 정의에 멤버를 부가함에 의해 어떤 프로즌 슬롯이 컴포넌트 타입을 가져야 하는지를 가리킨다. 바람직한 실시예에서, 개발자는 또한 프레임웍을 갖는 베이스 클래스를 등록하는 진술을 부가한다. 컴포넌트 기초 소프트웨어는 베이스 클래스의 부가 이후에 편집되고 실행된다. 소프트웨어가 초기 절차의 일부로서 실행될 때, 프레임웍은 베이스 클래스를 검출하며 도 1의 프로세스의 나머지를 통과하여 하나 이상의 컴포넌트 타입 및 이들에 기초하는 하나 이상의 컴포넌트를 생성한다.

프레임웍은 베이스 클래스를 조사하고 단계 101에서 모든 관련된 멤버를 발견한다. 이런 단계는 베이스 클래스의 인트로스펙션(introspection)에 의해 달성될 수 있다.

모든 타입의 슬롯(속성, 액션, 토픽)은 정의를 구성한다. 속성 슬롯의 정의는 속성 슬롯이 유지하는 데이터의 타입과 속성 슬롯의 이름을 특정한다. 액션 슬롯의 정의는 액션 슬롯의 이름과, 이런 액션을 실행하는 방법을 구현하는 코드를 포함한다. 유사하게, 토픽 슬롯의 정의는 토픽의 이름과 토픽을 구현하는 코드를 포함한다. 속성 슬롯은 물론 값을 포함하며, 액션 및 토픽 슬롯은 값을 갖지 못한다(그러나, 이들을 구현하는 방법은 컴포넌트 레벨에서 숨겨진 임의의 수의 변수들을 갖는다). 속성 슬롯은 값을 획득하고 설정하기 위하여 게터 및 세터 방법을 요구한다. 이들 게터 및 세터 방법은 속성 슬롯 정의의 일부이며, 베이스 클래스에서 초기에 정의된다.

단계 102에서, 속성 슬롯에 대응하는 베이스 클래스의 각각의 멤버는 게터 및 세터 방법에 대해 조사된다. 편리함을 위해, 게터 및 세터 방법은 속성 슬롯의 이름에 접두사 "get" 및 "set"을 붙이고 또한 이들 기능 각각을 구현하기 위해 표준 코드를 가지면서 명명된다.

프레임웍은 컴포넌트 타입 오브젝트를 생성한다(단계 103). 컴포넌트 타입 오브젝트의 목적은 컴포넌트 타입을 가리키는 것이다. 컴포넌트 타입 오브젝트는 하나 이상의 슬롯 정의를 저장 및 검색할 수 있는 데이터 구조를 포함한다. 이런 데이터 구조는 예컨대 어레이 또는 헤쉬테이블(hashtable)일 수 있다. 컴포넌트 타입 오브젝트는 또한 컴포넌트 타입의 이름인 이름을 포함한다. 이런 이름은 베이스 클래스의 이름으로부터 복사되거나, 예컨대 베이스 클래스에서 특정 필드를 이용하는 다른 방법에서의 개발자에 의해 식별된다.

단계 104에서, 베이스 클래스의 모든 슬롯 정의는 컴포넌트 오브젝트에 저장된다. 이들은 프로즌 슬롯 정의로 언급된다. 단계 105에서, 프레임웍은 단계 103에서 생성된 컴포넌트 타입 오브젝트와 연관된 슬롯맵 클래스를 발생시킨다. 슬롯맵 클래스는 컴포넌트 타입 오브젝트의 각각의 속성 슬롯에 대응하는 멤버를 정의한다. 슬롯맵 클래스는 또한 부가적인 동적 슬롯을 생성하기 위한 방법을 포함한다.

따라서 프로세스는 모든 기존의 베이스 클래스에 대해 단계 107에서 반복된다.

하나 이상의 반복 이후에, 컴포넌트 타입 오브젝트의 필요한 수는 단계 106에서 생성된다. 각각의 컴포넌트 타입 오브젝트에서는 각각의 슬롯맵 클래스, 프로즌 속성 슬롯에 대한 고유 값을 저장할 수 있는 인스탄스, 또한 부가될 수 있는 임의의 동적 슬롯이 있다.

따라서, 하나 이상의 컴포넌트 타입은 생성되나, 소프트웨어는, 이들 컴포넌트 타입의 인스탄스가 존재하지 않기 때문에, 컴포넌트 기초 기능이 여전히 결여된다. 단계 106에서, 하나 이상의 컴포넌트는 기존의 컴포넌트 타입 오브젝트로부터 발생된다. 프레임웍은 컴포넌트 레벨 기능을 제공하기 위하여 컴포넌트 인스탄스를 생성한다. 컴포넌트 인스탄스는 예컨대 데이터 파일 또는 사용자 입력을 기초로 생성된다. 예컨대, 데이터 파일은 개발자 또는 사용자에 의해 이미 설계된 컴포넌트 시스템을 효율적으로 포함할 수 있으며, 데이터 파일은 컴포넌트 인스탄스, 이들의 조직, 이들의 구성 속성, 및 링크를 통해 표시된 시스템내의 실행 플로우를 포함한다. 더욱이, 사용자는 그래픽 인터페이스를 이용할 수 있어 전단 브라우저 등을 통해 이들 사이에서 링크를 생성하고 컴포넌트를 예를들어 설명함에 의해 스크래치(scratch)로부터 이런 시스템을 생성한다.

바람직한 실시예에서, 프레임웍은 컴포넌트를 생성하는데 궁극적으로 책임이 있다. 임의의 컴포넌트 타입의 컴포넌트가 생성될 필요가 있을 때, 프레임웍은 기존의 컴포넌트 제네릭(generic) 클래스로부터 컴포넌트 인스탄스를 생성한다. 제네릭 클래스는 다른 컴포넌트와 통신하는데(또는 컴포넌트를 관리하는데) 사용되는하나 이상의 유틸리티 멤버멤버슬롯맵 또는 이에 대한 참조를 삽입하는데 적합한 필드를 포함한다. 프레임웍은 생성될 컴포넌트의 컴포넌트 타입과 연관된 컴포넌트 타입 오브젝트 및 이런 컴포넌트 타입과 연관된 슬롯맵 클래스를 식별한다. 그후, 슬롯맵 클래스로부터 슬롯맵 인스탄스를 생성한다. 프레임웍은 슬롯맵 인스탄스를 컴포넌트 인스탄스에 첨부하여, 슬롯맵은 컴포넌트에 효율적으로 포함되게 한다. 그 후, 컴포넌트 인스탄스로부터 컴포넌트 타입 오브젝트까지의 참조를 생성한다. 이런 참조, 통상 포인터는 인스탄스 타입 관계를 지정한다. 즉, 특정 컴포넌트 인스탄스가 컴포넌트 타입 오브젝트에 의해 설명되는 컴포넌트 타입에 속하는 것을 지정한다.

컴포넌트 타입 오브젝트가 속성 슬롯의 정의를 포함한다면, 프레임웍은 선택적으로 이들에 대한 값을 할당한다. 이들 값은 예컨대 데이터 파일 또는 사용자 입력으로부터 획득될 수 있다. 프레임웍이 속성 슬롯에 할당되는 값을 갖는다면, 프레임웍은 슬롯맵 오브젝트에서의 적당한 필드에서 값을 설정함에 의해 달성된다. 이는 속성 슬롯의 정의에서 세터 방법을 액세스하거나, 컴포넌트 또는 슬롯맵에 대한 세터 방법을 액세스하거나, 또는 슬롯 값을 직접 액세스함에 의해 달성될 수 있다. 슬롯 값이 제공되지 않는다면, 프레임웍은 디폴트 값을 할당하지 않고 아무 것도 할당하지 않는다.

대안적인 실시예에서, 슬롯맵 클래스는 각각의 컴포넌트 타입 오브젝트에 대해 생성되지 않으며, 오히려 각각의 컴포넌트는 제네릭 슬롯맵을 포함한다. 즉, 컴포넌트 오브젝트에 정의되는, 속성 슬롯의 속성 슬롯값에 대한 저장 위치를 제공하는 데이터 구조를 포함하며, 또한 동적 필드 정의 및 값을 저장할 수 있다. 이런 목적에 기여하는 데이터 구조는 공지되어 있으며, 어레이, 해쉬테이블 등일 수 있다.

프레임웍은 각각의 컴포넌트에 이름을 할당하며, 이 이름은 프레임웍에 의해 발생되거나 속성 슬롯 값이 있는 방식과 동일하게 얻어진다.

이런 방식으로, 프레임웍은 하나 이상의 컴포넌트 타입에 속하는 여러 컴포넌트를 생성한다. 도 2는 컴포넌트 타입 오브젝트(200)에 의해 정의되는 단일 컴포넌트 타입에 모두가 속하는 2개의 이런 컴포넌트들(211 및 212)을 예시한다. 컴포넌트 타입 오브젝트는 이름(202) 및 프로즌 슬롯(204)의 정의를 포함한다. 이런예시적인 예에서는 하나의 프로즌 액션 슬롯 시작(206), 하나의 프로즌 토픽 슬롯 경고(206) 및 하나의 프로즌 속성 슬롯 hrs_실행(210)이 있다. 슬롯 hrs_실행(210)은 정수를 포함하나, 다른 예에서 속성 슬롯은 보다 복잡한 데이터 또는 데이터 구조 또는 다른 데이터 타입을 포함할 수 있다. 슬롯(206 및 208)은 방법 및 토픽을 각각 실행하는데 요구되는 코드를 포함한다. 컴포넌트들(211 및 212)은 FirstFan 및 SecondFan으로 명명되면서, 각각은 슬롯맵(215 및 216)을 포함한다. 각각의 컴포넌트의 슬롯맵은 프로즌 속성 슬롯(217 및 218)에 대한 컴포넌트의 값을 포함한다.

바람직한 실시예의 현저한 특징에 따르면, 소프트웨어가 실행되는 동안, 동적 슬롯은 컴포넌트에 부가될 수 있다. 동적 슬롯은 프로즌 슬롯과 동일한 타입이다. 실행시간 동안 동적 슬롯의 부가는 사용자 또는 소프트웨어 그 자체에 의해행해진다. 구현에 의존하여, 동적 슬롯은 프레임웍에 대해 요청하거나 컴포넌트의 유틸리티 절차를 불러옴에 의해 부가된다. 사용되는 방식에 무관하게, 동적 슬롯은 슬롯맵에 저장됨에 의해 부가된다. 동적 슬롯은 항상 정의를 가지며, 또한 이것이 동적 슬롯이라면 값을 가진다. 정의는 슬롯맵에 저장되며, 적용가능하다면 값은 물론 이곳에 저장된다. 도 3은 2개의 슬롯이 컴포넌트(211)에 부가된 후 도 2의 컴포넌트 시스템을 도시한다. "Stop"로 명명된 동적 액션 슬롯(301)은 그 정의를 슬롯맵(215)에 부가함에 의해 부가된다. 또한, power_usage로 명명된 동적 속성 슬롯(302)은 그 정의(303) 및 값(304)를 슬롯맵에 부가함에 의해 부가된다.

컴포넌트(211)가 동일한 컴포넌트 타입 오브젝트(200)를 여전히 참조함에 유의해야 한다. 컴포넌트 타입 오브젝트는 동적 슬롯의 부가를 등록하도록 변경되지 않는다. 따라서, 컴포넌트 FirstFan(211)은 2개의 동적 슬롯의 부가 이후에 조차 여전히 동일한 컴포넌트 타입이 된다. 또한, 최종 컴포넌트(211 및 212)는 컴포넌트(211)가 2개 이상의 슬롯을 가진다는 사실에 무관하게 여전히 동일한 컴포넌트 타입이 된다. "순수한(pure)" 타입 인스탄스 모델로부터의 이런 출발은 성능 추론에 대해 행해진다: 각각의 변경된 컴포넌트에 대한 새로운 컴포넌트 타입의 생성은 시스템을 느리게 하며 너무 많은 부가적인 메모리를 요구한다. 컴포넌트는 동적 슬롯에 대한 슬롯맵을 조사하게 하며 외부 컴포넌트, 프레임웍 또는 소프트웨어의 다른 모듈에 이들의 정의를 제공하게 하는 유틸리티 방법을 소유한다. 이들 유틸리티 방법은 컴포넌트 타입 오브젝트가 동적 슬롯의 정의를 유지하지 못하기 때문에 필요하다. 동적 슬롯은 다른 컴포넌트, 프레임웍, 또는 슬롯맵 오브젝트의 프로즌 슬롯과 매우 동일한 방식으로 소프트웨어의 다른 모듈에 의해 액세스될 수 있다.

일단 생성되면, 동적 슬롯은 슬로맵으로부터 이들의 정의(및 임의의 값)를 제거함에 의해 이후에 삭제될 수 있다. 이는 예컨대 소프트웨어의 재편집에 자유롭게 도입되는, 즉 임의의 서비스 중단없는 새로운 제안된 특징 또는 기능의 테스트 결과로서 일어난다.

재편집없이 동적 슬롯을 도입하는 능력은 또한 사용자가 새로운 관계 및 프로그램 플로우에 영향을 미치는 연결성을 부가하게 한다. 이는 2개의 컴포넌트들간의 관계를 유지하는 슬롯인 "링크"를 통해 달성된다. 더욱 특히, 링크는 2개의 구별되는 컴포넌트들의 2개의 슬롯(모두 링크가 없는)간의 캐주얼 관계를 유지한다. 참조의 용이함을 위해, 이들 2개의 슬롯은 소스 및 타겟 슬롯으로 언급된다. 이들 슬롯을 유지하는 컴포넌트는 타겟 및 소스 컴포넌트로서 각각 언급된다. 링크에 의해 표현될 수 있는 많은 수의 가능한 캐주얼 관계가 있다. 바람직한 실시예에서 사용되는 링크의 타입은 이들이 링크되는 슬롯의 타입을 갖는 표 1에 리스트된다. 컴포넌트 레벨에서 실행 플로우의 개념이 속성 필드의 변경을 포함하기 때문에 표 1에 리스트된 모든 링크는 컴포넌트 시스템의 실행 플로우를 제어한다.

소스	타겟	세만틱스
속성	속성	소스 속성이 변경될 때, 타겟 속성을 설정
속성	액션	소스 속성이 변경될 때, 액션을 부름
액션	액션	소스 액션이 불러질 때, 타겟 액션을 부름
액션	토픽	소스 액션이 불러질 때, 타겟 토픽을 발화하다
토픽	액션	소스 토픽이 발화될 때, 액션을 부름
토픽	토픽	소스 토픽이 발화될 때, 타겟 토픽을 발화

사용자는 각종 컴포넌트의 각종 슬롯을 링킹함에 의해 실행의 플로우를 생성할 수 있다. 링크는 프로즌 또는 동적이다. 동적 링크는 소프트웨어가 실행중인 동안 컴포넌트 시스템의 실행 플로우가 변경되게 한다. 모든 것은 실행 플로우를 변경해야만 하며, 링크를 생성 또는 삭제한다. 동일한 링크의 생성 및 삭제를 회피하기 위하여, 바람직한 실시예는 링크가 활성화 및 비활성화되게 한다. 이는 삭제될 수 없는 프로즌 링크가 적당하게 고안된 동적 링크에 의해 여전히 비활성화될 수 있는 부가된 이점을 제공한다. 비활성화된 링크는 링크로서 기능하지 못하나, 타겟 컴포넌트에 존재하며, 연속적으로 활성화될 수 있다.

링크는 슬롯의 타입중 하나로서 구현된다. 바람직한 실시예에서, 링크는 타겟 컴포넌트, 즉 타겟 슬롯을 유지하는 컴포넌트에 포함된다. 링크는 바람직하게 다음의 슬롯을 포함한다: 참조 또는 소스 컴포넌트의 이름을 유지하는 소스 컴포넌트 필드, 소스 슬롯의 이름을 유지하는 소스 필드, 타겟 슬롯의 이름을 유지하는 타겟 필드, 및 활성화 또는 비활성화 여부를 나타내는 "활성화된" 플래그.

링크는 또한 예컨대, 활성 및 비활성 방법 또는 소스 필드, 소스 컴포넌트, 및/또는 타겟 필드를 변경하는 방법과 같이, 링크를 조작하는데 유용한 방법을 포함한다. 타겟 컴포넌트에 대한 참조가, 링크가 타겟 컴포넌트 - 타겟 컴포넌트는 링크의 배치에 의해 간접적으로 참조된다 -에 이미 포함되기 때문에, 이런 배열에서 회피됨에 유의해야 한다.

바람직한 실시예에서, 링크가 활성화될 때, 이들은 소스 컴포넌트에서 놉(knob)을 생성한다. 놉은 소스 컴포넌트의 슬롯맵에 저장되는 링크와 유사한 데이터 구조이다. 놉은 그 슬롯으로부터 타겟 컴포넌트의 슬롯으로 이벤트를 전파해야만 하는 소스 컴포넌트를 가리킨다. 놉은 링크와 유사한 데이터 필드를 가지나, 소스 컴포넌트 대신에 타겟 컴포넌트의 참조 또는 이름을 포함한다. 놉은 활성화된 플래그를 포함하지 않고, 오히려 링크가 비활성화될 때 놉은 단순하게 제거된다.

도 4는 동적 링크(401)가 부가된 도 3의 컴포넌트를 도시한다. 링크는 활성화되어, 대응하는 놉(402)이 생성되게 한다. 타겟 및 소스 슬롯이 속성이기 때문에, 이런 링크의 효과는 퍼스트 휀(FirstFan)의 hrs_ 실행의 값이 변경되는 경우에 세컨드 휀(SecondFan)의 hrs_실행의 값을 제1 팬의 hrs_실행의 새로운 값으로 변경하는 것이다. 달리 말하자면, 이런 링크는 값(217)이 변경될 때 값(218)이 값(217)을 추종하게 된다. 링크는 프로즌 또는 동적 슬롯에 링크되는 여부에 무관하게(동적 슬롯이 관련되는 경우 비록 일부 성능 패널티가 존재한다 할지라도) 동일한 방식으로 행위한다.

도 5A는 상세한 내용은 생략된 도 4의 컴포넌트 시스템의 요약도를 도시한다. 이는 컴포넌트 레벨로부터 본 링크의 기능성을 도시한다. 이하 링크(401)는 컴포넌트(211)에서의 슬롯 대신에 소스 슬롯으로부터 타겟 슬롯으로의 화살표로 표현된다. 그럼에도 불구하고 링크 슬롯은 컴포넌트(211)에 존재한다.

도 5A는 컴포넌트 모델의 이점들중 하나를 나타낸다. 컴포넌트 모듈은 복잡한 동적 시스템이 비교적 단순한 방식으로 요약되며 도시되게 한다. 사용자는 컴포넌트 시스템의 하나 이상의 컴포넌트가 위짓(widget) 또는 다이어그램으로서 가시적으로 표현되는 비주얼 인터페이스를 구비한다. 사실, 가시적 표현은 도 5A에 도시된 것과 유사하게 렌더링(rendering)된다. 컴포넌트는 속성 슬롯에서 그 자신의 표현을 저장할 수 있으며, 또는 이들 표현은 그래픽 모듈에 의해 조작될 수 있다. 이하 설명되는 컴포넌트 모델과 결합하여 동작할 수 있는 바람직한 비주얼 인터페이스에 대한 보다 상세한 내용은 이하 참고로 합체되는 미국특허출원(번호는 추후 배정, attorney docket No. 3929/1k294US2, entitled "real-time data interface and method for browsers and the like")을 참조해라.

컴포넌트가 그래픽 인터페이스를 통해 사용자에게 표현될 때, 각종 관련 슬롯 및 이들 컴포넌트의 값이 또한 도시된다. 사용자는 값을 변경할 수 있거나, 또는 각종 슬롯의 클릭 선택과 링크를 부가하기 위해 컴포넌트들간의 드래깅(dragging) 링크에 의해 이런 인터페이스를 통해 컴포넌트의 방법을 실행할 수 있다.

더욱이, 사용자는 링크, 슬롯 및 컴포넌트를 스크린상에 가시적으로 표현하는 것을 조절함에 의해 새로운 컴포넌트를 부가하며, 동적 속성을 부가 또는 제거하고, 동적 링크를 부가 및 제거하며, 링크를 활성화 및 비활성화할 수 있게 된다. 따라서, 사용자는 컴포넌트 기초 시스템을 가시적으로 재프로그래밍한다.

도 5B는 링크(401)가 제거된 후 도 5A에 도시된 컴포넌트 시스템의 개략도이다. 링크의 제거는 일점쇄선 401'으로 표시된다. 제거는 컴포넌트(211)로부터 동적 링크 슬롯(411)을 제거함에 의해 달성된다. 임의의 다른 동적 슬롯은 유사하게 제거된다.

바람직한 실시예의 이점중 하나는 프로즌 슬롯의 효율 및 속도를 동적 슬롯의 유연성에 결합하는데 있다. 임의의 시간에서, 동적 슬롯은 매우 비효율적인 것으로 판명된다. 그럼에도 불구하고, 바람직한 실시예는 최적의 구성을 찾기 위하여 동적 슬롯을 이용함에 의해 컴포넌트 시스템을 빠르게 변경 및 테스트하는데 사용된다. 최적 구성이 찾아질 때, 재편집은 모든 동적 슬롯을 프로즌 슬롯으로 변환하기 위해 행해진다. 재편집 후, 시스템은 매우 좋은 성능을 갖고 그 최적 구성을 보유한다.

도 6은 도 3에 도시된 시스템의 컴포넌트(211)가 최적화되는 방법을 예시한다. 동적 슬롯을 프로즌 슬롯으로 편집하는 경우, 원 컴포넌트 타입의 모든 컴포넌트가 동일한 동적 슬롯을 갖지 않는다면 원 컴포넌트 타입 또는 새로운 컴포넌트 타입으로의 변경을 초래한다. 동적 슬롯(301, 302)은 슬롯맵(215)으로부터 그 정의를 제거하고 컴포넌트 타입 클래스(200)의 프로즌 슬롯 정의를 인수화(augmenting)함에 의해 프로즌 슬롯으로 변환된다. 속성 슬롯(302)의 값(304)은 슬롯맵(215)에 유지되나, 지금은 동일한 컴포넌트 타입의 모든 컴포넌트에 대해 공통인 프로즌 슬롯 정의와 연관된다. 2개의 값(217 및 304)은 정의(210 및 303)로부터 리스트되거나 유도되는 오프셋에 의해 이 각각의 정의(210 및 303)로 쌍을 이룬다.

도 7은 컴포넌트를 컴포넌트 시스템으로 계층적으로 조직하는 바람직한 방식을 예시한다. 이미 설명된 바와 같이, 컴포넌트는 속성 슬롯으로서 다른 컴포넌트를 포함할 수 있다. 이는 속성 슬롯으로서 다른 컴포넌트에 대한 참조를 포함함에의해 달성된다. 대안적인 실시예에서, 소유를 지정하는 링크가 참조 대신에 사용된다.

도 7에 도시된 바와 같이 다른 컴포넌트를 포함하며 트리 구조에서 시스템의 컴포넌트를 조직화하기 위하여 컴포넌트의 능력을 활용하는 것이 바람직하다. 이들 컴포넌트 타입 오브젝트(706, 707, 708 및 709)는 컴포넌트 타입 A, B, C 및 D를 각각 설명한다. 컴포넌트(701)는 컴포넌트 타입 A로 이루어지며, 컴포넌트(702 및 703)은 컴포넌트 타입 B로, 컴포넌트(704)는 컴포넌트 타입 C로, 컴포넌트(705)는 컴포넌트 타입 D로 이루어진다. 컴포넌트(702, 703 및 704)는 컴포넌트(701)의 슬롯에 모두 포함되며, 이런 포함 관계는 컴포넌트(701)의 슬롯(710)에서 참조에 의해 정의된다. 컴포넌트(704)는 컴포넌트(705)를 더 포함한다. 또한 굵은 화살표로 예시되는 것으로, 소스로서의 컴포넌트(705)의 슬롯(711) 및 목적지로서 컴포넌트(703)의 슬롯(712)을 갖는 실행 플로우 링크(713)가 있다. 다른 컴포넌트를 포함하는 컴포넌트는 부모로서 언급된다. 다른 컴포넌트에 포함되는 컴포넌트는 자식(children)으로 언급된다. 보다 복잡한 시스템은 유사한 구조에서 조직된다. 바람직한 실시예에서, 시스템의 모든 컴포넌트는 단일 트리로 조직된다. 이는 루트 컴포넌트로 언급되는 하나의 부모 컴포넌트가 있으며, 루트 컴포넌트에 대한 그 혈통을 추적할 수 있는 임의의 다른 컴포넌트 및 하나 이상의 루트 컴포넌트에 포함되지 않는다는 것을 의미한다.

도 7에서, 루트 컴포넌트는 컴포넌트(701)이다. 이런 조직은 모든 컴포넌트가 앤세스터 이름의 순차적인 리스팅을 포함하고, 루트로부터 시작하며 컴포넌트명에서 종료하는 스트링을 통해 고유하게 식별된다는 점에서 부가적인 이점을 생성한다. 이런 특징은 다른 판매자로부터의 새로운 컴포넌트가 시스템에 연속해서 부가되는 복잡한 컴포넌트 시스템에서 컴포넌트의 고유 식별을 보장하는 도움을 주는데 사용될 수 있다. 식별은 컴포넌트의 필드에 고유한 식별을 유사하게 제공하기 위하여 필드명으로 확장될 수 있다.

비주얼 인터페이스가 컴포넌트 모델의 중요한 이점이기 때문에, 본 발명은 비주얼 인터페이스를 제공하기 위한 시스템을 또한 포함한다. 시스템은 특히 비주얼 오브젝트 또는 위짓에 기초하기 때문에 컴포넌트 모델에 인터페이스를 제공하는데 유용하며, 각각의 이런 위짓은 컴포넌트를 가시화할 수 있다. 다른 유용한 특징은 시스템이 비교적 낮은 자원 사용에 커다란 유연성을 결합하는데 있다.

가시화 시스템은 표준화된 파일 포맷을 통해 제3자 컨텐츠를 표시하는데 사용되는 유명 소프트웨어, 예컨대 HTML 브라우저와 호환가능하게 설계된다. 바람직한 실시예에서, 본 발명은 HTML 파일내에서 자바 어플릿으로서 구현된다. 자바 어플릿은 엔진으로 언급된다. 도 8은 가시화 시스템의 동작을 도시하는 플로우 챠트이다. 사용자는 단계 801에서 HTML 브라우저상에서 엔진으로 HTML 브라우저를 로딩한다. 단계 802에서, HTML 브라우저는 엔진을 실행한다. 단계 803에서, 엔진은 구성 파일을 요청한다. 구성 파일은 컴퓨터 네트워크를 통해 또는 사용자의 컴퓨터로부터 요청된다. 바람직한 실시예에서, 구성 파일은 XML 파일이다. 구성 파일은 가시적 프리젠테이션의 레이아웃을 포함하며, 하나 이상의 위짓에 대한 참조와,이들 위짓에 대한 배치 및/또는 사이징 정보를 포함한다.

위짓은 비주얼 오브젝트이다. 위짓의 예는 컴포넌트, 물리적 디바이스, 그래프, 파이 챠트 및 테이블의 표현이다. 위짓은 많은 수의 다른 방식에서 정보를 애니메이트 또는 제공할 수 있다. 위짓은 또한 선택적으로 사용자와 대화하는 능력을 가진다.

구성 파일에서 참조되는 각 위짓과 연관된 일부 실행가능한 코드가 있다. 이런 코드는 확장자(extension)로 언급된다. 확장자는 사용자 컴퓨터 또는 컴퓨터 네트워크에 의해 이에 연결된 다른 컴퓨터상에 위치한다. 확장자는 구성 파일에 포함된 참조에 의해 위치될 수 있다. 엔진은 구성 파일을 분석하며 확장자를 위치시킨다. 엔진은 그후 확장자를 로딩하며, 필요하다면 컴퓨터 네트워크를 통해 이들을 다운로딩한다(단계 804). 엔진은 그후 모든 확장자를 병렬로 실행한다. 확장자가 실행될 때, 이들은 엔진의 도움으로 사용자 인터페이스를 표시한다. 각각의 확장자는 연관된 위짓을 표시한다. 엔진은 구성 파일에 설명되는 전반적인 레이아웃을 표시하며, 표시된 위짓을 조작하여 구성 파일에 따라서 이들을 사이징 및 배치한다. 확장자는 선택적으로 다른 소프트웨어 모듈과 통신하며, 이들 통신에 따라서 연관된 위짓을 변경/업데이트한다.

예시적인 실시예에서, 위짓은 컴포넌트의 그래픽 표현이며, 위짓과 연관된 확장자는 컴퓨터 네트워크를 통해 컴포넌트와 통신한다. 확장자는 또한 사용자에 의해 커맨드에 수락 및 응답함에 의해 사용자와 선택적으로 대화한다. 확장자는 또한 사용자와의 대화에 기초하여 다른 소프트웨어 컴포넌트, 예컨대 컴포넌트로부터 정보를 전송 또는 수신할 수 있다. 위짓은 따라서 확장자의 소프트웨어 코드, 다른 소프트웨어 모듈과의 통신 및/또는 사용자와의 대화에 기초하여 연속적으로 업데이트한다. 확장자는 더욱이 사용자로부터 다른 소프트웨어 모듈로 수신된 제어 신호를 전송할 수 있다.

예컨대, 위짓은 서모스탯(thermostat) 컴포넌트에 의해 제어되는 서모스탯을 나타낸다. 서모스탯 위짓에 대응하는 확장자는 네트워크를 통한 업데이트된 온도 판독을 요청한다. 서모스탯 컴포넌트는 응답한다. 확장자는 온도를 업데이트한다. 사용자는 위짓과 대화한다. 예컨대, 위짓상에서 클릭킹에 의해 사용자는 화씨가 아닌 섭씨 온도를 보고자 하는 욕구를 표현한다. 위짓을 요청하고 업데이트하는 확장자가 수신된다. 사용자는 또한 위짓을 통해 실제 서모스탯에 커맨드를 전송할 수 있다. 예컨대, 사용자가 서모스탯을 스위치 오프하거나 전력 절약 모드에 두고자 한다면, 위짓은 서모스탯 컴포넌트에 커맨드를 전송한다.

비주얼 인터페이스 시스템의 대안적 실시예는 네트워크 통신이 확장자에 의해 종종 활용될 때 보다 높은 효율을 보장한다. 병렬로 동작하는 다수의 확장자에 의한 다수의 네트워크 통신이 종종 성능 문제를 야기하기 때문에, 대안적인 실시예에서 확장자는 네트워크 통신을 초기화하지 않고 오히려 엔진에 요청을 전송한다. 미리정의된 시간 주기를 통해 네트워크 통신 요청을 집합화하여 이들을 큰 사이즈의 번들(bundle)로 결합하고자 하며, 이들을 네트워크를 통해 전송하여, 네트워크 효율을 개선시킨다. 동일한 컴퓨터로 나오는 통신만이 번들된다. 또한, 통신을 비번들(unbundle)화할 수 있는 수신단에서는 소프트웨어 모듈이 있어야만 한다.엔진은 또한 임의의 소프트웨어 모듈로부터 번들을 수신하며, 이 번들은 하나 이상의 확장자로 전송된 통신을 포함하고, 이들을 단일 통신으로 비번들화하며 이들 단일 통신을 어드레싱되는 확장자에 전송한다. 본 실시예는 많은 수의 확장자가 동일한 소프트웨어 모듈과 통신할 때 아주 효율적이다.

비주얼 인터페이스 시스템은 상세함과 명확함을 위해 언어, 포맷, 및 프로토콜, 예컨대 HTML, 자바, XML을 이용하여 설명된다. 비주얼 인터페이스 시스템은 이들 언어, 포맷 및 프로토콜로 제한되지 않는다. 비주얼 인터페이스 시스템은 임베디드 어플리케이션이 허용되는 임의의 언어로 동작하도록 구성된다. 전용 데이터 포맷을 포함하는 임의의 데이터 파일 포맷은 XML 대신에 사용된다.

다시, 전술한 컴포넌트 모델과 결합하여 동작할 수 있는 바람직한 비주얼 인터페이스에 대한 추가적인 상세는 전술한 미국특허출원("Real-Time Data Interface And Method For Browsers And The Like")을 참조하길 바란다.

소프트웨어 프로그램 모두가 컴포넌트 모델에 구현될 필요는 없다. 컴포넌트 기초 기능은 전통적인 오브젝트 지향 코드보다 느리고 크기가 큰 경향이 있다. 따라서, 바람직한 실시예에서, 동적으로 수정될 필요가 있는 코드의 일부만 또는 컴포넌트 모델의 다른 특징이 컴포넌트 모델에 구현될 수 있다. 그러나, 컴포넌트 모델에 기술적으로 구현되지 않는 코드는 컴포넌트에 여전히 인캡슐레이팅되어 컴포넌트를 다른 컴포넌트로 보이게 한다.

본 명세서에서 설명된 컴퓨터는 임의의 컴퓨팅 디바이스일 수 있다. 컴퓨터 네트워크는 무선 네트워크를 포함한다.

본 발명은 특정 실시예와 결합하여 설명되고 있지만, 이하 첨부된 청구범위에 의한 제한없이 정의되며 요소 및 방법 단계의 비실질적인 변동을 포함한다.

Claims

동일한 컴포넌트 타입의 적어도 하나의 컴포넌트를 포함하며, 기계상에서 실행을 위한 소프트웨어 프로그램- 상기 컴포넌트 타입은 속성 슬롯 정의인 하나 이상의 슬롯 정의중 적어도 하나를 포함하는 베이스 클래스로부터 정의됨-에서,

상기 베이스 클래스에서 모든 속성 슬롯 정의를 식별하는 단계와,

상기 베이스 클래스에 각각 식별된 속성 슬롯 정의에 대한 게터 및 세터(getter and setter) 방법을 위치시키는 단계와,

슬롯 정의를 저장하도록 구성되는 컴포넌트 타입 오브젝트를 발생시키는 단계와,

상기 식별 단계에서 식별된 상기 속성 슬롯 정의를 상기 컴포넌트 타입 오브젝트에 저장하는 단계와,

각각이 슬롯맵 및 컴포넌트 타입 오브젝트에 대한 참조를 구비하는 하나 이상의 컴포넌트를 발생시키는 단계 - 상기 각각의 슬롯맵은 상기 컴포넌트 타입 오브젝트에 저장된 각 속성 슬롯 정의의 값에 대한 저장 위치를 포함함 -와,

상기 속성 슬롯값을 저장 위치로 삽입함에 의해 속성 슬롯값을 상기 하나 이상의 컴포넌트중 특정한 하나의 슬롯맵에 설정하는 단계 - 상기 속성 슬롯값은 상기 컴포넌트 타입 오브젝트에서 상기 속성 슬롯 정의와 연관됨 -

을 포함하는 단계에 의해 실행시간 동안 컴포넌트가 발생되는 방법.
제1항에 있어서,

정의가 상기 식별 단계에서 식별되는 각 속성 슬롯의 값에 대한 하나 이상의 저장 위치를 정의하는 슬롯맵 클래스를 발생시키는 단계를 더 포함하며,

상기 하나 이상의 컴포넌트의 발생 단계에서 각 슬롯맵은 상기 슬롯맵 클래스의 인스탄스인 방법.
제1항에 있어서,

상기 베이스 클래스의 정의들중 적어도 하나는 액션 슬롯 정의이며,

상기 베이스 클래스에서 하나 이상의 액션 슬롯 정의를 식별하는 단계와,

상기 하나 이상의 액션 슬롯 정의를 상기 컴포넌트 타입 오브젝트에 저장하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 베이스 클래스의 정의들중 적어도 하나는 토픽 슬롯 정의이며,

상기 베이스 클래스에서 하나 이상의 토픽 슬롯 정의를 식별하는 단계와,

상기 하나 이상의 토픽 슬롯 정의를 상기 컴포넌트 타입 오브젝트에 저장하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 소프트웨어 프로그램의 실행동안에, 상기 하나 이상의 컴포넌트들중에서 제1 컴포넌트의 슬롯맵에 동적 슬롯을 부가하는 단계와,

이와 동시에 상기 컴포넌트 타입 오브젝트가 임의의 편집 단계 없이 상기 부가 단계를 변경되지 않게 내버려두는 단계를 더 포함하는 방법.
제5항에 있어서,

상기 동적 슬롯은 속성 슬롯이며,

상기 부가 단계는,

동적 속성 슬롯 정의를 상기 제1 컴포넌트의 슬롯맵에 부가하는 단계와,

동적 속성 슬롯값을 상기 제1 컴포넌트의 슬롯맵에 부가하는 단계를 포함하는 방법.
제5항에 있어서,

상기 동적 슬롯은 액션 슬롯이며,

상기 부가 단계는 동적 액션 슬롯 정의를 상기 제1 컴포넌트의 슬롯맵에 부가하는 단계를 포함하는 방법.
제5항에 있어서,

상기 동적 슬롯은 토픽 슬롯이며,

상기 부가 단계는 동적 토픽 슬롯 정의를 상기 제1 컴포넌트의 슬롯맵에 부가하는 단계를 포함하는 방법.
제5항에 있어서,

상기 소프트웨어 프로그램 실행 동안에, 상기 제1 컴포넌트로부터 상기 동적 슬롯을 제거하는 단계 - 상기 제거 단계는 임의의 편집 단계가 없슴 -를 더 포함하는 방법.
제6항에 있어서,

시간 주기 동안 상기 소프트웨어 프로그램을 실행하는 단계와,

상기 제1 컴포넌트로부터 상기 동적 속성 슬롯을 제거하는 단계와,

상기 동적 속성 슬롯 정의와 동일한 프로즌 속성 슬롯 정의를 상기 컴포넌트 타입 오브젝트에 부가하는 단계와,

상기 동적 속성 슬롯 값과 동일한 프로즌 속성 슬롯값을 상기 제1 오브젝트의 슬롯맵에 부가하는 단계를 더 포함하며,

상기 프로즌 속성 슬롯 정의 및 프로즌 속성 슬롯 값을 부가하는 단계는 상기 소프트웨어 프로그램을 적어도 부분적으로 편집함에 의해 수행되는 방법.
제7항에 있어서,

시간 주기 동안 상기 소프트웨어 프로그램을 실행하는 단계와,

상기 제1 컴포넌트로부터 상기 동적 액션 슬롯을 제거하는 단계와,

상기 동적 액션 슬롯 정의와 동일한 프로즌 액션 슬롯 정의를 상기 컴포넌트타입 오브젝트에 부가하는 단계를 더 포함하며,

상기 프로즌 액션 슬롯 정의를 부가하는 단계는 상기 소프트웨어 프로그램을 적어도 부분적으로 편집함에 의해 수행되는 방법.
제8항에 있어서,

시간 주기 동안 상기 소프트웨어 프로그램을 실행하는 단계와,

상기 제1 컴포넌트로부터 상기 동적 토픽 슬롯을 제거하는 단계와,

상기 동적 토픽 슬롯 정의와 동일한 프로즌 토픽 슬롯 정의를 상기 컴포넌트 타입 오브젝트에 부가하는 단계를 더 포함하며,

상기 프로즌 토픽 슬롯 정의를 부가하는 단계는 상기 소프트웨어 프로그램을 적어도 부분적으로 편집함에 의해 수행되는 방법.
제5항에 있어서,

상기 소프트웨어 프로그램의 그래픽 표현을 표시하는 단계와,

사용자로 하여금 상기 그래픽 표현을 조절하게 하는 단계를 더 포함하며,

상기 부가 단계는 상기 그래픽 표현의 사용자 조절에 응답하여 수행되는 방법.
제13항에 있어서,

상기 그래픽 표현의 사용자 조절에 응답하여 상기 동적 슬롯을 제거하는 단계를 더포함하는 방법.
제5항에 있어서,

복수의 컴포넌트가 코드를 정의하기 위해 발생되며, 각각의 컴포넌트는 각각의 슬롯맵 및 동일한 컴포넌트 타입 오브젝트에 대한 참조를 구비하고, 상기 동적 슬롯은,

상기 2개 이상의 컴포넌트들중에서 제2 컴포넌트에서의 소스 슬롯으로부터 상기 제1 컴포넌트에서의 타겟 슬롯으로의 코드 실행 플로우를 정의하는 링크인 방법.
제15항에 있어서,

상기 링크의 그래픽 표현을 포함하는 상기 소프트웨어 프로그램의 그래픽 표현을 표시하는 단계와,

사용자로 하여금 상기 링크의 그래픽 표현을 조작하게 하는 단계를 더 포함하며,

상기 부가 단계는 상기 링크의 그래픽 표현의 사용자 조작에 응답하여 행해지는 방법.
제15항에 있어서,

상기 소스 슬롯은 속성 슬롯이고, 상기 타겟 슬롯은 속성슬롯이며, 상기 방법은 상기 타겟 슬롯의 값이 상기 소스 슬롯의 임의의 값 변화로 변화되도록 코드를 실행하는 추가 단계를 포함하는 방법.
제15항에 있어서,

상기 소스 슬롯은 속성 슬롯이고, 상기 타겟 슬롯은 액션 슬롯이며,

상기 방법은 상기 타겟 슬롯이 상기 소스 슬롯의 값 변화에 응답하여 불러지도록 코드를 실행하는 추가 단계를 포함하는 방법.
제15항에 있어서,

상기 소스 슬롯은 토픽 슬롯이고, 상기 타겟 슬롯은 액션 슬롯이며,

상기 방법은 상기 타겟 슬롯이 상기 소스 슬롯 발화에 응답하여 불러지도록 코드를 실행하는 추가 단계를 포함하는 방법.
제15항에 있어서,

상기 소스 슬롯은 토픽 슬롯이고, 상기 타겟 슬롯은 토픽 슬롯이며,

상기 방법은 상기 타겟 슬롯이 상기 소스 슬롯 발화에 응답하여 발화되도록 코드를 실행하는 추가 단계를 포함하는 방법.
제15항에 있어서,

상기 소스 슬롯은 액션 슬롯이고, 상기 타겟 슬롯은 액션 슬롯이며,

상기 방법은 상기 타겟 슬롯이 상기 소스 슬롯의 불러짐에 응답하여 불러지도록 코드를 실행하는 추가 단계를 포함하는 방법.
제15항에 있어서,

상기 소스 슬롯은 액션 슬롯이고, 상기 타겟 슬롯은 토픽 슬롯이며,

상기 방법은 상기 타겟 슬롯이 상기 소스 슬롯의 부름에 응답하여 발화되도록 코드를 실행하는 추가 단계를 포함하는 방법.
제15항에 있어서, 상기 링크는,

상기 제2 컴포넌트에 대한 참조와,

상기 소스 슬롯의 슬롯명과,

상기 타겟 슬롯의 슬롯명을 포함하는 방법.
컴포넌트 기초 소프트웨어 시스템에서 고유 이름을 컴포넌트에 자동적으로 지정하는 방법에 있어서,

어떠한 부모도 갖지 않는 루트 컴포넌트를 생성하는 단계와,

상기 루트 컴포넌트내에 하나 이상의 비루트 컴포넌트를 배치하는 단계와,

다른 비루트 컴포넌트내에 하나 이상의 비루트 컴포넌트를 배치하여 상기 컴포넌트들이 하나의 트리구조를 형성하고 각각의 비루트 컴포넌트가 하나의 부모를 갖게 하는 단계와,

상기 비루트 컴포넌트들중에서 제1 컴포넌트에 상기 컴포넌트의 앤세스터의 이름 및 상기 컴포넌트의 이름의 순차적인 리스트를 포함하는 고유 식별 스트링을 할당하는 단계를 포함하는 방법.
제24항에 있어서,

상기 제1 컴포넌트는 슬롯을 포함하며,

상기 슬롯에 식별을 제공하는 단계를 더 포함하는 방법.
제25항에 있어서, 상기 슬롯은 동적 슬롯인 방법.