KR940002343B1 - 인터페이스 및 아이템 표시 방법 - Google Patents

Abstract

내용 없음.

Description

인터페이스 및 아이템 표시 방법

제1a도는 다이얼로그(dialogue)로부터 작업의 실행에 대한 상부 메뉴로부터의 작업 과정을 도시한 도면.

제1b도는 다수의 그래픽 라이브러리(library)에 의해 사용자에게 디스플레이하기 위해 논리 프레임 표시를 동적으로 생성하는 오브젝트(object) 데이타 베이스로 부터 인터페이스 오브젝트를 검색하는 본 발명의 인터페이스 툴의 블럭 다이어그램.

제2도는 인터페이스 메뉴 옵션 오브젝트의 구조를 도시한 도면.

제3도는 인터페이스 다이얼로그 명령 옵션 오브젝트의 구조를 도시한 도면.

제4도는 인터페이스 다이얼로그 헤더 오브젝터의 구조를 도시한 도면.

제5a도는 시스템 자원에 대해 시스템 관리 작업을 수행하는데 있어 인터페이스 오브젝트의 사용을 도시한 도면.

제5b도는 다른 시스템 자원에 대해 시스템 관리 작업을 수행하는데 있어 인터페이스 오브젝트이 사용을 도시한 도면.

제6도는 인터페이스 네임 선택 오브젝트의 구조를 도시한 도면.

제7도는 인터페이스 오브젝트를 통한 동적 트랜스버설을 예증한 도면.

제8a 내지 c도는 시스템의 도폴로지를 통하여 인터페이스를 툴의 트랜스버설(transversal)을 도시한 흐름도.

제9a도는 계층에서 빠른 경로를 생성시키기 위해 다른 메뉴로 위치 정하는 에일리어스 메뉴 오브젝트(alias menu object)를 예증한 도면.

제9b도는 계층에서 빠른 경로를 생성시키기 위해 네임 선택기(name selector)로 위치 정하는 에일리어스 메뉴 오브젝트를 예증한 도면.

제9c도는 계층에서 빠른 경로를 생성시키기 위한 다이얼로그 위치 정하는 에일리어스 메뉴 오브젝트를 예증한 도면.

제10a도는 시스템 관리 메뉴 옵션 인터페이스 오브젝트의 계층을 예증한 도면.

제10b도는 시스템 관리 인터페이스 오브젝트의 계층내의 장치 메뉴 옵션 오브젝트의 계층을 예증한 도면.

제10c도는 제10a와 b도에 도시된 계층의 또다른 분해도.

* 도면의 주요부분에 대한 부호의 설명

200 : 메뉴 오브젝트 클래스 300 : 다이얼로그 오브젝트 클래스

400 : 다이얼로그 헤드 오브젝트 클래스 600 : 네임 선택 오브젝트 클래스

관련 출원에 대한 상호 참조 :

본 명세서에서 참조로 한 것은 R.J.Archon의 이름으로 1989년 5월 15일에 출원된 발명의 명칭이 "An Initial Program Load(IPL) Based On An Object Abstraction For A Data Processing System"인 07/960,180(IBM Internal docket number AT9-89-035).

R.A.Fabbio의 이름으로 1989년 5월 15일에 출원된 발명의 명칭이 "An Open System Management Architecture For A Data Processing System"인 07/871,615(IBM internal docket number AT9-89-031).

R.A.Fabbio의 이름으로 1989년 5월 15일에 출원된 발명의 명칭이 "Access Control Policies For An Object Oriented Database"인 07/808,060(IBM internal docket number AT9-89-038).

본 특허 서류의 명세서 및 도면의 일부에는 저작권 보호를 받는 자료를 포함하고 있다. 저작권 소유자는 특허청의과 보관 서류 또는 공보에서 발췌한 것으로서 특허 명세서 도면 또는 기타 특허 서류를 팩시밀리 복제하는 것은 허락하지만 그외의 복제에 대해서는 저작권자의 승인이 별도로 필요하다.

[발명의 배경]

[발명의 분야]

본 발명은 데이타 처리 시스템을 위한 사용자 인터페이스(user interface)를 구현하는 것에 관한 것으로서, 특히 오브젝트(boject) 데이타 베이스에서 오브젝트로서 인터페이스의 모든 엘리멘트(all elements of the interface)를 표시하는 것에 관한 것이다.

[관련기술의 설명]

시스템 관리란 데이타 처리 시스템 환경에서 사용자에게 노출된 구성 가능한 영역(configurable domain)을 관리하는데 사용되는 퍼실리티 또는 툴(facilities or tools)을 말한다. 영역이라는 말은 하나의 시스템내의 장치들 사용자들 분산 화일 시스템(distributed file system), 서브 시스템들 및 네트워크들을 의미하며, 여기서 말하는 시스템은 단일 기계(single machine)의 범위를 초과하는 확장된 개념으로 사용될 수 있다. 각각의 구성 가능한 영역들을 위한 시스템 관리 퍼실리티에는 콤퍼넌트가 시스템으로부터 추가되거나 삭제될때 시스템 콤포넌트를 구성하는 수단(means to configure), 다른 데이타 처리 시스템의 네트워크 내에 데이타 처리 시스템을 구성하는 수단, 시스템 구성 또느 시스템 콤퍼넌트에서의 고장을 진단하는 수단 등이 포함될 수 있다. 전통적으로, 시스템 관리는 오퍼레이팅 시스템 환경(operating system environment)의 보조 엘리멘트로서 취급되며, 시스템의 각종 양상을 관리하고 모니터하는 능력을 매니저/사용자에게 집합적으로 제공하는 한 부류의 디스조인트 툴(disjoint tools)로 구성된다.

사용자가 데이타 처리 시스템내에서 타스크(task)를 수행하기 위해서, 사용자와 데이타 처리 시스템 사이에는 대화(interaction)가 있어야 한다. 처리 시스템이 이해하는 언어로 처리 시스템이 필요로 하는 데이타를 입력시키지 않고 사용자가 이해하기 쉽고 조작하기 쉬운 데이타를 사용자가 데이타 처리 시스템에 입력시키고 다시 처리된 정보를 수신하려면 사용자 인터페이스가 필요하다. 이러한 사용자 인터페이스는 다종 다양하게 개발되어 있다.

이러한 사용자 인터페이스로서 몇몇의 다이얼로그 매니저(dialogue manager)라고 하는 것은 태그 언어(tag languag)에 기초를 두고 있다. 태그 언어는 특정한 비 프로그래밍 언어를 인식하는 스크린을 작성할 수 있는 개발자를 필요로 한다. 태그 언어는 전체 스크린상에 스크린 단위로 스크린 배치를 기술한다. 스크린 배치를 기술한다고 하는 것은 스크린상에 나타나는 스트링(string)을 기술하는 것과, 스크린내의 필드에 대하여 허용된 값을 기술하는 것과, 그리고 사용자에 의해서 취해질 액션을 기술하는 것을 포함한다. 또한, 하나의 완전한 스크린에 대해 기술된 태그 언어는 계속해서 나타나게 될 다음의 전체 스크린에 대한 기술도 포함한다.

시스템 관리 작업을 수행하기 위해 사용된 사용자 인터페이스는 시스템 관리 툴의 기능에 따라 그들을 그룹화하고, 메뉴의 계층(a hierarchy of menus)을 사용자에게 제공하며, 필요한 파라미터들에 대한 정보를 입력하도록 유도하며 그리고 나서 할일들을 실행한다. 이러한 인터페이스는 메뉴의 옵션(option)에 관한 정보를 기억하는 테이블을 갖는 데이타 베이스를 사용한다. 그러나, 많은 동일 옵션이 많은 동일 메뉴에 나타나기 때문에 메뉴와 옵션 사이에서 가능한 모든 순열(permutation)을 유지하려면 그러한 데이타 베이스가 필요하다. 그러한 데이타 베이스내에서 과대한 기억 공간이 필요한 것은 각각의 옵션과 메뉴에 관한 데이타가 그 데이타 베이스 전체를 통해서 반복적으로 기억되기 때문이다. 그래서, 만약 옵션 또는 메뉴중의 하나에 대한 변경이 행하여지면, 데이타 베이스는 한번에 갱신될 수 없고, 그러한 데이타가 상주하는 모든 장소에서 갱신되어야 한다. 하나의 메뉴의 혹은 그 메뉴내의 옵션들과 같은 단일의 인터페이스 오브젝트(single interface object) 혹은 그룹의 오브젝트들(group of objects)을 정의하는 데는 데이타 베이스내의 하나의 테이블만으로는 충분치 않다.

또한, 그러한 데이타 베이스로는 인터페이스 툴의 실행 동안에 시스템 정보를 개발하거나 또는 발견하는 능력도 없다. 그렇기 때문에 사용자에게 제공되는 모든 시스템 자원(resource) 속성값들은 개발시에 초기화된 그대로이며, 인터페이스 툴의 실행시 시스템의 참 상태가 반영되어 있지 않다. 따라서, 파라미터값에 대한 사용자 입력이 유효한가에 대하여 첵크되어야 하며 이러한 첵크는 시스템 실행시의 시스템 자원의 구성(the runtime configuration of the system resource)를 기초로하여 실제로 유효한 값에 대해서가 아니라 개발시 초기화된 값들에 대해서 행해져야 한다. 이러한 인터페이스 툴에 디스플레이된 메시지도 이와 비슷한 상황이다. 즉, 그러한 메세지도 개발시에 데이타 베이스 테이블에 초기화되어 있는 것으로서 시스템 자체의 작업으로부터 발생된 것은 아니다.

일반적으로, 인터페이스 데이타 베이스를 갱신 또는 변경시키려면 주위의 변경들이 완료될 때까지 고정시켜 두어야만 한다. 이것은 데이타 베이스가 인터페이스 툴 세션(tool session)의 종료까지는 수정될 수 없음을 의미하는 것이다. 인터페이스 툴을 통하여 데이타 베이스에서 행하여진 어떠한 수정도 즉시 반영되지 않으며, 인터페이스 툴의 다음 세션에 가서야 인터페이스 툴에서 반영된다. 다만, 시스템 매니저만이 통상적으로 인터페이스 데이타 베이스를 수정하는 것이 허용될 뿐이다.

일반적으로 특정한 점(specified point)에서 사용자가 인터페이스 툴의 계층을 입력시키는 것이 요구되는데, 이러한 일을 하려면 사용자 타스크(user task)에 관한 메뉴가 제공되기 전에 예비 메뉴의 시퀀가 사용자에게 제공되는 것이 필요하다.

통상적으로, 이러한 공지된 인터페이스들은 하나의 그래픽으로 표시(graphic representation)되어 있다. 이로 말미암아 다른 그래픽 라이브러리(graphic library)를 가지고 있는 다른 시스템에 대한 인터페이스의 혼화성(portability)이 감소된다. 게다가 메뉴, 옵션, 메세지 등이 여러 언어에서도 스크린 표시(screen presentation)를 지원하려면 그러한 인터페이스 데이타 베이스는 재작성되야만 하거나 또는 원전히 다른 데이타 베이스가 재개발되어야 한다.

또한, 몇몇의 인터페이스 툴에서 그러한 툴을 동작시키기 위해 수행되는 액션은 메뉴에서 펑크션널 레이어(functional layer)에 의해 수행되어야 할 작업과 혼합되어 있다. 예를들면, "exit", "go to next screen", "go to previous screen"등과 같은 펑크션 메뉴내에는 포함되어 있으나, 인터페이스 툴에는 포함되어 있지 않다. 그 결과, 만약 매니저가 새로운 메뉴를 추가하려면, 이러한 펑크션도 포함되어야만 한다. 그렇지 않고 이러한 펑크션이 포함되지 않으면 사용자는 인터페이스 툴에서 탈출하기 위한 수단을 가지지 못하게 된다.

[발명의 요약]

본 발명의 목적은 오브젝트 데이타 베이스에서 사용자 인터페이스를 제공하는(represent) 것이다.

본 발명의 다른 목적은 오브젝트 데이타 베이스의 오브젝트로서 스크린의 각각의 엘리멘트(each element of a screen)를 제공하는 것이다.

본 발명의 또다른 목적은 독립된 인터페이스 데이타 오브젝트들을 자체 식별하는 것으로부터 인터페이스 툴의 실행 동안에 동적으로 메뉴를 생성시키는 것이다.

본 발명의 또다른 목적은 임의의 엘리멘트들 갯수(anarbitrary number of elements)만큼 스크린 표시를 생성시키는 것이다.

본 발명의 또다른 목적은 재사용할 수 있는 인터페이스 데이타 오브젝트들로 스크린을 구축시킴으로써 인터페이스 데이타 베이스를 기억하는데 필요한 스페이스를 최소화하는 것이다.

본 발명의 또다른 목적은 시스템의 사전에 초기화된(preinitialized) 정보 대신에 시스템의 현재 상태를 사용자에게 제공하기 위하여 시스템과 동적으로 대화하는 인터페이스 툴을 생성시키는 것이다.

본 발명의 또다른 목적은 인터페이스 툴의 실행 동안 상호 대화에 의해 초래된 변경이 그 실행의 동일 세션내에서 반영되는 것을 허용시켜 주는 것이다.

본 발명의 또다른 목적은 시스템의 모든 사용자들이 새로운 인터페이스 오브젝트를 생성하는 것을 허용하며, 기존의 오브젝트들에 대해서는 액세스가 허용된 것들에 한하여 수정하는 것을 허용시켜 주는 것이다.

본 발명의 또다른 목적은 인터페이스 오브젝트들에 대하여 적용하는 액세스 제어 원칙들(the access control policies)을 이용하여 다른 어드미니스트레이티브 뷰(administrative views)를 제공하는 것이다.

본 발명의 다른 목적은 전체 계층의 트랜스버설(traversal)을 미연에 방지하기 위하여 하나의 빠른 경로를 계층(hierarchy)에 허용시켜 주는 것이다.

본 발명의 다른 목적은 독립적인 다수의 그래픽 라이브러리(independent multiple graphical libraries)를 지원하는 것이다.

