KR950007883B1

KR950007883B1 - 한 세트의 클래스 구성장치 및 그 방법

Info

Publication number: KR950007883B1
Application number: KR1019920022021A
Authority: KR
Inventors: 에이치. 코너 마이크; 알. 마틴 앤드류; 케이. 레이퍼 래리
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션; 죤 디. 크래인
Priority date: 1991-12-12
Filing date: 1992-11-23
Publication date: 1995-07-21
Also published as: US5361350A; EP0546809A3; KR930014001A; JPH05241844A; CN1073540A; CN1096637C; CA2077272C; EP0546809A2; CA2077272A1

Abstract

내용 없음.

Description

한 세트의 클래스 구성장치 및 그 방법

제1도는 본 발명에 따른 개인용 컴퓨터 시스템의 블럭 다이어그램.

제2도는 본 발명에 따른 SOM 데이터 구조도.

제3도는 본 발명에 따른 SOM 클래스데이터 구조도.

제4도는 본 발명에 따른 언어 중립 오브젝트 인터페이스(a language neutral object inteface)를 도시하는 순서도.

제5도는 본 발명에 따라 SOM 오브젝트를 사용하는 응용프로램의 링크, 로드 및 실행을 도시을 도시하는 순서도.

제6도는 본 발명에 따른 새로운 SOM 클래스의 생성을 도시하는 순서도.

제7도는 본 발명에 따른 새로운 SOM 오브젝의 상세한 구성을 도시한 순서도.

제8도는 본 발명에 따른 새로운 SOM 포괄 클래스의 상세한 구성을 도시한 순서도.

제9도는 본 발명에 따른 새로운 SOM 클래스 오브젝트의 상세한 초기화를 도시하는 순서도.

제10도는 본 발명에 따라 오프셋 값(offset values)을 사용하여 SOM 클래스 데이터 구조를 상세한 초기화를 도시하는 순서도.

제11도는 본 발명에 따라 정적으로 정의된 클래스 계층의 상세한 부모클래스 새도우딩(the detauled parent class shadowung of a statically definde class hierarchies)을 도시하는 순서도.

제12도는 본 발명에 따른 재디스패치(the redispatch)를 도시하는 흐름도.

제13도는 본 발명에 따라 한 개의 공용인스턴스 변수(a smgle public instance varuable)에 대한 SOM 클래스 데이터 구조에 오프셋 값의 사세한 초기화를 도시하는 순서도.

제14도는 본 발명에 따라 메쏘드 호출(a static method call)을 동적 메쏘드 호출(a dynamic method call)로 변환하는데 재디스패치 스터브(a redispatch stub)가 사용될 때 일어나는 상세한 제어 흐름을 도시하는 순서도.

제15도는 본 발명에 따라 클래스에 대한 메쏘드 프로시져 테이블(a method procedure table)을 초기화 하는 상세한 제어 흐름을 도시하는 순서도.

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

18 : I/O어댑터 22 : 사용자 인터페이스 어댑터

34 : 통신 어댑터 36 : 디스플레이 어댑터

본 발명은 일반적으로 오브젝트 지향 응용프로그램(obkect oriented applications)의 향상, 특히 클래스 메쏘드 명칭(class method names)을 효율적으로 관리하는 것에 관한 것이다.

워크스테이션 소프트웨어를 개발하는 사람들중에는, 오브젝트 지향 프로그래밍(또는 OPP)은 갈수록 중요한 새로운 프로그래밍 기술로서 인식되고 있다. 이것은 종래의 소프트웨어 개발의 유형과 비교할 때 프로그래머의 생산성을 향상시킴으로서 소프트웨어 재사용과 확정성을 위하여 많은 기회를 제공한다. 그렇지만, 오브젝트 지향 기술은 오늘날 주요한 상어적인 소프트웨어 분야에 효과적으로 파고들지 못하고 있더다. 특히, 운영체제가 새로운 기술을 수용하는 데 꺼려하고 있다.

많은 새로운 프로그래밍 기술과 같이, 초창기의 OPP 개념에 대한 표현은 새로운 언어와 개발도구를 만드는데 초점이 맞추어져 있었고, 각각은 일부의 특정한 면을 개발하는데 설계되어 있었다. 스몰트크(Smalltalk)와 같이 소위 수수한 오브젝트 지향 언어는 그 의미론이 전통적인 프로시져식 지향의 시스템아키텍쳐와 매우 다르기 때문에 완전한 실행시 환경(a complete run-time environment)(종종 가상기계로서 인식됨)을 가정한다. 다른 한편, C⁺⁺과 같은 하이브리드 언어(Hybrid language)는 실행시 지원을 적게 필요로 하지만 그 결과 종종 오브젝트를 제공하는 프로그램과 그것들을 사용하는 클라이언트 프로그램(the client programs)을 긴밀히 속박하는 결과가 된다. 오브젝트를 제공하는 프로그램과 그 클라이언트간의 긴밀한 속박(Tight binding)은 종종 제공하는 프로그램에 약간의 변화가 생길 때 마다 클라이언트 프로그램을 다시 컴파일시키는 것을 요구한다. 이러한 시스템의 예들은 미합중국 특허 제 4,885,717 ; 4,953,080 및 4,898,132 호에 공지되어 있다.

다른 언어와 오브젝트 지향 개발도구들이 OPP의 다른 면을 강조함으로서, 결과로 나타나는 소프트웨어를 이용하는 영역이 종종 제한되어 있다. 예, C⁺⁺프로그래머는 스몰토크에서 개발된 오브젝트 등을 쉽게 사용할 수 없거니와, 스몰토크 프로그래머가 C⁺⁺오브젝트들을 효율적으로 사용할 수 없다. 간단하게 한언어에서 구현된 오브젝트와 클래스는 다른 것으로부터 쉽게 사용될 수 없다. 불행하게도 이것이 발생할 때 OPP의 주요한 이점중에 하나인, 코드 재사용의 증가가 크게 감소한다. 오브젝트 지향 언어와 개발도구간의 경계로 인하여 상호 호환성을 유지하는데 장애가 되고 있다.

따라서, 본 발명의 중요한 목적은 관리 능력(manageabliity)을 향상시키기 위하여 하나의 데이터 구조에 있는 모든 명칭과 부수적인 지우너정보에 대한 표현을 잡합(collecting representations of all of the names and additional supporting information)시킴으로서 클래스 메쏘드 명칭을 관리하는 것이다.

