KR100995199B1

KR100995199B1 - 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템 및 컴퓨터 판독 가능 저장 매체

Info

Publication number: KR100995199B1
Application number: KR1020040032922A
Authority: KR
Inventors: 제프리피. 스노버; 제임스더블유.삼세 트루허; 데일더블유. 래이; 카우시크 푸쉬파바남
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-05-12
Filing date: 2004-05-11
Publication date: 2010-11-17
Also published as: US20050004973A1; JP4889204B2; CN100464294C; CN1550982A; EP1477897A2; US7624401B2; US20040230987A1; EP1477897A3; JP2004342108A; US7620959B2; KR20040097909A

Abstract

본 발명은 명령에 대한 입력 파라미터(input parameters)들의 반영 기반 프로세싱(reflection based processing)을 제공하는 반영 기반 셸(reflection based shell)에 관한 것이다. 반영 기반 셸은 파싱(parsing), 데이터 생성(data generation), 데이터 검증(data validation), 개체 암호화(object encoding), 개체 프로세싱 및 문서화(documentation) 등을 포함한다. 반영 기반 셸은 클래스를 사용하여 입력 파라미터들의 문법을 지정하기 위한 메커니즘을 제공한다. 이러한 방법은 명령 및 적어도 하나의 파라미터를 포함하는 파싱 가능한 스트림(parsable stream)을 수신하는 단계, 명령에 대해 예정된 파라미터를 기술하는 한정적인 정보를 검색하는 단계, 예정된 파라미터의 기술에 따른 형식으로 적어도 하나의 파라미터를 저장하기 위한 개체를 생성하기 위해 한정적인 정보를 사용하는 단계 및 명령으로 개체를 전달하는 단계를 포함한다.

입력 파라미터, 반영 기반 셸, 반영 기반 프로세싱, 파싱

Description

명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템 및 컴퓨터 판독 가능 저장 매체{REFLECTION-BASED PROCESSING OF INPUT PARAMETERS FOR COMMANDS}

도 1은 본 발명의 예시적인 일 실시예에 사용될 수 있는 예시적인 컴퓨팅 장치를 도시하는 도면.

도 2는 본 발명에 따른, 반영 기반 셸 내의 파서 및 엔진을 통한 명령 라인의 프로세싱을 도시하는 기능적인 흐름도.

도 3은 본 발명에 따른, 명령에 대한 입력 파라미터의 문법을 지정하기 위한 데이터 구조의 일 실시예를 도시하는 도면.

도 4는 본 발명의 반영 기반 셸 내에서 명령 라인에 입력된 입력 파라미터들을 처리하기 위한 예시적인 프로세스를 도시하는 논리적인 흐름도.

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

402 : 클래스 식별

404 : 클래스로부터 데이터 판독

406 : RequestObject 인스턴스와

408 : RequestObject에 반영 수행

410 : 적응성 지시자들 적용

412 : 메타데이터를 사용하여 인텔리센스 제공

멀티 유저 컴퓨터 시스템(multi-user computer system)의 시스템 관리자는 매우 전문화된다. 시스템 관리의 책임을 지는 시스템 관리자는 불일치하는 구문(syntax), 에러 보고(error reporting) 등을 사용하는 명령들을 알고, 이해하도록 기대된다. 명령들이 각각의 스타일을 사용하는 여러 상이한 소프트웨어 개발자에 의해 작성되기 때문에 명령들 간에 이러한 불일치가 발생한다. 이러한 불일치는 시스템 관리자에게 어려움을 초래한다.

하나의 어려움은 명령들의 유용성(usability)과 관련된다. 불일치하는 명령들을 가짐으로써 시스템 관리자가 학습하고 사용하는 것이 더욱 어렵게 된다. 예컨대, 일부 개발자는 파라미터들 사이에 대쉬("-")를 사용하는 것을 선호하고, 다른 사람들은 전향 슬래쉬(forward slash)("/")를 선호하며, 또 다른 사람들은 다른 유일한 구문을 사용하는 것을 선호할 수 있다. 각각의 개발자들은 에러 메시지를 보고하는 그들 자신만의 스타일을 갖는다. 그러므로, 시스템 관리자는 각각의 명령에 대하여 구문을 알아야 하고, 각각의 에러 메시지에 대하여 형식을 학습해야 한다.

다른 어려움은 명령들의 유지(maintenance)와 관련된다. 예컨대, 명령들 중의 하나를 작성했던 개발자가 떠난 경우, 다른 누군가는 사용되었던 로직(logic)을 알아내야 한다. 로직을 알아내기 위하여, 다른 개발자는 코드 자체를 조사하거나, 명령에 대한 문서를 보아야 한다. 이러한 방법중 어떤 것도 바람직하지 않다.

명령을 좀더 일관성 있게 만들려는 종래의 시도는 공통적인 기능을 수행하는 루틴의 라이브러리(library)를 제공하는데 초점을 맞추었다. 이러한 라이브러리가 라이브러리 루틴에 의해 제공되는 공통적인 기능들을 수행하기 위해 사용되는 코드의 양을 감소시킬 수는 있지만, 여전히 개발자들은 라이브러리 루틴을 사용함으로써 발생하는 에러 조건들을 처리하는데 있어 자신만의 스타일을 사용한다. 부가하여, 라이브러리의 사용은 각각의 명령이 명령 라인으로부터 입력 파라미터를 획득하기 위한 로직을 포함해야 할 필요성에 영향을 주지 않는다. 그러므로, 루틴의 라이브러리를 사용함으로써 작성해야할 코드의 일부를 감소시킬 수는 있지만, 각각의 명령이 파싱, 데이터 검증 및 에러 보고를 수행하도록 하기 위하여 발생하는 상당한 중복 코드가 여전히 존재한다.

따라서, 모든 명령들에 대한 파라미터 획득 단계 동안 일관된 에러 메시지를 제공할 뿐만 아니라, 명령을 위해 요구되는 코드의 양을 감소시키는 한편, 명령으로의 입력 파라미터들을 보다 일관된 방법으로 획득하고, 처리하는 환경에 대한 필요성이 존재한다.

모든 명령들에 대한 파라미터 획득 단계 동안 일관된 에러 메시지를 제공할 뿐만 아니라, 명령을 위해 요구되는 코드의 양을 감소시키는 한편, 명령으로의 입력 파라미터들을 보다 일관된 방법으로 획득하고, 처리하는 환경에 대한 필요성이 존재한다.

본 발명은 명령에 대한 입력 파라미터들의 반영 기반 프로세싱을 제공하는 반영 기반 셸에 관한 것이다. 반영 기반 프로세싱은 파싱, 데이터 생성, 데이터 검증, 개체 암호화, 개체 프로세싱, 문서화 등을 포함한다. 반영 기반 셸은 클래스를 사용하여 입력 파라미터들에 대한 문법을 지정하기 위한 메커니즘을 제공한다. 제3 자 개발자들은 자신의 명령들을 위한 문법을 지정하기 위하여 클래스를 사용한다. 동작에 있어서, 본 발명은 파싱 가능한 스트림을 수신한다. 파싱 가능한 스트림은 명령 라인, 음성 입력, 스크립트 등으로부터 획득할 수 있다. 파싱 가능 스트림은 명령 및 적어도 하나의 파라미터를 포함한다. 파싱 가능 스트림에 기초하여, 명령을 위해 예정된 파라미터를 기술하는 한정적인 정보가 검색된다. 한정적인 정보를 사용하여, 개체(즉, 개발자에 의해 생성된 클래스의 인스턴스)가 생성된다. 개체는 예정된 파라미터의 기술에 따른 형식으로 적어도 하나의 파라미터를 저장한다. 그 후, 개체는 명령에 전달되어, 자신의 고유한 프로세싱을 수행한다. 한정적인 정보는 파라미터들을 예정된 파라미터로 맵핑하는 방법, 파라미터들을 (예컨대, 상호 작용을 통해) 획득하는 방법 등과 같은, 파싱 가능 스트림에 수행되는 동작들을 지정하는 지시자를 포함할 수 있다. 또한, 지시자들은 파싱, 검증, 문서화, 데이터 생성 및 데이터 프로세싱과 관련된 동작들을 포함할 수 있다.

