그냥 그런 블로그

UML basics Part II: The activity diagram

원문링크 : https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep03/f_umlbasics_db.pdf

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

주의 : 번역이 개판이므로 이상하면 원문을 참조하십시오.

2003 년에, Rational Edge 는 IBM 글로벌 서비스의 도날드 벨( Donald Bell ) 이 작성한 새로운 아티클 시리즈를 소개했는데, 그것은 UML Basics 라고 합니다. 이 시리즈의 목적은 독자들이 UML 의 대부분을 구성하는 주요 다이어그램에 익숙해지도록 돕는 것입니다. 파트 1 은 이 다이어그램들에 대한 일반적인 개관을 제공했습니다; 이번 달에는, 활동( activity ) 다이어글매에 대한 세부 사항에 대해서 다루는데, 이 다이어그램은 완전한 UML v1.4 표기 집합을 포함하고 있습니다.

활동 다이어그램의 목적

활동 다이어그램의 목적은 큰 활동의 일부인 액션들의 절차적 흐름을 모델링하는 데 있습니다. 유스 케이스가 제출된 프로젝트에서, 활동 다이어그램들은 특정 유스 케이스를 좀 더 세부적인 레벨에서 모델링할 수 있습니다. 그러나 활동 다이어그램들은, 콘서트 티킷을 구입하거나 단과 수업을 등록하는 것과 같은, 비즈니스-레벨 기능들을 모델링하기 위해 유스 케이스들과는 독립적으로 사용될 수 있습니다. 활동 다이어그램들은, 티킷 예약 데이터 마트가 공동 세일즈 시스템의 데이터 웨어하우스를 덧붙이는 방식과 같은, 시스템-레벨 기능들을 모델링하는데 사용될 수도 있습니다.

그것은 절차적인 흐름을 모델링하기 때문에, 활동 다이어그램은 실행을 위한 액션 시퀀스와 그러한 액션들을 유발하거나 보호하는 상태들에 초점을 맞춥니다. 또한 활동 다이어그램은 활동의 내부 액션들에만 초점을 맞춥니다. 그것들의 처리 흐름에서 활동을 호출하는 액션들이나 특정 이벤트와 관련해 활동을 유발하는 액션들에는 관심을 두지 않습니다( 4월 13일 12:30 이며, 그룹의 섬머 투어를 위한 그린 데이 티킷들을 이제 판매한다 ).

UML 시퀀스 다이어그램들이 활동 다이어그램과 동일한 정보를 보여 주기는 하지만, 나는 개인적으로 활동 다이어그램들이 비즈니스-레벨 기능들을 모델링하는 것에 있어 최고라는 것을 발견했습니다. 왜냐하면, 활동 다이어그램은 활동에 있어서의 모든 잠재적인 시퀀스 흐름들을 보여 주기 때문입니다. 반면에 시퀀스 다이어그램은 보통 활동에 대한 하나의 흐름만을 보여 줍니다. 또한, 비즈니스 매니저와 비즈니스 인사 과정( process personnel )은 시퀀스 다이어그램들 보다는 활동 다이어그램을 선호하는 것처럼 보입니다 -- 활동 다이어그램은 보기에 덜 "기술적"이며, 그래서 비즈니스를 하는 사람들에게 겁을 덜 줍니다.게다가, 비즈니스 매니저들은 흐름 다이어그램들을 보는 것에 익숙해서, 활동 다이어그램의 "외형"에 친숙합니다.

표기( notation )

활동 다이어그램의 표기는 상태차트 다이어그램과 매우 유사합니다. 사실, UML 명세에 따르면, 활동 다이어그램은 상태차트 다이어그램의 변종입니다. 그래서 만약 당신이 상태차트 다이어그램에 익숙하다면, 활동 다이어그램 표기법을 이해하는데 한 다리 걸치게 된 것이며, 아래에서의 많은 논의들이 당신에게는 리뷰가 될 것입니다.

기본

