05 si(systems analysis and design )
Download as PPT, PDF10 likes4,114 views
The document discusses systems analysis and design models. It explains that analysts use various models like descriptive, graphical and mathematical models to define system requirements. Some key models mentioned are entity-relationship diagrams, used to model data entities, and class diagrams, used to model objects and classes. Events that trigger use cases and "things" in the problem domain help identify functional requirements.
05 si(systems analysis and design )
- 1. Systems Analysis and Design in a Changing World, Fourth Edition
- 2. Learning Objectives Explain the many reasons for creating information system models Describe three types of models and list some specific models used for analysis and design Explain how events can be used to define activities and use cases Identify and analyze events to which a system responds Systems Analysis and Design in a Changing World, 4th Edition
- 3. Learning Objectives ( continued ) Explain how the concept of “things” in the problem domain also defines requirements Explain the similarities and the differences between data entities and objects Identify and analyze data entities and domain classes needed in the system Read, interpret, and create an entity-relationship diagram Read, interpret, and create a class diagram Systems Analysis and Design in a Changing World, 4th Edition
- 4. Overview Document functional requirements by creating models Models created during analysis phase activity – Define system requirements Two concepts help identify functional requirements in the traditional approach and object-oriented approach Events that trigger use cases Things in the users’ work domain Systems Analysis and Design in a Changing World, 4th Edition
- 5. Models and Modeling Analyst describes information system requirements using a collection of models Complex systems require more than one type of model Models represent some aspect of the system being built Process of creating models helps analyst clarify and refine design Models assist communication with system users Systems Analysis and Design in a Changing World, 4th Edition
- 6. Reasons for Modeling (Figure 5-2) Systems Analysis and Design in a Changing World, 4th Edition
- 7. Types of Models Different types of models are used in information systems development Mathematical – formulas that describe technical aspects of the system Descriptive – narrative memos, reports, or lists that describe aspects of the system Graphical – diagrams and schematic representations of some aspect of the system Systems Analysis and Design in a Changing World, 4th Edition
- 8. Some Descriptive Models (Figure 5-3) Systems Analysis and Design in a Changing World, 4th Edition
- 9. Overview of Models Used in Analysis and Design Analysis phase activity named “define system requirements” Logical models Provide detail without regard to specific technology Design phase Physical models Provide technical details Extend logical models Systems Analysis and Design in a Changing World, 4th Edition
- 10. Models Created by Analysis Activities (Figure 5-4) Systems Analysis and Design in a Changing World, 4th Edition
- 11. Models Used in Design (Figure 5-5) Systems Analysis and Design in a Changing World, 4th Edition
- 12. Events, Activities, and Use Cases Use Case An activity the system performs in response to a user request A “case” where the system is used by actor Techniques for identifying use cases Identify user goals Each goal at the elementary business process (EBP) level is a use case 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 Event decomposition technique CRUD analysis technique (create, read, update, delete) Systems Analysis and Design in a Changing World, 4th Edition
- 13. Identifying Use Cases Based on User Goals (Figure 5-6) Systems Analysis and Design in a Changing World, 4th Edition
- 14. Event Decomposition Business events trigger elementary business processes (EBPs) EBPs are at correct level of analysis for use cases Identify business events to decompose system into activities/use cases Event decomposition is, therefore, used by Traditional approach to identify activities OO approach to identify use cases Systems Analysis and Design in a Changing World, 4th Edition
- 15. Types of Events External Outside system Initiated by external agent or actor Temporal Occur as result of reaching a point in time Based on system deadlines State Something inside system triggers processing need 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) Systems Analysis and Design in a Changing World, 4th Edition
- 17. External Event Checklist (Figure 5-8) Systems Analysis and Design in a Changing World, 4th Edition
- 18. Temporal Event Checklist (Figure 5-9) Systems Analysis and Design in a Changing World, 4th Edition
- 19. Identifying Events Can be difficult to determine Often confused with conditions and responses May be useful to trace a transaction’s life cycle Certain events left to design phase System controls to protect system integrity Perfect technology assumption defers events 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) 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) Systems Analysis and Design in a Changing World, 4th Edition
- 22. Events Deferred Until the Design Phase (Figure 5-12) Systems Analysis and Design in a Changing World, 4th Edition
- 23. Events in the RMO case Important external events involve customers Customer checks item availability, customer places order, customer changes or cancels order Other external events involve departments Shipping fulfills order, marketing sends promotion to customer, merchandising updates catalog Temporal events include periodic reports Time to produce order summary reports, Time to produce fulfillment summary reports 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) Systems Analysis and Design in a Changing World, 4th Edition
- 25. RMO Event Table (Figure 5-6 partial) Systems Analysis and Design in a Changing World, 4th Edition
- 26. “ 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 people deal with when they do their work Analysts identify these types of things by considering each use case in the event table What things does the system need to know about and store information about? Systems Analysis and Design in a Changing World, 4th Edition
- 27. Types of Things (Figure 5-17) Systems Analysis and Design in a Changing World, 4th Edition
- 28. Procedure for Developing an Initial List of Things Step 1: Using the event table and information about each use case, identify all nouns Step 2: Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed Step 3: Refine list and record assumptions or issues to explore See Figure 5-18 for RMO example Systems Analysis and Design in a Changing World, 4th Edition
- 29. Characteristics of Things Relationship Naturally occurring association among specific things Occur in two directions Number of associations is cardinality or multiplicity Binary, unary, ternary, n-ary Attribute One specific piece of information about a thing Systems Analysis and Design in a Changing World, 4th Edition
- 30. Relationships Naturally Occur Between Things (Figure 5-19) Systems Analysis and Design in a Changing World, 4th Edition
- 31. Cardinality/Multiplicity of Relationships (Figure 5-20) Systems Analysis and Design in a Changing World, 4th Edition
- 32. Attributes and Values (Figure 5-21) Systems Analysis and Design in a Changing World, 4th Edition
- 33. Data Entities Things system needs to store data about in traditional IS approach Modeled with entity-relationship diagram (ERD) Requirements model used to create the database design model for relational database Systems Analysis and Design in a Changing World, 4th Edition
- 34. Objects Objects do the work in a system and store information in the object-oriented approach Objects have behaviors and attributes Class – type of thing Object – each specific thing Methods – behaviors of objects of the class Objects contain values for attributes and methods for operating on those attributes An object is encapsulated – a self-contained unit Systems Analysis and Design in a Changing World, 4th Edition
- 35. Data Entities Compared with Objects (Figure 5-22) Systems Analysis and Design in a Changing World, 4th Edition
- 36. The Entity-Relationship Diagram (ERD) Systems Analysis and Design in a Changing World, 4th Edition
- 37. Cardinality Symbols of Relationships for ERD Systems Analysis and Design in a Changing World, 4th Edition
- 38. Expanded ERD with Attributes Shown Systems Analysis and Design in a Changing World, 4th Edition
- 39. Customers, Orders, and Order Items Systems Analysis and Design in a Changing World, 4th Edition
- 40. ERD with Many-to-Many Relationship Systems Analysis and Design in a Changing World, 4th Edition
- 41. Many-to-Many Relationship Converted to Associative Entity to Store Grade Attribute Systems Analysis and Design in a Changing World, 4th Edition
- 42. RMO Customer Support System ERD ( Figure 5-29) Systems Analysis and Design in a Changing World, 4th Edition
- 43. The 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) Design class diagram Models software classes Adds methods as behaviors Used in the design activity Systems Analysis and Design in a Changing World, 4th Edition
- 44. UML Class Symbol (Figure 5-30) Systems Analysis and Design in a Changing World, 4th Edition
- 45. Simple Domain Model Class Diagram (Figure 5-31) Systems Analysis and Design in a Changing World, 4th Edition No methods shown in domain model Domain classes are not software classes Very similar to ERD in Figure 5-25 UML and domain model can be used in place of ERD in traditional approach
- 46. Multiplicity of Associations (Figure 5-32) Systems Analysis and Design in a Changing World, 4th Edition
- 47. University Course Enrollment Domain Model Class Diagram (Figure 5-33) Systems Analysis and Design in a Changing World, 4th Edition
- 48. Refined Model with Association Class and Grade Attribute (Figure 5-34) Systems Analysis and Design in a Changing World, 4th Edition
- 49. More Complex Class Concepts Generalization/specialization hierarchies General superclasses to specialized subclasses Inheritance allows subclasses to share characteristics of their superclasses Whole-part hierarchies (object and its parts) Aggregation – parts can exist separately Composition – parts can’t exist separately Hand has fingers and thumb Systems Analysis and Design in a Changing World, 4th Edition
- 50. A Generalization/Specialization Class Hierarchy for Motor Vehicles (Figure 5-35) Systems Analysis and Design in a Changing World, 4th Edition
- 51. A Generalization/Specialization Class Hierarchy for RMO Orders (Figure 5-36) Systems Analysis and Design in a Changing World, 4th Edition
- 52. Whole-Part Aggregation Relationships (Figure 5-37) Systems Analysis and Design in a Changing World, 4th Edition
- 53. RMO Domain Model Class Diagram (Figure 5-41) Systems Analysis and Design in a Changing World, 4th Edition
- 54. Design Class Diagram Notation: Software Classes with Methods Systems Analysis and Design in a Changing World, 4th Edition
- 55. Course Enrollment Design Class Diagram with Association Class (Figure 5-39) Systems Analysis and Design in a Changing World, 4th Edition
- 56. Expanded Course Enrollment Design Class Diagram (Figure 5-40) Systems Analysis and Design in a Changing World, 4th Edition
- 57. Where You Are Headed (Figure 5-42) Systems Analysis and Design in a Changing World, 4th Edition
- 58. Summary Analysis phase – d efines system requirements Models created to further learning process, reduce complexity, communicate with team members, and document requirements Many types of models used Mathematical, descriptive, graphical Key early step in modeling is to identify and list Events that require a use case in the system Things users deal with in work environment Systems Analysis and Design in a Changing World, 4th Edition
- 59. Summary ( continued ) Use cases (activities) are identified from user goals and business events that trigger elementary business processes Business events are memorable, can be described, and occur at a specific time and place External events, temporal events, and state events Event table records event, trigger, source, use case, response, and destination A catalog of information about each use case Systems Analysis and Design in a Changing World, 4th Edition
- 60. Summary ( continued ) “ Things” are what user deals with and system remembers, such as customer placing an order Traditional approach uses entity-relationship diagrams (ERD) for data entities, attributes of data entities, and relationships between entities Object-oriented approach uses UML class diagrams for classes, attributes, methods of class, and associations among classes Domain model class diagram (requirements activity) Design class diagram (design activity) Systems Analysis and Design in a Changing World, 4th Edition
- 61. Systems Analysis and Design in a Changing World, 4th Edition