1. 7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases

2. 7 Systems Analysis and Design in a Changing World, 4th Edition 2 Learning Objectives u What are use cases? u Use case diagrams u Use case and scenario descriptions

3. 7 Systems Analysis and Design in a Changing World, 4th Edition 3 Overview u Objective of requirements definition is understanding users’ needs, business processes, and system to support business processes u Understand and define requirements for a new system using object-oriented analysis models and techniques u Line between object-oriented analysis and object- oriented design is somewhat fuzzy l Iterative approach to development l Models built in analysis are refined during design

4. 7 Systems Analysis and Design in a Changing World, 4th Edition 4 Object-Oriented Requirements u Object-oriented modeling notation is Unified Modeling Language (UML 2.0) u UML was accepted by Object Management Group (OMG) as standard modeling technique u Purpose of Object Management Group l Promote theory and practice of object-oriented technology for development of distributed systems l Provide common architectural framework for OO

5. 7 Systems Analysis and Design in a Changing World, 4th Edition 5 Object-Oriented Requirements (continued) u Object-oriented system requirements are specified and documented through process of building models u Modeling process starts with identification of use cases and problem domain classes (things in users’ work environment) u Business events trigger elementary business processes (EBP) that the new system must address as use cases u Use cases define functional requirements

6. 7 Systems Analysis and Design in a Changing World, 4th Edition 6 Object-Oriented Requirements Models u Use case diagrams – i dentify actors and their use cases (goals) u Use case descriptions – include details of a use case and how actors use the system u Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case u Activity diagrams – describe user and system activities for a use case u State machine diagrams – describe states of each object

7. 7 Systems Analysis and Design in a Changing World, 4th Edition 7 Requirements Models—Traditional versus OO (Figure 7-1)

8. 7 Systems Analysis and Design in a Changing World, 4th Edition 8 The System Activities— A Use Case/Scenario View u Use case analysis used to identify and define all business processes that system must support u Use case – an activity a system carried out, usually in response to a user request u Actor l Role played by user l Outside automation boundary

9. 7 Systems Analysis and Design in a Changing World, 4th Edition 9 Techniques for Identifying Use Cases (Review from Chapter 5) u Identify user goals l Each goal at the elementary business process (EBP) level is a use case l EBP – task performed by one user in one place and in response to business event that adds measurable business value, and leaves system and data in consistent state u Event decomposition technique (event table) u CRUD analysis technique (create, read/report, update, delete) to ensure coverage

10. 7 Systems Analysis and Design in a Changing World, 4th Edition 10 Use Case Diagram u Graphical UML diagram that summarizes information about actors and use cases u Simple diagram shows overview of functional requirements u Can have multiple use case diagrams l By subsystem l By actor

11. 7 Systems Analysis and Design in a Changing World, 4th Edition 11 Simple Use Case with an Actor (Figure 7-2)

12. 7 Systems Analysis and Design in a Changing World, 4th Edition 12 Use Case Diagram with Automation Boundary and Alternate Actor Notation (Figure 7-3)

13. 7 Systems Analysis and Design in a Changing World, 4th Edition 13 All Use Cases Involving Customer as Actor (Figure 7-4)

14. 7 Systems Analysis and Design in a Changing World, 4th Edition 14 Use Cases of RMO Order Entry Subsystem (Partial Figure 7-5 with package symbol)

15. 7 Systems Analysis and Design in a Changing World, 4th Edition 15 > Relationship u Documents situation in which one use case requires the services of a common subroutine u Another use case is developed for this common subroutine u A common use case can be reused by multiple use cases

16. 7 Systems Analysis and Design in a Changing World, 4th Edition 16 Example of Order-Entry Subsystem with > Use Cases (Figure 7-6)

17. 7 Systems Analysis and Design in a Changing World, 4th Edition 17 CRUD Analysis for Identifying/Confirming Use Cases u CRUD – create, read/report, update, delete u Information Engineering (IE) technique to identify event table or directly develop use case diagram u Compares identified use cases with domain model class diagram u Every class in class diagram must have use cases to support creating, reading, reporting, updating, and deleting object instances u Confirms system integration requirements

18. 7 Systems Analysis and Design in a Changing World, 4th Edition 18 Use Case Description u Use case description provides details of preconditions, postconditions, sequence of activities, and exception conditions in use case u Describes actor interacting with computer system step-by- step to carry out business activity u May have several scenarios for a use case, each a specific use case instance u Three levels of detail: brief, intermediate, and fully developed description u Many analysts prefer to write narrative descriptions of use cases instead of drawing activity diagrams

