서비스 지향 아키텍처의 엔지니어링 패러다임 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 토론 영어원문  제안 및 의견 피드백

난이도 : 초급

James Densmore, Certified IT Specialist and Western Regional Practice Lead for Solutions Architecture, IBM
Tim Bohn, Certified IT Specialist and Worldwide Community of Practice Leader for Solutions Architecture, IBM

2007 년 7 월 18 일

IBM Rational Unified Process (RUP) 프레임웍과 Model Driven Systems Development (MDSD)을 결합하여 서비스 지향 아키텍처(SOA) 컴포넌트를 개발할 때 위험 부담을 줄이는 방법을 설명합니다. 또한 SOA 개발과 관련된 몇 가지 오류에 대해서도 설명합니다.

로부터 The Rational Edge.

서비스 지향 아키텍처(SOA)가 소프트웨어 개발에 중요한 위치를 차지하게 되면서, 점점 더 많은 IBM® Rational® 고객들은 서비스 지향 솔루션을 개발 및 활용하게 되었다. 하지만, SOA를 설계 및 개발하는데 따른 문제와 위험 요소들도 있기 마련이다. 한 가지 예가 재사용 가능한 컴포넌트를 구현하는 문제이다. 개발자들은 애플리케이션의 요구 사항들을 넘어 이러한 서비스들이 미래 또는 현재의 비즈니스 프로세스에 어떻게 재사용 될 수 있는지도 생각해야 한다. 마찬가지로, 여러 비즈니스 프로세스에 의해 서비스들이 사용 될 때, 높은 품질과 강력한 성능에 대한 요구 사항은 기존 애플리케이션 보다 더 많아질 수 있다. 보안이나 순응성 요구 사항들을 위반하는 서비스는 심각한 비즈니스 위험을 불러일으킬 수 있다.

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

SOA가 약속하는 것

복잡성과 변화 속도는 소프트웨어 개발뿐만 아니라, 우리 삶 전반에 걸쳐 점점 증가하고 있다. 개발 팀들은 품질에 대한 요구 사항을 맞추면서, 복잡한 솔루션들을 더욱 빠르게 제공해야 한다. 전통적인 접근 방식으로는 속도를 맞추지 못하고 많은 상황에서 실패를 거듭한다면 소프트웨어 개발 팀들은 방식을 바꾸어야 한다. 몇 가지 예를 들어보겠다.

동기

미국 9/11테러를 다룬 뉴스 기사를 보면 정보 수집에 있어서 미국 정보 커뮤니티가 얼마나 무능력했는지를 비난하는 것을 볼 수 있다. 비행기로 자주 여행을 다니는 사람들은 항공사가 출발 직전 15분 미만의 비행기 지연에 관한 정보를 제공해 주지 않는다는 것을 안다. (여러분이 기다리고 있는 비행기는 출발지 공항을 떠나지도 않았다.) 자동차의 라디오를 제거해서 차를 출발시킬 수 없다는 이유로 발생했던 2002년 자동차 리콜을 기억하는가? 공군, 육군, 해군이 공용 라디오 통신 기능을 갖고 있지 않았기 때문에 전산을 통해 제공되어야 하는 매일의 군사 명령을 플로피 디스크를 통해 해군 함정으로 보내야 했던 Operation Desert Storm 상황에 대해서는 어떻게 생각하는가? 미 육군이 22,000 개 이상의 지휘 본부를 갖고 있고, 매년 증가했다는 것을 알고 있었는가? 이 세 개의 다른 팀들이 다른 위성의 위치를 추적하는 데이터베이스를 만들었던 위성 프로그램에 대해 들어보았는가? 더욱이, 일단 이들이 프로그램의 다른 부분에 있는 다른 요소들에 대응하기 때문에 세 개의 데이터베이스를 통합하기에는 가격이 너무 비싸다.

