Systems Analysis and Design in a Changing World, Fifth Edition

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

2. Systems Analysis and Design in a Changing World, 5th Edition Learning Objectives • Understand the models and processes of defining object-oriented requirements • Develop use case diagrams and activity diagrams • Develop system sequence diagrams • Develop state machine diagrams to model object behavior • Explain how UML diagrams work together to define functional requirements for the object-oriented approach

3. Systems Analysis and Design in a Changing World, 5th Edition Overview • The objective of requirements definition is understanding – understanding the users’ needs, the businessprocesses, and the systems to support business processes • Understand and definerequirements for a new system using object-oriented analysismodels 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

4. Systems Analysis and Design in a Changing World, 5th Edition Object-Oriented Requirements • Object-oriented modeling notation is Unified Modeling Language (UML2.0) • 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

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

6. Systems Analysis and Design in a Changing World, 5th Edition Object-Oriented Requirements Models • Use case model – a collection of models to capture system requirements • Use case diagram – identify actors and their roles and how the actor roles utilize the system • Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case • Activity Diagram – Used to document workflow of business processes within a use case • Domainmodel – describes the classes of objects and their states • Statemachinediagrams – describe states of each object

7. Systems Analysis and Design in a Changing World, 5th Edition Requirements Models—Traditional vs OO Figure 7-1

8. Systems Analysis and Design in a Changing World, 5th Edition 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 userrequest • Actor • Role played by user • Outside automation boundary

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

10. Systems Analysis and Design in a Changing World, 5th Edition Use Case Diagram • GraphicalUMLdiagram that summarizes information about actors and usecases • Simple diagram shows overview of functionalrequirements • Can have multiple use case diagrams • By subsystem • By actor

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

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

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

14. Systems Analysis and Design in a Changing World, 5th Edition Use Cases of RMO Order Entry Subsystem Figure 7-5 (partial figure)‏

15. Use Case of Customer Support System

16. Use Case of Customer Support System Order Entry Subsystem Customer Order Clerk Order Fulfillment Subsystem Shipping Clerk Clerk Customer Maintenance Subsystem Catalog Maintenance Subsystem Management Merchandising

17. Systems Analysis and Design in a Changing World, 5th Edition <<Includes>>Relationship • Documents situation in which one use case requires the services of a commonsubroutine • Another use case is developed for this commonsubroutine • A commonusecase can be reused by multipleusecases

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

19. Systems Analysis and Design in a Changing World, 5th Edition Developing a Use Case Diagram • Underlying conditions for describing use cases • Based on automatedsystem, e.g. users “touch” the system • Assume perfect technology condition • Iterate through these twosteps • Identify actors as roles • List goals, e.g. use cases, for each actor. A goal is a unit of work. • Finalize with a CRUD analysis to ensure completeness

21. Systems Analysis and Design in a Changing World, 5th Edition Use Case Descriptions • Use case description – a description of the processingsteps for a usecase • Actor – a person or thing that uses the system. • Actors have contact with the system • Scenario or Instance – a particular set of internalsteps that represent a uniquepath of the usecase • Threetypes of descriptions • Brief description • Intermediate description • Fully developed description

22. Systems Analysis and Design in a Changing World, 5th Edition Brief Description Figure 5-13

23. Systems Analysis and Design in a Changing World, 5th Edition Intermediate Description Figure 5-14

24. Systems Analysis and Design in a Changing World, 5th Edition Fully Developed Description Figure 5-16

25. Systems Analysis and Design in a Changing World, 5th Edition “Things” in the Problem Domain • Define system requirements by understanding system information that needs to be stored • Store information about things in the problem domain that peopledealwith when they do their work

26. Systems Analysis and Design in a Changing World, 5th Edition Types of Things Figure 5-18

27. Systems Analysis and Design in a Changing World, 5th Edition The Domain Model Class Diagram • Unified Modeling Language (UML) diagram • Domain model class diagram • Models things in the users’ work domain • Used to define requirements for OO (very similar to entities in ERD)‏

