Extremely Agile/UML2007.10.27 00:19

I. UML 컴포넌트

UML 컴포넌트 다이어그램을 구성하는 하나의 컴포넌트는 컴포넌트와 거기에 붙은 여러개의 인터페이스로 그릴 수 있습니다. 인터페이스는 provided interface와 required interface의 두 종류로 나뉘는데, 전자는 그 컴포넌트가 제공하는 인터페이스이고, 후자는 다른 컴포넌트가 제공하는 인터페이스를 사용한다는 의미입니다. 그러니까 어떤 컴포넌트 입장에서 봤을 때 제일 중요한 인터페이스는 provided 인터페이스인 셈입니다. 컴포넌트 다이어그램을 그리는 사람 입장에서도 그렇습니다. 그 다이어그램을 그리는 사람은 어떤 인터페이스가 어떤 컴포넌트에 속해야 하는지가 가장 뚜렷이 드러나도록 다이어그램을 그리려고 할 테니 말이죠.

사용자 삽입 이미지
 

이렇게 달랑 컴포넌트 하나만 놓고 설명하는 건 좀 심심하니까, 이번에는 컴포넌트가 여러개 등장하는 컴포넌트 다이어그램을 보도록 하겠습니다. 보시다시피 컴포넌트의 인터페이스 간에는 의존성 관계가 있습니다. 그 방향은 언제나 일정하죠. provided interface 쪽으로 화살표가 가게 되어 있습니다. (뭐 당연한 일이겠죠?)

컴포넌트 다이어그램

컴포넌트 다이어그램 - 누르면 커집니다



II. UML 컴포넌트의 인터페이스

그런에 위의 그림을 잘 보면, 인터페이스의 이름이 마치 자바 클래스나 자바 인터페이스의 이름과 비슷하게 만들어져 있다는 것을 보실 수 있을 겁니다. 그렇다면 저 동그라미 하나는 하나의 자바 인터페이스에 대응되어야 하나요?

흔히 컴포넌트 인터페이스를 정의할 때, 그 인터페이스가 가지는 역할을 중심으로 인터페이스 이름을 결정합니다. 해당 인터페이스를 호출하면 해당 컴포넌트가 어떤 종류의 역할을 수행하게 되는지를 중심으로 인터페이스 이름을 결정한다, 뭐 그렇게 생각해도 되겠죠.

그런데 문제는 그런 식으로 정해진 인터페이스가 꼭 자바 인터페이스 하나에 대응되는 것은 아닐 수도 있다는 것이죠. 자바의 인터페이스/클래스를 어떻게 나눌 것이냐 하는 문제는 단순히 '역할'이라는 하나의 관점만 사용해서는 풀기가 좀 힘듭니다. "UML, 실전에서는 이것만 쓴다"라는 책의 클래스 다이어그램 부분을 읽어보면 짐작할 수 있는 사항입니다만,  클래스들을 나눌 때에는 "의존도를 최소화해야"하고 "변경을 국지화해야 한다"는 등의 원칙들이 강하게 작용하거든요. 그러니 위의 그림에서 볼 수 있는 RequestAdmissionInterface 같은 것은 사실 그 인터페이스를 사용하는 외부 컴포넌트가 두 개 이상일 경우에는 역시 두 개 이상의 자바 인터페이스에 의해 모델링 될 수가 있습니다. 그렇다면 이렇게 정리하면 되겠군요.

하나의 컴포넌트 인터페이스는 하나 이상의 자바 인터페이스에 대응될 수 있다 



이 말이 어쩐지 좀 이상하게 들린다는 분들은 Enterprise Architect같은 UML 툴을 한 번 써 보시기 바랍니다. 실제로 저 동그라미 하나에 하나 이상의 자바 인터페이스 (혹은 C++ Abstract 클래스) 에 대한 '링크'를 만들어 넣을 수가 있습니다.

이런 관점은 애자일 적으로 봐도 유효합니다. 컴포넌트 다이어그램을 그리는 단계에서는 컴포넌트 안에 무슨 클래스들이 만들어질지 모르는 경우가 허다한데, 인터페이스 클래스의 이름까지 고정적으로 붙여버린다는 것은 솔직히 너무한 일 아니겠어요?

그렇게 본다면 위의 컴포넌트 다이어그램에서 RequestAdmissionInterface같은 이름은 어쩐지 이상하군요. 꼭 자바 인터페이스 같은 뉘앙스를 풍기니 말이죠. 그냥 Request Admission Interface같이 띄어쓰기를 해 주는 편이 더 낫겠어요.


참고문헌

"UML, 실전에서는 이것만 쓴다" (인사이트)

이 글은 스프링노트에서 작성되었습니다.


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