본 발명의 다른 목적은 다수의 언어들로 인터페이스의 엘리멘트를 표시하기 위하여 시스템의 메시지 퍼실리티를 이용하는 것이다.

본 발명의 시스템과 방법은 사용자에게 메뉴와 다이얼로그를 디스플레이시키기 위한 인터페이스 툴에 관한 것이다. 사용자에게 실제의 시각적 표시(visual presentation)를 제공하는 일은 이러한 인터페이스 툴로부터의 데이타를 사용하는 스크린 라이브러리에 의해서 수행된다. 본 발명의 양호한 실시예에서 인터페이스 툴은 또한 사용자와 시스템 관리 펑크션(system management functions) 사이의 인터페이스로서도 사용된다. 본 발명의 인터페이스 툴은 자신이 표시하는 시스템 관리의 개별 인스턴스에 대한 지식을 가지고 있지 않은 일반 엔진(generic engine)이다. 데이타의 수집과 표시를 통한 네비게이션(navigation)은 응용층 또는 시스템층에서(in the application or system layer) 적절한 펑크션을 호출하는 것을 목표로 하여 나아간다. 이러한 작업은 특별한 사례에 대한 지식이 없이도 행해질 수 있는데 왜냐하면 인터페이스를 툴이 상기 타스크(task)의 성취를 위해 인터페이스층에 방향을 주기에 충분한 독립적인 데이타 오브젝트들을 자체 정의시킴으로써 구동되기 때문이다.

메뉴, 다이얼로그 및 시스템 자원의 각각의 인스턴스(instance)는 오브젝트 데이타 베이스내의 오브젝트들로서 표시되며, 인터페이스 오브젝트들이라 칭한다. 이러한 인터페이스 오브젝트들 내의 데이타는 시스템 자원의 토폴로지(the topology of the system resource)를 반영한다. 인터페이스 툴은 사용자 선택과 인터페이스 오브젝트들 자체내에서 데이타를 기초로 하여 이러한 인터페이스 오브젝트들을 트래버스(traverse)한다.

인터페이스 데이타 오브젝트와 시스템 자원 데이타 오브젝트는 구별되고, 그렇지 않으면 응용 데이타 오브젝트로 불리워진다. 시스템 자원 오브젝트는 본 명세서에서 참고로 한 R.J.Archon의 이름으로 1989년 5월 15일에 출원된 발명의 명칭이 "An Initial Program(IPL) Based on and Object Abstraction for a Data Processing System"인 07/960,180(IBM internal docket number AT9-89-035)와 ; R.A.Fabbio의 이름으로 1989년 5월15일에 출원된 발명의 명칭이 "An Open system Management Architecture For A Data Processing System"인 07/871,615, IBM internal docket number AT9-89-031)에 상세히 기술되어 있다. 시스템 자원 데이타 오브젝트는 시스템의 작업을 규정하며, 작업을 제어하는 소프트웨어(응용 또는 시스템)로 설치되며, 응용층(application lay)에서 기록/판독되며, 인터페이스 툴과 직접적인 관계가 없다.

인터페이스 데이타 오브젝트는 인터페이스의 작업을 한정하며, 작업을 제어하는 소프트웨어(응용)와 함께 설치되며, 인터페이스 툴에 의해서만 주로 판독되며, 데이타 처리 시스템내의 다른 층과 무관하다. 인터페이스 툴은 데이타의 이러한 몸체를 직접 참고로 하기 보다는 응용층에서 펑크션의 호출을 통해 시스템 자원 데이타 오브젝트내에 포함되는 필요한 정보를 얻는다.

인터페이스 툴은 모든 입력과 출력을 제어하는 어떤 명령을 독자적으로 실행할 수 있다. 그래서, 상기의 툴은 적절한 명령 셀 펑크션(command shell function)의 실행에 의한 모든 시스템 자원으로의 액세스 및 시스템 자원을 제어한다.

비록 구별이 데이타의 상술된 그룹내의 존재한다고 하더라도, 각종 그룹이 다른 데이타 베이스에서 상주하도록 기술적으로 행할 필요가 없으며, 다른 데이타 베이스 참조 기술을 사용할 필요도 없다. 그룹간 라인은 인터페이스층이 알고 있는(후에 기술될 클래스 정의를 참조) 오브젝트 클래스만을 참고로 하여 설계되기 때문에 특별한 노력없이도 유지된다. 인터페이스 툴이 참조 시스템 데이타로(또는 그 역으로) 명령될 가능성은 없는데, 그 이유는 상기 그러한 데이타가 다른 데이타 오브젝트 뿐만 아니라 다른 클래스의 데이타 오브젝트에 유지되기 때문이며, 이에 관하여 인터페이스 툴은 아무것도 알고 있지 않다. 그러나, 데이타 오브젝트의 어떤 클래스를 참조하기 위한 방법은 같게 될 것이다.

오브젝트 지향된 인터페이스 모델은 매우 융통적이고 쉽게 연장 가능한 인터페이스를 허용한다. 인터페이스의 부분은 대체로 층에 최소의 충격(impact)으로 함께 추가되거나 또는 삭제될 수 있다. 소프트웨어의 각각의 새로운 부분의 추가와 함께, 인터페이스 오브젝트는 처음에 어떠설계되었던 부분과 같은 방법으로 정확하게 시스템의 새로이 설치된 부분이 관리되도록 허용해주는 데이타 저장시스템에 추가될 수 있다. 그래서, 제3파티 벤더(party vendor)는 응용에 필요한 지원을 얻기 위해 본래의 제조자와 협상할 필요가 없다. 유지 보수의 문제점은 인터페이스를 연장시키거나 또는 제단하는(tailoring) 사용자가 대량의 데이타(테이블, 프로그램, 등등…)를 편집하지 않고 오히려 새로운 인터페이스 오브젝트를 생성시키고, 상기의 데이타를 저장소에 추가시키기 때문에 감소된다. 재컴파일할 필요없이, 새로운 오브젝트는 다음에 인터페이스 툴에 의해 발견되고 원하는 환경에서 다른 오브젝트와 함께 공통 id키(key)를 공유하기 때문에 새로운 오브젝트는 원하는 환경에서 입력된 환경을 나타낸다.

[양호한 실시예의 설명]

인터페이스 데이타 베이스에는 메뉴, 네임 카드(예를들면, 네임 선택)과 다이얼로그와 같은 오브젝트의 3개의 일반적인 형태가 있다. 이러한 형태는 역할에 의해 구별되며, 각각의 형태는 정보의 수집시 그 역할을 하지만 표시할 때 다르게 표시되지는 않는다. 요컨데, 메뉴에 의해 사용자는 필요로 하는 작업(job)을 다듬고 규정하게 된다. 네임 카드에 의해 사용자는 변경 또는 작업(work)/계획(plan)/모델(model) 처리하려는 자원 클래스의 특정한 인스턴스를 상세히 기술하게 해준다. 다이얼로그에 의해 사용자는 자원에 인스턴스에 관한 상세한 정보를 특정화한다. 본 발명의 인터페이스 툴(또는 툴 ; tool)은 응용층 펑크션을 실행하기 전에 필요로 하는 모든 정보를 수집하기 위해 이러한 3가지 형태의 조합을 사용할 수 있다. 어느 경로의 경우, 하나 이상의 이러한 형태는 불필요할 수도 있다. 데이타 오브젝트 그 자체는 원하는 종료 펑크션에 대해 경로에서 어느 오브젝트가 다음에 오는지를 인터페이스 툴 코드에 알린다.

인터페이스 툴에서 데이타 오브젝트의 3개의 클래스는 펑크션널 클래스이며, 표시 형태 또는 방법의 어느 지정된 특정한 상관 관계를 가짐을 의미하는 것은 아니다. 부연하여, 데이타 오브젝트 클래스는 인터페이스 툴에 제공될 수 있지만 사용자에게는 상관 관계를 디스플레이하지 않는다.

"메뉴(menu)"는 어떤 특별한 스크린 외양을 내포하거나, 또는 아이템(item)이 어떤 형태의 리스트로 제시됨의 시사하는 것을 의미하는 것은 아니다. "메뉴(Menu)"는 관리된 오브젝트 또는 액션(명사 또는 동사)의 범위를 감소시키는 수단을 나타내는데 사용될 것이다.

사용자가 관리 작업(job)을 더 미세하게 구별하는 한 사용자는 메뉴내에 있게 된다. 메뉴(menu)는 선택의 형태를 리스트, 더 상세화하기 위해 개방될 수 있는 오브젝트, 우리의 출력으로의 주밍(zooming), 룸(room)을 통한 이동 또는 메타포어(metaphor)가 적절한 것은 무엇이든지 취할 수 있다. 일단 작업(job)이 충분하게 규정되면, 사용자는 다이얼로그에 대한 메뉴의 범위(realm)를 남겨 놓는다. 여기서 주목해야 할 것은 메뉴의 목적이 다이얼로그에서 얻는 것이라는 것이다.

메뉴는 종료 작업을 실행하는 것이 아니고 단지 작업을 통해 사용자에게 전달하는 기능만 한다. 그러나, 어떤 펑크션들은 메뉴를 통한 패시지(passage) 동안 실행된다. 이러한 펑크션들은 래터럴 펑크션 또는 촉진 펑크션으로서 고려될 수 있다. 이러한 펑크션들은 선택을 타당하게 하고, 선택을 위한 가능한 후보를 제공하고, 사용자에게 도움을 준다. 일반적으로, 이러한 래터럴 펑크션들은 특정한 펑크션들을 실행하는 응용층(application layer)과 교차한다. 그러나, 이러한 교차(cross)는 주요 작업에 대한 과정 동안에 사용자를 위한 정보를 모은다. 가령, 이러한 촉진 펑크션들은 일반적으로 "ready only"펑크션이다. 메뉴를 통과하는 메시지는 결과적으로 응용 또는 시스템 데이타 베이스를 변경시키지 않는다.

메뉴는 미리 규정된 엔티티(entity)가 아니고 하나의 특별한 메뉴의 환경을 사용자가 유입시킬 때에 데이타 베이스에서 발견된 모든 독립 종료 사용자 데이타 오브젝트의 스냅 샷(snapshot)이다. 어떤 시간에 "발견된(found)"서브 세트는 키 필트에 의해 검색 기준과 부합하는 세트이다. 이러한 것은 인터페이스의 제3자 확정 가능성(third-party extendibility)에 대한 기본 요건이다. 종료 사용자 데이타 오브젝트는 다른 오브젝트에 관한 과도 효과(undue effect) 없이 데이타 베이스로 부터 쉽게 추가되거나 삭제될 수 있다.

메뉴 인터페이스 데이타 오브젝트는 시스템 자원 데이타 오브젝트의 계층과 유사하지만 같지 않은 계층으로 정렬된다. 메뉴 타스크의 계층은 시스템 자원 가장 편리하고 사용 가능한 뷰를 사용자에게 제공한다.

제10a,b 및 c도는 인터페이스 툴 계층의 현저한 특성을 나타내는계층의 부분을 예증한 것이다. 제10a도에서 메뉴 오브젝트(902 내지 909)는 동일 검색키의 공유에 의해 논리 프레임 표시부에서 함께 나타난다. 제10b도는 제10a도에서 사용자에 의해 데이타 오브젝트(903)가 선택되면 트래버설이 가용한 계층의 분기(branch)를 예증한 것이다. 제10b도에서, 메뉴 인터페이스 데이타 오브젝트(916 내지 926)는 동일 검색키를 공유함으로써 논리 프레임 표시부에서 함께 나타난다. 오브젝트(927 내지 934)는 오브젝트(916)가 선택되면 논리 프레임 표시부에서 함께 나타나게 된다. 만약 오브젝트(932)가 선택되면, 오브젝트(935 내지 937)는 선택을 위해 이용된다. 이러한 것은 계층을 통하여 다른 선택 경로를 통해 도달된 논리 프레임 표시부로 제10a도에 나타나는 동일 오브젝트이다. 제10c도는 제10b도의 메뉴 오브젝트(926)의 선택을 통하여 이용할 수 있는 분기의 연속성을 도시한 것이다. 제10c도에서 오브젝트(936,937)는 메뉴의 다른 분기를 이끈다. 그러나, TCP/IP는 양 어댑터에서의 구성을 위해 사용자에게 이용될 수 있기 때문에, 제10c도의 몇몇의 메뉴 오브젝트(959,960)는 2개의 분기 사이에서 공유된다. 제10a도에서 메뉴 오브젝트(906)는 제10c도상에서 반복된다. 상기 오브젝트(906)의 선택은 오브젝트(930,940)의 표시부를 발생시킨다. 메뉴 오브젝트(939)의 선택은 오브젝트(945,955)를 포함하고 있는 논리 프레임 표시부를 결과적으로 생성시킨다. 오브젝트(955)는 또한 오브젝트(954)의 선택에 의해 도달된 논리 프레임 표시부에 포함되어 있다. 오브젝트(945)는 또한 선택에 의해 도달된 논리 프레임 표시부에 포함되어 있다.

각각의 메뉴 오브젝트에 포함된 정보는 다음의 처리를 수행하기에 충분하다 ; 1) 메뉴 아이템(실제의 가시적 표시부는 스크린 라이브러리에 남아 있다)을 제공하고 ; 2) 후속 오브젝트에 위치 정하고, 3) 메뉴 아이템상에서 도움을 준다.

제2도에는 메뉴 오브젝트 클래스(200)가 도시되어 있다. id(202)는 오브젝트의 네임이다. 이러한 필드는 이러한 오브젝트가 이전의 레벨 오브젝트에 의해 위치 정해짐으로써 검색키를 제공하기에 충분한 정보를 보유하고 있다. 그럼으로써, 그룹내에 다른 오브젝트와 함께 오브젝트의 참여을 결정하게 된다. 이러한 필드는 빠른 경로(id)로서 객관화된다.

