KR100314262B1 - 그래픽언어기술프로세스내다수도구사용대화식컴퓨터프로그램개발방법및그장치 - Google Patents

Abstract

본 발명의 방법 및 시스템은 사용자(16)가 소프트웨어 개발에서 사용되는 것과 같은 일련의 프러시져(procedure)들에 따른 업무를 달성하도록 지원한다. 개발되는 소프트웨어의 프로세스 명세서는 지원시스템에 의해 예증되며, 이에 따라 지원시스템(8)은 사용자에게 소프트웨어 개발에 관련된 일련의 선택들을 제공한다. 각각의 선택 사항들은 다수의 시스템 도구들(22)을 제공하며, 각 도구들은 병렬로, 동시에 작동하여 소프트웨어 개발을 위해 사용된다. 지원시스템은 모든 작업시 자동적으로 프로세스를 관리하고 검사하며, 사용자에게 작업코스를 제시하는 것은 물론 에러 분석을 제공한다. 이 시스템은 사용자에게 어려운 개발 과정을 따르도록 요구하지 않고 유연한 지원을 제공한다.

Description

[발명의 명칭]

소프트웨어 개발 지원 시스템(SYSTEM DEVELOPMENT SUPPORT)

[도면의 간단한 설명]

제 1 도는 형식화된 프로세스(process) 명세서를 작성하기 위한 절차를 설명하는 블록선도이다.

제 2 도는 형식화된 프로세스 명세서를 기계어로 번역하기 위해 필요한 절차를 설명하는 블록선도이다.

제 3 도는 본 발명에 사용될 수 있는 엑스퍼트(expert) 시스템의 주요 구성원을 나타내는 블록선도이다.

제 4 도는 본 발명의 지원시스템의 주요 구성원을 나타내는 블록선도이다.

제 5 도는 소프트웨어 프로세스의 대화식 지원에서 이행되는 절차를 순차적으로 설명하는 흐름도이다.

제 6 도는 본 발명의 브라우징 특성을 나타내는 흐름도이다.

제 7 도는 도구(tool)의 기능들의 시동과 작동을 설명하는 흐름도이다.

제 8 도는 본 발명의 지시에 따라 하나의 기능을 수행하는 요소들을 나타내는 블록선도이다.

제 9a 도 - 제 9c 도는 본 발명에 따라 데이타를 처리하는 여러가지 방법을 나타내는 흐름도이다.

제 10 도는 제 9 도의 다음 과정을 나타내는 데이타 처리방법의 흐름도이다.

제 11 도는 데이타 처리방법에서 그래픽 심볼의 사용을 설명하는 흐름도이다.

제 12 도는 본 발명에 따른 데이타 검색방법을 설명하는 흐름도이다.

제 13 도는 데이타 처리방법의 그 다음과정, 특히 본 발명의 원리에 따른 작업의 실행을 나타내는 흐름도이다.

제 14 도는 본 발명에 따라 도구에 의해 지원되지 않는 작업의 실행을 도식적으로 설명하는 흐름도이다.

제 15 도는 데이타 처리 과정의 완결부분을 설명하는 흐름도이다.

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

8 : 지원시스템(support system) 12 : 보조장치

16 : 사용자

20 : 엑스퍼트 시스템(expert system)

22 : 도구들(tools)

30 : 지식베이스(knowledge base)

32 : 추론 엔진(inference engine)

34 : 규칙베이스(rule base)

36 : 데이타베이스(data base)

38 : 엑스퍼트(expert) 40 : 유도엔진(induction engine)

41 : 컴퓨터 42 : 보조 논리 모듈

44 : 보조 논리 인터프리터(assistart logic interpreter)

46 : 메세지 핸들러(message handler)

48 : 사용자 인터페이스(user interface)

90 : 브라우져 서버(browser server)

[발명의 상세한 설명]

본 발명은 일련의 과정에 따라 소프트웨어를 개발하는 시스템 및 특히 컴퓨터 프로그램 설계에 관계된 많은 방법에서 발견되는 것과 같은 일련의 과정에 따라 과거, 현재, 미래에 처리되어져야하는 작업을 자동적으로 관리, 기록, 제시하는 대화식 지원시스템에 관한 것이다.

수년동안 컴퓨터 소프트웨어 개발자 및 프로그래머들은 복잡한 컴퓨터 프로그램의 제작과 관련된 정신적 부담감을 해소시킬 수 있는 도구들을 요망하고 추구해왔다. 과거에 소프트웨어 개발은 프로그램의 진행과 관련된 모든 상세한 사항 및 이와 관련된 문서화, 명세화 등에 프로그래머의 특별한 주의력을 요구해왔다. 컴퓨터 소프트웨어는 제작되고 시험되어, 그 구성요소들을 개선하므로써, 프로그래머가 바라는 제품을 생성할 때까지 재구성된다. 컴퓨터 소프트웨어들은 그 크기와 복잡성이 계속 증가하고 있기때문에 하나의 소프트웨어를 작성하기 위한 프로그래머의 인원수도눈부시게 계속 증가해왔다. 결국 각각의 프로그래머들은 최종적으로 상호작용하게 구성된 전체 소프트웨어의 일부분을 설계하게될 것이다. 이렇게 될 때 일관성과 균일성의 문제가 발생하게 된다. 예를 들어, 어떤 프로그래머가 자신이 작성한 프로그램의 일부를 수정하게 되면, 프로그램 다른 부분들이 영향을 받게 되어, 그 부분들을 담당하는 프로그래머들은 주의를 요하게 된다. 그러므로, 복잡한 컴퓨터 프로그램의 제작시, 소프트웨어 개발자들을 추적하고 지원해 줄 수 있는 개발 지원 시스템이 필요하게 된다.

이것에 대한 한가지 해결책이 겐드론(Gendron)에 의해 출원된 미국특허 4,860,204 에서 보여지고 있는데, 여기에서 사용되는 워크스테이션(workstation)은 도식화된 표현을 사용하여 프로그램을 제작하게 되어 있다. 겐드론의 워크스테이션에 기초한 컴퓨터는 작업자가 도식화된 프로그램 블록들을 함께 결합하여 원하는 기능을 가진 프로그램을 작성하도록 해준다. 겐드론 시스템에서는 상호 연결된 프로그램의 완전성을 시험하고 있을때, 유력한 작업코스 및 작업자에 의해 취해진 작업의 결과를 자동적으로 제시하지 못하고 있다.

유사하게, 아프샤(Afshar)에 의해 출원된 미국특허 4,734,854에는, 공통으로 필요한 컴퓨터 기능을 수행하는 범용 프로그램모듈들을 설계하기 위한 시스템이 나와 있다. 사용자는 이 범용모듈을 특수한 또한 구체적인 소프트웨어 안에 통합시킬 수 있으며, 아프샤 시스템은 자동적으로 특정 소프트웨어에 적합한 범용 모듈의 구체적인 버젼을 생성하게 된다. 이 시스템은 약간의 자동화된 특성을 갖고 있는 반면, 소프트웨어 개발시 어느 범용시스템 또는 도구가 필요한가를 사용자에게 알려주지 못하며, 또한 개발을 위한 대안도 제시하지 못한다.

그러나 최근 컴퓨터 지원 소프트웨어 엔지니어링(Computer-Aided Software Engineering, "CASE")환경은 개발에 도움이 될 뿐만 아니라 많은 경우에, 컴퓨터 지원설계("CAD") 시스템이 복잡한 하드웨어 프로젝트에 필수적인 것처럼 복잡한 소프트웨어프로젝트에 필수적인 것이 되었다. 소프트웨어 엔지니어링 환경은 오퍼레이팅 시스템(OS) 환경 및 개발용 컴퓨터 프로그램에 의해 생성된 조건들의 영역에서 작용하는 도구들이나 서브루틴(subroutine)들의 모임과 관계가 있다. 예를 들면 레블랑등에 의해 출원된 미국특허 4,809,170 은 컴퓨터 지원 소프트웨어엔지니어링의 응용을 위한 지원 시스템을 설명하고 있다. 레블랑의 지원 시스템은 개발 시스템에서 생긴 변화를 관리하고, 앞으로의 검색을 위해 그러한 변화를 기록한다. 더우기 이 시스템은 시스템의 동시 작업들에게 그 변화를 통지한다. 그러나 레블랑은 여러가지 프로그램 제작 도구들을 자동적으로 불러오고 사용자에게 대화식으로 제안을 하는 지원 시스템을 제시하지 못한다.

초기의 소프트웨어 엔지니어링 시스템들은 소프트웨어 개발지원이론 및 목적과 함께 아래의 잡지 기사에서 일반적인 용어로 기술되어 있다.

그리피스(Griffiths)외, "앨프(ALF : 피시티이(PCTE)상에서 그처리모델 및 수행", 에스프리 앨프 프로젝트, 기술논문 1989.

