머리말

IBM Rational Software Development Platform은 Eclipse 기반의 공통 개발 환경으로서 다음 제품들이 공유하고 있다.

• IBM® Rational® Web Developer
• IBM® Rational® Application Developer
• IBM® Rational® Software Modeler
• IBM® Rational® Software Architect
• IBM® Rational® Functional Tester
• IBM® Rational® Performance Tester

이것은 프로젝트 수행시 요구사항 수집부터 설계, 개발에 이르는 일련의 과정을 관리 및 추적할 수 있게 하는 통합플랫폼이다.

IBM Rational Software Modeler는 IBM Software Development Platform 컴포넌트 중의 하나로 Unified Modeling Language (UML) 기반의 시각적 모델링과 디자인을 위한 툴이다. 이 툴을 통해서 아키텍트, 시스템 분석가, 디자이너는 자신들이 만든 스팩, 아키텍처, 디자인이 확실히 정의되었는지 확인하고 프로젝트에 참여자들과 커뮤니케이션할 수 있다. 예를 들어, 이 툴은 요구사항을 유스케이스 다이어그램과 그 밖의 클래스 다이어그램, 시퀀스 다이어그램 같은 UML에 기반한 여러 산출물로 변환하는 것이 용이하도록 설계되었다. Rational Software Modeler는 명확한 문서작업과 시스템을 바라보는 다양한 뷰들간 통신을 가능하게 해주는 커스토마이징 가능한 툴이다. 이러한 통합을 통하여 프로젝트 팀들은 프로젝트 생명 주기 동안 협업하고 트래킹 할 수 있다. 간단히 말해서 Rational Software Modeler는 UML 모델링 툴이다.

위로

Rational Software Modeler와 Eclipse

IBM Software Development Platform은 Eclipse와 통합되어 더욱 풍부하고 사용자 친화적인 툴 세트가 된다. Eclipse는 오픈 소스 통합 개발 환경(IDE)으로서 빠르게 인기를 얻고 있다. 점점 더 많은 개발자들은 가용성과 개발 플러그인 때문에 Eclipse를 채택하고 있다. (Eclipse에 대한 자세한 내용은 참고자료 섹션을 참조하기 바란다.) Rational Software Modeler는 Perspective 같은 Eclipse 패러다임을 채택하고 있다. Rational Software Modeler에서 자주 사용하는 Perspective와 기능들은 다음과 같다.

• Modeling perspective: 이 뷰를 사용하여 UML 산출물들을 생성 및 관리한다. 만들어진 산출물들은 모두 Eclipse 리소스로서 Eclipse IDE를 사용하여 이들을 활용할 수 있다. Rational Software Modeler에서는 유스케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램, 협업 다이어그램 등 어떤 UML 다이어그램이라도 구현할 수 있다.
• Requirements perspective: 이 뷰는 IBM® Rational® RequisitePro®와의 통합을 위한 뷰이다. (이 기사의 마지막 부분에 더 자세히 논의될 것이다.)
• Model Publishing: 모델을 퍼블리시 하여 다른 사람들도 볼 수 있도록 하는 기능이다.

UML 산출물은 UML 모델 자체나 또는 모델로부터 만들어진 소스코드 형태로 저장할 수 있다. 게다가 UML 모델과 코드간 자동화 기능이 특별히 없어도 한 쪽을 통하여 다른 한 쪽을 쉽게 생성할 수 있다. .이러한 기능은 UML 다이어그램에서 바로 코드의 초기 버전을 볼 수 있기 때문에 개발자에게는 매우 유용한 기능이다. (참고자료 섹션에서 Introducing Rational Software Architect를 참조하라.)

위로

간단한 UML 모델링

Rational Software Modeler를 사용하여 기본적인 UML 모델, 사용 케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램을 만들 수 있다. 먼저, 사용 케이스 다이어그램을 만드는 방법부터 배워보자.

사용 케이스 다이어그램 만들기

UML 사용 케이스 다이어그램을 사용하여 시스템의 기능을 기술할 수 있다. 사용 케이스에는 네 가지 주요 요소들이 있다.

