KR101224813B1

KR101224813B1 - 관계 모델링

Info

Publication number: KR101224813B1
Application number: KR1020060004396A
Authority: KR
Inventors: 벤자민 알바하리; 헨리쿠스 요하네스 마리아 마이제르; 마이클 이. 딤
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-02-18
Filing date: 2006-01-16
Publication date: 2013-01-21
Also published as: RU2421784C2; JP5592591B2; KR20060093018A; CA2533073C; JP2006228200A; BRPI0600051A; RU2006101269A; EP1693751A3; US7962497B2; US20060190927A1; CN1821957A; EP1693751A2; AU2005246946A1; AU2005246946B2; CN1821957B; CA2533073A1

Abstract

본 발명은 항목들 간의 관계에 관한 것이다. 항목들 간의 관계는 항목 자체의 외부에서 정의되어, 모듈적이고, 유연한 확장 가능 시스템을 제공할 수 있다. 예를 들어, 항목들 간의 관계는 지정된 관계에 따라 특정 요소 또는 값을 반환하기 위한 메소드를 포함하는 클래스에서 정의될 수 있다. 더욱이, 컴파일러 또는 유사 시스템이 간단한 특성 포맷의 관계 표현식을 수신하고 이러한 호출을 특정 메소드로 전달하도록 확장될 수 있다.

관계 모델링, 항목, 클래스, 메소드, 컴포넌트

Description

관계 모델링{RELATIONSHIP MODELING}

도 1은 관계 시스템의 블록도.

도 2는 예시적인 관계 시스템의 블록도.

도 3은 영향 컴포넌트를 포함하는 관계 시스템의 블록도.

도 4는 컴파일 시스템의 블록도.

도 5는 데이터와의 상호작용을 용이하게 하기 위한 인터페이스 시스템의 블록도.

도 6은 통합 개발 시스템 또는 환경의 블록도.

도 7은 관계를 정의하는 방법의 흐름도.

도 8은 컴파일 방법론의 흐름도.

도 9는 데이터 상호작용 방법론의 흐름도.

도 10은 프로그램 개발을 지원하는 방법의 흐름도.

도 11은 예시적인 컴파일 환경의 블록도.

도 12는 적절한 동작 환경을 나타내는 블록도.

도 13은 샘플 컴퓨팅 환경의 블록도.

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

110: 항목 수신기 컴포넌트

120: 관계 생성 컴포넌트

210: 관계

220: 항목 A

230: 항목 B

310: 영향 컴포넌트

410: 표현식 수신기 컴포넌트

420: 코드 생성 컴포넌트

430: 메타데이터 컴포넌트

510: 네비게이션 인터페이스 컴포넌트

520: 데이터 인터페이스 컴포넌트

610: 편집기 컴포넌트

620: 프로그램 지원 컴포넌트

<관련 출원에 대한 상호 참조>

본 출원은 2005년 2월 18일자로 "객체 지향 관계 모델링"이라는 명칭으로 출원된 미국 가출원 번호 60/654,237의 이익을 청구한다. 이 가출원 전체는 본 명세서에 참조로 반영되어 있다.

프로그래밍 언어는 태스크를 실행하도록 컴퓨터 또는 마이크로프로세서에 명령을 전달하기 위해 특정적으로 사용되는 형식 언어이다. 여러 해 동안, 객체 지향 프로그래밍은 디자이너 및 프로그래머가 컴퓨터 시스템 내에서 기능을 구현하기 위해 사용하는 많은 친숙하고 대중적인 모델 중 하나가 되었다. 객체 지향 프로그래밍은 적어도 다른 모델과 같이 동작이 아니라 객체 또는 사물의 관점에서 프로그래밍을 보는 것을 전제로 한다는 점에서 특이하다.

객체 기술의 이익은 3 가지 기본 원리, 즉 캡슐화, 다형성 및 상속성으로부터 발생한다. 객체는 그의 데이터 및 관련 메소드의 내부 구조를 감추거나 캡슐화한다. 객체는 구현 상세를 노출하는 대신에, 외부 정보 없이도 그의 추상 개념을 명백하게 표현하는 인터페이스를 제공한다. 다형성은 캡슐화를 한 단계 더 취한다. 다형성은 상이한 데이터 타입들에 대해 동일 코드의 사용을 허용하는데, 이 아이디어는 다양한 형태, 하나의 인터페이스이다. 따라서, 하나의 소프트웨어 컴포넌트는 다른 컴포넌트가 정확히 어떤 것인지를 모르고도 다른 컴포넌트에게 요구할 수 있다. 요구를 받는 컴포넌트는 요구를 해석하고, 그 요구의 변수 및 데이터에 따라 요구를 어떻게 실행할지를 이해한다. 세 번째 원리는 개발자가 기존의 디자인 및 코드를 재사용하는 것을 가능하게 하는 상속성이다. 이러한 능력은 개발자가 스크래치로부터 모든 소프트웨어를 생성하는 것을 피할 수 있게 한다. 오히려, 개발자는 상속을 통해 다른 클래스의 상태 및 거동 양자를 상속하고 수정하는 서브 클래스를 도출할 수 있다.

객체 지향 프로그래밍 모델은 종종 클래스 기반 어프로치를 통해 정의된다. 이러한 시스템에서, 객체는 상태 및 거동 양자를 포함하는 엔티티이다. 객체의 상태 및 거동 양자는 특정 타입의 객체를 식별하는 클래스에 의해 정의된다. 클래스 정의에 기초하여 생성된 객체는 동적 타입으로 반영된 그 클래스의 인스턴스로서 간주된다. 따라서, 객체가 포함할 수 있는 데이터(즉, 상태)는 물론, 객체가 수행할 수 있는 메소드, 함수 또는 거동을 지정한다. 메소드는 관련 객체 내에 포함된 데이터를 변경함으로써 관련 객체의 내부 상태를 수정한다. 객체에서 이러한 데이터 및 메소드의 조합은 종종 객체 지향 프로그래밍에서 캡슐화로서 지칭된다. 캡슐화는 객체의 상태가 객체와 관련된 잘 정의된 메소드에 의해서만 변경되도록 한다. 객체의 거동이 이러한 잘 정의된 위치 및 인터페이스로 한정될 때, 객체에서의 변경(예를 들어, 코드 수정)은 시스템 내의 다른 객체 및 요소에 최소의 영향을 미치게 될 것이다.

아래의 설명은 특허 청구된 내용의 여러 양태에 대한 기본적인 이해를 제공하기 위한 개요를 제공한다. 이러한 개요는 포괄적인 개요는 아니다. 키/임계 요소를 식별하거나 특허 청구된 내용의 범위를 기술하려는 목적이 아니다. 그 유일한 목적은 후술하는 상세한 설명에 대한 서론으로서 간단한 형태의 몇 가지 개념을 제공하고자 하는 것이다.

요컨대, 본 발명은 항목들 및/또는 그들의 요소들 간의 관계의 표현식에 관한 것이다. 구체적으로, 관계는 첫 번째 클래스 개념으로서 취급된다. 본 발명의 일 양태에 따르면, 관계는 관계를 연산 및/또는 네비게이트하는 메카니즘 또는 메 소드를 제공하는 클래스와 같은, 항목 외부의 구조체에 의해 표현될 수 있다. 본 발명의 다른 양태에 따르면, 관계 메소드는 데이터 타입 특성 표기법을 이용하여 호출될 수 있다.

본 발명의 양태들은 적어도 항목들 사이의 관계와의 상호작용을 위한 확장 가능하고 사용하기 쉬운 시스템 및 방법을 제공한다는 점에서 유익하다. 관계들을 제1 클래스 프로그래밍 객체로 간주함으로써 기존 항목들을 수정하지 않고도 기존 항목들 사이에 새로운 관계가 생성될 수 있다. 이것은 적어도 프로그래머의 관리하에 있지 않을 수 있는 일부 또는 전체 항목 또는 요소 사이의 관계의 정의를 허용한다는 점에서, 또는 새로운 관계를 반영하도록 요소들을 수정하는 것이 비현실적인 경우에 가치가 있다. 더욱이, 클래스 메소드의 호출은 특성 표현식을 통해 쉽게 이루어질 수 있으며, 실제 메소드 표기법으로 맵핑될 수 있다.

전술한 관련 목적을 달성하기 위해, 특허 청구된 내용의 소정의 예시적인 양태들이 아래의 설명 및 첨부 도면과 관련하여 본 명세서에 기술된다. 이러한 양태들은 본 내용이 실시될 수 있는 다양한 방법을 나타내는데, 이들 모두는 특허 청구된 내용의 범위 내에 있는 것으로 의도된다. 다른 이점 및 신규한 특징은 도면과 관련하여 고려될 때 아래의 상세한 설명으로부터 명백해질 것이다.

이제, 본 발명의 다양한 양태가 첨부 도면들을 참조하여 설명되는데, 이 도면들에서 동일 번호는 동일 또는 대응 요소를 나타낸다. 그러나, 도면 및 그에 관한 상세한 설명은 특허 청구된 내용을 개시된 특정 형태로 한정하려는 의도는 아니 라는 것을 이해해야 한다. 오히려, 청구된 내용의 사상 및 범위 내에 모든 수정, 균등물 및 대체물을 포함하는 것으로 의도한다.

