KR101087439B1

KR101087439B1 - 소프트웨어 컴포넌트화

Info

Publication number: KR101087439B1
Application number: KR1020040069530A
Authority: KR
Inventors: 라즈 잔워; 비자야찬드란 자야셀란; 마이클존 그리어; 마이클제임스 데이; 브라이언 맥네일
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-09-02
Filing date: 2004-09-01
Publication date: 2011-11-25
Also published as: CN1617097A; EP1521172A2; US7562346B2; CN100426223C; US20040093593A1; KR20050024227A; EP1521172A3; JP2005078650A

Abstract

파일들을 나타내는 컴포넌트화 스키마(componentization schema)로부터 오퍼레이팅 시스템 또는 다른 소프트웨어 제품이 제작된다. 이 스키마에 따르면, 컴포넌트 객체는 하나 이상의 파일을 나타낸다. 컴포넌트 객체는 컴포넌트를 식별하고 이 컴포넌트와 다른 객체들 사이의 임의의 의존관계들을 지정하는 매니페스트를 갖는다. 매니페스트에 지정된 의존관계들에 따라 객체들을 그룹화함으로써 소프트웨어 제품을 제작할 수 있다. 적어도 하나의 컴포넌트 객체에 의해 정의된 특징 객체는 소프트웨어 제품의 특징을 나타내고, 적어도 하나의 특징 객체에 의해 정의된 제품 객체는 소프트웨어 제품을 나타낸다.

컴포넌트화, 매니페스트, 객체, 컴포넌트 정의 스키마

Description

소프트웨어 컴포넌트화{SOFTWARE COMPONENTIZATION}

도 1은 본 발명의 실시예들에 따른 예시적인 컴퓨터를 나타내는 블록도.

도 2는 도 1의 컴포넌트 및 대응하는 매니페스트를 나타내는 예시적인 블록도.

도 3 내지 도 8은 본 발명의 실시예들에 따른 예시적인 컴포넌트 정의 스키마를 나타낸 도면.

도 9 내지 도 12는 도 3 내지 도 8의 컴포넌트 정의 스키마의 객체를 더 상세히 나타낸 도면.

도 13은 소프트웨어 제품에 포함될 컴포넌트들을 선택하기 위한 본 발명의 실시예들에 따른 예시적인 설계 프로세스를 나타낸 도면.

도 14는 본 발명의 실시예들에 따른 예시적인 프로그래밍 객체 모델을 나타낸 도면.

도 15는 도 3 내지 도 8의 컴포넌트 정의 스키마와 함께 사용하기 위한 예시적인 컴포넌트화 아키텍처를 나타낸 블록도.

도 16은 도 1을 사용하기 위한 컴퓨터의 예시적인 컴포넌트를 나타낸 블록도.

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

150: 컴퓨터

152: 오퍼레이팅 시스템

154: 애플리케이션

156: 컴포넌트

158: 매니페스트

본 발명의 실시예들은 소프트웨어 아키텍처 분야에 관한 것이다. 상세하게는, 본 발명의 실시예들은 오퍼레이팅 시스템을 비롯한 소프트웨어 제품의 컴포넌트화된 아키텍처에 관한 것이다.

소프트웨어 제품이 더 커지고 더 복잡해짐에 따라, 기존의 소프트웨어 제품에 기초하여 새로운 제품을 제작하고 또 시장 및 경쟁적 요구사항에 의해 요구되는 바에 따라 이들 제품을 서비스하는 것이 점점 더 어려워지고 있다. 오퍼레이팅 시스템(OS)은 비교적 크고 복잡한 소프트웨어 제품의 일례이다.

오퍼레이팅 시스템은 그 자신이 존재하는 컴퓨터 또는 장치의 자원을 관리하고 스케쥴링하며, 또 여러가지 태스크를 달성하기 위해 애플리케이션들에 의해 사용될 수 있는 여러가지 기능 모듈 및 인터페이스를 제공한다. 종래의 컴퓨터는 일반적으로 그 컴퓨터가 동작 중일 때 그 컴퓨터의 여러가지 측면들을 관리하기 위해 그의 오퍼레이팅 시스템을 실행한다. 예를 들어, 오퍼레이팅 시스템은 일반적으로 저장 장치는 물론 입력 장치 및/또는 출력 장치에 대한 액세스를 관리하고 또 하나 이상의 부가의 애플리케이션의 실행을 제어하는 일을 맡고 있다. 설치는 보통 컴퓨터가 오퍼레이팅 시스템을 실행하기 이전에 (예컨대, CD-ROM 등의 배포 매체로부터의 다수의 파일을 컴퓨터의 하드 디스크 상으로 복사함으로써) 행해진다.

종래의 오퍼레이팅 시스템은 많은 수(예를 들어, 수천개)의 명령어 및/또는 데이터 파일을 가지고 있다. 이러한 명령어는 컴퓨터에 의해 실행될 때 오퍼레이팅 시스템의 기능을 제공한다. 많은 수의 파일 이외에, 오퍼레이팅 시스템은 보통 파일들 간에 많은 수의 의존 관계를 갖는다. 예를 들어, 다수의 파일들은 그의 의도한 기능이 수행되도록 하기 위해 하나 이상의 다른 파일들의 설치를 필요로 할 수 있다. 오퍼레이팅 시스템의 제작업자는 설치 시에 이러한 의존 관계들에 관해 알고 있을 수 있지만, 사용자, 관리자 또는 다른 소프트웨어 개발자가 이러한 의존 관계들에 관해 안다는 것은 어려울 수 있다. 이것은 성가신 것임을 입증할 수 있는데, 그 이유는 다른 파일들에 있는 어느 데이터 또는 명령어가 소프트웨어 개발자가 관심을 갖고 있는 특정의 파일(들)에 영향을 주는지를 소프트웨어 개발자가 알지 못할 수 있기 때문이다. 이와 마찬가지로, 오동작하는 컴퓨터의 문제를 해결하는 관리자 또는 사용자는 그 의존 관계들을 모르고서는 어느 파일이 그 문제에 적용될 수 있는지를 모를 수 있다.

게다가, 통상의 오퍼레이팅 시스템은 일반적으로 특성상 모놀리식(monolithic)하다. 당업자라면 종래의 오퍼레이팅 시스템에 익숙하며, 이 경우 서버 및 클라이언트 OS 제품은 둘다 모든 바이너리 파일을 포함하는 거대한 중심 파 일로부터 제작된다. 이 예에서, 셋업 실행 파일은 서로 다른 제품 내에 어느 파일들이 포함되어 있는지를 지정해야만 한다. 따라서, 각 제품의 여러가지 부분들 사이의 관계를 이해하기가 어렵다. 이러한 정보의 부족은 오퍼레이팅 시스템의 라이프 사이클 동안 그의 부분들에 서비스하는 것을 방해한다. 즉, 오퍼레이팅 시스템이 더 커지고 더 복잡해짐에 따라 오퍼레이팅 시스템의 서로 다른 모듈들 및 파일들이 전체적으로 및 개별적으로 제대로 동작하도록 하기 위해 개발자 및 다른 사람이 그 모듈 및 파일 모두를 추적하는 것이 더욱 어려워지고 있다.

예로서, 특정의 OS 제품이 "홈" 버전으로 판매될 수 있는 반면, 부가의 특징들을 갖는 프리미엄 제품이 "프로페셔널" 버전으로 판매될 수 있다. 이 예에서, 홈 제품 및 프로페셔널 제품은 종종 개별적인 제품을 구성하는 많은 바이너리 파일들에 걸쳐 산재되어 있는 제품 표시 정보 및 기타 참조를 포함하게 될 것이다. 불행하게도, 제품의 제작 및 그에 대한 서비스는 아주 힘드는 일이며 바이너리 파일들 간의 관계 및 이들 제품 표시 참조(이 각각은 새 제품에 대해 변경되어야 함)의 존재로 인해 광범위한 테스트를 필요로 한다.

오퍼레이팅 시스템은 하나 이상의 특정의 바이너리 파일을 추가 또는 대체하는 것에 의해, 다양한 사람들(예를 들어, 사용자, 관리자, 오퍼레이팅 시스템 개발자 이외의 소프트웨어 개발자 등)에 의해서와 같은 임의의 여러가지 방식으로 수정(예를 들어, 업데이트 또는 서비스)될 수 있다. 이러한 수정이 있는 경우, 그 수정은 컴퓨터 상에 존재하는 파일들 사이의 의존 관계를 확인하는 것의 어려움을 증대시킨다. 예를 들어, 단일 파일에 대한 변경은 다른 의존하는 파일들에 대한 변 경을 필요로 할 수 있다. 또한, 사용자 또는 관리자가 컴퓨터 상에 어느 기능이 설치되어 있는지 또는 설치되어 있어야만 하는지를 정확하게 아는 것이 쉽지 않기 때문에 오동작하는 컴퓨터의 문제를 해결하거나 오퍼레이팅 시스템을 업데이트하는 것이 훨씬 더 어려워진다.

따라서, 하나 이상의 이러한 단점 및 기타의 단점을 해소하고 또 그 중에서도 특히 개선된 오퍼레이팅 시스템을 제작할 수 있게 하기 위해서는 소프트웨어 컴포넌트화가 요망된다.

