KR20100091209A

KR20100091209A - 의미론적 분석에 의해 선택된 오프―더―쉘프 구성요소들 및 명세서들로부터 애플리케이션들을 자동적으로 구축하기 위한 디바이스 및 방법

Info

Publication number: KR20100091209A
Application number: KR1020107012172A
Authority: KR
Inventors: 필리페 라르베
Original assignee: 알까뗄 루슨트
Priority date: 2007-12-07
Filing date: 2008-11-18
Publication date: 2010-08-18
Also published as: KR101584972B1; RU2495480C2; RU2010128102A; BRPI0820905A2; US20090150853A1; JP2011507061A; EP2071452A1; CN101452392B; CN101452392A; JP5319694B2; MX2010006118A; TWI446263B; WO2009071440A1; IL205865A; IL205865A0; AU2008333378B2; US8453105B2; AU2008333378A1; TW200939121A

Abstract

명세서들(AS) 및 소프트웨어 구성요소들(SC)로부터 애플리케이션들(AP)을 구축하는 디바이스(D)는 i) 소프트웨어 구성요소가 실행할 수 있는 각각의 공용 연산을 규정하기 위한 적어도 하나의 관련 어구를 포함하는 의미론적 디스크립션에 연관된 소프트웨어 구성요소로 구성되는, 의미론적 소프트웨어 구성요소들을 저장하기 위한 저장 수단(SM), ii) 구축될 애플리케이션(AP)을 기술하는 명세서(AS)가 수신될 때마다, 명세서(AS)의 텍스트로부터 기본 요건들, 및 이들 기본 요건들(SR) 사이의 링크들을 추출하기 위해서, 명세서의 의미론적 분석을 실행하는 것으로서, 상기 링크들은 "명세서의 전체 구조"를 규정하는, 상기 명세서의 의미론적 분석을 실행하고, 각각의 기본 요건에 대해서, 이것이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건에 대해서, 추출된 관련 어구들에 기초하고 "이 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 구축하고, 각각의 추출된 기본 요건에 대해서, 어떤 구성요소(들)가(이) 추출된 기본 요건(SR)을 커버할 수 있는지 결정하기 위해, 저장 수단(SM)에 액세스하기 위해 구성된 분석 수단(AM), 및 iii) 애플리케이션(AP)을 구축하기 위해서, 명세서의 전체 구조에 따라 결정된 소프트웨어 구성요소들을 어셈블링하기 위한 처리 수단(PM)을 포함한다.

Description

의미론적 분석에 의해 선택된 오프―더―쉘프 구성요소들 및 명세서들로부터 애플리케이션들을 자동적으로 구축하기 위한 디바이스 및 방법{DEVICE AND METHOD FOR AUTOMATICALLY BUILDING APPLICATIONS FROM SPECIFICATIONS AND FROM OFF-THE-SHELF COMPONENTS SELECTED BY SEMANTIC ANALYSIS}

본 발명은 애플리케이션들(applications)의 설계에 관한 것으로, 특히 오프-더-쉘프(off-the-shelf) 소프트웨어 구성요소들로부터 애플리케이션들을 구축하기 위한 방법 및 디바이스에 관한 것이다.

객체-지향 및 구성요소-기반 애플리케이션 개발의 범위에서 참조들로서 이용된 수용된 규정들에 따라서, "설계"라는 용어는 여기에서는 코드 위의 논리적 수준에서, 이 애플리케이션이 어떻게 구현될 것인가를 기술하는 애플리케이션의 단계를 의미한다. 설계에 있어서, 애플리케이션의 요구된 기능 및 질적 요건들을 충족시키기 위해 전략적 및 전술적 결정들이 행해진다. 예를 들면, Grady Booch의 책자 "Object-Oriented Analysis and Design with Applications", 3판 - Cased, Addison-Wesley (2007), ISBN 9780201895513에 설명에 따르면, 이 단계의 결과들은 설계-레벨 모델들: 정적 뷰, 상태 머신 뷰 및 상호작용 뷰로 나타나게 된다. 설계의 액티비티(activity)는 애플리케이션의 아키텍처(architecture)에 이르게 되고, 이것은 이 애플리케이션의 조직적 구조이며: 이는 소프트웨어 구성요소들로의 분해, 이들 소프트웨어 구성요소들 사이의 연결성, 상호작용 메커니즘들(interaction mechanisms), 및 애플리케이션의 설계를 알려주는 안내 원리들을 포함한다.

많은 저자들이 (소프트웨어) 구성요소-기반 애플리케이션들의 구축을 안내하는 몇가지 방법들을 기술하였으나 이들 방법들은 2가지 주된 결점들이 있다: 이들은 완전히 수작업이며, 정확한 구성요소들을 찾아 어셈블링하는 과정이 구축될 애플리케이션의 명세서로부터 직접 얻어지지 않는다는 것이며, 이 명세서는 애플리케이션이 커버(cover)해야 할 기능 및 비-기능 요건들을 기술하는 것이다.

본 발명의 목적은 애플리케이션 명세서들의 의미론적 분석에 의해서, 및 애플리케이션 명세서의 텍스트(text)에 표현된 요건들 사이의 관계들(즉, 문제의 아키텍처)로부터 애플리케이션 설계(즉, 솔루션의 아키텍처)가 얻어질 수 있음을 고찰함으로써, 오프-더-쉘프 소프트웨어 구성요소들로부터 애플리케이션들을 자동적으로 구축하는 새로운 방법 및 대응 디바이스를 제안하는 것이다.

이 목적을 위해서, 구축될 애플리케이션을 기술하는 명세서를 받을 때마다:

- 명세서의 텍스트로부터 기본 요건 및 이들 기본 요건들 사이의 링크들을 추출하기 위해서, 이 명세서의 의미론적 분석을 실행하는 단계로서, 상기 링크들의 세트는 이하 "명세서의 전체 구조"라고 하는, 상기 명세서의 의미론적 분석 실행 단계,

- 각각의 기본 요건에 대해서, 이것이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건에 대해서, 그의 추출된 관련 어구들에 기초하며 "이 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 구축하는 단계,

- 각각의 추출된 기본 요건에 대해서, 이 기본 요건의 의미론 및 구성요소들의 의미론적 디스크립션들을 비교함으로써, 어떤 구성요소(들)가(이) 상기 추출된 기본 요건을 커버할 수 있는지를 결정(선택)하기 위해, 각 구성요소가 등록되고 "의미론적 소프트웨어 구성요소들"(이것은 각각의 구성요소가 이 소프트웨어 구성요소가 실행할 수 있는 각각의 공용 연산을 규정하기 위한 적어도 하나의 관련 어구를 포함하는 "의미론적 디스크립션"에 연관된 것임을 의미한다)로서 기술되는 적어도 하나의 구성요소 저장소에 액세스하는 단계, 및

- 애플리케이션을 구축하기 위해서, 명세서의 전체 구조에 따라 이들 결정된 소프트웨어 구성요소들을 최종적으로 어셈블링하는 단계로 구성되는, 명세서들 및 ("오프-더-쉘프") 소프트웨어 구성요소들로부터 애플리케이션들을 구축하기 위한 방법을 제공한다.

따라서, 의미론적 디스크립션들은 소프트웨어 구성요소들 뿐만 아니라, 기본 요건들에 연관될 수 있다:

- 기본 요건들의 의미론적 디스크립션들이 결정되고 기본 요건 자체의 텍스트, 즉 기본 요건의 표현을 구성하는 문장(들)에 연관된다;

- 소프트웨어 구성요소들의 의미론적 디스크립션들이 결정되고 후술하는 바와 같이, 이 구성요소가 실행할 수 있는 공용 연산(들)에 연관된다.

본 발명에 따른 방법은 개별적으로 또는 조합되는 것으로 간주되는 부가의 특징을 포함하고, 특히:

- 소프트웨어 구성요소들의 의미론적 디스크립션들의 적어도 일부는 i) 소프트웨어 구성요소가 실행할 수 있는 연산의 목적, ii) 연산의 목적 및 연산의 입력(들)/출력 파라미터들을 기술하는 어구들이 규정되는 도메인(domain)을 지정하는 적어도 하나의 도메인 식별자, 및 iii) 이들 입력(들)/출력 파라미터들에 연관된 관련 어구들 및/또는 특정의 메타-데이터를 포함하고;

- 추출된 기본 요건들의 각각에 대해서, 이의 의미론적 디스크립션과 저장된 소프트웨어 구성요소들 각각의 의미론적 디스크립션 사이의 의미론적 거리를 결정할 수 있고, 최소 의미론적 거리에 대응하는 저장된 소프트웨어 구성요소를 선택할 수 있고, 따라서 이 선택된 소프트웨어 구성요소는 기본 요건을 구현하고;

- 이 n-업렛이 이하 "syn-업렛(syn-uplet)"이라고 하는 것으로 예를 들면, 동의어들인, 단어들의 주 n-업렛을, 기본 요건의 각각의 관련 어구에 연관시키며, 이 syn-업렛은 "req-업렛"이라 하며, 같은 방법으로, syn-업렛을 각 소프트웨어 구성요소의 각각의 공용 연산의 목적의 각각의 관련 어구에 연관시키며, 이 syn-업렛을 이하 "comp-업렛"이라 하며, 각각의 기본 요건과 각각의 저장된 소프트웨어 구성요소 사이의 의미론적 거리를 결정하기 위해서 이들 req-업렛들 각각을 이들 comp-업렛들 각각과 비교할 수 있고;