먼저, 활동 다이어그램에서 액션 요소를 살펴 봅시다. 이것의 공식 UML 이름은 액션 상태( action state )입니다. 내 생각에는 사람들이 그것을 액션 상태라고 부르는 경우는 거의 없는 것 같습니다; 보통 액션이나 활동이라고 부릅니다. 이 기사에서, 나는 그것을 항상 액션이라고 부르도록 하겠습니다. 그리고 활동이라는 개념은 활동 다이어그램에 의해서 모델링되고 있는 전체 작업을 부를 때만 사용할 것입니다. 이러한 구분은 내 설명을 더 이해하기 쉽게 만들어 줄 것입니다.

활동 다이어그램에서의 액션은 "캡슐" 모양에 의해 표시됩니다 -- 왼쪽과 오른쪽 끝에 반쪽 원들을 가지고 있는 사각형 개체입니다( Figure 1 참조 ). 내부의 텍스트는 액션을 가리킵니다( 예를 들어 "사용자가 티킷 사무소에 전화를 겁니다" 혹은 "등록 사무소가 문을 엽니다" ).

Figure 1: 활동 다이어그램의 일부인 샘플 액션.

활동 다이어그램들은 액션의 시퀀스를 보여 주므로, 그것들은 반드시 시퀀스의 시작 지점을 표시해야 합니다. 활동 다이어그램 시작 지점의 공식 UML 이름은 초기 상태( initial state )입니다. 그리고 그것은 액션 시퀀스를 읽기 시작할 위치입니다. 초기 상태는 채워진 원으로 그려지는데, 활동의 액션 시퀀스에서 처음 액션과 연결하는 전이 라인( transition line, 화살표 )를 가지고 있습니다. Figure 2 는 활동 다이어그램의 초기 상태가 어떻게 생겼는지 보여 줍니다. UML 명세는 활동 다이어그램에서 초기 상태의 위치를 지정하지는 않습니다만, 보통은 당신의 다이어그램의 좌상단 코너에 있는 첫 번째 액션에 배치되는 것이 가장 쉽습니다.

Figure 2: 초기 상태는 활동 다이어그램의 액션 시퀀스를 위한 시작 지점을 명확하게 보여 줍니다.

활동 다이어그램에는 하나만의 초기 상태만 존재할 수 있으며, 초기 상태와 연결되는 하나만의 전이 라인만 존재할 수 있다는 것을 기억하는 것이 중요합니다. 활동 다이어그램이 하나만의 초기 상태를 가질 수 있다는 것이 명확해 보임에도 불구하고, 애매한 상황들이 있습니다 -- 이름하여, 비동기 액션 시퀀스의 시작. 이 상황들은 활동 다이어그램에서 새로운 초기 상태가 표시되어야 함을 암시할 수도 있습니다. Figure 3 은 잘못된 활동 다이어그램의 예를 보여 줍니다. 왜냐하면 그것의 초기 상태가 두 개의 액션들을 가리키는 두 개의 전이 라인을 가지기 때문입니다.

Figure 3: 활동 다이어그램에서 초기 상태의 잘못된 렌더링. 초기 상태는 단지 하나의 액션만을 지목할 수 있습니다.

화살표가 가리키는 방향과 함께, 활동 다이어그램의 전이 라인들은 모델링된 활동에서의 액션의 연속된 흐름을 보여 줍니다. 화살표는 항상 활동 다이어그램 시퀀스에서의 다음 액션을 가리킵니다. Figure 4 는 완전한 활동 다이어그램을 보여 주는데, 고객이 콘서트 티킷을 예약하는 방법을 모델링합니다.

Figure 4: 이해하기 쉬운 액션 시퀀스를 만드는 완전한 활동 다이어그램.

Figure 4 의 샘플 활동 다이어그램은 "콘서트 티킷 예약하기" 활동을 기술하는데, 다음과 같은 순서로 액션을 실행합니다:

1. 고객이 티킷 사무소에 전화를 겁니다.
2. 티킷 판매 대리인( Ticket rep )은 그 사람이 어떤 이벤트를 위한 티킷을 원하는지 묻습니다.
3. 고객이 대리인에게 선택한 이벤트를 말해 줍니다.
4. 대리인이 이용 가능한 좌석과 가격을 고객에게 말해 줍니다.
5. 고객이 선택한 좌석을 대리인에게 말해 줍니다.
6. 대리인이 좌석을 예약합니다.
7. 대리인이 신용 카드와 청구 주소에 대해 묻습니다.
8. 고객이 요구된 정보를 제공합니다.
9. 대리인이 신용 카드를 결제합니다.
10. 대리인이 티킷을 우편으로 보냅니다.

위의 액션 순서는 다이어그램에서 명확합니다. 왜냐하면 다이어그램은 초기 상태( 시작 지점 )를 보여 주고, 그 지점으로 부터 사람들은 전이 라인을 따라서 그것들이 연결된 활동들의 액션을 따라갈 수 있기 때문입니다.

활동의 흐름은 시퀀스에서 마지막 액션의 전이 라인이 "최종 상태" 심볼과 연결될 때 끝납니다. 그 심불은 과녁모양입니다( 채워진 원을 둘러싼 원 ). Figure 4 에서 보이듯이, "Ticket Rep Mails Tickets" 액션은 최종 상태 심볼과 연결되며, 그것은 활동의 액션 시퀀스가 끝에 도달했음을 지시합니다. 모든 활동 다이어그램은 적어도 하나의 최종 상태 심볼을 가집니다; 그렇지 않으면, 독자들은 어디에서 액션 시퀀스가 끝나는지 불명확하게 느낄 것이며, 혹은 활동 다이어그램이 여전히 작동중이라고 간주하게 될 것입니다.

활동 다이어그램이 여러 개의 최종 상태를 가지는 것이 가능합니다. 활동 다이어그램에서 단 하나만 존재해야 하는 초기 상태 심볼과는 다르게, 최종 상태 심볼은 로직 내의 많은 가지들 중의 하나의 끝을 표현할 수 있습니다 -- 다시 말해, 활동 다이어그램은 여러 가지 방식으로 끝날 수 있습니다.

기본의 너머에

우리는 활동 다이어그램의 기본 표현 요소들에 대해 다뤄왔지만, 이 유형의 다이어그램에 배치될 수 있는 더 많은 표현 요소들이 여전히 존재합니다. Figure 4 의 다이어그램이 기술적으로는 완전하지만, Figure 4 에서 모델링된 활동은 매우 단순합니다. 보통, 실제 소프트웨어 개발 프로젝트에서 모델링되는 활동들은 어떤 액션들을 취할지를 제어하는 결정 지점( decision point )들을 포함합니다. 그리고 가끔은 활동들이 병행적인 액션들을 가집니다.

결정 지점( decision points )

일반적으로, 결정은 활동 전반에서 필요한데, 특정한 이전 액션의 출력에 의존합니다. 그러한 경우에 활동 다이어그램을 생성하면서, 당신은 두 개 이상의 서로 다른 액션 시퀀스를 모델링할 필요가 있을 것입니다. 예를 들어, 중국 배달 음심을 주문할 때, 나는 중국 음식 배달원에게 전화를 겁니다. 그리고 내 전화 번호를 줍니다. 그리고 내가 이전에 음식을 주문한 적이 있다면 그의 컴퓨터가 자동적으로 내 주소를 출력해 줄 것입니다. 하지만 내가 처음 전화를 건 새로운 고객이라면, 그는 내 주문을 받기 전에 내 주소를 획득해야 할 것입니다.

UML 명세는 결정을 모델링하기 위해, 아래와 같이 두 가지 방식을 제공합니다.

첫 번째 방식은 액션에서 나오는 단일 전이 라인을 표시하고, 그것을 결정 지점과 연결하는 것입니다. UML 명세는 결정 지점을 결정( decision )이라고 부릅니다. 그리고 그것은 활동 다이어그램에서 다이아몬드 모양으로 그려집니다. 결정은 적어도 두개의 서로 다른 출력을 가질 것이므로, 결정 심볼은 서로 다른 액션들과 연결되는 다중 전이 라인들을 가질 것입니다. Figure 5 는 결정을 포함하는 샘플 활동 다이어그램의 일부를 보여 줍니다.