28. Systems Analysis and Design in a Changing World, 5th Edition UML Class Symbol Figure 5-30

29. Systems Analysis and Design in a Changing World, 5th Edition Simple Domain Model Class Diagram Figure 5-31

30. Systems Analysis and Design in a Changing World, 5th Edition Simple Domain Model Class Diagram (continued) • Nomethods shown in domain model • Domain classes are not software classes • Very similar to ERD • UML and domain model can be used in place of ERD in traditional approach

31. Systems Analysis and Design in a Changing World, 5th Edition Multiplicity of Associations Figure 5-32

32. Systems Analysis and Design in a Changing World, 5th Edition UniversityCourseEnrollmentDomain Model Class Diagram Figure 5-33

33. Systems Analysis and Design in a Changing World, 5th Edition RefinedModel with Association Class and Grade Attribute Figure 5-34

34. Systems Analysis and Design in a Changing World, 5th Edition More Complex Class Concepts • Generalization/specialization hierarchies • General superclasses to specialized subclasses • Inheritance allows subclasses to share characteristics of their superclasses

35. Systems Analysis and Design in a Changing World, 5th Edition A Generalization/Specialization Class Hierarchy for MotorVehicles Figure 5-35

36. Systems Analysis and Design in a Changing World, 5th Edition A Generalization/Specialization Class Hierarchy for RMOOrders Figure 5-36

37. Systems Analysis and Design in a Changing World, 3rd Edition Example of Domain Model Class Diagram

38. Systems Analysis and Design in a Changing World, 5th Edition Whole-Part Hierarchies • Whole-part hierarchies – hierarchies that structure classes by components • Aggregation – whole-part relationships between and object and its removable parts • Parts can exist separately • Like car and its tires • Composition – whole-part relationships between and object and its non-removableparts. • Parts cannot exist separately • Like Hand is composed of fingers and thumb

39. Systems Analysis and Design in a Changing World, 5th Edition Whole-Part Aggregation Relationships Figure 5-37

40. Systems Analysis and Design in a Changing World, 5th Edition RMO Domain Model Class Diagram‏ Figure 5-38

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

42. Systems Analysis and Design in a Changing World, 5th Edition Activity Diagram— Telephone Order Scenario Figure 7-8

43. Systems Analysis and Design in a Changing World, 5th Edition Activity Diagram— Web Order Scenario Figure 7-9

44. Systems Analysis and Design in a Changing World, 5th Edition The System Sequence Diagram • Interactiondiagram – a communication diagram or a sequencediagram • Systemsequencediagram (SSD) is type of UML 2.0 interactiondiagram • Used to model input and output messaging requirements for a use case or scenario • Shows sequence of interactions as messages during flow of activities • System is shown as oneobject: a “black box”

45. Systems Analysis and Design in a Changing World, 5th Edition SSD Notation • Lifeline or object lifeline is a verticallineunderobject or actor to show passage of time for object • Message is labelled on arrows to show messages sent to or received by actor or system • Actor is role interacting with the system with messages • Object is the component that interacts with actors and other objects

46. Systems Analysis and Design in a Changing World, 5th Edition System Sequence Diagram (SSD) Notation Figure 7-10

47. Systems Analysis and Design in a Changing World, 5th Edition SSD Lifelines • Verticalline 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

48. Systems Analysis and Design in a Changing World, 5th Edition 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

49. Systems Analysis and Design in a Changing World, 5th Edition Repeating Message Figure 7-11

50. Systems Analysis and Design in a Changing World, 5th Edition Developing a System Sequence Diagram • Begin with detaileddescription of usecase from fully developed form or activitydiagram • Identify inputmessages • Describe message from external actor to system using message notation • Identify and add any special conditions on input message, including iteration and true/false conditions • Identify and add outputreturnmessages