본 발명의 실시예들은 오퍼레이팅 시스템 등의 소프트웨어 제품을 컴포넌트의 집합으로서 표현함으로써 종래 기술에서의 하나 이상의 결점을 극복한다. 본 발명의 한 측면은 컴포넌트화된 방식으로 소프트웨어 제품을 제작하기 위해 몇가지 추상화를 도입하는 것을 포함한다. 이와 같이, 본 발명의 실시예들은 컴포넌트화된 제품에 기초하여 새로운 제품을 제작하는 것과 그 제품에 대한 서비스를 제공하는 것을 용이하게 해준다. 애플리케이션 컴포넌트를 일반적으로 기술하기 위해 컴포넌트 정의가 사용될 수 있는데, 즉, 어떤 애플리케이션도 이 컴포넌트 정의를 사용하여 기술될 수 있다. 다른 대안에서, 컴포넌트 정의는 오퍼레이팅 시스템 컴포넌트를 보다 구체적으로 기술하는데 사용될 수 있다. 게다가, 본 명세서에 기술된 본 발명의 특징은 현재 이용가능한 기술보다 구현하기가 덜 힘들고 보다 용이함은 물론 경제적으로 실현성이 있고 상업적으로 실시가능하다는 것이다.

간단히 말하면, 본 발명의 특징들을 구현하는 방법은 복수의 파일로부터 소 프트웨어 제품을 제작하는 단계를 포함한다. 본 방법은 파일을 객체로 구성하는 단계를 포함한다. 이 예에서, 복수의 객체는 컴포넌트를 나타내며, 이 컴포넌트 각각은 적어도 하나의 파일을 포함한다. 본 방법은 또한 매니페스트(manifest)를 사용하여 각각의 컴포넌트를 식별하는 단계와 그 매니페스트를 사용하여 컴포넌트들과 기타 객체들 사이에 하나 이상의 의존관계를 지정하는 단계를 포함한다. 매니페스트에 지정된 의존관계들에 따라 객체들을 그룹화함으로써 소프트웨어 제품의 제작을 할 수 있다.

본 발명의 다른 실시예는 하나 이상의 컴퓨터 판독가능 매체에 관한 것이다. 복수의 컴포넌트 객체를 비롯하여 매체 상에 저장된 객체들은 복수의 파일로부터 소프트웨어 제품을 제작하는데 사용된다. 각각의 컴포넌트 객체는 하나 이상의 파일 및 매니페스트를 포함한다. 매니페스트는 컴포넌트 객체를 식별해주고 컴포넌트 객체들과 하나 이상의 다른 객체들 사이의 의존관계를 지정하는 메타데이터를 포함한다. 이 매체는 또한 소프트웨어 제품의 특징에 대응하는 적어도 하나의 특징 객체(feature object)를 포함한다. 특징 객체는 매니페스트에 지정된 의존관계에 따라 그룹화된 하나 이상의 선택된 객체를 포함한다.

또 다른 실시예에서, 컴포넌트화 스키마는 하나 이상의 파일을 나타내는 것으로, 이로부터 소프트웨어 제품이 컴포넌트 객체를 사용하여 제작된다. 컴포넌트 객체와 관련된 매니페스트는 그 객체를 식별하며 컴포넌트 객체들과 적어도 하나의 다른 객체들 사이에 하나 이상의 의존관계를 지정한다. 스키마는 또한 특징 객체 및 제품 객체도 포함한다. 적어도 하나의 컴포넌트 객체에 의해 정의되는 특징 객 체는 소프트웨어 제품의 특징을 나타낸다. 적어도 하나의 특징 객체에 의해 정의되는 제품 객체는 소프트웨어 제품을 나타낸다.

컴포넌트화 방법을 수행하기 위한 컴퓨터 실행가능 명령어를 갖는 컴퓨터 판독가능 매체는 본 발명의 추가의 특징을 구현한다.

다른 대안에서, 본 발명은 여러가지 다른 방법 및 장치를 포함할 수 있다.

다른 특징들은 부분적으로는 자명한 것이고 또 부분적으로는 이후에 지적될 것이다.

도면 전체에 걸쳐 대응하는 참조 번호는 대응하는 부분을 나타낸다.

이제 도면들을 참조하면, 도 1은 본 발명의 어떤 실시예들에 따른 예시적인 컴퓨팅 장치(150)를 나타낸 것이다. 컴퓨팅 장치(150)는 오퍼레이팅 시스템(152) 및 하나 이상의 애플리케이션 프로그램(154) 등의 소프트웨어 제품을 갖는 것으로 도시되어 있다.

오퍼레이팅 시스템(152)은 컴퓨팅 장치(150)의 기본적인 소프트웨어 제어 프로그램으로서, 사용자 인터페이스를 제공하는 것, 하나 이상의 애플리케이션(154)의 실행을 관리하는 것, 및 여러가지 입력/출력(I/O) 장치로의 데이터 입력 및 그로부터의 데이터 출력을 제어하는 것을 포함하여 여러가지 기능을 수행한다. 애플리케이션 프로그램(154)은 컴퓨팅 장치(150) 상에서 실행될 수 있는 하나 이상의 여러가지 소프트웨어 애플리케이션 프로그램을 나타낸다. 이러한 애플리케이션 프로그램(154)의 예는 교육 프로그램, 참조 프로그램, 생산성 프로그램(예를 들어, 워드프로세서, 스프레드쉬트, 데이터베이스), 오락 프로그램, 유틸리티 프로그램(예를 들어, 통신 프로그램) 등을 포함한다. 애플리케이션 프로그램(154)은 사용자에 의해 컴퓨팅 장치(150) 상에 설치될 수 있거나 또는 다른 대안에서는 컴퓨팅 장치(150)의 제조업자 및/또는 판매업자에 의해 사전 설치될 수 있다.

도 1의 오퍼레이팅 시스템(152)은 예시된 실시예에서 그의 기능을 컴포넌트 #1 내지 컴포넌트 #N 등의 다수의 컴포넌트(156)로 분리한다. 각각의 컴포넌트(156)는 각각 매니페스트 #1 내지 매니페스트 #N 등의 대응하는 매니페스트(158)를 갖는다. 컴포넌트(156)는 하나 이상의 파일(또는 파일 식별자)의 집합을 포함한다. 파일은 실행가능 파일, 동적 링크 라이브러리(DLL) 또는 컴포넌트 객체 모듈(COM) 등의 소프트웨어 명령어를 포함할 수 있다. 파일은 또한 하나 이상의 컴포넌트(156)가 사용하기 위한 데이터를 포함할 수 있다. 한 구현에서, 오퍼레이팅 시스템(152)의 특정의 기능에 대응하는 파일(예를 들어, 데이터 및/또는 명령어)은 동일한 컴포넌트(156)내에 함께 그룹화되어 있다. 예를 들어, 게임 컴포넌트, 통신 컴포넌트 및 파일 시스템 컴포넌트가 있을 수 있다. 컴포넌트화를 가져오는 파일의 그룹화는 정적일 수 있거나 다른 대안에서는 시간에 따라 변할 수 있다. 한 예에서, 오퍼레이팅 시스템(152)에 대한 업데이트의 결과 어떤 컴포넌트(156)로부터의 선택된 파일들이 제거되어 다른 컴포넌트(156)에 부가될 수 있다.

또한 도 1을 참조하면, 각각의 매니페스트(manifest)(158)는 대응하는 컴포넌트(156)를 기술하는 정보를 포함한다. 대응하는 컴포넌트(156)에 관한 임의의 여러가지 메타데이터가 각각의 매니페스트(158)에 포함될 수 있다. 한 구현에서, 매니페스트(158)는 대응하는 컴포넌트(156)의 버전은 물론 대응하는 컴포넌트(156)가 의존하고 있는 어떤 다른 컴포넌트(156)가 있는 경우 그 컴포넌트를 식별해준다. 예로서, 컴포넌트(156) 내의 하나 이상의 파일이 제대로 실행되기 위해서는, 다른 컴포넌트로부터의 하나 이상의 다른 파일(예를 들어, DLL 파일)이 컴퓨팅 장치(150) 상에 설치될 필요가 있다. 이 예에서, 매니페스트(158)는 컴포넌트(156)가 다른 컴포넌트에 의존함을 나타낼 것이다.

기존의 오퍼레이팅 시스템의 복잡성 및 크기로 인해, 시장 또는 경쟁적 요구 사항을 만족시키는 새 제품을 제작하는 것이 점점 더 어려워지고 있다. 현재의 오퍼레이팅 시스템은 특성상 더욱 모놀리식하며, 따라서 여러가지 구성 부분들 사이의 관계를 이해하는 것이 어려울 수 있다. 이러한 정보의 부족은 제품의 라이프 사이클 동안 오퍼레이팅 시스템에 대한 서비스를 제공하는 것을 아주 어렵게 만든다. 이들 문제 및 다른 문제를 극복하기 위해, 본 발명의 실시예들은 오퍼레이팅 시스템을 컴포넌트화한다. 즉, 본 발명은 소프트웨어 제품을 컴포넌트의 집합으로 표현할 수 있게 해준다. 본 발명의 측면들은 새로운 제품을 제작하는 것 및 기존의 제품에 대한 서비스를 제공하는 것을 용이하게 해주기 위해 컴포넌트화된 방식으로 오퍼레이팅 시스템을 제작하는데 사용되는 몇가지 추상화를 포함한다. 추상화는 애플리케이션 프로그램 및 임의의 오퍼레이팅 시스템을 비롯한 임의의 소프트웨어 제품에 적용될 수 있다.

본 발명의 특징을 대표하는 컴포넌트 정의 스키마는 몇가지 추상화, 즉 컴포넌트(또한 어셈블리라고도 함), 카테고리, 특징, 패키지, 제품 및 SKU(stock keeping unit, 재고 관리 단위)를 도입한다. 이 예에서, 컴포넌트(156)는 배포, 서비스 제공 및/또는 바인딩의 재사용가능하고 공유가능하며 자기 설명적인 최소 단위(atomic unit)를 나타낸다. 가장 기본적인 추상화가 컴포넌트 자체와, 설치, 서비스 제공 및/또는 선언적 방식으로 필요한 자원에 바인딩하기 위해 사용되는 모든 관련 정보(즉, 메타데이터)를 기술한다는 것이다.

