비즈니스 프로세스 관리를 위한 질의 언어 및 모델링 표기법 표준화...

NCA IV-RER 05015/2005. 9

비즈니스 로세스 리를 한 질의 언어

모델링 표기법 표 화 연구

Standardization of Modeling Notation and Query

Language for Business Process Management

수탁기 : (재)경기북부- 진테크노 크

한 국 산 원

NCA IV-RER 05015/2005. 9 60

비즈니스 로세스 리를 한 질의 언어

모델링 표기법 표 화 연구

Standardization of Modeling Notation and Query

Language for Business Process Management

2005. 9. 30.

수탁기 : (재)경기북부- 진테크노 크

한 국 산 원

제 출 문

한국 산원장 귀하

본 보고서를 “비즈니스 로세스 리를 한 질의 언어 모델링 표기법

표 화 연구”의 최종연구개발보고서로 제출합니다.

2005년 9월 30일

수 탁 기 : (재)경기북부- 진테크노 크

연 구 책 임 자 : 김 훈 태 ( 진 학교 교수)

참 여 연 구 원 : 이 용 한 (동국 학교 교수)

탁과제 리자 : 오 목 (한국 산원 정보화표 장)

윤 정 희 (한국 산원 정보화표 )

- i -

요 약 문

1. 제 목

비즈니스 로세스 리를 한 질의 언어 모델링 표기법 표 화 연구

2 . 연구개 발 의 목 요성

본 연구의 목 은 비즈니스 로세스 리를 한 질의 언어 모델링 표

기법 표 화에 하여 연구하고 표 안을 도출하는 것이다.

BPMN은 2004년 5월에 Version 1.0이 발표되었으나 기존의 BPMS 개발업

체들로부터 극 으로 수용되고 있지는 않은 상황이다. 이는 기존의 BPMS

들이 각자 나름 로의 로세스 표기법과 그에 부합하는 실행 엔진을 기반으

로 하고 있는 상황에서 검증되지 않은 최신 BPM 표 들을 수용하는데 극

으로 나서지 못하고 있는 것으로 이해된다. 따라서 BPMN에 한 객 이

고 체계 인 이해, 분석 평가를 통해서 한 활용방안을 도출하는 연구

가 필요하다.

BPQL은 재 BPMI.org에 의해서 개발 에 있는 표 스펙으로 비즈니스

로세스를 한 최 의 표 기반 질의 언어이다. 2005년 9월 재 BPMI.org

는 BPQL에 한 표 스펙을 확정하지 않고 있다. 이에 따라 BPQL이 확정

되어 국내 BPM 솔루션업체가 신속하게 채용하여 국제경쟁력을 확보할 수 있

도록 이에 비할 필요가 있다.

따라서 비즈니스 로세스 리(BPM)에 한 다양한 기술과 제품이 도출

되고 있는 시 에서 매우 요한 의미가 있다.

- ii -

3 . 연구개 발 의 내 용 범

앞서 기술한 연구 목표를 달성하기 해 다음과 같은 세부목표와 연구 범

를 설정하도록 한다.

BPM과 련된 기술 표 들에는 본 연구에서 으로 분석 조사하

는 BPMN, BPQL과 더불어 BPML, BPEL4WS 등과 웹서비스 기술표 등이

있다. 본 연구에서는 이러한 기술표 들에 한 참조 아키텍처를 도출하여 각

표 간의 연 계를 명확히 하고자 한다.

BPMI.org의 BPMN 1.0을 기 으로 비즈니스 로세스 모델링 표기와 련

된 기술표 들을 조사분석하고 비즈니스 로세스 모델링 표기법의 국내 표

안을 도출하고자 한다. 한 이러한 표 안의 용을 한 사례를 개발하고자

한다.

2005년 9월 재 BPMI.org는 BPQL에 한 표 스펙이 확정되어 있지 않

으므로, 직 인 표 안 도출은 많은 험요소를 포함할 가능성이 있다. 이에

따라 본 연구에서는 질의언어 설계를 한 다양한 근법에 한 기 조사와

공개된 표 안 개념을 연구하고자 한다. 한 BPQL의 다양한 사용 사례를

조사 분석하고 가능한 안들을 제시하고자 한다.

4 . 연구결과

본 연구의 결과를 장별로 요약하면 다음과 같다.

제 1 장. 서론: 본 연구의 목 필요성에 해 설명하고 본 연구의 내용

과 범 를 간략하게 기술하 다.

제 2 장. BPM 표 황 참조 아키텍처: BPM의 국제표 화 기구와 국

- iii -

제 표 에 하여 조사하고, BPM 표 의 참조 아키텍처를 제시하 다. 한

BPM 표 간의 구조 계를 분석하 다.

제 3 장. 비즈니스 로세스 리를 한 모델링 표기법: BPMN의 BPD

(Business Process Diagram)에 하여 체계 으로 정리하 다. 한 BPMN을

BPEL4WS로의 매핑하는 규칙에 하여 정리하 다.

제 4 장. BPMN 분석 활용방안: BPMN을 분석하기 하여 다른 로세

스 모델링 표기법과 비교하 으며, BPMN의 표 력을 확인하기 하여 비즈

니스 로세스의 패턴을 기 으로 검증하 다. 한 BPMN의 활용방안을 제

시하기 하여 BPD의 상 로세스를 분류하고, BPD BPMN의 작성 가

이드라인을 도출하 으며, BPMN의 사례를 제시하 다.

제 5 장. 비즈니스 로세스를 한 질의 언어: 비즈니스 로세스 질의 언

어의 연구 배경을 조사하고, 비즈니스 로세스 질의 언어를 한 설계 개념

을 분석하 다. 한 BPQL의 기반 연구를 수행하고, 사례를 조사하여 제시하

다.

제 6 장. 결론: 본 연구의 결론과 연구결과의 활용방안, 향후 연구과제에

해 요약하 다.

5 . 활 용 에 한 건의

본 과제의 결과물은 자상거래표 화통합포럼 등의 표 화 단체와 기업정

보화 련 단체를 통해 BPM 솔루션 개발업체와 BPM 도입을 추진하는 기업

에 제공하는 것이 바람직할 것이다. 기업정보화 자거래 련 정책을 수

립하는 정부기 에서도 기술정책 수립 시 본 연구의 결과를 활용할 수 있을

것이다.

- iv -

6 . 기 효과

본 연구의 기 효과와 활용방안은 아래와 같이 요약될 수 있다.

첫째, BPMN, BPQL BPEL4WS를 지원하는 소 트웨어의 개발자들에게

해당 표 들의 입문서로서 빠른 이해를 돕는데 활용될 수 있을 뿐 아니라, 소

트웨어의 개발에 있어서 구체 인 설계지침으로 활용될 수 있다. 특히 국내

환경에 맞는 용 사례의 개발은 보다 정확하고 신속한 표 의 이해 활용

을 가능하게 할 것으로 기 된다.

둘째, BPMS를 개발하는 소 트웨어 업체 도입을 검토하고 있는 업체들

에게는, BPM 련 핵심 표 들의 정확한 이해 상 가능한 기술 이슈들

을 사 검 악할 수 있게 해 으로써, BPM 표 의 수용과 련된

략을 수립하는데 있어서 시행착오를 최소화할 수 있을 것으로 기 된다.

셋째, 본 연구를 통해서 얻어진 결과는 BPM 개발 도입 기업들이 참조

할 수 있도록 표 안으로 작성하여 표 화 과정을 밟도록 할 정이다. 표

은 국내 실정에 맞게 작성됨으로써, 련 용어 개념의 표 인 한 용어

를 제공할 뿐 아니라, BPM 업계의 표 수용을 진하는데 활용될 수 있다.

마지막으로 BPMN, BPQL, BPEL4WS를 활용하고자 하는 로세스 설계

분석가들에게는 비즈니스 로세스 표 표기법 질의어를 학습하거나

련 교육자료를 제작하는데 참고자료로 활용될 수 있다.

- v -

Summary

1. Title

Standardization of Modeling Notation and Query Language for Business

Process Management

2 . Purpose and I mportance

The purpose of this research is to investigate modeling notations and

query languages for business process management purpose and to derive

the standard specification of the business process modeling notation.

Having been announced in May 2004, BPMN (version 1.0) has not been

actively adopted by BPM solution vendors. That is mainly due to the fact

that the BPM solutions in the market have their own process modeling

notations and corresponding execution engines, thereby making the solution

vendors hesitate in adoption of the unproven brand-new specifications.

Therefore, it is necessary to derive proper ways of BPMN's practical use

based on the systematic investigation, analysis and evaluation of BPMN.

BPQL is the first business-process-purpose query language, which is

currently under development. As of September 2005, BPMI.org has not

finalize the BPQL standard specification. Hence, in order to achieve

international competitiveness, we need to prepare for the instance adoption

of the specification in the domestic BPM solution industry when the

specification is ratified as a standard. In this sense, this research has great

- vi -

significance at this moment.

3 . Contents and Scope

In order to achieve the purpose of this research, the objectives and

research scope are established as follows.

Beside BPMN and BPQL that are the main focus of this research, there

are other importance technical standards such as BPML and BPEL4WS. In

this research, the relationship among these standards will be clarified by

deriving a reference architecture for the standards.

The domestic standard specification of business process modeling

notation will be developed based on thorough investigation and analysis of

the BPMN 1.0 from BPMI.org. In addition, sample cases will be developed

in order for promoting the specification.

As of September 2005, standard specification of BPQL is not finalized

yet, meaning that developing our own domestic specification in advance is

undesirable. Accordingly, various approaches to the design of query

languages are investigated and the underlying concepts of publically

available drafts of the specifications will be studied. In addition, various

practical cases of using BPQL will be investigated and possible proposals

will be generated.

4 . Results

The results of this research are summarized in chapters as follows:

- vii -

Chapter 1. Introduction: The purpose and necessity of this research are

explained along with the brief description of the contents and the scope of

the research.

Chapter 2. Present State of BPM Standards and Reference Architecture:

International standardization organizations and their standards on business

process management are investigated, and a reference architecture for BPM

standards is proposed. In addition, the structural relationship among BPM

standards are analyzed.

Chapter 3. Modeling Notation for Business Process Management: BPD

(Business Process Diagram) in the BPMN specification is systematically

explained along with the mapping rules of BPDs to BPEL4WS model.

Chapter 4. Analysis of BPMN and Usage Guidelines: For the analysis

purpose, BPMN is compared with other process modeling notations. In

specific, BPMN's modeling power is assessed on the basis of the business

process patterns. In addition, BPD's target processes are classified to

generate guidelines for using BPMN, along with some example cases of

BPD.

Chapter 5. Query Language for Business Process Management: The

research background of business process query languages are investigated,

and various design concepts of business process query languages are

analyzed. In addition, basic research on BPQL is carried out, and cases are

investigated and explained.

Chapter 6. Conclusions: The results of this research, application areas,

and future research issues are summarized.

- viii -

5 . Suggestions

The results of this research can be provided to the BPM solution

vendors and the companies who are considering BPM implementation after

reviewing by the standardization organizations such as Integrated Forum

on Electronic Commerce (ECIF). Government organizations in charge of

promoting enterprise information systems and establishing electronic

commerce strategies can utilize this research result in making new policies

and strategies.

6 . Benefits

The expected benefits and application areas of this research are

summarized as follows.

First, this work can be used by BPMN, BPQL and BPEL4WS-compliant

software developers as a primer of these standards or as a detailed design

guidelines. Especially application cases that fit the domestic environment

make users understand and utilized the standards in a more correct and

prompt way.

Second, by use of the research results, BPMS vendors and the

companies considering BPM implementation can understand the

technologies and assess the possible technical issues in advance, thereby

minimizing the chances of trial and error establishing BPM

standard-adoption strategy.

Third, the results of this research will be used to make a standard

- ix -

specification through the standardization process so that both BPMS

vendors and consumers can consult the standards. The standard will be

made fit the domestic situations, namely terminologies and concepts are to

be translated to appropriate standard Korean terms. Also the domestic

version of the standards will promote BPM industry to adopt the global

standards.

Finally, this work can be used by business process designers and

analysts who want to use BPMN, BPQL and/or BPEL4WS to study the

standard process modeling notation and query language as an reference for

the instructional purposes.

- x -

Contents

Ch apter 1. I ntroduction ················································································ 1

Section 1. Research Background ········································································· 1

Section 2. Research Purpose and Scope ···························································· 4

Ch apter 2 . Status and Reference A rch itecture of BPM

Standards ······················································································ 6

Section 1. Status of BPM Standards ································································· 6

Section 2. Reference Architecture of BPM Standards ································ 17

Ch apter 3 . Business Process Modeling Notation ···························· 2 7

Section 1. BPD (Business Process Diagram) ················································ 28

Section 2. Mapping to BPEL4WS ····································································· 52

Ch apter 4 . BPMN A nalysis and U ses ··············································· 5 8

Section 1. Comparison Study between Modeling Notations ······················ 58

Section 2. BPMN Analysis ················································································· 74

Section 3. BPMN Uses ························································································ 84

Ch apter 5 . Business Process Query Language ······························ 10 7

Section 1. Background of Business Process Query Language ··············· 107

Section 2. Requirement of Business Process Query Language ·············· 115

Section 3. Foundations and Cases for BPQL ·············································· 125

- xi -

Ch apter 6 . Conclusions ············································································ 15 0

Reference ········································································································ 15 2

A ppendix A . BPMN ················································································· A - 1

- xii -

목 차

제 1 장 서 론 ··································································································· 1

제 1 연구의 필요성 ···························································································· 1

제 2 연구의 목표 범 ················································································ 4

제 2 장 BPM 표 황 참 조 아 키 텍 처 ············································· 6

제 1 BPM 표 황 ······················································································· 6

제 2 BPM 표 의 참조 아키텍처 ······························································· 17

제 3 장 비즈니스 로세스 리를 한 모델링 표기법 ················· 2 7

제 1 BPD (Business Process Diagram)의 체계 이해 ······················· 28

제 2 BPEL4WS로의 매핑 ············································································ 52

제 4 장 BPMN 분 석 활 용 방 안 ·························································· 5 8

제 1 로세스 모델링 표기법 비교분석 ···················································· 58

제 2 BPMN 표 력 검증 ·············································································· 74

제 3 BPMN 활용 방안 ·················································································· 84

제 5 장 비즈니스 로세스를 한 질의 언어 ···································· 10 7

제 1 비즈니스 로세스 질의 언어의 연구 배경 ·································· 107

제 2 비즈니스 로세스 질의 언어를 한 설계 개념 ························ 115

제 3 BPQL의 기반 연구 사례 ····························································· 125

- xiii -

제 6 장 연구 개 발 결과 의 활 용 방 안 기 효과 ··························· 15 0

참 고 문헌 ·········································································································· 15 2

부 록 A . 비즈니스 로세스 모델링 표기법 ········································ A - 1

- xiv -

표 목 차

<표 2-1> BPM 국제 표 화 황 ············································································· 6

<표 2-2> 외국 BPM 솔루션업체의 표 용 황 ············································· 16

<표 2-3> 국내 BPM 솔루션업체의 표 용 황 ··········································· 17

<표 3-1> BPD의 핵심요소 ······················································································· 37

<표 3-2> BPD의 완 한 집합 ················································································· 39

<표 3-3> BPEL4WS 매핑 규칙 요약 ···································································· 49

<표 4-1> 페트리넷의 표기 ························································································ 59

<표 4-2> UML Activity Diagram의 표기 ···························································· 62

<표 4-3> IDEF3 로세스 설계도의 표기 ···························································· 63

<표 4-4> IDEF3 객체 상태 이도의 표기 ·························································· 64

<표 4-5> 로세스 설계를 한 순서도의 표기 ·················································· 66

<표 4-6> 로세스 표기법의 핵심 요소 비교 ······················································ 68

<표 4-7> 로세스 표기법의 흐름 제어 요소 비교 ············································ 71

<표 4-8> 로세스 표기법의 보조 요소 비교 ······················································ 72

<표 5-1> 로세스 리의 발 과정 ·································································· 112

<표 5-2> ICONS에서 정의된 BPQL의 문법 ···················································· 141

- xv -

그 림 목 차

<그림 2-1> BPM을 한 국제 표 ······································································· 10

<그림 2-2> 국제표 의 발 단계 ············································································ 15

<그림 2-3> BPM 참조 아키텍처의 개념도 ··························································· 17

<그림 2-4> BPMI의 BPM 표 구조 ···································································· 19

<그림 2-5> BPM 라이 사이클에서 BPMN과 BPEL의 치 ·························· 21

<그림 2-6> XPDL 1.0의 로세스 정의 상호교환 ·············································· 23

<그림 2-7> XPDL 2.0의 로세스 정의 상호교환 ·············································· 24

<그림 2-8> BPMN 다이어그램과 XPDL 2.0 문서의 변환 ······························· 26

<그림 3-1> Start 이벤트의 그래픽 요소 - 기본형과 그 변형들 ···················· 30

<그림 3-2> BPD 핵심 요소 집합의 구성 ····························································· 31

<그림 3-3> 이벤트 (Event) ······················································································ 32

<그림 3-4> 액티비티 (Activity) ·············································································· 33

<그림 3-5> 게이트웨이 (Gateway) ········································································· 33

<그림 3-6> 순서흐름 (Sequence Flow) ································································ 34

<그림 3-7> 메시지흐름 (Message Flow) ····························································· 34

<그림 3-8> 계 (Association) ················································································ 34

<그림 3-9> 풀 (Pool) ································································································· 35

<그림 3-10> 인 (Lane) ·························································································· 35

<그림 3-11> 데이터 객체 ·························································································· 36

<그림 3-12> 그룹 ········································································································ 36

<그림 3-13> 해설 ········································································································ 37

<그림 3-14> 이메일 투표 로세스 ········································································ 52

<그림 3-15> “이메일 투표 로세스"의 시작 로세스 ···································· 53

<그림 3-16> “이메일 투표 로세스” 시작 로세스의 BPEL4WS 매핑결과 ···· 55

- xvi -

<그림 3-17> “이메일 투표 로세스”의 BPEL4WS 매핑 결과 ······················· 56

<그림 4-1> 페트리넷의 로세스 시 ·································································· 60

<그림 4-2> BPMN의 로세스 표기 시 ··························································· 60

<그림 4-3> UML2 Activity Diagram의 로세스 시 ···································· 62

<그림 4-4> IDEF3의 로세스 시 ······································································ 65

<그림 4-5> 순서도의 로세스 시 ······································································ 66

<그림 4-6> BPMN과 UML2 Activity Diagram의 Deferred Choice 표 ········ 69

<그림 4-7> 페트리넷의 Deferred Choice 표 ···················································· 69

<그림 4-8> BPMN의 트랜잭션 표기 ····································································· 72

<그림 4-9> BPMN과 UML2 Activity Diagram의 외처리 표 ·················· 73

<그림 4-10> BPMN과 UML2 Activity Diagram의 참여자 표 ···················· 73

<그림 4-11> Pi-Calculus로 표 되기 어려운 페트리넷 표 ·························· 74

<그림 4-12> Sequence 패턴의 표 ······································································· 75

<그림 4-13> Parallel Split 패턴의 표 ································································ 75

<그림 4-14> Synchronization 패턴의 표 ··························································· 76

<그림 4-15> Exclusive Choice 패턴의 표 ························································ 76

<그림 4-16> Simple Merge 패턴의 표 ······························································ 77

<그림 4-17> Multiple Choice 패턴의 표 ··························································· 77

<그림 4-18> Synchronizing Merge의 표 ·························································· 78

<그림 4-19> Multiple Merge의 표 ····································································· 78

<그림 4-20> Discriminator 패턴의 표 ······························································· 78

<그림 4-21> Arbitrary Cycle 패턴의 표 ··························································· 79

<그림 4-22> Implicit Termination 패턴의 표 ·················································· 79

<그림 4-23> MI without Synchronization 패턴의 표 ···································· 80

<그림 4-24> MI with a Priori Known Design Time Knowledge 패턴의 표 ·· 80

<그림 4-25> MI with a Priori Known Runtime Knowledge 패턴의 표 ·· 80

- xvii -

<그림 4-26> MI without a Priori Runtime Knowledge 패턴의 표 ··········· 81

<그림 4-27> Deferred Choice 패턴의 표 ·························································· 82

<그림 4-28> Interleaved Parallel Routing 패턴의 표 ···································· 82

<그림 4-29> Milestone 패턴의 표 ······································································ 83

<그림 4-30> Cancel Activity 패턴의 표 ··························································· 83

<그림 4-31> Cancel Case 패턴의 표 ································································· 84

<그림 4-32> 비공개 비즈니스 로세스의 ······················································ 85

<그림 4-33> 추상 비즈니스 로세스의 ·························································· 86

<그림 4-34> 업 비즈니스 로세스의 ·························································· 87

<그림 4-35> BPD 작성 차 ··················································································· 92

<그림 4-36> 이메일 투표 로세스 ········································································ 94

<그림 4-37> “이메일 투표 로세스”의 시작 로세스 ···································· 95

<그림 4-38> “Discussion Cycle" 하부- 로세스 세부사항 ······························ 96

<그림 4-39> “Collect Votes” 하부- 로세스 세부사항 ····································· 99

<그림 4-40> E-Mail 투표 로세스의 마지막 부분 ········································· 101

<그림 4-41> 자외상매출채권 방식의 자결제 로세스 ···························· 103

<그림 4-42> 자외상매출채권 방식의 자결제 로세스 ···························· 104

<그림 5-1> DBMS와 BPMS ················································································ 111

<그림 5-2> 비즈니스 로세스를 한 질의 언어의 기능 ······························ 113

<그림 5-3> WfMC의 워크 로우 참조모델과 다섯 인터페이스 ···················· 118

<그림 5-4> WebML 하이퍼텍스트 모델을 활용한 ····································· 127

<그림 5-5> IT 어 리 이션의 일부분으로써의 워크 로우 시스템 ··········· 136

<그림 5-6> 로세스 메타모델 ·············································································· 139

<그림 5-7> 선택 인 활동의 를 나타내는 BPQL 질의문 ··························· 143

<그림 5-8> 참여자 할당의 를 나타내는 BPQL 질의문 ······························· 143

<그림 5-9> 로세스 정의에 사용된 BPQL 질의문의 ······························· 144

- xviii -

<그림 5-10> XPDL의 트랜지션 조건에 사용된 BPQL 질의문의 ············ 146

<그림 5-11> XPDL의 참여자 할당에 사용된 BPQL 질의문의 ················ 147

<그림 5-12> XPDL의 사 /사후 조건에 사용된 BPQL 질의문의 ·········· 148

- 1 -

제 1 장 서 론

제 1 연구의 필 요성

지난 몇 년간 BPM (Business Process Management)을 한 웹서비스 기

반의 XML 실행언어 개발을 한 다양한 활동이 있어왔다. BPML이나

BPEL4WS와 같은 언어들은 비즈니스 로세스들을 정의하기 한 형식 메

커니즘을 제공한다.

이러한 언어들은 BPM의 운 상호운 을 해서 최 화되어 있다. 이

들 언어들이 BPM의 운 을 해 최 화되어 있다는 은, 비즈니스 로세스

를 사람이 직 설계, 리, 모니터하는 목 에는 덜 합하다는 것을 의미한

다. 즉, BPEL4WS가 복잡한 비즈니스 로세스들이 소 트웨어 시스템이나

로그래머들에 의해서는 아주 용이하게 처리될 수 있는 형식으로 구성되어

있으나, 로세스를 개발, 리, 모니터 해야 하는 비즈니스 분석가들이나

리자들로서는 이해하기 어려운 문제 이 있다.

일반 으로 비즈니스 실무자들은 비즈니스 로세스들을 흐름도

(flow-chart) 형식으로 시각화하는데 매우 익숙하다. 따라서 비즈니스 로세

스 기 설계 형식과 BPEL4WS와 같이 비즈니스 로세스들을 실행시키는

언어 형식 사이에는 기술 인 공백이 존재하게 된다. 이러한 공백을 메우기

해서는 비즈니스 로세스들의 시각 표 방식의 정립과 이를 한 실

행형식 (BPM 실행언어)으로 매핑시켜 주는 형식 메커니즘이 필요하다.

이러한 필요성에 따라 BPMI.org에 의해서 제안된 BPMN (Business

Process Modeling Notation)은, 비즈니스 로세스들을 설계하고 리하는 사

람들이 용이하게 사용할 수 있는 비즈니스 로세스 다이어그램(BPD:

Business Process Diagram) 표기법과 함께 이를 비즈니스 로세스 실행언어

- 2 -

( , BPEL4WS)로 변환하기 한 형식변환방법(formal mapping)을 제공해

다.

한 BPQL은 재 BPMI.org에 의해서 개발 에 있는 표 스펙으로 비

즈니스 로세스를 한 최 의 표 기반 질의 언어이다. BPQL은 비즈니스

로세스 정의가 로세서 서버 상에 배치되고 로세스 인스턴스의 실시간

인 질의를 가능하게 해 다.

오늘날의 데이터 리시스템들이 서로 다른 로그래 언어라 하더라도

SQL이나 기타의 연결 리 도구(Connectivity Tool) 등을 통해 근할 수 있

는 것처럼, 동일한 개념이 로세스 리 역에도 용될 수 있다. DBMS가

일종의 범용 데이터 서버라 한다면, BPM은 범용의 로세스 리 서버라 할

수 있을 것이다. 여기서 SQL이 범용의 DBMS에 한 표 인 질의 조작

언어라고 한다면, BPQL은 범용의 BPM에 한 표 인 질의 조작 언어

가 되는 것이다.

이러한 BPQL의 필요성은 DBMS에서 SQL이 차지하는 역할에 견주어 짐

작할 수 있다. 비즈니스 로세스를 개발하여 실행시키고자 하는 개발자가

BPQL과 같은 표 언어를 필요로 하는 이유는 바로 개발 생산성과 유지보수

의 향상에 있다.

만약 BPQL이 없이 로세스를 리해야 한다면 로세스 리의 많은 로

직들이 조각난 상태로 곳곳의 응용 로그램 내에 흩어져 숨겨지게 될 것이

다. 이 게 구 된 BPM 시스템은 해당 조직의 로세스 지식과 경험을 명시

으로 리하지 못할뿐더러, 로세스 체의 통합 력과 조정을 어렵게

만든다. 따라서 BPQL을 이용한 로세스 질의어의 표 화는 다양하게 개되

고 있는 BPM 시스템들의 리 근을 단순화시킬 것이고, 이들 간의 연계

와 통합을 가능하게 하는 첩경이 된다. BPQL의 도입으로 인한 효과는 단순히

개발자에 국한되는 것이 아니라 리자 경 자들 모두를 한 실제 인 이

- 3 -

득으로 나타나게 될 것이다.

본 과제는 비즈니스 로세스 리를 한 질의 언어 모델링 표기법 표

화에 하여 연구하고 표 안을 도출하는 것으로서, 비즈니스 로세스

리(BPM)에 한 다양한 기술과 제품이 도출되고 있는 시 에서 매우 필요하

다고 할 수 있다.

○ 비즈니스 로세스 모델링 표기법 표 화의 필요성

BPMN은 2004년 5월에 Version 1.0이 발표되었으나 기존의 BPMS 개발업

체들로부터 극 으로 수용되고 있지는 않은 상황이다. 이는 기존의 BPMS

들이 각자 나름 로의 로세스 표기법과 그에 부합하는 실행 엔진을 기반으

로 하고 있는 상황에서 검증되지 않은 최신 BPM 표 들을 수용하는데 극

으로 나서지 못하고 있는 것으로 이해된다. 따라서 BPMN에 한 객 이

고 체계 인 이해, 분석 평가를 통해서 한 활용방안을 도출하는 연구

가 필요하다.

○ 비즈니스 로세스 질의 언어의 필요성

BPQL은 재 BPMI.org에 의해서 개발 에 있는 표 스펙으로 비즈니스

로세스를 한 최 의 표 기반 질의 언어이다. 2005년 9월 재 BPMI.org

는 BPQL에 한 표 스펙을 확정하지 않고 있다. 이에 따라 BPQL이 확정

되어 국내 BPM 솔루션업체가 신속하게 채용하여 국제경쟁력을 확보할 수 있

도록 이에 비할 필요가 있다.

- 4 -

제 2 연구의 목 표 범

비즈니스 로세스 리를 한 모델링 표기법 질의언어 표 화 연구를

수행하기 하여 다음과 같은 세부목표와 연구 범 를 설정하도록 한다.

(1) 참조 아키텍처 도출

BPM과 련된 기술 표 들에는 본 연구에서 으로 분석 조사하

는 BPMN, BPQL과 더불어 BPML, BPEL4WS 등과 웹서비스 기술표 등이

있다. 본 연구에서는 이러한 기술표 들에 한 참조 아키텍처를 도출하여 각

표 간의 연 계를 명확히 하고자 한다.

(2) 비즈니스 로세스 모델링 표기법의 국내 표 안 도출

BPMI.org의 BPMN 1.0을 기 으로 비즈니스 로세스 모델링 표기와 련

된 기술표 들을 조사분석하고 비즈니스 로세스 모델링 표기법의 국내 표

안을 도출하고자 한다. 한 이러한 표 안의 용을 한 Case Study 사례를

개발하고자 한다.

BPD의 체계 이해 표 력 분석

실행언어로의 매핑을 한 지침 연구

BPMN 사례 연구

(3) BPM을 한 질의언어의 표 화 기반연구

2005년 3월 재 BPMI.org는 BPQL에 한 표 스펙이 확정되어 있지 않

으므로, 직 인 표 안 도출은 많은 험요소를 포함할 가능성이 있다. 이에

따라 본 연구에서는 질의언어 설계를 한 다양한 근법에 한 기 조사와

- 5 -

공개된 표 안 개념을 연구하고자 한다. 한 BPQL의 다양한 사용 사례를

조사 분석하고 가능한 안들을 제시하고자 한다.

질의언어 설계개념 연구

BPQL의 기반 연구 사례

- 6 -

<표 2-1> BPM 국제 표 화 황

기능 표 명 제정 단 체 상 태

로세스

설계도구

BPMN BPMI v1.0

Business Process Definition Metamodel OMG RFP 발표후

진행

로세스

실행언어

BPEL4WS (WSBPEL) OASIS WSBPEL TC v1.1

BPXL BPMI 진행

WS-CDL W3C 진행

XPDL WfMC v1.0

로세스

모니터링/분석BPQL BPMI 진행

상호운용성Wf-XML WfMC v2.0

BPSM BPMI 진행

기타UML Profile for EAI OMG v1.0

UML Profile for EDOC OMG v1.0

제 2 장 BPM 표 황 참 조 아 키 텍 처

본 장에서는 BPM과 련된 표 들의 황에 하여 조사하고, BPM 표

들에 한 참조 아키텍처를 제시하고자 한다.

제 1 BPM 표 황

BPM 의 국제 표 화는 로세스 실행 언어를 심으로 이루어졌으며 최

근 로세스 설계도구 등으로 그 범 가 확 되었다. BPM 표 화를 이끄는

단체로는 OASIS, BPMI, WfMC, OMG, W3C 등이 존재한다. 아래 표는 각

단체에서 발표하 거나 는 제정 인 BPM의 기능별 표 화 황을 나타낸

다.

- 7 -

1. 국 제 표 화 기구의 황

BPM과 련된 국제 표 화 기구의 활동 황은 다음과 같다.

가 . O A SI S

공개 표 에 기반하여 표 이 신속히 채택되는 것을 목표로 하는 비 리

국제 컨소시엄으로 주로 SGML, XML, HTML CGM 은 물론 기타 구조화

된 정보처리에 련 표 을 다룬다. 보안, 웹서비스, XML, 자거래, 자출

, Topic maps와 같은 세계 인 표 을 제정하고 있으며 UN/CEFACT와 공

동으로 확장 가능 XML 규격을 표 화하는 세계 인 로젝트를 출범하여

ebXML이 모든 자업무 데이터의 교환에 일 성 있게 활용될 수 있도록 기

