Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake1 Special Relationships between Use Cases Normally it is not necessary to identify interactions between use cases (too much detail for this stage) However the functionality of a use case can sometimes be split up into “modules” by –Extends – this means optionally extended by another use case –Includes or Uses – this means always uses another use case original by K.Ingram & J.Westlake

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake2 The Extends relationship If 2 use cases are similar but 1 does more than the other, can you identify some common functionality? If so, consider putting the common functionality in 1 use case and the extras in a second - the second then “extends” the first.

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake3 Example of Extends If your customer tries to pay for a rented DVD but has forgotten their wallet, you may put the DVD behind the counter until they return with the money. This is an extension to the normal use case of ‘Pay for DVD’ to bundle it up with the usual situation will clutter up the logic

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake4 Example Use Case Diagram of Extends Customer Pay for DVD No money > Note the direction of the Arrow – the No Money use Case optionally happens

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake5 Identifying Extends relationships 1. Document the normal, simple use case 2. identify “what could go wrong?” 3. identify “how may it work differently?”

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake6 The Includes (or Uses) relationship Do two (or more) use cases have a chunk of identical functionality? If so, consider extracting the common functionality from both and putting it in another use case - this can then be > by each of the others. You may see > in your reading but > is now written instead

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake7 Example of Includes If a customer asks for a particular DVD the assistant checks where the copies are. If the manager is doing stock checks this may include finding where specific titles are. to include a find it or search for in each of the original use cases means you would have to handle it twice in your UML, to code it twice, to test it twice,….

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake8 Example Use Case Diagram of Includes Customer > Request DVD Manager Check stock Locate DVD Note the direction of the Arrow – to Check Stock the use case ALWAYS includes the use of Locate DVD use case

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake9 When is a Use Case not a Use Case? A use case is a process or sometimes referred to as a business function required of the system being considered a use case can normally be broken down into many steps - each individual step is not shown as a separate use case. A use case can be carried out at One Time, in One Place, by One Person (OTOPOP). –The person being an Actor role

Staffordshire UNIVERSITY School of Computing Version Jan 08 original by K.Ingram & J.Westlake10 One diagram or many? Too much on a diagram negates its purpose You may decide it all fits on 1 diagram or you may decide to split the diagram –1 diagram for each actor –or 1 diagram for each main business activity Splitting the diagram means a Use Case or an Actor may be shown more than once – this is okay –As explained last week the best approach is top level view of use cases and then do a separate sheet for the use cases being broken down and then repeat at the next level if needs be