본 명세서에서 사용되는 용어들인 "컴포넌트", "시스템" 등은 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어 또는 실행중인 소프트웨어인 컴퓨터 관련 엔티티를 지칭하고자 한다. 예를 들어, 컴포넌트는 프로세서에서 실행되는 프로세스, 프로세서, 객체, 인스턴스, 실행 가능물, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있으나 이에 한하지 않는다. 예를 들어, 컴퓨터에서 실행되는 애플리케이션 및 컴퓨터 양자는 컴포넌트일 수 있다. 하나 이상의 컴포넌트가 프로세스 및/또는 실행 스레드 내에 상주할 수 있으며, 하나의 컴포넌트가 하나의 컴퓨터에 국한되거나, 둘 이상의 컴퓨터 사이에 분산될 수 있다.

본 명세서에서 "예시적인"이라는 낱말은 보기, 사례 또는 실례를 의미하기 위해 사용된다. 본 명세서에 "예시적인" 것으로 설명되는 임의의 양태 또는 디자인은 다른 양태 또는 디자인 이상으로 선호되거나 이로운 것으로 해석할 필요는 없다. 또한, 다양한 예시적인 코드 조각들이 본 명세서에서 제공된다. 이러한 예들은 명료성과 이해의 목적으로 제공되는 것이지, 개시된 내용을 청구된 내용의 다양한 양태의 설명에서 사용되는 언어, 아키텍쳐 및/또는 특징으로 한정하는 것을 의미하지 않는다는 것을 이해해야 한다.

인공 지능 기반 시스템(예를 들어, 명시적 및/또는 암시적으로 훈련된 분류자, 지식 기반 시스템 등)은 후술하는 바와 같이 본 발명의 하나 이상의 양태에 따라 추론 및/또는 개연성 결정 및/또는 통계 기반 결정을 수행하는 것과 관련하여 이용될 수 있다. 본 명세서에서 사용되는 용어 "추론"은 일반적으로 이벤트 및/또는 데이터를 통해 캡쳐된 일련의 관측치로부터 시스템, 환경 및/또는 사용자의 상태를 판단 또는 추론하는 프로세스를 말한다. 추론은 특정 컨텍스트 또는 동작을 식별하는 데 이용되거나, 예를 들어 상태들 상의 확률 분포를 생성할 수 있다. 추론은 개연성, 즉 데이터 및 이벤트의 고려에 기초한 해당 상태들 상의 확률 분포의 연산일 수 있다. 또한, 추론은 일련의 이벤트 및/또는 데이터로부터 더 높은 레벨의 이벤트를 구성하기 위해 사용되는 기법을 지칭할 수도 있다. 이러한 추론은 이벤트들이 시간적으로 근접하여 상관되어 있는지의 여부, 및 이벤트들 및 데이터가 하나 또는 여러 이벤트 및 데이터 소스로부터 생성된 것인지의 여부에 관계없이 일련의 관측된 이벤트들 및/또는 이벤트 데이터로부터 새로운 이벤트 또는 동작이 구축되는 결과를 산출한다. 다양한 분류 스킴 및/또는 시스템(예를 들어, 지원 벡터 머신, 신경망, 전문가 시스템, 베이시안 신뢰망, 퍼지 이론, 데이터 퓨전 엔진 등)이 본 발명과 관련하여 자동 및/또는 추론 동작을 수행하는 것과 관련하여 이용될 수 있다.

또한, 개시되는 내용은 시스템, 메소드, 장치, 또는 표준 프로그래밍 및/또는 엔지니어링 기법을 이용하여 본 명세서에서 상술하는 양태들을 구현하기 위한 컴퓨터 또는 프로세서 기반 장치를 제어하기 위한 소프트웨어, 펌웨어, 하드웨어 또는 이들의 임의 조합을 생성하는 제조물로서 구현될 수 있다. 본 명세서에서 사용되는 "제조물"(또는 대안으로 "컴퓨터 프로그램 제품")이라는 용어는 임의의 컴퓨터 판독 가능 장치, 캐리어 또는 매체로부터 액세스 가능한 컴퓨터 프로그램을 포함하는 것으로 의도된다. 예를 들어, 컴퓨터 판독 가능 매체는 자기 기억 장치(예를 들어, 하드 디스크, 플로피 디스크, 자기 띠 등), 광 디스크(예를 들어, CD, DVD 등), 스마트 카드, 및 플래시 메모리 장치(예를 들어, 카드, 스틱, 점프 드라이브 등)를 포함할 수 있으나 이에 한하지 않는다. 또한, 캐리어 웨이브는 전자 메일을 송수신하거나 인터넷 또는 LAN과 같은 망에 액세스하는 데 사용되는 것들과 같은 컴퓨터 판독 가능 전자 데이터를 전달하는 데 사용될 수 있다. 물론, 청구 내용의 범위 또는 사상을 벗어나지 않고도 이러한 구성에 대한 다양한 변경이 이루어질 수 있음을 당업자들은 이해할 것이다.

먼저, 도 1을 참조하면, 본 발명의 일 양태에 따른 관계 시스템(100)이 도시되어 있다. 관계 시스템(100)은 항목 수신기 컴포넌트(110) 및 관계 생성 컴포넌트(120)를 포함할 수 있다. 항목 수신기 컴포넌트(110)는 항목 및/또는 그의 요소를 수신, 검색 또는 취득한다. 이들 항목은 데이터 타입, 객체, 웹 페이지 및 XML 문서를 포함할 수 있으나, 이에 한하지 않는다. 관계 생성 컴포넌트(120)는 항목 수신기 컴포넌트(110)로부터 다수의 항목을 수신, 검색 또는 취득한다. 관계 생성 컴포넌트(120)는 항목들을 분석하고, 항목들 간의 관계를 지정 및/또는 정의한다. 예를 들어, 관계는 클래스, 보다 구체적으로는 정적 클래스와 같은 프로그램 구조체에서 정의될 수 있다. 클래스는 특정 관계에 따라 다양한 항목 세트 또는 그 요소를 검색하기 위한 기능을 캡슐화하는 클래스 외부의 메소드 또는 메소드에 대한 참조를 포함할 수 있다.

관계 생성 시스템(100)은 두 가지 이상의 방법에서 이롭다는 점에 유의해야 한다. 예를 들어, 시스템(100)은 개발에 있어서의 모듈러성은 물론, 항목 및 관계 또는 이들 사이의 링크와 같은 개념들의 분리를 지원한다. 더욱이, 항목 및 관계의 분리는 항목들이 변경을 위해 항상 이용 가능하지 않을 수 있거나 이들을 수정하는 것이 실질적이지 않을 때 유연성 및 확장성을 제공한다. 예를 들어, 수십 년 전에 소정의 레거시 포맷으로 정의된 사람들 및 각 사람에 대한 데이터 또는 특성의 집합이 존재하는 상황을 고려하자. 이어서, 이 집합에 각 사람에 대한 이동 전화 번호를 추가하여 수정하는 것은 가능하지 않거나 적절하지 않을 수 있다. 이제, 사람들의 집합과 개별 셀 전화 집합을 연관시키기 위한 개별 관계 구조체가 생성될 수 있다.

도 2는 예시적인 관계 상호작용 시스템(200)을 나타낸다. 시스템(200)은 본 발명의 양태들의 설명 및 논의를 용이하게 하기 위해 제공된다. 시스템(200)은 하나 이상의 관계 메소드(210) 및 2개의 항목 A(220) 및 B(230)를 포함한다. 도시된 바와 같이, 항목 A(220) 및 항목 B(230)의 관계는 항목들의 특성 내에 또는 특성으로서 정의되지 않는다. 오히려, 관계는 항목들의 외부에 제1 클래스 개념으로서 정의된다. 관계 메소드(210)는 항목들 및 항목 요소들과 상호작용하도록 연산을 캡슐화한다.

제한적이지 않은 예로서, 객체 대 관계 맵핑 시나리오를 고려하자. 구체적으로, 이 상황은 객체와의 데이터베이스 관계에 대해 프로그래밍하는 것이 바람직한 상황이다. 타입 T의 객체를 개념적으로 포함하는 데이터베이스 테이블은 프로그래밍 언어에서 C#에서의 IEnumerable<T>와 같은 집합 타입으로 표현될 수 있는 데, 여기서 T는 테이블의 필드로 맵핑되는 특성을 가진 클래스이다. 이어서, 데이터베이스 관계는 프로그래밍 언어에서 정적 클래스로 표현될 수 있다. 이 클래스는 연결 조건을 캡슐화함으로써 이들 관계를 네비게이트하는 정적 메소드를 제공한다. 예를 들어, 항목 A(220)는 고객 테이블에 대응하는 객체, 타입 또는 클래스일 수 있고, 항목 B(230)는 순서 테이블에 대응하는 객체, 타입 또는 클래스일 수 있다. 예를 들어,

public class Customer {...}

public class Order {...}

관계(210)는 정적 클래스와 같은 프로그램 구조체에서 다음과 같이 항목 A(220) 및 B(230)와 별개로 정의될 수 있다.

public static class OrderRelationship {

public static Customer GetCustomerGivenOrder(Order order);

public static IEnumerable<Order> GetOrdersGivenCustomer (Customer, customer);

public static IEnumerable<Customer> GetCustomersGivenOrders (IEnumerable<Order> orders);

public static IEnumerable<Order> GetOrdersGivenCustomers (IEnumerable<Customer> customers);

}

