유연한 컴포넌트 결합을 지원하는 컴포넌트 모델

A Component Model for Flexible Component Composition

류기열,       이정태,       김윤명

Ki-Yeol Ryu,  Jung-Tae Lee, Yoon-Myoung Kim

아주대학교 정보및컴퓨터공학부

School of Information and Computer Engineering

Ajou University

요 약

최근 들어, 소프트웨어의 재사용을 통한 효과적인 소프트웨어의 개발을 위한 컴포넌트 개념에 대한 연구가 활발하게 진행되고 있으며  상용 시스템에서까지 이러한 개념을 부분적으로 구현하고 있으나,  아직 컴포넌트 모델에 대한 개념이 이론적으로 명확하게 정립되지 않은 실정이다.

본 논문에서는 기존의 여러 연구에서 정의되고 있는 컴포넌트 개념을 분석하고 컴포넌트 모델이 갖추어야 할 요구조건에 따라 하나의 새로운 컴포넌트 모델을 정의한다. 제안된 모델에서는 컴포넌트들이 부합성의 규칙에 따라 유연하게 결합될 수 있다. 본 논문에서는 컴포넌트의 기본 요소,  컴포넌트들간의 결합에 관한 규칙, 그리고 이미 조립된 복합 컴포넌트의 부품 컴포넌트의 교체 규칙 등 컴포넌트 모델에 대한 몇 가지 성질들을 정의한다.

1. 서론

Brad Cox는 객체지향 프로그래밍의 목표는 마치 표준화된 IC 칩을 조립하여 컴퓨터 하드웨어를 만드는 것과 같이 미리 제작된 소프트웨어 부품을  조립함으로써 응용프로그램을 개발하는 것이라고 말했다[2]. 그러나 현재 소프트웨어 개발 환경은 기존의 객체지향 기술만으로 이 목표를 달성하는 데는 한계가 있음을 보여주고 있다[4,5]. 최근 들어 이러한 객체지향 개념의 한계를 극복하고 보완하여,  기존 소프트웨어 부품의 재사용을 통하여 보다 효과적으로 응용 소프트웨어를 개발하기 위한 기술로 컴포넌트 기술(component technology)에 대한 연구가 활발하다[3,4,8].

컴포넌트라는 개념은 이 용어를 사용하는 연구나 제품 등에 따라 다소 다른 의미로 사용되고 있으나, 컴포넌트는 독립적으로 개발되어(심지어는 서로 다른 회사에 의해서) 응용 소프트웨어의 개발이나 더 큰 컴포넌트를 개발하기 위한 부품으로 사용될 수 있는 소프트웨어의 단위라는 데는 대부분 동의한다.  기존의 컴포넌트들을 결합함으로써 응용 소프트웨어를 보다 효과적으로 개발하고 또 개발된 후에도 컴포넌트를 추가하거나 한 컴포넌트를 다른 부품 컴포넌트로 교체함으로써 쉽게 유지보수를 할 수 있는 기술이다. 이러한 컴포넌트 개념을 지원하기 위해서는 컴포넌트 모델에 기반한 언어나 컴포넌트 프레임웍을 필요로 한다. 현재 컴포넌트 모델을 지원하는 대표적인 시스템으로는 OMG의 CORBA[7], Microsoft의 COM[6], 그리고 Sunsoft의 JavaBeans[9]를 들 수 있다. 그러나 이러한 시스템들은 모두 처음부터 앞에서 언급한 컴포넌트의 목적에 부합하기 위해서 만들어진 시스템이 아니며 뒤에 기존의 시스템에 컴포넌트 기술을 접목하거나 객체지향 개념을 컴포넌트의 개념으로 재해석하여 확장한 경우가 대부분이다.