본 발명의 상기 및 다른 목적들은 두 개의 메카니즘을 사용하는 프로세서가 메모리에 있는 알고리즘을 연산함으로서 달성된다. 먼저, 클래스 메쏘드 프로시져 테이블은 시스템 오브젝트 모델(the System Object Model (SOM) 컴파일러에 의해 생성된 클래스 특수 프로시져(class specific proceduress)에 의해서 초기화된다. 이 프로시져들은 메쏘드 정의를 포함하고 있는 파일내에 포함되어 있다. 이렇게 함으로서 프로시져는 메쏘드 명칭을 외연화(externalizaton)할 필요없이 메쏘드 명칭을 참조할 수 있다. 특스 프로시져에 의해 제공된 정보는 클래스 데이터 구조에 의해 유지되며 정보가 필요할 때 마다 클래스 메쏘드를 경유하여 액세스할 수 있다.

다음에, 메쏘드에 대한 어떤 부수적인 지원정보, 특히 각 메쏘드에 대한 메쏘드 프로시져 테이블에서의 오프셋을 오부에서 명명된 한 개의 데이터 구조(a single externallu named data struture)에 기록된다. 두 메카니즘을 조합시키므로써 매쏘드마다(on a per method basis) 외부 명칭을 부여할 필요성이 없어진다.

본 발명은 IBM 코포레이션으로부터 입수할 수 있는 IBM S/2 컴퓨터상에 상주하는 운영체제의 콘텍스트(the context)에서 양호하게 실행된다. 전형적인 하드웨어 환경(A representative hardware environment)은 제1도에 도시되어 있고, 이것은 종래의 마이크로프로세서와 같은 중앙처리 장치(10)와, 시스템 버스(12)를 통해서 상호 연결된 많은 다른 장치를 갖는 본 발명에 따른 워크스테이션의 정형적인 하드웨어 구성을 도시한다. 제1도에 도시된 워크스테이션은 랜덤액세스 메모리(RAM)(14), 판독전용메모리(ROM)(16), 디스크 장치와 같은 주변 장치를 버스에 연열하기 위한 I/O 어댑터(22), 키보드(24), 마우스(26), 스피커(28), 마이크로폰(32) 및 터치스크린 장치(도시되어 있지 않음)와 같은 다른 사용자 인터페이스 어댑터(22), 워크스테이션을 데이터 처리 네트워크에 연결하기 우한 통신 어댑터(34)와 버스를 디스플레이 장치(38)에 연결하기 위한 디스플레이 어댑터(36)를 포함한다. 워크스테이션은 극서에 상주하는 OS/2 베이스 운영 체제를 가지며 본 발명은 구성하는 컴퓨터 소프트 웨어는 툴킷(a toolkit)으로서 포함되어 있다.

오브젝트 지향프로그래밍 그 자체는 고품질이며, 재사용가능한 코드를 개발하는데, 있어서 중요한 방법학으로 자리를 잡고 있다. 본 발명은 클래스 라이브러리와 오브젝트 지향 프로그램을 개발하기 위한 새로운 시스템을 포함한다. 상기 시스템은 시스템 오브젝트 모델(SOM)이라고 불리운다. 오브젝트 지향 프로그램인 SOM에 대한 상세한 설명과 다른 오브젝트 지향 언어와의 비교는 본 발명을 이해하는데 도움을 준다.

소프트웨어 환경에서 새로운 개발은 오브젝트 지향 프로그래밍이다. 오브젝트 지향 프로그래밍 언어(Object-Oriented Programming Languages)(OOPL)는 업계 전체에서 사용되고 있으며, 오브젝트 지향 데이터 베이스(OODB)가 많은 관심을 가지고 시작되고 있으며 심지어 오브젝트 지향의 설계 및 분석(OODA)도구들이 시스테믈 설계하고 모델화하는 방법을 변모시키고 있다.

오브젝트 지향 프로그램은 그것과 매우 유사한 구조화된 프로그래밍과 비교하며 잘 이해될 수 있다. 모두가 똑같이 근본적인 프로그램은 시스템을 기능적 모듈의 계층화된 세트로서(as a layered ste of functional modules)모델화 한다. 이 모듈들은 각가그이 계층(each layer)이 시스템에 대한 보다높은 계층에서의 도시를 나타내는 피라미드식으로형성된다. 구조화된 프로그래밍은 시스템의 행위를 모델화하지만, 시스템의 정보를 모델화시키는 것(modeling the system's information)은 거의 도입하고 있지 않다.

오브젝트 지향 프로그래밍은 시스템을 한 세트의 협동하는 오브젝트(a set of cooperating obkects)들로 모델화한다. 구조화된 프로그래밍과 같이, 이것은 시스템 행위의 복잡성을 관리하려고 한다. 그러나, 오브젝트 지향 프로그래밍도 역시 시스템 정보의 복잡성을 관리하려는 데에서 구조화된 프로그래밍을 능가하고 있다.

오브젝트 지향 프로그래밍이 시스템의 행위와 정보의 복잡성(the behavioral and informational complexity) 모두를 모델화하기 때문에, 시스템이 단순히 잘 "구조화(structured)"된 것보다 훨씬 우수하게 구성(to be much better organixed)되는 경향이 있다. 오브젝트 지향 시스템이 보다 우수하게 구성되었기 때문에, 이해하고, 디버그하고, 유지관리하여 그리고 전개시키는 것이 보다 쉽다. 잘 구성된 시스템은 또한 코드를 재사용할 수 있다.

오브젝트 지행 프로그래밍은 정보와 행위의 복잡성을 관리하는 두가지 문제를 긴밀하게 관련된 것으로 간주한다. 그것의 기본적인 구성 단위는 오브젝트이다. 오브젝트는 오브젝트의 스테이트(an object's state)라는 오브젝트으 스테이트를 표현하는 데이터를 정의하는 오브젝트와 오브젝트를 지원하는 메쏘포드에 대한 총제적인 설명이다.

C에서 오브젝트 지향 프로그래밍; 이것은 자연스럽게 우리들을 SOM 철학으로 유도한다. 포괄적인 스택(a generic stack)과 관련된 정보를 포함하고 있는 데이터 구성정의를 생각해보자. 데이터 구조는 스택구조에서 동작하도록 의도된 일련의 함수들(a series of functions)을 포함하고 있다. 기본적인 스택정의가 주어졌다면, 이 데이터 구조에 대한 복수의 인스턴스는 프로그램내에서 선언될 수 있다.

C에서 포괄적인 스택정의는 이하와 같다 ;

struct stack Type{

void *stackArray[STACK-SIZE];

int stackTop;

};

typedef struct stackType Stack;

포괄적인 스택 함수의 정의는 다음과 같다 ;

stack *create(); /*메모리를 할당하고 새로운 스택을 초기화시킴

void *pop( /*^*/스태틱에서 인수한 팝업함

*/

stack *thisstack;

void push( /*스택에 푸시함 */

stack *thisStack,

void *nextElement);

대부분 C프로그래머는 어떻게 하여 이러한 함수들이 작성되는지를 상상할 수 있는 예를들면 <push()>는 이하와 같다.

void push(stack *thisStack, void *nextElement)

{

thisStack->stackArray[thisStack->stackTop] =

nextElement;

thisStack->stackTop++:

}

클라이언트 프로그램은, 즉 통역(interpretation)을 필요로 하는 한 스택의 단어들은 생성하기 위해 이 스택을 사용할지도 모른다.

main()

{

stack *wordStack;

char *subject="Emily";

char *verb="eats";

char *object="ice cream";

char *nextWord;

wordStack=create();

push(wordStack, object);

push(wordStack, verb);

push(wordStack, subject);

/* … */

}

상기 예는 오브젝트 지향 프로그래밍을 검토하는 데 사용될 수 있다. 클래스는 오브젝트의 정의이다. 정의(The definition)는 오브젝트의 데이터 항목과 그것이 지원하는 메쏘드를 포함한다. <stack>은 클래스의 한 예이다. 스택은 두 개의 데이터 항목<stack Array)와 <stack Top>를 포함하며, 세 개의 메쏘드 <create()>, <push()> 및 <pop()>를 지원한다. 메쏘드는 함수와 유사하지만, 특정한 클래스의 오브젝트를 동작시키도록 설계되었다. 오브젝트 클래스의 특수한 인스턴스이거나 혹은 클래스의인스턴화된 것이다. 오브젝트 <wordstack>은 클래스 <Stack>의 오브젝트이거나 또는 <wordstack>은 스택의 인스턴스이다.

모든 메쏘드는 실행시킬 특정한 오브젝트를 필요로 한다. 이 오브젝트는 타게트 오브젝트 혹은 때때로 쉰하는 오브젝트라고 불리운다. 각 메쏘드(except <(create()>) 그것의 첫 번째 파라메타로서 타게트 오브젝트에 대한 포인터를 취한다는 것에 유의하여야 한다. 이것은 프로그래밍 소정의 클래스에 대하여 많은 오브젝트를 가질 수도 있으며, 그리고 각각은 클래스 메쏘드에 대한 잠재적인 타게트(potential targets)이다.

상기 유형의 구성에는 세가지 중요한 장점이 있다. 첫째, 유사한 개념이 어울리는 다른 환경하에서 재사용될 수 있는 포괄개념(generic concepts)이 전개된다. 둘째, 프로그램속으로 포함되기 전에 완전히 테스트될 수 있는 자신이 포함되어 있는 코드(self-cintainde code)가 개발된다. 셋째, 내부의 세부사항이 은폐되고 클라이언트에게 이해 관계가 없는 캡슐화된 코드가 개발된다. 클라이언트<main()>프로그램은 그 명칭을 제외한 <stack> 클래스, 그것이 지원하는 메쏘드 및 그 메쏘드에의 인터페이스에 대하여 어떤 것도 알 필요가 없다.

이점이 되는 다른 비교는 SOM과 가장 널리 사용되는 오브젝트 자향 프로그래밍 언어 C⁺⁺이다. SOM은 C⁺⁺와 유사한 점이 많다. 모두가 클래스 정의, 상속(inheritance) 및 오버리든 메쏘드(overridden methods)(C⁺⁺에서 가장 메쏘드(virtual method)를 지원한다. 모두가 인캡슐레이션이라는 개념을 지원한다. 그러나 그런 반면에 C⁺⁺는 스탠드얼론(stand-alone) 프로그래밍을 지원하도록 설계되었고, SOM은 상업적 품질의 클래스라이브러리를 지원하는 데 초점되어 있다. SOM과 C⁺⁺간의 대부분의 차이는 이 문제에 집중된다. C⁺⁺클래스 라이브러리들은 버전에 의전적인 반면, C⁺⁺클래스 라이브러리들은 버전에 독립적(version independent)이다. 새로운 C⁺⁺클래스 라이브러리가 공개될 때, 만일 일어난 변화가 공용인터페이스와 관련이 없다면 클라이언트 코드는 완전히 다시 컴파일되어야 한다.

C⁺⁺은 단지 한 개의 C⁺⁺에서만의 프로그래밍을 지원한다. SOM은 많은 언더들을 지원하도록 설계되어 있다. 언어라기 보다는 SOM은 클래스라이브러리를 정의하고, 조작하며 그리고 해제(releasing)하기 위한 시스템이다. SOM은 클래스와 메쏘드를 정의하는데 사용하지만, 그것은 새로운 언어구문을 배울 필요없이 메쏘드를 실행시키기 위해 언어를 선택하는 실행자에게 달려있다.

C⁺⁺은 은페(hiding) 혹은 인캡슐레이션을 구현하기 위한 최소한의 지원을 제공한다. 클라이언트에게 공개되어야 하는 C⁺⁺클래스 정의는 전형적으로 전용(pricate)인 데이터와 메쏘드에 대한 선언을 포함한다. SOM에 있어서, 클라이언트는 이와같이 실행에서의 세부사항에 결코 초점을 맞추어서는 안된다. 클라이언트는 단지 공용정보만을 포함하고 있는 <.SC> 파일만을 주시할 필요가 있다. 또한 C⁺⁺은 한정된 메쏘드 함수를 제공한다. SOM은 오프셋 메쏘드 레져루션(offste method resolution), 명칭 룩업(lookup) 레져루션 및 디스패치 레져루션과 같은 몇가지 선택 사하을 제공한다.

SOM과 C⁺⁺간의 다른 한가지 흥미이는 차이는 클래스에 대한 그것의 개념에 있다. C⁺⁺에서, 클래스 선언은 구조선언과 매우 유사하다. 이것은 실행시에 중요성을 갖는 특성이 없는 컴파일시의 패키지이다.

SOM에서, 오브젝트의 클래스는 오브젝트이다. 클래스 오브젝트 그자체는 메타클래스(the metaclass) 라고 하는 다른 클래스의 인스턴스화한 것이다. 클래스 오브젝트는 C⁺⁺에서 직접적으로 유사한 것이 없는 <someGetName()>, <someGetParent()> 및 <someFindMethod()>와 같은 많은 유용한 메쏘드들을 지원한다.

S/2 2.0은 SOM(시스템 오브젝트 모델을 위한(이라고 하는 언어-중립(a languatge-neutral)오브젝트 지향 프로그래밍 메커니즘을 포함한다. 비록 스택의 예에서와 같은 전통적인 언어로 오브젝트 지향 프로그램을 작성하는 것이 가능하지만, SOM은 새로운 패러라임(the new paradigm)을 지원하고 절차식(또는 비-오브젝트 지향의) 언어와 오브젝트 지향언어 모두와 함께 사용되도록 특별히 설계되었다.

오브젝트 지향 프로그램밍의 중요한 필수조건은 코드 재사용성이다. 전형적으로, 코드 재사용성은 클래스 라이브러리를 사용함으로서 이루어진다. 오늘날의 라이브러리 기술은 클래스 라이브러리가 항상 언어에 특수하다(language specific)는 점에서 제한이 있다. C⁺라이브러리는 스몰토크 프로그래머에 의해 사용될 수 없고 스몰트크 프로그머는 C⁺라이브러리를 이용할 수 없다. 분명히 절차식 혹은 오브젝트 지향의 어떤 프로그래밍 언어로부터 사용할 수 이는 클래스 라이브러리를 생성하는데 사용될 수 있는 언어-중립 오브젝트 모델을 새로이 만들 필요가 있다.

SOM은 대부분의 절차식 언어에 결여되어 있는 세가지 중요한 특성을 도입한다. 이것들은 캡슐화, 상속 그리고 다형성(polymorphism)(여기서 "오버라이드 레져루션(override resolution)"이라고 일컬어진다. 상속은 클래스(서브클래스라 부른다)의 형태의 행위(the shape and behavior of a Class)를 다른 클래스(부모클래스 또는 슈퍼클래스라 부른다)로부터 자동증가차(incremernatal differences)로서 명시하는 기법을 일컫는다.

캡슐화는 클라이언트로부터 실행의 세부사항(implementation details)을 은폐시키는 것을 가르킨다. 이것은 클라이언트가 시스템에 역효과를 미칠 수 있는 실행에서 변화가 일어나는 것을 방지한다. 예로, 스택의 예에서 C코드에는 어떤 보호도 존재하지 않는다. 비록 클라이언트가 스택에 대한 내부의 데이터 구조를 알필요가 없었더라도, 클라이언트가 이러한 실행상의 세부사항을 참조하는 것을 방지할 방법이 없었다. 그러나 우리는 클라이언트가 내부의 스택 데이터 항목을 사용하였고, 아마도 낡게 만든 코드를 작성하지 못하게 방지(prevent)하는 것이 아니라 못하게(prevent)할 수 있다.

상속 또는 클래스 파생(class derivation)은 기존의 클래스로부터 새로운 클래스를 개발(developing)하기 위한 특수기법이다. 이 능력은 기존클래스의 보다 특수화 버전인 새로운 클래스의 생성에 대비한다. 예를 들어, 우리는 <stack> 클래스와 같은 <DebuggableStack>을 생성할 수 있지만, 그러나 최고값(the top value)을 참조하기 위한 <peek()>와 스택의 완전한 리스팅을 인쇄하기 위한 <dump()>과 같은 부가적인 디버깅 메쏘드를 지원한다.

또한 상속은 코드의 결합(Code Consolidation)을 제공한다. 그래서, 예를들어, <GraduateStudent> 와 <UnderGraduateStudent>를 정의하는 클래스는 제3의 클래스인 <Student>속으로 통합될 수 있다. 이때 우리는 <GraduateStudent>와 <UnderGraduate>를 모두 공통의 부모<Student>로부터 파생된 보다 특수한 클래스(more specialized Classes)로서 정의한다.

상속은 몇가지 부가적인 의미론(semantics)을 도입한다. 특수화된 클래스는 보다 범용화된 클래스(more generalized class)로부터 파생되어진다고 한다. 범용 클래스는 부모클래스 또는 종종 베이스 클래스(the generalized class)라고 불리운다. 특수화된 클래스는 자식클래는 또는 종종 파생된 클래스라고 불리운다. 자식클래스는 부모를 위해 정의돈 어떤 메쏘드가 자식을 대하여 자동적으로 정의되는 것을 의미하는 그 부모클래스의 특성을 상속받는다고 한다. 그리하여, <GraduateStudent> 와 <UnderGraduateStudent> 모두가 <Student>로부터 파생되었기 때문에, 그것들 모두는 공통의 부모에서 선언된 어떤 메쏘드를 자동적으로 얻게 된다.

오버라이드 레져루션(overrride resolution)은 메쏘드의 명칭뿐만이 아니라 클래스 위계구조(a class hierarchy)에 기초하여 리졸브(being resolved)되는 호출된 메쏘드(invoked methods)를 일퀴는다. 이것으로 클래스를 파생하는 것과 같이 메쏘드를 재정의하는 것이 가능하다. <Student>에 대한 <PrintStydent Info()> 메쏘드를 정의한 다음, <UnderGraduateStudent>와 <GraduateStudent>모두에서 메쏘드를 오버라이드하거나 또는 재정의할 수 있다, 오버라이드 레져루션은 타게트 오브젝트의 형을 기초로 하여 리졸브한다. 만약 타게트 오비젝트형이 <Student>라면, <PrintStydent Info()>의 <Student> 버전이 호출된다. 만약 타게트 오브젝트 형이 <GraduateStudent>라면, <PrintStydent Info()>의 <GraduateStudent> 버전이 호출된다.

SOM에 클래스라이브러리를 생성하는 프로셋는 세단계 프로세스이다. 클래스 설계가가 클래스 인터페이스를 정의하고, 클래스 메쏘드를 실행하며, 마지막으로 결과로 나타는 오브젝트 코드를 클래스 라이브러리속으로 로드한다. 클라이언트는 이 클래스를 직접 사용하고, 특수목적에 적합하도록 변형을 가하거나, 혹은 자신을 위해 전적으로 새로운 클래스를 덧붙인다.

SOM에서, 클래스는 클래스 정의 파일을 생성함으로서 정의된다. 클래스 정의 파일(The class definition file)은 "csc"의 확장잘 명명된다. 그것은 가장 기본적인 형태에서, 클래스 정의 파일은 다음과 같은 부류로 나뉘어진다.

1. 인클루드 부분

이 부분은 C<#include> 지시문과 매우 유사한 포함될 필요가 있는 파일을 선언한다.

2. 크래스 명칭과 옵션

이 부분은 클래스의 명칭을 정의하고 여러 가지 옵션들을 선언한다.

3. 부모정보(Parent information)

이것은 클래스에 대한 부모 또는 베이스클래스를 정의한다. 모든 클래스는 반드시 부모를 가져야 한다. 만약 클래스가 기존의 어떤 클래스로부터 파생되지 않았다면, 이때 그것의 부모는 SOM이 정의한 클래스 <SOMObject>일 것이며, 이것에 대한 클래스 정보는 파일 <Somobj.sc>에 존재한다.

4. 데이터 부분

이 부분은 이 클래스의 오브젝트에 의해 포함된 어떤 데이터 항목을 선언한다. 디폴트로서, 데이터는 클래스의 메쏘드에 의해서만 액세스될 수 있다.

5. 메쏘드 부분

이 부분은 이 클래스의 오브젝트가 응답할 수 있는 메쏘드는 어떤 클래스 클라이언트도 사용할 수 있다. 이 클래스 정의화일 <Student. csc>는 파생되지 않은 <Student> 클래스를 설명하면, 이하와 같다.

class Definition File:<student.csc>

inculude<somobj.sc>

class:

student;

parent;

SOMObject;

data:

char id[16]; /* 학생 :d */

char name[32]; /* 학생이름 */

methods:

void setUpStudent(char *id, char *name);

--sets up a new student.

void printStudentInfo();

--prints the student information.

char *getStudentType();

--returns the student type.

char *getStudentId();

--returns the student id.

클래스 메쏘드 클래스 메쏘드 실행와일에서 실행된다. 클래스 정의 파일의 메쏘드 부분에 정의된 각 메쏘드는 실행될 필요가 있다. 그것은 SOM 지원을 제공하는 어떤 언어에서 실행될 수 있다. C는 명세서 전반에 걸쳐 예시적인 언어로 사용된다. 그러나, 기술분야에 통상적인 기술을 가진 사람들을 어떤 프로그래밍 언어가 대체될 수 있다는 것을 알 수 있을 것이다. 학생(Student)클래스 메쏘드 파일 <Student.c>은 이하와 같다.

클래스 메쏘드 실행화일:<Student.c>

Class Method Implmentation File:<student.c>

#define student_Class_Scource

#include "student.ih"

static void setUpStudent(

Student *somSelf, char *id, char *name)

}

studentDate *somThis=

studentGetDate(somSelf);

strcpy(_i, id);

strcpy(_name, name);

}

static voide printStudentInfo(student *somSelf)

}

StudentData *somThis=

studentGetData(somSelf);

printf(" Id : %s ＼n",_id);

printf(" Name : %s ＼n",_name);

printf(" Type : %s ＼n",

_getStudentType(somSelf));

}

static char *getStudentType(Student *somSelf)

}

studentData *somThis=

studentGetData(somSelf);

static char *type="student";

return(type);

}

static char *getStudentId(Student *somSelf)

}

StudentData *somThis=

studentGetData(somSelf);

return(_id);

}

메쏘드 코드가 표준 C와 유사하게 보인다는 것에 주목해야 한다. 첫째, 각 메쏘드는 첫 번째 파라메타로서 타게트 오브젝트를 가리키는 포인터(<somSelf>)를 취한다. 이 파라메타는 클래스 정의화일에서 묵시적이지만, 메쏘드 실행에서는 명사적으로 된다. 둘째, 각 메쏘드는 SOM 해더 파일내에서 정의된 마이크로의 의해 사용되는 <SomThis>라고 명명된 내부 변수를 설정하는 라인에서 시작한다. 셋째, 타게트 오브벡트에 대한 데이터 인수의 명칭은 밑줄문자 "-"가 선행한다. 밑줄문자가 붙은 명칭은 클래스 헤더화일에 정의된(C언어 마이크로를 나타낸다. 넷째, 메쏘드는 메쏘드 명칭의 앞에 밑줄 "-"를 높음으로서 호출된다. 이 밑줄 문자가 붙은 명칭은 메시지 레져루션(message resolution)을 위한 마이크로를 나타내며 프로그래머로 하여금 상기 처리 과정(this process)의 세부사항을 이해할 필요가 없게 한다.

모든 메쏘드의 첫 번째 파라메타는 항상 타게트 오브젝트에 대한 포인터이다. 이것은 이하에 그 타게트 오브젝트상의 메쏘드 <grtSStudentType()>fmf 호출하는 메쏘드 <printStudentInfo()>에 예시되어 있다.

SOm compiler generated<student.c>

#define Student_Class_Source

#includ "student.ih"

static void setUpStudent(

student *somSelf, char *id, char *name)

}

studentData *somThis=

studentGetDdata(somSelf);

}

static void printStudentInfo(student *somSelf)

}

studentData *somThis=

studentGetData(somSelf);

}

/*…and so on for the other methods. */.

이하에 논의 되는 각 클래스와 함께 호출된 한 세트의 파일이 있는 파일은 다른 확장자를 가지나, 모두가 예에서 클래스 정의화일 <Student>같이 동일한 파일명을 가진다. 그 파일들은 이하에 설명되어 있다.

<Student.csc>-이것은 상술된 것과 같이, 클래스 정의화일이다.

<Student.csc>-이것은 클래스 정의화일의 서브세트이다. 이것은 공용항목(public elements)에 대한 주석을 포함하고 있는 공용인 <.cac>화일로부터 나오는 모든 정보를 포함한다. 스튜던트(Student)예를 위하여, <Student.csc> 데이터 부분을 제외한 <Student.csc>로 부터의 모든 것을 포함할 것이다. 이 파일은 SOM 컴파일러에 의해 생성된다.