Figure 5: 결정 지점은 액션 시퀀스 내에서 생성되어야만 하는 선택을 모델링합니다.

Figure 5 에서 보이듯이, 결정 지점에 포함된 각 전이 라인은 반드시 "가드 조건( guard condition )"을 지시하기 위해서 위와 같은 텍스트에 의해서 레이블링되어야만 합니다. 이는 보통 guards 라고 발음됩니다.

가드 조건 텍스트는 항상 대괄호 내에 배치됩니다 -- 예를 들어 [ 가드 조건 텍스트 ] 입니다. 가드 조건은 전이 조건이 다음 액션으로 언제 이동할 지를 명시적으로 말해 줍니다. Figure 5 의 결정 지점에 따르면, 바텐더( 사용자 )는 단지 고객이 술을 주문할 때 "사용자가 적어도 21 살인지 확인한다" 만을 필요로 합니다. 만약 고객 주문이 다른 종류의 음료를 주문하면( "else" 조건 ), 바텐더는 그냥 고객에게 드링크를 제공하기만 하면 됩니다. 활동 다이어그램에서 [else] 가드는 보통 "만약 다른 가드된 전이 라인들이 실제 조건과 일치하는 것이 없을 때" 를 의미하기 위해서 사용되며, [else] 전이 라인을 따라 가게 됩니다.

병합 지점( merge points )

Figure 6 의 "고객 나이 >= 21" 에서 볼 수 있듯이, 가끔은 한 조건 경로로부터의 절차적 흐름이 다른 조건 경로로 다시 연결됩니다. 이러한 경우에, 우리는 두 개 이상의 액션 경로들을 다중 경로들이 그것을 가리킬 때 사용했던 것과 동일한 다이아몬드 아이콘을 사용해 연결합니다. 그렇지만 그것으로 부터 나오는 전이 라인은 하나 뿐입니다. 이는 결정 지점을 가리킨다기 보다는, 병합( merge )을 가리킵니다.

Figure 6 은 Figure 5 와 같은 결정을 보여 주지만, Figure 6 은 그 활동 다이어그램을 확장합니다. 고객의 나이에 대한 검사를 수행하는 것은 사용자를 두 번째 결정으로 유도합니다; 만약 고객이 21 살 보다 어리다면, 바텐더는 고객에게 다른 비알콜 음료를 주문하라고 말해야만 하며, 그것은 "Customer Orders Drink" 액션으로 시퀀스를 되돌립니다. 그러나 만약 고객이 21 살 이상이라면, 우리 액션 시퀀스는 비알콜 드링크를 주문했을 때 바텐더가 따라야 하는 것과 동일한 액션을 취하게 됩니다: "Get Drink For Customer".

Figure 6: 부분 활동 다이어그램, 

두 개의 결정 지점( "Drink is alcoholic" 과 "Customer's age < 21" )과 하나의 병합 지점( "else" 와 "Customer's age >= 21" )을 보여 줍니다.

대안적인 접근

결정을 모델링하는 두 번째 접근법은 Figure 7 에서처럼 액션의 결과로 다중의 전이 라인을 가지는 것입니다. 만약 이 기법이 사용되면, 액션으로부터 나오는 전이 라인은 첫 번째 접근법의 결정처럼( 예를 들어 다이아몬드 심볼 ) 반드시 가드 레이블을 그 위에 가져야만 합니다. 결정 심볼에 적용되는 모든 규칙이 액션 외부에서 모델링되는 결정들에 적용됩니다. 갱니적으로, 나는 이 접근법을 추천하지 않습니다. 왜냐하면 나는 결정에 대한 가시적인 대기열을 선호하기 때문입니다. 그렇기는 하지만 UML 1.4 명세는 Figure 7 에서 볼 수 있듯이 이 접근법을 허용하며, 완결성을 높이기 위해서 여기에서 그것을 언급했습니다.

Figure 7: 나는 이 접근법을 선호하지는 않지만, UML 1.4 명세는 가드 조건들을 사용해 결정을 액션처럼 모델링하는 것을 허용합니다.