그러므로, 본 발명의 하나의 이점은 명령 개발자들이 입력 파라미터를 획득하기 위하여 명령 라인을 파싱하고, 그 입력 파라미터들을 검증하는 로직을 작성할 필요없이, 그들의 명령으로의 입력 파라미터들을 위한 문법을 쉽게 지정할 수 있다는 점이다. 그러한 과정에서, 본 발명은 개발자가 작성해야 할 코드의 양을 감소시키고, 명령에 대한 구문이 더욱 일관되지만, 융통성 있도록 만들어 준다.

간략히 서술하면, 본 발명은 명령에 대한 입력 파라미터의 반영 기반 프로세싱을 제공하는 반영 기반 셸에 관한 것이다. 다음의 상세한 설명을 읽은 후에 명확해지는 바와 같이, 본 발명은 제3 자 개발자가 작성해야 하는 코드의 양을 최소화하고, 시스템 관리자가 시스템 관리 업무를 수행하기 위하여 알아야 할 지식의 양을 최소화한다. 그러므로, 본 발명은 시스템 관리 업무를 크게 경감시킨다. 부가하여, 본 발명은 입력 파라미터에 대해 보다 일관성 있는 구문을 제공하고, 입력 파라미터와 연관된 프로세싱을 위한 공용 기능을 제공한다.

도 1은 본 발명의 예시적인 일 실시예에서 사용될 수 있는 예시적인 컴퓨팅 장치를 도시한다. 매우 기본적인 설정으로, 전형적으로 컴퓨팅 장치(100)는 적어도 하나의 프로세싱 유닛(102) 및 시스템 메모리(104)를 포함한다. 컴퓨팅 장치의 정확한 설정 및 유형에 따라, 시스템 메모리(104)는 (RAM과 같은) 휘발성, (ROM, 플래시 메모리등과 같은) 비휘발성 또는 둘의 조합이 될 수 있다. 전형적으로, 시스템 메모리(104)는 운영 시스템(105), 하나 이상의 프로그램 모듈(106)을 포함하고, 프로그램 데이터(107)를 포함할 수 있다. 운영 시스템(105)은 운영 시스템 명령을 실행하는 명령 처리기(command processor; 130)를 포함한다. 명령 처리기(130)는 운영 시스템 명령들을 수용하는 셸(131)(즉, 명령 처리기 인터페이스)을 포함한다. 셸은 명령 프롬프트를 디스플레이하거나, 그래픽 사용자 인터페 이스(graphical user interface) 또는, 사용자 입력(user input)을 입력하거나 해석하기 위한 다른 수단을 디스플레이 할 수 있다. 셸(131)은 입력된 명령들이 유효함을 확인하고, 확인된 명령들을 실행을 위해 명령 처리기(130)의 다른 부분으로 전송한다. 이러한 기본적인 설정이 점선(108) 내의 구성 요소들에 의해 도 1에 도시되어 있다.

컴퓨팅 장치(100)는 부가적인 특징 및 기능을 가질 수 있다. 예컨대, 컴퓨팅 장치(100)는 또한 예컨대 자기 디스크, 광 디스크 또는 테이프와 같은 부가적인 (분리형 및/또는 고정형) 데이터 저장 장치들을 포함할 수 있다. 이러한 부가적인 저장은 도 1에서 분리형 저장(109) 및 고정형 저장(110)에 의해 도시되어 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 분리형 및 고정형 매체를 포함할 수 있다. 시스템 메모리(104), 분리형 저장(109) 및 고정형 저장(110)은 모두 컴퓨터 저장 매체의 예이다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(Digital Versatile Disks) 또는 다른 광 저장, 자기 카세트, 자기 테이프, 자기 디스크 저장 또는 다른 자기 저장 장치, 또는 희망하는 정보를 저장하기 위하여 사용될 수 있고, 컴퓨팅 장치(100)에 의해 접근할 수 있는 임의의 다른 매체를 포함하는데, 이에 제한되지는 않는다. 임의의 이러한 컴퓨터 저장 매체는 장치(100)의 일부가 될 수 있다. 또한, 컴퓨팅 장치(100)는 키보드, 마우스, 펜, 음성 입력 장치(voice input device), 접촉식 입력 장치(touch input device) 등과 같은 입력 장치(들)를 가질 수 있다. 디스플레이, 스피커, 프린터 등과 같은 출력 장치(들)(114)도 또한 포함될 수 있다. 이러한 장치들은 당해 기술 분야에서 잘 알려져 있으므로, 이하에서 자세히 기술할 필요가 없다.

또한, 컴퓨팅 장치(100)는 장치가 네트워크를 통해서와 같이 다른 컴퓨팅 장치들(118)과 통신할 수 있도록 해주는 통신 접속들(116)을 포함한다. 통신 접속들(116)은 통신 매체의 일 예이다. 전형적으로, 통신 매체는 컴퓨터 판독 가능 명령어들, 데이터 구조, 프로그램 모듈, 또는 반송파나 다른 전송 메커니즘과 같은 변조된 데이터 신호(modulated data signal) 내의 다른 데이터에 의해 구체화될 수 있고, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 하나 이상의 특징 세트(characteristic set)를 가지고 신호에 정보를 암호화하는 방법으로 변경된 신호를 의미한다. 제한이 아닌 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 접속과 같은 유선 매체, 및 음향(acoustic), RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함한다. 본 명세서에서 사용된 컴퓨터 판독 가능 매체는 저장 매체와 통신 매체 모두를 포함한다.

도 2는 본 발명에 따른 반영 기반 셸(200) 내의 파서(parser; 202) 및 엔진(204)을 통한 명령 라인(command line; 250)의 프로세싱을 도시하는 기능적인 흐름도이다. 예시적인 명령 라인(250)은 여러 명령어들(즉, process 명령(260), where 명령(262), sort 명령(264) 및 table 명령(266))을 파이프라인으로 보낸다. 그러나, 다음의 논의는 하나의 명령(예컨대 where 명령(262))에 대한 입력 파라미터의 반영 기반 프로세싱에 집중한다. 다른 명령들에 대한 반영 기반 프로세싱은 유사한 방법으로 수행된다. 명령 라인(250)은 명령들 중의 임의의 것에 입력 파라미터들을 넘겨줄 것이다(예컨대, "handlecont > 400"은 where 명령(262)에 넘겨짐). 프로세스 명령(260)은 어떠한 연관된 입력 파라미터도 가지지 않음에 주의해야 한다. 과거에는, 각각의 명령은 명령과 연관된 입력 파라미터들을 파싱하고, 입력 파라미터가 유효한지 결정하며, 입력 파라미터가 유효하지 않다면 에러 메시지를 발생시키는 책임을 가졌다. 전형적으로, 명령들은 다양한 프로그래머에 의해 작성되므로, 명령 라인 상의 입력 파라미터들에 대한 구문은 일관되지 않았다. 부가하여, 에러가 발생하면, 심지어 동일한 에러에 대한 에러 메시지들이 명령들 간에 일치하지 않았다.

