工學博士學位論文

객체 지향 아키텍쳐에 기반한 컴포넌트

명세화 및 검색

Component Specification and Retrieval based on

Object-Oriented Architecture

2000 年 8 月

仁荷大學校 大學院

電子計算工學科

李 潤 洙

工學博士學位論文

객체 지향 아키텍쳐에 기반한 컴포넌트

명세화 및 검색

Component Specification and Retrieval based on

Object-Oriented Architecture

2000 年 8 月

指導敎授 王 昌 鍾

이 論文을 博士學位論文으로 提出함.

仁荷大學校 大學院

電子計算工學科

李 潤 洙

이 論文을 李潤洙의 博士學位 論文으로 認定함.

2000 年 8 月 日

主審 _________________________

副審 _________________________

委員 _________________________

委員 _________________________

委員 _________________________

i

요 약

컴포넌트 기반 소프트웨어 개발은 새로운 소프트웨어를 개발하기 위해

이미 개발된 소프트웨어들을 적절하게 수정하여 소프트웨어 개발에 적용함으

로써 소프트웨어 개발 기간을 단축시키고, 개발 비용의 절감과 소프트웨어의

생산성을 향상시킬 수 있는 효과를 얻을 수 있다. 이러한 컴포넌트의 재사용을

위해서는 컴포넌트의 기능 명세를 위한 명세 언어와 컴포넌트의 효율적인 검

색을 위한 검색 방법이 필수적으로 요구된다.

그러나, 기존의 명세 언어는 많은 경우 정형 명세에 기반하기 때문에 정

형 기법에 관한 지식이 부족한 개발자에게는 적합하지 않으며, 대부분의 명세

언어들은 기능에 관한 명세로 비기능의 명세 지원이 미흡하고, 특정 언어에 종

속적이며, 명세되는 시스템의 관점이 제한적이다. 또한, 재사용을 고려하지 않

았기 때문에 재사용의 지원이 미약하며, 구조적인 언어로 작성된 함수 단위의

기술을 제공하기 때문에 컴포넌트가 외부와 연결을 제공하는 인터페이스에 의

해 기능이 정의되는 특징을 표현하기에 부족하다.

그리고, 기존의 검색 방법들은 컴포넌트의 기능적인 측면이나 컴포넌트

를 구성하고 있는 함수 타입을 기준으로 비교하기 때문에 검색 시간이 길고,

검색의 효율과 검색의 정확성이 떨어지는 단점이 있다. 따라서, 컴포넌트 저장

소에 저장되어 있는 일치 수행을 위한 비교 횟수를 줄일 수 있고, 소프트웨어

의 구조적인 측면을 고려하여 정확성을 향상시킬 수 있는 검색 방법이 요구된

다.

따라서, 이 논문에서는 이러한 문제점들을 해결하기 위한 방법으로 소프

ii

트웨어 아키텍쳐의 개념을 적용하여 객체 지향 응용 개발에 이용할 수 있는

아키텍쳐에 기반한 컴포넌트 검색 방법과 이에 적합한 컴포넌트 명세와 아키

텍쳐 명세를 제공하는 XML 기반의 명세 모델을 제안하였다. 제안된 검색 방

법은 아키텍쳐 검색을 이용하여 개발자의 요구 사항과 구조적으로 일치하는

아키텍쳐를 검색한 후, 아키텍쳐를 재구성하기 위해 아키텍쳐 내의 컴포넌트와

대체될 수 있는 컴포넌트들을 개선된 시그니쳐 일치 검색 방법과 행위 일치

검색 방법을 사용하여 검색하도록 하며, XML 형태로 매핑된 명세 모델은 개발

자로 하여금 컴포넌트 명세 언어에 대한 특정 지식없이 원하는 컴포넌트에 대

한 요구 사항 정보를 기술할 수 있도록 한다.

제안한 검색 방법은 아키텍쳐 검색을 통해 검색된 아키텍쳐를 이용하여

아키텍쳐 재구성에 사용할 컴포넌트들의 검색 범위를 제한함으로써 검색의 재

현율과 정확성을 향상시키고, 일치 수행의 비교 횟수를 줄임으로써 검색 수행

시간을 단축시켰다. 또한, 이전 개발자들이 정의한 아키텍쳐의 재사용과 저장

된 컴포넌트의 재사용성을 향상시킬 수 있으며, XML 로 기술된 명세는 효율적

인 데이터 관리를 지원하며, 표준화된 사용자 인터페이스를 적용할 수 있고,

효율적인 검색이 가능하다.

iii

Abstract

Component-based software development applies to develop a new software through

modification of the legacy software. This reduces software development periods and

development costs and improves a software productivity. For a component reuse, we need a

component specification language to specify the behaviors of a component and a component

retrieval method to retrieve the appropriate components efficiently.

However, the legacy specification languages seem to be inappropriate to developers

who lack the enough knowledge of formal schemes, because they are based on the formal

specification. Most of specification languages are insufficient to specify non-behavioral

elements of a component and are dependent to a specific language. Moreover, they are

restrictive to the aspects of a specified system and do not support the reusability sufficiently.

They are also insufficient to describe the idioms defined by interfaces which provide

connections to the outside of the components, because they provide descriptions of

functional units written by the structural languages.

And, legacy retrieval methods have compared components with the functional types

or behavioral aspects of components. They increased retrieval times and reduced efficiency

and precisions of a retrieval. So, it is needed new retrieval method which can reduce

comparison counts to match the components in component repository and improve

precision with consideration of structural aspects of a software.

Therefore, in this paper, we propose architecture-based component retrieval method

to utilize object-oriented application development with the concepts of software architecture

iv

and XML-based specification model to provide the appropriate component specification and

architecture specification. The proposed retrieval method retrieves the architectures which

match to the developers requirements in structural aspects through architecture retrieval

module. And then, it retrieves the appropriate components which can substitute for the

components within the retrieved architecture for restructuring architecture through the

enhanced signature match retrieval method and behavior match retrieval method. The XML-

based specification model enables the developers to describe the requirements of a

component without any specific knowledge of a component specification language.

The proposed retrieval method improves recall and precision of a retrieval with a

reduction of a component retrieval scope utilizing retrieved architecture by the retrieval

module and reduces retrieval time by decreasing the comparison counts of components for

matching. It also improves reusability of the legacy architectures and components in a

repository. In addition, XML-based specification supports more efficient data management

and could be applicable to the generalized user interfaces and possibly to the more efficient

retrieval.

v

목 차

요 약.................................................................................................................................................i

Abstract ................................................................................................................................................iii

제 1 장 서 론...................................................................................................................................1

1.1 연구 배경 및 목적 ........................................................................................................1

1.2 연구 범위 및 논문의 구성 .........................................................................................7

제 2 장 컴포넌트 명세와 검색 방법의 고찰.....................................................................10

2.1 컴포넌트와 인터페이스 정의 언어 .......................................................................10

2.1.1 컴포넌트 소프트웨어 .....................................................................................10

2.1.2 인터페이스 정의 언어...................................................................................13

2.2 기존의 아키텍쳐 명세................................................................................................16

2.2.1 소프트웨어 아키텍쳐 .....................................................................................16

2.2.2 아키텍쳐 명세 언어 .......................................................................................18

2.3 XML과 XML기반 명세.............................................................................................23

2.3.1 XML......................................................................................................................24

2.3.2 XMI 와 MOF ......................................................................................................26

2.3.3 XML 명세 저장소............................................................................................29

2.4 기존의 컴포넌트 검색 방법.....................................................................................33

2.4.1 시그니쳐 일치에 의한 검색........................................................................33

2.4.2 명세서 일치에 의한 검색 ............................................................................35

2.4.3 행위 샘플링에 의한 검색 ............................................................................38

2.4.4 검색 효율의 평가 기준.................................................................................39

제 3 장 XML 기반 명세 모델과 아키텍쳐 기반 검색 모델 제안 .............................41

3.1 컴포넌트 검색 이론 ....................................................................................................41

3.1.1 검색을 고려한 명세 요소 ............................................................................41

3.1.2 방향성을 고려한 검색 이론........................................................................43

3.2 아키텍쳐 명세 모델 ....................................................................................................46

3.2.1 컴포넌트의 명세 ..............................................................................................47

3.2.2 커넥터의 명세 ..................................................................................................51

vi

3.2.3 아키텍쳐의 명세 ..............................................................................................54

3.3 컴포넌트 명세 모델 ....................................................................................................56

3.3.1 컴포넌트 명세의 특징...................................................................................56

3.3.2 인터페이스 명세 ..............................................................................................58

3.3.3 메시지 명세.......................................................................................................61

3.3.4 XML기반의 명세 언어 구조.......................................................................62

3.4 아키텍쳐에 기반한 컴포넌트 검색 모델 ............................................................65

3.4.1 아키텍쳐 검색 방법 .......................................................................................65

3.4.2 시그니쳐 일치 검색 .......................................................................................68

3.4.3 행위 일치 검색 ................................................................................................76

제 4 장 아키텍쳐 기반 컴포넌트 검색 시스템의 설계 및 구현...............................79

4.1 구현 환경과 시스템 구성 .........................................................................................79

4.1.1 구현 환경 ...........................................................................................................80

4.1.2 시스템 구성과 동작 .......................................................................................81

4.2 소프트웨어 개발을 위한 아키텍쳐 검색 ............................................................84

4.3 아키텍쳐 재구성을 위한 컴포넌트 검색 ............................................................88

4.3.1 시그니쳐 일치 검색 .......................................................................................90

4.3.2 행위 일치 검색 ................................................................................................97

4.4 명세 저장소와 웹 인터페이스 ............................................................................. 100

4.4.1 명세 저장소.................................................................................................... 100

4.4.2 웹 인터페이스 ............................................................................................... 103

제 5 장 실험 및 평가 ...............................................................................................................107

5.1 실험 환경 ..................................................................................................................... 107

5.2 아키텍쳐 기반 컴포넌트 검색 실험 .................................................................. 108

5.3 재현율과 정확성 측정............................................................................................. 118

제 6 장 결 론...............................................................................................................................122

참고 문헌 .......................................................................................................................................126

vii

그림 목차

[그림 2-1] 컴포넌트 인터페이스..............................................................................................12

[그림 2-2] C2 컴포넌트의 구조.................................................................................................21

[그림 2-3] OMG 메타 데이터 저장소 아키텍쳐 ................................................................26

[그림 3-1] 컴포넌트 명세를 위한 클래스 다이어그램....................................................50

[그림 3-2] 커넥터 명세를 위한 클래스 다이어그램 ........................................................53

[그림 3-3] 아키텍쳐 명세를 위한 클래스 다이어그램....................................................55

[그림 3-4] 개선된 행위 일치 검색 과정 ..............................................................................77

[그림 4-1] 시스템의 구현 환경 ................................................................................................80

[그림 4-2] 시스템의 구성과 동작............................................................................................81

[그림 4-3] 아키텍쳐 및 컴포넌트 검색의 순차 다이어그램 ........................................83

[그림 4-4] 아키텍쳐 검색의 순차 다이어그램...................................................................85

[그림 4-5] 컴포넌트 검색의 순차 다이어그램...................................................................89

[그림 4-6] 시그니쳐 일치 검색 모듈에 의한 컴포넌트 검색 과정 ...........................93

[그림 4-7] 행위 일치 검색 모듈에 의한 컴포넌트 검색 과정 ....................................98

[그림 4-8] 관계형 데이터베이스 매핑을 위한 개체-관계도 .......................................101

[그림 5-1] 아키텍쳐 검색을 위한 실험 환경 ...................................................................108

[그림 5-2] 질의 입력을 위한 사용자 인터페이스 ..........................................................109

[그림 5-3] 질의 확인을 위한 사용자 인터페이스 ..........................................................110

[그림 5-4] 질의의 내부 자료 구조 .......................................................................................112

[그림 5-5] 후보 아키텍쳐 브라우징을 위한 인터페이스.............................................113

[그림 5-6] 후보 컴포넌트 브라우징을 위한 인터페이스.............................................114

[그림 5-7] 아키텍쳐 최종 선택을 위한 인터페이스 ......................................................115

[그림 5-8] 아키텍쳐 기반 검색과 기존 컴포넌트 검색의 비교(1) ...........................119

[그림 5-9] 아키텍쳐 기반 검색과 기존 컴포넌트 검색의 비교(2) ...........................120

viii

표 목차

[표 2-1] 일반 함수 일치의 인스턴스 .....................................................................................34

[표 2-2] 선조건/후조건 일치 ....................................................................................................36

[표 2-3] 술어 일치의 분류 .........................................................................................................37

[표 2-4] 기존 컴포넌트 검색 방법들의 비교 .....................................................................40

[표 3-1] 컴포넌트 명세 정의에 필요한 요소 .....................................................................42

[표 3-2] 시그니쳐 파라미터의 방향성...................................................................................59

[표 3-3] 시그니쳐 일치의 인스턴스.......................................................................................69

[표 5-1] 실험 결과 ......................................................................................................................118

[표 5-2] 검색 효율 평가 기준에 따른 평가......................................................................121

[표 5-3] 기존 검색 방법과의 비교 .......................................................................................121

ix

알고리즘 목차

[알고리즘 1] 아키텍쳐 검색 알고리즘..................................................................................86

[알고리즘 2] 개선된 시그니쳐 일치 검색 알고리즘 .......................................................91

[알고리즘 3] 시그니쳐 일치의 완전 일치 검색 알고리즘 ............................................94

[알고리즘 4] 시그니쳐 일치의 타입 이완 일치 검색 알고리즘.................................94

[알고리즘 5] 시그니쳐 일치의 방향 이완 일치 알고리즘 ............................................96

[알고리즘 6] 개선된 행위 일치 검색 알고리즘 ................................................................99

x

리스트 목차

[리스트 3-1] 가변 컴포넌트 표기............................................................................................48

[리스트 3-2] 단순 컴포넌트 표기............................................................................................48

[리스트 3-3] 가변 커넥터 표기 ................................................................................................52

[리스트 3-4] 단순 커넥터 표기 ................................................................................................52

[리스트 3-5] 소프트웨어 아키텍쳐 명세의 전체 구조....................................................54

[리스트 3-6] 시그니쳐 명세 문법............................................................................................59

[리스트 3-7] 기능 명세 문법 ....................................................................................................60

[리스트 3-8] 인터페이스 명세 문법 .......................................................................................61

[리스트 3-9] 메시지 명세 문법 ................................................................................................62

[리스트 3-10] 컴포넌트 명세의 DTD 정의 .........................................................................63

[리스트 3-11] 컴포넌트 명세의 기본 구조 ..........................................................................63

[리스트 4-1] 아키텍쳐 표현을 위한 스타일 시트 ..........................................................104

[리스트 5-1] 아키텍쳐 질의의 예..........................................................................................111

[리스트 5-2] 개발자가 선택한 아키텍쳐 명세의 일부..................................................116

xi

정의 목차

[정의 1] 일반적인 함수 일치 ...................................................................................................33

[정의 2] 일반적인 선조건/후조건 일치 ...............................................................................36

[정의 3] 술어 일치 .......................................................................................................................37

[정의 4] 완전 동등 .......................................................................................................................43

[정의 5] 강한 동등 .......................................................................................................................44

[정의 6] 시그니쳐 동등...............................................................................................................45

[정의 7] 구조 동등 .......................................................................................................................45

[정의 8] 시간 동등 .......................................................................................................................45

[정의 9] 아키텍쳐의 일치 ..........................................................................................................66

[정의 10] 개선된 시그니쳐 일치 .............................................................................................69

[정의 11] 시그니쳐 일치의 완전 일치..................................................................................71

[정의 12] 시그니쳐 일치의 일반화 일치 .............................................................................73

[정의 13] 시그니쳐 일치의 특수화 일치 .............................................................................73

[정의 14] 시그니쳐 일치의 방향 이완 일치.......................................................................74

1

제 1 장 서 론

1.1 연구 배경 및 목적

소프트웨어가 대형화되고, 복잡해짐에 따라 컴포넌트 기반 소프트웨어

개발(Component Based Software Development)은 시스템을 컴포넌트의 조합만으로

완성함으로써 소프트웨어 개발의 새로운 패러다임(paradigm)으로 생각되어 지고

있다. 또한, 대부분의 소프트웨어 프로젝트들은 개발 기간이 지연되고, 예산을

초과하거나 사용자들이 원하는 고품질의 소프트웨어를 생산하지 못함으로 인

해 실패하는 경우가 많다[Koz98, Mil95, Szy98].

이에 대한 해결 방안으로 소프트웨어 재사용 기술이 소개되면서 80 년대

부터 이와 같은 소프트웨어 컴포넌트(Software Components) 시장을 구축하기 위

한 기술로 객체 지향 프로그래밍이 본격적으로 도입되기 시작하였다. 당시의

소프트웨어 재사용(Software Reuse)은 클래스 단위의 재사용에 초점을 두었다.

데이터와 오퍼레이션들을 객체(object)와 클래스(class) 단위로 통합함으로써 재

사용성(reusability)의 증대를 가져왔다.

클래스들은 클래스 라이브러리(Class Library)로 패키지화 되었고, 이러한

클래스 라이브러리들은 리스트(list)나 큐(queue)와 같은 서로 다른 데이터들을

위한 클래스들로 구성되었다. 그리고 클래스 라이브러리들은 상속 구조를 이용

함으로써 효율적인 재사용성을 제공하였다[Bro98, Koz98, Per93].

그러나, 이와 같은 클래스 라이브러리 단위의 재사용도 충분한 소프트웨

어 재사용성을 제공하지 못하고, 소프트웨어 개발자들은 여전히 응용 소프트웨

2

어의 대부분을 자동화된 도구의 활용보다는 개발자 개인의 프로그래밍 능력과

자동화되지 못한 개발 절차에 의존하는 개발 관행을 따르고 있다. 이는 클래스

라이브러리 단위로 재사용을 하는 데 있어서 복잡성이나 중복성 그리고 제어

흐름으로 인한 많은 한계점이 따르기 때문이다.

오늘날 이와 같은 클래스 라이브러리의 한계점을 극복하고, 소프트웨어

재사용성을 향상시키기 위한 방법으로 컴포넌트 단위의 재사용 기법이 도입되

고 있다. 소프트웨어 재사용 측면에서 살펴 보면 컴포넌트 기술은 객체 지향

프레임워크(Object Oriented Framework) 단위의 재사용보다는 바이너리 코드

(Binary Code) 단위의 재사용에 초점을 두고 있다.

객체 지향 프레임워크는 설계와 일부 구현의 재사용을 모두 지원함으로

인해서 재사용의 효율성은 기존의 클래스 라이브러리에 비해 향상되었으나 프

레임워크 사용자들이 프레임워크를 사용하기 어렵다는 문제점이 있었다. 이러

한 문제점을 해결하면서 동시에 재사용성의 효과를 높이기 위해 컴포넌트는

바이너리 코드 단위의 재사용을 제공하고 있다[Szy98].

소프트웨어 재사용은 소프트웨어 위기 현상을 극복하기 위한 방안으로

널리 연구되고 있는 소프트웨어 공학의 여러 분야 중에서 관심이 상대적으로

증가하고 있는 분야이다[Boe81, Kru92]. 소프트웨어 재사용은 개발되어 있는 컴

포넌트들을 새로운 소프트웨어 개발에 사용함으로써 소프트웨어 개발 기간을

단축시키고, 개발 비용의 절감과 소프트웨어의 생산성을 향상시킬 수 있는 효

과를 얻을 수 있다[Big89, Kru92, Pen97].

따라서, 소프트웨어 개발에 필요한 컴포넌트들을 재사용하기 위해서는

소프트웨어 컴포넌트들을 분류하여 컴포넌트 저장소(Component Repository)에 저

장하고, 개발자의 요구와 일치하는 컴포넌트들을 검색해야 한다.

3

컴포넌트는 구조와 행위를 캡슐화하여 사용자가 내부 동작을 몰라도 인

터페이스(interface)만 사용하여 원하는 서비스를 제공받는 장점을 가지고 있고,

이러한 컴포넌트를 기반으로 한 개발은 상호작용으로 컴포넌트를 조립하는 과

정으로 볼 수 있다. 따라서, 많은 컴포넌트 개발자들은 CORBA 와 DCOM 과

같은 소프트웨어 버스를 기반으로 한 컴포넌트 기반 소프트웨어 개발이 광범

위한 소프트웨어 재사용을 유도하여 컴포넌트 시장이 더욱 성장될 것으로 보

고 있다.

컴포넌트 기반 소프트웨어 개발이란 독립적인 기능을 담당하는 다양한

컴포넌트 소프트웨어의 집합으로부터 해당 업무의 수행에 필요한 기능을 담당

하는 하나 이상의 컴포넌트들을 결합하여 해당 업무를 위한 소프트웨어를 개

발하는 기술이다[Kir98, Lee99, Low98].

세계적인 소프트웨어 시장에서 소프트웨어 개발 프로젝트에서의 주된 변

화는 규모가 큰 소프트웨어 시스템을 개발, 분류, 갱신하는 방법으로 이루어지

고 있다[Bro96, Dia87]. 소프트웨어 시스템을 하나의 컴포넌트의 조합으로 설계

하고 구현하는 것은 이제 더 이상 새로운 개념이 아니며, 규모가 큰 소프트웨

어 개발은 컴포넌트의 적절한 검색, 검증 그리고 통합 과정을 통해 이룰 수 있

게 되었다.

이러한 컴포넌트의 재사용을 위해 우선 필요한 것은 컴포넌트의 기능을

명세하는 명세 언어이다[Pen96, Rol91]. 컴포넌트 명세 언어(Component Specifi-

cation Language)는 특정 문제에 대한 컴포넌트의 기능을 기술함으로써 컴포넌트

재사용성을 향상시키고 보다 쉽게 접근할 수 있는 방법을 제공한다. 이를 위해

서는 사용자의 요구 사항 정보를 추출하고, 비교하는 과정이 필요하다[Maa91,

Pen95].

4

컴포넌트 명세에 있어 기존에 이미 많은 명세 언어가 사용되고 있으며,

이들은 나름대로의 장점을 가지고 있다. 그러나, 이들은 대부분 구현을 위해

특정 언어에 의존성이 강하며, 표현 능력에 한계를 가지고 있다[Gut91]. 이러한

한계를 해결하기 위해 문제 요구사항에 대한 설명, 컴포넌트의 기능 그리고 컴

포넌트 구조에 대한 명확한 정의를 제공하는 정형화된 명세 언어(Formal

Specification Language)에 대한 연구가 이루어져 왔다[Gut85, Jen94, Jen95].

그러나, 기존의 명세 언어들은 구조적 프로그래밍 방법을 고려한 형태의

명세였기 때문에 컴포넌트 명세에 적용하기에는 문제점이 있다. 또한, 이러한

명세는 설계 단계에 초점을 두고 있기 때문에 소프트웨어 재사용을 위해서는

보완이 필요하다.

최근 소프트웨어 시스템을 컴포넌트의 조합으로 구현하는데 있어 소프트

웨어 아키텍쳐(Software Architecture)의 관점에서 접근하는 연구가 진행되고 있다

[Gar97, Kaz96, Lee2000, Med98]. 이러한 접근을 지원하기 위한 명세에 관한 연구

도 활발히 진행중이다[Med99]. 컴포넌트 기반 소프트웨어 개발과 관련된 기술

들 중의 하나인 소프트웨어 아키텍쳐는 시스템의 구조적 기술로서 시스템을

구성하는 컴포넌트와 그 컴포넌트들 사이의 상호작용을 기술한 것이다[All97,

But96].

그러나, 아키텍쳐 관점의 접근을 제공하는 명세도 설계에 초점을 두고

있고, 재사용을 고려하지 않은 구현을 위한 부분들을 다수 포함함으로써 재사

용을 위해 이용하기에 어려운 단점이 있다. 따라서, 컴포넌트 기반 소프트웨어

개발에서 컴포넌트는 재사용을 고려해서 컴포넌트 저장소에 저장, 관리해야 하

며, 저장된 컴포넌트들은 사용자의 요구사항에 적합한 컴포넌트들이 효율적으

로 검색되어져야 한다.

5

또한, 최근에 와서 새로운 소프트웨어를 개발하기 위해 재사용 가능한

컴포넌트의 검색 방법에 관한 연구가 활발히 진행되고 있다. 대표적인 예가

Zaremski 와 Wing 이 제안한 시그니쳐 일치(Signature Match) 방법[Zar93]과 명세서

일치(Specification Match) 방법[Zar95b] 그리고 소프트웨어의 실행 속성을 기반으

로 하여 컴포넌트를 검색하는 행위 샘플링(Behavioral Sampling)에 의한 검색 방

법[Pod92]이 있다.

시그니쳐 일치 방법은 함수의 파라미터 타입이나 인터페이스와 같은 시

그니쳐 정보를 사용하여 컴포넌트를 검색하는 방법이다[Zar93, Zar95a]. 그리고,

명세서 일치 방법은 두 개의 컴포넌트 명세서를 비교하기 위한 방법이다

[Zar95b, Zar96, Zar97]. 행위 샘플링 방법은 소프트웨어 저장소로부터 컴포넌트들

의 자동화된 검색을 지원하며, 소프트웨어 컴포넌트의 기능적인 측면에서 컴포

넌트를 검색하는 방법이다[Pod92, Pod93].

이와 같은 기존의 검색 방법들은 컴포넌트 저장소에 저장된 전체 컴포넌

트를 대상으로 하기 때문에 검색 시간이 길고, 컴포넌트의 기능적인 측면이나

컴포넌트를 구성하고 있는 함수 타입만을 비교하기 때문에 검색의 효율과 검

색의 정확성이 떨어지는 단점이 있다. 따라서, 컴포넌트 저장소에 저장되어 있

는 일치 수행을 위한 비교 횟수를 줄일 수 있고, 소프트웨어의 구조적인 측면

을 고려하여 정확성을 향상시킬 수 있는 검색 방법이 요구된다.

따라서, 이 논문에서는 이러한 문제점들을 해결하기 위한 방법으로

XML(eXtensible Markup Language)[Kha97]을 기반으로 한 컴포넌트 명세 모델을 제

안하였다. 제안한 명세 모델을 XML형태로 매핑시킴으로 XML의 기본적인 특

징 중 하나인 구조적인 형태의 컴포넌트 명세 형식을 나타낸다. 이는 개발자로

하여금 컴포넌트 명세에 대한 특정 지식 없이 원하는 컴포넌트에 대한 요구

6

사항 정보를 기술할 수 있도록 한다. 그리고, 기술된 명세는 XML 문서로 저장

되므로 저장소를 효율적으로 관리할 수 있다.

이 논문에서 제안하는 컴포넌트 명세 모델은 재사용을 고려하여 컴포넌

트 기능 명세와 아키텍쳐 명세 두 형태의 명세 모델을 제공한다. 컴포넌트 기

능 명세는 컴포넌트 기능을 명세함으로써 블랙 박스 재사용(Black Box Reuse)을

지원하는 것이고, 아키텍쳐 명세는 구조적인 재사용 즉, 화이트 박스 재사용

(White Box Reuse)을 지원한다. 이 두 형태의 명세는 서로 개별적인 것이 아니라

컴포넌트 명세로 기술된 컴포넌트를 아키텍쳐 명세에서 사용할 수 있다.

또한, 소프트웨어 아키텍쳐의 개념을 도입하여 제안한 아키텍쳐 명세와

컴포넌트 명세가 컴포넌트 저장소(Component Repository)와 아키텍쳐 저장소

(Architecture Repository)에 저장되어 있을 때 개발자의 아키텍쳐 질의에 의해 유

사한 아키텍쳐를 검색하기 위한 아키텍쳐 검색 방법을 제안한다. 그리고, 검색

된 아키텍쳐를 재구성하기 위해 아키텍쳐를 구성하는 컴포넌트 그룹 내에서

컴포넌트 검색을 수행하기 위한 개선된 시그니쳐 일치 검색 방법과 개선된 행

위 일치 검색 방법을 제안하여 아키텍쳐에 기반한 컴포넌트 검색 시스템

(Architecture based Component Retrieval System)을 설계하여 검색 시스템의 프로토

타입(prototype)을 구현하였다.

소프트웨어 개발에 적합한 아키텍쳐 검색은 컴포넌트의 기능적인 측면보

다는 구조적인 측면을 고려하여 저장소에 저장된 컴포넌트들을 조합하여 아키

텍쳐를 재구성할 수 있으므로 검색된 아키텍쳐들을 구성하는 컴포넌트들로 컴

포넌트 검색의 범위를 축소시킬 수 있으며, 검색 범위의 축소에 의해서 검색의

재현율(recall)과 정확성(precision)을 향상시킬 수 있고, 검색 수행 시간을 줄일

수 있다.

7

1.2 연구 범위 및 논문의 구성

이 논문의 범위는 컴포넌트 소프트웨어의 개념과 최근 컴포넌트 분야의

기반을 이루고 있는 프레임워크인 CORBA 컴포넌트와 DCOM 컴포넌트의 인

터페이스 정의 언어를 분석하고, 기존의 아키텍쳐 명세 언어와 XML 의 특성

및 XML 에 기반한 명세 저장소 등을 분석한다.

그리고, 기존의 컴포넌트 검색 방법 등을 분석하고, 소프트웨어 아키텍쳐

개념을 적용하여 XML기반의 명세 모델을 제안한다. 또한, 재현율과 정확성을

향상시킬 수 있는 컴포넌트 검색 방법을 제안하며, 객체 지향 응용 개발에 이

용할 수 있는 아키텍쳐에 기반한 컴포넌트 검색 시스템을 설계하고, 검색 시스

템의 프로토타입을 구현한다. 그리고, 구현된 검색 시스템에 대해 실험을 통해

제안한 컴포넌트 검색 방법의 타당성을 입증한다.

이 논문에서 제안하는 명세 모델은 일반적인 컴포넌트 기반 소프트웨어

개발에 사용될 수 있는 컴포넌트 명세에 적용 가능하며, 아키텍쳐에 기반한 컴

포넌트 검색 방법은 객체 지향 응용 개발에서 메시지를 기반으로 하는 운영

환경에 적합하다. 그리고, 현재 사용자 상호 작용을 지원하는 GUI 응용 개발을

위한 컴포넌트들을 명세하여 실험에 적용한다.

구체적인 연구의 범위는 다음과 같다.

첫째, 컴포넌트 소프트웨어와 소프트웨어 아키텍쳐의 특성들을 분석한다.

분석된 특성들은 소프트웨어 재사용을 고려한 컴포넌트 명세와 검색 방법에

적용된다.

둘째, 아키텍쳐 명세에 대한 기존의 명세 언어들을 분석하여, 이 논문에

서 제안할 명세 모델을 설계하는 기본 방향을 설정한다.

8

셋째, XML 의 특성과 XML 기반 명세를 분석하여 재사용을 고려한 XML

기반 컴포넌트 명세 모델을 제안한다. 제안하는 명세 모델은 컴포넌트 기능

명세와 아키텍쳐 명세 두 형태의 명세로 구분되며, 효율적인 검색을 가능하

게 한다.

넷째, 기존의 인터페이스 정의 언어를 분석하여 제안할 명세 모델의 컴

포넌트 인터페이스를 기존의 IDL 형태로 설계하는 기본 방향을 설정한다.

다섯째, 기존의 명세 저장소의 종류들을 분석하여, 이 논문에서 사용되는