<Student.h>-이것은 공용 메쏘드를 호출하고 클래스의 공용데이타 함수들을 액세스하는 데 필요한 마이크로들을 포함하고 있는 유효한 C헤더화일이다. 이 파일은 클래스의 어떤 클라이언트에 포함될 것이며, SOM 컴파일러에 의해 생성된다.

<Student.ih>-<Student.h>와 유사하지만, 이것은 메쏘드를 실행하는데 필요한 부수적인 정보를 포함한다. 이것은 <.h> 파일에 대한 실행자(the inplementor)의 버전이며, 클래스 메쏘드 실행화일에 포함되어야만 한다. 이 파일은 SOM 컴파일러로서 생성되며 편집(edited)되어서는 안된다.

<Student.c>-메쏘드 실행을 포함한다. 초기에는 SOM 컴파일러로서 생성되고 다음에 클래스 실행자에 의해 업데이트된다.

다른 클래스를 우한 블록을 형성하는 것으로서 클래스를 이용하는 두가지 방법이 있다. 이것은 파생(또는 상속)과 구성(derivation and construction)이다.

이 예에서, <GraduateStudent>는 그것의 베이스 또는 부모클래스인<Student>로부터 파생된다. 파생된 클래스는 베이스 클래스의 모든 특성을 자동적으로 승계(picks ip)한다. 파생된 클래스는 새로운 메쏘드의 정의와 실행을 통해서 새로운 기능성(new functionality)을 덧붙일 수 있다. 또한 파생된 클래스는 오버라이딩(overriding)이라고 하는 프로세스인 그 베이스 클래스의 메쏘드를 다시 정의할 수 있다. 예로 <GraduateStudent>는 (setUpGraduateStudent()>을 <Student>로부터 상속받는 그 메쏘드들에게 부가한다. 이것은 두 개의 다른 상속된 메쏘드 <printStudentInfo()와 <getStudentType()>를 오버라이드한다. 이것은 변화없이 <Student> 베이스 크래스로부터 <setUpStudent()>와 <getStudentId()>를 상속받는다. <GraduateStudent>에 대한 클래스 정의화일<graduate.cse>는 이하와 같다.

클래스 정의화일 : <graduate.csc>

include<student.sc>

class:

GraduateStudent;

parent:

student;

data:

char thesis[128]; /*논문 제목 */

char thesis[16 ]; /*학위 유형

*＼

methods:

override printStudentInfo;

override getStudentType;

void setUpGraduateStudent(

char *id, char *name, char *thesis, char

*degree);

메쏘드 실행화일<graduate.c>은 이하와 같다.

클래스 메쏘드 실행화일 : <graduate.c>

#define Graduate student_Class_Scource

#include "graduate.ih"

static void printStudentIbfo(GraduateStudent

*somSelf)

{

GraduateStudentData *simThis=

GraduateStudentGetData(somSelf);

parent_printStudentInfo(somSelf);

printf(" Thesis :%s ＼n",_thesis);

printf(" Degree :%s ＼n",_degree);

}

static char *getstudentdentType(Graduatestudent

*someSelf)

{.

Static char *type="Graduate";

return(type);

}

static void setUpGraduateStuent(

Graduatestuent *somSelf, char *id, char

*name,

char *thesis, char *degree)

}

GraduateStudentData *somThis=

GraduateStudentGetData(somself);

_setUpStudent(somSelf, id, name);

strcpy(_thesis, thesos);

strcpy(_degree, degree);

}

종종 오버리든 메쏘드는 그 부모의 원래 메쏘드(the original method)를 호출할 필요가 있을 것이다. 예를 들어, <GraduateStudent>에 대한

<printStudentInfo()>는 <GraduateStudent>특수 정보를 인쇄하기 전에 먼저 <printStudentInfo())의 <Student> 버전을 호출한다. 이것에 대한 구문은 <printStudentInfo()>메쏘드에서 볼수 있는 것과 같이, "parent()MethodName>"이다.

소정의 베이스 클래스는 한 개 이상 파생하기 위하여 사용될 수 있다. 클래스<UnderGraduateStudent>도 역시 <Student> 로부터 파생된다. 클래스 정의화일<undgrad.csc>는 이하와 같다.

클래스 정의 파일 : <undgrad.csc>

include<student.sc>

clss:

UnderGraduateStudent;

parent:

Stuent;

data:

char data[16]; /*졸업일 */

methods:

override printStudentInfo;

overrdie getStudentType;

void setUpUnderGraduateStudent(

char *id, char *name, char *date);

메쏘드 실행화일 <undgrad.c>는 이하와 같다.

클래스 메쏘드 실행화일 : <undgrad.c>

#define UnderGraduateStudent_Class_Source

#include "undgra.ih"

static void printStudentInho(

UnderGraduateStudent *somSelf)

{

UnderGraduatesStudentData *somThis=

UnderGraduateStudentGata(somSelf);

parent_printStudentInto(somSelf);

printf("Grad Date:%s ＼n",_date);

}

static char *getStudentType(UnderGraduateStudent)

*somSelf)

}

static char *type="UnderGraduat";

return(type);

}

static void setUpUnderGraduateStudent(

UnderGraduateStudent *somSelf, char *id, char

*name, char *date)

{

UnderGraduateStudentData *somThis=

UnderGraduateStudentGetData(somSelf);

_setUpStudent(somSelf, id, name);

strcpy(_date, dat);

}

클래스를 구축(building)하는 두 번째 기법은 구성(cinstrucution)이다. 구성은 다른 클래스를 사용하나, 상속을 거치지 않는 클래스를 가리킨다. 구성에 대한 좋은 예는 <Student>들에 대한 포인터의 배열을 포함하는 클래스 <Course>이다. 각각의 포인터는 코스(course)를 수강하고 있는 특정 스튜던트<Student>의 어드레스를 포함한다. <course>는 <Student>로부터 구성된다. <course>에 대한 클래스 정의화일 <course.csc>을 이하와 같다.

Class Definition File:<course.cac>

include<somobj.sc>

class:

Course;

parent:

SOMObject;

data:

char code[8]; /*수강코드번호

*/

char title[32]; /*수강제목 */

char instructor[32]; /*강사

teaching */

int credit; /*학점수

*/

int capacity; /*최대 좌석수

*/

Student *aaodentList[20]; /*enrolled student

int enrollment; /*등록학생수

*/

methods:

override somInit;

void setUpCourse(char *code, char, *title,

char *instructor, int credit, int capacity);

--sets up a new course.

int addStudent(Student *student);

--enolls a student to the course.

void dropStudent(char (studentId);

--drops the student from course.

void printCourseInfo( );

--prints course information.

종종 클래스는 그 인스턴스 데이터를 초기화시키기 위해 특별한 조치를 취하기를 원할 것이다. <course>의 인스턴스는 배열 인덱스 시작을 유효 상태로 하기 위해 적어도 <enrollment> 데이터 요소를 초기화시켜야 한다. 새로운 오브젝트가 생성될 때 메쏘드<somInit()>가 항상 호출된다. 이 메쏘드는 <SOMObject>로부터 상속되고, 오브젝트 초기화가 필요할 때 모버리든될 수 있다.

이와 같은 예는 파생된 베이스 클래스간에 "is-a"관계인 상속의 흥미있는 특징을 불러일으킨다. 파생된 어떤 클래스는 베이스 클래스로 간두될 수 있다. 파생된 클래스 "is-a"베이스 클래스라고 부른다. 상기 예에서, 어떤 <GraduateStudent> "is-a"<Student>이며, <Student>를 기재하는 어느 장소에서나 사용될 수 있다. 그 역은 성립할 수 없다. 베이스 클래스는 파생된 클래스가 아니다. <Student>는 <GraduateStudent>를 또는 <UnderGraduateStudent>들중에서 어느 하나를 가리킬 수 있다.

<course>에 대한 메쏘드 실행화일 <course.c>은 이하와 같다.

클래스 메쏘드 실행화일 : <course.c>

#define Course_Class_Source

#include<student.h>

#include "course.ih"

static void somInit(Course (somSelf)

{

CoruseData *somThis=CourseGetData(somSelf);

parent_somInit(somSelf);

_code[0]=_title[0]=_instructor[0]=0;

_credit=_capacity=_enrollment=0;

}

static void setUpCourse(Course *somSelf, char

*Code,

char *title, char *instructor, int credit,

int capacity)

}

CourseData *somThis=CourseGetData(somSelf);

strcpy(_code, code);

strcpt(_title, title);

strcpy(_instructor, instructor);

_credit=credit);

capacity=capacity);

}

static int addStudent(Course *somSelf, Student

*student)

{

CourseData *somThis=CourseGetData(somSelf);

if(_enrollemtn>=_capacity) return(-1);

_studentList[_enrollment++]=student;

reture(0);

}

static void dropStudent(Course *somSelf, cgar

*studentId)