I. 사용자 스토리와 유스케이스?

[1]을 보면 이런 말이 나옵니다.

유스케이스 다이어그램은 UML의 많은 다이어그램에서 가장 혼란스럽고 쓸모없다. 나는 잠시 후 설명할 시스템 경계 다이어그램을 제외한 다른 유스케이스 다이어그램들을 여러분이 전혀 사용하지 않으면 좋겠다.

뭐 이런 말도 나옵니다.

유스케이스는 시스템의 동작 하나를 기술한 것이다. 유스케이스는 방금 시스템에게 특정한 일을 시킨 사용자의 관점에서 작성하며, 사용자가 보낸 자극 하나에 대한 반응으로 시스템이 진행하는 눈에 보이는 이벤트의 흐름을 포착한다.

눈에 보이는 이벤트란 사용자가 볼 수 있는 이벤트를 뜻한다. 유스케이스는 사용자의 눈에 보이지 않는 동작을 전혀 기술하지 않고 시스템 안에 숨겨진 메커니즘도 다루지 않는다. 오직 사용자가 직접 볼 수 있는 것만을 적어놓을 뿐이다.

좀 다른 식으로 말을 하고 있긴 하지만, 이 책의 저자는 "유스케이스는 가급적 상세하게 작성하고, 세부사항은 고객과 의논해라"라는 뜻의 말을 하고 있습니다. 이런 말은 아마 어디서 많이 들어본 소리일 겁니다. 맞습니다. "사용자 스토리"란 책에 보면 나오는 이야기이죠. 위와 같은 말을 한 다음에 저자는 다음의 유스케이스 사례를 보여줍니다. 유스케이스는 이 정도로 작성하면 좋지 않겠느냐,는 이야기를 하고 있는 것이죠.

상품을 구입하기

  1. 점원은 상품을 스캐너 위로 통과시킨다. 스캐너가 UPC 코드를 읽는다.
  2. 상품 가격과 설명이 지금까지 통과시킨 상품 가격의 합계와 함깨 고객 쪽의 화면에 표시된다. 가격과 설명은 점원의 화면에도 표시된다.
  3. 가격과 설명이 영수증에 출력된다.
  4. 점원이 UPC 코드가 올바르게 읽혔는지를 확인할 수 있도록 시스템이 잘 들리는 "승인"소리를 낸다.

실제로 유스케이스에 관한 책들을 보면 Use Case는 "기본 흐름"과 "대체 흐름"으로 구성된다는 것을 확인할 수 있는데요, 위의 유스케이스는 기본 흐름만 보여주고 있습니다. 사용자 스토리를 선호하는 개발자들은 유스케이스를 "기본 흐름"정도만 작성하는 선에서 마무리 짓기를 원할 것입니다. 하지만 시스템이 정상적으로 동작하지 않을 경우에 어떤 식으로 프로세스가 일어나야 하는지를 고객이 정확하게 명시하고자 하는 경우도 있을 수 있으니까, 그런 경우에는 "대체 흐름"도 작성해야 합니다. 사용자 스토리라면 대체 흐름은 아마 사용자 스토리 카드의 "테스트" 부분에 명시될 가능성이 높겠습니다만, 유스케이스 작성을 요구하는 부서에서 일하고 있다면 대체 흐름을 통해 그 사실을 적시할 필요가 있겠습니다. (유스케이스로 사용자 스토리 카드를 대체하는 것이죠.)  

위의 유스케이스를 보면 대략 다음과 같은 사실을 눈치챌 수 있습니다.

  1. 유스케이스의 제목은 사용자 스토리 관점에서 보면 에픽(Epic)이다
  2. 유스케이스를 구성하는 절차는 사용자 스토리가 아니다

왜 사용자 스토리가 아니라고 이야기 해야 하나요? 사용자 스토리는 "우리가 시스템을 통해 성취해야 할 무엇"을 시스템 전반에 걸쳐 "종적"으로 명시하는 것이지 결코 그 중 일부분만 떼어 내어 절차 단위로 분할하지 않습니다. 물론 위의 유스케이스는 "스캐너가 UPC코드를 읽는다"와 같은 독립적인 스토리가 될 수 있는 여지를 가지고 있는 작업도 포함하고 있습니다만, 그건 위의 유스케이스에 한정되는 것이지 다른 유스케이스에도 적용될 수 있는 이야기라고 보기는 좀 힘듭니다.


II. 회사가 유스케이스와 다이어그램을 작성하라고 요구합니다