카이저(Kaiser)외, "소프트웨어 개발 및 유지를 위한 인텔리전트 컴퓨터 지원", IEEE 소프트웨어, 1988.

클렘(Clemm), "번역 관리를 업무 관리로 대치함", 컴퓨터 장치협회, 1989.

더우기 CASE 시스템은 코드 생성과는 다른 방법으로 사용자를 돕는다. 예를 들면, 프로그램의 특정 부분을 수정하는 소프트웨어개발자들에 의해 취해진 작업은 프로그램 모듈 요소들에 영향을 미칠뿐만 아니라 또한 그 프로그램의 다른 비코드(non code)요소들에도 영향을 미치게 된다. 프로그램의 성능을 향상시키기 위해서는 프로그램의 설계 사양, 사용자 매뉴얼 및 온라인 도움말화일들의 개선이 요구된다. 또한 그 프로그램을 사용하는 사람들에게 변화를 알려주고, 개선된 프로그램을 위한 플로피 디스크를 제작하며, 새로 제작된 디스크를 프로그램머와 사용자들에게 전달해주는 그러한 오프라인(off-line) 업무가 수행되어야 한다. 소프트웨어 개발 과정은 단지 프로그래밍 작업보다 훨씬 많은 것을 지원해야 한다.

오늘날 산업용 컴퓨터 프로그램 개발은 특정 소프트웨어가 전개되는 방법 및 절차를 설계하는 것에서부터 시작된다. 이러한 설계는 완성을 위해 수많은 단계가 필요한 복잡한 과정들은 물론 수많은 표준들을 포함하게 된다. 앞의 소프트웨어 지원 시스템들은 특정한 업무를 완수하기 위한 여러가지 도구들을 모아놓은 "도구상자들(toolboxes)"을 포함하고 있다. 이러한 지원 시스템에서 사용되는 도구들에는 에디터(editors), 컴파일러(compiler) 플로우 차트 에디터(flow chark editors)등이 포함되어 있다. 프로그래머들은 정확한 도구를 선택하고, 여러가지 프로그램요소들 사이의 일관성을 확보할 책임이 있었다.

다른 소프트웨어 지원 시스템들에는 소프트웨어에 의해 소프트웨어 프로세스를 기술하는 "프로세스 프로그래밍" 기술들이 포함되어 있다. 프로세스 프로그래밍은 소프트웨어로써 소프트웨어 프로세스들을 수행한다. 이러한 접근 방법은 형식화된 프로그래밍 언어에 의한 소프트웨어 처리의 많은 가능성을 설명하고 있으며, 컴퓨터는 이러한 프로세스들을 기계어로 번역하여 사용자가 특정 업무를 수행할 수 있도록 도와준다. 기존의 프로세스 프로그래밍 기술들은 소프트웨어 개발 지원수단으로써 충분히 작용할 수 있는 반면, 사용자에게 신축성있는 지원을 제공하지 못한다. 그대신 기존의 프로세스 프로그래밍은 사용자가 개발과정에서 여러가지 다른 단계를 거쳐 진행하도록 강요한다. 그러나 사용자들은 프로세스 프로그래밍 기술에 의해 부과된 강제적인 통제를 마지못해 받아들이고 있다. 소프트웨어 개발과정이 효과적으로 되기 위해서는, 사용자에 의해 취해진 작업을 관리하고, 사용자가 앞의 개발과정과 일관된 여러방향에서 작업을 진행할 수 있게 하며, 사용자의 작업 내용을 기계어로 번역하여 수행된 작업을 도와주는 더욱 신축성있는 지원시스템이 필요하게 된다. 그러므로, 복잡한 컴퓨터 프로그램의 개발을 위해 신축성있는 방법으로 프로그래머 및 엔지니어들을 지원할 수 있는 "대화식 프로세스 프로그램" 지원 시스템 기술이 필요하다.

본 발명의 한 실시예에서는 특별한 소프트웨어 프로세스를 통해 소프트웨어 제품을 개발하는 대화식 지원방법이 제공되어 있다. 이 방법은 첫단계로서 소프트웨어 개발에 사용되는 일련의 단계들에 관계하는 소프트웨어 프로세스를 특정 언어로 기술된다. 이렇게 기술된 프로세스는 명령어 해석기(interprter)에 의해 번역될 수 있는 형태로 변형되어야 한다. 번역시, 대화식 지원방법은 선택 매뉴를 표시하여 특정 소프트웨어 과정에 적절한 작업매뉴를 선택하도록 제시한다. 이때 사용자가 어느 하나를 선택하면 많은 시스템 도구들중 하나가 사용되어 작업을 수행한다. 또한 사용자는 도구의 작업을 직접 시동시킬 수 있다. 도구를 통해 수행된 모든 작업의 결과는 그것이 프로세스에 적절한가를 보기 위하여 추적되어진다. 작업 결과의 분석이 진행되고, 그 결과 다른 시스템 도구들 또는 다른 도구의 작업들이 자동적으로 시작된다. 계속해서 사용자는 전단계들에 비춰 개발의 현재상태를 나타내는 정보를 제공받는다.

본 발명의 방법은 형식화된 프로세스 명세서 내용에 들어있는 일관성 검사를 포함하고 있다. 이러한 일관성 검사는 각 시스템도구들의 사용후에 진행되어 이때 발견되 오류들이 사용자에게 보고된다. 이 방법의 부가적 요소로써, 개발과 관련된 데이타베이스에 개발된 객체들의 일람이 가능하다. 이러한 특정객체의 탐색은 브라우져(browser) 프로그램의 유용한 시스템도구들을 자동시키므로써 가능하게 된다.

또다른 면에서, 본 발명은 특정 소프트웨어 프로세스를 통한 소프트웨어 개발시 대화식 지원방식을 제공하는 컴퓨터 시스템에 관한 것이다. 대화식 지원시스템은 형식화된 프로세스 명세서를 입력하고 저장하기 위한 수단이다. 더우기, 프로세스 명세서를 기계어로 번역이 가능한 형태로 변형시키기 위한 도구가 이시스템안에 제공되어 있다. 명령어 해석기인 인터프리터(interpreter)는 논리적인 인터프리터에 전자적으로 접근할 수 있는 데이타베이스는 물론 엑스퍼트(expert) 시스템을 포함하고 있다. 논리적인 인터프리터에 전자적으로 연결되어 있는 메시지핸들러(message handler)는 명세화된 프로세스에 관련된 특정업무를 수행하도록 구성되어 있는 한패의 시스템 도구들과의 통신을 처리한다. 결국 사용자 인터페이스(interface)는 시스템의 사용자와 그래픽을 통해 통신하게 하며, 또한 사용자가 입력하는 것을 가능하게 한다.

지원 시스템의 사용자가 행하는 모든 것들은 목표의 완성, 예를들면 새로운 소프트웨어 제품을 창조하는 일에 관계될 수 있다. 지금부터 프로세스라는 용어는 이러한 목표를 완수하기 위해 필요한 단계를 나타내기 위해서 사용되며 또한 이러한 단계가 진행되는 순서를 나타낸다. 프로세스들은 설계자의 작업을 구조화하는 자연스러운 방법이다. 그러므로 프로세스의 명세화는 의도한 목표를 달성하기 위해 설계자가 어떻게 최선의 방법으로 업무를 진행해야 하는가에 대한 전문가의 주의깊은 분석의 결과이어야 한다. 본 발명에서는 프로세스를 형식적으로 명세화하기 위하여, PDL(Process Description Language)이라 불리는 특수한 언어가 사용된다. 프로세스에 의해 정의된 작업을 하는 설계자를 돕기 위해서 PDL 로 기술된 명세서는 실행 가능해야하며, 그렇지 않으면 그것은 단지 교과서적인 표현에 지나지 않을 것이다. 명세화된 프로세스를 실행하므로써 시스템의 사용자는 바라는 목표에 도달하는데 필요한 모든 절차를 통해 시스템으로부터 안내를 받게 된다.

본 발명은 두개의 특징적인 요소를 포함하고 있다. 첫째로는 프로세스 요소(process element)이고 둘째는 지원 요소이다. 지원을 받기 전에 지원을 받는 프로세스가 위에 기술된 PDL 을 사용하여 형식적으로 명세화되어야 한다. 그리고나서 이 프로세스명세서는 수정된 형태에서 프로세스 명세서 인터프리터로 입력되고, 그것에 의해 지원 시스템은 목표의 달성을 위해 지원을 할 수 있게 된다. 그러므로 제 1 도는 프로세스 명세화의 초기단계를 설명하고 있다. 프로세스 필요조건이 블록(300)에서 분석되어 프로세스의 비형식적인 모델이 블록(302)에서 생성된다(예를들면, 교과서적인 표현의 명세서). 블록(300)과 (302)에서 우리는 어떤 결과가 생산되어야 하며, 그 프로세스에서 어떠한 여러가지단계가 취해져야 하는가에 대한 비형식적인 명세서를 얻게 된다. 다음에 PDL 프로세스 명세서가 블록(304)에서 작성되며, 블록(306)에서는 데이타 구조와 같은 프로세스의 정보 모형이 제작된다.

