[펌] [안영회의 UML 강좌18] - Object Behavior-1

##########0*0 Object Behavior

2 .0 상태(State)

3 .0 상태 천이(State Transition)

4 .0 Statechart 상세화

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

##########2*
유스케이스(Use case)는 시스템 레벨의 행위(Behavior)를 표현한 것입니다. 유스케이스에서 출발해서 이들 행위를 달성해야 하는 시스템의 책임(Responsibility)을 객체들에 나눠주고 이들 간의 협력(Collaboration)이 모여서 시스템 레벨의 행위를 달성하게 되는 것이죠.

자, 시스템 레벨의 행위는 유스케이스에, 이를 세분화 시켜서 객체들의 집합이 보여주는 행위는 협력을 보여주는 시퀀스 혹은 협력 다이어그램(Collaboration Diagram)에 표현되었습니다. 그렇다면 더 낮은 수준의 분석은 필요가 없을까요?

결국 객체지향 기술에서 시스템을 이루는 단위는 ‘객체’입니다. 객체의 행위 수준까지 분석을 해야 한다는 것이죠. 이번 강좌는 객체의 행위에 대해 다루도록 하겠습니다.


Object Behavior

##########3*
그림 18-1. Statechart Diagram 만들기

유스케이스는 사용자와 시스템과의 상호작용 행위를 집약한 것입니다. 유스케이스는 결국 객체들이 메시지를 주고 받거나, 특정한 관계를 맺으면서 실현됩니다. 객체 사이에 오고 가는 메시지는 결국 객체 내부에서 어떠한 처리를 하게 됩니다. 따라서, 객체 내부에서 어떠한 행위를 필요로 한다는 것이죠.

이러한 행위는 객체 내부의 상태로 표현되는데 Statechart Diagram으로 나타냅니다. 그림 18-1은 Rose에서 Statechart Diagram 다이어그램을 만드는 순서를 나타냅니다. Statechart를 나타낼 클래스에서 오른쪽 마우스를 클릭한 후에 [New]-[Statechart Diagram]순으로 선택을 합니다.

객체의 모든 행위들에 대하여 Statechart Diagram을 그릴 필요는 없습니다. Statechart Diagram에 표현된 것들은 구현 과정에서 객체의 메소드내지는 함수의 알고리즘이 됩니다. 따라서, 간단한 행위에 대해 알고리즘을 다이어그램으로 표현할 필요는 없을 것입니다.

중요한 행위에 대해 Statechart Diagram를 표기하거나, 다른 타입의 클래스보다 상대적으로 이해하기에 어려운 컨트롤 클래스에 대해 다이어그램을 작성합니다. 또한, 집합연관(Aggregation)을 갖는 클래스에서 쓰기도 하죠. 요는 반드시 이해해야 하거나 이해하기 어려운 경우에 이를 돕는 것이라는 점이죠.

1 .0 Object Behavior

##########4*0 상태(State)

3 .0 상태 천이(State Transition)

4 .0 Statechart 상세화

##########5*

##########6*
상태(State)

상태(State)는 객체의 컨디션(condition)을 말하는데 이는 하나 이상의 속성 값으로 표현이 되죠. 쉬운 예로 전화기의 상태를 살펴 보면 ‘전화를 기다리는 상태(idle)’와 ‘전화기가 쓰이는 상태(active)’ 둘로 나눠 볼 수도 있겠죠.

##########7*
그림 18-2. 상태에 대한 UML 표기법

그림 18-2는 상태에 대한 UML 표기법입니다. 상태는 모서리가 둥근 직사각형으로 표현합니다. Rose에서 상태는 표현하는 일은 매우 간단합니다. 상태 아이콘을 선택하여 다이어그램에 놓일 위치를 클릭하면 되는 것이죠.

상태의 중요한 특성 하나는 상태는 객체가 주고 받는 메시지들 사이에서 표현된다는 점입니다. 가령, 전화기에 벨이 울리는 메시지가 있다고 합시다. 이 메시지를 받기 전과 후에는 상태가 변하겠죠?