여기서, 클래스 메소드는 고객과 순서 사이에 존재할 수 있는 다수의 관계에 따라 데이터 저장소를 네비게이트하는 메카니즘을 제공한다. 여기서, 바이너리 관계는 클래스 및 클래스 메소드에 의해 캡슐화된다. 바이너리 관계는 일대일, 일대다, 다대일 및 다대다 관계를 포함할 수 있다. 제1 메소드 "GetCustomerGivenOrder"는 고객이 특정 순서가 주어진 때 검색되는 일대일 관계를 캡쳐한다. 제2 메소드 "GetOrdersGivenCustomer"는 다대일 관계이다. 여기서, 특정 고객과 연관된 다수의 순서가 검색된다. 제3 메소드 및 제4 메소드 "GetCustomerGivenOrders" 및 "GetOrdersGivenCustomers"는 다대다 관계이다. 구체적으로, 제3 메소드는 지정된 순서들과 연관된 고객들의 집합을 검색한다. 한 세트의 순서들이 주어질 때, 제4 메소드는 관계 고객들을 검색할 수 있다.

전술하였고 후술하는 예들은 첨부된 청구범위의 범위를 제한할 의도는 없다. 본 발명의 양태들은 항목들 사이의 관계 또는 네비게이션이 존재하는 어떠한 상황에도 적용할 수 있다. 예를 들어, 링크된 문서들의 시나리오를 고려하자. 항목 A(220) 및 항목 B(230)는, 항목 A(220)에서 항목 B(230)로의 하이퍼링크와 같은 링크를 포함하는 것이 아니라 하이퍼텍스트 및 XML을 포함하지만 이에 한하지 않는 다양한 포맷 중 어느 하나의 포맷을 가진 전자 문서일 수 있다. 문서들 사이의 관 계는 그 외부에 정의될 수 있다. 이것은 문서들 중 하나의 수정을 필요로 하지 않고 관계들이 정의될 수 있게 한다.

구성 및 결합을 포함하지만 이에 한하지 않는, 바이너리 및 링크 외의 다른 관계들도 고려되며, 첨부된 청구범위의 범위 내에 있다. 하나의 항목이 다른 항목 내에 중첩되어 있는 경우, 이 항목은 다른 항목과 구성 관계를 갖는다. 따라서, 하나의 항목 또는 엔티티는 임의의 다른 항목 또는 엔티티를 구성할 수 있다. 다음 테이블은 메시지 참여 구성 관계를 나타낸다.

Id	주제	참가자
1	Hey!	ID	이메일 어드레스
		1	Jili
		2	Michael
2	Yay!	ID	이메일 어드레스
		3	Jili
		4	Ben

결합에 따라, 참조, 공통 값, 조건 및 엔티티를 포함하는 여러 상이한 타입이 존재한다. 참조 결합은 주요-키 외부-키 관계에 대응할 수 있다. 다음 예는 고객-순서 참조 결합 관계를 나타내는데, 테이블 2는 고객에 대응하고, 테이블 3은 순서에 대응한다.

Id	이름
1	Fred
2	Wilma

Id	고객	...
1	(1)	...
2	(2)	...
3	(1)	...

공통 값 결합은 2개 이상 항목에서 공통값이 공유되는 관계이다. 예를 들어, 다음 테이블은 개인(테이블 4)과 악기(테이블 5) 사이의 음악가 공통 값 결합을 나타낸다.

Id	이름	악기
1	Fred	피아노
2	John	기타
3	Wilma	피아노

Id	이름
1	기타
2	플룻
3	피아노

조건 결합은 질의 기준에 의해 표현되는 관계이다. 다음 예는 콘텍 문서 조건 결합을 제공한다.

Id	이메일 어드레스
1	요소 0:benja@xyz.com 요소 1:mbtyalor@xyz.com
2	요소 0:jili@xyz.com

Id	저자
1	mbtyalor@xyz.com
2	jili@xyz.com
3	benja@xyz.com

엔티티 결합은 다른 타입의 관계를 통해 다른 엔티티에 대한 허브로서 동작하는 항목 또는 엔티티 주위의 n 엔드 포인트를 갖는다. 링크 관계는 단순히, 하나의 허브와 2개의 참조 기반 엔드 포인트를 갖는 엔티티 결합의 특수 예일 수 있다. 아래의 예시적인 테이블은 고용 엔티티 결합을 나타내는데, 테이블 8은 고용에 대응하고, 테이블 9는 개인에 대응하며, 테이블 10은 고용자에 대응한다.

Id	고용일	피고용자 Id	고용자 Id
1	01/01/01	2	1
2	01/01/02	2	2
3	01/01/03	1	2

Id	이름
1	Fred
2	Wilma
3	Barney

Id	이름
1	Zoo
2	Boo

도 3은 본 발명의 일 양태에 따른 관계 시스템(300)을 나타낸다. 도 1의 시스템(100)과 마찬가지로, 시스템(300)은 항목 수신기 컴포넌트(110) 및 관계 생성 컴포넌트(120)를 포함한다. 전술한 바와 같이, 수신기 컴포넌트(110)는 예를 들어 데이터 객체, 웹 페이지 또는 XML 문서와 같은 다수의 요소를 수신 및/또는 검색할 수 있다. 관계 생성 컴포넌트(120)는 수신기 컴포넌트(110)로부터 요소들을 수신 및/또는 검색할 수 있다. 관계 생성 컴포넌트(120)는 항목들 사이의 관계 또는 링크를 정의 또는 지정할 수 있다. 또한, 생성 컴포넌트(120)는 지정된 관계에 응답하여 특정 항목 또는 그 요소를 검색하기 위해 메소드 또는 참조를 제공할 수 있다. 시스템(100)과 마찬가지로, 시스템(300)은 클래스에서 관계를 정의할 수 있으며, 클래스는 관계를 계산하기 위한 메소드를 포함할 수 있다. 그러나, 시스템(300)은 영향 컴포넌트(310)를 더 포함할 수 있다. 영향 컴포넌트(310)는 관계들의 명명에 영향을 주기 위한 메카니즘이다. 본 발명의 일 양태에 따르면, 영향 컴포넌트(310)는 관련된 요소들의 이름에 기초하여 관계 이름을 추론 또는 연역하기 위하여 발견적 또는 인공 지능 컴포넌트, 메소드 또는 메카니즘을 포함하거나 이에 통신적으로 결합될 수 있다. 예를 들어, 2개의 항목 "Customer" 및 "Order"는 전술한 예에서와 같이 "GetCustomerGivenOrder"라는 이름의 관계 메소드를 가질 수 있다. 추가적으로 또는 대안으로, 영향 컴포넌트(310)는 예를 들어 외부 메타데이터 정보에 의해 구동되는 명명 스킴을 수신 및/또는 제공함으로써 관계 생성 컴포넌트(120)를 도울 수 있다.

전술한 바와 같이, 관계는 여러 관계들 중에서 바이너리 관계 또는 일반적 n가 관계(예를 들어, 허브-스포크 관계)일 수 있다. 바이너리 관계는 엔티티-관계 강연에서 사용되는 바와 같은 일대일, 일대다, 다대일 또는 다대다 관계일 수 있다. 타입 S 및 T 사이의 관계는 정적 클래스로 모델링될 수 있다. 여러 바이너리 관계를 캡쳐하는 클래스의 다음 예를 고려하자.

public static class RelationshipName_Relationship{

public static IEnumerable<T> GetTsGivenS (S,s);

public static S GetSGivenT (T t);

public static IEnumerable<S> GetSsGivenTs (IEnumerable<T> ts);

public static IEnumerable<T> GetTsGivenSs (IEnumerable<S> ss);

}

일대일 관계의 경우, GetTsGivenS 메소드는 T의 단일 인스턴스를 리턴하며, 다대다 관계의 경우, GetSGivenT 메소드는 IEnumerable와 같은 집합 타입을 리턴한다.

관계 클래스, 정적 메소드 및 독립 변수의 이름은 타입 이름에 기초한 발견론의 이용 및 외부 메타데이터 정보에 의해 구동되는 명명 스킴의 이용을 포함하지만 이에 한하지 않는 다양한 방법으로 도출될 수 있다. 전술한 바와 같이, 다음은 "Customer"와 "Order" 사이의 관계를 모델링한다.

public class Customer {…}

public class Order {…}

public static class OrderRelationship {

public static Customer GetCustomerGivenOrder(Order order);

public static IEnumerable<Order> GetOrdersGivenCustomer (Customer, customer);

public static IEnumerable<Customer> GetCustomerGivenOrders (IEnumerable<Order> orders);

}

다음과 같이 고객 테이블 내의 일련의 고객들을 나타내는 변수가 주어진다:

IEnumerable<Customer>customer=...;

아래의 정적 메소드는 다음과 같이 일련의 고객들과 연관된 일련의 순서를 검색하는 데 이용될 수 있다.

IEnumerable<Order> orders =

OrerRelationship.GetOrderGivenCustomer(customers);

정적 메소드 호출은 연결 조건을 캡슐화한다:

SELECT (fields) FROM Customer JOIN Order ON (condition)

n가 관계(본 명세서에서 엔티티 결합이라고도 한다)는 예를 들어 특정 타입의, 또는 다른 타입의 일련의 바이너리 관계이다. 그 일례는 허브 및 스포크 관계이다. 이러한 관계에 대한 디자인 패턴은 다음과 같다:

public static class RelationshipName_Relationship {

public static S1 GetSpoke1GivenHub (hub);

public static IEnumerable<Hub> GetHubsGivenSpoke1 (spoke1);

public static S2 GetSpoke2GivenHub (hub);

public static IEnumerable<Hub> GetHubsGivenSpoke2 (spoke2);

public static IEnumerable<S1> GetSpoke1GivenHub (IEnumerable<Hub> hubs);

public static IEnumerable<Hub> GetHubsGivenSpoke1 (IEnumerable<S1> spoke1s);

public static IEnumerable<S2> GetSpoke2GivenHub (IEnumerable<Hub> hubs);

public static IEnumerable<Hub> GetHubsGivenSpoke2 (IEnumerable<S2> spoke2s);

}

