KR100252644B1 - 전기통신 시스템과 개방형 시스템에 있어서의 관리 - Google Patents

Abstract

본 발명은 전기통신 또는 개방형 시스템에 관한 것으로서 하나 이상의 관리시스템(2) 및 하나이상의 피관리시스템(10)을 구비하는 관리망에 관한 것이다.

상기 피관리시스템은 물리적 및/또는 논리적 자원을 포함하고, 이들 자원은 피관리시스템에 의해 이들 자원의 데이터 영상의 형태로의 피관리목적물로서 고려되고 관리된다.

관리시스템은 피관리시스템에 지향한 그의 작동에 맞아 피관리시스템의 관리정보모델(8)을 이용하고 이 관리정보모델은 관리시스템의 작동모우드에 적응하고, 모든 피관리목적물의 기술을 포함한다.

관리네트워크는 피관리시스템(10)의 밖에 범용관리자(4) 및 관리정보모델의 표현(6)을 포함하고, 여기서 작동중의 범용관리자의 운용은 이 정보모델표현에 의해 결정된다.

Description

전기통신 시스템과 개방형 시스템에 있어서의 관리{MANAGEMENT IN TELECOM AND OPEN SYSTEMS}

본 발명은 전기통신 또는 개방형 시스템용의 하나 이상의 관리시스템과 하나 이상의 피관리시스템을 지닌 관리망에 관한 것으로, 상기 피관리시스템은 물리적 및/또는 논리적 자원을 포함하며, 이들 자원은 관리시스템에 의해 자원의 데이타영상의 형태로 피관리 목적물로 고려되어 관리되며, 이 시스템내에서 관리시스템은 피관리시스템에 지향되는 관리시스템의 동작에 맞는 피관리시스템의 정보 모델을 이용하고, 이 정보모델은 이런 관리시스템의 동작모우드에 적응된 모든 피관리 목적물의 기술을 포함한다.

또한, 본 발명은 전기통신 및 개방형 시스템에 있어서의 하나 이상의 관리시스템과 하나 이상의 피관리시스템을 지닌 관리망에서 피관리 목적물을 실현하는 방법에 관한 것으로, 여기서 서브시스템은 하나 이상의 피관리 목적물을 포함하며, 피관리시스템의 각각의 부분을 의미한다.

하나 이상의 피관리시스템과 하나 이상의 관리시스템을 지닌 관리망이라는 의미는 상기 관리망이 관리망의 부분을 형성하는 하나 이상의 피관리시스템을 관리할 수 있는하나 이상의 관리시스템을 포함할 수 있는 것이다.

개방형 시스템이란 CCITT Applications, Rec. X.200 의 Referemce Model of open systems Interconnection (OSI) 에 규정된 종류의 시스템을 의미한다. 관리 도메인에서 관리능력을 수행하기 위해 하나 이상의 관리자가 자원의 관리를 책임져야 한다. 자원은 도메인의 능력 및 개념을 포함한다. 도메인의 예는 자원이 스위치, 트렁크 (trunk) 인 전기통신망이다. 그리고, 관리유닛은 예를 들어 전기통신망용 오퍼레이터 툴(tool) 및 관리시스템이다.

전화망의 작동을 위해 각각의 회사들은 운전과 유지보수에 있어서 다수의 다른 시스템을 이용한다. CCITT 는 소위 TMN (전기통신 관리망) 이라고 부르는 전화망에서 작동과 유지보수를 위해 표준모델을 개발해 왔다. TMN 의 기본 원리는 여러 관리시스템을 전기통신장비에 연결하는 원래 망구조를 표시하는 것이다. 이것은 표준화 프로토콜과 인터패이스를 이용하여 성취된다. 전화사나 다른 오퍼레이터는 전기통신망이 TMN 에 적합되는 것을 요구한다.

CCITT 는 개발하에 있는 이것들에 대해 권고 M.3000-series 를 행하고 있다. TMN 은 네트워크 노우드를 네트워크소자 (NE) 로 간주한다. 이 네트워크소자는 전화교환기 및 전송 및 수송네트워크 제품으로 만들어진다.

TMN 의 기능 구조는 사무관리, 서어비스 및 네트워크행정을 위해 관리기능과 같은 사용자에 유용한 응용 프로그램을 관리하는 관리기능 (OSF, Operations Support Functions) 과 ; 관리시스템 (OSS) 과 피관리시스템 (NE) 사이의 데이타 통신을 관리하는 데이타 통신기능 (DCF, Data Communication Functions) 과 ; 피관리 목적 사이에 정보를 전환시키고 데이타를 관리하고 축소 편집하며, 임계값과 관련된 결정을 하며, 장비와 네트워크를 식별하는 데이타를 축적하는 중재기능 (MF, Mediation Functions) 과 ; 스위칭기능과 전송으로 전기통신처리를 관리하며, 펄트 국부 및 보호 접속을 위해 관리처리에 참가하는 네트워크소자기능 (NEF, Network Element Functions) 과 ; 인터패이스를 비표준화에서 표준화로 변환시키는 인터패이스 어댑션의 기능 (QAF, Q-Adaptor Functions) 과 ; TMN 의 사용자 단말을 구성하고 정보를 나타내고 네트워크를 관리하기 위해 관리기술자를 돕는 워크스테이션기능 (WSF, Work Station Functions) 을 포함한다.

TMN 은 소위 Q3 라고 불리우는 인터패이스를 포함하고, Q3 는 통신 프로토콜외에 데이타 방식, 작동 및 통고를 포함하는 정보모델이다. Q3 인터패이스와 이의 프로토콜의 상세한 설명은 CCITT 권고 Q961 과 Q962 에서 나타난다.

TMN 은 모든 물리적 및 논리적 목적물을 피관리 목적물이라 하고, 이것을 TMN 에서는 MO(Managed Objects)라 한다(명칭은 지금부터 이용). 피관리 목적물은 전선, 회로 신호단말, 전송루우트, 이벤트 로그 (event log), 경고와 같은 물리적 또는 논리적 자원과 같은 데이타 화상이다. 특정한 관계가 자원과 피관리 목적물 사이에서 발생한다.

자원은 하나 이상의 MO 에 관련되고 또는 전혀 관련되지 않을 수 있다. 한편, MO 는 하나 이상의 자원과 관련되거나 전혀 관련되지 않을 수 있다. MO 가 어떤 형태의 동작 또는 유지보수 활동에 의해 영향받는 경우 이 관계가 중요하다. MO 는 이것이 속해있는 기능자체가 제거되기 전에 제거되지 말아야 한다. 이 정보모델은 목적물 지향 및 관계개념에 기초로 한다.

관리시스템 (OSS-Operation Support System) 은 영상 데이타 베이스 (MIB) (관리 정보 베이스)내의 피관리 목적물의 수집으로서 네트워크 소자와 종속 관리시스템을 처리한다. 이 피관리 목적물은 같은 타입의 다수의 신호 단말과 같은 MO 클래스의 사례(instances)에 의해 구성된다. 그리하여, 각각의 단말은 클래스신호 단말의 사례를 구성한다.

TMN 내에 또한 개념 MIM (관리정보모델)이 존재하고 이 모델은 피관리 목적물에 관한 모든 정보를 집합적으로 언급한다. MIM 은 피목적물에 관한 모든 속성, 관계, 동작 및 통고의 모델이다. MO 사례를 서치하기 위해 관리정보트리 (MIT) (Management Information Tree) 가 이용된다. 이 트리구조는 네트워크내에서 시작하고, 네트워크소자, 가입자 또는 장비를 표시한다.

동작과 유지보수를 위해 이의 정보가 필요한 분리유닛 또는 자원 또는 시스템 외측으로 부터 영향을 받는 동작이 피관리 목적물에 의해 표현된다. (데이타의 셋업, 이름 할당 또는 경보 관리와 같은) 것을 보고해야만하거나 영향을 입을 수밖에 없는 작동관리 또는 유닛에 관한 정보교환은 피관리 목적물상에서거나 또는 이것으로부터의 주의의 형태로 행해진다.

피관리 목적물은 속성을 포함하고 기타 관련 목적물과 관계를 가질수 있다. 다수의 다른 동작이 피관리 목적물쪽으로 지향될 수 있고, 이벤트 (event) 가 이러한 목적물에 의해 발생될 수 있다.

TMN 의 결점은 다음과 같다.

네트워크소자 및 종속 관리시스템은 그 피관리시스템내의 피관리 목적물쪽으로 향해서 동작 또는 피관리시스템에 의해 전달되는 통고 감독을 경유해 관리시스템에 의해 관리된다.

피관리시스템에서 피관리 목적물쪽의 다음 작동은 전송될 수 있는 통고와 함께 피관리시스템의 정보모델에 의해 결정된다.

정보모델은 다음을 표명한다.

정의되는 것은 피관리목적물의 어느 클래스인가.

이것의 클래스내의 피관리목적물은 어느 동작을 받아들이는가.

피관리 목적물이 송신되면 기대되는 것은 어느 통고인가.

피관리목적물의 각 클래스내에서 생성 또는 제거되는 것은 어느 정도의 사례인가. 예를들어 한 개의 피관리 목적물이 한 개의 타 피관리 목적물의 존재를 필요로 하는 경우 피관리목적물간의 종속성 ;

어느 속성의 특정값이 허용되는 것은 타 속성이 특정값에 설정되는 경우인가.

또는 혹시 그 피관리 목적물이 특정상태에 있는 경우에 그 목적물만을 제거할 수 있는 경우에만 한정되는 것.

피관리 목적물내의 종속성.

피관리 목적물에 관계되는 목적과 의도 및 이것의 통고.

관리시스템은 피관리시스템의 정보모델을 알아야 한다. 이것이 TMN 에서는 '공용관리지식(shared managment knowledge)' 이라 불리운다.

정보모델을 변경할 때, 관리모델은 이 변경에 따라 갱신되어야 한다.

종래의 시스템에서 이들 변경은 다음에 의해 이루어진다.

- 새로운 정보모델의 정의.

이것은 GDMO/ASN.1 탭플레트 (GDOM- CCITT rec. X.722 ISO/IFC 10165-4 에 따르는 피관리 목적물용 가이드 라인) 과 피관리 목적물의 ER-다이그램 (앤티티- 관계 다이어그램) 으로 기록된 피관리 목적물의 사양에 의해 이루어진다. 피관리 목적물의 사양은 피관리 목적물의 (기계판독가능) 신텍스 (예 : 작동 및 통고)를 형식적으로 표명한다.

종속성, 사례의 수 등과 같은 다른 모든 부분의 정보모델은 자연어의 설명으로 비형식적으로 표명된다.

- 관리시스템 및 피관리시스템내의 새로운 정보모델의 구현 및 검증 ;

- 입수된 테스트 순서를 수행하는 것에 의해 관리시스템과 피관리시스템이 같은 정보모델에 적합하다는 확인 ;

- 정보모델의 새로운 버젼을 지닌 관리시스템과 피관리시스템을 구성하는 네트 워크의 갱신.

위에서 언급한 것은 다수의 문제를 일으킨다.

첫째, 관리시스템과 피관리시스템의 개발이 서로 맞아야 하므로 개발비가 비싸고, 시장에 새로운 서어비스 도입이 지연된다.

둘째, 사양의 해석이 논의의 여지가 있기 때문에 피관리시스템의 사양에 관한 형식주의의 결여는 관리시스템 및 피관리시스템의 실현, 검증 및 수용을 곤란하게 하고 시간을 걸리게 한다.

세째, 네트워크의 갱신이 계획 및 주위깊게 수행되어야 한다. 이는 다른 여러 버젼의 관리시스템과 피관리시스템의 사이에 종속성이 있기 때문이다.

TMN 모델에 의한 관리목적은 전기통신 및 개방형 시스템의 관리 표준화의 토대가 되는 것이다. 관리 구조는 새로운 시스템 구조의 관리모델에 큰 영향을 준다. 전체 관리가 아니라 표준화를 받는 도메인이 TMN 모델의 관리모델을 취하기 때문이다. 이러한 이유 때문에 균일한 방식으로 관리 기능을 개발 및 설계하는 것이 바람직하다.

본 발명의 제 1 목적은 다음과 같은 관리 기능용 새로운 구조를 제공하는 것으로,

- 관리 기능의 설계를 저렴하게 할 수 있고 ;

- 관리 기능 및 자원의 갱신의 코디네이션 (coordination) 과 계획의 필요성을 줄일 수 있으며 ;

- 네트워크 관리와 같은 복잡한 프로세스의 효율적인 지원 ;

- 관리 기술을 자원기술과 분리하여 각각 개발할 수 있고 ;

- 상이한 종류의 능력이 최적으로 이용될 수 있다.

즉, 전문가, 예를들어 자원 영역의 전문가는 이 영역에 대한 노력에 중점을 두어야 하는 반면, 설계의 노아우를 아는 사람은 여기에 전념해야 한다.

본 발명의 제 1 특징에 따른 목적은 서론에서 소개한 관리망은 피관리시스템외에 범용 관리자와 관리정보모델의 표현을 포함하며, 작동하는 동안 범용 관리자의 운용이 이 모델표현에 의해 결정된다.

본 발명의 제 2 특징에 따라 문제의 관리망에서 피관리시스템에서 관리 정보모델의 표현은 피관리 목적물의 특별한 클래스의 사례로 구현된다.

제 3 특징에 따라 문제의 관리망은 관리정보모델의 결정가능표현의 형태에 있는 관리정보 모델 사양을 특징하는 것에 의해 달성되고, 상기 모델은 다음을 정의한다.

- 관리관점으로부터 주목의 어느 상태를 피관리시스템은 가정할 수가 있는가 ;

- 피관리시스템이 수용할 수 있는 것은 어느 동작인가 ;

- 특정한 상태에 있는 피관리시스템으로 지향될 수 있는 동작이 어느 것인가 ;

- 피관리시스템이 특정동작을 수용할 수 있는때 그것이 달성하는 것은 어느 상태인가 ;

여기서, 결정 가능한 표현모델이란 위에서 언급한 특성을 사양으로 부터 결정할 수 있도록 위의 정의가 기계해석 가능언어로 표현되는 것을 의미한다.

어느 피관리시스템을 정의하기 위해서 다음을 정의한다.

존재할 수 있는 피관리 목적물의 사례와 ; 이들이 가지는 속성과 ; 이 속성의 가능한 값.

제 4 특징에 따라 문제의 관리망은 피관리시스템의 관리정보모델의 표현을 조절함으로써 외부 사용자가 피관리시스템과 상호 작동할 수 있게 하는 범용 관리자를 특징으로 한다.

상기 목적은 또한 서론에 정의된 방법이 다음의 것을 특징으로 하여 달성된다. 즉, 피관리 목적물이 다른 서브시스템내의 목적물을 이것의 다른 서브시스템내의 목적물에 접속 및 메시지를 여기에 송신할 수 있는 방법으로 및 타 서브시스템내의 목적물의 형식을 알지 않고 이것의 피관리목적물이 이것의 타 서브시스템과 부정합하게 자신의 서브시스템내에 실현된다.

본 발명의 여러 장점의 실시예는 각각의 종속항을 특징으로 한다. 관리시스템을 분리함으로써 다음 장점이 성취된다.

