IBM Rational Software Architect Version 7.5에서 UML Modeler의 새로운 기능 사용하기

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

난이도 : 중급

Wayne Diu, 소프트웨어 개발자, IBM Canada

2008 년 12 월 02 일

본 글에서는 IBM® Rational® Software Architect Standard Edition Version 7.5와 IBM® Rational® Software Architect for WebSphere Software Version 7.5에서 일반적인 UML Modeler 컴포넌트가 가지는 몇 가지 새로운 기능에 대해 소개하고 최근에 추가된 기능을 어떻게 활용하는지 설명합니다.

향상된 UML 모델링

UML Modeler 컴포넌트의 새로운 기능은 새로 출시된 IBM® Rational® Software Architect Standard Edition Version 7.5와 IBM® Rational® Software Architect for WebSphere Software Version 7.5에서 모두 일반적으로 사용된다. 이 글에서 이 두 제품을 짧게 IBM® Rational® Software Architect Version 7.5 또는 Rational Software Architect V7.5라 칭하겠다.

본 글에서는 Rational Software Architect V.5에서 UML Modeler 컴포넌트가 가지는 몇 가지 새로운 기능을 소개하고 최근에 추가된 기능을 어떻게 활용하는지 설명한다.

Rational Software Architect V7.5에서는 UML Modeler 컴포넌트 사용이 매우 편해졌다. 먼저 다수의 사용자들이 거대한 모델을 공유하는 데 있어 작업하기 편하게 만듦으로써 모델 관리 기능을 대폭 강화했다. 또한 모델링이 어렵거나 배우기 힘들다고 생각하는 이들을 위해 단계별로 좀 더 명쾌하게 만들었다. 특히 잠재적으로 복잡해질 수 있는 영역을 단순화함으로써 더 신속히 결과를 가질 수 있게 했다.

강조할 또 다른 점은 모델 무결성이다. 즉, 망가진 모델로 끝내는 경우를 줄였다. 실제로 Rational Software Architect에서 모델이 가진 잠재적 문제를 이해하고 수리할 수 있게 됐다. 이를 통해 더 신속하게 작업을 끝낼 수 있고 더 정확한 모델을 가지게 되고 그 결과 모델에 변경을 가져와 UML 명세에 적합한 더 높은 수준의 모델을 가지게 됐다.

위로

New Model 마법사

Rational Software Architect 이전 버전에서 업그레이드한 사용자들은 New Model 마법사를 사용하면서 바로 다른 점을 발견할 것이다.

• 이제 모델을 만드는 데 Model 마법사와 UML Model 마법사라는 두 개의 마법사가 있다.
• 모델 템플릿 세트가 업데이트됐다.
• 새 기능을 맞춤화할 수 있도록 마법사 페이지가 추가됐다(루트 요소, UI 기능, 작업 세트 같은 패키지를 갖게 됐다).
• 확장 메커니즘이 개선돼 두 마법사가 존재하는 이유를 설명한다.

루트로서의 패키지

템플릿에서 새 모델을 만든다면 UML 패키지를 리소스의 루트 요소로 삼는 것이 New Model 마법사가 보여주는 시각적으로 가장 명확한 변화 중 하나다. 템플릿을 모델로 참조하는 대신 패키지로 참조하는 것을 볼 수 있을 것이다.

용어를 확실히 하자면 모델은 사실 두 개 이상의 속성을 가진 패키지며 그 중 하나는 뷰포인트 String(다른 속성은 metamodel이다)이다.

이 변화는 아주 미묘하지만 아주 중요한 함의가 있다. 역사적으로 제품의 모든 이전 버전에서 Model UML 요소는 항상 .emx 파일 리소스의 루트에 있었다. UML 명세에는 리소스의 루트에 무엇이 있어야 하는지에 대한 규정은 없다. 사실 UML 명세에는 리소스의 개념조차 없다.

Model이 사실 Package의 명세에 지나지 않는다는 것은 Rational Software Architect V7.5의 Package가 리소스의 루트 요소라는 이야기다. 그렇기 때문에 "Blank Package" 대신 "Blank Model"을 볼 수 있다.

여기서 제기되는 문제는 파일 호환성인데 제품의 이전 버전은 모델을 루트로 지원하지 않기 때문이다. 그렇다면 파일이 호환되도록 하려면 어떻게 해야 하나? 가장 처음 할 일은 마법사 페이지를 찾는 것이다.

Package Details 마법사 페이지

템플릿 선택 후 Next 버튼을 클릭하면(그리고 템플릿이 지원하면) Package Details 페이지가 나온다.

그림 1처럼 Package Type 그룹에서 패키지 유형을 Model로 변경할 수 있다. 그러고 나면 리소스 루트가 model이 될 것이고 파일은 이전 버전에서도 제대로 열릴 것이다. 이 설정은 원래대로 돌릴 수 없다. 그러므로 마법사로 다시 작동시키면 Packages가 아니라 Models가 생성될 것이다. 제품 이전 버전에서 모델을 사용하고자 한다면 Package 대신 Model을 선택해야 호환성 문제를 겪지 않을 것이다.

팁: 그림 2에서 보면 Project Explorer의 패키지 아이콘(닫힌 폴더)이 모델 아이콘(세모로 닫혀진 폴더)과 약간 다름을 알 수 있을 것이다. 그러므로 Properties 뷰를 활성화하지 않아도 차이점을 알 수 있다.

이미 만들어진 Package를 Model로 변환하는 것은 쉽다.

1. Package를 오른쪽 클릭한다.
2. Refactor > Convert Package to Model 순으로 선택한다.
3. OK를 클릭한다.

팁: Model에서 Package로 변환하는 것도 같은 방법을 사용하면 된다. Model을 오른쪽 클릭하고 Refactor > Convert Model to Package를 선택한다. 뷰포인트 속성을 잃을 것이라는 경고를 받을 것이다. 위에서 잠깐 언급했듯이 뷰포인트 String은 모델이 아닌 패키지만이 지원하는 추가 속성임을 기억하자. 또한 UML 명세의 이 뷰포인트 String을 사용자 인터페이스의 불필요한 요소를 숨기는 데 사용되는 Modeling 뷰포인트와 혼동하지 말자.