아키텍쳐 및 컴포넌트 저장소에 적합한 저장소를 설계한다.

여섯째, 기존의 컴포넌트 검색 방법들을 분석하여 검색의 재현율과 정확

성을 향상시킬 수 있는 소프트웨어 아키텍쳐의 개념을 적용하여 컴포넌트를

검색할 수 있는 아키텍쳐에 기반한 컴포넌트 검색 방법을 제안한다.

일곱째, 아키텍쳐에 기반한 컴포넌트 검색 시스템을 설계 및 구현한다.

구현된 프로토타입 검색 시스템은 실험 및 평가를 통해 제안한 검색 방법의

타당성을 보인다.

이 논문의 구성은 다음과 같다.

2 장에서는 컴포넌트 소프트웨어의 개념과 최근 컴포넌트 분야의 기반을

이루고 있는 프레임워크인 CORBA 컴포넌트와 DCOM 컴포넌트의 인터페이스

정의 언어를 분석하고, 기존의 아키텍쳐 명세와 XML 의 특성 및 XML 기반 명

세 등을 분석한다. 또한, 검색을 고려한 명세 저장소와 기존의 컴포넌트 검색

방법 등을 분석한다.

3 장에서는 아키텍쳐의 개념을 도입하여 검색에 사용되는 파라미터의 방

향성을 고려한 검색의 요구 사항들을 정의하여 XML에 기반한 아키텍쳐 명세

9

모델과 컴포넌트 명세 모델을 제안하고, 아키텍쳐 저장소로부터 아키텍쳐 검색

을 위한 아키텍쳐 검색 방법과 아키텍쳐 재구성에 사용되는 컴포넌트 저장소

로부터 컴포넌트 검색을 위한 개선된 시그니쳐 일치 검색(Enhanced Signature

Match Retrieval) 방법과 개선된 행위 일치 검색(Enhanced Behavior Match Retrieval)

방법을 제안한다.

4 장에서는 아키텍쳐에 기반한 컴포넌트 검색 시스템을 설계하고, 프로토

타입 검색 시스템을 구현한다. 5장에서는 이 논문에서 제안한 컴포넌트 검색

방법의 타당성을 입증하기 위해 실험을 통해 검색의 재현율과 정확성을 이용

하여 평가한다. 마지막으로, 6장에서는 이 논문의 결과와 향후 연구 과제를 기

술한다.

10

제 2 장 컴포넌트 명세와

검색 방법의 고찰

이 장에서는 컴포넌트 소프트웨어의 개념과 최근 컴포넌트 분야의 기반

을 이루고 있는 프레임워크인 CORBA 컴포넌트와 DCOM 컴포넌트의 인터페

이스 정의 언어를 분석하고, 기존의 아키텍쳐 명세 및 XML 의 특성 등을 분석

한다. 그리고, 검색을 고려한 명세 저장소들과 기존의 컴포넌트 검색 방법 등

을 분석한다.

2.1 컴포넌트와 인터페이스 정의 언어

이 절에서는 컴포넌트 소프트웨어의 개념 그리고 현재 RFP(Request For

Proposal) 형태로 제출된 CORBA 컴포넌트 모델과 표준화된 컴포넌트 모델인

DCOM 의 인터페이스를 정의하기 위해 사용되는 인터페이스 정의 언어에 대해

서 분석한다.

2.1.1 컴포넌트 소프트웨어

컴포넌트 소프트웨어의 개념은 특정한 기능들을 다른 응용에서 재사용할

수 있게 해준다. 소프트웨어의 재사용은 소프트웨어 개발자와 객체 지향 프로

그래밍 기법의 오랜 숙원이며, 컴포넌트 소프트웨어는 변경없이 재사용이 가능

하도록 설계되어야 한다[Boo94, Bro98, Szy98].

컴포넌트를 크기 관점에서 살펴보면 클래스(class), 컴포넌트(component),

11

프레임워크(framework) 그리고 응용(application)으로 분류할 수 있다. 하나의 클

래스를 하나의 컴포넌트로 구현하면, 기존의 클래스 라이브러리와 거의 유사한

형태라고 볼 수 있다. 그러나, 보다 큰 단위의 재사용을 위한 단위로 표현하면

프레임워크에 해당한다. 즉, 프레임워크는 단지 하나의 클래스라기 보다는 서

로 관련된 여러 클래스들을 포함하고 있으면서 클래스들간의 메시지 흐름을

프레임워크내에 포함하게 된다. 이러한 프레임워크가 확장하여 하나의 응용이

될 수도 있다[Bro98, Koz98] .

컴포넌트는 외부와 인터페이스만을 통해 동작하므로 외부와 철저히 단절

되고 결과적으로 시스템의 단순성이 높아지며, 복잡성이 떨어진다. 또한, 객체

지향 프로그래밍 개념으로 컴포넌트를 작성해 그 내부에 많은 객체가 존재하

더라도 이러한 객체는 컴포넌트 내부의 객체에만 접근할 수 있고, 외부로의 접

근은 컴포넌트의 인터페이스를 통해 제한된다. 이것은 순수한 객체 지향 프로

그래밍보다 발전된 형태인 블랙 박스 추상화(Black Box Abstraction)라고 볼 수

있다[But98, Szy98].

또한, 컴포넌트는 객체 지향 특성을 많이 갖고 있으나, 객체 지향 언어로

만 구현되는 것은 아니다 . 많은 경우 컴포넌트는 다음과 같은 특성들을 가지고

있다[Szy98].

• 컴포넌트를 구별하는 식별자를 가진다 .

• 동일한 서비스를 제공하는 새로운 버전으로의 변경이 해당 컴포넌트를

사용하는 응용 소프트웨어나 다른 컴포넌트에 영향을 주지 않아야 한다 .

• 서비스는 인터페이스를 통해서 제공하고, 컴포넌트 인터페이스의 변경이

없어야 한다 .

12

• 자신의 인터페이스에 대한 명확한 설명을 함께 제공하여야 한다.

• 개발 도구나 언어 그리고 플랫폼에 독립적인 재사용이 가능해야 한다.

• 실행 시점에 동적 재사용이 가능해야 한다.

컴포넌트 기반 소프트웨어는 위와 같은 특성을 가진 컴포넌트들의 집합

으로 구성되며, 이들의 상호작용으로 원하는 기능을 제공하는 소프트웨어를 말

한다. 컴포넌트 기반 소프트웨어를 구축하는데 있어 기본적인 이해 및 구현의

단위는 컴포넌트이다. 하나의 컴포넌트는 독립된 인터페이스를 지원할 수 있는

여러 개의 객체 참조(Object Reference)를 가질 수 있다.

컴포넌트는 컴포넌트 정의를 준수하는 인터페이스를 갖는 유일한 참조를

갖는다. 이 인터페이스는 제공되는 다른 인터페이스들과 컴포넌트 기능의 컨테

이너(container)로 동작한다 . 이렇게 다른 것들과 구분되는 참조와 인터페이스를

컴포넌트 참조(Component Reference)와 컴포넌트 인터페이스(Component Interface)

라 한다. 컴포넌트에서 제공되는 다른 인터페이스들은 제공되는 인터페이스

(Provided Interface)라고 부른다. [그림 2-1]은 컴포넌트와 제공되는 인터페이스의

관계를 나타낸 것이다 .

Component

Component Reference

Provided Reference Encapsulated Implementation of Provided Interface

[그림 2-1] 컴포넌트 인터페이스

13

컴포넌트 인터페이스는 기본적으로 컴포넌트 참조에 의해 식별되며, 컴

포넌트 참조가 동일한 경우, 제공되는 참조의 집합으로 식별된다. 컴포넌트 모

델은 동일한 컴포넌트 인스턴스(Component Instance)에 속한 서로 다른 참조를

식별하는 연산을 제공하며, 이 연산은 컴포넌트의 참조들을 검사한다.

동일한 컴포넌트 인스턴스라는 의미는 궁극적으로 컴포넌트 개발자가 컴

포넌트를 개발할 당시의 구현 방법에 달려 있으며, 개발자는 정의된 연산을 서

로 다른 컴포넌트에서 동일하게 구현할 수도 있고 다르게 구현할 수도 있다는

의미이다. 그러나, 컴포넌트 프레임워크는 동일함의 정의에 근거하여 표준화된

구현을 제시한다.

2.1.2 인터페이스 정의 언어

현재 널리 사용되는 컴포넌트 모델로는 CORBA 컴포넌트 모델과

EJB(Enterprise JavaBeans) 그리고 마이크로소프트사의 DCOM(Distributed

Component Object Model) 등이 있다. CORBA 컴포넌트 모델은 IBM, IONA, Oracle,

Sun 등의 업체에서는 1997 년 5 월 OMG(Object Management Group)에 CORBA 에

적용할 수 있는 컴포넌트 기술로 EJB 의 컴포넌트 모델에 기반을 둔 CORBA

컴포넌트 모델에 대한 백서를 제출하였으며, 현재 CORBA 3.0 표준으로 확립되

고 있다[OMG99].

OMG 는 이 백서에 영향을 받아 CORBA 컴포넌트 모델을 제안했으며,

제안하고 있는 개념 중 가장 핵심적인 것은 컴포넌트의 기능을 사용자에게 보

여지는 부분과 업무 논리, 데이터베이스 제어 등으로 분리한 것이다. 특히 업

무 객체 개념의 도입은 다단계 클라이언트/서버 환경에 적용 가능한 컴포넌트

모델의 근간이 되었다.

14

CORBA 에서의 컴포넌트는 객체 타입의 확장으로 정의될 수 있다. 이러

한 컴포넌트 타입은 IDL(Interface Definition Language)에 의해 정의될 수 있으며,

인터페이스 저장소에 저장될 수 있다. 컴포넌트는 객체 참조를 특수화한 컴포

넌트 참조를 통해 표현되며, 컴포넌트 정의는 특수화되고, 확장된 형태의 인터

페이스 정의가 된다.

CORBA 의 IDL 은 분산 환경에서 어떤 프로그래밍 언어나 컴파일러 등에

상관없이 CORBA 응용 프로그램을 작성할 수 있게 해준다. 즉, IDL 로 작성된

CORBA 응용 프로그램은 IDL 컴파일러를 통해 원하는 프로그래밍 언어에 적

합한 코드로 변환된다. 사용자는 이 코드를 이용하여 원하는 응용 프로그램을

개발하게 된다.

현재 IDL 은 C/C++로의 매핑을 지원하고 있으며, 많은 제품들이 자바

매핑도 지원하고 있다. 그리고 Smalltalk, Ada, Cobol 등과 같은 다양한 언어를 지

원할 예정이다. IDL 은 특정 프로그램밍 언어와 컴파일러에 독립적이고, 다중

상속(Multiple Inheritance) 등과 같은 객체 지향 개념을 지원한다. 그리고, IDL 은

구현을 위한 프로그래밍 언어가 아니며, 동적 호출 메커니즘(Dynamic Invocation

Mechanism)을 제공한다.

IDL 에서 가장 기본이 되는 단위는 인터페이스이다. 인터페이스는 속성

(attributes)과 메소드(methods)로 구성된다. 대부분의 문법은 자바 언어의 구문과

매우 유사하다. 그러나, 파라미터 타입의 경우 클라이언트와 구현 객체간 이동

방향에 따라 입력(In), 출력(Out), 입출력(Inout)으로 선언할 수 있다.

In 의 경우 클라이언트에서 구현 객체로, Out 은 구현 객체에서 클라이언

트로, Inout 은 양방향으로 이동 가능한 파라미터를 의미한다. IDL 은 인터페이

스를 선언하기 위한 문법뿐만 아니라 기본 자료형을 제공한다. 기본 자료형을

15

사용하여 작성된 인터페이스를 새로운 자료형으로 사용할 수 있다.

COM(Component Object Model)/DCOM(Distributed COM)은 마이크로소프트

사의 모든 제품들에 근간이 되고 있는 기술이다. 특히, 분산 객체 기술의 표준

으로 CORBA 가 대두되면서 COM/DCOM 은 CORBA 에 대응하는 마이크로소프

트사의 컴포넌트 모델이다[Edd98, Gri97].

DCOM 은 근거리 통신망(Local Area Network ; LAN), 원거리 통신망(Wide

Area Network ; WAN) 또는 인터넷(Internet)에서 서로 다른 플랫폼들간의 통신을

지원하기 위한 COM 의 확장형이다. DCOM 모델에서 인터페이스 정의 언어로

사용하는 MIDL(Microsoft Interface Definition Language)는 인터페이스 설계자가 손

쉽게 인터페이스를 작성할 수 있고, 인터페이스 메소드의 원형을 첨가할 수 있

게 해 준다. 그런 다음 프로그래밍 언어 고유의 컴파일러를 가지고 IDL 을 컴

파일하면 특정 언어의 소스 코드를 생성할 수 있다.

또한, MIDL 은 인텔 기계(Intel Machine)를 위한 C/C++ 코드를 생성하고,

알파(Alpha)와 RPC(Remote Procedual Call)를 위한 코드를 생성시킨다. MIDL 은

RPC 에 대한 코드를 생성하는데, 사용된 MIDL 이전 버전과 ODL(Object

Description Language)을 컴파일하여 자동화을 위한 타입 라이브러리를 조합한

것이다.

MIDL 의 장점은 크게 두 가지가 있다. 첫째는 인터페이스에 대해 언어별

로 고유한 매핑을 제공한다. 둘째는 프록시(proxy)와 스터브(stub)에 대한 코드를

제공한다. 인터페이스를 정의하기 위한 언어인 MIDL 로 정의한 후 MIDL 컴파

일러를 이용하여 프록시와 스터브 코드를 생성한다. COM 서버를 사용하는 프

로그램은 프록시 코드에서 제공되는 COM 서버의 인터페이스를 통해 COM 서

버의 서비스에 접근하며, 스터브 코드는 COM 서버에서 사용된다.

16

COM 서버를 만들 때는 이런 인터페이스에 대한 클래스를 만들고, 클라

이언트는 COM 서버에 접근하기 위해 사용하려는 인터페이스가 무엇이며, 그

것의 클래스는 무엇인지 알아야 한다. COM 에서는 여기에 고유한 ID 를 제공

하는데 인터페이스에 대해 IID(Interface IDentifier), 클래스에 대해 CLSID(CLaSs

IDentifier)를 제공한다.

이 논문에서는 인터페이스를 선언하기 위한 문법뿐만 아니라 기본 자료

형을 제공하며, 인터페이스를 정형화 할 수 있는 표준 인터페이스 언어인 IDL

형식에 따라 컴포넌트 인터페이스를 갖는 명세 모델을 제안한다.

2.2 기존의 아키텍쳐 명세

이 절에서는 소프트웨어 아키텍쳐의 개념 및 기존의 아키텍쳐 명세 언어

인 Rapide 와 C2 그리고 Larch 언어 등에 대해서 고찰한다.

2.2.1 소프트웨어 아키텍쳐

1994 년 SEI(Software Engineering Institute)에서 SADG(Software Architecture

Discussion Group)는 소프트웨어 아키텍쳐를 프로그램과 시스템의 컴포넌트, 그

들의 상호관계에 대한 구조 그리고 컴포넌트를 설계하고 개발하기 위한 규칙

과 가이드 라인이라고 정의하고 있다[ Per95, SEI99, Sha95b].

소프트웨어 아키텍쳐(Software Architecture)는 시스템을 구성하는 컴포넌트

와 컴포넌트 사이의 상호작용을 중심으로 분석하고, 기술함으로써 시스템의 구

조적 측면을 명세한다. 소프트웨어 아키텍쳐가 중점을 두고 있는 소프트웨어의

구조적인 측면은 컴포넌트와 그 상호작용에 대한 관점이외에 전체 제어 구조, 통

17

신 프로토콜, 동기화, 자료 접근, 물리적 분산, 성능 등의 문제를 포함하는 포괄

적인 의미이다[Cle94, Gar95, Ros97, Sha95a].

소프트웨어 아키텍쳐는 전체 시스템의 구성을 개발 초기 단계에서 기술함

으로써 설계 단계의 결정을 위한 지침을 제공하고, 개발자들의 시스템 이해를 도

모하고, 시스템 구성에 대한 분석을 가능하게 한다 .

소프트웨어 아키텍쳐에 대한 연구는 컴포넌트 기반 소프트웨어 개발 방법

론(Component based Software Development Methodology)의 등장과 함께 기존의 객체

지향 개발 방법의 설계 과정에서 각 클래스 사이의 연관 관계로 표현되는 것들

에 비해 컴포넌트 기반 소프트웨어 개발에서는 더 다양한 관계 기술 , 즉 각각의

컴포넌트들간에 상호 작용에 대한 프로토콜을 표현하는 방법이 요구된다. 이러

한 요구에 따라 소프트웨어 아키텍쳐는 전체 시스템을 구성하는 컴포넌트와 그

들 사이의 상호작용을 기술함으로써 컴포넌트 기반 소프트웨어 개발에 있어서

전체 시스템 설계에 해당하는 역할을 수행한다 .

소프트웨어 아키텍쳐와 관련한 최근 두 가지 경향은 복잡한 소프트웨어

시스템을 구조화 하기 위해 메소드(method), 기술(description), 패턴(pattern) 그리

고 특징(idioms)을 공유하는 것과 사용 가능한 프레임워크를 제공하기 위한 특

정 영역의 이용 문제에 관한 것이다. 이러한 경향을 일반화하기 위해 소프트웨

어 아키텍쳐는 다음 세 가지 항목에 의해 구분된다[All92, Per95].

첫째, 알고리즘과 데이터 구조의 설계에 대한 전통적인 관심과 대규모

시스템의 구성에 대한 구조적 관심간의 구분이 존재한다.

둘째, 정의-사용 구조(Definition-use Structure)에 기반한 시스템 기술과 컴포

넌트들간 상호작용에 대한 그래프에 기반한 구조적 기술간의 구분이 존재한다.

18

전자는 소스 코드에 기반해서 시스템을 모듈화하고, 후자는 컴포넌트와 커넥터

에 대한 그래프나 구성을 사용하여 시스템을 모듈화한다. 여기서 컴포넌트는

시스템에 대한 응용 단계 처리와 데이터 저장에 대해 정의하며, 커넥터는 이러

한 컴포넌트간 상호작용에 대해 정의한다.

셋째, 객체 지향 설계, 구조적 분석과 같은 소프트웨어 설계 방법과 소프

트웨어 구조간의 구분이 존재한다.

소프트웨어 개발에서 정형화된 소프트웨어 구조를 사용하게 되면 시스템

설계에서 추상화의 고수준(High Level)으로 시스템을 표현함으로써 복잡한 시스

템에 대한 이해를 돕고, 컴포넌트 라이브러리를 통해 다중 레벨에서 재사용이

가능하다. 그리고, 정형화된 소프트웨어 구조 사용으로 인해 시스템의 발전 방

향 예측이 가능하고, 소프트웨어 유지 보수자로 하여금 변화를 보다 쉽게 이해

할 수 있도록 함으로 수정에 대한 비용을 비교적 정확하게 예측할 수 있게 한

다[Abo93, Dea95].

또한, 컴포넌트들간의 상호작용을 위한 연결을 조절함으로써 시스템의

성능과 상호작용 능력을 향상시킬 수 있으며, 시스템의 일관성 검사, 구조적

스타일의 일치, 특정 영역 분석을 위한 고수준의 형식을 제공한다. 마지막으로

시스템 구현 시 소프트웨어 시스템의 기본적인 요구사항과 기대되는 발전 방

향에 대한 시뮬레이션을 통한 요구사항과 발전 범위의 축적을 통해 소프트웨

어 개발에 있어서 위험성을 감소시킨다[Cle94, Gar93].

2.2.2 아키텍쳐 명세 언어

기존의 소프트웨어 아키텍쳐 명세 언어로는 Rapide 와 C2 등이 있고, 두

계층 형태를 통해 언어에 종속적인 형태와 언어에 독립적인 형태를 제공하는

19

Larch 언어 등이 있다.

(1) Rapide

Rapide 는 분산 시스템 구조의 프로토타이핑을 위해 설계된 이벤트 기반

동시 객체 지향 언어(Event-based Concurrent Object-Oriented Language)이다[Bry92].

Rapide 의 주된 설계 기준은 구현 결정이 이루어지기 전에 시뮬레이션을 위해

시스템 구조가 실행 가능한 형태로 표현될 수 있도록 하는 아키텍쳐 구성을

제공한다. 그리고, 분산 행위와 타이밍을 정확하게 찾아내는 실행 모델

(Execution Model)을 채택했다. 또한, 참조 아키텍쳐의 제약 기반 정의와 구조적

표준과의 일치를 위한 시스템 테스팅을 제공하기 위해 정형화된 제약 조건과

매핑을 제공한다.

Rapide 에서 아키텍쳐는 모듈에 대한 명세 집합, 인터페이스간 직접적인

통신을 정의하는 연결 규칙의 집합 그리고 통신 패턴을 정의하는 정형화된 제

약 조건으로 구성된다[Rap94]. 인터페이스는 함수와 같은 다른 모듈 인터페이스

에 제공되는 특징들에 대해 정의하는 것으로써 모듈의 행위에 대한 추상적인

정의가 가능하다. 또한, 인터페이스 행위는 모듈에 의해 수신된 데이터와 생성

된 데이터 간의 관계를 명세한다.

연결은 인터페이스간 데이터에 대한 동기적, 비동기적 통신에 대해 정의

한다. 그리고, 아키텍쳐 제약 조건은 poset(Partially Ordered Set) 모델이라고도 불

리는 이벤트 기반 실행 모델을 가진다. Rapide에서 아키텍쳐는 모듈을 기술하

기 전에 정의하고, 모듈들을 결합하기 위한 프레임워크이며, 모듈간 통신을 제

약한다.

Rapide 는 5 가지의 중요한 부분으로 구성되는데, 컴포넌트 인터페이스를

기술하기 위한 타입 언어, 컴포넌트간 이벤트의 흐름을 기술하기 위한 아키텍

20

쳐 언어, 컴포넌트 행위에 추상적인 제약조건을 기술하기 위한 명세 언어, 실

행 가능한 모듈을 기술하기 위한 실행 가능 언어 그리고 이벤트 패턴을 기술

하기 위한 패턴 언어가 그 구성 요소이다[Luc95, 김 99].

(2) C2

C2 는 메시지 기반 스타일을 사용하여 사용자 인터페이스를 기술하는 언

어이다[Rob95]. C2의 구조적 스타일에서 주된 두 가지 요소는 컴포넌트와 커넥

터이며, 이는 아키텍쳐를 구성하는 요소이기도 하다[All97].

따라서, C2 에서는 사용자 인터페이스 시스템들에서 사용되는 일반적인

컴포넌트와 커넥터의 구성에 대한 제약조건과 커넥션 규칙을 정의함으로써 이

들의 올바른 구성을 제어한다.

컴포넌트는 커넥터를 통해서만 통신할 수 있으며, 하나의 커넥터에 연결

될 수 있는 컴포넌트와 커넥터의 수에는 제한이 없다. C2 에서 컴포넌트간 통

신은 메시지 전달을 통해 이루어지며, 커넥터는 컴포넌트에서 발생한 이벤트를

다른 컴포넌트에 전달한다[Tay96]. 이 때 제약 조건으로 아래 쪽 방향으로는 통

지(notification) 이벤트만을, 위쪽 방향으로는 요구(request) 이벤트만을 전달한다

는 방향성에 제한을 두고 있다.

C2 에서 컴포넌트는 상위 영역과 하위 영역을 가져야 한다. 상위 영역은

반응할 컴포넌트에 대한 통지 메시지의 집합과 아키텍쳐에서 위쪽 방향으로

발생하는 컴포넌트의 요구 메시지 집합을 명세한다. 이와는 반대로 하위 영역

은 반응할 컴포넌트에 대한 요구 메시지의 집합과 아키텍쳐에서 아래쪽 방향

으로 발생하는 컴포넌트의 통지 메시지 집합을 명세한다. 하위 영역 집합의 요

소들은 서로 밀접하게 관련되어 있지만, 상위 영역이 포함하는 두 가지 집합은

서로 어떤 관련을 가질 필요가 없다.

21

또한, 컴포넌트는 인터페이스가 정의된 객체, 객체 주위의 랩퍼(wrapper),

다이얼로그와 제약 조건 관리자 그리고 영역 번역기(Domain Translator)를 포함

한다. [그림 2-2]는 C2 에서의 컴포넌트 구조를 나타내고 있다.

Dialog & Constraints

DomainTranslator

Wrapper

InternalObject

[그림 2-2] C2 컴포넌트의 구조

랩퍼는 객체 인터페이스 루틴에 대한 참조가 호출될 때마다 호출과 컴포

넌트 하위 영역에서 통지 메시지로 어떤 반환값을 구체화하고, 컴포넌트의 아

래쪽 커넥터에 통지 메시지를 보낸다. 따라서, 컴포넌트로부터 발생되는 통지

메시지의 타입은 내부 객체에 대한 인터페이스에 의해 결정된다. 객체에 대한

참조 루틴은 컴포넌트의 다이얼로그 부분에 의해서만 호출될 수 있다.

커넥터는 컴포넌트들을 C2 아키텍쳐로 결합하는데 사용되며, 여러 컴포넌

트와 연결될 수 있을 뿐만 아니라 다른 커넥터와도 연결될 수 있다. 커넥터는

메시지 경로 지정과 이의 전달에 책임이 있다. 또한, 커넥터는 컴포넌트에서

정의된 상위 영역과 하위 영역을 가지며, 이러한 커넥터는 컴포넌트와 연결되

어 있다.

(3) Larch

Larch 언어는 양질의 소프트웨어 유지보수 및 개발을 돕기 위한 명세 언

22

어의 일종으로 두 계층 형태를 통해 언어에 종속적인 형태와 언어에 독립적인

형태를 제공한다[Gut91, Gut93]. 그러나, 컴포넌트는 구현 언어와 무관하게 동일

한 기능을 제공한다. Larch 는 컴포넌트와 각 프로그래밍 언어 사이의 인터페이

스 기술을 위한 Larch 인터페이스 언어(Larch Interface Language)와 언어 독립적인

Larch 공유 언어(Larch Shared Language)의 2 계층(two-tired hierarchy)의 구조를 가진

다.

Larch 인터페이스 언어는 다양한 프로그래밍 언어를 지원하기 위한 것으

로써 현재 C, C++, Modula-3, Ada, CLU, CORBA, ML등의 언어를 지원한다. 또한,

각 프로그램 언어의 특성에 따라 추상 데이터 형(Abstract Data Type)을 표현하기

위한 메커니즘(mechanism)을 제공한다. 인터페이스 명세는 Larch 공유 언어로

작성된 보조적인 명세를 참조한다.

Larch 공유 언어는 특정한 인터페이스나 클래스의 명세에 적당한 특별한

어구들을 정의한다. 공유 언어 명세는 인터페이스 명세에서 나타나는 어구들에

대한 명확한 수학적 정의를 제공한다. Larch 는 이처럼 명세의 기본을 구조화하

는데 공유 언어 계층을 이용하고, 상세한 프로그래밍은 인터페이스 계층으로

분리한다. 그러나, Larch 와 같은 두 계층의 형태는 언어에 독립적이기 때문에

컴포넌트의 특징을 표현하는데 불필요한 요소를 많이 가진다.

기존의 명세 언어는 나름대로의 장점을 갖고 있지만, 많은 경우 정형 명

세에 기반하기 때문에 정형 기법에 관한 지식이 부족한 개발자의 경우 명세에

어려움이 있다. 그리고, 대부분의 명세 언어들은 기능(functionality)에 관한 명세

로 비기능의 명세 지원이 미흡하고, 특정 언어에 종속적이며, 명세되는 시스템

의 관점이 제한적이다.

소프트웨어 개발에 사용되는 정형 명세(Formal Specification)란 컴포넌트의

23

특성을 묘사하기 위해 수학적 이론에 바탕을 둔 기술을 말한다. 정형적 방법은

비정형적 방법과 달리 임기응변 식의 즉흥적인 방법이 아니라 체계적인 방법

으로 컴포넌트를 명세하고 개발하며, 증명하기 위한 틀을 제공한다. 그러나, 이

러한 정형 명세는 이해하기 어렵고, 작성하는 데 많은 노력이 들기 때문에 일

반적으로 적용하기에 어려움이 있다.

또한, 재사용을 고려하지 않았기 때문에 재사용의 지원이 미약하며, 구조

적인 언어로 작성된 함수 단위의 기술을 제공하기 때문에 컴포넌트가 외부와

연결을 제공하는 인터페이스에 의해 기능이 정의되는 특징을 표현하기에 부족

하다.

따라서, 이 논문에서는 이러한 단점을 해결하기 위해 소프트웨어 아키텍

쳐의 개념을 적용하여 재사용을 고려한 XML 기반의 정형적인 컴포넌트 명세

모델을 제안하여 검색이 용이하고, 컴포넌트 개발자들 뿐만 아니라 응용 개발

자들도 명세 질의를 쉽게 작성할 수 있도록 하였다.

또한, 컴포넌트의 특징을 표현하기 위해 언어 종속적인 형태를 제거하고,

언어 독립적인 형태만을 제공할 수 있게 하였다. 기능 명세 부분은 구현 프로

그래밍 언어에 종속되는 경우가 일반적이기 때문에, 이 논문에서는 기능 명세

와 행위 일치 검색을 지원하기 위하여 기존 프로그래밍 언어들을 사용할 수

있도록 정의하였다.

2.3 XML 과 XML 기반 명세

이 절에서는 제안하는 명세 모델에 적용할 XML 을 분석하고, 표준으로

채택된 형태의 XML 명세인 XMI 와 표준 저장소인 MOF 에 대해서 분석한다.

24

2.3.1 XML

XML( eXtensible Markup Language)은 주로 WWW(World Wide Web) 상에서 쉽

고 일관된 방법으로 데이터를 형식화하며, 전송을 위한 구조적 데이터 형식을

제공하는 메타-마크업(meta-markup) 언어이다[Kha97].

특히, XML 은 웹 상에서의 사용에 목적을 두고 설계된 SGML(Standard

Generalized Markup Language)의 부분 집합 형태로 제공된다. 이는 여러 플랫폼

상에서 내용을 좀더 정확하게 선언하고, 의미있는 검색 결과를 얻을 수 있도록

하며, 새로운 웹 기반 데이터를 보여주고 처리하는 응용으로 동작 가능하다.

XML 문서는 DTD(Document Type Definition)와 결합되어 있고, DTD 의 규

칙에 따르면 응용에 적용 가능하다. DTD 는 XML 문서에서 사용할 태그를 정

의하고, 이들이 어떤 순서로 동작하며, 어떤 태그가 다른 태그를 포함하는지를

정의할 수 있다.

DTD 는 XML 문서에서 반드시 필요한 것은 아니지만 문서가 유효한지

확인하기 위해 그리고 XML 프로세서가 설정한 규칙에 따르는지 확인하기 위

해 반드시 포함시켜야 한다. XML 형식은 HTML보다 좀 더 간단한 파싱 규칙

을 가지는데 이는 XML 해석기가 XML 데이터의 의미에 대한 특별한 지식이나

추가적인 설명없이 XML 데이터를 읽고, 표현하는 것을 허용한다.

스키마(schema)는 XML 문서의 규칙에 대한 형식적 명세, 즉 어떤 요소가