즉, 범용 관리자는 피관리시스템에서 더 많은 응용을 위해 더 많은 관리기능을 위해 재이용될 수 있다. 범용 관리자는 정보모델의 변경에 의해 영향을 받지 않는다.

상이한 버젼의 피관리시스템을 구비하거나 상이한 기능을 지닌 다른 종류의 네트워크들이 공용 관리자에 의해 관리될 수가 있다.

피관리시스템내의 정보모델의 표현 구현의 장점은 다음과 같다.

표현이 네트워크의 노우드에 항상 기록된다. ;

표현은 항상 피관리시스템의 모델에 따른다. ;

공용 관리 지식의 관리를 쉽게 한다. ;

시스템 및 네트워크의 갱신관리를 쉽게 한다. ;

시스템 및 네트워크의 갱신은 작동 방해없이 이루어진다. ;

타임슬롯은 유효한 정보모델에 대해 피관리시스템과 관리시스템이 다른 의견을 하는 곳에서는 발생하지 않는다.

다수의 장점은 정보모델의 결정 가능한 표현 형태로 정보모델의 사양을 만듦으로써 이루어진다.

범용 관리자는 특정 작동후 피관리시스템의 새로운 상태를 예상할 수 있기 때문에 더 강하고, 이는 특정상태에서 허용되는 것은 어느 동작에 있다는 것을 의미한다.

기대성능이 충분히 특정되기 때문에 피관리시스템은 말할것도 없이 관리응용에 대해서도 그의 실현 및 검증이 간단해진다.

사양으로부터 대부분의 구현 코우드의 발생이 또한 가능해진다.

피관리시스템에서 허여된 상태 천이를 유도하는 유일한 작동은 수용할 수 있기 때문에 작동하는 동안 견고성(robustness)이 향상된다.

정보모델의 에뮬레이션과 평가가 간단해져 사양 업무를 더 간단히 한다.

계산상태가 동작상태로 들어가기전에, 동작의 다소 자유순서를 용인하지만 피과리시스템의 완전한 계산상태를 보증하는것에 의해 관리모델을 견고하고 사용하기가 쉽게 하는 것이 가능하다.

본 발명의 실시예들을 수반한 도면을 참고로 설명할 것이다.

도 1은 본 발명의 기본 원리의 블록도.

도 2는 도 1의 하나의 블록 유닛의 구현의 흐름도.

도 3은 본 발명의 관리망 구조의 블록도.

도 4는 도 3의 하나의 유닛의 블록도.

도 5는 하나의 자원의 제어관리시스템 뷰 (view) 의 도면.

도 6은 형식과 사례 레벨 사이 관계를 도시한 도면.

도 7 및 도 8은 사례 레벨의 여러 유닛이 제 1 및 제 2 시스템의 형식 레벨에 공통유닛을 공용하는 방법을 도시한 도면.

도 9는 도 7 및 도 8의 양 시스템의 제어관리시스템 뷰를 도시한 도면.

도 10은 형식유닛에 기록된 정보모델의 예를 도시한 도면.

도 11은 도 10에서 제어관리시스템이 자원표현을 해석함으로써 수행되는 작동을 설명한 도면.

도 12는 정보모델의 변경을 도시한 도면.

도 13은 도 10 및 도 12에서 정보모델을 위반하고, 피관리시스템쪽으로결코향하지 않는 작동의 예를 도시한 도면.

도 14는 신·구 기술이 두개의 제어관리시스템과 관리 도메인에서 공존할 수 있는 블록도.

도 15는 도 1의 본 발명의 원리에 의해 얻어지는 플레임 워크에 포함된 관리시스템 유닛을 도시한 도면.

도 16은 자원의 표현과 인간 이용자 사이의 협력을 도시한 도면.

도 17은 유효하지 않은 협력을 예시한 도 16과 유사한 도면.

도 18은 자원표현이 데이타 구조내에서 어떻게 조직되는 방법을 도시한 도면.

도 19는 관리시스템과 피관리시스템을 포함하는 모델 구동 시스템의 일반 설계를 도시한 도면.

도 20은 두개의 목적형태의 다른 클래스를 도시한 개략도.

도 21은 본 발명을 실행할 때 이용되는 특별한 목적 타입의 특성을 도시한 도 20과 같은 도면.

도 22는 관리정보모델의 형식에 맞는 정상 목적물 클래스와 특별형식의 목적물 사이의 연결을 도시한 도면.

도 23은 정보모델의 발생과 관련하여 코우드 발생중의 다른 순간을 도시한 도면.

도 24∼도 29는 피관리시스템에서 특별한 목적 클래스로 부터 정보를 해석하게 하는 모멘트를 도시한 도면.

도 30∼도 40은 의사 코우드의 정의를 나타낸 도면.

여기서,

도 30은 피관리 목적물의 정의를 도시한 도면.

도 31은 잠재 속성값이 속성 타입에 의해 결정되는 방법을 도시한 도면.

도 32는 작동 정의를 도시한 도면.

도 33은 예비상태의 예를 설명한 도면.

도 34는 끝상태의 예를 설명한 도면.

도 35는 피관리시스템이 일관성을 점검하는 끝상태의 예를 설명한 도면.

도 36은 피관리시스템이 일관성을 유지시키는 끝상태의 예를 설명한 도면.

도 37은 LineDriver 라고 부르는 목적물의 정의를 설명한 도면.

도 38은 종속성 방식의 예를 설명한 도면.

도 39는 본 발명에 연결된 종말조건의 예를 설명한 도면.

도 40은 발생작동에 연결된 끝상태의 예를 도시한 도면.

도 41∼도 44는 특히 도 3 및 도 4에 따라 본 발명 및 여러 특성에 따라 전에 설명한 응용부분을 되풀이하는 블록 및 응용도.

도 45는 속성, 방법 및 예비 및 종말조건을 지닌 피관리 목적물 형태의 사양용 신텍스의 예를 도시한 도면.

도 46 및 도 47은 두개의 다른 목적물 형태를 같은 신텍스를 사용하여 특정화하는 도면.

도 48은 같은 신텍스가 도 46 및 도 47의 목적형태 사이의 종속성을 특정하는 도면.

도 49는 종말/필수조건 사이의 관계를 도시한 개념모델과 응용할 수 있는 개념을 도시한 블록도.

도 50은 도 46과 도 47의 목적형태 사이에 종속성을 유지하기 위해 구현메카니즘의 명세서의 도 45∼도 47에서와 같은 신텍스를 이용한 예를 도시한 도면.

도 51은 도 47의 관련목적타입으로 부터 얻어진 속성으로 같은 신텍스가 도 46을 따르는 목적타입의 속성을 특정화하는 도면.

도 52는 도 51에서 하나의 속성으로 부터 다른 속성으로의 전과를 도시한 도면.

도 53은 일관성 첵크와 함께 트랜스액션 단계를 나타낸 흐름도.

도 54는 C++ 코우드의 클래스에 대해 도 46의 목적형태를 컴파일할 때 얻어진 선언화일의 공중부분을 도시한 도면.

도 55는 도 54에 따르는 화일에 협체된 방법의 C++ 구현의 도면.

도 56은 도 47 및 도 50의 명세서에서 발생한 C++ 선고화일의 도면.

도 57은 도 56의 선고화일의 목적의 두 방법의 C++ 구현을 도시한 도면.

도 58은 필수조건의 점검이 포함된 트렌스액션의 작동을 실행하는 알고리즘의 흐름도.

도 59는 필수조건을 점검하여 목적물을 제거하기 위한 방법에 의해 도 54 의 상태화일의 C++ 익스텐션을 도시한 도면.

도 60은 도 54의 목적물의 두 방법의 C++ 구현을 도시한 도면.

도 61∼도 69는 맵핑 시스템의 설계와 연결하여 선행기술의 상태의 기술을이용할 때 나타날 수 있는 문제를 도시한 블록도.

여기서,

도 61∼도 64는 피관리시스템에서 피관리 목적의 라이브어리 소자를 재이용할 수 있는 관련 문제를 도시한 도면.

도 65 및 도 66은 층이 있는 시스템 구조에서 피관리시스템을 구현할 때 나타날 수 있는 관련 문제를 도시한 도면.

도 67∼도 70은 도 61∼도 66의 문제가 알려지지 않은 피관리 목적과 상호 작동할 수 있는 특정한 형태의 설계에 의해 해결될 수 있는 방법을 도시한 도면.

도 71∼도 74는 도 45∼도 52에서 설명하고 같은 의사 신텍스를 이용하여 도 70∼도 74의 목적 설계를 특정화시키며, 도 47의 목적형태가 프렛트폼 시스템에 포함하는 도면.

도 75∼도 80은 도 71∼도 74 사이의 종속성의 프로그램 코우드 C++ 의 구현을 도시한 도면.

본 발명의 특징에 따라, 관리시스템은 범용 관리자와 피관리시스템의 정보 모델의 표시로 나누어진다.

도 1은 개략도이다. 관리시스템을 2 로 표시했다. 범용 관리자(4) 의 운용은 정보모델 (8) 의 표시에 의해 결정된다. 다시 말하면, 모델표현 (6) 으로부터 범용 관리자는 피관리시스템 (10) 쪽으로 이루어져야하는 동작을 결정할 수 있고, 이 바람직한 상태를 성취하는데 필요한 동작을 결정할 수 있다. 모델표현 (6) 은 피관리시스템 (10) 으로 부터 및 까지의 데이터의 패킷(packet)화의 바른 해석에 사용된다.

새로운 자원이 피관리시스템 (10) 에 도입될 때, 모델표현 (6) 을 변경하기만 하면 된다.

본 발명의 또 다른 특성에 따라, 정보모델의 표현이 피관리시스템에 도입(기록) 된다.

시스템에서 피목적물의 사양 및 구현을 위해 기계 해석 가능 언어가 이용된다. 이 언어에서 사양이 피관리 목적물에 대해서 기록된다. 피관리 목적물의 사양은 일괄해서 관리정보 모델의 사양을 형성한다.

이 사양은 관리정보모델을 위해 구현 스터브 코우드 (implementation stub code) 및 중간포멧을 발생시키는 컴파일러에 전달된다.

구현 스터브 코우드는 수동으로 정련되고 피관리시스템을 구현하도록 컴파일 된다. 이 구현은 다음, 로딩 패키지 (loding packages) 에 관리정보모델의 중간 포멧과 함께 패킷화된다. 이 적재 패키지가 목표 시스템, 즉 피관리시스템에 적재된다. 이 적재과정동안 관리정보모델의 중간포멧이 관리정보모델의 표현을 발생시키는데 이용된다.

피관리시스템내에서 관리정모델의 표현은 피관리 목적물의 특징 클래스 (specific class) 의 사례 (instances) 로 구현된다. 이 클래스는 아래에서 MIM-서버 (관리정보 모델서버)로 표시했다. 피관리 목적물의 각 클래스에 대해서 한 사례가 MIM 서버 클래스로부터 생성된다.

적재 패키지의 발생을 도 2에서 설명했다.

도 2에 따라 피관리 목적물의 사양(12)이 제 1 단계 (11) 에서 기록된다. 다음 단계 (13) 에서 이 사양이 C++ 의 구현 스터브 코우드 (14) 및 목적물 사양의 중간포멧 (16) 에 컴파일된다. 언어 C++ 를 상세히 설명하기 위해 Margaret A Ellis, Bjarne Stroustrup 의 ' The annotated C++ Reference Manual ' 를 참고했다.

단계 (18) 에 따라 피관리 목적물이 C++ 에서 구현된다. 이 구현은 생성된스터브 코우드를 포함하고, 이 코우드는 사양의 중간포멧을 포함한다. 단계 (20)에서 C++ 구현이 22 에 컴파일된다.

피관리시스템에서 패키지 (30) 을 적재할 때 MIM-서버 클래스의 새로운 사례가 적재 패키지에 의해 구현되는 피관리 목적의 각각의 클래스에 대해 발생된다.

본 발명의 또 다른 특징에 따라 관리정보모델 사양이 관리정보모델의 결정 가능한 표현으로 수행된다.

관리 정보 모델은 다음을 나타낸다.

- 어느 상태를 피관리시스템은 가정하는 것이 가능하는 것인가(관리관점으로부터의 주목상태).

- 피관리시스템로의 지향되는 것의 가능한 것은 어느 동작인가.

- 특정상태에 있는 피관리시스템에 지향되는 것이 가능한 것은 어느 동작인가.

- 피관리시스템이 특정동작을 수용하고 있는 경우 이것이 달성되는 것은 어느 상태인가.

관리정보모델의 결정 가능한 표현이란 기계 해석 가능 언어로서 표현된 결과 사양에서 위의 특성을 결정할 수 있다는 것을 의미한다.

도 3의 블록도는 관리기능의 구성의 기본 설계 블록을 도시한다.

관리시스템 (40) 에서 범용 관리자 (42) 는 사용자 인터패이스 (44) 를 포함한다. 이 인터패이스에서 피관리시스템의 모든 피관리 목적물이 검색되고 수정될수 있다.

서론에서 설명한 DCF 데이터 통신기능 (46) 은 CMIP 로 관리 프로토콜을 수행하는 프로토콜 구현이다. 이 통신기능은 본 발명의 부분이 아니다.

피관리시스템 (48) 에, 관리 프로토콜을 종료시키는 범용 에이전트(generic agent) (50) 가 포함되어 있다.

다수의 자원 에이전트(52) 는 피관리시스템의 피관리 목적물의 클래스에 대해서 표현된다. 각각의 피관리 목적물의 클래스에 대해 자원 에이전트가 있다. 피관리 목적의 클래스에 유일한 관리 프로토콜의 종료는 자원 에이전트에서 종료된다.

위에서 언급한 MIM-서버 (54) 는 피관리 목적물의 클래스 MIM-서버용 자원 에이전트이다. MIM-서버는 피관리시스템의 실제 관리정보모델의 표현의 공급기이다.

데이타 베이스 관리기능 (56) (DBMS-데이타 베이스 관리시스템) 은 목적물 지향 데이타 베이스 서버이다. 이것은 목적물 구조 유지 데이타를 기억, 액세스 및 갱신할 수 있다.

피관리 목적물용 보조 인터패이스 (58) (MOSI-피관리 목적 서어비스 인터패이스) 는 자원 에이전트에 의해 공급되는 일반 인터패이스이다. 이 인터패이스내의 동작은 생성, 지음, 기록, 판독 및 방법이다. MOSI 내의 작동은 피관리 목적물의 특정 클래스의 사례에 항상 지향되어진다.

데이타 관리 인터패이스 (60) (DMI-데이타 관리 인터패이스) 는 DBMS 쪽의 인터패이스이다. 이는 목적물 구조 퍼시스턴트 데이터(persistent data)를 생성,지음, 판독 및 갱신하는 작용을 한다.

MOSI-인터패이스의 명세서는 아래와 같다.

범용 목적물 관리자 (42) 는 MIM-서버의 인터패이스를 안다. 이것은 MIM-서버로 부터 데이타를 판독하고, 피관리시스템에 있는 피관리 목적물의 어느 클래스를 확인한다.