id_seq-num(203)은 메뉴의 오브젝트가 디스플레이되는 순서를 나타낸 것이다. next_id(204)는 이러한 아이템이 선택되면 검색하기 위한 다음의 오브젝트의 id를 나타낸다. 필드 텍스트(205)는 사용자에게 표시될 타스크를 기술한다. text_msg_file(206)은 스트링, 텍스트를 위한 메시지 퍼실리티 카탈로그이다. text_msg_set 필드(207)는 스트링, 텍스트를 위한 메시지 퍼실리티 세트 id이다. 세트 ids는 메시지 서비스에 의해 할당된다. text_msg_id 필드(208)는 스트링, 네임을 위한 메시지 퍼실리티 메시지 id이다. text_type 필드(209)는 이러한 아이템이 선택되면 다음 오브젝트의 형태를 나타낸다. 허용된 값들은 "menu", "name", "dialogue"와 "info"이다. 에일리어스 필드(210)는 이러한 메뉴 오브젝트가 다른 메뉴 오브젝트에 대한 빠른 경로 포인터인지의 여부를 나타낸다. 허용된 값은 "yes"와 "no"이다. 에일리어스인 메뉴 오브젝트에 대해, 다음의 규칙이 응용된다. 오브젝트 next_id(204)와 id_seq_num(203)은 원하는 메뉴로 위치 지정될 메뉴 오브젝트를 찾는데 사용될 것이다. help_msg_id(211)는 오브젝트에 대한 콘텍스트의 헬프를 위한 태그 번호를 나타낸다.

다이얼로그(dialogue)는 어떤 때에도 관련되어 발견되는 엘리멘트의 복합(데이타 오브젝트에서 개별적으로 표시된 바와같은)이다. 그래서, 그러한 것은 구조체들의 어레이로서 생각될 수 있으며, 정보(파라미터)의 조각과 대응하는 각각의 엘리멘트는 다이얼로그의 종료 작업(job) 펑크션으로 통과하게 될 것이다. 비록 엘리멘트가 그래픽 표시로 광범위하게 널리 변경할 수 있다고 하더라도, 엘리멘트에 포함된 정보는 동식 방식으로 구성되며, 다음의 작동을 하기에 충분하다 ; 1) 다이얼로그 아이템을 표시(적당한 표시는 그래픽 라이브러리와 텍스트 라이브러리에 남게 된다) ; 2) 실행될 펑크션으로 위치 지정 ; 3) 선택(값을 표시 및 수집) ; 4)헬프 부여.

다이얼로그 엘리멘트 오브젝트는 "question"(id)와 "answer"(값)부분을 가지고 있다. 대답(answer)부분은 예를들면 디폴트(default) 또는 현재값과 같은 사용자에게 제안하는 임시 대답을 가질 수 있다. 이러한 2개의 부분은 매우 다른 기원을 가질 수 있다. 질문(question)은 다이얼로그 오브젝트가 개발될 때 초기화 되는 것이 필요하다. 대답의 예외가 있는 데이타 오브젝트에서 상기의 질문은 모든 다른 필드와 함께 초기화된다. 대답은 제안된 값을 가질 수 없거나 또는 가능한 값의 제한된 세트를 가질 수 있다. 그러나, 만약 대답이 시스템의 현재 상태에 종속되면, 실행시 대답은 "discovered(발견)"되어야만 한다. 발견 과정은 아래에 상세히 기술되어 있다.

상술된 "question(질문)"은 다이얼로그에서 엘리멘트의 바로그 존재에 의해 포함될 수 있다. 예를들면, 만약 다이얼로그의 메타포어가 다이얼을 호출하면, 다이얼의 엘리멘트와 페이스(face) 및 니들(needle)은 각각 다이얼로그의 엘리멘트가 된다. 그러한 환경으로의 엔트리시, 사용은 리터럴 질문(literal question)과 직면하게 되지 않는다. "니들이 원하는 세팅이 무엇이냐?"라는 질문은 니들의 존재에 의해서 함축된다. 대답(값)은 현재(입력)값에 주어지며, 그러한 것은 아래에 기술된 바와같이 발견된다. 사용자는 원하는 세팅으로 니들을 조작하며, 그러한 세팅은 데이타 오브젝트의 출력값이 된다. 새로운 세팅은 인터페이스 툴이 변화를 성취하도록 적당한 펑크션을 실행할 때 파라미터로서 수신된다.

스크린상에 다이얼로그를 생성시키기 위해, 인터페이스 툴은 키된(keyed) 데이타 오브젝트(이전 오브젝트의 "next" 필드로부터 공급된 것을 가지고 있는 키)를 검색하고 데이타 오브젝트에 대한 적절한 표시부를 선택하고, 다른 가능한 오브젝트와의 자체 상태의 관계에 따라 데이타 오브젝트를 주문하고, 사용자에게 제공할 준비를 한다. 그러나, 데이타 오브젝트의 몇몇 양상(현재값과 같은)을 잃게 될 수도 있다. 이때에, 인터페이스 툴은 현재 구성값을 발견 응용층 펑크션에 호소한다. 이러한 펑크션들의 네임(name)은 다이얼로그 데이타 오브젝트내에 포함되어 있다.

다이얼로그는 데이타 오브젝트의 2개의 클래스로 표시된다. 헤더 오브젝트는 종료 작업을 나타내려 응용층 데이타 베이스를 성취하는데 충분하며 시스템에서 실제 변화를 성취시킨다. 각각의 헤더 오브젝트에는 하나 이상의 엘리멘트 오브젝트가 있다. 각각의 엘리멘트는 메타포어의 한개의 아이템을 제공하며 한개의 자원, 한개의 파라미터, 하나의 선택 및 하나의 값등을 제공한다.

모든 메뉴가 다이얼로그 헤더 오브젝트(실제로 작업을 수행함)를 이끌면서 모든 다이얼로그 헤더 오브젝트는 다이얼로그 엘리멘트 오브젝트를 이끌지는 않는다. 작업이 메뉴에 의해서 충분히 규정될때("감소될 때 ; diminished"), 사용자와의 더 이상의 대화가 필요가 없다. 이런 경우에, 다이얼로그 헤더는 충분하며, 기능은 수고없이 디스패치(dispatch)될 것이다. 그러나 다른 경우에 더 상세한 정보(선택)는 사용자(가능한 변경을 위해 사용자에게 제공됨)에게 요청할 필요가 없다.

엘리멘트를 포함하고 있고 헤더를 포함하고 있는 다이얼로그 사이에서의 구별은 펑크션널, 문체적 또는 콘텍스트적으로 구분될 수 있다. 예를들면, 자원의 인스턴스를 리스트하려는 요청은 항상 저절로 종료되며 다이얼로그 엘리멘트 데이타 오브젝트를 경유하여 정교하게 할 필요가 없다. 이러한 것을 성취하는 펑크션은 즉시 실행될 수 있다(차례로, 그러한 것은 다이얼로그 환경에서 위치 정해지는 이러한 데이타 엘리멘트를 다시 보낼 수 있다). 다른 한편으로, 사용자가 경고 메시지와 같은 자원의 특성을 변경시키고자 하면 최소 하나의 다이얼로그 엘리멘트가 있어야 하며, 이러한 값이 현재 메시지이다. 사용자는 기꺼이 이러한 것을 변경시킬 수 있고, 헤더에 포함된 펑크션이 변경의 발생을 가능케 해준다. 변경될 수 있는 다중 특성을 가진 자원은 서로 분리된 엘리멘트 데이타 오브젝트를 필요로 한다. 그러나 모든 것은 단일 헤더로 합쳐진다. 헤더가 충분한 경우와 다중 엘리멘트에 의해서 자원되어야만 하는 경우간의 구별은 펑크션널인 것이다. 엘리멘트들을 필요로 하는 펑크션이 없는 경우 엘리멘트들은 규정되지 않는다.

대조적으로 하나의 단일 펑크션이 더 상세한 엘리멘트 오브젝트의 정교함을 필요로 할 수도 있고 필요로 하지 않을 수도 있다. 만약 사용자가 공지된 형태의 자원을 추가시키려고 한다면 인터페이스 툴은 자원의 규정 가능한 사용자 특성이 추가된 자원을 변경시키는 것이 가능하거나 조사를 위해 사용자에게 제공된 자원을 결정하는 콘텍스트(context), 스타일 또는 보안 레벨을 사용할 수도 있다. 어떤 레벨에서, 그러한 것은 그러한 내용을 제공하는 것을 꺼려하거나 부적절한 것으로 고렬될 수도 있으며, 반면에 다른 레벨에서는 필수적인 경우도 있으며, 그러한 경우에 엘리멘트 오브젝트는 규정되어야만 하고 결정은 인터페이스 툴에 따라 좌우된다.

제4도에는 다이얼로그 헤더 오브젝트 클래스(400)가 도시되어 있다. id(400)는 오브젝트의 id 또는 "네임"이다. 필드 option_id(403)는 헤더가 가리키는 다이얼로그 필드(sm_cmd_option)의 id이다. 필드 has name_select(405)는 다이얼로그가 네임 선택기에 의해 진행되거나 또는 진행되지 않음을 나타내는 것이다. 허용된 값은 "예스(YES)"와 "노(no)"이다. 네임(404)은 작업을 기술한 것이며 다이얼로그의 제목으로서 사용된다. name_msg_file(406)은 스트링, 네임을 위한 메시지 퍼실리티 카탈로그이다. 필드 name_msg_set(407)는 스트링, 네임을 위한 메시지 퍼실리티 세트(id)이다. 필드 name_msg_id(410)는 스트링 네임을 위한 메시지 퍼실리티(id)이다. 필드 cmd_to_exec(408)는 다이얼로그의 작업을 실행하는 오퍼레이팅 시스템 명령이다.

필드 ask(409)는 사용자가 작업을 실행하는(예를들면, 타스크) 사용자의 선택을 재고려하도록 요청받았는지의 여부를 나타낸다. 이러한 것은 "DELETE"와 같은 작업에 유용하며, 여기서 시스템 자원이 삭제된다. 가끔, 작업과 관련된 다이얼로그를 디스플레이 가능하게 되지 않을 때를 재고려할 필요가 있다. 만약 이러한 것이 그런 경우라면 고스트(ghost) 다이얼로그가 이용된다. 필드 ghost(411)는 이러한 작업과 관련된 디스플레이 가능한 다이얼로그가 있는지의 여부를 표시한다. 만약 사용자로부터 요구될 필요가 있는 다른 정보가 없다면 다이얼로그가 필요하지 않게 될 것이다. 이러한 경우에, cmd_to_exec(408)가 즉시 실행된다. 필드 ghost(411)에 대해 허용된 값은 "예스"나 "노"이다. 필드 ask(408)에 대해 허용된 값은 "예스"와 "노"이다.

필드 exec_mode(413)는 명령이 인터페이스 툴(sm_default)을 통하여 재지향된 stdin/stdout/stderr와 함께 실행되거나, 또는 독립 스크린 관리(sm_fork_exec)를 위한 stdin/stdout/stderr를 인계 받는지의 여부를 나타낸다. 필드 cmd_to_discover(412)는 조종되는 오브젝트의 디폴트 또는 현재값을 발견하는데 사용되는 오퍼레이팅 시스템 명령이다. 이러한 명령은 다이얼로그가 디스플레이되기 전에 실행되며 stdout는 검색된다. 출력 컬럼의 헤더는 필드의 값으로 부합하기 위해 사용될 것이다. 필드 cmd_to_discover_postfix(414)는 command_to_discover와 함께 사용될 후위(postfix)를 나타낸다. 세개의 허용된 값이 있다. 첫번째 값은 다이얼로그와 관련된 네임 선택기가 있을 때만 사용된다. 값 sm_postfix_raw는 네임 선택기 패널에 입력된 네임이 이러한 명령과 함께 사용될 것이라는 것을 나타낸다. 값 sm_postfix_cooked는 선택기 패널로부터 네임이 cmd_to_classify에 의해 형태 지어지고 그러한 것을 분류시키는 명령어로부터의 출력이 cmd_to_discover와 함께 사용되어야만 하는 것을 나타낸다. 값 sm_postfix_empty가 cmd_to_discover를 위한 후위(postfix)가 없음을 나타낸다.

필드 name_size(415)는 다이얼로그를 위한 필드 네임의 폭을 나타낸다. 만약 이러한 필드가 0이면, 디폴트 포맷팅이 이용된다. 필드 value size(416)는 다이얼로그를 위한 필드값의 폭을 나타낸다. 만약 이러한 필드가 0이면, 디폴트 포맷팅이 사용될 것이다. 필드 help_msg_id(417)는 전체 다이얼로그를 위한 콘텍스트 헬프용 태그 번호를 나타낸다.

제3도에는 다이얼로그 오브젝트 클래스(300)가 도시되어 있다. 필드 id(302)는 오브젝트의 id 또는 "네임"이다. 하나의 다이얼로그와 함께 나타나는 모든 오브젝트(필드)는 같은 id를 가져야만 한다. id_seg_num(303)은 다이얼로그의 오브젝트(필드)가 시퀀스로 디스플레이되도록 해준다. 모든 캐랙터값은 코드 포인트에 의해 시퀀스된다. 이러한 오브젝트가 네임 선택기용으로 사용될때 이러한 필드는 0이다. disc_fieldnmme(304)는 cmd_to_discover로부터 stdout내의 헤더 스트링을 나타내며 이러한 값은 오브젝트와 관련된다. 그러한 것은 네임 필드(305)와 논리적 등가치이지만, 더 단축된 형태가 될 수도 있다. 이러한 필드는 cmd_to_discover (412)의 stdout와 동등하게 될 것이다. 이러한 오브젝트에 대한 값을 나타내는 것은 cmd_to_discover 대신에 (raw/cooked) 네임으로부터 오는 것이다. 또한 이러한 필드는 "raw name" 또는 "cooked name"으로 세트되어야만 한다. 이러한 오브젝트가 네임 선택기를 위해 사용될 때, 이러한 필드는 보존되며 널(null)로 세트된다.

네임 필드(305)는 필드 네임과 같이 스크린상에 나타나게 될 스트링이다. 예를들면, 그러한 것은 옵션, 파라미터, 플래그 등의 자연 언어 설명인 cmd_to_exec의 파라미터와 상관 관계가 있으며, "질문"부분이다. name_msg_file(306)은 스트링, 네임을 위한 메시지 퍼실리티 카탈로그이다. name_msg_set(307)는 스트링, 네임을 위한 메시지 퍼실리티 세트 id이다. name_msg_id(308)은 스트링, 네임을 위한 메시지 퍼실리티 메시지 id이다.

