Use Case Analysis

1. Use Case Analysis From soft systems methodology to understanding the system functionality

2. The Vision SSM Models Databases Use Cases Programs Activity Models Object Models Dynamic Models Computing Business

3. Beginnings of a Method Soft Systems Model

4. Use Case Models • Consist of • Use Cases • Actors • Relationships between Actors and Use Cases

5. What is a Use Case? Formal definition“A Use Case is a sequence of transactions performed by a system that yields a measurable result of values for an actor” A Use Case: • is a meaningful piece of system functionality • models a dialogue between a user and the systemNote - The user can be another system • is more than a simple transaction (e.g. enter customer address)

6. We draw a use case as:

7. Examples of Use Cases • Print Invoice • Correct Invoice • Chase Payment • Register Bad Debt

8. What is an Actor? • Anyone or any thing that uses or interfaces with the system, such as: • customer • credit controller • EPOS system • Bank system

9. We draw actors as: An Actor

10. Actors and Use Cases • An Actor may use many Use Cases • A Use Case may interface with many Actors • We draw a simple line to indicate interaction

11. Relationships between actors and use cases A Use Case An Actor

12. Arrows indicate who initiates interaction A Use Case An Actor Sometimes the use case initiates interaction

13. Use Cases can be related • One Use Case may use another Use Case • Sometimes that use is an exception or alternative, and we say that one Use Case extends another Use Case

14. Stereotypes UML has a concept called a stereotype which is used to describe the type of relation ship that is being used. Stereotypes are written between guillemets << >> (pronounced “ gweemays”) which are placed on the relationship lines. Example <<extend>>

15. <<extend>> Chase Payment Issue Warning Letter Extend relationship Used where an alternative or an exception is being shown. In this case as part of a money collecting function, it is required that a warning letter is sent out. Note the direction of the arrow. It always goes from the extension to the base case.

16. Include relationship When use cases share the same piece of functionality, we use the include relationship whereby the common use case is linked to the use cases that use its functionality. In this case, the Validate User use case needs to be used for takingan order and for displaying user information Note direction is from base to extension case Confirm details <<include>> Validate user Take order <<include>>

17. SSM Conceptual Model Any use cases here?

18. Initial thoughts on a development method

19. Problem Situation • Student Retention • Too many students enrol on a course then withdraw in their first year • Need a software system to help solve the problem • An improved school intranet

20. Identify Relevant Systems • Admissions • Pastoral Care • Timetabling • Module Delivery • Peer Tutoring • Assessment • Attendance Monitoring • Research

21. Definition of a Pastoral Services System • A system under the control of an in-school counselling team – giving appropriate referrals to external agencies to students presenting personal problems to members of the counselling team.

22. Root Definition for Peer-Tutoring • A system owned by the school that provides study skills support to students using volunteers from the student body with the quality of their support activities monitored by academic staff

23. Conceptual Model Identify suitable peer tutors Advertise Receive tutee Train peer tutors Document tutee needs Document Skills of peer tutors Book times and rooms

24. Attendance Monitoring

25. Related Use Cases Let’s consider this one

26. Create Class List

27. The information displayed here might be brought together through collaboration between objects

28. Class Diagram showing relationships between these objects

29. We can do two things with this class diagram • Implement it in an OOPL • Translate it into an entity model then implement the entity model as a relational database

30. We’ve considered how class diagrams can be implemented in an OOPL

31. And how class diagrams can drive database design • When the computer is switched off…. • …the data used by the class diagram must be stored in a database

33. My Next Example Program

34. Another Student

35. The Underlying Database

36. The Program that uses the Database

37. The Class Diagram

39. Get Group Student Numbers Get Student Number

40. Get Module Results Get Student Marks

41. Three Tiers

42. Classic Three Tier Architecture An interface developed in Visual Basic or HTML? An implementation of the class diagram using VB class modules or Java? An implementation of the entity model in MS Access, ORACLE, MySQL?

43. Back to Use Cases

44. Finding Use Cases (cont’d) • Examine all the activities in the conceptual model and determine where the system is used • Big use cases sometimes naturally break down via includes and extends • Elaborating the use case often finds other use cases

45. Finding Use Cases (cont’d) To fulfil a defined role: • What do users need to be able to do? • What are users trying to accomplish • What are the main tasks of users in this role? • What information do users in this role need to examine, create, or change? • What do users in this role need to be informed of by the system? • What do users in this role need to inform the system about?

46. What do Students do? • Enroll in, attend, drop, fail, and pass modules. • Need a list of available modules. • Need to determine basic information about a module, such as its description and its prerequisites. • Obtain a copy of their transcript, their course schedules, and the fees due. • Pay fees, pay late charges, receive reimbursements for dropped and cancelled modules, receive grants, and receive student loans. • Graduate from a school or drop out of it. • Need to be informed of changes in modules, including room changes, time changes, etc.

47. Prototyping and Use Cases • Interface prototypes are good for: • Agreeing user interaction (HCI factors) • Clarifying with users • Determining data requirements • Working out how to group use cases in interfaces

48. Use Case Proforma • Number and Name • Primary Path • Pre- and post-conditions • Alternatives and Exceptions • Related Use Cases • Prototype Interfaces • Activity Diagrams • Supported Business Processes / Activities • Notes

49. A Use Case Catalogue • Is a Substantial Document • Overviewed by set of Use Case Diagrams • Has Individual Use Cases • Linked into CASE tool • This is your requirements definition!

50. Invoicing use case (1)