한빛출판네트워크

제공 : 한빛 네트워크
저자 : 이노우에 타츠키
역자 : 이영희
출처 : 다이어그램으로 쉽게 배우는 UML



▶ 유즈케이스 다이어그램 작성 시의 주의사항

이번에는 이 기사의 주제인 ‘보다 좋은 유즈케이스 다이어그램을 작성하려면 어떻게 하면 될까’에 대해 설명합니다. 유즈케이스 다이어그램은 앞에서 보았듯이 심플하기 때문에 신경써서 그리지 않으면 아무런 정보도 얻을 수 없을뿐 아니라 오히려 프로젝트에 혼란만 가져옵니다. 그래서 좋은 다이어그램을 그릴 수 있도록 주의해야 할 사항들에 대해 차례로 열거해 보겠습니다.

목적(독자)을 확인한다
일단 처음에는 목적(독자)을 정합니다. 유즈케이스 다이어그램에만 해당되는 얘기는 아니지만, 모델은 목적이 확실해야 합니다. 목적과 모델이 일치하지 않으면 결코 좋은 모델이라고 할 수 없습니다.

다른 사람이 이해할 수 없고 오로지 자기 자신만 이해할 수 있는 그러한 모델은 의미가 없습니다. 그래서 유즈케이스 다이어그램을 만들기 전에는 유즈케이스 다이어그램을 그리는 목적이 무엇이며, 누구를 위해 만드는지를 확실히 해두는 것이 중요합니다. 그리고 유즈케이스 다이어그램을 그리면서 목적에 맞는 것인지, 독자(유즈케이스 다이어그램을 이용하는 사람)에게 의미가 있는 것인지 수시로 검토하는 습관을 갖게 되면 더 좋은 유즈케이스 다이어그램을 그릴 수 있습니다.

[그림 2-1]을 보세요. 이 다이어그램은 렌탈 비디오 가게 전체를 모델화한 것으로 이해하기 쉬운 유즈케이스 다이어그램입니다. 그러나 렌탈 비디오 가게에 도입 중인 POS시스템을 개발할 때 개발자가 참조하는 유즈케이스 다이어그램으로는 어떨까요? [그림2-1]의 유즈케이스는 POS가 어떻게 관련되어 있는지 알 수가 없기 때문에 개발자에게는 큰 의미가 없습니다. 개발자 참조용으로는 [그림2-4]와 같은 유즈케이스 다이어그램이 아니면 안됩니다.

이와 같이 목적에 따라 만들어야 할 유즈케이스 다이어그램의 내용이 바뀌기 때문에, 유즈케이스 다이어그램을 만들 때는 목적을 확인하고 나서 목적에 맞는 유즈케이스 다이어그램이 작성되었는지를 검토하면 좋겠지요.


[그림2-4] 관점을 바꾼 유즈케이스 다이어그램 [그림2-5] 좋지 않은 명명법의 예

명명법에 주의한다
‘명명법’이란‘유즈케이스와 액터에 이름을 붙여주는 것을 말합니다. 이름을 붙이는 일은 매우 중요한 것으로, 어떤 이름을 붙이는가에 따라 다이어그램을 쉽게 읽을 수도 있고 의미 전달도 완전히 달라집니다. 예를들어 [그림2-1]의 유즈케이스 다이어그램이 [그림2-5]와 같았다면 어떠했을까요?

갑자기 [그림2-5]와 같은 다이어그램을 접하면 도대체 이 다이어그램으로 무엇을 나타내려고 한 것인지 좀처럼 이해하기 어려울 것이라고 생각합니다. ‘사람’이라고 하는 액터명은 너무 추상적이어서‘사람이라면 아무나 상관없다는 것인가?’의 의미가 되기도 합니다. 또한‘대출’이나‘반환’도 무엇을 대출하고 무엇을 반환해야 하는지 도무지 알 수가 없습니다. 극단적인 예로, 손님이 빌려간 것을 반환하는 서비스가 아니고, 손님에게 빌린 것을 다른 손님에게 반환하는 서비스라고 해석될 수도 있습니다.

어떻게 하면 이름을 잘 명명할 수 있을까요? 좋은 이름을 명명하기 위한 주요 포인트로‘추상도’,‘ 정확성’,‘ 표현의 통일’3가지를 들 수 있습니다. 이것을 유즈케이스 다이어그램에 적용하면 다음과 같습니다.