op_type 필드(309)는 이러한 오브젝트를 위한 스크린 관리 방법을 나타낸다. 허용된 값은 다음과 같다. 값 sm_list_entry는 0 또는 1의 값이 사용자에게 제공된다 하더라도 이러한 필드를 위해 리스트가 이용될 수 있음을 나타내는 것이다. 상기 리스트는 사용자가 LIST 펑크션을 나타낼때 cmd_to_list에 의해 생성된다. 값 sm_ring_entry는 사용자가 순환할 수 있는 다중값을 필드가 가짐을 나타낸다. 모든 링 필드는 또한 리스트와 같이 도시될 수 있다(스크린의 제한내에서 한번에 모든 것이 선택).

entry_type(321)는 이러한 오브젝트를 위한 스크린 관리 방법을 나타낸다. 값 sm_text_entry는 사용자가 필드에 영숫자의 입력을 타이프시킬 수 있음을 나타낸다. 값 sm_numeric_entry는 사용자가 숫자 데이타만을 입력시킬 수 있음을 나타낸다. 값 sm_hex_entry는 사용자가 16진수 데이타만을 입력시킬 수 있음을 나타낸다. 값 sm_file_entry는 파일 네임만을 입력시킬 수 있다. 값 sm_no_entry는 필드가 단지 정보임을 나타낸다.

필드 entry_size(322)는 사용자가 값 필드에 입력시킬 수 있는 바이트 최대 숫자를 나타낸다. 이러한 숫자가 0이면, 어떤 상위 제한도 요청되지 않는다. 필드 required(310)는 사용자가 값을 변경시키는지의 여부에 관계없이 필드가 항상 cmd_to_exec와 함께 보내져야만 하는 것을 나타낸다. 일반적으로 변경되지 않는 필드는 명령과 함께 보내지지 않는다. 허용된 값은 "예스"와 "노"이다. 이러한 오브젝트가 네임 선택기용으로 사용될 때 이러한 필드는 보존되어 널(null)로 세트된다.

필드 prefix(311)는 cmd_to_exec의 실시에서 값 필드와 함께 보내지게 될 프리픽스(prefix) 또는 플래그를 나타낸다. 그러한 것은 노 플래그(no flag) 또는 "-f"를 위해 널로 세트될 수도 있으며, 여기서 "f"는 사용될 플래그를 나타낸다. 이런 두가지 경우에서, 값과 필드는 제1패스상에 수집될 것이다. 또한, 그런 것은 "--"로 세트될 수 있으며, 상기에는 플래그가 없고 값은 제2패스상에 수집되어야만 하는 것을 나타낸다. 이러한 오브젝트가 네임 선택기로서 사용될때 이러한 필드는 보존되며 널로 세트되어진다.

cmd_to_list_mode(313)는 리스트로부터 선택된 아이템이 얼마나 많이 사용되어야만 하는지를 나타낸다. 허용된 값은 sm_first_field와 sm_all_field이다. 만약 명령이 리스트 이외의 범위로 복귀하려면 이러한 필드의 값은 sm_range가 되어야만 한다. 범위는 선택 가능한 것이 아니라 정보만을 위한 것이다. cmd_to_list(312)는 값 필드에 대한 후보들의 리스트를 공급하는 오퍼레이팅 시스템 명령을 나타낸다. 필드 cmd_to_list_postfix(323)는 cmd_to_list와 함께 사용될 후위를 나타낸다. 허용된 세가지 값이 있는데 ; 첫째는 다이얼로그와 관련된 네임 선택기가 있을 때만이 사용될 수 있다. sm_postfix_raw는 네임 선택기 패널에 입력된 네임이 명령어와 함께 사용될 것임을 나타낸다. 값 sm_postfix_cooked는 네임 선택기의 cmd_to_classify로부터의 출력이 명령과 함께 사용되어야만 한다. 값 sm_postfix_empty는 명령을 위한 후위(postfix)가 없음을 나타낸다. 이러한 오브젝트가 네임 선택기용으로 사용되어질때, 이러한 필드는 보존되어지고 널로 세트되어야만 한다.

필드 multi_select는 cmd_to_list로부터 사용자가 다중 선택을 할 수 있는지의 여부를 나타낸다. 허용된 값은 "예스"와 "노"이다. 필드 value_index(314)는 이러한 오브젝트가 링(ring)이면 값 필드에서 규정된 값의 시퀀스로 디폴트값을 나타내는 zero origin index(제로 오리진 인덱스)이다.

필드 disp_values(315)는 다이얼로그의 초기에 사용자에 제공될 커런트(current), 디폴트 또는 허용된 값을 제공한다. 이러한 필드는 오브젝트가 cmd_to_discover에 의한 실행시 개발되거나 발견될때 초기화될 수 있다. values_msg_file(316)는 스트링, disp_values용 메시지 퍼실리티 카탈로그이다. 만약 이러한 값이 초기화되면 그때 오브젝트가 개발되어진다. values_msg_set 필드(317)는 만약 이러한 값이 개발 시간에서 초기화되면 스트링, disp_values용 메시지 퍼실리티 세트 id이다. 필드 values_msg_id(318)는 만약 이러한 값이 오브젝트가 개발될때 초기화되면 스트링, disp_values용 메시지 퍼실리티 메시지 id이다.

필드 aix_value(319)는 오퍼레이팅 시스템 명령값을 나타내며, 그러한 것은 개발 시간에서 초기화된 링필드에 표시된 자연적인 언어 disp_value와 동기이다. 이러한 오브젝트가 네임 선택기용으로 사용될때 이러한 필드는 보존되어 널로 세트되어야만 한다. help_msg_id(320)는 오브젝트용 콘텍스트 헬프에 대한 태그 번호를 나타낸다. 필드 cmd_to-validate(325)는 단일 필드를 위한 사용자 입력값들을 유효하게 하는데 사용된다.

네임 선택기 오브젝트들은 용융층 펑크션이 수행됨에 따라 오브젝트의 인스턴스를 모으기 위해 사용된다. 다시말하면, 상기의 오브젝트들은 펑크션의 다이렉트 오브젝트를 선택한다. 네임 카드에서 리스트 펑크션은 사용자가 선택할 수 있는 곳으로 부터 실행 시간 선택을 제공한다.

네임 선택기 오브젝트는 래터럴 펑크션들 또는 종료의 연속 실행시 사용된 파라미터를 제공한다. 네임 선택기 오브젝트는 또한 인터페이스층을 다른 연속적인 인터페이스 데이타 오브젝트에 직접 연결시킴으로써, 종료 펑크션으로 취해진 경로를 변경시키게 된다.

예를들면, 만약 사용자가 어떤 큐(pueue)에 프린터를 접속시키기를 원한다면 인터페이스 툴은 정확히 접속될 프린터를 알고 있어야만 한다. 다시 말하면, 논리 인스턴스 네임을 필요로 하고, 네임 선택기 오브젝트에 의한 정보를 필요로 한다. 인터페이스 오브젝트는 가능한 프린터 네임의 리스트와 함께 초기화될 수 없는데 이것은 정보가 시스템의 현재 구성에 의존하기 때문이다. 그래서 네인 선택기 오브젝트는 시스템(예를들면 시스템 데이타 베이스에 표시된 바와같은)에 공지된 원하는 형태의 프린터의 리스트를 검색할 응용층 펑크션을 규정한다. 네임 선택 오브젝트는 리스트 및 선택 펑크션을 수행한다. 선택된 네임은 종료 작업 펑크션에 대한 파라미터로서 필요하다.

상위 레벨에서 네임 선택기 오브젝트는 논리 프린터의 네임보다는 오히려 물리적 프린터의 형태를 리스트 하는데 사용될 수 있다. 다시 말해서, 인터페이스 오브젝트는 이러한 리스트를 포함할 수 없으며 이런 정보를 얻는 응용층에서 실행하는 펑크션의 네임을 포함해야만 한다. 사용자가 자원 클래스내의 형태 사이에서 선택할때 그러한 선택은 가끔 후속 데이타 오브젝트의 선택에 대한 함축성을 가지고 있다. 어떤 프린터의 형태도 같은 방식으로 운용(접속/구성)되지 않을 것이다. 그래서 선택된 형태는 다음의 인터페이스 오브젝트를 발견하는 어떤 방법(연결 방법)으로 사용될 것이다.

일반적으로, 리스트에 대한 펑크션은 단지 타당한 선택을 하는 사용자에게 자동적으로 제공되도록 실행된다. 다시말하면, 전체 리스트를 표시하기 위해 표시 공간의 광범위한 스크롤링(scrolling)이 사용자를 귀찮게 하거나 또는 리스트의 후보가 거의 제한되지 않거나 또는 사용자가 선택하고자 하는 오브젝트의 네임을 알고자 하는 그러한 선택 리스트가 길다면 가장 짧은 경로는 인스턴스에서 간단하게 키(key)시킬 수 있는 능력을 가진 사용자에게 네임 선택 펑크션을 표시하는 것이다. 옵션으로서 리스팅 특징(listing feature)을 제공한다. 이런 경우는 모든 파일이 후보로서 리스트될 필요가 있는 파일 시스템으로 작업시에 종종 발생한다.

네임 선택 오브젝트 클래스(600)는 제6도를 참고로 하여 설명된다. id(602)는 오브젝트의 id 또는 "네임"이다. 필드 next_id(603)은 이러한 네임 선택기가 선행하는 sm_cmd_hdr 오브젝트의 id를 나타낸다. 필드 potion id(605)는 이러한 네임 선택기를 위한 sm_cmd_ppt이다. 필드 네임(604)는 네임 선택기 스크린의 타이틀이다. 필드 name_msg_file(606)은 스트링, 네임용 메시지 퍼실리티 카탈로그이다. 필드 name_msg_set(607)는 스트링, 네임용 메시지 퍼실리티 세트 id 이다. 필드 name_msg_id(608)는 스트링, 네임용 메시지 퍼실리티 메시지 id 이다.

필드 type(609)는 선택된 네임을 처리하는데 사용될 방법을 나타낸 것이다. 값 sm_just_name은 선택된 네임이 단지 다이얼로그로 통과된다는 것을 나타낸다. 이런 경우에서, next_id 필드는 오브젝트가 개발될때 초기화되어 전체가 규정된 스트링이다. cmd_to_classify가 필요치 않으며 따라서 널이다. 다이얼로그가 표시될 필요가 있는 것을 결정하도록 인스턴스가 선택될 때까지 기다릴 필요가 없다. 값 sm_raw_mane은 선택된 네임이 다이얼로그를 위한 검색키를 생성시키는 next_id 에서 스트링과 함께 연결되는 것을 나타낸다. 이런 경우의 예는 TCP/IP 메뉴에서 찾아볼 수 있으며, 네임 선택 "Ethernet"은 "Token"의 네임 선택보다 다른 다이얼로그를 호출한다. 이런 경우에, next_id는 부분적으로 개발에서 규정되며 실행시간에서 규정된다. 다시말하면, cmd_to_classify가 필요치않으며 그래서 널(null)된다. 값 sm_cooked_name 은 선택된 네임이 다음에 제공하는 다이얼로그의 결정에 충분치 않음을 나타낸다. 이런것의 예는 프린터와 관계가 있으며 인스턴스 "IpO"의 선택이 다음 다이얼로그의 선택을 위해 충분한 정보를 주지않으며, 그런것은 "IpO"가 공지된 형태가 아니기 때문이다. 이런 경우에 next_id는 cmd_to_classify로부터 복귀된 next_id+the stdout의 값을 얻으며, 그러한 것은 name_selected로 보내어진다.

ghost 필드(610)는 네임 필드(604)를 디스플레이하는지여부 또는 cmd-to-list에 의해 생성된 리스팅(listing)에 곧바로 가는지의 여부를 나타낸다. cmd-to-classify(614)는 만약 필요하다면 이런 네임 선택기에 대한 sm-cmd-opt 레코드의 네임 필드의 값을 분류하는데 사용되는 오퍼레이팅 시스템 명령을 나타낸다. 필드 help-msg-id(611)는 오브젝트에 대한 콘텍스트 헬프를 위한 태그 번호를 나타낸다.

제1a도는 상부 메뉴 1A로부터 작업의 실시까지의 작업 진행을 도시한 것이다. 모든 작업(work)은 다이얼로그(14)에서 실시된다. 비록 래터럴 헬프(2)와 리스트(4)가 진행에 기여하지 않는다고 하더라도 그러한 것들은 어떤 아이템에서 가능한 후보들의 리스트와 헬프를 제공함으로써 진행되도록 사용자를 돕는다. 사용자는 상부 메뉴(1A)를 입력시키고 네임 선택(12)을 얻을 때까지 다른 가능한 메뉴를 통하여 트래버스하며, 그러한 것은 옵션이다. 그 다음은 다이얼로그(14)이다. 이러한 각각의 세개의 단계 : 메뉴(1), 네임 선택(12), 다이얼로그(14)는 다르게 나타나며 다른 성질을 가지고 있다. 다이얼로그는 실제로 사용자와의 대화이며, 통상적으로 시스템 자원의 속성으로 구성된다. 사용자는 그후 속성에 대한 값을 입력시키거나 또는 선택하며 다이얼로그에 대한 응답 모드를 완료시키고 후에 실행될 타스크를 사용자가 진행시킬 준비가 되어 있음을 표시한다. 명령의 출력은 출력 프레임으로 향하게 된다. 헬프(2)와 리스트(4)가 콘텍스트이기 때문에 사용자는 전체 메뉴에 대한 헬프(help)를 얻을 수 있으며 또한 메뉴내의 어떤 개별적인 아이템과, 전체 다이얼로그, 또는 다이얼로그 내의 어떤 개별적인 아이템에 관하여 헬프를 얻을 수 있다.