예컨대, Unix 환경에서, "ls" 명령 및 "ps" 명령은 그들 간에 많은 불일치를 갖는다. 두 명령어 모두 "-w" 옵션을 수용하는데, "ps" 명령에 의한 "-w" 옵션은 프린트 폭 출력(print wide output; 본질적으로 페이지 폭을 무시)을 나타내기 위하여 사용되는 반면, "ls" 명령에 의한 "-w" 옵션은 페이지의 폭을 나타내기 위하여 사용된다. "ls" 및 "ps" 명령과 연관된 도움 페이지(help page)들 역시 여러 불일치를 갖는데, 그 예로 한 명령어에서는 볼드형(bolded) 옵션을 가지고 다른 하나에서는 그렇지 않은 경우, 한 명령어에서는 알파벳 순(alphabetically) 정렬 옵션을 가지고 다른 하나에서는 그렇지 않은 경우, 일부 옵션에서는 대시(dash)를 가질 것을 요구하고 다른 일부에서는 그렇지 않은 경우를 들 수 있다.

이하 자세히 기술되는 바와 같이, 본 발명은 더욱 일관성 있는 접근법을 제공하고, 각각의 개발자가 작성해야 하는 중복 코드의 양을 최소화시킨다. 반영 기 반 셸(200)은 구문(예컨대, 문법), 대응되는 시맨틱(예컨대, 사전) 및 사용자가 반영 기반 셸(200)에 의해 제공되는 공용 기능을 쉽게 이용할 수 있도록 하는 참조 모델(reference model)을 제공한다.

본 발명에 대해 더 자세히 기술하기 전에, 본 명세서에 걸쳐 나타나는 용어들에 대한 정의를 제공한다. "명령(command)"은 독립형 실행 가능 프로그램(standalone executable program)을 의미한다. "소명령(commandlet)" 또는 "소명령(cmdlet)"은 명령들에 비해 상당히 작은 프로그램을 의미한다. 일 실시예에서, 각각의 소명령은 명사-동사 쌍(noun-verb pair)(예컨대, 명령 라인(250)에서 get/process)을 정의한다. 이하의 논의에서는 본 발명에 따라 작성된 명령어를 언급하는 경우 소명령이라는 용어를 사용한다. 그러나, 일부 예에서는, 소명령을 언급하기 위해, 보다 공통된 용어인 "명령"을 사용할 것이다. 입력 파라미터는 소명령에 대한 입력 필드(input-field)들을 의미한다. 인수(argument)는 argv 배열에서 하나의 문자열(string)과 동등한 명령 또는 소명령으로 전달되거나 RequestObject에서 하나의 요소로서 전달된 입력 파라미터를 의미한다. 이하에서 기술되는 바와 같이, RequestObject는 소명령에 대한 문법을 지정하기 위한 메커니즘을 의미한다. 인수는 옵션, 옵션-인수, 또는 명령-이름 뒤의 피연산자(operand) 중의 하나이다. 다음의 명령 라인에 기초하여 인수의 예를 제공한다.

findstr /i /d:\winnt;\winnt\system32 aa*b *.ini

위의 명령 라인에서, "findstr"은 인수 0, "/i"는 인수 1, "/d:\winnt;\winnt\system32"는 인수 2, "aa*b"는 인수 3, 및 "*.ini"는 인수 4이다. "옵션"은 프로그램의 기본 행동(default behavior)에 변화를 지정하기 위하여 일반적으로 사용되는 명령 또는 소명령으로의 인수이다. 위의 예시적인 명령 라인에 있어서, "/i" 및 "/d"는 옵션이다. "옵션-인수"는 특정한 옵션을 수반하는 입력 파라미터이다. 일부 경우에 있어서, 옵션-인수는 옵션과 동일한 인수 문자열 내에 포함된다. 다른 경우에는, 옵션 인수는 다음 인수로 포함된다. 다시 위의 명령 라인을 참조하면, "winnt;\winnt\system32"는 옵션-인수이다. "피연산자"는 프로그램 프로세싱을 완료하기 위하여 필수적인 정보를 프로그램에 제공하는 개체로서 일반적으로 사용되는 명령 또는 소명령으로의 인수이다. 일반적으로, 피연산자는 명령 라인에서 옵션을 뒤따른다. 다시 위의 예시 명령 라인을 참조하면, "aa*b" 및 "*.ini"가 피연산자들이다. "파싱 가능 스트림"은 인수들을 포함한다.

"클래스 멤버(class member)들"은 서브 클래스(sub-class), 필드, 상수, 메소드, 구조체(structure), 특성, 배열, 인덱서(indexer), 인터페이스, 이벤트, 예외(exception) 등과 같은 요소들을 의미한다. "지시자(directive)"는 메타데이터(metadata) 속성을 의미한다. "카테고리(category)"는 한 세트의 특정 유형의 지시자을 의미한다. 이하에서 상세히 기술되는 바와 같이, 본 발명의 반영 기반 셸은 파싱 지시자, 데이터 생성 지시자와 같은 여러 카테고리의 지시자를 제공한다. 각각의 카테고리 내에서, 반영 기반 셸은 여러 지시자를 제공한다. 카테고리 및 지시자들은 소프트웨어 개발자에 의해 확장될 수 있다.

도 2를 참조하면, 파서(202)는 파싱 가능 스트림(예컨대, 명령 라인(250))을 RequestObjects(220 내지 226)(예컨대, where 요청(222))로 파싱한다. 각각의 RequestObjects(220 내지 226)는 소명령들(260 내지 266) 중의 하나와 연관된다. 간략히 말하면, 도 3과 연관하여 이하에서 자세히 기술되는 바와 같이, RequestObjects(220 내지 226)는 개발자가 소명령으로의 입력 파라미터를 위한 문법을 지정할 수 있는 수단 또는 메커니즘을 제공한다. RequestObject는 실행 가능한 대응되는 소명령(예컨대, where 실행 가능형(232))으로 전달된다. 그러나, 도 4와 관련하여 이하에서 기술되는 바와 같이, 파서(202) 및 엔진(204)은 RequestObject를 실행 가능한 소명령으로 전달하기 전에 명령 라인(200)에서 지정된 입력 파라미터에 다양한 프로세싱을 수행한다. 이러한 프로세싱은 파싱, 파라미터 검증, 데이터 생성, 파라미터 프로세싱, 파라미터 암호화 및 파라미터 문서화를 포함한다. 파서(202) 및 엔진(204)은 명령 라인 상의 입력 파라미터들에 공용 기능들을 수행하므로, 반영 기반 셸(200)은 사용자에게 일관된 에러 메시지를 발생시킬 수 있다. 인식할 수 있는 바와 같이, 본 발명에 따라 작성된 실행 가능한 소명령들(230 내지 236)은 종래 시스템에서의 명령보다 더 적은 코드를 요구한다. 각각의 실행 가능 소명령(230 내지 236)은 대응되는 RequestObejct(220 내지 226)를 수용한다. 부가하여, 각각의 실행 가능 소명령(230 내지 236)은 다음의 파이프라인된 소명령으로의 입력인 개체를 출력한다. 전형적으로, 이러한 개체들은 개체에 참조(예컨대, 핸들)를 전달함으로써 입력이 된다. 그 후, 실행 가능 소명령들(230 내지 236)은 전달된 개체들에 부가적인 프로세싱을 수행할 수 있다.