본 논문은 기존의 다양한  컴포넌트의 개념과 컴포넌트의 요구조건을 분석하여 이론적으로 보다 체계적인 컴포넌트 모델을 만드는 것을 목표로 한다. 이를 위해 우선 컴포넌트가 갖추어야 할 요소를 정의한다. 그리고 이러한 컴포넌트들이 어떻게 결합(composition)할 수 있는지 그 결합 방법을 제공하고 이러한 결합방법을 이용하여  부품 컴포넌트들을 결합하여 복합 컴포넌트(composite component)를 만드는 방법을 정의한다. 마지막으로 부품 컴포넌트들로 생성된 복합 컴포넌트나 응용프로그램으로부터 하나의 부품 컴포넌트를 새로운 부품 컴포넌트로 교체할 수 있는 규칙을 정의한다.

컴포넌트 모델이 효과적이기 위해서는 컴포넌트의 독립성을 보장해야 한다. 컴포넌트의 독립성은 독립적으로 개발되고, 독립적으로 다른 컴포넌트와 결합되고, 다른 컴포넌트와 무관하게 확장되거나 교체될 수 있어야 한다는 것이다. 독립성으로 인해 서로 다른 회사, 다른 사람에 의해 다른 시점에 개발된 컴포넌트들은 자칫 결합에 어려움을 가질 수 있다. 따라서 컴포넌트 모델은 컴포넌트들이 유연하게 결합하고 교체할 수 있는 능력을 제공해야 한다. 본 논문에서는  컴포넌트간의 부합성(conformity)을 정의하여 이 부합성의 조건에 따라 컴포넌트들의 유연한 결합과 교체를 가능하게 한다.

2. 컴포넌트 모델

이 장에서는 본 논문에서 제안하는 컴포넌트 모델에 대하여 기술한다. 이 컴포넌트 모델은 객체지향 개념에 바탕을 두고 설계된다. 그 이유는 객체지향 개념은 추상화(abstraction), 다형성(polymorphism)등의 중요한 개념을 지원하고 있고 이러한 개념은 컴포넌트 기술에서도 여전히 유효하다고 판단되기 때문이다. 실제로 대부분 현존하는 컴포넌트 프레임웍들이 객체지향 모델에 기반을 두고 있다.

또한 본 논문에서 제안하는 컴포넌트 모델은 특정 컴포넌트 운용 환경(component environment)을 가정하지 않고 있다. 컴포넌트 모델은 운용환경과는 서로 독립적이라고 판단하기 때문이다. 이 모델은 하나의 객체지향 프로그래밍 언어 위에서 구현될 수도 있고 CORBA와 같이 분산 이기종 환경에서 구현될 수도 있을 것이다.

2.1 컴포넌트의 정의

컴포넌트 기술은 근래에 등장한 새로운 기술로서, 이에 관련된 용어들은 아직 학자 또는 제품마다 일치되지 않는 부분이 많다. 그렇기 때문에 컴포넌트의 모델을 정의하기 전에 먼저 이 모델에서 사용하는 컴포넌트라는 용어에 대하여 다음과 같이 정의하기로 한다.  컴포넌트는 타 컴포넌트에 독립적으로 설계 및 구현된 추상화 및 캡슐화 단위로서, 다른 컴포넌트와 쉽게 결합되어 보다 큰 단위의 컴포넌트를 생성할 수 있으며, 응용프로그램에서 다른 컴포넌트에 영향을 주지 않고 하나의 컴포넌트를 쉽게 교체할 수 있고,  개별적인 단위로 매매 유통이 가능하며, 그 자체로서 재사용 가능한 소프트웨어 단위이다.

이러한 컴포넌트의 정의에 입각하여 본 논문에서는 컴포넌트를 상호작용하는 관련된 클래스들의 집합으로 정의한다. 이 개념은 모듈과 매우 유사하다. 그러나 컴포넌트의 독립적인 성질을 위해  컴포넌트는 명확한 인터페이스를 가지고 있어야 한다. 이 컴포넌트의 인터페이스에는 그 컴포넌트가 외부로 제공하는 서비스와 또 그 컴포넌트가 외부로부터 요구하는 서비스를 명시해야 한다. 본 논문에서는 이러한 컴포넌트의 인터페이스를 컨트랙트(contract)라고 부른다. 이러한 컨트랙트의 조건에 따라 컴포넌트들은 결합될 수 있다. 즉, 한 컴포넌트가 제공하는 인터페이스가 다른 컴포넌트가 요구하는 인터페이스를 부분적으로 또는 전체적으로 부합하면 두 컴포넌트는 결합될 수 있다.

