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


Learning Objectives :Systems Analysis and Design in a Changing World, 4th 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


Learning Objectives (continued) :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


Overview :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


Models and Modeling :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


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


Types of Models :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


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


Overview of Models Used in Analysis and Design :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


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


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


Events, Activities, and Use Cases :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)


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


Event Decomposition :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


Types of Events :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


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 16 Events Affecting a Charge Account Processing System that Lead to Use Cases (Figure 5-7)


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


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


Identifying Events :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


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 20 Sequence of Actions that Lead Up to Only One Event Affecting the System (Figure 5-10)


Sequence of “Transactions” for One Specific Customer Resulting in Many Events (Figure 5-11) :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)


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


Events in the RMO case :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


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 24 Information about Each Event in an Event Table: Catalog of Information about Each Use Case (Figure 5-15)


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


“Things” in the Problem Domain :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?


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


Procedure for Developing an Initial List of Things :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


Characteristics of Things :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


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


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


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


Data Entities :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


Objects :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


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


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


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


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


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


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


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


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


The Class Diagram :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


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


Simple Domain Model Class Diagram (Figure 5-31) :Systems Analysis and Design in a Changing World, 4th Edition 45 Simple Domain Model Class Diagram (Figure 5-31) 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


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


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


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


More Complex Class Concepts :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


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


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


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


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


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


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


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


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


Summary :Systems Analysis and Design in a Changing World, 4th Edition 58 Summary Analysis phase – defines 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


Summary (continued) :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


Summary (continued) :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)