문서에서 허용되는가와 어떤 결합에서 허용 되는가를 나타내는 요소의 이름들

이다. 이러한 스키마는 확장이 가능하기 때문에 개발자는 데이터 타입(Data

Type), 상속(inheritance) 그리고 표현 규칙(Representation Rule) 같은 추가적인 정보

를 증가시킬 수 있다. 이것은 이러한 새로운 스키마 언어를 DTD 보다 더욱 강

25

력하게 만든다.

스키마를 사용하면 문서에서 허용되는 요소들과 각 요소 내의 서브 요소

(Sub Element), 속성(attribute), 관계(relationship)를 자세하게 정의할 수 있다. 또한,

XML 은 웹 상에서 쉽고 일관된 방법으로 데이터를 형식화하며, 전송을 위한

구조적 데이터 형식을 제공하고, 다음과 같은 특징이 있다[Inn99].

• XML은 확장이 가능하다.

• 데이터의 구조적 표현을 제공한다.

• 구조적 데이터와 사용자 인터페이스의 분리를 유지한다 .

• XML 데이터는 자신의 구조를 서술할 수 있다.

• 데이터에 유일한 태그를 붙임으로써 기존의 검색 방법보다 검색의 효율을

높일 수 있다.

• XML은 3 계층 구조의 웹 응용 개발에 필요한 기술을 제공함으로써

유연한 웹 응용 개발을 가능하게 한다 .

• XML은 HTTP 를 통한 전달이 가능하기 때문에 웹에 데이터를 전달할 수

있다.

XML 문서를 HTML 과 비교했을 때, 다음과 같은 장점들을 가지고 있다

[Par99]. 첫째, 문서의 구조가 논리적으로 명확하게 되어 있어 문서의 내용 파악

에 있어서 신뢰도와 속도 향상을 가져올 수 있다. 둘째, 문서 자체가 하나의

단위가 아니라 문서를 구성하는 많은 단위들이 존재하므로 다양한 수준에서

검색이 가능하며, 상호 유사한 수준의 문서정보에 쉽게 접근할 수 있다. 셋째,

구조화된 문서의 경우 새로운 정보의 추가나 기존 정보의 수정이 용이하다.

26

XML 에서는 브라우저에서 데이터를 나타내기 위해 XSL(eXtensible Style

Language)과 CSS(Cascading Style Sheets)와 같은 스타일 시트를 사용한다. XML 은

다른 스타일 시트와 응용을 적용하여 데이터를 보여주고 처리하도록 함으로써

표현과 처리로부터 데이터를 구분한다.

2.3.2 XMI 와 MOF

XMI(XML-based Metadata Interchange)는 XML 에 기반한 명세로써 주된 목

적은 OMG(Object Management Group)의 UML(Unified Modeling Language)을 기반으

로 하는 모델링 도구들간에 메타 데이터와 서로 다른 분산 환경에서의 저장소

들간에 메타 데이터의 효율적인 교환이 이루어지도록 하는데 있다[OMG98]. [그

림 2-3]은 XMI 로 통합되어 나타낼 수 있는 OMG 메타 데이터 저장소 아키텍

쳐를 나타낸다.

Tools & Repositories

Repository Common Facility

MOF XMI UML

Object Request Broker(ORB)

Ojbect Services

APIsAPIs

[그림 2-3] OMG 메타 데이터 저장소 아키텍쳐

[그림 2-3]에서 아키텍쳐는 4 개의 계층으로 구성되어 있으며, CORBA 인

터페이스를 사용하여 메타 모델들을 정의하고, 처리하기 위해 MOF(Meta Object

Facility)를 사용하고 있다. 모델들과 메타 모델들을 표현하고 객체 분석과 설계

27

모델의 의미를 기술하는데 UML 표기법을 사용한다. 그리고, 스트림 기반 메타

데이터(Stream based Metadata)의 교환을 위해 XMI 를 사용한다.

XMI 는 XML기반 메타 데이터의 교환을 위해 OMG 의 스트림 기반 모

델 교환 형식을 제시하고 있다. XMI 는 크게 두 가지 주된 요소로 구성된다.

첫째, XML DTD 생성을 위한 XML DTD생성 규칙들이다. XML DTD 는 XMI 문

서들을 위한 문법 명세서와 같으며, 이는 XMI 문서들의 구성과 검증을 위해

XML 도구를 사용할 수 있도록 한다. 둘째, 메타 데이터를 XML 형식으로 인코

딩하기 위한 XML 문서 생성 규칙들이다. 이 생성 규칙들은 XMI 문서들을 디코

딩하여 메타 데이터를 재구성하는데 적용될 수 있다.

XMI 는 모델 정보와 메타 모델 정보를 포함하여 MOF 명세로 표현될 수

있는 모든 종류의 메타 데이터 교환을 제공한다. 그리고, 특정 도구 확장 메타

데이터뿐만 아니라 완전한 모델과 모델의 부분들을 구성하는 메타 데이터 인

코딩도 제공한다. XMI 는 다른 형태의 메타 데이터 교환과 메타 데이터에 대해

불완전한 호환 도구를 사용하는 메타 데이터 교환을 위한 선택적인 지원을 제

공한다.

메타 데이터 표현을 위해 XMI 는 MOF 메타 데이터 교환에 중점을 둔다.

XMI 는 실제적으로 MOF 메타 모델과 XML DTD 간 그리고 MOF 메타 데이터와

XML 문서간의 병렬적인 매핑을 고려한다. MOF 기반 메타 데이터 저장소를 사

용자 관점에서 볼 때 XMI 는 하나의 저장소로부터 다른 저장소로의 메타 데이

터 교환을 위한 새로운 방법이다.

XMI 는 CORBA 인터페이스라기 보다는 전송 형식 자체를 나타내므로 전

송을 위한 ORB(Object Request Broker)연결을 고려할 필요는 없다. 따라서, XMI

는 MOF 의 이용성을 향상시키는 새로운 형태의 메타 데이터 교환을 가능하게

28

한다. 또한, XMI 는 문서 설계를 위해 기존의 XML 규칙들을 따른다. 따라서,

XMI 는 문서의 검증을 허용하는 XML DTD 가 어떻게 생성될 수 있는지를 명

세한다. XMI 는 XMI DTD 의 요소들을 모든 MOF 데이터 타입과 매핑시키지는

않는다. XMI 문서의 사용자나 생성자는 메타 데이터를 위한 MOF 메타 모델에

대한 지식을 필요로 한다.

XMI DTD 는 XMI 문서에 대한 문법 규칙들을 정의하지만, XML DTD는

단지 MOF 메타 모델에 포함된 일관성 규칙들과 구조의 부분 집합만을 표현할

수 있다. 따라서, XMI 문서는 DTD 에 포함되지 않은 문서의 의미적 정확성이나

메타 데이터를 원래의 형태로 재구성하는 정보와 같은 메타 모델에 대한 지식

을 필요로 할 수도 있다. 이러한 메타 모델에 대한 지식은 메타 데이터와 데이

터 타입을 위한 MOF 메타 모델을 교환함으로써 얻을 수 있다.

XMI 문서는 두 부분으로 구성된다. 첫번째 부분은 특정 MOF 메타 모델

과 일치하는 메타 데이터를 포함하고 있고, 두번째 부분은 기본 메타 모델에

의해 기술되지 않은 추가적인 메타 데이터를 포함한다. 두번째 부분의 경우는

다중 섹션을 가지게 되는데, 각각의 섹션은 특정 도구에 의해 생성된 모델 확

장과 일치한다.

이와 같이 XMI 는 UML 로 표기된 형태를 XML 형태의 메타 데이터로

명세하기 위한 것으로써 재사용에 이용되는 컴포넌트들을 XML 형태로 표현하

게 되면 검색이 용이하게 될 수 있다. 그리고, XML에 기반한 컴포넌트 명세를

저장하기 위해서는 XML 로 표현된 컴포넌트들을 저장하고, 관리할 수 있는 컴

포넌트 저장소가 필요하다.

29

2.3.3 XML 명세 저장소

이 절에서는 XML 형태의 컴포넌트 명세를 저장할 수 있는 명세 저장소

가 가져야 할 기능들을 정의하고, 컴포넌트들을 저장할 수 있는 명세 저장소의

종류들을 비교 분석한다.

XML 명세 저장소는 XML 로 표현된 객체들을 저장하고, 관리할 수 있는

특별한 목적의 데이터베이스이다[Bar97, Hog98]. 이는 개발자로 하여금 데이터베

이스 설계와 프로그래밍 대신 비즈니스 로직(Business Logic) 에만 집중할 수 있

도록 허용한다. XML 명세 저장소는 다음과 같은 기본적인 기능을 제공해야 한

다[Bar97, Hog98, Poe97].

파일 시스템에 저장된 XML 파일을 저장소로 읽어들여 저장하거나, 저장

된 XML 명세를 파일 형태로 내보내는 기능과 저장소에 저장된 XML명세들을

태그를 이용하여 검색할 수 있는 질의 인터페이스를 가져야 한다[Poe97]. 이는

명세 저장소에서 특정한 컴포넌트 명세의 검색 방법을 지원해야 함을 의미한

다. 또한, XML 명세 저장소는 생성된 표준 웹 서버로의 인터페이스인 HTTP 와

일반 프로그래밍 언어들과 스크립트 언어들에 대한 인터페이스를 제공할 수

있어야 한다.

그리고, HTTP 를 통해 전송된 XML데이터에 대해 추가적인 프로세스들

을 구현하기 위한 클라이언트 측의 프로그래밍 환경을 제공하여야 하며, XML

저장소는 클라이언트 측에서 사용 가능하여야 한다. 이는 XML 데이터가 로컬

저장소에 중복되는 것을 허용해야 한다는 것을 의미한다.

이러한 기능을 갖는 XML저장소의 구현을 위해서는 운영 체제의 파일

시스템(File System)을 사용하거나, 데이터베이스 관리 시스템(Database Manage-

30

ment System)을 사용할 수 있다[Bar97, Hog98].

(1) 파일 시스템

운영 체제의 파일 시스템을 사용하는 방법은 운영체제의 기본적인 부분

에 대한 기술이 자유롭고, 잘 정의되어 있으며, 모든 시스템에 매우 일관성있

게 사용 가능하다는 장점이 있다. 또한, 파일 시스템을 이용하는 방법은 주로

프로토타이핑에 사용되며, 확장성(scalability)과 수행 능력(performance)과 같은 요

구 사항에 대한 특별한 고려가 없기 때문에 바이트 스트림을 파일로 저장하는

방법은 응용 데이터에 기본적인 일관성을 제공하기 위해 편리하고, 비용이 비

교적 많이 들지 않는 방법이 될 수 있다.

그러나, 파일 시스템 방식으로 XML을 저장하게 되면, 확장성이 결여되

어 XML 의 중요한 링킹 메커니즘을 제공할 수 없으며, 검색을 고려한 경우 파

일에서 확장된 속성들이 요구되는데, 이는 전체 텍스트 검색 엔진과 같은 제 3

의 도구에 의해서만 해결될 수 있다. 또한, XML데이터를 접근하기 위해 파일

을 파징(parsing)해야 하는 서버에서의 병목 현상을 피할 수 없으며, 다중 사용

자 응용을 위한 동시 접근 제어가 어렵다.

기존의 파일 시스템은 XML 응용을 위한 API(Application Programming

Interface)를 정의하지 않는다. 또한, 특정한 보안 모델이 있는 것이 아니라 파일

시스템의 보안 메커니즘에 의지하고 있기 때문에 응용 내에 컴포넌트 기반 보

안 모델이 구현되어야 한다. 그리고, 트랜잭션에 대한 고려와 일관성

(consistency), 무결성(integrity)과 신뢰성(reliability)이 중요하며, 일반적인 파일 시

스템 형태의 저장소는 일관성에 대한 관리를 고려하지 않은 채로 다중 디스크

와 다중 서버에 분산되어 있으므로 이러한 사항들을 전체적으로 수행할 수 없

31

다.

(2) 관계형 데이터베이스 관리 시스템

관계형 데이터베이스 형태의 저장소는 일관성과 무결성 그리고 신뢰성을

제공한다. 관계형 데이터베이스 관리 시스템을 사용하여 구조화된 자료 관리를

위한 저장소를 구현하는데 있어서의 문제점은 링크(link), 가변 길이 필드

(variable length fields), 튜플(tuple), 컨테이너(container) 그리고 다중 값 필드(multi-

value fields) 등으로 표현된 계층적인 데이터들을 표현할 수 있는 데이터 모델이

요구된다는 점이다.

이러한 관계형 데이터베이스 관리 시스템을 사용하면 트랜잭션, 보안, 데

이터베이스 관리의 기능을 제공하므로 구현을 좀 더 쉽게 할 수 있으며, 널리

사용되고 있는 기술이기 때문에 트랜잭션 프로세싱과 같은 응용 분야에 널리

사용되고 있다. 또한, 관계형 데이터베이스 관리 시스템은 기존의 운영체제와

하드웨어 플랫폼 및 개인용 컴퓨터에서 사용 가능하며, SQL(Structured Query

Language)이란 프로그래밍 언어에 의해 표준화 되었다. 관계형 모델은 데이터와

비즈니스 로직의 통합이 가능하며, 현재 많은 안정적인 상용 제품과 도구 그리

고 관련 기술들이 존재하고 있다.

단점으로는 관계형 모델이 가지는 제약으로 링크의 구현이 어려우며, 가

변 길이 필드와 컨테이너 기능, 다중치 필드가 제공되지 않는다는 점이다. 테

이블의 수가 많아지기 때문에 조인 연산과 동시성 제어를 위한 잠금 연산에

의한 성능이 낮아질 수 있다. 또한, 관계형 모델은 고정된 필드와 스키마 구조

때문에 유연성(flexibility)이 낮아지게 되는데, 새로운 스키마나 데이터베이스를

위해서는 DTD 를 새로 정의해야 한다.

32

(3) 객체 지향 데이터베이스 관리 시스템

객체 지향 데이터베이스 관리 시스템은 XML 과 SGML에서 발견되는 계

층 구조와 많은 관계를 위해 적합한 방법을 제공하며, 관계형 데이터베이스 관

리 시스템과 같이 무결성, 일관성 등의 데이터베이스 기능을 제공한다. 또한,

응용의 구현을 위해 객체 지향 프로그래밍 언어에 대한 인터페이스를 제공하

며, 트리 형태의 계층적인 구조와 데이터 탐색을 제공한다. 그리고, 관계형 데

이터 모델의 단점인 링크와 가변 길이 필드, 다중치 필드에 대한 문제를 객체

의 형태로 해결할 수 있다. 데이터에 대한 모든 DTD 들을 제공함으로써 일반

적인 스키마 디자인이 가능하다. 따라서, 하나의 데이터베이스는 좀 더 쉬운

질의와 탐색 그리고 비즈니스 규칙 응용 등을 제공한다.

객체 지향 데이터베이스 관리 시스템을 사용하는 저장소가 XML 형태의

명세 저장소에 가장 적합한 해결책이 될 수 있으나, 현재 표준화된 질의 인터

페이스를 제공하지 않고 프로그래밍 언어로의 매핑만을 제공하기 때문에 일반

사용자들이 프로그래밍 언어를 통해 데이터에 접근하기가 어렵고, 프로그래밍

언어에 의존적인 구현이 될 수 있다. 또한, 안정화 단계에 이른 상용 제품이

충분하지 못하다는 단점이 존재한다.

따라서, 이 논문에서는 XML 기반의 명세를 저장하기 위한 저장소로써

현재 다수의 개발자들이 이용하며, 표준화된 질의 인터페이스를 갖는 관계형

데이터베이스 관리 시스템을 사용한다. 관계형 데이터베이스 관리 시스템이 갖

는 문제점들은 현재 데이터베이스 관리 시스템에서 제공되거나, 데이터 모델의

정규화 과정을 통해 해결이 가능하다.

33

2.4 기존의 컴포넌트 검색 방법

이 절에서는 기존의 컴포넌트 검색 방법으로써 시그니쳐 일치에 의한 검

색, 명세서 일치에 의한 검색과 행위 샘플링에 의한 검색 방법을 분석하고, 검

색 효율의 평가 기준에 대해서 분석한다.

2.4.1 시그니쳐 일치에 의한 검색

시그니쳐 일치 검색 방법은 컴포넌트로부터 얻을 수 있는 함수의 파라미

터 타입이나 인터페이스와 같은 시그니쳐 정보를 이용하여 질의 시그니쳐와

일치하는 컴포넌트를 결정하는 방법이다[Zar93, Zar95a, Zar96]. 즉, 함수의 기능

적인 측면보다는 구조적인 측면에서 컴포넌트를 검색하는 방법이다.

시그니쳐 일치 방법은 함수와 모듈로 구성된 컴포넌트를 고려하여 함수

일치(Function Match) 방법과 모듈 일치(Module Match) 방법을 제공한다. 두 가지

일치 방법은 완전 일치(Exact Match) 방법과 이완 일치(Relaxed Match) 방법을 고

려하고 있다. 이완 일치는 소프트웨어 개발자의 질의와 유사한 컴포넌트들을

검색한다[Zar93, Zar95a, Zar96]. 함수 일치는 시그니쳐 정보인 함수의 타입을 이

용하여 질의와 일치하는 함수를 검색한다[Zar96].

컴포넌트 저장소의 함수 타입이 τl 이고, 질의의 타입이 τq 일 때, 일반적인

함수 일치는 [정의 1]과 같이 정의하고 있다.

[정의 1] 일반적인 함수 일치

( ) ( ) ( )qqllqlql RthatsuchandM

BooleanQueryTypeeLibraryTypM

ττττ ΤΤΤΤ∃=

→

,

,:

34

R 은 타입들 사이에 관련성을 나타내고, Τl 과 Τq 는 저장소의 함수 타입과

질의 타입에 적용된 변환을 나타낸다. [표 2-1]은 타입들 사이의 관련성 R 의 인

스턴스 방법과 일반적인 함수 일치 정의에 대해 Tl 과 Tq에 대한 변형의 종류

와 일치 방법들이다. [표 2-1]에서 Id 는 동일 함수(Identity Function), V 는 변수 이

름 변경(Variable Renaming), Tσ는 튜플 치환(Tuple Substitution), UC 는 uncurry 를 나

타낸다.

[표 2-1] 일반 함수 일치의 인스턴스

Match R Tl Tq

ExactUncurryReorder

GeneralizedSpecialized

=T

Match E

Match E

≥

≤

VUCTσ

IdId

IdUCIdIdId

완전 일치는 저장소에 있는 컴포넌트 함수들의 타입과 질의에서 주어진

함수 타입이 정확하게 일치할 때 함수들을 검색할 수 있는 방법이다. 그러나,

저장소에 있는 컴포넌트와 유사한 타입을 가진 함수를 검색할 수 없는 단점이

있다. 그러므로, 완전 일치를 사용하기 위해서 사용자는 저장소 아키텍쳐나 사

용 언어를 잘 알고 있어야 한다[Zar95a].

일반적으로 컴포넌트 검색 방법들은 질의와 정확하게 일치하는 컴포넌트

를 검색하기 어렵기 때문에 많은 검색 방법들이 이완 일치 방법에 대해 정의

하고 있다. 시그니쳐 일치 방법에서도 변형 이완 일치(Transformation Relaxed

Match)와 부분 이완 일치(Partial Relaxed Match)를 정의하고 있다[Zar93, Zar95a]. 변

형 이완 일치는 일치를 수행하기 위해 함수에 대한 타입 표현을 변형하는 것

이다. 변형 이완 일치의 예는 튜플내에 타입의 순서를 변경하거나 함수에 포함

된 파라미터의 순서를 변경하여 일치를 수행하는 순서 변경 이완 일치 방법

35

(Reordering Relaxed Match)과 다수의 파라미터를 가지고 있는 함수들의 curried 나

uncurried 표현을 변경하는 방법들이 있다.

부분 이완 일치는 저장소 타입과 질의 타입 사이의 관련성을 변경하여

일치를 수행하는 방법이다. 부분 이완 일치 방법에는 일반화 일치(Generalized

Match) 방법과 특수화 일치(Specialized Match) 방법이 있다. 일반화 일치 방법은

질의의 타입이 컴포넌트 타입에 적용하여 연속적인 타입 대체의 결과이면 컴

포넌트 타입은 질의 타입보다 일반적이라고 할 수 있다. 즉, 저장소 타입이 질

의 타입을 포함하는 관계일 때, 질의와 유사한 컴포넌트로 간주한다. 특수화

일치는 일반화 일치의 반대 개념으로써 일반화 일치의 타입 순서를 교환하여

정의된다.

시그니쳐 일치 방법은 완전 일치 방법과 이완 일치 방법을 제공함으로써

개발자의 요구 사항과 일치하는 컴포넌트들을 검색할 수 있는 방법이다. 그러

나, 질의와 일치하는 컴포넌트를 검색하기 위한 시간 비용이 크고, 정확성에

비해 재현율이 떨어지는 단점이 있다.

2.4.2 명세서 일치에 의한 검색

명세서 일치 검색 방법은 두 개의 컴포넌트 명세서를 비교하기 위한 방

법이다[Zar95b, Zar96, Zar97]. 소프트웨어 재사용에서 명세서 일치 방법은 하나의

컴포넌트가 다른 컴포넌트에 대체될 수 있는지를 결정한다. 또한, 컴포넌트의

명세서를 비교함으로써 컴포넌트의 기능적인 측면에서 개발자의 요구사항과

일치하는지를 결정한다.

두 개의 컴포넌트가 일치하는지를 결정하기 위해 선조건 술어

(Precondition Predicate)와 후조건 술어(Postcondition Predicate)를 이용하여 컴포넌트

36

의 행위를 기술하는 정형 명세서(Formal Specification)를 작성한다. 이를 통해 이

론 판명자(Theory Prover)는 컴포넌트가 일치하는지를 결정한다. 명세서 일치 방

법은 일치 조건에 따라 선조건/후조건 일치(Pre/post Match) 방법과 술어 일치

(Predicate Match) 방법을 제공하고 있다[Zar95b, Zar96, Zar97]. 선조건/후조건 일치

는 각 컴포넌트의 선조건과 후조건을 비교하여 컴포넌트를 검색한다. 일반적인

선조건/후조건 일치 술어를 [정의 2]와 같이 정의하고 있다.

[정의 2] 일반적인 선조건/후조건 일치

)'()(),(/ post2pre1prepostpre QRSSRQQSMatch ∧=

S 는 컴포넌트의 정형 명세서를 나타내고, Q 는 질의 명세서를 나타내며,

R1 과 R2 는 컴포넌트 명세서와 질의 명세서의 선조건과 후조건 간의 관련성을

나타낸다. 이 관련성에 따라 [표 2-2]와 같이 선조건/후조건 일치를 분류한다.

[표 2-2] 선조건/후조건 일치

Match R1 R2 S′Exact Pre/Post ⇔ ⇔ Spost

Plug-in ⇒ ⇒ Spost

Plug-in Post ⇒ Spost

Guarded Plug-in ⇒ ⇒ Spre ∧ Spost

Guarded post ⇒ Spre ∧ Spost

완전 선조건/후조건(Exact Pre/Post Match) 일치 방법은 두 개의 함수 명세

서는 선조건이 일치하고, 후조건이 일치한다는 의미이다. 따라서, 두 개의 컴포

넌트는 상호 교환이 가능하다. 플러그-인 일치(Plug-in Match) 방법은 질의에서

요구하는 선조건이 명세서의 선조건에 포함되고, 명세서의 후조건이 질의의 후

조건에 포함된 경우의 일치 방법이다. 즉, 명세서가 질의 내에 포함된 형태의

37

일치 방법이다.

플러그-인 포스트 일치(Plug-in Post Mqtch) 방법은 함수의 결과에 관심이

있을 때 유용한 일치 방법이다. 즉, 함수의 수행 조건보다는 수행 결과만이 필

요한 경우 사용하는 일치 방법이다 . 경계 플러그-인 일치(Guarded plug-in Match)

방법은 후조건 관련성에 가설로써 Spre를 추가한 형태이다. 플러그-인 일치 방

법과 비슷하지만, S′ = Spost 가 아니라 S′ = Spre ∧ Spost 를 사용한다.

경계 포스트 일치(Guarded post Match) 방법은 플러그-인 포스트 일치 방법

과 마찬가지로 수행 조건보다는 후조건 관련성에 가설로써 Spre 를 추가한 형태

이다. 술어 일치의 일반적인 형태를 [정의 3]과 같이 정의하고 있다[Zar97].

[정의 3] 술어 일치