어떻게 이러한 일이 발생하는가? 비즈니스, 정부, 군사 환경에서 점점 늘어만 가는 복잡성을 어떻게 관리할 수 있을까? IBM Rational은 대형 시스템 개발 프로그램의 복잡성을 관리하는데 사용할 수 있는 현대적인 모델 중심의 시스템을 선보이고 있다.

더 나은 접근 방식

SOA는 이러한 종류의 문제를 해결할 수 있다는 비전을 제시한다. SOA는 협업 정의를 통해서 다양한 서비스들의 통합을 지원하면서, 엔터프라이즈의 많은 영역들에서 가져온 복합 애플리케이션들을 구현하여 목표를 달성한다. 앞서 인용했던 위성 위치 데이터베이스 예제에서, SOA 사용자들은 이러한 서비스를 필요로 하는 기업 내 누구나 잘 알려진 인터페이스를 통해 사용할 수 있는 필수 기능을 만드는 것이 중요하다고 역설하고 있다.

하지만, SOA를 초기에 채택했던 사람들은 SOA 스타일을 고수한 협업 엘리먼트들을 개발하는 많은 팀들에 부정적인 영향을 주었던 많은 문제들을 직면했다. 대표적인 다음 문제들이다.

• 일관성이 없다. 컴포넌트가 상호 운용하는 방식에 대한 모호함과 오해가 생긴다.
• 기능이 분해된다. 이는 아키텍처를 쓸모 없게 만든다.
• 다르고 일관성 없는 애플리케이션 개발 프로세스 때문에 엔지니어링 팀들간 효율성과 협업 기능이 떨어진다.
• 개발 과정을 안전하게 이끌어갈 고급 패턴과 제약 조건에 집중하기 보다는 디자인에만 초점을 맞추게 된다.

Model Driven Systems Development (MDSD)는 SOA 아키텍처에 순응하는 엔터프라이즈 개발 팀들을 도울 이상적인 방식을 제공한다. 효율적이고 반응적인 엔지니어링 결과를 만들어내는 기능에 영향을 주는 문제들을 줄인다. 필자가 제안하는 MDSD 애플리케이션은 본질적으로 분열성을 띤다. 다시 말해서, 동일한 장치로 때 단위 및 소 단위 SOA의 발견을 지원한다. 기본적으로, 이러한 접근 방식은 유연한 엔터티로서 엔터프라이즈 IT 인프라스트럭처를 관리하는데 필요한 확장성 있는 협업 패턴들에 초점을 맞춘다. 고객과 서비스 품질 요구 사항이라는 두 가지의 필요에 대한 반응이다.

MDSD Flowdown 개요

엔터프라이즈 IT 환경을 SOA 아키텍처 스타일로 바꿀 때 직면하는 첫 번째 문제는 엔터프라이즈가 소프트웨어에 관한 것만은 아니라는 것이다. 비즈니스 목표는 많은 참여자들간 협업을 통해 이룩되고, 여기에는 사람(사용자), 정보, 하드웨어, 여러 종류의 소프트웨어가 포함된다.

MDSD는 분열성을 띄고 있기때문에, 그 개념을 적용해 보도록 하자. 엔터프라이즈가 일종의 시스템이라고 생각할 수 있을까? Blanchard와 Fabrycky는 시스템을 다음과 같이 정의하고 있다.

시스템은 상호 작동하는 엘리먼트, 상호 연관된 엘리먼트, 또는 상호 의존적인 엘리먼트들이 복잡한 전체를 구성한 것이다. 하나의 시스템은 엔터프라이즈에 의해 사용되는 서비스를 제공하여 비즈니스 목적(임무)를 수행한다. 시스템 컴포넌트는 하드웨어, 소프트웨어, 데이터, 사용자(worker)로 구성된다. ¹

이것은 전형적인 비즈니스 엔터프라이즈에 대한 정의이다. 엔터프라이즈는 일종의 시스템이고, 이와 같은 방식으로 분석할 수 있다. 필자는 이러한 관점에서 출발하여 엔터프라이즈를 구성하는 컴포넌트 시스템을 분석할 것이다.

