스윔레인으로 경계와 상호작용 드러내기
한국의 마틴 파울러가 되기
지난 글에 이어 동료가 상태도를 만드는 과정을 돕고, 팀에서 상태도를 활용하는 과정에 대한 기록을 남깁니다. 동료가 그린 그림에 대한 첫 번째 피드백은 앞서 말한 대로 다음과 같습니다.
일단, 표기법은 무시하고, 중요한 내용이 모두 담겼는지만 초점을 맞춰 보죠.
수행 주체와 역할이 드러나도록 표현하기
동료의 첫 번째 그림은 누가 하는 일인지가 모호했습니다. UML에서는 행위의 수행 주체를 액터(Actor)라고 하는데, 동료에게 액터가 드러나게 그림을 그려 보라고 제안했습니다. UML을 사용하던 버릇이 있어서 Swimlane을 쓰라고 예시로 아래와 같이 그렸습니다.
Swimlane으로 구글링 해 보니 UML뿐만 아니라 다양한 다이어그램에서 많이 쓰이는 듯합니다. [1]
수영장 레인의 비유이지만 다른 점이 있습니다. 수영장은 레인을 넘으면 안 되지만, 보통 다이어그램에서 스윔레인을 쓸 때는 레인을 넘나드는 상호작용을 표시한다는 점입니다. 애초에 상호작용과 역할을 드러내기 위해서 사용하기 때문입니다.
경계와 상호작용을 드러내기
과학 공부하다가 즉흥적으로 썼던 <소프트웨어 설계에서 파동의 응용>을 연상하게 됩니다. 상호작용을 구체화하면서 경계가 드러납니다. 경계가 바로 스윔레인이죠. 그리고, 경계를 오가는 선이 바로 메시지이거나 선후 관계 등으로 규명됩니다.
하지만, 여기 하나의 함정이 있습니다. 스윔레인은 일의 흐름에 쓰는 것이지 상태도에서 쓰이는 요소는 아닙니다. 다시 한번 제가 동료의 그림을 보고 했던 조언을 돌아보겠습니다.
일단, 표기법은 무시하고, 중요한 내용이 모두 담겼는지만 초점을 맞춰 보죠.
처음에는 형식에 얽매이지 않고 내용에 중심을 두기로 한 것입니다. 상태도를 처음부터 그리는 일은 매우 어렵습니다.[2] 그래서, 상태도를 그리는 것을 목표로 두기보다는 사태를 명확하게 파악하여 시각화하는 일로 발전시키려고 한 것입니다.
경계를 지어 객체를 만들기
동료가 그렇게 그린 후에 한쪽 스윔레인에 있는 항목을 객체로 묶으면 상태도를 그릴 수 있다고 설명했습니다.
그리고 다른 종이에 네모 박스를 그린 후에 객체의 이름을 지어 주었습니다. 앞서 스윔레인에 담기는 일의 흐름 혹은 행위들을 포함하는 그것을 우리는 객체라고 할 수 있습니다.
또다시 <소프트웨어 설계에서 입자의 응용>을 연상할 수 있습니다. 입자와 객체는 물론 정확하게 같은 개념은 아니지만, 이들을 정의하는 과정에서 머릿속에서 발생하는 인지 활동은 어딘가 비슷한 구석이 있습니다.
객체는 상태의 맥락을 제공합니다. 객체가 없으면 상태도가 모호해집니다. 여기까지 안내하고 동료의 작업을 기다렸습니다.
주석
[1] 참고로 UML은 버전을 업데이트하면서 언젠가부터 Swimlane을 쓰지 않고 Partition이라는 개념과 표기법을 쓰기 시작했습니다.
[2] 제가 20년 가까이 소프트웨어 일을 해 왔지만 문서로 만들어진 상태도 말고 응용 프로그램을 만드는 동료가 상태도를 그리는 일을 본 적이 없습니다. 저 역시 아주 복잡한 프로그램을 작성할 때, 딱 두 번 실전에서 그리고 사용한 일이 있습니다. 2004년 원자력 발전소 제어기 시뮬레이터 설계를 할 때 상태도를 그렸고, 2010년 IFRS 회계 시스템의 결산 제어기를 만들 때 상태도를 그리고 프로그램 작성과 테스트 케이스를 만든 일이 있습니다.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기
13. 설계는 변화에 대한 준비인가?
