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

2. 5 Systems Analysis and Design in a Changing World, 4th Edition 2 Learning Objectives u Explain the many reasons for creating information system models u Describe three types of models and list some specific models used for analysis and design u Explain how events can be used to define activities and use cases u Identify and analyze events to which a system responds

3. 5 Systems Analysis and Design in a Changing World, 4th Edition 3 Learning Objectives ( continued ) u Explain how the concept of “things” in the problem domain also defines requirements u Explain the similarities and the differences between data entities and objects u Identify and analyze data entities and domain classes needed in the system u Read, interpret, and create an entity-relationship diagram u Read, interpret, and create a class diagram

4. 5 Systems Analysis and Design in a Changing World, 4th Edition 4 Overview u Document functional requirements by creating models u Models created during analysis phase activity – Define system requirements u Two concepts help identify functional requirements in the traditional approach and object-oriented approach l Events that trigger use cases l Things in the users’ work domain

5. 5 Systems Analysis and Design in a Changing World, 4th Edition 5 Models and Modeling u Analyst describes information system requirements using a collection of models u Complex systems require more than one type of model u Models represent some aspect of the system being built u Process of creating models helps analyst clarify and refine design u Models assist communication with system users

6. 5 Systems Analysis and Design in a Changing World, 4th Edition 6 Reasons for Modeling (Figure 5-2)

7. 5 Systems Analysis and Design in a Changing World, 4th Edition 7 Types of Models u Different types of models are used in information systems development l Mathematical – formulas that describe technical aspects of the system l Descriptive – narrative memos, reports, or lists that describe aspects of the system l Graphical – diagrams and schematic representations of some aspect of the system

8. 5 Systems Analysis and Design in a Changing World, 4th Edition 8 Some Descriptive Models (Figure 5-3)

9. 5 Systems Analysis and Design in a Changing World, 4th Edition 9 Overview of Models Used in Analysis and Design u Analysis phase activity named “define system requirements” l Logical models l Provide detail without regard to specific technology u Design phase l Physical models l Provide technical details l Extend logical models

10. 5 Systems Analysis and Design in a Changing World, 4th Edition 10 Models Created by Analysis Activities (Figure 5-4)

11. 5 Systems Analysis and Design in a Changing World, 4th Edition 11 Models Used in Design (Figure 5-5)

12. 5 Systems Analysis and Design in a Changing World, 4th Edition 12 Events, Activities, and Use Cases u Use Case l An activity the system performs in response to a user request l A “case” where the system is used by actor u Techniques for identifying use cases l Identify user goals u Each goal at the elementary business process (EBP) level is a use case u EBP – a task performed by one user, in one place in response to a business event, that adds measurable business value, and leaves system and data in consistent state l Event decomposition technique l CRUD analysis technique (create, read, update, delete)

13. 5 Systems Analysis and Design in a Changing World, 4th Edition 13 Identifying Use Cases Based on User Goals (Figure 5-6)

14. 5 Systems Analysis and Design in a Changing World, 4th Edition 14 Event Decomposition u Business events trigger elementary business processes (EBPs) u EBPs are at correct level of analysis for use cases u Identify business events to decompose system into activities/use cases u Event decomposition is, therefore, used by l Traditional approach to identify activities l OO approach to identify use cases

15. 5 Systems Analysis and Design in a Changing World, 4th Edition 15 Types of Events u External l Outside system l Initiated by external agent or actor u Temporal l Occur as result of reaching a point in time l Based on system deadlines u State l Something inside system triggers processing need

16. 5 Systems Analysis and Design in a Changing World, 4th Edition 16 Events Affecting a Charge Account Processing System that Lead to Use Cases (Figure 5-7)

17. 5 Systems Analysis and Design in a Changing World, 4th Edition 17 External Event Checklist (Figure 5-8)

18. 5 Systems Analysis and Design in a Changing World, 4th Edition 18 Temporal Event Checklist (Figure 5-9)