• 액터(Actor): 시스템과 인터랙팅 한다. 사용 케이스 다이어그램에서는 막대 모양으로 나타난다. (이 툴은 사람 처럼 보이는 그래픽을 보여준다.)
• 사용 케이스(Use cases): : 시스템의 기능을 설명한다. 다이어그램에서는 타원형으로 그려진다.
• 시스템(System): 시스템
• 관계(Relationships): 위 세 가지 요소들간 관계를 나타낸다. 다이어그램에서는 선으로 나타난다.

Rational Software Modeler를 실행하는 것으로 시작한다.

1. File 메뉴에서, BookStore라는 새로운 UML 프로젝트를 만든다. File > Create을 클릭한 다음 UML Project 필드에서 Bookstore를 타이핑한다. (서점을 모델링 한다고 생각하면 된다.)
2. BookStore 프로젝트 밑에 사용 케이스 모델을 만든다.

Rational Software Modeler 윈도우는 다음과 같다.(그림 1)

그런 다음, 사용 케이스 다이어그램을 만든다. 먼저 다변성 액터(Versatile Actors)를 만든다. 이것은 다른 사용 케이스들간 공유될 액터이다.

3. Versatile Actors 탭을 오른쪽 클릭하여 두 개의 액터, Customer와 Administrator를 만든다.
4. 이 액터들을 사용 케이스 다이어그램으로 드래그 한다.
5. 팔레트를 사용하여 Customer를 위한 네 개의 사용케이스(Search Books, Browse Catalog, Order Book, Manage Account)를 만든다.
6. Administrator 액터에는 두 개의 사용케이스(Ship Book와 Manage Catalog)를 만든다.
7. System이라는 액터를 만들어서 결제 프로세스를 핸들한다.

그림 2는 액터들과 사용 케이스 모습이다.

기본적인 사용 케이스를 만들었다. 이제 이 다이어그램에 관계(relationship)가 포함되도록 다이어그램을 확장해야 한다.

8. Manage Account 사용 케이스를 더 큰 사용 케이스를 구성하는 다른 조각들로 확장한다.
9. Manage Account 사용 케이스가 두 개의 사용 케이스(Create User Account와 Edit User Account)로 구성되는 것으로 한다.
10. 이 두 개의 사용 케이스 모두 세 개의 세부적인 사용 케이스들(Update User Profile, Update Shipping Information, Update Payment Information)로 구성된다.

그림 3은 이들간 관계를 나타낸다.

Rational Software Modeler에서 첫 번째 사용 케이스 다이어그램을 만들었다. 액터, 사용 케이스, 시스템, 사용 케이스들간 관계 모두 구축되었다. 이제 클래스 다이어그램을 만들어 보자.

클래스 다이어그램 만들기

클래스 다이어그램(class diagram)은 시스템의 다양한 클래스들과, 클래스들간 관계를 기술한다. 클래스 다이어그램은 다용도로 쓰인다.

• 요구 사항들을 파악하고 시스템의 디자인 상세를 기술할 수 있다. (아키텍트는 개발 팀과 협업하여 클래스 다이어그램을 만들어서 개발자들이 무엇을 구현해야 하는지를 충분히 이해할 수 있도록 한다.)
• 디자인 패턴들을 적용시키고 시스템이 작동하는 방식을 시각화 한다.

클래스 다이어그램은 아키텍트와 개발자간 최상의 통신 채널이 된다. 그런데 어떻게 유스 케이스로부터 클래스를 식별해 내는가? 사용 케이스의 명사(noun)가 코드의 클래스가 될 수 있다는 것을 염두해 두면 가장 좋은 구별법이 될 것이다. (참고자료)

다음 단계를 통해 Class Diagram이라는 클래스 다이어그램을 만든다.

1. Model Explorer에서 사용 케이스 모델을 오른쪽 클릭한다.
2. Customer클래스를 만든다.
3. Customer 클래스 밑에 네 개의 애트리뷰트(firstName, lastName, userId, password)를 만든다.
4. Address클래스를 만든다. (애트리뷰트는 언제라도 추가할 수 있다.)
5. Address 클래스 밑에 두 개의 클래스(BillingAddress와 ShippingAddress)를 만든다. 이 클래스들은 Address 클래스에서 일반화 된다. (그림 4)
6. Customer 클래스와 Address 클래스간 일대다 관계를 만든다.
7. CreditCard라는 클래스를 만든다.
8. CreditCard 클래스에 세 개의 애트리뷰트(creditCardNumber, creditCardType, creditCardExpirationDate)를 추가한다.
9. CreditCard 클래스와 BillingAddress 클래스 간 일대일 관계를 만든다.
10. Customer 클래스와 CreditCard 클래스간 일대다 관계를 만든다.

