KR100940127B1 - 요구사항 모델에서 자연어로의 번역방법 - Google Patents

Abstract

본 발명은 시스템 분석에서 그래픽적으로 표현된 요구사항 모델을 자연어로 번역하는 방법에 관한 것으로, 본 발명의 방법은 소프트웨어 개발과정에서 그래픽적인 모델링 언어로 작성된 요구사항을 자연어로 번역하는 요구사항 모델에서 자연어로의 번역방법에 있어서, 요구사항에서 사용된 각 최종 출력들을 위한 입출력관계트리(IORT)를 생성하는 제 1 단계; 상기 제 1 단계에서 생성된 입출력관계트리(IORT)를 요구사항 번역트리(RTT)로 변환하는 제 2 단계; 및 상기 제 2 단계에서 구해진 요구사항 번역트리(RTT)의 루트노드로부터 각 노드들을 차례로 전위순회로 방문하면서 해당 요구사항 번역트리(RTT)를 자연어로 변환하는 제 3 단계로 구성된다. 본 발명의 방법은 그래픽적인 표기법으로 표현된 요구사항을 자연어로 번역하여 개발과정에 참여하는 계층들간의 격차를 없애주는 역할을 할 뿐만이 아니라 요구사항을 명확화하고 보다 단순하게 하는데 도움을 준다. 또한 표기법에 익숙지 않은 사람들도 무슨 의미로 작성한 요구사항인지를 이해하는데 큰 도움이 된다.

소프트웨어 개발, 요구사항, 시스템 분석, REED, 입출력관계 트리

Description

요구사항 모델에서 자연어로의 번역방법{METHOD OF TRANSLATING REQUIREMENT MODEL TO NATURAL LANGUAGE}

본 발명은 소프트웨어 개발과정에서 시스템 분석에 사용되는 언어 기술에 관한 것으로, 더욱 상세하게는 시스템 분석에서 그래픽적으로 표현된 요구사항 모델을 자연어로 번역하는 방법에 관한 것이다.

일반적으로, 소프트웨어 개발과정은 도 1에 도시된 바와 같이 계층적인 단계들로 이루어지는데, 어느 한 단계에서 작성된 문서는 다른 단계에서 직접적 혹은 간접적으로 다양한 형태로 번역된다. 예를 들면, 시스템 분석가가 영어(자연어)로 작성한 시스템 요구사항(L1)은 소프트웨어 설계자에 의하여 상태 다이어그램 등으로 표현된 소프트웨어 모델(L2)로 번역된다. 역으로, 시스템 분석가는 소프트웨어 모델(L2)이 원하는 기능을 수행하는 지를 검사하기 위하여 자신이 이해하는 언어로 번역한다. 이외에도, 소프트웨어 모델(L2)은 프로그래머에 의하여 혹은 자동 코드 생성기에 의하여 프로그램 코드(L3)로 번역된다.

이러한 번역 과정에서 오류가 발생할 수 있는데, 특히 정확한 표현이 어려운 자연어로 기술된 요구사항 경우, 번역하면서 많은 오류가 발생한다. 다른 사람이 작성한 요구사항을 정확하게 이해하기 어렵게 만들기도 하고, 틀린 점을 발견하기 어렵게 만들기도 한다. 정확한 번역이 어렵다는 점은 요구사항의 검증을 어렵게 만들고, 부정확한 요구사항은 프로젝트 일정이나 소프트웨어 품질에 매우 큰 부정적 영향을 준다. 제임스 마틴(James Martin)은 소프트웨어 프로젝트에서 발생하는 결함들 중에서 56%는 요구사항 결함이며, 이 결함들 중 약 50%가 엉망으로 쓰여졌거나 모호하거나 명료하지 않거나 부정확한 요구사항 때문이라고 보고하고 있다. 요구사항 결함은 재작업을 발생시키는데, 프로젝트 개발비의 약 30~50%가 재작업 비용이며, 이 재작업 비용 중 70~85%가 요구사항의 오류에서 기인한 것으로 알려져 있다.

따라서 요구사항 번역 오류를 줄이기 위하여 요구사항 모델링/기술 언어들(UML, Simulink, SDL)로 요구사항을 기술하려는 노력이 시도되고 있다. 이들 요구사항 모델링/기술 언어들은 모두 공통적인 특징이 있는데, 가장 주목되는 특징은 이해하기 쉬운 그래픽적인 표기법을 사용한다는 점과 사용된 그래픽적인 구성요소들의 의미가 분명하다는 점이다. 특히, 이들 방법을 사용하여 요구사항을 작성하면, 자동 코드 생성기 등 번역의 자동화가 가능해져 번역 과정에서 발생하는 오류를 줄일 수 있다.

그러나 자연어를 사용하는 시스템 분석가가 스테이트차트(Statechart)나 스테이트플로우(Stateflow)로 기술된 요구사항을 자연어로 정확하게 번역하는 데 많 은 어려움이 예상된다. 이는 스테이트차트(Statechart)에 관한 지식을 가지고 있을 때에야 비로소 스테이트차트(Statechart)로 기술된 요구사항을 정확하게 이해할 수 있으며, 스테이트플로우(Stateflow) 실행에 대한 의미를 정확하게 이해하고 있을 때, 스테이트플로우(Stateflow)로 작성된 요구사항을 정확하게 분석할 수 있기 때문이다. 즉, 요구사항 작성 및 분석에 관련된 모든 사람이 동일한 언어를 사용할 수는 없다. 따라서 시스템 분석가는 그들의 언어인 자연어를 사용하기 원하며 소프트웨어 설계자에게는 그들의 역할에 적합한 모델링 언어가 필요하다. 프로그래머는 코드를 기술하기 위한 자신들의 언어인 프로그래밍 언어가 필요하다.

이와 같이, 시스템 분석가와 소프트웨어 설계자 등 소프트웨어 개발과정에 참여하는 다양한 계층의 사람들에게 동일한 언어의 사용을 강제하는 것보다는 사람들 사이의 간격을 메워주는 번역 기법이나 도구를 제공하는 것이 효과적이다. 예를 들면, 자연어로 기술된 요구사항으로부터 핵심적인 요구사항을 추출하는 기법이나, 자연어로 기술된 것으로부터 요구사항을 추출하는 기법 등은 정확한 요구사항 작성에 많은 도움을 준다. 또한 자동 코드 생성기는 모델을 C/C++ 코드로 번역하여 줌으로써 소프트웨어 설계자와 프로그래머 사이의 간격을 메워 준다. 이처럼 하위 방향으로의 번역뿐 아니라 상위 방향으로의 번역을 위한 도구도 많이 발명되고 있다. 예를 들면, C/C++ 코드로부터 UML 다이어그램들을 생성하기도 하고, 프로그램 코드로부터 UML 객체 다이어그램 등을 자동으로 생성해 주는 기능 등은 이미 비주얼 스튜디오(MS visual studio)를 비롯한 많은 도구에 적용되었다. 그러나 아직 모델링 언어로 기술된 요구사항을 자연어로 번역하는 상위(upward) 방향으로의 번역에 대 한 발명은 아직 이루어지지 않고 있다.

시스템 분석가 혹은 소프트웨어 설계자는 REED를 사용하여 모호하지 않고 분명하며, 유일한 의미를 가진 그래픽적인 객체의 연결구조로 요구사항을 기술할 수 있다. 하나의 요구사항은 그래픽적인 객체들의 관계를 나타내는 그래프로 표현될 수 있고, 유일한 의미로 인하여 요구사항의 정확성이나 행위를 분석하는 것이 가능해진다.