본 발명의 일 실시예에 관해 이하에 보다 상세히 기술하는 바와 같이, 카테고리 객체(162)(도 4 참조)는 컴포넌트(156)의 공통 집합을 그룹화하기 위한 메카니즘을 나타내고, 특징 객체(164)(도 5 참조)는 컴포넌트(156) 및/또는 특징(164)의 합성을 나타내며 또 제품 객체(166)(도 7 참조)를 작성하기 위한 구성 블록으로서 사용되고, 패키지 객체(168)(도 6 참조)는 컴포넌트(156), 특징(164), 카테고리(162) 및/또는 기타 패키지(168)의 합성을 나타낸다. 예로서, 패키지 객체(168)는 관리 목적을 위해 한 세트의 컴포넌트(156)를 그룹화하는데 사용된다. 게다가, 이 실시예에서의 제품 객체(166)는 특징(164) 및/또는 컴포넌트(156)의 최상위 레벨 합성을 나타내며, SKU 객체(170)(도 8 참조)는 제품(166)의 출하 메카니즘을 나타낸다[예를 들어, 하나의 SKU(170)는 다수의 제품(166)을 포함할 수 있다].

본 명세서에 기술되는 컴포넌트 정의는 오퍼레이팅 시스템 컴포넌트를 구체적으로 기술하기보다는 애플리케이션 컴포넌트를 일반적으로 기술하는데 사용될 수도 있다. 즉, 임의의 애플리케이션은 이 컴포넌트 정의를 사용하여 기술될 수 있다.

본 발명의 실시예들에 따른 컴포넌트화 아키텍처는 설계시와 실행시 양쪽 동 안에 컴포넌트를 관리하기 위한 개념, 컴포넌트 저장소 및 프로그래밍 모델을 정의한다. 민첩성, 속도, 지원성 및 증가된 수익 기회를 비롯한 컴포넌트화의 몇가지 전략적 이점이 있다. 제품 또는 SKU 객체로 표현되는 새로운 소프트웨어 제품의 제작은 심지어 클라이언트 및 서버 제품 전반에 걸쳐서도 훨씬 더 쉽게 이루어 진다. 새 제품을 제작하는 것은 올바른 컴포넌트를 선택하고 어떤 부가의 구성을 제공하는 비교적 간단한 작업이다. 비교적 짧은 시간 내에 새 제품을 제작함에 있어서의 민첩성은 효율적으로 경쟁하고 시장 기회를 놓치지 않도록 할 수 있게 해준다. 예를 들어, 현재의 제품에 나중에 부가할 부가의 컴포넌트를 제공하는 것이 가능하며, 이는 고객이 프리미엄 제품으로 업그레이드할 수 있게 해주어 라이센스의 총수 등을 증대시킨다. 이러한 부가의 행위들 모두는 제품에 대한 부가의 수익을 가져올 수 있다.

컴포넌트화는 또한 OEM(original equipment manufacturer, 주문자 상표 부착 생산자) 또는 회사가 유지해야만 하는 제품 이미지의 수의 감축을 용이하게 해주며, 이는 상당한 비용 절감을 가져올 수 있다. 본 발명의 적어도 하나의 실시예에 따르면, 컴포넌트 정보의 대부분은 컴포넌트가 오프라인 방식으로 설치될 수 있도록 선언적이다. 이것은 목표 장치 상에 전체 제품을 설치하는데 걸리는 시간을 줄여주며 그 결과 OEM, 회사, 최종 사용자 등에 대한 상당한 비용 절감이 있게 됨은 물론 고객 만족 증대를 가져온다.

당업자라면 제품 사이클의 일부로서 서비스의 중요성을 잘 알고 있다. 본 발명의 실시예들에 따라 컴포넌트화된 제품에 대한 서비스 제공은 비교적 간단하 며, 그 이유는 각각의 컴포넌트에 의해 제공되는 선언적 정보에 기초하여 변경의 영향을 평가하는 것이 용이하기 때문이다. 또한, 테스트 효율을 향상시키기 위해 보다 격리된 환경에서 컴포넌트를 테스트하는 것이 훨씬 더 용이하다. 이에 따라, 이것은 소프트웨어 제품에서의 전체적인 취약성을 감소시킨다.

본 명세서에 기술된 컴포넌트 정의 스키마는 설치, 서비스의 업그레이드 및 적절한 자원에 대한 바인딩을 위해 컴포넌트(156)가 기술하는 정보를 포함한다. 이 점에서, 도 2는 본 발명의 어떤 실시예들에 따른 예시적인 컴포넌트(156) 및 대응하는 매니페스트(158)를 나타낸 것이다. 본 발명의 실시예들에 따르면, 각각의 컴포넌트(156)는 대응하는 매니페스트(158)에 의해 표현된다. 컴포넌트(156)는 적어도 하나의 파일(174)을 포함하며, 선택적으로 2개 이상(n개)의 파일을 포함할 수 있다. 도 2에서 파일로서 나타내어져 있지만, 컴포넌트(156)는 다른 대안에서 실제 파일보다는 오히려 하나 이상의 파일(174)의 포인터 또는 다른 식별자를 포함할 수 있다.

컴포넌트(156)는 매니페스트(158)에 대응한다. 예시된 예에서, 매니페스트(158)는 (예를 들어, 이름 또는 어떤 다른 고유 식별자에 의해) 컴포넌트(156)를 식별하는 컴포넌트 식별자를 포함한다. 이러한 대응관계는 다른 대안에서 컴포넌트(156)에 매니페스트(158)의 식별자(도시 생략)를 포함하는 것, 컴포넌트(156)와 매니페스트(158) 사이의 본질적인 대응관계를 유지하는데이터 구조에 컴포넌트(156)와 매니페스트(158)(또는 이들의 식별자) 둘다를 저장하는 것 등과 같이 여러가지 방식으로 유지될 수 있다. 매니페스트(158)는 XML(extensible markup language, 확장가능 마크업 언어) 문서일 수 있다.

도 2의 예시적인 목록에 나타낸 바와 같이, 매니페스트(158)는 또한 컴포넌트(156)가 의존하고 있는 0개 이상의 컴포넌트를 식별하는 의존 컴포넌트 리스트를 포함한다. 식별된 의존 컴포넌트는 컴포넌트(156)가 제대로 기능하기 위해 오퍼레이팅 시스템 이미지의 일부로서 역시 설치될 필요가 있는 그 컴포넌트이다. 예시된 예에서, 식별자는 컴포넌트(156)가 제대로 기능하기 위해 필요하긴 하지만 다른 대안에서는 포함되어야만 하는 컴포넌트를 포함할 수 있는 컴포넌트(즉, 오퍼레이팅 시스템의 일부로서 가질 컴포넌트(156)에 의해 선호되지만 필요한 것은 아닌 컴포넌트)를 식별한다. 식별자 및 의존관계 이외에, 이 예에서의 매니페스트(158)는 또한 컴포넌트(156)의 여러가지 다른 세부 사항, 즉 일반 정보(소유자, 테스터, 개발자, 설명 등 포함), 자원(파일, 레지스트리 정보 등 포함), 설정(구성), 멤버쉽 및 기타 정보를 기술한다.

대체 실시예에서의 매니페스트(158)는 또한 설치 및/또는 업그레이드를 돕기 위해 우선 순위 및 버전 표시자를 포함할 수 있다.

다른 대안에서, 매니페스트(158)에 유지되는 정보의 일부 또는 그 전부는 서로 다른 장소에 유지될 수 있다. 예로서, 그 정보의 일부 또는 그 전부는 도 1의 컴포넌트(156) 내에 포함될 수 있다.

부록 A의 예는 매니페스트(158)에 관한 본 발명의 측면들을 나타낸 것이다.

이하의 설명은 본 발명의 측면들을 대표하는 컴포넌트화 아키텍처에서 사용되는 주요 추상화에 관한 추가의 상세를 제공한다.

전술한 바와 같이, 컴포넌트(156)(또는 어셈블리)라고 하는 객체는 배포, 서비스 제공, 및 바인딩의 재사용가능하거나 공유가능한 자기 설명적 최소 단위를 나타낸다. 도 3의 실시예에서, 컴포넌트(156)는 실행할 다른 컴포넌트(156) 및/또는 특징(164)에 의존할 수 있는데, 즉 그 컴포넌트는 이들 다른 객체에 관한 의존관계를 보여준다. 컴포넌트(156)는 또한 다른 공개 그룹, 즉 카테고리(162)의 멤버일 수 있다. 이 예에서, "식별자"라고 하는 개발자에 친숙하고 확장성이 있는 다자간 프로퍼티 "백"(multi-part property bag)은 각각의 컴포넌트(156)를 식별한다. 컴포넌트 식별자는 이하의 속성, 예를 들어 이름, 버전, 프로세서 아키텍처, 언어(예를 들어, "미국 영어" 또는 "일본어"), 빌드 타입(build type)[예를 들어, 프리(free) 또는 디버그], 및 창작자 식별 번호를 갖는다. 이름 속성은 일 실시예에서 특정의 컴포넌트(156)를 기술하는 현지-독립형 스트링(locale independent string)의 형태를 갖는다. 일반적으로 예를 들어 "주버전.부버전.빌드번호.개정" (major.minor.build.revision) 포맷을 따르는 4 부분으로 된 버전 번호가 식별자의 버전 속성에 의해 제공된다. 컴포넌트 식별자가 안전할 수 있게 해주는 암호 보안 정보는 식별자의 창작자 ID 속성에서 발견된다.

전술한 바와 같이, 각각의 컴포넌트(156)는 하나 이상의 파일과 관련 매니페스트(158)로 이루어져 있다. 매니페스트(158)는 도 3에 도시한 바와 같이 컴포넌트(156)의 상세를 기술한다. 도 3의 실시예에서, 컴포넌트 또는 어셈블리라고 하는 객체는 다른 컴포넌트(156), 카테고리(162) 및/또는 특징(164)에 관해 의존관계를 가질 수 있다.