{

int i;

CourseData *somThis=CourseGetData(somSelf);

for(i=0; i<_enrollemtn; i++)

if(!strcmp(studentId,

_getStudentId(_studentList[i]))) {

_enrollment--;

for(i; i<_enrollment; i++)

_studentList[i]=_studentList[i+1];

return;

} {

}

static void printCourseInfo(Course *somSelf)

{

int i;

courseData *somThis=CourseGetData(somSelf);

printf("%s %s ＼n", _code, _title);

printg("Instructor Name:%s ＼n",

_instructor);

printf("Credit-%d, Capacity=%d,

Enrollment=%d ＼n＼n",

_credit, _capacity, _enrollment);

pritf("STUDENT LIST:＼n＼n");

for(i=0, i<_enrollment; i++) {

_primtStudentInfo(_studentList[i]);

printf("＼n");

}

{

특히 메쏘드 <printCourseInfo()>를 주목하라, 이 메쏘드는 각 스튜던트상에 메쏘드 <pringStudentInfo()>를 호출하는 배열<StudentList>을 통과한다. 이 메쏘드는 <Student>에 한정된 다음, <GraduateStudent>와 <UnderGraduateStudent> 모두에 의해 오버리든된다. 배열 요소가 상기 세가지 클래스중 어느 한 개를 가르킬 수 있기 때문에 컴파일시 실제 타게트 오브젝트 형이 무엇인지 판단하기가 불가능하게, 타게트 오브젝트는 <Student> 혹은 <Student>로부터 파생된 몇가지 형중 하나로 되게 된다. 이 클래스 각각이 다른 <printStudentInfo()>메쏘드를 정의하기 때문에, 각 루프는 통과할 때 어느 메쏘드가 호출된 것인지를 판단하는 것이 불가능하다. 이것은 모두 오버라이드 레져루션의 제어하에 달려있다.

어떻게 하여 클라이언트가 프로그램에 있는 이와 같은 네 개의 클래스들을 이용하는가를 이해하기 위해, 파일<main.c>이하에 예가 제시되어 있다. 이 예는 SOM에서 오브젝트 인스턴스화 및 생성, 그리고 어떻게 해서 메쏘드가 호출되는지를 예시한다.

SOM 클라이언트 코드 : <main.c>

#include<student.h>

#include<course.h>

#include<graduate.h>

#include<undgrad.h>

main( )

{

Course *course=CourseNew( );

GraduateStudent *jana=GraduateStudentNew( );

UnderGraduateStudent *mak=

UnderGraduateStudentNew( );

_setUpCourse(coourse, "303", Compilers",

"Dr. David Johnson", 3, 15);

_setUpGraduateStudent(jane, "423538", Jane

Brown",

"Code Optimization", "Ph. D.");

_setUpUnderGraduateStudent(mark, "399542",

"Mark Smith", 12/17/92");

_addStudent(course, jane);

_addSTUDENT(course, mark);

_printCourseInfo(course);

}

클래스 메쑈드(className New()>와 함께 인스턴스화(is instantiated)되며, 이것은 인식된 각 클래스를 위하여 SOM에 의해서 자동적으로 정의된다. 메쏘드는 메쏘드 명칭앞에 밑줄 "_"을 위치시킴으로서 호출된다. 첫 번째 파라메타는 타게트 오브젝트이다. 나머지 파라메트들은 메쏘드에 필요한 부수적인 정보를 예시한다. 실행될 때, 클라이언트 프로그램은 이하와 같은 출력을 낸다.

Clint Program Output

303 Compilers

Instructor Name:Dr.David johnson

credit=3, Capacity=15, Enrollment=2

STUDENT LIST:

Id: 423538

Name: Jane Brown

Type: Graduate

Thesis: Code Optimization

Degree: Ph.D.

Id: 399542

Name: Mark Smith

Type: UnderGraduate

Grad Data: 12/17/92

크라이언트 프로그램 출력은 <UnderGraduate>과 <GraduateStudent>를 표시하는 다른 유형에서 동작하는 오버라이드 레져루션을 예시한다. <Course>는 그 자체를 <Student>의 배열을 포함하고 있는 것으로 생각하며, 어떤 <Student>가 <printStudentInfo()> 메쏘드에 응답하는 지를 안다. 그러나 <UnderGraduate>이 응답하는 <printStudentInfo()> 메쏘드는 <GraduateStudent>가 응답하는 <printStudentInfo()>와는 다르며, 이 두 메쏘드는 다른 출력을 낸다.

제2도는 본 발명에 따른 기본적인 SOM 데이터 구조도이다. 레이블(210)은 특정 모브젝트에 대한 스테이트 데이터 구조이다. 레이블(220)의 첫 번째 찬 우드(The first full word)는 오브젝트의 메쏘드 프로시저 테이블 레이블(240)의 어드레스를 포함한다. 레이블(230)에 제시된 나머지 스테이트 데이터 구조는 오브젝트와 관련된 부수적인 정보를 포함한다. 레이블(240)에 제시된 메쏘드 프로시저 테이블은 클래스 오브젝트 데이터 구조(245)의 어드레스와 특정 오브젝트(250과 260)에 대한 여러 가지 메쏘드의 어드레스를 포함한다. 245의어드레스는 클래슨 오브젝트 데이터 구조(248)을 가리킨다. 이 오브젝트와 동일한 클래스인 모든 오브젝트 역시 레이블(240)에 도시된 상기 메쏘드 프로시저 테이블을 가리키는 어드레스를 포함한다. 오브젝트에 의해 상속된 어떤 메쏘드들은 상속받는 조상 클래스(the ancestor class)의 레이블(240)에 제시된 것과 같이 그것들이 메쏘드 프로시저에 나타날 때 메모리의 동일한 오프셋에 그것들의 메쏘드 프로시저 어드레스를 가질 것이다.

두 개의 메쏘드 프로시저에 대한 일련의 명령을 포함하고 있는 컴퓨터 메모리 블록에 대한 어드레스는 레이블(250과 260)에 제시되어 있다. 레이블(270과 280)은 레이블(250과 260)로 표시된 어드레스에 의해 가리켜진 특정 메쏘드 프로시저에 대한 일련의 명령을 포함하고 있는 컴퓨터 메모리에서의 위치를 나타낸다.

대부분의 SOM 오브젝트 모델은 기본적인 SOM 지원의 일부인 세 개의 클래스로서 실행된다. 이 클래스에 대해 간략하게 설명한다 :

SOMObject-이 클래스는 모든 SOM클래스의 루트 클래스이다. 어느 클래스도 SOMObject로부터 승계되어야 한다. 모든 클래스들이 SOMObject로부터 승계되기 때문에 그들은 모두 상속하며 그리하여 SOMObject로 정의된 메쏘드를 지원한다. 어떤 SOM 클래스의 메쏘드와 같이 SOMObject의 메쏘드는 SOMObject로부터 승계된 클래스에 의해 오버리든될 수 있다.

SOMClass-이 클래스는 클래스 오브젝트를 관리하는 SOM을 기초로한 프로그램에서한개의 오브젝트를 생성하는 데 사용된다.

세개의 SOM 베이스 클래스는 이하에 정의되어 있다.

SOMObject

이것은 SOM 루트 클래스이다. 모든 SOM 클래스들은 <SOMObject>로부터 반드시 승계되어야 한다. <SOMObject>는 인스턴스 데이타를 갖지 않으므로 그것으로부터 승계되는 데에는 인스턴스마다 비용이 들지 않는다.

SOMObject는 다음과 같은 메쏘드를 갖는다 :

메쏘드 : somInit

파라메타 : somSelf

복귀 : void

설명 :

<self>를 초기화 <SOMObject>의 인스턴스가 어떤 인스턴스 데이타도 갖지 않기 때문에 초기화시킬 아무것도 존재하지 않으며 그리고 이 메쏘드를 호출할 필요가 없다. 초기화를 필요로 하는 서브클래스들간에 일관성을 유지하기 위해 제공된다.

<SOMInit>은 오브젝트 생성(즉, <somNew>에 의해)의 부작용으로서 자동적으로 호출된다. 만약 이 효과가 바람직하지 않다면, <somInit>를 호출하지 않는 스스로 만든 <somNew> 버젼(사용자가 작성한 메타 클래스에서)을 공급할 수 있다.

이 메쏘드를 오버라이드할때 자신을 초기화하기 전에 이 메쏘드의 부모클래스 버젼을 항상 호출하여야 한다.

메쏘드 : somUninit

파라메타 : somSelf

복귀 : void

설명 :

(자신을 초기화시키지 않음) <SOMObject>의 인스턴스는 어떤 인스턴스 데이타도 가지고 있지 않기 때문에 초기화 시키지 않을 어떤것도 없으며 이 메쏘드 호출할 필요가 없다. 초기화시키지 않을 것을 필요로 하는 서브클래스간에 일관성을 유지하기 위해 제공된다.

이 메쏘드를 사용하여 동적으로 할당된 기억 장치와 같이 요구되는 어떤것도 클린업(clean up)한다. 그러나 이 메쏘드는 오브젝트 인스턴스에 할당된 실기억 장치를 해제하지 않는다. 이 메쏘드는 동적으로 할당된 오브젝트와 연관된 기억 장치를 역시 해제하는 <somFree>에 대한 보충(a complement)으로서 제공된다. 통상적으로 항상 <someUninit>을 호출하는 <somFree>를 호출할 것이다. 그러나, <somRenew>을 (SOMClass>의 정의를 참조) 오브젝트 인스턴스를 생성하는데 사용하는 경우에, <somFree>는 호출될 수 없고 명시적으로 <someUninit>를 호출할 것이다.

이 메쏘드는 <somRenew>(<SOMClass>의 정의를 참조)에 의해서 생성된 오브젝트에 대해서 호출되어야 하며 결코 <somRenew>에 의해 생성된 오브젝트에 대해서 호출되어서는 안된다.

이 메쏘드는 오버라이드할 필요가 없을 것이다(대신에 <someUninit>를 오버라이드한다)

메쏘드 : somGetClassName

파라메타 : somSelf

복귀 : zstring

설명 :

이 오브젝트의클래스 명칭에 대한 포인터를 NULL 종료 스트링으로서 복귀시킨다. 그것이 명칭을 얻기 위해 클래스 오브젝트의 메쏘드(<somGetClassName>)를 단지 호출하였기 때문에 이 메쏘드를 오버라이드하는 것은 필요하지 않다.

메쏘드 : somGetClass

파라메타 : somSelf

복귀 : SOMClass*

설명 :

이 오브젝트의 클래스 오브젝트를 복귀시킨다.

메쏘드 : somGetSize

파라메타 : somSelf

복귀 : integer4

설명 :

이 인스턴스의 크기를 바이트로 복귀시킨다.

메쏘드 : somRespondsTo

파라메타 : somSelf

복귀 : integer4

설명 :

이 인스턴스의 크기를 바이트로 복귀시킨다.

메쏘드 : somRespondsTo

파라메타 : somSelf, somId Mid

복귀 : int

설명 :

만약 표시된 메쏘드가 이 오브젝트의 클래스에 의해 지원된다면 1(참)을 복귀시키고 그렇지 않으면 0(거짓)을 복귀시킨다.

메쏘드 : somIsA

파라메타 : somSelf, SOMClass*Aclassobj

복귀 : int

설명 :

만약 <self>의 클래스가 <Aclassobj>의 후손 클래스라면 1(참)을 그렇지 않다면 0(거짓)을 복귀시킨다.

주의 : 클래스 오브젝트는 이 메쏘드의 목적으로 그 자신의 후손으로 간주된다.

메쏘드 : somIsInstanceOf

파라메타 : somSelf, SOMClass*Aclassobj

복귀 : int

설명 :

만약 <self>의 클래스가 <Aclassobj>이라면 1(참)을 그렇지 않다면 0(거짓)을 복귀시킨다.

동적인 오브젝트 모델을 지원하는 SOMObject 메쏘드 이 메쏘드는 SOM 오브젝트 프로토콜 경계로 바이딩하기 위해 매우 동적인 영역(very dynamic domains)을 용이하게 만든다. 이 메쏘드는 디폴트 실행을 메쏘드를 명칭으로 간단히 참조(look up)하여 호출한다. 그러나, 다른 클래스는 그들이 원하는 다른 참조형을 실행하기 위해 선택할 수 있다. 예로, 사용자는 메쏘드 레저루션 CLOS 형식을 사용한 이 메쏘드의 실행을 제공할 수 있다.

그것이 가능한 영역에 대해서 통상적으로 디스패치 메쏘드를 거치는 것보다 직접 그 메쏘드를 호출하는 것이 훨씬 빠를 것이다. 그러나, 모든 메쏘드는 디스패치 메쏘드(the dispatch methods)를 거쳐서 도달할 수 있다. SOM은 호출자가 결코 메쏘드 레저루션을 할 필요없이 이 메쏘드 호출을 랩(wrap)하는 작은 세트의 외부 프로시저를 제공한다.

이 메쏘드는 가변길이 인수리트를 취하도록 선언되지만, 이러한 모든 메쏘드와 같이 SOM오브젝트 프로토콜 경계는 인수리스트의 가변부분이 메쏘드가 실제로 호출되기 전에 표준이며, 플랫폼에 특정한 가변인수 리스트에 대한 데이타 구조속으로어셈블리된 것을 요구한다. 이것은 실행시 인수리스트를 구성하는데 필요한 영역에서 매우 유용할 수 있다. 호출하기 위해 정식(the normal form)으로 구성된 인수를 탐색할 필요없이 메쏘드를 호출할 수 있다. 이러한 동작은 통상적으로 대부분의 고급 언어에서는 불가능하고 그리고 플랫포에 특정한 어셈블러 언어 루틴(platform-specific assembler language routines)이 사용되어야 하기 때문에 유용하다.

주의 : 다른 복귀값형에 대해서는 다른 메쏘드가 정의된다. 이것은 만약 복귀값으로 운반하는데 추가적인 파라메타들이 요구된다면 몇몇 영역에서 일어날 수 있는 메모리 관리상의 문제를 피할 수 있다. SOM은 이하에 도시된 네개의 패밀리(the four families)를 제외하고 복귀값을 지원하지 않는다. 패미리(정수같은)내에서 SOM은 단지 가장 큰 멤버만을 지원한다.

메쏘드 : somDispatchV

파라메타 : somSelf, somId methodId, somId descriptor,…

복귀 : void

설명 :

값을 복귀시키지 않는다.

메쏘드 : somDispatchL

파라메타 : somSelf, somId methodId, somId descriptor

복귀 : integer4

설명 :

정수 데이타가 복귀되는 정상적인 방법으로 4바이트 크기를 복귀시킨다. 이 4바이트 크기는 물론 정수이외의 어떤 것일 수 있다.

메쏘드 : somDispatchA

파라메타 : somSelf, somId methodId, somId descriptor

복귀 : void*

설명 :

이 데이타가 복귀되는 정상적인 방법으로 데이타 구조 어드레스를 복귀시킨다.

메쏘드 : somDispatchD

파라메타 : somSelf, somId methodId, somId descriptor

복귀 : float8

설명 :

부동소수점 데이타가 복귀되는 정상적인 방법으로 8바이트 크기를 복귀시킨다.

개발을 지원하는 SOMObject 메쏘드

이 그룹의 메쏘드들은 프로그램 개발을 지원하기 위해 제공된다. 이것들은 대부분의 개발 콘덱스트(most development contexts)가 그것들을 사용하기 쉽도록 정의되어 있다. 그러나, 몇몇 콘텍스트들은 그것들의 I/O장치를 커스텀화(customize)할 필요가 있을 수 있다. 이 커스텀화를 매우 호환성있게 제공하려 시도하고 있으나 모든 콘텍스트들이 커스텀화 동작을 직접 수행할 수 없는데 이것은 함수 파라메타의 전달을 필요로 하기 때문이다. 이것이 플랫폼-중립적인 유연성을 제공하기 때문에 이러한 해결책을 선택하였으며 그리고 우리는 어떤 개발지원 제공자도 특수한 개발환경에 필요한 커스텀화를 제공하는 것이 바람직하다고 생각하는 것을 알았다.

선택된 접근책은 캐릭터 루틴에 달려있다. 외부변수 <SOMOutCharRoutine>은 상기 루틴을 가리킨다. SON 환경은 대부분의 개발환경(이것은 표준 출력 스트림에 작성한다)에서 작동할 루틴의 실행을 제공한다. 그러나, 개발 콘텍스트는 새로운 값을 <SOMOutCharRoutine>에 할당하며 그리하여 그것에 의해 출력 프로세스를 재정의한다. SOM은 이러한 형태에 대해 특별한 지원을 제공하지 않는다.

메쏘드 : somPrintSelf

파라메타 : somSelf

복귀 : SOMAny*

설명 :

<SOMOutCharRoutine>을 사용하여 상기 오브젝트에 대한 정보를 식별하는 간단한 스트림을 작성한다. 디폴트 실행은 단지 오브젝트의 클래스 명칭과 메모리내의 그 어드레스만을 부여한다. <self>가 복귀된다.

메쏘드 : somDumpSelf

파라메타 : somSelf, int level

복귀 : void

설명 :

<SOMOutCharRoutine>을 사용하여 상기 오브젝트에 대한 정보를 식별하는 간단한 스트림을 작성한다.

<level>은 0보다 반드시 크거나 또는 같은 혼합 오브젝트(compound objects)를 설명하기 위한 네스팅 레벨(the nesting level)을 가르킨다. 설명에 있는 모든 라인들은 <2*level>공간이 붙어있을 것이다.

이 루틴만이 클래스와 같이 대체로 오브젝트에 관련하는 데이타를 실제로 작성하며, <somDumpSellfInt>를 사용하여 오브젝트의 현재 상태를 설명한다. 이러한 접근책은 판독가능한 혼합 오브젝트에 대한 설명을 구성하는 것을 가능케 한다.

일반적으로 상기 메쏘드를 오버라이드 하는 것은 필요하지 않고, 만약 오버라이드 된다면 총체적으로 완전히 교체되어야만 한다.

메쏘드 : somDumpSelfInt

파라메타 : somSelf, int level

복귀 : void

설명 :

<SOMOutCharRoutine>사용하여 상기 오브젝트에 대한 현재상태를 작성(write out)한다. 전반적으로 상기 메쏘드는 오버라이드될 필요가 있을 것이다. 그것을 오버라이드할때, 상기 메쏘드의 부모콜래스 형식을 호출하여 시작하고 다음에 자기자신의 클래스의 인스턴스 데이타에 대한 설명을 작성한다. 이것으로서 그 루트 조상클래스로부터 그것의 특정한 클래스에 이르는 모든 클래스의 인스턴스 데이타에 대해서 설명하는 결과과 될 것이다.

SOMClass

이것은 SOM 메타크래스이다. 즉, 상기 클래스의인스턴스는 클래스 오브젝트이다. SOM 환경이 생성될 때 외부 명칭 <SOMClassClassData.classObject>를 갖는 상기 클래스에 대한 한개의 인스턴스가 생성된다. 이 클래스 오브젝트는 그것이 그 자신의 클래스 오브젝트이기 때문에 유일(unique)한다.

즉, SOMClassClassData.classObject==

-somGetClass(SOMClassClassData.classObject>. 이 클래스는 SOM 오브젝트의 새로운 인스턴스를 생성하는데 사용되는 sonNew와 SOMRenew 메쏘드들을 소개한다. <SOMClassClassData.classObject>에 적용된 somNew는 특수한 새로운 클래스가 되도록 초기화될 수 있는 새로운 클래스 오브젝트를 만든래스는 새로운 메카클래스들이며 <SOMClassClassData.classObject>에 의해 만들어진 것들 보다 다른 실행을 갖는 클래스 오브젝트를 생성할 수 있다.

SOMClass는 SOMObject으로부터 전해진다.

SOMClass는 다음과 같은 메쏘드들을 정의한다.

메쏘드 : somNew

파라메타 : somSelf

복귀 : SOMAny*

설명 :

상기 클래스의 인스턴스를 만든다. <SOMClassClassData.classObject>에 또는 어떤 다른 메타크래스 오브젝트에 적용되었을때, 이것은 새로운 클래스 오브젝트를 만들것이다 ; 정류클래스 오브젝트(a regular class object)에 적용되었을때, 이것은 그 클래스의 인스턴스를 만들 것이다.

메쏘드 : somRenew

파라메타 : somSelf, SOMAny*obj

복귀 : SOMAny*

설명 :

상기 클래스의인스턴스를 만든다. 하지만 상기 오브젝트에 대한 새로운 공간을 할당하기 보다는 <obj>에 의해서 가리켜진 공간을 사용한다.

주 : <obj>가 확실히 충분한 공간을 가리키는 지에 대해 테스트되지 않는다. <obj>가 복귀된다. 그러나 그것은 유효하고 초기화된 오브젝트에 대한 지금 현재의 포인터이다.

메쏘드 : somClassReady

파라메타 : somSelf

복귀 : void

설명 :

상기 메쏘드는 클래스에 대한 모든 정적 초기화가 끝났을때 호출된다. 디폴트 실행은 SOMClassMgr으로서 새롭게 구성된 클래스를 단순히 등록한다. 메타클래스는그들이 원하는 어떤 방법으로 클래스 구성시이퀸스를 보강하기(augment)위해 상기 메쏘드를 오버라이드할 수 있다.

메쏘드 : somGetName

파라메타 : somSelf

복귀 : Zstring

설명 :

NULL 종료 스트림으로서 상기 오브젝트의 클래스 명칭을 복귀시킨다.

메쏘드 : somGetParent

파라메타 : somSelf

복귀 : SOMClass*

설명 :

만일 존재한다면 자시의 부모클래스를 그렇지 않다면 NULL을 복귀시킨다.

메쏘드 : somGetClassData

파라메타 : somSelf

복귀 : somGetClassDataStructure*

설명 :

정적 <className> classData 구조에 대한 포인터를 복귀시킨다.

메쏘드 : somGetClassData

파라메타 : somSelf, somGetClassDataStructure*cds

복귀 : viod

설명 :

정적 <className> classData 구조에 대한 클래스의 포인터를 세트한다.

메쏘드 : somDescendekrom

파라메타 : somSelf, SOMClass*Aclassobj

복귀 : int

설명 :

민약 <self>가 <Aclassobj>의 후손이라면 1(참)을 그렇지 않다면 0(거짖)을 복귀한다.

주의 ; 클래스 오브젝트는 상기 메쏘드의 목적으로 그 자체가 후손되는 것으로 간주된다.

메쏘드 : somCheckVersion

파라메타 : somSelf, integer4 majorVersion, integer4 mimorVersion

복귀 : int

설명 :

만약 상기 클래스의 실행이 지정된 메이저 및 마이너 버전번호(the specified major and minor version number)와 양립(be compatible with)한다면 1(참)을 그리고 그렇지 않다면 0(거짖)을 복귀시킨다. 만약 그것이 메이저 버전번호와 <minorVersion>과 같거나 또는 마이너 버전번호를 가지고 있다면 구현하는 것은 지정된 버전번호와 양립할 것이다. 메이저, 마이너 버전번호 쌍(0, 0)은 어느 버전도 부합(match)하는 것으로 간주된다. 상기 메쏘드는 동적으로 로드된 클래스 정의와 사용하는 응용프로그램이 양립하는 것을 증명하기 위해 클래스 오브젝트를 생성한 직후에 통상적으로 호출된다.

메쏘드 : somCheckVersion

파라메타 : somSelf, integer4 majorVersion, integer4 mimorVersion

복귀 : int

설명 :

만약 상기 클래스의 실행이 지정된 메이저 및 마이너 버전번호(the specified major and minor version number)와 양립(be compatible with)한다면 1(참)을 그리고 그렇지 않다면 0(거짖)을 복귀시킨다. 만약 그것이 메이저 버전번호와 <minorVersion>과 같거나 또는 큰 마이너 버전번호를 가지고 있다면 구현하는 것은 지정된 버전번호와 양립할 것이다. 메이저, 마이너 버전번호 쌍(0,0)은 어느 버전도 부합(match)하는 것으로 간주된다. 상기 메쏘드는 동적으로 로드된 클래스 정의와 사용하는 응용프로그램이 양립하는 것을 증명하기 위해 클래스 오브젝트를 생성한 직후에 통상적으로 호출된다.

메쏘드 : somFindMethod

파라메타 : somSelf, somId methodId, somMethodProc*m

복귀 : int

설명 :

상기 클래스에 대해 <methodId>와 연관된 메쏘드 프로시저를 찾아 그것에 <m>을 세트시킨다. 메쏘드 프로시저가 직접 호출가능할때 1(참)이 복귀되고 메쏘드 프로시저가 디스패치 함수일때 0(거짖)이 복귀된다.

만약 클래스가 지정된 메쏘드를 지원하지 않는다면 이때 <m>이 NULL로 세트되고 복귀값은 의미가 없다.

디스패치 함수를 복귀하는 것은 클래스가 지정된 메쏘드를 지원하는 것을 보장하지 않는다 ; 디스패치는 실패할 것이다.

메쏘드 : somFindMethodOK

파라메타 : somSelf, somId methodId, somMethodProc*m

복귀 : int

설명 :

그것을 제와한 <somFindMethodOK>와 똑같이 만약 메쏘드가 지원되지 않는다면 이때 에러가 제기되어 실행이 중지된다.

메쏘드 : somFindMethod

파라메타 : somSelf, somId methodId

복귀 : somMethodProc*

설명 :

상기 클래스를 위하여 정위된 정적 메쏘드임에 틀림이 없는 지시된 메쏘드(the indicated method)를 찾아, 그 메쏘드는 프로시저에 대한 포인터를 복귀시킨다. 만약 상기 클래스를 위해 메쏘드가 정의되지 않았다면(정적 메쏘드로서 또는 존재한다면)이때 NULL 포인터가 복귀된다.

메쏘드 : somFindMethodOK

파라메타 : somSelf, somId methodId

복귀 : somMethodProc*

설명 :

그것을 제외한 <somfidnSmethod>와 똑같이 만약 상기 클래스를 위해 메쏘드가 정의되지 않았다면 에러가 제기된다.

메쏘드 : somFindMethod

파라메타 : somSelf, somId Mid

복귀 : int

설명 :

상속된 메쏘드(정적 그리고 동적 모두)를 포함하는 상기 클래스에 의해 현재 지원도니 메쏘드의 수를 복귀시킨다.

메쏘드 : somGetInstanceSize

파라메타 : somSelf

복귀 : integer4

설명 :

상기 클래스에 속하는 인스턴스 데이타를 위해 상기 오브젝트의 몸체부분(the body part)에 있는 오프셋을 복귀시킨다.

메쏘드 : somGetInstancePartSize

파라메타 : somSelf

복귀 : integer4

설명 :

상기 클래스에 요구된 인스턴스 데이타의 바이트 크기를 반환한다. 이것은 상기 클래스의 조상 또는 후손 클래스에 요구된 인스턴스 테이타 공간을 포함하지 않는다.

메쏘드 : somGetNumStaticMethods

파라메타 : somSelf

복귀 : int

설명 :

상기 클래스가 각기 갖는 정적 메쏘드의 수를 복귀시킨다. 이것은 그것의 메쏘드 테이블을 초기화시키는데 있어서 지시클래스에 의해 사용된다.

메쏘드 : somGetPclsMtab

파라메타 : somSelf

복귀 : somMethodTab*

설명 :

상기 클래스의 부모클래스의 메쏘드 테이블에 대한 포인터를 복귀시킨다. 만약 이 클래스가 루트클래스(SOMObject)라면 이때 NULL이 복귀된다.

메쏘드 : somGetPclsMtab

파라메타 : somSelf

복귀 : somMethodTab*

설명 :

상기 클래스의 메쏘드 테이블에 대한 포인터를 반환한다.

메쏘드 : somAddStaticMethod

파라메타 : somSelf, somId methodId, somId methodDescriptor, somMethodProc*method, somMethodProc*redispatchStub, somMethodProc*applystub

복귀 : somMoffset

설명 :

지시된 메쏘드를 더하거나/오버라이드하며,상기 메쏘드는 명칭을 위한 클래스 데이타 구조에 오프셋 값을 세트시키기 위해 사용되어야 할 값을 반환한다.

<methodDescriptor>는 SOMObject 클래스 정의에 정의된 <somGetNthMethodInfo>에 설명된 것과 같이 상기 메쏘드에 대한 호출 순서를 설명하는 스트링에 대한 somId이다.

<method>는 상기 메쏘드에 대한 실제 메쏘드는 프로시저이다.

<redispatchStub>는 상기 클래스의 디스패치 함수중 한개로 상기 메쏘드를 다시 디스패치하는 <method>와 같이 동일한 호출순서(the same calling sequence)를 갖는 프로시저이다.

<applyStub>는 데이타 구조로부터 파생된 인수를 갖는 <method>를 호출함으로서 그것을 타게트 오브젝트에 적용하는 표준 변수 인수리스트 데이타 구조를 취한 프로시저이다. 그것이 호출순서는 SOMObject에 정의된 디스패치 메쏘드의 호출순서와 같다. 이 스터브는 몇몇 클래스에 사용된 디스패치 메쏘드의 지원에 사용된다. 디스패치 함수가 이와 같은 함수를 필요로 하지 않는 클래스에 있어서 이 파라메타는 널(nell)일 수 있다.

메쏘드 : somOverrideSMethod

파라메타 : somSelf, somId methodId, somMethodProc*method,

복귀 : void

설명 :

상기 메쏘드는 상기 클래스의 부모클래스가 이미 상기 메쏘드를 지원한다는 것에 알려졌을때 <somAddStatocMethod> 또는 <somAddStatocMethod>대신에 사용될 수 있다. 이 클래스는 다른 클래스들이 필요로 하는 메쏘드 기술자와 스터브 메쏘드(the method descriptor and Stub methods)를 필요로 하지 않는다.

메쏘드 : somGetInstanceOffset

파라메타 : somSelf, somId methodId

복귀 : integer4

설명 :

이것이 정적 메쏘드라고 가정하는 메쏘드 프로시저 테이블에 있는 지정된 메쏘드 오프셋을 반환하고, 만약 그것이 아니었다면 0을 반환한다. 이 값은 상기 클래스 데이타 구조에 오프셋 값을 세트시키는데 사용된다. 클래스가 지금현재 상속하는 메쏘드를 정의하기 위해 사용하였을 때만이 상기 메쏘드를 사용할 필요가 있을 것이다.

메쏘드 : somGetAppplystub

파라메타 : somSelf, somId methodId

복귀 : somMethodProc*

설명 :

지정된 메쏘드와 연관된 어플라이 스터브(the apply stub)를 반환한다. 만약 상기 클래스에 의해 메쏘드가 지원되지 않는다면 NULL이 반환된다. 어플라이 스터브는 정해진 호출순서(a fixed calling sequence), 즉 <ap>가 메쏘드로 전달될 실제 인수리스트를 포함하는 varargs 데이타 구조(SOMAny*self, somId methodId, somId descriptor, ap=list up)로서 호출되는 프로시저이다. 어플라이 스터브는 호출을 그것의 연관된 메쏘드로 진행시킨 다음 메쏘드에 의해 만들어진 어떤 결과를 반환한다.

SOMClassMgr

SOMClassMgr은 SOMObject의 후손이다. SOMObject는 다음과 같은 메쏘드들을 정의한다.

메쏘드 : somFindclsInFile

파라메타 : somSelf, somId method, int majorVersion, int minorVersion, Zstring file

복귀 : SOMClass*

설명 :

지정된 클래스에 대한 클래스 오브젝트를 반환한다. 이것의 결과로 동적 로딩(dynamic loading)이 될 수 있다. 만약 클래스가 이미 존재한다면 <file>이 주시되고, 그렇지 않다면 이것은 클래스를 탐색하여 동적으로 로드시키는데 사용된다. 메이저와 마이너 버전번호에 대한 0의 값은 비전검사를 바이패스 한다.

메쏘드 : somFindclsInFile

복귀 : SOMClass*

설명 :

지정된 클래스에 대한 클래스 오브젝트를 반환한다. 이것의 결과로 동적 로딩이 될 수 있다. somFindclsInFile를 사용하여 클래스의 코드가 놓여있는 화일의 명칭을 얻은 다음 somFindclsInFile을 사용한다.

메쏘드 : somClassFromId

파라메타 : somSelf, somId methodId

복귀 : SOMClass*

설명 :

만약 크래스 오브젝트 Id가 이미 존재한다면 클래스 오브젝트를 찾는다. 그 클래스를 로드하지 않는다. 만약 크래스 오브젝트가 아직 존재하지 않는다면 NULL을 반환한다.

메쏘드 : somRegisterclass

파라메타 : somSelf, SOMClass*classobj

복귀 : void

설명 :

클래스 매니저에게 지정된 크래스가 인스톨되었다는 것을 알려주고 클래스 오브젝트가 있는 곳을 가르켜 준다.

메쏘드 : somUnregisterClass

파라메타 : somSelf, SOMClass*classobj

복귀 : int

설명 :

클래스 화일을 언로드(unloads)하고 SOM 등재부(registry)로부터 그 클래스를 제거한다.

메쏘드 : somLocateClassFile

파라메타 : somSelf, somId methodId, int MajorVersion, int minorVersion, Zstring file

복귀 : SOMClass*

설명 :

클래스의 코드를 로드하고 클래스 오브젝트를 초기화 시킨다.

메쏘드 : somUnregisterClassFile

파라메타 : somSelf, SOMClass*classobj

복귀 : int

설명 :

클래스 코드를 해제(Release)하고 클래스 오브젝트를 제거한다.

메쏘드 : somGetInitFunction

파라메타 : somSelf

복귀 : Zstring

설명 :

클래스의 코드 화일에 초기화 함수의 이름을 제공한다. 디폴트 실행은 (*SOMClassInit FuncName)을 반환한다.

본 발명은 각각의 클래스 실행과 연관된 특별한 프로시저를 경유하여 실행시 클래스 메쏘드 테이블을 초기화시키며 그리고 메쏘드 오프셋 세트를 외부에서 명명된 한개의 클래스 데이타 구조(a single externally named class data structure)로 집합(collecting)시킴으로서 클래스의 모든 메쏘드에 대해 독특한 외부 명칭을 필요로 하는 과저의오브젝트 지향기법을 향상시킨다. 이렇게 향상시킴으로서 커다란 외부변수 리스트를 관리하는 복잡성을 감소시키고, 독특한 명칭(명칭 맹글링(name mangling)이라고 한다)을 생성할 문제를 줄이며, 메모리의 필요성 및 생성된 실행 모듈의 로드 시간을 감소시킨다.

제3도는 본 발명에 따른 SOM 클래스 데이타 구조이다. 레이블(310)은 제2도에 248로 제시된 클래스 오브젝트 데이타 구조에 대한 포인터를 표시한다. 레이블(320)은 제2도에서 레이블(240)에 제시된 메쏘드 프로시저 테이브에의 혹은 제2도에서 레이블(230)에 제시된 오브젝트의 스테이트 데이타 구조에의 오프셋을 표시한다. 유사하게, 레이블(330과 340)은 메쏘드 프로시저 테이블 또는 그 스테이트 데이타 구조로의 부수적인 오프셋을 표시한다. 상기 클래스에서 최초로 정의된 부수적인 메쏘드 또는 클래스 해제순서부분(the class release order section)에 언급되지만 클래스의 조상클래스중 한개의 의해 정의되는 메쏘드, 또는 상기 클래스에 의해 정의된 공용변수들을 위해, 타원과 테이블(350)에서 "N⁺¹"로 의미를 나타낸 것과 같이 상기 클래스와 연관된 오프셋을 표시하는 클래스 데이타 구조에 유사한 엔트리가 존재한다. 부수적인 엔트리가 필요한데 이것은 제1엔트리가 제2도에서 클래스 오브젝트 데이타 구조(248)에 대한 포인터를 표시하기 때문이다.

클래스 데이타 구조에 있는 값의 순서는 대응하는 메쏘드 또는 클래스 OIDL 화일의 해제순서부분에 있는 공용 인스턴스 변수 명칭의 순서에 의해 결정된다. 메쏘드 또는 클래스에 정의되었지만 해제순서부분에 언급되지 않은 공용 데이타 멤버는 해제순서부분과 클래스 OIDL 화일에 보이는 순서로 언급된 것의 이후에 순서가 정해진다.

오브젝트 인터페이스 정의 언어(OIDL)

본 발명은 어떤 언어에 대한 오브젝트 지원이 제공되는 중립 세트의 정보(a neutral set of information)로서 언어 의존성 오브젝트 정의(Language dependent object definitions)를 재정의한다. 중립세트의 정보를 SOM에서 오브젝트 인터페이스 정의 언어(an Object Interface Definition Language(OIDL)) 정의라고 부른다.SOM OIDL은 프로그래밍 언어의 사용을 가능하게 하는 바인딩 화일(binding files)을 생성하는데 필요한 기초를 제공하며 SOM 오브젝트 및 그것의 정의(클래스라 부른다)를 제공한다. 각각의 OIDL 화일은 SOM 오브젝트 클래스에 대한 완전한 인터페이스(the complete interface)를 정의한다.

OIDL 화일은 언어에 따라 형식이 다르다. 형식이 다름으로서 클래스 실행자는 SOM 컴파일러로 하여금 클래슬르 구성하는데 필요한 지원을 제공할 수 있게 하는 부수적인 언어-특정 정보(additional language-specdific ingormation)를 규정할 수 있다. 이와 같은 각각의 다른 형식은 사용자가 클래스의 사용법을 반드시 알아야 하는 정확한 정보를 규정하는 공통의 핵심언어(a common core language)를 공유한다. SOM 컴파일러의 장점중 하나는 클래스 정의에 대한 공통의 핵심부분을 발췌하는 것이다. 그리하여, 클래스 실행자는 클래스에 대한 언어-특정 OIDL 화일을 유지하며, SOM 컴파일러를 사용하여 필요하다면 언어-중립 핵심 정의를 만들 수가 있다.

이 부분은 C-언어 프로그래밍을 지원하기 위해 확장자를 갖는 OIDL을 설명한다. 상술된 것과 같이, OIDL 화일은 한 세트의 언어-특정한 또는 사용-특정한 바인딩 화일을 만들기 위해 SOM 컴파일러에 의해 컴파일된다.

SOM 컴파일러는 C언어에 대해 일곱가지의 다른 화일들을 만든다.

·클래스를 사용하는 프로그램을 위한 공용헤더화일, 클래스의 사용은 클래스의인스턴스 오브젝트를 생성하고, 인스턴스 오브젝트에 대한 메쏘드를 호출하며 그리고 새로운 클래스를 만들기 위해 상기 클래스를 서브클래스(subclassing)하는 것을 포함한다.

·전용헤더화일, 이것은 클래스가 가질 수 있는 어떤 전용 메쏘드에 대한 사용상의 바인딩(usage bindings)을 제공한다.

·실행헤드화일, 이것은 마이크로와 클래스의 실행을 지원하기 위한 다른 것들을 제공한다.

·실행 템플리트(An implementation template), 이것은, 클래스 제공자가 편집할 수 있는 클래스 실행에 대한 개요를 제공한다.

· 언어-중립의 핵심정의

·전용언어-중립의 핵심화일, 이것은 클래스 인터페이스에 대한 전용부분을 포함한다.

·OS/2 DLL의 형식으로 클래스를 패키지하는데 사용될 수 있는 OS/2 . DEF화일.

OIDL 화일은 다음과 같은 부분을 포함할 수 있다.

·인클루드부분 ;

·클래스부분 ;

·해제순서(Release Order)부분 ;

·부모클래스부분 ;

·패스스루(Passthru)부분 ;

·데이타부분 및

·메쏘드부분

인클루드부분(Include Section)

이 부분은 상기 클래스의 부모클래스에 대한 클래스 인터페이스 정의, 만약 클래스가 한개를 규정한다면 클래스이 메타클래스 그리고 상기 클래스가 한개 이상의 그 전용 메쏘드를 오버라이드하기 위한 어떤 조상클래스에 대한 전용 인터페이스 화일을 찾을 곳을 컴파일러에 가르쳐주는 OIDL 전처리기에 대한 지시문인 인클루드문을 포함한다.

클래스부분(Class Section)

이 부분은 그 명칭, 속성 및 대체로 선택적으로 클래스에 대한 설명을 제공하는 클래스를 유입(introduces)한다.

해제순서부분(Release Order Section)

이 선택적인 부분은 컴파일러에게 규정된 순서로 배열된 항목을 갖는 어떤 임계 데이타 구조(certain critical data structures)를 형성하게 하는 해제순서문을 포함한다. 이것은 이 클래스를 사용하는 프로그램이 다시 컴파일될 필요없이 클래스 인터페이스 및 실행이 진행(to be evolved)되게 한다.

해제순서는 모든 메쏘드 명칭과 공용 데이타 항목에 적용(applies to)된다. 만약 몇몇 메쏘드 또는 공용 데이타 항목의 해제순서가 지정되어 있지 않았다면, OIDL 화일에서 발생하는 것에 따라 실행-규정 순성로 디폴트할 것이다. 새로운 공용 데이타 항목 또는 메쏘드의 유입(The introduction)으로 다른 공용 데이타 항목 또는 메쏘드의 디폴트 순서가 변하게 된다. ; 이때 이 클래스를 사용하는 프로그램은 다시 컴파일 될 필요가 있을 것이다.

메타클래스부분(Metaclass section)

이 선택적 부분은 그 명칭 및 선택적으로, 메타클래스에 대한 이유의 설명, 또는 그 클래스의 인터페이스에서의 그 역할에 대한 다른 주석을 제공하는 클래스의 메타클래스가 규정되었다면, 그것의 정의는 인클루드부분에 반드시 포함되어야 한다. 만약 아무런 메타클래스도 규정되지 않았다면, 이 클래스의 부모클래스에 대한 메타클래스가 사용될 것이다.

클래스의 메타클래스는 또한 데이타 부분의 클래스 속성과 메쏘드부분의 클래스 속성을 결합 사용하여 묵시적으로 정의돌 수 있다. 마약 이 속성들중 어느 하나가 사용된다면, 이때 메타클래스부분은 반드시 바이패스(be bypassed)되어야 한다. 이 경우, 내포된 메타클래스(the implied metaclass)는 부모클래스에대한 메타클래스의 서브클래스일 것이다.

부모클래스부분(Parent class section)

이 부분은 그 명칭과 선택적으로상기 클래스의 인터페이스에서 부모클래스의 역할에 대한 설명을 표시함으로서 클래스의 부모클래스를 규정한다.

패스스루(Passthru section)

이 부분은 컴파일러에 의해 여러 바인딩 화일(various binding files)속으로 패스될 코드의 블럭을 제공한다. 패스된 정보의 내용은 컴파일러에 의해 무시된다. 심지어 패스스루 라인에 포함된 주석들도 변경되지 않고 처리된다.

데이타부분(Data section)

이 부분은 상기 클래스에 대한 인스턴스 변수들을 리스트한다. 이 부분은 일반적으로 클래스 인터페이스정의(.csc 화일)의 언어 특정 버전에만 존재한다. 그러나, 만약 클래스가 공용 인스턴스 연수들을 포함하고 있다면 클래스 인터페이스 정의의 공용형식으로 반드시 존재하여야 한다. ANSI C 구문은 이 변수들을 설명하는데 사용된다.

메쏘드부분(Methods section)

이 부분은 상기 클래스로 지원되는 메쏘드들을 리스트한다. ANSI C 함수 프로토타입 구문은 각 메쏘드에 대한 호출 시이퀀를 정의하는데 사용된다.

SOM 컴파일러

SOM 컴파일러는 SOM 크래스에 대한 OIDL 소스 정의를 특정 프로그래밍 언어에 적합한 한 세트에 바인딩(a set of bindings)으로 번역한다. OS/2.0 개발도구가 공급된 SOM 컴파일러는 C 프로그래밍 언어를 위해 완전한 한 세트의 바인딩을 만들어 내다.

컴파일러는 2단계-컴파일 이전 단계(a precompile phase)와 방출 단계(an emission phase)로 동작한다. 첫번째 단계에서 사전 컴파일러는 사용자가 제공한 클래스 정의를 판독하여 분석하고 이진 클래스 정보, 주석 및 패스스루 라인을 포함하는 중간 출력 화일을 만든다. 두번째 단계에서, 한개 이상의 방출 프로그램(emitter programs)이 실행하여 알맞는 언어 바인딩 화일을 만든다. 두개의 부수적인 프로그램은 SOM 컴파일러 이전 단계에 대한 전처리기로서의 역할을 한다. 이와 같은 모든 프로그램의 순서와 실행은 SOM 컴파일러의 명령에 따른다.

방출기(the emitter)로부터 나오는 출력과 사용자가 제공한 클래스 메쏘드에 대한 논리는 다음에 C 컴파일러로서 컴파일되어 로드가능한 모듈을 생성하기 위해 OS/2 링커로서 링크된다. 로드가능한 모듈은 자신이 포함된 화일(self-contained files)에 패키지되거나 또는 DLL에 놓을 수 있으므로 클래스는 많은 프로그래으로부터 사용될 수 있다.

제4도와 관련, 제어는 터미널(400)에서 시작하여 SOM 언어 중립 오브젝트 인터페이스 정의(OIDL)(402)가 SOM OIDL 컴파일러(404)속으로 입력되는 함수블럭(404)으로 직접 넣어진다. SOM OIDL 컴파일러는 타게트 언어 방출기(410)에 대한 입력으로서 코드 생성 프로세스를 간단하게 하기 위해 OIDL의 오브젝트 정의를 정규형(a canonical form)(406)로 파스(Parses)한다. 언어 방출기(410)는 제3도에 도시된 클래스 데이타 구조를 포함하는 언어 바인딩(414)을 생성한다. 제어는 언어 응용프로그램(416)과 SOM 바인딩(412)으로부터 추가적인 입력을 수신하는 함수블럭(420)에 도시된 언어 컴파일러로 넘어간다. 언어 컴파일러는 사용자의 편의에 따라 C, Fortran, Cobol 또는 다른 컴파일러일 수 있다. 언어 컴파일러에서 나온느 출력은 다음에 설명하기 위해 SOM 실행시 라이브러리와 함께 링크 에딧(link edited)될 수 있는 오브젝트 화일(422)이다.

제5도는 본 발명에 따른 SOM 오브젝트를 사용하여 응용프로그램의 링크, 로드 및 실행을 나타내는 순서도이다. 처리는 단자(500)에서 시작하여 즉시 제4도의 레이블(422)에서 생성된 SOM 오브젝트(510)와 SOM 실행시 라이브러리(520)를 위한 함수블럭(530)으로 넘어간다. 이때, 함수블럭(540)에서,응용프로그램이 시작되며, 이것은 함수블럭(550)에 제시되고 그리고 제6,7,8,9 및 10도에 상세하게 제시된 필요한 클래스와 오브젝트의 생성을 호출한다. 마지막으로, 응용프로그램은 함수블럭(560)에 도시된 것과 같이 실행되고 터미널 블럭(570)에서제어가 종결된다.

오브젝트 지향 ㅍ로그래에 대한 버전 독립성

본 발명의 상기 특성은 일반적으로 오브젝트 지향의 응용프로그램의 향상, 특히 오브젝트 정의 라이브러리의 독립적 전개 및 그것을 사용하는 컴퓨터 응용프로그램으로부터 발생하는 문제를 해결하는 것에 관한 것이다.

버전에 독립적인 처리는 오브젝트 정의 라이브러리(또한 오브젝트 클래스 라이브러리라고 부른다)를 사용하는 컴퓨터 응용프로그램의 실행 가능한 이진형태를 라이브러리의라이프사이클 동안에 자연적으로 발생하는 오브젝트 정의의 실행 또는 명세의 어떤 변화로부터 격리시킨다. 특히, 응용프로그램이 실행될때마다 오브젝트 정의를 다이나믹하게 로드하는 컴퓨터 응용프로그래의 변경되지 않은 실행가능한 이진형태로서 그 사용을 절충하지 않고 오브젝트 정의에 대한 다음과 같은 변화가 일어날 수 있다.

1) 새로운 메쏘드를 오브젝트 정의에 부가한다 ; 2) 자식클래스로부터 그것의 부모클래스로 메쏘드에 대한 정의의 포인트를 옮긴다 ; 3) 오브젝트 정의와 연관된 전용 인스턴스 데이타에 더하거나, 그것으로부터 삭제하거나, 또는 그렇지 않다면 바꾸며 4) 새로운 클래스 정의를 클래스 위계 구조로 삽입시킨다.

이 처리는 다음과 같이 몇가지 기법을 사용하는 프로세서가 메모리에서 알고리즘 연산에 의해 수행된다. 메쏘드와 인스턴스 오프셋은 응용프로그램 이진이미지(application binary images)로부터 제거된다. C⁺⁺에서 정의된 것과 같은 정적 오브젝트 모델에섬 프로시저 테이블로의 오프셋(정수)은 특수한 각각의 메쏘드 명칭에 대한 메쏘드 프로시저를 선택하는데 사용된다. 오프셋은 메쏘드가 정의되어 있고 그것의 조상에 의해 정의된 클래스으 메쏘드에 대한 번호 및 순서에 따른다.

이러한 접근책은 메쏘드 레저루션의 매우 빠른 형식을 갖는 이점이 있다. 그러나, 종래기술에서 오브젝트 모델은 특수한 오브젝트 클래스를 사용한 응용프로그램의 이진이미지에 그 오프셋을 위치시키기 때문에, 결국 오프셋이 바뀔때마다 응용프로그램을 다시 컴파일할 필요가 있게 된다.

SOM에서, 메쏘드와 연관된 오프셋은 제3도의 논의에서 상세하게 설명된 클래스 데이타 구조라고 불리우는 각 클래스에 대한 하나의 메모리 데이타 구조속으로 집합된다. 이 데이타 구조에는 외부 명칭이 주어지며 그 내용은 응용프로그램내에서 참조된다. 각 클래스 데이타 구조는 제10도에 상세하게 설명된 것과 같이 클래스 오브젝트가 초기화될 때 알맞는 오프셋 값을 포함하도록 초기화된다. 그리하여 응용프로그램이 실행될 때마다 모든 오프셋 값은 응용프로그램에 의해 사용된 클래스의 현재 정의를 기준으로 다시 계산된다.

클래스 데이타 구조에 저장된 값에 대한 응용프로그램의 이진이미지의 어떤 참조는 오프셋을 포함하고 있다는 것을 주의해야 한다. 그러나, 이 오프셋들은 상기 열거된 네 종류의 병화 전체에 걸쳐 일정할 수 있다. 이것은 클래스 데이타 구조만이 특수한 클래스에 정의된 메쏘드에 대한 오프셋을 포함하고 있으며, 클래스에 의해 상속된 메쏘드의 오프셋에 대한 오프셋은 포함하고 있지 않기 때문이다. 그리하여, 클래스에 부가된 새로운 메쏘드는 이미 클래스내에 정의되어 있는 메쏘드에 대한 오프셋 값의 위치를 흐트려뜨리지 않고 클래스 데이타 구조의 끝에 부가된 그것의 오프셋을 가질 수 있다.

SOM 오브젝트 인터페이스 정의언어(OIDL)는 상기 "SOM 오브젝트 모델"로 제목이 붙은 부분에서 논의된 해제순서부분을 포함한다. OIDL의 해제순서부분은 클래스 실행자로 하여금 클래스내에 이미 정의되어 있는 메쏘드에 대한 메쏘드 오프셋 값이후에새로운 메쏘드 오프셋 값을 더할 수 있게끔 보장한다. OIDL 화일내의해제순서부분은 또한 만약 클래스내에 정의된 메쏘드중 한개가 제3도에 강조된 것과 같은 부모클래스로 이동되었다면 앤트리가 클래스 데이타 구조에서 분류되도록 한다. 이 엔트레는 이때 OIDL 컴파일러가 제10도에 설명된 것과 같이 클래스 데이타 구조를 초기화시키는 논리를 부가하는 간단한 배정문을 사용하여 부모오프셋(the parent offset)으로부터 초기화된다.

공용 인스턴스 데이타와 함께 유사한 문제가 발생한다. 응용프로그램의 오브젝트의 스테이트 데이타 구조중 하나에 포함된 공용 인스턴스 변수를 액세스하는 응용프로그램은 오브젝트으 스테이트 데이타 구조에 대한 오프셋을 거쳐 반드시 그렇게 하여야 한다. 종래기술에서, 이 오프셋은 응용프로그램의 이진이미지내에 포함된다. 만약 이 기법이 사용된다면, 이때 응용프로그램의 이진이미지는 한개 이상의 오브젝트의 조상클래스에 대한 인스턴스 데이타 필요조건으 크리가 변화하거나 또는 오브젝트 자신의 인스턴스 데이타 레이아웃의 변화로 인해 오프셋이 바뀔때 반드시(재컴파일을 거쳐) 재생성되어야 한다.

SOM에서 이 문제는 제3도에 상세히 설명된 클래스 데이타 구조에 있는 각 공용 데이타 변수에 대한 오프셋을 놓음으로서 그리고 다음 논의로서 해결된다. 각각의 클래스 데이타 구조는 제7도와 제13도에 상세히 설명된 것과 같이 클래스 오브젝트가 초기화될 때 적당히 오프셋 값을 포함하도록 초기화된다. 그리하여, 응용프로그램이 실행될 때마다 모든 오프셋 값은 응용프로그램에 의해 사용된 클래스의 현재 정의를 토대로 다시 계산된다.

응용프로그램의이진이미지로부터 오브젝트 스테이트 데이타 구조를 제거한다.

새로운 오브젝트의인스턴스가 생성될때, 오브젝트의 상태 데이타 구조를 수용하도록 컴퓨터 메모리에 대한 정확한 크기가 반드시 할당되어야 한다. 종래기술에서, 이 메모리 블럭의 크기는 응용프로그램의 이진이미지내에 포함되어 있다. 만약 이 기법이 사용된다면, 이때 응용프로그램의 이진이미지는 오브젝트의 스테이트 데이타 구조의 크기가 변할때(재컴파일을 거쳐)반드시 다시 생성되어야 한다. SOM에서, 이 값은 오브젝트의 클래스 오브젝트에 대한 호출을 통해서 사용할 수 있으며 그리하여 응용프로그래의 이진이미지내에 포함될 필요가 없다.

상술된 기법을 사용함으로서 상기에 강조된 네가지 변화의 각각이 응용프로그램이 이진이미지가 다시 생성될 필요없이 응용프로그램에 의해 사용된 클래스 정의와 관련하여 발생하는 것이 가능케된다.

제6도는 본 발명에 따른 새로운 SOM 클래스의 생성을 나타내는 순서도이다. 제어는 버전번호가 맞는지를 증명하기 위해 검사가 이루어지는 판단블럭(610)에서 올바른 버전번호에 대한 테스트로 즉시 넘어가는 터미널(600)에서 시작한다. 만약 올바르지 않은 버전번호가 검출된다면, 이때 출력블럭(612)에 메시지가 디스플레이되고 제어는 터미널 블럭(614)에서 종료된다. 만약 올바른 버전번호가 검출된다면 이때 SOM클래스가 존재하는지를 판단하기 위해 판단블럭(620)에서 다른 테스트가 수행된다. 만약 SOM 클래스가 존재한다면, 이때 처리는 터미널 블럭(622)에서 복귀된다.

만약 SOM 클래스가 판단블럭(620)에서 존재하지 않는다면, 이때 SOM 실행시 환경이 작동(is active)중인지를 판단하기 위해 판단블럭(630)에서테스트가 수행된다. 만약 작동중이지 않다면, 이때 함수블럭(632)에서 SOM 실행시 환경이 호출된다. SOM 환경이 초기에 존재하는지 혹은 아닌지, 판단블럭(640)에서 SOM 환경의 에러를 검사하기 위해 제어가 판단블럭(640)으로 넘어간다. 만약 에러가 검출된다면, 이때 출럭블럭(642)에서 알맞는 메시지가 제시되고 처리는 터미널 블럭(644)에서 종료된다. 만약 에러가 검출되지 않는다면, 이때 제어는 디폴트 메타클래스가 준비되는 함수블럭(650)으로넘어간다. 다음에, 제7도에 상세히 설명된 것과 같이 함수블럭(652)에서 클래스가 구성된다. 마직막으로, 터미널 블럭(660)에서 처리가 종료된다.

제7도에 본 발명에 따른 새로운 SOM 클래스에 대한 세부 구성을 도시하는 흐름도이다. 제어는 터미널(700)에서 시작하여 제8도에 상세하게 설명된 것과 같이 포괄 클래스 오브젝트가 생성도는 함수블럭(710)으로 즉시 넘어간다. 다음에, 함수블럭(720)에서 새로운 포괄 클래스가 디폴트 값으로 초기화되고 제9도에 상세히 설명된다. 다음에 함수블럭(730)에서,특수한 새로운 클래스를 위해 인스턴스 데이타 오프셋이 초기화된다. 제어는 제10도에 상세하게 설명된 것과 같이 새로운 클래스에 대한 각각의 정적 메쏘드를 표시하는 값을 할당함으로서 새로운 클래스에 대한 클래스 데이타 구조(제3도)가 초기화되는 함수블럭(740)으로 넘어간다.

함수블럭(750,760과 770)에서, 부모클래스가 세트되고, 클래스 데이타가 초기화되어 그리고 클래스가 등록된다. 이 단계는 제2,10 및 13도의 논의에 상세히 설명된 것과 같이 새로운 클래스 데이타 구조를 업데티하는 것을 포함한다. 마지막으로, 터미널(780)에서 제어가 복귀된다.

제8도는 본 발명에 따른 새로운 SOM 포괄클래스 오브젝트의 세부구성을 도시하는 순서도이다. 제어는 터미널(800)에서 시작하여 오브젝트에 대해 메모리가 할당되는 함수블럭(810)으로서 즉시 넘어간다. 이때 메모리가 할당되었는지를 판단하기 위해 판단블럭(820)에서테스트가 수행된다. 만약 에러가 검출된다면, 이때 출력블럭(830)에서 적절한 에러메시지가 디스플레이되고 터미널 블럭(840)에서 처리가 종료된다. 만약 아무런 에러도 검출되지 않는다면, 이때 함수블럭(850)에서 오브젝트의 디폴트값이 세트되고 터미널 블럭(860)에서 제어가 종료된다.

제9도는 본 발명에 따른 새로운 SOM 클래스 오브젝트의 상세한 초기화를 도시하는 순서도이다. 제어는 터미널(900)에서 시작하고 판단블럭(910)으로즉시 넘어가 새로운 SOM 클래스 오브젝트의 부모클래스가 존재하는지를 검출하기 위해 테스트가 수행된다. 만약 부모클래스가 존재한다면, 이때 함수블럭(912)에서 메모리가 할당된다. 다으에, 판단블럭(930)에서 새로운 SOM 클래스 오브젝트의 부모클래스가 존재하는지를 검출하기 위해 다시 테스트가 수행된다.

만약 부모클래스가 존재하지 않는다면, 이때 함수블럭(932)에 도시된 것과 같이 초기 변수가 0으로 세트되고 제어가 함수블럭(970)으로 넘어간다. 만약 부모클래스가 존재한다면, 이때 함수블럭(940,950 및 960의 부모클래스에서 나오는 값을 토대로초기변수가 업데이트된다. 이때, 함수블럭(970)에서 클래스에 대한 버전번호가 세트되고 판단블럭(980)에서 에러처리가 수행된다. 만약 에러가 검출된다면, 이때 출력블럭(982)에서 알맞는 메시지가 디스플레이되고 터미널 블럭(934)에서 처리가 종료한다. 만약 아무런 에러도 검출되지 않는다면, 이때 터미널 블럭(990)에서 제어가 복귀된다.

제10도는 본 발며에 따른 오프셋 값을 갖는 SOM 클래스 데이타 구조의 상세한 초기화를 도시하는 순서도이다. 제어는 터미널 블럭(100)에서 시작하며 다음의 정적 메쏘드의 획득(the acquisition)과 동시에 루프가 시작도는 함수블럭(1010)으로 즉시 넘어간다. 함수블럭(1020)에서, SOM 실행시 환경과 함께 새로운 메쏘드 id가 등록된다. 다음, 판단블럭(1030)에서 부모클래스내에 메쏘드가 이미 등록되었는지를 판단하기 위해 테스트가 수행된다. 만약 메쏘드가 등록되어 있다면, 이때 메쏘드 오프셋이 함수블럭(1032)에서 오버라이드되어 제어는 판단블럭(1070)으로 넘어간다.

만약 메쏘드가 어떤 부모클래스로도 등록되지 않았다면, 이때 판단블럭(1040)에서 메쏘드가 현재의클래스에 정의되었는지를 판단하기 위해 테스트가 수행된다. 만약 메쏘드가 정의되었다면, 이때 함수블럭(1042)에서기존의 오프셋이 사용되고제어는 판단블럭(1070)으로 전달돈다. 만약 메쏘드가 정의되지 않았다면, 이때 메모리가 할당되며 함수블럭(1050과 1060)에서 값이 초기화된다. 함수블럭(1060)에서 오프셋은 상속돈 정적 메쏘드의 번호를 클래스에 의해 지금까지 처리된 상속된 정적 메쏘드의번호를 더함으로서 계산된다. 판단블럭(1070)에서 에러 처리가 수행되며, 만약 에러가 검출된다면, 이때 출력블럭(1072)에서 적절한 메시지가 디스플레이 되고 터미널 블럭(1074)에서처리가 종료한다. 에러 처리가 완료된 후, 어떤 부수적인 메쏘드가 처리를 원하는지를 판단하기 위해 판단블럭91080)에서 다른 테스트가 수행된다. 만약 부수적인 메쏘드가 존재한다면, 이때 제어는 다음의 루프 순환을 위해 함수블럭(1010)으로 넘어간다. 그렇지 않으면, 제어는 제어가 복귀하는 터미널(1090)로 넘어간다.

부모클래스 섀도우잉(Patrent Class Shadowing)

오브젝트 프로그래밍에서 부모클래스 섀도우(a parent class shadow)을 일컬어지는 교체 부모클래스의 동적인 삽입(a dynamic insention of a replaement parent class)를 제공하기 위한 논리는 본 발명의 이부분에 상세하게 설명되어 있다. 이 처리는 어떤 부모클래스가 실행시(at runtime)에 특정 클래스에 링크도었는가에 대한 정적으로컴파일된 정의가 실행동안(during executon) 동적으로 변경되게 한다. 새로운 부모클래스를 정적으로 컴파일된 클래스 위계 구조로 삽입시키는 능력은 이것이 이진형태로 나타난 후 기존의 코드를 유지하고 증가시키는데 있어서 보다 큰 유연성을 제공한다. 또한 이것은 재컴파일 없이 이와 같은 결과가 달성될 수 있기 때문에 소스 머트리얼(source materials)에 액세스하지 않고 코드를 커스텀화하기 위한 새로운 자유도(a new degree of freedom)를 제공한다.

종래기술의 시스템은 정적으로 링크하는 파생된 클래스 및 그것의 부모크래스와 연관된 선천적인 한계를 갖는다. 이러한 제한은 파생된 오브젝트 스테이트 데이타 구조의 크기에 대한 연산, 파생된 메쏘드 프로시저의 초기화 그리고 파생된 클래스의 메쏘드(부모클래스 레저루션이라고 부른다)내로부터 부코클래스의 메쏘드로의 액세스를 제공하지 못하는 것을 포함한다.

SOM 오브젝트 모데은 부모클래스 오브젝트를 통해서 실행시에 사용가능한 모든 부모클래스 정보를 가짐으로서 이러한 정적 참조를 제거한다. 그리하여, 파생된 클래스 시행이 부모클래스의 스테이트 데이타 구조의 크기 부모클래스의 메쏘드 프로시저에 대한 어드레스 또는 부모클래스의 메쏘드 프로시저 테이블(부모클래스 레저루션을 지원하기 위한)에의 액세스에 대한 정보를 요구할 때 부모클래스 오부젝트로부터 정보를 얻기 위해 적절하게 호출된다. 이 정보를 얻기위한 세부적인 처리는 제7,8,9, 및 10도에 제공되어 있다.

SOM은 모든 SOM 프로세스에 대한 클래스 매니저(a class manager)를 소개한다. 클래스 매니저는 클래스의 등록(a registry fo Classes)을 유지할 책임이 있다. SOM 컴파일러에 의해 생성된 클래스 구성 코드 자식클래스 오브젝트가 생성될 때마다 클래스와 그것의 부모클래스간의 관게를 설정하기 위해 클래스 매니저와 함께 일한다. SOM 클래스 매니저는 어떤 다른 SOM 클래스와 같이 서브클래스될 수 있는 클래스의 인스턴스이다.

파생된 클래스는 SOM 클래스 매니저 오브젝트를 호출함으로서 그것들의 부모클래스 오브젝트에의 연결을 확립한다. 원래의 클래스 실행을 대체가능한 클래스 실행으로 교체하기를 원하는 응용프로그램 설계자는 다음과 같은 단계를 따른다.

1)클래스 명칭(즉, SOMClassFromId, somFindClass 및 somFindClsInFile의 실행을 바꾸는 것)으로부터 클래스 오브젝트를 결정하기 위해 새로운 세트의 응용에 특정한 규칙을 제공하는 서브클래스 SOMClassMgr.

이것을 하기 위한 간단하고 융요한 방법은 기존의 클래스 명칭하에 섀도우 클래스 오브젝트를 등록시키기 위해 메쏘드를 더한 다으 다음의 어떤 호출에서 호출하는 응용프로그램에 대한 섀도우 클래스 오브젝트를 섀도우된 명칭이 지정되는 SOMClassFromId, somFindClass 및 somFindClsInFile로 복귀시키는 것이다.

2) 섀도우된 부모클래스 오브젝트를 갖게될 어떤 파생된 클래스 오브젝트를 생성하기 전에, 새로운 클래스 매니저 클래스의 인스턴스를 생성(상기 단계 1에 설명된 것과 같이)하고, 기존의 SOMClassMgr 인스턴스(somMgr Into 메쏘드를 거쳐)로부터 그것을 초기화시키며, 다음에 SOM 실행시에 기존의 SOMClassMgr 인스턴스의 어드레스를 오버라이드시킴으로써 기존의 SOMClassMgr 인스턴스를 섀도우 클래스 매니저 인스턴스로 교체한다.