술 인 임워크 표 을 개발하고 있다.

나 . W fMC

워크 로우 리 시스템 개발에 주도 인 역할을 하고 있는 기 은

WfMC(Workflow Management Coalition)이다. WfMC는 워크 로우 련 개

발 업체들의 비 리기 으로 워크 로우 련 기술들과 이슈들에 한 표

제정 연구 활동을 수행하고 있다. WfMC는 워크 로우 제품의 표 화를

통하여 워크 로우 시스템간의 연동성을 실 하기 하여, 워크 로우 련

용어, API, 로토콜 포맷에 한 정의를 제공하고 있다. WfMC에는 부

분의 워크 로우 업체들이 참여하고 있으며 사용자, 분석가들도 함께 가입되

어 있다.

워크 로우 시스템을 이루는 여러 컴포 트는 분산되어있는 이기종 시스템

인 경우가 부분이다. 이러한 워크 로우 시스템의 구조난립을 막고, 서로 다

- 8 -

른 워크 로우 제품들을 표 화하기 해서 WfMC에서는 워크 로우 참조모

델(WRM, Workflow Reference Model)을 제안하 다.

다 . BPMI

자상거래의 비즈니스 로세스 리를 한 문기 으로서 2000년 6월

에 설립되어 후지쯔, 휴랫팩커드, IBM, 선 등 XML 이마켓 이스솔루션

분야의 핵심기술과 사업수행 능력을 갖춘 80여개 세계 정보통신 기업들이

가입돼 있는 단체이다.

BPMI는 BPM의 체수명주기를 지원할 수 있는 표 개발에 힘쓰고 있다.

BPM의 체수명주기는 비즈니스 로세스의 설계에서부터 구축, 실행, 유지

리, 최 화 등을 포함한다.

BPMI는 2005년 6월 OMG와의 략 합병을 결정했음을 발표했다. 이후

BPMI와 OMG는 BPM의 분야에서 합작을 통한 기술 개발을 진행할 것임

을 밝혔다.

라 . O MG

OMG는 1989년 4월, HP, SUN등 11개 업체에 의해 발족된 비 리단체로써

표 화된 객체 기술의 소개를 진함으로써 컴포 트 기반의 소 트웨어 시장

을 활성화하기 해 구성되었다. 재 800여개 이상 업체의 컨소시엄 형태로

운 되고 있으며, 컴퓨터 사용자들에게 시스템 통합시 발생하는 문제를 해결

할 수 있도록 개방형이며 벤더에 립 으로 상호운용이 가능한 명세를 제공

한다.

OMG가 발표한 CORBA는 시스템 통합 시 상호운용에 한 표 을 정의한

- 9 -

명세이며, 10여 년간 많은 벤더들에 의해 구 되었고, 다수의 시스템이

CORBA를 기반으로 개발되어 왔다. 그러나 1997년 이후 조직의 범 가 속

히 확 되고, CORBA 가 제공하는 표 로그래 인터페이스를 사용하여

획득할 수 있는 상호운용성에 한계가 생기게 되었다. 이에 OMG에서는

CORBA를 기반으로 하지 않고 체 시스템 라이 사이클을 통해 시스템 통

합을 지원할 수 있는 UML, MOF(Meta Object Facility), XMI(XML

Metadata interchange), CWM(Common Warehouse Metamodel)등의 명세를

발표하 다.

OMG에서는 UML v2.0의 발표와 함께 UML의 사용범 를 소 트웨어 설

계 외의분야들로 확장하려는 노력을 진행 이며, 비즈니스 로세스 설계

한 이 확장 노력에 포함되어 있다. UML2에서는 Activity Diagram에서 비즈

니스 로세스를 표 할 수 있도록 많은 확장을 하 으며, UML Profile for

EAI, UML Profile for EDOC등 BPM과 련있는 UML Profile들을 발표하

다. 2003년에는 Business Process Definition Metamodel의 RFP를 발표한 이

후 별다른 진 이 없었으나, 2005년 6월 BPMI와의 략 합병을 발표함으로

써 빠른 시일 안에 표 안을 발표할 것으로 기 된다.

2 . 국 제 표 의 황

다음의 <그림 2-1>은 BPM과 련된 국제 표 의 상 계를 보여주는

그림이다. 다음은 각 표 에서 본 연구와 연 성이 높은 표 인 BPMN,

XPDL, BPEL4WS, BPML, BPXL, WSCI, WS-CDL, Wf-XML, BPQL,

BPSM들에 하여 조사하여 정리한 것이다.

- 10 -

<그림 2-1> BPM을 한 국제 표

가 . BPMN

BPMN(Business Process Modeling Notation)은 비즈니스 로세스들을 설

계하고 리하는 사람들이 사용하기 한 도표인 BPD(Business Process

Diagram)와 함께 BPEL4WS로의 형식 변환(formal mapping)을 제공해 다.

따라서 BPMN은 실행을 해 최 화되어 있는 비즈니스 로세스 언어로 정

의된 비즈니스 로세스들을 한 표 시각화 메커니즘을 제공하는 것이다.

BPMN은 비즈니스 실무자들에게 그들의 내부 비즈니스 로세스들을 시각

표 을 통해 이해하는 능력을 제공해 주고, 한 이러한 로세스들을 표

인 방법으로 상호 교환 (communicate)할 수 있는 능력을 비즈니스 조직

들에게 제공하게 된다.

BPMN은 가독성(readability)를 해 흐름도 표기법의 통을 따르면서, 한

편으로는 실행 가능한 언어 구성체(constructs)로의 변환(mapping)을 제공한

다. BPMI는 BPMN 이 의 여러 가지 비즈니스 로세스 표기법들의 경험을

이용하여, 가독성, 유연성 확장성을 결합하는 차세 표기법을 만들고 있

- 11 -

다. BPMN은 한 공개, 비공개 로세스들, 구성(choreographies) 등과 같은

B2B 비즈니스 로세스 개념들은 물론 외처리와 트랜잭션 보

(compensation) 등의 고 모델링 개념들까지 본질 으로 처리해 으로써

통 인 비즈니스 로세스의 기능들을 진보시킬 것이다.

BPMI는 BPMN 1.0 버 을 2004년 5월에 발표하 다.

나 . X PD L

WfMC의 워크 로우 참조모델을 구성하는 다섯 가지 인터페이스 인터

페이스 1에 해당하는 로세스 정의 모델을 XML로 표 한 것이 XPDL(XML

Process Definition Language)이다. XPDL 명세서에는 워크 로우에서 사용되

는 다양한 로세스 정의요소를 포함한 로세스 메타모델을 제시하고 있다.

그리고 워크 로우 제품들이 내부 으로 사용하는 로세스 정의를 주고받을

수 있도록 공통의 XML 교환 포맷을 제공하고 있다.

WfMC에서 2002년 10월에 v1.0이 발표된 이후 큰 수정이 이루어지지 않았

으나, BPMN의 발표 이후 BPMN 장 포맷의 기능 추가를 목표로 v2.0의 제

정이 속히 이루어지고 있어, 2005년 8월 v2.0의 드래 트 버 이 발표되었

다. XPDL v2.0은 v1.0과 호환되면서 BPMN의 장포맷으로 사용되기 해

Swimlanes 등의 개념 추가와 웹서비스 개체 강화 등의 확장을 주 내용으로

하고 있다.

다 . BPE L4 W S

BPEL4WS(Business Process Execution Language for Web Services)는

웹서비스에 근거하여 비즈니스 로세스의 작동을 기술하기 하여 개발된 이

- 12 -

후 업계에서 가장 리 받아들여진 표 으로 자리 잡았다. BPEL4WS는 BEA

Systems, IBM, Microsoft가 2002년 8월에 웹서비스를 활성화하기 해 제정

한 규약이다. BPEL4WS에 있는 로세스는 으로 웹서비스 인터페이스들

을 사용함으로써 기능들을 가져오고 내보낸다. 그리고 BPEL4WS는 기존에

IBM의 WSFL Microsoft의 XLANG의 기능을 통합하고 확장한 것이다.

비즈니스 로세스 기술 언어인 BPEL4WS는 함께 발표된 웹서비스 통신

규약인 WS-Coordination, WS-Transaction과 함께 기업간 로세스, 즉 력

업체 고객 반에 걸쳐 다 비즈니스 로세스 트랜잭션 서비스를 신

뢰성 있게 통합할 수 있도록 한다.

BPEL4WS은 비즈니스 로세스와 비즈니스 상호 로토콜의 정형 인 명

세 언어를 제공한다. 이는 웹서비스 상호작용 모델을 확장하여, 그 모델이 비

즈니스 트랜잭션을 지원할 수 있도록 한다. BPEL4WS은 기업 내 이나 기업

간 거래를 한 자동화된 로세스 통합을 수행하는 상호운용 가능한 통합 모

델을 정의한다.

OMG에 2003년 표 으로 상정되어, OASIS의 WSBPEL TC에서 표 화 작

업이 진행되고 있다.

라 . BPML

BPML(Business Process Modeling Language)은 기업 비즈니스 로세스

의 모든 추상 이고 실행 인 로세스를 포함하는 모델이다. 이 로세스는

다양한 트랜잭션, 복잡한 활동, 데이터 리, 일치성, 외처리, 운 의미 체

계 등을 포함한다.

BPML의 문법은 XML 스키마를 따르고 BPML 사양, Web Services Flow

Language(WSFL) 사양, XLANG(an extension of WSDL for business

- 13 -

process design) 사양의 의미상 슈퍼 셋이다.

이것은 이질 인 시스템과 모델링 도구 환경에 지속성과 상호 호황성의

로세스 정의를 제공한다. 그리고 BPML은 BEA Systems, Intalio, SAP AG,

Sun 에 의해 개발된 Web Service Choreography Interface(WSCI)에게도 향

을 주고 있다. 한 BPML의 최종 버 은 Business Process Execution

Language for Web Services(BPEL4WS) 사양과 함께 상호호환성 있게 설계

고, WS-Security, WS-Transaction 그리고 WS-Coordination specifications

을 지원한다.

BPMI는 BPML 1.0 버 을 2003년 11월에 발표하 으나, 2004년 BPMI에서

BPEL4WS를 사실상의 표 으로 인정함에 따라 더 이상의 개발은 없을 것으

로 상된다.

마 . W SCI 와 W S- CD L

WSCI(Web Service Choreography Interface)는 XML 기반의 인터페이스

기술 언어로서, 웹서비스가 다른 서비스들과 상호작용 하는데 필요한 메시지

흐름을 기술하고 제어하기 하여 사용된다. 웹서비스들의 작동을 상호 간에

인식시키고, 존재하는 웹서비스 로토콜들을 연결하기 한 표 언어이다.

WSCI는 BEA Systems, Intalio, SAP AG, Sun Microsystems 등이 공동으로

참여하여 2002년 8월에 1.0 버 이 발표되었다.

WS-CDL(Web Services Choreography Description Language)은 웹서비스

참여자들 간의 peer-to-peer 업을 기술하는XML 기반의 언어이다.

WS-CDL은 포 인 시각에서 이들 웹서비스 참여자들의 공통 는 보완

인 행 들을 정의하며, 이러한 정렬된 메시지 교환은 궁극 으로 공통의 비즈

니스 목표를 달성할 수 있게 해 다.

- 14 -

다수의 서로 다른 조직들이 계된 비즈니스 는 여타 활동들, 는 웹서

비스 기술을 이용하여 업하는 독립 인 로세스들은, 하게만 통합될

수 있다면 매우 성공 일 수 있다. 이 문제를 풀기 해서, 하나의 메시지 교

환 시에 따라야 하는 공통의 순서와 제약조건들에 한 역 (global) 정의가

생성되는데, 이는 포 시각에서 모든 웹서비스 참여자들의 공통 는 보완

인 행 들을 기술하게 된다.

이러한 역 정의 근법의 가장 요한 이 은, 이것이 개별 비즈니스

는 시스템들이 따라야 하는 내부 로세스들을 각 비즈니스나 시스템들이

서로 정보를 교환하는 순서에 한 정의로부터 분리시켜 다는 이다. 이것

은 외부에 공개되는 순서가 변하지 않는 한, 개별 비즈니스 는 시스템 내부

의 비즈니스 규칙이나 논리는 의도에 따라 변경할 수 있음을 의미한다.

WS-CDL은 W3C에서 표 화가 추진되고 있는 표 이다. 재 1.0 버 이

워킹 드래 트로 제출되어 있다.

사 . W f- X ML

WfMC의 워크 로우 참조모델을 구성하는 다섯 가지 인터페이스 인터

페이스 4에 해당하는 워크 로우 상호운용성을 한 XML 메시지 표 으로

제시된 것이 Wf-XML이다. Wf-XML은 기존에 WfMC에서 제안된 워크 로

우 상호운용성에 한 추상 명세서를 기반으로 하고 있다. Wf-XML은 서로

다른 워크 로우 시스템 간에 로세스 련 메시지를 교환함으로써 로세스

연동을 구 하기 한 표 이다.

Interoperability Wf-XML Binding 표 은 2000년 5월에 1.0 버 이 제출되

었고, 1.1 버 (최종)이 2001년 12월에 WfMC 표 문서로 발표되었다.

Wf-XML 표 은 2003년 10월에 Wf-XML 2.0 버 의 드래 트가 제출된

- 15 -

이후 데모 시연 등 강화 작업을 진행 에 있다.

아 . BPQL( Business Process Query Language)

비즈니스 로세스 리 시스템(BPMS)을 한 표 인터페이스로, 시스템

리자가 BPMS를 리하고, 시스템 분석가가 비즈니스 로세스의 인스턴스

를 질의할 수 있는 인터페이스를 개발하는 것을 목 으로 한다. BPMI에서 개

발 에 있다.

다음의 <그림 2-2>는 BPM과 련된 기술표 들의 발 단계를 보여주고

있다.

<그림 2-2> 국제표 의 발 단계

- 16 -

3 . BPM 솔 루 션 업 체 의 표 용 황

다음의 <표 2-2>는 2005년 9월 재, 외국 BPM 솔루션업체의 제품과 표

용 황을 나타내고 있다.

<표 2-2> 외국 BPM 솔루션업체의 표 용 황

솔 루 션 업 체 BPM 솔 루 션 표 용 황

FileNetFileNet Business Process Manager

BPEL 지원, BPMN 미정

Microsoft BizTalk Server 2004 BPEL 모델 import 지원

Tibco Staffware Process Suite BPEL 지원 정

오라클 Oracle BPEL Process ManagerBPMN 미 용,BPEL4WS 용

Intalio Intalio | n3 Server BPEL, BPML 지원

Active Endpoints Active WebFlow BPEL4WS 용

IBMWebSphere Business Integration Server

BPEL4WS 용

FiveSight Technologies

PXE(Process eXecution Engine) WS-BPEL 2.0 용

Cast IronTM Application RouterTM 1000 BPEL4WS 모델링 지원

다음의 <표 2-3>은 2005년 9월 재, 국내 BPM 솔루션업체의 제품과 표

용 황을 나타내고 있다.

- 17 -

<표 2-3> 국내 BPM 솔루션업체의 표 용 황

솔 루 션 업 체 BPM 솔 루 션 표 용 황

HandySoft BizFlow BPM 9.0 BPEL4WS 지원 정

미라콤 Hightway101 BPMS Suite BPMN, BPEL4WS 지원

비투비인터넷 XicoBPM3BPEL 실행 지원,BPMN 모델링 지원

메타빌드 Indigo BPM BPEL, BPMN 지원

TMAX 소 트 Tmax BizMaster BPEL 지원, BPMN 미정

제 2 BPM 표 의 참 조 아 키 텍 처

다음의 <그림 2-3>은 본 연구에서 제안하는 BPM 표 의 참조 아키텍처

의 개념도이다. BPM 표 간의 연 계를 심으로 제시하 다.

<그림 2-3> BPM 참조 아키텍처의 개념도

- 18 -

체 으로 로세스 모델(Process Model), 로세스 설계(Process

Design), 기업간 로세스 실행(Process Execution(B2B)), 기업내 로세스 실

행(Process Execution(internal)) 등으로 구분하 다.

표 의 참조 아키텍처에서 본 연구에서 주요 상으로 하고 있는 BPMN과

로세스 실행언어와의 구조 계에 하여 으로 분석하 다.

본 에서는 BPM 련 표 들이 이루는 BPM 구조에서 BPMN의 치에

해 분석하고, 특히 로세스 실행언어들 표 으로 가장 리 인정되고

있는 BPEL4WS와 BPM 라이 사이클에서 갖는 구조 계를 분석한다.

그리고 BPMN의 장구조 제공을 해 제정이 진행 인 XPDL 2.0을 소

개하고 BPMN과의 계에 해 분석한다.

1. BPM 표 구조

아래 그림은 재 BPMI에서 완성을 목표로 하고있는 BPM 표 구조이다.

이 BPMI에서는 웹 서비스 기반의 비즈니스 로세스 실행언어 제작을 목

표로 했으며, 그 결과 2002년 11월 BPML의 제안을 발표하 다. 이후 그 범

를 로세스 모델링 표기법, 로세스 의미, 로세스 분석까지 확 한 로세

스 심 BPM 구조의 완성을 목표로 하 으며, 그 로세스 모델링 표기법

표 인 BPMN의 제안을 2004년 5월 가장 먼 완성하 다. BPSM과 BPXL은

아직 표 제안이 발표되지 않은 상태이다.

- 19 -

<그림 2-4> BPMI의 BPM 표 구조

(1) BPMN

로세스 모델링 표기법의 표 이다. 로세스 실행언어에 독립 으로 설

계되는 모델링 표기법의 표 은 BPMS제품에 독립 인 로세스 교환을 가능

하게 하며 로세스 설계자의 편의성을 높인다. 더불어 BPMN에서는 다양한

추상화를 가능하게 함으로써 로세스 설계자, 컨설턴트, 개발자 등 모든 계층

에서 필요한 추상화 단계의 설계를 가능하도록 하 다.

(2) BPSM

로세스 의미 설계의 표 이다. 로세스 메타모델을 설계, 통합할 수 있

게 하는 것을 목표로 제안 작성이 진행 이다. OMG의 MOF(Meta-Object

Facility)를 이용해 정의된다.

(3) BPEL & BPXL

BPMI에서는 BPML의 제안 이후 BPEL이 BPML의 부분집합임을 주장하며

- 20 -

BPML을 BPMS의 로세스 실행언어로 사용하 으나, 2004년 6월 로세스

실행언어의 표 으로 OASIS의 BPEL을 받아들 다. BPEL은 BPML에 비해

축소된 기능을 지니고 있으나 간단성과 높은 사용성으로 업계에서 가장 리

이용되는 표 이 되었다. BPMI에서는 BPML이 아닌 BPEL을 BPM 표 구

조에 포함시키는 신 BPEL의 확장 메커니즘을 이용, BPEL의 기능을 확 하

기로 하 는데, 이 확장 내용이 BPXL이다. BPXL은 인간업무(BPEL에서는

로세스의 모든 활동이 웹 서비스만으로 이루어짐), 트랜잭션, 비즈니스 규칙,

태스크(활동의 하 단계) 리 등 BPEL에서 지원하지 않으나 업에서 필

요로 하는 기능들을 추가하는 것을 목표로 제안 작성이 진행 이다.

(4) BPQL

BPQL은 로세스 쿼리 랭귀지의 표 안으로 제안 작성이 진행 이다.

BPQL은 로세스 인스턴스에 해 질의를 실행할 수 있도록 함으로써 로

세스 모니터링 분석에 이용될 수 있으며, 비즈니스 활동 모니터링(BAM;

Business Activity Monitoring)의 기반기술이 된다. 한 공개된 업 로세

스의 검색에도 이용되는 것을 목표로 하고 있다.

(5) WS-CDL

WS-CDL은 기업간 웹 서비스 업을 설계하기 한 언어로 W3C에서 제

안 작성이 진행 인 표 이다.

(6) Web Service Stack

웹 서비스 계층은 BPM 표 구조를 통한 로세스 구축과 실행의 기반기

술이 되는 계층으로, WSDL, UDDI 등 웹서비스의 기반 표 들을 의미한다.

- 21 -

2 . BPMN과 BPE L의 구조 계

BPM 표 구조에서 설명되었듯 BPMN은 로세스 모델링 표기법의 표

으로, BPEL은 로세스 실행언어의 표 으로 독립된 치를 차지한다.

BPMN, BPEL BPM 표 구조의 구성 요소들이 BPM 라이 사이클에서

수행하는 기능은 아래 그림과 같다.

<그림 2-5> BPM 라이 사이클에서 BPMN과 BPEL의 치

설계(Modeling)

구축 및 실행(Deployment & Execution)

모니터링 및 분석(Monitoring & Analysis)

개선

(Reengin

eeri

ng)

BPMN

BPEL BPEL + BPXL

BPSM

BPQL

UDDI

WSDL

SOAP

변환

의미 통합

실행 기반

질의

BPM계층 웹서비스계층

(1) 설계단계 - BPMN

BPMN은 비즈니스 로세스의 설계 단계에서 사용된다. 비즈니스 설계자,

컨설턴트들은 BPMN을 이용해 로세스의 개 업무 흐름을 설계하고, 이

후 개발자들은 설계된 로세스에 실행 언어로의 변환을 한 상세 속성들을

추가한다. BPMN을 이용하여 기업내 로세스, 공개 로세스, 업 로세스

모두를 설계하는 것이 가능한데, 이들 공개 로세스와 업 로세스는

BPMN의 형태로 상호 교환될 수도 있다.

- 22 -

(2) 구축 단계 - BPMN에서 로세서 실행언어로의 변환

BPMN으로 설계된 비즈니스 로세스는 실행을 해 BPEL 는 확장된

BPEL로 변환된다. BPM 표 구조에서 BPXL로 확장한 BPEL을 로세스 실

행언어 표 으로 명시하고 있으나, BPMN은 로세스 실행언어에 독립 이므

로 경우에 따라 순수한 BPEL이나 확장된 BPEL 둘 어느 쪽으로도, 는

XPDL 등 기타 로세스 실행언어로도 변환될 수 있는 가능성을 지닌다.

(3) 구축 실행단계 - BPEL의 실행

BPMN으로부터 변환된 BPEL 는 확장된 BPEL은 BPM엔진을 통해 구축

되고 인스턴스화되어 실행된다. 본 단계에서 사용되는 BPEL문서는 표 을 통

해 작성되어 있으므로 BPM엔진에 독립 이다. BPM엔진에서는 웹서비스 계

층의 여러 표 들과 연동하여 비즈니스 로세스를 실행한다.

(4) 기타 단계

BPQL은 실행단계, 분석단계 등에서 실행 인 로세스 인스턴스의 모니터

링과 종료된 로세스 인스턴스의 분석을 해 질의를 실행한다. 로세스 설

계단계에서는 로세스의 의미 통합과 교환을 해 BPSM이 사용된다.

3 . BPMN과 X PD L의 구조 계

(1) XPDL 1.0

본래 XPDL은 WfMC의 워크 로우 참조모델 인터페이스 1에 해당하는

로세스 정의 상호교환 모델로 발표되었다. 즉 서로 다른 조직들에서 설계한

로세스 모델을 XPDL 포맷을 통해 교환하고 한 XPDL로 정의된 로세스

- 23 -

를 실행, 시뮬 이션, 모니터링 등에 사용하는 것을 그 목 으로 하 다.

아래 그림은 XPDL 1.0 표 문서에서 제시한 로세스 정의 상호교환 개념

을 설명한다.

<그림 2-6> XPDL 1.0의 로세스 정의 상호교환

의 그림에서 설명하듯 각 조직들이 서로 다른 모델로 설계한 로세스를

XPDL로 변환/역변환함으로써 상호교환할 수 있고, 한 변환된 XPDL문서는

시뮬 이션 엔진, 실행 엔진, 모니터링 엔진 등에서 로세스 실행언어의 역할

을 할 수 있다.

(2) XPDL 2.0

로세스 정의 상호교환 모델로써의 XPDL 1.0은 2002년 10월 완성되어 최

종 버 이 발표되었다. 이후 2004년 5월 BPMN이 발표되었고 이후 BPMN과

- 24 -

XPDL 1.0의 매핑 작업이 다소 진행되었으나, BPMN과의 합성을 최 화하

기 해 XPDL의 수정 작업이 이루어졌다. 2005년 9월 재 XPDL의 1.13 버

의 최종 문서가 발표되어있다.

아래 그림은 XPDL 2.0에서의 로세스 정의 상호교환 모델을 설명한다.

그림에서 XPDL 1.0에서의 로세스 정의 상호교환 모델과 달라진 은 로

세스 메타모델의 구성에서 BPMN이 활용되고 있다는 것이다.

<그림 2-7> XPDL 2.0의 로세스 정의 상호교환

그림과 같이 XPDL 2.0에서는 BPMN과의 메타모델 공유를 추가한 반면

이 의 로세스 정의 상호교환 모델로써의 기능을 유지하고 있다. 특히

XPDL 1.0과의 상호운용성을 유지하는 것을 그 목표로 하고 있으며, XPDL

1.0으로의 역변환 가능성을 제시한다.

- 25 -

(3) BPMN과 XPDL 2.0의 상호 변환

XPDL 2.0은 BPMN의 장 포맷 제공을 가장 큰 목표로 하고 있다.

BPMN 표 문서에서는 다이어그램의 구성요소만을 명시할 뿐 설계된 로세

스의 장구조는 제공하고 있지 않으므로, BPMN을 설계도구로 사용하는 조

직에서는 BPMN을 데이터 형태로 장하기 한 장구조를 개발해야 한다.

XPDL 2.0이 BPMN의 장구조가 됨으로써 이러한 개발 필요성을 없앨 뿐만

아니라 별도의 변환작업 없이 로세스 정의 상호교환이 가능하도록 한다.

XPDL 2.0에서는 BPMN의 구성요소들을 포 하기 해 메타모델의 확장이

이루어졌으며, 표 문서에서 BPMN 다이어그램으로부터의 변환 방법들을 명

시하고 있다. 아래 그림은 BPMN 다이어그램과 그에 응하는 XPDL 2.0 문

서의 시를 보여 다.

로세스 흐름은 Data-based Decision Gateway에 의해 분기가 이루어지는

를 나타낸다. 데이터의 값에 의한 XOR분기로, 각 분기들에 해 데이터 값

에 한 조건이 첨가되고 디폴트 분기가 정의되어 있다. 아래의 XPDL 2.0 문

서에서 BPMN과의 합성을 해 Route 엘리먼트에 GatewayType,

XORType, MarkerVisible 등의 속성들을 추가한 것을 볼 수 있다. XPDL 2.0

에서는 이 외에도 Swimlanes, Artifacts, Association 등 BPMN의 구성요소들

을 XPDL 개체로 추가하고 있다.

- 26 -

<그림 2-8> BPMN 다이어그램과 XPDL 2.0 문서의 변환

XXa1

a2

a3

a4

a<b

a>bg1

(a) BPMN 다이어그램

<Activities>

<Activity Id="3" Name="a1"/>

<Activity Id="4" Name="g1">

<Route GatewayType="XOR" XORType="Data" MarkerVisible="TRUE"/>

<TransitionRestrictions>

<TransitionRestriction>

<Split Type="XOR">

<TransitionRefs>

<TransitionRef Id="9"/>



</TransitionRefs>

</Split>

</TransitionRestriction>

</TransitionRestrictions>

</Activity>




</Activities>

<Transitions>

<Transition Id="8" Name="" From="3" To="4" FlowType="SequenceFlow"/>

<Transition Id="9" Name="" From="4" To="5" FlowType="SequenceFlow">

<Condition Type="CONDITION">a<b</Condition>

</Transition>


<Condition Type="CONDITION">a>b</Condition>

</Transition>


<Condition Type="OTHERWISE"/>

</Transition>

</Transitions>

(b) XPDL 문서

- 27 -

제 3 장 비즈니스 로세스 리를 한 모델링 표기법

Business Process Modeling Notation (BPMN)은 Business Process

Management Initiative (BPMI)에 의해서 개발되었으며, 2004년 5월 3일에

BPMI.org에 제출된 BPMN 스펙 버 1.0이 최신 버 이다. 앞서 1장에서도

설명된 바와 같이 BPMN의 주된 목표는, 로세스의 설계하는 비즈니스 분석

가로부터 로세스의 실행기술을 구 하는 개발자, 그리고 그 로세스들을

리하고 모니터하는 비즈니스 담당자들에 이르기까지 모든 비즈니스 사용자

들이 쉽게 이해할 수 있는 표기법을 제공하는데 있다.

따라서 BPMN은 비즈니스 로세스 설계와 로세스 구 사이의 표 화

된 인터페이스 역할을 해 수 있다. 아울러, 부가 인 목표로서 BPEL4WS

(Business Process Execution Language for Web Services)와 같은 비즈니스

로세스 실행언어를 비즈니스 의 표기법으로 가시화시키는 것이다. 이러

한 목표에 따라서 BPMN 스펙은 크게 다음의 두 부분으로 나눠진다.

비즈니스 로세스 다이어그램 (Business Process Diagram, BPD)

비즈니스 실행언어로의 매핑

각각의 주제에 해서 다음의 3장 1 과 3장 2 에서 살펴본다. 비즈니스

실행언어로의 매핑의 경우 BPMN 1.0에서는 BPEL4WS만을 다루고 있다. 이

에 따라 본 보고서에서도 BPEL4WS만을 상으로 한다. 아울러 상세한 스펙

은 부록 A에 첨부하 다.

- 28 -

제 1 BPD ( Business Process D iagram) 의 체 계 이 해

BPMN은 비즈니스 로세스들을 설계하고 리하는 사람들이 사용하기

한 도표인 비즈니스 로세스 다이어그램(BPD: Business Process Diagram)을

제공한다. 이를 통해서 BPMN은 비즈니스 실무자들에게 그들의 내부 비즈니

스 로세스들을 시각 표 을 통해 이해하는 능력을 제공해 주고, 한 이

러한 로세스들을 표 인 방법으로 의사소통 할 수 있는 능력을 제공하게

된다. BPMN 스펙에서는 BPD의 표기법과 의미를 정의하고 있는데, 기존의

수많은 다른 모델링 표기법들과 들을 하나의 비즈니스 로세스 모델링

표기법으로 표 화하고자 의도하 다. 그 게 함으로써 다른 비즈니스 사용자

들, 로세스 구 가들, 고객들과 공 업자들과 로세스 정보를 의사소통하는

편리한 수단을 제공하려는 것이다. 이를 해서 개발과정에서 기존의 다양한

표기법 방법론들이 검토되었다.

1. BPD 의 범

재 버 의 BPMN은 “비즈니스 로세스”에 용할 수 있는 모델링 개념

만을 지원하도록 한정되어 있다. 따라서 BPD가 제공하는 특징(features)은

로세스의 모델링에 요구되는 그래픽 요소들과 그 의미로 한정된다. 완 한 비

즈니스 로세스 리를 해서는 추가 인 모델들( 를 들어 조직구조, 데이

터 정보 모델, 비즈니스 규칙 등)이 필요하지만, 이는 별도의 기법들에 의

해서 표 되어야 한다. 단, 이와 같은 상 수 는 부가 인 모델링 형식들

은 직 혹은 간 으로 비즈니스 로세스에 향을 주기 때문에, 향후

BPMN과 다른 비즈니스 모델링 사이의 계는 보다 정형화된 형식으로 정의

되게 될 것이다.

- 29 -

비즈니스 로세스 모델링은 매우 다양한 종류의 사람들에게 매우 다양한

종류의 정보를 달하는데 사용된다. BPMN은 많은 모델링 유형들을 처리하

고, 종단간 비즈니스 로세스를 생성할 수 있도록 설계되었다. 종단간 BPMN

모델 내에는 기본 으로 세 가지 하부모델이 존재한다. 이들에 해서는 4장

3 에서 보다 자세히 다루어진다.

비공개 (내부) 비즈니스 로세스: 특정 조직 내부 로세스를 표

추상 (공개) 로세스: 비공개 로세스와 외부 로세스 간 상호작용 표

