KR101044182B1 - 시스템의 검증을 용이하게 하는 방법, 소프트웨어 애플리케이션의 검증을 용이하게 하는 장치 및 컴퓨터 판독 가능 기록 매체 - Google Patents

Abstract

시스템의 설계 시간 검증(design time validation)의 특정 태양에 따라, 설계되는 시스템의 기술(description) 및 환경의 기술이 수신된다. 수신된 기술들은 시스템이 설계되는 동안 및 시스템을 배치(deploy)하려 시도하기 전에 환경에 대하여 시스템을 검증하기 위하여 사용된다.

Description

시스템의 검증을 용이하게 하는 방법, 소프트웨어 애플리케이션의 검증을 용이하게 하는 장치 및 컴퓨터 판독 가능 기록 매체 {DISIGN TIME VALIDATION OF SYSTEM}

동일 구성 요소를 참조하기 위해 도면들을 통해 동일한 숫자가 사용되었다.

도 1은 예시적인 네트워크 설정을 도시하는 도.

도 2는 시스템 정의 모델을 사용하는 예시적인 아키텍처를 도시하는 블록도.

도 3은 예시적인 계층화된(layered) 설정을 도시하는 도.

도 4는 설계 시간 검증을 위한 예시적인 프로세스를 도시하는 흐름도.

도 5A 및 5B는 인스턴스 스페이스(instance space)을 생성하는 예시적인 재귀적 확장 프로세스를 도시하는 흐름도.

도 6A 및 6B는 평가 플로우를 위한 예시적인 프로세스를 도시하는 흐름도.

도 7A, 7B, 7C, 7D 및 7E는 제한 조건(constraint)들을 평가하기 위한 예시적인 프로세스를 도시하는 흐름도.

도 8은 예시적인 SDM 문서를 도시하는 도.

도 9는 예시적인 SDM 정의를 도시하는 도.

도 10은 예시적인 SDM 멤버를 도시하는 도.

도 11은 예시적인 설정 멤버를 도시하는 도.

도 12는 예시적인 제한 조건 정의를 도시하는 도.

도 13은 예시적인 기술 오브젝트(description object)를 도시하는 도.

도 14는 한 계층(layer)에서의 웹 애플리케이션으로부터 다른 계층에서의 웹 서버 호스트로의 예시적인 맵핑(mapping)을 도시하는 도.

도 15는 예시적인 내장(built-in) 데이터 타입 계층(hierarchy)을 도시하는 도.

도 16은 업 캐스팅(upcasting) 및 다운 캐스팅(downcasting)의 예시를 도시하는 도.

도 17은 타입 전환의 예시를 도시하는 도.

도 18은 예시적인 관계 트리를 도시하는 도.

도 19는 호스트의 게스트에 대한 실행(implementation)을 나타내기 위해 위임(delegation)을 사용하는 예시를 도시하는 도.

도 20은 멤버의 부모에 대한 실행을 나타내기 위해 위임을 사용하는 예시를 도시하는 도.

도 21 및 22는 커뮤니케이션 접속 확인의 예시를 도시하는 도.

도 23은 영역 경계의 예를 도시하는 도.

도 24는 예시적인 인스턴스 스페이스를 도시하는 도.

도 25는 여기에서 설명되는 기술들을 실행하는데 사용될 수 있는 예시적인 일반적 컴퓨터 환경을 도시하는 도.

＜도면 번호에 대응하는 구성요소에 대한 설명＞

202 : 개발 컴포넌트

204 : SDM

206 : LIM

208 : 검증 컴포넌트

210 : 인터페이스 및 프로세싱 계층

212 : 로더

214 : 검증기

218 : 시뮬레이터

220 : 확장 엔진

222 : 플로우 엔진

224 : 제한 조건 엔진

[관련출원]

본 출원은 2003년 3월 6일에 출원된 "분산 컴퓨팅 시스템 및 분산 애플리케이션의 자동화된 설계, 배치 및 관리를 위한 아키텍처"인 미국 임시 출원 번호 60/452,736에 대해 우선권을 주장하며, 상기 임시 출원은 참조되어 본 출원에 결합된다. 또한, 본 출원은 2003년 10월 24일에 출원된 "시스템들을 위한 설계, 배치 및 관리 단계들의 통합"인 미국 출원 번호 10/693,838의 일부 계속 출원이며, 상기 일부 계속 출원은 참조되어 본 출원에 결합된다.

본 발명은 시스템들의 설계에 관한 것으로서, 더욱 구체적으로는 시스템들의 설계 시간 검증에 관한 것이다.

과거 수 년 동안 인터넷 사용은 폭발적으로 증가해 왔으며, 현재도 계속 성장하고 있다. 사람들은 전자 메일, 온라인 쇼핑, 뉴스 및 정보 수집, 음악 청취, 비디오 감상, 구직 활동 등과 같은 월드와이드웹(이하 "웹"이라 한다) 상에서 제공되는 많은 서비스들에 매우 만족해 하고 있다. 인터넷에 기초한 서비스들에 대한 수요의 성장 페이스를 유지하기 위해, 호스팅 웹사이트, 상기 사이트들을 위한 백엔드(backend) 서비스의 제공 및 상기 사이트들에 관련한 데이터의 저장에 쓰인 컴퓨터 시스템들에 있어서 놀랄만한 성장이 있어왔다.

분산 컴퓨터 시스템의 한 유형은 인터넷 데이터 센터(IDC) 또는 엔터프라이즈 데이터 센터(EDC)와 같은 데이터 센터로서, 이는 호스팅 네트워크 서비스들을 위한 많은 컴퓨터들을 수용할 수 있도록 매우 복잡하게 설계된다. 또한 "웹팜(Webfarms)" 또는 "서버팜(server farms)"이라고도 하는 데이터 센터들은 통상적으로 수백에서 수천의 컴퓨터들을 기후가 조절되고 물리적으로 안전한 건물 내에 수용한다. 데이터 센터들은 통상적으로 신뢰성이 높은 인터넷 액세스, 신뢰성이 높은 전원 및 안전한 동작 환경을 제공한다.

다른 데이터 센터들은 데이터 센터 내에서 실행되는 애플리케이션들을 강제하는 다른 요구들을 가질 수 있다. 예를 들어, 다른 데이터 센터들은 다른 유형의 안전을 요구하거나 다른 커뮤니케이션 프로토콜을 지원하는 애플리케이션들을 요구할 수 있다. 또한, 몇몇 데이터 센터들은 그들의 요구들을 시간에 따라 변경할 수 있다. 데이터 센터들 간의 이러한 차이점들은 설계자가 이러한 모든 차이점들에 대해 알아야 하고, 이들의 애플리케이션들이 원하는 데이터 센터(들)에서 실행될 수 있도록 애플리케이션들을 설계함에 있어서 고려해야 하는 것과 같이, 애플리케이션들의 설계 프로세스를 어렵게 한다.

나아가, 일반적으로 설계자들은 그들이 애플리케이션들을 데이터 센터에 배치할 때 특정 데이터 센터에서 애플리케이션이 실행될지 여부만을 평가한다. 데이터 센터의 하나 이상의 요구가 애플리케이션에 의해 만족되지 않아서 배치가 성공적이지 않다면, 설계자는 애플리케이션이 갖는 문제점(들)을 고치는 시도를 하고, 데이터 센터에 애플리케이션의 배치를 재시도해야 한다. 이 프로세스는 여러 번 반복될 수 있으며, 불충분하면서도 실망스러운 설계 프로세스가 될 수 있다.

여기에서 설명되어지는 시스템들의 설계 시간 검증은 이러한 문제점 및 다른 문제점들을 해결하기 위한 것이다.

시스템들의 설계 시간 검증이 이하에서 설명된다.

시스템들의 설계 시간 검증의 몇몇 측면에 따르면, 설계되는 시스템의 기술(description)과 환경의 기술이 수신된다. 수신된 기술들은 시스템을 배치하는 시도에 앞서서 시스템이 설계되는 동안 환경에 대해 시스템을 확인하는 데 사용된다.

이하에서 개시되는 내용은 시스템들의 설계 시간 검증을 위한 아키텍처에 관 련된 많은 태양에 대해 설명한다. 상기 개시 내용은 서비스 정의 모델(service definition model; SDM)로도 언급되는 시스템 정의 모델(system definition model; SDM)의 검토를 포함한다. 상기 SDM은 추상적인 방법으로 분산 컴퓨터 애플리케이션과 데이터 센터를 설계하기 위한 애플리케이션 설계사를 위한 도구(tool) 및 컨텍스트(context)를 제공한다. 상기 모델은 물리적인 컴퓨터 소스 및 소프트웨어에 의해 궁극적으로 구현되는 애플리케이션들의 기능적인 유닛들을 나타내는 한 세트의 요소들을 정의한다. 모델 요소들에 관련되는 것은 구성 요소들에 의해 얼마나 기능적인 동작을 나타내는지를 지시하는 스키마(schema)가 열거되는 것이다.

본문에 있어서, 용어 "전선(wire)"은 "접속(connections)", "커뮤니케이션" 또는 "커뮤니케이션 관계"라고 할 수 있다. 또한, 용어 "시스템(system)"은 "모듈"로서, 용어 "리소스 공간(resource space)"은 "리소스들"이라고 할 수 있다. 게다가, 용어 "애플리케이션 공간(application space)"은 "애플리케이션"으로, 그리고 용어 "인스턴스 스페이스"는 "인스턴스들(instances)"로 할 수 있다. 나아가, 용어 "클래스(class)"는 "추상적인 정의"로, 용어 "포트(port)"는 "종단점(endpoint)"로, 그리고 용어 "타입(type)"은 "정의(definition)"라고 할 수 있다.

도 1은 예시적인 네트워크 설정(100)을 도시하고 있다. 설정(100)에서, 복수(x)의 컴퓨팅 디바이스들{102(1), 102(2), . . . , 102(x)}은 네트워크(106)에 결합된다. 네트워크(106)는 다양한 종래의 네트워크 토폴로지(topology) 및 타입들 중 임의의 것을 의미하며, 종래의 다양한 네트워크 프로토콜들(공중 및/또는 사 유 프로토콜들을 포함) 중 임의의 것을 사용하고자 한다. 네트워크(106)는 예를 들어, 로컬 영역 네트워크(LAN), 광역 네트워크(WAN), 인터넷의 부분들을 포함할 수 있다. 설정(100)은 예컨대 데이터 센터들(예를 들어 인터넷 데이터 센터들), 사무실 또는 비지니스 설정, 홈 설정, 교육 또는 연구 시설들, 소매(retail) 또는 판매 설정, 데이터 저장 설정 등을 포함하는 매우 다양한 설정 중 임의의 것을 의미한다.

컴퓨팅 디바이스(102)는 데스크탑, 워크스테이션, 메인 프레임 컴퓨터, 서버 컴퓨터, 인터넷 애플리케이션, 게임 콘솔, 핸드헬드 컴퓨터, 셀룰라 전화기, PDA 등을 포함하는 종래의 다양한 컴퓨팅 디바이스 중 임의의 것이다. 하나 이상의 디바이스들(102)은 같은 타입의 디바이스일 수 있으며, 또는 선택적으로 다른 타입의 디바이스일 수 있다. 또한, 복수의 디바이스들이 같은 타입의 디바이스인 경우라 하더라도, 상기 복수의 디바이스들은 서로 다르게 구성될 수 있다(예를 들어, 두 디바이스(102)는 서버 컴퓨터이지만 서로 다른 프로세서, 다른 RAM의 양, 다른 하드 디스크 드라이브의 크기 등과 같이 다른 하드웨어 구성을 가질 수 있다).

하나 이상의 컴퓨팅 디바이스들(102)은 또한 설정(100)에 부가된 이후에 재구성될 수 있다. 예를 들어, 특정 컴퓨팅 디바이스(102)는 하나의 기능을 수행하기 위해 한 주기의 시간(예를 들어, 분, 시간, 일, 월 등의 순서로) 동안 동작하며, 관리자는 다른 기능이 바람직하다고 결정할 수 있다(예를 들어 서버 컴퓨터로부터 워크스테이션으로 변경하거나, 웹 서버로부터 로컬 파일 서버로 변경하는 등이다).

도 2는 SDM을 사용하는 예시적인 아키텍처(200)를 도시하는 블록도이다. 상기 SDM은 시스템들의 설계 프로세스 동안 사용하도록 설계되며, 또한 설계 프로세스 완료 후에 시스템의 배치 및/또는 관리를 위해 사용될 수 있다. 시스템은 공통 기능의 완수를 위해 같이 작업할 수 있는 한 세트의 관련 소프트웨어 및/또는 하드웨어 리소스들이다. 그러한 시스템의 일례가 애플리케이션인데, 이는 다양한 기능성을 수행하는 컴퓨팅 디바이스에 의해 실행될 수 있는 한 세트의 지시를 가리킨다. 애플리케이션의 예시들은 게임과 같은 엔터테인먼트 애플리케이션, 워드 프로세서와 같은 생산성 애플리케이션, 전자 백과사전과 같은 참조 애플리케이션, 웹 서버들 또는 재정 분석을 위해 사용되는 것과 같은 분산 애플리케이션 등을 포함한다. 그러한 시스템의 다른 예는 애플리케이션(또는 다른 환경)이 배치될 수 있는 환경이다. 환경은 애플리케이션(또는 다른 환경)이 배치되는 소프트웨어 또는 하드웨어 리소스들을 가리킨다. 그러한 환경들은 서로의 가장 위에 계층화될 수 있다.

일반적으로, 시스템을 위한 설계 프로세스 또는 단계(또한 개발 프로세스 또는 단계라고 할 수 있다)동안, SDM에 영향을 주는 개발 도구들은 커뮤니케이팅 소프트웨어 및/또는 하드웨어 컴포넌트들로 구성되는 시스템을 정의하기 위해 사용된다. 시스템 정의는 요구되는 리소스들, 구성, 동작 태양, 방법들 등을 포함하는 분산 시스템을 배치하고 동작하기 위해 필요한 모든 정보들을 제한한다. 설계 단계의 완료 후에, 배치 단계는 또한 시스템을 자동적으로 배치하고, 요구되는 소프트웨어 및 하드웨어(예를 들어, 서버, 스토리지 및 네트워킹) 리소스들을 동적으로 할당하고 구성하기 위해 시스템 정의를 사용할 수 있다. 동일한 시스템 정의가 다른 호스트 환경 및 다른 스케일에 배치를 위해 사용될 수 있다.

아키텍처(200)는 SDM 정의 모델 내의 기능적인 동작들을 정의하는 스키마 뿐만 아니라 SDM 정의 모델도 사용한다. 상기 정의 모델은 총괄하여 "정의들"인 다양한 서로 다른 종류의 데이터 구조들을 포함한다. SDM의 기능성은 애플리케이션 프로그램 인터페이스들(APIs)과 같은 하나 이상의 플랫폼(platform) 서비스들을 통해 나타내어진다.

시스템을 위한 설계 단계 동안, 개발 구성 요소(202)는 SDM 문서(204)와 같은 시스템 정의를 포함하는 문서를 발생시킨다. 개발 구성 요소(202)는 워싱턴, 레드몬드의 마이크로소프트사의 비주얼 스튜디오 개발 시스템과 같은 다양한 개발 구성 요소들 중 임의의 것일 수 있다. SDM 문서(204)는 시스템의 배치(선택적으로 관리일 수 있다)와 관련된 모든 정보(또한 지식이라고 할 수 있다)를 정의한다. 시스템을 배치하거나 관리할 때 사용되거나 필요한 임의의 지식은 SDM 문서(204) 내에 포함된다. 단일 문서로서 본 명세서에서 설명되었지만, 지식은 선택적으로 분배되거나 복수의 문서 내에서 유지되는 것이 바람직하다.

시스템 정의는 하나 이상의 리소스들, 종단점들, 관계들 및 서브시스템들의 관점에서 시스템을 정의한다. 시스템 정의는 SDM 문서(예를 들어, XML 문서)로 선언된다. 리소스들은 하드웨어 리소스들 또는 소프트웨어 리소스들일 수 있다. 종단점들은 시스템 간의 커뮤니케이션들을 나타낸다. 관계들(relationships)은 시스템, 리소스 및 종단점 간의 관련성을 정의한다. 서브시스템들은 완전한 시스템으 로 취급되며, 통상적으로 큰 시스템의 부분이다.

시스템 정의는 동적 시스템의 기본 구조를 캡쳐한다. 그것은 다른 모든 정보들이 가해지는 골격으로 볼 수 있다. 이 구조는 설계자들 및 개발자들에 의해 개발 프로세스 동안 통상적으로 열거되며, 자주 변경되지 않는다. 상기 구조에 더하여, SDM은 배치 정보, 인스톨 프로세스, 구성을 위한 스키마들, 이벤트들 및 계측, 자동 사무, 건강 모델, 작동 방법 등을 포함할 수 있다. 다른 정보는 작동 스텝, 벤더(vendor) 및/또는 분산 시스템의 수명에 걸친 관리 시스템에 의해 더해질 수 있다.

SDM 문서(204)는 시스템의 하나 이상의 제한 조건(또한 요구라고 한다)을 포함하는데, 시스템이 만족하도록 배치되고 및/또는 실행되도록 하는 환경 내에 있어야 한다. 상기 환경 자체는 또한 "논리적 기반 구조(logical infrastructure; LIM)" 문서(206) 또는 데이터 센터 설명 또는 데이터 센터 모델인 SDM 문서를 사용하여 설명된다. SDM 문서(204)에 유사한 LIM 문서(206)는 단일 문서이거나 선택적으로 둘 이상의 문서로 만들어질 수 있다. LIM 문서(206)는 개발 컴포넌트(202)에 예사한 구성 요소와 같은 다양한 개발 컴포넌트들 중 임의의 것을 사용하여 생성될 수 있다. 또한, LIM 문서(206)는 개발 컴포넌트(202)를 사용하여 개발될 수 있다(즉, 같은 개발 컴포넌트가 SDM 문서와 LIM 문서를 모두를 생성하는데 사용될 수 있다).

LIM 문서(206)에 의해 설명되는 환경은 단일 컴퓨팅 디바이스 또는 선택적인 컴퓨팅 디바이스들(예를 들어 데이터 센터들)의 집합, 애플리케이션 호스트들 등일 수 있다. 다른 시스템들 또는 같은 시스템이더라도, 다른 환경들로 인스톨 될 수 있다. 예를 들어, 데이터 센터는 50개의 컴퓨팅 디바이스들을 포함할 수 있고, 하나의 시스템은 그들 컴퓨팅 디바이스들의 5개에 배치될 수 있으며, 반면 다른 시스템은 그들 컴퓨팅 시스템의 35개에 배치될 수 있다. 이러한 요구들은 시스템이 배치되는 컴퓨팅 디바이스 관련 하드웨어 요구(예를 들어 최소한의 프로세서 스피드, 최소한의 메모리, 최소한의 하드 디스크 여유 공간, 최소한의 이용 가능한 네트워크 대역폭, 이용 가능한 특정 안전 메카니즘 등), 상기 시스템이 배치되는 컴퓨팅 디바이스 관련 소프트웨어 요구(예를 들어 특정 운영 체제, 설치되어야 하는 하나 이상의 다른 애플리케이션, 특정 시스템 및 또는 운영 체제가 어떻게 구성되어야 하는지에 관한 스펙, 사용되는 안전 또는 암호화의 특정 타입 등), 상기 시스템이 배치되는 컴퓨팅 디바이스 관련 다른 요구들(예를 들어 이용 가능한 안전 키, 실행되어야 하는 데이터 센터 정책들, 사용되는 인증, 환경 토폴로지 등)과 같은 다양한 형태를 취할 수 있다. SDM 문서(204)에서 설명되는 것과 같은 단일 시스템은 다른 LIM들(206)에서 설명되는 것과 같은 복수의 서로 다른 환경들에 대해 확인될 수 있다.

요구들은 다른 방향으로 미칠 수 있다. 즉, 환경은 (예를 들어, 환경의 표준 또는 정책을 구현하기 위해) 설치될 시스템의 구성상 제한 조건들 또는 요구들을 가질 수 있다. 이들은 시스템이 가져야 하는 특정 설정 또는 구성들, 시스템이 제공하거나 지원해야 하는 특정 기능성, 시스템이 지원해야 하는 특정 안전 메카니즘들 등과 같은 환경의 운용자(operator)에 의해 생성되는 "명백한(explicit)" 요 구일 수 있다. 이들은 환경의 특별한 구성 때문에 발생하는 "명백한" 요구일 수 있다. 예를 들어, 환경 내의 호스트 컴퓨팅 디바이스가 파일 시스템의 특정 타입을 사용하고 있다면, 그 파일 시스템을 사용하는 몇몇 동작들은 실행될 수 없을 것이다(설령 다른 파일 시스템을 사용하는 같은 동작들이 실행될 수 있다고 하더라도 마찬가지이다).

시스템의 설계 단계 동안, SDM 문서(204)는 검증 컴포넌트(208)에 의해 하나 이상의 특정 환경(들)을 위한 시스템을 확인하는데 사용될 수 있다. 이는 쌍방향 확인으로서, 시스템은 환경을 위해 확인되고, 환경은 시스템을 위해 확인된다. 검증 컴포넌트(208)는 LIM 문서(206) 내에서 설명된 것과 같은 환경을 갖는 SDM 문서(204) 내에서 식별되는 요구들을 비교하고, 모든 요구들이 환경에 의해 만족되어지는지 여부를 결정함으로써 시스템을 위한 환경을 확인할 수 있다. 검증 컴포넌트(208)는 SDM 문서(204) 내에서 설명된 것과 같은 시스템을 갖는 LIM 문서(206) 내에서 식별되는 요구들을 비교하고, 모든 요구들이 시스템에 의해 만족되어지는지 여부를 결정함으로써 환경을 위한 시스템을 확인할 수 있다. 모든 요구들이 환경과 시스템에 의해 만족되어지면, 설계자 또는 개발자는 상기 시스템이 환경 내에서 배치되고 실행될 수 있음을 알게 된다. 그러나, 모든 요구들이 환경 및/또는 시스템에 의해 만족되지 않는다면, 검증 컴포넌트(208)는 설계자 또는 개발자에게 요구들이 만족되지 않음을 알리고, 설계자 또는 개발자가 SDM 문서(204) (그리고 시스템에 상응하여) 또는 그러한 환경 내에서 배치되는 시스템을 위한 환경에 어떤 변화를 주어야 하는지 알려준다.

LIM 문서(206)는 실제 환경 또는 선택적으로 시뮬레이트된 환경을 위한 것일 수 있다. 실제 환경을 위해, 상기 LIM은 존재하거나 아직 생성되지 않았지만 설명된 환경을 설명한다. 예를 들어, 실제 환경은 통상 존재하는 데이터 센터일 수 있으며, 또는 아직 실제로 구현되지는 않았지만 설계된 적이 있는 데이터 센터일 수 있다. 시뮬레이트된 환경을 위해, 상기 LIM은 반드시 존재하지는 않을 수 있는 예상되는 환경을 설명한다. 예상되는 환경에 관한 다양한 가정들이 만들어지며, 그러나 실제 환경을 위해 그러한 가정들이 만들어질 필요는 없다. 통상적으로, 시스템을 위한 설계 프로세스 동안, LIM 문서(206)는 시뮬레이트된 환경을 설명한다. 그러나, 조만간 특정 포인트에서 존재하는 환경으로서의 실제 환경을 설명하는 LIM 문서(206)는 설계 단계동안 선택적으로 사용될 수 있다.

검증 컴포넌트(208)는 개발된 시스템이 배치되는 데이터 센터와는 별도의 하나 이상의 컴퓨팅 디바이스들 일 수 있다. 예를 들어, 검증 컴포넌트(208)는 단일 컴퓨팅 디바이스 또는 복수의 디바이스에 걸쳐 분산된 선택적인 확인 책임들(responsibilities) 일 수 있다. 선택적으로, 검증 컴포넌트(208)는 시스템이 개발된 시스템이 배치되는 데이터 센터의 하나 이상의 컴퓨팅 디바이스들(102) 일 수 있다.

SDM은 수평축 및 수직축에 걸쳐 시스템들의 기능적인 구성을 가능하게 한다. 수평축을 따른 구성은 시스템들 및 서브시스템들로 이루어진다. 수직축을 따른 구성은 "계층들(layers)"로 이루어진다. 응용들, 서비스들, 네트워크 토폴로지들 및 하드웨어는 분산 시스템 내에서 역할(role)을 수행하지만, 통상 독립적으로 정의되 고 서로 다른 팀이나 조직에 의해 소유된다. 계층화는 호스트 상에서의 한 세트의 제한 조건들을 정의하는 컴포넌트들 및 컴포넌트들을 정의하는 호스트 상에서의 한 세트의 제한 조건들에 의해 이루어진다.

도 3은 예시적인 계층화 설정을 도시하고 있다. 도 3에 계층(302), 계층(304), 계층(306) 및 계층(308)과 같이 4개의 계층들이 도시되고 있다. 4개의 계층들이 도 3에 도시되고 있음에도 불구하고, 계층들의 실제 수는 가변적이며, 네 개보다도 적거나 많을 수 있다. 게다가, 다른 계층들의 내용은 다른 실시예에서 달라질 수 있다. 도 3에 보여지는 바와 같이, 다른 계층들은 다른 계층들의 위 및/또는 아래에 놓이게 된다(예를 들어 계층(306)은 계층(304)의 위이나, 계층(308)의 아래이다).

한 계층 내의 다른 시스템들 및 서브시스템들은 서로 상호 작용할 수 있으며, 또한 다른 계층들의 시스템들 및 서브시스템들과 상호 작용할 수 있다. 예를 들어, 계층(308) 내의 서브시스템(310)은 계층(308) 내의 서브시스템(312)과 상호 작용할 수 있을 뿐만 아니라, 계층(306) 내의 서브시스템(314)과도 상호 작용할 수 있다. 게다가, 각 계층은 이웃하는 높은 계층을 위한 환경으로서 보여질 수 있다. 예를 들어, 계층(306)은 계층(308) 내의 시스템들 및 서브시스템들을 위한 환경이며, 반면 계층(304)는 계층(306)의 시스템들 및 서브시스템들을 위한 환경이다. 각 계층(302, 304, 306 및 308)은 고유의 관련 SDM 문서를 갖는다.

다른 계층들(302, 304, 306 및 308)은 다른 내용을 나타낼 수 있다. 어떤 실시예에서, 계층(302)은 하드웨어 계층이고, 계층(304)은 네트워크 토폴로지 및 운영 체제 계층이며, 계층(306)은 애플리케이션 호스트 계층이고, 계층(308)은 애플리케이션 계층이다. 상기 하드웨어 계층은 물리적 디바이스들(예를 들어, 컴퓨팅 디바이스들)을 나타내며, 계층화된 시스템이 그 위에 만들어진다(예를 들어 도 1의 디바이스들(102)). 상기 네트워크 토폴로지 및 운영 체제 계층은 컴퓨팅 디바이스들(예를 들어 도 1의 네트워크 설정(100)) 뿐만 아니라 상기 컴퓨팅 디바이스들 상에 설치되는 운영 체제들을 나타낸다. 상기 애플리케이션 호스트 계층은 다른 애플리케이션들을 호스트할 수 있는 컴퓨팅 디바이스들 상에 설치되는 애플리케이션들을 나타낸다(예를 들어 SQL 서버, IIS 등). 상기 애플리케이션 계층은 다른 애플리케이션들을 호스트할 수 없는 컴퓨팅 디바이스들 상에 설치되는 애플리케이션들을 나타낸다(예를 들어, 게임과 같은 엔터테인먼트 애플리케이션들, 워드프로세서와 같은 생산성 애플리케이션들, 전자 백과사전과 같은 참조 애플리케이션들, 웹 서비스 또는 재정 분석을 위해 사용되는 분산 애플리케이션 등).

도 2로 돌아가서, 애플리케이션 개발자는 개발 컴포넌트(202)를 사용하여 애플리케이션을 설계하고 개발할 수 있다. 개발자가 그 또는 그녀의 시스템의 다양한 부분을 정의하고 이들 부분들이 어떻게 서로 연관되는지 정의할 때, 이들 부분들 및 관계들을 캡처하는 SDM 파일(204)이 발생된다. 상기 개발자는 LIM 파일(206) 내에 설명되는 환경에 대한 시스템 설명을 확인하기 위한 검증 컴포넌트(208)를 사용할 수 있다. 설계 단계 동안의 이 검증은 "설계 시간 검증"이라고 한다.

아래의 "예시적인 SDM 구현" 부분에서 더욱 상세하게 논의되는 상기 SDM은 분산 시스템(모델화된 시스템) 내의 컴포넌트들에 대한 구성, 상호 작용 및 변화들의 설명을 지원하도록 설계된다. SDM은 오브젝트 관계 모델(object-relational model)에 기초한다. "오브젝트들"은 시스템 내에 존재하는 실체들(entities)을 설명하고, "관계들"은 다양한 실체들 사이의 링크들을 식별한다. 오브젝트들 및 관계들은 나아가 SDM에 상응하는 의미론적 정보를 캡처하도록 정의된다. 특히, 오브젝트들은 컴포넌트들, 종단점들 및 리소스들로 나누어진다. 관계들은 다음과 같이 접속들(또한 커뮤니케이션이라고도 한다), 견제, 호스팅, 위임(delegation) 및 참조로 나누어진다. 나아가 오브젝트들과 관계들 관련 상세한 내용은 이하에서 설명되어진다.

SDM은 시스템 부분들의 공통 분류를 제공하고, 시스템들의 넓은 범위를 위한 도구 지원을 제공하며, 설계시에 정의를 검사(check)하기 위한 기초를 제공하는 "추상적인 정의들"을 포함한다. 추상적인 정의들의 한 세트는 서비스 설계를 위한 포괄적인(comprehensive) 기초를 제공한다. "구체적인 정의들"은 실제 시스템의 부분들 또는 데이터 센터 설계를 나타낸다. 구체적인 정의는 추상적인 정의를 선택하고 구체적인 설계의 멤버들 및 그것의 속성을 위한 설정값들을 정의하는 구현을 제공함으로써 발생된다. 애플리케이션들은 이들 구체적인 정의들의 집합을 사용하여 발생된다.

상기 SDM은 또한 참여할 수 있는 관계의 인스턴스 내의 허용된 셋트의 관계들에 기초한 제한 조건들을 설계한다. 제한 조건들은 관계들에 포함되는 오브젝트들의 구성에 의존하는 요구들을 설명하는데 유용하다. 예를 들어, 제한 조건은 커 뮤니케이션 프로토콜의 각 엔드 상에서 참여자(participant)들이 양립할 수 있는 안전 설정을 사용하는지 여부를 결정하는데 사용된다.

상기 LIM 파일(206) 및 SDM 파일(204)은 검증 컴포넌트(208)의 인터페이스 및 프로세싱 계층(210)에 입력된다. 인터페이스 및 프로세싱 계층(210)은 SDM 파일(204)의 확인을 제어한다. 검증 컴포넌트(208)는 컴파일러라고도 한다.

인터페이스 및 프로세싱 계층(210)은 로더(loader; 212), 검증기(verifier; 214) 및 시뮬레이터(218)를 포함한다. 로더(212)는 SDM 파일(204)을 분석하고 인 메모리(in-memory) 타입 공간 내의 임의의 참조된 파일 또는 타입들을 로드한다. SDM 파일(204)은 SDM 클래스들(예를 들어, XML 내의)을 정의하고, 로더(212)는 인 메모리 타입 공간 내의 SDM 클래스들로 변형한다. 검증기(214)는 SDM 파일(204) 내에 어떤 에러가 있는지 여부를 검사하고, SDM 파일(204)이 로더(212)가 SDM 파일(204)을 로드하도록 적절히 쓰여졌는지 확인한다. 검증기(214) 또는 로더(212)가 에러를 발견하면, 에러는 에러를 야기한 문제의 표시를 선택적으로 나타내는 개발 컴포넌트(202)로 되돌려진다. 검증기(214)는 또한 타입 공간 내에서 설정값들, 타입들, 및 SDM 파일 참조들을 검사한다. 통상, 에러가 검증기(214) 또는 로더(212)에 의해 발견되면, 설계 시간 검증은 종료된다.

시뮬레이터(218)는 아래에서 설명되는 바와 같이, LIM 문서(206)에 의해 정의되는 환경을 시뮬레이트하고, 확장 엔진(220), 플로우 엔진(222) 및 제한 조건 엔진(224)을 호출한다. 시뮬레이터(218)에 의해 발견되는 에러들은 선택적으로 에러를 야기한 문제의 표시를 포함하는 컴포넌트(202)로 되돌려진다(예를 들어, 결과 로서 (226)). 통상 에러가 시뮬레이터(218)에 의해 발견되면, 에러의 표시가 개발 컴포넌트(202)로 되돌려지지만, 설계 시간 검증은 계속된다.

인터페이스 및 프로세싱 계층(210)은 SDM 파일(204)의 확인을 수행하기 위한 확장 엔진(220), 플로우 엔진(222) 및 제한 조건 엔진(224)을 호출한다. 일반적으로, 확장 엔진(220)은 SDM 파일(204)에 기초한 인스턴스 스페이스를 생성하고 모든 추가적인 인스턴스들을 부가하기 위한 동작들의 세트 및 값에 의한 자식(by-value chiledren) 및 관계들을 포함하거나 적절한 인스턴스들 및 관계들을 제거하도록 요구되는 동작들을 확장한다. 플로우 엔진(222)은 인스턴스 "그래프"에 걸쳐서 인스턴스들 상에서 정의된 플로우들을 발견하고, 플로우 내의 값들을 적절한 값들로 설정한다. 제한 조건 엔진(224)은 인스턴스 스페이스에 걸쳐서 각 제한 조건 멤버를 발견하고 평가한다.

어떤 실시예들에서는, 모든 제한 조건들이 진실로 평가되면 (즉, 모든 제한 조건들이 만족되면) 그리고 SDM 문서(204)를 처리할 때 검증 컴포넌트(208)가 에러를 발견하지 못하면, 검증 컴포넌트(208)는 디지털 방식으로 SDM 문서(204)에 서명한다. 이 디지털 서명은 SDM 문서(204)가 성공적으로 컴파일되었음을 나타낸다. SDM 문서(204)는 다양한 서로 다른 방법, SDM 문서 및 검증 컴포넌트(208)에 관한 한 쌍의 공개/개인 키에 기초한 디지털 서명을 발생시키는 것을 통상적으로 포함하는 다른 방법들 중 임의의 것으로 디지털 서명이 될 수 있다. 따라서, 디지털로 서명된 SDM 문서들은 (예를 들어 그들이 배치되었을 때) 이미 확인된 것으로서 취급될 수 있다. 디지털로 서명된 SDM 문서는 또한 컴파일된 SDM 문서라고도한다.

다양한 제한 조건들을 평가하는 것 외에도, 검증 컴포넌트(208)는 또한 참조된 문서들의 풀네임 (및 선택적인 버전)을 갖는 다른 SDM 문서들에 대한 참조를 갱신할 수 있다. 따라서, 상기 컴파일된 SDM 문서는 이러한 풀네임들을 갖는다. 예를 들어, SDM 문서는 버전이 아닌 이름에 의한 다른 SDM 문서 및 참조를 들여올 수 있고, 검증 컴포넌트(208)가 참조된 문서를 들여올 때, 들여온 문서의 버전은 식별되고 컴파일된 SDM 문서에 부가된다.

