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

2. 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

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

4. 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 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

6. 5 6 Models Created by Analysis Activities

7. 5 7 Models Used in Design

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

9. 5 9 Identifying Use Cases Based on User Goals

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

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

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

13. 5 13 External Event Checklist

14. 5 14 Temporal Event Checklist

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

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

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

18. 5 18 Events Deferred Until the Design Phase

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

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

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

22. 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?

23. 5 23 Types of Things

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

25. 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

26. 5 26 Relationships Naturally Occur Between Things

27. 5 27 Cardinality/Multiplicity of Relationships

28. 5 28 Attributes and Values

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

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

31. 5 31 Data Entities Compared with Objects

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

33. 5 33 UML Class Symbol

34. 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

35. 5 35 Multiplicity of Associations (Figure 5-32)

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

37. 5 37 Refined Model with Association Class and Grade Attribute

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

39. 5 39 A Generalization/Specialization Class Hierarchy for Motor Vehicles

40. 5 40 A Generalization/Specialization Class Hierarchy for RMO Orders

41. 5 41 Whole-Part Aggregation Relationship

42. 5 42 RMO Domain Model Class Diagram

43. 5 43 Design Class Diagram Notation: Software Classes with Methods

44. 5 44 Expanded Course Enrollment Design Class Diagram

45. 5 45 Where You Are Headed

46. 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)