또, 한가지 상태 중에는 복합 상태(Composite State)라는 것이 있는데 하나의 상태를 세부적인 상태들로 나눌 수 있는 경우를 말합니다. 더 자세한 것은 UML Specification 등을 참조하셔야 할 것 같네요. 무한정 이야기를 늘여 나갈 수는 없으니까요.^^;

1 .0 Object Behavior

2 .0 상태(State)

##########8*0 상태 천이(State Transition)

4 .0 Statechart 상세화

##########9*

##########10*
상태 천이(State Transition)

State Transition은 객체의 상태가 변화되는 것입니다. Transition은 전이(轉移)라고 번역되는 경우가 많은데, 전이란 원래 ‘자리를 이동한다’는 의미로 적합한 표현이 아닙니다. Transition을 굳이 우리말로 바꾼다면 ‘천이’ 혹은 ‘변이’와 같이 바꿀 수가 있겠죠. 그렇지만 중요한 것은 ‘천이’냐 ‘전이’냐가 아니라 Transition이 무엇이냐 하는 것이죠.

##########11*
그림 18-3 CourseOffering의 States와 State Transitions

상태 천이는 특정 액션 혹은 이벤트와 연관을 갖습니다. 상태를 변화시키는 요인이 무엇이냐 하는 것이죠. 그림 18-3은 수강 신청 예제의 CourseOffering(강좌) 클래스에 대한 State Transition을 표현한 다이어그램입니다.

1 .0 Object Behavior

2 .0 상태(State)

3 .0 상태 천이(State Transition)

##########12*0 Statechart 상세화

##########13*

##########14*
Statechart 상세화

그림 18-4는 Rose에서 State Transition을 상세하게 설명하는 사항을 나타내는 모습입니다. ‘이벤트 이름[감시 조건]/액션’ 혹은 ‘^클래스 이름.보내는 이벤트’의 형태로 표기합니다. Rose에서는 Transition에 대한 Specification 창에서 이벤트 이름은 General 탭의 Name 항목에 나머지 상세한 사항은 Detail 탭에 기술합니다.

##########15*
그림 18-4. State Transition Detail 나타내기

감시 조건은 Guard Condition 항목에, 액션은 Action 항목, 대상 클래스 이름은 Send target, 보내는 이벤트는 Send event 항목에 각각 기술하면 UML 표기법에 맞게 다이어그램에 표기됩니다.

여기에서 액션과 이벤트를 구분할 필요가 있겠네요. 액션은 전이가 일어날 때 나타나는 행위입니다. 가령, 위의 경우 세부적으로는 count를 0으로 만드는 액션이 일어났습니다. 그와 동시에 다른 클래스인 CourseRoster에게 create 메시지가 호출됩니다. 이러한 메시지 호출은 액션과 구분하여 이벤트라고 합니다. 여기서 또 혼돈이 올 수 있죠. 이들이 하나의 Transition에 따른 것이기 때문에 이들을 묶어서 표현할 이름이 필요한데 그것이 여기에서는 add student입니다.

마지막으로 State Transition뿐만 아니라 State도 더욱 세분화 하여 표기할 수 있습니다. State에 대한 Specification 창을 열면 Actions 탭이 있습니다. 여기에서 insert를 하여 State를 상세히 설명하는 액션이나 이벤트를 표기할 수 있습니다. insert 명령을 수행하면 디폴트로 On Entry 액션을 생성합니다. 이를 더블 클릭하면 그림 18-5와 같이 Action Specification 창이 뜹니다.

##########16*
그림 18-5. Action Specification Window

타입 옵션에서 Action과 Send Event 중에 하나를 선택할 수 있습니다. Name 항목에 액션이나 이벤트의 이름을 표기하고, 언제 이러한 행위가 일어날 지에 대해서는 네 가지 옵션을 선택할 수 있습니다. 각각의 세부 사항에 대해서는 UML User Guide나 UML Spec을 참고하세요.