자바 리플렉션과 메소드 오버로딩을 활용한 상황인지 툴킷kiise.or.kr/e_journal/2012/1/SA/pdf/02.pdf · 장 및 재사용하기 어려운 문제점이 있다

12 정보과학회논문지 : 소프트웨어 및 응용 제 39 권 제 1 호(2012.1)

․본 논문은 2010학년도 목포대학교 교내연구비 지원에 의하여 연구되었음

† 정 회 원

논문접수

심사완료

:

:

:

목포대학교 컴퓨터공학과 교수

[email protected]

2011년 4월 27일

2011년 11월 21일

CopyrightⒸ2012 한국정보과학회ː개인 목적이나 교육 목적인 경우, 이 저작

물의 전체 또는 일부에 대한 복사본 혹은 디지털 사본의 제작을 허가합니다.

이 때, 사본은 상업적 수단으로 사용할 수 없으며 첫 페이지에 본 문구와 출처

를 반드시 명시해야 합니다. 이 외의 목적으로 복제, 배포, 출판, 전송 등 모든

유형의 사용행위를 하는 경우에 대하여는 사전에 허가를 얻고 비용을 지불해야

합니다.

정보과학회논문지: 소프트웨어 및 응용 제39권 제1호(2012.1)

자바 리플렉션과 메소드 오버로딩을 활용한 상황인지 툴킷

(A Toolkit for Context-aware Systems

using Java Reflection and Method Overloading)

최 종 명 †

(Jongmyung Choi)

요 약 본 논문은 jContext라는 자바 기반의 객체지향 상황인지 툴킷에 대해서 소개한다. jContext는

브랜치와 트리거형 상황인지 서비스를 지원하며, 네 가지 특징을 갖고 있다. 첫째는 상황을 클래스로 표현

하는 것이고, 둘째는 상황에 따라 달라지는 오퍼레이션을 코드 조각이 아닌 모듈화된 메소드 단위로 기술

하고, 동일한 의미의 메소드들을 첫 번째 매개변수를 상황 클래스를 갖는 메소드 오버로딩으로 표현하는

것이다. 셋째, 클래스 외부에서 메소드 호출은 자바 리플렉션을 통해서 상황에 적합한 오버로딩된 다른 메

소드를 자동적으로 호출하도록 구성되어 있다. 넷째로 jContext는 계층형 아키텍처와 기능별 모듈화를 통

해서 컴포넌트의 교체, 확장 등이 가능하도록 하였다. jContext의 이러한 특징은 새로운 상황 추가, 기존

API 지원, 기존 시스템을 상황 인지 시스템으로 재사용 및 확장 등의 유연성 및 확장성을 제공하는 장점

이 있다.

키워드 : 상황인지, 툴킷, 리플렉션, 오버로딩, 자바

Abstract In this paper, we introduce a Java-based, object-oriented toolkit for context-aware

systems named jContext. It supports branch style and trigger style context-aware services, and it has

four interesting features. First, it represents contexts as classes in the programming language. Second,

it represents the different operations executed according to contexts as methods, rather than code

fragments, thus allowing the operations to be modular. In addition, methods with the same semantics

are represented by method overloading, and have a context class as their first parameter. Third,

method calls from outside of class are business logic-oriented and don't have any context class

parameters. Internally, these method calls automatically invoke other context-related methods using

Java reflection. Fourth, jContext adopts a layered architecture, and its functional units are modular, so

that each of them is replaceable and extensible. These features allow jContext to be flexible and

extensible, so that it supports new contexts, allows existing APIs to be context-aware, and extends

the existing systems into context-aware systems.

Key words : Context-aware, Toolkit, Reflection, Overloading, Java, jContext

1. 서 론

상황인지 시스템(context-aware systems)에 관한 관

심이 높아지면서 이를 쉽게 구현할 수 있는 툴킷(toolkit)

[1], 프레임워크(framework)[2,3], 미들웨어[4]에 관한

관심도 높아지고 있다. 현재까지 상황인지 서비스를 위

한 다양한 툴킷 및 프레임워크가 개발되었지만, 시스템

유연성, 확장성, 기존 시스템 지원 등에서 부족한 점이

있었다. 구체적으로 툴킷의 기능적인 모듈성 부족, 상황

에 따라 수행하는 오퍼레이션 코드의 단편화에 따른 모

듈성 부족, 상황에 따른 오퍼레이션 수행이 if-then과

같은 하드 코드로 표현되어 있기 때문에 이를 수정, 확

자바 리플렉션과 메소드 오버로딩을 활용한 상황인지 툴킷 13

장 및 재사용하기 어려운 문제점이 있다.

본 논문은 객체지향 프로그래밍 환경에서 시스템의

유연성, 확장성 및 기존 시스템을 상황인지 시스템으로

확장할 수 있는 jContext라는 상황인지 툴킷을 구현한

내용을 소개한다. 프로그래밍 APIs 관점에서 볼 때

jContext는 다음과 같은 특징을 갖고 있다. 첫째로

jContext는 상황을 클래스로 표현하고, 이 클래스의 멤

버 필드로 상황과 관련된 정보를 표현한다. 둘째로 브랜

치(branch)형 상황인지 서비스[5](즉, 상황에 따라 호출

되는 메소드가 다른 경우)에서 메소드들을 오버로딩을

통해서 표현한다. 예를 들어, doX()라는 서비스가 있다

면, 상황A와 상황B에 대해서 각각 doX(ContextA

cntxt), doX(ContextB cntxt)라는 오버로딩 메소드들을

정의하고, 상황에 따른 서비스 내용을 메소드에 정의한

다. 현재 상황이 결정되면, 메소드 호출은 메소드 오버

로딩 방식에 따라서 doX(ContextA cntxt) 혹은 doX

(ContextB cntxt)가 호출된다. 기존 툴킷들은 if-then

문장을 이용해서 메소드를 직접 호출하는 방식을 사용

하였는데, 이는 추후 시스템을 수정 및 확장하기 어려운

문제점을 갖고 있다. 셋째로 상황인지 메소드를 호출하

는 클라이언트는 상황에 관련된 정보를 모르는 상태에

서 메소드를 호출할 수 있다. 즉, 위의 예에서 클라이언

트는 매개 변수가 없는 doX() 메소드를 호출하고,

jContext 내부적으로 자바의 리플렉션을 통해서 현재의

상황을 파악하고, 이를 바탕으로 자바 오버로딩을 통해

서 현재 상황에 해당되는 메소드를 호출한다. 넷째로

jContext는 계층형(layer) 아키텍처를 사용하고, 기능에