▶ 각각의 req-업렛 및 각각의 comp-업렛에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정할 수 있고, 각각의 기본 요건에 대해 예를 들면, "sem-업렛"이라고 하며 상기 req-업렛들 각각과 comp-업렛들 각각의 com-업렛들 사이의 의미론적 근접들을 나타내는 2차 n-업렛을 구축할 수 있고, 각각의 2차 n-업렛은 의미론적 거리를 규정하며, 이어서 최소 의미론적 거리를 규정하는 2차 n-업렛에 대응하는 저장된 소프트웨어 구성요소를 선택할 수 있고;

- 애플리케이션의 구조를 최적화하기 위해서, 추출된 기본 요건들에 대응하는 선택된 저장된 소프트웨어 구성요소들 사이의 명세서의 전체 구조를 규정하는 것들과 동일한 관련 링크들을 확정할 수 있고;

- 명세서의 전체 구조를 결정하기 위해서, 각 쌍의 기본 요건들의 req-업렛들에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정할 수 있고, 각각의 기본 요건에 대해서, "sem-업렛"이라 하는 것으로 그의 req-업렛과 다른 기본 요건들의 req-업렛들 사이의 의미론적 근접들을 포함하는, 2차 n-업렛을 구축하고, 각각의 sem-업렛은 의미론적 거리를 규정하고, 2개의 구별되는 기본 요건들의 sem-업렛의 값이 최대일 때 이들 사이의 관련 링크를 확립한다.

또한, 본 발명은 명세서들 및 소프트웨어 구성요소들로부터 애플리케이션들을 구축하기 위한 디바이스를 제공하고:

- 의미론적 소프트웨어 구성요소들을 저장하기 위한 저장 수단으로서, 상기 의미론적 소프트웨어 구성요소들 각각은 소프트웨어 구성요소가 실행할 수 있는 각각의 공용 연산을 규정하기 위한 적어도 하나의 관련 어구를 포함하는 의미론적 디스크립션에 연관된 소프트웨어 구성요소로 구성되는, 상기 저장 수단,

- 구축될 애플리케이션을 기술하는 명세서가 수신될 때마다, i) 명세서의 텍스트로부터 기본 요건들, 및 이들 기본 요건들 사이의 링크들로서, 상기 링크들의 세트는 이하 "명세서의 전체 구조"라고 하는, 상기 링크들을 추출하기 위해서, 명세서의 의미론적 분석을 실행하고, ii) 각각의 기본 요건에 대해서, 이것이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건에 대해서, 그의 추출된 관련 어구들에 기초하며 "이 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 구축하고, iii) 각각의 추출된 기본 요건에 대해서, 이 기본 요건의 의미론 및 구성요소들의 의미론적 디스크립션들을 비교함으로써, 어떤 구성요소(들)가(이) 이 추출된 기본 요건을 커버할 수 있는지를 결정(선택)하기 위해, 저장 수단에 액세스하기 위해 구성된 분석 수단, 및

- 애플리케이션을 구축하기 위해서, 명세서의 전체 구조에 따라 결정된 소프트웨어 구성요소들을 어셈블링하기 위한 처리 수단을 포함한다.

본 발명에 따른 디바이스는 개별적으로 또는 조합되는 것으로 간주되는 부가의 특징을 포함하고, 특히:

- 분석 수단은 각각의 추출된 기본 요건들에 대해서, 그의 의미론적 디스크립션과 저장된 소프트웨어 구성요소들 각각의 의미론적 디스크립션 사이의 의미론적 거리를 결정하고, 최소 의미론적 거리에 대응하는 저장된 소프트웨어 구성요소를 선택하기 위해 구성될 수 있고, 따라서 이 선택된 소프트웨어 구성요소는 기본 요건을 구현한다;

- 분석 수단은 이 n-업렛이 "syn-업렛"이라고 하는, 예를 들면 동의어들인, 단어들의 주 n-업렛을 기본 요건의 각각의 관련 어구에 연관시키고, 이 syn-업렛은 "req-업렛"이라 하고, 각각의 기본 요건과 각각의 저장된 소프트웨어 구성요소 사이의 의미론적 거리를 결정하기 위해서 이들 req-업렛들 각각을 각각의 comp-업렛들(각 소프트웨어 구성요소의 각각의 공용 연산의 목적의 각각의 관련 어구에 연관된 syn-업렛)에 비교하기 위해 구성될 수 있고,

▶ 분석 수단은 i) 각각의 req-업렛 및 각각의 comp-업렛에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정하고, ii) 각각의 기본 요건에 대해서 예를 들면, "sem-업렛"이라고 하며 req-업렛들 각각과 comp-업렛들 각각의 comp-업렛들 사이의 의미론적 근접들을 나타내는, 2차 n-업렛을 구축하고, 각각의 2차 n-업렛은 의미론적 거리를 규정하고, iii) 최소 의미론적 거리를 규정하는 2차 n-업렛에 대응하는 저장된 소프트웨어 구성요소를 선택하기 위해 구성될 수 있고;

- 처리 수단은 애플리케이션의 구조를 최적화하기 위해서, 추출된 기본 요건들에 대응하는 선택된 저장된 소프트웨어 구성요소들 사이의 명세서의 전체 구조를 규정하는 것들과 동일한 관련 링크들을 확립하기 위해 구성될 수 있고;

- 전체 구조를 결정하기 위해서, 분석 수단은 i) 각 쌍의 기본 요건들의 req-업렛들에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정하고, ii) 각각의 요건에 대해, 그의 req-업렛과 다른 기본 요건들의 req-업렛들 사이의 의미론적 근접들을 포함하는 것인 2차 n-업렛(또는 "sem-업렛")을 구축하고, 각각의 sem-업렛은 의미론적 거리를 규정하는 것이며, 2개의 구별되는 기본 요건들의 sem-업렛의 값이 최대일 때 이들 사이에 관련 링크를 확립하기 위해 구성될 수 있다.

본 발명의 다른 특징들 및 잇점들은 이하 상세한 명세서들 및 본 발명에 따른 디바이스의 실시예의 일례를 개략적으로 도시한 단일 도면인 첨부된 도면을 검토할 때 명백하게 될 것이다.

첨부한 도면은 본 발명을 완전하게 할 뿐만 아니라, 필요하다면, 본 발명의 규정에 기여하기 위해 제공될 수 있다.

본 발명은 오프-더-쉘프 소프트웨어 구성요소들을 이용함으로써, 애플리케이션들의 명세서들의 텍스트로부터 애플리케이션들을 자동적으로 구축하는 디바이스, 및 연관된 방법을 제공하는 것을 목적으로 한다.

본 발명은 명세서에 의해 기술되고 오프-더-쉘프 소프트웨어 구성요소들의 어셈블리로부터 구축될 수 있는 임의의 유형의 애플리케이션을 다룬다.

여기에서 "애플리케이션"이라는 용어는 하나의 세트의 상호-관계된 (소프트웨어) 구성요소들을 의미하는 것으로, 이들 각각은 연산이라고 불리우는, 하나의 세트의 적어도 하나의 공용 함수로서 표현되는 기능성을 가지며, 자신의 데이터를 인캡슐레이트(encapsulate)하고 관리한다. 이 규정은 객체-지향으로부터 얻어진, 구성요소 패러다임이며 최근의 개발 표준이다.

또한, "오프-더-쉘프 소프트웨어 구성요소"이라는 표현은 여기에서는 파일 관리 메커니즘, 데이터베이스 액세스, GUI 디스플레이 메커니즘, 텍스트 번역, 변환 모듈, URL로부터 판독하는 HTML 페이지, 텍스트 처리를 위한 기본 함수, 등과 같은, 정밀 기본 함수(즉, 원자(atom)의 기능성)를 구현하는 하나의 피스(piece)의 실행가능한 코드를 의미한다.

도 1은 본 발명에 따른 디바이스의 실시예의 일례를 개략적으로 도시한 도면.

도 1에 개략적으로 도시된 바와 같이, 본 발명에 따른 디바이스(D)는 적어도 저장 수단(SM), 분석 모듈(AM) 및 처리 모듈(PM)을 포함한다.

저장 수단(SM)은 적어도, 의미론적 소프트웨어 구성요소들(SSC)을 저장한다. 각각의 의미론적 소프트웨어 구성요소(SSC)는 의미론적 디스크립션(SD)에 연관되는 소프트웨어 구성요소(SC)로 만들어진다.