사용자 인터패이스 (44) 내에서 예를들어 일반 피목적물 관리자는 피관리 목적물의 특정한 클래스의 모든 사례를 나타내도록 리퀘스트가 행할수 있다. 일반 목적물 관리자는 MIM-서보 (54) 로부터 선택된 클래스의 정의를 판독할 수 있다. 이것은 이 클래스가 DCF 를 경유하여 일반 에이전트에 어떻게 액세스하는 방법을 안다. 또한, 범용 에이전트로 부터의 데이타가 어떻게 해석되는지를 안다.

도 4를 참고하면, 자원 에이전트는 MOSI-서브에이젠트 (subagent)(61) 와, 데이타 목적논리 (62) 와, 보조논리 (64) (CL-보조논리) 로 구성되어 있다. 이것은 외부 인터패이스 (58) (MOSI) 를 제공하고, 두개의 외부 인터패이스, 즉 데이타 목적 인터패이스(66)(DOI-데이타 목적 인터패이스)와, 보조 논리 인터패이스(68) (CLI-보조논리 인터패이스) 를 지니고 있다.

여기서 관리시스템을 범용 관리자와 피관리시스템의 모델의 표현으로 분리하여 도 1에 설명된 원리를 더 자세히 설명할 것이다. 이 분리를 참조목적용 분리모델이라고 부른다.

시스템의 자원 관리를 위해 무슨 관리를 얻는 것인가와 이의 수행방법에 관한 지식이 필요하다. 이를 위해 세개의 기능이 필요하다. 즉, 간단히 '제어관리자'라 불리는 관리시스템의 제어 부분과 자원표현, 자원이 필요하다. 도 5는 세개의 기능 사이의 관계를 상세히 설명했다. 문제는 제어관리자에게 특정자원을 관리하는 일반적 가능성을 부여한다는 것이다. 따라서, 자원의 내부 구조 및 이의 가능한 바인드를 알지 않고 자원을 관리할 수 있는 응용설계를 할 수 있는 프레임워크 (framework) 를 구현해야 한다. 더 정확히 설명하면, 새로운 자원이 추가될 수 있어야 하고, 구 (old) 자원이 제어 관리자에게 영향을 주지 않고 제거 또는 변경될 수 있어야 한다.

이러한 프레임워크는 제어 관리자와 피관리시스템 사이의 어느 관계가 존재하는 각각의 도메인에 적용될 수 있다.

항상 자원표현은 형식 레벨 (type level)상의 진술 (statements) 로 표현된다. 이것은 특정타입의 모든 사례가 같은 자원표현을 공용한다는 것을 의미한다. 도 6에서, 형식 레벨상의 유닛 (T₁-T₄) 은 독립해서 존재하고 사례 레벨상의 유닛 (I1-I4) 간에 공유될 수 있다는 것을 알 수 있다. 특별한 예에서, 도 7에 따른 형식이 유효할 수 있다. 형식 가입자 번호는 사례가 어떻게 해석되어야 하는 방법을 설명하는 정보 (예를 들면 가입자의 포멧, 즉 전화번호를 유지하는데 이용되는 데이타 구조의 종류) 를 유지시킨다.

이 구조기술은 범용 관리자의 사용을 허락한다. 도 7의 목적이 시스템(S1) 에 유효하고, 도 8의 방식이 시스템 (S2) 에 유효하면, 같은 범용 관리자가 시스템 (S1),(S2) 모두를 관리하는데 이용된다.

두 시스템의 관리자 도면을 도 9에 도시했다. 사용되는 것은 같은 범용 관리자이고 이것은 시스템 (S1) 과 시스템 (S2)내의 모델표현을 해석한다. 시스템 (S1),(S2) 의 가입자 번호의 관리정보모델은 다르다.

도 9에서, 관리자는 그의 동작을 시스템 (S1),(S2) 에서 관리되어야만 하는 자원쪽으로 향하게 한다. 보정 신텍스 (correct syntax) 와 데이타 포멧을 얻기 위해, 관리자는 모델표현 (R1) 과 (R2) 을 해석한다. 사용자 관점에서, 관리 프레임 워크는 같다. 즉, 같은 구상, 비유 및 툴(tool)을 사용할 수 있고, 이것을 통해 자원의 실현과 무관계로 이들의 자원의 유효 및 용이한 관리를 위한 수단이 얻어진다.

목적은 물리 및/또는 논리자원을 관리하는 범용 관리자를 설계하는데 이용되는 프레임워크를 구현하는 것이다. 프레임워크는 자원표현 (모델) 과 실제 자원의 엄격하고 형식적인 분리를 통해 수행된다. 자원표현은 제어 관리자라고 부르는 소프트웨어 유닛에 의해 해석된다.

관리자는 사전에, 즉, 일하기 시작하기 전에 어떤 특정자원정보를 필요로 하지 않는다. 이것은 관리자 유닛이 이것에 의해 해석할 수 있는 방식으로 표현되는 어떠한 가능한 자원 표현에도 적응할 수 있다는 것을 의미한다. 주요 장점은 관리자를 갱신하지 않고 새로운 형태의 자원을 도입할 수 있다.

예를 들어, 가입자와 같은 소정의 자원과 함께 새로운 가능성을 이 가입자에게 도입하고, 같은 관리자로 신규 및 오래된 가입자 표현을 관리할 수 있다.

또 다른 예로 전체 새로운 형태의 자원을 구현할 때 이를 관리자 시스템에서 도입할 수 있고, 새로운 자원을 기존의 관리자로 관리할 수 있다.

도 5와 관련해서 인터패이스를 더 자세히 설명할 것이다.

모델용 액세스 인터패이스

이 인터패이스는 자원표현 및 이로부터 수집정보에 연결되도록 제어 관리자에 의해 이용된다. 이 정보는 자원쪽으로 일반 관리동작의 수행에 이용된다. 한 예가 도 10에 있다. 자원표현을 해석함으로써 관리자는 가입자 사례 (I1) 에 관한 작동을 도 11에서 수행할 수 있고, 이 모델과 관련하여 의미론과 신텍스가 유효하다는 것을 알 수 있다.

같은 관리자가 재컴파일 또는 재구성을 할 필요 없이 도 12에 도시된 도 10 의 자원표현의 정보의 갱신/변경을 관리할 수 있다.

어떤 경우에도 도 13에 작동은 자원에 전송되지 않아도 된다. 그리하여 오류 작동이 자원에 전혀 전달되지 않는다.

문제의 인터패이스는 다음 작동을 한다.

1. - 을 - 표현에 접속한다.

2. - 의 표현을 - 이라 해석한다.

자원의 액세스 인터패이스

이 인터패이스는 실제 인터패이스 쪽으로 관리작동의 수행에 이용된다. 이 인터패이스의 작동은 자주 실현종속성이다.

작동

1. 작동 (개방/판독/기록/서치 등) 수행

2. 사건전환

관리능력용 정보 인터패이스

이 인터패이스는 자원을 관리할 때 특정 관리자가 이용할 수 있다.

작동

1. 액세스 체크

2. 액세스 제한

자원능력용 정보 인터패이스

이 인터패이스는 수출되거나 자원표현내에 보여주는 것은 그 자원의 어떤 능력을 인가를 표명한다. 그 실제 자원내의 어느 형태의 능력은 다중화되고, 자원표현내의 단일능력으로서 표명되는 것이 가능하다.

작동

1. - 가능성을 수출한다.

2. - 가능성을 다중화한다.

제어 관리자

문제의 프레임워크의 제어 관리자는 기계 해석 가능하게 표현된 모델표현을 해석할 수 있는 소프트웨어 유닛이다. 이들 표현은 관리자 자원과 피관리자 자원 사이의 가능한 협력을 위해 프로토콜을 나타낸다. 또한, 이들 표현은 피관리 자원내의 개념을 표현하는데 이용되는 데이타 구조를 나타낸다. 많은 제어관리자는 하나의 표현을 이용할 수 있고, 하나의 제어 관리자는 많은 표현을 이용할 수 있다.

표현

자원의 표현은 본 발명의 문맥에서 1 개의 자원내의 약간의 또는 모든 양태의 뷰(view)이다. 1개의 자원에는 많은 뷰를 얻을수 있다. 이런 표현에서, 정보는 인간과 협력하는데 더 정확한 다른 표현으로 변형할 수 있게 정보를 해석할 수 있게 구성되어 있다. 이런 표현은 관리 작동 수행을 위해 필요한 정보를 지닌 다소 지능적인 소프트웨어를 공급하는데 이용될 수 있다.

위에서 설명한 분리모델의 주요 장점은 자원을 관리하고, 서어비스를 관리하는 이들 유닛에 영향을 주지 않고 자원 및 서어비스를 도입 및 갱신시키는 수단을 제공한다는 것이다. 또한, 실제 자원을 관리하는 유닛은 관리되는 유지에 영향을주지 않고 대체/갱신될 수 있다는 것이다. 그리하여 새로운 기술이 이용될 때 이 기술이 관리 도메인에 적합할 때 도입될 수 있다.

오래된 및 새로운 기술은 관리 도메인에서 서로 상존할 수 있다. 예를들어 전기 통신망에 장비 (자원유닛 및 관리유닛) 가 하나 또는 여러 관련 활동에 도입될 수 있다.

도 14에서, 관리 도메인은 유닛의 다른 버전을 지닌 두개의 시스템을 구성한다. 이 버전은 각각의 시스템에서 및 양 시스템 사이에서 다르다. 이 접속에서 다음이 유용하다.

1. 타입 (1) 의 구 (old) 관리자는 타입 (1),(100) 및 (200) 의 자원을 관리할 수 있다.

2. 타입 (100) 의 신 (New) 관리자는 타입 (1),(100) 및 (200) 의 자원을 관리 할 수 있다.

3. 타입 (200) 에 대하여 개발된 관리자는 없다.

4. 모든 타입의 자원은 모든 타입의 관리자에 의해 관리된다.

도 14에서 하나는 비협조적인 방식으로 기술개발이 일어난 1 개의 작업 도메인을 지닌다. 관리자 관점 (수직으로) 으로부터 유닛에 영향을 주지 않고 각각의 층(수평으로)에서 수정이 이루어진다는 것을 알 수 있다.

또한, 위에서 설명한 분리모델이 설계제어 관리유닛과 관련해서 어떻게 이용하는 방법을 지금부터 설명한다.

자원쪽으로 관리작동에 책임이 있는 제어 관리자는 자원의 모델정보를 포함하는 모델표현으로 부터 분리모델 프레임워크내에서 필요한 지식을 얻는다.

관리자는 분리모델에 의해 제공되는 프레임워크에 구축되는데, 이 프레임 워크의 범용 관리자는 도 15에 따라 설계된다.

이 설계는 관리자층 (80) 내의 다수의 유닛을 포함하고 이의 명칭은 도면으로부터 명확하며 모델층 (82) 내에는 자원표현이 있다.

외부 사용자 인터패이스에 적합한 유닛(80)은 관리자를 외부 유닛에 적응시키는 것과 관련해서 이용된다.

이의 예는 윈도우 시스템 (Window systems) 으로 이것은 형태, 메뉴 그래프 표현과 같은 재생성 표현을 조절함으로써 자원과 상호 협력할 수 있다. 또한, 기타 컴퓨터/컴퓨터 시스템, 데이타 베이스 및 관리 도메인의 자체 유닛을 포함한다. 다시말하면, 관리자는 제어 및 의사결정유닛으로서 사용될 수 있다.

인간사용자가 협조하는 상대의 표현의 예로서 도 16을 생각하는 것이 가능하고, 이 도면은 어떻게 윈도우가 도 10에 따른 관리정보모델과 관련되어 있는가를 나타낸다.

또한, 이 정보는 입력신호가 모델에 따라 올바른 것인가를 확인하는 것과 관련해서이용된다. 위의 예에서, 사용자는 도 10의 자원표현에 맞지 않는 전화번호를 도입할 수 없다. 관리자는 사용자를 안내하기 위해 지식을 이용할 수 있거나 무엇이 성취되어야 하는 것을 시사할 수 있다. 도 10에 따라 부적당하고, 도 12에 도시된 사용자 상호 협력은 관리작동으로 변형할 수 없고, 자원에 전달되는 것이 불가능하다. 도 17에 설명된 수행은 분리모델 프레임워크를 이용하는 관리자의 모델해석 능력의 결과를 구성한다.

실제 피관리 자원 (mySubDir) 은 아직 유효한 상태이고 무효작동을 수행하지 않는다.

여기서 설명한 관리자 형태에서, 다수의 검사가 자원 자체에서 수행되는 대신에 모델의 사용자, 즉 범용 관리자에 위임된다. 이것은 1개의 자원이 여러 종류의 사용자의 바램을 만족시킬 수 있다는 것을 의미한다. 사용자 케이스 (user cases) 는 대개 시간이 다르게 정해져 있다. 종래의 구현에서, 가능한 장래 사용자 케이스를 예측해야만 하는 반면, 본 프레임워크에서는 다른 모델표현을 하는 것만을 필요로 한다.

종래의 방법으로 '가입자 번호 자원'은 자원을 표현하는 C++ 문(ststements) 로 도 10에서 설명한 규칙을 구현할 수 있다. 그리하여 자원의 이용자는 전화번호가 727 로 만 시작할 수 있는 문맥 (context) 으로 제한된다.

내부 표현유닛 (86) 은 모델표현을 제어 관리자에 의해 이용하기에 알맞은 표현으로 변형한다. 모델내의 추상 데이타 구조 (Abstract data structures)등은 다른 언어로, 관리자의 작업에 이용되는 데이타 구조로 맵 (map) 된다.

내부 표현유닛은 자원표현을 기록하는데 이용되는 구조를 생성한다. 각각의 각 관리자 도메인에 대해 하나 이상의 이러한 구조가 있다. 개시에서 구조는 비지만 나중에 자원표현으로 채워진다. 이 구조는 다수의 방법 (일차 메모리, 목적 데이타 베이스등) 로 생성될 수 있다.

도 18에서, 자원표현 (R1-R5) 이 데이타 구조내에서 편성되었다는 것을 알수 있다. 이 구조는 자원표현에 액세스 하기 위해 제어 관리자에 의해 사용된다.

또한, 이러한 자원표현은 릴레이션 (relation) 을 가진다. 이러한 릴레이션은관리자 도메인의 모델의 부분을 구성한다 (가입자 카달로그 넘버 (a subscriber catalogue number) 는 LIC 에 대해 릴레이션을 지닌다).

관리정보모델의 범용 내부 표현은 관리자에 의해 피관리시스템의 일관성을 유지하고 어떤 작동이 수행된 후 피관리시스템의 상태를 결정하기 위해 이용된다. 이들 작동은 예를 들어 일관성 위반 (consistency Violation) 을 일으킬 수 있지만, 이런 작동이 피관리시스템에 적용되기 전에 검출될 것이다.

모델을 해석하여 얻은 지식 (knowledge) 은 여러 방식으로 사용될 수 있다. 즉, 모델을 위반하지 않는 관리동작 집합의 생성과 일관성 위반의 자동 해결 : 바른 동작 집합으로의 대화 사용자의 안내 : ' what if ' 분석수행에 이용될 수 있다. 범용 관리자 논리유닛 (88) 은 다른 유닛의 활동을 제어한다. 이 유닛은 또한 다른 유닛으로 부터 보고된 이벤트 (event) 을 토대로 결정을 내린다. 이벤트는 외부유닛으로부터 관리자에게 보고될수 있는 것이 있으며, 이들 이벤트는 이들 관리자에 의해 관리되는 것이 가능한 표현 및 구조에 항상 변환될 수 있다.