시스템 콘텍스트 이해하기

MDSD를 사용하는 시스템 -- 엔터프라이즈의 분석은, 시스템이 협업하는 UML/SysML 액터(actor)/역할(role)을 정의하거나 시스템의 비즈니스 목표를 UML/SysML 유스 케이스로서 정의함으로써 시스템 정황을 정확하게 이해하는 것으로 시작된다.

그림 1: 리테일 시스템의 정황 다이어그램

Context 다이어그램에 나타난 액터와 역할에 기반하여, 같은 시스템의 Use Case 다이어그램을 만들 수 있다. (그림 2)

그림 2: 그림 1의 같은 리테일 시스템의 Use Case 다이어그램

Black box(Black box)

다음 단계는 시스템이 참여하는 각 유스 케이스용 시나리오를 문서화 함으로써 유스 케이스를 분석하는 단계이다. 우리가 기존 시스템이나 엔터프라이즈를 향상하고 있다면, 이러한 시나리오가 무엇인지를 알고 있어야 한다. 이 단계에서, 우리가 분석중인 시스템의 유스 케이스의 상세로 들어가지 않도록 조심해야 한다. "Black box" 레벨에 머물러야 한다. 시스템의 액터가 요청하는 것을 문서화 하고, 시스템에서 협업할 다양한 액터들도 문서화 해야 한다. 복잡한 시스템에서, 많은 시나리오들이 있을 것이다. 우리는 일반적으로 UML/SysML 시퀀스 다이어그램을 사용하여 각 시나리오를 묘사한다. (그림 3)

그림 3: Black box 시퀀스 다이어그램

전형적인 UML 또는 SysML 모델링 애플리케이션을 사용하여 이러한 분석을 수행한다면, 다양한 Sequence 다이어그램에서 시스템에 대한 연산을 찾고, 이 툴은 그러한 연산을 기록하고, 다른 Sequence 다이어그램에서 이들을 재사용할 수 있다. 근본적으로 인간의 노력을 요하는 이 같은 분석에서, 모호함과 중복이 있을 것이다. 따라서 연산 세트에서 중복을 이해하고, 재정의하고 제거하는 리팩토링 단계가 중요하다. 결과는 그림 4처럼 보인다.

그림4: 시스템 클래스/블록에 대한 연산이 묘사되는 Context 다이어그램

Joint flowdown

다음의 주요 MDSD 단계는 위에 설명했던 각 연산에 대해 Joint flowdown을 수행하는 것이다. Joint flowdown 단계는 MDSD의 올바른 사용에 있어서 중요하다. 여러 중요한 관점에서 초기 시스템 디컴포지션에 대한 이론화를 수행한다는 점에서 혁신적이다. (비록, 개별 관점을 먼저 고려하는 것이 중요하다.)

필자는 이러한 관점을 뷰포인트(viewpoints)라고 한다. 이 용어는 IEEE 1471 정의에서 나온 용어이다. ² 각각의 뷰포인트는 개별적인 엔지니어링 컨선을 다룬다. 예를 들어, 논리적 뷰포인트는 기능, 확장성, 관리성, 커플링, cohesion, 관련 컨선들의 완벽성을 다룬다. 분산 뷰포인트는 시스템의 물리적 특성과 리소스들이 이러한 기능을 수용하기에 알맞는지, 서비스 품질 목표를 달성하는데 알맞는지를 다룬다. 다른 뷰포인트도 정의될 수 있고 필요한 대로 사용된다.

