CMPT 275 Software Engineering

1. CMPT 275Software Engineering Requirements Analysis Phase Requirements Analysis Activity (use cases)

2. Class Project: Requirements Analysis • Next you will proceed using use case centered development (UCCD) to your requirements model • System Context Diagram • Identifying Actors and developing Use Cases • Primary classes • Use cases and Scenarios (formal and informal) • Use case Diagram • Class (object) Diagram • State Diagrams

3. Requirements Analysis Activity Software Developer Client/User Update SRS Use Case Centered Development (UCCD) Questions Use Case Diagram Use Cases System Context Diagram Class Diagram Primary Classes Scenarios State Diagram

4. Actor • Entity outside the software system • interacts with the system • Operates on objects in the system but cannot be operated upon by objects in the system. • Human, hardware device, another software system • Represents coherent role played by users • e.g.: In an automated registration system teacher, student, registrations data base

5. Actor • A user of software system may take on more than 1 role, usually at different times • e.g.: Eva interacts with the system not only as a student actor but also as a teacher actor • Eva teaches math, but is a student of French • An actor may represent more than one user • e.g.: Both Eva and John may take the role of a student

6. Primary and Secondary Actors • Primary Actors • Actors who initiate a scenario (use case) causing the system to achieve a goal • automated registration system example the student or teacher is a primary actor • Secondary Actors • Actors supporting the system so primary users goals can be completed (do not initiate the use case or scenario) • automated registration system example the registration data base is a secondary actor

7. System Context Diagram: LMS Show how the software system interacts with its environment Librarian Resources (Books, CDs ..) Patron Software System Being created Employee Information Repository (DB) Web Libraries Resource Information Repository (DB) Online Journals Student Information Repository (DB)

8. Use Cases • Specify the behaviour of the system from the user’s perspective • Provides value to at least one user of the system • Describe a sequence of actions, performed by the system, to yield a result desired by that user • The behavior of the system is expressed without specifying how the behavior is implemented (What is behavior, not how is it done) • To get started generalize an informal scenario (or closely related set of informal scenarios) • Informal scenarios are a good starting point

9. Use Case Format • Use Case Name (+ Functional Requirement #s) • Usually short active verb phrase related to behavior modelled by the use case • Participating actors • Preconditions • What conditions must be true at the beginning of the use case? • Main flow of events

10. Use Case Format • Main flow of events • Indicate how and when use case starts • Describe the essential behavior associated with the use case • Post conditions • What occurs as a result of the use case executing • Describe state of system • Exceptional flow of events (zero to many) • Enumerate possible erroneous flow of events

11. Building a use case • Start with your informal scenario for a basic function of the system • As an example use the Check in resource case for the LMS, using an example scenario illustrating the most common case. (Book checked in, no extra problems) • Build a first draft of your use case based on this use case • Consider other related use cases, add the exceptional conditions that may occur in related informal scenarios • Revise your use case to include actions needed to also model the related informal scenarios.

12. Sample LMS use case: 1 • Use case name: CheckInResource (Functional Requirement #7) • Participating actors: Librarian and Patron • Preconditions • Librarian and patron validated to LMS • Library DB initialized

13. Sample LMS use case: 2 • Main flow of events • Librarian enters resource’s call number • The status of the resource is changed to "reshelve“ • Return date is reset • Librarian indicates that he is done

14. Sample LMS use case: 3 • Postconditions • Patron DB entry updated to reflect returned resource • Resource DB entry updated to reflect changed status: reshelve • Exceptional flow of events (some examples) • Resource call number not valid • Resource is overdue • There is a hold on the resource

15. Building Use Cases • Building your use cases is an iterative process • When you have a use case like the one we just built read through it carefully and identify exceptional (special) cases • The exceptional cases we have identified are shown in part F of the previous slide • Determine what needs to be done in each of these exceptional cases and add the information to the use case

16. Revised Check in Use Case: 1 • Use case name: CheckInResource (Functional Requirement #7) • Participating actors: Librarian (Patron does not directly interact with the system so is not a participating actor unless they are doing the check out themselves)

17. Revised Check in Use Case: 2 • Preconditions: • Librarian is a valid librarian • LMS is ready to go (DB has been populated and LMS has been initialized) • Initial Option screen displayed (your mock up should tell you what information will be on the option screen) • Main flow of events: • The use case starts when Librarian selects CheckInResource option.

18. Revised Check in Use Case: 3 • Main flow of events (cont): • Librarian enters the Dewey call number for the resource (HOW: either scan or type in #) then checks and commits the entry (HOW: by pressing the Enter key). • The LMS checks that the Dewey call number for the resource has been entered successfully and it is valid (i.e., it does refer to a resource of this library) • The LMS finds the resource and finds its borrower, then displays the resource and patron information on the screen.

19. Revised Check in Use Case: 4 • Main flow of events: (cont) • The DetermineOverdueCharge use case is initiated. • LMS verifies that there is no outstanding request for this resource. • The LMS changes the status of the resource to "reshelve" and cancels its "due date" and "date of loan" and updates "date of return". • LMS updates the screen showing the newly checked-in resource along with the updated dates. • The use case terminates when Librarian indicates that she/he is done.

20. Revised Check in Use Case: 5 • Postconditions: • Patron record updated to reflect the newly checked in resource. • Resource record updated to reflect its checked in status and dates. • Return to the initial Option screen.

21. Revised Check in Use Case: 6 • Exceptional flow of events: • Exceptional flow of events #1 • If the Dewey call number was entered incorrectly, LMS states so and the use case terminates. • Exceptional flow of events #2 • If the Dewey call number entered is invalid (does not exists in LMS DB), LMS states so and the use case terminates.

22. Revised Check in Use Case: 7 • Exceptional flow of events: • Exceptional flow of events #3 • If there is an outstanding request for this resource, LMS changes the status of the resource to “requested“, cancels its "due date" and "date of loan" (perhaps updates "date of return"), updates the screen showing the new state of the resource and the use case terminates.

23. Building Use Cases • Remember that building your use cases is an iterative process • When you have a use case like the one we just built read through it carefully and look for more possibilities • E.G. what happens if the resource the patron is trying to check in has not been checked out • Add these additional possibilities and integrate them into the use case. • Continue iterating till you cannot see any other possibilities

24. Characteristics of Use Cases • Use cases are more abstract than informal scenarios, because … • A single use case may encompass multiple informal scenarios • Use cases avoid redundancy • Use cases are more formally structured than informal scenarios • Use cases seek to capture complete breadth of system behavior

25. Use case modeling • Identify actors • Define the scope of the system (context diagram) • Use scenarios, along with mock ups for visual support, to help you validate requirements with the client • Build a set of use cases that encapsulates the requirements • How do we verify that our use cases are complete, consistent, and unambiguous? Use a use case diagram