업 ( 역) 로세스: 두 개 이상의 비즈니스 개체들 간의 상호작용 표

BPMN은 모델링 작업자와 모델링 도구에 의해 확장할 수 있도록 의도되었

다. 이 확장성은 모델링 작업자에게 응용분야의 독특한 요구사항들과 같은 특

정 요구를 충족시키기 한 비표 요소나 인공물(Artifact)을 추가할 수 있도

록 허용하고 있다.

하지만, 이러한 확장성에도 불구하고 BPMN 다이어그램은 어떤 모델링 작

업자가 만든 다이어그램이건 다른 사람이 쉽게 이해할 수 있도록 기본 인 외

은 유지하여야 한다. 따라서 기본 인 흐름 요소들(이벤트, 액티비티, 게이

트웨이)등의 모양은 변경되어서는 안 된다. 아울러 어떠한 흐름 요소도 BPD

에 새로 추가되어서는 안 된다.

BPMN의 시각 요소들은 특별한 표식(marker)들을 이용하여 특별한 정보

를 달하는 것을 허용하도록 개방된 형태로 설계되었다. 를 들면, 이벤트

(Event)의 세 가지 유형은 BPMN 표 표식들뿐만 아니라 사용자 정의 표식

들을 해 모두 앙이 비어있다. 다음 <그림 3-1>은 하나의 를 보여 다.

- 30 -

<그림 3-1> Start 이벤트의 그래픽 요소 - 기본형과 그 변형들

(가) 기본형 (나) 변형들(가) 기본형 (나) 변형들

2 . BPD 의 설 계 개 념

BPMN 특히 BPD의 개발 목 은 표기법을 단순화하고 비즈니스 분석가들

에게 채택되어 리 사용될 수 있게 하는 것이다. 하지만 한편으로는 BPMN

은 복잡한 비즈니스 로세스를 표 하는 능력과 BPM 실행 언어들로의 매핑

도 되어야하는 요구도 함께 충족해야 하는 어려움을 가지고 있다.

이러한 상충되는 요구조건들을 만족시키기 한 근법으로서, BPMN 그

래픽 요소들을 두 그룹으로 나 어 제공한다.

BPD 핵심 요소 집합 (Core Element Set): 간단한 표기법의 요구를 지원하

기 해 제한 개수의 핵심 인 요소들만을 정의한다. 이것은 BPD의 기본

인 외 을 정의하는 요소들이다. 부분의 비즈니스 로세스는 이 요소

들을 가지고 히 모델링될 수 있다.

BPD 체 집합 (Complete Set): 더 진보된 모델링 상황을 다룰 수 있는

강력한 표기법의 요구를 충족하기 한, 핵심 요소를 포함한 요소들의

체 리스트이다. 아울러 표기법의 그래픽 요소들은 실행언어 는 다른 비

즈니스 모델링 목 에 매핑하는데 필요한 추가 정보의 제공을 한 비시각

속성들의 지원을 받는다.

- 31 -

3 . BPD 구성 요소

BPD의 사용자들이 요소의 기본 유형들을 쉽게 인식하고 다이어그램을 이

해할 수 있도록, 표기법 카테고리의 작은 집합으로서 제공되는 체 BPD의

핵심 인 부분집합들을 정리하 다. 요소의 기본 범주 내에서 추가 인 변형

과 정보는 이 핵심요소들 에 다이어그램의 외 상의 큰 변화 없이 복잡성을

지원하기 해 추가될 수 있다. 핵심요소 집합을 구성하는 네 가지 기본 범주

들과 각 범주에 속하는 구성요소들은 다음 <그림 3-2>에 보이는 바와 같다.

BPD는 이들 구성요소들의 시각 요소와 함께 의미 인 정의를 제공한다.

<그림 3-2> BPD 핵심 요소 집합의 구성

흐름객체 (Flow Objects)흐름객체 (Flow Objects)

인공물 (Artifacts)인공물 (Artifacts)

스윔레인 (Swimlanes)스윔레인 (Swimlanes)

연결객체 (Connecting Objects)연결객체 (Connecting Objects)

데이터 객체 (Data Objects)데이터 객체 (Data Objects)

그룹 (Group)그룹 (Group)

레인 (Lane)레인 (Lane)

풀 (Pool)풀 (Pool)

순서흐름 (Sequence Flow)순서흐름 (Sequence Flow)

게이트웨이 (Gateway)게이트웨이 (Gateway)

액티비티 (Activity)액티비티 (Activity)

이벤트 (Event)이벤트 (Event)

메시지흐름 (Message Flow)메시지흐름 (Message Flow)

연관 (Association)연관 (Association)

주석 (Annotation)주석 (Annotation)

흐름객체 (Flow Objects)흐름객체 (Flow Objects)

인공물 (Artifacts)인공물 (Artifacts)

스윔레인 (Swimlanes)스윔레인 (Swimlanes)

연결객체 (Connecting Objects)연결객체 (Connecting Objects)

데이터 객체 (Data Objects)데이터 객체 (Data Objects)

그룹 (Group)그룹 (Group)

레인 (Lane)레인 (Lane)

풀 (Pool)풀 (Pool)

순서흐름 (Sequence Flow)순서흐름 (Sequence Flow)

게이트웨이 (Gateway)게이트웨이 (Gateway)

액티비티 (Activity)액티비티 (Activity)

이벤트 (Event)이벤트 (Event)

메시지흐름 (Message Flow)메시지흐름 (Message Flow)

연관 (Association)연관 (Association)

주석 (Annotation)주석 (Annotation)

- 32 -

가 . 　흐 름 객 체 ( F low O b j ects)

비즈니스 로세스의 행동(behavior)을 정의하는 주요 그래픽 요소들이다.

다음의 세 가지 흐름객체들을 가진다.

(1) 이벤트 (Event)

이벤트는 비즈니스 로세스의 실행 과정 에 발생하는 사건이다. 이벤트

들은 로세스의 흐름에 향을 주며 보통 그 이벤트를 발하는 트리거

(trigger)와 이벤트의 결과(result)를 가진다. 이벤트는 서로 다른 트리거 결

과들을 구별하는 표시를 할 수 있도록 앙이 개방된 원으로 표시된다. 이벤

트는 흐름에 향을 주는 시 을 기 으로 세 가지 유형 (Start 이벤트,

Intermediate 이벤트, End 이벤트)으로 구분된다. 다음의 <그림 3-3>은 Start

이벤트, Intermediate 이벤트, End 이벤트를 순서 로 나타낸 것이다.

<그림 3-3> 이벤트 (Event)

(2) 액티비티 (Activity)

액티비티는 조직이 실행하는 일(work)을 지칭하는 일반 인 용어이다. 액

티비티의 유형은 로세스(Process), 하부- 로세스(Sub-Process), 태스크

(Task)로 나뉘어진다. 태스크와 같이 원자 으로 존재할 수도 있고, 로세스

와 같이 다른 액티비티들 (즉, 태스크 는 하부- 로세스)을 포함(복합)하는

형태로 존재할 수도 있다. 액티비티는 둥근 모서리의 직사각형 표 된다.

- 33 -

<그림 3-4> 액티비티 (Activity)

(3) 게이트웨이 (Gateway)

게이트웨이는 순서흐름(Sequence Flow)의 분기(branch)와 병합(merge)을

통제하는데 사용된다. 따라서 게이트웨이는 흐름 경로(path)의 랜칭

(branching), 포킹(forking), 머징(merging), 조이닝(joining)을 결정한다. 게이

트웨이는 다이아몬드 형태의 심볼로 표시되며 그 내부에는 행동 제어의 형태

를 정의하는 표식(marker)를 추가할 수 있다.

<그림 3-5> 게이트웨이 (Gateway)

나 . 연결 객 체 ( Connecting O b j ects)

비즈니스 로세스의 기본 골격을 만들을 해 흐름 객체들을 연결하는 역

할을 하며, 아래와 같은 순서흐름(Sequence Flow), 메시지흐름(Message

Flow), 계(Association) 등의 세 가지 연결 객체가 있다.

(1) 순서흐름 (Sequence Flow)

순서흐름은 액티비티가 로세스 안에서 수행될 수 있는 순서를 보여주는

데 사용된다. BPMN에서는 “제어 흐름(Control flow)"이라는 용어가 사용되지

- 34 -

않음을 주의해야 한다. 로세스의 순서는 화살표의 방향과 일치한다.

<그림 3-6> 순서흐름 (Sequence Flow)

(2) 메시지흐름 (Message Flow)

메시지흐름은 메시지를 주고받을 비가 된 두 참여자(Participant) 사이에

메시지의 흐름을 보여주는데 사용된다. BPMN에서, 하나의 다이어그램 내의

분리된 두 개의 풀(Pool)은 두 참여자를 나타낸다. 여기서 참여자는 구체 인

비즈니스 개체가 될 수도 있고, 비즈니스 역할이 될 수도 있다.

<그림 3-7> 메시지흐름 (Message Flow)

(3) 계 (Association)

계는 정보를 흐름 객체와 연 시키는데 사용된다. 문자 그래픽 형식

의 비-흐름객체 (non-Flow Object)들은 흐름객체와 계 가능하다. 방향성을

가지거나 방향성을 가지지 않을 수 있다. 방향성을 가지는 경우에는 화살표로

표시한다.

<그림 3-8> 계 (Association)

다 . 스윔 인 ( Sw imlane)

- 35 -

많은 로세스 모델링 방법론들은 서로 다른 기능을 하는 액티비티들을 시

각 으로 분리하기 해 스윔 인(swimlanes)의 개념을 이용한다. BPD에서는

두 가지 형태의 스윔 인이 존재한다.

(1) 풀 (Pool)

풀은 로세스의 참여자를 표 한다. 보통 B2B상황의 다른 풀로부터 액티

비티의 집합을 분할하기 한 시각 컨테이 로서 활용된다. 에 보여지지

않는 디폴트 풀을 포함해서 모든 BPD에는 한 개 이상의 풀이 존재한다.

<그림 3-9> 풀 (Pool)

(2) 인(Lane)

인은 풀 내부의 하부 티션이다. 그리고 수직 는 수평으로 풀의 체

길이까지 확장된다. 인은 액티비티를 조직 으로 편제하고 분류하는데 사용

된다. 로세스 객체들을 조직의 역으로 구분해주는 용도로 쉽게 이해될 수

도 있으나, BPMN 스펙 자체는 명시 으로 그 용도를 제한하고 있지는 않다.

<그림 3-10> 인 (Lane)

라 . 인 공 물 ( A rtifact)

BPMN은 모델링 작업자와 모델링 도구들이 기본 표기법을 확장할 수 있는

- 36 -

약간의 유연성을 제공할 수 있도록 한다. 인공물(Artifact)은 로세스에 한

추가 인 정보를 제공하는데 사용된다. 네 가지 표 화된 인공물이 제공된다.

하지만 모델링 작업자나 모델링 도구는 필요한 만큼의 인공물(Artifact)을 자

유로이 추가할 수 있다.

(1) 데이터 객체(Data Object)

데이터 객체는 인공물로 간주된다. 왜냐하면 그것들이 로세스의 순서 흐

름이나 메시지 흐름에 직 인 향을 주지 않기 때문이다. 하지만 데이터

객체는 어떤 액티비티가 수행되는데 필요한 것 는 그것들이 무엇을 만드는

지에 한 정보를 제공한다.

<그림 3-11> 데이터 객체

(2) 그룹(Group)

액티비티의 그룹화는 순서흐름(Sequence Flow)에 향을 주지 않는다. 그

룹화는 문서화(documentation) 는 분석 목 으로 사용될 수 있다. 그룹들은

풀(Pool)들 사이를 넘나드는 분산 트랜잭션의 액티비티들을 식별하는데도 사

용될 수 있다.

<그림 3-12> 그룹

- 37 -

<표 3-1> BPD의 핵심요소

요소 내 용 표기법

이벤트

(Event)

이벤트는 비즈니스 로세스의 과정동안

“일어나는” 무엇이다. 이 이벤트들은 로

세스의 흐름에 향을 주고 보통 하나의 원

인(트리거, trigger) 는 하나의 향(결과)

을 가진다. 이벤트는 다른 종류의 트리거나

결과를 구분하기 한 내부 표식을 허용하

기 해 앙이 개방된(뚫린) 원으로 표

된다. 이벤트는 흐름(flow)에 향을 때

를 기 으로 세 가지 유형 (Start,

Intermediate, End)을 가진다.

액티비티

(Activity)

액티비티는 기업에서 실행하는 일에 한

일반 인 용어이다. 액티비티는 원자 이거

나 비원자 (합성)일 수 있다. 로세스 모

델(Process Model)의 일부인 액티비티의

유형은 로세스(Process), 하부- 로세스

(Sub-Process), 태스크(Task)등이다. 태스

크와 하부- 로세스는 둥근 직사각형이다.

로세스는 풀 (Pool) 내부에서 묶일 수도

있고, 그 지 않을 수도 있다.

게이트웨이

(Gateway)

게이트웨이는 순서흐름 (Sequence Flow)의

분산과 집 을 제어하는데 사용된다. 즉, 게

이트웨이는 경로(path)의 랜칭

(branching), 포킹(포킹), 머징(merging), 조

이닝(joining)을 결정한다. 내부의 표식

주석 (Annotation)

텍스트 주석은 모델링 작업자가 BPD를 읽을 사람들을 해서 추가 인 정

보를 제공하기 한 메커니즘이다.

<그림 3-13> 해설

다음 <표 3-1>은 비즈니스 로세스 모델링 표기법을 통해 묘사될 수 있

는 비즈니스 로세스 개념의 핵심 모델링 요소들의 목록이다.

- 38 -


(marker)은 동작제어의 유형을 나타낸다.

순서흐름

(Sequence

Flow)

순서흐름(Sequence Flow)은 액티비티가 하

나의 로세스(Process) 내에서 수행되는

순서를 보여주는데 사용된다.

메시지흐름

(Message

Flow)

메시지흐름은 메시지를 주고받을 비가 되

어있는 두 참여자 사이에 메시지의 흐름을

보여주는데 사용된다. BPMN에서는, 다이

어그램의 두 개의 분리된 풀(Pool)들이 두

참여자를 표 한다. ( 를 들어, 비즈니스

개체 는 비즈니스 역할)

계

(Association)

계(Association)는 정보를 흐름객체와

계시키는데 사용된다. 문자 그래픽 형식

의 비-흐름객체 (non-Flow Object)들은 흐

름객체와 계 가능하다.

풀 (Pool)

풀(Pool)은 로세스의 참여자를 표 한다.

풀은 한 보통 B2B 상황에서 다른 풀로부

터 액티비티의 집합을 분할하기 한 그래

픽 컨테이 로서 활용된다.

인 (Lane)

인(Lane)은 풀(Pool) 내부의 하부 티션

으로서, 수직 는 수평으로 풀의 체 길

이까지 확장한다. Lane은 액티비티들을 조

직 으로 편제하고 분류하는데 사용된다.

데이터 객체

(Data Object)

데이터 객체는 인공물(Artifact)로 간주된

다. 왜냐하면 그것들이 로세스의 순서흐

름(Sequence Flow)이나 메시지 흐름

(Message Flow)에 직 인 향을 주지

않기 때문이다. 하지만 데이터 객체는 액티

비티가 수행되는데 어떤 것들이 필요한지

는 액티비티들이 무엇을 생성해 내는지에

한 정보를 제공한다.

그룹 (Group)

액티비티의 그룹화는 순서흐름(Sequence

Flow)에 향을 주지 않는다. 그룹화는 문

서화 는 분석 목 으로 사용될 수 있다.

그룹들은 풀(Pool)들 사이를 넘나드는 분산

트랜젝션의 액티비티들을 식별하는데도 사

용될 수 있다.

주석

(Text

Annotation)

텍스트 주석은 모델링 작업자가 BPD를 읽

을 사람들을 해서 추가 인 정보를 제공

하기 한 메커니즘이다.

- 39 -

<표 3-2> BPD의 완 한 집합


이벤트 (Event)

이벤트는 비즈니스 로세스의 과

정동안 “일어나는” 무엇이다. 이

이벤트들은 로세스의 흐름에

향을 주고 보통 하나의 원인(트리

거, trigger) 는 하나의 향(결

과)를 가진다. 이벤트는 흐름

(flow)에 향을 때를 기 으

로 세 가지 유형 (Start,

Intermediate, End)을 가진다.

>흐름(flow) 차원

( , Start, Intermediate,

End)

Start (None, Message,

Timer, Rule, Link,

Multiple)

Intermediate (None,

Message, Timer,

Cancel, Compensation,

Rule, Link, Multiple)

End (None, Message,

Cancel, Compensation,

Link, Terminate,

Multiple)

이름이 암시하듯이, Start 이벤트

는 특정 로세스가 시작하는 곳

을 나타낸다.

Intermediate 이벤트는 Start이벤

트와 End 이벤트 사이에서 발생

한다. 로세스의 흐름에 향을

주지만 로세스를 시작하거나 직

으로 종료시키지는 않는다.

이름이 암시하듯이, End 이벤트는

로세스가 종료하는 곳을 나타낸

다.

>유형(Type) 차원 ( ,

Message, Timer,

Error, Cancel,

Compensation, Rule,

Link, Multiple,

Terminate)

Start와 부분 Intermediate 이벤

트는 이벤트에 한 원인을 정의

하는 트리거(trigger)를 갖는다. 이

이벤트가 유발되는 많은 방법이

있다. End 이벤트는 순서흐름

(Sequence Flow) 결말의 결과인

“결과(Result)”로 정의 된다.

다음의 <표 3-2>는 비즈니스 로세스 모델링 표기법을 통해 표 할 수

있는 비즈니스 로세스 개념의 체 목록을 나타낸다.

- 40 -


태스크 (원자 )

(Task (Atomic))

태스크(Task)는 로세스 내에 포

함된 원자 액티비티이다. 태스

크는 로세스(Process)의 작업이

더 이상 세부 로세스 모델

(Process Model)로 분해되지 않을

때 사용된다.

로세스/하부- 로세스

(비 원자 )

(Process/Sub-Process

(non-atomic))

하부- 로세스는 하나의 로세스

(Process) 내에 포함된 복합 액티

비티이다. 이것은 하부-액티비티

들의 집합을 통해 더 미세한 세부

수 ( 로세스)으로 분해될 수 있

는 집합이다.

아래에 나오는 두 개의 그림

참고

> 힌 하부- 로세스

(Collapsed

Sub-Process)

하 부 - 로세스( Sub - Process) 의

세부사항들은 다이어그램에서 보

여지지 않는다. 앙 아래쪽의 더

하기 기호는 이 액티비티가 서

로세스이고 하부 단계의 상세도

수 을 가진다는 것을 표시한다.

> 펼쳐진 하부-

로세스 (Expanded

Sub-Process)

하부 로세스의 경계가 확장되고

세부내용(하나의 로세스)은 그

경계 내에 보여진다.

순서흐름(Sequence Flow)은 하부

- 로세스의 경계를 넘나들 수 없

음을 주의해라.

게이트웨이 (Gateway)

게이트웨이는 순서흐름

(Sequence Flow)의 분산과

집 을 제어하는데 사용된다. 즉,

게이트웨이는 경로(path)의

랜칭(branching), 포킹(포킹),

머징(merging), 조이닝(joining)을

결정한다.

> 게이트웨이 제어

유형들

(Gateway Control

Types)

다이아몬드 모양 안에 아이콘들은

흐름 제어 행동의 유형을 나타낸

다. 제어의 유형들은 다음과 같다.

XOR - 배타 (exclusive) 결

정과 머징(merging), 데이터

기반 (Data-based) 는 이벤

트 기반 (Event-based). 데이

터 기반은 "X" 표식을 가지거

- 41 -


나 표식 없이 보여질수 있다.

OR - 포 인(inclusive)결정

과 머징(merging)

Complex - 복잡한 조건과 상

황들 ( , 5개 3개)

AND - 포킹(포킹)과 조이닝

(joining)

각각의 제어 유형은 들어오고

나가는 흐름(Flow)에 향을

다.

순서흐름

(Sequence Flow)

순서흐름(Sequence Flow)은 액티

비티가 하나의 로세스(Process)

내에서 수행되는 순서를 보여주는

데 사용된다.

아래에 나오는 일곱 개의 그

림 참고

> 정상흐름 (Normal

Flow)

정상 순서흐름 (Sequence Flow)

은 Start 이벤트로부터 시작하여,

안 경로, 병렬 경로들을 지나는

액티비티들을 통해 연속되어 End

이벤트에서 정상 으로 끝나는 흐

름을 의미한다.

>>비제어 흐름

(Uncontrolled

flow)

비제어 흐름은 어떤 조건에도

향을 받지 않는 흐름 는 게이트

웨이를 통과하지 않는 흐름을 말

한다. 이것의 가장 간단한 는

두 액티비티를 연결하는 단일 순

서흐름(Sequence Flow)이다. 이것

은 한 액티비티에 수렴 되거나

액티비티로부터 분산된 다 순서

흐름(Sequence Flow)에 용된다.

각각의 비제어 순서흐름

(Sequence Flow)에 하여 “토큰

(Token)”은 근원(source) 객체부

터 목표 (target) 객체까지 흐른

다.

>>조건부 흐름

(Conditional

flow)

순서흐름(Sequence Flow)은 그

흐름이 사용될지 안 될지를 실행

시간에 평가하는 조건식을 가질

수 있다. 조건부 흐름이 액티비티

로부터 나간다면, 순서흐름

(Sequence Flow)은 라인의 시작

에 작은 다이아몬드 모양을 가질

것이다 (오른쪽 그림을 보라). 조

- 42 -


건 흐름이 게이트웨이로부터 나간

다면, 라인은 작은 다이아몬드를

가지지 않을 것이다( 행의 그림

을 보라).

>>디폴트 흐름

(Default flow)

데이터 기반 (Data-based) 배타

(Exclusive) 결정이나 포

(Inclusive) 결정을 한 흐름의

한 가지 유형은 디폴트조건

(Default Condition) 흐름이다. 이

흐름은 다른 모든 조건부 흐름이

실행시간에서 사실이 아닐 경우에

만 사용된다. 이 순서흐름

(Sequence Flow)은 라인의 시작

부분에 각선표시가 추가된다(오

른쪽 그림을 보라).

> 외 흐름

(Exception Flow)

외 흐름(Exception Flow)은

로세스의 정상흐름 (Normal

Flow) 외부에서 발생하고 로세

스 에 일어나는 Intermediate

이벤트를 기반으로 한다.

메시지흐름 (Message

Flow)

메시지흐름은 메시지를 주고받을

비가 되어있는 두 참여자 사이

에 메시지의 흐름을 보여주는데

사용된다. BPMN에서는, 다이어그

램의 두 개의 분리된 풀(Pool)들

이 두 참여자를 표 한다. ( 를

들어, 비즈니스 개체 는 비즈니

스 역할)

보상 계

(Compensation

Association)

보 상 계 ( C o m p e n s a t i o n

Association)은 로세스의 정상

흐름(Normal Flow) 외부에서 발

생하며, 트랜잭션(Transaction)

는 보상 (Compensate) 이벤트의

실패를 통해 유발된 이벤트

(Cancel Intermediate 이벤트)를

기반으로 한다. 계의 표

(target)은 보상 액티비티

(Compensation Activities)로 표시

되어야 한다.

- 43 -


데이터 객체

(Data Object)

데이터 객체는 인공물(Artifact)로

간주된다. 왜냐하면 그것들이

로세스의 순서흐름(Sequence

Flow)이나 메시지 흐름(Message

Flow)에 직 인 향을 주지

않기 때문이다. 하지만 데이터 객

체는 액티비티가 수행되는데 어떤

것들이 필요한지 는 액티비티들

이 무엇을 생성해 내는지에 한

정보를 제공한다.

포크 (AND-Split)

(Fork (AND-Split))

BPMN은 두 개 이상의 병렬 경로

(path)로의 분할을 나타내기 해

“포크(fork)”라는 용어를 사용한다

(AND-Split으로 도 부른다). 이것

은 로세스 상의 액티비티들이

순서 이 아니라 동시에 수행될

수 있는 부분으로서, 다음과 같

은 두 가지 옵션을 가진다.

다 방출 순서흐름(Multiple

Outgoing Sequence Flow)_가 사

용될 수 있다(오른쪽 의 그림을

보라). 이것은 비제어 흐름을 표

하는 것으로서 부분의 상황에서

선호되는 방법이다.

병렬(Parallel) ( 는 AND) 게이

트웨이가 사용될 수 있다(오른쪽

아래 그림을 보라). 이것은 드물게

사용되며, 일반 으로 다른 게이

트웨이와 함께 결부되어 사용된

다.

조인 (AND-Join)

(Join (AND-Join))

BPMN은 하나의 경로로 들어오는

둘 이상의 병렬경로의 합류을 지

칭하는 “조인(join)”이라는 용어를

사용한다(AND-Join 는 동기화

(synchronization)로 불린다).

병렬(Parallel) ( 는 AND) 게이

트웨이가 다 흐름의 합류를 보

여주는 조인을 표시하는데 사용된

다.

- 44 -


결정 (Decision),

분기 (Branching

Point);

(OR-Split)

결정(Decision)은 제어의 흐름이

하나 는 더 많은 안 패스를

택할 수 있는 비즈니스 로세스

내의 게이트웨이이다.

아래에 나오는 다섯 개의 설

명 참고

>배타 (Exclusive)

배타 게이트웨이(XOR)는 안

(Alternatives) 집합 오직 하나

만이 실행시간 에 선택되도록

흐름을 제한한다. 배타 게이트

웨이에는 두 가지 유형이 있다:

데이터 기반 (Data-based)과 이벤

트 기반(Event-based).

>>데이터 기반

(Data-Based)

이 결정(Decision)은 안

(Alternative)들이 방출 순서흐름

(Sequence Flow)에 포함된 조건

식 (conditional expression)들을

기반으로 하고 있는 분기 을 나

타낸다. 안들 오직 하나만이

선택될 것이다.

>>이벤트 기반

(Event-Based)

이 결정(Decision)은 안들이

로세스 안 특정 시 에서 발생하

는 이벤트에 근거로 하는 분기

을 나타낸다. 그 특정 이벤트(보

통 Message의 수신)는 어떤 경로

를 택할 것인지를 결정한다. 타이

머(Timer)와 같은 다른 유형의 이

벤트들도 사용될 수 있다. 안들

오직 하나만이 선택된다. 메

시지의 수령은 다음 두 옵션이 있

다.

- 수신 유형 (Type Receive) 태

스크들의 사용(오른쪽 그림)

- 수신 유형 (Type Receive)

Intermediate 이벤트들의 사용(오

른쪽 아래 그림)

- 45 -


>포 (Inclusive)

이 결정은 안(Alternative)들이

방출(outgoing) 순서흐름

(Sequence Flow)내에 포함된 조

건식에 기 으로 하는 분기 을

나타낸다.

각 경로가 서로 독립 이기 때문

에 (0 부터 모든) 경로의 조합이

선택될 수 있다. 하지만 어도

한 경로는 선택될 수 있도록 만들

어져야 한다. 디폴트 조건(Default

Condition)은 어도 한 패스가

택해질 수 있도록 보장하기 해

사용된다.

이 결정의 유형에는 다음의 두 가

지 버 이 있다.

첫 번째는 작은 다이아몬드표시를

가진 조건부 순서흐름(Sequence

Flow)의 모임을 이용(오른쪽

그림).

두 번째는 보통 다른 게이트웨이

와 함께 OR 게이트웨이를 이용

(오른쪽 아래 그림).

머징 (OR-Join)

(Merging)

BPMN은 둘 이상의 배타 경로

가 하나의 경로로 합류되는 것을

지칭하기 해 "머지(merge)"라는

용어를 사용한다(OR-Join으로도

불린다).

머징(Merging 는 XOR) 게이트

웨이는 여러 개의 흐름이 하나로

합병하는 것을 보여주는데 사용된

다. 만약 모든 도입 흐름이 서로

안 (alternative)라면 게이트웨

이는 필요하지 않다. 즉, 비제어

흐름이 같은 행동을 제공한다.

루핑 (Looping)

BPMN은 하나의 로세스

(Process) 내에 루핑(looping)을

한 두 가지 메커니즘을 제공한

다.아래에 나오는 두 개의 그림

참고

- 46 -


> 액티비티 루핑

(Activity Looping)

태스크(Task)와 하부- 로세스의

속성들은 그것들이 되풀이되거나

한번만 수행될지를 결정한다. 루

(loop)에는 두 가지 유형이 있

다: Standard 와 Multi-Instance.

작은 루핑 표식을 액티비티의

앙 하단에 표시한다.

> 순서흐름 루핑

(Sequence Flow

Looping)

루 들은 순서흐름(Sequence

Flow)을 "상류(upstream)" 객체로

연결함으로써 생성될 수 있다. 어

떤 객체의 상류객체란 상 개체

에 까지 이르는 일련의 순서흐름

(Sequence Flow)으로 이어지는

방출 순서흐름(Sequence Flow)을

가지는 객체를 의미한다.

다 인스턴스

(Multiple Instances)

태스크(Task)와 하부 로세스의

속성들은 그것들이 반복될 것인지

한번만 수행될 것인지를 결정한

다. 작은 병렬 표식을 액티비티의

앙 하단에서 표시한다.

로세스 이크

(Process Break)

( 로세스의 제어를

벗어나는 경우

로세스의

휴지(休止)를 래)

로세스 이크 (Process

Break)는 로세스 내에서 상된

지연이 발생하는 곳을 나타낸다.

하나의 Intermediate 이벤트가 실

제 인 동작을 보여주는데 사용된

다(오른쪽 그림). 아울러 해당 흐

름 내에 지연이 발생되는 곳을 표

시하기 하여, 모델링 작업자

는 모델링 도구에 의해 디자인된

로세스 이크 인공물

(Artifact)이 이벤트와 계될 수

있다.

트랜잭션

(Transaction)

트랜잭션(transaction)은 련된

모든 당사자들 간에 액티비티가

완료되거나 아니면 취소되어야 한

다는 에 완 한 동의를 갖도록

보장하는 특별한 로토콜에 의해

지원되는 하부- 로세스이다. 액

티비티의 속성들은 액티비티가 트

랜잭션인지를 결정한다. 겹 의

경계선은 하부- 로세스가 트랜잭

션(Transaction)임을 의미한다.

- 47 -


첩/내장

하부- 로세스 (Inline

Block)

(Nested/Embedded

Sub-Process)

첩( 는 내장) 하부- 로세스는

그것의 부모 로세스와 같은 데

이터 집합을 공유하는 액티비티이

다. 이것은 독립 이고 재사용 가

능하며 부모 로세스로부터 참조

되는 하부- 로세스와는 반 된

다.

데이터는 참조된 하부- 로세스로

는 달될 필요가 있으나, 첩

하부- 로세스에는 필요하지 않

다.

첩 하부- 로세스에 한

구체 인 표시는 없다.

그룹 (Group)

액티비티의 그룹화는 순서흐름

(Sequence Flow)에 향을 주지

않는다. 그룹화는 문서화 는 분

석 목 으로 사용될 수 있다. 그

룹들은 풀(Pool)들 사이를 넘나드

는 분산 트랜젝션의 액티비티들을

식별하는데도 사용될 수 있다.

오 -페이지 연결자

(Off-Page Connector)

일반 으로 린 을 해 사용되

는 이 객체는 순서흐름(Sequence

Flow)이 어디에서 한 페이지를

떠나고 다음 페이지에서 재개되는

지를 보인다. 링크(Link)

Intermediate 이벤트는 오 페이

지 연결자(Off Page Connector)로

사용될 수 있다.

계 (Association)

계(Association)는 정보를 흐름

객체와 계시키는데 사용된다.

문자 그래픽 형식의 비-흐름객

체 (non-Flow Object)들은 흐름

객체와 계 가능하다.

주석 (Text

Annotation)

텍스트 주석은 모델링 작업자가