따라서 모듈화되었기 때문에 특정 컴포넌트를 교체 및

확장할 수 있는 구조로 되어 있다. 특히, 상황 추론기를

응용 분야에 따라 적합한 알고리즘을 구현한 것으로 교

환할 수 있다.

jContext는 상황인지 컴퓨팅분야의 발전에서 다음과

같은 기여를 한다. 첫째로 브랜치형 상황인지 서비스를

메소드 오버로딩을 통해서 구조적으로 기술함으로써 시

스템 개발을 체계화할 수 있도록 한다. 이는 브랜치형

상황인지 서비스가 의미적으로 동일한 서비스이지만, 상

황에 따라 다른 구현 메소드가 호출되는 개념을 제시

및 구체화함으로써 상황인지 시스템 분석, 설계 및 구현

시에 상황인지 서비스를 구조적으로 기술할 수 있도록

한다. 둘째로 브랜치형 상황인지 메소드들은 서비스의

커스터마이징, 새로운 센서 도입 등에 따라 기존 상황인

지 메소드를 확장해야 할 필요성들이 존재하는데, 이때

메소드들을 서브 클래스에서 재정의(overriding)할 수

있기 때문에 시스템 유연성, 확장성, 재사용성이 높아지

는 장점을 갖고 있다. 셋째로 클라이언트에서 호출하는

메소드는 상황에 관련된 매개변수가 없기 때문에 기존

시스템의 API를 변경하지 않고, 상속과 일부 메소드 구

현을 통해서 상황인지 서비스로 변환할 수 있다.

본 논문은 2장에서 기존 상황인지 서비스에 관련된

프레임워크 및 미들웨어 시스템들을 소개하고, 기존 시

스템들과 jContext의 유사성과 차이점을 기술한다. 3장

에서는 jContext의 이론적인 배경을 기술하고, 4장에서

시스템 구현에 관해서 기술한다. 5장에서는 jContext 시

스템을 테스트 및 평가한 내용을 기술하고, 6장에서 결

론을 밝힌다.

2. 관련연구

상황인지 시스템과 관련된 툴킷 혹은 미들웨어에 관한

연구들 중에서 대표적인 것으로는 Dey[1]의 Context

Toolkit, Bardram[2]의 JCAF, Román[4]의 Gaia,

Tanter[3]의 Reflex 등이 있다. 상황인지 시스템을 위한

툴킷을 상황 표현, 상황인지 서비스 선택 방법, 추론 방

법을 기반으로 분석하면 다음과 같은 특징들을 갖고 있다.

Context Toolkit[1]은 GUI 시스템 개발에 활용된 위

짓(widget)이라는 개념을 상황인지 시스템 개발에 도입

한 툴킷이다. Context Toolkit은 상황을 센서 타입(이

름)과 값으로 표현하며, 추론은 if 문장에서 이름과 값의

매칭을 통해서 이루어지고, 상황인지 서비스로 스위치는

if-then 문장을 통해서 이루어진다. Context Toolkit은

주로 자바 언어를 이용해서 구현하였으며, 위짓 개념을

통해서 센서 값 인지와 상위 계층을 분리하는 장점을

갖고 있지만, 상황 표현과 추론 기능이 프로그램 내부에

if-then 문장으로 하드 코딩되어 있어서 유연성과 확장

성이 떨어지는 단점이 있다.

Java Context Awareness Framework(JCAF)[2]는

자바 언어를 기반으로 객체지향 방법으로 구현한 상황

인지 프레임워크이다. JCAF의 특징은 상황 정보를

ContextItem 클래스로 표현하고, 상황을 ContextItem

을 포함하는(composition) 클래스로 표현한다는 점이다.

상황 변화에 따른 메소드 호출을 지원하기 위해 이벤트

드리븐 방식을 지원하고 있다. Context Toolkit과 유사

하게 상황 추론이 값의 비교를 통해서 이루어지고, 상황

에 따른 메소드 호출 역시 if-then 방식의 코드를 사용

한다는 점에서 유연성 및 확장성이 떨어진다.

Gaia[4]는 메타 운영체제로 불리는 유비쿼터스 컴퓨

팅 환경을 위한 미들웨어 플랫폼으로 상황인지 시스템

을 위한 기능을 제공한다. Gaia에서는 상황을 Context

(, , , )