PDL 명세서는 특정회사의 요구나 또는 특수한 목적, 예를 들면 미래 설계, 결점보고 등을 위해 특별히 제작된 프로세스들의 개발에 전문가이며 지원 시스템을 맡고 있는 시스템 설계자들에 의해 만들어진다(보통 사용자들도 원리적으로 프로세스 명세서를 설계할 수 있다). 예를 들면, PDL 명세서는 다수의 기본특성을 갖고 있다. 첫째, 하나의 프로세스는 여러개의 분리된 하위 프로세스들로 나뉘어지며, 각 하위 프로세스들은 다른 하위 프로세스들에 의해 기술되는 작업과 병렬로 이행될 수 있는 작업들을 기술하므로써 생산성을 향상시킨다. 이것은 설계자가 다수의 컴퓨터도구들이 병렬로 실행 될 수 있는 현대적인 워크 스테이션을 사용할 때 직면하게 되는 상황에 매우 적합하게 된다. 도구들 각각은 PDL 을 사용하여 몇개의 프로세스로 기술되며, 그 하위프로세스는 도구들을 통해 수행되어야 하는 것과 도구들이 다른 하위 프로세스 또는 다른 도구들과 상호작용하는 방법을 기술한다. 둘째로, PDL 명세서는 여러가지 하위 프로세스들에 의해 기술된 작업들이 상호작용하는 방법을 프로세스들간에 비동기로 통신되는 내용을 명세화하므로써 기술하고 있다. 셋째, PDL 명세서는 특정하위 프로세스의 시작과 끝을 위한 조건을 기술하고 있다. 넷째, PDL 명세서는 하나의 하위 프로세스, 예를 들면 에디트(edit), 컴파일(compile), 링크(link)등을 포함하는 여러가지 단계들 및 작업들을 기술하며, 또한 그러한 작업들의 각각에 대해 그 단계 또는 작업이 시작되기 위해 이행되어야 하는 필요조건을 기술하고 있다. 마지막으로, PDL 명세서는 프로세스의 상태에 관한 정보를 제공하는 방법과 프로세스의 현재 상태에서 실행하기에 적당한 단계들을 지시하므로써 사용자와의 상호작용을 가능하게 한다.

사용자 자신이 직접 선택하며, 지원 시스템이 사용자에게 어떤 일련의 작업을 하도록 제한하는 방해물로써 인지되는 것을 피하기 위해, PDL 명세서에는 오직 프로스세의 상태만이 어떤 작업이 수행되어야 하는가를 결정해야 한다. 즉 이것은 작업이 수행되는 순서가 중요한 것이 아니라는 것을 말한다. 둘째, PDL 명세서는 프로세스의 현재 상태에 적절하며 사용자가 자유롭게 선택할 수 있는 다수의 제안을 사용자에게 제공하므로써 신축성을 가져야한다. 그리하여, 지원 시스템은 사용자에게 특정한 작업을 선택할 것을 강요하지 않게 된다. 셋째, 사용자는 본 발명에 의해 제공된 선택권을 사용하지 않고 직접 작업을 수행할 수 있어야 한다. 이러한 PDL 명세서의 세가지 특성들은 설계자가 해야 하는 여러가지 작업들이 너무 융통성 없는 것으로 인지되지 않도록 한다.

제 2 도에서 제 1 도에서 정의된 프로세스의 PDL 명세를 실행하고, 그러므로써 몇개의 특정 프로세스를 지원하기 위해 취해져야 하는 단계들이 나타나 있다. 먼저 프로세스의 PDL 명세서가 블록(350)에서 작성된다. 이 명세서는 분석되어 블록(352)에서 지원 논리 인터프리터를 위해 적당한 형식으로 바뀌게 된다. 적당히 형식화된 명세서는 블록(354)의 지원 논리인터프리터(44)(제 4 도)로 적재되므로써 시스템이 사용자에게 필요한 지원을 제공할 수 있게 된다. 이러한 단계들은 시스템프로그래머에 의해 취해져 지원 시스템이 PDL 명세서에 표현된 지원을 제공하도록 만든다. 그러므로 이것은 본 발명의 두번째 특징요소, 즉, 지원요소를 구성한다. 사용자가 특정한 프로세스에 의해 명세화된 작업을 수행하려고 결정했을 때, 지원 논리인터프리터(44)는 PDL 명세서의 변형된 형식을 기계어로 번역하기 시작하며, 그렇게 하므로써 설계자가 그의 업무를 완수하도록 지원한다. 그러므로 PDL 은 지원논리, 즉 작업방법을 기술하기 때문에 PDL 명세서를 달리 "지원논리"라 부르기도 한다.

지원논리의 실행시 다수의 "그림자"(shadow) 객체들이 생성된다. 이 객체들은 설계자가 작업의 일부로써 만들고, 함께 작업하는 "실"(real) 객체, 화일들, 명세서 등을 기술하고 있다. 이 그림자 객체는 지원논리에서, 작업을 명세화하는 프로스세에 관한 실객체들 각각의 상태를 추적하기 위해 사용된다. 실객체들의 상태를 추적하므로써, 새로운 조치가 적당한 것인가를 검사하게 되며, 적당할 경우 이러한 조건들을 사용자에게 제시하게 된다. 이 그림자 객체들은 제 1 도에서 기술된 정보모형(information model)의 일부이다.

제 3 도에, 본 발명의 엑스퍼트 시스템(20)과 유사한 엑스퍼트시스템의 주요성분들을 설명하는 블록선도가 나타나 있다. 전형적인 엑스퍼트 시스템은 시스템 그 자체의 생성시 축적되는 지식의 총체에 의존한다. 이 지식의 총체는 엑스퍼트 시스템(20)의 지식 베이스(30)안에 들어있다. 지식 베이스(30)안에 저장되는 정보는 지식 베이스(30)의 범주 유닛(unit)과 개별유닛안으로 분리된다. 이러한 면은 지식 베이스(30)에 포함된 #1KB와 #2KB를 통해 보여진다. 지원 시스템(8)의 적절한 작동을 위해 요구되는 지식은 명료하고 엑스퍼트 시스템(20)에 접근(access)이 가능해야 한다.

엑스퍼트 시스템(20)의 보편문제 해결요소는 추론 엔진(32)을 포함하고 있다. 추론 엔진(32)은 규칙 베이스(34)안에 저장되어 있는 규칙들을 불러낸다. 추론 엔진(32)은 규칙 베이스(34)에 저장되어 있는 규칙들이 어떻게 문제에 바로 적용되며 어떠한 순서로 실행될 것인가를 결정하게 된다. 엑스퍼트 시스템(20)에서 많은 규칙들은 해결책 발견을 위한 간단한 방법들로 구성된 발견적 형태를 갖고 있다. 작동시, 추론 엔진(32)은 데이타 베이스(36)안에 있는 데이타를 자세히 조사하여 규칙 베이스(34)의 기준에 데이타를 맞추게 된다. 차례로 규칙 베이스(34)에 관계한 발견적 해결방법이 지식 베이스(30)를 위한 정보를 발생시킨다. 처음에 프로세스에서 사용된 규칙들은 특별한 순서없이 엑스퍼트(38)로부터 발생한다. 더 나아가서 지식 베이스(30)안에 있는 정보는 엑스퍼트 시스템이 작동하고 있는 동안에 실시간 갱신된다.

또한, 규칙 베이스(34)의 규칙들을 생성하기 위해 유도 엔진을 사용하여 엑스퍼트 시스템을 가동시킬 수 있다. 유도 엔진(40)은 지식 베이스(30)안에서 발견되는 특정 정보로부터 프로세스에 적용할 수 있는 보편 원리들을 끌어낸다. 엑스퍼트(38)는 직접규칙들을 제공하거나 또는 유도 엔진(40)에 의해 규칙들로 변환될 수 있는 예제들을 제공할 수 있다.

제 4 도를 참조하면 본 발명에 따른 지원 시스템의 구성부품을 설명하는 블록선도가 보여지고 있다. 본 발명의 우선 실시예는 컴퓨터를 기초로 한 시스템이기 때문에 컴퓨터의 장점을 이용하기 위하여 미리 확립되어 있는 일련의 논리문(즉, 프로그램 및 펌웨어)을 실행시키고 메모리로부터 읽어들이거나 메모리에 기억시키기 위해 적합한 컴퓨터(41)안에 존재한다. 지원시스템(8)의 작업 중간에 보조장치(12)가 있다. 이 보조장치(12)는 보조논리 모듈(42)와 보조 논리 인터프리터(44)를 포함하고 있다. 보조 논리 모듈(42)는 프로세스를 정의하며 성취목표를 나타내는 위에 설명되어 있는 변환된 PDL 명세서를 포함하고 있다.

