머리말

재사용 가능한 자산, 레시피, 패턴들을 소개하고자 한다. 자산들은 문제에 대한 솔루션을 제공하는 생성물들의 집합이다. Reusable Asset Specification (RAS)을 참조하라.(참고자료)

소프트웨어 패턴은 문제에 대한 반복적인 솔루션이다. Rational® Software Architect는 소프트웨어 패턴에 대해 모델 중심 개발(MDD) 방식을 취한다. MDD는 전형적으로 한 레벨의 추상화에서 또 다른 레벨로 변형을 허용한다. 변형의 예제는 분석 모델부터 디자인 모델이 될 수 있고 디자인 모델에서 코드가 될 수 있다.

다중 Rational Software Architect 패턴들과 모델이나 요구 사항 같은 기타 자산들은 서로 조직되어 대단위 솔루션을 형성한다. 레시피는 프로세스 가이드, 구성 요소들의 콘텍스트와 디스크립션, 자산과 패턴들을 제공한다.

레시피, Rational Software Architect 패턴과 변형, 기타 자산들은 RAS를 사용하여 패키징 되고 자산이나 RAS 리파지토리에 저장된다. RAS 리파지토리는 개발용 자산 리파지토리이고 특정 솔루션의 자산과 엘리먼트를 발견하는 메커니즘을 제공한다. 우리는 SOA 솔루션에 초점을 맞추겠지만 이 개념도 널리 사용될 수 있다.

패턴 레시피는 사용, 조직, 구체화된 패턴들의 상호 연결에 대한 문서를 제공한다. 레시피는 구현에 필요한 패턴과 자산을 사용하는 법에 대한 가이드를 제시한다. 레시피는 한 패턴의 아웃풋을 또 다른 패턴의 인풋과 조화시킨다. 레시피는 한 개 이상의 패턴들을 대체할 수 있다. 콘텍스트는 시간이 지나면서 변하기 때문에 이는 매우 유용하다.

SOA Implementation and Optimization Recipe는 Rational Software Architect 패턴과 변형의 컬렉션이자, SOA 솔루션을 제공하는 가이드이다. 이 레시피에서 논의하는 패턴들은 UML 모델들을 조작하여 서비스를 만들과 최적화한다. Rational Software Architect 패턴들은 Rational Software Architect Pattern Engine을 사용하여 구현된다. 각 Rational Software Architect 패턴과 변형은 Eclipse 플러그인으로서 구현되고 Rational Software Architect 패턴 작성 및 변형 API를 사용한다.

재사용 가능한 자산

수년 전에, IBM, Rational Software (IBM에 이수되기 전), Microsoft가 포함된 소프트웨어 산업 선두 업체들의 컨소시엄이 소프트웨어 투자를 도모할 방법을 모색하기 시작했다. 그 당시에 이 컨소시엄은 자산을 다음과 같이 정의했다. 주어진 정황에서 문제에 대한 솔루션을 제공하는 생성물들의 컬렉션.

자산은 다른 특성들도 갖고 있다. 사용자들이 다양한 매개변수들을 설정함으로서 자산을 커스터마이징 할 수 있는 변이 포인트들을 갖고 있다. 이러한 방식으로 취급될 수 있는 자산을 템플릿이라고 한다. 오늘날 IBM Rational 툴링은 이러한 정의를 염두해 두고 구현된다.

자산에는 사용법에 대한 지침과 규칙이 포함된다. 개발자가 자산을 발견, 분석, 소비, 테스트하는데 드는 시간을 최소화 하기 위해서이다. 자산이 재사용 될 수 있는 개발 및 비즈니스 정황도 설명된다.

자산이 포함하고 있는 생성물들의 종류는 재사용 정황에 의존한다. 개발 정황에서 자산에는 요구 사항, 모델, 소스 코드, 테스트가 포함된다. 서비스를 구현하는 사람들에는 이러한 유형의 생성물들이 포함되어 다른 개발자들도 이 서비스를 효율적으로 사용할 수 있도록 한다.