predpredpred QRSQSMatch =),(

관련성 R 은 동등 관계(⇔), 포함(⇒), 역포함(⇐) 관계로 나타낸다. 관련성

R 에 따라 완전 술어 일치(Exact Predicate Match), 일반화 술어 일치(Generalized

Predicate Match), 특수화 술어 일치(Specialized Predicate Match)로 분류한다. [표 2-3]

은 관련성 R 에 따라 술어 일치를 분류한 것이다.

[표 2-3] 술어 일치의 분류

Match RExact Predicate ⇔

Generalized ⇒

Specialized ⇐

완전 술어 일치 방법은 명세서의 술어와 질의의 술어가 동등 관계를 나

타낸다는 의미이다. 그리고, 일반화 술어 일치 방법은 명세서의 술어는 질의

38

명세서의 조건하에서 정상적으로 동작하지만 질의의 술어는 명세서의 조건하

에서 동작하지 않는 것을 검색하는 일치 방법이며, 특수화 술어 일치 방법은

일반화 술어 일치 방법의 역이다.

명세서 일치 방법은 컴포넌트 명세서를 비교하여 일치 여부를 결정하기

때문에 질의 작성이 어렵고, 일치를 결정하는 자동화된 이론 판명자가 있어야

하기 때문에 검색 시간과 비용이 높다는 단점이 있다. 그러나, 시그니쳐 일치

방법에 의해 검색될 수 없는 컴포넌트를 검색할 수 있다.

2.4.3 행위 샘플링에 의한 검색

행위 샘플링 검색 방법은 소프트웨어 저장소로부터 자동화된 방법에 의

해 재사용 가능한 컴포넌트를 검색하기 위해서 제안되었다[Pod92, Pod93]. 개발

자는 루틴에 대한 파라미터의 수, 파라미터 타입, 입력과 출력 모드를 규정한

다. 이와 같은 속성들에 대한 개발자의 명세서를 대상 인터페이스 명세서

(Target Interface Specification)라 하고, 대상 인터페이스 명세서와 호환되는 인터페

이스를 가진 저장소 루틴을 후보 루틴(Candidate Routine)이라 한다[Atk94, Atk97].

기본적인 행위 샘플링은 저장소 루틴을 검색자가 제공하는 연산 입력

(Operational Input)의 샘플 상에 실행시키고, 검색자에 의해 제공된 출력과 루틴

의 출력을 비교함으로써 연관된 루틴을 확인한다[Pod93, Pod93]. 행위 샘플링의

정확성은 입력 샘플의 크기에 따라 증가되지만 샘플의 크기에 따라 비용과 시

간이 증가되고, 효율성이 떨어지게 된다[Pod93]. 따라서, 행위 샘플링의 정확성

을 향상시키기 위해서 샘플의 크기를 최소화할 수 있는 방법이 고려되어야 한

다[Pod93, Hal93].

또한, 재사용 요소인 설계, 테스트 계획 등과 같은 비 실행적인 요소들에

39

대해서는 이 방법을 적용할 수 없으며, 자동화 방법의 구현이 어렵다[Hal93].

그러나, 검색 방법이 자동화로 이루어지기 때문에 검색 시간을 줄일 수 있으며,

개발자가 입력 샘플과 출력 샘플을 직접 설정할 수 있다면 컴포넌트 검색의

재현율과 정확성을 향상시킬 수 있다[Hal93, Mil97].

따라서, 이 논문에서는 이와 같은 기존의 검색 방법들에 대한 문제점을

해결하기 위해 재사용을 위한 컴포넌트 검색을 소프트웨어 아키텍쳐 개념을

적용하여 아키텍쳐에 기반한 컴포넌트를 검색할 수 있는 검색 방법을 제안하

였다. 이는 기존의 검색 방법에 대한 단점들을 해결할 수 있으며, 컴포넌트 검

색의 재현율과 정확성을 향상시킬 수 있다.

2.4.4 검색 효율의 평가 기준

최근에 소프트웨어 컴포넌트들을 새로운 소프트웨어 개발에 사용하기 위

해서 많은 컴포넌트 검색 방법들이 제안되었다. 이와 같은 방법들은 일반적으

로 다음과 같은 평가 기준들을 이용하여 검색 방법의 검색 효율을 평가한다

[Maa91, Mil94, Mil97, Pen97, 권 99, 이 2000].

• 재현율(recall) : 저장소에 저장된 모든 관련 컴포넌트들 중에 사용자의

요구 사항과 관련된 컴포넌트들의 검색 비율을 나타낸다.

• 정확성(precision) : 검색된 모든 컴포넌트들 중에서 사용자의 요구 사항을

만족하는 컴포넌트들의 비율을 나타낸다.

• 시간 복잡성(time complexity) : 질의와 컴포넌트를 일치시키기 위해

요구되는 연산 단계의 수를 나타낸다. 시간 복잡성은 n 이 질의의 크기일

때, O(n)으로 측정된다.

40

• 자동화(automation) : 검색 방법을 자동화할 수 있는지를 나타낸다.

재현율과 정확성은 일반적으로 반비례 형태로 나타난다[Mil97]. 컴포넌트

저장소에서 개발자의 요구 사항에 적합한 컴포넌트를 검색할 때, 개발자가 요

구하는 관련 컴포넌트들이 모두 검색되고, 검색된 컴포넌트들이 모두 관련 컴

포넌트이면 가장 이상적인 검색 방법이라 할 수 있다. 그러나, 이와 같은 검색

방법을 구현하는 것은 어렵다. 따라서, 재현율과 정확성을 최적화할 수 있는

방법이 고려되어야 한다[Mil97, Pen97, Pen98].

시간 복잡성은 질의의 크기에 따라 시간 비용을 측정하기 때문에, 질의

작성을 최소화하여야 한다. 그러나, 질의 작성이 너무 간단하면 검색의 재현율

과 정확성이 낮아지는 단점이 있다[Mil97]. 따라서, 검색 방법들은 시간 비용을

최소화하고, 재현율과 정확성을 최적화할 수 있도록 하여야 한다. [표 2-4]는 검

색 효율 측정 기준에 의해 기존의 컴포넌트 검색 방법들을 상대적으로 비교한

것이다.

[표 2-4] 기존 컴포넌트 검색 방법들의 비교

재현율 정확성시간

복잡성자동화 비고

시그니쳐

일치낮음 높음 높음 가능

재현율을 높이기 위해서는 시간

비용이 크다.명세서

일치높음 높음 높음 어렵다

질의 작성과 이론 판명자의 구현

이 어렵고, 검색 비용이 높다.

행위

일치높음 높음 낮음 어렵다

재현율과 정확성이 입력 샘플의

크기에 의존되며, 비실행적 요소

에 대해서는 적용이 불가능하다.

41

제 3 장 XML 기반 명세 모델과

아키텍쳐 기반 검색 모델 제안

이 장에서는 개발자의 요구 사항에 부합되는 컴포넌트를 검색하기 위한

XML 기반의 컴포넌트 명세 모델(Component Specification Model)을 제안하고, 컴

포넌트 검색을 고려하여 XML 기반의 명세 모델을 이용하는 아키텍쳐에 기반

한 컴포넌트 검색 모델(Component Retrieval Model)을 제안한다.

3.1 컴포넌트 검색 이론

이 절에서는 컴포넌트 검색에 사용되기 위한 명세 요소들을 정의하고,

이 논문에 도입된 아키텍쳐에 기반한 검색에 사용되는 파라미터의 방향성을

고려한 검색의 요구 사항들을 정의하여 방향성을 고려한 검색 이론(Retrieval

Theory)을 제안한다.

3.1.1 검색을 고려한 명세 요소

기존의 검색 방법 중 대표적으로 사용되는 시그니쳐 일치 방법과 명세서

일치 방법, 행위 샘플링 방법에서는 컴포넌트 명세의 특정한 요소들을 이용하

여 검색을 수행하게 된다. 시그니쳐 일치에 의한 검색에서는 함수의 파라미터

타입이나 인터페이스와 같은 시그니쳐 정보를 이용하게 되며, 이러한 정보들은

각 검색 방법에 의해 위치가 변경되거나, 자신을 포함하는 데이터 형식으로 대

치될 수 있다.

42

명세서 일치에 의한 검색 방법에서는 기술된 일치 술어에 의해 일치를

결정하게 되는데, 선조건과 후조건 술어 그리고 정형 명세서를 사용하게 된다.

행위 샘플링을 이용한 검색 방법에서는 저장소에 저장된 실제 컴포넌트를 실

행시키거나, 정형 명세서를 이용한 모의 실행을 통해 질의에서 주어지는 입력

에 해당하는 출력을 만족하는가를 검색하게 된다. 이러한 검색 방법들에 의해

컴포넌트 검색을 수행하는 경우, 대부분의 컴포넌트 명세에서는 재사용성이 고

려되지 않았기 때문에 검색에 적용하는데 어려움이 많았다.

컴포넌트 기반 소프트웨어 공학의 가장 큰 목적은 기존 객체 지향 기술

이 해결하지 못한 재사용성에 있다. 재사용성을 높이기 위해서는 컴포넌트 명

세가 재사용에 기반을 두고 정의되어야 한다. 재사용성에 기반을 두고 컴포넌

트를 명세하기 위한 명세 모델을 정의하기 위해서는 가장 먼저 명세를 위해

필요한 요소의 정의가 필요하다. 따라서, 이 논문에서는 컴포넌트를 명세하기

위해 필요한 요소를 [표 3-1]과 같이 정의하였다.

[표 3-1] 컴포넌트 명세 정의에 필요한 요소

요 소 의 미

Component_name 정의된 컴포넌트 이름

Description 컴포넌트 기능을 자연어로 기술

Uses 컴포넌트에서 사용되는 추상형 데이터 타입

Sig_name 컴포넌트 내의 시그니쳐명(시그니쳐 명세)

Direction 입출력 파라미터에 대한 방향성

Param_name 메소드에 선언된 파라미터 이름

Param_type 메소드의 파라미터 타입

Interface_name 컴포넌트 내의 인터페이스명

Modifies 메소드 수행시 값이 변하는 변수명

Ensures 메소드 기능의 명세(핵심 로직 기술)

In_message 컴포넌트에서 처리하는 메시지

Out_message 컴포넌트에 요청하는 메시지

43

3.1.2 방향성을 고려한 검색 이론

소프트웨어 개발을 위한 아키텍쳐 명세는 구조적인 재사용을 목적으로

하고 있으므로 아키텍쳐의 동등에 관한 연구가 필요하며, 이를 위해 검색에 적

용할 방향성을 고려한 검색 이론을 제안한다.

이 논문에서는 컴포넌트들 간의 관련성을 표현하기 위해 컴포넌트들이

다른 컴포넌트에게 발생시키는 커넥터인 메시지를 사용한다. 컴포넌트들 사이

에서 발생되는 메시지들을 이용하여 컴포넌트를 식별하기 위해서는 메시지의

유사성과 연산에 대한 정의가 필요하다. 따라서, 이러한 정의들을 다음과 같이

제안하였다.

[정의 4] 완전 동등

컴포넌트들이 다른 컴포넌트에게 발생시키는 커넥터인 메시지 im와

jm 가

다음 조건을 만족할 때 이를 완전 동등(Exact Equivalence)이라 한다.

)()()(

).().()(

).().()(

)()()(

ji

kjki

kjki

ji

mActmActiv

parametermTypeparamtermTypeiii

parametermCountparamtermCountii

mNamemNamei

==

==

==

==

완전동등은 ji mm e== 로 표기한다. 단, 1 ≤ i, j, k ≤ n 이며, Name 은 메소

드의 이름이고, Count 는 파라미터의 개수를 세는 메소드, Type은 파라미터의

자료형을 확인하는 메소드, Act 는 메시지에 대한 동작을 의미한다.

[정의 4]는 이 논문에서 제안한 메시지가 모든 조건 아래에서 완전히 일

치하는 완전 동등을 정의하고 있다. [정의 4]의 (i)은 메시지 im 와

jm 의 메소드

44

명이 같은 경우이고, (ii)는 메시지 im 와

jm 의 파라미터 개수가 같은 경우이다.

그리고, (iii)은 메시지 im 와

jm 의 파라미터 자료형이 같은 경우이며, (iv)는 메시

지 im 와

jm 의 행위 결과가 같은 경우이다.

[정리 1] 동등의 특성

kikjjikji

ijjiji

jiji

mmmmmmmmmmessageiii

mmmmmmmessageii

mmmmmessagei

==→==∧==∀

==→==∀

==∀

)(),,()(

),()(

),()(

메시지의 동등은 [정리 1]의 (i)과 같이 ‘==’로 표기하며, 두 메시지가 동

일한 메시지임을 나타낸다. [정리 1]의 (ii)는 메시지 동등의 대칭성(symmetry)을

표현하고 있다. 그리고, (iii)은 메시지 im 와

jm 가 동등하고, 메시지 jm 와

km 가

동등하면 메시지 im 와

km 는 동등하다는 이행성(transitivity)의 특징을 표현한다.

[정의 5] 강한 동등

메시지 im 와

jm 가 다음 조건을 만족할 때 이를 강한 동등(Strong

Equivalence)이라 한다.

)()()(

).().()(

).().()(

ji

kjki

kjki

mActmActiii

parametermTypeparametermTypeii

parametermCountparametermCounti

==

==

==

강한 동등은 jstri mm == 로 표기하며, 기능적인 완전 동등을 의미한다.

[정의 5]의 (i)은 메시지 im 와

jm 의 파라미터 개수가 같은 경우이며, (ii)는 메시

지 im 와

jm 의 파라미터 자료형이 같은 경우이며, (iii)은 메시지 im 와

jm 의 행위

결과가 같은 경우이다.

45

[정의 6] 시그니쳐 동등

메시지 im 와

jm 가 다음 조건을 만족할 때 이를 시그니쳐 동등(Signature

Equivalence)이라 한다.

).().()(

).().()(

kjki

kjki

parametermTypeparametermTypeii

parametermCountparametermCounti

==

==

시그니쳐 동등은 jsigi mm == 로 표기한다. [정의 6]의 (i)은 메시지 im 와

jm 의 파라미터 개수가 같은 경우이며, (ii)는 메시지 im 와

jm 의 파라미터 자료형

이 같은 경우이다.

[정의 7] 구조 동등

메시지 im 와

jm 가 다음 조건을 만족할 때 이를 구조 동등(Structure

Equivalence)이라고 한다.

)).(()).(()(

).().()(

kjki

kjki

parametermTypereorderparametermTypereorderii

parametermCountparametermCounti

==

==

구조 동등은 jstructi mm == 로 표기한다. [정의 7]의 (i)은 메시지 im 와

jm 의

파라미터 개수가 같은 경우이며, (ii)는 메시지 im 와

jm 의 파라미터 자료형을 재

배열할 경우 같게 되는 경우이다.

[정의 8] 시간 동등

메시지 im 와

jm 가 다음 조건을 만족할 때 이를 시간 동등(Time

Equivalence)이라고 한다.

starttimemstarttimem ji .. =

46

시간 동등은 jti mm == 로 표기하며, [정의 8]은 메시지 im 와

jm 에서 보내

는 메시지 전송 시간이 같은 경우이다.

[정리 2] 시간 순서의 특성

ktiktjjtikji

jtiitjjtiji

jtiji

mmmmmmmmmmessageiii

mmmmmmmmmessageii

mmmmmessagei

≤→≤∧≤∀

==→≤∧≤∀

≤∀

))(,,()(

))(,()(

),()(

[정리 2]는 메시지의 시간 순서에 관한 정리이다. [정리 2]의 (i)은 메시지

시간 순서의 표현이고, (ii)는 메시지 시간 동등의 특성을 표현하고 있다. 그리고,

(iii)은 메시지 시간 순서의 이행성을 표현하고 있다.

이 논문에서는 위와 같이 제안된 정의들을 적용하여 소프트웨어 개발을

위해 재사용에 이용할 수 있는 검색을 고려한 아키텍쳐를 명세할 수 있는 명

세 모델을 제안하여 개발자들의 요구에 부합되는 컴포넌트들을 효율적으로 검

색할 수 있도록 하였다.

3.2 아키텍쳐 명세 모델

컴포넌트 기반 소프트웨어 개발에서 컴포넌트 단위의 명세는 컴포넌트

기능을 명세함으로써 블랙 박스 재사용(Black Box Reuse)을 지원할 수 있게 하고,

아키텍쳐 명세는 구조적인 재사용, 즉 화이트 박스 재사용(White Box Reuse)을

지원한다.

소프트웨어 개발을 위한 아키텍쳐는 전체 시스템을 컴포넌트들 간의 상

호작용과 연결을 관할하는 커넥터(connector)를 중심으로 분석하고, 기술함으로

47

써 시스템의 구조를 명세한다.

이 논문은 이러한 아키텍쳐도 하나의 컴포넌트라는 관점으로 명세에 접

근하며, 컴포넌트와 컴포넌트 간의 관련성을 컴포넌트 간에 주고받는 메시지로

정의하여 XML 기반의 아키텍쳐 명세 모델을 제안한다. 재사용을 고려한 아키

텍쳐 명세를 위해서는 아키텍쳐를 구성하는 컴포넌트 명세(Component

Specification)와 컴포넌트 간의 관련성을 표현하는 커넥터의 명세(Connector

Specification)가 요구된다.

3.2.1 컴포넌트의 명세

이 논문에서 제안하는 컴포넌트는 크게 임의의 컴포넌트나 복합 컴포넌

트로 대치될 수 있는 가변 컴포넌트와 필요한 기능을 가지는 단순 컴포넌트로

구분하여 컴포넌트 명세에 적용한다.

(1) 가변 컴포넌트

가변 컴포넌트(Variable Component)는 일반적으로 요구에 정확하게 일치하

는 기능을 갖는 컴포넌트는 아니지만 적용 가능한 컴포넌트 명세에 사용되며,

프로그램상의 변수 역할을 한다. 이러한 가변 컴포넌트는 패턴과 아키텍쳐 기

술을 위해 사용된다. 기술한 패턴이나 아키텍쳐에서 가변 컴포넌트는 임의의

컴포넌트로 대치되거나 복합 컴포넌트로 대치될 수 있다.

따라서, 가변 컴포넌트를 표현하기 위해서 컴포넌트 이름이 요구된다. 가

변 컴포넌트는 이후의 컴포넌트 검색에 활용되며, 검색이 수행된 후 특정한 컴

포넌트나 복합 컴포넌트로 대치된다. 가변 컴포넌트는 <type> 태그에 variable

이라고 표기하여 정의한다. 가변 컴포넌트의 표기는 [리스트 3-1]과 같다.

48

[리스트 3-1] 가변 컴포넌트 표기

<component>

<type> variable </type>

<name> 가변 컴포넌트 이름 </name>

</component>

(2) 단순 컴포넌트

단순 컴포넌트(Simple Component)는 패턴의 명세와 아키텍쳐의 명세에서

특정 컴포넌트에 의해 기능을 가지는 경우 필요한 기능을 지니는 컴포넌트 명

세에 사용한다. 따라서, 단순 컴포넌트는 가변 컴포넌트와는 달리 세부적인 컴

포넌트 명세가 필요한 컴포넌트이다.

단순 컴포넌트에는 이후에 정의할 컴포넌트 명세에 의한 메시지와 인터

페이스의 명세가 포함될 수 있기 때문이다. 그러나, 단순히 아키텍쳐 명세를

위한 것이라면 해당되는 컴포넌트가 컴포넌트 저장소의 특정 컴포넌트라는 것

만을 명세할 수도 있다.

이러한 세부적인 명세를 위해 컴포넌트 명세의 내부에 직접 명세를 하는

방법과 컴포넌트 명세 저장소의 명세를 지정하여 사용하는 방법이 있다. 단순

컴포넌트는 필요한 기능을 지니는 컴포넌트 명세에 사용되며, [리스트 3-2]는 단

순 컴포넌트의 표기를 나타낸 것이다.

[리스트 3-2] 단순 컴포넌트 표기

(a)

<component>

<type> simple </type>

<name> 단순 컴포넌트 이름 </name>

컴포넌트 명세 파트

</component>

49

(b)

<component>

<type> simple </type>

<uses> 컴포넌트 이름 </uses>

</component>

단순 컴포넌트의 표기에는 두 가지 표기법이 있다. [리스트 3-2]의 (a)는

컴포넌트 기능 명세를 직접하는 방법이고, 단순 컴포넌트의 인터페이스와 메시

지 명세를 컴포넌트 명세 저장소에 저장된 명세를 참조할 때 [리스트 3-2]의

(b)와 같이 명세한다.

(3) 복합 컴포넌트

복합 컴포넌트(Composite Component)는 단순 컴포넌트와는 달리 소프트웨

어의 설계 패턴(Design Pattern)이나 아키텍쳐와 동일한 개념으로 정의되므로 하

나 이상의 컴포넌트와 커넥터의 조합으로 구성된다. 복합 컴포넌트는 제안하는

명세 모델에서 아키텍쳐 명세와 동일하게 정의된다.

복합 컴포넌트 명세를 위해서는 일반적인 단순 컴포넌트 명세와 컴포넌

트 검색의 경우 가변 컴포넌트 명세 그리고 커넥터 명세를 포함한다. 저장을

위한 아키텍쳐 명세의 경우 가변 컴포넌트가 존재해서는 안 되며, 가변 컴포넌

트는 아키텍쳐 검색을 위한 목적으로만 사용된다.

[그림 3-1]은 이러한 컴포넌트들을 명세하기 위해 정의된 속성들로 구성

된 컴포넌트 클래스 다이어그램(Component Class Diagram)을 나타낸 것이다. 각

각의 컴포넌트 클래스가 존재하며, 모든 속성들을 컴포넌트 클래스로부터 상속

받는 클래스로 표현한다. 각각의 컴포넌트는 이름과 타입 정보 그리고 하나의

컴포넌트가 발생시키는 메시지인 인터페이스의 리스트를 나타내는 int_list 와

받아들일 수 있는 메시지의 리스트를 나타내는 msg_list 에 대한 정보를 가진다.

50

이러한 인터페이스와 메시지에 대한 세부적인 정보를 Interface 와 Message라는

클래스로 유지하게 되는데, 이러한 클래스들은 컴포넌트 클래스와 포함관계로

표현된다.

+name+type+int_list+msg_list

Component+name+type-uses+int_list+msg_list

Composite+name+type+int_list+msg_list

Variable

+name+type-uses+int_list+msg_list

Simple

+name+signature

Interface+name+signature

Message

+name+return_type+param_list

Signature

inherit

inherit

inherit

0..n0..n

11

+name+type+direction

Parameter

0..n

[그림 3-1] 컴포넌트 명세를 위한 클래스 다이어그램

Interface 와 Message클래스는 이름과 반환되는 값에 대한 정보와 송수신

메시지들의 파라미터 정보를 가지고 있는데, 이러한 정보는 Signature 클래스에

의해 하나의 클래스로 유지된다. 또한, 파라미터 정보는 Parameter 클래스에 표

51

현되는데, 이와 같이 컴포넌트에 대한 정보를 개개의 세부적인 클래스로 표현

함으로 검색의 효율이 향상될 수 있다.

3.2.2 커넥터의 명세

이 절에서는 소프트웨어 개발을 위해 아키텍쳐를 구성하는 컴포넌트와

컴포넌트들 간의 관련성을 나타내는 커넥터의 명세를 제안한다.

커넥터는 컴포넌트들 간의 관련성을 표현하는 컴포넌트들 간에 발생될

수 있는 메시지를 의미하며, 커넥터의 명세에는 가변 커넥터와 단순 커넥터로

분류하여 명세하였다. 그리고, 각 커넥터는 입력, 출력, 입출력과 같은 방향성

을 지니며, 커넥터의 방향성에 따라 단방향 커넥터, 양방향 커넥터로 분류한다.

(1) 가변 커넥터

가변 커넥터(Variable Connector)는 가변 컴포넌트로부터 발생되는 메시지

이다. 가변 컴포넌트로부터 발생되는 메시지는 가변 커넥터로 정의하여야 하며,

컴포넌트 명세에서와 마찬가지로 검색을 위해 사용될 수 있다. 가변 커넥터는

구조적인 재사용을 위한 요소이다.

가변 커넥터의 표기는 메시지가 발생하는 컴포넌트와 발생한 메시지를

처리하는 컴포넌트의 이름, 커넥터의 이름을 기본값으로 가진다. 가변 커넥터

는 메시지를 발생시키는 컴포넌트나 메시지를 처리할 컴포넌트를 명세하며, 메

시지를 발생시키는 컴포넌트는 <src> 태그를 사용하고, 메시지를 받아 처리하

는 컴포넌트는 <dest> 태그를 사용하여 명세한다.

또한, 컴포넌트 명세에서와 마찬가지로, 시그니쳐 정보를 이용하게 되는

데, <signature> 태그를 이용하여 메시지의 반환값과 파라미터 정보들을 결정한

52

다. 메시지의 출력 타입은 양방향 메시지에서 사용된다. [리스트 3-3]은 가변 커

넥터의 표기를 나타낸 것이다.

[리스트 3-3] 가변 커넥터 표기

<connector>

<type> Variable </type>

<name></name><direct> </direct>

<signature><return_type> </return_type><name> </name>

<param_list><num_of_param> </num_of_param>

<parameter><type> </type><name> </name><direct> </direct></parameter>

</param_list>

</signature>

<src> </src><dest> </dest>

</connector>

(2) 단순 커넥터

단순 커넥터(Simple Connector)는 단순 컴포넌트에서 발생하는 메시지를

의미한다. 단순 커넥터를 이용하여 명세한 패턴이나 아키텍쳐는 특정 기능을

수행하는 복합 컴포넌트를 표현한다.

단순 커넥터의 표기는 기본적으로 가변 커넥터와 같은 구조를 지닌다.

<type>태그에 Simple 이라고 표기하는 것을 제외하면 가변 커넥터와 같은 방법

으로 표기한다. [리스트 3-4]는 단순 커넥터의 표기를 나타낸 것이다.

[리스트 3-4] 단순 커넥터 표기

<connector>

<type> Simple </type>

<name></name><direct> </direct>

<signature><return_type> </return_type><name></name>

53

<param_list> <num_of_param> </num_of_param>

<parameter> <type></type> <name></name><direct></direct></parameter>

</param_list>

</signature>

<src></src><dest></dest>

<order></order>

</connector>

[그림 3-2]는 컴포넌트들 간에 전달되는 메시지 정보를 나타내는 커넥터

명세를 위한 클래스 다이어그램을 표현한 것이다. 커넥터의 종류에는 단순 컴

포넌트에서 발생하는 메시지인 단순 커넥터와 가변 컴포넌트에서 발생하는 메

시지인 가변 커넥터가 있으며, VarConn 클래스와 SimpConn 클래스로 표현된다.

그리고, 이들 모두 Connector 클래스로부터 모든 속성들을 상속받는다.

+name+type+direction+src+dest+Order

Connector

+name+type+direction+src+dest+Order

VarConn+name+type+direction+src+dest+Order

SimpConn

+name+type+direction

Parameter

1

inheritinherit

+name+return_type+param_list

Signature

0..n

[그림 3-2] 커넥터 명세를 위한 클래스 다이어그램

Connector 클래스는 이름과 타입에 대한 정보와 메시지 방향, 메시지 발

생 컴포넌트 명과 메시지 수신 컴포넌트 명, 메시지 발생 순서와 시그니쳐 정

54

보들을 가지고 있다. 시그니쳐 정보는 컴포넌트 명세에서와 마찬가지로 반환값

의 타입과 메시지가 가지는 파라미터 리스트에 대한 정보를 포함한다. 파라미

터 리스트 내의 파라미터 정보는 Parameter 라는 별도의 클래스로 속성 정보들

이 유지된다.

3.2.3 아키텍쳐의 명세

이 논문에서 제안하는 명세 모델에서 아키텍쳐의 명세는 복합 컴포넌트

와 동일하게 정의되며, 다수의 컴포넌트와 커넥터로 구성된다. 따라서, 컴포넌

트의 명세에 따라 아키텍쳐도 복합 컴포넌트의 기능으로써 하나의 컴포넌트라

는 관점으로 명세에 접근한다. 아키텍쳐 명세의 전체 구조는 [리스트 3-5]와 같

이 정의한다.

[리스트 3-5] 아키텍쳐 명세의 전체 구조

<component_architecture>

<component> 컴포넌트 명세 부분 </component>

<connector>

<type> </type>

<direct> </direct>

<signature>

<return_type> </return_type>

<name> </name>

<param_list>

<num_of_param> </num_of_param>

<parameter>

<type> </type>

<name> </name>

<direct> </direct>

</parameter>

</param_list>

55

</signature>

<src> </src>

<dest> </dest>

</connector>

</component_architecture>

단순 컴포넌트는 일반적으로 필요한 기능을 지니는 컴포넌트를 표현하기

위한 것이고, 가변 컴포넌트는 컴포넌트의 형이 결정되지 않은 컴포넌트를 표

현하기 위한 것이며, 화이트 박스 재사용을 위한 컴포넌트로 UNIX 의 파이프

라인과 같은 구조를 표현하는데 사용한다. [그림 3-3]은 아키텍쳐 명세를 위한

클래스 다이어그램을 나타낸다.

+name+type+int_list+msg_list

Component

+name+type-uses+int_list+msg_list+Comp_list+Conn_list

CompArch

inherit

+name+type+int_list+msg_list

Component

1..n

+name+type+direction+signature+src+dest+Order

Connector0..n

[그림 3-3] 아키텍쳐 명세를 위한 클래스 다이어그램

메시지의 교환을 통해 컴포넌트들 간의 통신이 이루어지는 아키텍쳐에서

56

발생하는 메시지의 형태는 단방향과 양방향 형태의 메시지가 있다. 가변 커넥

터는 가변 컴포넌트와 함께 화이트 박스 재사용을 위한 요소이다.

3.3 컴포넌트 명세 모델

이 절에서는 소프트웨어 개발을 위해 아키텍쳐의 재구성을 위해 사용되

는 컴포넌트와 소프트웨어 개발자의 요구에 부합되는 컴포넌트를 명세하기 위

한 컴포넌트 명세 모델(Component Specification Model)을 제안한다.

3.3.1 컴포넌트 명세의 특징

컴포넌트의 명세는 컴포넌트 개발 단계에서의 산출물이지만 실제로 유지

보수나 컴포넌트 검색에 더 깊이 관련되어 있다. 이는 컴포넌트를 명세하는 작

업은 단순히 어떤 컴포넌트를 개발했는가에 대한 기록을 남기는 것보다 이후

의 재사용에 이용하기 위한 목적이라는 의미이다.

컴포넌트의 재사용을 위해 우선 필요한 것은 특정 문제에 대한 컴포넌트

의 기능을 기술함으로써 컴포넌트 재사용성(Component Reusability)을 향상시키고

보다 쉽게 접근할 수 있는 방법을 제공하는 컴포넌트의 기능을 명세할 수 있

는 명세 모델이 요구된다. 이를 위해서는 사용자의 요구 사항 정보를 추출하고,

비교하는 과정이 필요하다.

컴포넌트 명세에 있어 기존에 이미 많은 명세 언어가 사용되고 있으며,

이들은 나름대로의 장점을 가지고 있다. 그러나, 이들은 대부분 구현을 위해

특정 언어에 의존성이 강하며, 표현 능력에 한계를 가지고 있다. 이러한 한계

를 해결하기 위해 문제 요구 사항에 대한 설명, 컴포넌트의 기능 그리고 컴포

57

넌트 구조에 대한 명확한 정의를 제공하는 정형화된 명세 언어(Formal

Specification Language)가 필요하다.

그러나, 기존의 명세 언어들은 구조적 프로그래밍 방법을 고려한 형태의

명세였기 때문에 재사용을 고려한 컴포넌트 명세에 적용하기에는 부적합하다.

또한, 이러한 명세는 설계 단계에 초점을 두고 있기 때문에 소프트웨어 재사용

을 위해서는 보완이 필요하다.

컴포넌트 명세는 이후에 수행될 메시지 기반 컴포넌트 검색을 고려하여

모듈의 인터페이스 단위나 클래스의 메소드 단위의 명세를 제공한다. 일반적인

컴포넌트 검색 방법인 시그니쳐 일치 방법이나 명세서 일치 방법을 위해 시그

니쳐를 구조적인 방법을 이용하여 표현하고, 행위 샘플링 방법에서는 해당 컴

포넌트를 검색하여 직접 실행시키는 방법보다는 검색 도중 실행 가능한 형태

의 시그니쳐 기능 명세를 제공해야 한다.

이를 위해, 이 논문에서는 시그니쳐 일치 검색을 위해 컴포넌트를

CORBA 컴포넌트의 표준 인터페이스 정의 언어인 IDL 형식을 도입하고, 메시

지의 전달과 반환값의 처리를 위해 양방향 파라미터를 지원할 수 있게 하여

컴포넌트의 재사용성 향상과 효율적인 검색을 위해 XML 기반의 컴포넌트 명

세 모델을 제안한다.

이 논문에서는 컴포넌트 명세를 XML 형태로 매핑시킴으로 XML 의 기본

적인 특징 중 하나인 구조적인 형태의 컴포넌트 명세 언어 형식을 나타낸다.

이는 개발자로 하여금 컴포넌트 명세 언어에 대한 특정 지식 없이 원하는 컴

포넌트에 대한 요구 사항 정보를 기술할 수 있도록 한다. 그리고, 기술된 명세

는 XML 문서로 저장되므로 데이터를 효율적으로 관리할 수 있다.

58

이 논문에서 제안하는 인터페이스 명세의 기능 명세 부분은 컴포넌트 개

발자가 정의하여 사용할 수 있도록 허용한다. 컴포넌트 개발자의 정의에 따라

정의된 기능 명세 부분은 특정한 프로그래밍 언어의 형태를 따를 수도 있고,

새로 정의한 문법에 의해 정의될 수 있다.

특정한 프로그래밍 언어의 형태에 따라 기능 명세를 정의하게 되면, 컴

포넌트 개발자가 기능 명세를 위해 새로운 명세 언어를 습득해야 하는 어려움

이 없지만, 해당 프로그래밍 언어에 종속될 수 있으므로 이 논문에서는 언어

독립적인 기능 명세의 형태와 특정 언어를 이용한 기능 명세 모두를 허용한다.

명세 언어에서 기능 명세를 인터프리터 언어의 형태를 취하게 되면, 행

위 일치 검색 과정에서 해당 컴포넌트를 직접 실행시키지 않고, 기능 명세의

번역 과정을 통해 행위 일치 검색을 수행할 수 있다. 또한, 제안하는 컴포넌트

명세 언어의 특징은 인터페이스에 기반한 시그니쳐 기술과 기능 기술을 모두

지원함으로써 컴포넌트의 재사용을 위한 시그니쳐 일치 검색과 행위 일치 검

색 방법을 모두 지원할 수 있게 한다.

3.3.2 인터페이스 명세

이 논문에서 제안하는 컴포넌트 명세 모델은 XML 형태에 따라 명세하

며, 컴포넌트의 인터페이스 명세(Interface Specification)와 메시지 명세(Message

Specification)로 구분하여 명세되며, 인터페이스 명세는 시그니쳐 명세(Signature

Specification)와 기능 명세(Functional Specification)로 구분하여 명세된다.

(1) 시그니쳐 명세

컴포넌트 명세 언어에서 인터페이스는 CORBA 컴포넌트의 표준 인터페

59

이스 정의 언어인 IDL 명세 형태를 따른다. 인터페이스 명세는 해당 컴포넌트

가 발생시킬 수 있는 메시지들의 목록을 기술함으로써 특정 타입을 검색하는

시그니쳐 검색 방법을 제공한다.

메시지가 포함하는 파라미터 수와 타입 그리고 파라미터의 방향성과 같

은 정보를 나타내는 시그니쳐 명세는 [리스트 3-6]과 같이 정의한다.

[리스트 3-6] 시그니쳐 명세 문법

<signature>

<return_type> </return_type>

<name> </name>

<param_list>

<num_of_param> </num_of_param>

<parameter>

<type> </type>

<name> </name>

<direct> </direct>

</parameter>

</param_list>

</signature>

시그니쳐 명세 문법에서 <direct> 태그는 파라미터가 입력(In), 출력(Out)

그리고 입출력(Inout)인지를 지정하고, <type> 태그는 파라미터의 데이터 타입을

지정한다. [표 3-2]는 시그니쳐 명세의 파라미터 방향성을 정의한 것이다.

[표 3-2] 시그니쳐 파라미터의 방향성

방향 의미

In 입력 전용

Out 출력 전용

Inout 입출력

60

파라미터 타입을 정의하는 태그는 기본적으로 프로그래밍 언어의 데이터

타입에 기반을 두며, 타입은 크게 기본 타입과 생성 타입으로 구분한다. 기본

타입은 다시 실수형(Real Type), 정수형(Integer Type) 그리고 문자형(Character

Type)으로 분류하고, 생성 타입은 클래스형(Class Type), 공용체형(Union Type) 그

리고 열거형(Enumerate Type)으로 분류된다.

(2) 기능 명세

컴포넌트의 기능 명세는 특정 컴포넌트에 의해 기능을 가지는 경우 필요

한 기능을 지니는 컴포넌트 명세에 사용한다. 컴포넌트 명세의 기능 명세는

[리스트 3-7]과 같이 정의한다.

[리스트 3-7] 기능 명세 문법

<behavior>

<name>인터페이스 이름</name>

<modifies> </modifies>

<ensures> </ensures>

</behavior>

기능 명세는 인터페이스에 의해 접근 가능한 컴포넌트의 기능을 명세한

다. 기능 명세는 컴포넌트에서 제공되는 인터페이스의 기능에 대한 관점에서

명세를 제공해야 하기 때문에 인터페이스의 기능 명세 부분에 정의한다. [리스

트 3-7]에서 <modifies> 태그는 인터페이스 기능 수행 중 변경되는 변수들을 기

술하고, <ensures> 태그에는 인터페이스의 실제 동작을 명세한다. 그리고,

<ensures> 태그 내의 기술은 컴포넌트 개발자의 정의에 따라 자료형(Data Type),

연산(operation), 제어(control) 등을 기술한다. 이를 통한 인터페이스 명세의 전체

구조는 다음 [리스트 3-8]과 같다.

61

[리스트 3-8] 인터페이스 명세 문법

<int_list>

<num_of_int> </num_of_int>

<interface>

<name></name>

<signature>

<return_type> </return_type>

<name> </name>

<param_list>

<num_of_param> </num_of_param>

<parameter>

<type> </type>

<name> </name>

<direct> </direct>

</parameter>

</param_list>

</signature>

<behavior>

<name> </name>

<modifies> </modifies>

<ensures> </ensures>

</behavior>

</interface>

</int_list>

3.3.3 메시지 명세

메시지 명세에는 커넥터에 의한 컴포넌트들 간의 통신에서 해당 컴포넌

트가 다른 컴포넌트로부터 수신 가능한 메시지 목록에 대한 명세를 포함하며,

컴포넌트 명세에서 메시지 명세 부분은 [리스트 3-9]와 같이 시그니쳐 정보를

이용하여 정의한다.

62

[리스트 3-9] 메시지 명세 문법

<msg_list>

<num_of_msg> </num_of_msg>

<message>

<name> </name>

<signature>

<param_list>

<num_of_param> </num_of_param>

<parameter>

<type> </type>

<name> </name>

<direct> </direct>

</parameter>

</param_list>

</signature>

</message>

</msg_list>

<msg_list> 태그를 시작으로 컴포넌트가 받아들일 수 있는 메시지의 목록

을 나타내는 <num_of_msg> 태그가 있으며, <message> 태그에는 처리되는 메시

지에 대한 구체적인 기술을 한다. <name> 태그에 메시지의 이름을 기술하며,

<signature> 태그 내의 <num_of_param> 태그에는 파라미터의 개수를 기술하고,

<parameter> 태그에 각각의 파라미터에 대한 파라미터 명과 타입 그리고 방향

성 정보를 기술한다.

3.3.4 XML 기반의 명세 언어 구조

컴포넌트 명세 언어는 명세에 필요한 요소들을 XML태그를 사용하여 정

의한다. 이는 XML 에서 사용되는 사용자 태그가 유효하도록 하고, 각각의 태

그에 대한 데이터 타입을 정의함으로써 사용자의 잘못된 데이터 타입 입력에

대해 검사할 수 있는 기능을 제공한다.

63

이 논문에서 제안한 컴포넌트 명세에 사용된 명세 요소들에 대한 DTD

를 [리스트 3-10]과 같이 정의한다.

[리스트 3-10] 컴포넌트 명세의 DTD 정의

<?xml version=”1.0”?>

<!ELEMENT component (type, name, int_list, msg_list, uses)>

<!ELEMENT int_list (num_of_int, interface*)>

<!ELEMENT msg_list (num_of_msg, message*)>

<!ELEMENT interface (name?, signature, behavior?)>

<!ELEMENT message (name?, signature )>

<!ELEMENT signature (name?, return_type?, param_list)>

<!ELEMENT param_list (num_of_param, parameter*)>

<!ELEMENT parameter (type?, name?, direct?)>

<!ELEMENT behavior (name?, modifies?, ensures)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT type (#PCDATA)>

<!ELEMENT uses (#PCDATA)>

<!ELEMENT num_of_int (#PCDATA)>

<!ELEMENT num_of_msg (#PCDATA)>

<!ELEMENT return_type (#PCDATA)>

<!ELEMENT num_of_param (#PCDATA)>

<!ELEMENT direct (#PCDATA)>

<!ELEMENT modifies (#PCDATA)>

<!ELEMENT ensures (#PCDATA)>

[리스트 3-10]에서 정의한 DTD 를 기본으로 XML 형태의 컴포넌트 명세

언어의 기본 구조는 [리스트 3-11]과 같이 정의한다.

[리스트 3-11] 컴포넌트 명세의 기본 구조

<component><type></type><name> </name>

<int_list><num_of_int></num_of_int>

<interface><name></name>

<signature><return_type></return_type><name></name>

64

<param_list><num_of_param></num_of_param>

<parameter>

<type></type><name></name><direct></direct>

</parameter>

</param_list>

</signature>

<behavior>

<name></name><modifies></modifies><ensures></ensures>

</behavior>

</interface>

</int_list>

<msg_list><num_of_msg></num_of_msg>

<message><name></name>

<signature><name></name>

<param_list><num_of_param></num_of_param>

<parameter>

<type></type><name></name><direct></direct>

</parameter>

</param_list>

</signature>

</message>

</msg_list>

</component>

[리스트 3-11]의 컴포넌트 명세의 기본 구조에서 <component> 태그를 최

상위 태그로 정의했으며, 각각의 하위 태그들을 계층적으로 표현함으로써 개발

자가 그 의미를 파악하고 데이터를 입력하는데 어려움이 없도록 표현하였다.

또한, XML 의 특징인 구조적인 데이터 표현을 컴포넌트 명세에 활용함으로 개

발자가 사용자 인터페이스의 질의에 기술하고자 하는 데이터만을 입력하면

XML 문서는 기본 구조에 따라 자동으로 생성된다. 따라서, XML 문서를 사용하

여 데이터를 표현할 때 얻게 되는 데이터 관리의 일관성을 그대로 유지할 수

있고, 기본적으로 제공되는 뷰와 DTD 를 통해 오류 발생률을 감소시킬 수 있

다.

65

3.4 아키텍쳐에 기반한 컴포넌트 검색 모델

이 절에서는 컴포넌트 검색을 고려하여 이 논문에서 제안된 XML기반의

명세 모델을 이용하여 아키텍쳐에 기반한 컴포넌트 검색 모델(Architecture based

Component Retrieval Model)을 제안한다.

제안한 검색 모델은 아키텍쳐 저장소(Architecture Repository)로부터 아키텍

쳐를 검색하는 아키텍쳐 검색 모델(Architecture Retrieval Model)과 아키텍쳐 재구

성을 위해 컴포넌트 저장소(Component Repository)로부터 컴포넌트를 검색하기

위한 개선된 시그니쳐 일치 검색 모델(Enhanced Signature Match Retrieval Model)

그리고, 개선된 행위 일치 검색 모델(Enhanced Behavior Match Retrieval Model)로

구성된다.

3.4.1 아키텍쳐 검색 방법

소프트웨어 개발에 이용하는 아키텍쳐 검색은 아키텍쳐 저장소로부터 개

발자의 질의(query)와 구조적으로 일치하는 아키텍쳐들을 검색하는 방법이다.

아키텍쳐 저장소에 저장되어 있는 아키텍쳐들은 다수의 컴포넌트들과 커넥터

들로 구성되어 있다. 컴포넌트들간 통신은 인터페이스를 통해 이루어지며, 커

넥터는 컴포넌트들 간에 이러한 통신을 제어한다.

따라서, 소프트웨어 개발에 적합한 아키텍쳐를 검색하기 위해서는 개발

자의 질의와 아키텍쳐 저장소내의 컴포넌트들과 커넥터들을 일치시켜야 한다.

소프트웨어 개발에 적합한 아키텍쳐 검색 방법의 일반적인 일치 술어는 [정의

9]와 같이 정의한다.

66

[정의 9] 아키텍쳐의 일치

))',(,targetas'with'messageandtargetaswithmessage(

))',(,sourceas'with'messageandsourceaswithmessage())',(,in'componentsimpleandincomponentsimple(

))()(())((),(

MMmatchCMCM

MMmatchCMCM

CCmatchARCQC

QcountARcountQcount)count(ARQARM msgmsgcompcomp

∃∀∧∃∀∧

∃∀∧

≥∧==

[정의 9]에서 아키텍쳐 일치는 아키텍쳐 저장소와 개발자 질의의 컴포넌

트 개수와 커넥터의 개수를 사용하여 일치 여부를 비교하는 방법으로 아키텍

쳐내의 단순 컴포넌트 수가 일치하고, 단순 컴포넌트에 연결된 커넥터의 소스

와 목표 컴포넌트에 대한 정보가 일치하여야 한다.

이 논문에서 제안하는 아키텍쳐 검색 방법은 아키텍쳐 저장소내에 존재

하는 모든 컴포넌트의 수를 검사하고, 컴포넌트에 의해 발생되는 메시지를 다

른 컴포넌트로 전달하는 커넥터의 개수를 비교하여 아키텍쳐를 검색한다. 검색

된 아키텍쳐는 소프트웨어 재구성을 위해 사용된다. 아키텍쳐 검색 방법을 사

용하여 아키텍쳐 저장소로부터 개발자의 요구에 적합한 아키텍쳐를 검색하는

과정은 다음과 같다.

개발자 질의에 있는 컴포넌트 개수와 아키텍쳐 저장소의 아키텍쳐 내에

있는 컴포넌트 개수를 비교하기 위해 질의와 아키텍쳐 내에서 컴포넌트를 찾

는 과정이 필요하다. 먼저 검색된 컴포넌트를 시작으로 해서 질의와 아키텍쳐

저장소에 존재하는 전체 컴포넌트 개수를 검색한다.

아키텍쳐 저장소에 존재하는 모든 아키텍쳐들에 대해 이 과정을 반복해

서 수행하고, 아키텍쳐 저장소의 아키텍쳐에 존재하는 컴포넌트 개수가 개발자

의 질의와 일치하는 아키텍쳐들만을 검색하여 아키텍쳐 저장소의 검색 범위를

일차적으로 축소시킨다.

다음 과정으로 컴포넌트 개수 비교에 의해 검색된 아키텍쳐들을 대상으

67

로 컴포넌트들간 메시지를 전달하는 커넥터의 개수를 비교하는 과정을 수행한

다. 커넥터의 개수를 비교할 때 단순히 소프트웨어 아키텍쳐 내의 커넥터 수만

을 비교하게 되면 컴포넌트들간 이루어지는 통신을 완벽하게 만족하는 아키텍

쳐를 검색할 수 없다. 따라서, 먼저 커넥터 명세에 있는 메시지 발생 컴포넌트

정보와 메시지 수신 컴포넌트 정보를 비교하여야 한다.

개발자의 질의에 명세되어 있는 컴포넌트들을 확인하고, 이들 컴포넌트

들이 어떤 커넥터에 의해 통신이 이루어지고 있는지를 저장소의 아키텍쳐들과

비교한다. 마지막으로 이러한 커넥터의 개수를 비교해서 개발자 질의에 나타난

커넥터 개수보다 많거나 같은 커넥터 수를 가진 아키텍쳐들을 아키텍쳐 저장

소로부터 검색함으로써 개발자의 질의와 유사한 후보 아키텍쳐들을 검색할 수

있다.

소프트웨어 개발에 적합한 아키텍쳐 검색을 수행하기 위해 가장 먼저 수

행되는 과정은 저장소에 있는 첫번째 아키텍쳐를 검색하는 것이다. 그리고, 검

색된 첫번째 아키텍쳐를 대상으로 검색 과정의 모든 절차를 적용시킨다. 개발

자의 아키텍쳐 질의와 검색된 저장소의 첫번째 아키텍쳐 내에 존재하는 컴포

넌트 개수를 비교해서 일치 여부를 확인하고, 커넥터에 대해서도 동일한 과정

을 수행하게 된다. 이 때 개발자의 질의 아키텍쳐와 아키텍쳐 저장소내의 컴포

넌트 개수는 동일해야 하지만, 커넥터의 개수는 아키텍쳐 저장소의 아키텍쳐

커넥터 개수가 개발자의 질의 아키텍쳐 커넥터 개수보다 많거나 동일하면 된

다.

다음 과정으로 개발자의 질의 아키텍쳐와 저장소의 첫번째 아키텍쳐 내

의 단순 컴포넌트 리스트와 커넥터 리스트를 구성한다. 저장소의 첫번째 아키

텍쳐 내의 단순 컴포넌트 리스트에서 개발자의 질의 아키텍쳐 내의 단순 컴포

68

넌트 명과 일치하는 컴포넌트가 검색되면 이후 과정을 계속해서 수행하고, 그

렇지 않으면 아키텍쳐 저장소의 다음 아키텍쳐를 선택한다.

단순 컴포넌트 명이 일치하는 컴포넌트를 포함하는 아키텍쳐일 경우 단

순 컴포넌트의 반환 타입과 단순 컴포넌트에 연결된 커넥터의 소스와 목표 컴

포넌트에 대한 정보를 개발자의 질의 아키텍쳐와 일치 여부를 비교하여 아키

텍쳐를 검색하게 된다.

선택된 아키텍쳐가 모든 조건을 만족하면 이를 후보 아키텍쳐로 등록하

고, 아키텍쳐 저장소의 다른 아키텍쳐를 선택하여 동일한 과정을 통해 개발자

의 질의 아키텍쳐와 비교 과정을 계속해서 수행하게 된다.

아키텍쳐 검색 방법에 의해 검색된 아키텍쳐들을 소프트웨어 개발에 적

합한 아키텍쳐로 재구성하기 위해 필요한 대체 가능한 컴포넌트들을 검색하는

검색 방법이 필요하다. 따라서, 이 논문에서는 컴포넌트 검색을 위한 개선된

시그니쳐 일치 검색과 개선된 행위 일치 검색 방법을 제안한다.

3.4.2 시그니쳐 일치 검색

개선된 시그니쳐 일치 검색 방법은 컴포넌트 인터페이스에 존재하는 메

소드의 파라미터 타입과 파라미터의 입출력 방향을 이용하여 컴포넌트 저장소

로부터 개발자의 질의와 일치하는 인터페이스를 가진 컴포넌트를 검색하는 방

법이다.

개선된 시그니쳐 일치 검색 방법의 일반적인 일치 술어는 [정의 10]과 같

이 정의한다.

69

[정의 10] 개선된 시그니쳐 일치

)()(),( 21 qrqr tRtdRdQRM ∧=

[정의 10]에서 시그니쳐 일치는 컴포넌트 저장소에 있는 컴포넌트 인터페

이스와 개발자 질의의 메소드 파라미터 타입과 파라미터 입출력 방향 정보를

사용하여 일치 여부를 비교하는 방법이다.

t r 과 tq 는 컴포넌트 저장소와 개발자 질의에 있는 인터페이스 파라미터

타입들이고, dr 과 dq 는 컴포넌트 저장소에 있는 컴포넌트 인터페이스 내의 메

소드와 개발자 질의의 파라미터 입출력 방향을 나타낸다. 그리고, R1 과 R2 는

컴포넌트 저장소에 있는 컴포넌트 인터페이스의 메소드와 개발자의 질의와의

관련성을 나타낸다. 이 관련성에 따라 개선된 시그니쳐 일치 검색 방법은 완전

일치(Exact Match) 방법과 이완 일치(Relaxed Match) 방법으로 분류되며, 이완 일

치 방법은 타입 이완 일치(Type Relaxed Match) 방법과 방향 이완 일치(Direction

Relaxed Match) 방법으로 분류하였다.

[표 3-3]은 시그니쳐 일치 검색 방법의 시스니쳐 일치에 대한 인스턴스들

을 정의한 것이다.

[표 3-3] 시그니쳐 일치의 인스턴스

Match R1 R2 dr dq t r tq

완전 일치

일반화 일치

특수화 일치

방향 이완 일치

====

=≥≤=

DnDnDnDn

DnDnDnDn

TdTdTd

T∂(Td)

TdTdTd

T∂(Td)

[표 3-3]에서 Dn 은 파라미터 방향의 수, Td 은 각 방향에 대한 타입을 나

70

타낸다. 그리고, T∂는 입출력 방향 수의 변형을 나타낸다.

컴포넌트 저장소에 있는 컴포넌트 인터페이스의 파라미터 입출력 방향의

개수와 질의의 파라미터 입출력 방향의 개수를 비교하여 일치하면 완전 일치

방법이나 타입 이완 일치 방법을 수행한다. 일치 하지 않을 경우는 방향 이완

일치 방법을 수행한다.

소프트웨어 개발에 적합한 아키텍쳐를 재구성하기 위한 컴포넌트를 검색

하는 방법인 개선된 시그니쳐 일치 검색 방법은 다음과 같은 절차에 의해 수

행된다. 컴포넌트 저장소를 대상으로 개발자의 질의에서 컴포넌트 명세 부분을

사용하여 컴포넌트 질의를 생성하고, 개발자 질의에서 파라미터 입출력 방향에

따른 파라미터 개수를 비교한다.

그리고, 저장소에 있는 모든 컴포넌트들을 대상으로 입출력 방향에 따른

파라미터 개수를 비교한 다음, 파라미터 개수가 일치하는 컴포넌트에 대해 완

전 일치 방법이나 타입 이완 일치 방법 또는 방향 이완 일치 방법을 사용하여

아키텍쳐 재구성을 위해 필요한 컴포넌트를 검색한다.

각 방향성을 고려하여 파라미터를 비교한 결과의 파라미터 개수가 동일

한 컴포넌트에 대해서는 완전 일치 방법이나 타입 이완 일치 방법을 적용하고,

동일하지 않을 경우는 방향 이완 일치 방법을 적용한다. 컴포넌트 저장소의 모

든 컴포넌트들을 대상으로 이 과정을 반복 수행함으로써 아키텍쳐 재구성을

위해 적합한 컴포넌트를 검색한다.

(1) 완전 일치

완전 일치 방법은 컴포넌트 저장소에 있는 컴포넌트 인터페이스의 파라

미터 입출력 방향의 수와 개발자 질의의 파라미터 입출력 방향의 수가 같을

71

때, 각 방향에 대한 타입을 비교하여 컴포넌트를 검색한다. 만약, 타입이 일치

하지 않을 경우에는 이완 일치 방법으로 검색이 수행된다. 완전 일치(Exact

Match)의 일치 술어는 [정의 11]과 같이 정의한다.

[정의 11] 시그니쳐 일치의 완전 일치

)()(),( ttqrE QRddQRM =∧==

qr dd = 는 컴포넌트 인터페이스의 파라미터 입출력 방향의 수와 질의의

입출력 방향의 수가 같아야 한다는 의미이고, tt QR = 는 컴포넌트 인터페이스

파라미터의 타입과 질의의 파라미터 타입이 같아야 한다는 의미이다.

완전 일치 방법에 의한 컴포넌트 검색은 개발자 질의와 컴포넌트 저장소

에 저장되어 있는 컴포넌트간 각 방향성, 즉 입력(In), 출력(Out), 입출력(Inout)

방향에 따른 파라미터 개수를 비교하여 일치하는 컴포넌트를 대상으로 방향성

에 따른 각각의 타입을 비교하여 일치하는 컴포넌트를 검색하는 방법이다.

완전 일치 방법은 개발자의 질의와 컴포넌트 저장소에 있는 컴포넌트들

을 대상으로 입출력 방향성에 대한 파라미터의 개수를 비교한 결과 일치하는

컴포넌트에 대해 각각의 타입을 비교함으로써 수행된다. 개발자의 질의와 컴포

넌트 저장소의 컴포넌트들에 나타난 입출력 방향에 따른 파라미터 타입을 이

용하여 상호간 일치 여부를 비교함으로써 검색이 이루어진다.

완전 일치 방법을 이용한 컴포넌트 검색은 저장소의 컴포넌트 인터페이

스 내에 있는 메소드들의 타입과 질의의 타입이 정확하게 일치할 때 컴포넌트

들을 검색할 수 있는 방법으로 개발자가 컴포넌트 저장소와 명세 언어에 대한

정확한 지식이 필요하며, 개발자의 질의와 정확하게 일치하는 컴포넌트를 검색

72

할 수는 있지만 아키텍쳐 재구성을 위해 이용될 수도 있는 질의와 유사한 컴

포넌트를 검색할 수 없다.

따라서, 검색의 효율을 높이기 위해서는 개발자의 질의와 정확하게 일치

하지는 않지만, 질의와 유사한 컴포넌트를 검색할 수 있는 방법이 요구된다.

이 논문에서는 아키텍쳐 재구성에 사용될 수 있는 유사한 컴포넌트들을 검색

하기 위한 방법으로 이완 일치 방법을 사용한다. 이완 일치 방법에는 타입 이

완 일치 방법과 방향 이완 일치 방법으로 구분한다.

(2) 타입 이완 일치

타입 이완 일치 방법은 컴포넌트 인터페이스 명세를 개발자의 질의와 비

교할 때 파라미터의 입출력 방향의 수는 일치하지만, 입출력 방향의 타입이 질

의와 다른 컴포넌트들을 검색한다.

따라서, 질의나 컴포넌트의 파라미터 입출력 방향의 수가 일치하였을 때

파라미터의 타입만을 비교하여 컴포넌트를 검색한다. 타입 이완 일치 방법에는

일반화 일치(Generalized Match) 방법과 특수화 일치(Specialized Match) 방법으로

분류한다.

• 일반화 일치

컴포넌트 저장소의 컴포넌트 인터페이스 타입과 질의 타입을 비교할 때

일반화 일치 방법은 컴포넌트 저장소에 있는 컴포넌트 인터페이스 타입이 개

발자의 질의 타입을 포함하는 형태의 컴포넌트를 검색하는 방법이다.

일반화 일치의 일치 술어는 [정의 12]와 같이 정의한다.

73

[정의 12] 시그니쳐 일치의 일반화 일치

)()(),( ttqrgen QRddQRM ≥∧==

qr dd = 는 컴포넌트 인터페이스의 파라미터 입출력 방향의 수와 질의의

입출력 방향의 수가 같아야 한다는 의미이다. tt QR ≥ 는 컴포넌트 인터페이스

의 파라미터의 타입이 질의의 입출력 방향의 타입을 포함하는 관계로서 보다

일반적임을 나타낸다.

• 특수화 일치

특수화 일치 방법은 일반화 일치 방법의 역으로 저장소에 있는 컴포넌트

인터페이스 파라미터 타입이 질의의 타입에 포함되는 형태인 컴포넌트를 검색

하는 방법이다. 특수화 일치는 개발자가 새로운 소프트웨어를 개발할 때 필요

한 컴포넌트 내에 존재하는 메소드의 파라미터 타입을 정확히 알지 못할 경우

에 사용할 수 있다. 특수화 일치의 일치 술어는 [정의 13]과 같이 정의한다.

[정의 13] 시그니쳐 일치의 특수화 일치

)()(),( ttqrspec QRddQRM ≤∧==

qr dd = 는 컴포넌트 인터페이스의 파라미터 입출력 방향의 수와 질의

의 입출력 방향의 수가 같아야 한다는 의미이다. tt QR ≤ 는 질의의 입출력 방

향의 타입이 컴포넌트 저장소에 있는 컴포넌트 인터페이스의 파라미터의 타입

보다 일반적이라는 의미이다.

타입 이완 일치 방법에 의한 컴포넌트 검색은 개발자의 질의와 컴포넌트

저장소에 있는 컴포넌트 인터페이스 사이에 각 방향성에 따른 파라미터 개수

74

가 일치하는 컴포넌트를 대상으로 일반화 일치 방법이나 특수화 일치 방법을

사용하여 아키텍쳐 재구성에 필요한 적절한 컴포넌트를 검색한다.

타입 이완 일치 방법은 완전 일치 방법과 동일하게 개발자의 질의와 컴

포넌트 저장소의 컴포넌트들간 입출력 방향에 대한 파라미터 개수가 일치하는

컴포넌트를 대상으로 수행된다. 타입 이완 일치 방법은 개발자의 질의와 저장

소의 컴포넌트 입출력 방향에 대해 일반화 방법을 적용하거나, 특수화 방법을

적용하여 컴포넌트를 검색한다.

(3) 방향 이완 일치

방향 이완 일치 방법은 컴포넌트 명세에서 파라미터의 입출력 방향을 나

타내는 Inout 파라미터가 입력 방향과 출력 방향 모두에 적용할 수 있기 때문

에 질의와 일치하는 컴포넌트를 검색한다. 이 방법은 컴포넌트나 질의의 파라

미터 각각의 입력, 출력, 입출력 방향 개수가 일치하지는 않지만 전체 파라미

터 개수가 일치할 때 입출력 방향의 수를 조정하여 일치시킨 후, 각 방향의 타

입을 검사하여 질의와 일치하는 컴포넌트를 검색한다.

예를 들어, 컴포넌트 인터페이스의 입력, 출력, 입출력 방향에 대한 컴포

넌트 파라미터의 수가 (5, 3, 4)이고, 질의의 파라미터 수가 (3, 1, 6)일 때, 질의의

입출력 방향의 수를 (5, 3, 4)로 조정하여 각 방향의 타입을 검사한다. 방향 이완

일치의 일치 술어는 [정의 14]와 같이 정의한다.

[정의 14] 시그니쳐 일치의 방향 이완 일치

))(T)(T()(),( ttqrD QRddQRM σσ =∧≠=

)( qr dd ≠ 는 컴포넌트 저장소에 있는 컴포넌트 인터페이스의 파라미터

75

각각의 입출력 방향의 수와 질의의 입출력 방향의 수가 일치하지 않는다는 의

미이다. ))(T)(T( tt QR σσ = 는 컴포넌트 인터페이스의 파라미터 입출력 방향의

수와 질의의 입출력 방향의 수를 조정하여 각 방향의 타입이 같다는 의미이다.

방향 이완 일치 방법을 수행하기 위해서는 다음과 같은 조건을 만족하여

야 한다.

• Inout 방향의 개수를 조정하기 전에 일치하는 파라미터들의 타입은 완전

일치나 타입 이완 일치를 수행한다 .

• 컴포넌트 인터페이스와 질의의 입출력 방향을 나타내는 In 방향 파라미터,

Out 방향 파라미터와 Inout 방향 파라미터 개수의 차이가 같아야 한다 .

• 조정한 입출력 파라미터들의 타입들은 반드시 완전 일치를 수행하여야

한다.

방향 이완 일치 방법에 의한 컴포넌트 검색은 개발자의 질의와 컴포넌트

저장소에 있는 컴포넌트 인터페이스 사이에 각 방향성에 따른 파라미터 개수

가 다른 경우에 Inout 파라미터를 이용하여 개수를 조정한 후 완전 일치 방법

을 사용하여 컴포넌트를 검색하는 방법이다.

방향 이완 일치 방법은 우선 개발자의 질의와 컴포넌트 저장소의 컴포넌

트 인터페이스간 입력 방향 파라미터 개수의 차이와 출력 방향 파라미터 개수

의 차이 그리고 입출력 방향 파라미터 개수의 차이를 검사하고, 이 차이가 동

일한 컴포넌트들을 대상으로 하여 각 방향성에 따른 타입 비교를 위해 완전

일치 방법을 사용하여 아키텍쳐 재구성에 필요한 컴포넌트를 검색하는 방법이

다.

방향 이완 일치 방법은 개발자의 질의와 컴포넌트 저장소의 컴포넌트 인

76

터페이스간 입출력 방향에 따른 파라미터 개수의 차이를 비교하기 위해 입력,

출력 그리고 입출력 각각에 대한 파라미터 개수 차이를 저장하고, 파라미터 개

수 차이가 일치하는지를 비교한 후 일치하는 저장소의 컴포넌트를 컴포넌트

배열에 저장한다. 다음 과정으로 방향성에 따른 파라미터 개수 차이의 일치 여

부가 확인된 컴포넌트들을 대상으로 완전 일치 방법에서와 동일한 방법을 사

용하여 개발자의 질의와 컴포넌트 저장소의 컴포넌트 인터페이스 사이에 입출

력 방향에 따른 타입을 비교한다.

개선된 시그니쳐 일치 검색 방법은 개발자의 질의와 일치하는 컴포넌트

를 검색할 수도 있고, 행위 일치 검색을 수행하기 위한 컴포넌트 저장소의 크

기를 제한하여 줄여주는 역할을 수행한다. 또한, 완전 일치를 통해 검색될 수

없는 컴포넌트를 검색할 수 있도록 하는 이완 일치 방법을 제공함으로써 검색

의 재현율과 정확성을 향상시킬 수 있다.

3.4.3 행위 일치 검색

아키텍쳐 검색 방법에 의해서 검색된 아키텍쳐를 구성하는 컴포넌트들의

재구성을 위한 검색 방법으로 개선된 행위 일치에 의한 검색 방법을 제안한다.

[그림 3-4]는 개선된 행위 일치 검색 방법의 검색 과정을 나타낸 것이다.

평가기(Evaluator)에 의해서 수행되는 과정에서 에러를 발생시키는 경우와

무한 루프를 발생시키는 경우 그리고 수행 과정이 오랜 기간 동안 수행되는

경우는 검색 대상에서 제외된다.

개선된 행위 일치 검색을 수행하는 데 있어서 컴포넌트 저장소에 있는

모든 컴포넌트들을 대상으로 하는 것은 검색 효율성을 감소시킨다. 따라서, 개

선된 시그니쳐 일치 검색 방법에 의해 검색된 컴포넌트들을 대상으로 하여 새

77

로운 소프트웨어를 개발하기 위해 개발자의 요구에 맞는 컴포넌트를 검색함으

로써 검색의 효율성을 높일 수 있도록 하였다.

Previous Phase

Data forValidation

(User Input)

Selected Component Group

Retrieved Component Group

ParameterValue

RecommendedOutput

Virtual Machine

RetrievedComponents

Behavior Matching

Evaluator

ComponentRepository

[그림 3-4] 개선된 행위 일치 검색 과정

개발자는 컴포넌트의 인터페이스를 평가기에 의해서 수행하기 위한 입력

값과 수행 결과와 비교하기 위한 출력값을 설정하여 평가기의 수행 결과와 출

력값을 비교하여 컴포넌트를 검색한다.

개선된 행위 일치 검색 방법에 의한 컴포넌트 검색 과정은 다음과 같이

수행된다. 개발자는 컴포넌트 저장소의 컴포넌트들을 대상으로 가상 머신

(Virtual Machine) 상에서 수행하기 위한 입력값과 출력값을 설정하게 된다. 평가

기(Evaluator)는 개발자가 설정한 입력값을 가지고 컴포넌트 저장소 각각의 컴

78

포넌트 인터페이스를 가상 머신 상에서 직접 실행하게 된다. 실행 결과로 생성

된 결과값을 개발자가 설정한 출력값과 비교하여 아키텍쳐 재구성에 필요한

컴포넌트를 검색하게 된다.

개선된 행위 일치 검색 방법을 사용하더라도 다수의 컴포넌트가 검색될

수 있고, 개발자의 요구 사항과 정확하게 일치하지 않는 컴포넌트들이 검색될

수 있기 때문에 개발자는 적절한 커넥터를 사용하여 소프트웨어 개발에 적용

하여야 한다.

시그니쳐 검색 방법에 의해 검색된 각각의 컴포넌트들을 대상으로 하여

개발자가 설정한 입력값을 가지고 가상 머신 상에서 직접 컴포넌트 인터페이

스를 실행시키고, 그 결과값을 저장한다. 다음 과정으로 실행 결과값과 개발자

가 설정한 출력값을 비교하여 일치하는 컴포넌트들을 검색하게 된다.

개선된 행위 일치 검색 방법은 개선된 시그니쳐 일치 검색에 의해 검색

된 컴포넌트들을 대상으로 하기 때문에 검색 시간 비용을 줄일 수 있고, 개발

자가 직접 입력값과 출력값을 설정하기 때문에 검색의 재현율을 향상시킨다.

또한, 컴포넌트의 기능적인 측면에서의 검색을 수행하기 때문에 검색의 정확성

을 향상시킨다. 그리고, 컴포넌트 기능 명세를 인터프리터 언어의 형태를 취하

게 되면 행위 일치 검색 과정에서 해당 컴포넌트를 직접 실행시키지 않고, 기

능 명세의 번역 과정을 통해 행위 일치 검색을 수행할 수 있다.

이를 위해, 이 논문에서 제안한 인터페이스 명세의 기능 명세 부분은 컴

포넌트 개발자가 정의하여 사용할 수 있도록 하여 컴포넌트 개발자의 정의에

따라 정의된 기능 명세 부분은 특정한 프로그래밍 언어의 형태를 따를 수도

있고, 새로 정의한 문법에 의해서 정의할 수 있다.

79

제 4 장 아키텍쳐 기반 컴포넌트 검색

시스템의 설계 및 구현

이 장에서는 제안한 XML 기반의 명세 모델과 컴포넌트 검색 방법을 적

용하여 아키텍쳐에 기반한 컴포넌트 검색 시스템을 설계하고, 프로토타입 검색

시스템을 구현한다. 전체적인 검색 시스템은 명세 저장소(Specification Repository)

와 검색 모듈(Retrieval Module) 그리고 사용자 인터페이스(User Interface)로 구성

된다. XML 기반 명세를 사용하기 때문에 사용자 인터페이스는 웹 기반의

HTML 스타일 형태로 설계하였다.

4.1 구현 환경과 시스템 구성

대부분의 검색 방법들은 개발자의 질의와 일치하는 컴포넌트들을 검색하

여 새로운 소프트웨어 개발에 적용하고, 아키텍쳐를 재구성하는데 사용된다.

따라서, 소프트웨어 개발에 적용하기 위한 노력을 최소화할 수 있는 검색 방법

이 제공되어야 한다.

이 논문에서는 소프트웨어의 기능성보다는 구조적인 관점에서 개발자의

요구 사항과 일치하는 아키텍쳐를 검색하는 아키텍쳐 검색 모듈(Architecture

Retrieval Module)과 검색한 아키텍쳐의 재구성에 필요한 컴포넌트를 검색하기

위한 시그니쳐 일치 검색 모듈(Signature Match Retrieval Module), 행위 일치 검색

모듈(Behavior Match Retrieval Module)로 구성되는 아키텍쳐에 기반한 컴포넌트 검

색 시스템(Architecture based Component Retrieval System)을 설계 및 구현한다.

80

4.1.1 구현 환경

시스템의 전체 구현 환경은 [그림 4-1]과 같이 구성된다.

Internet Information Server 4.0 with Active Server Page (As Service Executor) Architecture

basedComponent

Retrieval

XML enabledHTML Browser

Windows NT Server 4.0MS SQL Server 7.0(RDBMS)

Visual C++ 6.0, Platform SDK

Internet(Intranet)

XML DTDStyle data(XSL)

Implementedas

COM Service

[그림 4-1] 시스템의 구현 환경

이 논문에서 설계한 아키텍쳐 기반 컴포넌트 검색 시스템은 운영체제로

Windows NT 4.0 을 사용하여 구현한다. XML DTD에 기반한 XML 형태의 아키

텍쳐 및 컴포넌트 명세서는 COM(Component Object Model) 서비스 형태로 제공

되는 검색 시스템을 실행시키는 기능과 시스템과의 인터페이스를 위해

Windows NT 4.0 이 제공하는 IIS(Internet Information Server) 4.0을 사용한다. 그리

고, 이러한 XML 기반의 명세서 관리를 위한 저장소 구현을 위해 MS SQL

Server 7.0 을 사용한다. 개발 도구로는 Visual C++ 6.0 과 PSDK(Platform SDK)를

사용하였고, 구현 대상이 되는 아키텍쳐 기반 컴포넌트 검색 시스템은 COM

컨트롤 객체로 구현하여 서비스의 형태로 실행하였다.

웹 상에서 개발자의 질의 작성과 검색 시스템에 의한 검색 결과를 브라

81

우저를 통해 확인하기 위해 XML 데이터를 표시할 수 있는 브라우저가 필요하

며, 이러한 데이터들은 XSL 과 같은 스타일 시트를 사용함으로써 표현될 수 있

다.

4.1.2 시스템 구성과 동작

[그림 4-2]는 이 논문에서 설계한 아키텍쳐 기반 컴포넌트 검색 시스템의

전체적인 구성과 동작 형태를 보여주고 있다.

ArchitectureMatching

Module

SignatureMatching

Retrieval Module

BehaviorMatching

Retrieval Module

TemporaryWorkspace

WW

W U

ser Interface

ArchitectureSpecificationRepository

ComponentSpecificationRepository

Query

ArchitectureMatchingResult

SignatureMatchingResult

BehaviorMatchingResult

[그림 4-2] 시스템의 구성과 동작

아키텍쳐 검색 모듈은 소프트웨어의 구조적인 측면에서 소프트웨어 재구

성을 위한 아키텍쳐들을 아키텍쳐 저장소로부터 검색한다. 시그니쳐 일치 검색

모듈은 검색된 아키텍쳐를 소프트웨어 개발에 적합한 아키텍쳐로 재구성하는

데 필요한 대체 가능한 컴포넌트들을 컴포넌트 저장소로부터 검색한다. 그리고,

행위 일치 검색 모듈은 시그니쳐 일치 검색 모듈에 의해 검색된 컴포넌트들을

대상으로 하여 사용자 인터페이스를 직접 시뮬레이션함으로써 아키텍쳐 재구

성에 필요한 좀 더 구체적인 컴포넌트들을 검색한다.

82

웹 사용자 인터페이스 상에서 개발자에 의해 작성된 질의는 새로운 소프

트웨어 개발에 적합한 아키텍쳐를 검색하기 위해 아키텍쳐 검색 모듈로 전달

된다. 아키텍쳐 검색 모듈은 아키텍쳐 명세 저장소로부터 개발자의 질의와 일

치하는 아키텍쳐를 검색하고, 검색된 후보 아키텍쳐(Candidate Architecture)들은

임시 작업공간(Temporary Workspace)으로 전달됨과 동시에 개발자가 웹 상에서

확인할 수 있도록 한다.

검색된 후보 아키텍쳐들이 개발자가 원하는 아키텍쳐가 아닐 경우 후보

아키텍쳐 내의 컴포넌트들을 대체하여 소프트웨어 개발에 적합한 아키텍쳐로

재구성하기 위해 컴포넌트 저장소로부터 적합한 컴포넌트를 시그니쳐 일치 검

색 모듈에 의해서 검색하게 된다.

임시 작업공간의 후보 아키텍쳐는 아키텍쳐 재구성을 위한 컴포넌트 검

색을 위해 시그니쳐 일치 검색 모듈로 전달되고, 시그니쳐 일치 검색 모듈은

컴포넌트 저장소로부터 후보 아키텍쳐 내의 컴포넌트들을 대체할 수 있는 컴

포넌트를 검색한다. 시그니쳐 일치 검색 모듈에 의한 컴포넌트 검색 결과는 임

시 작업공간으로 전달될 뿐만 아니라 웹 상에서 사용자가 확인할 수 있다.

개발자가 시그니쳐 일치 검색 모듈에 의해서 검색된 컴포넌트들보다 좀

더 구체적인 컴포넌트를 원할 경우, 시그니쳐 일치 검색 모듈을 통해 검색된

임시 작업공간의 컴포넌트들은 행위 일치 검색 모듈로 전달된다. 행위 일치 검

색 모듈은 전달된 컴포넌트들의 인터페이스 명세를 직접 실행함으로서 아키텍

쳐 재구성에 필요한 컴포넌트들을 검색한다.

행위 일치 검색 모듈에 의해 검색된 컴포넌트들도 개발자가 웹 상에서

확인할 수 있도록 하여 새로운 소프트웨어 개발에 적합한 아키텍쳐를 재구성

할 수 있도록 한다. [그림 4-3]은 개발자가 질의를 작성하는 단계를 시작으로 아

83

키텍쳐 및 컴포넌트 검색 모듈에 의해 아키텍쳐와 컴포넌트들이 어떠한 과정

을 통해 검색되고, 최종적인 아키텍쳐를 개발자가 스타일 시트를 적용해 확인

하는 단계까지를 순차 다이어그램(Sequence Diagram)으로 나타낸 것이다.

User

WWW UserInterface

ArchitectureRetrieval

TemporaryWorkspace

ComponentRetrieval

Query

XML Query Form

MatchingRetrieved

Architecture

Component Query

SignatureMatching

RetrievedArchitecture

RetrievedComponents DiagValue

Generation

BehaviorMatching

RetrievedComponents

RetrievedComponents

RetrievedComponents

XMLConversion

ApplyingXSL

ApplyingXSL

ApplyingXSL

XML Documents

XML Documents

XML Documents

[그림 4-3] 아키텍쳐 및 컴포넌트 검색의 순차 다이어그램

웹 사용자 인터페이스 상에서 개발자가 질의를 작성하면 이는 검색을 위

한 XML 형태의 문서로 변환하는 과정을 거치게 된다. 변환된 XML 형태의 질

의는 소프트웨어 개발에 적합한 아키텍쳐를 검색하기 위해 아키텍쳐 저장소에

저장된 아키텍쳐들을 대상으로 아키텍쳐 검색을 수행하게 된다. 검색된 후보

아키텍쳐들은 XSL 을 사용하여 브라우저를 통해 개발자가 확인할 수 있다.

84

후보 아키텍쳐들 중에서 소프트웨어 개발에 적합한 아키텍쳐가 없을 경

우 임시 작업공간에서 아키텍쳐 내의 컴포넌트를 대체하기 위해 컴포넌트 저

장소에 저장된 컴포넌트들을 대상으로 적합한 컴포넌트를 검색하게 된다. 아키

텍쳐 재구성을 위한 대체 컴포넌트 검색을 위해 개발자 질의의 인터페이스 명

세의 시그니쳐 부분을 사용하여 시그니쳐 검색을 수행한다.

시그니쳐 일치 검색 모듈을 통해 검색된 컴포넌트들도 XSL 을 사용하여

개발자가 확인할 수 있다. 시그니쳐 일치 검색 모듈을 통해 검색된 컴포넌트에

대한 좀 더 구체적인 검색을 수행하고자 한다면 시그니쳐 일치 검색 모듈에

의해 검색된 컴포넌트들을 대상으로 행위 일치 검색 모듈을 수행하게 된다. 행

위 일치 검색 모듈에 의해 검색된 컴포넌트들 중에서 적합한 컴포넌트를 후보

아키텍쳐 내의 컴포넌트와 대체하여 아키텍쳐를 재구성함으로써 새로운 소프

트웨어 개발에 적용할 수 있다.

아키텍쳐 검색 방법을 이용하여 검색된 아키텍쳐들은 실제로 소프트웨어

개발에 적용할 수 있는 적합한 아키텍쳐가 아닐 수 있다. 따라서, 아키텍쳐의

재구성에 적합한 컴포넌트를 검색한 다음, 후보 아키텍쳐의 컴포넌트들을 검색

된 컴포넌트로 대체하여 새로운 아키텍쳐에 적용하여야 한다.

4.2 소프트웨어 개발을 위한 아키텍쳐 검색

이 절에서는 개발자의 질의와 구조적으로 일치하는 후보 아키텍쳐를 검

색하기 위한 아키텍쳐 검색 모듈을 설계 및 구현한다.

아키텍쳐 검색 모듈은 아키텍쳐 내에 존재하는 모든 컴포넌트의 수를 검

사하고, 컴포넌트에 의해 발생되는 메시지를 다른 컴포넌트로 전달하는 커넥터

85

의 개수를 비교하여 검색한다. 검색된 아키텍쳐는 소프트웨어 개발을 위한 아

키텍쳐의 재구성을 위해 사용된다.

[그림 4-4]는 아키텍쳐 검색 모듈이 소프트웨어 개발에 적합한 아키텍쳐

를 검색하기 위해 수행하는 과정을 순차 다이어그램으로 나타낸 것이다.

Count ComparisonModule

Type ComparisonModule

Compare Numberof Component

XML Query Form

Compare Numberof Connector usingparameter direction

RetrievedArchitectures

RetrievedArchitectures

TemporaryWorkspace

XML Query Form

CompareConnector TypeRetrieved

ArchitecturesTo Outside

[그림 4-4] 아키텍쳐 검색의 순차 다이어그램

아키텍쳐 검색 모듈은 개발자의 질의를 아키텍쳐 저장소에 저장되어 있

는 아키텍쳐와 비교하기 위해 두 가지의 모듈을 가진다. 하나는 아키텍쳐 내의

컴포넌트 개수와 커넥터의 개수를 비교하기 위한 개수 비교 모듈(Count

Comparison Module)이고, 다른 하나는 커넥터의 타입을 비교하기 위한 타입 비

교 모듈(Type Comparison Module)이다.

XML 형태로 변환된 개발자의 질의가 주어지면 개수 비교 모듈에 의해서

아키텍쳐를 구성하는 컴포넌트의 개수와 커넥터의 개수가 비교되고, 결과가 임

시 작업공간으로 전송된다. 그리고, 타입 비교 모듈에 의해서 커넥터의 타입을

86

비교하여 질의와 일치하는 아키텍쳐들을 아키텍쳐 저장소로부터 검색한다.

아키텍쳐 검색 모듈을 이용하여 검색된 아키텍쳐들은 실제로 소프트웨어

개발에 적용할 수 있는 아키텍쳐가 아닐 수 있다. 따라서, 아키텍쳐의 재구성

에 적합한 컴포넌트를 검색한 다음, 후보 아키텍쳐의 컴포넌트를 검색된 컴포

넌트로 대체하여 새로운 아키텍쳐에 적용하여야 한다. [알고리즘 1]은 소프트웨

어 개발을 위해 아키텍쳐 검색이 수행되는 아키텍쳐 검색 알고리즘이다.

[알고리즘 1] 아키텍쳐 검색 알고리즘

method Architecture Retrieval

Query Architecture : Q

Architecture Repository : AR

Candidate Architectures : C

Begin Architecture Match

Arch a := AR.getFirstArch();

flag = FIND_OK;

While (a != NULL)

If (a.getCompCount() == Q.getCompCount()) Then

If (a.getConnCount) >= Q.getConnCount()) Then

CompList QueryComps := Q.getSimpComps();

CompList ArchComps := a.getSimpComps();

ConnList ArchConnList := a.getConns();

For (i = 0; i < QueryComps.getSize(); i++)

SelectedComp := ArchComps.findWithName(QueryComps[i].name);

If (SelectedComp == NULL) Then

flag := MATCH_FAIL;

break;

End If

MsgList CompMsgList := QueryComps[i].getMsgs();

MsgList SCMsgList := SelectedComps[i].getMsgs();

For (j = 0; j < CompMsgList.getSize(); j++)

SelectedConn := SCMsgList.findWithReturn(CompMsgList[j].return);

If (SelectedConn != NULL) Then

87

If (SelectedConn.source != CompMsgList[i].source) Then

flag := MATCH_FAIL;

break;

End If

if (SelectedConn.target != CompMsgList[i].target) Then

flag := MATCH_FAIL;

break;

End If

End If

End For

if (flag == MATCH_FAIL) Then

break;

End If

End For

End If

End If

If (flag != MATCH_FAIL) Then

C.addArchitecture(a);

End If

a := AR.getNextArch();

End While

End Architecture Match

[알고리즘 1]에서 개발자 질의의 아키텍쳐는 Q, 저장소에 저장되어 있는

아키텍쳐들은 AR 그리고 아키텍쳐 검색 과정을 통해 검색된 아키텍쳐들은 C

로 표현된다.

소프트웨어 개발에 적합한 아키텍쳐 검색을 수행하기 위해 가장 먼저 수

행되는 과정은 저장소에 있는 첫번째 아키텍쳐를 검색하는 것이다. 그리고, 검

색된 첫번째 아키텍쳐를 대상으로 검색 과정의 모든 절차를 적용시킨다.

getCompCount( ) 메소드를 사용하여 개발자의 아키텍쳐 질의와 검색된 저장소

의 첫번째 아키텍쳐 내에 존재하는 컴포넌트 개수를 비교해서 일치 여부를 확

인하고, 커넥터에 대해서도 getConnCount( ) 메소드를 사용하여 동일한 과정을

88

수행하게 된다. 이 때, 개발자의 질의 아키텍쳐와 아키텍쳐 저장소내의 컴포넌

트 개수는 동일해야 하지만, 커넥터의 개수는 아키텍쳐 저장소의 아키텍쳐 커

넥터 개수가 개발자의 질의 아키텍쳐 커넥터 개수보다 많거나 동일하면 된다.

다음 과정으로 개발자의 질의 아키텍쳐와 저장소의 첫번째 아키텍쳐 내

의 단순 컴포넌트 리스트와 커넥터 리스트를 getSimpComps( ) 메소드와

getConns( ) 메소드를 사용하여 구성한다. 저장소의 첫번째 아키텍쳐 내의 단순

컴포넌트 리스트의 인스턴스인 ArchComps 의 findWithName( ) 메소드를 사용하

여 개발자의 질의 아키텍쳐 내의 단순 컴포넌트 명과 일치하는 컴포넌트가 검

색되면 이후 과정을 계속해서 수행하고, 그렇지 않으면 getNextArch( ) 메소드를

사용하여 아키텍쳐 저장소의 다음 아키텍쳐를 선택한다. 단순 컴포넌트 명이

일치하는 컴포넌트를 포함하는 아키텍쳐일 경우 단순 컴포넌트의 반환 타입과

단순 컴포넌트에 연결된 커넥터의 소스와 목표 컴포넌트에 대한 정보를 개발

자의 질의 아키텍쳐와 일치 여부를 비교하여 아키텍쳐를 검색하게 된다.

선택된 아키텍쳐가 모든 조건을 만족하면 이를 후보 아키텍쳐로 등록하

고, 아키텍쳐 저장소의 다른 아키텍쳐를 선택하여 동일한 과정을 통해 개발자

의 질의 아키텍쳐와 비교 과정을 계속해서 수행하게 된다.

4.3 아키텍쳐 재구성을 위한 컴포넌트 검색

이 절에서는 아키텍쳐 검색 모듈에 의해서 검색된 아키텍쳐의 재구성을

위해 필요한 컴포넌트 검색 모듈로써 시그니쳐 일치 검색 모듈과 행위 일치

검색 모듈을 설계 및 구현한다.

아키텍쳐 검색 모듈에 의해서 검색된 아키텍쳐를 소프트웨어 개발에 적

89

합한 아키텍쳐로 재구성하기 위해서는 컴포넌트 검색 방법을 사용하여 적절한

컴포넌트를 검색하고, 검색된 컴포넌트로 후보 아키텍쳐 내의 컴포넌트를 대체

하여 새로운 아키텍쳐를 구성한다. [그림 4-5]는 컴포넌트 검색 모듈인 시그니쳐

일치 검색 모듈과 행위 일치 검색 모듈에 의해서 컴포넌트를 검색하는 과정을

순차 다이어그램으로 표현한 것이다.

Signature MatchingModule

TemporaryWorkspace

Behavior MatchingModule

ComponentQuery

RetrievedComponents

ExactMatching

SelectedComponents

RetrievedComponents

RetrievedComponentsTo Outside

RelaxedMatching

RetrievedComponents

DiagValueGeneration

Execute withDiagVal

Verify withDiagVal

[그림 4-5] 컴포넌트 검색의 순차 다이어그램

아키텍쳐 검색 모듈에 의해 검색된 아키텍쳐 내의 컴포넌트들을 대체할

수 있는 적합한 컴포넌트 검색을 위해 개발자의 질의에서 시그니쳐 부분을 사

용하여 시그니쳐 검색을 수행하게 된다. 먼저 완전 일치에 의한 방법을 이용하

여 컴포넌트들을 검색하고, 검색된 컴포넌트들 중에서 요구에 부합되는 컴포넌

트가 없으면 이완 일치 방법으로 컴포넌트들을 검색하게 된다.

검색된 컴포넌트들 중에서 적절한 컴포넌트를 선택하지 못했을 경우 좀

더 요구에 정확한 검색을 위해 행위 일치 검색 모듈에 의한 검색을 수행하게

90

된다. 행위 일치 검색에 필요한 입력값과 출력값은 개발자가 임의로 설정하고,

설정된 입력값으로 가상 머신 상에서 평가기에 의해 수행한다. 평가기에 의해

수행을 종료한 후 개발자가 이미 설정해 놓은 출력값과 수행 결과값을 비교하

여 아키텍쳐 재구성에 적합한 컴포넌트들을 검색한다.

4.3.1 시그니쳐 일치 검색

시그니쳐 일치 검색 모듈은 컴포넌트 인터페이스에 존재하는 메소드의

파라미터 타입과 파라미터의 입출력 방향을 이용하여 컴포넌트 저장소로부터

개발자의 질의와 일치하는 인터페이스를 가진 컴포넌트를 검색한다.

완전 일치 방법은 컴포넌트 인터페이스의 파라미터 입출력 방향의 수와

개발자 질의의 파라미터 입출력 방향의 수가 일치할 경우 각 방향에 대한 타

입을 비교함으로써 컴포넌트를 검색하는 방법으로 타입이 일치하지 않을 경우

에는 이완 일치 방법에 의해서 검색을 수행한다.

완전 일치 방법을 이용한 컴포넌트 검색은 컴포넌트 저장소의 컴포넌트

파라미터 타입과 개발자 질의의 파라미터 타입이 정확하게 일치하는 컴포넌트

가 존재하는 경우에 사용할 수 있는 검색 방법이다. 완전 일치 방법을 사용하

여 컴포넌트를 검색할 경우 정확한 컴포넌트를 검색할 수는 있지만 소프트웨

어 개발에 이용될 수 있는 개발자의 질의와 유사한 컴포넌트를 검색할 수 없

으므로 개발자의 질의와 유사한 컴포넌트를 검색할 수 있는 타입 이완 일치

방법과 방향 이완 일치 방법으로 검색을 수행한다.

타입 이완 일치 방법은 컴포넌트 인터페이스와 개발자 질의의 비교 과정

에서 파라미터 입출력 방향의 수는 일치하지만 입출력 방향 타입이 질의와 다

른 컴포넌트들을 검색한다.

91

방향 이완 일치 방법은 컴포넌트 저장소의 컴포넌트 인터페이스와 개발

자 질의의 파라미터 입출력 방향 수가 일치하지 않을 때 입출력 방향의 수를

조정하여 일치시킨 후 각 방향의 타입을 검사하여 질의와 일치하는 컴포넌트

를 검색하는 방법이다.

시그니쳐 일치 검색 모듈은 개발자의 질의와 일치하는 컴포넌트를 검색

할 수도 있고, 행위 일치 검색을 수행하기 위한 컴포넌트 저장소의 크기를 줄

여주는 역할을 수행한다. 또한, 완전 일치를 통해 검색될 수 없는 컴포넌트를

검색할 수 있도록 하는 이완 일치 방법을 제공함으로써 검색의 재현율과 정확

성을 향상시킬 수 있다. [알고리즘 2]는 개선된 시그니쳐 일치 검색 방법을 사

용하여 컴포넌트를 검색하는 시그니쳐 일치 검색 방법의 알고리즘이다.

[알고리즘 2] 개선된 시그니쳐 일치 검색 알고리즘

Component Repository: R

Component: C

Query: Q

Begin Enhanced Signature Match

Incount := count(Q.InDirParam);

Outcount := count(Q.OutDirParam);

InOutcount := count(Q.InOutDirParam);

While((C := readComponentRepository(R)) != NULL)

rIncount := C.InDirParam;

rOUtcount := C.OutDirParam;

rInOutcount := C.InOutDirParam;

If ((Incount == rIncount) && (Outcount == rOutcount) &&

(InOutcount == rInOutcount)) Then

If (Exact Match(C, Q)) Then

Return C;

Else If (Type Relaxed Match(C, Q)) Then

Return C;

92

End If

Else If (Direction Relaxed Match(C, Q)) Then

Return C;

End If

End while

End Enhanced Signature Match

[알고리즘 2]에서 컴포넌트 저장소는 R, 컴포넌트는 C 그리고 개발자의

질의는 Q 로 표현된다. 개발자의 질의와 컴포넌트 저장소에 저장되어 있는 컴

포넌트 인터페이스의 입출력 방향에 따른 파라미터의 개수 검사는 count( ) 메

소드를 사용하여 수행한다.

각 방향성을 고려하여 파라미터를 비교한 결과의 파라미터 개수가 동일

한 컴포넌트에 대해서는 Exact Match( ) 모듈에 의한 완전 일치 방법이나 Type

Relaxed Match( ) 모듈에 의한 타입 이완 일치 방법을 적용하고, 동일하지 않을

경우는 Direction Relaxed Match( ) 모듈을 사용하여 방향 이완 일치 방법을 적용

한다. 컴포넌트 저장소의 모든 컴포넌트들을 대상으로 이 과정을 반복 수행함

으로써 아키텍쳐 재구성을 위해 적합한 컴포넌트를 검색한다.

[그림 4-6]은 시그니쳐 일치 검색 모듈이 아키텍쳐 재구성을 위해 컴포넌

트를 검색하는 순차 다이어그램을 나타낸 것이다.

시그니쳐 일치 검색 모듈은 아키텍쳐 재구성에 필요한 적절한 컴포넌트

검색을 위해 두 가지 모듈로 구성된다. 두 가지 모듈은 개발자의 질의와 컴포

넌트 인터페이스 상의 파라미터 개수를 비교하기 위한 개수 비교 모듈(Count

Comparison Module)과 타입을 비교하기 위한 타입 비교 모듈(Type Comparison

Module)이다.

개발자의 질의에서 컴포넌트 검색을 위한 컴포넌트 질의가 생성되면 질

93

의는 개수 비교 모듈에서 질의와 저장소의 컴포넌트 인터페이스간 입출력 방

향에 따른 파라미터 개수를 비교하게 된다. 개수 비교 결과 일치하는 컴포넌트

들에 대해 타입 비교 모듈은 입출력 각 방향에 대한 타입을 비교하게 된다.

Count ComparisonModule

Type ComparisonModule

Compare Parameteraccording to

in/out direction

Component Query

RetrievedComponentsTo Temporary

WorkspaceGeneralized

Match

SpecializedMatch

RetrievedComponents

RetrievedComponentsTo Temporary

Workspace

Arrange Numberof Parameters Retrieved

Components

CompareParameter Type

RetrievedComponentsTo Temporary

Workspace

[그림 4-6] 시그니쳐 일치 검색 모듈에 의한 컴포넌트 검색 과정

이 방법은 완전 일치 방법에 의한 검색 방법으로 검색된 컴포넌트들은

임시 작업공간에서 다음 작업을 위해 대기한다.

[알고리즘 3]은 완전 일치 방법에 의해 컴포넌트 검색을 수행하는 알고리

즘이다.

94

[알고리즘 3] 시그니쳐 일치의 완전 일치 검색 알고리즘

Component: C

Query: Q

Begin Exact Match

If(Exact Match(Q.eachDirType, C.eachDirType)) Then

Return true;

Else

Return false;

End If

End Exact Match

완전 일치 방법은 개발자의 질의와 컴포넌트 저장소에 있는 컴포넌트들

을 대상으로 입출력 방향성에 대한 파라미터의 개수를 비교한 결과 일치하는

컴포넌트에 대해 각각의 타입을 비교함으로써 수행된다. 개발자의 질의와 컴포

넌트 저장소의 컴포넌트들에 나타난 입출력 방향에 따른 파라미터 타입은

eachDirType 으로 표현되고, 상호간 일치 여부를 Exact Match( ) 모듈로 수행함으

로써 검색이 이루어진다.

완전 일치 방법보다 좀 더 유연한 방법을 사용하여 컴포넌트를 검색하기

위해 입출력 방향에 따른 파라미터 개수를 비교한 결과 일치하는 컴포넌트에

대해 각 방향에 대한 타입 비교에서 일반화 방법에 의한 검색과 특수화 방법

에 의한 검색 방법을 사용할 수 있다. 이 방법은 타입 이완 일치 방법에 의한

컴포넌트 검색 방법으로 검색된 컴포넌트들은 임시 작업공간으로 전달된다. [알

고리즘 4]는 타입 이완 일치를 수행하는 알고리즘이다.

[알고리즘 4] 시그니쳐 일치의 타입 이완 일치 검색 알고리즘

Component: C

Query: Q

95

Begin Enhanced Type Relaxed Match

If(Generalized Type Match(Q.eachDirType, C.eachDirType)) Then

Return true;

Else

If(Specialized Type Match(Q.eachDirType, C.eachDirType)) Then

Return true;

End If

Return false;

End If

End Enhanced Type Relaxed Match

[알고리즘 4]에서 타입 이완 일치 방법은 완전 일치 방법과 동일하게 개

발자의 질의와 컴포넌트 저장소의 컴포넌트들간 입출력 방향에 대한 파라미터

개수가 일치하는 컴포넌트를 대상으로 수행된다. 타입 이완 일치 방법은 개발

자의 질의와 저장소의 컴포넌트 입출력 방향에 대한 타입을 나타내는

eachDirType 에 대해 일반화 방법을 적용하는 Generalized Type Match( ) 모듈을 사

용하거나, 특수화 방법을 적용하는 Specialized Type Match( ) 모듈을 사용하여 컴

포넌트를 검색한다.

다음 과정으로 개발자 질의와 저장소의 컴포넌트 인터페이스의 입출력

방향에 따른 파라미터 개수가 일치하지 않을 경우 컴포넌트를 검색하는 방향

이완 일치 방법을 사용하여 컴포넌트를 검색하는 절차를 수행한다. 개수 비교

모듈은 입출력 방향에 따른 질의와 컴포넌트 인터페이스간 입출력 파라미터

개수의 차이가 동일한 컴포넌트에 대해 Inout 파라미터를 사용하여 전체 입출

력 파라미터 개수를 조정한다. 조정된 파라미터에 대해 타입 비교 모듈을 사용

하여 입출력 각 방향에 대한 파라미터 타입을 비교하게 된다. 검색된 컴포넌트

들은 임시 작업공간으로 전송되어 행위 일치 검색 방법을 위한 대상 컴포넌트

가 된다.

96

[알고리즘 5]는 방향 이완 일치 알고리즘을 나타낸 것이다.

[알고리즘 5] 시그니쳐 일치의 방향 이완 일치 알고리즘

Component: C[]

Query: Q

Begin Direction Relaxed Match

int i := j := 0;

inTemp := Incount – rIncount;

outTemp := Outcount – rOutcount;

inoutTemp := InOutcount – rInOutcount;

If ((inTemp == outTemp) && (inTemp == (-inoutTemp)) Then

C[i++] := R;

End If

While(C[j] == NULL)

If (!checkType(C[j].inType, Q.inType)) Then

j++;

Continue;

End If

If (!checkType(C[j].outType, Q.outType)) Then

j++;

Continue;

End If

If(!checkType(C[j].inoutType, Q.inoutType)) Then

j++;

Continue;

End If

If(compareType(C[j].inType, C[j].outType)) Then

If(compareType(C[j].inType, C[j].inoutType)) Then

Return true;

End If

End If

End While

End Direction Relaxed Match

97

[알고리즘 5]에서 방향 이완 일치 방법은 개발자의 질의와 컴포넌트 저장

소의 컴포넌트 인터페이스간 입출력 방향에 따른 파라미터 개수의 차이를 비

교하기 위해 입력, 출력 그리고 입출력 각각에 대한 파라미터 개수 차이를

inTemp, outTemp, 그리고 inoutTemp 변수에 저장한다.

그리고, 이 세 개의 변수에 대한 파라미터 개수 차이가 일치하는지를 비

교한 후 일치하는 저장소의 컴포넌트를 C 라고 표현된 컴포넌트 배열에 저장

한다. 다음 과정으로 방향성에 따른 파라미터 개수 차이의 일치 여부가 확인된

컴포넌트들을 대상으로 완전 일치 방법에서와 동일한 방법을 사용하여 개발자

의 질의와 컴포넌트 저장소의 컴포넌트 인터페이스 사이에 입출력 방향에 따

른 타입을 checkType( ) 메소드를 사용하여 비교한다.

개선된 시그니쳐 일치 검색 방법은 개발자의 질의와 일치하는 컴포넌트

를 검색할 수도 있고, 행위 일치 검색을 수행하기 위한 컴포넌트 저장소의 크

기를 제한하여 줄여주는 역할을 수행한다. 또한, 완전 일치를 통해 검색될 수

없는 컴포넌트를 검색할 수 있도록 하는 이완 일치 방법을 제공함으로써 검색

의 재현율과 정확성을 향상시킬 수 있다.

4.3.2 행위 일치 검색

행위 일치 검색 모듈은 개발자가 설정한 입력값을 사용하여 컴포넌트 인

터페이스를 직접 실행시켜 실행 결과값과 개발자가 설정한 출력값의 비교를

통해 일치하는 컴포넌트를 검색한다.

[그림 4-7]은 시그니쳐 일치 검색 모듈에 의해 검색된 컴포넌트들을 대상

으로 하여 행위 일치 검색을 수행하는 과정을 순차 다이어그램으로 표현한 것

이다.

98

DiagValue GenerationModule

EvaluatorModule

ExcuteUser Interface

Retrieved Componentsby Signature Matching

RetrievedComponentsTo Outside

Input Value

ComparisonModule

Output Value

Output Valueby Simulation

Varification

[그림 4-7] 행위 일치 검색 모듈에 의한 컴포넌트 검색 과정

시그니쳐 일치 검색 모듈에 의해 검색된 컴포넌트들을 대상으로 개발자

의 요구 사항과 구체적으로 일치하는 컴포넌트 검색을 위해 행위 일치 검색을

수행하게 된다. 행위 일치 검색 모듈은 개발자가 입력값과 출력값을 설정하는

모듈인 DiagValue Generation 모듈과 컴포넌트 저장소의 컴포넌트 인터페이스를

직접 실행하는 모듈인 Evaluator 모듈 그리고 개발자가 설정한 출력값과 실행

결과값을 비교하는 모듈인 Comparison 모듈로 구성된다.

DiagValue Generation 모듈에서 개발자가 설정한 출력값은 실행 결과값과

의 비교를 위해 Comparison 모듈로 전송된다. 다음 과정으로 DiagValue

Generation 모듈을 통해 개발자가 설정한 입력값을 가지고 Evaluator 모듈은 컴

포넌트 저장소의 컴포넌트 인터페이스를 직접 실행시킨다. 마지막으로 실행 결

과값과 개발자가 설정한 출력값을 비교하는 과정이 Comparison 모듈에서 수행

됨으로써 아키텍쳐 재구성을 위해 필요한 컴포넌트를 검색한다.

행위 일치 검색 방법은 시그니쳐 일치 검색 모듈에 의해 검색된 컴포넌

트들을 대상으로 하기 때문에 검색 시간 비용을 줄일 수 있고, 개발자가 직접

99

입력값과 출력값을 설정하기 때문에 검색의 재현율을 향상시킨다. 또한, 컴포

넌트의 기능적인 측면에서의 검색을 수행하기 때문에 검색의 정확성을 향상시

킨다.

[알고리즘 6]은 개선된 행위 일치 검색 방법에 의한 전체적인 컴포넌트

검색 과정에 대한 알고리즘이다.

[알고리즘 6] 개선된 행위 일치 검색 알고리즘

Component Repository: R

UserInputValue: I

UserOutPutValue: O

Component: C

Query: Q

ResultValue: V

Begin Enhanced Behavior Match

While((C := readComponetRepository(R)) != NULL)

V := Virtual_Machine(C, I);

If (O == V) Then

Return C;

End If

End While

End Enhanced Behavior Match

[알고리즘 6]에서 가상 머신 상에서 수행하기 위해 개발자가 설정한 입력

값은 I, 출력값은 O 그리고 수행 결과값은 V 로 표기하였다. 시그니쳐 검색 방

법에 의해 검색된 각각의 컴포넌트들을 대상으로 하여 개발자가 설정한 입력

값을 가지고 Virtual_Machine( ) 모듈로 표기된 가상 머신 상에서 직접 컴포넌트

인터페이스를 실행시키고, 그 결과값을 V 라고 표기된 변수에 저장한다. 다음

과정으로 실행 결과값과 개발자가 설정한 출력값 O 를 비교하여 일치하는 컴

100

포넌트들을 검색하게 된다.

4.4 명세 저장소와 웹 인터페이스

이 논문에서는 XML 형태의 아키텍쳐 명세와 컴포넌트 명세를 관리하기

위한 저장소로 관계형 데이터베이스 관리 시스템을 사용한다. 명세의 매핑은

객체 지향 데이터베이스 관리 시스템이 용이하나, 안정성과 XML 태그를 이용

한 검색에서 더 큰 효율을 나타내고 있는 관계형 데이터베이스 관리 시스템을

사용한다.

4.4.1 명세 저장소

소프트웨어 개발을 위한 아키텍쳐를 구성하는 각각의 엔티티들은 자신의

속성들을 가지며, 그들 사이의 관계로 정의될 수 있다. 컴포넌트 엔티티는 컴

포넌트 이름과 타입을 포함하며, 메시지와 인터페이스들을 포함한다. 인터페이

스와 시그니쳐를 컴포넌트 엔티티의 속성으로 정의하게 되면 다중치 종속성이

발생하게 되며, 커넥터 엔티티에서도 동일한 상황이 발생하게 된다.

마찬가지로 시그니쳐 엔티티에서도 파라미터를 속성으로 정의하게 되면

다중치 종속성이 발생하게 된다. 이 논문에서는 명세를 컴포넌트, 커넥터, 인터

페이스, 메시지 그리고 시그니쳐와 파라미터로 분해하여 정규화를 수행하였다.

[그림 4-8]은 명세 저장소의 관계형 데이터베이스 매핑을 위한 아키텍쳐와 컴

포넌트 명세에 대한 개체-관계도(Entity-Relationship Diagram)를 나타낸 것이다.

[그림 4-8]에서 컴포넌트 엔티티는 msg_list 라는 이름의 관계성을 통

해 메시지 엔티티와의 관계를 표현하고 있으며, int_list 관계성을 통해 인터페이

101

스 엔티티와의 관계가 표현된다. 같은 방법으로 파라미터 엔티티를 포함하는

시그니쳐 엔티티도 param_list 라는 관계성을 사용하여 표현하였다.

Component

Connector

Param_list

Interface Message

Parameterm 1

int_list msg_list

m m

11

numnum

num

name

name

name

name

name

type

type

type

direct

direct

ret_type

uses

src

dest

ArchitectureComp_list

Conn_list

m

1

m 1

Signature

name

id

id

id

id

id

id

signature_id signature_id

signature_id

[그림 4-8] 관계형 데이터베이스 매핑을 위한 개체-관계도

인터페이스와 메시지 그리고 커넥터 엔티티는 파라미터와 반환값의 타입

등이 정의되어야 하는데, 이를 표현하기 위해 파라미터 리스트를 갖는 시그니

쳐 엔티티의 식별자 값을 포함하도록 하였다.

또한, 아키텍쳐 엔티티는 하나의 독립적인 컴포넌트로 취급될 수 있으며,

포함되는 각각의 컴포넌트들과 커넥터들과의 관계가 정의되어 있다. 아키텍쳐

에 포함되는 커넥터들과 컴포넌트들은 커넥터 엔티티에 방향이 정의되어 있으

므로 생성 순서나 커넥터에 의한 방향성에 관계없이 저장될 수 있다.

아키텍쳐 명세와 컴포넌트 명세의 명세 저장소로서 관계형 데이터베이스

관리 시스템을 사용함으로써 시스템 관리 목적의 많은 특징들을 그대로 사

102

용할 수 있으며, 기존의 관계형 데이터베이스로의 저수준 접근(low level

accesses)을 허용한다. 또한, 관계형 데이터베이스 관리 시스템은 기본적으로

인덱싱(indexing), 질의(query) 그리고 네비게이션(navigation)과 같은 기능들을

제공하고 있으며, 트랜잭션을 처리하고 동시적인 작업을 처리하는 기능들을

제공한다. 이러한 기능들은 전체적인 시스템의 확장성과 관련해서 중요한 역

할을 수행한다.

일반적으로 DTD 라고 불리는 XML 메타 데이터는 데이터를 표현하고 서

로간 구조적 관계를 표현하기 위한 기능성을 제공할 수 있다. 즉, XML 메타

데이터는 계층적으로 표현되는 데이터 구조를 설계하는데 사용될 수 있다. 따

라서, 다른 저장소 모델들과의 호환을 고려할 때, XML 메타 데이터는 저장소

를 위한 유연성과 확장성을 제공할 수 있다.

개발자들은 XML 전용 브라우저와 CSS와 XSL 과 같은 스타일 시트를 사

용하여 저장소에 저장되어 있는 XML 명세서들을 브라우징할 수 있다. 개발자

들은 저장소의 명세서들을 관리하기 위해 고유의 XML 전용 브라우저를 사용

하여 이들을 시각화할 수 있다.

기존의 ActiveX 기술이나 DOM(Document Object Model)과 같은 프로그래밍

환경은 저장소 명세서들에 대한 웹 브라우징을 위해 스크립트와 같은 프로그

래밍을 제공할 수 있다. 이는 다양한 어플리케이션으로 하여금 일반화된 생산

방법을 사용할 수 있도록 한다.

이러한 기능들은 기존의 HTTP 프로토콜을 사용하여 HTML 문서들을 통

해 제공될 수 있으며, 이는 클라이언트 측에서 브라우징을 위한 어떠한 변환도

필요하지 않다는 것을 의미한다. 그러나, 개발자에 따라 관리 목적의 어떤 연

산들을 수행하기 위해 특수 목적의 전용 브라우저를 사용할 수도 있다.

103

4.4.2 웹 인터페이스

이 논문에서는 XML 형태의 아키텍쳐 명세와 컴포넌트 명세 그리고 이

러한 명세를 이용하여 아키텍쳐에 기반한 컴포넌트 검색 시스템을 설계 및 구

현하였다.

소프트웨어 개발에 필요한 아키텍쳐 검색을 위해 개발자가 작성한 질의

가 XML 형태로 변환되고, 질의를 바탕으로 하여 적절한 아키텍쳐가 검색되었

을 경우 이러한 개발자의 질의와 검색된 아키텍쳐를 구성하는 컴포넌트 및 커

넥터를 개발자가 웹 인터페이스를 통해 확인할 수 있는 방법이 제공되어야 한

다. 이를 위해, 아키텍쳐를 구성하는 컴포넌트와 커넥터에 대한 속성 정보들을

HTML 의 테이블 형식으로 표시하는 스타일 시트를 XSL 을 사용하여 정의하였

다.

XSL 은 구조적으로 표현되는 XML 데이터가 표현되는 방법에 대해 기술

하는 스타일 시트 언어이다. 스타일 시트 설계자는 XML 데이터의 표현을 위

해 스타일과 설계 방법 그리고 웹 브라우저와 같은 출력 매체를 결정해야 한

다. HTML과는 달리 XML의 요소들은 표현을 위한 내부적인 의미를 가지고

있지 않기 때문에 스타일 시트가 제공되지 않을 경우 XML 문서 내의 데이터

를 표시할 방법이 없다. 따라서, XSL 은 XML 문법을 기반으로 하는 스타일 시

트를 기술하기 위한 포괄적인 모델과 어휘들을 제공한다.

아키텍쳐 저장소와 컴포넌트 저장소에 저장된 XML 형태의 아키텍쳐와

컴포넌트의 XML 데이터 표현을 위해 XSL 을 사용하여 스타일 시트를 정의하

면 많은 이점을 얻을 수 있다. 우선 명세 내용을 다양한 출력 매체를 사용하여

나타낼 수 있으며, 명세 저장소의 아키텍쳐와 컴포넌트 속성 데이터의 재사용

104

성을 향상시킨다.

또한, XSL 은 XML 데이터 표현을 위한 표준화된 스타일을 제공한다. 그

리고, 하나 이상의 스타일 시트를 정의하였을 경우 웹 인터페이스를 통해 서로

다른 개발자에게 다른 스타일 시트를 적용함으로써 다양한 출력 형식으로 명

세 내용을 표현할 수 있다. XSL은 XML 형태의 아키텍쳐를 구성하는 컴포넌트

와 커넥터의 속성 정보에 대한 처리와 웹 브라우저를 통해 개발자에게 표현할

수 있는 쉽고 효율적인 접근 방법을 제공한다는 점에서 이 논문에서의 아키텍

쳐에 기반한 컴포넌트 검색 시스템을 위한 웹 인터페이스 설계에 효율적이다.

[리스트 4-1]은 특정한 아키텍쳐를 구성하는 컴포넌트와 커넥터의 속성들

을 저장하는 명세를 HTML 의 테이블 형태로 나타내기 위한 스타일 시트이다.

[리스트 4-1] 아키텍쳐 표현을 위한 스타일 시트

<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">

<xsl:template match="/">

<HTML>

<HEAD><TITLE><xsl:value-of select="component_architecture/name" /></TITLE>

<style>

BODY { font-family: Tahoma; font-size: 8pt }

TH { font-family: Tahoma; font-size: 8pt; background-color: #CCFFFF }

TD { font-family: Tahoma; font-size: 8pt; background-color: #FFFFCC }

A { font-family: Tahoma; font-size: 8pt; text-decoration: none; }

</style>

</HEAD>

<BODY>

<xsl:element name="H1">Query Architecture</xsl:element>

<xsl:element name="H3">Components</xsl:element>

<TABLE border="0" width="600">

<TR><TH width="100">name</TH><TH width="100">type</TH>

105

<TH width="200">messages</TH><TH width="200">signatures</TH></TR>

<xsl:for-each select="component_architecture/component" order-by="name">

<TR><TD><xsl:value-of select="name" /></TD>

<TD><xsl:value-of select="type" /></TD>

<TD><xsl:for-each select="msg_list/message" order-by="name">

<xsl:value-of select="name" />, </xsl:for-each></TD>

<TD><xsl:for-each select="int_list/interface" order-by="name">

<xsl:value-of select="name" />, </xsl:for-each></TD></TR>

</xsl:for-each>

</TABLE>

<xsl:element name="H3">Connectors</xsl:element>

<TABLE border="0" width="600">

<TR><TH width="100">name</TH><TH width="100">direction</TH>

<TH width="100">return type</TH><TH width="100">src comp</TH>

<TH width="100">dest comp</TH><TH width="100">parameters</TH></TR>

<xsl:for-each select="component_architecture/connector/signature "

order-by="name">

<TR><TD><xsl:value-of select="name" /></TD>

<TD><xsl:value-of select="direct" /></TD>

<TD><xsl:value-of select="return_type" /></TD>

<TD><xsl:value-of select="src" /></TD>

<TD><xsl:value-of select="dest" /></TD>

<TD><xsl:for-each select="param_list/parameter">

<xsl:value-of select="type" />, </xsl:for-each></TD>

</TR>

</xsl:for-each>

</TABLE>

<xsl:element name="H3">Used Signatures</xsl:element>

<xsl:for-each select="component_architecture/component/int_list/interface/signature "

order-by="name">

<xsl:value-of select="return_type" />

<xsl:value-of select="name" />(

<xsl:for-each select="param_list/parameter" order-by="name">

<xsl:value-of select="direct" /> <xsl:value-of select="type" />,

</xsl:for-each>)<BR></BR>

</xsl:for-each>

</BODY>

106

</HTML>

</xsl:template>

</xsl:stylesheet>

정의된 스타일 시트는 이 논문에서 아키텍쳐를 구성하는 컴포넌트와 커

넥터 명세에 사용된 모든 속성 정보를 웹 브라우저를 통해 HTML 페이지의

테이블 형식으로 표현될 수 있도록 XSL 을 사용하여 정의하였다. 저장소의

XML 명세서와 스타일 시트를 연결하기 위해 XML 명세서의 루트 태그를 참조

하는 xsl:template 태그를 선언하였으며, 테이블 형식의 표준화된 HTML 태그를

삽입함으로써 HTML 템플릿을 생성하였다.

반복적으로 명세되는 컴포넌트와 커넥터 그리고 파라미터 정보들을 표현

하기 위해 xsl:for-each 태그를 사용하였고, XML 문서에서의 구조적인 참조 위치

표현을 위해 select 속성을 사용하여 정의하였다. 반복적인 수행 과정에서 XML

명세서에 포함된 각각의 데이터 할당을 위해 xsl:value-of 태그를 사용함으로써

전체적인 스타일 시트를 구성하였다.

정의된 스타일 시트는 아키텍쳐를 구성하는 컴포넌트와 커넥터 명세의

모든 속성 정보를 웹 인터페이스를 통해 확인할 수 있도록 설계하였으나, 목적

에 따라 여러 개의 스타일 시트를 작성하여 데이터를 제한적으로 출력할 수도

있으며, 다른 출력 형식으로 표현이 가능하다.

107

제 5 장 실험 및 평가

이 장에서는 아키텍쳐에 기반한 컴포넌트 검색 방법이 타당함을 보이기

위해 제안한 XML 기반 명세 모델로 명세된 컴포넌트와 아키텍쳐를 이용하여

검색을 수행한다. 컴포넌트 검색은 사용자가 정의한 질의에 대해 아키텍쳐 검

색을 수행하고, 검색 결과로 선정된 후보 아키텍쳐들에 대해 아키텍쳐 재구성

을 위한 컴포넌트 검색을 수행하는 방법으로 진행된다. 또한, 제안한 아키텍쳐

에 기반한 컴포넌트 검색 방법의 효율을 평가하기 위하여 재현율과 정확성을

측정하였다.

5.1 실험 환경

제안한 아키텍쳐에 기반한 컴포넌트 검색 방법의 효율을 평가하기 위하

여 실험에 사용한 컴포넌트 명세는 Java 2 SDK 1.2 버전에서 제공하는 AWT

(Abstracted Window Toolkit)와 Javax 패키지의 사용자 인터페이스 클래스(User

Interface Class) 728 개 중에서 일부를 제안한 명세로 표현하여 사용하였고, 사용

자와의 상호작용에 관련된 클래스 구조들을 아키텍쳐로 정의하여 XML 기반의

컴포넌트 명세로 표현하여 사용하였다.

실험에서는 구현 환경에서와 같이 운영 체제로는 Windows NT Server 4.0

을 사용하였고, 관계형 데이터베이스 관리 시스템으로 MS SQL Server 7.0 을 사

용하였다. 인터넷에서의 사용자 인터페이스를 위해 IIS(Internet Information

Server) 4.0 를 사용하였고, 질의의 처리나 XML 문서 구성 그리고 사용자에게 보

여질 HTML 문서 구성과 변환을 위해 Active Server Page 를 사용하였다. 클라이

108

언트는 웹 브라우저로 Internet Explorer 5.0 을 사용하였다.

실험에서 사용한 사용자 인터페이스 컴포넌트의 개수는 총 322 개이며,

아키텍쳐 검색을 위해 일반적으로 사용되는 사용자 인터페이스 아키텍쳐 81 개

를 추가로 정의하여 아키텍쳐 저장소에 저장하였다. [그림 5-1]은 제안한 아키텍

쳐 기반 컴포넌트 검색 시스템의 실험 환경을 나타내고 있다.

Retrieved Component Group

ArchitectureMatching

QueryUserInterface

Retrieved User InterfaceArchitecture

Architecture Repository

Query SoftwareArchitecture

Generated Component Retrieval Query

Component Repository

Component Matching(Signature, Behavior)

UI CompA

UI CompC

UI CompB

[그림 5-1] 아키텍쳐 검색을 위한 실험 환경

5.2 아키텍쳐 기반 컴포넌트 검색 실험

소프트웨어 개발에 이용하는 아키텍쳐 검색을 위한 실험은 사용자 인터

페이스 아키텍쳐를 구성하기 위해 아키텍쳐 저장소에 저장된 사용자 인터페이

스 아키텍쳐를 대상으로 하여 개발자의 질의와 일치하는 사용자 인터페이스

109

아키텍쳐를 검색한다. [그림 5-2]는 질의를 입력하기 위한 사용자 인터페이스를

나타낸 것이다.

[그림 5-2] 질의 입력을 위한 사용자 인터페이스

개발자의 질의 입력을 위한 인터페이스는 IIS 4.0 에서 지원하는 ASP 와

Javascript 를 사용하여 작성되었으며, 아키텍쳐를 구성하는 컴포넌트와 커넥터에

대한 속성들은 추가할 때마다 해당되는 위치에서 추가하도록 구성되었다. 컴포

110

넌트와 인터페이스, 메시지 등의 속성들을 입력하기 위해서는 컴포넌트 목록에

서 원하는 컴포넌트를 더블 클릭하여 입력한다. 그리고, 커넥터와 시그니쳐, 파

라미터 등의 속성들을 입력하기 위해서는 커넥터 목록에서 해당 커넥터를 더

블 클릭하여 입력하도록 전체 질의 아키텍쳐 생성 인터페이스를 구성하였다.

개발자가 원하는 아키텍쳐를 검색하기 위해서 질의의 아키텍쳐 입력을

마치거나, 입력하는 동안에 개발자가 입력한 질의의 아키텍쳐 내용을 확인할

수 있다. [그림 5-3]은 질의 아키텍쳐의 내용 확인을 위한 인터페이스이다.

[그림 5-3] 질의 확인을 위한 사용자 인터페이스

질의 아키텍쳐의 입력이 완료되면, 입력된 질의를 아키텍쳐 검색 모듈로

전송하여 검색을 시작한다. [리스트 5-1]은 검색하고자 하는 아키텍쳐 질의가 입

력된 후 XML 형태로 생성된 아키텍쳐 질의의 일부를 나타낸 것이다.

111

[리스트 5-1] 아키텍쳐 질의의 예

<component_architecture><name>Query01</name>

<component><type>Simple</type><name>Button</name>

<int_list><num_of_int>1</num_of_int>

<interface> … <name>MsgC</name>

<param_list><num_of_param>1</num_of_param><signature>

… </param_list></signature></interface></int_list>

<msg_list><num_of_msg>1</num_of_msg>

<message><name>MsgA</name><signature>

<param_list><num_of_param>2</num_of_param>

… </param_list></signature></message></msg_list></component>

…

<connector><type>Variable</type><direct>Uni</direct>

… <name>MsgC</name><signature>

<param_list><num_of_param>1</num_of_param>

… <src>Button</src><dest>CompA</dest></connector>

…

<component><type>Variable</type><name>CompB</name>

<int_list><num_of_int>0</num_of_int></int_list>

<msg_list><num_of_msg>2</num_of_msg>

<message><name>MsgB</name><signature>

<param_list><num_of_param>1</num_of_param>

… </param_list></signature></message>

<message><name>MsgD</name><signature>

<param_list><num_of_param>1</num_of_param>

… </param_list></signature></message></msg_list></component>

…

</component_architecture>

[리스트 5-1]에서 아키텍쳐 검색을 위한 질의는 4 개의 컴포넌트와 5 개의

커넥터로 구성되어 있다. 2 개의 컴포넌트는 단순 컴포넌트로 아키텍쳐 재구성

에 사용될 수 있도록 저장된 컴포넌트들을 정의하였으며, 가변 컴포넌트인

CompA 와 CompB 는 저장소에서 검색되어 아키텍쳐에 포함되어야 하는 컴포넌

112

트들을 정의하였다. Dialog 컴포넌트는 Button 컴포넌트와 CompA 컴포넌트에

int 형의 메시지를 전달하고, CompB 컴포넌트에 char 형의 메시지를 전달한다.

Button 컴포넌트는 CompA 컴포넌트에 bool 형의 메시지를 전달하며, CompA 컴

포넌트는 CompB 컴포넌트에 string 형의 메시지를 전달하고, CompB 컴포넌트로

부터 이에 대한 응답을 받는 XML 형태로 생성된 질의이다. 파라미터의 방향은

정의되지 않았으므로 모두 기본값인 in 으로 정의되었다. 위와 같은 질의를 시

스템 내부 자료 구조로 표현하면 [그림 5-4]와 같은 구조를 갖는다.

VarConnector

MsgD(string)

Source CompA

Target CompB

Direct Uni

VarConnector

MsgB(char)

Source Dialog

Target CompB

Direct Uni

VarConnector

MsgA(int, int)

Source Dialog

Target Button

Direct Uni

Target CompA

Direct Uni

VarConnector

MsgE(int, int)

Source Dialog

VarConnector

MsgC(bool)

Source Button

Target CompA

Direct Uni

Dialog

Interface List

SimpleComp

MsgA(int, int)

MsgB(char)

MsgE(int, int)

CompA

Interface List

Message List

VarComp

MsgC(bool)

MsgD(string)

MsgE(int, int)

SimpleComp

Interface List

Message List

Button

MsgA(int, int)

MsgC(bool)

CompB

Interface List

Message List

MsgB(char)

MsgD(string)

VarComp

[그림 5-4] 질의의 내부 자료 구조

개발자에 의해서 작성된 질의는 아키텍쳐 저장소에 저장된 아키텍쳐를

대상으로 검색한다. 아키텍쳐 저장소에 저장된 아키텍쳐 내의 컴포넌트 수가

질의의 컴포넌트 수와 일치하는 지를 검사하고, 컴포넌트들 사이의 커넥터 수

를 비교하여 아키텍쳐 저장소에 있는 아키텍쳐 내의 커넥터의 수가 질의의 커

113

넥터 수보다 많거나 같은 아키텍쳐들만을 검색한다.

그리고, 검색된 아키텍쳐들 중에서 커넥터의 반환 타입과 방향이 같은

컴포넌트들로 구성된 아키텍쳐들을 검색한다. 커넥터의 방향은 커넥터로 연결

된 두 컴포넌트들 사이의 관련성을 정의하므로 검색된 중간 단계의 아키텍쳐

들 중에서 커넥터의 방향이 다른 것을 제외시킨다.

[그림 5-5]는 제안된 아키텍쳐 검색 방법을 이용하여 검색된 후보 아키텍

쳐들을 나타내는 인터페이스이다. 여기서, 후보 아키텍쳐들 중에서 Architecture3

을 선택할 경우 아키텍쳐를 구성하고 있는 컴포넌트들과 커넥터들에 대한 목

록을 나타내고 있다.

[그림 5-5] 후보 아키텍쳐 브라우징을 위한 인터페이스

질의에서 CompA 와 CompB 는 가변 컴포넌트로 정의되어 컴포넌트를 검

114

색하기 위한 방법으로 정의되었기 때문에 사용자 인터페이스들이 저장된 컴포

넌트 저장소로부터 컴포넌트를 검색하여 후보 아키텍쳐의 컴포넌트들과 대체

한다. 대체한 아키텍쳐가 정확하게 개발자가 요구하는 아키텍쳐일 경우에 소프

트웨어 개발을 위한 아키텍쳐 재구성에 사용한다.

후보 아키텍쳐들 중에는 개발자의 요구 사항과 일치하는 컴포넌트를 포

함하는 아키텍쳐들이 검색될 수 있지만, 만약 일치하지 않으면 요구 사항과 일

치하는 컴포넌트로 아키텍쳐를 재구성하기 위해 제안된 컴포넌트 검색 방법을

이용하여 컴포넌트들을 검색하여야 한다.

[그림 5-6] 후보 컴포넌트 브라우징을 위한 인터페이스

[그림 5-6]은 아키텍쳐를 구성하는 가변 컴포넌트인 CompA 를 대체할 수

있는 컴포넌트를 검색하기 위하여 컴포넌트 검색을 수행한 후의 결과 인터페

115

이스를 나타내고 있다. 제시되는 컴포넌트들 중에서 하나의 컴포넌트를 선택하

면, 해당 컴포넌트의 명세가 웹 브라우져 상으로 전달되어 개발자에게 보여진

다. 제시된 명세를 가지고 개발자는 요구와 일치하는 컴포넌트를 선택할 수 있

다.

후보 컴포넌트들은 질의에서 주어진 가변 컴포넌트 당 하나의 그룹으로

표시되며, 개발자는 각 가변 컴포넌트에 대체될 수 있는 컴포넌트들의 명세를

확인하여 선택할 수 있다. 컴포넌트 검색 시 아키텍쳐 검색에서 검색된 아키텍

쳐 구조 내에 포함된 컴포넌트에 대해서는 후보 컴포넌트로 간주한다.

[그림 5-7] 아키텍쳐 최종 선택을 위한 인터페이스

116

[그림 5-7]은 사용자 인터페이스 아키텍쳐의 구성을 위해 제안된 아키텍

쳐 검색과 컴포넌트 검색 방법을 이용하여 검색된 아키텍쳐를 개발자에게 보

여주는 인터페이스이다. 개발자는 선택한 아키텍쳐를 XML 파일 타입으로 저

장하거나, 다시 검색을 진행할 수 있다. 개발자는 아키텍쳐 재구성에 사용될

후보 아키텍쳐를 선택하고, 검색된 컴포넌트들을 대상으로 하여 아키텍쳐를 재

구성하여 요구와 일치하는 아키텍쳐인지를 검사한다.

[리스트 5-2]는 개발자가 선택한 아키텍쳐의 XML 명세 일부를 보여주고

있다.

[리스트 5-2] 개발자가 선택한 아키텍쳐 명세의 일부

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="component.xsl"?>

<component_architecture>

<name>Architecture3</name>

<component><type>Simple</type><name>Button</name>

<int_list><num_of_int>1</num_of_int>

<interface><name>Update1</name>

…</interface></int_list>

<msg_list><num_of_msg>2</num_of_msg>

<message><name>MouseClick1</name>…

<message><name>KeyDown1</name>

… </message></msg_list></component>

<component><type>Simple</type><name>Dialog</name>

<int_list><num_of_int>6</num_of_int>

<interface><name>MouseClick1</name>… </interface>

<interface><name>KeyDown1</name>… </interface>

<interface><name>MouseClick2</name>… </interface>

<interface><name>KeyDown2</name>… </interface>

<interface><name>MouseClick3</name>… </interface>

<interface><name>KeyDown3</name>… </interface></int_list>

<msg_list><num_of_msg>0</num_of_msg><message/></msg_list></component>

117

<component><type>Simple</type><name>List</name>

<int_list><num_of_int>2</num_of_int>

<interface><name>Update2</name>… </interface>

<interface><name>RequestData</name> … </interface></int_list>

<msg_list><num_of_msg>4</num_of_msg>

<message><name>MouseClick2</name>… </message>

<message><name>KeyDown2</name> … </message>

<message><name>Update1</name>… </message>

<message><name>RequestData</name>… </message></msg_list></component>

<component><type>Simple</type><name>TextField</name>

<int_list><num_of_int>1</num_of_int>

<interface><name>RequestData</name> … </interface></int_list>

<msg_list><num_of_msg>4</num_of_msg>

<message><name>MouseClick3</name>… </message>

<message><name>KeyDown3</name> … </message>

<message><name>Update2</name>… </message>

<message><name>RequestData</name>… </message></msg_list></component>

<connector><type>Simple</type><direct>Uni</direct><name>MouseClick1</name>

<signature>… </signature><src>Dialog</src><dest>Button</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>MouseClick2</name>

<signature>… </signature><src>Dialog</src><dest>List</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>MouseClick3</name>

<signature>… </signature><src>Dialog</src><dest>TextField</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>KeyDown1</name>

<signature>… </signature><src>Dialog</src><dest>Button</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>KeyDown2</name>

<signature>… </signature><src>Dialog</src><dest>List</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>KeyDown3</name>

<signature>… </signature><src>Dialog</src><dest>TextField</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>Update1</name>

<signature>… </signature><src>Button</src><dest>List</dest></connector>

<connector><type>Simple</type><direct>Uni</direct><name>Update2</name>

<signature>… </signature><src>List</src><dest>TextField</dest></connector>

<connector><type>Simple</type><direct>Bi</direct><name>RequestData</name>

<signature>… </signature><src>List</src><dest>TextField</dest></connector>

</component_architecture>

118

5.3 재현율과 정확성 측정

[표 5-1]은 특정한 컴포넌트를 아키텍쳐 내에 포함시켜 검색하는 경우와

컴포넌트 검색만 수행하는 경우의 실험 수행 결과를 구분하여 정리한 것이다.

여기서, 컴포넌트 검색만 수행한 경우는 기존의 검색 방법을 적용하여 수행하

였고, 아키텍쳐 검색 방법을 병행한 검색에서는 이 논문에서 제안한 아키텍쳐

검색 방법을 적용하여 컴포넌트 검색 방법인 파라미터의 방향성을 이용한 개

선된 시그니쳐 일치 검색 방법과 행위 일치 검색 방법을 사용하였다.

[표 5-1] 실험 결과

컴포넌트 검색만 수행 아키텍쳐 검색을 병행아키텍쳐 내검색할

컴포넌트 수 재현율 정확성 비교 재현율 정확성비교

(+81)

4 1 0.25 322 1 0.69 81 + 38

7 0.75 0.34 322 0.77 0.71 81 + 63

11 0.67 0.43 322 0.68 0.68 81 + 81

17 0.65 0.52 322 0.69 0.71 81 + 87

20 0.7 0.41 322 0.75 0.58 81 + 91

22 0.73 0.6 322 0.78 0.75 81 + 99

27 0.63 0.69 322 0.71 0.8 81 + 128

31 0.6 0.85 322 0.75 0.93 81 + 137

35 0.5 0.64 322 0.67 0.69 81 + 156

38 0.37 0.77 322 0.62 0.8 81 + 167

• 비교 : 컴포넌트 일치 수행 횟수(아키텍쳐 검색을 병행한 경우 아키텍쳐

일치 수행 회수 81 을 추가)

[그림 5-8]은 아키텍쳐 검색을 이용한 경우에 컴포넌트 검색의 재현율과

119

정확성을 검색하고자 하는 아키텍쳐 내에 포함되는 컴포넌트의 개수에 대한

관련성을 표시한 그래프이다. 그래프에서 점선은 컴포넌트 검색만을 수행하여

측정한 결과를 나타내고, 실선은 아키텍쳐 검색을 병행하여 수행한 결과를 나

타낸다.

0

0.5

1

N(Comp)

Rec

all

With Architecture MatchingComponent Matching Only

0

0.5

1

N(Comp)

Pre

cisi

on

With Architecture Matching

Component Matching Only

[그림 5-8] 아키텍쳐 기반 검색과 기존 컴포넌트 검색의 비교(1)

120

[그림 5-8]에서 아키텍쳐 내에 컴포넌트 개수가 증가함에 따라 재현율과

정확성이 기존 방법보다 높은 것을 볼 수 있다. 이는 다량의 컴포넌트를 동시

에 검색하는 경우, 각각의 컴포넌트를 단독으로 검색하는 것보다 소프트웨어

개발을 위해서 아키텍쳐 개념을 도입함으로써 구조 단위의 검색을 수행할 수

있도록 하는 것이 더 효율적임을 나타내고 있다.

[그림 5-9]는 아키텍쳐 기반 검색 방법과 기존 컴포넌트 검색 방법의 재

현율과 정확성을 비교한 그래프를 나타낸 것이다.

0

0.9

0.3 1Recall

Pre

cisi

on

With Architecture Matching

Component Matching Only

[그림 5-9] 아키텍쳐 기반 검색과 기존 컴포넌트 검색의 비교(2)

실험 결과, 이 논문에서 제안한 아키텍쳐 검색 방법과 컴포넌트 검색 방

법을 병행하여 검색을 수행할 경우 검색할 컴포넌트의 개수를 줄임으로써 컴

포넌트 검색만을 수행한 결과에 비해 재현율과 정확성을 높였으며, 아키텍쳐에

포함된 컴포넌트와 커넥터의 수가 많을수록 정확성이 증가함을 알 수 있다.

[표 5-2]는 검색 효율의 평가 기준에 따른 실험 결과를 나타낸 것이며, [표

121

5-3]은 제안한 검색 방법과 기존의 검색 방법들을 검색 효율의 평가 기준에 따

라 상대적으로 비교한 것이다.

[표 5-2] 검색 효율 평가 기준에 따른 평가

평가 기준 평가 내용

재현율아키텍쳐 내 검색될 컴포넌트 개수가 많을수록 기존 방법보다

재현율 증가

정확성아키텍쳐 내 검색될 컴포넌트 개수가 많을수록 기존 방법과 차

이가 근소해짐

시간 복잡성아키텍쳐 개념을 적용하여 비교 회수 감소

아키텍쳐가 많아지는 경우 아키텍쳐 검색을 위한 오버헤드 증가

자동화행위 일치 검색을 위한 입력값과 출력값 생성을 제외한 전 부분

자동화 가능

[표 5-3] 기존 검색 방법과의 비교

재현율 정확성 시간 복잡성 자동화

시그니쳐 일치 낮음 높음 높음 가능

명세서 일치 높음 높음 높음 어렵다

행위 일치 높음 높음 낮음 어렵다

제안한 방법 높음 높음 높음 가능

시간 복잡성 측면에서, 제안한 검색 방법은 아키텍쳐 검색과 시그니쳐

일치 검색 그리고 행위 일치 검색을 병행하므로 높게 평가되었다. 그러나, 제

안된 아키텍쳐에 기반한 검색 방법을 기존의 시그니쳐 일치 검색과 행위 일치

검색 방법와 비교하면, 시간 복잡성은 상대적으로 높아 질 수가 있다는 단점이

있다.

122

제 6 장 결 론

이 논문에서는 컴포넌트 기반 소프트웨어 개발에서 컴포넌트의 효율적인

검색을 고려해 아키텍쳐와 컴포넌트를 명세하기 위한 XML기반의 컴포넌트

명세 모델을 제안하였다. 또한, 제안한 XML 기반의 컴포넌트 명세 모델을 이

용하여 검포넌트를 검색할 수 있는 개선된 컴포넌트 검색 방법을 제안하여 객

체 지향 응용 개발에서 이용할 수 있는 아키텍쳐에 기반한 컴포넌트 검색 시

스템을 설계하고, 프로토타입 검색 시스템을 구현하여 실험을 통해 제안한 검

색 방법의 타당성을 입증하였다.

제안한 컴포넌트 명세 모델에서는 구현을 고려한 정형화된 명세 언어의

복잡성을 줄이고, 개발자에게 쉬운 접근 방법을 제공하기 위해 시그니쳐 명세

와 기능 명세로 구성되는 컴포넌트의 명세를 XML 형태로 정의하였다. 컴포넌

트 명세를 XML 형태로 정의함으로써 컴포넌트 명세 요소들은 계층적인 구조를

가지며, 개발자는 계층적인 뷰를 통해 이 구조를 확인할 수 있다.

또한, XML 문서의 유효성은 DTD 에 사용된 태그들과 데이터 타입을 정

의함으로 유지된다. 이러한 XML의 장점을 통해 명세 문서 관리의 효율이 개

선됨과 동시에 블랙 박스 재사용을 지원하게 되었다. 이 논문에서 제안한

XML 기반의 컴포넌트 명세 모델을 이용하여 아키텍쳐 명세를 기술함으로써

구조적인 재사용을 지원할 수 있다.

그리고, 제안된 아키텍쳐 검색 방법은 아키텍쳐의 기능적인 측면에서 보

다는 구조적인 측면에서 개발자의 요구에 일치하는 아키텍쳐를 검색할 수 있

다. 검색된 아키텍쳐 재구성을 위해 아키텍쳐 내에 컴포넌트를 대체할 수 있는

123

컴포넌트를 검색하기 위해서 개선된 시그니쳐 일치 검색 방법과 행위 일치 검

색 방법을 제안하였다.

아키텍쳐 검색을 이용하여 아키텍쳐를 검색한 후, 아키텍쳐 재구성을 위

해 컴포넌트를 검색하도록 함으로써 컴포넌트 검색의 범위를 제한하여 컴포넌

트 검색의 재현율과 정확성을 향상시키고, 일치 수행을 위한 비교 횟수를 줄임

으로써 검색 수행 시간을 단축시켰다. 또한, 소프트웨어 개발을 위한 아키텍쳐

와 컴포넌트의 재사용성을 향상시켰다.

그러나, 아키텍쳐에 포함된 컴포넌트의 개수가 많아짐에 따라 재현율은

많은 향상이 있었으나, 검색 시간과 정확성은 기존의 검색 방법보다 월등한 향

상을 보이지는 못했다. 이는 아키텍쳐 기반 컴포넌트 검색 시에 요구되는 아키

텍쳐와 저장소의 아키텍쳐들과 컴포넌트 저장소의 컴포넌트들이 많아지게 되

는 경우에 재현율과 정확성 그리고 검색 시간의 단축을 위해서는 아키텍쳐를

구성할 때, 기존에 명세되어 있는 아키텍쳐들을 재사용함으로써 계층적인 아키

텍쳐를 구성함으로써 극복할 수 있다.

제안한 명세 모델과 아키텍쳐에 기반한 검색 방법의 특성 및 기능은 다

음과 같다.

컴포넌트 명세 모델은 아키텍쳐도 하나의 컴포넌트라는 관점으로 명세에

접근하며, 컴포넌트와 컴포넌트 간의 관련성을 컴포넌트 간에 주고받는 메시지

로 정의하여 XML 기반의 아키텍쳐 명세와 컴포넌트 명세 모델을 제안하였다.

이러한 아키텍쳐 명세는 구조적인 재사용, 즉 화이트 박스 재사용을 지원할 수

있게 하고, 컴포넌트 명세는 컴포넌트 기능을 명세함으로써 블랙 박스 재사용

을 지원할 수 있게 하였다.

124

아키텍쳐 검색 방법은 소프트웨어 아키텍쳐의 개념을 적용하여 소프트웨

어의 구조적인 측면에서 소프트웨어 개발을 위한 아키텍쳐들을 검색한다. 이는

아키텍쳐 저장소내에 존재하는 모든 컴포넌트의 수를 검사하고, 컴포넌트에 의

해 발생되는 메시지를 다른 컴포넌트로 전달하는 커넥터의 개수를 비교하여

아키텍쳐를 검색함으로써 소프트웨어 재구성을 위해 사용될 수 있음을 보였다.

시그니쳐 일치 검색 방법은 아키텍쳐 검색 방법에 의해서 검색된 아키텍

쳐들이 개발자의 요구와 일치하지 않을 경우 아키텍쳐 재구성을 위해 컴포넌

트 인터페이스에 존재하는 메소드의 파라미터 타입과 파라미터의 입출력 방향

을 이용하여 컴포넌트 저장소로부터 개발자의 질의와 일치하는 인터페이스를

가진 컴포넌트를 검색하게 하였다. 이는 아키텍쳐 재구성에 필요한 컴포넌트를

검색할 수도 있고, 행위 일치 검색을 수행하기 위한 컴포넌트 저장소의 크기를

제한하여 줄여주는 역할을 하여 일치 수행 횟수를 줄일 수 있음을 보였다.

행위 일치 검색 방법은 시그니쳐 일치 검색 방법에 의해서 검색된 컴포

넌트들을 대상으로 하여 아키텍쳐 재구성에 필요한 좀 더 구체적인 컴포넌트

를 검색하여 재현율과 정확성이 향상됨을 입증하였다.

앞으로의 연구는 보다 완벽한 컴포넌트 검색 시스템으로의 발전을 위하

여 다음과 같은 연구가 필요하다.

(1) 컴포넌트와 아키텍쳐의 분류 등의 보완 작업을 통해 해당되는 질의의

크기를 조절하는 방법에 대한 연구가 요구된다.

(2) 컴포넌트 저장소에서의 컴포넌트들간의 통합 과정을 위한 연구가 필

요하다.

(3) 개발자의 요구에 일치하는 컴포넌트가 검색되었을 때 적합성을 검증

125

하기 위한 체계적인 테스트 과정에 대한 연구가 필요하다.

(4) 컴포넌트 분류 체계에 따라 명세할 수 있는 자동화된 명세 지원에 관

한 연구가 필요하다.

(5) 보다 완벽한 컴포넌트 검색 시스템으로의 발전을 위해 분산 공동 작

업 환경에서의 적용에 관한 추가적인 연구가 필요하다.

126

참고 문헌

[Abo93] G. Abowd, R. Allen and D. Garlan, “Using style to understand

descriptions of software architecture,” Proceedings of SIGSOFT’93:

Foundations of Software Engineering, Software Engineering notes, Vol.18,

No.5, pp.9-20, Dec., 1993.

[All92] R. Allen and D. Garlan, “Toward Formalized Software Architecture,”

Carnegie Mellon University, School of Computer Science, Technical Report

CMU-CS-92-163, Jul., 1992.

[All97] R.J. Allen, “A Formal Approach to Software Architecture,” Ph.D. Thesis,

Carnegie Mellon University, 1997.

[Atk94] Steven Atkinson and Roger Duke, “Behavioural Retrieval from Class

Libraries,” Australian Computer Science Communications, Vol.17, No.1,

pp.13~20, Jan., 1995. An extended version appears as Software Verification

Research Center Technical Report 94-28, 1994.

[Atk97] Steven Atkinson, “Examining Behavioural Retrieval,” Proceedings of the

8th Workshop on Institutionalizing Software Reuse(WISR8), Electronically

Published., Mar., 1997.

[Bar97] Dirk Bartels, “A Scalable XML Repository,” http://www.poet.com/xml,

Nov., 1997.

[Big89] T. J. Biggerstaff, Software Reusability Vol.1: Concepts and Models, ACM

Press, New York, 1989.

[Boe81] B. W. Boehm, Software Engineering Economics, Prentice Hall,

Englewood Clifss, NJ., 1981.

[Boo94] G. Booch, Object Oriented Analysis and Design Applications, Benjamin

Cumming Publishing Company, 1994.

127

[Bro96] Alan W. Brown, “Foundations for Component-Based Software

Engineering,” http://computer.org/cspress/CATALOG/BP07718/reface.htm,

1996.

[Bro98] Alan W. Brown and K. C. Wallnau, “The Current State of CBSE,” IEEE

Software, pp.37-46, Sept./Oct., 1998.

[Bry92] D. Bryan, “Rapide-0.2 language and tool-set overview,” Technical Note

CSL-TN-92-387, Computer System Laboratory, Stanford University, Feb.,

1992.

[But96] Shawn Butler, David Diskin, Norman Howes and Kathleen Jordan,

“Architectural Design of a Common Operating Environment,” IEEE Software,

pp.57-65, Nov., 1996.

[Cle94] P. Clements and P. Kogut, “The Software Architecture Renaissance,” The

Journal of Defense Software Engineering, Vol.7, 1994.

[Dea95] Yhomas R. Dean and James R. Cordy, “A Syntactic Theory of Software

Architecture,” IEEE Transactions on Software Engineering, Vol. 21, No.4,

pp.302-313, Apr., 1995.

[Dia87] R. Prieto Diaz and P. Freeman, “Classifying Software for Reusability,”

IEEE Software, Vol.4 No.1 pp.6-16, Jan., 1987.

[Edd98] Guy Eddon and Henry Eddon, Inside Distributed COM, Microsoft Press,

1998.

[Gar93] D. Garlan and M. Shaw, “An Introduction to Software Architecture,”

Advances in Software Engineering and Knowledge Engineering, Vol.1, World

Scientific Publishing Co., Singarpore, 1993.

[Gar95] D. Garlan and D. E. Perry, “Introduction to the Special Issue on Software

Architecture,” IEEE Transactions on Software Engineering Vol.21, No.4,

pp.269-274, Apr., 1995.

[Gar97] D. Garlan and R. Allen, “A Formal Basis for Architectural Connection,”

128

ACM Transactions on Software Engineering and Methodology, Vol.6, No.3,

Jul., 1997.

[Gri97] Richard Grimes, Professional DCOM Programming, Wrox Press, 1997.

[Gut85] J. V. Guttag, J. J. Horning and J. M. Wing, “The Larch Family of

Specification Languages,” IEEE Software Vol.2, No.5, pp.24-36, Sep., 1985.

[Gut91] J. V. Guttag and J. J. Horning, “A Tutorial on Larch and LCL, a Larch/C

Interface Language,” Proceeding of VDM91: Formal Software Development

Methods, S. Prehn and W.J. Toetenel (eds.), Delft, Oct., 1991.

[Gut93] J. V. Guttag and J. J. Horning, Larch: Language and Tools for Formal

Specification, Texts and Monographs in Computer Science. Springer-Verlag,

New York, NY, Jan., 1993.

[Hal93] R. J. Hall, “Generalized behavior-based retrieval,” Proceedings of 15th

International Conference on Software Engineering, pp. 371-380, May, 1993.

[Hog98] Mike Hogan, “Defining A Scalable Database for XML,”

http://www.poet.com/xml, Mar., 1998.

[Inn99] InnerView XML Search System, Techno2000 Project, Inc.,

http://xml.t2000.co.kr/ products/guide.html, Aug., 1999.

[Jen94] J.J. Jeng and B.H.C. Chang, “A Formal Approach to Reusing More

General Components,” Proceedings of IEEE 9th Knowledge-Based Software

Engineering Conference, Monterey, California, pp. 90-97, Sep., 1994.

[Jen95] J.J. Jeng and B.H.C. Chang, “Specification Matching for Software Reuse:

A Foundation, “ ACM Symposium Software Reuse, pp.97-105, Apr., 1995.

[Kaz96] Rick Kazman, Gregory Abown, Len Bass and Paul Clements, “Scenario-

Based Analysis of Software Architecture,” IEEE Software, PP.47-55, Nov.,

1996.

[Kha97] R. Khare and A. Rifkin, “X Marks the Spot,” http://www.cs.caltech.edu

/~adam/papers/xml/x-marks-the-spot.html, 1997.

129

[Kir98] M. Kirtland, Designing Component-Based Applications, Microsoft Press,

1998.

[Koz98] Wojtec kozaczynski and G. Booch, “Component-Based Software

Engineering,” IEEE Software, pp.34-36, Sept./Oct., 1998,

[Kru92] C. W. Krueger, “Software Reuse,” ACM Computing Surveys, Vol.24, No.2,

1992.

[Lee99] Y. S. Lee and C. J. Wang, “Software Component Retrieval System using

Agents,” First International Workshop on Mobile Agents for

Telecommunication Applications(MATA'99), pp. 431-438, Oct., 1999.

[Lee2000] Yoonsoo Lee, Kyungseob Yoon and Changjong Wang, “Component

Retrieval Based on Architecture for Reuse,” Proceedings on 16th

International Federation for Information Processing(The 16th IFIP World

Computer Congress), Aug., 2000.

[Low98] M. R. Lowry, “Component-based Reconfigurable Systems,“ IEEE

Computer, Vol.31, No.4, pp.44-45, Apr., 1998.

[Luc95] D. C. Luckham, J. J Kenney and L. M. Augustin, “Specification and

Analysis of System Architecture Using Rapide,” IEEE Transactions on

Software Engineering, Vol.21, No.4, pp.336-355, Apr., 1995.

[Maa91] Y. S. Maarek, D. M. Berry and G. E. Kaiser, “An Information Retrieval

Approach For Automatically Constructing Software Libraries,” IEEE

Transactions on Software Engineering, Vol.17, No.8, pp.800-813, Aug., 1991.

[Med98] N. Medvidovic, D. S. Rosenblum and R. N. Taylor, ”A Type Theory for

Software Architectures,” Technical Report UCI-ICS-98-14, Department of

Information and Computer Science, University of California, Irvine, Apr.,

1998.

[Med99] N. Medvidovic, D. S. Rosenblum and R. N. Taylor, “A Language and

Environment for Architecture-Based Software Development and Evolution,”

Proceeding of the 21st International Conference on Software Engineering,

130

L.A., May, 1999.

[Mil94] A. Mili, R. Mili and R. Mittermeir, “Storing and Retrieving Software

Components: A Refinement Based System,” Proceedings 16th International

Conference on Software Engineering, IEEE Computer Society Press, pp.91-

100, May, 1994.

[Mil95] H. Mili, F. Mili and A. Mili, “Reusing Software: Issues and Research

Directions,” IEEE Transactions on Software Engineering, Vol.21, No.6,

pp.528-562, Jun., 1995.

[Mil97] A. Mili, R. Mili and R. Mittermeir, “A Survey of Software Components

Storage and Retrieval,” The Institute for Software Research Technical Report,

17, 1997.

[OMG98] Object Management Group Inc., Proposal to the OMG OA&DTF RFP 3,

http://www.omg.org/cgi-bin/doc?ad/98-10-06, Oct., 1998.

[OMG99] Object Management Group Inc., CORBA Component Model RFP,

http://www.omg.org/techprocess/meetings/schedule/CORBA_Component_M

odel_RFP.html, Feb., 1999.

[Par99] W.J. Pardi, XML in Action-Web Technology, Microsoft Press, 1999.

[Pen95] J. Penix, P. Baraona and P. Alexander, “Classification and Retrieval of

Reusable Components using Semantic Features,” proceedings of the 10th

Knowledge Based Software Engineering Conference, pp.131-138, Nov., 1995.

[Pen96] J. Penix and P. Alexander, “Efficient Specification based Component

Retrieval, “ Technical Report, University of Cincinnati, Knowledge Based

Software Engineering Laboratory, ECE CS, Jul., 1996.

[Pen97] J. Penix and P. Alexander, “Toward Automated Component Adaptation,”

Proceedings of the 9th International Conference on Software Engineering

and Knowledge Engineering, Knowledge Systems Institute, pp.535-542, Jun.,

1997.

131

[Pen98] J. Penix, “Automated Component Retrieval and Adaptation Using Formal

Specifications,” Ph.D Dissertation, University of Cincinnati, Apr., 1998.

[Per93] D. E. Perry and S. S. Popovich, “Inquire: Predicate-based Use and

Reuse,” Proceedings of Knowledge Based Software Engineering, pp.144-151,

Sep., 1993.

[Pod92] A. Podgurski and L. Pierce, “Behavior sampling: A Technique for

automated retrieval of reusable components,” Proceedings of 14th

International Conference on Software Engineering, pp.11-15, May, 1992.

[Pod93] A. Podgurski and L. Pierce, “Retrieving Reusable Software by Sampling

Behavior,” ACM Transactions on Software Engineering and Methodology,

Vol.2, No.3, pp.286-303, Jul., 1993.

[Poe97] Poet Software, The Poet XML Repository, http://www.poet.com/xml,

Nov. 1997.

[Rap94] Rapide Design Team, “The Rapide-1 Architectures Reference Manual,”

Program Analysis and Verification Group, Computer System Laboratory,

Stanford University, Oct., 1994.

[Rob95] J. E. Robbins, E. J. Whitehead Jr., N. Medvidovic and R.N. Taylor, “A

Software Architecture Design Environment for Chiron-2 Style Architectures,”

Arcadia Technical Report UCI-95-01, University of California, Irvine, Jan.,

1995.

[Rol91] E.J. Rollins and J.M. Wing, “Specification as search keys for software

libraries,” Proceeding of International Conference on Logic Programmings,

Paris, Jun., 1991.

[Ros97] Wilhelm Rossak, Vassilka Kirova, Leon Jololian, Harold Lawson and

Tamar Zemel, “A Generic Model for Software Architectures,” IEEE Software,

pp.84-92, Jul./Aug., 1997.

[SEI99] Software Engineering Institute of Carnegie Mellon University,

http://www.sei.cmu.edu/architecture/definitions.html, Dec., 1999.

132

[Sha95a] M. Shaw, “Architectural Issues in Software Reuse: It’s Not Just the

Functionality, It’s the Packaging,” IEEE Symposium on Software Reuse, IEEE

Press, New York, 1995.

[Sha95b] M. Shaw, T. L. Ross, D. M. Young and G. Zelesnik, “Abstractions for

Software Architecture and Tools to Support Them,” IEEE Transactions on

Software Engineering, Vol.21, No.4, pp.314-335, Apr., 1995.

[Szy98] Clemens Szyperski, Component Software: Beyond Object-Oriented

Programming, Addison-Wesley, 1998.

[Tay96] R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. Whiteshead Jr.. J. E.

Robbins, K. A. Nies, P. Oreizy and D. L. Dubrow, “A Component-and

Message-Based Architectural Style for GUI Software,” IEEE Transactions on

Software Engineering, Vol.22, No.6, Jun., 1996.

[Zar93] A. M. Zaremski and J. M. Wing, “Signature Matching: A Key to Reuse,”

Technical Report CMU-CS-93-151, Carnegie Mellon University, May, 1993.

[Zar95a] A. M. Zaremski and J. M. Wing, “Signature Matching: A Tool for Using

Software Libraries,” ACM Transactions on Software Engineering and

Methodology, Vol.4, No.2, pp.146-170, Apr., 1995.

[Zar95b] A. M. Zaremski and J. M. Wing, “Specification Matching of Software

Components,” Proceedings of the 3rd ACM SIGSOFT Symposium on the

foundations of software engineering, pp.6-17, Oct., 1995.

[Zar96] A. M. Zaremski, “Signature and Specification Matching,” School of

Computer Science Carnegie Mellon University Technical Report CS-CMU-96-

103, 1996.

[Zar97] A. M. Zaremski and J. M. Wing, “Specification Matching of Software

Components,” ACM Transactions on Software Engineering and Methodology,

Vol.6, No.4, pp.333-369, Oct., 1997.

[김 99] 김원기, 안치돈, 이윤수, 왕창종, “XML 기반의 컴포넌트 명세 언어,”

한국정보과학회, 추계학술발표논문집, Oct., 1999.

133

[권 99] 권태삼, 이윤수, 윤경섭, 왕창종, “XML 명세에 기반한 소프트웨어 컴포

넌트 검색,” 한국정보과학회, 추계학술발표논문집, Oct., 1999.

[이 2000] 이윤수, 윤경섭, 왕창종, “재사용을 위한 XML 기반 소프트웨어 아키

텍쳐 명세 언어,” 한국정보처리학회, 정보처리논문지, Vol.7, No.3, Mar.,

2000.

감사의 글

오늘 제가 이 논문을 완성하기까지는 많은 사람들의 도움과 수고가

있었습니다. 그 분들에게 이 자리를 빌어 감사의 마음을 전하고자 합니다.

먼저, 학부와 대학원 석⋅박사과정의 10여년을 학문과 인격 도야에 길

을 열어주신 왕창종 지도교수님께 깊은 감사를 드립니다. 왕창종 교수님

의 도움이 없었다면 학위 논문과 오늘의 저는 없었을 것입니다. 지금까지

많은 지도 편달을 해주시고, 평소에 보여주신 학문, 인생관과 사랑의 가

르침은 제 일생을 살아가는데 큰 줄기가 될 것입니다.

평소 깊은 관심과 애정으로 논문을 지도해 주신 배해영 교수님께 깊

은 감사를 드립니다. 그리고, 학문 연구에 바쁘신 중에도 기꺼이 논문 심

사를 맡아주시고, 지도하여 주신 조근식 교수님께 감사드립니다. 전자계

산공학과 이균하 교수님, 양용준 교수님, 유원희 교수님, 이정현 교수님,

이필규 교수님, 한창호 교수님, 김유성 교수님, 김기창 교수님께도 감사드

립니다.

학문 연구에 바쁘신 중에도 기꺼이 논문 심사를 맡아주시고, 논문 심

사 과정에서 부족한 점을 일깨우쳐 주심과 동시에 자상한 지도를 아끼지

않으신 충북대학교의 구연설 교수님과 숭실대학교의 류성렬 교수님께 깊

은 감사를 드립니다.

선배로써 평소에 많은 조언을 해주시고, 깊은 관심과 배려로 인격적

으로 성숙될 수 있도록 이끌어주신 인하공업전문대학의 윤경섭 박사님과

이세훈 박사님께 진심으로 감사드리며, 멀리서 격려를 보내주신 충청대

학의 진영배 박사님, 신흥대학의 김남용 박사님께도 감사드립니다.

논문 작성 과정에서 많은 밤을 새워가며 도와준 소프트웨어 공학 연

구실의 안치돈, 김상길군에게 감사의 마음을 전합니다. 또한, 함께 학위를

받게되는 탁진현 선생과 다음 논문을 위해 열심히 준비하는 고희창 선배

님과 이승근군에게 좋은 결과가 있을 것으로 기대하고, 석사 과정의 이대

규, 장진윤, 한인구군에게도 감사합니다. 그리고, 그동안 두터운 교분과

우애로 같이 지내왔던 이용준 선배님, 강운구 교수님, 이재호 교수님, 윤

경배 교수님, 백영태 교수, 서대우 교수에게도 이 자리를 빌어 감사 드립

니다.

이 논문이 있기까지 많은 배려를 해주신 안산공과대학의 강성락 학장

님께 진심으로 감사를 드립니다. 또한, 박덕재 사무국장님, 김운선 교무처

장님, 지의상 학생처장님, 소봉암 서무행정처장님께 감사드리고, 전산정

보과의 김숙영 교수님, 이순희 교수님, 김진봉 교수님, 강우준 교수님께도

감사드립니다.

늘 바쁘다는 핑계로 자주 찾아뵙지 못하고, 오늘 제가 있기까지 한 없

는 사랑으로 보살펴주신 부모님께 이 논문으로 감사의 마음을 전합니다.

그리고, 가까이서 항상 격려를 아끼지 않으신 장인어른과 장모님께 이 자

리를 빌어서 깊은 감사를 드립니다. 형님과 형수님,동생들, 처제와 처남

에게도 감사합니다.

끝으로, 학위 과정동안 어려울 때마다 옆에서 힘이 되어 주고, 화목한

가정을 만들어 준 사랑스러운 나의 아내에게 이 논문을 선물하고 싶습니

다. 그리고, 많은 시간을 함께하지 못했던 아빠를 항상 따르며, 예쁘고 건

강하게 자라는 딸 예주와 이 기쁨을 나누고자 합니다.

모든 사람들과 기쁨을 나누고 싶은 날, 연구실에서…

2000년 6월