Events and Things
Download
Report
Transcript Events and Things
Systems Analysis and Design in a
Changing World, Thursday, Feb 22
Today’s Schedule
2
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
Recall … Where You Are Headed
3
Events Affecting a Charge Account
Processing System that Lead to Use Cases
4
Identifying Events
5
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 “Transactions” for One
Specific Customer >> Many Events
6
Defer Some Events Until Design
7
Event Table:
Catalog of Information about Each Use Case
How do the “events” in Activity Diagram fit?
8
“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
–
9
What things does the system need to know about and store
information about?
Types of Things
10
Developing an Initial List of Things
11
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
Questions for Refining List
Should you include it?
–
–
–
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?
–
–
12
A unique thing system needs to know about?
Inside scope of this system?
Need to remember more than one of these?
Is it a characteristic of another “thing”?
What if assumptions change, is it still needed?
“Things” have …
Relationship
–
–
–
Naturally occurring association among specific
things
Occur in two directions
Number of associations is cardinality or
multiplicity
Attribute (characteristic)
–
13
Binary, unary, ternary, n-ary
One specific piece of information about a thing
Cardinality/Multiplicity of
Relationships
14
Attributes and Values
Identifier or Key – Attribute that Uniquely identifies the “thing”
15
Data Entities
16
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
Objects
do the work in a system and store
Objects
information in the object-oriented approach
Objects have behaviors and attributes
–
–
–
17
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)
18
The Entity-Relationship Diagram
(ERD)
19
Cardinality Symbols of
Relationships for ERD
20
Expanded ERD with Attributes
Shown
21
Customers, Orders, and Order
Items
22
ERD with Many-to-Many
Relationship
23
Many-to-Many Relationship Converted
to Associative Entity to Store Grade
Attribute
24
RMO Customer Support System ERD
(Figure 5-29)
25
Now you try it …
26
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
For Tuesday, February 27
27
For Tuesday, February 27
Finish Reading Chapter 5,
ERDs and Class Diagrams
Try out ERDs in Visual Paradigm