도 4에 도시한 카테고리 객체(162)는 멤버쉽 정보가 카테고리 매니페스트에 존재하는 것이 아니라 오히려 카테고리의 멤버와 함께 존재하는 것인 공개 그룹을 정의한다. 예를 들어, 하나의 카테고리(162)가 메모장(Notepad) 및 워드패드(Wordpad) 등의 텍스트 편집기에 관련된 하나 이상의 컴포넌트(156)를 그룹화하기 위해 구축될 수 있다. 카테고리(162)는 또한 컴포넌트(156)의 식별자 메카니즘과 유사한 식별자 메카니즘을 사용하여 식별된다. 일 실시예에서, 카테고리(162)는 식별자, 일반 정보 및 기타 정보 등의 상세를 갖는다.

이제 도 5를 참조하면, 특징 객체(164)는 컴포넌트(156) 및/또는 기타 특징(164)의 합성을 나타낸다. 특징(164)은 소프트웨어 제품 구성 블록으로서 사용되며 설치로부터 부가되거나 제거될 수 있다. 특징(164)은 다른 객체에 의존하기 보다는 오히려 컴포넌트(156), 다른 특징(164) 및 카테고리(162)에 관해 포함적 관계를 갖는다. 즉, 특징(164)은 본 실시예에 따르면 의존관계를 갖지 않는다. 예로서, 하나의 특징 객체(164)는 통합된 웹 브라우저 특징을 나타내며, 다른 특징 객체(164)은 미디어 플레이어 애플리케이션을 나타내고, 둘다 오퍼레이팅 시스템과 함께 출하된다. 특징(164)은 식별자, 일반 정보(예를 들어, 소유자, 테스터, 개발자, 설명 등), 멤버쉽, 합성 및 기타 정보로 이루어져 있다. 본 발명의 일 실시예에서, 특징 식별자는 구조에 있어서 컴포넌트 식별자와 유사하며 각각의 특징(164)을 식별하는데 사용된다. 특징(164)은 다수의 서로 다른 카테고리(162)의 멤버일 수 있다(도 4 참조).

도 6은 패키지 객체(168)를 개략적으로 나타낸 것이다. 도시한 바와 같이, 패키지(168)는 컴포넌트(156), 특징(164), 카테고리(162) 및 기타 패키지(168)의 합성이다. 카테고리(162)와는 달리, 패키지(168)는 폐쇄 그룹(closed group)이다. 패키지(168)는 주로 관리 목적으로 사용된다. 예를 들어, OS의 홈 버전은 "cab1", "cab2", "cab3" 및 "cab4"로 나타낸 4개의 서로 다른 패키지(168)로 출하될 수 있다. 이 예에서 패키지 객체(168)는 셋업 목적으로 형성된 그룹이다. 패키지(168)는 도 6의 실시예에서 다른 패키지(168)에 대한 의존관계만을 지정한다. 본 명세서에 기술된 컴포넌트화 정의에 따른 각각의 패키지(168)는 식별자, 일반 정보, 멤버쉽, 합성, 의존관계, 및 기타 정보 등의 상세로 이루어져 있다.

도 7의 제품 객체(166)는 특징(164) 및/또는 컴포넌트(156)의 최상위 레벨 합성을 나타낸다. 제품 객체(166)는 또한 합성된 특징(164) 및 컴포넌트(156)를 구성하는데 사용되는 프로퍼티를 갖는다. 본 발명의 실시예들에 따라, 제품 설계자는 제품(166)(도 13 참조)의 특징(164)을 선택한다. 제품 객체(166)는 식별자, 일반 정보, 합성 및 기타 정보에 관한 상세를 포함한다.

이제 도 8을 참조하면, SKU 객체(170)는 제품(166)의 출하 매체(즉, 어느 제품이 출하를 위해 디스크 상에 포함되어 있는지)를 나타낸다. 적절한 출하 매체로는 플로피 또는 콤팩트 디스크 그리고 웹 다운로드 캐비넷 파일이 있다. 또한, SKU(170)는 2개 이상의 제품(164)(도 13 참조)으로 이루어질 수 있다. 본 발명의 적어도 하나의 실시예는 SKU 설계자 툴을 사용하여 SKU 매니페스트를 생성한다. 전술한 다른 추상화와 유사하게, SKU(170)는 식별자, 일반 정보, 제품, 및 기타 정보를 포함한다.

도 9 내지 도 12는 또한 컴포넌트(156)와 다른 객체들 사이의 예시적인 관계를 나타낸 것이다. 구체적으로는, 도 9는 컴포넌트(156)가 하나 이상의 카테고리(162), 하나 이상의 특징(164), 및/또는 하나 이상의 다른 컴포넌트(156)에서 발견되는 하나 이상의 바이너리 파일에 의존할 수 있음을 나타낸다. 게다가, 컴포넌트(156)는 카테고리(162)에 멤버쉽을 선언할 수 있다. 도 10의 예시적인 관계도에서, 카테고리(162)는 하나 이상의 특징(164), 하나 이상의 컴포넌트(156), 및/또는 하나 이상의 패키지(168)를 그룹화하는데 사용될 수 있다. 전술한 바와 같이, 카테고리 객체(162)는 다른 객체들이 카테고리 객체에 대한 그의 멤버쉽을 선언하는 공개 그룹을 나타낸다. 도 11은 또한 특징(164)이 하나 이상의 다른 특징(164) 및/또는 컴포넌트(156)을 포함하고 또 특징(164)이 하나 이상의 카테고리(162)에 멤버쉽을 선언할 수 있음을 나타내고 있다. 이제 도 12를 참조하면, 패키지(168)는 하나 이상의 다른 패키지(168), 카테고리(162), 특징(164), 및/또는 컴포넌트(156)의 그룹을 나타낸다. 이 예에서, 패키지(168)는 카테고리(162) 등의 공개 그룹에 속할 수 있거나 다른 패키지(168) 등의 폐쇄 그룹에 의존할 수 있다.

도 13은 특징(164)을 정의하기 위해 OS 바이너리 파일의 여러가지 컴포넌트(156)를 그룹화하는 것의 예를 제공한다. 이어서, 특징(164)은 제품(166)을 정의하기 위해 그룹화되고, 이 제품(166)은 이어서 SKU(170)로 출하하기 위해 포함된다. 서로 다른 컴퓨터는 동일한 오퍼레이팅 시스템에 기초하는 서로 다른 오퍼레이팅 시스템 이미지를 가질 수 있다. 예를 들어, 서로 다른 OEM은 동일한 오퍼레이팅 시스템을 여러가지 방식으로(예를 들어, 오퍼레이팅 시스템이 OEM을 식별하는 초기 화면으로 부트하도록, 서로 다른 디폴트 설정이 사용될 수 있도록, 기타 등등의 방식으로) 커스터마이즈할 수 있다. 서로 다른 기능(예를 들어, 화면 보호기, 배경 또는 테마, 통신 프로그램, 게임 등과 같은 소프트웨어 애플리케이션)이 또한 포함될 수 있다. 이 부가의 기능은 OEM, 또는 다른 대안에서 다른 제조업자 또는 판매업자에 의해 제공될 수 있다. 따라서, 많은 서로 다른 컴포넌트는 오퍼레이팅 시스템의 일부일 수 있으며, 실제로는 그 오퍼레이팅 시스템의 서브셋만이 특정의 컴퓨터 상에 오퍼레이팅 시스템 이미지로서 설치되어 있다. 반면에, OEM-고유의 컴포넌트 및 매니페스트 세트는 OEM에 의해 오퍼레이팅 시스템 이미지의 일부로서 설치될 수 있는 부가의 컴포넌트를 포함한다.

오퍼레이팅 시스템은 임의의 여러가지 이유로 인해 업데이트될 수 있다. 예로서, 어떤 컴포넌트의 어떤 파일에 대한 버그 수정이 이용가능하거나, 컴포넌트 내의 새로운 기능(예를 들어, 교체 또는 부가 파일)이 이용가능하게 될 수 있거나, 새로운 컴포넌트가 이용가능하게 될 수 있거나, 기타 등등이 있다.

게다가, 새로운 컴포넌트가 이전의 컴포넌트를 대체하는 것이 아니라 그 컴포넌트와 나란히 설치될 수 있다. 이것은 서로 다른 애플리케이션이 그가 선호하는(또는 사용하도록 프로그램되어 있는) 어느 버전의 컴포넌트라도 사용할 수 있게 해준다.

예로서, OEM은 가정용, 업무용, 서버용, 기타 등등에 대응하는 여러가지 기본적인 컴퓨터 구성을 제공할 수 있다. 이 예에서의 구성들 각각은 동일한 오퍼레이팅 시스템에 기반하고 있지만 서로 다른 기능을 포함한다. 가정용이나 업무용 구성에 포함되지 않은 부가의 네트워킹 및 통신 기능이 서버 구성에 포함될 수 있으며, 업무용 또는 서버 구성에 포함되지 않은 부가의 게임 또는 오디오 재생 기능이 가정용 구성에 포함될 수 있다. 도 13은 기본적인 가정용 제품을 포함하는 예시적인 프리미엄 제품을 나타낸 것이다.