[추상도]
액터명이나 유즈케이스명에 추상적인 이름을 붙이게 되면 도대체 무엇을 나타내려고 한 것인지 애매모호한 경우가 발생합니다. 액터명은 모델화 대상에 대한 역할을 나타냅니다. 그런데 ‘사람’이라고 하면 너무 추상적이기 때문에 그 역할이 무엇인지 알 수가 없습니다. 반대로 ‘홍길동’같이 너무 구체적인 것도 좋지 않습니다.

알기 쉽게 하려면‘일반 회원’이나‘종업원’이라고 하는 렌탈 비디오 가게에서 사용하는 정도 의 추상도로 선택하면 됩니다. 이것은 유즈케이스명에서도 마찬가지입니다. 유즈케이스명도 대상이 제공하는 서비스를 문장으로 설명할 경우에 사용하는 정도의 추상도로 지어주면 됩니다. 또 액터명이나 유즈케이스명은 사용자 매뉴얼이나 유지보수 매뉴얼의 목차 수준 정도면 됩니다.

[정확성]
기술자는 대체로 문장을 짧게 쓰는 경향이 있습니다. 앞의 [그림2-5]의 유즈케이스에 있는 ‘대출’이나‘반환’이 그러한 예입니다. 단축은 간결하기는 하지만 의미를 정확하게 전달하지못할 경우가 있습니다. 유즈케이스명과 같은 이름은 작성자의 의도가 정확하게 전달되는 것이 중요합니다. 그러므로 귀찮더라도 유즈케이스명을 단축하지 마세요.

유즈케이스명을 제대로 명명하기 위해서는 서비스의 대상과 서비스가 제공해야 할 것을 명시하는 것이 중요합니다. 구체적으로‘~를 ~한다’식의 유즈케이스명으로 하면 서비스 대상과 수행하는 일이 명확해집니다. 단,‘ 대출을 한다’고 했을 경우‘~를~한다’라고 하는 룰은 지키고 있지만, 대상을 명시하고 있지 않기 때문에 명명법으로는 부적절합니다3).‘ 비디오를 대출한다’같은 이름이 되도록 해주세요.

[표현의 통일]
동일한 의미에 대해 여러 개의 용어를 사용하고 있으면 다이어그램을 이해하기 어려워집니다. 예를들면‘대출한다’와‘렌탈한다’라는 말이 동시에 나오는 유즈케이스 다이어그램은 별로 좋지 않습니다. 이것은 유즈케이스 다이어그램에만 해당하는 이야기는 아니지만, 모델을 만들 때에는‘이음 동의어’와‘동음 이의어’를 피해 주세요. 대출한다와 렌탈한다가 다이어그램 안에서 동일한 의미로 사용되고 있다면 통일하는 것이 훨씬 좋습니다.

명명하는 일이 단순할 것 같지만 좋은 모델을 만들기 위해서는 상당히 중요한 부분 중 하나입니다. 단순히 많은 모델 요소를 암기하는 것보다 이름 하나 하나에 신경을 더 쓰는 것이야말로, 모델을 만드는데 있어서 훨씬 의미가 있는 일입니다.

규모를 동일하게 한다
‘규모를 동일하게 한다’라는 의미는 유즈케이스 다이어그램에 표시할 유즈케이스의 규모를 동일하게 만든다는 것입니다.‘ 규모’란 유즈케이스가 나타내는 서비스의 크기입니다. 예를들어‘회원을 관리한다’의 서비스는 회원의 등록, 삭제, 참조를 포함하고 있기 때문에 큰 규모의 유즈케이스이고,‘ 회원을 등록한다’의 서비스는 작은 규모의 유즈케이스라고 볼 수 있습니다.즉, 1개의 유즈케이스 다이어그램에 비슷한 규모의 유즈케이스를 그려 넣게 되면 유즈케이스 다이어그램은 훨씬 읽기 쉽습니다[그림2-6].

또 규모를 동일하게 한다는 것은 앞에서 서술했듯이 단순하게 유즈케이스 수를 열거해 놓은 것만으로 시스템 전체의 작업 규모를 측정할 수 있다는 의미이기도 합니다. 그런데 만약, 유즈케이스의 규모가 제각각일 경우라면 유즈케이스 별로 어느 정도의 규모가 되는지 일일이 파악하지 않으면 안됩니다. 한번 훑어 본 후, 작업 규모가 어느 정도인지를 알 수 있다고 하는 유즈케이스 다이어그램의 장점을 살리기 위해서는 유즈케이스의 규모를 동일하게 해 둘 필요가 있습니다.


[그림2-6] 유즈케이스 다이어그램과 유즈케이스의 규모