소위 시스템 관리 툴 메뉴 옵션이라 불리우는 각각의 인터페이스 메뉴 오브젝트는 메뉴로 표시된다. 메뉴는 정적인 것이 아니며 오히려 같은 검색키를 가진 어떤 시간에서 오브젝트 데이타 베이스내에서 발견되었던 메뉴 옵션의 수집이다. 이러한 것은 응용 또는 셀(shell)의 펑크션을 확장시키는데 중요한 것이며, 왜냐하면 이러한 것이 사용자에게 새로운 메뉴 옵션과 오브젝트를 추가시킴으로써 메뉴내의 새로운 아이템을 집어 넣도록 해주고, 그러한 것은 사용자가 포함되기를 원하는 메뉴에 관한 다른 아이템과 같은 검색키를 가지고 있기 때문이다. 다음에 사용자는 셀을 작동시키며, 셀에는 메뉴에서 나타났던 특별한 아이템(방금 추가된 것)이 있다. 그래서 메뉴는 정적인 것이 아니다. 대신에 메뉴는 어느때라도 검색 표준을 충족시켜온 모든 오브젝트를 포함하고 있다. 그러므로 사용자는 셀내에 후크(hool)하기를 원하는 트리(tree)내의 장소를 선택하고 그러한 장소에서 검색 표준과 만남으로써 이러한 인터페이스 툴을 확장할 수 있다.

제8a 내지 c도는 시스템의 토폴로지(topology of the system)를 통하여 트래버스하기 위한 일반적인 플로우를 도시한 것이다. 상부 메뉴의 id는 단계(801)에서 오브젝트 데이타 매니저에게 메뉴 인터페이스 오브젝트를 위한 검색을 id가 사용하는 메뉴 처리 모듈에 대한 프리밍(priming) 입력으로써 사용된다. 메노 인터페이스 오브젝트에 대한 적절한 표시는 언어 및/또는 그래픽 환경을 참조로 하여 결정된다. id 키와 부합하기 위해 발견된 모든 오브젝트는 단계(802)에서 다중의 그래픽 라이브러리에 대한 인터페이스를 줄임으로써 적합성을 강화하는 스크린 라이브러리에 디스플레이시키기 위해 보내진다. 인터페이스 툴로부터 스크린 라이브러리에 보내진 오브젝트의 수집은 논리 프레임 표시로 언급되는데, 이것은 사용자에게 아직 디스플레이되지 않았기 때문이다.

스크린 라이브러리는 사용자 선택이 행하여질 때까지 사용자 입력을 수집하며, 단계(803)에서 메뉴 처리 유니트에 다시 선택을 보낸다. 메뉴 처리 모듈은 단계(804)에서 사용자 선택을 나타내는 메뉴 인터페이스 오브젝트를 조사한다. 단계(805)에서 다음 형태가 메뉴를 나타내면, 단계(806)에서 다음의 id는 순환 호출(recursive call)로 메뉴 처리 모듈에 통과된다. 이러한 루프는 다음의 형태가 메뉴가 아닐 때까지 계속된다.

다음 형태가 단계(807)에서 네임 선택기로 된 것이 발견되면 네임 선택 처리 모듈은 단계(808)에서 오브젝트 데이타 매니저내의 네임 선택이 인터페이스 오브젝트에 대한 검색을 하는 id를 사용한다. 네임 선택기 인터페이스 오브젝트를 위한 적절한 표시는 언어 및 그래픽 환경을 참고로 하여 결정된다. 그러한 표시는 단계(809)에서 인터페이스을 좁게 하므로써 다수의 그래프 라이브러리를 적합하게 하는 스크린 라이브러리에 디스플레이시키기 위해 보내진다. 스크린 라이브러리는 사용자 선택이 행하여질 때까지 사용자 입력을 수집하고 단계(810)에서 네임 선택기 처리 모듈로 다시 선택을 보낸다. 네임 선택 처리 모듈은 단계(811)에서 다이얼로그 헤더를 위한 검색키를 결정하는 사용자 선택과 다음 id 사이에서 상호 작용을 결정하는 네임 선택기 인터페이스 오브젝트를 조사한다. 이러한 상호 작용을 수행하기 위한 세가지 방법이 있다. 첫번재 방법은 사용자 선택이 단지 다이얼로그를 통과하는 것을 나타내는 것이다. 이러한 경우에 next-id 필드는 충분히 규정된 스트링이다. command-to-classify는 필요하지 않아서 널(null)된다. 사용자 선택은 다이얼로그 헤더 오브젝트에 어떤 영향을 미치지 않는다. 두번째 방법은 선택된 네임이 다이얼로그를 위한 검색키를 생성시키는 next-id에서 스트링과 함께 연결되는 것을 나타낸다. 이런 경우에, next-id는 사용자의 선택을 기초로 한 사용자와 네인 선택 인터페이스 오브젝트의 개발자에 의해 부분적으로 규정된다. 다시 말하면, cmd-to-classify는 필요하지 않게 되어 널된다. 세번째 방법은 사용자 선택이 다음에 제공하는 다이얼로그의 결정을 위해 충분하지 않음을 나타낸다. 이런 경우에 네임 선택 처리 모듈은 파라미터와 같은 사용자 입력을 cmd-to-classify에 보내고 단계(812)에서 형태를 명령으로부터 출력과 같이 수신한다. 만약 존재한다면 네임 선택한 사용자와 형태는 단계(813)에서 다이얼로그 처리가 모듈로 통과된다.

단계(813 및 807)후에, 만약 next-type이 다이얼로그 인터페이스 오브젝트이면, 제어는 다이얼로그 처리 모듈로 통과된다. 다이얼로그 처리 모듈은 단계(814)에서 오브젝트 데이타 매니저내의 다이얼로그 헤더 인터페이스 오브젝트를 검색하기 위해 id를 사용한다. 다이얼로그 처리 모듈은 단계(815)에서 다이얼로그가 고스트(ghost)인지의 여부를 결정하는 인터페이스 오브젝트를 조사한다. 고스트 다이얼로그는 관련된 사용자 I/O를 가지고 있지 않다. 만약 다이얼로그가 고스트가 아니면, 다이얼로그 처리 모듈은 단계(816)에서 오브젝트 데이타 매니저내의 다이얼로그 옵션을 검색하기 위해 옵션 id를 사용한다. cmd-to-discover는 단계(817)에서 다이얼로그 옵션 인터페이스 오브젝트를 위해 적절한 디폴트값을 얻도록 실행된다. 각각의 다이얼로그 옵션 인터페이스 오브젝트의 적절한 표시는 어어 및 그래픽 환경을 참고로 하여 결정된다. 발견된 값에 따른 표시는 단계(818)에서 다수의 그래픽 라이브러리에 대한 인터페이스를 좁게 하므로써 적합하게 해주는 스크린 라이브러리에 디스플레이시키기 위해 보내진다. 스크린 라이브러리는 단계(819)에서 사용자가 실행될 작업(job)을 나타낼 때까지 사용자 입력을 수집한다. 단계(815 및 819)후에, 만약 다이얼로그가 고스트이면, 다이얼로그 처리 모듈은 단계(820)에서 작업 실행하는 결정을 재고려하도록 요청되었는지의 여부를 결정하는 다이얼로그 헤더 오브젝트를 조사한다. 예스(yes)이면, 단계(812)에서 사용자는 질문을 받게 되고, 단계(822)에서 그러한 반응이 스크린 라이브러리를 통하여 수신된다. 사용자가 단계(823)에거 긍정적으로 응답하면 또는 질문이 잘못되었으면(단계 820) 다이얼로그 처리 모듈은 단계(824)에서 다이얼로그 헤더 인터페이스 오브젝트에서 실행하는 명령을 조사할 것이다. 명령의 실행으로부터 파생된 어떤 출력 또는 에러 메시지가 단계(825)에서 디스플레이된다.

어떤 반응은 단계(826)에서 출력 또는 메시지를 재검토하는 것을 사용자가 끝냈음을 나타내는 사용자로부터 수신된다. 다이얼로그 처리 모듈은 단계(827)에서 다이얼로그를 다시 디스플레이시킨다. 단계(828)에서 사용자 입력을 수집한다. 만약 사용자가 단계(829)에서 명령이 다시 실행되어야만 한다는 것을 타나내면 다이얼로그 처리 모듈은 단계(824)로 복귀한다. 다시 말하면, 만약 사용자가 출구(exit)를 선택하면 제어는 단계(801)에서 인터페이스 툴에 대한 엔트리상에 도시된 메뉴를 다시 디스플레이시키는 메뉴 처리 모듈로 통과된다. 세번째 가능성은 단계(813)에서 다이얼로그를 즉시 실행하는 메뉴를 디스플레이시키는 처리 모듈에 제어를 통과시키는 것을 중지하도록 표시하는 것이다.

제2도에 도시된 바와같이 메뉴 부분인 각각의 오브젝트는 sm-menu-option(200)에 의해 도시된 바와 같은 구조를 가지고 있다. 만약 7개의 메뉴 아이템이 있다면 이러한 아이템은 7개의 작업을 표시하며 그러한 것을 같은 검색키를 가진 데이타 베이스에 표시된 7개의 sm-menu-option 오브젝트가 된다.

사용자가 메뉴를 통과할때 아이디어(idea)는 성취될 작업을 계속해저 정제(refinement)시키는 것이다. 각각의 후속 메뉴는 예전의 아이템의 확대된 뷰(view)이다. 이러한 후속 메뉴를 통하여, 작업은 단일 작업으로 정제될 것이다. next-id(204)는 next-id(204)가 next-type(209)에 의해 규정된 다이얼로그를 지정할때까지 next-type(209)에서 규정된 next-menu(넥스트 메뉴)를 지정한다. 정적이 아닌 메뉴와 유사하게 다이얼로그도 정적이 아니다. 다이얼로그내의 필드는 제3도에 도시된 바와같은 형태 sm-command-option(300)의 오브젝트이며, 그러한 것은 검색 기준을 충족시킨다. 추가로, 명령의 소유자는 인터페이스 셸에 다이얼로그내의 다른 필드와 같은 검색 기준을 충족시켰던 형태(type) sm-command-option의 데이타 베이스에 새로운 인터페이스 오브젝트를 추가시키므로써 그러한 명령의 새롭게 수행된 현상을 제공할 수 있다.

sm-command-option 오브젝트(300)는 다이얼로그에 하나의 필드만을 나타낸다. 다이얼로그가 몇몇의 필드를 자졌다면, 다이얼로그에는 몇몇의 sm-command-option 오브젝트가 존재하게 될 것이다. 각각의 sm-command-option 오브젝트가(300)는 몇몇의 아이템을 가지고 있다. id(302)는 이전의 인터페이스 오브젝트에 의해 당신에게 지정된 검색 표준이다. id 시퀀스 번호(303)는 스크린상에서 어떤 시퀀스로 제공되며 id 검색 기준을 충족시키는 그러한 모든 오브젝트에 대해 규정한다. 예로, 다이얼로그가 5옵션을 갖고 있는 명령에 대응한다면, sm-command-option 오브젝트(300)중 5개를 필요로 할 다이얼로그에는 5필드가 있게 될 것이다. 각각의 오브젝트에는 1-5로 번호를 붙일 수 있다. 네임(305)은 스크린에 나타나는 필드 네임이다. 본 발명의 양호한 실시예는 NLS(내쇼날 랭귀지 서포트)를 지원하기 때문에 네임(305)은 실제로 이용되지 않느다. 대신에 번역 기능과 관련되는 3개의 필드(306,307,308)가 있다. 이들 3개의 필드는 실제 메시지 id를 포함하는 메시지 세트(307)에 있는 네임을 갖고 있는 파일 즉 카탈로그(306)를 지정한다. 이들 3개의 필드(306,307,308)는 언어 민감성 스트링 또는 콘텍스트 민감성 아이콘을 추출하는데 이용된다. 단지 이들 3개의 필드가 0이거나 또는 메시지 기능이 고장이라면 실제 name 필드(305)가 이용된다.

type(309)은 인터페이스, 오브젝트에 의해 표시되는 속성을 표현하는데 이용되는 방법이다. type(309)은 필드 타입 즉 필드가 숫자 필드, 텍스트 엔트리 필드, 또는 옵션이 유한(finite)한 링 필드 등으로서 관리되는지를 판정한다. 링 필드에서 사용자는 텍스트를 입력시킬 수 없지만 단기 가용한 옵션을 통해 증대시키기 위해 반복해서 키를 대릴 수 있다. 다른 타입의 필드는 파일 필드라 칭한다. 파일필드(file field)는 사용자가 엔터되면 에러가 발생되는 경향이 있는 네임을 공지된 파일로부터 선택할 수 있게 해준다. 요구되는 아이템(310)은 파일이 모든 명령 실행시 전송될 필요가 있는지를 지정한다. 이는 단지 사용자가 바뀐 필드만이 전송되기 때문에 필요하다. 이는 디폴트를 재설정해야 하는 것을 방지해준다. 그러나 어떤 필드는 사용자에 의해 바뀌었든 그렇지 않든간에 항상 전송되어야만 하기 때문에 요구된 아이템(310)이 필요하다. prefix 필드(311)는 일반적으로 이러한 옵션으로 이루어지는 플래그이다. 그것이 사용자에게 표시되지 않을지라도, 프리픽스 필드는 명령을 구성하는데 실제로 이용되는 것이다.

정규의 오퍼레이팅 명령인 리스트(312)에 대한 명령은 한 필드에 대한 가능한 후보들을 리스트하는데 이용된다. 사용자는 커서는 상기 필드에 걸쳐 이동시킬 수 있고 상기 필드에 관한 LIST를 요구할 수 있고 가능한 값 모두를 얻을 수 있다. 리스트( 312)에 대한 명령은 스탠다드 아웃을 산출하는 명령이다. 예로, 사용자가 프린터로의 출력을 프린터하기를 원하나 이용 가능한 프린터의 네임을 기억할 수 없다면, 사용자는 LIST를 선택할 것이다. 인터페이스 툴은 타켓 프린터의 네임을 요청하는 sm-command-option(300)과 관련된 리스트에 대한 명령을 실행할 것이다. 이러한 리스트에 대한 명령이 실행된 명령의 스탠다드 아웃을 스크린으로 직접 보내는 대신에 명령 라이상으로 입력될 수 있는 동일한 명령일지라도, 그것은 상기 인터페이스 툴에 의해 수집되어져서 리스트 패널(4)에 제공되다. 명령 그 자체는 이러한 식별에 민감하지 않다. 이때 사용자에게는 모든 지지된 형태의 프린터의 리스트가 제공될 것이다. 사용자는 필요한 값을 제공하는 이 리스트로부터 선택할 수 있다. 리스트(312)에 대한 명령은 리스트에 대한 명령의 실행을 보증하지 않는 시퀀셜 리시트 숫자와 같은 몇몇 아이템이 있기 때문에 항상 제공될 수 없다.