일 실시예에서, 소프트웨어 제품을 제작하는 것은 제품 객체에서 언급된 컴포넌트의 저장소로부터 런타임 이미지를 작성하는 행위이다. 제작은 일반적으로 오프라인 방식으로 행해진다, 즉 머신 X에 대한 런타임 이미지는 머신 Y 상에서 작성된다. 의존관계는 최상위 레벨 제품으로부터 완전히 분석된다. 의존관계가 분석되면, 의존관계 트리에 있는 각각의 노드는 타겟으로 설치된다. 타겟은 오프라인 방식으로 작성되고 있는 설치를 나타낸다. 각 컴포넌트의 설치는 컴포넌트의 일부인 각각의 자원(예를 들어, 레지스트리 키 및 파일)을 설치하는 것 및 설치 컴포넌트를 추적하기 위해 설치 컴포넌트 저장소에 엔트리를 집어넣은 것을 포함한다.

도 14는 본 발명의 실시예들에 따른 프로그래밍 모델의 제1 레벨 추상화를 나타낸 것이다. 구체적으로 말하면, 예시적인 도면은 예를 들어 UML(Unified Modeling Language, 통합 모델링 언어)를 사용하여 서로 다른 제1 레벨 객체(또는 클래스)를 나타낸 것이다. 이 예에서 객체들은 UML을 사용하여 프로그래머에게 노출된다. 각각의 인터페이스는 컴포넌트화의 제1 레벨 개념으로 직접 매핑된다.

오퍼레이팅 시스템 설치 프로세스는 오퍼레이팅 시스템의 컴포넌트화에 의해 크게 간소화된다. OEM 고유의 기능이 적절한 컴포넌트 및 대응하는 매니페스트를 포함함으로써 컴퓨터에 용이하게 부가될 수 있다. 게다가, 기능의 개선, 버그 수정 등을 위한 오퍼레이팅 시스템의 업데이트는 대응하는 컴포넌트를 간단히 교체함으로써 용이하게 설치 프로세스에 포함될 수 있다. 다른 대안에서, 부가의 업데이트 컴포넌트 및 매니페스트 세트는 이러한 업데이터를 포함하는 오퍼레이팅 시스템 설치 스테이션에서 이용가능하게 될 수 있다.

도 15는 본 발명과 함께 사용하기 위한 예시적인 컴포넌트화 아키텍처를 나타낸 것이다. 도 15에 도시한 확장가능 아키텍처는 컴포넌트의 설치 및 제거를 포함한 OS 설치의 구축을 가능하게 해주며, 또한 제품/SKU 민첩성을 가능하게 해준다. 게다가, 이 아키텍처는 실행중인 OS 및 OS 이미지에 대한 서비스를 제공하기 위한 기반 구조를 제공하고, OS 컴포넌트의 인벤토리를 제공하며, 설치된 시스템 상에 존속한다. 컴포넌트화 아키텍처는 컴포넌트의 작성 및 관리를 위한 일반화된 프레임워크를 제공한다. 이 아키텍처는 또한 일반적 방식으로 구성으로부터 런타임 이미지를 제작하는 것을 가능하게 해준다. 컴포넌트 관리 인터페이스(component management interface, CMI)는 컴포넌트화 아키텍처에 의해 노출되는 기능에 액세스하기 위해 서로 다른 소비자에 의해 사용될 수 있는 프로그래밍 모델 인터페이스이다. 이 툴은 일반적으로 이하의 클래스, 즉 설계시 툴, 실행시 툴, 및 제작시 툴로 분할될 수 있다. 설계시 툴은 설계 시에 사용되는 툴(예를 들어, 컴포넌트를 설계 또는 작성하기 위한 컴포넌트 디자이너 및 구성을 설계 또는 작성하기 위한 타겟 디자이너)이다. 실행시 툴은 런타임 이미지 상의(설치 시에) 기존의 컴포넌트를 관리하는데 사용된다. 이것은 시스템 상에 설치된 컴포넌트를 관리 하는 옵션 컴포넌트 관리자(option component manager, OCM) 등의 기능을 포함할 수 있다. 실행시 툴의 다른 예는 컴포넌트 업데이트를 얻기 위해 원격 서버와 대화하고 설치 시에 설치된 컴포넌트를 업데이트하는 서비스 클라이언트일 수 있다. 제작시 툴은 제작 랩(build lab)에서 사용된다. 제작시 툴은 주로 구성으로부터 런타임 이미지를 작성하는데 사용된다.

도 15에 도시한 바와 같이, CMI는 코어 계층 및 유틸리티 계층을 갖는다. CMI 코어 계층은 일반적으로 공지의 인터페이스로서 노출되고 소비되는 여러가지 기능 블록으로 이루어져 있다. 이 계층은 코어 CMI 객체 모델, 저장소 및 파일 저장소, 그리고 직렬화기/역직렬화기로 이루어져 있다. 코어 CMI 객체 모델 블록은 프로그래밍을 용이하게 하기 위한 CMI 클라이언트로의 인터페이스로서 다수의 서로 다른 제1 클래스 추상화를 노출한다. 이들은 일반적으로 비교적 사용하기 쉬운 포맷으로 컴포넌트화 추상화를 반영한다. 예를 들어, IAssembly는 컴포넌트 개념을 추상화한다. 이 실시예에서의 추상화는 그와 관련된 어떤 기능도 갖지 않는다. 이 추상화는 추상화에 대해 노출되는 메소드를 통해 검색되고 설정될 수 있는 속성의 집합이다. 이하의 리스트, 즉 IAssembly, IFeature, ICategory, IPackage, IProduct, ISku, IConfiguration, IRepository는 코어 CMI 객체 모델에서의 인터페이스를 통해 노출되는 추상화 중 몇가지를 포함한다.

도 15의 예에서의 컴포넌트 저장소는 저장소들 중 하나에 존재하는 컴포넌트를 관리하는데 사용된다. 전술한 바와 같이, 각각의 컴포넌트는 메타데이터(즉, 데이터에 관한 정보) 및 실제 데이터(즉, 컴포넌트의 파일)를 갖는다. 메타데이터 는 메타데이터 저장소 인터페이스(IRepository)를 통해 액세스가능한 반면, 데이터는 파일 저장소 인터페이스(IFileRepository)를 통해 액세스가능하다. 일 실시예에서, 메타데이터 저장소 인터페이스는 컴포넌트의 메타데이터를 저장 및 인덱싱하기 위해 관계형 데이터베이스를 사용하여 구현된다. 파일 저장소 인터페이스는 클라이언트가 컴포넌트 데이터(파일)에 일관된 방식으로 도달할 수 있게 해준다.

컴포넌트 메타데이터 및 데이터 인터페이스는 서로 다른 시나리오에 기초하여 서로 다른 플러그가능한 메타데이터 저장소 구현을 가능하게 하도록 도 15의 컴포넌트 저장소 인터페이스 하에서 분할된다. 예를 들어, 설계 머신 상에서 SQL 메타데이터 저장소를 사용할 수 있는데 그 이유는 이용가능한 스토리지 및 메모리가 제약을 받지 않을 수 있지만 런타임 시스템 상에서는 엄격한 메모리 요구사항을 지키기 위해 메타데이터 저장소가 적은 풋프린트 데이터베이스(예를 들어, 레지스트리)에 의해 배킹될 수 있기 때문이다.

직렬화기 및 역직렬화기 인터페이스는 CMI 내의 제1 클래스 객체가 텍스트 파일로 직렬화 및 그로부터 역직렬화될 수 있게 해준다. 예를 들어, XML 직렬화기 및 역직렬화기는 XML 파일을 판독 및 기록한다. 직렬화기 및 역직렬화기는 일반적으로 이하에 기술하는 바와 같이 캐리어 및 구성을 판독 및 기록한다.

직렬화된 포맷으로 임의의 제1 클래스 추상화를 전달하는 파일은 캐리어 또는 매니페스트라고 한다. 캐리어는 컴포넌트 저장소 데이터를 배치하는 수단을 제공한다, 즉 툴은 캐리어 파일 내의 컴포넌트의 직렬화된 인스턴스를 작성 또는 편집하고, 컴포넌트 저장소 인터페이스는 컴포넌트 저장소로 캐리어의 임포트 (import)를 가능하게 해준다.

정보 교환을 위해 캐리어를 사용하는 것의 주된 이점은 그렇게 하면 툴이 컴포넌트 저장소로부터 분리될 수 있다는 것이다. 다른 이점은 캐리어 정보를 임포트하는 동안, 데이터가 보다 일관된(또는 완전한) 포맷으로 컴포넌트 저장소로 임포트될 수 있다는 것이다. 직렬화기 및 역직렬화기 인터페이스 분리는 또한 다른 종류의 캐리어(예를 들어, INF)가 구현될 수 있게 해준다.

구성은 CMI의 IConfiguration 객체의 직렬화된 표현으로서, 이는 런타임 이미지를 작성하는데 사용되는 컴포넌트 및 세팅의 집합을 나타낸다. 구성이 캐리어 파일이 아닌 별개의 파일에 직렬화되어 있는 이유는 구성이 데이터베이스로 임포트될 수 없기 때문이다.

CMI 유틸리티 계층은 빈번하게 변하는 기능 블록들로 이루어져 있다. 이 기능 블록들은 도 15의 실시예에서 공지의 인터페이스로서 노출되고 소비된다. 유틸리티 계층은 인스톨러(installer), 업그레이더(upgrader), 의존관계 분석기, CMI 객체 모델, 및 클라이언트에 대한 블록들을 포함한다. 인스톨러 블록은 코어 계층에 의해 노출된 특정의 컴포넌트화 추상화를 설치(또는 구축) 및 제거하기 위한 로직을 갖는다. 예를 들어, IAssembly는 온라인 또는 오프라인 방식으로 OS 설치로부터 설치되고 제거된다. 어셈블리를 설치 및 제거하는 로직은 이 블록에 존재한다. 모든 코어 추상화는 "설치가능" 인터페이스를 사용하여 설치 및 제거된다. 이들 메소드의 구현은 각각의 코어 추상화에 대해 변한다. 예를 들어, 어셈블리의 경우, "IAssemblyInstaller"라고 하는 인스톨러 추상화가 있게 된다. IAssemblyInstaller는 "IAssembly" 인터페이스를 통합하고 어셈블리 인스턴스를 설치 및 제거하기 위한 "IInstallable"을 구현한다.

