jaso extends j2ee :: 유스케이스 모델링은 글쓰기 이다.

- 유스케이스는 요구사항을 분석하는데 있어 아주 효과적인 기법임에도 불구하고 실제 프로젝트에서는 이를 제대로 사용하지 못하고 있는 것 같다. 프로젝트의 산출물을 분석해보면 기존의 기능챠트 수준의 유스케이스 도출과 디스크립션 작성으로 원래 유스케이스의 의미를 퇴색하게 하는 경우가 많다.

- 유스케이스 모델링은 유스케이스 다이어그램을 작성하는 것이 주 목적이 아니라 유스케이스 디스크립션을 작성하는 것이라 할 수 있다. 따라서 유스케이스 모델링은 글쓰기가 전부라고 할 수 있다.

- 유스케이스 다이어그램은 시스템의 경계 또는 범위를 나타내거나 유스케이스가 어떤 것들이 있는지, Actor가 어떤 유스케이스를 사용할 수 있는지를 표현하는 것 정도로만 활용할 수 있는 다이어그램이라고 할 수 있다. 실제 중요한 모든 내용은 디스크립션에 표현된다.

- 유스케이스 모델링을 하는데 있어 많은 프로젝트에서 다이어그램을 먼저 그린 후 디스크립션을 작성하는데 이것은 정말로 잘못된 방법이라 생각한다. 먼저 유스케이스를 도출한 후 도출된 유스케이스에 대해 메인 흐름에 대해 기술하면서 유스케이스의 수준을 조절하거나, 누락된 내용이 없는지 파악하여 모든 유스케이스에 대해 인식한 다음 유스케이스 다이어그램을 그리는 것이 바람직하다.
물론 최초에 그린 다이어그램이 확정되는 것이 아니기 때문에 다이거어그램을 먼저 그린 다음 이 다이어그램에 나타나는 유스케이스의 디스크립션을 작성하면서 다이어그램을 보완할 수도 있지만 이것은 생각보다 어렵다. 다이어그램을 먼저 그리게 되면 개발자의 생각속에는 다이어그램을 어떻게 그려야 할지가 관심의 대상이 되기 때문에 핵심인 디스크립션은 나중에 고려하기 쉽기 때문이다.

- 하나의 유스케이스는 단순히 게시글등록, 게시글삭제 등과 같이 CRUD 기준으로 결정하는 것이 아니라 액터에게 의미있는 단위(액터의 목적)를 하나의 유스케이스로 선정해야 한다.
예를 들어 메일시스템에서 액터는 메일을 작성하기 위해 "메일내용작성", "수신인지정(필요한 경우 동명이인검색)", "파일첨부", "메일전송" 등과 같은 단위를 만들 수 있지만 액터가 이러한 action을 수행히는 이유는 단 하나 메일을 보내기 위해서이다. 따라서 이런 경우 각각을 유스케이스로 정의하는 것이 아니라 "메일보내기" 와 같은 하나의 유스케이스로 도출해야 한다.

- 유스케이스의 도출은 1명이 작업하는 것이 아니라 규모에 따라 다르겠지만 하나의 시스템 바운더리당 고객이 포함되어4 ~ 5명 정도가 적당하지 않을까 생각한다. 1명이 작업할 경우 작업자의 수준에 따라 유스케이스 범위가 너무 자세하게 되거나, 너무 추상적이게 될 가능성이 많기 때문이다. 여러명이 작업하여 간단한 메인 흐름 정도까지 정의한 다음 각자 자신이 맡은 유스케이스에 대해 자세한 흐름을 작성하게 하는 것이 좋은 방법이다.

- 유스케이스 디스크립션이 보통 10페이지 이상이 되는 것을 보면 알 수 있다. 단순한 경우라 하더라도 3 ~ 4페이지 정도이고 많을 경우 20페이지 이상, 30 ~ 40페이지가 되는 경우도 있다고 한다. 유스케이스의 경우 시스템 규모가 크다 하더라도 50개 미만이라고 하니 유스케이스가 어느정도 수준에서 정해져야 하는지 알 수 있다.

