 | |
|
난이도 : 중급 Nicholas Bennett, Software Engineer,
IBM
Natalia Balaba-Liaskovski, Software Engineer,
IBM
2008 년 2 월 12 일 IBM® Rational® Software Architect는 소프트웨어용 서비스 지향 아키텍처(SOA)를 개발할 때 UML을 사용하여 SOA를 모델링 하는 툴입니다. 네 파트로 구성된 시리즈에서는 SOA 변형 기능에 대해 살펴봅니다. IBM®
WebSphere® Business Modeler 와 Rational Software Architect를 사용하여 비즈니스 프로세스를 SOA 모델로 변형하는 방법을 설명합니다.
비즈니스 프로세스 분석(Business Process Analysis) 모델 개요
전형적인 개발 사이클은 비즈니스 요구 사항과 목적을 파악하고 분석하는 것으로 시작된다. 이러한 분석에는 비즈니스 요구 사항에 맞는 서비스 지향 아키텍처(SOA) 솔루션을 구현하는데 필요한 핵심 서비스를 구분하는 일이 포함된다.
비즈니스 요구 사항들을 분석하는 일은 일반적으로 비즈니스 분석가가 수행하는데, 이들은 보통 IBM® WebSphere® Business Modeler를 사용하여 비즈니스 분석 모델(Business Analysis model ) (또는 서비스 스팩 모델(Service Specification
model))을 생성하고, WebSphere 소프트웨어의 빌트인 분석 및 시뮬레이션 기능을 사용하여 이 모델을 조정, 확장, 최적화 한다. 이러한 분석 단계의 결과물은 핵심 서비스를 정의하는 모델(비즈니스 프로세스), 인터랙팅 방식, 액터(actor)나 다른 서비스에 의해 호출되는 방식이다.
Jim Amsden의 "SOA 모델링" 컬럼의 "SOA 모델링: 서비스 스팩"에 서비스 스팩 모델링에 대한 상세한 설명이 되어 있다. (참고자료).
비즈니스 프로세스를 고급 아키텍처로 변형하기
이 사이클의 다음 단계는 비즈니스 분석 모델을 디자인 솔루션 아키텍처 모델(Design Solution Architecture model)로 옮기는 단계이다. 이는 주로 소프트웨어 아키텍처가 수행한다. IBM® Rational® Software Architect의 Business Process-Service Model 변형 기능이 이 과정을 돕는다.
WebSphere Business Modeler Integration 기능을 사용하여 설정된 Rational Software Architect 내에 WebSphere Business Analysis 모델 프로젝트를 사용할 수 있다. 이것을 열면, 소프트웨어는 비즈니스 연산 요구 사항들을 모델링 하는 토대로서 사용할 수 있는 비즈니스 모델을 UML로 표현한다.
WebSphere Business Modeler의 비즈니스 분석 모델은 비즈니스 프로세스의 역할 기반 뷰를 반영함으로써 UML로 변환된다. 다시 말해서, 비즈니스 프로세스를 태스크에 필요한 역할과 프로세스에 개입된 서비스 간 협업으로 볼 수 있다는 것이다. 각 필요한 역할을 각 태스크와 WebSphere Business Modeler에 대한 연산을 정의하는 UML 인터페이스로서 볼 수 있다. 그림 1은 한 비즈니스의 고객 주문을 핸들하는 방법을 설명한 WebSphere Business Modeler의 비즈니스 프로세스 부분이다. 이 뷰에서, 프로세스를 수영장 레인처럼 보여주는데, 각각 프로세스에 참여하는 특정 역할을 나타낸다.
고객 주문을 핸들링(Customer Order Handling) 하는 WebSphere Business Modeler 프로세스 부분
비즈니스 프로세스의 UML 표현에는 각 프로세스를 나타내는 UML 유스 케이스와, 이 유스 케이스에 참여하는 각 역할에 대한 액터가 포함된다. 이러한 표현을 통해서 역할과 프로세스간 관계를 볼 수 있는데, 이는 비즈니스 프로세스를 파악하기에 알맞다. 그림 2는 Customer Order Handling 비즈니스 프로세스의 유스 케이스와 액터를 보여주고 있다.
그림 2. Customer Order Handling 비즈니스 프로세스의 UML 유스 케이스
그림 3은 같은 프로세스를 표현하는 UML 협업에, 필요한 역할들을 나타내는 UML 인터페이스와 그 프로세스에 대한 UML 유스 케이스의 관계가 추가되었다. 이 그림에서, 그림 1에서 필수 CRMApplication 역할 (이를 테면, Determine Requester Status)로 보여준 태스크가 CRMApplication UML Interface(그림 3)에서는 연산으로 변환되었다.
유스 케이스와 협업 외에도, 비즈니스 프로세스의 작동 측면(다시 말해서, 태스크를 수행할 때 역할들이 서로 인터랙팅 하는 방식)은 협업에 의해 소유된 UML Activity로서 표현된다. 원래 비즈니스 프로세스에서 온 각 태스크는, 앞서 설명한 역할 인터페이스에 정의된 것처럼, 적절한 연산을 호출하는 UML Call Operation 액션에 의해 표현된다. 태스크들 간 흐름과 컨트롤 노드(결정, 사람들, 합병) 역시도 UML Activity에 표현된다. 이 협업은 어떤 역할들이 협동하여 프로세스를 정의하는지를 보여주고, Activity는 이러한 역할들이 서로 인터랙팅 하는 방식을 지정한다. 액티비티 내 파티션들은 협업 내 역할들을 나타낸다. UML 모델은 비즈니스 프로세스를 구현하는 어떤 솔루션 모델이라도 만족시켜야 하는 구조 및 작동 요구 사항들을 정의하는 스팩을 제공한다.
그림 3. 유스 케이스, 인터페이스, Activity에 대한 관계를 보여주는 Customer Order Handling 비즈니스 프로세스를 위한 UML 협업
팁:
WebSphere Business Modeler Business Analysis 모델의 엘리먼트와 UML 모델간 관계는Jim Amsden의 SOA 모델링 시리즈의 비즈니스 서비스 모델링 기술자료를 참조하라. (참고자료)
그림 4. Rational Software Architect에서 WebSphere Business Modeler 모델의 UML 표현
WebSphere Business Modeler에 있는 모델의 UML식 표현은 구축된 솔루션 모델에서 수행될 요구 사항 조건으로서 간주되어야 한다. Rational Software Architect의 Business Process-to-Service Model SOA 변형 기능의 목적은 초기의 또는 기본적인 SOA 솔루션 모델을 만드는 것이다.
변형을 생성 및 설정하려면, Modeling 퍼스펙티브에서 Modeling >
Transform > Create new configuration menu 를 선택한다. (그림 5) 변형은 WebSphere Business Modeler에서 열린 모델을 유효 소스로서, Eclipse 프로젝트를 유효 타겟으로서 받아들인다.
그림 5. 비즈니스 프로세스를 서비스 모델로 변형하기
그림 6은 WebSphere Business Modeler 모델과 타겟으로, 변형에 의해 생성된 아웃풋을 놓을 Eclipse 프로젝트나 폴더가 된다.
그림 6. 변형 소스 설정하기
변형에 의해 생성된 UML 서비스 모델은 각 비즈니스 프로세스를 위해 분석 모델로부터의 서비스 분해(decomposition)를 나타낸다. 변형 UI에서 분해 유형을 설정하고, 이것을 개별 비즈니스 프로세스에 적용한다. 분해 구조는 타겟 영역(구현 언어, 전개 환경 등)에 기반한다.
각 서비스의 분해는 확장에 의해 만들어 진다. 변형에는 세 가지 확장이 있지만, 이 세 가지(고급 UML, 일반 SCDL 분해, Do Not Transform을 위한 빈(empty) 구현)로만 제한되지 않는다. 변형은 확장성 있고, 클라이언트가 커스텀 확장을 생성 및 추가할 수 있다. 이 글 후반에 각각의 기본 확장에 대해 자세히 설명하도록 하겠다.
모델이 변형에 의해 생성된 후에, 시스템 또는 소프트웨어 아키텍트는 더 많은 구현 상세를 지정하거나, 재사용을 위해 다른 서비스나 레거시 라이브러리에 대한 레퍼런스를 만듦으로써, 서비스 모델을 조정할 수 있다.
요구 사항을 추적하여 콘트랙트 확인하기
특정 분해와 관계 없이, 변형에 의해 생성된 솔루션 모델(서비스 모델, 또는 콘트랙트 이행 모델)은 스팩 모델에서 정의된 콘트랙트 정보를 보존한다. 또한, 콘트랙트를 이행하는데 필요한 구현 상세를 제공한다.
스팩 모델의 비즈니스 프로세스는 UML Collaboration 엘리먼트로 나타난다. 스팩 모델의 UML Collaboration 엘리먼트는 솔루션 모델의 UML Component 엘리먼트로 변형된다. 변형을 통해 생성된 컴포넌트에는 비즈니스 프로세스에 필요하거나 제공된 서비스용 인터페이스를 지정하는 포트가 채워진다.
또한, 변형은 각 컴포넌트 내에 CollaborationUse 엘리먼트를 만든다. CollaborationUse 엘리먼트는 스팩 모델의 원래 Collaboration 엘리먼트와 서비스 모델의 Component 엘리먼트 간 연결을 관리한다. 변형은 컴포넌트 포트와 협업 역할 간 UML 바인딩을 만든다. CollaborationUse 엘리먼트를 통해 구축된 포트와 역할 바인딩은 서비스 소프트웨어의 일부로서 작동하는 콘트랙트 요구 사항에 역할들을 정의한다. 이는 이것이 수행하는 솔루션과 비즈니스 요구 사항들간 추적을 가능케 하고, 솔루션이 실제로 WebSphere Business Modeler 비즈니스 모델에서 제시하는 비즈니스 요구 사항들을 맞추고 있는지를 확인하는 수단이 된다.
그림 7의 예제는 Customer Order Handling 비즈니스 프로세스와 제휴 서비스 모델의 콘트랙트 확인을 묘사한 것이다.
그림 7. 복합 구조 다이어그램 예제
서비스를 나타내는 Customer Order Handling 컴포넌트에는 CollaborationUse 엘리먼트와, WebSphere Business Modeler에서 생성된 Business Analysis 모델에 정의된 Customer Order Handling Collaboration 엘리먼트를 가리키는 Collaboration 유형이 포함된다. Customer Order Handling Collaboration 역할들은 컴포넌트 포트에 의해 작동한다. 각 포트는 Business Analysis 모델에 명시된 것처럼, 비즈니스 프로세스에 의해 제공 또는 요구되는 인터페이스를 지정한다. 예: 서비스(myRole)에 대한 인터페이스를 제공하는 포트는 Collaboration 역할에 속하게 되는데, 이는 비즈니스 프로세스 자체를 나타낸다. 다양한 액터들(다른 서비스)을 나타내는 다른 포트들은 Collaboration 엘리먼트에서 각각의 역할로 연결된다. 이러한 포트들(PaymentHandling, OrderVerification, CRMApplication 등)은 인터페이스가 관련 액터와 통신하도록 한다. 필수 인터페이스들은 WebSphere Business Modeler 모델에 정의되고, Rational Software Architect에 있는 서비스 모델은 그러한 인터페이스를 가리킨다. (표 1)
표 1. 변형 매핑
| 스팩 모델 엘리먼트 | 변형 결과(UML 아키텍처 모델) |
|---|
| Model 또는 package | 변형을 통해 같은 이름을 가진 UML 모델 또는 패키지, 중첩된 패키지를 위한 봉쇄 구조, 협업이 만들어 진다. 중첩된 패키지나 협업에는 UML 액티비티가 포함되기도 한다. 인터페이스, 클래스와 데이터 유형, 액티비티 엘리먼트는 변형되지 않는다. 필요할 경우, 생성된 모델은 소스 모델에서 이러한 엘리먼트에 상응하는 관계를 만든다.
생성된 모델에는 <<serviceModel>>
스테레오타입이 적용된다.
|
|---|
| Collaboration | 이 변형을 통해서, Software Services 프로파일의 <<serviceProvider>> 스테레오타입으로 UML 컴포넌트가 생성된다. 생성된 컴포넌트는 소스 Collaboration 엘리먼트와 같은 이름과 봉쇄 구조를 갖는다.이러한 변형으로 각 컴포넌트에 대한 CollaborationUse 엘리먼트가 생성된다.
CollaborationUse 엘리먼트의 유형은 소스 모델에 협업 엘리먼트로 설정된다.
생성된 컴포넌트의 각 포트는 CollaborationUse 엘리먼트를 통해 협업 속의 각 역할로 연결된다. 변형이 만드는 포트에 대한 자세한 내용은 Collaboration role::type
부분을 참조하라.
|
|---|
| Collaboration role | 이것은 컴포넌트에 대한 UML 포트를 만든다. 생성된 포트는 소스 모델의 역할과 같은 이름을 갖고 있다. 각 포트는 협업 사용 관계를 사용함으로써 역할로 연결된다.
|
|---|
| Collaboration role::type |
role::type 프로퍼티가 협업 엘리먼트에 의해 실행되는 같은 인터페이스를 설정한다면, role::type 프로퍼티는 포트에 의해 제공되는 인터페이스로 설정된다.이 포트 유형 역시 그 인터페이스로 설정된다.
다른 모든 role::type 프로퍼티는 필수 인터페이스로 설정된다. 변형을 통해 포트 유형은, 소스 모델에 의해 정의된 인터페이스에 사용 관계를 갖고 있는 UML 클래스로 설정된다. 사용 관계 속의 UML 클래스 이름은 소스 모델의 인터페이스 이름과 같지만, Protocol이라는 접미사가 붙는다.
|
|---|
프로세스 분해 선택하기
Business Process에서 Service Model 변형은 스팩 모델에서 비즈니스 프로세스를 변형할 수 있는 확장을 제공한다.
Default Implementation 분해는 UML Component에 의해 표현된 것처럼, UML Activity를 비즈니스 프로세스의 작동으로서 할당함으로써 프로세스의 작동을 설명하고 있다. 이러한 분해는 나중에 UML-SOA 변형에 의해 사용되어 Services Component Definition Language (SCDL) 모듈과 Business Process Execution Language (BPEL) 생성물을 만들 수 있다.
그림 8. 변형 설정을 사용하여 각 비즈니스 프로세스에 대한 분해 유형 설정하기
그림 9에 나타난 것처럼, 기본 Implementation 확장으로 분해가 이루어지는데, 이를 통해서 작동은 비즈니스 분석 모델에서 복제된 Activity 엘리먼트에 의해 기술된다.
그림 9. Implementation 기본 확장
주:
Do Not Transform 옵션은 변형을 원치 않는 특정 프로세스가 있을 경우에 제공된다. 이러한 확장은 "Ignore this process(이 프로세스를 무시할 것)"를 의미한다.
Skeleton Only 구현은 작동을 구조로 변형하면서, Services Component Definition Language를 분해한다. (그림 9) 역할에 대한 각 액터(또는 다른 서비스)에 호출하기 전에 어떤 사전 프로세싱(예를 들어, 프록시 획득하기)을 수행하기 위해 각 Collaboration 역할에 대한 내부 컴포넌트를 만들어 낸다. 이와 같은 모델은 UML-SOA 변형에 의해 사용되어 아웃풋을 만들어 내는데, 이것은 IBM® WebSphere® Integration Developer로 전개될 수 있다.
그림 10. Skeleton Only 확장을 통해 생성된 SCDL 분해
다른 영역에 대한 구현 상세를 포함하고 있는 UML 서비스 모델을 만들려면, 클라이언트는 Business -Service Model 변형에 대한 커스텀 확장을 생성 및 등록할 수 있다.
분해 커스터마이징에 대한 예제는 본 시리즈의 다음 기술자료 "SOA로 변형하기: Part 2. IBM Rational Software Architect의 Business Process- Service Model 변형 기능을 위한 커스텀 확장 생성하기"에서 설명하도록 하겠다. (시리즈 보기).
Part 2 예고
이 글에서는 WebSphere Business Modeler 생성물을 Rational Software Architect 환경에 통합하는 것과, 비즈니스 모델과 소프트웨어 분석 및 디자인 모델 간 다리를 만드는데 필요한 툴링을 소개했다. Part 2에서는 비즈니스 프로세스를 서비스 모델로 변형하는 커스텀 프로세스 분해 방법을 예제를 통해 단계별로 설명하겠다. 변형 확장을 작성할 수 있는 독자들을 겨냥한 글이다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | | | Nicholas는 IBM Rational 소프트웨어 툴을 지원하는 소프트웨어 엔지니어이다. |
| | | Natalia는 IBM Rational 소프트웨어 툴을 지원하는 소프트웨어 엔지니어이다. |
기사에 대한 평가
| |