19. 7 Systems Analysis and Design in a Changing World, 4th Edition 19 Brief Description of Create New Order Use Case (Figure 7-7)

20. 7 Systems Analysis and Design in a Changing World, 4th Edition 20 Intermediate Description of the Telephone Order Scenario for Create New Order Use Case (Figure 7-8)

21. 7 Systems Analysis and Design in a Changing World, 4th Edition 21 Intermediate Description of the Web Order Scenario for Create New Order (Figure 7-9)

22. 7 Systems Analysis and Design in a Changing World, 4th Edition 22 Fully Developed Description of Telephone Order Scenario for Create New Order Use Case (Figure 7-10)

23. 7 Systems Analysis and Design in a Changing World, 4th Edition 23 Top Detail from Fully Developed Use Case Description (Figure 7-10)

24. 7 Systems Analysis and Design in a Changing World, 4th Edition 24 Middle Detail from Fully Developed Use Case Description (Figure 7-10)

25. 7 Systems Analysis and Design in a Changing World, 4th Edition 25 Bottom Detail from Fully Developed Use Case Description (Figure 7-10)

26. 7 Systems Analysis and Design in a Changing World, 4th Edition 26 Use Case Description Components u Use case name/scenario name u Actors/stakeholders u Related use cases u Preconditions – set of criteria that must be true prior to initiation of the use case u Postconditions – set of criteria that must be true upon completion of the use case u Flow of activities (steps in one column or two) u Exception conditions

27. 7 Systems Analysis and Design in a Changing World, 4th Edition 27 Activity Diagrams u Used to document workflow of business process activities for each use case or scenario u Standard UML 2.0 diagram as seen in Chapter 4 u Can support any level of use case description; a supplement to use case descriptions u Helpful in developing system sequence diagrams

28. 7 Systems Analysis and Design in a Changing World, 4th Edition 28 Activity Diagram Symbols

29. 7 Systems Analysis and Design in a Changing World, 4th Edition 29 Activity Diagram that Models a Workflow (Figure 4- 13)

30. 7 Systems Analysis and Design in a Changing World, 4th Edition 30 Activity Diagram— Telephone Order Scenario (Figure 7-12)

31. 7 Systems Analysis and Design in a Changing World, 4th Edition 31 Activity Diagram— Web Order Scenario (Figure 7-13)

32. 7 Systems Analysis and Design in a Changing World, 4th Edition 32 SSD Notation u Actor represented by a stick figure – a person (or role) that interacts with system by entering input data and receiving output data u Object is a rectangle with name of object underlined – shows individual object and not class of all similar objects ( :System for SSD ) u Lifeline or object lifeline is a vertical line under object or actor to show passage of time for object u Message is labeled on arrows to show messages sent to or received by actor or system

33. 7 Systems Analysis and Design in a Changing World, 4th Edition 33 SSD Lifelines u Vertical line under object or actor l Shows passage of time u If vertical line dashed l Creation and destruction of thing is not important for scenario u Long narrow rectangles l Activation lifelines emphasize that object is active only during part of scenario

34. 7 Systems Analysis and Design in a Changing World, 4th Edition 34 SSD Messages u Internal events identified by the flow of objects in a scenario u Requests from one actor or object to another to do some action u Invoke a particular method

35. 7 Systems Analysis and Design in a Changing World, 4th Edition 35 Repeating Message (Figure 7-15)

36. 7 Systems Analysis and Design in a Changing World, 4th Edition 36 Developing a System Sequence Diagram u Begin with detailed description of use case from fully developed form or activity diagram u Identify input messages u Describe message from external actor to system using message notation u Identify and add any special conditions on input message, including iteration and true/false conditions u Identify and add output return messages

37. 7 Systems Analysis and Design in a Changing World, 4th Edition 37 Activity Diagram and Resulting SSD for Telephone Order Scenario (Figures 7-16 and 7-17)

38. 7 Systems Analysis and Design in a Changing World, 4th Edition 38 SSD of the Web Order Scenario for the Create New Order Use Case (Figure 7-18)

39. 7 Systems Analysis and Design in a Changing World, 4th Edition 39 Integrating Object-Oriented Models u Complete use case diagram is needed to understand total scope of new system u Domain model class diagrams should also be as complete as possible for entire system u With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration u Development of a new diagram often helps refine and correct previous diagrams