Systems Analysis and Design in a Changing World, Thursday, Feb 22.
-
Upload
briana-briggs -
Category
Documents
-
view
216 -
download
0
Transcript of Systems Analysis and Design in a Changing World, Thursday, Feb 22.
Systems Analysis and Design in a Changing World, Thursday, Feb 22
2
Today’s Schedule
Using Events for Requirements Using “Things” for Requirements For Tuesday, February 27
Finish Reading Chapter 5, ERDs and Class Diagrams
Try out ERDs in Visual Paradigm
3
Recall … Where You Are Headed
4
Events Affecting a Charge Account Processing System that Lead to Use Cases
5
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
6
Sequence of “Transactions” for One Specific Customer >> Many Events
7
Defer Some Events Until Design
8
Event Table: Catalog of Information about Each Use Case
How do the “events” in Activity Diagram fit?
9
“Things” in 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?
10
Types of Things
11
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
12
Questions for Refining List
Should you include it?– A unique thing system needs to know about?– Inside scope of this system?– Need to remember more than one of these?
Should you exclude it?– Synonym for another thing already in list?– Is it really an output?– Input that results in recording info already in list?
Should you research it?– Is it a characteristic of another “thing”?– What if assumptions change, is it still needed?
13
“Things” have …
Relationship– Naturally occurring association among specific
things– Occur in two directions– Number of associations is cardinality or multiplicity
Binary, unary, ternary, n-ary
Attribute (characteristic)– One specific piece of information about a thing
14
Cardinality/Multiplicity of Relationships
15
Attributes and Values
Identifier or Key – Attribute that Uniquely identifies the “thing”
16
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
17
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
18
Data Entities Compared with Objects (Figure 5-22)
19
The Entity-Relationship Diagram (ERD)
20
Cardinality Symbols of Relationships for ERD
21
Expanded ERD with Attributes Shown
22
Customers, Orders, and Order Items
23
ERD with Many-to-Many Relationship
24
Many-to-Many Relationship Converted to Associative Entity to Store Grade Attribute
25
RMO Customer Support System ERD(Figure 5-29)
26
Now you try it …
Case Study: (Page 194-5) The Spring Breaks ‘R’ Us Travel Service Booking System
#1 Events and event Table #2 Data Entities and their relationships
27
For Tuesday, February 27
For Tuesday, February 27Finish Reading Chapter 5, ERDs and Class Diagrams
Try out ERDs in Visual Paradigm