객체지향의 사실과 오해 - 기능

- 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.)

- 유스케이스

기능적 요구사항이라는 말을 들어본적이 있을것이다. 기능적 요구사항이란 시스템이 사용자에게 제공해야하는 기능의 목록이다. 시스템은 사용자의 목표를 달성하기 위해 기능들을 제공하는데 사용자가 시스템에 작업을 요청하고 시스템은 이 요청을 처리하여 응답한다. 이러한 과정은 사용자가 목표를 이루거나 에러가날 때까지 계속된다.

 

유스케이스는 사용자의 목표 달성을 위해 사용자와 시스템간의 상호작용의 흐름을 텍스트로 정리한것이다. 시스템이 제공해야 하는 기능 목록을 모두 만족하면 사용자의 목표를 이룰 수 있는데 왜 굳이 유스케이스 라는 것을 따로 작성해야 하는가?

 

시스템이 제공해야하는 기능 목록을 계속 읽다보면 내가 읽고 있는 기능이 도대체 무엇을 의미하는지 그리고 이 기능이 시스템에서 어떤 의미인지 알 수 없게 된다. 유스케이스는 사용자의 목표를 위한 기능들을 시나리오 형식으로 묶어 놓은것이기 때문에 단순하게 목록형식으로 파악하는것 보다 정신적 과부화를 줄여준다. 즉 기능과 다른 기능의 관계, 이 기능이 시스템에서 어떻게 쓰이는지를 파악하기가 용이하다.

---

- 유스케이스의 특징

아래는 유스케이스 예제를 보여준다.

위의 예제와 함께 유스케이스의 주요 특징을 알아보자.

 

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 텍스트다. 유스케이스가 텍스트라는게 특징이라고 할만한것 인지의문이들 수 있다. 이 특징은 UML 서적에서 유스케이스 다이어그램을 접한 사람이 빠지기 쉬운 함정에 관해 언급하고 있다. 인간은 글보다 도식화된것을 볼 때 훨씬 직관적으로 느낀다. 이런 특성으로 인해 텍스트로서의 가치가 있는 유스케이스를 과도하게 다이어그램으로 변경하려고 한다.

위는 유스케이스 텍스트 예제를 다이어그램으로 표현한것이다. 물론 주석이나 노트 기능을 이용해서 부연설명을 할 수 있지만 다이어그램만으로 특별한 정보를 파악하기는 힘들다. 유스케이스의 가치는 UML 다이어그램을 화려하거나 엄격한 잣대로 그리는것이 아니라 텍스트에 그 본질이 있다고 할 수 있다.

 

2. 유스케이스는 하나의 시나리오가 아니라 시나리오들의 집합이다. 유스케이스 예제에서 3. 과 3a. 를 보면 예금주가 계좌를 선택하고 당일까지의 이자액을 계산하는것과 특정 일자까지의 이자액을 계산하는 2 개의 시나리오를 포함하고 있는것을 알 수 있다.

 

3. 유스케이스는 피처 목록과 다르다. 유즈케이스의 1,2,3,4 는 단순한 기능 목록이라고 볼 수 있다. 이를 따로따로 분석하면 이런 기능들이 서로 연관성이 있는것인지 알 수 없다. 하지만 이를 '중도 해지 이자액을 계산한다.' 라는 하나의 이야기속에서 보면 관점이 달라진다.

 

4. 유스케이스에서 사용자 UI 를 언급해서는 안된다. 나도 UML 에 대한 설명을 보기전에 유스케이스 예제를 보고 단순하게 작성했을 때 했던 실수였다. 예를 들어 '달력 버튼을 눌러서...', '검색 버튼으로.... 조회한다.' 와 같이 유스케이스는 UI 와 관련성이 있어서는 안된다. UI 는 언제든지 변할 수 있기 때문에 시스템의 행위에만 초점을 맞추어야 한다.

 

5. 4.와 같은 기조로 내부 설계 정보를 포함해서는 안된다. 유스케이스는 시스템의 기능들을 시나리오로 묶는것이지 내부 설계를 기술하기 위한것이 아니다. 

---

- 유스케이스의 오해

유스케이스는 기능 목록을 시나리오로 묶는 작업이기 때문에 객체지향에 종속된 기법도 아니며, 유스케이스를 통해 시스템의 내부 구조도 알 수 없다. 어떤 공학적인 기법도 획기적으로 유스케이스를 객체로 깔끔하게 변환할 수 없다. 이는 순수한 창조성을 띤 작업이다. 또한 도메인 모델에 사용할 용어에 대한 힌트를 얻을 수는 있지만 이를 통해 도메인 모델링을 잘할 수 있는것도 아니다.