코어 추상화에서의 이러한 유형의 특정의 기능 바인딩은 코어 IAssembly 인터페이스에 영향을 주지 않고 어셈블리 인스톨 로직의 구현이 필요에 따라 변동될 수 있게 해준다. 다른 코어 추상화에 대해서는 역시 마찬가지이다.

업그레이더 블록은 윈도즈 설치에 대한 특정의 코어 추상화를 업그레이드 및 다운그레이드하기 위한 로직을 갖는다. 예를 들어, IAssembly는 온라인 또는 오프라인 방식으로 OS 설치로부터 업그레이드 또는 다운그레이드된다. 어셈블리를 업그레이드 및 다운그레이드하는 로직이 이 블록에 존재한다. 모든 코어 추상화는 "IUpgradable" 인터페이스를 사용하여 업그레이드 및 다운그레이드된다.

각각의 코어 추상화에 대한 이들 메소드의 별도의 구현이 있다. 업그레이드 프로세스에서 설치 및 제거 기능이 필요하기 때문에, "IUpgradable"은 기존의 설치 및 제거 기능을 재사용하기 위해 "IInstallable"로부터 상속한다. 예를 들어, 어셈블리는 "IAssemblyUpgrader"라고 하는 업그레이더 추상화를 갖는다. IAssemblyUpgrader는 "IAssembly", "IAssemblyInstaller"를 통합하고 윈도즈 설치에 대한 어셈블리 인스턴스를 업그레이드 및 다운그레이드하기 위해 "IUpgradable"을 구현한다. 다시 말하면, 이러한 종류의 바인딩은 코어 IAssembly 인터페이스 및 설치 또는 제거 로직에 영향을 주지 않고 어셈블리 업그레이드 로직의 구현이 필요에 따라 변할 수 있게 해준다. 다른 코어 추상화의 업그레이드 기능에 대해서도 역시 마찬가지이다.

의존관계 분석기 블록은 특정의 코어 추상화에 대한 의존관계 분석 로직을 구현한다. 이 예에서, 각각의 코어 추상화의 경우, 이 블록은 자동화된 방식 또는 수동 방식으로 의존관계 분석에 관한 로직을 갖는다. 의존관계 분석기는 클라이언트 프로그램이 특정의 클라이언트 콘텍스트에서 필요에 따라 디폴트 의존관계 분석 기능을 확장하도록 확장가능하다. 이 블록의 기능은 "IDependencyResolver" 인터페이스를 통해 노출된다. 의존관계를 분석하는 메소드는 그것이 사용되는 시나리오에 기초하여 CMI 객체 또는 인스턴스 객체의 트리를 반환한다. 의존관계 분석은 본 발명의 적어도 하나의 실시예에 따라 일반적으로 구성 또는 저장소에 관해 행해진다. 저장소는 설치가능한 것이거나 설치된 저장소일 수 있다.

일반적으로, 런타임 시스템 상에서, 의존관계 분석은 설치된 저장소 및 기존의 구성에 대해 행해지는 반면, 설계시 시나리오에서, 의존관계 분석은 설치가능 저장소 및 편집되고 있는 현재의 구성에 대해 행해진다.

CMI 객체 모델은 CMI 코어 객체 모델 및 유틸리티 계층에서 노출되는 여러가지 기능의 통합 형태이다. 코어 CMI 객체 모델은 또한 캐리어(또는 매니페스트)를 직렬화 및 역직렬화하는 동안 저작 툴이 추상화를 직접 처리하도록 노출된다.

상기 아키텍처에서 주목할 중요한 것들 중 하나가 동일한 프로그래밍 모델이 설계시, 실행시 및 제작시 시나리오 동안 노출되는 이점이 있다는 것이다. 이것은 객체 모델이 서로 다른 요구사항에 관해 일관성을 유지하게 해주는 데 도움을 주며 도 프로그래머의 생산성에도 도움을 준다. 이것은 또한 설계 및 실행시 등의 서로 다른 시나리오에 대해 사용될 CMI의 단일 구현을 재사용하는데 도움을 주며, 따라 서 설계시 및 실행시 시나리오에 대한 서로 다른 구현과 비교하여 유지성이 더 높다.

도 16은 컴퓨터(70) 형태의 범용 컴퓨팅 장치의 일례를 나타낸 것이다. 본 발명의 일 실시예에서, 컴퓨터(70) 등의 컴퓨터는 컴퓨터(150)으로서 사용하기에 적합하다.

예시된 실시예에서, 컴퓨터(70)는 하나 이상의 프로세서 또는 프로세싱 유닛(72) 및 시스템 메모리(74)를 갖는다. 예시된 실시예에서, 시스템 버스(76)는 시스템 메모리(74)를 포함한 여러가지 시스템 컴포넌트를 프로세서(72)에 연결시킨다. 버스(76)는 메모리 버스 또는 메모리 콘트롤러, 주변 버스, AGP(가속 그래픽 포트) 및 프로세서나 임의의 각종의 버스 아키텍처를 사용하는 로컬 버스를 비롯한 임의의 여러가지 유형의 버스 구조 중 하나 이상을 나타낸다. 제한이 아닌 예로서, 이러한 아키텍처는 ISA(산업 표준 아키텍처) 버스, MCA(마이크로 채널 아키텍처) 버스, EISA(확장 ISA) 버스, VESA(비디오 일렉트로닉스 표준 어소시에이션) 로컬 버스, 및 메자닌 버스라고도 알려진 PCI(주변 컴포넌트 상호연결) 버스를 포함한다.

컴퓨터(70)는 일반적으로 적어도 어떤 유형의 컴퓨터 판독가능 매체를 갖는다. 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체 둘다를 포함하는 컴퓨터 판독가능 매체는 컴퓨터(70)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 제한이 아닌 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함한다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프 로그램 모듈 또는 기타 데이터 등의 정보의 저장을 위한 임의의 방법 또는 기술에서 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 포함한다. 예를 들어, 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD 또는 기타 광학 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는데 사용되고 컴퓨터(70)에 의해 액세스될 수 있는 임의의 다른 매체를 포함한다. 통신 매체는 일반적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 반송파 또는 기타 전송 매카니즘 등의 변조된 데이터 신호로 구현하며 임의의 정보 전달 매체를 포함한다. 당업자라면 변조된 데이터 신호를 잘 알고 있으며, 이 신호는 정보를 그 신호에 인코딩하기 위해 하나 이상의 그의 특성이 설정 또는 변경된다. 유선 네트워크 또는 직접 유선 연결 등의 유선 매체, 및 음향, RF, 적외선, 및 기타 무선 매체 등의 무선 매체는 통신 매체의 예이다. 상기한 것들 중 임의의 것의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함된다.

시스템 메모리(74)는 분리형 및/또는 비분리형, 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 예시된 실시예에서, 시스템 메모리(74)는 ROM(78) 및 RAM(80)을 포함한다. 시동 중과 같은 때에 컴퓨터(70) 내의 구성요소들 사이의 정보 전송을 돕는 기본적인 루틴을 포함하는 기본 입출력 시스템(82)(BIOS)은 일반적으로 ROM(78)에 저장되어 있다. RAM(80)은 일반적으로 프로세싱 유닛(72)이 즉시 액세스가능하고 및/또는 프로세싱 유닛(72)에 의해 현재 처리되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 제한이 아닌 예로서, 도 16 은 오퍼레이팅 시스템(84), 애플리케이션 프로그램(86), 기타 프로그램 모듈(88), 및 프로그램 데이터(90)를 나타내고 있다.

컴퓨터(70)는 또한 기타 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예를 들어, 도 16은 비분리형, 비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(94)를 나타내고 있다. 도 16은 또한 분리형, 비휘발성 자기 디스크(98)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(96), 및 CD-ROM 또는 기타 광학 매체 등의 분리형, 비휘발성 광학 디스크(102)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(100)도 도시하고 있다. 예시적인 오퍼레이팅 환경에서 사용될 수 있는 기타의 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM, 등을 포함하지만, 이에 한정되는 것은 아니다. 하드 디스크 드라이브(84), 자기 디스크 드라이브(96), 및 광학 디스크 드라이브(100)는 일반적으로 인터페이스(106)와 같은 비휘발성 메모리 인터페이스에 의해 시스템 버스(76)에 연결되어 있다.

앞서 기술하였고 도 16에 도시되어 있는 드라이브 또는 기타의 대용량 저장 장치 및 그와 관련된 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 및 컴퓨터(70)의 기타 데이터에 대한 저장을 제공한다. 예를 들어, 도 16에서, 하드 디스크 드라이브(94)는 오퍼레이팅 시스템(110), 애플리케이션 프로그램(112), 기타 프로그램 모듈(114), 및 프로그램 데이터(116)를 저장하는 것으로 도시되어 있다. 유의할 점은 이들 컴포넌트가 오퍼레이팅 시스템(84), 애플리케이션 프로그램(86), 기타 프로그램 모듈(88), 및 프로그램 데이터(90)와 동일한 것이거나 또는 그와 다른 것일 수 있다는 것이다. 오퍼레이팅 시스템(110), 애플리케이션 프로그램(112), 기타 프로그램 모듈(114), 및 프로그램 데이터(116)는 최소한 이들이 서로 다른 복사본임을 나타내기 위해 본 명세서에서는 다른 번호가 부여되어 있다.