2.2 컴포넌트의 종류

컴포넌트는 단위에 따라 기본 컴포넌트 (primitive component)와 복합 컴포넌트 (composite component)로 나뉜다. 기본 컴포넌트는 기본적인 객체들로만 이루어진 컴포넌트이다. 기본 컴포넌트에는 다른 컴포넌트가 포함되어 있지 않다. 복합 컴포넌트는 하나 이상의 컴포넌트들로 이루어진다.  복합 컴포넌트들을 이루는 작은 단위의 컴포넌트들을 부품 컴포넌트(part component)라고 부른다. 부품 컴포넌트로는 기본 컴포넌트가 이용될 수도 있고 또 다른 복합 컴포넌트가 포함될 수 도 있다. 그림 1은 부품 컴포넌트로부터 복합 컴포넌트를 얻는 개념적인 그림이다. 복합 컴포넌트도 외부에서 볼 때는 기본 컴포넌트와 차이가 없다. 즉, 같은 형식의 컨트랙트를 제공한다. 이 컨트랙트는 컴포넌트 결합(component composition)규칙에 따라 부품 컴포넌트들의 컨트랙트들로부터 얻을 수 있다. 부품 컴포넌트들에 대하여 그것들이 속한 복합 컴포넌트를 전체 컴포넌트(whole component)라고 부르기로 한다.

.

그림 1. 복합 컴포넌트 생성의 개념도

2.3 기본 컴포넌트의 구조

제안된 모델에서의 컴포넌트는 크게 두 가지 요소로 나누어진다. 하나는 컴포넌트의 컨트랙트로서 이는 다시 제공 인터페이스(providing interface)와 요구 인터페이스(requiring interface)로 나누어진다. 제공 인터페이스와 요구 인터페이스는 둘 모두 클래스 인터페이스의 계층구조(class interface hierarchy)로 이루어진다. 제공 인터페이스는 컴포넌트가 외부로 제공하는 서비스의 계층구조이며 요구 인터페이스는 그 컴포넌트가 사용하는 외부의 서비스를 위한 클래스 인터페이스 계층구조이다.  제공 인터페이스나 요구 인터페이스에 속하는 각 계층 구조의 각 클래스 인터페이스에는 그 클래스 인터페이스가 제공하는 메쏘드의 시그니처(signature)들이 기술된다. 제안된 모델에서는 이 인터페이스 구조에 따라 객체지향 개념에서의 다형성(polymorphism)을 제공한다.

) 클래스의 인터페이스부분을 구현 클래스와 구분하기 위해 클래스 인터페이스라는 용어를 사용한다.

그리고 컴포넌트의 다른 요소는 컴포넌트의 내부 구현이다.  그림 2는 기본 컴포넌트의 구조를 보여준다. 그림 2에서와 같이 내부 구현코드는 일반적으로 컨트랙트의 클래스 인터페이스 계층구조와 유사한 클래스 계층구조로 이루어지지만 반드시 이와 일치할 필요는 없다. 컨트랙트에서 제공되는 클래스 인터페이스에 대응되는 클래스만 존재하면 된다. 그러나 제공 인터페이스의 계층 구조에 따라 다형성을 제공할 수 있도록 클래스들이 구현되어야 한다. 즉, 계층구조의 서브타입에 해당하는 클래스 인터페이스를 구현하는 클래스는 수퍼타입 인터페이스를 구현하는 클래스를 상속을 받거나 아니면 수퍼타입 인터페이스의 모든 메쏘드를 서버타입 인터페이스의 메쏘드와 함께 구현해야 한다.

그림 2. 기본 컴포넌트의 구조