BPD를 읽을 사람들을 해서 추

가 인 정보를 제공하기 한 메

커니즘이다.

풀 (Pool)

풀(Pool)은 로세스의 참여자를

표 한다. 풀은 한 보통 B2B

상황에서 다른 풀로부터 액티비티

의 집합을 분할하기 한 그래픽

컨테이 로서 활용된다.

- 48 -


인 (Lane)

인(Lane)은 풀(Pool) 내부의 하

부 티션으로서, 수직 는 수평

으로 풀의 체 길이까지 확장한

다. Lane은 액티비티들을 조직

으로 편제하고 분류하는데 사용된

다.

- 49 -

<표 3-3> BPEL4WS 매핑 규칙 요약

매핑 상 요소 설명

공통 객체

(Common

Object)

BPD 매핑

BPD 자체의 속성들에 한 매핑 (Id,

Name, Version, Language 등) 정의

부록 A-6.1 참조

비즈니스 로세스 매핑

BPD를 구성하는 단 로세스 자체에

속한 속성의 매핑 정의

단 로세스는 Pool에 의해서 구분됨

부록 A-6.2 참조

공통 흐름객체 매핑

흐름객체(Events, Activities, Assignments)

들에 공통되는 속성들의 매핑 정의

부록 A-6.3 참조

제 2 BPE L4 W S로의 매 핑

BPMN으로 표 된 비즈니스 로세스는 비즈니스 로세스 모델링 언어

실행 언어로 변환될 수 있어야 한다. BPMN이 높은 수 의 표 력을 확보

하는 과정의 한편에서는 모델링 실행언어로의 매핑이 복잡해지고 어려워지

는 문제가 발생하게 된다. BPMN 모델을 표 인 실행언어인 BPEL4WS로

변환하는데 있어서 발생되는 모호성은 업에서 꾸 히 보고되어지고 있다.

한 BPMN 스펙에 정의된 매핑 규칙들은, BPD 요소(element)들과

BPEL4WS 요소들 간의 1:1 응 계를 규정하고 있으나, 이것만으로는

BPD-BPEL4WS 변환기의 개발에는 충분한 지침을 제공하지 못한다. 재

BPMN 스펙에서 정의하고 있는 매핑 규칙의 구조는 다음의 <표 3-3>에 정

리된 바와 같다.

- 50 -


이벤트

(Event)

Start 이벤트 매핑Start 이벤트들의 매핑 정의

부록 A-6.4.1 참조

Intermediate 이벤트 매핑

9 종류의 Intermediate 이벤트들의 매핑

정의

부록 A-6.4.3 참조

End 이벤트 매핑End 이벤트들의 매핑 정의

부록 A-6.4.2 참조

액티비티

(Activity)

공통 액티비티 매핑Activity들의 공통 속성의 매핑 정의

부록 A-6.5.1 참조

하부- 로세스 매핑3 종류의 Sub-Process에 한 매핑 정의

부록 A-6.5.2 참조

태스크 매핑8 종류의 Task에 한 매핑 정의

부록 A-6.5.3 참조

게이트

웨이

(Gateway)

공통 게이트웨이 매핑

여러 종류의 Gateway들의 공통속성 매핑

정의

부록 A-6.6.1 참조

배타 게이트웨이 매핑

2 종류의 Exclusive Gateway의 속성에

한 매핑 정의

부록 A-6.6.2 참조

포 게이트웨이 매핑

Inclusive Gateway의 속성에 한 매핑

정의

부록 A-6.6.3 참조

복합 게이트웨이 매핑매핑 정의할 만큼 충분히 정립되지 못함

부록 A-6.6.4 참조

병렬 게이트웨이 매핑Parallel Gateway (AND)의 매핑 정의

부록 A-6.6.5 참조

풀 (Pool)실행언어에 매핑 요소 없음

부록 A-6.7 참조

- 51 -


인 (Lane)실행언어에 매핑 요소 없음

부록 A-6.8 참조

인공물(Artifacts)

Artifact는 실행언어로 매핑하지 않는

것이 원칙

부록 A-6.9 참조

순서흐름 (Sequence Flow)

부분의 경우 BPEL4WS로 매핑이 필요

없으나, link 요소로 변환되는 경우에

속성들의 매핑 정의

부록 A-6.10 참조

메시지흐름 (Message Flow)

BPEL4WS로 특별히 매핑 안 되며, 신

WSDL operation으로 매핑


계 (Association)

BPEL4WS로 특별히 매핑하지 않는 것이

원칙


외흐름 (Exception Flow)

BPMN Exception Flow의 유연성으로

인해서, 구조화된 Exception handling

방식의 BPEL4WS 로의 매핑에 어려움

있음. 4 가지 형 패턴의 Exception

Flow들의 매핑 정의


보상 계 (Compensation Association)Compensation Association 매핑 정의


할당 (Assignment) 매핑Assignment (from-to) 식의 매핑 정의


다음은 BPMN을 BPEL4WS로 매핑하는 제이다. 제로 들고 있는 “이메

일 투표 로세스"는 작지만 복잡성을 가지고 있으며 BPMN의 특징들을 부

분 표 할 수 있는 제이다. 여기에서는 무한 루 와 같은 비즈니스 로세

- 52 -

스의 외 인 특징들을 가지고 있다.

<그림 3-14> 이메일 투표 로세스

로세스는 매주 요일에 로세스를 실행시키도록 세 된 타이머 Start

이벤트에 의해 시작된다. 투표 리스트(voting list) 리자는 투표 리스트를 검

토하고 Discussion Cycle과 Voting Cycle에 들어갈 비가 된 투표가 있는지

결정할 것이다.

비된 투표 목록이 없다면, 이번 주 로세스는 끝이 나고, 다음 주에 다

시 시작된다. 비된 투표 목록이 있다면 로세스는 Discussion Cycle을 진

행할 것이다. "Discussion Cycle" 하부- 로세스는 "Any issues ready?" 결정

이후의 첫 번째 액티비티이며 루 로세스이다.

여기에서는 "이메일 투표 로세스"의 첫 번째 하부- 로세스인

Discussion Cycle 까지를 BPEL4WS로 매핑하는 를 설명한다.

로세스의 매 핑

BPEL4WS의 process들은 반드시 receive 액티비티로부터 시작된다.

“E-Mail Voting Process"는 타이머 Start 이벤트에 의해 매주 요일에 시작

- 53 -

<그림 3-15> “이메일 투표 로세스"의 시작 로세스

되도록 스 된다. 따라서 매주 요일에 투표 목록을 가진 시작 메시지를

“이메일 투표 로세스”에 보내는 추가 인 로세스가 필요하다. <그림

3-15>는 이러한 로세스를 보여 다.

<그림 3-14>의 메인 로세스 내에 있는 “Receive Issue List" 작업은

”Yes"로 세 된 createInstance 속성을 가지고 있는 BPEL4WS receive

에 매핑된다. 이것은 시작 메시지를 받는 것이며 process를 시작하는 것

이다.

receive 액티비티를 따르는 다른 액티비티들 때문에 sequence 내부에

치한다.

받은 메세지는 기화된 값들과 process에 사용되는 모든 variable

parts에 포함된다. 로세tm의 모델러에 의해 정의된 속성들은

“processData"라고 명칭된 BPEL4WS variable들에 치한다. 같은

variable 요소는 이 제에서 시작된 모든 processe들에 사용된다.

"Review Issue List" 작업은 BPEL4WS invoke에 매핑된다. 이

TaskType 은 invoke 가 동기식이며 outputVariable 이 포함되었다는

뜻을 의미하는 사용자이다.

- 54 -

배 타 게 이 트 웨 이 의 매 핑

“Any Issues Ready?” 결정(배타 게이트웨이)은 BPEL4WS switch에

매핑된다.

“NO" 순서 흐름을 한 게이트는 switch의 otherwise case에 매핑된다.

otherwise는 로세스가 끝나고 할 수 있는 것이 아무것도 없기 때문에

오직 empty activity를 포함한다.

“Yes" 순서 흐름을 한 게이트는 switch의 other case에 매핑된다. 이

case는 비한 많은 수의 투표들을 체크하는 condition을 가지고 있다.

이 case는 <그림 3-14>에 표 한 로세스의 나머지를 다룬다.

인 터 리 루 의 향

만약 루 가 단지 단순한 루 라면, 아마도 only loop 즉, BPEL4WS while

루 를 사용한다. 하지만, 이러한 상황에서 루핑은 (웹 서비스로서) invoking

을 통해 근되고 시작되는 로세스의 집합에 의해 조정된다. 시작된

processe들을 표 하기 한 특정한 다이어그램 요소가 없다. 게다가 모델링

작업자는 복잡한 루핑을 조정하기 해 련된 로세스들의 집합을 만들지 않

는다. 실행 엔진이 언어문서와 요소들의 복잡한 집합을 쉽게 다루지만, 비즈니

스 개발자와 이 로세스를 모니터하는 사람들은 쉽게 읽을 수 있도록 BPMN

과 같은 로세스로 보여지길 원한다. <그림 3-14>에서 보여진 로

“Discussion Cycle" 하부- 로세스는 ”Discussion_Cycle_Derived_Process"

process를 해 (구제 인 receive 후에) 순서를 계속 진행한다.

액 티 비티 루 조 건의 매 핑

“Disccusion Cycle" 로세스는 루 표식(loop marker)를 가진다. 이러한

- 55 -

상황에서 루핑 메커니즘은 단순하다. “Disccusion Cycle" 하부- 로세스와

련된 속성은 LoopType:“Standard”; LoopCondition:DiscussionOver

=“FALSE”; 그리고 TestTime:“After.”이다. 이것은 process를 요청하는 invoke

는 BPEL4WS가 시작될 때 while 액티비티 내에 넣어진다는 뜻이다.

LoopType은 BPEL4WS while에 매핑된다. ( 에서 보여진) 로세스의

LoppCondition은 while을 한 조건인 “DiscussionOver = False”에 매

핑된다.

“DisscussionOver" 를 한 기본 값은 False이다. 게다가 하부- 로세스

내에 있는 액티비티는 while 루 가 끝나기 에 True로 바 게 되고,

while은 내부에 있는 액티비티가 실행되기 에 조건을 테스트한다.

LoopCounter은 0으로 기값을 맞춰놓고 assign은 흐름 상 while 요소

보다 먼 추가된다.

while의 activity는 하부- 로세스를 한 invoke를 가진 sequence로 변

화된다.

<그림 3-16> “이메일 투표 로세스” 시작 로세스의 BPEL4WS 매핑결과

- 56 -

다음은 <그림 3-14> 이메일 투표 로세스의 BPD를 BPEL4WS로 매핑한 결

과이다.

- 57 -

<그림 3-17> 이메일 투표 로세스의 BPEL4WS 매핑 결과

- 58 -

제 4 장 BPMN 분 석 활 용 방 안

제 1 로세스 모델링 표기법 비교 분 석

로세스 설계시 로세스의 정확한 이해와 설계, 교환을 해 로세스

실행언어가 아닌 로세스 모델링 표기법을 이용해 설계하게 된다. 로세스

모델링 표기법은 해당 실행언어에 특화된 것일 수도 있고, 는 실행 언어에

무 하게 범용 으로 사용되는 표기법일 수도 있다. 본 에서는 페트리넷,

UML Activity Diagram, IDEF3, 순서도 등 실행 언어에 독립 으로 사용되는

로세스 표기법들과 본 연구에서 상으로 하고 있는 BPMN을 비교 분석하

다.

1. 로세스 모델링 표기법

가 . 페 트 리넷 ( Petri Net)

페트리넷은 상태가 변화하는 시스템을 모델링하는 방법으로, 시스템을 도

식화하는 동시에 수식으로 표 할 수 있는(Mathematical formalism) 방법론이

다. 페트리넷은 1962년 제안된 이후 많은 확장들이 제안되었고, 통신, 생산 등

다양한 분야에서 분산 시스템의 설계, 로세스 모델링, 성능 분석, 시뮬 이

션 등의 목 에 사용되고 있다.

페트리넷은 시스템을 상태(Place)와 이(Transition), 그리고 이들 사이를

잇는 연결(Link)로 표 한다. 페트리넷으로 모델링된 시스템은 특정 상태에서

그에 연결된 이에 해당하는 활동 는 사건에 의해 다른 상태로 변화한다.

페트리넷에서는 시스템의 가능한 상태 이 조건뿐만 아니라 재 시스템

의 상태 한 나타낼 수 있는데, 이는 토큰(Token)을 사용함으로써 가능하다.

- 59 -

토큰은 다이어그램 내의 특정 상태에 치함으로써 시스템이 해당 상태에 있

음을 나타낸다. 토큰은 여러 개의 상태들을 잇는 이, 즉 AND 분기/병합에

의해 두 개 이상으로 늘어나거나 다시 하나로 어들 수 있다. 아래의 표는

로세스 모델링에 사용될 수 있는 페트리넷의 표기들과 그 기능들에 해 설

명하고 있다.

<표 4-1> 페트리넷의 표기

표기 이 름 설 명

이(Transition)재상태를 장소에서 장소로 이시키는

행 . 로세스의 활동 사건을 나타낸

다.

상태(Place)로세스가 가질 수 있는 상태들을 나타

낸다.

토큰(Token)특정 장소에 치함으로써 로세스의

재 상태를 나타낸다.

연결(Link)이에서 장소로, 장소에서 이로의 연

결. 이에서 이, 장소에서 장소로는 연

결할 수 없다.

다음의 <그림 4-1>은 페트리넷으로 표 된 로세스의 시이다. 로 제

시된 로세스는 구매주문을 처리하는 간단한 로세스로, 구매주문서를 수신

하는 것으로 시작하여 해당 고객의 신용 정보를 조회한 뒤, 고객 신용도에 따

라 거 문서를 발송하거나, 는 가격을 계산하여 견 서를 발송한다.

- 60 -

<그림 4-1> 페트리넷의 로세스 시

구매주문서수신

신용도평가

고객데이터조회

거절문서발송가격계산

견적서발송

수신대기

주문수신완료

조회완료

신용도>1

문제없음

완료견적서준비


신용도평가


거절문서발송가격계산

견적서발송

수신대기

주문수신완료

조회완료

신용도>1

문제없음

완료견적서준비

다음의 <그림 4-2>는 동일 로세스를 BPMN으로 표 한 결과이다. 페트

리넷에서는 ‘상태’를 통해 로세스 인스턴스가 처한 상태를 악할 수 있으나

BPMN으로 표 된 로세스에서는 상태를 나타내는 표기가 존재하지 않는다.

그리고, BPMN에서는 메시지를 수신하거나 발신하는 행 가 타 행 들과는

다른 표기로 표 된다. 즉 사건과 활동이 구분되나, 페트리넷에서는 두 경우

모두 이로 나타나게 된다.

<그림 4-2> BPMN의 로세스 표기 시


가격계산신용도평가

거절문서발송고객데이터

구매주문수신

신용도>1

견적서발송



거절문서발송고객데이터

구매주문수신

신용도>1

견적서발송

- 61 -

나 . U ML A ctiv ity D iagram

UML은 객체지향 소 트웨어 설계를 해 OMG에 의해 제안된 모델링 방

법론이다. UML은 시스템의 정 /동 구조를 나타내는 여러 개의 다이어그램

들로 구성되는데, Activity Diagram은 시스템의 동 설계를 로세스의 형태

로 나타낸 다이어그램이다.

재 부분의 UML 설계도구들에서 지원하는 UML v1.4의 제안 이후로

UML을 다른 분야에의 설계로 확 하는 데에 을 맞춘 UML 2.0이 제안되

었는데, 이 제안에서 Activity Diagram이 보다 풍부한 로세스 표 방식들

을 가지도록 많은 확장을 하 다. 따라서 본 보고서에서는 UML 2.0의

Activity Diagram을 설명한다.

UML Activity Diagram은 로세스의 핵심을 구성하는 활동(Activity)과

그들을 잇는 순차(Sequence)로 표 된다. 한 외부와의 상호작용을 한 사

건(Event)를 표 하기 해 신호(Signal) 노테이션을 제공한다. 신호는 외부에

서 내부로, 내부에서 외부로의 방향성을 가지고 표기된다. Activity Diagram에

서는 활동들 간의 데이터 입출력을 나타내기 해 객체(Object)를 제공하는데,

객체는 활동에 핀 형태로 첨부되어 입력과 출력을 나타내거나 순차에 첨부되

어 선행 활동에서 후행 활동으로 달되기도 하고, 는 활동과 같이 순차에

의해 연결되어 객체 흐름을 나타낼 수도 있다. 그 외에도 로세스의 외상

황(Exception), 루 등의 제어문, 수행자 등을 나타내기 한 표 방법을 제

공한다. 아래 표는 로세스 설계에 사용되는 Activity Diagram의 표기들과

그 기능들에 해 설명하고 있다.

- 62 -

<표 4-2> UML Activity Diagram의 표기


활동(Activity) 로세스의 활동을 나타낸다.

객체(Object)로세스에서 다루는 객체( -입출력)를

나타낸다.

신호(Signal)로세스의 사건( -메시지 송)을 나타

낸다.

선택(Decision)로세스 흐름에서 선택에 의한 분기를

나타낸다.

병렬분기/병합

(Fork/Join)로세스 흐름에서 병렬 분기/병합을 나

타낸다.

순차(Sequence) 로세스의 순차 흐름을 나타낸다.

시작/종료 로세스의 시작과 종료를 나타낸다.

아래 그림은 UML2 Activity Diagram으로 표 된 로세스 시이다. 로세

스의 내용은 앞서 제시된 페트리넷과 BPMN의 로세스 시와 동일하다.

<그림 4-3> UML2 Activity Diagram의 로세스 시



거절문서발송

구매주문수신

[>1]

견적서발송

신용도

[<=1]



거절문서발송

구매주문수신

[>1]

견적서발송

신용도

[<=1]

의 시에서 알 수 있듯 UML2 Activity Diagram과 BPMN의 표기법들

- 63 -

은 표 방식에서 다소 차이를 보이나 구성에서 매우 유사하다. 활동과 사건

의 구분, 흐름에서 달되는 데이터 객체의 표 , 작업자와 외상황의 표 방

법 제공 등이 이에 속한다.

다 . I D E F 3 ( I ntegrated D efinition Meth ods 3 )

IDEF3는 IDEF 모델링 방법론들 로세스 모델링을 해 제안된 방법

론이다. IDEF3에서는 로세스 설계도와 객체 상태 이도의 두 가지 다이어

그램을 제공한다. 로세스 설계도는 여타 모델링 방법론들과 유사한 형태로

로세스를 표 한다.

<표 4-3> IDEF3 로세스 설계도의 표기


행동단

(Unit Of Behavior)로세스의 활동을 나타낸다.

&& &&

AND분기(Sync/Async AND Junction)

동기/비동기의 AND 분기/병합을 나타낸

다.

OO OOOR분기(Sync/Asyn

c OR Junction)동기/비동기의 OR 분기/병합을 나타낸다.

XXXOR분기(XOR

Junction)XOR 분기/병합을 나타낸다.

순차(Precedence Link)

로세스의 순차 흐름을 나타낸다.

계(Relational Link)

UOB간의 계를 정의한다.

- 64 -

IDEF3 로세스 설계도에서 심이 되는 표기는 행동단 (UOB; Unit Of

Behavior)로, 로세스의 활동을 나타낸다. 로세스는 이 행동단 들이 순차

(Precedence Link)로 연결됨으로써 표 되는데, 순차는 그들이 가지는 제약조

건에 의해 여러 가지 형태로 분화될 수도 있다. 로세스 설계도에서는 행동

단 들 간의 계를 나타내기 해 계(Relational Link)를 제공하는데, 이는

하 로세스 등 사용자가 나타내고자 하는 계들을 자유로이 정의하여 나

타낼 수 있도록 한다. <표 4-3>은 IDEF3의 로세스 설계도에서 사용되는

표기들과 그 기능들에 해 설명한다.

객체 상태 이도는 객체 상태 변화를 심으로 로세스를 표 하는 다이

어그램이다. 객체 상태 이도의 심이 되는 표기는 객체(Object)로, 특정 객

체의 상태를 나타낸다. 이 객체들이 이(Transition Link)를 통해 연결됨으로

써 로세스를 나타내는데, 해당 이가 어떤 행동단 (UOB)의 실행을 통해

발생하는지 나타내기 해 참조(Referent)를 제공한다. 참조는 로세스 설계

도에서 정의된 행동단 를 가리키며, 이에 첨부되어 표기된다. 아래 표는

IDEF3 객체 상태 이도에서 사용되는 표기들과 그 기능들을 설명한다.

<표 4-4> IDEF3 객체 상태 이도의 표기


객체

(Object)객체의 상태를 나타낸다.

& O X 분기(Junctions) AND, OR, XOR 분기/병합을 나타낸다.

참조(Referent)Transition Link에 연결되어 (UOB에 한) Call And Continue/Call And Wait 참조를

나타낸다.

이(Transition Link)

객체 상태의 변화 방향을 나타낸다.

- 65 -

다음의 <그림 4-4>는 IDEF3로 표 된 로세스 시이다. 로세스 내용

은 앞서 제시된 시들과 동일하다.

<그림 4-4> IDEF3의 로세스 시

구매주문수신

A01


A02J01

X

가격계산

A03

거절문서발송

A05

견적서발송

A04신용도>1

신용도<=1

구매주문수신

A01


A02J01

X

가격계산

A03

거절문서발송

A05

견적서발송

A04신용도>1

신용도<=1

그림에서 알 수 있듯 IDEF3에서는 시 로세스가 행동단 와 분기의 두

개의 개체만으로 표 되었다. IDEF3는 활동, 사건, 시작/종료 등을 구분하지

않고 이들의 표 을 해 행동단 표기만을 제공한다.

라 . 순 서 도 ( F low Ch art)

순서도는 로그램의 알고리즘 설계를 해 사용되는 모델링 방법론으로,

페트리넷과 마찬가지로 그 자체로 수학 형식화가 가능하다. 본래 목 인 알

고리즘 설계를 해 처리, 데이터 입출력 등에서 다양한 표기들을 가지고 있

으나, 로세스 설계에서는 처리, 단, 서류, 흐름선의 4개 표기가 주축을 이

룬다. 여타 로세스 설계 방법론들과 마찬가지로 활동을 나타내는 처리를 흐

름선으로 연결함으로써 로세스를 표 하는데, AND 분기/병합을 표 하는

표기가 없다는 문제 을 지니고 있다. 아래 표는 로세스 설계에서 사용되는

순서도의 표기들과 그 기능들에 해 설명하고 있다.

- 66 -

<표 4-5> 로세스 설계를 한 순서도의 표기


처리 로세스의 활동을 나타낸다.

단 조건에 의한 (XOR) 분기를 나타낸다.

서류서류(문서)에 의한 데이터 입출력을 나타

낸다.

흐름선 로세스의 순차 흐름을 나타낸다.

다음의 <그림 4-5>는 순서도로 표 된 로세스의 시이다. 로세스 내

용은 앞서 제시된 시들과 동일하다.

<그림 4-5> 순서도의 로세스 시

시작

신용도평가

신용도>1



가격계산 거절문서발송

견적서발송 종료

종료

시작

신용도평가

신용도>1



가격계산 거절문서발송

견적서발송 종료

종료

의 시에서 메시지 수신 발신이 타 활동과 구분되어 있는 것을 볼

- 67 -

수 있으나, 이는 활동과 사건이 구분되기 때문이 아니라 문서에 근하는 활

동과 그 지 않은 활동이 구분되기 때문이다. 같은 이유로 ‘고객데이터조회’

활동과 메시지 수신/발신 활동이 동일한 표기법으로 표 된다. 이러한 차이

은 병렬처리의 부재와 더불어 순서도가 비즈니스 로세스 표 에 부 합한

요소들을 지니고 있다는 것을 보여 다.

2 . 로세스 모델링 표기법의 비교

다음은 앞서 설명된 페트리넷, UML Activity Diagram, IDEF3, 순서도,

BPMN의 모델링 표기법들을 로세스 구성요소 측면에서 비교한 결과이다.

가 . 로세스 핵 심 요소

로세스 핵심 요소는 비즈니스 로세스 설계의 메타 모델이 정의해야 하

는 필수 개념인 동시에 로세스 표기법이 그 표기 형식을 가지고 있어야 하

는 요소들을 의미한다.

활동(Activity)

활동은 로세스의 기본 구성 요소인 행동 단 를 의미한다.

사건(Event)

사건은 로세스의 내/외부에서 발생하는 메시지 달, 특정 시각 도달 등

의 사건을 의미한다.

자원 입출력(Data Handling)

자원 입출력은 로세스 내의 활동들이 수행되기 해 필요로 하거나 활동

들의 수행 결과로 도출되는 자원을 의미한다.

- 68 -

각 표기법의 핵심 요소 지원은 다음의 표와 같다. 표기법에 해당 요소를

한 표기가 존재하면 ○, 암시 표기 는 체 표기가 존재하면 △, 존재하

지 않으면 ☓로 나타내었다.

<표 4-6> 로세스 표기법의 핵심 요소 비교

요소 BPMN Petri Net U ML A . D I D E F 3 순 서 도

활 동 ○ ○ ○ ○ ○

사 건 ○ ○ ○ △ ☓자 원 입 출력 ○ ○ ○ ○ ○

활동과 자원입출력은 모든 표기법들에서 표 형식을 제공한다. 사건의 표

은 독립된 표 을 제공하는 표기법과 활동과 동일한 표 을 사용해야 하는

표기법으로 나뉜다. BPMN과 UML Activity Diagram에서는 활동과 사건의

표기가 명확히 구분되어 있다. 활동과 사건의 구분이 필요한 이유는 다음과

같은 에서 나타난다. 아래의 그림은 van der Aalst에 의해 제시된 워크 로

우 패턴 Deferred Choice 패턴을 BPMN과 UML2 Activity Diagram으로

표 한 것이다. BPMN에 의한 표 은 S.White에 의해 제시되었으며, UML2

Activity Diagram에 의한 표 은 P.Wohed외 4인에 의해 제시되었다.

Deferred Choice 패턴은 사건에 의한 선택 분기를 나타내는 것으로, 자세한

내용은 다음 에서 설명될 것이다.

- 69 -

<그림 4-6> BPMN과 UML2 Activity Diagram의 Deferred Choice

패턴 표

A

B

C

E1

E2

(a) BPMN의 표

A

B

C

E1

E2

(b) UML2 Activity Diagram의 표

와 같이 사건을 표 하는 표기를 제공함으로써 표 될 수 있는 로세스

흐름이 존재한다. IDEF3와 순서도에서는 시와 같은 로세스 흐름을 표

하는 데에 어려움이 있다. 단, 페트리넷의 경우에는 활동과 사건을 한 표

기가 구분되어있지 않으나, 상태와 함께 표 됨으로써 이가 사건의 성격을

명확히 지닐 수 있다. 아래 그림은 동일한 패턴을 페트리넷을 통해 표 한

시이다.

<그림 4-7> 페트리넷의 Deferred Choice 표

A

B

C

E1

E2

그림과 같이 페트리넷에서도 사건에 의한 선택 분기를 나타낼 수 있다.

한 메시지 는 타이머 등의 사건 종류를 표 할 수 있는 확장이 제안되어

있다.

- 70 -

나 . 흐 름 제어 요소

흐름 제어 요소는 로세스의 핵심 요소들의 흐름을 제어하는 기본 메커니

즘을 의미한다.

기반 수식 (Mathematical Formalism)

기반 수식은 해당 표기법이 따르는 수학 표 형식을 의미한다. 기반 수

식은 해당 표기법이 특정 언어로 변환될 수 있는 가능성과 해당 표기법에서

표 가능한 패턴들을 함축 으로 나타낸다.

순차 흐름 (Sequence)

순차 흐름은 로세스의 요소들이 실행되는 순차 계를 나타낸다.

XOR 분기/병합 (XOR Split/Merge)

XOR 분기/병합은 로세스 흐름 조건에 의해 하나의 흐름만이 선택되

어 진행되는 분기/병합을 나타낸다.

AND 분기/병합 (And Fork/Join)

AND 분기/병합은 로세스의 흐름이 병렬 으로 분기되어 실행되거나, 분

기된 흐름이 동기화되어 병합되는 제어 흐름을 나타낸다.

OR 분기/병합 (OR Split/Merge)

OR 분기/병합은 로세스의 흐름이 조건에 따라 선택되어 실행되거나, 조

건에 의해 분기된 흐름이 병합되는 제어 흐름을 나타낸다.

반복 흐름 (LOOP)

반복 흐름은 로세스의 흐름이 부분 으로 반복되는 제어 흐름을 나타낸

다.

각 표기법의 흐름 제어 요소 지원은 다음 표와 같다. 기반 수식 항목의 경

- 71 -

우 해당 표기법이 따르는 기반 수식명을 표기하 으며, 기타의 경우 지원하면

○, 지원하지 않으면 ☓로 표기하 다. 기반 수식이 표기법과 같은 이름으로

명시된 경우는 표기법 자체의 기반 수식이 정의되어 있음을 의미한다.

<표 4-7> 로세스 표기법의 흐름 제어 요소 비교


기반 수 식 Pi-Calculus Petri Net 없음 없음 Flow Chart

순 차 흐 름 ○ ○ ○ ○ ○

X O R분 기/ 병 합 ○ ○ ○ ○ ○

A ND 분 기/ 병 합 ○ ○ ○ ○ ☓O R분 기/ 병 합 ○ ○ ○ ○ ☓

반 복 흐 름 ○ ○ ○ ○ ○

와 같이 순서도를 제외한 다른 표기법들은 기본 인 로세스 흐름 제어

요소들을 모두 제공한다. 순서도의 경우에는 AND분기/병합과 OR분기/병합

등 흐름의 병렬 진행을 한 표기를 제공하지 않는다.

다 . 보 조 요소

보조 요소는 로세스 실행을 해서는 필수 으로 정의되어야 하나, 로

세스 표기법에서는 설계의 편의를 해 제공할 수 있는 요소들을 의미한다.

트랜잭션 (Transaction)

ACID속성을 갖는 일반 트랜잭션을 의미한다.

외 (Exception)

로세스의 흐름에서 실행 시에 발생할 수 있는 외상황을 의미한다.

- 72 -

참여자 (Participant, Role)

로세스를 구성하는 활동들의 참여자를 의미한다.

각 표기법의 보조 요소 지원은 다음 표와 같다. 표기법에 해당 요소를

한 표기가 존재하면 ○, 암시 표기 는 체 표기가 존재하면 △, 존재하지

않으면 ☓로 나타내었다.

<표 4-8> 로세스 표기법의 보조 요소 비교


트 랜 잭 션 ○ ☓ ☓ ☓ ☓외 ○ △ ○ △ △

참 여 자 ○ ☓ ○ ☓ ☓

트랜잭션의 명시 표기는 BPMN에서만 제공된다. 아래 그림은 BPMN에

서 제공하는 트랜잭션의 표 이다. 두 로 이루어진 둥근 사각형이 트랜잭션

을 의미한다.

<그림 4-8> BPMN의 트랜잭션

표기

외상황과 그에 한 처리 흐름은 BPMN과 UML2 Activity Diagram에서

제공한다. 아래의 그림은 BPMN과 UML2 Activity Diagram에서 제공하는

- 73 -

외상황과 외 처리 흐름의 표 시이다.

<그림 4-9> BPMN과 UML2 Activity Diagram의 외처리 표

(a) BPMN의 외처리 표 (b) UML2 Activity Diagram의

외처리 표

BPMN과 UML2 Activity Diagram 외의 다른 표기법들에서는 외처리에

한 표기를 제공하지 않으므로, 외상황을 로세스의 흐름 일부로 간주

하는 등의 체 표 을 사용하게 된다.

참여자에 한 표기 역시 BPMN과 UML2 Activity Diagram에서만 제공된

다. 아래 그림은 BPMN과 UML2 Activity Diagram에서 참여자 표 의 시

이다.

<그림 4-10> BPMN과 UML2 Activity Diagram의 참여자 표