값 아이템(314 내지 318)은 현재값 아니면 디폴트값을 가리킨다. 예로, 사용자 타스크가 프린터의 형태값을 바꾸는데 관련되어 있다면, 사용자는 현행 값 및/또는 디폴트값을 알아야 할 필요가 있을 것이다. 다시, 메시지 퍼실리티에 관련되는 필드(316 내지 318)는 이들 값이 상술한 바와같이 NLS 이기 때문에 사용된다. 예로, 값(315)이 "예" 또는 "아니오" 값을 갖는다면, 이들 값에 대한 올바른 랭귀지가 사용자에게 표시될 것이다. 값 인덱스(314)는 링에 있는 값이 먼저 제공되는 I/O 루틴을 가리킨다. 값 인덱스가 0이라면, 0번째 엘리먼트가 먼저 제공된다.

오퍼레이팅 시스템 명령어에 전송되는 값들이 다소 암호적(cryptic)이기 때문에 aix-value(319)가 사용된다. aix-value(319)는 형태에서 디스플레이값(315)과 같은 포맷을 갖고 있지만, 내용에 있어서는 다르다. 예로, 자연 언어 지원시 표시값이 "edge" 및 "center"라면, 오퍼레이팅 시스템 명령어는 실제로 이들 값을 이용하지 않는다. 값 "edge" 및 "center"는 환경이 영어를 가리킨다면 사용자에게 표시되는 값이지만, 오퍼레이팅 시스템 명령어에 의해 이용되는 값들은 "e" 및 "c"일 수 있다. 사용자가 제2값을 선택한다면, 인터페이스는 제2 aix-value로 오퍼레이팅 시스템 명령어를 만든다. 헬프 메시지 id(320)는 개개의 아이템 각각에 대한 콘텍스트상의 헬프이다.

이하 명령어를 만드는 것에 대한 설명을 하기로 한다. 인터페이스 툴은 값의 수집을 위해 2패스 모델을 이용한다. 제1패스는 데이타 오브젝트값 모두를 순서있게 모으며, 그것의 prefix 필드(311)는 널(null) 스트링 또는 플래그 예로 "-f" 이다. 이들은 위치 결정이 민감치 않으며 즉시 명령어 네임을 따르는 파라미터, 제2패스는 값 모두를 순서있게 모으며, prefix 필드(311)는 반전된 스트링 "‥" 이다. 이들은 위치 결정이 민감한 파라미터이며 제1패스에서 수집된 플래그 옵션을 따라야만 한다.

바로 앞의 네임 선택기에서 수집된 스트링을 패스하기 위한 특정 매카니즘이 필요하다. 스트링은 "rawname" 즉 사용자에 의해 선택된 것 또는 "cookedname" 즉 com-to-classify(614)의 출력일 수 있다. 이 (raw/cooked) 네임은 그를 위해 규정된 데이타 오브젝트를 가져야만 하는 값이다. 그것은 다이얼로그에서 통상 제1오브젝트일 수 있다. 선택돈 순간의 스크린상에 나타나는 것((raw/cooded)name)은 명령어의 구축을 용이하게 하는 다이얼로그의 이용도를 증가시킨다. (raw/cooDed)네임은 플래그보다 선행될 수 있고 그렇지 않을 수도 있다.

(raw/cooked) 네임이 플래그를 갖고 있다면, 그를 위해 할당된 데이타 오브젝트 sm-cmd-option은 프리픽스 필드에 있는 적당한 플래그로 초기화될 것이다. disp-values 필드가 전체로서 다이얼로그를 위해 수행될 수 있는 임의의 cmd-to-discover로부터 초기화된지 않기 때문에, dis-fidld-name은 상기 값이(raw/cooked)네임으로부터 취해져야만 한다는 것을 가리키는데 이용될 수 있다. 이는 후자의 필드를 반전된 값 "rawname" 또는 "cookedname"으로 초기화시키므로서 실행된다. 요청된 필드를 "yes"에 초기화시키면 다이얼로그에서 변화가 없을지라도 네임이 그것의 플래그를 따라서 명령어로 전송된다. 이는 거의 항상 no 엔트리 필드로 만들어져야 한다. 그러한 값들은 위치 결정이 민감치 않으며 상술한 제1패스에서 픽업될 것이다.

(raw/cooked)네임이 플래그를 갖고 있지 않다면, 그를 위해 할당된 데이타 오브젝트 sm-cmd-option은 프리픽스 필드에서 "‥"로 초기화될 것이다. disp-values 필드는 전체로서 다이얼로그를 수행할 수 있는 임의의 cmd-to-discover 로부터 초기화되지 않을 것이기 때문에, disc-field-name은 상기 값이(raw/cooked)네임으로부터 취해져야만 한다는 것을 가리키는데 이용될 수 있다. 이는 반전된 값 "-rawname" 또는 "-cookedname"으로 후자의 필드를 초기화시키므로써 실행된다. "yes"로 요청된 필드를 초기화시키면서 상기 네임이 다이얼로그에서 바뀌지 않을지라도 상기 네임은 명령어로 전송된다. 이는 거의 항상 no 엔트리 필드를 만들어야만 한다. 이들 값들은 상술한 바와같이 제2패스에서 픽업된다. 이들이 서로 위치 결정이 민감한 vis-a-vis 이기 때문에, 이들은 필요한 시퀀스로 다이얼로그에서 나타난다.

value-index(314)는 헤더 오브젝트 클래스(400)로부터 채워진다(제4도). 헤더 오브젝트(400)는 오퍼레이팅 시스템 명령을 실행하는 필드(412)를 발견하기 위한 명령어를 갖고 있다. 이러한 명령어로부터 출력되는 것은 인터페이스 툴에 의해 포획되어 다이얼로그를 만드는 sm-command-option 오브젝트(300)의 어레이에서 표시값 필드(315) 모두에 대한 값으로 채우는데 이용된다. 예로, "프린터 특성 변화"에 대한 명령헤드(400)가 있다면, command-to-discover는 프린터의 현재 특성을 발견하기 위해 실행된다. command-to-discover로부터의 출력은 값들을 개개의 인터페이스 오브젝트에 관련시키기 위해 인터페이스 툴에 의해 파스(parse)로 된다. 예로, 보 속도(baud rate)가 헤더에 의한 출력에서 BR로 나타난다면, 상기 컬럼에서의 값은 discover-field-name(304)이 스트링 BR인 인터페이스 오브젝트와 연관된다. 그러므로, 인터페이스 셀(shell)은 데이타 처리 시스템의 현재 상태를 근거로 동적으로 구성된다. 현재 상태를 질의하는 명령어로부터의 출력은 사용자에게 나타난다. 사용자는 표시된 현재 상태값 또는 선택/엔터 다른 값들을 이용할 수 있다. 명령어는 현재 데이타 및 사용자 규정 데이타의 조합을 근거해 구축된다.

제4도에서, 다이얼로그 헤더 오브젝트 클래스(400)는 다이얼로그를 구성하는 인터페이스 오브젝트를 가르킨다. id(402)는 검색 id이다. 또한 헤더는 또다른 키필드 command-to-eec(408)이다. command-to-exec는 다이얼로그가 실행하는 명령이다. command-to-exec는 또한 로그되는 명령이다. 단지 후보들을 리스트하기 위해 사용되거나 현재상태, 래터럴 또는 퍼실리테이팅 명령을 발견하기 위해 사용되는 명령은 로그(log)되지 않는다. 래터럴 명령들은 시스템 데이타를 판독한다. 종료 작업은 다이얼로그 헤더(400)에서의 command-to-execute(408)이다. 이와같이, 로크는 사용자가 기계를 구성하는 것을 돕기 위한 정보를 수집하기 위해 사용되는 명령 이외에 사용자가 기계를 구성하기 위해 실제로 사용되는 명령만을 포함한다. command_to_execute 명령을 로킹(logging)함으로써, 사용자 로그를 재실행할 수 있으며, 계속해서 동일 구성을 정확히 얻을 수 있다.

헤더 오브젝트(400)에서 고스트(ghost) 특징(411)이 스크린에서 I/O가 없음을 나타낸다. 어떤 인스턴스에서, 사용자와 함께 하는 다이얼로그는 필요치 않으나, 본 발명의 인터페이스 툴이 데이타 구동되기 때문에, 다이얼로그 오브젝트가 존재한다.

상기 설명은 제5a도에 도시한 바와 같이 인터페이스 툴의 블럭도에서 예증된다. 예를 들면, 사용자가 데이타 처리 시스템에서 논리적 볼륨 매니저에 관한 시스템 관리 타스크들을 수행하기를 원한다면, 이를 수행하기 위해 사용된 모델이 제5a도에 도시된다. 매뉴 1A는 사용자가 선택할 수 있는 모든 논리적 볼륨 작업을 포함한다. 어떤 보다 일반적인 타스크들은 ADD(501), SHOW(502), DELETE(503), CHANGE(505) 및 LIST ALL(506) 등을 포함한다. ADD(501) 모델에서, 사용자는 논리적 볼륨 매니저 메뉴 1A도에서 ADD를 선택한다. 다이얼로그로 바로 진행한다. 그것은 디폴트를 발견하는 command_to_discover이다. 사용자는 선택된 ADD(501)을 갖고 있기 때문에 사용자는 기준 시스템 자원을 이용하지 않으며, 그러므로 현행 정보가 존재하지 않는다. 디폴트의 발견과 현행 세팅의 발견 사이의 분별은 인터페이스 셸의 기능상 중요한 것은 아니다. 사용자는 정보로 다이얼로그를 채우고 ADD command_to_exec을 실행한다.

SHOW(520) 타스크를 이용할때에, 사용자는 시스템 자원의 특성을 알기를 원한다. 그러므로 인터페이스는 이러한 시스템 자원ㅇ르 알려주어야 할 순간을 인식해야만 한다. 그러므로, sm_name_select 오브젝트(601)이 필요하다. 이 예에서 필드는 "논리적 볼륨의 네임 "을 사용자에게 제공할 것이다. 사용자가 원하는 그 네임을 알았다면, 사용자는 그 네임을 필드에 입력시킬 것이다. 네임 선택 오브젝트(601)는 리스트(612,613)를 갖고 있기 때문에 인터페이스는 사용자가 선택할 패널에 있는 논리적 볼륨의 네임들을 리스트하기 위해 오퍼레이팅 시스템 명령을 이용한다.

SHOW 명령의 다른 실행을 위해서 다이얼로그가 필연적인 것은 아니다. 그러나, 이 예가 보여주듯이 사용자가 알기를 원하는 시스템 자원에 대해서는 여러 견해가 있을 수 있다. 이들 여러 뷰(view)는 SHOW(502)에서 여러 실행 파라미터로 표현된다. 이들 여러 실행 파라미터에 대한 다이얼로그는 사용자가 제한된 양의 데이타를 선택해서 보든가 모든 데이타를 선택하여 볼수 있고 또한 리스트가 어떻게 보여져야 하는지 등을 지정할 수 있게 해준다. 사용자는 이들 결정을 하고, 명령을 실행하여 데이타를 보여주는 스크린에서 출력을 수신하기 위하여 다이얼로그와 대화한다.

sm_name_select 오브젝트(601)는 또한 사용자가 삭제될 시스템 자원의 네임을 인터페이스 셸에 가리켜야만 하기 때문에 DELETE(503) 타스크에 이용된다. 그러나, 다이얼로그 헤더 오브젝트(400)는 실제로 고스트이다. 고스트 다이얼로그는 스크린에 대한 I/O가 없다는 것을 의미한다. 다이얼로그는 부가의 정보가 필요없기 때문에 사용자에게 제공되지는 않는다. 그러나, 시스템 자원의 삭제가 여러 펑크션(예로 능동 이용은 삭제하나 완전히 삭제하기 위한 것과는 정반데로 보유 파일에 info를 세이브함)을 갖고 있다면, 스크린 다이얼로그는 사용자가 원하는 것을 요청할 것이다. 고스트와 관련된 다이얼로그 오브젝터(300)는 없다. 헤더는 종료 명령을 실행하기에 충분하다.

다이얼로그 헤더 오브젝터(400)에는 "ask"(490) 필드가 있다. "ask"(409) 필드가 턴온된다면 즉 참으로 세트된다면 다이얼로그는 사용자에게 "are you sure?"를 표시할 것이다. 이러한 요청 펑크션은 사용자가 아이템을 삭제하기 위하여 실로 어느것을 실행해야 하는지를 입증할 수 있게 해주기 때문에 삭제와 같은 그러한 타스크로서 유용하다. 사용자가 "yes"를 선택한다면, DELETE command_to_execute(503)이 실행된다. 사용자가 선택하지 않는다면 명령은 실행되지 않는다.

ADD 타스크와 같지 않는 CHANGE 타스크의 실행에 있어, 바뀔 시스템 자원이 존재한다. sm_name_select 오브젝트(601)는 오브젝트의 네임을 얻는데 이용된다. command_to_discover는 실행되고, 시스템 자원의 속성의 현행값은 발견되고, 이들 현재값들 및 속성은 사용자에게 다이얼로그로 표시되며, 사용자 응답들은 수집되고, CHANGE command_to_execute(505)가 실행된다.