그림 4는 여러분이 만든 클래스 다이어그램 모습이다. Catalog, Book, Order등의 다른 클래스들도 포함시켜 클래스 다이어그램을 완성시킨다.

지금까지 사용 케이스 다이어그램과 클래스 다이어그램을 만들어 보았다. 이제 또 다른 유형의 다이어그램도 만들어 보자. 바로 시퀀스 다이어그램이다. UML 시퀀스 다이어그램은 다음과 같은 경우에 사용된다.

• 사용 케이스의 로직을 검증하고 구체화 한다.
• 요구사항을 시각화 하여 개발자와 커뮤니케이션 할 수 있다.
• 객체들간의 상호 작용을 이해함으로써 잠재적인 설계 이슈를 파악할 수 있게 하는데 도움을 준다.
• 상세한 디자인이 필요한 복잡한 클래스나 이슈들을 규명한다.

나는 사용 케이스, 클래스 다이어그램, 시퀀스 다이어그램이 소프트웨어 디자인 문서의 정수라고 생각한다. 다른 UML 다이어그램 역시 뚜렷한 가치가 있지만, 프로젝트에 할당된 시간이 그렇게 많지는 않다. 개발에 들어가기에 앞서 적어도 이 세 가지 다이어그램은 만들어야 한다.

시퀀스 다이어그램 만들기

UML 시퀀스 다이어그램 만들기:

1. Model Explorer를 사용하여 새로운 시퀀스 다이어그램을 만든다.
2. Customer, Address, CreditCard 클래스, Update User Profile 사용 케이스를 시퀀스 다이어그램에 드래그한다.
3. 팔레트를 사용하여 다음 시퀀스를 만든다. (그림 5)
   1. Customer가 updateProfile 메소드를 호출한다. 이것은 Update User Profile 사용 케이스의 일부이다.
   2. updateProfile 메소드는 Address 클래스 상에 있는 updateAddress 메소드를 호출한다.
   3. updateProfile 메소드가 CreditCard 클래스에 있는 updateCreditCard 메소드를 호출한다.
   4. updateProfile 메소드가 Customer 클래스로 리턴된다.

Rational Software Modeler에서 UML 협업 다이어그램(UML collaboration diagram)을 만들 수 있다. 이것은 객체들의 상호작용과 객체들이 교환하는 메시지 순서를 기술한다. 이 다이어그램은 그리기가 비교적 쉽다. 협업 다이어그램과 시퀀스 다이어그램에는 거의 동일한 정보가 포함되기 때문에 각 개발팀과 아키텍트가 선호하는 것을 사용하면 된다. 두 개 모두는 필요 없고, 개인적으로는 시퀀스 다이어그램이 좋다. 이벤트 순서에 대해 보다 구체적으로 되어있기 때문이다. 알고리즘 로직을 구현하는 것도 시퀀스 다이어그램이 더욱 쉽다. 하지만 여러분 생각이 다르다면 협업 다이어그램 기능을 생각해 볼 수도 있다.

위로

Rational RequisitePro와 통합

IBM Software Development Platform의 핵심적인 특징 중 하나는 소프트웨어 개발 생명 주기 와 완벽히 엔드투엔드 통합이 된다는 점이다. Rational Suite는 툴 세트에서 이러한 통합을 지원한다. 이 툴을 사용하여 정보기술(IT) 팀은 같은 툴 프레임웍 내의 모든 것 즉, 요구 사항부터 시작하여 디자인, 개발, 테스트, 전개할 때 까지 협업할 수 있다.

더 중요한 것은 Rational RequisitePro와 Rational Software Modeler의 통합이다.(참고자료) 이 둘이 통합됨으로써 요구 사항들을 트레이싱 할 수 있다. 예를 들어, 유스케이스를 특정 요구 사항에 연결지을 수 있다. 또한 이러한 유스케이스는 차례대로 어플리케이션을 정의하는 클래스 다이어그램 및 시퀀스 다이어그램과 다시 연결지어 질 수 있다. 이러한 일련의 연결과정을 통하여 개발자는 설계요소부터 요구사항까지 쉽게 파악할 수 있다.