기술적으로, 관계의 다양한 측면에 대한 중요성들이 구별될 수 있지만, 간명화를 위해 허브와 스포크들 사이의 모든 개별 바이너리 관계는 일대다인 것으로 가정한다.

간단한 바이너리 관계의 경우와 같이, 관계 클래스 및 정적 메소드의 이름은 타입 이름에 기초한 발견론에서 외부 메타데이터 정보에 의해 구동되는 명명 스킴에 이르는 다양한 방법으로 도출될 수 있다. 아래의 예는 "Employment", "Person" 및 "Organization" 사이의 관계를 모델링한다. "Employment"와 "Person" 및 "Employment"와 "Organization" 사이에는 2개의 일대다 바이너리 관계가 존재한다. "Employment"는 허브로서 동작한다.

public class Person {..}

public class Organization {..}

public class Employment {..}

public static class EmploymentRelationship {

public static IEnumerable<Employment> GetEmploymentsGivenEmployee (Person employee);

public static Person GetEmployeeGivenEmployment (Employment employment);

public static IEnumerable<Employment> GetEmploymentsGivenEmployer (Organization employer);

public static Organization GetEmployerGivenEmployment (Employment employment);

public static IEnumerable<Employment> GetEmploymentGivenEmployee

(IEnumerable<Person> employees);

public static IEnumerable<Person> GetEmployeeGivenEmployment

(IEnumerable<Employment> employments);

public static IEnumerable<Employment> GetEmploymentGivenEmployer

(IEnumerable<Organization> employers);

public static IEnumerable<Organization> GetEmployerGivenEmployment

(IEnumerable<Employment> employments);

}

다음과 같이 개인 테이블 내의 일련의 사람들을 나타내는 변수가 주어진다:

IEnumerable<Person>people=...;

아래의 정적 메소드는 일련의 사람들과 연관된 일련의 고용을 얻는 데 이용된다:

IEnumerable <Employment> employments =

EmploymentRelationship.GetEmploymentGivenEmployee(people);

아래의 정적 메소드는 일련의 고용과 연관된 일련의 조직을 얻는 데 이용된다:

IEnumerable <Organization> employers =

EmploymentRelationship.GetEmployerGivenEmployment(employments);

후자의 정적 메소드 호출은 연결 조건을 캡슐화한다:

SELECT (fields) FROM Person JOIN Employment ON (condition) JOIN Organization ON (condition)

타입 또는 클래스 관계는 타입 특성을 가진 관계로서 모델링될 수 있다. 예를 들어, 조직이 개인을 고용하고 개인이 조직에 고용되는 타입 개인 및 타입 조직을 포함하는 시나리오를 고려하자. 이것은 C#과 같은 객체 지향 언어에서 다음과 같이 표현된다:

public class Person {

public IEnumerable<Employment>Employments {get;}

}