자산의 정의는 패턴의 그것과 매우 비슷하다. 이것은 디자인에 의한 것이다. 패턴과 자산 뒤에 숨은 근본적인 개념들은 콘텍스트, 문제, 솔루션을 한데 모은다. 세세한 차이점들이 있다. 자산은 패턴보다 일반적인 개념이다. 자산의 변이 포인트들은 생성물 레벨에 있는 반면, 패턴은 매개변수와 참여자들을 갖고 있다. 이것은 일종의 변이 포인트로서, 특정 생성물이 아닌 전체 패턴에 적용된다.

위로

RAS 소개

자산을 어떻게 조직하고 구성할 수 있을까? 이것에 대해 알려면 어떤 정보가 필요한가? Reusable Asset Specification (RAS)는 이러한 질문에 대한 답을 줄 수 있는 구조를 제공한다. 이것은 2005년 채택된 Object Management Group (OMG) 표준이다.

많은 유형의 소프트웨어 개발 생성물들이 있고 이들은 다양한 형태로 존재하고 다양한 스타일을 반영한다. 이러한 다양성은 다른 작성자의 생성물들을 발견, 이해, 재사용하는 비용을 늘릴 수 있다. 이러한 생성물들을 구성, 기술, 패키징 하는 방식을 지정함으로서 RAS는 자산들간 일관성과 예견 가능성을 보장한다. 이는 자산 관리 및 소비 비용을 줄일 수 있는 요소이다.

자산 패키징을 표준화 하는 것의 가치를 설명하기 위해 표준화가 야간 선적 회사를 어떻게 돕는지에 대해 생각해 보자. 표준 봉투와 박스를 고객에게 제공하고 선적 레이블에 일관된 정보를 요구하여, 이 회사는 고급의 트래킹 시스템을 구현할 수 있었다. 게다가 이러한 정책들은 전사적으로 더 나은 플래닝과 의사 결정을 도모했다. 컨베이어 벨트의 넓이를 결정하는 것부터 비행기에 맞는 패키지를 결정하는 것 까지 플래닝에 들어갔다.

자산 표준화가 효율성을 증대화 하면서, 소프트웨어 개발 툴에 효율성과 자동화를 가능케 하고 이를 사용하는 팀의 생산성을 높이게 된다. RAS를 사용하면 개발자들은 각 자산을 메타-데이터 래퍼로 패키징 할 수 있다. 자산의 이름, 버전, 디스크립션 같은 탑 레벨 애트리뷰트를 여기에 포함시켜서 말이다.(그림 1)

그림 1에서 보듯, RAS 자산은 검색과 브라우징을 용이하게 하는 구분 섹션을 갖고 있다. 이 섹션에는 간단한 이름/값 쌍 디스크립터와 특정 도메인, 개발, 전개 콘텍스트 같은 정황의 선언이 포함된다.

그림 1의 솔루션 섹션은 자산의 "핵심"이다. 솔루션을 제공하는 생성물들의 컬렉션을 기술하고 있다.

사용법 섹션은 자산을 적용 및 커스터마이징 하는 것에 대한 가이드를 제공하면서 변이 포인트들을 사용하고 있다. 몇몇 사용법 정보는 스크립트와 마법사를 사용하여 자동화되는데, 이는 다른 자산 생성물들과 함께 솔루션 섹션에 저장된다.

관련 자산 섹션들은 다른 자산들과의 관계를 정의하고 대단위 솔루션을 형성하는 자산들의 컬렉션을 만드는데 도움이 된다.

조직에서 재사용, 형식, 프로세스 성숙도를 다양화 하기 위해 많은 RAS 자산들은 선택적이다. RAS는 프로파일을 통해 확장 및 개인화 될 수 있다. OMG는 현재 세 개의 프로파일을 제공한다. Default 프로파일, Default Component 프로파일, Default Web Service 프로파일이 바로 그것이다.

디폴트 프로파일은 모든 종류의 소프트웨어 자산을 패키징 하는데 사용되고, 다른 두 개의 프로파일들은 각각 컴포넌트와 웹 서비스와 함께 사용될 것이다.

위로

패턴 소개

