UML - 유스 케이스 - 개요와 내용

- 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다.

- 유스 케이스

유스 케이스는 시스템의 기능적인 요구사항을 잡아내는 기술이다. 유스케이스는 시스템과 사용자간의 교류를 기술한다. 유스 케이스를 곧바로 판별해내는것은 사실 어려운일이다. 보통은 시나리오를 생각해본 뒤 유스케이스를 식별한다.

시나리오는 사용자와 시스템간의 교류를 단계적으로 나타낸것이다. 예를 들어 온라인 쇼핑몰에서 물건을 산다면 시나리오는 아래와 같다.

 

고객은 상품 목록을 보고 원하는것을 선택하여 장바구니에 담는다. 물건을 구매하기 위해 배송지 및 신용카드 정보를 기술한다. 시스템은 신용카드 승인을 확인하고 물건 구매 확정을 한다. 그리고 그 결과를 이메일로 발송한다.

 

위의 시나리오는 개발자가 구현하기 좋은 전형적인 케이스만 기술한것이다. 신용카드 승인을 하다가 신용카드사 시스템과 통신이 안 될 수도 있고, 배송정보를 미리 저장한 고객이어서 입력단계가 생략되어야 할 수도 있다. 하지만 전형적인 시나리오든 그 변형이든 목표 "물건을 구매한다"는 똑같다.

 

유스 케이스에서 사용자는 액터(Actor)이다. 고객, 고객 서비스 담당자, 판매 담당자등은 모두 액터이다. 액터는 유스케이스를 수행한다. 액터 하나가 많은 유스케이스를 수행하며, 유스케이스 하나에 많은 액터들이 딸려있기도 한다. 액터는 사람뿐만 아니라 다른 시스템이 되기도 한다.

 

로버트 C.마틴의 클린 아키텍처에서는 객체지향설계 5대 원칙 SOLID의 SRP(단일 책임의 원칙)를 액터를 이용하여 언급했다. 단일 책임의 원칙이라는 이름은 마치 한 가지 일만 해야 하는것처럼 오해를 불러일으키기 좋다. SRP의 진정한 의미는 "하나의 모듈은 하나의 액터에 대해서만 책임져야 한다."이다. 자세한 내용은 ocwokocw.tistory.com/30 를 참조하길 바란다.

---

- UML과 유스 케이스

유스 케이스는 UML에서 큰 비중을 갖는다. 흔히 UML을 배울 때 유스 케이스에 대해 오해하는 측면이 있는데, UML이 유스 케이스를 모두 표현할 수 있다고 맹신하는것이다. 특히 Tool 에 집착하는 성향이 있는 사람이라면 이런 오해에 빠지기 쉽다. 

 

UML은 유스케이스 다이어그램을 표현하며, 이것은 유스케이스들의 연관관계를 보여주는것이지 그 내용 자체를 보여주는것이 아니다. 유스 케이스의 내용을 표현한 텍스트는 저급하며, UML로 화려하게 그린 다이어그램은 보기가 좋다고 해서 더 가치가 높은것은 아니다. 유스 케이스는 내용이 본질이다. 이점을 명심해야 한다.

---

- 유스 케이스와 내용

유스케이스의 내용을 어떻게 기술해야한다는 표준은 없다. 하지만 일반적으로 사용하는 형식은 있다. 일단 주된 메인 성공 시나리오(main success scenario)를 생각한다. 각 단계별로 번호를 붙여서 기록하고, 다른 시나리오는 확장(extension)으로 기록한다. 확장은 메인 시나리오의 변형이다.

 

액터에는 두 가지 타입이 있다. 주 액터는 유스케이스가 수행하려 하는 목표를 가진 액터이다. 그리고 유스케이스를 수행하는 동안 시스템과 통신하는 다른 액터가 있다면 이는 보조 액터이다.

 

각 단계는 액터의 행동을 표현하는것이 아니라 의도를 표현해야 한다. 또 유스케이스는 보통 사용자 인터페이스 디자인 전에 이루어지기 때문에 사용자 인터페이스를 기술하지 않는다. (ex - 버튼을 누른다.)

확장에는 조건이 발견되는 단계의 이름과 짧은 설명을 달아준다. 확장단계가 종료된 후 메인으로 돌아갈때 돌아가는 시점을 기록하면서 끝낸다.

 

유스케이스 단계가 복잡하다면 또 다른 유스케이스를 포함(include)하고 있을 가능성이 크다. 위의 유스케이스에서 1.단계와 같이 밑줄로 표현하거나 하이퍼링크를 단다. 이런 표현이 유용하기는 하지만 기능으로 나누어서 하위의 하위를 달거나 이런 구조에 집착하면 안된다. 이는 본질을 벗어나서 행위이다.

 

시나리오 뿐만 아니라 아래 정보도 더할 수 있다.

• 선행 조건(pre-condition) : 유스 케이스를 시작하기전에 만족시켜야 하는 조건.
• 보장(guarantee): 유스 케이스가 끝나면 보장하는것을 나타낸다.
• 트리거(trigger): 유스 케이스를 시작하도록 하는 이벤트

 

유스 케이스를 작성할 때에는 간결해야 한다. 일단 내용이 길면 아무리 좋은 유스 케이스라도 읽기 싫어하는 경향이 있다. 또한 몇 개 중요한 유스케이스에 대해서만 자세히 기술해야지 모든 유스 케이스를 자세히 기술하는데에 집착하면 안된다.