"소프트웨어 구성요소의 의미론적 디스크립션"이라는 표현은 여기에서는 연관된 소프트웨어 구성요소(SC)가 실행할 수 있는 공용 연산(또는 함수)의 목적을 규정하는 적어도 하나의 관련 어구를 포함하는 디스크립션을 의미한다. 이 목적은 간단히 자연 언어 형태(즉, 관련 어구들을 갖는)로 표현되는 것이 바람직하며 구성요소(SC)가 실제로 무엇을 하는지, 이의 기능(들)이 무엇인지 및 어떤 데이터를 조작하는지(즉, 이의 연산(들)의 입력(들)/출력(들))를 명백하게 기술한다. 바람직하게, 각각의 구성요소의 의미론적 디스크립션(예를 들면, "의미론적 카드"라고 하는)(SD)은 각각의 연산을 기술하는 어구들이 규정되는 도메인을 지정하는 적어도 하나의 도메인 식별자도 포함한다.

예를 들면, 소프트웨어 구성요소의 각각의 의미론적 디스크립션(SD)은 입력들 및 출력 데이터가 다음의 3가지 주 속성들로 기술되는 XML 표현이다:

- 데이터 명칭(또는 식별자);

- 데이터의 의미론을 명시하기 위해서, 외부 온톨로지(ontology)에서 또는 외부 사전 또는 시소러스(thesaurus)에서 클래스로서 규정된 개념에 관련하여 표현된, 데이터에 연관된 개념(또는 관련 어구). 여기에서, 온톨로지는 예를 들면, 구성요소(SC)에 의해 표현되고 이름이 의미론적 카드의 헤더에 언급된 도메인을 일컫는다.

- 의미론적 데이터 유형의 스테레오타입(stereotype)을 나타내며 데이터의 특성을 명시하는, 데이터의 의미론적 태그(예를 들면, "semTag"라고 함). 이 semTag는 후술하는 바와 같이, 구성요소들의 상호작용들을 결정하여 최적화하는데 유용할 것이다.

의미론적 소프트웨어 구성요소들(SSC)을 저장할 수 있고 당업자로부터 공지된 임의의 유형의 저장 수단(SM)은, 특히 데이터베이스들, 플래시 메모리들, ROM들 또는 RAM들, 플랫 파일 시스템들(flat files systems) 및 임의의 다른 종류의 저장소가 이용될 수도 있다.

분석 모듈(AM)은 그의 디바이스(D)가 구축될 애플리케이션(AP)을 기술하는 명세서(AS)를 수신할 때마다 개입하기 위해 구성된다.

"애플리케이션 명세서"라는 표현은 여기에서는 요망되는 애플리케이션이 이행해야 하는 적어도 하나의 요건을 규정하는 적어도 하나의 문장을 의미한다. 특히, 애플리케이션 요건들은 애플리케이션(AP)이 무엇을 할 것인지, 및 그의 기능 및 비-기능 특징들이 무엇인지를 기술한다. 이들 요건들은 바람직하게는 자연 언어로 표현되나, 그들은 임의의 공식적 또는 비-공식적 텍스트 표현 형태 하에 표현될 수도 있다.

분석 모듈(AM)은 애플리케이션 명세서(AS)가 수신될 때마다:

▶ 예를 들면, 문법 분석기에 의해 명세서(AS)의 텍스트로부터 기본 요건들(SR), 및 이들 기본 요건들(SR) 사이의 링크들로서, 상기 링크들의 세트는 이하 "명세서의 전체 구조(또는 논리적 어셈블리)"라고 하는, 상기 링크들을 추출하고,

▶ 각각의 기본 요건(SR)에 대해서, 이것이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건(SR)에 대해서, 그의 추출된 관련 어구들에 기초하여 "이 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 추출하기 위해서, 이 수신된 애플리케이션 명세서(AS)의 의미론적 분석을 실행하고,

- 각각의 추출된 기본 요건(SR)에 대해서, 이 기본 요건(SR)의 의미론 및 구성요소들의 의미론적 디스크립션들(SD)를 비교함으로써, 어떤 구성요소(들)(SC)가(이) 이 추출된 기본 요건(SR)을 커버할 수 있는지를 결정(선택)하기 위해 저장 수단(SM)에 액세스한다.

분석 모듈(AM)은 2개의 서브(sub)-모듈들로 분할되고, 제 1 서브-모듈은 의미론적 분석을 실행하기 위한 것이며 제 2 서브-모듈은 제 1 서브-모듈에 의해 추출된 기본 요건(SR)을 커버할 수 있는 구성요소(들)를(을) 저장 수단(또는 구성요소 저장소)(SM) 내에 결정하기 위한 것임의 유의하는 것이 중요하다.

즉, 분석 모듈(AM)은 기본 요건들(SR)을 나타내는 각각의 문장의 의미(즉, 그의 의미론)를 결정하여, 이를 적절한 계산가능한 데이터 구조로 표현한다. 아이디어는 나중에 이 구조를 저장된 소프트웨어 구성요소들(SC)의 등가 의미론적 데이터 구조와 비교하고, 어떤 구성요소가 어떤 (기본) 요건(SR)을 커버할 수 있는지를 결정하기 위해서, 그들의 적절한 의미론적 데이터 구조를 갖는 기능성의 모든 의미론적 원자를 마크하는 것이다. 실제로, 그 자신의 의미론적 데이터를 수신하기 위해서, 각 문장(또는 원자의 요건)이 평가되어 마크될 수 있다. 이 프로세스는 온톨로지-기반의 요건 분석 방식과는 다른 것에 유의하는 것이 중요한데, 여기서 소프트웨어 요건 분석 방법은 소프트웨어 요건 명세서와 몇 개의 도메인 온톨로지들 사이에 매핑이 확립될 수 있는 도메인 온톨로지 기술에 기초한다. 온톨로지는 주어진 도메인에서 조작되는 개념들 및 이들 개념들 사이의 관계들의 공식적 디스크립션인 것을 상기하도록 한다. 본 발명에서, 의미론은 텍스트 자체로부터 추출되기 때문에, 요건 분석에 도움이 되게 하기 위해서 어떠한 외부 온톨로지도 이용되지 않는다.

연산의 목적들의 의미론은 바람직하게는 다음과 같은 정밀한 규칙들로 규정된다:

- 목적들은 특정의 단어들을 이용하여, 자연 언어로 표현된다;

- 이들 특정의 단어들은 의미론적 카드(SD)에 내장되고 목적들을 기재하기 위해 이용될 관련 단어들을 요약하는 "개념들의 리스트"에 속한다;

- 이들 "개념들의 리스트들"은 예를 들면, 외부 온톨로지들에, 즉 의미론적 카드(SD)에 참조되거나, 외부 사전 또는 시소러스의 규정들에 대한 단순 참조들일 수 있는 관계된 도메인들의 공식적 디스크립션들로 기술될 수도 있다.

이러한 규칙들은 간결하고 모호하지 않은 연산 목적들을 기재하는데 도움을 준다.

RSS-피드-액세서 구성요소(RSS-feed-accessor component)에 연관된 의미론적 카드(SD)의 비-제한적 예가 이하 주어진다:

<URL>http://xxx.xx.xxx.x/components/RSS/RSS_Component.asmx</URL>

</domain>

</domain>

</domains>

<goal>Deliver the titles of all the news of the RSS feed addressed by a given URL.</goal>

</inputs>

</operation>

<goal>Deliver the description of the title of one news of the RSS feed addressed by a given URL.</goal>

</inputs>

</operation>

</component>

</semCard>.

요건들(SR)의 관련 어구들의 논리적 어셈블리(또는 전체 구조)는 관련 어구들과 이들 사이의 논리적 순서 사이의 관련 링크들로 구성된다. 예를 들면, "The application has to access the Internet, to generate a script from the file "Parameters.txt" and to execute this script"라는 문장에서, 요건들을 나타내는 관련 어구들(또는 개념들)은 "access Internet", "generate script", "file "Parameters.txt"" 및 "execute script"이며, 이들 관련 어구들의 논리적 순서는 "access Internet", "read file "Parameters.txt"", "generate script" 및 "execute script"이다.

분석 모듈(AM)은 명세서의 기본 요건들(SR) 사이의 논리적 어셈블리를 결정하기 위해 구성됨에 유의하는 것이 중요하다. 실제로, 명세서(AS)를 포함하는 세트의 기본 요건들(SR)에서, 요건들(SR)은 서로 논리적으로 링크되는 것으로 가정된다. 이것은 2개의 상이한 요건들(2개의 피스들의 요건은 그들이 타겟된 애플리케이션(AP)의 주어진 데이터, 제약, 기능성 또는 특징에 관하여 말할 때 서로 링크된다) 사이의 링크가 이들 요건들을 구현하는 구성요소들 사이의 링크로 된다는 사실에 기인한다. 여기에서, 요건들(SR) 사이에 어떤 관련 링크들이 존재한다면, 이들 요건들(SR)을 구현하는 구성요소들(SC) 사이에 동일한 관련 링크들이 존재하는 것으로 가정된다. 따라서, "요건 네트워크"는 문제를 기술하는 애플리케이션 명세서(AS)의 전체 구조를 결정하기 위해서 요건들(또는 요건 원자들) 사이의 링크들을 분석함으로써 결정된다. 즉, 문제 구조는 솔루션 구조와 동일 구조이다.

