UML 모델 그릴 필요가 있을까?

설계에 최소한의 노력만 하라고 말하면서 UML 모델을 남용할 수는 없다. 그렇지만, 가끔 그리고 싶은 충동을 느낄 때가 있다. 대부분은 대화과정에서 즉흥적으로 매직으로 그린 경험이다.

대화할 때 흔히 쓰는 UML 도해

popit에 올려둔 글만 보아도 대화하며 설명을 위해 그린 흔적이 있다. 대략 쓰임새를 요약해보면 다음과 같다.

혼자서도 필요한가?

가끔은 혼자서 생각을 정리할 때도 유익하다. 손으로 종이에 직접 그리는 것이 창의력을 발휘하기 위해서는 유리하다. 그러나, 의미를 조직화 할 때는 이미 정의된 기호를 손으로 그리기보다는 도구를 쓰는 것이 간편하다. 어제 문득 '진짜 그런가' 싶어서 기술문서[1]를 보다가 클래스도를 한번 그려봤다. 그리다 보니, 선 하나하나의 의미와 클래스 이름을 뭐라 정할까 고민하는 자신을 관찰할 수 있었다. 프로그램 할 때 고민하는 방식과 거의 유사하다. 도해 행위가 생각을 끌어주고, 생각할 시공간을 만들어주는 효과가 있다. 하지만, 작성한 결과물이 가치가 있는지는 확실하지 않았다. 그래서 저장하지 않고 지웠다.

며칠 후에 비슷한 시도를 하다가 결과가 나중에 보더라도 의미가 있다고 확신할 수 있는 경우가 생겼다. 중국에서 소비자용 플랫폼으로 너무나도 중요한 위챗WeChat 플랫폼에 대해 학습 하던 중이었다. 남이 만든 프로그램 구동 방식을 문서만 보면서 이해하는 일은 집중하기 어려웠다. 코딩하면서 확인하는 과정이라도 있으면 모르지만... 이때 코드를 작성하며 확인하는 방법 대안으로 UML 작성 과정이 유익했다. 대상은 아래 문단이다.

After becoming a developer, then whenever a user sends a message to the Official Account, or generates a custom-defined menu, or a WeChat Pay order, and so forth, then the server configuration URL entered by the developer will get messages and events pushed by the WeChat server. The developer can respond according to their own business logic, such as to reply with a message.[2]

문자열 파서Parser처럼 행동하기

조금씩 읽으면서 소화를 한다. 이를테면 이런 식이다.

After becoming a developer

이 부분은 위 문단 읽기 전에 인증 절차를 지칭하는 말이다. 그래서 일단 넘긴다.

then whenever a user sends a message to the Official Account, or ...

위챗WeChat은 기본적으로 채팅 서비스이니 메시지를 보낼테고, 여기서 다루는 메시지 수신 대상은 다른 사용자가 아니라 Official Account 즉 공식계정公众号이다. 공식 계정에 사용자와 소통하는 애플리케이션 기능을 넣기 위한 개발자를 위한 설명이기 때문이다. 한국에 있는 분을 위해 의미를 설명하면, 카톡처럼 쓰는 메신저에서 기업용 미니홈피에 메신저를 날릴 수가 있는데, 이럴 경우 미니홈피 개발자가 할 수 있는 것을 설명하고 있다. 그 설명 중에서 바로 메시지를 공식 계정이 받을 때 벌어지는 일을 막 설명하려고 하는 문장이다.

, or generates a custom-defined menu, or a WeChat Pay order, and so forth

메시지 말고도 확인하거나 대응할 수 있는 이벤트가 꽤 있음을 알 수 있다. 개발자라면 훅hook이나 콜백callback 이벤트를 짐작할 수 있는 내용이다.

then the server configuration URL entered by the developer will get messages and events

뒤이어 풀어야 할 내용이 많은 문장이 등장했다.

한장으로 요약하기