외부 표현유닛 (90) 은 관리자의 내부 표현을 80에서 '외부 사용자 인터패이스에 적응하는 유닛'에 연결된 유닛에 의해 이해될 수 있는 표현으로 변형되는 것을 관리한다. 이러한 표현의 예가 X 윈도우 장치에서 재생되는 윈도우를 표현하는 구조이다.

94 에 있어서, 관리작동용 유닛 ' Machine ' 은 관리자 도메인의 자원에 확실히 안내되어야 하는 사실관리작동을 생성시킨다. 이 작동은 관리자의 논리유닛 (88) 중 하나에 의해 제어되는 표현의 내부 또는 외부 (또는 모두의) 협동/제어의 결과로서 생성된다. 양식 (form)을 표현하는 윈도우는 예를들어 관리자에 의해 제어되는 표현이다. 윈도우는 사용자에게 사용자 선택을 보여줄 수 있다. 이들 활동의 어떤 것은 피관리 자원에 전달되는 하나 이상의 관리동작이 될 수 있다.

96 에서 관리시스템 도메인용 유닛 액세스 인터패이스는 관리작동을 제어유닛에 전송하는데 책임이 있다. 문제의 액세스 인터패이스는 여러 관리 프로토콜에 적응될 수 있다.

92 에 있어서, 유닛 모델 인터프리터 (unit model interpreter) 는 모델에 표현된 자원 표현의 해석을 책임진다. 모델 인터프리터는 자원표현을 판독하고, 이를 내부 표현용 유닛에 할당한다.

모델 인터프리터는 자원의 표현을 해석한다. 이 표현은 합의 포맷으로 표현된다. 이 포맷은 사용되는 모델표현의 포맷이다.

관리작동의 수행, 예를들어 가입자 번호를 변경하기 위해 다음 단계가 실행된다.

1. 관리 도메인에 대한 접속이 설정된다.

2. (외부 표현을 위해 유닛 바깥에 있다고 가정한) 사용자가 관리해야할 자원(즉, 가입자) 를 어드레스 하고,

3. 관리자 논리유닛은 관리하고자하는 자원의 내부 표현이 이미 있는지를 내부표현유닛을 경유하여 검사한다.

4. 이러한 표현이 존재하지 않으면, 관리자 논리유닛이 관리자 도메인에 대해 액세스 인터패이스를 경유해 관리작동을 수행하기 위해 관리작동용 ' 기기 ' 에 명령하여 피관리시스템으로 부터 자원표현을 수집한다 (모든 것은 단계 (7) 아래 계속),

5. 수집된 자원표현은 내부 표현을 위해 유닛에 전달되고, 관리자에 알맞는 포멧으로 변형된다.

6. 내부 표현용 유닛은 구조내의 표현을 위치시키고, 이 표현은 관리도메인내의 자원표현의 합이다.

7. 이러한 표현이 존재하면, 관리자 논리유닛은 내부 표현을 외부 표현 유닛을 이용하여 적당한 외부 표현으로 변형시킨다.

8. 외부 표현은 외부 사용자에 맞는 인터패이스에 더 안내되고, 여기서 이런 표현은 사용자(X 윈도우로 도시한 양식을 조절함으로써) 에 의해 이용될 수 있다.

9. 외부 사용자는 가입자 번호 속성 (subscriber number attribute) 의 값을 변경시킨다 (사용자가 값을 이 목적의 장치에 입력시킨다).

10. 입력된 값이 자원표현 또는 자원표현이 존재하는 문맥에 어떤 위반이 있었는지를 모델 인터프리터가 첵크한다 (이는 관리작동의 번호가 피관리시스템 쪽으로 수행된다).

11. 만일 위반이 검출되면, 사용자는 적절한 방식 (즉, 암시 주의 등) 으로 확인한다.

도 15에서 설명하고, 분리모델 문맥에서 사용되는 관리자의 주요 장점은 관리유닛과 이와 코디네이트 (coordinate) 된 자원유닛을 갱신하지 않고, 변화환경에서 자원유닛을 관리할 수 있다는 것이다. 관리 및 자원유닛을 각각 개발할 때 최상의 이용 가능한 기술이 이용된다.

위에서 설명한 분리모델에서 모델표현이 피관리시스템에 기록되는 방법에 관한 실시예를 설명할 것이다. 기술적인 문제는 시간에 따라 변경될 수 있는 어떤 피관리시스템과 관련있는 올바른 관리 정보모델을 지닌 관리시스템을 어떻게 상시 유지시키는 방법이다.

도 19에서, 분리모델에 따라 구동되는 관리시스템 (100) 모델이 나타내는 것처럼, 이 시스템은 다른 시스템의 목적물을 조작할 수가 있다. 관리시스템은 에이전트(104) 를 경유해 피관리시스템 (102) 과 통신한다. 목적물 (106) 을 조절할 수 있게 관리시스템은 피관리시스템을 기술하는 정보를 필요로 한다. 문제는 관리시스템의 관리자 (108) 가 이 정보를 얻는 방법이다.

만약 관리시스템이 필요할 때 관리정보를 판독할수 있게금된다면, 관리시스템은 그의 피관리시스템부터 한층 독립될 수가 있다. 만약 관리시스템과 피관리시스템 사이의 종속성만이 관리정보를 구조화하는 방법이라면 이것 두 시스템을 독자적으로 개발할 수 있다. 이 문제를 해결하기 위해 새로운 목적물이 피관리시스템에 도입된다. 관리시스템이 각각의 시간에 각각의 피관리시스템으로 부터 데이타를 판독할 수 있기 때문에 피관리시스템에 관한 데이타를 기억하는 최상의 방법은 피관리시스템 자체에 데이타를 기억시키는 것이다. 이러한 새로운 종류의 목적물을사용하기 위해서는 어떻게 이것을 구조화하는가 및 어느때 어떻게 이것을 시스템내에 설치하는 것과 같은 새로운 문제가 발생한다.

피관리시스템내에 또 다른 목적물을 기술하는 피관리시스템의 정보를 기억하는 것은 어떤 시간에 관리시스템이 이러한 정보를 판독할 수 있게 하는 방법이다. 하지만, 모든 종류의 목적물을 기술하기 위해 공통 목적물을 이용할 수 있게 하기 위해서는 관리시스템이 임무를 수행하는데에 필요한 정보의 종류를 분석해야만 한다.

피관리시스템에서 모든 정보를 구조화할 때 새로운 목적물에 포함되는 필요가 있다는 것은 피관리 목적물의 클래스를 기술하는 정보라는 것을 알 수 있다. 만일 예를들어 도 20에 나타난 다른 클래스 두개의 피관리 목적물을 비교하면 두 목적물 타입이 속성, 릴레이션 및 방법을 갖는다는 것을 알 수 있다. 이 정보를 이용하면, 일반적으로 피관리 목적물을 기술하는 템플릿 (template) 을 형성할 수 있다. 이 템플릿은 전에 언급했고, 도 21에 도시된 피관리 목적물 MIM-서버에 포함되어 있다. 템플릿을 이용하여 피관리시스템에 이용될 수 있는 각각의 피관리 목적물을 기술할 수 있다. 만일 목적물 타입을 기술하는 정보를 포함하는 MIM-서버 목적물을 설치함과 동시에 피관리시스템에 설치하고, 관리시스템이 MIM-서버 목적 타입을 해석할 수 있으면, 관리시스템이 어떠한 시간에도 피관리시스템의 목적물에 관한 정보를 수집할 수 있다.

문제의 피관리 목적물이 자동으로 발생하고 목적물 사양 자체로부터 기원된 데이타에 의해 채워짐에 따라 MIM-서버 목적물이 어떠한 관리정보를 포함하는가의제한은 피관리시스템을 어떻게 표현상 특정화하는 방법에만 의존한다.

MIM-서버 클래스의 구조가 어떻게 보일 수 있는 방법의 예를 아래에 도시했다. 이 예는 쉽게 판독할 수 있게 되어 있지만 임의어로 특정되어 있고 약어어 설명을 요한다.

- ADT (AbstractData Type) = 압스럭트 데이터 형식

- DD (DataDomain) = 데이터 형식

- Persistent = 데이터 베이스내에 기억되어야 한다.

속성의 리스트 (myAttributeList) 는 속성 필드 (AttributeArray) 로 규정한다. 사실 이 필드는 다이나믹 필드로 소정의 크기를 갖고 있지 않지만 추가되는 각각의 소자에 대해 성장하는 것을 의미한다.

필드는 소자를 포함하며 몰려있는중의 각각의 소자가 MO-시방내의 실제 속성의 특성을 기술하고 있기 때문에 ' Attribute ' 이다. 속성 시방의 조사에 의하면 속성 특성을 기술하는 myName 와 같은 속성이 있다.

myDD 라고 고려할 때, 이것 DD. 로 규정될 수 있다는 것을 알 수 있다. 이것은 다음 명세서에서 더 설명될 것이다.

속성이 정수, 실수 및 기호열과 같은 형이기 때문에, 이 정보는 불가결하다. 문제는 속성이 동시에 모든 형태를 하는 것이 아니라 하나의 형태로만 할수 있다는것이다. 이러한 이유 때문에 여러 형태를 선택하고 정보를 더 공급해야 한다. 이는 WhichOne 에 의해 수행된다.

정식 형태의 속성은 물론, 정수, 10 진수 또는 택스트 기호열이고, 이들은 다음과 같이 특정된다.

8진렬(octet string) 및 열거(enumerated)와 같은 잊어서는 안되는 다른 공통의 형식이 있다.

항상 그런 것은 아니지만 구조형태 및 필드형태(구조 및 어레이)와 같은 속성의 완전한 기술을 가능하게 하기 위해서는 어쨋거나 필요한 다른 형태가 있다. 자신의 형태를 특정화하는 것이 가능하며 레인지는 이 범위의 한 형태이다.

속성은 디펄트 값을 가질 수 있다. 이 정보를 포함하기 위해 특별한 ' 디펄트형 ' 이 특정된다. 이 형태는 디펄드 값이 관련된 것이 무엇인가를 기술하기 위해 WhichOne 를 또한 이용한다.

피관리시스템은 속성, 방법 및 통고 등에 의해 특정될 수 있다. 정보 사양에 이 기술을 사용하는 것에 의해 모든 것이 MIM-서버-클래스에 적합시킬수 있다. 기억된 여러 형태의 리스트가 아래와 같다.

모든 MIM-서버-목적물은 피관리시스템의 완성모델을 구성한다. 이 형태의 목적에 의해 관리시스템이 피관리시스템의 정보를 하나 하나씩 얻도록 할 수 있다. 작동하는 동안 피관리시스템 (즉, 모델) 을 변경할 수 있고, 피관리시스템에 설치되었던 MIM-서버-목적물의 정보를 판독함으로써 재컴파일 없이 피관리시스템의 뷰(view)를 갱신하게 한다.

도 22는 MIM-서버-사례와 피관리 목적물의 클래스간의 관계를 도시했다. '일반 피관리 목적물의 각각의 클래스 (120),(122) 에 대해 피관리시스템 (130) 의 특별한 피관리 목적물의 클래스 (128) 의 사례 (124),(126) 가 있다. 이 특별한 피관리 목적물은 피관리시스템의 관리정보모델 (132) 의 표현을 구성한다.

피관리시스템을 갱신하기 위해, 오직 새로운 MIM-서버-목적물만이 피관리시스템의 새로운 목적 형태를 반영하도록 설치되어 있다. 관리시스템은 다른 MIM-서버-목적과 같은 방식으로 수집할 수 있고, 코우드를 재컴파일 하지 않고 피관리시스템의 뷰의 갱신이 있다. 이는 관리시스템을 매우 안정하게 하고, 피관리시스템은 관리시스템의 갱신에 관한 염려 없이 자주 갱신된다.

MIM-서버 코우드 발생의 실시예의 기술의 서론에서 처럼, 전에 설명한 간단한 요약은 도 2를 참고로 설명된다.

위에서 설명한 간단한 요약은 다음과 같다.

MIM-서버 및 MO-코우드의 발생은 도 23과 비교되는 MO 의 명세서로 시작되는 체인이다. 설계자는 우선 특별한 명세서 언어를 이용하여 MO 를 특정하고 다음 특정 컴파일러에 의해 코우드를 컴파일한다. 컴파일러는 C 또는 C++ 와 같은 표준 프로그램 언어의 소오스 코우드 (source codes) 를 생성한다. 주목표 코우드는 피관리시스템의 실행 코우드이지만 이는 관리정보모델의 피관리 목적 부분의 중간포멧을 발생시키는 전체 시간이다. 이를 성취하기 위해, 컴파일러는 MIM-서버-클래스의 구조 지식을 지녀야 한다. 컴파일러는 MO-시방이라고 간주하고 속성 및 방법의 번호를 카운터한다. 그리고, MIM-서버-사례를 설계하기 위해 이 정보를 이용한다. 이 정보가 피관리시스템의 소오스 코우드의 ' 클래스-방법 ' (' class-method ') 에 도입되고, 피관리시스템에 설치한 후 실행이 자유롭다.

설명한 기술을 이용하면, MIM-서버-정보 및 목적물 코우드의 발생이 같은 MO-명세서로 부터 편집되기 때문에 모델은 기술하는 목적과 일치한다. 이는 MO-설계자가 모델정보를 발생시키려는 의무가 있기 때문에 더 쉽게 한다. 정보발생의 체인이 자동화하면 피관리시스템을 설계하기 용이하고, 신속하고 신뢰성 있게 할 수 있다.

MIM-서버-코우드-발생은 예가 아래와 같다.

컴파일러는 목적물용 소오스 코우드를 발생시킨다. C++ 에서, 이는 다음과 같이 관찰할 수 있다 (코우드는 정확하지 않지만, 예를 들었을 뿐이고 발표 파일은 클래스 MO 를 위해 도시했다).

시간이 복합형식이기 때문에 이것은 또한 분리 클래스이다.

MIM-서버 정보는 발생할 수 있다. 컴파일러는 MO-명세서를 통해 진행하고 피이스(piece) MIM-서보-사례를 설계한다. 이 정보는 여기서 mimInit 로 불리우는 클래스 방법하에 수집된다.

여태까지 시간이 구성되는 속성이 생성되며, 그러므로 또한 시간속성 자체를 구성 및 여기에 대해 다른 속성을 할당하지 않으면 안된다.

클래스는 통상의 C++ 컴파일러에 의해 컴파일될 것이다. 이때, 이 클래스는피관리시스템에 설치될 수 있다. 방법 MimInit 는 이제 실행하려는 준비를 하는 것이고, MIM-서버-사례는 모든 도입 정보로 발생할 것이다. 앞에서 설명했듯이, 소프트웨어는 먼저 시험된 다음, 피관리시스템에 설치될 것이다.

MIM-서버-클래스의 사례를 만드는 방법을 실행하기 위해 MIM-서버-클래스가 피관리시스템에 설치되어야 한다. 따라서, MIM-서버-클래스는 피관리시스템내에 설치된 제 1 클래스이어야 한다.

방법 MimInit 는 클래스 방법이기 때문에 관리시스템이 실행할 수 있는 일반 방법이 아니다.