자.  그렇다면 이제 이런 경우를 생각해 봅시다. 회사가 유스케이스와 다이어그램을 작성하라고 요구하는 경우에는 어떻게 해야 하나요? 그런 요구를 받은 사람이 사용자 스토리를 포함하는 애자일 프로세스의 추종자라면 (가령 저같은 사람 -_-;) 분명 그 요구에 무리한 부분이 있다고 느낄 것입니다. 유스케이스를 신봉하는 대부분의 조직은 개발 기간의 70% 정도를 유스케이스와 그 세부사항을 작성하는 데 투여하는 경향이 있습니다, 그렇게 해서 작성된 유스케이스가 실제 개발이 시작될 시점에 사용자의 요구를 몇 퍼센트나 정확하게 반영할까요? 개발자 집단이 유스케이스를 열심히 작성하고 있는 동안에도, 사용자의 요구사항은 끊임없이 변화하게 마련이라는 데에 주목합시다. [1]의 저자도 이야기하는 사항입니다만, 문서는 "덜 자세할 수록 더 정확" 합니다. 디버깅을 나중에 할 수록 결함 비용이 증가하듯이, 검증되지 않은 유스케이스를 보다 더 자세히 작성할 수록 나중에 개발 결과물이 산으로 갈 가능성은 더 높아집니다.

그런데 어떤 회사는 "그래도 유스케이스와 다이어그램을 작성해야 한다"고 요구합니다. 이런 조직은 대부분 잘 정의된 문서가 있어야 직성이 풀리는 조직입니다. [1]의 저자는 '그러니 문서는 가급적 맨 마지막에 작성해야한다'고 언급합니다. 그래야 문서가 개발된 결과물의 상태를 정확하게 반영하니까요.

따라서,  그런 조직에서 일한다면 이제 타이밍의 문제를 심각하게 고려해 볼 필요가 있습니다.

  1. 문서를 개발기간 초기에 작성해야 하는가?
  2. 문서를 개발기간이 끝난 뒤에 작성해도 되는가?

2의 경우라면 좋겠습니다만, 1의 경우라면 가급적 조직을 설득하는 게 좋겠습니다. '이런 저런 이유로, 문서관리 시스템에 지금 모든 문서를 일괄등록시키는 것은 불가합니다'라구요. 설득이 안된다면, 가급적 문서를 '점진적으로 개선'하는 방향으로 해 나가겠다고 설득하는 것이 좋겠습니다. 그런데 유스케이스는 과연 점진적으로 작성하는 것이 가능한 문서인가요? 의 유스케이스 사례만 보더라도, "승인"을 알리는 알람 시그널이 울려야 한다는 등의 세부사항이 유스케이스 안에 들어있어서 도대체 점진적인 작성이라는 것이 어려워 보이기는 합니다. 그러니, 유스케이스를 점진적으로 작성하려면 "개발에 관한 모든 요구 사항을 개발 전에 FIX 시키겠다는 환상을 버리"고, 문서에 포함된 내용이 점진적으로 발전하게 될 수 있음을 모든 사람에게 납득시켜야 합니다. 물론 조직에 따라서는 이렇게 하기가 좀 힘들 수도 있겠습니다.

유스케이스 작성에 있어서 한 가지 더 고려해야 할 사항은, 유스케이스 다이어그램의 작성입니다. 어떤 조직은 유스케이스 문서와 더불어 유스케이스 다이어그램이 나와 줘야 한다고 요구하기도 합니다. 그런 경우에는 [1]의 저자의 말대로 '시스템 경계 다이어그램' 정도를 작성하는 것이 옳아 보입니다. 그런데 '시스템 경계 다이어그램'은 대체 어떻게 작성해야 하나요?

유스케이스 다이어그램

유스케이스 다이어그램 (http://www.oracle.com/technology/global/kr/pub/columns/051024_jdeveloper_uml.html)

애자일 개발 조직이라면 사용자 스토리 식별 과정에서 나온 스토리들을 역으로 "에픽"으로 그룹화 한 다음 그것으로 유스케이스 이름을 정하고, 그 이름들로 경계 다이어그램을 그려 나갈 수 있습니다. 비-애자일 조직이라고 하더라도 그런 식으로 작업해서 효율을 높일 수 있습니다. 유스케이스를 그리는 것이 유일한 목적인 비-애자일 조직에서도 사용자 스토리는 활용될 수 있다는 것이죠.


참고문헌

  1. Java  프로그래머를 위한 UML: 실전에서는 이것만 쓴다
  2. 사용자 스토리(User Story Applied)

이 글은 스프링노트에서 작성되었습니다.

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 윤영석

    늘 1번만 염두에두고서 어떻게 개발전 단계에서 모든 문제를 포함 할수 있을지만 고민했는데
    처음으로 2번의 방법도 존재한다는 걸 생각해봤습니다;

    2012.04.04 16:37 신고 [ ADDR : EDIT/ DEL : REPLY ]