Joint flowdown에서, 각 시스템 연산은 원자 요청으로서 취급되고 시스템 내에서 엘리먼트의 협업이 요청을 수행하기 위해 어떻게 구성되는지를 분석하게 된다. 협업은 순서가 정해진 메시지 세트로서 나타나거나 시스템 내의 이러한 엘리먼트에 대해 연산 호출로서 나타난다. 시스템은 순수한 소프트웨어일 필요는 없지만, 좋은 객체 지향 소프트웨어 디자인의 장점은 이러한 목적을 위해 협업해야 하는 엘리먼트들을 결정할 때 매우 유용하다는 점이다. 시스템이 이미 존재하고 있고 분석하는 이유가 향상을 목적으로 한다면, 기존 시스템이 달성하지 못한 새로운 목표를 달성하기 위해 수정 또는 개발이 필요하다. 결과는 그림 5와 같은 논리적 White box(white box) 시나리오이다.

그림 5: 논리적 White box 시나리오 Sequence 다이어그램
크게보기

다중 뷰포인트로의 Flowdown

Joint flowdown 단계의 다음 단계는 왜 "Flowdown"이라고 불리게 되었는지를 명확히 알 수 있는 단계이다. 논리적 White box 시나리오를 만들었던 연산을 통해, 순서로 되어 있는 메시지 세트가 생겼다. 이 세트에 추가 분석을 수행하여 각 연산 호출을 호스트하거나 수신해야 하는 시스템 내의 리소스 엘리먼트를 결정한다. 각각의 리소스 엘리먼트는 로컬리티의 인스턴스이다. 이러한 방식으로 찾은 로컬리티는 시스템 품질과 분산 요구를 고려하면서 이루어진 디자인 결정을 나타낸다.

그림 6: 리테일 시스템용 분산 White box 시나리오 Sequence 다이어그램
크게보기

이러한 특정 시나리오에 대한 Joint flowdown은 그들이 나타내는 영역에 비중을 두는 것이 적절해 지면서 추가 뷰포인트를 고려함으로써 지속된다. 각 뷰포인트와 관련된 엘리먼트들 간 협업을 나타내는 White box 시퀀스 다이어그램은 같은 메시지 세트를 사용하여 개발된다. 그림 7은 Organizational Viewpoint 모습이다. 각 뷰포인트는 같은 시나리오를 다루어야 하지만 다른 영역들이 평가되고 있다.

그림 7: White box 시나리오 시퀀스 다이어그램 예제

마지막으로, Joint Realization Table (JRT)이 이 시나리오를 위해 작성되면서, 테이블의 칼럼에 각 뷰포인트용 협업 엘리먼트들을 보여준다. 행이 이 시나리오의 이 단계와 관련이 있다. SOA 정황에서 서비스 품질 요구 사항(quality of service requirements)이라고 하는 비 기능적 요구 사항이 지정된다. 우리는 이 시나리오 전체적인 서비스 품질 요구 사항을 지정하고 이를 인풋으로 취한다.

JRT가 지정한 협업 과정에서, 협업의각 연산에 대한 서비스 품질 요구 사항은 파생을 나타낸다. 이것은 그러한 연산 호출(메시지)가 할당되었던, 주로 로컬리티의 인스턴스인 엘리먼트에 대한 서비스 품질 요구 사항을 내포하고 있다. 예를 들어, 로컬리티에 대한 주어진 연산 호출은 많은 시나리오에서 여러 번 발생한다. 이것은 각 로컬리티가 만족시켜야 하는 서비스 품질 요구 사항들이다. 표 1은 JRT 예제이다.

Joint Realization의 정적 구성

MDSD Joint flowdown의 작동 층면과 관련된 단계로 끝을 맺지만, 추가적인 아키텍처 분석 단계가 있다. UML/SysML 인터페이스는 각각의 뷰포인트에서 협업하는 엘리먼트에 의해 실현된 다양한 연산 세트들을 구성한다. (그림 8)

그림 8: 리테일 예제를 위한 Joint Realization 정적 구조(인터페이스 실현)

SOA 개념과 MDSD의 관계