라는 서술 논리로 표현한다. Relator는 관계 연산자(=,

>,


표 1 기존 상황인지 툴킷과 본 연구의 비교

툴킷

특성Context Toolkit JCAF Gaia Reflex 본 연구

상황의 의미 센서 값ContextItem으로

구성된 클래스

고차원 개념

(서술 개념)

고차원 개념

(명사 개념)

고차원 개념

(명사 개념)

상황표현 이름-값 객체 서술 논리 관점(aspect) 클래스

프로그래밍 객체지향 객체지향 스크립트언어 관점지향 객체지향

추론 방법 값 매칭(if 문) 값 매칭(if 문) 논리 추론 값 매칭 다양한 알고리즘 지원

분기 방법 if-then 문 if-then 문 알려지지 않음 포인트컷의 논리식 오버로딩, 리플렉션

상황 범위 하드 코드 하드 코드 규칙 집합 하드 코드 하드 코드, 규칙 집합

분산 시스템여부 분산 객체(RMI) 분산 객체(RMI) 분산 객체(CORBA) - -

Reflex[3]는 관점지향 프로그래밍(AOP: aspect-oriented

programming)의 개념에서 상황인지 기능을 추가한 것

이다. Reflex에서는 상황을 관점(aspect)으로 표현하고,

상황에 따른 메소드들을 AOP의 포인트컷의 추가적인

메소드 호출 방법으로 해결하고 있다.

표 1은 본 연구에서 구현한 jContext와 기존에 연구

된 툴킷 시스템들의 유사한 점과 차이점들을 보여준다.

표 1에서 볼 수 있듯이 상황에 대한 개념은 Reflex와

본 연구에서는 사람이 생각하는 형태의 명사형태의 개

념을 사용하는 반면에 Gaia는 서술 형태의 개념을 사용

한다. Context Toolkit의 경우에는 센서 값을 상황으로

인지한다. 상황을 프로그램에서 표현하는 방법으로는

jContext는 상황을 클래스로 표현하는 반면에 Reflex는

관점(aspect)으로, Gaia는 서술 논리, Context Toolkit

은 센서 이름과 이들의 값을 이용한다. 추론 방법에서는

대부분 값을 비교해서 상황을 추론하는 반면에 Gaia는

서술 논리 추론을 사용하고, jContext는 서술 논리 추론

과 값 비교 등의 알고리즘을 지원한다.

3. 객체지향 관점에서 상황 표현

3.1 상황의 정의

“상황(context)”이라는 용어에 대해서 분야에 따라 많

은 정의와 의미가 있으며, 유비쿼터스 컴퓨팅 분야에서

도 연구자들에 따라서 다른 정의를 내리고 있다. 유비쿼

터스 및 상황인지 컴퓨팅 분야에서 가장 널리 인용되고

있는 정의는 Dey[6]의 “Context is any information

that can be used to characterize the situation of an

entity”이지만, 이는 구체적인 정보 및 이를 구조적으로

분석하는 정형성이 부족하다. 따라서 본 논문에서는

Dey[6]와 본 연구의 사전 연구[5]에서 정의한 상황을

좀 더 구체적인 객체지향 프로그래밍 관점에서 재정의

하고, 이를 바탕으로 상황인지 시스템 툴킷을 설계 및

구현한다.

우선 가장 먼저 상황인지 서비스를 정의하도록 하자.

상황인지 서비스란 상황에 따라 서비스 내용 혹은 사용

자에게 전달되는 방법이 달라지는 서비스를 의미하며,

상황 정보를 활용하는 형태에 따라서 5가지 유형으로

분류[5]할 수 있다. 본 논문에서 소개하는 jContext는

트리거(trigger)와 브랜치(branch) 유형의 상황인지 서

비스를 대상으로 한다.

정의 1. 상황인지 서비스

상황인지 서비스는 상황에 따라 내용 혹은 표현이 달

라지는 서비스를 의미한다.

본 논문에서는 상황을 서비스에 영향을 주는 주변 정

보들에 대한 해석으로 정의한다. 이를 기술하기 위해서

첫 번째 단계로 시스템 및 사용자 주변 정보들은 “주변

요소(surrounding elements)”로 정의한다.

정의 2. 주변요소

주변요소란 상황인지 시스템 내부, 외부, 사용자 관련

정보의 원천을 의미한다. □

상황인지 시스템의 주변요소는 무한히 많다. 하지만,

이렇게 많은 주변요소들 중에서 대부분은 시스템과 무

관하고, 오직 일부분만이 시스템 서비스에 영향을 미친

다. 즉, 많은 정보들 중에서 관심을 가져야 할 것은 서

비스에 영향을 미치는 주변요소들이다. 이처럼 상황인지

시스템의 주변요소들 중에서 시스템의 서비스에 영향을

미칠 수 있는 정보들은 “상황 속성(context attribute)”

이라고 한다. 상황 속성은 실제 시스템에서 센서 값 혹

은 사용자 프로파일 등의 시스템 내부의 값들로 구현될

수 있다. 대표적인 상황 속성의 예로는 위치, 시간, 사용

자 프로파일 정보 등이 있다.

정의 3. 상황 속성

상황 속성 ai는 상황인지 서비스에 영향을 주는 단일

개념의 주변요소이다. 상황 속성 집합 A는 A = { a | a

→ f, f ∊ F ∧ a ∊ R }이다. 단, F는 상황인지 서비스들의 집합이고, R는 주변요소들의 집합이다. →는 영

향을 미친다는 의미이다. □

상황 속성을 구체적으로 분석해보면, 상황인지 시스템

에서 서비스를 결정하는 것은 상황 속성들의 값이다.

즉, 임의의 시간 t에 상황 속성들의 값이 상황을 구성하


며, 이것이 서비스를 결정한다. 예를 들어, 시간, 위치,

사용자라는 상황 속성을 사용하는 여행자 가이드 시스

템이 존재한다면, 12시 10분에 미국 여행자가 종로 2가

에 있을 때 이 시스템은 종로 2가 근처에서 미국 여행

자들이 점심 식사로 선호하는 식당에 대한 정보를 영어

로 제시할 것이다. 그러나 만약 오후 4시라면, 이 시스

템은 다른 볼 만한 곳 혹은 차를 마실 수 있는 곳에 대

한 정보를 먼저 제시할 것이다.

위의 예에서 볼 수 있듯이 상황인지 시스템의 서비스

를 결정하는 것은 상황 속성의 값이고, 이러한 관점에서

볼 때 상황, 상황 속성, 상황 속성 값, 서비스의 관계는

그림 1과 같이 표현할 수 있다. 그림에서 시스템에 영향

을 주는 상황 속성은 시간, 위치, 사용자라고 했을 때

각 상황 속성은 다양한 값을 가질 수 있다. 이때 동일한

서비스 결과를 가져오는 상황 속성 값들의 모임을 상황

라고 한다. 즉, 그림에서 시간 속성의 값은 T1 혹은 T2

이고, 위치의 값은 L2이고, 사용자의 값은 U2일 때 X

상황이다. 그림 1에서 S는 개념 수준에서 본 상황인지

시스템의 서비스 이름이고, S1과 S2는 상황에 따라 실제

서비스되는 구체적인 서비스 내용이다.

T: 시간, L: 위치, U: 사용자, S: 서비스

그림 1 상황 속성, 상황, 상황인지 서비스의 관계

상황 속성들의 값이 주어졌을 때 이것이 어떤 상황인

지 여부를 결정하는 것은 각 사용자의 판단(해석) 혹은

사회적인 동의에 의해 결정된다. 개인에 혹은 문화에 따

라서 동일한 조건이라도 다른 상황으로 인식하는 것은

모두 해석의 차이 때문이다. 따라서 상황이란 상황 속성

값들에 대한 해석으로 이해할 수 있으며, 이는 정의 4와

같이 표현할 수 있다.

정의 4. 상황

상황 c는 시간 t1..tn 동안에 상황 속성 값들(a1, ...,

am)을 상황 추론 함수 f로 해석한 값이다. 즉, c = f(a1,

..., am)t1..tn 로 표현할 수 있다. 단, n ≧ 1 이고, m ≧

1 이다. □

정의 4에서 a1, ..., am는 상황 속성 값들을 의미하고,

t1..tn는 일정 시간 간격을 의미한다. 즉, 어떤 경우에는

어떤 순간(n=1인 경우)의 상황 속성 값을 통해서 상황

을 판단하기도 하지만, 또 다른 경우에는 일정 시간 간

격 동안(n > 1인 경우) 파악된 속성 값들을 통해서 상

황을 판단할 수도 있다. 예를 들어, 마이크를 이용한 음

성 인식이나 카메라를 통한 사용자 인식 혹은 행동 인

식 등은 일정 시간 동안 값을 읽어야 상황을 파악할 수

있다.

정의 4에 따르면, 상황 c는 상황 속성 값들의 집합임

과 동시에 의사소통의 단위인 어떤 구체적인 값을 의미

하며, 이 값을 결정하는 것은 상황 속성 값과 상황 추론

함수 f이다. 예를 들어, “덥다”, “회의중”, “서비스 가능”

등은 모두 어떤 서비스에 대한 상황을 의미하는데, 이러

한 값을 추론하기 위한 근거 혹은 규칙이 필요하다. 이

러한 근거 혹은 규칙을 “상황 범위(context boundary)”

라고 하고, 정의 5와 같이 정의한다.

정의 5. 상황 범위

상황 범위는 상황을 추론하기 위한 상황 속성들 값으

로 기술한 규칙 혹은 근거를 의미한다. □

상황 범위가 주어진 경우에 상황 추론 함수는 상황

속성들 값을 이용해서 상황을 추론한다. 이때 상황 추론

함수는 어떤 시간에 주어진 상황 속성들이 어떤 상황

범위에 소속되는지 여부를 판단하는 집합의 멤버 함수

이다.

정의 6. 상황 추론 함수

상황 추론 함수 f는 상황 속성 값을 입력으로 받고,

해당 속성 값들이 소속된 상황을 파악하는 함수이며, f:

(a1,...,am)t1..tn -> ci 로 표현할 수 있다. 이때 ak ∈ A,

A는 상황 속성의 집합이고, ci ∈ C, C는 시스템에서

사용하는 상황 집합이다.

3.2 상황 모델링

3.1절에서 상황이라는 개념을 상황 속성 값과 해석이

라는 측면을 통해서 정의하였다. 정의된 상황을 어떻게

모델링하고, 표현할 것인가가 툴킷 개발 및 상황인지 시

스템 개발에서 매우 중요한 문제이다. 그 동안 상황인지

시스템에서 상황을 표현하고 모델링하기 위한 많은 연

구들이 진행되었다. 일부 연구에서는 상황을 이름-값의

쌍[1]으로 표현하고, 어떤 시스템에서는 서술 논리[4],

객체[2], 온톨로지 문서[7] 등으로 표현한다. 기존 시스

템들에 대한 상황 모델링에 대한 조사는 Strang[8]에

의해서 자세히 연구되었다.

본 논문에서는 상황을 클래스로 표현한다. 클래스의


그림 2 상황 클래스 모델

멤버 필드들은 상황 속성을 의미한다. 다음 그림 2는 상

황 클래스와 속성들의 관계를 보여준다. IEntity는 현재

상황의 소유자를 의미하는 엔티티이다. 즉, 현재 시스템

에서 관심을 갖는 현재 상황이 누구(혹은 무엇)의 상황

인지를 의미한다.

상황 범위는 상황 추론함수 알고리즘에 따라 다르게

표현될 수 있다. 추론기가 서술 논리를 사용하는 경우에

는 상황 범위 규칙들을 서술 논리로 표현하고, 온톨로지

추론기를 사용하는 경우에는 온톨로지 문서를 사용할

수 있다. 또한 간단하게 값의 범위를 이용하는 추론기의

경우에는 이름-값의 쌍을 사용할 수 있다. 따라서 본

논문에서는 상황인지 시스템에서 사용하는 추론기의 알

고리즘에 따라 다른 방법으로 상황 범위를 표현한다.

3.3 상황인지 기능 기술 모델

브랜치형 상황인지 서비스를 기술하는 방법은 크게

세 가지로 분류할 수 있다. 첫째는 프로그램 코드 조각

을 직접 수행하도록 하는 방법이다. 보통 if-then 문장

을 통해서 상황을 파악하고, 이에 따라 기능을 수행하도

록 코드를 기술하는 방법이다. 이 방법은 프로그램 코드

가 전혀 구조적으로 분리되어 있지 않고, 추후에 시스템

을 확장하기 어려운 문제점을 갖고 있다. 둘째는 관점지

향(aspect-oriented) 프로그래밍 방법을 이용해서 상황

에 따라 메소드의 일부에 코드를 삽입해서 수행하는 방

법이다. 이 방법은 관점(aspect)을 이용해서 코드를 구

조화할 수 있기 때문에 추후 유지보수 및 확장이 용이

하다. 세 번째 방법은 상황에 따른 기능을 각각 다른 메

소드로 구현하는 방법이다. 이 방법은 jContext에서 지

원하는 방법이며, 기능을 상황에 따라 구조화할 수 있

고, 추후 유지보수 및 확장이 쉬운 장점을 갖고 있다.

jContext에서 브랜치형 상황인지 서비스는 상황에 따

라 다른 메소드를 호출한다. 이때 메소드들을 어떻게 볼

것인가가 중요한 관점이다. 메소드들이 서로 무관하다

면, 메소드 이름이나 구현 내용이 전혀 무관할 것이다.

그러나 일반적으로 볼 때 상황에 따라 구현 내용이 다

른 메소드들은 고차원의 의미론적으로 볼 때 동일한 의

미를 갖는다고 볼 수 있다. 예를 들어, K라는 상황인지

시스템이 doX()라는 서비스를 제공한다고 가정해보자.

이때 doX() 서비스는 상황A와 상황B가 존재할 수 있다

면, 각각에 대해서 별도의 메소드로 서비스 내용을 구현

할 수 있다. 그러나 의미론적인 입장에서 볼 때 상황A

그림 3 상황인지 메소드 구현의 오버로딩 메소드 개념

에서 doX() 서비스와 상황B에서 doX() 서비스는 동일

한 의미를 갖는다. 따라서 이는 그림 3과 같이 표현할

수 있고, 이를 jContext에서는 doX() 오버로딩 메소드

들로 표현한다.

3.4 상황인지 서비스 브랜치 모델

상황 추론 함수가 현재 상황을 추론한 경우에 브랜치

유형의 서비스는 상황에 맞는 오퍼레이션을 수행하거나

메소드를 호출해야 한다. 프로그램 구현 관점에서

Pascal Costanza[9]는 다음과 같이 기술하고 있다.

Currently, the only way to introduce context-depen-

dent behavior into a program is either by inserting

if statements ... or else by factoring out the context

dependent behavior into separate objects ...[9]

Pascal Costanza가 언급한 것처럼 대부분 상황에 따

른 메소드 호출은 if-then 문을 사용하는 것이 일반적이

지만, 본 논문에서는 분기 방법을 네 가지 방법으로 분류

하였다. 첫 번째는 if 문장을 이용해서 상황에 따라서 분

기하는 방법이다. 다음 코드는 if-then 문장을 이용해서

상황에 따라 다른 방법으로 인사하는 내용을 보여준다.

if ("Korean".equals(p.lang)) then

greet_korean(p)

else if ("English".equals(p.lang)) then

greet_english(p)

...

코드 1 if-then 문장을 이용하는 경우

두 번째 방법은 상황에 의존적인 코드를 별도의 클래

스로 분리하는 방법[10]이다. 이 방법은 상황 클래스의

요소가 상황에 의존적인 코드를 포함하고 있어서 서비

스를 호출할 때 이 메소드들이 호출되도록 하는 방법이

다. 이 방법은 간단한 시스템에는 적합하지만, 많은 서

비스들이 존재하는 경우에는 별도로 분리된 클래스가

모든 서비스들을 지원하기 위해서는 커지고, 복잡해져야

하는 문제점이 있다.


세 번째 방법은 서술형 논리 추론 엔진을 사용하는

경우에 추론 규칙에 상황에 적합한 메소드를 호출하도

록 하는 방법[11]이다. 이 방법은 상황을 추론하는 추론

엔진에서 비즈니스 로직의 메소드를 호출하는 방법으로

확장성과 유연성이 높은 장점을 갖고 있다. 그러나 추론

엔진에서 일반 프로그래밍 언어의 메소드를 호출하도록

하는 것은 쉬운 일이 아니기 때문에 이를 구현하기 어

렵다는 문제점을 갖고 있다.

When (p.isKorean)

Do Notify (p, “안녕하세요”)

When (p.isEnglish)

Do Notify (p, “Hello”)

코드 2 추론 규칙에 따라 메소드를 호출하는 경우

네 번째 방법은 본 연구에서 제안하는 메소드 오버로

딩과 자바 리플렉션을 이용해서 상황에 따라 메소드를

호출하는 방법이다. 우선 브랜치형 상황인지 서비스에

대해서 오버로딩형태로 메소드들을 정의한다. 이때 첫

번째 매개변수로 상황을 표현하는 클래스를 매개 변수

로 지정한다. 아래의 코드에서 greet()라는 메소드는

KoreanContext와 EnglishContext의 2개 상황에 대해

서 메소드를 제공한다.

public void greet(KoreanContext c, People p) {

System.out.printf("안녕하세요.\n");

}

public void greet(EnglishContext c, People p) {

System.out.printf("Hello.\n");

}

코드 3 오버로딩을 이용하는 경우

상황에 따라 다른 메소드를 호출할 수 있는 메소드

오버로딩 방법은 손쉽게 정의할 수 있지만, 이 메소드를

호출해야 하는 클라이언트에서 상황에 따라 메소드를

호출하는 것은 시스템의 유연성을 저하시키는 원인이

되기 때문에 본 연구에서는 클라이언트에서는 상황 정

보가 없는 greet() 메소드를 호출하도록 한다. 즉, 다음

과 같이 외부 클라이언트가 호출할 수 있는 메소드를

갖는다. greet() 메소드는 상황과 관련된 매개 변수를

갖고 있지 않다.

greet() 메소드는 내부에서 invokeContextAwareMethod()

메소드를 호출하는데, invokeContextAwareMethod()는

현재 상황을 파악하고, 자바 리플렉션을 통해서 greet

메소드 이름을 가지면서, 현재 상황에 해당되는 클래스

public void greet(People p) {

invokeContextAwareMethod(p, p);

}

코드 4 invokeContextAwareMethod() 메소드 호출

를 매개 변수로 갖는 메소드를 찾아서 호출한다.

상황에 따라 메소드 호출 분기를 시키는 방법은 오버

로딩 메소드를 호출하는 방법을 사용하는데, jContext에

서는 greet() 메소드에서 직접 상황에 따른 오버로딩 메

소드를 호출하는 대신에 자바 리플렉션을 이용해서

invokeContextAwareMethod() 메소드에서 상황에 적합

한 메소드를 호출하도록 설계 및 구현하였다. 이는 두

가지 요소를 고려하였기 때문인데, 첫째는 향후에 시스

템을 확장해서 문자열 타입으로 상황 이름이 주어지는

경우에도 상황 이름에 따라 적절한 상황 인지 메소드를

호출할 수 있도록 지원하기 위함이다. 둘째는 상황에 따

른 메소드 호출의 복잡한 작업들을 invokeContext

AwareMethod()에서 모두 지원하도록 함으로써 개발자

에게 복잡한 정보를 숨기기 위함이다. 예를 들어, 디폴

트 상황 인지 메소드 호출이라든가, 시스템에서 지원하

지 않는 상황이 발생할 때 처리, 혹은 일반 상황과 개인

선호의 충돌 해결 등의 문제를 각 응용프로그램 메소드

에서 기술하지 않고, invokeContextAwareMethod() 메

소드에서 해결하도록 함으로써 문제를 단순화할 수 있다.

다음 코드 5는 invokeContextAwareMethod()의 내

용 중에서 주요 부분들이다. 코드 내용에서 볼 수 있듯

이, invokeContextAwareMethod()는 자신을 호출한 메

소드 이름을 파악하고, 현재 상황을 파악한다. 이후에

자바 리플렉션을 이용해서 자신을 호출한 메소드와 동

일한 이름이면서 현재 상황과 동일한 클래스를 첫 번째

매개변수로 갖는 메소드를 찾아서 호출한다.

4. jContext 구현

4.1 jContext 개발 환경 및 현 상태

jContext[12]는 맥 스노우레오파드 운영체제의 데스크

탑 자바 플랫폼(JDK 1.6)에서 개발하고 있으며, 현재

버전은 v0.5이지만 그림 4의 시스템 구조와 그림 5의

클래스 기능을 모두 갖추고 있다. 센서 모듈을 위해서는

카메라를 위해 JavaCV[13](OpenCV[14]의 자바 버전),

시리얼로 연결된 센서 값을 읽기 위해서는 RxTx[15]

라이브러리를 사용한다. 블루투스 센서를 위해서는 자바

용 BlueCove[16]를 사용한다. 상황 추론을 위해서는 값

과 거리를 이용하는 방법은 자바 프로그램을 직접 작성

하도록 하고 있으며, 서술 논리를 위해서는 mProlog[17]

를 확장하는 방법을 사용한다. 온톨로지를 활용하는 추

론기는 현재 개발 중에 있다. 또한 툴킷을 개발하고 테


public Object invokeContextAwareMethod(IEntity e, Object ...objects) {

String methodName = /* 호출한 메소드 이름 파악 */

Thread.currentThread().getStackTrace()[2].getMethodName();

...

IContext _context = getContext(e); /* 현재 상황 파악 */

...

Method[] methods = this.getClass().getMethods();

for(Method ms: methods) {

String name = ms.getName();

if(name.equals(methodName)) { /* 메소드 이름이 동일한 경우에 */

Class clz[] = ms.getParameterTypes();

if(clz.length == 0) continue;

if(clz[0].equals(_context.getClass())) {

/* 첫 번째 매개변수의 타입이 상황 클래스와 동일한 경우 */

...

return ms.invoke(this, args); /* 오버로딩 메소드 호출 */

코드 5 상황에 따라 적절한 메소드를 호출해서 분기하는 invokeContextAwareMethod() 내용

그림 4 jContext 시스템 구조

스트하기 위해서 기존에 발표된 상황인지 시스템들을

간단한 시뮬레이션 버전으로 직접 개발함으로써 테스트

및 평가하고 있다. jContext 및 이를 사용해서 개발한

응용프로그램들은 sourceforge.net 사이트[12]를 통해서

공개하고 있다.

4.2 jContext 아키텍처

jContext는 시스템의 복잡도를 줄이고, 유연성을 높이

기 위해서 계층형(layer) 구조를 따르며, 기능에 따라

세 개의 계층(센서, 컨텍스트, 비즈니스)으로 구성되어

있다. 가장 하부에는 시스템 내외 환경 정보를 모니터링

하는 센서 계층이 있으며, 중간 계층에는 센서 정보를

바탕으로 상황을 추론하는 계층으로 구성되어 있다. 가

장 상위에는 상황 정보를 활용하는 비즈니스 응용프로

그램 계층으로 구성되어 있다. 다음 그림 4는 jContext

의 구조를 보여준다.

센서 계층의 센서는 하드웨어 센서와 소프트웨어 센

서로 구성되어 있으며, 상위 계층에서 볼 때 둘 사이의

차이점은 없다. 하드웨어 센서는 실제 센서 하드웨어가

있는 경우이고, 소프트웨어 센서는 시스템 정보, 사용자

정보 등을 알아보는 소프트웨어로만 구성된 것이다. 센


그림 5 jContext 주요 클래스

서는 매우 다양하기 때문에 센서의 변경에서 시스템 변

경을 최소화하기 위해서 raw sensor와 semantic sensor

계층으로 분리하였다.

컨텍스트 계층은 센서 정보를 바탕으로 현재 상황을

파악하는 역할을 한다. 상황인지에 관련있는 엔티티는

ContextType 객체와 1:1 관계를 갖고 있으며, Context-

Type에는 상황을 추론하기 위해서 필요한 센서들을 모

두 등록한다. ContextReasoner는 파일 혹은 데이터베이

스에 등록된 상황 범위 정보를 읽고, 현재 상황 속성 정

보들을 바탕으로 상황을 추론해서 상황 객체를 생성한다.

비즈니스 계층에는 상황이 변경되는 경우에 호출되는

ContextChangeListner 인터페이스를 구현한 클래스가

존재하며, 이 클래스에서 이벤트가 발생하는 경우에 어

떤 서비스들을 호출할 것인지를 결정한다. 또한 비즈니

스 계층에는 상황인지 서비스를 구현한 클래스들이 존

재하며, ContextChangeListener에서 서비스를 호출하는

경우에 현재 상황에 맞는 메소드가 호출된다.

4.3 jContext 클래스 설계

jContext의 클래스 설계는 계층형 구조를 선택한 요

구사항인 독립성, 유연성, 확장성을 염두에 두고 설계하

였다. 따라서 주요 구성 요소들은 인터페이스로 정의함

으로써 구현에 따른 의존성을 줄이도록 하였다. 그림 5

는 jContext 툴킷의 주요 클래스들 및 그들 간의 관계

를 보여준다. 하단부의 Context-aware Applications으

로 마크된 부분은 실제 상황인지 시스템을 구현해야 하

는 부분을 의미한다.

모든 센서들은 ISensor 인터페이스를 구현하며, 센서

값을 읽기 위한 getValue()/getValues() 메소드를 갖는

다. 또한 센서 값이 변경된 경우에 센서 값을 이용해서

상황을 파악해야 하는 클래스들에게 센서 값이 변경됨

을 알리기 위한 update() 메소드를 갖고 있다. ISensor

의 update()는 센서에 등록된 IContextType 인터페이

스의 update() 메소드를 호출한다. IContextType 인터

페이스는 상황을 추론하기 위해서 필요한 상황 속성(센

서)을 관리하기 위해서 사용된다.

IReasoner 인터페이스는 상황을 추론하는 추론기를

표현하기 위한 인터페이스이다. 이 인터페이스는 inter-

pret()라는 메소드를 갖고 있으며, IContextType 인터

페이스에 접근할 수 있다. 즉, ISensor에서 센서 값이

변경되면, ISensor의 update() 메소드가 호출되고, 이는

다시 IContextType 인터페이스의 update() 메소드를

호출한다. IContextType 인터페이스의 update() 메소드

는 IReasoner의 interpret() 메소드를 호출함으로써 현

재 상황을 추론한다. IReasoner의 interpret()는 추론한

상황을 IContext 인터페이스로 표현해서 결과를 리턴한

다. IContextType 인터페이스는 상황이 변경된 경우에

비즈니스 객체의 엔티티에 현재 상황을 설정하고, Con-

textChangeEvent를 발생시킴으로써 IContextListener

인터페이스를 구현한 비즈니스 객체의 메소드가 자동으

로 호출되도록 한다.

그림 5에서 Context-aware Applications 영역은 응

용 프로그램에 따라 달라지는 부분이다. BizContext에

해당되는 부분은 서비스에 따라 필요한 Context 클래스

들을 구현해서 사용하며, BizContextAwareClass 역시

CObject 클래스로부터 상속받거나 ICObject 인터페이

스를 구현해야 한다. 이 클래스는 상황에 따라 다르게

수행할 메소드들을 본 논문의 3절에서 소개한 오버로딩

방법을 이용해서 구현해야 한다. 또한 IContextListener

인터페이스를 구현한 contextChanged() 메소드에서 오

버로딩한 메소드의 원형 메소드를 호출함으로써 오버로

딩과 리플렉션에 의해서 상황에 맞는 메소드가 호출되

도록 한다.


그림 6 TourGuide 시스템 클래스 구성

그림 7(a) 전문가, 영어, 텍스트 그림 7(b) 초보자, 한국어, 멀티미디어

5. jContext 테스트 및 평가

5.1 투어 가이드 시스템

jContext로 개발한 투어 가이드 시스템은 MyGuide[18]

시스템의 기능을 일부 축소하고, 시뮬레이션으로 실행시

켜보는 시스템이다. 관광객이 전시물 근처로 이동하는

경우에 센서는 사용자를 인식하고, 이에 따라 사용자에

게 전시물에 대한 정보를 제공한다. 그림 6은 투어 가이

드 시스템의 클래스 구성 및 관계를 보여준다. 투어 가

이드 시스템은 관광객의 언어, 수준, 사용 단말기의 기

능(멀티미디어 지원 여부), 사용자 위치를 상황 정보로

사용하고, 이를 NoService와 ServiceAt이라는 두 개의

상황으로 구분해서 서비스를 제공한다. 실질적으로 정보

를 제공하는 상황인지 메소드들은 TourGuide 클래스의

provideInfo() 메소드로 구현되었다.

그림 7은 투어 가이드 시스템을 시뮬레이션으로 실행

시킨 결과이다. 그림 7(a)는 Kim이 영어를 사용하고,

그림에 대한 전문 지식을 갖고 있으며, 텍스트를 지원하

는 단말기를 가지고 해바라기라는 전시물로 접근했을

때 안내 정보가 전달되는 것을 보여준다. 반면에 그림 7

(b)는 Choi가 미술에 대한 초보적인 지식을 갖고 있으

며, 한국어를 사용하고, 멀티미디어 단말기를 가지고 있

으면서 모나리자에 접근했을 때 안내 정보를 제공하는

것을 보여준다. 그림 7의 (a)와 (b)는 모두 ServiceAt

상황을 의미하며, 관광객이 전시물에서 멀어지거나 휴게

소에서 쉬는 동안에는 NoService 상황으로 전이된다.

5.2 상황인지 PDF 뷰어

상황인지 PDF 뷰어는 기존의 PDF 뷰어에 상황인지

기능을 추가하기 위해서 센서 및 상황 처리에 관련된

클래스들을 추가한 것이다. 상황인지 PDF 뷰어는 사용

자가 움직이지 않는 경우에는 보통으로 PDF 문서를 보

여주지만, 이동 중인 경우에는 문서 내용을 확대해서 보

여준다. PDF 뷰어는 SwingLab[19]에서 개발한 것을

확장하는 방법을 사용하였다. 그림 8은 상황인지 PDF

뷰어 클래스 관계를 보여준다. MyPDFViewer는 기존

의 PDFViewer 클래스를 상속받으면서, 상황인지 기능

을 추가하기 위한 것이다. MyPDFViewer 클래스의

view() 메소드는 상황(StillContext 혹은 MovingCon-


그림 9(a) 정지 상황 그림 9(b) 움직이는 상황

표 2 jContext 평가

툴킷

특성Context Toolkit JCAF Gaia Reflex 본 연구

기존 시스템 지원 X X X △ O

사용의 용이성 △ O O △(AOP +OOP) O

추론 알고리즘 변경 X X X X O

상황 추가 X △ O(서술 논리 추가) O(aspect 추가) O(클래스 추가)

상황범위 수정 및 추가 X X O(서술 논리 추가) X O(외부 파일에 범위 추가)

기존 API 지원 X X unknown O O

브랜치형 서비스 지원 O O O △ O

트리거형 서비스 지원 O O unknown X O

센서 변경 O X unknown unknown △

X: 지원안함, △: 일부 지원, O: 지원

그림 8 상황인지 PDF 뷰어 시스템 클래스 구성

text)이 변함에 따라 문서를 보여주는 방법을 변경한다.

사용자의 움직임을 파악하기 위한 센서로는 SensorAcc-

elemetor 클래스를 사용하는데, 이는 실제 모션 센서가

아니라 시뮬레이션하기 위해서 마우스 커서 움직임을

파악하는 방법을 사용하였다.

그림 9(a)와 9(b)는 상황인지 PDF의 실행 화면을 보

여준다. 그림 9(a)는 정지 상태에서 일반적인 PDF 문서

뷰어를 보여주는 반면, 그림 9(b)는 움직이는 상황에서

문서의 내용이 확대돼서 보여준다.

5.3 평가

jContext 툴킷에 대한 평가는 시스템을 개발하는 개

발자 입장에서 사용의 용이성, 확장성, 유연성 등을 바

탕으로 하도록 한다. 표 2는 jContext 툴킷을 기존 툴킷

과 비교해서 평가한 내용이다.

표 2의 평가에서 “기존 시스템 지원”은 기존에 존재

하던 시스템을 확장해서 상황인지 기능을 추가할 수 있

는지 여부를 의미한다. 상황인지 PDF 뷰어 실험에서

볼 수 있듯이 jContext는 기존 시스템에 상황인지 기능

을 추가할 수 있지만, 대부분의 다른 툴킷들은 이러한

기능을 지원하기 어렵다. Reflex의 경우에 AspectJ를

기반으로 하기 때문에 기존 시스템에 상황을 추가할 수


있지만, 포인트컷에 의한 상황인지 기능 추가가 제한적

이다.

“추론 알고리즘 변경”을 위해서 jContext는 추론 기

능이 별도의 iReasoner 인터페이스로 분리되어 있고, 이

를 알고리즘에 따라 구현하는 클래스들이 별도로 존재

하기 때문에 필요한 경우에 추론기를 변경할 수 있다.

그러나 다른 툴킷들의 경우에 추론기 기능이 명확히 분

리되어 있지 않고, 추론 알고리즘이 하드코드로 표현되

어 있어서 변경이 어렵거나 불가능하다.

“상황 추가”와 “상황범위 수정 및 추가”는 기존 상황

인지 시스템에 새로운 상황과 상황범위를 추가할 수 있

는지 여부를 의미한다. 대부분의 툴킷이 하드코드되어

있기 때문에 새로운 상황을 추가하기 어렵다. 반면에

Gaia, Reflex, jContext는 상황 표현, 추론 기능, 상황

범위가 유연하기 때문에 새로운 상황과 상황 범위를 상

대적으로 쉽게 수정 및 추가할 수 있다.

“센서 변경”은 기존 센서를 다른 종류의 센서로 변경

하는 것을 의미한다. 예를 들어, 위치를 파악하기 위해

GPS 센서를 사용하다가 에너지 소모를 줄이기 위해 휴

대폰 송전탑 삼각측량법을 이용한 센서로 변경하는 경우

에 시스템 변경 없이 가능한지 여부를 의미한다.

Context Toolkit은 다양한 오퍼레이션을 제공함으로써

이를 가능하게 하였고, jContext 역시 raw 센서와 의미

센서 계층을 분리함으로써 이러한 기능을 일부 지원한다.

6. 결 론

상황인지 시스템의 중요성이 커지면서, 이를 쉽게 구

축하기 위한 프레임워크 혹은 툴킷에 대한 관심도 높아

지고 있지만, 현재까지 개발된 툴킷들은 하드 코딩된 내

용이 많기 때문에 유연성 및 확장성이 부족하다는 문제

점을 갖고 있었다.

상황인지 툴킷의 유연성 및 확장성 부족 문제를 해결

하기 위해서 본 연구에서는 트리거와 브랜치 형태의 상

황인지 서비스들에 대해서 의미적으로는 동일하지만, 상

황에 따라 다른 구현을 갖는 오퍼레이션들을 메소드 오

버로딩 방식으로 표현하고, 이를 리플렉션을 통해서 상

황에 따라 자동적으로 호출하는 방법을 제시하였다. 메

소드 오버로딩을 통한 상황인지 메소드들의 표현은 의

미적으로 동일한 서비스들을 보다 구조적으로 관리할

수 있다는 장점을 갖고 있다. 또한 자바 리플렉션을 사

용해서 상황인지 서비스를 요청하는 클라이언트는 단지

일반 메소드를 호출하는 것과 동일한 방법으로 상황인

지 서비스를 호출할 수 있다.

오버로딩 메소드로 상황인지 메소드를 구현하는 기능

은 기본적으로 상황을 클래스로 표현하는 것을 바탕으

로 하고 있으며, 이를 통해서 시스템의 유연성과 확장성

을 높일 수 있었다. 구체적으로 새로운 상황을 추가할

수 있으며, 상황 추론 알고리즘을 교체하거나 기존 시스

템을 상황인지 시스템으로 확장할 수 있다. 이러한 확장

성은 소프트웨어 유지보수 및 재사용 측면에서 매우 중

요하면, 비용을 절감할 있는 장점을 갖고 있기 때문에

시스템 유지보수 및 마이그레이션 분야에서도 중요한

연구 토픽이 될 수 있을 것이다.

참 고 문 헌

[ 1 ] Anind K. Dey, Daniel Salber and Gregory D.

Abowd, "A Conceptual Framework and a Toolkit

for Supporting the Rapid Prototyping of Context-

Aware Applications," Human-Computer Interaction

(HCI) Journal, vol.16, no.2-4, pp.97-166, 2001.

[ 2 ] Jakob E. Bardram, "The Java Context Awareness

Framework (JCAF) - A Service Infrastructure and

Programming Framework for Context-Aware App-

lications," LNCS 3468, Springer, pp.98-115, 2005.

[ 3 ] Eric Tanter, et al., "Context-Aware Aspects,"

Proc. of the 5th International Symposium on Soft-

ware Composition, LNCS, Springer, pp.227-249, 2006.

[ 4 ] Manuel Román et al., "Gaia: A Middleware Infra-

structure to Enable Active Spaces," IEEE Perva-

sive Computing, vol.1, pp.74-83, 2002.

[ 5 ] J. M. Choi, "A Study of Requirements Elicitation

and Specification for Context-Aware Systems,"

Journal of KIISE : Computer Systems and Theory,

vol.35, no.7-8, pp.394-406, Aug. 2008. (in Korean)

[ 6 ] Anind K. Dey, "Understanding and Using Context,"

Personal and Ubiquitous Computing Journal, vol.5,

no.1, pp.4-7, 2001.

[ 7 ] Harry Chen, Tim Finin, and Anupam Joshi, "An

Ontology for Context-Aware Pervasive Computing

Environments," The Knowledge Engineering Review,

Cambridge University Press, vol.18, pp.197-207,

2003.

[ 8 ] Strang T. and Linnhoff-Popien C., "A Context

Modeling Survey," First International Workshop

on Advanced Context Modelling, Reasoning and

Management, UbiComp., 2004.

[ 9 ] Pascal Costanza and Robert Hirschfeld, "Language

Constructs for Context Oriented Programming,"

Proc. of the ACM Dynamic Languages Symposium,

pp.1-10, 2005.

[10] Gustavo Rossi, ilvia Gordillo, and Fernando

Lyardet, "Design Patterns for Context-Aware

Adaptation," Proc. of the The 2005 Symposium on

Applications and the Internet Workshops, pp.170-

173, 2005.

[11] Richard Etter, Patricia Dockhorn Costa, and Tom

Broens, "A Rule-Based Approach Towards Context-

Aware User Notification Services," Proc. of the

2006 ACS/IEEE International Conference on

Pervasive Services, IEEE, 2006.


[12] jContext, available at http://sourceforge.net/projects/

jmcontext/.

[13] JavaCV, available at http://code.google.com/p/javacv/.

[14] OpenCV, available at http://sourceforge.net/projects/

opencv/.

[15] RxTx. available at http://rxtx.qbang.org/wiki/index.

php/Main_Page.

[16] BlueCove, available at http://bluecove.org/.

[17] mProlog: Lightweight PROLOG Engine, available

at http://www.cs.uu.nl/3apl-m/mprolog.html

[18] Jongmyung Choi and Jongbae Moon, "MyGuide: A

Mobile Context-Aware Exhibit Guide System,"

Proc. of ICCSA 2008, LNCS 5073, Springer,

pp.348-359, 2008.

[19] PDF-render, available at http://java.net/projects/

pdf-renderer/

최 종 명

2010년 7월～2011년 12월 미국 조지아공

대 방문교수. 2004년 3월～현재 국립목

포대학교 컴퓨터공학과 교수. 2003년 8월

숭실대학교 컴퓨터학과(공학박사). 1996

년 8월 숭실대학교 전자계산학과(공학석

사). 1992년 2월 숭실대학교 전자계산학

과(공학사). 관심분야는 프로그래밍 언어, 유비쿼터스 컴퓨

팅, 상황인지 시스템, 소셜 네트워크 서비스

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputCondition () /PDFXRegistryName (http://www.color.org) /PDFXTrapped /Unknown

/Description >>> setdistillerparams> setpagedevice

Documents

자바 리플렉션과 메소드 오버로딩을 활용한 상황인지 툴킷kiise.or.kr/e_journal/2012/1/SA/pdf/02.pdf · 장 및 재사용하기 어려운 문제점이 있다