그런데 REED가 형상화한 언어로 요구사항을 기술하도록 지원한다고 하더라도, REED의 객체들의 의미나 이들의 관계에 대한 정확한 의미를 모르는 시스템 분석가는 요구사항을 번역하여 정확히 이해하는 데 어려움을 겪게 된다. 그리고 이는 결국, 모델링된 요구사항이 시스템 분석가의 의도를 정확하게 표현하였는지를 이해하는 데 장애를 준다.

따라서 소프트웨어 설계자와 시스템 분석가 사이의 간격을 제거하기 위해서는 그래픽적인 요구사항을 자연어로 된 요구사항으로 번역하는 것이 필요하다.

본 발명은 상기와 같은 필요성을 충족시키기 위해 제안된 것으로, 본 발명의 목적은 그래픽적인 표기법으로 표현(즉, 모델링)된 요구사항을 자연어 요구사항으로 번역하는 요구사항 모델에서 자연어로의 번역방법을 제공하는 것이다.

상기와 같은 목적을 달성하기 위하여 본 발명의 방법은 소프트웨어 개발과정에서 그래픽적인 모델링 언어로 작성된 요구사항을 자연어로 번역하는 요구사항 모델에서 자연어로의 번역방법에 있어서,

요구사항에서 사용된 각 최종 출력들을 위한 입출력관계 트리(IORT)를 생성하는 제 1 단계; 상기 제 1 단계에서 생성된 입출력관계 트리(IORT)를 요구사항 번역트리(RTT)로 변환하는 제 2 단계; 및 상기 제 2 단계에서 구해진 요구사항 번역트리(RTT)의 루트노드로부터 각 노드들을 차례로 전위순회로 방문하면서 해당 요구사항 번역트리(RTT)를 자연어로 변환하는 제 3단계를 포함하는 것을 특징으로 한다.

상기 제 1단계는 여러 개의 엔티티 객체와 연산 객체가 서로 연결된 다이어그램 모양의 요구사항에서, 각 출력 엔티티 객체로부터 거꾸로 다이어그램을 탐색하여 상기 입출력관계 트리를 생성하고, 상기 요구사항의 다이어그램이 루프나 시퀀셜과 같은 흐름제어 객체를 포함하는 경우, 생성된 입출력관계 트리를 관련이 있는 것과 병합하는 것이다.

상기 제 2단계는 상기 제 1 단계에서 생성된 입출력관계 트리에서 흐름제어 객체를 중심으로 바라본 중간트리로 변환하는 2-1단계와, 상기 중간트리의 각 서브그래프를 출력에서 입력으로 거꾸로 탐색하여 연산객체를 중심으로 요구사항 번역 트리를 구성하는 2-2단계로 구성되고, 상기 2-1단계는 입출력관계 트리에서 사용된 하나의 흐름제어 객체를 찾은 후 이들 객체의 링크를 따라 탐색하면서 찾은 객체를 그룹으로 묶어 흐름제어 객체의 자식으로 만드는 단계와, 흐름제어 객체를 가리키는 노드와, 흐름제어 객체가 포함되지 않은 서브그래프를 가리키는 노드들로 이루어진 그래프를 만드는 단계로 이루어진다. 상기 2-2단계는 중간트리의 노드를 흐름제어 객체인 경우와 서브그래프로 구분하여 노드가 서브그래프이면 서브그래프를 트리구조로 변형하고, 흐름제어 객체인 경우 자식들을 대상으로 서브그래프를 트리구조로 변형하는 것이다.

상기 제 3단계는 상기 요구사항 번역 트리를 전위순회로 탐색하면서 상기 요구사항 번역 트리의 루트 노드를 번역한 후 루트의 각 서브 트리를 차례대로 번역하고, 객체별로 사용패턴을 분류하고, 각 사용패턴에 대한 자연어 템플릿을 작성하여 데이터베이스화한 것이다.

상기 제 3단계는 상기 요구사항 번역 트리(RTT)가 많은 자식들을 포함하고 있을 경우, 하나의 노드를 하나의 문장으로 번역하고, 각각의 문장에 문장 번호를 부여한 것이고, 하나의 요구사항 안에 여러 개의 다이어그램이 존재하는 경우, 다이어그램의 화면상의 위치와 번역된 문장의 순서를 일치시키기 위해서 다이어그램의 화면 위치를 이용하여 요구사항 번역트리(RTT) 자체를 정렬하고, 제일 위에 위치한 다이어그램의 요구사항 번역트리(RTT)부터 순차적으로 해석하는 것이다.

본 발명의 방법은 그래픽적인 표기법으로 표현된 요구사항을 자연어로 번역하여 개발과정에 참여하는 계층들간의 격차를 없애주는 역할을 할 뿐만이 아니라 요구사항을 명확화하고 보다 단순하게 만드는 효과가 있다. 또한 표기법에 익숙지 않은 사람들도 무슨 의미로 작성한 요구사항인지를 이해하는데 큰 도움이 된다.

본 발명과 본 발명의 실시에 의해 달성되는 기술적 과제는 다음에서 설명하는 본 발명의 바람직한 실시예들에 의하여 더욱 명확해질 것이다. 다음의 실시예들은 단지 본 발명을 설명하기 위하여 예시된 것에 불과하며, 본 발명의 범위를 제한하기 위한 것은 아니다.

본 발명의 실시예에서는 본 발명자가 개발한 요구사항 관리 시스템인 REED에 적용되는 예를 보여준다. 그리고 이해의 편의를 위해 REED의 기능 및 요구사항을 그래픽으로 표현하는 것에 대하여 먼저 간략히 소개한 후 본 발명에 따라 그래픽적인 표기법으로 기술된 요구사항을 자연어로 번역하는 알고리즘을 설명하고, 본 발명을 자동차 내부 온도 자동조절장치(TC), 버스 요금 계산기(BusCard), 굴삭기 제어기 등 3 개의 시스템의 요구사항에 적용한 실험예를 들어 평가해본다.

1. 요구사항을 그래픽적으로 표현하는 방법

요구사항을 자연어로 표현할 때 발생하는 문제점을 해결하기 위하여 다양한 방법이 제시되고 있다. 특히 그래픽적인 표현은 기술하기 쉽다는 점과 요구사항 모델의 의미가 분명하다는 장점 때문에 널리 사용되고 있다. 또한, 시뮬레이션 등의 방법을 통하여 요구사항 모델로부터 시스템의 행위를 예측할 수 있다는 장점 때문에 널리 사용되고 있다.

요구사항을 그래픽적인 표기법으로 표기하기 위하여 가장 널리 사용되는 방법으로 UML(Unified Modeling Language)이 있다. UML 2.0은 클래스(class) 다이어그램이나 스테이트머신(statemachine) 다이어그램 등 13가지 다이어그램을 통해서 시스템을 모델링하는 언어이다. 클래스(Class) 다이어그램 등을 통해서 시스템을 정적인 관점에서 모델링할 수 있고, 스테이트머신(statemachine) 다이어그램 등을 통해서 시스템을 행위적인 관점에서 모델링할 수 있다. 정적인 관점과 행위적인 관점에서 모델링할 경우, 시스템의 구조뿐 아니라 시스템의 동작에 대한 명확한 모델링이 가능해 진다. 또한 UML은 많은 사용자층을 확보하고 있고, IBM의 Rational Rose, RequisitePro, Borland의 Together, Telelogic의 Rhapsody 등 많은 도구에서 지원된다. 이 도구들 중의 일부는 UML로부터 프로그래머가 작성해야 할 코드를 자동으로 생성하는 하위방향으로의 번역 기능까지도 제공한다.