도 3은 소명령으로의 입력 파라미터들에 대한 문법을 지정하기 위한 데이터 구조(300)에 대한 일 실시예이다. 본질적으로, 데이터 구조(300)는 반영 기반 셸 과 소명령 사이의 계약을 명확히 표현하기 위한 수단을 제공한다. 다음의 논의는 워싱턴 주, 레드몬드의 Microsoft Corporation에 의해 만들어진 .NET 프레임워크를 사용하여 본 발명을 기술한다. 그러나, 본 발명의 범위를 벗어나지 않고 다른 환경이 사용될 수 있다.

소프트웨어 개발자는 대응되는 실행 가능 소명령에 대한 코드 내에 데이터 구조(300)을 코딩한다. 이러한 요청을 구현하는 메소스들 및 특성들은 어떤 입력 파라미터들이 명령 라인을 통해 사용자에게 노출될 것인지를 실질적으로 결정한다. 데이터 구조(300)는 RequestObject 클래스(304)에서 파생된 퍼블릭 클래스(public class)이다. 소프트웨어 개발자는 데이터 구조(300)를 위한 클래스 이름(302)를 제공한다. 클래스 이름(302)은 소명령을 위하여 명령 라인에 지정되는 인수의 이름을 식별한다. 각각의 명령 이름(302)은 도 2에서 도시된 예시 명령 라인(200)에서의 "get/process" 및 "format/table"과 같은 동사/명사 쌍을 나타낸다. 동사 또는 명사는 "where" 명령과 같이 명령 이름으로는 불명확할 수 있다. 일 실시예에서, 클래스 이름(302)은 소명령과 동일하지 않음을 인식할 것이다. 이러한 실시예에서, 다른 주석이 소명령의 이름을 식별하기 위하여 사용된다. 데이터 구조(300)는 적어도 하나의 퍼블릭 멤버(예컨대, Name(330))를 포함한다. 퍼블릭 멤버들(330 및 332)은 소명령과 연관된 입력 파라미터들을 나타낸다. 각각의 퍼블릭 멤버(330 및 332)는 다음 카테고리(파싱 지시자(310), 데이터 검증 지시자(312), 데이터 생성 지시자(314), 프로세싱 지시자(316), 암호화 지시자(318) 및 문서화 지시자(320))의 각각에서 하나 이상의 지시자를 가질 수 있 다. 지시자들은 대괄호로 둘러싸는데, 이는 그들을 뒤따르는 입력 파라미터를 기술한다. 또한, 사용자 상호 작용 유형 지시자(user interaction type directive)와 같은 지시자들 중의 일부는 클래스 수준에도 적용될 수 있다. 또한, 데이터 구조(300)는 파서가 입력 파라미터로 인식하지 않는 프라이빗 멤버(340)를 포함할 수 있다. 프라이빗 멤버(340)는 지시자들 중의 하나에 기초하여 생성된 데이터를 저장하기 위하여 사용될 수 있다.

퍼블릭 멤버를 위한 이름은 명령 라인 상의 입력 파라미터에 자격을 부여하기(qualify) 위하여 명령 라인 상에서 사용될 수 있다. 그렇지 않다면, 퍼블릭 멤버는 명령 라인 상의 자신의 위치에 기초하여 입력 파라미터를 저장하기 위하여 사용될 수 있다. 다음은 이러한 개념을 도시하는 예로서, RequestObject는 다음과 같다.

public class FileCopyRequest : RequestObject

{

[ParsingParameterPositionAttribute(0)]

public string From;

[ParsingParameterPositionAttribute(1)]

public string To;

...

}

ParsingParameterPisitionAttrubute은 위치에 기초하여 자격이 부여되지 않은 파라미터들을 맵핑시키는 방법을 기술하는 파싱 지시자이다. 상술한 바와 같이, 자격이 부여되지 않은 파라미터들은 입력 파라미터와 연관하여 퍼블릭 멤버 이름을 사용하지 않는 파라미터들이다. 다음은 위의 파싱 지시자를 "To" 및 "From" 멤버에 적용한 후의 적절한 문법이다.

$ copy/File -From:a -To:b

$ copy/File a b

$ copy/File -From:a b

$ copy/File a -To:b

$ copy/File -To:b -From:a

다음의 문법은 무효가 될 것이다.

$ copy/File -To:b a

$ copy/File b -From:a

이하에서 기술되는 바와 같이, 다른 지시자들은 명령 라인에서 지정된 입력 파라미터들의 프로세싱에 영향을 미친다. 그러므로, 지시자의 사용을 통해, 소명령 개발자는 자신들의 소명령으로의 입력 파라미터들을 위한 문법을 쉽게 지정할 수 있고, 임의의 내재하는 로지을 생성하지 않고도 입력 파라미터들에 프로세싱을 수행할 수 있다.

지시자들은 소명령과 연관된 메타데이터에 저장된다. 이후에 도 4와 관련하여 기술되는 바와 같이, 메타데이터 프로세싱은 반영 기반 셸에 걸쳐 분산된다. 예컨대, 적응성 지시자(applicability directive), 문서화 지시자 및 파싱 지침 지시자는 파서 내에서 매우 이른 단계에서 처리된다. 데이터 생성 지시자 및 검증 지시자는 파서가 모든 입력 파라미터들을 파싱하는 것을 마친 경우에 엔진에서 처리된다.

다음 표는 지시자에 응답하여 반영 기반 셸에 의해 수행되는 프로세싱의 설명과 함께, 다양한 카테고리들을 위한 대표적인 지시자들을 나타낸다.

적응성 지시자들

이름	설명
PrerequisiteMachineRoleAttribute	셸에게 요소가 특정 장치 역할(예컨대, 파일 서버, 메일 서버)에서만 사용될 것인지 통보.
PrerequisiteUserRoleAttribute	셸에게 요소가 특정 사용자 역할(예컨대, 도메인 관리자, 백업 작업자)에서만 사용될 것인지 통보.

파싱 지침 지시자들

이름	설명
ParsingParameterPositionAttribute	위치에 근거하여 자격이 부여되지 않은 파라미터들을 맵핑함.
ParsingVariableLengthParameterListAttribute	ParsingParameterPosition 속성을 갖지 않은 파라미터들을 맵핑함.
ParsingDisallowInteractionAttribute	파라미터의 수가 요구되는 수보다 적은 경우의 동작 지정.
ParsingRequireInteractionAttribute	파라미터들이 상호 작용을 통해 획득됨을 지정.
ParsingHiddenElementAttribute	파라미터가 사용자에게 보이지 않도록 만듦.
ParsingMandatoryParameterAttribute	파라미터가 요구됨을 지정.
ParsingPasswordParameterAttribute	파라미터의 특별 처리 요구.
ParsingPromptStringAttribute	파라미터를 위한 프롬프트 지정.
ParsingDefaultAnswerAttribute	파라미터를 위한 기본 응답 지정
ParsingDefaultAnswerScriptAttribute	파라미터를 위한 기본 응답을 얻기 위한 동작 지정.
ParsingDefaultValueAttribute	파라미터를 위한 기본 값 지정.
ParsingDefaultValueScriptAttribute	파라미터를 위한 기본 값을 얻기 위한 동작 지정.

문서화 지시자들

이름	설명
DocumentNameAttribute	상호 작용 또는 도움을 위한 요소를 의미하는 이름 제공.
DocumentShortDescriptionAttribute	요소의 요약 설명 제공.
DocumentLongDescriptionAttribute	요소의 상세 설명 제공.
DocumentExampleAttribute	요소의 예시 제공.
DocumentSeeAlsoAttribute	관련 요소들의 목록 제공.
DocumentSynopsisAttribute	요소를 위한 문서화 정보 제공.

데이터 검증 지시자들