컨트랙트는 그림3의 예와 같이 기술될 수 있다. 키워드 component 뒤에 오는 <component-name> 부분에는 실제 컴포넌트의 이름을 기술한다. 이 이름은 구조를 타 컴포넌트가 이 컴포넌트를 식별하는데 사용하므로, 컴포넌트마다 유일한 이름이어야 한다. provides 키워드로 시작하는 블록은 제공 인터페이스를 기술하고 requires 키워드로 시작하는 블록은 요구 인터페이스를 기술한다.

제공 인터페이스 블록은 다시 class 키워드로 시작하는 작은 블록들로 나뉘어지는데, 이 블록들은 타 컴포넌트에 의해 하나의 클래스로 식별된다. 이 클래스 블록을 컴포넌트 구현 코드의 클래스 구현과 구별하기 위하여 클래스 인터페이스(class interface)라고 부르기로 한다. 클래스 인터페이스에는 해당 클래스가 제공하는 메쏘드(들)의 시그니처(들)을 기술한다. 이 시그니처의 구체적인 문법은 구현 코드를 생성하는데 사용한 프로그래밍 언어에 따라 달라질 수 있다. 이를 피하기 위해서는 CORBA IDL과 같이 특정 프로그래밍 언어에 무관한 인터페이스 언어를 사용하는 방법도 있을 수 있다. 그러나 본 모델 개발의 현 단계에서는 구현 코드 생성 방법에 대한 사항이 구체적으로 결정되지 않았으므로, 이에 대한 문법은 후에 정하기로 한다.  메쏘드 시그니처에 표현되어야 하는 내용은 메쏘드 식별자, 입력 파라미터(들)의 순서와 자료형, 그리고 출력 파라미터(들)의 순서와 자료형이다. 클래스 인터페이스들 간에는 계승의 계층 구조가 존재할 수 있으며 이를 위해서는 각 클래스 이름 뒤에 extends 키워드를 기술하고, 그 뒤에 수퍼클래스에 해당하는 클래스 인터페이스의 식별자를 기술한다. 클래스 인터페이스간의 계승 계층 구조를 표현하는 이유는 컴포넌트 경계를 넘어선 다형성을 지원하기 위한 것이다. 이 계층 구조는 제공 인터페이스 블록의 범위를 넘을 수 없다.

그림 3. 컨트랙트의 예

requires 블록의 기술 방법은 제공 인터페이스의 provides 블록의 기술 방법과 동일하다. 어떤 컴포넌트는 제공 서비스가 전혀 없는 경우도 있다. 이 때에는 provides 블록을 생략할 수 있다. 마찬가지로 어떤 컴포넌트는 요구 인터페이스를 전혀 필요로 하지 않을 수도 있으며, 이 때에는 requires 블록을 생략할 수 있다.

2.4 컴포넌트의 결합과 복합 컴포넌트

2.4.1 컴포넌트의 결합

이 절에서는 두개 이상의 컴포넌트들의 결합에 관한 방법과 그 성질들에 대하여 설명하기로 한다. 이러한 결합을 통하여 작은 단위의 부품 컴포넌트들을 이용하여 더 큰 단위의 복합 컴포넌트를 만들 수 도 있고 하나의 완성된 응용프로그램을 생성할 수도 있다. 일반적으로 두개의 컴포넌트를 결합하는 작업이 항상 복합 컴포넌트를 만드는 것은 아니지만 본 논문에서는 설명의 편의를 위해 복합 컴포넌트를 만드는 경우에 대하여 설명하기로 한다. 복합 컴포넌트를 만들지 않는 결합의 경우는 복합 컴포넌트의 컨트랙트를 고려하지 않기만 하면 된다.

컴포넌트에 관한 규칙들을 기술하기 위하여 다음과 같은 기호들을 사용하기로 한다.

A, B, C, ...	; 컴포넌트

□	; 컴포넌트의 컨트랙트

i, j, ...	; 객체 인터페이스

□, □, □, □, ...	; 객체 인터페이스들의 계층 구조

□, □,  ...	; 객체 인터페이스들의 계층 구조의 집합

컴포넌트들을 결합하는 방법으로는 다음과 같은 세 가지 방법이 있다.