매스웍스(Mathworks)의 시뮬링크(Simulink)는 동적인 시스템을 모델링, 시뮬레이션, 분석하기 위한 소프트웨어이다. 시뮬링크(Simulink)는 시스템을 설계하는데 필요한 여러 가지 컴포넌트를 제공한다. 예를 들면, AND/OR 게이트에서부터 신호 생성기, 수학 연산자에 이르기까지 다양한 컴포넌트를 제공한다. 이들 컴포넌트를 이용하여 시스템을 쉽게 모델링할 수 있다. 시뮬레이션을 수행하여 시스템의 동작을 미리 예측해 볼 수도 있고, 설계된 시스템의 오류를 미리 찾아낼 수도 있다. 또한 다양한 부가 기능을 통하여 요구사항 관리기능, 검증 및 확인 기능도 가능하 다.

SDL(Specification and Description Language)은 이벤트 기반 시스템, 특히 원격통신 시스템의 명세서를 기술하기 위한 언어이다. SDL은 복잡하지 않으며 상대적으로 적은 하위 시스템을 가지고 있는 행위 모델링에 적합하다. 타임 시퀀스(Time sequence) 다이어그램은 시스템의 행위를 사용자의 관점에서 명세서로 표현하는데 특별히 적합하다. SDL은 실시간 시스템의 행위를 모델링하기에 편리한 "SDL machine"이라로 불리는 동적인 의미를 지원한다.

본 발명이 적용되는 REED(REquirement EDitor)는 앞에서 설명한 도구들처럼 그래픽적인 표현을 사용하여 요구사항을 기술하도록 지원하는 도구이다. UML 등에서 사용되는 스테이트차트(Statechart)는 시스템의 행위를 표현하기 위해서 시스템의 상태에 기반을 둔 스테이트머신(statemachine) 다이어그램을 사용하지만, REED는 시스템의 행위를 표현하기 위해서 입/출력에 관심을 가지고 요구사항을 기술하도록 지원한다. 즉, 임베디드 시스템은 사용자의 입력에 시스템이 반응하여 원하는 출력을 생산한다는 점에 기반을 두고 있기 때문에 요구사항을 입/출력에 관심을 가지고 작성할 수 있도록 지원하는 것이다.

시뮬링크(Simulink)가 시스템에 대한 상세한 정보를 바탕으로 이루어지는 시스템 모델링 단계에서 사용할 수 있는 도구라면, REED는 사용자가 기술하려는 자연어를 그래픽적인 표기법을 사용하여 표현하는 그림 문장(picture sentence)으로써, 요구사항기술 및 검증을 하기 위한 목적으로 개발되었다. 그림 문자(Picture word)가 문자를 그림으로 표현하는 것처럼, REED에서 작성된 요구사항 다이어그램은 시 스템 분석가가 표현하려는 문장(Sentence)을 그림(Picture)으로 표현한 것에 해당한다.

도 2는 전자레인지의 요구사항 중 하나를 REED로 작성하는 화면의 모습이다. 화면 위의 'Requirement Name'에 기술된 'Pressing 10Min Button'은 이 요구사항의 이름이다. '10Min 버튼을 누르면, 전자레인지는 조리시간(Cooking Time)에 10분을 더해야 한다.'는 자연어로 표현된 요구사항이다. 도 2의 화면 아래에 보이는 다이어그램은 요구사항을 REED의 객체를 이용하여 표현한 요구사항이다. 이러한 다이어그램을 요구사항 다이어그램이라 부른다.

REED는 요구사항의 작성을 용이하게 하기 위하여 다양한 객체를 정의하고 있다. 도 2의 요구사항 다이어그램에 사용된 객체들의 의미는 다음 표 1과 같다.

기호	이름	의미
<이름>	입력장치	시스템의 입력을 표현한다. 예를 들면, 버튼, 센서 값 등이 이에 속한다. 입력장치의 이름은 <이름>이다.
<이름>	메모리	요구사항의 기술을 용이하게 하기 위해서 사용되는 변 수이다. 변수의 이름은 <이름>이다.
	Assignment	EN 포트로 어떤 값이 입력될 때, 입력 포트 X1~X 4으로 입력된 값을 사용하여 함수를 실행한 후, 그 값을 출력 포트로 출력한다.

상기 표 1은 REED의 그래픽적인 객체의 예이다. REED에서 객체는 엔티티 객체와 연산 객체로 구별된다. 입력장치, 출력장치, 메모리 등의 객체를 엔티티 객체로 분류하고, Assignment와 같이 어떠한 기능을 수행하는 객체는 연산 객체로 분류한다. 각 객체는 서로의 연결을 위하여 포트를 가지고 있다. 엔티티 객체와 연산 객체는 연산 객체의 포트를 통하여 연결된다. 연산 객체의 출력은 다른 연산 객체의 입력 포트와 연결이 가능하다. 그림 문장(Picture sentence)에 해당하는 요구사항 다이어그램에서 연산 객체들은 엔티티 객체로부터 입력을 받아 다른 엔티티 객체 혹은 연산 객체로 값을 출력하는 그래프의 형태를 가진다. 도 2에서 보는 바와 같이, 요구사항 다이어그램은 자연어로 기술된 요구사항이 쉽게 연상될 정도로 매우 직관적으로 표현되었다. 뿐만 아니라 요구사항 다이어그램은 다양한 분석을 가능케 한다.

2. 본 발명에 따른 요구사항 번역 알고리즘

2.1 번역 알고리즘 개요

다이어그램이 요구사항의 의미를 직관적으로 표현하고 있더라도 그 의미를 정확하게 이해하기 위하여는 객체의 의미들을 이해하여야 한다. 따라서 자연어로 번역된 요구사항은 다이어그램에서 사용하는 객체의 의미가 익숙하지 않은 시스템 분석가로 하여금 요구사항 다이어그램을 이해하는 데 많은 기여를 하게 된다.

본 발명에 따르면 다이어그램은 다음 표2에서와 같이 3 단계를 거쳐서 자연어로 번역되는데, 다음 표2는 번역 알고리즘을 C# 형태의 가상코드로 표현한 것이다.

// 번역 알고리즘 Let ReqDiag be the requirement diagram to be translated GS = GenIORT ( ReqDiag); // 1 단계 foreach (IORT in GS) { RTT = Transform_IORT_in_ReqTransTree( 입출력관계트리(IORT) ); // 2 단계 Translate_Into_NaturalLanguage(RTT, Description); // 3 단계 }

상기 표2의 1단계에서는 요구사 항에서 사용된 최종 출력들, 각각의 출력을 위한 입출력관계트리(IORT:Input-Output-Relation-Tree)로 분리한다.

도 2에서 보는 바와 같이, 요구사항 다이어그램은 왼쪽에 입력들이 위치하고, 오른쪽에 출력이 위치한 수평적으로 표현된다. 각 입출력관계트리(IORT)의 형태는 요구사항의 최종 출력 별로 요구사항 다이어그램을 시계 반대 방향으로 90도 회전시킨 트리와 매우 유사하다. 트리의 모습을 가진 입출력관계트리(IORT)의 각 노드들은 자식 노드들이 입력되었을 때의 출력에 해당된다. 즉, 입출력관계트리(IORT)에서 자식 노드들과 부모 노드는 입력-출력 관계가 성립한다. 여러 개의 출력을 생산하는 다이어그램은 각 출력을 루트로 갖는 여러 개의 입출력관계트리(IORT)로 분할된다. 입출력관계트리(IORT)로 분할하는 알고리즘은 다음에 보다 자세히 기술한다.