이름	설명
ValidationRangeAttribute	파라미터가 특정 범위 내에 존재해야 함을 지정.
ValidationSetAttribute	파라미터가 특정 모음 내에 존재해야 함을 지정.
ValidationPatternAttribute	파라미터가 특정 패턴을 일치해야 함을 지정.
ValidationLengthAttribute	문자열들이 크기 범위 내에 존재해야 함을 지정.
ValidationTypeAttribute	파라미터가 특정 유형이어야 함을 지정.
ValidationCountAttribute	입력 아이템들이 특정한 수이어야 함을 지정.
ValidationFileAttribute	파일을 위한 특정 특성 지정.
ValidationFileAtttibutesAttribute	파일을 위한 특정 특성 지정.
ValidationFileSizeAttribute	파일들이 지정된 범위 내에 존재해야 함을 지정.
ValidationNetworkAttribute	주어진 네트워크 엔티티가 특정 특성을 지원해야 함을 지정.
ValidationScriptAttribute	요소를 사용하기 전에 평가해야 할 조건 지정.
ValidationMethodAttribute	요소를 사용하기 전에 평가해야 할 조건 지정.

프로세싱 및 암호화 지시자들

이름	설명
ProcessingTrimStringAttribute	문자열들을 위한 크기 제한 지정.
ProcessingTrimCollectionAttribute	모음을 위한 크기 제한 지정.
EncodingTypeCoercionAttribute	개체가 암호화될 유형 지정.

.NET 프레임워크를 사용하는 실시예에서, 각각의 카테고리는 기본 카테고리 클래스(예컨대, CmdAttribute)로부터 파생된 기본 클래스를 갖는다. 기본 카테고리 클래스는 System.Attribute 클래스로부터 파생된다. 각각의 카테고리는 카테고리 프로세싱 동안에 파서에 의해 호출되는 사전에 정의된 함수(예컨대, attrib.func())를 갖는다. 소명령 개발자는 커스텀 카테고리 클래스(예컨대, CmdCustomAttribute)로부터 파생된 커스텀 카테고리를 생성할 수 있다. 또한, 소명령 개발자는 해당 카테고리에 대한 기본 카테고리 클래스로부터 지시자 클래스를 파생시킴으로써 현재 카테고리 클래스를 확장할 수도 있고, 자신의 구현으로 사전에 정의된 함수를 오버라이드(override)할 수도 있다. 또한 소명령 개발자는 지시 자들을 오버라이드할 수 있고, 지시자들의 사전에 정의된 세트에 새로운 지시자들을 추가할 수 잇다.

이러한 지시자들의 프로세싱 순서는 파서에 의해 접근 가능한 외부 데이터 저장소에 저장될 수 있다. 반영 기반 셸은 등록된 카테고리들을 찾아서, 해당 카테고리의 각각의 지시자들에 대해 함수(예컨대, ProcessCustomDirective)를 호출한다. 그러므로, 카테고리 프로세싱의 순서는 지속형 저장소(persistent store)에 카테고리 실행 정보를 저장함으로써 동적일 수 있게 된다. 상이한 프로세싱 단계에서, 파서는 임의의 메타데이터 카테고리가 그 시점에 실행될 필요가 있는지를 결정하기 위하여, 지속형 저장소에 체크인(check in)한다. 이러한 실시예로 인해, 지속형 저장소로부터 카테고리 엔트리를 제거함으로써 카테고리를 쉽게 비난할 수 있게 된다.

도 4는 명령을 위해 입력된 입력 파라미터들을 처리하기 위한 프로세스(400)를 도시하는 논리적인 흐름도이다. 이 지점에서, 소명령이 개발되고, 메타데이터는 도 3에 도시된 RequestObject를 사용하여 소명령 소스 파일에 삽입된다. 소명령은 컴파일되어 등록된다. 등록 동안, 클래스 이름(즉, 소명령 이름)이 등록 저장소에 기록되었다. 프로세스(400)는 블록(401)에서 시작하는데, 반영 기반 셸은 소명령을 나타내는 입력(예컨대, 키입력)을 수신한다. 반영 기반 셸은 레지스트리 내에서 입력을 조회하고, 타이프된 입력을 등록된 소명령과 연관시킴으로써 입력을 소명령으로 인식할 수 있다. 프로세싱은 블록(402)으로 계속된다.

블록(402)에서, 식별된 소명령과 연관된 클래스가 식별된다. 또한, 이 클래 스는 레지스트리를 통해 식별될 수 있다. 프로세싱은 블록(404)으로 계속된다.

블록(404)에서, 클래스와 연관된 메타데이터가 판독된다. 메타데이터는 소명령과 연관된 임의의 지시자들을 포함한다. 지시자들은 소명령 자체 또는 RequestObject에서 지정된 하나 이상의 파라미터에 적용될 수 있다. 소명령 등록 동안, 등록 코드는 메타데이터를 지속형 저장소에 등록한다. 메타데이터는 XML 파일에 직렬화된 형식으로, 외부 데이터베이스 등에 저장될 수 있다. 위의 표에서 설명된 바와 같이, 메타데이터에 지정된 지시자들은 각각 Applicability Directives, Parsing Guideline Directives 등과 같은 카테고리와 연관된다. 각각의 지시자 카테고리는 반영 기반 셸의 상이한 단계에서 처리된다. 각각의 메타데이터 지시자는 자신의 에러 처리를 담당한다. 프로세싱은 블록(406)으로 계속된다.

블록(406)에서, RequestObejct는 식별된 클래스에 기초하여 인스턴스화된다(instantiated). 프로세싱은 블록(408)으로 계속된다.

블록(408)에서, 입력 파라미터에 관련된 정보를 얻기 위하여 RequestObject 상에서 반영이 수행된다. 반영 기반 셸은 호출자에게 (요구를 근거로) 반영 데이터를 반환하기 위한 공용 인터페이스를 제공한다. 상술한 실시예에서, 반영은 .NET Reflection을 사용한다. 프로세싱은 블록(410)으로 계속된다.

블록(410)에서, 적응성 지시자들(예컨대, 표 1)이 적용된다. 적응성 지시자들은 클래스가 특정 장치 역할들(machine roles) 및/또는 사용자 역할들에 사용됨을 보장한다. 예컨대, 특정 소명령들은 오직 Domain Administrators에 의해 사용 될 수 있다. 적응선 지시자들 중의 하나에 지정된 제한이 만족되지 않으면, 에러가 발생한다. 프로세싱은 블록(412)으로 계속된다.

블록(412)에서, 메타데이터는 인텔리센스(intellisense)를 제공하기 위하여 사용된다. 프로세싱의 이 지점에서, 아직 전체 명령 라인이 입력되지는 않았다. 그러나, 반영 기반 셸은 소명령과 연관된 RequestObject에 대한 반영을 통해 허용되는 입력 파라미터들을 알고 있다. 그러므로, 엔진을 통한 반영 기반 셸은 명령 라인에 입력 파라미터의 명확한 부분이 타이프된 경우 입력 파라미터를 자동으로 완성시킬(auto-complete) 수 있다. 자동 완성은 입력 파라미터의 일부가 입력 파라미터들 중의 하나를 명확하게 인식할 수 있는 순간에 발생할 수 있다. 프로세싱은 블록(414)으로 계속된다.

블록(414)에서, 프로세스는 소명령에 대한 입력 파라미터가 입력될 때까지 대기한다. 전형적으로, 리턴 키를 치는 것과 같이 사용자가 명령 라인의 마지막을 나타내는 경우가 이에 해당된다. 프로세싱은 블록(416)으로 계속된다.