만약 당신이 이 접근법을 사용한다면, 반드시 다중 액션 시퀀스를 단일 시퀀스로 병합해야만 합니다. 이를 위해서, 당신은 특정 액션 시퀀스 내의 마지막 전이 라인을 시퀀스가 다시 시작되는 곳에 연결합니다. Figure 7 에서, "Tell Customer to order a non-alcoholic drink" 로부터의 전이라인이 "Customer orders drink" 로 되돌아 가는 것을 보여 줍니다.

Figure 8: 결정을 모델링하는 두 번째 접근법.

비동기 액션( asynchronous actions )들을 위한 동기화 상태( synch states )

활동을 모델링할 때, 가끔 병행적으로나 비동기적으로 수행될 수 있는 액션 시퀀스들을 보여 줘야 할 필요가 있습니다. 특별한 표기 요소가 병행 액션 시퀀스들을 보여 줄 수 있도록 합니다. 공식적인 이름으로는 동기화 상태( synch states )인데, 그것이 활동 흐름의 동기화 상태를 가리키기 때문입니다. 동기화 상태는 실행 스레드의 분기( forking )와 결합( joining )을 허용합니다.명확함을 위해 언급하자면, 액션을 두 개 이상의 스레드로 분기시키는 동기화 상태는 ( 비동기 액션들인 ) 비동기화( de-synchronizing )를 표현하며, 액션들을 다시 결합하는 동기화 상태는 동기화된 흐름으로의 복귀를 표현합니다. 동기화 상태는 굵은 채워진 라인으로 그려지는데, 전이 라인이 ( 보통 ) 그것의 왼쪽으로 들어 오며, ( 보통 ) 오른쪽으로 나갑니다. 액션 시퀀스를 다중 스레드로 분기시키는 동기화 상태를 그리기 위해서는, 먼저 병행 시퀀스에 앞서 액션으로부터의 전이 라인을 동기화 상태에 연결합니다. 그리고 나서 두 개의 전이 라인을 동기화 상태로부터 뽑아서, 각각을 자신의 액션에 연결합니다. Figure 9 에서 실행의 분기를 보여주는 활동 다이어그램의 일부분입니다.

Figure 9: 굵은 채워진 라인은 동기화 상태를 가리키는데,

두 개 이상의 액션 시퀀스가 병행적으로 처리되는 것을 허용합니다.

Figure 9 에서 보여준 예제에서, "Receive Order" 액션이 완료된 후에, 두 개의 스레드들이 병행적으로 수행됩니다. 이는 시스템이 "Verify Ordered Products Are In Stock" 액션과 "Verify Customer Has Available Credit" 액션을 동시에 처리할 수 있도록 해 줍니다.

실행을 다중 스레드로 분기시킬 때, 보통 나중의 처리를 위해서 특정 지점에서 그것들을 다시 합쳐야 합니다. 그러므로, 동기화 상태 요소는 다중 스레드들이 단일 스레드로 결합되는 것을 표현하는데 사용되기도 합니다. Figure 10 은 두 개의 스레드가 하나의 스레드로 결합되는 활동 다이어그램의 일부분을 보여 줍니다.

Figure 10: 병행 액션 시퀀스가 종료될 때, 동기화 상태( 굵은 라인 )이 사용되는데,

이는 다중 스레드가 다시 단일 스레드로 결합되는 것을 지시합니다.

Figure 10 에서, "Verify Ordered Products Are In Stock" 액션과 "Verify Customer Has Available Credit" 액션은 Figure 9 에서 보여 준 것이며, 이는 처리가 완료된 것입니다. 그리고 "Accept Order" 액션이 처리됩니다. 단일 전이 라인이 동기화 상태로부터 나오는 것은 이제 단지 하나만의 실행 스레드가 존재한다는 것을 의미한다는 것을 기억하십시오.