피관리시스템이 새로운 클래스로 갱신되어야 한다는 것이 결정될 때, 소프트웨어는 사용전 주위깊게 시험되어야 한다. 모든 것이 완료되고, 클래스가 피관리시스템을 클리어 (clear) 하면 소프트웨어는 갱신을 위해 각각의 클래스에서 MimInit 방법을 실행한다. 각각의 클래스가 자신의 MimInit 방법을 지니기 때문에 각각의 클래스의 하나의 사례가 데이타 베이스에 설치된다. 각각의 MIM-클래스가 사례가 된 후 설치된 클래스를 기술하는 노트 (note) 가 전달된다. 이 노트에 대해 가입자인 관리시스템은 당연히 노트를 얻고, 어떤 구 (old) MIM-서보-정보를 갱신하거나 노트를 무시해야 할 것인가를 결정한다.

관리시스템에서 피관리시스템의 모델을 표현을 코드화해서 갖는 대신에 그의 피관리시스템내에 갖는 것은 그 표현이 이것이 기술하는 피관리시스템에 항상 따른다는 장점이 있다. 마찬가지로, 임의의 피관리시스템에 연결된 관리시스템은 모델표현을 판독하고, 이를 관리할 수 있다. MIM 서버클래스는 피관리시스템에 설치된각각 다른 클래스와 유사한 클래스이기 때문에 MIM-서버-클래스 자체를 설명하는 1 개의 MIM-서버-클래스를 지닌다. 이로 인해 관리자는 먼저 MIM-서버-클래스, 그의 버전을 기술하는 MIM-서버-클래스-사례를 판독하고 이 정보는 시스템의 MIM-서버-클래스를 어떻게 해석하는 방법을 결정한다.

관리시스템이 어떻게 액세스하고 피관리시스템에 기록된 모델정보를 해석하는 방법을 이하에서 설명할 것이다.

관리시스템과 피관리시스템 사이에 데이타를 전송하고 정보를 원래 양식으로 클리어하기 위해 수신 시스템은 무엇을 전송하고 어떤 시퀸스인가를 정확히 알 수 있거나 라벨, 즉 소자를 식별하는 것에 의해 정보가 확인되어야 한다. 어떤 방법이 어느쪽으로 사용되는가는 자주 프로토콜이라 불리우는 공통의 정보 또는 규칙이 이것을 성취하는데 이용된다.

여러 다른 데이타 타입이 다른 번호 비트 또는 같은 번호 비트로 코우드되기때문에, 수신 비트 스트링이 해석될 때 각각의 데이타 타입에 포함되는 많은 비트를 정확히 아는 방법이 필요하다. 이것은 이 문맥에서 항상 문제이고, 다른 많은 프로토콜의 번호가 이용될 수 있다. 데이타를 전달 및 재생산하는 여러 수단 사이에서 선택하는 것은 정보가 복합적이라 할수 있고 이 정보가 수신 시스템에 있을 때 이것을 이용할 수 있는 방식으로 재구조해야 한다.

따라서, 모델정보는 양 통신 당사자가 알고 있는 구조에서 표현되어져야 한다. 간단한 데이타 타입을 비트 스트링으로 코딩 및 디코딩하기 위해 내부 통신을 위해 피관리시스템에 이용되는 것과 같은 코딩 및 디코딩 시스템이 여기에 설명한실시예에 이용된다. 이 코딩 및 디코딩 시스템은 데이타 파괴를 방지하기 위해 링크의 당사자에 알려져야 한다.

통신 가능한 비트 스트링에 간단한 데이타 타입을 전달하기 위해, 이 비트스트링의 코딩 및 디코딩에 관한 전략을 지니는 것이 근본이다. 여기서 사용되는 방법은 정수 형태가 값을 표현하기 위해 32 비트를 이용할 수 있게 한다. 스트링은 스트링의 문자번호를 나타내는 32 비트 정수를 이용하여 코우드되고, 각각의 문자는 8 비트로 표현된다.

통신 가능한 비트 스트링에 데이타 타입을 코딩하기 위해 각각의 시프트 방법을 지니며, 이것은 무엇이 일어나는지를 간단히 설명해준다.

간단한 데이타 타입을 위해 코딩 및 디코딩 원리를 이용하여 더 복잡한 데이타 구조에 대해 코딩 및 디코딩 방법을 생성할 수 있다. 이는 일련의 간단한 코딩 또는 디코딩 방법으로 방법을 구현함으로써 간단히 성취된다.

복합 데이타 구조에 대해, 코딩 및 디코딩을 설계하는 이 기술을 사용함으로써 어떠한 종류의 코딩 또는 디코딩 방법을 설계할 수 있다.

관리시스템이 피관리시스템의 사례쪽으로 판독작용을 시작할 때, 어떤 속성이 판독을 원하는 상태라는 것을 표명해야 한다. 속성의 데이타는 위에서 설명한 방법을 이용하여 코우드화되고, 관리시스템에 전달된 다음 디코우드된다. 전송 시스템 및 수신기가 이 정보를 코우드화하는데 이용되는 방법을 알기 때문에 만일 수신장치가 같은 코우드 방법 및 디코우드 방법을 지니면 복잡한 정보를 판독하는데 더 이상 문제가 발생하지 않는다.

MIM-정보를 해석할 수 있게 하기 위해, MIM-서버-클래스 코딩과 디코딩 루우틴(routine) 이 관리자로 통합된다. 이에 의해 피관리시스템에서 수신된 정보는 MIM-서버-클래스로 된 사례에 의해 해석될 수 있고, 이때 비트들은 데이터 버퍼에서 MIM-서버-사례로 시프트 된다.

관리시스템은 도 15의 해석부분 모델 인터프리터에 MIM-서버-클래스를포함하고, 피관리시스템의 MIM-서버-사례로 부터 속성값을 판독하고 코우드화한 데이타를 지닌 버퍼를 수신할 때 데이타는 비트를 버퍼에서 MIM-서버-클래스의 빈 로컬 사례 (empty local instance) 로 시프트 함으로써 쉽게 디코우드 된다. MIM-서버-클래스는 버퍼에 및 로부터 시프트 하는 방법을 지니기 때문에 이는 일을 쉽게 한다. 주요 문제는 MIM-서버외의 다른 클래스를 해석할 때 나타난다. 이 경우에, 정보를 디코딩하는 MIM-서버-정보를 이용해야 한다.

또 다른 실시예를 도 24∼도 28과 관련해서 설명할 것이다.

MO 로 부터 판독된 속성값을 해석하기 위해 관리시스템은 MO 클래스를 기술하는 MIM-서버-정보를 필요로 한다. 이는 MIM-서버의 엠티 사례 및 MO 판독 속성값으로 부터 판독된 속성값의 핸들 (UsrMO) 을 발생시키는 데서 시작한다.

1. MIM local_MIM_Link;//a MIM 서버 사례 발생

2. UsrMO local_UsrMO_Link;//creates a UsrMO 발생

3. get (MIM,Link,myAttList);모델정보 판독

상기 3 단계는 도 24에 설명되어 있다.

4. Buffer>>local_MIM_Link.myattList;//카피충만

관리시스템은 국부적으로 표현된 MIM-서버를 지금 관찰할 수 있고, 클래스링크 (class Link) 를 조사한다. 다음 단계는 관계된 사례 데이타를 MO 목적물에서 추론하는 것이다. 이 절차는 다소 복잡하지만, 다음 단계를 따른다. 도 25는 관리시스템이 링 (A) 로 부터 사례 링크를 추론하는 방법을 예시했다.

5. get(Link, A,a11) ; 모든 속성값을 판독한다. A 로 부터의 사례 데이타는 디코우드를 위해 버퍼의 리스트에서 대기한다. 관리시스템은 비트의 올바른 량을 얻기 위해 시프트 작동을 이용하고 이를 올바른 데이타 타입으로 디코우드한다. 제 1 속성이 데이타 타입인지를 결정하기 위해 논리 MIM-서버를 조사함으로써 제 1 속성이 얻어지고 버퍼로 부터 디코우드 된다. 도 26은 MO 클래스를 표현하는 로컬 MIM-서버가 MO-사례의 제 1 로컬표현을 구축하는데 이용되는 방법을 도시한다.

6. 관리시스템이 데이타 타입 데이타에 들어올 때, 구조화되고 더 조사를 위해 이 구조내로 들어갈 필요가 있다는 것을 알 수 있다. 이는 도 27에 도시되어 있다.

7. 인터프리터는 구조 데이트 (' Date') 를 조사하고, 속성 타입을 조사하기 위해 속성의 리스트를 조사한다. 이 정보를 이용함으로써 다음 버퍼가 해석될 수 있다. 이는 도 28에 도시되어 있다.

8. 해석이 실시되고, 관리시스템이 속성값을 외부 사용자에게 제공할 수 있다. 도 29는 데이타가 해석되는 방법과 다음 속성 타입이 국부 MIM-서버 해석에 판독 방법을 도시한다.

지금으로부터, 전에 설명한 관리정보모델이 어떻게 결정 가능하게 되는가에 대해서 설명할 것이다. 이것은 이와함께 컴퓨터 프로그램은 사양을 판독하고 해석할수 있다는 것을 의미한다. 즉, 피관리시스템이 택할 수 있는 상태 (관리시스템 관점에서 흥미있는 상태), 어느 작동이 피관리시스템이 지향하는가, 특정상태에 있는 피관리시스템에 어느 작동을 지향시킬수 있는가 및 최종적으로 특정상태의 작동을 피관리시스템으로 지향시키는 때 피관리시스템은 어느 상태로 들어가는가.

결정 가능하다는 것을 얻기 위해서, 관리 정보모델은 기계해석 가능 언어로 표현되지 않으면 안된다. 종래의 기술에서, 자연어 (natural language) 는 어느 작동이 피관리시스템 쪽으로 향할수 있게 하는 것과, 어느 작동을 피관리시스템에 지향시킬수 있는때에 피관리시스템은 어느 상태에 있는가에 표현하는데 이용된다. 사양을 결정가능하게 함으로써 다수의 장점이 성취된다. 즉, 범용 관리자는 특정작동 후 피관리시스템의 새로운 상태를 예측할 수 있기 때문에 더 강해질 수 있고, 특성상태로 되고/또는 바람직한 상태의 작동을 제안할 수 있다.

피관리시스템의 구현 및 확인은 물론 (일반적이지 않는), 관리응용은 기대성능이 특정화 되기 때문에 간단해진다. 또한, 사양으로 부터 대부분의 구현코우드를 발생시킬 수 있다.

작동하의 완강성 (robustness) 이 피관리시스템의 허용상태천이를 초래하는 동작만이 수용되기 때문에만 성취된다.

관리정보모델의 초기 애뮬레이션 및 평가가 간단해져 사양 업무는 더 간단하다.

관리모델은 구성이 활성상태로 취소되기 전에 작동의 프리 시퀸스 (free sequence) 를 허락하지만 피관리시스템의 완성된 구성을 보장함으로써 양 로버스트 (robust) 에 모델되고 쉽게 이용할 수 있다.

제 1 가능 상태를 정의할 것이다.

특정 순간의 피관리시스템의 상태는 이들 사례가 이 순간에 피관리시스템에서 피관리 목적물의 사례와 속성값을 나타낸다.

특성 피관리시스템이 취할 수 있는 상태를 정의하기 위해, 피관리 목적의 사례가 존재해야 하고, 어느 속성을 지녀야 하고, 이 속성이 가질수 있는 값을 주어져야 한다.

도 30, 선 (1) 에 주어진 사양으로 부터 클래스 가입자의 목적이 관리되어야하고, 이 클래스의 피관리 목적물은 속성, 선 (3-8) 을 지닌다.

가입자 번호를 표현하는 번호(Number), 행정상태를 나타내는 AdmState, 작동상태를 나타내는 UsageState, 가입자 물리적 단말에 대해 레퍼런스 (reference) 를 라인 드라이버 (line driver) 를 제공하는 라인(line), 피관리시스템의 가능한 상태공간은 이 사양에 의해 확대된다. 새로운 상태의 공간은 가능한 조합의 속성값을 지닌 새로운 잠재적인 가입자를 구성한다.

잠재적인 속성값은 도 31의 선 (24),(28),(32),(37),(41) 에 의해 결정된다. 작동을 다음과 같은 방법으로 규정한다.

피관리시스템 쪽으로 향하는 작동은 피관리 목적물의 사례를 발생, 조작 및 검색한다.

이 생성작동은 피관리 목적의 상태 클래스의 새로운 사례를 생성한다.

지움작동은 피관리 목적물을 취소시킨다.

기록작동은 피관리 목적물의 클래스의 사례의 속성값을 변경시킨다.

방법작동은 피목적의 클래스에 대해 사례의 방법을 호출한다.

판독작동은 사례의 속성값을 리턴 (return) 시킨다.

판독, 기록 발생 및 지움작동은 피관리 목적물의 모든 클래스에 대해 같은 신텍스와 의미법칙을 지닌다. 발생 및 지움작동은 피관리 목적물의 주어진 클래스에 대해 가능 또는 불가능하게 특정화된다.

판독작동은 피관리 목적물의 클래스의 각각의 속성에 대해 가능하지만 특성 및 타입을 정의할 때, 함축적으로 특정화된다.

기록작동은 항상 선택을 면제받고 갱신될 수 있는 속성을 규정하는 것으로 정의된다.

방법작동은 피관리 목적물의 클래스에 대한 특정작동에 대한 탈출 루우트 (escape route) 이다. 이 작동은 방법으로 수행된다. 각각의 방법은 입력 데이타로 파라미터의 리스트를 수신하고, 이 결과를 리턴한다.

도 32는 작동을 정의한다. 선 (61-64) 에서 다음 작동이 정의된다.

속성 Line, Number, AdmState, OpState 라인 (62-63) 의 작동을 판독한다.

속성 라인 (61) 의 작동을 기록한다. 방법 LockRequest 라인 (64), 이 피관리 목적물은 지움을 알지 않고, 또는 작동을 생성하지 않는 것으로 한다 (라인 (65)).

여기서, 작동/상태의 허용결합을 규정하는 방법을 설명할 것이다.

피관리시스템내에 있는 관리시스템의 어느 사례에 종속해서 및 이것의 속성값에 종속해서 특정상태에 있는 허용동작의 특유의 조합이 있다. 이 예는 만약 사례가 이용중인 경우에는 사례가 지울수 없다.

다른예는, 실현 종속성 제약이 있기 때문에, 피관리 목적물의 어느 클래스의제 10 사례를 형성하는 것은 허용되지 않는다.

일반적으로 필요조건 및/또는 종말조건 (end condition) 에 의해 작동/상태의 결합을 특정하는데는 두가지 방법이 있다.

필요조건은 동작이 승인되기 위해서 어느 조건을 만족해야만 한다는 것을 나타낸다. 본 경우에 명령을 받아들이기 위해서 피관리시스템이 어느 상태에 있지 않으면 안되는가를 각 동작에 대해 표명된다. 필요조건은 피관리 목적물의 클래스의 논리부분을 구성한다.