2 단계에서는 입출력관계트리(IORT)를 자연어로 번역하기에 적합한 트리로 변환된다. 2단계에서 생성되는 트리를 요구사항번역트리(RTT:Requirement Translation Tree)라 부른다. 입출력관계트리(IORT)의 구조와 자연어가 가지는 언어적 특성 차이 때문에 입출력관계트리(IORT)를 바로 번역에 사용하기에는 몇 가지 어려움이 있다. 2단계에서는 입출력관계트리(IORT)를 자연어의 특성을 고려하여 번역에 적합한 요구사항번역트리(RTT)로 변환한다. 입출력관계트리(IORT)를 요구사항번역트리(RTT)로 변환하는 알고리즘은 다음에 보다 자세히 기술한다.

3단계에서는 요구사항번역 트리(RTT)의 루트 노드부터 요구사항 번역트리(RTT)의 노드들을 차례대로 전위순회로 방문하면서 자연어로 변환한다. 요구사항번역트리(RTT)를 자연어로 표현하는 알고리즘은 다음에 보다 자세히 기술한다.

2.2 입출력관계트리(IORT:Input Output Relation Tree)의 생성

하나의 요구사항은 여러 개의 엔티티 객체와 연산 객체가 서로 연결된 다이어그램의 모양을 가지고 있다. 전자레인지의 'Start Button'이 눌려 졌을 때의 요구사항을 하나의 다이어그램으로 기술한 다음의 도 3의 예로 들어 보자.

도 3의 요구사항 다이어그램은 "사용자가 'Start Button'을 눌렀을 때, 전자레인지의 'Mode'가 'AutoCook'으로 설정되어 있으면 조리 시간을 자동 조리에 적합하도록 설정하고, 'Mode'가 'idle'로 설정되어 있을 경우, 만약 설정된 'Cooking Time'이 0이라면 'Cooking Time'을 30sec로 설정한다."라는 요구사항을 기술한 것이다. 그리고 다음 표3은 도 3에 사용된 REED 객체의 의미를 정리한 것이다.

기호	이름	의미
	Bypass	EN 포트가 활성화되었을 때, 입력으로 들어온 값을 출력으로 내보낸다.
	Equal	EN 포트가 활성화되었을 때, 입력으로 들어온 2개의 값이 같으면 출력 T를 활성화하고, 입력 값이 서로 다르면 출력 F를 활성화한다.
	Internal Event	<name>이라는 이벤트를 발생시킨다.
	Constant	연결된 링크에 적힌 상수 값을 의미한다.

상기 표3에서 "Bypass"는 EN 포트가 활성화되었을 때, 입력으로 들어온 값을 출력으로 내보낸다.　"Equal"은 EN 포트가 활성화되었을 때, 입력으로 들어온 2개의 값이 같으면 출력 T를 활성화하고, 입력 값이 서로 다르면 출력 F를 활성화한다.　"Internal Event"는 <name>이라는 이벤트를 발생시키고, "Constant"는 연결된 링크에 적힌 상수 값을 의미한다.

도 3의 요구사항 다이어그램은 'AutoCookTimeSet'과 'Cooking Time' 라는 두 개의 출력을 내보내도록 하고 있다. 'AutoCookTimeSet'을 출력하기 위하여 'Cooking Time' 앞에 있는 Equal 객체는 필요가 없다. 그러나 'Bypass'라는 객체(object)는 'AutoCookTimeSet'과' CookingTime'을 출력하기 위하여 모두에게 필요하다. 이처럼 하나의 다이어그램을 출력 별로 그 출력에 영향을 미치는 객체들로만 연결된 다이어그램으로 분리할 수 있다.

도 3을 출력 별로 관계되는 객체들만을 추출하면 다음도 4와 같이 루트가 오른쪽에 위치하는 트리 모습을 가진 2개의 입출력관계트리(IORT)를 만들 수 있다.

간단한 다이어그램을 입출력관계 트리(IORT)로 변환하는 방법은 간단하다. 예를 들면, 도 3처럼 간단한 요구사항 다이어그램을 입출력관계 트리(IORT)로 분할하는 방법은 비교적 간단하다. 각 출력 엔티티 객체에서부터 거꾸로 다이어그램을 탐색하면 된다. 출력 엔티티 객체 'AutoCookTimeSet'부터 거꾸로 탐색을 시작하여 마지막 연산 객체인 Bypass 객체에서 종료하면, 도 4의 위쪽에 도시된 입출력관계트리(IORT)가 생성된다. 또한, 출력 엔티티 객체인 'Cooking Time'에서 출발하여 거꾸로 탐색하면, 도 4의 아래쪽에 도시된 입출력관계트리(IORT)가 만들어진다.

도 4의 요구사항 입출력관계 트리(IORT)는 위에서 예시된 하나의 요구사항 문장을 다음 표4와 같은 두 개의 문장으로 표현한 것으로 간주할 수도 있다.

문장 1	사용자가 'Start Button'을 눌렀을 때, 'mode'가 ' AutoCook'으로 설정되어 있으면 자동 cooking으로 작동하도록 cooking 시간을 설정한다.
문장 2	사용자가 'Start Button'을 눌렀을 때 , 'Mode'가 'idle'로 설정되어 있을 경우, 만약 설정된 'Cooking Time'이 0이라면 'Cooking Time'을 30sec로 설정한다.

요구사항을 여러 개의 요구사항으로 나누어 번역하면 더욱 명확하게 그 뜻을 파악할 수 있을 뿐 아니라, 테스트할 때에도 요구사항에서 체크할 출력값들이 중복되지 않아 오류를 명확하게 판단하는 데 기여한다.

그러나 복잡한 다이어그램의 경우, 단순히 거꾸로 탐색하는 것만으로 입출력관계트리(IORT)를 생성할 수 없으며 추가적인 처리를 하여야 한다. 본 발명에서는 위 예가 보여주듯, 출력을 기준으로 입출력관계트리(IORT)를 생성하는 방법을 제안한다. 특히, 반복 작업을 표현하기 위한 'Loop' 객체나 순차적인 작업을 표현하기 위한 'Sequential' 객체를 포함한 다이어그램에서 입출력관계트리(IORT)를 추출하는 알고리즘을 기술한다. 설명의 편의를 위하여 'Loop' 과 'Sequential' 객체를 흐름제어(FC:Flow of Control) 객체라 부른다. 다음 표 5는 이 두 객체들의 의미를 기술하고 있다.

기호	이름	의미
	Loop	'Loop'는 동일한 반복되는 작업을 표현할 때 사용하는 객 체이다. 'Start'포트로 입력되면, 엔티티에 연결된 작업을 수행한 후, Do에 연결된 작업을 'stop' 입력이 발생할 때까지 반복한다는 것을 의미한다.'Stop'에 입력이 발생하면, 'Exit'에 연결된 작업을 수행하고, 'Loo p'는 종료된다.
	Sequential	'Sequential' 은 일련의 행동을 차례대로 기술할 때 사용된다. 각 출력 포트에 연결된 작업을 번호순으로 차례대로 수행하라는 것을 가리킨다