예를 들면, 청구서의 VAT를 계산하는 애플리케이션을 고찰하도록 하고, 애플리케이션 명세서(AS)의 텍스트가 VAT 계산에 관한 2개의 상이한 단락들을 포함한다: VAT를 계산하는 일반적인 방법을 설명하는 제 1 단락, 및 제품 카테고리들에 따라 상이한 VAT 레이트들을 부가하는 제 2 단락(아마도 명세서(AS)에 나중에 위치된 몇 페이지들). 이들 두 단락들은 그들이 같은 데이터를 다루기 때문에 함께 링크되는 2개의 피스들의 요건들(SR)이다. 결국, 이들 요건들(SR)을 구현하는 2개의 구성요소들(SC)은 주어진 제품에 대한 VAT의 계산이 VAT 액수를 계산하는 일반적인 방법을 필요로 하기 때문에, 함께 링크되어야 할 것이다.

분석 모듈(AM)이 수신된 애플리케이션 명세서(AS)의 "요건들(SR)의 의미론" 및 이들 요건들(SR)의 논리적 어셈블리를 결정하였을 때마다, 분석 모듈은 의미론적 디스크립션들(SD)이 요건들의 의미론에 대응하는 의미론적 소프트웨어 구성요소(SSC)을 선택하기 위해 저장 수단(SM)에 액세스한다.

이 목적을 위해서, 분석 모듈(AM)은 애플리케이션 명세서(AS)로부터 추출된 요건의 의미를 구성요소의 의미론적 카드(SD)의 일부인 각 구성요소의 목적과 비교해야 한다. 이것은 이 구성요소(SC)가 요건을 커버하기 때문에 이를 선택할 수 있기 위해서 행해진다.

앞에서 언급된 바와 같이, 이 비교는 명세서 텍스트의 의미의 결정을 필요로 한다. 여기에서, 의미는 명세서 텍스트의 각 문장을 구성하는 모든 관련 어구들의 기본 의미들의 연쇄로 구성된다. 따라서, 2개의 상이한 텍스트들의 의미를 비교한다는 것은 그들이 의미론적으로 가까운지의 여부를 결정하기 위해서, 상이한 어구들 또는 개념들(2개씩)을 비교하는 것을 의미한다.

결국, 이 비교를 처리할 수 있기 위해서, 기본 어구의 의미를 표현하는 방식을 자유롭게 이용할 수 있는 것이 필요하다. 그렇게 하기 위해서, 시소러스에서 발견될 수 있는 어구의 동의어들로 주 n-업렛을 구축하는 것이 가능하다. 이러한 주 n-업렛을 이하 "syn-업렛"이라 한다.

예를 들면, "battle", "war", 및 "peace"라는 어구들의 syn-업렛들은 각각 다음과 같을 수 있다:

- battle = {fight, clash, combat, encounter, skirmish, scuffle,

conflict, confrontation, fracas, fray, action; struggle, crusade, war, campaign, drive, wrangle, engagement},

- war = {conflict, combat, warfare, fighting, confrontation, hostilities, battle; campaign, struggle, crusade; competition, rivalry, feud}, 및

- peace = {concord, peacetime, amity, harmony, armistice, reconciliation, ceasefire, accord, goodwill; agreement, pact, pacification, neutrality, negotiation}.

요건(SR)의 어구에 대해 syn-업렛이 구축된다면, 이는 "req-업렛"이라 할 수 있고, 소프트웨어 구성요소(SC)의 공용 연산의 목적의 어구에 대해 syn-업렛이 구축된다면, 이는 "comp-업렛"이라 할 수 있는 것에 유념한다.

syn-업렛들, 즉 req-업렛들 및 comp-업렛들에 관해서 다음 함수들을 규정할 수 있다:

- syn(word)는 어구 "word"에 대한 syn-업렛이고,

- N1은 "word1"에 대한 syn-업렛을 나타내며 N2는 "word2"에 대한 syn-업렛을 나타내고: N1 = syn(word1) 및 N2 = syn(word2)이고,

- card(N1)는 syn-업렛 N1의 카디널(cardinal), 즉 N1 내에 동의어들의 수이고,

- common(N1,N2)는 N1 및 N2에 공통인 동의어들의 수이고,

- avg(N1,N2)은 N1 및 N2의 카디널들의 평균이고,

그러면, 위에 언급된 syn-업렛들의 예들에 있어서, card(common(syn("battle"), syn("war"))) = 9이다. 즉, "battle" 및 "war"에 공통되는 9개의 동의어들이 있다.

또한, 예를 들면 2개의 syn-업렛들(syn(T1) 및 syn(T2)) 내에 공통의 동의어들을 고려하여 비를 계산함으로써 2개의 어구들(T1 및 T2) 사이에 의미론적 근접을 규정하는 것이 가능하다.

이러한 의미론적 근접(예를 들면, "semProx"라고 하는)은 예를 들면, 다음 식에 의해 주어질 수 있다:

semProx(T1, T2) = 100 * card(common(synT1), synT2))) / avg(synT1), synT2)).

위에 언급된 syn-업렛들의 예들에서, "battle" 및 "war"의 syn-업렛들의 의미론적 근접은 semProx("battle", "war") = 100 * 9 / 0.5 * (19 + 13) = 900 / 16 = 56.25에 의해 주어진다. 즉, "battle" 및 "war"의 세트들의 동의어들의 합집합에서, 엘리먼트들 중 56.25%가 이중으로 발견된다. 또 다른 샘플으로서, "war" 및 "peace"의 syn-업렛들의 의미론적 근접은 semProx("war", "peace") = 0에 의해 주어지며, 이는 논리적이다.

의미론적 근접은 두 어구들 사이의 근접 비를 나타낸다. 예를 들면, 의미론적 근접이 제 1 선택된 임계값 A(예를 들면, 50)보다 크거나 또는 100에 가깝다면, 2개의 어구들이 의미론적으로 가까운 것으로 간주한다. 반대로, 의미론적 근접이 제 2 선택된 임계값 B(예를 들면 10) 미만 또는 0에 가깝다면, 2개의 어구들이 의미론적으로 먼 것으로 간주한다. 임계값들 A 및 B의 값들은 처리될 텍스트들의 카테고리에 따라 "조율될(tuned)" 수 있다.

예를 들면, 주어진 문장의 의미의 결정은 다음과 같이 행해질 수 있다.

제 1 단계에서 문장이 분석되고 관련 어구들(단어들)이 추출된다. 관사들, 전치사들, 접속사들, 등과 같은 비-관련 단어들은 무시된다.

제 2 단계에서, 각각의 관련 어구(단어)에 대해서, 대응하는 syn-업렛이 구축된다.

마지막으로, 제 3 단계에서 문장에 포함된 관련 단어들의 모든 syn-업렛들을 어셈블링함으로써 전체 문장에 대한 글로벌 n-업렛이 구축된다. 이러한 글로벌 n-업렛은 "phrase-업렛"이라고 할 수 있다(이것은 super-n-업렛, 즉 n-업렛들의 n-업렛로서 간주될 수 있다).

일례로서, 호 관리 시스템의 명세서(AS)로부터 추출된 요건(SR)이 "The caller makes a call to a receiver by creating a message that contains the call subject, submitted to the receiver at the same time"이라면, 관련 어구들은 caller, call, make a call, receiver, message, subject 및 submit이다. 이 요건(SR)에 대한 phrase-업렛은 다음 syn-업렛들의 연쇄일 수 있다:

- caller = {phone caller, telephone caller, visitor, guest, company},

- call = {phone call, telephone call, buzz, bell, ring; demand, request, plea, appeal, bid, invitation},

- make a call = {phone, make a demand, send a request},

- receiver = {recipient, heir, addressee, beneficiary, inheritor, heritor},

- message = {communication, memo, memorandum, note, letter, missive, dispatch},

- subject = {topic, theme, focus, subject matter, area under discussion, question, issue, matter, business, substance, text; field, study, discipline, area},

- submit = {offer, present, propose, suggest, tender}.

명세서(AS)의 하나의 문장(S1)을 소프트웨어 구성요소들(SC)에 연관된 의미론적 디스크립션들(또는 카드들)(SD)의 2개의 다른 문장들(S2, S3)과 비교하는 것은 그들의 phrase-업렛들을 비교함으로써 행해질 수 있다. 이 비교는 후술하는 바와 같이, 문장들 사이의 의미론적 거리를 계산하기 위해 이용될 수도 있을 결과를 제공한다. phrase-업렛 비교 단계들은 다음과 같을 수 있다:

- 2개의 phrase-업렛들의 내부 syn-업렛들은 2개씩 비교된다. 즉, S1의 phrase-업렛의 모든 syn-업렛은 S2 및 S3의 phrase-업렛들의 모든 syn-업렛과 비교된다.

- 각 쌍의 syn-업렛들마다 의미론적 근접(semProx)이 계산된다.

- 예를 들면, "sem-업렛들"이라고 하는 순서화된 2차 n-업렛들이 구축된다. 각각의 의미론적 n-업렛(또는 sem-업렛)은 S1의 각각의 syn-업렛과 S2 또는 S3의 syn-업렛들 사이의 의미론적 근접들을 포함하며, 의미론적 거리를 규정한다.