3) 섀도우된 부모클래스 오브젝트를 갖게 될 어떤 파생된 클래스 오브젝트를 생성하기 훨씬전에, 섀도우 클래스 오브젝트를 등록시키기 위해 응용에 특정한 클래스 매니저 시설(the facilities of the application specified class manger object)을 이용한다.

a) 이것은 정적으로 공지된 부모클래스의 정의의 이진이미지에 대한 정적인 참조(a static reference)를 생성함으로서, 부모클래스 실행이 응용프로그램의 이진이미지(the binary image)속으로 확실하게 링크될 수 있게 한다.

b) 이것은 적어도 정적으로공지돈 부모클래스 오브젝트가 다음 단계가 발생하기 전에 SOM클래스 매니저 오브젝트와 함께 등록되는 것을 보장한다.

만약 정적으로 공지된 부모클래스 오브젝트(the statocallu Known parent class Object)가 이미 생성(즉 상기 논의된 섀도우잉 단계 다음의 응용에 의해서)도었다면, 이때 이번에는 두번째 시도는 무시된다.

2) 두번째, 파생된 클래스의 부모클래스 명칭을 근거로 하여 적절한 클래스 오브젝트의 어드레스를 회수하기 위해 SOM 클래스 매니저 오브젝트에 대해 호출이 이루어진다. 만약 부모클래스가 섀도우 되었다만 이때 이 호출은 섀도우 크래스 오브젝트를 반환할 것이다.