목표물 클래스 가입자와 관련된 우리의 예에서, 우리는 가입자가 비블록 (deblock)화 (속성 AdmState =unlocked)되기전에, 속성 라인이 엠티 (empty) (NULL 로 설정) 하는 것을 방지하기를 원한다. 언급했듯이, 라인 속성은 가입자 물리적 단말의 라인 드라이브 유닛 (line drive unit) 의 레퍼런스 (reference) 이다. 가입자가 이용할 때 이 레퍼런스가 존재하는 것이 바람직하다.

도 33의 라인 (79),(80) 은 표현방법을 도시한다.

종말조건은 갱신 트랜스액션 (updating transaction) 후 채워져야 한다는 것을 기술한다. 본 경우에는, 클래스의 사례가 일관해서 있기 위해서는 어느 상태를 취하지 않으면 안되는가를 표명하는 것이 피관리 목적물의 각 클래스에 대해 가능하다. 종말조건은 피관리 목적물의 클래스의 부분 또는 이러한 클래스의 그룹이다. 후자는 목표물 사이의 의존성에 유효하다.

목적물 클래스 가입자와 관련한 본 예에서, 우리는 속성 라인이 엠티되면 속성 Adm 상태가 비블록화 되는 것을 방지하기를 바란다. 가입자가 이용될 때, 후자의 레퍼런스가 존재하는 것이 안정되기를 바란다. 도 34에서 이것이 라인 (106) 및 (107) 에서 표현된다.

종말조건은 두 방법중 하나로 만족시킬 수 있다. 관리시스템은 종말조건이 만족하는 방식으로 피관리시스템을 갱신한다. 이 경우에, 관리자는 이 상태를 만족시킬 책임이 있다. 만일 관리자가 이 책임을 무시하면, 피관리시스템의 갱신 트랜스액션을 거부하게 된다. 종말조건을 만족시키는 또 다른 방법은 필요한 갱신을 자동적으로 성취함으로써 피관리시스템이 제한을 유지시키는 것이다.

제 1 경우에, 관리자의 전략은 관리자 정보모델 명세서로 부터 결정되고, 이 모델로 부터 작동이 현상태에서 허여 될 것인가를 결정한다. 또 다른 경우에, 작동은 피관리시스템에 의해 자동적으로 수행된다.

도 34의 예에서, 양 전략이 모두 고려되었다. 만일 속성 라인이 엠티이고, AdmState = unlocked 이면, AdmState 가 록으로 설정된다. 하지만, 이 예의 경우에 종말조건은 제 2 전략을 방해한다. 따라서, 제 1 전략이 선택되어야 한다. 피관리시스템의 갱신 트랜스액션이 되기 전에 종말조건이 점검되고, 관리시스템이 상태를 충족시키는 책임을 진다. 도 35의 라인 (124),(125) 은 표현방법을 도시한 것이다.

도 36의 라인 (134) 은 피관리시스템이 일관성을 유지하도록 제 2 전략이 특정화되는 방법을 도시한다.

여태까지는 목적물의 일관성 제한을 조절하는 종말조건만을 논해왔다. 그러나, 목적물 사이의 일관성 제한을 특정화하는 종말조건을 기술할 수 있어야 한다.

도 37에서, 목적물 LineDriver 가 특정된다. 이 목적물은 도 33의 목적물 가입자에 대한 관계이다. 두 목적물 사이의 일관성 제한을 조절하는 목적상태는 특정화 되어야 한다. 도 34의 라인 (118) 과 도 37의 라인 (163) 에서 두개의 목적물은 같은 의존성 목적 LineAndSubscriber 을 구성하도록 특정된다. 이 의존성 계획은 도 38에 도시되어 있다. 가입자가 록될 라인 드라이버를 록해야만 하는 경우 도 38의 라인 (169-171) 의 의존성 목적이 기술된다.

여기서 작동이 된 후, 얻어진 상태의 정의가 어떻게 행해지는가를 자세히 설명할 것이다.

작동을 성취한 후, 피관리시스템의 새로운 상태를 결정할 수 있는 문제의 해결책은 이 상태를 유지시키는 전략법칙과 더불어 종말조건을 이용하는 것을 포함한다.

그러나, 하나의 남은 문제는 방법의 결과를 결정하고, 작동을 발생시키는 방법이다. 이를 위해 개념종말조건이 방법 및 생서동작에의 그 조건을 접속함으로써 확장 및 어느정도 변경된다.

본 예에서, 가입자와 관련된 필수조건은 AdmState 가 관리자가 속성 라인을 엠티하게 수용하는 전제조건으로 록되어야 하는 상태를 기술한다. 관리자는 속성 AdmState 가 판독만 하기 때문에 AdmState 가 록되어야 하는 방법을 알아야 한다. 방법 LockRequest 는 바람직한 효과를 성취하는데 이용되어야 하는 방법이다.

도 39는 라인 (176-178) 에서 특정되는 방법을 도시한다.

이들 종말조건과 개별 또는 그룹내의 피관리 목적물 클래스에 속박돼 있는종말조건과의 차이는 이들 조건이 항상 피관리시스템에 의해 유지된다는 것이다.

도 40은 또 다른 경우를 도시한 것으로, 목적물이 발생한 후 속성 Line 이 Null 과 같지 않게 특정된다. 속성 Line 이 다른 목적물에 대해 레퍼런스 속성이기때문에 가입자 목적물 자체, 목적물 LineDriver를 생성하거나 또는 다른 방식으로 발견하고 속성 라인에 이 목적물을 참조하는 것을 이 사양으로 부터 결정할 수 있다.

여기서, 결정할 수 있는 관리모델을 결정하고 구현하는 방법을 설명할 것이다.

이와 연결하여 언어 C++ 는 또 다른 문맥이 사용된 것을 언급했다.

관리모델은 목적물과 릴레이션을 포함한다. 이는 도 41에 설명되어 있고, 직.간접으로 관련된 네개의 목적물 타입이 도시되어 있다. 이러한 모델에는 목적물 사이에 일관성 제한과 종속성이 자주 있다. 도 41에서 트렁크 목적물(Trunk object) (200) 은 작동하기 위해 포트 목적 (port object) 과 관련된 상태에 의존한다. 따라서, 포트 목적의 작동상태의 속성 (opState) 가 작동하지 않을 때, 트렁크 목적물이 또한 작동하지 않아야 한다. 트렁크 및 포트 목적에 관리상태, 즉 속성 admstate 사이에 유사한 의존성이 있다. 유사한 의존성은 도 41의 다른 관계에서 생각될 수 있다.

관리정보모델이 결정할 수 있게 하기 위해, 이러한 의존성을 분명하게 기술해야 한다. 다음, 관리시스템은 피관리시스템의 특성 갱신작동의 결과를 예측할 수 있다.

데이타 베이스를 액세스 할 수 있는 여러 다른 응용에서 이러한 의존성의 구현은 이 응용을 어렵게 하고, 데이타 베이스의 일관성을 보장할 수 없게 한다. 따라서, 의존성과 일관성 제한을 하게 하는 메카니즘은 데이타 베이스 시스템에서 구현되어야 한다. 데이타 베이스에 기록된 정보에 관한 일관성 법칙을 유지시키는 논리는 데이타 베이스를 액세스 하는 응용이 아니라 데이타 베이스의 논리부를 구성해야 한다. 이 방법에서, 각각의 법칙이 특정되고, 한 장소에서만 구현된다.

서론에 의해, 본 발명 및 여러면에서 설명한 것은 도 3 및 도 4 및 이에 상응하는 텍스트를 도 42∼도 44에 도시된 블록도가 기본도를 비교할 수 있게 응용 가능한 부분에서 요약된다.

피관리시스템 (204) 의 관리정보모델은 속성, 방법, 릴레이션 및 일관성 법칙을 지닌 한 셋트의 피관리 목적물 (206) 을 구성한다. 대부분의 목적물은 DOL-논리(데이타 베이스 논리) 와 영구 데이타 베이스 목적물에 의해 구현된다. (하드웨어 자원을 나타내는 것과 같은) 많은 피관리 목적물은 도 42와 비교해 목적물이 표현되는 물리적 장치로 부터 신호를 액세스 하고 수신하는 정적 프로세스(208) 를 포함한다.

그러나, 데이타 베이스 목적물은 통화응용으로 부터 액세스 되고, 목적물의 관리시스템내에서 보이지 않는 데이터를 포함한다. 피관리 목적물은 실제목적으로 구현되는 것이 아니라 실제 구현된 목적물의 뷰 (View) (210) 를 구성한다. 실제 목적물 (206) 은 자원 목적물로 생각할 수 있다. 따라서, 자원 목적물은 도 42 와 비교해 관리 및 트래픽 관리용 기능을 포함하는 목적물이다.

각각의 자원 목적물 (206) 은 뷰의 관리 목적물을 구성하는 한 셋트의 작동을 포함한다. 이 관리 뷰는 관리정보모델 (214) 을 함께 구성한다. 이 모델 (214) 은 기본 완성 정보모델 (216) 의 뷰이다.

각각의 피관리 목적물은 특별한 타입이다. 목적물 타입은 이 타입의 모든 목적을 위해 공통 특성을 형성한다. 즉, 속성, 방법, 관계 및 일관성 법칙을 형성한다. 각각의 목적물 타입에 대해 논리를 포함하는 자원 에이전트(218) (도 44) 가 있다. 목적물 타입의 각각의 사례는 사례의 영구 데이터 값을 포함하는 데이타 베이스 목적물 (220) 에 의해 표현된다. 각각의 피관리 목적물에 대해서 (정적 프로세서와 함께) 자원 에이전트 (218) 와 데이타 베이스 목적물 (220) 이 있다.

이것은 도 44로 부터 나타난다. 범용 에이전트 (212) 는 MOSI 인터패이스 (피관리 서어비스 인터패이스) (222) 를 경유해 자원 에이전트(218)를 액세스 한다. 이 인터패이스는 관리정보모델에 형성된 작동을 정지시킨다. 자원 에이전트 (218) 는 목적물 사례가 된다. 자원 에이전트 DOL 논리 (224) 는 DMI 인터패이스 (데이타 베이스 관리 인터패이스)를 경유해 사례 데이타 베이스 목적물을 액세스 한다.

해결책은 속성, 관계 및 방법과 같은 개념적 모델링 및 목적물 지향의 영역내에 설정된 특성을 지닌 영구 목적물을 특정화하는 기계 해석 가능 언어를 포함하고 앞서의 필수조건 및 종말조건을 포함한다.

아래의 설명 및 앞 및 끝상태의 상세한 설명에서, 신텍스는 기존 언어의 부분을 구성하는데 이용되는 것이 아니라 예에 의해 원리를 확인하는데 이용된다. 여기서 이용된 의사 신텍스는 전에 설명한 도 30∼도 40 및 도 45에서 나타난다. 아래의 설명은 도 30∼도 40 을 참고로 설명한 것을 부분적으로 반복한다.

도 45의 예는 목적물 타입 표시 AnObject 라인 (1) 을 특정화시킨다. 이것은 세개의 영구 속성, 즉 attr1, attr2 및 attr3 (데이타 베이스에 기록된 값을 속성) 을 포함한다. 이 속성이 수용할 수 있는 형태의 값은 Atyp, 정수 및 정수 4-6 이다. 또한, AnObject 는 2 개의 방법 m1, m2 를 포함한다. 이들 방법은 타입 ArgType 및 AnotherArgType 의 인수 (argument) 를 지닌다(라인 (9-10)). 방법 m2 는 타입 AreturnType 의 값을 리턴한다 (라인 (10)).

도 45의 또 다른 AnObject 는 방법이 실행되어야 할 때, attr2 의 값이 attr3 의 값과 같게 특정화하는 필수조건을 지닌다(라인 (13)). 종말조건은 attr2 의 값이 attr3 의 값 보다 크거나 같은 것을 서술한다 (라인 (16)). 이것은 트랜스액션이 데이타 베이스에서 실행될 때, 위반하지 말아야 하는 제한이다.

도 45의 목적물 타입 AnObject 는 필수 및 종말조건의 간단한 예를 도시한다. 조건이 더 관련된 목적물 타입과 관련될 때, 종말조건이 더 복잡해진다. 이것은 (도 41의 트렁크와 포트 사이의 의존성은 이들 2 개의 목적물 사이의 의존성과 거의 유사하다) ResourceA 와 ResourceB 를 상호 작동시키는 예로 설명할 수 있다.