□ 사용 관계(use relation)에 의한 결합

□ 상속 관계(inheritance relation)에 의한 결합

□ 병렬 관계(parallel relation)에 의한 결합

사용관계에 의한 결합은 하나의 컴포넌트의 요구인터페이스에서 요구하는 서비스의 일부분 또는 전체를 다른 컴포넌트의 제공 인터페이스에서 제공할 때 두 컴포넌트사이에 가능한 결합 방법이다. 즉, 하나의 컴포넌트는 다른 컴포넌트가 제공하는 서비스를 호출하여 이용하는(use) 경우이다. 하나의 컴포넌트는 두개이상의 컴포넌트가 제공하는 서비스를 이용할 수 도 있다. 그리고 두 컴포넌트들은 상호 사용하는 방식으로 결합이 될 수도 있다. 그림 4는 하나의 컴포넌트가 두개의 컴포넌트가 제공하는 서비스를 이용하는 방식으로 결합된 예이다.

그림 4. 사용관계에 의한 컴포넌트 결합

두 컴포넌트사이의 상속에 의한 결합은 하나의 컴포넌트의 제공 인터페이스에 속하는 한 클래스 인터페이스 계층이(즉, 그 계층구조의 루트 클래스가) 다른 컴포넌트의 제공 인터페이스에 속하는 한 클래스 인터페이스의 서브클래스가 되거나 또는 하나의 컴포넌트의 요구 인터페이스에 속하는 한 클래스 인터페이스 계층이(즉, 그 계층구조의 루트 클래스가) 다른 컴포넌트의 요구 인터페이스에 속하는 한 클래스 인터페이스의 서브클래스가 될 때 일어나는 결합이다. 본 모델에서는 상속의 복잡성을 피하기 위해, 상속받는 측의 인터페이스의 계층 구조들의 최상위 클래스들만이 상속 관계를 맺을 수 있도록 제약을 둔다. 그림 5는 상속관계를 이용한 결합의 예를 보여주고 있다.

두 컴포넌트사이의 상속에 의한 결합에서 상속은 엄밀하게 말하면 두 컴포넌트의 요구 또는 제공인터페이스들 간의 상속이다. 따라서 두 컴포넌트는 두개 이상의 인터페이스 계층을 가지고 있다면 상호 상속도 가능하다.

마지막으로 병렬관계에 의한 결합은 사용관계에 의한 결합의 특수한 경우로 서로 사용하는 관계가 없이 단순히 두개의 컴포넌트를 모은 것이다. 이러한 결합은 그 자체로는 의미가 없으나 복합 컴포넌트를 만들 때 사용될 수 있다.

그림 5. 상속관계에 의한 컴포넌트 결합

2.4.2 복합 컴포넌트

복합 컴포넌트는 앞 절에서 언급한 세 가지 컴포넌트의 결합방법에 의해 만들어진다. 복합컴포넌트도 하나의 컴포넌트이므로  컨트랙트와 내부 구현부분으로 구성된다. 내부구현은 부품 컴포넌트들로 이루어지는데, 이 때 부품 컴포넌트들은 기본 컴포넌트가 일 수도 있고 그 자체가 또 다른 복합 컴포넌트일 수도 있다. 복합 컴포넌트의 컨트랙트는 부품 컴포넌트들의 컨트랙트들에 의해 정의된다. 뒤에서 복합컴포넌트의 컨트랙트에 관한 규칙에 대하여 설명하기로 한다.

다시말하면, 복합 컴포넌트의 생성작업은 부품 컴포넌트들을 수집하고, 부품 컴포넌트들을 결합한 후 복합 컴포넌트에 대한 컨트랙트를 정의함으로써 이루어진다. 우선, 부품 컴포넌트 수집 단계에 지켜져야 할 규칙들을 기술하면 다음과 같다.

[규칙1] 한 복합 컴포넌트 내에 있는 서로 다른 부품 컴포넌트간에는 컴포넌트 식별자의 충돌이 없어야 한다.