동기화 상태는 활동에서의 전체적인 액션 실행에서 동기화 지점으로서 사용될 수도 있습니다. 이 경우에, 그것은 개별 스레드들이 그 이후의 실행이 진행되기 이전에 강제로 결합되는 방식을 모델링합니다. Figure 11 은 동기화 지점으로서 동기화 상태를 사용하는 활동 다이어그램의 일부분을 보여 줍니다.

Figure 11: 동기화 지점으로서 동기화 상태를 사용함.

추상적이기는 하지만, 나는 Figure 11 의 다이어그램은 동기화 상태가 동기화 지점으로 사용되는 방식을 쉽게 이해하게 해 주는 방식을 제공한다고 생각합니다. 이를 이해하기 위해서, 활동 시퀀스를 여기에서 명확하게 해 봅시다. 활동은 하나의 스레드에서 모든 액션들을 시작합니다. 그리고 "Main Thread Action XXX" 액션이 실행될 때, 활동은 세 개의 스레드로 분리되며 병행적으로 실행됩니다. 첫 번째 스레드에서, "Thread 1 Action 1" 이 실행되고, 그리고 나서 "Thread 1 Action 2" 이 실행됩니다. 이 첫 번째 스레드가 실행되는 것과 동시에, 두 번째 스레드와 세번째 스레드가 실행됩니다 -- 각각 "Thread 2 Action 1" 과 "Thread 3 Action 1" 입니다. 두 번째 동기화 상태를 가짐으로써( Figure 11 의 오른쪽에 있는 것, 역주 : 아래쪽인듯 ), 우리는 더 진행하기 전에 "Thread 1 Action 2", "Thread 2 Action 1", "Thread 3 Action 1" 이 완료될 때까지 기다립니다. 모든 이전 액션들이 수행되면, 오른쪽 동기화 상태는 이전 세 스레드들을 동기화합니다. 그리고 나서 두 개의 스레드가 분기되고, 이 스레드들에서 두 액션들이 병행적으로 실행됩니다.

이제, 이 예제에서 가장 중요한 부분이 무엇인지가 나옵니다. 다중 스레드가 실행중일 때, 한 스레드의 액션들은 병행 스레드들에서 실행중인 액션들에 영향을 주어서는 안 됩니다. Figure 11 에서, "Thread 1 Action 1" 액션은 아마도 빨리 수행될 것이고, "Thread 1 Action 2" 액션은 "Thread 2 Action 1" 이 완료되기 전에 처리를 시작할 것입니다. 다른 병행 스레드들을 위해 스레드들을 대기하도록 만드는 유일한 것은 동기화 상태이며, Figure 11 에서 보여 준 것처럼 배치되어 있습니다.

위의 모든 예제에서, 동기화 상태들은 굵은 수직 라인으로 그려집니다; 하지만 UML 명세는 이 라인들이 한 방향이나 다른 방향을 향해야 한다고 요구하지는 않습니다. 동기화 상태는 수평 굵은 라인이거나 심지어는 대각선의 굵은 라인일 수도 있습니다. 그러나 UML 다이어그램들은 가능한 한 쉽게 정보를 교환하기 위한 수단입니다; 그래서 사람들은 보통 수직 라인이나 수평 라인으로 동기화 상태를 그립니다; 단지 복잡한 상황일 때만( 예를 들어 화이트보드나 종이의 공간이 부족할 때 ) 동기화 상태가 이상한 각도로 그려질 수 있습니다.

스윔레인( Swimlanes )

활동 다이어그램에서 실제로 액션들을 실행하는 개체( 사람, 조직, 혹은 다른 책임 엔터티 ) 사이에서 활동의 절차적 제어 흐름을 모델링하는 것이 유용합니다. 이를 위해서, 당신은 스윔레인( swimlane )을 활동 다이어그램에 추가할 수 있습니다( 스윔레인은 수영 대회에서 둘 이상의 경쟁자들 사이에 있는 직선 경계와 닮았기 때문에 이름붙여졌습니다 ).