19. 5 Systems Analysis and Design in a Changing World, 4th Edition 19 Identifying Events u Can be difficult to determine u Often confused with conditions and responses u May be useful to trace a transaction’s life cycle u Certain events left to design phase l System controls to protect system integrity l Perfect technology assumption defers events

20. 5 Systems Analysis and Design in a Changing World, 4th Edition 20 Sequence of Actions that Lead Up to Only One Event Affecting the System (Figure 5-10)

21. 5 Systems Analysis and Design in a Changing World, 4th Edition 21 Sequence of “Transactions” for One Specific Customer Resulting in Many Events (Figure 5-11)

22. 5 Systems Analysis and Design in a Changing World, 4th Edition 22 Events Deferred Until the Design Phase (Figure 5-12)

23. 5 Systems Analysis and Design in a Changing World, 4th Edition 23 Events in the RMO case u Important external events involve customers l Customer checks item availability, customer places order, customer changes or cancels order u Other external events involve departments l Shipping fulfills order, marketing sends promotion to customer, merchandising updates catalog u Temporal events include periodic reports l Time to produce order summary reports, Time to produce fulfillment summary reports

24. 5 Systems Analysis and Design in a Changing World, 4th Edition 24 Information about Each Event in an Event Table: Catalog of Information about Each Use Case (Figure 5-15)

25. 5 Systems Analysis and Design in a Changing World, 4th Edition 25 RMO Event Table (Figure 5-6 partial)

26. 5 Systems Analysis and Design in a Changing World, 4th Edition 26 “Things” in the Problem Domain u Define system requirements by understanding system information that needs to be stored u Store information about things in the problem domain that people deal with when they do their work u Analysts identify these types of things by considering each use case in the event table l What things does the system need to know about and store information about?

27. 5 Systems Analysis and Design in a Changing World, 4th Edition 27 Types of Things (Figure 5-17)

28. 5 Systems Analysis and Design in a Changing World, 4th Edition 28 Procedure for Developing an Initial List of Things u Step 1: Using the event table and information about each use case, identify all nouns u Step 2: Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed u Step 3: Refine list and record assumptions or issues to explore l See Figure 5-18 for RMO example

29. 5 Systems Analysis and Design in a Changing World, 4th Edition 29 Characteristics of Things u Relationship l Naturally occurring association among specific things l Occur in two directions l Number of associations is cardinality or multiplicity u Binary, unary, ternary, n-ary u Attribute l One specific piece of information about a thing

30. 5 Systems Analysis and Design in a Changing World, 4th Edition 30 Relationships Naturally Occur Between Things (Figure 5-19)

31. 5 Systems Analysis and Design in a Changing World, 4th Edition 31 Cardinality/Multiplicity of Relationships (Figure 5-20)

32. 5 Systems Analysis and Design in a Changing World, 4th Edition 32 Attributes and Values (Figure 5-21)

33. 5 Systems Analysis and Design in a Changing World, 4th Edition 33 Data Entities u Things system needs to store data about in traditional IS approach u Modeled with entity-relationship diagram (ERD) u Requirements model used to create the database design model for relational database

34. 5 Systems Analysis and Design in a Changing World, 4th Edition 34 Objects u Objects do the work in a system and store information in the object-oriented approach u Objects have behaviors and attributes l Class – type of thing l Object – each specific thing l Methods – behaviors of objects of the class u Objects contain values for attributes and methods for operating on those attributes u An object is encapsulated – a self-contained unit

35. 5 Systems Analysis and Design in a Changing World, 4th Edition 35 Data Entities Compared with Objects (Figure 5-22)

36. 5 Systems Analysis and Design in a Changing World, 4th Edition 36 The Entity-Relationship Diagram (ERD)

37. 5 Systems Analysis and Design in a Changing World, 4th Edition 37 Cardinality Symbols of Relationships for ERD

38. 5 Systems Analysis and Design in a Changing World, 4th Edition 38 Expanded ERD with Attributes Shown

39. 5 Systems Analysis and Design in a Changing World, 4th Edition 39 Customers, Orders, and Order Items

40. 5 Systems Analysis and Design in a Changing World, 4th Edition 40 ERD with Many-to-Many Relationship