블록(416)에서, 파싱 지침 지시자가 적용되고, RequestObject 인스턴스는 입력 파라미터들과 파퓰레이트된다(populated). 파서는 파싱 동안에 사용되는 한 세트의 규칙들을 갖는다. 규칙들의 세트는 RequestObject 데이터 구조에 지정된 문법이 명령 라인 상의 입력 파라미터를 위한 구문으로 변환되는 방법을 지정한다. 예컨대, Foo 명령에 대한 다음의 RequestObject 선언이 주어지면:

class Foo : RequestObject

{

string Name;

Bool Recurse;

}

명령 라인 구문은 다음 중의 하나가 될 수 있다.

$Foo -Name:(string) -Recurse:True

$Foo -Name<string> -Recurse True

$Foo /Name (string)

규칙의 세트는 희망하는 구문을 생성하기 위해 시스템 관리자에 의해서 변경될 수 있다. 부가적으로, 파서는 다수의 세트의 규칙을 지원할 수 있는데, 그 결과 사용자는 하나 이상의 구문을 사용할 수 있다. 따라서, RequestObject 구조에 지정된 문법(예컨대, string Name 및 Bool Recurse)은 파서를 구동한다.

일반적으로, 파싱 지시자는 명령 라인에 입력된 파라미터들이 RequestObject에서 식별된 예정 파라미터들로 어떻게 맵핑될 것인지를 기술한다. 다음의 예시는 위치 정보를 지정하는 파싱 지시자를 도시한다.

Class foo : RequestObject

{

[ParsingParameterPositionAttribute(0)]

String HostName

[ParsingParameterPositionAttribute(1)]

String AliasName

}

올바른지 결정하기 위하여, 입력 파라미터 유형을 검사한다. 입력 파라미터 유형이 올바르지 않다면, 입력 파라미터는 올바르게 되도록 강제될 수 있다. 입력 파라미터 유형이 올바르지 않고 강제될 수도 없다면, 사용 에러(usage error)가 프린트된다. 사용 에러로 인해 사용자는 예정된 올바른 구문을 알게 된다. 사용 에러는 문서화 지시자(418)로부터 구문을 기술하는 정보를 획득할 수 있다. 입력 파라미터 유형이 맵핑되거나 확인되면, RequestObject 인스턴스의 대응되는 멤버가 파퓰레이트된다. 프로세싱은 블록(420)으로 계속된다.

결정 블록(420)에서, 입력 파라미터들 중의 어떤 것이 사용자와의 상호 작용이 필요한지에 대한 결정이 내려진다. 파라미터들 중의 임의의 것이 사용자 상호 작용이 필요하면, 프로세스는 블록(422)으로 진행된다. 그렇지 않으면 프로세싱은 블록(424)으로 계속된다.

블록(422)에서, 반영 기반 셸은 입력 파라미터들을 획득하기 위하여 사용자와 상호 작용한다. 개발자는 RequestObject의 파라미터에 대한 CmdPgRequireInteraction 지시자를 지정함으로써 입력 파라미터가 사용자 상호 작용을 통해 획득되도록 지정할 수 있다. 부가하여, 모든 입력 파라미터들이 명령 라인에 입력되지 않았으면, 반영 기반 셸은 사용자 상호 작용이 필요하다고 결정할 수 있다. 입력 파라미터, 소명령 자체 및 다른 설정들이 상호 작용하는 것이 금지되지 않는 한, 반영 기반 셸은 필수적인 입력 파라미터를 획득하기 위하여 사용자와 상호 작용할 것이다. 사용자 수준, 그룹 수준 및 기업 수준에서 사용자 상호 작용이 허용되는지를 지정하기 위하여 플래그를 사용할 수 있다. 이러한 수준들 중의 하나가 사용자 상호 작용을 허용하지 않는다면, 에러 메시지가 발생된다. 사용자 상호 작용이 수행되면, 프로세싱은 블록(424)으로 계속된다.

블록(424)에서, 엔진은 RequestObeject 인스턴스에 다른 전달을 수행하고, 입력 파라미터들에 임의의 남은 지시자들을 적용한다. 남은 지시자들은 데이터 생성 지시자들, 데이터 검증 지시자들, 개체 프로세싱 지시자들 및 개체 암호화 지시자들을 포함한다. 이러한 지시자들은 파서가 입력 파라미터들을 파싱하는 것을 종료한 후에 엔진에서 처리된다. 표 3 내지 표 5에서 상술한 각각의 카테고리들로부터의 대표 지시자(representative directive)가 기술될 것이다.

제1 대표 지시자는 데이터 생성 지시자로부터 유래한다. RequestObject는 다음 문장을 포함할 수 있다.

[ParsingDefaultAnswerScriptAttribute(Filename, F)]

String Name;

private Arraylist F;

Arraylist F가 프라이빗이므로, 파서는 이 선언을 소명령으로의 입력 파라미 터로 처리하지 않는다. 대신, Arraylist F는 Data Generation 지시자에 지정된 서비스에 의해 생성되는 데이터를 위한 임시 저장이다. 위의 예시에서, 서비스는 "Filename"이다. Filename은 반영 기반 프레임워크에 의해 제공되는 유틸리티이거나, 제3 자 함수 또는 유틸리티일 수 있다. 엔진이 위의 지시자를 마주친 경우, 엔진은 레지스트리 내에서 "Filename"이라 이름 붙은 서비스를 식별한다. 서비스 설치 동안 서비스의 등록이 발생한다. Data Generation 지시자로 인해 유일한 프로세싱이 입력 파라미터에 대해 발생할 수 있다. 예컨대, 서비스는 명령 라인에 "A*"로 입력된 파일이름에 와일드카드 확장(wildcard expansion)을 수행할 수 있다. 제2 전달 전에, Name 멤버는 명령 라인에 입력된 바와 같이 "A*"를 포함한다. 제2 전달 동안, Filename 서비스는 A로 시작하는 한 세트의 파일의 위치를 파악하여, Arraylist F에 그들을 저장할 수 있다. 당업자는 데이터 생성 지시자가 파일 이름의 와일드카드 확장을 제공할 뿐만 아니라, 사용자 이름, 프로세스 등의 와일드카드 확장을 제공할 수 있음을 인식할 것이다. 부가하여, 데이터 생성 지시자는 입력 파라미터들에 다른 프로세싱을 수행할 수 있다.

예시적인 데이터 검증 지시자는 RequestObject 내에 다음의 문장을 포함할 수 있다.

[ValidationSetAttribute("Debug", "Production", "Test")]

[ParsingParameterMandatoryAttribute]

String Name;

위의 데이터 검증 지시자들에 있어서, 파서는 Name이 강제 입력 파라미터(mandatory input parameter)이고, 문자열은 Debug, Production 또는 Test 중의 하나이어야 함을 인식한다. 그렇지 않다면, 데이터 검증 지시자는 에러를 발생시킬 것이다. 에러는 에러 메시지를 공급하기 위하여 문서화 지시자들을 사용할 수 있다.

예시적인 개체 프로세싱 지시자는 RequestObject 내에 다음의 문장을 포함할 수 있다.

[tolower]

String HostName;

위의 개체 프로세싱 지시자에 있어서, HostName으로 지정된 인수는 RequestObject를 실행 가능 소명령으로 처리하기 전에 소문자 문자열(lower case string)로 변환된다.

예시적인 개체 암호화 지시자는 RequestObject 내에 다음의 문장을 포함할 수 있다.

[TOIP(HostIP)]

String HostName;

Private IPaddrHostIP;