여기에서의 논의는 SDM 문서(204)에 포함될 수 있는 정의들 또는 다양한 멤버들에 대한 참조를 만든다. 정의는 얼마나 특별한 인스턴스들이 인스턴스 스페이스 내에 생성되는지를 정의한다. 다시 말해서, 정의는 무엇이 가능한지를 정의한다. 멤버는 정의에 기초한 특정 용도 및 시나리오를 설명한다. 예를 들어, 정의는 특정 인스턴스를 위해 무엇이 가능한지, 멤버는 그러한 가능성 중 어느것이 특정 인스턴스에 포함되는 지를 설명한다. 다음의 표는 멤버 또는 정의들의 예시 뿐만 아니라 각 멤버 및 정의의 요약 설명까지 도시하고 있다.

멤버/정의	설명
개요(abstract)	모델화된 시스템 오브젝트 상에서 동작이 요구되는 설정들을 정의하는데 사용되는 타입
커뮤니케이션 (communication)	종단점 멤버들 간의 커뮤니케이션 관계를 설명한다. 독립적으로 배치된 소프트웨어 요소들 간의 상호작용을 설명하는데 사용된다.
제한 조건(constraint)	제한 조건을 설명한다. 정의의 멤버들의 설정 값 또는 관계 내에서 참여자들에 있어서의 제한 조건을 식별하는데 사용될 수 있다.
포함(containment)	포함 관계 정의는 한 타입이 다른 타입을 포함할 수 있음을 선언한다. 포함 관계 멤버는 한 오브젝트 멤버가 다른 오브젝트 멤버를 포함할 수 있음을 선언한다.
위임(delegation)	종단점 멤버들 간의 위임 관계를 설명한다. 한 시스템에서 다른 시스템으로 작용을 전달하는 것을 허용한다.
종단점(endpoint)	커뮤니케이션 종단점을 설명한다.
플로우(flow)	한 쌍의 설정값에 적용하기 위한 특정 변환을 설명한다.
호스팅(hosting)	오브젝트 멤버들 간의 호스팅 관계를 설명한다. 게스트가 구성되기 위해 호스트를 요구한다는 것을 표시하는데 사용된다(예를 들어 웹 서비스 오브젝트 정의는 IIS 오브젝트 호스트를 요구할 수 있다).
관리자(manager)	어느 타입 및 관계에 의해 커스텀 행동(custom behavior)을 삽입하는지의 메카니즘을 설명한다. 복잡한 제한 조건 및 플로우을 위한 구현을 제공하는데 사용될 수 있다.
오브젝트(object)	애플리케이션의 독립적으로 배치될 수 있는 부분들 또는 시스템이 나타내는 커뮤니케이션 종단점들을 설명하는데 사용되는 시스템 정의들과 같이 모델화된(시뮬레이트된 환경에도 불구하고) 시스템 내에 존재하는 엔티티를 설명한다.
참조(reference)	오브젝트 멤버들 간의 참조 관계를 설정한다. 오브젝트 멤버들 간의 종속성을 캡처하는데 사용된다.
관계(relationship)	오브젝트 멤버들이 생성될 때, 그들간의 관계에 대해 설명한다.
리소스(resource)	시스템 정의의 부분으로 식별될 수 있는 특정 요소들을 설명한다.
서브시스템(subsystem)	완전한 시스템들로서 취급되지만 통상적으로 큰 시스템의 부분인 데이터, 소프트웨어 및/또는 하드웨어 요소들의 집합을 설명한다.
시스템(system)	데이터, 소프트웨어 및/또는 하드웨어 요소들의 집합을 설명한다.

여기서 논의된 엔진들은 값에 의한 멤버(by-value member), 참조에 의한 멤버, 확장, 청취자 및 탑-레벨(top-level) 정의에 의해 참조를 만든다. 값에 의한 멤버는 확장동안 자동적으로 생성되는 인스턴스를 위한 멤버에 속한다. 어떤 구현에서, 값에 의한 멤버는 추상적일 수 없다. 참조에 의한 멤버는 확장동안 확장 엔진에 의해 자동적으로 생성될 수 없는 인스턴스를 위한 멤버이다. 오히려, 확장 엔진 내의 이벤트를 위한 외부 소스 청취가 인스턴스를 생성한다(예를 들어 인터페이스 및 프로세싱 계층(210)은 시뮬레이션 동안 인스턴스를 생성하거나 시뮬레이션 또는 배치동안 인스턴스를 생성하는 설계자 또는 개발자에 (예를 들어 사용자 인터페이스를 통해) 문의할 수 있다).

확장은 주어진 루트 인스턴스에서의 프로세스에 속하고, 인스턴스 스페이스는 상기 루트 인스턴스에 관하여 구분된다. 루트 인스턴스의 모든 멤버들이 재귀적으로 생성된다. 참조에 의한 멤버들은 확장 엔진이 아니라 외부 소스에 의해 생성된다.

청취자(예를 들어, 시뮬레이터(218))는 이벤트가 트리거되었을 때 통지된다. 그러한 이벤트의 예는 생성되는 참조에 의한 멤버를 위해 필요하다. 탑-레벨 정의는 SDM 문서 내에서 루트 레벨로 정의되는 정의에 속한다. 선택적인 실시예에서 SDM 문서는 두 개 이상의 탑-레벨 정의들을 가질 수 있음에도 불구하고, SDM 문서는 통상적으로 단지 하나의 탑-레벨 정의를 갖는다.

도 4는 설계 시간 검증을 위한 예시적인 프로세스(400)을 도시하는 흐름도이다. 프로세스(400)는 도 2의 검증 컴포넌트(208)에 의해 구현되며, 소프트웨어, 펌웨어, 하드웨어 또는 이들의 조합 내에서 실행될 수 있다.

시스템을 생성, 삭제 또는 변경하라는 요구에 응하여, SDM 문서 및 상기 SDM 문서에 관한 임의의 참조들이 로드되고 (동작 402), SDM 문서가 로드되었음을 선택적으로 확인한다. 어떤 실시예에서는, LIM 문서(들)가 로드되었을 수 있고, 상기 LIM 문서(들)에 의해 인스턴스 스페이스(들)이 이미 생성되었을 수 있다. 그러나, 이러한 것이 아직 일어나지 않았다면, LIM 문서(들)는 로드되고, 상기 LIM 문서(들)에 의해 설명되는 인스턴스 스페이스(들)이 생성된다. 어떤 실시예에서, 상기 인스턴스 스페이스(들)은 동작 402에서 SDM 문서를 로딩하기에 앞서 설명된 확장, 플로우 및 제한 조건 엔진들을 사용함으로써 생성된 LIM 문서(들)에 의해 설명된다.

SDM 문서 또는 상기 SDM 문서가 로드될 때 생성되는 타입 공간 내에 에러가 있는지 여부를 위한 검사가 이루어진다(동작 404). 동작 404 내의 상기 검사는 설계되는 시스템이 아닌, SDM 문서 자체의 구조 또는 포맷에 속한다. 예를 들어, 동작 404에서 검사는 SDM 문서의 포맷이 적절한지(예를 들어, 문서가 적절한 XML 포맷인지) 또는 SDM 문서 내에 알려지지 않은 요소 또는 타입이 있는지 또는 SDM 문서 내의 타입 참조들이 유효한지 등을 확인하기 위해 만들어진다. 어떤 에러가 있다면, 그러한 에러들의 표시가 되돌려지고(동작406) 프로세스(400)는 종료된다. 이러한 에러들은 예를 들어, 결과 226으로서, 도 2의 개발 컴포넌트(202)로 되돌려질 수 있다.

그러나, 에러가 없다면, 동작 402에서 로드된 SDM 문서 내의 탑-레벨 정의가 선택된다(동작 408). 어떤 실시예에서는, SDM 문서 내에 단지 하나의 탑-레벨 정의가 존재한다. 상기 선택된 정의를 위한 인스턴스가 생성되고(동작 410), 상기 인스턴스 스페이스는 확장된다(동작 412). 상기 탑-레벨 정의는 확장을 위한 시작 포인트로 사용되고, 이는 도 4의 확장 엔진(410)에 의해 수행된다. 상기 인스턴스 스페이스는 탑-레벨 정의를 분석 및 상기 루트 인스턴스의 각 멤버의 인스턴스를 생성하고, 그리고 각 생성된 인스턴스들을 분석하고 각 멤버들을 위한 인스턴스(들)를 생성하는 것 등에 의해 확장된다. 이 프로세스는 이하의 "확장 엔진" 부분에서 더욱 상세히 논의된다.

탑-레벨 정의에 기초한 확장이 완성될 때, 확장된 인스턴스 스페이스 내의 인스턴스들 상에서 정의된 플로우가 식별되고, 상기 플로우 내의 값들이 적절한 값들로 설정된다(동작 414). 이 프로세스는 이하의 "플로우 엔진" 부분에서 더욱 상세히 논의된다.

플로우들의 평가로부터의 값들이 설정된 후에, 제한 조건들이 검사된다(동작 416). 인스턴스 스페이스 내의 각 제한 조건 멤버는 제한 조건 검사의 일부로서 평가되며, 이하 "제한 조건 엔진" 부분에서 더욱 상세히 논의된다. 이들 제한 조건들은 통상적으로 시스템이 확인되는 시뮬레이트된 환경 내의 설정에 대해 검사된다 (예를 들어 LIM (206)으로 설명된 바와 같은).

제한 조건 검사가 완료된 후에, 아직 선택되지 않은 SDM 문서 내의 임의의 부가적인 탑-레벨 정의들이 있는지 여부를 위한 검사가 이루어진다. SDM 문서 내에 하나 이상의 추가적인 탑-레벨 정의가 있다면, 이들 추가적인 탑-레벨 정의들 중 하나가 선택되고(동작 420), 프로세싱은 선택된 탑-레벨 정의의 인스턴스가 생성되는 동작(410)으로 되돌아간다.

그러나, 선택되지 않는 탑-레벨 정의가 없다면, 에러가 검출되었는지 여부를 위한 검사가 이루어진다(동작 422). 동작 422 내의 이들 에러들은 동작 412의 확장, 동작 414의 플로우 및 동작 416의 제한 조건 검사 동안 만들어지는 에러 및/또는 경고들에 속한다. 에러 또는 경고가 있다면, 이들 에러 및 경고들의 표시가 되돌려지고(동작 406), 프로세스(400)는 종료된다. 이들 에러들은 예를 들어, 결과 226으로서, 도 2의 개발 컴포넌트(202)로 되돌려질 수 있다.

동작 406에서 개발 컴포넌트(202)로 에러 및/또는 경고들 또는 동작 424에서 성공의 표시가 되돌려짐으로써, SDM 문서(204) 내에서 설명된 시스템의 설계 시간 검증이 개발 컴포넌트(202)로 되돌려진다. 이들 에러들 및/또는 경고들, 또는 성공의 표시는 설계된 시스템이 유효한지 여부(그리고 SDM 문서(204) 내에서 설명되었는지) 또는 잠재적인 문제가 있는지 여부를 설계자에게 알리는 것을 허용하도록 개발 컴포넌트(202)를 사용하는 것을 개발자에게 나타낼 수 있다. 설계자에 대한 특정 에러 및 또는 경고들의 표시를 되돌림으로써, 설계자는 어떠한 잠재적인 문제점이 있는지, 이들을 어떻게 해결할지(또는 해결할 필요가 있는지 여부) 보다 잘 알 수 있다. 이러한 피드백은 설계 프로세스 동안 설계자에게 부여될 수 있고, 설계자가 설계된 시스템에 대한 문제점을 발견하기 전에 데이터 센터에서 시스템을 배치하는 시도를 하는 것을 요구하지 않을 수 있다.

시뮬레이션

상술한 바와 같이 도 2의 인터페이스 및 프로세싱 계층(210)은 LIM 문서(206)에서 정의된 환경을 시뮬레이션한다. 이는 시스템 설계 동안, SDM 문서(204)에 의하여 설명된 시스템이 예상되는 환경에 대하여 확인될 수 있도록 하여, 시스템을 환경에 배치하기에 앞서 에러가 식별될 수 있도록 한다.

인스턴스 스페이스 내의 많은 인스턴스는 확장 엔진(expansion engine)에 의 하여 생성될 수 있는데, 이에 대해서는 이후에 상세히 설명한다. 그러나, 인스턴스 일부는 확장 엔진이 아닌 시뮬레이터(218)에 의하여 생성된다. 어떤 실시예에 있어서는, 시뮬레이터(218)에 의하여 생성된 인스턴스는 탑-레벨 정의(top-level definitions) 및 참조에 의한 멤버이다. 어떤 구현에 있어서는, 각 탑-레벨 정의는 그 고유의 인스턴스 스페이스에서 시뮬레이션된다.

시뮬레이터(218)는 컴파일되는 문서의 루트에서 발견되는 2가지 카테고리의 정의(이는 탑-레벨 정의로서 참조됨)를 시뮬레이션한다: 2가지 정의는 (1) 시스템 정의, 및 (2) 호스트 및 게스트가 시스템 정의인 호스팅 정의이다. 이러한 2가지 카테고리의 정의는 주로 자립형 정의(stand-alone definitions)이며, 이를 위하여 인스턴스가 시뮬레이터(218)에 의하여 생성될 수 있다. 다른 정의는 일반적으로 다른 정의의 컨텍스트에서만 사용되고, 따라서 확장 엔진(220)에 의하여 생성될 수 있다. 어떤 실시예에 있어서는, 시뮬레이터(218)는 추상적인 정의를 시뮬레이션하지 않으며, 그렇기 때문에 전형적으로 거의 의미 없는 확인을 가져오게 된다.

시스템 정의는 정의를 위한 인스턴스를 생성하고, 인스턴스를 인스턴스 스페이스의 루트 인스턴스로서 추가함으로써 시뮬레이션된다. 멤버 및 인스턴스의 내포된 멤버(nested members)은, 확장 엔진(220)을 호출(invoke)함으로써 인스턴스화된다.

호스팅 정의의 시뮬레이션은 호스트와 게스트 간의 확인을 제공한다. 어떤 실시예에 있어서는, 호스팅 관계의 인스턴스는 루트 인스턴스로서 사용되지 않고, 따라서 확장 엔진이 호출되기 전에 특정 루트 인스턴스가 생성된다. 이 특정 루트 인스턴스는 다음과 같은 3개의 멤버를 갖는 시스템 정의이다: (1) 호스팅 관계의 호스트에 대한 시스템 정의, (2) 호스팅 관계의 게스트에 대한 시스템 정의, 및 (3) 호스트의 인스턴스와 관련된 호스팅 정의 및 처음 2개의 멤버의 게스트 시스템 정의. 그 후, 확장 엔진(220)은 멤버 및 특정 루트 인스턴스의 내포된 멤버를 인스턴스화하기 위하여 호출된다.

확장 엔진(220)은 참조에 의한 멤버의 인스턴스를 생성하지 않는데, 이는 생성하기 위한 인스턴스의 수는 알려지지 않고 배치 환경에 의하여 결정되기 때문이다. 또한, 참조에 의한 멤버는 추상적일 수 있으므로, 멤버를 인스턴스화하기 위하여 사용되는 구체적인 정의는 알지 못한다. (예를 들어, 시스템 관리자에 의한) 인간 간섭(human intervention)이 배치하는 동안에 이러한 질문에 답하기 위하여 일반적으로 사용된다. 이러한 간섭은 설계 시간 검증(design time validation) 동안 선택적으로 사용될 수도 있다. 그러나 보다 전형적으로는, 인터페이스 및 프로세싱 계층(210)(예를 들어, 시뮬레이터(218))이 다음과 같이 인간 작업자가 선택한 것을 시뮬레이션하며, 그럼으로써 시뮬레이션 동안에 인간 작업자의 필요성을 덜 수 있다. 시뮬레이터(218)는, 1 또는 (예를 들어, 참조에 의한 멤버를 위한 파라미터 MinOccurs에서 지정됨) 발생의 최소 수 중 큰 것과 동일한, 다수의 멤버의 인스턴스를 생성한다. 참조에 의한 멤버가 추상적이라면, 시뮬레이터(218)는 멤버의 인스턴스를 생성하지 않고 사용자가 경고하는 정보를 되돌려 줄 것이다(예를 들어, 추상적인 참조에 의한 멤버는 시뮬레이션 될 수 없다고 표시함).

확장 엔진(Expansion Engine)

확장 엔진(220)은, 대강의(broad) 명령어가 검증 컴포넌트(208)로 입력되어 이러한 명령어가 밖으로 확장될 수 있게 하여, 이러한 명령어에 의하여 영향을 받는 관계 및 적절한 오브젝트를 식별한다. 전형적으로는, 이러한 대강의 명령어는 특정 오브젝트 또는 관계를 생성 또는 삭제하기 위한 명령어(예를 들어, 웹 애플리케이션을 생성하기 위한 명령어, 또는 웹 애플리케이션을 삭제하기 위한 명령어)이다. 확장 엔진(220)은 SDM 파일(204)에 기초하여 인스턴스 스페이스를 생성하는 동작의 세트를 확장하여, 값에 의한 자식 및 관계(by-value children and relationships)를 포함하여 요구되는 추가적인 인스턴스 및 동작을 추가하거나, 적절한 인스턴스 및 관계를 제거한다.

우선, 시뮬레이션 동안에 탑-레벨 정의의 인스턴스(탑-레벨 인스턴스라고도 함)가 생성된 후, 인스턴스 스페이스를 거주시키기 위하여 발동된다. 루트 인스턴스는 확장의 시작 위치로서 확장 엔진(220)으로 보내진다. 확장에 의하여 생성된 인스턴스는 루트 인스턴스와 관련된다. 특정 인스턴스 스페이스에 대하여 확장 엔진(220)이 처음 호출될 때, 확장 엔진(220)으로 보내지는 루트 인스턴스는 탑-레벨 인스턴스(탑-레벨 정의의 인스턴스)이다. 그러나, 확장 엔진(220)은 이른바 반복적일 수 있고, 전형적으로는 반복적이다. 따라서 멤버 및 탑-레벨 인스턴스의 내포된 멤버는 그러한 반복 호출에 대한 루트 인스턴스이다.

확장 엔진(220)은 루트 인스턴스의 각 멤버의 인스턴스(들)를 생성함으로써 개시된다. 각 멤버가 인스턴스화되면, 이는 내포된 멤버에 대하여 시험된다. 다른 멤버 내에서 정의된 임의의 멤버는 그 다른 멤버 내에 내포된 것으로서 참조된다. 멤버의 내포는 다중 레벨을 통하여 발생할 수 있다 (예를 들어, 멤버가 멤버 내에 정의된 멤버를 내포할 수 있고, 이러한 멤버의 각각이 이들 내에서 정의되는 멤버를 내포할 수 있으며, 반대로 이들 내에 정의된 멤버를 내포할 수도 있다). 인스턴스 스페이스가 루트 인스턴스에 대하여 완전히 생성될 때까지, 확장 프로세스가 멤버 및 내포된 멤버 각각에서 반복되어 수행된다.

어떤 실시예에 있어서는, 멤버의 다양한 유형의 서브세트만이 확장 동안에 인스턴스화된다. 확장 동안에 생성되는 이 인스턴스의 서브세트는 서브시스템, 리소스 및 종단점와 같은 오브젝트 멤버를 포함한다. 확장 동안에 생성되는 이 인스턴스의 서브세트는 또한, 포함, 커뮤니케이션(Communication), 호스팅(Hosting), 위임(Delegation) 및 참조(Reference) 등의 관계 멤버를 포함한다. 이 서브세트에 포함되지 않는 기타 멤버는 확장에 의하여 인스턴스화되지 않고, 오히려 상기 인스턴스 중 하나가 확장에 의하여 생성되었을 때, 특정 프로세스가 정의의 멤버를 시험하고 이러한 다른 멤버에 대한 자식 멤버의 인스턴스를 생성한다. 이러한 다른 멤버의 예는 플로우 멤버(flow members) 및 제한 조건 멤버(constraint members)을 포함한다.

어떤 실시예에 있어서는, 확장 엔진(220)이 호출되었을 때 이미 멤버의 인스턴스가 존재하면, 인스턴스가 다시 생성되지 않는다. 그러나, 확장 엔진(220)은, 인스턴스 스페이스가 충분히 생성되었는지 검증하기 위하여 각 인스턴스에 대해 반복적으로 계속한다(그리고 아직 생성되지 않은 이 반복 호출로부터 임의의 내포된 멤버를 생성한다).

도 5A 및 도 5B는 인스턴스 스페이스를 생성하는 예시적인 반복 확장 프로세스(500)를 도시한 흐름도이다. 인스턴스 스페이스는 도 2의 SDM 문서(204)와 같은 SDM 문서에 의하여 정의된다. 프로세스(500)는 도 2의 확장 엔진(220)에 의하여 구현되며, 소프트웨어, 펌웨어, 하드웨어 또는 이들의 조합에서 수행될 수 있다.

우선, 인스턴스 정의가 액세스된다(동작502). 확장 엔진(220)이 호출되면, 확장 엔진(220)은 확장될 인스턴스 정의(본 섹션의 이전 부분에서 설명한 루트 인스턴스)를 인식하고, 이 인스턴스 정의가 동작(502)에서 액세스된다. 확장 엔진(220)은, 인스턴스 정의를 보내거나, 인스턴스 정의가 위치하는 식별자(예를 들어, 포인터)를 보내거나, 아니면 인스턴스 정의가 액세스될 수 있는 장소 및/또는 방법을 인식한다. 프로세스(500)는 탑-레벨 정의인 인스턴스 정의 내의 시뮬레이터(218)에 의하여 호출되거나, 또는 프로세스(500) 자체에 의하여 반복적으로 호출될 수 있다.

그리고, 인스턴스 정의의 멤버가 선택된다(동작 504). 멤버는 임의의 순서로 인스턴스 정의로부터 선택될 수 있는데, 전형적으로는 인스턴스 스페이스를 정의하는 SDM 파일에 나타난 순서에 따라 선택된다. 어떤 실시예에서는 모든 오브젝트 멤버가 선택되는 임의의 관계 멤버에 앞서 선택된다.

선택된 멤버가 오브젝트 멤버인지 또는 관계 멤버인지에 관한 검사가 행해지고(동작 506), 이 검사 결과에 기초하여 프로세스(500)를 계속한다. 선택된 멤버가 오브젝트 멤버라면, 선택된 멤버의 인스턴스의 정확한 수가 생성되는 인스턴스 스페이스에 이미 존재하는지에 대한 검사가 행해진다(동작508). 각 멤버는 몇 개의 멤버의 인스턴스가 생성되어야 하는지에 대한 표시를 포함한다. 어떤 실시예에서는, 하나의 인스턴스의 디폴트 값이 사용되고, 따라서 멤버가 더 많은 인스턴스가 생성되어야 한다고 지정하지 않는다면 각 멤버의 인스턴스가 한 개(멤버에서 명백하게 지정되었는지 여부) 생성된다.

정확한 수의 인스턴스가 존재하지 않는다면, 오브젝트 멤버가 값에 의한 멤버(by value member)인지 검사가 행해진다(동작 510). 오브젝트 멤버가 값에 의한 멤버라면, 멤버 정의에서 지정된 바와 같이 오브젝트의 발생의 최소수가 생성된다(동작 512). 그러나, 오브젝트 멤버가 값에 의한 멤버가 아니라면, 이는 참조에 의한 멤버이므로, 청취자(예를 들어, 도 2의 시뮬레이터(218))로 하여금 참조에 의한 멤버의 인스턴스를 생성하도록 하는 이벤트가 트리거된다.

단계(512) 또는 단계(514)에서 오브젝트 멤버의 인스턴스가 생성된 후, 또는 단계 (508)에서 이미 올바른 수의 멤버 인스턴스가 존재한다고 판정되었으면, 프로세스(500)는 단계(516)로 계속된다. 단계(516)에서, 단계(512) 또는 단계(514)에서 생성된 인스턴스(또는 단계(508)에서 이미 생성된 것으로 판정된 인스턴스)의 각 멤버 인스턴스에 대하여 프로세스(500)가 호출된다. 프로세스(500)를 재귀적으로 호출할 때, 프로세스(500)가 호출되는 각 멤버 인스턴스는 호출된 프로세스(500)에 대한 인스턴스 정의가 된다. 따라서, 모든 인스턴스가 인스턴스 스페이스에 생성될 때까지 프로세스(500)가 오브젝트 멤버에 대하여 재귀적으로 호출된다.

추가적으로, 단계(504)에서 선택되지 않았던 인스턴스 정의 내의 추가적인 멤버가 있는지에 대하여 검사가 행해진다(단계 518). 만일 인스턴스 정의 내에 이러한 하나 이상의 추가적인 멤버가 있으면, 프로세스(500)는 단계(504)로 복귀하며 여기서 그 멤버 중 하나가 선택된다. 그러나, 만일 인스턴스 정의 내에 이러한 추가적인 멤버가 없으면, 프로세스(500)는 이 인스턴스 정의에 대해서는 완료된 것이다.

단계(506)로 돌아가, 만일 선택된 멤버가 관계 멤버(relationship member)이면, 프로세스(500)는 그 관계와 연관된 소스 인스턴스의 수와 목적 인스턴스의 수에 기초하여 생성할 관계 인스턴스의 수를 식별한다(도 5b의 단계 522). 소스 인스턴스의 수를 목적 인스턴스의 수로 승산한 결과가 생성할 관계 인스턴스의 수이며, 이로써 생성할 관계 인스턴스의 수가 결정된다. 이어서, 식별된 수의 관계 인스턴스가 생성된다(단계 524).

대안적으로, 소스 인스턴스의 수를 목적 인스턴스의 수로 승산하는 것은 관계 인스턴스의 수의 최대값일 수 있으며, 단계(524)에서 이 최대값의 서브 세트만이 생성될 수 있다. 예를 들어, 만일 다수의 가능한 호스트가 존재하면, 단계(524)에서 하나만이 선택될 수 있다. 전술된 참조 멤버에 의한 것과 유사하게, 청취자(예를 들어, 인간 오퍼레이터 또는 시뮬레이터 218)는 관계 인스턴스의 서브 세트를 선택하도록 요구받을 수 있다. 시뮬레이터(218)는, 예를 들어 어떤 관계 인스턴스의 서브 세트를 생성할지를 결정하는 데에 사용되어야 하는 다양한 기준 또는 따라야 할 규칙과 함께 구성 또는 프로그래밍될 수 있다.

관계 인스턴스는 관계 멤버의 유형에 따라 상이한 방식으로 생성된다. 일부 실시예에서, 포함 정의 멤버(containment definition member), 통신 정의 멤버(communication definition member), 참조 정의 멤버(reference definition member), 호스팅 정의 멤버(hosting definition member), 위임 정의 멤버(delegation definition member)와 같은 관계 멤버의 유형이 사용된다. 포함 정의 멤버는 일대다(one-to-many) 관계로서, 부모를 자식 멤버의 각 인스턴스와 연관시킨다. 포함 정의 멤버는 오브젝트 멤버가 다른 오브젝트 멤버에 포함될 수 있다는 것을 기술한다. 통신 정의 멤버는 다대다(many-to-many) 관계로서, 서버 및 클라이언트 멤버 인스턴스의 모든 조합을 연관시킨다. 통신 정의 멤버는 독립적으로 배치된 소프트웨어 컴포넌트간의 상호작용을 기술한다. 참조 정의 멤버는 다대다 관계로서, 모든 소스 종속 멤버의 조합을 연관시킨다. 참조 정의 멤버는 (호스팅 정의 멤버에 추가하여) 인스턴스간의 종속성(dependencies)을 캡쳐링하는 데에 사용된다. 이러한 종속성은, 예를 들어 배치 중에 구축 순서를 제어하고 인스톨 및 갱신 중에 시스템간에 파라미터를 전달하는 데에 사용될 수 있다. 호스팅 정의 멤버는 일대다 관계로서, 호스트를 그 게스트의 멤버 인스턴스의 각각과 연관시킨다. 호스팅 정의 멤버는, 게스트가 구축되기 위하여 호스트를 요하는 것을 식별하는 데에 사용된다. 위임 정의 멤버는 일대일 관계로서, 두 시스템의 통신 종단점을 연관시킨다. 위임 정의 멤버는 하나의 시스템으로부터 또 다른 시스템으로 행위를 포워딩(예를 들어, 하나의 시스템으로 지정되었을 모든 상호작용을 다른 시스템상의 종단점으로 포워딩)하는 데에 사용된다.

각 관계 인스턴스에 있어서, 소스 및 목적 인스턴스는 그 관계 인스턴스와 연관된다(단계 526). 이어서, 프로세스(500)는 5a의 단계(518)로 복귀하며, 여기서, 선택될 인스턴스 정의 내의 추가적인 멤버가 있는지에 대한 검사가 행해진다.

프로세스(500)는 재귀적으로 호출되며, 프로세스(500)가 재귀적으로 호출될 때 다양한 오브젝트 및 관계 인스턴스가 생성된다. 모든 멤버 인스턴스가 생성되었을 때 재귀적인 확장 프로세스는 인스턴스 스페이스의 생성을 완료하였음을 안다.

확장 프로세스의 재귀적인 성질 때문에, 귀결되는 인스턴스는 서로 링크되는데, 여기서 탑-레벨 인스턴스는 도 2의 플로우 엔진(222)과 제한 조건 엔진(224)을 위한 엔트리 포인트이다. 이렇게 생성된 인스턴스 스페이스는 인스턴스 트리로 보여질 수 있으며, 트리의 각 노드는 멤버 인스턴스를 나타낸다. 추가적으로, (탑-레벨 노드를 제외한) 트리의 각 노드는 트리의 그 노드를 생성하기 위하여 확장 프로세스를 호출한 멤버 인스턴스를 나타내는 부모 노드와 링크된다. 또한, 트리의 각 노드는, 트리의 그 노드의 멤버 인스턴스의 멤버인 0개 이상의 자식 노드와 링크된다. 재귀적인 확장 프로세스는, 리프 멤버(leaf member)가 어떤 내포(nesting)된 멤버도 갖지 않을 때(예를 들어, 모든 리프 멤버가 자식 노드를 갖지 않을 때), 인스턴스 그래프의 생성을 완료하였음을 안다. 추가적으로, 일부 실시예에서, 그 유형의 멤버를 가진 정의로 인하여 확장 프로세스가 불확정으로(indefinite) 될 수 있는 상황을 방지하기 위하여, 확장 프로세스는, 정의가 이미 조상 인스턴스(ancestor instance)로서 생성되지 않은 경우에만 인스턴스를 생성하도록 선택할 것이다. 예를 들어, 만일 디렉토리의 정의가 있고 그것이 그 안에 디렉토리를 가지면, 확장 엔진은, 일단 단일의 디렉토리가 있으면, 이를 확장하는 것을 중단할 것이다.

플로우 엔진(Flow Engine)

확장 엔진(220)이 확장 프로세스를 완료한 후, 시뮬레이터(218)는 그 확장 프로세스로 인하여 귀결되는 인스턴스 스페이스에 대하여 플로우 엔진(222)을 호출한다. 플로우 엔진(222)는 인스턴스 스페이스의 인스턴스 그래프 상을 "걸으며(walk)", 그 인스턴스 그래프에서 정의된 플로우 인스턴스를 찾는다. 이어서, 플로우 엔진(222)은 플로우 내의 값들을 적절한 값으로 설정한다.

설정(settings)은 SDM 파일(204) 내의 정의 상에서 선언될 수 있으며, 대응하는 설정값(setting values)은 이 정의로부터 생성된 인스턴스 상에 존재할 수 있다. 설정값은 비계산 설정값이거나 계산 설정값일 수 있다.

비계산 설정값(non-calculated setting values)은 디폴트값 또는 (예를 들어, SDM 파일 204 내의) 정의로부터의 초기값에 의하여 설정되거나, 명시적으로 값을 설정하는 사용자에 의하여 설정된 설정값이다. 비계산 설정값은 그것이 속하는 SDM 인스턴스의 생성시에만 설정되는 것으로 제한될 수 있으며, 대안적으로, SDM 인스턴스의 수명 동안 변경될 수도 있다. 비계산 설정값은 플로우의 출력이 아니지만, 플로우로의 입력으로서 기능할 수 있다.

계산 설정값(calculated setting values)은 플로우의 출력인 설정값이다. 결과로서, 플로우는 계산 설정값의 값을 설정할 수 있지만, 다른 엔티티(entity)는 일반적으로 그럴 수 없다. 일부 실시예에서, 특정 계산 설정값에 대하여 값을 공 급하는 플로우가 하나만 있을 수 있다. 이러한 실시예에서, 만일 다수의 플로우가 동일한 설정값 인스턴스로 출력하면, 에러가 보고되고 플로우의 출력은 에러 상태로 설정된다. 계산 설정값은 하나 이상의 입력에 기초한다. 이러한 입력은 계산 설정값 및/또는 비계산 설정값일 수 있다.

일부 실시예에서, 계산 설정값은 구성값(configuration values)과 비구성값(non-configuration values)의 두 개의 카테고리로 나뉠 수 있다. 구성값은, 그것이 일부를 형성하는 SDM 인스턴스의 구성으로 귀결되며 플로우에 의하여 계산되는 값이다. 예를 들어, 파일로의 풀 패스(full path) 또는 데이터베이스 이름은 구성값일 것이다.

비구성값은 플로우에 의하여 계산되지만 구성으로 귀결되지 않는 값이다. 대신, 비구성값은 제한 조건을 위하여 계산되는 값으로서만 존재한다. 예를 들어, 모든 상속된 웹 구성값(web.config values)을 고려하는 귀결되는 웹 구성 설정은 비구성값일 것이다. 비구성값의 또 다른 예는, 그 파일의 포함된 디렉토리 및 용량 뿐만 아니라 그 파일에 대한 구성된 액세스 제어 목록을 고려하는 귀결되는 파일에 대한 액세스 제어 목록일 것이다.

플로우 엔진(222)은, 선택적으로 구성값 및 비구성값을 상이하게 처리할 수 있다. 예를 들어, 구성값에 더 높은 우선순위를 부여함으로써, 구성값을 설정하는 플로우가 비구성값을 설정하는 플로우보다 먼저 평가되도록 할 수 있다.

일반적으로, 인스턴스 스페이스 내의 플로우 인스턴스를 식별하고, 플로우 인스턴스로의 입력값을 식별함(예를 들어, 이 입력의 소스인 다른 인스턴스의 설정 값을 식별함)으로써 플로우가 평가(evalulating)된다. 명령 세트 또는 모듈은 플로우 인스턴스에 의하여 참조되며, 그 플로우 인스턴스에 대응하는 플로우 함수를 처리할 수 있다. 플로우 함수는 입력값에 기초하여 처리되며, 플로우 함수의 결과가 얻어진다. 플로우 함수의 결과는 플로우 인스턴스의 출력으로서 설정된다. 플로우는 0개 이상의 입력값과 하나 이상의 출력을 가질 수 있다(예를 들어, 하나 이상의 인스턴스에 대한 설정값이 플로우의 출력에 기초하여 설정될 수 있다).