ResourceA 의 사양을 도시한 도 46을 참고하면, 이 목적물 타입은 2 개의 상태 속성, 즉 admState 와 OpState 를 포함한다. 만일 목적물이 작동하거나 작동하지 않나를 속성 admState 는 서술하는 반면 (라인 (23), 또 다른 측위의 opState 는 목적물이 작동하나 하지 않나를 서술한다 (라인 (24)). 이러한 레퍼런스 속성은 목적물 사이에서 데이타 베이스 관계를 구현한다. 데이터 베이스의 ResourceA 의 모든 사례는 속성 Bref 에서 관련된 ResourceB 사례의 레퍼런스를 포함한다 (라인 (25)).

도 46의 필수조건은 ResourceA 의 사례를 제거하기 위해 admState 가 (목적이 사용되지 않아야 하는 것을 의미함) 록이 같게 되어야 한다 (라인 (32)). 도 46의 종말조건은 ResourceA 의 사례가 ResourceB 목적물과 관련이 있으면 작동만 할 수 있다는 것을 기술한다 (admStat = 록되지 않음) (라인 (35)).

resourceB 의 사양은 도 47에서 알 수 있다. 이는 resourceA 의 Bref 의 인버스 (inverse) 를 구성하는 레퍼런스 특성 Aref 을 포함한다(라인 (45)). 도 47 에서 알 수 있듯이, ResourceB 는 ResourceA 와 같은 필수조건을 갖는다 (라인 (52)).

위에서 설명했듯이, ResourceA 와 ResourceB 와 관련된 종말조건이 있다. 이 종말조건은 두 목적 타입 사이의 의존성으로 간주할 수 있다. 이러한 의존성은 여러 목적 타입을 포함하는 서브시스템 (subsystem) 과 관련이 있다.

도 48에서, ResourceA 와 ResourceB 에 관한 끝상태를 특정화하는 의존성 방식이 특정된다. 관련된 ResourceB 목적물이 '록' 되면, 제 1 조건은 타입 ResourceA 의 목적이 '언록' 할 수 없다는 것을 서술한다 (라인 (62) 및 (63)). 만일 ResourceB 의 opState 의 값이 이에 상응하는 ResourceA 의 opState 의 값을 작동시키지 않으면, 제 2 조건은 작동하지 말아야 하는 것을 기술한다 (라인 (65) 및 (66)).

도 49는 종결 및 필수조건과 적용 가능한 개념 사이의 관계를 도시한 개념 모델을 도시한다. 도 49는 각각의 블록의 상세한 설명없이 자체로 대화해야 한다.

종결 및 필수조건의 의미는 분명해야 한다. 이 개념의 정확한 정의가 설명될 것이다. 종말조건은 관리정보모델로 특정된다. 이 종말조건은 관리정보모델에 적합한 피관리시스템에서 위반되지 말아야 하는 정적 일관성 법칙을 서술한다. 종말조건은 피관리시스템의 데이타 베이스에 더 정확히 적용할 수 있다. 종말조건은 데이타 베이스에 기록된 목적물 사례와 속성값에 관한 것이다 (도 49와 비교).

전에 언급했듯이, 종말조건은 속성값 사이의 의존성을 기술한다. 또 다른 예는 속성과 데이타 베이스 관계 사이의 기본이다. 즉, 속성값의 번호에 관한 제한이다. 이것은, 또한 목적물 타입의 사례의 번호에 관한 제한을 할 수 있다.

어떤 제한을 기술하는 특정 종말조건에 적합해야 하는 데이타 베이스는 이 제한을 위반하는 상태에 결코 통과하지 말아야 한다. 작동이 기록된 정보를 갱신할 때, 데이타 베이스의 상태 천이가 일어난다.

갱신작동은 트랜스액션에서 수행된다. 트랜스액션은 작동결과를 포함한다. 트랜스액션은 모든 작동이 수행되거나 수행되지 않는 방식으로 아토믹 (atomic)으로 간주할 수 있다. 이것은 작동을 하거나 뒤로 롤링 (rolling) 함으로써 성취된다. 트랜스액션은 각각의 작동이 성공적인 경우에만 수행된다. 어떤 것이 트랜스액션 동안 잘못되면, 롤백된다 (즉, 모든 작동이 되지 않음).

따라서, 트랜스액션이 종료될 때, 데이타 베이스는 일관성 상태를 취할 수 있다. 트랜스액션은 데이타 목적물의 카피(copy)만을 처리하고, 실제 목적물은 트랜스액션이 있기 전에 갱신되지 않는다. 이것은 일관성 법칙이 트랜스액션동안 일시적으로 위반한다는 것을 의미한다. 트랜스액션이 될 때, 제한 위반이 발생하지 않아야 되지만 발생한다.

필수조건은 특성 작동이 수행되어야 할 때 만족되어야 하는 법칙을 기술한다. 더 정확히, 데이타 베이스는 트랜스액션이 시작되기 전에 법칙이 만족해야 하는 상태이어야 한다 (도 49와 비교).

필수조건은 데이타 베이스의 작동의 시퀸스를 제한하는데 이용된다. 상태 천이의 제한이 또한 표현될 수 있다.

여기서, 실현기구를 어떻게 특정하는 것이 설명된다.

종말조건과 관련되어 있듯이, 전에 설명한 것처럼 구현의 2 개의 또 다른 원리가 있다. 하나의 원리는 트랜스액션이 일어나기 전에 실행되는 트랜스액션의 일관성 점검이다. 종말조건이 위반되지 않으면 트랜스액션이 되고 그렇지 않으면 롤백(roll back) 된다.

또 다른 원리는 자동 정정 조치이다. 이것은 트리거 작동 (triggered operations) 으로 수행될 수 있다. 더 정확히 설명하면, 특성 속성이 갱신될때, 작동은 특정기회에 트리거된다.

도 50의 사양은 이 다른 구현 메카니즘이 특정될 수 있는 방법을 도시한다. 각각의 목적의 속성 admState 에 관한 제 1 종말조건은 트랜스액션이 시작되기 전에 일관성 점검으로 구현하기 위해 특정된다 (라인 (73-77)).

제 2 종말조건은 자동 정정으로 부분적으로 특정된다. 비작동이 ResourceB의 opState 에 할당될 때, 작동은 ResourceA 의 opState 에 할당된다. 작동이 ResourceB 의 opState 에 할당될 때, 일관성 점검이 수행된다 (라인 (79-79)).

도 50의 종말조건의 완전 자동 구현이 바람직할 때, 구현은 다소 더 복잡해진다. ResourceA 의 속성 opState 는 resourceA 의 내부상태와 ResourceB 의 상태에 의존하는 구동 가능한 속성으로 간주할 수 있다. 도 51은 ResourceA 의 opState 가 얻어진 속성으로 특정할 수 있는 방법을 도시한다(라인 92-95)). opState 의 값은 다른 2 개의 속성, 즉 internalOpState 와 ResourceBstate 으로 부터 산출된다. 속성 ResourceBstate 는 ResourceB 의 opState 의 맵핑 (mapping) 이다. ResourceB 목적의 opState 의 값이 변할때마다 이것은 ResourceA 목적의 ResourceBstate 를 따라 전파된다 (라인 (117),(118)). 이것은 도 52에 도시된 ResourceAandB 의 의존성 계획에서 특정될 수 있다.

종결 및 필수조건을 C++ 에서 구현할 수 있는 방법을 상세히 설명할 것이다. 이 구현은 구현 메카니즘의 단계에서 설명한 명세서로 부터 자동적으로 발생한다.

먼저, 종말조건이 처리될 것이다.

일관성 검사의 구현은 각각의 목적 타입으로 컴파일 된다. 이것은 각각의 목적물이 목적물에 관한 모든 제한을 점검할 수 있다는 것을 의미한다. 목적물의 일관성 점검은 트랜스액션이 되기전 목적을 조절할 때 수행되어야 한다.

도 53에서, 트랜스액션의 단계는 250 에 따라 수행된다. 다음, 조절된 모든 목적물은 252 에 따라 일관성 점검을 수행하여야 한다. 만일, 일관성 제한이 위반되지 않으면 트랜스액션이 254 에서 끝나고 그렇지 않으면 256 으로 롤백한다.모든 갱신작동은 일관성 점검이 수행되기 전에 이루어져야 한다.

일관성 점검의 자동 발생 구현을 도시하기 위해 도 46의 예가, 이용될 수 있다. 특정종말조건을 유지하기 위한 법칙이 특정되지 않으면 구현을 디펄트에서 일관성 점검이 되어야 한다. 도 46의 ResourceA 의 종말조건은 일관성점검으로 수행된다. 자동 발생 구현 코우드는 C++ 에 도시되어 있다. 따라서, 목적 타입 ResourceA 는 C++ 의 클래스에 컴파일 된다. 이 클래스용 선언 화일이 도 54에 도시되어 있다.

도 54의 클래스는 사실 자원 에이전트의 구현이다. 파라미터로서 주키이의 값으로 정적방법을 개방하라고 호출함으로써(라인 (134))이 자원 에이전트는 데이타 베이스 목적에 사례화될 수 있다. 자원 목적의 각각의 영구 속성 (admState, opState 및 Bref) 에 대해 자원 에이전트가 사례가 되는 데이타 베이스 목적에 속성값을 기록 및 판독하는 기록 및 판독방법이 있다.

이 문맥의 도 54의 주목되는 것은 라인 (137) 의 방법이다. 이는 트랜스액션이 일관성 법칙을 점검하기 위해 수행되기전에 호출되는 방법이다. 이 방법의 구현은 도 55에서 알 수 있다. 여러 관련 목적에 관련된 종말조건이 (도 48에 도시된 것처럼) 관련될 때, 일관성 점검이 각각의 목적에서 수행되어야 한다.

앞으로 트리거 작동과 전파 동작을 설명할 것이다.

자동 정정의 구현이 발생할 수 있는 방법을 설명하기 위해, 우리는 도 50의 사양을 이용할 수 있다. 라인 (82) 에서는 비작동이 opState 에 할당될 때, ResourceB 의 opState 의 값이 ResourceA 의 opState 에 전파된다. ReseourceB의 선언화일은 도 56에서 발견된다. 주된 주목은 방법 setOpState 와 propagateOpState 이다 (라인 (198),(203)). 도 57은 이 방법의 구현을 도시한다.

도 57에서 알 수 있듯이, 방법 setOpState의 방법 propagateOpState 는 속성 opState가 작동에서 비작동으로 변경될 때 호출된다. 이것은 propage-OpState 가 작동에서 비작동의 상태 천이로 트리거 된다. 이 트리거 작동은 OpState 의 새로값을 관련된 ResourceA 목적에 전달한다.

필수조건은 특정한 작동이 수행되어야 할 때 유효한 상태이다. 종말조건 반대에는 의문시되는 작동이 트랜스액션으로 수행되기전 필수조건이 결정되어야 한다. 필수조건은 자동 정정처리로 거의 수행되지 않아 일관성 점검으로만 구현될 수 있다. 종말조건에 대한 또 다른 차이점은 필수조건의 트랜스액션의 카피대신 데이타 베이스에 기록된 원 속성값을 액세스 해야 한다.

도 58에서 트랜스액션의 작동의 성능의 알고리즘이 예시되어 있다. 도 58의 260 에서 알 수 있듯이 트랜스액션은 필수조건이 위반될 때 롤백된다.

도 59에서, 선언화일은 도 46의 사양으로 부터 발생된다. 도 59의 사양은 deleteObject 작동에 관한 필수조건을 평가하는 방법을 포함한다(라인 268). 이 방법을 deleteObject 작동이 수행될 때 트리거 되어야 한다.

도 60은 ReseourceA 에서 방법 deleteObject 및 deleteObjectCondition 의 자동 발생 구현을 도시한다. deleteObject 에서 방법 deleteObjectCondition 은 목적이 제거되기 전에 호출된다. 방법 deleteObjectCondition 은 방법 admState DatabaseValue 를 지닌 데이타 베이스에 기록된 admState 의 값을 판독한다. 만약, 조건이 admState 가 록되어야 하다면, 예외가 드루운 (thrown) 되고, 한편 조건이 유효하면 목적 사례가 deleteObject 에서 호출되는 데이타 베이스로 부터 지워진다.

위에서 설명한 장점은 다음과 같다.

구현 코우드는 관리시스템에 의해 해석되는 같은 확인 사양으로 부터 자동으로 발생 (컴파일) 될 수 있다. 모델의 사양의 수정은 정보 베이스의 오퍼레이터의 뷰와 같은 구현을 자동적으로 갱신된다. 따라서, 피관리시스템은 관리시스템에 의해 예상된 방식으로 수행하는 것을 보증한다.

각각의 일관성 제한은 특정화할 때만 필요하다. 구현은 일관성 제한에 함된 속성과 함께 캡슐화된다. 일관성 점검은 데이타를 액세스하는 응용을 구현하는데 필요하지 않다. 따라서, 코우드의 유지는 간단히 된다.

시스템에서 모든 일관성 제한은 같은 방식으로 구현된다. 믿을 만한 코우드가 자동으로 발생된다.

구현 전략은 의존성을 목적 사이의 통신이 유지하는 방식으로 비집중된다. 피관리시스템에 새로운 의존성을 지닌 새로운 목적 타입의 도입에 수정되어야 하는 집중기능은 없다.

트랜스액션에 포함된 목적은 일관성 점검의 성능이 비일관성 상태에 있기 전에 잠재적으로 할 수 있다. 이것은 트랜스액션의 작동 명령이 덜 중요한 방식으로 데이타 베이스의 관리를 간단히 한다.

위에서 설명한 해결책은 언코디네이트적으로 개발된 시스템 성분 사이의 의존성의 구현을 쉽게 한다. 이 해결책을 컴파일되고 부하된 시스템 성분에 적용할 수 있다.

시스템 성분의 케이스 언코디네이트 구현을 상세히 설명할 것이다.

피관리시스템은 여러 서브시스템, 즉 시스템 프렛트폼과 다수의 응용을 포함한다. 이 서브시스템은 언코디네이트적으로 개발되었고, 각각 로드된다.

응용 또는 시스템 프렛트폼을 개발할 때, 재사용 소자를 갖는 라이브러리(libraries) 가 있다. 이들 소자는 다른 서브시스템에 여러 다른 방식으로 합체 결합되어 있다.

위에서 설명한 2 개의 다른 문제는 공통적인 특징이 있다. 시스템 소자는 언코디네이트리적으로 개발되었지만 소자 사이에 의존성이 있다. 이러한 의존성을 유지시키기 위해 소자는 각각 개발되고 코우드된 다른 성분과 통신할 수 있어야 한다.

아래에 자세히 설명된 설계 과정은 유사한 문제를 지닌 2 개의 상이한 문맥에서 이용할 수 있다.

제 1 성분은 라이브어리 소자 (library components) 의 재사용에 관한 것이다.

이 재사용 소자는 피관리시스템의 목적에 합체할 수 있다. 도 61에 도시되어 있듯이, 메인라이브러리(260)는 MOstateComponent(262) 및 WorkingState-Component (264) 와 같은 베이직 기능을 지닌 소자를 포함한다. 이들 소자는 많은 다른 형태의 피관리 목적에 공통인 서술 속성을 포함한다. 이 베이직 성분의 기능은 특정 기능을 가진 다른 소자에 의해 재사용 된다. 통화 관리 라이브어리 (266) 에서, StatePropationComponent (268) 는 MOstateComponent(262) 의 상태 천이를 관련 의존 목적 (270) 에 전달할 수 있다.

소자는 물론 피관리 목적물은 목적물 지향 언어로 구현된다고 해야 한다. 소자와 피관리 목적물은 실제 목적물이다. 그러나, 소자는 응용시 식별 목적물로 존재할 수 없다. 이들은 단지 피관리 목적물의 부분을 형성할 수 있다.

다른 베이스 성분에 의존하는 소자를 구현하는 스트레이트포워드 방식(stragightforward way), 예를 들면 도 61의 폴트 조절 소자 및 통화 관리 라이브어리는 계승(heritage) 또는 결집(aggregating)에 의해 기본 소자를 포함해야 한다. 그러나, 이는 많은 문제를 야기한다. 이는 여러 소자, 즉 같은 기본 소자, 즉 MOstateComponent(262)를 계승(inherit) 또는 결집하는 FaultHandlingComponent (272) 및 Resource-ManagementComponent는 같은 피관리 목적 루트 (276) 를 포함한다(도 62 비교). 만일 베이직 소자가 소자에 외부적으로 볼 수 있는 데이타를 포함하면 이것은 일관성 문제를 야기하는 피관리 목적물에 베이직 성분의 여러 카피가 있다는 것을 의미한다. MOstateComponent는 MOstateComponent가 포함되는 피관리시스템의 또 다른 기능에 이용되어야 한다.

위에서 설명한 문제를 회피할 수 있는 방법이 있다.

MOstateComponent 는 이 소자에 의존하는 소자에서 계승되거나 결집되지 않는다. 그러나, 의존 소자는 MOstateComponent 의 레퍼런스 속성을 포함한다. 따라서, 후자는 이것이 포함되는 이들 목적물의 소자이다. MOstateComponent 를 액세스 하는데 필요한 소자는 MO-상태 소자의 같은 사례의 레퍼런스를 각각 포함한다 (도 63 비교).

전에 언급했듯이, ReseourceManagementComponent (274) 와 FaultHandling- Component (272) 와 같은 소자는 MOstateComponet (262) 의 상태 변화에 의해 트리거 되는 기능을 포함한다. 따라서, 후자는 상태 변화 메세지를 다른 소자에 전달할 수 있어야 한다. 그러나, 문제는 메세지의 수신기가 MOstate- Component 의 설계에서 공지되어 있다. MOstateComponent (262) 는 임의 후 출현 소자와 280, 282 가 통신할 수 있게 해야 한다 (도 64 비교).

제 2 문제는 층있는 시스템 아킷텟쳐 (layered system architecture) 에 관한 것이다.