- 최소 의미론적 거리를 제공하는 의미론적 n-업렛은 자제되며, 이 의미론적 n-업렛에 의해 관계되는 문장(S2 또는 S3)은 S1에 의미론적으로 더 가까운 것으로 간주되고 따라서 이의 대응하는 저장된 소프트웨어 구성요소(SC)가 선택된다.

이하 주어진 표는 요건들(SR) "The caller makes a call to a receiver by creating a message that contains the call subject, submitted to the receiver at the same time"와 구성요소 저장소(SM)에 저장된 구성요소 세트의 하나의 샘플 사이의 대응들을 탐색하는 비-제한적 예이다. 요건의 관련 어구들은 {caller, call, make call, receiver, message, subject, submit}이다. 다음 표의 마지막 우측에 열에 도시된 sem-업렛들은 이들 관련 어구들의 syn-업렛과 구성요소의 목적으로부터 계산된 것들 사이의 비교의 결과들이다. 이들 sem-업렛들을 신속히 살펴봄으로써 요건을 이행할 수 있는 구성요소들(SC)을 쉽게 결정할 수 있게 된다.

처리 모듈(PM)은 요망되는 애플리케이션(AP)을 구축하기 위해서 명세서의 논리적 어셈블리(즉, 분석 모듈(AM)에 의해 결정된 전체 명세서 구조)에 따라, 결정된 의미론적 소프트웨어 구성요소들(SSC)의 소프트웨어 구성요소들(SC)을 어셈블링하기 위해 구성된다.

앞에서 언급된 바와 같이, 이 어셈블링은 애플리케이션 명세서(AS)(또는 문제)의 요건들 사이의 관련 링크들이 결정된 소프트웨어 구성요소들(SSC)(솔루션의 블록들) 사이의 링크들과 유사한 대응을 갖는다.

따라서, 처리 모듈(PM)은 애플리케이션(AS)의 초기 아키텍처를 구성하기 위해서 의미론적 거리들이 가장 짧은 선택된 구성요소들(SC)을 요건들의 의미론적 원자들로 조직한다. 이 초기 아키텍처는 문제 구조(또는 요건 네트워크)를 복제하고 문제 원자들(또는 요건들) 대신 솔루션 원자들(또는 구성요소들(SC))을 사용함으로써 만들어진다.

앞에서 언급된 바와 같이, 명세서 요건들 사이의 관련 링크들을 요약하고 나타내는 요건 네트워크는 분석 모듈(AM)에 의해 결정된다. 이 목적을 위해서, 분석 모듈(AM)은 요건들(또는 요건 원자들) 사이의 관련 링크들을 드러내는 전술한 sem-업렛(2차 n-업렛) 방식을 이용할 수 있다. 명세서(AS)의 문장들은 phrase-업렛과 더불어 sem-업렛 방식을 이용함으로써 2개씩 의미론적으로 비교된다. 구체적으로, 명세서(AS)의 요건(R1)과 동일 명세서(AS)의 2개의 다른 요건들(R2, R3) 사이의 비교의 경우에:

- 2개의 phrase-업렛들의 내부 syn-업렛들이 2개씩 비교된다. 즉, R1의 phrase-업렛의 모든 syn-업렛은 R2 및 R3의 모든 syn-업렛과 비교된다,

- 각 쌍마다 의미론적 근접(semProx)이 계산된다,

- 순서화된 2차 n-업렛들(sem-업렛들이라 하는 의미론적 n-업렛들)이 구축된다. 각각의 sem-업렛은 R1의 각각의 syn-업렛과 R2 또는 R3의 syn-업렛들 사이의 의미론적 근접들을 포함하며, 의미론적 거리를 규정한다. 따라서, 의미론적 거리에 대해서, 다른 것들에 관하여 각 요건의 링크들을 나타내는 하나의 세트의 n-업렛들을 얻는다. 의미론적 근접에 관하여 "최상의" sem-업렛들, 즉 주어진 요건에 대해 가장 의미론적으로 관련 링크들만을 유지하기 위해서 의미론적 거리들의 수준을 "조율"하는 것이 가능하다. 이것은 각 요건이 의미론적으로 가장 근접한 한정된 수의 다른 요건들을 갖는다고 가정됨을 의미한다. 따라서, 의미론적으로 가장 근접한 다른 요건들을 나타내는 제한된 하나의 세트의 sem-업렛들에 의해서, 전체 명세서(AS)의 콘텍스트(context) 내에서, 요건이 공식적으로 기술될 수 있음을 고려한다.

예를 들면, R2가 R1 및 R3와 링크되지만 sem-업렛(R2,R3) > sem-업렛(R2,R1)이라면, 링크 R2-R3만이 최종 모델로 유지된다. 이것이 최적화 문제이다. 모델을 조율하는 것은 sem-업렛들 사이에 최대 수용가능한 갭을 결정함으로써 가능하다. 예를 들면, diff(sem-업렛(R2, R3), sem-업렛(R2,R1)) > 10일 경우, 링크 R2-R3만이 유지될 것임을 생각할 수도 있고, 여기서 "diff()"은 함수 차(또는 감산)이다. 변형에서, 문제 카테고리 또는 요건들의 종류에 따라서, 함수 "diff()"에 대한 한계(또는 임계값)은 5 또는 15와 같을 수 있다. 또 다른 변형에서, 최소 임계 레벨보다 큰 함수 diff()에 대응하는 모든 링크들은 문제 모델(또는 요건 네트워크)에 유지될 수 있고, 따라서 솔루션 모델에 복제될 수 있다.

솔루션 "분자(molecule)"는 그들이 동일 종류들의 원자들을 포함하지 않고 이용하지 않을지라도, 문제 "분자"와 동일한 공간적 구조를 갖고: 문제 원자들은 요건들이며 솔루션 원자들은 구성요소들(SC)이다. 문제 원자들은 그들이 같은 개념들을 공유하고 같은 요건들을 다루기 때문에 함께 링크되며, 솔루션 원자들은 그들이 같은 데이터를 공유 또는 교환하기 때문에 함께 링크된다. 그러나, 요건들 사이의 관련 링크들을 포함하는 요건 네트워크(또는 문제 분자)는 애플리케이션 아키텍처(또는 솔루션)와 동일한 링크들을 포함한다.

이들 두 종류의 원자들은 상이하고 정확히 동일한 특징을 갖고 있지 않으므로, 요건 네트워크에 관련한 링크들은 초기 구성요소 구조에서 관련하지 않을 수 있다. 실제로, 2개의 요건들이 동일 개념들을 공유한다는 사실이, 2개의 대응하는 구성요소들이 함께 상호작용한다는 것을 반드시 의미하는 것은 아니다. 따라서, 처리 모듈(PM)은 애플리케이션(AS)의 초기 아키텍처를 최적화하기 위해서, 더 구체적으로 최상의 구성요소 상호작용 모델을 결정하기 위해서 구성될 수 있다.

최적화 처리는 문제 구조로부터 상속된 가장 유용한 링크들, 즉 구성요소(Comp1)의 출력이 Comp2에 대한 입력인, 또는 그 반대인 2개의 구성요소들(SC)(Comp1, Comp2) 사이의 실제 데이터 교환들에 대응하는 연관들만을 유지하는 것을 목적으로 한다.

이 최적화 처리는 선택된 구성요소들(SC) 사이의 상호작용들을 결정하고 최적화하기 위한 구성요소들의 연산들의 데이터 디스크립션들에(더 구체적으로는 그들의 입력들 및 출력들에) 의미론적 메타데이터로서 첨부된 의미론적 태그들을 이용할 수 있다.

이들 의미론적 태그들이 적합하게 선택되어 설정된다면, 구성요소들(SC)이 연결될 수 있고 그들의 연결이 공식적으로 표현될 수 있다. 예를 들면, Comp1.operation_A()의 출력이 의미론적으로 Comp2.operation_B()의 입력과 들어맞는다면, Comp1은 "B의 입력"에 링크 "A의 출력"을 통해 Comp2에 연결될 수 있고, 다음과 같이 기재하는 것이 가능하다:

out_A = Comp1.operation_A(A_parameters);

out_B = Comp2.operation_B(out_A);

또는, 더 직접적으로:

out_B = Comp2.operation_B(Comp1.operation_A(A_parameters)).

이것은 2개의 연결된 데이터는 동일한 의미론적 "차원"을 갖는다는 것을 의미하는데, 즉 그들은 그들이 동일한 데이터 유형을 공유할 뿐만 아니라, 데이터의 같은 특성도 공유하기 때문에 서로 의미론적으로 들어맞는다는 것을 의미한다(또는 그들은 처리가 호환적이다). 이 의미론적 데이터 유형은 UML 태그 값과 유사하고 의미론적 디스크립션들(또는 의미론적 카드들)(SD) 내에서 입력들 및 출력들에 첨부되는 파라미터 "semTag"에 의해 표현될 수 있다.

