[UML 실전에서는 이것만 쓴다 :: 5장] 유스케이스

유스케이스 적기

유스케이스는 그리지않고 글로 적는다. 유스케이스는 다이어그램이 아니다. 

 

• 유스케이스란 무엇인가
  • 시스템의 동작 하나를 기술한 것
  • 방금 시스템에 특정한 일을 시킨 사용자의 관점에서 적성하며, 사용자가 보낸 자극 '하나'에 대한 반응으로 시스템이 진행하는 '눈에 보이는' 이벤트들의 흐름을 포착한다.
  • 사용자의 눈에 보이지 않는 동작을 전혀 기술하지 않고 시스템 안에 숨겨진 메커니즘도 다루지 않는다.
  • 오직 사용자가 직접 볼 수 있는 것을 적어 놓을 뿐이다.

 

유스케이스를 구성하는 항목은 보통 두 개이다.

 

• 기본 흐름 (primary course)

사용자의 자극에 시스템이 어떻게 반응하는지 기술하는데 이때 아무것도 잘못되지 않는다고 가정한다.

 

ex ) 판매 시점 관리(point of sale. POS) 유스케이스 :: 상품을 구입하기

1. 점원은 상품을 스캐너 위로 통과시킨다. 스캐너가 UPC 코드(바코드)를 읽는다.

2. 상품 가격과 설명이 지금까지 통과시킨 상품 가격의 합계와 함께 고객과 점원 쪽 화면 에 표시된다.

3. 가격과 설명이 영수증에 출력된다.

4. UPC 코드가 올바르게 읽혔는지 점원이 확인할 수 있도록 시스템이 잘 들리는 "승인" 소리를 낸다.

 

• 유스케이스를 며칠 또는 몇 주안에 구현하지 않는다면 이런 세부사항을 기록하지 않을 것이다.
• 세부사항을 기록하지 않고 프로젝트의 이해관계자와 이야기하며 대강 추정하면 충분한 정보를 얻을 수 있다. 
• 이때 그 내용을 기록할 필요가 없는데, 내일이면 세부사항들이 또 바뀔 것이기 때문이다.
• 세부사항 대신 유스케이스의 이름을 기록하라.
• 구현할 때가 가까워지면 세부사항을 채워 넣는다.

 

• 대체 흐름

유스케이스의 세부사항 가운데 일부는 일이 잘못되는 경우(실패 시나리오)를 고려해야 한다.

 

ex ) UPC 코드를 읽지 못했을 경우

1. 시스템은 점원이 다시 시도하도록  "다시 통과시키시오" 소리를 낸다.

2. 세 번 시도했는데도 스캐너가 UPC 코드를 인식 못하면, 점원은 직접 코드를 입력해야 한다.

 

ex ) UPC 코드가 없을 경우

점원은 가격을 직접 입력해야 한다.

 

• 나머지는?

액터나 2차 액터, 선행조건, 후행조건 등은 신경 쓰지마라. 대부분의 작업에서 이것들을 거의 알 필요가 없다.

절대로 유스케이스를 적는 것 자체를 목적으로 삼고 자리에 앉아 시간을 허비하지 마라.

 

유스케이스 다이어그램

시스템 경계 다이어그램을 제외하고 사용하지 말 것.

 

• 시스템 경계 다이어그램

 

• 커다란 사각형이 시스템 경계다.
• 사각형 안에 들어있는 것은 모두 개발 중인 시스템의 일부다.
• 액터 : 시스템에 자극을 가하며 시스템 바깥에 있는 존재. 사용자인데 대개 사람이다. 간혹 다른 시스템이나 심지어 실시간 클럭같은 장치가 액터가 될 수도 있다.
• 유스케이스 : 타원 안에 그 유스케이스의 이름을 써서 나타낸다. 화살표는 그리지 말 것.

※ 이 다이어그램은 아예 쓸모없지는 않지만 쓸모없는 것과 마찬가지다. 자바 프로그래머에게 도움이 될 정보는 거의 없지만, 프로젝트 이해관계자에게 프레젠테이션할 때 멋진 표지로는 좋다.

 

• 유스케이스 관계(use case relationship)

'그때는 참 좋은 생각으로 보였는데' 범주에 들어가는 아이디어. 무시하길 권장.

 

결론

유스케이스를 단순하게 유지하라.