유스케이스 드리븐 방식의 한계

- 유스케이스 드리븐 방식은 식별된 유스케이스로부터 공통된 객체를 식별하는 방법으로 가장 널리 사용되는 방법 중의 하나이다.
- 그렇지만, Don Firesmith 는 다음과 같이 유스케이스 드리븐 방식에 대해서 반대입장을 표명했다. [Firesmith1996]
“유스케이스는 객체지향 방법이 아니다. 각각의 유스케이스는 객체 기술에서 지양해야 하는 기능 분해 관점에서 수많은 문제점을 야기시킬 수 있는 주요한 기능적인 추상화를 담고 있다... 객체와 클래스가 식별되기 이전에 유스케이스가 먼저 식별되었기 때문에 유스케이스는 객체에 대한 속성과 오퍼레이션을 무시하게 된다.”
계속해서 그는 유스케이스 드리븐 방식이 “전형적인 서브시스템 아키텍처 형태를 띠며... 개개의 유스케이스의 로직을 표현하는 단일 기능 컨트롤 객체와 컨트롤 객체에 의해서 제어되는 몇몇 사소한 엔티티 객체가 식별되며...그러한 아키텍처는 일반적으로 캡슐화에 취약하며, 과도한 커플링을 양산하며, 클래스간 어플리케이션의 기능을 부적절하게 분산하게 되는 ”형태를 띨 것이라고 말하고 있다.
- Jacobson[Jacobson1992]도 유스케이스를 ‘테스팅과 산출 시스템’이라는 또 다른 목적으로써 바라보고 있다. ‘유스케이스는 명시적으로 여러 클래스와 블록(모듈 혹은 컴포넌트)과 상호 연결되어 있어서 통합 테스트에 아주 훌륭한 기반을 제공한다. 모든 유스케이스가 (다양한 수준에서) 테스팅된다면 시스템은 전체적으로 테스팅된다.’
- 유스케이스는 이미 식별되고 구체화된 객체에 대한 오퍼레이션 관점에서 쓰여지고, 해당 객체 모델을 테스트하는데 사용되면 가장 강력하다고 말할 수 있다. 반대로, 유스케이스는 객체 모델이 식별되기 전에 쓰여지고, 객체와 그 책임성을 식별하는데 사용된다면 가장 위험하다고 할 수 있다.
- 그렇다면, 비즈니스 객체를 어떻게 식별해야 하는지의 의문이 남는다. 그 해답은 사용자와 개발자 간에 직접적이고 구조화되지 않은 대화를 통해서 얻을 수 있다. 직접적인 상호작용 혹은 ‘온 사이트 고객’ 이라는 개념은 ‘agile’ 방법론에서 주창하는 것이다. 이러한 상황에서 능숙한 객체 모델러는 다른 공식적인 산출물 없이 직접적으로 객체를 식별할 수 있다는 근거가 많이 있다. [Rosson1989]

[Firesmith1996] Firesmith, D. (1996). Use Cases: The Pros and Cons. in Wisdom of the Gurus. R. Wiener. New York, SIGS books.
[Jacobson1992] Jacobson, I., M. Christersson, et al. (1992). Object-oriented Software Engineering: A Use Case Driven Approach. Reading, MA, Addison-Wesley.
[Rosson1989] Rosson, M. B. and E. Gold (1989). Problem-Solution Mapping in Object-Oriented Design. OOPSLA 89, New York, ACM.