[펌] [안영회의 UML 강좌14] - Behavior and Structure(2)

##########0*0 객체 사이의 메시지

2 .0 Operation 생성

##########1*

##########2*
지난 강좌에서는 객체의 behavior와 structure가 클래스에 어떤 영향을 미치는지를 살펴보고, behavior와 structure 각각에 대해 살펴 보았습니다. 찾아낸 behavior는 클래스의 operation을 생성하게 된다고 했죠. 마찬가지로 여러분들이 찾아낸 structure는 클래스의 속성이 되지요. 이번 강좌에서는 이들을 어떻게 만들어 내는지 살펴 보도록 하겠습니다.

객체 사이의 메시지

sequence diagram이나 collaboration diagram과 같은 객체의 상호작용을 표현한 다이어그램에 나타나는 메시지는 일반적으로 메시지를 받는 객체의 operation이 되는 경우가 많습니다. 전에도 언급했었지만 이러한 상호작용은 메시지를 보내고 받는 일로 이뤄지는데 메시지를 보내는 일이란 받는 객체의 operation을 호출하는 것이 되죠.

##########3*
그림 14-1. 메시지를 보내고 받는 객체의 표현

그러나, interaction diagram에 나타나는 모든 메시지가 operation이 되지는 않습니다. 일반적으로 Boundary 클래스와 액터가 주고 받는 메시지는 객체 사이의 메시지와는 구분해서 다룰 필요가 있습니다.

액터가 사람인 경우와 연동 시스템인 경우로 나눠서 살펴 봅시다. 우선, 액터가 사람인 경우에는 메시지는 액터가 GUI 콘트롤을 선택하는 경우가 일반적입니다. 가령, 로그인 하는 경우를 생각해 보면 액터가 자신의 ID와 패스워드를 타이핑하고 ‘확인’과 같은 버튼을 누르는 것으로 메시지 전달이 되지요.

이런 경우는 메시지가 operation이 되지 않고, 사용자가 버튼을 누르는 것이 메시지 전달이 되는 것이죠. 따라서, operation이 되는 것이 아니라 사용자 매뉴얼 같은 곳에 기록해두어야 합니다.

##########4*
그림 14-2. 액터와 객체 사이의 메시지 교환

그렇다면 액터가 연동하는 시스템인 경우는 어떻게 될까요? 대부분의 경우 이종의 시스템은 다른 메커니즘을 갖게 됩니다. 즉, 작동 방식이 틀리게 되는 것이죠. 따라서, 프로토콜이 다른 경우가 대부분입니다. 이러한 경우는 메시지가 프로토콜을 처리하는 클래스가 됩니다. 프로토콜 처리기(Protocol Handler)가 필요한 것이죠. 이미 Boundary 클래스를 뽑아내면서 프로토콜 처리기를 뽑아낸 경우는 예외가 되겠죠.

1 .0 객체 사이의 메시지

##########5*0 Operation 생성

##########6*

##########7*
Operation 생성

Operation 역시 자연어를 이용한 작명을 하기 때문에 이름을 지을 때 신중한 것이 좋습니다. 개발팀 사이에서 일정한 네이밍 룰(Naming Rule)은 정하는 것이 좋겠죠. 객체지향 언어에서 쓰이는 일반적인 네이밍 컨벤션(Naming Convention)은 여기서 언급하지 않겠습니다. 그 외에 두 가지 사항 정도를 염두에 두시길 바랍니다.

첫째는 operation은 클래스의 멤버이기 때문에 해당 클래스가 수행하게 되는 것입니다. 따라서, 해당 클래스의 입장에서 능동 표현이 되어야 적합합니다. 클래스가 무엇 무엇을 해야 한다는 식이면 곤란하다는 것입니다. 또한, operation은 명사보다는 동사 표현이 적합하겠죠? 동사, 동사구나 동사+목적어 형태가 적절할 듯 하네요.

둘째로 operation은 구현 내용을 반영하는 이름은 적절하지 않습니다. 구현은 자주 변할 수 있기 때문이죠.

##########8*
그림 14-3 Operation 만들기

그림14-3에서 보는 바와 같이 메시지를 선택한 후 오른쪽 마우스를 클릭하면 팝업 메뉴에서 이라는 옵션이 나타납니다. 주의하실 점은 메시지를 나타내는 화살표나 메시지의 이름은 선택하셔야지, 객체 사이를 잇는 링크를 선택하면 해당 옵션이 나타나지 않는다는 점입니다.

##########9*
그림 14-4 Operation 만들기

옵션을 선택하면 그림 14-4과 같이 specification window가 나타납니다. 이제 적절한 이름을 입력합니다. Operation을 만드는 것은 collaboration diagram에서는 물론이고 sequence diagram에서도 가능합니다.

Collaboration diagram이나 interaction diagram을 보고 operation을 찾아내는 방법을 “Collaboration”을 이용한 유스케이스의 Realization이라고 합니다. 사용자가 원하는 유스케이스를 통해서 클래스를 찾고, 클래스의 속성과 행위를 찾겠다는 접근 방식이죠.

그러나, 때로는 업무의 분석과 설계 과정에서 직관적으로 operation을 찾아낼 수도 있습니다. 그런 경우는 그림 14-5와 같이 브라우저에서 해당 클래스를 더블클릭하여 specification window를 나타낸 후 operation을 입력할 수도 있습니다.

##########10*
그림 14-5 Class Specification 창에서 operation 추가하기

이렇게 생성한 operation은 interaction diagram에 묘사되는 메시지와 연관을 갖지 않습니다. 직관적으로 뽑아낸 operation을 특정 메시지와 연결시키는 일은 간단합니다. 메시지를 받는 클래스에 operation을 갖고 있는 경우 메시지에서 오른쪽 마우스 클릭을 할 때 팝업에 해당 operation이 나타납니다.

##########11*
그림 14-6 operation과 메시지의 연결

무결성 유지를 위해서는 메시지와 연결이 안 되는 operation이 없어야 올바른 모델링이라는 생각이 언뜻 떠오를 수도 있겠죠. 그러나, 반드시 모든 operation이 메시지와 연결될 필요는 없습니다. 편의를 위해 객체 내부에서 사용되는 operation 들도 있으니까요.