활동 다이어그램에 스윔레인을 넣기 위해서, 수직 열( column )을 사용합니다. 하나 이상의 액션을 실행하는 각 개체들은, 자신의 이름을 그 열의 최상위에 할당합니다. 그리고 나서 개체와 관련이 있는 액션들을 그 개체의 스윔레인에 배치합니다. Figure 12 는 액션들을 수행하는 두 개의 개체들을 보여 줍니다( Band Manager 와 Reporting Tool ). Band Manager 개체는 "Selects the View Sales For My Band Report" 액션을 실행하며, Reporting Tool 개체는 "Retrieve Bands the Band Manager Manages" 액션을 실행합니다. 비록 스윔레인이 활동 다이어그램의 명료성을 증진시켜주기는 하지만( 왜냐하면 모든 활동들이 자신의 실행 개체의 스윔레인에 배치되기 때문에 ), 이전에 언급한 활동 다이어그램을 관리하기 위한 모든 규칙들이 여전히 적용된다는 것을 기억하는 것이 중요합니다. 다시 말해, 당신은 스윔레인이 사용되지 않은 것처럼 활동 다이어그램을 읽으면 됩니다.

Figure 12: 두 개의 스윔레인은 Band Manager 개체의 액션을 Reporting Tool 개체의 액션과 구분합니다.

진보된 표기 요소들

지금까지 살펴 봤듯이, 액션들은 보통 개체에 의해 실행됩니다. 하지만 다른 액션에 대한 입력인 개체의 출력이 액션일 수 있습니다. UML 명세는 이 개체 입력/출력이 활동 다이어그램에서 모델링되도록 절대적인 요구를 하지는 않습니다만, 가끔은 그렇게 하는 것이 스윔레인을 다이어그램에서 제공하는 것이 유용한 것과 같은 이유로 유용합니다. 이러한 개체 흐름을 모델링하기 위해서, UML 은 액션-개체 흐름 관계( action-object flow relationship )라는 표기를 가지고 있는데, 이것은 두 가지 형태의 심볼을 포함합니다 -- 오브젝트 플로우( object flow )과 상태 개체( object in state ).

오브젝트 플로우( Object flow )

오브젝트 플로우는 전이 라인과 동일한 것입니다만, 채워진 선이 아니라 점선으로 표시됩니다. 오브젝트 플로우 라인은 상태 개체( object in state ) 심볼에 연결됩니다. 그리고 다른 오브젝트 플로우 라인은 상태 개체를 다음 액션과 연결합니다. Figure 13 은 액션-개체 흐름 관계를 보여 줍니다.

Figure 13: 액션-개체 흐름 관계

Figure 13 에서, 두 액션 사이의 전이 라인 대신에, 액션-개체 흐름 관계 심볼을 볼 수 있습니다. 이는 두 액션 사이에서 액션-개체 흐름 관계가 다른 액션으로의 전이를 내포하므로, 전이 라인들이 중복되는 것으로 고려되기 때문입니다( 역주 : 액션-개체 흐름 관계가 전이 라인을 대체하므로, 액션 사이에 전이 라인이 필요하지 않다는 의미. ).

상태 개체( Object in state )

상태 개체( Object in state ) 심볼은 Figure 13 에서 사각형으로 표현됩니다. 상태 개체 심볼의 첫 번째 부분은 밑줄친 텍스트입니다. 사각형에서 밑줄친 텍스트는 개체의 클래스 이름입니다 -- 우리 예제에서는 "Order" -- 그리고 이 클래스는 모델링된 시스템의 클래스 다이어그램에서 찾아볼 수 있을 것입니다. 상태 개체의 두 번째 부분은 괄호 내부의 텍스트인데, 이는 오브젝트의 상태 이름입니다. 오브젝트의 상태를 포함하는 것은 선택적입니다만, 액션이 개체의 상태를 변경한다면 오브젝트 상태를 포함시키는 것을 추천합니다. Figure 14 는 다중의 액션-개체 흐름 관계들을 가진 완전한 활동 다이어그램을 보여 줍니다.

Figure 14: "Place Order" 액션은 Order 개체를 "Placed" 상태로 만듭니다;

그리고 나서 "Verify Ordered Products Are In Stock" 액션은 Order 개체를 "Accepted" 상태로 옮깁니다.