[규칙2] 한 복합 컴포넌트 내에 있는 서로 다른 부품 컴포넌트들의 제공 인터페이스나 요구 인터페이스들에 속한 클래스 인터페이스간에는 식별자 충돌이 없어야 한다.

컴포넌트 결합은 두 부품 컴포넌트간의 사용 관계 또는 상속 관계를 반복적으로 수행함으로써 이루어진다. 마지막으로 복합컴포넌트의 컨트랙트는 요구인터페이스와 제공인터페이스들의 부합성(conformity)에 의해 정의된다. 우선 클래스 인터페이스 계층구조간의 부합성을 정의한 후 요구인터페이스와 제공인터페이스 사이의 부합성에 대하여 정의하기로 한다.

[정의 1] 두 계층구조간의 상속구조의 유지(Preservation of Inheritance Structure)

두개의 클래스 인터페이스 계층구조 □와 □에 대하여 □의 각 클래스 인터페이스에 대하여 이름에 의해 대응하는 클래스 인터페이스가 □에 존재하고, □의 임의의 두 클래스 인터페이스 i, j사이에서 i가 j의 서브클래스이면 이 두 클래스에 각각 대응하는 □의 클래스 인터페이스 g, h사이에도 g가 h의 서브클래스 관계가 성립하면 □가 □의 상속구조를 유지한다고 말한다.

[정의 2] 클래스 인터페이스 계층 구조간의 부합성(conformity)

임의의 클래스 인터페이스 계층 구조 □, □에 대하여 다음의 조건이 만족되면 □가 □에 부합한다고(conforms) 말한다:

□가 □의 상속구조를 유지하고,  □의 각 클래스 인터페이스  i의 모든 메쏘드 시그니처 x에 대해, i에 대응하는 □의 클래스 인터페이스 j 또는 j의 수퍼클래스 인터페이스 내에 y가 x의 서버타입 관계인 메쏘드 시그니처 y가 존재한다.

□가 □에 부합하는 경우를 □□□로 표현하기도 한다.

위 정의에서 메쏘드 시그니처간의 서브타입 관계는 [1]에서 정의한 메쏘드 시그니처의 서브타입 관계를 그대로 따르기로 한다.  그림 6은 클래스 인터페이스 계층구조 □가 클래스 인터페이스 계층구조 □에 부합하는 경우를 보여주고 있다. 이 그림에서 사각형은 클래스 인터페이스를 나타내며, 사각형안의 기호는 클래스 인터페이스 내의 메쏘드 시그니쳐를 나타낸다. 또한 방향이 없는 선분은 클래스 인터페이스간의 상속 관계를 표현하며, 방향이 있는 선분은 클래스 인터페이스 간의 매핑을 표현한다. 이 그림에서 메쏘드 시그니처 a와 b에 대해서는 매핑하는 클래스 인터페이스 자체에 대응하는 메쏘드 시그니처가 존재한다. 반면, 메쏘드 시그니처 c의 경우에는 매핑하는 클래스 인터페이스 내에는 대응 메쏘드 시그너처가 존재하지 않지만, 매핑하는 클래스의 상위 클래스에 대응하는 메쏘드 시그니처가 존재한다.

그림 6 객체 인터페이스 계층 구조 □가 □에 대입될 수 있는 관계

이제 클래스 인터페이스 계층 구조간의 부합성을 사용하여 클래스 인터페이스 계층 구조 집합간의 부합성을 다음과 같이 정의하기로 한다.

[정의 3] 클래스 인터페이스 계층 구조 집합간의 부합성(Conformity)

클래스 인터페이스 계층 구조의 집합 □, □가 있을 때, B의 각 원소 □에 대하여 그에 대응하는 □□□를 만족하는 A의 원소 □가 존재하면, □는 □에 부합한다(□ conforms to □)라고 말하며, □□□로 표시한다.

이제 부품 컴포넌트의 결합에 의해 생성된 복합 컴포넌트의 컨트랙트에 관한 규칙을 설명하기로 한다. 우선,  사용 관계에 의한 결합의 경우 부품 컴포넌트들과 복합 컴포넌트간에는 다음과 같은 규칙이 지켜져야 한다.