광범위한 플로우 함수 중 어느 것도 사용 가능하다. 플로우 함수는 시스템 개발자 및/또는 다른 집단에 의하여 정의될 수 있다. 예를 들어, SDM 파일(204)을 생성한 동일한 설계자가 하나 이상의 플로우 함수를 정의할 수 있다. 또 다른 예로서, 개발 컴포넌트(202)의 제조자 또는 다른 어떤 제3의 집단의 개발자가 하나 이상의 플로우 함수를 정의할 수 있다. 플로우 함수 자체는 대수, 기하, 미적분 등을 사용하는 계산, 날짜 및/또는 시간 기반 계산, 난수 계산 등의 임의의 다양한 계산 및/또는 동작을 포함할 수 있다.

일부 실시예에서, SDM 파일(204) 내에 정의된 플로우 멤버는 관리자 정의(manager definition)와 연관된다. 관리자 정의는, 플로우 함수를 처리하기 위하여 실행될 수 있는 명령 또는 코드 세트에 대한 포인터를 포함한다. 따라서, 플로우 인스턴스에 대하여 플로우를 평가하기 위하여, 연관된 관리자 정의가 식별되고 연관된 관리자의 인스턴스가 (이미 생성되지 않았으면) 생성된다. 명령 또는 코드 세트로의 포인터는 관리자로부터 획득되며, 이는 플로우 출력을 결정하기 위하여 명령 또는 코드 세트가 획득 및 실행될 수 있도록 한다.

추가적으로, 일부 실시예에서 관리자는 유형 전환(type conversion)을 지원할 수도 있다. 이러한 실시예에서, 관리자는 플로우가 서로 다른 유형의 둘 이상의 설정값에 기초할 수 있도록 한다. 예를 들어, 입력값은 출력 유형과 상이한 유형일 수 있다. 관리자는, 이러한 유형의 전환이 행해질 수 있도록 하는 하나 이상의 방법을 진열하거나, 대안적으로 전환을 수행하기 위하여 획득 및 실행되는 명령 또는 코드 세트로의 포인터를 포함한다. 상이한 전환은 상이한 관리자에 의하여 지원될 수 있다(예를 들어, 관리자 설계자는 관리자가 그들이 원하는 어떠한 유형의 전환도 지원하도록 설계할 수 있다).

도 6a 및 6b는 플로우를 평가하기 위한 예시적인 프로세스(600)를 도시하는 흐름도이다. 프로세스(600)는 도 2의 플로우 엔진(222)에 의하여 구현되며, 소프트웨어, 펌웨어, 하드웨어, 또는 이들의 조합으로 수행될 수 있다.

초기에, 인스턴스 스페이스 내의 인스턴스에 대한 모든 설정이 찾아진다(단계 602). 이러한 설정은 다른 방식, 예를 들어 설정값에 대하여 인스턴스 그래프 내의 각 노드를 검사함으로써 찾아질 수 있다. 이어서, 인스턴스 스페이스 내의 모든 플로우 인스턴스가 식별된다(단계 604). 인스턴스 스페이스 내의 각 플로우 인스턴스는 "더티(dirty)" 및 "미방문(not visited)"으로 마킹(marking)된다(단계 606). "더티" 마킹은 플로우의 실행 또는 평가가 아직 완료되지 않았다는 것을 지시한다. "미방문" 마킹은 플로우의 실행 또는 평가가 아직 시작되지 않았다는 것을 지시한다. 플로우 인스턴스의 마킹은 다양한 상이한 방식으로 수행될 수 있다. 예를 들어, 각 플로우 인스턴스는, 그 플로우 인스턴스를 "더티"로 마킹하기 위하 여 설정될 수 있는 "더티" 플래그와, 그 플로우 인스턴스를 "미방문"으로 마킹하기 위하여 설정될 수 있는 "미방문" 플래그를 가질 수 있다. 또 다른 예로서, 플로우 엔진(222)은 플로우 인스턴스 및 그와 연관된 마킹의 기록을 보존할 수 있는 목록, 테이블, 또는 다른 데이터 구조를 유지할 수 있다.

이어서, 플로우 인스턴스의 결과로서 값을 수신하는 설정이 식별된다(단계 608). 단계(608)에서, 모든 계산 설정값이 식별된다. 설정 자체는 그것이 계산 설정값인지 또는 비계산 설정값인지를 지시한다(예를 들어, 설정은 그것이 비계산 설정값이라는 것을 지시하기 위하여 설정될 수 있는 "고정(fixed)" 속성과 같은 속성 또는 플래그를 가질 수 있다). 단계(608)에서 값 종속성을 식별하는 종속 그래프도 선택적으로 생성될 수 있다. 종속 그래프는 각 설정값에 대하여 그것이 다른 어떤 설정값(즉, 그것의 입력인 다른 설정값)에 종속되는지와, 다른 어떤 설정값(즉, 그것을 입력으로서 사용하는 다른 설정값)이 그것에 종속되는지를 지시한다.

이어서, 단계(604)에서 식별되어 "더티" 및 "미방문"으로 마킹된 플로우 인스턴스 중 하나가 선택된다(단계 610). 플로우 인스턴스는, 예를 들어 플로우 인스턴스가 단계(604)에서 식별된 순서, 무작위순, 입력값의 수에 기초한 순서 등과 같은 임의의 순서로 선택될 수 있다. 이어서, 선택된 플로우 인스턴스는 "방문"으로 마킹되지만, "더티"로 마킹된 채로 남아 있다(단계 612). 이는 그 플로우 인스턴스와 연관된 플로우의 평가 또는 실행이 시작되었지만, 플로우의 실행 또는 평가가 아직 완료되지는 않았다는 것(예를 들어, 플로우에 대한 출력값이 아직 결정되지 않았다는 것)을 지시한다.

이어서, 플로우 인스턴스에 대한 입력이 식별된다(단계 614). 각 플로우 인스턴스는 그 입력의 각각에 대한 소스를 식별하는 파라미터(예를 들어, 또 다른 오브젝트의 특정 설정값)를 갖는다. 이어서, 식별된 입력이 값을 할당받았는지에 대한 검사가 행해진다(도 6b의 단계 616). 비계산 설정값인 입력은 값을 할당받았을 것이며, 이미 평가된 플로우 인스턴스에 의하여 계산되는 계산 설정값인 입력도 그러할 것이다. 그러나, 아직 평가되지 않은 플로우 인스턴스에 의하여 계산되는 계산 설정값은 아직 값을 할당받지 못하였을 것이다(예를 들어, 널(null) 값을 가질 수 있을 것이다).

만일 하나 이상의 식별된 입력이 값을 할당받지 못했으면, 이어서 (단계 610에서 선택된) 이 플로우 인스턴스의 평가는 중지(pausing)된다(단계 618). 입력값이 계산될 수 있도록 하기 위하여 평가가 중지된다. 아직 값을 갖지 않는 각 입력에 대하여, 입력값을 설정하는 플로우 인스턴스가 식별된다(단계 620). 이어서, 프로세스(600)는 도 6a의 단계(612)로 복귀하여 그 플로우 인스턴스의 평가를 시작한다(단계 622). 이어서, 모든 입력이 값을 가질 때, 단계(618)에서 중지된 플로우 인스턴스의 평가가 재개된다(단계 624). 평가는, 예를 들어 후술되는 단계(616) 또는 단계(626)에서 재개될 수 있다. 단계(620)에서 식별된 하나 이상의 플로우 인스턴스의 평가 자체가 식별된 입력이 아직 값을 가지지 않음으로 인하여 중지될 수 있다는 점을 주의해야 한다.

단계(616)로 돌아가, 만일 식별된 입력이 값을 가지면, 그 입력의 값은 그 소스로부터 획득된다(단계 626). 예를 들어 SDM 파일(204), SDM 파일(204)에 기초 하여 인스턴스가 생성된 오브젝트, 플로우 인스턴스(플로우의 출력) 등과 같은 다른 소스로부터 값이 획득될 수 있다. 이어서, 플로우 멤버에 대하여 플로우 함수를 평가하기 위하여 실행할 명령 또는 코드 세트가 식별된다(단계 628). 대안적으로, 실행되는 명령 또는 코드 세트 대신, 플로우 함수가 하드웨어로 구현될 수 있다. 이어서, 명령 또는 코드 세트가 실행되고, 실행된 명령 또는 코드 세트의 결과가 플로우 인스턴스의 출력으로서 사용되며(단계 630), 플로우의 출력으로서 참조되기도 한다.

이어서, 플로우의 실행 또는 평가가 완료되었다는 것을 지시하기 위하여 플로우 인스턴스가 "더티(not dirty)하지 않음"으로 마킹된다(단계 632). 단계(612)에서 플로우 인스턴스가 이미 "방문"으로 마킹되었어야 하지만, 만일 플로우 인스턴스가 아직 "방문"으로 마킹되지 않았다면, 단계(632)에서 플로우 인스턴스가 "방문"으로 마킹될 수도 있다.

이어서, 인스턴스 스페이스에서 식별되고 "더티" 또는 "미방문"으로 마킹된 추가적인 플로우 인스턴스가 있는지에 대한 검사가 행해진다(단계 634). 만일 이러한 추가적인 플로우 인스턴스가 있으면, 프로세스(600)는 도 6a의 단계(610)로 복귀하며, 여기서 이러한 추가적인 플로우 인스턴스 중 하나가 선택된다. 모든 플로우 인스턴스가 평가되었을 때(예를 들어, 단계 604에서 식별된 플로우 인스턴스 중 어느 것도 "더티" 또는 "미방문"으로 마킹되지 않을 때), 플로우 평가 프로세스(600)는 완료된다(단계 636). 플로우가 완료되면, 시뮬레이터(218)는 설정을 위한 값을 가진 완성된 인스턴스 스페이스를 갖는다.

도 6a 및 6b에서, 프로세스(600)는 아직 값을 갖지 않은 입력을 가진 플로우 인스턴스의 평가를 중지하고 그러한 값들을 설정하는 플로우 인스턴스를 평가한다고 설명되었다. 그러나, 프로세스(600)는 대안적인 방식으로 구현될 수도 있을 것이다. 예를 들어, 그러한 값을 설정하는 플로우 인스턴스를 평가하는 대신, 프로세스(600)는 도 6a의 단계(610)로 복귀할 수 있으며, 여기서 플로우 인스턴스 중 하나가 (그것이 중지된 플로우의 입력값을 설정하는지와 무관하게) 선택된다. 이러한 대안적인 방식으로 플로우 인스턴스를 평가하는 것은, 일부 플로우 인스턴스의 평가는 완료되었지만 다른 모든 플로우 인스턴스의 평가는 중지되는 상황으로 귀결될 수 있다. 이러한 상황이 발생할 때, 식별된 입력이 값을 갖는지를 판정하기 위하여, 중지된 플로우 인스턴스 각각에 대하여 단계(616)가 반복될 수 있다. 적어도 하나의 중지된 플로우 인스턴스에 대한 입력이 값을 가져야 하며, 모든 플로우 인스턴스의 평가가 완료될 때까지 이러한 단계(616)의 반복 프로세스가 계속되어야 한다.

플로우 엔진(222)은 또한 도 6a 및 6b의 플로우 평가 프로세스 중 순환 참조(circular reference)를 검출한다. 순환 참조는, 하나 이상의 플로우 인스턴스가 각각 적어도 하나의 입력에 대하여 서로의 출력에 (직접적 또는 간접적으로) 종속되는 상황을 가리키는 것이다. 예를 들어, 플로우 인스턴스(A)가 플로우 인스턴스(A)으로의 입력값이기도 한 출력값을 가지는 경우가 그러하다. 또 다른 예로서, 플로우 인스턴스(A)가 플로우 인스턴스(B)로부터의 출력인 입력값을 갖고, 플로우 인스턴스(B)가 플로우 인스턴스(A)로부터의 출력인 입력값을 가지는 경우가 그러하다. 또 다른 예로서, 플로우 인스턴스(A)가 플로우 인스턴스(B)로부터의 출력인 입력값을 갖고, 플로우 인스턴스(B)가 플로우 인스턴스(C)로부터의 출력인 입력값을 가지며, 플로우 인스턴스(C)가 플로우 인스턴스(A)로부터의 출력인 입력값을 가지는 경우가 그러하다. 이러한 순환 참조는 평가되지 않으며, 플로우 엔진(222)에 의하여 검출되어 순환 참조 내의 설정값이 에러 상태로 설정된다.

순환 참조는 "더티" 및 "방문" 마킹을 사용하여 검출될 수 있다. 전술된 단계(618)에서 플로우의 평가가 중지될 때, 플로우는 "방문"으로 마킹되지만, 또한 "더티"로 마킹되며, 또 다른 플로우의 평가가 시작된다. 이러한 다른 플로우의 평가도 중지될 수 있다. 만일 이러한 플로우 평가의 중지 중에, 이전에 "방문"으로 마킹되었지만 여전히 "더티"인 플로우가 평가되면, 순환 참조에 직면한 것이다. 즉, 하나 이상의 플로우의 평가가 중지되고, 그 중지 중에 이미 "방문" 및 "더티"로 마킹된 또 다른 플로우가 평가를 위하여 선택되면, 평가를 위하여 선택된 그 다른 플로우가 이전에 중지되었으므로 순환 참조에 직면한 것이다.

대안적으로, 순환 참조는 다양한 다른 방식으로 검출될 수 있다. 예를 들어, 전술된 바와 같이 단계(608)에서 값 종속성을 식별하는 종속 그래프가 생성되고, 이러한 종속 그래프가 순환 참조를 식별하는 데에 사용될 수 있다.

순환 참조가 검출될 때, 그 순환 참조의 일부인 모든 플로우가 에러(예를 들어, 순환 플로우 에러)로 마킹된다. 순환 참조가 검출될 때 평가되고 있는 플로우와, 순환 참조가 검출될 때 평가되고 있는 플로우로부터 입력을 수신하는 다른 모든 플로우와, 이러한 플로우들 중 하나로부터 입력을 수신하는 다른 모든 플로우 등은 순환 참조의 일부이다. 순환 참조의 일부인 모든 플로우의 평가는 중단된다. 선택적으로, 남은 플로우의 평가가 계속될 수 있도록 이러한 플로우가 "방문" 및 "더티하지 않음"으로 마킹될 수 있다.

플로우가 결정적(deterministic) 또는 비결정적(nondeterministic)일 수 있다는 점을 주의해야 한다. 결정적 플로우는 특정 입력값의 세트와 함께 호출될 때 언제나 동일한 값을 출력한다. 예를 들어, 플로우가 두 입력값의 합을 출력할 수 있다. 이러한 플로우는 특정 입력값의 세트가 주어졌을 때 언제나 동일한 값을 출력하므로 결정적이다. 그러나, 비결정적 플로우는 특정 입력 세트의 값과 함께 호출될 때마다 상이한 값을 출력할 수 있다. 예를 들어, 플로우가 입력 값에 기초하여 난수를 생성할 수 있다. 이러한 플로우는 동일한 입력값과 함께 호출될 때마다 상이한 난수를 생성하므로 비결정적이다. 입력값을 갖지 않는 플로우는 (언제나 동일한 값을 출력하여) 결정적이거나 (호출될 때마다 상이한 값을 출력하여) 비결정적일 수 있다.

일부 실시예에서, 설정값은 에러 상태를 가질 수 있다. 에러 상태에서, 설정값은 에러 정보(예를 들어, 에러 코드 또는 에러 기술)를 보유할 수 있다. 만일 설정값이 에러 정보를 보유하지 않으면, 에러 정보는 다른 방식으로(예를 들어, 설정을 에러 상태로 놓는 이벤트에 의하여) 보고될 수 있을 것이다. 설정값은 다양한 방법으로 에러 상태로 설정될 수 있다. 예를 들어, 플로우를 실행하는 동안 에러가 발생할 때 플로우 엔진(222)은 플로우의 출력값을 에러 상태로 설정할 것이다(예를 들어, 플로우가 에러를 리턴했거나 플로우 엔진이 순환 참조를 검출할 때 또는 플로우가 입력에 대한 문제로 인하여 실행될 수 없을 때와 같이 플로우 엔진이 플로우를 실행시킬 수 없었기 때문에).

에러 상태는 플로우를 통하여 전파되어 에러 상태의 입력값을 갖는 어떤 플로우도 플로우 엔진으로 하여금 에러 상태를 출력으로 전달하도록 할 것이다. 결국, 이러한 에러 상태가 플로우 엔진(222)에 의하여 개발 컴포넌트(202)로 (예를 들어, 도 2의 결과 226으로서) 리턴될 수 있을 것이다. 대안적으로, 플로우를 통하여 에러 상태의 전파를 리턴하는 대신, 원래의 에러를 야기하는 이벤트가 플로우 엔진(222)에 의하여 개발 컴포넌트(202)로 (예를 들어, 도 2의 결과 226으로서) 리턴될 수 있을 것이다.

추가적으로, 일부 실시예에서 플로우 입력 및/또는 출력이 현재 존재하지 않는 인스턴스를 참조할 수 있다(예를 들어, 입력 또는 출력이 생성되지 않은 멤버를 참조할 수 있다). 플로우 입력이 현재 존재하지 않는 인스턴스를 참조할 때, 입력은 설정되지 않은 것으로 간주되며 만일 디폴트가 그 플로우에 대하여 정의되었으면 디폴트로 복귀한다(예를 들어, 할당된 값으로 복귀한다). 만일 플로우에 대하여 이러한 할당이 없으면, 그 멤버에 대한 데이터 유형에 대한 디폴트값으로 복귀한다.

플로우 출력이 현재 존재하지 않는 인스턴스를 참조할 때, 출력값은 사용되지 않는다. 만일 플로우의 출력이 아무것도 존재하지 않으면, 플로우는 어떤 값도 설정하지 않을 것이므로 실행될 필요가 없다. 그러나, 설령 모든 입력이 현재 존재하지 않아도, 적어도 하나의 출력이 존재하면, 플로우는 실행될 것이다.

또한, 설계 시간 검증(design time validation)이 상속된 설정 패턴(inherited settings patterns)을 허용하는 것이 바람직하다. 상속된 설정은, 인스턴스 스페이스가 오브젝트의 계층을 갖고, 설정값이 오브젝트에 적용될 수 있으며, 설정값이 계층에서 그 아래의 모든 오브젝트에 대한 설정을 위한 값으로 귀결되는 상황을 가리킨다. 실제로, 그 오브젝트 아래의 오브젝트들이 디폴트 값을 오버라이딩하기 위하여 명시적으로 적용되는 그들 자신의 값을 갖지 않으면, 이는 그 오브젝트 아래의 오브젝트들에 대하여 디폴트값을 생성한다. 이들은 오브젝트에 대한 적용 설정(applied settings; 특정 오브젝트에 적용되는 설정) 및 오브젝트에 대한 결과 설정(resulting settings; 부모 오브젝트로부터 상속된 설정과 결합된 적용 설정의 결과)으로 불리울 수 있다.

이러한 상속된 설정은 상이한 방식으로 수용될 수 있다. 일부 실시예에서, 이러한 상속된 설정은 SDM 파일(204)의 생성 중에 수용될 수 있다. SDM 파일(204)의 설계자는 이러한 상속된 설정이 존재하는 상황을 인식하고, SDM 파일(204)의 설계에 이를 반영한다. 예를 들어, SDM 파일(204)의 설계자는 적용 설정 및 결과 설정 양쪽 모두를 선언하지만, 결과 설정에 대해서만 제한할 수 있다.

대안적인 실시예에서, 각 설정은 적용 설정값 및 결과 설정값 모두를 갖는다. 따라서, 인스턴스 내의 각 설정은 실제로 하나가 아닌 두 개의 값을 가질 것이다. 적용 설정값은 초기화 또는 값의 명시적인 설정에 의하여 설정되는 값이다. 결과 설정값은 플로우에 의하여 설정된다. 디폴트로, 어떤 플로우라도 그것을 설정한다면, 설정에 대한 참조는 결과 설정값을 얻을 것이고, 어떤 플로우도 그것을 설정하지 않는다면, 설정에 대한 참조는 적용 설정값을 얻을 것이다. 한편, 플로우 출력에 대한 참조는 디폴트로 결과값을 참조할 것이다. 추가적으로, 모든 참조는 두 개의 설정값 중 하나를 명시적으로 참조하기 위하여 값 유형 자격 부여자(value type qualifier)를 선택적으로 추가할 수 있다.

전형적으로, 플로우의 출력은 그 플로우가 평가될 때마다 교체된다. 즉, 플로우의 실행은 그 플로우의 임의의 이전 출력을 오버라이팅하는 것으로 귀결된다. 그러나, 각 설정이 적용 설정값 및 결과 설정값의 양쪽 모두를 갖는 실시예에서, 플로우는 그 입력의 하나로서 적용 설정값을 취하도록 쓰여질 수 있다. 적절히 구축된 플로우 함수가 주여졌을 때, 이는 플로우의 출력이 그 플로우의 다른 입력에 부가되는 적용 설정이 되도록 할 수 있다. 따라서, 이러한 실시예에서, 실제로 플로우 출력에 부가되는 새로운 입력을 갖는 것이 가능하다.

제한 조건 엔진(Constraint Engine)

시뮬레이터(218)는 SDM 문서(204)에 의하여 정의된 시스템에 대한 제한 조건을 평가하기 위하여 제한 조건 엔진(224)을 호출한다. 제한 조건 엔진(224)에 의하여 수행되는 평가는 (환경이 SDM 문서 204에 의하여 진술된 제한 조건을 만족함을 검증하기 위하여) 환경에 대하여 SDM 문서(204)에 정의된 제한 조건을 평가하고, (SDM 문서 204에서 정의된 시스템이 환경에 의하여 진술된 제한 조건을 만족함을 검증하기 위하여) SDM 문서(204)에 정의된 시스템에 대하여 (예를 들어, LIM 문서 206에서) 환경에 의하여 정의된 제한 조건을 평가한다.

제한 조건 엔진(224)은 인스턴스 스페이스를 "걸으며(walk)", 각 제한 조건 멤버를 찾아 평가한다. 제한 조건 엔진(224)은, LIM 문서(206)에 의하여 정의된 제한 조건 멤버뿐만 아니라, SDM 문서(204)에 의하여 정의된 제한 조건 멤버도 평가할 수 있다. 전형적으로, 플로우 엔진(222)이 플로우의 평가를 마친 후에, 시뮬레이터(218)가 제한 조건 엔진(224)을 호출하며, 따라서 제한 조건 검사는 확장 및 플로우 평가 프로세스로부터 귀결되는 인스턴스 스페이스에 기초하여 수행된다. 그러나, 대안적인 실시예에서, 플로우 엔진(222)가 플로우의 평가를 마치기에 앞서 제한 조건 엔진(224)이 호출될 수 있다.

제한 조건은 상이한 형태를 가질 수 있으며, 일부 실시예에서 제한 조건은 설정 제한 조건, 관계 제한 조건, 및 오브젝트 제한 조건을 포함한다. 설정 제한 조건은 오브젝트에 대한 설정을 제한하며 평가를 수행하기 위한 관리자 또는 코드에 의하여 뒷받침된다. 관계 제한 조건은 오브젝트가 참여할 수 있는 관계를 제한한다. 오브젝트 제한 조건은 관계 내의 오브젝트를 제한한다.

전형적으로, 제한 조건 정의는 제한 조건이 적용되는 목적 정의를 식별하며, 또한 그 제한 조건이 무엇인지를 정의한다. 설정 제한 조건의 경우, 목적이 제한 조건을 만족하는지를 평가하기 위하여 실행될 수 있는 명령 또는 코드 세트(또는 대안적으로 하드웨어 모듈)가 (예를 들어, 제한 조건 정의에 의하여 식별되는) 제한 조건과 연관된다. 일부 실시예에서, 제한 조건 정의는, 플로우 평가와 관련하여 전술된 관리자 정의와 유사하며 명령 또는 코드 세트를 지시하는 관리자 정의와 연관된다.

도 7a-7e는 제한 조건을 평가하기 위한 예시적인 프로세스(700)를 도시하는 흐름도이다. 프로세스(700)는 도 2의 제한 조건 엔진(224)에 의하여 구현되며, 소프트웨어, 펌웨어, 하드웨어, 또는 이들의 조합으로 수행될 수 있다.

초기에, 인스턴스 스페이스 내의 모든 제한 조건이 식별된다(단계 702). 이러한 단계(702)에서의 식별은 설정 제한 조건, 관계 제한 조건, 및 오브젝트 제한 조건을 식별하는 단계를 포함한다. 단계(702)에서의 식별은, (예를 들어, LIM 문서 206에서) 환경에 의하여 정의된 제한 조건뿐만 아니라 (예를 들어, SDM 문서 204에서) 시스템에 의하여 정의된 제한 조건을 식별하는 단계도 포함할 수 있다.

이어서, 식별된 제한 조건 중 하나가 선택된다(단계 704). 제한 조건은 상이한 다양한 방식 중 임의의 것에 의하여 선택될 수 있다. 예를 들어, 제한 조건이 단계(702)에서 식별된 순서로 선택될 수 있고, 상이한 유형의 제한 조건이 다른 유형보다 먼저 선택될 수도 있으며(예를 들어, 설정 제한 조건이 관계 제한 조건보다 먼저 선택될 수 있다), 제한 조건이 무작위순으로 선택될 수도 있다. 이어서, 선택된 제한 조건은 그 제한 조건이 관계 제한 조건, 설정 제한 조건, 또는 오브젝트 제한 조건인지에 기초하여 평가된다.

제한 조건이 설정 제한 조건이면, 제한 조건의 목적 인스턴스로부터의 적절한 값이 획득된다(단계 706). 제한 조건은 평가될 목적 인스턴스를 식별한다(예를 들어, 이름에 의하여, 제한 조건의 목적인 오브젝트를 식별한다). 제한 조건은 또한 목적 인스턴스의 어떤 설정값이 평가될지를 식별하며, 식별된 설정값은 목적 인스턴스로부터 획득된다. 이어서, 제한 조건에 대하여 제한 조건 함수를 평가하기 위하여 실행되는 명령 또는 코드 세트가 식별된다(단계 708). 대안적으로, 명령 또는 코드 세트가 실행되는 대신, 제한 조건 함수가 하드웨어로 구현될 수 있다. 이어서, 단계(706)에서 획득된 값이 제한 조건을 만족하는지를 판정하기 위하여 명령 또는 코드 세트가 실행되거나, 또는 하드웨어가 판정을 행할 수 있다(단계 710). 예를 들어, 명령 세트는 획득된 값을 제한 조건 내의 값과 비교하고 만일 획득된 값의 하나 이상이 제한 조건의 설정값의 하나 이상과 동일하면(일치하면) 제한 조건이 만족되는 것으로 판정할 수 있다.

이어서, 제한 조건 함수의 결과가 리턴된다(단계 712). 결과는 결과(226)의 일부로서 도 2의 개발 컴포넌트(202)로 리턴된다. 제한 조건은, 단계(712)에서 결과의 일부로서 리턴될 수 있는 제한 조건을 기술하는 이름 또는 다른 정보를 선택적으로 포함할 수 있으며, 이는 임의의 에러를 기술하는 추가적인 정보가 개발 컴포넌트(202)에서 설계자에게 제공될 수 있도록 한다.

이어서, 아직 선택되지 않은 추가적인 인스턴스 스페이스 내의 제한 조건이 존재하는지에 대한 검사가 행해진다(단계 714). 만일 모든 제한 조건이 선택 및 평가되었으면, 제한 조건 검사 프로세스는 완료된다(단계 716). 그러나, 만일 하나 이상의 제한 조건이 선택되지 않았으면, 식별된 제한 조건 중 또 다른 하나를 선택하기 위하여 프로세스(700)가 단계(704)로 복귀한다.

단계(704)로 돌아가, 만일 선택된 제한 조건이 오브젝트 제한 조건이면, 제한 조건의 목적 인스턴스에 대한 1차 역할(primary role) 및 1차 오브젝트 정의(primary object definition)가 식별된다(도 7b의 단계 718). 오브젝트 제한 조건에 있어서, 제한 조건의 목적 인스턴스는 관계 인스턴스이다. 목적 인스턴스 의 1차 오브젝트 정의는 선택된 제한 조건이 목적으로 하는 오브젝트의 이름을 참조한다. 목적 인스턴스의 1차 역할은 1차 오브젝트 정의에 의하여 식별된 정의와 일치해야 하는 관계 역할(relationship role)을 식별한다. 이어서, 제한 조건에 의하여 목적으로 되는 2차 역할(secondary role) 및 2차 오브젝트 정의(secondary object definition)가 있는지에 대한 검사가 행해진다(단계 720). 일부 실시예에서, 제한 조건은 다수의 오브젝트 및/또는 역할을 목적으로 할 수 있으며, 제한 조건에 의하여 목적으로 되는 2차 역할 및/또는 오브젝트 정의를 식별하기 위하여 2차 역할 및 2차 오브젝트 정의가 사용될 수 있다.

만일 제한 조건에 의하여 목적으로 되는 2차 역할 및 2차 오브젝트 정의가 있으면, 제한 조건의 1차 및 2차 역할과 1차 및 2차 오브젝트 정의 모두가 목적 인스턴스와 일치하는지에 대한 검사가 행해진다(단계 722). 만일 하나 이상의 역할 또는 하나 이상의 오브젝트 정의가 목적 인스턴스와 일치하지 않으면, 일치 횟수 변수(match count variable)가 0으로 설정되고(단계 724), 프로세스(700)는 도 7c의 단계(726)로 계속되며, 이는 아래에서 상술된다.

그러나, 만일 제한 조건의 1차 및 2차 역할과 1차 및 2차 오브젝트 정의가 목적 인스턴스와 일치하면, 1차 오브젝트 인스턴스에 대한 모든 내포된 제한 조건이 평가된다(단계 728). 내포된 제한 조건은 그것의 자식 뿐만 아니라, 제한 조건 정의의 임의의 자식 인스턴스도 참조한다. 내포된 제한 조건은 오브젝트 제한 조건, 관계 제한 조건, 및/또는 설정 제한 조건일 수 있다. 만일 임의의 내포된 제한 조건이 이전에 평가되고 그 결과가 기록되었으면, 그 결과는 단계(728)에서 사 용될 수 있다. 그러나, 아직 평가되지 않은 임의의 내포된 제한 조건에 대하여, 도 7a의 단계(704)에서 프로세스(700)를 호출하고 내포된 제한 조건의 각각을 선택된 제한 조건으로서 사용함으로써 제한 조건이 평가된다.

일단 모든 내포된 제한 조건이 평가되면, 모든 내포된 제한 조건이 참(true)으로 평가되는지에 대한 검사가 행해진다(단계 730). 만일 내포된 제한 조건 중 하나 이상이 참으로 평가되지 않으면, 일치 횟수 변수는 0으로 설정된다(단계 724). 그러나, 모든 내포된 제한 조건이 참으로 평가되면, 일치 횟수 변수는 1로 설정되고(단계 732), 프로세스(700)는 도 7c의 단계(726)로 계속되며, 이는 아래에서 상술된다.

대안적으로, 단계(730)는 모든 내포된 제한 조건이 참으로 평가되는지에 대한 테스트이므로, 일부 환경에서는 모든 내포된 제한 조건이 평가될 필요는 없다. 하나의 내포된 제한 조건이 참이 아닌 것으로 평가되자마자 내포된 제한 조건의 평가가 중단될 수 있으며 프로세스(700)는 단계(730)로 계속된다. 예를 들어, 만일 세 개의 내포된 제한 조건이 있고 두 번째 내포된 제한 조건이 거짓으로 평가되면, 세 번째 내포된 제한 조건이 참으로 평가되는지와 무관하게 단계(730)에서의 결과는 동일(단계 724로의 진행)하다.

단계(720)로 돌아가, 만일 제한 조건에 의하여 목적으로 되는 2차 역할 및 2차 오브젝트 정의가 없으면, 제한 조건의 1차 역할 및 1차 오브젝트 정의가 목적 인스턴스와 일치하는지에 대한 검사가 행해진다(단계 734). 단계(734)는 단계(722)와 유사하지만, 1차 역할 및 1차 오브젝트 정의에만 기초하여 수행된다. 단계(734)에서는 2차 역할 및 2차 오브젝트 정의가 없으므로 1차 역할 및 1차 오브젝트 정의만이 고려된다.

만일 1차 역할 또는 1차 오브젝트 정의가 목적 인스턴스와 일치하지 않으면, 일치 횟수 변수는 0으로 설정되고(단계 736), 프로세스(700)는 도 7c의 단계(726)로 계속되며, 이는 아래에서 상술된다. 그러나, 만일 제한 조건의 1차 역할 및 1차 오브젝트 정의가 오브젝트 인스턴스와 일치하면, 프로세스(700)는 단계(728)로 계속되며, 여기서 1차 오브젝트 인스턴스에 대한 모든 내포된 제한 조건이 평가된다.

도 7c의 단계(726)로 돌아가, 일치 횟수의 값이 적어도 최소값이며 최대값을 초과하지 않는지에 대한 검사가 행해진다(단계 726). 이러한 최소 및 최대값은 제한 조건에 의하여 식별되며, 임의의 값일 수 있다. 만일 일치 횟수가 적어도 최소값이지만 최대값을 초과하지 않으면, 이 제한 조건에 대하여 참값이 리턴된다(단계 738). 참인 리턴값은 다른 인스턴스를 평가하는 프로세스로 리턴될 수도 있다. 예를 들어, 도 7b의 단계(728)에서 내포된 제한 조건이 평가될 때, 만일 단계(738)에서 그 내포된 제한 조건이 참으로 평가된다고 판정되면, 단계(730)에서 그 결정을 행하기 위하여 부모 노드를 평가하는 프로세스로 그 참값이 리턴될 수 있다.

참인 리턴값은, 선택적으로 결과(226)의 일부로서 도 2의 개발 컴포넌트(202)로 리턴될 수 있다. 추가적으로, 만족된(참으로 평가된) 제한 조건의 이름 또는 다른 식별 정보가 선택적으로 개발 컴포넌트(202)로 리턴될 수 있다.

그러나, 만일 일치 횟수가 적어도 최소값이 아니거나 최대값을 초과하면, 이 제한 조건에 대하여 에러 메시지가 생성되어야 하는지에 대한 검사가 행해진다(단계 740). 제한 조건은, 그 제한 조건에 대한 에러 메시지가 리턴되어야 하는지를 지시하는 파라미터 또는 설정을 갖는다. 이러한 파라미터 또는 설정은, 예를 들어 제한 조건의 설계자 또는 개발자에 의하여 설정될 수 있다. 단계(740)의 검사는, 제한 조건에 대한 이러한 파라미터 또는 설정이 에러 메시지가 생성되어야 하는지를 지시하는지 여부를 검사함으로써 수행된다.

만일 제한 조건에 대하여 에러 메시지가 생성되어야 하면, 에러 메시지가 생성된다(단계 742). 에러 메시지는, 사용자(예를 들어, 설계자 또는 개발자)가 에러를 야기하는 제한 조건의 성질을 식별하는 것을 돕는 이름 또는 다른 식별 정보를 선택적으로 포함할 수 있다. 이어서, 이 제한 조건에 대하여 거짓값이 리턴된다(단계 744). 거짓값 및/또는 단계(742)에서 생성된 에러 메시지는, 결과(226)의 일부로서 도 2의 개발 컴포넌트(202)로 리턴될 수 있다. 단계(738)에서의 참인 리턴값과 유사하게, 거짓인 리턴값 및/또는 에러 메시지는, 다른 인스턴스를 평가하는 프로세스로 리턴될 수도 있다.

단계(738)에서 참값이 리턴되거나 단계(744)에서 거짓값이 리턴된 후, 아직 선택되지 않은 추가적인 제한 조건이 있는지를 검사하기 위하여 프로세스(700)가 도 7a의 단계(714)로 복귀한다.