사용자는 키보드(120) 및 포인팅 장치(122)(예를 들어, 마우스, 트랙볼, 펜, 또는 터치 패드) 등의 입력 장치 또는 사용자 인터페이스 선택 장치를 통해 컴퓨터(70)에 명령 및 정보를 입력할 수 있다. 기타의 입력 장치(도시 생략)로는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등이 있을 수 있다. 이들 및 기타의 입력 장치는 시스템 버스(76)에 연결된 사용자 입력 인터페이스(124)를 통해 프로세싱 유닛(72)에 연결되어 있지만 병렬 포트, 게임 포트, 또는 USB(유니버설 직렬 버스) 등의 기타의 인터페이스 및 버스 구조에 의해 연결될 수 있다. 모니터(128) 또는 기타의 유형의 디스플레이 장치도 또한 비디오 인터페이스(130) 등의 인터페이스를 통해 시스템 버스(76)에 연결되어 있다. 모니터(128) 이외에, 컴퓨터는 종종 출력 주변 인터페이스(도시 생략)를 통해 연결될 수 있는 프린터 및 스피커 등의 기타의 주변 출력 장치(도시 생략)를 포함한다.

컴퓨터(70)는 원격 컴퓨터(134) 등의 하나 이상의 원격 컴퓨터로의 논리적 연결을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(134)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타의 통상의 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(70)에 대해 전술한 구성요소들의 대부분 또는 그 모두를 포함한다. 도 16에 도시된 논리적 연결은 LAN(근거리 통신망)(136) 및 WAN(원거리 통신망)(138)을 포함하지만, 기타의 네트워크도 포함할 수 있다. LAN(136) 및/또는 WAN(138)은 유선 네트워크, 무선 네트워크, 이들의 조합 등등일 수 있다. 이러한 네트워킹 환경은 사무실, 기업 규모 컴퓨터 네트워크, 인트라넷, 및 글로벌 컴퓨터 네트워크(예를 들어, 인터넷)에서 통상적인 것이다.

근거리 네트워킹 환경에서 사용되는 경우, 컴퓨터(70)는 네트워크 인터페이스 또는 어댑터(140)를 통해 LAN(136)에 연결되어 있다. 광대역 네트워킹 환경에서 사용되는 경우, 컴퓨터(70)는 일반적으로 모뎀(142) 또는 인터넷 등의 WAN(138)을 거쳐 통신을 설정하기 위한 기타의 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(142)은 사용자 입력 인터페이스(134) 또는 기타의 적절한 메카니즘을 통해 시스템 버스(76)에 연결된다. 네트워크화된 환경에서, 컴퓨터(70)에 관해 도시된 프로그램 모듈 또는 그의 일부분은 원격 메모리 저장 장치(도시 생략)에 저장될 수 있다. 제한이 아닌 예로서, 도 16은 원격 애플리케이션 프로그램(144)이 메모리 장치 상에 존재하는 것으로 나타내고 있다. 도시된 네트워크 연결은 예시적인 것이며 컴퓨터들 사이에 통신 링크를 설정하는 기타의 수단이 사용될 수 있음을 잘 알 것이다.

일반적으로, 컴퓨터(70)의 데이터 프로세서는 컴퓨터의 여러가지 컴퓨터 판독가능 저장 매체에 서로 다른 때에 저장된 명령어에 의해 프로그램되어 있다. 프로그램 및 오퍼레이팅 시스템은 일반적으로 예를 들어 플로피 디스크 또는 CD-ROM 상으로 배포된다. 이들은 그곳으로부터 컴퓨터의 2차 메모리로 설치 또는 로드된다. 실행 시에, 이들은 적어도 부분적으로 컴퓨터의 1차 전자적 메모리로 로드된다. 본 명세서에 기술된 본 발명은 이들 및 기타의 여러가지 유형의 컴퓨터 판독가능 저장 매체가 마이크로프로세서 또는 기타의 데이터 프로세서와 연계하여 본 명세서에 기술된 단계들을 구현하기 위한 명령어 또는 프로그램을 포함하는 경우 이러한 매체를 포함한다. 본 발명은 또한 컴퓨터가 본 명세서에 기술된 방법 및 기술에 따라 프로그램될 때 그 컴퓨터 자체를 포함한다.

설명의 목적상, 오퍼레이팅 시스템 등과 같은 프로그램 및 기타의 실행가능 프로그램 컴포넌트가 본 명세서에서 개별적인 블록으로서 나타내어져 있다. 그렇지만, 이러한 프로그램 및 컴포넌트가 다양한 시기에 컴퓨터의 서로 다른 저장 컴포넌트에 존재하고 컴퓨터의 데이터 프로세서(들)에 의해 실행됨을 잘 알 것이다.

컴퓨터(70)를 포함하는 예시적인 컴퓨팅 시스템 환경과 연계하여 기술되어 있지만, 본 발명은 여러가지 다른 범용 또는 특수 목적 컴퓨팅 시스템 환경 또는 구성에서 동작한다. 컴퓨팅 시스템 환경은 본 발명의 사용 또는 기능의 범위에 관한 어떤 제한을 암시하려는 것이 아니다. 게다가, 컴퓨팅 시스템 환경은 예시적인 오퍼레이팅 환경에 예시된 컴포넌트들 중 임의의 하나 또는 그의 조합에 관하여 어떤 의존관계 또는 요구사항을 갖는 것으로 해석되어서는 안된다. 본 발명과 함께 사용하기에 적합할 수 있는 공지의 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩톱 장치, 멀티프로세서 시스템, 마이크로프로세스 기반 시스템, 셋톱 박스, 이동 전화를 포함한 프로그램가능 가전제 품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기한 시스템 또는 장치 중 임의의 것을 포함하는 분산 컴퓨팅 환경, 기타 등등이 있지만, 이에 한정되는 것은 아니다.

본 발명의 실시예들은 하나 이상의 컴퓨터 또는 기타의 장치에 의해 실행되는 프로그램 모듈 등의 컴퓨터 실행가능 명령어의 일반적 관점에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정의 태스크를 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 및 데이터 구조를 포함하지만, 이에 한정되는 것은 아니다. 본 발명은 또한 태스크들이 통신 네트워크를 통해 연결되어 있는 원격 프로세싱 장치들에 의해 수행되는 것인 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함한 로컬 컴퓨터 저장 매체 및 원격 컴퓨터 저장 매체 둘다에 위치될 수 있다.

동작시, 컴퓨터(70)는 파일들을 가지고 객체를 구성하기 위해 본 명세서에 기술된 것과 같은 컴퓨터 실행가능 명령어를 실행한다. 이 예에서, 객체들 중 적어도 일부는 컴포넌트를 나타내며, 그 컴포넌트 각각은 적어도 하나의 파일을 포함한다. 컴퓨터 실행가능 명령어에 따라, 매니페스트는 각각의 컴포넌트를 식별하고 그 컴포넌트와 기타의 객체들 사이의 의존관계를 지정한다. 매니페스트에 지정된 의존관계에 따라 객체들을 그룹화함으로써 소프트웨어 제품을 제작할 수 있다.

당업자라면 본 명세서에 도시되고 기술된 방법들의 실행 또는 수행 순서가 달리 언급하지 않는 한 필수적이 아님을 잘 알 것이다. 즉, 발명자들은 본 방법의 요소들이 달리 언급하지 않는 한 임의의 순서로 수행될 수 있으며 본 방법은 본 명 세서에 기술된 것보다 더 많거나 더 적은 요소를 포함할 수 있음도 생각하고 있다.

URL(uniform resource locator) 및 기타의 인터넷 웹 사이트 참조를 포함하여 본 문서에서의 정보는 예고없이 변경될 수 있다. 달리 언급하지 않는 한, 본 명세서에 나타낸 예시적인 회사, 조직체, 제품, 도메인 이름, 이메일 주소, 로고, 사람, 장소 및 이벤트는 가상의 것이며, 임의의 실제 회사, 조직체, 제품, 도메인 이름, 이메일 주소, 로고, 사람, 장소 또는 이벤트와의 어떠한 관련도 의도한 것이 아니며 추론되어서도 안된다.

본 발명의 구성요소 또는 그의 실시예를 소개할 때, 단수로 표현된 구성요소는 하나 이상의 구성 요소가 있음을 의미하고자 한 것이다. "포함하는", "구비하는" 및 "갖는"이라는 표현은 포함적 관계를 나타내어 열거된 구성요소 이외의 추가의 구성요소가 있을 수 있음을 의미하기 위한 것이다.

이상의 것을 살펴보면, 본 발명의 몇가지 목적이 달성되고 기타의 유익한 결과가 획득됨을 알 수 있다.

예를 들어, 본 발명의 실시예들은 확장가능하고 확대가능하다. 컴포넌트 저장소는 런타임 시스템 상에서 비교적 적은 수(예를 들어, 수백개)의 컴포넌트를 추적할 수 있는 것에 대해 설계시 시스템 상에서 비교적 많은 수(예를 들어, 수십만개)의 컴포넌트를 추적할 수 있다. 본 발명에 의해 구현되는 스키마는 또한 부가의 메타데이터 및 새로운 컴포넌트가 서로 다른 제품 부서 및 써드 파티에 의해 부가될 수 있도록 충분히 확장가능하다. 프로그래밍 모델은 사람이 그를 확장시키기 위해 일관된 방식으로 코어 컴포넌트화 프레임워크에 기능을 부가할 수 있도록 충분히 확장가능하다.

본 발명의 범위를 벗어나지 않고 상기 구조 및 방법에 여러가지 변경이 행해질 수 있기 때문에, 상기 설명에 포함되고 첨부 도면에 도시된 모든 것들은 제한적 의미가 아닌 예시적인 것으로 해석되어야 할 것이다.

<부록 A>