[규칙 3] 복합 컴포넌트 C 내의 부품 컴포넌트 A와 B가 서로 사용하는 관계일 때, A, B, C의 요구 인터페이스를 각각 □A, □B, □L, 이고, 제공 인터페이스를 각각 □A, □B, □C라 하고, 클래스 인터페이스 계층 구조의 집합 □, □를

□ = {□∈ □A | ～□ ∈ □B, □□□ },

□ = {□∈ □B | ～□ ∈ □A, □□□ }

라 하면, 다음의 두 식은 반드시 성립하여야 한다.

□C = (□A∪□B) - (□∩□)

□C ⊆ (□A∪□B)

상속 관계에 있는 두 부품 컴포넌트들간에는 다음의 규칙이 반드시 지켜져야 한다.

[규칙 4] 컴포넌트 A가 B를 상속하는 관계로 결합하여 컴포넌트 C를 이룰 때, A, B, C의 요구 인터페이스를 각각 □A, □B, □C, 이고, 제공 인터페이스를 각각 □A, □B, □C라 하면 다음의 두 식은 반드시 성립하여야 한다.

□C = □A∪□B

□C = □A□□B

위 규칙에서 연산 □ 는 상속 결합에 의한 부품 컴포넌트의 제공 인터페이스들의 통합 연산자로서, □A□□B의 결과값은 □A의 클래스 인터페이스 계층구조의 일부 또는 전부가 □B의 클래스 인터페이스 계층구조에 상속 관계로 통합된 결과이다.

2.5 부품 컴포넌트 교체

소프트웨어-IC를 지향하는 컴포넌트 프레임웍에서는 다른 컴포넌트에 대한 고려와 영향을 최소화하면서 부품 컴포넌트를 교체할 수 있어야 한다. 부품 컴포넌트 교체의 목적은 성능의 향상, 사용자 인터페이스의 변경 요구, 사용 자원의 변경 요구 등과 같이 부품 컴포넌트의 기능 변화에 무관한 경우도 있고, 새로운 기능의 추가, 추가적인 제공 인터페이스의 요구 등과 같이 컴포넌트 자체의 기능의 추가가 목적인 경우도 있다. 반면, 시스템 자원의 절약이나 비용의 절감을 위하여 기능이 더 적은 부품 컴포넌트로의 교체도 가능하다.

그러나 모든 경우에 부품 컴포넌트의 교체가 가능한 것은 아니다. 잘못된 부품 컴포넌트의 교체는 그 부품 컴포넌트뿐만 아니라 전체 컴포넌트, 그 전체 컴포넌트를 부품으로 사용하는 복합 컴포넌트, 나아가서는 어플리케이션 전체에까지도 영향을 미칠 수 있기 때문이다. 그러므로 본 프레임웍 모델에서는 부품 컴포넌트 교체의 규칙을 제시함으로써 컴포넌트의 교체가 컴포넌트 외부에 미치는 영향을 제한하고, 이러한 영향의 범위를 예측할 수 있도록 한다. 그림7은 부품 컴포넌트 교체의 개념도이다. 그림에서 부품 컴포넌트 A는 다른 부품 컴포넌트 B로 교체된다. 이때 교체가 가능하려면 B의 제공 인터페이스가 A의 제공 인터페이스에 부합해야 한다. 즉, 복합 컴포넌트가 A가 요구하는 서비스를 B가 모두 대신할 수 있어야 한다.

그림 7. 컴포넌트 교체의 개념도

다음의 규칙은 다른 컴포넌트에 영향을 미치지 않는 부품 컴포넌트 교체의 필요조건을 기술하고 있다.

[규칙 5] 컴포넌트 A와 B가 있을 때 A, B의 요구 인터페이스를 각각 □A, □B, 제공 인터페이스를 각각 □A, □B라 할 때, □A□□B 이고 □B□□A이면 컴포넌트 A로 항상 컴포넌트 B를 교체할 수(substitutable) 있다.