sale

s

(a) BPMN의 참여자 표

sales

(b) UML2 Activity Diagram의

참여자 표

- 74 -

제 2 BPMN의 표 력 검 증

이 에서 언 되었듯 BPMN은 Pi-Calculus를 기반 수식으로 따른다.

Pi-Calculus의 표 력에 해서는 의문이 제기되기도 하 다. 아래 그림은

Pi-Calculus로 표 되기 어려운 로세스 흐름을 페트리넷으로 표 한 시이

다.

<그림 4-11> Pi-Calculus로 표 되기 어려운 페트리넷 표

van der Aalst는 페트리넷과 Pi-Calculus의 비교에서 와 같은 로세스

흐름을 제시하며 Pi-Calculus로는 표 이 불가능함을 지 하 다. 그러나

Pi-Calculus를 기반으로 한 XLANG등의 로세스 실행언어들이 실제 제품들

에서 사용되고 있다는 사실은 Pi-Calculus가 실질 인 비즈니스 로세스 설

계에는 부족함이 없음을 시사한다. 본 에서는 van der Aalst가 제시한 20개

워크 로우 패턴에 한 BPMN 표 을 S. White의 논문을 바탕으로 제시함

으로써 BPMN의 표 력을 검증하고자 한다. 아래는 각 워크 로우 패턴에

한 설명과 BPMN을 이용한 표 이다.

- 75 -

1. Seq uence

워크 로우 흐름상 선행 작업 완료후 후속작업을 진행하는 기본 패턴이다.

아래 그림과 같이 BPMN으로 표 된다.

<그림 4-12> Sequence 패턴의 표

2 . Parallel Split

분기 으로의 입력은 하나지만, 출력은 다수인, 즉 AND분기를 의미하는

패턴이다. 이때 병렬로 실행되는 후의 작업들은 동시 으로 실행할 수도 있고,

순서 으로 실행될 수도 있다. 아래 그림과 같이 여러 형태로 표 될 수 있다.

<그림 4-13> Parallel Split 패턴의 표

(a) 로우만을 사용 (b) 게이트웨이를 사용 (c) 서 로세스를 사용

3 . Synch ronization

분기 으로의 입력은 다수이나 출력은 하나인, 즉 AND병합을 의미하는 패

턴으로, 병렬로 처리되던 것을 동기화하여 하나의 흐름으로 합친다. 아래와 같

이 두 개 형태로 표 될 수 있다.

- 76 -

<그림 4-14> Synchronization 패턴의 표

(a) 게이트웨이를 사용 (b) 서 로세스를 사용

4 . E x clusiv e Ch oice

의사결정이나 데이터에 기 하여서 뒤에 오는 다수의 흐름 하나를 선택

하여 계속 실행하는, 즉 XOR분기를 의미하는 패턴으로, 여러 가지를 동시에

실행시킬 수는 없다. 아래와 같이 표 된다.

<그림 4-15> Exclusive Choice

패턴의 표

5 . Simple Merge

다수의 로세스 에서 하나의 값만이라도 입력으로 들어오면 다음 로

세스를 실행하는, 즉 XOR병합을 의미하는 패턴이다. 동기화 과정이 필요 없

으므로 다른 입력들이 들어올 때까지 기다릴 필요가 없다. 아래와 같은 방법

들로 표 된다.

- 77 -

<그림 4-16> Simple Merge 패턴의 표

(a) 게이트웨이를 사용 (b) 플로우만을 사용

6 . Multiple Ch oice

의사 결정이나 데이터에 의해서 뒤에 계속될 로세스를 하나 선택하거나

동시에 다수의 로세스를 선택할 수 있는, 즉 OR분기를 의미하는 패턴이다.

아래와 같은 방법들로 표 된다.

<그림 4-17> Multiple Choice 패턴의 표

(a) 조건 플로우를 사용 (b) 게이트웨이를 사용

7 . Synch ronizing Merge

들어오는 입력들을 모두 받은 후에 동기화시켜 하나의 출력을 내보내는,

즉 OR병합을 의미하는 패턴이다. 아래와 같이 표 된다.

- 78 -

<그림 4-18> Synchronizing Merge의 표

8 . Multiple Merge

들어오는 입력의 개수만큼 출력을 내보내는, 다 병합을 의미하는 패턴이

다. 이때 내보내는 출력의 순서는 들어온 입력의 순서와 상 없다. 아래와 같

이 표 된다.

<그림 4-19> Multiple Merge의 표

9 . D iscriminator

하나의 입력 토큰을 받으면 다음 입력들을 기다리지 않은 채 무시하고 바

로 하나의 출력 토큰을 내보내는 패턴이다. 아래와 같이 표 된다.

<그림 4-20> Discriminator 패턴의 표

- 79 -

10 . A rb itrary Cycle

어느 특정 부분의 로세스를 계속 으로 반복하는 패턴이다. 아래와 같

이 표 된다.

<그림 4-21> Arbitrary Cycle 패턴의 표

11. I mplicit Termination

주어진 서 로세스가 할 일이 남아 있지 않을 때 명시 인 종료 활동이

없더라도 종료되는 패턴이다. 아래와 같이 표 된다.

<그림 4-22> Implicit Termination 패턴의 표

12 . MI w ith out Synch ronization

한 활동 내에서 다수의 인스턴스들이 각각 독립 인 쓰 드로 실행되는 패

턴이다. 인스턴스는 순차 으로 실행되지만 병렬 으로 수행될 수 있다는

에서 Arbitrary Cycle 패턴과 구분된다. 아래와 같이 표 된다.

- 80 -

<그림 4-23> MI without Synchronization

패턴의 표

13 . MI w ith a Priori K now n D esign Time K now ledge

활동의 인스턴스가 여러 번 수행되는 패턴으로, 수행 횟수를 로세스 설

계시에 미리 알고 있는 경우이다. 모든 인스턴스가 완료되면 후속 활동이 진

행된다. 아래와 같이 표 된다.

<그림 4-24> MI with a Priori Known

Design Time Knowledge 패턴의 표

14 . MI w ith a Priori K now n Runtime K now ledge

활동의 인스턴스가 다수개 생성되는 패턴으로, 인스턴수의 개수는 자원의

가용도등 상황에 따라 달라지지만 해당 활동이 기화되기 의 수행 의 어

느 한 시 에서 미리 알려지는 경우이다. 생성된 모든 인스턴스가 완료되면

후속 활동이 수행된다. 아래 그림과 같이 표 된다.

<그림 4-25> MI with a Priori Known Runtime

Knowledge 패턴의 표

- 81 -

15 . MI w ith out a Priori Runtime K now ledge

활동의 인스턴스가 다수개 생기나, 해당 활동의 인스턴스 생성이 단되는

시 까지 인스턴스 개수를 알 수 없는 패턴이다. 14번 패턴에서는 수행될 인

스턴스가 다 생성된 후에 하나씩 수행되지만 이 패턴에서는 일부 인스턴스가

완료되더라도 새로운 인스턴스가 계속 생성될 수 있다는 차이 을 가진다. 아

래 그림과 같이 표 된다. 그림에서, B 활동이 실제 반복을 수행하는 활동이

며, C는 B가 반복을 수행해야 하는지 결정하는 활동이다.

<그림 4-26> MI without a Priori Runtime Knowledge

패턴의 표

16 . D eferred Ch oice

가능한 분기 에서 해당 치에 도달하기 까지는 알 수 없는 정보, 즉 사

건을 바탕으로 분기하는 패턴이다. 데이터에 따라 명시 으로 이루어지는

XOR 분기와 달리 외부조건에 따라서 안이 선택된다. AND 분기와 다른

은 반드시 하나의 분기만을 따른다는 것이다. 아래 그림과 같이 표 된다.

- 82 -

<그림 4-27> Deferred Choice 패턴의

표

17 . I nterleav ed Parallel Routing

일단의 활동들의 집합이 임의의 순서로 실행되는데, 집합 내 각 활동의 실

행순서는 수행시에 결정되고 동시에 두 활동이 실행되는 경우는 없는 패턴이

다. 아래와 같이 표 된다. 그림에서 서 로세스의 아랫부분에 Ad hoc 표기

가 추가되어있음을 볼 수 있다.

<그림 4-28> Interleaved Parallel Routing

패턴의 표

18 . Milestone

활동의 진행 여부가 특정 상태에 따라 달라지는 패턴이다. 즉, 활동의 수행

에 일종의 이정표를 읽어 수행 여부를 결정한다. 를 들어 약된 여행 스

쥴에 해 고객은 출발 까지 취소할 수 있고 여행사는 취소여부를 출발

- 83 -

까지 계속 확인하면서 후속 작업을 진행하는 경우이다. 아래와 같이 표 된

다.

<그림 4-29> Milestone 패턴의 표

19 . Cancel A ctiv ity

해당 활동의 쓰 드를 제거시키는, 즉 활동을 종료하는 패턴이다. 아래와

같이 표 된다. 그림에서 B 활동이 완료되면 C 활동을 종료시켜버린다.

<그림 4-30> Cancel Activity 패턴의

표

2 0 . Cancel Case

워크 로우 인스턴스를 완 히 제거하는 패턴으로, 흐름의 일부분이 인스

턴스화되었더라도 후속 작업들을 수행하지 않고 종료한다. 아래 그림과 같이

- 84 -

표 된다. 그림에서 B 활동의 수행이 완료되면 서 로세스 C 체를 단

시킨다.

<그림 4-31> Cancel Case 패턴의

표

와 같이 모든 워크 로우 패턴이 BPMN을 통해 한 가지 이상의 방법으

로 표 됨을 알 수 있는데, 이는 일반 인 비즈니스 로세스 설계에서 요구

하는 표 력을 BPMN이 만족하고 있음을 의미한다.

제 3 BPMN 활 용 방 안

1. BPD 의 상 로세스 유 형 들

비즈니스 로세스를 기술하기 한 BPD 모델은 비즈니스 로세스들을

다음의 세 가지 유형으로 매핑시켜 다. BPD 모델링을 시작하기에 앞서서 모

델링 작업자는 자신이 모델링 하고자 하는 상 로세스가 이들 가운데 어떤

유형인지를 단함으로써, 한 BPD 패턴을 선택할 수 있다. 이들을 표 하

는데 있어서 스윔 인(Swimlane) ( 를 들어, 풀(Pool)과 인(Lane))은 요

- 85 -

하게 활용된다.

비공개 (Private) 비즈니스 로세스 (내부 비즈니스 로세스)

추상 (Abstract) 로세스 (공개 비즈니스 로세스)

업 (Collaboration) 로세스 ( 역 비즈니스 로세스)

가 . 비공 개 비즈니스 로세스 ( Priv ate Business Process)

비공개 비즈니스 로세스는 특정 조직 내부 로세스를 의미하고 일반

으로 워크 로우(workflow) 혹은 BPM 로세스(<그림 4-32> 참조)로 불리

는 로세스의 형태이다. 단일 비공개 비즈니스 로세스는 하나 는 그 이

상의 BPEL4WS 문서로 변환된다. 만약 스윔 인(Swimlane)들이 사용된다면

비공개 비즈니스 로세스는 단일 풀(Pool)에 포함된다. 따라서 그 로세스의

순서흐름(Sequence Flow)은 풀에 속해있고 풀의 경계를 넘나들 수 없다. 하지

만 메시지 흐름(Message Flow)은 분리된 비공개 비즈니스 로세스들 간에

존재하는 상호작용을 보여주기 해서 풀(Pool)의 경계를 넘나들 수 있다. 따

라서 하나의 BPD는, 각각 개별 BPEL4WS로 변환되는 다수의 비공개 비즈니

스 로세스들을 표 할 수 있다.

<그림 4-32> 비공개 비즈니스 로세스의

나 . 추 상 비즈니스 로세스 ( A b stract Business Processes)

추상 로세스는 비공개 비즈니스 로세스와 다른 로세스 는 참여자

- 86 -

(Participant) 간의 상호작용을 표 한다.(<그림 4-33> 참조) 오직 공개 비즈

니스 로세스 외부와 소통하는데 사용되는 이런 액티비티와 흐름 제어(flow

control) 메커니즘만이 추상 로세스에 포함된다. 비공개 비즈니스 로세스

의 다른 모든 내부 액티비티들은 추상 로세스에 나타내지 않는다. 즉, 추상

로세스는 비즈니스 로세스와 상호작용하는데 필요한 메시지들의 순서를

외부에 보여주는 역할을 한다. 단일 추상 로세스는 단일 BPEL4WS 추상

로세스로 변환된다. (하지만, 이 변환에 해서는 버 에서는 다루어지지

않고 있다.)

추상 로세스들은 하나의 풀(Pool)에 속하여 개별 으로 모델링되거나, 보

다 큰 BPD 내에서 추상 로세스 액티비티들과 다른 개체(entity)들 간의 메

시지 흐름(Message Flow)을 보여주기 해 모델링 될 수 있다. 만약 추상

로세스가 련된 비공개 비즈니스 로세스와 동일한 BPD에 기술된다면, 양

로세스들의 공통 액티비티들은 서로 연계될 수 있다.

<그림 4-33> 추상 비즈니스 로세스의

다 . 업 로세스 ( Collab oration Processes)

업 로세스는 두 개 이상의 비즈니스 개체들 (비즈니스 거래처들) 간의

- 87 -

상호작용을 표 한다. 이 상호작용은 련된 개체들 사이에 메시지 교환 패턴

을 표 하기 한 액티비티들의 순서로서 정의 된다. 단일 업 로세스는

다양한 업 언어들(ebXML, RosettaNet, 는 W3C Choreography Working

Group으로부터 나온 스펙)로 매핑될 수 있을 것이다. (하지만, 이 매핑들은

BPMN의 향후 개발 방향이다.) 업 로세스는 2개 이상의 추상 로세스가

서로 의사소통하는 형태로 나타난다(<그림 4-34> 참조). 하나의 추상 로세

스에서 업 당사자들 간의 액티비티들은, 참여자들 간의 “ ”으로 볼 수

있다. 업 로세스들은 풀(Pool)들 내에 통합될 수 있다. 거래 당사자들 간

의 인터랙션들은 개별 인 인(Lane)들 내에 기술된다. 이 게 함으로써

로세스들은 개별 으로 는 체 BPMN 다이어그램의 일부로서 모델링 될

수 있는 것이다. 만약에 업이 하나의 다이어그램 내에 마치 내부 로세스

가운데 하나인 것처럼 나타난다면, 양 당사자에 공통 인 액티비티들은 서로

연계될 수 있다.

<그림 4-34> 업 비즈니스 로세스의

- 88 -

라 . BPD 다 이 어그 램 의 형 식

아주 다양한 비즈니스 로세스들의 유형들이 에 언 된 세가지의 로

세스 클래스들로부터 다시 유도될 수 있다. 다음은 BPMN에 의해 모델링 될

수 있는 비즈니스 로세스의 다양한 유형들이다. 다만, 별표 표시된 것들은

실행언어로 매핑되지 않는다.

상 수 의 비공개 로세스 액티비티들 (기능 으로 분할되지 않은) *

상세한 비공개 비즈니스 로세스

변경 (As-is) 는 구(old) 비즈니스 로세스 *

변경 후(To-be) 는 새(new) 비즈니스 로세스

하나 이상의 외부 개체들( 는 “블랙박스” 로세스들)과 상호작용하는 세

부 비공개 비즈니스 로세스

둘 이상의 세부 비공개 비즈니스 로세스 간의 상호작용

세부 비공개 비즈니스 로세스와 추상 로세스와의 계

세부 비공개 비즈니스 로세스와 업 로세스와의 계

둘 이상의 추상 로세스들 *

추상 로세스와 업 로세스의 계 *

업 로세스 자체 ( 를 들면, ebXML BPSS 는 RosettaNet) *

추상 로세스들을 통한 둘 이상의 비공개 비즈니스 로세스 상호작용

업 로세스를 통한 둘 이상의 비공개 비즈니스 로세스 상호작용

추상 로세스와 업 로세스를 통한 둘 이상의 비공개 비즈니스 로세

스의 상호작용

- 89 -

2 . BPD 작 성 가 이 드 라 인

가 . 목 의 명 확 화

BPMN은 앞에서 설명한 바와 같은 다양한 유형들을 모두 허용하도록 설계

되었다. 하지만 셋 이상의 비공개 로세스 간의 메시지 흐름을 갖는 비공개

로세스들과 같이, 무 많은 하부 모델 유형들을 함께 사용하는 경우에는

BPD를 다른 사용자가 이해하기에 무 어려워 질 수 있다. 따라서 모델링 사

용자는 비공개 로세스 는 업 로세스와 같이 해당 BPD의 주된 목 을

우선 으로 결정하는 것이 제일 먼 필요하다.

나 . 이 아 웃 상 의 권 고

어떤 흐름객체(Flow Object)로 들어오는 순서흐름(Sequence Flow)은 그

흐름객체에 어느 치(왼쪽, 오른쪽, , 아래)에도 연결 될 수 있다. 마찬가지

로, 밖으로 나가는 순서흐름(Sequence Flow) 역시 해당 흐름객체(Flow

Object)의 어느 치(왼쪽, 오른쪽, , 아래)로부터도 연결될 수 있다. 메시지

흐름(Message Flow)도 동일한 특성을 가지고 있다. 비록 BPMN이 이러한 융

통성을 제공하고는 있으나, 모델링 작업자는 흐름객체가 다이어그램을 보는

사람으로 하여 명확하고 쉽게 따라올 수 있도록 이아웃 상의 한 단

을 해야 할 것이다. 이는 다이어그램이 순서흐름(Sequence Flow)과 메시지흐

름(Message Flow)을 모두 포함하고 있을 때 더더욱 요하다. 이런 경우 순

서흐름(Sequence Flow)의 방향(왼쪽에서 오른쪽 는 에서 아래로)을 먼

결정한 후에 메시지 흐름을 순서흐름(Sequence Flow)의 90도 각도로 치시

키는 것이 가장 좋은 방법이다. 그 결과 다이어그램은 이해하기가 훨씬 수월

해진다.

- 90 -

다 . 실 행 언어로의 변 화에 한 고 려

BPMN은 에서 설명한 바와 같이 많은 활용 역들을 다루기 때문에, 이

보다 낮은 수 의 여러 가지 스펙 언어들로 매핑 될 수 있다.

BPEL4WS는 BPMN이 매핑될 주된 언어이다. 그러나 BPEL4WS는 오

직 하나의 실행 가능한 비공개 비즈니스 로세스만을 다룬다. 만약 어

떤 BPMN 다이어그램이 두 개 이상의 내부 비즈니스 로세스를 기술

한다면, 이들은 각각 별도의 비즈니스 로세스로 분리되어 매핑 될 것

이다.

BPMN 다이어그램의 추상 로세스를 나타내는 부분은, BPEL4WS의

추상 로세스들 처럼 웹서비스 인터페이스 스펙으로 매핑 될 것이다.

BPMN의 업모델링 부분은 ebXML BPSS, RosettaNet, W3C

Choreography Working Group Specification (그것이 완성될 때) 같은

업 모델에 매핑이 될 것이다.

BPD는 비즈니스 로세스를 시작 으로 표 하도록 설계되었으나, 비즈

니스 로세스를 실행하는데 필요한 모든 정보를 시각 으로만 달하지는

못한다. 따라서 BPMN의 그래픽 요소들은 BPEL4WS으로의 매핑에 요구되

는 추가 인 정보를 제공해주는 속성들의 도움을 받아야 한다.

라 . 다 이 어그 램 이 가 지 는

BPD가 서로 다른 참여자(Participant)들의 로세스를 묘사하기 때문에, 각

각의 참여자는 다이어그램을 서로 다르게 볼 수 있다. 즉, 참여자들이 어떻게

- 91 -

로세스가 행동할 것인지에 해서 다른 (point of view)을 가진다는 것

이다. 어떤 액티비티들은 참여자의 내부(즉, 참여자의 조정 하에 는 조정에

의해 수행되는 것을 의미)가 될 것이며, 다른 액티비티들은 참여자의 외부가

된다. 각 참여자는 내부인지 외부인지에 따라서 다른 시각을 가지게 될 것이

다. 실행 에는, 내부와 외부 액티비티간의 차이는 참여자가 액티비티의 상

태를 악하거나 문제 해결을 하는데 있어서 요하다. 하지만, 다이어그램 그

자체는 동일하다. 의 <그림 4-34>는 두개의 을 갖는 비즈니스 로세

스를 보여 다. 한 은 환자(Patient)의 것이고 다른 은 병원 원무과

(Doctor's office)의 이다. 이 다이어그램은 해당 로세스에서 두 참여자

들의 액티비티들을 모두 보여주고 있지만, 로세스가 실제로 수행되고 있을

때 각 참여자들은 자기 자신의 액티비티들만을 실질 으로 제어를 할 수 있

다.

이와 같이 다이어그램이 가지는 이 해당 BPD를 읽는 사람에게 로세

스가 어떻게 동작할지를 이해시키는데 요한 역할을 함에도 불구하고, 재

BPMN은 을 표시해주는 어떤 시각화 메커니즘도 제공하지 않고 있으며,

신 모델링 작업자나 모델링 도구 개발자들이 다이어그램의 성격을 강조하는

시각 인 단서를 제공할 수 있도록 허용하고 있다. 따라서 BPD의 을

히 표시해 으로써 BPD를 읽는 사람들의 이해도를 높이는 배려가 필요하

다.

마 . 일 반 인 BPD 작 성 차

이상의 가이드라인을 바탕으로 일반 인 BPD 작성의 형 인 차를 다

음 <그림 4-35>와 같이 제시하 다. 가장 먼 작성하고자 하는 BPD의 목

을 명확히 정의한다. 즉, 비공개 (내부) 로세스를 표 하는 것인지 아니면

- 92 -

공개 ( 업) 로세스를 표 하려는 것인지를 정하고, 아울러 상세도 (level of

detail)을 결정하는 것이 요구된다. 업 로세스의 경우에는 의의 참여자들

을 이 단계에서 명확히 정의하고, 이에 따라서 당한 개수의 풀과 인을 생

성한다. 개별 로세스를 작성하는 단계에서는 먼 태스크들을 도출하고, 이

들 간의 순서흐름을 결정한다. 순서의 흐름을 BPD 상에 어떤 방향으로 나열

할지를 결정한다. 일반 으로 왼쪽에서 오른쪽으로, 쪽에서 아래쪽으로 흐름

이 정의될 것이다. 다음으로는 결정된 태스크들과 이들과 연 된 이벤트들이

배치되어야 할 것이다. 여기에 연결객체들을 추가함으로써 기본 인 를

완성한다. 마지막으로 여러 가지 인공물들을 첨가함으로써 BPD를 완성한다.

<그림 4-35> BPD 작성 차

- 93 -

3 . BPMN 스펙 수 확 장 가 이 드 라 인

BPMN은 모델링 작업자와 모델링 도구에 의해 확장할 수 있도록 의도되었

다. 이 확장성은 모델링 작업자에게 응용분야의 독특한 요구사항들과 같은 특

정 요구를 충족시키기 한 비표 요소나 인공물(Artifact)을 추가할 수 있도

록 허용하고 있다. 이러한 확정성에도 불구하고 BPMN 다이어그램은 어떤 모

델링 작업자가 만든 다이어그램이건 다른 사람이 쉽게 이해할 수 있도록 기본

인 외 은 유지하여야 한다. 따라서 기본 인 흐름 요소들(이벤트, 액티비

티, 게이트웨이)등의 모양은 변경되어서는 안된다. 아울러 어떠한 흐름 요소도

BPD에 새로 추가되어서는 안된다. 이는 순서흐름(Sequence Flow)과 메시지

흐름(Message Flow)이 새로운 흐름객체(Flow Object)에 어떻게 연결되어야

할 것인지에 한 스펙이 존재하지 않기 때문이다. 한, 새 흐름 요소가 추가

된다면 실행 언어로의 매핑이 향을 받을 수 있다. 기본 흐름요소 집합의 일

부가 아닌 추가 인 모델링 개념을 충족시키기 해서, BPMN은 계

(Association)를 통해 기존의 흐름객체(Flow Object)들과 연결될 수 있는 인공

물(Artifact)의 개념을 제공한다. 따라서 인공물(Artifact)들은 기본 인 순서흐

름 는 메시지 흐름에 향을 주지 않고 실행 언어로의 매핑에도 향을 주

지 않는다.

4 . BPMN 제 - 비공 개 ( 내 부 ) 로세스

이 에서는 BPMN을 모델화한 비즈니스 로세스의 제를 제공한다.

제의 로세스는 BPMI 가 이 표기법을 개발하기 해 사용해 온 로세스이

다. 이것은 이메일 투표를 통해 이슈를 처리하는 로세스이다(<그림 4-36>

참조). 이 로세스는 작지만 매우 복잡하고 BPMN의 특징에 해 많은 제

- 94 -

들을 보여 다. 무한 루 와 같은 비즈니스 로세스에서 보기 드문 특징들도

가지고 있다. 일반 이지 않은 로세스이지만, 이를 통해 BPMN이 단순하고

일반 이지 않은 비즈니스 로세스를 처리할 수 있고, 여 히 다이어그램을

보는 사람으로 하여 쉽게 이해할 수 있게 해 다는 것을 보여 다. 아래에

서는 로세스 부분들을 각각 나 고, 표 된 로세스 작업마다 모델링 특징

을 집 조명함으로써 BPMN을 활용하는데 있어서 지침을 제공하고자 한다.

<그림 4-36> 이메일 투표 로세스

이 로세스는 이슈 리스트와 이 리스트에 해 검토하는 리자의 을

가지고 있다. 그 에서 작업그룹의 투표자들은 (메세지 흐름에서 보이는)

- 95 -

메시지를 통해 의사소통하는 외부 참여자들로서 고려된다.

가 . 로세스의 시 작

로세스는 매주 요일에 시작하도록 설정된 타이머 Start 이벤트로부터

시작한다.(<그림 4-37> 참조)

<그림 4-37> “이메일 투표 로세스”의 시작 로세스

이슈 목록 리자는 목록을 검토하고 discussion과 voting 사이클로 갈

비가 된 이슈가 있는지를 단한다. 만약 이슈가 비되지 않았다면, 그 로

세스는 일주일 동안 멈추어지고 그 다음주에 다시 시작하게 된다. 이슈가

비가 되었다면, 로세스는 Discussion Cycle부터 진행이 될 것이다.

“Discussion Cycle”이라는 이름의 하부- 로세스는“Any issues ready?” 결정

이후의 첫 번째 액티비티이고 이 하부- 로세스는 결정(Decision)에서 발생한

것과 루 부분에서 발생한 2 가지의 들어오는 순서흐름(Sequence Flow)을

가진다. 이는 로세스에 존재하는 복잡한 5 가지의 루 구성 에 하나이다.

“Discussion Cycle" 하부- 로세스의 내용과 이를 따르는 액티비티들은 아래

에 서술하 다.

- 96 -

나 . 첫 번 째 하 부 - 로세스

<그림 4-38>은 펼쳐진 형태인 “Discussion Cycle" 하부- 로세스의 자세

한 설명을 보여 다.

<그림 4-38> “Discussion Cycle" 하부- 로세스 세부사항

하부- 로세스는 이슈 리스트 매니져가 작업그룹에게 이메일을 보내는 것

으로 시작된다. 몇몇 이슈는 토론을 해 워킹그룹의 메시지보드에 즉시 공개

된다. 이러한 태스크는 외부의 참여자(작업그룹멤버들)에게 메시지를 보낸 후

에, <그림 4-36>에서처럼 "Discussion Cycle" 하부- 로세스에서 Voting

Members 풀로 나가는 메시지흐름으로 보여진다. 기본 으로 작업그룹은 일주

일 동안에 이슈들의 토론과 이슈들의 추가 인 해결들을 제안한다. 첫 번째

태스크 후에 동기식 하 흐름인 3 개의 분리된 병렬 경로들이 뒤에 치한

다. 이것은 액티비티를 해 3 개의 나가는 순서흐름(Sequence Flow)에 의해

보여 진다.

- 97 -

그림에서 맨 의 병렬 경로는 그것의 경계에 붙어있는 타이머

Intermediate 이벤트를 가진 장기실행 인 태스크 “Moderate E-mail

Discussion"로 시작된다. “Moderate E-mail Discussion" 태스크가 보통 이러

한 모델에서 정상 으로 종결된다는 것이 있을 수 없음에도 불구하고, 시작

이벤트와 종료 이벤트가 로세스 내부에서 사용되기 때문에 이 태스크를

해 방출 순서흐름(Sequence Flow)이 있어야만 한다. 이러한 순서흐름은 타이

머 Intermediate 이벤트에서 나오는 순서흐름과 병합된다. 머징 배타 게이트

웨이는 다음 객체가 3개의 병렬 경로들의 동기화에 사용되는 병합 병렬 게이

트웨이( 앙에 십자를 가진 다이어몬드)이기 때문에 이러한 상황에 사용된다.

만약 머징 게이트웨이가 사용되지 않고 순서흐름이 조이닝 게이트웨이에

연결된다면, 로세스는 각각의 도입 순서흐름(Sequence Flow)으로부터 도착

한 토큰을 기다리는 조이닝 게이트웨이에 붙여지게 된다.

간 병렬 경로는 Intermediate 이벤트와 태스크(Task)을 포함한다. 타이머

Intermediate 이벤트는 로세스 흐름 에 사용되는데(액티비티의 경계에 결

합되어 있지 않음) 이를 통해 시간 연기를 시킨다. 연기는 6일로 되어있다.

“E-mail Discussion Deadline Warning" 태스크(Task)이 그 후에 나타난다.

다시 외부의 참여자(태스크그룹 맴버들)에 메시지를 보낸 후, 방출 메시지 흐

름이 ”Discussion Cycle" 하부- 로세스에서 <그림 4-36>에 있는 “Voting

Members" 풀에 보여 진다.

하부의 병렬 경로는 이번 주에 의 요청이 있는지 보기 해 이슈리스트

매니 가 날짜를 체크하는 첫 번째 태스크 같은 한 개 이상의 객체을 포함하

고 있다. 태스크(Task)의 결과는 ture나 false로 “ConCall" 변수에 업데이트된

다. 태스크 후에 2개의 게이트와 함께 배타 게이트웨이가 나온다. "defalult"

수 이 붙은 게이트는 상 의 병렬 경로에서와 같은 이유로 머징 배타 게이

트웨이로 바로 흐른다. ”Yes" 순서흐름(Sequence Flow)에 한 게이트는 다

- 98 -

가오는 주 에 의 호출이 될지를 보기 해 “ConCall" 변수( 태스크에서

한)의 값을 체크하는 조건을 가진다. 만일 그 다면, 타이머 Intermediate 이벤

트는 연기를 하게 되고, 그 이후 모든 태스크그룹 의는 목요일 서양시간

기 으로 오 9시에 시작한다. 의 요청을 만드는 태스크는 머징 게이트웨

이 뒤에 나오는 연기(delay) 뒤에 치한다.

상 와 하 경로의 머징 게이트웨이들과 “E-mail Discussion Deadline

Warning" 태스크는 모두 결합하는 게이트웨이로 흐른다. 이러한 게이트웨이

는 다음 태스크 ”Evaluate Discussion Progress"에 있는 로세스 흐름 에

완성하기 해 모든 3가지 경로들을 기다린다. 이슈 목록 리자는 지난주

에 토론과 이슈들의 상태를 재 검하고 검토가 연장될 것인지에 해 결정한

다. 이 평가에 따라 DiscussionOver 변수는 TRUE 는 FALSE로 구성된다.

만약 변수가 FALSE로 되어있으면 DiscussionOver 변수를 테스트하는 루핑

셋과 루 조건을 가진 후에 체의 하부- 로세스는 반복된다.

다 . 두 번 째 하 부 - 로세스

<그림 4-39>은 “Collect Votes" 하부- 로세스를 펼친 세부 내용을 포함하

는 로세스를 보인다.

- 99 -

<그림 4-39> “Collect Votes” 하부- 로세스 세부사항