보조 논리 인터프리터(44)는 엑스퍼트 시스템(20)을 포함하고 있다. 한 우선 실시예에서, 엑스퍼트 시스템은 인텔레코프회사에서 제작한 프로카파 언어로 프로그램되어 있다. 본 발명은 작업을 더욱 간편하게 하기 위하여 제공된 프로토크(ProTalk)언어에 그래픽을 추가하고 있다. 보조장치(12), 특히 보조 논리 인터프리터(44)는 메세지 핸들러(message handler)(46)을 통해 지원시스템안에 있는 컴파일러와 에디터를 포함한 도구들과 통신을 한다. 여기서 이 도구들은 컴파일러와 에디터에 제한되지는 않는다. 도구와 도구의 기능들은 프로세스가 표현되는 기본 구성블록이며 또한 프로세스가 지원시스템에서 수행되는 방법이다. 이러한 방법으로 대부분의 프로세스 특정 지식은 도구 대신에 PDL 명세서에 할당될 수 있다. 그러므로 여러가지 도구들은 다른 프로세스들에서 다시 사용되기 쉽고, 또한 도구들은 프로세스가 수정되었을 때에도 바뀔 필요가 없다. 또한 데이타베이스(36)가 보조장치(12)에 연결되어 있다. 데이타베이스(36)은 보조 논리 인터프리터(44)와 보조논리(42)를 위해 미리저장된 프로세스정보에 접근을 제공하는 것은 물론 일반적으로 지원시스템(8)에 의해 발생되거나 처리된 정보를 저장한다.

지원 시스템(8)을 사용할 때 생산성을 증가시키기 위하여 각각의 도구들(22)은 서로 병렬로 작동한다(만일 유닉스 플랫폼(UNIXplatform)에서 수행된다면 여러가지 유닉스 프로세스에서 병렬작동된다). 각 도구는 그 도구에 의해 취해진 작업의 핸재 상태에 관한 메세지를 교환하므로써 보조장치(12)와 상호 작용한다. 따라서 많은 동시 작업이 지원장치(8)안에서 발생하며, 그 각각은 보조장치(12)에 의해 관리되고 분석된다.

제 4 도에서는 또한 보조장치의 사용자 인터페이스 액티비티윈도우(user interface/activity window)(48)이 도시되어 있다. 사용자 인터페이스(48)는 사용자와 프로세스 상태를 통신하며, 사용자가 프로세스에 의해 정의된 작업을 수행하기 위한 안내역할을 한다. 사용자 인터페이스는 사용자에게 명백한 보조장치(12)요소만을 포함하고 있다. 엑스퍼트 시스템(20)은 진행중인 프로세스의 상황에서 사용자의 작업들을 사용자 인터페이스에서 만들어진 도구들이나 선택으로부터 받은 메세지를 통해 분석하며, 특별한 상황에 맞는 적절한 그래픽 정보를 발생시킨다.

사용자 인터페이스(48) 안에서, 정보의 통신은 여러가지 다른표현을 사용할 수 있다. 예를 들어, 표시된 정보는 리스트의 형태를 가질 수 있고 또는 그래픽 표현은 물론 플로우 차트의 형태를 가질 수도 있다. 사용가능한 다수의 인터페이스의 제 1 대용 인터페이스를 나타내는 블록(50)과 제 2 대용 인터페이스를 나타내는 블록(52)으로 도시되어 있다. 사용자는 자신의 기술과작업에 가장 적당한 인터페이스의 종류를 선택할 수 있다.

제 5 도에서는, 보조 논리 인터프리터(44)에 프로세스 명세서가 적재되었을때 보조장치가 실행되는 방법을 기술한 플로우차트가 더욱 상세하게 보여지고 있다. 플로우 차트로부터 보조장치(12)는 지원장치(8)의 부품들인 도구들(22)에 관련된 다수의 요소들에 의존한다. 먼저, 보조장치(12)는 도구들(22)을 작동시킬 수 있어야 하며 도구 기능들을 유발시켜야 한다. 이것은 통신을 담당하는 메세지 핸들러(46)를 통해 수행된다. 또한 도구들은 여러가지 발생하는 사건들을 기록해야 하며, 이 사건들의 대부분은 파일 수정, 인터페이스 명세서 생성, 프로그램 컴파일링 등과 같은설계 목표의 달성 및 프로세스의 상태와 관계를 가지기 때문이다. 어떤 사건이 보고되어야 하는가는 작업을 기술하는 프로세스명세서가 설계될 때 결정된다.

도구는 보조장치(12)와 통신할 수 있기 때문에, 보조장치액티비티 윈도우, 데이타베이스 브라우져, 또는 유닉스쉘 등 어느 곳에서 시작되는 것에 상관없이 지원시스템(8)은 사용자(16)가 보조장치에 의해 조정되는 액티비티 윈도우들(48-52)과 다른 수단에 의해 도구들을 시동시키는 것은 허락한다. 사용자는 또한 액티비티 윈도우들에서 제안으로서 반드시 나타나지는 않는 도구들로부터 직접 여러가지 도구 기능들을 수행할 수 있다. 따라서 보조장치(12)와 보조논리(42)는 여러가지 도구들로 부터 언제라도 발생한 사건을 처리할 수 있어야 한다. 이것은 사건이 발생했을 때 해야할일을 기술한 PDL 명세서가 사건이 발생한 순서를 참조하는 것이 아니라 프로세서의 현재 상태만을 참조하기 때문에 가능하게 된다(이것은 엑스퍼트 시스템의 트리거(triggering)메카니즘을 사용하여 가능하다). 따라서 모든 사건은 그것이 보조장치(12)로부터의 제안에 관련된 것인지의 여부와 관계없이 프로세스의 상태에 따라 처리된다.

또한 제 5 도에는 프로세스 흐름의 상세한 설명이 보여지고 있다. 블록(60)에서 시작하여, 사용자는 자신이 수행해야 하는 업무를 선택한다. 예로써 그 업무는 새로운 소프트웨어 제품의 설계 또는 에러 보고서의 처리등이 될 수 있다. 블록(61)에서, 보조장치(12)는 특정작업에 적절한 PDL 명세서를 선택한다(이것은 내부에서 자동적으로 처리된다). 이 명세서는 제 2 도에서 설명된 것처럼 전에 분석되고 변환되었다. 블록(62)로 진행되어 작업을 기술하는 프로세스의 현재 상태가 데이타베이스(36)로부터 보조장치(12)안으로 적재된다. 이러한 적재는 사용자가 앞서 업무를 진행하여 앞선 업무의 상태를 저장해 놓았을 때 가장 적절하다. 블록(63)에서 보조장치(12)는 프로세스의 현상태에 맞춰 취해져야 할 작업에 관한 제안을 하게 된다. 제안이 보여지는 방법은 사용되는 사용자 인터페이스에 의존한다.

블록(65)는 지원장치(8)에서 발생하는 사건들을 기다리는 보조장치를 나타내고 있다. 가지쳐진 블록(66)은 한 도구가 기능수행의 결과를 사건으로써 보조장치(12)에 보고하는 것을 나타내고 있다. 블록(66)에서 발생한 사건에 응답하여 블록(67)은 프로세스의 상태를 변화시키는데, 이 블록(67)은 지원 시스템에서 발생하는 사건들로부터 유래되기 때문이다. 사용자가 액티비티윈도우로부터 보조장치의 제한중 하나를 선택했다면, 블록(68)이 활성화될 것이다. 블록(68)에서 블록(69)로 진행이 되고 액티비티윈도우로부터 선택된 제안이 도구기능의 실행을 포함하고 있다면, 도구(22)는 필요하다면 시동되며 메세지 핸들러(46)을 통해 적절한 기능이 불려진다. 블록(70)으로 진행되면서 프로세스의 상태가 변화되며 도구기능의 실행이 반영된다. 그러나 사용자에 의해 선택된 제안이 도구기능의 실행을 포함하고 있지 않다면 프로세스의 내부상태는 단지 사용자에 의해 만들어진 선택을 통해서만 변화된다. 이 경우에 사용자(16)는 보통 약간의 수동작업이 프로세스에서 진행되었다는 것을 지시하게 된다.

상태변화가 일어난후에 블록(72)에서는 보조장치(12)가 변화의 결과를 추론하게 된다. 블록(72)에서 수행된 분석의 결과로써 보조장치는 블록(73)에 있는 다른 도구들을 자동적으로 시동시키게 된다. 더나아가서 블록(72)에서의 분석결과로써 여러가지 정보요소들 사이의 일관성 검사가 블록(74)에서 자동적으로 진행되어 이때 발견된 에러들은 블록(75)에서 보고된다. 추가적으로, 보조장치(12)는 블록(72)의 분석결과로서 자동 도구실행이 불필요한 것으로 판단하여 대신 사용자를 위한 새로운 제안들을 발생시킨다. 새로운 제안들은 새로 생성된 프로세스 상태에 기초하며, 이 프로세스 상태에서 싸이클이 반복된다. 그러나 사용자가 멈추기를 원한다면 그것은 블록(77)에서 발생하고 프로세스의 상태는 블록(78)에 저장된다.