도 7a의 단계(704)로 돌아가, 만일 선택된 제한 조건이 관계 제한 조건이면, 일치 횟수 변수가 초기화된다(도 7d의 단계 746). 일치 횟수 변수는, 예를 들어 일치 횟수 변수를 0으로 설정함으로써 초기화될 수 있다. 이어서, 제한 조건의 목적 오브젝트 인스턴스가 참여하는 관계 인스턴스가 식별되고(단계 748), 식별된 관계 인스턴스 중 하나가 식별된다(단계 750).

이어서, 제한 조건의 관계 정의 및 지시가 선택된 관계 인스턴스와 일치하는지에 대한 검사가 행해진다(단계 752). 관계 정의(relationship definition)는 관계의 유형(예를 들어, 호스팅, 위임, 통신 등)을 가리키며, 지시(direction)는 관계의 역할 또는 지시(예를 들어, 호스팅 관계에서 제한 조건이 호스트 또는 게스트를 목적으로 하는지 여부)를 가리킨다. 만일 제한 조건의 관계 정의 및 지시가 선택된 관계 인스턴스의 관계 정의 및 지시와 동일하면, 제한 조건의 관계 정의 및 지시는 식별된 관계 인스턴스와 일치한다.

만일 제한 조건의 관계 정의 및 지시가 선택된 관계 인스턴스와 일치하지 않으면, 아직 선택되지 않은 단계(748)에서 식별된 추가적인 관계가 있는지에 대한 검사가 행해진다(단계 754). 만일 이러한 추가적인 관계가 하나 이상 있으면, 프로세스(700)는 단계(750)로 복귀하며, 여기서 아직 선택되지 않은 추가적인 관계 중 하나가 선택된다. 그러나, 만일 이러한 추가적인 식별된 관계가 없으면, 프로세스(700)는 도 7e의 단계(756)로 진행하며, 이는 아래에서 상술된다.

단계(752)로 돌아가, 만일 제한 조건의 관계 정의 및 지시가 선택된 관계 인스턴스와 일치하지 않으면, 제한 조건 내에 목적 오브젝트 정의가 있는지에 대한 검사가 행해진다(단계 758). 제한 조건에서 목적 오브젝트 정의는 선택적이며, 평가되고 있는 관계 인스턴스의 다른 편에 있는 오브젝트 인스턴스를 참조한다. 예를 들어, 만일 관계 인스턴스가 호스팅 관계이고 목적 오브젝트 인스턴스가 호스트 이면, 호스팅 관계의 다른 편에 있는 오브젝트 인스턴스는 게스트 인스턴스일 것이다. 만일 제한 조건 내에 목적 오브젝트 정의가 있으면, 제한 조건 내의 목적 오브젝트 정의가 관계 인스턴스의 다른 편의 인스턴스와 일치하는지에 대한 검사가 행해진다(단계 760). 만일 제한 조건 내의 목적 오브젝트 정의가 관계 인스턴스의 다른 편의 인스턴스와 동일하면, 제한 조건 내의 목적 오브젝트 정의는 관계 인스턴스의 다른 편의 인스턴스와 일치한다.

만일 제한 조건 내의 목적 오브젝트 정의가 관계 인스턴스의 다른 편의 인스턴스와 일치하지 않으면, 아직 선택되지 않은 추가적인 식별된 관계가 있는지를 검사하기 위하여 프로세스(700)가 단계(754)로 진행한다.

그러나, 만일 제한 조건 내의 목적 오브젝트 정의가 관계 인스턴스의 다른 편의 인스턴스와 일치하거나, 또는 만일 제한 조건 내에 목적 오브젝트 정의가 없으면, 프로세스(700)는 그 관계 인스턴스에 대한 모든 내포된 제한 조건을 평가하기 위하여 진행된다(도 7e의 단계 762). 이어서, 모든 내포된 제한 조건이 참으로 평가되는지 여부에 기초하여 프로세스(700)가 진행된다(단계 764). 단계(762) 및 단계(764)의 평가 및 검사는 도 7b의 단계(728) 및 단계(730)의 평가 및 검사와 유사하다.

만일 모든 내포된 제한 조건이 참으로 평가되지 않으면, 아직 선택되지 않은 추가적인 식별된 관계가 있는지를 검사하기 위하여 프로세스(700)가 도 7d의 단계(754)로 복귀한다. 그러나, 만일 모든 내포된 제한 조건이 참으로 평가되면, 일치 횟수 변수가 증가된다(단계 766). 일치 횟수 변수는 상이한 양만큼 증가될 수 있으며, 예를 들어 1만큼 증가될 수 있다. 이어서, 아직 선택되지 않은 추가적인 식별된 관계가 있는지를 검사하기 위하여 프로세스(700)가 도 7d의 단계(754)로 복귀한다.

이어서, 도 7c의 단계(726)와 유사하게, 일치 횟수의 값이 적어도 최소값이고 최대값을 초과하지 않는지에 대한 검사가 행해진다(단계 756). 도 7c의 단계(738)와 유사하게, 만일 일치 횟수의 값이 적어도 최소값이고 최대값을 초과하지 않으면, 참값이 리턴된다(단계 768). 그러나, 도 7c의 단계(740)와 유사하게, 만일 일치 횟수의 값이 적어도 최소값이 아니거나 최대값을 초과하면, 제한 조건에 대하여 에러를 생성할 것인지에 대한 검사가 행해진다(단계 770). 도 7c의 단계(742)와 유사하게, 만일 에러가 생성될 것이면, 에러 메시지가 생성된다(단계 772). 도 7c의 단계(744)와 유사하게, 에러 메시지가 생성될 때, 또는 만일 에러 메시지가 생성되지 않을 것이면, 거짓값이 리턴된다(단계 774).

추가적으로, 제한 조건의 그룹에 대해서도 제한 조건 검사 프로세스가 수행될 수 있다는 점을 주의해야 한다. 제한 조건의 그룹을 평가하기 위해서, 각 제한 조건은 프로세스(700)를 사용하여 개별적으로 평가되고, 그룹의 결과는 개별적인 제한 조건 평가의 결과에 의존한다. 일부 실시예에서, 만일 그룹 내의 적어도 하나의 제한 조건이 참으로 평가되면, 그 그룹은 참으로 평가된다.

프로세스(700)에서 개발 컴포넌트(202)로 에러 메시지뿐만 아니라 성공적인 제한 조건 검증(예를 들어, 참값) 또는 성공적이지 않은 제한 조건 검증(예를 들어, 거짓값)을 지시하는 값을 리턴함으로써, SDM 문서(204)에서 기술된 시스템의 설계 시간 검증의 결과가 개발 컴포넌트(202)로 리턴된다. 이러한 지시 및/또는 에러 메시지는 개발 컴포넌트(202)를 사용하는 설계자에게도 제공될 수 있으며, 이는 설계되고 있는 (또한 SDM 문서 204에 기술되어 있는) 시스템이 검증되었는지, 또는 잠재적으로 문제가 있는지 여부를 설계자가 통지받을 수 있도록 한다. 에러 메시지를 리턴함으로써, 설계자는 잠재적인 문제가 무엇이고 이를 어떻게 해결할지에 대하여 더욱 원활하게 통지받을 수 있다. 이러한 피드백은 설계 프로세스 중에 설계자에게 주어질 수 있으며, 설계자가 설계된 시스템에 문제가 있다는 것을 발견하기 전에 시스템을 데이터 센터에 배치하기를 시도하도록 요구하지 않는다.

예시적인 에러 구현

본 섹션은 도 2의 검증 컴포넌트(208)에 의하여 에러 및 경고가 보고될 수 있는 방법을 도시한다. 에러 및 경고는, 본 섹션에서 논의되는 예시적인 XML 포맷과 같은 다양한 포맷 중 임의의 것에 의할 수 있다. 만일 검증 컴포넌트(208)가 CLR(Common Language Runtime)을 통하여 사용되면, 본 섹션에서 논의되는 XML 포맷과 등가의 정보를 가진 클래스가 리턴될 수 있다.

본 섹션은 한 클래스의 에러에 공통일 값들을 식별한다. 이는 추가적인 값들을 배제하지 않는다.

유형 공간(type space)의 검증 중에 발생하는 에러(파싱 및 분해 에러)는 컴파일된 SDM 문서가 기록되는 것을 막을 것이다. 그러나, 인스턴스 스페이스 검증 중에 발생하는 에러(플로우 및 제한 조건 에러)는 컴파일된 SDM 문서가 기록되는 것을 막지 않을 것이다.

기본 에러 포맷

기본 에러는 모든 에러에 공통인 에러 정보를 포함한다. 기본 에러 포맷을 위한 예시적인 XML 포맷은 아래와 같다.

기본 에러 포맷의 속성 또는 컴포넌트는 아래의 표에서 설명된다.

파싱 에러(parse error)

파싱 에러는 SDM 문서의 로딩을 시도하는 중의 실패(failure)로부터 발생할 것이다. 이 에러는 행 및 컬럼 번호를 포함할 것이다. 파싱 에러 포맷을 위한 예시적인 XML 포맷은 아래와 같다.

파싱 에러의 속성 또는 컴포넌트는 아래의 표에서 설명된다.

분해 에러(resolution error)

분해 에러는 파일 내에서 유형(types)을 로딩 및 분해하는 중의 실패로부터 발생할 것이다. 이러한 클래스의 에러는 임포트(imports) 분해 실패와, 유형, 멤버 및 패스(path) 분해 실패를 포함한다. 이 단계에서, 완전히 파싱된 오브젝트 모델이 있으므로, 파일로부터의 행 및 컬럼 번호 대신 오브젝트 모델에 대하여 에러를 발생시키는 부분에 대한 참조가 행해질 수 있다. 분해 에러 포맷을 위한 예시적인 XML 포맷은 아래와 같다.

분해 에러 포맷의 속성 또는 컴포넌트는 아래의 표에서 설명된다.

플로우 에러(flow error)

플로우 에러는, 플로우가 실행되고 하나 이상의 입력 또는 출력에 대하여 에러를 리턴할 때 발생한다. 목적 설정 멤버(destination setting member)와 함께 현재의 입력 및 출력 세트를 포함하는 실패 발생의 전후 관계(context)와 플로우 멤버의 유형과 플로우 멤버가 식별된다. 플로우 에러 포맷을 위한 예시적인 XML 포맷은 아래와 같다.

플로우 에러 포맷의 속성 또는 컴포넌트는 아래의 표에서 설명된다.

플로우 입력 포맷의 설명용 예시 XML 포맷은 다음과 같다.

플로우 입력 포맷의 설명의 속성 또는 요소는 다음 테이블에서 설명된다.

플로우 출력 포맷의 설명용 예시 XML 포맷은 다음과 같다.

플로우 출력 포맷의 설명의 속성 또는 요소는 다음 표에 설명된다.

제한 조건 에러(constraint error)

제한 조건 에러는 설정 제한 조건이 평가되고 에러를 리턴할 때, 가드(guard)가 카디널리티 제한 조건(cardinality constraint)에 실패할 때, 또는 제한 조건 그룹의 적어도 하나의 멤버가 참(true)으로 평가되는데 실패할 경우 발생한다.

설정 제한이 실패할 경우, 제한 조건 타입, 제한 조건이 실행되는 컨텍스트 및 제한 조건용 입력 값의 세트에 따라, 제한 조건 멤버 선언이 리턴된다. 제한 조건은 또한 커스템 에러 id를 리턴할 수 있는데, 이것은 추가적 에러 정보를 찾기 위하여 사용될 수 있다. 이같은 제한 조건 에러 포맷용 예시 XML 포맷은 다음과 같다.

이같은 제한 조건 에러 포맷의 속성 또는 요소는 다음 표에 설명된다.

제한 조건 입력 포맷의 설명용 예시 XML 포맷은 다음과 같다.

플로우 입력 포맷의 설명의 속성 또는 요소는 다음 표에서 설명된다.

가드 또는 그룹이 실패할 때, 제한 조건 멤버는 멤버 컨텍스트 및 평가 컨텍스트를 따라 인식된다. 평가 컨텍스트가 내포된 제한 조건이 평가되는 타입 또는 관계를 인식할 때, 평가 컨텍스트는 내포된 제한 조건용 멤버 컨텍스트와 다르다. 이러한 제한 조건 에러 포맷을 위한 예시 XML 포맷은 다음과 같다.

이러한 제한 조건 에러 포맷의 속성 또는 요소는 다음 표에서 설명된다.

문서 패스

이것은 SDM 문서 내의 특정 SDM 요소에 대한 패스이다. 문서 패스 포맷에 대한 예시 XML 포맷은 다음과 같다.

상기 패스는 일반적으로 다음의 형태를 가진다.

관계 및 제한 조건용으로 잘 알려진 설정은 내포된 멤버로 취급된다.

포함 패스(Containment Path)

포함 패스는 특정 멤버에 대한 루트로부터 멤버 시퀀스를 인식한다. 패스는 에러를 일으킨 멤버가 도달될 때까지 그 멤버 등을 통하여 루트 시뮬레이션 컴포넌트로부터 멤버를 조종한다. 문서 패스 포맷용 예시 XML 포맷은 다음과 같다.

패스는 일반적으로 다음의 형식을 갖는다.

에러의 예

컴파일러는 사용자에 표시될 컴파일레이션으로부터 에러 및 경고를 리턴한다. SDM 문서의 컴파일레이션동안 잡힌 에러는 심각성의 레벨이 다를 수 있다. 대부분의 에러는 치명적이지만, 일부는 다른 에러를 일으키도록 하고, 일부는 무시할 만큼 안전한 것도 있다. 다음의 예시는 각각의 에러 레벨의 심각성에 대하여 상술한다.

에러 : 이 카테고리의 에러는 치명적이고, 다음을 내포한다.

. 출력 sdm 파일(.sdmDocument)은 컴파일레이션으로부터 생성될 수 없다.

. 에러는 컴파일러가 현 단계의 컴파일레이션을 완료하고 종료하도록 할 것이다. 예를 들어, 만약 XML 파스 에러가 발생한다면 문서는 로딩되지 않을 것이다. 만약 로드 에러가 발생한다면, 더이상의 로드 에러가 찾아질 수도 있지만, 플로우 및 제한 조건 체킹은 계속되지 않을 것이다.

경고 1(W1) : 경고는 SDM 문서가 컴파일되는 것을 금지하지 않는다. 경고 1에 대한 가이드 라인은 다음을 포함한다.

. 컴파일레이션의 다음 단계에서 에러를 유발할 수도 있음. 예를 들어, 만약 참조 파일이 찾아지지 않는다면, 임의의 타입이 상기 참조로부터 사용될 경우 목적 SDM 파일의 로드 동안 에러가 발생할 것이다.

. 인스턴스 스페이스 시뮬레이션 동안의 에러.

경고 2(W2) : 경고 2는 가장 낮은 심각도의 에러이다. 예를 들어, 추가적 속성이 XML 파일에서 발견된다. 경고 2를 위한 가이드 라인은 아래와 같다.

. 경고 2는 무시할 만큼 안전하다.

. SDM을 깨끗이 하기 위하여 수정하도록 추천됨.

경고 3(W3) : 경고 3은 정보 메시지이다.

. 경고 3은 정보적이다.

. 디폴트로, 이러한 경고는 보고되지 않는다.

다음 표는 도 2의 유효화 컴포넌트(208)에 의하여 보고될 수 있는 에러의 예를 열거한다. 분리된 표는 일반 컴파일러 에러, 문서 로드 에러, 정의 스페이스 검증 에러, 플로우 에러 및 제한 조건 에러의 예를 도시하기 위하여 사용된다. 에러 및 그 레벨의 설명은 다음 표에 포함된다. 각각의 에러용 포맷이 또한 인식된다(예를 들어 에러(베이스 에러) 포맷, 파스 포맷, 레졸루션 포맷, 플로우 포맷 및 제한 조건 포맷).

일반 컴파일러 에러

문서 로드 에러

정의 스페이스 검증 에러

플로우 에러

예시 SDM 구현

다음은 SDM의 예시적 구현이다. 이 예시 SDM 구현은 정의 섹션(섹션 1), 구조적 개관 섹션(섹션 2), 및 상세 구현 섹션(섹션 3)을 포함한다. 다양한 특정 값 및 요구사항이 이 예시적 구현에서 설명되지만, 모든 구현이 이 특정 값 및 요구사 항에 제한되는 것이 아니라는 것을 이해할 것이다.

1. 정의

용어	정의
변화 요청	모델링된 시스템에 변화의 세트를 설명하는 선언적 문서
오브젝트 정의	오브젝트 정의는 모델링된 시스템의 요소 설정을 캡쳐링함
관계 정의	모델링된 시스템 요소 사이에서 상호 작용을 설명하기 위하여 사용되는 정의
시스템 정의 모델(SDM) 문서	오브젝트, 관계, 설정, 플로우 및 제한 조건용 정의를 포함하는 xml 문서
소프트웨어 배치 유닛(SDU)	sdm 문서의 세트의 조합 및 상기 타입들을 SDM 관리 시스템에 배치하기 위하여 필요한 관련 바이너리 정보(파일)
SDM 인스턴스 스페이스	모델링된 시스템을 표현하는 견고한 타입 및 관계 인스턴스의 세트

2. 구조적 개관

시스템 정의 모델(SDM)은 모델링된 시스템이라 부르는 연결된 시스템의 요소 사이에서의 설정 및 상호 작용을 설명하는 것을 지원한다.

SDM은 오브젝트 관련 모델에 기초한다. 모델링된 시스템에 존재하는 요소를 설명하기 위하여 오브젝트를 사용하고, 그들 사이의 링크를 인식하기 위하여 관계를 사용한다. 또한 SDM은 SDM에 중요한 의미를 캡쳐링하기 위하여 오브젝트 및 관계를 정련한다. 특히, 오브젝트를 시스템, 종단점(endpoint) 및 리소스로 나누고, 관계를 통신, 포함, 호스팅, 위임 및 참조로 나눈다.

추상화 오브젝트 정의를 사용하여 넓은 범위의 애플리케이션을 지원하는 툴을 허용하고 디자인 시간에서의 타입 검사용 베이시스를 제공하는 시스템 부분의 일반 카테고리화를 제공한다. 추상 정의의 집합을 예상하여 시스템 디자인용 포괄 베이시스를 제공하고 그들이 긴 시간에 걸쳐 천천히 변화할 것을 예상한다.

그런 후, 실제 애플리케이션이나 데이터 센터 디자인의 부분을 나타내는 견고한 정의(concrete definition)를 정의하기 위한 베이시스(basis)로서 추상화 정의를 사용한다. 추상화 정의를 취하고, 그 특성을 위한 견고한 타입의 멤버 및 설정 값을 정의하는 구현을 제공한다. 그런 후 이 정의의 집합으로부터 시스템을 구축한다.

제한 조건은 인스턴스가 참가하는 관계의 허용된 세트에 대한 규제를 모델링하기 위하여 사용된다. 제한 조건을 사용하여 관계에 관련된 오브젝트의 설정에 의존하는 잘 정련된 요구 사항을 캡쳐링한다. 예를 들어, 제한 조건은 통신 프로토콜의 각각의 종단점에서의 참가자가 호환 가능 보안 설정을 사용하고 있다는 것을 유효화하기 위하여 사용될 수 있다.

목적 시스템 상의 변화에 영향을 주기 위하여, 변화 요청을 호출하는 요구된 변화의 선언적 설명이 사용될 수 있다. SDM은 SDM 실행 모델의 일부로서 변화 요청을 확장, 유효화 및 실행하기 위하여 사용되는 프로세스를 정의한다.

인스턴스 스페이스는 관리된 애플리케이션의 현재 상태 및 원하는 상태 모두를 캡쳐링한다. 인스턴스 스페이스에서의 변화를 추적하여 그것들을 변화를 초기화하는 변화 요청과 연관시키는 것이 가능하다.

매니저는 런타임에 커스터마이징된 동작을 제공하고 런타임 및 모델링된 시스템 사이의 상호 작용을 지원하기 위하여 사용된다.

2.1 오브젝트

오브젝트는 모델링된 시스템의 논리적 및 물리적 특징을 모두 표현하기 위하 여 사용된다. 예를 들어, 오브젝트는 파일, 디렉토리 및 IIS 내의 설정을 나타내기 위하여 사용될 수 있다. 오브젝트는 또한 애플리케이션이나 분산 시스템 바운더리를 나타내기 위하여 사용될 수 있다.

오브젝트는 세 카테고리로 분류할 수 있다. 각각은 속성을 통하여, 또는 특정 모델 인스턴스에 대한 임포징된 상속 구조라기 보다는 SDM 모델 그 자체의 일부로서 나타나고 이해되어야 하는 모델링된 시스템의 특징을 나타낸다.

2.1.1 리소스

리소스는 시스템 모델을 생성하기 위하여 조합될 수 있는 행동의 기초 유닛을 나타낸다. 리소스는 구조를 시스템 모델로 추가하기 위하여 다른 리소스를 함께 그룹핑하기 위하여 사용될 수 있다. 각각의 리소스는 모델링된 행동을 수행하기 위하여 요구될 수 있는 다른 리소스에 대한 의존을 나타낼 수 있다. 리소스의 인스턴스를 생성하기 위하여, 호스트 환경은 리소스를 위하여 인식되어야만 한다.

리소스의 예시는 파일, 디렉토리, 레지스트리 키 및 운영체제의 일부인 값, 웹 디렉토리 및 IIS의 일부인 웹 파일 및 표, 행(row) 및 데이터베이스의 일부로서 저장된 프로시져를 포함한다.

2.1.2 시스템

시스템은 잘 정의된 태스크를 수행하는 리소스의 집합을 나타내거나 잘 정의된 태스크를 수행하기 위하여 상호 작용하는 시스템의 집합을 나타내기 위하여 사용된다. 시스템 바운더리 내의 리소스는 바운더리 외부의 리소스에 의존함을 나타낼 수 없다. 동시에, 리소스가 동일한 시스템 바운더리 내에서 다른 리소스와 통 신하도록 사용되는 메카니즘을 문서화하도록 요구하지 않는다.

이것은 시스템 간의 상호 작용이 통신관계를 사용하여 명시적으로 모델링되어야만 함을 의미한다. 일반적으로 시스템은 배치의 가장 작은 유닛을 의미한다. 리소스가 다른 리소스와의 문서화되지 않은 상호 작용을 가질수 있으므로, 만약 리소스가 독립적으로 배치된다면, 리스스가 동작할 것이라고 보증할 수 없다.

시스템의 예시는 운영체제, IIS에서 호스팅된 웹 애플리케이션 및 SQL에 의하여 호스팅된 데이터 베이스를 포함한다.

2.1.3 종단점(Endpoint)

종단점은 다른 시스템과의 통신을 지원하도록 시스템이 나타내는 인터페이스를 정의하기 위하여 사용된다. 리소스가 시스템 바운더리를 크로싱하는 의존성을 갖도록 허용되지 않으므로, 종단점은 시스템이 바르게 동작하도록 허용하기 위하여 요구되는 상호 작용을 모델링하기 위하여 사용되어야만 한다. 종단점의 예시는 Http, Tcpip 및 Soap 종단점을 포함한다.

2.2 관계(RELATIONSHIP)

오브젝트간에 발생하는 상호 작용의 특징을 캡쳐하기 위하여 관계가 사용된다. 모든 관계는 바이너리이고, 유도된다. 오브젝트 간의 상호 작용을 캡쳐링함과 동시에, 관계는 관계에 참가하는 오브젝트에 제한 조건을 두고, 참가자간의 설정 정보를 플로윙할 수 있다.

다시 한번, 상기 관계에 특정 의미(sematics)를 첨부하기 위하여 SDM 모델에 의하여 이해되는 관계의 세트가 인식된다. 이에 의하여 모델 시스템의 런타임 행 동에 관하여 추론할 수 있다.

특히 특정 오브젝트 인스턴스에 대하여 설명할 필요가 있는 특성은 다음과 같다.

a) 그 수명

b) 누가 특정 오브젝트 인스턴스와 상호 작용할 수 있는지

c) 시스템 구조에서의 어디에서 특정 오브젝트 인스턴스가 출현하는지

d) 특정 오브젝트 인스턴스가 누구와 통신하는지

e) 그 작업을 수행하기 위하여 특정오브젝트 인스턴스가 누구에 종속되는지

f) 어떤 환경에서 실행되어야 하는지

g) 정확하게 동작하고 있는지 및 사용가능한지

또한 애플리케이션의 허용가능 구조를 정의하기 위하여 관계가 사용될 수 있다.

a) 다른 오브젝트가 어떤 오브젝트를 포함할 수 있는지

b) 어떤 종단점이 함께 연결될 수 있는지

c) 어떤 환경이 특정 오브젝트를 호스팅할 수 있는지

각각의 다음 관계는 상기 특징 중 하나 이상의 일부를 캡쳐링한다.

2.2.1 포함(Containment)

포함 관계는 SDM 모델의 포함 구조를 정의하기 위하여 사용된다. 포함 관계의 존재는 하나의 오브젝트가 다른 오브젝트를 포함할 수 있다는 것을 지시하기 위하여 사용된다. 포함 관계가 시스템, 리소스 및 종단점을 어떻게 연관시킬수 있는 지에 대하여 개발자나 설계자에 옵션을 제시할 때, 이 정보는 디자인 타임에 디자인 환경을 안내하기 위하여 사용된다.

포함 관계는 SDM 모델의 구조를 제한하기 위하여 정의된다. 예를 들어, 설계자는 웹 디렉토리, 파일 시스템 디렉토리 및 파일을 포함할 수 있는 웹 애플리케이션 모델을 디자인할 수 있다. 다른 설계자는 모델을 확장하여 모델이 웹사이트를 포함할 수 있도록 한다. 이 모델의 기본 구조를 이해함으로써, 오퍼레이터 및 툴 빌더는 모델의 환경 인스턴스가 무엇을 요구할 수 있고 그것이 배치되는 시스템 상에서 특정 모델이 가질 수 있는 효과가 어떠한 것인지에 관하여 추론할 수 있다. 예를 들어, 위에서 정의된 제1 모델에서, 오퍼레이터는 웹 사이트를 제공하여 애플리케이션이 배치될 수 있도록 한다.

포함 관계는 오브젝트의 수명, 오브젝트의 소유자 및 모델링된 시스템의 구조에서 오브젝트가 어디에서 출현하는가를 정의한다. 만약 오브젝트용 단일 부모 컨테이너가 존재한다면, 부모의 수명은 포함된 오브젝트의 수명 내에 머무른다. 부모는 또한 포함된 오브젝트를 소유할 것이다. 이것은 부모가 오브젝트의 가시성에 대한 제어를 구비하고, 그 부모에 오브젝트의 일부 또는 오브젝트를 나타낼 것인지를 결정할 수 있다는 것을 의미한다. 결과적으로, 부모는 오브젝트용 컨텍스트 정보를 제공한다. 이 컨텍스트 정보는 개발자가 그 애플리케이션의 구조를 다른 개발자 또는 애플리케이션의 사용자와 통신하도록 돕기 위하여 사용된다. 예를 들어, 실행중인 애플리케이션에서 에러를 로컬라이징할 때, 포함 체인은 애플리케이션의 어느 부분이 실패인지를 상세히 지시하면서, 풍부한 컨텍스트 정보를 제공 할 수 있다.

포함 관계의 사용은 웹 애플리케이션의 가상 디렉토리 구조 및 웹 애플리케이션에 의하여 배치되는 파일 및 디렉토리의 구조를 나타내는 것을 포함한다. 포함은 또한 웹 애플리케이션 및 그 일부인 연결된 시스템 모델 사이의 관계를 설명하기 위하여 사용될 것이다.

2.2.2 호스팅(Hosting)

호스팅 관계는 모델링되고 있는 환경의 포함 구조를 모델링하기 위하여 사용된다. 이 관계는 환경 상의 기능 제한 조건을 캡쳐링한다. 예를 들면, 파일들이 디렉토리에 포함되어야만 한다는 제한 조건 또는 웹 디렉토리가 웹사이트에 포함되어야만 한다는 제한 조건을 말한다.

호스팅 관계는 실행 환경 및 실행 시의 오브젝트의 수명 모두를 정의한다. 오브젝트가 존재하기 위하여, 오브젝트는 적어도 하나의 호스트를 가진다. 이것은 호스트의 수명은 오브젝트의 수명 내에 머무르고, 만약 호스트가 오프라인으로 마킹된다면, 호스트의 수명도 오프라인으로 마킹된다는 것을 의미한다.

호스팅 관계는 호스트에 의하여 정의되는 환경 내에서 오브젝트의 인스턴스를 관리하고 생성하는 것을 책임진다. 이 팩터링은 게스트 또는 호스트보다는, 관계를 갖는 호스트 상의 게스트의 인스턴스를 생성하는 책임을 둔다. 호스팅 관계의 범위를 제공함으로써, 게스트는 다중 호스트 환경에 의하여 지원될 수 있다.

호스팅 관계의 존재는 호스트 오브젝트 상에 게스트 오브젝트를 위치시키는 것이 가능하다는 것을 지시한다. 다른 시스템 상에서 호스팅되는 많은 리소스를 포함하는 시스템에 대하여, 게스트 시스템에서의 모든 리소스는 호스트 시스템에서의 적어도 하나의 리소스와 호스팅 관계를 가져야 한다.

2.2.3 통신(Communication)

통신 관계는 연결된 시스템의 서브시스템 사이에서 발생하는 통신을 모델링하기 위하여 사용된다. 통신 관계는 종단점 오브젝트 사이에서 나타나므로, 통신 관계는 종단점을 나타내는 시스템 사이에서만 설정될 수 있다. 만약 시스템이 종단점을 나타내는 중첩 시스템을 포함한다면, 이 종단점은 내부 시스템의 종단점과 교대로 위임되는 외부 시스템 상의 프록시 종단점을 통하여 나타난다.

통신 관계가 종단점의 세트 간에 존재하지 않는다면, 커넥션은 이 종단점 사이에 설정될 수 없다.

만약 시스템이 오프라인으로 마킹된다면, 이 시스템의 모든 클라이언트는 시스템이 사용 불가하다는 사실을 반영하여 업데이트 된다. 이것은 시스템을 참조하는 통신 관계를 통하여 변화를 전파함으로써 수행된다.

2.2.4 참조(Reference)

참조 관계는 정확한 연상을 수행하기 위하여 요구되는 리소스 또는 시스템 간의 종속성을 캡쳐하기 위하여 사용되지만, 종속 오브젝트의 실행 환경의 일부로 고려되지는 않는다.

예를 들어, 웹 디렉토리는 웹 서비스의 소비자에게 웹 컨텐츠를 나타내기 위하여 로컬 디렉토리 또는 원격 쉐어로의 참조를 필요로 한다. 이것은 웹 디렉토리 및 로컬 디렉토리 또는 원격 쉐어 사이에서의 종속성 관계로 표현될 것이다.

2.2.5 위임(Delegation)

프록시에 의하여 나타난 행동을 구현하는 오브젝트 인스턴스로의 프록시로 상호작용을 전달하기 위하여 위임 관계가 사용된다. 널리 사용되는 위임의 예시는 부모 시스템에서의 종단점으로부터 포함된 시스템의 종단점으로 통신 관계를 포워딩하고 있다.

2.3 정의(DEFINITION)

오브젝트 및 관계 정의는 상기 설정의 인스턴스를 생성하기 위하여 인스턴스화 될 수 있는 재사용 가능한 설정을 생성하기 위하여 사용된다. 그러면 이 인스턴스들은 정의에 의하여 인식된 공통 특성을 공유한다.

추상화 정의는 그것이 불완전하므로 직접 인스턴스화될 수 없다. 추상화 정의를 완료하기 위하여, 또다른 정의가 빠진 요소를 추가하기 위하여 추상화 정의를 확장한다.

실제 시스템의 모델을 구축할 때 사용할 수 있는 빌딩 블록을 생성하기 위하여, 추상화 정의가 사용된다. 추상화 정의 사이의 관계는 추상화 정의를 확장하는 정의의 허용 가능 구조를 정의한다. 이것은 디자인 표면이 추상화 정의를 사용하여 표면의 사용자가 수행할 수 있는 동작을 정의하도록 허용한다. 예를 들어, 추상화 웹 애플리케이션이 참가하는 포함 관계는 추상화 정의를 확장하는 웹 애플리케이션의 구조를 안내한다.

본래, 추상화 오브젝트 정의 및 관계 정의의 조합은 목적 시스템을 모델링하기 위한 스키마를 정의한다. 견고한 오브젝트 정의의 역할은 추상화 정의 스페이 스의 서브셋을 사용하여 하나 이상의 추상화 정의에 기초한 재사용 가능 설정을 생성하는 것이다. 간단히 유추하면, 추상화 정의 스페이스는 데이터베이스용 스키마와 비교될 수 있다. 그러면 견고한 오브젝트 정의는 데이터베이스에서의 행(row)의 세트용으로 재사용 가능한 템플릿을 나타낸다. 행은 견소한 오브젝트의 인스턴스가 생성될 때, 데이터 베이스에서만 생성될 수 있다. 디자인 시간 유효화를 수행하기 위하여, 스키마(예를 들어, 외부 키 등)의 제한 조건에 대한 데이터베이스에서 행을 유효화하는 것과 같은 방식으로, 추상화 정의 스페이스에 대한 견고한 오브젝트 정의를 유효화할 수 있다.

설정 정의는 간단한 값 요소를 생성하기 위하여 사용된다. 그러면 이 값 요소는 설정 정보를 저장하기 위하여 사용된다.

2.4 멤버(MEMBER)

정의는 다른 정의를 참조하는 멤버를 포함할 수 있다. 멤버는 특정한 애플리케이션에 커스터마이징된 방식으로 하나의 정의가 다른 정의를 재사용하도록 허용한다.

설정 멤버는 정의와 연관된 설정 정보를 인식하기 위하여 사용된다. 설정 멤버는 설정 정의에 기초한다.

오브젝트 멤버는 특정 오브젝트 정의의 인스턴스를 생성하기 위하여 사용된다. 설정 플로우는 오브젝트용 값을 제공하기 위하여 사용될 수 있다. 오브젝트 멤버를 선언할 때, 사용자는 외측 시스템이 생성되거나(값 의미; value semantics), 외측 시스템이 이후에 발생하는 명시적인 새로운 연산에 의하여 생성 됨(참조 의미; reference semantics)과 동시에, 오브젝트 멤버가 생성되는지 여부를 결정할 수 있다.

관계 멤버는, 그것들이 생성될 때 오브젝트 멤버가 참가할 관계를 정의한다. 만약 오브젝트 멤버가 부모에 의하여 포함되는 경우, 포함 관계 멤버는 멤버 및 포함 정의 사이에서 선언될 것이다. 만약 오브젝트 멤버가 위임되는 경우, 위임 관계 멤버는 오브젝트 멤버 및 소스 오브젝트 멤버 사이에서 정의될 것이다. 통신 관계 멤버는 통신하는 종단점 사이에서 선언될 수 있다. 종속성 관계 멤버(참조 및 호스팅)는 종속 및 소스 오브젝트 멤버 사이에서 선언될 수 있다.