이제는 앞서 설명했던 MDSD 개념들이 SOA와 어떻게 관련되는지를 설명하겠다. 이 둘 사이의 관계가 좋다면, MDSD를 활용하여 서비스 지향 아키텍처 스타일에 순응하는 고급의 효율적인 시스템을 만들 수 있을 것이다.

정의와 분석

"서비스 지향 아키텍처"라는 문구부터 분석해 보자. 여기에 대한 많은 정의들이 있다. 그 중에서도 필자는 Hao He 박사의 정의를 지지한다.

SOA는 상호 작동하는 소프트웨어 에이전트들 간 약결합을 달성하는 것을 목표로 하고 있는 아키텍처 스타일이다. ³

출발이 좋다. 앞서의 MDSD에 대한 논의에서, 필자는 뷰포인트들 중에-실제로, 완전한 기능에 대한 필요 때문에 가장 먼저 고려해야 할 부분임-논리적 뷰포인트가 있다고 언급한 바 있다. 논리적 뷰포인트는 많은 다른 관련 요소들이 다루어지는 장소이기도 하다. 확장성, 관리성, 좋은 결합력, 약결합 등이 다루어진다. 확실히, 이러한 개념들은 비슷하다.

SOA에 대한 보다 정확한 정의는 -- IBM Redbooks ⁴ 과 기타 자료들 ⁵ -- 의 개념들을 결합한 것이다.

SOA는 아키텍처 스타일로서, 협업하고 있는 에이전트들의 컬렉션으로서 실현되고, 각각은 서비스라고 불리며, 이들의 목표는 복잡성을 관리하고, 약결합, 위치 투명성, 프로토콜 독립성 같은 개념을 통해 아키텍처 탄력성과 강력함을 실현하는 것이다.

"서비스"라는 단어는 신중하게 정의하지 않은채 사용되므로 다음에 이를 정의해야 한다. 서비스라는 단어에는 많은 뜻이 내포되어 있다. 어떤 참고자료에서 찾은 기능적 정의는, "에이전트" 또는 "엔터티" 같은 개념을 사용하여, 서비스들은 고유의 상태를 관리하는 객체에 의해 실현되고 객체 지향 프로그래밍과 관련된 일반 용어로 구분될 수 있다고 명시하고 있다.

Hao는 다음과 같이 정의를 내린다.

서비스는 디스크립션이 있는 엔터티이며, 서비스 사용자가 호출할 때 사용할 수 있는 공식 인터페이스를 통해 사용할 수 있는 엔터티이다.

서비스는 일반적으로 대단위의, 발견 가능한 소프트웨어 엔터티 [my emphasis] 에 의해 구현되고 단일 인스턴스로서 존재하고, 약결합 된, 메시지 기반 통신 모델을 통해 애플리케이션과 다른 서비스들과 상호 작동한다.

마지막으로, UML 스팩에서는 서비스가 가진 프로퍼티들을 열거하고 있다. ⁶ :

• 서비스에 대한 인터페이스 콘트랙트는 플랫폼 독립적이다.
• 서비스는 동적으로 배치 및 호출될 수 있다.
• 서비스는 독립적이다. 서비스는 고유의 상태를 관리한다.

따라서, 필자는 다음과 같이 서비스에 대한 정의를 내리게 되었다.

서비스는 독립 엔터티로서, 엔터페이스 세트를 만들어야 하며, 동적으로 배치될 수 있고 메시지를 사용하여 온 디맨드 방식으로 호출될 수 있다.

Philippe Kruchten ⁷ 에 따르면, 서비스에 알맞는 적절한 UML /SysML 구조는 포트(Port)이다. UML 포트는 전적으로 이러한 정의에 일치한다.

서비스는 서비스 공급자에 의해서 서비스의 구현 또는 실현을 제공한다. 서비스 공급자는 서비스의 실행을 위한 리소스를 갖고 있다. 따라서, 정의에 이해서 이것은 로컬리티이다. 로컬리티는 보다 일반적인 개념이지만, 모든 서비스 공급자들을 로컬리티로서 생각할 수 있다.