Comp1의 출력을 Comp2의 입력에 연결하는 것이 그들이 의미론적으로 서로 들어맞기 때문에 가능하다는 사실(예를 들면, Comp1은 텍스트를 생성하고 Comp2는 텍스트를 소비한다)이 반드시 예를 들면, 텍스트를 생성하는 또 다른 구성요소인 Comp4의 출력 대신에, comp2가 Comp1의 출력을 효과적으로 기다리고 있음을 의미하지는 않는다. 사실, 솔루션 구조에 나타나 있는 링크들에 따름으로써 상호작용들이 구축되기 때문에 Comp1-Comp2 연결성이 입증된다. Comp4가 텍스트를 생성할지라도, 이것이 Comp2에 직접 링크되지 않는다. 결국, 그들의 입력들-출력들을 조합하려고 시도할 이유가 전혀 없다.

SemTag들은 구성요소들의 인터페이스들의 일관성을 보증하며, 이러한 이유로 그들은 구성요소들의 상호작용들을 최적화하기 위한 중요한 엘리먼트들이다. UML 의미에서 구성요소(SC)의 인터페이스는 그의 공용 연산들의 파라미터들과 더불어 그의 공용 연산들의 세트로 구성됨을 상기한다. 예를 들면, Comp1.operation_A()이 텍스트를 제공하며 Comp2.operation_B()은 구성요소 번역기의 연산 translate()인 것으로 가정하도록 한다. 텍스트를 번역하는 것이 맞을 때, Comp1.operation_A()의 출력은 Translator.translate()의 입력과 맞아야 한다. 그러나, Comp1.operation_A()이 주어진 회사에 대한 주식 기호를 제공한다고 하면, Translator.translate()에 의해 입력으로서 취해진 이 기호 및 텍스트는 동일한 데이터 유형 (스트링)을 가질 수 있지만, 그러나 이들은 주식 기호를 번역하려는 것이 맞지 않기 때문에 의미론적으로 동등하지 않다. 그러므로, 이들 두 데이터에 첨부된 의미론적 정보는 상이해야 하고, 결국 두 연산들, 및 그들의 2개의 구성요소들(SC)은 연결가능(또는 링크 가능)하지 않다.

semTag들의 유용성을 보이기 위해서 구성요소 번역기의 의미론적 카드(SD)의 비-제한적 예가 이하 주어진다:

<URL>http://xxx. xx. xxx. x/components/Translation/Translator.asmx</URL>

</domain>

</domain>

</domains>

<input name="source_language"

concept="Translation#SourceLanguage" semtag="language" />

<input name="target_language"

concept="Translation#TargetLanguage" semtag="language" />

</inputs>

<goal> The goal of the operation is to provide a translated_text written in a given target_language as a result of the translation of a given text_to_translate written in a source_language.

</goal>

</operation>

</component>

</semCard>.

예를 들면, 구성요소들(SC)이 웹 서비스들일 때, 그들의 의미론적 디스크립션들(의미론적 카드들)(SD)은 서비스의 WSDL(웹 서비스 디스크립션 언어)로부터 생성될 수 있다. 그러나, 의미론적 태그들을 자동적으로 설정하기 위해서, 도면에 도시된 바와 같이, 디바이스(D)의 선택적 및 특정의 의미론적 모듈(SSM)이 이용될 수 있다. 이 모듈(SSM)은 처리 모듈(PM)의 일부일 수도 있을 것이다.

이 의미론적 모듈(SSM)은 WSDL에 기술된 바와 같이, 동작의 파라미터들의 명칭들 및 유형들을 분석할 수 있고, 특정 온톨로지에서 의미론적 대응들을 탐색할 수 있다.

이 특정한 온톨로지는 일반적으로 프로그래머들에 의해 이용되는 입력 및 출력 데이터의 현재의 명칭들 및 유형들의 의미론 사이의 링크들, 및 대응하는 의미론적 태그들을 포함한다.

예를 들면, "텍스트" 또는 "콘텐트" 또는 "스트링" 유형의 "translated_page" 또는 "디스크립션" 명칭의 데이터는 데이터가 텍스트의 "차원"을 갖기 때문에, 의미 태그 "텍스트"를 가질 수 있다. "날짜" 또는 "스트링" 유형의, "날짜" 또는 "current_date" 명칭의 데이터는 의미론적 태그 "날짜", 등을 가질 수 있다.

의미론적 카드들(SD) 내에서 의미론적 태그들을 자동적으로 설정하는 이러한 특정한 온톨로지는 단순 대응 표로서 나타낼 수 있다. 이러한 대응 표의 예가 이하 주어진다.

데이터 명칭	유형	의미론적 태그
text, content, page, description,...	스트링	텍스트
date, current_date,...	스트링\|날짜	날짜
phone_number, mobile_phone, ...	스트링	telephone_number
lang, language, dest_lang, srce_lang,...	스트링	언어
postal_code, zip_code, city_code,...	스트링	zip_code
...

이러한 특정의 온톨로지는 당업자에 의해 쉽게 구축될 수 있고, 프로그래머들의 관행을 보이는 공포된 구성요소 인터페이스들의 콘텐트들을 분석하고 그들의 적합한 이용들을 요약함으로써 점진적으로 개선될 수 있다.

자동 구성요소 상호작용 모델을 구축하기 위해 의미론적 태그들이 어떻게 고려되는가를 보이는 일례가 이하 주어진다.

이 비-제한적 예에서 명세서(AS)의 요건(자연 언어로 표현된)은 애플리케이션(AP)이 뉴스 피드(news feed)의 번역된 버전(version)을 생성하는 것을 나타내는 것으로 가정된다. 또한, sem-업렛 플러스(plus) 구성요소-발견 방식은 이 요건에 2개의 구성요소들(SC)로서 RSS-액세서(accessor) 구성요소 및 번역기 구성요소(이의 의미론적 카드들(SD)의 예들이 위에 주어져 있다)를 할당한 것으로 가정된다.

예를 들면, RSS-액세서 구성요소는 인터넷을 통해 액세스될 수 있는 RSS 피드들로부터 정보를 모으는 것을 목적으로 하며 그의 인터페이스는 2개의 동작들을 포함한다: getAllTitles()는 주어진 URL에 대한 피드의 모든 주 타이틀들을 얻는 것이고, getDescriptionOfTitle()은 이 타이틀에 대해 짧은 기사의 텍스트를 얻는다.

예를 들면, 번역기 구성요소는 동작 translate()이 주어진 소스 언어(입력 파라미터)로 작성된 텍스트(입력 파라미터로서 주어진)를 목적 언어(입력 파라미터)로 작성된 번역된 텍스트(출력)으로 변환하는 고전적 구성요소이다.

이제, 문제는 이들 두 구성요소들, 즉 명세서 요건(즉, 뉴스 피드의 번역된 버전을 제공하는 것)을 이행하기 위해 그들의 3가지 동작들을 자동적으로 및 논리적으로 어셈블링하는 것이다. 이 목적을 위해서, 2가지 포인트들이 고려되어야 한다.

첫 번째 포인트는 데이터 대신, 의미론적 태그들을 구성요소 동작들의 입력들 및 출력들로서 간주하는 것으로 구성된다. 이것은 완전히 일관된 구성을 만들기에는 정밀하게 충분하진 않지만 어떤 가능한 연결성들이 나타나게 한다.

두 번째 포인트는 어떤 구성요소 동작들이 그의 입력들을 제공할 수 있는지를 찾고, 이들 동작들에 대한 프로세스를 반복하여: 어떤 다른 동작들이 그들의 입력들을 제공할 수 있는지를 탐색하기 위해서 타겟된 구성요소 어셈블리의 주 출력을 고찰하는 것으로 구성된다. 이어서 주 출력으로부터 이를 생성하는데 필요한 입력 데이터에 점진적으로 되돌아가며, 이와 같이 하여, 상이한 구성요소 동작들의 출력들 및 입력들을 링크함으로써 이들 구성요소 동작들을 자동적으로 어셈블링한다.

동시에, 링크들은 동작 호들을 나타내는 의사-코드(pseudo-code) 형태로 선입 후출(first in, last out; FILO) 스택에 저장될 수 있다. 이 프로세스의 끝에서, 스택의 콘텐트는 선택된 구성요소들 사이의 올바른 상호작용들을 나타낸다.

구성요소 어셈블리의 주 출력은 명세서 요건의 표현에 의해 주어진다. 번역된 버전이 요구되는 이 예에서, 주 출력은 번역된 텍스트, 즉 동작 Translator.translate()의 출력이다. 따라서, 타겟된 구성요소 어셈블리에 의해 표시된 함수의 "return"으로서 표현되는 이 주 출력을 스택에 넣어 둘 수 있다:

translated_text = Translator.translate(text_to_translate, src_lang, dest_lang);

return translated_text.

이제 이 동작의 입력들의 각각의 의미론적 태그들이 "언어", "언어" 및 "텍스트"인 이들 입력들로 가보면, 의미론적 태그 "텍스트"를 갖는 데이터가 동작 RSS.getDescriptionOfTitle()에 의해 제공됨을 알 수 있다. 따라서, 이 연산을 Translator.translate()에 연결시킬 수 있고, 호를 스택 내 연산 RSS.getDescriptionOfTitle()에 부가하여, 다음과 같이 교환된 파라미터의 명칭을 통해 Translator.translate()에 링크할 수 있다:

text_to_translate = RSS.getDescriptionOfTitle(site_address, title);

translated_text = Translator.translate(text_to_translate, src_lang, dest_lang);

return translated_text.

이제, RSS.getDescriptionOfTitle()의 입력들의 의미론적 태그들이 "URL" 및 "타이틀"인 이들 입력들로 가보면, 의미론적 태그 "타이틀"을 갖는 데이터가 연산 RSS.getAllTitles()에 의해 제공됨을 알 수 있다. 따라서, 스택에 새로운 연산 호를 넣어둠으로써 이들 두 연산들을 연결할 수 있다:

titles = RSS.getRSSTitles(adr_site);

text_to_translate = RSS.getDescriptionOfTitle(site_address, title);

translated_text = Translator.translate(text_to_translate, src_lang, dest_lang);

return translated_text.

명세서 요건들에 할당된 모든 구성요소들(SC)이 이용되고 함께 연결되었을 때, 스택은 이제 거의 실행가능한 의사-코드 형태 하에 구성요소 어셈블리의 일반적 구조를 포함한다. 그러나, 이 의사코드를 실행하기 전에 이를 구체화하는 것이 바람직하다. 이들 일부 구체화들을 이하 열거한다:

- 데이터 유형들이 고려되어야 한다. 예를 들면, RSS.getAllTitles()는 스트링들의 어레이를 리턴하며 단일 스트링이 아니다.

- 일부 파라미터들의 명칭들은 그들의 의미론을 통해서, 즉 그들의 semTag들의 도움을 받아 해결될 수 있다. 예를 들면, "adr_site" 및 "site_address"는 같은 개념을 복구하여 같은 semTag를 갖는다.

- 이외의 일부 파라미터들은 오리지널 요건에 포함된 어떤 유용한 정보를 이용하여 해결될 수 있다. 예를 들면, 요건이 프랑스어 번역을 명시한다면, 연산 Translator.translate()의 파라미터 "dest_lang"는 "프랑스어"로 설정되어야 한다.

- 다른 파라미터들을 해결하기 위해서 일부 부가적인 구성요소들(SC) 또는 구성요소 연산들이 이용될 수 있다. 예를 들면, 파라미터 "src_lang"는 주어진 텍스트의 소스 언어를 자동적으로 결정하기 위해, 유틸리티 구성요소인 "Language Finder", 또는 RSS 피드 구성요소 상에 연산 getSourceLanguage()을 이용함으로써 설정될 수 있다.

의사-코드를 완료하기 위한 구체화들을 실행하기 위해서 디바이스(D)의 또 다른 선택적 및 특정의 모듈(OSM)이 제공될 수 있다. 이 모듈(OSM)은 처리 모듈(PM)의 일부일 수도 있을 것이며, 또는 도면에 도시된 바와 같이 처리 모듈(PM)에 결합될 수도 있을 것이다. 예를 들면, 이 모듈(OSM)은 다음과 같은 소프트웨어 모듈일 수 있다.

Vector ComponentAssembly(String site_address) {

Vector result;

titles = RSS.getAllTitles(site_address);

foreach title in titles {

text_to_translate = RSS.getDescriptionOfTitle(site_address, title);

source_lang = LanguageFinder.getLanguage(text_to_translate);

translated_text = Translator.Translate(text_to_translate, source_lang,

"french");

result.add(title + translated_text);

}

return result;

}

가능하게 구체화된 후에, 의사-코드는 최종적으로 최적화 프로세스에 의해 생성되는 구성요소 어셈블리의 유효성을 테스트하기 위해서 예를 들면, 실행가능한 자바 파일로 변환될 수 있다.

명세서(AS)의 오리지널 텍스트의 의미론적 분석이 자동적이고, 소프트웨어 구성요소들(SC)의 발견 및 어셈블리가 자동적임을 고려하고, 애플리케이션 설계의 최적화 역시 자동적임을 고려하고, 마지막으로 이 최적화된 설계로부터 컴파일가능하고 실행가능한 코드 생성이 가능함을 고려할 때, 본 발명은 그의 명세서(AS)의 텍스트로부터 직접 실행가능한 애플리케이션(AP)을 생성하는 수단으로서 간주될 수 있다.

디바이스(D), 및 더 상세하게는 그의 분석 모듈(AM) 및 처리 모듈(PM), 및 아마도 그의 저장 수단(SM)은 바람직하게는 소프트웨어 모듈들이다. 그러나, 그들은 각각 전자회로(들) 또는 하드웨어 모듈들, 또는 하드웨어와 소프트웨어 모듈들의 조합으로 만들어질 수도 있다.

또한, 본 발명은 소프트웨어 구성요소들(SC)로부터 애플리케이션들(AP)을 구축하기 위한 방법에 대해서도 고찰될 수 있다.

이러한 방법은 도면을 참조하여 위에 기술된 것과 같은 디바이스(D)에 의해 구현될 수 있다. 그러므로, 그의 주 특징들만이 이하 언급될 것이다.

본 발명에 따른 방법은 명세서(AS)(구축될 애플리케이션(AP)을 기술하는)가 수신될 때마다:

- 명세서(AS)의 텍스트로부터 기본 요건들(SR), 및 이들 기본 요건들(SR) 사이의 링크들을 추출하기 위해서, 이 명세서(AS)의 의미론적 분석을 실행하는 단계로서, 상기 링크들의 세트는 "명세서의 전체 구조"라고 하는, 상기 명세서(AS)의 의미론적 분석 실행 단계,

- 각각의 기본 요건(SR)에 대해서, 이것이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건(SR)에 대해서, 그의 추출된 관련 어구들에 기초하여 "이 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 구축하는 단계,

- 각각의 추출된 기본 요건(AS)에 대해서, 이 기본 요건(SR)의 의미론 및 구성요소들의 의미론적 디스크립션들(SD)을 비교함으로써, 어떤 구성요소(들)(SC)가(이) 추출된 기본 요건(SR)을 커버할 수 있는지를 결정하기 위해, 각각의 구성요소(SC)가 등록되고 "의미론적 소프트웨어 구성요소(SSC)"로서 기술된 적어도 하나의 구성요소 저장소(SM)에 액세스하는 단계, 및

- 애플리케이션(AP)을 구축하기 위해서, 명세서의 전체 구조에 따라 이들 결정된 소프트웨어 구성요소들(SC)을 최종적으로 어셈블링하는 단계로 구성된다.

본 발명은 단지 예들로서 위에 기술된 방법 및 디바이스의 실시예들로 제한되지 않으며, 이하 청구항들의 범위 내에서 당업자에 의해 생각될 수 있는 모든 대안적 실시예들을 포괄한다.

Claims