제한 조건 멤버는 특정 오브젝트가 참가하기 쉬운 관계의 세트 또는 특정 관계에 참가할 수 있는 오브젝트의 세트를 좁히기 위하여 사용된다. 그들은 오브젝트 또는 관계의 설정을 목적할 수 있거나 오브젝트 또는 관계와 연관된 상호 작용을 제한할 수 있는 오브젝트 또는 관계에서 제한 조건을 인식한다.

멤버들 사이에서 설정의 플로우를 정의하기 위하여 플로우 멤버가 사용된다. 플로우 멤버는 멤버에 대한 설정으로부터 입력 값을 수집하고, 상기 정보에 대한 일정한 프로세싱을 수행하고, 결과를 멤버에 대한 설정으로 배치한다.

2.5 인스턴스(INSTANCE)

인스턴스 스페이스는 모델링된 시스템의 현재 상태를 반영한다. 생성된 인스턴스의 완전한 레코드 및 이 인스턴스 사이의 관계도 관리될 수 있다. 각각의 인스턴스는 각각의 버전(version)이 변화 요청(change request)으로 링킹된 관련 버전 히스토리를 가진다.

새로운 인스턴스를 생성하는 프로세스는 변화 요청에 의하여 초기화된다. 변화 요청은 현존하는 인스턴스의 특정 멤버와 연관된 타입 및 관계를 위한 생성, 업데이트 및 삭제 요청을 생성한다. 루트는 특별한 케이스이다.

변화 요청은 런타임에 의하여 확장되고, 모든 제한 조건에 대하여 검증되고, 구축된다. 확장 프로세스는 포함 오브젝트의 구축 요청의 일부로서 내재적으로 구축된 관계 인스턴스 및 오브젝트를 인식하고, 그런 후 설정 플로우는 모든 관계에 대하여 평가된다. 검증 단계는 모든 요구 관계가 존재한다는 것을 검사하고 관계가 모든 제한 조건을 충족한다는 것을 검사한다. 결과적으로, 구축 프로세스는 배치에 대한 적절한 정렬, 업데이트 또는 각각의 인스턴스의 제거를 결정하고, 그런 후 적절한 동작을 수행하기 위하여 인스턴스 매니저로 각각의 인스턴스를 정확한 시퀀스로 통과시킨다.

2.6 오브젝트 모델

다음의 uml 다이아그램은 SDM 모델에서 오브젝트 간의 광범위한 상호 작용을 캡쳐링한다. 간단하게 하기 위하여, 이 상호 작용의 일부는 유도된 타입 사이에서 실제 상호 작용이 존재하는 베이스 타입 사이에서 정의되고, 그에 따라 결과는 더 특화된다.

SDM 문서는 문서를 설명하는 정보, 문서에서의 정의를 위한 매니저, 다른 문서를 참조하는 임포트 명령문 및 문서에 의하여 설명되는 오브젝트 및 관계용 정의의 세트를 포함한다. 다수의 SDM 요소는 또한 디자인 데이터를 포함할 수 있고, 이것은 디자인 표면이 SDM 요소를 디자인 표면 내에서의 상기 요소의 디스플레이 및 조작에 특정한 정보로 귀착시키도록 허용한다.

도 8은 예시 SDM 문서를 도시한다.

모든 SDM 정의는 도 9에 나타난 것처럼 공유 베이스 정의로부터 유도된다. 정의는 설명, 멤버의 세트, 설정 값 및 디자인 데이터의 세트를 포함할 수 있다. 정의는 오브젝트, 관계, 제한 조건, 플로우 및 설정 정의로 분화된다. 그런 후 오브젝트 정의는 시스템, 리소스 및 종단점 정의로 또한 분화된다. 관계 정의는 또한 호스팅, 통신, 위임, 참조 및 포함 정의로 분화된다.

네임을 도 10에 도시된 특정 인스턴스 또는 인스턴스 어레이에 연관시키기 위하여 멤버가 사용된다. 모든 멤버는 정의를 참조한다. 각각의 멤버는 설정 값의 세트, 설명 및 디자인 데이터를 포함할 수 있다. 그런 후 멤버는 그들이 참조하는 정의의 종류에 기초하여 분화된다. 플로우 및 제한 조건 멤버는 포함 정의 내의 설정 멤버로부터 설정 값을 소싱하는 입력을 정의하는 능력을 추가한다. 플로우 멤버는 또한 포함 정의 내에서 설정 멤버에 전달되는 프로세싱된 플로우 값을 허용하는 출력을 추가한다.

예시 설정 멤버가 도 11에 도시되어 있다. 설정 멤버는 복잡한 또는 간단한 설정 정의를 나타낼 수 있는 설정 정의를 참조한다. 복잡한 설정 정의는 중첩 설정 멤버를 포함할 수 있다. 간단한 정의는 단일 값 필드를 정의한다. 입력 및 출력 오브젝트는 설정 멤버 사이의 설정 값의 전송을 정의하기 위하여 사용된다.

예시 제한 조건 정의는 도 12에 도시된다. 설정 값 및 SDM 모델의 구조에 대하여 규제하기 위하여 제한 조건이 사용된다. 제한 조건 정의는 특정 오브젝트 또는 관계 정의를 목적화한다. 제한 조건 정의는 오브젝트가 참가하는 관계에 대한 또는 관계에 참가하는 오브젝트에 대한 구조적 제한 조건을 가할 수 있다. 이 구조적 정의는 또한 오브젝트 또는 관계 정의에 직접 추가될 수 있다.

설명 오브젝트는 도 13에 도시된 것처럼, SDM 요소에 대한 사람이 판독 가능한 설명을 제공하기 위하여 사용된다. 매니저의 책임인 이 요소는 로컬화되어야만 한다. 디자인 데이터 요소는 SDM 문서를 편집하는 디자인 표면에 의하여 정의되는 구조화된 데이터를 포함한다.

2.7 계층화(LAYERING)

SDM 모델의 목표는 애플리케이션의 개발자, 소프트웨어 하부구조의 디자이너 및 데이터 센터의 설계자 사이의 관계의 분리를 허용하는 것이다. 상기 각각의 그룹은 특정 서비스에 초점을 맞추고 다른 종속성 집합을 갖는다.

예를 들어, 개발자는 주로 SQL, IIS 및 CLR과 같은, 그들이 의존하는 호스트 사이의 설정 및 연결성에 관하여 신경을 쓴다. 호스트 설정의 디자이너는 네트워크 토폴로지 및 OS 설정에 관하여 신경을 쓰는 반면, 네트워크 토폴로지, OS 설정 및 저장 맵핑을 개발하는 설계자는 데이터 센터에 존재하는 하드웨어에 관하여 알 필요가 있다.

이와 같은 관계의 분리를 지원하기 위하여, SDM은 계층화의 개념을 나타낸다. 계층화는 호스팅 관계의 사용에 의하여 가능해진다. 운영체제, sql과 같은 호스트 및 sql이 예시 데이터베이스에 제공하는 서비스 사이에서의 호스팅 관계를 정의함으로써, 애플리케이션 개발자는 데이터 베이스를 포함하는 애플리케이션을 정의하도록 허용되는 반면에, 설계자는 sql 호스트를 포함하는 시스템을 정의한다. 게스트 시스템 및 호스트 시스템 사이에서의 호스팅 관계를 연결함으로써, 상기 분리된 시스템을 조합하여 계층화한다.

계층화 바운더리는 호스팅 관계가 존재하는 곳마다 발생할 수 있다. 계층 바운더리를 위치시킬 곳의 선택을 간단히 하기 위하여, 4개의 기초 계층은 SDM 모델의 일부로 정의된다. 그러면 시스템은 이 계층들 중 하나와 연관된다. 4개의 계층은 아래와 같다.

애플리케이션 계층

. 애플리케이션 계층은 제한된 컨텍스트에서 애플리케이션의 구축을 지원한다. 컨텍스트는 호스트 계층에서 인식되는 호스트의 설정에 의하여 정의된다.

. 애플리케이션 계층에서의 시스템 정의의 예시는 웹 서비스, 데이터 베이스 및 비즈토크 스케줄(biztalk schedule)을 포함한다.

호스트 계층

. 소프트웨어 컴포넌트로부터 데이터 센터를 구축. 컴포넌트 사이에 커넥션을 설정. 이 컴포넌트 중 일부는 애플리케이션 계층을 위한 호스트로 동작

. 이 계층에서의 시스템 정의의 예시 - IIS, SQL, AD, EXCHANGE, DNS 및 Biztalk.

네트워크/OS/저장 계층

. 데이터 센터 네트워크 및 플랫폼 구축. 네트워크 보안 모델 및 운영체제 플랫폼 설정을 설정. 운영체제 설정에 저장공간을 추가.

. 이 계층에서의 시스템 정의의 예시 - VLAN, Windows, Filter, Storage

하드웨어 계층

하드웨어 계층은 데이터 센터에 존재하는 기계의 타입 및 이 기계사이에 존재하는 물리적 커넥션을 인식한다.

도 14는 계층 4 웹 애플리케이션을 계층 3 웹 서버 호스트로 맵핑하는 예제를 도시한다. 각각의 계층에서의 외측 박스는 시스템을 나타내고, 바운더리 상의 박스는 종단점을 나타내고, 내측에서의 박스는 리소스를 나타낸다. 각각의 상기 요소는 호스팅 관계를 통하여 아래의 계층에서 호스트로 맵핑된다.

3. 구현 세부사항

3.1 명칭 부여(NAMING)

SDM에는 우리가 오브젝트를 식별하기 위해 강력한 명칭 부여 시스템이 필요한 곳이 많이 있다. 이하의 명칭 부여 시스템은 SDM 문서 생성자로 하여금 문서내의 정의들을 사용하는 사용자가 그 정의들이 개발자가 최초에 공표했던 것과 동일한 것이라고 확신할 수 있는 방식으로 문서에 서명할 수 있도록 한다.

이하 헤더는 SDM 문서의 식별자에 대한 일례이다.

다른 명칭 공간(namespace)의 타입을 참조하기 위해서는, 해당 명칭 공간 가져오기(import)를 해야한다.

그 다음에 에일리어스(alias)를 사용하여 그 명칭 공간 내의 정의들을 참조할 수 있다.

3.1.1 식별 번호(identity)

SDM 명칭들은 그들이 정의되는 명칭 공간에 의해 범위가 정해진다. 하나의 명칭 공간은 명칭, 버전, 언어 및 공개 키 토큰에 의해 식별되고, 하나의 파일 내에 포함된다.

식별 번호의 기본 양식은 명칭(name), 버전(version), 컬쳐(culture), 플랫폼(platform) 및 공개 키 토큰(public key token)을 포함한다.

기본 식별 번호는 서명 및 공개 키와 관련하여 사용될 수 있는데, 명칭 공간 식별 번호(Namespace Identity)라고 불리는 새롭고 강한 식별 번호를 생성할 수 있다. 이 식별 번호는 SDM 문서를 식별하는데 사용된다. 식별 번호를 생성하기 위해서는, 문서의 사용자에게 공개 키를 이용하여 내용을 검증하도록 하면서, 문서는 비밀 키를 이용하여 서명될 것이다.

공개 키 토큰은 공개/비밀 키 쌍에서 공개 부분을 식별하는 16 문자의 16진 수 스트링이다. 이것은 공개 키가 아니고 단순히 공개 키의 64-비트 해시이다.

문자 언어는 해당 언어를 정의하는 두 개의 소문자와 그 다음에 국가 또는 지역을 정의하는 두 개 또는 세 개의 대문자로 구성된 컬쳐 식별자를 사용하여 명시된다.

3.1.2 버전

파일 버전은 N.N.N.N 형식의 네 부분의 숫자에 의해 정의되는데, 여기서 0＜=N＜65535 이다. 관례적으로, 숫자는 주(Major).부(Minor).빌드(Build).개정(Revision)을 일컫는다. 버전 번호는 문서내에 포함된 모든 정의들의 버전을 식별한다. 이는 문서내의 모든 정의가 함께 업그레이드될 때에 문서가 버전을 매기는 단위가 된다는 것을 의미한다.

3.1.3 단순 명칭(Simple names)

단순 명칭은 영숫자(alpha-numeric) 문자와 제한된 구두점으로 구성된다. 명칭은 숫자가 아닌 문자로 시작한다.

식별자에 대해서는 C# 정의를 따르려고 한다. 이하의 테이블에서 적절한 섹션이 밑에 추가되었다. SDM 모델에서 "＠" 접두 명칭은 지원하지 않는다.

3.1.4 예약 명칭(Reserved names)

다음은 사용자로 하여금 SDM 정의에서 멤버에 해당하는 명칭을 생성할 때에 사용하지 못하게 하는 예약 명칭의 리스트이다. 일정 문맥 안에서, 일정 이름이 예약될 것이다. 컴파일러는 이들의 명칭이 사용되는 것을 인지하고 사용자에게 에 러를 리턴할 것이다.

3.1.5 다른 명칭 공간으로의 참조

다른 명칭 공간을 현재의 명칭 공간으로 가져오기를 하고, 그 다음에 에일리어스를 그 명칭 공간과 연관시킴으로써, 명칭 공간이 다른 명칭 공간을 참조하도록 할 수 있다. 가져오기가 된 명칭 공간은 명칭, 버전, 및 공개 키 토큰에 의해 참조된다.

3.1.6 승인 명칭(Qualified Names)

승인 명칭은 현재의 명칭 공간 또는 에일리어스된 명칭 공간에서 정의된 정 의 또는 관리자를 참조하는 명칭이다. 만일 명칭이 에일리어스 또는 "점 분리자(dot separator)"를 포함하지 않는다면, 그것은 승인되지 않은 것이고, 범위 규칙(scoping rule)에 기반하여 분해되어야 한다. 승인되지 않은 패스는 평가되는 문맥에 기반하여 다른 정의로 분해될 수 있다. 이것은 내포된 정의가 더 넓은 범위에서 정의를 숨길 수 있기 때문이다. 이는 섹션 3.1.7에서 설명된다.

"점 분리자"를 포함하는 모든 패스는 완전하게 승인되어야 하고, 문서 루트(root)부터 분해될 것이다. 이것은 사용자가 하나 이상의 타입 명칭을 포함하는 부분적으로 승인된 명칭을 생성할 수 없고, 단지 선언 문맥으로부터 분해될 수 있음을 의미한다.

에일리어스는 중요한 문(statement)에서 정의된다.

3.1.7 명칭 범위(Name scoping)

정의의 명칭은 정의되는 문맥에 의해 범위가 정해진다. 가장 넓은 범위는 문서이다. 만일 정의가 내포되어 있다면, 그것의 명칭은 그 정의에 의해 범위가 정해진다. 이것은 그것이 부모 범위의 명칭을 숨길 수 있음을 의미한다. 그것은 또한 정의된 범위 밖의 정의에 대한 참조는 그것의 부모 범위의 명칭에 의해 승인되어야 한다는 것을 의미한다. 완전하게 승인된 명칭은 문서 루트부터 내포된 정의까지의 모든 명칭을 포함한다.

3.1.8 멤버 패스(Member Paths)

멤버 패스는 교차되는 정의의 멤버에 대응하는 명칭의 시퀀스이다. 패스는 그 패스가 선언되는 문맥에서 정의된 멤버 명칭으로 시작되야 한다.

어떤 멤버 명칭들은 자동으로 정의에 부가된다. 이것들은 주지(well-known) 명칭이라고 불린다. 주지 명칭에 대한 예는 정의 또는 참조 선언에서의 "this", 호스팅 관계 선언에서의 "Host" 및 "Guest", 제한 조건 선언내에서 정의된 "Target"을 포함한다. 설정 목적은 또한 소스(source) 값 또는 패스에 의해 식별되는 설정의 종착(destination) 설정 중 어느 하나로 사용될 관련 플로우(flow) 정의 상의 설정을 식별한다.

멤버 명칭은 점으로 분리된다.

3.1.9 인스턴스 패스(Instance Paths)

인스턴스 스페이스에서의 패스는 xpath 내의 요소 명칭이 멤버 명칭과 대응하고 xpath 내의 속성이 설정과 대응하는 xpaths를 기반으로 한다.

3.1.10 서명(Signature)

컴파일된 SDM 문서는 문서의 내용을 확인하고, 강한 명칭을 문서와 연관시키기 위한 절차를 제공하기 위하여 키를 이용하여 서명된다. 상기 서명 절차는 DSIG 표준(http://www.w3.org/2000/09/xmldsig#)을 사용하여 문서에 서명한다.

다음과 유사한 서명 노드는 서명된 문서에 삽입된다.

상기 노드는 문서의 다른 내용에 앞서 발생해야 하는 문서의 루트 노드이다. 'any' 태크를 이용하여 이 요소를 선언하지만, 이 위치에서 단지 "Signature" 노드를 인식하고 처리할 것이다.

3.1.11 명칭 공간 명칭의 정의, 참조, 및 분해

이 섹션에서는, 명칭 공간 참조(namespace reference)를 특정 명칭 공간과 정합시키기 위해 사용하는 절차를 설명한다. 섹션 3.1.1에서 정의된 바와 같이, 명칭 공간 식별 번호는 다섯 개의 속성으로 구성된다.

●단순 명칭(Simple name)

●공개 키 토큰(Public key token)

●버전(Version)

●언어(Language)

●플랫폼(Platform)

이러한 속성들은 요청되는 명칭 공간(명칭 공간 참조)를 식별하기 위해 명칭 공간의 소비자에 의해 사용되고, 명칭 공간(명칭 공간 정의)에 대한 주지 식별 번호를 제공하기 위해 명칭 공간의 개발자에 의해 사용된다. 이러한 각 속성들의 번역은 그들이 명칭 공간 참조 또는 명칭 공간 정의의 일부인지 여부에 따라서 달라진다.

3.1.11.1 명칭 공간 정의

개발자가 새로운 명칭 공간을 생성하고 공표하고자 할 때에는 개발자는 다음과 같은 일을 수행한다.

●명칭 공간에 대한 단순 명칭 제공

●명칭 공간에 대한 버전 제공

개발자는 선택적으로 다음과 같은 일을 할 수 있다.

●암호화 키로 명칭 공간 서명하기

●명칭 공간에 대한 특정 컬쳐 식별하기(디폴트는 culture neutral임)

●명칭 공간에 대한 특정 플랫폼 식별하기(디폴트는 platform neutral임)

만일 명칭 공간이 서명되지 않으면, 공개 키 토큰은 없을 것이고, 명칭 공간은 약한(weak) 명칭을 가질 것이다. 명칭 공간은 개발자로 하여금 서명 절차를 컴 파일 절차와 분리할 수 있도록 지연 서명될 수 있다. 컴파일되었지만 아직 서명되지 않은 지연 서명된 명칭 공간은 컴파일 동안에 참조될 수 있지만, 런타임에 사용될 수 없다.

3.1.11.2 명칭 공간 참조

소비자가 SDM 파일의 명칭 공간을 참조(가져오기) 할 때, 그들은 다음과 같은 일을 한다.

●참조되는 명칭 공간의 명칭 제공

그들은 선택적으로 다음을 포함하는 부가적인 정보를 제공할 수 있다.

●참조되는 명칭 공간의 공개 키 토큰

●참조되는 명칭 공간의 최소 버전

●참조되는 명칭 공간의 컬쳐 또는 와일드카드(*)

●참조되는 명칭 공간의 플랫폼 또는 와일드카드(*)

제공되지 않은 모든 속성들은 디폴트로 속성의 어떠한 값과도 정합하는 와일드카드가 된다.

3.1.11.3 참조를 정의에 정합시키기

다음 알고리즘은 명칭 공간 참조를 명칭 공간 정의에 정합하는데 사용된다. 이 알고리즘은 명칭 공간을 컴파일할 때 및 컴파일된 명칭 공간 사이에 참조를 분해할 때 모두에 있어 사용된다.

컴파일과 후(post) 컴파일 시나리오 사이에는 다음과 같은 약간의 차이점 하나가 있다. 컴파일 시간에는 명칭 공간 참조의 버전 필드가 무시되나, 런타임에는 그것이 존재해야 한다. 컴파일 과정은, 컴파일 동안에 참조가 분해되는 명칭 공간으로부터 부가적인 정보를 추가하기 위해서 명칭 공간 참조를 업데이트 할 것이다. 그것은 항상 명칭 공간으로부터 버전을 추가할 것이다. 만일 공개 키 토큰이 제공되지 않고, 분해된 명칭 공간 상에 존재한다면, 그것은 명칭 공간 참조에 부가될 것이다.

논리적으로, 분해 알고리즘은 다음과 같이 동작한다.

1. 참조의 명칭과 정합하는 명칭을 가진 모든 명칭 공간을 찾는다.

2. 만일 참조가 공개 키 토큰을 제공하면, 제공된 공개 키 토큰과도 정합하는 명칭 공간 만을 선택한다.

3. 만일 특정 언어가 참조에 의해 제공되었다면, 그 언어에 정합하지 않는 모든 명칭 공간을 제거한다. 만일 언어 속성이 와일드카드로 설정되었거나, 또는 제공되지 않았다면, 모든 명칭 공간을 유지한다.

4. 만일 특정 플랫폼이 제공되었다면, 그 플랫폼과 정합하지 않는 모든 명칭 공간을 제거한다. 만일 플랫폼 속성이 와일드 카드로 설정되었거나, 또는 제공되지 않았다면, 모든 명칭 공간을 유지한다.

5. 그리고 나서 가능한 명칭공간의 집합으로부터 특정 명칭 공간을 선택하는 버전 정책(versioning policy)을 사용한다.

다음 섹션은 더욱 자세하게 이러한 단계를 정의한다.

3.1.11.3.1 정합 명칭 공간 명칭(Matching namespace name)

명칭 정합은 정확한 스트링 정합이다. 명칭은 경우에 따라 다르다.

3.1.11.3.2 정합 공개 키 토큰(Matching public key token)

토큰은 정확한 정합이다.

3.1.11.3.3 정합 언어(Matching language)

언어 정합을 위한 세 가지의 시나리오가 있다.

1. Reference = *, Definition = 특정 언어.

2. Reference = 특정 언어, Definition = *.

3. Reference = 특정 언어, Definition = 특정 언어.

첫 번째와 두 번째의 경우, 정의가 참조에 대한 정합이다. 세 번째의 경우, 언어가 정확한 정합인 경우에만 정의는 참조에 대해 정합이다.

3.1.11.3.4 정합 플랫폼(Matching platform)

플랫폼 정합을 위한 세 가지 시나리오가 있다.

1. Reference = *, Definition = 특정 플랫폼.

2. Reference = 특정 플랫폼, Definition = *.

3. Reference = 특정 플랫폼, Definition = 특정 플랫폼.

첫 번째와 두 번째의 경우, 정의가 참조에 대한 정합이다. 세 번째의 경우, 플랫폼이 정확한 정합일 경우에만 정의는 참조에 대해 정합이다.

3.1.11.3.5 정합 버전(Matching version)

버전 정합은 컴파일러 또는 런타임에 의해 사용되는 버전 정책에 종속된다.

3.2 설정(SETTINGS)

모든 정의는 XML 스키마 내에서 설정 선언(setting declarations)이라고 불 리는 설정 멤버를 노출시킨다. 이러한 멤버들은 그 정의와 관련된 구성(configuration) 값을 나타내는데 사용된다. Setting Value 문을 이용하여 값이 제공될 수 있다.

이러한 것들은 다음에 의해서 사용될 수 있다.

a) 설정에 대한 디폴트 값을 정의하기 위해 설정 멤버를 선언하는 정의.

b) 기본 정의에 대한 디폴트 또는 고정 값을 제공하기 위해 다른 정의를 확장하는 정의에 의해서.

c) 정의를 참조하는 멤버에 의해 또는 해당 정의를 참조하는 멤버로 끝나는 멤버 패스를 통하여.

d) 관계를 따르는 플로우를 통하여.

설정을 정의하기 위해서는 먼저 xsd를 사용하여 설정의 정의를 정의할 필요가 있다.

그 다음에 정의를 사용하고, 설정의 작용을 정의하는 속성의 집합을 포함하는 설정을 선언할 수 있다.

일단 설정의 선언을 하면, 설정에 대한 값을 제공할 수 있다.

3.2.1 설정 정의

설정 멤버에 의해 사용되는 설정의 정의를 정의하기 위하여 XSD 스키마를 사용한다. 다른 스키마 요소들이 그들의 타입의 정의를 지원하기 위해 존재하더라도, 단지 스키마의 단순 타입과 복합 타입의 사용을 지원한다.

설정 정의 섹션은 명칭 공간 선언 및 명칭 공간 가져오기를 포함하는 완전한 xml 스키마를 포함하여야 한다. xsd 스키마에서의 가져오기가 xsd 스키마 명칭 공간를 제외하고 SDM 파일에서의 가져오기와 정합하는지 여부를 검사할 것이다. 이는 모든 참조되는 타입이 다른 SDM 파일에서 정의되어야 한다는 것을 의미한다. 스키마는 임의의 xsd 파일에서 정의되는 타입을 참조할 수 없다.

스키마의 목적 명칭 공간은 SDM 문서의 명칭과 정합하여야 한다. 명칭 공간 명칭이 유일하다는 것을 보장되기 위해서는 문서에 서명할 때, 문서에 대한 공개 키를 명칭 공간 명칭에 추가할 것이다. 따라서 컴파일러는 tagetNamespace="System"을 targetNamespace="System/AAAABBBBCCCCDDDD"로 변경할 것이다.

설정 정의 스키마가 다른 문서의 명칭 공간을 참조할 때에, 그들은 완전한 명칭 공간 명칭을 사용할 것이다. 즉 xmlns:system="System/AAAABBBBCCCCDDDD" 가 된다.

설정은 세 가지 분리된 명칭 공간으로부터 분해 가능하다.

a) SDM 명칭 공간 - 시스템 내의 설정 타입, 리소스(resource), 종단점(endpoint), 관계(relationship), 제한 조건(constraint) 또는 플로우 타입을 참조할 때.

b) clr 명칭 공간 - clr 내의 엄격 타입 클래스(strongly typed classes)를 사용하는 설정을 참조할 때 및 설정 타입이 다른 설정 타입을 토대로 생성될 때.

c) XSD 명칭 공간 - 설정 타입이 다른 설정 타입을 이용해서 생성될 때.

이것이 동작하게 하기 위해서는, 선언하는 설정 방식에 다수의 제한 조건을 두어야 한다.

a) 모든 설정은 각 clr, SDM, xsd 명칭 공간 내의 동일한 그룹핑(grouping) 내에 있어야 한다. 즉, 만일 두 개의 설정이 하나의 명칭 공간에 함께 있는 경우, 그들은 모두 세 개의 명칭 공간에 함께 있어야 한다.

b) xsd 스키마 정의내의 가져오기가 된 명칭 공간은 SDM 파일의 가져오기가 된 명칭 공간 및 관련 도우미 어셈블리의 가져오기가 된 명칭 공간과 정합해야 한다.

c) xsd 명칭 공간을 제외하고, xsd 스키마내의 모든 가져오기가 된 명칭 공간은 SDM 파일 내에 정의되어야 한다.

가져오기된 SDM 문서의 XSD 타입은 QNames:＜alias＞:＜type-name＞을 이용하여 접근 가능하다.

다음의 예는 상기 레지스트리 예에서 정의된 타입을 이용한다. 문서는 설정 정의를 포함하는 레지스트리 문서를 가져오기 한다.

그 다음에 설정 정의 스키마는 System.Operatingsystem.Registry 명칭 공간을 참조할 수도 있다.

3.2.2 내장(Built-in) 단순 데이터 타입

SDM은 XSD와 C# 명칭 공간의 공통된 내장 데이터 타입의 한정된 집합을 지원한다. 이러한 타입들은 원시적으로 SDM 런타임에 지원되고, 이하의 테이블에서 정의된다. 이러한 타입들에 부가하여, 사용자는 xsd와 cls 타입간에 그들 자신의 사상을 자유롭게 생성하여 이용한다.

이러한 타입들은 c# 및 xsd 타입 공간에서 이러한 타입들의 양립 가능한 파생형으로 흐를 수 있다. 예를 들면 스트링의 값은 스트링에 대한 제한 조건을 정의하는 xsd 타입으로 흐를 수 있고, 모든 값은 type="any" 를 수용하는 설정으로 흐를 수 있다.

3.2.2.1 XSD 내장 타입

도 15는 내장 데이터 타입 계층 예제를 보여준다. 도 15에서, 모든 복합(complex) 타입은 확장(extension) 또는 제한 조건(restriction)에 의해 유도 된다. NMTOKENS. IDREFS, 및 ENTITIES 타입들은 리스트에 의해 유도된다. 도 15에 도시된 모든 다른 타입들은 제한 조건에 의해 유도된다.

3.2.2.2 C# 데이터 타입

3.2.2.3 지원되는 변환

이것들은 xsd 타입과 cls 타입간에 존재하는 변환들이다.

3.2.3 설정 멤버

설정 선언 섹션은 명칭화된 설정을 생성하기 위해서 종전의 섹션의 설정 정의를 이용한다. xsd 스키마내의 설정 정의는, 그 설정을 포함하는 문서의 에일리어스를 포함하는 승인된 명칭(설정 정의가 현재의 문서에 있다면 필요하지 않다) 및 설정의 명칭 이용하여 참조된다. 설정 정의를 참조하는 경우 xsd 명칭 공간을 이용하지 않는다.

속성들은 각 설정 멤버에 대한 더 자세한 정보를 제공하는데 사용된다.

3.2.4 리스트 지원

다중 값(multi-valued) 설정의 조작을 지원하기 위해서, 설정 값의 단순 리스트를 지원한다. 리스트는 설정 선언과 동일한 정의에 대한 값들의 시퀀스이다. 리스트는 그것들이 대체하거나 부가할 수 있는 다른 리스트로 흐를 수 있다. 설정 플로우를 이용하여 더욱 유연하게 수행될 수 있기 때문에, 값을 리스트에 부가할 때에 중복 검출을 지원하지 않고, 어떠한 형태의 순서(ordering)도 보장하지 않는다.

리스트 선언은 true로 설정된 속성 리스트를 포함한다.

그 다음에 값들은 settingValueList를 이용하여 제공된다. 리스트를 제공할 때에, 사용자는 종전의 값들을 대체할 것인지 또는 종전의 값에 부가할 것인지 명세할 수 있다.

SDM은 값 리스트에 대한 단순 조작을 지원한다. 플로우 멤버로부터의 패스가 설정 선언을 목적으로 할 때에, 결과적인 동작은 패스의 양단의 정의에 종속된다.

3.2.5 설정 속성

설정 속성은 특정 설정의 동작을 설명하기 위하여 런타임에 사용된다.

3.2.6 설정 값

설정이 하나의 값 또는 리스트로서 선언되었는지 여부에 따라서, 설정에 대한 값은 설정 값 요소 또는 설정 값 리스트 요소 중 어느 하나를 이용하여 제공될 수 있다.

3.2.6.1 설정 값

설정 값 문(statement)은 특정 설정 선언에 대한 값을 제공하기 위하여 사용된다. 상기 값은 상기 선언과 관련된 정의와 정합하여야 하고, 상기 설정 선언과 관련된 정의로 캐스트되거나 변환될 수 있어야 한다. 만약 값이 고정된 것으로 선언된다면, 제공된 값은 모든 유도된 정의 또는 상기 값이 고정된 위치에 따라 참조하는 멤버에서 사용될 것이다. 일단 값이 고정되면, 그것은 번복될 수 없다.

속성/ 요소	설명
PATH	이 값이 적용되는 설정 선언으로의 패스
FIXED	fixed 속성은 제공된 값이 새로운 값에 의해 그 후에 번복될 수 있는지 여부를 제어한다. fixed 값이 true면 설정에 대해 제공된 값은 번복될 수 없음을 나타낸다. 만약 fixed 값이 구체적 정의 멤버의 설정 값에 대해 true라면, 그것은 그 멤버의 모든 배치에서 고정된다. 그와는 달리, 만약 fixed 값이 false라면 그것은 그 멤버의 각 배치에서 번복 가능하다. 만약 fixed 값이 구체적 정의의 설정 값에 대해 true라면, 그것은 그 구체적 정의의 모든 멤버(즉, uses)에 대해 고정된다. 그와는 달리, 만약 fixed 값이 false라면, 그것은 구체적 정의의 각 멤버(즉, use)에 따라 다르다. 만약 fixed 값이 추상적 정의의 설정 값에 대해 true라면, 그것은 그 추상적 정의를 확장하는 오브젝트를 구현하거나 추상화하는 구체적 정의에 대해 고정된다. 그와는 달리 fixed 값이 false라면, 그것은 유도된 추상적 정의 또는 멤버 선언에서 구체적 정의에 의해 번복될 수 있다.
NIL	종국적으로, 만약 설정 값이 값 ture인 속성 Nil을 가지고 있다면, 그 설정 값은 내용없이 유효하다고 여겨진다. 그렇게 레이블된 요소는 비어있어야 하나, 만일 설정 정의에 의해 허용되면 속성을 가질 수 있다.
Definition	definition 속성은 설정 정의에 대한 참조를 포함할 수 있다. 만약 그것이 제공된다면, 설정 값은 이 정의 안에서 타입이 정해진다. 만약 그것이 제공되지 않는다면, 패스의 양단에 있는 설정 선언의 설정 정의는 설정 값의 타입을 정하는데 사용된다.

3.2.6.2 설정 값 리스트

설정 값 리스트는 리스트로 선언된 설정에 대해 하나 또는 그 이상의 값을 제공하는데 사용된다. 상기 값을 선언할 때에, 사용자는 종전의 값과 합병할 것인지 아니면 모든 종전의 값들을 겹쳐쓸 것인지를 정할 수 있다.

속성/ 요소	설명
Path	이 값이 적용되는 설정 선언의 명칭
Fixed	fixed 속성은 제공된 값이 새로운 값에 의해 그 후에 번복될 수 있는지 여부를 제어한다. fixed 값이 true면 설정에 대해 제공된 값은 번복될 수 없음을 나타낸다. 만약 fixed 값이 구체적 정의 멤버의 설정 값에 대해 true라면, 그것은 그 멤버의 모든 배치에서 고정된다. 그와는 달리, 만약 fixed 값이 false라면 그것은 그 멤버의 각 배치에서 번복 가능하다. 만약 fixed 값이 구체적 정의의 설정 값에 대해 true라면, 그것은 그 구체적 정의의 모든 멤버(즉, uses)에 대해 고정된다. 그와는 달리, 만약 fixed 값이 false라면, 그것은 구체적 정의의 각 멤버(즉, use)에 따라 다르다. 만약 fixed 값이 추상적 정의의 설정 값에 대해 true라면, 그것은 그 추상적 정의를 확장하는 오브젝트를 구현하거나 추상화하는 구체적 정의에 대해 고정된다. 그와는 달리 fixed 값이 false라면, 그것은 유도된 추상적 정의 또는 멤버 선언에서 구체적 정의에 의해 번복될 수 있다.

3.2.7 설정 상속

설정 상속은 유도된 정의가 기본 정의에서의 모든 설정 선언을 암시적으로 포함하고 있음을 의미한다. 설정 상속의 몇 가지 중요한 측면은 다음과 같다.

설정 상속은 이행적(transitive)이다. 만약 C가 B로부터 유도되고, B가 A로부터 유도된다면, C는 A에 선언된 설정 뿐만 아니라 B에 선언된 설정을 상속한다.

유도된 정의는 그것이 확장하는 기본 정의로부터 상속하는 것들에 새로운 설정 선언을 추가할 수 있으나, 상속된 설정의 정의를 제거하거나 변경할 수 없다.