서비스 스팩

서비스 설명 중에 유사성은 무엇인가? UML /SysML에서, 일련의 연산들의 디스크립션을 인터페이스라고 한다. SOA에서, 이러한 개념을 서비스 스팩(service specification)이라고 한다. 하지만, 서비스 스팩은 서비스 품질 요구 사항과 실현된 연산의 스팩을 포함하고 있다. 따라서, 서비스 스팩은 일종의 인터페이스이기 때문에 서비스 품질 정보를 추가한다. 우리는 인터페이스와 제약 조건을 사용하여 서비스 스팩을 모델링 할 수 있다.

힘들게 노력하지 않아도, 이러한 개념들을 계속해서 조정해 가면서 뚜렷한 유사성을 찾게 되었다. 표 2는 MDSD와 SOA 간 매핑에 몇 가지 개념을 추가한다.

MDSD의 역사를 잘 알고 있는 독자의 경우, 이 테이블에서 우리는 "서비스"에 대한 역사적인 Rational Unified Process for Systems Engineering (RUP-SE®) 정의는 생략했다. 여기에서는 SOA에서의 서비스에만 초점을 맞추었다.

맺음말

MDSD는 SOA 아키텍처를 개발하는데 탁월한 방식을 제공하여, 기능적 요구 사항만큼 강력하게 요구되는 서비스 품질 요구 사항에 대해 탄력성 있는 결과를 만들어 내고 있다. 따라서, 이것이 가진 본연의 확장성은 다른 분석 방식 보다 월등하다. MDSD에 대한 상세한 설명은 참조 리스트의 5, 15, 16, 17을 참조하기 바란다.

MDSD는 가치의 결과를 설명하는 유스 케이스 같은 액터와 미션으로서 정황을 구축하는 것으로 시작한다. 시스템이 구현해야 하는 Black box 연산을 찾고, 이들을 실현할 시나리오를 찾고, 적절한 서비스 스팩에 갖도록 지정된 Black box 연산들의 기능을 실현하기 위해 협업하는 여러 뷰포인트를 포함시킨다. 로컬리티를 찾게 되면, 각각의 프로퍼티를 분석하여 이것이 서비스 프로바이더가 될 수 있는지를 결정한다. SysML 인터페이스로 스팩의 기능적 측면과, 제약 조건들이 첨부된 joint realization 테이블에서 파생된 서비스 품질 측면으로, 이미 서비스 스팩이 개발되었다.

이것은 매우 단순한 것처럼 보이지만, 다음 단계는 같은 방식으로 이렇게 찾아낸 서비스 공급자들을 분석하는 것이다. 결국, 각각은 시스템과 MDSD는 앞서 언급했던 것처럼 이러한 관점에서 분열성을 띠고 있다. 간단하게 구현할 수 있는 서비스 공급자를 찾으면 알맞은 기술을 사용하여 이들을 구현한다. 그 기술에 웹 지향 소프트웨어가 포함되어 있다면 실현 메커니즘은 IBM Websphere® Application Server 같은 애플리케이션 서버가 될 것이다.

참조