루트 요소로 패키지를 갖게 되면 여러 혜택이 있다. 예를 들어 간단한 끌어다 놓기(drag-and-drop) 동작으로 하나의 루트 패키지를 다른 루트 패키지에 옮길 수 있다. 패키지는 다른 패키지를 가질 수 있으므로 이는 완전히 유효하다.

Model Capabilities 마법사 페이지

Model Capabilities 페이지에서는 상관없는 UI를 모델에서 숨겨버릴 수 있다. 예를 들어 Blank Package 템플릿에서 모델을 만들고자 할 때 Activity 다이어그램만 설계할 것이다. 메뉴, 팔레트, 메뉴 아이템의 다이어그램 어시스트, 도구, 흥미없는 요소를 만드는 옵션을 가진 버튼 등을 신경쓸 필요가 없다. 이 마법사 페이지에서 잠재적으로 모델에 사용할 다이어그램과 UML 요소만 선택하면 된다.

팁: 모델을 만든 후 기능을 변경하고자 한다면 간단히 다음과 같이 한다.

1. Project Explorer 뷰에서 모델을 선택한다.
2. 그러고 나면 Properties 뷰의 Capabilities 탭에서 기능을 수정할 수 있다.

Add the project to Modeling Sets 마법사 페이지

Modeling Working Set는 이클립스 작업공간의 Modeling 리소스만을 가진 리소스 그룹이다. 이를 Modeling 파일만을 포함하기 위해 필터된 Resource Working Set로 생각할 수 있다.

Add the project to Modeling Working Sets 페이지에서 새로 만든 모델(표준 템플릿에서 만든 모델이거나 기존 모델)을 가지는 프로젝트를 working set에 추가할 수 있다. Working set가 아직 없다면 그림 4처럼 Select 버튼을 클릭해 자신만의 working set를 만들면 된다.

Working set의 목적은 작업공간에서 관련없는 리소스를 숨기는 것이다. 예를 들어 시간의 반은 Scheduling System을 담당하고 다른 반은 Reservation System을 담당한다고 가정하자. 두 리소스 세트 모두 비슷한 명칭 규약(naming convention)을 가지기 때문에 혼동할 수 있다. 대체로 이것들은 독립적이지만 가끔 같은 시간에 두 개의 세트를 함께 작업해야 할 일이 생긴다.

이 문제를 해결하기 위해 리소스를 두 개의 working set로 나눌 수 있다.

1. 그러고 나면 Project Explorer(또는 Package Explorer) 같은 뷰에서 세모 버튼을 눌러 View 메뉴를 꺼낼 수 있다.
2. 여기서 Select Working Set(그림 5처럼)를 선택해 작업공간의 관련없는 리소스를 제거해 혼동을 없앨 수 있다.

마법사 확장

그간 New Model 마법사의 확장 메커니즘이 많이 향상됐다. 사실 확장성 계약처럼 UML Model 마법사는 일반적이고 UML 특유의 것이 아닌 Model 마법사로 확장한다. 이 때문에 두 개의 마법사가 필요하다. 하나는 일반적인 모델을 위한 것이고 다른 하나는 UML 모델을 위한 것이다. UML Model 마법사는 com.ibm.xtools.common.ui.wizards.NewModelWizard를 하위로 분류한다. 맞춤화된 마법사를 만들려면 같은 방법을 사용하면 된다.

