CODEWITHSUNDEEP
includeumlextenduse-caseuse-case-diagram
teddy
teddy

Reputation: 27

Why do we need to separate or breakdown one Use Case into two or more use cases?

Why do you need to, in many instances, separate or breakdown one Use Case into two or more use cases?

Upvotes: 2

Views: 1961

Answers (2)

www.admiraalit.nl
www.admiraalit.nl

Reputation: 6089

The only reason to split a use case in multiple use cases is to share a significant piece of functionality among multiple use cases by isolating that piece of functionality in a separate use case.

Example: 'search product information' may be a separate use case included by use cases 'buy product' and 'hire product'.

Apart from 'include' there are also examples of the same principle using 'extend' or 'generalize'.

By doing so, you prevent that the shared behaviour is copied in multiple use cases, with the chance of growing inconsistencies.

In the previous example: We want to make sure that customers don't get a different way to search for product information when buying compared to when hiring products. With an included use case, people who read the use cases are immediately aware of that fact.

Upvotes: 1

qwerty_so
qwerty_so

Reputation: 36313

First of all: you don't. Starting to do that means you are doing functional analysis. The point in use case synthesis is to find the goal(s) (aka. added value) the different actors have when interacting with the system under consideration. It's quite futile to separate a goal into sub-goals at that level. Either you have some added value or you don't have it. So if someone has settled a use case and tries to break it down then the use case is either wrong (no use case) or it's useless since the use case already shows the added value.

My personal opinion about include and extend: they are basically evil and a wrong concept introduced by techies (which most of the UML designers are) with no business background. Using them means you are already starting functional analysis. But UCs are synthesized from requirements. That is, you drag your net through that requirements soup and fish out those that fit together to build a story which makes sense - and which delivers added value: a use case.

And as always: read Bittner/Spence about use cases.

Upvotes: 0

Related Questions