또‘어떤 규모로 유즈케이스를 표현하는 것이 좋을까?’하는 논의가 많은데, 이에 대해서는 대상이 갖고 있는 기능 단위보다 큰 규모로 유즈케이스를 만든다면 어떤 규모라도 상관없다고 필자는 생각하고 있습니다. 다만 규모가 너무 작은 유즈케이스만은 피하는 편이 좋습니다. 이것은 다음에 설명할 항목인‘기능 분할로 하지 않는다’에서 설명하겠습니다.

‘기능 분할’을 하지 않는다
유즈케이스는 대상이 제공하는 서비스가 아니라 대상이 갖고 있는 기능을 추출하는 경우가 대부분입니다.

개발 경험이 있는 기술자라면 아무래도‘이 기능, 이 기능, 이 기능이 있으면 이 서비스를 실현할 수 있다’라고 쉽게 생각할 수 있기 때문에 결과적으로 유즈케이스 다이어그램 안에 서비스가 아닌, 서비스를 실현하기 위해 필요한 기능이 정의되어 버립니다. 그러한 유즈케이스 다이어그램을 흔히‘기능 분할 유즈케이스 다이어그램’이라고 부르기도 합니다[그림2-7].

기능 분할의 유즈케이스 다이어그램의 문제점은 유즈케이스 규모가 너무 작아서 모델화한 대상이 어떠한 서비스를 제공하고 있는지 알 수 없다는 점입니다.


[그림2-7] 기능 분할의 유즈케이스 다이어그램

유즈케이스의 규모가 너무 작으면 액터에게 의미있는 서비스가 아닌, 이용 목적을 알 수 없는 하나의 기능이 되어 버립니다. [그림2-7]을 예로 얘기하자면‘대출 일수만을 입력한다’라고 하는 유즈케이스는 상품관리부에서는 아무런 의미가 없는 기능입니다4).

유즈케이스를 한글로 바꾸면‘이용 사례’라는 의미가 있듯이, 유즈케이스의 추출은 액터에게 이용 사례로써의 의미가 있는 단위로 추출합니다. 만일 [그림2-7]에서 그려져 있는 모든 유즈케이스를‘비디오를 대출한다’고 하는 1개의 유즈케이스로 합쳐 버리면 액터에게 의미있는 단위가 됩니다.

또 기능 분할 유즈케이스는 유즈케이스간의 <> 관계를 정의할 때 범하기 쉬운 오류입니다. <>는 포함 관계를 나타내는 관계이기 때문에, 이 서비스에 이 기능이 포함되어 있고, 다른 기능에는 또 다른 기능이 포함되어 있다고 하는 것처럼, 기능의 계층 구조(WBS：Work Breakdown Structure)를 만듭니다[그림2-8].

따라서 <>를 사용할 때는 주의가 필요합니다. 필자의 경우,‘ <>는 가능한한 사용하지 말고, 사용한다면 1번만’이라고 하는 개인적인 룰을 갖고 있습니다. [그림2-8]이라면‘회원인지를 확인한다’라고 하는 유즈케이스까지는OK이지만 그 이외의 것은 필요하지 않습니다. 경험상 2회 이상 <>를 사용하면 액터에게 그다지 의미있는 규모의 유즈케이스가 되지 않기 때문입니다.


[그림2-8] WBS가 되어 있는 유즈케이스 다이어그램

<>와 <>, 일반화 관계를 혼동하지 않는다
유즈케이스 다이어그램에서는 유즈케이스에 대해 <>와 <>, 일반화 관계를 정의할 수 있지만, 베이스가 되는 유즈케이스에 기능을 덧붙인다고 하는 관점에서 볼 때 이 3개를 구분해서 사용하기란 무척 어렵습니다. 그 때문인지 잘못 사용하고 있는 경우도 자주 봅니다. 아래에 이 3개의 차이를, 유즈케이스에 기능을 추가한다고 하는 관점에서 간단하게 정리합니다.

<>에 의한 정의
<>를 사용하여 베이스가 되는 유즈케이스에 부가하는 서비스를 정의하면, 베이스 유즈케이스를 실행하기 위해서는 <>로 연결되어 있는 유즈케이스가 반드시 필요하다는 것을 알 수 있습니다. 다시 말하면, 베이스가 되는 유즈케이스가 서브 루틴을 호출하는 식으로 유즈케이스를 정의합니다.

[그림2-9]를 보면‘비디오를 빌린다’를 실행하기 위해서는‘회원인지를 확인한다’가 반드시 필요합니다. 또 <>로 정의된 유즈케이스는 여러 유즈케이스에서 공유할 수 있습니다.


[그림2-9] <>와 <>, 일반화 관계의 예

