IS0514 Lecture Week 4

1. IS0514 Lecture Week 4 Use Case Modelling (2)

2. Today's Lecture • Revision – use cases • Use case scenarios • What is a use case description? • Use / misuse of use cases

3. Exercise 1 Issues to consider .... • In groups of 3-4 spend 5 minutes discussing • What do Use Case Diagrams show you? • How do they help in understanding problems? • What is missing from Use Case Diagrams? • At the end of this time please be ready to share your findings

4. Exercise 1 - Answer

5. Use Case Description • Use Case Description is • A detailed description of a use case • Will be text • Typically in the form of a use case template (more later) • Can include: • Models -Activity diagrams (next year) • User interface designs (next year) • Other documents that help describe what happens in a use case (next year) • Describes what is required to satisfy the use case

6. Use Case ModelingOne Approach Develop Use Case Diagram Scenarios are different paths through a use case Develop Scenarios This is the process suggested by the unified process Develop Use Cases (Descriptions)

7. Use Case Modeling • Identify actors • Identify use cases • Link actors to use cases • Show the system boundary • Identify relationships between use cases • Consider scenarios • Write use case descriptions • Validate with stakeholders

8. Scenarios • Unfortunately this is a widely used and often ambiguous term • You will come across the term scenario to mean a domain description • Sometimes it is synonymous with use case • In UML the term scenario refers to a single path through a use case • A use case usually has several associated scenarios (although it can have only one)

9. Identifying Scenarios • Consider all the possibilities in the use case • Identify the normal (primary) scenario associated with the use case • What typically happens • Ignore any complications • Identify the exceptions to the normal action:- • Alternative scenarios • Things that could happen • Exceptional scenarios • Things that could be considered errors that need to be caught • Each scenario should be presented as a series of simple numbered steps in text format

10. Simple Scenario – Make Tea • Normal Scenario: • Switch on kettle to boil water. [A1: Kettle empty] • Place tea bag and milk in mug. • When kettle has boiled pour boiling water into mug. • Let tea brew and then remove tea bag and put tea bag in the bin. • Alternative Scenarios: A1. Kettle empty • Fill Kettle with water. • Use case continues from step 1. • Exceptional Scenarios: E1. No milk • Sorry, have tea without milk. • Use case terminates. What other scenarios are there?

11. Exercise 2 – Use Case Scenarios • Remember Space Invaders • One use case was “move left” • Identify • Normal Scenario • Alternative Scenario • Exceptional Scenarios http://www.neave.com/games/invaders/

12. Exercise 2 - Use Case Scenarios (for the Move Left use case)

13. Use Case (Description) includes : • Title/Heading • Summary • Actors • Trigger condition • Primary Scenario • Alternative Scenarios • Exceptional Scenarios • Options: • pre-conditions • post-conditions • assumptions

14. Exercise 3 • Look at the example use case description “Move Left” • Attempt to write a use case description “Move Right”

15. Exercise 3 - Answer • Very similar to “Move Left”

16. Exercise 4 • Attempt to write a use case description “Fire Laser” in your own time.

17. The use of Use Cases • Use cases are used to capture functional requirements • Most use case modeling will happen during the early part of a project • They drive the rest of development • You build what the client wants! • Used as part of planning, testing and evaluation • New Use Cases will continue to emerge as project iterates

18. Possible problems withUse Case modeling • Danger of building a system which is not object oriented • Avoid function decomposition • i.e. developing a top-down function based system • Need other views • Class Diagrams / Communication / Collaboration diagrams • Danger of mistaking requirements for design • You are analysing not designing - avoid technical detail • Possibility of missing requirements if too much emphasis is placed on actors • Incomplete picture • Non-functional requirements • Usability requirements

19. Use Case ModellingA More Realistic Approach Develop Use Case Descriptions Develop Scenarios Develop Use Case Diagram Iterative?

20. Extracting informationfrom Use Case modeling • Candidate objects • Attributes • Operations • Forms a basis for subsequent modeling activities To be used later in class diagrams, interaction sequence diagrams, statecharts, communication diagrams, etc.

21. This weeks reading ESSENTIAL READING Dennis A, Wixom B, and Tegarden D (2005) System Analysis and Design with UML version 2 second edition, Wiley Pages 171-209 Further reading Bennett, S., McRobb, S. and Farmer, R. (2002) Object-Oriented Systems Analysis and Design using UML, 2nd Edition, McGraw-Hill Pages 133-146 • http://www.omg.org • http://alistair.cockburn.us/usecases/usecases.html

22. Summary • Use case diagram • High level view of functional requirements • Use case description • Detailed view of functional requirements • Use case template • Use case scenarios • Normal / Alternative / Exceptional • Use / misuse of use cases • Next Week • Introduction to Object-Orientation