1 / 54

Use Case Analysis

Use Case Analysis. From soft systems methodology to understanding the system functionality. The Vision. SSM Models. Databases. Use Cases. Programs. Activity Models. Object Models. Dynamic Models. Computing. Business. Beginnings of a Method. Soft Systems Model. Use Case Models.

aquila
Download Presentation

Use Case Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  32. My Next Example Program

  33. Another Student

  34. The Underlying Database

  35. The Program that uses the Database

  36. The Class Diagram

  37. Get Group Student Numbers Get Student Number

  38. Get Module Results Get Student Marks

  39. Three Tiers

  40. 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?

  41. Back to Use Cases

  42. 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

  43. 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?

  44. 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.

  45. 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

  46. 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

  47. 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!

  48. Invoicing use case (1)

More Related