"패턴"이라는 용어는 다양한 반응과 정의를 만들 수 있다. 평범한 관찰자는 이것이 적용되고 있는 현장에 있으면서도 패턴이 사용되고 있다는 것을 눈치채지 못한다. 반면, 관찰자는 적용된 패턴의 혜택을 누리게 된다. 패턴을 적용하는 이유와 목적을 깨닫지 못하지만 패턴의 이론, 지식, 효용은 없어지고 궁극적으로 잊혀져서 사용되지 않는다. 간단히 말해서 추상화는 적이 될 수도 있고 친구가 될 수도 있다.

정의

패턴이란 무엇인가? 선각자들이 이미 수행한 좋은 예를 차용해보겠다.

James Coplien은 패턴을 다음과 같이 정의한다. "한 정황에서 문제를 해결하는 되풀이 되는 구조적 구성으로서 감각적이거나 문화적 가치를 반영하는 시스템에 기여한다."[Organizational Patterns, p. 4, Pearson Prentice Hall]

Christopher Alexander는 다음과 같이 정의한다. "각 패턴은 한 환경에서 반복적으로 발생하는 문제를 기술하고 그 문제에 대한 핵심 솔루션을 기술한다."[Alexander, 1979]. 또한 "각 패턴들은 세 부분으로 나뉜 규칙이다. 각각은 특정 정황, 문제, 솔루션간 관계를 나타낸다."[Alexander 1979, p. 274]

Booch의 정의는 다음과 같다. "패턴은 어떤 정황 속에서 공통적인 문제에 대한 좋은 솔루션을 제공한다."[The Unified Modeling Language User Guide, p. 370, Addison Wesley]

많은 정의가 있을 수 있지만, 우리는 이 글의 목적에 맞게 일반적으로 사용되는 정의를 채택하고자 한다.

패턴은 주어진 정황에서 반복적으로 발생하는 문제에 대한 솔루션이다.

모델 중심 개발이란 무엇인가?

모델 중심 개발은 기본적으로 솔루션을 지정 및 구현하는 소프트웨어 관련 추상화이다. 모델들은 소프트웨어 개발 수명주기를 통해 다양한 위치에서 사용된다. 수명 주기의 어떤 포인트에서도 이 모델은 특정 추상화 레벨에서 표현된다.

예를 들어, 비즈니스 프로세스 모델은 태스크, 조건, 리소스, 비용, 타이밍을 기술한다. 그 모델이 정리되면서, 구체적인 IT 시스템이나 서비스에 대한 리소스의 본질을 기술하게 된다. 이러한 종류의 정련은 추상화 레벨을 줄일 수 있다.

또 다른 예제는 액터들을 약술하는 유스 케이스의 모델이다. 이 모델이 정리되면서 유스 케이스의 구현의 본질을 기술하고 유스 케이스를 구현하는데 사용되는 컴포넌트와 서비스를 규명한다.

추상화는 다른 방향으로 갈 수 있다. 추상화를 늘리고 이 모델에서 발견된 상세 레벨을 줄이기도 한다.

가끔씩 내가 받는 질문 중에 이런 것이 있다. "모델의 가치를 찾을 수 있는 또 다른 분야는 없나요?" 모델은 꽤 오랫동안 사용되었다. Hermann Schichl(Modeling Languages in Mathematical Optimization)에 따르면 "’모델링’이란 단어는 라틴어 modellus에서 왔다. 이는 현실을 모사하는 인간의 방식을 기술한다. 인문학자들은 추상 모델을 구현하는 능력은 인간의 가장 중요한 특성이라고 생각한다…" [History of modeling, p. 25]

Schichl에 따르면 "기원전 2000년 까지 최소한 세 개의 문명(바빌론, 이집트, 인도)이 수학에 대한 놀라운 지식을 갖추었고 수학적 모델을 사용했다."[History of modeling, p. 25]

Schichl은 초기의 그래픽 모델들 중 하나는 천문학이라고 밝혔다. 이 분야에서 Ptolemy는 원과 중심점을 사용하여 서기 150년에 태양계의 모델을 만들었다. 분명 이 모델은 1619년까지 사용되었다. [History of modeling, p. 26]

모델은 커뮤니케이션의 수단을 제공한다. 이것이 잘 수행되면 꽤 오랫동안 지속될 수 있는 추상화를 제공한다. 우리 모델들 중 얼마나 많은 것들이 1500년 까지 지속될 것인가?