지루해지기 전에 결과부터 보여드리면, 아래와 같은 순차도sequence diagram를 그렸다. 요약이라는 결과를 만들어내는 과정에서 의미있는 작업은 뜻을 이해했는지 잘라서 그려보고, 모호한 내용은 이해한 바를 (비록 틀리더라도) 명확히 규정하고, 조금씩 이해한 내용을 합쳐서 종합해보는 일의 반복이다.

문단 내용을 순차도로 변환

문단 내용을 순차도로 변환

그리는 과정에서는 텍스트 편집기를 쓴다. PlantUML이라는 훌륭한 도구가 있다. 그런데, 설치를 안하고 쓰기에는 두레이 편집창에서 쓰는 편이 중국 네트워크 상황에서 가장 빨라 그렇게 쓴다. 위 순차도를 그리기 위한 마크업 결과는 아래와 같다.

actor user actor developer actor "WeChat admin" as admin entity "Official Account" as spot entity "WeChat server" as server entity "Message or Event" as object == After becoming a developer == user -> spot : 1. sends a message admin -> spot : 2. generates a custom-defined menu user -> spot : 3. a WeChat Pay order spot -> server server -> object : create for that situation developer -> server : get messages and events pushed by the WeChat server developer -> object : respond according to their own business logic(such as to reply with a message)

생각의 과정

모델링은 생각하는 과정에 도움을 준다. 문제에 집중하게 하고, 질문을 좁혀서 던지게 해준다. 앞에 소개한 문장을 다시 보며 예를 들어보자. 이렇게 콤마로 구분하여 여러 가지 내용을 나열하는 경우가 있다. 이때, 머리속에서 결정해야 한다. 하나만 취하고 버릴 것인가(문제 우선순위 결정), 하나로 묶어서 볼 것인가(일반화) 아니면 선택사항을 명료하게 드러낼 것인가?

then whenever a user sends a message to the Official Account, or generates a custom-defined menu, or a WeChat Pay order, and so forth, then

나는 후자를 택했다. 왜냐하면 앞서 설명한대로 콜백 상황이 어떤 것이 있느냐가 주안점이 될 수 있기 때문이다. 다음과 같이 빠르게 그려서 요약 결과를 확인할 수 있다. 선택상황을 드러내기 위해 선택사항 각각에 순번을 달았다.

```uml[3] user -> "Official Account" : 1. sends a message admin -> "Official Account" : 2. generates a custom-defined menu user -> "Official Account" : 3. a WeChat Pay order ```

아래와 같이 그려진다.

선택상황을 명시한 순차도

선택상황을 명시한 순차도

다듬으며 종합하기

uml 편집 문장을 보면 "Official Account" 문자열이 중복이다. 모던[4] 개발자라면 리팩토링refactoring을 해야 한다. 아래와 같은 식으로 한다.

```uml "Official Account" as site user -> site : 1. sends a message admin -> site : 2. generates a custom-defined menu user -> site : 3. a WeChat Pay order ```

더 나아가 최종 결과에 이르려면 몇 가지 결정을 더 하면서 다듬고 결정하는 행위를 계속해야 한다. 마치 개발하는 과정과 비슷하게[5] 설계 행위를 루틴화 해서 할 수 있다. 루틴에 쓰인 행위를 요약하면 다음과 같다.

  • 이름 정하기 (예를 들면, "Official Account" 별칭을 site로 할까? shop으로 할까? spot으로 할까?)
    • 객체지향적으로 표현하면 어떤 책임(Responsibility)을 부여할지 정하는 일이기도 하다
  • 스테레오타입stereotype으로 유형 부여
  • (앞서 언급한) 풀어야 할 내용 다루기
    • 가정하여 그려넣기
    • 생략하기

주석

[1] https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud

[2] https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421135319에서 발췌

[3] 두레이에서 UML 편집할 때 쓰는 문법 표현

[4] 오늘부터 2018년 이후에 생존할 개발자를 모던 개발자로 부르기로 한다. 동참(?)해주세요!

[5] 따라서, 대안으로 코딩 행위로 설계를 할 수 있다.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.