[펌] [안영회의 UML 강좌15] - Behavior and Structure (3)-1

##########0*0 Operation 상세화

2 .0 속성 추가하기

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

##########2*
지난 강좌에는 Operation을 찾아내는 것까지 살펴 보았습니다. 이어서 Operation에 대해 좀 더 알아본 뒤에 Attribute를 추가하는 것을 살펴 보도록 하죠.


Operation 상세화

객체 간에 오고 가는 메시지는 결국 서비스를 하는 Operation이 됩니다. 향후에 응용 프로그램의 기능도 결국을 이들 객체 사이에서 호출하거나 호출 되는 Operation을 기반으로 제공되는 것이죠. 반면에 객체 내부에서 사용할 목적으로 쓰이는 Operation도 있었습니다.

여기까지의 단계에서는 매우 추상적으로 Operation을 찾아낸 것이죠. 이러한 Operation을 점차 구체화 시키는 과정이 차츰차츰 반복됩니다.(Iterative Development!!) 상세화는 보통 두 가지를 생각해 볼 수 있습니다.

첫째는 Operation에 대한 설명을 기술하는 것이고, 둘째는 Operation Signature를 정의하는 것이죠. Operation Signature란 Operation의 이름과 입출력 데이터 들을 함께 가리키는 말입니다.

##########3*
그림 15-1. 브라우저의 Operation

먼저 Operation에 설명을 기술하는 것을 배워보죠. Rose에서 Operation에 설명을 기술하는 것은 다른 모델링 요소의 경우와 일치합니다. 그림 15-1에 보이는 것처럼 브라우저에서 Operation을 선택하고, 오른쪽 마우스를 클릭하면 나타나는 메뉴에서 Open Specification을 선택합니다. Operation을 더블클릭해도 동일한 효과를 냅니다.

##########4*
그림 15-2. Operation Specification Window

그림 15-2는 Operation Specification Window의 모습입니다. Documentation에 설명을 기술합니다. 설명을 기술할 때 유의할 점은 해당 Operation이 무엇(What)을 해야 하는지를 명시해야 합니다. Operation의 목적을 잃어버리지 않기 위한 것이죠.

기술적인 백그라운드를 가진 개발자들이 가장 오류를 범하기 쉬운 부분이 바로 분석 과정에서 “기술 지향적(Technology-Oriented) “으로 문제를 바라볼 수 있다는 점입니다. 그럴 경우에 자꾸 근원적인 문제를 해결하는 쪽이 아니라 자꾸만 소스코드를 향해 달려(?) 가려고 하기 쉽다고 많은 전문가들이 지적을 하더군요.

Operation의 설명을 기록하는 과정에서도 기술 지향적인 개발자들은 입출력 값을 중요시 여겨 이것만 기록하려고 하기도 합니다. 그러나, 입출력 값은 Operation Specification Window에서 이를 적절히 정의할 수 있는 곳이 존재합니다. Operation은 입력 값은 Arguments의 형태를 띄어 Detail Tab에서 찾아볼 수 있고, 출력 값은 그림 15-2에서 나타나는 Return Type에서 선택이 가능합니다. 물론, 편의상 입출력 값을 기술할 수 있습니다만 중요한 것은 Operation이 무엇을 하기 위한 것이냐는 질문에 대한 대답이 Documentation에 꼭 기술되어 있어야 한다는 사실이죠.

이번에는 Operation의 Signature를 어떻게 찾아내는지 살펴 보도록 하겠습니다. 물론 Operation Signature를 직관적으로 도출할 수도 있습니다. 경험이 많은 개발자이거나 익숙한 도메인에서 수행하는 개발인 경우에는 이러한 일이 많겠죠.

그러나, 그렇지 못한 경우에는 클래스의 Relationship이 도움을 줍니다. 개발이 진척되면서 Relationship도 정제(refinement)되는 과정을 거치게 되죠. 그러면서 Relationship은 일반화 혹은 상속 관계가 되는 경우가 아닌 경우에는 대부분 Operation Signature의 많은 부분을 보여줍니다.

##########5*
그림 15-3. System Architecture를 바라보는 4+1 View