<>에 의한 정의
<>를 사용하여 베이스가 되는 유즈케이스에 부가하는 서비스를 정의하면, 베이스 유즈케이스를 실행하기 위해 <>로 연결되어 있는 유즈케이스가 반드시 필요하지 않다는 것을 알 수 있습니다. 반대로 <>로 정의되어 있는 유즈케이스를 실행할 경우에는 반드시 베이스 유즈케이스가 필요합니다.

[그림2-9]에서 보면‘비디오를 빌린다’를 실행하기 위해‘카드로 요금을 지불한다’는 반드시 필요하지는 않지만, ‘카드로 요금을 지불한다’를 실행하기 위해서는 반드시‘비디오를 빌린다’가 실행되지 않으면 안됩니다. 또 <>를 정의하고 있는 유즈케이스는 여러 유즈케이스에서 공유할 수 없습니다.

일반화 관계
일반화 관계는 기본적으로 기능의 추가 관계를 나타내지는 않습니다. [그림2-9]에서 보면, ‘비디오를 택배로 빌린다’는‘비디오를 빌린다’에 기능을 추가한 것이 아닙니다. 즉, 일반화 관계는 <>나 <>와는 전혀 다릅니다.

일반화 관계는 기능을 추가하는 것이 아니라 개념만 공유할 뿐이지, 완전히 새로운 유즈케이스를 정의하고 있다고 생각하면 됩니다. [그림2-9]에서 보면‘비디오를 택배로 빌린다’라고 하는 유즈케이스는 일반화 관계를 사용하여‘비디오를 빌린다’의 특수한 예를 나타내고 있지만, 그 내용은‘비디오를 빌린다’와 다를 수 있습니다. 실제 비디오를 택배로 빌리기 위해서는대출 대상인 비디오의 지정 방법이나 요금의 지불 방법, 비디오의 해석 방법은 베이스 유즈케이스와는 또 다른 것이 됩니다. 다만‘비디오를 빌린다’라는 관점에서는 둘 다 같습니다.

▶ 유즈케이스 정의서와 병행해서 사용

지금까지 유즈케이스에 대해 설명을 했습니다만, 구체적으로 유즈케이스의 내용이 무엇인지는 유즈케이스 다이어그램만 보아서는 알 수 없는 경우가 있습니다. 그래서 유즈케이스 다이어그램을 사용할 때는 유즈케이스 내용을 구체적으로 설명한 유즈케이스 정의서가 함께 작성됩니다.

역으로 말하면, 유즈케이스 정의서를 제외한 유즈케이스 다이어그램만 사용하면 유즈케이스의 구체적인 내용을 알 수 없기 때문에 오해를 불러 일으키기 쉽다는 위험이 뒤따릅니다.

그래서 유즈케이스 다이어그램을 그릴 때는 유즈케이스 정의서까지 작성해서 함께 사용하세요.

추가로, 유즈케이스 다이어그램과 유즈케이스 정의서를 합해서‘유즈케이스 모델’이라고 부르기도 합니다. 유즈케이스 정의서를 작성하는 방법은 다음 장에서도 다룹니다.

▶ 정리

이번 기사에서는 유즈케이스 다이어그램에 관한 주의사항에 대해 설명을 했습니다. 어떻습니까?

이번 기사에서 설명한 주의사항에 대해 체크 리스트 식으로 정리해 봅시다.

• 목적(독자)을 확인하고 있는가
• 명명 시 추상도, 정확성, 표현의 통일은 확인했는가
• 규모는 일정한가
• 기능 분할로 되어 있지는 않는가
• <>, <>, 일반화 관계의 사용법이 잘못되어 있지는 않은가

유즈케이스 다이어그램의 작성 시 위와 같은 체크 리스트 항목에 위반되는 사항이 없는지 확인해 보는 편이 좋습니다.

필자도 지금까지 많은 유즈케이스 다이어그램을 봐 왔습니다만, 제일 많은 오류가 기능 분할로 되어 있는 유즈케이스 다이어그램입니다. 이는‘시스템을 어떻게 만들까’를 위주로 생각하는 개발자의‘습성’이기 때문에 어쩔 수 없다고 하면 어쩔 수 없는 일이지만, 그렇다고 해서 방치해 둬서도 안되는 일입니다.

제일 먼저 주의해야 할 사항으로‘유즈케이스 다이어그램을 그리는 목적을 확인하면서 작성한다’라고 했었는데, 이것을 실천하면 기능 분할 위주의 유즈케이스 작성으로부터 벗어나기가 쉽습니다. 목적에 맞는 유즈케이스 다이어그램을 만들 수 있도록 자신이 만들고 있는 모델이 목적에 맞는지 항상 확인하는 습관을 가지세요.