3.2.8 설정 인스턴스

인스턴스 스페이스에 있는 설정 인스턴스는 설정 멤버에 대한 실제 값을 가진다. 설정 인스턴스의 값은 초기에 정의 공간의 설정 값 문을 통하여 할당된다. 그리고 나서 플로우의 목적이 되는 설정 인스턴스에 대한 값을 업데이트하면서, 설정 플로우가 평가된다.

어떤 시나리오에서는, 설정 값 문으로부터 유도된 설정 값과 플로우를 통해 그 후에 제공된 값을 구별할 필요가 있다. 전자를 "할당된(assigned)" 값이라고 부르고, 후자를 "결과적인(resultant)" 값이라고 부른다.

3.2.9 값 전송(Value Transfer)

설정 값을 플로우 또는 제한 조건으로 또는 그로부터 전달하기 위해서는, 값 전송을 사용한다. 입력 전송은 멤버와 관련된 정의가 평가되기 전에 평가되고, 출력 전송은 멤버와 관련된 정의가 평가된 후에 평가된다.

각각의 값 전송은 Name 속성을 통하여, 입력에 대한 종착 또는 출력에 대한 원시 중 하나로서 사용되는 정의의 설정을 식별한다. path 속성은 입력에 대한 원시 또는 출력에 대한 종착이 되는 설정 선언을 식별한다.

3.2.9.1 입력

입력 문은 플로우 또는 제한 조건이 실행되기 전에 전달되는 입력 값을 식별한다. 입력은 "할당된" 아니면 "결과적인" 설정 값을 입력으로 사용할 것인지를 선택하기 위하여 ValuseScore 요소를 이용한다(할당된/결과적인의 정의는 섹션 XX에 있다).

3.2.9.2 출력

출력은 목적 값을 고정시키고 대체하는 의미(semantics)를 지원하는 값 전송에 대한 변동이다.

3.2.10 캐스팅(Casting)

우리는 설정 정의 상속 트리의 캐스팅 업 또는 다운을 지원한다. 원시 정의가 종착 정의로부터 유도될 때에는, 원시로부터 종착 정의로의 캐스트는 업캐스트(upcast)라고 불리운다. 종착 정의가 원시 정의로부터 유도될 때에는, 원시로부터 종착으로의 캐스트가 다운캐스트(downcast)라고 불리운다. 트리의 루트가 항상 Any 정의이기 때문에, 모든 정의는 Any로 업캐스트 될 수 있다.

도 16은 업캐스팅과 다운캐스팅의 예를 보여준다. 도 16에서, User 정의는 기본 정의 Any를 확장시킨다. ExtendedUser 정의는 이번에는 기본 정의 User를 확 장시킨다. 이러한 정의 계층을 생성함으로서, ExtendedUser 정의가 User 정의가 요청되는 어느 곳에서나 제공될 수 있고, ExtendedUser 및 User 정의가 Any 정의가 요청되는 어느 곳에서나 제공될 수 있다는 것을 나타낸다.

이하의 설정 선언문은 도 16의 정의를 이용하고, 이하 섹션의 예에서 사용될 것이다.

3.2.10.1 업캐스트

도 16에서, ExtendedUser 정의의 인스턴스가 User 또는 Any 중 하나의 정의를 요청하는 설정 선언에 할당되는 때에 업캐스트가 발생할 것이다. 업캐스트에 대한 하나의 예는 설정 선언 First로부터 설정 선언 Second로의 값 전송일 것이다. 이것은 플로우 입력 선언의 일부로서 발생할 수 있다.

업캐스트는 자동적으로 지원된다. 개발자 편에서 어떤 특별한 상호 작용의 필요 없이, 어떠한 값도 그것의 기본 정의 중의 하나로 캐스트될 수 있다. 설정 인스턴스가 업캐스트될 때, 실제 인스턴스 정의는 설정 값과 함께 보존된다.

3.2.10.2 다운캐스트

도 16에서, 다운캐스트는 사용자가 Any로 표시된 설정 선언에서 User로 표시된 설정 선언으로 설정 값을 전송할 때 발생한다. 이러한 경우에, 만약 인스턴스와 관련된 정의가 User 또는 ExtendedUser라면 단지 할당(assignment)이 발생할 수 있다. 이것은 설정 인스턴스가 현재 관련된 설정 선언과 다른 정의를 가질 수도 있음을 의미한다. 참조를 인스턴스 자체 주위의 실제 인스턴스 정의에 전달함으로써 인스턴스 스페이스에서 이것을 추적한다.

다운캐스트의 하나의 예는, 인스턴스가 초기에 First로부터 왔다는 것을 가정하고, Second로부터 Third로 설정 인스턴스를 전달할 때에 발생할 수 있다. 이러한 경우에, 설정 인스턴스는 ExtendedUser 정의의 인스턴스가 된다. 이러한 예는 설정 인스턴스가 플로우 정의 밖으로 전달될 때에 발생할 수 있다.

다운캐스트는 개발자에 의해 명시적으로 요청되는데, 만일 인스턴스의 런타임 정의가 목적 정의와 다르거나 그로부터 유도되지 않는 경우에 실패할 것이다. 다운캐스트를 요청하기 위해서는 개발자는 관련 전송 동작(입력 또는 출력) 상의 Cast 속성을 true로 설정한다. 캐스트가 요청된 경우, 만약 종착 정의가 출처 정의로부터 유도된 것이 아니라면 사용자는 컴파일 시간 에러를 수신하고, 만약 설정 인스턴스의 정의가 종착 정의와 동일하지 않거나 그로부터 유도된 것이 아니라면 런타임 에러를 수신할 것이다.

3.2.11 변환

사용자가 설정 인스턴스를 상기 인스턴스와 다른 정의를 가지는 설정 선언으로 전환하기를 바라고 상기 설정의 정의가 인스턴스의 정의의 기본 정의가 아닌 경우에 유형 변환이 요구된다.

도 17은 유형 변환의 일례를 도시한다. 도 17에 도시된 바와 같이, 유형 변환은 상속 구조의 상이한 가지에 속하는 정의 간에 발생하고 상속 구조의 동일한 가지 상에서 목적지 정의가 원시 정의보다 낮은 경우에 발생한다.

유형 변환은 설정 관리자에 의해 처리된다. 소스 및 목표 관리자 모두는 변환 지원을 노출할 수 있다. 이는 도 17의 상기 정의 및 User 정의로부터 String 정의로 할당이 주어진 경우, User를 위한 관리자가 String으로 변환을 노출할 수 있거나 String을 위한 관리자가 User로부터의 변환을 노출할 수 있다.

우선 런타임에 소스 관리자에게 상기 인스턴스의 변환을 요청하고, 다음으로 목표 관리자에게 요청한 후 마지막으로 이용 가능한 변환이 없을 경우에는 에러를 리턴한다.

유형 변환을 요청하기 위해 개발자는 전송 설정(입력 또는 출력) 상에서 Convert 속성을 참으로 표시한다. Convert가 지정되어 있지 않고 소스 정의가 동일하지 않거나 목표 정의로부터 상속된 것이 아닌 경우, 컴파일러는 에러를 리턴한다. Convert가 지정되어 있다면, 컴파일러는 두 개의 관리자에게 그들이 변환을 지원하는지 질의하여 두 유형 사이에서 이용 가능한 변환이 존재하는지 검사할 것이다.

인스턴스가 설정 선언과 연관된 정의의 파생인 정의인 경우에는, 고장시에 대한 조치로 업캐스팅하여 값을 변환하기 전에 우선 파생된 정의를 목적지 정의로 변환하려고 시도할 것이다. 만약 업캐스팅을 수행한다면 변환 과정의 일부로 정보를 잃을 수도 있음에 주의해야 한다. 예를 들어, User와 String 간의 변환을 지정하고 실제 인스턴스가 Extended User인 경우, User를 String으로 변환하기에 앞서 우선 ExtendeUser를 String으로 변환하기 위해 시도할 것이다.

3.2.12 CLR의 SDM형으로 사상

SDM 모델에서, 모든 설정 정의는 대응되는 CLR 형을 가진다. 이러한 유형은 SDM 모델에서 SettingDefinition 요소와 연관된 관리자에 의하여 정의된다.

플로우, 제한 조건 또는 배치 관리자가 SDM 정의를 대신하여 동작하는 경우, SDM 설정 정의의 인스턴스 상에서 보다는 CLR 형의 인스턴스 상에서 동작함으로써 작업을 수행한다. 이는 개발자에게 보다 자연스러운 프로그래밍 모델을 제공할 뿐만 아니라, SDM 런타임이 SDM 런타임으로부터 관리자에게 정보를 넘겨주기 위하여 SDM 정의를 CLR 형으로 사상할 수 있어야 하며 관리자로부터 정보를 되돌려 받기 위해 CLR 형을 SDM 정의로 사상할 수 있어야 함을 의미한다.

예를 들어, 일 SDM 모델에서, 개발자는 다음의 설정 정의를 정의할 수 있다.

그 후에 개발자는 다음의 CLR 형의 인스턴스를 생성하는 설정 정의와 연관된 값을 처리하는 관리자를 기록할 수 있다.

상기 문제에는 두 가지 부분이 존재한다. 첫 번째는 정의를 유형으로 및 그 반대로 사상할 수 있는 것이고, 두 번째는 SDM 인스턴스를 CLR 인스턴스로 및 그 반대로 사상할 수 있는 것이다.

3.2.12.1 정의를 유형으로 사상하기

설정 정의를 CLR 형으로 사상하기 위하여 관리자 선언, 설정 정의 이름 공간(setting definition namespace) 및 설정 정의 이름을 사용한다. SettingDefinitions 요소 상의 Manager 속성에 의하여 지정된 관리자 선언으로부터 유형을 포함하는 어셈블리를 위한 강한 이름 및 위치를 얻을 수 있고, SettingDefinitions 요소 상의 ClrNamespaceName으로부터 유형을 포함하는 이름 공간의 이름을 얻을 수 있다. 결국, 어셈블리로부터 CLR 형을 회복하기 위하여 이름 공감의 이름에 설정 정의의 이름을 덧붙일 수 있다.

반대 과정은 CLR 형으로부터 SDM 정의로 사상하기 위하여 동일한 정보를 사용한다. 첫번째로, 런타임에 의해 제공되는 유형 정보로부터 어셈블리 이름을 얻는다. 그 후에 어셈블리를 참조하는 관리자 선언을 찾는데, 이는 우리에게 하나 이상의 모델 파일을 부여한다. 모델 파일 내의 설정 정의 부분으로부터 이름 공간 이름과 유형 이름의 대응되는 쌍을 찾는다.

3.2.12.2 인스턴스 값을 변환하기

XML로 표시된 SDM 표현으로부터 Clr 개체 인스턴스로 또는 그 역으로 설정 인스턴스를 변환하기 위하여, 다시 SettingDefinitions 요소와 연관된 관리자를 사용한다. 이 경우, 번역을 구현하는 Clr 클래스는 Manager 속성에 의해 구분되는 관리자 선언으로부터의 어셈블리 정보 및 ClrClassName 속성의 조합에 의하여 구분된다.

Clr 클래스는 관리자 인터페이스 사양(Manager Interface Specification)에 기술된 ISettingSerialization 인터페이스를 구현한다. 상기 인터페이스는 SDM의 Xml 표현으부터 Clr 인스턴스로의 변환 및 Clr 개체 인스턴스로부터 SDM의 Xml 표현으로의 변환 모두를 지원한다. Model 파일 내의 설정 정의를 생성하는 동일한 개발자가 변환을 수행하는 코드를 작성할 책임을 진다.

Clr 클래스는 SettingDefinitions 요소 내의 모든 설정 정의에대한 변환을 지원해야 한다.

3.3 속성

SDM 내의 다수의 개체는 개체의, 주요 실행에 직교하는(orthogonal) 실행을 획득하도록 속성이 결정될 수 있다. 우리는 다음과 같이 정의된 일반적인 속성 모델을 사용한다.

3.4 정의

정의는 리소스 및 시스템의 재사용 가능한 설정을 생성하기 위해 사용된다. 이는 개체 지향 언어에서 클래스와 유사하다.

3.4.1 정의

정의는 개체, 관계, 제한 조건 및 플로우 정의가 파생되는 기본이다. 모든 정의는 설명, 설정 멤버, 설정 값 및 디자인 표면 데이터를 포함할 수 있다. 각 정의는 간단한 이름에 의하여 구분되고 관리자를 참조한다. 상기 관리자는 정의에 의하여 구분되는 클래스간에 특별한 정의를 위하여 SDM 런타임을 지원하는 기능을 제공해야 할 책임이 있다.

정의의 이름은 상기 정의를 포함하는 범위 내의 모든 정의에 대하여 유일해야 한다. 상기 범위는 SDM 문서 또는 다른 정의가 될 수 있다.

3.4.2 개체 정의

추상 개체 정의는 일 단의 설정 선언을 포함하고, 자신이 참여하는 관계에 대한 제한 조건을 포함할 수 있으며, 런타임에 연관된 관리자를 가질 수 있다.

다음은 웹 서버를 위한 추상 시스템 정의이다. 상기 웹 서버는 두 개의 설정을 가지고 있고, 적어도 자신이 vsite 유형에 포함할 것을 요구하는 관계 제한 조건을 가진다.

상기 vsite는 서버 바인딩 정보를 포함하는 추상 종단점 정의(abstract endpoint definition)다.

전단 웹서버(frontend webserver)를 위한 구체적인 시스템 정의는 웹서버 범주를 정적인 콘텐츠로 구분하고, 1에서 100 종단점 인스턴스 사이를 나타낼 수 있는 하나의 참조 종단점 멤버(byReference endpoint member)을 포함한다. 종단점을 위한 구체적인 종단점 정의는 시스템 정의 내에 내포되고 vsite가 종단점 80이 되도록 ip 종단점을 정의한다.

3.4.2.1 개체 정의

추상적 및 구체적인 개체는 다음의 기본 개체 정의를 확장한다. 기본 유형인 정의 요소에 부가하여, 요소들은 개체가 참여하는 관계를 제한하는 능력을 공유한다.

추상 개체 정의는 디자인 표면이 노출하고, 모든 구체적인 개체가 파생된 구성 요소(building block)를 정의하기 위해 사용된다. 즉, 구체적인 개체 정의는 추상 개체 정의를 구현한다.

추상 개체 정의는 간단한 상속을 추가함으로써 SDM 개체를 확장한다. 즉, 추상 개체 정의에 대하여 기본 개체 정의를 구분하기 위해 "extends" 속성이 사용된다. 추상 개체 정의는 기본 개체 정의로부터 설정 및 관계 제한 조건을 상속받는다. 상속을 통해서, 개체 정의는 새로운 설정 및 제한 조건을 추가함으로써 추상 개체 정의의 설정 및 제한 조건을 확장할 수 있다.

또한 추상 개체 정의는 자신이 참여하고자 하는 관계에 제한 조건을 부가할 수 있다. 예를 들어, 추상 개체 정의는 특정 관계의 존재를 요구하거나, 관계의 다른 종단점에 존재하는 개체 정의를 제한하거나 또는 주어진 관계에 참여하는 인스턴스에 대한 설정을 제한할 수 있다.

또한 개체 정의는 내포된 정의의 선언을 포함할 수 있다. 이러한 정의는 포함된 정의의 범위 내에서는 멤버를 위해 사용될 수 있고, 정의의 범위 밖에서는 제한 조건에서 참조될 수 있다.

구체적인 개체 정의는 추상 개체 정의를 위한 구현을 제공한다. 구현은 개체, 관계 멤버, 구현된 추상 정의의 설정을 위한 값, 새로운 설정 선언 및 멤버과 멤버에 대한 제한 조건 사이의 플로우으로부터 생성된다.

3.4.2.2 묵시적 기본 정의

다른 개체 정의를 확장하지 않는 모든 개체 정의는 묵시적으로 종단점, 시스템 또는 리소스 기본 정의들 중의 하나를 확장한다. 이러한 기본 정의는 관계 및 제한 조건 선언에서 사용될 수 있는 각각의 트리(tree)의 근원을 형성한다. 이는 관계 또는 제한 조건이, 근원으로 부터 파생된 임의의 유형이 구분된 근원 정의의 위치에서 사용될 수 있음을 나타내는 것을 가능하게 한다. 이러한 근원 유형은 언 제나 추상적이고 직접 인스턴스화 할 수 없다.

이러한 유형의 정의는 모델 내의 그들의 인스턴스화를 통제할 수 있는 기본 제한 조건을 포함한다.

3.4.2.3 종단점 정의

종단점 정의는 내포된 리소스 유형, 리소스 멤버과 호스트, 포함 및 참조 관계 멤버를 선언할 수 있는 능력을 추가함으로써 기본 개체 정의를 확장한다.

3.4.2.4 시스템 정의

시스템 유형은 내포된 종단점, 시스템, 리소스 유형, 종단점, 시스템, 리소스 멤버, 호스트, 포함, 연결, 위임 및 참조 관계에 대한 지원을 추가함으로써 기본 유형을 확장한다.

3.4.2.5 리소스 정의

리소스 유형은 내포된 리소스 유형 정의, 리소스 멤버, 호스트, 포함 및 참 조 관계 멤버를 포함할 수 있다.

3.4.2.6 관계 규칙

개체 정의의 특별한 인스턴스에 대하여 다음 테이블은 인스턴스가 수행할수 있는 각각의 역할과 연관된 카디널리티(cardinality)를 구분한다.

3.4.2.6.1 시스템 규칙

3.4.2.6.2 종단점 규칙

3.4.2.6.3 리소스 규칙

3.4.2.6.4 주의

모든 인스턴스는 정확히 하나의 포함 관계 및 적어도 하나의 호스팅 관계에 참여해야 한다.

이는 다음을 의미한다.

A) 참조형이 아닌(값에 의한) 멤버들은 동일한 정의에서 포함 관계를 구분해야 한다.

B) 생성되기 위해서 참조 멤버는 포함 관계를 구분해야 한다.

3.4.3 관계 정의

관계는 유형 간의 가능한 상호작용을 구분하기 위하여 사용된다. 관계는 이진으로써 방향성을 가지는데(binary and directed), 각각은 관계에 참여할 수 있는 인스턴스의 유형을 구분한다. 관계는 또한 관계에 참여하는 인스턴스의 설정을 제한할 수 있고 관계를 가로질러 설정 값을 흐르게 할 수 있다.

다음은 유형 부분에서 기술된 웹 서버상의 웹 응용프로그램에 대한 가능한 호스팅 관계이다. 관계는 두 시스템의 보안 모델이 양립가능하고 vsite로부터 vdir로 서버의 이름을 복사하는 플로우 멤버(flow member) 설정을 포함할 것을 확인하는 제한 조건을 포함한다.

관계는 관계에 참여하는 유형 멤버를 구분하는 관계 멤버를 선언하는 방법으 로 사용된다.

3.4.3.1 관계 정의

기본 관계 정의는 정의들에 개체 제한 조건 및 플로우를 부가한다. 개체 제한 조건은 본 관계의 인스턴스에 참여하는 개체 인스턴스에 대한 설정값에 관한 서술이다. 예를 들어, DCOM 연결을 나타내는 통신 관계는 클라이언트와 서버에 대한 보안 설정이 양립 가능한가를 검사할 것이다. 이 경우, 디자인 과정의 일부로써 쉽게 획득할 수 있는 설정 간의 엄격한 관계가 존재한다. 즉, 관계에 대한 4 계승 조합이 존재하는데, 훨씬 더 적은 수의 유효한 조합이 존재할 수 있다.

플로우는 관계 개발자가 하나의 인스턴스로부터 다른 인스턴스로 값을 전달할 수 있는 능력을 부여한다. 이는 개체 정의가 그들의 가능한 상호 작용과 분리하여 개발될 수 있도록 하고, 인스턴스가 특정한 인스턴스를 완전히 기술하기 위하여 관계 그래프의 부집합(subset)을 요구하기보다 정보에 대한 참조점(reference point)으로서 독립적일 수 있도록 한다.

구체적인 관계는 두 개의 구체적인 개체 정의간의 관계이다. 각 구체적인 관계는 추상 관계를 구현해야 한다. 추상 관계는 직접 또는 간접적으로(상속을 통해) 구체적인 개체 정의에 의하여 구현되는 추상 개체 정의의 대응되는 쌍 사이에 존재해야 한다.

관계의 이름은 관계를 포함하는 이름 공간 내에서 유일해야 한다.

3.4.3.2 통신 관계

통신 관계는 종단점 정의 간에 가능한 통신 연결을 획득하기 위하여 사용된다. 상기 관계는 독립적으로 배치된 소프트웨어 요소들 간의 상호 작용을 기술하기 위하여 사용된다. 통신 관계 스키마는 클라이언트 및 서버 종단점 참조를 추가함으로써 기본 관계 스키마를 확장한다.

다음 추상 유형 쌍들(abstract type pairs)의 조합이 통신 관계에 대하여 유효하다.

3.4.3.3 호스팅 관계

호스팅 관계는 게스트에 의하여 호스트가 생성될 것을 요구한다는 사실을 획득하기 위하여 사용된다. 게스트에 대하여 하나 이상의 가능한 호스트가 존재할 수 있는데, 이는 호스팅 관계의 책임으로 호스트 상에 게스트를 생성함을 의미한다. 따라서, 개체의 인스턴스를 생성하기 위하여, 호스팅 관계는 게스트로부터 양립 가능한 호스트로 향해야 한다.

예를 들어, 호스팅 관계는 웹서비스 개체 정의와 IIS 개체 정의 사이에 존재 할 수 있다. 이 경우, 상기 관계는 MyWebservice 및 MyIIS가 각각 웹서비스 및 IIS를 구현하고 있다고 가정하면 호스팅 관계 상에서 관리자를 이용하여 MyIIS 시스템의 인스턴스 상에 MyWebservice 시스템의 인스턴스를 생성하는 것이 가능함을 나타낸다. 시스템 및 관계 상에 존재하는 제한 조건을 평가할 때까지 관계를 생성하는 것이 가능한지 알지 못한다.

애플리케이션을 데이터센터에 배치할 때, 애플리케이션 내의 시스템에 대한 모든 현저한 호스팅 관계를 분석해야 할 필요가 있다. 이를 수행하기 위해, 작업자는 필요로 하는 각 호스팅 관계에 대하여 호스팅 멤버를 생성할 필요가 있을 것이다. 작업자의 업무를 단순화하고 개발자가 배치 과정을 이끌 수 있도록, 개발자는 대신 구체적인 호스팅 관계를 생성할 수 있다. 구체적인 호스팅 관계는 작업자가 애플리케이션을 배치할 때 하나의 호스팅 멤버만을 선언할 필요가 있는 방법으로 일 단의 호스팅 관계 멤버들을 분류하기 위하여 사용된다.

게스트 내의 각 게스트 멤버에 대하여 호스트 내에 하나 이상의 호스트 멤버가 존재할 때 게스트는 호스트에 결합될 수 있는데, 이 경우 게스트 멤버의 유형은 호스트 멤버의 유형과 호스팅 관계를 가지고, 게스트 멤버의 호스트 제한 조건은 호스트 멤버의 설정에 대하여 유효성을 판단하며, 호스트 멤버의 게스트 제한 조건은 게스트 멤버의 설정에 대하여 유효성을 판단하고, 게스트 멤버의 각각의 멤버에 대하여 호스트 멤버의 멤버에 결합이 존재한다.

예를 들어, 다음의 구체적인 관계는 계층 3 시스템(자전거)을 계층 2 호스트(작업 시스템)에 결합시킨다. 이 경우, "시스템 폴더"의 기본 값에 호스팅 관계에 대한 설정을 정의한다. 우리는 상기 설정을 계층 3 애플리케이션의 시스템과 계층 2 호스트의 시스템 간에 호스팅 관계를 정의하는 세 호스팅 멤버 가운데 하나에 돌려 보낸다.

추상 정의 쌍의 다음 조합들은 호스팅 관계에 대하여 유효하다.

3.4.3.4 포함 관계

두 개의 추상적인 개체 간의 포함 관계는, parentType에 기반한 구체적인 유형이 memberType에 기반한 멤버를 포함할 수 있다는 사실을 획득한다. 포함은 부모 인스턴스가 멤버 인스턴스의 수명을 제어할 수 있고 행위를 멤버 인스턴스에 위임할 수 있음을 의미한다.

추상 정의 쌍의 다음 조합들은 포함 관계에 대하여 유효하다.

3.4.3.5 위임 관계

위임은 외부 시스템으로부터 포함된 시스템으로 행위를 전달하기 위하여 사 용된다. 외부 시스템 상의 종단점을 내부 시스템 상의 종단점에 위임하는 방법으로 상기 작업을 수행한다. 이러한 방법은 외부 시스템으로 지시되었을 모든 상호 작용을 내부 시스템 상의 종단점에 효과적으로 전달한다. 위임은 연쇄될 수 있는데, 이는 내부 시스템이 다른 시스템에게 자신의 행위를 다시 위임할 수 있도록 한다.

위임 관계는 위임에 참여할 수 있는 추상 종단점 정의의 쌍을 정의한다. 각각의 관계는 프락시 및 행위를 위임할 수 있는 추상 종단점 정의로서 역할을 수행할 수 있는 추상적인 종단점 정의를 구분한다.

리소스 및 시스템 위임이 계층 간의 바인딩을 지원하는 것을 허용할 수 있다. 예를 들어, IIS가 파일 시스템을 배치할 필요없이 파일 시스템의 일부를 노출하는 것을 허용할 수 있다.

우리는 호스팅 관계 종속성에 부가되는 인스턴스 간의 강한 종속성을 획득하기 위하여 참조 관계를 사용한다. 이러한 종속성은 배치 동안의 생성 순서 및 설치 및 업데이트 동안의 시스템 간 플로우 매개 변수를 제어하기 위하여 사용된다. 참조 관계는 강한 종속성을 나타내기 때문에, 시스템 경계를 넘는 참조 관계를 허용할 수 없다. 이는 한 시스템 내의 리소스는 다른 시스템 내의 리소스에 종속성을 가질 수 없음을 의미한다. 이는 시스템을 더 이상 배치에 대하여 독립적 유닛이 아니도록 한다. 시스템 간에 종속성이 존재하는 경우, 우리는 통신 관계를 사용한다. 통신 관계는 시스템의 재설치 없이 시간에 따라 변경할 수 있다.

3.4.3.6 참조 관계

우리는 호스팅 관계 종속성에 부가되는 인스턴스 간의 강한 종속성을 획득하기 위하여 참조 관계를 사용한다. 이러한 종속성은 배포 동안의 생성 순서 및 설치 및 업데이트 동안의 시스템 간 플로우 매개 변수를 제어하기 위하여 사용된다. 참조 관계는 강한 종속성을 나타내기 때문에, 시스템 경계를 넘는 참조 관계를 허용할 수 없다. 이는 한 시스템 내의 리소스는 다른 시스템 내의 리소스에 종속성을 가질 수 없음을 의미한다. 이는 시스템을 더 이상 배포에 대하여 독립적 유닛 이 아니도록 한다. 시스템 간에 종속성이 존재하는 경우, 우리는 통신 관계를 사용한다. 통신 관계는 시스템의 재설치 없이 시간에 따라 변경할 수 있다.

추상 유형 쌍의 다음 조합들은 참조 관계에 대하여 유효하다.

3.4.3.7 묵시적 기본 관계

모든 추상 관계는 묵시적으로 하나의 기본 관계 정의를 확장한다. 이러한 정의는 각각의 관계 트리의 근원을 형성한다. 도 18은 관계 트리의 예를 도시한다. 본 방법에 의해, 제한 조건 정의 내에서 근원 정의를 참조할 수 있고, 근원 유형으로부터 공통 유형 제한 조건을 상속할 수 있다.

3.5 멤버들

3.5.1 멤버

멤버는 런타임에 생성될 수 있는 특정 정의의 인스턴스를 구분하기 위하여 사용된다. 모든 멤버들은 멤버를 포함하는 정의의 영역 내의 멤버 집합 내에서 유일한 이름으로 구분된다. 멤버는 자신이 참조하는 정의에 대한 설정을 제공할 수 있다. 또한 디자인 표면 특정 데이터(design surface specific data)를 포함할 수 있다.

속성/요소	설명
Description	멤버들의 설명
DesignData	멤버에 대한 디자인 표면 특정 정보
SettingValue	참조 유형에 관한 기록 가능한 설정에 대응되는 설정을 위한 값. 본 값이 고정된 것으로 표시된 경우, 인스턴스가 멤버에 대하여 생성될 때 사용되어야 하고, 값이 고정되지 않은 경우에는 배치 또는 유입된 매개 변수에 의해 상기 값들을 재정의할 수 있다.
SettingValueList	참조 유형에 대한 기록 가능한 목록 설정을 위한 값들의 목록.
Name	포함하는 유형의 범위 내에서 멤버를 위한 유일한 이름.
Definition	본 멤버가 참조하는 정의의 이름.
Visibility	가시성 속성은 멤버가 public 또는 private인지를 나타나기 위하여 사용된다. 그것이 private이라면 상기 멤버를 포함하는 정의 안으로 부터만 참조될 수 있다. 그것이 public이라면 정의 밖으로부터 참조될 수 있다. 기본 행위는 정의 상의 가시성 속성에 의하여 정의된다.

3.5.2 개체 멤버

개체 멤버는 추상적 또는 구체적인 개체 정의 중 하나를 참조해야만 한다. 개체 멤버들은 배열의 상위 및 하위 경계를 정의할 수 있는 인스턴스의 배열을 나타낼 수 있다. 그들이 참조 멤버는, 개체를 초기화하는 사용자는 명시적으로 멤버에 대한 인스턴스를 생성해야 한다. 그들이 참조 멤버가 아니라면, 런타임은 외부 개체가 생성되는 것과 동시에 인스턴스를 생성할 것이다.

SDM 모델에서, 부모가 생성될 때 생성되고 부모가 소멸할 때 소멸되는 멤버들을 부모와 독립하여 수명을 가지는 것들과 구별해야 할 필요가 있다. 우리는 이러한 목적으로 IsReference 속성을 사용한다. 간단한 유사예가 C++ 선언에 있어서 인스턴스를 생성하기 위하여 "new"가 사용될 것인지에 근거한 스택 기반 또는 힙 기반 생성을 허용하는 것이다. 멤버가 IsReference로 표시된 경우에는, 인스턴스를 생성하고 그를 멤버과 연관시키기 위한 연산자의 일부로 명시적인 새로운 연산이 필요하다.

우리가 상기의 작업을 수행하는 다음과 같은 다수의 이유가 존재한다.

1. 작업자가 시스템을 생성할 때, 오직 참조형 멤버를 생성할 능력만을 노출한다. 이는 작업자 경험을 크게 단순화시킨다.

2. SDM 문서를 처리할 때, 문서의 인스턴스 스페이스가 구체적인 정의 공간 의 경계와 구별될 수 있는 명확한 경계를 가진다.

3.5.3 관계 멤버

관계 멤버들은 개체 멤버들이 생성될 때 개체 멤버 간에 존재하는 관계를 구분한다. 관계 인스턴스들은 작업자에 의해 명시적으로 생성되거나 런타임에 묵시적으로 생성된다. 전자의 예는 인스턴스들간의 호스팅 관계이고, 후자의 예는 시스템 간의 통신 관계이다.

3.5.4 종단점 멤버

3.5.5 시스템 멤버

3.5.6 리소스 멤버

3.5.7 호스팅 멤버

호스트 멤버들은 두 개체 멤버 간에 호스팅 관계를 선언하기 위하여 사용된다. 개체 멤버는 포함하는 정의의 직접적인 멤버이거나 정의와 멤버 관계를 가지는 내포된 멤버일 수 이다. 참조된 멤버과 포함하는 정의 간에 멤버 연결 사슬(membership chain)이 존재해야 한다.

3.5.8 통신 멤버

통신 멤버는 정의의 인접한 시스템 멤버들의 종단점 멤버 간에 통신 관계를 선언하기 위하여 사용된다.

3.5.9 포함 멤버

포함 멤버는 유형 멤버가 상기 유형에 의해 포함되었음을 선언하기 위하여 사용된다. 각각의 유형 멤버는 포함되거나 또는 위임될 수 있다. 포함 멤버는 자동으로 포함 관계의 부모 값을 상기 관계의 본 포인터가 되도록 설정한다.

3.5.10 위임 멤버

위임 멤버는 외부 유형 상의 종단점 정의 멤버과 외부 유형의 인접 시스템 멤버 상의 종단점 정의 멤버 간에 위임 관계를 설정하기 위하여 사용된다.

3.5.11 참조 멤버

참조 멤버는 외부 정의의 인접한 또는 내포된 멤버들 간에 참조 관계를 설정 하기 위하여 사용된다.

3.6 플로우

설정 플로우는 개체 정의의 멤버 사이와 관계 내의 참여자간의 파라미터를 전달하는 데 사용된다. 플로우의 부분으로서, 사용자는 변환(transformation)을 사용하여 설정 값을 결합하거나 분리하고 새로운 설정 값을 산출한다.

모든 설정 플로우 멤버가 플로우 정의를 사용하여 변환을 구현한다. 플로우 정의는 SDM 파일 내에서 선언된다. 다음은 url을 구문 분석(parse)하는 플로우 유 형이다.

플로우 멤버는 그후 개체 또는 관계 내에서 선언된다. 플로우 멤버는 플로우 정의에 대한 입력을 제공하고 그후 플로우로부터 목적 설정으로 출력을 보낸다.

3.6.1 플로우 정의

우리는 플로우 정의를 사용하여 우리가 설정 값의 세트에 적용하고자 하는 특정 변환을 정의한다. 플로우 정의는 입력 설정(기록 전용 설정) 및 출력 설정(판독 전용 설정)을 정의하는 설정 스키마, 변환을 정의하는 입력 인터페이스 등의 설계 표면 특정 정보에 대한 설계데이터 섹션 및 SDM 파일을 브라우징(browsing)할 때 사용하기 위한 설명을 노출시킨다. 플로우 정의는 그것이 정의되는 이름 공간 내의 이름에 의해 식별된다. 정의는 또한 플로우를 평가할 때 런타임을 지원하는 관리자를 식별한다.

우리는 런타임이 몇개의 표준 플로우 정의를 포함하여 직진 변환이 요구되는 플로우 요소의 구성을 간략화시키는 것을 예상한다. 예는 카피, 병합 및 스트링 대입(substitution)을 포함할 수 있다. 플로우 정의가 파라미터화될 수 있으므로, 우리는 또한 구성 파라미터에 기초하여 다른 액션을 수행하는 간단한 하나 이상의 변환이 있음을 예상한다.

3.6.2 플로우 멤버

각각의 플로우 요소는 하나 이상의 소스 노드, 하나 이상의 목적지 노드, 임 의의 정적 설정 및 플로우 정의를 식별한다, 플로우가 평가될 때, 소스 데이터는 소스 노드로부터 수집되고 플로우 요소로부터의 설정과 결합되고 변환을 위한 플로우 정의로 전달된다. 출력 데이터는 정의 노드로 전달된다.

플로우의 재평가는 소스 값 중의 어느 하나가 변경될 때마다 트리거될 것이다. 이때문에, 우리는 값을 플립플롭하는 순환 플로우를 회피할 필요가 있다. 값이 일정한 채로 유지되면, 루프는 종료할 것이다. 런타임은 스택 깊이의 추적을 유지하면서 무한 루프를 검출하고 종료할 것이다.