1. "Intelligence 'Failures' and the Blame Game," War Watch, Orson Scott Card, (http://www.ornery.org/essays/warwatch/2002-12-16-1.html)
2. "Computer Woes Continue to Plague Airlines," USA Today online, Harry Weber AP, (http://www.usatoday.com/tech/news/2004-12-28-flying-bugs_x.htm)
3. Air Force Command Structure -- Federation of American Scientists, fas.org (http://www.fas.org/main/content.jsp?formAction=297&contentId=220)
4. Systems Engineering and Analysis (3^rd ed.), B.S. Blanchard and W.J. Fabrycky, Prentice Hall, 1998.
5. Model-driven systems development, IBM Systems Journal Vol. 45, No. 3, 2006, Balmelli, Brown, Cantor, Mott. http://www.research.ibm.com/journal/sj/453/balmelli.html
6. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000, Institute for Electrical and Electronic Engineers (2004). http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html
7. Patterns: Service-Oriented Architecture and Web Services, an IBM Redbook; Endrel et al, Apr-2004. http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf
8. What is Service-Oriented Architecture?, Hao He, Sep-2003. http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
9. Service-oriented architecture (SOA) definition; Barry & Associates, 2004: http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html, or more generally http://www.service-architecture.com/
10. Service-Oriented Architecture Explained; Sayed Hashimi, Aug-2003: http://www.ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html
11. Unified Modeling Language: Superstructure, Version 2.0, Final Adopted Specification, ptc/03-08-02, Aug-2003; Object Management Group. www.omg.org, www.uml.org
12. OMG Systems Modeling Language (OMG SysML) Final Adopted Specification, Version 1.0, ptc/06-05-04, May-2006; Object Management Group: www.omg.org, www.omgsysml.org
13. Modeling service-oriented solutions; Simon Johnston, The Rational Edge, July 2005: http://www.ibm.com/developerworks/rational/library/jul05/johnston/index.html
14. The Rational Unified Process: An Introduction, Third Edition; Philippe Kruchten, Addison-Wesley, 2003.
15. The Rational Unified Process for Systems Engineering, Part I: Introducing RUP SE 2.0, Murray Cantor, The Rational Edge, August 2003: http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf
16. The Rational Unified Process for Systems Engineering, Part II: System Architecture, Murray Cantor, The Rational Edge, September 2003: http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/sep03/m_systemarch_mc.pdf
17. The Rational Unified Process for Systems Engineering, Part III: Requirements Analysis and Design, Murray Cantor, The Rational Edge, October 2003: http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/oct03/m_rupse_mc.pdf

주

¹ Systems Engineering and Analysis (3^rd ed.), B.S. Blanchard and W.J. Fabrycky, Prentice Hall, 1998.

² IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000, Institute for Electrical and Electronic Engineers (2004), http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html

³ What is Service-Oriented Architecture?, Hao He, Sep-2003; http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

⁴ Patterns: Service-Oriented Architecture and Web Services, an IBM Redbook; Endrel et al, Apr-2004; http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf

⁵ One I recommend is Service-Oriented Architecture Explained; Sayed Hashimi, Aug-2003; http://www.ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html

⁶ Unified Modeling Language: Superstructure, Version 2.0, Final Adopted Specification, ptc/03-08-02, Aug-2003; Object Management Group: www.omg.org, www.uml.org

⁷ The Rational Unified Process: An Introduction, Third Edition; Philippe Kruchten, Addison-Wesley, 2003.

필자소개

		Jim Densmore는 IBM Rational Solutions Architecture의 지역 리더이다. 조직 변형과 복잡한 시스템의 엔지니어링 분야에서 클라이언트를 대응하고 있다. 2000년 영업 팀의 기술 대표로서 Rational에 입사하기 전에 아키텍처, 디자인, 개발, 실시간 전투 시뮬레이션, 실시간 통신 소프트웨어에 20년 동안 경력을 쌓아왔다. UCLA에서 학사 학위를 메릴랜드 대학에서 컴퓨터 공학 석사 학위를 받았다.

		Tim Bohn은 IBM 시스템 및 소프트웨어 개발 프로세스 커뮤니티의 리더이다. 시스템 및 소프트웨어 엔지니어링 솔루션과 개발 프로세스 전략에 대해 클라이언트를 대상으로 컨설팅을 하고 있으며, Rational Unified Process, Requirements Development, Analysis 전문가이다. 실시간 임베디드 애플리케이션, 상용 애플리케이션, 프로젝트 관리 및 구현 등 소프트웨어 개발 분야에서 28년의 경력을 쌓아왔다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로