- 단순 CRUD 형태로 유스케이스 시나리오가 나타나면 분명히 유스케이스를 잘못 잡은 것이다. 이렇게 도출되는 것은 요구분석 단계에서부터 이미 머리속에서는 개략적인 설계가 되어 관리해야 할 정보가 무엇인지 파악이 되고, 액터는 이들 정보를 관리함으로써 액터가 원하는 기능을 수행할 수 있다는 것을 알고 있기 때문이다.
단순히 ***관리라는 형태로 데이터 관리 위주로 유스케이스를 설정한 뒤 유스케이스 흐름에서는 단순히 "***를 입력한다", "등록 요청한다", "등록 후 결과를 보여준다" 이런 형태의 유스케이스 흐름이라면 단순히 다음과 같이 공통적인 양식으로도 사용할 수 있을 것이다.

*** 데이터에 대해 입력, 수정 삭제, 처리를 관리하고 주요 데이터 항목은 다음과 같으며, 입력시 주의해야할 사항은 다음과 같다.
[관리항목]
[입력시 주의사항]
[수정시 주의사항]
[삭제시 주의사항]

필자도 개발을 먼저 생각하기 때문에 ***관리 형태의 유스케이스를 먼저 생각하고 있다. 이것은 구조적 프로그래밍에서 객체지향 프로그래밍으로의 패러다임의 변화가 어려운 것처럼, 데이터 분석 기법에서 유스케이스 분석 기법으로의 변화가 패러다임의 변화에 버금가는 수준이기 때문이 아닐까 생각한다.

- 유스케이스 디스크립션의 Flow에 대한 설명은 한번에 완성하기 어려우며 여러번의 반복 작업을 통해 완성해 나가야 한다. 흐름내에서의 설명이 복잡하면 서브흐름으로 만들고, 흐름 내부에서 사용되어지는 일부 내용이 여러 유스케이스에서 사용되어지는 <> 관계가 있는 유스케이스로 도출하는 작업들이 이러한 반복 작업 중에 나타날 수 있다.

1.처음에는 간단한 메인 흐름만 기술
2.두번째 반복에서는 메인 흐름에서 액터가 입력하거나 시스템이 표시하는 내용들에 대해 추가
3.세번째 반복에서는 메인 흐름의 각 항목에 대해 추가 선택 사항을 도출하여 Alternative Flow 기술
4.Alternative Flow에 대해서 좀 더 상세하게 기술
5.복잡한 메인 흐름의 경우 서브흐름으로 도출(서브흐름은 복잡한 흐름을 제목정도만 작성한 후 동일 유스케이스 내에서 마지막에 서브흐름에 대해 설명하는 방식)
6.다른 유스케이스 작성시 기존의 유스케이스에서 사용된 서브흐름과 동일한 흐름이 계속 반복되는 경우 include 관계로 도출

- 유스케이스 디스크립션을 작성하는데 있어 일부 프로젝트에서는 표 형태의 정형화된 양식을 제공하고 있는데 필자의 경우 이런 양식보다는 free style로 작성하는 것이 더 바람직하다고 생각한다. 물론 반드시 포함되어야 할 내용들이 있기 때문에 다음과 같은 양식 정도가 어떨까.

1. 유스케이스명 :
2. 작성자 :
3. 액터 :
4. 개요 :
5. 선조건 :
6. 후조건 :
7. 메인흐름
8. 대안흐름 :
9. 예외 :
10. 서브흐름 :

- 기존의 방법론에서는 요구사항에 대한 구체적인 분석 기법을 제공하지 않았지만 유스케이스는 요구사항을 분석하는데 있어 실용적인 기법들을 제공하고 있다. 유스케이스를 이용할 경우 과거의 방법론에서 요구하는 산출물(요구사항정의서, 프로세스정의서 등)에서는 표현할 수 없었던 많은 부분을 설명할 수 있으며, 고객, 설계자, 코더, 테스터 등 다양한 이해관계자가 시스템의 기능적인 측면을 이해할 수 있는 핵심 산출물이 될 수 있다. 지금까지의 프로젝트에서 만들어진 어떠한 산출물을 보아도 시스템에서 사용자가 어떤 목적으로 시스템을 사용하고 있으며 각각의 목적을 달성하기 위해 어떤 세부적인 절차에 의해서 수행되어지는가에 대한 내용은 찾을 수 없는데 유스케이스가 바로 이런 목적으로 사용될 수 있는 산출물일 것이다.