제한 조건은 정의의 멤버의 설정 값 또는 관계 내의 참여자에 대한 한정을 식별하는 데 사용된다. 이들 한정은 설계 시간 및 배치 시간에 인스턴스 스페이스 내에서 평가된다.

3.7 제한 조건

제한 조건은 정의의 멤버의 설정 값 또는 관계 내의 참여자에 대한 한정을 식별하는 데 사용된다. 이들 한정은 설계 시간 및 배포 시간에 인스턴스 스페이스 내에서 평가된다.

모든 설정 제한 조건은 제한 조건 정의를 사용하여 설정 값을 평가한다. 제한 조건 정의는 설정 선언을 사용하여 그것이 제한하는 값을 식별한다. 다음의 제한 조건 정의는 2개의 독립 변수(argument) 및 연산자를 취하는 간단한 비교 함수를 구현하고, 그후 제한 조건을 평가하고 마지막으로 성공 또는 에러를 리턴한다.

제한 조건 멤버는 평가에 대한 제한 조건 타입에 값을 제공하는 데 사용된 다.

3.7.1 제한 조건 정의

제한 조건 정의는 입력 값의 세트에 동작하는 제한 조건을 정의한다. 제한 조건은 파라미터화되어 고객 행동을 선택하거나 파라미터를 사용하여 그 행동을 정의하는 간단한 제한 조건 엔진에 대하여 지원할 수 있다. 우리는 표준 제한 조건 정의의 세트가 간단한 파라미터 값 제한 조건 및 컴플렉스 제한 조건의 세트에 대하여 기록되어 추상 개체 사이의 공지된 관계를 지원하는 것을 예상한다.

3.7.2 제한 조건 멤버

제한 조건 멤버는 특정 제한 조건 정의에 대한 입력 값의 세트를 식별한다. 멤버는 설정 값에 대한 정적 값을 식별할 수 있고 입력 명령문을 사용하여 경로에 제한 조건 설정을 결합시킬 수 있다.

3.7.3 구조 제한 조건

우리는 특정 관계에 사용될 때 개체 및 관계 제한 조건을 사용하여 구체적 공간의 지형을 정의하고 개체의 설정을 제한한다.

예를 들어, 추상 개체 정의(A)내에서, 우리는 이 추상 정의의 구현이 또다른 추상 개체 정의(B)의 하나의 인스턴스를 포함해야 한다는 것을 식별하기를 원한다. 하나 이상의 적절한 포함 관계가 이미 존재하는 것을 가정하면, 이것을 수행하기 위하여, 우리는 다음과 같이 보이는 A 내의 관계 제한 조건을 사용한다.

제한 조건은 A의 구현이 부모의 역할을 하고 관계의 다른 엔드에서의 타입이 타입 B인 포함 관계가 존재함을 식별한다. 우리가 B의 구성을 통해 더 많이 제어하기를 원하면, 우리는 다음과 같이 타입 B의 설정에 대한 제한 조건을 부가할 수 있다.

이 경우, 우리는 스트링 "myPort"와 동일하도록 멤버의 이름을 요구한 제한 조건을 부가한다.

우리는 또한 관계에 제한 조건을 부가할 수 있고; 우리는 이들 개체 제한 조건을 호출할 수 있다. 관계로부터, 우리는 관계에 참여한 개체를 제한한다. 관계 내의 각각의 역할에 대하여, 우리는 개체 정의를 식별할 수 있고 그 개체 정의에 설정 제한 조건을 부가할 수 있다. 그 관계로부터, 카디널리티(cardinality)는 항상 minOccurs=1 및 maxOccurs=1이고, 그래서, 이것은 제한 조건 선언에 나타나지 않는다.

마지막으로, 우리는 제한 조건을 내포할 수 있다. 이것은 함께 제한 조건을 체인할 수 있는 능력을 제공하고, 외부 제한 조건은 내부 제한 조건에 대한 컨텍스트를 설정한다. 다음은, webApp를 특정 타입의 포함 종단으로 제한하는 webapp 시스템을 호스트하는 IIS 시스템의 일예이다.

이 경우, 우리는 하나 이상이 참이어야 하는 가능성의 세트를 지정하기 위하 여 개체 제한 조건의 그룹을 사용한다.

foo의 관점으로부터, 다음의 2개의 시나리오는 동등하다. 제 1 foo는 포함된 시스템 바 상의 내포된 제한 조건을 배치하고, 제 2 foo에서는, 타입 바가 이미 제한 조건을 포함한다.

내포된 제한 조건은 외부로부터 평가할 수 있는 경로를 형성한다. 경로 상의 각각의 제한 조건은 현재의 인스턴스 뿐만 아니라 경로 상의 이전의 인스턴스의 설정을 액세스할 수 있다. 내포된 제한 조건의 평가는 마치 제한 조건이 식별된 시스템 내에 정의된 것처럼 수행된다.

foo의 관점으로부터, 다음의 2개의 시나리오는 동등하다. 제 1 foo는 포함된 시스템 바 상의 내포된 제한 조건을 배포하고, 제 2 foo에서는, 타입 바가 이미 제한 조건을 포함한다.

시나리오 1:

시나리오 2:

3.7.3.1 제한 조건 모델

제한 조건 모델에 2개의 부분, 즉 가드(guard)와 프리디케이트(predicates)가 있다. 우리는 가드를 사용하여 프리디케이트를 실행하는 컨텍스트를 정의한다. 예를 들어, 관계 내에서, 우리는 가드를 사용하여 프리디케이트를 실행하기를 원하는 타입의 특정 조합을 식별한다. 개체 내에서, 우리는 가드를 사용하여 다른 개체에 대한 관계의 세트를 식별한다.

프리디케이트는 그 가드의 요구사항이 충족되면 실행된다. 우리는 프리디케이트의 2가지 형태를 갖는다: 설정 값을 유효화하는 설정 제한 조건 및 제한 조건의 세트를 유효화하는 그룹 제한 조건.

우리는 가드 내에 가드를 내포할 수 있고, 이 경우, 내부 가드는 외부 가드가 만족하면 검사된다. 이것은 관계 구조의 검증을 지원하는 경로를 작성하도록 한다.

가드와 그 프리디케이트의 조합은, 횟수를 나타내고 가드가 매칭되어야 하고 프리디케이트가 참으로 평가되는 카디널리티를 가질 수 있다.

더 형식적으로,

가드는 ObjectConstraint 또는 RelationshipConstraint로서 정의된다. 개체 제한 조건은 관계의 엔드에 관련된 2개의 개체 정의를 식별한다. 관계 제한 조건은 관계 정의와 목적 개체 정의를 식별한다. 개체 제한 조건은 선택적이거나 요구될 수 있고, 관계 제한 조건은 하한 및 상한을 갖는다. 이것은 관계가 2개의 타입을 식별할 수 있지만, 타입은 다수의 관계에 참여할 수 있다는 사실을 반영한다는 점에서 카디널리티와 다르다.

프리디케이트는 규칙을 포함하는 설정 제한 조건과 가드의 세트를 포함하는 그룹중의 하나이다. 프리디케이트는 가드의 컨텍스트 내에서 평가된다. 설정 제한 조건의 경우, 프리디케이트는 루트 가드의 소유자 및 각각의 내포된 가드에 의해 식별된 컨텍스트로부터 설정을 식별할 수 있다. 그룹은 하나 이상이 매칭하고 참으로 평가되는 가드의 세트를 식별하는 데 사용된다.

예:

이 예는 webapp에 대한 제한 조건 관계가 있을 때마다 참으로 평가하는 가드를 나타낸다. 이 가드는 최대 한번 참으로 평가할 수 있다. 또한 매칭은 사용자 에게 에러를 리턴하도록 한다.

이 예는 가드에 프리디케이트를 부가한다. 가드는 관계와 목적 정의가 매칭하고 설정 제한 조건이 참으로 평가될 때 단지 참으로 평가될 것이다. 관계와 목적 정의가 매칭하고 설정 제한 조건이 참이 아니면, 에러가 사용자에게 리턴된다. 관계와 목적 타입이 매칭하고 설정 제한 조건이 한번 이상 참으로 평가되면, 에러가 사용자에게 리턴된다.

이 예에서, 우리는 가드 내에 가드를 내포한다. 외부 가드가 참이면(제한 조건을 포함하는 타입이 webapp를 포함하면), 우리는 외부 가드 내의 컨텍스트 내의 내부 가드를 평가한다. 이것은 내부 관계 제한 조건이 webapp 인스턴스의 컨텍스트 내에서 평가되는 것을 의미한다. webApp가 0 또는 1의 vdirs를 포함하면, 내부 제한 조건은 참을 리턴하고, 1보다 큰 vdir을 포함하면, 제한 조건은 사용자에 게 에러를 리턴한다.

개체 제한 조건의 컨텍스트는 주요 개체 정의(제 1 개체 정의)이다. 이것은 관계 제한 조건은 webapp의 컨텍스트 내에서 평가되는 것을 의미한다. 관계 제한 조건은 2개의 가능한 컨텍스트를 정의하고, 제1컨텍스트는 개체 제한 조건을 위한 컨텍스인 관계이고, 제2컨텍스트는 관계 제한 조건을 위한 컨텍스트인 목적 개체 정의이다.

3.7.3.2 기본 제한 조건

모든 구조적 제한 조건은 StructuralConstraint라고 불리는 공통의 기본 제한 조건으로부터 유도된다. 각 구조적 제한 조건은 기술 엘리먼트(description element) 및 설계 데이터 모두를 포함할 수 있다. 이러한 기술 엘리먼트는 필요한 제한 조건에 맞지 않으면 에러 메시지로서 복귀될 것이다. 또한, 각각의 제한 조건은 이름, 및 이러한 제한 조건이 필요한지 또는 단지 보다 큰 제한 조건의 부분 을 형성하는 테스트인지를 나타내는 플래그(flag)를 갖는다. 결국, 제한 조건의 평가 엘리먼트(evaluate element)는 제한 조건이 평가되어야만 할 때를 나타내도록 사용될 수 있다. 제한 조건 평가에 대한 더 많은 정보는 3.7.3.7을 참조하면 된다.

3.7.3.3 오브젝트 제한 조건

오브젝트 제한 조건은 관계의 역할 하나 또는 양자 모두에게 제한 조건을 기술한다. 제한 조건은 제한 조건이 맞지 않은 경우에 제한 조건을 나타내는 데에 도움을 주는 이름을 갖는다. 오브젝트는 함유된(nested) 관계 제한 조건 또는 제한 조건 멤버를 포함할 수 있는데, 이들은 역할이 관계에 참가하는 인스턴스(instance)와 매칭되면 평가될 것이다.

제한 조건은 하기와 같이 평가된다.

a) 첫번째 역할 및 첫번째 정의가 오브젝트 인스턴스와 매칭된다. 만일 그렇다면, 두번째 역할 및 두번째 정의가 오브젝트 인스턴스와 매칭된다. 이들이 매칭되지 않는다면, matches=0으로 설정하고 c)로 스킵한다.

b) 첫번째 오브젝트 인스턴스의 컨텍스트에서 모든 함유된 제한 조건을 평가한다. 이들 모두가 참으로 평가되면, matches=1로 설정하고, 그렇지 않으면 matches=0으로 설정한다.

c) matches＞MinOccurs 및 matches＜MaxOccurs이면 result=true로 설정하고, 그외의 경우는 result=false로 설정한다.

d) required가 참이고 result가 거짓이면 메시지를 사용자에게 복귀시킨다.

e) result를 부모 컨텍스트(parent context)로 복귀시킨다.

3.7.3.4 오브젝트 제한 조건 그룹

오브젝트 제한 조건 그룹은 오브젝트 제한 조건의 세트가 함께 그룹화 되도록 하여, 그들이 최소한 하나의 의미(at-least-one semantics)를 사용하여 평가될 수 있게 한다. 그룹 내의 제한 조건 중 적어도 하나가 참으로 평가되지 않는다면, 그룹은 거짓을 복귀시킬 것이다. 제한 조건 그룹은 하기와 같이 평가된다.

a) 각각의 함유된 제한 조건을 교대로 평가한다. 적어도 하나가 참으로 평가되면 result=true로 설정하고, 그렇지 않으면 result=false로 설정한다.

b) result=false 및 Required=true인 경우, 에러를 발생시킨다.

c) result를 부모 컨텍스트로 복귀시킨다.

3.7.3.5 관계 제한 조건

관계 제한 조건은 오브젝트가 참가할 수 있는 관계를 제한하는 데에 사용된다. 관계 제한 조건은 관계 정의를 식별하고, 선택적으로는 관계의 다른 끝에서의 인스턴스의 오브젝트 정의 및 관계의 카디날리티(cardinality)를 식별한다. 제한 조건에는 이름이 주어져 에러 메시지에서 식별될 수 있도록 한다. 관계 제한 조건의 바디(body)는 이러한 제한 조건을 더욱 정제하는 함유된 제한 조건을 포함한다.

관계 제한 조건은 수 많은 목적으로 사용될 수 있다: 추가적인 술어(predicate) 없이 단지 카디날리티를 사용하여, 인스턴스가 정확하게 동작하기 위하여 제공되어야만 하는 관계를 식별하도록 관계 제한 조건이 사용될 수 있다. 술어를 이용해서는, 관계 제한 조건이 이러한 오브젝트와 기꺼이 상호작용하는 인스턴스의 구성 세트를 한정하도록 사용될 수 있다.

관계 제한 조건은 하기와 같이 평가된다.

a) matches=0으로 설정한다.

b) 오브젝트 인스턴스가 참가하는 각각의 관계 인스턴스에 대하여,

a. 관계 정의가 관계 인스턴스의 정의와 매칭되고, 관계 방향은 목표 역할에 의해 식별되는 방향과 매칭된다. 만일 그렇다면, 목표 오브젝트 정의는 관계의 다른 끝에서의 인스턴스의 정의와 매칭된다. 이들이 매칭되지 않으면, 다음 관계로 스킵한다.

b. 관계 인스턴스의 컨텍스트에서 모든 함유된 제한 조건을 평가한다, 이러한 모든 제한 조건이 참으로 평가되면 matches=matches+1로 설정한다.

c) matches＞MinOccurs 및 matches＜Maxoccurs인 경우는 result=true로 설정하고, 그외에는 result=false로 설정한다.

d) required가 참이고 result가 거짓인 경우, 메시지를 사용자에게 복귀시킨다.

e) result를 부모 컨텍스트에 복귀시킨다.

3.7.3.6 관계 제한 조건 그룹

관계 제한 조건 그룹은 관계 제한 조건의 세트가 함께 그룹화 되도록 하여, 그들이 최소한 하나의 세만틱스로서 평가될 수 있게 한다. 제한 조건 그룹은 하기와 같이 평가된다:

d) 각각의 함유된 제한 조건을 교대로 평가한다. 적어도 하나가 참이라고 평가하면 result=true라고 설정하고, 그렇지 않다면 result=false라고 설정한다.

e) result=false 및 Required=true인 경우에는, 에러를 발생시킨다.

f) result를 부모 컨텍스트에 복귀시킨다.

제한 조건이 평가될 수 있는 세가지 구별되는 시간이 있다: 설계 프로세스 중, 애플리케이션의 배치(deployment) 중, 및 조작자가 검사를 원하거나 애플리케이션의 구성을 업데이트 하기를 원하는 임의의 시간에 애플리케이션이 배치되는 경우이다.

제한 조건이 평가되는 시간은 제한 조건에 사용가능한 정보의 세트를 변화시킨다. 설계 시간에 평가되는 제한 조건은 배치 중에만 오직 공급되거나 또는 배치 후에만 오직 사용가능 하게 될 값에 의존할 수 없다. 배치 시간에 평가되는 제한 조건은 배치 후에만 오직 사용가능 하게 될 값에 의존할 수 없다. 배치 후에 평가되는 제한 조건은 애플리케이션의 임의의 설정에 액세스할 수 있다.

우리는 제한 조건 개발기로 하여금 제한 조건을 언제 실행해야만 하는가에 따라 제한 조건을 표시(mark)하도록 할 수 있다. 이러한 정보는 입력이 사용가능 하지 않을 때 우리가 제한 조건을 실행하려고 시도하는 경우에 발생할 에러를 회피하도록 사용된다. 컴파일러는 설계 제한 조건이 배치 또는 검증(validation)까지 사용 가능하지 않게 될 값에 의존하지 않는 것을 검사할 수 있다. 마찬가지로, 컴파일러는 배치 제한 조건이 배치 후까지 사용가능 하지 않게 될 값에 의존하지 않는 것을 확인할 수 있다. 컴파일러가 설정이 사용가능 하게 될 때의 완전한 지식을 가진다면, 제한 조건이 실행될 수 있는 시간은 계산될 수 있으나, 불행하게도, 이러한 경우는 일어나지 않는다. 값이 설정을 위해 제공될 수 있는 시간은 변화될 수 있으며, 예를 들어, 디렉토리 이름은 먼저 알려질 수 있거나 유일한 식별기를 발생시키는 알고리즘을 사용하여 배치 중에 생성될 수 있다.

a) 설계 - 설계 시간, 배치 시간 또는 확인 중에 제한 조건이 실행될 수 있음을 나타냄,

b) 배치 - 배치 또는 확인 중에 제한 조건이 실행될 수 있음을 나타냄,

3.7.3.7 제한 조건 평가

제한 조건이 평가될 수 있는 세가지 구별되는 시간이 있다: 설계 프로세스 중, 애플리케이션의 배포(deployment) 중, 및 조작자가 검사를 원하거나 애플리케이션의 구성을 업데이트 하기를 원하는 임의의 시간에 애플리케이션이 배포되는 경우이다.

제한 조건이 평가되는 시간은 제한 조건에 사용가능한 정보의 세트를 변화시킨다. 설계 시간에 평가되는 제한 조건은 배포 중에만 오직 공급되거나 또는 배포 후에만 오직 사용가능 하게 될 값에 의존할 수 없다. 배포 시간에 평가되는 제한 조건은 배포 후에만 오직 사용가능 하게 될 값에 의존할 수 없다. 배포 후에 평가되는 제한 조건은 애플리케이션의 임의의 설정에 액세스할 수 있다.

우리는 제한 조건 개발기로 하여금 제한 조건을 언제 실행해야만 하는가에 따라 제한 조건을 표시(mark)하도록 할 수 있다. 이러한 정보는 입력이 사용가능 하지 않을 때 우리가 제한 조건을 실행하려고 시도하는 경우에 발생할 에러를 회피하도록 사용된다. 컴파일러는 설계 제한 조건이 배포 또는 검증(validation)까지 사용 가능하지 않게 될 값에 의존하지 않는 것을 검사할 수 있다. 마찬가지로, 컴파일러는 배포 제한 조건이 배포 후까지 사용가능 하지 않게 될 값에 의존하지 않는 것을 확인할 수 있다. 컴파일러가 설정이 사용가능 하게 될 때의 완전한 지식을 가진다면, 제한 조건이 실행될 수 있는 시간은 계산될 수 있으나, 불행하게도, 이러한 경우는 일어나지 않는다. 값이 설정을 위해 제공될 수 있는 시간은 변화될 수 있으며, 예를 들어, 디렉토리 이름은 먼저 알려질 수 있거나 유일한 식별기를 발생시키는 알고리즘을 사용하여 배포 중에 생성될 수 있다.

제한 조건은 하기와 같이 표시될 수 있다:

a) 설계 - 설계 시간, 배포 시간 또는 확인 중에 제한 조건이 실행될 수 있음을 나타냄,

b) 배포 - 배포 또는 확인 중에 제한 조건이 실행될 수 있음을 나타냄,

c) 확인 - 확인 중에만 오직 제한 조건이 실행될 수 있음을 나타냄, 또는

d) 네버(never) - 제한 조건이 절대로 실행될 수 없음을 나타냄.

아래의 열거(enumeration)는 이러한 선택사항을 캡쳐(capture)하는 데에 사용된다.

제한 조건의 평가 거동은 구조적 제한 조건 및 제한 조건 멤버 모두에서 설정될 수 있다. 양자의 경우에서, 평가 거동은 구조적 제한 조건 또는 제한 조건 멤버 중의 하나를 이용하여 모든 함유된 제한 조건에 적용된다.

디폴트에 의한 제한 조건은 설계 시간 제한 조건으로 표시되고, 언제나 실행될 수 있다.

3.8 위임

위임의 목적은 모델의 개발기가 호스트 또는 포함된 컴포넌트로부터 게스트 또는 부모까지 특정 거동을 노출시키도록 허용하는 것이다. 이는 개발기가 존재하는 구현을 재사용하거나 클라이언트에 대한 더 포괄적인 구현을 제공하는 컴포넌트 를 설계하게 한다. 도 19는 호스트의 구현을 게스트에 노출시키는 위임을 사용하는 예를 도시한다. 도 19에서, Application Platform 컴포넌트는 데리게이션 관계를 사용하여 호스트, 동작 시스템 컴포넌트로부터 게스트, 애플리케이션까지 파일 시스템을 노출시킨다. 이렇게 함으로써, 애플리케이션 플랫폼은 동작 시스템의 어떤 부분이 그들을 직접 구현할 필요 없이 게스트에 대하여 사용가능한 것인가를 제어할 수 있다.

도 20은 부모에 멤버의 구현을 노출시키는 위임을 사용하는 예를 도시한다. 도 20에서, 클라이언트 애플리케이션은 티켓팅(ticketing) 애플리케이션에 부킹(booking) 서비스의 종단점을 노출시킨다. 이는 티켓팅 애플리케이션으로 하여금 Server 애플리케이션에 종단점을 연결하게 하며, 이 Server 애플리케이션은 교대로 UserData 애플리케이션에 그 종단점을 위임한다.

3.8.1 원리

하기의 원리는 위임 모델의 설계를 가이드(guide)한다.

ㆍ프록시(proxy)는 목표 시스템 내에 존재하지 않는다. 프록시는 모델을 위한 컨비니언스(convenience)이며 물리적인 조짐(manifestation)을 갖지 않는다. 이것이 참이 아니라면 위임의 사용은 목표 시스템에 준다.

데이터 센터에서, 구역은 서로 다른 안전 필요 조건 또는 거동으로 시스템을 구별하는 데에 자주 사용된다. 통신 관계가 구역 경계를 크로스할 때, 사용자는 그 관계의 거동상에 제한 조건을 배치하는 것을 원할 수 있다. 예를 들어, 사용자는 후위 서버에 일정 포트를 통한 http 통신을 허용하는 것만을 원할 수 있다. 이를 위하여, 사용자는 통신 관계가 구역 경계를 크로스할 때 이를 식별할 수 있어야만 한다: 프록시는 이를 할 수 있는 유일한 방법이다. 도 23에서 구역 경계의 예를 설명한다.

ㆍ외부 사용자의 관점으로부터, 사용자는 특별한 인스턴스가 프록시인지 또는 실제 구현인지 여부를 인식할 필요가 없어야 했다. 이것이 참이 아니라면, 제한 조건 및 플로우 저자는 복잡하고 부서지기 쉬운 코드가 되게 하는 양자의 경우를 커버해야 한다.

ㆍ사용자는 제한 조건 표현의 부분으로서 명백하게 프록시를 목표로 삼을 수 있게 해야만 한다. 이는 컴포넌트 경계를 통해 거동의 노출을 제어하는 제한 조건을 구현하는 데에 필요하다.

3.8.2 시나리오

하기는 시스템에서 위임을 사용하는 것과 관련된 문제점을 설명하는 두개의 시나리오이다.

3.8.2.1 통신 연결성 검증(communication connectivity validation)

클라이언트 포트가 서버 포트에 연결될 수 있는가를 확인하기 위하여, 통신 관계는 제한 조건을 포함하는데, 이 제한 조건은 서버로 워크(walk)하고, 그 후에 서버의 호스트로 워크며, 그 후에 3층에서 통신 관계를 따라 워크-백(walk back)하며, 그 후에 호스팅 관계 위에서 4층 클라이언트로 워크하고, 끝으로 통신 관계로 워크-백한다. 이는 도 21에서 설명된다.

위임 관계는 포함 경계(containment boundaries)의 존재 때문에 양 층에서 클라이언트와 서버 사이에 존재될 가능성이 있다. 이러한 예는 도 22에서 설명된다. 이러한 경로를 따르는 제한 조건을 기록하기 위하여, 사용자는 임의의 수의 이러한 관계에 대처할 수 있어야만 하며, 이는 제한 조건의 기술을 복잡하게 하고 제한 조건 언어의 사용을 감소시킨다.

이를 회피하기 위하여, 우리는 사용자가 프록시가 존재하는지 및 얼마나 맣이 존재할 수 있는지를 미리 인식하지 않고 제한 조건을 기록할 수 있게 할 필요가 있다.

3.8.2.2 구역(zone) 경계

호스팅	호스트	예	호스팅 관계가 프록시를 목표로 할 때, 게스트는 위임에 재라우팅(reroute)된다. 결과는 게스트가 위임 상에서 직접 호스팅되었던 것처럼 된다.
	게스트	아니오	이것은 허용되지 않는다. 이는, 프록시가 모델링된 시스템에 존재하거나 위임이 프록시의 구성에 기초하여 배치되는 것을 의미한다.
포함	부모	아니오	프록시는 포함 관계에 부모로서 참가할 수 없다. 그렇다면, 위임의 멤버를 변화시키게 되는데, 이는 허용되지 않는다.
	멤버	예	프록시는 애플리케이션의 포함 구조 내에 존재한다. 따라서, 프록시는 포함 관계 내의 멤버로서 참가할 수 있어야만 한다.
위임	프록시	예	프록시는 위임에 요청을 전달할 수 있도록 위임 관계에 참가하여야만 한다.
	위임	예	프록시는 다른 위임 관계를 위한 위임으로서 동작할 수 있다. 이는, 포함의 복수의 층을 통해 인스턴스를 노출시키면서, 위임이 연결되도록 한다.
레퍼런스	소스	예	프록시는 레퍼런스 관계를 위한 소스로서 동작할 수 있다. 소스를 위한 요청은 위임으로 다시 향한다.
	디펜던트	아니오	프록시는 레퍼런스 관계에서 디펜던트로서 동작할 수 있는데, 이는 위임이 레퍼런스를 요구함으로써 위임의 거동을 변화시키는 것을 의미하기 때문이다.
통신	클라이언트	예	우리는 위임을 이용하여 컨테이너를 통해 종단점을 노출시키기 때문에, 프록시는 클라이언트로서 동작할 수 있어야만 한다.
	서버	예	우리는 위임을 이용하여 컨테이너를 통해 종단점을 노출시키기 때문에, 프록시는 서버로서 동작할 수 잇어야만 한다.

도 23에서, 개발기가 구역 1로부터 구역 2까지 발신(outgoing) 통신을 제한할 수 있다면, 구역 경계에 위임되는 종단점을 제한 조건함으로써 그렇게 할 수 있다. 예를 들어, 그들은 착신(incoming) http 및 발신 sq1 통신 플로우만을 허용하는 제한 조건을 기록할 수 있다. 이러한 제한 조건은 구역에 의해 노출되는 각각의 프록시 종단점에 대해 발사(fire)한다.

프록시를 제한하기 위하여, 프록시는 제한 조건에 시각적으로 표시되어야 한다. 이는, 제한 조건이, 프록시가 거동을 구현하는 위임으로부터 개별적으로 참가 하는 관계를 목표로 삼을 수 있어야만 하는 것을 의미한다. 이는, 일부 시나리오에서 프록시가 사용자에게 투과성(transparent)이 아니기 때문에, 이전의 시나리오를 위해 예측되는 거동을 복잡하게 한다.

3.8.3 모델의 다른 부분과의 상호작용

위임을 위한 규칙은 도 24에 도시된 예시적인 인스턴스 공간을 사용하여 설명된다.

3.8.3.1 프록시 및 위임

프록시는 위임의 동일 등급이거나 기본 등급이어야 한다. 도 24의 예에서, 프록시로 동작하는 b는 위임, c의 동일 정의이거나 기본 정의이어야 한다. 이는 프록시(b)가 c의 거동만을 노출시킬 수 있기 때문에 필요하다. 형태가 다른 것이 허용된다면, b의 노출된 거동은 c의 거동과 다를 수 있으나, 필요한 거동을 구현할 수 있는 b의 어떠한 물리적인 조짐도 존재하지 않는다.

인스턴스 공간에서, 프록시 인스턴스는 오직 하나의 위임만을 가질 수 있다. 즉, 관계에서 프록시로 동작하는 b로부터의 오직 하나의 위임 관계만이 존재할 수 있다. 이러한 제한 조건 없이는 위임으로부터 설정 값 또는 멤버 수집을 복귀시키는 것이 가능하지 않기 때문에, 이러한 제한 조건이 필요하다 (실행 시간은 어떠한 위임이 그 값을 위한 소스로서 선택되는가를 알지 못한다).

3.8.3.2 관계 역할

프록시는 하기의 관계 역할에 참가할 수 있다.

3.8.3.3 멤버 필터링 및 경로 결정

프록시는 프록시의 정의의 부분으로서 정의된 위임으로부터의 멤버만을 노출시킨다. 프록시 및 위임의 정의가 동일한 경우에, 위임의 모든 멤버는 프록시에 의해 노출될 것이다. 프록시 정의가 위임의 정의의 기본 정의일 때, 프록시는 두 정의 모두에 공통인 멤버만을 노출시킬 것이다.

도 24에 B 및 C에 대한 정의를 아래에 나타낸다:

각각의 오브젝트 인스턴스는 관계 세트에 참가한다. 이러한 관계는 제한 조건 및 플로우 모두를 평가하는 데에 사용되며, 또한 인스턴스화(instantiation) 프로세스를 제어하는 데에도 사용된다. 프록시 및 위임 모두는, 프록시 및 위임 모두의 코히런트 픽쳐(coherent picture)를 사용자에게 표시하기 위하여 서로 결합되어야만 하는 관계 세트에 참가한다. 프록시로부터, 우리는 프록시의 관계와 협력하여 위임 관계의 서브-세트를 노출시켜야만 한다. 우리가 구현을 숨기고 있다면, 프록시는 사용자에게 자신의 포함 관계 및 가능하다면 위임 관계의 작은 서브-세트만을 복귀시켜야만 한다. 완전한 투과성의 프록시를 원한다면, 우리는 모든 위임 관계를 노출시키거나 프록시의 관계를 숨길 것이다.

프록시(b)는 고도 설정만을 노출시킬 것이고, 가중치 설정은 노출시키지 않을 것이다.

설정 값이 프록시 상에 설정되면, 동작이 위임 관계를 통해 위임에 전달된다: 새로운 설정 값은 위임 상에 직접 기록되고, 그 위임을 목표로 하는 임의의 다른 프록시에 시각적으로 표시된다.

설정 값이 프록시로부터 검색되면, 요청이 위임으로 전달되고, 설정 값은 위임으로부터 직접 복귀된다.

오브젝트 및 관계 멤버 필터링은 설정 필터링과 같은 방법으로 작동된다. 프록시의 정의의 부분으로서 선언되는 공개 멤버만이 프록시에 의해 노출된다. 멤버에 대한 즉각적인 변화는 위임 멤버에 영향을 주며, 그 위임을 목표로 하는 모든 프록시에 시각적으로 표시된다. 멤버 경로가 프록시 상의 멤버를 참조할 때, 경로는 위임 상의 멤버로 자동 결정된다. 이는, 경로 구문(path syntax)은 멤버가 프 록시인지 또는 위임인지에 따라 변화하지 않는다는 것을 의미한다.

3.8.3.4 관계 필터링

각각의 오브젝트 인스턴스는 관계 세트에 참가한다. 이러한 관계는 제한 조건 및 플로우 모두를 평가하는 데에 사용되며, 또한 인스턴스 생성(instantiation) 프로세스를 제어하는 데에도 사용된다. 프록시 및 위임 모두는, 프록시 및 위임 모두의 코히런트 픽쳐(coherent picture)를 사용자에게 표시하기 위하여 서로 결합되어야만 하는 관계 세트에 참가한다. 프록시로부터, 우리는 프록시의 관계와 협력하여 위임 관계의 서브-세트를 노출시켜야만 한다. 우리가 구현을 숨기고 있다면, 프록시는 사용자에게 자신의 포함 관계 및 가능하다면 위임 관계의 작은 서브-세트만을 복귀시켜야만 한다. 완전한 투과성의 프록시를 원한다면, 우리는 모든 위임 관계를 노출시키거나 프록시의 관계를 숨길 것이다.

위임으로부터, 우리는 프록시가 참가하는 관계의 서브-세트와 관련한 직접적인 관계를 노출시킬 필요가 있다. 즉, 프록시가 다른 종단점과 통신 관계를 갖는다면, 위임이 이러한 관계에 직접 참가하는 것처럼 보여야만 한다. 반면에, 우리는 위임의 부분으로서 프록시의 포함 관계를 노출시키는 것을 원하지 않는다. 제한 조건에 대한 롤-업(roll up) 거동은 3.8.3.6에서 기술된다.

3.8.3.4.1 프록시 식별(proxy identity) 및 관계 필터링

우리는 투과성 프록시 및 불투명(opaque) 프록시의 두가지 형태의 프록시를 갖는다. 투과성 프록시는 개발기가 프록시의 클라이언트에 위임의 구현을 노출시키기를 원할 때 사용된다. 붙투명 프록시는 개발기가 프록시의 클라이언트로부터 위임의 구현을 숨기기를 원할 때 사용된다.

3.8.3.4.1.1 투과성 프록시

투과성 프록시는 클라이언트에 위임의 구현을 노출시키도록 사용된다. 전형적인 예가 도 23에 도시되며, 여기서 존은 단순히 모델링 목적이며, 존이 포함하는 시스템을 존이 숨겨서는 안된다. 이러한 경우에, 구역 2에서 Sq1 시스템과 통신하고 있는 개발기는 위임된 종단점의 구현이 구역에서보다는 Sq1 시스템적이라는 사실을 인식해야만 한다.

투과성 프록시는 클라이언트 보다는 위임으로부터 모든 식별 정보를 복귀시킨다. 이는, 인스턴스 ID, 정의, 버전 및 포함 정보는 모두 프록시 보다는 위임으로부터 나온다는 것을 의미한다.

쿼리될(queried) 때, 또한, 투과성 프록시는 프록시의 관계 보다는 위임이 참가하는 관계 세트를 복귀시키기도 할 것이다.

3.8.3.4.1.2 불투명 프록시

불투명 프록시는 위임의 구현을 숨기도록 사용되어, 개발기가 클라이언트와의 접속을 깨지 않으면서 그 구현을 자유로이 변화시킬 수 있도록 한다. 예를 들면, 도 19에서, IIS 시스템은 파일 시스템 구현을 숨기도록 불투명 프록시를 사용할 수 있어서, IIS의 게스트가 파일 시스템을 구현하는 동작 시스템에 의존하지 않게 한다.

불투명 프록시는 위임 보다는 프록시로부터 인스턴스 ID, 정의, 버전 및 포함 정보를 복귀시킬 것이다.

쿼리될 때, 불투명 프록시는, 불투명 프록시가 그 위임 관계를 직접 포함하지 않는 것에 참가하는 관계만을 복귀시킬 것이다.

3.8.3.5 플로우