제 6 도에서 지원시스템(8)의 독립적인 요소를 포함하고 있는 본 발명의 브라우져 서버(browser server)(90)를 설명하고 있다. 브라우져 서버(90)는 사용자(16)가 시스템 데이타베이스(36)에서 객체들을 찾는 것과 보조장치(12)의 지시없이 이러한 객체들을 선택하는 것을 허용한다. 브라우져 서버(90)는 사용자(16)에게 제안들을 제공하지 않는다. 명세서, 플로우 챠트, 프로그램들과 같이 발견된 객체들은 브라우져 서버(90)를 통해 조사되고, 객체위에 도구의 작동이 시작될 수 있다. 브라우져 서버(90)는 시작브라우져 블록(92)과 함께 시작된다. 브라우져 서버(90)를 시작하자마자 사용자는 블록(93)과 (94)에서 시스템 데이타 베이스(36)에 있는 객체들을 찾아 선택할 수 있다. 객체가 선택되었을 때 객체를 위해 유용한 작업 메뉴가 블록(95)에 표시된다. 블록(96)은 도구(22)를 시동시키며, 이 사실은 블록(98)에서 보조장치(12)에 보고된다. 이것은 어떤 사건이 발생하고 있는가를 알게되므로써 시스템의 보조장치 관점이 일관성 있는 것을 허용한다. 따라서 사용자(16)는 지원시스템(8)과 여러가지 방법으로 상호작용할 수 있는데, 이 방법중 하나가 브라우져 서버를 통해 보조장치로부터 지원을 얻는 것이다.

제 7 도에서 도구 기능 실행의 흐름선도가 나타나 있다. 사용자는 보조장치(12)의 도움없이 도구들(22)을 시동시킬 수 있기 때문에, 또한 사용자는 보조장치(12)에 의해 처리되는 액티비티윈도우에서의 제안들로써 반드시 보여지는 것이 아닌 여러가지 도구 기능들을 실행할 수 있다. 따라서 보조장치(12) 및 보조논리(42)는 어떤 주어진 시간에 여러가지 도구들로부터 일어나는 사건들을 처리할 수 있어야 한다. 이것은 사건이 발생했을 때 해야 할 일을 기술하고 있는 PDL 명세서가 위에서 언급된 바와 같이 작업이 수행되는 순서가 아니라 프로세스의 현재 상태만을 참조하기 때문이다. 그러므로 모든 사건들은 보조장치가 사건들을 제안에 의해 진행시키는 여부에 관계없이 프로세스의 상태에 의해 번역된다.

결과적으로 도구 설계자가 보조장치(12)에 의해 부과된 필요조건에 적응하기 위해 도구는 다음 방법으로 작동해야 한다. 먼저 도구기능은 블록(370)에서 시동되며 이 사실은 보조장치에 보고된다. 시동후 도구는 블록(371)에서 도구기능의 실행을 명령받을 수 있다. 도구 기능은 블록(372)를 거쳐 보조장치(12)를 통하거나 또는 블록(374)를 거쳐 도구 사용자 인터페이스를 통해 유도된다. 다음에 도구기능은 블록(376)에서 실행되며, 프로세스에 의해 요구된다면, 그 결과가 블록(378)에서 보조장치에 보고된다. 다시 프로세스에 적절한 도구 기능들(따라서 보조장치에 보고가 요구되는 기능들)이 프로세스의 설계시 결정된다. 이러한 싸이클이 반복되며, 도구는 유도블록(371)을 기다리는 것으로부터 시작되는 다음 도구 기능을 준비하며, 또는 블록(380)에서 정지한다.

제 9 도에서는 비서가 회의를 처리할 때 취해야 하는 여러가지 단계들을 도식적으로기술하고 있는 본 발명의 표준의 하나에서 주어진 보조를 상술하고 있는 전형적인 프로세스 명세서의 일례를 나타내는 PDL 선도가 보여진다. 프로세스 명세서는 그래픽 심볼을 통해 표현되기 때문에 제 9 도의 흐름선도는 다음의 논의에서 그러한 그래픽 심볼을 사용한다. 더우기, 지원시스템(8)은 그래픽흐름선도를 위에서 기술된 바와 같이 보조 논리 인터프리터에 의해 번역될 수 있는 형식으로 바꾼다.

제 9-15 도에서 보여진 텍스트(text) 정보는 흐름선도의 완전한 내용의 일부분이다. 각 그래픽 심볼은 그것에 수반된 여러 종류의 텍스트 정보를 가질 수 있다(비형식적인 주석, 암시적으로 또는 명백히 기술된 실행코드, 문서, 변수 명세서 등). 제 9-15 도에서 나타난 그림은 선도를 단순화하고 그들을 읽기 쉽게 만들기 위해 아이콘(icon)들을 위한 매개 변수 명세서들만을 보이고 있다. 이그림에서 변수들과 상수들은 매개변수들로써 상술되며, 변수들은 그것의 제 1 문자로서 물음표에 의해 표시된다. 이 언어를 지원하는 그래픽 에디터에서 이 그림은 앞서 기술된 모든 다른 그림들로 바뀔 수 있다.

제 8 도에서 PDL 아이콘들의 또다른 예가 나타나 있다. PDL에서 기본구성 블록은 액티비티의 조건과 결과를 기술하며 제 8 도에서 설명된 일반구조를 갖는 액티비티 구조물이다. 액티비티아이콘(386)은 한쪽이 전제조건 아이콘들(388)에 의해 쌓여 있다. 전제조건 아이콘들(388)은 실행될 액티비티에 대한 필요조건을 기술하고 있다. 예를 들면, 제 11 도에서 심볼들(140, 142) 및 (144)는 모든 전제조건들이다. 액티비티 아이콘(386)은 완전한 구조물 즉 모든 전제조건과 결과에 대한 참고로써 작용한다. 결과아이콘(390)은 사용자에 의해 또는 자동적으로 보조장치(12)를 통해 수행되는 작업을 표시할 수 있다. 또한 특정조건 및 결과들, 예로써 메뉴 아이콘, 화일 아이콘, 시계 아이콘 등을 나타내는 다수의 달리 예정된 아이콘들이 존재한다. 예정된 실행코드, 문서등은 이러한 아이콘들에 첨가되며, 매개 변수들이 이 아이콘 들에 주어질 수 있다. 한 액티비티에 도입되는 모든 변수들은 그 액티비티에 국한된다는 것이 주목되어야 한다.

위에서 언급된 바와 같이 보조장치에 내재하고 있는 그림자객체들(shadow objects)은 상태 정보의 홀더(holder)들이다. 문서, 프로그램, 하위 프로그램 등의 추적을 지속하기 위해서 이들은 보조장치에서 그림자 객체들로써 표현된다. 이 그림자객체들은 대응하는 실 객체들이 생성될 때 생성된다. PDL에서는 특수 사이클, 즉 그림자 객체의 생성을 나타내는 예증 아이콘(일반적으로 예증이란 템플릿(template)으로부터 그림자 객체의 명세서와 같은 특수예를 생성하는 것을 의미한다)이 존재한다. 제 9 도에서 예증심볼(102)의 경우에 비서업무가 예증된다. 비서업무의 선도(diagram)는 일반적으로 다수의 가능한 업무들을 기술하고 있으며, 많은 다른 회의들이 이 명세서를 사용하여 준비될 수 있다. 사용자가 특별한 회의를 준비하는 것을 돕기 위하여 명세서를 실행할 때, 이 특별회의 준비업무는 하나의 표현, 즉 그림자 객체를 가지고 있어야 한다. 예증 심볼(102)는 그러한 실례의 생성을 나타내며, 이 실례는 특정 회의 준비업무에 대한 상태 정보를 가질 수 있고 선도의 다른 부분들로부터 참조될 수 있다.

제 9a-9c 도의 흐름선도에서 기술된 프로세스는 사업회의 등을 준비하기 위해 비서에게 요구되는 업무와 관련이 있다. 이 선도는 프로세스의 여러측면을 보여주고 있다. 최사우 제 9a 도는 프로세스의 시작조건의 도형 설명인 반면, 중간부 제 9b 도는 프로세스가 하위 프로세스들로 나누어지는 것을 나타내고 있다. 지원시스템(8)에 의해 처리되는 다른 모든 프로세스에 대해 가능한 것처럼 비서 프로세스도 몇개의 하위 프로세스를 포함할 수 있다. 제 9b 도에서 도시된 하위 프로세스들은 자료 하위 프로세스(108), 통지 하위 프로세스(116), 회의 하위 프로세스(118), 텍스트 편집하위 프로세스(119) 및 프로토콜(protocol) 처리 하위 프로세스(122)등이다. 자료 하위 프로세스(108)는 특정회의를 위해 필요한 자료들을 모으는 방법을 기술하고 있으며, 반면 통지 하위프로세스(116)은 회의 참석자들에게 정보를 보내는 방법을 기술하고 있다. 회의 하위 프로세스(118)은 회의를 수행하는 방법을 기술하며 텍스트 편집 하위 프로세스(119)는 텍스트에 들어가는 방법을 기술하고 있다. 프로토콜(통신규약) 처리 하위프로세스(122)는 프로토콜을 작성하는 하위업무를 처리하는 방법을 기술하고 있다. 하단부 제 9c 도는 프로세스의 정지 조건을 기술하고 있다. 제 9a-9c 도에서 보이지 않는 프로세스의 다른관점들(인터페이스 관점, 액티비티 관점등)이 존재한다는 것을 알아야 한다.