특정 정황에서 모델의 추상화를 선택하는 것이 중요하다.

패턴 스팩과 패턴 구현

툴링 패턴의 관점에서, 패턴 스팩과 패턴 구현의 개념을 분리했다. 패턴 스팩은 패턴을 기술하는 텍스트이다. 책이나 웹 페이지에서 볼 수 있다.

패턴은 여러 형식들 중 하나로 구현될 수 있다. 따라서 각 패턴 스팩의 경우 많은 패턴 구현들이 있을 수 있다. 패턴은 UML 모델, 컴포넌트, 서비스로서 구현된다.

여기에서 우리가 설명하는 패턴들은 UML 모델을 사용하여 구현되고 변형 기술을 사용하여 그러한 모델들을 정련한다. 여기에는 패턴 엔진이나 메커니즘이 필요하다.

위로

레시피

자산의 수가 리파지토리에서 증가하면서 문제를 해결하는데 도움이 될 자산들을 찾는데도 엄청난 노력이 필요하게 된다. 한 개 이상의 자산들을 결합하여 대단위 솔루션을 만드는 방법을 결정하는 것도 큰 짐이다.

소단위 방식으로 자산을 재사용 하면 모듈성과 자산 버저닝의 효과를 얻을 수 있다. 하지만 이들을 한데 모으는데 드는 노력은 이들의 가치를 되묻게 된다.

자산들을 결합하는데 약결합 방식을 제공하는 것이 가치가 있는 것 처럼 자산들이 주어진 정황 속에서 함께 결합되는 방법을 설명하는 것도 중요하다.

이를 위해 우리는 레시피라는 은유를 사용하기로 한다. 부엌에서 레시피는 재료와 이들을 혼합하는 방법을 알려준다. 요리사는 이들을 대체하고 활용할 많은 유연성을 갖고 있다. 이러한 관점에서 볼 때 레시피는 템플릿이다.

소프트웨어 세계에서 레시피라는 용어를 차용하고 이들을 템플릿 솔루션을 만드는데 사용할 수 있다. 여기에서 재료는 소단위 자산들이고 레시피는 이러한 자산들을 혼합하는 것에 대한 프로세스 가이드를 제공한다. 레시피 자체는 하나의 자산이다.

패턴 솔루션은 많은 패턴들을 조직한다. 레시피를 사용해서 말이다. 레시피는 재료들-패턴과 기타 자산들-을 기술하고 이들을 사용하여 문제를 해결하는 방법을 기술한다. 패턴 솔루션 구현에는 서비스, 컴포넌트, 기타 소프트웨어 생성물들이 포함된다. 이들은 레시피에 따라서 패턴들을 구현한다.

위로

Rational Software Architect 환경 설정하기

이제 이론을 공부했으니 실전에 돌입해 보도록 하자. 이 글 전체적으로 Rational Software Architect를 사용하기 때문에 갖고 있다면 설치하기 바란다.(참고자료) Rational Software Architect는 이 글을 쓰고 있는 당시 최신 fix pack 6.0.1.1로 업데이트 되어야 했다. Rational Software Architect는 Help > Software updates > IBM Rational Product Updater에서 쉽게 업데이트 할 수 있다.

RAS 클라이언트 설정하기

첫 번째로 해야 할 일은 Rational Software Architect에 RAS 클라이언트를 설정하는 일이다. RAS 클라이언트는 원격 RAS 리파지토리에 액세스 하는데 사용될 것이다. 우리가 사용할 RAS 리파지토리는 dW에서 호스팅 되는 RAS 리파지토리이다. 이 글에 사용되는 재사용 가능한 자산들은 이 리파지토리에 저장되고 이 글 전반에 걸쳐 이 리파지토리로 접근할 것이다.

다음은 Rational Software Architect 클라이언트를 설정하는데 필요한 단계이다.

• Rational Software Architect를 시작한다. 처음 시작할 경우 웰컴 스크린을 보게 될 것이다.
• Windows > Open Perspective > Other로 간다. Rational Software Architect (Reusable Asset) Perspective (Show All을 선택해서 보도록 한다.)를 선택한다.

• RAS 퍼스펙티브 뷰가 열린다.