sm_name_select(601)은 여러 종류의 시스템 자원의 인스턴스의 모든 네임이 이용되기 때문에 LIST ALL 타스크(506)를 요구하지 않는다. 다이얼로그는 사용자가 이 명령어에 다른 임의 지시를 줄 필요가 없기 때문에 고스트 다이얼로그이다. 그러므로, LIST ALL command_to_execute은 즉시 실행되고 사용자는 스크린으로의 출력을 수신한다. 고스트 다이얼로그는 통상적으로 사용자와의 대화를 위한 스크린에 대한 I/O가 없다는 것을 의미한다. 그러나, 다이얼로그 오브젝트(400)는 command_to_execute(408)이 이러한 구조내에 있기 때문에 필요하다.

제5b도에는 상기 시스템에 있는 프린터 또는 다른 물리적 디바이스를 관리하기 위한 인터페이스 툴에 관하여 좀더 복잡한 예가 도시되어 있다. 프린터를 부가하기 이하여 논리적 볼륨과는 달리 모든 프린터들이 동일하지 않기 때문에 네임 선택 오브젝트(601)가 필요하다. 즉 프린터들은 상이한 형태이다. 그러므로 어느 다이얼로그 오브젝트(400)가 이용되는지를 타입이 네임 선택(601)이 퍼실리티에서 규정될 때까지 알려지지 않는다. 예로, 타입 A 프린터를 부가하기 위하여 한 세트의 질문이 다이얼로그에 필요한 한편 타입 B 프린터가 부가된다면 또 다른 세트이 질문이 다이얼로그에 필요하게 된다. 그러므로, 옮바른 다이얼로그 오브젝트(400)에 도달하기 위하여 네임 선택 오브젝터(601)는 사용자에게 프린터의 타입을 요청해야 한다. sm_name_select에 있는 네임(604)을 이용하는 여러 방법이 있다. next_id(603)에 가리켜져 있는 스트링은 다이얼로그 헤더(400)용 실제 검색키일 수 있고, 이 경우에 네임값은 중요한 것이 아니다. 그러나, 이 네임은 다음 다이얼로그 헤더(400)를 발견하는데 필요할 수 있다. 예로, 사용자가 취급한 프린터의 타입을 알고 있지 못하다면, 사용자는 모든 지원된 프린터의 리스트를 얻기 위해 LIST를 선택할 수 있다. 이 경우에, 인터페이스는 적당한 다이얼로그 오브젝트(400)를 발견하기 위한 "타입"을 취한다. 그러나 지지된 프린터 타입을 바꾸는 대신에 CHANGE(505) 작업을 실행하기 위하여, 사용자는 시스템 자원, 예로 프린터의 타입의 특성을 바꿀 필요가 있다. 이러한 인스턴스의 네임은 사용자에 의해 규정되었을 수도 있고, 이는 사용자의 머신에 대한 지정일 것이다. 이는 어떤 타입을 필히 표기해야 할 필요는 없다. 사용자가 머신 지정 타임을 필히 표기해야 할 필요는 없다. 사용자가 머신 지정 네임을 기억할 수 없다면, 사용자는 가능한 수단을 리스트할 필요가 있다. 그러나, 리턴된 리스트는 타입 네임을 가지고 있지 않을 것이지만 사용자 지정 네임을 가지고 있을 것이다.

이러한 네임을 인터페이스 셸이 올바른 다이얼로그 헤더 오브젝트를 찾기 위하여 이해할 수 없는 것이다. 이들 사용자 지정 네임이 보편적이 것이 아니기 때문에, 인터페이스 툴은 이들 사용자 지정 네임 각각에 임의 선정이 된 다이얼로그 오브젝트(400)를 제공할 수 없다. 대신에 sm_name_select 오브젝트내에는 사용자 지정 네임을 프린터 타입에 상관지워주는 command_to_classify(614)가 있다. 이때 command_to_classify는 올바른 대응 다이얼로그 오브젝트(400)를 찾기 위하여 네임을 검색 필드에 연결시켜 준다.

프린터에 대한 SHOW 타스크(502)를 실행하기 위하여, sm_name_select(602)는 사용자가 정보를 원하는 프린터 인스턴스 네임을 지정하는데 이용된다. 수집할 필요가 있는 더 이상의 정보가 없기 때문에, SHOW 명령은 선택된 네임을 이용하여 직접 실행되고, 그 출력은 스크린상에 표시된다.

제5b와 a도를 비교해보면, 제5a도에 도시된 바와 같이 다이얼로그는 네임 선택 오브젝트(601) 후에 이용되었다. 다이얼로그가 네임 선택을 계속해야 하는지 그렇지 않는지를 명령하는 오브젝트 그 자체에 대해서는 아무것도 없다. 대신에, 그것은 명령어와 어떻게 이 명령이 실행되어야 하는지에 달려있다. 예로, 몇몇 경우에, 도시될 수 있는 디바이스는 아주 복잡할 수 있고 많은 수의 여러 속성들을 갖고 있을 수 있다. 이들 경우, 다이얼로그를 SHOW 명령에 부가하면 사용자는 어느 속성을 도시해야 할지를 선택하고 어느 방법을 이용해야 할지를 선택할 수 있다.

예로, 다이얼로그, 사용자는 SHOW 명령을 어떻게 실행해야 할지를 지정하기 위하여 "quick search", "show all fields", 또는 "show only specified fields"등을 지정할 수 있다. 많은 속성들이 없는 좀더 간단한 디바이스에 대하여, 이 디바이스에 관한 정보 모두를 보여주는 것은 단지 네임과 디바이스 타입을 보여주는 것을 포함한다. 이보다 간단한 경우에, 다이얼로그는 사용자가 네임 선택기로 시스템 자원의 인스턴스를 가리켜준 후에 모든 정보가 제공되기 때문에 필요치 않다.

네임 선택기 오브젝트(601)가 메뉴 오브젝트 클래스(200) 다음에 이어지면, 메뉴 대상 클래스(200)에서 next_type 필드 (209)는 네임 선택 오브젝트를 지정할 것이다. 다이얼로그(400)가 메뉴 뒤를 바로 따른다면, next_type 필드(209)는 다이얼로그 오브젝트를 지정할 것이다. 또 다른 메뉴 오브젝트가 상기 메뉴를 바로 따른다면, 메뉴 오브젝트에서 next_type 필드(209)는 또 다른 메뉴 오브젝트를 규정할 것이다. 인터페이스 툴은 메뉴를 얻기를 계속하여 "nexs_type" 필드가 네임 선택(601) 또는 다이얼고르(400)를 규정할 때까지 이들 동일한 루틴을 통항 순환을 유지한다.

제5b도에는 "통신"메뉴 1B가 CHANGE 작업에 대한 네임 선택(601)을 이끄는 것이 도시되어 있다. 이는 단지 이들 작업과 액션 모두가 또 다른 메뉴에도 표시될 수 있음을 보여준다. 또 다른 메뉴는 그것의 다음 ID 필드(603)(제6도)가 다른 메뉴 1A와 동일한 서치 크리터리어를 갖고 있다면 이들 오브젝트중 임의 하나를 지정할 수 있다.

상세한 설명으로 알 수 있들시 각각의 작업(SHOW, ADD, DELETE, CHANGE, LIST ALL에 제한되지 않음)은 전적으로 데이타 구동된다. 수행되는 코드는 실행될 명령 즉 어떤 필드로 정보가 수집되는지, 어떤 경로로 해서 이루어지는지, 앞서 실행된 단계, 또는 실행된 다음 단계에 의존하지 않는다. 오브젝트, 메뉴, 네임, 선택 및 다이얼로그를 통한 명령 모두와 명령 실행은 데이타내에 포함되어 있지만 코드로 되어 있지 않다. 메뉴, 또는 다이얼로그 또는 네임 선택을 나타내는 제1오브젝트가 구축될때, 오브젝트의 트래버스내의 다음 오브젝트는 제1오브젝트 그 자체내에서 지정되며, 이러한 것은 본 발명의 인터페이스 툴을 포함하는 오브젝트 전체를 통해 반복적으로 이루어진다.

본 발명의 인터페이스 툴을 메뉴 다이얼로그, 타스크 및 명령을 포함한 펑크션의 실행이 코드내에서 선정이 되는 것 대신에 데이타 구동되는 것을 허용하는 모든 메뉴 및 다이얼로그의 타입과 함께 사용될 수 있다.

양호한 실시예는 데이타 처리 시스템내의 시스템 관리 펑크션들 대한 인터페이스로서 상기 인터페이스 툴을 이용한다. 시스템 관리 퍼실리티의 한 펑크션은 시스템 자원을 위한 구성 타스크를 제공하는 것이다. 예로, 하드디스크 드라이브, 프린트, 디스플레이 등과 같은 새로운 디바이스가 시스템에 부가된다면, 이러한 새로운 디바이스는 조만간 구성될 것이다. 사전에 상기 시스템의 제조자는 시스템의 구성 퍼실리티로 제공된 메뉴와 코드로 디바이스의 가능한 재구성을 고려해야만 한다. 이러한 시스템의 인터페이스 툴로, 디바이스의 제조자는 시스템의 제조자로부터 사전 자원을 얻지 않아도 된다. 시스템에 관한 새로운 디바이스를 관리하기 위하여 코드가 바뀌어서는 안되고 코드가 재컴파일되어서도 안된다. 디바이스를 시스템에 부가하기 위하여, 새로운 인터페이스 오브젝트는 디바이스용 디바이스 구동 코드로 설치된다. 새로운 디바이스 인터페이스 오브젝트는 단지 사용자에게 디바이스 관리 능력을 주기 위하여 한 메뉴로 나타날 필요가 있다. 새로운 디바이스의 관리 작업을 제공하는 분기는 메뉴를 제공하는 다른 메뉴 인터페이스 오브젝트와 동일한 검색 키를 갖고 있는 메뉴 인터페이스 도브젝트에 의한 메뉴에 관해서 나타난다. 새로운 오브젝트 디바이스는 구성 퍼실리티가 사용자에 의해 수행된 넥스트 타임에 이러한 새로운 디바이스가 시스템 관리 인터페이스 툴의 일부였던 것처럼 나타나도록 데이타 저장소에 부가될 것이다. 이때 이러한 새로운 디바이스는 시스템 관리 인터페이스에 다른 모든 디바이스와 동일하게 참가할 것이다.