각 하위 프로세스들은 일단 예증의 기준이 만족되면 시작하게 되는데 이 기준은 예를 들면, 프로세스가 제공되는 서비스(몇개의 다른 서브 프로세스로부터의 텍스트 압력등)가 요구되는 것이 될 수 있다. 프로세스들 또는 하위 프로세스들의 순서가 또한 기술될 수 있으며, 이 경우에 연속적인 프로세스의 업무에 중요한 사건은 앞 프로세스에 의해 보고되는 "종료"(finished)라는 사건이다. 제 9 도안의 "편집"(edit) 화살표(112) 및 "자료종료"(materialfinished) 화살표(114)같은 화살표들에 의해 지시되는 정보의 이동은 더 나아가서 동시 업무들을 기술하는 하위 프로세스에 적절한 사건들의 교환을 설명하고 있다. 이 화살표들은 선도에서 어의상 중요성이 없으며 단지 정보흐름을 기술하는 비형식적인 방법이다. 정보의 실제 교환은 엑스퍼트 시스템의 추론 엔진에 의해 처리되며, 대응하는 하위 프로세스에서 상세하게 기술된다.

아이콘(100)은 지원시스템(8)이 프로세스를 시작하는 외부사건(예를 들면, 새로운 회의 준비업무를 생성하는 사용자에 대응하는)을 받아들이므로써 작업을 시작한다는 것을 나타내고 있다. 따라서 사건의 매개 변수는 이름("시작")과 시작 프로세스의 종류("비서")이다. 예증은 아이콘(102)에서 발생한다. 심볼(104)는 비서 프로세스와 관련된 초기값의 설정을 나타내며, 프로세스의 상태변화로서 기술된다(프로세스의 시작은 참(true)으로 설정된다). 액티비티 아이콘(101)은 위에서 기술된 바와 같이 완전한 액티비티를 나타낸다.

제 9 도에서 보여진 여러 화살표들을 참고할 때 편집화살표(112)는 또 하나의 하위 프로세스에 의해 처리되는 서비스를 참조하는 자료 하위프로세스(108)를 지시한다. 이 경우에 자료하위 프로세스(180)로부터 텍스트 편집 하위 프로세스(119)가 이용된다. 텍스트 편집 하위 프로세스(119)는 시스템에서 다른 하위 프로세스들에 의해 기술된 액티비티들과 함께 평행하게 동시에 수행될 수 있는 텍스트 편집기를 사용하는 방법을 기술하고 있다. 일단 자료 하위 프로세스(108) 및 통지 하위 프로세스(116)이 각각 그들의 업무를 완수하면 "종료"사건(114) 및 (115)가 발생한다. 회의(118)로부터의 "회의로부터의 자료" 사건(120)은 회의에서 나온 자료가 유효하다는 것을 지시한다. 회의 자료는 반드시 수행되어야 하는 회의 후의 작업을 나타내는 프로토콜 처리하위 프로세스(119)에 의해 텍스트 편집을 진행시킨다. 따라서 제 9 도는 병렬로 실행될 수 있는 업무들을 기술하는 하위 프로세스들사이의 사건 교환들을 도시하고 있다. 여를 들면 자료 하위프로세스(108) 및 통지 하위 프로세스(116)의 업무들이 그들 사이에 교환되고 있는 동시 사건들의 부족에 의해 입증된 바와 같이, 병렬로 발생할 수 있다.

아이콘(124)에서, 조건은 어느 하위 프로세스에서 "정지"단계가 "참"인 상태를 기술하고 있다. 아이콘(126)에서 조건은 그러한 프로세스가 이 액티비티를 위해 이로운 친절한 프로토콜처리임에 틀림없다는 것을 말하고 있다. 아이콘(128)에서 비서프로세스(?프로세스로 표시된)가 정지된 하위 프로세스를 갖고 있다는 것을 보이고 있다. 최종적으로 아이콘(130)에서는 비서프로세스가 정지된다.

제 10 도를 참고할 때, 본 발명에 따른 자료처리방법이 설명되어있다. 이것은 제 9 도의 통지 하위 프로세스(116)의 예증을 나타낸다. 따라서, 비서업무는 시작되며, 심볼(130) 및 (132)에 의해 표시된다(시작단계는 "참"이며 프로세스의 종류는 "비서"이다). 전제조건이 "참"일때 액티비티(135)가 시작되며, 통지하위 프로세스(116)의 예증이 심볼(136)에서 실행된다(이 보기의 참조문은 하위 프로세스이다). 그다음 심볼(138)에서 통지 하위프로세스의 초기값들이 상태 정보로써 기록된다.

제 11 도에서 본 발명에 따른 자료처리방법, 특히 편집액티비티(145)가 더욱 상세하게 설명되어 있다. 기본이 되는 엑스퍼트 시스템의 메카니즘은 액티비티의 전제조건이 언제참인가를 탐지할 것이다. 편집 액티비티(145)가 가능하기 위해서는 통지 하위 프로세스가 시작되어야 한다는 것을 심볼(140)이 지시하고 있다. 심볼(142)는 임시 화일 저장을 요구하는 자료가 현재의 액티비티를 통해 발생하며 따라서, 임시화일 명칭이 정보를 저장하기 위하여 알려져야 한다는 것을 지시하고 있다(이것이 실행되는 방법은 여기서는 나타나지 않는 심볼의 코드 단락에 기술되어 있다). 다음에 메뉴(144)는 사용자(16)와의 대화를 위한 명세서의 기능을 한다. PDL 언어에서 메뉴 심볼은 보조장치(12)가 사용자(16)와 대화하는 방법을 요약한다. 예를 들면 액티비티 리스트가 사용자(16)에서 제시된다. 먼저 심볼은 사용자(16)에게 제시되는 텍스트를 표시한다9이 경우에는 "주의사항을 적어라"). 제시된 텍스트는 사용자에 의해 수행될 수 있거나 수행되어야 하는 액티비티를 기술한다. 메뉴(144)는 또한 객체, 예로써 화일, 코드 등을 내포하고 있으며 이것들 위에서 액티비티가 수행된다(이 경우에 ?템프(temp:temporary)에 표현된 임시 화일). 더 나아가서 메뉴(144)는 조건을 표시한다. 사용자(16)가 액티비티 리스트에서 액티비티를 명백히 선택하기 전에는 이 조건은 항상 "거짓"이며, 도구기능의 실행 또는 상태 변화와 같은 결과가 실행되지 않는다. 사용자가 사용자 인터페이스에서 액티비티를 선택했을 때 조건은 참이 되며 결과들이 실행된다. 이 경우에 사용자(16)가 액티비티 리스트에서 "주의사항을 적어라" 항목을 선택할 때 "편집" 사건이 심볼(146)에서 편집 업무를 요구하는 다른 하위 프로세스로 보내진다(제 9 도에서 화살표(112)에 상응한다). 이 요구는 텍스트 편집 하위프로세스에 의해 처리되며, 여기서 편집기가 시동되어 사용자는 회의의 주의사항을 적기 위해 편집기를 사용한다.

제 12 도에서 본 발명의 자료처리방법이 더욱 상세하게 나타나있다. 통지 하위 프로세스(116)의 명세서는 회의에 참석할 사람에 관한 자료검색을 포함하고 있는 액티비티(151)과 함께 계속된다. 심볼(150)은 프로세스의 "타인들(others)" 단계의 상태가 거짓이면 정보가 검색되어야 한다는 것을 지시하고 있다. 심볼(152)는 참가가 기대되는 사람들의 등록을 요구하는 메뉴 윈도우를 표시하며, 그 다음 이 등록된 사항은 시스템에 의해 지원되는 기본윈도우 원시함수들을 사용하여 아이콘(152)의 코드 관점에서 기술될 것이다. 심볼(154)는 통지 하위 프로세스(116)의 상태를 표시하며 이름의 검색이 발생한다는 것을 나타낸다(이때 "타인들"상태는 참이다). 이러한 액티비티는 제 13 도와 관련하여 아래기술되어 있는 액티비티에 의해 시동된다.