• 여기에서 사용할 수 있는 Eclipse 기능들 중 하나는 이 퍼스펙티브를 아이콘으로 만드는 것이다.
• 퍼스펙티브 윈도우 바를 오른쪽 클릭하고 드롭다운 리스트에서 간단히 보기를 선택한다.
• Rational Software Architect 메인 윈도우의 오른쪽에 Rational Software Architect 퍼스팩티브가 아이콘으로 만들어질 것이다. 메인 Rational Software Architect 윈도우의 아래도 아이콘으로 만들 수 있다.
• 이 아이콘을 클릭하여 이 퍼스펙티브를 간단히 보기로 한다.
• 작업 공간을 깨끗이 유지한다.
• 원격 Rational Software Architect 리파지토리를 설정한다. Rational Software Architect 퍼스펙티브의 아무 곳이나 오른쪽 클릭하여 New Repository를 선택한다. 'DeveloperWorks Repository' 옵션을 선택하면 다음 값들이 채워질 것이다.
  • Name: "IBM developerWorks Rational Software Architect Repository"
  • URL:http://www.ibm.com/developerworks/product/rational/rsa/ras

• 이제 Rational Software Architect 클라이언트가 설정되어 리파지토리를 검색할 수 있다.
• 우리는 레시피를 사용할 것이기 때문에 Rational Software Architect가 레시피로 무엇을 할 것인지를 인식하도록 한다. Rational Software Architect의 앞으로의 릴리스에는 레시피를 인식하는 기능이 생긴다. 하지만 현재의 Rational Software Architect 기능을 확장하기 위해 RAS 자산을 사용하는 방법을 보여주는 좋은 예이다. dW RAS 리파지토리 구조는 ./tools/ras 폴더를 검색하고 'Solution Guide' 자산을 선택한다. 자산을 오른쪽 클릭하고 반입을 선택한다. Rational Software Architect가 레시피를 인식하는데 필요한 Eclipse 플러그인을 다운로드 및 설치한다. 설치를 완료하면 Rational Software Architect를 재시작 한다.

• 이제 레시피를 다운로드 할 수 있다. dW Rational Software Architect 리파지토리에서 ./design_soa/recipes 폴더를 검색하고 "SOA Implementation and Optimization of Services Recipe" 자산을 선택한다. 레시피를 오른쪽 클릭하면 솔루션 가이드를 여는 옵션이 있다. (주: 현재 솔루션 가이드 플러그인에 있는 버그 때문에 레시피를 작업 공간으로 반입해야 한다. 레시피를 오른쪽 클릭하고 Import를 선택한다. 법적 동의서를 수락하면 전체 레시피가 작업 공간으로 반입된다. 그런 다음, Navigator 뷰로 전환하여 레시피를 오른쪽 클릭하고 Solution Guide > Open Solution Guide View를 선택한다. 레시피가 열리고 작업 공간에서 레시피의 내용과 구조를 볼 수 있다.) 이 기능은 Rational Software Architect가 레시피를 인식하도록 하는데 필요한 Solution Guide가 이미 이전 단계에서 설치되었기 때문에 사용할 수 있는 것이다.

• SOA Implementation and Optimization of Services 레시피로는 Rational Software Architect 내부를 검색할 수 있다. 이 레시피를 이 글 전체적으로 사용할 예정이다. 윈도우를 Rational Software Architect 스크린 팔레트의 아래 쪽으로 옮기는 것이 더 좋다.
• 다운로드 섹션에서 플래시 데모를 참조하기 바란다.

Rational Software Architect 가능은 원격 RAS 리파지토리에서 다운로드 했던 재사용 가능한 자산을 사용하여 확장되었다. SOA 서비스를 구현하는데 사용되는 레시피는 원격 리파지토리에서 다운로드 했고 퍼스펙티브 가이드, 베스트 프랙티스, 패턴들을 제공하여 그러한 서비스를 구현하는데 사용된다.

Requisite/Pro RSA/RSM 통합

이 글에서 최대의 효과를 얻으려면 Requisite Pro와 Rational Software Architect를 통합 설정해야 한다. 이를 위해서 Rational Requisite Pro가 시스템에 설치되어야 한다.(참고자료) Rational Software Architect에는 최소한의 기능들이 있다. Rational Software Architect의 고급 기능을 사용하려면 Windows > Preferences > Workbench > Capabilities로 가서 Requirement Management 박스를 실행한다.