위의 개체 암호화 지시자에 있어서, HostName으로 입력된 문자열은 IP 주소로 변환된다. 파서는 HostIP 파라미터가 Private으로 선언되었으므로, 이를 입력 파라미터로 처리하지 않는다. 그러나, 실행 가능 소명령은 HostIP 멤버를 참조할 수 있다. 위의 개체 암호화 지시자가 많은 코드 라인을 절약시켜주는 것으로 보이지 않을 수도 있지만, 실질적으로 지시자는 제3 자 개발자에 의해 작성될 코드의 양을 상당히 감소시킨다. 예컨대, 종래 환경에서는, 제3 자 개발자가 에러 프로세싱을 처리한다. 부가하여, 에러 메시지가 문자열이면, 그 문자열은 다수의 언어로 변환되어야 할 필요가 있다. 그러나, 본 발명은 일정한 에러 처리를 제공한다. 부가하여, 본 발명은 에러 메시지를 다수의 언어로 일정하게 변환하는 메커니즘을 제공한다. 프로세싱은 블록(426)에서 계속된다.

블록(426)에서, RequestObject 인스턴스는 실행 가능 소명령에 전달된다. 그 후, 실행 가능 소명령은 자신의 프로세싱에 이러한 입력 파라미터를 사용할 것이다. 그러므로, 종래 명령 구현과 반대로, 본 발명의 소명령은 입력 파라미터들을 파싱하거나 검증하기 위하여 어떠한 유일 코드를 작성할 필요가 없다. 부가하여, 본 발명은 소프트웨어 개발자가 지시자들을 통해 입력 파라미터들의 부가적인 프로세싱을 지정할 수 있는 훨씬 풍부한 환경을 제공한다.

각각의 지시자는 자신의 에러 메시지를 처리한다. 에러 메시지가 디스플레이될 필요가 있다면, 지시자는 문서 저장소(document store)로부터 지역화된 문자열(localized string)을 얻고, 에러 메시지를 디스플레이 하기 위하여 디스플레이 인터페이스를 호출한다. 문서화 지시자들과 관련된 데이터는 소명령, XML 저장소 또는 외부 데이터베이스, 또는 리소스 파일에 저장될 수 있다. 그러므로, 본 발명은 모든 소명령에 대하여 일관된 에러 메시지를 제공할 수 있고, 제3 자의 지역화(localization) 수고를 감소시킬 수 있다.

부가하여, 반영 기반 셸은 하나의 지시자에 의해 생성된 데이터를 개체의 형태로 호출 지시자에 반환하는 공용 인터페이스를 제공한다. 호출 지시자는 데이터를 요구된 데이터타입으로 캐스팅(casting)할 책임이 있다. 표 1 내지 표 5는 여러 카테고리에 대한 대표 지시자들을 나타내지만, 다른 지시자들 및 부가적인 카테고리가 본 발명의 범위를 벗어나지 않고 부가될 수 있다.

그러므로, 상술한 바와 같이, 본 발명은 소명령으로의 입력 파라미터들을 위한 문법을 정의하는 메커니즘을 제공한다. 메커니즘으로 인해 개발자는 소명령을 개발, 시험 및 지원할 수 있게 된다. 소명령은 적은 코드 양을 가지고, 신속한 구현이 가능하며, 적은 결점을 가지고, 결점의 위치 파악이 용이하다. 메커니즘은 구문, 의미론, 에러 처리, 리소스 관리, 보안 등에 있어서 더 많은 일관성을 제공한다. 이상의 논의는 .NET 프레임워크 내에서 본 발명을 기술했다. 그러나, 당업자는 본 발명이 반영 능력을 제공하는 임의의 운영 시스템 내에서 구현될 수 있음을 인식할 것이다. 부가하여, 본 발명은 명령 라인 실시예에서 기술되었다. 그러나, 파싱된 파싱 가능한 데이터는 본 발명의 범위를 벗어나지 않고 음성(voice), 그래픽 사용자 인터페이스(graphical user interface), 스크립트 등을 통해 획득될 수 있다. 부가하여, 본 발명은 하나의 RequestObject 클래스가 다른 RequestObject 클래스를 선언할 수 있도록 허용함으로써 풍부한 세트의 문법을 기술하기 위하여 사용될 수 있다. 그러므로, 본 발명은 시스템 관리자에게 강력한 다용성(versatility)을 제공한다.

이상의 명세서, 예시 및 데이터는 발명의 구성의 사용 및 제조를 위한 완전한 설명을 제공한다. 발명의 많은 실시예가 본 발명의 사상 및 범위를 벗어나지 않고 구현될 수 있으므로, 이하 첨부된 청구항에 발명이 존재한다.

본 발명의 이점은 명령 개발자들이 입력 파라미터를 획득하기 위하여 명령 라인을 파싱하고, 그 입력 파라미터들을 검증하는 로직을 작성할 필요없이, 그들의 명령으로의 입력 파라미터들을 위한 문법을 쉽게 지정할 수 있다는 점이다. 그러한 과정에서, 본 발명은 개발자가 작성해야 할 코드의 양을 감소시키고, 명령에 대한 구문이 더욱 일관되지만, 융통성 있도록 만들어 준다.

Claims

클래스를 사용하여 입력 파라미터들에 대한 문법(grammar)을 지정(specifying)하기 위한 데이터 구조가 인코딩되어 있는 컴퓨터 판독 가능 저장 매체로서,

상기 데이터 구조는,

개체(object)의 클래스에 대한 클래스 이름 - 상기 클래스 이름은 개발자에 의해 지정된 명령(command)을 식별함 -;

상기 명령과 연관된 예정된 파라미터(expected parameter)의 한정적인 정보(definitional information) - 상기 한정적인 정보는 상기 명령에 대한 문법을 정의함 -; 및

상기 클래스와 연관된 복수의 지시자(directive)들

을 포함하고,

상기 복수의 지시자들은,

상기 예정된 파라미터가 명령 라인(command line)에서 입력되지 않은 경우, 상기 예정된 파라미터의 입력을 위한 사용자 인터페이스를 결정하는 상호 작용 지시자;

상기 예정된 파라미터에 대한 텍스트형 정보(textual information)가 요청되면, 상기 예정된 파라미터에 대한 텍스트형 정보를 지정하는 문서 - 상기 텍스트형 정보는 명령 내의 요소를 참조하기 위한 이름 및 상기 요소의 기술(description)을 포함함 -; 및

요청되면, 상기 예정된 파라미터에 대한 텍스트형 정보를 생성하고, 유효하지 않은 구문(syntax)을 만나면, 정확한 구문의 기술을 제공하는 문서화 지시자(documentation directive)

를 포함하며,

상기 클래스는 기본 클래스로부터 파생되고 - 상기 기본 클래스는 복수의 지시자들의 카테고리들을 포함하고, 각각의 지시자들의 카테고리 아래에는 하나 이상의 지시자가 있음 -,