3. 결론 및 향후 과제

기존의 컴포넌트 모델들은 컴포넌트 모델을 개발하기 위해 시작하였다기 보다 대부분 어플리케이션 개발환경을 중심으로 사후에 기존의 모델을 컴포넌트 모델로 해석하거나 변경, 확장하였기 때문에 컴포넌트 모델의 이론적인 정립에 아직 미비한 부분이 많다. 본 논문에서는 시작단계에서부터 컴포넌트의 요구조건을 분석하여 보다 이론적이고 체계적인 컴포넌트 모델을 제시함으로써 보다 컴포넌트 기술의 궁극적인 목적에 도달하려고 하였다. 본 논문에서 제시한 컴포넌트 모델은 객체지향 개념에 바탕을 두고 있는데 하나의 컴포넌트는 객체지향적인 인터페이스(컨트랙트)를 가지고 있으며 이는 그 구현과 명확하게 분리된다. 이러한 컴포넌트들의 컨트랙트 사이의 부합성 관계를 정의하고 이에 따라 컴포넌트간의 결합규칙을 정의하여, 작은 컴포넌트들의 결합하여 더 큰 컴포넌트를 생성할 수 있게 하며, 그 컴포넌트를 다시 부품으로 사용할 수 있도록 한다. 또, 부합성 관계를 이용하여 컴포넌트 교체 가능성을 정의함으로써 전체에 영향을 미치지 않는 부품 컴포넌트 교체를 허용하여, 이미 운용되고 있는 어플리케이션의 유지보수, 수정, 확장을 용이하도록 하였다.

앞으로  본 논문에서 제시한 컴포넌트 모델은 보다 이론적으로 정교화 작업을 한 후, 컴포넌트 모델의 실험환경을 만들 계획이다. 컴포넌트 환경으로 다양한 경우를 고려해 볼 수 있다. 하나는 Java나 C++와 같은 순수한 객체지향 언어를 바탕으로 하나의 플랫폼에서 컴포넌트 개발환경을 구축하는 경우이고, 또 다른 방안으로는 CORBA의 목적과 같이 분산환경에서 이기종 플랫폼에서 컴포넌트 개발 환경을 고려해 볼 수 있다. 컴포넌트 환경이 제공해야 하는 서비스는 이러한 방안에 따라 크게 다르겠지만 기본적으로 컴포넌트 프로그래밍 언어와  컴포넌트의 생성과 저장을 위한 도구, 바이너리 컴포넌트 생성을 위한 도구, 그리고 컴포넌트를 이용한 소프트웨어의 운용환경등을 지원해야 한다.

4. 참조 문헌

[1] Andrew Black, Norman Hutchinson, Eric Jul, Henry Levy, and Larry Carter, Distribution and Abstract Types in Emerald," IEEE Transactions on Software Engineering, Vol. SE-13, No.1, January 1987.

[2] Brad J. Cox, Object Oriented Programming: An Evolutionary Approach, Addison-Wesley, Reading, MA, 1986.

[3] Carlos Canal, Ernesto Pimentel, Jose M. Troya, On the Composition and Extension of Software Components, Proceedings of Foundations of Component-Based Systems Workshop, 1997.

[4] Clemens Szypaski, Component Software Beyond Object-oriented Programming, Addison-Wesley, 1998.

[5] Cuno Pfister, Clemens Szyperski, Why Objects Are Not Enough, Proceedings of First International Component Users Conference, 1996.

[6] Kraig Brockschmidt, Indide OLE 2 Second Edition, Microsoft Press, 1995.

[7] OMG, CORBA: Architecture and Specification 2.0, 1996.

[8] Pual Harmon(Ed), Components, Component Development Strategies, Vol 8, No. 7,, July 1998.

[9] Sun Microsystems, JavaBeans 1.0, Dec. 4, 1996.

[10] Wolfgang Weck, Independently Extensible Component Framework, Proceedings of First International Workshop on Component-Oriented Programming, 1996.