제 13 도에서 통지 하위 프로세스가 계속 기술된다. 심볼(160)으로 시작하여, 화일이 저장되어 있는 다른 하위 프로세스에서 발생한 사건이 탐지된다. 이 정보는 텍스트 편집 하위 프로세스(119)로부터 발생한다. 심볼(162)에서, 시스템은 저장화일이 임시화일명(142)에서 참조된 것과 같은 화일인 것을 증명하기 위한 검사를 수행한다(이것은 프로세스의 상태정보의 일부이다). 또한 시스템은 다음 조건이 만족되었는가를 즉 모든 참가자들이 등록되었는가의 여부를 검사하는데, 이것은 심볼(164)에서 발생한다. 이것이 "참"이 아니면 제 12 도의 액티비티참가자들을 받기 위하여 시동된다. 여기서 엑스퍼트 시스템의 목적 실현 기능이 사용된다. 즉 조건이 충족되지 않고 그 결과가 조건을 만족시킬 수 있는 액티비티가 존재한다면 이 액티비티는 수행될 것이다. 심볼(166)에서, 시스템은 통지가 미리 참가자들에게 보내졌는지를 확인한다(이것은 ?화일 객체위에 상태정보로서 기록된다). 이것은 지원시스템(8)의 비순차적인 특성을 나타낸다. 각 프로세스 및 병렬로 동시에 작동되는 하위 프로세스들과 함께, 시스템은 작업이 반복되지 않으므로써 나쁜결과들, 즉 감소된 성능 및 시스템의 저하된 처리능력등이 발생된다. 따라서, 오직 하나의 회의 통지서만이 요구되기 때문에 심볼(166)은 검사를 수행한다. 최종조건이 만족되면 메뉴(170)은 사용자(16)에게 "통지서를 보내라"는 액티비티(171)의 선택을 위한 선택권을 제공한다. 심볼(172)에서 본 발명의 보조장치는 통지서를 보내고 그것을 프린트한다. 심볼(172)는 모든 필요한 부분에 전달될 통지서를 적재하고 전송하며 프린트하는 작업을 표시한다(이것은 아이콘의 코드 관점에서 기술되어 있는 유닉스 메일(mail)과 프린트서비스들을 사용하여 가능하게 된다). 심볼(174)는 통지서가? 화일 객체에 보내졌고 이에 따라 이 액티비티가 반복될 수 없다는 상태 정보를 기록한다.

제 14 에서 통지 하위 프로세스의 요소들이 더욱 상세하게 도식적인 형태로 표시되어 있다. 심볼(180)은 통지서의 "하드카피(hard copy)"가 이미 생성되었다는 조건, 다시말해서 통지서가 프린트되었다는 조건을 지시한다(이것은 위의 액티비티(171)에서 발생한다). 메뉴(182)는 통지서가 원하는 위치에 통지서 판위에 놓여져야 한다는 것을 사용자에게 말하고 있다. 이 경우 액티비티(184)는 지원시스템(8)이 도구들을 제공하여 지원할 수 없는 액티비티를 나타낸다. 차라리 사용자는 스스로 통지서를 놓아야 한다. 따라서 아이콘(186)은 이 액티비티에서 오직 내부상태변화만이 발생하여 외부의 어떤 도구도 포함되지 않는다는 것을 지시한다. 최종적으로 제 15 도에서 통지 하위 프로세스의 완성을 포함하는 액티비티(194)가 설명되어 있다. 조건(190) 및 (192)는 통지서가 보내지고 게시되었을 때 참값을 나타낸다. 심볼(196)은 프로세스를 멈추고, 심볼(198)은 이 상태변화를 기록한다. 이것은 또한 엑스퍼트 시스템의 트리거링(triggering) 메카니즘에 기인한이 사실에 관계있는 프로세스들을 위한 사건을 작동시킨다. 제 9 도에서 "종료" 화살표(114)가 따라질 때 통지 하위 프로세스(116)가 회의(118)이 예증되며, 회의를 완성하기 위해 필요한 단계와 업무들이 발생한다.

심볼 식별자 명세서가 부록 A 에 추가되어 있다. 이 명세서는 제 8-15 도에서 도시된 바와 같이 지원시스템(8)에 의해 사용되는 그래픽 심볼들을 정의하고 있다. 또한 본 발명에 따라 설계된 여러가지 표준을 위한 자료처리단계들을 수행하는 프로그램 목록이부록 B, C 에 상세히 나와 있다. 특히, 부록 B, C 는 본 발명에서 사용되는 종류의 엑스퍼트 시스템(20)에서의 실행을 위해 PDL그래픽 언어에 의해 프로카파(ProKappa) 언어에서 코드가 생성되는 방법을 설명하는 프로그램 목록이다. 부록 B, C 의 프로그램목록에 의해 정의되어 있는 전형적인 프로세스들이 제 8-15 도에서 보여진 "비서" 프로세스의 예와 완전히 다른 반면에, 이 목록들은 프로세스의 PDL 명세서가 실행코드로 번역되는 방법을 설명하는데 도움이 된다.

제 8-15 도에서 다수의 다른 액티비티들이 보여지고 있다. 이것들은 각각의 조건들이 다른 액티비티가 수행되는 것과 관계없이 유효성을 위해 검사되기 때문에 내부적으로 비순차적이다. 이러한 방법에 의해 최종 사용자를 위한 최대한의 유연성이 달성된다. 사용되고 있는 여러가지 도구들을 바꾸지 안고도 여러가지 업무들을 위해 지원이 위에 기술된 메카니즘을 통해 생성되고 수정될 수 있다. 형식화된 명세서는 다수의 성분들의 정상에서 제어 프로그램으로써 작용하며, 단독 도구들을 통합적인 방법에서 활성화하기 위해 필요한 논리를 기술하고 있다. 따라서 여기에는 시스템 개발지원을 위한 방법 및 장치가 기술되고 도시되어 있다. 그러나 이 방면에 기수를 가진 사람들은 본 발명의 개념으로부터 실질적으로 이탈하지 않고 여기에서 설명되어있는 기술에서 특별히 언급된 것들외에 많은 수정과 변환이 만들어질 수 있다는 것을 인식할 것이다. 따라서, 여기에서 기술된 바와 같은 본 발명의 형태가 오직 예시적인 것이며, 발명의 영역을 제한하는 것이 아님을 강조한다.

[부록 A]

1. 심볼 식별자 명세서

1.1 액티비티(활동, activities)

PDL 의 주요개념은 액티비티이다. 액티비티는 정육면체로 표시된다.

조건들은 액티비티가 언제 수행될 것인가를 결정하기 위해 액티비티에 연결된다. 결과들은 무엇이 이루어지는가를 결정하기 위하여 액티비티에 연결된다.

1.2 조건(conditions)

일반적인 조건은 역삼각형으로 표시된다. 조건은 흐름 화살표에 의해 액티비티에 연결된다.

한 조건 이상이 액티비티에 연결될 수 있다. 한 조건이 시험되기 전에 선행조건이 유효해야 할 때, 이것은 다음과 같이 표시된다.

액티비티에서 가장 멀리 떨어진 조건이 첫번째로 시험된다. 일반적인 조건보다 더욱 특별한 것을 표현하기 위해 다수의 특수조건 아이콘들이 존재한다. 즉,

입력(일반적인 객체)이 있어야 한다.

입력(문서 또는 화일)이 일정한 상태(매개변수들로 기술된)에서 존재해야 한다. 예를 들면 일정한 개정, 이것은 앞 심볼의 특수화된 형태이다.

상태를 표시한다. 예를들면 객체의 속성은 일정한 값을 가져야 한다(proc.state===validation 또는 obj.al>obj. a2)

시간 식(time expression)을 표시한다. 예를 들면 특정시간에 일어나야 할 일을 나타낸다.

(now.date>=1991-10-15)

사용자 인터페이스에서 사용자에게 제시되어야 하는 액티비티를 표시한다. 대응하는 액티비티는 사용자가 사용자 인터페이스에서 그 액티비티를 선택했을 때 실행된다. 이 조건은 연쇄 조건들의 마지막에 위치하여 나머지 조건들이 액티비티가 수행될 때 확실하게 유효하도록 한다.

들어오는 신호에 관한 조건을 표시한다(매개 변수들이 부가될 수 있다).

1.3 결과(effects)

일반적인 결과는 똑바로 선 삼각형으로 표시된다.

액티비티는 흐름 화살표에 의해 결과에 연결된다.

액티비티는 다수의 결과에 연결될 수 있다. 하나의 결과가 다른 결과의 전에 수행되어야 한다면, 그것은 다음과 같이 표시된다.

액티비티에 가장 가까운 결과들이 먼저 수행된다. 또한 더욱 복잡한 결과들이 표시될 수 있다.

위의 그림은 다음의 결과들을 의미한다.

(a or (b and (d and e))) and c