요구사항 다이어그램이 흐름제어(FC) 객체를 사용하는 경우, 입출력관계트리(IORT)를 추출하는 작업은 도 4 을 도 3로부터 추출하는 것보다 다소 복잡하다. 예를 들면, 두 개의 출력 A와 B가 'Sequential' 객체의 출 력 포트에 연결되어 있을 경우, 출력 A를 생산하는 요구사항과 출력 B를 생산하는 요구사항을 독립적으로 번역되도록 별개의 입출력관계트리(IORT)를 만드는 것보다는 두 개의 출력 A와 B가 순차적으로 생산된다고 번역될 수 있도록 하나의 입출력관계 트리(IORT)에 속하도록 추출하는 것이 타당하다. 또한 입출력관계트리(IORT)의 수를 줄이기 위하여 하나의 연산 객체가 여러 개의 최종적인 출력을 생산하는 경우에도 독립적인 여러 개의 입출력관계트리(IORT)를 만드는 것보다는 하나의 입출력관계 트리(IORT)로 묶도록 하였다.

하나의 요구사항 다이어그램을 입출력관계 트리(IORT)들의 리스트로 만드는 알고리즘의 개략적 흐름은 다음의 표6과 같다.

// 입출력관계트리(IORT) 생성 GraphSet GenIORT ( Graph ReqDiag) { Let SetG be an empty set ListofLastOP = List of last operation objects of ReqDia g foreach (L in ListofLastOP) { 1)mark all objects ∈ ReqDiag as unvisited 2)Create an 입출력관계트리(IORT) G, and initi ally L∈ G, mark L as visited 3)while(there is an unvisited object Obj that is researchable by backward traverse from an object already visited) { (1)mark Obj as visited (2)if(Obj is 'Sequential'or 'Loop' object and Obj is already used by other 입출력관계트리(IORT) F in SetG) { Set all objects ∈ F as visited Merge F into G remove F from SetG } else { Expand G using Obj } } 4)Insert G into SetG } return SetG }

상기 표 6을 참조하면, 우선, 다이어그램의 최종 출력 리스트를 만든 후, 이 리스트내의 각각 객체 "L"에서 출발하여 거꾸로 탐색하면서 "L"을 생산하는 객체들이 사용되는 값을 출력하는 객체들을 찾는다. 거꾸로 탐색하는 도중, 'Loop' 나 'Seq' 등의 흐름제어(FC) 객체를 만나면, 이들을 사용하여 이미 어떤 입출력관계트리(IORT)가 만들어졌는지를 확인하기 위하여 "SetG"라는 입출력관계트리(IORT) 집합을 검색한다. 이미 만들어진 입출력관계트리(IORT)는 작업 중이던 입출력관계트리(IORT)에 병합시켜 하나의 입출력관계 트리(IORT)로 구축한 후, 작업을 계속한다. 이러한 작업을 다이어그램 내의 모든 객체들이 적어도 하나의 입출력관계트리(IORT)에서 사용될 때까지 계속된다.

도 5는 전자레인지의 'START' 버튼을 눌렀을 때, 1)cooking time을 설정하는 작업과, 2) "Turning Motor" 회전을 시작하고 전자파를 "emit"하는 두 개의 작업을 순차적으로 수행하여야 한다는 것을 명시한 다이어그램이다. 순차적으로 수행할 것을 명시하기 위하여 'Sequential' 객체가 사용되었다. 도 5에서 처음으로 등장한 AND와 유사하게 생긴 block은 2개의 입력에 대하여 logical AND와 유사한 기능을 담당하는 block이다. 그리고 표 6의 알고리즘에서 마지막 연산 객체인 'Equality' 연산 객체부터 출발해서 입출력관계트리(IORT)를 생성하는 경우, 도 6과 같은 입출력관계트리(IORT)가 생성되고, 생성된 입출력관계 트리(IORT)는 "SetG"에 보관된다. 또한, "Turning Motor"와 "Emitter"에게 값을 출력하는 연산 객체에서 출발하여 두 번째 입출력관계트리(IORT)를 생성하기 시작한다. 생성 도중, 'Sequential' 객체를 만나면 "SetG"에 있는 입출력관계트리(IORT), 'Equality' 연산 객체로부터 만들어진 입출력관계 트리(IORT)와 병합한다. 사용된 모든 연산 객체를 모두 처리하였으므로 알고리즘을 종료되며, 모든 객체가 하나로 묶인 원래의 도 5와 같은 하나의 입출력관계트리(IORT)가 만들어진다. REED에서 사용되는 기타 40여 개의 다양한 객체도 같은 방법으로 입출력관계트리(IORT)를 만들 수 있다.

2.3 요구사항 번역 트리의 생성

생성된 입출력관계트리(IORT)를 이용하여 번역하기 위해서는 또 하나의 과정을 거쳐야 한다. 만일 입출력관계트리(IORT)가 간단하다면 추가적인 작업이 필요없이 출력 객체부터 거꾸로 탐색하면서 직접 번역할 수도 있다. 그러나 'loop'나 'sequential' 등 흐름제어(FC) 객체를 가진 경우에는 자연어로 번역할 때, 번역 순서가 달라야 한다. 번역 측면에서 볼 때, 다른 객체보다 우선해서 번역되어야 하는 특징을 가진 흐름제어(FC) 객체가 입출력관계트리(IORT) 하위에 나타난다 하더라도 우선하여 번역되도록 트리 구조상 상위에 나타나도록 하는 것이 적합하다. 즉, 입출력관계 트리(IORT)를 직접 번역에 사용하는 것보다는 입출력관계트리(IORT)를 번역에 적합하도록 변형할 필요가 있다.

이처럼 입출력관계트리(IORT)를 번역에 편리하도록 재구성한 자료 구조를 요구사항 번역트리(RTT: Requirement Translation Tree)라 한다. 즉, 요구사항 번역트리(RTT)는 요구사항을 표현한 입출력관계트리(IORT) 객체들을 번역에 적합하도록 재배열 한 자료구조이다.

입출력관계 트리(IORT)는 두 단계를 거쳐 요구사항 번역트리(RTT)로 변환된다.

첫 단계는 입출력관계 트리(IORT)에서 사용된 흐름제어(FC) 객체를 중심으로 바라본 그래프로 변형하는 작업이다. 이 그래프를 요구사항 번역트리(RTT)를 만들기 위한 중간 그래프라는 뜻으로 중간트리(IMT:Intermedi ate Tree)라고 부른다. 중간트리(IMT)는 입출력관계 트리(IORT)에서 사용된 흐름제어(FC) 객체를 루트 노드로 이동한 자료구조이다. 그리고 흐름제어(FC) 객체 이외의 객체들은 모두 그룹화하여 서브그래프라는 노드로 표현한다.

이와 같이 중간트리(IMT)를 만드는 상세한 알고리즘은 다음 표 7과 같다.

// 입출력관계 트리(IORT)로부터 Intermediate Tree 생성 IntermediateTree Convert_IORT2IntT (IORT G) { Let IMT as a Empty Intermediate Tree FC = Find 'Loop'or 'Sequential' object in G if FC is not found { Initialize IMT with G } else { 1)Set FC as a root node of IMT 2)Make Gin, connected to each input port of F C, as a child of FC 3)Make Gout, connected to each output port of FC, as a child of FC 4)Call Convert_IORT2IntT(Gout) } return IMT }