액션-개체 흐름 관계들을 포함하는 것은 활동 다이어그램을 읽는 방식을 변경시키지 않습니다; 이것은 그냥 부가적인 정보를 제공합니다. Figure 14 에서 "Place Order" 액션은 Order 개체에 "Placed" 상태를 설정합니다; 나중에 "Verify Ordered Products Are In Stock" 액션은 Order 오브젝트를 "Accepted" 상태로 옮깁니다. 우리는 이러한 액션들이 Order 의 상태를 수정하는 것을 알고 있습니다. 왜냐하면 상태 개체 심볼들이 상태들을 가지기 때문입니다.

하위 활동 상태( Subactivity state )

하위 활동 상태( subactivity state ) 는 활동의 흐름에 다른 활동을 내포하고자 할 때 사용할 수 있는 또 다른 상태 다이어그램입니다. 하위 활동 상태는 활동 다이어그램에서 액션 상태가 위치한 곳에 배치됩니다. 액션 상태와 같은 방식으로 하위 활동 상태를 그릴 수 있는데, 우하단에 내포된 활동 다이어그램임을 표현하는 아이콘이 추가되어 있습니다. 하위 활동 상태의 이름은 Figure 15 와 Figure 16 에서 볼 수 있듯이 심볼 내에 위치합니다.

Figure 15 : IBM Rational XDE^TM 으로 그려진 하위 활동 상태의 예.

Figure 16: UML 명세에 그려진 하위 활동 상태의 예.

Figure 15 와 Figure 16 에서 우하단에 있는 하위 활동 상태 아이콘들이 약간 다르다는 점에 주목하십시오. UML 1.4 명시적으로 어떤 아이콘이 사용되어야 하는지에 대한 언급이 없습니다. 대신에 다음과 같이 이야기하고 있습니다:

하위 활동 상태는 액션 상태와 동일한 방식으로 표현되는데, 우하단에 내포된 활동 다이어그램을 표현하는 아이콘을 가지고 있다. 하위 활동 상태의 이름은 심볼 내에 위치한다. 하위 활동 상태는 다이어그램 내에서 유일할 필요는 없다. 이 표기법은 "내포된" 구조를 지원하는 모든 UML 생성에 적용된다. 아이콘은 내포된 구조의 형식을 암시해야만 한다.

지금으로썬 이것이 표준 심볼이 없다는 것을 의미합니다. 왜냐하면 하위 활동 상태 아이콘들이 누가( 혹은 어떤 도구가 ) 그것들을 활동 다이어그램에 넣느냐에 의존하기 때문입니다. 그래서 이 아이콘의 외형에 대한 확고한 동의에 도달할 때까지는 단순하게 일관성있는 것이 최선입니다: 하위 활동 상태를 표현할 때마다 같은 아이콘을 사용하는 것이 좋습니다.

결론

다른 UML 다이어그램들과 마찬가지로, 활동 다이어그램의 첫 번째 목적은 정보를 효율적으로 교환하는데 있습니다. 활동 다이어그램을 전체 시스템 모델에 포함하는 주요 이유는 그것들이 다양한 활동을 위한 절차적인 제어 흐름을 모델링한다는 것입니다. 이는 이러한 종류의 모델이 비즈니스를 하는 사람들이 시스템이 동작하는 비즈니스 환경에 대한 이해를 더 잘할 수 있게 해 주기 때문에 중요합니다. 물론, 활동 다이어그램은 비즈니스 처리를 모델링하는데만 국한되는 것은 아닙니다; 그것들은 컴퓨터 프로세스를 모델링하는 데도 사용될 수 있습니다.

일반적으로, 자신만의 활동 다이어그램을 생성할 때 이 기사에서 설명한 모든 표기 요소들을 사용하지는 않을 것입니다. 하지만 초기 상태, 전이 라인, 액션 상태, 최종 상태 표기들은 매우 자주 사용할 것입니다.

필수 UML 다이어그램에 대한 이 시리즈의 다음 기사에서는, 클래스 다이어그램에 대해서 세부적으로 다룰 것입니다. 올 가을에 다시 만납시다.