Requirements Modelling and Specification for Service Oriented Architecture

7.2. Some Problems with the Conventional Approach to Use Cases

Use cases were first introduced as a technique for specifying telephone switching systems at Ericsson and were later recognized as a brilliant and useful idea by the object-oriented methods community. Most methodologists of that generation integrated use cases into their methods and they are a key feature of UML. Use cases offered possibly the first technique within object-oriented development that did not assume that a written system specification existed at the start of object-oriented analysis.

In this section I consider a number of features of the conventional use case approach that militate against its successful use. In the next we will see how these may be overcome. The problems are, in brief, as follows.

• Overemphasis on functional decomposition.

• Lack of a clear definition and agreed interpretation.

• The inappropriate use of controller objects.

• Confusion over the relationship of use cases with scenarios.

• Lack of a notion of genericity.

• Lack of a notion of atomicity.

• Too much detail and too many use cases as a result of poor abstraction.

• Poor exception handling.

7.2.1. Overemphasis on Functional Decomposition

At first sight, the use case approach appears to have a more functional flavour than an object-oriented practitioner would be comfortable with. Blaha and Premerlani (1998), leading thinkers behind OMT, go so far as to include a treatment of use cases within the dataflow-based Functional Model of that method. This ...