상술된 기법과 메카니즘을 조합함으로서 파생된 클래스가 부모클래스 데이타를 발췌하는데 사용하는 크래스 오브젝트의 정확한 클래스에 대한 어떤 의존성으로부터 파생된 클래스이 이진이미지를 효과적으로 분리한다.

자식클래스와 그것의 부모클래스 사이에 새로운 클래스를 삽입시킬때 두가지 제한이 관찰되어야 한다. 첫째, 삽입(the insertion)은 반드시 자식클래스의 어떤 인스턴스가 생성되기 전에 반드시 수행되어야 된다. 둘째, 삽입된 클래스도 역시 반드시 원래의 부모클래스에 대한 즉시 자식(the immediate child)이어야 한다. SOM 클래스 매니저는 실행시에 클래스간의 관곌르 설정할때 중간체(an intermediary)로서 사용되기 때문에, 심지어 정적으로 링크된 클래스도 이와 같이 섀도우될 수 있다.

제11도는 본 발명에 따라 정적으로 정의된 클래스 위계 구조에 대한 세부적인 부모클래스 섀도우잉을 도시하는 순서도이다. 제어는 터미널블럭(1100)에서 시작하여 정적으로 부모클래스 오브젝트가 생성되는 함수블럭(1100)속으로 즉시 넘어간다. 다음에, 함수블럭(1120)에서 클래스가 생성되어 정적으로 정의된 부모클래를 오버라이드시키는데 사용된다. 이때, 함수블럭(1130)에 도시된 것과 같이 자식클래스가 생성되며 그 자식클래스는 정적으로 정의된 부모클래스보다는 그것의 현재 부모클래스를 확인(ascertain)하기 위해 SOM 크래스 매니저를 조사(interrogates)한다. 제어는 터미널 브럭(1140)에서 복귀한다.