41. 5 Systems Analysis and Design in a Changing World, 4th Edition 41 Many-to-Many Relationship Converted to Associative Entity to Store Grade Attribute

42. 5 Systems Analysis and Design in a Changing World, 4th Edition 42 RMO Customer Support System ERD ( Figure 5-29)

43. 5 Systems Analysis and Design in a Changing World, 4th Edition 43 The Class Diagram u Unified Modeling Language (UML) diagram u Domain model class diagram l Models things in the users’ work domain l Used to define requirements for OO (very similar to entities in ERD) u Design class diagram l Models software classes l Adds methods as behaviors l Used in the design activity

44. 5 Systems Analysis and Design in a Changing World, 4th Edition 44 UML Class Symbol (Figure 5-30)

45. 5 Systems Analysis and Design in a Changing World, 4th Edition 45 Simple Domain Model Class Diagram (Figure 5-31) u No methods shown in domain model l Domain classes are not software classes u Very similar to ERD in Figure 5-25 l UML and domain model can be used in place of ERD in traditional approach

46. 5 Systems Analysis and Design in a Changing World, 4th Edition 46 Multiplicity of Associations (Figure 5-32)

47. 5 Systems Analysis and Design in a Changing World, 4th Edition 47 University Course Enrollment Domain Model Class Diagram (Figure 5-33)

48. 5 Systems Analysis and Design in a Changing World, 4th Edition 48 Refined Model with Association Class and Grade Attribute (Figure 5-34)

49. 5 Systems Analysis and Design in a Changing World, 4th Edition 49 More Complex Class Concepts u Generalization/specialization hierarchies l General superclasses to specialized subclasses l Inheritance allows subclasses to share characteristics of their superclasses u Whole-part hierarchies (object and its parts) l Aggregation – parts can exist separately l Composition – parts can’t exist separately u Hand has fingers and thumb

50. 5 Systems Analysis and Design in a Changing World, 4th Edition 50 A Generalization/Specialization Class Hierarchy for Motor Vehicles (Figure 5-35)

51. 5 Systems Analysis and Design in a Changing World, 4th Edition 51 A Generalization/Specialization Class Hierarchy for RMO Orders (Figure 5-36)

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

53. 5 Systems Analysis and Design in a Changing World, 4th Edition 53 RMO Domain Model Class Diagram (Figure 5-41)

54. 5 Systems Analysis and Design in a Changing World, 4th Edition 54 Design Class Diagram Notation: Software Classes with Methods

55. 5 Systems Analysis and Design in a Changing World, 4th Edition 55 Course Enrollment Design Class Diagram with Association Class (Figure 5-39)

56. 5 Systems Analysis and Design in a Changing World, 4th Edition 56 Expanded Course Enrollment Design Class Diagram (Figure 5-40)

57. 5 Systems Analysis and Design in a Changing World, 4th Edition 57 Where You Are Headed (Figure 5-42)

58. 5 Systems Analysis and Design in a Changing World, 4th Edition 58 Summary u Analysis phase – defines system requirements u Models created to further learning process, reduce complexity, communicate with team members, and document requirements u Many types of models used l Mathematical, descriptive, graphical u Key early step in modeling is to identify and list l Events that require a use case in the system l Things users deal with in work environment

59. 5 Systems Analysis and Design in a Changing World, 4th Edition 59 Summary ( continued ) u Use cases (activities) are identified from user goals and business events that trigger elementary business processes u Business events are memorable, can be described, and occur at a specific time and place l External events, temporal events, and state events u Event table records event, trigger, source, use case, response, and destination l A catalog of information about each use case

60. 5 Systems Analysis and Design in a Changing World, 4th Edition 60 Summary ( continued ) u “Things” are what user deals with and system remembers, such as customer placing an order u Traditional approach uses entity-relationship diagrams (ERD) for data entities, attributes of data entities, and relationships between entities u Object-oriented approach uses UML class diagrams for classes, attributes, methods of class, and associations among classes l Domain model class diagram (requirements activity) l Design class diagram (design activity)