체 로세스 , 이 부분은 이슈 목록 리자가 태스크그룹과 투표 멤버

들에게 투표가 재 비되었다는 내용을 알리기 한, 이메일을 송신 태스크

로부터 시작한다.

이 태스크(Task)는 외부 참여자(태스크그룹 멤버)에게 메시지를 보내기 때

문에, 방출 메시지 흐름("Announce Issues" 태스크(Task)으로부터 “Voting

Members" 풀)이 <그림 4-36>에서 보여진다. 이 태스크(Task)는 한 로세

스안의 복잡한 루 들 하나의 목 지이다.

- 100 -

“Collect Votes" 하부- 로세스는 태스크 뒤에 치하며, 한 반복하는 순

서흐름(Sequence Flow) 하나의 목 지를 가지고 있다. 하부- 로세스는

기본 으로 하부- 로세스의 시작에서 종료까지 연장된 4개의 병렬 경로들의

집합을 가지고 있다.

분기의 첫 번째 경로는 태스크그룹의 스 이 체크된 후에, 다가오는 주

에 컨퍼런스를 개최 할것인지를 결정하는 결정(Decision)을 야기한다. 기본

으로, 지난 주에 call이 있었다면, 이번주에는 개최되지 않는다(혹은 그 반 ).

“Discussion Cycle" 로세스에서 변경된 당한 변수가 다시 사용된다.

두 번째와 세 번째 경로는의 태스크들은 ”Moderate E-Mail Discussion"태

스크(Task)가 타이머 Intermediate 이벤트가 부착되지 않았다는 것을 제외하

고, “Discussion Cycle" 하부- 로세스 안에 있는 액티비티들과 유사하다. 이

것은 하부- 로세스 경계에 부착된 Intermediate 이벤트를 통해 체 하부-

로세스가 7 일 후에 단되지 않기 때문에 필요하지 않다. ”E-Mail Vote

Deadline Warning" 태스크(Task)는 외부 참여자(태스크그룹)에게 메시지를

보낸다. 따라서, 방출 메시지 흐름("Collect Votes" 태스크(Task)로부터

“Voting Members" 풀)이 <그림 4-36>에서 보여진다.

네 번째 경로는, 다이어 그램이 결정(Decision)이 없는 루 를 사용하기 때

문에 다소 독특하다. 따라서, 마치 무한루 처럼 보일 수 있다. 태스크그룹의

정책은 투표 멤버가 한 이슈에 여러번 투표할 수 있도록 한다. 즉, 멤버들은

주에 걸쳐서 그들이 원하는 만큼 의사를 번복할 수 있다. 루 의 첫 번째

태스크는 외부 참여자(태스크그룹 멤버)로부터 메시지를 받는다. 따라서, 도입

메시지 흐름("Voting Members" 풀(Pool)로부터 “Collect Votes")이 <그림

4-36>에서 보여진다. 하부- 로세스의 경계에 부착된 타이머 Intermediate 이

벤트는 하부- 로세스 내의 모든 액티비티들이 time-out이 발생하면 종료되기

때문에, 무한 루 를 종료하는 메커니즘이다.

- 101 -

<그림 4-39>은 time-out뒤에 나오는 두 가지 태스크들을 보인다. 첫 번째

태스크는 모든 투표 결과를 비하고, 투표 멤버에게 결과를 보낸다. 문서객체

(Document Object), “Issue Votes"가 다이어그램 안에 나타나지만, 실행언어

에 어떤것으로도 매핑되지는 않는다, 로세스의 나머지 액티비티들은 다음

섹션에서 설명되어진다.

라 . 로세스의 종 료

<그림 4-40>는 결정(Decision)들과 루 들이 복합 으로 구성된 로세스

의 마지막 섹션을 보여 다.

<그림 4-40> E-Mail 투표 로세스의 마지막 부분

- 102 -

로세스의 이 부분은 앞 에서 언 한 마지막 부분이 종료한 곳에서 계

속 된다. 이 부분은 서로 상호작용하고 상 흐름에 놓인 액티비티들을 반복

시키는 루 들을 생성하는 네 가지 결정(Decision)들을 포함한다.

첫 번째 결정, “Did Enough Members Vote?"은 투표자 2/3가 어떤 이

슈에 한 해결을 승인해야함이 요구되기 때문에 필요하다. 투표자의 2/3 보

다 게 투표될 경우, 이슈들은 해결되지 않는다. 이 결정(Decision) 후, 흐름

은 그것들의 안에 한 두 개의 결정들로 흐른다. "No" 안은 ”Have the

Members been Warned" 결정으로 흐른다. 만약 투표자가 투표를 잊어버렸다

면, 그들은 경고받게 된다. 그들이 두 번째 투표를 잊었다면, 그들은 투표자로

서의 자격을 상실하고, 퍼센티지는 태스크(“Reduce number of Voting

Members and Recalculate Vote")를 통해 재계산된다. 그들이 아직 경고받지

않았다면, 경고는 보내어지고 투표 주(week)가 반복된다.

만약 모든 이슈들이 해결되면, 로세스는 종료한다. 만약 그 지 않으면,

다른 결정(Decision)이 요구된다. 투표는 토의의 다른 사이클로 가기 두

번의 기회를 부여받게 된다. 첫 번째 기회는 가장 인기있는 두 투표(동수 득

표가 있다면)에 한 해결 수의 정리를 보게 된다. 어떤 투표자들은 그들의

선택이 더 이상 유효하지 않기 때문에, 그들의 투표를 변경해야 할 것이다. 하

부- 로세스 안 이 두 액티비티들은 Start와 End 이벤트를 가지지 않은 하부

- 로세스가 어떻게 간단한 병렬 액티비티들의 집합을 만드는데 사용되는지를

보여 다. 이것은 “병렬 박스(parallel box)"라고 불린다. 특별한 객체는 아니지

만, 하부- 로세스의 다른 사용이다. 간단한 상황을 로 든다면, 많은 순서흐

름의 혼란들이 없는 병렬 액티비티들의 집합을 보여주기 해 사용된다. 실제

로, 이 두 태스크들은 병렬 으로 실행되지 않는다. 하지만, 그것들은 Start,

End 이벤트의 선택 인 사용을 강조하기 한 방안으로 모델된다.

- 103 -

병렬 박스 후에, 흐름은 "Collect Votes" 하부- 로세스로 돌아간다. 이미

투표의 두 사이클들이 존재한다면, 로세스 흐름은 “Decision Cycle" 하부-

로세스로 돌아간다.

5 . BPMN 제 - 업 ( 다 참 여 자 ) 로세스

이 에서는 앞 의 제와 비되는 다 참여자를 가지는 업 로세

스 제를 제공한다. 이것은 B2B의 자결제방식 가운데 하나인 ‘ 자외상매

출채권’ 방식의 자결제 로세스이다(<그림 4-41>참조). 이 로세스에는

여섯 참여자(회사, 은행 등)가 참여하게 된는 형 인 업 로세스이다. 따

라서 앞 의 제가 보여주지 못했던 BPD의 다른 측면을 잘 보여 다.

<그림 4-41> 자외상매출채권 방식의 자결제 로세스

자외상매출채권은 기업간 상거래에 가장 많이 사용되고 있는 어음과 수

표기능의 장 을 혼합한 자 인 형태의 융.결제수단으로서, 구매기업이 은

- 104 -

행을 통해서 자외상매출채권을 발행하여 거래 을 결제하는 업무, 매기

업은 동 자채권을 만기까지 보유하거나 만기 에 이를 담보로 거래은행으로

부터 출을 받아 화하는 방식의 자결제 제도이다. 기업간 상거래에서

사용되고 있는 어음의 분실, 조 등 단 을 보완하면서 미래의 을 재

화하는 싱용창조기능을 가진 새로운 자결제수단으로서, 은행과 자외상매

출채권거래계약을 체결한 기업 (법인, 개인업체) 이상거래를 통하여 물품을 구

매한 후 물품 매자를 채권자로 지 하여 일정 액을 일정시기에 지 하겠다

고 발행하는 채권으로, 자 으로 발행되어 발행내역은 앙 리기 ( 융결

제원) 채권등록 원장에 등록되며 만기시 자채권교환 차에 의해 채권자계좌

에 입 이 이루어지는 방식의 자결제제도이다. 로세스의 세부 내용은 아

래 <그림 4-42>와 이하의 단계별 설명과 같다.

<그림 4-42> 자외상매출채권 방식의 자결제 로세스

구매기업은 거래은행에 자채권 발행을 한 계좌를 개설하고 약정을 체

결한다. 매기업은 거래은행에 자채권의 보 추심(지 제시) 등을 한

- 105 -

약정을 체결한다. 따라서 구매기업과 발행은행은 발행, 지 사무 행, 보증 등

의 역할을 하며 매기업과 보 은행은 자채권내역보 , 지 제시 행, 자

채권 입 등의 역할을 수행한다.

a- 구매기업과 매기업은 거래은행과 각각 자외상매출채권 약정을 체결

b- 구매기업과 매기업은 Market Place를 통하여 매매계약을 체결

c- MP는 매매계약 체결정보(결제수단 포함)를 발행 행은행으로 송

d- 구매은행은 채권발행 약 후 약결과를 MP로 송

e- MP는 채권발행 약결과를 매기업과 구매기업에 안내

f- 매기업은 구매기업으로 물품을 인도

g- 매기업은 MP를 통해 자세 계산서를 구매기업으로 송

1- 구매기업은 물품인수 후 채권발행 신청내역을 자서명

암호화(공인인증서 사용)하여 발행 행은행(구매기업 거래은행)으로 송

2- 발행 행은행은 채권발행 신청내역을 복호화하고 구매기업의 자서명을

검증한 후 채권발행 신청내역을 심사함. 구체 으로 MP가 송한

매매계약체결정보, 은행과 구매기업간 계약사항 등과의 일치여부를

심사한다. 신청내역이 정당한 경우 앙 리기 으로 채권발행 등록을

의뢰(의뢰 시 구매기업의 자서명 송)

3- 앙 리기 은 채권발행 내역과 구매기업의 자서명을 채권원장에 등록.

등록시 공인인증기 의 시 확인서비스를 통해 채권원장 등록시 도 함께

등록

4- 앙 리기 은 채권발행 등록결과를 발행 행은행으로 통지하고,

채권발행 사실을 매기업 거래은행(보 은행)으로 통지

5- 매기업 거래은행은 채권발행 사실을 채권자( 매기업)로 통지하고

매기업은 보 은행 홈페이지 등을 통하여 자채권발행내역을 조회한다.

- 106 -

- 107 -

제 5 장 비즈니스 로세스를 한 질의 언어

본 연구에서는 기존에 비즈니스 로세스를 한 질의 언어와 련하여 수

행된 연구 결과를 심으로 요구사항에 한 이해와 기 조사 용 사례

를 심으로 진행하 다. 한 비즈니스 로세스 질의 언어의 설계 개념에

포함되어야 할 요구 사항들을 살펴보고, BPQL 표 에 반 될 것으로 상되

는 표 인 기반 기술에 한 조사와 다른 연구를 통해 발표된 비즈니스

로세스 질의 언어의 사례를 살펴보았다.

제 1 비즈니스 로세스 질의 언어의 연구 배 경

1. 질의 언어의 탄생 과 개 념

질의 언어(query language)는 데이터의 정의, 검색 조작을 해 도입되

었으며 데이터베이스(database)라는 데이터 장소와 이를 리하는 응용

로그램인 데이터베이스 리 시스템(DBMS: Database Management System)

을 제로 하여, 그 에서 지원 처리되는 언어이다.

1960년 부터 기업의 경쟁력 제고를 해 형의 산 시스템을 비즈니스

업무에 도입하고 이를 통해 기업정보처리 환경을 신시키고자 하는 움직임이

태동되었는데, 이 당시에는 이러한 정보처리 시스템을 EDPS(Electronic Data

Processing System)라 통칭하 다. 이런 움직임 속에서 DBMS가 기업에 도입

되었으며, 이와 함께 질의 언어도 정비되면서 표 화되어갈 수 있었다.

1970년 에 IBM은 SEQUEL(Structured English Query Language)이라는

구조화된 문 질의어 제품을 개발하 는데, 이것이 결국 재 SQL 표 의

- 108 -

신이 되었다. 당시, IBM은 다른 계형 DBMS 공 자들과 함께 계형 데

이터베이스에 장되어 있는 데이터에 근하여 이를 조작할 수 있는 표 화

된 방법을 모색하던 이었다. 그 까지 데이터의 근 조작을 한 다양

한 로그래 언어가 존재했지만, 배우고 사용하기가 매우 까다롭다는 때

문에 다양한 개발자 층에 의해서 사용되지는 못했다. 그러나 SEQUEL과 같은

몇몇의 질의 언어는 계형 데이터 모델을 기반으로 한 다양한 연산과 집합함

수(Aggregation Function)를 일상의 문 언어와 같은 구성을 통해 쉽게 작성

하여 사용할 수 있도록 함으로써, 다양한 개발자 계층에게서 환 받았으며, 차

츰 데이터 설계 분석가들에게도 쉽게 수용되어, 재의 SQL 표 과 같은

형태로 다듬어져 확고한 표 질의 언어의 자리에 이르게 되었다.

SQL은 DML(Data Manipulation Language), DDL(Data Definition

Language) DCL(Data Control Language)라는 세 가지의 특성을 동시에 지

니고 있는 언어이다. DML은 데이터의 검색, 변경 조작을 한 언어이고,

DDL은 데이터의 구조, 즉 계형 테이블의 논리 구조와 이들 간의 계성

을 정의하는 데이터 정의 언어이다. 마지막으로 DCL은 데이터베이스 사용자

들에게 특정 데이터에 한 근의 허가 제한 등과 련된 특권 등을 정의

하는 데이터 제어 언어이다. 리 알려져 있는 Select, Insert, Update

Delete 문은 DML에 해당되는 것으로 계형 테이블로부터 특정 행이나 열을

검색하거나 추가, 변경 삭제하는 용도로 각기 이용된다.

2 . 질의 언어의 발 달

SQL에 한 표 화 작업에는 그 필요성이 두되었던 시 부터 상당한 시

간이 소요되었다. 1982년에 최 로 미국 표 화 기구인 ANSI의 데이터베이스

원회인 X3H2에 의해 공론화되었으며, 1986년에야 비로소 최 의 표 안이

- 109 -

제안되어 1987년에 국제 표 화 기구인 ISO에 의해 ‘ISO 9075, 1987’로 채택

되었다. 여기에는 데이터베이스 응용에 필요한 기본 기능들로서 DDL, DML,

그리고 기본 인 무결성 제약조건들이 일부 포함되었다. 이때의 SQL 표 안

을 종종 SQL1이라고 부르는데, SQL1은 다시 벨 1과 벨 2의 두 가지 수

으로 분류된다. 벨 2는 표 안을 부 지원하는 것을 의미하며, 벨 1은

벨 2의 지원 수 에서 일부를 제공하지 않는 것을 의미한다.

데이터베이스 시스템의 활용도가 높아지고 용 분야도 다양해지면서 사용

자의 요구사항들을 충족시키기 해 SQL의 기능을 더욱 확장시켜야 할 필요

성이 두되었다. 이에 따라 1989년 기존의 SQL1 표 안에 무결성 제약조건

을 보완한 표 이 ‘ISO/IEC 9075, 1989’로 제정되었는데, 이를 보통 SQL/89라

부른다.

기의 SQL은 데이터베이스의 질의 조작 등을 심으로 인터 리트 방

식의 언어로 제공되었기 때문에, 실제 응용 로그램 내에서 데이터베이스를

근하여 조작하기 해서는 SQL 코드를 사용할 수 있는 방법이 필요하게 되

었다. 즉, 외부의 응용 로그램이 실행 에 SQL 코드를 생성하여 데이터베

이스 리시스템에 달하고, 그 결과를 다시 넘겨받기 한 기능이 추가될 필

요가 있었다. 이와 같이 응용 로그램에 내포되어 사용되는 SQL 언어를

Embedded SQL 혹은 ESQL이라고 부른다. 이러한 ESQL에 한 모든 개념을

포함하고, SQL에 한 X/Open 표 안, IBM의 SAA 표 안, 그리고 미연방

표 인 FIPS 표 안 등을 차례로 반 하고, 서로 다른 시스템들 간의 상호 연

동성 등을 포함하도록 새로이 ‘ISO/IEC 9075, 1992'를 제정하 다. 흔히 SQL2

혹은 SQL/92라 부르는 것으로 오늘날 부분의 계형 DBMS가 기본 으로

지원하고 있는 표 질의 언어로 자리 잡고 있다.

이후, 계형 데이터베이스는 다양한 데이터 타입을 지원하면서도 뛰어난

성능과 안정성을 보일 수 있도록 기술 인 발 을 계속하 는데, 차츰 멀티미

- 110 -

디어 데이터의 활용이 일반화되면서, 이미지, 오디오 비디오 등과 같이

용량의 복잡한 형태의 데이터에 한 리 요구가 높아지게 되었다. 한

CAD/CAM과 같은 공학 응용 제조 분야에서 다루어지는 데이터는 기존의

테이블에 정의되던 정규형의 데이터가 아니라, 다양한 계층 구조와 가변 인

크기의 복잡한 필드들로 구성된 형태가 일반 이었으며, 사용자의 정의에 따

라 새로운 데이터 유형이 추가될 필요가 빈번히 발생하 다. 이와 련하여

기존 계형 데이터베이스의 한계와 문제 들이 거론되기 시작하 는데, 여기

에는 SQL에서 정의된 데이터 타입이 제한 이고 확장이 불가능하다는 , 테

이블을 통해 복합객체(complex object)의 표 이 어렵다는 , 정의된 복합객

체들 간의 연 계를 충분히 지원할 수 있는 참조 경로의 활용 방안이 SQL

로는 어렵고, 응용 로그램 등에서 SQL을 다른 언어와 연결하여 사용할 때

Impedence Mismatch의 문제가 발생하여 유기 인 개발이 어렵다는 등이

표 으로 거론되었다.

이와 같은 문제 들에 한 해결 방안의 하나로 제시되었던 것이 객체지향

데이터베이스이다. 객체지향 기술과 데이터베이스 기술의 목은 1980년 이

후부터 활발히 연구되기 시작하 는데, 객체지향 모델링 개발 방법론 등이

1990년 에 들어서면서 소 트웨어 산업의 핵심 기술로 인정받기 시작하면서,

데이터베이스 분야에서도 이를 표 으로 수용하려는 움직임이 자연스럽게

나타나게 되었다. 이와 련하여 질의 언어에는 크게 두 가지의 움직임이 있

었는데, 새로이 객체지향 데이터베이스 리시스템(OODBMS)을 Effel, C++,

Java 등과 같은 객체지향 로그래 언어를 근간으로 하여 구성하고 이를 효

과 으로 지원할 수 있는 OQL(Object Query Language)을 표 으로 제정하여

제공하려는 움직임이 있었으며, 다른 한편으로는 기존의 계형 DBMS 공

자들을 심으로 객체지향 개념을 수용하고 이를 지원할 수 있도록 SQL/92

를 확장하는 움직임이 있었다. 이러한 움직임의 결과로 1999년에는 객체기반

- 111 -

의 SQL3가 표 으로 발표되기에 이르 다.

질의 언어의 지속 인 발 은 재에도 계속 진행 에 있는데, XML DB

까지를 지원하기 한 SQL4, 멀티미디어 데이터베이스를 지원하기 한

SQL/MM 등 다양한 방면으로의 기술 확장이 이루어지고 있다.

3 . 비즈니스 로세스를 한 질의 언어의 필 요성

기존의 질의 언어에 한 기술 발달이 새로운 데이터 유형과 데이터 모

델링 분야의 등장으로 인해 주도되었다면, 비즈니스 로세스를 한 질의 언

어의 등장에는 비즈니스 로세스의 리라는 새로운 응용 분야의 지원이 핵

심 요인으로 작용했다고 할 수 있다.

SQL이 데이터 주의 근을 한 DBMS DB 서버의 표 언어라고

한다면, 비즈니스 로세스를 한 질의 언어는 BPMS 혹은 로세스 서버에

축 되고 유지되는 비즈니스 로세스 정보를 상으로 하는 표 언어라 할

수 있겠다. 이러한 은 DBMS와 BPMS를 응 시키고 있는 다음의 그림

을 통해 쉽게 이해할 수 있다.

<그림 5-1> DBMS와 BPMS

- 112 -

기존의 DBMS가 데이터간의 연계를 통해 비즈니스 응용 로그램을 구동시

키는 핵심이었다면, 이제 BPMS는 기업 후단의 백오피스 시스템과 기업 면

의 B2B 채 의 연계를 통해 비즈니스 로세스를 구동시키는 핵심 시스템으

로서의 기능을 하고 있음을 확인할 수 있다.

Howard Smith와 Peter Fingar는 그들의 서인 “BPM The 3rd Wave"에

서 차츰 기업의 비즈니스 업무가 데이터 심에서 로세스 심으로 변화되

어 감을 지 하며, 다음의 표와 같은 로세스 리의 발 과정을 제시하

다.

<표 5-1> 로세스 리의 발 과정

기존 응 용 로그 램 1세 신 로그 램성숙 된 로세스

응 용 로그 램

로세스 내부에 녹아들어 있음 부분 으로 명세됨 완 히 명세됨

로세스의

표없거나 묵시 임

개별 으로 기술되

며 시스템의 일차

인 요소가 되지 못

함

표 화 됨

(BPML)

로세스

질의 언어없음 개별 으로 처리됨

표 화 됨

(BPQL)

로세스

리 도구들없음 개별 으로 제공됨

랫폼상에서 제공

됨

(BPMS)

비즈니스에

미치는 향

소 트웨어 공학 없이

는 로세스의 변화를

가져올 방법이 없음

몇몇 분리된 로세

스들이 리 가능함

(point solution)

사 차원의 (공유

된) 로세스 리

가 가능함

- 113 -

여기에서 로세스 질의 언어는 성숙된 로세스의 리를 해서 표 화

되어 정의될 필요가 있으며, 이것이 BPMS라는 랫폼 상에서 제공될 필요가

있음을 확인할 수 있다. 재의 기업 환경은 1세 신 로그램들이 태동하

는 단계로 볼 수 있는데, 차츰 각 BPMS 제공 업체를 심으로 독 인 형

태의 로세스 질의 언어가 개별 으로 제시되기 시작할 것으로 상된다.

DBMS에서 개발자가 SQL을 필요로 하는 것과 마찬가지로 BPMS에서 비

즈니스 로세스에 한 질의 언어를 필요로 하는 이유는 바로 개발 생산성과

유지보수에 있다. BPMS가 범용의 로세스 서버와 같은 역할을 하는 상태에

서라면 기업들은 자신들의 비즈니스 지식과 경험이 명시 으로 리되면서도

회사 내의 체 로세스가 쉽게 통합되고 력·조정될 수 있기를 바랄 것이

다. 만약 표 화된 비즈니스 로세스 질의 언어가 없다면, 이러한 귀 한 비

즈니스 로세스 자산들이 어 리 이션 속에 조각난 상태로 흩어져 숨겨지게

될 것이고, 비즈니스 로세스 어 리 이션의 개발과 유지보수는 더더욱 어

려워지게 될 것이다. 다음의 그림은 비즈니스 로세스를 한 질의 언어가

비즈니스 로세스의 수명 주기 상에서 기능 으로 맡게 될 기능과 상 역

을 개념 으로 도시한 것이다.

<그림 5-2> 비즈니스 로세스를 한 질의 언어의 기능

- 114 -

비즈니스 로세스 질의 언어는 비즈니스 로세스 모델의 설계와 배치

리 단계 모두에 활용될 수 있는데, 로세스 장소로부터 비즈니스 모델을

읽거나 장하고 갱신하는데 사용될 수 있으며, 실행 에 있는 로세스 인

스턴스의 상태에 한 조회 갱신을 해 사용될 수도 있다. 이 외에도

로세스의 최 화와 감시 등을 해 다방면으로 활용될 수 있을 것이다.

4 . BPQL 표 에 한 연구

재 워크 로우 혹은 BPM 제품을 제공하고 있는 몇몇 공 자를 심으

로 자사에서 기존에 사용하고 있던 로세스 정의를 확장하여 비즈니스 로

세스 질의 언어의 몇몇 선택 인 요소들을 제공하려는 노력이 보이고 있다.

표 으로 스탭웨어(Staffware)에서는 조건문 정의와 워크 로우 참여자들의

지정을 해 사용할 수 있도록 SW 함수라 불리는 일련의 워크 로우 함수를

제공하고 있으며, 로터스(Lotus)의 워크 로우에서는 이와 같은 요소들을 정의

하기 해 로터스 스크립트 함수를 호출할 수 있도록 지원하기도 한다. 특히

오피스오 젝트(OfficeObjects)사의 워크 로우에서는 로세스 질의 언어를

기존의 XPDL과의 연계를 이루면서 다양한 함수와 기능을 제공할 수 있도록

확장하여 제공하고 있기도 하다.

이상과 같은 로세스 질의 언어를 한 노력들이 아직까지는 개별 회사와

제품 차원에서 이루어지고 있기 때문에 개발자와 분석 설계자들이 표 화

된 로세스 질의 언어를 기 하기는 어려운 실정이다. 특히 BPMI를 심으

로 로세스 실행과 로세스 배치( 로세스 장소)에 한 기능성을 제공할

것으로 고되었던 BPQL 표 화 작업에 한 연구가 진행된 지 3년이 지난

시 에서도 여 히 공식 인 발표가 없고 심지어는 드래 트 버 도 제시되지

않고 있는 상태라 로세스 질의 언어 표 의 제정은 앞으로도 상당한 시간이

- 115 -

소요될 것으로 상된다.

BPMI의 시도는 최 의 비즈니스 로세스를 한 질의 언어 표 화 작업

이라는 에서 BPMS 공 자와 학계의 높은 심을 받고 있지만, BPQL 표

안이 기존의 SQL, OQL XQL과 같은 질의 언어 표 들의 기술 발 을

수용하되, 이들을 어 리 이션 차원에서 모두 포 할 수 있어야 하기 때문에

많은 기술 문제들을 해결해야 할 것으로 상되고 있다. 이로 인해 정된

발표 일정이 지연되는 등의 난항을 겪고 있는 것으로 단된다.

제 2 비즈니스 로세스 질의 언어를 한 설 계 개 념

BPQL 표 이 갖추어야 할 요구 사항들로 언 되는 사항들은 매우 다양하

다. 이러한 요구사항들 에서 개념 으로 언 되는 요소들 에서 가장 요

한 요소는 바로 질의 언어의 문법과 의미가 명확하게 정의되어 혼동의 여지가

없어야 한다는 것이다. 이것은 다양한 공 자와 사용자 사이에서 립 인 표

으로 사용되어, 그 의미와 기능에 혼란이 없이 질의 언어의 해석과 실행이

일치해야 하기 때문이다. 이와 함께 질의 언어가 개발자뿐만 아니라 로세스

의 실행과 모니터 리를 담당하는 다양한 이해 계자 즉, 설계자, 리

자, 분석가 등이 쉽게 이해할 수 있어야 한다는 도 요하게 언 되고 있다.

특히 비즈니스 로세스의 모델링 언어가 주로 객체지향 에서 기술된다는

에서 질의 언어 역시 이에 부합하도록 설계되어야 할 필요가 있다.

이외에도 기존의 데이터베이스에서 SQL을 통해 데이터의 조작을 쉽게 할

수 있도록 집합함수(aggregate function)를 제공하는 것과 유사하게 로세스

질의 언어에서도 로세스의 조작을 한 특화된 함수와 API 등을 제공해야

한다는 기능 인 요구사항들이 존재한다.

본 에서는 이들 개념 기능 인 요구사항들에 한 내용을 하나하나

- 116 -

찾아서 나열하는 것보다는 이들 개념과 기능들을 제공하기 해 BPQL 표

이 설계 단계에서부터 기술 으로 고려해야 할 요구사항을 다루고자 한다. 설

계 개념의 정립을 한 기술 요구사항들을 살펴보는 것은 BPQL 표 이 갖

추어야 할 요구사항들을 보다 명확하고 간결하게 이해하는데 도움을 수 있

을 것이다.

1. 질의를 한 로세스 메 타 모델

성공 인 BPQL 표 이 정의되기 해서는 로세스에 한 질의 언어를

고려한 보다 유연한 로세스 메타모델의 개발이 먼 이루어져야만 한다. 다

양한 유형의 비즈니스 로세스를 구 하기 해 도입된 워크 로우 리 시

스템들이 지난 십여 년간 상당한 성과를 거두었지만, 여 히 지 되는 한계

의 하나로는 비즈니스 로세스의 잦은 변경 상황에 효과 으로 처하지

못한다는 이었다.

부분의 워크 로우 리 시스템들은 비즈니스 로세스가 일단 배치되면

해당 로세스의 정의가 그다지 변경되지 않거나 고정된다는 가정을 두고 있

다. 이러한 가정이 부분의 정형화된 비즈니스 로세스를 기술하는 데에는

효과를 발휘하 으나 동 인 요소들에 의해 향을 크게 받는 비즈니스 로

세스에서는 많은 한계를 드러내게 되었다. 를 들어, 표 인 리 로세스

로 생각해 볼 수 있는 것으로 재 참여자들의 작업 부하를 고려한 비즈니스

로세스의 라우 과 같은 요소들은 로세스의 정의 속에 포함되는 것이 가

장 자연스러움에도 불구하고, 부분의 경우 응용 로그램에 로그래 코드

의 형태로 구 되는 것이 일반 이었다.

따라서 로세스 정의가 워크 로우 환경의 잦은 변경 요소들을 포함해야

하는 일반 인 상황에서 매번 응용 로그램의 코드를 재작성하는 방식을 사용

해야 했으며, 이것이 로세스의 응성과 활용도를 떨어뜨리는 결과를 가져

- 117 -

왔다. 만약 이때 로세스의 정의에 실행시간 데이터, 실행한 결과 이력 데이터

그리고 실행 에 있는 워크 로우 환경 정보를 모두 포함할 수 있게 된다면

로세스의 응성은 비약 으로 증가하게 될 것이며, 잦은 응용 로그램의

변경으로 인한 로세스 응성 하도 피할 수 있게 될 것이다. 특히 이러한

요소들이 사 에 정의된 표 화된 용어와 방식을 통해 로세스 정의 속에 명

시 으로 기술될 수 있다면 로세스 정의의 가시성을 높이게 될 것이다. 따

라서 이러한 실행시간의 동 요소들에 한 정의가 비즈니스 로세스의 정

의를 기술하는 BPQL 표 에 언 되어야 하는 것은 당연하다고 하겠다.

이 게 비즈니스 로세스의 정의를 해 로세스 정의 데이터, 실행 데

이터 응용 로그램들과 련된 주변 데이터들까지를 포 하여 기술할 수

있기 해서는 이를 명시 으로 정의할 수 있는 유연한 로세스 메타모델이

필요하다. 결국 BPQL 표 은 이 게 유연성을 갖도록 확장된 로세스 메타

모델에 한 질의 조작 언어에 해당된다고 할 수 있겠다.

재 로세스 정의 메타모델로 제안된 것 리 알려져 있는 것으로는

WfMC 표 의 메타모델이 있다. 이 메타모델은 비교 잘 정의되어 있지만

로세스의 실행을 설명하는 메타모델이 빠져있다는 단 을 가지고 있다. 이

외에도 부분의 WfMS에 의해 제공되는 로세스 실행 모델들은 개별 인

도구에 의존 인 경우가 많으며, 상당부분이 주어진 시스템 내에서 해당 요소

들의 구 에 을 두고 작성된 것들이 부분이다. 최근 이러한 로세스

실행모델의 정의를 메타모델에 포함시키려는 노력이 나타나고 있지만, 여 히

시간 련한 요소의 도입과 동 인 참여자 할당, 실행 환경 정보의 정의와 같

은 내용들이 부족한 상태이다. BPQL 표 은 이러한 모든 요소들을 포함하는

로세스 메타모델로부터 유도되어야 할 것이다. 로세스 메타모델과 련하

여서는 2 에서 오피스오 젝트 사의 사례를 통해 보다 자세히 살펴보기로 하

겠다.

- 118 -

2 . 표 인 터 페 이 스와 질의 언어와 의 계

BPQL이 어떤 일을 할 수 있을 지를 이해하기 하여 다양한 활용 를 차

례로 살펴보는 방법도 좋겠지만, 보다 근본 으로는 로세스 서버(혹은 로

세스 실행 엔진)과 주변 액터(Actor)들과의 인터페이스 형태를 통해 확인하는

방법도 체 인 계를 쉽게 악할 수 있게 하는 좋은 방법이 될 것이다.

로세스 서버와 주변 액터들의 인터페이스를 살펴보기 한 좋은 로써

WfMC에서 제시하는 워크 로우 참조 구조와 다섯 가지 인터페이스를 생각해

볼 수 있겠다. 다음의 그림은 WfMC에서 정의하고 있는 워크 로우 참조모델

의 다섯 인터페이스를 나타낸 것이다.

<그림 5-3> WfMC의 워크 로우 참조모델과 다섯 인터페이스

인터페이스 1번은 로세스 정의가 모델링 로세스 정의 도구와 런타

- 119 -

임 워크 로우 소 트웨어 간에 임포트/익스포트 될 수 있도록 하는 것이다.

이 인터페이스는 기본 으로 로세스 정의 API 호출의 형태와 련된 것

으로, 특정 공 자의 그래픽 모델링 도구 등을 통해 생성된 로세스 정의가

다양한 물리 혹은 자 교환 매체를 통해 교환되어 다른 공 자의 런타임

실행 엔진에 의해서 실행될 수 있음을 의미한다. 이때, 해당 로세스 정의의

체 혹은 일부가 교환될 때 련된 일련의 속성(attribute)과 활동(activity)들

도 함께 교환될 수 있어야 한다.

인터페이스 2번은 워크 로우 클라이언트 응용 로그램과의 인터페이스를

정의하는 것으로 실제 클라이언트 응용 로그램이 어떻게 구 되었는지에 무

하게 워크 로우 엔진과 워크리스트 등에 일 된 형태로 근할 수 있도록

하는 일련의 표 인 API 들을 포함하게 된다.

인터페이스 3번은 기존에 존재하는 응용 로그램의 호출을 한 인터페이

스로써, 로컬 혹은 원격의 응용 로그램과의 연결을 해 에이 트 등을 사용

하는 형태로 나타나게 된다. 물론 해당 인터페이스를 지원하는 워크 로우 가

능한 응용 로그램들은 바로 워크 로우 실행 엔진과 통신할 수 있다.

인터페이스 4번은 서로 다른 이종의 워크 로우 시스템 간에도 하나의 비

즈니스 로세스를 성공 으로 진행시키기 해 상호운용성을 보장하기 한

것이다. 이를 해서는 서로 다른 두 워크 로우 실행 엔진 간에 동기 혹은

비동기 인 메시징을 사용하여 액티비티나 서 로세스 등을 동기/비동기

인 형태로 호출하여 실행시킬 수 있도록 해야 한다.

마지막으로 인터페이스 5번은 리 모니터링을 한 인터페이스로써,

서로 다른 워크 로우 도메인 간에라도 동일한 근 API를 통해 사용자, 역

할, 감사, 자원 제어 로세스 제어 등의 작업을 할 수 있음을 의미한다.

비즈니스 로세스를 한 질의 언어는 이상의 다섯 가지 인터페이스에 모

두 여하게 되는데, 이들 인터페이스의 구성을 보다 명백하게 악할 수 있

- 120 -

게 한다. 모든 인터페이스가 명확히 모호성 없이 정의되기 해서는 인터페이

스의 정의에 사용되는 입력 라미터와 출력 결과 데이터에 한 용어 정의

형태에 한 결정이 필요하다. 이것들은 한 로세스 질의 언어가 기본

으로 이해해야할 로세스 메타모델의 스키마에 명시되어야 할 것들이 된

다. 따라서 원칙 으로 앞서 언 된 모든 인터페이스에서 나타나는 데이터들

은 로세스 메타모델의 구성요소가 되며, BPQL은 이를 활용하여 개별 인터

페이스들의 API 함수들을 체할 정도 수 의 표 력을 갖추어야 한다.

우선 인터페이스 1과 련해서는 로세스에 한 질의를 진행시키기 해

서 로세스 모델의 표 인 기술이 필요하다. SQL이 DDL을 통해 데이터

스키마를 정의하듯, BPQL은 인터페이스 1과 호환되는 근 방식을 통해 로

세스 스키마를 정의하여 서로 다른 워크 로우 시스템 간에도 립 으로 교

환할 수 있어야만 한다. BPQL의 에서는 로세스의 정의를 장하고 교

환하기 한 스키마가 명시되어야 함을 의미하는 것으로, 부분의 BPMS에

서는 이를 제공하기 한 로세스 리포지토리의 개념을 함께 고려하고 있다.

특히 BPMI의 경우에는 BPQL을 한 로세스 리포지토리로써 UDDI의 활용

에 해서 언 하고 있기도 하다.

인터페이스 2와 련하여서는 상당히 다양한 BPQL의 활용 를 생각해

낼 수 있다. 단순히 워크리스트의 인출을 한 질의로부터 매우 복잡한 조건

을 제시하여 검토시키는 질의의 작성이 BPQL을 통해 가능해 질 것이다. 이것

은 인터페이스 2에서 정의되는 API를 사용하여 코딩하는 형태보다도 훨씬 선

언 인 형태가 될 것이고 활용 면에서 효과 인 방법일 것이다. 특히 재

로세스 서버의 실행 환경에 한 정보를 로세스 메타모델에 정의된 스키마

로 근하여 얻을 수 있게 될 경우 클라이언트 응용 로그램의 요구에 맞춰

보다 유연한 BPQL 질의 문의 작성도 가능해 질 것이다.

인터페이스 3의 경우에는 Embedded SQL과 같은 형태의 Embedded BPQL

- 121 -

을 유사한 형태로 생각해 볼 수 있겠다. 응용 로그램들은 Embedded BPQL

을 통해 복잡한 비즈니스 로세스 질의를 로그래 코드로부터 분리시켜

모아 놓을 수 있게 되며, 이를 해석하여 실행하고 그 결과를 반환하는 방법

역시 표 화됨으로써 응용 로그램의 재를 한 에이 트의 작성이 훨씬 쉬

워지게 될 것이다. 따라서 인터페이스 3의 경우, 그 정의가 다른 인터페이스에

비해 나 에 나타날 수도 있겠지만 비즈니스 응용 로그램들과의 유기 인 통

합을 해서는 궁극 으로 Embedded BPQL과 같은 형태로 BPQL의 큰 구조

속에 포함되어 기술되어야 하겠다.

인터페이스 4의 경우에는 유사한 로 분산된 데이터베이스들 상에서 발

생하는 분산 트랜잭션을 생각해 볼 수 있겠다. 서로 다른 데이터 소스로부터

단일의 트랜잭션을 진행시켜 나가기 한 과정이 분산된 워크 로우 시스템

상에서 단일의 비즈니스 로세스를 실행시켜 나가기 한 상호 력 과정과

유사하게 설명될 수 있을 것이다. 이러한 분산 비즈니스 로세스의 진행을

해서는 물론 분산 트랜잭션의 제어를 한 로토콜의 개발에 버 가거나

혹은 그 이상의 로토콜 요소와 기술이 개발되어야 하겠지만, BPQL 등을 통

해서 분산된 로세스 자원들을 쉽게 지정하고 근할 수 있는 방법이 제시된

다면, 분산 비즈니스 로세스의 정의 실행이 훨씬 수월하게 될 것이다. 최

근에는 웹 서비스 등을 통한 상호운용성의 개선이 비즈니스 로세스 분야

에서 활발히 진행되고 있음을 고려할 때, 이에 한 고려가 BPQL 내부의 설

계 시에 반 될 필요도 있겠다. BPMI의 경우에는 로세스 리포지토리에

한 근을 해 SOAP을 고려하고 있으며, 로세스 모델의 배치 회수를

해서 WebDAV(Distributed Authoring and Versioning Protocol)에 기반을

둔 방법을 고려하고 있음을 밝히기도 하 다.

마지막으로 인터페이스 5의 경우는 다양한 로세스 통계와 제어를 한

BPQL 질의문의 작성과 실행으로 설명될 수 있을 것이다. 여기에는 실행 이력

- 122 -

에 한 데이터가 주로 분석 등에 활용될 것으로 상되는데, 실행 이력 한

비즈니스 로세스의 메타모델을 통해 정의되었기 때문에 BPQL을 통해 쉽게

근할 수 있을 것으로 상된다.

이처럼 BPQL은 워크 로우 참조모델에서 언 하고 있는 5가지 표 인터

페이스의 정의 활용에 상당한 향을 주게 되며, 이들 인터페이스를 체

하거나 보완하는 역할을 할 정도의 표 력을 갖추어야 할 것이다.

3 . 기존 로세스 정 의와 의 호 환 성

BPQL을 해 새로이 정의되는 로세스 메타모델과 이를 통해 얻어지게

되는 로세스 정의는 개념 으로는 기존의 로세스 정의를 포 할 수 있어

야 한다. 호환성 혹은 상 통합성은 한 BPQL의 활용도를 더욱 넓히기

해서도 필요한 요소가 된다. 여기에는 두 가지 측면이 있는데, 하나는 기존의

로세스 정의 언어로 기술된 비즈니스 로세스들에 해서도 BPQL 표 으

로 작성된 질의가 작동할 수 있는 실행시간(runtime)에 한 측면과 다른

측면으로는 BPQL 표 이 기존에 리 사용되고 있는 XPDL, BPML,

BPEL4WS, 혹은 WSDL과 같은 로세스 정의 언어들의 내부에서 로세스

정의를 해서 이용될 수 있어야 한다는 작성시간(buildtime)에 한 측면이

그것이다.

먼 실행시간에 한 측면은 각 BPMS를 제공하는 공 자들의 BPQL 표

합성 기능의 지원 여부에서 그 해답을 얻을 수 있다. BPQL 표 이

모든 BPMS 공 자들에 의해 수용되어, 각각의 BPMS에서 구 된다면 실행

시간 측면에서의 호환성은 얻어질 수 있다. BPQL 표 질의가 기존에 개별

공 자들의 특화된 시스템에 맞도록 작성된 로세스 정의에 해 실행될 경

우, 해당 BPMS의 공 자들은 BPQL에 명시된 로세스 데이터와 용어를 자

- 123 -

신들의 거시 포맷에 맞도록 응시켜 해당 질의의 결과를 성공 으로 실행

하여 제공할 책임을 지게 된다. 이것은 BPQL 질의를 수용하는 확장된 로세

스 메타모델을 이해하고 이를 자사의 거시 형식과 응시키는 모종의 기술

구 이 해당 BPMS 공 자에 의해 제동되어야 가능할 것이다.

정의시간 측면은 개별 인 로세스 정의 언어의 내부에서 BPQL이 어떻

게 사용될 수 있을지를 결정한다. 일단 BPQL 표 이 제시될 경우 해당

BPQL의 문법과 의미론에 따라 로세스 정의의 형태가 립 으로 결정될

것이다. 그러나 기존의 BPMS 업체에서 리 사용하고 있는 모든 로세스

정의 언어가 바로 이러한 새로운 로세스 정의 언어로 변화되지는 않을 것이

다. 이것은 BPQL 표 에서 제공하는 표 력보다 개별 BPMS 업체에서 제공

하는 고유 로세스 정의 언어의 표 력에 더 뛰어난 요소가 있을 경우 더욱

그러할 것이다. 이런 경우 BPMS 제공 업체에서는 자신들의 로세스 정의

언어의 장 을 활용하고, BPQL 표 에서 제공하는 장 을 수용하기 한 방

안으로 두 로세스 정의 언어를 혼합하여 사용하고자 시도할 가능성이 높아

진다. 즉, 기존의 로세스 정의 언어의 일부를 변형하거나 확장하여 BPQL

요소를 추가하는 시도가 일어나게 될 것이다. 물론 이 게 혼합된 형태의

로세스 정의는 여러 BPMS 시스템간의 호환성을 해 BPQL 표 에서 정의

되는 립 인 형태의 로세스 정의로 변환될 수 있을 것이다. 이때 개별

BPMS에서 제공하던 부가 인 요소들이 락될 험은 여 히 상존하게 된

다.

이상의 두 측면이 BPQL 표 의 설계시에 기존 로세스 정의 언어와의

호환성과 련하여 원활히 이루어질 수 있도록 고려되어야 할 것이다.

이 외에도 BPQL 표 이 채용하게 될 문법과 개념이 계형 모델 보다는

객체지향 모델에 기반을 두어야 할 필요가 있다. 재 리 사용되고 있는

부분의 로세스 정의 언어들이 객체지향 개념에 근거하여 제시되고 있으며,

- 124 -

특히 기존의 SQL OQL 표 에 한 기능 인 포함 계를 해서는 객체

지향 개념에 근거하는 것이 보다 자연스럽다고 하겠다. 특히 로세스 메타모

델이 객체와 객체 인스턴스 등의 객체지향 인 개념을 통해서 쉽게 정의될 수

있고, 객체간의 계성(association)에 의해 상호작용이 쉽게 기술될 수 있다는

측면에서 더욱 그러하다.

4 . 시 간 ( Temporal) 요소 의 지 원

WfMC의 워크 로우 참조모델 뿐만 아니라 많은 BPM 모델에서 요구하고

있는 로세스 정의 요소로써 시간이 있다. 시간 요소는 기존에 실시간 로

세스 데이터의 인출과 같은 연구에서 실행시간 요소에서 많이 그 필요성이 언

되어 왔으나, 로세스의 정의시간 요소로써도 BPQL에서 매우 요하게 다

루어지고 있다.

BPQL 표 을 통해 BPMS의 실행시간 데이터와 응용 로그램의 실행환경

정보가 로세스 질의에 포함될 수 있기 때문에 해당 데이터에 한 시간

상 시간의 제어 요소가 명확히 정의될 필요가 있는 것이다.

이미 몇몇 BPMS에서 로세스의 실행 조건이나 트랜지션 조건을 해 제

한 으로 시간 요소를 도입해서 사용해 왔는데, BPQL에서는 이들 요소를 모

두 포함하되 시간 요소에 한 체계를 제시할 필요가 있다. SQL에서

CurrDate와 같이 재 시스템의 시간을 반환하는 함수가 제공되고 있는

데, BPQL에서는 이보다 훨씬 복잡한 시간 요소의 정의와 함수들이 제공되어

야만 할 것이다.

를 들어, 특정 로세스나 활동의 실행 조건 등이 시간에 기 해

정의될 수도 있지만, 병렬 으로 진행되는 다른 로세스나 활동의 상태 등에

기 할 수도 있다. 이처럼 BPQL 내에서 시간 요소를 지원하기 해서는 로

- 125 -

세스의 런타임 데이터에 한 시간 정보를 로세스 메타모델을 통해 표 으

로 정의할 필요가 있다. 즉 로세스와 활동의 실행시간, 종료시간 등에 한

정보들이 메타모델에서 정의되어 로세스 정의에 활용될 수 있어야 하며,

BPQL은 이러한 시간 요소를 질의 속에 포함할 수 있어야 한다.

제 3 BPQL의 기반 연구 사 례

본 에서는 비즈니스 로세스를 한 질의 언어를 정의하고 이를 로세

스 정의 내부에서 사용하기 한 기존의 표 인 근법들을 개략 으로 정

리하고, 최근 유럽연합의 탁 과제로 진행된 ICONS 로젝트 내에서 BPQL

의 활용 사례를 설명하기로 하겠다.

1. BPQL 련 연구 황

비즈니스 로세스의 모델 정의와 련된 무수한 연구들이 상당 기간에 걸

쳐 다양하게 진행되어 왔으며, 최근에는 웹 서비스와 BPM 표 을 심으로

새로이 개되고 있는 실정이다. 여기에서는 이런 많은 연구들 에서 비즈니

스 로세스의 질의를 한 언어 표 의 연구와 직․간 으로 련되는

표 인 몇몇 연구들만을 심으로 살펴보기로 하겠다.

가 . W eb ML 표

이탈리아의 Stefano Ceri와 Ioana Manolescu는 2003년에 VLDB 컨퍼런스

에서 “Constructing and integrating data-centric Web applications:

methods, tools and techniques"라는 짧은 논문을 통해 웹 어 리 이션의 설

계를 한 언어로 WebML(Web Modeling Language)을 제시하 다.

WebML은 하이퍼텍스트를 인식하는 응용 로그램들의 구성과 네비게이션

속성을 명시하기 한 그래픽 표기 언어로써, E-R(Entity-Relationship), UML

- 126 -

과 같은 인 표 을 기 로 하여 작성되었다. WebML을 통해 사용자는

복잡한 웹 어 리 이션을 랫폼에 립 인 형태로 명세하고, 이를 통해 질

의, 평가 유지보수를 할 수 있는데, 특히 로세스 정의를 해 제공되는

기능성이 강력하여 보다 유연한 로세스 정의가 가능하다는 에서 많은 주

목을 받고 있다.

WebML에서는 크게 데이터 모델, 하이퍼텍스트 모델, 젠테이션 모델

그리고 WebML 로세스라는 네 가지의 표 요소들을 제시하고 있다. 데이

터 모델은 데이터베이스 설계, 소 트웨어 공학, 지식의 표 과 같은 여러 분

야에서 이미 사용되고 있는 것과 유사한 형태로 데이터 설계의 개념 인 모델

을 제시하고 있다. 이 모델은 E-R 데이터 모델과 UML 클래스 다이어그램에

호환성을 지니며, 객체지향 모델링의 틀을 지키고 있다.

하이퍼텍스트 모델은 특정 웹 사이트의 네비게이션과 구성을 명세하는 그

래픽 표기법을 정의하고 있는데, 특정 웹 페이지 구성의 명세를 통해 동 인

페이지 템 릿의 자동 생성과 후단의 데이터 근 질의문의 조작 등을 가

능하게 한다.

WebML의 하이퍼텍스트 모델에 정의된 엘리먼트로는 Data unit, Multidata

unit, Index unit, Multi-choice index unit, Hierarchical index unit, Scroller

unit, Entry unit, Global parameter, Set unit, Get unit, Creat unit, Delete

unit, Modify unit, Connect unit, Disconnect unit, Login unit, Logout unit,

Sendmail unit, Generic operation unit, Transaction, Page, OR sub-pages,

AND sub-pages, Area, Site view, Link 등이 정의되어 있는데, 웹 어 리

이션의 화면을 구성하기 한 그래픽 요소들과 해당 웹 어 리 이션의 데이

터 조작 연산을 한 요소들이 다양하게 정의되어 있음을 알 수 있다. 다

음 그림은 WebML에서 정의하고 있는 하이퍼텍스트 모델 기본 유닛들을 활

용하여 웹 페이지를 모델링한 를 보여주고 있다.

- 127 -

<그림 5-4> WebML 하이퍼텍스트 모델을 활용한

리젠테이션 모델은 웹 페이지의 외형을 가시화하기 한 요소를 정의한

것이며, WebML 로세스는 웹 어 리 이션의 실제 증 인 개발 과정과

련한 근법을 정의한 것으로 본 연구에서 다루고자 하는 비즈니스 로세

스 모델링 질의 언어 표 과 련성이 낮아 추가 인 언 을 하지는 않겠

다.

- 128 -

이 게 WebML로 정의된 웹 어 리 이션은 XML로 표 되어 다양한 웹

어 리 이션 서버 환경에 배포될 수 있다.

WebML에서 제시되고 있는 데이터 모델과 하이퍼텍스트 모델은 그 유연성

이 높아서 워크 로우 심의 웹 어 리 이션 구성과 련한 연구에 활발히

응용되고 있는 실정이다. 특히 조건문을 평가하거나 워크 로우 참여자를 결

정하기 해서는 그 값이 복잡한 로그램에 의해 계산되어야 할지도 모르는

속성(attribute)값들을 로세스 정의 내에서 사용할 수 있어야 하는데,

WebML의 근법을 이를 해 활용하고자 하는 시도가 진행 에 있다고 한

다.

그러나 WebML의 주된 상 역이 웹 어 리 이션으로 워크 로우

로세스 모델링과는 차이가 있기 때문에 기존의 비즈니스 로세스 모델 정

의와는 호환되지 않는다는 한계를 가지고 있다. WebML은 다양한 실제의 어

리 이션에서 테스트 되었으며 몇몇 비즈니스 환경에서 작동 에 있는 표

으로, 충분히 BPQL 표 을 한 로세스의 정의에 활용할 가치가 있다고

하겠다.

나 . W PA L을 통 한 동 인 모델 변 경

폴란드의 Mariusz Momotko와 Kazimierz Subieta라는 두 연구자를 심으

로 제안된 WPAL(Workflow Participant Assignment Language)은 기존의 워

크 로우 시스템에서 제약으로 자주 언 되고 있는 정 인 로세스 정의에

한 가정을 확장하려는 표 인 시도로 볼 수 있다.

동 인 워크 로우 환경의 구성을 한 기존 연구들은 부분 제어 흐름

(control flow)의 원활한 지원에 을 맞추고 있는 반면, 워크 로우 참여자

(participant)의 동 할당과 같이 로세스 정의 자체의 변형이 요구되는 환경

- 129 -

의 지원은 상 으로 미미한 상태 다. WPAL은 이러한 한계를 극복하기

해 워크 로우 참여자의 동 할당을 정의할 수 있는 기능 언어로써 제시되

었다. 로세스 설계자는 WPAL을 통해 워크 로우 제어 데이터( 를 들어

지정된 활동의 수행자 정보, 시작 활동에 한 객체 참조)를 로세스 정의에

사용할 수 있는데, 이것이 결국 로세스 정의가 동 으로 변화할 수 있는 유

연성을 제공하게 된다는 에서 많은 연구자들의 심을 받게 되었다.

WPAL은 WfMC에서 정의한 WPA를 확장하여 일련의 함수들을 제공하

으나, 이 게 얻어진 로세스 정의의 유연성에도 불구하고, WebML이 가졌

던 것과 유사한 한계 을 지니고 있었다. 즉, 보다 근본 인 로세스 메타모

델에 한 완 한 정의를 통해 BPQL의 모든 요소들을 밝 내고 이를 통해

로세스와 질의를 기술하기 한 체계 인 근이 제시되지 않고 있다는

이다.

다 . X Query 표 의 활 용

XML이 정형 혹은 비정형의 문서 데이터에 한 효과 인 표 방식으

로 리 사용되면서 XML 문서를 상으로 하는 표 질의 언어에 한 요구

가 꾸 히 있어 왔다. XQuery는 이러한 XML 질의를 한 W3C의 표 으로

서 XML Query 워킹그룹과 XSL 워킹그룹의 공동 노력을 통해, 재 1.0 버

의 안(Working Draft)이 발표된 상태이다. 표 이 아직까지는 안 상태

에 있기 때문에 향후로도 변경될 가능성이 존재한다.

XQuery는 질의문이 간결하면서도 쉽게 이해될 수 있도록 설계되었으며,

데이터베이스에서부터 문서에 이르기까지 매우 다양한 스펙트럼의 XML 정보

소스들에 질의를 할 수 있을 정도의 유연함을 갖고 있다. 향후 XQuery는

SQL/XML과 마찬가지로 XML 데이터의 검색 처리를 한 표 으로 자리

- 130 -

잡을 것으로 상된다.

XML의 성 때문에 XQuery와 같은 XML 계열의 질의 언어가 비즈니

스 로세스를 한 질의 언어 표 의 안으로 인정받을 가능성도 있다. 이

러한 XML 계열의 질의 언어는 매우 명확한 문법과 다양한 일련의 연산자들

을 제공하고 있다는 장 을 가지고 있으나, XML 문서 정의로부터 생된 몇

몇 제약에 의해 한계 한 지니고 있다. 표 으로는 사이클이 없는 다 다

계의 계층 인 데이터 구조를 가진다는 과 XML 문서의 싱과 처리를

해 발생하는 성능상의 부하가 상당하다는 실 인 문제 들이 주로 지 되

고 있다.

그러나 최근 리 이용되고 있는 로세스 정의 언어 부분이 XML 문서

의 형태로 정의되어 있음을 감안할 때, XML 장소 등에 유지되고 있는

XML 로세스 정의 문서를 상으로 XQuery를 활용하는 형태의 BPQL 표

이 정의될 가능성도 배제할 수는 없겠다. 이때, XQuery를 BPQL 표 에 활

용하는 방안이 성공 이기 해서는 XQuery를 확장하여 워크 로우 혹은 비

즈니스 로세스 분야에 특화된 기능과 로세스 인 개념이 포함될 수 있도

록 하는 것이 요하다.

라 . SQL 계 열 O QL 표 의 활 용

BPQL 표 을 한 다음 안으로 고려해 볼 수 있는 것이 SQL 질의 언

어 계열이다. 이들 언어는 이미 이며 리 사용되고 있기 때문에 다양

한 사용자 층을 확보하고 있는 상태이며, 모든 계형 데이터베이스 리시스

템에서 구 되어 제공되므로, 이를 기반으로하여 작성된 BPQL 표 을 비교

쉽게 보 할 수 있다는 장 이 있다. 이들은 계형 데이터에 용되며, 엔티

티 사이의 매우 다양한 계성 까지도 비교 높은 수 까지 지원할 수 있도

- 131 -

록 꾸 히 그 문법과 스펙이 확장되어 왔다.

그러나 이들 언어의 많은 장 에도 불구하고 SQL 계열 질의어의 문법을

살펴보면 SQL-89에서부터 SQL-92와 SQL-99에 이르기 까지 지속 인 확장

과 추가 작업으로 인해 매우 복잡해지게 되었다. SQL의 group by 연산자나

null 값에 한 지원 등의 요소들은 상당한 제약을 지니거나 논란을 유발시키

고 있다. 한 몇몇 요소들은 의미상의 모호성까지도 지니고 있는 것으로 지

되고 있다. 게다가 BPQL의 모델 요소가 객체지향형으로 정의되는 것이 바

람직하다는 측면에서 볼 때 계형 뿐만 아니라 객체- 계형 구조까지를 지원

할 수 있도록 확장된 SQL-99가 강력한 안의 하나로 인식될 수 있겠지만,

1500여 페이지에 달하는 스펙을 구 하여 시스템 상에서 지원하는 작업은 작

은 소 트웨어 회사들에게는 분명 한계를 넘는 지나치게 모험 인 작업이 될

것이다. 이 외에도 비즈니스 로세스에 한 질의의 성격상 상당한 수의 객

체 참조에 한 네비게이션이 필요한데, 기존의 SQL 계성만으로는 이에

한 충분한 지원이 부족한 상태이다.

SQL 계열의 표 언어 외에도 BPQL 표 을 한 다른 안으로 생각

해 볼 수 있는 것이 바로 객체지향 질의 언어 계열을 사용하는 것이다. 객체

지향 모델을 기반으로 하여 작성된 표 질의 언어이므로 비즈니스 로세스

메타모델에 한 다양한 유형의 질의들을 표 하기에 가장 합한 것으로 보

인다. 그러나 재까지 발표된 객체지향 혹은 객체 계형 질의 언어 스펙만으

로는 비즈니스 로세스의 특성을 잘 지원할 수 있는 표 은 없어 보인다. 가

장 리 알려져 있고, 다른 객체지향 질의 언어 스펙에 비해 일 되면서도 명

확한 내용을 정의하고 있다고 인정받고 있는 ODMG의 OQL에서도 의미상의

모호성과 련하여 여 히 많은 이견이 존재하고 있기 때문이다. 더구나 객체

지향 질의 언어계열에서 계형에 비해 가장 자주 지 받고 있는 이 바로

계형 연산 논리에 필 할만한 설득력을 갖춘 연산 의미론의 체계이다.

- 132 -

이러한 요소가 결여된 재 상태의 OQL에서는 질의 최 화 문제가 여 히

해결되지 않은 문제로 남아있게 된다는 한계를 가진다.

이상의 내용을 종합해 볼 때, 지나치게 복잡해져 버린 SQL 계열의 단순

확장이나 OQL의 활용만으로는 비즈니스 로세스의 특성을 잘 지원하면서도

의미상의 명확성과 유연성을 가지는 BPQL 표 을 이끌어 내는 것은 상당한

한계를 지닐 것으로 보인다. 그러나 기존의 표 인 질의 언어에 한 지원

이나 고려 없이 새로운 BPQL 표 이 설계된다면 거시 시스템과의 통합에

서 다른 연계 문제들을 유발시키게 될 것이다.

마 . SBQL의 활 용

기존의 다른 질의 언어 표 을 활용하는 방법과는 다르게 기술 으로

BPQL의 설계에 고려해야할 최근의 연구결과로 SBQL(Stack Based Query

Language)을 언 할 필요가 있다. SBQL은 앞서 언 된 언어들에 비해 간단

하면서도 형식 이고 일 된 의미론을 제공한다. 뿐만 아니라 SBQL은 질의

최 화 방법론을 제공하며, 특히 질의 재작성 방법, 인덱스 활용 결과를 만

들어 내지 않는 죽은 질의문의 삭제와 같은 다양한 기법을 갖추고 있다.

SBQL은 일반 인 로그래 언어에서 요시되는 스코 (scope), 네임

(name) 바인딩(binding) 요소를 질의 언어의 설계에 극 으로 수용한 것

으로, 자체 인 데이터 모델과 장 공간을 가지는 추상 인 기계(Abstract

Machine)의 개념을 도입한 다음, 스택에 기반을 두어 연산을 진행하도록 하여

스코 를 처리할 수 있게 하 다. 즉, 스택기반의 근법(SBA: Stack-Based

Approach)을 질의 언어에 도입한 결과 얻어진 것이 SBQL이다. SBQL은 질의

에서 발생하는 개별 네임이 해당 네임에 한 스코 와 함께 한 실행시간

요소(즉 특정 객체, 속성, 메쏘드의 인자 등)와 결합되어 스택을 통해 유지되

- 133 -

도록 한다.

SBA에서는 질의 언어를 로그래 언어의 특별한 형태로 간주한다. 따라

서 질의의 의미는 로그래 언어에서 함수의 호출 스택과 같이 잘 알려진

메커니즘에 기반을 두고 있다. 거의 모든 로그래 언어에 구 되어 있는

통 인 스택의 개념이 데이터베이스 컬 션과 SQL OQL의 에서와 같

이 모든 타입의 질의 연산자들을 지원하기 해 확장되었다. SBA는 재

selection, projection, navigation, join, quantifier 다양한 질의 연산자를 제

공하고 있다. 스택은 한 재귀와 라메터를 지원하므로, SBA에서 정의되는

모든 함수, 로세져, 메쏘드 뷰에서 재귀가 가능해 진다.

SBA를 사용하여 객체지향 개념에 계성과 질의 명령어 요소들을 포함시

키고, 질의를 근본 으로는 로시 , 함수, 뷰, 메쏘드, 모듈 등과 같은 로

그래 에서 자주 언 되는 요소들에 개념 으로 응시켜 정의함으로써 질의

언어의 운 상의 의미를 명확히 결정할 수 있다는 장 이 있다.

SBA는 일반 인 객체의 장 모델을 정의하고 있는데, M0, M1, M2

M3 등으로 열거되는 일련의 객체 장 모델을 가정한다. 가장 간단한 것이

M0로 계형, 첩된 계형 XML 지향의 DB를 담당한다. M0는 객체나

콜 션의 첩과 련해서 아무런 제약이 없는 계층형 객체들을 가정하고 있

다. M0는 객체들 간의 이진 링크( 계성) 한 지원한다. M1은 M0의 상

수 장 모델로 클래스와 정 상속성의 개념을 추가로 도입하며, M2는 객

체의 역할과 동 상속성의 개념을 장 모델에 추가하 다. 마지막으로 M3

장 모델은 캡슐화의 개념을 제공하도록 설계되었다. 이들 모델들에 해서

SBQL로 정형화된 질의 언어가 설계되어 제시되고 있다.

SBQL은 추상 문법과 연산자의 완 한 온톨로지에 기반을 두고 있기 때문

에 계형 연산 계산법과 같은 수학 인 성질을 가지고 있다. SBQL은 명

령형의 확장과 추상화와 함께 로그래 언어와 같은 계산 능력도 가진다.

- 134 -

구체 인 문법, 특별한 기능성, 장모델의 두드러진 특징 구체 인 메타모

델은 SBQL로부터 비교 쉽게 BPQL과 같은 구체 인 질의 언어를 만들 수

있을 것으로 기 되고 있다. 재 SBQL은 유럽 로젝트와 DOM 모델을 기

반으로 하는 XML 장소, 그리고 객체지향 DBMS인 Objectivity/DB 상에서

표 인 구 사례를 가지고 있다.

2 . I CO NS 로젝 트 에 서 의 BPQL 구 사 례

ICONS(Intelligent Content Management System) 로젝트는 2002년 1월

부터 2004년 4월에 걸쳐 수행된 유럽연합의 연구과제의 일부로, 웹 페이지나

기존의 이기종 데이터베이스(문서나 구조 혹은 멀티미디어 형태)에 비즈니

스 로세스 명세 운 인 정보와 같은 다양한 형태로 분산되어 있는 정

보 자원들을 통일되어 있으면서도 지식 기반의 근이 가능하도록 지원하는

로토타입 랫폼의 개발을 목표로 하여 추진되었다. 이 로젝트의 내용

에서 로세스 지식의 효과 인 리 활용을 해 BPQL 개념을 정의하고

구 한 사례가 있다. 본 소 에서는 해당 사례를 정리한 논문의 내용을 심

으로 살펴보기로 한다.

가 . I CO NS의 BPQL 연구 개 요

지난 시간동안 워크 로우 리 시스템이 상당한 성과를 거두고 다양한 비

즈니스 로세스를 지원하는 WfMS가 사용되고 있지만, 로세스의 정의 자

체가 동 으로 자주 변화하게 되는 상황, 를 들면 리 모니터링 로세

스에서는 충분한 지원을 하지 못하고 있다. 이런 응용 분야에서는 특히 로

세스가 실행되는 런타임 환경의 정보가 로세스가 정의되는 시 에 활용될

- 135 -

수 있는 것이 요해진다. 해당 연구는 이러한 로세스 환경에서 로세스의

응성을 높이기 한 방법의 하나로 로세스 정의의 유연성을 제공하려는

시도를 하 다.

여기서 로세스 정의의 유연함이란 재의 조직 응용 로그램 데이터

(WfMC의 정의에 따르면 relevant data에 해당함) 뿐만 아니라 로세스의 실

행 이력에 의존하는 복합 인 동 요구사항을 로세스 정의 단계에서 명시

으로 표 할 수 있어야 함을 의미한다. 이러한 목 을 달성하기 해서

ICONS 로젝트에서는 해당 요구사항들을 히 표 할 수 있는 로세스

메타모델을 정의하고, 이 모델에 해서 질의를 할 수 있는 언어를 개발하여

BPQL로 제시하 다. 이 연구에서는 한 제시한 BPQL을 기존의 XPDL과 통

합하여 사용하는 방법을 보이고, OfficeObjets라는 상업용 워크 로우 시스템

상에서 구 한 결과를 제시하고 있다.

나 . 로세스 메 타 모델과 비즈니스 로세스의 정 의

로세스 메타모델은 로세스의 정의 단계와 실행단계라는 두 과정을 유

기 으로 표 할 수 있어야 한다. 로세스 정의는 워크 로우나 BPM 엔진에

의해서 로세스의 실행을 해 사용이 되며, 로세스 실행은 해당 로세스

의 모니터링과 분석을 해 주로 사용될 것이다.

WfMS를 일반 인 IT 응용 로그램의 하나로 간주할 때, 워크 로우 혹은

BPM 환경에 한 요구사항은 처리되는 데이터, 제공되는 서비스, 그리고 이

러한 데이터에 한 서비스처리를 담당하게 되는 리소스라는 세 가지 차원이

존재한다. 그리고 이런 세 가지 요소들을 기술하는 데이터들이 다시 WfMS에

의해 사용된다. 다음의 그림은 이 게 IT 요소로써 악하는 워크 로우 시스

템의 개념 인 구성을 나타내고 있다.

- 136 -

<그림 5-5> IT 어 리 이션의 일부분으로써의 워크 로우

시스템

제공되는 서비스들은 로세스의 활동을 표 하기 해 사용될 수 있는데,

활동이 실행되는 동안 WfMS는 이들 서비스를 한 인자와 함께 호출하게

된다. WfMS에서는 이것을 응용 로그램이라 부르며 보통은 활동을 수행하는

사용자와 자동 에이 트들이 모두 포함된다.

자원들은 역할이나 그룹 혹은 조직 단 를 사용하여 선택될 수 있는데,

로세스의 실행에 참여할 수 있는 자원을 워크 로우 참여자(participant)라 부

른다. 이 외에도 WfMS에서는 워크 로우 제어 데이터라는 개념을 사용하는

데, 이것은 재 활동 인 로세스 인스턴스의 개수, 지역화(Localization)

국제화(Internationalization)와 련된 설정 사항 처럼 특정 WfMS에 의해

서 리되어야 하는 설정 제어 정보들을 의미한다.

워크 로우를 한 로세스 메타모델은 워크 로우 Entity와 이들 간의

계성 기본 인 속성(attribute)들을 정의하며, 크게는 로세스 정의 메타

- 137 -

모델과 로세스 인스턴스 메타모델이라는 두 개의 부분으로 구성된다. 자

는 로세스 정의와 이들 간의 계성, 그리고 기본 속성들을 정의한다. 이것

은 비즈니스 로세스를 컴퓨터상에 설계하고 구 하기 해 사용된다. 후자

는 로세스 인스턴스와 이들 간의 계성 기본 속성들의 정의하며, 로

세스 정의 모델에 따라서 수행된 로세스의 실행을 표 하기 해 사용된다.

이외에도, 워크 로우 로세스 메타모델은 어떻게 개개의 로세스 정의 요

소들이 로세스의 실행 동안 인스턴스화되는 지를 정의하여 제공한다.

로세스 정의 자체는 메타모델의 가장 요한 요소로, 일련의 활동들로

구성된다. 여기에는 일련의 데이터 컨테이 와 속성들이 정의되는데, 이런 속

성값들이 로세스의 실행 에 트랜지션 조건이나 사 /사후 조건과 같은 조

건문들의 평가에 활용된다. 하나의 활동은 로세스를 처리하기 한 체 작

업에서 하나의 논리 인 단계를 형성하는 것으로, 여기에는 기본(atomic) 활

동, 라우트(route) 활동 복합(compound) 활동의 세 가지 유형이 존재한다.

기본 활동은 말 그 로 더 이상 쪼갤 수 없는 로세스 내에서 최소의 논

리 단계를 나타낸다. 모든 기본 활동에 해서 가 이것을 수행할 것이며,

어떻게 실행되고 어떤 데이터가 처리되는지를 정의할 수 있다. 기본 활동은

하나 이상의 워크 로우 참여자에 의해 수행될 수 있다. 워크 로우 참여자는

사용자(혹은 사용자 그룹), 역할 조직단 를 나타내며, 특별한 경우에는 시

스템이 워크 로우 참여자로 처리되는 경우도 있다. 이처럼 활동에 한 참여

자 할당을 명세하는 것을 워크 로우 참여자 할당(WPA: Workflow

Participant Assignment)라 부른다. 이러한 명세에서 응용 로그램에 달될

일련의 인자들이 포함될 수도 있다. 해당 응용 로그램은 데이터에 한 연산

을 수행하기 때문에 이 활동에 의해 처리(즉, 생성, 변경, 읽기 삭제와 같

은)될 객체의 유형이 정의될 필요가 있다. 이러한 객체 유형은 워크 로우

로세스들과 련되거나 이들에 의해 처리될 응용 로그램 데이터의 일부가 되

- 138 -

며, 워크 로우 련 데이터(relevant data)로 불린다.

복합 활동은 보통 서 로세스를 나타내며, 로세스의 정의를 단순화시

키기 해 도입되는 것이 일반 이다. 특히, 많은 비즈니스 로세스들에서 공

통 으로 나타나는 활동들에 해서 이를 서 로세스화하여 라이 러리나

템 릿 등을 구성하는데 활용될 수 있다.

마지막으로 라우트 활동은 분할(split)과 결합(join)과 흐름제어를 표 하기

해 사용된다. 분할과 결합 모두에 해 AND와 XOR라는 두 가지의 기본

인 제어 흐름이 정의되어 있다. 이들 기본 인 연산을 결합하여 보다 복잡한

흐름을 만들어 낼 수도 있다. 라우트 활동은 시스템에 의해 수행되며, 체

로세스의 흐름에 여할 뿐 실제의 작업 처리를 수행하는 것은 아니다.

로세스 내에서 활동의 순서는 트랜지션에 의해 정의되는데, 트랜지션은

두 개의 활동 사이의 계를 나타낸다. 한 활동에서 다른 활동으로의 트랜지

션은 조건부(트랜지션을 허용할지 아니면 막을지를 평가하는 표 식이 있을

경우)이거나 무조건 일 수 있다.

일단 워크 로우 로세스가 정의된다면, 여러 번에 걸쳐 실행될 수 있는

데, 특정 워크 로우 로세스가 정의에 따라 실행되는 것을 로세스의 실행

(enactment)이라고 부른다. 이러한 실행 컨텍스트에는 실제 수행자(워크 로우

참여자)와 구체 인 련 데이터(relevant data) 특정 응용 로그램의 호출

인자 등을 모두 포함하게 된다.

로세스 인스턴스는 로세스가 정의에 의해서 실행된 상을 지칭하며,

그 행동 양태가 상태(states)에 의해서 설명될 수 있다. 어떤 로세스 인스턴

스의 상태에 한 이력은 해당 로세스 인스턴스를 포함하고 있는 데이터 컨

테이 에 의해 유지되며, 로세스의 후속 실행을 제어하는데 사용될 수 있다.

이러한 모든 요소들에 한 개념 인 정의가 바로 로세스 메타모델이 되

며, BPQL이 로세스의 정의 단계와 실행 단계 모두에서 정확성을 가지며 표

- 139 -

되기 해서 반드시 필요한 요소이다. 본 연구 사례에서 제시된 로세스

메타모델이 다음의 그림에 개략 으로 나타나 있다.

<그림 5-6> 로세스 메타모델

다 . SBA 에 기반 을 둔 BPQL의 정 의

ICONS 로젝트에서는 로세스 메타모델을 정의하고 이로부터 정보를 추

출하기 해 비즈니스 로세스를 기술하는 질의 언어를 BPQL이라는 이름으

로 정의하 다. ICONS의 BPQL은 다른 표 인 질의 언어와 유사하게 명확

한 문법과 모호하지 않은 의미성을 가질 수 있으면서도, 객체지향 모델로 기

술된 로세스 정의에 해서 복잡한 질의까지도 표 할 수 있도록, SBQL이

라는 스택기반의 근법을 극 채용하 다.

ICONS의 BPQL은 특히 워크 로우에 특화된 기능을 제공할 수 있도록 많

- 140 -

은 부분에서 SBQL을 확장하 는데, 로세스 정의 인스턴스를 그래 구

조 속에서 쉽게 연산할 수 있도록 다양한 함수들을 제공하고 있다. 여기에는

특정 로세스에서 최 의 활동, 재 실행 인 활동, 진행 가능한 모든 후행

활동 바로 직 의 선행 활동 등과 같은 정보를 인출할 수 있는 기능 등이

포함되어 있다. 이 외에도 주어진 질의의 호출 컨텍스트에 한 정보들을 추

출하는 함수들, 를 들어, 재 처리되고 있는 활동을 인출하는 함수의 경우,

질의가 어떤 로세스에 해서 던져지는지를 알아야 할 필요가 있기 때문에

이러한 요소들에 한 추가 인 지원이 포함되어 있다.

BPQL은 EBNF 표기법에서 문맥자유형 문법(context-free grammar)로 정

의된다. 다음의 <표 5-2>는 ICONS BPQL의 간략한 문법을 정리한 것이다.

BPQL은 quantifier, selection, dependent join, projection, navigation(path

expression)과 같은 모든 기본 인 non-algebraic 연산자(SBA 용어로)를 포함

하고 있으며, 많은 algebraic 연산자도 제공한다. 이들 에서도 “if q1 then

q2 else q3”와 같은 형태의 조건 질의문, “as”와 같은 alias 연산자, 형 인

수학 문자열 연산자, 그리고 비교 논리 연산자 등이 포함되어 있음을

의 문법을 통해 확인할 수 있을 것이다.

BPQL 질의는 한 함수를 호출할 수 있는데, 인자를 가지는 함수의 호출

한 정식의 BPQL 질의로 인정된다. 반환된 결과 한 다른 BPQL 질의문

에 자유로이 재사용될 수 있다. 표 인 함수로 수학함수( 를 들어, COS,

SIN, SQRT)와 문자열 함수(CONCAT, SUBSTRING), 날짜 시간 함수(

를 들어, CURRDATE, YEAR, MONTH), 집합 함수( 를 들어, AVG,

COUNT, MAX) 등이 모두 제공된다.

이러한 기본 함수 외에도, BPQL에서는 워크 로우 분야의 특수성을 반

한 특화된 함수가 4개가 제공되고 있는데, 이것들을 통해서 BPQL 질의가 보

다 간결하고 명확해 진다는 장 이 있다. 각각을 살펴보면 다음과 같다.

- 141 -

<표 5-2> ICONS에서 정의된 BPQL의 문법

정규표 식 하 정규표 식

<query> ::= <literal>

| <name>

| e xi st s <query> (<query>)

| a l l <query> (<query>)

| <query>.<query>

| <query> whe r e <condition>

| <query> jo i n <query>

| <query> a s <query>

| <query> gr o u p a s <aliasName>

| <function>

| (queryList)

| i f <query> t he n <query> e l se <query>

| <algExpression>

queryList ::= <query> {, <query>}

<condition> ::= <logExpression>

<logExpression> ::= <logSum>

<logSum> ::= <logProduct> { o r <logProduct>}

<logProduct> ::= <logSExpression> { a n d <logSExpression>}

<logSExpression> ::= n o t <logSum> | (<logSum>) | <logCondition>

<logCondition> ::= <leftSide> <opComp> <rightSide>

<opComp> ::= < | < = | = | = > | > | < >

<leftSide> ::= <algExpression>

<rightSide> ::= <algExpression>

<algExpression> ::= <algSum>

<algSum> ::= <algProduct> { [+|-] <algProduct> }

<algProduct> ::= <algExpression> { [*|/|%] <algExpression> }

<algExpression> ::= (<algExpression>)

| <symbol> | <literal> | {<query>}

<function> ::= <fName> | <fName> (<queryList>)

<symbol> ::= <objName> {.<objName>}

<literal> ::= <text> | <integer> | <float> | <boolean>

<boolean> ::= t r u e | f a l se

F irstA ctI nst( ProcessI nstance) : A ctiv ityI nstance - 함수에 인자로

달된 로세스 인스턴스에 해 시작 액티비티를 나타내는 객체를 반

환한다.

- 142 -

Prev A ctI nst( A ctiv ityI nstance) : A ctiv ityI nstance[] - 함수에 인자로

달된 액티비티의 직 선행 액티비티를 표 하는 객체의 목록을 반환

한다.

A ctI nst( ProcessI nstance, A ctI D ) : A ctiv ityI nstance[] - 로세스

인스턴스 내에 액티비티의 인스턴스를 나타내는 액티비티 인스턴스들의

목록을 반환한다. 로세스 인스턴스 객체와 액티비티의 Identifier 모두

함수의 인자로 달된다.

Nex tI nstance( A ctiv ityI nstance) : A ctiv ityI nstance[] - 함수에 인자

로 달되는 액티비티 인스턴스의 바로 후행하는 액티비티 인스턴스 객

체의 목록을 반환한다.

이상의 네 함수 외에도 다음의 두 개 함수가 질의가 실행 에 있는 컨텍

스트와 련되어 추가로 제공된다.

Th isProcessI nst : ProcessI nstance - 지정된 질의가 실행 에 있는

로세스 인스턴스를 나타내는 객체가 반환된다.

Th isA ctiv ityI nst : A ctiv ityI nstance - 지정된 질의가 실행 에 있는

액티비티 인스턴스를 나타내는 객체가 반환된다.

라 . BPQL 질의문의 사 용

ICONS의 BPQL 문법을 사용하여 기술된 질의문 를 살펴보기로 하자.

선택 인 활동(optional activity)의

특정 활동은 주어진 로세스 인스턴스의 마감시한이 2일 이상이고 재

- 143 -

작업부하가 업무시간으로 볼 때, 8시간보다 은 수행자가 있을 경우에만 수

행되어야 한다.

<그림 5-7> 선택 인 활동의 를 나타내는 BPQL 질의문

(ThisProcessInst.deadline - Currdate) > 2 and exists (Performer as P where sum((P.performs.ActivityInst where status = 'open').duration) < 8)

참여자 할당의

특정 활동은 첫 번째 활동을 수행한 Performer에 의해서만 수행되어야 하

는데, 만약 이 Performer가 수행해야 할 활동에서 5개 이상이 지연 상태에 있

다면, 그 신 바로 이 의 활동을 수행한 Performer에게 할당되도록 한다.

<그림 5-8> 참여자 할당의 를 나타내는 BPQL 질의문

if count(FirstActInst(ThisProcessInst).performedBy. Performer.performs.ActivityInst where (delayed = 'yes' and status = 'open') <= 5then FirstActInst(ThisProcessInst).performedBy.Performerelse PrevActInst(ThisActInst).performedBy.Performer

로세스 정의에 활용된

랩탑을 주문하는 단순화된 로세스를 가정해 보기로 하자. 모든 등록된

고객들이 임의 으로 랩탑을 주문할 수 있을 것이다. 주문은 고객의 재정 상

태를 확인하고 요구된 시간에 주문을 충족시킬 수 있는지를 확인할 책임이 있

- 144 -

는 회사의 일반 매담당자(seller)에 의해 수용된다. 액이 보다 큰 주문이거

나 주문을 수용하기 한 시간이 충분치 않은 경우에는 해당 주문이 고참

매담당자(senior-seller)에 의해 처리된다고 해보자. 아닐 경우에는 보통의

매담당자가 처리하게 되는데 최소의 작업부하를 가지고 있는 담당자에 의해

처리되어야 한다. 여기서 최소의 의미는 할당된 작업의 수가 최소인 사람으로

가정하기로 한다. 일단 주문이 수용되면 해당 주문은 제조부서로 달된다.

이 게 단순화된 제에서도 로세스 정의에는 로세스의 실행 데이터가

포함되어야만 한다. 즉, 최소의 작업부하라는 요구사항은 재 작업의 할당 상

태에 한 질의를 통해서만 확인할 수 있는 사항이기 때문이다. 다음의 그림

에서 이러한 로세스 정의의 일부를 확인할 수 있다.

<그림 5-9> 로세스 정의에 사용된 BPQL 질의문의

if Order.Value > 30000 or (Order.DeliverDate - CurrDate) <= 2then User where position = 'Senior-Seller' and count(is.Performer.performs.ActivityInst where status = 'open') = min((User where position = 'Senior-Seller'). count(is.Performer.performs.ActivityInst where status = 'open'))else User where position = 'Seller' and count(is.Performer.performs.ActivityInst where status = 'open') = min((User where position = 'Seller'). count(is.Performer.performs.ActivityInst where status = 'open'))

- 145 -

의 그림에서 ‘is'라는 연 계는 User 객체를 Performer 객체에 연결하

고 요소이며, performs라는 연 계는 Performer 객체를 ActivityInst 객체에

연결하는 역할을 한다. 일반 으로 질의는 여러 명의 user(최소의 작업부하를

가지는 모든)를 반환할 수 있기 때문에, 이들 에서 한명을 무작 로 선택하

기 한 추가의 함수가 필요하다.

마 . BPQL을 사 용 한 유 연한 로세스 정 의

BPQL은 로세스의 실행 데이터에 의존하는 사항들을 로세스 정의에

사용할 수 있기 때문에 로세스 정의를 보다 일반화시킬 수 있게 해 다.

를 들어, 최소의 작업부하를 갖는 Performer에게 특정 활동을 할당하고자 할

때, 최소의 작업 부하는 해당 로세스가 실행된 후에야 얻어질 수 있다. 기존

의 로세스 정의에서는 이 게 실행 상태의 정보를 포함하여 지원하기가 어

렵기 때문에 주로 응용 로그램 내부에서 해결해야 하 으나, 확장된 로세

스 메타모델을 통해 정의되는 BPQL을 사용하게 된다면, 비교 쉽게 로세

스 정의에 이러한 내용들을 명세할 수 있다.

이처럼 BPQL은 트랜지션 조건, 워크 로우 참여자 할당, 사 혹은 사후

활동의 조건, 그리고 이벤트 처리(조건 부분)와 같이 워크 로우 련 데이터

제어 데이터에 한 연산들을 기술하기 해 사용될 수 있으며, 특히 이러

한 내용들이 로세스의 정의에 포함될 수 있게 한다.

과거에 이러한 내용들은 로세스 설계자에 의해 가려지거나 로그래

요소로 신 작성되었던 것이다. 그러한 상황에서는 빈번하게 로세스의 정

의나 로그램을 변경해야 하는 상황이 오게 된다. BPQL이 로세스 정의에

직 포함되어 높은 표 력을 통해 실행 시간 데이터의 요구까지도 명세할 수

있게 될 경우, 로세스 정의와 로그램의 재작성 없이도 높은 유연성을 제

- 146 -

공하게 된다.

바 . X PD L과 BPQL의 통 합

ICONS의 BPQL은 XPDL로 기술된 로세스 정의 내에서 BPQL을 사용할

수 있도록 함으로써, BPQL이 보다 폭넓게 활용 될 수 있도록 하 는데, 크게

트랜지션 조건, 참여자 할당 사 /사후 조건의 세 가지 내용을 명세하는데

BPQL을 도입하여 활용하고 있다. 각각에 해서 살펴보기로 하겠다.

트랜지션 조건

XPDL에서 트랜지션 조건은 Transitions/Transition/Condition이라는 XML

태그의 CONDITION 타입으로 표 된다. 그러나 이 조건이 어떤 형태로 보일

지에 해서는 명확한 스펙이 없다. 개의 경우 텍스트로 해당 조건이 기술

되는데, 이를 BPQL을 활용하도록 확장하는 방법을 제안하고 있다. 해당

BPQL 질의가 하나 이상의 객체를 결과로 반환할 경우, 조건이 만족된 것으로

처리하며, 반면에 결과가 비어있는 경우에는 만족하지 못한 것으로 처리하고

있다. XPDL에 포함된 를 살펴보면 다음의 그림과 같다.

<그림 5-10> XPDL의 트랜지션 조건에 사용된 BPQL 질의문의

<Transition Id="b1" From="ChckBalance" To="ProcRequest"> <Condition Type="CONDITION"> Order where (id = ThisProcessInstance.hasDataContainer.orderId and (value > 30000 or quantity > 100)) </Condition></Transition>

- 147 -

워크 로우 참여자 할당

WfMC의 정의에 따르면, 워크 로우 참여자 할당은 주어진 워크 로우 활

동을 수행하게 될 일련의 참여자들을 정의하는 것이다. 참여자는 자원(특정

자원 에이 트), 자원 집합, 조직 유닛, 역할(조직 내에서 인간의 기능), 인간

(사용자) 혹은 시스템(자동 에이 트) 등이 될 수 있는데, 여기에 BPQL을 활

용할 수 있을 것이다. 다음의 는 XPDL에서 ParticipantType에 확장 속성

(ExtendedAttributes)을 사용하여 BPQL을 도입한 것을 나타내고 있다.

<그림 5-11> XPDL의 참여자 할당에 사용된 BPQL 질의문의

<Participant Id="p1" Name="Seller"> <ParticipantType Type="ROLE"> <Description>Seller</Description> <ExtendedAttributes> <ExtendedAttribute Name="Definition"> User where (position = "Seller") </ExtendedAttribute> </ExtendedAttributes> </ParticipantType></Participant>

사 사후 조건

지 까지 워크 로우 활동을 한 사 사후 조건은 XPDL 내에 직

으로 정의되지 않았지만 ExtendedAttribute 태그를 활용하여 BPQL을 통해

명시 으로 포함될 수 있을 것이다. 만약 BPQL 정의가 결과로 하나 이상의

객체를 반환한다면, 그 다면 조건이 만족된 것이고, 결과가 비어 있다면, 조

건이 만족되지 않은 것으로 간주된다. XPDL로 기술된 는 다음과 같다.

- 148 -

<그림 5-12> XPDL의 사 /사후 조건에 사용된 BPQL 질의문의

<Activity Id="56" Name="Compose Acceptance Message"> <Implementation> <Tool Id="composeMessage" Type="APPLICATION"> <ActualParameters> <ActualParameter>status</ActualParameter> </ActualParameters> </Tool> </Implementation> <ExtendedAttributes> <ExtendedAttribute Name="Pre-Condition"> Order where (id = ThisProcessInstance.hasDataContainer.orderId and status = 'closed') </ExtendedAttribute> </ExtendedAttributes></Activity>

사 . I CO NS BPQL의 활 용 사 례 결과

ICONS 로젝트에서 제안된 BPQL이 워크 로우 참여자 할당 기능을

상으로 Rodan 시스템사의 OfficeObject WorkFlow (OO WorkFlow)에 통합되

어 구 되었다. Rodan 시스템사는 폴란드의 표 인 워크 로우 BPMS

업체로, 이 회사의 OO WorkFlow 시스템은 Sanplast 사와 같은 개인 회사들

뿐만 아니라 폴란드의 노동 사회 복지부, 산업부와 같은 주요 공공 기 에

설치되어 있기도 하다.

BPQL에 한 최 의 실용 인 검증은 폴란드와 유럽 의회간의 자 인

- 149 -

문서 교환을 한 시스템(EWDP)에서 수행되었다. EWDP 시스템에서 OO

WorkFlow는 유럽 의회에서 COREPERS(Committee of Deputy Permanent

Representatives, Committees of Permanent Representatives)나 련 워킹그룹

에서 논의되었던 사안에 한 폴란드 정부의 입장을 비하기 한 로세스

를 구 하기 해 사용되었다. 이 로세스는 40개 이상의 활동들과 10여개

정도의 로세스 역할을 포함하고 있다. 모두 19개의 폴란드 정부부처와 앙

사무국에서 사용될 정인데, 등록된 사용자만 12000명에 달한다. 매일 략

200여 개의 문서가 처리되고 있는데, 평균 으로 폴란드 정부의 입장을 비

하는데 2~3일 정도가 소요된다고 한다.

BPQL을 사용하여 이런 로세스들이 한 워크 로우 참여자를 할당하

기 한 복잡한 규칙들과 함께 매우 쉽게 정의될 수 있었다. 이를 통해 로

세스의 소유자들이 시스템의 코드를 변경시키지 않고서도 로세스 정의를 쉽

게 변경시킬 수 있는 기회를 가질 수 있게 되었다.

- 150 -

제 6 장 연구 개 발 결과 의 활 용 방 안 기 효과

본 연구에서는 BPM의 국제표 화 기구와 국제 표 에 하여 조사하고,

BPM 표 의 참조 아키텍처를 제시하 으며, BPM 표 간의 구조 계를

분석하 다. BPMN의 BPD (Business Process Diagram)에 하여 체계 으

로 정리하 다. 한 BPMN을 BPEL4WS로의 매핑하는 규칙에 하여 정리

하 다.

BPMN을 분석하기 하여 다른 로세스 모델링 표기법과 비교하 으며,

BPMN의 표 력을 확인하기 하여 비즈니스 로세스의 패턴을 기 으로 검

증하 다. 한 BPMN의 활용방안을 제시하기 하여 BPD의 상 로세스

를 분류하고, BPD BPMN의 작성 가이드라인을 도출하 으며, BPMN의

사례를 제시하 다.

비즈니스 로세스 질의 언어의 연구 배경을 조사하고, 비즈니스 로세스

질의 언어를 한 설계 개념을 분석하 다. 한 BPQL의 기반 연구를 수행하

고, 사례를 조사하여 제시하 다.

본 연구의 기 효과와 활용방안은 아래와 같이 요약될 수 있다.

첫째, BPMN, BPQL BPEL4WS를 지원하는 소 트웨어의 개발자들에게

해당 표 들의 입문서로서 빠른 이해를 돕는데 활용될 수 있을 뿐 아니라, 소

트웨어의 개발에 있어서 구체 인 설계지침으로 활용될 수 있다. 특히 국내

환경에 맞는 용 사례의 개발은 보다 정확하고 신속한 표 의 이해 활용

을 가능하게 할 것으로 기 된다.

둘째, BPMS를 개발하는 소 트웨어 업체 도입을 검토하고 있는 업체들

에게는, BPM 련 핵심 표 들의 정확한 이해 상 가능한 기술 이슈들

을 사 검 악할 수 있게 해 으로써, BPM 표 의 수용과 련된

- 151 -

략을 수립하는데 있어서 시행착오를 최소화할 수 있을 것으로 기 된다.

셋째, 본 연구를 통해서 얻어진 결과는 BPM 개발 도입 기업들이 참조

할 수 있도록 표 안으로 작성하여 표 화 과정을 밟도록 할 정이다. 표

은 국내 실정에 맞게 작성됨으로써, 련 용어 개념의 표 인 한 용어

를 제공할 뿐 아니라, BPM 업계의 표 수용을 진하는데 활용될 수 있다.

마지막으로 BPMN, BPQL, BPEL4WS를 활용하고자 하는 로세스 설계

분석가들에게는 비즈니스 로세스 표 표기법 질의어를 학습하거나

련 교육자료를 제작하는데 참고자료로 활용될 수 있다.

- 152 -

참 고 문 헌

[1] 김인구, 문형남, 자결제론, 도서출 두남, 2003

[2] BPMI, BPMN 0.9 Visio Stencil, http://www.bpmn.org/documents.htm

[3] BPMI, Business Process Modeling Notation (BPMN) Version 1.0 - May

3, 2004

[4] BPMI, Introduction to BPMN, http://www.bpmn.org/documents.htm

[5] Ceri, S., Manolescu I., Constructing and integrating Data-Centric Web

Applications; Methods, Tools and Techniques, VLDB'2003, Berlin, Germany

[6] Hayes, J. et al., Workflow Interoperability Standards for the Internet,

IEEE Internet Computing, vol. 4, no. 3, May/June 2000, pp. 37-45.

[7] Intelligent Content Management System, IST-2001-32429, 5th EC

Framework Programme, www.icons.rodan.pl

[8] Momotko M., Subieta K., Business Process Query Language - a Way

to Make Workflow Process More Flexible, ADBIS'2004, Budapest, Hungary

[9] Momotko, M., Subieta. K., Dynamic change of Workflow Participant

Assignment, ADBIS'2002, Bratislava, Slovakia

[10] Smith, H. and Fingar, P., Business Process Management: The third

wave, Meghan-Kiffer Press, 2003

[11] Subieta, K., Beeri, C., Matthes, F., Schmidt, J., W., A Stack-Based

Approach to Query Language, East-West Database Workshop, 1994,

Springer Workshops in computing, 1995

[12] Workflow Management Coalition: The Workflow Reference Model,

WfMC-TC-1003 issue 1.1, Jan 1995

[13] Workflow Management Coalition: Workflow process definition language

- XML process definition language, WfMC-TC-1025, ver. 1.0, Oct 2002

비즈니스 프로세스 관리를 위한 질의 언어 및 모델링 표기법 표준화...

Documents