재디스패치 메쏘드 스터브(Redispatch Method Stubs)

오브젝트 지향 프로그래밍의 가장 중요한 면은 메쏘드 레저루션(method resolution)으로 일컬어진다. 이처리는 오브젝트, 메쏘드의 id 그리고 메쏘드 호출로 전달된 인수가 주어진 특정 메쏘드를 선택한다. C⁺⁺에 사용된 것과 같은 많은 오브젝트 모델에서, 메쏘드 레저루션은 프로그램의 소스 코드를 분석한 것을 토대로 하여 프로시저 엔트리 포인트으 오브젝트 지정 테이블(an object specific table)에의 오프셋을 판단하는 것으로 이루어진다. 이와 같은 종류의 레저루션은 오브젝트 모데에서 정적(static)이라고 일컬어진다. 스몰토크에 사용된 것과 같은 다른 오브젝트 모델에서 실행시에 특정한 메쏘드를 결정하기 위해 오브젝트의 명칭을 사용하는 것으로 이루어지는 보다 동적 모델(a more dynamic model)이 사용된다. 오브젝트 모델에서 이것은 동적(dynamic)인 것으로 일컬어진다.

본 발명은 정적인 모델과 동적인 모델간의 차이를 완화시키기 위해 재디스패치 스티브(redispatch stubs)라고 불리우는 프로그래밍 메커니즘으로 구성된다. 재디스패치 스터브는 프로시저 엔트리 포인트의 테이블 내에 놓을 수 있는 엔트리 포인트를갖는 작은 프로시저이다. 프로시저 엔트리 포인트의 테이블은 정적인 오브젝트 모델에서 예상되는 실제 메쏘드 엔트리 포인트의 대용으로서 사용된다. 재디스패치 스티브는 동적인 오브젝트 모데의 필요성에 따라 자동적으로 생성된다. 재디스패치 스티브는 정적인 오브젝트 모델에서 생성된 호출을 동적인 오브젝트 모델에 필요한 형식으로 변환하고 프로세스에서 어떤 미비한 정보(anymissing information)를 공급한다. 그리하여, 만약 동적인 오브젝트 모데에 의해 제공되는 정적인 오브젝트 모델에 표현될 수 있다.