org.eclipse.ui.newWizards 확장 포인트를 통해 마법사에 기여하는 것에 대해 더 자세히 알고 싶으면 참고자료 절을 참조하자. 템플릿에 기여하는 것을 더 자세히 배우려면 제품 문서(Extending product function > Extending IBM Rational Software Architect Software function > Extending the Rational modeling environment > Rational Modeling Platform Developer Guide > Programmer's Guide > Customizing the user interface > Adding Templates to the New Model Wizard)를 읽자.

위로

모델 로드 타임 줄이기

보통 모델을 열려면 Project Explorer 뷰에서 이를 더블 클릭하면 된다. Rational Software Architect V7.5에서는 그림 6처럼 각 모델 옆에 + 사인이 있음을 발견할 것이다. 닫힌 모델 옆의 + 사인을 클릭하면 주 다이어그램이나 모델 편집기를 열지 않고도 모델을 열 수 있다. 일반적으로 모델이 열릴 때 열리는 주 다이어그램은 다수의 레퍼런스를 가진 다이어그램이다. 그러므로 이를 렌더링하면 참조된 모델이 로드된다. 모델을 더블 클릭하는 대신 + 사인을 클릭하면 다이어그램이 열리지 않은 상태에서 모델이 열리므로 잠재적으로 다른 모델이 로드될 준비를 한다. 이를 통해 많은 시간을 절약할 수 있다.

팁: Project Explorer에서 선택된 모델을 오른쪽 클릭할 때 나타나는 Open Model 메뉴 아이템을 사용해 열 수도 있다. Open Model 메뉴 아이템도 모델 편집기나 주 다이어그램을 열지 않는다.

모델 무결성
좀 전에 제대로 열린 모델을 다시 열었는데 열자마자 잘못된 레퍼런스를 포함했다는 것을 깨달은 적이 있는가? Rational Software Architect에서는 잘못된 레퍼런스가 있다는 정보를 제공하는 새 대화상자가 있다. 이 대화상자는 하나나 그 이상의 잘못된 레퍼런스(예를 들어 + 사인을 클릭하거나 모델을 더블 클릭하거나 다른 참조된 모델을 간접적으로 열었을 때 같은 사용자 행위에 따른)를 포함한 모델을 열 때마다 나타난다.

Details 버튼을 누르면 그림 7처럼 잘못된 레퍼런스 테이블을 보여준다. 아래에 다음과 같은 세 가지 버튼이 있다.

• 첫 버튼은 Repair다. 이 버튼은 나중에 설명할 작업공간 환경설정에 따라 바로 레퍼런스를 수리한다. Repair는 현재 로드중인 모델 내의 요소만을 검색할 것이다. 현재 해결할 수 없는 요소를 위해 문제 마커가 만들어질 것이다.
• 중간 버튼은 Mark problems로 Problems 뷰에 모든 잘못된 레퍼런스를 문제 마커로 추가한다. 또한 모델 요소가 빨간 x표로 표시되는데 이는 문제의 위치를 나타낸다.
• 오른쪽 버튼은 Ignore다. 잘못된 레퍼런스만을 남겨둔다.

수리를 할 수 없다면 문제를 표시하는 것은 별로 유용하지 않다. 다행히 수리 능력 또한 있다. Quick Fix 메뉴 아이템을 선택하면 두 가지 선택사항이 담긴 대화상자가 나타난다. Automatic Workspace Reference Fixup을 선택하면 작업공간(닫힌 리소스를 포함한)의 모든 리소스를 스캔한다. 그러고 나면 리소스 중 하나의 안에 요소를 위치시켜 모든 잘못된 레퍼런스를 수리하려고 한다. 매칭되는 알고리즘은 요소 ID를 기반으로 한다. 또는 Change resource path reference를 선택해 현재 선택된 잘못된 레퍼런스만을 수리할 수도 있다.

표시된 문제를 수리하는 두 가지 방법 Repair Workspace References 대화상자의 Repair와 Quick Fix 대화상자의 Automatic Workspace Reference Fixup 간의 차이는 다음과 같다. Repair는 잘못 참조된 요소를 찾는 모델만을 검색한다. 예를 들어 팀이 두 개의 조각난 패키지를 포함한 모델을 작업하는 경우를 고려해 보자. 그 중 첫 번째 조각난 패키지는 클래스를 가지고 있고 모델의 루트 수준의 다이어그램은 그 클래스에 레퍼런스를 포함하고 있다. 팀의 다른 멤머가 첫 번째 조각난 패키지에서 두 번째 조각난 패키지로 클래스를 이동시키면서 주 모델에서 이를 확인하는 것을 잊었다면 클래스의 다이어그램 레퍼런스가 부서질 것이다. Repair Workspace References 대화상자의 Repair는 Check to perform 옵션을 Check resource and elements로 설정했다는 가정 하에 이 시나리오를 수리할 것이다. 하지만 누군가가 클래스를 완전히 다른 모델로 이동시켰다면 잘못된 레퍼런스를 찾고 수리하기 위해 Automatic Workspace Reference Fixup Quick Fix를 호출해야 할 것이다.

레퍼런스 해결 설정을 작업 흐름에 맞게 변경할 수 있다. 이는 그림 8처럼 Modeling, Resource Resolution 카테고리의 Preferences 대화상자에서 할 수 있다.

옵션의 첫 번째 그룹에 선택할 수 있는 사항은 다음과 같다(Resolution Method).

• None: 잘못된 레퍼런스를 찾았을 때 아무런 행동도 취하지 않는다. 대화상자의 Ignore 버튼과 같다.

• Prompt(기본): Repair Workspace References 대화상자를 보여줘 잘못된 레퍼런스를 미리 보고 다음에 무엇을 할지 결정할 수 있게 한다.

• Mark broken references: 잘못된 레퍼런스를 찾았을 때 아무런 지시없이 문제 마커를 자동으로 만든다. 대화상자의 Mark problems 버튼과 같다.

• Repair broken references: 아무런 지시없이 잘못된 레퍼런스를 자동으로 수리한다. 대화상자의 Repair 버튼과 같다.

옵션의 두 번째 그룹(Check to Perform)은 설명이 더 필요하다.

• Check resources(기본): 리소스가 존재하는 한 리소스에 참조된 요소가 더 이상 존재하지 않아도 레퍼런스는 잘못되지 않았다고 여긴다.

• Check resources and elements: 리소스가 존재하고 참조된 요소가 리소스 안에 존재하면 레퍼런스는 잘못되지 않았다고 여긴다.

팁: 이전 제품의 행위를 보존하려면 Check resources 옵션이 기본으로 선택됐어야 한다. 하지만 Check resources and elements가 더 완벽한 업무를(더 시간이 많이 걸리더라도) 수행한다. 리소스 사이에서 몇 가지 요소를 이동시킨 후 레퍼런스를 수리해야 한다면 Check resources and elements 옵션을 선택해야 한다.

프로파일 무결성

잘못된 내부모델(intra-model) 레퍼런스를 여는 것과 별개로 적용된 프로파일이 빠진 모델을 열 수 있다. 그림 9는 모델에 적용된 프로파일이 빠진 모델(PilotOrderMaker)에서 모델(CateringSystem)을 연 후의 상황을 설명한다.

1. 먼저 Profile Editor를 열고 Details 탭을 클릭한다.
2. 그러고 나서 해결되지 않은 적용된 프로파일을 선택한다. Repair와 Remove 버튼 모두 선택 가능하다.

Rational Software Architect V7.5에는 이 문제를 해결하는 데 도움이 될 두 가지 활동이 있다. Repair를 클릭하면 프로파일을 재선택해 적용할 수 있다. 이는 프로파일의 위치가 이동했을 때 유용하다. 예를 들어 작업공간에서 파일로 사용했던 프로파일이 환경에 플러그인으로 배치됐을 때 일어난다.

하지만 전혀 필요없는 프로파일이 적용된다면(파일럿이 배달 서비스 주문을 받기나 한단 말인가?) Remove 버튼을 클릭하는 게 더 적절하다. Remove는 프로파일 애플리케이션을 적용하지도 않을 것이고 프로파일에서 적용된 모든 전형(stereotype)도 적용하지 않을 것이다. 이 정보가 한 번 제거되면 다시는 회복할 수 없으므로 사용할 때 주의해야 한다. 프로파일이 전혀 의미가 없는 경우 매우 유용하다.

위로

Activity 다이어그램

Rational Software Architect V7.5의 Activity 다이어그램에서 새로 개발된 것은 다음과 같다.

• 각각의 행위나 동작으로 Call Behavior Actions와 Call Operation Actions의 자동 동기화
• 레이아웃 강화
• 새롭게 통합된 흐름 도구
• 핀 감추기와 보여주기 통제 기능

Call Behavior Actions와 Call Operation Actions

IBM® Rational Software Modeler V7.0.5.1과 IBM® Rational Software Developer V7.0.5.1부터, 그리고 Rational Software Architect V7.5의 새로운 점으로 Call Behavior Actions와 Call Operation Actions는 기본으로 이름이 주어지지 않는다. Call Behavior Action이나 Call Operation Action에 이름이 없으면 참조된 행위나 동작의 이름이 대신 사용된다. 물론 이름을 지정하겠다고 선택하면 그 이름이 보인다.

주의: 다이어그램에서 별칭을 보여주기로 하고 Call Behavior Action이나 Call Operation Action에 이름이 없다면 참조된 행위나 동작의 별칭이 보인다(Call Behavior Action이나 Call Operation Action용 별칭이 설정됐는지 여부에 상관없이). 참조된 행위나 동작의 별칭은 공백(blank)이어야 이름이 보일 것이다.

제품의 이전 버전에서 만들어진 Call Behavior Actions와 Call Operation Actions는 이름이 기본으로 주어졌기 때문에 모델에서 이 이름들을 제거해 새 기능을 사용하고 싶을 것이다. 모든 Call Behavior Actions의 이름을 신속히 제거하려면 다음과 같다.

1. Tasks 뷰를 활성화하고 "call behavior action인 "[이름]"은 공백 이름을 가져 참조된 [행위/동작] 이름을 보여줘야 한다(It is suggested that the call behavior action "[name]" has a blank name to show the name of the referenced [behavior / operation])"라는 제목이 붙은 작업을 선택한다.
2. Quick Fix를 오른쪽 클릭하고 선택한다.
3. 이제 그림 10처럼 모델의 모든 call behavior actions 이름을 제거(Clear the name of all call behavior actions in the model)하는 옵션을 선택한다.

필요에 따라 동작(Operation) 대신 행위(Behavior)를 써서 Call Operation Actions에도 이 단계를 반복할 수 있다.

레이아웃

Activity 다이어그램의 Arrange All과 Arrange Selection 행위가 강화됐다. 특히 요소가 파티션을 오버랩하지 않는다. 또한 파티션 안의 요소를 쉽게 배열할 수 있다. 이제 파티션이 선택될 때 Arrange Selection이 가능하다. 이는 그림 11처럼 현재 선택된 파티션 내의 요소를 배열하는 것이다. 반면 Arrange All은 선택된 객체의 전체 activity 다이어그램을 독립적으로 배열한다.

Unified Flow 도구

Rational Software Architect의 이전 버전에서 Activity 다이어그램을 작업한다면 팔레트에 Object Flow와 Control Flow라는 두 개의 흐름 도구를 발견할 것이다. 이제 Rational Software Architect V7.5에서는 팔레트는 하나의 도구만을 가지게 됐다. UML 규칙과 상식 선에서 자신이 원하는 것을 도구가 결정할 만큼 똑똑해졌기 때문에 더 이상 올바른 것을 선택하기 위해 고심할 필요가 없어졌다.

이제 Flow 도구는 필요에 따라 Control 흐름과 Object 흐름을 변경할 수 있을 만큼 똑똑해졌다. 예를 들어 그림 12처럼 isvaluedcustomer Decision 컨트롤 노드 간의 Yes와 No 흐름이 확실해졌고 Hang up과 Give offer Activity Final 노드가 Control 흐름이어야 한다. 하지만 어떤 이유에서인지 Central Buffer에 추가돼야 한다고 가정하자. Central Buffer에 No 엔드를 재적용했다면 Control 흐름은 자동으로 Object 흐름으로 변경될 것이다.

물론 어떤 흐름 도구를 사용할지 확실할 수도 있다.

1. 이런 경우 여전히 General > Capabilities의 Preferences 대화상자에서 이전 두 개의 흐름 도구를 다시 가능하게 하는 옵션을 가진다.
2. 그림 13처럼 Advanced 버튼을 클릭하고 UML Activity 4 옵션을 선택해 이를 가능하게 한다.

핀 보여주기와 숨기기

어떤 사람들은 핀을 매우 불편히 여겨(시맨틱하게는 필요함에도 불구하고) Activity 다이어그램에서 숨기길 원하기도 한다.

1. 다이어그램 표면을 클릭한 후 Appearance 속성 탭을 클릭한다.
2. Hide action pins 체크박스를 선택한다. 이제 핀이 화면에서 보이지 않을 것이다.
3. 그림 14처럼 Modeling > UML Diagrams > Activity > Pin Display의 Preferences 대화상자에서 모든 다이어그램의 핀을 숨기도록 선택할 수도 있다.

위로

시퀀스 다이어그램

이제 시퀀스 다이어그램의 포션을 InteractionUse에 리팩터링할 수 있다. 또한 동작을 리팩터링함으로써 시퀀스 다이어그램이 닫힌 모델에 있더라도 시퀀스 다이어그램 안의 맞는 메시지를 업데이트할 것이다. 또한 시퀀스 다이어그램은 UML 명세에 더 잘 맞는 Formal and Actual Gates를 지원하고 복사와 붙이기 지원이 더 향상됐다.

시퀀스 다이어그램 리팩터링하기

가끔 시퀀스 다이어그램에는 별로 흥미롭지 않은 많은 상세 내역이 들어가 있다. 다이어그램 섹션을 InteractionUse로 리팩터링할 수 있다. 그림 15처럼 다이어그램에서 AgentSystem은 CancellationManager에 취소요청을 보낸다. 이 포션은 InteractionUse로 리팩터링될 수 있다. 이를 위해 Refactor > Refactoring Into New Interaction을 오른쪽 클릭해 선택한다. 이 리팩터링을 수행하는 기능은 Rational Software Architect V7.5의 새로운 기능이다.

InteractionUse를 더블 클릭하면 리팩터링의 결과인 새 시퀀스 다이어그램이 열린다.

또한 시퀀스 다이어그램 메시지가 동작을 참조하고 다음에 동작이 리팩터링되면 메시지 이름이 자동으로 업데이트될 것이다. 업데이트는 시퀀스 다이어그램이 닫힌 모델에 있을 때도 일어날 것이다. 이 기능은 Rational Software Architect V7.5의 새 기능이지만 IBM® Rational® Software Modeler Version 7.0.5.1(및 그 이후 버전)과 IBM® Rational® Software Developer Version 7.0.5.1에 있던 기능이다.

팁: 닫힌 모델을 고려해 보려면 간단히 재명명하기보다는 리팩터링해야 한다(그림 16처럼). 동작을 간단히 재명명하는 대신(예를 들어 다이어그램 표면이나 Properties 뷰로부터) Project Explorer에서 동작의 컨텍스트 메뉴에서 Refactor > Rename을 선택해야 한다. 동작 상에서 Refactor > Rename을 선택하면 시퀀스 다이어그램이 닫힌 모델의 메시지를 포함하더라도 메시지 이름을 업데이트할 것이다.

Gate 지원

Gate 지원은 Rational Software Modeler V7.0.5.1과 Rational Software Developer V7.0.5.1에는 있었지만 Rational Software Architect V7.5에는 새로운 기능이다.

1. 인터랙션 프레임 상에 Formal Gate를 추가하려면 메시지 팔레트 생성 도구를 클릭한다.
2. 다음 다이어그램 프레임을 클릭하고 이를 라이프라인에 끌어넣는다.

그림 17의 예처럼 동기화된 메시지는 다이어그램 프레임에서 생명선(lifeline)까지 만들어졌고 기존 동작인 performCancel이 선택됐다. 메시지는 생명선의 밑에 추가된다. 이것들을 적당한 위치로 이동시키는 가장 간단한 방법은 메시지를 재정열하는 것이다.

1. 이를 위해 윈도우에서 메시지를 선택하는 동안 Alt 키를 누른다(또는 메시지를 선택하고 오른쪽 클릭한 후 Select Message Set > Reorder를 선택한다).
2. 그러고 나서 requestCancel을 performCancel 블록에 끌어다 놓는다.

원래 다이어그램에서 Actual Gate를 InteractionUse로 모델링하려면 다음 단계를 거치면 된다.

1. 다른 생명선에서(Actor가 그림 18의 Agent를 나타낸다고 하자) InteractionUse까지 메시지를 끌어다 놓는다.
2. Formal Gate에서 선택한 것과 같은 동작을 선택한다.

팁: Rational Software Architect V7.5는 잘못된 게이트를 찾는 타당한 규칙을 가진다. 오류와 작업이 Problems 뷰와 Tasks 뷰에 각각 나타날 것이다. 규칙 이름은 Interaction gates와 Actual gates - formal gates matching rule이다.

복사와 붙이기 강화

복사와 붙이기 지원은 Rational Software Architect V7.5의 시퀀스 다이어그램에서 많이 향상됐다. 이제 시퀀스 다이어그램 내와 사이의 시퀀스 다이어그램 요소를 복사할 수 있고 Project Explorer 내의 interactions를 복사할 수 있다. 이 기능과 관련된 가장 유용한 강화된 점은 붙이기 동작이 컨텍스트임을 안다는 것이다.

이는 Optional Combined Fragment를 다른 것에 복사할 수 있다는 것을 의미한다. 아마 틀림없이 더 유용한 기존 생명선과 요소는 가능할 때마다 재사용될 것이다. 예를 들어 메시지를 복사하면 기존 생명선의 아래에 나타난다. 심지어 생명선과 메시지 부분만도 복사할 수 있다. 이것들이 강화됨에 따라 시퀀스 다이어그램을 편집하는 것이 훨씬 쉬워졌다.

위로

다른 새로운 기능과 향상점

유효성 규칙 인식하기

이 글의 이전 절에서 게이트 지원에 따라 어떻게 특정 유효성 규칙이 추가되는지 논의했다.

하지만 특정 문제, 경고, 작업 등의 이유가 직접적으로 명백해지진 않는다. 이제 유효성 실패에 관련된 규칙을 인식하는 쉬운 방법을 설명하겠다.

1. 문제, 경고, 작업을 Problems 뷰나 Tasks 뷰에서 선택하고 오른쪽 클릭한다.
2. 그림 19처럼 Constraint definition이라는 새 메뉴 아이템을 볼 수 있을 것이다. 이 메뉴 아이템을 선택하면 작업에 관한 자세한 정보를 제공하므로 제안된 동작을 더 쉽게 이해할 수 있을 것이다. 제약이 의무적인 것이 아니라면 체크박스 표시를 제거하고 OK를 클릭해 이 옵션을 사용하지 못하게 할 수 있다.

Explore 팔레트 탭

Rational Software Architect V7.5에서는 관계를 쉽게 찾을 수 있다. 다이어그램 팔레트의 Explore 탭으로 다른 종류의 관계를 찾으면 된다. 특정 요소와 관련된 요소를 보려면 팔레트 아이템을 클릭하고 다이어그램 표면의 표적 요소를 클릭하면 된다. 관계와 관련된 요소 모두 자동으로 나타난다.

그림 20은 SingleAvailabilityQuery의 관계와 관련된 요소를 보여준다(팔레트에 있는 Explore 탭의 UML 드로어(drawer)에서 도구를 선택하고 SingleAvailabilityQuery 클래스를 클릭한다).

또한 그림 21처럼 Profile 드로어에서 적용된 스테레오타입과 적용된 프로파일을 시각화할 수 있다. 이를 위해 팔레트의 Explore 탭의 Profile 드로어에서 Applied Stereotypes 도구를 사용한다.

그루핑

특정 다이어그램 요소를 함께 가지고자 할 수도 있다. 예를 들어 StartLocation과 EndLocation 목록은 개념이 같으므로 다이어그램 상에서 서로 가까이 나타나는 것이 좋다. 이를 위해 다음과 같이 한다.

1. 모양을 선택한다.
2. 이것들을 오른쪽 클릭한 후 Filters > Group?.. 순으로 선택한다.

이것들을 그룹으로 묶은 후 요소는 배열 작동시에도 하나의 분리될 수 없는 블록으로 처리된다. 또한 그룹이 선택되면 Arrange Selection은 그룹 내의 객체를 배열할 것이다.

그루핑 요소의 또 다른 혜택은 그룹으로 묶인 요소의 외향을 신속히 수정할 수 있다는 것이다. 예를 들어 StartLocation과 EndLocation의 구획 모양은 Filters 팝업 메뉴에서 수정할 수 있다.

다른 속성도 그룹이 선택될 때 Properties 뷰의 Appearance 탭이나 Format 팝업 메뉴에서 설정할 수 있다. 이를 통해 변경을 가하기 전 같은 요소를 다시 선택하고 또 재선택할 필요 없이 다중 요소의 모양을 일관성 있게 적용할 수 있다. 그림 22처럼 팝업 메뉴를 사용해 요소를 그룹 해제할 수 있다.

모델링 예외

Rational Software Architect의 이전 버전에서는 예외를 모델링할 수 없었다. Rational Software Architect V7.5는 예외 모델링 지원을 추가했다. 다음을 통해 이를 시도할 수 있다.

1. Class에 Operation을 추가한다.
2. Operation을 선택하고 나면 Properties 뷰를 호출한다. 그림 23처럼 Exceptions라는 탭을 볼 수 있을 것이다.
3. Add 버튼을 클릭해 추가할 예외를 선택한다.

다중 값을 가진 속성용 기본 값 설계하기

Rational Software Architect V7.5에서는 속성용 다중 기본 값을 지정할 수 있다.

1. 속성을 만든 후 Properties 뷰를 선택한다.
2. ellipses (...) 버튼을 클릭한다. 그림 24처럼 다중값을 가진 속성을 모델링하기 위한 인터페이스가 나타날 것이다.

팁: ellipses 버튼이 유효하지 않다면 다수를 *나 1보다 큰 숫자로 설정하고 속성의 유형을 설정한다. 다른 유형은 다중값을 가진 속성을 모델링하기 위한 인터페이스에 다른 버튼을 보여줄 것이다. 예를 들어 속성을 Enumeration 유형으로 설정하면 최초 유형으로 속성을 설정하기보다는 다른 버튼에 나타날 것이다.

이처럼 Instance 모델링을 수행할 때 Rational Software Architect V7.5에서는 같은 인터페이스를 통해 슬롯 값을 지원하는데 더욱 향상된 모습을 보일 것이다. Rational Software Modeler와 Rational Systems Developer V7.0.5.1에도 같은 개선점이 추가됐다.

리치 텍스트

리치 텍스트(rich text) 기능은 그림 25처럼 Rational Software Architect V7.5에서 더욱 향상되고 폭발적으로 사용된다. 리눅스의 행위는 윈도의 행위와 약간 차이가 있다는 것에 유의하자. 예를 들어 리눅스를 사용해 Model Editor의 문서를 편집하려면 문서 블록 하의 Edit 버튼을 클릭해 리치 텍스트를 편집할 수 있는 대화상자를 보여준다.

위로

요소와 관계 기능

Rational Software Architect V7.5에는 몇 가지 중요한 새 기능이 있다.

요소 임포트와 패키지 임포트 그 자리에서 확대하기

그림 26처럼 + 사인을 클릭해 요소 임포트와 패키지 임포트를 쉽게 확대할 수 있다. 이 기능은 Rational Software Architect V7.5에서는 새로운 기능이지만 Rational Software Modeler와 Rational Systems Developer V7.0.5.1에는 이미 있던 기능이다. 그 자리에서 요소를 확대할 수 있다면 관리 가능한 크기의 모델을 더 큰 팀들 사이에서 공유할 수 있고 이것들을 쉽게 참조할 수 있다.

이 임포트는 시스템 라이브러리에 있을 필요가 없다는 것이 중요하다. 이는 팀의 다른 성원(심지어 다른 팀일 수도 있다)과 공유하는 다른 모델일 수도 있고 같은 모델의 다른 패키지를 가리킬 수도 있다. 요소 임포트나 패키지 임포트를 요소에 만들 수 있는 한 그 자리에서 확대할 수 있다.

Element 대화상자 선택하기

작업 공간에 모델 수가 많을 때 동시에 이것들을 열지 않는 것이 좋다. 성능에 나쁜 영향을 주기 때문이다. 대신 이전에 논의한 + 사인 강화는 환경에서 모델을 여는 수를 줄이는 데 도움이 된다.

Rational Software Architect의 이전 버전에서는 Select Element 대화상자의 닫힌 모델로는 작업할 수 없었다. 사실 닫힌 모델은 걸러져 나갔다. 닫힌 모델에서 무언가를 선택하려면 이들 Select Element 대화상자를 취소하고 수동으로 모델을 열어 요소를 선택하도록 대화상자를 재호출해야 했다.

이제 더 이상 그럴 필요가 없다! 먼저 Select Element 대화상자는 그림 27처럼 Browse 탭의 닫힌 모델을 보여준다. 둘째, 닫힌 모델을 더블 클릭하면 열릴 것이다.

팁: 물론 Browse 탭에서도 Project Explorer와 같은 방식으로 요소 임포트와 패키지 임포트를 확대할 수 있다. 임포트를 확대할 수 있다는 것은 이전 제품에서 Model Imports 가상 폴더를 교환할 수 있다는 것이고 이제 초기 유형을 위치, 선택하는 방법이 될 것이다.

이와 비슷하게 Select Element 대화상자의 Search 탭에서 닫힌 모델의 요소는 매치의 목록에 반환된다. 이것들의 아이콘은 그림 28처럼 상단 좌측의 장식자로 보인다.

1. 이 매치 중 하나를 더블 클릭하면(또는 선택해 OK를 누르고) 모델을 로드하고 요소를 선택할 것이다.
2. 검색 범위에서 닫힌 모델을 배제하려면 Modify search scope를 클릭하고 Search entire workspace 체크박스 표시를 제거한다.

콘텐츠 어시스트와 알지 못하는 유형 만들기

요소 임포트와 패캐지 임포트는 그 자리에서 이것들을 확장할 때만 유용한 것이 아니다. 요소를 임포트하고 콘텐츠 어시스트를 호출한다면 임포트된 패키지의 유형은 그 결과에 포함될 것이다. 콘텐츠 어시스트는 임포트된 모델에서 유형을 보여준다. CentralSystem 패키지가 임포트됐으므로(그림 29의 Project Explorer 뷰를 보자) 이 유형은 콘텐츠 어시스트에 나타난다.

Select Element 대화상자가 가시성 규칙에 더 느슨함에 유의하자. 사실 Select Element 대화상자는 닫힌 모델과 (어떻게 호출되느냐에 따라) 유효한 선택이 아닐 수도 있는 요소마저도 보여줌으로써 작은 Project Explorer처럼 행동한다.

하지만 콘텐츠 어시스트는 현재 모델(요소가 있는 다이어그램이 아니라 현재 모델이 실제 요소의 위치와 관련이 있는 곳에서)과 가시성에 상관없이 임포트로 가능한 요소에서 유효한 선택을 보여준다. 유효한 선택인 한에서는 닫힌 모델과 파편에서의 요소 또한 보인다.

반면 인식되지 않은 유형에 접어든다면 그림 30처럼 즉시 초기 유형을 만들어야 할 것이다. 만들어진 유형은 모델의 루트에 있는 PrimitveTypes 패키지에 추가될 것이다. 이 패키지가 존재하지 않는다면 만들어진다.

Preferences 대화상자에서 Create New Type 대화상자를 설정하려면 Modeling > Miscellaneous 페이지의 알려지지 않은 유형이 들어올 때 자동으로 새 유형을 만든다는(Automatically create a new type when an unknown type is entered) 설정을 조절해 통제할 수 있다. 또한 그림 31처럼 환경설정 페이지에서 콘텐츠 어시스트 환경설정을 수정할 수 있다.

관계

Rational Software Architect의 이전 버전에서 관계를 설계하려면 다이어그램에 적어도 소스나 표적을 끌어다 놓고 관계 팔레트 도구나 커넥터 핸들을 사용해 관계를 그려야 했다. 또한 다이어그램에 요소가 있길 원하지 않으면 두 개의 요소와 관계를 지워야 했다.

Rational Software Architect V7.5에서는 다이어그램의 어떤 요소도 시각화할 필요 없이 관계를 모델링할 수 있다.

1. Project Explorer에서 관계의 소스 끝에 있을 객체를 위치시킨다.
2. 그러고 나서 Add UML, Relationship를 오른쪽 클릭, 선택한다.
3. 메뉴의 일반적인 관계 중 하나를 선택하거나 Advanced를 클릭할 수 있다. 어떤 방법을 사용하든 수정된 버전의 익숙한 Select Element 대화상자가 나타난다. 이는 관계의 표적 요소를 선택할 때 사용될 것이다. Advanced를 선택했다면 그림 32처럼 관계 유형을 선택하는 옵션을 갖게 된다.

팁: Add UML > Relationship 메뉴에 Advanced가 나타나지 않으면 UML Element Building Blocks에서 UML Relationship 3 기능을 사용 가능하게 하자.

대안으로 소스나 표적 요소를 선택하면 Properties 뷰에 새 Relationships 속성 탭을 볼 수 있다. 이 탭에서 새 관계를 만들도록 선택하고 관계의 표적 요소나 소스 요소를 선택할 수 있다(이는 선택된 요소가 소스 요소이고 표적 요소만을 선택한다고 가정하는 Add UML 메뉴와는 다르다). Relationships 탭은 또한 그림 33처럼 관계에 참여하는 요소를 보여준다. Navigate 버튼을 클릭하면 Project Explorer에서 선택된 관계를 볼 수 있을 것이다. 한편 Navigate to Related Element(s) 버튼을 클릭하면 Project Explorer에서 선택된 관계에 참여하는 다른 요소를 볼 수 있을 것이다.

모델 조각

조각에서 가장 확실한 변화는 Project Explorer의 패키지를 오른쪽 클릭할 때 그림 34처럼 Create Fragment와 Absorb Fragment 메뉴가 하위 메뉴로 이동한다는 것이다.

여기에 더해 Fragment All Sub-Packages와 Absorb All Sub-Fragments를 포함한 새 메뉴 아이템들을 발견할 것이다. 이것들을 통해 배치를 만들고 조각을 흡수할 수 있다. 이전에는 조각은 각각 만들어지거나 흡수됐다.

팁: 선택된 아이템은 Fragment All Sub-Packages와 Absorb All Sub-Fragments를 선택할 때 조각화되거나 흡수되지 않는다. 중첩된 자식 요소만이 조각화되거나 흡수된다.

위로

리팩터링

시퀀스 다이어그램의 포션을 InteractionUse로 리팩터링하는 것이 얼마나 간단해지는지 봤다. 또한 Rational Software Architect가 모델 무결성을 보존하기 위해 리팩터링하는데 동기화 내에서 모델 요소를 보관하는 게 얼마나 큰 도움이 되는지 봤다. 즉, 시퀀스 다이어그램에서 메시지 이름 업데이트하기와 Call Behavior Actions와 Call Operation Actions로 참조된 행위와 동작 이름을 사용하는 것이 그것이다. 하지만 Rational Software Architect V7.5에는 리팩터링에서 강화된 것이 몇 가지 더 있다.

리팩터링, 삭제하기

새로운 Delete 메뉴 아이템이 Project Explorer의 Refactor 팝업 메뉴에 추가됐다. Refactor > Delete는 닫힌 모델을 열고(삭제된 요소의 레퍼런스와 함께) 레퍼런스를 업데이트한다. 예를 들어 삭제된 요소를 참조하는 다이어그램 요소는 제거된다.

상세한 프리뷰와 강제적이지 않은 업데이트를 불가능하게 하는 기능

Rational Software Architect V7.5에서 리팩터링을 수행할 때(조각 만들기와 흡수하기 포함) 모든 영향을 받은 리소스를 나열하는 상세한 프리뷰가 나타난다. 어쩌면 더 중요하게는 그림 35처럼 이제 필수가 아닌 업데이트를 끄는 기능을 가지게 됐다. 이는 이전 버전처럼 전체 리팩터링 동작을 중단하는 것과 반대되는 것이다.

그러므로 이 프리뷰는 리팩터링이 수행돼야 하는지의 여부에 따라 경고 역할만을 하는게 아니다. 또한 팀 시나리오(모든 파일이 작성가능하지 않은)에서 필수 사항이 될 수 있는 특정 업데이트를 끄는 기능을 제공한다. 종속 파일(작성을 위한 접근이 안 되는)을 업데이트할 수 없을 때에도 리팩터링을 꼭 수행해야 하는 경우가 있을 수 있다. 예를 들어 외부 클라이언트를 부술 수 있다는 것을 알면서도 버전 사이에서 API를 변경해야 할 때가 그것이다.

조각 만들기와 흡수하기 참가자 추가하기

조각 만들기와 흡수하기용 커스텀 참여자(participant)가 이제 지원된다. 이는 이클립스의 리팩터링 참여자와 같다. API 사용에 관한 더 자세한 정보를 가지려면 그림 36처럼 File > New > Example 순으로 선택해 UML Modeler Plug-ins 카테고리에서 Fragment Participant Example을 선택한다.

팁: New Example 마법사에서 샘플을 볼 수 없으면 Installation Manager에서 Modeling Extensibility 컴포넌트를 설치하기 바란다.

위로

Rational Software Architect의 새로운 기능

더 큰 팀에서 작업하기 위해 모델 수리와 프로파일 애플리케이션 수리가 강화됐고 두 가지 모두 모델 일관성과 무결성을 확인하는 수단이 된다. 요소 임포트와 패키지 임포트를 제자리에서 확대하는 기능은 더 큰 팀에서 모델 공유 시나리오를 만들고 구현하는 데 있어 이전과는 비교가 안 될 정도로 향상됐다. 또한 리팩터링 프리뷰를 제공함으로써 어떤 변화가 부서지는 변화인지 식별하기 쉬워졌다. 특히 더 큰 팀에서 많은 낯선 모델을 작업하는 데 더욱 그렇다.

사용의 편리성에 있어 Modeling Working Set는 환경의 리소스를 능률화하는 데 도움이 된다. 어떤 요소가 주어진 소스를 타깃으로 할 수 있는지 명확히 나타냄으로써(또는 그 반대로) 다이어그램과 상관없이 애플리케이션으로 관계를 만드는 새로운 방법이 생겼다. 그루핑이 이제 지원된다. Activity 다이어그램이 강화돼 모든 이이 흐름과 핀의 UML 시맨틱에 관한 자세한 사항을 알지 않아도 되게끔 했다.

배열 지원이 향상됐다. 이제 타당한 실패에 맞는 유효성 규칙을 쉽게 인식하게 됐다. + 사인을 사용해 닫힌 모델을 신속하게 훑음으로써 모델 로드 시간도 빨라졌다. 콘텐츠 어시스트가 강화돼 임포트를 고려하게 됐고 유형 생성 기능이 추가돼 유형을 신속히 만들 수 있게 됐다. 거기에 시맨틱보다 작업 흐름에 더 집중하게 됐다.

Select Element 대화상자도 마찬가지다. 작업 흐름에 집중한다. 시퀀스 다이어그램의 복사 기능이 강화돼 다이어그램 편집이 쉬워졌다. 또 Explore 탭으로 요소간의 관계를 더 빨리 찾을 수 있다.

UML 명세와 호환을 위해 formal and actual gates가 시퀀스 다이어그램에서 지원되며 패키지를 루트 요소로 가지게 됐다.

일반적으로 강화된 사항은 다음과 같다.

• New Model 마법사의 확장 메커니즘이 향상됐다.
• 리치 텍스트 지원이 강화됐다.
• 이제 모델 예외와 다중값 속성이 가능해졌다.

여기에 메시지 이름, Call Behavior Actions Call Operation Actions가 강화돼 어쩔 수 없는 재시동이 시행될 때도 모델 동기화와 모델 무결성을 보존하기 쉬워졌다.

위로

감사의 말

이 글을 감수한 Dusko Misic과 Michael Hanner에게 고맙다는 말을 전한다.

참고자료

• developerWorks의 Rational 소프트웨어 영역을 방문해 Rational Software Delivery Platform 제품의 기술 자료와 모범 사례를 읽어보자.
  
  
• IBM developerWorks 뉴스레터를 구독해 최고의 developerWorks 튜토리얼, 글, 다운로드, 커뮤니티 활동, 웹 캐스트, 행사를 매주 업데이트 받자.
  
  
• developerWorks Rational 존 뉴스레터를 구독하자. developerWorks Rational 기사를 지속적으로 접하자. 2주에 한 번씩 Rational Software Delivery Platform에 관한 최신 기술 자료와 모범 사례를 업데이트 받을 것이다.
  
  
• Rational Edge 뉴스레터에 가입하여 효과적인 소프트웨어 개발의 기본 개념에 관한 글을 읽어보자.
  
  
• 기술 서점에서 다른 기술 주제에 관한 책을 찾아보자.
  
  
• Object Management Group의 UML 사이트에서 UML에 대해 더 배워보자.
  
  
• Authoring UML Profiles: Part 1을 읽어 UML 프로파일 정복에 관해 더 이해해 보자.
  
  
• Authoring UML Profiles: Part 2를 읽어 UML 프로파일 정복에 관해 더 이해해 보자.
  
  
• 이클립스에 대해 더 알아보자. org.eclipse.ui.newWizards 확장
  
  

• IBM Rational 소프트웨어의 시험판을 다운로드하자.
  
  
• IBM 제품 평가판을 받아 DB2®, Lotus®, Tivoli®, WebSphere®의 미들웨어 제품과 애플리케이션 개발 도구에 익숙해지자.
  
  

• 포럼, 블로그, 포드캐스트, 위키 등이 있는 developerWorks 커뮤니티에 참여해 보라.
  
  
• developerWorks의 Rational 포럼에 참여하자.

필자소개

		Wayne Diu는 IBM Rational의 소프트웨어 개발자로 Profile Integration 기능을 디자인, 구현하는 업무를 담당하고 있다. Browse Diagram 인프라스트럭처 같은 Rational Modeling Platform용으로 몇 가지 다른 기능을 개발해 왔고 메타 모델 통합 프레임워크의 플랫폼화를 담당한 개발자 중 하나였다. 또한 프린팅, 찾기 및 대체, 리팩터링 지원 같은 다른 기능의 다양한 컬렉션 작업도 해왔다.

기사에 대한 평가

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

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로