피관리시스템은 층있는 아킷텟쳐에서 구현될 수 있다. 시스템 프렛트폼은 다른 응용에 의해 재사용 되는 기본 기능을 지닌다 (도 65 비교). 시스템 프렛트폼 (290) 은 다른 종류의 공통 전기 통신 서어비스를 포함한다. 따라서, 응용은 많은 업무를 시스템 프렛트폼에 위임할 수 있다. 시스템 프렛트폼 (290) 과 응용 (292) 은 각각 로드된다. 프렛트폼의 리로딩(reloading) 없이 응용을 로드하고 이를 시스템 프렛트폼에 링크 (link) 할 수 있어야 한다.

시스템 프렛트폼 (290) 과 응용 (292) 은 피관리 목적물을 포함한다. 프렛트폼 (290) 의 목적물 (294),(296) 은 스위치, 전송 루우트, 트렁크로 자원을 표현할 수 있다. 응용 292.1 resp 292.2 내의 목적물 (298),(300),(302),(304) 는 시스템 프렛트폼의 자원과 관련되어 상호 작동한다 (도 66 비교). 따라서, 응용내의 목적물은 어떤 임무를 시스템 프렛트폼의 목적에 위임할 수 있다. 응용내의 목적물은 작업할 수 있도록 시스템 프렛트폼내의 관련된 목적물에 의존할 수 있다.

시스템 프렛트폼이 응용 개발 과정에서 이미 알려졌기 때문에 시스템 프렛트폼의 목적물과 통신하는 응용 목적물을 설계하는데 문제가 없다. 전에 설명했듯이, 응용의 목적물은 시스템 프렛트폼의 목적물에 의존한다. 이것은 시스템 프렛트폼의 목적물이 전에 설명했듯이 상태 변화를 응용 목적물에 전달할 수 있다는 것을 의미한다. 이것은 프렛트폼이 관련되고 프렛트폼 시스템의 설계에서 알려지지 않은 호출 목적을 시작한다는 것을 의미한다.

유사한 문제를 지닌 두 경우는 설명되어 있다. 이 문제를 해결할 수 있는 방법을 설명할 것이다.

두 경우의 진정한 문제는 알려지지 않은 또 다른 목적물과 통신할 수 있는 목적물을 설계해야 한다는 것이다. 원래 목적물은 수정 심지어 원래 목적물의 재로딩없이 알려지지 않은 목적물과 관련해서 상호 작동할 수 있어야 한다.

이 문제는 도 67에 예시한 설계 원리로 해결될 수 있다. 원래 목적물(330)은 요약 목적물 (332) 과 상호 작동하도록 설계되어 있다. 요약 목적물은 비구현 방법을 구성하는 인터패이스를 정의한다. 원래 목적물에 의해 호출될 수 있는 방법이 있다. 원래 목적과 상호작용하도록 표시된 목적물 (334) 의 설계에서, 이것은 요약 목적물 (332) 을 계승하고, 이 계승된 방법을 구현한다. 알려지지 않은 형태의 목적물과 상호작용할 때, 원래 목적물 (330) 은 이를 요약 타입(332) 으로 간주한다. 요약 목적물 (332) 의 인터패이스에 규정된 방법을 호출할때, 호출은 나중의 바인딩 (binding) 을 경유해 실제 목적물 (332) 의 구현에 위임된다.

미래의 목적물이 로딩할 때, 원래 목적물의 재로딩의 회피는 동적 링킹에 의해 성취된다.

도 68은 바로 위에서 설명한 설계가 기본 라이브어리 소자의 설계에 이용될 수 있는 방법을 설명할 것이다. MOstateComponent (340) 은 요약 목적물, 즉 MOstate-Subscriber (342) 계승하는 목적물과 통신하도록 설계되어 있다. 이 요약 목적물이 상태 변화가 일어날 때, MOstateComponent 에 의해 호출된 방법을 정의한다. 만일 소자가 MOstateComponent 의 상태 변경에 신청하면, 이는 MOstateSubscriber (342) 을 계승하고, 상태 천이 확인에 대한 답을 구현한다. 이 신청 소자는 가입자로 MOstateComponent 에 서술되어야 한다.

도 67과 관련되어 설명된 설계 원리를 응용 특정 목적물과 상호 작용하도록 시스템 프렛트폼에서 목적물을 설계하는데 이용될 수 있다. 이는 도 69에 도시되어 있고, 목적물 PlatformObject1 350 이 응용 시스템(354)에서 목적물(352)과 협력하도록 구성되어 있다. 목적물 Plateformobject1 350 과 협력해야만 하는 응용의 목적물은 요약 목적물 Interfaceobject (356) 을 계승해야 한다. Plateform-Object (350) 와 InterfaceObject (356) 사이에 데이타 베이스 관계가 있다. 시스템 재로딩 없이 부하 응용을 가능하게 하기 위해 프렛트폼 동적 링크가 이용된다.

응용 시스템의 목적물은 보통 시스템 프렛트폼의 또 다른 목적물의 의존 상태이다. 상태 의존성이 아래에 자세히 설명되어 있듯이, 구현될 때 서로 아는 목적에 대해 같은 방식으로 상태 의존성을 이 구조는 가능케 한다.

비협조된 목적물 사이의 의존성은 위에서 설명한 협조된 목적물 사이에서 같은 방식으로 특정되고 구현될 수 있다. 그러나, 목적물 타입 ResourceB 는 프렛트폼 시스템에 속한다고 가정했다. 따라서, 도 70을 참고하면, 여러 응용시스템의 여러 종류의 목적물이 목적물 ResourceB (370) 과 관련되어 상호 작동할 수 있다. 목적물 타입 ResourceB (370) 은 데이타 베이스 관계를 경유하여 UserObject (372) 에 관계된다. ResourceA (374) 는 ResourceB (370) 에 관련되게 하도록 UserObject (372) 를 계승한다. 다음 설명에서, 이 목적이 특정화되고 구현되는 방법을 설명할 것이다. 같은 의사 신텍스가 위와 같이 이용된다.

목적물 ResourceB 의 사양은 도 71에서 발견된다. 사양은 2 개의 상태 속성 admState 와 opState 를 포함하는데, ResourceB 의 사례를 할당하는 방법과 ResourceB 의 소거를 가능하게하기 위해 이것을 록해야 하는 것을 표명하는 필수조건을 포함한다. 이는 전과 근본적으로 같다. 유일한 차이는 ResourceB 가 ReseourceA 대신 User-Object 와 관련된다는 것이다. 이 관계는 레퍼런스 속성 userRef 라인(6) 을 경유해 설정된다.

도 72에서 목표물 UserObject 가 특정된다. 이것은 상태 속성 admState 를 포함한다. 그러나, 주목되는 것은 이 속성이 순수하게 가상적이기 때문에 특정되는 것이다(라인 19). 이것은 UserObject 가 실제로는 속성 admState 를 포함하지 않는다는 것을 의미한다. UserObject 의 인터패이스는 이 속성에 대해 구현되지 않은 기록방법과 판독방법을 포함한다. 이들 가상적인 방법의 실제 구현은 UserObject의 각각의 서브타입 (subtype) 에서 일어난다. 관련된 목적 ResourceB 에 opState 값을 유지시키는 또 다른 속성 ResourceBstate 가 있다. 또한, UserObject 는 타입 ResourceB 라인 (21) 의 목적물과 관계를 설정하는데 이용되는 레퍼런스 속성 Bref 를 지닌다.

목적물 UserObject 와 목적물 ResourceB 를 포함하는 끝상태를 특정화하는 의존성 방식은 도 73에서 발견할 수 있다. 만일 관련된 목표 ResourceB 가 록되면 목표 UserObject 가 록할 수 없는 방식으로 UserObject 가 ResourceB 의 admState 에 의존하는 종말조건이다.

도 73에서, 목적물 ResourceB 의 opState 의 값이 변경할 때 새로운 값이 UserObject 의 관련 사례에 전파해야 하는 것이 또한 규정된다. 도 73의 사양과 도 52의 사양 차이를 알 수 있고, 도 73에서 opState 에 관해 특정된 종말조건이 없고, ResourceB 의 opState 의 변화가 UserObject 의 속성 resourceBState 에 전달만 되는 것을 나타낸다 (라인 (36),(37)). 이것은UserObject 의 모든 서브타입이 ResourceB 에 의존하는 opState 를 반드시 필요하지 않지만, 각각의 UserObject 의 서브타입은 자신의 방식으로 ResourceB 의opState 의존성을 관리할 수 있다.

도 74는 ResourceA 의 사양을 도시한다 (라인 (41)). 이것은 ResourceA 가 UserObject 의 속성, 방법, 상태 및 전달은 계승한다는 것을 의미한다. UserObject 의 모든 실제 사양은 ResourceA 에서 특정되고 구현되어야 한다.

도 67에서 분명하듯이, ResourceA 의 opState 의 값은 (UsreObject 로 부터 계승한) 속성 internalOpState 와 resourceBstate 로 부터 얻는다 (라인(46-49)).

위에서 언급했듯이, 구현은 같은 시스템에 속하는 목적물의 때와 같다. 차이는 ResourceB 를 이용하는 의존 목적물의 기능의 어떤 부분은 UserObject 에서 구현된다. 전에 설명되어 있듯이, 코우드는 컴파일러에 의해 사양으로부터 자동적으로 발생될 수 있다. 도 72의 UserObject 의 사양으로부터 발생한 선언화일은 도 75에서 발견될 수 있다.

UserObject 의 방법 checkConsistency 는 도 73의 의존성 방식으로 진술된 admState 속성 사이의 의존성을 점검한다. 이 방법의 구현은 도 76에 도시되어 있다. 이 상태를 점검하기 위해 UserObject 의 admState 의 값이 판독되어야 한다. 이 속성이 UserObject 에 포함되지 않을지라도, 이것은 UserObject 에 admState 있는 이유를 설명한다.

도 71의 ResourceB 의 사양에 의해 발생되는 선언화일을 도 71에서 발견된다. 이것은 도 56과 거의 같다. 새로운 값이 관계한 UserObject 사례의 속성 ResourceBstate 에 전달된다. UserObject 와 ResourceB 사이의 admState 의존성이 목표 ResourceB 가 갱신되고, UserObject 사례가 갱신될 때 점검되어야 한다. 따라서, 이 상태가 ResourceB 의 방법 CheckConsistency 에서 구현된다.

도 79는 ResourceA 의 사양으로 부터 발생한 선언화일을 도시한다. ResourceB 의 opState 의존성은 opState 값을 ResourceBstate internal-OpState 를 뺌으로써 구현된다.

위에서 설명한 장점은 다음과 같다.

비협조 목적물 사이의 의존성 및 상호 작동은 같은 서브 시스템의 목적물 사이의 의존성과 같은 방식으로 특정 및 구현된다. 이것은 관리시스템을 볼 수 있고, 해석할 수 있다는 것을 의미한다.

제어 및 볼 수 있는 방식으로 협조된 목적물 사이의 의존성 유지의 상기에서 설명한 과정은 층이 있는 아킷텟쳐의 결정 가능한 구현 모델의 구현을 쉽게 한다.

라이브어리의 재사용 정도는 소자 결합이 관련될 때 매우 크게 향상된다.

Claims (13)

1. 전기통신 시스템 또는 개방 시스템용 하나 이상의 관리 시스템과 하나 이상의 피관리 시스템을 지닌 관리망에 있어서의 피관리 시스템의 서브시스템에서 피관리 목적물을 구현하는 방법에 있어서, 서브시스템은 하나 이상의 피관리 목적물을포함하는 피관리 시스템의 각각의 부분을 의미하며, 피관리 목적물은 다른 서브시스템의 다른 피관리 목적물에 연결되고 메시지를 송신할 수 있는 방식으로 다른 서브시스템의 목적물 형식을 알지 못하고 다른 서브시스템에 대해서 비협조적으로 상기 피관리 목적물이 서브시스템에서 구현되는 방법.
2. 제 1 항에 있어서, 제 1 목적물은 비구현 방법으로 구성하는 인터패이스를 정의하는 추상 목적물과 상호 작용하도록 설계되어 있어, 이를 제 1 목적물이라 하고, 나중에 제 2 목적물의 설계는 상기 제 1 목적물에 알려지지 않고, 제 1 목적물과 상호 작동하도록 되고, 제 2 목적물과 상호작용하는 제 1 목적물이 제 2 목적물을 추상형식의 것으로 간주하기 위해 다른 목적물은 추상 목적물을 계승 및 계승한 방법을 구현하는 것을 특징으로 하는 방법.
3. 제 2 항에 있어서, 추상 목적물의 인터패이스에 형성된 방법을 호출할때 결합에 의해 실제 목적의 구현에 이 호출이 전달되는 것을 특징으로 하는 방법.
4. 제 2 항 또는 3 항에 있어서, 상기 제 2 목적물을 로딩하는 경우에 피관리 시스템의 경우에 제 1 목적물의 재로딩은 각각의 서브시스템 사이의 동적 링크에 의해 이루어지는 것을 특징으로 하는 방법.
5. 제 2 항 또는 제 3 항에 있어서, 제 1 및 제 2 목적물은 제 1 및 제 2 서브 시스템에 각각 위치한 것을 특징으로 하는 방법.
6. 제 5 항에 있어서, 제 1 서브시스템의 재로딩없이 피관리 시스템에서 로딩할 수 있도록 동적 링크를 이용하는 것을 특징으로 하는 방법.
7. 제 1 항에 있어서, 범용 관리자는 피관리 시스템의 관리정보모델을 조절함으로써 외부 사용자가 피관리 시스템과 상호 작용하도록 하는 기능을 포함하는 것을 특징으로 하는 방법.
8. 제 7 항에 있어서, 범용 관리자는 범용 관리자 내부의 표현을 범용 관리자에 대한 외부 이용자, 예를 들면 윈도우 관리 시스템의 사용자와 데이타 베이스 관리자에 적합한 표현으로 변형시키는 외부표현 유닛을 포함하는 것을 특징으로 하는 방법.
9. 제 7 항 또는 제 8 항에 있어서, 범용 관리자는 피관리 시스템의 범용 표현을 해석할 수 있는 모델 인터프리터를 포함하는 것을 특징으로 하는 방법.
10. 제 7 항 또는 제 8 항에 있어서, 범용 관리자는 관리정보모델의 내부표현을 해석함으로써 피관리 시스템쪽으로 지향할 수 있는 작동을 발생시키거나 문맥적으로 또는 의미적으로 보정하는 기능을 포함하는 것을 특징으로 하는 방법.
11. 제 7 항 또는 제 8 항에 있어서, 범용 관리자는 피관리 시스템에서 발생한 이벤트를 수신하여 피관리 시스템에 기록된 관리 정보모델의 표현을 전달하여 액세스시키는 관리망쪽으로 인터패이스를 포함하는 것을 특징으로 하는 방법.
12. 제 7 항 또는 제 8 항에 있어서, 범용 관리자는 피관리 시스템의 관리정보의 같은 범용 표현을 상이한 형태의 통신망에 전달하는 액세스 인터패이스를 포함하는 것을 특징으로 하는 방법.
13. 제 7 항 또는 제 8 항에 있어서, 범용 관리자는 피관리 시스템의 관리정보모델을 이용할 수 있게 하며, 추가/새로운 정보를 피관리 시스템에 특정되고 기록된 정보외의 관리정보모델의 표현에 공급하지 않고 외부 사용자에 맞는 표현으로 변형시키는 기능을 포함하는 모델에 따라 구현되는 것을 특징으로 하는 방법.