제12도는 본 발명에 따른 재디스패치 메쏘드를 도시하는 순서도이다. 레이블(1200)은 특정한 오브젝트에 대한 스테이트 데이타 구조이다. 레이블(1210)에서 첫번째로 채운 단어(The first full word)는 오브젝트의 메쏘드 프로시저 테이블 레이블(1240)의 어드레스를 포함한다. 나머지 스테이트 데이타 구조는 그 오브젝트에 속하는 부수적인 정보를 포함하는 레이블(1230)에 제시되어 있다. 레이블(1240)에 제시된 메쏘드 프로시저 테이블은 특정 오브제트에 대한 여러가지 메쏘드의 어드레스를 포함한다. 이 오브젝트와 동일한 클래스인 메쏘드든 오브젝트도 역시 레이블91240)에 다이어그래된 상기 메쏘드 프로시저 테이블을 가리키는 어드레스를 포함한다. 오브젝트에 의해 상속된 어떤 메쏘드들도 상속되는 조상클래스의 레이블(1240)에 제시된 것과 같이 메쏘드 프로시저 테이블에 나타날때 메모리내의 동일한 오프셋에 그것들의 메쏘드 프로시저 어드레스를 가질 것이다.

도면에서, 레이블(1250)은 재디스패치 스터브(1270)에 대한 포인터를 포함한다. 재디스패치 스터브는 클라이언트 프로그램에 대한 메쏘드로서 나타나는 일련의 명령어이다. 그러나, 명령은 단지 레이블(1260)에 예시된 것과 같이 메쏘드 호출을 오브젝트의 적정한 디스패치 함수에 대한 호출로 변환한다. 레이블(1260)에 있는 어드레스는 오브젝트의디스패치 함수(1280)에 대한 포인터이다. 모든 SOM 오브젝는 디스패치 함수를 갖는다. 디스패치 함수(1280)는 재디스패치 스터브에 의해 전달돈 파라메타를 토대로 하는 특정한 메쏘드를 선택하기 위해 알고리즘을 실행한다. 이 파라메타들은 메쏘드 식별자(identifier), 식별된 메쏘드로 전달된 한 세트의 인수들을 설명하는 스트림과 상기 세트의 인수들을 포함하는 데이타 구조를 포함한다.

오프셋 값(offset Values)

제13도는 하나의 공용 인스턴스 변수에 대한 SOM 클래스 데이타 구조에 있어서 오프셋 값에 대한 상세한 초기화를 도시하는 순서도이다. 이러한 논리적 순서는 특정 클래스 (상기 OIDL 데이타부분의 설명을 참조)에 정의된 각각의 공용 인스턴스 변수에 대해 반복된다. 제어는 터미널 블럭(1300)에서 시작하여 상기 클래스의 오브젝트 스테이트 데이타내에 있는 인스턴스 변수의 오프셋을 제2도의 레이블(230)에 제시된 오브젝트 스테이트 데이타 구조내에 있는 상기 클래스의 오브젝트 스테이트 데이타의 시작에 대한 오프셋에 더함으로서 인스턴스 변수의 오프셋이 계산되는 함수블럭(1310)으로 즉시 넘어간다.

클래스의 오브젝트 스테이트 데이타의 시작은 상기 클래스의 조상클래스인 각각의 오브젝트 스테이트 데이타의 크기까지 더함으로서 결정된다. 이때 제어는 OIDL 화일 해제순서부분(상기 OIDL 해제순서부분과 제3도 참조)에 있는 공용 인스턴스 변수 명칭의 위치에 의해 결정되는 것과 같이 계산된 오프셋이 클래스 데이타 구조의 위 치내로 저장될때 함수블럭(1320)으로 넘어간다. 이때 제어는 터미널 블럭(1330)으로 넘어가고 프로세스는 완료한다.

재디스패치 스터브(Redispatch Stubs)

제14도는 정적 메쏘드 호출이 동적 메쏘드 호출로 변환되도록 재디스패치 스터브가 사용될때 발생하는 세부적인 제어 흐름을 도시하는 순서도이다. 제어는 터미널 블럭(1400)에서 시작하여 클래스가 정의될때 결정된 위치에서 적절한 크래스 데이타 구조내에 포함되어 있는 오프셋의 오브젝트 메쏘드 프로시저 테이블에 저장된 어드레스를 얻음으로서 정상적인 정적 메쏘드 레저루션 방법으로 재디스패치 스터브의 어드레스가 결정되는 함수블럭(1410)으로 즉시 넘어간다.

다음에 제어는 실제의 정적 메쏘드 프로시저(the real static method procedure)와 거의 똑같이 재디스패치 스터브가 호출되는 함수블럭(1420)으로 넘어간다. 함수블럭(1430)은 어떻게 해서 재디스패치 스터브가 오브젝트의 디스패치 메쏘드(상술된 것과 같이 정상적인 메쏘드 레저루션을 사용하여)를 호출하는지를 도시한다. 재디스패치 스터브는 오브젝트으디스패치 메쏘드에 의해 요구되는 것과 같이 메쏘드의 식별자와 기술자(the method's identifier and descriptor)를 호출에 부가한다. 상기 값들은 SOM OIDL 컴파일러에 의해 생성될때 재디스패치 함수정의로 통합된다(주 ; 상기 SOMObject 클래스의 정의에 상세히 설명된 것과 같이, 모든 클래스는 반드시 디스패치 메쏘드를 지원하여야 한다). 오브젝트의 디스패치 메쏘드 프로시저는 함수블럭(1440)에 도시된 것과 같이 오브젝트의 클래스에 특정한 알고리즘을 사용하여 어떤 실제의 메쏘드 프로시저가 호출되어야 하는가를 결정한다.

SOM은 메쏘드 프로시저의 어드레스를 결정하기 위해 오브젝트의 클래스 오브젝트내에 포함된 테이블에서 메쏘드의 식별자를 참조하는 이와 같은 알고리즘의 디폴트 실행을 제공한다. 다른 오브젝트 모델을 다른 알고리즘을 사용할 수 있다. 다으에 제어는 블럭(1450)에서 결정된 메쏘드 프로시저가 호출되는 함수블럭(1450)으로 넘어간다. 메쏘드 프로시저 그 복귀값을 반환할때 터미널 블럭(1460)에서재디스패치 스터브의 원래의 호출자로 복귀된다. 재디스패치 스터브는 오브젝트를 조작하는 응용프로그램을 변경할 필요없이 원래의 정적 메쏘드 호출의 임의의 다이나믹스(arbitrary dynamics)중 한개로 변환되게 한다.

메쏘드 프로시저 테이블 초기화

제15도는 클래스를 사용하는 응용프로그램의 실행동안 메쏘드 프로시저의 연관(the association of method procedures)을 메쏘드로 바꿀 수 있는 클래스에 대한 메쏘드 프로시저 테이블을 적절하게 초기화 시키는 세부적인 제어 흐름을 도시하는 순서도이다. 제어는 터미널 블럭(1500)에서 시작하여 메쏘드 프로시저 테이블에 대해 공간이 할당되는 함수블럭(1510)으로 즉시 넘어간다. 클래스의 오브젝트에 대한 어드레스의 엔트리 및 제7도에 따라 클래스에 의해 상속되거나 정의된 각 메쏘드를 포함하도록 충분한 공간이 할당된다. 다음에 제어는 메쏘드 프로시저 테이블내 각 메쏘드 엔트리가 그것의 재디스패치 스티브에 의해 교체되는 함수블럭(1520)으로 넘어간다. 상속된 것을 위한 재디스패치 스터브는 클래스의 부모클래스로부터 그것들을 요청함으로서 결정된다. 클래스에 대한 재디스패치 스터브는 SOM 컴파일러에 의해 생성되어 각 클래스으 정적 메쏘드를 등록하기 위해 호출에 있는 클래스 초기화 프로시저로 공급된다. 다음에 제어는 클래스의 디스패치 함수에 대한 메쏘드 프로시저 테이블 엔트리가 클래스 디스패치 함수의 실제 어드레스에 의해서 교체되는 함수블럭(1530)으로 넘어간다(이것은 결국 무한 루프가 되기 때문에 디스패치 함수 슬롯에 재디스패치 스터브 어드레스를 갖는 것은 결코 올바른 것이 아니다). 마지막으로 제어는 터미널 블럭(1540)으로 넘어가고 처리가 완료한다.

특정한 시스템 환경에서 바람직한 실시예로서 본 발명이 설명되었지만, 본 발명은 첨부된 청구범위의 정신과 영역내에서 변경시키지 않고 다른 하드웨어 및 소프트웨어 환경에 실시될 수 있다는 것을 기술분야에 숙달된 사람들은 이해할 것이다.

Claims

컴퓨터 메모리에서 함수에 의해 구현된 메쏘드를 대표하는 메쏘드 명칭을 갖는 한 세트의 클래스를 구성(organizing a set of classes with method names representative of methods implemented by functions in a computer memory)하기 위한 장치에 있어서, 상기 장치는 (a) 각 클래스를 위해 메쏘드 프로시저 테이블(a method procedure table)을 초기화시키는 수단, (b) 각 클래스를 위해 모든 함수들을 정적으로(statically) 정의하는 수단, (c)각 클래스를 위해 데이타 구조는 오프셋 변수들을 집합(collecting offset varjabes into a data structure for each class)시키는 수단과, (d) 컴퓨터 메모리에 있는 각 크래스를 위해 데이타 구조를 외연화(externalizing)시키는 수단을 구비하는 것을 특징으로 하는 한 세트의 클래스 구성장치.
제1항에 있어서, 상기 (a) 의 초기화 수단은 디스크 또는 다른 기억매체 상에 메쏘드 프로시저를 저장시키기 위한 수단을 포함하는 것을 특징으로 하는 한 세트의 클래스 구성장치.
제1항에 있어서, 상기 장치는 실행시(at runtime)에 (c)의 오프셋을 초기화시키기 위한 수단을 포함하는 것을 특징으로 하는 한 세트의 클래스 구성장치.
제1항에 있어서, 상기 장치는 (a)의 메쏘드를 오버라이드(overriding the methods)하기 위한 수단을 포함하는 것을 특징으로 하는 한 세트의 클래스 구성장치.
제1항에 있어서, 상기 장치는 메쏘드의 명칭을 변경시킬 필요없이 (a)의 메쏘드들을 독특하게 차별화(uniquely differentiating between the methods)시키기 위한 수단을 포함하는 것을 특징으로 하는 한 세트의 클래스 구성장치.
컴퓨터 메모리에서 함수에 의해 구현된 메쏘드를 대표하는 메쏘드 명칭을 갖는 한 세트의 클래스를 구성방법에 있어서, 상기 방법은(a)각 클래스를 위해 메쏘드 프로시저 테이블을 초기화시키는 단계, (b) 각 클래스를 위해 모든 함수들을 정적으로(statically) 정의하는 단계, (c) 각 클래스를 위해 데이타 구조는 오프셋 변수들을 집합시키는 단계와, (d) 컴퓨터 메모리에 있는 각 클래스를 위해 데이타를 구조를 외연화시키는 단계를 구비하는 것을 특징으로 하는 한 세트의 클래스 구성방법.
제6항에 있어서, 상기 (a)의 초기화 단계는 디스크 또는 다른 기억매체 상에 메쏘드 프로시저를 저장하는 단계를 구비하는 것을 특징으로 하는 한 세트의 클래스 구성장치.
제6항에 있어서, 상기 방법은 실행시에 (c)의 오프셋을 초기화시키는 단계를 포함하는 것을 특징으로 하는 한 세트의 클래스 구성방법.
제6항에 있어서, 상기 방법은 (a)의 메쏘드를 오버라이드 하는 방법을 포함하는 것을 특징으로 하는 한 세트의 클래스 구성방법.
제6항에 있어서, 상기 방법은 메쏘드의 명칭을 변경시킬 필요없이 (a)의 메쏘드들을 독특하게 차별화시키기 위한 단계를 포함하는 것을 특징으로 하는 한 세트의 클래스 구성방법.