객체지향 분석 및 설계 과정에서 가장 힘든 것 중에 하나가 바로 ‘딱딱 떨어지지’ 않는다는 점입니다. 복잡한 산수 계산을 할 때에도 딱딱 맞아 떨어지는 경우는 수월한데 나누기 했더니 몫이 소수점 몇 자리까지 내려가고 하면 골치가 아픕니다. 과거의 방법론이나 기술은 딱딱 떨어지게끔 만들어졌습니다. 방법론만 해도 객체지향 방법론에 비하면 따라 하기 수월했었죠. 그런데 그러한 기술이나 개방 방법론으로는 매우 복잡한 문제를 해결하는데 한계가 보였다고 합니다.

그래서, 객체지향 기술이 나왔고, 이에 맞는 방법론이 등장했죠. 객체지향 방법론에서는 ‘두루두루 둘러봐서’ 알아내는 전략을 취합니다. 그림 15-3는 Rational의 Philippe Krutchten이 복잡한 시스템을 바라보는 관점으로 제시한 ‘4+1 Model View’입니다.

복잡한 문제는 한가지 관점으로만 봐서는 해결이 안 된다는 논리죠. 동의 하시나요? 현행범을 잡은 경우에 형사는 고민을 하지 않지만, 미지에 빠진 사건을 조사하는 형사는 다양한 관점에서 사건을 바라보게 되죠.

일단 사건 현장을 조사하며 단서를 찾기도 하고, 목격자의 진술을 들어보기도 하고, 법의학의 도움을 받기도 하죠. 용의자가 나타나면 심문을 하기도 하지만, 과거의 범죄 기록을 살피기도 하죠.

소프트웨어 역시 매우 복잡한 경우에는 다양한 관점을 동원함으로써 한쪽에서 못 봤던 것을 다른 관점으로 바라보면서 발견해낼 수 있습니다. 여기서 이 얘기를 왜 장황하게 늘어놓느냐고 물으실 분들이 계실지 모르겠네요.

Operation을 살피다가 돌연 클래스의 Relationship을 논하는데 마치 점프를 하는 느낌을 받으실 분들이 계실 듯 해서죠. 동적인 성향의 Sequence Diagram에서 메시지를 찾아낸 것을 정적인 클래스에 다시 적용시키게 되는 것처럼 다양한 관점을 아울러서 개발이 진척되는 것을 이해하시라는 의도입니다.

저도 이 부분이 가장 이해하기 힘들었고, 많은 분들이 이 부분을 가장 힘들어 하십니다만 객체 지향 분석과 설계의 묘미는 공교롭게도 바로 여기에 있는 듯 합니다. 복잡한 일을 다양한 관점을 통해 바라봄으로 해서 해결한다. 그러나, 최종 산출물은 단일한 결과로 존재해야 합니다. 다양한 관점의 이면에는 통합성(Integration)이 존재한다는 것 또한 잊으시면 안됩니다.

1 .0 Operation 상세화

##########6*0 속성 추가하기

##########7*

##########8*
속성 추가하기

속성은 Operation처럼 Sequence Diagram이나 여타 다이어그램에 명시적으로 드러나지는 않습니다. 오히려 여기저기 많이 산재해 있죠. 해당 업무를 잘 이해해야만 속성을 제대로 뽑아낼 수 있는데 그런 면에서 쉬운 일은 아니죠. 요구사항을 정의한 문서들이나 이벤트의 흐름을 기술한 시나리오 내지는 이를 다이어그램으로 표현한 Activity Diagram 등이 좋은 소스가 될 수 있겠죠.

##########9*
그림 15-4. 클래스에 속성(Attribute) 추가하기

클래스에 속성(attribute)을 추가하는 방법에도 여러 가지가 있습니다. 우선 브라우저에서 클래스를 선택한 후 그림 14-1와 같이 팝업메뉴에서 [New]-[Attribute] 순으로 선택한 후에 이름을 입력하여 생성할 수도 있습니다. 다른 방법으로는 클래스를 더블 클릭하여 나타나는 Class Specification Window에서 Attributes탭을 선택한 뒤에 추가하는 방법도 존재합니다.