제1b도를 보면, 모든 오브젝트, 즉 메뉴 오브젝트(200), 다이얼로그 오브젝트(300), 다이얼로그 헤더 오브젝트(400) 및 네임 오브젝트(600)는 오브젝트 데이타 매니저 레코드(30)로서 라벨이 붙은 오브젝트 지정된 데이타 베이스내에 포함되어 있다. 시스템 관리 인터페이스를 툴(10)은 오브젝트 데이타 매니저(10)로부터 톱 매뉴 오브젝트를 얻으므로써 시작한다. 동일한 id(202(제2도)를 갖고 있는 모든 오브젝트는 오브젝트 데이타 매니저 데이타베이스(30)로부터 검색되어 인터페이스 툴(10)에 의해 표현된다. 이러한 관점에서, 오브젝트(메뉴, 네임, 다이얼로그)를 통한 트래버설(traversal) 및 오브젝트로 부터의 데이타 제공은 레코드 즉 오브젝트 그 자체내의 데이타에 의해 결정된다.

이는 제7도를 참조하여 설명된다. 톱 메뉴(701)는 그것의 필드들중 하나가 "DEVICES"(205)로서 표시된 실제 텍스트(205)를 포함하는 곳에 도시되어 있다. 명령을 실행하고 파라미터 및 옵션의 엔트리를 용이하게 하기 위해 인터페이스 툴을 이용하길 원한다면, 인터페이스 툴은 파라미터로서의 명령 네임으로 유발될 수 있다. 이 파라미터는 상기 명령을 실행하는 다이얼로그 헤더 인터페이스 오브젝트의 id이다. 이러한 제2억세스 방법은 패스트 통로 방법이라 불리어지고 있고, 모든 오브젝트는 id를 갖고 있는 덕분으로 인터페이스 툴의 유발 파라미터로서 id를 통과시키는 사용자에 의해 상기 신속 경로 방법으로 접근할 수 있다. 이때, 인터페이스 툴은 전송된 파라미터의 id를 갖고 있는 오브젝트를 검색한다. 인터페이스 툴은 먼저 주어진 id를 갖고 있는 다이얼로그 헤더 오브젝트를 검색한다. 발견되면,대응하는 다이얼로그 인터페이스 오브젝트는 스크린 라이브러리에 전송되어 제8도의 단계(814)에서와 같이 사용자에게 제공된다. 이러한 처리는 상술한 바와 같이 계속된다. 다이얼로그 헤더가 발견되지 않으면, 인터페이스 툴은 주어진 id를 갖고 있는 네임 선택기 오브젝트를 검색한다. 다이얼로그가 네임 선택기에 의해 선행된다면, 코맨드 네임은 다이얼로그 헤더라기 보다 네임 선택기의 id이다. 네임 선택기 오브젝트가 발견되면, 처리는 상술한 바와 같이 단계(808)로 계속된다. 마지막으로, 인터페이스 툴은 주어진 id를 갖고 있는 메뉴를 검색한다. 만약 메뉴가 발견되면, 처리는 상술한 바와 같이 단계(801)로 계속한다. 어떤 명령들이 하나 이상의 다이얼로그에 의해 표현되기 때문에, 파라미터로서 명령 네임을 통과시키기는 것은 단일 다이얼로그에 대한 분명한 참조로서 취해질 수 없다. 그러므로, 명령 네임은 명령어의 모든 유형의 인스턴스를 나타내는 계층에 있는 최하위 오브젝트의 id이다. 대부분의 경우에, 이는 다이얼로그 헤더이나 메뉴일 수도 있다.

이러한 신속한 경로 방법의 또 다른 양상은 제9a,b 및 c도에 도시되어 있듯이 에일리어싱(aliasing)이라 칭한다. 하나 이상의 신속한 경로 토큰은 상기 계층에서 동일한 노드를 가리켜야 한다. 하나의 토큰(token)은 오브젝트의 실제 id이며, 이 오브젝트를 통해 상기 계층이 위에서 아래로 트래버스된다면 한 토큰이 통과한다. 상기 계층에는 없는 다른 토큰은 상기 계층에 있는 상기 토큰을 가리킨다. 에일리어스는 항상 메뉴 인터페이스 오브젝트(200)이며, 이의 에일리어스 필드(201)는 참값이다. 인터페이스 툴은 에일리어스가 가리키는 메뉴 오브젝트를 발견하여 이는 마치 그것이 선택되었던 것처럼 처리된다. 이는 제8도의 스텝(804)에서 처리가 시작될 수 있게 해준다. 이러한 식으로, 에일리어스는 제9a도에 있는 메뉴, 제9b도의 네임 선택기, 또는 제9c도의 다이얼로그에 있는 계층을 가리키는데 이용될 수 있는 한편 이는 실제로는 상기 계층의 바깥이 존재한다.

상기 설명은 인터페이스 툴 계층내로의 신속한 경로를 기술하고 있다. 또한 틀에서 명령 셸로 탈출하기 위한 퍼실리티가 존재한다. 상기 명령 셸로부터 다른 응용 또는 명령은 사용자가 탈출하는 인터페이스내의 포인트로 복귀하기 전에 실행될 수 있다.

제1b도에 도시되어 있듯이, ASL 층은 정보를 사용자에게 제공하고 사용자 응답을 수집하는데 이용된다. ASL 층은 인터페이스 툴이 텍스트 또는 그래픽 라이브러리에서 차이점을 취급하지 못하게 하는 스크린 라이브러리 층이다. 몇몇 표시 라이브러리(22,23)는 여러 표시 스타일을 만들수 있게 교환될 수 있다. 타켓트 그래픽 라이브러리는 개시 시간에 사용자에 의해 선택될 수 있거나 또는 외부 환경 변환에 근거하여 선택될 수 있다. 이들 다른 지원 라이브러리는 그래픽 및 텍스트를 사용자에게 제공하는 것을 포함할 수 있다. 이용된 표시 인터페이스(20)에 관계없이, 오브젝트 데이타 매니저 데이타베이스내의 동일한 오브젝트들이 이용된다. 이 데이타베이스내의 데이타 오브젝트들은 단지 한번 정의된다. 각각의 그래픽 라이브러리는 오브젝트로부터 사용자에게 정보를 제공하는데 그 자신의 심볼을 이용할 수 있다. 이들 교환 가능한 그래픽 인터페이스는 단지 여러 가시적 방법으로 인터페이스 툴로부터 동일한 정보를 표시할 수 있다.

인터페이스 툴이 ALS 층에 의한 그래픽 라이브러리에 있는 차이점에 관계없이 되어 있을지라도, ALS 층은 어떤 연속성을 강제하며 ALS에 바운드된 그래픽 라이브러리에 관계없이 공통적인 기능을 제공한다. 하나의 그러한 펑크션은 논리적 프레임 표시가 물리적 표시 영역의 사이즈를 초과할때 이용된다. ALS 층을 사용자에게 임의 방향으로 스크린을 스크롤 오프된 엘리멘트(데이타 오브젝트)의 수를 보여준다.

여러 시스템에 대해 허가받은 몇몇 시스템 매니저에 의해 억세스 가능한 여러 논리적 프레임 표시는 억세스 제어 원칙을 인터페이스 오브젝트에 제공하므로써 제어될 수 있다. 억세스 제어 원칙은 오브젝트에 제공하는 방법은 1984년 5월15일에 R.A. Fabbio의 이름으로 출원된 발명의 명칭이 "오브젝트 재생된 데이타 베이스용 억세스 제어 원칙"인 07/808,060(IBM interal docket number AT9-89-038)에 좀더 기술되어 있다. 이들 억세스 제어 원칙들은 각각의 인터페이스 오브젝에 적용될 수 있다. 메뉴 인터페이스 오브젝트, 네임 선택 인터페이스 오브젝트, 또는 다이얼로그 인터페이스 오브젝트는 인터페이스 툴이 동작할 때 사용자가 인터페이스 오브젝트에 부착된 억세스 제어 리스트내에 있는 사람들과 일치하지 않으면 발견되지 않을 것이다. 여러 인터페이스 오브젝트 각각은 오브젝트 데이타베이스에 있는 단지 하나의 위치에 저장되고 관리적인 뷰(view) 여러 교환이 뷰내의 오브젝트용 억세스 제어 폴리시에 의해 이루어지게 적당한 억세스 제어가 할당된다. 예로 매니저 A는 TCP/IP, 디바이스 및 사용자의 구성 가능한 도메인을 제공하는 사용자 인터페이스 오브젝트를 위한 특권을 판독, 기록 및 실행할 수 있는 한편 매니저 B는 STCP/IP, SNA, 디바이스, 사용자 및 시스템의 구성 가능한 영역을 제공하는 사용자 인터페이스 오브젝트를 위한 특권을 판독, 기록 및 실행할 수 있다. 그러므로, 메뉴, 다이얼로그 및 옵션을 테일러(tailor)하는 것이 가능하므로, 각각의 매니저는 사용자 인터페이스를 정의하는 여러 오브젝트에 관한 적당한 억세스 제어 원칙을 설정하므로서 서로 영향을 끼친다.

다른 보안 방법은 인터페이스가 실행하는 명령어 각각으로 구성되기 때문에 인터페이스 툴내에 내재한다. 인터페이스 툴은 이들 오브젝트 그 자체를 바꾸는 것 보다는 오히려 시스템 자원 오브젝트를 바꾸기 위한 명령을 이용하기 때문에, 명령된 임의 보안 필터는 인터페이스 툴이 상기 명령을 실행할때 자동적으로 적용될 것이다. 인터페이스 툴의 사용자가 명령을 실행할 수 있는 권한을 갖고 있지 않다면, 명령어 그 자체는 그 명령의 실행을 하지 못하게 할 것이며, 인터페이스 툴이 상기 명령이 실행될 수 없다는 것을 사용자에게 에러 메시지로 복귀해준다.

양호한 실시예가 구성 타스크 및 명령을 참조하고 있을지라도, 특정 명령은 인터페이스 툴의 일부가 아니다. 각각의 명령어는 단지 다이얼로그 헤더 인터페이스 오브젝트내의 실행 필드에 대한 명령어로 된 스트링이다. 인터페이스 툴에 대한 하나의 명령어는 임의 다른 명령어와 동일하다. 여러 명령어를 실행하기 위하여 인터페이스 툴내에는 특정 코드가 포함되어 있지 않다.

그러므로, 인터페이스 툴을 위한 엔진 모델은 시스템 관리 펑크션들뿐만 아니라 실행될 필요가 있는 임의 펑크션에도 적용될 수 있다. 다른 펑크션들, 명령들 및 타스크는 노트(note) 등을 전소하는 메일을 판독하는데 필요한 것들을 포함할 수 있다. 임의의 종료(end) 사용자 타스크는 단지 오브젝트 데이타 매니저 데이타 베이스내의 인터페이스 오브젝트에 부가하므로서 상기 인터페이스 툴로 실행될 수 있다.

본 발명은 양호한 실시예를 참조하여 설명되고 도시되었으므로 본 발명 분야에 숙련된 사람이면 본 발명의 사상 및 범위를 벗어나지 않고도 여러 형태의 변형을 할 수 있을 것이다.

Claims (26)

1. 데이타 처리 시스템을 사용하는 사용자에 의해 선택된 아이템들을 표시하는 수단(means for presenting item)과 상기 선택된 아이템들을 실행하는 수단(means for executing the selected items)을 갖고 있는 인터페이스에서, 오브젝트 데이타 베이스(object database)로 복수의 인터페이스 오브젝트들을 나타내는 수단과, 상기 인터페이스 오브젝트들 중 각각의 상기 다른 오브젝트내의 데이타를 토대로 상기 인터페이스 오브젝트들중 상이한 오브젝트들을 복수의 논리 프레임 표시(a plurality of logical frame presentation)과 동적으로 결합시키는 수단을 구비한 인터페이스.
2. 제1항에 있어서, 상기 복수의 인터페이스 오브젝트중 적어도 하나의 오브젝트가, 적어도 하나의 시스템 자원의 적어도 하나의 속성(attribuite)을 나타내는 인터페이스.
3. 제1항에 있어서, 복수의 인터페이스 오브젝트중 적어도 두개의 오브젝트가 상기 적어도 두 인터페이스 오브젝트 각각내에 있는 데이타를 토대로 데이타 처리 시스템의 콤포넌트 사이의 계층 관계(hierarchical relation)를 표시하는 인터페이스.
4. 제2항에 있어서, 인터페이스 오브젝트들은 각각의 상기 적어도 두 인터페이스 오브젝트들내에서 표시된 상기 계층 관계에 따라서 동적으로 결합되는 인터페이스.
5. 제1항에 있어서, 복구스이 인터페이스 오브젝트들중 적어도 하나의 오브젝트내에 있는 데이타를 토대로 상기 오브젝트들과의 사용자 대화 및 오브젝트들의 스크린 표현을 관리하는 수단을 더 포함하는 인터페이스.
6. 제2항에 있어서, 상기 사용자에게 표시하기 위한 상기 적어도 하나의 시스템 자원의 적어도 한 속성의 현재 값을 이용하기 위한 수단을 더 포함하는 인터페이스.
7. 제2항에 있어서, 상기 시스템 자원의 상기 인스턴스(instance)에 대한 이용 가능성을 사용자에게 알려주기 위하여 상기 사용자에게 표시를 위한 상기 시스템 자원중 적어도 한 인스턴스를 이용하기 위한 수단을 더 포함하는 인터페이스.
8. 제7항에 있어서, 사용자가 상기 사용자에게 표시된 상기 시스템 자원의 상기 인스턴스를 선택할 수 있게 해주는 수단을 더 포함하는 인터페이스.
9. 제2항에 있어서, 사용자 응답의 유효성에 대하여 상기 적어도 한 시스템 자원의 상기 적어도 한 속성의 현재 값을 이용하는 수단을 더 포함하는 인터페이스.
10. 제1항에 있어서, 상기 인터페이스 오브젝트들중 적어도 하나의 오브젝트내의 옵션과 적어도 하나의 사용자 입력값을 결합시키므로써 명령을 구성하는 수단을 더 포함하는 인터페이스.
11. 제10항에 있어서, 상기 구성된 명령을 실행하기 위한 수단을 더 포함하는 인터페이스.
12. 제11항에 있어서, 상기 실행된 명령어가 나중에 재실행 되도록 로깅(logging)하는 수단을 더 포함하는 인터페이스.
13. 제1항에 있어서, 상기 데이타 처리 시스템의 현재 상태, 복수의 사용자 선택 및 상기 인터페이스 오브젝트들내의 데이타를 토대로 명령을 구성하여 실행시키는 수단을 더 포함하는 인터페이스.
14. 제1항에 있어서, 상기 사용자 선택된 아이템에 응답하여 상기 오브젝트 데이타 베이스로부터 상기 오브젝트들을 검색하는 수단을 더 포함하는 인터페이스.
15. 제1항에 있어서, 상기 인터페이스 오브젝트내에 복수의 사용자 선택 및 상기 데이타를 토대로 상기 인터페이스 오브젝트들을 상기 사용자에게 반복적으로 표시하는 수단을 더 포함하는 인터페이스.
16. 제1항에 있어서, 복수의 스크린 표현으로부터 적어도 하나의 인터페이스 오브젝트를 억세싱하는 수단을 더 포함하는 인터페이스.
17. 제1항에 있어서, 복수의 인터페이스 오브젝트들로부터 적어도 하나의 스크린 표현을 억세싱하는 수단을 더 포함하는 인터페이스.
18. 제1항에 있어서, 상기 인터페이스의 실행 섹션 동안 인터페이스내에서 인터페이스 오브젝트 데이타 베이스를 변경하는 수단과 상기 인터페이스의 동일한 실행 섹션 동안 상기 변경된 인터페이스를 반영하는 수단을 더 포함하는 인터페이스.
19. 제1항에 있어서, 적어도 하나의 새로운 인터페이스 오브젝트를 만듦으로써 상기 인터페이스 오브젝트 데이타 베이스를 변경하는 수단을 더 포함하는 인터페이스.
20. 제3항에 있어서, 상기 계층내의 복수의 위치중 적어도 하나에 상기 인터페이스 오브젝트들의 상기 계층을 직접 입력시키는 수단을 더 포함하는 인터페이스.
21. 제1항에 있어서, 복수의 그래픽 라이브러리로 상기 논리적 프레임 표시를 디스플레이하는 수단을 더 포함하는 인터페이스.
22. 제1항에 있어서, 상기 인터페이스 데이타 오브젝트내에서 그래픽 콘텍스트에 따라서 복수의 방법중 적어도 한 방법으로 상기 논리적 프레임 표시로 상기 아이템을 표현하기 위한 수단을 더 포함하는 인터페이스.
23. 제1항에 있어서, 상기 인터페이스 데이타 오브젝트내에서 언어 콘텍스트에 따라서 복수의 방법중 적어도 한 방법으로 상기 논리적 프레임 표시로 상기 아이템을 표현하기 위한 수단을 더 포함하는 인터페이스.
24. 제1항에 있어서, 상기 사용자에게 시각적 스크린 표시 외에 상기 논리적 프레임 표시로 복수의 상기 아이템을 나타내기 위한 수단을 구비한 스크린 라이브러리를 상기 사용자에게 억세싱하는 수단을 더 포함하는 인터페이스.
25. 제1항에 있어서, 상기 복수의 인터페이스 오브젝트에게 적용된 적어도 하나의 억세스 제어 원칙(access control policy)에 따라서 적어도 하나의 논리적 프레임 표시를 제공하는 수단을 더 포함하는 인터페이스.
26. 데이타 처리 시스템 을 사용하는 사용자에 의해 선택된 아이템들을 표시하는 방법에서, 오브젝트 데이타 베이스로 복수의 인터페이스 오브젝트들을 표현하는 단계와, 상기 인터페이스 오브젝트들중 각각의 상기 다른 오브젝트 각각내의 데이타를 토대로 상기 인터페이스 오브젝트들중 다른 오브젝트들을 복수의 논리적 프레임 표현과 동적으로 결합시키는 단계로 이루어진 사용자에게 의해 선택된 아이템 표시방법.

Images