데이터 저장 및 포맷 저작 툴은 컴포넌트, 특징, 카테고리, 패키지, 제품 및 SKU를 제작한다. 이 예에서, 이들은 XML 파일(캐리어 또는 매티페스트라고 함)로 표현되어 있다. 각각의 캐리어는 특징, 카테고리, 패키지, 제품 또는 SKU의 단지 하나의 인스턴스를 포함한다. 메모장 매니페스트의 일례는 다음과 같다.

Claims

복수의 파일로부터 복수의 특징(features)을 포함하는 소프트웨어 제품을 제작하는(build), 컴퓨터로 수행되는 방법으로서,

상기 복수의 파일을 객체들로 구성하는 단계;

상기 제작될 소프트웨어 제품의 상기 복수의 특징들 중 하나의 특징을 정의하는 단계 - 상기 정의된 특징은 적어도 하나의 컴포넌트를 포함하고, 상기 컴포넌트는 상기 객체들 중 적어도 하나에 의해 표현되고, 상기 제작될 소프트웨어 제품의 상기 복수의 특징들 중 제2 특징은 상기 정의된 특징의 상기 적어도 하나의 컴포넌트를 포함하며, 상기 정의된 특징은 상기 제2 특징에 의존하는 컴포넌트가 아니고, 상기 제2 특징은 상기 정의된 특징에 의존하는 컴포넌트가 아님 - ;

상기 복수의 특징의 각각의 컴포넌트를 그와 고유하게 관련된 상응하는 개별 매니페스트(manifest)를 사용하여 식별하는 단계 - 상기 매니페스트는 상기 관련된 컴포넌트와 상기 객체들 중 적어도 하나 사이의 하나 이상의 의존관계(dependencies)를 각각 지정하고(specify), 상기 객체들 중 상기 적어도 하나는 상기 소프트웨어 제품 내의 상기 파일들의 카테고리를 대표함 - ;

하나 이상의 다른 객체에 의해 상기 카테고리에 멤버쉽을 선언하는 단계 - 상기 카테고리에 상기 멤버쉽을 선언하는 상기 하나 이상의 다른 객체들 각각은 컴포넌트, 특징, 및 패키지 중 적어도 하나를 대표함 - ;

상기 제작될 소프트웨어 제품의 상기 복수의 특징의 상기 컴포넌트들과 관련된 상기 매니페스트에 의해 지정된 상기 의존관계에 따라 상기 객체들을 그룹핑함으로써, 상기 소프트웨어 제품을 제작하는 단계

를 포함하는 방법.
제1항에 있어서,

상기 객체들 중 적어도 하나는 상기 소프트웨어 제품의 상기 정의된 특징을 대표하는 것이고,

상기 방법은 상기 선택된 객체들의 상기 파일들에 의해 구현되는 상기 소프트웨어 제품의 상기 특징을 정의하기 위하여 선택된 객체들을 그룹핑하는 단계를 더 포함하는 방법.
제2항에 있어서,

상기 특징을 정의하기 위하여 그룹핑된 상기 선택된 객체들은, 상기 매니페스트 내에 지정된 상기 의존관계에 따라 그룹핑된 상기 컴포넌트들 중 하나 이상을 포함하거나, 다른 특징을 대표하는 적어도 하나의 객체를 포함하는, 방법.
제1항에 있어서,

상기 컴포넌트는 다른 컴포넌트, 카테고리, 및 특징 중 하나 이상을 대표하는 객체들에 의존하는 것인, 방법.
제1항에 있어서,

서로 다른 소프트웨어 제품들을, 선택된 컴포넌트들의 서로 다른 집합의 함수로 기술하기 위하여, 상기 컴포넌트들에 관련된 메타 데이터를 생성하는 단계를 더 포함하는 방법.
제1항의 방법을 수행하기 위한 컴퓨터 실행가능 명령어를 포함하는 하나 이상의 컴퓨터 판독가능 저장 매체.
복수의 파일로부터 복수의 특징을 포함하는 소프트웨어 제품을 제작하는데(build) 사용하기 위한, 객체들이 저장된 하나 이상의 컴퓨터 판독가능 저장 매체로서,

복수의 컴포넌트 객체 - 상기 컴포넌트 객체들 각각은 상기 파일들 중 하나 이상 및 그와 고유하게 관련된 상응하는 개별 매니페스트를 포함하고, 상기 매니페스트는, 상기 관련된 컴포넌트 객체를 식별하고 상기 관련된 컴포넌트 객체와 하나 이상의 기타 객체들 사이의 의존관계를 지정하는 메타 데이터를 포함함 - ;

상기 제작될 소프트웨어 제품의 상기 복수의 특징들 중 제1 특징에 상응하는 제1 특징 객체를 포함하는 복수의 특징 객체 - 상기 제1 특징 객체는 상기 매니페스트 내에 지정된 상기 의존관계에 따라 그룹핑된 하나 이상의 선택된 객체를 포함하고, 상기 선택된 객체들 중 적어도 하나는 상기 제작될 소프트웨어 제품의 상기 복수의 특징들 중 제2 특징에 상응하는 제2 특징 객체에 포함되며, 상기 제1 특징 객체는 상기 제2 특징 객체에 의존하는 컴포넌트 객체가 아니고, 상기 제2 특징 객체는 상기 제1 특징 객체에 의존하는 컴포넌트 객체가 아님 - ; 및

상기 소프트웨어 제품을 제작하기 위하여, 관련된 객체들인 상기 하나 이상의 선택된 객체들을 그룹핑하기 위한 카테고리 객체 - 상기 카테고리 객체 내의 객체는 상기 카테고리 객체에 멤버쉽을 선언하고, 컴포넌트 객체, 특징 객체, 및 패키지 객체 중 하나 이상을 포함함 -

를 포함하는 하나 이상의 컴퓨터 판독가능 저장 매체.
제7항에 있어서,

상기 제1 특징 객체 내의 상기 선택된 객체는 상기 객체들 사이의 의존관계에 따라 그룹핑되고, 컴포넌트 객체 및 특징 객체 중 하나 이상을 포함하는, 하나 이상의 컴퓨터 판독가능 저장 매체.
제7항에 있어서,

상기 컴포넌트는 객체는 다른 컴포넌트 객체, 카테고리 객체, 및 특징 객체 중 하나 이상에 의존하는, 하나 이상의 컴퓨터 판독가능 저장 매체.
제7항에 있어서,

상기 객체들 각각은 식별 정보를 포함하는, 하나 이상의 컴퓨터 판독가능 저장 매체.
컴포넌트화 스키마(componentization schema)의 함수로서 저장된 파일을 포함하는 컴퓨터 판독가능 저장 매체로서, 상기 컴포넌트화 스키마는,

하나 이상의 파일을 포함하는 컴포넌트 객체 - 상기 하나 이상의 파일로부터 소프트웨어 제품이 제작되고, 상기 컴포넌트 객체는 그와 고유하게 관련된 상응하는 매니페스트를 포함하며, 상기 매니페스트는 상기 컴포넌트 객체를 식별하고 상기 컴포넌트 객체 및 적어도 하나의 다른 객체 사이의 하나 이상의 의존관계를 지정함 -;

상기 제작될 소프트웨어 제품의 특징을 표현하기 위한 특징 객체 - 상기 특징 객체는 적어도 하나의 컴포넌트 객체를 포함하고, 상기 특징 객체 내에 포함된 상기 적어도 하나의 컴포넌트 객체는 상기 제작될 소프트웨어 제품의 제2 특징을 표현하는 제2 특징 객체 내에 포함되고, 상기 특징 객체는 상기 제2 특징 객체에 의존하는 컴포넌트 객체가 아니고, 상기 제2 특징 객체는 상기 특징 객체에 의존하는 컴포넌트 객체가 아니며, 상기 특징 객체 및 제2 특징 객체의 각각의 컴포넌트 객체는 그들과 고유하게 관련된 상응하는 개별 매니페스트로 식별되고, 상기 매니페스트는 상기 관련된 컴포넌트 및 상기 객체들 중 적어도 하나 사이의 하나 이상의 의존관계를 각각 지정함 - ;

상기 소프트웨어 제품을 표현하기 위한 제품 객체 - 상기 제품 객체는 적어도 상기 특징 객체에 의해 정의됨 -; 및

상기 소프트웨어 제품을 제작하기 위하여, 상기 매니페스트 내에 지정된 상기 의존관계에 따라 그룹핑된 컴포넌트 객체들의 공통 집합을 표현하기 위한 카테고리 객체 - 상기 카테고리는 상기 공통 집합 내의 하나 이상의 컴포넌트 객체가 공개 그룹(open group) 내에서 멤버쉽을 선언하도록 허가하는 공개 그룹이고, 상기 카테고리 객체는 컴포넌트 객체, 특징 객체, 및 패키지 객체 중 하나 이상을 대표하는 멤버를 포함함 -

를 포함하는 컴퓨터 판독가능 저장 매체.
제11항에 있어서,

상기 특징 객체는 관련된 상기 매니페스트 내에 지정된 상기 의존관계에 따라 그룹핑된 선택된 컴포넌트 객체를 포함하는, 컴퓨터 판독가능 저장 매체.
제11항에 있어서,

컴포넌트 객체, 카테고리 객체, 특징 객체, 및 패키지 객체 중 적어도 하나를 대표하는 하나 이상의 멤버를 포함하는 폐쇄 그룹(closed group)을 표현하는 패키지 객체를 더 포함하는 컴퓨터 판독가능 저장 매체.
제11항에 있어서,

상기 컴포넌트 객체는 다른 컴포넌트 객체, 카테고리 객체, 및 특징 객체 중 하나 이상과 의존적인 관계를 가지는, 컴퓨터 판독가능 저장 매체.
제11항에 있어서,

상기 특징 객체는 적어도 하나의 다른 특징 객체에 의해 정의되는, 컴퓨터 판독가능 저장 매체.
삭제
삭제
삭제
삭제
삭제