Systems Analysis and Design in a Changing World, Fourth Edition

1. Systems Analysis and Design in a Changing World, Fourth Edition

2. Learning Objectives • Develop use case diagrams • Write use case and scenario descriptions • Develop activity diagrams and system sequence diagrams to model interactions • Develop state machine diagrams to model object behavior • Explain how UML diagrams work together to define functional requirements for the object-oriented approach Systems Analysis and Design in a Changing World, 4th Edition

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

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

5. Systems Analysis and Design in a Changing World, 4th Edition

6. System perspectives An external perspective, where you model the context or environment of the system. An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system. A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system. A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.

7. Context models • Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. • Social and organisational concerns may affect the decision on where to position system boundaries. • Architectural models show the system and its relationship with other systems.

8. System boundaries • System boundaries are established to define what is inside and what is outside the system. • They show other systems that are used or depend on the system being developed.

9. The context of the MHC-PMS

10. Sample Context Diagram Chapter 5 System modeling

11. Automation System Boundary Chapter 5 System modeling

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

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

14. Techniques for Identifying Use Cases • Starting points for use case development • Identify all actors of the system • Identify functions actors perform with system • Develop flow of activities to identify various scenarios • Common internal use cases can be identified and separated into different use cases Systems Analysis and Design in a Changing World, 4th Edition

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

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

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

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

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

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

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

22. <<Extends>> Relationship Can be used: • To show that a part of a use case is optional, or potentially optional, system behavior. In this way, you separate optional behavior from mandatory behavior in your model. • To show that a subflow is executed only under certain (sometimes exceptional) conditions, such as triggering an alarm. • To show that there may be a set of behavior segments of which one or several may be inserted at an extension point in a base use case. The behavior segments that are inserted (and the order in which they are inserted) will depend on the interaction with the actors during the execution of the base use case. Systems Analysis and Design in a Changing World, 4th Edition

23. (Figure 7-6) Systems Analysis and Design in a Changing World, 4th Edition

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

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

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

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

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

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

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

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

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

33. Activity Diagrams • Used to document workflow of business process activities for each use case or scenario • Can support any level of use case description; a supplement to use case descriptions • Helpful in developing system sequence diagrams Systems Analysis and Design in a Changing World, 4th Edition

34. Activity Diagrams A swim lane (or swimlane) is a visual element used in process flow diagrams, or flowcharts, that visually distinguishes job sharing and responsibilities for sub-processes of a business process Systems Analysis and Design in a Changing World, 4th Edition

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

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

37. Identifying Inputs and Outputs—The System Sequence Diagram • System sequence diagram (SSD) is type of UML 2.X interaction diagram • Used to model input and output messaging requirements for a use case or scenario • Shows actor interacting with system • Shows sequence of interactions as messages during flow of activities • System is shown as one object: a “black box” Systems Analysis and Design in a Changing World, 4th Edition

38. System Sequence Diagram (SSD) Notation (Figure 7-14) Systems Analysis and Design in a Changing World, 4th Edition

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

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

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

42. Identifying Object Behavior—The State Machine Diagram • State machine diagram is UML 2.X diagram that models object states and transitions • Complex problem domain classes can be modeled • State of an object • A condition that occurs during its life when it satisfies some criterion, performs some action, or waits for an event • Each state has unique name and is a semipermanent condition or status • Transition • The movement of an object from one state to another state Systems Analysis and Design in a Changing World, 4th Edition

43. Simple State Machine Diagram for a Printer (Figure 7-19) Systems Analysis and Design in a Changing World, 4th Edition

44. RMO State Machine Diagram for OrderItem Problem Domain Class Systems Analysis and Design in a Changing World, 4th Edition

45. Summary • Object-oriented approach has complete set of diagrams that define system requirements • Requirements specified using following models • Domain model class diagram • Use case diagrams • Use case detailed models, either descriptive formats or activity diagrams • System sequence diagrams • State machine diagrams Systems Analysis and Design in a Changing World, 4th Edition