우선 입출력관계트리(IORT) 내에서 사용된 하나의 흐름제어(FC) 객체를 찾은 후, 이들 객체의 링크를 따라가며 탐색하면서 찾은 객체 들을 그룹으로 묶은 후, 이들을 흐름제어(FC) 객체의 자식으로 만들면 된다. 만약 이렇게 생성된 자식들 중에 또 다른 'Sequential'이나 'Loop' 객체가 있다면, 동일한 방법에 의하여 그룹화를 실시한다. 이러한 작업을 통하여 흐름제어(FC) 객체를 가리키는 노드와 흐름제어(FC) 객체가 포함되지 않은 서브그래프를 가리키는 노드들로 이루어진 그래프를 만들 수 있다. 이 그래프를 중간트리(IMT)라 한다. 도 7은 도 5의 입출력 관계트리(IORT)로부터 만들어진 중간트리(IMT)의 모습이다. 세 개의 서브그래프를 자식으로 가지며 'Sequential' 객체가 root인 중간트리(IMT) 이다. 서브그래프 이외의 노드가 하나인 것은 도 5의 요구사항에서 하나의 'Sequential' 객체가 사용되었기 때문이다.

두 번째 단계에서는 중간트리(IMT)의 각 서브그래프들이 번역하기에 적합한 트리로 변형된다. 중간트리(IMT)에서 구축된 서브그래프는 관련된 객체들의 입출력관계트리(IORT)이다. 번역에 적합한 순서를 얻기 위해서는 입출력관계트리(IORT)를 연산 객체를 중심으로 출력에서 입력 방향으로 거꾸로 정렬을 해야한다. 요구사항은 출력을 중심으로 설명될 수 있기 때문에 최종적으로 출력을 내보내는 연산 객체에서부터 거꾸로 탐색하면서 출력이 발생한 이유를 설명하는 것은 요구사항에 대한 번역을 자연스럽게 만드는 좋은 방법이기 때문이다. 도 7의 각 서브그래프를 단순히 거꾸로 탐색하면서 연산 객체를 중심으로 트리를 구성하면 도 8과 같은 요구사항 번역트리(RTT)를 생성할 수 있다. 요구사항 번역트리(RTT)를 생성하는 상세한 알고리즘은 다음 표 8과 같다.