명세서들(AS) 및 소프트웨어 구성요소들(SC)로부터 애플리케이션들(AP)을 구축하기 위한 방법에 있어서,
구축될 애플리케이션(AP)을 기술하는 명세서(AS)를 수신할 때마다, i) 기본 요건들(SR), 및 상기 기본 요건들(SR) 사이의 링크들을 추출하기 위해서, 상기 명세서(AS)의 텍스트의 의미론적 분석을 실행하는 것으로서, 상기 링크들은 "명세서의 전체 구조"를 규정하는, 상기 명세서(AS)의 텍스트의 의미론적 분석을 실행하고, 각각의 기본 요건(SR)에 대해서, 상기 기본 요건(SR)이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건(SR)에 대해서, 상기 추출된 관련 어구들에 기초하며 "상기 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 구축하는 단계, ii) 각각의 추출된 기본 요건(AS)에 대해서, 상기 기본 요건(SR)의 의미론 및 구성요소들의 의미론적 디스크립션들(SD)를 비교함으로써, 어떤 구성요소(들)(SC)가(이) 상기 추출된 기본 요건(SR)을 커버(cover)할 수 있는지를 결정하기 위해, 의미론적 소프트웨어 구성요소들(SSC)을 저장하는 적어도 하나의 구성요소 저장소에 액세스하는 단계로서, 각각은 상기 소프트웨어 구성요소(SC)가 실행할 수 있는 각각의 공용 연산을 규정하기 위한 적어도 하나의 관련 어구를 포함하는 의미론적 디스크립션(SD)에 연관된 소프트웨어 구성요소(SC)로 구성되는, 상기 적어도 하나의 구성요소 저장소에 액세스하는 단계, 및 iii) 상기 애플리케이션을 구축하기 위해서, 상기 명세서의 전체 구조에 따라 상기 결정된 소프트웨어 구성요소들(SC)을 어셈블링하는 단계로 구성되는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
제 1 항에 있어서,
상기 소프트웨어 구성요소들(SC)의 의미론적 디스크립션들(SD)의 적어도 일부는 i) 상기 소프트웨어 구성요소(SC)가 실행할 수 있는 연산의 목적, ii) 상기 연산의 목적 및 상기 연산의 입력(들)/출력 파라미터들을 기술하는 어구들이 규정되는 도메인(domain)을 나타내는 적어도 하나의 도메인 식별자, 및 iii) 상기 입력(들)/출력 파라미터들에 연관된 관련 어구들 및/또는 특정의 메타-데이터(meta-data)를 포함하는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
제 1 항 또는 제 2 항에 있어서,
상기 추출된 기본 요건들(SR)의 각각에 대해서, 상기 추출된 기본 요건의 의미론적 디스크립션(SD)과 상기 저장된 소프트웨어 구성요소들(SC) 각각의 의미론적 디스크립션(SD) 사이의 의미론적 거리를 결정하고, 최소 의미론적 거리에 대응하는 저장된 소프트웨어 구성요소(SC)을 선택하고, 상기 선택된 소프트웨어 구성요소(SC)는 상기 기본 요건(SR)을 구현하는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
제 2 항 및 제 3 항의 조합에 있어서,
"syn-업렛(syn-uplet)"이라고 하는 단어들의 주 n-업렛을 기본 요건(SR)의 각각의 관련 어구에 연관시키고, 상기 syn-업렛은 "req-업렛"이라 하고, syn-업렛을 각 소프트웨어 구성요소(SC)의 각각의 공용 연산의 목적의 각각의 관련 어구에 연관시키고, 상기 syn-업렛은 "comp-업렛"이라 하고, 각각의 기본 요건(SR)과 각각의 저장된 소프트웨어 구성요소(SC) 사이의 의미론적 거리를 결정하기 위해서 상기 req-업렛들을 상기 comp-업렛들 각각과 비교하는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
제 4 항에 있어서,
i) 각각의 req-업렛 및 각각의 comp-업렛에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정하고; ii) 각각의 기본 요건(SR)에 대해서, "sem-업렛"이라고 하고 상기 req-업렛들 각각과 상기 comp-업렛들 각각의 com-업렛들 사이의 의미론적 근접들을 나타내는 2차 n-업렛을 구축하고, 각각의 2차 n-업렛은 의미론적 거리를 규정하고, 상기 최소 의미론적 거리를 규정하는 2차 n-업렛에 대응하는 상기 저장된 소프트웨어 구성요소(SC)을 선택하는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
제 3 항 내지 제 5 항 중 어느 한 항에 있어서,
상기 애플리케이션(AP)의 구조를 최적화하기 위해서, 상기 추출된 기본 요건들(SR)에 대응하는 상기 선택된 저장된 소프트웨어 구성요소들(SC) 사이에 상기 명세서(AS)의 전체 구조를 규정하는 것들과 동일한 관련 링크들을 확립하는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
제 4 항 내지 제 6 항 중 어느 한 항에 있어서,
상기 명세서의 전체 구조를 결정하기 위해서, i) 각 쌍의 기본 요건들(SR)의 req-업렛들에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정하고, ii) 각각의 기본 요건(SR)에 대해서, "sem-업렛"이라 하는, 상기 기본 요건들(SR)의 req-업렛과 다른 기본 요건들(SR)의 req-업렛들 사이의 의미론적 근접들을 포함하는 2차 n-업렛을 구축하고, 각각의 sem-업렛은 의미론적 거리를 규정하고, 2개의 구별되는 기본 요건들(SR)의 sem-업렛의 값이 최대일 때 상기 2개의 구별되는 기본 요건들(SR) 사이에 관련 링크를 확립하는 것을 특징으로 하는, 애플리케이션(AP) 구축 방법.
명세서들(AS) 및 소프트웨어 구성요소들(SC)로부터 애플리케이션들(AP)을 구축하기 위한 디바이스에 있어서,
i) 의미론적 소프트웨어 구성요소들(SSC)을 저장하기 위한 저장 수단(SM)으로서, 상기 의미론적 소프트웨어 구성 요소들(SSC) 각각은 소프트웨어 구성요소(SC)가 실행할 수 있는 각각의 공용 연산을 규정하기 위한 적어도 하나의 관련 어구를 포함하는 의미론적 디스크립션(SD)에 연관된 상기 소프트웨어 구성요소(SC)로 구성되는, 상기 저장 수단(SM), ii) 구축될 애플리케이션(AP)을 기술하는 명세서(AS)가 수신될 때마다, 상기 명세서(AS)의 텍스트로부터 기본 요건들(SR), 및 상기 기본 요건들(SR) 사이의 링크들을 추출하기 위해서, 상기 명세서(AS)의 의미론적 분석을 실행하는 것으로서, 상기 링크들은 "명세서의 전체 구조"를 규정하는, 상기 명세서(AS)의 의미론적 분석을 실행하고, 각각의 기본 요건(SR)에 대해서, 상기 기본 요건(SR)이 포함하는 관련 어구들을 추출하고, 각각의 기본 요건(SR)에 대해서, 상기 추출된 관련 어구들에 기초하고 "상기 기본 요건의 의미론"을 나타내는 "의미론적 디스크립션"을 구축하고, 각각의 추출된 기본 요건(AS)에 대해서, 상기 기본 요건(SR)의 의미론 및 구성요소들의 의미론적 디스크립션들(SD)를 비교함으로써, 어떤 구성요소(들)(SC)가(이) 상기 추출된 기본 요건(SR)을 커버할 수 있는지를 결정하기 위해, 상기 저장 수단(SM)에 액세스하기 위해 구성된 분석 수단(AM), 및 iii) 상기 애플리케이션(AP)을 구축하기 위해서, 상기 명세서의 전체 구조에 따라 상기 결정된 소프트웨어 구성요소들(SC)을 어셈블링하기 위한 처리 수단(PM)을 포함하는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.
제 8 항에 있어서,
상기 소프트웨어 구성요소들(SC)의 의미론적 디스크립션들(SD)의 적어도 일부는 i) 상기 소프트웨어 구성요소(SC)가 실행할 수 있는 연산의 목적, ii) 상기 연산의 목적 및 상기 연산의 입력(들)/출력 파라미터들을 기술하는 어구들이 규정되는 도메인을 나타내는 적어도 하나의 도메인 식별자, 및 iii) 상기 입력(들)/출력 파라미터들에 연관된 관련 어구들 및/또는 특정의 메타-데이터를 포함하는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.
제 8 항 또는 제 9 항에 있어서,
상기 분석 수단(AM)은 각각의 추출된 기본 요건들(SR)에 대해서, 상기 추출된 기본 요건들(SR)의 의미론적 디스크립션과 상기 저장된 소프트웨어 구성요소들(SC) 각각의 의미론적 디스크립션(SD) 사이의 의미론적 거리를 결정하고, 최소 의미론적 거리에 대응하는 저장된 소프트웨어 구성요소를 선택하기 위해 구성되고, 상기 선택된 소프트웨어 구성요소(SC)는 상기 기본 요건을 구현하는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.
제 9 항 또는 제 10 항의 조합에 있어서,
상기 분석 수단(AM)은 "syn-업렛"이라고 하는 단어들의 주 n-업렛을 기본 요건(SR)의 각각의 관련 어구에 연관시키고, 상기 syn-업렛은 "req-업렛"이라 하고, 각각의 기본 요건(SR)과 각각의 저장된 소프트웨어 구성요소(SC) 사이의 의미론적 거리를 결정하기 위해서, 각 소프트웨어 구성요소(SC)의 각각의 공용 연산의 목적의 각각의 관련 어구에 연관된 syn-업렛들인, 상기 req-업렛들 각각을 comp-업렛들에 비교하기 위해 구성되는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.
제 11 항에 있어서,
상기 분석 수단(AM)은 i) 각각의 req-업렛 및 각각의 comp-업렛에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정하고; ii) 각각의 기본 요건(SR)에 대해서, "sem-업렛"이라고 하고 상기 req-업렛들 각각과 상기 comp-업렛들 각각의 com-업렛들 사이의 의미론적 근접들을 나타내는 2차 n-업렛을 구축하고, 각각의 2차 n-업렛은 의미론적 거리를 규정하고, 상기 최소 의미론적 거리를 규정하는 2차 n-업렛에 대응하는 상기 저장된 소프트웨어 구성요소(SC)을 선택하기 위해 구성되는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.
제 10 항 내지 제 12 항 중 어느 한 항에 있어서,
상기 처리 수단(PM)은 상기 애플리케이션(AP)의 구조를 최적화하기 위해서, 상기 추출된 기본 요건들(SR)에 대응하는 상기 선택된 저장된 소프트웨어 구성요소들(SC) 사이에 상기 명세서(AS)의 전체 구조를 규정하는 것들과 동일한 관련 링크들을 확립하는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.
제 11 항 내지 제 13 항 중 어느 한 항에 있어서,
상기 전체 구조를 결정하기 위해서 상기 분석 수단(AM)은 i) 각 쌍의 기본 요건들(SR)의 상기 req-업렛들에 공통인 단어들의 수를 나타내는 의미론적 근접을 결정하고, ii) 상기 기본 요건들(SR)의 req-업렛과 다른 기본 요건들(SR)의 req-업렛들 사이의 의미론적 근접들을 포함하는, 2차 n-업렛을 구축하고, 각각의 2차 n-업렛은 의미론적 거리를 규정하고, 2개의 구별되는 기본 요건들의 sem-업렛의 값이 최대일 때 상기 2개의 구별되는 기본 요건들 사이에 관련 링크를 확립하기 위해 구성되는 것을 특징으로 하는, 애플리케이션(AP) 구축 디바이스.