프록시를 목표로 하는 플로우는, 목표가 실제 구현 보다는 프록시라는 것을 플로우가 인식하도록 하는 어떠한 요구 사항 없이, 위임으로 자동적으로 다시 향할 것이다. 프록시는 멤버를 위해 위임과 관련된 인스턴스에 모든 요청을 전달하기 때문에, 플로우의 영향은 프록시에 의해 위임으로 직접 전달된다.

프록시의 부분으로서 선언되는 플로우는 평가되지 않을 것이다. 이는, 위임이 프록시의 정의와 동일하거나 이의 도출이 되어야 하기 때문에, 플로우 또한 위임의 부분으로서 평가될 것이기 때문이다. 플로우가 평가되면, 우리는 항상 위임 설정 값 상에 중복(duplicate) 플로우 에러를 가질 것이다.

3.8.3.6 제한 조건

제한 조건은 위임 인식이 되도록 또는 되지 않도록 기록될 수 있다. 제한 조건이 위임 인식이라면, 프록시가 참가하는 관계의 어떠한 롤-업 없이도, 제한 조건은 각 프록시 인스턴스 상에서 평가될 것이다. 위임 관계는 제한 조건에 노출될 것이다. 예를 들어, 도 24에서 x로부터 b를 목표로 기록된 위임 인식 통신 제한 조건은 프록시(b) 및 그 제한 조건이 x, c, d, e 및 i와 같이 참가하는 관계를 인식한다. 그 후, 그 제한 조건이 c에 대한 위임 관계 다음에 온다고 가정하면서, 그 제한 조건은 c로부터 b, f, h 및 g까지의 관계를 인식한다.

제한 조건이 위임 인식으로서 표시되지 않으면, 제한 조건 엔진은 프록시를 목표로 하는 관계를 평가할 때 투과성 프록시 상으로 자동 스킵할 것이다. 제한 조건의 목표 인스턴스가 프록시라면, 제한 조건 엔진은 위임에 의해 그것을 대체할 것이다. 제한 조건은 위임 관계를 절대로 인식하지 못할 것이다.

동일한 제한 조건이 위임 인식의 존재 없이도 평가된다면, 그 제한 조건은 b를 전혀 인식하지 못한다. 대신에, 오직 c에 대해서만 평가된다. c를 평가할 때, 그 제한 조건은 c 및 x, d, f, h, g 및 i간의 관계를 인식한다. 이러한 경우에, 우리는 포함 관계를 제외하고 b로부터 모든 관계를 롤-업하고, 위임 관계를 숨긴다는 것을 주목하라.

제한 조건은 구조적 제한 조건(오브젝트 또는 관계 제한 조건 중의 하나, 3.7.3 참조) 상에 DelegationAware 속성을 참으로 설정함으로써 위임 인식으로 표시된다.

프록시의 정의의 부분으로서 선언되는 제한 조건은 프록시 상에서 평가되지 않을 것이다. 이는, 제한 조건이 프록시의 정의 및 위임의 정의 모두에 공통이어야만 하기 때문에, 또한 제한 조건도 위임에 대하여 평가될 것이기 때문이다.

3.9 관리기

메카니즘에 의해 형태 및 관계가 실행 시간 환경으로 커스텀(custom) 거동을 삽입하는데, 관리기는 이러한 메카니즘에 해당한다. 관리기가 관리하는 각각의 형태에 대하여 관리기를 지원할 수 있는 몇가지 역할이 있다: 관리기는 형태의 설치에 참가할 수 있고, 형태의 CLR 표현을 제공할 수 있으며, 형태간의 결합이 어떻게 분해될 것인가에 대한 정책 결정에 포함될 수 있으며, 복잡한 제한 조건 및 플로우 에 대한 구현을 제공할 수 있다.

모든 오브젝트 관리기 역할은 강하게 명명된 등급으로의 진입점(entry points)으로서 CLR을 통해 드러난다. 오브젝트 관리기는 패키징되고, SDM에서의 다른 형태와 동일한 방법으로 개조된다. 오브젝트 관리기는 시스템 분산 유닛에서 분산되고, 그 버전 및 강한 이름은 그것이 선언된 SDM 파일로부터 도출된다.

3.9.1 역할

오브젝트 관리기는 오브젝트 관리기가 지원하는 각 형태에 대해 하나 이상의 역할을 지원할 수 있다. 이러한 역할은:

a) 형태 또는 관계에 대한 제한 조건을 평가함

b) 형태 또는 관계에 대한 플로우를 평가함

c) 형태에 대한 제작(construction)/파괴(destruction)/업데이트 지원

d) 형태 또는 관계 사의 설정을 위한 오브젝트 표현을 노출시킴

e) 형태 또는 관계에 대한 디스커버리(discovery)를 수행함

f) 형태 또는 관계 주위에서 설계 표면 특정 UI를 지원함

3.9.2 노트

관리기는 다른 관리기에 대한 종속성을 가질 수 있으나, 이러한 종속성은 사용자가 관리하는 SDM 파일의 가져오기 문장(import statement)에서 리플렉팅되어야(reflected)만 한다. 이러한 종속성이 기술되지 않으면, 특정 관리기가 의존하는 다른 관리기는 실행시간에 의해 로딩되지 않을 것이며, 그 관리기는 실행을 할 수 없을 것이다.

3.10 설계 데이터 및 기술

기술은 관련된 SDM 엘리먼트를 기술하는 텍스트를 포함한다. 이러한 텍스트는 DocumentLanguage 속성에 의해 식별되는 문서의 언어 내에 있다. 텍스트의 로컬리제이션(localization)을 지원하기 위하여, 자원 식별기가 제공될 수 있다. 실행 시간은 기술 상에서 식별된 관리기를 요구할 것이고, 또한, 관리기가 공급되지 않는다면, 기술과 관련된 로컬라이징된 텍스트를 위한 문서용 디폴트 관리기를 요구할 것이다.

설계 데이터 형태는 설계 표면에 의해 정의되는 구조적 데이터를 포함한다. 각각의 설계 표면은 데이터를 식별하거나 구성하기 위한 그 자신의 스키마(schema)를 사용해야만 한다.

3.11 SDM 문서 구조

SDM 문서는 한 세트의 관계, 오브젝트 및 관리기를 위한 강한 식별성(strong identity), 버저닝(versioning) 및 로컬리제이션 정보를 제공한다.

삭제

시스템들의 설계 시간 검증의 몇몇 측면에 따르면, 설계되는 시스템의 기술(description)과 환경의 기술이 수신될 수 있다. 수신된 기술들은 시스템을 배치하는 시도에 앞서서 시스템이 설계되는 동안 환경에 대해 시스템을 확인하는 데 사용된다.

3.11.1 정보

SDM 문서의 정보 섹션은 SDM 문서의 식별 및 관리를 지원하기 위한 인간 판독가능 정보를 포함한다.

예시적인 컴퓨터 환경

도 25는 일반적인 컴퓨터 환경(800)을 설명하는데, 이는 본명세서에 개시된 기술을 구현하기 위해 사용될 수 있다. 컴퓨터 환경(800)은 단지 컴퓨터 환경의 한 예이며, 컴퓨터 및 네트워크 아키텍쳐의 사용 또는 기능에 대하여 어떠한 제한 조건도 제안할 의도는 없다. 예시적인 컴퓨터 환경(800)에서 도시된 임의의 컴포넌트 또는 이의 결합과 관련한 종속성 또는 요구조건 어느 것도 컴퓨터 환경(800)이 구비하고 있는 것으로 해석되어져서는 안된다.

컴퓨터 환경(800)은 컴퓨터(802)의 형태로 범용의 컴퓨터 소자를 포함한다. 예를 들어, 컴퓨터(802)는 도 1의 컴퓨터 소자(102), 도 2의 구현 개발 시스템(implement development system, 202) 또는 검증 컴포넌트(208)가 될 수 있다. 컴퓨터(802)의 컴포넌트는 하나 이상의 프로세서 또는 프로세싱 유닛(804), 시스템 메모리(806), 및 프로세서(804)를 포함하는 다양한 시스템 컴포넌트를 시스템 메모리(806)에 결합하는 시스템 버스(808)를 포함할 수 있으나, 이들에 한정되는 것은 아니다.

시스템 버스(808)는, 메모리 버스 또는 메모리 제어기, 주변 장치 버스, AGP(accelerated graphics port), 및 다양한 버스 아키텍쳐 중의 하나를 사용하는 프로세서 또는 로칼 버스를 포함하면서, 임의의 몇가지 형태의 버스 구조 중에서 하나 이상을 표현한다. 예시로서, 그러한 아키텍쳐는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 버스, 및 메짜닌(Mezzanine) 버스로도 알려진 PCI(Peripheral Component Interconnects) 버스를 포함할 수 있다.

일반적으로, 컴퓨터(802)는 다양한 컴퓨터 판독가능 매체를 포함한다. 그러한 매체는 컴퓨터(802)로 액세스 가능한 임의의 사용가능 매체일 수 있으며, 휘발성 및 비휘발성 매체 모두와 분리성 및 비분리성 매체를 포함한다.

시스템 메모리(806)는, RAM(810)과 같은 휘발성 메모리, 및/또는 ROM(812)과 같은 비휘발성 메모리 형태의 컴퓨터 판독가능 매체를 포함한다. 기본적인 입력/출력 시스템(BIOS, 814)은, 스타트 업 동안과 같이 컴퓨터(802) 내의 엘리먼트간에 정보를 전송하는데 도움을 주는 기본 루틴을 포함하면서, ROM(812)에 저장된다. 일반적으로, RAM(810)은 프로세싱 유닛(804)에 직접 액세스 가능하고 및/또는 프로세싱 유닛(804)에 의해 현재 동작되는 데이터 및/또는 프로그램 모듈을 포함한다.

또한, 컴퓨터(802)는 다른 분리성/비분리성, 휘발성/비휘발성 컴퓨터 기억 메체를 포함할 수 있다. 예시로서, 도 25에는, 비분리성이며 비휘발성 자기 매체(도시되지 않음)로부터 판독하거나 그 매체에 기록하는 하드 디스크 드라이브(816), 분리성이며 비휘발성 자기 디스크(820, 예를 들어, "플로피 디스크")로부터 판독하거나 그 디스크에 기록하는 자기 디스크 드라이브(818), 및 CD-ROM, DVD-ROM, 또는 다른 광학 매체와 같은 분리성이며 비휘발성 광학 디스크(824)로부터 판독하거나 그 디스크에 기록하는 광학 디스크 드라이브(822)가 도시된다. 하드 디스크 드라이브(816), 자기 디스크 드라이브(818), 및 광학 디스크 드라이브(822) 각각은 하나 이상의 데이터 매체 인터페이스(826)에 의해 시스템 버스(808)에 연결된다. 또한, 하드 디스크 드라이브(816), 자기 디스크 드라이브(818), 및 광학 디스크 드라이브(822)는 하나 이상의 인터페이스(도시되지 않음)에 의해 시스템 버스(808)에 연결될 수 있다.

디스크 드라이브 및 그와 관련된 컴퓨터 판독가능 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 및 다른 컴퓨터(802) 데이터의 비휘발성 저장을 제공한다. 본 예시가 하드 디스크(816), 분리성 자기 디스크(820), 및 분리성 광학 디스크(824)를 도시한다고 하여도, 자기 카세트 또는 다른 자기 기억 장치, 플래시 메모리 카드, CD-ROM, DVD 또는 다른 광학 기억 매체, RAM, ROM, EEPROM 및 이와 유사한 것과 같이, 컴퓨터에 의해 액세스 가능한 데이터를 저장할 수 있는 다른 형태의 컴퓨터 판독가능 매체 역시 전형적인 컴퓨터 시스템 및 환경을 구현하기 위해 사용될 수 있다.

예시적으로, 운영 시스템(826), 하나 이상의 애플리케이션 프로그램(828), 다른 프로그램 모듈(830),및 프로그램 데이터(832)를 포함하는 임의의 수의 프로그램 모듈은 하드 디스크(816), 자기 디스크(820), 광학 디스크(824), ROM(812), 및/또는 RAM(810) 상에 저장될 수 있다. 그러한 운영 시스템(826), 하나 이상의 애플리케이션 프로그램(828), 다른 프로그램 모듈(830),및 프로그램 데이터(832)(또는 그들의 일부 결합)의 각각은 분산 파일 시스템을 지원하는 상주 컴포넌트(resident component)의 모두 또는 일부를 구현할 수 있다.

사용자는 키보드(834) 및 위치 지정 도구(pointing device, 836)(예를 들어, "마우스")와 같은 입력 장치를 통해 컴퓨터(802)에 명령 및 정보를 엔터할(enter) 수 있다. 다른 입력 장치(838, 구체적으로 도시되지 않음)는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 직렬 포트, 스캐너, 및/또는 이와 유사한 것을 포함할 수 있다. 이들 및 다른 입력 장치들은 시스템 버스(808)에 결합되는 입력/출력 인터페이스(840)를 통하여 프로세싱 유닛(804)에 연결되나, 병렬 포트, 게임 포트, 또는 USB(universal serial bus)와 같은 다른 인터페이스 및 버스 구조에 의해 연결될 수 있다.

또한, 모니터(842) 또는 다른 형태의 표시 소자가 비디오 어댑터(844)와 같은 인터페이스를 통하여 시스템 버스(808)에 연결될 수도 있다. 모니터(842)에 부가하여, 다른 출력 주변 장치는 입력/출력 인터페이스(840)를 통하여 컴퓨터(802)에 연결될 수 있는 스피커(도시되지 않음) 및 프린터와 같은 컴포넌트를 포함할 수 있다.

컴퓨터(802)는 원격 컴퓨터 장치(848)와 같은 하나 이상의 원격 컴퓨터로의 논리적 연결을 이용하여 네트워크 환경에서 동작할 수 있다. 예시로서, 원격 컴퓨터 장치(848)는 개인용 컴퓨터, 휴대용 컴퓨터, 서버, 라우터, 네트워크 컴퓨터, 동등 장치(peer device) 또는 다른 공통 네트워크 노드, 및 이와 유사한 것이 될 수 있다. 원격 컴퓨터 장치(848)는 컴퓨터(802)와 비교하여 본명세서에서 개시된 엘리먼트 및 특징의 다수 또는 모두를 포함할 수 있는 휴대용 컴퓨터로 도시된다.

컴퓨터(802)와 원격 컴퓨터(849)간의 논리적 연결은 LAN(local area network, 850) 및 일반적인 WAN(wide area network, 852)로서 표시된다. 그러한 네트워크 환경은 사무실, 기업 전체(enterprise-wide) 컴퓨터 네트워크, 인트라넷 및 인터넷에서 평범한 것이다.

컴퓨터가 LAN 네트워크 환경에서 구현될 때, 컴퓨터(802)는 네트워크 인터페이스 또는 어댑터(854)를 통하여 로컬 네트워크(850)에 연결된다. 컴퓨터가 WAN 네트워크 환경에서 구현될 때, 컴퓨터(802)는 일반적으로 전체 네트워크(852) 상에서 통신을 확립하기 위한 모뎀(856) 또는 다른 수단을 포함한다. 컴퓨터(802)에 내부적 또는 외부적일 수 있는 모뎀(856)은 입력/출력 인터페이스(840) 또는 다른 적합한 메카니즘을 통해 시스템 버스(808)에 연결될 수 있다. 도시된 네트워크 연결은 예시적이며, 컴퓨터(802, 848)간의 통신 연결(들)을 확립하는 다른 수단이 채용될 수 있다.

네트워크 환경에서, 컴퓨터 환경(800)으로 도시된 것과 같이, 컴퓨터(802)와 비교하여 표시된 프로그램 모듈 또는 그 부분은 원격 메모리 기억 장치에 저장될 수 있다. 예시로서, 원격 애플리케이션 프로그램(858)은 원격 컴퓨터(848)의 메모리 장치 상에 상주한다. 운영 시스템과 같은 다른 실행가능 프로그램 컴포넌트 및 애플리케이션 프로그램이 컴퓨터 장치(802)의 다른 저장 컴포넌트에 다양한 시간에 상주한다는 것을 인식한다고 하여도, 본명세서에서는 도시의 목적으로, 그러한 프로그램 및 컴포넌트는 개별 블록으로 도시되며, 컴퓨터의 데이터 프로세서(들)에 의해 실행된다.

프로그램 모듈과 같이, 다양한 모듈 및 기술들이 본명세서에서의 컴퓨터 실행가능 명령의 일반적인 컨텍스트 내에서 기술될 수 있으며, 하나 이상의 컴퓨터 또는 다른 장치에 의해 실행될 수 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터 형태를 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이처 구조 등을 포함한다. 일반적으로, 프로그램 모듈의 기능은 다양한 실시예에서 요구되는 것과 같이 결합되거나 분산될 수 있다.

이러한 모듈 및 기술의 구현은 컴퓨터 판독가능 매체의 일부 형상 상에 저장되거나 컴퓨터 판독가능 매체의 일부 형상을 통하여 전송될 수 있다. 컴퓨터 판독가능 매체는 컴퓨터에 의해 액세스 가능한 임의의 사용가능 매체가 될 수 있다. 예시로서, 컴퓨터 판독가능 매체는 "컴퓨터 저장 매체" 및 "통신 매체"를 포함할 수 있으나, 이에 한정되지 않는다.

"컴퓨터 저장 매체"는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술에서 구현되는 휘발성 및 비휘발성, 분리성 및 비분리성 매체를 포함한다. 컴퓨터 기억 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 기억 장치, 자기 카세트, 자기 테이프, 자기 디스크 기억 장치 또는 다른 자기 기억 장치, 또는 원하는 정보를 저장하는데 사용될 수 있으며 컴퓨터로 액세스 가능한 임의의 다른 매체를 포함하나, 이에 한정되지 않는다.

일반적으로, "통신 매체"는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 또는 반송파 또는 다른 전달 메카니즘과 같은 변조된 데이터 신호에서의 다 른 데이터를 구현한다. 또한, 통신 매체는 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 하나 이상의 특성 세트를 가지거나, 신호에서 정보를 인코드 하는 것과 같은 방법으로 변화되는 신호를 의미한다. 예시로서, 통신 매체는 유선 네트워크 또는 직접 유선 연결(direct-wired connection)과 같은 유선 매체, 및 음향, RF, 적외선, 및 다른 무선 매체와 같은 무선 매체를 포함하나, 이에 한정되지 않는다. 상술한 것의 임의의 결합도 컴퓨터 판독가능 매체의 범위 내에 포함된다.

또한, 프레임워크의 부분은 하드웨어 또는 하드웨어의 결합, 소프트웨어, 및/또는 펌웨어 내에서 구현될 수 있다. 예를 들어, 하나 이상의 ASIC(application specific integrated circuits) 또는 프로그램가능 논리 소자(PLD; programmable logic device)는 하나 이상의 프레임워크의 부분을 구현하도록 설계되거나 프로그램될 수 있다.

결론

본발명이 구조적 특징 및/또는 방법론적인 동작으로 특정된 언어로 기술되어 있지만, 첨부되는 청구범위에서 정의되는 본발명은 반드시 기술된 특정 특징 또는 동작에 한정되지 않는다는 것을 인식할 수 있을 것이다. 대신에, 특정 특징 및 동작은 청구된 본발명을 구현하는 예시적인 형태로 개시된다.

시스템들의 설계 시간 검증의 몇몇 측면에 따르면, 설계되는 시스템의 기술(description)과 환경의 기술이 수신될 수 있다. 수신된 기술들은 시스템을 배포하는 시도에 앞서서 시스템이 설계되는 동안 환경에 대해 시스템을 확인하는 데 사용된다.

Claims (43)

1. 설계 중인 시스템의 배치(deploy)를 시도하기 전에, 상기 시스템의 검증(validation)을 용이하게 하는 방법으로서,

   설계 중인 시스템의 배치를 시도하기 전에, 상기 시스템의 검증을 용이하게 하도록 구성된 시스템 검증 컴퓨팅 장치에 의해, 데이터 센터의 환경에서 사용되도록 설계 중이지만 아직 상기 데이터 센터에 배치되지는 않은 상기 시스템의 기술(description)을 수신하는 단계;

   상기 시스템 검증 컴퓨팅 장치에 의해, 대상-배치 환경(a target-deployment environment)을 시뮬레이션하는(simulate) 환경의 기술을 수신하는 단계 - 상기 대상-배치 환경은 상기 시스템이 배치될 상기 데이터 센터임 - ; 및

   상기 시스템을 설계 중이고, 상기 데이터 센터에 상기 시스템의 배치를 시도하기 전에, 상기 시스템 검증 컴퓨팅 장치에 의하여, 상기 환경에 대하여 상기 시스템을 검증하기 위해 상기 수신된 기술들 둘 다를 사용하는 단계를 포함하고,

   상기 환경에 대하여 상기 시스템을 검증하는 것은,

   애플리케이션 기술로부터 탑-레벨 정의(top-level definition)를 선택하고,

   인스턴스 스페이스에 대하여 상기 탑-레벨 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하고,

   상기 탑-레벨 정의 내에 내포되어 있는(nested) 부가적 정의(additional definition)를 선택하며,

   상기 선택된 부가적 정의가 오브젝트를 정의하는지 또는 관계(relationship)를 정의하는지에 기초하여 상기 인스턴스 스페이스에 대하여 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하고,

   상기 탑-레벨 정의 내에 내포되어 있는 모든 정의들에 대한 인스턴스들이 상기 인스턴스 스페이스에 대하여 생성될 때까지, 부가적 정의의 선택 및 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하는 것을 계속하도록 하는 것을 더 포함하는,

   시스템의 검증을 용이하게 하는 방법.
2. 제1항에 있어서,

   상기 시스템의 기술은 SDM 문서를 포함하는, 시스템의 검증을 용이하게 하는 방법.
3. 제1항에 있어서,

   상기 환경의 기술은 LIM 문서를 포함하는, 시스템의 검증을 용이하게 하는 방법.
4. 다수의 명령문(instructions)들을 저장하는 1 이상의 컴퓨터 판독 가능 기록 매체로서,

   상기 다수의 명령문들은 1 이상의 프로세서에 의해 실행될 때, 상기 1 이상의 프로세서로 하여금

   상기 1 이상의 프로세서 상에서 실행되는 프로그램에 의하여, 데이터 센터의 환경에서 사용되도록 설계 중인 프로세스에서 애플리케이션을 기술하는 애플리케이션 기술(application description)에 액세스하는 단계;

   시뮬레이션된 환경에 대하여 상기 애플리케이션 기술을 사용하여, 상기 데이터 센터로의 배치 이전에 상기 애플리케이션을 검증하는 단계 - 상기 환경은 상기 데이터 센터의 기술을 포함함 - ;

   상기 애플리케이션 기술로부터 탑-레벨 정의를 선택하는 단계;

   인스턴스 스페이스에 대하여 상기 탑-레벨 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하는 단계;

   상기 탑-레벨 정의 내에 내포되어 있는 부가적 정의를 선택하는 단계;

   상기 선택된 부가적 정의가 오브젝트를 정의하는지 또는 관계를 정의하는지에 기초하여 상기 인스턴스 스페이스에 대하여 상기 부가적 정의에 의하여 기술되는 바와 같이, 인스턴스를 생성하는 단계; 및

   상기 탑-레벨 정의 내에 내포되어 있는 모든 정의들에 대한 인스턴스들이 상기 인스턴스 스페이스에 대하여 생성될 때까지, 부가적 정의의 선택 및 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하는 것을 계속하는 단계

   를 포함하는 방법을 수행하도록 하는 컴퓨터 판독 가능 기록 매체.
5. 삭제
6. 제4항에 있어서,

   상기 1 이상의 프로세서로 하여금 상기 시뮬레이션된 환경에 대하여 상기 애플리케이션을 검증하게 하는 상기 명령문들은 상기 1 이상의 프로세서로 하여금 추가적으로,

   상기 애플리케이션을 기술하는 인스턴스 스페이스에서의 1 이상의 제한 조건(constraint)을 식별하는 단계,

   상기 1 이상의 제한 조건이 만족되는지 여부를 검사하는 단계, 및

   상기 1 이상의 제한 조건의 각각에 대하여, 상기 제한 조건이 만족되는지 여부를 나타내는 값을 리턴(return)하는 단계를 수행하도록 하는 컴퓨터 판독 가능 기록 매체.
7. 소프트웨어 애플리케이션을 데이터 센터의 한 영역에 배치하는 것을 시도하기 전에, 상기 데이터 센터의 환경에서 사용되도록 설계 중인 상기 소프트웨어 애플리케이션의 검증을 용이하게 하는 장치로서,

   로더(loader)가 로딩을 하게 하기 위해서 소프트웨어 애플리케이션을 기술하는 1 이상의 문서에 에러가 있는지 검사(check)하도록 구성된 검증기(verifier),

   상기 소프트웨어 애플리케이션을 기술하는 상기 1 이상의 문서를 로딩하도록 구성된 상기 로더 - 상기 1 이상의 문서가 로딩될 때 상기 소프트웨어 애플리케이션은 설계 중임 -,

   데이터 센터(data center)의 환경을 시뮬레이션하고 - 상기 환경은 상기 데이터 센터의 기술을 포함함 - , 상기 데이터 센터로의 배치 이전에 상기 환경에 대하여 상기 소프트웨어 애플리케이션을 검증하여, 그 검증 결과를 리턴하도록 구성된 시뮬레이터, 및

   상기 1 이상의 문서 중 하나로부터 탑-레벨 정의를 식별하고, 상기 탑-레벨 정의에 내포되어 있는 멤버들을 인스턴스화(instatiate)함으로써 인스턴스 스페이스를 파퓰레이팅(populating)하도록 상기 탑-레벨 정의를 확장하기 위한 확장 엔진을 포함하고,

   상기 확장 엔진은,

   상기 탑-레벨 정의 내에 내포되어 있는 부가적 정의를 선택하며,

   상기 선택된 부가적 정의가 오브젝트를 정의하는지 또는 관계를 정의하는지에 기초하여 상기 인스턴스 스페이스에 대하여 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하고,

   상기 탑-레벨 정의 내에 내포되어 있는 모든 정의들에 대한 인스턴스들이 상기 인스턴스 스페이스에 대하여 생성될 때까지, 부가적 정의의 선택 및 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하는 것을 계속하는,

   소프트웨어 애플리케이션의 검증을 용이하게 하는 장치.
8. 다수의 명령문들을 저장하는 1 이상의 컴퓨터 판독 가능 기록 매체로서,

   상기 다수의 명령문들은 1 이상의 프로세서에 의해 실행될 때, 상기 1 이상의 프로세서로 하여금,

   데이터 센터의 환경 내에서 사용되도록 하기 위해 설계 중인 시스템을 기술하는 문서에 액세스하고,

   상기 문서로부터 탑-레벨 정의를 선택하며,

   인스턴스 스페이스에 대하여 상기 탑-레벨 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하고,

   상기 탑-레벨 정의 내에 내포되어 있는 부가적 정의를 선택하며,

   상기 선택된 부가적 정의가 오브젝트를 정의하는지 또는 관계를 정의하는지에 기초하여 상기 인스턴스 스페이스에 대하여 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하고,

   상기 탑-레벨 정의 내에 내포되어 있는 모든 정의들에 대한 인스턴스들이 상기 인스턴스 스페이스에 대하여 생성될 때까지, 부가적 정의의 선택 및 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하는 것을 계속하도록 하는 컴퓨터 판독 가능 기록 매체.
9. 제8항에 있어서,

   상기 선택된 부가적 정의가 관계를 정의하는 경우에, 상기 부가적 정의에 의하여 기술되는 바와 같이, 상기 1 이상의 프로세서가 인스턴스를 생성하도록 하는 상기 명령문들은 상기 1 이상의 프로세서로 하여금 추가적으로,

   상기 정의된 관계에 관여하는 소스 인스턴스들(source instances)의 수와 목적 인스턴스들(target instances)의 수에 기초하여, 생성할 관계 인스턴스들의 수를 식별하고,

   상기 식별된 수의 관계 인스턴스들을 생성하며,

   상기 생성된 관계 인스턴스들의 각각에 대하여, 소스 및 목적 인스턴스들을 상기 관계 인스턴스와 연관시키도록 하는 컴퓨터 판독 가능 기록 매체.
10. 다수의 명령문들을 저장하는 1 이상의 컴퓨터 판독 가능 기록 매체로서,

    상기 다수의 명령문들은 1 이상의 프로세서에 의하여 실행될 때, 상기 1 이상의 프로세서로 하여금,

    데이터 센터의 환경 내에서 사용되도록 설계 중인 시스템을 기술하는 인스턴스 스페이스에서의 1 이상의 플로우를 식별하고,

    상기 1 이상의 플로우 중 적어도 하나의 각각에 대하여:

    상기 플로우에 대한 1 이상의 입력 값을 식별하고 - 상기 입력 값은 상기 인스턴스 스페이스의 다른 인스턴스로부터 획득됨 -,

    상기 입력 값들에 적어도 일부 기초하여, 상기 플로우에 대한 출력 값을 생성하도록 하고,

    상기 1 이상의 프로세서로 하여금, 상기 입력 값들에 적어도 일부 기초하여, 상기 플로우에 대한 출력 값을 생성하도록 하는 명령문들은, 상기 1 이상의 프로세스로 하여금 추가적으로,

    결과를 생성하도록 실행될 수 있는 상기 플로우와 연관된 1 세트의 명령문을 식별하고,

    상기 식별된 세트의 명령문을 실행하며,

    상기 생성된 결과를 상기 플로우에 대한 출력 값으로서 사용하도록 하는,

    컴퓨터 판독 가능 기록 매체.
11. 제10항에 있어서,

    상기 1 이상의 프로세서가 상기 플로우에 대한 1 이상의 입력 값을 식별하도록 하는 상기 명령문들은 상기 1 이상의 프로세서로 하여금 추가적으로,

    상기 입력 값이 이미 할당되었는지 여부를 식별하고,

    상기 입력 값이 할당되었다면, 상기 다른 인스턴스로부터의 상기 입력 값을 획득하며,

    상기 입력 값 중 적어도 하나가 아직 할당되지 않았다면, 아직 할당되지 않은 상기 입력 값의 각각에 대하여:

    상기 입력 값을 설정하는 하나의 다른 플로우를 식별하고,

    상기 다른 플로우에 대한 1 이상의 입력 값을 식별하며 - 상기 입력 값은 상기 인스턴스 스페이스의 다른 인스턴스로부터 획득됨 -,

    상기 입력 값에 적어도 일부 기초하여, 상기 다른 플로우에 대한 출력 값을 생성하도록 하는 컴퓨터 판독 가능 기록 매체.
12. 다수의 명령문들을 저장하는 1 이상의 컴퓨터 판독 가능 기록 매체로서,

    상기 다수의 명령문들은 1 이상의 프로세서에 의하여 실행될 때, 상기 1 이상의 프로세서로 하여금,

    데이터 센터의 환경 내에서 사용되도록 설계 중인 시스템을 기술하는 인스턴스 스페이스에서의 1 이상의 제한 조건을 식별하고,

    상기 1 이상의 제한 조건이 만족되는지 여부를 검사하며,

    상기 1 이상의 제한 조건의 각각에 대하여, 상기 제한 조건이 만족되어 있는지 여부를 나타내는 값을 리턴하도록 하고,

    상기 1 이상의 프로세서로 하여금 상기 1 이상의 제한 조건이 만족되는지 여부를 검사하도록 하는 상기 명령문들은, 상기 제한 조건들 중 하나에 대하여, 상기 1 이상의 프로세서로 하여금 추가적으로,

    결과를 생성하도록 실행될 수 있는 상기 제한 조건과 연관된 1 세트의 명령문을 식별하고,

    상기 식별된 세트의 명령문을 실행하며,

    상기 생성된 결과를 상기 제한 조건이 만족되는지 여부를 나타내는 리턴되는 값으로서 사용하도록 하는,

    컴퓨터 판독 가능 기록 매체.
13. 제12항에 있어서,

    상기 1 이상의 프로세서로 하여금 상기 1 이상의 제한 조건이 만족되는지 여부를 검사하도록 하는 상기 명령문들은, 상기 1 이상의 프로세서로 하여금 추가적으로,

    상기 제한 조건 중 하나에 대하여,

    일치 횟수 변수(match count variable)를 초기화하고,

    상기 제한 조건의 목적 인스턴스가 참여하는(participates in) 1 이상의 관계 인스턴스를 식별하며,

    상기 1 이상의 관계 인스턴스의 각각에 대하여, 상기 관계 인스턴스가 상기 제한 조건을 만족시키는지 여부를 평가하고,

    상기 제한 조건을 만족시키는 상기 1 이상의 관계 인스턴스의 각각에 대하여 상기 일치 횟수 변수를 증가(increment)시키며,

    상기 1 이상의 관계 인스턴스가 평가된 후에 상기 일치 횟수 변수의 값에 기초하여, 상기 제한 조건이 만족되는지 여부를 나타내는 리턴되는 값을 생성하도록 하는 컴퓨터 판독 가능 기록 매체.
14. 소프트웨어 애플리케이션을 데이터 센터의 한 영역에 배치하는 것을 시도하기 전에, 상기 데이터 센터의 환경에서 사용되도록 설계 중인 상기 소프트웨어 애플리케이션의 검증을 용이하게 하는 장치로서,

    로더가 로딩을 하게 하기 위해서 소프트웨어 애플리케이션을 기술하는 1 이상의 문서에 에러가 있는지 검사하도록 구성된 검증기;

    상기 소프트웨어 애플리케이션을 기술하는 상기 1 이상의 문서를 로딩하도록 구성된 상기 로더;

    데이터 센터의 환경을 시뮬레이션하고 - 상기 환경은 상기 데이터 센터의 기술을 포함함 - , 상기 데이터 센터로의 배치 이전에 상기 환경에 대하여 상기 소프트웨어 애플리케이션을 검증하여, 그 검증 결과를 리턴하도록 구성된 시뮬레이터;

    상기 1 이상의 문서 중 하나로부터 탑-레벨 정의를 식별하고, 상기 탑-레벨 정의에 내포되어 있는 멤버들을 인스턴스화함으로써 인스턴스 스페이스를 파퓰레이팅하도록 상기 탑-레벨 정의를 확장하기 위한 확장 엔진;

    인스턴스 스페이스에서의 플로우를 식별하고, 상기 플로우에 대한 입력들의 값을 식별하고, 상기 플로우에 대한 입력들에 기초하여 상기 플로우의 출력을 설정하도록 구성된 플로우 엔진; 및

    상기 인스턴스 스페이스에서의 제한 조건을 식별하고 평가하도록 구성된 제한 조건 엔진을 포함하고,

    상기 확장 엔진은,

    상기 탑-레벨 정의 내에 내포되어 있는 부가적 정의를 선택하며,

    상기 선택된 부가적 정의가 오브젝트를 정의하는지 또는 관계를 정의하는지에 기초하여 상기 인스턴스 스페이스에 대하여 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하고,

    상기 탑-레벨 정의 내에 내포되어 있는 모든 정의들에 대한 인스턴스들이 상기 인스턴스 스페이스에 대하여 생성될 때까지, 부가적 정의의 선택 및 상기 부가적 정의에 의하여 기술되는 바와 같이 인스턴스를 생성하는 것을 계속하고,

    상기 장치는,

    상기 데이터 센터로부터 분리되고,

    적어도 일부가 컴퓨터 하드웨어 컴포넌트로 구성되는

    소프트웨어 애플리케이션의 검증을 용이하게 하는 장치.
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제

Images