public class Organization{

public IEnumerable<Employment> Employments {get;}

그러나, 개별 클래스를 이용한 모델링은 특성을 이용하여 관계를 모델링하는 것 이상의 이점을 갖는다. 예를 들어, 기존 타입을 수정하지 않고도 기존 타입들 간에 새로운 관계가 생성될 수 있다. 특성을 이용하는 위의 시나리오에서, "Person" 및 "Organization" 타입은 "Employment" 타입에 대한 종속성을 갖는다. 또한, 특성을 이용한 관계 모델링은 하나의 인스턴스로부터의 네비게이션만을 가능하게 하지만, 정적 클래스로부터의 관계 모델링은 인스턴스 집합으로부터의 네비게이션을 가능하게 한다.

정적 메소드를 이용하여 관계를 제1 클래스 개념으로 표현하는 디자인 패턴은 프로그래머에게 상당한 표현력을 제공하지만, 이는 구문적으로 장황하다. 더욱이, 이들 관계는 상이해 보이며, 특성으로서 모델링된 관계보다 발견 가능성이 적다.

도 4는 본 발명의 일 양태에 따라 관계에 액세스하는 방식을 구문적으로 통합한 컴파일 시스템(400)을 나타낸다. 시스템(400)은 표현식 수신기 컴포넌트(410), 코드 생성 컴포넌트(420), 및 메타데이터 컴포넌트(430)를 포함한다. 수신기 컴포넌트(410)는 데이터 타입을 포함하지만 이에 한하지 않는 항목들 사이의 관계를 포함하는 프로그램 표현식을 수신한다. 이 프로그램 표현식은 관계가 특성인 것처럼 지정되는 간략화된 표현식일 수 있다. 예를 들어, 고객 테이블 내의 일련의 고객들을 나타내는 변수 "IEnumerable<Customer>customers=...;"가 주어질 때, 이 일련의 고객들에 관한 일련의 순서들을 얻기 위해 구문 "IEnumerable<Order>orders=customer.Orders"가 이용될 수 있다. 코드 생성 컴포넌트는 이 표현식을 수신하고, 이 표현식으로부터 "OrderRelationship.GetOrderGivenCustomers(customers)"와 같은 보다 장황한 코드 또는 메소드에 대한 호출을 생성한다. 이러한 기능은 메타데이터 컴포넌트(430)를 통해 코드 생성 컴포넌트(420)에 의해 가능하게 된다. 메타데이터 컴포넌트(430)는 클래스에 관한 메타데이터를 검색 또는 수신하고, 이를 코드 생성 컴포넌트(420)에 제공하여 간략화된 표현식으로부터 실제 또는 보다 장황한 표현식으로의 맵핑을 가능하게 할 수 있다. 이러한 메타데이터는 "OrderRelationship.GetOrderGivenCustomer(customers)"가 "customer.Order"로 맵핑되도록 지정할 수 있다. 본 발명의 일 양태에 따르면, 이러한 메타데이터는 요소들 사이의 관계를 정의하는 클래스에서 제공될 수 있다. 대안으로, 메타데이터는 컴파일 시스템 및/또는 코드 생성 컴포넌트(420)에 의해 이용되는 소정의 외부 파일 또는 스키마에 의해 제공될 수 있다.

도 5를 참조하면, 데이터 상호작용을 용이하게 하기 위한 인터페이스 시스템(500)이 도시되어 있다. 인터페이스 시스템(500)은 통신 결합된 네비게이션 인터페이스 컴포넌트(510) 및 데이터 인터페이스 컴포넌트(520)를 포함한다. 예를 들어, 데이터 인터페이스 컴포넌트(520)는 네비게이션 인터페이스 컴포넌트(510)에 의해 호출 또는 실행될 수 있는 메소드를 구현할 수 있으며, 그 반대도 마찬가지다. 네비게이션 인터페이스 컴포넌트(510)는 관계 표현식을 수신할 수 있다. 인터페이스 컴포넌트(510)는 각각 "customer.Orders" 또는 "OrderRelationship.GetOrderGivenCustomers(customers)"와 같은 간략화되거나 완전한 길이의 표현식을 수신할 수 있다. 간략화된 표현식이 제공되는 경우, 네비게이션 인터페이스 컴포넌트(510)는 표현식을 완전 길이 표현식으로 변환할 수 있다. 이어서, 이 표현식은 네비게이션 인터페이스 컴포넌트(510)로부터 데이터 인터페이스 컴포넌트(520)로 전송될 수 있다. 데이터 인터페이스 컴포넌트(520)는 하나 이상의 항목 상에서의 실행을 위해 이 표현식을 제공할 수 있다. 데이터가 검색되는 경우, 데이터 인터페이스 컴포넌트(520)는 그 결과를 네비게이션 인터페이스 컴포넌트(510)로 전송할 수 있다. 따라서, 네비게이션 인터페이스 컴포넌트(510) 및 데이터 인터페이스 컴포넌트(520)는 애플리케이션 프로그램 인터페이스(API)에 대응할 수 있다.

도 6은 본 발명의 일 양태에 따른 통합 개발 환경 또는 시스템(600)을 나타낸다. 시스템(600)은 편집기 컴포넌트(610) 및 프로그램 지원 컴포넌트(620)를 포함할 수 있다. 편집기 컴포넌트(610)는 컴퓨터 소스 코드의 편집 및/또는 개발을 위해 특수화된 텍스트 편집기이다. 구체적으로, 편집기 컴포넌트(610)는 관계들의 사양을 수신할 수 있다. 텍스트 편집기는 프로그램 지원 컴포넌트(620)에 통신 결합된다. 지원 컴포넌트(620)는 특히 힌팅, 포맷팅, 칼라화, 툴 팁 및 에러 표시 또는 경고를 포함하는 코딩 지원을 제공할 수 있다. 예를 들어, 프로그램 지원 컴포넌트(620)는 항목 및 도트와 같은 트리거의 수신에 응답하여 텍스트 편집기 컴포넌트(610)가 문장 완성을 위한 제안을 표시하도록 제공 및/또는 유발할 수 있다. 제안은 본 명세서에서 제공되는 바와 같이 관계와 관련하여 이루어질 수 있다. 예를 들어, "customer"의 수신시, "Orders"는 "customer"에 대한 모든 순서가 검색되어야 함을 나타내는 완성된 문장 "customer.Orders"에 대해 제안될 수 있다. 따라서, 항목의 특성들로 보이지만 개별 관계 방법론에 대응하는 힌트 또는 제안이 이루어질 수 있다.

전술한 시스템은 여러 컴포넌트들 간의 상호작용에 관련하여 설명되었다. 이들 시스템 및 컴포넌트는 그 내부에 지정된 컴포넌트 또는 서브 컴포넌트, 지정된 컴포넌트 또는 서브 컴포넌트의 일부, 및/또는 추가 컴포넌트를 포함할 수 있다는 것을 이해해야 한다. 서브 컴포넌트는 부모 컴포넌트 내에 포함되는 것이 아니라 다른 컴포넌트와 통신 결합되는 컴포넌트로서도 구현될 수 있다. 또한, 하나 이상의 컴포넌트 및/또는 서브 컴포넌트는 수집 기능을 제공하는 단일 컴포넌트로 조합될 수 있다. 컴포넌트는 또한 간략화를 위해 본 명세서에서는 구체적으로 설명되지 않지만 당업자에게 공지되어 있는 하나 이상의 다른 컴포넌트와 상호작용할 수 있다.

또한, 이해할 수 있듯이, 전술한 시스템들 및 후술하는 방법들의 다양한 부분들은 인공 지능 또는 지식 또는 규칙 기반 컴포넌트, 서브 컴포넌트, 프로세스, 수단, 방법론 또는 메카니즘(예를 들어, 지원 벡터 머신, 신경망, 전문가 시스템, 베이시안 신뢰망, 퍼지 이론, 데이터 퓨전 엔진, 분류기 등)을 포함하거나 이들로 구성될 수 있다. 이들 컴포넌트는 특히 수행되는 소정의 메카니즘 또는 프로세스를 자동화하여 시스템 및 방법 중 일부가 효율적이고 지능적인 것은 물론 더 적응성 있게 만들 수 있다. 제한적이지 않은 예로서, 영향 컴포넌트(310)는 이러한 방법 또는 시스템을 이용하여, 생성되는 관계의 이름을 추론하고 영향을 줄 수 있다.

전술한 예시적인 시스템을 고려할 때, 개시된 내용에 따라 구현될 수 있는 방법들은 도 7-10의 흐름도를 참조하여 보다 잘 이해될 것이다. 설명의 간략화를 위하여 방법들은 일련의 블록들로서 도시되고 설명되지만, 소정의 블록들은 본 명세서에 도시되고 설명된 것과 다른 순서로 그리고/또는 다른 블록들과 동시에 발생할 수 있으므로 청구되는 내용은 블록들의 순서에 의해 제한되지 않는다는 것을 이해해야 한다. 더욱이, 후술하는 방법들을 구현하기 위해 모든 도시된 블록들이 필요하지 않을 수 있다.

또한, 이하에 그리고 본 명세서 전반에서 개시되는 방법들은 이 방법들을 컴퓨터에 전달하고 전송하는 것을 용이하게 하기 위하여 제조물 상에 저장될 수 있다는 것도 이해해야 한다. 본 명세서에서 사용되는 제조물이라는 용어는 임의의 컴퓨터 판독 가능 장치, 캐리어 또는 매체로부터 액세스 가능한 컴퓨터 프로그램을 포함하는 것을 의도한다.

도 7을 참조하면, 관계를 정의하는 방법(700)이 도시되어 있다. 710에서, 항목들이 수신된다. 이들은 데이터 유형 및 문서(예를 들어, XML, 워드 프로세싱, HTTP 등)와 같은 프로그램 항목을 포함할 수 있지만 이에 한하지 않는다. 720에서, 다수의 항목들 사이의 관계를 정의하는 클래스와 같은 구조체가 생성된다. 예를 들어, 클래스는 객체 지향 정적 클래스일 수 있다. 또한, 클래스는 항목 또는 요소 관계의 컴퓨팅 및/또는 네비게이팅을 캡슐화하는 정적 메소드를 포함할 수 있다. 관계는 특히 바이너리 또는 n가일 수 있다. 또한, 관계 또는 메소드의 이름은 관련될 항목과 연관된 이름 또는 다른 메타데이터에 의해 영향을 받을 수 있다. 클래스는 자동으로 생성될 수 있지만, 방법(400)은 예를 들어 데이터 타입과 같은 다수의 요소를 식별하고 통합 개발 환경(IDE) 또는 유사 시스템의 도움이 있거나 없이 객체 지향 프로그래밍 언어에서 요소들 사이의 관계를 정의하는 클래스를 수동으로 지정함으로써 수동으로 실시될 수도 있다는 것을 이해해야 한다.

도 8은 본 발명의 일 양태에 따른 컴파일 방법(800)을 나타낸다. 810에서, 관계 표현식이 수신된다. 관계 표현식은 "customer.Orders"와 같은 클래스의 특성으로 표현될 수 있다. 820에서, 컴파일러 또는 다른 시스템이 표현식을 수신하여, 예를 들어 항목들 간의 관계를 지정하는 클래스에서 정의되는 메소드와 연관된 코드를 생성하거나 이 코드로 확장할 수 있다. 이러한 코드 생성을 용이하게 하기 위하여, 컴파일러는 예를 들어 관계 클래스와 연관된 메타데이터를 이용하여 표현식과 보다 장황한 메소드 호출 사이의 맵핑을 결정할 수 있다. 따라서, 컴파일러는 정적 메소드의 호출이 타입과 같은 항목 상에 직접 정의되는 특성으로서 나타나게 한다.

도 9를 참조하면, 데이터와의 상호작용을 위한 방법(900)이 도시되어 있다. 910에서, 관계 표현식이 수신된다. 관계 표현식은 2개 이상의 항목 또는 요소 및 항목들 간의 관계를 식별한다. 본 발명의 일 양태에 따르면, 표현식은 관계가 항목의 특성, 예를 들어 "customer.Orders", "order.Customer" 또는 "orders.Customers"인 것으로 나타나도록 특성 포맷으로 지정될 수 있다. 920에서, 관계 표현식과 연관된 메소드가 발견된다. 일례로, 메소드는 항목들 자체와 무관하게 정의된 개별 관계 클래스에 상주할 수 있다. 예를 들어, "customer.Orders"는 순서 관계 메소드 및 구체적으로 메소드 "GetOrdersGivenCustomer(Customercustomer)"로 맵핑되는 것으로 결정될 수 있다. 930에서, 메소드가 실행될 수 있다. 메소드는 데이터 네비게이션, 및 검색, 추가, 제거 또는 다른 데이터 상호작용 또는 조작과 같은 선택적 추가 기능을 용이하게 할 수 있다. 940에서, 결과들이 적절한 경우에 리턴될 수 있다.

도 10은 본 발명의 일 양태에 따른 프로그램 지원 방법(1000)이다. 방법(1000)은 관계의 사양을 지원할 수 있다. 1010에서, 특정 타입의 항목이 수신, 검색 또는 취득된다. 항목에 이어서, 1020에서 트리거가 수신, 검색 또는 취득된다. 트리거는 특히 스페이스(" "), 도트(".") 및 캐리지 리턴과 같은 것들에 대응할 수 있다. 1030에서, 예를 들어 정의된 관계에 기초한 힌트의 형태로 지원이 제공된다. 예를 들어, 사용자가 "customer"를 입력하면, 특히 "Orders"와 같은 완성 힌트가 제공될 수 있다. 힌트는 예를 들어 드롭다운 메뉴로 사용자에게 표시될 수 있다. 선택시 문장이 완료되고 "customer.Orders"가 판독될 수 있다. 이것은 주어진 항목과 연관된 모든 가능한 관계를 기억하거나 상기하여야 하는 부담을 줄이며, 특히 타이핑 에러를 최소화한다.

힌팅에 더하여, 관계 표현식과 연관된 고유 포맷핑 및/또는 칼라화와 같은 다른 형태의 프로그램 지원이 제공될 수 있다는 점에 유의해야 한다. 또한, 예를 들어 타입 정보가 커서의 롤오버 또는 호버시 및/또는 소정 키 조합의 누름시에 텍스트 박스 또는 버블에서 버블 업되는 툴 팁들이 제공될 수 있다. 관계 표현식에 관한 추가적인 프로그램 지원도 고려되며, 본 청구범위의 범위 내에 있다.

도 11은 구현 코드(예를 들어, 실행 가능물, 중간 언어 등)를 생성하는 데 이용될 수 있는 컴파일러 환경(1100)을 나타내는 블록도이다. 그러나, 환경(1100)의 양태들은 지능 또는 컨텍스트 민감 프로그래밍 지원이 제공되는 것을 가능하게 하기 위하여 예를 들어 코드 편집기와 연관된 백그라운드 컴파일러의 일부로서 사용될 수도 있다. 컴파일러 환경(1100)은 프론트 엔드 컴포넌트(1120), 변환기 컴포넌트(1130), 백 엔드 컴포넌트(1140), 에러 체커 컴포넌트(1150), 심볼 테이블(1160), 파스 트리(1170) 및 상태(1180)를 포함하는 컴파일러(1120)를 포함한다. 컴파일러(1120)는 소스 코드를 입력으로 수신하여 구현 코드를 출력으로서 생성한다. 입력은 본 명세서에서 설명되는 바와 같이 관계 표현식, 클래스 및/또는 다른 구조체를 포함할 수 있지만 이에 한하지 않는다. 컴파일러 환경(1100)의 컴포넌트들 및 모듈들 간의 관계는 데이터의 주요 흐름을 나타낸다. 간명화를 위해 다른 컴포넌트 및 관계는 도시되지 않는다. 구현에 따라 컴포넌트들이 추가, 삭제, 다수의 모듈로 분할, 다른 모듈 및/또는 모듈들의 다른 구성과 조합될 수 있다.

컴파일러(1120)는 일련의 요소들의 처리와 연관된 소스 코드를 가진 파일을 입력으로 수신할 수 있다. 소스 코드는 관계 표현식, 클래스, 다른 표현식, 메소드 및/또는 프로그램 구조체를 포함할 수 있다. 컴파일러(1120)는 구조체를 분석하고 코드를 생성하거나 주입하기 위해 하나 이상의 컴포넌트와 함께 소스 코드를 처리할 수 있다.

프론트 엔드 컴포넌트(1120)는 소스 코드를 판독하여 어휘 분석을 수행한다. 본질적으로, 프론트 엔드 컴포넌트(1120)는 소스 코드 내의 일련의 문자들(예를 들어 영 숫자)을 특히 상수, 식별자, 연산자 심볼, 키워드 및 구두점을 나타내는 구문 요소 또는 토큰으로 변환한다.

변환기 컴포넌트(1130)는 토큰을 중간 표현식으로 파싱한다. 예를 들어, 변환기 컴포넌트(1130)는 구문을 검사하고 토큰들을 표현식들 또는 다른 구문 구조로 그룹화할 수 있는데, 이들은 문장 트리 내로 합체된다. 개념적으로, 이들 트리는 파스 트리(1170)를 형성한다. 또한 그리고 적절한 경우, 변환기 컴포넌트(1130)는 관련 특징과 함께 소스 코드에서 사용되는 심볼 이름 및 타입 정보를 열거한 심볼 테이블(1160)에 엔트리를 배치할 수 있다.

상태(1180)는 수신 또는 검색된 소스 코드를 처리하여 파스 트리(1170)를 형성함에 있어서 컴파일러(1120)의 진행을 추적하는 데 사용될 수 있다. 예를 들어, 상이한 상태 값들은 컴파일러(1120)가 클래스 정의 또는 함수의 시작에 있거나, 클래스 멤버를 막 선언하였거나 표현을 완료하였음을 지시한다. 컴파일러가 진행할 때, 컴파일러는 상태(1180)를 계속적으로 갱신한다. 컴파일러(1120)는 상태(1180)를 외부 엔티티에 부분적으로 또는 전적으로 노출시켜, 외부 엔티티가 컴파일러(1120)에 입력을 제공하게 할 수 있다.

소스 코드 내의 구조체 또는 다른 신호에 기초하여(또는 달리 기회가 인정되는 경우), 변환기 컴포넌트(1130) 또는 다른 컴포넌트는 효율적이고 적절한 실행을 용이하게 하기 위하여 코드를 주입할 수 있다. 예를 들어, 이해를 생략으로 확장하거나 질의 이해를 시퀀스 연산자로 변환하기 위한 코드가 주입될 수 있다. 변환기 컴포넌트(1130) 또는 다른 컴포넌트로 코딩된 규칙들은 원하는 기능을 구현하고 코드가 주입되어야 하거나 다른 연산이 수행되어야 하는 위치를 식별하기 위해 행해져야 하는 것을 지시한다. 주입된 코드는 일반적으로 하나 이상의 위치에 추가되는 문장, 메타데이터 또는 다른 요소를 포함하지만, 이 용어는 또한 기존 소스 코드의 변경, 삭제 또는 수정을 포함할 수 있다. 주입된 코드는 하나 이상의 템플릿으로서, 또는 소정의 다른 형태로 저장될 수 있다. 또한, 심볼 테이블 조작 및 파스 트리 변환이 발생할 수 있다는 것을 이해해야 한다.

백 엔드 컴포넌트(1140)는 심볼 테이블(1160) 및 파스 트리(1170)에 기초하여 중간 표현식을 출력 코드로 변환할 수 있다. 백 엔드 컴포넌트(1140)는 중간 표현식을 타겟 프로세서에서 또는 그에 의해 실행 가능한 명령들로, 변수들에 대한 메모리 할당 등으로 변환할 수 있다. 출력 코드는 실제 프로세서에 의해 실행될 수 있지만, 본 발명은 가상 프로세서에 의해 실행될 수 있는 출력 코드도 고려한다.

또한, 프론트 엔드 컴포넌트(1120) 및 백 엔드 컴포넌트(1140)는 코드 최적화와 같은 추가 기능을 수행할 수 있으며, 단일 단계로서 또는 다수의 단계에서 전술한 연산을 수행할 수 있다. 컴파일러(1120)의 컴포넌트들의 다양한 다른 양태들은 통상적인 것이며 동일한 기능을 수행하는 컴포넌트들로 대체될 수 있다. 또한, 소스 코드 처리 동안의 다양한 단계에서, 에러 체커 컴포넌트(1150)가 어휘 구조에서의 에러, 구문 에러 및 심지어 시맨틱 에러와 같은 에러를 검사할 수 있다. 에러 검출시, 체커 컴포넌트(1150)는 컴파일을 중지하고 에러를 나타내는 메시지를 생성한다.

개시된 내용의 다양한 양태에 대한 컨텍스트를 제공하기 위하여, 도 12, 13 및 다음의 설명은 개시된 내용의 다양한 양태가 구현될 수 있는 적절한 환경의 간단하고 일반적인 설명을 제공하고자 한다. 그 내용은 컴퓨터 및/또는 컴퓨터들에서 실행되는 컴퓨터 프로그램의 컴퓨터 실행 가능 명령들의 일반적인 컨텍스트에서 전술하였지만, 본 발명은 다른 프로그램 모듈과 함께 구현될 수도 있다는 것을 당업자는 이해할 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하고 그리고/또는 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 더욱이, 본 발명의 방법은 단일 프로세서 또는 멀티 프로세서 컴퓨터 시스템, 미니 컴퓨팅 장치, 메인프레임 컴퓨터, 개인용 컴퓨터, 핸드헬드 컴퓨팅 장치(예를 들어, PDA, 전화, 시계 등), 마이크로프로세서 기반 또는 프로그래머블 소비자 또는 산업 전자 장치 등을 포함하는 다른 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 당업자는 이해할 것이다. 도시된 양태들은 통신망을 통해 링크된 원격 처리 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 그러나, 본 발명의 모든 양태는 아니지만 그 일부는 독립식 컴퓨터 상에서 실시될 수 있다. 분산 컴퓨팅 환경에서 프로그램 모듈들은 로컬 및 원격 메모리 저장 장치 양자에 위치할 수 있다.

도 12를 참조하면, 개시된 다양한 양태를 구현하기 위한 예시적인 환경(1210)은 컴퓨터(1212)(예를 들어, 데스크탑, 랩탑, 서버, 핸드헬드, 프로그래머블 소비자 또는 산업 전자장치 등)를 포함한다. 컴퓨터(1212)는 처리 유닛(1214), 시스템 메모리(1216), 및 시스템 버스(1218)를 포함한다. 시스템 버스(1218)는 시스템 메모리(1216)를 포함하지만 이에 한하지 않는 시스템 컴포넌트를 처리 유닛(1214)에 결합시킨다. 처리 유닛(1214)은 이용가능한 다양한 마이크로프로세서 중 어느 하나일 수 있다. 이중 마이크로프로세서 및 다른 마이크로프로세서 아키텍쳐도 처리 유닛(1214)으로 사용될 수 있다.

시스템 버스(1218)는 메모리 버스 또는 메모리 제어기, 주변 버스 또는 외부 버스, 및/또는 11비트 버스, ISA, MSA, EISA, IDE, VESA 로컬 버스(VLB), PCI, USB, AGP, PCMCIA 및 SCSI를 포함하지만 이에 한하지 않는 임의의 다양한 이용가능한 버스 아키텍쳐를 이용하는 로컬 버스를 포함하는 여러 타입의 버스 구조 중 어느 하나일 수 있다.

시스템 메모리(1216)는 휘발성 메모리(1220) 및 불휘발성 메모리(1222)를 포함한다. 예를 들어 시동시에 컴퓨터(1212) 내의 요소들 사이에 정보를 전달하는 기본 루틴을 포함하는 기본 입출력 시스템(BIOS)은 불휘발성 메모리(1222)에 저장된다. 예를 들어, 불휘발성 메모리(1222)는 ROM, PROM, EPROM, EEPROM, 또는 플래시 메모리를 포함할 수 있지만 이에 한하지 않는다. 휘발성 메모리(1220)는 외부 캐시 메모리로서 동작하는 RAM을 포함한다. 예를 들어, RAM은 SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM 및 DRRAM과 같은 다양한 형태로 이용가능하지만 이에 한하지 않는다.

컴퓨터(1212)는 분리식/비분리식, 휘발성/불휘발성 컴퓨터 저장 매체도 포함한다. 도 12는 예를 들어 디스크 저장 장치(1224)를 도시한다. 디스크 저장장치(1224)는 자기 디스크 드라이브, 플로피 디스크 드라이브, 테입 드라이브, 재즈 드라이브, 짚 드라이브, LS-100 드라이브, 플래시 메모리 카드 또는 메모리 스틱을 포함하지만 이에 한하지 않는다. 또한, 디스크 저장 장치(1224)는 CD-ROM, CD-R 드라이브, CD-RW 드라이브 또는 DVD-ROM과 같은 선택적 디스크 드라이브를 포함하지만 이에 한하지 않는 다른 저장 매체와 별개로 또는 조합하여 저장 매체를 포함할 수 있다. 디스크 저장 장치(1224)와 시스템 버스(1218)의 접속을 용이하게 하기 위하여, 인터페이스(1226)와 같은 분리식 또는 비분리식 인터페이스가 일반적으로 사용된다.

도 12는 적절한 동작 환경(1210)에서 설명되는 사용자와 기본 컴퓨터 자원 간의 매개물로서 동작하는 소프트웨어를 나타낸다는 것을 이해해야 한다. 이 소프트웨어는 운영 체제(1228)를 포함한다. 디스크 저장 장치(1224)에 저장될 수 있는 운영 체제(1228)는 컴퓨터 시스템(1212)의 자원을 제어하고 할당한다. 시스템 애플리케이션(1230)은 시스템 메모리(1216) 또는 디스크 저장 장치(1224)에 저장되는 프로그램 모듈(1232) 및 프로그램 데이터(1234)를 통해 운영 체제(1228)에 의해 자원의 관리를 이용한다. 본 발명은 다양한 운영 체제 또는 운영 체제들의 조합에 의해 구현될 수 있다는 것을 이해해야 한다.

사용자는 입력 장치(1236)를 통해 컴퓨터(1212)에 명령 또는 정보를 입력한다. 입력 장치(1236)는 마우스, 트랙볼, 스타일러스, 터치 패드와 같은 포인팅 장치, 키보드, 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너, TV 튜너 카드, 디지털 카메라, 디지털 비디오 카메라, 웹 카메라 등을 포함하지만 이에 한하지 않는다. 이들 및 다른 입력 장치는 인터페이스 포트(1238)를 경유하여 시스템 버스(1218)를 통해 처리 유닛(1214)에 접속된다. 인터페이스 포트(1238)는 직렬 포트, 병렬 포트, 게임 포트 및 USB를 포함하지만 이에 한하지 않는다. 출력 장치(1240)는 입력 장치(1236)와 동일한 타입의 포트들 중 일부를 이용한다. 따라서, 예를 들어, USB 포트를 사용하여 컴퓨터(1212)에 입력을 제공하고 컴퓨터(1212)에서 출력 장치(1240)로 정보를 출력할 수 있다. 출력 어댑터(1242)는 특수 어댑터를 필요로 하는 다른 출력 장치들 중에서 디스플레이(예를 들어, 평판 패널 및 CRT), 스피커 및 프린터와 같은 소정의 출력 장치(1240)가 있다는 것을 나타내기 위하여 제공된다. 출력 어댑터(1242)는 예를 들어 출력 장치(1240)와 시스템 버스(1218) 사이의 접속 수단을 제공하는 비디오 및 사운드 카드를 포함하지만 이에 한하지 않는다. 다른 장치 및/또는 장치들의 시스템도 원격 컴퓨터(1244)와 같은 입출력 능력 양자를 제공한다는 점에 유의해야 한다.

컴퓨터(1212)는 원격 컴퓨터(1244)와 같은 하나 이상의 원격 컴퓨터에 대한 논리적 접속을 이용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(1244)는 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 워크스테이션, 마이크로프로세서 기반 기기, 피어 장치 또는 다른 공통 네트워크 노드 등일 수 있으며, 일반적으로 컴퓨터(1212)와 관련하여 설명된 요소들의 다수 또는 전부를 포함한다. 간략화를 위해, 메모리 저장 장치(1246)만이 원격 컴퓨터(1244)와 함께 도시되어 있다. 원격 컴퓨터(1244)는 네트워크 인터페이스(1248)를 통해 컴퓨터(1212)에 논리적으로, 그리고 통신 접속(1250)을 통해 물리적으로 접속된다. 네트워크 인터페이스(1248)는 LAN 및 WAN과 같은 통신 네트워크를 포함한다. LAN 기술은 FDDI, CDDI, 이더넷/IEEE 802.3, 토큰 링/IEEE 802.5 등을 포함한다. WAN 기술은 점대점 링크, ISDN 및 그 변형과 같은 회로 교환망, 패킷 교환망, 및 DSL을 포함하지만 이에 한하지 않는다.

통신 접속(1250)은 네트워크 인터페이스(1248)를 버스(1218)에 접속시키는 데 사용되는 하드웨어/소프트웨어를 나타낸다. 통신 접속은 간략화를 위해 컴퓨터(1212) 내부에 도시되어 있지만, 컴퓨터(1212) 외부에 있을 수도 있다. 네트워크 인터페이스(1248)의 접속에 필요한 하드웨어/소프트웨어는 예를 들어 정규 전화급 모뎀, 케이블 모뎀, 파워 모뎀 및 DSL 모뎀과 같은 모뎀들, ISDN 어댑터 및 이더넷 카드 또는 컴포넌트와 같은 내장 및 외장 기술을 포함한다.

도 13은 본 발명이 상호작용할 수 있는 샘플 컴퓨팅 환경(1300)의 개략 블록도이다. 시스템(1300)은 하나 이상의 클라이언트(1310)를 포함한다. 클라이언트(1310)는 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 시스템(1300)은 또한 하나 이상의 서버(1330)를 포함한다. 따라서, 시스템(1300)은 여러 모델 중에서 2층 클라이언트 서버 모델 또는 다층 모델(예를 들어, 클라이언트, 중간층 서버, 데이터 서버)에 대응할 수 있다. 서버(1330)는 또한 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수도 있다. 서버(1330)는 예를 들어 본 발명을 이용하여 변환을 수행하도록 스레드를 하우징할 수 있다. 클라이언트(1310)와 서버(1330) 간의 하나의 가능한 통신은 2개 이상의 컴퓨터 프로세스 사이에서 전송하기에 적합한 데이터 패킷의 형태일 수 있다.

시스템(1300)은 클라이언트(1310)와 서버(1330) 간의 통신을 용이하게 하는 데 사용될 수 있는 통신 프레임워크(1350)를 포함한다. 클라이언트(1310)는 클라이언트(1310)에 대해 로컬하게 정보를 저장하는 데 사용될 수 있는 하나 이상의 클라이언트 데이터 저장소(1360)에 동작적으로 접속된다. 마찬가지로, 서버(1330)는 서버(1330)에 대해 로컬하게 정보를 저장하는 데 사용될 수 있는 하나 이상의 데이터 저장소(1340)에 동작적으로 접속된다.

전술한 내용은 청구되는 내용의 양태들의 예를 포함한다. 물론, 청구되는 내용을 설명할 목적으로 컴포넌트 또는 방법의 모든 구상 가능한 조합을 설명하는 것을 불가능하지만, 개시된 내용의 조합 및 교환이 가능하다는 것을 당업자는 이해할 수 있을 것이다. 따라서, 개시된 내용은 첨부된 청구범위의 사상 및 범위 내에 있는 모든 교체, 수정 및 변경을 포함하는 것으로 의도된다. 또한, "포함", "구비"라는 용어 또는 그 변형은 상세한 설명 또는 청구범위에서 사용되는 범위 정도로, "포함"이라는 용어가 청구범위에서 전이구로 사용될 때 해석되는 것과 유사한 방식으로 포괄적인 것으로 의도된다.

본 발명은 적어도 항목들 사이의 관계와의 상호작용을 위한 확장 가능하고 사용하기 쉬운 시스템 및 방법을 제공한다

Claims

컴퓨터로 구현된 관계 시스템으로서, 상기 시스템은 컴퓨터 실행가능한 컴포넌트들을 포함하며, 상기 컴포넌트들은,

프로세서;

시스템 메모리;

2개 이상의 프로그램 항목들(programmatic items)을 획득하는 항목 수신기 컴포넌트 - 상기 프로그램 항목은 2개의 상이한 포맷을 가지며, 적어도 하나의 상기 프로그램 항목은 오래된 다른 포맷의 항목에 의해서는 허용되지 않는 데이터를 포함하는 새로운 포맷을 가짐 - ;

상기 항목 수신기 컴포넌트로부터 항목들을 수신하고 상기 항목들 사이의 하나 이상의 관계를 정의하는 구조체를 상기 항목들의 외부(external)에 생성하는 관계 생성 컴포넌트 - 상기 관계는 하나 이상의 정적 메소드들을 제공하는 정적 클래스에 의해 나타나며 상기 정적 메소드들은 상기 정적 클래스에 의해 나타나는 상기 관계를 사용하여 항목들 사이의 네비게이팅을 허용하고, 상기 관계 생성 컴포넌트는 상기 항목들을 변경하지 않으면서 상기 항목들 사이의 관계를 생성하고, 상기 관계들은 기본 키(primary key) 관계 또는 외래 키(foreign key) 관계를 포함하는 참조 결합(reference association), 2개 이상의 항목들 사이에서 공통 값이 공유되는 공통 값 결합(common key association), 상기 관계가 질의 기준(query criteria)에 의해 표현되는 조건 결합(condition association), 및 하나 이상의 다른 결합들을 통해 항목이 하나 이상의 다른 항목들에 대한 허브(hub)로 동작하도록 하나 이상의 상기 항목들 주위에 n-엔드 포인트(n-end point)들을 포함하는 엔티티 결합(entity association) 중 적어도 두 개의 결합(association)을 가지고, 상기 새로운 포맷과 오래된 포맷 사이에서 생성된 상기 관계는 이전에는 상기 오래된 포맷의 데이터 항목과 함께 저장되는 것이 허용되지 않던 데이터가 상기 오래된 포맷의 데이터 항목에 의해 저장되도록 생성됨 - ;

클래스 인스턴스의 집합으로부터의 상기 정적 클래스에 의해 나타나는 상기 관계를 사용하여 상기 항목들을 네비게이팅하는 네비게이션 컴포넌트 - 상기 관계들은 단순화된 표현식 및 메타데이터에 저장된 매핑을 사용하여 액세스되고, 상기 매핑은 대응되는 자세한 표현식(verbose expression)에 링크됨 - ; 및

관계들에 대한 항목을 특정하는 명칭을 생성하는 영향 컴포넌트(influence component) - 상기 영향 컴포넌트는 관계된 요소의 명칭들에 기초하여 관계의 명칭들을 추론하는 인공지능 컴포넌트(artificial intelligence component)를 포함하고, 외부의 메타데이터 정보에 의해 구동되는 명명 스키마를 수신하고 제공하는 것에 의해 상기 관계 생성 컴포넌트를 지원함 -

를 포함하는, 컴퓨터로 구현된 관계 시스템.
제1항에 있어서, 상기 항목들은 데이터 타입 및 XML 문서 중 하나인 컴퓨터로 구현된 관계 시스템.
제1항에 있어서, 상기 구조체는 클래스인 컴퓨터로 구현된 관계 시스템.
제3항에 있어서, 상기 클래스는 지정된 관계에 따라 특정 항목 요소를 검색하기 위한 메소드를 포함하는 컴퓨터로 구현된 관계 시스템.
제4항에 있어서, 상기 클래스는 정적 클래스인 컴퓨터로 구현된 관계 시스템.
제1항에 있어서, 상기 하나 이상의 관계는 일대일, 일대다, 다대일 및 다대다를 포함하는 바이너리(binary)인 컴퓨터로 구현된 관계 시스템.
제1항에 있어서, 상기 하나 이상의 관계는 상기 항목들에 관해 네비게이션 연산을 캡슐화하는 메소드에 의해 지정되는 컴퓨터로 구현된 관계 시스템.
제1항에 있어서, 상기 하나 이상의 관계는 구성(composition), 결합(association) 및 링크(link) 중 하나를 포함하는 컴퓨터로 구현된 관계 시스템.
데이터 구조를 저장하는 컴퓨터 판독 가능 기록 매체로서,

제1 데이터 타입;

제2 데이터 타입 - 상기 데이터 타입들은 2개의 상이한 포맷을 가지며, 적어도 하나의 상기 데이터 타입은 오래된 다른 포맷의 데이터 타입에 의해서는 허용되지 않는 데이터를 포함하는 새로운 포맷을 가짐 - ;

상기 제1 데이터 타입과 상기 제2 데이터 타입 간의 관계를 상기 제1 데이터 타입 및 상기 제2 데이터 타입 외부의 외부 구조체를 사용하여 상기 타입들과 독립적으로 정의하는 클래스 - 상기 관계는 하나 이상의 정적 메소드들을 제공하는 정적 클래스에 의해 나타나며 상기 정적 메소드들은 상기 정적 클래스에 의해 나타나는 상기 관계를 사용하여 데이터 타입들 사이의 네비게이팅을 허용하고, 상기 관계는 상기 제1 데이터 타입 및 상기 제2 데이터 타입을 변경하지 않으면서 정의되고, 상기 관계들은 기본 키(primary key) 관계 또는 외래 키(foreign key) 관계를 포함하는 참조 결합(reference association), 상기 제1 데이터 타입 및 상기 제2 데이터 타입 사이에서 공통 값이 공유되는 공통 값 결합(common key association), 상기 관계가 질의 기준(query criteria)에 의해 표현되는 조건 결합(condition association), 및 하나 이상의 다른 결합들을 통해 데이터 타입이 하나 이상의 다른 데이터 타입들에 대한 허브(hub)로 동작하도록 하나 이상의 상기 데이터 타입들 주위에 n-엔드 포인트(n-end point)들을 포함하는 엔티티 결합(entity association) 중 적어도 두 개의 결합(association)을 가지고, 상기 새로운 포맷과 오래된 포맷 사이에서 생성된 상기 관계는 이전에는 상기 오래된 포맷의 데이터 항목과 함께 저장되는 것이 허용되지 않던 데이터가 상기 오래된 포맷의 데이터 항목에 의해 저장되도록 생성됨 - ;

클래스 인스턴스의 집합으로부터의 상기 정적 클래스에 의해 나타나는 상기 관계를 사용하여 상기 데이터 타입들을 네비게이팅하는 네비게이션 컴포넌트 - 상기 관계들은 단순화된 표현식 및 메타데이터에 저장된 매핑을 사용하여 액세스되고, 상기 매핑은 대응되는 자세한 표현식(verbose expression)에 링크됨 - ; 및

관계들에 대한 항목을 특정하는 명칭을 생성하는 영향 컴포넌트(influence component) - 상기 영향 컴포넌트는 관계된 요소의 명칭들에 기초하여 관계의 명칭들을 추론하는 인공지능 컴포넌트(artificial intelligence component)를 포함함 -

를 포함하는 컴퓨터 판독 가능 기록 매체.
제9항에 있어서, 상기 클래스는 타입들 간의 관계를 정의하는 연산을 캡슐화하는 메소드를 포함하는 컴퓨터 판독 가능 기록 매체.
제10항에 있어서, 상기 관계는 바이너리, 구성, 결합 및 링크 중 하나를 포함하는 컴퓨터 판독 가능 기록 매체.
제10항에 있어서, 상기 타입들은 데이터베이스 테이블들로 맵핑되고, 상기 관계는 상기 테이블들 간의 공통 특성 상의 연결을 캡쳐하는 컴퓨터 판독 가능 기록 매체.
프로세서와 시스템 메모리를 포함하는 컴퓨터 시스템에서 실행되는 컴퓨터 구현 방법으로서,

2개 이상의 프로그램 항목들 사이의 관계 표현식을 수신하는 동작 - 상기 프로그램 항목은 2개의 상이한 포맷을 가지며, 적어도 하나의 상기 프로그램 항목은 오래된 다른 포맷의 항목에 의해서는 허용되지 않는 데이터를 포함하는 새로운 포맷을 가지고, 상기 관계는 대응되는 프로그램 언어에 의해 정적 클래스로서 나타나고, 상기 정적 클래스는 상기 정적 클래스에 의해 나타난 상기 관계들을 사용하여 항목들 사이의 네비게이팅을 허용하기 위한 하나 이상의 정적 메소드를 제공함 - ;

상기 표현식과 연관된 항목들 외부의 메소드를 찾는 동작;

상기 프로세서를 사용하여 상기 메소드를 실행하여, 상기 항목들 사이의 관계가 상기 항목들을 변경하지 않으면서 정의되도록 상기 항목들 외부의 외부 구조체를 사용하여 상기 항목들 사이의 관계를 연산하는 동작 - 상기 관계들은 기본 키(primary key) 관계 또는 외래 키(foreign key) 관계를 포함하는 참조 결합(reference association), 2개 이상의 항목들 사이에서 공통 값이 공유되는 공통 값 결합(common key association), 상기 관계가 질의 기준(query criteria)에 의해 표현되는 조건 결합(condition association), 및 하나 이상의 다른 결합들을 통해 항목이 하나 이상의 다른 항목들에 대한 허브(hub)로 동작하도록 하나 이상의 상기 항목들 주위에 n-엔드 포인트(n-end point)들을 포함하는 엔티티 결합(entity association) 중 적어도 두 개의 결합(association)을 가지고, 상기 새로운 포맷과 오래된 포맷 사이에서 생성된 상기 관계는 이전에는 상기 오래된 포맷의 데이터 항목과 함께 저장되는 것이 허용되지 않던 데이터가 상기 오래된 포맷의 데이터 항목에 의해 저장되도록 생성됨 - ;

클래스 인스턴스의 집합으로부터의 상기 정적 클래스에 의해 나타나는 상기 관계를 사용하여 상기 항목들을 네비게이팅하는 동작 - 상기 관계는 단순화된 표현식 및 메타데이터에 저장된 매핑을 사용하여 액세스되고, 상기 매핑은 대응되는 자세한 표현식(verbose expression)에 링크됨 - ; 및

관계에 대한 항목을 특정하는 명칭을 생성하는 동작 - 상기 영향 컴포넌트는 관계된 요소의 명칭들에 기초하여 관계의 명칭들을 추론하는 인공지능 컴포넌트(artificial intelligence component)를 포함함 - ; 및

외부의 메타데이터 정보에 의해 구동되는 명명 스키마를 수신하고 제공하는 동작

을 포함하는 데이터 상호작용을 용이하게 하는 컴퓨터 구현 방법.
제13항에 있어서, 결과를 반환하는 동작을 더 포함하는 컴퓨터 구현 방법.
제13항에 있어서, 상기 관계 표현식을 수신하는 동작은 특성 표기법(property notation)에 있어서의 타입들 간의 관계를 수신하는 동작을 포함하는 컴퓨터 구현 방법.
제15항에 있어서, 상기 메소드를 찾는 동작은 상기 표현식을 특성 표기법에서 메소드 명칭으로 확장하는 동작을 포함하는 컴퓨터 구현 방법.
제16항에 있어서, 상기 메소드를 찾는 동작은 하나 이상의 관계 메소드를 포함하는 관계 클래스를 식별하는 동작을 더 포함하는 컴퓨터 구현 방법.
제13항에 있어서, 상기 관계는 바이너리, 구성, 결합 및 링크 중 하나를 포함하는 컴퓨터 구현 방법.
삭제
삭제