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

5 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 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 a class diagram

5 3 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

5 4 Types of Models u Different types of models are used in information systems development l Mathematical – formulas that describe technical aspects of the system (i.e., reorder quantity) 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

5 5 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

5 6 Models Created by Analysis Activities

5 7 Models Used in Design

5 8 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)

5 9 Identifying Use Cases Based on User Goals

5 10 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

5 11 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

5 12 Events Affecting a Charge Account Processing System that Lead to Use Cases

5 13 External Event Checklist

5 14 Temporal Event Checklist

5 15 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

5 16 Sequence of Actions that Lead Up to Only One Event Affecting the System

5 17 Sequence of “Transactions” for One Specific Customer Resulting in Many Events

5 18 Events Deferred Until the Design Phase

5 19 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

5 20 Information about Each Event in an Event Table: Catalog of Information about Each Use Case

5 21 RMO Event Table (Figure 5-6 partial)

5 22 “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?

5 23 Types of Things

5 24 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

5 25 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 Attribute l One specific piece of information about a thing

5 26 Relationships Naturally Occur Between Things

5 27 Cardinality/Multiplicity of Relationships

5 28 Attributes and Values

5 29 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

5 30 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

5 31 Data Entities Compared with Objects

5 32 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

5 33 UML Class Symbol

5 34 Simple Domain Model Class Diagram 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

5 35 Multiplicity of Associations (Figure 5-32)

5 36 University Course Enrollment Domain Model Class Diagram (Figure 5-33)

5 37 Refined Model with Association Class and Grade Attribute

5 38 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

5 39 A Generalization/Specialization Class Hierarchy for Motor Vehicles

5 40 A Generalization/Specialization Class Hierarchy for RMO Orders

5 41 Whole-Part Aggregation Relationship

5 42 RMO Domain Model Class Diagram

5 43 Design Class Diagram Notation: Software Classes with Methods

5 44 Expanded Course Enrollment Design Class Diagram

5 45 Where You Are Headed

5 46 Summary u Analysis phase – defines system requirements u Models created to further learning process, reduce complexity, communicate with team members, and document requirements u Mathematical, descriptive, graphical models used 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 u Use cases (activities) are identified from user goals and business events that trigger elementary business processes u Business events (external events, temporal events, and state events) are memorable, can be described, and occur at a specific time and place u Event table records event, trigger, source, use case, response, and destination 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)