• Rational Software Architect를 시작한다. 처음 시작할 경우 웰컴 스크린을 보게 될 것이다.
• Windows > Open Perspective > Other > Requirements로 간다.
• Rational Software Architect에 새로운 요구 사항 검색 퍼스펙티브가 열린다.

• 요구 사항 익스플로러는 Requisite Pro 파일을 여는데 사용될 수 있다.
• Requisite Pro 파일은 RAS 자산으로 패키지되었고 dW RAS Repository에서 ./design_soa/requirements를 검색하면 갈 수 있다. 자산을 오른쪽 클릭하지만, 이번에는 다운로드 옵션을 선택한다. Rational Software Architect가 Requisite Pro 파일로 무엇을 해야 하는지 모르기 때문이다. ZIP 파일을 다운로드 하여 디스크에 저장한다. Requisite Profile이 첨부되었는지를 확인한다.(다운로드)
• 파일 시스템에 Requisite Pro 프로젝트의 압축을 풀고 Rational Software Architect Requirements 익스플로러가 파일을 가리키게 하고, 이를 Rational Software Architect 내부에서 열도록 한다.

Rational Software Architect는 이 Requisite Profile을 읽고 쓰도록 설정되었다.

위로

결론

레시피, 패턴, 재사용 가능한 자산들에 대해 살펴보았다. 용어를 소개했고 이들간 관계를 확립했다. Rational Software Architect를 설정하여 dW에 있는 원격 자산 리파지토리를 검색했다. 자산은 Rational Software Architect가 레시피를 인식하도록 하는데 사용되었다. 이 리파지토리에서 SOA Implementation and Optimization Recipe 자산에 액세스 했다. Rational Software Architect는 Requisite Pro와 통합되었고 Requisite Pro 테스트 파일은 자산으로서 다운로드 되어 Rational Software Architect 내부에서 열렸다.

이제 SOA 애플리케이션의 레퍼런스 예제에서 SOA Implementation and Optimization of a Service Recipe를 사용하도록 설정된다. 레시피는 MDD 환경에서 비 기능적 요구 사항들을 사용하여 어떤 패턴들이 사용되어 일관된 애플리케이션을 구현하는지 결정하는 방법에 대한 가이드를 제공한다. 다음 글에서는 레퍼런스 예제를 소개하고 Rational Unified Process와 MDD 방식이 재사용 가능한 자산에서 어떻게 결합되는지를 설명하겠다.

기사의 원문보기

• Building SOA applications with reusable assets: Reusable assets, recipes, and patterns

위로

다운로드 하십시오

다운로드 방식에 대한 정보

참고자료

교육

• Reusable Asset Specification, version 2.2
  
  
• developerWorks SOA and Web services zone
  
  
• Pattern Solutions
  
  
• developerWorks technical events and Webcasts.
  
  

제품 및 기술 얻기

• Rational RequisitePro V2003.06.15.
  
  
• Rational Software Architect V6.0.
  
  
• IBM trial software
  
  
• Reusable Asset Specification Repository for Workgroups
  
  
• Order the SEK for Linux
  
  

토론

• developerWorks blogs
  
  

필자소개

Grant Larsen는 Asset Management for IBM Rational 소프트웨어의 수석 아키텍트이고 프로세스, 표준, 툴링, 재사용 가능한 자산(패턴)을 통한 자산 기반 개발을 소프트웨어에 개발에 활용하고 있다.

Eoin Lane 박사는 솔루션 엔지니어이고 IBM SOA에 애플리케이션 패턴을 개발하고 있으며, IBM pattern 관리를 통해 그러한 패턴을 채택하도록 하는데 힘쓰고 있다. Eoin은 또한 Model Driven Development (MDD), 자산 기반 개발, Reusable Asset Specification (RAS)을 SOA 개발에 활용하고 있다.

아티클 순위

의견

위로

목차

• 머리말
• 재사용 가능한 자산
• RAS 소개
• 패턴 소개
• 레시피
• Rational Software Architect 환경 설정하기
• 결론
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견