이 글에서는 Rational RequisitePro에서 요구 사항들을 만드는 방법을 설명하지는 않겠다. 대신 Rational RequisitePro 프로젝트와 몇 가지 요구 사항들과 사용 케이스들을 정의했다고 가정한다. (어디까지나 Rational RequisitePro와 Rational Software Modeler 라이센스가 있는 경우이다.)

Rational Software Modeler에서 Requirement Perspective를 연다. Requirement Explorer를 사용하여 Rational RequisitePro 프로젝트를 연다.

이 예제에는 간단한 Rational RequisitePro 프로젝트와 Use Case 유형의 두 개의 요구 사항(Search Books와 Browse Catalog)이 포함된다. Rational Software Modeler에서 다음을 수행한다.

1. 사용 케이스 다이어그램을 연다.
2. Requirement Explorer의 요구 사항들을 드래그 하여 다이어그램에 있는 사용 케이스에 갖다 놓는다.
3. 요구 사항이 연결되었다는 표시로 Requirement Explorer에서 요구 사항의 이름 옆에 작은 화살표가 나타난다.
4. UML 다이어그램에서 사용 케이스를 오른쪽 클릭하고 Requirement를 선택하면 Rational RequisitePro에서 요구 사항을 직접 검색할 수 있다.

위로

모델 퍼블리시 하기

완성된 모델을 웹에 퍼블리시 하기는 쉽다. Rational Software Modeler는 모델에서 HTML과 이미지를 자동으로 생성한다. (이 기능은 자바 환경에서의 Javadoc 생성과 비슷하다.) 아웃풋 파일은 API 문서의 포맷과 매우 닮아있다. 이 포맷은 모든 자바 개발자들에게 익숙한 포맷이다. Javadoc에 익숙치 않은 자바 개발자들도 이 구조를 쉽게 이해할 수 있다. 아웃풋은 보기 좋게 교차 연결되어 있고 다른 모든 모델 객체들을 통해 쉽게 검색할 수 있다.

이 모델을 실제로 퍼블리시 하려면 Modeling > Publish를 클릭한다. 그림 7은 웹 브라우저에서의 모습이다. Rational Software Modeler는 모델을 Adobe® PDF 포맷으로 반출하는 옵션도 제공한다.

위로

요약

Rational Software Modeler를 사용하여 UML 2.0 표준의 사용 케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램을 만들어 보았다. 이러한 UML 객체들을 Rational RequisitePro의 요구 사항들과 함께 묶어서 각 디자인 요소들에 대한 요구 사항들을 관리 및 트레이싱 할 수 있다는 것도 배웠다. 마지막으로 완성된 모델을 웹으로 가져가기 하는 것이 얼마나 쉬운 것인지를 설명했다. 퍼블리시된 모델은 디자인 문서에 있어 귀중한 자산이 된다.

기사의 원문보기

• Introducing Rational Software Modeler

참고자료

• Trials and betas page.
  
  
• Introducing IBM Rational Software Architect (developerWorks, February 2005)
  
  
• Understanding and Customizing Model Publishing in IBM Rational Software Modeler/Architect (developerWorks, February 2005)
  
  
• How to migrate from code-centric to model-centric development using Rational Software Architect (developerWorks, January 2005)
  
  
• OO design process: Use cases, an introduction
  
  
• Getting from use cases to code Part 1: Use-Case Analysis
  
  
• The Modeling Structure Guidelines (developerWorks, January 2005)
  
  
• about UML 2.0 : UML Resource Center.
  
  
• Eclipse home page.
  
  
• IBM Software Developer Platform homepage
  
  
• developerWorks Rational content area
  
  
• IBM Rational marketing pages.
  
  
• developerWorks blogs.
  
  
• Rational Software Architect, Software Modeler, Application Developer and Web Developer forum.
  
  
• Browse for books
  
  

필자소개

Kunal Mittal, Portal/J2EE Architect, Consultant

아티클 순위

의견

위로

목차

• 머리말
• Rational Software Modeler와 Eclipse
• 간단한 UML 모델링
• Rational RequisitePro와 통합
• 모델 퍼블리시 하기
• 요약
• 참고자료
• 필자소개
• 의견