RTT ReqTransTree(IntermediateTree IntTREE) { Let N be a root node of IntTree; 1) if (N is a subgraph node) { R = convertSubgraph 2Tree(N); return R; } 2) Let R be a RTT whoose root node is N foreach (child node C of N) { (1) if (C is a subgraph node) { T = convertSubgraph 2Tree (C); Make subtree T into a child node of N; } (2) else { // C is a FC object node Let ST be a subtree in IntTree whoose roo t node is C T = ReqTransTree(ST); Make subtree T into a child node of N; } } 3) return R; } RTT convertSubgraph2Tree(subgraph N) { Let L be a last operation node of N; Let R be a RTT whoose root node is L; 1)Mark all objects ∈ N as unvisited 2)Create an RTT R, initially set L as root node of R, and mark L as visited 3)while(there is an unvisited object Obj that is reachable by backward traverse from an object already visited) { (1)mark Obj as visited (2)make input objects of Obj children node of Obj; } }

중간트리(IMT)에서 서브그래프는 항상 말단에 위치하게 된다. 왜냐하면 중간트리(IMT)를 생성할 때 흐름제어(FC) 객체는 항상 서브그래프의 상위에 놓이게 하였고, 서브그래프의 하위에는 아무것도 생성되지 않도록 하였기 때문이다. 이러한 특성을 바탕으로 상기 표 8의 ReqTransTree 알고리즘은 IMT의 노드 종류, 즉 노드가 FC 객체인 경우와 서브 그래프인 경우로 구별하여 처리한다.

노드가 서브그래프뿐인 경우는 IMT에 하나의 노드만 존재하게 된다. 따라서 서브그래프만 트리로 변환하면 곧바로 요구사항 번역 트리(RTT)가 얻어진다. 서브그래프 이외의 노드가 존재하는 경우, 즉, FC 객체가 루트인 경우는 자식들을 대상으로 다시 ReqTransTree을 재귀적으로 호출하여 IMT를 구축한다. 서브그래프를 트리 구조로 변형하는 알고리즘은 상기 표 8의 convertSubgraph2Tree와 같다. 입출력관계트리(IORT)를 출력 객체에서 출발하여 거꾸로 탐색하면서 트리구조로 만든다. 연산 객체는 루트에 놓이며, 연산 객체의 입력과 출력은 자식 위치에 놓인다. 어떤 자식이 입력인지, 혹은 출력인지는 연산 객체의 특성에 따라 결정된다.

2.4 자연어로의 번역

자연어로의 번역은 요구사항 번역트리(RTT)를 전위순회로 탐색하면서 이루어진다. 즉, 요구사항 번역트리(RTT)의 루트 노드를 번역한 후, 루트의 각 서브 트리를 차례대로 번역한다. 각 서브 트리 역시 동일한 방법으로 전위순회로 탐색하면서 번역한다.

노드를 번역하는 과정에서 다양한 문제가 발생한다. 첫째는 동일한 객체라 하더라도 다른 객체와 연결된 모양에 따라 다르게 번역되어야 한다는 점이다. 이를 해결하기 위하여 패턴을 기반으로 한 번역 기법을 적용하였다. 즉, 객체별로 사용 패턴을 분류하고, 각 패턴에 대한 자연어 템플릿을 작성하여 데이터베이스화하였다. 템플릿은 번역 문자열로 표시된다. 요구사항 번역트리(RTT)의 노드 객체의 사용 패턴을 판단한 후, 해당 번역 템플릿의 문자열 일부를 요구사항 번역 트리(RTT) 내의 객체의 속성으로 취한다. 사용 패턴은 객체의 타입, 입력을 제공하는 객체의 개수 및 유형, 출력을 넘겨줄 객체의 개수 및 유형 등에 의하여 결정된다. 객체 들을 서로 연결하는 링크에 조건이 주어졌는지의 여부도 사용 패턴을 결정하는 데 매우 중요하게 사용된다. 자연어 자체는 사용 패턴의 결정보다는 템플릿의 결정에 많은 영향을 주었다. 그러나 영어로 번역할 때와 한글로 번역할 때 사용 패턴은 달라지지 않는다. REED가 지원하는 총 44개 종류의 객체별 사용 패턴에 따른 템플릿의 수는 다음 표 9와 같다.

객체의 종류	템플릿 의 수
Input	5
Output	5
Memory	8(In4,Out4)
Event	4(In2,Out2)
Sequential	2
Equality	17
Bypass	8
Assignment	12

두 번째 문제는 요구사항 번역트리(RTT)가 많은 자식들을 포함하고 있을 때 발생한다. 많은 자식들을 포함한 하나의 다이어그램을 하나의 문장으로 번역하는 것은 번역된 문장의 이해를 어렵게 한다. 이에, 본 발명에서는 하나의 노드를 하나의 문장으로 번역하고, 각각의 문장에 문장 번호를 부여하였다. 이러한 작업은 요구사항 번역 트리(RTT)의 각 노드를 독립적으로 번역함으로써 새로운 객체가 추가되더라도 확장을 용이하게 한다. 문장 번호는 문장의 깊이에 따라 차례대로 1, 1.1, (1), (A), (a) 등으로 부여하였다. 도 9는 번역된 모습과 문장 번호 부여 체제를 보여준다.

또 다른 문제는 하나의 요구사항 안에 여러 개의 다이어그램이 존재하는 경우이다. 이 경우, 다이어그램의 화면상의 위치와 번역된 문장의 순서를 일치시키기 위해서 다이어그램의 화면 위치를 이용하여 요구사항 번역트리(RTT) 자체를 정렬하였고, 제일 위에 위치한 다이어그램으로부터 생성된 요구사항 번역트리(RTT)에서부터 해석을 하여 해석된 문장과 다이어그램을 비교하여 이해하기 쉽도록 하였다.

자연어는 단어 이외에도 다양한 기능을 가진 조사를 사용한다. 조사는 단어가 주어인지 목적어인지를 나타내기도 하며, 단어와 단어를 연결하는데 사용되기도 한다. 앞 단어의 문자적 특성에 따라 조사가 달라지기도 한다. 예를 들면, "감"이라는 단어를 주어로 만들기 위하여 "'이'라는 조사가 사용되지만 '가'라는 조사는 사용되지 않는다. 본 발명에서는 이러한 언어적 특성으로 발생하는 문제를 해결을 향후 발명 과제로 미루고, "이(가)"처럼 동일한 의미를 가진 조사를 모두 표기하는 방법을 사용하였다. 즉 "감 이(가)"와 같이 번역한다. 조사를 정교하게 구별하여 사용하는 알고리즘에 대한 발명이 이루어지는 경우, 다이어그램의 가독성이 크게 향상되리라 본다.

3. 실험예

본 발명이 적용된 REED를 이용하여 임베디드 시스템의 요구사항을 다이어그램으로 기술하고, 기술된 요구사항을 바탕으로 테스팅 작업을 수행하였다. 자동차 내부 온도 자동조절장치(TC), 버스 요금 계산기(BusCard), 굴삭기 제어기 등 3 개의 시스템의 요구사항은 워드프로세서 혹은 엑셀로 작성되어 있었다. 본 발명에서는 이들 요구사항들을 REED를 이용하여 요구사항 다이어그램으로 재구성하고, 재작성된 다이어그램을 바탕으로 시스템 들의 임베디드 소프트웨어를 테스트하였다.

요구사항 다이어그램의 작성 및 검증이 완료된 후, 각 시스템의 다이어그램을 본 발명에서 기술된 방법으로 한글 혹은 영어로 번역하였다. 각 장비들의 간단한 특성, 요구사항 다이어그램 관련 통계, 번역된 글에 관련된 통계는 다음 표 10과 같다.

상기 표 10에서 보는 바와 같이, 발명된 시스템들이 요구사항의 개수는 많으나 다이어그램으로 표기하기 위하여 사용된 객체의 수는 비교적 적다.

자동차 내부 온도 자동조절장치(TC)는 다양하며 정교한 온도 조절 기능을 299개의 요구사항으로 표현하고 있다. 예를 들면, 자동차 내부 온도 자동조절 장치(TC)의 요구사항은 다양한 센서로부터 감지된 온도의 평균을 사용하거나, 센서의 고장에 대한 처리 기능 등 매우 다양하며 세밀한 제어 기능을 명시하고 있다. 이에 따라, 34종의 다양한 객체를 사용하여 요구사항을 재구성하였다. 그러나 굴삭기 제어기는 자동차 내부 온도 자동조절장치(TC)와 비교할 때 요구사항의 수는 많으나 사용된 객체의 수는 적다. 굴삭기 제어기는 자동차 내부 온도 자동조절장치(TC)보다는 많은 수의 입출력 장치들에 대한 제어를 기술하기 위하여 많은 요구사항을 명시하고 있다. 그러나 자동차 내부 온도 자동조절장치(TC)보다는 적은 29종의 객체를 사용하여 요구사항을 재구성할 수 있다.

버스 요금 계산기(BusCard)는 입출력 장치의 수는 적으나 다른 시스템과 TCP/IP 통신을 하는 분산 시스템이다. 버스 요금 계산기(BusCard)의 일부 기능만을 요구사항으로 표현하고 테스트를 수행하였다. TCP/IP 패킷에 기록된 정보는 많으나 그 처리가 비교적 간단하여 다이어그램에 사용된 그래픽적인 객체의 종류는 적으며 요구사항당 많은 수의 객체를 사용하고 있다. 전자레인지는 다이어그램의 수는 작으나 다양한 객체를 사용하고 있다. 이는 전자레인지의 요구사항이 사용자 메뉴얼로부터 구성되면서, 사용자 메뉴얼에는 제어 목표는 표현되었으나, 제어의 상세한 요구사항이 없기 때문이다.

이러한 실험을 통하여 볼 때, 시스템의 종류나 기능, 복잡도에 따라 차이는 있으나, 대략적으로 20~30종의 객체를 사용하여 250~400개 정도의 요구사항 다이어그램이 표현됨을 알 수 있다. 문장의 최대 깊이는 번역된 문장들의 깊이를 가리킨다. 버스 요금 계산기(BusCard)나 굴삭기 제어기의 경우 최대 깊이가 5이다. 깊이가 5인 요구사항의 경우, 사용된 문장 번호 부여방식은 1, 1.1, (1), (A), (a) 등이다. 문장의 깊이는 RTT의 레벨을 가리키며, 하나의 출력을 내보내기 위해서 사용된 객체의 단계가 최대 5 단계라는 의미이기도 하다.

번역 문장 최대 줄 수는 가장 길게 번역된 문장의 줄 수이다. 버스 요금 계산기(BusCard)의 경우 최대 64줄의 문장으로 구성된다. 하지만 문장 최대 깊이는 5 레벨임을 알 수 있다. 가장 긴 문장은 이더넷으로 수신되거나 혹은 이더넷으로 송신할 패킷에 담긴 정보들을 구별하기 위하여 많은 객체들을 사용하는 문장이다. 이러한 경우, 패킷에 기록된 정보 각각에 대한 처리를 하나의 문장으로 번역하면서 많은 수의 문장이 필요하였으나, 그 경우의 문장의 깊이는 깊지 않다. 그러나 이 요구사항의 경우, 이것은 사용된 객체가 많아서 번역이 수행된 결과 문장은 길지만, 하나의 출력을 내보내기 위해서 필요한 블럭(block)의 단계는 많지 않다는 의미이다. 바꾸어 말하면, 하나의 다이어그램으로부터 입 출력관계트리(IORT)가 10개 이상 생성된 경우에 해당한다. 이처럼 여러 개의 입출력관계트리(IORT)가 하나의 요구사항에서 생성된다는 것은 하나의 요구사항이 실제로는 여러 개의 요구사항을 동시에 표현된 경우에 해당한다.

요구사항당 사용된 객체의 개수를 보면 굴삭기 제어기의 경우는 4.54개인 반면에 자동차 내부 온도 자동조절장치(TC)의 경우에는 9.45개로 2배 이상의 많은 차이가 나는 것을 볼 수 있다. 물론 시스템의 복잡도에 따라 다르겠지만 이 숫자는 굴삭기 제어기의 요구사항이 훨씬 간결하게 작성되었다는 것을 알 수 있다. 굴삭기 제어기의 요구사항은 자동차 내부 온도 자동조절장치(TC)보다 약 70개 가량이 더 많다. 하지만 2개의 시스템의 입/출력장치의 숫자는 비슷하다. 따라서 굴삭기 제어기의 요구사항이 훨씬 잘게 쪼개져 있다고 생각할 수도 있다. 이처럼 요구사항을 작은 단위로 나누어서 작성하는 경우, 번역된 문장의 깊이나 줄의 수가 줄어들고 가독성도 좋아진다.

4개의 임베디드 시스템의 요구사항을 표현하기 위하여 최대 40개 정 도의 객체가 사용되었다. 시스템의 특성에 따라 차이는 있으나, 일부 시스템의 경우, 약 20~30개 정도의 객체로도 그 기능을 매우 명확하게 기술할 수 있었다. 또한, REED가 제공하는 표기법만으로 요구사항 다이어그램을 재작성하는 동안, 명확하지 못한 요구사항들을 많이 식별하고 그것들 명확하게 재 정의하였다. 이는 워드프로세서나 엑셀로 작성된 문장을 의미가 분명하여야만 하는 그래픽적인 표기법으로 표현하는 과정에서 발생하는 자연스러운 현상이기도 하다.

출력을 기준으로 기술된 번역은 해당 출력이 생산되는 정확한 절차와 조건을 설명하고 있다. 즉, 번역된 문장은 입력과 출력의 관계를 다이어그램보다는 오히려 더욱 분명하게 설명하고 있다. 번역은 한 곳에서 여러 개의 출력을 생산하는 요구사항에 대하여 알려 주었다. 작은 요구사항은 읽기 쉬우며 명확하고, 테스트하기도 쉽다. 또한, 요구사항을 작은 단위로 나누도록 하면 요구사항을 작성하는 사람들로 하여금 요구사항을 더 이상 쪼개지지 않도록 만들려고 많은 노력을 기울이도록 한다. 이처럼 번역이 요구사항을 단순히 번역하여 개발과정에 참여하는 계층들 간의 격차를 없애 주는 역할을 할 뿐만이 아니라 요구사항을 명확화하고 보다 단순하게 하는데 도움을 준다는 사실을 알 수 있다.

번역된 문장의 깊이가 크지 않다는 사실을 통해서 문장 번호를 사용해서 번역을 해도 사람이 이해하기에 그다지 어렵지 않게 번역이 됨을 알 수 있다. 즉, 다이어그램을 실제 자연어와 같이 하나의 문장으로 만들지 못하고 여러 레벨의 문장 번호를 사용하여 쓴다고 할지라도 어렵지 않게 이해할 수 있는 문장으로 생성된다는 사실을 확인할 수 있다.

이처럼 작성된 요구사항을 한글로 번역한 후, 다이어그램이 가리키는 의미와 번역된 문장의 의미를 검토한 결과, 이러한 표기법을 처음 보는 사람들도 무슨 의미로 작성한 요구사항인지를 이해하는데 큰 도움이 되었다.

이상에서 본 발명은 도면에 도시된 일 실시 예를 참고로 설명되었으나, 본 기술분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다.

도 1은 일반적인 소프트웨어 개발 과정을 도시한 개략도 ,

도 2는 본 발명이 적용된 REED에서 전자레인지의 요구사항 중 하나를 작성하는 화면의 예,

도 3은 본 발명에 따라 전자레인지의 'Start Button'이 눌려 졌을 때의 요구사항을 하나의 다이어그램으로 기술한 예,

도 4는 도 3의 요구사항에 따른 2개의 입출력관계트리(IORT)의 예,

도 5는 본 발명에 따라 흐름제어 객체를 포함한 요구사항 다이어그램의 예,

도 6은 본 발명에 따라 'E quality' 연산 객체부터 출발해서 입출력관계트리(IORT)를 생성한 예,

도 7은 도 6의 입출력관계 트리(IORT)로부터 만들어진 중간트리(IMT) 및 서브그래프의 예,

도 8은 본 발명에 따른 요구사항 번역트리(RTT)의 예,

도 9는 본 발명에 따라 자연어 번역된 모습과 문장 번호 부여 체제를 보여주는 예이다.

Claims (10)

1. 소프트웨어 개발과정에서 그래픽적인 모델링 언어로 작성된 요구사항을 자연어로 번역하는 요구사항 모델에서 자연어로의 번역방법에 있어서,

   요구사항에서 사용된 각 최종 출력들을 위한 입출력관계트리(IORT)를 생성하는 제 1 단계;

   상기 제 1 단계에서 생성된 입출력관계트리(IORT)를 요구사항 번역트리(RTT)로 변환하는 제 2 단계; 및

   상기 제 2 단계에서 구해진 요구사항 번역트리(RTT)의 루트노드로부터 각 노드들을 차례로 전위순회로 방문하면서 해당 요구사항번역트리(RTT)를 자연어로 변환하는 제 3 단계를 포함하는 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
2. 제1항에 있어서, 상기 제 1 단계는

   여러 개의 엔티티 객체와 연산 객체가 서로 연결된 다이어그램 모양의 요구사항에서, 각 출력 엔티티 객체로부터 거꾸로 다이어그램을 탐색하여 상기 입출력관계 트리를 생성하는 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법 .
3. 제2항에 있어서, 상기 제 1 단계는

   상기 요구사항의 다이어그램이 루프나 시퀀셜과 같은 흐름제어 객체를 포함하는 경우, 생성된 입출력 관계 트리를 관련이 있는 것과 병합하는 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
4. 제1항에 있어서, 상기 제 2 단계는

   상기 제 1 단계에서 생성된 입출력관계 트리에서 흐름제어 객체를 중심으로 바라본 중간트리로 변환하는 2-1단계와,

   상기 중간 트리의 각 서브그래프를 출력에서 입력으로 거꾸로 탐색하여 연산객체를 중심으로 요구사항번역 트리를 구성하는 2-2단계로 구성된 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
5. 제4항에 있어서, 상기 2-1 단계는

   입출력관계 트리에서 사용된 하나의 흐름제어 객체를 찾은 후 이들 객체의 링크를 따라 탐색하면서 찾은 객체를 그룹으로 묶어 흐름제어 객체의 자식으로 만드는 단계와,

   흐름제어 객체를 가리키는 노드와, 흐름제어 객체가 포함되지 않은 서브그래프를 가리키는 노드들로 이루어진 그래프를 만드는 단계로 이루어진 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
6. 제 4항에 있어서, 상기 2-2단계는

   중간트리의 노드를 흐름제어 객체인 경우와 서브그래프로 구분하여

   노드가 서브그래프이면 서브그래프를 트리구조로 변형하고, 흐름제어 객체인 경우 자식들을 대상으로 서브 그래프를 트리구조로 변형하는 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
7. 제1항에 있어서, 상기 제 3 단계는

   상기 요구사항 번역 트리를 전위순회로 탐색하면서 상기 요구사항 번역 트리의 루트 노드를 번역한 후 루트의 각 서브 트리를 차례대로 번역하는 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
8. 제7항에 있어서, 상기 제 3 단계는

   객체별로 사용패턴을 분류하고, 각 사용패턴에 대한 자연어 템플릿을 작성하여 데이터베이스화한 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
9. 제7항에 있어서, 상기 제 3 단계는

   상기 요구사항 번역트리(RTT)가 많은 자식들을 포함하고 있을 경우, 하나의 노드를 하나의 문장으로 번역하고, 각각의 문장에 문장 번호를 부여한 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.
10. 제7항에 있어서, 상기 제 3 단계는

    하나의 요구사항 안에 여러 개의 다이어그램이 존재하는 경우, 다이어그램의 화면상의 위치와 번역된 문장의 순서를 일치시키기 위해서 다이어그램의 화면 위치를 이용하여 요구사항 번역트리(RTT) 자체를 정렬하고, 제일 위에 위치한 다이어그램의 요구사항 번역트리(RTT)부터 순차적으로 해석하는 것을 특징으로 하는 요구사항 모델에서 자연어로의 번역방법.

Images