PDL은 프롤로그(Prolog)를 생각하게 하는 문장형태 및 어의론을 가지고 있는데, 이것은 각 문장(결과)이 성공하거나 실패한다는 것을 의미한다. 이것은 결과들의 흐름관계로 배열돌 수 있다. 이경우 "or"는 하나가 성공될 때까지 모든 분기들이 검사되는 것으로 해석된다.

일반적인 결과보다 더욱 특수한 것을 표현하기 위해 다수의 특수 결과 심볼들이 존재한다.

일반적인 객체가 출력으로써 생성된다.

문서 또는 화일이 출력하므로써 생성되거나 혹은 새로운 상태를 받아들인다(예를 들면, 새로운 개정). 이것은 앞 심볼의 특수화된 형태이다.

상태 변화를 표시한다(예를 들면, proc.state=validation).

시간 식을 표시한다(예를 들면, 특정시간 또는 비동기 신호 전달상의 정지시간을 기다린다).

외부로 나가는 신호를 표시한다. 이 신호는 널리 전파되거나 특정 리시버에 송신될 수 있다.

그림자 객체의 생성을 표시한다(프로세스 또는 화일과 같은 실 객체를 기술하는 객체를 표시할 수 있다).

객체의 제거를 표시한다(프로세스가 종료되었을 때 사용될 수 있다).

2. 구문론

2.1 프로세스 선도

[프로세스 영역]

2.2 일반적인 조건 심볼

2.3 특수한 조건 심볼

2.4 일반적인 결과 심볼

2.5 특수한 결과 심볼

2.6 and 관계 심볼

2.7 or 관계 심볼

2.8 not 관계 심볼

2.9 제어 관계 심볼

2.10 상속 관계 심볼

[부록 B]

[부록 C]

Claims (12)

1. 대화식 시스템에서 컴퓨터 프로그램을 개발하는데 수행되어야 할 필요가 있는 다수의 단계들을 포함하는 프로그램 개발 프로세스(350)에 대한 디스크립션(기술)을 제공함을 포함하며,

   상기 프로그램 개발 프로세스가 다수의 단계들을 갖는데, 각각의 단계에서 상기 디스크립션이 상기 컴퓨터 프로그램의 개발을 진행시키며 각 단계의 출현에 응답해서 취해질 수 있는 각각의 동작을 명시하고,

   상기 프로그램 개발 프로세스 디스크립션을 실행시킴(44)과, 컴퓨터 프로그램을 개발시키는 동작을 취하였음을 나타내는 이벤트(events)를 발생시킴(65), 그리고 상기 발생된 이벤트를 설명하기 위해 상기 발생된 이벤트를 설명하기 위해 상기 프로그램 개발 프로세서를 상기 갱신된 단계로 갱신하도록 함(67)을 포함하는 컴퓨터 프로그램 개발 방법에 있어서,

   상기 제공 단계가 프로그램 개발 프로세스를 그래픽 언어로 기술하여 상기 디스크립션이 그래픽형태로 확인될 수 있도록 하며, 그리고

   상기 실행 단계가 컴퓨터 프로그램을 개발함에 있어서, 상기 디스크립션에 의해 갱신된 상태에 대하여 명시된 동작이 취해져야함을 제안하고(76), 그러는 동안에도 대화식 시스템의 사용자가 상기 디스크립션에 의해 갱신된 상태에 대하여 명시되지 않는 한 동작을 선택할 수 있도록 함(66)을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
2. 제 1 항에 있어서, 사용자가 상기 제안된 동작을 택함(68)을 포함함을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
3. 제 1 항에 있어서, 사용자가 상기 디스크립션에 의해 갱신된 상태에 대하여 명시되지 않은 동작을 택함(66)을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
4. 제 1 항에 있어서, 상기 프로그램 개발 프로세스의 디스크립션이 컴퓨터 프로그램의 개발을 진행시키며 상기 갱신된 상태의 출현에 응답하여 취해질 수 있는 다수의 동작을 명시함을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
5. 제 4 항에 있어서, 상기 제안 단계가 상기 디스크립션에 의한 갱신된 상태에 대하여 명시된 다수의 동작중 어느 한 동작이 택하여져야함을 제안하며, 그러는 동안에도 상기 디스크립션에 의해 갱신된 상태에 대하여 명시되었던 동작이 아닌 다른 한 동작을 선택할 수 있도록 함을 포함함을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
6. 제 1 항 내지 5 항중 어느 한 항에 있어서, 상기 한 동작이 범용 프로그램 개발 도구 기능의 호출을 포함함을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
7. 제 1 항에 있어서, 상기 프로그램 개발 프로세스의 디스크립션이 상기 갱신된 상태가 아닌 한 상태에 대하여 상기 컴퓨터 프로그램의 개발을 진행시키며 상기 한 상태의 출현에 응답하여 택하여 질 수 있는 다수의 동작을 명시함을 특징으로 하는 그래픽 언어로 기술된 프로세스내에서 다수의 도구를 사용하여 대화식으로 컴퓨터 프로그램을 개발하는 방법.
8. 보조장치(12)와 다수의 범용 프로그램 개발도구(단일기능 프로그램)(22)를 갖는 지원(대화식) 시스템(8)을 포함하며,

   상기 보조장치가 프로그램 개발 프로세스에 대한 디스크립션을 실행시키기 위한 수단(44)을 포함하고,

   상기 프로그램 개발 프로세스가 상기 컴퓨터 프로그램을 개발하기 위해 필요하며 상기 디스크립션에 의해 표현된 다수의 단계들을 포함하고,

   상기 프로그램 개발 프로세스가 또한 다수의 상태를 가지며, 이들 상태 각각에 대하여 컴퓨터 프로그램의 개발을 진행시키며 각 상태의 출현에 응답하여 택하여질 수 있는 각 동작을 상기 디스크립션이 명시하도록 하고, 상기 보조장치(12)가 상기 프로그램 개발 도구중 하나에 의해 동작을 취하였음(65)을 나타내는 이벤트를 인식하기 위한 수단, 그리고

   상기 인식된 이벤트를 설명하기 위해 상기 프로그램 개발 프로세스를 상기 갱신된 상태로 갱신시키기 위한(67) 수단을 더욱더 포함하는 컴퓨터 프로그램을 대화식을 개발하기 위한 장치에 있어서,

   상기 디스크립션이 그래픽 언어로 상기 프로그램 개발 프로세스를 표현하고, 이에 의해서 상기 디스크립션이 그래픽 예증형태로 제공되며, 그리고

   상기 보조장치(12)가 상기 갱신된 상태에 대하여 상기 디스크립션(기술)에 의해 명시된 동작이 컴퓨터 프로그램을 개발하는데 택하여져야 함(76)을 제안하며, 그러는 동안에도 사용자가 상기 디스크립션에 의해 갱신된 상태에 대하여 명시되지 않은 동작을 선택할 수 있도록(66)하기 위해 상기 갱신된 상태의 출현에 응답하는 수단을 포함함을 특징으로 하는 대화식 컴퓨터 프로그램을 개발하기 위한 장치.
9. 제 8 항에 있어서, 상기 프로그램 개발 프로세스의 디스크립션이 상기 갱신된 상태에 대하여 컴퓨터 프로그램의 개발을 진행시키고 상기 갱신된 상태의 출현에 응답하여 취해질 수 있는 다수의 동작을 명시하며, 그리고

   상기 제안 수단이 상기 디스크립션에 의해 갱신된 상태에 대하여 다수의 동작중 어느 한 동작이 취해져야함을 제안하며, 그러는 동안에도 사용자가 상기 디스크립션에 의해 상기 갱신된 상태에 대하여 명시된 동작이 아닌 한 동작을 선택(또는 취)할 수 있도록 함(66)을 특징으로 하는 대화식으로 컴퓨터 프로그램을 개발하기 위한 장치.
10. 제 8 항에 있어서, 상기 프로그램 개발 프로세스의 디스크립션이 상기 갱신된 상태가 아닌 한 상태에 대하여 컴퓨터 프로그램의 개발을 진행시키고 상기 한 상태의 출현에 응답하여 취해질 수 있는 다수의 동작을 명시함을 특징으로 하는 대화식으로 컴퓨터 프로그램을 개발하기 위한 장치.
11. 제 8 항에 있어서, 상기 보조장치가 프로그램 개발 프로세스의 디스크립션을 저장하였던 모듈(42)을 포함하며,

    상기 모듈이 실행을 위한 상기 수단에 결합됨을 특징으로 하는 대화식으로 컴퓨터 프로그램을 개발하기 위한 장치.
12. 제 8 항에 있어서, 상기 대화식 시스템이 다수의 도구를 상기 보조장치(12)에 연결시키는 메시지 핸들러(46)를 포함하며,

    상기 메시지 핸들러가 상기 보조장치(12)로부터 다수의 도구(22)로 필요한 동작을 통신시키며, 상기 도구내에서 발생된 이벤트(events)를 인식을 위해 상기 수단으로 통하게함을 특징으로 하는 대화식으로 컴퓨터 프로그램을 개발하기 위한 장치.