상기 클래스의 복수의 지시자들은 상기 기본 클래스의 대응하는 지시자들의 카테고리로부터 파생되거나, 또는 상기 클래스에 대한 명령의 개발자에 의해 확장되는, 컴퓨터 판독 가능 저장 매체.
제1항에 있어서, 상기 한정적인 정보는 상기 개체의 멤버에 대한 멤버 이름(member name)을 포함하고, 상기 멤버 이름은 상기 예정된 파라미터에 대한 한정자(qualifier)에 대응되고, 상기 한정자는 상기 명령이 호출된(invoked) 경우에 상기 예정된 파라미터들에 선택적으로 제공되는, 컴퓨터 판독 가능 저장 매체.
제1항에 있어서, 상기 한정적인 정보는 데이터타입(datatype)을 포함하고, 상기 데이터타입은 상기 예정된 파라미터에 대한 데이터 형식을 지정하는, 컴퓨터 판독 가능 저장 매체.
제1항에 있어서, 상기 복수의 지시자들은 상기 예정된 파라미터를 상기 한정적인 정보에 맵핑시키기 위한 규칙을 지정하는 파싱 지시자(parsing directive)를 더 포함하는, 컴퓨터 판독 가능 저장 매체.
제1항에 있어서, 상기 복수의 지시자들은 상기 예정된 파라미터에 대해 수행되는 검증(validation) 프로세스를 지정하는 데이터 검증 지시자(data validation directive)를 더 포함하는, 컴퓨터 판독 가능 저장 매체.
제1항에 있어서, 상기 복수의 지시자들은 상기 예정된 파라미터에 기초하여 데이터의 세트를 생성하기 위해 호출되는 서비스를 지정하는 데이터 생성 지시자(data generation directive)를 포함하고, 상기 데이터 생성 지시자는 입력 파라미터들에 고유한 프로세싱이 발생할 수 있게 하는, 컴퓨터 판독 가능 저장 매체.
제1항에 있어서, 상기 복수의 지시자들은 상기 예정된 파라미터에 수행되는 부가적인 프로세싱을 지정하는 지시자를 더 포함하는, 컴퓨터 판독 가능 저장 매체.
명령에 입력되는 파라미터들에 대해 반영 기반 프로세싱(reflection-based processing)을 수행하는 시스템에 있어서,

상기 시스템은,

프로세서; 및

메모리 - 상기 메모리는 상기 프로세서에 의한 실행을 위하여 상기 메모리에 로드(load)되는 복수의 컴퓨터 실행 가능 명령어들을 위하여 할당됨 -

를 포함하고,

상기 컴퓨터 실행 가능 명령어들은,

명령과 연관된 식별자를 포함하는 파싱 가능한 스트림을 수신하는 단계;

상기 명령에 대하여 예정된 파라미터를 기술하는 식별자에 기초하여 한정적인 정보를 검색하는(retrieving) 단계 - 상기 한정적인 정보는 프로세싱될 수 있는 스트링(string)들 및 모음(collection)들에 대한 구체적인 크기 제한들을 포함함 -;

상기 한정적인 정보에 기초하여 개체를 생성하는 단계;

상기 예정된 파라미터와 연관된 상기 한정적인 정보에 따라 상기 개체의 상기 파싱 가능한 스트림으로부터 획득되는 파라미터를 저장하는 단계;

상기 파싱 가능한 스트림에 복수의 지시자들을 적용하는 단계 - 상기 복수의 지시자들은, 요청되면, 상기 예정된 파라미터에 대한 텍스트형 정보를 생성하고, 유효하지 않은 구문을 만나면, 정확한 구문의 기술을 제공하는 문서화 지시자, 및 상기 예정된 파라미터의 입력을 위한 사용자 인터페이스를 결정하는 상호 작용 지시자 - 상기 예정된 파라미터가 상기 파싱 가능한 스트림에서 수신되지 않으면, 상기 상호 작용 지시자가 적용됨 - 를 포함함 -; 및

상기 명령에 대해 상기 개체를 제공하는 단계 - 상기 개체는 상기 명령에 의해 호출될 수 있는 메소드(method)를 포함함 -

를 포함하는 방법을 수행하며,

상기 한정적인 정보 및 상기 복수의 지시자들은 반영 기반 셸(reflection-based shell)로부터 파생되거나, 또는 상기 명령의 개발자에 의해 확장되고,

상기 반영 기반 셸은 하나 이상의 지시자들의 카테고리들을 제공하고, 각각의 지시자들의 카테고리 아래에는 하나 이상의 지시자가 있고,

제1 명령과 연관된 상기 한정적인 정보 및 상기 복수의 지시자들은 제2 명령과 연관된 상기 한정적인 정보 및 상기 복수의 지시자들과는 상이한, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 상기 컴퓨터 실행 가능 명령어들은 상기 한정적인 정보와 연관된 지시자에 따라 상기 파라미터에 대해 프로세싱을 수행하는 지시자를 상기 파라미터에 적용하는 단계를 더 포함하는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 상기 파싱 가능한 스트림이 상기 한정적인 정보에 기초하여 상기 파싱 가능한 스트림을 자동 완성(autocomplete)하기 위하여 생성되고 있을 때에 인텔리센스(intellisense)를 제공하는 단계를 더 포함하며,

상기 자동 완성은 상기 파싱 가능한 스트림의 명확하게 한 부분(disambiguating portion)을 수신할 때 발생하는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 상기 파라미터를 상기 개체와 연관된 상기 예정된 파라미터와 상관시키는(correlate) 파싱 지시자(parsing directive)를 적용하는 단계 - 상기 파싱 지시자는 상기 한정적인 정보와 연관되고, 상기 파싱 지시자는 상기 개체의 문법이 상기 파싱 가능한 스트림에서 수신된 파라미터의 구문으로 변환되는 방식을 지정하는 규칙들의 세트에 기초하여 상관시킴 -;

상기 파라미터의 구문을 확인하는(verifying) 단계;

상기 문서화 지시자로부터의 구문 정보에 기초하여 상기 파라미터의 구문을 교정하는(correcting) 단계; 및

상기 개체를 상기 파라미터들로 파퓰레이트하는(populating) 단계

를 더 포함하는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 사용자로부터 상기 파라미터를 요청하는 것을 포함하여, 상기 파라미터를 획득하기 위한 방식을 결정하는 파싱 지시자를 적용하는 단계 - 상기 파싱 지시자는 상기 한정적인 정보와 연관됨 -;

상기 파싱 가능한 스트림이 상기 개체에 요구되는 필수적인 파라미터(necessary parameter)를 포함하지 않는 것으로 판단하는 단계;

플래그를 디스플레이함으로써 상기 필수적인 파라미터가 필요로 됨을 나타내는 단계 - 상기 플래그는 상기 필수적인 파라미터를 공급하기 위하여 사용자 상호 작용의 허용 가능한 수준을 나타내고, 상기 사용자 상호 작용의 수준은 사용자 수준, 그룹 수준 및 기업 수준을 포함함 -; 및

상기 사용자로부터 상기 필수적인 파라미터를 요청하는 단계

를 더 포함하는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 상기 파싱 가능한 스트림이 상기 한정적인 정보와 연관된 데이터 검증 지시자에 의해 지정된 기준(criterion)을 만족하는지 여부를 판단하기 위하여 상기 데이터 검증 지시자를 적용하는 단계; 및

상기 데이터 검증 지시자를 적용하는 단계에 응답하여, 검증 에러 메시지를 생성하는 단계 - 상기 검증 에러 메시지는 상기 문서화 지시자로부터의 정보를 포함함 -

를 더 포함하는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 상기 개체에 저장되는 정보의 세트를 생성하기 위하여 상기 파라미터에 데이터 생성 지시자를 적용하는 단계를 더 포함하고,

상기 데이터 생성 지시자는 상기 한정적인 정보와 연관되고,

상기 데이터 생성 지시자는 파일 이름들, 사용자 이름들 및 프로세스들 중 하나 이상의 와일드카드 확장(wildcard expansion)을 제공하는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
제8항에 있어서, 상기 개체에 상기 명령에 대한 파라미터를 제공하기 전에, 상기 파라미터를 조작하기 위하여 상기 파라미터에 제2 프로세싱 지시자(processing directive)를 적용하는 단계를 더 포함하고,

상기 제2 프로세싱 지시자는 개체들이 인코딩되는 구체적인 타입을 포함한 상기 한정적인 정보와 연관되는, 명령에 입력되는 파라미터들에 반영 기반 프로세싱을 수행하는 시스템.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제